Subject: RE: delta CRLs

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

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: "Carlin Covey" <[email-masked]>
Date: Wed, 9 May 2001 10:35:02 -0700

RE: delta CRLsSantosh,

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: Carlin Covey [mailto:[email-masked]]
  Sent: Wednesday, May 09, 2001 1:16 PM
  To: Santosh Chokhani
  Cc: [email-masked]
  Subject: RE: delta CRLs

  Santosh,

  - 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

    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

    possibility
    future.
    (0..MAX).
    order[ed]
    >From: Housley, Russ [mailto:[email-masked]]
    B
>[<mailto:[email-masked]>mailto:[email-masked]]
    stream
    is

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 9 May 2001 12:22:40 -0700

RE: delta CRLsHaving 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

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

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,

  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?

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

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

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

      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

      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: "Michael Myers" <[email-masked]>
Date: Wed, 9 May 2001 13:37:54 -0700

Just out of curiousity, has anyone actually experienced real-world (vs.
lab-bench) collisions with this numbering issue?  I suspect not, but after
reading through all of this thread I'm curious to know.

Mike

---

From: Dr S N Henson <[email-masked]>
Date: Wed, 09 May 2001 22:22:51 +0100

> reading through all of this thread I'm curious to know.

Well speaking personally I haven't noticed collisions. However I've seen
*very* few V2 CRLs that may have something to do with them being
rejected by certain software.

I've yet to see a single example of a delta CRL. Considering some of the
confusion I suppose that's just as well :-)

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

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

Carlin,

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

Have you missed my e-mails ? I don't think you can say that "no one speak
against". I did. 

Regards,

Denis