FYI

At the NADF meeting this week, the topic of storing public key
certificates in the Directory was discussed.  Here is text of a
contribution summarizing the discussion.  Prospective readers of this
text should be aware of the difference between the concepts of
registration and listing.  These are discussed in the NADF's SD-5.  RFC
1417 says how to get a copy of the NADF's SD series.

/mtr
                                #######
1. Introduction

This contribution discusses how information about a user with a Public
Key Certificate (PKC) may be represented in the Directory.  This
contribution does not discuss how the Directory makes use of strong
authentication.


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.

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.


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.

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
is 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.

There are two results which follow from this schism:

 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.

 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.
                                #######