idnits 2.17.1 draft-ietf-ldapbis-dn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 458 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 March 2002) is 8092 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Schema' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 1 March 2002 5 Obsoletes: 2253 7 LDAP: String Representation of Distinguished Names 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document 17 replacing RFC 2253. Distribution of this memo is unlimited. 18 Technical discussion of this document will take place on the IETF LDAP 19 Revision Working Group mailing list . 20 Please send editorial comments directly to the document editor 21 . 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 . The list of 33 Internet-Draft Shadow Directories can be accessed at 34 . 36 Copyright 2002, The Internet Society. All Rights Reserved. 38 Please see the Copyright section near the end of this document for 39 more information. 41 Abstract 43 The X.500 Directory uses distinguished names as the primary keys to 44 entries in the directory. Distinguished Names are encoded in ASN.1 in 45 the X.500 Directory protocols. In the Lightweight Directory Access 46 Protocol, a string representation of distinguished names is 47 transferred. This specification defines the string format for 48 representing names, which is designed to give a clean representation 49 of commonly used distinguished names, while being able to represent 50 any distinguished name. 52 1. Background 54 This specification assumes familiarity with X.500 [X.500], and the 55 concept of Distinguished Name (DN). It is important to have a common 56 format to be able to unambiguously represent a distinguished name. 57 The primary goal of this specification is ease of encoding and 58 decoding. A secondary goal is to have names that are human readable. 59 It is not expected that LDAP clients with a human user interface would 60 display these strings directly to the user, but would most likely be 61 performing translations (such as expressing attribute type names in 62 one of the local national languages). 64 This document is an integral part of the LDAP Technical Specification 65 [Roadmap]. 67 This document obsoletes RFC 2253. Changes since RFC 2253 are 68 summarized in Appendix A. 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in BCP 14 [RFC2119]. 74 2. Converting DistinguishedName from ASN.1 to a String 76 In X.501 [X.501] the ASN.1 structure of distinguished name is defined 77 as: 79 DistinguishedName ::= RDNSequence 81 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 83 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 84 AttributeTypeAndValue 86 AttributeTypeAndValue ::= SEQUENCE { 87 type AttributeType, 88 value AttributeValue } 90 The following sections define the RECOMMENDED algorithm for converting 91 from an ASN.1 structured representation to a UTF-8 [RFC2279] string 92 representation. 94 2.1. Converting the RDNSequence 96 If the RDNSequence is an empty sequence, the result is the empty or 97 zero length string. 99 Otherwise, the output consists of the string encodings of each 100 RelativeDistinguishedName in the RDNSequence (according to 2.2), 101 starting with the last element of the sequence and moving backwards 102 toward the first. 104 The encodings of adjoining RelativeDistinguishedNames are separated by 105 a comma character ("," ASCII 44). 107 2.2. Converting RelativeDistinguishedName 109 When converting from an ASN.1 RelativeDistinguishedName to a string, 110 the output consists of the string encodings of each 111 AttributeTypeAndValue (according to 2.3), in any order. 113 Where there is a multi-valued RDN, the outputs from adjoining 114 AttributeTypeAndValues are separated by a plus ("+" ASCII 43) 115 character. 117 2.3. Converting AttributeTypeAndValue 119 The AttributeTypeAndValue is encoded as the string representation of 120 the AttributeType, followed by an equals character ("=" ASCII 61), 121 followed by the string representation of the AttributeValue. The 122 encoding of the AttributeValue is given in Section 2.4. 124 If the AttributeType is in the following table of attribute types 125 associated with LDAP [Schema], then the type name string from that 126 table is used, otherwise it is encoded as the dotted-decimal encoding 127 of the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation 128 (numericoid) is described in [Models]. 130 The type name string is not case sensitive. 132 String X.500 AttributeType 133 ------ -------------------------------------------- 134 CN commonName (2.5.4.3) 135 L localityName (2.5.4.7) 136 ST stateOrProvinceName (2.5.4.8) 137 O organizationName (2.5.4.10) 138 OU organizationalUnitName (2.5.4.11) 139 C countryName (2.5.4.6) 140 STREET streetAddress (2.5.4.9) 141 DC domainComponent (0.9.2342.19200300.100.1.25) 142 UID userId (0.9.2342.19200300.100.1.1) 144 2.4. Converting an AttributeValue from ASN.1 to a String 146 If the AttributeValue is of a type which does not have a string 147 representation defined for it, then it is simply encoded as an 148 octothorpe character ("#" ASCII 35) followed by the hexadecimal 149 representation of each of the octets of the BER encoding of the X.500 150 AttributeValue. This form is also be used if the AttributeType is of 151 the dotted-decimal form. 153 Otherwise, if the AttributeValue is of a type which has a string 154 representation, the value is converted first to a UTF-8 string 155 according to its syntax specification (see for example Section 6 of 156 [Syntaxes]). 158 If the UTF-8 string does not have any of the following characters 159 which need escaping, then that string can be used as the string 160 representation of the value. 162 - a space (" " ASCII 32) or octothorpe ("#" ASCII 35) occurring at 163 the beginning of the string 165 - a space (" " ASCII 32) character occurring at the end of the 166 string 168 - one of the characters ",", "+", """, "\", "<", ">" or ";" (ASCII 169 44, 43, 34, 92, 60, 62, or 59, respectively) 171 - the null (ASCII 0) character 173 Implementations MAY escape other characters. 175 Each octet of the character to be escaped is replaced by a backslash 176 and two hex digits, which form a single octet in the code of the 177 character. Alternatively, if and only if the character to be escaped 178 is one of 180 ",", "+", """, "\", "<", ">", ";", "#", "=", or " " 181 (ASCII 44, 43, 34, 92, 60, 62, 59, 35, 61 or 32 respectively) 183 it can be prefixed by a backslash ("\" ASCII 92). 185 Examples of the escaping mechanism are shown in Section 4. 187 3. Parsing a String back to a Distinguished Name 189 The structure of the UTF-8 [RFC2279] string is specified using the 190 following Augmented BNF [RFC2234] grammar. 192 distinguishedName = [name] 193 ; may be empty 195 name = name-component *(COMMA name-component) 197 name-component = attributeTypeAndValue *(PLUS attributeTypeAndValue) 199 attributeTypeAndValue 200 = attributeType EQUALS attributeValue 202 attributeType = keyword / oid 204 keyword = ALPHA 1*keychar 206 keychar = ALPHA / DIGIT / MINUS 208 oid = number *(DOT number) 210 number = ( LDIGIT *DIGIT ) / DIGIT 212 attributeValue = string / hexstring 214 string = *( stringchar / pair ) 215 ; the string MUST NOT start with SHARP or SP 216 ; and MUST NOT end with SP 218 stringchar = 221 pair = ESC ( ESC / special / hexpair ) 223 special = escaped / SHARP / EQUALS / SP 225 escaped = COMMA / PLUS / %x22 / %x3C / %x3E / %x3B 226 ; "," / "+" / """ / "<" / ">" / ";" 228 hexstring = SHARP 1*hexpair 230 hexpair = HEX HEX 232 HEX = DIGIT / %x41-46 / %x61-66 233 ; 0-9 / A-F / a-f 235 ALPHA = %x41-5A / %x61-7A 236 ; A-Z / a-z 238 LDIGIT = %x31-39 239 ; 1-9 241 DIGIT = %x30 / LDIGIT 242 ; 0-9 244 SP = %x20 ; space (" ") 245 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 246 PLUS = %x2B ; plus sign ("+") 247 COMMA = %x2C ; comma (",") 248 MINUS = %x2D ; minus sign ("-") 249 DOT = %x2E ; period (".") 250 EQUALS = %x3D ; equals sign ("=") 251 ESC = %x5C ; backslash ("\") 252 NULL = %x00 ; null (0) 254 Implementations MUST recognize AttributeType string type names 255 (keywords) listed in the Section 2.3 table, but MAY recognize other 256 names. Implementations MAY recognize other DN string representations 257 (such as that described in RFC 1779). As there is no requirement for 258 other names or alternative DN string representations to be recognized, 259 implementations SHOULD only generate DN strings in accordance with 260 Section 2 of this document. 262 4. Examples 264 This notation is designed to be convenient for common forms of name. 265 This section gives a few examples of distinguished names written using 266 this notation. First is a name containing three relative 267 distinguished names (RDNs): 269 UID=jsmith,DC=example,DC=net 271 Here is an example name containing three RDNs, in which the first RDN 272 is multi-valued: 274 OU=Sales+CN=J. Smith,DC=example,DC=net 276 This example shows the method of escaping of a comma in a common name: 278 CN=John Smith\, III,DC=example,DC=net 280 An example name in which a value contains a carriage return character: 282 CN=Before\0dAfter,DC=example,DC=net 284 An example name in which an RDN was of an unrecognized type. The 285 value is the BER encoding of an OCTET STRING containing two octets 286 0x48 and 0x69. 288 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 290 Finally, an example of an RDN commonName value consisting of 5 291 letters: 293 Unicode Letter Description 10646 code UTF-8 Quoted 294 =============================== ========== ====== ======= 295 LATIN CAPITAL LETTER L U+0000004C 0x4C L 296 LATIN SMALL LETTER U U+00000075 0x75 u 297 LATIN SMALL LETTER C WITH CARON U+0000010D 0xC48D \C4\8D 298 LATIN SMALL LETTER I U+00000069 0x69 i 299 LATIN SMALL LETTER C WITH ACUTE U+00000107 0xC487 \C4\87 301 could be written in printable ASCII (useful for debugging purposes): 303 CN=Lu\C4\8Di\C4\87 305 5. Security Considerations 307 The following security considerations are specific to the handling of 308 distinguished names. LDAP security considerations are discussed in 309 [Protocol] and other documents comprising the LDAP Technical 310 Specification [Roadmap]. 312 5.1. Disclosure 314 Distinguished Names typically consist of descriptive information about 315 the entries they name, which can be people, organizations, devices or 316 other real-world objects. This frequently includes some of the 317 following kinds of information: 319 - the common name of the object (i.e. a person's full name) 320 - an email or TCP/IP address 321 - its physical location (country, locality, city, street address) 322 - organizational attributes (such as department name or affiliation) 324 Most countries have privacy laws regarding the publication of 325 information about people. 327 5.2. Use of Distinguished Names in Security Applications 329 The transformations of an AttributeValue value from its X.501 form to 330 an LDAP string representation are not always reversible back to the 331 same BER or DER form. An example of a situation which requires the 332 DER form of a distinguished name is the verification of an X.509 333 certificate. 335 For example, a distinguished name consisting of one RDN with one AVA, 336 in which the type is commonName and the value is of the TeletexString 337 choice with the letters 'Sam' would be represented in LDAP as the 338 string CN=Sam. Another distinguished name in which the value is still 339 'Sam' but of the PrintableString choice would have the same 340 representation CN=Sam. 342 Applications which require the reconstruction of the DER form of the 343 value SHOULD NOT use the string representation of attribute syntaxes 344 when converting a distinguished name to the LDAP format. Instead, 345 they SHOULD use the hexadecimal form prefixed by the octothorpe ('#') 346 as described in the first paragraph of Section 2.3. 348 5.3. Use of Other Names 350 Attribute type names are not unique. A string representation 351 generated with names other than those in the Section 2.3 table is 352 ambiguous. That is, two applications may recognize the string as 353 representing two different DNs possibly associated with two different 354 entries. This may lead to a wide range of unexpected behaviors which 355 can have both direct and indirect impacts upon security. 357 For example, a distinguished name consisting of one RDN with one AVA 358 of the known locally attribute type FOO and the value "BAR" (an 359 octetString) could be represented in LDAP as the string FOO=BAR. As 360 the name FOO does not uniquely identify an attribute type, the DN 361 FOO=BAR is ambiguous. That is, FOO could be recognized as the 362 attribute type 1.1.1 by one application and 1.2.3.4 in another and not 363 recognized by another. This may lead to operations not behaving as 364 intended. 366 Applications desiring to generate an unambiguous string representation 367 of a DN SHOULD generate string representation per section 2, not use 368 names other than those in the Section 2.3 table, and while taking 5.2 369 into consideration. 371 6. Acknowledgment 372 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 373 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 375 This document is a product of the IETF LDAPbis Working Group. 377 7. Document Editor's Address 379 Kurt D. Zeilenga 380 OpenLDAP Foundation 381 383 8. Normative References 385 [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993). 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", RFC 2119. 390 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 391 Specifications: ABNF", RFC 2234, November 1997. 393 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 394 10646", RFC 2279, January 1998. 396 [Models] K. Zeilenga (editor), "LDAP: Directory Information 397 Models", draft-ietf-ldapbis-models-xx.txt, a work in 398 progress. 400 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 401 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 402 progress. 404 [Protocol] J. Sermersheim (editor), "LDAP: The Protocol", 405 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 407 [Syntaxes] K. Dally (editor), "LDAP: Syntaxes", 408 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 410 [Schema] K. Dally (editor), "LDAP: User Schema", 411 draft-ietf-ldapbis-user-schema-xx.txt, a work in 412 progress. 414 9. Informative References 416 [X.500] "The Directory -- overview of concepts, models and 417 services," ITU-T Rec. X.500(1993). 419 Appendix A. Changes made since RFC 2253 421 This appendix is provided for informational purposes only, it is not a 422 normative part of this specification. 424 The following substantive changes were made to RFC 2253: 425 - Removed IESG Note. The IESG Note is addressed by RFC 2829. 426 - Replaced specification of additional requirements for LDAPv2 427 implementations which also support LDAPv3 (Section 4) with a 428 statement (in Section 3) allowing recognition of alternative 429 string representations. 430 - Updated 2.3 to clarify which table is the published table of names 431 which may be appear in DNs. Remove "as an example" language. 432 Added statement (in Section 3) allowing recognition of additional 433 names. Added security consideration (Section 5.3) regarding the 434 use of other names. 435 - Updated 2.3 to indicate attribute type name strings are not case 436 sensitive. 437 - Updated 2.4 to allow hex pair escaping of all characters and 438 clarified escaping for when multiple octet UTF-8 characters are 439 present. 440 - Rewrote Section 3 to use ABNF as defined in RFC 2234. 441 - Rewrote Section 3 ABNF to be consistent with 2.4. 442 - Rewrote examples. 443 - Added reference to documentations containing LDAP-specific 444 security considerations. 446 In addition, numerous editorial changes were made. 448 Copyright 2002, The Internet Society. All Rights Reserved. 450 This document and translations of it may be copied and furnished to 451 others, and derivative works that comment on or otherwise explain it 452 or assist in its implementation may be prepared, copied, published and 453 distributed, in whole or in part, without restriction of any kind, 454 provided that the above copyright notice and this paragraph are 455 included on all such copies and derivative works. However, this 456 document itself may not be modified in any way, such as by removing 457 the copyright notice or references to the Internet Society or other 458 Internet organizations, except as needed for the purpose of 459 developing Internet standards in which case the procedures for 460 copyrights defined in the Internet Standards process must be followed, 461 or as required to translate it into languages other than English. 463 The limited permissions granted above are perpetual and will not be 464 revoked by the Internet Society or its successors or assigns. 466 This document and the information contained herein is provided on an 467 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 468 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 469 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 470 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.