|
Size: 111
Comment:
|
Size: 2521
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 |
| Line 5: | Line 5: |
| Slides: | 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 * Yes, this is a CA-like approach * 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, CCC, ... ? * 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]] |
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
- 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, CCC, ... ?
- 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
