|
Size: 154
Comment:
|
Size: 2647
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| OpenPGPEmailSummit: EmailValidation | = OpenPGPEmailSummit: EmailValidation |
| Line 3: | Line 3: |
| Workshop @ OpenPGPEmailSummit201512 run my Nicolai Josuttis | Workshop at [[OpenPGPEmailSummit201512|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 * 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 |
| Line 6: | Line 50: |
Whiteboard 2nd OpenPGP Summit: [[attachment:Whiteboard_EmailValidation.png]] |
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
