Subject: ESSCertID in TSP

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 19 Mar 2001 22:44:00 +0100

The TSP draft has several reference to an "ESSCertID attribute", saying
it's defined in ESS (RFC2634).

But as far as I see RFC2634 does not define an ESSCertID attribute.

It defines a SigningCertificate attribute, that can include one or
several ESSCertID structures.

Only the SigningCertificate has an OID assigned to it in RFC2634, not
the ESSCertID alone.

Therefore to be more explicit, I think the wording should modified to :
"a ESSCertID identifier inside a SigningCertificate attribute".

Also the recent "Time-stamp issue" thread a lead me to te conclusion
that some hints should be included in the draft about the correct way to
generate a hash value that is intended to be time-stamped.

Without a proper warning that a timestamp states that some data existed
before a given time, but does _not_ date the data as in "this is a
transaction that was generated at this date", the temptation for user ot
the TSP service to directly use a time-stamp to guaranty this, will
exist.

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.
Time-stamped signed data will have exactly the same behaviour, because
the signature algorithm is deterministic.
The same data will always generate the same signature (at least in RSA
with standard padding algorithm)

Therefore the standard should warn that the data to be time-stamped
should be "new", that is it must include enough data to guarantee it to
be unique, and that the user will not generate twice the same exact
request.
Except of course when this is deliberate.

One of the easiest way to guaranty that being to include local time in
the data before hashing it.

---

From: Joerg Seidel <[email-masked]>
Date: Tue, 20 Mar 2001 10:58:19 +0100

Comments inline.

> the TSP service to directly use a time-stamp to guaranty this, will

Agree. The draft states:

"The TSA is a TTP that creates time stamp tokens in order to indicate 
that a datum existed at a particular point in time."

This could be changed to

"The TSA is a TTP that creates time stamp tokens in order to indicate
that a datum existed at a particular point in time. This token does not
indicate that the datum was generated at that time."

But I don't feel like this change is important enough to further delay
the RFC.

> that the two items are separate entities.

The serial number and usually also the time of the timestamp will be
different.

> with standard padding algorithm)

IMO not a problem the timestamps will be different. See above.

> be unique, and that the user will not generate twice the same exact

If a user feels such a need he should use a nonce in the request.
Whether this is necessary depends on the application.

Regards
Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 20 Mar 2001 13:22:43 +0100

> The serial number and usually also the time of the timestamp will be

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

---

From: Joerg Seidel <[email-masked]>
Date: Tue, 20 Mar 2001 16:46:37 +0100

> time-stamp, that this new time-stamping proves _nothing_.

Yes, now I see your point. You are totally right. The problem arises
because the timestamp proves only that the signature was made before a
given date, not at the date.

There are serveral ways to solve this problem. One of them is to
timestamp the document, sign the timestamp and timestamp the signature.
This proves that the signature was made between the two timestamp times.
Another is, as you stated already, to include the time in the document
or as a signed attribute in the signature.

What about this one:
"I owe the owner of this document 2000$". It is equivalent to a cheque
in the real world, but it has the value zero in any case, because there
is no way to identify the original. The signer can always claim that he
never gave the original to anyone - just copies.

Regards
Jörg