Re: Untrusting a Trusted Third Party: TSA.

["todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>]

Alfonso - 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.

Todd

----- Original Message -----
From: "Alfonso De Gregorio" <agregorio@xxxxxxx>
To: <ietf-pkix@xxxxxxx>
Sent: Thursday, September 13, 2001 5:30 AM
Subject: Untrusting a Trusted Third Party: TSA.


>
> 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
>