Re: TSA Response serialNumber Field

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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