[layer8]

I’d like to add that one should be aware that such timestamps are only valid until the TSA certificate expires (or is revoked). To prolong the validity, you need to add another timestamp on top, using a newer certificate, to prove that the first timestamp was created before its certificate expired/was revoked. This is a recursive process. If the TSA renews its certificate every N years, it makes sense to accordingly re-timestamp every N years to keep the original timestamp valid. To guard against the case of an untimely revocation, you may want to timestamp with multiple TSAs each time.

[smileybarry]

That's not really the case -- at least on Windows, timestamp signatures persist past the timestamping certificate's validity, it's their whole point. I just looked for something signed on my PC to find that Office 2019 installations were signed & timestamped on 2019-12-01 by Microsoft with both certs (code-signing and timestamping) valid 2019-2020. The signature & timestamp remain valid.

[layer8]

It may be the case that Windows behaves that way, but it means that if the signature and timestamp were fraudulently created after the fact, enabled by a key compromise or an algorithm compromise, Windows would incorrectly treat them as valid although they aren’t.

[password4321]

> if the signature and timestamp were fraudulently created

This is enough, independent of whether or not it happened after any of the certificates involved have expired. I don't think most consider total "key compromise" (of the 3rd party timestamping cert + the code signing cert) part of the threat model... but if there was an issue either could be revoked at a specific point in time. (Mentioning algorithm compromise takes away from your argument, when that happens entire segments of PKI get tossed.)

https://knowledge.digicert.com/generalinformation/INFO1119.h...

A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.

[smileybarry]

That's why only about 10 timestamping authorities exist (at least in a trust sense) on Windows, and they're held to a much higher security standard compared to every other signing operation. Could just be an independent HSM with its own atomic clock to prevent such attacks.

Otherwise there's no viable way to actually use timestamping, or your archived timestamped files would just randomly become untrustworthy. Keeping the signature valid using a timestamp (and giving the timestamp special standing) means you can still trust something like a Windows XP installer 20 years later without needing to save a hash ahead of time (and without worrying the hash you saved elsewhere was maliciously changed to fit the changed file).

[huhtenberg]

> I’d like to add that one should be aware that such timestamps are only valid until the TSA certificate expires (or is revoked).

This is simply not true.

More precisely, it depends on the definition of "valid", but conventionally the death of a notary doesn't invalidate their notarizations.

[layer8]

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.

[password4321]

> it would be a questionable practice to do so in general for an automated validation procedure

Or, as parent mentioned ("conventionally"): standard practice.

Yes, if you have nothing in place to update and check CRLs and transition away from SHA1, you're gonna have a bad time. Is that the clarification you're trying to make? It's not like expiration vs. revocation hasn't been considered:

https://social.technet.microsoft.com/Forums/ie/en-US/405be5d...

certificates remain in the CRL indefinitely - Code Signing and Kernel Code Signing