| 
  
   Size: 2521 
  
  Comment:  
 | 
  
   Size: 2647 
  
  Comment:  
 | 
| Deletions are marked like this. | Additions are marked like this. | 
| Line 9: | Line 9: | 
| * We have a lot of "moldered" keys (old keys not for any usage anymore | * We have a lot of "moldered" keys (old keys not for any usage anymore) | 
| Line 31: | Line 31: | 
| * Fast establishment possible when email clients (e.,g. enigmail) support this in a new version * The standard format might also be used by email providers, who provide both email address and keys (e.g. Google)  | 
|
| Line 33: | Line 35: | 
| * Careful selection of initial CAs ** Options: Current SMime CAs, trusted organizations, CCC, ... ? * Fast establishment possible when email clients (e.,g. enigmail) support this in a new version * The standard format might also be used by email providers, who provide both email address and keys (e.g. Google)  | 
** Careful selection of initial CAs ** Options: Current SMime CAs, trusted organizations, ... ?  | 
| Line 38: | Line 38: | 
| * This is *no perfect solution* but it makes faking keys a lot harder and easier to detect | * This is **no perfect solution**, but it makes faking keys a lot harder and easier to detect | 
| Line 40: | Line 40: | 
| ** But very important for the acceptance of OpenPGP because the naive user does not understand, why emails are not validated | 
OpenPGPEmailSummit: EmailValidation
Workshop at 2nd OpenPGP Email Summit, Dec 2015 run by Nicolai Josuttis
With this approach we want to establish a quick backward compatible solution to validate email addresses of UIDs of OpenPGP keys.
This would help to solve two major problems we have:
- People can currently easily upload faked keys (and they do)
 - We have a lot of "moldered" keys (old keys not for any usage anymore)
 
The key approach is:
- Define a standard signature format to signal successfull email validation
- The standard format would be:
- expires after 1 year
 - having a "signature notation" defining when/how/what was validated as JSON value
 
 - The standard format allows email clients to process them accordingly
- E.g.: List who validated the email address or prefer validated email addresses over those not validated.
 
 - But even existing email clients can benefit from them:
- According to the WebOfTrust a user can grant trust (and therefore priority) to emails with specific signatures
 
 
 - The standard format would be:
 
- Establish some initial validation servers to perform that validations on request
- Request might be explicit or implicit triggered when uploading own key
 - Sends email to UID encrypted with the key to ensure that the one who confirms has the private key
 - Validation can be done asynchonously (not hindering immediate use of a new key)
 
 
Key properties of the approach are:
- No change of existing key server infrastructure or protocol
 - Existing email clients can use it
 - Fast establishment possible when email clients (e.,g. enigmail) support this in a new version
 - The standard format might also be used by email providers, who provide both email address and keys (e.g. Google)
 
- Yes, this is a CA-like approach
- Careful selection of initial CAs
 - Options: Current SMime CAs, trusted organizations, ... ?
 
 
- This is no perfect solution, but it makes faking keys a lot harder and easier to detect
- Solution against trolls not against secret services
 - But very important for the acceptance of OpenPGP because the naive user does not understand, why emails are not validated
 
 
Open issues:
- How to ensure that the validation request is triggered by the owner of the key?
- To avoid spam DOS
 - Answer: explicit request by email client that supports this approach or by user sending a specific email.
 
 
Initial Proposal: https://lists.gnupg.org/pipermail/gnupg-users/2015-July/053971.html
Slides: attachment:EmailValidation20151207.pdf
Whiteboard 2nd OpenPGP Summit: attachment:Whiteboard_EmailValidation.png
