Subject: Re: Time-stamp server. TimePrecision info

From: "Todd S. Glassey" <[email-masked]>
Date: Thu, 1 Apr 1999 07:14:17 -0800

Hey all, Sorry about the "Know Idea" pun - I thought the typo was funny

-----Original Message-----
From: Todd S. Glassey <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, March 31, 1999 1:29 PM
Subject: Re: Time-stamp server. TimePrecision info

>Hey Paul -
>Does this mean that we are going to use NTP for timestamping? (This is not
>such a bad idea and Michael McNeil and i suggested just this with the two
>drafts on PKI extended NTP we did with Dave Mills),
>
>The real issue is how timestamps are derived from a local timebase and that
>the local timebase has to deal with Leap Seconds somehow... The current
>Entrust protocol toolkit assumes that the time data it is handed by the
>underlying OS is "legally sufficient" to use as core for timestamping-  but
>the problem here is that NO COMMERCIAL OS's know about Leap Seconds and so
>using the TOD clock is a gamble... that the BCP addresses these and that
the
>timebase services are managed out of band.
>
>BTW, as a simple example of how most people just believe this has already
>been handled, there is a paragraph in the TimeServe addition to the NT
>resource kit (timeserve.txt file) that states the accuracy of the NT clock
>is at best .45S/day. That in and of itself is an issue since the PC and
>Server manufacturers are all worried about the bottom line so they use the
>most "cost effective" (from their $$$ viewpoint) clock chips and the like.
>
>My personal feeling is that without some BCP that has one dialing into the
>ACTS servers at NIST on a once daily or twice daily model, we have know
idea
>what time it really is.
>
>There are no secure NTP servers out there yet but we are woking on this
and,
>well - Stay tuned for the first one's announcement in the next 45 days.
>
>Todd
>
>
>-----Original Message-----
>From: Paul Koning <[email-masked]>
>To: [email-masked] <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Date: Wednesday, March 31, 1999 10:03 AM
>Subject: Re: Time-stamp server. TimePrecision info
>
>
>>>>>>> "Todd" == Todd S Glassey <[email-masked]> writes:
>>
>> Todd> How will you deal with leap seconds?  T.
>>
>>The NTP RFC (RFC 1305) has an excellent discussion on this and the
>>approaches it describes would be good to use.  In particular, it
>>suggests using a two part date/time coding (day separate from
>>time-in-day).  That way the existence of leap seconds merely increases
>>the range of the second field by one.  (Analogy: if you sent the
>>timestamp as yyyymmddhhmmss.ssss the impact is merely that ss can be
>>from 0 to 60, not 0 to 59.)
>>
>> paul
>>
>
>

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 1 Apr 1999 11:27:17 -0500

One point that I would like to clear up.  The present timestamping draft
does not consider resolution of hours to be sufficient.  The reference to
resolution of "less than a few hours" comes from an informative annex giving
an example of how the protocol could be used.  The resolution required by
any particular application is not considered in the main document.  Remember
this document describes just the protocol to be used by the TSA.  

That said, I agree with Denis.  I do not see the use of microseconds to be
especially useful within this protocol.

	Robert.

> ----------
> From: 	Paul Koning[SMTP:[email-masked]]
> Sent: 	Thursday, April 01, 1999 11:04 AM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: Time-stamp server. TimePrecision info
> 
> 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
>

---

From: "Todd S. Glassey" <[email-masked]>
Date: Thu, 1 Apr 1999 09:05:03 -0800

Thanks for the opening... I was wondering how to work this in...

There is an even bigger issue here for the use model. The actual end use of the system you are describing, the document timestamper/verifier is a end user application of timestamping only. There are many other uses of certifiable time than just adding non-repudiation. Certain IA control processes and other industrial control apps that are time based need this resolution as part of their control and messaging processes.

However the real issue is how to represent a timestamp in a manner conducive to the most general purpose use models. Also to make this same system work everywhere. That's why we need the token structure defined.

The bottomline is that subsecond accuracy is required for a growing number of industrial, commercial, and financial applications and because of the complexities of integrating certifiable timebases into processes and deliverable technologies, clean and reliable timebase services are better off being deployed everywhere. 

Todd 

    -----Original Message-----
    From: [email-masked] <[email-masked]>
    To: [email-masked]' <[email-masked]>
    Cc: [email-masked] <[email-masked]>
    Date: Thursday, April 01, 1999 8:19 AM
    Subject: RE: Time-stamp server. TimePrecision info

    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: "Robert Klerer" <[email-masked]>
Date: Thu, 1 Apr 1999 16:36:23 -0500

Sequencing can be important.  It is correctly stated that establishing
precise sequencing across servers may not be achievable, but if a
non-arbitrary ordering needs to be established, the availability of
sequencing on a single server can be useful.  (Whose bid got in first at the
sellers choice of server).  If the loser losses because of latency, they
should buy a better network service.

-----Original Message-----
From: Paul Halliden <[email-masked]>
To: 'Paul Koning' <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, April 01, 1999 1:15 PM
Subject: RE: Time-stamp server. TimePrecision info

>
>
>I quite agree that hours may not be close enough in some cases. The point
>is
>that the spec specifically talks about a range of communication techniques
>between requester and TSS including e-mail which has a notoriously variable
>transit time.  The timestamp gives no indication about how long the
>requester's message took to get to the timestamp authority.  Even if it
>did,
>I don't believe that the authority would be in any position to know
>reliably
>at what time the request was made.  Thus anyone who relies on a sequence of
>timestamps to indicate order is deluding themselves if they want precision
>anywhere near the transit time of the network(s) used. I would expect the
>timestamp authority's policy to say its service was unsuited for such
>precise sequencing and that some other technique for establishing the
>sequence of transactions should be used.
>
>Paul
>
>
>
>From: Paul Koning [mailto:[email-masked]]
>Sent: 01 April 1999 17:05
>To: [email-masked]
>Cc: [email-masked]
> - att-1.htm

---

From: "Todd S. Glassey" <[email-masked]>
Date: Fri, 2 Apr 1999 14:00:39 -0800

-----Original Message-----
From: Paul Koning <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Friday, April 02, 1999 11:10 AM
Subject: Re: Time-stamp server. TimePrecision info

>>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
>
> Stephen> Denis and Todd, Do we agree that the timestamp represents
> Stephen> the point at which a signature was applied, independent of
> Stephen> transmission delays and signing speed?
>
>It seems to me it can only possibly mean one thing: it is the time
>when the clock was read.  :-)  That time is later than the generation
>of the request and earlier than the generation of the signature.

Within a few microseconds, assuming a vertical stamping model, yes it would
be the time when the agent got the event notification and responded.

>
> Stephen> If so, then I would
> Stephen> not agrue against very fine granularity time stamps on thae
> Stephen> basis of thise delays. Instead, I would argue that there is
> Stephen> a false sense of precision being implied, and that we're
> Stephen> better off just relying on the sequence number to serialize
> Stephen> time stamps issued by the same server within the same tick.

Don't limit the granularity of the timestamping facility by the OS
implementation today. They are all broken with regard to this, but that will
change when people come to realize how important "secureing their trust
anchors" is and how critical the timebase is part of that.

Certifiable timebases will become the metranome of the business to buisness
extranet and corporate audited infrastructure.

>
>It sounds like you're arguing that only significant digits should be
>present in the timestamp.  The problem with that is that the server
>has no way to do that, if you want to include network delays as part
>of the tolerance implied by the digit count.

This network delay weighting model then becomes the policy of what your
timestamp represents. The total end to end time, or the time the "reciever
agent" acknowledged the recepit of the event?, either way its specific to
the policy and services structure of your stamping process, i.e. the use
models...

>
>Better to indicate or document the various error sources explicitly.
>Those the server knows about it can report if a tolerance (precision)
>field is added.  Those relating to network latency the server cannot
>know but the client can (bounded by delay between request and
>response).
>
> Stephen> If one believes that the time stamps have to represent finer
> Stephen> granularity because they will be compared with time stamps
> Stephen> from other servers, then there's a lot of work to do to
> Stephen> convince me that the resulting synchronization is feasible,
> Stephen> and that there is a legitimate need for such.  Obviously the
> Stephen> world lives with rather coarse precision and accuracy for
> Stephen> lots of business time stamp operations today.  maybe we need
> Stephen> some additional, credible, motivating examples.
>
>Synchronization of two devices to within a fraction of a microsecond
>is perfectly feasible today.  Any GPS nav box does exactly that.

GPS based NTP servers are in the 2.5K range and you can get a high quality
one with a rubidium oscillator for an addition 5K or 6K. Cesiums is cheap
these days if you are a bank. These days a medium performance router is more
costly than an atomic clock setup for a network timebase. Since locally
operated Atomic sources can provide 1x10-12th accuracy over a year and if
they are audited by NIST. With a setup like this, you should be able to run
a local source that stays  provably, within a few nanoseconds of TAI/UTC.

>
>Given that it costs nothing to allow the extra digits, why is there
>such a concern about doing that and future-proofing things?

Amen!

Todd

---

From: Robert Zuccherato <[email-masked]>
Date: Fri, 2 Apr 1999 20:54:51 -0500

Todd;

> ----------
> From: 	Todd S. Glassey[SMTP:[email-masked]]
> Sent: 	Friday, April 02, 1999 4:46 PM
> To: 	Denis Pinkas; Todd S. Glassey
> Cc: 	Robert Zuccherato; [email-masked]; 'Paul Koning';
> [email-masked]; Mike King
> Denis, Robert , I totally disagree
> 
> >> >That said, I agree with Denis.  I do not see the use of microseconds
> to
> be
> OK, so what exactly are the end uses of the protocol then? - I mean the
> specific end use models. You must have them in mind if you can say that
> Microseconds are not relevent. What I need to know is how am I going to
> use
> this protocol?
> 
As the draft states, the main purpose of this service is "to verify that a
digital signature was applied before the certificate was revoked thus
allowing a revoked public key certificate to be used for verifying
signatures created prior to the time of revocation".  Since CRLs only use
either UTCTime or GeneralizedTime, even milliseconds may not be relevant for
this purpose.  

However, as the draft states "An exhaustive list of possible uses of a TSA
is beyond the scope of this document."  Thus, we included millisecond
accuracy.  I am not really opposed to including microsecond accuracy.  I
just do not see the need for it.

	Robert.

---

From: "Todd S. Glassey" <[email-masked]>
Date: Fri, 2 Apr 1999 20:58:52 -0800

Robert - this is a dodge. I am not looking for an exhaustive list, I am
looking for the one you designed it for. You built a suite of routines
here - so how and what did you intend to use them.

Todd

-----Original Message-----
From: Robert Zuccherato <[email-masked]>
To: Denis Pinkas <[email-masked]>; 'Todd S. Glassey'
<[email-masked]>
Cc: [email-masked] <[email-masked]>; 'Paul Koning'
<[email-masked]>; [email-masked] <[email-masked]>; Mike King
<[email-masked]>
Date: Friday, April 02, 1999 7:41 PM
Subject: RE: Time-stamp server. TimePrecision info

---

From: Paul Koning <[email-masked]>
Date: Mon, 5 Apr 1999 13:43:56 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Paul,
 >> You can also apply the same sort of example to real time systems.
 >> Consider a distributed real time control system.  Suppose
 >> something goes wrong, and after the fires are put out and the bits
 >> of concrete have been bulldozed away, people start picking through
 >> the logs trying to figure out what sequence of events made things
 >> blow up.  You need fine grain timestamps so you can unambiguously
 >> follow the directed graph of cause and event.  For real time
 >> systems, sub-millisecond timestamps are perfectly meaningful.

 Stephen> That's more of what I had in mind when I asked for a
 Stephen> concrete example.  However, in a realtime system, it is not
 Stephen> clear that the audit trails need or could tolerate the
 Stephen> overhead of signing every log entry.  They might need
 Stephen> accurate local clocks for the logs, but do they need time
 Stephen> stamps from network accessible servers?

Quite possibly yes, since such analysis may end up being done in
court.  Whether the overhead is acceptable depends on how much is
riding on it, and how big the overhead actually is.  I'm suggesting
that with modern hardware it's not that high and dropping fast.

	paul

---

From: Michael Zolotarev <[email-masked]>
Date: Tue, 6 Apr 1999 12:08:21 +1000

Thank you, Stephen.
This looks like a very reasonable point.

Just think about it - aren't we are getting carried away from the main 
purpose of Time Stamping? Which is, of course, TIME STAMPING. Which is to 
define a TTP to provide "a proof-of-existence of a message at an instant of 
time". Old good PKIX, non-repudiation, etc, etc

Instead, what the discussion is now getting dragged into appears to have 
more to do with some kind of Real Time Mission Critical Globally 
Distributed Secure Ultimate Time Synchronization Service.

Yes, there are a lot of requirements which fall under the umbrella of the 
abovementioned RTMCGDSUTSS :), and there are solutions for this. And 
today's mail can serve as an excellent reference point for anybody who 
would like to find out about that class of systems. And the issue may well 
worth its own discussion thread.

But is it what has been originally set as a goal of Time Stamping?

If the answer is Yes, then we should change dramatically our original pa  
radigm. My own coordinate system would definitely have to undergo major 
tuning up.

Otherwise, should we concentrate on identifying the scope of the system, 
based on classical boring Use Case approach?

Once we are clear on the scope of the system, we would be much better off 
thinking about TS Token, precision and other unarguably important issues.

And of course, the fact that TSS may not happen to be exactly what NTP and 
other services are for, does not preclude borrowing solutions/approaches 
that are already out there.

Michael Z

Stephen wrote:
>in a realtime system, it is not clear that the audit trails need
>or could tolerate the overhead of signing every log entry.  They might 
need
>accurate local clocks for the logs, but do they need time stamps from
>network accessible servers?