IDS Working Group Al Grimstad INTERNET-DRAFT Rick Huber Sri Sataluri AT&T Steve Kille Isode Ltd. Mark Wahl Critical Angle Inc. March 12, 1997 Naming Plan for an Internet Directory Service Filename: draft-ietf-ids-dirnaming-01.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, in the experience of the authors, proven to be an obstacle to the creation of directory services. 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 the problems encountered by those using the conventional recommended X.500 approach to naming. 1.0 EXECUTIVE SUMMARY The conventional approach to naming taken by the X.500 community has, in the experience of the authors, shown itself to be an obstacle to the creation of directory services. 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. This paper describes an alternative directory naming plan for the construction of the Internet White Pages Service (IWPS) and other directory-enabled applications. It has three main features. First, it bases directory name construction 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 plan use existing standardized directory attributes and can co-exist with names constructed according to traditional X.500 naming practices. And third, the hierarchical pattern of directory names need not mirror exactly the domain part of RFC822 mailbox identifiers, but can be structured to support various requirements such as data partitioning and access control lists (ACLs) based on the naming hierarchy. 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 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 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 X.500 Directory model [1] 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 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]. 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 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 for X.500 directories. However, more recently, a number of different directory server implementations have begun to appear 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 a world-wide directory in a top-down fashion. This approach has only met with partial success. The appearance on the Internet of directory systems supporting LDAP but not tied into the world of X.500 will, in our opinion, stimulate the creation of directories in a bottom-up fashion [5]. These directory servers or directory islands will be loosely tied together via LDAP referrals and other external mechanisms. For such loosely coordinated mechanisms to work effectively, a few of the general properties of X.500 need to be retained. Among these are (1) an approach to naming that makes the linkage of the directory islands as simple as possible, and (2) an extendible schema of 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 a directory naming plan that is 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 be very clumsy in implementing and administering directory services by the authors. This naming plan is straightforward to implement by both classic X.500 systems and islands of stand-alone LDAP servers. Its unique strength lies in its use of the existing Internet naming schemes -- RFC822 addresses [6] and the Domain Name System [7]. Further, by use of an attribute, the user ID attribute, and a tree structure based on the DNS, the plan, if broadly implemented, may well simplify the construction of external mechanisms to locate appropriate LDAP servers. The focus of this naming plan 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), the naming plan can co-exist with other hierarchical plans using other typed attributes such as a plan for residential persons and the conventional X.521 Annex B plan. 3.0 TECHNOLOGICAL ASSUMPTIONS We assume that the fundamental protocol interface to systems offering general directory services will be the TCP/IP-based Lightweight Directory Access Protocol. Objects -- users, certification authorities and server applications -- are named in this protocol in 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 the Secure Sockets Layer (SSL) [9]. These techniques use information such as certificates (certified public cryptographic keys) in which objects are identified with directory names. 4.0 IDENTIFICATION The one universally accepted scheme of user identification (actually user maildrop or mailbox identification) in the Internet today is the RFC822 syntax for e-mail addresses. The RFC822 syntax contains a domain name and a user identifier that is local to that domain. 4.1 Domain Identification The syntax of a domain identifier is defined by the Domain Name System (DNS) in RFC 1034 [6]. Examples of such identifiers are acme.com and foo.nj.us. 4.2 RFC822 Identification The syntax of an RFC822 identifier is: local@domain where "domain" is a hierarchically structured identifier as defined by the DNS, and "local" is an identifier for a user (literally a maildrop) that is valid within the domain "domain". Examples of such identifiers are J.Smith@acme.com and S.Johnson@corporate.acme.com. Each user for whom information is maintained in a directory service will typically have at least one e-mail address structured according to RFC822. While the user may well have many such addresses, one will be selected for the purpose of user identification. We call this the "distinguished" e-mail address or the "distinguished" RFC822 identifier for the user. 5.0 DIRECTORY DISTINGUISHED NAMES 5.1 Overview of Distinguished Names The general structure of a name in LDAP, termed a distinguished name (DN), is: attribute, attribute, ... attribute An "attribute" 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 in a DN is significant. Like DNS identifiers, DNs are hierarchical and "little endian", that is, the most global piece comes last. An example 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 attribute type "c", short for country name, has the value "GB", the international abbreviation for the country Great Britain. The set 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 of DN construction largely based on RFC1279 [10]. This RFC shows how to map an RFC822 e-mail address 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 the attribute type user ID (userid or uid) for the first attribute of the DN. The value of the uid attribute is a complete RFC822 address that may but need not be related to the DN of the parent entry. The pattern for the organization's DN will be: dc=A, ..., dc=Z and the pattern for the DN of a user in that organization will be: uid=RFC822 identifier, dc=A, ..., dc=Z We consider each of the two attribute types, dc and uid, used to form the DN in turn. 5.2.1 Domain Component (dc) The domain component attribute is defined and registered in RFC1274 [2]. The domain component attributes of a organization's DN will normally be constructed from the domain name of that organization. That is, for the organization "Acme, Inc." with domain name "acme.com", the DN will be dc=acme, dc=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 constructing the uid part of the DN is given in section 5.2.2. 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 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 the same DN, these are two different views of the same real world object, not two unrelated objects that accidentally share a "name.") Naming based on DNS meets this criterion. Disciplined use of X.500 naming can also meet this criterion. To enable a consistent searching strategy in a directory where objects named according to the plan described here as well as the classic X.500/NADF naming system, we strongly recommend the user ID (uid) attribute, although not part of the DN, have a valid RFC822 identifier for the user. The LDAP DIT structure will follow the typical X.500/NADF approach as follows. Organizations wishing to pursue this approach will need to register their organization's name with the appropriate authority as generally accepted in the X.500/NADF community. This means that US organizations will register with ANSI. The resort to the civil naming infrastructure of states and counties should be actively discouraged. There may be cases where this sort of name construction can make sense, so no absolute prohibition is made here. The names constructed from this civil naming infrastructure (a la NADF), while meeting the technical criteria for non-ambiguity and right to use, are typically long and unwieldy. Suppose the US company "XYZ Widgets" expressed a wish 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 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 of the registered information.) To support structured access control within the company, the analogous form to the registration of a subdomain in the mainline approach is the creation of an organizational unit node. 8.3 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] 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. 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. The auxiliary object class dcObject is defined as: name: dcObject requires: dc The auxiliary object class uidObject is defined as: name: uidObject requires: 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 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 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 Person Schema No schema extensions are required for person objects if either the inetOrgPerson (preferred) or the newPilotPerson object classes are used. The attribute uid is permissible in each class. For consistency, the uidObject could be added to person entry objectClass attributes to assist applications filtering on this attribute. 8.3.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 Server Application Schema Server applications are typically represented 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 be employed to construct the RDN of a server application object. This is enabled by adding the auxiliary class uidObject to the server application's objectClass attribute. 8.3.6 Group of Names Schema The uid attribute may be employed to construct the RDN of a groupOfNames object. This is enabled by adding the auxiliary class uidObject to the groupOfNames' objectClass attribute. 9.0 SECURITY CONSIDERATIONS Security considerations are not part of this paper. 10.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 [1] X.500: The Directory -- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988. [2] P.Barker, and S. Kille, "The COSINE and Internet X.500 Schema", RFC1274, 11/27/1991. [3] The North American Directory Forum, "A Naming Scheme for c=US", RFC1255, September 1991. [4] 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 Internet text messages", RFC822. [8] S. Kille, "A String Representation of Distinguished Names", RFC1779, 03/28/1995. [9] A. Freier, P. Karlton, and P. Kocher, "The SSL Protocol Version 3.0", Work in Progress, Internet Draft , March 1996. [10] S. Kille, "X.500 and Domains", RFC1279, 11/27/1991. [11] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Work in Progress, Internet Draft , February 17, 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 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