Confirmed users
1,022
edits
Labs/Identity/VerifiedEmailProtocol: Difference between revisions
Jump to navigation
Jump to search
m
→Certification
m (→Certification) |
|||
| Line 219: | Line 219: | ||
The relying party, when it sees that a certificate is present, may choose to skip the retrieval of the user's public key by instead verifying the certificate. That flow would be: | The relying party, when it sees that a certificate is present, may choose to skip the retrieval of the user's public key by instead verifying the certificate. That flow would be: | ||
# Resolve a site-level public key for the issuer by performing host discovery on the email in the certificate (for example, by performing an RFC 5785 "well-known" lookup on an HTTPS server, or talking to a trusted directory server) | # Resolve a site-level public key for the issuer by performing host discovery on the email in the certificate (for example, by performing an RFC 5785 "well-known" lookup on an HTTPS server, or talking to a trusted directory server) <font color=green>Does this mean that there are more than one method used to do resource lookups? (WebFinger & "well-known"?) Isn't that potentially confusing to users and developers?)</font> | ||
# Verify the signature on the certificate using the public key | # Verify the signature on the certificate using the public key | ||
| Line 227: | Line 227: | ||
Unfortunately, adding revokation complicates this flow and reduces the privacy-enhancing properties of it. Just as with site-identifying certificates, the RP is required to either retrieve a revocation list or use an online status check (that is, a CRL or OCSP) to make sure an identity certificate is still valid. These steps have proven to be problematic for the site-identifying CAs that power the SSL site-identification infrastructure, and there is little reason to think that email hosts would be any more capable of handling them at larger scale. It may be realistic to think that the internet could support identity certificate revokation at scale; perhaps we should focus our attention instead on limiting the scope of breaches, for example by encouraging short-lived identity certificates and automated certificate refresh. | Unfortunately, adding revokation complicates this flow and reduces the privacy-enhancing properties of it. Just as with site-identifying certificates, the RP is required to either retrieve a revocation list or use an online status check (that is, a CRL or OCSP) to make sure an identity certificate is still valid. These steps have proven to be problematic for the site-identifying CAs that power the SSL site-identification infrastructure, and there is little reason to think that email hosts would be any more capable of handling them at larger scale. It may be realistic to think that the internet could support identity certificate revokation at scale; perhaps we should focus our attention instead on limiting the scope of breaches, for example by encouraging short-lived identity certificates and automated certificate refresh. | ||
<blockquote><font color=green>How best should this be addressed in the short term for the system we are creating? Should certificates have a mandatory expiration period of <5 minutes?</font></blockquote> | |||
= 5. User Experience Discussion = | = 5. User Experience Discussion = | ||