Subject: Re: TSA Response serialNumber Field

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2000 13:59:42 +0200 (MET DST)

Denis, 

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

This is exactly the contrary of what is defined. 

See below (the first X* should be like the second one).

2.1. Requirements of the TSA

The TSA is REQUIRED:

     1.  to use a trustworthy source of time.

     2.  to include a trustworthy time value for each time stamp token.

     3.  to include a monotonically incrementing integer for each 
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
         newly generated time stamp token.

.....

The serialNumber field shall include a strictly monotonically 
                                       XXXXXXXXXXXXXXXXXXXXXX  

increasing integer from one TimeStampToken to the next (e.g. 45, 236, 
XXXXXXXXXXXXXXXXXX                                           YYYYYYYY
245, 1023, ...). 
YYYYYYYYYYYYYY
                  This guarantees that each token is unique and allows 
to compare the ordering of two time stamps from the same TSA. This is 
useful in particular when two time stamps from the same TSA bear the 
same time. This field also provides the way to build a unique 
identifier to reference the token. It should be noticed that the 
monotonic property must remain valid even after a possible 
interruption (e.g. crash) of the service. 

> 
> 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. 
Indeed.
                                              This is implementation
> details that should not appear in an RFC.
Some hints about possible ways to do this can be given as examples. 

> 
> 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.
How do you avoid a duplicate random number in the same interval.

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

How would you compare two time stamps in this case? 

Regards

---

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

Peter,

You are right. The name "serialNumber" in this context is
misleading. I forgot to look backwards to find out the additional
statements you mention. :-(

The serialNumber field serves several purposes, one of them being to
be used in conjunction with the DN to uniquely identify a TS token.

We have added another constraint, i.e. monotonically increasing,
that does not appear in other standards. This was done to save an
additional parameter. The main idea was to be able to compare two
time stamps issued during the same second.

An implementation could use a concatenation of a time (up to the
second granularity) and a counter.
The counter may be preset to any value when starting a new second,
then incremented using some fixed value, and make sure that the
counter cannot overflow within one second.

Since I do not know today a server recovering from a deep crash in
one second, there should be no problem. When such a recovery time
will happen, the TSA functionality could possibly wait for one
second.

Note that in that case the use of a hash function is far less
obvious than before and a limit 128 bits would probably be much more
than needed.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 May 2000 10:41:28 -0400

Denis,

>time stamps issued during the same second.

I think that is critical and there is another possible reason for 
wanting the counter to be monotonically increasing.  It helps detect 
if a TSA tries to insert a late arriving hash into the time stamp 
stream.  If there are no sequence number gaps, there are no "hole" 
into which a later arriving hash can be inserted.  I assumed this was 
another motivation.

Steve