Subject: RE: Timestamp: TSA Response serialNumber Field

From: "Manger, James H" <[email-masked]>
Date: Wed, 31 May 2000 11:30:15 +1000

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

You don't need this property.  Each genTime value is a measurement of UTC
with a given uncertainty, but successive measurements are not independent.
The measuring instrument is a clock and I assume it only increments.  So a
later measurement is never less than an earlier measurement regardless of
the uncertainty.
    genTime1 = 6:45 +/- 8
    genTime2 = 6:47 +/- 8
genTime1 was issued before genTime2 because genTime1 < genTime2.
The uncertainty, +/- 8, is important only when comparing the time to another
clock (e.g. a timestamp from another TSA or some external event such as a
deadline of 7:00).

Your "huge server" scenario is interesting, but I don't think it changes the
arguments.  The genTime values from a TSA can be the *definition* of order.
With a huge server, the order requests hit the front switch may differ from
the order they are finally processed (after being in different queues in
different crypto engines), but which order is correct?  I am not even sure
that "hit the front switch" is a simple concept given that a request is many
octets, perhaps split over many IP packets with any number of TCP/IP
interactions.
 
We could have two uncertainties: (1) the uncertainty between genTime and
UTC; and (2) the uncertainty between "simultaneous" measurements by the TSA.
If a TSA has many clocks (e.g. one for each crypto engine) the second value
is the uncertainty in synchronisation between its own clocks.  However, I
don't think this (or your BOOLEAN) is necessary.

Peter Sylvester,
 
> What kind of decision can you make based on that? [23h59'59'' +/- 2'']
 
Probability that timestamp was issued before 12h00'00''
    = Pr(x < 12h00'00'' | x sample of X =
Normal-Distribution(mean=23h59'59'', sd=2''))
    = Pr(x < 0.5 | x sample of X = Standard-Normal-Distribution)
    = 0.69
=> There is about a 70% chance that the timestamp was issued before the
deadline.  If this is not good enough the user should have got an timestamp
earlier or used a TSA with a lower uncertainty.
If you want a black-and-white decision you could
(A) pick a confidence level, say 60%, and accept any timestamp that has at
least this probability of being before the deadline; or
(B) get your own timestamp from the same TSA at the deadline and accept
timestamps issued before yours (regardless of the actual time and
uncertainty listed in your timestamp).
 
UTC is a continuous quantity.  Any measurement will have an uncertainty.
Any comparison involves a confidence interval.  This is unavoidable.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 May 2000 09:29:55 +0200

James,

I will pick your message to answer.

> The measuring instrument is a clock and I assume it only increments.  

No. Your are making an assumption which is not true. You are
assuming that the TSA is using a single clock. This is not
necessarilly the case with the huge server scenario. Paul gave the
right answer:

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

Denis

> So a

---

From: Paul Koning <[email-masked]>
Date: Wed, 31 May 2000 10:22:14 -0400 (EDT)

>>>>> "Manger," == Manger, James H <[email-masked]> writes:

 Manger,> ...We could have two uncertainties: (1) the uncertainty between
 Manger,> genTime and UTC; and (2) the uncertainty between
 Manger,> "simultaneous" measurements by the TSA.  If a TSA has many
 Manger,> clocks (e.g. one for each crypto engine) the second value is
 Manger,> the uncertainty in synchronisation between its own clocks.
 Manger,> However, I don't think this (or your BOOLEAN) is necessary.
 
I agree with that conclusion.  A clean way to solve it is to say that
the rule for comparing timestamps with their accuracy (i.e., the
partial order we've been talking about) applies to pairs of timestamps
no matter what their source.  In other words, it applies to a pair
from a "single" source just as it does for timestamps from two
independent TSAs.  That's conservative (it is probable that the
relative synchronization of multiple internal clocks is tighter than
the synchronization to UTC) but I can't see that it hurts a whole lot.

This takes care of the "large TSA" issue.  It also takes care of the
restart problem, where an "internal" clock is volatile but refreshed
from a non-volatile reference at startup.  That's of course the common
PC model, and may well fit other types of devices too.  Admittedly it
is not all that likely that a box can restart in less time than 2 *
accuracy, but it doesn't hurt to cover that case.

Hm... if you assume a large modular TSA, should you assume it has a
single global "sequence number" generator?  Of course, if that data
item is just a unique ID (e.g., hash) as has been argued, this is a
non-issue.  If it is an increasing number, though, then it has to be a
single global resource, which would also be problematic in this
scenario.  Not as much as tightly synchronized clocks, admittedly.  

	  paul