OpenPGPEmailSummit201512: EmailValidation
This is a summary and outcome of two session of the 3rd Open PGP Email Summit discussing how to deal with Key/Email Validations.
The topic is a follow-up from OpenPGPEmailSummit201512/EmailValidation.
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
Categorizing Key and Validation Servers
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 |
Standard Validation Signatures
The discussion went around the topic: In case servers validate email addresses and sign this validation in the key, can we establish an improved (backward compatible) signature format?
What informations should standard validation signatures hold?
So, let's first list what we want to signal with a validation signature (and see what can we do already with standard OpenPGP signatures):
| Currently with OpenPGP | Goal | How? | |
| What was validated? | the (person behind a) UID | the email address in a UID | new field for the exact email address |
| 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 and an optional expiry date. This can be a problem if the validation happened earlier than adding the signature (e.g. when signing later another key for the same email address). | A clear statement when exactly the validation happened. An expiry date still makes sense to helkp to filter out expires signatures. | recommendation to always set the expiry date to e.g. 1 year and a new field for the validation date |
| 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 |
What general requirements should apply for a standard validation signatures?
So, then let's talk about the general requirements for a new format:
- Backward Compatibilty:
The new format should be backward compatible. That is, we use the existing OpenPGP standard for signature and just add some supplementary details that would simply be ignored by existing clients. - Easy to identify There should be one common aspect signaling clearly to client that this standard extension is used.
- Easy to process It should be as easy as possible to process the additional informations.
- Easy to extend Whatever we define in the first version, it should be easy to extend the concept without breaking backward compatibility.
- KISS Let's start just with a fist approach, useful for itself and avoid to make it too complex by trying to be perfect.
Initial Proposed Format
The proposal
- The proposal is to
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)