Do you trust me?

January 30, 2008

Another area that is routinely conflated into the electronic signature/document processing stew is the topic of authentication. Authentication has many meanings, but in the context that it is usually used in the electronic document space it refers to “How do I know it is you signing this document?” This has obvious ramifications for non-repudiation.

Authentication then brings in the issue of trust. Do I trust your credentials/identification? Just as in real-world, potentially you could be an impersonator with a fake id. Peter Gutmann at the University of Auckland has an interesting (if slightly dated) discussion of issues around using electronic signatures, with a focus on signature laws and using PKI as an adequate proxy for trustworthy credentials. This presentation can be found here, Guttman on PKI and signatures. One area to note is the section on Trust beginning on page 23.

Mr. Gutmann discusses types of trust. His taxonomy includes (but is not limited to):

  • Blind Trust, where we trust because we have to, or there are no significant repercussions for a breach of trust
  • Swift Trust, which is hedged (limited liability) trust given to establish business relationships
  • Knowledge Based Trust based on a history of interactions between the trusting parties
  • Indirect Trust based on a trusted intermediary, such as a credit card

All of these forms of trust come into play in the world of electronic transactions. A business supports blind trust when it allows you to request a car insurance quotation online and emails you a link where you can access the web based applications. When a quotation is issued based upon your applying at the private link it has granted you swift trust. And when it issues you the insurance based upon you making your first payment with your American Express it employs indirect trust, American Express guarantees the payment!

In each step the business is increasing its confidence, or trust, that you are you. This is has been done through a web of interlocking identification factors: you own the email address, the car is registered in your name and you have provided a valid credit card which has the same billing address as your car registration. Each step has been hedged so that the insurance company (which assumes all liability if it is defrauded) has made a decision on the acceptable levels of business risk.

Peter Gutmann seems to believe, and I concur, that prescriptive digital signature laws do little to mitigate the risk of electronic transactions in an acceptable way. Furthermore, they may create more problems than they solve.

I would add to this that the general electronic signature laws (ESIGN/UETA in the US) provide all of the legislative framework that is necessary. With these laws, and a sensible approach to risk management through authentication and intermediaries, electronic transactions should have no more risk than the face to face transactions that we engage in every day.


Signing PDF Documents

January 2, 2008

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!


The best form of electronic document for signing

December 3, 2007

When you first decide to add signed electronic documents to your workflow the tendency is to want to sign the document in the native format of the creating application. So people often think that they want to sign Microsoft Office files, emails and CAD files. However there are several considerations when it comes to actually deploying the system.

What are retention requirements? If these signed documents need to be accessible in 10 years is the Word document format an appropriate format for archive?

Who will be signing the documents, and where? The availability of viewing tools is critical, as the document will need to be viewed electronically.

These considerations often cause the direction to turn to standard formats for archive. One format that has become very popular in electronic document archiving is the TIFF standard, largely due to its origins in the scanning and archiving of paper documents. TIFF is readily viewable using many applications and has proven to be a durable specification, as has its cousin in the imaging world, JPEG. These documents are easily signed and displayed. Indexing and storing requires using metadata tags as these documents are not inherently searchable.

Text documents have significant advantages for indexing and searching, but raw text lacks the formatting and images that are critical parts of most modern documents.

HTML and XHTML are gaining in popularity. The problem to date has been using restrictions to insure that the document is consistently rendered by the multitude of applications that display HTML.

The newest standard to gain favor is the Portable Document Format (PDF). This specification, developed and popularized by Adobe through its Acrobat family of products, is based on widely adopted Postscript page description language with extensions to support embedding fonts and other information useful to make a truly portable, device independent document format. Adobe released the PDF specifications and the rights to use them royalty free, although Adobe still owns copyrights. They also worked together with the ISO, AIIM and NPES to create the PDF/A format for long term document retention. The PDF references are available from Adobe here, and the PDF/A specification is available from the ISO. More information on PDF/A can be found at the PDF/A Competence Center.

In practice we have found that many organizations are migrating to the PDF standard, for multiple reasons. Native PDF has several advantages over image formats, in that PDFs are readily indexed and searched. However the biggest advantage is the ubiquitous and free Acrobat Reader. The prevalence of this application insures that nearly everyone that looks at a PDF document will see the exact same document. Other important features are the strong document-centric format and integrated support for digital signatures and X.509 digital certificates.

In the future we will have a section on methods for developing esignatures for PDF documents.


Follow

Get every new post delivered to your Inbox.