Subject: Re: Missing Protocol ?

From: Thierry Van Doninck <[email-masked]>
Date: 17 Apr 2000 09:13:05 +0200

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 : [email-masked]

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 <[email-masked]>
> > > > 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:
[email-masked]
eFax number: 413.425.5368
www.lucent.com/netcare

---

From: Al Arsenault <[email-masked]>
Date: Mon, 17 Apr 2000 09:26:52 -0400

Thierry,

	I'm not sure that there is a solution for this problem that doesn't
involve knowledge external to the PKI. 

	Suppose that the fondest dreams of the early X.500 designers had come
true, and every item (to include person) in the known universe had a
globally unique name.  Even in that case, if you are working with one
"Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
to distinguish them, then YOUR "Jim Jones of GM" has to tell you
out-of-band what his globally-unique name is, or at least enough
disambiguating information to let you accurately pick it out from the
entries in the global directory.  Otherwise, you'll never know which is
which.

	The same type of information can be passed to you "out-of-band" in the
current situation; when you first begin working with the right "Jim
Jones of GM", he can provide you his certificate directly, or give you
enough disambiguating information to make sure you find it somewhere
else.  If he doesn't, you're not going to work securely.  

	(All of this is a long way of saying that we're really wandering here. 
I'm not convinced that it is possible to define a technical - by which I
mean "machine-processable" - protocol that is guaranteed to find you the
right certificate if you don't have enough information from other
contexts.)

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
(410) 480-2052

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Apr 2000 17:01:28 +0200

Since I launched this thread, I am following the various exchanges.
I pick this one to comment.

> involve knowledge external to the PKI.

Since the knowledge is not external to PKI, the problem may be
considered by the PKIX WG. 

> right certificate if you don't have enough information from other

When dealing with signatures, it is the other way around. You have a
certificate, that may even contain a pseudonym. When it does not
contain a pseudonym, the question is still: who indeed is that
person (e.g. Jim Jones 22) ? This person may be liable for a
contract worth 10.000 $ and the requester would like to get the home
address of the signer.

The information that was obtained at the time of registration (and
that is NOT contained in the certificate) may help.

The problem is that this registration information varies from one CA
to another and we are not going to standardize it easily. Is it
really a problem ? 

We could standardize the request and very loosely standardize the
response. The request is easy to standardize: "I want more
registration information on the certificate holder that has the
following serial number". Depending both, on who the requester is
and the certificate policy of the CA, more or less (even none)
information will be released to the requester. We could thus
standardize the response without mandating any component to be
returned. In any case, it would be better than paper.

Thoughts ?

Denis

---

From: Al Arsenault <[email-masked]>
Date: Mon, 17 Apr 2000 11:19:08 -0400

Now that I understand better what you're getting at with this stuff  :-)

> returned. In any case, it would be better than paper.

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

	- passport number/nationality
	- employee ID number
	- mail stop/address
	- phone number
	- driver's license number
	- SSN/other identity number
	- physically descriptive information (no, I'm not kidding here.  I used
to have a roommate named Tom Smith.  He worked in an office with another
Tom Smith.  The middle names and even the generational qualifier were
the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you
wanted. The guy with the beard was threatened with mayhem if he ever
shaved while working in that office.:-)
	- a whole bunch of other stuff

If this is going to be meaningful to software and hardware, we'll have
to quantify/limit the list of acceptable information somehow.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or
an extension to CMP/CMC?

Thanks,

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Apr 2000 17:57:14 +0200

>         - physically descriptive information (no, I'm not kidding here.  

I am not sure that you *directly* ask for this. This is what you may
*receive*. The request would use some category of information. It
would be up to the RA/CA to return whatever information matches with
these categories.

> I used

The request may be sent by a computer, e.g. acting on behalf of a
person. The response might need to be read by a human being to be
understable.

> human consumption/decision?

The later.

> 3.  If we can get past 1., do you picture this being a new protocol, or

I have no preference at all, ... as long as we have that protocol.

Regards,

Denis

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 17 Apr 2000 12:43:01 -0400

>returned. In any case, it would be better than paper.

Sure, Denis.  Particularly since I've currently got my mind warpped around CMP.

This fits well within perceived uses of the genm and genp of CMP.  If it is 
a request from Jon Q, the CA can decide what to respond.  If genm contains 
a warrant, well then...

We have the basics here to build up requests for archived data.

I have been talking to some US university people that want anonymous certs 
for their library system.  A student might use their student cert for such 
a library cert.  A resident might use their DMV cert to get one.

But what if a proper authority needed to know who is cert holder 
3458923?  If the requester was the librarian, the response might be:  "A 
resident (non-student) of the State".  If it was a  law-type with a warrant 
it might be "Student ID-3456"; then let them deal with the school admin to 
learn more....

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]