What’s the PROPER way to validate a signature timestamp?
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:
- 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.
- 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)orcessationOfOperation (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?
