Subject: RE: delta CRLs

From: Olle Larsson <[email-masked]>
Date: Thu, 10 May 2001 09:12:50 +0200

Just want to point out that it DOES matter if the delta and the full CRL
have the same number or not, when issued at the same time and reflecting the
same set of revocation information.
 
Consider a client that tries to construct the local 'virtual' base CRL that
Peter Sylvester mentioned. That virtual base CRL will then have a crlNumber
= n = that of the dCRL used to update the local repository.
 
A while later, another dCRL is fetched. If the referred base CRL number m >
n, we are in trouble. 
 
In other words, a full CRL must always have a CRL number >= the CRL number
of the delta CRL that is issued at the same time and reflecting the same set
of revocation information.
 
<academical> The thisUpdate field is of no use, as computers are fast these
days and you cannot know for a fact that another full CRL m hasn't been
issued in the very same second interval as CRL n, possibly containing more
revocation information that will be missed in the virtual base CRL.
</academical>
 
Considering this, I would second Santosh's revised wording as well.
 
/Olle
 
-----Original Message-----
From: Carlin Covey [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 9:23 PM
To: [email-masked]
Subject: RE: delta CRLs

Having heard several persons speak for assigning the same CRL number to
simultaneously-issued delta-CRLs and full CRLs, and no one speak against, I
find myself convinced that they should be assigned the same CRL number.
Thanks for the convincing arguments.
 
P.S.  I still like Santosh's revised wording:
 
----------------------
 
        Thus, if two CRLs (in the same stream identifier or when stream
identifier is absent), have numbers n and m, the following shall be true
(assuming no wrapping) 

        n = m if and only if thisUpdate of n = thisUpdate of m 

        n > m if and only if thisUpdate of n > thisUpdate of m 

        n < m if and only if thisUpdate of n < thisUpdate of m 

--------------------

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Carlin Covey [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 10:35 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: delta CRLs

Santosh,
 
I don't see that it matters whether the delta-CRL or the full CRL is
assigned the earlier number.  But I'm not hard over about assigning them
different numbers.  I'm still willing to be convinced that it is bad that
they have different numbers, or good that they have the same number.
Earlier today Stephen Henson presented one argument for numbering them the
same.  Perhaps that is a compelling reason.
 
Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 10:13 AM
To: Carlin Covey; Santosh Chokhani
Cc: [email-masked]
Subject: RE: delta CRLs

Are you suggesting that when they are issued at the same time, they should
still have a different CRL number?
 
Which one should have the number n and which one n+1?
 
-----Original Message-----
From: Carlin Covey [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 1:16 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: delta CRLs

Santosh,
 
If simultaneously-issued delta-CRLs and full CRLs are to be numbered the
same, I think your wording is a significant improvement over the current
wording.  However, I'm still undecided whether they should be numbered the
same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and
constructed CRLs) could be matched via the thisUpdate field without the
necessity of violating the strictly increasing provision for CRL numbers.  A
unique reference for each CRL would be useful for evidentiary purposes, and
for historical validation.  Rendering a CRL identifier unique already
requires the issuer ID, the set of reason codes, the set of certificate
types, and either the CRL number or the thisUpdate value.  I wonder if it is
necessary to add the full vs. delta status as well.
 
- Carlin
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 9:28 AM
To: Carlin Covey; [email-masked]; David A. Cooper; [email-masked];
Santosh Chokhani
Cc: [email-masked]
Subject: RE: delta CRLs

I am simply suggesting that the numbers be strictly increasing, but if a
base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

 n = m if and only if thisUpdate of n = thisUpdate of m 

 n > m if and only if thisUpdate of n > thisUpdate of m 

 n < m if and only if thisUpdate of n < thisUpdate of m 

-----Original Message----- 
From: Carlin Covey [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, May 09, 2001 11:28 AM 
To: [email-masked]; David A. Cooper; [email-masked]; 
[email-masked] 
Cc: [email-masked] 
Subject: RE: delta CRLs 

David, Stephen, Ambarish, and Santosh, 

Some of us are in the business for the looooong haul.  ;>) 

Actually, I wasn't concerned about the CRL number wrapping, but that 
possibility was advanced a few days ago as an argument against the use of 
the "strictly increasing" wording.  Another email commented that PKIX did 
not permit the number to wrap, although X.509 might.  The only evidence I 
could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As 
various people have pointed out, one could be drumming one's fingers for 
quite a while........ 

My real point was that the "monotonically increasing" wording permits the 
CRL number to stay the same, while "strictly increasing" forces the numbers 
to be unique (issues of wrapping aside in both cases).  Stephen Henson just 
pointed out a reason why one might want the CRL number to stay the same when

issuing a delta CRL at the same time as a full CRL.  I am not arguing either

for or against that case, but it seems desirable to force the CRL numbers to

be unique in most cases.  (Unless, the CRLs are distinguished based upon 
thisUpdate, as Santosh has suggested.) 

Regards, 

Carlin 

____________________________ 

-  Carlin Covey 
   Cylink Corporation 

-----Original Message----- 
From: David A. Cooper [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, May 09, 2001 6:03 AM 
To: [email-masked] ' 
Subject: RE: delta CRLs 

 From a practical point of view, I don't think that we should need to worry 
about CRL numbers wrapping.  According to my calculations, if one assigns 
cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one could 
issue a new CRL every second for 68 years before the cRLNumber would require

more than 4 bytes (32 bits) to encode.  On the other hand, if you're willing

to issue a new CRL only once a minute, it would take 4083 years before the 
cRLNumber would require more than 4 bytes to encode. 

BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent use 
of negative numbers. While there may, in theory be a limit to the size of an

integer that may be encoded, for all practical purposes, one can encode any 
integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and DER",

a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus, 
MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any 
number we would ever need. 

Dave 

At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote: 
> 
>I always thought MAX for ASN.1 INTEGERs was something I would never 
>need to worry about. 
> 
>Looks like I was wrong :-) 
> 
>By the way, what is MAX? I know that we can represent numbers with 
>over 2048 bits... 
> 
>A 
> 
>-----Original Message----- 
>From: Carlin Covey 
>To: Housley, Russ; Santosh Chokhani 
>Cc: [email-masked] 
>Sent: 5/8/01 5:53 PM 
>Subject: RE: delta CRLs 
> 
>Russ, 
> 
>A week or two ago we arrived at a consensus to remove the requirement 
>that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the 
>CA chooses to issue them simultaneously, why would they need to be numbered

>the same?  If this requirement were lifted, it seems like requiring the CRL

>number to be "strictly increasing" in a sequence would be preferable to 
>"monotonically increasing".  "Monotonically increasing" allows the 
possibility 
>that the CRL number never changes, which seems undesirable.  I realize 
>that in either case the CRL number might wrap around at some point in the 
future. 
>That is inevitable, given that that CRL number is defined as INTEGER 
(0..MAX). 
>What else can a CA do when CRL number reaches MAX, stop issuing CRLs? 
> 
>"monotonically increasing" - Definition: A function from a partially 
order[ed] 
>domain to a partially ordered range such that x >= y implies f(x) >= f(y). 
> 
>- From the NIST web site: 
> http://hissa.nist.gov/dads/HTML/monotoncincr.html
<http://hissa.nist.gov/dads/HTML/monotoncincr.html>  
> 
>Regards, 
> 
>Carlin 
> 
>____________________________ 
> 
>-  Carlin Covey 
>    Cylink Corporation 
> 
>-----Original Message----- 
>From: Housley, Russ [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Monday, May 07, 2001 6:21 AM 
>To: Santosh Chokhani 
>Cc: [email-masked] 
>Subject: RE: delta CRLs 
> 
> 
>Santosh: 
> 
>X.509 may allow the CRL number to wrap around, but I do not believe that 
>PKIX does. 
> 
>     5.2.3  CRL Number 
> 
>     The CRL number is a non-critical CRL extension which conveys a 
>     monotonically increasing sequence number for each CRL issued by a CA. 
>     This extension allows users to easily determine when a particular CRL 
>     supersedes another CRL.  CAs conforming to this profile MUST include 
>     this extension in all CRLs. 
> 
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 
> 
>Russ 
> 
> 
>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote: 
> 
> >Actually, the text allows for the wrap of the numbers.  Please see Annex 
B 
> >of X.509.  Thus, it is not strictly increasing 
> > 
> >-----Original Message----- 
> >From: Peter Sylvester 
> >[< mailto:[email-masked] <mailto:[email-masked]>
> mailto:[email-masked] <mailto:[email-masked]> ] 
> >Sent: Saturday, May 05, 2001 2:08 PM 
> >To: [email-masked]; [email-masked]; 
> >[email-masked] 
> >Cc: [email-masked] 
> >Subject: RE: delta CRLs 
> > 
> > > Trevor: 
> > > 
> > > The 2000 version of X.509 is very clear on this.  For a given CRL 
stream 
> > > identifier, the CRL number is unique whether it is base or delta. That

is 
> > > why delta number has to be greater than the base. 
> > 
> >" 8.5.2.1 CRL number extension 
> > 
> >   This CRL extension field conveys a monotonically increasing sequence 
> > number .." 
> > 
> >The text might be clearer IMHO if 'strictly increasing' would be used 
> >instead.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 May 2001 10:19:21 +0200

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: "Housley, Russ" <[email-masked]>
Date: Thu, 10 May 2001 09:05:56 -0400

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.

>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

>  So a

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 10 May 2001 10:15:25 -0400

Denis,

If I understand this text correctly, it would prohibit a CA from
issuing an unscheduled delta CRL (one whose thisUpdate is less than
the nextUpdate of the prior delta).  Two possible workarounds:

1) A CA that issues a delta-CRL at time T less than nextUpdate of
   a previous delta-CRL referring to the same base MUST NOT populate
   the nextUpdate field of the unscheduled delta-CRL.

or

2) A CA that issues a delta-CRL at time T less than nextUpdate of
   a previous delta-CRL referring to the same base MUST populate
   the nextUpdate field of the unscheduled delta-CRL with the
   value of nextUpdate from that previous delta-CRL.

Either of these restrictions would allow multiple deltas to exist
at a time T, but would forbid interleaved series of deltas, which
I believe is the intent of your proposal.

Dave

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 10 May 2001 09:07:43 -0700

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

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

Common point:

Tim/David/Russ: ???

Denis: No.
Tim/David/Russ : ???

Denis: No.
Tim/David/Russ : ???

Regards,

Denis

---

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

Carlin and Sharon (at the same time),

> Now I'm confused again (or still).  

:-)

> I agree that there is a difference
> 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

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 10 May 2001 09:50:58 -0700

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

Common point:

Tim/David/Russ: ???

Denis: No.
Tim/David/Russ : ???

Denis: No.
Tim/David/Russ : ???

Regards,

Denis

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 10 May 2001 10:07:56 -0700

Denis said: So do you mean that X.509 and PKIX are taking different
approaches ?

Carlin says:  Well, yes, they are taking different approaches in that PKIX
has defined a subset of certain X.509 features. As of a few weeks ago, we
added wording to the PKIX profile to mandate the deltaCRLIndicator extension
in delta CRLs.  Prior to that its usage was discussed in the profile, but
there was no text saying that this extension was the required way to
identify delta CRLs.  When the deltaCRLIndicator extension is used to
identify a CRL as a delta CRL, the base CRL must be a full CRL.  But X.509
also permits a delta CRL to be identified by a cRLScope extension, in which
case the base CRL could another delta CRL.  (Thanks, David Cooper, for
confirming my understanding.)

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 9:30 AM
To: Carlin Covey; Sharon Boeyen
Cc: [email-masked]
Subject: Re: delta CRLs

:-)

Regards,

Denis

---

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

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

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

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

 >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

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.

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

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

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

 >(which may less frequent due to the support of delta CRLs).

Yes, but the goal should be to minimize the fetching of full CRLs.

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

 >the value of nextUpdate from the base CRL.

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 ?

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

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.

 >Denis: Yes. The delta CRL refers to the *new* base.

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.

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

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

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.

 >    contains a delta CRL indicator extension with the same CRL number as

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

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

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.

 >the baseUpdateTime extension from X.509 which would even more complicate the

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:
>You are quite right.  I, for one, will try to be more careful about the 
>use of them.
>
>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]

---

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

>relying parties not supporting delta CRLs.

Neither X.509 nor the draft PKIX profile requires the inclusion of the 
freshestCRL extension.  It might be a nice to advertise the availability 
(that is why it is there).  Remember that the PKIX profile does not require 
CAs to issue CRLs.  We do not want to make it difficult for them to do 
so.  Further, we do not want to make it too difficult to support delta CRLs.

>PKIX are taking different approaches ?

The PKIX profile is selecting a subset of the X.509 functionality.  Always 
has!  Always will!

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 10 May 2001 16:06:41 -0400

I agree with Russ, Tim, and David on **every single point** made in
this long note.

Dave

"Housley, Russ" wrote:
> Here goes ....  [ remainder snipped ]
> 

  ... which was later corrected:
> 
> 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.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 11 May 2001 18:58:27 +0200

Russ, 

Thanks for this very detailed collective response.

I have been hoping to have a phone call with some of you today, but since
this had not been possible, here is an answer to your email.

FYI, I will be out of my office during three days, so do no expect a reply
before next Thursday.

The thread has been focussing on the mechanisms, forgetting what is the
rational about them. So let us come back to the rationals. One of them
relates top the use of CRLs when applied to a non repudiation service.

X.509 has been originally written to use CRLs for other security services
and for these other services, the problems are different.

We all want to be able to use either CRLs or OSCP responses for non
repudiation purposes. In fact we want to allow any of these two techniques
to be used in single or in combination. Right ?

Having said this, we can now explain some of the rational. 

When validating a digital signature, for a given time T, for non repudiation
purposes, it is important for a verifier to be able to prove that the
certificate was NOT revoked. It is also important that two different
verifiers come to the same result, for the same time T, because of the goal
of non repudiation is to solve disputes.

The same properties must be achieved whether OCSP or CRLs are used. When an
OCSP response is received with a time T in it, there can be no dispute about
it: it contains three possible answers (not revoked, revoked, don't know).
If an OCSP responder produces one such answer with a time T and one of the
three statuses, no one else can present an answer with the same time T in it
with a different answer from the same OCSP responder. Once again, it would
not be acceptable that at a given time T two opposite responses could be
obtained. This would result in disputes.

This means that at time T, there is must be one and only one possible
answer. This allows to use OCSP responses for non repudiation purposes. The
same property must be supported so that CRLs can be used for non repudiation
purposes. So the goal is that when using CRLs in the context of non
repudiation, only one response (i.e. not revoked, revoked, don't know) can
be obtained.

I do know that non repudiation is only one use of the PKI and that there are
other usages such as authentication, integrity and confidentiality. So let
us now describe what is necessary, if the CRL contains at least one
certificate that can be used for non repudiation purposes (e.g. it has the
NR bit set).

If at time T there is more than one CRL valid, then there is a possibility
to miss the most recent, in case there is a denial of service attack on it
(i.e. suppression of the latest CRL while in transit).

This means that "emergency" CRLs will not necessarily be seen. "Emergency"
CRLs may be used for authentication, integrity and confidentiality, but may
create problems when used in the context of non repudiation.

This has several implications: we should deprecate the use of "emergency"
CRLs for being used for a non repudiation service, because they could
provide two different responses. 

People using full CRLs, i.e. without taking advantage of the delta CRLs,
would get only one result.

People using base CRLs and thus taking advantage of the delta CRLs would
also get one single result. For that reason we should also deprecate the use
of "emergency" delta CRLs.

This now explains why it is important to get one answer, at most, at a time.
I do understand that lacking this information, the mechanism seems to be
constrained without any "good" reason.

Now how can a verifier be sure to get the freshest information ?

This depends on the verification rules. Let us restrict the discussion to
the leaf certificate.

If the validation rules (be careful this has strong relationships with the
DPV protocol) say : "use full CRLs only" and there is no "emergency CRL",
then everything works nice.

If the validation rules say: "use the freshest information that is provided
by the CA", then the question is how can a verifier know how the freshest
information is obtained ? The answer is: only through extensions. Why ?

Let us assume first that no extension either in the certificate or the CRL
is being used. The answer would be : make a search for delta CRLs in the
directory. The problem is that, in case a denial of service attack, the
delta CRLs, even if they exist, will not be "seen". So the verifier will use
the base CRL and thus two verifications done at the same time T will provide
two different results. :-(

So there needs to be some way, so that, in the event of a denial of service
attacks, either the right information is obtained or that no information at
all is obtained. In the later case, if the revocation information is not
found, then the signature is not accepted (in some cases a try can be done
later on).

A consequence is the following: verifiers must know without ambiguity
whether a delta CRL mechanism is supported, so that if delta CRL are
supported it is possible to know unambiguously that it is the case. 

There are two options. 

1) Should we use the freshestCRL extension from the leaf certificate ? This
means that the CA MUST support delta CRLs at any time during whole the
life-time of the certificate. This is quite constraining for the CA, but
this is possible.

2) Should we use the freshestCRL extension from the CRL? This means that the
CA will only support delta CRLs for that CRL without any engagement to
support a delta CRL mechanism for the next one. This is more flexible.

What does this means ? That it is very likely that we will not end up wit
the same mechanism when using delta CRLs for a certificate used for non
repudiation purposes and when using a certificate for other purposes. One of
the algorithms may look first at the delta CRLs, whether they exist or not,
while the other will only take a look for them after making sure that they
must exit.

The best guess, if it succeeds, is certainly valid for "other purposes". So
I will now focus on the algorithm to be used for non repudiation purposes.

   An application that is willing to obtain the freshest CRL 
   information for a given certificate used for non repudiation 
   purposes, must know if a delta CRL mechanism is supported. 
   Either the certificate or any CRL that is able to reference 
   that certificate MUST include a freshestCRL extension 
   (a.k.a. a Delta CRL distribution point). 

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

For the constraint about the CA:

   For any CRL that may reference a certificate used for 
   non repudiation purposes, and for any time T until 
   the nextUpdate time indicated in a base CRL, the CA MUST 
   provide one and only one base CRL and one and only delta 
   CRL that refers to that base CRL and for which time T 
   falls between thisUpdate and nextUpdate from the delta CRL.

There are still other issues to discuss, like the CRL numbering,
whether it is unique or not, let us wait for next week for that topic.

Regards,

Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 16 May 2001 17:54:08 -0400

Denis,

It appears that the concerns you expressed below are not specifically related to the use of delta-CRLs, but are instead related to the use of CRLs in general. You seem to be suggesting that, in order to support non-repudiation, CRLs must be issued in a certain way and that you want to require that CRLs only be issued in a manner that supports non-repudiation. While I do not agree that all PKIs should be required to support the special needs of non-repudiation, I will set aside that issue for the moment.

Even if I were to agree that CRLs must be issued in a manner that supports non-repudiation, I would still disagree with the requirements you propose for the following reasons:

1) You state that any two CRLs issued for a given scope must not have overlapping validity periods (where the validity period of a CRL is defined as [thisUpdate ... nextUpdate]). This is troubling for two reasons:

         a) As Trevor Freeman has pointed out, there may be significant delays between the
             time that a CRL is issued and when it is available in repositories. If the validity
             periods of CRLs can not overlap, then there will be gaps (periods of time in which
             no valid CRL is available to relying parties). This is not acceptable.

         b) If a CRL issuer discovers that a private key has been compromised, your requirements,
             by not allowing the issuing of an "emergency" CRL, would require the CRL issuer to
             hide the compromise of the private key from relying parties until the end of the validity
             period of the currently valid CRL. While this would ensure that all relying parties receive
             the same information, it would also ensure that all relying parties receive incorrect
             information. Does this really help to support non-repudiation?

2) You state that in a non-repudiation dispute, the issue would be settled by using CRLs or OCSP responses to determine the status of the certificate at some time T and that all possible methods of determining that status at time T must provide the same result. You did not state when time T should be. Time T could either be the time that the signature was created or the time that the signature is being validated. Since the signature could be validated at different times, it seems that the only way to ensure consistency is make time T the time that the signature was created.

You state that one should use a CRL for which thisUpdate <= T <= nextUpdate.  This, however, contradicts the requirements stated in "Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service" (http://www.ietf.org/internet-drafts/draft-ietf-pkix-technr-03.txt). According to this draft, in order to make a final judgement about the validity of a signature, one must use a CRL that has a thisUpdate time later than the time at which the signature was created (i.e, T <= thisUpdate). If one follows these guidelines, then consistency is assured.  If the certificate was revoked at the time that the signature was created (T), then it will appear as revoked on any CRL issued after time T (at least until the certificate expires) with a revocationDate <= T.  So, following the rules in the draft document on non-repudiation, one will always receive a consistent answer as to the status of the certificate, even if the CRL issuer creates "emergency" CRLs.

Perhaps you believe that the draft document on non-repudiation does not accurately reflect the requirements for supporting non-repudiation. If this is the case, though, then any necessary changes should be made to that document, not to the text in the Certificate and CRL profile on how to use delta-CRLs.

>of non repudiation is to solve disputes.

The only way to determine whether a certificate was revoked at time T is to use a CRL that was issued after time T (i.e., T <= thisUpdate). If the certificate was revoked at time T, any CRL issued after time T will state that. The rules that you propose, on the other hand (thisUpdate <= T <= nextUpdate), would not achieve the result that you claim to desire.

Perhaps the rules should instead state that in order to determine the status of a certificate at time T, one should obtain a CRL whose scope includes the certificate for which T <= thisUpdate (in the CRL) < notAfter (in the certificate). If the certificate is not listed or is listed with a revocationDate > T, then the certificate was not revoked at time T.

>obtained. This would result in disputes.

Actually, this is not technically correct. There is no guarantee that an OCSP response that is received at time T was generated at time T. An OCSP response contains three fields: thisUpdate, nextUpdate, and producedAt. Any response received by a relying party for which T < nextUpdate should be considered a good response. However, there is no guarantee that the producedAt time is after the time at which the request was made. Furthermore, even if it were, the thisUpdate time in the response could precede the producedAt time. So, again, a response from an OCSP server at time T that states that a certificate is "not revoked" only guarantees that the status was "not revoked" at time thisUpdate. It is not a guarantee about the certificate's status at time T if T > thisUpdate.