The NADF meeting referred to by Marshall Rose and
Steve Dusse was very enlightening.
Marshall's contribution is very important, but also rather
information dense in terms of the concepts presented. At
the risk of putting words in his mouth, I'll try to expand his
comments from a PEM perspective.
I'll skip his discussion regarding naming for now, then come
back to it.
3. Relationship between the Directory and Public Key Certificates
X.509 defines a syntax for PKCs consisting of several fields,
including two name fields having the Distinguished Name (DN) syntax:
the name of the subject (user), and the name of the issuer
(certification authority or CA).
In X.500, DNs are used to distinguish between entries in the
Directory. That is, DNs can be viewed as having the property that
different entries always have different DNs. Although DNs may
correspond to real-world objects (e.g., persons), X.500 does not
prescribe that any particular DN can be used to unambiguously identify
a real-world object (e.g., a particular person). In essence, DNs are
not unlike DIT addresses.
This prompted some discussion regarding the nature of listing vs.
registration vs. certification. Marshall's point is that X.500 does not
mandate any relationship between a DN and a particular object.
In fact, some DNs do not represent real world "objects" at all.
However, if the real world object does exist and if a binding does
exist between object itself and the Distinguished Name of that object,
then the DN DOES unambiguously (but not necessarily uniquely) identify
that object.
The X.509 certificate structure may be used without an underlying
Directory service, and X.500 does not prescribe the relationship of
the name fields within a PKC to the entries within the DIT. As such,
the interpretation of the significance of the name fields within a PKC
i>s a matter for each CA to decide. That is, a CA may, or may not,
choose to view these name fields as being descriptive names outside the
scope of the DIT, and in doing so may choose to assign a real-world
semantics to a principal named in a PKC.
In other words, X.500 by itself does not dictate ANY particular relationship
between the DN in the PKC and the DN in the DIT (i.e., in the Directory,
if such a name has actually been entered into the Directory), or vice versa.
That does not imply that certain relationships may not be necessary
or at least helpful if X.500 is going to support PEM and/or other uses of PKC,
and vice versa.
The important point is that the Certification Authority DOES assert
that such a binding exists between a real world object (generally an
individual or "user") and the DN of that user, and in addition binds
the DN (and by implication the user with that name) to a particular
public key in a PKC.
There are two results which follow from this schism:
(Marshall said he couldn't remember how to spell dichotomy, but "schism"
may have the right theological connotations after all. :-) )
1. An entry having an objectClass attribute value of
strongAuthenticationUser contains one or more userCertificate
attribute values. Each of these is a PKC. However, there need be no
relationship between the name of the entry holding a PKC and the
subject or issuer fields of that PKC. Similarly, the subject field of
a PKC needn't correspond to an entry in the DIT.
Example:
I might have a number of DN listings (some of which might be aliases)
in the DIT, including
C=US, ansiOrg=GTE Laboratories Incorporated, CN=Robert R. Jueneman
C=US, O=GTE Labs, CN=Robert R. Jueneman
C=US, O=GTEL, CN=Bob Jueneman
C=US,S=MA,O=GTE Laboratories, CN=Robert Jueneman
In the case of separate listings, each DN could contain one or more
X.509 PKCs as attributes. Any aliases would presumably point to one of
these listings.
However, the subject's DN contained in the certificate might very well
read
C=US, O=GTE Laboratories Incorporated, CN=Robert Reade Jueneman
As far as X.500 is concerned, this is perfectly legal. Likewise, as far as PEM
and other uses of X.509 is concerned, this is also legal. No further
specification
of DNs should be REQUIRED, either by X.500 or PEM.
2. The issuer (CA) field of a PKC needn't correspond to a entry in the
DIT. However, this may be useful as that entry might contain an
objectClass attribute value of certificationAuthority, which indicates
that the CA's entry contains information such as a PKC revocation
list.
I.e., it may be DESIRABLE to define the same DN as in the PKC,
C=US, O=GTE Laboratories Incorporated, CN=Robert Reade Jueneman
within the Directory as well, in order to have a convenient place to refer to
other useful entries such as my Internet or X.400 address, my FAX number,
etc. In particular , some PCAs might usefully require that such a relaionship
exist, and that the name of the PCA, the DN of the PCA's policy, and perhaps
any caveats or limitations pertainling the the user's use of his digital
signature
be spelled out as additional (non-distinguished) attributes.
Likewise, if we ever expect to distribute CRLs via the X.500 mechanism in
addition to the distributing the PKCs, it would presumably be very useful
to include the current CRL (and perhaps some previous ones?) as attributes
of the CA's entry. In order to faciltate finding those CRLs, it would be
convenient to have a DN in the Directory that exactly corresponds to the
issuer's DN in the certificate.
Marshall's point regarding naming requires some further explanation, I think.
2. Naming
SD-5 is used as the basis for naming PKC users. Specifically, the DIT
is divided into the Shared DIT Domain and one or more Service Provider
DIT Domains.
Although X.500 was written from the point of view of a monopoly provider
or Administrative Directory management Domain (ADDMD), within the US
and a number of other countries unfettered compition will be the rule. The
Shared DIT Domain consists of that portion of the name space which is
not uniquely qualified by an organization name. The knowledge of all
of the organizations and residential persons within this shared DIT space is
managed by sort of an offline directory-of-directories process, whereby the
knowledge of which directory service provider(s) contain or has access to
information regarding a particular DN is disseminated through naming links that
are broadcast as updates to a baseline set of name links. Directory
administrators
provide updates to the NADF (coordinated by the US Post Office under a no-cast
contract), and then all ADDMDs and some Private Directory Management
Domains (PRDMDs) retrieve these update via FTP and apply then to their
own X.500 systems through a set of tools. This process is called the Central
Administration for NADF (CAN).
The Shared DIT Domain consists of a geographical structure: within a
country there are regions, and within regions there are localities.
At each level, an entity such as an organization, may have zero, one,
or more listings, based on its civil standing and where it wishes to
list. Once an entity is listed, it is solely responsible for
organizing the DIT beneath its listing. Although SD-6 provides
guidance in this area for organizations, SD-5 does not mandate any
particular schema.
For example, the entry named by
{ c=CA, o=ABC }
might have an objectClass attribute with values of organization and
strongAuthenticationUser, and would also contain PKC-related
attributes such as its userCertificate. Of course, as with any entry
in the Shared DIT Domain, some of this information might be made
indirectly available through the use of naming links. For example,
the entry named by
{ c=CA, o=DEF }
might have an objectClass attribute with values of organization and
publicObject, and might also contain a namingLink attribute such as
{ c=CA, ad=AD1, o=DEF }
That entry might have an object class attribute value of
strongAuthenticationUser and contain one or more userCertificate
attribute values.
X.500 allows all sorts of listings, including listings under state other
than the state in which an organization resides (similar to listing the Trump
Palace in Atlantic City in the NYC white and yellow pages.) However,
PEM PCAs might reasonably want to impose some SEMANTICS and/or schema
on this process, so that for example the use of a state attribute without
a locality attribute would imply that the organization was registered with
the Secretary of State of that state.
Once the first level entity (organization, usually) is defined within the DIT,
that entity serves as a mount point for all entries under that node, and that
entity
is allowed to create DNs however it will, including the use of private
attributes with
OIDs belonging to and understood by that entity alone.
However, a PCA may choose not to allow such arbitrary naming schemes as
DNs within PKCs that it certifies (directly or indirectly), in particular
because
of the difficulty imposed on all of the Directory User Agents and certificate
processors that would be requried to interpret such an arbitrary
string of attributes. For example, the PCA might require that the attributes
used to make up the DN in the PKC be chosen from the set of X.520 attributes
and a few selected additional ones, and further impose rules such as name
subordination on these DNs.
I hope this was helpful, and in particular I hope it answered John Lowry's
question:
If there is no relationship between the CA or subject name in the PKC and
the DIT then how do you propose we search the Directory to validate
certificatePaths and CRLs ? We have always assumed that upon being presented
with a subject PKC (from a mailer) that we could search the Directory to
to find all issuers and their CRLs. If this functionality is not present
or is sufficiently complicated they [sic - then?] you have lost one of your
best "users".
Whether X.509 certificates and CRLs can be distributed efficiently via X.500
directories is a question that the NADF is beginning to make plans to answer. I
wouldn't make any particular assumptions one way or the other as yet, in
particular because the NADF is just beginning to define how settlements will be
done and as yet we don't know what this service will cost. Fortunately, PEM is
not
dependent on the use of X.500 for such features, and a number of other models
have
been suggested. Unfortunately, the alternative PEM certificate and CRL
distribution
infrastructure doesn't seem to be moving very rapidly to date.
Perhaps the PEM community would like to make some concrete recommendations as to
how the PKC and DIT DN space should be structured, how we should distribute
certificates and CRLs, etc. Several members of the NADF, including GTE Labs,
are
potentially interested in providing such services and would welcome specific
requirements.
(A well thought-out business case that would spell out what the users would be
willing to
pay for such services would certainly be welcome as well!)
Bob