Subject: WG Last Call: Son-of-2459: More about delta-CRLs

From: Denis Pinkas <[email-masked]>
Date: Mon, 05 Mar 2001 18:12:09 +0100

We already discussed on the mailing list the sentence contained in section
5.2.4  Delta CRL Indicator:

" When a conforming CA issues a delta CRL, the CA MUST also issue a CRL that
is complete for the given scope."

However I noticed that in the new text, MUST has not been changed into
SHOULD. There has been no definitive answer but many people were arguing for
the SHOULD.

Indeed, this text always allows relying parties not supporting delta-CRLs to
have access to the same freshness of the information. I would still think
that this should be a recommendation and not be a mandatory requirement.

However, we did not discussed that much the implications of another
sentence: "A CRL user constructing a locally held CRL from delta-CRLs ...."
Notice the "s" at the end of delta-CRLs. 

How is it possible to issue more than one delta-CRL referring to a given
basic CRL and know that it is the freshest ? The text does not say anything.
Some guidance should be given. Is the following an adequate rough
explanation ?

Every delta-CRL SHOULD indicate the next issuing date of the next delta-CRL
[we have this feature]. If the next issuing date is missing, then it means
that no further delta-CRL will be issued and that a new base CRL is now also
available. The delta-CRL obtained is the freshest, when the date for
checking is between the issuing date and the next issuing date of that
delta-CRL. 

Ideally, but not necessarily, the base CRL SHOULD include an indicator
saying that a delta mechanism is supported [we do not have that indicator].

Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 05 Mar 2001 14:06:09 -0500

>Notice the "s" at the end of delta-CRLs. 

I think the above sentence is correct. Imagine, for example, that a user has in his local cache CRL number 3. He downloads a delta-CRL with cRLNumber 7 and BaseCRLNumber 5. Perhaps the simplest solution at this point would be for the user to download a new full CRL with a cRLNumber of 5 or greater. However, the user could instead attempt to get a second delta-CRL that has a cRLNumber of 5 or greater and a BaseCRLNumber or 3 or less. The user would then apply the two delta-CRLs in sequence to the locally held CRL number 3 in order to locally construct the contents of CRL number 7.

>Some guidance should be given. Is the following an adequate rough

How is this any different from full CRLs? One can always compare two CRLs using the cRLNumber and/or thisUpdate time to determine which is fresher, but even if CRLs include a nextUpdate time, there is no way to know for sure that no "emergency" CRLs have been issued.

>checking is between the issuing date and the next issuing date of that

The profile already requires every CRL to include the nextUpdate field and states that "[t]he behavior of clients processing CRLs which omit nextUpdate is not specified by this profile". I see no reason to treat delta-CRLs differently from other types of CRLs in this respect and so I think it would be a bad idea to attach some special meaning to delta-CRLs that have no nextUpdate field.

Similarly, the profile states that the nextUpdate field "indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date." There is no reason to apply different semantics to the nextUpdate field in delta-CRLs vs. non-deltas.

>saying that a delta mechanism is supported [we do not have that indicator].

We already have the FreshestCRL certificate extension which "identifies how delta-CRL information is obtained". Is there some compelling reason to have a CRL extension as well?

Dave