Subject: Untrusting a Trusted Third Party: TSA.

From: Alfonso De Gregorio <[email-masked]>
Date: Thu, 13 Sep 2001 14:30:01 +0200

Hi Everyone,

The following consideration is quite obvious; however, it's intriguing
to see how the TSP allows a user to perform a simple test against a
TSA that he doesn't trust anymore.

Assume a user is afraid that a TSA is issuing time-stamp tokens while
not in synchronization with UTC; after all if a TSA use a trustworthy 
source of time and include a trustworthy time value for each time-stamp 
token is not necessarily ensuring that the clock doesn't drift outside
the declared accuracy (this is addressed in ETSI - STF 178-T1 draft H).

The test 
The ordering of time-stamp tokens issued by different TSAs is only
possible when the _absolute value_ (*) of the difference between the
genTime of the first time-stamp token and the genTime of the second
time-stamp token is greater than the sum of the accuracies of the
genTime for each time-stamp token.

*) partially contrarywise to what is asserted in section 2.4.2 of rfc3161.

TSA-1: the tsa not trusted anymore by alice 
TSA-2..TSA-3: tsa still trusted by alice

1. Alice send a TimeStampReq to TSA-1 (TSA1Req) where 
   TimeStampReq.messageImprint is simply an hash of a document kept
   secret (Alice_doc);
2. Upon receiving the response (TSA1Response), Alice hash the received 
   time-stamp token ( hash(TSA1Response) ) and send as quickly as possible
   a time-stamp request to TSA2 (TSA2Req), where 
   TimeStampReq.messageImprint is hash(TSA1Response);
3. if the absolute value of the difference of the first time-stamp token 
   and the genTime of the second time-stamp token ( abs(x) ) is greater 
   than the sum of the accuracies of the genTime for each time-stamp 
   token, Alice can order the two tokens; but for a positive value of
   the difference we have a consistent chain of time-stamp 
   request/response, and for a negative a contradictory result.

  x = TSA2Response.genTime - TSA1Response.genTime;
  while abs( x ) > (TSA2Response.accuracy + TSA1Response.accuracy)
	if  x > 0 --> TSA2Resoponse follows TSA1Response
	if  x < 0 --> TSA2Response is _antecedents_ to TSA1Response 
                      
   Alice can prove the opposite showing the chained sequence of time-stamp 
   requests:
	a. Alice_doc
	b. TSA1Response.TSTInfo.messageImprint = hash(Alice_doc)
	c. TSA2Response.TSTInfo.messageImprint(hash(TSA1Response))

Sincerely,
alfonso

---

From: "todd glassey" <[email-masked]>
Date: Thu, 13 Sep 2001 18:53:38 -0700

Alfonso - I have said this many many times, but lets try it once more. The
instant of trust for the issuance of the time stamping token happens when
the token is verified. At this instant the TSA can easily return a
commentary to the questioning client that its clocks drifted xy and z amount
and as such the relying party can take the testimony of the TSA as being
that the actual time the incident happened was XY and Z + drift_value.

There is nothing anywhere that says that the TST itself is the testimony of
the TSA, just the token to prove that some TS was actually issued - i.e its
a receipt and not a very good one. This is an important concept and is
crucial to many many use models, but since the Authors decided not to add
use models to the draft or delineate them in a corresponding use document,
well...

Todd

---

From: "todd glassey" <[email-masked]>
Date: Fri, 14 Sep 2001 17:32:16 -0700

Alfonso - The instant of trust for the issuance of the time stamping token
happens when

There is nothing anywhere that says that the TST itself is the testimony of
the TSA, just the token to prove that some TS was actually issued - i.e its
a receipt and not a very good one. This is an important concept and is
crucial to many many use models.

Todd