Adobe added a robust digital signature architecture to the PDF electronic document standard. They also support sophisticated form filling and document roll-back capabilities. As mentioned in earlier posts, PDF has made significant progress as a de facto standard for electronic documents and the inclusion of sophisticated digital signing further enhances PDF’s 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.
Adobe specificed an extensible signature dictionary as the analog of XMLDSIG’s <Signature> element. 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 1100+ pages) and associated IP to create PDFs are freely available. Certainly Adobe 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 and complex relationship of trust. This is similar to the weakness in the XMLDSIG paradigm. Additional complexity is created by the fact that PDF depends upon PDF specific trust relationships, for example it does not use the standard Windows certificate store. 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 are still no universally adopted credentias that one can assume are 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. 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 the 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 ESIGN. An example is the capture of an electronically recorded handwritten signature with its associated biometrics as well as extended signature ceremony data. Doing this requires the use of another plug-in or aplet to capture and embed this information in the PDF document. Several vendors provide PDF plug-in solutions such as this.
Other signature systems using PDF documents implement the signature using a detached signature that references the pdf document and provides the necessary signing information and tamper evident seal. They may embed an image of a handwritten signature or seal into the PDF as an image field. This model is well suited to the workflow of many businesses but it may not use the PDF signature dictionary at all!
So are signable PDFs the way of the future? Maybe, but probably not exactly as Adobe believed that they would be!
Subscribe to Esignature Post feed
Hi Mike,
This morning I read your article about PDF signing, a nice article I must say. Here in the Netherlands we see lots of applications using this PDF signing. All though it does not work with the Microsoft Certificate store it does work with PKCS#11 based tokens. In most cases this part is covered. The big issue in most cases is the “See what you Sign” part which is not very well addressed at the moment, what do you think about that ?
Keep up the good work,
Jan Rochat
CTO AET (www.aeteurope.nl)
Thanks, Jan and you have some good points.
I know that Adobe has several initiatives on the “see what you sign” front, including SigQ and the ongoing work on PDF/A. I hope to get some participation by Adobe people soon. Adobe is starting from a huge, complex specification that attempts to be all things to all people and properly restricting it is a challenge.
I still believe that depending on a ubiquitous and reliable PKI credentialing system that is used by the general public is a significant problem with Adobe’s defaults, and its solution is probably still years away. My thought (from a parochial perspective, as I have not been involved in European efforts to any extent) is that both Adobe and the European community are institutionalizing the digital signatures without having such a system in place. The work on ETSI TS 101 903 and the W3C’s XMLDSIG largely focuses on the document security and assumes the existence of ubiquitous PKI.
Likewise, signature standards are not enforcing the process or ceremony required by law. Both Acrobat and XMLAdES require extensions, and those are not yet standardized.
Good post. Interesting that Microsoft announced Office 2003 SP3 ‘blocks’ older versions of word: http://www.downloadsquad.com/2008/01/03/office-2003-sp3-blocks-old-file-formats/
Hard to imagine basing electronic signatures on Word when Microsoft explicitly doesn’t support aging versions.
PDF isn’t perfect, but a far superior archiving choice if nothing else.