Subject: Re: Time-stamp server. TimePrecision info

From: "Todd S. Glassey" <[email-masked]>
Date: Fri, 2 Apr 1999 13:46:17 -0800

Denis, Robert , I totally disagree

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

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?

>>Todd Responded: OK Fine, but humor me - what's the harm in being able to
represent them?
>
> Denis: The TSA gets the clock first and then signs. I do not know any
hardware
>capable of signature in the micro-second range.

Denis, The speed of the signature generation process today, has only a small
amount to do with the time the timestamp process generation model takes, so
this is not true. The signing process will be addressed by large signing
engines for bulk document processing and for end user or POS style
documents, the onesee twosee game - who cares how long it takes.

And as to the issue of microseconds or nanoseconds, the physicists, have had
time distribution networks with IRIG-B timecode protocol distribution
facilities and the like for some years now. We in the IETF standarized on
NTP and it supports 2 to the -32nd power resolution, so why is this argument
even happening?

We can commercially distribute time down to the nanosecond if we desire to.
Timebases to support these requirements are available commercially today
from Datum, HP, TrueTime, Odetics, Guide Technologies, and a  wealth of
others. Ay commercial operator could easily have their own Cesium reference
for between $40K to $60K. IBM and HP have both regularly included them as an
option with the mainframes they offer.

As an example of this technology availability, Datum and others have these
Cesium Heads with built in GPS Disciplining and all the drivers you need.
Datum calls their's the GPS+ and from my side, this is a no brianer, if I
need a certifiable timesource as a policy anchor for a PKI, I buy one of
these systems and put it under contract to NIST to calibrate.  POOF!!!, the
resulting system, coupled with a rigid BCP model provides a  truely credible
Local Timebase that will easily pass any SAS70 and/or CS2 Audit if operated
correctly.

>The transmission delay is also
>quite variable.

...and not directly relevent to the question at hand. While the transmission
delay is specific to the time it takes to get the event notification to the
stamping engine. The only relevency here is when the event actually reached
the stanmping agency itself. The amount of time of takes is a function of
the transport and its utilization... and these issues will change as
technology is evolved and the stamper is right sized for its loading.

As to the existance of the transmission delay issue, well this is the plight
of any distributed agency, the hysteresis and latency of the transport being
what it is, you build end user models that take this into account. [here we
are again, back to the end user models and how important they are...]

>The harm is giving false impression of precision.

No Sir - I really feel strongly here that the actual harm is in not building
a system that is insensitive to hiccups in the technological landscape.

Denis, let me know if I read you wrong, but the general tone of your retort
here leads me to believe that your model is specific to  SW only based
systems, layered on traditional clock chips and the OS  TOD Services. My
personal feeling is that this is one of those instances where SW only models
are limited, but that hybrid systems abound and they are not, and the SW
only ones will get better in time so in closing,  Gentlemen - the timebase
representation should mirror NTP 4.0's as a baseline.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Apr 1999 18:18:46 -0500

Todd,

I have no idea what the phrase "a policy anchor for a PKI" means.  As a
provider of CA services and technology, I can assure you that none of my
clients has ever felt the need for such a precise time base wrt certificate
or CRL processing.  So, I am puzzled by your terminology, insofar as it
references PKIs, and suggest that you don't continue to use this phrease
unless you can explain what it means and how it relates to the current
discussion.

Separately, I am willing to believe that there may be applications that
require the sort of precision you're suggesting, but I don't recall seeing
them described here yet.

Steve

---

From: Dan Geer <[email-masked]>
Date: Fri, 02 Apr 1999 22:36:17 -0500

We argue most about mechanism when we are least
reconciled with respect to requirement.  Perhaps
I can provide a succulent target:

  The requirement for time is event serialization
  sufficient to support an economic level of recourse.

Unremarkably, two events within the error band are
definitionally simultaneous -- the NYSE tick is
not micro-seconds but rather macro- and many events
are declared simultaneous in the interest of fairness,
to take a central example from high-value commerce.

Is there an economist in the house?

--dan

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 06 Apr 1999 10:36:33 -0700

It may be true that, out of a sense of fairness, some events are
considered "simultaneous" if they occur within the same second,
or minute.  But 100 years ago, that may have been "days or weeks".

I see technology rocketing ahead so fast my head spins.  Try, if
you can, to imagine processor speeds and typical transmission
bandwidths 1000 times greater than the fastest today.  It will
not be too far off.  So I must concur with those who ask "What
harm in allowing microseconds, or even nanoseconds, to be
representable in the protocol?  We may not (yet) have many
applications where such resolution (in signatures, certs, and
authentication) is critical.  But can the same be said for
"hours"?  Generally, no.

Whatever you do, do not make a determination based upon saving
a few bytes.  Such a decision will appear laughable in 10 years.

___tony___

>Is there an economist in the house?

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