idnits 2.17.1 draft-ietf-ids-dirnaming-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 504: '...idObject' SUP top AUXILIARY MUST uid )...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 1997) is 9736 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1274 (ref. '3') (Obsoleted by RFC 4524) ** Obsolete normative reference: RFC 1255 (ref. '4') (Obsoleted by RFC 1417) ** Obsolete normative reference: RFC 1417 (ref. '5') (Obsoleted by RFC 1758) ** Obsolete normative reference: RFC 1777 (ref. '6') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1779 (ref. '8') (Obsoleted by RFC 2253, RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDS Working Group Al Grimstad 3 INTERNET-DRAFT Rick Huber 4 Sri Sataluri 5 AT&T 6 Steve Kille 7 Isode Ltd. 8 Mark Wahl 9 Critical Angle Inc. 11 August 28, 1997 13 Naming Plan for Internet Directory-Enabled Applications 14 Filename: draft-ietf-ids-dirnaming-02.txt 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this document is unlimited. Editorial comments 35 should be sent directly to the authors. Technical discussion will 36 take place on the IETF Integrated Directory Services mailing list, 37 ietf-ids@umich.edu. 39 Abstract 41 Application of the conventional X.500 approach to naming has 42 heretofore, in the experience of the authors, proven to be an 43 obstacle to the wide deployment of directory-enabled applications on 44 the Internet. We propose a new directory naming plan that leverages 45 the strengths of the most popular and successful Internet naming 46 schemes for naming objects in a hierarchical directory. This plan 47 can, we believe, facilitate the creation of an Internet White Pages 48 Service (IWPS) and other directory-enabled applications by overcoming 49 the problems encountered by those using the conventional X.500 50 approach to naming. 52 1.0 Executive Summary 54 Application of the conventional X.500 approach to naming has 55 heretofore, in the experience of the authors, proven to be an 56 obstacle to the wide deployment of directory-enabled applications on 57 the Internet. The required registration infrastructure is either 58 non-existent or largely ignored. The infrastructure that does exist 59 is cumbersome to use and tends to produce counterproductive results. 60 The attributes used for naming have been confusing for users and 61 inflexible to managers and operators of directory servers. 63 This paper describes an alternative directory naming plan for the 64 construction of an Internet directory infrastructure to support 65 directory-enabled applications. 67 The plan has the following two main features. First, it bases the 68 root and upper portions of the name hierarchy on the existing 69 infrastructure of names from the Domain Name System (DNS). This 70 component of the plan makes use of the ideas described in the 71 companion paper to this plan, "Using Domains in LDAP Distinguished 72 Names" [1]. And second, it provides a number of options for the 73 assignment of names to directory leaf objects such as person objects, 74 including an option that allows the reuse of existing Internet 75 identifiers for people. 77 Here, in summary, is our proposal. 79 The upper portions of the hierarchical directory tree should be 80 constructed using the components of registered DNS names using the 81 domain component attribute "dc". The directory name for the 82 organization having the domain name "acme.com" will then be, e.g., 84 dc=acme, dc=com 86 Organizations can add additional directory structure, for example to 87 support implementation of access control lists or partitioning of 88 their directory information, by using registered subdomains of DNS 89 names, e.g., the subdomain "corporate.acme.com" can be used as the 90 basis for the directory name 92 dc=corporate, dc=acme, dc=com 94 For naming directory leaf objects such as persons, groups, server 95 applications and certification authorities in a hierarchical 96 directory, we propose the use of either the "uid" (user identifier) 97 or the "cn" (common name) attribute for the relative distinguished 98 name. This plan does not constrain how these two attributes are used. 100 One approach to their use, for example, is to employ the uid 101 attribute as the RDN when reusing an existing store of identifiers 102 and the cn attribute as the RDN when creating new identifiers 103 specifically for the directory. A convenient existing identification 104 scheme for person objects is the RFC822 mailbox identifier. So an RDN 105 for person employing this store of identifiers would be, e.g., 107 uid=John.Smith@acme.com 109 For leaf objects not conveniently identified with such a scheme, the 110 "cn" attribute is used, e.g., 112 cn=Reading Room 114 Directory distinguished names will thus have the following structure, 115 e.g., 117 uid=John.Smith@acme.com, dc=acme, dc=com 118 uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com 119 uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com 120 cn=Reading Room, dc=physics, dc=national-lab, dc=edu 122 2.0 The Problem 124 The X.500 Directory model [2] can be used to create a world-wide 125 distributed directory. The Internet X.500 Directory Pilot has been 126 operational for several years and has grown to a size of about 1.5 127 million entries of varying quality. The rate of growth of the pilot 128 is far lower than the rate of growth of the Internet during the pilot 129 period. 131 There are a substantial number of contributing factors that have 132 inhibited the growth of this pilot. The common X.500 approach to 133 naming, while not the preponderant problem, has contributed in 134 several ways to limit the growth of an Internet White Pages Service 135 based on X.500. 137 The conventional way to construct names in the X.500 community is 138 documented as an informative (i.e., not officially standardized) 139 Annex B to X.521. The relative distinguished name (RDN) of a user 140 consists of a common name (cn) attribute. This is meant to be what -- 141 in the user's particular society -- is customarily understood to be 142 the name of that user. The distinguished name of a user is the 143 combination of the name of some general object, such as an 144 organization or a geographical unit, with the common name. There are 145 two main problems with this style of name construction. 147 First, the common name attribute, while seeming to be user-friendly, 148 cannot be used generally as an RDN in practice. In any significant 149 set of users to be named under the same Directory Information Tree 150 (DIT) node there will be collisions on common name. There is no way 151 to overcome this other than either by forcing uniqueness on common 152 names, something they do not possess, or by using an additional 153 attribute to prevent collisions. This additional attribute normally 154 needs to be unique in a much larger context to have any practical 155 value. The end result is a RDN that is very long and unpopular with 156 users. 158 Second, and more serious, X.500 has not been able to use any 159 significant number of pre-existing names. Since X.500 naming models 160 typically use organization names as part of the hierarchy [2, 3], 161 organization names must be registered. As organization names are 162 frequently tied to trademarks and are used in sales and promotions, 163 registration can be a difficult and acrimonious process. 165 The North American Directory Forum (NADF, now the North Atlantic 166 Directory Forum but still the NADF) proposed to avoid the problem of 167 registration by using names that were already registered in the 168 "civil naming infrastructure" [4][5]. Directory distinguished names 169 would be based on an organization's legal name as recognized by some 170 governmental agency (county clerk, state secretary of state, etc.) or 171 other registering entity such as ANSI. 173 This scheme has the significant advantage of keeping directory 174 service providers out of disputes about the right to use a particular 175 name, but it leads to rather obscure names. Among these obscurities, 176 the legal name almost invariably takes a form that is less familiar 177 and longer than what users typically associate with the organization. 178 For example, in the US a large proportion of legal organization names 179 end with the text ", Inc." as in "Acme, Inc." Moreover, in the case 180 of the US, the civil naming infrastructure does not operate 181 nationally, so the organization names it provides must be located 182 under state and regional DIT nodes, making them difficult to find 183 while browsing the directory. NADF proposes a way to algorithmically 184 derive multi-attribute RDNs which would allow placement of entries or 185 aliases in more convenient places in the DIT, but these derived names 186 are cumbersome and unpopular. For example, suppose Nadir is an 187 organization that is registered in New Jersey civil naming 188 infrastructure under the name "Nadir Networks, Inc." Its civil 189 distinguished name (DN) would then be 191 o="Nadir Networks, Inc.", st=New Jersey, c=US 192 while its derived name which is unambiguous under c=US directly is 194 o="Nadir Networks, Inc." + st=New Jersey, c=US 196 More generally, the requirement for registration of organizations in 197 X.500 naming has led to the establishment of national registration 198 authorities whose function is mainly limited to assignment of X.500 199 organization names. Because of the very limited attraction of X.500, 200 interest in registering an organization with one of these national 201 authorities has been minimal. Finally, multi-national organizations 202 are frustrated by a lack of an international registration authority. 204 3.0 Requirements 206 A directory naming plan must provide for names of directory objects 207 that are unambiguous (identify only one object) within some context, 208 at a minimum within one isolated directory server. 210 The following additional naming characteristics are requirements that 211 this naming plan seeks to satisfy: 213 a) hierarchical 215 The Internet, consisting of a very large number of objects and 216 management domains, requires hierarchical names. Such names permit 217 delegation in the name assignment process and partitioning of 218 directory information among directory servers. 220 b) friendly to loose coupling of directory servers 222 One purpose of this naming plan is to define a naming pattern that 223 will facilitate one form or another of loose coupling of potentially 224 autonomous directory servers into a larger system. A name in such a 225 system should unambiguously identify one real-world object. The 226 object may, however, be represented differently (i.e. have different 227 attributes) in different (e.g. independently managed) servers in the 228 system. The plan does not attempt to produce names to overcome this 229 likely scenario. 231 c) readily usable by LDAP clients and servers 233 As of this writing, a substantial number of the Lightweight Directory 234 Access Protocol (LDAP) [6][7] implementations are currently available 235 or soon will be. The names specified by this naming plan should be 236 readily usable by these implementations and applications based on 237 them. 239 d) friendly to re-use of existing Internet name registries 240 As described in Section 2 above, creation of new global name 241 registries has been highly problematic. Therefore, a fundamental 242 requirement this plan addresses is to enable the reuse of existing 243 Internet name registries such as DNS names and RFC822 mailbox 244 identifiers when constructing directory names. 246 e) minimally user-friendly 248 Although we expect that user interfaces of directory-enabled 249 applications will avoid exposing users to DNs, it is unlikely that 250 users can be totally insulated from them. For this reason, the 251 naming plan should permit use of familiar information in name 252 construction. Minimally, a user should be capable of recognizing the 253 information encoded in his/her own DN. Names that are totally opaque 254 to users cannot meet this requirement. 256 4.0 Name Construction 258 The paper assumes familiarity with the terminology and concepts 259 behind the terms distinguished name (DN) and relative distinguished 260 name (RDN) [2][8][9]. 262 We describe how DNs can be constructed using three attribute types, 263 domainComponent (dc), userID (uid) and commonName (cn). They are 264 each described in turn. 266 4.1 Domain Component (dc) 268 The domain component attribute is defined and registered in RFC1274 269 [3][10]. It is used in the construction of a DN from a domain name. 270 Details of the construction algorithm is described in "Using Domains 271 in LDAP Distinguished Names" [1]. 273 An organization wishing to deploy a directory following this naming 274 plan would proceed as follows. Consider an organization, for example 275 "Acme, Inc.", having the registered domain name "acme.com". It would 276 construct the DN 278 dc=acme, dc=com 280 from its domain name. It would then use this DN as the root of its 281 subtree of directory information. 283 The DN itself can be used to identify a directory organization object 284 that represents information about the organization. The directory 285 schema required to enable this is described below in section 5.2. 287 The subordinates of the DN will be directory objects related to the 288 organization. The domain component attribute can be used to name 289 subdivisions of the organization such as organizational units and 290 localities. Acme, for example, might use the domain names 291 "corporate.acme.com" and "engineering.acme.com" to construct the 292 names 294 dc=corporate, dc=acme, dc=com 295 dc=engineering, dc=acme, dc=com 297 under which to place its directory objects. The directory schema 298 required to name organizationalUnit and locality objects in this way 299 is described below in section 5.2. 301 Use of this attribute for the RDN of directory objects of class 302 "domain" is also possible [1]. 304 4.2 User ID (uid) 306 The userid (uid) attribute is defined and registered in RFC1274 307 [3][10]. 309 This attribute may be used to construct the RDN for directory objects 310 subordinate to objects named according to the procedure described in 311 Section 4.1. This plan does not constrain how this attribute is 312 used. 314 4.3 Common Name (cn) 316 The commonName (cn) attribute is defined and registered in X.500 317 [3][11]. 319 This attribute may be used to construct the RDN for directory objects 320 subordinate to objects named according to the procedure described in 321 Section 4.1. This plan does not constrain how this attribute is 322 used. 324 4.4 Examples of uid and cn Usage 326 Although this plan places no constraints on the use of the uid and cn 327 attributes for name construction, we would like to offer some 328 suggestions by way of examples. 330 In practice, we have used uid for the RDN for person objects were we 331 could make use of an existing registry of names and cn for other 332 objects. 334 Examples of existing registries of identifiers for person objects are 335 RFC822 mailbox identifiers, employee numbers and employee "handles". 337 Aside from the convenience to administrators of re-use of an existing 338 store of identifiers, if it is ever necessary to display to a user 339 his/her DN, there is some hope that it will be recognizable when such 340 identifiers are used. 342 We have found RFC822 mailbox identifiers a particularly convenient 343 source for name construction. When a person has several e-mail 344 addresses, one will be selected for the purpose of user 345 identification. We call this the "distinguished" e-mail address or 346 the "distinguished" RFC822 mailbox identifier for the user. 348 For example, if there is a user affiliated with the organization Acme 349 having distinguished e-mail address J.Smith@acme.com, the uid 350 attribute will be: 352 uid=J.Smith@acme.com 354 The domain component attributes of a user's DN will normally be 355 constructed from the domain name of his/her distinguished e-mail 356 address. That is, for the user uid=J.Smith@acme.com the domain 357 component attributes would typically be: 359 dc=acme, dc=com 361 The full LDAP DN for this user would then be: 363 uid=J.Smith@acme.com, dc=acme, dc=com 365 Directory administrators having several RFC822 identifiers to choose 366 from when constructing a DN for a user should consider the following 367 factors: 369 o Machine-independent addresses are likely to be more stable, 370 resulting in directory names that change less. Thus an 371 identifier 372 such as: 374 js@acme.com 376 may well be preferable to one such as: 378 js@blaster.third-floor.acme.com. 380 o Use of some form of "handle" for the "local" part that is 381 distinct from a user's real name may result in fewer collisions 382 and thereby lessen user pain and suffering. Thus the 383 identifier: 385 js@acme.com 387 may well be preferable to one such as: 389 J.Smith@acme.com 391 Practical experience with use of the RFC822 mailbox identifier scheme 392 described here has shown that there are situations where it is 393 convenient to use such identifies for all users in a particular 394 population, although a few users do not, in fact, possess working 395 mailboxes. For example, an organization may have a existing unique 396 identification scheme for all employees that is used as a alias to 397 the employees' real mailboxes -- which may be quite heterogeneous in 398 structure. The identification scheme works for all employees to 399 identify unambiguously each employee; it only works as an e-mail 400 alias for those employees having real mailboxes. For this reason it 401 would be a bad assumption for directory-enabled applications to 402 assume the uid to be a valid mailbox; the value(s) of the mail 403 attribute should always be checked. 405 It is important to emphasize that the elements of the domain name of 406 an RFC822 identifier may, BUT NEED NOT, be the same as the domain 407 components of the DN. This means that the domain components provide 408 a degree of freedom to support access control or other directory 409 structuring requirements that need not be mechanically reflected in 410 the user's e-mail address. We do not want under any condition to 411 force the user's e-mail address to change just to facilitate a new 412 system requirement such as a modification in an access control 413 structure. It should also be noted that while we do not require that 414 the domain components match the RFC822 identifier, we DO require that 415 the concatenated domain components form a registered domain name, 416 that is, one that is represented in the DNS. This automatically 417 avoids name conflicts in the directory hierarchy. 419 To provide an example of a DN which deviates from what might be 420 considered the default structure, consider the following scenario. 422 Suppose that J.Smith needs to be granted special permissions to 423 information in the dc=acme, dc=com part of the LDAP DIT. Since it 424 will be, in general, easier to organize special users by their name 425 structure than via groups (an arbitrary collection of DNs), we use 426 subdomains for this purpose. Suppose the special permissions were 427 required by users in the MIS organizational unit. A subdomain 428 "mis.acme.com" is established, if it does not already exist, 429 according to normal DNS procedures. The special permissions will be 430 granted to users with the name structure: 432 uid=*, dc=mis, dc=acme, dc=com 433 The DN of J.Smith in this case will be: 435 uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com 437 In principal, there is nothing to prevent the domain name elements of 438 the RFC822 identifier from being completely different from the domain 439 components of the DN. For instance, the DN for a J.Smith could be: 441 uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com 443 While we do not REQUIRE that the domain name part of the uid match 444 the dc components of the directory distinguished name, we suggest 445 that this be done where possible. At a minimum, if the most 446 significant pieces of the DN and the uid are the same (i.e., 447 "dc=acme, dc=com" and "acme.com") the likelihood, based on a 448 knowledge of a user's e-mail address, of discovering an appropriate 449 directory system to contact to find information about the user is 450 greatly enhanced. 452 The example above represents a situation where this suggestion isn't 453 possible because some of the users in a population have mailbox 454 identifiers that differ from the pattern of the rest of the users, 455 e.g., most mailboxes are of the form local@acme.com, but a 456 subpopulation have mailboxes from an ISP and therefore mailboxes of 457 the form local@worldnet.att.net. 459 5.0 Implementation Issues 461 5.1 Directory Services Considerations 463 We envision the deployment of LDAP-based directory services on the 464 Internet to take the form of LDAP servers loosely connected into 465 islands by means of LDAP referral [12] information configured into 466 the servers. By generalizing this concept one can imagine building a 467 simple referral server that knows about the LDAP islands of the 468 Internet. It would compare the naming or search information in a 469 query it receives with its knowledge of LDAP islands and return a 470 referral to the appropriate island. 472 We do not envision the X.500 model of a single DIT to viable in an 473 environment of competing service providers. This naming plan does 474 not attempt to produce names to hide the possibility that a given DN 475 may have independently managed entries associated with it. Referral 476 servers such as those envisioned in the previous paragraph can help 477 to deal with this situation: a) first, because referrals are 478 expressed as LDAP URLs [13] which can identify both a host server and 479 a DN; and b) second, because referrals can be multi-valued. Future 480 LDAP v3 clients can be expected to support such referrals. 482 5.2 Directory Schema Implications of the Naming Plan 484 The traditional directory schema(s) developed for the X.500 standard 485 and its application to the Internet [4] require extension to be used 486 with the naming plan developed here. The extensions described below 487 attempt to reuse existing schema elements as much as possible. The 488 directory objects for which extensions are required are: 489 organization, organizational unit, and various classes of leaf 490 objects. We describe the schema modifications below for organization, 491 organizationalUnit and selected leaf classes. 493 So as to continue to use existing structural object classes to the 494 extent possible, we propose supplementing entries based on these 495 classes with additional information from two new auxiliary object 496 classes, dcObject and uidObject. They are specified using the 497 notation in Section 4 of [14]. 499 The auxiliary object class dcObject is defined in "Using Domains in 500 LDAP Distinguished Names" [1]. 502 The auxiliary object class uidObject is defined as: 504 ( OID-TBD NAME 'uidObject' SUP top AUXILIARY MUST uid ) 506 In a pure X.500 context, our schema would also require the definition 507 of new name forms and structure rules. These concepts are not 508 required, however, for the specification of LDAP schemas. 510 5.2.1 Organization Schema 512 The dc attribute is employed to construct the RDN of an organization 513 object. This is enabled by adding the auxiliary class dcObject to 514 the organization's objectClass attribute. 516 5.2.2 Organizational Unit Schema 518 The dc attribute is employed to construct the RDN of an 519 organizationalUnit object (which is subordinate in the DIT to either 520 an organization or an organizationalUnit object). This is enabled by 521 adding the auxiliary class dcObject to the organizational unit's 522 objectClass attribute. 524 5.2.3 Person Schema 526 No schema extensions are required for person objects if either the 527 inetOrgPerson [15] (preferred) or the newPilotPerson object classes 528 are used. The attribute uid is permissible in each class. For 529 consistency, the uidObject could be added to person entry objectClass 530 attributes to assist applications filtering on this attribute. Use of 531 other classes for person objects with RDN constructed with the uid 532 attribute such as organizationalPerson requires the use of the 533 uidObject class. 535 It has been traditional in X.500 and LDAP directory services to 536 employ the common name (cn) attribute in naming. While this naming 537 plan doesn't require use of the cn attribute in naming, it should be 538 stressed that it is a required attribute in any class derived from 539 the person class and is still quite important. It will play a 540 significant role in enabling searches to find user entries of 541 interest. 543 5.2.4 Certification Authority Schema 545 The certification authority (CA) object class is an auxiliary class, 546 meaning it is essentially a set of additional attributes for a base 547 class such as organizationalRole, organization, organizationalUnit or 548 person. Except in the case where the base structural class is 549 inetOrgPerson, use of the uid attribute to construct the RDN of a CA 550 will require the auxiliary class uidObject to permit the uid 551 attribute to be used. In the cases where organizationalUnit or 552 organization is the base class for a CA, use of the auxiliary class 553 dcObject will permit the RDN of the CA to be a domain component. 555 5.2.5 Server and Server Application Schema 557 Servers and server applications are typically represented, for want 558 of anything better, by entries of the object class applicationProcess 559 (or a class derived from it). Sometimes the class applicationEntity 560 is used. In either case, the uid attribute should probably not be 561 employed to construct the RDN of a server or server application 562 object. The standard schema uses the attribute cn for such RDNs. 564 Suppose one wants to use this naming plan both in the construction of 565 DNs for SSL server certificates and for their storage in a directory. 566 It is customary for clients connecting via SSL to compare the 567 server's domain name (e.g. from the URL used to contact the server) 568 with the value of the cn attribute in the subject field (i.e. 569 subject's DN) of the server's certificate. For this reason, it is 570 common practice to set the cn attribute to the server's domain name. 572 The naming and schema to handle this situation is best explained by 573 an example. Consider the server "host.acme.com". Following the 574 algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN 575 dc=host, dc=acme, dc=com is constructed. To conform to the existing 576 practices just described, the server's subject DN for the SSL server 577 certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and 578 the server's certificate should be stored in a directory entry with 579 this name. This entry should use application process or application 580 entity as its structural object class and strong authentication user 581 as is auxiliary class. 583 6.0 Security Considerations 585 Although access controls may be placed on portions of the DIT to deny 586 browse access to unauthorized clients, it may be possible to infer 587 directory names and DIT structure in such sensitive portions of the 588 DIT from the results of DNS queries. Providing public visibility to 589 some portions of the DIT may assist those make such inferences. 591 7.0 Acknowledgments 593 This plan has emerged in the course of a number of fruitful 594 discussions, especially with David Chadwick, John Dale, Joe Gajewski, 595 Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu. 597 8.0 References 599 [1] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 600 "Using Domains in LDAP Distinguished Names", Internet 601 Draft , August 602 1997. 604 [2] X.500: The Directory -- Overview of Concepts, Models, and 605 Service, CCITT Recommendation X.500, December, 1988. 607 [3] P. Barker, and S. Kille, "The COSINE and Internet X.500 608 Schema", RFC1274, 11/27/1991. 610 [4] The North American Directory Forum, "A Naming Scheme for 611 c=US", RFC1255, September 1991. 613 [5] The North American Directory Forum, "NADF Standing Documents: 614 A Brief Overview", RFC 1417, The North American Directory 615 Forum", NADF, February 1993. 617 [6] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory 618 Access Protocol", RFC1777, 03/28/1995. 620 [7] M. Wahl, T. Howes, and S. Kille, "Lightweight Directory 621 Access Protocol (v3)", Internet Draft , March 1997. 624 [8] S. Kille, "A String Representation of Distinguished Names", 625 RFC1779, 03/28/1995. 627 [9] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 628 Protocol (v3): UTF-8 String Representation of Distinguished 629 Names", Internet Draft , 630 April, 1997. 632 [10] M. Wahl, "A Summary of the Pilot X.500 Schema for use in 633 LDAPv3", Internet Draft , March 1997. 636 [11] M. Wahl, "A Summary of the X.500 User Schema for use with 637 LDAPv3", Internet Draft , July 1997. 640 [12] T. Howes, M. Wahl, "Referrals and Knowledge References in 641 LDAP Directories", Internet Draft, , May 1997. 644 [13] T. Howes, M. Smith, "The LDAP URL Format", Internet Draft, 645 , August 1997. 647 [14] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 648 Directory Access Protocol (v3): Attribute Syntax 649 Definitions", Internet Draft , August 1997. 652 [15] M. Smith, "Definition of the inetOrgPerson Object Class", 653 Internet Draft , 654 July 1997. 656 12. Authors' Addresses 658 Al Grimstad 659 AT&T 660 Room 1C-429, 101 Crawfords Corner Road 661 Holmdel, NJ 07733-3030 662 USA 664 EMail: alg@att.com 666 Rick Huber 667 AT&T 668 Room 1B-433, 101 Crawfords Corner Road 669 Holmdel, NJ 07733-3030 670 USA 671 EMail: rvh@att.com 673 Sri Sataluri 674 AT&T 675 Room 4G-202, 101 Crawfords Corner Road 676 Holmdel, NJ 07733-3030 677 USA 679 EMail: sri@att.com 681 Steve Kille 682 Isode Limited 683 The Dome, The Square 684 Richmond 685 TW9 1DT 686 UK 688 Phone: +44-181-332-9091 689 EMail: S.Kille@isode.com 691 Mark Wahl 692 Critical Angle Inc. 693 4815 W Braker Lane #502-385 694 Austin, TX 78759 695 USA 697 EMail: M.Wahl@critical-angle.com