What a countersignature adds that a signature does not
A timestamp turns a signature into a dated claim. The date is often the more useful half, and it is the half most tooling discards.
A signature says who. A countersignature says when, and the two decay on completely different schedules.
The mechanism
When a publisher signs a binary, they can send the signature value, not the file, to a timestamp authority. The authority signs that value together with its own clock reading and returns the result, which is embedded back into the PKCS#7 structure as an unauthenticated attribute.
Two formats are in circulation. The legacy Authenticode timestamp is a PKCS#9 countersignature. The modern one is an RFC 3161 token, carried in the same place, and it is what current signing tooling emits by default. A binary may carry either, both, or neither, and a verifier that only understands one will report a file as untimestamped when it is not.
What it establishes
That the signature existed at a stated moment, attested by a third party who was not the publisher.
The immediate consequence is the familiar one: the signature survives the expiry of the signing certificate. Without it, every signed binary would become unverifiable a year or three after release, and shipping software would mean re-signing the back catalogue forever.
The less familiar consequence is about revocation. A revocation carries an effective date and often a reason code. If a key is revoked as compromised with an effective date, a signature timestamped before that date can still validate, on the reasoning that it was made while the key was still good. If the revocation reason indicates the key was compromised all along, it should not. Whether your verifier draws that distinction is a property of the verifier, not of the file, and the two answers are both defensible.
The part worth keeping
For triage, the date is the useful field, and it is usually thrown away.
Inventory tells you a file is present. The countersignature tells you when it was built. A binary that appeared on an endpoint last week and was signed in 2019 is an old tool newly introduced, which is an ordinary and mostly boring story. The same binary signed eleven days ago is a recent build of something, which is a different story and may deserve a different question.
Neither is a verdict. But a file with no time dimension can only be sorted by when you noticed it, which says more about your collection schedule than about the software.
More of this
New posts on what a file tells you before you run it: headers, signatures, manifests, overlays, the fields most inventory never reads. Only when there is something worth the write-up.
We intend to offer a tool that does this across every file on an endpoint. You get one message when you can use it.