Revoking Certificates

Public key infrastructure really relies on private keys remaining private. When those private keys are compromised or stolen, then the certificates that are associated with them are no longer valid. We need some mechanism in place so that when a key is compromised we can recall those certificates. So let's talk about certificate revocation and see what that looks like.

We'll start out by talking about the certificate revocation list, the CRL, and then we'll get into the online certificate status protocol, or OCSP, and then we're going to compare and contrast the two.

Why revocation is needed

When public key infrastructure was designed, it really was designed with the idea in mind that a user wouldn't have to wait for a response from a certificate authority, that it could go out and make a connection with any other parties involved. It does this by verifying the certificate from the servers by using a root certificate that's on the device, and then it can verify the certificate.

But the problem is that if this private key is compromised, then that certificate right there is compromised as well. We need some way to revoke that certificate, or let this user know that certificate is no longer valid.

Certificate revocation list

One way to do this verification is through a certificate revocation list, or a CRL. What happens is that there is a list of revoked certificates. So if this key was ever compromised, then whatever entity has that key would need to notify the CA that this key is compromised and therefore this certificate is compromised as well. It would add it to the list, then the user would download that list and reference the list to see if this certificate is valid or not.

Using this method can be problematic. One is that this list can actually become quite large, and so that could be problematic in trying to download a large list every time you want to verify a certificate. It would look to the end user like that site is being slow before a user could actually communicate with it.

The other problem too is that once you download it, that list is really outdated already. If this site were to be compromised after that and notify the certificate authority, and it would update the list, then there's this delay between the next time that you're actually going to download the list. Often what's going to happen is it's going to wait until that list is expired before it downloads a new list, so that can be problematic.

Online certificate status protocol

So there was a protocol that was created, the online certificate status protocol, or OCSP, that would run on the certificate authority. That way what this user could do is when it received a new certificate, it could do just a quick check-in, just a request, and say, is this certificate still good? And then it would receive a PL reply saying yay or nay, yes or no, that that certificate is good or not. So it's a much more dynamic way of doing a check.

Comparing the two

So between the two, CRL and OCSP, OCSP really is the clear winner, and CRL is not used very much. OCSP just is so much more dynamic. But the problem with it is that there still can be a delay from the service, causing a delay to the end user, and so the browser has to choose how to handle those delays. For one, if it doesn't receive a response back from the OCSP, what it's probably going to do is just assume that the certificate is valid and allow the communication to happen.

But quite honestly, a lot of browsers won't do either of these, that it is just going to do the validation check with the root CA and make sure that the root CA certificate validates that certificate, and then once it's done that, it's going to allow the communication.

This once again drives home the point that it is really important that those private keys remain private. It's going to be an essential part of this, because even if you submit something to your certificate authority saying I need to revoke this certificate, many users are not actually going to get that update that that certificate is revoked, causing a problem, or potentially causing a problem.

Summing up

So with public key infrastructure, the local computer is actually going to validate that certificate, but once it's validated, it needs to check to see if that certificate has been revoked, and it can do that with a certificate revocation list, a CRL, or an online certificate status protocol, OCSP. OCSP is much more dynamic and preferred out of the two, although the use of this is going to vary depending on which browser it is and which version of the browser it is. So you can't just rely on this. We really need to, for the most part, keep those private keys private. That's going to be the most important thing when it comes to PKI.