idnits 2.17.1 draft-zeilenga-ldapv3bis-rfc2253-00.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? 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 383 has weird spacing: '...for the purpo...' -- 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 (4 July 2000) is 8691 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) -- Looks like a reference, but probably isn't: 'RFC 2253' on line 43 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2251 (ref. '3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (ref. '4') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires: 4 January 2001 4 July 2000 6 LDAPv3bis Suggestions: 7 UTF-8 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 Distribution of this memo is unlimited. Technical discussion of this 18 document will take place on the IETF LDAP Extension Working Group 19 mailing list . Please send editorial 20 comments directly to the author . 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 32 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 34 Copyright 2000, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Forward 41 This Internet Draft suggests a number of updates to the "Lightweight 42 Directory Access Protocol: UTF-8 String Representation of 43 Distinguished Names" [RFC 2253]. This document is not intended to be 44 published as an RFC but used to identify LDAPv3bis work items. 46 The remainer of this documents incorporates the substantive portion of 47 RFC 2253 text (less status of memo, appendices, etc). Comments and 48 suggested updates to this text are inserted as inline notes prefixed 49 with '//'. 51 // Start of RFC 2253 text 53 Abstract 55 The X.500 Directory uses distinguished names as the primary keys to 56 entries in the directory. Distinguished Names are encoded in ASN.1 in 57 the X.500 Directory protocols. In the Lightweight Directory Access 58 Protocol, a string representation of distinguished names is 59 transferred. This specification defines the string format for 60 representing names, which is designed to give a clean representation 61 of commonly used distinguished names, while being able to represent 62 any distinguished name. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [6]. 68 1. Background 70 This specification assumes familiarity with X.500 [1], and the concept 71 of Distinguished Name. It is important to have a common format to be 72 able to unambiguously represent a distinguished name. The primary 73 goal of this specification is ease of encoding and decoding. A 74 secondary goal is to have names that are human readable. It is not 75 expected that LDAP clients with a human user interface would display 76 these strings directly to the user, but would most likely be 77 performing translations (such as expressing attribute type names in 78 one of the local national languages). 80 2. Converting DistinguishedName from ASN.1 to a String 82 In X.501 [2] the ASN.1 structure of distinguished name is defined as: 84 DistinguishedName ::= RDNSequence 86 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 88 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 89 AttributeTypeAndValue 91 AttributeTypeAndValue ::= SEQUENCE { 92 type AttributeType, 93 value AttributeValue } 95 The following sections define the algorithm for converting from an 96 ASN.1 structured representation to a UTF-8 string representation. 98 2.1. Converting the RDNSequence 100 If the RDNSequence is an empty sequence, the result is the empty or 101 zero length string. 103 Otherwise, the output consists of the string encodings of each 104 RelativeDistinguishedName in the RDNSequence (according to 2.2), 105 starting with the last element of the sequence and moving backwards 106 toward the first. 108 The encodings of adjoining RelativeDistinguishedNames are separated by 109 a comma character (',' ASCII 44). 111 2.2. Converting RelativeDistinguishedName 113 When converting from an ASN.1 RelativeDistinguishedName to a string, 114 the output consists of the string encodings of each 115 AttributeTypeAndValue (according to 2.3), in any order. 117 Where there is a multi-valued RDN, the outputs from adjoining 118 AttributeTypeAndValues are separated by a plus ('+' ASCII 43) 119 character. 121 2.3. Converting AttributeTypeAndValue 123 The AttributeTypeAndValue is encoded as the string representation of 124 the AttributeType, followed by an equals character ('=' ASCII 61), 125 followed by the string representation of the AttributeValue. The 126 encoding of the AttributeValue is given in section 2.4. 128 If the AttributeType is in a published table of attribute types 129 associated with LDAP [4], then the type name string from that table is 130 used, otherwise it is encoded as the dotted-decimal encoding of the 131 AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is 132 described in [3]. As an example, strings for a few of the attribute 133 types frequently seen in RDNs include: 135 String X.500 AttributeType 136 ------------------------------ 137 CN commonName 138 L localityName 139 ST stateOrProvinceName 140 O organizationName 141 OU organizationalUnitName 142 C countryName 143 STREET streetAddress 144 DC domainComponent 145 UID userid 147 2.4. Converting an AttributeValue from ASN.1 to a String 149 If the AttributeValue is of a type which does not have a string 150 representation defined for it, then it is simply encoded as an 151 octothorpe character ('#' ASCII 35) followed by the hexadecimal 152 representation of each of the bytes of the BER encoding of the X.500 153 AttributeValue. This form SHOULD be used if the AttributeType is of 154 the dotted-decimal form. 156 Otherwise, if the AttributeValue is of a type which has a string 157 representation, the value is converted first to a UTF-8 string 158 according to its syntax specification (see for example section 6 of 159 [4]). 161 If the UTF-8 string does not have any of the following characters 162 which need escaping, then that string can be used as the string 163 representation of the value. 165 o a space or "#" character occurring at the beginning of the 166 string 168 o a space character occurring at the end of the string 170 o one of the characters ",", "+", """, "\", "<", ">" or ";" 172 Implementations MAY escape other characters. 174 If a character to be escaped is one of the list shown above, then it 175 is prefixed by a backslash ('\' ASCII 92). 177 Otherwise the character to be escaped is replaced by a backslash and 178 two hex digits, which form a single byte in the code of the character. 180 Examples of the escaping mechanism are shown in section 5. 182 3. Parsing a String back to a Distinguished Name 184 The structure of the string is specified in a BNF grammar, based on 185 the grammar defined in RFC 822 [5]. Server implementations parsing a 186 DN string generated by an LDAPv2 client MUST also accept (and ignore) 187 the variants given in section 4 of this document. 189 distinguishedName = [name] ; may be empty string 190 name = name-component *("," name-component) 192 name-component = attributeTypeAndValue *("+" attributeTypeAndValue) 194 attributeTypeAndValue = attributeType "=" attributeValue 196 attributeType = (ALPHA 1*keychar) / oid 197 keychar = ALPHA / DIGIT / "-" 199 oid = 1*DIGIT *("." 1*DIGIT) 201 attributeValue = string 203 string = *( stringchar / pair ) 204 / "#" hexstring 205 / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2 207 quotechar = 209 special = "," / "=" / "+" / "<" / ">" / "#" / ";" 211 pair = "\" ( special / "\" / QUOTATION / hexpair ) 212 stringchar = 214 hexstring = 1*hexpair 215 hexpair = hexchar hexchar 217 hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 218 / "a" / "b" / "c" / "d" / "e" / "f" 220 ALPHA = 221 ; (decimal 65-90 and 97-122) 222 DIGIT = ; (decimal 48-57) 223 QUOTATION = 226 4. Relationship with RFC 1779 and LDAPv2 228 The syntax given in this document is more restrictive than the syntax 229 in RFC 1779. Implementations parsing a string generated by an LDAPv2 230 client MUST accept the syntax of RFC 1779. Implementations MUST NOT, 231 however, generate any of the RFC 1779 encodings which are not 232 described above in section 2. 234 Implementations MUST allow a semicolon character to be used instead of 235 a comma to separate RDNs in a distinguished name, and MUST also allow 236 whitespace characters to be present on either side of the comma or 237 semicolon. The whitespace characters are ignored, and the semicolon 238 replaced with a comma. 240 Implementations MUST allow an oid in the attribute type to be prefixed 241 by one of the character strings "oid." or "OID.". 243 Implementations MUST allow for space (' ' ASCII 32) characters to be 244 present between name-component and ',', between attributeTypeAndValue 245 and '+', between attributeType and '=', and between '=' and 246 attributeValue. These space characters are ignored when parsing. 248 Implementations MUST allow a value to be surrounded by quote ('"' 249 ASCII 34) characters, which are not part of the value. Inside the 250 quoted value, the following characters can occur without any escaping: 252 ",", "=", "+", "<", ">", "#" and ";" 254 5. Examples 256 This notation is designed to be convenient for common forms of name. 257 This section gives a few examples of distinguished names written using 258 this notation. First is a name containing three relative 259 distinguished names (RDNs): 261 CN=Steve Kille,O=Isode Limited,C=GB 263 Here is an example name containing three RDNs, in which the first RDN 264 is multi-valued: 266 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 268 This example shows the method of quoting of a comma in an organization 269 name: 271 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 273 An example name in which a value contains a carriage return character: 275 CN=Before\0DAfter,O=Test,C=GB 277 An example name in which an RDN was of an unrecognized type. The 278 value is the BER encoding of an OCTET STRING containing two bytes 0x48 279 and 0x69. 281 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 283 Finally, an example of an RDN surname value consisting of 5 letters: 285 Unicode Letter Description 10646 code UTF-8 Quoted 286 =============================== ========== ====== ======= 287 LATIN CAPITAL LETTER L U0000004C 0x4C L 288 LATIN SMALL LETTER U U00000075 0x75 u 289 LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D 290 LATIN SMALL LETTER I U00000069 0x69 i 291 LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87 293 Could be written in printable ASCII (useful for debugging purposes): 295 SN=Lu\C4\8Di\C4\87 297 6. References 299 [1] The Directory -- overview of concepts, models and services. 300 ITU-T Rec. X.500(1993). 302 [2] The Directory -- Models. ITU-T Rec. X.501(1993). 304 [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 305 Access Protocol (v3)", RFC 2251, December 1997. 307 [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight 308 Directory Access Protocol (v3): Attribute Syntax Definitions", 309 RFC 2252, December 1997. 311 [5] Crocker, D., "Standard of the Format of ARPA-Internet Text 312 Messages", STD 11, RFC 822, August 1982. 314 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 315 Levels", RFC 2119. 317 7. Security Considerations 319 // Add consideration requiring the use of strong authentication 320 // to update the directory. 322 7.1. Disclosure 324 Distinguished Names typically consist of descriptive information about 325 the entries they name, which can be people, organizations, devices or 326 other real-world objects. This frequently includes some of the 327 following kinds of information: 329 - the common name of the object (i.e. a person's full name) - an email 330 or TCP/IP address - its physical location (country, locality, city, 331 street address) - organizational attributes (such as department name 332 or affiliation) 333 Most countries have privacy laws regarding the publication of 334 information about people. 336 7.2. Use of Distinguished Names in Security Applications 338 The transformations of an AttributeValue value from its X.501 form to 339 an LDAP string representation are not always reversible back to the 340 same BER or DER form. An example of a situation which requires the 341 DER form of a distinguished name is the verification of an X.509 342 certificate. 344 For example, a distinguished name consisting of one RDN with one AVA, 345 in which the type is commonName and the value is of the TeletexString 346 choice with the letters 'Sam' would be represented in LDAP as the 347 string CN=Sam. Another distinguished name in which the value is still 348 'Sam' but of the PrintableString choice would have the same 349 representation CN=Sam. 351 Applications which require the reconstruction of the DER form of the 352 value SHOULD NOT use the string representation of attribute syntaxes 353 when converting a distinguished name to the LDAP format. Instead, 354 they SHOULD use the hexadecimal form prefixed by the octothorpe ('#') 355 as described in the first paragraph of section 2.4. 357 // remainder trimmed 359 // End of RFC 2253 text 361 Additional Information 363 Discussions regarding these suggestions may directed to the author: 365 Kurt D. Zeilenga 366 OpenLDAP Foundation 367 369 or the LDAPext Working Group mailing list: 371 373 Copyright 2000, The Internet Society. All Rights Reserved. 375 This document and translations of it may be copied and furnished 376 to others, and derivative works that comment on or otherwise explain 377 it or assist in its implementation may be prepared, copied, published 378 and distributed, in whole or in part, without restriction of any 379 kind, provided that the above copyright notice and this paragraph 380 are included on all such copies and derivative works. However, 381 this document itself may not be modified in any way, such as by 382 removing the copyright notice or references to the Internet Society 383 or other Internet organizations, except as needed for the purpose 384 of developing Internet standards in which case the procedures for 385 copyrights defined in the Internet Standards process must be 386 followed, or as required to translate it into languages other than 387 English. 389 The limited permissions granted above are perpetual and will not 390 be revoked by the Internet Society or its successors or assigns. 392 This document and the information contained herein is provided on 393 an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE 394 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 395 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 396 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 397 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 398 PURPOSE.