Tech Insight: New CA Group Has Big Names, Small Impact

As reported earlier today on Dark Reading, a group of big-name certificate authorities (CAs) have formed an organization called the Certificate Authority Security Council (CASC) to promote best practices in the use of the public key infrastructure on the Internet. The founding members are Comodo, DigiCert, Entrust, GlobalSign, Go Daddy, Symantec, and Trend Micro.

CAs such as Symantec, Go Daddy, and Comodo sell digital certificates and services related to them, but what they are really selling is trust. Users of digital certificates -- website administrators, developers, end users, and pretty much everyone -- rely on the CA to authenticate the identity of the parties with whom they interact.

Compromises in this system aren't especially common -- as far as we know -- but when they happen, it's big, embarrassing news. Here are some examples:

If trust in the system breaks down, then the ability to perform sensitive operations on the Internet is threatened, so the CAs need to do whatever they can to keep the system trustworthy, or at least to keep up people's confidence in them. For this reason they have formed organizations to improve trust. For example, the CA/Browser Forum created the EV-SSL system; these are the special, very expensive digital certificates that turn your browser address bar green.

The CASC's first campaign will be to increase and improve the use of certificate revocation. Revocation is an essential element of trust in the PKI and played an important part in all four of the breaches listed above. In every case, false certificates were issued by attackers using the agencies of the CA. These certificates were revoked by the CA. The way the system works, the systems that rely on a certificate are supposed to check to see whether it has been revoked.

Revoked certificates classified as untrusted by Windows

There are two systems for revocation-checking: CRL and OCSP. CRL (certificate revocation list) is a simple list, published by the CA, of unique IDs of revoked certificates. Because these lists can get rather large, an alternative system was built. OCSP (Online Certificate Status Protocol) is an interactive protocol that systems can use to query a CA for the status of a specific certificate.

Both systems have downsides: Large CRLs consume bandwidth, and OCSP requests have multiple round-trips and latency. For these and other reasons, it's disturbingly common for software not to bother checking for revocation. Java, for instance, is set by default not to check for certificate revocation (but nobody has accused Java of being a secure system lately).

To lower the cost of an OCSP transaction, CASC is promoting a technology called OCSP stapling (see section 8 of RFC6066 -- TLS Extension Definitions). Stapling allows the site that holds the certificate also to hold a signed OCSP response and to serve it to users as part of the TLS handshake.

Certainly OCSP stapling is a good thing, although exactly how much of a help it will be is controversial. Adam Langley, a top encryption developer at Google, is on record doubting its real-world value:

"OCSP stapling has several issues. Firstly, the protocol only allows the server to staple one response into the handshake: so if you have more than one certificate in the chain the client will probably end up doing an OCSP check anyway. Secondly, an OCSP response is about 1K of data.

Remember the issue with overflowing the initcwnd with large certificates? Well the OCSP response is included in the same part of the handshake, so it puts even more pressure on certificate sizes.

" I put these concerns to CASC, and its response was that, in most cases, the other certificate in the chain is a trusted CA, so no check will be necessary. It added that browsers cache these responses, further diminishing traffic, and that in the longer term, improvements to OCSP stapling will bring further efficiencies.

Who's right? I can imagine research using the EFF's SSL Observatory to determine how common it is for certificates to have untrusted CAs in their certificate chains. Perhaps the CASC would be willing to do it.

In the meantime, don't look to do a whole lot of OCSP stapling soon. Support for it is not especially common. The Nginx Web server just recently got support (the work was paid for by Comodo, DigiCert, and GlobalSign, charter members of CASC). Nginx is an open-source Web server designed for high-volume servers. In its most recent survey, Netcraft found Nginx on 12.85 percent of all Internet-facing Web servers. Presumably the work is portable to other servers, chiefly Apache.

It's not like I object to the work of the CASC: It's unobjectionable, even laudable. It's just hard to see it making a big dent in the problem. Having written many papers on OCSP over several years, I know that the need for revocation-checking isn't a secret. People who aren't aggressive about it now are willful in their irresponsibility. What can CASC really do for them?

The CA/BForum was originally going to have a broader mission, but it seems to be limiting itself to EV-SSL now, and many of the same companies are now forming the CASC for purposes that can only be called "similar." Something political is going on there. At least the CASC says it supports the CA/Browser Forum in its work.

In the meantime, there are others who dismiss the whole CA system and seek to go beyond it. TACK (Trust Assertions for Certificate Keys) is a proposal for TLS extensions to allow clients to "pin" (as opposed to "staple"?) to a server-chosen signing key. TACK claims to be fully compatible with the existing CA infrastructure.

This stuff moves slowly. Even a relatively incremental change like OCSP stapling will take many years to become at all common because it requires code changed in every client and server. Same with more radical changes like TACK. The only way to speed change in a situation like this would be to disrupt business -- for instance, by deprecating support for older standards. This does happen, but slowly and rarely. But for the foreseeable future, we've made our PKI bed, and now we're going to have to sleep in it.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.