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

Versions: 00                                                            
Internet Engineering Task Force       Jeff Hodges, Stanford University
INTERNET-DRAFT                                           October, 1997
Category: Standards Track

         Requirements for Distinguished Names in Autonomous to
             Loosely-coupled LDAP-based Directory Services

                        Status of this Document

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments 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).

This document expires in April 1998.


This document analyzes the issues involved in the Distinguished Name-
spaces of autonomous to loosely-coupled, LDAP-based directory services
(LLDSs). It folds in experience learned from the global X.500-based Dis-
tinguished Name-space, and proposes requirements for the construction of
Distinguished Names for LLDSs of varying scopes.

1.  Introduction

LDAP-based directory services provide a "named entry with attributes"
model -- an entry's attributes may be retrieved by looking up its name
in the directory. In order to provide a directory service in which por-
tions of the namespace are contributed by relatively autonomous servers,
there must be agreements on how the namespace's topology, properties,
and allocation work.

J. Hodges                                                       [Page 1]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

This document provides general background on naming in LDAP-based direc-
tory services, analyzes the specific case of loosely-coupled, LDAP-based
directory services (LLDSs), examines experience gleaned from the X.500-
based global directory, postulates some future applications for LLDSs,
and then proposes requirements for such a directory service's Dis-
tinguished Name-space.

Note that this document does not address requirements for an LLDS Dis-
tinguished Name-space in the context of their utilization as part of
LDAP URLs [LDAPurls] or LDAP Uniform Resource Names (URNs). See the fol-
lowing section for details.

This is a requirements definition document. It does not define a partic-
ular solution or its implementation. These topics will either be
addressed in other Internet-Drafts or this document will be merged with
ones addressing them.

1.1.  What this Document Doesn't Address

This document does not address the specific cases of..

  1. The details of entry Relative Distinguished Name (RDN) construction
  and "entry naming" in general. They both are ostensibly pieces of
  overall "entry naming schemes". Such schemes may address not only how
  RDNs are selected, but also issues such as how to accomodate
  representing "names" of entries utilizing non-distinguished attri-
  butes. Entry naming schemes are thus decidedly site-specific and
  potentially complex in their own right.

  2. How, given the DN of an entry and/or some attribute value from the
  entry, e.g. the value of the "mail" attribute, one would go about
  locating a specific directory service or server hosting the entry.

  3. How DNs and thus entries in an autonomous or loosely-coupled direc-
  tory service are mapped to so-called "real world objects". This is
  entirely site- and entry-specific.

  4. Distinguished Name-space requirements in the context of LDAP URLs
  or URNs. The requirements proposed in this document are based on the
  assumption of Distinguished Names being utilized on their own, not
  specifically as part of LDAP URLs or other amalgamations such as URNs.
  LDAP URLs/URNs may be considered and utilized, in some contexts, as
  "meta-Distinguished Names" which would explicitly contain more
  specific directory service context than Distinguished Names can on
  their own. Determining requirements for such utilization of Dis-
  tinguished Names is outside the (current) scope of this document.

All of the above concepts are outside of the (current) scope of this

J. Hodges                                                       [Page 2]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

document. They may be addressed in other Internet-Drafts, or the scope
of this document may be widened to include them.

2.  Document Conventions

The key words "MUST", "SHOULD", and "MAY" used in this document are to
be interpreted as described in [ReqsKeywords].

3.  Background: Concepts of Naming in an LDAP-based Directory Service

Directory services provide a lookup capability -- knowing something
about an object, such as one of its names, one may lookup additional
information about it in the directory. Thus a name in the directory ser-
vices context is analogous to the concept of "keys" in the relational
database management systems (RDBMS) context.

X.500 [X.500], and thus LDAP [LDAP], employ a hierarchical namespace.
This namespace is analogous to the "keyspace" a specific RDBMS-based
database may have. An entry may have a name that relates only unto
itself, with the only requirement being that the name is unique at that
level of that particular branch of the hierarchy -- i.e. among its
siblings. However, one must be able to locate the name at its position
in the hierarchy before the name is meaningful in a context beyond that
of the entry itself.

Thus in X.500 and LDAP, names have the concepts of being "relative" or
"distinguished". A relative name is the entry's name unto itself, and
isn't required to have any relation to other entries at that point in
the hierarchy. There is a fully-qualified form of an entry's name,
called the Distinguished Name (DN). DNs are quite similar to fully-
qualified Internet domain names [DNS] in that their components trace the
path from the root of the namespace hierarchy down to the entry. The
entry's relative name is simply a component of the entry's Distinguished
Name, much the same way that an Internet host's name is just a component
of the host's fully-qualified domain name. An entry's relative name is
known as its Relative Distinguished Name (RDN).

Given that RDNs must be unique at each level in the hierarchy (i.e.
among their siblings), then each DN derived from that naming hierarchy
will be unique, relative to that hierarchy.

One uses different forms of an entry's name to look it up, depending
upon one's context relative to the naming hierarchy. If one's context is
the same as that of the entry, one may refer to it using only its RDN.
If one's context is different, e.g. perhaps being outside the directory
context and "looking in", then one (essentially) uses the entry's DN
(which is fully-qualified by definition).

J. Hodges                                                       [Page 3]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

4.  The Specific Problem Space: Loosely-coupled, LDAP-based Directory

Loosely-coupled, LDAP-based directory services (LLDS) are being postu-
lated by various working groups within the IETF. Specifically, such
directory services will be made up of coalitions of cooperating, but
essentially autonomous, site-specific directory services belonging to
distinct and independent administrative domains. One of the primary pur-
poses of such directory services will be to provide for lookup of, and
searching for, entries across administrative domains. This, in essence,
calls for a unified "distinguished name"-space in an LLDS's context,
which we'll term in this document a "LLDS distinguished name-space".

The autonomous directory services making up an LLDS will be contributing
to portions of the LLDS distinguished name-space in much the same way
that various administrative domains' DNS services contribute portions of
the DNS namespace [DNS]. Given the characteristics of naming in LDAP-
based directory services described above, the DNs contributed to a LLDS
by the cooperating participants must be at least distinctly unambiguous,
if not distinctly unique. This is similar to how Domain Names contri-
buted to the DNS namespace must be unambiguous, i.e. they and their
associated entry may be hosted on more than one server, if not dis-
tinctly unique.

5.  Prior Work: The X.500 Directory

The X.500 standard proposes a global directory naming scheme in
[X.500Naming]. In this scheme, the DN hierarchy, known as the Directory
Information Tree (DIT), is based upon combinations of the names of geo-
political (e.g. countries, states, provinces, etc.) and organizational
(e.g. companies, governments, universities, etc.) entities.

In practice, this has proved quite unwieldy, though not entirely unwork-
able, in many geopolitical and organizational contexts because conflicts
abound when trying to allocate globally distinct and unique DNs directly
from the patchwork quilt of real-world namespaces -- specifically, there
is ~noone~ with the authority to consistently mediate them all. This
situation can be summarized as..

  There is no overarching, international naming authority for
  geopolitical and organizational entities in the global,
  real-world context.

[Amen. -- ed.]

6.  The Future: Applications of LLDSs

There are many potential applications for LLDSs. A broad-based,

J. Hodges                                                       [Page 4]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

Internet-wide whitepages listing for people is arguably the most com-
monly promoted one. Other high-leverage, emerging applications will be
in the context of Internet-based electronic commerce and security
infrastructures. In this context, DNs, and/or URLs based on the DNs
[LDAPurls], will likely be cached for later use, where "later" might be
on a scale of (potentially many) years.

Also, products are already emerging, e.g. Netscape Communicator, which
directly utilize and cache LDAP URLs and DNs. Certainly, more are likely
to follow, and broad-based usage of such tools to increase.

7.  Definitions of Directory Service Contexts

7.1.  Local Directory Service Context

A "local directory service context" may range from a single autonomous
directory server to a set of loosely-coupled directory servers, i.e. an

7.2.  General LLDS Context

A "general LLDS context" may range from a small set of LLDSs to a set of
arbitrary size.

8.  Requirements for LLDS Distinguished Name-spaces

Given LDAP's distinguished name-space model, the movement towards creat-
ing LLDSs, the lessons from X.500, and envisioned applications for
LLDSs, these are requirements for distinguished names in the context of
loosely-coupled, LDAP-based directory services...

8.1.  The Primary Requirements

  R1.0. Distinguished Names (DNs) of entries in a given "local directory
  service context" MUST be able to perform as unique primary keys. This
  is essentially "by definition" of a DN. Local-context DNs MAY OR MAY
  NOT be unique across other autonomous directory servers or other

  R1.1. Distinguished Names (DNs) of entries in a given "general LLDS
  context" MAY be able to perform as unique primary keys. If a given DN
  is not unique, then a non-null set of entries within the general LLDS
  context will have that same DN. However, this DN SHOULD be unambiguous
  within the general LLDS context -- i.e. distinct entries in a general
  LLDS context MAY have the same DN IF there is an explicitly esta-
  blished relationship among them, otherwise distinct entries SHOULD
  have DNs which are unique within the general LLDS context.

J. Hodges                                                       [Page 5]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

8.2.  Overall Derived Requirements for DNs in a General LLDS Context

  R2. DNs contributed to a general LLDS distinguished name-space by oth-
  erwise autonomous directory service instances MUST satisfy R1.1.

  R3. DNs in a local directory context, which MAY potentially become a
  part of a general LLDS context, SHOULD utilize DNs that satisfy R1.1.

  R4. DNs in a local directory context, which may or may not become a
  part of a general LLDS context, MAY utilize DNs that satisfy R1.1.

  R5. A general LLDS context's distinguished name-space hierarchy, from
  which DNs are allocated (and modulo the specific requirements for RDNs
  below), SHOULD be based on some pre-existing heirarchical naming
  infrastructure having these specific properties...

    R5.1. It is available across the administrative domains participat-
    ing in the general LLDS context.

    R5.2. It is well-understood, and has a low-cost registration process
    (in both monetary and effort terms).

    R5.3. It is widely subscribed-to.

    R5.4. It is actively and effectively managed and has clearly defined
    procedures that are published across participating administrative

    R5.5. It provides names that are guaranteed-unique across the parti-
    cipating administrative domains.

    R5.6. It provides names that change relatively infrequently, by some
    established, well-documented procedure, or not at all.

8.3.  Requirements for Entry RDNs

  R6. Entry RDNs MUST be unique among their siblings (this is by defini-
  tion, but worth reiterating).

  R7. Entry RDNs SHOULD be immutable.

  R8. Entry RDNs MAY be based on any attribute type, subject to the
  entry's object class restrictions, and the attribute's value SHOULD be
  sourced from a documented, site-specific scheme that provides well-
  managed, guaranteed-unique names.

  R9. Entry RDNs MAY be constructed using only one attribute type and

J. Hodges                                                       [Page 6]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

  value pair, or MAY be constructed of an amalgamation of attributes. If
  the latter option is used, the involved attributes and their values
  SHOULD satisfy R8.

9.  Summary

This document has presented LDAP-based directory service naming con-
cepts, analyzed naming issues involved in loosely-coupled LDAP-based
directory services, and briefly summarized prior X.500-based experience
with naming.

The presented LLDS Distinguished Name-space requirements seek to satisfy
the issues involved in LLDS naming as well as ameliorate the naming
issues experienced with the global X.500-based directory.

The intent is that in using these requirements as guidelines, we can
reasonably and manageably design and construct Distinguished Name-spaces
for LLDSs of arbitary and evolving scope.

10.  Security Considerations

This document expresses requirements for Distinguished Names in contexts
ranging from an autonomous directory server to a loosely-coupled direc-
tory service of potentially Internet-wide scope. Other documents which
specify designs for systems and/or protocols seeking to satisfy these
requirements should consider security implications from at least this

  DNs and/or URLs based upon them are publicly consummable and cache-
  able. Each one will conceivably expose some of a LLDS's structure.
  What are the implications for the security and authorization facili-
  ties of the individual directory services participating in the LLDS,
  and the various client systems based upon the LLDS?

11.  Acknowledgements

Many of the concepts in this document are drawn from [Dirnaming]. Al
Grimstad, Chris Apple, and Chris Weider contributed valuable comments
and perspectives to this document.

12.  References

     Naming Plan for Internet Directory-Enabled Applications. A. Grim-
     stad, R. Huber, S. Sataluri, S. Kille, M. Wahl. Internet-Draft,
     work-in-progress. August 1997. Available as: <draft-ietf-ids-

J. Hodges                                                       [Page 7]

Internet-Draft         DN Requirements for LLDSs                Oct-1997

[DNS]Domain Name System Structure and Delegation. J. Postel. RFC 1951.
     March 1994.

[LDAP]Lightweight Directory Access Protocol. W. Yeong, T. Howes & S.
     Kille. RFC 1777, Draft Standard. March 1995.

     An LDAP URL Format. T. Howes & M. Smith. RFC 1959. June 1996.

     Scott Bradner, "Key Words for use in RFCs to Indicate Requirement
     Levels", RFC 2119.

     The Directory: Overview of Concepts, Models and Service.  CCITT
     Recommendation X.500, 1993.

     Annex B to CCITT Recommendation X.521, 1993.

13.  Author's Address

   Jeff Hodges
   Computing & Communication Services
   Stanford University
   Pine Hall
   241 Panama Street
   Stanford, CA 94305-4122

   Phone:  +1-650-723-2452
   EMail:  Jeff.Hodges@Stanford.edu
   URL:    http://www.stanford.edu/~hodges/

J. Hodges                                                       [Page 8]