Subject: RE: TSA Response serialNumber Field

From: "Manger, James H" <[email-masked]>
Date: Mon, 29 May 2000 15:59:15 +1000

TSA clients must support genTime values with fraction-of-second components,
e.g "20000529053138.345Z".  Consequently, by using sufficient
fraction-of-seconds digits, it is easy for a TSA to issue genTime values
that always increase and never repeat.
 
* The TSA does not need to maintain another never-repeating value
(serialNumber) and does not have to worry about maintaining it when the TSA
server crashes.
* The TSA does not need to issue (nor the client expect) huge integer
values.
* Ordering two timestamps from one TSA is simply achieved by comparing their
genTime fields.
* Accuracy (uncertainty with respect to UTC) is not affected as it is
conveyed in a separate field.
 
Simple.  Complete.
 
The only issue is whether the ordering works from timestamps with the same
TSA name or same TSA signing key.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 30 May 2000 11:24:54 +0200

James,

Thanks for the shortest "simple and complete" message. I picked it
to answer to all the recent messages posted on that topic. 
 
> (serialNumber) and does not have to worry about maintaining it when the TSA

Correct. This a very important argument. So if we maintain that
field it is *only* to uniquely identify the TST. Now, let us answer
to the question raised: whether that field is NECESSARY. This field
is not *necessary*. It MAY be *useful*. Yes, it usually makes sense
to associate the Time Stamp with the data it applies to. However, it
MAY or MIGHT be useful to be able to reference a Time Stamp that is
stored somewhere else.

> * Ordering two timestamps from one TSA is simply achieved by comparing their

Correct, this can ALWAYS been achieved  ... if we have the following
property:
| genTime 1 - GenTime 2 | > Accuracy of GenTime 1 + Accuracy of
GenTime 2

In the above equation > means stricly superior.

Now, when this condition does NOT apply, the BOOLEAN indicator
"ordering" allows to say whether ordering two timestamps from one
TSA can or cannot be achieved by comparing their genTime fields.

In the case a huge server doing parallel queuing and using parallel
crypto engines that this property is not that easy to maintain.
Allowing to perform an ordering in *any* case (i.e. in time frames
less than the second) is not needed by many applications, hence the
reason to place low contraints on the design, unless this property
is really needed.

Now, about the last received comment from Ed Gerck, the above
distinction gives a reliability of 100% if we have: | genTime 1 -
GenTime 2 | > Accuracy of GenTime 1 + Accuracy of GenTime 2 and when
that condition does not apply, either a reliability of 100% if the
the BOOLEAN indicator "ordering" is set to TRUE and a reliability of
0% if the the BOOLEAN indicator "ordering" is set to FALSE.

> TSA name or same TSA signing key.

It works, as indicated above, with the same TSA name.

As a conclusion:

1) Time Stamp Token ordering can be done in most cases (see above)
by only using GenTime and accuracy.
2) serialNumber is not *necessary*, but may be *useful*. So let us
keep it.
3) the BOOLEAN indicator "ordering" is useful to allow to address
two segment needs, and does not place design constraints when no
ordering within the second range is needed.

Denis