FWD: Re: The role of the human notary (was Federate Identity (was: RE: Jon Udell: How to forge an S/MIME signature))

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

PRIA has announced that it will be posting a new version 2.0 proposed Notary DTD to its website. John Jones may be able to provide a url and some IP rules for participating to those who are interested.

I am cross-posting a thread from the ABA ISC dealing with machine-based authentications that ends with some comments about an enhanced need for human notaries. It was prompted by a weblog by Jon Udell which discussed an experiment in forging a cert to fool Aunt Tillie into believing that Bill Gates was the author, though in fact the cert was issued by Thawte to a different ficititious identity altogether. The url of the weblogb can be found at the very bottom of the cross-posting, in the first communication.

This group is currently working on notarial use cases or scenarios. I think one that is very difficult to analyze in these terms is the civil notary, who is a legal technician as much as a professional authentication agent. As such the art and craft of the civil notary does not seem to lend itself well to automation, except perhaps to generate checklists of matters to be followed in electronic format, other than the electronic tools for authentication being discussed for common law notaries.

Any different views?

---------- Original Message ----------------------------------
From:         jmessing <jmessing@LAW-ON-LINE.COM>
Reply-To:     jmessing <jmessing@LAW-ON-LINE.COM>
Date:          Fri, 26 Mar 2004 00:02:50 -0500

This is precisely one reason why the eTrust subcommittee of the Science and Technology Section has taken the view as a committee that in-person notarizations may well become more of a necessity in the electronic world than they have been in the paper world, at least in the 21st century.

The Federal appellate case of In Re Pirhana is a good example. The opinion was circulated to this eList by Jon Stanley a few months ago.
The opinion basically allowed a corporate director to withdraw an electronic signature on the grounds that he did not intend to sign the electronic document, even thought it was electronically signed and sent at his request through attorneys. The legal effect of the document, a resignation letter, was important in a fight over corporate control of the fate of the company.

The court of appeals had the good sense to depublish the opinion. The judges seemed to sense that they did not know what really was before them, and they were fumbling.

The opinion is murky on the communications that were issued by the director to the attorneys and the procedures for verifying his identity and contemporaneous intent to sign, which could have been easily remedied by an in-person notarization, traditionally conducted except for the fact that the documents were electronic.

The notary, or authentication professional, as the new role is becoming defined, can testify as direct evidence of what was said and how it was reasonably interpreted in ways that juries and judges can intuitively grasp without having to learn about the intricacies of new technologies. The notaries are subject to traditional tools of cross-examination. Credibility determinations do not require expensive witnesses with doctoral degrees. Juries make them all the time.

The eTrust subcommittee recognizes that there will be a probable expansion, not contraction, in the role of the notary or successor professional for electronic signing involving significant financial or governmental interests.

A court trial over whether the notary is lying is a lot cheaper to conduct than one involving armies of experts arguing about whether a technology worked as it was supposed to and would achieved the desired result even if it did.

New forms of notarized transactions, perhaps involving real-time financial information, may be in the offing as well.

Machines can't testify. Only people can testify. Either about what people did and said, or alternatively, about whether machines operated as they should and whether that was good enough anyway.

For further information, please feel free to contact me off-list.

John Messing
Law-on-Line, Inc.
3900 E. Broadway Blvd., Suite 201
Tucson, AZ 85711
(520) 270-1953

---------- Original Message ----------------------------------
From:         "Steven W. Teppler" <steppler@TIMECERTAIN.COM>
Reply-To:     "Steven W. Teppler" <steppler@TIMECERTAIN.COM>
Date:          Thu, 25 Mar 2004 23:22:05 -0500

>Someone, somewhere, will be in charge of "manually" correcting ID hijacks
>for the victimized (as in, we will give you back your name and
>credentials -- a little cert generation here, a little delete key action
>there, and voila!).  It will be someone we won't know, who has little or no
>accountability or visibility, who will not be transparent to the
>"credentialing" process or chain, and who will probably be a political
>appointee.  That person will be very busy.
>
>Make very sure you become friends with this person.  Never offend him or
>her.  Give gifts, and do so frequently.  Josef K. didn't, and look what
>happened to him.
>
>S
>
>"If the probability be called P; the injury, L; and the burden, B; liability
>depends upon whether B is less than L multiplied by P: i.e., whether B is
>less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
>
>
>
>-----Original Message-----
>From: Information Security Committee [mailto:ST-ISC@MAIL.ABANET.ORG]On
>Behalf Of Russ Savage
>Sent: Thursday, March 25, 2004 8:55 PM
>To: ST-ISC@MAIL.ABANET.ORG
>Subject: Re: Federate Identity (was: RE: Jon Udell: How to forge an
>S/MIME signature)
>
>
>all,
>a common assurance standard is that the electronic practice be of equal
>reliability as the equivalent paper (meatspace) practice.
>so consider Bob's comments in that context - not just credentialing
>electronic identity but 'meatspace' identity (e.g. notarization).
>
>On Mar 25, 2004, at 6:44 PM, Robert Jueneman wrote:
>
>> Ben,
>>
>> In the particular case of the Federated Identity program, it isn't the
>> government that is operating the PKI, it is the individual "credential"
>> provider.  And for certain classes of "low-risk" transactions, no
>> certificate is required at all -- user name and password, or mother's
>> maiden
>> name, or even knowledge of an SSN might suffice.
>>
>> As you say, HOPEFULLY the government would consider the privacy
>> interests of
>> the citizenry when evaluating the kinds of systems they will accept for
>> access to certain kinds of information.  And Yes, hopefully, all of the
>> various branches of the government will get their computer security
>> grades
>> up to at least a D-minus sometime in the foreseeable future.  Color me
>> skeptical. The government is relatively good at writing regulations
>> that
>> apply to other people (e.g., HIPAA), but absolutely lousy at putting
>> them
>> into practice themselves.  But I would still like some kind of a veto
>> power
>> over who gets to have access to MY information, even (especially) if
>> they
>> are pretending to be me.
>>
>> But I think there is another, perhaps deeper issue here.
>>
>> In order to be certain that the certificate isn't being issued in the
>> name
>> of someone who is now a victim of identity theft, I would claim that
>> even
>> face-to-face issuance is not sufficient, because the issuer wouldn't
>> issue
>> the cert if he thought something was amiss.
>>
>> Instead, the notice has to go back out-of-band to the address of the
>> "real"
>> user.  And how can that be done?  Clearly, you can't rely on the
>> subscriber
>> himself telling you what his address is, so some other form of
>> meat-space
>> verification must be used -- utility bills, credit card addresses, etc.
>> And the notice has to be sent with some form of restricted delivery,
>> because
>> a common scam is for someone to send in a change of address form to
>> the post
>> office, thereby allowing them to intercept any such notices.
>>
>> E-mail notice MIGHT be acceptable, but only if that e-mail address is
>> part
>> of the subscriber's persona, AND if the various e-mail systems, etc.,
>> properly display and confirm that the address in the certificate
>> matches the
>> entire From address, and not just a part of it.
>>
>> Naturally, I know that I'm preaching to the choir, but social
>> engineering
>> didn't go away when Messers Rivest, Shamir, and Adleman cooked up their
>> nifty algorithm.
>>
>> But it's disappointing when people don't consider the system
>> implications of
>> some of their designs.
>>
>> Bob
>>
>> -----Original Message-----
>> From: Benjamin Wilson [mailto:benwilsonusa@yahoo.com]
>> Sent: Thursday, March 25, 2004 2:47 AM
>> To: Robert Jueneman; ST-ISC@MAIL.ABANET.ORG
>> Subject: Re: Federate Identity (was: RE: Jon Udell: How to forge an
>> S/MIME
>> signature)
>>
>> Bob,
>> As to your point concerning the rule that putative
>> subscribers be given notice and give positive assent
>> to the issuance of a certificate--the degree of notice
>> and assent once again becomes a matter of risk
>> analysis.  Hopefully the party implementing PKI (e.g.,
>> the government) would analyze the potential harm to
>> the citizen by looking at the kinds of information for
>> which access will be granted and/or the systems that
>> will be accessed.  Whatever process is used, however,
>> will likely contain the two requirements (at least
>> most systems I've seen)--notice is usually given by an
>> e-mail back to the user at the e-mail they provide (in
>> higher risk systems, more notice can be required,
>> including in-person identification, the personal
>> appearance of the individual before a notary, etc.),
>> then by clicking on the link (in low risk systems) or
>> again by personal appearance (in higher risk systems)
>> evidence of "user" assent can be collected. Again,
>> it's a matter of degree as you state, but to create
>> (or let alone expect compliance with) a rule that is
>> both specific and universal as to what notice and
>> assent means is nearly impossible.  So I doubt the DSG
>> or any similar standard can answer the question.
>> (Hopefully the PAG provides guidance. :^))
>>
>>
>> --- Robert Jueneman <bob@JUENEMAN.COM> wrote:
>>> This seems like to right time to reiterate the point
>>> I made at the recent
>>> ISC meeting, for those who weren't in attendance.
>>>
>>> The Federal government seems to have momentarily
>>> given up on establishing
>>> their own universal PKI, and instead seems to have
>>> fervently embraced the
>>> concept of a "Federated Identity".
>>>
>>> What this concept means, bottom line, is that the
>>> government will accept
>>> various kinds of credentials, mostly PKI (hopefully)
>>> but perhaps some other,
>>> weaker types like user name and password, for
>>> authenticating an individual
>>> who wishes to do business (of some unspecified kind)
>>> with the government.
>>>
>>> These credentials might emanate from a number of
>>> different sources, ranging
>>> from well-respected (?) trusted third party CAs, to
>>> banks and similar
>>> institutions, and perhaps even corporations or
>>> private companies.
>>>
>>> Presumably, the government will do some kind of a
>>> risk analysis to determine
>>> to their satisfaction that the type of credentials
>>> being issued meets the
>>> standard of risk/reward TO THE GOVERNMENT.
>>>
>>> Banks do a somewhat similar risk analysis under
>>> Gramm-Leech-Bliley to
>>> determine whether the risk TO THEM of their security
>>> practices is such that
>>> they are comfortable, i.e., can absorb whatever risk
>>> that entails.
>>>
>>> But where does that leave the poor citizen/consumer,
>>> who says "That may be
>>> all and good for the government, but what about the
>>> risk to ME?"  The
>>> Government may not be harmed significantly if
>>> someone can snoop around my
>>> Social Security data, my health benefits, my
>>> security clearance data,
>>> student loan data, etc., etc., but I might damned
>>> well be so harmed, at
>>> least from my perspective.  So what voice to I have
>>> in deciding whether some
>>> certificate is good enough?  If it is a certificate
>>> issued to an imposter,
>>> probably none at all.  And there's the rub.
>>>
>>> The point of the post from Jon Udell was that
>>> Thawte's poor practices
>>> allowed someone else to get a certificate in his
>>> name without detection.
>>> But although the government might well consider that
>>> an acceptable risk from
>>> their cost/benefit analysis, poor Jon undoubtedly
>>> wouldn't, yet with
>>> Thawte's current practices, he might never know that
>>> this scam had been
>>> carried out unless or until he tried to get a
>>> certificate with that SSN and
>>> found he couldn't.  (I can't either, because of a
>>> mistake I made somewhere
>>> along the line -- I'm now blocked.  Perhaps it's
>>> just as well!)
>>>
>>> Early on, in the Digital Signature Guidelines, we
>>> included a rule to the
>>> effect that the putative subscriber had to be given
>>> notice and give his
>>> positive assent to the issuance of a certificate.
>>> Unfortunately, that rule
>>> has been widely ignored, to the industry's
>>> detriment.
>>>
>>> I think it is high time we reinforced that rule,
>>> with close to iron-clad
>>> evidence, before PKI and identity theft become
>>> inextricably linked in the
>>> public's mind.  And of course, that applies equally
>>> well to the Government's
>>> (or anyone else's) use of this dangerous "federated
>>> identity" notion, whose
>>> time I fervently hope has NOT come, at least until
>>> these problems are
>>> address and resolved.
>>>
>>> Unfortunately, given all of the hype around such
>>> constructs as XACML, I
>>> don't have a lot of confidence that anyone will care
>>> until it is too late.
>>>
>>> Bob
>>>
>>> Robert R. Jueneman
>>> Chief Security Architect
>>> SPYRUS, Inc.
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Information Security Committee
>>> [mailto:ST-ISC@MAIL.ABANET.ORG] On
>>> Behalf Of Steven W. Teppler
>>> Sent: Tuesday, March 23, 2004 7:39 PM
>>> To: ST-ISC@MAIL.ABANET.ORG
>>> Subject: Re: Jon Udell: How to forge an S/MIME
>>> signature
>>>
>>> This is not quite forged as I understand the term,
>>> at least in the sense of
>>> "forging" a digital signature.  In the examples
>>> given, the ID and the
>>> ultimate source are set up to be what they are.
>>> And, in the final analysis,
>>> they are different -- even if Aunt Minnie doesn't
>>> check it out.
>>>
>>> A more difficult example of spoofing occurs where
>>> there has been a
>>> catastrophic CA compromise resulting in a successful
>>> identity shift (or
>>> hijack) and a valid seeming digital signature
>>> (authentic in all respects
>>> except that it wasn't created by the identity to
>>> which it was associated by
>>> the CA).  The difference is not verifiable by any
>>> electronic means...that is
>>> until the compromise is detected, or the fraud is...
>>>
>>> Steven
>>>
>>> "If the probability be called P; the injury, L; and
>>> the burden, B; liability
>>> depends upon whether B is less than L multiplied by
>>> P: i.e., whether B is
>>> less than PL." United States v. Carroll Towing (159
>>> F.2d 169 [2d Cir. 1947]
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Information Security Committee
>>> [mailto:ST-ISC@MAIL.ABANET.ORG]On
>>> Behalf Of todd glassey
>>> Sent: Tuesday, March 23, 2004 9:46 PM
>>> To: ST-ISC@MAIL.ABANET.ORG
>>> Subject: Re: Jon Udell: How to forge an S/MIME
>>> signature
>>>
>>>
>>> Excellent post Russ, this is germane to the issue we
>>> have been pounding
>>> around today on authenticating end-user identities
>>> and whether paper is any
>>> better than PKI or the reverse..
>>>
>>> Good reading!
>>>
>>> Todd
>>>
>>> ----- Original Message -----
>>> From: "Russ Savage" <russasis@MAC.COM>
>>> To: <ST-ISC@MAIL.ABANET.ORG>
>>> Sent: Tuesday, March 23, 2004 6:22 PM
>>> Subject: Jon Udell: How to forge an S/MIME signature
>>>
>>>
>>>>
>>>
>> http://weblog.infoworld.com/udell/2004/03/23.html#a952
>>>>
>>>> To unsubscribe send the following in the body of a
>>> message to
>>>> listserv@abanet.org  - unsubscribe st-isc
>>>
>>> To unsubscribe send the following in the body of a
>>> message to
>>> listserv@abanet.org  - unsubscribe st-isc
>>>
>>> To unsubscribe send the following in the body of a
>>> message to
>>> listserv@abanet.org  - unsubscribe st-isc
>>>
>>> To unsubscribe send the following in the body of a
>>> message to
>>> listserv@abanet.org  - unsubscribe st-isc
>>
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Finance Tax Center - File online. File on time.
>> http://taxes.yahoo.com/filing.html
>>
>> To unsubscribe send the following in the body of a message to
>> listserv@abanet.org  - unsubscribe st-isc
>>
>
>To unsubscribe send the following in the body of a message to
>listserv@abanet.org  - unsubscribe st-isc
>
>To unsubscribe send the following in the body of a message to
>listserv@abanet.org  - unsubscribe st-isc
>

To unsubscribe send the following in the body of a message to
listserv@abanet.org  - unsubscribe st-isc