RE: [dss] Timestamping

[karel.wouters@esat.kuleuven.ac.be]

Hi all,

I have some comments on the independent/dependent time-stamping decision
that has to be made by this TC.

It is true that linked timestamps can carry a time value, but I'm not
sure that the timestamp checking algo requires the inspection of that
time value. For the Surety timestamps, I guess the time value is
essential and the linking is (only) used to make sure that the TSA
doesn't cheat. Other time-stamping techniques (such as the binary linking
scheme and the scheme built on threaded authentication trees) only
provide relative temporal authentication. This means that timestamps can
only be compared, and that -ideally- the certificate and the CRL (or
something else attesting the certificate expiration) must be
in the linking chain. This way you can check that the certificate existed
before the signature, and the the signature existed before the CRL was
published.
The authors of these schemes never intended for a time value to be present
in their time-stamps. The linking phase serves not only to show that the
TSA isn't cheating, it represents the core of the scheme. (as opposed to
the Surety timestamps, I assume)

Note that the security of a linking scheme only depends on the hash
functions used in it. In that way, they are more robust than schemes based
on Sign(hash, time).
Also, linked timestamps only 'expire' when the hash function is broken,
and are independent of the TSA (after publication); the repository can be
kept by a third party if the TSA ever stops its business.
Moreover, although Sign(hash, time) without linking seems more simple, it
has some problems:
- The TSA can back-date any signature/document.
- Suppose the signature algo of the signature and the timestamp are the
  same (eg RSA). If the algo is broken, the timestamp is also broken.
- What happens if the TSA's keys are compromised?
- What happens if the TSA stops it's business and I need my signature to
  be valid for another 30 years? (XAdES)
(Robert may be able to answer these :)

For these reasons, I think at least some more discussion is needed before
linked time-stamps are defined out-of-scope.


Karel.

PS: A up-to-date copy of Gregors submission of my paper is available at
http://www.esat.kuleuven.ac.be/~kwouters/TimeStamp.pdf
It also contains links to various time-stamping papers and the ISO
standards (working drafts).

PS2: I bumped into this some months ago:
http://www.edelweb.fr/cgi-bin/stamp and https://www.openevidence.org