[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).