Re: Missing Protocol ?

[tgindin@xxxxxxxxxx]

     Some comments.  I think we can get a lot of this into certificates or
CMP responses, if we don't try for a "universal solution".  If liability is
at issue, even one of the ID's should do the trick.  The only problem I see
is a privacy problem.  If something shouldn't be in a certificate, which
RP's should be allowed to get it?  If ordinary unprivileged RP's are
allowed to get it, why (other than certificate lifetime considerations)
shouldn't it be in the certificate?

          Tom Gindin

Al Arsenault <awa1@home.com> on 04/17/2000 11:19:08 AM

To:   Denis Pinkas <Denis.Pinkas@bull.net>
cc:   ietf-pkix <ietf-pkix@imc.org>
Subject:  Re: Missing Protocol ?



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

[Tom Gindin] Most of your list, up to (not including) physically
descriptive information, has perfectly well-defined formats in our domain
already - and IMO we should start with those.  The ones I have been trying
to profile for an OTHER-NAME format to go into certificates are Employee ID
number, SSN or other nationwide government ID number, CA-assigned ID
number, and Passport, Driver's license, or other government agency ID
number.  Maybe we should include phone number (distinguished between work
and home) as long as there's a separate place for extension number at work.
How would we do mail stop/address - perhaps with an X.400 Physical Delivery
Address?  Of course, most people have different work and home mail
addresses too.

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

[Tom Gindin] Yes, we need to keep the list down.  However, I don't think
that means empty.  For the four ID types, I have only three syntaxes and
two of them are effectively subsets of the other.

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