Cisco Blogs

Top of Mind: Reexamining Public Key Infrastructure

November 14, 2011 - 1 Comment

Nearly all of us depend on public key infrastructure (PKI) when we engage in secure transactions on the Internet. Digital certificates, most commonly based on ITU standard X.509, are used to prove that one is communicating with an intended website or Internet host. They are also used to establish the ownership of specific email addresses when S/MIME signing and encryption are used. Having a secure way to determine who you’re communicating with is important because an impostor or “man in the middle” site could decrypt the data sent to it, effectively defeating the security of the transaction.

Certificates issued by Certificate Authorities (CAs) digitally sign a public key presented by the subject (website/host or user) after some diligence (usually for a fee) is done to determine that the entity requesting the signature is in fact the legitimate owner of that host or address. The public keys of the Certificate Authorities are, in turn, configured into Web browsers, email clients, and other software that makes sure connections. If the host being communicated with proves ownership of a certificate that is signed by a recognized CA, the certificate is recognized as valid.

Security and process problems at several X.509 CAs, most notably DigiNotar and Comodo, have received considerable coverage in the past year. This has led to doubts about the long-term viability of the X.509 ecosystem, and alternatives have been proposed. I’d like to step back from that a little bit and look at the properties we would like to have in an idealized replacement system and then how that might be accomplished.

How many Certificate Authorities?

There are problems with having too many and with having too few Certificate Authorities. If there are too many, it’s not practical for users to know why they should trust all of them. If there are too few, certificate issuance can become too monopolistic (driving up prices) and may tend to disenfranchise sites that are geographically or politically distant.

My Firefox browser currently has 240 trusted root certificates from 88 different organizations ranging from “TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı” to “XRamp Global Certification Authority,” most of which I don’t recognize. (Some of these certificates were built into the browser and some were ones I added later.) With respect to the built-in certificates, it’s really the people at the Mozilla Foundation (who supply the Firefox browser) that I’m really trusting: they make the decisions about what root certificates to include with the browser. Perhaps there should be just one root certificate, that of Mozilla, in my browser and it should certify all of the other CAs that are currently root CAs. Whether Mozilla (or any other browser maker) is the “one true root” or works as it does today, an effective way of revoking the accreditation of a compromised or unreliable CA needs to be provided. Currently, this is done through revisions to the browser software itself.

Scope of Authority

Trusted (root) Certificate Authorities currently can sign certificates for anyone. Therefore, any of the CAs in my browser can create a valid certificate for a well-known site such as Google. This is unnecessarily broad. Google’s CA certificate is signed by only one root CA, and it’s a security risk for others to be able to issue certificates for them as well. This is effectively what happened in some of the recent breaches. The security of the system is determined by the weakest of the trusted CAs (all 88 or so). A better approach would be to only empower certain CAs to sign certain certificates, or to have a reliable way of determining what CA a given site or domain uses.

With the wider availability of secure Domain Name Service (DNSSEC), there is considerable discussion about ways to constrain the scope of Certificate Authorities. Secure DNS can be used to publish the certificate authority(ies) that serve a particular domain, or can be used to distribute public keys or certificates directly under the control of the given domain. This might be seen to reduce the value of CAs, but CAs are increasingly (as with Extended Validation certificates) certifying the binding between a domain name and a given corporate name or logo. This is important for discouraging certain types of phishing attacks using look-alike domain names.


Certificates sometimes need to be revoked, either due to a breach at the certificate owner’s site or as a result of unauthorized issuance of a certificate. Revocation is hard for both technical and practical reasons.

From a technical standpoint, complete verification that a certificate has not been revoked requires an online check. This is done using Online Certificate Status Protocol (OCSP), but it adds time to establishment of a secure session. Many implementations therefore default to not using OCSP, which makes it very difficult to detect a revoked certificate.

Revoking a certificate, particularly that of a CA, can cause significant collateral damage; this is the practical side of the revocation problem. In the case of the Comodo breach, even if it had been practical to revoke the CA’s certificate, doing so would have caused thousands of websites’ certificates to be rendered suspicious. This can be thought of as the CA version of the Too Big to Fail problem. If it was possible for certificates to contain more than one signature, it might be possible for sites to mitigate this risk by use of a multiply signed certificate (signed by Comodo and also by someone else). However, it’s not clear that many sites would actually go to the trouble and expense of getting multiple signatures, even if that were supported.


It’s far too late to change the X.509 public-key infrastructure; it is built in to far too many implementations. But new forms of distribution and accreditation are under development. One of the most promising is the work of the IETF Domain Authentication of Named Entities (DANE) Working Group, which is defining ways to store certificates in secured DNS records. Their work is still in early stages, but we hope that initiatives such as this will improve public-key infrastructure in the future.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Evening Jon.

    I was wondering if there is a certificate root for google chrome and if so, can you give it any kind of modification? Is it usefull by the way to add some more certification to the already presents ones? As i know nothing about those certification, maybe I should better not change anything. But still I’d like to know where to see that in firefox or chrome. It’s a matter of curiosity.