Subject: RE: TSA Response serialNumber Field

From: Bill Lattin <[email-masked]>
Date: Tue, 23 May 2000 08:13:59 -0700

I think a better way to address this would be to reset the counter when the 
TSA signature key pair is generated.  This way, we could be more confident 
that a 64-bit counter is sufficient, plus given the real world difficulties 
of guaranteeing a monotonic counter for all time, this gives us a way to 
recover from system failures.  Linkage to the TSA signature key is a 
natural delimiter since the counter would be unique per key and the stated 
objective of the counter - to identify sequential time stamps containing 
the same time - would still be still achieved.

Cheers,

Bill Lattin
TTFN Associates

-----Original Message-----
From:	Peter Gutmann [SMTP:[email-masked]]
Sent:	Thursday, May 18, 2000 8:37 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	Re: TSA Response serialNumber Field

[email-masked] writes:

>To accomodate your issue we could add a comment in the ASN1 for the
>serialNumber saying:
>
>-- Time Stamps users must be ready to accomodate integers up to 64 bits.

I think a more general way of putting this would be "...must be ready to
accomodate integers larger than the machine's native word size", which 
warns
of potential problems without implying that there's some magic limit which
they can expect to find.  Actually for anyone who's worked with certs on
any scale, the use of 128-bit and 160-bit "serial numbers" there should be
enough of a warning.

Peter.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 24 May 2000 10:46:57 +0200

Bill,

Your proposal would not allow to unambiguously distinguing two TS
token using the TSA mane and the serialNumber. The same issue arises
in other documents. For example, in draft-ietf-pkix-ac509prof-03.txt
there is the following text.

Given the uniqueness and timing requirements above serial numbers
can be expected to contain long integers. AC users MUST be able to
handle serialNumber values longer than 4 octets. Conformant ACs MUST
NOT contain serialNumber values longer than 20 octets.

We could take the text proposed by Peter, which is a good warning,
but does not include an upper limit.
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.

I would thus propose to have a text like:

Given the uniqueness and timing requirements above serial numbers
can be expected to contain long integers, TSA users MUST be able to
handle serialNumber values longer than 4 octets. Conformant Time 
Stamps MUST NOT contain serialNumber values longer than 20 octets.

Can we agree on this ?

Denis

---

From: Paul Koning <[email-masked]>
Date: Wed, 24 May 2000 10:05:28 -0400 (EDT)

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

 Denis> ...
 Denis> We could take the text proposed by Peter, which is a good
 Denis> warning, but does not include an upper limit.  I understand
 Denis> that using 20 octects allows to use the result of a hash
 Denis> function and thus does not mandate any sequentiality. It also
 Denis> has the further benefit to hide the number of time stamps
 Denis> generated.

 Denis> I would thus propose to have a text like:

 Denis> Given the uniqueness and timing requirements above serial
 Denis> numbers can be expected to contain long integers, TSA users
 Denis> MUST be able to handle serialNumber values longer than 4
 Denis> octets. Conformant Time Stamps MUST NOT contain serialNumber
 Denis> values longer than 20 octets.

Sounds good.

If the intent is to allow hash function outputs -- and that is a good
feature -- then I question the use of the name "serial number".  The
problem with that name is that it implies sequentiality.  If the only
property required is uniqueness, then "Unique ID" is a better name.

Incidentally, note that a 20 bytes hash function does not guarantee
2^160 unique values.  By the birthday rule, you have a good chance of
a duplicate after 2^80 values have been generated.  So in fact it
would be wise not to use such a hash for more than 2^64 or so values,
which is fine since you're not going to go that high anyway in any
plausible amount of time....

      paul

---

From: "William Lattin" <[email-masked]>
Date: Wed, 24 May 2000 07:42:56 -0700

Denis,

The approach I suggested does allow for unique determination of a time
stamp, but to do so the validator must also have the certificate for the TSA
signature key.  I don't think this is unreasonable since proper verification
should include this information.

The issue I am attempting to address is the requirement for a monotonically
increasing serial number for all time.  The draft does not address how to
recover from a situation where the serial number is lost due to equipment
failure.  Such a failure is likely to occur at least once over all time :-).
The approach I suggest above does allow graceful recovery, since one could
generate a new TSA signature key and certificate and start again with a
reset counter.

I strongly suggest that we consider the ramifications of trying to assure
seamless operation for all time.  I don't think it is practical and we
should not design a standard requiring such.  I am open to other solutions
if the above suggestion is perceived as too burdensome.

Cheers,

Bill

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 01:47
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'

---

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

Bill,

A monotonically increasing serial number for all time is not
REQUIRED. See my previous response to Peter Sylvester.

However, your concern on how to recover from a situation where the
serial number is lost due to equipment failure is valid. The concern
is to make sure to have no duplicate when re-starting the service.
There are several ways to solve this issue. This is implementation
details that should not appear in an RFC.

As an example, you can use a concatenation of a time on 32 (or 33)
bits and a random number. In this way, when you recover from a
crash, at least one second has elapsed and there is no problem.

You can use the result of a hash applied to a concatenation of a
time on 32 (or 33) bits and a random number. The risk of collisions
is low if keep around 2 ^64 time stamps.

You can use a sequential number to derive from it (using some other
stuff) the serial number. Storing that sequential number every day
may allow you to make sure to have no duplicate (by skipping some of
the numbers that would have been normaly generated). 
  
There are many other ways or variants, and we are not going to
detail them. However, if you would like some additional text in the
security considerations section to warn better implementors (without
specifying how to meet the requirement), I would be ready to
consider a proposal.

Denis