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

From: "David P. Kemp" <[email-masked]>
Date: Mon, 02 Jul 2001 17:17:21 -0400

Trevor Freeman wrote:
> 
> 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.

Trevor,

That would be correct if a delta (call it "delta B") were
applied only to a complete CRL downloaded by the application.

But it is possible to save bandwidth by locally constructing the base
CRL instead of downloading a complete CRL.  Since the constructed base
needs a CRL number, the delta ("delta A") used to construct it must have
a CRL number.

   Complete CRL: ->  Delta A:
    CRL# = 1          baseCRL# = 1
                      CRL# = 2

                       |
                       V

                     locally-constructed   ->  Delta B:
                     complete CRL:              baseCRL# = 2
                      CRL# = 2

An application that supports delta CRLs is not required to support local
construction.  But an application that performs local construction
requires the CRL number extension to be present in delta CRLs - the
application cannot function without that extension regardless of
whether constructed CRLs are "numbered".

Denis argues that although the constructed CRL is built from Delta A
and Delta A must have a CRL number, the constructed CRL need not be
assigned a number.  That line of reasoning strikes me as pure sophistry.
But regardless of its merits, the identical argument can be made against
propogating thisUpdate and nextUpdate from Delta A to the constructed CRL.
Not propogating CRL number does not make the algorithm any more general,
it merely forces the algorithm description to be more verbose.

Denis says:
> This would lead to option D:
> 
>    The CRL number is a non-critical CRL extension which conveys a
>    unique number for a given CRL scope and CRL issuer. CRL issuers 
>    conforming to this profile MUST include this extension in all CRLs.
> 
> Only for reasons of backward compatibility, I will not push this proposal,
> but we have to understand that CRL numbers have an unneeded and overloaded
> semantics. So why we should make clear that local CRL numbers are no more
> than ONE way to implement an algorithm that could also be implemented using
> thisUpdate. Saying that using an algorithm that exhibits the same properties
> would be equally valid is not enough, because the reader will understand
> that the algorithm has to use CRL numbers. It would help to say that an
> algorithm using thisUpdate could also be constructed.

The reader will understand correctly that any algorithm for constructed CRLs
requires delta CRLs to contain the CRL number extension.  An algorithm using
thisUpdate and CRL number is possible; an algorithm using thisUpdate alone is
not.

Moreover, if as in option D CRL numbers are merely unique and not time-ordered,
then an application cannot use a base CRL more recent than that specified in
the deltaCRLIndicator extension.  You were previously happy when Russ
changed "greater than or equal to" to "equal to or greater than". Option D
would force it to be exactly "equal to" and would make thisUpdate
irrelevant when matching a delta to its base.  You can't have it both
ways; either you want a construction algorithm which permits the use of
thisUpdate, or you want CRL numbers to be unique but unordered thereby
excluding the use of thisUpdate.

If a new delta CRL extension were defined which contained a "baseThisUpdate"
time,
then an alternate algorithm which does not use CRL numbers would be possible.
But PKIX requires delta CRLs to contain the deltaCRLIndicator extension and
PKIX does not profile the X.509 crlScope extension, therefore an algorithm
using thisUpdate alone to link a delta to its base cannot be defined within
this edition of Part 1.  Perhaps in grandson-of-2459.

Regards,
Dave

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 6 Jul 2001 09:08:45 -0700

Hi Dave,

I don't see the CRL number is that vital in the construction of a local
CRL.

The application must start a db of s\n from a base CRL. Then the
application needs to update that DB by adding the list of s\n from the
next delta CRL. The "this update time" can be used to determine from a
set of deltas, which is the oldest. The only reason you need to apply
them in sequence is because of the "remove from CRL" reason codes,
otherwise it would not matter. As you process the next delta you will
get a number of "collisions", by design which you ignore, these will be
because have already either added or removed the s\n referenced in the
delta. 
As a point of interest any application doing this behavior with delta
CRLs only, will start to diverge from applications using base and delta
CRLs because what these applications will not do is purge s\n of
certificates which have expired. So technically speaking they will not
contain identical information.

Trevor

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]] 
Sent: Monday, July 02, 2001 2:17 PM
Cc: [email-masked]
Subject: Re: Should a CRL number be unique or not ?

Trevor Freeman wrote:
> 
> 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.

Trevor,

That would be correct if a delta (call it "delta B") were applied only
to a complete CRL downloaded by the application.

                       |
                       V

An application that supports delta CRLs is not required to support local
construction.  But an application that performs local construction
requires the CRL number extension to be present in delta CRLs - the
application cannot function without that extension regardless of whether
constructed CRLs are "numbered".

Denis argues that although the constructed CRL is built from Delta A and
Delta A must have a CRL number, the constructed CRL need not be assigned
a number.  That line of reasoning strikes me as pure sophistry. But
regardless of its merits, the identical argument can be made against
propogating thisUpdate and nextUpdate from Delta A to the constructed
CRL. Not propogating CRL number does not make the algorithm any more
general, it merely forces the algorithm description to be more verbose.

Denis says:
> Only for reasons of backward compatibility, I will not push this
> proposal, but we have to understand that CRL numbers have an unneeded 
> and overloaded semantics. So why we should make clear that local CRL 
> numbers are no more than ONE way to implement an algorithm that could 
> also be implemented using thisUpdate. Saying that using an algorithm 
> that exhibits the same properties would be equally valid is not 
> enough, because the reader will understand that the algorithm has to 
> use CRL numbers. It would help to say that an algorithm using 
> thisUpdate could also be constructed.

The reader will understand correctly that any algorithm for constructed
CRLs requires delta CRLs to contain the CRL number extension.  An
algorithm using thisUpdate and CRL number is possible; an algorithm
using thisUpdate alone is not.

Moreover, if as in option D CRL numbers are merely unique and not
time-ordered, then an application cannot use a base CRL more recent than
that specified in the deltaCRLIndicator extension.  You were previously
happy when Russ changed "greater than or equal to" to "equal to or
greater than". Option D would force it to be exactly "equal to" and
would make thisUpdate irrelevant when matching a delta to its base.  You
can't have it both ways; either you want a construction algorithm which
permits the use of thisUpdate, or you want CRL numbers to be unique but
unordered thereby excluding the use of thisUpdate.

If a new delta CRL extension were defined which contained a
"baseThisUpdate" time, then an alternate algorithm which does not use
CRL numbers would be possible. But PKIX requires delta CRLs to contain
the deltaCRLIndicator extension and PKIX does not profile the X.509
crlScope extension, therefore an algorithm using thisUpdate alone to
link a delta to its base cannot be defined within this edition of Part
1.  Perhaps in grandson-of-2459.

Regards,
Dave

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 06 Jul 2001 10:53:13 -0700

Hi Trevor,
    I believe what Dave was trying to say, is that by having
a CRLNumber on the delta, you can know what your new effective
base is, so that if the new delta is off a CRL at or before
the new effective base, you can apply it to the locally
created CRL data.

For example:

You get a full CRL with CRLNumber 10
Get delta1 with a base of 10 and CRLNumber of 11
Get delta2 with a base of 11 and a CRLNumber of 12

You can now apply delta2 to (CRLNumber 10 + delta1), without
ever having had to get CRLNumber 11.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 9:09 AM
> To: David P. Kemp
> Cc: [email-masked]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Dave,
> 

....[Bunch of stuff deleted]

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 06 Jul 2001 11:52:19 -0700

Trevor,
    If delta2 was off a base of CRLNumber 11, then you would need
to retrieve the full CRL for CRLNumber 11 - even thought CRLNumber 11
might just be the combination of CRLNumber 10 + delta1

Regards,
Ambarish

> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [email-masked]
> Hi Ambrish,
> I acknowledge the need for the delta CRL indicator extension in the
> delta CRL which contains the CRL number of the base CRL. That is not
> what I am talking about. I am talking about the CRL number 
> extension in
> the delta itself - which I agree is a common mistake to make. I don't
> see the value of the CRL number extension in the delta CRL if you are
> simply trying to establish the sequence of delta CRLs.
> 
> So equally
> base CRL, CRL number = 10
> 
> Delta1, delta CRL indecator = 10, this update = 12:00 pm
> 
> Delta2, delta CRL indeactor = 10, this update = 12:01pm
> 
> It is ovious which base number I need, and which is the freshest delta
> CRLs.
> 
> If I had an application building is own local database from 
> delta CRLs,
> then it has all the information it needs.
> 
> Trevor
> 
> From: Ambarish Malpani [mailto:[email-masked]] 
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [email-masked]
> a CRLNumber on the delta, you can know what your new 
> effective base is,
> so that if the new delta is off a CRL at or before the new effective
> base, you can apply it to the locally created CRL data.
> 
> For example:
> 
> > get a number of "collisions", by design which you ignore, 
> these will 
> > be because have already either added or removed the s\n 
> referenced in 
> > the delta.

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 6 Jul 2001 11:43:55 -0700

Hi Ambrish,
what I am talking about. I am talking about the CRL number extension in

So equally

If I had an application building is own local database from delta CRLs,
then it has all the information it needs.

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Friday, July 06, 2001 10:53 AM
To: Trevor Freeman; David P. Kemp
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?

Hi Trevor,
    I believe what Dave was trying to say, is that by having
a CRLNumber on the delta, you can know what your new effective base is,
so that if the new delta is off a CRL at or before the new effective
base, you can apply it to the locally created CRL data.

For example:

You can now apply delta2 to (CRLNumber 10 + delta1), without ever having
had to get CRLNumber 11.

Hope this helps,
Regards,
Ambarish

> get a number of "collisions", by design which you ignore, these will 
> be because have already either added or removed the s\n referenced in 
> the delta.

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 6 Jul 2001 14:43:28 -0700

Ambrish,
Yes, I have considered that and I don't see it makes an impact on the
requiremtns for the CRL number extension in the delta CRL. You are just
pointing out that the delta CRL indicator extension in te delta CRL may
have the value of 11 in the example delta 2 rather than 10.

The assertion Dave made was that the CRL number extension (N.B. not the
delta CRL indicator extension) in the delta CRL was necessary for
applications trying to construct local CRLs. I don't think the CRL
number extension in the delta CRL helps.

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?

Trevor,
    If delta2 was off a base of CRLNumber 11, then you would need to
retrieve the full CRL for CRLNumber 11 - even thought CRLNumber 11 might
just be the combination of CRLNumber 10 + delta1

Regards,
Ambarish

> what I am talking about. I am talking about the CRL number extension 
> in the delta itself - which I agree is a common mistake to make. I 
> don't see the value of the CRL number extension in the delta CRL if 
> you are simply trying to establish the sequence of delta CRLs.
> 
> So equally

>     I believe what Dave was trying to say, is that by having a 
> CRLNumber on the delta, you can know what your new effective base is,
> > I don't see the CRL number is that vital in the construction of a 
> > local CRL.
> >

---

From: Olle Larsson <[email-masked]>
Date: Sat, 7 Jul 2001 12:10:52 +0200

Trevor,

Constructing a local CRL like you say, ie by using the thisUpdate field
only, imposes a requirement that only one delta CRL may be issued per second
and issuer, as the date field doesn't come with a higher resolution than
that.

Is that really a fair requirement for a general internet PKI?
I doubt it.

/Olle

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Friday, July 06, 2001 11:43 PM
To: Ambarish Malpani
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?

Ambrish,

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?

Trevor,

Regards,
Ambarish

---

From: Olle Larsson <[email-masked]>
Date: Sat, 7 Jul 2001 16:28:49 +0200

My apologies: scrap that. Mental meltdown...

/Olle

-----Original Message-----
From: Olle Larsson [mailto:[email-masked]]
Sent: Saturday, July 07, 2001 12:11 PM
To: 'Trevor Freeman'; Ambarish Malpani
Cc: [email-masked]'
Subject: RE: Should a CRL number be unique or not ?

Trevor,

/Olle

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Friday, July 06, 2001 11:43 PM
To: Ambarish Malpani
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?

Ambrish,

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?

Trevor,

Regards,
Ambarish