| |||||||||
In the operation of some cryptosystems, usually PKIs, a certificate revocation list (CRL) is a list of certificates which have been revoked, are no longer valid, and should not be relied upon by any system user. A certificate is revoked (and be entered on a CRL) if, for instance, it is discovered that the certificate authority (CA) had improperly issued a certificate: to the wrong person, with the wrong public key, to an ineligible person or entity, and so on. Alternatively, the private key corresponding to the public key contained in the certificate may have been compromised. Certificate expiration dates are not a substitute for a CRL as the problem may be discovered whilst the certificate has not yet expired.
A CRL is a prudent part of any practical PKI as mistakes in certificate generation can be confidently expected to occur in real world operations. In a particularly noteworthy example, a certificate for Microsoft was mistakenly issued to an unknown individual (who had successfully posed as Microsoft itself) by the CA contracted to maintain the ActiveX 'publisher certificate' system (VeriSign). Microsoft finally saw the need to patch their cryptography subsystems so they would actually check certificates being used against a CRL. As a short term fix, a patch was issued for the relevant Microsoft software (most importantly Windows) specifically listing the two certificates in question as 'invalid'.
The certificates for which a CRL should be maintained are often X.509/public key certificates, as this format is commonly used by PKI schemes.
Wherever, and however, a CRL is maintained, it must be available to a PKI participant whenever they might need access. Failing this, a revoked certificate may be accepted as valid because access to the CRL is temporarily not possible. This requirement of effectively on-line validation negates one of the original major advantages of PKI over symmetric cryptograhy protocols, namely that the certificate is "self authenticating". Symmetric system, e.g. Kerberos, typically depend on the existence of an on-line Key distribution center.
In addition, the existence of a CRL implies someone (or some organization) which decides that this certificate or that should be entered (or not) in the CRL. If this vetting is mistaken, problems will arise. As this is often done by the CA or some subsidiary, conflicts of interest will naturally often arise.
Still further, the necessity of consulting a CRL prior to accepting a certificate as reliable raises a potential denial-of-service attack against the entire PKI scheme and all its users. Moreover, an attacker could violate the integrity of the CRL, just as other components of the PKI are subject to attack. Even if the PKI is well protected, some attacks may succeed, resulting (at best) in a massive denial of service.
No comprehensive solution to these problems is known, though there are multiple workarounds for various aspects of it, some of which have proven acceptable in practice.
An increasingly popular alternative to using CRLs is on-line certificate validation. One of the options is the Online Certificate Status Protocol (OCSP) defined in . See also http://www.openvalidation.org/.
trusted third party, web of trust