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

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Dennis,

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.

TF> I agree, we don't have a clause requiring the publication of a full
base when using OCSP. Non-delta aware client are not impacted since they
don't know about delta publication. It is therefore impossible to
achieve all clients having the same revocation information.

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. 

TF> There are two cases to consider here. Where the freshest CRL
indicator is in the certificate or the CRL. In the former case, it may
be necessary to merge multiple delta CRLs since there is no guarantee of
a 1-2-1 relationship between base and delta. You could have delta CRLs
partitioned by reason coded, and a base CRL for all reasons. In the
later case where the freshet CRL indicator in in the CRL, there is an
implicit 1-2-1 relationship between base and delta. A delta aware client
in this case only has to search for the latest delta CRL. Each delta has
a this update time, so a client can establish which is the latest.
Merging the latest delta CRL with the appropriate base provided the
answer.

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 

TF> given the range of possibilities introduced by having freshest CRL
in either the certificate or CRL, I would prefer some recommendations on
what should be done. Having no guidance opens up a large number of
permutations, and we want to progress this to draft standard, we need to
refine our scope to what is reasonable, not what is possible.

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

TF> Having a freshest CRL extension in a CRL provides such an indicator.

Denis

Trevor