Subject: Re: TSA Response serialNumber Field

From: [email-masked] (Peter Gutmann)
Date: Fri, 19 May 2000 03:37:07 (NZST)

[email-masked] writes:

>To accomodate your issue we could add a comment in the ASN1 for the
>serialNumber saying:
>
>-- Time Stamps users must be ready to accomodate integers up to 64 bits.

I think a more general way of putting this would be "...must be ready to
accomodate integers larger than the machine's native word size", which warns
of potential problems without implying that there's some magic limit which
they can expect to find.  Actually for anyone who's worked with certs on
any scale, the use of 128-bit and 160-bit "serial numbers" there should be
enough of a warning.

Peter.

---

From: Michael Zolotarev <[email-masked]>
Date: Wed, 24 May 2000 09:43:41 +1000

A very fair comment, Bill. Worth mentioning in the draft, Denis?

> -----Original Message-----
> From: Bill Lattin [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 1:14 AM
> To: [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: [email-masked]'
> Subject: RE: TSA Response serialNumber Field
> 
> 
> I think a better way to address this would be to reset the 
> counter when the 
> TSA signature key pair is generated.  This way, we could be 
> more confident 
> that a 64-bit counter is sufficient, plus given the real 
> world difficulties 
> of guaranteeing a monotonic counter for all time, this gives 
> us a way to 
> recover from system failures.  Linkage to the TSA signature key is a 
> natural delimiter since the counter would be unique per key 
> and the stated 
> objective of the counter - to identify sequential time stamps 
> containing 
> the same time - would still be still achieved.
> 
> Cheers,
> 
> Bill Lattin
> TTFN Associates
> 
> -----Original Message-----
> From:	Peter Gutmann [SMTP:[email-masked]]
> Sent:	Thursday, May 18, 2000 8:37 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	Re: TSA Response serialNumber Field
> 
> accomodate integers larger than the machine's native word 
> size", which 
> warns

---

From: [email-masked]
Date: Fri, 26 May 2000 14:51:43 -0400

Denis,

You could still achieve your objective of maintaining ISO compatibility and
requiring global uniqueness of each TS token using only a combination of the
TSA's name and the serialNumber provided the serialNumber field itself can
be made up of a date/time component and a numbering counter that start over
with every new time interval (e.g. a day, an hour, a minute, etc.). Note
this is similar to what I had suggested in my original message on May 18,
which started this whole thread.

For this reason I support the text proposed by Michael for the serialNumber
field.

I also support your rationale for the addition of the proposed BOOLEAN on
ordering in TS tokens with a minor change as suggested below. I think if it
is missing, or if the ordering field is present and set to false, then it
should only indicate that the ordering of Time Stamps issued by the same TSA
can not be guaranteed.

In section 2.4.2. Page 8.

"If the ordering field is present and set to true, Time Stamps tokens can
always be ordered by looking only at the genTime and the serialNumber
parameters.

If the ordering field is missing, or if the ordering field is present and
set to false, then the genTime field only indicates the time at which the
timestamp has been created by the TSA. In such a case, the ordering of Time
Stamps issued by the same TSA can not be guaranteed."

Regards

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, May 26, 2000 9:38 AM
To: Michael Zolotarev
Cc: [email-masked]
Subject: Re: TSA Response serialNumber Field

Michael,

Thank you for this good analysis of the issue.

The problem we have is that, currently, the serialNumber is used 
for two different purposes in order to address two different 
requirements, hence why we have some difficulties.
These requirements are the following:

1) Uniquely designate a TS token using a combination of the TSA's
name and the serialNumber. This is how serialNumber is used in RFC
2459 for both Public Key Certificates and CRLs, as well as how it is
used for Attributes Certificates, at least at the time being as
defined by ISO (and I suppose we are not going to change this). :-)

2) Distinguish betwen two time-stamps issued with the same time
(e.g. the same second).

I would propose a simple (and new) way to solve this issue: use one
parameter for one purpose only.

1) for the first requirement, stick to the use of this parameter as
required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
require uniqueness and nothing else. We may then keep the name 
"serialNumber".

2) for the second requirement, let us first look at it slightly
differently. 

Today we implicitly MANDATE TSAs to be able to indicate which one of
two time stamps (e.g. issued within the same second) was first. We
could simply ALLOW TSAs to be able to indicate which one of two time
stamps (e.g. issued within the same second) was first. In many
cases, the ordering of the token will be artificial and even wrong,
in particular when the TSA is handling multiple crypto-engines in
parallel. It may be indesirable or pretty hard to try to distinguish
between who came first in a waiting queue for a given crypto-engine
and who came out first from a waiting queue for another given
crypto-engine from the same TSA. In some designs shall parallel
crypto-engines use the same clock or can they use their own clock ?
If the clock is different, how is it possible to still guarantee the
ordering ? I would not like to answer to these questions and hence
mandate designs where all TSAs MUST always guarantee the ordering.
This would prevent some implentation designs. I would rather prefer
to ALLOW TSAs to guarantee the ordering, if they wish to do so. This
is more flexible and also recognizes the fact that mandating this
requirement in some environments is not at all needed.

Now let us look how to achieve these goals:

genTime is defined as the time at which the timestamp has been
created by the TSA. It can include any *precision*. However the
accuraccy (i.e. the time difference with UTC - not the precision) is
indicated in another parameter called accuracy which represents the
time deviation around the UTC time contained in GeneralizedTime.

If a TSA wants to ALLOW users to make the difference, it may then
use a precision much better than the second (and, for example, 
still have an accuracy of one second). Otherwise it does what 
it wants.

To this end the following changes are proposed:

Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a unique integer for each newly 
       generated time stamp token.

In section 2.4.2. Page 8. The serialNumber is an integer assigned by
the TSA to each Time Stamp token. It MUST be unique for each Time
Stamp token issued by a given TSA (i.e., the TSA name and
serialNumber identify a unique Time Stamp token).

On page 8, just after the sentence: " However, when there is no need
to have a precision better than the second, then GeneralizedTime
with a precision limited to one second should be used (as in 
[RFC 2459]).", add the following:

"When there is a need to sequence the time stamps issued from the
same TSA at a granularity better than the second, then a greater
precision must be used and be commensurate with the number of time
stamps that can be generated by that TSA within the same second."
  
There is however one major drawback with this. How can a TS user
know if the TS token issued by a given TSA are garanteed or not to
be ordered ? Simply looking at genTime and accuracy does not allow
to always make the difference. So we would need another parameter
(e.g. a BOOLEAN) :-( or use the security policy which is not
directly machine processable. :-(

The BOOLEAN would be "better", simple to understand, and allow more
more flexibility than we have today. It is quite late to introduce
another parameter at this stage, :-(  but if it is not now, it will
never be. :-). 

If we do so, it could be after:

      policy      PolicyInformation,

add:

     ordering     BOOLEAN DEFAULT FALSE,

with the following explanations:

" If the ordering field is present and set to true, Time Stamps
tokens
can always be ordered by looking only at the genTime parameter,
whatever their accuracy is.

If the ordering field is missing, or if the ordering field is
present and set to false, then the genTime field only indicates the
time at which the timestamp has been created by the TSA. In such 
a case, the ordering of Time Stamps issued by the same TSA is 
only possible when the difference between their genTime is greater 
than the accuracy of the first Time Stamp token plus the accuracy 
of the second Time Stamp token."

Now, an alternative to this proposal would be to MANDATE Time stamps
ordering (which does not appear to be a good requirement as
explained earlier). If so we should rename the current parameter
differently (in order to avoid confusion), like:

         increasingNumber                 INTEGER,

and have the following changes:
 
Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a strictly incrementing integer for 
       each newly generated time stamp token.

In section 2.4.2. Page 8. The increasingNumber field shall include a
strictly increasing integer from one TimeStampToken to the next
(e.g. 45, 236, 245, 1023, ...). This guarantees two properties: (1)
When used in combination with the TSA's name the increasing number
identifies a unique Time Stamp token. (2) It is always possible to
compare the ordering of two time stamps from the same TSA by looking
only at that field. This may be useful in particular when two time
stamps from the same TSA bear the same time. It should be noticed
that the stricly increasing numbering property must remain valid
even after a possible interruption (e.g. crash) of the service. A
recipient of a Time Stamp token MUST be able to handle increasing
numbers that are up to 16-bytes.

As a conclusion, at the time being, there are thus two choices.

Denis

> Folks,
> 
> As I can recall, the original idea behind the SerialNumber was simple: to
> preserve the ordering, and to arbitrate between timestamps which happen to
> have the same time value. It itself enforces that each timestamp is now
> unique (time+SerialNumber_within_time_interval is a unique combination),
> though the global uniqueness of the stamps was not the initial intent.
> 
> Considering that the original intention for the field is still there, let
me
> put a few short points together, to straighten things up a bit:
> 
> Point 1: "SerialNumber" in TSA is not the same thing as the 2459's serial
> number.
>
> Point 2: a hash can NOT be used as a serialNumber - we need some sort of
> *integer sequentual etc numbering*.
> 
> Point 3: Within the same time value interval, the numbering can be
"strictly
> monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
> monotonically increasing" (1,34,111,112,654). Both choices are perfectly
> suitable for the purpose. But the latter is a superset of the former, so
we
> can use just "scrictly monotonically increasing".
> 
> Point 4: The numbering counter can be "ever going", or start over with
every
> new time interval. Both choices are perfectly suitable for the purpose. So
> that the draft should NOT dictate which one to be used.
> 
> Point 5: Depending on which numbering scheme is used by the TSA, a
> SerialNumber can reach a big value. Therefore the recepient should be
> prepared to handle 4+ bytes integer.
> 
> Point 6: A TSA can switch from one numbering scheme to another, or reset
the
> counter at its will, provided that the order (uniqueness) of timestamps
with
> the same time interval is preserved (not violated). This is the only
comment
> the draft should probably bear.
> 
> Point 7: A unique Time+SerialNumber_within_that_interval combination
should
> be sufficient for audits.
> 
> To summarize all above, the [slightly modified] statement about the
> SerialNumber could be:
> ***
> The serialNumber field shall include a strictly monotonically increasing
> integer (e.g. 45, 236, 245, 1023, ...), across all time stamps or at least
> across all tokens bearing the same time value. This guarantees that each
> token is unique and allows
> to compare the ordering of two time stamps from the same TSA. This is
useful
> in particular when two time stamps from the same TSA 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 ordering is defined by the
> combination of the time value and the SerialNumber of the tokens. The
> ordering MUST be maintained even after a possible interruption (e.g.
crash)
> of the service. A recepient of a token MUST be able to handle serial
numbers
> that are greater than 4-bytes integers.
> 
> 
> Regards
> Michael

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 17:07:40 +0200 (MET DST)

> though the global uniqueness of the stamps was not the initial intent.

I cannot read brains, so I don't know what was the original idea
(not that we have drafts on the table since almost 3 years now).

From recalling the discussions, there have been SEVERAL interpretations,
one of them was that:

- a serial number uniquely identifies a time stamp.
- a serial number ONLY is used to order time stamps. 

That is the actual text. I am not against a change as proposed:
to use the time value to take part of the global order. 
Thus, the unique identifier of a time stamp and its order is at least
defined by the indicated time and the serialNumber.

On the other hand you might note that in the actual text, the
time value may not be mononotical increasing for time stamps
ordered by serialNumber. You are able to adjust your clock. Thus
the serialnumber, and not the time defines the order. Agreed,
this might create some confusion if you detect that your clock is
two seconds ahead and you have to go back, well, in the new
rule, you would create a LOOONGG second. 

Note also that the precision becomes a somewhat strange information,
how do you compare two time stamps that just happen to to be
a second aprt with a precision of 999 milliseconds.
 
> 
> Considering that the original intention for the field is still there, let me
> Point 3: Within the same time value interval, the numbering can be "strictly
> suitable for the purpose. But the latter is a superset of the former, so we
> Point 4: The numbering counter can be "ever going", or start over with every
> Point 6: A TSA can switch from one numbering scheme to another, or reset the
> counter at its will, provided that the order (uniqueness) of timestamps with
> the same time interval is preserved (not violated). This is the only comment
> Point 7: A unique Time+SerialNumber_within_that_interval combination should
> to compare the ordering of two time stamps from the same TSA. This is useful
> ordering MUST be maintained even after a possible interruption (e.g. crash)
> of the service. A recepient of a token MUST be able to handle serial numbers

This is a possible way.

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 18:01:17 +0200 (MET DST)

> 2) Distinguish betwen two time-stamps issued with the same time
These are not TWO requirements but one, since one obviously assumes
that whatever time interval is chosen, it occurs only once.

The requirement is: 'Each time stamp token has a unique identification',
and you 2 points are just two ways of adressing this.

In the current text this requirement is addressed by having a
unique serialNumber. 

Of course it could be addressed by many other things, you could even
issue a new certificate for each signature with a name component
uniqueId=nnn 

I rather see that the data retrurned respond to the following
requirements:

1 - unique identification

2 - associate a time value to an event

3 - determine an order between two events.

> parameter for one purpose only.

1 - is addressed by the serialNumber
2 - is addressed by the time value
3 - is currently also addressed by the serialNumber

> Today we implicitly MANDATE TSAs to be able to indicate which one of
This is rather explicit and whether they are issued within the same
second is not important.  

> crypto-engines use the same clock or can they use their own clock ?
Allocating a time valiue, and SIGNING the result may not necessarily happen
in the same processor. You could just start creating the unsigned
time stamp and then hand out this to several signing engines in
parallel. See below for more.

> mandate designs where all TSAs MUST always guarantee the ordering.
The time stamp does not guarantee the ordering of what they recived etc.
They simply establish the order, the TSA *IS* the authority, they don't
have to justify the order. It's like asking the clock providers to
guarantee the order they generate. 

What testing device how would you create in order to test whether
a TSA hands out time stamps in a wrong order? How would you try
to establish a proof of such misbehaviour. 

In the same way as for a clock: You just send request, get an anwser,
create a new request etc. If for the new request the order is
wrong, you have an indication of misbehaviour.   

> requirement in some environments is not at all needed.

Assume a parallel solution where the time of each of the processing
engines can have some access to a time value within let's say a
precision of n milliseconds. Each engine gets a a unique identifier
let's say 0 - 2**x-1.

Each engine maintains a local counter within this precision value, 
create time stamps of the form   time + id + counter (concatenation)
AND delay the delivery of the stamp by about 2*n.

This avoids that a client could get a time stamp, create a hash of
the time stamp, and get a time stamp of the token with a serialnumber
with is lower serial number.

> time deviation around the UTC time contained in GeneralizedTime.
genTime is the time that the TSA has allocated to that time stamp,
not more.

>        generated time stamp token.
Can you tell me a method to create a unique identifier that
is substantially faster than one that you cannot easily transform
into one having the property that the integer also grows.
 
> stamps that can be generated by that TSA within the same second."
Horrible. 
> directly machine procn application has to establish in its context whether to
accept a time stamp authority, and WHICH one; you never just say
I will accept all tokens that are signed as a TSA. 

> whatever their accuracy is.
This is USELESS: Either you have all time stamps with a different
time value, then you can compare them, or it can happen that
they have the same. Then you don't need a boolean to indicate that.

I think you will almost never be in a situation of an application
that uses one time first to determine whether a document or whatever
is conformant, i.e., a verifier would reject the time stamped data
with an indication saying: Sorry, this TIMESTAMP is not good
enough since we won't be able to establish an order between this
one and another one of the same authority. I don't believe that
a TSA would create different time stamps based on the load or
wahatever. You might consider to indicate in the request to
ask for an ordered or unordered time stamp. 

The question is there: Do we want two different types of services
or not. 

> present and set to false, then the genTime field only indicates the
nit picking: when the value is THERE it is ALWAYS TRUE.
 
I thought that we had already been beyond this discussion. We already
had consensus that the genTime is not a good value to establish the order
of two time stamps. 

> of the second Time Stamp token."
Trying to compare tokens on the basis of a precision and non unique
and arbitraily injected time values, one per vaguely defined second,
doesn't seem a good solution.

One thing to retain is whether the time stamp authority does
establish an order among time stamps or not. 

Another: Would there be any possibility to use time stamps
from several authorities? In fact this latter question is much more
interesting, and probably shows that exact ordering and TIME stamping
are two different services, anyway. Note that I didn't say
'compare two time stamps'. An application would be to get a time
stamp in order to demonstrate that you have made your tax declaration
in time. There is no requirement to have an order among two time stamps. 

> differently (in order to avoid confusion), like:

Why do you say 'WOULD BE'. This is the actual definition since 3 years,
you just change the name from serialNumber to increasingNumber. 

> numbers that are up to 16-bytes.

The latter mean just renaming of the actual text, but not what had
been discussed by Bill, Paul and Michael, i.e., it was questioned whether
it can be achieved in all circumstances, and whether it wouldn't be
sufficient to just have ordering property AND the unique identification
defined by the combination of the genTime and "that number".

Personally I prefer the current text, i.e., uniqueness and ordering
defined by the serialNumber. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 18:19:53 +0200 (MET DST)

> For this reason I support the text proposed by Michael for the serialNumber

Ooops, I forgot to mention Francois.

> should only indicate that the ordering of Time Stamps issued by the same TSA

I don't think that this observation is worth the boolean. 
Since the serialnumber field indicates a unique value within a period of a second
or so, I do not see what a TSA cannot simply be the authority of establishing the order.

People might try to misinterprete the unique identifier as order anyway.

Thus, I would propose to say somewhere either: 

- "The TSA defines order of time stamps by a combination of the genTime
   and serialnumber value."

- "The TSA defines the order of time stamps by the serialNumber value."

Or 'the order of time stamps is defined by ...'

> Stamps issued by the same TSA can not be guaranteed."
Comments about DER as in my previous message.

---

From: Michael Zolotarev <[email-masked]>
Date: Mon, 29 May 2000 10:37:35 +1000

> a second aprt with a precision of 999 milliseconds.
Peter,

You compare a time stamp with:
1. 'Real' time.
When dealing with real time, you do not compare, strictly speaking. You just
use the precision to say that "the time was somewhere around X, within +-Y
interval". This is the prime intention of the precision field.

2. a stamp issued by the same TSA.
When comparing with a stamp issued by the same TSA (2), you ignore the
precision at all.

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

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

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

If TSA2 wants to argue that the *other* TSA's precision field is a fake,
then it is the matter for another, totaly unrelated to this one, court
hearing.

Regards
M

---

From: Michael Zolotarev <[email-masked]>
Date: Mon, 29 May 2000 12:42:58 +1000

Folks,

I'll be very short:

The most significant points raised, related to what I've proposed, are:
1. By Denis about having two requirements: a) accepting the 2459 style
interpretation for the SerialNumber, and b) preserving the order.
2. By Peter that a TSA IS(!) the authority which establishes the order. So
the natural order of timestamps as being issued by the TSA is the ONLY order
we should recognize. 

A simple way to put it all together would be to:
1) Define a SerialNumber as a strictly monotonically increasing number (1,
3,47, 543) across all tokens by the same TSA.
2) Accept the point that a TSA *always* naturally establishes the order
makes the BOOLEAN flag proposed by Denis unnecessary. The draft should not
say anything about the requirement(!) of maintaining the order at all.

And guess what: the previous two point are EXACTLY what is covered by the
very original text of the draft. Exactly that! Not a bad outcome of a good
technical discussion :)

What is missing is: 

3) a 2459-styled statement about the uniqueness of TSA_Name+SerialNumber.
4) A statement *not preventing* the crash recovery handling suggested by
Bill Lattin.
4) Long integer handling.

I've stolen a sentence from 2459, and slightly modified and shortened the
original text from the draft:
**
The serialNumber field shall include a strictly monotonically increasing
integer from one TimeStampToken to the next (e.g. 45, 236, 245, 1023, ...).
It MUST be unique for each token issued by a given TSA (i.e., the TSA name
and serial number identify a unique time stamp), providing the way to build
a unique identifier to reference the token. The serialNumber also allows to
compare the ordering of two time stamps from the same TSA, which is useful
in particular when two time stamps bear the same time. 
It should be noticed that the uniqueness of the token references must remain
valid even after a possible interruption (e.g. crash) of the service. 
The clients MUST be able to handle serialNumber longer than 4 bytes digits.
***

To what I saw, this should keep the most of us happy. Or am I dreaming?

Regards
Michael

---

From: Michael Zolotarev <[email-masked]>
Date: Wed, 31 May 2000 14:20:13 +1000

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.

> Sent: Tuesday, May 30, 2000 7:25 PM
> To: Manger, James H
> Cc: [email-masked]
> 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
>