Who says a signature is valid.
Validation as a process: trusted lists, revocation and policy.
A green check mark on the screen looks like a definitive answer: the signature is valid. But behind that check mark lies a process with several steps, each with its own sources of trust and its own rules. Two different validators can reach different conclusions about the same signature, and both can be right by their own criteria. Understanding how validation works means understanding what it really means for a signature to "count."
Validating means answering several questions in order
- Is the document intact? The hash of the content is recalculated and checked against the one that was signed.
- Does the signature match the certificate? It is verified mathematically using the certificate's public key.
- Is the certificate trusted? The chain is built up to a root authority, and the validator checks that this root is among its trust anchors.
- Was the certificate valid? The validator checks that it had not expired and was not revoked at the time of signing, which requires knowing that time with certainty.
- Are the required rules met? Acceptable algorithms, certificate type, signature level and any other condition imposed by the applicable policy.
Trust anchors
Step three is the one most often overlooked. No validator trusts every certificate: it trusts a list of root authorities and, through them, the certificates they issue. Who compiles that list is an enormously consequential decision.
- System and software stores. Operating systems, browsers and PDF readers ship with their own lists, compiled according to their own criteria and designed mainly for the web.
- Official trusted lists. In the European Union, each Member State publishes, under the eIDAS Regulation, a list of the qualified trust service providers it supervises, along with their status over time. Other countries maintain national roots administered by a public body, such as Uruguay's National Root Certification Authority, run by AGESIC and overseen by the Electronic Certification Unit (UCE).
- Custom lists. An organization may decide to trust certain authorities for its own processes, provided it documents that decision.
That is why a signature can show up as valid in one program and as "unknown identity" in another. The signature has not changed; the trust anchors have.
Three outcomes, not two
The European standard for signature validation, ETSI EN 319 102 1, does not reduce the outcome to "yes" or "no." It defines three states: passed, failed and indeterminate. The third is the most common in practice and the most misunderstood. It means the validator could not reach a conclusion, for example because it could not check revocation status or does not recognize the root. It is not a rejection, but it is not an approval either.
| Outcome | What it means | What to do |
|---|---|---|
| Passed | Every check succeeded under the policy applied. | Keep the validation report. |
| Failed | A check failed conclusively; for example, the document was altered. | Do not accept the document. |
| Indeterminate | There was not enough information to decide. | Find the missing data or validate under another policy. |
What to expect from a good validator
- It states which trust anchors and which policy it used.
- It distinguishes between passed, failed and indeterminate, and explains why.
- It validates as of the time of signing, using embedded timestamps and revocation data.
- It produces a report that can be stored alongside the document.
- It also declares what it does not check.
Validating a signature means checking integrity, correspondence, trust, validity and rules, in that order. The outcome depends on the validator's trust anchors and policy, and can be passed, failed or indeterminate. A good validator says what it checked, by what criteria, and what was left unchecked.