Evidence, stated plainly

What a PAdES B-T signature actually proves (and what it does not)

You hear that a document was signed with a PAdES B-T signature. What, precisely, does that let you assert — and on what is the evidence still silent?

The short answer

Three independent facts are bound together in the file: a named signer created the signature over this exact document content, and that content existed in this exact form no later than a stated, trusted time. Everything else is packaging; these three claims are the signature.

When the four requirements of eIDAS article 26 hold, a B-T signature is also an advanced electronic signature under article 3(11) of Regulation (EU) No 910/2014: it is uniquely linked to and identifies the signatory, it was created under their sole control, and any later change to the data is detectable. This article covers the cryptographic side of the proof; the legal tiering is in our guide to qualified vs advanced signatures.

The three facts, and where they live in the file

First, identity: the PDF signature dictionary carries the signer's certificate, issued by a certification authority, and the certificate links the key that signed to the person or organisation named in it. Validating the chain from that certificate to a trusted root is what makes the name inside the file worth listening to.

Second, content: the private key paired with that certificate signed a SHA-256 digest of the signed byte range of the document. No practical method is known for producing a different document with the same digest, so a document that verifies is the document that was signed.

Third, time: embedded in the signature is a detached cryptographic timestamp token, issued by a timestamp authority under RFC 3161. It binds the hash of the signature bytes to a creation time (genTime), expressed in UTC, and carries a serial number unique to that authority — the authority's name and that number together identify the token.

The timestamp, precisely

The token's message imprint is a hash of the signer's signature: the authority never sees the document, only that digest. RFC 3161 requires the server to return the imprint exactly as received, which makes the binding mechanical rather than a matter of trusting the wording.

Under eIDAS article 42, a qualified electronic time stamp binds the date and time to the data in a manner that reasonably precludes undetectable change, is based on an accurate time source linked to Coordinated Universal Time, and is signed or sealed by the provider. Article 42(2) lets Commission implementing acts reference standards whose compliance is presumed — in practice, the reference here is RFC 3161.

One precision that changes what the proof is worth: the presumption in article 41(2) — accuracy of the date and time indicated and integrity of the data — belongs to the qualified electronic time stamp, defined in article 3(34). A stamp from a non-qualified service is still cryptographic evidence, but it does not carry that statutory presumption; its weight is assessed under general rules.

What the signature proves

Existence. The document bytes covered by the digest existed, unchanged, no later than the authority's creation time. That is exactly what RFC 3161 opens with: a trusted third party certifying the existence of a datum at an instant, indicating that the datum existed before that time.

Authorship. The private key paired with the signing certificate produced the signature over the digest. A verifier who validates the certificate chain attributes the signature to the entity the certificate names — or, with precision, to whoever controlled that key at the moment of creation.

Integrity at signing. The digest makes the statement self-contained: verification re-computes the hash of the signed range and compares the claim. Any different document either fails verification or is a different statement.

What it does not prove

That the signer read or agreed to the contents. A signature is produced by a key; understanding is produced by a person. That is why the ceremony records — the audit trail — count as evidence alongside the cryptography rather than instead of it.

That the signer knew the time. The PDF signature dictionary carries a claimed signing time that comes from the signer's own clock. Poorly synchronised laptops are routinely wrong about time. This is why the detached stamp exists: the authority's time has a defensible source.

That the signer remains verifiable. A B-T signature is a point-in-time proof. If the certificate expires or is revoked the following week, a window remains in which the proof of validity is thinner than you would want before a court years later.

That the platform exists. The sealed PDF is designed to be validated outside Signattio in any tool that understands PAdES — Adobe Reader, the EU's open-source DSS validator, or a command-line OpenSSL call. Public verification does not require an account.

From B-T to B-LT and B-LTA

The baselines are fixed in ETSI EN 319 142-1, the European profile for PAdES. B-T is the base plus a signature timestamp. B-LT adds a Document Security Store that embeds the validation material — the certificate chain and the revocation information (OCSP responses or CRLs) — inside the PDF itself, so validity can be demonstrated years later, when the responding services are long gone. B-LTA goes one step further and re-seals the whole before the digest algorithms age out.

Signattio's evidence pack records the level the signing service actually returns for each document. A self-issued seal without a configured timestamp authority is B-B; when an RFC 3161 authority answers, it is B-T. The level is reported as B-LT only when the full validation material — both chains and their revocation data — was embedded in the document security store and the result re-validated. The difference becomes relevant exactly when the proof has to outlive the certificates that produced it.

Check one yourself

Open the final PDF in Adobe Reader or another PAdES-aware validator: the signature panel shows the issuing certificate, whether the chain validates, and where the timestamp is. The EU's open-source Digital Signature Service (DSS) validator validates the levels and explains what each means.

Outside the PDF, Signattio's public verification code presents the same evidence pack — the document fingerprint, the timestamp authority and the hash-chained audit trail — without an account. The two layers complete each other: the file proves itself; the trail documents the ceremony.

Sources

  • Regulation (EU) No 910/2014, articles 3(11), 3(12), 3(34), 25, 26, 41, 42 — CELEX 32014R0910.
  • RFC 3161, Adams, Cain, Pinkas & Zuccherato, August 2001 — rfc-editor.org.
  • ETSI EN 319 142-1: PAdES — cited by name; it is a paywalled ETSI standard, not reproduced here.
  • EU open-source digital signature validator (Digital Signature Services — DSS).

This is an explanation of the technical record, not legal advice.

Read next

Qualified vs advanced electronic signature: what the law actually says

Where B-T sits on the eIDAS ladder — and when the law asks for more.

What a qualified timestamp is: RFC 3161 and eIDAS article 42

Inside the timestamp token: RFC 3161 fields and the article 41/42 presumptions.