Re: Missing Protocol ?

[Thierry Van Doninck <Thierry.VanDoninck@xxxxxxxx>]

Roger,

Yes,

But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
Therefor a relying party might not know wether the certified party can be allowed to perform a certain 
action. A certificate received by a RP might not contain sufficient information to authenticate 
the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)

I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ), 
but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)

Thierry Van Doninck
eMail : Thierry.vandoninck@dexia.be






ryounglove%lucent.com@Internet
14/04/2000 21:14
To:	egerck%nma.com@Internet
cc:	ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)

Subject:	Re: Missing Protocol ?

I agree with both Dave and Ed, however I do not believe that a new WG is 
needed. The individual identity (carbon or silicon life form) that is 
certified with a digital certificate is the responsibility of the PKI which 
is issuing the cert. The Certificate Policy written by that PKI operator 
supplies the requirements for identification authentication. The CA CPS 
states how the CP requirements are met. It is the Relying Parties 
responsibility to properly evaluate the validity of a certificate that they 
receive. When both the CP OID and the CPS OID is included in the cert it 
becomes easy to evaluate the validity.
At 01:41 PM 4/14/2000 , you wrote:
>Dave:
>
>Yes and to your final paragraph.  A new WG would be needed -- otherwise
>this WG would need to backtrack so much that nothing would be left ;-)
>OTOH, with a new WG then what this WG has done might be a *component*
>in a bigger frame, and a useful one.
>
>Cheers,
>
>Ed Gerck
>
>"David P. Kemp" wrote:
>
> > > From: Denis Pinkas <Denis.Pinkas@bull.net>
> > > > From: Ed Gerck
> > > > Here, in PKIX, the main purpose of a CA is also to bind a public 
> key to the name
> > > > contained in the certificate and thus assure third parties that 
> some measure of care
> > > > was taken to ensure that this binding is valid for both -- i.e., 
> name and key. However,
> > > > the issue whether a user's DN actually corresponds to identity 
> credentials that are
> > > > *globally* linked to a person, or to a local alias or, simply to an 
> e-mail address -- and
> > > > how such association was verified --   is  outside the scope of 
> PKIX and depends
> > > > on each CA's CPS.
> > >
> > > I am not sure that this is really outside the scope of PKIX. If some
> > > judge would like to make the difference between John Smith 22 and
> > > John Smith 23, what can he do ? Nothing that has been standardized
> > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > should ? What kind of solution ? Being able to get back (when
> > > appropriate) the registration information (sometimes called the
> > > credentials) that has been registered at the time of registration by
> > > the RA. I do not think that it may be practical to get that
> > > information by paper and in a different format for every CA in the
> > > world. A protocol (and a schema) might be useful.
> > >
> > > Denis
> >
> > Denis,
> >
> > As long as CPSs are different, the "big identity in the sky" (the
> > information about a subject which makes John Smith 22 different from
> > John Smith 23) will be different, and outside the scope of PKIX.  If
> > the judge has access to a certain body of information:  employment and
> > credit history, property ownership and tax records, utility bills, etc,
> > and the CA has used any of that information to establish identity, then
> > the certificate may be useful to the judge.  If the CA uses only email
> > address to establish "identity", the certificate will be useless to a
> > judge dealing in non-electronic matters.  I don't see how PKIX could
> > consider in-scope an effort to develop a schema for the universe
> > of information which could constitute a human identity.
> >
> > Dave

---
TTFN
Roger W. Younglove, CISSP
Sr. Network Security Consultant
NetworkCare® Security Services
100 Galleria Officentre, Ste. 200
Southfield, MI 48034
Numeric page: 888.935.6755
E-mail page:
page_roger_younglove@ins.com
eFax number: 413.425.5368
www.lucent.com/netcare