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

["Moskovitz, Ram Austryjak" <ram@verisign.com>]

Nice to see a hearty discussion has begun! Sorry for the slow responses but
I've been otherwise busy.

Inline responses ...

> From: John Messing [mailto:jmessing@law-on-line.com] 
 
> 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.
> 

Actually I think you'll find that the process is far more rigorous then most
use for SSL Server ID issuance. Browse the appropriate CP/CPSs for more
data. You have assumed that the entirety of the process is based on third
party credit databases but as I mention in the original posting we _may_ use
a credit scorer to looking phone number information if we can't get it from
a government agency (this may very well stem from my failure to effectively
communicate). Note that this is how we get the phone number to call back.
There are other activities involved as well. Since we cannot reasonably
expect CEOs to travel to our site and register their company we decided to
use multiple sources of data and multiple authentication steps in
combination.

Unfortunately you are correct that there are certificate authorities who use
little if anything beyond a credit score type lookup before they issue an
SSL server certificate. This is indeed bad for the public as it lowers
substantially the bar for fraud. Given the large number of "trusted" roots
shipped in popular operating systems and browsers one can assume that there
are different levels of authentication in use and this is in fact true.

Note however that I did not describe our vetting process. I described one
aspect of our process namely the part where we use traditional notarization
to augment our vetting process. Note also that this example describes part
of the vetting process for server certificates and not for client
certificates - and therefore the user/pass analog is not relevant.


> 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.
> 
> 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 intended to provide an example of how we use traditional notarization to
evaluate as a use case to help determine requirements for an electronic
version of the same. I have an example of a deployed digital witnessing
service based on PKI I'd be happy to walk through. From a security
perspective it is robust - a colleague and I are just finishing a technical
WP on a related design which I'll post to the list when it's ready. If there
is interest in the witnessing service (as discussed on our first conference
call) I'm happy to submit that as an example and discuss it as well.


[snipped by RAM]

> 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.
>

Actually I don't agree with the SSL point. There is no non-repudiation type
of characteristics to an SSL session. That is SSL provides no value after
the session is completed. It is strictly a secured tunnel through which to
push data through. It provides an assurance as to the PKI credentials
involved and it provides tamper proofing for the data pushed through the
tunnel, and optionally it may also provide opacity of the data to would be
snoopers.

best,
ram
BTW now on to the rest of the thread!
 
> 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>
>