19.5 CERTIFICATE REVOCATION

Team-Fly

According to RFC 2828, certificate revocation refers to "the event that occurs when a CA declares that a previously valid digital certificate issued by that CA has become invalid" [6]. In practice, there are many reasons that may require certificate revocation. For example, a user's or a CA's private key may be compromised, or a user may no longer be registered and certified by a particular CA. In many legislations for digital or electronic signatures, the user may suspend a certificate (in addition to revoking it). This is interesting from a user's point of view, because it allows him or her to temporarily disable a certificate. Note, however, that providing support for certificate suspension is also very difficult to say the least. It requires that the entire history of a certificate (i.e., the validity intervals for the certificate) is maintained and properly managed for a potentially very long period of time. While we are starting to understand certificate revocation, certificate suspension is still largely not understood today. Therefore, we are not going to address the topic in this book.

In general, the certification and revocation of certificates involves three different parties:

The certificate-issuing authority (i.e., the CA or AA);
The certificate repository, such as a networked directory service (which may be replicated several times);
The users of the certificate-issuing authorities and the corresponding certificate repositories.

In this setting, the certificate-issuing authorities do not necessarily provide online certificate status information about the certificates they have issued to the users. Instead, they may operate off-line and update the certificate repositories only on a periodic basis. The certificate repositories, in turn, may operate on-line to be permanently available and accessible to the users. In general, it must be assumed that the certificate-issuing authorities are trustworthy and trusted, whereas the certificate repository and the users may not be. A user who contacts the certificate repository does not only want to retrieve a certificate, but may also want to get some kind of proof of validity for the certificates he or she retrieves.

From a theoretical point of view, there are several approaches to address certificate revocation:

To have certificates expire automatically after a certain amount of time and to require periodic renewals of certificates;
To list all nonrevoked certificates in an on-line certificate repository, and to accept only certificates that are found there;
To have all certificate-issuing authorities periodically issue lists that itemize all certificates that have been revoked and should no longer be used;
To provide an on-line certificate status checking mechanism that informs users whether a specific certificate has been revoked.

Note that the approaches are not mutually exclusive, but can be combined to develop more efficient or more effective certificate revocation schemes. Also note that all approaches have advantages and disadvantages. For example, the first approach has the advantage of not requiring explicit certificate revocation (because the certificates expire after a certain amount of time). The disadvantages of this approach are due to the fact that certificate expiration only provides a slow revocation mechanism, and that it depends on servers having accurate clocks. Someone who can trick a server into turning back its local clock can still use expired certificates (the security of the certificate revocation mechanism thus depends on the security of the timing service). Similarly, the second approach has the advantage that it is almost immediate, whereas the disadvantages are that the availability of authentication is only as good as the availability of the certificate repository, and that the security of the certificate revocation mechanism as a whole is only as good as the security of the certificate repository. Furthermore, users tend to cache certificates they have retrieved from the directory service for performance reasons, and the use of such a cache actually defeats the original purpose of the certificate repository (i.e., to provide timely status information). The third approach has the advantage that it is simple and straightforward, whereas the disadvantages are that the lists must be retrieved and taken into account and that the revocation of a certificate is enforced only after the publication and distribution of the next list. Finally, the fourth approach is immediate and provides a high level of security, but also reintroduces an on-line component.

For all practical purposes, the first and second approaches are the ones that are being followed for the revocation of attribute certificates, whereas the third and fourth approaches are the ones that are being followed for the revocation of public key certificates. For example, the ITU-T recommendation X.509 follows the third approach for the revocation of public key certificates.^[13] More specifically, it recommends that each CA periodically issue a certificate revocation list (CRL) that itemizes all certificates that have been revoked and should no longer be used. The CRLs can be pushed or pulled by the communicating peers:

If a CRL is pushed, the initiating peer (e.g., the client) provides the currently valid CRL to the responding peer (e.g., the server).
Contrary to that, if a CRL is pulled, the responding peer retrieves the CRL from the certificate-issuing authority.

Applications that use certificates can either use the push model, the pull model, or both. For example, IKE, SSL/TLS, and S/MIME are protocols that can push CRLs rather than requiring CRL retrieval from a repository.

In addition to the use of CRLs as proposed in the ITU-T recommendation X.509, the IETF PKIX WG is also following the fourth approach and has specified a standards track Online Certificate Status Protocol (OCSP) in RFC 2560 [26] and an experimental DVCS in RFC 3029 [30]. CRLs and OCSP are further addressed in the rest of this section. Afterward, we mention some alternative certificate revocation schemes that are primarily of theoretical interest.

19.5.1 CRLs

The classical and simplest solution to the certificate revocation problem is the use of CRLs. As mentioned, this approach is being followed in the ITU-T recommendation X.509 [8] and ISO/IEC 9594-8 [9]. In this approach, a CA periodically issues and digitally signs a message that lists all certificates that have been revoked and should no longer be used. This message is called a CRL and it is made available through the certificate repository. Users who want to make sure that a particular certificate has not been revoked (at least until the time the CRL was issued and digitally signed).

If a CRL is becoming too large, the use of delta CRLs may be appropriate. In short, a delta CRL lists all certificates that have been revoked and should no longer be used since the latest break point. Consequently, the set of all revoked certificates at a given point in time consists of all certificates listed in the most recent CRL plus all certificates listed in the delta CRLs that have been published meanwhile. Furthermore, other mechanisms are included in X.509 to allow a CA to split CRLs into multiple pieces (e.g., using CRL distribution points).

The major advantage of using CRLs (together with delta CRLs) is simplicity. A user of a certificate is required to retrieve the latest CRL from the appropriate CA or the repository and check whether the certificate has been revoked. Only if the certificate is not included in the CRL (and has not been revoked accordingly) is the user authorized to accept and use the certificate. Obviously, the consequence of this scheme is that the user has to periodically retrieve the latest CRLs from all the CAs he or she uses and accepts certificates from. This introduces some communication costs between the CA and the certificate repository, and high communication costs between the repository and the users (as CRLs may be very long). Another disadvantage is that a user does not receive succinct proof for the validity of a particular certificate.

Finally, note that a CRL is a negative statement. It is the digital equivalent of the little paper books of bad checks or bad credit cards that were distributed to cashiers in the 1970s and before. These have been replaced in the retail world by positive statements in the form of on-line validation of a single check, ATM card, or credit card. The digital equivalent to this on-line validation of a certificate is provided by the OCSP (or a similar protocol).

19.5.2 OCSP

Instead of, or as a supplement to, checking against periodically issued CRLs, it may be necessary to obtain timely information regarding a certificate's current status. Examples include high-value funds transfer or large stock trades. Consequently, the IETF PKIX WG has specified and standardized an OCSP in RFC 2560 [26]. In short, the OCSP enables a user to determine the status of an identified certificate. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response (whether the certificate in question is good, revoked, or is in an unknown state for the responder). A certificate-issuing authority can either respond to OCSP requests directly or have one (or several) delegated OCSP responder(s) providing OCSP responses to the requesting entities on its behalf.

As of this writing, the use of OCSP is not yet widely deployed on the Internet.^[14] Nevertheless, it is assumed and very likely that future CAs and certificate repositories will provide support for both certificate revocation mechanisms (CRLs and OCSP queries). It is also possible and very likely that the value of an electronic commerce transaction will finally determine whether a check in a CRL is sufficient enough, or whether an OCSP query must be invoked.

Finally, note that for financial transactions the merchant often needs to know not just whether a certificate is valid, but whether the charge to be made against the account represented by the certificate is acceptable (e.g., because of credit limit concerns). Thus, in such circumstances, timeliness of certificate status information may be irrelevant, because the merchant may need to contact the site responsible for the account (e.g., a bank for a bank credit-card charge) and that site would have very timely knowledge of certificate status information, which probably would not rely on CRLs and OCPS.

19.5.3 Alternative Schemes

We have seen that the use of CRLs introduces some communication costs between the CA and the certificate repository, and high communication costs between the repository and the users (as CRLs may be very long), and that by using CRLs, a user does not receive succinct proof for the validity of a particular certificate. We have also seen that protocols, such as the OCSP, can be used to address the second problem.

More recently, some alternative certificate revocation schemes have been proposed that try to address both problems mentioned. Chapter 8 of [2], for example, overviews and discusses Silvio Micali's certificate revocation system (CRS), Paul Kocher's certificate revocation trees (CRT), and a certificate revocation and update scheme proposed by Moni Naor and Kobbi Nissim. These discussions are not repeated in this book. The alternative certificate revocation schemes are interesting mainly from a theoretical point of view (as of this writing, they are not relevant for all practical purposes).

^[13]The X.509 CRL format is an ITU-T and ISO/IEC standard, first published in 1988 as version 1 (X.509v1 CRL). Similar to the ITU-T X.509 certificate format, the X.509v1 CRL was subsequently modified to allow for extension fields, resulting in X.509 version 2 CRL (X.509v2 CRL) format.

^[14]Note that browsers do not currently check the revocation status of any certificate at all. The only time a browser knows that a site certificate has been revoked is when it eventually expires. It is possible and very likely that this behavior will change in the future, and that certificate revocation checking will be adapted in one way or another. For example, Netscape has implemented a preliminary and incomplete version of OCSP.

Team-Fly