Re: X.509 certificate and its subject name field

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

> From: Hal Lockhart <hal@platsol.com>
> 
> Look, I apologize if I am the only one on this list who doesn't "get it",
> but I am trying to ask serious questions about what the specification
> specifies and what it does not specify.

They are valuable questions, and I in turn apologize if my comments sound
abrupt.  But getting a universal understanding of the facts and the areas
of general agreement will free up the discussion to focus on other topics.

> Suppose I am going to make an authorization decision.  To do so, one of the
> things I have to determine is the "subject."  It seems to me that my notion
> of what a subject is has to match that of the certificate issuer. 
> 
> Does the spec tell me what fields I need to check to (unambigiously)
> determine the identity of the subject?  Or is that up to me?
> 
> Is the CA free to put anything it likes in the subject name field as long as
> the syntax is right and it follows its own published policies?

Precisely.

The IETF conundrum "mechanism, not policy" applies here.  I believe PKIX's
role is to define unambiguous mechanisms for allowing the various parties
in the PKI (subjects, issuers, and verifiers) to interwork.  The mechanisms
must be precisely defined, because policy designers must know how to encode
their intended semantics into certificates, but they must be flexible
enough to allow a wide range of semantics to be expressed.

The question "what is a subject" is unanswerable in the PKIX context
(except perhaps for the PKIX part 4 document, which specifies the universe
of questions PKI participants should consider, but does not specify answers
to any of them).

Anyone who claims that X.509 DNs are globally unique is probably speaking
in the context of the X.500 DIT.

But it is certainly a requirement that X.509 certificates be usable without
relying on globally-unique DNs, given the fact that the world has not signed
up to the concept of either a single root Certification Authority or a
single root Naming Authority (the Directory).  The best we can hope for
is Federated Naming, ugly though it might be.

Bottom-up designs and locally managed environments are a fact of life.
We must just ensure that the mechanisms used in local environments are
also capable of scaling up to global scope.  Designing for the global
environment but allowing the flexibility to simplify is the PKIX approach,
in contrast to some other public key based mechanisms.