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