Subject: RE: Time-stamp server. TimePrecision info

From: Michael Zolotarev <[email-masked]>
Date: Tue, 30 Mar 1999 13:38:09 +1000

Michael,
Technically you are right, and I certainly agree that monotonicity is 
absolutely essential, and assumed. It is accuracy and precision which I am 
trying to address here.

I believe that when considering what might go into a time stamp, we should 
think in terms of what a user would NEED to know. After all, what matters 
for a client is
1) how trustworthy is the TSA in general, and
2) how accurate is the time in that particular time stamp.

Presenting a customer with extra details, like splitting the quality of the 
time into its precision and accuracy, may unnecessarily overcomplicate the 
issue, without giving much information anyway.

A reference to the source(s) of time data, available from the TSA's policy, 
should be a starting point for anybody who wants to know more about 
characteristics of the time.

Thinking of monotonicity:
Should the TSTInfo::serialNumber field be OPTIONAL? In addition to serving 
as just an extra proof of monotonicity, which is assumed anyway, the 
serialNumber may be the only way to resolve a 'who was the first' argument. 
If two requests arrived virtually 'simultaneously', the TSS will generate 
two time stamps with the same time value. The probability of it depends on 
the resolution of the time source used. It may be critical for the clients 
to know who was actually the first (thinking of on-line betting, auctions, 
etc). This turns the serialNumber into a mandatory field, doesn't it?

Michael Zolotarev
Technical Architect, Baltimore Technologies Ltd (Australia)

-----Original Message-----
From:	Michael Sierchio [SMTP:[email-masked]]
Sent:	Monday, March 29, 1999 3:32 PM
To:	[email-masked]
Cc:	[email-masked]'; Simon Laing; Andrew Shellshear
Subject:	Re: Time-stamp server. TimePrecision info

Michael Zolotarev wrote:
> ...
> for example, the policy might state: "The time returned will be accurate 
to
> within 100ms, and if the time-stamp server cannot
> provide this level of accuracy, it will not issue a time-stamp."

It seems to me that there are three qualities of interest for
timestamps, in increasing order of importance -- precision, accuracy,
and monotonicity.  The last is essential,  and perhaps more important
than the other two.

---

From: "Todd S. Glassey" <[email-masked]>
Date: Tue, 30 Mar 1999 19:49:43 -0800

Robert -
The precision of the timestamp is actually of key interest to few subsecond
processes existing today, but its really there for tomorrow - The real issue
is that with the amount of calendar time that it takes to get a standard in
place, the resolution of the timestamps will likely be of serious
technological import *prior* to any significant legislation or approval at
the end user level being enacted.

So address a couple of issues proactively and deal with the resolution
issue, down to microseconds at least.

Todd

-----Original Message-----
From: Robert Zuccherato <[email-masked]>
To: [email-masked]' <[email-masked]>; [email-masked]'
<[email-masked]>; [email-masked]'
<[email-masked]>
Cc: 'Simon Laing' <SECURITY/SDPL/[email-masked]>; 'Andrew
Shellshear' <SECURITY/SDPL/[email-masked]>
Date: Tuesday, March 30, 1999 7:25 AM
Subject: RE: Time-stamp server. TimePrecision info

>Personally, I have no problem with adding an optional timePrecision field
to
>specify the accuracy of the given time stamp.  I think that in some
>applications that can be useful information, particularly when the time
>stamp token will be kept for evidence purposes.  However, I really don't
>think it would be wise to make the serial number mandatory.  I agree that
in
>some situations it may be critical for clients to know "who was first" if
>the resolution of the timestamp means that they both have the same value
for
>the time.  But, I don't think that it will be critical in all applications.
>Therefore, I would rather not make it mandatory and force its use on those
>applications (and TSA's supporting them) where it is not required.
>
> Robert Zuccherato.
>
>> ----------
>> From: Michael Zolotarev[SMTP:[email-masked]]
>> Reply To: [email-masked]
>> Sent: Monday, March 29, 1999 10:38 PM
>> To: [email-masked]'; [email-masked]'
>> Cc: 'Simon Laing'; 'Andrew Shellshear'
>> Subject: RE: Time-stamp server. TimePrecision info
>>
>> Michael,

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 Mar 1999 11:10:50 +0200

> 
> How will you deal with leap seconds?
Sleep. :-)

---

From: "Todd S. Glassey" <[email-masked]>
Date: Wed, 31 Mar 1999 10:44:50 -0800

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
>