Few can deny the importance of electronic signatures in modern business. Companies that use electronic documents rely on electronic signatures to protect their documents and to ensure trust and confidence with their business practices.

The European Directive on a community framework for Electronic Signatures defines an electronic signature as "data in electronic form which is attached to or logically associated with other electronic data and which serves as a method of authentication."

Wikipedia defines an electronic signature (or digital, which is the same in our context) signature as follows:

A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives to a recipient reasons to believe that the message was created by a known sender, and that it was not altered in transit. Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery and tampering.

The first attempts to provide a mechanism of digitally signed documents were made in the early '80s, but the first commercial software package to offer digital signatures was Lotus Notes 1.0, released in 1989, which used the RSA algorithm.

RSA (which stands for Rivest, Shamir, and Adleman, who first publicly described it) is an algorithm for public-key cryptography. It is the first algorithm known to be suitable for signing as well as encrypting, and was one of the first great advances in public key cryptography.

Today, the most popular document format providing a mechanism for electronic signature is PDF (Portable Document Format), which enables users to exchange and view electronic documents easily and reliably, independent of the environment in which they were created or the environment in which they are viewed or printed.

The International Organization for Standardization published a new standard, ISO 32000-1, in 2008 identifying the ways in which an electronic signature, in the form of a digital signature, may be incorporated into a PDF document to authenticate the identity of the author and validate the integrity of the document's content.

These signatures are based on the same CMS (Cryptographic Message Syntax) technology and techniques as TS 101 733 (CAdES), but without the extended signature capabilities of CAdES. CAdES, which stands for CMS Advanced Electronic Signatures, describes the usage of electronic signatures in any generic file or email message, while PAdES, the issue of this article, deals strictly with PDF documents.

Contents

1. Why PAdES?
2. How to Deal with the PAdES Specifications
3. Long Term Validation
4. Who is PAdES For?
5. Application
6. Parts at a Glance
• Part 1: Overview
• Part 2: PAdES Basic - Profile Based on ISO 32000-1
• Part 3-1: PAdES Enhanced - PAdES-BES Profile
• Part 3-2: PAdES Enhanced - PAdES-EPES Profile
• Part 4: Long Term - PAdES-LTV Profile
• Part 5-1: PAdES for XML Content - Profile for Basic XadES Signatures of XML Documents Embedded in PDF Containers
• Part 5-2: PAdES for XML Content - Profile for Long-Term XAdES Signatures of XML Documents Embedded in PDF Containers
• Part 5-3: PAdES for XML Content - Profile for Basic XAdES Signatures on XFA Forms
• Part 5-4: PAdES for XML Content - Profile for Long-Term Validation XAdES Signatures on XFA Forms (XAdES-LTV)

Why PAdES?

In July 2009, ETSI (the European Telecommunications Standard Institute) published a new standard that would facilitate secure paperless transactions throughout Europe, in conformance with European legislation. The standard defined a series of profiles for PAdES - Advanced Electronic Signatures for PDF documents - that met all the requirements of the European Directive on a community framework for electronic signatures (Directive 1999/93/EC).

The new standard was developed by ETSI's Electronic Signatures and Infrastructure (ESI) Technical Committee in collaboration with PDF experts. PDF is defined in a ISO 32000-1 standard, so the ETSI activity included reviewing and documenting how ISO 32000-1 can satisfy the European Directive. The resulting PAdES standard, ETSI Technical Specification (TS) 102 778, also introduces a number of adaptations and extensions to PDF to satisfy the Directive's requirements.

A main benefit of PAdES is that it is being implemented by means of widely available PDF software: it does not require the development or customization of specialized software.

How to deal with the PAdES Specifications

The PAdES specifications consist of 5 parts. The following shows a brief summary of each.

• Part 1 is the overview.
• Part 2 is the basic form of PAdES. This is equivalent to what is already specified in ISO 32000-1.
• Part 3 is an enhanced form of PAdES, which includes an equivalent to BES and EPES as specified in CAdES (TS 101 733) and XAdES (TS 101 903).
• Part 4 specifies extensions to a PDF document to carry information to support validation of signatures long after they are created. This is referred to as PAdES LTV (Long Term Validation).
• Part 5 specifies the application of XAdES signatures applied to XML within PDF documents, either a general XML document or one using XFA. It includes profiles to support long term validation of signatures.

The PAdES, CAdES and XAdES standards can be downloaded free of charge from the ETSI website.

You can find more details in the Application section of this article.

Long Term Validation

The main requirement when creating PAdES was a feature called Long Term Validation. This is the ability of a signed document to stay valid long after signing, for many years or even decades. You may ask: "What is the problem? Just set the expiration date long enough, 50 years for example." But the problem is that the document may become invalid before the expiration date comes.

Suppose you lend money to a person, and this person gives you a digitally signed promissory note. Then this person becomes a Signer, and, when it comes to a court, you become a Verifier.

A conventional scheme for signing a document looks like this: To have an ability to digitally sign contracts, a Signer has to be registered in an organization called a Certificate Authority (CA) and obtain a digital certificate. This certificate states that the Signer is really the person the Signer claims to be and contains some necessary information about the Signer, including the Signer's public key. The private key must be kept in secret -- the loss of privacy immediately invokes certificate compromise. While the certificate is valid, you can prove that the Signer owes you the money.

But certificates may be revoked, even by the Signer. The private key may be lost, or at least lose its privacy. The cryptographic scheme of the Certificate Authority may be broken as a result of an attack. But you still need to prove in court that the promissory note was valid in the moment it was signed. The Long Term Validation being implemented must solve this problem.

Who Is PAdES For?

Who needs to implement the PAdES standard, specifically Part 4, which states the requirements for realizing Long Term Validation? Adobe and other developers of end-user applications like Acrobat? Or Certificate Authority programmers, who are responsible for creating validation data to be embedded in digital signatures?

ETSI claims that no changes have to be made in end-user applications.

For PDF documents, the signature data is incorporated directly within the signed PDF document, as an ink signature becomes an integral part of a paper document, allowing the complete self-contained PDF file to be copied, stored, and distributed as a simple electronic file. The signature can also have a visual representation as a form field, just as it might on a paper document. A significant advantage of PAdES is that it is being deployed by means of widely available PDF software: it does not require the development or customization of specialized software.

Also, ETSI will feed these European-specific elements back into ISO for inclusion in the next release of the PDF standard, ISO 32000-2.

Application

Links

• PAdES specifications

Parts at a Glance

The following sections provide a quick look at each part of the PAdES specifications.

Part 1: Overview

Part 1 describes the general features of PDF signatures.

Part 2: PAdES Basic - Profile Based on ISO 32000-1

Description

This profile specifies a PDF signature as currently specified in ISO 32000-1 [1]. The profile is specified in TS 102 778-2 [6].

Features

1. Supports serial signatures.
2. Recommends inclusion of a signature timestamp.
3. Recommends inclusion of revocation information.
4. The signature protects the integrity of the document and authenticates the signatory.
5. The signature can optionally include the "reasons" for the signature.
6. The signature can optionally include a description of the location of the signing.
7. The signature can optionally include the contact info of the signatory.
8. A "legal content attestation" can be used to indicate to the relying party the PDF capabilities that may affect the signed document (e.g., JavaScript).

Part 3-1: PAdES Enhanced - PAdES-BES Profile

Description

This profile specifies an advanced PDF signature based upon CAdES-BES as specified in TS 101 733 [2] with the option of a signature timestamp (CAdES-T).

Features

The features provided by this profile are very similar to the PAdES profile as specified in TS 102 778-2 [6]. CAdES is used instead of CMS and the profile gives guidance to avoid embedding potentially duplicated information.

1. The signature is encoded as CAdES-BES (see TS 101 733 [2]).
2. Must include a signing certificate reference.
3. Recommends inclusion of a signature timestamp. (CAdES-T).
4. Supports serial signatures.
5. The signature protects the integrity of the document and authenticates the signatory.
6. The signature can optionally include CAdES simple attributes (Signing Time, Signer Attributes, Content-Timestamp).
7. A "legal content attestation" can be used to indicate to the relying party the PDF capabilities that may affect the signed document (e.g., JavaScript).

Part 3-2: PAdES Enhanced - PAdES-EPES Profile

Description

This profile specifies an advanced PDF signature based upon CAdES-EPES as specified in TS 101 733 [2]. This profile is the same as the PAdES-BES profile with the addition of a signature policy identifier and optionally a commitment type indication.

Features

The features provided by this profile are very similar to the PAdES-CMS profile as specified in TS 102 778-2 [6]. CAdES is used instead of CMS and the profile gives guidance to avoid embedding potentially duplicated information.

1. The signature is encoded as CAdES-BES (TS 101 733 [2]).
2. Must include a signing certificate reference.
3. Must include a signature policy identifier.
4. Optionally includes a signature timestamp (CAdES-T).
5. Optionally includes a commitment type indicator.
6. Supports serial signatures.
7. The signature protects the integrity of the document and authenticates the signatory.
8. The signature can optionally include CAdES simple attributes (Signing Time, Signer Attributes, and Content-Timestamp).
9. A "legal content attestation" can be used to indicate to the relying party the PDF capabilities that may affect the signed document (e.g., JavaScript).

Part 4: Long Term - PAdES-LTV Profile

Description

This profile supports the long term validation of PDF signatures. Also it can be used in conjunction with the PAdES-CMS, PAdES-BES, or PAdES-EPES profiles.

This profile is applicable to any party relying on a signature over a long period (e.g., longer than the lifetime of the signing certificate). It may be applied by a party receiving and verifying the document or the signing party, who should also verify the document when applying LTV.

Features

This profile adds the following to the features of the PAdES-CMS, PAdES-BES, or PAdES-EPES profiles described above:

1. The addition of validation data to an existing PDF document, which may be used to validate earlier signatures within the document (including PDF signatures and timestamp signatures).
2. The addition of a document timestamp, which protects the existing document and any validation data.
3. Further validation data and a document timestamp may be added to a document over time to maintain its authenticity and integrity.

Part 5-1: PAdES for XML Content - Profile for Basic XadES Signatures of XML Documents Embedded in PDF Containers

Description

This is the first of two profiles that profile the usage of a signed XML document that is embedded within a PDF container, for providing integrity, authentication, and nonrepudiation services on the XML data objects that are signed with the XAdES signature. The XML document may be aligned with any XML language, i.e., a signed UBL e-invoice.

This profile specifies requirements for the basic XAdES forms (XAdES-BES, XAdES-EPES, and XAdES-T).

Features

The main features provided by this profile are listed as follows:

1. The XML signed document is created independently from the PDF container. The profile also puts requirements on the relative placement of XAdES signatures and the signed data objects.
2. The XAdES signatures present within the embedded signed XML document protect the signed objects and provide integrity and authenticity. Additionally, the incorporation of a signature timestamp also allows nonrepudiation of signature production.
3. The following XAdES signature forms are profiled: XAdES-BES, XAdES-EPES, and XAdES-T (see TS 101 903 [3]).
4. This profile supports serial signatures using XAdES countersignature mechanisms.
5. This profile supports parallel signatures.

Part 5-2: PAdES for XML Content - Profile for Long-Term XAdES Signatures of XML Documents Embedded in PDF Containers

Description

This is the second of two profiles that profile the usage of arbitrary signed XML content (that may be aligned with any XML language, i.e., a signed UBL e-invoice) that is embedded within a PDF container as an attached file, for providing integrity, authentication, and nonrepudiation services on the XML data objects that are signed with the XAdES signature.

Features

This profile adds to the profile in Part 5-1 the features listed as follows:

1. Long-term signature production.
2. The signature is encoded as XAdES-C, XAdES-X, or XAdES-XL, XAdES-A (see TS 102 903 [3]).

Part 5-3: PAdES for XML Content - Profile for Basic XAdES Signatures on XFA Forms

Description

This is the first of two profiles that profile the usage of XAdES signatures to sign dynamic XFA forms. XFA defines an XML-based architecture for building up and completing forms where the data is held as XML elements.

Features

The main features provided by this profile are listed as follows:

1. The XAdES signature will be able to sign XFA data only or any XML content from XFA allowed by the XFA specification [i.2].
2. The XAdES signature protects the integrity of what is signed and authenticates the signatory. Additionally, the incorporation of a signature timestamp also allows nonrepudiation of the signature production.
3. The signature is encoded from XAdES-T or XAdES-BES or XAdES-EPES (see TS 101 903 [3]).
4. This profile supports serial signatures.
5. This profile supports parallel signatures.

Part 5-4: PAdES for XML Content - Profile for Long-Term Validation XAdES Signatures on XFA Forms (XAdES-LTV)

Description

This is the second of two profiles that profile the usage of XAdES signatures to sign dynamic XFA forms. XFA defines an XML-based architecture for building up and completing forms where the data is held as XML elements.

Features

1. Features a), b), d), and e) of the profile defined in Part 3.
2. The signatures aligned with this profile provide equivalent features as XAdES-XL and XAdES-A forms.