1 2 3 4 5 6 7 Network Working Group K. Zeilenga, Ed. 8 Request for Comments: 4514 OpenLDAP Foundation 9 Obsoletes: 2253 June 2006 10 Category: Standards Track 11 12 13 Lightweight Directory Access Protocol (LDAP): 14 String Representation of Distinguished Names 15 16 Status of This Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24 Copyright Notice 25 26 Copyright (C) The Internet Society (2006). 27 28 Abstract 29 30 The X.500 Directory uses distinguished names (DNs) as primary keys to 31 entries in the directory. This document defines the string 32 representation used in the Lightweight Directory Access Protocol 33 (LDAP) to transfer distinguished names. The string representation is 34 designed to give a clean representation of commonly used 35 distinguished names, while being able to represent any distinguished 36 name. 37 38 1. Background and Intended Usage 39 40 In X.500-based directory systems [X.500], including those accessed 41 using the Lightweight Directory Access Protocol (LDAP) [RFC4510], 42 distinguished names (DNs) are used to unambiguously refer to 43 directory entries [X.501][RFC4512]. 44 45 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 46 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 47 directory protocols), DNs are encoded using the Basic Encoding Rules 48 (BER) [X.690]. In LDAP, DNs are represented in the string form 49 described in this document. 50 51 It is important to have a common format to be able to unambiguously 52 represent a distinguished name. The primary goal of this 53 specification is ease of encoding and decoding. A secondary goal is 54 to have names that are human readable. It is not expected that LDAP 55 56 57 58 Zeilenga Standards Track [Page 1] 59 61 RFC 4514 LDAP: Distinguished Names June 2006 62 63 64 implementations with a human user interface would display these 65 strings directly to the user, but that they would most likely be 66 performing translations (such as expressing attribute type names in 67 the local national language). 68 69 This document defines the string representation of Distinguished 70 Names used in LDAP [RFC4511][RFC4517]. Section 2 details the 71 RECOMMENDED algorithm for converting a DN from its ASN.1 structured 72 representation to a string. Section 3 details how to convert a DN 73 from a string to an ASN.1 structured representation. 74 75 While other documents may define other algorithms for converting a DN 76 from its ASN.1 structured representation to a string, all algorithms 77 MUST produce strings that adhere to the requirements of Section 3. 78 79 This document does not define a canonical string representation for 80 DNs. Comparison of DNs for equality is to be performed in accordance 81 with the distinguishedNameMatch matching rule [RFC4517]. 82 83 This document is a integral part of the LDAP technical specification 84 [RFC4510], which obsoletes the previously defined LDAP technical 85 specification, RFC 3377, in its entirety. This document obsoletes 86 RFC 2253. Changes since RFC 2253 are summarized in Appendix B. 87 88 This specification assumes familiarity with X.500 [X.500] and the 89 concept of Distinguished Name [X.501][RFC4512]. 90 91 1.1. Conventions 92 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in BCP 14 [RFC2119]. 96 97 Character names in this document use the notation for code points and 98 names from the Unicode Standard [Unicode]. For example, the letter 99 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. 100 101 Note: a glossary of terms used in Unicode can be found in [Glossary]. 102 Information on the Unicode character encoding model can be found in 103 [CharModel]. 104 105 106 107 108 109 110 111 112 113 114 115 Zeilenga Standards Track [Page 2] 116 118 RFC 4514 LDAP: Distinguished Names June 2006 119 120 121 2. Converting DistinguishedName from ASN.1 to a String 122 123 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished 124 name. The following is a variant provided for discussion purposes. 125 126 DistinguishedName ::= RDNSequence 127 128 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 129 130 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 131 AttributeTypeAndValue 132 133 AttributeTypeAndValue ::= SEQUENCE { 134 type AttributeType, 135 value AttributeValue } 136 137 This section defines the RECOMMENDED algorithm for converting a 138 distinguished name from an ASN.1-structured representation to a UTF-8 139 [RFC3629] encoded Unicode [Unicode] character string representation. 140 Other documents may describe other algorithms for converting a 141 distinguished name to a string, but only strings that conform to the 142 grammar defined in Section 3 SHALL be produced by LDAP 143 implementations. 144 145 2.1. Converting the RDNSequence 146 147 If the RDNSequence is an empty sequence, the result is the empty or 148 zero-length string. 149 150 Otherwise, the output consists of the string encodings of each 151 RelativeDistinguishedName in the RDNSequence (according to Section 152 2.2), starting with the last element of the sequence and moving 153 backwards toward the first. 154 155 The encodings of adjoining RelativeDistinguishedNames are separated 156 by a comma (',' U+002C) character. 157 158 2.2. Converting RelativeDistinguishedName 159 160 When converting from an ASN.1 RelativeDistinguishedName to a string, 161 the output consists of the string encodings of each 162 AttributeTypeAndValue (according to Section 2.3), in any order. 163 164 Where there is a multi-valued RDN, the outputs from adjoining 165 AttributeTypeAndValues are separated by a plus sign ('+' U+002B) 166 character. 167 168 169 170 171 172 Zeilenga Standards Track [Page 3] 173 175 RFC 4514 LDAP: Distinguished Names June 2006 176 177 178 2.3. Converting AttributeTypeAndValue 179 180 The AttributeTypeAndValue is encoded as the string representation of 181 the AttributeType, followed by an equals sign ('=' U+003D) character, 182 followed by the string representation of the AttributeValue. The 183 encoding of the AttributeValue is given in Section 2.4. 184 185 If the AttributeType is defined to have a short name (descriptor) 186 [RFC4512] and that short name is known to be registered [REGISTRY] 187 [RFC4520] as identifying the AttributeType, that short name, a 188 <descr>, is used. Otherwise the AttributeType is encoded as the 189 dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. 190 The <descr> and <numericoid> are defined in [RFC4512]. 191 192 Implementations are not expected to dynamically update their 193 knowledge of registered short names. However, implementations SHOULD 194 provide a mechanism to allow their knowledge of registered short 195 names to be updated. 196 197 2.4. Converting an AttributeValue from ASN.1 to a String 198 199 If the AttributeType is of the dotted-decimal form, the 200 AttributeValue is represented by an number sign ('#' U+0023) 201 character followed by the hexadecimal encoding of each of the octets 202 of the BER encoding of the X.500 AttributeValue. This form is also 203 used when the syntax of the AttributeValue does not have an LDAP- 204 specific ([RFC4517], Section 3.1) string encoding defined for it, or 205 the LDAP-specific string encoding is not restricted to UTF-8-encoded 206 Unicode characters. This form may also be used in other cases, such 207 as when a reversible string representation is desired (see Section 208 5.2). 209 210 Otherwise, if the AttributeValue is of a syntax that has a LDAP- 211 specific string encoding, the value is converted first to a UTF-8- 212 encoded Unicode string according to its syntax specification (see 213 [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode 214 string does not have any of the following characters that need 215 escaping, then that string can be used as the string representation 216 of the value. 217 218 - a space (' ' U+0020) or number sign ('#' U+0023) occurring at 219 the beginning of the string; 220 221 - a space (' ' U+0020) character occurring at the end of the 222 string; 223 224 225 226 227 228 229 Zeilenga Standards Track [Page 4] 230 232 RFC 4514 LDAP: Distinguished Names June 2006 233 234 235 - one of the characters '"', '+', ',', ';', '<', '>', or '\' 236 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, 237 respectively); 238 239 - the null (U+0000) character. 240 241 Other characters may be escaped. 242 243 Each octet of the character to be escaped is replaced by a backslash 244 and two hex digits, which form a single octet in the code of the 245 character. Alternatively, if and only if the character to be escaped 246 is one of 247 248 ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\' 249 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, 250 U+003C, U+003D, U+003E, U+005C, respectively) 251 252 it can be prefixed by a backslash ('\' U+005C). 253 254 Examples of the escaping mechanism are shown in Section 4. 255 256 3. Parsing a String Back to a Distinguished Name 257 258 The string representation of Distinguished Names is restricted to 259 UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure 260 of this string representation is specified using the following 261 Augmented BNF [RFC4234] grammar: 262 263 distinguishedName = [ relativeDistinguishedName 264 *( COMMA relativeDistinguishedName ) ] 265 relativeDistinguishedName = attributeTypeAndValue 266 *( PLUS attributeTypeAndValue ) 267 attributeTypeAndValue = attributeType EQUALS attributeValue 268 attributeType = descr / numericoid 269 attributeValue = string / hexstring 270 271 ; The following characters are to be escaped when they appear 272 ; in the value to be encoded: ESC, one of <escaped>, leading 273 ; SHARP or SPACE, trailing SPACE, and NULL. 274 string = [ ( leadchar / pair ) [ *( stringchar / pair ) 275 ( trailchar / pair ) ] ] 276 277 leadchar = LUTF1 / UTFMB 278 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 279 %x3D / %x3F-5B / %x5D-7F 280 281 trailchar = TUTF1 / UTFMB 282 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 283 284 285 286 Zeilenga Standards Track [Page 5] 287 289 RFC 4514 LDAP: Distinguished Names June 2006 290 291 292 %x3D / %x3F-5B / %x5D-7F 293 294 stringchar = SUTF1 / UTFMB 295 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 296 %x3D / %x3F-5B / %x5D-7F 297 298 pair = ESC ( ESC / special / hexpair ) 299 special = escaped / SPACE / SHARP / EQUALS 300 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 301 hexstring = SHARP 1*hexpair 302 hexpair = HEX HEX 303 304 where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>, 305 <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, 306 <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512]. 307 308 Each <attributeType>, either a <descr> or a <numericoid>, refers to 309 an attribute type of an attribute value assertion (AVA). The 310 <attributeType> is followed by an <EQUALS> and an <attributeValue>. 311 The <attributeValue> is either in <string> or <hexstring> form. 312 313 If in <string> form, a LDAP string representation asserted value can 314 be obtained by replacing (left to right, non-recursively) each <pair> 315 appearing in the <string> as follows: 316 317 replace <ESC><ESC> with <ESC>; 318 replace <ESC><special> with <special>; 319 replace <ESC><hexpair> with the octet indicated by the <hexpair>. 320 321 If in <hexstring> form, a BER representation can be obtained from 322 converting each <hexpair> of the <hexstring> to the octet indicated 323 by the <hexpair>. 324 325 There is one or more attribute value assertions, separated by <PLUS>, 326 for a relative distinguished name. 327 328 There is zero or more relative distinguished names, separated by 329 <COMMA>, for a distinguished name. 330 331 Implementations MUST recognize AttributeType name strings 332 (descriptors) listed in the following table, but MAY recognize other 333 name strings. 334 335 336 337 338 339 340 341 342 343 Zeilenga Standards Track [Page 6] 344 346 RFC 4514 LDAP: Distinguished Names June 2006 347 348 349 String X.500 AttributeType 350 ------ -------------------------------------------- 351 CN commonName (2.5.4.3) 352 L localityName (2.5.4.7) 353 ST stateOrProvinceName (2.5.4.8) 354 O organizationName (2.5.4.10) 355 OU organizationalUnitName (2.5.4.11) 356 C countryName (2.5.4.6) 357 STREET streetAddress (2.5.4.9) 358 DC domainComponent (0.9.2342.19200300.100.1.25) 359 UID userId (0.9.2342.19200300.100.1.1) 360 361 These attribute types are described in [RFC4519]. 362 363 Implementations MAY recognize other DN string representations. 364 However, as there is no requirement that alternative DN string 365 representations be recognized (and, if so, how), implementations 366 SHOULD only generate DN strings in accordance with Section 2 of this 367 document. 368 369 4. Examples 370 371 This notation is designed to be convenient for common forms of name. 372 This section gives a few examples of distinguished names written 373 using this notation. First is a name containing three relative 374 distinguished names (RDNs): 375 376 UID=jsmith,DC=example,DC=net 377 378 Here is an example of a name containing three RDNs, in which the 379 first RDN is multi-valued: 380 381 OU=Sales+CN=J. Smith,DC=example,DC=net 382 383 This example shows the method of escaping of a special characters 384 appearing in a common name: 385 386 CN=James \"Jim\" Smith\, III,DC=example,DC=net 387 388 The following shows the method for encoding a value that contains a 389 carriage return character: 390 391 CN=Before\0dAfter,DC=example,DC=net 392 393 In this RDN example, the type in the RDN is unrecognized, and the 394 value is the BER encoding of an OCTET STRING containing two octets, 395 0x48 and 0x69. 396 397 398 399 400 Zeilenga Standards Track [Page 7] 401 403 RFC 4514 LDAP: Distinguished Names June 2006 404 405 406 1.3.6.1.4.1.1466.0=#04024869 407 408 Finally, this example shows an RDN whose commonName value consists of 409 5 letters: 410 411 Unicode Character Code UTF-8 Escaped 412 ------------------------------- ------ ------ -------- 413 LATIN CAPITAL LETTER L U+004C 0x4C L 414 LATIN SMALL LETTER U U+0075 0x75 u 415 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D 416 LATIN SMALL LETTER I U+0069 0x69 i 417 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 418 419 This could be encoded in printable ASCII [ASCII] (useful for 420 debugging purposes) as: 421 422 CN=Lu\C4\8Di\C4\87 423 424 5. Security Considerations 425 426 The following security considerations are specific to the handling of 427 distinguished names. LDAP security considerations are discussed in 428 [RFC4511] and other documents comprising the LDAP Technical 429 Specification [RFC4510]. 430 431 5.1. Disclosure 432 433 Distinguished Names typically consist of descriptive information 434 about the entries they name, which can be people, organizations, 435 devices, or other real-world objects. This frequently includes some 436 of the following kinds of information: 437 438 - the common name of the object (i.e., a person's full name) 439 - an email or TCP/IP address 440 - its physical location (country, locality, city, street address) 441 - organizational attributes (such as department name or 442 affiliation) 443 444 In some cases, such information can be considered sensitive. In many 445 countries, privacy laws exist that prohibit disclosure of certain 446 kinds of descriptive information (e.g., email addresses). Hence, 447 server implementers are encouraged to support Directory Information 448 Tree (DIT) structural rules and name forms [RFC4512], as these 449 provide a mechanism for administrators to select appropriate naming 450 attributes for entries. Administrators are encouraged to use 451 mechanisms, access controls, and other administrative controls that 452 may be available to restrict use of attributes containing sensitive 453 information in naming of entries. Additionally, use of 454 455 456 457 Zeilenga Standards Track [Page 8] 458 460 RFC 4514 LDAP: Distinguished Names June 2006 461 462 463 authentication and data security services in LDAP [RFC4513][RFC4511] 464 should be considered. 465 466 5.2. Use of Distinguished Names in Security Applications 467 468 The transformations of an AttributeValue value from its X.501 form to 469 an LDAP string representation are not always reversible back to the 470 same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules) 471 form. An example of a situation that requires the DER form of a 472 distinguished name is the verification of an X.509 certificate. 473 474 For example, a distinguished name consisting of one RDN with one AVA, 475 in which the type is commonName and the value is of the TeletexString 476 choice with the letters 'Sam', would be represented in LDAP as the 477 string <CN=Sam>. Another distinguished name in which the value is 478 still 'Sam', but is of the PrintableString choice, would have the 479 same representation <CN=Sam>. 480 481 Applications that require the reconstruction of the DER form of the 482 value SHOULD NOT use the string representation of attribute syntaxes 483 when converting a distinguished name to the LDAP format. Instead, 484 they SHOULD use the hexadecimal form prefixed by the number sign ('#' 485 U+0023) as described in the first paragraph of Section 2.4. 486 487 6. Acknowledgements 488 489 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 490 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 491 492 This document is a product of the IETF LDAPBIS Working Group. 493 494 7. References 495 496 7.1. Normative References 497 498 [REGISTRY] IANA, Object Identifier Descriptors Registry, 499 <http://www.iana.org/assignments/ldap-parameters>. 500 501 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 502 3.2.0" is defined by "The Unicode Standard, Version 503 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 504 61633-5), as amended by the "Unicode Standard Annex 505 #27: Unicode 3.1" 506 (http://www.unicode.org/reports/tr27/) and by the 507 "Unicode Standard Annex #28: Unicode 3.2" 508 (http://www.unicode.org/reports/tr28/). 509 510 511 512 513 514 Zeilenga Standards Track [Page 9] 515 517 RFC 4514 LDAP: Distinguished Names June 2006 518 519 520 [X.501] International Telecommunication Union - 521 Telecommunication Standardization Sector, "The 522 Directory -- Models," X.501(1993) (also ISO/IEC 9594- 523 2:1994). 524 525 [X.680] International Telecommunication Union - 526 Telecommunication Standardization Sector, "Abstract 527 Syntax Notation One (ASN.1) - Specification of Basic 528 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 529 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 533 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 534 10646", STD 63, RFC 3629, November 2003. 535 536 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 537 Specifications: ABNF", RFC 4234, October 2005. 538 539 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access 540 Protocol (LDAP): Technical Specification Road Map", RFC 541 4510, June 2006. 542 543 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 544 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 545 546 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 547 (LDAP): Directory Information Models", RFC 4512, June 548 2006. 549 550 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access 551 Protocol (LDAP): Authentication Methods and Security 552 Mechanisms", RFC 4513, June 2006. 553 554 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 555 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 556 2006. 557 558 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access 559 Protocol (LDAP): Schema for User Applications", RFC 560 4519, June 2006. 561 562 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 563 (IANA) Considerations for the Lightweight Directory 564 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 565 566 567 568 569 570 571 Zeilenga Standards Track [Page 10] 572 574 RFC 4514 LDAP: Distinguished Names June 2006 575 576 577 7.2. Informative References 578 579 [ASCII] Coded Character Set--7-bit American Standard Code for 580 Information Interchange, ANSI X3.4-1986. 581 582 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 583 #17, Character Encoding Model", UTR17, 584 <http://www.unicode.org/unicode/reports/tr17/>, August 585 2000. 586 587 [Glossary] The Unicode Consortium, "Unicode Glossary", 588 <http://www.unicode.org/glossary/>. 589 590 [X.500] International Telecommunication Union - 591 Telecommunication Standardization Sector, "The 592 Directory -- Overview of concepts, models and 593 services," X.500(1993) (also ISO/IEC 9594-1:1994). 594 595 [X.511] International Telecommunication Union - 596 Telecommunication Standardization Sector, "The 597 Directory: Abstract Service Definition", X.511(1993) 598 (also ISO/IEC 9594-3:1993). 599 600 [X.690] International Telecommunication Union - 601 Telecommunication Standardization Sector, 602 "Specification of ASN.1 encoding rules: Basic Encoding 603 Rules (BER), Canonical Encoding Rules (CER), and 604 Distinguished Encoding Rules (DER)", X.690(1997) (also 605 ISO/IEC 8825-1:1998). 606 607 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 608 Technical Specification", RFC 2849, June 2000. 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 Zeilenga Standards Track [Page 11] 629 631 RFC 4514 LDAP: Distinguished Names June 2006 632 633 634 Appendix A. Presentation Issues 635 636 This appendix is provided for informational purposes only; it is not 637 a normative part of this specification. 638 639 The string representation described in this document is not intended 640 to be presented to humans without translation. However, at times it 641 may be desirable to present non-translated DN strings to users. This 642 section discusses presentation issues associated with non-translated 643 DN strings. Issues with presentation of translated DN strings are 644 not discussed in this appendix. Transcoding issues are also not 645 discussed in this appendix. 646 647 This appendix provides guidance for applications presenting DN 648 strings to users. This section is not comprehensive; it does not 649 discuss all presentation issues that implementers may face. 650 651 Not all user interfaces are capable of displaying the full set of 652 Unicode characters. Some Unicode characters are not displayable. 653 654 It is recommended that human interfaces use the optional hex pair 655 escaping mechanism (Section 2.3) to produce a string representation 656 suitable for display to the user. For example, an application can 657 generate a DN string for display that escapes all non-printable 658 characters appearing in the AttributeValue's string representation 659 (as demonstrated in the final example of Section 4). 660 661 When a DN string is displayed in free-form text, it is often 662 necessary to distinguish the DN string from surrounding text. While 663 this is often done with whitespace (as demonstrated in Section 4), it 664 is noted that DN strings may end with whitespace. Careful readers of 665 Section 3 will note that the characters '<' (U+003C) and '>' (U+003E) 666 may only appear in the DN string if escaped. These characters are 667 intended to be used in free-form text to distinguish a DN string from 668 surrounding text. For example, <CN=Sam\ > distinguishes the string 669 representation of the DN composed of one RDN consisting of the AVA 670 (the commonName (CN) value 'Sam ') from the surrounding text. It 671 should be noted to the user that the wrapping '<' and '>' characters 672 are not part of the DN string. 673 674 DN strings can be quite long. It is often desirable to line-wrap 675 overly long DN strings in presentations. Line wrapping should be 676 done by inserting whitespace after the RDN separator character or, if 677 necessary, after the AVA separator character. It should be noted to 678 the user that the inserted whitespace is not part of the DN string 679 and is to be removed before use in LDAP. For example, the following 680 DN string is long: 681 682 683 684 685 Zeilenga Standards Track [Page 12] 686 688 RFC 4514 LDAP: Distinguished Names June 2006 689 690 691 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 692 O=OpenLDAP Foundation,ST=California,C=US 693 694 So it has been line-wrapped for readability. The extra whitespace is 695 to be removed before the DN string is used in LDAP. 696 697 Inserting whitespace is not advised because it may not be obvious to 698 the user which whitespace is part of the DN string and which 699 whitespace was added for readability. 700 701 Another alternative is to use the LDAP Data Interchange Format (LDIF) 702 [RFC2849]. For example: 703 704 # This entry has a long DN... 705 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 706 O=OpenLDAP Foundation,ST=California,C=US 707 CN: Kurt D. Zeilenga 708 SN: Zeilenga 709 objectClass: person 710 711 Appendix B. Changes Made since RFC 2253 712 713 This appendix is provided for informational purposes only, it is not 714 a normative part of this specification. 715 716 The following substantive changes were made to RFC 2253: 717 718 - Removed IESG Note. The IESG Note has been addressed. 719 - Replaced all references to ISO 10646-1 with [Unicode]. 720 - Clarified (in Section 1) that this document does not define a 721 canonical string representation. 722 - Clarified that Section 2 describes the RECOMMENDED encoding 723 algorithm and that alternative algorithms are allowed. Some 724 encoding options described in RFC 2253 are now treated as 725 alternative algorithms in this specification. 726 - Revised specification (in Section 2) to allow short names of any 727 registered attribute type to appear in string representations of 728 DNs instead of being restricted to a "published table". Removed 729 "as an example" language. Added statement (in Section 3) 730 allowing recognition of additional names but require recognition 731 of those names in the published table. The table now appears in 732 Section 3. 733 - Removed specification of additional requirements for LDAPv2 734 implementations which also support LDAPv3 (RFC 2253, Section 4) 735 as LDAPv2 is now Historic. 736 - Allowed recognition of alternative string representations. 737 - Updated Section 2.4 to allow hex pair escaping of all characters 738 and clarified escaping for when multiple octet UTF-8 encodings 739 740 741 742 Zeilenga Standards Track [Page 13] 743 745 RFC 4514 LDAP: Distinguished Names June 2006 746 747 748 are present. Indicated that null (U+0000) character is to be 749 escaped. Indicated that equals sign ('=' U+003D) character may 750 be escaped as '\='. 751 - Rewrote Section 3 to use ABNF as defined in RFC 4234. 752 - Updated the Section 3 ABNF. Changes include: 753 + allowed AttributeType short names of length 1 (e.g., 'L'), 754 + used more restrictive <oid> production in AttributeTypes, 755 + did not require escaping of equals sign ('=' U+003D) 756 characters, 757 + did not require escaping of non-leading number sign ('#' 758 U+0023) characters, 759 + allowed space (' ' U+0020) to be escaped as '\ ', 760 + required hex escaping of null (U+0000) characters, and 761 + removed LDAPv2-only constructs. 762 - Updated Section 3 to describe how to parse elements of the 763 grammar. 764 - Rewrote examples. 765 - Added reference to documentations containing general LDAP 766 security considerations. 767 - Added discussion of presentation issues (Appendix A). 768 - Added this appendix. 769 770 In addition, numerous editorial changes were made. 771 772 Editor's Address 773 774 Kurt D. Zeilenga 775 OpenLDAP Foundation 776 777 EMail: Kurt (a] OpenLDAP.org 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 Zeilenga Standards Track [Page 14] 800 802 RFC 4514 LDAP: Distinguished Names June 2006 803 804 805 Full Copyright Statement 806 807 Copyright (C) The Internet Society (2006). 808 809 This document is subject to the rights, licenses and restrictions 810 contained in BCP 78, and except as set forth therein, the authors 811 retain all their rights. 812 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 820 821 Intellectual Property 822 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 831 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 838 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr (a] ietf.org. 844 845 Acknowledgement 846 847 Funding for the RFC Editor function is provided by the IETF 848 Administrative Support Activity (IASA). 849 850 851 852 853 854 855 856 Zeilenga Standards Track [Page 15] 857 859
Indexes created Tue Sep 15 00:24:42 UTC 2026