RE: [dss] freezing doc, and next steps

["jmessing" <jmessing@law-on-line.com>]

The explanation that Trevor gives of an eNotary DSS service is close to the UPU model, in that both assume that a human notary does not witness the act of signature as it occurs. Absent such human witnessing of a notarization, it is probably not legal at this time in any state in the United States except Arizona. In the Arizona legislation, such a model of enotarization is called "notarization outside the presence of a notary."

The other model, where a human notary witnesses the act of signature, is called, not illogically, "notarization in the presence of a notary". 

Both a UPU or a DSS could be invoked for a notarization in the presence of a notary, where the notary was the holder of the key, in the UPU model or was the authenticated signer, in the DSS model. In this model, the client signs electronically by unspecified means, as for example, a click-wrap. The notary's trusted status, as in the paper world, suffices to establish an "inherited trust" in the signer's action. Thus, the notary could wrap a crypto signature around the signer's document, basically attesting to the fact that the signer did some act to evidence an intent to sign the document.

A common way of a signer expressing his or her consent is by a digitized signature, which is common in some retail outlets in the United States to sign credit card receipts. On May 28, 2003, the National Notary Association, which is very respected, announced the availability of a biometric kit, available to its members (and others) for a price, for use with an electronic journal in connection with notarizations. By way of explanation, notaries keep journals of the various acts of notarizations. In connection with the notarization of a document, an entry is made in the journal of the date, time, etc. The document signer also signs a journal entry. The journal functions in the paper world like a timestamp does in the electronic world. It is a consecutive record chronologically arranged to prevent later back dating of documents. In the National Notary offering, the digitized signature and biometric identifier of a signer, with optionally a photograph are entered into the electronic journal. This is probably a step preliminary to obtaining authorization to use this method for the notarization itself, but presumably the notarization remains on paper, for the time being.

For more information on the National Notary offering, see http://www.nationalnotary.org/enjoa/index.cfm?Text=enjoaFeatures

The eNotarization TC of LegalXML-Oasis' charter tackles these issues. If interested in further information, please contact me offlist.

Best regards to all.

John Messing

---------- Original Message ----------------------------------
From: Trevor Perrin <trevp@trevp.net>
Date:  Tue, 03 Jun 2003 14:03:53 -0700

>At 05:50 PM 6/3/2003 +0200, Gray Steve wrote:
>
>>Please refer to my answers to John's questions below, marked as <UPU>
>>
>>-----Original Message-----
>>From: jmessing [mailto:jmessing@law-on-line.com]
>>
>><sg>
>>2.9 eNotarization in Presence of Notary
>>
>>Status: Neutral
>>
>>Comments: We do not agree that this feature should be a protocol issue. For
>>example if we EPM-enabled a Canadian Bar Association application or a
>>specific application utilized within Doyle, Selusci, Jacobs, and Associates
>>... we would have accompished all that this requirement is intending to
>>achieve without burdening the protocol. Besides this is the domain of RFC
>>3126 and ETSI 101 733 Signature Policy anyway.
>>
>></sg>
>>
>><jm>
>>
>>I have reviewed RFC 3126, which states it is identical to ETSI 101 733 and
>>indicates that it is informational only, not a standard. As for RFC 3126, it
>>is PKI specific.
>>
>>In the context of the use case, I have trouble understanding your comments.
>>They are directed to long term electronic signatures, I assume because of
>>the reference, but this is different from notarized signatures, which also
>>involve other considerations.
>>
>>Can you explain further?
>>
>>
>></jm>
>>
>><UPU>
>>What we are saying is that the EPM is also a Notary service for the
>>electronic world. Using the analogy of a Notary "on paper" a document is
>>notarised by witnessing a document being signed.  The EPM does the same
>>thing for electronic documents, but the "witnessing" is performed by the
>>Posts EPM Server once the integrity of the document and the digital
>>signature has been verified, again by the Postal EPM server. The evidence
>>supporting the signed and EPM'd document is then stored and archived by the
>>Posts.
>
>The eNotary service alluded to in the DSS requirements is a little 
>different - the client would authenticate to it (using a password, say), 
>and the service would sign the document using its own private key, while 
>adding the client's name as a signed attribute (this is what we mean by 
>"Identifying the Requestor").  Whether this is a better or worse analogue 
>of a "physical-world" notary I dunno.  The chief difference is that an EPM 
>notary assumes the client already has a keypair/cert he can sign with, 
>while an eNotary assumes the client only has some way of authenticating 
>himself.
>
>
>>Perhaps I need some clarification as to the scope of this Requirements
>>documnet. In my view, eNotarisation and Court Filings are "Use Cases" not
>>requirements for use cases. That is why we have stated that we do not think
>>this feature needs to be addressed in the subsequent protocol/
>
>You're right - things like "eNotarisation" and "Court Filings" are use 
>cases, not requirements.  The contents under 2.9 and 2.10 are "particular 
>features" of these use cases which the requirements proper (in section 3) 
>are intended to take into account.
>
>
>Trevor
>
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
>
>