|
Size: 2521
Comment:
|
← Revision 33 as of 2016-07-21 09:36:43 ⇥
Size: 3514
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = OpenPGPEmailSummit: EmailValidation | ## page was renamed from OpenPGPEmailSummits-EmailValidation = OpenPGPEmailSummit201512: EmailValidation |
| Line 3: | Line 4: |
| Workshop at [[OpenPGPEmailSummit201512|2nd OpenPGP Email Summit, Dec 2015]] run by Nicolai Josuttis | Workshop at [[OpenPGPEmailSummit201512|2nd OpenPGP Email Summit, Dec 2015]] run by Nicolai Josuttis \\ Follow-Up: [[OpenPGPEmailSummit201607/EmailValidation]] == Approach |
| Line 7: | Line 11: |
| This would help to solve two major problems we have: | This would help to **solve two major problems** we have: |
| Line 9: | Line 13: |
| * 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 11: | Line 15: |
| The key approach is: | The **key approach** is: |
| Line 13: | Line 17: |
| * Define a standard signature format to signal successfull email validation ** The standard format would be: *** expires after 1 year |
* Define a **standard signature format** to signal successfull email validation ** The standard format would require to: *** let the signature expire after 1 year |
| Line 17: | Line 21: |
| *** having a link to the validation policy of the validation server | |
| Line 18: | Line 23: |
| *** E.g.: List who validated the email address or prefer validated email addresses over those not validated. | *** E.g.: **** Prefer or highlight keys that hav any such signature **** In the UI show a list of who validated the email address **** Signal trust for a UID if it is signed by one or more (specific) validating servers |
| Line 22: | Line 30: |
| * 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 |
* Establish some **initial validation servers** to perform that validations on request ** To validate: Sends email to email address in UID encrypted with the key to ensure that the one who confirms has the private key ** Request might be implicitly triggered by email clients or explicitly triggered by sending an email *** request shall be an email **** to ensure that the request is signed by the owner *** part of the email can be two hints: **** "upload to key server" **** "revoke signatures on old keys" |
| Line 27: | Line 40: |
Key properties of the approach are: |
**Key properties of the approach** are: |
| Line 31: | Line 43: |
| * 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 47: |
| * 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 50: |
| * 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 52: |
| ** But very important for the acceptance of OpenPGP because the naive user does not understand, why emails are not validated | |
| Line 41: | Line 54: |
| Open issues: | **Open issues:** |
| Line 45: | Line 59: |
* Who runs a first validation server? == Documents / Links / Resources |
|
| Line 50: | Line 68: |
| Whiteboard 2nd OpenPGP Summit: [[attachment:Whiteboard_EmailValidation.png]] | Whiteboard 2nd OpenPGP Email Summit: [[attachment:Whiteboard_EmailValidation.png]] == Feedback Please send comments and feedback to Nico Josuttis, nico(at)enigmail.net (Fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5) |
OpenPGPEmailSummit201512: EmailValidation
Workshop at 2nd OpenPGP Email Summit, Dec 2015 run by Nicolai Josuttis
Follow-Up: OpenPGPEmailSummit201607/EmailValidation
Approach
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 require to:
- let the signature expire after 1 year
- having a "signature notation" defining when/how/what was validated as JSON value
- having a link to the validation policy of the validation server
- The standard format allows email clients to process them accordingly
- E.g.:
- Prefer or highlight keys that hav any such signature
- In the UI show a list of who validated the email address
- Signal trust for a UID if it is signed by one or more (specific) validating servers
- E.g.:
- 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 require to:
- Establish some initial validation servers to perform that validations on request
- To validate: Sends email to email address in UID encrypted with the key to ensure that the one who confirms has the private key
- Request might be implicitly triggered by email clients or explicitly triggered by sending an email
- request shall be an email
- to ensure that the request is signed by the owner
- part of the email can be two hints:
- "upload to key server"
- "revoke signatures on old keys"
- request shall be an email
- 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.
- Who runs a first validation server?
Documents / Links / Resources
Initial Proposal: https://lists.gnupg.org/pipermail/gnupg-users/2015-July/053971.html
Slides: attachment:EmailValidation20151207.pdf
Whiteboard 2nd OpenPGP Email Summit: attachment:Whiteboard_EmailValidation.png
Feedback
Please send comments and feedback to Nico Josuttis, nico(at)enigmail.net (Fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5)