[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 rfc2247                                                 
Network Working Group                                           S. Kille
INTERNET-DRAFT                                          ISODE Consortium
Obsoletes: RFC 1279                                              M. Wahl
                                                     Critical Angle Inc.
Expires in six months from                                 July 31, 1996
Intended Category: Experimental

           An Approach for Using Domains in LDAP Distinguished Names

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

1. Abstract

   The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
   Distinguished Names for providing unique identifcation of entries.
   Distinguished Names in currently-deployed X.500 directories have the
   properties that they are descriptive, hierarchical, and follow common
   organizational models.  However, there is not today a universal
   registration mechanism to permit individuals and organizations to obtain
   Distinguished Names.

   This document describes an experimental mechanism by which a name
   registered with the Internet Domain Name Service, for which there is an
   active registration service, can be represented as a Distinguished Name
   so that it may be used with the LDAP protocol.  This is not intended to
   have LDAP replace the DNS protocol, but to permit further deployment of
   LDAP into organizations connected to the Internet.

2. Domain Names and Distinguished Names

   The Domain (Nameserver) System (DNS) provides a hierarchical resource
   labelling system [1].  An example domain name would be

   Entries usually have a single name, although pointers to entries
   may be provided by CNAME records.  Information (resource records) is
   associated with each entry.  Name components are typically chosen to be
   shortish (e.g., "WWW").

INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996

Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 2

   The X.500 Directory provides a very general hierarchical naming framework.
   A primary difference in specification of Distinguished Names from
   domain names is that each component of an distinguished name has an
   explicit attribute type indication.  (It is also possible to have multiple
   components in the same level, but that is not commonly done today).

   An example Distinguished Name represented in the LDAP string format [2]
   is "CN=Mark Wahl, O=Critical Angle Incorporated, ST=Texas, C=US".

3.  Mapping Domain Names into Distinguished Names

   This section defines a subset of the X.500 naming structure for use in
   representing names allocated in the Internet Domain Name System.  It is
   expected that it would be possible to algorithmically transform any
   Internet domain name into a Distinguished Name, and to be able to convert
   such a name back into a domain name.

   The algorithm for transforming a domain name is to begin with a DN of
   "O=Internet", and then attach RDNs for each component of the domain,
   most significant first.  Each of these RDNs have a single
   AttributeTypeAndValue, where the type is domainComponent (abbreviated "DC")
   and the value is an IA5 string.

   Thus the domain name
   can be transformed into
        DC=CS, DC=UCL, DC=AC, DC=UK, O=Internet

   And similarly
        DC=11, DC=168, DC=192, DC=IN-ADDR, DC=ARPA, O=Internet

   X.500 Distinguished Names in which the first RDN is "O=Internet", and there
   are one or more following RDNs, each with the attribute type
   domainComponent, can be mapped back into domain names.  Note that there
   will not be an algorithmic domain name equivalence for all other
   Distinguished Names, such as:

    CN=Steve Kille, DC=ISODE, DC=COM, O=Internet
    O=ISODE Consortium, C=GB

4.  Limitations on Use of this Mechanism

   This naming mechanism is primarily intended for experimental or single-site
   pilot projects, or where the directory service does not currently intend to
   connect to any established service, but still requires a globally unique

   If an organization is running a service in a locality for which there is an
   official registration authority for distinguished names, an officially
   registered distinguished name should be used instead of this mechanism.
   These names are typically based on the concatenation of an organization's
   registered name and the location of that registry, such as "O=IC, C=GB".

   If an organization intends to connect to an established directory service,
   then the guidelines of that service should be followed.

INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996

Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 3

5.  Attribute Type and Object Class Definition

   The domainComponent or DC attribute type is defined in [3], and is
   reproduced here for convenience.

    domainComponent ATTRIBUTE ::= {
        WITH SYNTAX               IA5String
        EQUALITY MATCHING RULE    iA5EqualityMatchingRule
        SINGLE VALUE              TRUE
        ID                        {pilotAttributeType 25} }

   The encoding of IA5String for use in LDAP is simply the characters of the
   string itself.  The equality matching rule is case insensitive, as is
   today's DNS.

   The domain object class would be used as the structural object class of
   entries whose distinguished names are generated according to the algorithm
   in section 3.

     domain OBJECT-CLASS ::= {
         SUBCLASS OF { top }
         MUST CONTAIN { domainComponent }
         MAY CONTAIN {
             organizationalAttributeSet }
         ID {pilotObjectClass 13} }

      domainNameForm NAME-FORM ::= {
         NAMES domain
         WITH ATTRIBUTES { domainComponent }
         ID {enterprises 1466 345 }}

   If it is desired to be able to store or retrieve DNS-specific attributes
   via LDAP, the dNSDomain object class can be used as well.

6.  Directory Information Structure

   This algorithm assigns to any organization which has obtained a domain name
   for use in the Internet a distinguished name for use as a prefix for their
   own entry's names.

   Thus a small organization which holds the domain name

   Might have as their directory entries:

     CN=Mark Wahl, DC=CRITICAL-ANGLE, DC=COM, O=Internet
     CN=Postmaster, DC=CRITICAL-ANGLE, DC=COM, O=Internet

   While an organization with multiple subdomains might structure their
   entries as:

     CN=Steve Kille, DC=Richmond, DC=ISODE, DC=COM, O=Internet
     CN=Greg Lavender, DC=Austin, DC=ISODE, DC=COM, O=Internet

INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996

Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 4

   There are a number of RFCs, such as [4] and [5], which provide guidance
   on representing and structuring information in directory entries which
   would be applicable.

7. Relationship with LDAP when Browsing

   To effectively search the entries in an LDAP server connected to a global
   directory system, it is necessary to know the base object of the entries
   a server maintains.

   If a client does not have any information on a search base to use, then
   there are three possible approaches:

    1. Interrogate the server for the naming contexts it holds.
    2. Create a search base based on the domain name of the contacted server.
    3. Browse by searching immediately subordinate to the root.

   Approach 1 is recommended if the client and server both support LDAP
   version 3 or higher.  If this is not the case and there is no other
   information available to the client, then approach 2 is recommend.

   Approach 2 makes use of the mechanism defined in this document, with a
   slight extension.  If the least significant component of the contacted
   server's domain name is "ldap" or "x500", this component is ignored, and
   the remainer of the domain name is transformed into a distinguished name.

   Thus for example if the client was asked to contact the server
   ldap.critical-angle.com and browse, it would using approach 2 issue its
   searches with the base object "DC=CRITICAL-ANGLE, DC=COM, O=Internet".

   Approach 3 is not recommended, as the server may chain or refer the
   operation to another server which holds entries subordinate to the root
   (such as countries).

8. References

   [1] P. Mockapetris. Domain names - concepts and facilities.
       RFC 1034, November 1987.

   [2] S. Kille, M.Wahl.  Lightweight Directory Access Protocol (v3):
       UTF-8 String Representation of Distinguished Names.
       INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996.

   [3] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
       X.500 schema. Request for Comments RFC 1274, November 1991.

   [4] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring
       Guidelines for X.500 Directory Pilots". RFC 1617 May 1994.

   [5] B. Jennings, "Building an X.500 Directory Service in the US",
       RFC 1943, May 1996.

9. Security Considerations

    This memo does not address security issues.

INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996

Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 5

10. Author's Address

   Steve Kille
   ISODE Consortium
   The Dome
   The Square
   Richmond, Surrey
   TW9 1DT

   Phone:  +44-181-332-9091
   EMail:  S.Kille@ISODE.COM

   Mark Wahl
   Critical Angle Inc.
   4815 W. Braker Lane #502-385
   Austin, TX 78759

   EMail:  M.Wahl@critical-angle.com