| HN Mirror

The issue is that you need to apply a time to the certificate path validation (RFC 5280). If you apply the current time after certificate expiration, the validation will fail. But if you have no proof of when the signature was actually created, then using an earlier time incurs the risk of judging a fraudulent signature as being valid. This can be due to key compromise, for example, or due to algorithm compromise. In the context of signatures, timestamps serve exactly the purpose of providing the proof that the signature was created before a possible compromise. If however one doesn’t apply the same logic to the timestamp signature itself, the whole exercise becomes moot.

Of course, after a risk assessment you may still decide to treat an expired signature (timestamp) as valid in a concrete case, but it would be a questionable practice to do so in general for an automated validation procedure. It would effectively mean that you ignore the expiration date of certificates and treat them as being valid indefinitely. Those expiry dates exist precisely to contain the risk of fraudulent key use. Accepting signatures after certificate expiration without having proof of when the signatures were created completely undermines that mechanism.

An additional issue is that CAs are not required to maintain and publish revocation information (via CRL/OCSP) for expired certificates, which means that in general you lose the ability to even check the certificate for revocation. This is why AdES formats provide the ability to store revocation information with the signature (and also timestamps). Of course, to make use of revocation information you have to validate the CRL/OCSP signatures, which in the long run again requires adding timestamps covering those.