Subject: Re: Should a CRL number be unique or not ?

From: Peter Sylvester <[email-masked]>
Date: Fri, 29 Jun 2001 18:20:20 +0200 (MET DST)

> 
>    If a CRL issuer generates delta CRLs in addition to complete CRLs for
>    a given scope, the complete CRLs and delta CRLs MUST share one
>    numbering sequence.  If a delta CRL and a complete CRL that cover the
>    same scope are issued at the same time, they MUST have the same CRL
>    number and provide the same revocation information.  That is, the
>    combination of the delta CRL and an acceptable complete CRL MUST
>    provide the same revocation information as the simultaneously issued
>    complete CRL.

Isn't the following also true as a replacement or addition to the second sentence: 

If a delta CRL and a complete CRL that cover the same scope have 
the same CRL number they MUST provide the same revocation information
and MUST be issued at the same time. 

> 
>    If a CRL issuer generates two CRLs (two complete CRLs, two delta
>    CRLs, or a complete CRL and a delta CRL) for the same scope at
>    different times, the two CRLs MUST NOT have the same CRL number.
>    That is, if the this update field (section 5.1.2.4) in the two CRLs
                     thisUpdate

>    are not identical, the CRL numbers MUST be different.

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 29 Jun 2001 16:20:37 -0700

Sorry to be a heretic, but why do we need a CRL number in the delta CRL?
The "This Update" time seems far less ambiguous as a mechanism for
determining succession of delta CRLs - without resorting so linguistic
gymnastics. Having determined the delta CRL is of the same scope which
the CRL numner plays no pary, a simple comparison of the This update
time tells me which came last. Just keep the CRL number in the base
since you need that for the delta CRL indecator extension.

-----Original Message-----
From: Tim Polk [mailto:[email-masked]] 
Sent: Friday, June 29, 2001 1:26 PM
To: Denis Pinkas; Housley, Russ
Cc: [email-masked]
Subject: Re: Should a CRL number be unique or not ?

Option B.

At 05:05 PM 6/29/01 +0200, Denis Pinkas wrote:

>Russ,
>
>I have purposely changed the header of this e-mail so that people may
>pay attention to it.
>
>I have only copied a pasted the first part of your response so that
>people can reply. I will address the other part in a separate e-mail.
>
> > Denis:
>
> > > >> I do think it is a major advantage to be able to use unique
> > > >> numbers so
> > > that
> > > >> if I say "CRL 12345", only one CRL can be retrieved for a given
> CRL scope
> > > >> and CRL Issuer. In this way references to CRLs can easily be
> > > >> used
> and only
> > > >> the right CRLs may be stored or fetched in some repositories.
>
> > > > We have achieved this goal.  CRL 12345 represents a specific set

> > > > of
> revoked
> > > > certificates.  The relying party might determine the membership
> > > > of that list in more than one way (complete CRL, delta CRL 
> > > > combined with a
> previous
> > > > complete, or delta CRL combined with a locally constructed
> complete), but
> > > > in each case the membership of the list will be identical.
>
> > >I do not think so. You are not looking at the problem in the same
> > >way. I looked at it in terms of objects stored, whatever their 
> > >content is. If
> I ask
> > >to retrieve CRL 12345 from a repository, with your approach, I
> > >could retrieve TWO CRLs and not a single one. Thus If I want to 
> > >make sure
> that CRL
> > >12345 is stored, with your approach, the answer could be yes, but
> > >without additional information it would be impossible to know 
> > >whether it is
> the full
> > >CRL or the delta-CRL with the same number.
>
> > >I do understand that you want this property, but I do insist to say

> > >that this not necessary. See later for additional explanations.
>
> > This point has already been discussed.  If there are two CRLs with
> > the same number, then they contain the same list of revoked 
> > certificates (potentially with different nextUpdate information).  
> > This point has been beat to death, and I do not hear anyone besides 
> > you that thinks this is an issue.
>
>This is not the main issue, but how many responses you can get while
>specifying a CRLnumber + a CRL distribution point. If a CRL number is 
>unique, then the answer is one (or none). If not, it may be two (or 
>even more).
>
>OPTION A: The original text in draft-ietf-pkix-new-part1-06.txt was:
>
>    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.
>
>Everybody agrees that the first sentence option A is misleading (e.g.
>it would be permitted to issue all CRLs with the same number !). So we 
>have options B and C.
>
>OPTION B: The (much longer) text in draft-ietf-pkix-new-part1-07.txt
>
>    The CRL number is a non-critical CRL extension which conveys a
>    monotonically increasing sequence number for a given CRL scope and
>    CRL issuer.  This extension allows users to easily determine when a
>    particular CRL supersedes another CRL.  CRL numbers also support
the
>    identification of complementary complete CRLs and delta CRLs.  CRL
>    issuers conforming to this profile MUST include this extension in
all
>    CRLs.
>Option C : I am proposing a simple and single fix to RFC 2459 by
>changing "monotonically" into "strictly", which leads to:
>
>    The CRL number is a non-critical CRL extension which conveys a
>    strictly 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.
>
>[Note: monotonically means "superior or equal". strictly only means
>"superior".]
>
> > If others agree with Denis and have kept quiet because they feel
> > that he is a good spokesman, now is the time to speak up.  To me, 
> > and the PKIX WG chairmen, it seems that Denis is a lone voice on 
> > this issue.  If it is not so, yell now!
>
>So the vote, if any, is between Option B and Option C.
>
>Denis