Subject: Re: time-stamp-03: interaction of TSTTime and serialNumber values

From: "Michael Duren" <[email-masked]>
Date: Thu, 23 Sep 1999 11:22:10 -0400

Denis,

The revised text for that section is more appropriate.

Seems to me that section 2.1 (Requirements of the TSA), items 3 and 4
already invalidate the example.  However, looking at item 4 of that section:

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

Should that requirement state that the monotonically incrementing integer
must be unique?

Mike Duren

-----Original Message-----
From: Denis Pinkas <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: IETF-PXIX <[email-masked]>
Date: Thursday, September 23, 1999 5:52 AM
Subject: Re: time-stamp-03: interaction of TSTTime and serialNumber values

>Terry,
>
>The current text says:
>
>The serialNumber field shall include a strictly monotonically
>increasing integer from one TimeStampToken to the next (e.g. 45,
>236,
> 245, 1023, ...). This guarantees that each token is unique and
>allows to compare the ordering of two time stamps from the same TSA
>bearing 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.
>
>Apparently it is not clear enough. The text was supposed to mean:
>
>The serialNumber field shall include a strictly monotonically
>increasing integer from one TimeStampToken to the next (e.g. 45,
>236,
> 245, 1023, ...). This guarantees that each token is unique and
>allows to compare the ordering of two time stamps. This is
>useful in particular when two times stamps 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.
>
>As a consequence with this clarification, your example will become
>invalid. I will include this clarification in the next draft.
>
>Denis
>
>> The current draft of TSP requires that responses include a monotonically
>> increasing integer to identify the token and to resolve ordering within
>> the precision of the time stamp value.  However, the draft is not clear
>> as to whether the serial number itself is sufficient to order all tokens
>> issued by a certain TSA.  In particular, the draft does not indicate
>> whether the order of serialNumbers must correspond with the order of the
>> time stamp values themselves.
>>
>> For example, is it legal to issue the following time stamps?
>>
>>   Token #1:
>>     genTime: 19990922233002Z
>>     serialNumber: 1
>>
>>   Token #2:
>>     genTime: 19990922233001Z
>>     serialNumber: 2
>>
>>   Token #3:
>>     genTime: 19990922233002Z
>>     serialNumber: 3
>>
>> I think that this sequence should be legal.  The serial number field
>> still provides ordering within the same genTime value, and also provides
>> the required reference value for future queries about the token.  The
>> primary source of ordering information should always be the genTime
>> field.  If those values are the same, then the serialNumber MAY be used
>> to resolve the ordering of the tokens.
>>
>> (As an aside, I think providing ordering information is really beyond
>> the scope of this protocol in any case, and so I don't see any
>> requirement for monotonically increasing values)
>>
>> Terry
>>
>>   --------------------------------------------------------------------
>>
>>   Terry Hayes <[email-masked]>
>>   Netscape Communications Corp.
>>
>>   Terry Hayes
>>   Netscape Communications Corp.  <[email-masked]>
>>                                  Courrier HTML
>>                                  Bureau: (650) 937-2788
>>                                  Adresse Netscape Conference
>>   Informations supplémentaires:
>>   le nom           Hayes
>>   Prénom           Terry
>>   Version          2.1
>