Subject: RE: Time-stamp server. TimePrecision info

From: [email-masked]
Date: Thu, 1 Apr 1999 13:03:50 +0100

Are we missing a point here?  The use of a timestamp server is to resolve
questions such as "At what time was a document signed?", "In what order were
documents signed?" or "At what time was a document received?".  A timestamp
server says "I issued a timestamp for the document at xxxx date and time".
In other words, there is not a precise time relationship between the event
potentially in dispute and the generation of the timestamp.  Appendix B of
the current draft recognises this by saying that, when subsequently
verifying a document is consistent with its timestamp, the evidence should
only be accepted if the times are "close enough (e.g. less than a few
hours)".  Whilst hours may be a bit pessimistic for some systems, one only
has to consider the likely method of communication between the requestor and
the timestamp server to realise that a [leap] second either way is
irrelevant.  Certainly, two requests issued at almost the same time will not
necessarily arrive at the timestamp server in the same order as they were
dispatched.  If we really are concerned about establishing completely
unambiguously the order in which two documents are signed, a higher level
protocol is required e.g. one in which the second document contains the
timestamp of the first one.

Paul Halliden
Director for Strategic Technology
______________________________________________________________________
Baltimore, The Square, Basing View, Basingstoke, Hants, RG21 4EG, UK
Tel: +44 (0) 1442 342 784 Fax: +44 (0) 1256 812901
http://www.baltimore.com
Baltimore is the operating name of Zergo Holdings plc 

-----Original Message-----
From: Michael Zolotarev [mailto:[email-masked]]
Sent: 01 April 1999 09:00
To: 'Tony Bartoletti'; Todd S. Glassey; Paul Koning;
[email-masked]
Cc: [email-masked]; [email-masked]';
[email-masked]'
Subject: RE: Time-stamp server. TimePrecision info

Tony,

I guess there is a neater solution to the 'gain a leap second' problem, 
using the serialNumber field of the response. If the serialNumebr is 
properly maintained by the TSS, and returned to the client, a second can 
last as long as we want it:

time:  0.21           0.22              0.23        0.23        0.23 
      0.24
S/N:  1,2,3,4...   x,x+1,x+2...    n,n+1,n+2,n+3, n+4, n+..      m,m+1...

The issue is, the problem only exists when we COMPARE two stamps produced 
by THE SAME TSS. And this is exactly where the serialNumber will help us 
out.

In a situation when you compare the stamps produced by different servers, 
or compare a stamp to a 'Golden Rolex' time, a one second difference should 
be tolerated, as the sources are not expected to be highly synchronised 
anyway.

Michael Zolotarev
Technical Architect, Baltimore Technologies Limited (Australia)

Happy Easter!

-----Original Message-----
From:	Tony Bartoletti [SMTP:[email-masked]]
Sent:	Thursday, April 01, 1999 4:31 AM
To:	Todd S. Glassey; Paul Koning; [email-masked]
Cc:	[email-masked]
Subject:	Re: Time-stamp server. TimePrecision info

At 07:44 PM 3/30/99 -0800, Todd S. Glassey wrote:
>How will you deal with leap seconds?
>

The only solution I can think of would be UGLY, but would preserve
the all-important monotonicity.  At least it would work when a
leap-second is added. (Subtracting is another matter.  You would
already have monotonicity, but differencing might be difficult.)

Add another field to the "seconds", as little as one "bit", that
is always zero except for a leap-second, when it is "one."

  E.G.   leap.seconds.milliseconds

Now, if (say) the 23rd second of this minute had to be "repeated"
(the clock is being set back 1 second, "gaining" a leap second,)
then it would first occur as 0.23.ms, and then a second later
as 1.23.ms.

Thus, the sequence of timestamps of seconds from 21 to 25 might
be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, with

    0.23 < 1.23, and 1.23 < 0.24

Losing a leap-second (should that ever happen) is another matter.
One could just drop the "missing" second as the clock advances.
E.G.

    0.21, 0.22, 0.24, 0.25

Monotonicity is preserved.  Differencing is a headache.

I wonder how they will actually deal with this.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Paul Koning <[email-masked]>
Date: Thu, 1 Apr 1999 11:04:42 -0500

I suspect that "close enough" may change over time, and hours may not
be good enough.  For example, the required accuracy for timestamps on
stock trading messages is more likely to be minutes rather than hours
even today.

In any case, it helps to be consistent.  If hours or even minutes is
the outer limit of resolution needed, them milliseconds have no place
in the timestamp format.

As for establishing order by having a second document include the
older timestamp of the first document, that's fine if I generate both
documents.  If the dispute is on which of the two of us generated our
document first, then we'll be dealing with two independent timestamps
presumably from different servers.  If they aren't synchronized to UTC 
any better than hours, the service will not be useful in a number of
interesting cases. 

Finally: it's a bad idea to make the specs tighter than what is
achievable, but it also doesn't make a whole lot of sense to make them
4 orders of magnitude looser.  Synchronizing to UTC to within a
fraction of a second is easy, and network round trip times are in the
range of seconds (actually, often way smaller than that).  Yes, that
opens the question of how you handle leap seconds.  One solution is to
loosen things up some more, but going from seconds to hours is really
not necessary.

	paul