RE: Time-stamp server. TimePrecision info

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxxxxx>]

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?