PDF Java Toolkit

Digital Signatures in PDF

PDF offers two dictionaries related to digital signatures, signature fields and signatures.

Signature fields are form fields that can be filled in, or signed. It is not necessary to sign every signature field in a PDF document. If a user adds a signature to a signature field a signature dictionary is attached to that field. The signature dictionary holds the digital signature, and this dictionary is added to the signature field when the PDF is signed. When the PDF document is signed the document’s data is written to a new byte stream. The digital signature itself is a signed hash of the document’s bytes or a selective hash of some subset of the document’s object tree.

A PDF document can hold other signature values. For example, a PDF can have a digital signature that is not attached to a signature field, such as a Usage Rights signature or a DocMDP signature. These signatures are both used to control document permissions and are accessed via the Perms entry in the document’s Catalog.  See “Permissions,” Section 12.8.4, of the ISO 32000 document, page 476. This document is found on the web store of the International Standards Organization.

There are two techniques for computing a digital signature within a PDF file, byte range signatures and modification detection specified by a signature reference dictionary.

Byte range signatures are the basic method for managing digital signatures in PDF documents and are used for recipient and author signatures.  Byte range signatures place spaces in the PDF to hold the signature data, and the signature is computed over the balance of the document. This means that all of the data in the PDF document, except for the byte range signature itself, is included in the signature digest. This allows for tamper detection of any of the PDF data.  For more detail see Section 12.8.1, “Digital Signatures: General” of the ISO 32000 document, page 466.

Filters and Subfilters in PDF

The signature dictionary defines a filter and subfilter that are used to select an appropriate signature handler. The filter specifies a preferred handler while the subfilter specifies the signature type. It is not necessary that a signature handler exist to match the filter. The PDF can use a signature handler that matches the subfilter instead, if a handler that matches the filter is not available.

PDF Java Toolkit’s digital signature handlers conform to the Adobe PPKLite signature handler used in Acrobat. PDFJT also uses the filter designation of Adobe.PPKLite to match the Acrobat implementation.

The PDF Java Toolkit digital signature handlers support the three standard subfilter types:

  • x509.rsa_sha1
  • pkcs7.sha1
  • pkcs7.detached

Any of these subfilter types can be used to support recipient or author signatures.

For more detail, see Section 12.8.3, “Signature Interoperability,” of the ISO 32000 document, page 474. This document is found on the web store of the International Standards Organization.

This table matches the subfilter types to the byte range digest. The values are case sensitive.

Subfilter Byte range digest
adbe.x509.rsa_sha1 SHA1
adbe.pkcs7.sha1 SHA1
adbe.pkcs7.detached MD5/SHA1/SHA256

A byte range digest is computed over a range of bytes in the file to be signed. The hash algorithm to be applied when computing the byte range digest is specified as a byte range digest method.

  • The default byte range digest method is SHA1.
  • Clients can specify the hashing algorithm to be used for byte range signatures by calling SignatureOptions.setDigestMethod(String), the SetDigestMethod in the SignatureOptions class

Types of Signatures

The types of digital signatures discussed in this document are specified in Section 12.8, “Digital Signatures,” of the ISO 32000 document, page 466. This document is found on the web store of the International Standards Organization.

Recipient and Author Signatures use Modification Detection and Prevention (MDP) restrictions, designed to protect the signature and other fields from being changed after a PDF document is signed.

Recipient Signatures

Recipient signatures are also known as ordinary or document signatures. A recipient signature is the type of signature created when you sign a PDF document in Acrobat.
Recipient signatures use a byte range signature. A PDF document may contain more than one recipient signature.  Each time a PDF is signed using a recipient signature, the document is saved incrementally for that signature.  The save includes any recent changes made to the document itself.  Recipient signatures can be signed or unsigned.

Recipient signatures may have FieldMDP restrictions in effect.

Author Signatures

Author signatures are also known as certifying or DocMDP signatures.  A PDF document may have only one author signature.  Adobe Acrobat creates an author signature in a PDF when the document is certified.  An author signature specifies what kinds of changes are permitted after the signature has been applied.

Unsigned recipient signature fields, created before certification is applied, can be signed after the document is certified if the author signature allows it. This means that a PDF document may contain one author signature and multiple signed or unsigned recipient signatures fields. Author signatures use a byte range signature.

Author signatures are used in workflows where an author wants to stipulate what kinds changes are allowed to the document after having signed it. The author signature computes a byte range signature.

The PDF format examines incremental save records in a document to detect objects that have been altered.  Also, DocMDP workflows may use FieldLocks, applied when recipient signatures are signed in a PDF document after the document is certified. In this case, FieldMDP transforms are created on the signature being signed and the relevant information on which fields should be protected is transferred from the FieldLock dictionary to the FieldMDP transform dictionary. The FieldMDP transform is then processed so that tampering with those fields can be detected later. A DocMDP workflow may have more than one signature fields that are pre-configured to allow signing and appropriate locking by other recipients. The original document provides the necessary tamper detection so that the recipients can trust that they are signing the document as created by the author.

Usage Rights Signatures

Usage rights signatures (UR3) differ from recipient and author signatures in that they are not attached to a signature field. Instead, usage rights signatures show up only in the Perms entry of the document’s Catalog. As such, the usage rights signature creation method do not take aSignatureField as a parameter as do the sign() and certify() methods. Usage rights signatures do not require support for timestamping, CRLs, or OCSP.

Usage rights signatures also differ from recipient or author signatures in what they hold in their transform parameters dictionary.

These signatures carry a list of “rights” that should be enabled in the Adobe Reader, or Reader Extensions. See the section called “Providing Reader Extensions for PDF Documents” in the PDF Java Toolkit Sample Program Guide. See also “Permissions,” Section 12.8.4, of the ISO 32000 document, page 476. This document is found on the web store of the International Standards Organization.

These rights will need to be passed in to the method for creating the signature along with credentials that chain up to the Adobe root certificate. So, other than lacking a signature field parameter, the method to apply usage rights will be very similar to the methods for signing or certifying a signature field. The method will need the list of usage rights, credentials, and a byte writer.

When applying a usage rights signature, the client specifies which rights should be granted in Adobe Reader. These rights must correspond to rights embedded in the certificate in order to be honored in Adobe Reader.

UR signatures compute a byte range digest and rely on PDF interrogation during validation. This is to determine if any changes have been made to the PDF document after the signatures were added, changes that are not permitted.

PKCS#7 vs. PKCS#1

The Public Key Cryptography Standards (PKCS) is part of a family of standards first published in the early 1990s by RSA Laboratories.

The standard signature subfilters store digital signatures in one of two formats for the PKCS, PKCS#1 or PKCS#7.

PKCS#1 refers to a standard that defines simple encodings for Public Key Infrastructure (PKI) constructs. In this case, the PKCS#1 packet only contains the digital signature itself, so other structures must be used to hold the certificate and certificate chains.

PKCS#7 defines a Cryptographic Message Syntax (CMS) that can be used to bind data and cryptographic collateral together in a variety of ways, such as SignedData or EnvelopedData. For PDF signatures, the digital signature and related certificates are bound together in a PKCS#7 SignedData packet. This PKCS#7 packet contains either a digital signature of the hash of the PDF’s data (for the adbe.pkcs7.sha1 subfilter) in the SignedData or it contains a digital signature of the data in the PDF document, where the PKCS#7 SignedData packet is detached.  “Detached” means that the SignedData packet does not itself contain the original data.

For PKCS#1 processing, PDF Java Toolkit uses the RSA asn1 library. For PKCS#7 processing PDF Java Toolkit uses the RSA cert-j library.


PKCS#12 defines a file format used to store cryptography objects in a single file.

This file format, Personal Information Exchange (.pfx), is used to bundle in one place all of the members of a certificate chain of trust. A PFX file can be encrypted and signed. A PFX file differs from a certificate (.crt) file in that the PFX is an archive that can contain a variety of objects with optional password protection. A PDF commonly holds a certificate, with assorted CA certificates, and a private key. A CRT file only holds a single certificate, without a password and without a private key.

The PFX file is made up of a set of internal containers called “SafeBags.” These SafeBags are used to hold certificates, private keys, and CRLs, as well as whatever else the party that creates the file may want to place in a secured storage space.