Our digital world is becoming more dependant on PKI (public key infrastructure) every day. All of us are barraged by digital certificates in our daily lives, though much of it occurs behind the scenes. Applications and devices that check for and "consume" digital certificates surround us. What once was a high-security assurance for James Bond types is a part of everyday life for Joe and Jane.
Smart cards used to only be for nuclear testing labs; now almost every company has one. Millions of websites are protected by SSL/TLS certificates. Our remote connections begin and end with digital certificates. And no rational person would think of downloading software without a valid digital signature present. I've even seen more than one person who had their public encryption keys tattooed on their body. (Note to those people: You will always win my unofficial geek contest.)
[ It's time to take another look at security. Two former CIOs show you how to rethink your security strategy for today's world. Bonus: Available in PDF and e-book versions. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
How digital certificates work
Digital certificates cryptographically tie one thing -- be it a person, company, or other entity -- to an unmodified or encrypted other thing (digital content, encrypted tunnel, and so on). Digital certificates attest to identity. A PKI is an involved (trusted) party that attests to the identity and issues the certificates. If the certificate checks out when consumed, we can supposedly rely on related digital content sent to or used by us as being legitimate. (I'm hugely simplifying here, so please, all you crypto-hobbyists out there, stop typing.)
PKI differs from other peer-to-peer digital trust encryption schemes, like PGP (Pretty Good Privacy), which is an example of peer-to-peer trust, because it implies that a trusted (or soon-to-be-trusted) third party is validating the certificate holder's identity. If we trust the identity verifier, we should trust the validity of the certificate holder. This emulates how much of the world trusts driver's license IDs to identify people and correctly state their date of birth.
A big part of the PKI process is revocation, performed by the digital certificate issuer when they no longer want the issued digital certificate to be used. A certificate can be revoked for a lot of reasons, ranging from the malicious compromise of any part of the issuing PKI infrastructure to the holder not paying their bill or being separated from employment to any reason the issuer decides.
When a consuming application receives a digital certificate to rely on, it is supposed to verify that the certificate is still valid (that is, not revoked, not expired, and other checks) before it begins to use it. Usually the revocation check begins by assembling (and downloading, if necessary) all the digital certificates from the current endpoint certificate back to its trusted root certification authority (CA). This is called certificate chaining (not to be confused with certificate pinning, which ties a specific certificate with a specific place).
Is this certificate still good?
After all the certificates in the chain have been assembled and verified, the revocation checking begins. This is usually a separate, but related process, which verifies that each certificate in the chain has not been revoked.
Normally this is done by looking at each (x.509's) certificate distribution point (CDP) field and finding one or more CDP entries. The CDP entries hopefully point to valid certificate revocation lists (CRLs), which contain revoked certificate entries maintained by the CA that issued the cert. More and more, however, the newer online certificate status protocol (OCSP) is used instead of CDPs. OCSP entries are found nearly the same way as CDPs, but result in a single client-side query and response, instead of the client having to download the whole CRL list -- which can be substantial. To add even more confusion to the process, many different OS and service vendors have their own revocation checking routines.
The latter process is causing much consternation between crypto-experts and hobbyists. I'm one of those who essentially believes that open standards are good and reinventing the wheel is not needed. Vendors inventing new methods have their reasons, and I believe their hearts are in the right place, but this is fracturing revocation checking at a critical time, when the process is becoming integral. Competing standards make it more likely that revocation checking won't work.
With revocation checking, each consuming client is essentially asking, "Is this certificate still valid and not revoked?" If the answer is in the affirmative, the client can supposedly rely on it. If not, they are supposed to reject the certificate and fail the current operation starting the whole process.