x.509 CRLs: next update?

Question

An X.509 certificate revocation list contains a field specifying when the next such list is expected to be issued. I'm trying to figure out the importance of this field...I know that sometimes certificates are placed on a "do not use" list, and this needs to be updated constantly. But I also feel like the CRL update on a regular basis, so what is the point of having this field anyways? Why not just use a fixed schedule?

Answer 1

There are two distinct semantics that the nextUpdate field is used to convey:

1. the date at which a newer CRL should be available, thus making it worth a new download (similarly, before the date given in the nextUpdate field, a cached CRL should be considered to be the newest);
2. the date after which a given CRL should be considered obsolete.

It is expected that CRL overlap, so that transitions are smooth and network traffic spread throughout the day. Typically, a CA would produce a new CRL every hour (so that fresh information is available) but would "allow" a given CRL to be valid for one day (24 hours). Since a CRL can be somewhat large, downloading it is expensive, thus implementations would prefer not to do it too often if it has no practical use. But since each CA has its own policy, a generic certificate validator cannot know a priori what kind of schedule a given CA uses; it must learn it through the data in the certificates and CRL.

The first meaning is what X.509 mandates. However, everybody uses it with the second meaning. In effect, implementations of X.509 (e.g. in Web browsers, when they validate the certificate of a Web server) handle nextUpdate as if it was an endOfValidity date. Lately, Microsoft has defined a new extension called nextPublish which assumes the first meaning (the extension can be seen in annex A.1 of this draft, in an OCSP context). This extension (which seems to be, so far, private to Microsoft, not standard) somehow acknowledges that the common practice deviates from theory with regards to the meaning of nextUpdate.

Answer 2

It's used for a number of reasons:

• It allows more optimal fetching of CRLs from a pull-based service such as HTTP, so that polling times can be configured on a per-response basis.
• It allows for selection of diff-based vs. complete CRL downloads, since a CRL appearing on or after the next update time is assumed to be a regular update, whereas an update appearing before the next update is assumed to be security patch, so the entire CRL is replaced in the local cache.
• It allows for CRLs to be trimmed after the certificate expires, without having to push a new CRL. This is done by automatically removing the CRL entry on the first regular update (i.e. on the next update time) after the certificate expires.

See section 5.1.2.5 of RFC3280 for more information.