draft-ietf-ldapbis-dn-14.txt   draft-ietf-ldapbis-dn-15.txt 
INTERNET-DRAFT Editor: Kurt D. Zeilenga INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 4 June 2004 Expires in six months 24 October 2004
Obsoletes: 2253 Obsoletes: 2253
LDAP: String Representation of Distinguished Names LDAP: String Representation of Distinguished Names
<draft-ietf-ldapbis-dn-14.txt> <draft-ietf-ldapbis-dn-15.txt>
Status of Memo Status of Memo
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document revision, submitted to the RFC Editor as a Standard Track document
replacing RFC 2253. Distribution of this memo is unlimited. replacing RFC 2253. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF LDAP Technical discussion of this document will take place on the IETF LDAP
Revision (LDAPBIS) Working Group mailing list Revision (LDAPBIS) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly <ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>. to the document editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been applicable patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in disclosed, or will be disclosed, and any of which I become aware will
accordance with RFC 3668. be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. <http://www.ietf.org/shadow.html>.
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document Please see the Full Copyright section near the end of this document
for more information. for more information.
Abstract Abstract
The X.500 Directory uses distinguished names (DNs) as primary keys to The X.500 Directory uses distinguished names (DNs) as primary keys to
entries in the directory. This document defines the string entries in the directory. This document defines the string
skipping to change at page 4, line 28 skipping to change at page 4, line 28
the output consists of the string encodings of each the output consists of the string encodings of each
AttributeTypeAndValue (according to Section 2.3), in any order. AttributeTypeAndValue (according to Section 2.3), in any order.
Where there is a multi-valued RDN, the outputs from adjoining Where there is a multi-valued RDN, the outputs from adjoining
AttributeTypeAndValues are separated by a plus sign ('+' U+002B) AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
character. character.
2.3. Converting AttributeTypeAndValue 2.3. Converting AttributeTypeAndValue
The AttributeTypeAndValue is encoded as the string representation of The AttributeTypeAndValue is encoded as the string representation of
the AttributeType, followed by an equals ('=' U+003D) character, the AttributeType, followed by an equals sign ('=' U+003D) character,
followed by the string representation of the AttributeValue. The followed by the string representation of the AttributeValue. The
encoding of the AttributeValue is given in Section 2.4. encoding of the AttributeValue is given in Section 2.4.
If the AttributeType is defined to have a short name and that short If the AttributeType is defined to have a short name and that short
name is known to be registered [REGISTRY][BCP64bis] as identifying the name is known to be registered [REGISTRY][BCP64bis] as identifying the
AttributeType, that short name, a <descr>, is used. Otherwise the AttributeType, that short name, a <descr>, is used. Otherwise the
AttributeType is encoded as the dotted-decimal encoding, a AttributeType is encoded as the dotted-decimal encoding, a
<numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid> <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
is defined in [Models]. is defined in [Models].
skipping to change at page 6, line 17 skipping to change at page 6, line 17
*( COMMA relativeDistinguishedName ) ] *( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue relativeDistinguishedName = attributeTypeAndValue
*( PLUS attributeTypeAndValue ) *( PLUS attributeTypeAndValue )
attributeTypeAndValue = attributeType EQUALS attributeValue attributeTypeAndValue = attributeType EQUALS attributeValue
attributeType = descr / numericoid attributeType = descr / numericoid
attributeValue = string / hexstring attributeValue = string / hexstring
; The following characters are to be escaped when they appear ; The following characters are to be escaped when they appear
; in the value to be encoded: ESC, one of <escaped>, leading ; in the value to be encoded: ESC, one of <escaped>, leading
; SHARP or SPACE, trailing SPACE, and NULL. ; SHARP or SPACE, trailing SPACE, and NULL.
string = [ (leadchar / pair) string = [ ( leadchar / pair ) [ *( stringchar / pair )
[ *( stringchar / pair ) ( trailchar / pair ) ] ] ( trailchar / pair ) ] ]
leadchar = LUTF1 / UTFMB leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F %x3D / %x3F-5B / %x5D-7F
trailchar = TUTF1 / UTFMB trailchar = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F %x3D / %x3F-5B / %x5D-7F
stringchar = SUTF1 / UTFMB stringchar = SUTF1 / UTFMB
skipping to change at page 8, line 4 skipping to change at page 8, line 4
This section gives a few examples of distinguished names written using This section gives a few examples of distinguished names written using
this notation. First is a name containing three relative this notation. First is a name containing three relative
distinguished names (RDNs): distinguished names (RDNs):
UID=jsmith,DC=example,DC=net UID=jsmith,DC=example,DC=net
Here is an example name containing three RDNs, in which the first RDN Here is an example name containing three RDNs, in which the first RDN
is multi-valued: is multi-valued:
OU=Sales+CN=J. Smith,DC=example,DC=net OU=Sales+CN=J. Smith,DC=example,DC=net
This example shows the method of escaping of a comma in a common name: This example shows the method of escaping of a special characters
appearing in a common name:
CN=John Smith\, III,DC=example,DC=net CN=James \"Jim\" Smith\, III,DC=example,DC=net
An example name in which a value contains a carriage return character: The following shows the method for encoding a value which contains a
carriage return character:
CN=Before\0dAfter,DC=example,DC=net CN=Before\0dAfter,DC=example,DC=net
An example name in which an RDN was of an unrecognized type. The In this RDN example, the type in the RDN is unrecognized, and the
value is the BER encoding of an OCTET STRING containing two octets value is the BER encoding of an OCTET STRING containing two octets
0x48 and 0x69. 0x48 and 0x69.
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 1.3.6.1.4.1.1466.0=#04024869
Finally, an example of an RDN commonName value consisting of 5 Finally, this example shows an RDN whose commonName value consisting
letters: of 5 letters:
Unicode Character Code UTF-8 Escaped Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ -------- ------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
could be written in printable ASCII (useful for debugging purposes): could be encoded in printable ASCII (useful for debugging purposes)
as:
CN=Lu\C4\8Di\C4\87 CN=Lu\C4\8Di\C4\87
5. Security Considerations 5. Security Considerations
The following security considerations are specific to the handling of The following security considerations are specific to the handling of
distinguished names. LDAP security considerations are discussed in distinguished names. LDAP security considerations are discussed in
[Protocol] and other documents comprising the LDAP Technical [Protocol] and other documents comprising the LDAP Technical
Specification [Roadmap]. Specification [Roadmap].
skipping to change at page 9, line 27 skipping to change at page 9, line 31
For example, a distinguished name consisting of one RDN with one AVA, 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 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 choice with the letters 'Sam' would be represented in LDAP as the
string <CN=Sam>. Another distinguished name in which the value is string <CN=Sam>. Another distinguished name in which the value is
still 'Sam' but of the PrintableString choice would have the same still 'Sam' but of the PrintableString choice would have the same
representation <CN=Sam>. representation <CN=Sam>.
Applications which require the reconstruction of the DER form of the Applications which require the reconstruction of the DER form of the
value SHOULD NOT use the string representation of attribute syntaxes value SHOULD NOT use the string representation of attribute syntaxes
when converting a distinguished name to the LDAP format. Instead, when converting a distinguished name to the LDAP format. Instead,
they SHOULD use the hexadecimal form prefixed by the number sign ('#') they SHOULD use the hexadecimal form prefixed by the number sign ('#'
as described in the first paragraph of Section 2.3. U+0023) as described in the first paragraph of Section 2.4.
6. Acknowledgment 6. Acknowledgment
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
This document is a product of the IETF LDAPBIS Working Group. This document is a product of the IETF LDAPBIS Working Group.
7. Document Editor's Address 7. Document Editor's Address
skipping to change at page 10, line 22 skipping to change at page 10, line 24
Telecommunication Standardization Sector, "Abstract Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998). Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997. Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC3329] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3329 (also STD 64), November 2003. 10646", RFC 3629 (also STD 63), November 2003.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0" 3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the 3.1" (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[Models] Zeilenga, K. (editor), "LDAP: Directory Information [Models] Zeilenga, K. (editor), "LDAP: Directory Information
skipping to change at page 13, line 18 skipping to change at page 13, line 23
Appendix B. Changes made since RFC 2253 Appendix B. Changes made since RFC 2253
This appendix is provided for informational purposes only, it is not a This appendix is provided for informational purposes only, it is not a
normative part of this specification. normative part of this specification.
The following substantive changes were made to RFC 2253: The following substantive changes were made to RFC 2253:
- Removed IESG Note. The IESG Note has been addressed. - Removed IESG Note. The IESG Note has been addressed.
- Replaced all references to ISO 10646-1 with [Unicode]. - Replaced all references to ISO 10646-1 with [Unicode].
- Clarified (in Section 1) that this document does not define a - Clarified (in Section 1) that this document does not define a
canonical string representation. canonical string representation.
- Clarified that Section 2 describes the RECOMMENDED encoding
algorithm and that alternative algorithms are allowed. Some
encoding options described in RFC 2253 are now treated as
alternative algorithms in this specification.
- Revised specification (in Section 2) to allow short names of any - Revised specification (in Section 2) to allow short names of any
registered attribute type to appear in string representations of registered attribute type to appear in string representations of
DNs instead of being restricted to a "published table". Remove DNs instead of being restricted to a "published table". Remove
"as an example" language. Added statement (in Section 3) allowing "as an example" language. Added statement (in Section 3) allowing
recognition of additional names but require recognization of those recognition of additional names but require recognization of those
names in the published table. The table is now published in names in the published table. The table is now published in
Section 3. Section 3.
- Replaced specification of additional requirements for LDAPv2 - Removed specification of additional requirements for LDAPv2
implementations which also support LDAPv3 (RFC 2253, Section 4) implementations which also support LDAPv3 (RFC 2253, Section 4) as
with a statement (in Section 3) allowing recognition of LDAPv2 is now Historic.
alternative string representations. - Allow recognition of alternative string representations.
- Updated Section 2.3 to indicate attribute type name strings are
case insensitive.
- Updated Section 2.4 to allow hex pair escaping of all characters - Updated Section 2.4 to allow hex pair escaping of all characters
and clarified escaping for when multiple octet UTF-8 echodings are and clarified escaping for when multiple octet UTF-8 encodings are
present. present. Indicated that null (U+0000) character is to be escaped.
Indicated that equals sign ('=' U+003D) character may be escaped
as '\='.
- Rewrote Section 3 to use ABNF as defined in RFC 2234. - Rewrote Section 3 to use ABNF as defined in RFC 2234.
- Rewrote Section 3 ABNF to be consistent with 2.4. - Updated the Section 3 ABNF. Changes include:
+ allow AttributeType short names of length 1 (e.g., 'L'),
+ use more restrictive <oid> production in AttributeTypes,
+ do not require escaping of equals sign ('=' U+003D) characters,
+ do not require escaping of non-leading number sign ('#' U+0023)
characters,
+ allow space (' ' U+0020) to escaped as '\ ',
+ require hex escaping of null (U+0000) characters, and
+ removed LDAPv2-only constructs.
- Updated Section 3 to describe how to parse elements of the - Updated Section 3 to describe how to parse elements of the
grammar. grammar.
- Rewrote examples. - Rewrote examples.
- Added reference to documentations containing general LDAP security - Added reference to documentations containing general LDAP security
considerations. considerations.
- Added discussion of presentation issues (Appendix A). - Added discussion of presentation issues (Appendix A).
- Added this appendix. - Added this appendix.
In addition, numerous editorial changes were made. In addition, numerous editorial changes were made.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/