PAdES vs PKCS#7: Understanding PDF Digital Signature Standards

Upload any signed PDF document to inspect its embedded PKCS#7 / PAdES signature dictionary, extract signing certificates, and calculate cryptographic hash integrity.

1. Fundamentals of PDF Digital Signatures

Unlike simple electronic signatures (which are merely visual image overlays or scanned handwriting marks), a cryptographic digital signature locks the binary integrity of a document using asymmetric Public Key Infrastructure (PKI).

When a PDF is signed, the PDF specification (ISO 32000) reserves a signature dictionary (`/Sig`) within the PDF structure containing specific keys:

• /ByteRange: An array of integers specifying the exact byte offsets and lengths of the document that are covered by the cryptographic signature.
• /Contents: A hex-encoded byte stream containing the actual ASN.1 cryptographic signature container (either PKCS#7 or PAdES format).
• /SubFilter: Identifies the signature encoding standard, such as adbe.pkcs7.detached, ETSI.CAdES.detached, or adbe.pkcs7.sha1.
• /M: The claimed signing timestamp recorded by the signer's computer or server clock.

2. PKCS#7 / CMS (RFC 5652) Signature Architecture

PKCS#7 (Public-Key Cryptography Standards #7), standardized by the IETF as Cryptographic Message Syntax (CMS - RFC 5652), is the historical standard for digital signatures in PDF documents.

Under the legacy SubFilter adbe.pkcs7.detached, the PDF file bytes outside of the /Contentshex container are hashed (typically using SHA-256 or SHA-1). The hash is then encrypted with the signer's private RSA or ECDSA key and encapsulated alongside the X.509 signer certificate and intermediate CA certificates.

3. ETSI PAdES (ISO 32000-2 & ETSI EN 319 142) Overview

PAdES (PDF Advanced Electronic Signatures) was developed by the European Telecommunications Standards Institute (ETSI) to meet rigorous European eIDAS regulation requirements and modern global enterprise security compliance.

PAdES extends CMS by embedding validation data (OCSP responses, CRL revoking data, and TSA timestamps) directly inside the PDF file structure itself. This enables Long-Term Validation (LTV), ensuring signatures remain verifiable decades after creation—even if the issuing CA shuts down or network CRL servers disappear.

PAdES Conformance Levels & Profiles

• PAdES-B-B (Basic Building Block): Includes the signed document hash, X.509 signing certificate chain, and cryptographic signature algorithm parameters.
• PAdES-B-T (Timestamp): Adds a cryptographically secure RFC 3161 timestamp issued by an independent Time Stamping Authority (TSA) to prevent post-dating or pre-dating fraud.
• PAdES-B-LT (Long-Term): Embeds all revocation evidence (OCSP responses and CRLs) into the PDF Document Security Store (DSS) dictionary at signing time.
• PAdES-B-LTA (Long-Term Availability): Periodically appends new document time-stamps to preserve cryptographic strength over years as algorithms evolve.

4. Comparing PKCS#7 vs PAdES: Technical Feature Matrix

5. How PDF SignCheck Validates Both Standards

PDF SignCheck features a unified hybrid parsing engine that handles both legacy PKCS#7 structures and advanced PAdES profiles seamlessly:

1. Byte Range Slice Parsing: Extracts the exact binary chunks defined by the PDF /ByteRange array without loading unnecessary memory headers.
2. ASN.1 DER Decoding: Decodes the hex /Contents payload to inspect X.509 certificates, public keys, signed attributes, and CRL/OCSP tokens.
3. Digest Recalculation: Re-computes SHA-256 document digests to detect even single-bit byte manipulations or post-signature modifications.
4. Root Trust Store Cross-Check: Checks certificates against Mozilla's Root CA store, Adobe Approved Trust List (AATL), and CCA India root certificates.
5. Visual Stamp Generation: Embeds a verified visual badge (`Signature Valid ✓`) into the document while preserving the original cryptographic byte ranges.

6. Frequently Asked Questions (FAQs)