2

the purpose of adding trusted timestamps to signatures is so that they can be considered valid long beyond the validity of the signing certificate. However, this is not so easy, since TSA's signing certificate has an expiration date too or may be revoked and already issued timestamps may become invalid.

My question thus is, what's the text-book way of validating trusted timestamps?

My understanding of the process is this:

  1. Verify that the token has been issued for the data in question and that the issuing certificate of the token was valid and trusted at that time the token was issued.
  2. Verify that by the current time, none of the certificates in the trust chain have been revoked, OR that they have been revoked with a reasonCode extension present and the reasonCode is one of unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5) (according to RFC 3161)

But both of these steps seem to have some considerable problems in regards to CRLs:

For the first step, one would need to have a historical CRL record (valid at the time of timestamping) for each certificate in the trust (this in turn means that for every timestamp one should also store current CRLs, otherwise how would one validate the timestamp in the future?).

For the second step, one would need for each certificate in the chain a CRL which is valid NOW. However, that in turn would require that the CRL revocation points keep publishing updated CRLs for each certificate for all eternity. But by the time the timestamp is being validated the CRL distribution points may not be updated anymore for a long time already (especially if the certificate just expired and never got revoked).

So, let's say in 20 years someone wants to validate a timestamp token and the CRL distribution point URL of the signing certificate (or any certificate in the trust chain) would not be maintained anymore - how could the person validate the timestamp?

1 Answer 1

0

AFAIK, the goal of adding a trusted timestamp is not to extend the validity of the signed document, but just to prove that is was signed at a precise time.

It matters when anteriority is a thing. For example when two research teams want to publish an article on the same subject, it can be interesting to have evidence of which one established/discovered the thing first. Here a signed document with a trusted timestamp could be such an evidence.

Without the trusted timestamp, it is too easy to set the clock of local machine several months back, sign a document and reset the clock to the current time.

7
  • But that's the point - since timestamps can become retroactively invalid (for example if a private key leaks or if a certificate is revoked without giving a reasonCode), the question of how to properly check the validity of a timestamp token remains Feb 16, 2021 at 8:37
  • There is no difference between a trusted timestamp signature and a signature: it is only valid as log as all the involved certificates are. As soon as one certificate looses validity (because it is revoked or it reaches its end date) the signature is no longer valid. The rationale is that is could have been forged Feb 16, 2021 at 8:42
  • 1
    This is not correct, check chapter 4.1 of RFC3161 specification (ietf.org/rfc/rfc3161.txt), in particular [...] tokens generated before the revocation time will remain valid Feb 16, 2021 at 14:45
  • @matthias_buehlmann: I should have been more precise. A certificate loses validity when it is revoked or reaches its end date except when it is contained in a valid CRL with a reasonCode of either unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5). If it cannot be found it in a CRL all certificates and documents it has signed directly or indirectly are invalid. Feb 16, 2021 at 15:01
  • exactly, so the question is, what is a "valid CRL" in that case exactly? for example, if one has a historic CRL which shows that the certificate was revoked with one of those accepted reasonCodes (so, in essence, that the revocation was not due to key compromise) but the "notAfter" date of this CRL already lies in the past (and there are no new CRLs issued anymore), can the timestamp-token in that case still be considered valid? Feb 16, 2021 at 16:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .