OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-enotary message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [legalxml-enotary] Next Meeting


A. Next TC call

Day/Date: November 18, 2002 
Time of call: 9:00 AM EST
Conference Dial-in: 512-225-3050
Conference Guest Code: 84759#

B. Regrets

Eric Cohen, who will be in Hong Kong. Many thanks for the courtesy of informing us of your absence.

C. Agenda

1. Security Joint TC and its F2F meeting request

2. Dr. Leff's research

He writes:

I found several interesting articles on the role of notaries in electronic commerce and their relationship to digital signatures.  Several of these concern
other nations or Puerto Rico.  I have ordered these via interlibrary loan.

Milton G. Valera, "New Technology and a Global Economy Demand that American Notaries better Prepare for the Future: Upgrading the Current Common Law
System May Mean Establishing a New Class of Cyber Professional," John Marshall Law Review, Summer 1999 32(4), 935-964 is an excellent summary of notarial laws.  It has three parts.  The first part describes the illustrious history of notary publics and compares their role in the United States with other countries.  The second part discusses how their roles could usefully be expanded.  Finally, the relationship of these roles with that of the evolving electronic commerce
is elucidated.

In many countries, notaries put private transactions in proper legal format,  authenticate them, and record them.   They often must be graduates of law schools.  These notaries are similar to the Roman tabelliones who would draft deeds and wills.  They were allowed to register acts directly into public archives without a court proceeding.

American notaries' duties were always modest.  At one time, they archived documents, and in many states could serve as a kind of public stenographer, 
taking the document down as it was dictated.    (Some state statutes, including California, still give notaries the power to "take" documents.) Another obsolete power is to verify the condition of shipped goods, once important for transatlantic commerce in colonial times. Washington State has given the notaries the power to "certify" that something occurred.

However, the "core duty" is to insure that a person who signs the document is the person purported, is aware and is not under obvious duress. In some states, another duty is to verify that the person has authority to sign the document.  This might include checking a power of attorney or partnership agreement. However, other states such as California removed this function. This creates a problem.  Sometimes, attorneys in state A insist that a notary in state B certify capacity according to the forms of state A.

Valero points out the National Notary Association notes the following additional functions that would be useful in interstate and foreign commerce:
 1)
certifying facts about adoptive parents for foreign adoptions
  2)
certify that a pensioner receiving a foreign pension is still alive
 3)
certifying true copies of documents
 4)
certifying photographs for renewing a foreign passport
 5)
certifying age for ordering products such as cigarettes.

Florida and Utah have already created statutes authorizing "electronic notaries"who would certify digital signatures  (citing FLA STAT ch 117.20 (1998)). To become an electronic notary, the person would have to be commissioned as a regular notary and be issued a private/public key by a certification authority.  The Florida Secretary of State would "amend" their certificate. Note, that such notaries would still have to have the person personally appear and keep a sequential journal of all acts performed.

I found the bill that  became law creating electronic notaries in Florida (House Bill 1413, 1997 Regular Session).  However, that statute has not made it to the civil code.  Arizona also established an electronic notarization. (Title 41, Chapter 2, Article Three, Arizona Revised Statues)

Arizona's statute provides for notarization in the presence of the electronic notary. It also allows the electronic notary to give a person a token by which they can later notarize their own documents without going to the notary again. The electronic notary would be responsible for ensuring that the party requesting one understands the significance of their "notary service electronic signature certificate." An electronic notarized document is required by the statute to contain the document, time and date stamp, and an electronic notary token.

The statute also provides for electronic acknowledgments, jurats, and oaths or affirmations.

Valeria also notes the relationship between notaries and certificate authorities, and notes that Verisign uses notaries to issue its "highest class of digital ID."

The American Bar Association's Information Security Committee conceived of a "CyberNotary" who would have both computer and legal specialist.  They would be similar status to the Latin notaries  and whose main purpose would be facilitating international commerce. Florida also created a "civil-law notary" who must be a member of the Bar, and who could issue "authentic acts." This is a separate title from both regular notary or cybernotary.  (I did find the section of their code
regarding civil-law notaries.)

On a related subject, Valeria noted that many of the  state statutes restrict notarial fees to very low amounts and require very small surety bonds of no more than a thousand dollars.  In some cases, the amount of these fees have not changed since the state joined the Union.

I look forward to sending you more information when I receive it from our interlibrary loan department.

Sincerely yours,



Laurence L. Leff, Ph.D.
Associate Professor of Computer Science

cc: messing
** P. S. ** The Open Interchange Consortium prepared a paper on standard messages for managing electronic mailing lists, i. e., subscribing and unsubscribing.  They mentioned the role of an electronic notary in this process, but I am not clear why any more verification is needed than that customarily used for this purpose.  (www.oic.org/3b1a4.htm)

3. A propos of the Arizona statute, this was just posted by Russ Savage of the Arizona Secretary of State's office, charged with eNotary regulation in that state, to the American Bar Association Information Security List, in regards to the so-called non-repudiation bit in a digital certificate as specified in the X-509 Standard, and proposed changes thereto.

His perspective is --

that of actually trying to establish electronic signature policy for this state and then assist agencies and local jurisdictions implementing electronic signing processes.

Our statute http://www.azleg.state.az.us/ars/41/00132.htm has several statements but is driven by one sentence: "An electronic signature shall be unique to the person using it, shall be capable of reliable verification and shall be linked to a record in a manner so that if the record is changed the electronic signature is invalidated." While there are later statements specific to PKI, this definition is technology neutral and is asking simply that whatever signing process is used meets something comparable to the forensic evidence one expects from a pen and paper signing process - to be able to reliably determine who signed and check the technical integrity of what they signed. I believe, even with pen and paper, evidence as to intent, time, etc are determined by context.

While our statute is titled " 41-132. Electronic and digital signatures; exemptions; definitions" and the definition is of the criteria for an electronic signature, the reality is that what is effectively defined is an signed electronic government document - with all the implications of what a signed government document is. Trust me, if you think this discussion of "non-repudiation" is confounding, sit through unending debates among IT, business management and archivists about the meaning of the verb "to archive" or "to migrate" =:0

When we implement a signing process that uses PKI, it is with the expectation that X509 defines a set of engineering principles for constructing the encryption/decryption engine inside an application. The extensions SHOULD tell the application what that particular key pair was issued to do. The application SHOULD consider many aspects of the engineering principles (has this cert expired or been revoked? are the extensions required to do this specific use properly set? that is, is this the right type of key pair for this particular use? was it intended to be used this way? is this use prohibited?). That is all the non-repudiation bit is for - this private key was acquired for and MAY be used in a "legal" signing (a type of encryption/decryption process). It does not invoke any legal standing by itself. However, its being ignored when it is clearly set to NOT allow that use may leave the application vendor liable (IMHO). This is along the lines of saying my
pen and paper signature was created with "legal" ink - it may or may not be legally binding depending on all sorts of other evidence.

The difficulty with PKI is not with the engineering principles as defined by X509. It is that few commercial products that are PKI aware will correctly interpret the extensions. Or, as was noted some weeks back, may not even check the CRL or the chain of certs as being a valid, trustable chain - even for SSL uses!

For me there are at least three layers to this onion:
1. the encryption/decryption engine inside a signing process application (e.g. PKI)
2. the signing process application (e.g. email, an implementation of DigSigXML, Adobe Acrobat signing, etc)
3. the context of signing (and retention) - what in the event gives clues about the signer's intent, who they are and the integrity of what they signed? Having the nonrepudiation bit set or not set means nothing if the application ignores the bit. Having it set and using an application that checks it gives you a clue about intent but not the whole of the evidence on intent.

I happen to have four PKI certs (and two PGP keys). The PKI cert/keys have wildly different levels of how well I was identified and authenticated and how they are coded (for very different uses). I doubt many applications for signing, encryption or authentication will hiccup on any of those differences. THAT is the failing of PKI - it is not the X509 spec or the concept known as PKI, it is the deployed applications, the vehicles that the engine known as PKI is in.

Aware of these general failings, our state PKI standard essentially lumps all PKI cert/keys into four categories:
1. a person's authentication/encryption cert/keys
2. a person's authentication/signing cert/keys
3. a device's authentication/encryption cert/keys
4. a device's authentication/signing cert/keys
This was done to begin educating our community about the possible uses while keeping it simple enough to actually work. And to try really, really hard to have key recovery on any long term encryption use but no key recovery on any signing use with legal intent.

While Hoyt cries over our gutting X509, let me emphasize that that decision has nothing to do with X509 or the potential of PKI. It is a recognition of the fact that debates over terms used in completely different areas of expertise help give the application vendors plenty of cover for not meeting either criteria (legal or technical) when they need to meet both.

I think the comments that started all of this have merit if they are looked at as comments about signing/authentication/encryption processes rather than about esoteric technical issues that should be implemented inside a tool. The signer will never see or understand the insides of the tool. We need to be sure that the use of the tool - how it works and the context is may be used in - gives us what we need for evaluating the intent and validity of a signing event. The ABA-ISC has
done a great job articulating the framework - the PKI Guidelines.

I have no idea if my comments here help in anyway with the task at hand. Hopefully they at least shed some light on why I keep coming back to certain issues :)

My wish is that we move from debate about the PKI engine to talking about the types of uses and their legal implications (and vendor liability/responsibility to make the vehicle that PKI is inside of reliably deliver the goods - e.g. signed electronic documents, authentication, encryption).

respectfully,
Russ

Russ Savage
Electronic Transactions Liaison
Arizona Secretary of State
1700 W. Washington St
Phoenix AZ 85007
602.542.2022
rsavage@sos.state.az.us

John Messing: My own belief is that the eNotary TC needs to distill these and other authorities into certain propositions about when machine-authenticated evidence shoud be considered legally self-authenticated evidence and why. That dividing line will have enormous marketing implications not only for signature and authentication products but for various other products that make use of such technologies in the marketplace.

John Messing
3900 E. Broadway Blvd., Suite 201
Tucson, AZ 85711
(520)547-7933 (v)
(520)547-7920 (f)
jmessing@law-on-line.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC