Subject: Re: TSA Response serialNumber Field

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 May 2000 18:22:00 +0200 (MET DST)

> I understand that using 20 octects allows to use the result of a
> hash function and thus does not mandate any sequentiality. It also
> has the further benefit to hide the number of time stamps generated.
> 

What do you mean by your first sentence 'sequentiality'? 
I guess you mean contiguous 'no holes in the sequence'?  

Where is a hash in that scenario? 

The requirement is to have unique values AND and that the numbers
are ordered in time.

An example is to make a concatenation of a binary time value
with some arbritrary precision, and a counter below like
a STCK instruction on IBMs, time with 2**-20 seconds + 12 bits
counter.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 May 2000 09:34:47 +0200

Folks,

Do not ask more than what RFC 2459 is saying about the serial number
from a public key certificate;

Extract from RFC 2459 page 18, section 4.1.2.2:

   The serial number is an integer assigned by the CA to each
   certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a
unique
   certificate).

The same field in a TS token serves the same purpose. There is no
notion of sequentiality. Maybe we should have called it unique
number. This has not been done since we wanted to maintain
consistancy with ISO. In order to maintain consistancy between
standards, it would not be appropriate to change the name and/or the
concept.

Denis

---

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:19:41 -0400 (EDT)

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> Folks, Do not ask more than what RFC 2459 is saying about the
 Denis> serial number from a public key certificate;

 Denis> Extract from RFC 2459 page 18, section 4.1.2.2:

 Denis> The serial number is an integer assigned by the CA to each
 Denis> certificate.  It MUST be unique for each certificate issued by
 Denis> a given CA (i.e., the issuer name and serial number identify a
 Denis> unique certificate).

 Denis> The same field in a TS token serves the same purpose. There is
 Denis> no notion of sequentiality. Maybe we should have called it
 Denis> unique number. This has not been done since we wanted to
 Denis> maintain consistancy with ISO. In order to maintain
 Denis> consistancy between standards, it would not be appropriate to
 Denis> change the name and/or the concept.

Ok, if uniqueness is the requirement to be satisfied, then that is
what should be required of the number in question.  

And yes, in that case it really should be called "Unique number" or
"Unique ID".  The fact that ISO calls it something else is not
important in my view; the fact that someone uses a misleading term is
not good reason for others to copy that mistake.

But if we keep the misleading term, the least that is needed is a note
right next to its definition that says "we call it this only for
compatibility with ISO; it actually is only a unique ID.  Values are
not ordered in any way."

    paul