That's weird. The blog post that answer links to implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted.

That doesn't make sense to me: If the certificates are compromised, an attacker could backdate the timestamp to whatever he wanted and sign anything.

What's the thinking here?

> implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted.

That's not how I read it. The "lifecycle table" doesn't mention the case of both signing and timestamping certificates going bad at the same time, only what happens if one of them expires or is revoked. The only mention about both certificates going bad is in the text below the table:

> But timestamped signature remains considered as a valid even if all certificates in the signing and timestamping chains are expired.

Note that it doesn't say anything about certificates being revoked.

Take a look at the "Digital signature lifecycle table" here: https://www.sysadmins.lv/blog-en/digital-signatures.aspx

As an outsider my guess is that by having a signer and counter-signer you are accepting that the chance of both certs being compromised is minimal enough.

Of course this sorta falls apart if you consider large bad actors could have legit timestamp certs over a period of time and then use those historic certs on backdated servers to counter-sign a stolen signing cert. It would appear as a legit signed and counter-signed cert done when the signing certs were valid.