[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Missing Protocol ?
- To: Denis Pinkas <Denis.Pinkas@xxxxxxxx>
- Subject: Re: Missing Protocol ?
- From: Al Arsenault <awa1@xxxxxxxx>
- Date: Mon, 17 Apr 2000 11:19:08 -0400
- Cc: ietf-pkix <ietf-pkix@xxxxxxx>
- Organization: @Home Network
- References: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> <> <>
Now that I understand better what you're getting at with this stuff :-)
Denis Pinkas wrote:
>
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
>
> > Thierry,
> >
> > I'm not sure that there is a solution for this problem that doesn't
> > involve knowledge external to the PKI.
>
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
>
> > 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.)
>
> 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
>
>
>
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
Ellicott City, MD 21042-0530
(410) 480-2052