Subject: RE: delta CRLs

From: Santosh Chokhani <[email-masked]>
Date: Thu, 10 May 2001 18:43:46 -0400

Russ:

I agree with most of what you say except the following.

I think use of the "full" is dangerous.  These CRLs are "full" only with
respect to the scope as defined in the CRLScope and/or IDP extension.  This
is simply a nit.

You say "Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs."  Do you
mean a base could also be a delta as opposed to a full?  If so, that
distinction can be and will be made through the deltaCRLIndicator extension
without.  In any case, this point seems to be irrelevant.

You also say that "Every base CRL MUST be a full CRL, but not every full CRL
is a base CRL." 

While I agree with most of what you say, your distinction between base and
full (for scope) does not seem relevant or germane to me and seems to
confuse the issue.  But, I think (and hope) I understand this enough to know
that I do NOT disagree with the final conclusions.  Your rationale comes
across more convoluted and confusing than it needs to be due to this
needless distinction between base and full.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 2:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: delta CRLs

Denis:

Please excuse the half-done message from this morning.  My mailer and I had 
a disagreement...

Anyway, since I was not going to get the full message out before the end of 
the business day in France, I took the time to coordinate a response with 
Tim Polk and David Cooper.  This mail thread is quite long, so hopefully 
our coordination on the side will reduce the overall number of messages to 
the list and help to reach consensus faster.

Here goes ....

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

There is no requirement in X.509 to include any extension in a certificate 
or CRL advertising the availability of delta CRLs. PKIX makes the 
freshestCRL extension available for advertising the existence of delta 
CRLs, but again does not mandate its use. Furthermore, even if the 
freshestCRL extension is used, it may be placed in either the certificate 
or the full CRL. If the extension is placed in certificates, there is no 
need for it to be in the full CRL (but, it could be).

Finally, if delta CRLs are being issued, and are being advertised through 
the freshestCRL CRL extension, then the extension should be included in all 
full CRLs for that scope, not just the base CRLs. If a relying party 
obtains the most recently issued full CRL for a scope from a repository, 
and that full CRL is not a base CRL, how will the relying party know that 
delta CRLs are available?

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

The nextUpdate field in a full CRL (base or otherwise) should specify the 
time by which new revocation information will be available. So, if a new 
base CRL is issued once a day, but full CRLs are issued every hour, the 
nextUpdate field of each full CRL should one hour after that CRL's 
thisUpdate time.

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

We disagree.  If a full CRL and a delta CRL are issued at the same time for 
the same scope, then they ARE the same CRL and MUST have the same CRL
number.

 >If a full CRL is issued, its CRL
 >number bears no relationship with the previous base CRL, if any.

Again, we disagree. A sequence of CRLs for a given scope must contain a 
monotonically increasing sequence of CRL numbers. Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs. The CRL 
numbers for these full CRLs must be from one monotonically increasing
sequence.

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

Exactly. If a full CRL and the delta CRL are issued for the same scope at 
the same time, they are the same CRL. The CRL number unambiguously and 
uniquely refers to this ONE CRL.

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

If you agree that delta thisUpdate > base thisUpdate implies delta CRL 
number > base CRL, then you are acknowledging that the CRL numbers of the 
full CRLs and delta CRLs are not independent.

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

Our goal should be to allow delta CRL enabled clients to obtain accurate 
information in the most efficient manner possible. Forcing clients to 
periodically download full CRLs, when this is not necessary, is inefficient.

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

True. However, if one performs validations frequently enough, it is 
possible to obtain a single full CRL and then subsequently download only 
delta CRLs. We need to require that full CRL be issued periodically so that 
clients whose locally stored information is not sufficiently up-to-date to 
apply the delta CRLs being issued can obtain the full CRLs that they need, 
but we should not require clients to download full CRLs when it is not 
necessary for them to do so.

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

Yes, but the goal should be to minimize the fetching of full 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.

You are mixing apples and oranges. Obviously the scheme of keeping 
up-to-date by obtaining a base from 1990 and then only downloading deltas 
will only work so long as deltas continue to be issued. If the CRL issuer 
ceases to issue deltas, then the relying parties will have to revert to 
downloading full CRLs.

 >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: ???

The nextUpdate field in a base CRL states when the next full CRL will be 
available. This is important for supporting clients that do not handle 
delta CRLs. The nextUpdate field in a delta CRL states when the next CRL 
(either a delta CRL or a full CRL) will be available. As a general rule, if 
the CA is continuing to issue deltas, the nextUpdate in the delta will be 
the time by which the next delta will be available. If this is the last 
delta that the CA is going to issue, then the nextUpdate in the delta will 
be the time by which the next full CRL will be available. ("Available" 
SHOULD reflect distribution delays associated with the repository 
architecture.)

 >2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
 >
 >Denis: No.
 >Tim/David/Russ : ???

No. A CA never is required to issue deltas. However, it would be helpful to 
delta CRL enabled clients to allow them to construct the full CRL.

If the full CRL contains a freshestCRL extension, then it is a very good 
idea to generate a delta CRL at the same time. In this way, any client will 
be able to find a current delta CRL.

 >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 : ???

No. HOWEVER, the CA must issue a new full CRL by the nextUpdate in the 
previously issued full CRL (whether that full CRL is a base CRL or not). 
There is no requirement that the next full CRL be a base CRL. (The CA could 
quit issuing deltas, etc. etc.)

Every base CRL MUST be a full CRL, but not every full CRL is a base CRL. 
But, a CA could make every full CRL a base CRL if they wanted to.

 >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 : ???

No. HOWEVER, in practice we belive that CAs will do so. The delta CRL needs 
to exist so that clients can follow the freshest CRL extension (either in a 
certificate or a base CRL). The delta CRL that is issued at the same time 
SHOULD point to a previously issued full CRL (which will then, by 
definition be a base CRL) whenever possible. There is no information to add 
to the new base CRL! By providing the delta as an update to a previous base 
CRL, clients can download the delta CRL to construct the new base CRL.

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

PKIX is a profile of X.509.  PKIX may impose additional requirements beyond 
those in X.509 or may exclude features that are optional in X.509, but 
otherwise PKIX must be consistent with X.509. In that context, references 
to X.509 are appropriate.

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

No. The relying party needs a full CRL (either one that has been downloaded 
from a repository or one that has been locally generated) against which the 
delta CRL of interest may be applied. There is no requirement that the full 
CRL be a base CRL.

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

It may construct an updated CRL by combining the delta CRL with any full 
CRL whose CRL number is greater than or equal to the CRL number of the 
referenced base.  By saying "equal" instead of "greater than or equal" we 
would be hiding useful information from implementors. We should not be 
hiding useful information.

 >    Applications that support
 >    delta CRLs MUST ensure that time T falls between thisUpdate and
 >    nextUpdate for both the base CRL and the delta CRL.

As stated above, the nextUpdate field in a base CRL specifies the time by 
which new revocation information will be available through full CRLs. A 
delta CRL may be applied to a base CRL as long as the CRL number in the 
base CRL is greater than or equal to the CRL number of the base CRL 
referenced by the delta CRL. The nextUpdate time of the base CRL is
irrelevant.

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

Same problem as above.  Need to say "greater than or equal to".

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

This is an unnecessary statement. A delta CRL must include a BaseCRLNumber. 
The CRL specified by that BaseCRLNumber is by definition a base CRL.  Of 
course, the referenced base CRL MUST be a full CRL.

 >    i.e. a full
 >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
 >    distribution point).

While it might be a good idea to mandate the inclusion of the frestestCRL 
extension in full CRLs that are issued for scopes in which delta CRLs are 
also being issued, there is currently no such requirement in the draft PKIX 
profile.

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

This sentence has several problems:

1) The nextUpdate time of a base CRL is the time when the next full CRL 
will be available, which may precede the time that the next base CRL will 
be issued.

2) There is no requirement that a delta CRL use the most recently issued 
base CRL as its base.  I suppose that we could add this requirement for the 
PKIX profile, but why?  Does it really simplify the client?  Or, does it 
just make it a wee bit harder to make a conforming CA that supports delta
CRLs?

3) If the thisUpdate time of one delta CRL must equal the nextUpdate time 
of the previously issued delta CRL, then no time can be allotted to account 
for propagation delays between when a delta-CRL is issued and when it is 
available in repositories for relying parties to obtain. Thus, there would 
be gaps between when the nextUpdate time of one delta-CRL was reached and 
when the next delta-CRL was available.

4) There is nothing in either X.509 or the PKIX profile that prevents a CA 
from issuing an unscheduled (or "emergency") delta CRL. And, there should 
not be!  Many CAs intend to issue a new CRL (delta or otherwise) 
immediately upon the revocation of a certificate due to key compromise. 
When such an "emergency" delta CRL is issued, there will be two delta CRLs 
for which T falls between thisUpdate and nextUpdate. While it is true that 
there is no guarantee that relying parties will obtain the fresher of these 
two delta CRLs, that is no reason to prevent the CA from issuing the 
"emergency" delta.  Some clients will obtain the emergency 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.)

No. In order to base delta CRL processing on time, the baseUpdateTime 
extension must be present in the delta CRL. Furthermore, the presence of 
this extension would not complicate the problem. baseUpdateTime is a 
non-critical extension that merely provides useful information. If you 
don't think that the information provided by baseUpdateTime is useful, 
ignore it. Since the extension is non-critical and can be ignored, its 
presence can not complicate the problem.

At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote:
>Denis:
>
>>There is difference between a base CRL and a full CRL
>
>You are quite right.  I, for one, will try to be more careful about the 
>use of them.
>
>>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.
>
>I disagree.  A full CRL (that may be a base CRL for subsequent delta CRLs) 
>and a delta CRL issued at the same time as that full CRL may actually 
>represent the same revocation information.  In this case, they are the 
>same CRL, and they should have the same number.  There have been several 
>tables posted that illustrate this numbering scheme, and I do not see any 
>text in X.509-200 that indicates this scheme is
[snip - truncate - the message is too long anyway]