Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition

From: Peter Sylvester <[email-masked]>
Date: Tue, 3 Aug 1999 19:14:15 +0200 (MET DST)

This message is not a flame, there is no intention for any personal
attack, although it might sound like so in some comments, 

> Denis to using your words - Creating yet another representation of time in a
> PKIX tool also 'seems pointless'.

BERT provides yet another representation of 
'time' <--> GeneralizedTime in PKI, or date in rfc822
'identifiers' <--> generalname in pki
'policyidentifier' <--> object id 
'signature'     <--> existing structures in pki+object ids for algorithms

> 
> Lets think of standardizing the representation of time to a format that will
> interoperate across the greatest number of PKIX applications. I suggest that
> the UTC 96 representation format from the BERT draft be adopted as the use
> standard. (McNeil - You want to jump in here?)
it seems that some people have forgotten why we have leap seconds inserted
sometimes (and not additional leap minutes). The intension is to make
them invisible in real life applications. Or better, don't fix all
real life applications by adding code to support leap seconds because 
you just need them once per 5 years. 

> 
> And Denis -  partner - as to what "you" personally think is the greatest
> resolution of time necessary, I look to that great Tommy Lee Jones line from
> MiB (Men In Black)  that went something like: "1500 years ago mankind
> thought that the Earth was the center of the Universe. 500 years ago mankind
> new the earth was flat. 15 minutes you knew you man was alone here on
> earth....think what you'll know tomorrow".
The earth is the center of the universe (as Bert seems to tell us.)

> My point is that we don't know all the uses yet - and if we limit ourselves
> to representing time at the same level of granularity that the OS designers
> thought was relevant - Ahahahahahahah - Well it just seemed a bit funny
> since we already know that it is not clean enough. If you don't believe me
> call the stock exchanges and find out what and how they use
> timedata/timesources for.
Event arrive in ORDER, and the only relevant thing is the order, and not the
absolute time value. 

> 
> I have, and was surprised to find out that most of them have local Atomic
> Clocks that they reset daily or more often to NIST prime. These systems are
> good to 1*10e-12 Sec/Year which is clearly cleaner and finer that what we
> are proposing.  They have the most furious use of timestamping yet today and
> to them milliseconds are critically important. Especially in Digital Agent
> Models, where a number of agents are competing for common services in a
> control or market pool. The bottom line is that very fine granularity is
> absolutely necessary, if for no other reason than that the OS vendors
> choked.
Put a broker into a shuttle and look at the consequences. The only requirement
is the order of two events, and sorry, you can give any resolution you want,
something can arrive at 'the same moment' using whatever clock you use as
external source, and you just decide who came first. A high resolution 
real time counter counts faster that you an make personal decisions, thus
it is usable as a pure counter (and just gives an addtional convenient 
information). 

> 
> So what are the real issues here ? - It seems that we are going to choose a
> limiting criteria based on the fact that there is
>     o-    currently substantial propagation delay in a Open Networking
> Models (dependant on the topology of course) and this sets the baseline for
> the precision in remote-timestamping model's "credibility envelope".
>     o-    and that the OS is only capable of 1 Sec resolution in most cases
>     o-    and in almost all cases, the TOD services that create this
> granularity are based in some cheap Clock Chip that the BIOS or otherwise
> sub-OS services provide
>     o-    and most importantly, that there is really no real way to resynch
> the clocks properly in the field. [which simply isn't true BTW]
None of these 'facts' should be used. They are not necessary: 

- one second resultion is proposed only because 
  - we first overlooked that there was a subdivision (remember that the
    initial draft just had an integer indicating milliseconds.
  - existing certificats use seconds. I don't see a problem, a CORRECT
    comparison of GeneralizedTime isn't rocket science (leaving apart
    Challenger and Ariane 5).
   
> 
> What this entire thread seems to overlook or negate is that:
>     o-    even in SW only systems,  that sub-millisecond precision time is
> easily distributed in networking models. IRIG-B timecode and NTP have been
> doing this *for decades* already.
No it doesn't in principle. waht it negates is that real applications and 
HUMAN decisions need a higher precision. Tell me a real application with
non-repudiation where you really need more than counting within the smallest
observable time period for a human being (a second, or may be a little bit less
than that). (if not, see my last comment).

>     o-    Also that timestamping is often going to be done differently that
> the TS draft suggests, that is to say commercially I believe that the TS
> services will commercially live on the same platform that uses them, per
> say, rather than some Trusted-Third Party external third system. They may
> have a secondary proofing-stamp process happen at the "Archive Server" for
> the TST's, but that in reality that the system has to work not only embedded
> as we have proposed, but externally as you have proposed as well.
The scenarios is a little bit more complex. A time stamp service and any
form of notarisation service can be operated in a chain. Somewhere a clients
asks some local service, the local service either provides it directly, or
has to be backed up by another external service or more of them. 
BTW: Where is the external reference for spatial coordinates? I am here,
and I can see the top of the Eiffel tower, do you trust me?

> 
> To my mind, what this means is that the issue of network delay is not always
> applicable in the timestamping models, and this should be addressed by a
> uniform model that supports *all* use cases. Also that anyone can add a Time
> Board to a system if they need better grades of local time that can survive
> a reboot. Even the people that commercially depend on GPS for time (poor
> fools), get better time than the OS's can track in most all instances.

It seems that you misunderstood time and time stamp. I can make a time stamp
'number 9986557555787687', it comes before  'number 9986557556787686', I
record somewhere that I have issued time stamp X just at some time, in
order to establish a convenient way of using it. The time stamp is the stamp
of MY TIME, and nothing more.
 
> 
> My point is that there needs to both be interoperability in timestamping, as
> in all PKI, and in particular in the representation of the other cornerstone
> trust element, like the "Time" that an event is supposed to happened...and
> that the granularity is really needed in the submillisecond range.
No, a time stamp has nothing to do with when an event has happened, it is my
time that I tell after perception of the event. 

Why do you stop at a granularity of 32 bits? I want 20 decimal digit time stamps
in the next millenium. I want them human readable without a conversion of a 
binary digits.  

> 
> Also what is the real overhead for adding these features to the process?
> What is it really.?

Someone told me once: Whenever you can remove one additional parameter, you divide
you problems by 2 (I told that to myself BTW).

Peter Sylvester
Not signed but simply written at PARIS (5th floor Montparnasse tour if
you need more precision)

PS: let's avoid reinventing the wheel. take the single element which is
supposed to generalize a time event, if this is not sufficient, one
can always propose a correction, for example addition a precision in
readable form after the zone.

---

From: Michael McNeil <[email-masked]>
Date: Thu, 05 Aug 1999 13:38:45 -0700

>attack, although it might sound like so in some comments,

I didn't notice any such!

>>Denis to using your words - Creating yet another representation of
>>time in a PKIX tool also 'seems pointless'.

I agree with that.

>'time' <--> GeneralizedTime in PKI, or date in rfc822

BERT's representation of time is a slight modification to one
which has long existed, enshrined in various RFCs -- that of NTP.
The modification is one which I've proposed (and presented at the
Stime meeting at Oslo) to defeat NTP's upcoming millennium problem.

>'signature'     <--> existing structures in pki+object ids for

BERT is still incomplete in these definitions; you might also have
criticized that some of these elements aren't (yet) defined in the
draft.  The intention (soon) is to reconcile these with other usage.

>it seems that some people have forgotten why we have leap seconds
>inserted sometimes (and not additional leap minutes). The intension
>is to make them invisible in real life applications. Or better,
>don't fix all real life applications by adding code to support
>leap seconds because you just need them once per 5 years.

Leap seconds actually occur about one every eighteen months these
days.  (The rate increases as time goes on and the Earth slows;
the current rate has been accumulated over the last century.)

Leap _years_, however -- a single day -- only occur every four
years; every eight years in the vicinity of the average century.
How many people should buy a calendar program that ignored them?

>The earth is the center of the universe (as Bert seems to tell us.)

Not at all.  Bert simply utilizes a coordinate system which, at the
moment, is relevant for nearly all of human affairs -- but which
is fully convertible into any other coordinate system that is
convenient.  If other coordinate systems become important, new
Bert "types" can be created which incorporate these systems.

However, except for planetary coordinate systems for those standing
on those planets, just about any other coordinate system is going to
have things moving about rather than remaining at fixed coordinates.

>>My point is that we don't know all the uses yet - and if we limit
>>ourselves to representing time at the same level of granularity
>>that the OS designers thought was relevant - Ahahahahahahah -
>>Well it just seemed a bit funny since we already know that it is
>>not clean enough. If you don't believe me call the stock exchanges
>>and find out what and how they use timedata/timesources for.

>Event arrive in ORDER, and the only relevant thing is the order,
>and not the absolute time value.

You're absolutely right, but it's also true that the absolute time
value (within limitations imposed by the space-time continuum --
relativity rules!) is the best tool we have (the best ruler against
which we can peg events) to help us put events into their proper
chronological order, and thus assist in making sense of them.

>Put a broker into a shuttle and look at the consequences. The only
>requirement is the order of two events, and sorry, you can give any
>resolution you want, something can arrive at 'the same moment' using
>whatever clock you use as external source, and you just decide who
>came first. A high resolution real time counter counts faster that
>you an make personal decisions, thus it is usable as a pure counter
>(and just gives an addtional convenient information).

That's why having a high resolution real time clock is a good idea,
and why the time in the timestamp should have a resolution much
finer than any practical usage -- to provide a smooth continuum
for expressing any possible time to any possible resolution.

>  - we first overlooked that there was a subdivision (remember that
>    the initial draft just had an integer indicating milliseconds.
>  - existing certificats use seconds. I don't see a problem, a
>    CORRECT comparison of GeneralizedTime isn't rocket science
>    (leaving apart Challenger and Ariane 5).

There's even a saying I've heard of late that "rocket science isn't
rocket science."  Of course quite a few space rockets have blown up
recently, so maybe that's not such a good motto to take to heart.

>>    o-    even in SW only systems,  that sub-millisecond precision
>>time is easily distributed in networking models. IRIG-B timecode
>>and NTP have been doing this *for decades* already.

>No it doesn't in principle. waht it negates is that real
>applications and HUMAN decisions need a higher precision. Tell
>me a real application with non-repudiation where you really need
>more than counting within the smallest observable time period for
>a human being (a second, or may be a little bit less than that).
>(if not, see my last comment).

Reminds me of an apocryphal story of a British commission early
in this century which decided that the automobile had no future
across the Atlantic in the United States -- because in all the
U.S.A. there was at the time no more than a few hundred miles of
_road_.  Sometimes these things change, the needed infrastructure
gets built.  Who would have predicted more than a handful of years
ago that every computer in every home in America (in the world...)
would need to be connected to the Internet, just to shop, to do
research, to read world newspapers -- as early as 1999?

I predict that these applications will be built, they will
appear -- and much faster than many people expect.  They will
initially be designed to operate in close proximity -- within
as close a fraction of a second as they can -- of temporal
boundary points with clear financial consequences, stock
closing times and the like.  Time will tell the tale.

Meanwhile, setting up a timestamp time format so that fine
subsecond precision is _impossible_, because we the designers
of the format decided no one would ever need it, is simply
silly.  It's like doing a repetition of the Y2K problem -- just
as that problem is about to climax.  One would think that we as
people would learn; but just as folks over the ages returned
after Pompeii to the slopes of Vesuvius (or, here in California,
live in the shadow of volcanic Mount Shasta), we make the same
mistakes, slightly differently each time, over and over again.
(What's the saying?  "History doesn't repeat itself, but
sometimes it rhymes.")

>The scenarios is a little bit more complex. A time stamp service
>and any form of notarisation service can be operated in a chain.
>Somewhere a clients asks some local service, the local service
>either provides it directly, or has to be backed up by another
>external service or more of them.

>BTW: Where is the external reference for spatial coordinates?
>I am here, and I can see the top of the Eiffel tower, do you
>trust me?

GPS is a possible source for location information.  Some future
secure-GPS system would be even better.  A fixed mounting, such
as within a building, might have the location wired in.  The
source and quality of the spatial information, as with the
temporal, should be identified, but needn't be the same.

>It seems that you misunderstood time and time stamp. I can make a
>time stamp 'number 9986557555787687', it comes before  'number
>9986557556787686', I record somewhere that I have issued time
>stamp X just at some time, in order to establish a convenient way
>of using it. The time stamp is the stamp of MY TIME, and nothing
>more.

Kind of like each community before the coming of the railroads;
each had its own time.  Then the railroads came, and they for
all practical purposes forced each community (at least within
a time zone, and convertible between) to keep the _same_ time.

What I'm saying is that the existence of Internet commerce will
basically force each TSA to keep the same (good) time, with which
they will calibrate their internal counters, and as a result of
which the counters from different TSAs will be fully comparable.

>>My point is that there needs to both be interoperability
>>in timestamping, as in all PKI, and in particular in the
>>representation of the other cornerstone trust element, like
>>the "Time" that an event is supposed to happened...and that
>>the granularity is really needed in the submillisecond range.

>No, a time stamp has nothing to do with when an event has
>happened, it is my time that I tell after perception of the
>event.

Since the former follows the latter by a (presumably small)
interval, it clearly does have something to do with it.

>Why do you stop at a granularity of 32 bits? I want 20 decimal
>digit time stamps in the next millenium.

As mentioned elsewhere, a 32-bit fractional second resolution
pins time down to a granularity wherein light travels a mere
3 inches (7 cm).  I do have some qualms about this, however, as
3 inches is certainly a macroscopic distance, and scientists
will definitely want to pin things down more accurately.  So,
reasoned arguments that a 2^(-64) second resolution is needed
might find me receptive.  However, for nearly every practical
(versus laboratory) purpose, 2^(-32) second is satisfactory.

>I want them human readable without a conversion of a binary digits.

Do you also want the Moon, as a bauble you can close your hand on?
Can you read computer media, without conversion and presentation?

>Someone told me once: Whenever you can remove one additional
>parameter, you divide you problems by 2 (I told that to myself
>BTW).

Actually, it's for a similar reason that I favor the NTP time
format over calendric.  The time server must keep count of the
current leap second count, and as a result TAI (atomic time)
is available.  TAI is simply a seconds count which marches one
standard second at a time towards infinity -- none of this
years-months-weeks-days-hours-minutes-seconds-microseconds-leap
seconds-leap years-AD-BC -- GAH!  Just a simple seconds count,
then call well-established software when desired to convert
into the calendar of your choice (and there are many calendars
in use today around the world, not just the conventional).

A pure standard seconds count, to my mind, is much less
"geocentric" (since we're talking geocentric) than our complex
calendric system, so closely tied to the cycles of the Earth.

>Peter Sylvester
>Not signed but simply written at PARIS (5th floor Montparnasse
>tour if you need more precision)

_Is_ the Eiffel Tower visible?  (I trust you!)

>PS: let's avoid reinventing the wheel. take the single element
>which is supposed to generalize a time event, if this is not
>sufficient, one can always propose a correction, for example
>addition a precision in readable form after the zone.

Regards,
Michael McNeil