An encryption key may need to be revoked for many reasons. In this video, you’ll learn about automated key revocation and how to revoke keys in a web-of-trust.
<< Previous Video: Certificate AuthoritiesNext: Digital Certificates >>
There are times when we create a certificate and then decide maybe we would not like to use that certificate any longer. There is a process for key revocation and this is handled through a CRL, which stands for a Certificate Revocation List. This is usually maintained by a Certificate Authority, so you can go to one central place and view the CRL for that particular CA. There’s lots of reasons you might want to revoke a key– maybe the key is not one you’d like to use anymore, maybe you feel that the key has been compromised and you want to be sure that nobody can use that key to do any type of encryption.
A significant case for key revocation was in April of 2014– and if you want to look up the CVE in 2014 of 0160 you can read all about heartbleed. This was the name that was associated with a bug that was discovered in a very popular web encryption library called OpenSSL. This OpenSSL flaw allowed people from the outside to view the memory of a machine and be able to pull private information directly from that device. Some of that private information could even be the private key for the web server. And because you never knew if somebody did actually gain access to your private key, every web server had to have a replacement certificate.
And now that you’ve got a new certificate, you wanted to be sure that nobody would try to use the old certificate and so everybody had their old certificates added to the CRL. To be able to query the CRL and look at the revocation list, a protocol was created called OSCP– stands for Online Certificate Status Protocol– and your browser knows how to use that protocol to communicate back to the CEA and check the status of a certificate.
These messages are usually sent via HTTP so it’s very easy to get that across the network and through firewalls. And it’s a way that is very standardized across many different browsers. However, many browsers don’t have the knowledge of how to use OSCP– especially older browsers were never developed with OSCP as part of its configuration.
And even today some modern browsers– even though they are OSCP capable– have not been configured in the software to even check for revocation. The concept of checking for revoked keys is one that we didn’t pay a lot of attention to, but now that we’ve discovered this heartbleed problem– and now that we have so many keys that had been revoked– a lot of browser manufacturers are going back and doing the development work to properly support this very important OSCP protocol.
In a web-of-trust you don’t have a Certificate Authority. If you’re using something like PGP the keys are managed by all of the key users. You would then go to a friend of yours and have them sign your key and you would sign theirs. And then their friends would sign theirs, and there would be a web-of-trust created all the way through all of those signed keys.
If you then need to revoke a key, you would create a revocation certificate. And you can keep that revocation certificate on some centralized key servers that are located on the internet. You can also configure some of this software to have other people create revocation certificates for your key that way you’re all working together to make sure that the keys that are in use are really the ones that are appropriate and trusted for every user.