HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:51:37 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 01 Aug 1996 22:15:00 GMT ETag: "304d86-299d-32012c64" Accept-Ranges: bytes Content-Length: 10653 Connection: close Content-Type: text/plain Network Working Group S. Kille INTERNET-DRAFT ISODE Consortium Obsoletes: RFC 1279 M. Wahl Critical Angle Inc. Expires in six months from July 31, 1996 Intended Category: Experimental An Approach for Using Domains in LDAP Distinguished Names Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Abstract The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible Distinguished Names for providing unique identifcation of entries. Distinguished Names in currently-deployed X.500 directories have the properties that they are descriptive, hierarchical, and follow common organizational models. However, there is not today a universal registration mechanism to permit individuals and organizations to obtain Distinguished Names. This document describes an experimental mechanism by which a name registered with the Internet Domain Name Service, for which there is an active registration service, can be represented as a Distinguished Name so that it may be used with the LDAP protocol. This is not intended to have LDAP replace the DNS protocol, but to permit further deployment of LDAP into organizations connected to the Internet. 2. Domain Names and Distinguished Names The Domain (Nameserver) System (DNS) provides a hierarchical resource labelling system [1]. An example domain name would be "CRITICAL-ANGLE.COM". Entries usually have a single name, although pointers to entries may be provided by CNAME records. Information (resource records) is associated with each entry. Name components are typically chosen to be shortish (e.g., "WWW"). INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996 Kille, Wahl An Approach for Using Domains in LDAP DNs Page 2 The X.500 Directory provides a very general hierarchical naming framework. A primary difference in specification of Distinguished Names from domain names is that each component of an distinguished name has an explicit attribute type indication. (It is also possible to have multiple components in the same level, but that is not commonly done today). An example Distinguished Name represented in the LDAP string format [2] is "CN=Mark Wahl, O=Critical Angle Incorporated, ST=Texas, C=US". 3. Mapping Domain Names into Distinguished Names This section defines a subset of the X.500 naming structure for use in representing names allocated in the Internet Domain Name System. It is expected that it would be possible to algorithmically transform any Internet domain name into a Distinguished Name, and to be able to convert such a name back into a domain name. The algorithm for transforming a domain name is to begin with a DN of "O=Internet", and then attach RDNs for each component of the domain, most significant first. Each of these RDNs have a single AttributeTypeAndValue, where the type is domainComponent (abbreviated "DC") and the value is an IA5 string. Thus the domain name CS.UCL.AC.UK can be transformed into DC=CS, DC=UCL, DC=AC, DC=UK, O=Internet And similarly 11.168.192.IN-ADDR.ARPA to DC=11, DC=168, DC=192, DC=IN-ADDR, DC=ARPA, O=Internet X.500 Distinguished Names in which the first RDN is "O=Internet", and there are one or more following RDNs, each with the attribute type domainComponent, can be mapped back into domain names. Note that there will not be an algorithmic domain name equivalence for all other Distinguished Names, such as: CN=Steve Kille, DC=ISODE, DC=COM, O=Internet O=ISODE Consortium, C=GB 4. Limitations on Use of this Mechanism This naming mechanism is primarily intended for experimental or single-site pilot projects, or where the directory service does not currently intend to connect to any established service, but still requires a globally unique name. If an organization is running a service in a locality for which there is an official registration authority for distinguished names, an officially registered distinguished name should be used instead of this mechanism. These names are typically based on the concatenation of an organization's registered name and the location of that registry, such as "O=IC, C=GB". If an organization intends to connect to an established directory service, then the guidelines of that service should be followed. INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996 Kille, Wahl An Approach for Using Domains in LDAP DNs Page 3 5. Attribute Type and Object Class Definition The domainComponent or DC attribute type is defined in [3], and is reproduced here for convenience. domainComponent ATTRIBUTE ::= { WITH SYNTAX IA5String EQUALITY MATCHING RULE iA5EqualityMatchingRule SINGLE VALUE TRUE ID {pilotAttributeType 25} } The encoding of IA5String for use in LDAP is simply the characters of the string itself. The equality matching rule is case insensitive, as is today's DNS. The domain object class would be used as the structural object class of entries whose distinguished names are generated according to the algorithm in section 3. domain OBJECT-CLASS ::= { SUBCLASS OF { top } MUST CONTAIN { domainComponent } MAY CONTAIN { associatedName, organizationName, organizationalAttributeSet } ID {pilotObjectClass 13} } domainNameForm NAME-FORM ::= { NAMES domain WITH ATTRIBUTES { domainComponent } ID {enterprises 1466 345 }} If it is desired to be able to store or retrieve DNS-specific attributes via LDAP, the dNSDomain object class can be used as well. 6. Directory Information Structure This algorithm assigns to any organization which has obtained a domain name for use in the Internet a distinguished name for use as a prefix for their own entry's names. Thus a small organization which holds the domain name CRITICAL-ANGLE.COM Might have as their directory entries: CN=Mark Wahl, DC=CRITICAL-ANGLE, DC=COM, O=Internet CN=Postmaster, DC=CRITICAL-ANGLE, DC=COM, O=Internet While an organization with multiple subdomains might structure their entries as: CN=Steve Kille, DC=Richmond, DC=ISODE, DC=COM, O=Internet CN=Greg Lavender, DC=Austin, DC=ISODE, DC=COM, O=Internet INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996 Kille, Wahl An Approach for Using Domains in LDAP DNs Page 4 There are a number of RFCs, such as [4] and [5], which provide guidance on representing and structuring information in directory entries which would be applicable. 7. Relationship with LDAP when Browsing To effectively search the entries in an LDAP server connected to a global directory system, it is necessary to know the base object of the entries a server maintains. If a client does not have any information on a search base to use, then there are three possible approaches: 1. Interrogate the server for the naming contexts it holds. 2. Create a search base based on the domain name of the contacted server. 3. Browse by searching immediately subordinate to the root. Approach 1 is recommended if the client and server both support LDAP version 3 or higher. If this is not the case and there is no other information available to the client, then approach 2 is recommend. Approach 2 makes use of the mechanism defined in this document, with a slight extension. If the least significant component of the contacted server's domain name is "ldap" or "x500", this component is ignored, and the remainer of the domain name is transformed into a distinguished name. Thus for example if the client was asked to contact the server ldap.critical-angle.com and browse, it would using approach 2 issue its searches with the base object "DC=CRITICAL-ANGLE, DC=COM, O=Internet". Approach 3 is not recommended, as the server may chain or refer the operation to another server which holds entries subordinate to the root (such as countries). 8. References [1] P. Mockapetris. Domain names - concepts and facilities. RFC 1034, November 1987. [2] S. Kille, M.Wahl. Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996. [3] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet X.500 schema. Request for Comments RFC 1274, November 1991. [4] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring Guidelines for X.500 Directory Pilots". RFC 1617 May 1994. [5] B. Jennings, "Building an X.500 Directory Service in the US", RFC 1943, May 1996. 9. Security Considerations This memo does not address security issues. INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996 Kille, Wahl An Approach for Using Domains in LDAP DNs Page 5 10. Author's Address Steve Kille ISODE Consortium The Dome The Square Richmond, Surrey TW9 1DT England 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