Subject: RE: delta CRLs

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

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 08:28:26 -0700

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