Subject: Re: Time-stamp server. TimePrecision info

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

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

>Paul,
>
>> 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.
>
>A concise definition, but I think an unsatisfying one.  If the goal is to
>compare time stamps from two servers who have very pricesly synchronized
>clocks, as you note is easy to do with GPS, then internal processing delays
>at each server seem likely to vary so much that very fine grained time
>stamps cease being maeningful in many applications.  That's even before
>asking about network delays.  So, I'm back to the last part of my previous
>message.  Give us some examples where very fine grained time stamps from
>different (synchronized) servers are meaningful.

off the top of my head here are four

#1)    Telcom Backbone management systems, tightly coupled cluster systems
maker up what are now virtual switches.

#2)    Event Simulation and Decision Support Management

#3)    Precision control of mechancial processes, like operating a high head
water cam on a power plant or the like, or operating a vacume control
sputtering system for semiconductor processing.

#4)    Market Trading and Control of trading processes. - Many systems are
now tightly coupled fault tolerant clusters and these systems need this
"ridiculous" level of precision in their timestamping since they are not
connected in the same way we usually connect together (lan/wan/man etc).

>>
> <snip>
>
>>
>>Given that it costs nothing to allow the extra digits, why is there
>>such a concern about doing that and future-proofing things?
>
>Just because we CAN do something syntactically, that does not mean that we
>should.  I'm a firm believer in trying to understand the implications of
>the protocols that we develop, not just working on the details of the
>protocols.

Then you have to answer the question "how is this thing going to be used" in
order to know what it needs to be able to do.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 1999 11:15:58 -0500

Todd,

>maker up what are now virtual switches.

I work for a large telecom company, but I'll have to ask for more details
here, as this doesn't yet make sense to me.

>#2)    Event Simulation and Decision Support Management

Distributed simulation systems don't seem to need this, based on the work
I've seen re DoD simulators.

>sputtering system for semiconductor processing.

I see why these folks need precise time, but not time stamping.

>connected in the same way we usually connect together (lan/wan/man etc).

Definately not true.

Perhaps I was not specific enough in my request.  I'd like to see examples
where someone actually explains the need, not just cites a topic.  And, as
Roberto points out, we're PKIX and so our initial focus was motivated by
the time scale that we use in certs and crls.  We might refine this to
support greater precision, but I am not inclined to do so based on what I
have heard so far.

What I dl NOT want to see is the creation of a standard with provision for
very precise time stamps that some vendor uses to tout the superiority of
his product vs. another due to increased precision, irrespective of the
significance of the extra digits or the relevance to the applciation
context.

Steve