idnits 2.17.1 draft-ietf-ids-dirnaming-00.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-26) 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 1 longer page, the longest (page 1) being 748 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 12 instances of lines with control characters in the document. 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 (November 1996) is 10024 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' ** Obsolete normative reference: RFC 1274 (ref. '2') (Obsoleted by RFC 4524) ** Obsolete normative reference: RFC 1255 (ref. '3') (Obsoleted by RFC 1417) ** Obsolete normative reference: RFC 1777 (ref. '4') (Obsoleted by RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 1588 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1107 (ref. '6') ** Obsolete normative reference: RFC 1779 (ref. '7') (Obsoleted by RFC 2253, RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 822 (ref. '9') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Experimental RFC: RFC 1279 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1417 (ref. '12') (Obsoleted by RFC 1758) Summary: 18 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDS Working Group Al Grimstad 2 INTERNET-DRAFT Rick Huber 3 Sri Sataluri 4 AT&T 5 November 1996 7 NAMING PLAN FOR AN INTERNET DIRECTORY SERVICE 8 Filename: draft-ietf-ids-dirnaming-00.txt 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. Editorial comments should 29 be sent directly to the authors. Technical discussion will take place 30 on the IETF Integrated Directory Services mailing list, 31 ietf-ids@umich.edu. 33 This Internet Draft expires April 15, 1997. 35 Abstract 37 Application of the conventional X.500 approach to naming has, in the 38 experience of the authors, proven to be an obstacle to the creation of 39 directory services. We propose a new directory naming plan that 40 leverages the strengths of the most popular and successful Internet 41 naming schemes for naming objects in a hierarchical directory. This 42 plan can, we believe, facilitate the creation of an Internet White 43 Pages Service (IWPS) by overcoming the problems encountered by those 44 using the conventional recommended X.500 approach to naming. 46 1.0 EXECUTIVE SUMMARY 48 The conventional approach to naming taken by the X.500 community has, 49 in the experience of the authors, shown itself to be an obstacle to the 50 creation of directory services. The required registration 51 infrastructure is either non-existent or largely ignored. The 52 infrastructure that does exist is cumbersome to use and tends to 53 produce counterproductive results. The attributes used for naming have 54 been confusing for users and inflexible to managers and operators of 55 directory services. 57 We propose an alternative approach -- which can co-exist with current 58 X.500 naming practices -- for the construction of the Internet White 59 Pages Service (IWPS). The existing infrastructure of names in the 60 Internet, that is, names from the Domain Name System (DNS) and mailbox 61 identifiers structured according to RFC822, can adequately supply the 62 need for names in the construction of an IWPS. Further, with the 63 proper construction of the IWPS, RFC822 identifiers can play a role 64 that is entirely analogous to the role distinguished names play in 65 X.500. 67 Here, in summary, is our proposal. 69 For naming entries of users, server applications and certification 70 authorities in a hierarchical directory (e.g., one accessed via LDAP), 71 we propose the use of the user identifier attribute "uid" for the 72 relative distinguished name. The value of this attribute should be an 73 RFC822 address, e.g., 75 uid=John.Smith@acme.com 77 The upper portions of the hierarchical directory tree should be 78 constructed using the components of registered DNS names using the 79 domain component attribute "dc". The directory name for the 80 organization having the domain name acme.com will then be, e.g., 82 dc=acme, dc=com 84 Organizations can add additional directory structure, for example to 85 support implementation of access control lists or partitioning of their 86 directory information, by using registered subdomains of DNS names, 87 e.g., 89 dc=corporate, dc=acme, dc=com 91 Directory distinguished names will thus have the following structure, 92 e.g., 94 uid=John.Smith@acme.com, dc=acme, dc=com 95 uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com 96 uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com 98 Searching the directory based on exact matching of the uid attribute 99 should be optimized in the directory service such that it is 100 essentially equivalent to searching using a directory distinguished 101 name. 103 External mechanisms can be used to locate the proper directory server 104 to query to obtain directory information. 106 2.0 THE PROBLEM 108 The X.500 Directory model [1] can be used to create a world-wide 109 distributed directory. The Internet X.500 Directory Pilot has been 110 operational for several years and has grown to a size of about 1.5 111 million entries of varying quality. The rate of growth of the pilot is 112 far lower than the rate of growth of the Internet during the pilot 113 period. 115 There are a substantial number of contributing factors that have 116 inhibited the growth of this pilot. The common X.500 approach to 117 naming, while not the preponderant problem, has contributed in several 118 ways to limit the growth of an Internet White Pages Service based on 119 X.500. 121 2.1 Naming Problems 123 The conventional way to construct names in the X.500 community is 124 documented as an informative (i.e., not officially standardized) Annex 125 B to X.521. The relative distinguished name (RDN) of a user consists of 126 a common name (cn) attribute. This is meant to be what, in the user's 127 particular society, is customarily understood to be the name of that 128 user. The distinguished name of a user is the combination of the name 129 of some general object, such as an organization or a geographical unit, 130 with the common name. There are two main defects to this style of name 131 construction. 133 First, the common name attribute, while seeming to be user-friendly, 134 cannot be used generally as an RDN in practice. In any significant set 135 of users to be named under the same Directory Information Tree (DIT) 136 node there will be collisions on common name. There is no way to 137 overcome this other than either forcing uniqueness on common names, 138 something they do not possess, or using an additional attribute to 139 prevent collisions. This additional attribute normally needs to be 140 unique in a much larger context to have any practical value. The end 141 result is a RDN that is very long and unpopular with users. 143 Second, and more serious, X.500 has not been able to use any 144 significant number of pre-existing names. Since X.500 naming models 145 typically use organization names as part of the hierarchy [2, 3], 146 organization names must be registered. As organization names are 147 frequently tied to trademarks and are used in sales and promotions, 148 registration can be a difficult and acrimonious process. 150 The North American Directory Forum (NADF, now the North Atlantic 151 Directory Forum but still the NADF) proposed to avoid the problem of 152 registration by using names that were already registered in the "civil 153 naming infrastructure" [3]. Directory distinguished names would be 154 based on an organization's legal name as recognized by some 155 governmental agency (county clerk, state secretary of state, etc.) or 156 other registering entity such as ANSI. 158 This scheme has the significant advantage of keeping directory service 159 providers out of disputes about the right to use a particular name, but 160 it leads to rather obscure names. Among these obscurities, the legal 161 name almost invariably takes a form that is less familiar and longer 162 than what users typically associate with the organization. For 163 example, in the US a large proportion of legal organization names end 164 with the text ", Inc." as in "Acme, Inc." Moreover, in the case of the 165 US, the civil naming infrastructure does not operate nationally, so the 166 organization names it provides must be located under state and regional 167 DIT nodes, making them difficult to find while browsing the directory. 168 NADF proposes a way to algorithmically derive multi-attribute RDNs 169 which would allow placement of entries or aliases in more convenient 170 places in the DIT, but these derived names are cumbersome and 171 unpopular. For example, suppose Nadir is an organization that is 172 civilly registered in New Jersey under the name "Nadir Networks, Inc." 173 Its civil distinguished name (DN) would then be 175 o="Nadir Networks, Inc.", st=New Jersey, c=US 177 while its derived name which is unambiguous under c=US directly is 179 o="Nadir Networks, Inc." + st=New Jersey, c=US 181 More generally, the requirement for registration of organizations in 182 X.500 naming has led to the establishment of national registration 183 authorities whose function is mainly limited to assignment of X.500 184 organization names. Because of the very limited attraction of X.500, 185 interest in registering an organization with one of these national 186 authorities has been minimal. Finally, multi-national organizations are 187 frustrated by a lack of an international registration authority. 189 2.2 Directory Models 191 The Internet community proposed the Light-weight Directory Access 192 Protocol [4], initially, as an access method for X.500 directories. 193 However, more recently, many different directories are starting to use 194 LDAP as an access protocol. Many software companies have endorsed the 195 LDAP protocol and are starting to sell stand-alone hierarchical 196 directories that use LDAP as the access protocol. 198 The meeting documented in RFC1588, held in conjunction with the Houston 199 IETF in November 1993, has the following as one of its conclusions 200 [5]: 202 It is evident that there are and will be several [directory] 203 technologies in use. In order to provide a white pages directory 204 service that accommodates multiple technologies, we should 205 promote interoperation and work toward a specification of the 206 simplest common communication form that is powerful enough to 207 provide the necessary functionality. This "common ground" 208 approach aims to provide the ubiquitous WPS (White Pages Service) 209 with a high functionality and a low entry cost. 211 In other words, at that time (November 1993) people already felt that 212 X.500 was not the one and only answer; we needed to try out other tools 213 and look for ways to tie all the resulting directories together. The 214 Internet community gave X.500 a fair chance [6] but it did not succeed 215 on a large enough scale to become the overall Internet White Pages 216 Service (IWPS). 218 The X.500 Directory, via its knowledge model, attempts to build a 219 world-wide directory in a top-down fashion. This approach has only met 220 with partial success. The advent of the LDAP protocol and its 221 popularity and the possible ubiquitous availability of stand-alone LDAP 222 directory server technology will, in our opinion, stimulate the 223 creation of directories in a bottom-up fashion. These directory 224 servers or directory islands will be loosely tied together via LDAP 225 referrals and other external mechanisms. 227 2.3 Addressing the Problems 229 This paper describes a directory naming plan that is a radical 230 departure from the traditional X.500 naming scheme -- the X.500 scheme 231 has not been generally accepted by the Internet community and has been 232 found to be very clumsy in implementing and administering directory 233 services by the authors. 235 This naming plan is straightforward to implement by both classic X.500 236 systems and islands of stand-alone LDAP servers. Its unique strength 237 lies in its use of the existing Internet naming schemes -- RFC822 238 addresses and the Domain Name System. Further, by use of an attribute, 239 the user ID attribute, and a tree structure based on the DNS, the plan, 240 if broadly implemented, may well simplify the construction of external 241 mechanisms to locate appropriate LDAP servers. 243 The naming plan focus is on naming Internet user and server 244 applications. It is not applicable to objects such as the X.500 245 residential person which typically lack e-mail mailboxes (we believe 246 that such entries are useless in this day and age). Because it is a 247 hierarchical plan using typed attribute values (tags), the naming plan 248 can co-exist with other hierarchical plans using other typed attributes 249 such as a plan for residential persons and the conventional X.521 Annex 250 B plan. 252 3.0 TECHNOLOGICAL ASSUMPTIONS 254 We assume that our fundamental protocol interface to systems offering 255 general directory services will be the TCP/IP-based Lightweight 256 Directory Access Protocol (LDAP) [4]. Objects are named in this 257 protocol in a hierarchical fashion and represented as described in RFC 258 1779 [7]. We also assume that user authentication and other security 259 services based on it will increasingly depend on the use of the Secure 260 Sockets Layer (SSL) or variant protocol and the structure of user and 261 server certificates (certified public cryptographic keys) as described 262 in an Internet Draft [8]. 264 4.0 RFC822 IDENTIFICATION 266 The one universally accepted scheme of user identification (actually 267 user maildrop identification) in the Internet today is the RFC822 [9] 268 syntax for e-mail addresses. The syntax of an RFC822 identifier is: 270 local@domain 272 where 274 "domain" is a hierarchically structured identifier as defined 275 by the Domain Name System (DNS), and 277 "local" is an identifier for a user (literally a maildrop) 278 that is valid within the domain "domain". 280 Examples of such identifiers are J.Smith@acme.com and 281 S.Johnson@corporate.acme.com. 283 Each user for whom information is maintained in a directory service 284 will have at least one e-mail address structured according to RFC822. 285 While the user may well have many such addresses, one will be selected 286 for the purpose of user identification. We call this the 287 "distinguished" e-mail address or the "distinguished" RFC822 identifier 288 for the user. 290 5.0 DIRECTORY DISTINGUISHED NAMES 292 5.1 Overview of Distinguished Names 294 The general structure of a name in LDAP, termed a distinguished name 295 (DN), is: 297 attribute, attribute, ... attribute 299 An "attribute" is a pairing of a type identifier and a value separated 300 by "=". For example, cn=Samuel Johnson is an attribute with type 301 identifier "cn", short for common name, and value "Samuel Johnson". 303 The order of the attributes in a DN is significant. Like DNS 304 identifiers, DNs are hierarchical and "little endian", that is, the 305 most global piece comes last. An example of a DN is: 307 cn=Samuel Johnson, o=Famous Lexicographers, c=GB 309 where: 311 cn=Samuel Johnson means the attribute type "cn" has the value 312 "Samuel Johnson", 314 o=Famous Lexicographers means that the attribute type "o", short 315 for organization name, has the value "Famous Lexicographers", and 317 c=GB means that the attribute type "c", short for country name, has 318 the value "GB", the international abbreviation for the country 319 Great Britain. 321 The set of all DNs forms a tree structure that is called the Directory 322 Information Tree (DIT). 324 5.2 Directory Distinguished Names 326 Suppose an organization, e.g., Acme, wants to bring up a Directory 327 Service. It either has a registered DNS name or it should get one. 329 Given a DNS name, we will use a form of DN construction largely based 330 on RFC1279 [10]. This RFC shows how to map an RFC822 e-mail address to 331 a DN. We differ from it in two respects: (1) we use a mapping that 332 starts at the root of the DIT; and (2) we use the attribute type user 333 ID (userid or uid) for the first attribute of the DN. The value of the 334 uid attribute is a complete RFC822 address that may but need not be 335 related to the DN of the parent entry. 337 The pattern for a user's DN will be: 339 uid=RFC822 identifier, dc=A, ..., dc=Z 341 We consider each of the two attribute types, uid and dc, used to form 342 the DN in turn. 344 5.2.1 User ID (uid) 346 The userid (uid) attribute is defined and registered in RFC1274 [2]. 348 The value of the user ID attribute for the user's name will be the 349 user's distinguished e-mail address in RFC822 syntax. For example, if 350 there is a user affiliated with the organization Acme having 351 distinguished e-mail address J.Smith@acme.com, the uid attribute will 352 be: 354 uid=J.Smith@acme.com 356 We require uid=J.Smith@acme.com to be a working e-mail address. The 357 whole idea here is that users will remember a working e-mail address; 358 we shouldn't plague them with broken RFC822 addresses constructed for 359 the convenience of the directory service only. The A or MX record for 360 the domain name can point to either a customer or network service 361 provider host. 363 Since an RFC822 identifier unambiguously identifies a user, it can be 364 used (by system processes) to search a particular directory system 365 (e.g. an LDAP server or a related set of LDAP servers) to find a user's 366 entry. The user need not -- and we assume typically will not -- even 367 know his/her DN. See Section 8.1. 369 Directory administrators having several RFC822 identifiers to choose 370 from when constructing a DN for a user should consider the following 371 factors: 373 o Machine-independent addresses are likely to be more stable, 374 resulting in directory names that change less. Thus an identifier 375 such as: 377 js@acme.com 379 may well be preferable to one such as: 381 js@blaster.third-floor.acme.com. 383 o Use of some form of "handle" for the "local-part" that is distinct 384 from a user's real name may result in fewer collisions and less 385 user pain and suffering when a preferred handle is unavailable 386 because it is already in use. Thus the identifier: 388 js@acme.com 390 may well be preferable to one such as: 392 J.Smith@acme.com 394 5.2.2 Domain Component (dc) 396 The domain component attribute is defined and registered in RFC1274 397 [2]. 399 The domain component attributes of a user's DN will normally be 400 constructed from the domain name of his/her distinguished e-mail 401 address. That is, for the user uid=J.Smith@acme.com the domain 402 component attributes would typically be: 404 dc=acme, dc=com 406 The full LDAP DN for this user would then be: 408 uid=J.Smith@acme.com, dc=acme, dc=com 410 It is important to emphasize that the elements of the domain name of 411 the RFC822 identifier may, BUT NEED NOT, be the same as the domain 412 components of the DN. This means that the domain components provide a 413 degree of freedom to support access control or other directory 414 structuring requirements that need not be mechanically reflected in the 415 user's e-mail address. We do not want under any condition to force the 416 user's e-mail address to change just to facilitate a new system 417 requirement such as a modification in an access control structure. It 418 should also be noted that while we do not require that the domain 419 components match the RFC822 identifier, we DO require that the 420 concatenated domain components form a registered domain name, that is 421 one that is represented in the DNS. This avoids name conflicts in the 422 directory hierarchy. 424 To provide an example of a DN which deviates from what might be 425 considered the default structure, consider the following scenario. 427 Suppose that J.Smith needs to be granted special permissions to 428 information in the dc=acme, dc=com part of the LDAP DIT. Since it will 429 be, in general, easier to organize special users by their name 430 structure than via groups (an arbitrary collection of DNs), we use 431 subdomains for this purpose. Suppose the special permissions were 432 required by users in the MIS organizational unit. A subdomain 433 "mis.acme.com" is established, if it does not already exist, according 434 to normal DNS procedures. The special permissions will be granted to 435 users with the name structure: 437 uid=*, dc=mis, dc=acme, dc=com 439 The DN of J.Smith is this case will be: 441 uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com 443 In principal, there is nothing to prevent the domain name elements of 444 the RFC822 identifier from being completely different from the domain 445 components of the DN. For instance, the DN for a J.Smith could be: 447 uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com 449 While we do not REQUIRE that the domain name part of the uid match the 450 dc components of the directory distinguished name, we suggest that this 451 be done where possible. At a minimum, if the most significant pieces of 452 the DN and the uid are the same (i.e., "dc=acme, dc=com" and 453 "acme.com") the likelihood, based on a knowledge of a user's e-mail 454 address, of discovering an appropriate directory system to contact to 455 find information about the user is greatly enhanced. 457 6.0 NAMING FOR CERTIFICATES 459 The certified public keys, certificates, used in SSL and other forms of 460 strong (i.e. cryptographically based) authentication are structured 461 according to the ITU X.509 standard. A certificate contains two names 462 of importance, the name of the "subject" and the "issuer". The subject 463 will be either a user or a server; the issuer will be a certification 464 authority. The encoding of these names differs significantly from the 465 encoding of LDAP names which are simply character strings. In 466 particular, the attribute types used in names are encoded as globally 467 unique "object identifiers." The object identifiers relevant to the 468 names considered in this naming plan are assigned in either the X.500 469 standards (ITU X.520) or RFC1274, the COSINE and Internet X.500 Schema 470 [2]. 472 6.1 User Certificates 474 For user certificates issued by a certification authority, the subject 475 name will be the proper X.509 representation of the user hierarchical 476 DNs described in this paper. 478 6.2 Server/Site Certificates 480 As certificates are used more and more for authentication, applications 481 that run as processes on systems need to be named so that they can also 482 be located in the directory. Since the name of the subject is encoded 483 in a certificate, for application instances to be portable, we need a 484 naming scheme that is independent of the underlying hardware platform 485 and its IP address or DNS host name. 487 In existing Internet products that use certificates, the terms "Server 488 Certificate" and "Site Certificate" have been (mis-)used to identify 489 application instances. 491 We propose that application instances be named similar to individuals 492 as entities under a specific branch of the DIT and be given appropriate 493 unique RFC822 identifiers. The RFC822 identifier so chosen is not 494 constrained by the naming plan. As illustrated in the three examples 495 below, it can be either host-independent (1,2) or host dependent (3). 496 If host-independent, it can be based on a subdomain (2) of the 497 organization's domain name or, if such registration is convenient, 498 based on the domain name (1) itself. 500 A few examples of application instance names are: 502 uid=dirsrv0@acme.com, dc=sales, dc=acme, dc=com (1) 503 uid=certsrv0@sales.acme.com, dc=sales, dc=acme, dc=com (2) 504 uid=gnarlysrv0@surf.sales.acme.com, dc=sales, dc=acme, dc=com (3) 506 This name is used in the construction of the server's certificate. 508 A consequence of this method of constructing names is that application 509 instances have mailboxes. This can be thought of as an opportunity to 510 provide users with a predictable contact for resolution of operational 511 problems with the application much like postmaster@DOMAIN is the 512 predictable contact for e-mail problems at DOMAIN. 514 6.3 Certification Authority Certificates 516 A certification authority (CA) is the trusted guarantor for a user or 517 server certificate. The CA's name appears in the "issuer" field of the 518 certificate it issues. The names of several CAs are already built into 519 popular Internet Web browsers such as the Netscape Navigator and the 520 Microsoft Internet Explorer. Some examples of such CA names are: 522 cn=Certification Authority, o=AT&T, c=US 523 cn=Directory Services, o=AT&T, c=US 524 cn=Certificate Services, o=AT&T, c=US 526 These names use the traditional X.500 attributes for naming. These 527 attributes are common name (cn), organization name (o) and country name 528 (c). To maintain compatibility, the appropriate CAs can be 529 incorporated in any LDAP-based directory service with these existing 530 names. 532 In future, new certification authorities should be assigned names 533 following the structure described in this document. 535 7.0 CONSUMER DIRECTORY SERVICES 537 Consumer customers are typically supported by on-line service 538 providers, such as AT&T WorldNet, America On-Line, CompuServe, etc. 539 Entries for these customers can also be represented in the LDAP DIT by 540 names with the following structure (reflecting current e-mail address 541 assignment practice): 543 uid=J.Smith@worldnet.att.net, dc= worldnet, dc=att, dc=net 545 Modifications in this practice (to avoid the M.Jones99 problem) by 546 using additional subdomains of worldnet.att.net can be easily 547 accommodated by the scheme described here, but such ideas are left to 548 the discretion of the on-line service provider. 550 8.0 IMPLEMENTATION ISSUES 552 8.1 Directory Services Considerations 554 This naming plan has been designed so that a user's entry can be found 555 uniquely using nothing but the user's distinguished e-mail address -- 556 assuming that the query is sent to the right LDAP directory server. 557 Systems having the user's DN in hand can, of course, directly access 558 the user's entry via LDAP. 560 An LDAP search request with the following components will either (1) 561 find uniquely the entry of a user with the provided distinguished 562 e-mail address, or (2) indicate that no user has the provided e-mail 563 address as a distinguished e-mail address: 565 baseObject: root 566 scope: wholeSubtree 567 filter: equalityMatch (uid == distinguished e-mail address) 569 A search such as this is possible in LDAP servers being planned 570 because, unlike X.500 servers, the LDAP servers we envision are not 571 universally interconnected in one global system according to the X.500 572 knowledge model. In X.500 such a search would propagate to all the 573 servers in the system; in the envisioned LDAP system it would be 574 limited to one server (or potentially a small set of servers). 576 In a world of LDAP islands, the issue of finding the right island to 577 which to direct a directory query arises. The new version of LDAP 578 under design in the IETF [11] has a referral mechanism. Given a query, 579 a server can return a referral to an other LDAP server that might hold 580 the data. This approach can be used to tie together the servers holding 581 the distributed data of an LDAP island. By generalizing this concept 582 one can imagine building a simple referral server that knows about the 583 LDAP islands of the Internet. It would compare the naming information 584 in a query it receives with its knowledge of LDAP islands and return a 585 referral to the appropriate island. 587 It has been traditional in X.500 and LDAP directory services to employ 588 the common name (cn) attribute in naming. While this naming plan 589 doesn't use the cn attribute, it should be stressed that it is still 590 quite important. It will play a significant role in enabling searches 591 to find user entries of interest. To this end, what is typically done 592 is to have multiple values of the common name attribute in the user's 593 entry. Thus the entry for J.Smith@acme.com might well have the common 594 name attribute values "John Smith", "John Q. Smith" and "John Quincy 595 Smith" to optimize matching of search requests. 597 The attribute rfc822mailbox (or mail) is normally used to hold a user's 598 e-mail address in X.500 and LDAP directory services. A user with 599 multiple e-mail addresses will not be assigned multiple DNs simply 600 because of the multiple addresses. As described above, one of these 601 e-mail addresses -- a machine-independent and fairly static one -- will 602 be elected the distinguished e-mail address and used to construct the 603 DN. If it is desirable to make available the other e-mail addresses, 604 they can be stored in the user's rfc822mailbox attribute. It is 605 technically possible, although undesirable because potentially 606 confusing, that the rfc822mailbox attribute does NOT contain the 607 distinguished e-mail address as one of its values. 609 8.2 Alternative DN Structures 611 Some organizations may wish to be represented by a scheme based upon a 612 more classic X.500/NADF naming system [12]. These organizations can be 613 accommodated in the scheme without significant problems or naming 614 conflicts. 616 The approach we take should not preclude participation in a larger 617 directory service, so names held in the stand-alone LDAP directory 618 shouldn't collide unnecessarily with names held by other directory 619 service operators. (If two directory service providers hold 620 information with respect to the same DN, these are two different views 621 of the same real world object, not two unrelated objects that 622 accidentally share a "name.") Naming based on DNS meets this 623 criterion. Disciplined use of X.500 naming can also meet this 624 criterion. 626 To enable a consistent searching strategy, we strongly recommend the 627 user ID (uid) attribute, although not part of the DN, have a valid 628 RFC822 identifier for the user. The LDAP DIT structure will follow the 629 typical X.500/NADF approach as follows: 631 Organizations wishing to pursue this approach will need to register 632 their organization's name with the appropriate authority as generally 633 accepted in the X.500/NADF community. This means that US organizations 634 will register with ANSI. The resort to the civil naming infrastructure 635 of states and counties should be actively discouraged. The names 636 constructed from this civil naming infrastructure (a la NADF), while 637 meeting the technical criteria for non-ambiguity and right to use, are 638 typically long and unwieldy. 640 Suppose the US company "XYZ Widgets" expressed a wish to follow this 641 approach. A typical user name might be 643 uid=J.User@xyzwidgets.com, o="XYZ Widgets, Inc.", c=US 645 where o="XYZ Widgets, Inc.", c=US is an ANSI registered name. (The 646 "alphanumeric string" registered with ANSI is 'XYZ Widgets, Inc.', 647 where the single quotes mark off what is registered but are not part of 648 the registered information.) 650 To support structured access control within the company the analogous 651 form to the registration of a subdomain in the mainline approach is the 652 creation of an organizational unit node. 654 8.3 Tagless Naming 656 The LDAP names of the form "cn=John Smith, ou= Corporate Sales, ou= 657 South East Region, o= Acme Service Corporation Inc., l= Monmouth, 658 st=New Jersey, c= US" are perpetually confusing to users. It is also 659 hard for an intermediate system to add tags correctly if a user does 660 not supply them. 662 This naming plan is eminently suited for the support of tag-less 663 naming. While supporting strong typing, we use a limited number of 664 tags -- uid for all leaf objects and dc for all non-leaf objects, and 665 hence adding tags is straight-forward. In the rare cases when users 666 must supply DNs, they will therefore do so without having to know about 667 tags. 669 9.0 SECURITY CONSIDERATIONS 671 Security considerations are not part of this paper. 673 10.0 ACKNOWLEDGMENTS 675 This plan has emerged in the course of a number of fruitful 676 discussions, especially with Joe Gajewski, Mark Jackson, Ryan Moats, 677 Tom Spencer and Chris Tzu. 679 11.0 REFERENCES 681 [1] X.500: The Directory -- Overview of Concepts, Models, and 682 Service, CCITT Recommendation X.500, December, 1988. 684 [2] P.Barker, and S. Kille, "The COSINE and Internet X.500 Schema", 685 RFC1274, 11/27/1991. 687 [3] The North American Directory Forum, "A Naming Scheme for c=US", 688 RFC1255, September 1991. 690 [4] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory Access 691 Protocol", RFC1777, 03/28/1995. (Work is also underway in the 692 IETF to produce an extended version of LDAP.) 694 [5] J. Postel, and C. Anderson, "White Pages Meeting Report", 695 RFC1588, February 1994. 697 [6] Sollins, K., "Plan for Internet Directory Services", RFC 1107, 698 July 1989. 700 [7] S. Kille, "A String Representation of Distinguished Names", 701 RFC1779, 03/28/1995. 703 [8] A. Freier, P. Karlton, and P. Kocher, "The SSL Protocol Version 704 3.0", Work in Progress, Internet Draft 705 , March 1996. 707 [9] D. Crocker, "Standard for the format of ARPA Internet text 708 messages", RFC822, 08/13/1982. 710 [10] S. Kille, "X.500 and Domains", RFC1279, 11/27/1991. 712 [11] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 713 Protocol (v3)", Work in Progress, Internet Draft 714 , October 22, 1996. 716 [12] The North American Directory Forum, "NADF Standing Documents: A 717 Brief Overview", RFC 1417, The North American Directory Forum", 718 NADF, February 1993. 720 12. Authors' Address 722 Al Grimstad 723 AT&T 724 Room 1C-429, 101 Crawfords Corner Road 725 Holmdel, NJ 07733-3030 726 USA 728 EMail: alg@att.com 730 Rick Huber 731 AT&T 732 Room 1B-433, 101 Crawfords Corner Road 733 Holmdel, NJ 07733-3030 734 USA 736 EMail: rvh@att.com 738 Sri Sataluri 739 AT&T 740 Room 4G-202, 101 Crawfords Corner Road 741 Holmdel, NJ 07733-3030 742 USA 744 EMail: sri@att.com