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

["David A. Cooper" <david.cooper@xxxxxxxx>]

At 06:12 PM 3/5/01 +0100, Denis Pinkas wrote:
>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. 

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.

>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 ?

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.

>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. 

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.

>Ideally, but not necessarily, the base CRL SHOULD include an indicator
>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