Re: RE: A web of directories

[Mike Smith <mfsmith@xxxxxxxxxxxxx>]

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