This document describes how digital signatures are represented in a PDF document and what signature-related features the PDF language supports. Adobe® Reader® and Acrobat® have implemented all of PDF’s features and therefore provide comprehensive support for the authentication of digital data based on public key infrastructure (PKI) technologies. Third-party developers can define their own mechanisms in the form of an Acrobat plug-in signature handler.

Digital signatures can be used for many types of documents where traditional pen-and-ink signatures were used in the past. However, the mere existence of a digital signature is not adequate assurance that a document is what it appears to be. Moreover, government and enterprise settings often need to impose additional constraints on their signature workflows, such as restricting user choices and document behaviour during and after signing.

For these reasons, the PDF language provides mechanisms for two broad categories of tasks:

• Fully trusting an electronic document by enabling verification that the signed document has not
  been altered and that it was signed by someone the recipient trusts.
• Creating and controlling feature-rich and secure digital signature workflows.

In a PDF, signature information is contained in a signature dictionary. Objects in the dictionary are defined by the PDF Reference. The signature dictionary can reference, or be referenced by, other dictionaries. The entries in these dictionaries determine the nature and features of the signature, and by extension, what data can be available to any PDF viewer designed to process the signature data.

PDF’s digital signature capabilities are designed for compatibility with all the standards associated with mainstream public key infrastructures (PKI) deployed in enterprise and government settings. A PKI is the set of people, policies, procedures, hardware, and software used in creating, distributing, managing, and revoking, and using the digital IDs that contain the public/private key pairs used when signing a PDF.

In the context of PDF signature workflows, “PKI” generally refers to the digital ID issuers, users, administrators, and any hardware or software used in those workflows. PDF viewers that implement and conform to the PDF language specification are able to interact with all of these components in a seamless and robust way.

When signing an important paper document, a person usually signs it in front of a notary public or other trusted authority after providing them satisfactory evidence of their identity. Because the notary is deemed trustworthy, you can trust the signature the notary witnesses. Using a PKI is a method of providing a similar kind of trust.

Some common PKI components directly related to providing trust include:

• Certificate authority (CA): An ultimate trust authority that sells or issues digital IDs (such as Verisign or Geotrust). The CA signs it’s own certificate (self-signs) and its certificate is typically the “root” certificate at the top of the certificate chain.
• Intermediate certificates (ICAs): A type of CA whose certificate resides in the certificate chain between the end entity and root certificates. The certificate is not self-signed, and the ICA often provides services such as policies, timestamping, revocation lists, etc.
• End entity certificate (EE): The signer’s certificate and the last element of a signing chain. By definition, an end entity certificate does not contain the basic constraint value CA.
• Digital ID: An electronic representation of data based on the ITU-T X.509 v3 standard, associated with a person or entity. It is stored in a password-protected file on a computer or network, a USB token, a smart card, etc. A digital ID contains a public key certificate, a private key, and other data.
• Public key certificate: A file that contains the numeric public key portion of a public/private key pair along with the associated extensions and attributes used to define the certificates owner, validity period, and usage.
• Private key: The secret key in a PKI system, used to validate incoming messages and sign outgoing ones. A Private Key is always paired with its Public Key during those key generations.

PDF includes support for signatures to be embedded in the document itself, rather than managed as separate data or added on to an existing document format. This means that the viewing application can perform certain types of modification without invalidating the signature. With other digital signature formats, the user may need either two applications to handle both the document and the signature, or would need to manage two separate files for each signed document.

Each digital signature in a PDF document is associated with a signature handler. The signature is placed in a PDF signature dictionary which contains the name of the signature handler which will be used to process that signature. The signature handler built into Adobe Acrobat leverages Public/Private Key (PPK) cryptography technologies. PPK is based on the idea that a value encrypted with a private key can only be decrypted using the public key (the reverse may also be true when encrypting documents for specific recipients, but that is outside the scope of this document).

When a PDF is signed, the signer’s certificate is embedded in the PDF file. Digital ID stored on the user’s hardware device and the signature value embedded in the PDF document. The signature value may also include additional information such as a signature graphic, a time stamp, and other data that may be specific to the user, system, or application.

Since private and public keys are merely numbers, anyone can generate a public and private key pair using any number of tools. Applications like Acrobat provide a mechanism to generate a self-signed certificate which binds a simple user-provided identity to a public key generated by the application; it is then signed using the corresponding private key. Obviously, there is nothing to prevent someone from generating a self-signed certificate with someone else’s name. Hence, an unknown self-signed certificate does not have a high level of assurance.

To solve this type of trust problem, organizations use a PKI that includes an independent authority that issues, records, and tracks digital IDs. Because PDF supports embedding the signer’s public key as part of the signature, document recipient always have it for signature validation. To validate a signature, the validator simply retrieves the signer’s certificate and compares it to their own list of trusted certificates:

1. The recipient’s application generates a one-way hash of the document using the same algorithm the signer used, excluding the signature value.
2. The encrypted hash value in the document is decrypted using the signer’s public key.
3. The decrypted hash value is compared to the locally generated hash value.
4. If they are identical, the signature is reported as known.