Re: Untrusting a Trusted Third Party: TSA.

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

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

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