Re: Missing Protocol ?

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Bob,

I appreciate you sense of humour, at the very end of this E-mail,
when you say: "But afer all, isn't what DIRECTORIES are for? Why do
we need a new protocol??? The answer is LDAP.  What was the
question??

Before discussing the technical solution(s), the thread is
discussing very validly the purpose and the goal of that (missing ?)
protocol. Since the information that might be released will not
match exactly with the arguments from the request (i.e. you cannot
ask specically for an attribute) I am not convinced that LDAP would
be the best choice. In addition, up to now, RAs do not need to
support a Directory or structure the information they have so that
it can be placed in a Directory.

The other arguments you raise in your E-mail, as well as the
examples provided by Robert Moskowitz, illustrate the topic very
well.

Peter Sylvester while advocating for the use of DVCS was saying: "
Since my current favorite is dvcs, I start with this: The request
would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain
all kinds of certificates, etc, just ONE of the certEtcToken
elements would be the signedData object created by the RA ".

The request we need has nothing to do with 'verify public key
certificate'. DVCS is already embrassing too many purposes. It would
not be a good idea to add one more purpose in the same shell.

Note that the request is mainly intended to be used by adjudicators
or plaintiffs, but nothing prevents anyone to send a request.
However, a server may well refuse to provide a response. So any RP
could make a request. It will always be up to the RA to decide
which, if any, information will be released.

Let us now add a refinment about the construct of the request.
Information may be released (or not) depending upon not only who the
requestor is, but also depending upon what kind of information is
provided. For example, if I can prove that a document was both
signed by myself and another party, I could perhaps legitimately ask
more information about that other party. Providing this "proof" as
part of the (authenticated) request might be valuable. Note that
this can be done without providing the actual content of what was
signed, thus respecting some privacy.
 
Regards,

Denis

 
> Tom,
> 
> You're right, the potential sticking point is the privacy issue.
> 
> But privacy comes in several flavors, and there is also some
> concern for cluttering up certificate with information that may
> not always be required.
> 
> I don't think we need to come to the complexity of a German wine
> label (auslese cabinette, green capsule, with silver stripes) to solve this.
> 
> Consider the telephone company's policy.  My number can be listed,
> unpublished, or unlisted.  If it is listed, I may or may not list an address,
> and if I do it doesn't have to be my real address -- it could be a forwarding
> service, or just a ZIP code.  (In the LA area, it costs extra to have your
> phone be unlisted, but it costs nothing to have a phony  address. So
> hundreds of people just list their names as Joe Doakes, 90210.
> 
> If my listing it is merely unpublished, you can ask for it.
> 
> If it is unlisted, only law enforcement, and maybe other emergency
> services can get it, but I don't know if it requires a warrant in that case.
> 
> Same with the Tom Smith-with-the-beard.  Tom may not choose to list his
> hirsuteness or glabrousness, but he probably would have no problem with
> telling anyone who asks.
> 
> His social security number might be a different story, but even then
> he is unlikely to defend that to the death, as too many people already
> have access to it. But he might require that such usage be audited, and
> that he have the right to know who asked for it, just as credit checks
> must be reported upon request.
> 
> If he is under the Witness Protection program, he is going to strenuously
> resist giving anyone his real name, birth date, etc.
> 
> But afer all, isn't what DIRECTORIES are for?
> 
> Why do we need a new protocol???
> 
> The answer is LDAP.  What was the question??
> 
> Bob
> 
> >>> <tgindin@us.ibm.com> 04/17/00 10:25AM >>>
>      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