{"id":583,"date":"2017-04-29T11:43:36","date_gmt":"2017-04-29T19:43:36","guid":{"rendered":"http:\/\/unmitigatedrisk.com\/?p=583"},"modified":"2017-04-30T08:04:52","modified_gmt":"2017-04-30T16:04:52","slug":"revocation-reasons-dont-make-sense-for-the-the-webpki-of-today","status":"publish","type":"post","link":"https:\/\/unmitigatedrisk.com\/?p=583","title":{"rendered":"Revocation reasons don\u2019t make sense for the WebPKI of today"},"content":{"rendered":"

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.<\/p>\n

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.<\/span><\/p>\n

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 \u201crevoked\u201d certificates while the last is more like a lookup that it enables User Agents to ask the status of a particular set of certificates.<\/span><\/p>\n

In both cases they have the option to indicate why the certificate was revoked, the available options include:<\/span><\/p>\n\n\n\n\n\n\n\n
Reason<\/b><\/td>\nDescription<\/b><\/td>\n<\/tr>\n
Key Compromise<\/span><\/td>\nWe believe the key to have been stolen or can no longer be sure it has not been. <\/span><\/td>\n<\/tr>\n
CA Compromise<\/span><\/td>\nThe issuing CA itself has been compromised (think <\/span>DigiNotar<\/span><\/a>).<\/span><\/td>\n<\/tr>\n
Affiliation Changed<\/span><\/td>\nThe 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.<\/span><\/td>\n<\/tr>\n
Privilege Withdrawn<\/span><\/td>\nThe right to represent the given host was revoked for some reason.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

There are a few other reasons but they are not materially relevant to WebPKI use cases so I left them out.<\/span><\/p>\n

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<\/a> and CRLSets<\/a>) so it’s not particularly relevant to the options available to CAs anymore, at least in the WebPKI. <\/span><\/p>\n

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.<\/span><\/p>\n\n\n\n\n\n\n
<\/td>\nDV<\/b><\/td>\nOV<\/b><\/td>\nEV<\/b><\/td>\n<\/tr>\n
Key Compromise<\/span><\/td>\nYes <\/span><\/td>\nYes<\/span><\/td>\nYes<\/span><\/td>\n<\/tr>\n
Affiliation Changed<\/span><\/td>\nMaybe<\/span><\/td>\nYes<\/span><\/td>\nYes<\/span><\/td>\n<\/tr>\n
Privilege Withdrawn<\/span><\/td>\nMaybe<\/span><\/td>\nYes<\/td>\nYes<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nAs you can see, the available \u201creasons\u201d for DV certificates are largely reduced to just \u201cKey Compromise\u201d. There is an argument that both \u201cPrivilege Withdrawn\u201d and \u201cAffiliation Changed\u201d 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.<\/span><\/p>\n

So what about Key Compromise? \u00a0How 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!<\/span><\/p>\n

The reality is that most key compromise cases can not be detected and worse yet is that it\u2019s 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\u2019t necessarily know about it.<\/span><\/p>\n

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.<\/span><\/p>\n

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?<\/span><\/p>\n

That is not to say \u201cKey Compromise\u201d as a revocation reason is not important when there is a large-scale vulnerability like Hearbleed<\/a>\u00a0but this is not exactly a common case.<\/span><\/p>\n

The other cases for the \u201cKey Compromise\u201d revocation reason are notably dependent on the subscriber:<\/span><\/p>\n