Certificate revocation list
|
|
In the operation of some cryptosystems, usually PKIs, a certificate revocation list (CRL) is a list of certificates (more accurately: their serial numbers) which have been revoked, are no longer valid, and should not be relied upon by any system user. A certificate is revoked (and entered on a CRL) if, for instance, it is discovered that the certificate authority (CA) had improperly issued a certificate or a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements such as publication of false documents, mis-representation of software behavior, or violation of any other policy specified by the CA operator or its customer.
Usually, a CRL is generated on the one hand periodically after a clearly defined timeframe and (optionally) on the other hand immediately after a certificate has been revoked. The CRL is always issued by the CA which issues the corresponding certificates. All CRLs have a (often short) lifetime in which they are valid and in which they may be consulted by a PKI-enabled application to verify a counterpart's certificate prior its use. To prevent spoofing or denial-of-service attacks, CRLs are usually signed by the issuing CA and therefore carry a digital signature. To validate a specific CRL prior relying on it, the certificate of its corresponding CA is needed, which usually can be found on a (even public) directory.
Certificate expiration dates are not a substitute for a CRL as the problem may be discovered whilst the certificate has not yet expired. CRLs or other certificate validation techniques are a necessary part of any properly operated PKI as mistakes in certificate vetting and key management are expected to occur in real world operations. In a noteworthy example, a certificate for Microsoft was mistakenly issued to an unknown individual who had successfully posed as Microsoft by the CA contracted to maintain the ActiveX 'publisher certificate' system (VeriSign). Microsoft saw the need to patch their cryptography subsystem so it would check the status of certificates before trusting them. 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 'revoked'.
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.
Problems with all CRLs
Best practices require that wherever and however certificate status is maintained, it must be checked whenever one wants to rely on a certificate. Failing this, a revoked certificate may be incorrectly accepted as valid. This means that to effectively use a PKI one must have access to current CRLs (i.e. Internet access in the case of a PKI). This requirement of 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, also depend on the existence of on-line services (Key distribution center in the case of Kerberos).
The existence of a CRL implies the need for someone (or some organization) to enforce policy and revoke certificates deemed counter to operational policy. If a certificate is mistakenly revoked significant problems can arise. As the certificate authority is tasked with enforcing the operational policy for issuing certificates they typically are reponsible for determining if and when revocation is appopriate by interpreting the operational policy.
The necessity of consulting a CRL, or other certificate status service, prior to accepting a certificate raises a potential denial-of-service attack against the PKI akin to the denial-of-service attack on Kerberos whereby a current authentication token cannot be retrieved.
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 alternative to using CRLs which is especially useful for software clients is the on-line certificate validation protocol Online Certificate Status Protocol (OCSP). OCSP has the primary benefit of requiring less network bandwidth and thus enabling real-time and near real-time status checks for high volume or high value operations.