What is a PAdES signature, and what does a document seal prove?

How a PDF digital signature works

When a PDF is digitally signed, the software reserves an empty slot in the file for the signature and records a byte range: everything in the file except that slot. It computes a hash of those bytes — a fixed-length fingerprint such as SHA-256 — and signs the hash with a private key. The result, a CMS (Cryptographic Message Syntax) signature that includes the signer’s certificate, is written into the slot.

To verify, a reader recomputes the hash of the same byte range and checks it against the signature using the public key in the certificate. If a single byte in the covered range has changed, the check fails. If bytes were added after the signed range, the signature itself still verifies, and a good validator reports that the document was changed after signing.

What PAdES adds

PAdES is a set of profiles, published by ETSI as EN 319 142, that pins down how these signatures are built so they can be validated consistently, particularly under the EU’s eIDAS framework. The baseline profiles have four levels, each building on the one before:

• B-B (basic): the signature, with the signing certificate bound into the signed data.
• B-T (timestamp): adds a trusted timestamp showing the signature existed at a specific time.
• B-LT (long-term): adds the certificates and revocation information needed to validate the signature later, even if online services are gone.
• B-LTA (long-term archival): adds document timestamps that can be renewed so the evidence stays verifiable as algorithms age.

RFC 3161 timestamps

A timestamp under RFC 3161 comes from a time-stamping authority (TSA): you send it a hash, and it returns a signed token binding that hash to the current time. The TSA never sees the document. The token provides proof that the data existed before that time, independent of the signer’s own clock, which could be set to anything. In a PAdES B-T signature, the token covers the signature value, so it dates the signature.

Electronic signature, digital signature, seal

These terms get used interchangeably but mean different things. An electronic signature is a legal concept: a mark or process that shows a person’s intent to sign, such as a typed name or a drawn signature. A digital signature is a cryptographic mechanism that protects a file’s integrity. A seal, in eIDAS terms, is a signature made by an organization rather than a person, and in everyday use it means a cryptographic signature applied by a service to certify a document as issued. A drawn signature on a page and a cryptographic seal on the file can coexist; they answer different questions.

What a seal proves — and what it doesn’t

A valid seal proves that the covered bytes haven’t changed since sealing, that the holder of a particular private key signed them, and — with a timestamp — that this happened no later than the stated time.

It doesn’t prove that the content is true or fair, that the person named in the document is who they say they are, or that they read and agreed to it. Identity depends on how the certificate was issued and on the separate evidence of who signed. Trust depends on the certificate: readers such as Adobe Acrobat trust certificates that chain to their trust lists (Adobe’s Approved Trust List, the EU Trusted Lists), and show others as ‘validity unknown’ even when the cryptography is intact.

How GhostSign seals a document

When you sign with GhostSign, the signing happens in your browser. To seal the finished file, the browser computes the SHA-256 hash of the PDF’s byte range and sends only that hash to GhostX’s server — not the document. The server signs it with an RSA-3072 key held in Google Cloud KMS at the HSM protection level, obtains an RFC 3161 timestamp from DigiCert or Sectigo over the signature value, and returns the signature, which the browser writes into the PDF. The result is a PAdES B-T certification signature that permits no further changes. The server also stores an append-only evidence record keyed by the hash, with no names, emails, or document content.

The limits, stated plainly: the seal certificate is issued by GhostX itself and is not on Adobe’s Approved Trust List, so Acrobat shows the seal as intact but the signer identity as unknown. Long-term validation data (B-LT) is not embedded yet. The signer’s name on the certificate page is self-attested; email verification is optional. And if sealing fails, the file is issued unsealed and its certificate says so. GhostX’s /verify page checks GhostX seals and the timestamp in your browser.

Frequently asked questions

• Is a PAdES signature legally binding?

  PAdES is a technical format, not a legal status. In the US, the ESIGN Act and UETA generally recognize electronic signatures without requiring any particular format; in the EU, eIDAS defines levels of electronic signature with different legal effects. What makes a signature enforceable depends on the jurisdiction and evidence of intent. This is general information, not legal advice.

• Why does Adobe say ‘signature validity is unknown’?

  Acrobat shows that when the signing certificate doesn’t chain to a certificate it trusts, even if the document is unchanged. It is common for self-issued certificates, including GhostX’s current seal certificate.

• What is the difference between PAdES B-T and B-LT?

  B-T adds a trusted timestamp to the signature. B-LT also embeds the certificates and revocation data needed to validate the signature years later without contacting online services.

• Can a sealed PDF be edited?

  Any change to the sealed bytes breaks the seal. Changes appended after sealing leave the seal verifiable but are reported by validators as modifications made after signing.

References

• ETSI EN 319 142-1 V1.2.1 — PAdES digital signatures, Part 1: Building blocks and baseline signatures
• RFC 3161 — Internet X.509 PKI Time-Stamp Protocol (TSP)