view Side-By-Side changes
IDS Working Group Al Grimstad
INTERNET-DRAFT Rick Huber
Sri Sataluri
AT&T
Steve Kille
Isode Ltd.
Mark Wahl
Critical Angle Inc.
March 12,
August 28, 1997
Naming Plan for an Internet Directory Service Directory-Enabled Applications
Filename: draft-ietf-ids-dirnaming-01.txt draft-ietf-ids-dirnaming-02.txt
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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Editorial comments
should be sent directly to the authors. Technical discussion will
take place on the IETF Integrated Directory Services mailing list,
ietf-ids@umich.edu.
This Internet Draft expires August 1, 1997.
Abstract
Application of the conventional X.500 approach to naming has, has
heretofore, in the experience of the authors, proven to be an
obstacle to the creation wide deployment of
directory services. directory-enabled applications on
the Internet. We propose a new directory naming plan that leverages
the strengths of the most popular and successful Internet naming
schemes for naming objects in a hierarchical directory. This plan
can, we believe, facilitate the creation of an Internet White Pages
Service (IWPS) and other directory-enabled applications by overcoming
Grimstad, et al. [Page 1]
INTERNET-DRAFT Naming Plan August 1997
the problems encountered by those using the conventional
recommended X.500
approach to naming.
1.0 EXECUTIVE SUMMARY
The Executive Summary
Application of the conventional X.500 approach to naming taken by the X.500 community has, has
heretofore, in the experience of the authors, shown itself proven to be an
obstacle to the creation wide deployment of directory services. directory-enabled applications on
the Internet. The required registration infrastructure is either
non-existent or largely ignored. The infrastructure that does exist
is cumbersome to use and tends to produce counterproductive results.
The attributes used for naming have been confusing for users and
inflexible to managers and operators of directory services. servers.
This paper describes an alternative directory naming plan for the
construction of the an Internet White Pages Service (IWPS) and other directory infrastructure to support
directory-enabled applications. It
The plan has three the following two main features. First, it bases directory the
root and upper portions of the name construction hierarchy on the existing
infrastructure of names in the Internet, that is, names from the Domain Name System
(DNS) and mailbox identifiers structured according to RFC822. Second,
names constructed according to this (DNS). This
component of the plan makes use existing standardized
directory attributes and can co-exist with names constructed according of the ideas described in the
companion paper to traditional X.500 naming practices. this plan, "Using Domains in LDAP Distinguished
Names" [1]. And third, the hierarchical
pattern second, it provides a number of directory names need not mirror exactly options for the domain part
assignment of
RFC822 mailbox identifiers, but can be structured names to support various
requirements directory leaf objects such as data partitioning and access control lists (ACLs)
based on person objects,
including an option that allows the naming hierarchy. reuse of existing Internet
identifiers for people.
Here, in summary, is our proposal.
For naming entries of leaf directory objects such as users, groups,
server applications and certification authorities in a hierarchical
directory (e.g., one accessed via LDAP, the Lightweight Directory
Access Protocol), we propose the use of the user identifier attribute
"uid" for the relative distinguished name. The value of this
attribute should be an RFC822 address, e.g.,
uid=John.Smith@acme.com
To address situations where it is inconvenient or inappropriate to use
an RFC822 mailbox identifier for a leaf directory object, we propose
the use of the conventional common name attribute, "cn".
The upper portions of the hierarchical directory tree should be
constructed using the components of registered DNS names using the
domain component attribute "dc". The directory name for the
organization having the domain name acme.com "acme.com" will then be, e.g.,
dc=acme, dc=com
Organizations can add additional directory structure, for example to
support implementation of access control lists or partitioning of
their directory information, by using registered subdomains of DNS
names, e.g.,
dc=corporate, dc=acme, dc=com
Directory distinguished names will thus have the following subdomain "corporate.acme.com" can be used as the
basis for the directory name
dc=corporate, dc=acme, dc=com
For naming directory leaf objects such as persons, groups, server
applications and certification authorities in a hierarchical
directory, we propose the use of either the "uid" (user identifier)
Grimstad, et al. [Page 2]
INTERNET-DRAFT Naming Plan August 1997
or the "cn" (common name) attribute for the relative distinguished
name. This plan does not constrain how these two attributes are used.
One approach to their use, for example, is to employ the uid
attribute as the RDN when reusing an existing store of identifiers
and the cn attribute as the RDN when creating new identifiers
specifically for the directory. A convenient existing identification
scheme for person objects is the RFC822 mailbox identifier. So an RDN
for person employing this store of identifiers would be, e.g.,
uid=John.Smith@acme.com
For leaf objects not conveniently identified with such a scheme, the
"cn" attribute is used, e.g.,
cn=Reading Room
Directory distinguished names will thus have the following structure,
e.g.,
uid=John.Smith@acme.com, dc=acme, dc=com
uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
cn=Reading Room, dc=physics, dc=national-lab, dc=edu
Searching the directory (for persons, or other similar objects) based
on exact matching of the uid attribute should be optimized in the
directory service such that it is essentially equivalent to searching
using a directory distinguished name.
External mechanisms can be used to locate the proper directory server
to query to obtain directory information.
2.0 THE PROBLEM The Problem
The X.500 Directory model [1] [2] can be used to create a world-wide
distributed directory. The Internet X.500 Directory Pilot has been
operational for several years and has grown to a size of about 1.5
million entries of varying quality. The rate of growth of the pilot
is far lower than the rate of growth of the Internet during the pilot
period.
There are a substantial number of contributing factors that have
inhibited the growth of this pilot. The common X.500 approach to
naming, while not the preponderant problem, has contributed in
several ways to limit the growth of an Internet White Pages Service
based on X.500.
2.1 Naming Problems
The conventional way to construct names in the X.500 community is
documented as an informative (i.e., not officially standardized)
Annex B to X.521. The relative distinguished name (RDN) of a user
consists of a common name (cn) attribute. This is meant to be what --
in the user's particular society -- is customarily understood to be
the name of that user. The distinguished name of a user is the
combination of the name of some general object, such as an
organization or a geographical unit, with the common name. There are
Grimstad, et al. [Page 3]
INTERNET-DRAFT Naming Plan August 1997
two main problems with this style of name construction.
First, the common name attribute, while seeming to be user-friendly,
cannot be used generally as an RDN in practice. In any significant
set of users to be named under the same Directory Information Tree
(DIT) node there will be collisions on common name. There is no way
to overcome this other than either by forcing uniqueness on common
names, something they do not possess, or by using an additional
attribute to prevent collisions. This additional attribute normally
needs to be unique in a much larger context to have any practical
value. The end result is a RDN that is very long and unpopular with
users.
Second, and more serious, X.500 has not been able to use any
significant number of pre-existing names. Since X.500 naming models
typically use organization names as part of the hierarchy [2, 3],
organization names must be registered. As organization names are
frequently tied to trademarks and are used in sales and promotions,
registration can be a difficult and acrimonious process.
The North American Directory Forum (NADF, now the North Atlantic
Directory Forum but still the NADF) proposed to avoid the problem of
registration by using names that were already registered in the
"civil naming infrastructure" [3]. [4][5]. Directory distinguished names
would be based on an organization's legal name as recognized by some
governmental agency (county clerk, state secretary of state, etc.) or
other registering entity such as ANSI.
This scheme has the significant advantage of keeping directory
service providers out of disputes about the right to use a particular
name, but it leads to rather obscure names. Among these obscurities,
the legal name almost invariably takes a form that is less familiar
and longer than what users typically associate with the organization.
For example, in the US a large proportion of legal organization names
end with the text ", Inc." as in "Acme, Inc." Moreover, in the case
of the US, the civil naming infrastructure does not operate
nationally, so the organization names it provides must be located
under state and regional DIT nodes, making them difficult to find
while browsing the directory. NADF proposes a way to algorithmically
derive multi-attribute RDNs which would allow placement of entries or
aliases in more convenient places in the DIT, but these derived names
are cumbersome and unpopular. For example, suppose Nadir is an
organization that is registered in New Jersey civil naming
infrastructure under the name "Nadir Networks, Inc." Its civil
distinguished name (DN) would then be
o="Nadir Networks, Inc.", st=New Jersey, c=US
Grimstad, et al. [Page 4]
INTERNET-DRAFT Naming Plan August 1997
while its derived name which is unambiguous under c=US directly is
o="Nadir Networks, Inc." + st=New Jersey, c=US
More generally, the requirement for registration of organizations in
X.500 naming has led to the establishment of national registration
authorities whose function is mainly limited to assignment of X.500
organization names. Because of the very limited attraction of X.500,
interest in registering an organization with one of these national
authorities has been minimal. Finally, multi-national organizations
are frustrated by a lack of an international registration authority.
2.2 Directory Models
The Internet community proposed the Light-weight Directory Access
Protocol (LDAP) [4], initially, as a simplified access method
3.0 Requirements
A directory naming plan must provide for
X.500 directories. However, more recently, a number names of different directory server implementations have begun to appear objects
that use LDAP as
an access protocol to backend retrieval systems not based on X.500.
The X.500 Directory, via its knowledge model, attempts to build are unambiguous (identify only one object) within some context,
at a
world-wide minimum within one isolated directory in a top-down fashion. This approach has only met
with partial success. server.
The appearance on the Internet following additional naming characteristics are requirements that
this naming plan seeks to satisfy:
a) hierarchical
The Internet, consisting of directory systems supporting LDAP
but not tied into the world a very large number of X.500 will, objects and
management domains, requires hierarchical names. Such names permit
delegation in our opinion, stimulate the creation name assignment process and partitioning of directories in a bottom-up fashion [5]. These
directory servers or information among directory islands will be loosely tied together
via LDAP referrals and other external mechanisms.
For such loosely coordinated mechanisms servers.
b) friendly to work effectively, a few loose coupling of
the general properties directory servers
One purpose of X.500 need to be retained. Among these are
(1) an approach this naming plan is to define a naming pattern that makes the linkage
will facilitate one form or another of the directory
islands as simple as possible, and (2) an extendible schema loose coupling of potentially
autonomous directory information with a widely accepted common base. The naming
plan described here supports these two characteristics.
2.3 Addressing the Problems
This paper describes servers into a directory naming plan that is larger system. A name in such a radical
departure from the traditional X.500 naming scheme -- the X.500 scheme
has not been generally accepted by the Internet community and has been
found to
system should unambiguously identify one real-world object. The
object may, however, be very clumsy represented differently (i.e. have different
attributes) in different (e.g. independently managed) servers in implementing and administering directory
services by the authors.
This naming
system. The plan is straightforward does not attempt to produce names to implement overcome this
likely scenario.
c) readily usable by both classic X.500
systems LDAP clients and islands servers
As of stand-alone LDAP servers. Its unique strength
lies in its use this writing, a substantial number of the existing Internet Lightweight Directory
Access Protocol (LDAP) [6][7] implementations are currently available
or soon will be. The names specified by this naming schemes -- RFC822
addresses [6] and the Domain Name System [7]. Further, plan should be
readily usable by use of an
attribute, the user ID attribute, these implementations and a tree structure applications based on the
DNS, the plan, if broadly implemented, may well simplify the
construction of external mechanisms
them.
d) friendly to locate appropriate LDAP
servers.
The focus re-use of existing Internet name registries
Grimstad, et al. [Page 5]
INTERNET-DRAFT Naming Plan August 1997
As described in Section 2 above, creation of new global name
registries has been highly problematic. Therefore, a fundamental
requirement this naming plan addresses is on naming Internet users,
certification authorities and server applications. It is not
applicable to resolving problems with naming objects such as X.500
residential persons which typically lack e-mail addresses. Because it
is a hierarchical plan using typed attribute values (tags), enable the naming
plan can co-exist with other hierarchical plans using other typed
attributes reuse of existing
Internet name registries such as a plan for residential persons DNS names and the conventional
X.521 Annex B plan.
3.0 TECHNOLOGICAL ASSUMPTIONS
We assume that the fundamental protocol interface to systems offering
general RFC822 mailbox
identifiers when constructing directory services names.
e) minimally user-friendly
Although we expect that user interfaces of directory-enabled
applications will avoid exposing users to DNs, it is unlikely that
users can be the TCP/IP-based Lightweight
Directory Access Protocol. Objects -- users, certification
authorities and server applications -- are named in totally insulated from them. For this protocol reason, the
naming plan should permit use of familiar information in name
construction. Minimally, a
hierarchical fashion and represented as described in RFC 1779 [8]. We
also assume that user authentication and other security services will
increasingly depend on public key cryptographic techniques such as
those used in should be capable of recognizing the Secure Sockets Layer (SSL) [9]. These techniques use
information such as certificates (certified public cryptographic keys) encoded in which objects his/her own DN. Names that are identified with directory names. totally opaque
to users cannot meet this requirement.
4.0 IDENTIFICATION Name Construction
The one universally accepted scheme of user identification (actually
user maildrop or mailbox identification) in paper assumes familiarity with the Internet today is terminology and concepts
behind the
RFC822 syntax for e-mail addresses. The RFC822 syntax contains a
domain terms distinguished name (DN) and a user identifier that is local to that domain. relative distinguished
name (RDN) [2][8][9].
We describe how DNs can be constructed using three attribute types,
domainComponent (dc), userID (uid) and commonName (cn). They are
each described in turn.
4.1 Domain Identification Component (dc)
The syntax of a domain identifier component attribute is defined by the Domain Name System
(DNS) and registered in RFC 1034 [6]. Examples RFC1274
[3][10]. It is used in the construction of such identifiers are acme.com and
foo.nj.us.
4.2 RFC822 Identification
The syntax a DN from a domain name.
Details of an RFC822 identifier is:
local@domain
where
"domain" the construction algorithm is described in "Using Domains
in LDAP Distinguished Names" [1].
An organization wishing to deploy a hierarchically structured identifier directory following this naming
plan would proceed as defined
by the DNS, and
"local" is follows. Consider an identifier organization, for a user (literally a maildrop)
that is valid within example
"Acme, Inc.", having the registered domain name "acme.com". It would
construct the DN
dc=acme, dc=com
from its domain "domain".
Examples name. It would then use this DN as the root of such identifiers are J.Smith@acme.com and
S.Johnson@corporate.acme.com.
Each user for whom information is maintained in its
subtree of directory information.
The DN itself can be used to identify a directory service
will typically have at least one e-mail address structured according organization object
that represents information about the organization. The directory
schema required to RFC822. While enable this is described below in section 5.2.
The subordinates of the user may well have many such addresses, one DN will be selected for directory objects related to the purpose
Grimstad, et al. [Page 6]
INTERNET-DRAFT Naming Plan August 1997
organization. The domain component attribute can be used to name
subdivisions of user identification. We call this the
"distinguished" e-mail address or the "distinguished" RFC822
identifier organization such as organizational units and
localities. Acme, for example, might use the user.
5.0 DIRECTORY DISTINGUISHED NAMES
5.1 Overview of Distinguished Names domain names
"corporate.acme.com" and "engineering.acme.com" to construct the
names
dc=corporate, dc=acme, dc=com
dc=engineering, dc=acme, dc=com
under which to place its directory objects. The general structure of a directory schema
required to name organizationalUnit and locality objects in LDAP, termed a distinguished name
(DN), is:
attribute, attribute, ... attribute
An "attribute" this way
is a pairing of a type identifier and a value separated
by "=". For example, cn=Samuel Johnson is an attribute with type
identifier "cn", short for common name, and value "Samuel Johnson".
The order of the attributes described below in a DN is significant. Like DNS
identifiers, DNs are hierarchical and "little endian", that is, the
most global piece comes last. An example section 5.2.
Use of a DN is:
cn=Samuel Johnson, o=Famous Lexicographers, c=GB
where:
cn=Samuel Johnson means the attribute type "cn" has the value
"Samuel Johnson",
o=Famous Lexicographers means that the attribute type "o", short
for organization name, has the value "Famous Lexicographers", and
c=GB means that the this attribute type "c", short for country name, has
the value "GB", the international abbreviation for the country
Great Britain.
The set RDN of all DNs forms a tree structure that is called the Directory
Information Tree (DIT).
5.2 Directory Distinguished Names
Suppose an organization, e.g., Acme, wants to bring up a directory
service. It either has a registered DNS name or it should get one.
Given a DNS name, we will use a form objects of DN construction largely based
on RFC1279 [10]. class
"domain" is also possible [1].
4.2 User ID (uid)
The userid (uid) attribute is defined and registered in RFC1274
[3][10].
This RFC shows how to map an RFC822 e-mail address attribute may be used to
a DN. We differ from it in two respects: (1) we use a mapping that
starts at the root of the DIT; and (2) we use construct the attribute type user
ID (userid or uid) RDN for directory objects
subordinate to objects named according to the first procedure described in
Section 4.1. This plan does not constrain how this attribute of the DN. is
used.
4.3 Common Name (cn)
The value of the
uid commonName (cn) attribute is a complete RFC822 address that defined and registered in X.500
[3][11].
This attribute may but need not be
related used to construct the DN of the parent entry.
The pattern for the organization's DN will be:
dc=A, ..., dc=Z
and the pattern RDN for directory objects
subordinate to objects named according to the DN of a user procedure described in that organization will be:
uid=RFC822 identifier, dc=A, ..., dc=Z
We consider each
Section 4.1. This plan does not constrain how this attribute is
used.
4.4 Examples of uid and cn Usage
Although this plan places no constraints on the two attribute types, dc use of the uid and uid, used cn
attributes for name construction, we would like to form offer some
suggestions by way of examples.
In practice, we have used uid for the DN in turn.
5.2.1 Domain Component (dc)
The domain component attribute is defined RDN for person objects were we
could make use of an existing registry of names and registered in RFC1274
[2].
The domain component attributes cn for other
objects.
Examples of existing registries of identifiers for person objects are
RFC822 mailbox identifiers, employee numbers and employee "handles".
Grimstad, et al. [Page 7]
INTERNET-DRAFT Naming Plan August 1997
Aside from the convenience to administrators of re-use of an existing
store of identifiers, if it is ever necessary to display to a organization's DN user
his/her DN, there is some hope that it will normally be
constructed from the domain recognizable when such
identifiers are used.
We have found RFC822 mailbox identifiers a particularly convenient
source for name construction. When a person has several e-mail
addresses, one will be selected for the purpose of that organization. That is, user
identification. We call this the "distinguished" e-mail address or
the "distinguished" RFC822 mailbox identifier for the
organization "Acme, Inc." user.
For example, if there is a user affiliated with domain name "acme.com", the DN organization Acme
having distinguished e-mail address J.Smith@acme.com, the uid
attribute will be
dc=acme, dc=com be:
uid=J.Smith@acme.com
The domain component attributes of a user's DN will normally be
constructed from the domain name of his/her distinguished e-mail
address. That is, for the user uid=J.Smith@acme.com the domain
component attributes would typically be:
dc=acme, dc=com
The full LDAP DN for this user would then be:
uid=J.Smith@acme.com, dc=acme, dc=com
The algorithm for
Directory administrators having several RFC822 identifiers to choose
from when constructing the uid part of the a DN is given in section
5.2.2.
It is important to emphasize that the elements of for a user should consider the domain name following
factors:
o Machine-independent addresses are likely to be more stable,
resulting in directory names that change less. Thus an
identifier
such as:
js@acme.com
may well be preferable to one such as:
js@blaster.third-floor.acme.com.
o Use of some form of "handle" for the "local" part that is
distinct from a user's real name may result in fewer collisions
and thereby lessen user pain and suffering. Thus the
identifier:
Grimstad, et al. [Page 8]
INTERNET-DRAFT Naming Plan August 1997
js@acme.com
may well be preferable to one such as:
J.Smith@acme.com
Practical experience with use of the RFC822 mailbox identifier scheme
described here has shown that there are situations where it is
convenient to use such identifies for all users in a particular
population, although a few users do not, in fact, possess working
mailboxes. For example, an organization may have a existing unique
identification scheme for all employees that is used as a alias to
the employees' real mailboxes -- which may be quite heterogeneous in
structure. The identification scheme works for all employees to
identify unambiguously each employee; it only works as an e-mail
alias for those employees having real mailboxes. For this reason it
would be a bad assumption for directory-enabled applications to
assume the uid to be a valid mailbox; the value(s) of the mail
attribute should always be checked.
It is important to emphasize that the elements of the domain name of
an RFC822 identifier may, BUT NEED NOT, be the same as the domain
components of the DN. This means that the domain components provide
a degree of freedom to support access control or other directory
structuring requirements that need not be mechanically reflected in
the user's e-mail address. We do not want under any condition to
force the user's e-mail address to change just to facilitate a new
system requirement such as a modification in an access control
structure. It should also be noted that while we do not require that
the domain components match the RFC822 identifier, we DO require that
the concatenated domain components form a registered domain name,
that is, one that is represented in the DNS. This automatically
avoids name conflicts in the directory hierarchy.
To provide an example of a DN which deviates from what might be
considered the default structure, consider the following scenario.
Suppose that J.Smith needs to be granted special permissions to
information in the dc=acme, dc=com part of the LDAP DIT. Since it
will be, in general, easier to organize special users by their name
structure than via groups (an arbitrary collection of DNs), we use
subdomains for this purpose. Suppose the special permissions were
required by users in the MIS organizational unit. A subdomain
"mis.acme.com" is established, if it does not already exist,
according to normal DNS procedures. The special permissions will be
granted to users with the name structure:
uid=*, dc=mis, dc=acme, dc=com
Grimstad, et al. [Page 9]
INTERNET-DRAFT Naming Plan August 1997
The DN of J.Smith in this case will be:
uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
In principal, there is nothing to prevent the domain name elements of
the RFC822 identifier from being completely different from the domain
components of the DN. For instance, the DN for a J.Smith could be:
uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
While we do not REQUIRE that the domain name part of the uid match
the dc components of the directory distinguished name, we suggest
that this be done where possible. At a minimum, if the most
significant pieces of
the DN and the uid are the same (i.e., "dc=acme, dc=com" and
"acme.com") the likelihood, based on a knowledge of a user's e-mail
address, of discovering an appropriate directory system to contact to
find information about the user is greatly enhanced.
The example above represents a situation where this suggestion isn't
possible because some of the users in a population have mailbox
identifiers that differ from the pattern of the rest of the users,
e.g., most mailboxes are of the form local@acme.com, but a
subpopulation have mailboxes from an ISP and therefore mailboxes of
the form local@worldnet.att.net.
5.2.2 User ID (uid)
The userid (uid) attribute is defined and registered in RFC1274 [2].
The value of the user ID attribute for the user's name will be the
user's distinguished e-mail address in RFC822 syntax. For example, if
there is a user affiliated with the organization Acme having
distinguished e-mail address J.Smith@acme.com, the uid attribute will
be:
uid=J.Smith@acme.com
We strongly suggest that uid=J.Smith@acme.com to be a working e-mail
address. The whole idea here is that users will remember a working
e-mail address; we shouldn't plague them with broken RFC822 addresses
constructed for the convenience of the directory service only. The A
or MX record for the domain name can point to either a customer or
network service provider host.
Since an RFC822 identifier unambiguously identifies a user, it can be
used (by system processes) to search a particular directory system
(e.g. an LDAP server or a related set of LDAP servers) to find a user's
entry. The user need not -- and we assume typically will not -- even
know his/her DN. See Section 8.1.
Directory administrators having several RFC822 identifiers to choose
from when constructing a DN for a user should consider the following
factors:
o Machine-independent addresses are likely to be more stable,
resulting in directory names that change less. Thus an identifier
such as:
js@acme.com
may well be preferable to one such as:
js@blaster.third-floor.acme.com.
o Use of some form of "handle" for the "local" part that is distinct
from a user's real name may result in fewer collisions and
thereby lessen user pain and suffering. Thus the identifier:
js@acme.com
may well be preferable to one such as:
J.Smith@acme.com
Practical experience with use of the RFC822 mailbox identifier scheme
described here has shown that there are situations where it is
convenient to use such identifies for all users in a particular
population, although a few users do not, in fact, possess working
mailboxes. For example, an organization may have a existing unique
identification scheme for all employees that is used as a alias to the
employees' real mailboxes -- which may be quite heterogeneous in
structure. The identification scheme works for all employees to
identify unambiguously each employee; it only works as an e-mail alias
for those employees having real mailboxes. For this reason it would
be a bad assumption for directory-enabled applications to use the uid
as a mailbox; the value(s) of the mail attribute should always be
checked.
5.2.3 Common Name
To address situations where it is inconvenient or inappropriate to use
an RFC822 mailbox identifier for the RDN of a leaf directory object,
we propose the use of the conventional common name attribute, "cn".
As an example of the assignment of a DN to a directory object for
which the creation of a uid would be cumbersome, consider naming an
object of class room, specified in 8.3.5 of the COSINE and Internet
X.500 Schema [2]. For example, the following name might be more
natural for the directory administrator to assign and for applications
using this sort of object to use:
cn=Reading Room, dc=physics, dc=national-lab, dc=edu
In certain environments, especially where there are a relatively small
number of users requiring DNs, that is, where name collisions of the
common name will not happen, it may be convenient to use the
traditional X.500 common name attribute as in:
cn=John Smith, dc=mis, dc=acme, dc=com
6.0 NAMING FOR CERTIFICATES
The certified public keys, certificates, used in SSL and other forms of
strong (i.e. cryptographically based) authentication are structured
according to the ITU X.509 standard. A certificate contains two names
of importance, the name of the "subject" and the "issuer". The subject
will be either a user or a server; the issuer will be a certification
authority. The encoding of these names differs significantly from the
encoding of LDAP names which are simply character strings. In
particular, the attribute types used in names are encoded as globally
unique "object identifiers." The object identifiers relevant to the
names considered in this naming plan are assigned in either the X.500
standards (ITU X.520) or RFC1274, the COSINE and Internet X.500 Schema
[2].
6.1 User Certificates
For user certificates issued by a certification authority, the subject
name will be the proper X.509 representation of the user hierarchical
DNs described in section 5 of this paper.
6.2 Server/Site Certificates
As certificates are used more and more for authentication, applications
that run as processes on systems need to be named so that they can also
be located in the directory. Since the name of the subject is encoded
in a certificate, for application instances to be portable, we need a
naming scheme that is independent of the underlying hardware platform
and its IP address or DNS host name.
In existing Internet products that use certificates, the terms "Server
Certificate" and "Site Certificate" have been (mis-)used to identify
application instances.
We propose that application instances be named similar to individuals
as entities under a specific branch of the DIT and be given appropriate
unique RFC822 identifiers. The RFC822 identifier so chosen is not
constrained by the naming plan. As illustrated in the three examples
below, it can be either host-independent (1,2) or host dependent (3).
If host-independent, it can be based on a subdomain (2) of the
organization's domain name or, if such registration is convenient,
based on the domain name (1) itself.
A few examples of application instance names are:
uid=dirsrv0@acme.com, dc=sales, dc=acme, dc=com (1)
uid=certsrv0@sales.acme.com, dc=sales, dc=acme, dc=com (2)
uid=gnarlysrv0@surf.sales.acme.com, dc=sales, dc=acme, dc=com (3)
This name is used in the construction of the server's certificate.
A consequence of this method of constructing names is that application
instances have mailboxes. This can be thought of as an opportunity to
provide users with a predictable contact for resolution of operational
problems with the application much like postmaster@DOMAIN is the
predictable contact for e-mail problems at DOMAIN.
To address situations where it is inconvenient or inappropriate to use
an RFC822 mailbox identifier for the RDN of an application instance,
we propose the use of the conventional common name attribute, "cn".
6.3 Certification Authority Certificates
A certification authority (CA) is the trusted guarantor for a user or
server certificate. The CA's name appears in the "issuer" field of the
certificate it issues. The names of several CAs are already built into
popular Internet Web browsers such as the Netscape Navigator and the
Microsoft Internet Explorer. Some examples of such CA names are:
ou=Directory Services, o=AT&T, c=US
ou=Secure Server Certification Authority, o="RSA Data Security, Inc.",
c=US
These names use the traditional X.500 attributes for naming. These
attributes are organizational unit name (ou), organization name (o)
and country name (c). To maintain compatibility, the appropriate CAs
can be incorporated in any LDAP-based directory service with these
existing names.
In future, new certification authorities may be assigned names
following the structure described in section 5 of this
document. Examples of such new CA names are:
uid=certification-authority@CAs-R-us.com, dc=CAs-R-us, dc=com
cn=certification authority, dc=CAs-R-us, dc=com
dc=certification-authority, dc=CAs-R-us, dc=com
7.0 OTHER DIRECTORY OBJECTS
This subsection of the naming plan is concerned with other
miscellaneous directory objects for which a regular naming structure
is required. This collection of objects consists, at this point, only
of groups. Other documents may define the naming plans for representing
other kinds of objects in the directory.
7.1 Groups
A group is a directory object, and therefore has a directory name. It
expresses membership of other directory objects in a set. Examples of
groups are: a set of users permitted to modify the entries in a
subtree of the DIT; a set of users permitted to view a related set of
web pages; and a set of e-mail recipients interested in a particular
subject. Note that the latter example is, from a UNIX-centric
perspective, at this point a hypothetical directory oriented
example. In practice, groups in the UNIX-centric part of e-mail world,
more commonly termed mailing lists, are not represented by directory
group entries and members of the group are identified by an e-mail
address rather than a directory name.
Group objects in the directory are named following the same structure
as users and servers: the RDN of the object uses a uid attribute value
and the group object is placed under an appropriate domain object. As
in the case of users and servers, the uid attribute value must be a
valid RFC822 mailbox identifier. There is no particular requirement
and, in fact, it might even be undesirable, that e-mail sent to this
mailbox should be exploded to the mailboxes of the members of the group.
On the other hand, it might well be convenient that the uid used as
the RDN of a group object be the mailbox of a list rather than an
individual.
For example, suppose the directory administrators for the dc=acme,
dc=com subtree of the DIT have set up an e-mail list
ds-admin@acme.com. It might be convenient to create a directory group
with the name
uid=ds-admin@acme.com, dc=acme, dc=com
for the construction of access control lists in the acme subtree,
granting members of this list modification permissions on all the
entries. In this case e-mail sent to ds-admin@acme.com would typically
go, in a UNIX-centric environment, not to the members of the directory
group as defined by the attribute of the group's entry that identifies
the members, but to the list of mailboxes exploded at the host
acme.com.
To address situations where it is inconvenient or inappropriate to use
an RFC822 mailbox identifier for the RDN of a group object, we propose
the use of the conventional common name attribute, "cn".
8.0 IMPLEMENTATION ISSUES
8.1 Directory Services Considerations
This naming plan has been designed so that a user's entry can be found
unambiguously using nothing but the user's distinguished e-mail address --
assuming that the query is sent to the right LDAP directory server.
Systems having the user's DN in hand can, of course, directly access
the user's entry via LDAP.
An LDAP search request with the following components will either (1)
find uniquely the entry of a user with the provided distinguished
e-mail address, or (2) indicate that no user has the provided e-mail
address as a distinguished e-mail address:
baseObject: root
scope: wholeSubtree
filter: equalityMatch (uid == distinguished e-mail address)
A search such as this is possible in LDAP servers being planned
because, unlike X.500 servers, the LDAP servers we envision are not
universally interconnected in one global system according to the X.500
knowledge model. In X.500 such a search would propagate to all the
servers in the system; in the envisioned LDAP system it would be
limited to one server (or potentially a small set of servers).
In a world of LDAP islands, the issue of finding the right island to
which to direct a directory query arises. The new version of LDAP
under design in the IETF [11] has a referral mechanism. Given a query,
a server can return a referral to an other LDAP server that might hold
the data. This approach can be used to tie together the servers holding
the distributed data of an LDAP island. By generalizing this concept
one can imagine building a simple referral server that knows about the
LDAP islands of the Internet. It would compare the naming information
in a query it receives with its knowledge of LDAP islands and return a
referral to the appropriate island.
It has been traditional in X.500 and LDAP directory services to employ
the common name (cn) attribute in naming. While this naming plan
doesn't require use of the cn attribute in naming, it should be
stressed that it is still quite important. It will play a significant
role in enabling searches to find user entries of interest. To this
end, what is typically done is to have multiple values of the common
name attribute in the user's entry. Thus the entry for
J.Smith@acme.com might well have the common name attribute values
"John Smith", "John Q. Smith" and "John Quincy Smith" to optimize
matching of search requests.
The attribute rfc822mailbox (or mail) is normally used to hold a user's
e-mail address in X.500 and LDAP directory services. A user with
multiple e-mail addresses will not be assigned multiple DNs simply
because of the multiple addresses. As described above, one of these
e-mail addresses -- a machine-independent and fairly static one -- will
be elected the distinguished e-mail address and used to construct the
DN. If it is desirable to make available the other e-mail addresses,
they can be stored in the user's rfc822mailbox attribute. It is
technically possible, although undesirable because potentially
confusing, that the rfc822mailbox attribute does NOT contain the
distinguished e-mail address as one of its values.
An important matter for directory administrators to consider with
respect to the use of RFC822 mailbox identifiers is that it is
possible to construct more than one DN using the same mailbox
identifier as the RDN. This may or may not have undesirable
consequences, depending on the expectations of specific applications
accessing the directory. The safest practice is probably to avoid such
multiple use of the same mailbox identifier.
Another less safe alternative might be to only permit such multiple
use in cases where the directory objects with the same uid as the RDN
have different base object classes. This would permit applications --
which would need to be aware of this nuance -- to find objects based
on searches for specific uid values to distinguish between meaningful
and non-meaningful directory objects.
Consider the following example. Suppose two directory objects were to
be created by Acme,
uid=ds-dsadmin@acme.com, dc=engr, dc=acme, dc=com (1)
and
uid=ds-admin@acme.com, dc=acme, dc=com (2).
The first object represents an administrative user and is of object
class organizational role. The second represents a group and
represents a list of objects (expressed by the values of the member
attribute) who have been granted some form of administrative
permission. An application wishing to determine the group members and
knowing only the uid value "ds-admin@acme.com" might experience
problems if it naively expected expected the first match found under
dc=acme, dc=com to contain a member attribute.
8.2 Alternative DN Structures
Some organizations may wish to be represented by a scheme based upon a
more classic X.500/NADF naming system [12]. These organizations can be
accommodated in the scheme without significant problems or naming
conflicts.
The approach we take should not preclude participation in a larger
directory service, so names held in the stand-alone LDAP directory
shouldn't collide unnecessarily with names held by other directory
service operators. (If two directory service providers hold
information with respect to pieces of the same DN, these DN and the uid are two different views
of the same real world object, not two unrelated objects that
accidentally share a "name.") Naming (i.e.,
"dc=acme, dc=com" and "acme.com") the likelihood, based on DNS meets this
criterion. Disciplined use of X.500 naming can also meet this
criterion.
To enable a consistent searching strategy in
knowledge of a user's e-mail address, of discovering an appropriate
directory where objects
named according system to the plan described here as well as the classic
X.500/NADF naming system, we strongly recommend contact to find information about the user ID (uid)
attribute, although not part is
greatly enhanced.
The example above represents a situation where this suggestion isn't
possible because some of the DN, have users in a valid RFC822 identifier
for population have mailbox
identifiers that differ from the user. The LDAP DIT structure will follow pattern of the typical
X.500/NADF approach as follows.
Organizations wishing to pursue this approach will need to register
their organization's name with rest of the appropriate authority as generally
accepted in users,
e.g., most mailboxes are of the X.500/NADF community. This means that US organizations
will register with ANSI. The resort form local@acme.com, but a
subpopulation have mailboxes from an ISP and therefore mailboxes of
the form local@worldnet.att.net.
5.0 Implementation Issues
5.1 Directory Services Considerations
We envision the deployment of LDAP-based directory services on the
Internet to take the civil naming
infrastructure form of states and counties should be actively
discouraged. There may be cases where this sort LDAP servers loosely connected into
islands by means of name construction
can make sense, so no absolute prohibition is made here. The names
constructed from LDAP referral [12] information configured into
the servers. By generalizing this civil naming infrastructure (a la NADF), while
meeting concept one can imagine building a
simple referral server that knows about the technical criteria for non-ambiguity LDAP islands of the
Internet. It would compare the naming or search information in a
query it receives with its knowledge of LDAP islands and right return a
referral to use, are
typically long and unwieldy.
Suppose the US company "XYZ Widgets" expressed appropriate island.
We do not envision the X.500 model of a wish single DIT to follow this
approach. A typical user name might be
uid=J.User@xyzwidgets.com, o="XYZ Widgets, Inc.", c=US
where o="XYZ Widgets, Inc.", c=US is viable in an ANSI registered name. (The
"alphanumeric string" registered with ANSI is 'XYZ Widgets, Inc.',
where the single quotes mark off what is registered but are not part
environment of
the registered information.)
To support structured access control within the company, the analogous
form competing service providers. This naming plan does
not attempt to produce names to hide the registration of possibility that a subdomain given DN
may have independently managed entries associated with it. Referral
servers such as those envisioned in the mainline approach is the
creation of an organizational unit node.
8.3 previous paragraph can help
to deal with this situation: a) first, because referrals are
expressed as LDAP URLs [13] which can identify both a host server and
a DN; and b) second, because referrals can be multi-valued. Future
LDAP v3 clients can be expected to support such referrals.
Grimstad, et al. [Page 10]
INTERNET-DRAFT Naming Plan August 1997
5.2 Directory Schema Implications of the Naming Plan
The traditional directory schema(s) developed for the X.500 standard
and its application to the Internet [3] [4] require extension to be used
with the naming plan developed here. The extensions described below
attempt to reuse existing schema elements as much as possible. The
directory objects for which extensions are required are:
organization, organizational unit, ca, server (application) and group. various classes of leaf
objects. We describe the schema modifications below for organization,
organizationalUnit and selected leaf classes.
So as to continue to use existing structural object classes to the
extent possible, we propose supplementing entries based on these
classes with additional information from two new auxiliary object
classes, dcObject and uidObject. They are specified using the
notation in Section 4 of [14].
The auxiliary object class dcObject is defined as:
name: dcObject
requires: dc in "Using Domains in
LDAP Distinguished Names" [1].
The auxiliary object class uidObject is defined as:
name: uidObject
requires:
( OID-TBD NAME 'uidObject' SUP top AUXILIARY MUST uid )
In a pure X.500 context, our schema would also require the definition
of new name forms and structure rules. These concepts are not
required, however, for the specification of LDAP schemas.
8.3.1
5.2.1 Organization Schema
The dc attribute is employed to construct the RDN of an organization
object. This is enabled by adding the auxiliary class dcObject to
the organization's objectClass attribute.
8.3.2
5.2.2 Organizational Unit Schema
The dc attribute is employed to construct the RDN of an
organizationalUnit object (which is subordinate in the DIT to either
an organization or an organizationalUnit object). This is enabled by
adding the auxiliary class dcObject to the organizational unit's
objectClass attribute.
8.3.3
5.2.3 Person Schema
No schema extensions are required for person objects if either the
inetOrgPerson [15] (preferred) or the newPilotPerson object classes
are used. The attribute uid uid is permissible in each class. For
consistency, the uidObject could be added to person entry objectClass
Grimstad, et al. [Page 11]
INTERNET-DRAFT Naming Plan August 1997
attributes to assist applications filtering on this attribute. Use of
other classes for person objects with RDN constructed with the uid
attribute such as organizationalPerson requires the use of the
uidObject class.
It has been traditional in X.500 and LDAP directory services to
employ the common name (cn) attribute in naming. While this naming
plan doesn't require use of the cn attribute in naming, it should be
stressed that it is permissible a required attribute in each class. For consistency, any class derived from
the uidObject could be added to person entry objectClass attributes class and is still quite important. It will play a
significant role in enabling searches to assist applications filtering on this attribute.
8.3.4 find user entries of
interest.
5.2.4 Certification Authority Schema
The certification authority (CA) object class is an auxiliary class,
meaning it is essentially a set of additional attributes for a base
class such as organizationalRole, organization, organizationalUnit or
person. Except in the case where the base structural class is
inetOrgPerson, use of the uid attribute to construct the RDN of a CA
will require the auxiliary class uidObject to permit the uid
attribute to be used. In the cases where organizationalUnit or
organization is the base class for a CA, use of the auxiliary class
dcObject will permit the RDN of the CA to be a domain component.
8.3.5
5.2.5 Server and Server Application Schema
Server
Servers and server applications are typically represented represented, for want
of anything better, by entries of the object class applicationProcess
(or a class derived from it). Sometimes the class applicationEntity
is used. In either case, the uid attribute
may should probably not be
employed to construct the RDN of a server or server application
object.
This is enabled by adding The standard schema uses the auxiliary class uidObject attribute cn for such RDNs.
Suppose one wants to use this naming plan both in the construction of
DNs for SSL server
application's objectClass attribute.
8.3.6 Group certificates and for their storage in a directory.
It is customary for clients connecting via SSL to compare the
server's domain name (e.g. from the URL used to contact the server)
with the value of Names Schema
The uid the cn attribute in the subject field (i.e.
subject's DN) of the server's certificate. For this reason, it is
common practice to set the cn attribute to the server's domain name.
The naming and schema to handle this situation is best explained by
an example. Consider the server "host.acme.com". Following the
algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
dc=host, dc=acme, dc=com is constructed. To conform to the existing
practices just described, the server's subject DN for the SSL server
Grimstad, et al. [Page 12]
INTERNET-DRAFT Naming Plan August 1997
certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
the server's certificate should be stored in a directory entry with
this name. This entry should use application process or application
entity as its structural object class and strong authentication user
as is auxiliary class.
6.0 Security Considerations
Although access controls may be placed on portions of the DIT to deny
browse access to unauthorized clients, it may be employed possible to construct the RDN infer
directory names and DIT structure in such sensitive portions of a groupOfNames
object. This is enabled by adding the auxiliary class uidObject to
DIT from the
groupOfNames' objectClass attribute.
9.0 SECURITY CONSIDERATIONS
Security considerations are not part results of this paper.
10.0 ACKNOWLEDGMENTS DNS queries. Providing public visibility to
some portions of the DIT may assist those make such inferences.
7.0 Acknowledgments
This plan has emerged in the course of a number of fruitful
discussions, especially with David Chadwick, John Dale, Joe Gajewski,
Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
11.0 REFERENCES
8.0 References
[1] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
"Using Domains in LDAP Distinguished Names", Internet
Draft <draft-ietf-asid-ldap-domains-02.txt>, August
1997.
[2] X.500: The Directory -- Overview of Concepts, Models, and
Service, CCITT Recommendation X.500, December, 1988.
[2] P.Barker,
[3] P. Barker, and S. Kille, "The COSINE and Internet X.500
Schema", RFC1274, 11/27/1991.
[3]
[4] The North American Directory Forum, "A Naming Scheme for
c=US", RFC1255, September 1991.
[4]
[5] The North American Directory Forum, "NADF Standing Documents:
A Brief Overview", RFC 1417, The North American Directory
Forum", NADF, February 1993.
[6] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory
Access Protocol", RFC1777, 03/28/1995. (Work is also underway in the
IETF to produce an extended version of LDAP.)
[5] J. Postel, and C. Anderson, "White Pages Meeting Report",
RFC1588, February 1994.
[6] P. Mockapetris, "Domain names - concepts and facilities",
RFC1034.
[7] D. Crocker, "Standard for the format of ARPA M. Wahl, T. Howes, and S. Kille, "Lightweight Directory
Access Protocol (v3)", Internet text
messages", RFC822. Draft <draft-ietf-asid-
ldapv3-protocol-04.txt>, March 1997.
Grimstad, et al. [Page 13]
INTERNET-DRAFT Naming Plan August 1997
[8] S. Kille, "A String Representation of Distinguished Names",
RFC1779, 03/28/1995.
[9] A. Freier, P. Karlton, and P. Kocher, "The SSL M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol Version
3.0", Work (v3): UTF-8 String Representation of Distinguished
Names", Internet Draft <draft-ietf-asid-ldapv3-dn-03.txt>,
April, 1997.
[10] M. Wahl, "A Summary of the Pilot X.500 Schema for use in Progress,
LDAPv3", Internet Draft
<draft-freier-ssl-version3-01.txt>, <draft-ietf-asid-schema-pilot-
00.txt>, March 1996.
[10] S. Kille, "X.500 and Domains", RFC1279, 11/27/1991. 1997.
[11] M. Wahl, "A Summary of the X.500 User Schema for use with
LDAPv3", Internet Draft <draft-ietf-asid-ldapv3schema-x500
01.txt>, July 1997.
[12] T. Howes, M. Wahl, "Referrals and Knowledge References in
LDAP Directories", Internet Draft, <draft-ietf-asid-ldapv3-
referral-00.txt>, May 1997.
[13] T. Howes, M. Smith, "The LDAP URL Format", Internet Draft,
<draft-ietf-asid-ldapv3-url-04.txt>, August 1997.
[14] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3)", Work in Progress, (v3): Attribute Syntax
Definitions", Internet Draft
<draft-ietf-asid-ldapv3-protocol-04.txt>, February 17, <draft-ietf-asid-ldapv3-
attributes-07.txt>, August 1997.
[15] M. Smith, "Definition of the inetOrgPerson Object Class",
Internet Draft <draft-ietf-asid-inetorgperson-01.txt>,
July 1997.
[12] The North American Directory Forum, "NADF Standing Documents: A
Brief Overview", RFC 1417, The North American Directory Forum",
NADF, February 1993.
12. Authors' Addresses
Al Grimstad
AT&T
Room 1C-429, 101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
EMail: alg@att.com
Rick Huber
AT&T
Room 1B-433, 101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Grimstad, et al. [Page 14]
INTERNET-DRAFT Naming Plan August 1997
EMail: rvh@att.com
Sri Sataluri
AT&T
Room 4G-202, 101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
EMail: sri@att.com
Steve Kille
Isode Limited
The Dome, The Square
Richmond
TW9 1DT
UK
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
Mark Wahl
Critical Angle Inc.
4815 W Braker Lane #502-385
Austin, TX 78759
USA
EMail: M.Wahl@critical-angle.com
Grimstad, et al. [Page 15]
----