Subject: RE: delta CRLs

From: Santosh Chokhani <[email-masked]>
Date: Thu, 10 May 2001 12:28:57 -0400

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 May 2001 18:52:49 +0200

Santosh,

Let me send you a reply just before leaving my office tonight.

> defined in CRLScope extension and/or the IDP extension.

I do not agree with you either. For a CRL to be a base CRL, there needs
first to be a delta CRL for it. In a closed environment, you could say that
this is sufficient because there is fixed point of contact to fetch delta
CRLs from and that this point is known using "out-of-bansds" means. We all
know what this means in terms of scalability. :-(

Until the CRL distribution point is used, noone knew where to fecth CRLs
from. The same will apply for delta CRLs. If we want to use delta CRLs in an
open environment, then we need the freshest CRL extension to be present.

There are other side advantages:

1° it allows to know when delta CRLs are supported, otherwise fetches in the
   repository would be done for nothing. So it saves time and/or increases
   performances.

2° it allows to make sure that a delta scheme is supported and by using
   additional rules, it allows to make sure to get the freshest delta CRL. 

I hope this clarifies the point.

Regards,

Denis