Subject: RE: delta CRLs

From: "Housley, Russ" <[email-masked]>
Date: Thu, 10 May 2001 14:42:50 -0400

Santosh:

Any CRL that does not include the deltaCRLIndicator extension is a full 
CRL.  I some delta CRL references it, then that full CRL is also a base CRL.

Russ

At 12:28 PM 5/10/2001 -0400, Santosh Chokhani wrote:

>Denis:
>
>I do not agree with you.  Any CRL that is not a delta CRL (i.e., 
>deltaCRLIndicator extension is absent), is a base CRL for some scope as 
>defined in CRLScope extension and/or the IDP extension.
>
>-----Original Message-----
>From: Denis Pinkas 
>[<mailto:[email-masked]>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]>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