Subject: RE: delta CRLs

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

Denis:

Since you did not ask me the questions, I will NOT answer them.

In general, my reading of the standard is that a base CRL need not have
freshest CRL extension in it.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 4: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