|
Size: 1946
Comment:
|
Size: 3778
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 12: | Line 12: |
| * **Validation Signature**: A signature that signals a successful validation | |
| Line 29: | Line 30: |
| The discussion went around the topic that **if** servers validate and sign this validation, can we establish an improved (backward compatible) signature format. that especially signals the successful validation of an email address? What do we want to signal with a validation signature (and what can we do already): || ||**Currently with OpenPGP**||**Goal**||**How?**|| ||What was validated?||the (person behind a) UID ||the email address in a UID|| ||How was validated?||only signature/certification levels ("0: no statement", "1: didn't validate", "2: casual validation", "3: extensive validation")||open list of keywords signaling how was validated (e.g. "encemail-and-click" for "click on URL after getting an encrypted email")||new field with predefined possible values|| ||When did the validation happen?||Currently there is only the timestamp of the signature, which would be a problem if the validation happened earlier than adding the signature (e.g. when signing later another key for the same email address), although you can set an expiry date already.||A clear statement when exactly the validation happened. An expiry date still makes sense.||new field|| ||Who validated?||defined by the signing key||no change here (we still want that trusting a key that represents the validation gives trust to the validated keys)|| ||Details of the validation policy||Policy URL||no change here (it makes sense to give the ability to add an URL that explains the validation (policy) in details|| ||???||???||signed certificate timestamp|| 0: no indication; 1: personal belief but no verification, useful for signing pseudonymous IDs; 2: casual verification; 3: extensive verification. |
OpenPGPEmailSummit201512: EmailValidation
Follow-Up from [[OpenPGPEmailSummit201512/EmailValidation]
General Discussion about Key and Email Validation
Terminology:
- Key Server: A server that manages keys
- Validating Server: A server that validates keys
- Validated-Keys Server: A server that only holds validated keys
- Servers can have multiple roles together
- Validation Signature: A signature that signals a successful validation
Current examples:
| pure Key Server | both Key- and Validating Server |
pure Validating Server | |
| doesn't add PGP signatures for signing | SKS | Mailvelope |
|
| adds PGP signatures for signing | GMX | TNG |
Better Table?:
| Key Server | only holds keys validated by |
Validating Server | adds PGP signature for validation |
|
| SKS | yes | |||
| yes | itself | |||
| GMX | yes | itself | yes | yes |
| Mailvelope | yes | GMX and ??? | yes | |
| TNG | yes | yes |
Discussion about Standard Validation Signatures
The discussion went around the topic that if servers validate and sign this validation, can we establish an improved (backward compatible) signature format. that especially signals the successful validation of an email address?
What do we want to signal with a validation signature (and what can we do already):
| Currently with OpenPGP | Goal | How? | |
| What was validated? | the (person behind a) UID | the email address in a UID | |
| How was validated? | only signature/certification levels ("0: no statement", "1: didn't validate", "2: casual validation", "3: extensive validation") | open list of keywords signaling how was validated (e.g. "encemail-and-click" for "click on URL after getting an encrypted email") | new field with predefined possible values |
| When did the validation happen? | Currently there is only the timestamp of the signature, which would be a problem if the validation happened earlier than adding the signature (e.g. when signing later another key for the same email address), although you can set an expiry date already. | A clear statement when exactly the validation happened. An expiry date still makes sense. | new field |
| Who validated? | defined by the signing key | no change here (we still want that trusting a key that represents the validation gives trust to the validated keys) | |
| Details of the validation policy | Policy URL | no change here (it makes sense to give the ability to add an URL that explains the validation (policy) in details | |
| ??? | ??? | signed certificate timestamp |
0: no indication; 1: personal belief but no verification, useful for signing pseudonymous IDs; 2: casual verification; 3: extensive verification.
Documents / Links / Resources
Whiteboard 3rd OpenPGP Email Summit:
- General discussion: Key and Email Validation:
- Standard Validation Signatures:
Feedback
Please send comments and feedback to Nico Josuttis, nico(at)enigmail.net (Fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5)