Subject: RE: delta CRLs

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 May 2001 12:27:55 -0400

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]]
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]]
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
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>-----Original Message-----
>From: Housley, Russ [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]]
> >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: "Carlin Covey" <[email-masked]>
Date: Wed, 9 May 2001 10:15:51 -0700

RE: delta CRLsSantosh,

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

  -----Original Message-----
  From: Carlin Covey [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

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

  possibility
  future.
  (0..MAX).
  order[ed]
  B
  stream
  is

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 09 May 2001 13:58:00 -0400

Carlin,

If a full CRL and a delta-CRL are issued for the same scope at the same time, then the constructed CRL that results from combining the delta-CRL with an appropriate base MUST be the same as the issued full CRL. The CRL number of the constructed CRL is the CRL number of the delta-CRL. Since the issued full CRL and the constructed CRL are the same CRL, they should have the same CRL number.  To assign the full CRL and the delta-CRL different CRL numbers would be to suggest that they are not the same, and that the one with the higher CRL number contains fresher information.

BTW, to chime in on two other issues:

1) I agree that if two CRLs, CRL1 and CRL2, are issued for the same scope, and thisUpdate of CRL1 is greater than thisUpdate of CRL2, then the cRLNumber of CRL1 must be greater than the cRLNumber of CRL2. I'm sure this was always the intention of the standard, but perhaps it was not stated with sufficient mathematical precision.

2) I agree with Santosh that much of the confusion we are having could be cleared up if delta-CRLs used the thisUpate field as a reference instead of cRLNumber. X.509 has defined a non-critical baseUpdateTime extension for use in delta-CRLs that specifies the value of thisUpdate in the base CRL that is referenced using the deltaCRLIndicator. I think it would be a good idea to include this extension in PKIX and recommend its inclusion in delta-CRLs. One could then base the delta-CRL processing rules on time instead of CRL numbers (at least for those cases in which the extension was present in the delta-CRL).

Dave

At 10:15 AM 5/9/01 -0700, Carlin Covey wrote:
>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