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

From: Peter Sylvester <[email-masked]>
Date: Wed, 4 Aug 1999 12:42:58 +0200 (MET DST)

> 
> [snip]
> > I am the authority that defines the order, and not something else.
> > I do NOT mean with respect to time. If at all it is MY time, my counter
> > is my time, it is just a matter of convenience to use something
> > that most people will understand. (I have not said that
> > I don't need an indication of time in a time stamp, I was just taking
> > about order).
> 
> In your own environment, you are correct. The problem arises when the order
> has to be agreed upon by more than just one party.
The order is defined as the order of integers. A smaller number comes
before a larger one.  

Which problem? The problem of what the counter actually means? Imagine an
environment where you need to meet a deadline. The deadline is defined as
the time stamp that is obtained by some trustworthy entity. Everybody 
knows that this entity will try to obtain a timestamp just at 
the deadline. You miss the deadline if your sequencenumber is higher.

In this scenario the TSA does not need to use time in the stamps.

The indication of what time it is at a particular counter simplifies 
the scenario, since everybody agrees that the time provided by the TSA
is part of the game. 

Or, are you taking about several independant TSA: 'In order to meet a
deadline, you need to have a time stamp from one of n well known entities".
in this case you do not compare the order of time stamps issued by
different tsas. You test whether your time stamp meets the deadline.
Again, the deadline can be defined by an indication of time in the stamp
or by using an independant entity that gets the deadline stamp from
all TSAs.

You can compare two time stamps of different TSAs; the game consists
of trusting in the ability of the TSA to sync their clocks. Either
you trust, or you don't. Whether or how the TSA do the sync is not
important; it may be important in order to decide whether one can
set up this game, or not.

> 
> [snip]
> >
> > I agree with you that a time structure that will not expire in the near
> > future is important, what's wrong with an arbitrary long decimal
> > subdivision of a second?
> 
> Good, then we're in violent agreement ;-). I personally prefer a
> numerator/denominator approach such as (please excuse my ASN.1):
> 
>     Seconds ::= SEQUENCE {
>         numerator INTEGER,
>         denominator INTEGER OPTIONAL DEFAULT 100
>     }

Well, if you want only decimal fractions I'd prefer the log10 of the denominator. 

Bit shifts and binary to decimal conversion are NOT FAST for humans.
if the bank tells me that they refused my payment because 
if was 1.000.000.000+65875655*47**-7 seconds after 1jan1970 I'll
change the bank. 

But we are not counting seconds in this context, aren't the time stamps
a refinement of a second-based generalizedTime used in other areas like
certificates, signing date etc?
generalizedTime as it supports decimal fractions. 

Regards

---

From: "tog" <[email-masked]>
Date: Wed, 4 Aug 1999 08:28:29 -0700

Peter -
----- Original Message -----
From: Peter Sylvester <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 04, 1999 3:42 AM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition

> Which problem? The problem of what the counter actually means?

Yes and how its referable to other counters in other parts of the world.
What binds the trust models together here. Simple. Their conformance to the
one thing on this planet that is agreed on by virtually all the nations on
this earth. UTC.

> Imagine an

This assumes that you are going to use a TSA based system that is public in
nature. What there is here is no real method or comparing the outputs from
separate TSA's becuase there is nothing to reference that the timebase
running below them is synchronous to squat. The issue isn't that the TSA is
broken its that when there are a number of TSA up everywhere and we have to
start interoperating between the logging systems that they support the
proofing models need to be made portable or their reference value is moot.

> In this scenario the TSA does not need to use time in the stamps.

Only if it is part of a system that only shows the order of which events in
a single environment happened.

> the scenario, since everybody agrees that the time provided by the TSA

But they don't and that's just the point. Just becuase we say so doesn't
mean jack to a Court without supporting evidence.

> you trust, or you don't.

So 10 years later, how do I trust. What is there that instills trust that
the TSA was operated correctly or that there is any real reason to believe
that the stamp is accurate.

> Whether or how the TSA do the sync is not

I guess that we have different use models for timestamping systems. In my
world, the accuracy of the clock is the key evidentiary issue.

> > > future is important,

Why? - if the accuracy of the timebase is irrelevent why is time needed at
all? If the timebase is not a referrable point in a transaction, this field
could just as eaisly be a nonce or other social-process keying component.
The point is that the time is very very important to the process. It is the
point of contact with the road so to speak.

>>> what's wrong with an arbitrary long decimal
> > > subdivision of a second?
> >

The UTC96 selection from the BERT draft works just fine here.

SNIP

Todd

---

From: Michael McNeil <[email-masked]>
Date: Wed, 04 Aug 1999 09:17:16 -0700

Peter Sylvester wrote:

>>In your own environment, you are correct. The problem arises when
>>the order has to be agreed upon by more than just one party.

>The order is defined as the order of integers. A smaller number
>comes before a larger one.
>
>Imagine an environment where you need to meet a deadline. The
>deadline is defined as the time stamp that is obtained by some
>trustworthy entity. Everybody knows that this entity will try to
>obtain a timestamp just at the deadline. You miss the deadline if
>your sequencenumber is higher.
>

As long as each TSA gets to define "time" (what the counter means)
then this works.  However...

>The indication of what time it is at a particular counter
>simplifies the scenario, since everybody agrees that the time
>provided by the TSA is part of the game.

Time not only "simplifies" the scenario, it makes it possible to
function in the real world.  Imagine that one has a contract or
document timestamped by a TSA.  Would it be of any utility in
our world to say merely that the document was "time"stamped at
counter location 25,058,964,923 of a counter meaningful only
to the TSA?  I think not (but convince me otherwise...).

[snips]

Regards,
Michael McNeil