RE: TSA Response serialNumber Field

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

Guys,

How do you know when the "Time stops" and the "Order begins"?

If we allow two different interpretations of the fractions component - i.e.
'ordering' or 'real time' - we have to say explicitly what it is. And a lot
more, to make it unambiguous.

How do I know whether I should take the fractions as order index, or as a
real value from high resolution clock?

Imagine:

Stamp from TSA_1: 20000529053138.345Z. Accuracy = 1 sec.
Stamp from TSA_2: 20000529053138.876Z. Accuracy = 1 sec

The difference is in fractions, as you can see. I trust that the TSAs are in
synch with 'absolute time', enough for me to be able to compare the stamps.

How do I do it?

1. Do I assume that .345 and .876 is just ordering? And consequently I trim
the time down to the order of accuracy (i.e. seconds), and the time is
identical?

or

2. Do I assume that both TSA_1 mad TSA_2 have a high resolution clock,
allowing to assign finer times? And consequently there is a high probability
that Stamp1 is older than Stamp2?

or

3. Do I assume that 20000529053138.34 was the actual time, and the order is
5? And the order was 6 for the other stamp?

What I am trying to say is that imposing two different meaning for one
variable inevitable creates a mess. Then you are trying to add a separate
variable to clear up the mess. Then you end up with a bloated document
explaining how those two variables interact, trying to eliminate any
ambiguity :)

What we had: Time, Accuracy, [Unique referencing+Ordering].

What we are getting to: [Time+order], Accuracy, ConditionVariable, and
derived referencing.

This is really a matter of style, though.






> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Tuesday, May 30, 2000 7:25 PM
> To: Manger, James H
> Cc: ietf-pkix@imc.org
> Subject: Re: TSA Response serialNumber Field
> 
> 
> James,
> 
> Thanks for the shortest "simple and complete" message. I picked it
> to answer to all the recent messages posted on that topic. 
>  
> > 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.
> 
> 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.
> 
> > * 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.
> 
> 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.
> 
> > * 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.
> 
> 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
>