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

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 5 Mar 2001 13:06:38 -0800

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

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 05 Mar 2001 16:42:33 -0500

Trevor,

According to X.509, the freshestCRL extension may only be used in certificates:

                 The freshest CRL extension shall be used only as a certificate extension
                 and may be used in certificates issued to authorities as well as certificates
                 issued to users. This field identifies the CRL to which a certificate user should
                 refer to obtain the freshest revocation information (e.g.: latest dCRL).

X.509 defines a CRL extension, deltaInfo, that could be included in base CRLs, but this extension has not been included in the PKIX profile. The deltaInfo extension is described as follows:

                 This CRL extension is for use in CRLs that are not dCRLs and is used to
                 indicate to relying parties that dCRLs are also available for the CRL containing
                 this extension. The extension provides the location at which the related dCRLs
                 can be found and optionally the time at which the next dCRL is to be issued. 

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 08 Mar 2001 13:25:10 +0100

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]

> section 5.2.4  Delta CRL Indicator:
 
> that is complete for the given scope."
 
> for the SHOULD.

> think that this should be a recommendation and not be a mandatory 
> requirement.
 
> ...." Notice the "s" at the end of delta-CRLs.

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

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