1 2 3 4 5 6 7 Network Working Group A. Grimstad 8 Request for Comments: 2377 R. Huber 9 Category: Informational AT&T 10 S. Sataluri 11 Lucent Technologies 12 M. Wahl 13 Critical Angle Inc. 14 September 1998 15 16 17 Naming Plan for Internet Directory-Enabled Applications 18 19 Status of this Memo 20 21 This memo provides information for the Internet community. It does 22 not specify an Internet standard of any kind. Distribution of this 23 memo is unlimited. 24 25 Copyright Notice 26 27 Copyright (C) The Internet Society (1998). All Rights Reserved. 28 29 Abstract 30 31 Application of the conventional X.500 approach to naming has 32 heretofore, in the experience of the authors, proven to be an 33 obstacle to the wide deployment of directory-enabled applications on 34 the Internet. We propose a new directory naming plan that leverages 35 the strengths of the most popular and successful Internet naming 36 schemes for naming objects in a hierarchical directory. This plan 37 can, we believe, by extending the X.500 approach to naming, 38 facilitate the creation of an Internet White Pages Service (IWPS) and 39 other directory-enabled applications by overcoming the problems 40 encountered by those using the conventional X.500 approach. 41 42 1.0 Executive Summary 43 44 Application of the conventional X.500 approach to naming has 45 heretofore, in the experience of the authors, proven to be an 46 obstacle to the wide deployment of directory-enabled applications on 47 the Internet. The required registration infrastructure is either 48 non-existent or largely ignored. The infrastructure that does exist 49 is cumbersome to use and tends to produce counterproductive results. 50 The attributes used for naming have been confusing for users and 51 inflexible to managers and operators of directory servers. 52 53 54 55 56 57 58 Grimstad, et. al. Informational [Page 1] 59 61 RFC 2377 A Directory Naming Plan September 1998 62 63 64 This paper describes a directory naming plan for the construction of 65 an Internet directory infrastructure to support directory-enabled 66 applications that can serve as an alternative (or extension) to the 67 conventional X.500 approach. 68 69 The plan has the following two main features. First, it bases the 70 root and upper portions of the name hierarchy on the existing 71 infrastructure of names from the Domain Name System (DNS). This 72 component of the plan makes use of the ideas described in the 73 companion paper to this plan, "Using Domains in LDAP Distinguished 74 Names" [1]. And second, it provides a number of options for the 75 assignment of names to directory leaf objects such as person objects, 76 including an option that allows the reuse of existing Internet 77 identifiers for people. 78 79 Just as the conventional X.500 style of naming is not a formal 80 standard, use of the naming plan described here is not obligatory for 81 directory-enabled applications on the Internet. Other approaches are 82 permissible. However, we believe widespread use of this plan will 83 largely eliminate naming as a typically thorny issue when 84 administrators set up an LDAP-based directory service. Further, we 85 strongly encourage developers of directory-enabled products, 86 especially LDAP clients and user interfaces, to assume that this 87 naming plan will see widespread use and design their products 88 accordingly. 89 90 Here, in summary, is our proposal. 91 92 The upper portions of the hierarchical directory tree should be 93 constructed using the components of registered DNS names using the 94 domain component attribute "dc". The directory name for the 95 organization having the domain name "acme.com" will then be, e.g., 96 97 dc=acme, dc=com 98 99 Organizations can add additional directory structure, for example to 100 support implementation of access control lists or partitioning of 101 their directory information, by using registered subdomains of DNS 102 names, e.g., the subdomain "corporate.acme.com" can be used as the 103 basis for the directory name 104 105 dc=corporate, dc=acme, dc=com 106 107 For naming directory leaf objects such as persons, groups, server 108 applications and certification authorities in a hierarchical 109 directory, we propose the use of either the "uid" (user identifier) 110 or the "cn" (common name) attribute for the relative distinguished 111 name. This plan does not constrain how these two attributes are used. 112 113 114 115 Grimstad, et. al. Informational [Page 2] 116 118 RFC 2377 A Directory Naming Plan September 1998 119 120 121 One approach to their use, for example, is to employ the uid 122 attribute as the RDN when reusing an existing store of identifiers 123 and the cn attribute as the RDN when creating new identifiers 124 specifically for the directory. A convenient existing identification 125 scheme for person objects is the RFC822 mailbox identifier. So an RDN 126 for person employing this store of identifiers would be, e.g., 127 128 uid=John.Smith (a] acme.com 129 130 For leaf objects not conveniently identified with such a scheme, the 131 "cn" attribute is used, e.g., 132 133 cn=Reading Room 134 135 Directory distinguished names will thus have the following structure, 136 e.g., 137 138 uid=John.Smith (a] acme.com, dc=acme, dc=com 139 uid=Mary.Jones (a] acme.com, dc=corporate, dc=acme, dc=com 140 uid=J.Smith (a] worldnet.att.net, dc=legal, dc=acme, dc=com 141 cn=Reading Room, dc=physics, dc=national-lab, dc=edu 142 143 2.0 The Problem 144 145 The X.500 Directory model [2] can be used to create a world-wide 146 distributed directory. The Internet X.500 Directory Pilot has been 147 operational for several years and has grown to a size of about 1.5 148 million entries of varying quality. The rate of growth of the pilot 149 is far lower than the rate of growth of the Internet during the pilot 150 period. 151 152 There are a substantial number of contributing factors that have 153 inhibited the growth of this pilot. The common X.500 approach to 154 naming, while not the preponderant problem, has contributed in 155 several ways to limit the growth of an Internet White Pages Service 156 based on X.500. 157 158 The conventional way to construct names in the X.500 community is 159 documented as an informative (i.e., not officially standardized) 160 Annex B to X.521. The relative distinguished name (RDN) of a user 161 consists of a common name (cn) attribute. This is meant to be what -- 162 in the user's particular society -- is customarily understood to be 163 the name of that user. The distinguished name of a user is the 164 combination of the name of some general object, such as an 165 organization or a geographical unit, with the common name. There are 166 two main problems with this style of name construction. 167 168 169 170 171 172 Grimstad, et. al. Informational [Page 3] 173 175 RFC 2377 A Directory Naming Plan September 1998 176 177 178 First, the common name attribute, while seeming to be user-friendly, 179 cannot be used generally as an RDN in practice. In any significant 180 set of users to be named under the same Directory Information Tree 181 (DIT) node there will be collisions on common name. There is no way 182 to overcome this other than either by forcing uniqueness on common 183 names, something they do not possess, or by using an additional 184 attribute to prevent collisions. This additional attribute normally 185 needs to be unique in a much larger context to have any practical 186 value. The end result is a RDN that is very long and unpopular with 187 users. 188 189 Second, and more serious, X.500 has not been able to use any 190 significant number of pre-existing names. Since X.500 naming models 191 typically use organization names as part of the hierarchy [2, 3], 192 organization names must be registered. As organization names are 193 frequently tied to trademarks and are used in sales and promotions, 194 registration can be a difficult and acrimonious process. 195 196 The North American Directory Forum (NADF, now the North Atlantic 197 Directory Forum but still the NADF) proposed to avoid the problem of 198 registration by using names that were already registered in the 199 "civil naming infrastructure" [4][5]. Directory distinguished names 200 would be based on an organization's legal name as recognized by some 201 governmental agency (county clerk, state secretary of state, etc.) or 202 other registering entity such as ANSI. 203 204 This scheme has the significant advantage of keeping directory 205 service providers out of disputes about the right to use a particular 206 name, but it leads to rather obscure names. Among these obscurities, 207 the legal name almost invariably takes a form that is less familiar 208 and longer than what users typically associate with the organization. 209 For example, in the US a large proportion of legal organization names 210 end with the text ", Inc." as in "Acme, Inc." Moreover, in the case 211 of the US, the civil naming infrastructure does not operate 212 nationally, so the organization names it provides must be located 213 under state and regional DIT nodes, making them difficult to find 214 while browsing the directory. NADF proposes a way to algorithmically 215 derive multi-attribute RDNs which would allow placement of entries or 216 aliases in more convenient places in the DIT, but these derived names 217 are cumbersome and unpopular. For example, suppose Nadir is an 218 organization that is registered in New Jersey civil naming 219 infrastructure under the name "Nadir Networks, Inc." Its civil 220 distinguished name (DN) would then be 221 222 o="Nadir Networks, Inc.", st=New Jersey, c=US 223 224 225 226 227 228 229 Grimstad, et. al. Informational [Page 4] 230 232 RFC 2377 A Directory Naming Plan September 1998 233 234 235 while its derived name which is unambiguous under c=US directly is 236 237 o="Nadir Networks, Inc." + st=New Jersey, c=US 238 239 More generally, the requirement for registration of organizations in 240 X.500 naming has led to the establishment of national registration 241 authorities whose function is mainly limited to assignment of X.500 242 organization names. Because of the very limited attraction of X.500, 243 interest in registering an organization with one of these national 244 authorities has been minimal. Finally, multi-national organizations 245 are frustrated by a lack of an international registration authority. 246 247 3.0 Requirements 248 249 A directory naming plan must provide a guide for the construction of 250 names (identifiers, labels) for directory objects that are 251 unambiguous (identify only one directory object) within some context 252 (namespace), at a minimum within one isolated directory server. 253 254 A directory object is simply a set of attribute values. The 255 association between a real-world object and a directory object is 256 made by directory-enabled applications and is, in the general case, 257 one to many. 258 259 The following additional naming characteristics are requirements that 260 this naming plan seeks to satisfy: 261 262 a) hierarchical 263 264 The Internet, consisting of a very large number of objects and 265 management domains, requires hierarchical names. Such names permit 266 delegation in the name assignment process and partitioning of 267 directory information among directory servers. 268 269 b) friendly to loose coupling of directory servers 270 271 One purpose of this naming plan is to define a naming pattern that 272 will facilitate one form or another of loose coupling of potentially 273 autonomous directory servers into a larger system. 274 275 A name in such a loosely-coupled system should unambiguously identify 276 one real-world object. The real-world object may, however, be 277 represented differently (i.e. by different directory objects having 278 different attributes but the same DN) in different (e.g. 279 independently managed) servers in the loosely-coupled system. The 280 plan does not attempt to produce names to overcome this likely 281 scenario. That is, it does not attempt to produce a single namespace 282 for all directory objects. (This issue is considered in more detail 283 284 285 286 Grimstad, et. al. Informational [Page 5] 287 289 RFC 2377 A Directory Naming Plan September 1998 290 291 292 in Section 5.1.) 293 294 c) readily usable by LDAP clients and servers 295 296 As of this writing, a substantial number of the Lightweight Directory 297 Access Protocol (LDAP) [6][7] implementations are currently available 298 or soon will be. The names specified by this naming plan should be 299 readily usable by these implementations and applications based on 300 them. 301 302 d) friendly to re-use of existing Internet name registries 303 304 As described in Section 2 above, creation of new global name 305 registries has been highly problematic. Therefore, a fundamental 306 requirement this plan addresses is to enable the reuse of existing 307 Internet name registries such as DNS names and RFC822 mailbox 308 identifiers when constructing directory names. 309 310 e) minimally user-friendly 311 312 Although we expect that user interfaces of directory-enabled 313 applications will avoid exposing users to DNs, it is unlikely that 314 users can be totally insulated from them. For this reason, the 315 naming plan should permit use of familiar information in name 316 construction. Minimally, a user should be capable of recognizing the 317 information encoded in his/her own DN. Names that are totally opaque 318 to users cannot meet this requirement. 319 320 4.0 Name Construction 321 322 The paper assumes familiarity with the terminology and concepts 323 behind the terms distinguished name (DN) and relative distinguished 324 name (RDN) [2][8][9]. 325 326 We describe how DNs can be constructed using three attribute types, 327 domainComponent (dc), userID (uid) and commonName (cn). They are 328 each described in turn. 329 330 4.1 Domain Component (dc) 331 332 The domain component attribute is defined and registered in RFC1274 333 [3][10]. It is used in the construction of a DN from a domain name. 334 Details of the construction algorithm is described in "Using Domains 335 in LDAP Distinguished Names" [1]. 336 337 An organization wishing to deploy a directory following this naming 338 plan would proceed as follows. Consider an organization, for example 339 "Acme, Inc.", having the registered domain name "acme.com". It would 340 341 342 343 Grimstad, et. al. Informational [Page 6] 344 346 RFC 2377 A Directory Naming Plan September 1998 347 348 349 construct the DN 350 351 dc=acme, dc=com 352 353 from its domain name. It would then use this DN as the root of its 354 subtree of directory information. 355 356 The DN itself can be used to identify a directory organization object 357 that represents information about the organization. The directory 358 schema required to enable this is described below in section 5.2. 359 360 The subordinates of the DN will be directory objects related to the 361 organization. The domain component attribute can be used to name 362 subdivisions of the organization such as organizational units and 363 localities. Acme, for example, might use the domain names 364 "corporate.acme.com" and "richmond.acme.com" to construct the names 365 366 dc=corporate, dc=acme, dc=com 367 dc=richmond, dc=acme, dc=com 368 369 under which to place its directory objects. The directory schema 370 required to name organizationalUnit and locality objects in this way 371 is described below in section 5.2. 372 373 Note that subdivisions of the organization such as organizational 374 units and localities could also be assigned RDNs using the 375 conventional X.500 naming attributes, e.g. 376 377 ou=corporate, dc=acme, dc=com 378 l=richmond, dc=acme, dc=com. 379 380 Use of the dc attribute for the RDN of directory objects of class 381 "domain" is also possible [1]. 382 383 4.2 User ID (uid) 384 385 The userid (uid) attribute is defined and registered in RFC1274 386 [3][10]. 387 388 This attribute may be used to construct the RDN for directory objects 389 subordinate to objects named according to the procedure described in 390 Section 4.1. This plan does not constrain how this attribute is 391 used. 392 393 4.3 Common Name (cn) 394 395 The commonName (cn) attribute is defined and registered in X.500 396 [3][11]. 397 398 399 400 Grimstad, et. al. Informational [Page 7] 401 403 RFC 2377 A Directory Naming Plan September 1998 404 405 406 This attribute may be used to construct the RDN for directory objects 407 subordinate to objects named according to the procedure described in 408 Section 4.1. This plan does not constrain how this attribute is 409 used. 410 411 4.4 Examples of uid and cn Usage 412 413 Although this plan places no constraints on the use of the uid and cn 414 attributes for name construction, we would like to offer some 415 suggestions by way of examples. 416 417 In practice, we have used uid for the RDN for person objects were we 418 could make use of an existing registry of names and cn for other 419 objects. 420 421 Examples of existing registries of identifiers for person objects are 422 RFC822 mailbox identifiers, employee numbers and employee "handles". 423 Aside from the convenience to administrators of re-use of an existing 424 store of identifiers, if it is ever necessary to display to a user 425 his/her DN, there is some hope that it will be recognizable when such 426 identifiers are used. 427 428 We have found RFC822 mailbox identifiers a particularly convenient 429 source for name construction. When a person has several e-mail 430 addresses, one will be selected for the purpose of user 431 identification. We call this the "distinguished" e-mail address or 432 the "distinguished" RFC822 mailbox identifier for the user. 433 434 For example, if there is a user affiliated with the organization Acme 435 having distinguished e-mail address J.Smith (a] acme.com, the uid 436 attribute will be: 437 438 uid=J.Smith (a] acme.com 439 440 The domain component attributes of a user's DN will normally be 441 constructed from the domain name of his/her distinguished e-mail 442 address. That is, for the user uid=J.Smith (a] acme.com the domain 443 component attributes would typically be: 444 445 dc=acme, dc=com 446 447 The full LDAP DN for this user would then be: 448 449 uid=J.Smith (a] acme.com, dc=acme, dc=com 450 451 Directory administrators having several RFC822 identifiers to choose 452 from when constructing a DN for a user should consider the following 453 factors: 454 455 456 457 Grimstad, et. al. Informational [Page 8] 458 460 RFC 2377 A Directory Naming Plan September 1998 461 462 463 o Machine-independent addresses are likely to be more stable, 464 resulting in directory names that change less. Thus an 465 identifier such as: 466 467 js (a] acme.com 468 469 may well be preferable to one such as: 470 471 js (a] blaster.third-floor.acme.com. 472 473 o Use of some form of "handle" for the "local" part that is 474 distinct from a user's real name may result in fewer collisions 475 and thereby lessen user pain and suffering. Thus the 476 identifier: 477 478 js (a] acme.com 479 480 may well be preferable to one such as: 481 482 J.Smith (a] acme.com 483 484 Practical experience with use of the RFC822 mailbox identifier scheme 485 described here has shown that there are situations where it is 486 convenient to use such identifies for all users in a particular 487 population, although a few users do not, in fact, possess working 488 mailboxes. For example, an organization may have a existing unique 489 identification scheme for all employees that is used as a alias to 490 the employees' real mailboxes -- which may be quite heterogeneous in 491 structure. The identification scheme works for all employees to 492 identify unambiguously each employee; it only works as an e-mail 493 alias for those employees having real mailboxes. For this reason it 494 would be a bad assumption for directory-enabled applications to 495 assume the uid to be a valid mailbox; the value(s) of the mail 496 attribute should always be checked. 497 498 It is important to emphasize that the elements of the domain name of 499 an RFC822 identifier may, BUT NEED NOT, be the same as the domain 500 components of the DN. This means that the domain components provide 501 a degree of freedom to support access control or other directory 502 structuring requirements that need not be mechanically reflected in 503 the user's e-mail address. We do not want under any condition to 504 force the user's e-mail address to change just to facilitate a new 505 system requirement such as a modification in an access control 506 structure. It should also be noted that while we do not require that 507 the domain components match the RFC822 identifier, we DO require that 508 the concatenated domain components form a registered domain name, 509 that is, one that is represented in the DNS. This automatically 510 avoids name conflicts in the directory hierarchy. 511 512 513 514 Grimstad, et. al. Informational [Page 9] 515 517 RFC 2377 A Directory Naming Plan September 1998 518 519 520 To provide an example of a DN which deviates from what might be 521 considered the default structure, consider the following scenario. 522 523 Suppose that J.Smith needs to be granted special permissions to 524 information in the dc=acme, dc=com part of the LDAP DIT. Since it 525 will be, in general, easier to organize special users by their name 526 structure than via groups (an arbitrary collection of DNs), we use 527 subdomains for this purpose. Suppose the special permissions were 528 required by users in the MIS organizational unit. A subdomain 529 "mis.acme.com" is established, if it does not already exist, 530 according to normal DNS procedures. The special permissions will be 531 granted to users with the name structure: 532 533 uid=*, dc=mis, dc=acme, dc=com 534 535 The DN of J.Smith in this case will be: 536 537 uid=J.Smith (a] acme.com, dc=mis, dc=acme, dc=com 538 539 In principal, there is nothing to prevent the domain name elements of 540 the RFC822 identifier from being completely different from the domain 541 components of the DN. For instance, the DN for a J.Smith could be: 542 543 uid=J.Smith (a] worldnet.att.net, dc=mis, dc=acme, dc=com 544 545 While we do not REQUIRE that the domain name part of the uid match 546 the dc components of the directory distinguished name, we suggest 547 that this be done where possible. At a minimum, if the most 548 significant pieces of the DN and the uid are the same (i.e., 549 "dc=acme, dc=com" and "acme.com") the likelihood, based on a 550 knowledge of a user's e-mail address, of discovering an appropriate 551 directory system to contact to find information about the user is 552 greatly enhanced. 553 554 The example above represents a situation where this suggestion isn't 555 possible because some of the users in a population have mailbox 556 identifiers that differ from the pattern of the rest of the users, 557 e.g., most mailboxes are of the form local (a] acme.com, but a 558 subpopulation have mailboxes from an ISP and therefore mailboxes of 559 the form local (a] worldnet.att.net. 560 561 5.0 Naming Plan and Directories 562 563 5.1 Directory Services Considerations 564 565 We envision the deployment of LDAP-based directory services on the 566 Internet to take the form of loosely coupled LDAP servers. This 567 coupling will occur at two levels. 568 569 570 571 Grimstad, et. al. Informational [Page 10] 572 574 RFC 2377 A Directory Naming Plan September 1998 575 576 577 Firstly, LDAP servers will be loosely connected into islands (i.e. a 578 set of servers sharing a single DN namespace). The glue connecting 579 the islands will be LDAP referral [12] information configured into 580 the LDAP servers. An LDAP search directed to any server in such an 581 island can be answered, if the information is not available to that 582 server, by an LDAP referral to another, more appropriate server 583 within the same island. 584 585 Secondly, various techniques will be used span LDAP islands. The 586 concept that enables such techniques is the LDAP URL [13]. By 587 combining a DNS host name and port (corresponding to one or more LDAP 588 servers) with a DN, the LDAP URL provides unified high-level 589 identification scheme (an LDAP URL namespace) for directory objects. 590 591 Because an LDAP referral is expressed as one or more LDAP URL, these 592 two levels of coupling may not sharply distinguished in practice. 593 594 We do not envision the X.500 model of a single DIT (i.e. a single DN 595 namespace) to be viable in an environment of competing service 596 providers. This naming plan does not attempt to produce DNs to hide 597 the possibility that a given real-world object may have independently 598 managed directory objects with the same DN associated with it. 599 600 5.2 Directory Schema Implications of the Naming Plan 601 602 The traditional directory schema(s) developed for the X.500 standard 603 and its application to the Internet [4] require extension to be used 604 with the naming plan developed here. The extensions described below 605 attempt to reuse existing schema elements as much as possible. The 606 directory objects for which extensions are required are: 607 organization, organizational unit, and various classes of leaf 608 objects. We describe the schema modifications below for organization, 609 organizationalUnit and selected leaf classes. 610 611 So as to continue to use existing structural object classes to the 612 extent possible, we propose supplementing entries based on these 613 classes with additional information from two new auxiliary object 614 classes, dcObject and uidObject. They are specified using the 615 notation in Section 4 of [14]. 616 617 The auxiliary object class dcObject is defined in "Using Domains in 618 LDAP Distinguished Names" [1]. 619 620 621 622 623 624 625 626 627 628 Grimstad, et. al. Informational [Page 11] 629 631 RFC 2377 A Directory Naming Plan September 1998 632 633 634 The auxiliary object class uidObject is defined as: 635 636 ( 1.3.6.1.1.3.1 637 NAME uidObject 638 SUP top 639 AUXILIARY 640 MUST uid ) 641 642 5.2.1 Organization Schema 643 644 The dc attribute is employed to construct the RDN of an organization 645 object. This is enabled by adding the auxiliary class dcObject to 646 the organization's objectClass attribute. 647 648 5.2.2 Organizational Unit Schema 649 650 The dc attribute is employed to construct the RDN of an 651 organizationalUnit object (which is subordinate in the DIT to either 652 an organization or an organizationalUnit object). This is enabled by 653 adding the auxiliary class dcObject to the organizational unit's 654 objectClass attribute. 655 656 5.2.3 Person Schema 657 658 No schema extensions are required for person objects if either the 659 inetOrgPerson [15] (preferred) or the newPilotPerson object classes 660 are used. The attribute uid is permissible in each class. For 661 consistency, the uidObject could be added to person entry objectClass 662 attributes to assist applications filtering on this object class 663 attribute value. Use of other classes for person objects with RDN 664 constructed with the uid attribute such as organizationalPerson 665 requires the use of the uidObject class. 666 667 It has been traditional in X.500 and LDAP directory services to 668 employ the common name (cn) attribute in naming. While this naming 669 plan doesn't require use of the cn attribute in naming, it should be 670 stressed that it is a required attribute in any class derived from 671 the person class and is still quite important. It will play a 672 significant role in enabling searches to find user entries of 673 interest. 674 675 5.2.4 Certification Authority Schema 676 677 The certification authority (CA) object class is an auxiliary class, 678 meaning it is essentially a set of additional attributes for a base 679 class such as organizationalRole, organization, organizationalUnit or 680 person. Except in the case where the base structural class is 681 inetOrgPerson, use of the uid attribute to construct the RDN of a CA 682 683 684 685 Grimstad, et. al. Informational [Page 12] 686 688 RFC 2377 A Directory Naming Plan September 1998 689 690 691 will require the auxiliary class uidObject to permit the uid 692 attribute to be used. In the cases where organizationalUnit or 693 organization is the base class for a CA, use of the auxiliary class 694 dcObject will permit the RDN of the CA to be a domain component. 695 696 5.2.5 Server and Server Application Schema 697 698 Servers and server applications are typically represented, for want 699 of anything better, by entries of the object class applicationProcess 700 (or a class derived from it). Sometimes the class applicationEntity 701 is used. In either case, the uid attribute should probably not be 702 employed to construct the RDN of a server or server application 703 object. The standard schema uses the attribute cn for such RDNs. 704 705 Suppose one wants to use this naming plan both in the construction of 706 DNs for SSL server certificates and for their storage in a directory. 707 It is customary for clients connecting via SSL to compare the 708 server's domain name (e.g. from the URL used to contact the server) 709 with the value of the cn attribute in the subject field (i.e. 710 subject's DN) of the server's certificate. For this reason, it is 711 common practice to set the cn attribute to the server's domain name. 712 713 The naming and schema to handle this situation is best explained by 714 an example. Consider the server "host.acme.com". Following the 715 algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN 716 dc=host, dc=acme, dc=com is constructed. To conform to the existing 717 practices just described, the server's subject DN for the SSL server 718 certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and 719 the server's certificate should be stored in a directory entry with 720 this name. This entry should use application process or application 721 entity as its structural object class and strong authentication user 722 as is auxiliary class. 723 724 5.2.6 Name Forms 725 726 For X.500 servers or LDAP servers following the X.500 model, our 727 schema requires the definition of new name forms, structure rules, 728 and DIT content rules. Structure rules and DIT content rules are 729 locally defined, and do not involve a globally significant object 730 identifier. 731 732 The following name forms are defined using the syntax of section 6.22 733 of [14] for the convenience of those using such servers. 734 735 Note that since the structural object classes organization, 736 organizationalUnit, locality and organizationalPerson do not permit 737 inclusion of the dc attribute, an auxiliary object class such as 738 dcObject [1] must be used for instances of these classes.) 739 740 741 742 Grimstad, et. al. Informational [Page 13] 743 745 RFC 2377 A Directory Naming Plan September 1998 746 747 748 5.2.6.1 Name Form for Domain Objects 749 750 The OIDs in this group are under the 751 iso.org.dod.internet.directory.NameForm branch of the OID tree 752 (1.3.6.1.1.2). 753 754 ( 1.3.6.1.1.2.1 755 NAME domainNameForm 756 OC domain 757 MUST dc ) 758 759 The domainNameForm name form indicates that objects of structural 760 object class domain have their RDN constructed from a value of the 761 attribute dc. 762 763 5.2.6.2 Name Form for Organization Objects 764 765 ( 1.3.6.1.1.2.2 766 NAME dcOrganizationNameForm 767 OC organization 768 MUST dc ) 769 770 The dcOrganizationNameForm name form indicates that objects of 771 structural object class organization have their RDN constructed from 772 a value of the attribute dc. 773 774 5.2.6.3 Name Form for Organizational Unit Objects 775 776 ( 1.3.6.1.1.2.3 777 NAME dcOrganizationalUnitNameForm 778 OC organizationalUnit 779 MUST dc ) 780 781 The dcOrganizationalUnitNameForm name form indicates that objects of 782 structural object class organizationalUnit have their RDN constructed 783 from a value of the attribute dc. 784 785 5.2.6.4 Name Form for Locality Objects 786 787 ( 1.3.6.1.1.2.4 788 NAME dcLocalityNameForm 789 OC locality 790 MUST dc ) 791 792 The dcLocalityNameForm name form indicates that objects of structural 793 object class locality have their RDN constructed from a value of the 794 attribute dc. 795 796 797 798 799 Grimstad, et. al. Informational [Page 14] 800 802 RFC 2377 A Directory Naming Plan September 1998 803 804 805 5.2.6.5 Name Form for Organizational Person Objects 806 807 ( 1.3.6.1.1.2.5 808 NAME uidOrganizationalPersonNameForm 809 OC organizationalPerson 810 MUST uid ) 811 812 The uidOrganizationalPersonNameForm name form indicates that objects 813 of structural object class organizationalPerson have their RDN 814 constructed from a value of the attribute uid. 815 816 6.0 Security Considerations 817 818 Although access controls may be placed on portions of the DIT to deny 819 browse access to unauthorized clients, it may be possible to infer 820 directory names and DIT structure in such sensitive portions of the 821 DIT from the results of DNS queries. Providing public visibility to 822 some portions of the DIT may assist those make such inferences. 823 824 7.0 Acknowledgments 825 826 This plan has emerged in the course of a number of fruitful 827 discussions, especially with David Chadwick, John Dale, Joe Gajewski, 828 Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu. 829 830 8.0 References 831 832 [1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. 833 Sataluri, "Using Domains in LDAP Distinguished Names", RFC 834 2247, January 1998. 835 836 [2] X.500: The Directory -- Overview of Concepts, Models, and 837 Service, CCITT Recommendation X.500, December, 1988. 838 839 [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 840 Schema", RFC 1274, November 1991. 841 842 [4] The North American Directory Forum, "A Naming Scheme for 843 c=US", RFC 1255, September 1991. 844 845 [5] The North American Directory Forum, "NADF Standing Documents: 846 A Brief Overview", RFC 1417, February 1993. 847 848 [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory 849 Access Protocol", RFC 1777, March 1995. 850 851 [7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 852 Access Protocol (v3)", RFC 2251, December 1997. 853 854 855 856 Grimstad, et. al. Informational [Page 15] 857 859 RFC 2377 A Directory Naming Plan September 1998 860 861 862 [8] Kille, S., "A String Representation of Distinguished Names", 863 RFC 1779, March 1995. 864 865 [9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory 866 Access Protocol (v3): UTF-8 String Representation of 867 Distinguished Names", RFC 2253, December 1997. 868 869 [10] Wahl, M., "A Summary of the Pilot X.500 Schema for use 870 in LDAPv3", Work in Progress. 871 872 [11] Wahl, M., "A Summary of the X.500 User Schema for use with 873 LDAPv3", RFC 2256, December 1997. 874 875 [12] Howes, T., and M. Wahl, "Referrals and Knowledge References 876 in LDAP Directories", Work in Progress. 877 878 [13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, 879 December 1997. 880 881 [14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, 882 "Lightweight Directory Access Protocol (v3): Attribute Syntax 883 Definitions", RFC 2252, December 1997. 884 885 [15] Smith, M., "Definition of the inetOrgPerson Object Class", 886 Work in Progress. 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 Grimstad, et. al. Informational [Page 16] 914 916 RFC 2377 A Directory Naming Plan September 1998 917 918 919 12. Authors' Addresses 920 921 Al Grimstad 922 AT&T 923 Room 1C-429, 101 Crawfords Corner Road 924 Holmdel, NJ 07733-3030 925 USA 926 927 EMail: alg (a] att.com 928 929 930 Rick Huber 931 AT&T 932 Room 1B-433, 101 Crawfords Corner Road 933 Holmdel, NJ 07733-3030 934 USA 935 936 EMail: rvh (a] att.com 937 938 939 Sri Sataluri 940 Lucent Technologies 941 Room 4D-335, 101 Crawfords Corner Road 942 Holmdel, NJ 07733-3030 943 USA 944 945 EMail: srs (a] lucent.com 946 947 948 Mark Wahl 949 Critical Angle Inc. 950 4815 W Braker Lane #502-385 951 Austin, TX 78759 952 USA 953 954 EMail: M.Wahl (a] critical-angle.com 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 Grimstad, et. al. Informational [Page 17] 971 973 RFC 2377 A Directory Naming Plan September 1998 974 975 976 13. Full Copyright Statement 977 978 Copyright (C) The Internet Society (1998). All Rights Reserved. 979 980 This document and translations of it may be copied and furnished to 981 others, and derivative works that comment on or otherwise explain it 982 or assist in its implementation may be prepared, copied, published 983 and distributed, in whole or in part, without restriction of any 984 kind, provided that the above copyright notice and this paragraph are 985 included on all such copies and derivative works. However, this 986 document itself may not be modified in any way, such as by removing 987 the copyright notice or references to the Internet Society or other 988 Internet organizations, except as needed for the purpose of 989 developing Internet standards in which case the procedures for 990 copyrights defined in the Internet Standards process must be 991 followed, or as required to translate it into languages other than 992 English. 993 994 The limited permissions granted above are perpetual and will not be 995 revoked by the Internet Society or its successors or assigns. 996 997 This document and the information contained herein is provided on an 998 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 999 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1000 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1001 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1002 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 Grimstad, et. al. Informational [Page 18] 1028 1030
Indexes created Tue Sep 15 00:24:42 UTC 2026