HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:52:30 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 01 Aug 1996 22:15:00 GMT ETag: "304d8c-2bd1-32012c64" Accept-Ranges: bytes Content-Length: 11217 Connection: close Content-Type: text/plain Network Working Group M. Wahl INTERNET-DRAFT Critical Angle Inc. Obsoletes: RFC 1779 S. Kille ISODE Consortium Expires in six months from July 31, 1996 Intended Category: Standards Track Lightweight Directory Access Protocol (v3): UTF-8 String Representation of 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). Abstract The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. 1. Background This specification assumes familiarity with X.500 [1], and the concept of Distinguished Name. It is important to have a common format to be able to unambiguously represent a distinguished name. The primary goal of this specification is ease of encoding and decoding. A secondary goal is to have names that are human readable. It is not expected that LDAP clients with a human user interface would display these strings directly to the user, but would most likely be performing translations (such as expressing attribute type names in the local national language). 2. A Notation for Distinguished Name In X.501 [2] the ASN.1 structure of Distinguished Name is defined as: DistinguishedName ::= RDNSequence RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue INTERNET-DRAFT draft-ietf-asid-ldapv3-dn-00.txt July 31, 1996 Wahl, Kille String Representations of Distinguished Names Page 2 AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } The following sections 2.1 and 2.2 define the algorithm for converting between an ASN.1 structured representation and a UTF-8 string representation. 2.1 Converting DistinguishedName from ASN.1 to a String If the RDNSequence is an empty sequence, the result is the empty or zero length string. Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to 2.2), starting with the last element of the sequence and moving backwards toward the first. The encodings of adjoining RelativeDistinguishedNames are separated by either a comma or a semicolon character. There may be space characters present on either side of the comma or semicolon. Either the comma or the semicolon character is to be used to separate all the RelativeDistinguishedNames in a particular string. 2.1.2. Converting RelativeDistinguishedName from ASN.1 to a String When converting from an ASN.1 RelativeDistinguishedName to a string, the output consists of the string encodings of each AttributeTypeAndValue (according to 2.3), in any order. Where there is a multi-valued RDN, the outputs from adjoining AttributeTypeAndValues are separated by a plus character. 2.1.3. Converting AttributeTypeAndValue from ASN.1 to a String The AttributeTypeAndValue is encoded as the string representation of the AttributeType, followed by an equals character, followed by the string representation of the AttributeValue. If the AttributeType is one defined in Table 1 or in the IANA- maintained register of valid attribute types, then the string from that table is used, otherwise it is encoded as the string "OID." or "oid." immediately followed by the dotted-decimal encoding of the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is described in [3]. Table 1: Standardized Attribute Types used in RDNs String AttributeType ------------------------------ CN commonName L localityName ST stateOrProvinceName O organizationName OU organizationalUnitName C countryName STREET streetAddress DC domainComponent INTERNET-DRAFT draft-ietf-asid-ldapv3-dn-00.txt July 31, 1996 Wahl, Kille String Representations of Distinguished Names Page 3 2.1.4. Converting AttributeValue from ASN.1 to a String If the AttributeValue is of a type which does not have a string representation defined in [4], then it is simply encoded as an octothorpe character ("#") followed by the hexidecimal representation of the bytes of the BER encoding of AttributeValue. Otherwise, if the AttributeValue is of a type which has a string representation, it is converted first to a UTF-8 string according to that specification. If that string does not have any of the following characters which need escaping, then that string can be used as the string representation of the value. o a space character occurring at the beginning of the string o a space character occurring at the end of the string o a space character adjoining another space character o non-printing characters other than the single space o one of the characters ",", "+", "=", """, "\", "<", ">", "#" or ";" There are two possible escaping mechanisms. If the string does not contain the double quote character, then the entire string can be surrounded by double quote characters, and that used as the encoding. The alternative is to prefix each of the characters which need escaping by a backslash character. Examples of these mechanisms are shown in section 3. 2.2. Parsing a String back to a Distinguished Name The structure of the string is specified in a BNF grammar, based on the grammar defined in RFC 822, with the terminals enclosed in <> [5]. ::= | "" -- empty string ::= ( ) | ::= ::= "," | ";" ::= *( " " ) ::= | "+" ::= "=" ::= 1*( ) | "OID." | "oid." ::= letters, numbers, and space INTERNET-DRAFT draft-ietf-asid-ldapv3-dn-00.txt July 31, 1996 Wahl, Kille String Representations of Distinguished Names Page 4 ::= | "." ::= 1* ::= digits 0-9 ::= ::= *( | ) | '"' *( | | ) '"' | "#" ::= "," | "=" | | "+" | "<" | ">" | "#" | ";" ::= "\" ( | "\" | '"') ::= any character except or "\" or '"' ::= 2* ::= 0-9, a-f, A-F 3. Differences from RFC 1779 The following changes have been made in this version of the specification: o The use of angle brackets to surround the strings is not described, as this is not used in LDAP. Also the grammar for UFNs has been removed. However it is suggested that angle brackets may be used in preference to quotes or other characters as delimiters when including distinguished names in paragraphs. o Only space characters, not newlines, are shown between RDNs. o The AttributeType name "DC" has been added. 4. Examples This notation is designed to be convenient for common forms of name. This section gives a few examples of distinguished names written using this notation: CN=Steve Kille, O=ISODE Consortium, C=GB CN=Christian Huitema, O=INRIA, C=FR Here is an example of a multi-valued Relative Distinguished Name, where the namespace is flat within an organization, and department is used to disambiguate certain names: OU=Sales + CN=J. Smith, O=Widget Inc., C=US The final examples show both methods quoting of a comma in an Organization name: CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB 5. References [1] The Directory -- overview of concepts, models and services. ITU-T Rec. X.500(1993). INTERNET-DRAFT draft-ietf-asid-ldapv3-dn-00.txt July 31, 1996 Wahl, Kille String Representations of Distinguished Names Page 5 [2] The Directory -- Models. ITU-T Rec. X.501(1993). [3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", INTERNET DRAFT, draft-ietf-asid-ldapv3-protocol-01.txt. June 1996. [4] M. Wahl, S. Kille, T. Howes, A. Coulbeck, "Lightweight Directory Access Protocol (v3): Standard and Pilot Attribute Definitions", INTERNET DRAFT, draft-ietf-asid-ldapv3-attributes-01.txt. June 1996. [5] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. 6. Security Considerations Security issues are not discussed in this memo. 7. Author's Address Mark Wahl Critical Angle Inc. 4815 W. Braker Lane #502-385 Austin, TX 78759 USA EMail: M.Wahl@critical-angle.com Steve Kille ISODE Consortium The Dome The Square Richmond, Surrey TW9 1DT England Phone: +44-181-332-9091 EMail: S.Kille@ISODE.COM INTERNET-DRAFT draft-ietf-asid-ldapv3-dn-00.txt July 31, 1996