Contracts, academic certificates, and government documents all face the same challenge: proving they haven’t been altered and that the signer is who they claim to be. PDF digital signatures solve this problem using well-established cryptography standards. This post covers the key standards behind PDF digital signatures and explains how they protect your documents.

The basics of PDF digital signatures

What is a digital signature?

A digital signature is a mathematical scheme used to validate the authenticity and integrity of a message, software, or a digital document. In the context of PDFs, digital signatures are akin to traditional handwritten signatures, but they offer additional security benefits, namely, ensuring a document hasn’t been altered since it was signed and that the signature is from a verified source.

Key cryptographic concepts

To understand PDF digital signatures, it’s important to grasp some fundamental cryptographic concepts:

• Hash algorithms — A hash algorithm takes an input (or message) and returns a hash value (or digest), which is a fixed-size string of bytes that appear random. Hash algorithms are designed to be one way (it’s infeasible to invert them) and collision-resistant (it’s hard to find two different inputs that produce the same output). Common hash algorithms include SHA-256, SHA-384, and SHA-512.
• Public key infrastructure (PKI) — PKI is a framework for managing digital keys and certificates. It involves a pair of keys: a private key (kept secret by the owner), and a public key (distributed widely). The private key is used to create a digital signature of the message, while the public key, shared with anyone who needs to verify the signature, is used to confirm the signer’s identity.
• Certificates — These are digital documents that certify the ownership of a public key. They’re issued by certificate authorities (CAs) and include information about the key owner and the CA that issued the certificate. Certificates play a crucial role in establishing trust. They ensure that the public key used to verify a digital signature indeed belongs to the entity it claims to represent. The system of trust for certificates relies on a hierarchy of CAs.

PDF digital signature creation

When a user signs a PDF, a cryptographic process generates a digital signature. This process involves:

1. Hashing — The PDF content is processed through a hash algorithm, producing a document digest. This digest uniquely represents the document’s content. Even a small change in the document will result in a completely different hash value.
2. Creation of a signature — The signer uses the private key to create a digital signature of the hash of the document’s content. The result, along with the signer’s certificate and signature metadata (e.g. algorithms used for hashing and signing), constitutes the digital signature.
3. Embedding — The digital signature and the associated certificate are embedded into the PDF document. This makes the signature an integral part of the document.

Each document can be signed multiple times. The way this works is that each signature is added incrementally and guards the previously signed and edited parts of the document.

PDF digital signatures verification

When a recipient receives a digitally signed PDF, they can verify the signature through the following steps:

1. Hash recalculation — The recipient’s PDF viewer software calculates the hash value from the received document using the same hash algorithm used during signing.
2. Verification — The recipient’s software then uses the signer’s public key and the recalculated hash to verify the digital signature and report whether or not the document is unaltered.
3. Certificate validation — The software also checks the signer’s digital certificate to ensure it’s issued by a trusted CA and hasn’t expired or been revoked. This step confirms the signer’s identity.

If all these checks pass, the signature is considered valid, confirming the document’s integrity and the authenticity of the signer.

Types of PDF signatures

PDF signatures come in various forms, each offering a different level of security and legal validity. Understanding the distinctions between these types is crucial for choosing the right one for your needs. Below, we outline the three main types of electronic signatures used in PDFs, ranging from basic to highly secure.

1. Simple electronic signatures (SES) — These are simple signatures that might include a scanned image of a handwritten signature or a typed name. They lack robust security features and are easily replicated.
2. Advanced electronic signatures (AES) — These signatures are created using a unique signing key controlled by the signer, with the identity verified by a trusted authority. They offer higher security by ensuring a signature is uniquely linked to the signer and the document.
3. Qualified electronic signatures (QES) — These signatures provide the highest level of security and legal standing. They require a qualified certificate issued by a trusted certification authority and are created using secure signature creation hardware or software.

You can read more about digital signatures in our guides.

Overview of PKCS standards

Public key cryptography standards (PKCS) are a major part of the spectrum of the digital signatures ecosystem. Developed by RSA Laboratories, the PKCS family consists of several standards, each addressing different aspects of public key cryptography. These standards collectively cover the basics of cryptographic operations necessary for document signing. We’ll cover the most important (and still maintained) PKCS standards here.

PKCS #1: RSA cryptography standard

PKCS #1 defines the RSA algorithm, which is fundamental for digital signatures and encryption. The standard specifies the mathematical properties and encoding methods for RSA keys and the processes for encryption, decryption, and signing:

• RSA key pair generation — Defines how to generate public and private RSA keys.
• Encryption and decryption — Outlines methods for encrypting data with the public key and decrypting it with the private key.
• Digital signing and verification — Details how to create a digital signature using a private key and verify it using the corresponding public key.

In the context of PDF signing, PKCS #1 ensures that a signature generated using RSA is robust and secure. For more details, refer to RFC 8017(opens in a new tab).

Signature schemes

Within PKCS #1, there are two primary signature schemes used to create and verify digital signatures:

• RSASSA-PKCS1-v1_5 is one of the oldest and most widely used RSA signature schemes. It was first standardized in version 1.5 of PKCS #1 and has been a cornerstone of digital signatures for many years. RSASSA-PKCS1-v1_5 uses a deterministic approach for generating signatures. The process involves hashing the message to be signed, padding the hash value, and then applying the RSA algorithm to produce the signature. The padding scheme ensures that the hash is of a fixed size and format, making it suitable for RSA operations. Despite its age, RSASSA-PKCS1-v1_5 remains secure and unforgeable when appropriately implemented. However, due to its deterministic nature, it lacks some of the advanced security features found in newer schemes.
• RSASSA-PSS is an improved signature scheme introduced to address some of the limitations of RSASSA-PKCS1-v1_5. RSASSA-PSS incorporates a probabilistic approach to signature generation. This means that even if the same message is signed multiple times, the resulting signatures will be different due to the use of random salt values. The process involves hashing the message, applying a special function to introduce randomness, and then using RSA to produce the signature. The probabilistic nature of the scheme helps protect against certain types of attacks, making it more robust in a variety of cryptographic scenarios.

PKCS #6: Extended-certificate syntax standard (X.509)

PKCS #6 is obsolete and is no longer maintained by RSA Laboratories. It has been replaced by version 3 of the X.509 certificates specification(opens in a new tab).

X.509 is a widely used standard for defining the format of public key certificates. These certificates are a critical component of public key infrastructure. X.509 certificates serve as digital passports, verifying the identity of parties involved in online transactions, and ensuring the confidentiality and integrity of data exchanged.

X.509 certificates operate within a hierarchical trust model. Certificate authorities issue certificates to entities, and these certificates can form a chain of trust, where each certificate is validated by the subsequent one until reaching a root certificate that’s inherently trusted by the system. This trust model ensures the integrity of the certificates and the security of the communication channels established using them.

PKCS #7: Cryptographic message syntax standard

PKCS #7, also known as Cryptographic Message Syntax (CMS), is pivotal for creating and reading signed data. It defines the general structure of the “signature container” used to store digital certificates and digital signatures.

In a context of PDF signing, you might also encounter CMS Advanced Electronic Signatures (CAdES) along with CMS. CAdES extends CMS by adding specific attributes and enhancements to ensure long-term validity and compliance with European standards. This includes timestamps, a certificate revocation status, and other features that enhance the trustworthiness and longevity of a signature.

When a PDF is signed, the signature and relevant certificates are often encapsulated in a PKCS #7 container, ensuring the integrity and authenticity of the document. For more details on CMS, refer to RFC 5652(opens in a new tab). For CAdES, refer to ETSI TS 103 173(opens in a new tab) and our guides.

PKCS #8: Private-key information syntax standard

PKCS #8 is a standard that defines the syntax for private-key information, enabling the secure storage and transport of private keys. It provides a comprehensive format for encoding private key data, ensuring private keys are handled securely and consistently across different systems and applications.

PKCS #8 uses Abstract Syntax Notation One (ASN.1(opens in a new tab)) to define the structure of the private-key information, which is then encoded using Distinguished Encoding Rules (DER). This ensures a standardized, interoperable format for private keys.

• DER encoding — A binary format that provides a compact, unambiguous representation of the ASN.1 data structures.
• PEM encoding — Often, DER-encoded private keys are further encoded using Base64 and encapsulated between header and footer lines (e.g. -----BEGIN PRIVATE KEY-----), producing a PEM file. This format is human-readable and commonly used in various cryptographic applications for storing private keys, certificates, certificate sign requests, etc.

PKCS #10: Certification request standard

PKCS #10 defines the format for a certificate signing request (CSR). This request is sent to a CA to obtain a digital certificate, which is essential for verifying signatures. Certificate signing requests include a public key, information about a subject’s identity, and other optional attributes.

PKCS #11: Cryptographic token interface standard

PKCS #11 defines a platform-independent API for interacting with cryptographic tokens, such as hardware security modules (HSMs). These devices securely manage and store cryptographic keys and perform operations like signing and encryption.

In the context of PDF signing, PKCS #11 enables the use of HSMs to securely store signing keys and perform signing operations, ensuring high security and compliance with regulatory requirements. For more details, refer to the OASIS PKCS #11 Specification(opens in a new tab).

PKCS #12: Personal information exchange syntax standard

PKCS #12 defines a container format for securely storing and transporting a user’s private keys, certificates, and other secrets.

In PDF signing, PKCS #12 files are often used to store and transport the signer’s private key and certificate securely, enabling the signing process. For more details, refer to RFC 7292(opens in a new tab).

Integrating PKCS standards in PDF document signing

To provide you with a better overview of what was presented in this post, this section will map the various PKCS standards to the most important aspects of PDF document digital signing:

1. Key generation — The process begins with generating a public-private key pair using RSA (PKCS #1).
2. Certificate request — A certificate signing request (PKCS #10) is created and sent to a CA to obtain a digital certificate.
3. Certificate storage — The private key and certificate (X.509) are stored securely in a PKCS #12 container.
4. Signature creation — The PDF digest is signed via RSA (PKCS #1), and the signature, along with the necessary certificates, is encapsulated in a PKCS #7 container. Using additional attributes defined by CAdES can provide additional features for long-term validation.
5. Hardware secure module utilization — If an HSM is used, the PKCS #11 API is used to interact with the secure store of the signing keys and certificates.

Enhance your digital workflow with Nutrient’s signature solutions

Nutrient’s SDK handles the cryptographic complexity for you. Here’s a basic example using the Web SDK to sign a PDF with a PKCS#7 signature:

// Load the PDF and sign it.
const instance = await NutrientViewer.load({
  document: "document.pdf",
  container: "#viewer",
});
// Sign using a callback that returns a PKCS#7 signature.
await instance.signDocument(null, async ({ fileContents }) => {
  // 1. Hash the document content (SHA-256).
  // 2. Sign the hash with your private key (RSA via PKCS#1).
  // 3. Wrap in PKCS#7 container with certificate.
  const signature = await createPKCS7Signature(fileContents, privateKey, certificate);
  return signature;
});

The signDocument method accepts a callback where you implement the signing logic. Your callback receives the document contents, and you return a PKCS#7 signature as an ArrayBuffer. For a complete implementation with certificate handling, see our Web SDK signing guide.

If you’re interested in exploring how to integrate these solutions, refer to our comprehensive signature guides:

• For server-side workflows, check out our Document Engine guide.
• For web-based apps, explore our Web SDK guide.
• For mobile, explore our Android and iOS guides.
• If you’re targeting desktop or hybrid solutions, you can find the appropriate guides for your platform of choice here.
• We also offer a simple-to-integrate API endpoint for signing documents with advanced digital signatures that validate in Adobe and other PDF readers. Check out our advanced eSignatures API.
• For sensitive documents, consider redacting PII before signing to ensure compliance and protect personal data.

These guides provide detailed instructions and best practices to help you get started quickly and effectively.

FAQ

Conclusion

PKCS standards form an integrated system for PDF digital signatures: RSA handles key generation, PKCS #10 manages certificate requests, PKCS #12 provides secure key storage, and PKCS #7 wraps the final signature. Together, they ensure your signed documents remain authentic and tamper-evident. To implement these standards in your own applications, explore Nutrient’s SDK documentation for digital signature support.