The security industry has no shortage of hard problems to solve, but the one that’s getting the most attention right now is finding a way to improve, or ideally, replace, the CA infrastructure. The latest in what has become a series of recent proposals to help shore up the certificate authority system comes from a pair of Google security researchers who have laid out a plan for providing auditable public logs of certificates as well as proofs for each certificate that’s issued.
The system proposed by Google’s Adam Langley and Ben Laurie comprises three separate ideas, but relies on the creation of a publicly viewable log of every public certificate that’s issued by a CA. There could be any number of public logs of these certificates, but the logs will be structured so that they are append-only. The entries in the logs will be the end certificates in the issuance chain. In addition to the logs, the proposal includes the use of proofs that are sent with each certificate to the user’s browser. Laurie and Langley haven’t defined exactly what the proof would look like, but suggest that it could be an extra certificate or a TLS extension.
“As the log grows, new entries will be periodically signed using a signed Merkle Tree. The log will be publicly available for download (probably in chunks corresponding to the Merkle signatures). Thus, domain owners can monitor the logs for certificate issuance for their domain. If a certificate is issued that should not have been, then the domain owner will have proof of that fact (the mere existence of the certificate is sufficient). And since browsers will check the Merkle proofs (see below), it will not be possible to issue a certificate that does not appear in the audit log,” the researchers wrote in their paper, “Certificate Authority Transparency and Auditability”.
One of the main problems that the proposal is meant to address is that of attackers being able to compromise CAs in one way or another and issue their own certificates for domains they don’t own. This has happened a couple of times in the last year, with the attack on Comodo and the compromise of DigiNotar later in the year. The attacker, who appears to have been the same in both cases, was able to issue valid certificates for a large number of domains, including Google, Skype, Yahoo, CIA and others.
Laurie and Langley’s proposal contemplates three different scenarios that could occur if a CA issues a certificate that it should not have, either by mistake or through a compromise. If the bad certificate doesn’t appear in a public log and none of the logs colludes with the CA, then the client will reject the certificate. If the certificate is in a public log, then the browser will acept it, but the legitimate owner of the domain will be able to see it and have it revoked. In the third scenario, if the certificate isn’t in the public log and a log provides the CA with a fraudulent proof for it, then the browser would accept the certificate, as well. But that proof eventually would be seen to not correspond with the public logs and would also serve as proof that the log that colluded with the CA had acted badly.
The researchers say that their proposal should be highly backward compatible with existing browsers and servers. It would mainly require just a configuration change on the server side, and if an older browser wasn’t able to read the public certificate logs, it would just ignore the extra code.
The proposal from the Google researchers is the latest in a line of ideas meant to address the inherent weaknesses of the CA system. Researcher Moxie Marlinspike has rolled out an entirely new system called Convergence that relies on notaries rather than the existing CA infrastructure. And the EFF has proposed another scheme called Sovereign Keys that is designed to associate specific keys with specific domains.
