As the old saying goes, to err is human but to forgive is divine, in WebPKI you deal with errors through the concept of revocation.
In the event a CA determines it made a mistake in the issuance of a certificate or has been notified by the subscriber they would like to see a certificate marked invalid, they revoke the corresponding certificate.
The two mechanisms they have available to them to do this are called Certificate Revocation Lists and OCSP responses. The first is a like a phonebook of all known “revoked” certificates while the last is more like a lookup that it enables User Agents to ask the status of a particular set of certificates.
In both cases they have the option to indicate why the certificate was revoked, the available options include:
|Key Compromise||We believe the key to have been stolen or can no longer be sure it has not been.|
|CA Compromise||The issuing CA itself has been compromised (think DigiNotar).|
|Affiliation Changed||The certificate contained affiliation information, for example, it may have been an EV certificate and the associated business is no longer owned by the same entity.|
|Privilege Withdrawn||The right to represent the given host was revoked for some reason.|
There are a few other reasons but they are not materially relevant to WebPKI use cases so I left them out.
CA Compromise is clearly a special and exceptional case, so much so that browsers have developed their own mechanism for dealing with it (see OneCRL and CRLSets) so it’s not particularly relevant to the options available to CAs anymore, at least in the WebPKI.
Another thing to consider when looking at revocation reasons is that about 90% of all certificates in used in the WebPKI (for TLS) are considered to be Domain Validated (DV) certificates, this limits the applicability of the remaining reasons substantially.
As you can see, the available “reasons” for DV certificates are largely reduced to just “Key Compromise”. There is an argument that both “Privilege Withdrawn” and “Affiliation Changed” could be applicable to DV but in my opinion, they are a bit of a stretch. If nothing else the difference between these two reasons in the case of DV is so subtle you will almost never see these two usages be used on a DV certificate.
So what about Key Compromise? How useful is it? Clearly, it is an important use case, your trust in an SSL certificate is frankly only as good as your confidence in how well the key is protected!
The reality is that most key compromise cases can not be detected and worse yet is that it’s far too easy to compromise an SSL key. Take for example the Heartbleed (http://heartbleed.com/) bug from last year, SSL keys are often kept in the process and relatively minor coding mistakes, as a result, can potentially expose that key and users won’t necessarily know about it.
Some platforms go out of their way to prevent such attacks at the expense of performance like we did at Microsoft with SCHANNEL where we keept the key out of process but this is the exception and not the rule.
Also popping a web server due to some third-party code vulnerability and getting to the shell in the context of the server is unfortunately far too easy. As a result, when an attacker does get a shell on a web server one of the first things they should be doing is taking that key so they can use it later, but again, how is this detected?
That is not to say “Key Compromise” as a revocation reason is not important when there is a large-scale vulnerability like Hearbleed but this is not exactly a common case.
The other cases for the “Key Compromise” revocation reason are notably dependent on the subscriber:
- Knowing the compromise happened,
- Being mindful enough to notify the CA,
- Being willing to let the world know there was a compromise.
This last point of public signaling of “compromise” combined with the fact user agents treat all revocations the same (if they check at all) means that we seldom see subscribers even specify a reason when they ask for a certificate to be revoked.
As I look at why a certificate gets revoked today I think there are a few cases, these include:
- CA has decided the certificate should be revoked,
- The subscriber has decided the certificate should be revoked,
- A root program has decided a certificate should be revoked.
These are far more meaningful signals to relying parties that the ones listed above and are not so specific that these is any negative signaling in their use.
Today it is not possible to specify these things but maybe we should take a second look at revocation reasons and if we continue to use them make them more relevant to the way the WebPKI works today.