Subject: Re: Timestamp: 04: comments

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Nov 1999 17:24:20 +0100 (MET)

The current text always requests for two serialnumber sn with times t: 

   sn1 > sn2 ==> t1 >= t2

Thus the following seems to be the original idea:

- in order to compare two stamps from the same TSP,
  one can use the serialnumbers.

- Time values can be used to compare against some external date/deadline. 

In the current draft there is no definition of the purpose and the
possible interpretations of accuracy:

Assume a time t and an accuracy a.
- Does this mean that the actual time is somewhere in a interval
  t-a or t+a? 
- Or it is at least at t but may actually be later up to t+a
- or earlier back to t-a? 

What does accuracy tell about serial numbers? Can I have for example

   sn1 > sn2  and  t1 < t2+a/100  

What can be said about two time stamps with

   sn1 > sn2   and t1 - t2 < a/100 

and what can be said about a time stamp with t1 when comparing it
to a deadline t and   |t-t1| < a/100
which is the same as comparing time stamps from two authorites
with different or identical accuracy.

Peter Sylvester

---

From: Simon Tardell <[email-masked]>
Date: Tue, 9 Nov 1999 18:00:30 +0100

> > Accuracy:
> > Why is 1 second the default?  This seems an arbitrary 
> figure.  There is no
> > reason why clocks will have this accuracy instead of any 
> other.  If you
> > really want 1 s as the default, use the ASN.1 syntax to 
> specify this:
> > 	accuracy [0] Accuracy DEFAULT seconds:1
> > I suggest keeping the field optional, but with no default 
> value.  If absent,
> > no statement is made about accuracy (2 tokens from the same 
> TSA can still be
> > meaningfully compared).
> 
> If you don't make a statement about accuracy, you cannot necessarily
> compare tokens even from the same TSA.  It might be reasonable to
> think you can do this IF the TSA hasn't rebooted in between.  (Then
> again, a TSA implementer might also reasonably interpret "no
> statement" to mean "NO statement at all"...)  But if you don't have a
> known accuracy, that means you may not know what the clock will do
> across a power glitch (because your OS timekeeping clock and your NV
> clock may not match, and by not making an accuracy statement you're
> making no guarantees about any bound on that offset).

Which still doesn't answer the question why the default accuracy should be
one second. It might make sense in imperial units, but certainly not in
metric.

Next it says that "By adding the accuracy value to the GeneralizedTime, an
upper limit of the time at which the timestamp has been created by the TSA
can be obtained. In the same way...". This is of course utter nonsense. The
time we discuss here is a quantity subject to a physical measurement about
which nothing can be said with certitude. What is missing is a confidence
level. It should say something along the lines of "The time at which the
timestamp was created is between genTime-accuracy and genTime+accuracy with
a confidence level of 90%" (if we can agree on a confidence level of 90%,
which I think we cannot). The level of confidence (a percentage) could
optionally be bundled with the length of the confidence interval
("Accuracy").

On a general note (regarding accuracy), there is a problem with syntax in
that if a TSA would like to time stamp something with less accuracy than a
second it has to go through hoops. For example, lets say it matters that may
matter only what day a document was received at a registrar but not at what
time that day. Then it would be superfluous to give any hours and minutes,
and in fact it could be desirable to not to (e.g. we don't want to make it
easy to reconstruct an electronic track of a person just because we are a
TTP. To get around that the TSA would have to set the timestamp to
YYYYMMDD120000Z (or rather 12:00:00 local time translated to Z) +/- 43200 s
(12 hours). It would have been more natural to set the timestamp to (just)
YYYYMMDD+ZZZZ. However, in their infinite wisdom the founding fathers made
GeneralizedTime not general enough to be able to represent that.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

---

From: Michael Zolotarev <[email-masked]>
Date: Wed, 10 Nov 1999 08:13:47 +1100

> optionally be bundled with the length of the confidence interval
	MZ:
	And what exactly would you do with the confidence-level encoded
accuracy? Take the token to the court and try to prove that the time was
"15% more likely to be the TokenTime+1ms then the TokenTime+2ms ( for some
given accuracy and confidence level)? 
	More important, it does not prove anything anyway - the actual time
still could be anywhere within the interval, taking a single token as a
case. Which is a case. Unless you have a nice collection of a thousand
tokens, and assert the fact that at least 900 of them has the time within
the range.
	For the sake of a mental exercise, and for all practical means,
wouldn't it be sufficient to just say that "the exact time was within the
interval"? Which of course corresponds to the confidence level of 100%,
practically speaking. If your confidence level is low, then you simply
increase the interval, to bring the confidence back to 
	the 100% mark.

---

From: Simon Tardell <[email-masked]>
Date: Wed, 10 Nov 1999 10:35:48 +0100

> > can be obtained. In the same way...". This is of course utter
nonsense.The
> > timestamp was created is between genTime-accuracy and genTime+accuracy
> > with a confidence level of 90%" (if we can agree on a confidence  level
of 90%,
> accuracy? Take the token to the court and try to prove that 
> the time was "15% more likely to be the TokenTime+1ms then the 
> TokenTime+2ms ( for some given accuracy and confidence level)?

That is not the question you would ask in court,is it? The question is
rather something like "Was the timestamp before (or after, as it may be)
this time, neyond reasonable doubt.". The meaning of "reasonable doubt" is
"at some commonly accepted confidence level" except in legalese.

> 	More important, it does not prove anything anyway - the 
> actual time still could be anywhere within the interval, taking a single 
> token as a case. Which is a case. Unless you have a nice collection of a
thousand
> tokens, and assert the fact that at least 900 of them has the 
> time within the range.

Sorry, I don't grok that. Yes, the real time can be anywhere in the
interval. And it can be outside the interval (with a probability of
1-confidence level). And that has nothing to do with having one or thousands
of timestamps. On a side note: Taking additional timestamps from the same
TSA doesn't buy you anything since it is safe to assume that the accuracy is
mainly a systematic error that changes slowly (i.e. comes from bad frequency
calibration "drift").

> interval"? Which of course corresponds to the confidence 
> level of 100%, practically speaking. If your confidence level is low, then
you simply
> increase the interval, to bring the confidence back to the 100% mark.

Except that confidence levels of 100% are unphysical, and this is a
measurement of a physical time. Unless, of course, you set your accuracy to
15 billion years or so.

Simon.

Simon Tardell, Software Architect, iD2 Technologies,
[email-masked]
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999