4. Relationship with RFC 1779 and LDAPv2

The syntax given in this document is more restrictive than the syntax in RFC 1779. Implementations parsing a string generated by an LDAPv2 client MUST accept the syntax of RFC 1779. Implementations MUST NOT, however, generate any of the RFC 1779 encodings which are not described above in section 2.

Implementations MUST allow a semicolon character to be used instead of a comma to separate RDNs in a distinguished name, and MUST also allow whitespace characters to be present on either side of the comma or semicolon. The whitespace characters are ignored, and the semicolon replaced with a comma.

Implementations MUST allow an oid in the attribute type to be prefixed by one of the character strings "oid." or "OID.".

Implementations MUST allow for space (' ' ASCII 32) characters to be present between name-component and ',', between attributeTypeAndValue and '+', between attributeType and '=', and between '=' and attributeValue. These space characters are ignored when parsing.

Implementations MUST allow a value to be surrounded by quote ('"' ASCII 34) characters, which are not part of the value. Inside the quoted value, the following characters can occur without any escaping:

",", "=", "+", "<", ">", "#" and ";"

5. 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. First is a name containing three relative distinguished names (RDNs):

CN=Steve Kille,O=Isode Limited,C=GB

Here is an example name containing three RDNs, in which the first RDN is multi-valued:

OU=Sales+CN=J. Smith,O=Widget Inc.,C=US

This example shows the method of quoting of a comma in an organization name:

CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB

An example name in which a value contains a carriage return character:

CN=Before\0DAfter,O=Test,C=GB

An example name in which an RDN was of an unrecognized type. The value is the BER encoding of an OCTET STRING containing two bytes 0x48 and 0x69.

1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB

Finally, an example of an RDN surname value consisting of 5 letters:

Unicode Letter Description 10646 code UTF-8 Quoted
=============================== ========== ====== =======
LATIN CAPITAL LETTER L U0000004C 0x4C L
LATIN SMALL LETTER U U00000075 0x75 u
LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
LATIN SMALL LETTER I U00000069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87

Could be written in printable ASCII (useful for debugging purposes):

SN=Lu\C4\8Di\C4\87

6. References

[1] The Directory -- overview of concepts, models and services. ITU-T Rec. X.500(1993).

[2] The Directory -- Models. ITU-T Rec. X.501(1993).

[3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[5] Crocker, D., "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119.

7. Security Considerations

7.1. Disclosure

Distinguished Names typically consist of descriptive information about the entries they name, which can be people, organizations, devices or other real-world objects. This frequently includes some of the following kinds of information:

- the common name of the object (i.e. a person's full name) - an email or TCP/IP address - its physical location (country, locality, city, street address) - organizational attributes (such as department name or affiliation)

Most countries have privacy laws regarding the publication of information about people.

7.2. Use of Distinguished Names in Security Applications

The transformations of an AttributeValue value from its X.501 form to an LDAP string representation are not always reversible back to the same BER or DER form. An example of a situation which requires the DER form of a distinguished name is the verification of an X.509 certificate.

For example, a distinguished name consisting of one RDN with one AVA, in which the type is commonName and the value is of the TeletexString choice with the letters 'Sam' would be represented in LDAP as the string CN=Sam. Another distinguished name in which the value is still 'Sam' but of the PrintableString choice would have the same representation CN=Sam.

Applications which require the reconstruction of the DER form of the value SHOULD NOT use the string representation of attribute syntaxes when converting a distinguished name to the LDAP format. Instead, they SHOULD use the hexadecimal form prefixed by the octothorpe ('#') as described in the first paragraph of section 2.4.

8. Authors' Addresses

Mark Wahl Critical Angle Inc. 4815 W. Braker Lane #502-385 Austin, TX 78759 USA

EMail: M.Wahl@critical-angle.com

Wahl, et. al. Proposed Standard [Page 8] RFC 2253 LADPv3 Distinguished Names December 1997

Steve Kille Isode Ltd. The Dome The Square Richmond, Surrey TW9 1DT England

Phone: +44-181-332-9091 EMail: S.Kille@ISODE.COM

Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd, MS MV068 Mountain View, CA 94043 USA

Phone: +1 650 937-3419 EMail: howes@netscape.com

9. Full Copyright Statement

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.