Re: ESSCertID in TSP

[Jean-Marc Desperrier <[e-mail]>]

Joerg Seidel wrote:

> Jean-Marc Desperrier wrote:
> > With such a use of time-stamp, if the base over wich the hash is
> > calculated does not include any reference to the local time, the
> > implementor has a hugh risk of time-stamping twice the same data, and
> > yet expect after the inclusion of the time-stamp to hold some guaranty
> > that the two items are separate entities.
>
> The serial number and usually also the time of the timestamp will be
> different.

Maybe my point wasn't clear enough.

I'll try to devise a stupid, but simple example.
This is not an attack against time-stamping, but against what happen when you
don't know how to use it properly.

On day A, Alice borrows Bob2000$.
She writes a statement "I owe Bob 2000$", digitally signs it, time-stamps the
signature and gives it to Bob , saying : "See, I owe you 2000$, and this
horodated statement proves it, digital signature, time-stamp, everything.

The next day, Alice borrows Bob 2000$ again.
Alice writes a second statement "I owe Bob 2000$", digitally signs it,
time-stamps the signature and gives it to Bob, saying : "See, I owe you 2000$
again, and this new time-stamp "proves" that this is what I owe you today".

Of course it's very clear to everyone who has a good understanding of
time-stamp, that this new time-stamping proves _nothing_.

The TSA does not identify who submits the TSP request. It could have been
either Bob restamping the message he got the previous day, or Alice stamping
her "new" message.
Even if the TSA identifies who submits the request, there's nothing wrong in
Alice restamping her message of the previous day.

I even feel that a TSA that would, when receiving a request, check in it's log
if a time-stamp for the same hash has already been generated, and resend that
time-stamp if that's the case, would be doing nothing wrong (if the request
includes a new nonce, of course it will have to generate a new time-stamp).