Subject: RE: Finding PKIX Servers!

From: "David P. Kemp" <[email-masked]>
Date: Wed, 10 Feb 1999 10:49:19 -0500 (EST)

> From: Andrew Probert <[email-masked]>
> 
> Again .. Banking infrastructure relies upon giving a customer a simple
> 'name'  (card-number) within a naming scheme:
> 
>    prefix-account number
> 
> Where the prefixes are globally registered in a process agreed amongst
> financial institutions, the authorities have an established registration
> process and a naming convention for these, to ensure global
> interoperability.  It works.  

Right.

In this thread it often appears that the distinction between Naming
authorities, Security authorities, and Retrieval mechanisms
(directories/repositories) is being either forgotten or intentionally
obfuscated.  It would be clearer (at least to me :-) if the discussion
and the architectural proposals maintained a clear separation of the
three and an explicit minimization of dependencies among them.

X.509 v3 extensions enabled the separation of naming and security
management: a car company "RR-Benz.com" or "C=de O=RR-Benz AG" could
outsource its CA functions to "CertFantastic.com" or
"C=US O=CertFantastic Inc." and I, as a relying party, could automatically
validate a cert path in which my root CA designated (after some
unspecified administrative process) CertFantastic as authoritative
for all of RR-Benz's certs.  Each entity could have names in one or
more global namespaces: the DNS namespace, the X.500 global DIT,
the banking global registered prefix space, or something else.
Those name(s) do not have any *required* connection to the path
of trust, although it makes life simpler if for some sets of
entities the trust path and the name heirarchy are topologically
related.

Similarly, the PKIX community should require that any proposal for
a standardized cert retrieval mechanism enable a similar separation
between CAs and repositories.  A repository can have one or more
names; it doesn't matter whether they are in the DNS space or the
X.500 space except that: 1) names registered under DNS are global
today, and 2) if you are going to use the Internet to move data
around, you have to wind up with an IP address for the repository
at some point.  Mapping X.500 names to IP addresses involves
either creating a separate infrastructure parallel to DNS, or using
a three step lookup: X.500 name -> DNS name -> IP address.

> From: "Tammy Carter" <[email-masked]>
> 
> I don't understand.  Several of the people on this list seem to
> believe that the way to find a CA is via some kind of advertisement.
> However, what I don't understand is why?  Bob's suggestion of using the
> certificate to contain information about where to find the CA seems to
> work AND it is more similar to the mechanism that we already have for
> finding revocation information.

Right.

I'm at a loss to understand Phill's suggestion to use DNS SRV records
(instead of just putting the CA's URL in the cert itself), and Alan
Lloyd's suggestion that putting a URL in a cert would require an
army of administrators.  Running a directory tightly coupled to
the security management infrastructure requires the army; running
a loosely coupled directory/repository named in a URL is easier.

> From: Andrew Probert <[email-masked]>
> 
> 1.  I think there is broad issue "Finding PKIX" servers in a global
> interoperable scenario, which needs to be addressed. I personally don't want
> hand code lots of browsers and software.  Is the agreed way to find a PKIX
> server going to be via URL/DNS reference as an active / informed decision.
> Requirements and discussion please?

Agreed, as above.

> 2.  I have responded to the Pasadena Ladies Club scenario, where coding a
> explicit reference into a cert to a bureau may cause an operational issue
> forcing re-issuance of all certificates, which hopefully people should admit
> is an problem?

Nope, I won't admit it's a problem.

If a CA issues a cert for a specific validity period, and contracts
out for repository services for that period, then the CA doesn't have
the option of changing its mind in the middle.  If the repository
goes bankrupt, it would seem reasonable to hand over operation of
the URL to some other organization.  If the repository willfully
decides not to honor the service contract, and as a result causes
damages because certs and CRLs can't be found, then take 'em to court.

Nothing forces re-issuance of all certificates; that's a red herring.

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Wed, 10 Feb 1999 16:02:35 -0500

> a loosely coupled directory/repository named in a URL is easier.

The URL in the cert method is fine but some folk have a problem. For example
the revocation service may be other than the CA originally specified. It may
not be possible to access the URL specified in the Cert when the time comes
to rely on it.

My interpretation of Alan's post was that he is proposing much more.
He wants to weld the PKI to the directory so that if the Directory is
down it is certain the PKI will be as well. This is the 'directory
dependent' model of PKI, I don't like that idea.

The 'directory linked' approach I believe is sensible uses the directory,
but only for purposes that are a good fit - i.e. locating parties -
One problem is how you obtain the cert in the first place given that
you probably are looking for a Cert which maps to [email-masked] so you can
do email. URLs in the cert don't help in this case :-)

According to Alan you go to the Global X.500 directory system and
perform a lookup. This approach only has three problems, first no such
directory exists, second if it did it might get tiresome doing a search of
the entire directory space for an entry with the right attribute, third
X.500 is only standardized over the OSI network stack and not over IP,
LDAP does not include the replication protocols being promoted as the basis
for the 'global scalability' claim.

In conclusion I really don't know why we need the argument. We have
established a function for directories in PKIX that makes sense. We
have revocation mechanisms which make sense. I don't know why we need
to conflate revocation of authentication credentials and the directory.
Authorization credentials might be another matter, but those are not
currently in PKIX scope.

		Phill