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

From: [email-masked]
Date: Tue, 10 Aug 1999 09:56:52 -0400

Tom Gindin has already said this, but as it seems to have got lost, I'll
repeat it...

There is a desire to be able to express timestamp times to sub-second
precision, coupled with an indication of the accuracy of the time value.

GeneralizedTime already allows for arbitrary precision; why not use this
rather than trying to invent a new format?  It's trivial for
implementations to simply ignore trailing decimal digits if they only
require one-second precision.

The only thing missing from this is an indication of the accuracy of the
time value.  This is easily accomplished by adding a field that indicates
the accuracy.  So the resulting ASN.1 would look something like:

TSTTime ::= SEQUENCE  {
  genTime  GeneralizedTime,
  errorFactor INTEGER DEFAULT 0
  -- genTime is correct to within (2**errorFactor) of the actual time.
}

Thus the default accuracy would be 1 second.  More accurate time values
would be indicated by a negative errorFactor, less accurate by a positive
value.

Or since generalizedTime is a decimal representation, perhaps
10**errorFactor would be a better way of expressing the inaccuracy.

John

---

From: Daniel Finkelstein <[email-masked]>
Date: Tue, 10 Aug 1999 15:14:37 -0400

> 10**errorFactor would be a better way of expressing the inaccuracy.

This brings back memories of significant digits and the red grade marks next
to my pathetic attempts. I don't want to dwell too long on this topic:
10^errorFactor could be a large number, but it correlates with TCP timeouts
that are also geometric so I don't disagree with the equation in theory.

Trust is the problem I envision. Who decides what your error factor is? If
you trust me, you assume that my clock is set correctly and I'm not lying
about the error factor with respect to some standard clock. Error factors
depend on network speed, routes, and availability, the accuracy of the
hardware clock, and so on. We could argue about the accuracy of every system
out there, every network, and combination of such. Rather messy.

The only surefire way to timestamp something is to have someone else do it,
a trusted third party, whom we assign the task of being the master
timestamper. But that's rather impractical.

--
Daniel Alex Finkelstein
New Technologies
phone   212-383-2951
pager   917-427-1630
fax     212-383-3289
Securities Industry Automation Corporation

---

From: Paul Koning <[email-masked]>
Date: Tue, 10 Aug 1999 15:58:12 -0400

>>>>> "Daniel" == Daniel Finkelstein <[email-masked]> writes:

 Daniel> [email-masked] wrote:
 >> The only thing missing from this is an indication of the accuracy
 >> of the time value.  This is easily accomplished by adding a field
 >> that indicates the accuracy.  So the resulting ASN.1 would look
 >> something like:
 >> 
 >> TSTTime ::= SEQUENCE { genTime GeneralizedTime, errorFactor
 >> INTEGER DEFAULT 0 -- genTime is correct to within (2**errorFactor)
 >> of the actual time.  }
 >> 
 >> Thus the default accuracy would be 1 second.  More accurate time
 >> values would be indicated by a negative errorFactor, less accurate
 >> by a positive value.
 >> 

 Daniel> Trust is the problem I envision. Who decides what your error
 Daniel> factor is? If you trust me, you assume that my clock is set
 Daniel> correctly and I'm not lying about the error factor with
 Daniel> respect to some standard clock. Error factors depend on
 Daniel> network speed, routes, and availability, the accuracy of the
 Daniel> hardware clock, and so on. We could argue about the accuracy
 Daniel> of every system out there, every network, and combination of
 Daniel> such. Rather messy.

 Daniel> The only surefire way to timestamp something is to have
 Daniel> someone else do it, a trusted third party, whom we assign the
 Daniel> task of being the master timestamper. But that's rather
 Daniel> impractical.

I don't understand the issue.  The subject is trusted timestamping.
If you ask a server to put a signed timestamp on something, presumably 
you trust it to do that correctly.  "Correctly" includes putting on a
proper value for accuracy.

Network delays etc. are not an issue.  The timestamp reflects when the 
server acted on the request, i.e., after it got it and before it
replied.   How long it took for the request to get there doesn't
affect the accuracy of the timestamp.

(If you care about establishing priority, you may need a server that
you can reach with low latency.  For that matter, you'd want it to
have good accuracy, and low processing delay also.)

	paul

---

From: "William Whyte" <[email-masked]>
Date: Tue, 10 Aug 1999 21:27:22 +0100

> INTEGER DEFAULT 0 -- genTime is correct to within (2**errorFactor)
 
But surely, since GeneralizedTime contains a subsecond facility, we
can simply assume that the GeneralizedTime is accurate to the precision
given?

In other words: If errorFactor implies a greater precision than
is provided in genTime (for example, genTime provides time to 1/10th
of a second and and errorFactor implies precision to a microsecond)
then errorFactor cannot be trusted; If errorFactor implies a smaller
prcision than is provided in genTime, why not simply leave off the
trailing digits of genTime?; and if errorFactor implies an error of
more than a second, why would anyone use that TST?

What actual purpose does errorFactor serve?

Cheers,

William

---

From: Daniel Finkelstein <[email-masked]>
Date: Tue, 10 Aug 1999 17:12:23 -0400

> proper value for accuracy.

I apologize if I was unclear; I agree with what you've said thus far.

> have good accuracy, and low processing delay also.)

That's what I was thinking about. Say two messages are sent from separate
systems at exactly the same time to a timestamp service; one may get a
timestamp that differs from the other. In the case of patent applications
and so on, this is of material consequence.

---

From: "tog" <[email-masked]>
Date: Tue, 10 Aug 1999 15:26:07 -0700

Paul,

SNIP

>
>  Daniel> Trust is the problem I envision.

Exactly!

>  Daniel> Who decides what your error

I think that the issue of the accuracy and services are specific to the
transaction types and the indemnity model that they support.

>  Daniel> someone else do it, a trusted third party,

I disagree. The issue with timestamping is whether a system can be put in
place that the two parties that are doing a transaction agree upon. I think
that a certifieable timebase is really necessary for fully enabling digital
commerce, but if your doing simple one-sided transactions so to speak, that
is you at your browser doing some POS transaction, then a simple
timestamping system where the transaction happens and then there is a
secondary approval of the event stamping process seems to me like it would
eliminate the timebase credibility issues.

So if a simple acknowkledgement process, that the transaction was accepted
as it was logged, would eliminate the issues of the timebase for a number of
transaction models.

As a political statement regarding timestamping and those of us trying to
scratch out a living doing it, it seems to me that the real key to making
timestamping work is to bury it into other processes models, and not in
making it a stand alone system. The TTP model can more readily be
implemented as an application layered on an embedded system than as a core
'distributed' protocol, I think!.

>  Daniel> whom we assign the

Paul, let me say that I believe that the real issue is the credibility of
the time data represented in the timestamp or other PKI services model. As a
second concern, there is how the timestamping process proves this
credibility some number of years later across stamps issued by different
servers..

> proper value for accuracy

The idea is really simple. If the source of time is not credible and
referencable then why should anyone believe anything that is stamped with
timedata in it?.

The reality is that the timedata itself represents nothing more than a
monotonic incrementing serialization process, that is globally referencable.
What this provides theoretically is that multiple marks or events can be
accurately comparable to each other, but this is totally based in that the
timesense on System A is identical to that on System B and it just aint so.
The problem is that the current draft doesn't address this issue too well.

This is now, and has always been my primary objection to the current TS
Drafts. They assume that the TOD clocks and the services that make them up
are reliable and they may be.

Todd