RE: [legalxml-enotary] Example - Authenticating Request For Servi ce

[Pieter Kasselman <pkasselman@baltimore.com>]

John, a few comments and thoughts in-line:

> -----Original Message-----
> From:	John Messing [SMTP:jmessing@law-on-line.com]
> Sent:	20 October 2002 15:16
> To:	legalxml-enotary@lists.oasis-open.org
> Subject:	Re: [legalxml-enotary] Example - Authenticating Request For
> Service
> 
> This soundslike a pretty standard enrollment procedure, which often is
> encountered in the process of getting an SSL server certificate for a
> business enterprise. In the law we might refer to such information as
> circumstantial evidence. That is useful to invoke when there is a paucity
> of
> information at one's disposal, as in the investigation of a crime. It is
> somewhat disappointing as a selection in a field of almost unlimited
> choices
> when identity is first established for key mapping purposes.
> 
> For one who is the least bit determined, a Dunn and Bradstreet rating and
> Equifax account are not that hard to get. Having a trumped up business
> name
> and phone number, with an associate on the line, is all that is needed to
> fool the enrollment process. The CA who relies on that identification has
> little to offer a bank that is looking for substantial electronic online
> residential mortgage lending capabilities.
> 
> Therefore, such an identification would not be suitable for online
> transactions of any kind where the due diligence of the relying party
> involved required more than the identification process which you have
> described.
> 
	[Pieter Kasselman]  I am for the moment assuming that the
certification event is taken as the notarization event as well. I think that
not all e-noatries will be trusted to the same extent or for the same thing.
The above process may be perfectly accesptable for a certain risk profile,
while it may be inadequate for another. It comes down to risk management,
which is in turn governed by policy. The "quality" of different e-notaries
may differ as its processes and procedures differ (in the PKI world, policy
is seperated from the technology through the use of explicit certificate
practice statements and certification policies). This allows for the
seperation of the technology and the process, where the quality or level of
assurance is primarily determined by the process/policy. I think we should
try to do the same in this TC (i.e. seperate policy from technology).

> This having been said, for ordinary commercial purposes of repetitive low
> value transactions, where perhaps a username and password had been
> previously employed for authorization access to an Internet web service of
> an e-commerce site, the enrollment process is perfectably acceptable.
> 
	[Pieter Kasselman]  Yes, this comes back to risk management and
policy.

> Therefore, it could be said that the process performs an eNotary function
> for a defined category of online transactions where the per transaction
> value does not exceed, for sake of argument $100, where eNotary is a short
> hand expression for what should be adjudged by the courts to be
> self-authenticating evidence under the Federal Rules of Evidence, E.R. 901
> et seq. and equivalent state law in the United States. That section of the
> federal evidence code has been referred to consistently in the cases
> previously provided to the TC dealing with authentication and
> admissibility
> of electronic evidence in federal courtroom trials.
> 
> I propose that we take on the task of creating a formula for bringing
> forward the application of such a dollar standard (of any hypothetical
> value) during predictable economic flunctuations so that equivalent
> relative
> values between the value of the transaction in relation to the other
> values
> of the society could be maintained indefinitely into the future. That
> requires identifying the policies and business rules being served,
> articulating how they translate to a dollar amount, and where they should
> be
> placed in a hierarchy that balances ranges of services against risks of
> liability across an entire field of information services.
> 
	[Pieter Kasselman]  I think as a TC we can provide the syntax and
technical means to to express such information (e.g. as part of a
notirasation policy), but I am not convinced that we should attempt to
specify an economic model as described above, it may open us to all sorts of
liabilities. I would rather provide the mechanism for expressing such a
model inside a policy and leave the model to the operator of the e-Notary
service.

> Where the work will make an important contribution practically is in
> consideration of the cases which fall squarely within the standard.
> Proving
> the content of the transaction will be facilitated and perhaps even
> declared
> to be definitive in the absence of any known contrary information, and all
> capable of being performed from beginning to end through totally automated
> means. That will create a base level of legal certainty which will help to
> promote robust computerized activity in each eNotarized sector.
> 
> Although this might displace paper notaries for such transactions, there
> are
> wonderful opportunities for the higher value paper and electronic
> transactions as in international real estate transactions, and
> enterprising
> individuals can improve their lot consistently with the eNotary process,
> with some advanced training.
> 
> This ties in well with the offer of Dr. Leff to investigate how eNotary
> could apply to ebXML (to be described in the draft minutes, which will be
> forthcoming). Once we havesuccessfully tackled the described enrollment
> process, we can  begin to expand with a consideration of what else in
> addition to SSL ebXML brings to the infrastructure, and what its eNotary
> needs may be, given where it ties into the emerging WSS security hiearchy.
> I
> think we should ask Dr. Leff if he would be willing take on the added job
> of
> eNotary liasion to ebXML in addition to doing that job for the Court
> Filing
> TC of LegalXML Oasis.
> 
> Please be alert to the absence in the discussion so far of data integrity
> determinations, which bring their own eNotary considerations. I think most
> of us can agree that the standard public key exchange principles for the
> generation and transmission of a shared symmetric session key used by SSL
> probably meet any conceivable eNotary standard, but I think we should
> articulate in concrete policy language why we feel that way.
> 
	[Pieter Kasselman] I agree that certain public key technologies has
many properties that will benefit an e-Notary (especially public key schemes
that are used to generate digital signatures).However I am not sure what key
establishment in the SSL sense would contribute, for instance DH key
establishement may not be that usefull to an e-Notary.

> I would appreciate comment on these propositions.
> 
> ----- Original Message -----
> From: "Moskovitz, Ram Austryjak" <ram@verisign.com>
> To: <legalxml-enotary@lists.oasis-open.org>
> Sent: Friday, October 18, 2002 10:47 AM
> Subject: [legalxml-enotary] Example - Authenticating Request For Service
> 
> 
> > Hiya,
> >
> > Here's my first contribution of an example - a real world example from
> our
> > Public CA operations team.
> >
> > When we are processing certificate requests we jump through a number of
> > hoops to ensure that the request is legitimate (requestor is authorized
> by
> > the company, company exists, right to use name, right to use domain
> name...
> > - the details vary by class, product line, and
> political/social/geographical
> > constraints etc).
> >
> > We may use a third party (credit scorer, government agency) to lookup a
> > corporate phone number in order to call back into the organization and
> > ensure that the alleged employee who made the certificate request is in
> > actual fact an employee of the named organization and/or is authorized
> to
> > act on their behalf. If we are unable to get a third party reference to
> the
> > phone # then we require the customer provide a notarized letter
> confirming
> > the organization has in fact enrolled for a n ID as well as validating
> the
> > name and email address of the technical contact.
> >
> > ram
> >
> > -----
> > Ram Austryjak Moskovitz
> > Director
> > VeriSign Research
> > VeriSign, Inc.
> > Ram@VeriSign.Com
> > +1(650)426-3485
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com