Subject: RE: When is Timestamp applied?

From: Michael Zolotarev <[email-masked]>
Date: Tue, 20 Jul 1999 19:09:23 +1000

>So no additional information is needed INSIDE the token. ... However, the
>*security policy* of the TSA may be to indicate that the time that will be
>placed inside the TST is the time of arrival in the FIFO or the time
>associated with the crypto operation. This may make a few seconds of
>difference. When the time is critical, some users may choose to use a TSA
>using the time of arrival rather than the time of time stamping.

How about a more generic qualifier: Guaranteed Maximum Latency (GML). Or may be a GAL (Average).
Independent of any particular crypto technology, scheduling and other 'why-would-a-user-care' implementation details.
It is just a value (millis?) - easy to change when a TSA changes its implementation (from FIFO to LIFO, for instance).

cheers
MichaelZ

---

From: Paul Koning <[email-masked]>
Date: Tue, 20 Jul 1999 12:01:02 -0400

>>>>> "Michael" == Michael Zolotarev <[email-masked]> writes:

 >> So no additional information is needed INSIDE the
 >> token. ... However, the *security policy* of the TSA may be to
 >> indicate that the time that will be placed inside the TST is the
 >> time of arrival in the FIFO or the time associated with the crypto
 >> operation. This may make a few seconds of difference. When the
 >> time is critical, some users may choose to use a TSA using the
 >> time of arrival rather than the time of time stamping.

 Michael> How about a more generic qualifier: Guaranteed Maximum
 Michael> Latency (GML). Or may be a GAL (Average).  Independent of
 Michael> any particular crypto technology, scheduling and other
 Michael> 'why-would-a-user-care' implementation details.  It is just
 Michael> a value (millis?) - easy to change when a TSA changes its
 Michael> implementation (from FIFO to LIFO, for instance).

"Guaranteed average" doesn't seem terribly meaningful, but "guaranteed 
maximum" makes sense.

Denis, it doesn't matter whether you want to put "time of arrival
rather than time of stamping" into a policy.  It isn't a testable
property.  Putting it into a policy doesn't make it a testable
property.  It is flat out improper for a protocol spec to mandate
properties that are not observable on the external interfaces of an
implementation. 

To put it differently: if I build a TSA, and there is a requirement
that the TSA must timestamp packets on arrival, how would you build a
conformance test that verifies this?  I say it cannot be done.  You
have no way to disprove my assertion that it conforms unless I stamp a 
time earlier than arrival on the wire, or later than departure on the
wire of the reply.  But that property proves "time of signing" just as 
well.

I'd have no problem with a statement like "since the purpose of the
time stamp is to demonstrate existence of data before a certain time,
it is recommended that a TSA apply a time stamp that is close to (but
not earlier than) the arrival time of the request".  Or you could
introduce Michael's GML and recommend that GML should be minimized.

	paul