1 2 3 4 5 6 7Network Working Group S. Kille 8Request for Comments: 2247 Isode Ltd. 9Category: Standards Track M. Wahl 10 Critical Angle Inc. 11 A. Grimstad 12 AT&T 13 R. Huber 14 AT&T 15 S. Sataluri 16 AT&T 17 January 1998 18 19 20 21 Using Domains in LDAP/X.500 Distinguished Names 22 23 24Status of this Memo 25 26 This document specifies an Internet standards track protocol for the 27 Internet community, and requests discussion and suggestions for 28 improvements. Please refer to the current edition of the "Internet 29 Official Protocol Standards" (STD 1) for the standardization state 30 and status of this protocol. Distribution of this memo is unlimited. 31 32Copyright Notice 33 34 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 361. Abstract 37 38 The Lightweight Directory Access Protocol (LDAP) uses X.500- 39 compatible distinguished names [3] for providing unique 40 identification of entries. 41 42 This document defines an algorithm by which a name registered with 43 the Internet Domain Name Service [2] can be represented as an LDAP 44 distinguished name. 45 462. Background 47 48 The Domain (Nameserver) System (DNS) provides a hierarchical resource 49 labeling system. A name is made up of an ordered set of components, 50 each of which are short strings. An example domain name with two 51 components would be "CRITICAL-ANGLE.COM". 52 53 54 55 56 57 58Kille, et. al. Standards Track [Page 1] 59 60RFC 2247 Using Domains in LDAP/X.500 January 1998 61 62 63 LDAP-based directories provide a more general hierarchical naming 64 framework. A primary difference in specification of distinguished 65 names from domain names is that each component of an distinguished 66 name has an explicit attribute type indication. 67 68 X.500 does not mandate any particular naming structure. It does 69 contain suggested naming structures which are based on geographic and 70 national regions, however there is not currently an established 71 registration infrastructure in many regions which would be able to 72 assign or ensure uniqueness of names. 73 74 The mechanism described in this document automatically provides an 75 enterprise a distinguished name for each domain name it has obtained 76 for use in the Internet. These distinguished names may be used to 77 identify objects in an LDAP directory. 78 79 An example distinguished name represented in the LDAP string format 80 [3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most 81 significant component, closest to the root of the namespace, is 82 written last. 83 84 This document does not define how to represent objects which do not 85 have domain names. Nor does this document define the procedure to 86 locate an enterprise's LDAP directory server, given their domain 87 name. Such procedures may be defined in future RFCs. 88 893. Mapping Domain Names into Distinguished Names 90 91 This section defines a subset of the possible distinguished name 92 structures for use in representing names allocated in the Internet 93 Domain Name System. It is possible to algorithmically transform any 94 Internet domain name into a distinguished name, and to convert these 95 distinguished names back into the original domain names. 96 97 The algorithm for transforming a domain name is to begin with an 98 empty distinguished name (DN) and then attach Relative Distinguished 99 Names (RDNs) for each component of the domain, most significant (e.g. 100 rightmost) first. Each of these RDNs is a single 101 AttributeTypeAndValue, where the type is the attribute "DC" and the 102 value is an IA5 string containing the domain name component. 103 104 Thus the domain name "CS.UCL.AC.UK" can be transformed into 105 106 DC=CS,DC=UCL,DC=AC,DC=UK 107 108 109 110 111 112 113 114Kille, et. al. Standards Track [Page 2] 115 116RFC 2247 Using Domains in LDAP/X.500 January 1998 117 118 119 Distinguished names in which there are one or more RDNs, all 120 containing only the attribute type DC, can be mapped back into domain 121 names. Note that this document does not define a domain name 122 equivalence for any other distinguished names. 123 1244. Attribute Type Definition 125 126 The DC (short for domainComponent) attribute type is defined as 127 follows: 128 129 ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match 130 SUBSTR caseIgnoreIA5SubstringsMatch 131 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) 132 133 The value of this attribute is a string holding one component of a 134 domain name. The encoding of IA5String for use in LDAP is simply the 135 characters of the string itself. The equality matching rule is case 136 insensitive, as is today's DNS. 137 1385. Object Class Definitions 139 140 An object with a name derived from its domain name using the 141 algorithm of section 3 is represented as an entry in the directory. 142 The "DC" attribute is present in the entry and used as the RDN. 143 144 An attribute can only be present in an entry held by an LDAP server 145 when that attribute is permitted by the entry's object class. 146 147 This section defines two object classes. The first, dcObject, is 148 intended to be used in entries for which there is an appropriate 149 structural object class. For example, if the domain represents a 150 particular organization, the entry would have as its structural 151 object class 'organization', and the 'dcObject' class would be an 152 auxiliary class. The second, domain, is a structural object class 153 used for entries in which no other information is being stored. The 154 domain object class is typically used for entries that are 155 placeholders or whose domains do not correspond to real-world 156 entities. 157 1585.1. The dcObject object class 159 160 The dcObject object class permits the dc attribute to be present in 161 an entry. This object class is defined as auxiliary, as it would 162 typically be used in conjunction with an existing structural object 163 class, such as organization, organizationalUnit or locality. 164 165 The following object class, along with the dc attribute, can be added 166 to any entry. 167 168 169 170Kille, et. al. Standards Track [Page 3] 171 172RFC 2247 Using Domains in LDAP/X.500 January 1998 173 174 175 ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc ) 176 177 An example entry would be: 178 179 dn: dc=critical-angle,dc=com 180 objectClass: top 181 objectClass: organization 182 objectClass: dcObject 183 dc: critical-angle 184 o: Critical Angle Inc. 185 1865.2. The domain object class 187 188 If the entry does not correspond to an organization, organizational 189 unit or other type of object for which an object class has been 190 defined, then the "domain" object class can be used. The "domain" 191 object class requires that the "DC" attribute be present, and permits 192 several other attributes to be present in the entry. 193 194 The entry will have as its structural object class the "domain" 195 object class. 196 197( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL 198 MUST dc 199 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ 200 x121Address $ registeredAddress $ destinationIndicator $ 201 preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ 202 telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ 203 street $ postOfficeBox $ postalCode $ postalAddress $ 204 physicalDeliveryOfficeName $ st $ l $ description $ o $ 205 associatedName ) ) 206 207 The optional attributes of the domain class are used for describing 208 the object represented by this domain, and may also be useful when 209 searching. These attributes are already defined for use with LDAP 210 [4]. 211 212 An example entry would be: 213 214 dn: dc=tcp,dc=critical-angle,dc=com 215 objectClass: top 216 objectClass: domain 217 dc: tcp 218 description: a placeholder entry used with SRV records 219 220 The DC attribute is used for naming entries of the domain class, and 221 this can be represented in X.500 servers by the following name form 222 rule. 223 224 225 226Kille, et. al. Standards Track [Page 4] 227 228RFC 2247 Using Domains in LDAP/X.500 January 1998 229 230 231 ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) ) 232 2336. References 234 235 [1] The Directory: Selected Attribute Types. ITU-T Recommendation 236 X.520, 1993. 237 238 [2] Mockapetris, P., " Domain Names - Concepts and Facilities," 239 STD 13, RFC 1034, November 1987. 240 241 [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol 242 (v3): UTF-8 String Representation of Distinguished Names", RFC 243 2253, December 1997. 244 245 [4] Wahl, M., "A Summary of the X.500(96) User Schema for use with 246 LDAP", RFC 2256, December 1997. 247 2487. Security Considerations 249 250 This memo describes how attributes of objects may be discovered and 251 retrieved. Servers should ensure that an appropriate security policy 252 is maintained. 253 254 An enterprise is not restricted in the information which it may store 255 in DNS or LDAP servers. A client which contacts an untrusted server 256 may have incorrect or misleading information returned (e.g. an 257 organization's server may claim to hold naming contexts representing 258 domain names which have not been delegated to that organization). 259 2608. Authors' Addresses 261 262 Steve Kille 263 Isode Ltd. 264 The Dome 265 The Square 266 Richmond, Surrey 267 TW9 1DT 268 England 269 270 Phone: +44-181-332-9091 271 EMail: S.Kille@ISODE.COM 272 273 274 275 276 277 278 279 280 281 282Kille, et. al. Standards Track [Page 5] 283 284RFC 2247 Using Domains in LDAP/X.500 January 1998 285 286 287 Mark Wahl 288 Critical Angle Inc. 289 4815 W. Braker Lane #502-385 290 Austin, TX 78759 291 USA 292 293 Phone: (1) 512 372 3160 294 EMail: M.Wahl@critical-angle.com 295 296 297 Al Grimstad 298 AT&T 299 Room 1C-429, 101 Crawfords Corner Road 300 Holmdel, NJ 07733-3030 301 USA 302 303 EMail: alg@att.com 304 305 306 Rick Huber 307 AT&T 308 Room 1B-433, 101 Crawfords Corner Road 309 Holmdel, NJ 07733-3030 310 USA 311 312 EMail: rvh@att.com 313 314 315 Sri Sataluri 316 AT&T 317 Room 4G-202, 101 Crawfords Corner Road 318 Holmdel, NJ 07733-3030 319 USA 320 321 EMail: sri@att.com 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338Kille, et. al. Standards Track [Page 6] 339 340RFC 2247 Using Domains in LDAP/X.500 January 1998 341 342 3439. Full Copyright Statement 344 345 Copyright (C) The Internet Society (1998). All Rights Reserved. 346 347 This document and translations of it may be copied and furnished to 348 others, and derivative works that comment on or otherwise explain it 349 or assist in its implementation may be prepared, copied, published 350 and distributed, in whole or in part, without restriction of any 351 kind, provided that the above copyright notice and this paragraph are 352 included on all such copies and derivative works. However, this 353 document itself may not be modified in any way, such as by removing 354 the copyright notice or references to the Internet Society or other 355 Internet organizations, except as needed for the purpose of 356 developing Internet standards in which case the procedures for 357 copyrights defined in the Internet Standards process must be 358 followed, or as required to translate it into languages other than 359 English. 360 361 The limited permissions granted above are perpetual and will not be 362 revoked by the Internet Society or its successors or assigns. 363 364 This document and the information contained herein is provided on an 365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394Kille, et. al. Standards Track [Page 7] 395 396