Let’s Get Started..

December 18, 2008

One of the hardest things about using electronic signatures in enterprises seems to be getting started. Or, as it was once put to me, “How do I justify putting this in my top 10 projects that will actually get done this year?”

One way that I think works well is to just begin by using one of the easy, hosted services for a couple of the occasional needs that you may have.  I use Echosign, a pioneer in this area, for executing NDAs and the like in my personal business. I have  found that the people that I send them to are ok with this, it is faster, and gives me a signed electronic document so that I don’t have to keep as many faxed copies and originals on hand.  In fact the money saved on FedEx can probably pay for the service!

I would suggest that anyone considering electronic signatures can easily get started by using a hosted service provided by one of a few providers.  You can start with just something relatively simple like NDAs that probably run outside of your standard workflow system anyway.  And once you get started you will find that a number of signature suppliers already integrate with the top CRM or ECM systems.  If you use Salesforce.com, the current version of Echosign supports it. Of course you would have to upgrade from the free version that I use for my small business!  (0;


A little on E-notarization

July 16, 2008

OK – I talked about this a long time ago and got busy and haven’t written anything. So I will try to at least say a little bit:

Notaries Public have a distinct place in society as being state licensed trusted witnesses. This has made the role of a notary public invaluable in many high value transactions such as real estate sales. The human notary’s function is to insure that the person is who they represent themselves to be and that they are executing the transaction of their own volition, i.e. they are not being coerced or in a state where they are unable to make decisions for themselves.

Many people have wanted to use PKI to replace this function, just as they want to use PKI for nearly all authentication functions. Unfortunately for PKI as a standalone solution to this problem the function of confirming that the person is not under duress or incapacitated is still best performed by a human agent.

Many states have enacted legislation to foster electronic signatures for electronic notarization. One notable effort has been put on hold, Virginia passed electronic notarization guidlines that were to take effect on July 1, but on June 24th got cold feet. They decided that much of the text, which was lifted verbatim from the Esign Act, was too ambiguous and offered too much opportunity for fraud. Maybe they believe that notarization must be more prescriptive in its implementation to help the poor county clerks that have to decide whether to accept signing methods!

One widely discussed electronic notarization method is Colorado’s. Colorado recommends the use of Document Authentication Numbers which is a very simple and clever method to electronically sign the document. The way that the Document Authentication Number works is that if a notary wants to obtain a license for electronic notarization they are assigned a unique notary identification number and are given a log that contains a sequence of random numbers. This sequence of numbers that is assigned to the notary is private to the notary and a copy is maintained by the Secretary of State for future validation purposes.

When a document is notarized the notary attaches his seal information, his identification number and one of the numbers from his log-book. He uses a different number for every document that he notarizes. This combination of notary number + random Document Authentication Number forms a unique signature for every electronic transaction.

Colorado also allows notaries to use other, non-specified electronic notarization methods by special approval:

3. Notification of intent to notarize electronically shall be on forms prescribed by the Secretary of State, and shall include a statement whether the applicant or notary will use only document authentication numbers as his or her electronic signature. If the applicant or notary indicates an intention to use a different electronic signature than document authentication numbers, then the notification of intent shall also be accompanied by an example of the electronic signature that will be used by the applicant or notary, and shall include the following information:

(a) A description of the technology that will be used for the notary’s electronic notarizations, specifically for the creation of the notary’s electronic signature;
(b) The name, address, telephone number, and web or e-mail address of the supplier or vendor of such technology; and
(c) Such other information as the Secretary of State finds necessary to confirm that the technology complies with the requirements of the Colorado Notaries Public Act, article 55 of title 12 of the Colorado Revised Statutes.

I don’t know what other technologies are being accepted in Colorado, this seems to pose the same county clerk dilemma as Virginia has. Perhaps there are other guidelines published by the Secretary of State, does anyone out there know the answer to this?

In any case I will join the list of bloggers and pundits that applauds Colorado for making the whole electronic signature issue something that is very easy for anyone to understand!


Administrivia

February 14, 2008

Since PDF is so important I added a PDF page, see Portable Document Format (PDF) signature, in the Esignature technology section. It has more information than the post on this topic.

In the process of writing this page I was struck by the way Adobe evolved from the company that wrote printer software… but I digress.

Hope to get up some stuff on eNotarization and authentication real soon now. Anything else you would like to see?


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.


It’s About Time

January 23, 2008

A key requirement for an electronically signed document is a trusted time stamp. This is very important for non-repudiation of contracts (was I bound by this at the time?) and for other important documents such as the disclosure of patentable inventions.

Proof of the existence of a signed document at a given time can be demonstrated by having a time stamp of the document signature issued by a trusted timestamp authority (TSA). A TSA is an entity that can demonstrate that it maintains its clock against a recognized time source such as NIST in the US. There are also standards for trusted time stamps such as RFC 3161 and ANSI X9.95, and a number of vendors that provide this service.

The basic process for obtaining a trusted time stamp is this:
The requesting party generates a hash or digital signature (only hashes may be signed in RFC 3161 compliant signatures) of the signed document and sends this value to the TSA. The TSA attaches a time stamp token to the hash, then digitally signs it with the TSA’s certificate. The requesting party validates the time stamp token and then associates this token with the signed document. This establishes that the signed document existed at the time of the time stamp. It does this without the TSA being aware of the conents of the digital document being signed, thus preserving the confidentiality of the signed document.

There are several ways of generating a time stamp token. RFC 3161 requires support of a time stamp token that contains the time as Zulu time, specified to the second, or better. It also requires that the TSA include a unique serial number with every timestamp issued so that the TSA name and token serial number define a unique time stamp.

Some other methods of generating timestamps rely on “document chaining” which includes a piece of the previous timestamp with each certificate thus establishing the validity of the time. Other methods combine this with using a single timestamp for a given interval of time so that many documents receive the same timestamp, and it is calculated as function of all of these documents. Should this timestamp be challenged several other document authors could be used as witnesses! An interesting survey of timestamping methods by Michael de Mare can be found here.

Some other methods proposed use transient keys, meaning the key used for signing the document hash is a function of the time. Generation of “trusted time stamps” is an area of significant activity, and many vendors will emphasize the advantages of their (often proprietary) methods.

Usage of a trusted time stamp is necessary for increasing the reliability of an electronic signature in a document. For many documents an institution may rely on its own time server for a TSA – this is legitimate as long as the institution is able to document its timekeeping policies and demonstrate their reliability in the event that the time stamps are challenged.

With many vendors pushing their own methods for time stamping and the significant complexity that can be attached to the topic it is easy to get confused. However the question that a relying party should ask is “How good do they have to be?” There are many ways of legally establishing the time of the occurence of an event. Just insure that you can justify yours!


It’s the process, stupid!

January 11, 2008

Looking at my own experiences and speaking with some of you makes it seem that there are two types of people working on deploying electronic signatures in companies. One type is the techie – this is the person that can tell you ten different ways to detect alterations to an electronic record and why anybody that doesn’t get that an electronic document is just a record is just stupid. This person is ready to start coding – and he may never produce a system that is usable and delivers legally binding signatures.

The other type is the cautious manager – this individual believes the existing paper or hybrid edoc/paper processes work fine and knows at least five reasons that the project is too risky, it is too expensive and should be killed or endlessly postponed until it sinks from view.

Yet everyone agrees that as more business and personal interaction moves into cyberspace the need exists and will be serviced. Growth of online purchases continues to outpace brick and mortar in the US. More and more the government is accepting electronic documents to streamline operations and comply with various regulations.

At some point everyone will need to concede that there are ways to make electronic documents far more secure than signed paper documents, and that they are different than paper documents! It is all about the process that is followed. Care must be taken to insure that individuals are aware of the transactions that they are engaged in and that their personal data is properly protected. Ultimately there will be a rich history of civil cases, law firm Buckley Kolar presents an extracted summary at the ESRA conference here citing some of the legal groundwork that is forming. But how long will you wait for this to occur? Waiting too long insures that your business will be left behind.

You just need to get your techies to use their wizardry to match the legal requirements – they are pretty clear. An overview is even available on the implementing esignatures page on this blog. The process for creating a legally binding signature and responsibly managing electronic documents is not that complicated, you just need to follow it.

Maybe the question is not can you afford to proceed ahead with esignatures, but can you afford not to? Businesses are gaining real savings in $, time and customer satisfaction with electronic document flow and electronic transactions – are you one of these businesses or are they your competitors?


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!


Why is Industry So Slow to Adopt?

December 19, 2007

Many of us in the esignature community are somewhat mystified by the slowness of industry to adopt electronic signatures. The ROI is demonstrated and generally accepted to be quite high for many documents, with improved productivity, reduced errors, more rapid processing, improved customer satisfaction and many other benefits. So it is remarkable that the government is leading the way ahead of many respected, world class companies in the private sector. The IRS has been willing to accept electronic tax filings from most individuals since 1998 and now receives over half of it filings electronically.

The Department of Education processes 14 million Financial Aid applications a year and is seeing significant growth in the electronic applications. They claim that none of the electronically signed applications has ever been contested. There is a nice presentation on the Department of Education’s roll-out from the ESRA Conference last month here.

An interesting opinion of Education’s authors:

Implementation will not be constrained by the technology or legal issues. It is constrained by the business side and its ability to handle the process re-engineering and the organizational willingness to change issues.

I guess it means that the Department of Education is more willing to change than most of our Fortune 100 institutions. Does this seem to match your experience?


XML Signature Page is up

December 14, 2007

The XML page is up to talk about this important technology: XML Electronic Signatures
Also – thanks for the ideas on structuring this site. I will be trying to incorporate things such as the XML technology PDF on static pages and possibly move to a static page for an entry. The blog will be used for updates on new technologies and depoloyment.
I am looking for co-contributors, anyone interested?


E-Signature Technology pages are going up

December 12, 2007

I’ve finished the first of the E-Signature technology pages, the beginning of a terminology primer, and hope to add more this week. I will be publishing technology pages geared at the intelligent lay person, as a practitioner it is more important that we carefully and correctly implement these technologies with widely available tools than that we have a deep understanding of the extremely complex mathematics associated with PKI cryptosystems.

Let’s get some discussion going here, I know that many people have greater insights than I and look forward to having you share your insights!


Follow

Get every new post delivered to your Inbox.