The Esignature Post

The Portable Document Format (PDF) has become a defacto standard for electronic document publishing. It was derived by Adobe from Postscript in 1991-1992 (code named “Carousel”) as an application independent method for distributing electronic documents across platforms. It was released commercially in Acrobat 1.0 in 1993 and truly began to gain momentum when the Acrobat Reader became a free download in 1994 and plugins were developed for the popular Internet browsers.

Adobe released the entire PDF Version 1.7 specification to AIIM as an Open Standard in 2007 and it has been approved as ISO 3200. There are other PDF standards that are worth noting for electronic contracts, particularly PDF/A, approved as an electronic document archiving standard ISO 19005-1 in 2005. Unfortunately PDF/A is based on an older version of the PDF specification, Version 1.4, which did not have as sophisticated of a document signing and history capabilities, this is expected to be addressed in future revisions of the ISO standard.

PDF has several benefits as a mechanism for maintaing electronic documents. Its ubiquity is certainly an advantage, that is nearly anyone with access to the Internet can view the document. It is also fairly easy to restrict PDF documents to insure that “What you see is what you get sign.”

Adobe added a robust digital signature architecture to the PDF electronic document standard. They also support sophisticated form filling and document roll-back capabilities. Many organizations are already generating PDF documents as their standard for manuals, forms, contracts and other traditional paper uses, this would seem to make the use of the PDF signatures even more compelling.

PDFs use extensible signature dictionaries as the analog of XMLDSIG’s <Signature> element. The signature dictionaries contain a byte range digest or object digest of data that is signed, supporting the use of sectional signing and multiple signatures. The PDF signature dictionary has native support for PKCS#7 and X.509 digital certificates, Acrobat and other programs will allow you to import or export certificates from Windows certificate store, PKCS#12 format certificates and smart cards for use in a PDF document. Adobe has published a useful primer on using certificates with Acrobat at Digital Signature Users Guide.

Additionally Adobe has developed SigQ and Adobe Certified Document Services and works with ISO and AIIM on implementing “open” trustworthy electronic document standards. The PDF specification (all 1300+ pages) and associated IP to create PDFs are freely available. Certainly PDF signatures must be the way of the future, right?

Unfortunately, the actual implementation of digital signing using PDF’s integrated capabilities has proven to be more challenging. Because of the reliance on a PKI, deploying the default Acrobat PKI-based signatures also requires the implementer to have and configure a sophisticated PKI. This is similar to the weakness in the XMLDSIG paradigm. Many of these challenges and the general lack of intutitiveness are addressed in a post by acrobatusers.com blogger Duff Johnson here. The end result is that the PKI based signatures are often easiest to use inside of existing companies or business relationships.

Another barrier has been complexity and confusion over generating Reader signable documents. Prior to Acrobat 8 this required purchasing an expensive license to Reader Extensions for Adobe’s servers. Since the advent of Acrobat 8 this may be relaxed – please consult with your local licensing expert!

Even after addressing the issues above one still has the fundamental problem of electronic credentials. All PKI based signing systems require the existence and maintenance of trusted electronic credentials and there is still no universally adopted credential that one can assume is possessed by all of the prospective signers in many business processes. Businesses often do not even want to assume responsibility for doing this for their own customers and partners.

These complications have certainly contributed to slower implementation of signable PDFs. Most of the signed PDFs you see are probably downloaded from Adobe! Many evaluators that initially think that they will go in this direction ultimately choose a more proprietary system – although one that often uses PDF for the document. We will discuss some of these below.

Adobe’s default verification plug-in often does not support all of the information that a business wishes to associate with a signature or signed document. The user of the electronic signature may want the signature to be self-contained, that is contain all of the elements required to meet the requirements of UETA. An example is the capture of an electronically recorded handwritten signature with its associated biometrics as well as extended signing ceremony data such as host IP address or network MAC address and a reference to the signing process being enforced. Doing this requires the use of another plug-in or aplet to capture and embed this information in the PDF signature dictionary. Several vendors provide PDF plug-in solutions such as this. Now a signature has been created that can not be applied or properly validated in the basic Adobe Reader. When the default Adobe Reader encounters such a signature it will complain that there are fields that it doesn’t understand.

This creates an opening for other signature systems that use PDF documents, but implement the signature using a detached digital signature that references the pdf document and provides the desired signing information and tamper evident seal. Such a signing system may embed an image of a handwritten signature or seal into the PDF as an image field. It may even use the PDF dictionary for a final, invisible signature that can detect any modifications to the document after the other signatures were applied. This gives the relying parties confidence that they are viewing an authentic electronic copy of the signed data using Adobe Reader, and depends upon another system to produce the audit trail and evidentiary data of the signing process if the document’s authenticity is disputed.

At this time many electronic workflow systems use PDF as the native document format. However most of them do not use esignatures and those that do seldom use an unadorned PDF digital signature.