Subject: Re: TSA Response serialNumber Field

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2000 16:40:34 +0200 (MET DST)

> 
> 1) Time Stamp Token ordering can be done in most cases (see above)
> by only using GenTime and accuracy.

A litte flame about accuracy: 
  A user that wants to get a time stamp in order not to miss a deadline
  goes to a TSA: The TSA tells, well it is 23h59'59" but maybe not, since
  we are not sure whether we have the right time, it may already be well
  2 seconds later or earlier, well, that's what we think, or almost.

  What kind of decision can you make based on that?
  What would be the harm if the TSA would simply adjust the time
  to the lower end of the interval, and generate no accuracy.
  If there is an application that requires to get the earlimost
  stamp just after midnight, and you are too early, you just repeat.

  Comparison between two time stamps of the same tsa can be done
  without using the accuracy; if the genTime is different, then there
  they are ordered by authority of the TSA. 

> 2) serialNumber is not *necessary*, but may be *useful*. So let us
> keep it.
That's a strange reasoning. Just because something may be useful, doesn't
mean that it MUST be supported. But actually that's not the problem:

You did not really address the proposals about how to generate
unique numbers, or in which scope they need to be unique.

- as it is now, the number has to be unique during the whole lifetime
  of the TSA.
(1)  "the time stamp token number xxx

- it was proposed to solve this unique identification requirement by
  either
  - a combination of some serialnumber that can make round trips
    AND the genTime value. 
(2)    "The time stamp token number xxx issued at genTime" 
  - or simply by using arbitrarily trailing things at genTime 
(3)    "The time stamp issued at genTime". 

If you have any of these UNIQUE identifications, you can most likely
transform this into an order, if you you allocate the 'numbers' 
not in a completely unorderable way, unlikely, since you would need to
avoid collisions by other means than 'hierachical counting'.

Personally I have a tendancy to like the idea of the genTime+serialnumber
approach (2) for unique identification, and leave it up to the TSA how
to reuse or not the serialnumber, but I am also happy with the text
as it stands since 3 years. 

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

How would an application decide in advance whether it could use
a time stamping authority, if there is a requirement to compare
time stamps. 

Would a TSA always either set the indicator in all certs or never,
or could it decide from stamp to stamp. (probably it's always on or off).

Some purists may also see a need for a third service possible 
without genTime, and just an serialNumber to establish an order, but
then I wouldn't call the service 'time' stamping .

---

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 14:00:47 -0400 (EDT)

>>>>> "Peter" == Peter Sylvester <[email-masked]> writes:

 >>  1) Time Stamp Token ordering can be done in most cases (see
 >> above) by only using GenTime and accuracy.

 Peter> A litte flame about accuracy: A user that wants to get a time
 Peter> stamp in order not to miss a deadline goes to a TSA: The TSA
 Peter> tells, well it is 23h59'59" but maybe not, since we are not
 Peter> sure whether we have the right time, it may already be well 2
 Peter> seconds later or earlier, well, that's what we think, or
 Peter> almost.

 Peter> What kind of decision can you make based on that?  What would
 Peter> be the harm if the TSA would simply adjust the time to the
 Peter> lower end of the interval, and generate no accuracy.  If there
 Peter> is an application that requires to get the earlimost stamp
 Peter> just after midnight, and you are too early, you just repeat.

 Peter> Comparison between two time stamps of the same tsa can be done
 Peter> without using the accuracy; if the genTime is different, then
 Peter> there they are ordered by authority of the TSA.

I can't see the point of this.

The interpretation of a timestamp with accuracy is simple: the TSA is
making an assertion that the time when it generated the stamp is in
the range [ts - accuracy .. ts + accuracy].  (In other words, it
promises that UTC will be contained in that interval.)

So if you want to know the lower end of the interval, fine, you can
compute that trivially.  It is not necessary to throw away information
in the protocol to give you that option.

Other applications may want to know the upper end of the interval.
And a number will want to know the interval itself.

For example, to order timestamps from two different TSAs, you have to
have the intervals.  The order is a partial order: if the intervals
don't overlap, the answer is obvious, and if they do overlap, the
order is indeterminate.  This in fact is the reason for having the
accuracy field.

>>>>> "Michael" == Michael Zolotarev <[email-masked]> writes:

 Michael> 3. a stamp issued by another TSA (AND the precision
 Michael> diapazons of the two stamps overlap). The only purpose of
 Michael> comparing is to figure out which stamp was issued
 Michael> earlier. We have two cases to consider here:

 Michael> Case1: Precision_TSA1 is equal to Precision_TSA2.  Here the
 Michael> rule would be to treat the precision as the span of the
 Michael> probability graph, with the probability being the highest at
 Michael> the middle point (base time value), and 0 at the ends of the
 Michael> 'hill'. Therefore, the court (my court :) would simply opt
 Michael> to ignore the precision field at all, and look at just the
 Michael> base values.  I would consequtively reject any claims that
 Michael> *your* probability graph is not a 'hill-shaped' curve.

 Michael> Case2: Precision_TSA1 is smaller than Precision_TSA2.  As a
 Michael> judge I fully trust the TSA1 'cause it's time is more
 Michael> precise. So I again look at the base time value. If TSA1
 Michael> stamp says it was generated a second earlier than TSA2 stamp
 Michael> - that's the truth. If TSA1 stamp says it was generated a
 Michael> second later than TSA2 stamp - that's the truth as well.

I don't understand this reasoning at all.  Whether TSA1 has an
accuracy smaller than that of TSA2 isn't interesting, as far as I can
see.  I don't understand why you would use it to make a binary
decision of merit (i.e., trusting only the TSA that has the smaller
accuracy). 

If you ignore the accuracy and compare only midpoints, you will
definitely be making an incorrect decision when the intervals
overlap.  ("Incorrect" in the sense of "not supported by the
evidence".)   This is true whether the accuracy values are the same or
different.  (For example, in your case 2, if TSA1 says 1:00:00 +/- 1s,
and TSA2 says 1:00:01 +/- 3s, it sounds like you're saying that the
TSA1 stamp is generated a second before the TSA2 stamp.  Not so -- the
TSA2 stamp may have been generated as much as 3 seconds before the
TSA1 stamp.)

     paul