Re: [legalxml-enotary] eNotary System

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

[jm]I am having a tough time determining if you have an XKMS type of server
in mind in this scenario or not.

[manoj]"It relies on a third party, such as Verisign, Thawte, Equifax etc.,
to have verified the identities of the users of the PKI based digital
signature prior to issuing them a PKI key pair. Once the key has been
issued, it is the responsibility of the key recipient to safe guard the key
and inform the key issuer to revoke the key if the key has been compromised.
Once the key has been issued, the key owner can use it for unlimited
signatures with no involvement from the key issuer." (p1, Heading 1)

[jm]Though this probably is not critical to the analysis, I think the
description may be inaccurate as to VeriSign, Thawte and Equifax current
offerings as they usually do not issue keys. The browser does so locally
through a certificate request. The CA's sign the public key contained in the
request with their private key, creating the certificate.

[manoj]"The time lag between the time the key was actually compromised and
when the user became aware of it could be substantial. This creates
potentially big legal issues for both the signer and the consumer of the
signed document such as financial institutions, governments and people at
large." (p1, Heading 1)

[jm]Actually, I think it is the key compromise itself, no matter how long,
that creates the problem. Key compromise can go undetected for some time, as
you point out, particularly if there is no real time checking of
certificates, but ODCP is supposed to do real time checking of revoked
certificates, and in any event CRL's (certificate revocation lists published
by CA's) are often considered determinative off any rights of relying
parties. A very interesting but not very general problem is posed when a
compromised key is used to sign a transaction in the time window after
compromise occurred but before the CRL is updated by the CA, in the
so-called gap. However, the details of the gap problem, however
intrinsically interesting, do not affect the general problem  you pose.

[manoj]"The notary public serves as an enrollment agent or an intermediate
certificate authority. The notary database (1) is kept current with
daily/weekly updates from the Secretary of State. Once a notary signs up as
a digital notary using the notary enrollment system (2), s/he becomes an
enrollment agent/intermediate certificate authority. Notary uses the User
Key Issuance System (3) to issue keys to the general public after verifying
their government issued identities as per various state regulations. The
notary also scans and attaches a digital copy of this ID to the user
database after encrypting it with his/her public key. This ensures that only
the notary will be able to see the digital copy of this ID by decrypting it
using his/her private key. If the notary chooses not to use the scanned
images, s/he may simply enter detailed information of the ID such as ID
type, number, expiration, issuing body, date of issue etc. and answers to
some personal questions from the user, which the user can reproduce at a
later time when signing any electronic document. These questions would be
similar to the ones used by financial institutions, for establishing
identities over the phone, such as, mother's maiden name, place of birth,
favorite color, pet's name etc. This information is also encrypted using
notary's public keys." (Page 1, heading 1)

[jm]What updates from the Secretary of State are you referring to? This is
not a usual or common occurrence in paper notarizations, so without further
explanation, is incomprehensible to me. Why would users have a Notary issue
keys when they can otherwise generate their own keys in a browser or an
application (such as a smart card application like Litronic), the private
key of which is never shared with a Notary? What are the state regulations
for identity issuance are you referring to? The sources of identity
management is a very hot topic right now in state governmental circles, and
the federal eAuthentication process. Like many technical publications, your
paper assumes that there is agreement and a structure in place so that the
proper bureacratic infrastructure can be assumed to be in existence and
stable. This is an unfounded assumption, from my experience. For a realistic
assessment of the problems if identity assessment, and a suggestion about
profiling which bears some resemblance to your knowledge based
identification, please see the article by Norman A. Willox, Jr. chairman of
the National Fraud Center and chief officer for privacy, industry and
regulatory affairs of LexisNexis at
http://news.com.com/2010-1071-963798.html?tag=fd_nc_1


[manoj]"The user, once s/he has obtained a key from a notary, can use it to
sign any electronic document digitally by using the Document Signature and
User Key Management System (4). User logs onto this system to see a record
of past activities and to create new signatures. During the signature
process, user selects whether s/he would like to have the signature
notarized. In the event s/he chooses notarized digital signature, s/he must
present a digital copy of the ID, which was presented at the time to key
issuance and/or answer all the personal questions, which were recorded
during key issuance. Once this information is provided, the system produces
signed document as per the XML digital signature standard. All personal
information is kept on the server after encrypting it with the notary's
public key and not attached to the signature. Once the notary has verified
the personal information, the user can see and download a proof of
notarization. If a normal signature (non-notarized) is chosen, no additional
information is needed and the signature is produced as per the XML digital
signature standard." (p.2, first para.)

[jm]I think you have two separate functions rolled together here. The first
is the identity verification performed prior to any signature authorization
or activity. This is akin to certficate issuance by a CA,  perhaps using an
XKMS server as the trusted party. The second function is a signature
affixation or approval for each occurrence of certain classes of signature
transactions. What I don't get from the description of the credential
production process is any enhanced security from the resubmission of the
identity credential. What is to prevent a capture and replay attack by an
unauthorized third party? I don't see the digital ID as being a unique token
that cannot be reproduced. As for the knowlege-based information, why not
use it alone? For that matter, where is it better than a password? A
password can be changed by the user to prevent capture and reply but some of
the knowledge-based answers you seek cannot.

In connection with your narration, I am reminded by a statement of Phillip
Hallum-Baker of Verisign at the recent joint security committee of OASIS
that I attended on behalf of the eNotary TC. Phil stated that VeriSign was
looking to create a delegated signature solution perhaps in the form of a
signature box. That would be similar in some respects to the notarization
function you describe as to the second class of post-authentication
notarizations. I would describe such functions as eSignature powers, as in
common law power sof attorney, rather than eNotarizations, as you have done.
Different legal considerations and regulations apply to each.

[manoj]"Notary can download and print a history of all electronic
notarization activity from this system for submitting to various state
bodies."(p.2, second para.)

[jm] The statement assumes there is in the paper world a submission from
notaries to the state regarding notarized transactions. In Arizona and
California this is not the usual case. Notary records are retained by the
notary unless required to be produced by the State, which is rare.

Did you base the model on Connecticut as the diagram indicates? Does
Connecticut use the system you have described? Do you have a citation to the
Conn. notary laws you referenced?

I hope the commentary is helpful to you. Best regards.

----- Original Message -----

From: "Manoj K. Srivastava" <manoj@infomosaic.com>
To: <legalxml-enotary@lists.oasis-open.org>
Sent: Tuesday, October 22, 2002 11:17 PM
Subject: [legalxml-enotary] eNotary System


> Hello folks,
>
> Attached is the eNotary system that I had mentioned during our last
> meeting.
>
> Your comments are welcome.
>
> Best Regards,
>
> Manoj Srivastava
> Infomosaic Corporation
> 2118 Walsh Avenue, Suite 200
> Santa Clara, CA 95050
> Voice: (408) 988-4337
> Fax:   (408) 516-9427
> http://www.infomosaic.net
>