How Hash/Digest Signing Works for PDF (PAdES)

PAdES (PDF Advanced Electronic Signatures) is the standard for applying electronic signatures to PDF documents. Within this standard, PAdES hash signing is a specific method that focuses on signing a cryptographic hash of the document—not the full document itself.

Let’s break down how it works, what to watch out for, and how it interacts with trust service providers (TSPs) and qualified electronic signature regulations like eIDAS.

What Happens During PAdES Hash Signing?

When performing PAdES hash signing:

• The PDF file is modified to include a signature dictionary.
• This dictionary contains metadata such as the time, location, reason for signing, and optionally, a visible signature widget.
• The signature itself is encoded using the CMS format, which can be either:
  • ETSI.CAdES.detached (eIDAS compliant), or
  • adbe.pkcs7.detached (an older Adobe format)

The Two Critical Digest Types (Don't Mix Them!)

To successfully sign a document using PAdES, you must know there are two different digests involved. Mixing these up will cause the signature to fail due to cryptographic errors.

1. Digest of Content Being Signed

• This is the hash of the PDF without the actual signature data.
• To calculate this:
  • Take the PDF where the signature dictionary is already created.
  • Remove all characters in the ByteRange Contents section (between < and >).
  • Hash the resulting byte stream using SHA256 or SHA512.
• This method can be used to create a CAdES signature without needing the signer’s public certificate upfront.

2. Digest of Content + Signed Attributes (DTBSR)

• Also called the Data To Be Signed Representation (DTBSR).
• Includes:
  • Digest of the PDF
  • The signer's public certificate
  • Additional signed attributes
• To create this, the TSP must provide an API that allows retrieving the signer’s public certificate beforehand.

How Does This Affect the Trust Service Provider (TSP) Workflow?

Depending on which digest is submitted to the TSP, different outcomes are possible:

If TSP receives the Digest of Content Being Signed:

• Returns a CMS signature, like CAdES.
• For eIDAS, CMS/CAdES is allowed in PAdES, but:
  • It must not contain the signingTime attribute.
  • Relaxed validators may ignore this, but strict ones will reject the signature.

If TSP receives the DTBSR:

• Returns a PKCS #1 signature, which is the raw building block for:
  • XAdES
  • CAdES
  • PAdES
  • ASiC
• This method is preferred, especially in cross-border or multi-standard environments.

Why DTBSR is the Preferred Method

Different countries and regulatory frameworks recognize different digital signature formats. By using DTBSR and receiving a raw PKCS #1 signature, the result can be shaped into any higher-level format needed, including:

• XAdES Baseline Profile – ETSI TS 103171 v.2.1.1
• CAdES Baseline Profile – ETSI TS 103173 v.2.2.1
• PAdES Baseline Profile – ETSI TS 103172 v.2.2.2
• ASiC Baseline Profile – ETSI TS 103174 v.2.2.1

Additional Reading

To understand the underlying structure behind CMS signatures, see the official RFC: RFC 5652 – Cryptographic Message Syntax (CMS)