Re: RE: A web of directories

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

I think we are off the track here.

The issue isn't domains of trust, or open vs. closed PKI, it is an issue of how to find 
the directory where ANY information about that DN is listed, since the connection 
between the user's name and the name of his CA, as well as that CA's directory,
may be completely non-obvious.  But I don't want to assume that the name of the 
CA and the name of the directory into which the CA publishes certificates or anything 
else is closely tied together, necessarily.

My model is that if I receive a naked DN, I would first look it up on my own personal 
cache or mini-directory, one that I may have updated with a "Hit the road option" just 
before I left for the airport.

If I don't find it there, my next choice would be to look for it in my corporate directory,
since I have a 100 megabit local LAN connection to it.

If it isn't there, but my company subscribes to a CA/repository service, I might 
well want to check there next, but that assumes a business model that I don't
necessarily want to force on people, any more than I want to compel people 
to necessarily use a directory at all if they would rather use DNS or http.

But if all else fails -- maybe I am a sole practitioner in my bedroom/office, I would like
to know where to point my browser/e-mail/code verification software to next, in order 
to find the certificate corresponding to that DN, and then to proceed to climb the 
Subject/Issuer chain without being compelled to make assumptions about the 
length of that chain or the fact that all of the certificates in the chain after the 
end-user's were necessarily issued by the same organization or are 
necessarily contained in the same directory.

And this has little or nothing to do with how to find CRLs, since we already have 
an adequate mechanism for that (if not necessarily the most elegant or generalizable).

Bob


>>> Mike Smith <mfsmith@zionsbank.com> 02/22/99 02:45PM >>>
So, isn't the burden on the CA to include what they need for folks that need to rely on the certificates that they issue?  Private CAs may issue certificates with no linkage to them because they do not wish their certs used outside the domain of trust in which they were issued.

If a CA issues certs to be used in other domains, then the issuing CA needs to ascertain that the other domains or their CA can route requests from the relying parties in those domains back to themselves.

It just seems that this discussion may be trying to solve a problem that won't exist, or, if it does exist, raises competancy (and trust) questions about the CA issuing certs that are intended to be "global" without including the CRL distribution point in the certs they issue.  The alternative for bridging non-global (private) PKIs would most likely have the CAs that would accept the foreign certificates into their domain of trust building the interface or validation process into the system for their subscribers that act as relying parties.

I think that the main problems arising in this discussion come from the perception that the relying party is the source of trust, not the CAs (theirs or the correspondent's issuer or some trusted third party that one or both CAs subscribe to).

If, in Bob's analogy, one were to set up a global directory to whihc all could go, search, retrieve certs and CRLS, it still comes down to the relying party's CA and issuing CA subscribing to or authorizing use of such third party directory for relying on their certificates, thus CRL or OCSP distribution points in their issued certs.

Quite often, the relying party would go into theor own trust domain (i.e., their issuing CA) to let the CA sort out all of the problems with bridging domains of trust transparent to themselves.

The relying party should, in my opinion, always go to THEIR trusted source to see if they are including the received cert and indemnifying them from the pitfalls of a bad or revoked cert.

This trust issue is the crux of any PKI.  If any relying party gets to choose their own trust domains and can't find the source of trust on a received cert, then maybe that is a good thing and they are not supposed to be trusting that cert outside of its own domain of trust?

Michael

>>> "Kurn, David" <david.kurn@compaq.com> 02/22/99 02:28PM >>>
Mike

Of course, if you *know* it's from the State of Utah.  But, let's consider
that I send you mail.  You have no idea who/what I am, so you look at my
signature certificate and try to deduce something from it.  Maybe if you're
a human being and bring to the table lots of context, you can guess where to
look for CRL,s or for the CA's web site, etc.  But, if you are a computer
program, it would be a lot easier if the certificate stated:

  To find the CRL and other stuff of the CA that issued me, please look in
this <URL or URI or something>.

David

-----Original Message-----
From: Mike Smith [mailto:mfsmith@zionsbank.com] 
Sent: Monday, February 22, 1999 12:48 PM
To: david.kurn@compaq.com; BJUENEMAN@novell.com; tgindin@us.ibm.com 
Cc: ietf-pkix@imc.org 
Subject: Re: A web of directories


Bob:

If you received a certificate from State of Utah for your drivers license,
fish and game or whatever, then shouldn't the CA that issued the cert
support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not
practical for any entity, whether corporate or human or animal (e.g.,
issuing a certificate of authenticity for a thoroughbred race horse with
it's DNA signed by the CA, or some such future application with biometric
filters as part of the biometric certificate authentication to activate the
information system that actually processes the "signature" of the entity
(say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more
business for our CA service).

Michael