Last week the freedom warrior Let’s Encrypt project released its root Certificate Authority (CA) certificate. Right now it is not trusted by browsers, but Let’s Encrypt has submitted it with all of the requisite proof for inclusion into the most popular browsers, so that will happen soon enough.
In the meantime, IdenTrust, a founding member of Let’s Encrypt, will be cross-signing the root, at which point the Let’s Encrypt-issued certificates will be trusted in by your browser. But, as the project gets closer to general availability, Let’s Encrypt is running into the more complicated aspects of the global public-key infrastructure (PKI), such as scaling certificate issuance and revocation.
For those just joining this discussion, I’m talking about the SSL Certificate Authorities. CAs are the corner stone of encryption and how it’s provided on the Internet. In the nineties, CAs were an innovative bunch, but after a few decades of neglect, that is no longer the case. That, along with a series of missteps within the CA industry, led a coalition of fed-up do-gooders to band together with the idea of creating a free, fully automated CA named Let’s Encrypt (hereafter LE). Even though it probably sounds like I’m always picking on them, I actually do hope they succeed. They remind me of the band of rogue pirate accountants in Monty Python’s short film, the Crimson Permanent Assurance, waging a doomed war against their more-powerful corporate rivals.
At their talk at Defcon 23 this summer, the LE project team laid out a new schedule. They’ve already slipped a bit but not too egregiously, especially when compared with traditional software development models. If LE stays on track going forward, they will be issuing certificates in mid-November. But here’s the thing.
Issuing certificates is easy. CA’s have been issuing SSL certificates via web APIs automatically for over a decade. The hard parts are verifying the person requesting the certificate is entitled to it, and handling revocation for those certificates when there is a compromise.
Both of these are hard problems to solve so, to make their lives simpler, LE has decided to only issue Domain Validated (DV) certificates, as opposed to the more stringently vetted Extended Validation (EV) certificates. But, even DV certificates often need manual intervention in the process. It will be interesting to see how LE handles this at scale without watering down the already fairly weak promises modern CAs make when issuing certificates.
Revocation is another hard problem. So hard, in-fact, Google Chrome no longer trusts CAs to operate their own revocation infrastructure and has developed its own proprietary solution. Here is where LE is doing something a little more unique; it is issuing “short-lived” certificates for which validity will be measured in days and not years. This will reduce the need to ever revoke a certificate, but it does not replace the need to have a scalable revocation solution.
Authentication systems based on symmetric cryptography (Active Directory, Kerberos, Novel, etc.) have the opposite problem. Symmetric crypto-based solutions make credential revocation easy (mark a password bad in a database), but issuing new credentials (password maintenance) as users forget them is a nightmare. Where passwords are the Achilles’ heel of the symmetric crypto world, revocation is the Achilles’ heel of PKI.
The password problem hasn’t been fixed after 20 years of consumer Internet. That failure doesn’t bode well for the security of the millions of retailer-level certificates that may appear if LE succeeds.
The LE team appears to be aware of the revocation pitfall: “Revocation is broken [across the Internet,]” they said in their Defcon23 talk. The LE team has a revocation system in place (Online Certificate Status Protocol (OCSP) servers cached by Akamai). The LE team is also championing the Automatic Certificate Management Environment (ACME) protocol, which must bring more automation to the certificate renewal process or the universe of short-lived certificates will expire on some horrible “Black Monday” months hence.
All that said, I hope LE succeeds in its overall goal to provide a better, more transparent PKI for the Internet. The LE effort may be a long shot because honestly, running a CA isn’t a hobby, has no associated glory, and it’s not particularly cheap. When the funding runs out, will LE sustain the same level of innovation and dedication fueled only by volunteer effort, idealism, and caffeine?
If LE succeeds, it might influence the rest of the CA industry to get its act together. It might drive many of the slightly sketchy bargain CA companies out of the market. The automation derived from the new ACME protocol may boost the adoption of transport layer security—at least for DV certificates. And a proliferation of retail-level certificates might induce browsers and web servers to optimize their support for new certificate verification technologies likeOCSP multi-stapling.
Let’s watch what the team does in November and hope for the best. If you want to take a proactive step, visit the LE project’s Get Involved page and pledge your support.
