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

[Pieter Kasselman <pkasselman@baltimore.com>]

Hi John, comments in-line

> -----Original Message-----
> From:	John Messing [SMTP:jmessing@law-on-line.com]
> Sent:	21 October 2002 15:55
> To:	Pieter Kasselman; legalxml-enotary@lists.oasis-open.org
> Subject:	Re: [legalxml-enotary] Example - Authenticating Request For
> Service
> 
> [Pieter Kasselman]
> > Now, at (what I call) the technical level, certificates that conform
> > to X.509 tend to interop without a problem, regardless of CPS/PS. At the
> > CPS/PS level it is invariably a business decision as to whether
> certificates
> > are accepted. Two organisations may have completely different views on
> this.
> > Organisation A will be happy to accept certificates issued under
> different
> > CPS/PS, while Organisation B may refuse to do so. This often has more to
> do
> > with business practices and philosophy than technical standards or even
> > security. I would be surprised if it is different in the e-Notary case.
> 
> [John Messing] But on the other hand, where cross-certification is
> involved,
> certificates may not interoperate, according to my understanding and
> experience, where the CP/CPS' upon which they are based, differ, even with
> the same hardware and software configurations. I thought that was the
> lesson
> of the Federal Bridge Authority. Am I mistaken?
> 
	[Pieter Kasselman]  I am not familiar with the Federal Bridge
Authority case, but I can guess at what happened. Cross certification is
complicated. 

	Back to interop, there are two kinds of interop up for discussion
here. The first answers the question "Is this an X.509 certificate". The
second is "does my certificate processing application accept an (arbitrary)
X.509 certificate". 

	In the first case, the CPS/CP may cause specific attributes and
fields to be set to specific values in a certificate. If this is an X.509
certificate, a standard X.509 parser should have no problem reading the
certificate, regardless of what was set where (the bits are where they
should be). 

	The problem arise when trying to answer the second question. At this
point you are dealing with a standard X.509 certificate that is fully
compliant with the standard. However this certificate has been profiled
through application of the CPS/CP. The processing application now has
certain expectations. For instance, the processing application may have been
implemented to accept certificates that was only issued by a certain CA,
regardless of cross certification. Or it may have been implemented without
any knowledge of a critical (proprietary) extension (the beauty of X.509 is
that you can include proprietary extensions that is known only to your
CPS/CP). Given an arbitrary certificate the certificate processing
application will detect a such extensions or attributes and abort (note it
has succeeded as far it is concerned, it detected a certificate that was
inconsistent with its understanding of the CPS/CP and refused further
action).

	As (a non-perfect) analogy think of a guard being told to only allow
cars into an estate that are of certain make or model, if I show up in a car
that does not fit the profile, I should be denied access (this is not a
perfect analogy btw).

	As for e-Notary, we seem not to be concerned with question one (i.e.
we are not trying to define what a notarised document should look like). Is
that correct? Are we looking to come up with a single equivalent of CPS/CP
for e-Notaries?

> [Pieter Kasselman]
> 
> > So you are proposing that this TC defines the requirements by
> > which any e-notary process is judged, rather than specifying what an
> > e-notarized document looks like or how that document is generated and
> > processed (processed in the machine sense as opposed to the processes
> > surrounding the practices of the e-notary)?
> >
>  [John Messing]
> 
> I believe that is correct, where an e-Notary process may involve totally
> machine processes as well as mixed human and machine processes.
> 
> 


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