The Legal Implications of Digital Signatures: Is a Digital Signature a Legal Signature?

It should be clear by now that a digital signature can provide the following technical security properties: authentication, data integrity, and (in some cases) non-repudiation. A digital signature is a security mechanism. Its meaning in the real world is something else entirely.

A digital signature may be used to create a legal signature, but only if proper procedures are followed. For a digital signature to create the effect of a legal signature, the following must be done:

  • The signer must view the entire document (or data to be signed).

  • The signer must intend to authenticate the document to be signed.

  • The document must be digitally signed in the proper form by the signer who is named in the corresponding certificate.

  • The use of digital signatures as legal signatures must be legal in the jurisdiction(s) of the parties.

  • The signed document must be validated at the time of signing.

  • The signed document may need to be countersigned by a time-stamping authority or cyber notary if the signature must be relied on past the time of the signer's certificate expiration.

As you can see, the first four requirements are not measurable by software. Yet, if you need a legal signature in support of legal non-repudiation, you must address these requirements.

Additionally and importantly, digital signatures are not specifically recognized in law in most jurisdictions as being valid legal signatures. As of this writing, the United States has no national statute governing digital signatures used for commercial purposes. U.S. state laws either say nothing or apply only to certain transactions, and they often conflict with each other. Inter- nationally, a few countries (Canada, Singapore) have adopted national statutes, and a European Union directive is in place that will lead to national legislation in the E.U. countries over the next few years. An alternative to this quagmire will be discussed in the following section.

When You Want to Use a Legal Signature

Legal signatures are not required of every application that uses digital signatures. However, if the purpose of your application is to record a human being's agreement, acknowledgment, assent, acceptance of information, and so on, then you have a need for a legal digital signature. Put another way, if your application is replacing (or would replace) a paper process that requires an ink signature, you must meet the requirements of legal digital signatures.

Recording Intent

In the United States, commercial law states that a document is signed when it "includes any symbol executed or adopted by a party with present intention to authenticate a writing." How do you know someone intends to authenticate a writing by making a digital signature? You have to ask them.

This could be done by a dialog box that states, "By clicking 'SIGN'below, you intend to be bound by the terms stated above." You should also include a statement of intent in the information to be signed, because your dialog box will not be captured as part of the signed data.

A classic contract states at the bottom something like, "agreed and accepted this 15th day of February, 2000." Your statement of intent needs to be appropriate in the context of the information to be signed. For example, a digitally signed time sheet or expense report might state, "The above information is true to the best of my knowledge and belief." You might need to involve your corporate legal team in these questions.

Recording the Form of the Transaction

For a document to be properly authenticated at a later date, you must be able to prove up the "four corners of the document." In other words, you must be able to prove what the person saw with his or her own eyes when the document was signed.

Note

I'm sure we've all seen movies in which one person is tricked into signing a blank piece of paper, only to find later that the paper has been turned into a contract of some sort. If the person who was tricked can prove that the paper was blank when he or she signed it, then the contract is not legal. In this situation, the holder of the contract would be unable to prove that the contract in hand is what the signer saw when he or she signed his or her name to the paper.


Consider typical forms-based applications. The user enters data into the form. The data is sent to a server for data validation. After the data is validated, it is written to a database. I would venture to say that 99% of software applications written do it this way. However, this is legally insufficient. It really did not matter much in the days of enterprise applications. The enterprise was the ruler of the kingdom and, as such, made most of the rules. Now it is the Internet world. This world is governed by statutory and contract law, which includes the laws of many jurisdictions and two dominant legal systems—common law and civil law.

You must record both the form and the content of the document. You must be able to prove what the user saw when he or she signed the document. This includes all data, writings, images, colors, and so on. You must be able to reproduce—from the digitally signed information—what the user saw when he or she signed the information.

This is easier to do with Web-based information and harder to do with hard-coded user interfaces. Here's an example of capturing a legal digital signature in a Web-based transaction:

  1. Authenticate the user to the form page using Digital Authentication (SSLv3 client authentication; this step is optional).

  2. Have the user enter the data into the form and submit the form using standard HTTP POST processing.

  3. Validate the data at the server and record the data in a database.

  4. Present a standard HTML page (or XML variant as they are standardized over time) with the complete information to be signed. This is the equivalent of a paper page. Ideally, the page should not have any external references (such as Java source files, IMG files, external style sheets, and so on). What the user saw should be clearly provable from the page source. The page data should include a clear statement of intent.

  5. Have the user digitally sign the page using an appropriate mechanism (such as the http://AlphaTrust.com Web Page Signing Control, available from http://www.alphatrust.com). The signed data must include the entire Web page from <HTML> through </HTML>.

  6. The signed data, including the signing certificate and optionally, the certificate chain, must be posted back to the server. The signed data should be in a standard PKCS#7 or CMS format.

  7. The signed data is validated at the server by a Web-based process or COM control (such as the http://AlphaTrust.com Web Page Validation object, available from http://www.alphatrust.com). The data validation must include a signature check and a certificate revocation check. Optionally, you may countersign with a time stamp or use a data certification service to "seal" the signed data for historical preservation.

  8. The signed data is stored in a database as part of the transaction record.

  9. You may optionally send the signed data to the user for the user's records.

The requirement to store the signed data impacts the database size accordingly. There is no way around saving this data, though. At least storage keeps getting cheaper and cheaper.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset