Certificate revocation list
From Wikipedia, the free encyclopedia
In the operation of some cryptosystems, usually public key infrastructures (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 on by any system user.
There are different revocation reasons defined in RFC 3280 :
- revoked: A certificate is irreversibly 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. The most common reason for revocation is the user's not being in sole possession of the private key (e.g token containing the private key has been lost or stolen).
- hold: This reversible status can be used to notice the temporary invalidity of the certificate, for instance when the user is not sure if the private key has been lost. If, in this example, the private key was found again and nobody had access to it, the status can be reinstated, and the certificate is valid again, thus removing the certificate from further CRLs.
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 can usually be found in a 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.
[edit] 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 use a PKI effectively 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 cryptography protocols, namely that the certificate is "self authenticating". Symmetric systems, 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 revoked mistakenly, significant problems can arise. As the certificate authority is tasked with enforcing the operational policy for issuing certificates they typically are responsible for determining if and when revocation is appropriate 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.
