Public-key cryptography enables transactions among those parties who haven’t previously agreed upon a symmetric cryptographic key. To make public-key cryptography work, one needs a mechanism for binding a person’s public key to their private identity (or to some set of authorizations or properties) for the purposes of providing security services.
The most common mechanism for doing so is a digital certificate, which is a document that is digitally signed by a certificate authority (CA). The digital certificate contains, among other things, the person’s public key together with the information the person would like to bind to it (such as a his or her identity, a domain name, etc.). Ultimately, we are relying on the due diligence the certificate authorities conducted prior to issuing the certificate. The proliferation of certificate authorities, many of whom have lax practices, could seriously undermine confidence in certificates and the use of public-key cryptography in general.
To address this concern, various CAs and browser vendors have gotten together to define a standard for a high assurance (HA) certificate, which is sometimes referred to as an extended validation certificate. Simply put, a high assurance certificate is one for which a “reputable” CA conducted due diligence prior to issuing the certificate, to ensure that the entity requesting the certificate met “certain” criteria. I have put the words “reputable” and “certain” in quotes because we have to drill down and define them precisely so we know what an HA cert means. Specifically, we would need to know:
• Who can issue an HA cert? Surely, for such a certificate to have meaning, not just any CA should be able to issue them. But who gets to decide who can issue such certificates? If the list of CAs who can issue HA certs is very small, then you might lock out numerous CAs and encourage oligopolistic behavior, which might inhibit the spread of HA certs. If users are not used to seeing such certificates they will continue to transact with vendors who do not have them. On the other hand, if too many CAs can issue HA certs, it will be hard to know whether they are all conforming to the same rigid standards for issuing them. Are they all performing the same level of background checks? If not, then HA certs will have lost their meaning.
• What criteria are required for obtaining such a certificate? Again, if the purpose of an HA cert is to trust the person who possesses it, we need to know what standards they needed to meet. For example, did they have to provide proof of being in business for some number of years? Did they have to prove that they held a membership with the Better Business Bureau, or maintained a certain income level, or did they have to provide Dun and Bradstreet records? If the criteria required to obtain a certificate are unnecessarily strict, we might lock out numerous businesses. This would also inhibit the spread of HA certs. On the other hand, if we set the bar very low and it becomes easy to obtain such a certificate, then anyone can get one. As a result, users will encounter them so often that HA certs will have lost their meaning.
As of this writing, I haven’t found precise answers to these questions. In general, one of the challenges involved in defining such a standard is that it requires many different parties (such as certificate authorities, browser manufacturers, etc.) with different interests to agree on a well defined common set of criteria. For example, each CA might already have its own class of certificates that provide better assurances. If the final agreed-upon standard for an HA cert differs from what that CA is doing now, they would have to “patch” their user base. This would require operational changes, amendments to their certification practice statement, and could be a very expensive proposition (which a CA will likely resist).
There are other caveats regarding HA certificates. First, using an HA certificate alone is not sufficient for providing security. For example, a CA could mistakenly issue a certificate to an illegitimate party. Or, a legitimate party might accidentally leak its private key. If users put too much trust into HA certs, then they may be more likely to divulge their information to someone who possesses such a certificate even if that person is malicious. Second, the CA’s role is not just limited to the safe issuing of certificates, but also extends to complete certificate lifecycle management. In particular, CAs must do an adequate job of renewing certificates, re-keying them, and possibly even revoking them. If they fail in any of these areas, then security could be compromised. For example, if a CA’s re-keying process is insecure, then an attacker can try to take a legitimate certificate and get it re-keyed. He will then possess a new certificate for which he knows the private key.
The idea behind a high-assurance certificate is very noble. Certificates are meant to provide assurances so that one can make a well-informed security judgment based on them. By trying to specify the level of assurance a certificate provides, we can attach more meaning to them. The ultimate test for high-assurance certificates is whether they indeed provide a favorable trade-off between the extra security gained and the extra costs involved in obtaining them. We believe that they raise the bar for attackers, but the extent of that is not clear yet because the final standard hasn’t been published, and we do not know how extensively they will be deployed.
At the end of the day, high assurance certificates are still just one part of the “security value chain,” so to speak. Ultimately, we have to be clear on the precise value provided by a given technology, and we need to understand how different technologies can be nested together to provide defense in-depth.
Below are some recommended blog articles related to HA certificates from different browser vendors:
• Microsoft IE7: http://blogs.msdn.com/ie/archive/2005/11/21/495507.aspx
• Konqueror: http://dot.kde.org/1132619164/
• Mozilla: http://www.hecker.org/mozilla/ssl-ui
Listed below are links to some posts that Ian Grig has on his blog regarding HA certificates:
• https://www.financialcryptography.com/mt/archives/000663.html
• https://www.financialcryptography.com/mt/archives/000662.html