Hi all, A recent thread on CAs using contractual terms to revoke certificates has made me want to bring up a topic that I am surprised does not come up more: removing the control of revocation from CAs and moving it to the user agent. While this is an idea that requires the backing of a user agent (for which I have none), I think it's worthwhile to float as a future prospect.
Revocation, fundamentally, is a measure that relying parties need to stay secure. CAs are largely not aligned with the relying party's incentives in this case -- they want to exert control over their issued certificates in a commercial manner, but they do not have an incentive to make this particularly fast/reliable/anonymous. Relying parties do not care if a site did not renew their contract, and they are forced to download a CRL with junk entries or compromise their privacy by contacting the CA via OCSP. Today, the web is stuck between a rock and a hard place with very little way to reliably and anonymously validate whether a certificate has been compromised or misissued. User agents, historically, have had to build their own revocation infrastructure for a variety of reasons. Calling an OCSP service may introduce privacy issues, CAs may not revoke a certificate quickly enough that threatens user security, etc. Mozilla has OneCRL, Google has CRLSets, Apple has something unnamed(?). This means that user agents have already built most of this infrastructure to revoke certificates independently of their issuer. And since the user agent is already acting on behalf of the user, they are best positioned to align their interests with the greater web. Unfortunately, no user agent has operationalized their mechanism in a way that allows for speedy revocation by all parties on the web. If the key of a certificate is compromised, anyone should be able to submit it to user agents and have a revocation notice pushed out to clients around the world -- eliminating the privacy risks of contacting individual CAs, increasing the risk of vendors distributing a hardcoded key, and improving efficiency of what is today a scattered database of thousands of individual CRLs. Since a "rogue" CA is unable to revoke their customer certificates, this also improves the state of the ecosystem in terms of predatory practices. But you may ask, what happens if there is a mis-issuance? Well, we have now built a perfect choke point for CAs: when they mis-issue a certificate, the user-agents will revoke them upon request, but they are able to require a complete incident report in a timely manner beforehand or afterwards. CAs cannot silently revoke a mistake or otherwise cover up a problem without leaving the certificates as valid. This proposal can be implemented with zero changes to certificate issuance processes today. Certificates can still include a legacy CRL/OCSP method, but modern user-agents will be able to ignore these in favor of the more reliable database they have locally. Anyway, these are just my 2 cents. Hopefully this sparks some interesting conversation :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
