Subject: RE: delta CRLs

From: Sharon Boeyen <[email-masked]>
Date: Thu, 10 May 2001 13:04:19 -0400

A full CRL is a CRL that is complete for a given scope. A base CRL is a CRL
that is the foundation for a delta CRL. I think the reason the wording in 
the definitions doesn't tie them together any more than that is because of 
a nuance where a delta CRL may reference a base CRL that was never actually 
issued as a full CRL. This is the case where the delta provides updates 
from a certain point in time, but it may be the case, in some environments, 
that full CRLs are never issued and the relying parties always build their 
local full CRLs from deltas. I realize that is not the case PKIX describes, 
but that's at least one reason the 509 definitions are the way they are (and
yes there are definitions in clause 3 for both base CRL and full CRL).
So, the term base is only relevant when used in the context of a delta that
points to it. 

As for freshestRevocationInfo, that is not mandated by 509, in the same 
way that other extensions are not. It is one way to indicate where to 
go to find deltas but there can be others (e.g. perhaps the relying 
parties know that there is one indirect CRL that provides delta info
for all CAs inside an organization - perhaps this info is listed on 
their web site). If PKIX wanted to mandate it they could, but 509 
certainly does not.

Cheers,
Sharon

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, May 10, 2001 12:30 PM
> To: Carlin Covey; Sharon Boeyen
> Cc: [email-masked]
> Subject: Re: delta CRLs
> 
> 
> Carlin and Sharon (at the same time),
> 
> > Denis,
>  
> > Now I'm confused again (or still).  
> 
> :-)
> 
> > I agree that there is a difference
> > between a base CRL and a full CRL.  However, my 
> understanding was that a CRL
> > is a "base CRL" with respect to some delta CRL only by 
> virtue of having been
> > so identified in that delta CRL. 
> 
> I believe that a base CRL must include the Freshest CRL 
> extension (a.k.a.
> Delta CRL Distribution Point) defined in section 4.2.1.16. It 
> indicates both
> that the service exists and where to fetch the information. It is a
> non-critical extension so that a base CRL may also be used as 
> a full CL for
> relying parties not supporting delta CRLs.
> 
> > According to the PKIX profile, this base CRL must be a full CRL 
> > (complete for the intended scope).  
> > I believe that X.509 does not require that a base CRL be a full CRL.
> 
> You just say above: "According to the PKIX profile, this base 
> CRL must be a
> full CRL (complete for the intended scope". So do you mean 
> that X.509 and
> PKIX are taking different approaches ?
> 
> Regards,
> 
> Denis
> 
> > Regards,
> > 
> > Carlin
> > 
> > ____________________________
> > 
> > -  Carlin Covey
> >    Cylink Corporation
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, May 10, 2001 1:19 AM
> > Cc: [email-masked]
> > Subject: Re: delta CRLs
> > 
> > Tim, David, Russ, Santosh, Carlin, and many others ...
> > 
> > There is difference between a base CRL and a full CRL : a 
> base CRL MUST
> > include a freshestCRL extension (a.k.a. a Delta CRL 
> distribution point),
> > whereas a full CRL may not include that extension. In other 
> words, a base
> > CRL is a also a full CRL, but a full CRL is not necessarily 
> a base CRL.
> > 
> > At any time a CA may issue a full CRL, whether or not a 
> base CRL has already
> > been issued. This additional CRL SHOULD have nextUpdate equal to the
> > nextUpdate of the last issued full CRL. However, there is 
> no guarantee that
> > this additional CRL will ever be seen by the relying party 
> (because there
> > will be two CRLs matching the thisUpdate and nextUpdate 
> rule and if one is
> > deleted, this is not seen by a relying party).
> > 
> > Due to the fact that CRLs numbers are strictly increasing, 
> two CRLs whether
> > they are a base CRL or delta CRL, CANNOT have the same CRL 
> number. So a
> > delta CRL and a full CRL that cover the same scope and are 
> issued at the
> > same time CANNOT have the same number. If a full CRL is 
> issued, its CRL
> > number bears no relationship with the previous base CRL, if 
> any. The only
> > relationship between the numbers is defined by the rule 
> that CRLs numbers
> > are strictly increasing. As Santosh said : "the CRL number is unique
> > whether it is a base or a delta ".
> > 
> > This is fairly important to be able to unambiguously (and 
> thus uniquely)
> > refer to a CRL by only providing its CRL number.
> > 
> > Besides the fact that a CRL issued later MUST have a higher 
> CRL number, full
> > CRLs and delta CRLs have independent numbering rules. As 
> noticed by Santosh,
> > " if the delta thisUpdate > base thisUpdate, delta CRL 
> number > base CRL
> > number (for the same or no stream identifier).
> > 
> > As Santosh said : "a check based on thisUpdate is more general and
> > preferred [to the use of CRL numbers]. "
> > 
> > Related to the three rules mentioned by Russ :
> > 
> > 1) the first rule is not understandable to me.
> > 2) the second rule does not say anything more than the 
> basic rule valid
> >    for any CRL (i.e. a CRL issued later MUST have a higher 
> CRL number).
> > 3) we will debate the hold condition, once we will have 
> sorted the main
> >    issue.
> > 
> > Russ said : "If separate number sequence is used, then you 
> will have to
> > periodically fetch base CRLs ". This is true.
> > 
> > Tim said that he would *not* like to be forced to download 
> new base CRLs.
> > This is the core of the "dispute".
> > 
> > >From the definition of what a delta CRL is, it is *not* possible to
> > get rid of the fetching of base CRLs. Unless we add a new 
> sentence to
> > expand/change that definition, base CRL fetching will 
> remain mandatory.
> > 
> > Remember that the goal of delta CRLs is to provide the 
> freshest information,
> > and to my knowledge the goal was not to get rid of the 
> fetching of base CRLs
> > (which may less frequent due to the support of delta CRLs).
> > 
> > If I understand correctly, Tim/David/Russ would like to 
> *always* achieve the
> > following property : it is possible to reconstruct the 
> current CRL by using
> > a base CRL from, e.g. 1990, i.e. by capturing every delta 
> CRL that has been
> > issued at the same time a base CRL was issued and which 
> contains updates
> > made to the *previous* base.
> > 
> > By this way the fetching of base CRLs could be avoided. 
> However, note that
> > it is perfectly " legal " to stop issuing base and delta 
> CRLs during some
> > period of time and to issue full CRLs instead (see the 
> difference between
> > "full" and "base" at the top of this e-mail). In other 
> words there is no
> > need to issue a new base CRL at the end of the validity 
> period of the
> > previous base CRL. Doing this would mandate to prescribe 
> issuing rules
> > for CAs that we have not prescripted.
> > 
> > I will now raise a series of questions, for which I believe we have
> > different answers. Tim/David/Russ do not hesitate to correct
> > if my guess is wrong. ;-)
> > 
> > Common point:
> > 
> > 1) What will be the value of the nextUpdate field from the 
> last issued delta
> > CRL for a given base CRL ?
> > 
> > Denis: the nextUpdate field from the last issued delta CRL 
> MUST be equal to
> > the value of nextUpdate from the base CRL.
> > 
> > Tim/David/Russ: ???
> > 
> > 2) Does a CA needs to issue a delta CRL at the time a full 
> CRL is issued ?
> > 
> > Denis: No.
> > Tim/David/Russ : ???
> > 
> > 3) Does a CA needs to issue a new base CRL at the end of 
> the validity of a
> > current base CRL ?
> > 
> > Denis: No.
> > Tim/David/Russ : ???
> > 
> > 4) Does a CA needs to issue a delta CRL at the same time a 
> new base is
> > issued ?
> > 
> > Denis: Yes. The delta CRL refers to the *new* base.
> > Tim/David/Russ : Yes. The delta CRL refers to the 
> *previous* base. [Note
> > that there can be no previous at all, or the "previous" may 
> even be three
> > months old].
> > 
> > The last point highlights the most noticeable difference. 
> Other differences
> > appears when considering the guaranty to get the freshest 
> information :
> > using the traditional scheme and the thisUpdate and 
> nextUpdate fields the
> > guaranty to get the freshest information is obtained, but 
> cannot be obtained
> > using the other scheme. :-(
> > 
> > Several people are referring to the X.509 document for 
> arguments to support
> > that discussion. However, it is important to remember that 
> we are defining
> > PKIX, not X.509, so we DO NOT need to copy and paste 
> everything from X.509,
> > but only what we believe is relevant.
> > 
> > We first need to clearly define the processing rules 
> applicable to the
> > relying parties. These rules will certainly contain 
> SHALL/MUST statements,
> > but may also include some MAY statements which may even be 
> conditional to
> > what the CA is doing. (I let Tim/David or Russ provide the 
> MAY statement).
> > 
> > Here is a proposal for the MUST statement, based on the 
> previous text I
> > produced:
> > 
> >    An application that is wishing to take advantage of delta CRLs
> >    for a given scope, MUST first find a base CRL for that scope,
> >    i.e. a full CRL that that contains a freshestCRL extension
> >    (a.k.a. a Delta CRL distribution point). It may then construct
> >    an updated CRL for that base, for a specific time T, by combining
> >    it with a delta CRL which contains a delta CRL indicator 
> extension
> >    with the same CRL number as the base CRL. Applications 
> that support
> >    delta CRLs MUST ensure that time T falls between thisUpdate and
> >    nextUpdate for both the base CRL and the delta CRL.
> > 
> >    Note: An application could also reconstruct an updated CRL, for
> >    a specific time T, by using a previously locally 
> reconstructed CRL
> >    based on the current base CRL, and combining it with a 
> delta CRL which
> >    contains a delta CRL indicator extension with the same 
> CRL number as
> >    the base CRL.
> > 
> > We also need to clearly separate the issuing rules 
> applicable for the CAs.
> > These rules will certainly contain SHALL statements, but 
> could also include
> > some MAY statements. (I let Tim/David or Russ provide the 
> MAY statement).
> > 
> > Here is a proposal for the MUST statement, based on the 
> previous text I
> > produced:
> > 
> >    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
> >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
> >    distribution point). For any time T until the nextUpdate time
> >    indicated in a base CRL, the CA MUST provide one and only one
> >    delta CRL that refers to that base CRL and for which time T
> >    falls between thisUpdate and nextUpdate from the delta CRL.
> > 
> > In his e-mail from Wednesday, May 9, David said that 
> delta-CRL processing
> > rules could be base on time instead of CRL numbers. This is 
> a point of which
> > I strongly agree. Let us do it!
> > 
> > (However, there is no need to add to PKIX, as he suggested, 
> the support of
> > the baseUpdateTime extension from X.509 which would even 
> more complicate the
> > problem.)
> > 
> > Regards,
> > 
> > Denis
>