© 2017 Adobe Systems, Inc. All rights reserved.

Updated Nov 16, 2017.

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.


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”.


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

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)

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)


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


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 “ 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 “ 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.”


  • 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.


  • 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.


  • 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.


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


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

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:

Seed values: Changes across releases
Seed value First support for seed value 6 7 8 9+

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
filter The language-independent name of the security handler to be used when signing. X X X X

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.
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

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.
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