|
Size: 791
Comment:
|
Size: 2511
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| 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 |
|
| Line 7: | Line 11: |
| * Define a standard signature to signal successfull email validation * Establish some initial validation key servers to perform that validations |
* 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 * 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) |
| Line 11: | Line 28: |
| * No change of existing key servers (protocol) | * No change of existing key server infrastructure or protocol |
| Line 13: | Line 30: |
* Yes, this is a CA-like approach * Careful selection of initial CAs ** Options: Current SMime CAs, trusted organizations, CCC, ... ? * Fast establishment possible when e.g. enigmail and PGPTolls support it in new version * The standard format might also be used by email providers, who provide both email address and keys (e.g. Google) * This is *no perfect solution* but it makes faking keys a lot harder and easier to detect ** Solution against trolls not against secret services 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. |
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
- Yes, this is a CA-like approach
- Careful selection of initial CAs
- Options: Current SMime CAs, trusted organizations, CCC, ... ?
- Fast establishment possible when e.g. enigmail and PGPTolls support it in new version
- The standard format might also be used by email providers, who provide both email address and keys (e.g. Google)
- This is *no perfect solution* but it makes faking keys a lot harder and easier to detect
- Solution against trolls not against secret services
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
