Your Rating: Results: PatheticBadOKGoodOutstanding! 11 rates

On this page you'll find a living FAQ that will evolve as Adobe responds to more questions from our customers regarding the digital signature aspects and configuration of these capabilities in our products.

Note that references to Acrobat typically mean both Acrobat AND Reader. Responses are also typically meant for the latest version (9.x), unless otherwise noted.

The document often referred to here as the 'Guide' can be found here: http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf?version=1 

 How do Adobe's products and signature capabilities match up with the European Union's Signature Directive?

  • Signatures made with Acrobat or LiveCycle (with the appropriate settings) conform with the new PDF Advanced Electronic Signatures Standard (PAdES) See PAdES. Combined with a digital certificate (signing credential) that is stored on a secure hardware device and has good identity vetting behind it, Adobe feels confident saying that these signatures are easily 'advanced electronic signatures' per the Directive. Our CDS Providers and AATL Members are good sources for these certificates.
  • Adobe products are also capable of producing Qualified Electronic Signatures, per the Directive, when combined with a Qualified Certificate from a Qualified CSP (some of our AATL Members offer Qualified certificates) and producing PAdES-compliant signatures. Note however that there are country-specific regulations that may require the use of additional software or hardware, depending on the use case.
  • CDS certificates are not by their very nature Qualified, but easily meet many of the needs of a high assurance, 'Advanced' signature.

For some reason, the form I designed and signed is coming up as 'modified' or it shows a different result when opened in Acrobat Reader 8 versus Acrobat Reader 9.  What's going on?

  • The form should be checked for scripts that are modifying the form at doc open time.  Things like this should not be done for signed forms.  This is a common cause of modified document signature problems.
  • The form should be coded to have an explicit locale.  This is a best practice for signed documents.  In particular, in the case of this document, it appears the document was signed in one locale and then opened in another, resulting in the display of several fields being reformatted causing field modified warnings in some cases.
  • Acrobat 8 and Acrobat 9 report changes differently by design.  Acrobat 8 tended to report any actions on a document as a modification even if there was no actual document change.  Acrobat 9 is more effective at reporting only actual document changes.
  • Still, documents whose appearance is not stable due to scripts or conflicting declarations will potentially report modifications that result from script execution and other actions.  Form authors need to exercise care when creating forms, particularly XML Dynamic forms, to avoid these types of problems in the presence of signatures.
  • For more information, check out the Security Guide, Section 11.5.2, page 263.

What happens when Acrobat signs a document (from a high level overview)? See also the Signature Creation Quick Key.

  • The user initiates the signing process from a menu, toolbar button, or clicking on the signature field
  • Acrobat pops the Sign dialog where the user can select a digital ID and add a reason and location.
  • The user clicks the Sign button and the first thing Acrobat does is check to see if it can gain either direct or indirect access to the private key (i.e. have they supplied the correct password)
  • Acrobat prompts the user for a Save As location
  • Using this Save As location Acrobat writes the file to disk.
    • This newly created file contains the signature appearance, which includes the computer generated signing time, data extracted from the digital ID's public key certificate, and any custom appearance info
    • The new file contains a hole where the signature will go filled with a block of zeros
  • Acrobat computes the byte range in two chunks. First, from the first byte of the file (newly written to disk) up to (but not including) the first byte of the signature hole. Then, from the first byte after the end of the signature hole to the end of the file
  • Using the cryptographic tools in the built in RSA library, Acrobat computes the hash over the two byte range chunks.
  • The hash is sent to the private key where it is encrypted
  • The signing chain and revocation information are gathered up and written into the signature hole along with the encrypted hash. The data is a hex encoded ASN.1 structured block of data that has over-written most of the zeros that were acting as a place holder. Any space that had been set aside, but has not been used remains filled with zeros in order to keep the byte range correct.
  • At this point you have a complete document signature. The next steps happen only if you are creating a timestamp.
  • The document signature is hashed
  • The new hash is sent to the time stamp server as a timestamp request packet
  • The server signs (encrypts) the hash and sends the signed timestamp token back as a timestamp response
  • Acrobat writes the timestamp response into the unsigned attributes section of the signer info section of the PKCS#7 signature object
  • For more information, refer to the Security Guide.

Are digital signatures in Adobe products compatible with PDF/A?

PDF/A-1 FULLY supports Digital Signatures. Reader, Acrobat and LC all fully support signing a PDF/A according the requirements for same.

Is there an easy way to roll out configurations for Acrobat or Reader after installation, specifically in regards to security settings, like trusted certificates, preferences, etc?

Refer to the Security Guide., Section 3.1.

There are several checkboxes in the Security->Advanced preferences relating to Windows Integration.  How do these affect Acrobat and Reader's interaction with the Microsoft Certificate Store and CAPI?

During chain-building of the signature process, Acrobat and Reader search all over for the needed certificates; the Acrobat Address Book (AAB), the Windows Cert Store, the CertCache folder, P12/PFX files, smart cards and tokens, and maybe even the internet if bFollowURIsFromAIA (a registry option) is turned on. Other than the last item, Acrobat doesn't care one iota what reg key or preference setting is selected. It builds the chain, top to bottom, as best it can.

Now comes time to establish trust. Here's is where the "use Windows trust anchor" option comes into play. Either it's off (the default setting) and the only place Acrobat can use to establish trust is the AAB, or it's on and Acrobat will use both the AAB and Windows. They are not mutually exclusive.

Is there a way to force Acrobat/Reader to use CAPI for OCSP checking? If so - what's the regkey? Also, what are the implications?

The order in which revocation checkers are invoked is fixed. It is always OCSP->CRL->CAPI discriminated against the content of cRevocationChecker array in the registry. If cRevocationChecker is not defined all three are used in the listed order. If cRevocationChecker is defined then only those that are defined in cRevocationChecker are used but in the same order sans those that are not in cRevocationChecker array. For instance if cRevocationChecker array contains MSCAPI_RevocationChecker and Adobe_OCSPRevChecker (in this order) then only these two will be used but Adobe_OCSPRevChecker first and MSCAPI_RevocationChecker second, not in the order they are listed in cRevocationChecker array.

LTV has embedded OCSP/CRL. Those are always checked with Acrobat's code, not CAPI.   However, if only MSCAPI revocation checking is enabled then embedded LTV info will NOT be used, eliminating the benefit of this long-term validation information.

Does Acrobat use AIA path discovery to load ICAs if they aren't present?  In other words, I have a Root certificate installed, and an End Entity cert - but no ICA.  Will Acrobat look in the AIA to find the server that has the ICA available? 

We disable this by default. due to the time it can sometimes take to look down all the paths for all of the certificates, especially when there is cross-certification in play. However, if you are interested in turning this option on, and are comfortable with the delays involved, please read Section 5.4.1.3 of the Guide which goes into detail about how to enable this option in the Registry.

When embedding CRLs/OCSP responses for Long Term Validation, what is the threshold cutoff? In other words, when a CRL gets to be X bytes, does Acrobat no longer embed it? Is this the same or different in 8.Xs and 9.Xs?

In 8.x it is very low (~32K). In 9.3.1 it is 200KB. In 9.3.2 it is 1.5MB. All of these numbers are the cumulative size of all OCSPs and CRLs embedded in the signature. There is no separate limit on a single CRL/OCSP.

I want to electronically sign a PDF---what do I need to do?

There are lots of different ways to electronically 'sign' documents, but they vary in terms of reliability, longer-term validity, and application.

At a very basic level, you could create a signature stamp or use the (new in Acrobat 9) 'Apply Ink Signature' capability to put a handwriting-like signature on the PDF that could be printed out or emailed, much in the same way a fax signature might work. These signatures don't get you much more than that fax signature, and can be manipulated, duplicated or deleted unless the document is 'flattened,' but it's one way to get started. Unfortunately, these kinds of signatures will not lock out changes or notify the recipient if something has been changed in the document...which is not so different than a wet ink signature, is it?

At a more sophisticated level, you could use a dedicated signature pad and software to capture your signature and embed it into the document. This can lock the document and notify the recipient if changes have been made. Several of our partners provide hardware and software plug-ins to manage this type of signature: CIC, Interlink, and SoftPRO.

Finally, you have digital signatures, which can lock down the document and notify recipients that the document has been changed, resulting in higher trust in the document. Acrobat provides you with the capability to create so-called 'self-signed' digital IDs (credentials) used to create digital signatures. While these are convenient, they do not offer the recipient any proof of the signer's identity...the signer is vouching for his or her self. However, this may be sufficient for personal use or small-medium businesses exchanging documents in trusted relationships.

You can also purchase digital IDs from third party 'Certificate Authorities,' who can validate your identity and provide better assurance as to your digital signature. These digital IDs may offer other benefits too, such as automatic trust in Acrobat and Reader, and embedding of secure time & validation information (Certified Document Services).

Does Adobe provide digital IDs (certificates) for use with digital signatures? If not, where do I get them?

No, Adobe does not provide digital IDs, other than giving you the ability to create self-signed ones. We rely on close partnerships with a number of leading Certificate Authorities (CAs) from around the world to provide these certificates to our customers. Certificates can be bought on a one-off basis to sign your PDF documents and email, or your organization could actually contract with these CAs for a managed service where certificates are provisioned to your users via web interfaces. Other partners sell appliances and other products that can make deploying certificates quite easy. Visit our Security Partner Community and explore the partners and solutions listed under "Digital ID infrastructure."

Of course, your organization may already be running a PKI (public key infrastructure) in-house that can provide you with a digital ID...be sure to check with your IT department.

I've read about CDS...how do I join the program?

Note that Adobe does not sell CDS certificates per se, but rather administers the program and provides the structure by which our CDS Providers can create these higher assurance, higher trust signing credentials---in use today with the US Government Printing Office, top universities, and other organizations looking to provide assurance as to the authorship and integrity of documents of record.

So, if you are interested in taking advantage of these credentials to sign your organization's PDF documents and experience the automatic trust provided by CDS, please contact Adobe's CDS Providers to purchase a CDS digital ID.

However, if your organization actually operates a Certificate Authority, and you would like to learn more about how to participate in the trust programs offered by Adobe, please contact us here. 

Where do I go to get more information?

  • Visit and subscribe to our blog at Security Matters
  • Visit the AcrobatUsers.com Security Forum
  • Explore the Learn.adobe.com wiki and documentation site
  • Be sure to use the built-in product help files!
Labels
  • None