digital signatures in acrobat - adobe inc. · 2019-11-27 · be set by the user or system...

Digital Signatures in Acrobat

Introduction

Digital signatures in PDF and

in Adobe® Acrobat® are described in two documents:

•

Digital Signatures in the PDF Language

— describes how signatures are represented in PDF and how signature security is based on features in the PDF language. It also discusses certified documents and explains why they are a critical part of secure digital signature workflows.

•

Digital Signatures in Acrobat

(this document) — describes Adobe’s Acrobat implementation of PDF language features and explains how Acrobat does dynamic validation of digital signatures.

This document also describes how certificates and signing procedures can be managed by IT administrators and how document content can interact with signatures. In addition, application differences, Reader enabling, and Adobe LiveCycle® dynamic forms are discussed.

Although this document discusses validation in relation to its default signature handler, the Acrobat plug-in architecture enables third-party developers to create custom signature handlers to support functions not implemented in Acrobat.

Prerequisites

This section describes how Acrobat validates digital signatures in a PDF

document. For validation to be trusted, the following practices and criteria

However, the validation cannot be trusted if it is attempted without the following practices and infrastructure being in place:

•

The person signing the document must have a valid digital ID that links to a trusted anchor.

•

A Public Key Infrastructure (PKI) system must be in place, so that Acrobat can query the Certificate Authority (CA) and timestamp servers to verify identities, certificate status, and time of signing for each signature.

•

Each user must be connected to the Internet at the time they sign or try to validate a signature.

The complete process is described in the following sections.

Developer Technical

Note

C

O N T E N T

S

P

r

er

equisit

es

1

V

alida

ting Dig

ital Sig

na

tur

es

2

M

anag

ing C

er

tifica

t

es in an En

t

er

pr

ise

En

vir

onmen

t

7

I

n

t

er

ac

tions B

et

w

een Sig

na

tur

es and

D

ocumen

t C

on

t

en

t

11

A

pplica

tion Diff

er

enc

es

12

A

dobe R

eader Enabling

12

Liv

eC

y

cle D

ynamic F

or

ms with Dig

ital

Sig

na

tur

es

12

R

esour

c

es

13

A

ppendix: S

tandar

ds U

sed b

y A

cr

oba

t

15

2

Dig

ital Sig

na

tur

es

in A

cr

oba

t

Validating Digital Signatures

When the user opens a signed document, and the above prerequisites have been

met, Acrobat performs the following steps to validate a digital signature.

1.

The document is checked to make sure it has not been altered since it was signed.

Acrobat checks if the hash value calculated for the document is the same as the hash from the signature. If they are not equal, the validation continues but the user is notified that the document has been altered.

2.

The signer’s certificate is checked to make sure it links to a trusted anchor.

A certificate chain is built, starting with the end-entity certificate associated with the signature. There may be multiple paths built to intermediate certificate authorities (ICAs), but at least one path must be found to a trust anchor.

3.

Revocation checking is performed to verify that the signer’s certificate was valid at the time of signing.

Revocation checking (see “Revocation Checking” on page 6) is done for the end-entity certificate, using either OCSP or CRL. If only one is referenced, that one is used. If both are referenced, OCSP will be tried first.

N

O T E

:

P

references for which revocation checking method is used, whether the local time or server timestamp is used, and other preferences can be set by the user or system administrator.

The revocation check consists of the following:

3a.

Because the OCSP or CRL response will itself be signed, steps 1 through 3 are repeated for the certificate used to sign the response (note that a different certificate chain may be built).

3b

.

For each Intermediate CAs (ICAs) in the certificate chain, Acrobat tries to obtain a revocation response (either OCSP or CRL).

3c

.

Because the responses for the revocation response for the ICAs are also signed, steps 1 through 3 are performed on the received response.

4.

The timestamp is validated.

If a timestamp from a trusted server has been embedded, steps 1 through 3 (including 3a, b, and c) are performed on the certificate for the timestamp. Validation depends on the certificate type and the configuration of the viewing application.

The above steps are discussed in detail in the following sections—except step 1 which is described in the document

D

igital Signatures in the PDF Language

.

Digital Identity Basics

Users obtain a credential to use in creating digital signatures from a

Certificate Authority

(CA). That credential, called a digital ID, contains a private key and a certificate, as shown in Figure 1. The certificate consists of a public key and identity information for the user or organization. When the certificate is used to sign a document, the certificate portion of their digital ID is embedded in the signature data stored in the document.

3

Dig

ital Sig

na

tur

es

in A

cr

oba

t

To prevent someone from tampering with the certificate, the certificate itself

is signed by the CA. The digital ID may be stored on a user’s system or on a hardware device such as a smart card or a token.

F

IGURE

1 Digital ID for Digital Signatures

Certificate Chaining

When a signature is applied, or a document with a digital signature

is opened, Acrobat first checks the document’s hash value. It then tries to verify that the embedded certificate can be linked to a trusted higher authority called the

trust anchor

. Trust anchors have been specified by the user or the organization, and stored in the user’s Certificate Store (see “Certificate Stores” on page 4).

For example, the user’s signature is based on their certificate (part of their digital ID), and that certificate may have been signed by an intermediate certificate authority (ICA). The ICA’s certificate has, in turn, been signed by a yet higher authority which might be the trust anchor. This linked sequence of CAs is referred to as a

certificate chain

; Acrobat tries to make sure that the chaining ends with a trusted certificate authority, and that the certificate for each link in the chain had not been revoked at the time of signing.

The certificate chain always begins with the end-entity certificate used to sign the document, whether it is the document signature, an OCSP or CRL response, or a time stamp value.

N

O T E

:

A

crobat can identify the type of certificate by inspecting the Key Usage entry in the certificate. If it is for an end-entity certificate, it will specify that it can be used to sign or encrypt a document. If it is a higher level certificate, it will specify that it can be used to sign other certificates.

When a certified document is signed, Acrobat considers the full chain of certificates,

which may form a tree-like structure. It tries to go from the end-entity certificate to the Intermediate CA, to a trust anchor certificate. It cannot always do that, so it tries alternate ways to complete the chain.

Trusted Certificates

When a document is signed and sent to one or more recipients, the sender must

have a valid digital ID and recipients must have the sender’s certificate. If there is a two-way workflow, it is best to make sure that everyone shares a common trusted identity list.

Signaturevalue

PDF Document

%PDF

/ByteRange { . . . }

• Certificate

• Signed hash value

• Time stamp

/Contents

(PDF content)

%%EOF

Digital ID

(stored on desktop or security device)

Private key

Certificate:

• Public key • Identity information

. .

.

signature dictionary

4

Dig

ital Sig

na

tur

es

in A

cr

oba

t

Acrobat allows the user to create a list of trusted identities, store their contact and

certificate information, and set different trust levels for each identity. Users can obtain and exchange certificates by one of three methods:

•

Extracting the data from a File Data Format (FDF) file, which can be exchanged by e-mail or a shared network folder

•

Extracting data embedded in a signed document

•

Searching a directory server that contains the required certificates

Certificate Stores

To digitally sign a document, the user must have a digital ID that identifies who they

are and which CA will verify their identity. The digital ID is stored in a

Certificate Store

, which can be on the user’s hard disk, on a hardware device, or in a Windows Certificate Store. Acrobat can use any of the supported certificate stores shown in Table 1, which lists the location of the certificate stores, their encryption formats, and their file extensions.

T

ABLE

1 Certificate Stores

L

ocation

Encryption Format

(and OS

-specific file

extensions)

C

omments

U

ser’s hard

disk

PKCS#12

.p12

(Macintosh file extension)

.pfx (Windows file extension)

PKCS#12 is a standard password protected and encrypted format. Files can be stored anywhere on user’s system; Acrobat remembers the location when the ID is registered. Files contain digital IDs (public and private keys)

.f

df

T

he Adobe File Data Exchange format used for importing and exporting settings and certificates (usually PKCS#12 files). (All supported platforms)

PK

CS#7

.p7b

(

Windows file extension)

.p7c

(


Certificate Message Syntax (CMS): Files with .p7b and .p7c extensions; registered by the WIndows OS. Acrobat products can import and export these files.

Har

dware

device

(e

.g. a Smart Key)

PK

CS#11

PK

CS#11 is an encryption format used on smart cards and other PKCS#11-compatible devices. There is no file associated with these IDs. communication with the device is handled by a P11 device driver

W

indows

Certificate

Store

.c

er

(


.apf

(


Windows only; IDs can be used by Windows’ programs and Acrobat. It may contain numerous certificates issued by different certification authorities.

5

Dig

ital Sig

na

tur

es

in A

cr

oba

t

Both Acrobat and Reader provide options for adding, for example, the Windows

Certificate Store to their directory search path in the Trusted Identity Manager. That allows those certificates to be imported, trusted, and used for building certificate chains. The administrator can completely customize how the store is used for signing and validation operations.

The Windows Certificate Store contains three sections: Personal, Trusted People, and Trusted Root. Certificates are

root

certificates simply by virtue of being at the top of the certificate chain hierarchy. They are X.509-compliant certificates that are digitally signed by a certificate authority that either Microsoft or the system administrator has determined is trustworthy.

Timestamps

When a digital signature is applied to a document, Acrobat stamps it with the

signer’s local machine time, and that is what appears in the signature appearance that recipients see. Because a user can set that time forward or back, that time is usually not trusted. Local times are labelled as such on the Date/Time and Summary tabs of the Signature Property dialog.

But a timestamp from a timestamp server may also be applied by the person signing. A timestamp is applied immediately after the signature is created, so the timestamp specifies that the document existed in its present form at the time the timestamp was applied.

Timestamps fulfill a critical need in the validation process: if Acrobat validates and timestamps the signature using a trusted timestamp server and the certification locks the critical parts of the document, then the signer cannot later claim that it was signed by someone else, that the document was altered after they signed it, or that it was signed at another time.

The process for timestamping a digital signature is as follows:

1. A hash is calculated on the signed contents in the signature dictionary (see PDF Reference Version 1.7 for information on PDF dictionaries used for signatures).

2. The unencrypted hash is sent to a timestamp server via HTTP, and it is encrypted (signed) with the timestamp server’s private key (from the TA’s digital ID).

3. The signed hash, along with the timestamp server’s certificate, is returned to Acrobat via HTTP where it is added to the PKCS#7 signature value as an unsigned attribute.

Like signatures, timestamps become trusted when they are associated with a timestamp authority’s (TA) trusted certificate. Therefore, while a TA certificate could be provided by the user or a company timestamp server administrator, most timestamps are provided by third-party TAs such as GeoTrust.

Acrobat users interact with timestamp servers differently based on their role:

6

Dig

ital Sig

na

tur

es

in A

cr

oba

t

•

Document signers: Authors and signers simply configure a default timestamp server based on information sent by their administrator or third-party provider. The administrator often preconfigures Acrobat.

•

Document recipients: In order to validate a signature associated with a timestamp, the user adds the root CA of the TA’s certificate chain to their list of trusted identities. When a timestamp server’s certificate is not trusted, the timestamp is labelled as such in the Signature Properties dialog and the signature validation is carried out at the current time.

Configuring Acrobat for Timestamping

In most cases, timestamp server administrators preconfigure end user machines or

provide the server information in an FDF file. The FDF file can either be posted on the Web, or e-mailed to a user, who then only has to double-click on the file to import the data that will configure the server. It is also possible to manually configure a timestamp server.

There are three methods for configuring Acrobat to use a timestamp server:

•

On a per-document basis

: a seed value (see “Using Seed Values in Form Fields” on page 8) is embedded in the document that tells Acrobat which timestamp server should be used.

•

On a per-certificate basis: settings apply to all validations done by that user (unless overridden by an OID). For organization-wide deployment, those settings can be controlled by the using Acrobat Customization Wizard to configure the installer.

• By embedding an Object Identifier (OID) in a specific certificate: It is possible to embed an OID (see “Object Identifiers (OIDs)” on page 10) in a certificate, and that OID will be used for all signatures signed with that certificate. When Acrobat encounters the OID, it will always use the timestamp server associated with that certificate.

Revocation Checking

An important component of a public key infrastructure is having a way to check if a user’s certificate has been revoked. There are a number reasons why a certificate might be revoked: its security might have been compromised, it could be invalid for some reason, or the owner of the ID might have left the company. Only the certificate issuer (a certificate authority) has the right to revoke a certificate.

Acrobat performs a revocation check at the time of signing, but the user can choose whether or not they want it included with the signature to save time when the document is opened by the recipient. Revocation checking starts at the bottom of a chain with the end- entity certificate, and once it reaches a trusted root, revocation checking stops. It is important to make sure that the revocation checks, done via HTTP, are allowed by an enterprise’s proxy configuration and firewall.

To check the revocation status, Acrobat uses either of two methods:

• Certificate Revocation List (CRL) is one common method that public key infrastructures use to maintain access to networked servers. With CRL, the certificate is checked against a list of revoked certificates. In addition to the certificate issue date and the issuing entities, the list specifies revoked

7Digital Signatures

in Acrobat

certificates as well as the reasons for revocation. Each list also contains a proposed date for the next release. One problem with CRL checking is the need for frequent updates to keep the list current. OCSP overcomes this limitation through real-time checking of certificate status.

• Online Certificate Status Protocol (OCSP) is the newer of the two schemes for maintaining server and network resource security. It defines a protocol for determining the current revocation status of a digital certificate without requiring a CRL (see Certification Revocation List). Unlike CRL, OCSP makes it unnecessary to frequently download updates to keep certification status lists current.

N O T E : Registry settings can be used to override preferences about whether OCSP or CRL is used.

So it can be seen that revocation checking for validating a signature is similar to credit card validation:

• CRL checking is like checking the card numbers against a list. • OCSP checking is like making a phone call to verify the card number.

Long-term Validation

One problem with validation is that it may need to be done some number of years after the signature was created. At that time the OCSP and CRL servers may not be functioning, or the certificate may have expired, causing it to be removed from CRLs. Acrobat embeds the revocation information in the document so validity can be determined, if necessary, at a later date.

Managing Certificates in an Enterprise Environment

When Acrobat is deployed within a company or organization, the IT administrator can standardize certain procedures and settings and limit the choices a user might make in order to achieve more accuracy and success.

Acrobat provides the following controls to help IT administrators manage digital signatures within an organization:

• System administrators can control what certificate stores are used for signing, signature validation, etc., and create custom preferences to control certificate processing.

• Seed values (associated with a signature field) can be used to control settings such as only allowing certain certificates to sign the document, as well as specifying how Acrobat should behave with respect to specific documents.

• The Adobe Customization Wizard utility can be used to customize the installer prior to deployment. It can preset preferences and standardize policies for all versions of Acrobat and Reader installed within the organization. Its use can streamline the installation process, customize security settings for digital signatures and Adobe LiveCycle Policy Server, and modify registry settings to optimize the operation of Acrobat and Reader.

• Using Object Identifiers (OIDs) in certificates to specify a policy that will control the behavior of Acrobat (see “Object Identifiers (OIDs)” on page 10).

8Digital Signatures

in Acrobat

These controls are explained in the following sections.

Setting Preferences

An organization can dictate specific policies and practices it requires of all employees with regard to digital signatures. The appropriate settings and preferences can be set in the application, on a per-certificate basis, or on a per-document basis:

• Application: Acrobat preferences can be set for all documents handled by a specified user; this can be done individually using the Acrobat UI, or the Customization Wizard can be used to set preferences in the installer.

• Certificate: Administrators can distribute certificates with specific policy OIDs, trust anchors, etc.

• Document: Administrators can control document templates with signature fields configured with seed values that control who can sign and how signing takes place.

Using Seed Values in Form Fields

An author of a PDF form may need to limit the choices a user can make when signing a particular signature field. In enterprise settings, documents with custom behaviors can be created using seed values for specific signature fields, and those documents can be used as templates and distributed across the company. Using seed values enables administrative control of signature properties such as signing reasons, the use of a custom signature handler, or specifying the preferred timestamp server.

Seed values constrain the properties of the signature that may be applied to the field to which they are applied. The values are set using JavaScript in Acrobat’s JavaScript console, and they can be set to be a preference or a requirement. Also, the seed values can be placed in documents and forms by a server process.Table 2 lists some examples of seed value properties which can be set using JavaScript.

N O T E : Table 2 contains only a partial list of seed value properties. For a complete list, see the Document Security User Guide for Adobe Acrobat and Adobe Reader Version 8.

TABLE 2 Examples of Seed Value Properties

Property Description

subject Specifies one or more specific individuals (as certificate owners) that can sign the document. It uses the exact format found in the certificate.

issuer Lists one or more issuers that are acceptable for signing. The issuer is often an ICA certificate but can also be the root. It is identified by a path to a discrete file in the format of ["/c/test/root.cer"].

N O T E : If specified, the signing certificate must be issued by a certificate that is an exact match with one of the certificates in this array.

9Digital Signatures

in Acrobat

Using seed value properties, authors or administrators can customize the behavior to achieve the following:

• Forcing a certification signature and document locking: Author can set a field so it automatically invokes the document certification workflow, so that only a certification signature can be used. Authors of certified documents can set permissions for what changes are allowed, so document integrity is assured.

• Adding custom legal attestations: Authors can add a legal attestation that explains why potentially dangerous content in the document, such as JavaScript or multimedia, is safe. That text will appear whenever recipients open the document.

• Restricting a signature field to a specific signer and certificate authority: Certificate seed values can be used to restrict signing to particular certificates, certificates issued by particular certificate authorities, or certificates with certain policy OIDs (see “Object Identifiers (OIDs)” on page 10). The values can be set as preferences or requirements. If a certificate cannot be found, a URL can be provided to allow the signer to get more information such as how to obtain an appropriate certificate.

• Specifying timestamp servers: The author can set a seed value so that a signature field is automatically associated with a specific timestamp server.

• Specifying alternate signature handlers and formats: Signing workflows may traverse multiple organizations and users using alternate signature technologies (signature handlers) provided by third-party software developers. Two seed values allow authors to specify which signature handler and format to use. By using a standard format, interoperability across multiple signature handlers is possible.

• Custom workflows and beyond: Organizations may have highly customized procedures and security workflows that go beyond those supported in Acrobat. Acrobat’s security APIs allow almost unlimited opportunities for creating documents and workflows that meet specific needs. Document developers can easily create custom signing menu items, automated tasks, and many other operations beyond those described above.

oid References one or more policy OIDs that must be present in the signing certificate. This property is only applicable if the issuer property is present. For example, a company might issue their own certificate with certain OIDs that are static across changing certificates.

url A URL that can be used to enroll for a new certificate if a matching certificate is not found.

flags A set of bit flags that control which of the following properties of this object are required:• subject• issuer• oid

Property Description

10Digital Signatures

in Acrobat

Object Identifiers (OIDs)

Certificates can reference a policy that controls how Acrobat will behave when a document with that certificate is encountered. When Acrobat finds such a certificate, it looks for a certificate policy and changes its behavior accordingly.

Acrobat examines the OID field of a certificate to understand the requirements imposed by the author or administrators, and presents that information to the user. The user or a server process can then decide to rely or not on the certificate for a given transaction. Also, certificates can specify that the signer’s certificate must contain a specific OID.

Certificate policies must be uniquely represented by a numeric string known as an “object identifier” (OID). An OID is simply a number a certificate issuer provides for a certificate field. OIDs must conform to ASN.1 format (http://www.iana.org/cgi-bin/enterprise.pl)

Acrobat recognizes two kinds of certificate policy OIDs:

• Acrobat-conformant OIDs: These OIDs conform to the format described in the PDF Reference. There are a limited number of predefined OIDs and each OID is associated with specific Acrobat behavior. These OIDs have a structure defined in X.208 from the International Telecommunications Union (ITU). These types of OIDs are attached to a certificate when it is created by a certificate authority using third-party software.

• Arbitrary OIDs: Any user-defined OID may be associated with a certificate. These types of OIDs are attached to a certificate when it is created by a certificate authority using third party software.

OIDs consist of a dot-separated series of numbers, where each dot-separated number has a specific meaning. Acrobat, and the X.509 standards recommendation, allows the OID field to contain several OIDs to specify that a given certificate fulfils the requirements of more than one certificate policy. This allows IT administrators to control many organization requirements in a consistent way, and also allows customization for specific certificates.

Enterprise Deployment and Installation

Adobe provides the free Adobe Customization Wizard 8.0 utility to help system administrators customize both Acrobat and Reader installers. It provides a graphical user interface to the product installers and makes it possible to make, save, and invoke modifications. It also allows IT managers to manage the security and digital signature preferences to provide consistent end user experience when using digital signature. This enables organizations to customize their workflows to be more efficient and less susceptible to error.

When the installer package has been modified using Customization Wizard, Acrobat and Reader can be deployed using many third-party deployment tools, or hosted on a centralized server and emulated on client systems. For more information on Customization Wizard 8, see:

http://www.adobe.com/devnet/acrobat/enterprise_deployment.html

http://www.iana.org/cgi-bin/enterprise.pl



in Acrobat

Post-deployment Windows Integration

Acrobat has its own certificate store, but it is often useful for Acrobat users to access certificates in the Windows Certificate Store.

Acrobat can be configured to allow users to search the Windows certificate store from the Trusted Identity Manager, set trust levels for any certificate found, and choose which certificates to use for encryption. Administrators can control whether clients can access MSCAPI through Acrobat so that users can find, use, and set trust levels for Windows certificates.

Interactions Between Signatures and Document Content

There are several types of document content, such as JavaScript or multimedia, that can potentially alter the contents of a PDF file and make the document untrustworthy. The main types of content are described below.

JavaScript

PDF documents can contain JavaScript, which can potentially change the document’s appearance or allow attackers access to your system. It is recommended that participants in certified workflows do not allow JavaScript to run. Consider the source of the document and the security of the workflow before enabling this option.

This option controls whether high privilege JavaScript can be executed from custom menu items in the Acrobat toolbar. Document recipients can set whether or not to execute JavaScript on a per-certificate basis. However, certificate settings do not override application-level settings, so even if JavaScript is enabled for a particular certificate, it may not execute unless the application’s preferences allow it.

Multimedia

Trust Manager preferences provide multimedia display permissions for both trusted documents and untrusted documents. Permissions are independently set for each document type.

Recipients of certified documents can control on a per-certificate basis whether a document uses the trusted or untrusted settings. By definition, a certified document is trusted for dynamic content if the certificate associated with the certifying signature is trusted for running dynamic content.

Because dynamic content represents a security risk and could potentially change the document’s appearance or allow security holes in multimedia players to adversely impact your system, it is recommended that participants in certified workflows do not allow multimedia. Consider the source of the document and the security of the workflow before enabling this option.

Attachments and External Content

Attachments can adversely affect document integrity or even the document’s operating environment, and they can cause other files to be opened and other


in Acrobat

applications to be launched. The Acrobat and Reader Trust Manager allows users to maintain lists of what types of files can be opened or not.

Silently transmitting data represents a security risk since malicious content can be transferred whenever the application communicates with an external source. Acrobat and Reader can be configured to allow or deny access to external content

Internet URL Access

Opening a Web page represents a security risk because malicious content can be transferred whenever the application communicates with the Internet. In addition to visible links in a PDF document, form fields can contain hidden JavaScript calls that open a page in a browser or silently requests data from the Internet. The Acrobat family of products maintain a list, called the Trust List, of trusted URLs and those for which access will be blocked. Users can specify whether or not URL access is allowed on a global or per-URL basis.

Application Differences

Although Acrobat supports all security features described in this document, Reader only allows users to validate digital signatures. They cannot save a signed file, fill in forms, or add comments. However, if the user receives a rights-enabled PDF, they will have expanded privileges—for more information, see “Adobe Reader Enabling” below) and see “Resources” on page 13 for the following documents which describe the differences between the applications in more detail:

• A Primer on Electronic Document Security• Adobe PDF Security—Understanding and Using Security Features with Adobe

Reader and Adobe Acrobat

Adobe Reader Enabling

Although Adobe Reader can be downloaded for free to read and print PDF documents, users generally cannot modify a document or fill in forms and save the data. However, Acrobat 8 Professional or Adobe LiveCycle Reader Extensions can be used to embed extended usage rights in a PDF document.

When a rights-enable PDF document is opened, it activates hidden functionality in Adobe Reader and the user will then be able to save the file to a local hard drive, fill it out, add comments and mark up content, share it with others, and submit a completed document electronically. When the user is finished working with the document, those functions are once again disabled until the user receives another rights-enabled PDF file. As a result, this enables organizations to easily include Adobe Reader users in simple and complex business processes that provide greater assurance of document authenticity and confidentiality for users outside the network.

LiveCycle Dynamic Forms with Digital Signatures

Digital signatures can be added to Adobe LiveCycle® forms, which can be published using either the PDF or XDP format. There are two basic types of LiveCycle forms,


in Acrobat

static or dynamic. Dynamic forms can contain logic to add form fields and additional pages as needed, according to rules set by the author. For example, if a user entered more text than what would fit in a field, the field would expand and, if needed, even flow onto an extra page which would be created for it.

The potential problem is that the extension of form fields or the variable number of pages could affect the legal impact of such a document. Table 3 shows the product versions and which ones support dynamic forms.

In Acrobat 6, digital signatures were supported for static forms, but not for dynamic forms. In Acrobat 7 and higher, both approval and certification signatures are fully supported for dynamic forms.

TABLE 3 Signature Type Support in LiveCycle XML Documents

Resources

The following documents are available from the Adobe Acrobat web pages:

Reference

PDF Reference, sixth edition, Adobe Portable Document Format, Version 1.7

http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference.pdf

White Papers and Technical Overview Documents

Digital Signatures in the PDF Language

http://partners.adobe.com/public/developer/acrobat/index_securitysupport.html

Adobe PDF Security — Understanding and Using Security Features with Adobe Reader and Adobe Acrobat

http://www.adobe.com/products/pdfs/AdobePDFSecurityGuide-c.pdf

Secure Electronic Documents Drive Efficient Online Business Processes

Signature

Type

Static LiveCycle XML

Documents

Dynamic LiveCycle XML

Documents

6.x 7.x 8.x 6.x 7.x 8.x

Approval Yes Yes Yes No Yes Yes

Certification Yes Yes Yes No Yes Yes

Reader

Extensions

Yes Yes Yes No Yes Yes

http://www.adobe.com/products/pdfs/AdobePDFSecurityGuide-c.pdf

http://partners.adobe.com/public/developer/acrobat/index_securitysupport.html

http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference.pdf


in Acrobat

http://www.adobe.com/products/server/pdfs/95003796_security_solbr_ue2.pdf

A Primer on Electronic Document Security: How Document Control and Digital Signatures Protect Electronic Documents

http://www.adobe.com/security/pdfs/acrobat_security_wp.pdf

Acrobat User and Administrator Guides for Security

Security Administration Guide for Adobe Acrobat and Adobe Reader Version 8

http://www.adobe.com/devnet/acrobat/security.html

Digital Signature User Guide for Adobe Acrobat and Adobe Reader Version 8


Document Security User Guide for Adobe Acrobat and Adobe Reader Version 8


Copyright 2006–2007 Adobe Systems, Incorporated. All rights reserved.

Adobe Systems Incorporated

345 Park Avenue, San Jose, CA 95110-2704 USA

http://www.adobe.com

Adobe, the Adobe logo, Acrobat, Adobe LiveCycle, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. Mac OS is a trademark of Apple Computer, Inc., registered in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Microsoft, Windows, and Word are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners.

May 11, 2007



http://www.adobe.com/security/pdfs/acrobat_security_wp.pdf

http://www.adobe.com




The implementation of digital signatures and the validation process is based on industry standards and algorithms as listed below.

TABLE 1 Standards for Digital Signatures

Feature Standard Title

Certificates RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

http://www.faqs.org/rfcs/rfc3279.html

CRL RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile


OCSP RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP


PKCS #7 RFC 2315 PKCS #7: Cryptographic Message Syntax Version 1.5


PKCS #11 PKCS #11 Cryptographic Token Interface Standard

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf

PKCS #12 PKCS #12 Personal Information Exchange Syntax Standard

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf

Timestamps RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).


Timestamping: signing and signature validation.

Hash Algorithms RFC 3174 US Secure Hash Algorithm 1 (SHA1)


Creating a document hash during signing.

Object Identifiers (OIDs)

ASN.1 From the International Telecommunications Union (ITU) — for OIDs


Digital signatures FIPS PUB 186-2 Digital Signature Standard

http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

Describes DSA signatures.

Appendix:

Standards Used by Acrobat

Technical Note







ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf


http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf




in Acrobat

TABLE 2 Encryption Algorithms

Protection of sensitive data

FIPS 140-2 Security Requirements for Cryptographic Modules

http://csrc.nist.gov/cryptval/140-2.htm

Attribute certificates

ISIS-MTT Specification v.1.1 March 2004

ISIS-MTT Specification v.1.1

http://www.isis-mtt.org/index.php?id=460&L=1

Chain building NIST PKITS Public Key Interoperability Public Key Interoperability Test Suite Certification Path Validation, Draft Version 0.7 June 30, 2003

http://csrc.nist.gov/pki/testing/x509paths.html

Chain building and path validation, including cross certificates and multiple chains.

Hash algorithms RFC 1321 The MD5 Message-Digest Algorithm


Creating a document hash during signing.

All RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax.


Digital signatures RFC 2437 PKCS #1: RSA Cryptography Specifications Version 2.0.


A format used for creating a digital signature object which is embedded in a document.

Attribute certificates

RFC 3281 An Internet Attribute Certificate Profile for Authorization


Algorithm Description

RC4 A proprietary encryption algorithm, RC4 is a symmetric stream cipher: the same algorithm is used for both encryption and decryption, and the algorithm does not change the length of the data.

AES The AES algorithm was introduced in Acrobat 7.0. It is a new crypt filter that is not recognized by older viewers. AES is a symmetric block cipher: the same algorithm is used for both encryption and decryption, and the length of the data when encrypted is rounded up to a multiple of the block size, which is fixed in this implementation to always be 16 bytes, as specified in FIPS 197, Advanced Encryption Standard (AES).

Feature Standard Title

http://www.isis-mtt.org/index.php?id=460&L=1




http://csrc.nist.gov/pki/testing/x509paths.html




in Acrobat

Digest Methods

The following are the algorithms used by Acrobat for calculating hash values.

TABLE 3 Digest Method Standards

Standard Title

MD5 The MD5 Message-Digest Algorithm


RIPEMD-160 RACE Integrity Primitives Evaluation Message Digest

http://homes.esat.kuleuven.be/~cosicart/pdf/AB-9601/AB-9601.pdf

SHA-1SHA-256SHA-384SHA-512

Secured Hash Algorithms

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

http://homes.esat.kuleuven.be/~cosicart/pdf/AB-9601/AB-9601.pdf
