Certificate distribution and revocation

13.6.3 Certificate distribution and revocation

A certificate directory (cf. §13.2.4) is a database which implements a pull model – users extract (pull) certificates from the database as necessary. A different model of certificate distribution, the push model, involves certificates being sent out (pushed) to all users upon certificate creation or periodically; this may be suitable for closed systems. Alternatively, individual users may provide their certificates to others when specifically needed, e.g., for signature verification. In certificate-based systems with certificate revocation lists (CRLs – see below), a method for distribution of CRLs as well as certificates is required.

A certificate directory is usually viewed as an unsecured third party. While access con- trol to the directory in the form of write and delete protection is necessary to allow mainte- nance and update without denial of service, certificates themselves are individually secured by the signatures thereon, and need not be transferred over secured channels. An exception is on-line certificates, which are created by a certification authority in real-time on request and have no on-going lifetime, or are distributed by a trusted party which guarantees they have not been revoked.

Certificate or CRL caching may be used, whereby frequently referenced items are sav-

ed in short-term local storage to avoid the cost of repeated retrievals. Cached CRLs must

be refreshed sufficiently often to ensure recent revocations are known.

Certificate revocation and CRLs

Upon compromise of a secret key, damage may be minimized by preventing subsequent use of or trust in the associated keying material. (Note the implications differ between sig- nature and encryption keys.) Here compromise includes any situation whereby an adver- sary gains knowledge of secret data. If public keys must be obtained in real-time from a trusted on-line server, the keys in question may be immediately removed or replaced. The situation involving certificates is more difficult, as all distributed copies must be effectively retracted. While (suspected or actual) key compromise may be rare, there may be other rea- sons a CA will prematurely dissolve its binding of a public key to a user name (i.e., revoke the certificate). Reasons for early termination of keying material include the associated en-

§13.7 Key life cycle issues 577

tity leaving or changing its role within an organization, or ceasing to require authorization as a user. Techniques for addressing the problem of revoked keys include:

1. expiration dates within certificates. Expiration dates limit exposure following com- promise. The extreme case of short validity periods resembles on-line certificates which expire essentially immediately. Short-term certificates without CRLs may be compared to long-term certificates with frequently updated CRLs.

2. manual notification. All system users are informed of the revoked key by out-of-band means or special channels. This may be feasible in small or closed systems.

3. public file of revoked keys. A public file is maintained identifying revoked keys, to

be checked by all users before key use. (The authenticity of data extracted from the file may be provided by similar techniques as for public keys – see §13.4.)

4. certificate revocation lists (CRLs). A CRL is one method of managing a public file of revoked keys (see below).

5. revocation certificates. An alternative to CRLs, these may be viewed as public-key certificates containing a revocation flag and a time of revocation, serving to cancel the corresponding certificate. The original certificate may be removed from the cer- tificate directory and replaced by the revocation certificate.

A CRL is a signed list of entries corresponding to revoked public keys, with each en- try indicating the serial number of the associated certificate, the time the revocation was first made, and possibly other information such as the revocation reason. The list signature, guaranteeing its authenticity, is generated by the CA which originally issued the certificates; the CRL typically includes this name also. Inclusion of a date on the overall CRL provides an indication of its freshness. If CRLs are distributed using a pull model (e.g., via a public database), they should be issued at regular intervals (or intervals as advertised within the CRL itself) even if there are no changes, to prevent new CRLs being maliciously replaced by old CRLs.

Revoked cross-certificates may be specified on separate authority revocation lists (ARLs), analogous to CRLs (which are then restricted to revoked end-user certificates).

13.44 Note (CRL segmenting) For reasons of operational efficiency when large CRLs may arise, an option is to distribute CRLs in pieces. One technique is to use delta-CRLs: upon each CRL update, only new entries which have been revoked since the last issued CRL are in- cluded. This requires end-users maintain (and update) secured, local images of the current CRL. A second technique is to partition a CRL into segments based on revocation reason.

A third is to segment a CRL by pre-assigning each certificate (upon creation) to a specified sub-list, with a limit n max on the number of certificates pre-assigned to any segment and new segments created as required. In all cases, for each certificate, available information must indicate which CRL segment must be consulted.