A: Changes Across Releases

The list describes major changes only. A more detailed change list for each dot release appears in the Release Notes.

Everything after 11.0.10

For a list of changes, refer to the release notes and the Preference Reference.

11.0.10

Certificate Viewer strings have changed. On the Details and Summary tabs, the strings for Key Usage appear as “Digital Signature” and “Non-Repudiation” instead of “Sign document” and “Sign transaction”.

11.0.09

Certificate filtering changes only.

The recent expansion of digital certificate usage has prompted Adobe to change the processing of Key Usage (KU) and Extended Key Usage (EKU) certificate extensions when performing digital signature creation in Acrobat products. This change means the following:

• Acrobat products better conform to RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile).
• Existing credentials (certificates) that do not adhere to the requirements in the following table may no longer be used for signing with Acrobat or Reader. Invalid certificates no longer appear in the certificate drop down list in the Sign Document dialog.

Certificate KU and EKU extension requirements

Valid KU Extensions	Valid EKU Extensions
Absent	Absent
Absent	One or more of the following: emailProtection codeSigning anyExtendedKeyUsage 1.2.840.113583.1.1.5 (Adobe Authentic Documents Trust)
One or more of the following: nonRepudiation signTransaction (11.0.09 only) digitalSignature (11.0.10 and later)	Absent
One or more of the following: nonRepudiation signTransaction (11.0.09 only) digitalSignature (11.0.10 and later)	One or more of the following: emailProtection codeSigning anyExtendedKeyUsage 1.2.840.113583.1.1.5 (Adobe Authentic Documents Trust)

Note

Adobe allows codeSigning, since some customers utilize this EKU extension for the presence and handling of JavaScript within PDF documents.

Background

RFC 5280, which started as RFC 2459 in 1999, did not include “Document Protection” as a potential EKU. Therefore, Adobe has always had to make certain assumptions regarding a Certificate Authority’s intention for the usage of an issued certificate.

Recently, certificate usage has become more popular in enterprise settings where certificate-based authentication is used to access corporate networks in a variety of ways. Some of these certificates have relatively open KU and EKU configurations, and these have automatically been displayed back to the user within Adobe Reader and Acrobat as potential credentials for digitally signing PDF documents. After a re-evaluation of RFC 5280 and the actual industry practices for digital certificates, Adobe Acrobat and Reader 11.0.09 increase their conformance to RFC 5280 by no longer displaying all available certificates. In some cases, the changes will mean that certificates available for signing in earlier versions will not be displayed.

According to RFC 5280, there are several ways to make sure your credential can be used for digital signing. First, from “4.2.1.3 Key Usage” in RFC 5280:

“The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. For example, when an RSA key should be used only to verify signatures on objects other than public key certificates and CRLs, the digitalSignature and/or nonRepudiation bits would be asserted. Likewise, when an RSA key should be used only for key management, the keyEncipherment bit would be asserted.”

And secondly, from “4.2.1.12 Extended Key Usage” in RFC 5280:

“This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates.”

Further, when both KU and EKU are present, the RFC states:

“If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.”

11.0

• A complete user interface overhaul which improves usability.

• The menu items for digital signatures and Adobe Sign’s electronic signatures are consolidated under the Sign Pane.

• Support for elevating certified documents to a privileged location. This feature allows admins to secure the product by turning off features, enabling sandboxing, etc., while making certified documents in trusted workflows exempt from those restrictions.

• Updated algorithm support as described in the Quick Keys. FIPS PUB 186-3 is also supported.

• The Signature Pane displays an icon and text when a signature has been deleted.

• Long term validation:

  • The new iAutoAddLTV preference allows admins to configure automatic LTV for all signatures in a PDF.
  • An LTV size threshold has been implemented so that when it exceeds 10% of the document size + 10kb, a dialog asks the user to confirm the action.
  • There is a new option in the user interface that allows users to Automatically add verification information when saving signed PDF.

• There is a new value for the signature validation preference cSigniReqRevCheck: 3: Require a check; it must succeed under all circumstances.

• Admins can lock the ability to clear signatures via bEnableSignatureClear.

10.1.2

• Adobe’s sign service continues to be further integrated into Acrobat and Reader.
• The presence and behavior of the Sign Pane can be configured by admins via registry-level preferences.
• The performance and stability of signing operations is also improved.

10.1

• Acrobat/Reader 9.4.5 and Acrobat/Reader 10.1 will accept Identrust certificates with a SHA256 hash. Prior to these releases, certificates with OIDs under the Identrust arc enforced the use of SHA1.

• The Signature Properties dialog provides a clearer presentation of signing time and validation times:

  • The Date fields on Date/Time and Summary tabs have been renamed to Signing Time. The field values always contains both the date and the signing time from the signer’s computer.
  • The Date/Time and Summary tabs contain more validation time details. In addition to the signing time from the signer’s computer, the validation time also appears in some workflows. For example, when a timestamp is present (including post-signing timestamps), the Date/Time tab displays timestamp details such as if it is embedded, the timestamp authority name, and other information. Some of this additional information also appear in the Certificate Viewer.

• Prior to 10.1, OCSP responses without nextUpdate were never embedded in a signature. For 10.1 and later, OCSP responses are always embedded irrespective of the presence of nextUpdate; however, whether they are used for signature validation depends on certain conditions:

  • Validation time is greater than thisUpdate minus the value of maxClockSkew (the default is 5 minutes). This test is always performed.
  • When nextUpdate is present and the validation time is less than the nextUpdate time plus the value of maxClockSkew.
  • When nextUpdate is not present and the validation time is less than the thisUpdate time or the producedAt time (whichever is greater) plus the value of maxClockSkew. If you need a relaxed security environment (for example, when the responder is caching OCSP responses), bIgnoreNextUpdate can be set to 1 to ignore the last test. In this case, embedded responses without nextUpdate are always used for signature validation provided that they pass first test. This behavior is designed to support Acrobat’s long term validation feature and allows validating a signature with embedded responses that were valid at signing time.

• Portfolio Signature Status indicators: 10.1 implements a portfolio status indicator called a Signature Badge. A signature badge button appears in a signed PDF portfolio window’s taskbar except when the portfolio’s cover sheet is visible. Like the signature in the Signature panel, a status icon shows the signature status. Although the portfolio user interface can give the impression that the cover sheet is some kind of special attachment to a portfolio document, the cover sheet is the same as the top-level portfolio document. The signature status of the portfolio’s cover sheet is the same as signature status of the entire portfolio. The badge has the following behaviors:

  • The portfolio document’s HideToolbar viewer preference is always honored even if it means that the badge will not be initially visible when the document is opened. The user can hide or show the taskbar using View > Show/Hide > Toolbar Items > Show/Hide Toolbars menu.
  • Clicking the badge button displays the cover sheet as well as the Signatures panel.
  • The badge displays a status icon which is similar to other status icons. For those states that display the common name, it is gotten from the “cn” key in the Subject section of the signing certificate.

10.0.1

• Acrobat stability is improved when opening a signed PDF file.
• Saving a signed file Safari is supported.

10.0

The following enhancements have been introduced with 10.0:

• Content security menus: Many of the menu items have been migrated to a new Tools menu bar which can be hidden or displayed as desired. Top level menu items have changed as follows:

  • Acrobat menu changes: To get the content security menu items, choose Tools.

    • The Security Settings Console, Import/Export Security Settings, and document security settings are under Tools > Protection > More Protection.
    • Signature related settings (expect for Digital ID settings which are in the Security Settings Console) are under Sign and Certify.
    • The Trusted Identity Manager is under Tools > Sign and Certify > More Sign and Certify.
    • The default signature format can be selected from the Preferences > Security > Advanced Preferences > Creation tab.
    • The Show timestamp warnings in Document Message Bar has been removed from the Preferences > Security > Advanced Preferences > Verification tab.

  • Reader menu changes: Content security menu items now reside under Edit > Protection.

• More nonce options: bSendNonce is deprecated and replaced by iSendNonce. The additional configuration option has been added which allows nonces but still permits valid signatures if they do not exist.

• Long term validation and timestamping:

  • Timestamps: The default size set aside for timestamps increased from 4096 to 6144. This value is controlled by the iSize key in the registry.
  • Invisible timestamping: Previous versions of Acrobat only allowed timestamps as part of a signature workflows. It is now possible to timestamp a document without going through the standard signing workflow (The document is still signed). There is a separate menu item called Time Stamp Document.
  • New default signing format choice: ETSI.CAdES.detached is now a supported value for aSignFormat, and it can be added via enterprise preference configuration (e.g. registry) or via the signature creation preferences in the user interface.
  • Standards support: Support for the PAdES and CAdES standards as well as the ETSI/ESI Technical Standard (TS) 102 778 standard.

• Non-explicit OID support: Acrobat products now support non-explicit OIDs with 10.0. Support for the non-explicit model allows Acrobat products to conform to the processing model used by many European Qualified CAs, SAFE, and others in which only the signing certificate (end entity) is checked against the initial-policy-set. The user interface

• PKCS#11 tokens and smartcards: Acrobat continues to provide robust device support. However, this feature interacts with the new Protected Mode in Adobe Reader in a way which may require a couple of extra installation steps. If you encounter a problem installing a PKCS#11 driver, disable Protected Mode, install the driver, and then re-enable Protected Mode.

• Adobe Database Connectivity (ADBC) support is removed: The ability to connect to Windows ODBC (Open Database Connectivity) data sources is deprecated for security reasons.

• SDK and API extensions: For information about new APIs and resources, download the SDK and its documentation.

Changes by feature

Digital ID Related Files

Note

There are no changes to this feature for 10.x and later.

A digital ID may reside in a local or networked file or on some external hardware. There are several digital ID-related file types and storage mechanisms a user might encounter in signing and certificate encryption processes. Digital IDs (both the certificate with the private key) and certificates (with a public key but no private key) are provided to Acrobat via digital ID service providers (one type of “cryptographic service provider” or CSPs).

In many cases, the digital ID is stored on a local or networked file. Common file locations include the Windows Certificate Store (where they can be used both by Acrobat and other Windows applications) and the default Acrobat cache (used only by the Acrobat family of products). Others IDs may reside on external PKCS#11 hardware that is plugged into the computer or on a roaming ID server. Regardless of location the application remembers the location when the ID is registered (imported) and is added to the Security Settings Console’s digital ID list.

The Acrobat family of products supports the following digital ID providers:

• PKCS#12 files: A common file format that contains the entire digital ID. It is used by Acrobat on Windows as well as Macintosh.
• Windows Certificate Store: A local store that can import and export various file formats and that can be used by both Windows MSCAPI-compliant programs including Acrobat products.
• PKCS#11 devices: External devices that store digital ID data. Users do not interact with a file.
• Roaming ID servers: The private key is known only to a remote server. The server sends the certificate and its public key to users after they authenticate. Users can import and export the certificate from Acrobat.
• APF files: A legacy format that is no longer used.

Digital ID-related file types

Type	Description	5.x	6.x	7.x	8.x	9.x
.acrobatsecurity	An XML format encapsulated in a PDF which stores security settings for import and export, includingdigital ID public and private keys.					Export, Import
PKCS#12: .pfx (Win), .p12 (Mac)	Personal Information Exchange Syntax Standard: Specifies a portable and password protected format for storing or transporting digital ID public and private keys.		Export, Import	Export, Import	Export, Import	Export, Import
.fdf	An Adobe file data exchange format used for importing and exporting settings and certificates (usually PKCS#12 files).	Export, Import	Export, Import	Export, Import	Export, Import	Export, Import
PKCS#7: .p7b, .p7c	Certificate Message Syntax (CMS): Files with .p7b and .p7c extensions are registered by the Windows OS which contains the digital ID certificate and public key only.		Export, Import	Export, Import	Export, Import	Export, Import
.cer	Certificate format: A Microsoft format for digital IDs usually stored in the Windows Certificate Store which contains the digital ID certificate and public key only.		Export, Import	Export, Import	Export, Import	Export, Import
.apf	Adobe Profile Files (Legacy): Not used after Acrobat 5. A file containing a digital IDs public and private keys that can be upgraded by double clicking them.	Export, Import	Import	Import	Import	n/a

APF files

The ability to create an APF file (Acrobat Personal File) only existed in Acrobat 4 and 5. The file was a container for an Acrobat generated, self-signed digital ID plus an address book that held other peoples public keys for the purpose of applying Certificate Security (for signature validation).

Beginning with Acrobat 6, the ability to create an APF file was dropped because P12/PFX usage was introduced along with a separate address book for managing other peoples certificates. Acrobat 6 would import the certificates from an APF file and allow export of a digital ID to a P12 file. Acrobat 7 would still open the APF file and allow access to its contents, it no longer offered the ability to export your private key. Therefore, if you want to convert your APF file to a P12 file you can only use Acrobat 6.

Acrobat 9 does not support APF in any way, so if you need to use or access an APF file after Acrobat 9 is installed, you will have to uninstall 9.0, reinstall 6.0, import and then export the digital ID from the APF to a P12 file, and then reinstall 9.0.

Signature Algorithms

See the Quick Key for changes across versions.

Applying a digital signature involves the use of two algorithms: one for creating the message digest (a document hash) and one for encrypting the digest:

• Message digest: The default algorithm used to digest signed data becomes stronger across releases. Specifying an alternate algorithm is possible through registry configuration.

• Encryption algorithm: That algorithm is selected based on the signing digital ID’s private key which specifies an algorithm and key length when the public-private key pair is generated.

• Libraries: The statically linked libraries (not dlls) in use are:

  • Acrobat 9: CryptoC 6.1.1 (Mac), CryptoC 6.3.2, CryptoC-ME 2.1 (Windows)
  • Acrobat 10: CryptoC 6.1.1 (Mac), CryptoC 6.4.0, CryptoC-ME 3.0 (Windows)
  • Acrobat 11: CryptoC 6.4.0 (Mac), CryptoC 6.4.0, CryptoC-ME 4.0.1 (Windows)

Seed Values

Signature field seed values enable document authors to limit a signer’s choices when signing a particular signature field, thereby creating documents with behaviors and features that meet specific business requirements.

For more information, refer to the following:

• • Digital Signature Workflow Guide
• Developing Acrobat Applications with JavaScript
• JavaScript for Acrobat API Reference

Seed values: Changes across releases

Seed value	First support for seed value	6	7	8	9+
certspec	Specifies that certain certificates must be used for a particular signature field. 6.0-7.x: Supports subject, issuer, and oid. 8.x: Adds support for subjectDN, issuerDN, keyUsage, url, and urlType	X	X	X	X
filter	The language-independent name of the security handler to be used when signing.	X	X	X	X
flags	A set of bit flags controlling which properties are required. 6.0-7.x: 1: filter, 2: subFilter, 4: version, and 8: reasons. 8.0: 16: legalAttestations, 32: shouldAddRevInfo, and 64: digestMethod.	X	X	X	X
legalAttestations	A list of legal attestations that the user can use when creating an MDP (certification) signature.	X	X	X	X
mdp	Can be used to force a certification signature as well as to control permitted document changes.	X	X	X	X
reasons	A list of reasons that the user is allowed to use when signing. 8.0: Supports disabling signing reasons.	X	X	X	X
subFilter	An array of acceptable signature formats.	X	X	X	X
timeStampspec	Specifies a timestamp server using the url and flags properties.	X	X	X	X
version	The signature handler version to be used to sign the signature field. Valid values are 1 and 2. 8.0: Must be set to 2 if this seed value object contains Acrobat 8-specific content marked as required.	X	X	X	X
digestMethod	The algorithm used to created the message digest. See the Quick Key for valid values across versions.		X	X	X
shouldAddRevInfo	Controls how the application does certificate and chain revocation checking.			X	X
lockDocument	Allows the author to add a Lock Document checkbox to the signing dialog so a signer can lock the document at the time of signing.				X
AppearanceFilter	A text string naming the appearance required to be used when signing the signature field.				X

Signature Appearances

The format has always been PDF, but appearance file names and behavior have evolved across releases.

Changes in signature appearances

Version	Filename	Behavior
10.0 and later	No change	No change.
9.0	No change	Signature status icon no longer appears with the appearance.
8.0	No change	No change.
7.x	No change	No change.
6.0	appearances.acrodata	One signature appearance file per OS login. Each page in the PDF corresponds to a signature appearance. Each page also contains private data that is hung off of the Page object. This data contains the settings for checkboxes and other options in the Configure Signature Appearance dialog.
5.05	(apf basename).pdf	One appearance file per apf file. 5.0 appearance files are forward compatible with 6.0.

XML Form Support

Support for security features in dynamic XML forms authored with Designer has improved across versions. With version 8.0, there is full support for the following:

• Approval signatures: Sometimes referred to as signing.
• Certification signatures: Sometimes referred to as certifying.
• MDP+: modification-detection-protection (field locking).
• Reader extensions: Enabling usage rights so Reader users can sign documents with existing fields.

Signature support in static XML forms

Signature Type	6.x	7.x	8.x	9.x	10.x and later
Approval	Yes	Yes	Yes	Yes	Yes
Certification (DocMDP)	Yes	Yes	Yes	Yes	Yes
Field protection (FieldMDP)			Yes	Yes	Yes
Reader extensions (UR3)	Yes	Yes	Yes	Yes	Yes
XML data signature		Yes	Yes	Yes	Yes

Signature support in dynamic XML forms

Signature Type	6.x	7.x	8.x	9.x	10.x and later
Approval		Yes	Yes	Yes	Yes
Certification (DocMDP)		Yes	Yes	Yes	Yes
Field protection (FieldMDP)			Yes	Yes	Yes
Reader extensions (UR3)	Yes	Yes	Yes	Yes	Yes
XML data signature	Yes	Yes	Yes	Yes	Yes

Directory Servers

Acrobat products ship with preconfigured directory servers. The servers are used by the Trusted Identity Manager to locate certificates for import. Users can trust the imported certificates for signing and certifying documents as well as for encrypting documents prior to sending them to the certificate owner.

LDAP certificate repositories

Version	Default Directory Servers
7.x	VeriSign Internet Directory Service, GeoTrust Directory Service, IDtree Directory Service
8.0 and later	VeriSign Internet Directory Service

FDF (Data Exchange) Files

With 9.0, FDF import/export is deprecated and replaced by the security setting import/export feature.

The FDF format and .fdf files enable the import and export of certificate data and security settings. End users can share application settings, and administrators can distribute trust anchors and server settings across their organization. Acrobat products can create the files as part of the export process, or files can be programmatically generated by a custom program or script that writes a file conforming to the SDK.

FDF changes across releases

First support for FDF feature	5	6	7	8	9+
Import and export of Acrobat-generated self sign certificates.	X	X	X	X	X
FDF file signing for origin verification.		X	X	X	X
Import and export of any supported certificate type (including those in the Windows store).		X	X	X	X
Import and export of directory server settings.		X	X	X	X
Import and export of Adobe LiveCycle Rights Management Server settings.			X	X	X
Import and export of timestamp server settings.			X	X	X
Import and export of roaming ID server settings.				X	X