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