Certificate Revocation

If you don’t pay your credit card bill, the credit card company will revoke your charging privileges. In some cases, if you present your card to a store after it is revoked they may confiscate your card or cut it in half. If you only use your card online there is no way anyone could seize or destroy your card.

Years ago, credit card companies published little booklets with a list of all revoked credit card numbers (sorted by card number). Before they would accept your card, stores would check if your card number was in that booklet, and if it wasn’t they would accept your card (it was a blacklist not a whitelist). Sorting the card numbers made it quicker to check for a given card.

A user could still charge things until a new booklet came out, which the card company might have to take a loss on. If a store didn’t check and the card number was already in the booklet, they might be liable for bogus charges.

Certificate Revocation List (CRL)

Certificates have a similar scheme called Certificate Revocation List (CRL). A CRL is a list of all certificate serial numbers that have been revoked, but not yet expired. Once expired, the certs should not be accepted regardless and the serial number can be removed from the CRL.

The CRL also has a “next issue date” and is digitally signed by the issuing CA. The CA periodically issues a new CRL and publishes it via HTTP or LDAP. Every cert has a CRL Distribution Point in the cert that client software can use to obtain a fresh CRL. Once  a new CRL is obtained, it is cached until the “next issue date” when a new one will be downloaded and cached (the next time a cert from that certificate hierarchy is encountered). When certs are presented to that node, it will first check the cache, and only obtain a new CRL if a new one was available (the current time was later than the “next issue date”). Each hierarchy has its own CRL, so the cache might have a number of CRLs in it, each expiring at a different time.

Each computer has a separate CRL cache, so when my desktop downloads a new CRL, that new CRL isn’t available to my notebook computer, which must also download the new CRL the next time it has to check a cert from that hierarchy.

As with credit cards, with CRLs there is a delay between the time the CA actually revokes the cert and the relying parties become aware of that revocation. The more frequently CRLs are issued, the shorter that delay is, but the more often CRLs have to be downloaded. It is common for CRLs to be reissued every 24 hours, but some CAs have premium service to reissue them every hour. Because of the “next issue time” and caching, CRLs don’t use that much bandwidth.

OCSP – Online Certificate Status Protocol

To minimize the gap between revoking a credit card and stores becoming aware of it, credit card companies abandoned the revocation booklets and introduced little machines that could check the revocation status of cards online. The store would swipe the customer’s card and enter the amount of the transaction. The machine would dial in and check the revocation status of the card (and the available balance as well). It would reject or approve the transaction and give the store an approval code if accepted. Once the store got that approval code, the card company was responsible for any loss.

CAs came up with a similar scheme, based on a new protocol called Open Certificate Status Protocol (OCSP). A new company called ValiCert split off from VeriSign, and opened just down the street. They specialized in OCSP deployments. OCSP is currently specified in RFC 6960, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”, June 2014.

Anytime a relying party is presented with a cert, it can send just that serial number to the CA (based on information in the cert) via OCSP and get back a go/nogo status reflecting the current revocation status of that cert. Once it gets back a “revoked” status on a given cert, it can cache that, because once a CA revokes a cert, it should never “unrevoke” it.

In theory this could reduce the delay from revocation to end users becoming aware of it to near zero, but many OCSP servers just provided another way to access the CRL information, so there was still a delay, but it was easier to determine revocation status, and did not require caching of anything.

OCSP queries can be the majority of the network traffic at a CA. Most people don’t request or renew certs all that often (typically once a year for a given cert), but OCSP could be used every time a cert is presented. It is possible to have a local cache that is queried instead of going all the way to the CA on every request.