[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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