[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: Son-of-2459: More about delta-CRLs
Trevor,
It took me some time respond to take a look at the short thread of the three
messages along this topic. We basically agree that :
1° The current text always allows relying parties not supporting delta-CRLs
to have access to the same freshness of the information. This should be a
recommendation and not be a mandatory requirement.
2° some clarifications about the use of delta CRLs are currently missing in
the document.
Tim ? Any proposal ?
[do not miss the last comment at the end]
> 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.
Dave (David A.Copper) mentioned that the indicator is there, not in the CRL
but in the certificate.
"4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
The freshest CRL extension identifies how delta-CRL information is
obtained."
but it can also be in the CRL:
" 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)
The freshest CRL extension identifies how delta-CRL information for
this CRL is obtained."
So we have two indicators and you are both right. :-)
Denis.