Subject: 3 Time Stamping issues

From: Denis Pinkas <[email-masked]>
Date: Thu, 01 Apr 1999 17:59:28 +0200

Since I am a co-editor of the Time Stamping document, I would like
to give my opinion on the various issues raised on the mailing list.

1. There has been a suggestion to possibly improve the resolution to
microseconds from milliseconds.

Since the delay in the transmission is at least in the millisecond
order, having something more precise would give a false degree of
precision. I would not go under the millisesond.

2. There has been a suggestion to possibly add a precision field.

I do not think this is absolutely necessary. So I am not supportive
of it since the policy can handle this.

3. There has been a suggestion to possibly add a message information
field.

I have arguments *against* this idea. I would realy like to keep the
TSA as much ignorant as possible of the purpose of the Time
Stamping. If we add that information, the TSA could know "Invoice
from Alpha company to Delta company". Is
this way the TSA could learn that the Delta company is doing
commerce with the Delta company. This may that be a nice point to
spy. So I am against the inclusion of that aditional information.

However, ... I understand the concern of the linkeage and I would
propose an alternative:

Defining a Time Stamping Token (TST) that would be able to include
that information. Basically the TST would be the concatenation of
the "message information field" and of the signed portion of the
information received. The TST would be constructed locally instead
of being fully constructed by the TSA. We could define its structure
in a normative annex.

Regards,

Denis

---

From: Paul Koning <[email-masked]>
Date: Thu, 1 Apr 1999 12:30:01 -0500

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> 2. There has been a suggestion to possibly add a precision
 Denis> field.

 Denis> I do not think this is absolutely necessary. So I am not
 Denis> supportive of it since the policy can handle this.

I would think the policy describes things that are more or less
constant, certainly not things that are changing from hour to hour.
But the precision of the timestamp (how closely it agrees with UTC) is 
a dynamic variable.  If your authoritative time source (e.g., GPS) is
working, you're synchronized to a small fraction of a second.  If you
lose the signal, your precision degrades at, typically, about 10^-4,
i.e., 86 seconds per day.

If your policy reports a rather loose synchronization you can use the
policy approach (simply go off-line when sync has been lost for too
long).  But if you want to claim, say, 100 ms tolerance, but want to
be able to keep operating even if the external clock is lost for more
than 16 minutes, the precision field in the timestamp is useful.

	paul