idnits 2.17.1 draft-ietf-ids-dirnaming-01.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-25) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 986 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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 636 has weird spacing: '... of the group...' -- 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 (March 12, 1997) is 9906 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') ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1779 (ref. '8') (Obsoleted by RFC 2253, RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** 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: 19 errors (**), 0 flaws (~~), 3 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 Steve Kille 6 Isode Ltd. 7 Mark Wahl 8 Critical Angle Inc. 10 March 12, 1997 12 Naming Plan for an Internet Directory Service 13 Filename: draft-ietf-ids-dirnaming-01.txt 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this document is unlimited. Editorial comments should 34 be sent directly to the authors. Technical discussion will take place 35 on the IETF Integrated Directory Services mailing list, 36 ietf-ids@umich.edu. 38 This Internet Draft expires August 1, 1997. 40 Abstract 42 Application of the conventional X.500 approach to naming has, in the 43 experience of the authors, proven to be an obstacle to the creation of 44 directory services. We propose a new directory naming plan that 45 leverages the strengths of the most popular and successful Internet 46 naming schemes for naming objects in a hierarchical directory. This 47 plan can, we believe, facilitate the creation of an Internet White 48 Pages Service (IWPS) and other directory-enabled applications by 49 overcoming the problems encountered by those using the conventional 50 recommended X.500 approach to naming. 52 1.0 EXECUTIVE SUMMARY 54 The conventional approach to naming taken by the X.500 community has, 55 in the experience of the authors, shown itself to be an obstacle to 56 the creation of directory services. The required registration 57 infrastructure is either non-existent or largely ignored. The 58 infrastructure that does exist is cumbersome to use and tends to 59 produce counterproductive results. The attributes used for naming 60 have been confusing for users and inflexible to managers and operators 61 of directory services. 63 This paper describes an alternative directory naming plan for the 64 construction of the Internet White Pages Service (IWPS) and other 65 directory-enabled applications. It has three main features. First, it 66 bases directory name construction on the existing infrastructure of 67 names in the Internet, that is, names from the Domain Name System 68 (DNS) and mailbox identifiers structured according to RFC822. Second, 69 names constructed according to this plan use existing standardized 70 directory attributes and can co-exist with names constructed according 71 to traditional X.500 naming practices. And third, the hierarchical 72 pattern of directory names need not mirror exactly the domain part of 73 RFC822 mailbox identifiers, but can be structured to support various 74 requirements such as data partitioning and access control lists (ACLs) 75 based on the naming hierarchy. 77 Here, in summary, is our proposal. 79 For naming entries of leaf directory objects such as users, groups, 80 server applications and certification authorities in a hierarchical 81 directory (e.g., one accessed via LDAP, the Lightweight Directory 82 Access Protocol), we propose the use of the user identifier attribute 83 "uid" for the relative distinguished name. The value of this 84 attribute should be an RFC822 address, e.g., 86 uid=John.Smith@acme.com 88 To address situations where it is inconvenient or inappropriate to use 89 an RFC822 mailbox identifier for a leaf directory object, we propose 90 the use of the conventional common name attribute, "cn". 92 The upper portions of the hierarchical directory tree should be 93 constructed using the components of registered DNS names using the 94 domain component attribute "dc". The directory name for the 95 organization having the domain name acme.com will then be, e.g., 97 dc=acme, dc=com 99 Organizations can add additional directory structure, for example to 100 support implementation of access control lists or partitioning of their 101 directory information, by using registered subdomains of DNS names, 102 e.g., 104 dc=corporate, dc=acme, dc=com 106 Directory distinguished names will thus have the following structure, 107 e.g., 109 uid=John.Smith@acme.com, dc=acme, dc=com 110 uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com 111 uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com 112 cn=Reading Room, dc=physics, dc=national-lab, dc=edu 114 Searching the directory (for persons, or other similar objects) based 115 on exact matching of the uid attribute should be optimized in the 116 directory service such that it is essentially equivalent to searching 117 using a directory distinguished name. 119 External mechanisms can be used to locate the proper directory server 120 to query to obtain directory information. 122 2.0 THE PROBLEM 124 The X.500 Directory model [1] 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 is 128 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 several 134 ways to limit the growth of an Internet White Pages Service based on 135 X.500. 137 2.1 Naming Problems 139 The conventional way to construct names in the X.500 community is 140 documented as an informative (i.e., not officially standardized) Annex 141 B to X.521. The relative distinguished name (RDN) of a user consists of 142 a common name (cn) attribute. This is meant to be what -- in the user's 143 particular society -- is customarily understood to be the name of that 144 user. The distinguished name of a user is the combination of the name 145 of some general object, such as an organization or a geographical unit, 146 with the common name. There are two main problems with this style of 147 name construction. 149 First, the common name attribute, while seeming to be user-friendly, 150 cannot be used generally as an RDN in practice. In any significant 151 set of users to be named under the same Directory Information Tree 152 (DIT) node there will be collisions on common name. There is no way 153 to overcome this other than either by forcing uniqueness on common 154 names, something they do not possess, or by using an additional 155 attribute to prevent collisions. This additional attribute normally 156 needs to be unique in a much larger context to have any practical 157 value. The end result is a RDN that is very long and unpopular with 158 users. 160 Second, and more serious, X.500 has not been able to use any 161 significant number of pre-existing names. Since X.500 naming models 162 typically use organization names as part of the hierarchy [2, 3], 163 organization names must be registered. As organization names are 164 frequently tied to trademarks and are used in sales and promotions, 165 registration can be a difficult and acrimonious process. 167 The North American Directory Forum (NADF, now the North Atlantic 168 Directory Forum but still the NADF) proposed to avoid the problem of 169 registration by using names that were already registered in the "civil 170 naming infrastructure" [3]. Directory distinguished names would be 171 based on an organization's legal name as recognized by some 172 governmental agency (county clerk, state secretary of state, etc.) or 173 other registering entity such as ANSI. 175 This scheme has the significant advantage of keeping directory service 176 providers out of disputes about the right to use a particular name, 177 but it leads to rather obscure names. Among these obscurities, the 178 legal name almost invariably takes a form that is less familiar and 179 longer than what users typically associate with the organization. For 180 example, in the US a large proportion of legal organization names end 181 with the text ", Inc." as in "Acme, Inc." Moreover, in the case of 182 the US, the civil naming infrastructure does not operate nationally, 183 so the organization names it provides must be located under state and 184 regional DIT nodes, making them difficult to find while browsing the 185 directory. NADF proposes a way to algorithmically derive 186 multi-attribute RDNs which would allow placement of entries or aliases 187 in more convenient places in the DIT, but these derived names are 188 cumbersome and unpopular. For example, suppose Nadir is an 189 organization that is registered in New Jersey civil naming 190 infrastructure under the name "Nadir Networks, Inc." Its civil 191 distinguished name (DN) would then be 193 o="Nadir Networks, Inc.", st=New Jersey, c=US 195 while its derived name which is unambiguous under c=US directly is 197 o="Nadir Networks, Inc." + st=New Jersey, c=US 199 More generally, the requirement for registration of organizations in 200 X.500 naming has led to the establishment of national registration 201 authorities whose function is mainly limited to assignment of X.500 202 organization names. Because of the very limited attraction of X.500, 203 interest in registering an organization with one of these national 204 authorities has been minimal. Finally, multi-national organizations are 205 frustrated by a lack of an international registration authority. 207 2.2 Directory Models 209 The Internet community proposed the Light-weight Directory Access 210 Protocol (LDAP) [4], initially, as a simplified access method for 211 X.500 directories. However, more recently, a number of different 212 directory server implementations have begun to appear that use LDAP as 213 an access protocol to backend retrieval systems not based on X.500. 215 The X.500 Directory, via its knowledge model, attempts to build a 216 world-wide directory in a top-down fashion. This approach has only met 217 with partial success. 219 The appearance on the Internet of directory systems supporting LDAP 220 but not tied into the world of X.500 will, in our opinion, stimulate 221 the creation of directories in a bottom-up fashion [5]. These 222 directory servers or directory islands will be loosely tied together 223 via LDAP referrals and other external mechanisms. 225 For such loosely coordinated mechanisms to work effectively, a few of 226 the general properties of X.500 need to be retained. Among these are 227 (1) an approach to naming that makes the linkage of the directory 228 islands as simple as possible, and (2) an extendible schema of 229 directory information with a widely accepted common base. The naming 230 plan described here supports these two characteristics. 232 2.3 Addressing the Problems 234 This paper describes a directory naming plan that is a radical 235 departure from the traditional X.500 naming scheme -- the X.500 scheme 236 has not been generally accepted by the Internet community and has been 237 found to be very clumsy in implementing and administering directory 238 services by the authors. 240 This naming plan is straightforward to implement by both classic X.500 241 systems and islands of stand-alone LDAP servers. Its unique strength 242 lies in its use of the existing Internet naming schemes -- RFC822 243 addresses [6] and the Domain Name System [7]. Further, by use of an 244 attribute, the user ID attribute, and a tree structure based on the 245 DNS, the plan, if broadly implemented, may well simplify the 246 construction of external mechanisms to locate appropriate LDAP 247 servers. 249 The focus of this naming plan is on naming Internet users, 250 certification authorities and server applications. It is not 251 applicable to resolving problems with naming objects such as X.500 252 residential persons which typically lack e-mail addresses. Because it 253 is a hierarchical plan using typed attribute values (tags), the naming 254 plan can co-exist with other hierarchical plans using other typed 255 attributes such as a plan for residential persons and the conventional 256 X.521 Annex B plan. 258 3.0 TECHNOLOGICAL ASSUMPTIONS 260 We assume that the fundamental protocol interface to systems offering 261 general directory services will be the TCP/IP-based Lightweight 262 Directory Access Protocol. Objects -- users, certification 263 authorities and server applications -- are named in this protocol in a 264 hierarchical fashion and represented as described in RFC 1779 [8]. We 265 also assume that user authentication and other security services will 266 increasingly depend on public key cryptographic techniques such as 267 those used in the Secure Sockets Layer (SSL) [9]. These techniques use 268 information such as certificates (certified public cryptographic keys) 269 in which objects are identified with directory names. 271 4.0 IDENTIFICATION 273 The one universally accepted scheme of user identification (actually 274 user maildrop or mailbox identification) in the Internet today is the 275 RFC822 syntax for e-mail addresses. The RFC822 syntax contains a 276 domain name and a user identifier that is local to that domain. 278 4.1 Domain Identification 280 The syntax of a domain identifier is defined by the Domain Name System 281 (DNS) in RFC 1034 [6]. Examples of such identifiers are acme.com and 282 foo.nj.us. 284 4.2 RFC822 Identification 286 The syntax of an RFC822 identifier is: 288 local@domain 290 where 292 "domain" is a hierarchically structured identifier as defined 293 by the DNS, and 295 "local" is an identifier for a user (literally a maildrop) 296 that is valid within the domain "domain". 298 Examples of such identifiers are J.Smith@acme.com and 299 S.Johnson@corporate.acme.com. 301 Each user for whom information is maintained in a directory service 302 will typically have at least one e-mail address structured according 303 to RFC822. While the user may well have many such addresses, one will 304 be selected for the purpose of user identification. We call this the 305 "distinguished" e-mail address or the "distinguished" RFC822 306 identifier for the user. 308 5.0 DIRECTORY DISTINGUISHED NAMES 310 5.1 Overview of Distinguished Names 312 The general structure of a name in LDAP, termed a distinguished name 313 (DN), is: 315 attribute, attribute, ... attribute 317 An "attribute" is a pairing of a type identifier and a value separated 318 by "=". For example, cn=Samuel Johnson is an attribute with type 319 identifier "cn", short for common name, and value "Samuel Johnson". 321 The order of the attributes in a DN is significant. Like DNS 322 identifiers, DNs are hierarchical and "little endian", that is, the 323 most global piece comes last. An example of a DN is: 325 cn=Samuel Johnson, o=Famous Lexicographers, c=GB 327 where: 329 cn=Samuel Johnson means the attribute type "cn" has the value 330 "Samuel Johnson", 332 o=Famous Lexicographers means that the attribute type "o", short 333 for organization name, has the value "Famous Lexicographers", and 335 c=GB means that the attribute type "c", short for country name, has 336 the value "GB", the international abbreviation for the country 337 Great Britain. 339 The set of all DNs forms a tree structure that is called the Directory 340 Information Tree (DIT). 342 5.2 Directory Distinguished Names 344 Suppose an organization, e.g., Acme, wants to bring up a directory 345 service. It either has a registered DNS name or it should get one. 347 Given a DNS name, we will use a form of DN construction largely based 348 on RFC1279 [10]. This RFC shows how to map an RFC822 e-mail address to 349 a DN. We differ from it in two respects: (1) we use a mapping that 350 starts at the root of the DIT; and (2) we use the attribute type user 351 ID (userid or uid) for the first attribute of the DN. The value of the 352 uid attribute is a complete RFC822 address that may but need not be 353 related to the DN of the parent entry. 355 The pattern for the organization's DN will be: 357 dc=A, ..., dc=Z 359 and the pattern for the DN of a user in that organization will be: 361 uid=RFC822 identifier, dc=A, ..., dc=Z 363 We consider each of the two attribute types, dc and uid, used to form 364 the DN in turn. 366 5.2.1 Domain Component (dc) 368 The domain component attribute is defined and registered in RFC1274 369 [2]. 371 The domain component attributes of a organization's DN will normally be 372 constructed from the domain name of that organization. That is, for the 373 organization "Acme, Inc." with domain name "acme.com", the DN will be 375 dc=acme, dc=com 377 The domain component attributes of a user's DN will normally be 378 constructed from the domain name of his/her distinguished e-mail 379 address. That is, for the user uid=J.Smith@acme.com the domain 380 component attributes would typically be: 382 dc=acme, dc=com 384 The full LDAP DN for this user would then be: 386 uid=J.Smith@acme.com, dc=acme, dc=com 388 The algorithm for constructing the uid part of the DN is given in section 389 5.2.2. 391 It is important to emphasize that the elements of the domain name of 392 an RFC822 identifier may, BUT NEED NOT, be the same as the domain 393 components of the DN. This means that the domain components provide a 394 degree of freedom to support access control or other directory 395 structuring requirements that need not be mechanically reflected in 396 the user's e-mail address. We do not want under any condition to 397 force the user's e-mail address to change just to facilitate a new 398 system requirement such as a modification in an access control 399 structure. It should also be noted that while we do not require that 400 the domain components match the RFC822 identifier, we DO require that 401 the concatenated domain components form a registered domain name, that 402 is, one that is represented in the DNS. This automatically avoids name 403 conflicts in the directory hierarchy. 405 To provide an example of a DN which deviates from what might be 406 considered the default structure, consider the following scenario. 408 Suppose that J.Smith needs to be granted special permissions to 409 information in the dc=acme, dc=com part of the LDAP DIT. Since it will 410 be, in general, easier to organize special users by their name 411 structure than via groups (an arbitrary collection of DNs), we use 412 subdomains for this purpose. Suppose the special permissions were 413 required by users in the MIS organizational unit. A subdomain 414 "mis.acme.com" is established, if it does not already exist, according 415 to normal DNS procedures. The special permissions will be granted to 416 users with the name structure: 418 uid=*, dc=mis, dc=acme, dc=com 420 The DN of J.Smith in this case will be: 422 uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com 424 In principal, there is nothing to prevent the domain name elements of 425 the RFC822 identifier from being completely different from the domain 426 components of the DN. For instance, the DN for a J.Smith could be: 428 uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com 430 While we do not REQUIRE that the domain name part of the uid match the 431 dc components of the directory distinguished name, we suggest that this 432 be done where possible. At a minimum, if the most significant pieces of 433 the DN and the uid are the same (i.e., "dc=acme, dc=com" and 434 "acme.com") the likelihood, based on a knowledge of a user's e-mail 435 address, of discovering an appropriate directory system to contact to 436 find information about the user is greatly enhanced. 438 The example above represents a situation where this suggestion isn't 439 possible because some of the users in a population have mailbox 440 identifiers that differ from the pattern of the rest of the users, 441 e.g., most mailboxes are of the form local@acme.com, but a 442 subpopulation have mailboxes from an ISP and therefore mailboxes of 443 the form local@worldnet.att.net. 445 5.2.2 User ID (uid) 447 The userid (uid) attribute is defined and registered in RFC1274 [2]. 449 The value of the user ID attribute for the user's name will be the 450 user's distinguished e-mail address in RFC822 syntax. For example, if 451 there is a user affiliated with the organization Acme having 452 distinguished e-mail address J.Smith@acme.com, the uid attribute will 453 be: 455 uid=J.Smith@acme.com 457 We strongly suggest that uid=J.Smith@acme.com to be a working e-mail 458 address. The whole idea here is that users will remember a working 459 e-mail address; we shouldn't plague them with broken RFC822 addresses 460 constructed for the convenience of the directory service only. The A 461 or MX record for the domain name can point to either a customer or 462 network service provider host. 464 Since an RFC822 identifier unambiguously identifies a user, it can be 465 used (by system processes) to search a particular directory system 466 (e.g. an LDAP server or a related set of LDAP servers) to find a user's 467 entry. The user need not -- and we assume typically will not -- even 468 know his/her DN. See Section 8.1. 470 Directory administrators having several RFC822 identifiers to choose 471 from when constructing a DN for a user should consider the following 472 factors: 474 o Machine-independent addresses are likely to be more stable, 475 resulting in directory names that change less. Thus an identifier 476 such as: 478 js@acme.com 480 may well be preferable to one such as: 482 js@blaster.third-floor.acme.com. 484 o Use of some form of "handle" for the "local" part that is distinct 485 from a user's real name may result in fewer collisions and 486 thereby lessen user pain and suffering. Thus the identifier: 488 js@acme.com 490 may well be preferable to one such as: 492 J.Smith@acme.com 494 Practical experience with use of the RFC822 mailbox identifier scheme 495 described here has shown that there are situations where it is 496 convenient to use such identifies for all users in a particular 497 population, although a few users do not, in fact, possess working 498 mailboxes. For example, an organization may have a existing unique 499 identification scheme for all employees that is used as a alias to the 500 employees' real mailboxes -- which may be quite heterogeneous in 501 structure. The identification scheme works for all employees to 502 identify unambiguously each employee; it only works as an e-mail alias 503 for those employees having real mailboxes. For this reason it would 504 be a bad assumption for directory-enabled applications to use the uid 505 as a mailbox; the value(s) of the mail attribute should always be 506 checked. 508 5.2.3 Common Name 510 To address situations where it is inconvenient or inappropriate to use 511 an RFC822 mailbox identifier for the RDN of a leaf directory object, 512 we propose the use of the conventional common name attribute, "cn". 514 As an example of the assignment of a DN to a directory object for 515 which the creation of a uid would be cumbersome, consider naming an 516 object of class room, specified in 8.3.5 of the COSINE and Internet 517 X.500 Schema [2]. For example, the following name might be more 518 natural for the directory administrator to assign and for applications 519 using this sort of object to use: 521 cn=Reading Room, dc=physics, dc=national-lab, dc=edu 523 In certain environments, especially where there are a relatively small 524 number of users requiring DNs, that is, where name collisions of the 525 common name will not happen, it may be convenient to use the 526 traditional X.500 common name attribute as in: 528 cn=John Smith, dc=mis, dc=acme, dc=com 530 6.0 NAMING FOR CERTIFICATES 532 The certified public keys, certificates, used in SSL and other forms of 533 strong (i.e. cryptographically based) authentication are structured 534 according to the ITU X.509 standard. A certificate contains two names 535 of importance, the name of the "subject" and the "issuer". The subject 536 will be either a user or a server; the issuer will be a certification 537 authority. The encoding of these names differs significantly from the 538 encoding of LDAP names which are simply character strings. In 539 particular, the attribute types used in names are encoded as globally 540 unique "object identifiers." The object identifiers relevant to the 541 names considered in this naming plan are assigned in either the X.500 542 standards (ITU X.520) or RFC1274, the COSINE and Internet X.500 Schema 543 [2]. 545 6.1 User Certificates 547 For user certificates issued by a certification authority, the subject 548 name will be the proper X.509 representation of the user hierarchical 549 DNs described in section 5 of this paper. 551 6.2 Server/Site Certificates 553 As certificates are used more and more for authentication, applications 554 that run as processes on systems need to be named so that they can also 555 be located in the directory. Since the name of the subject is encoded 556 in a certificate, for application instances to be portable, we need a 557 naming scheme that is independent of the underlying hardware platform 558 and its IP address or DNS host name. 560 In existing Internet products that use certificates, the terms "Server 561 Certificate" and "Site Certificate" have been (mis-)used to identify 562 application instances. 564 We propose that application instances be named similar to individuals 565 as entities under a specific branch of the DIT and be given appropriate 566 unique RFC822 identifiers. The RFC822 identifier so chosen is not 567 constrained by the naming plan. As illustrated in the three examples 568 below, it can be either host-independent (1,2) or host dependent (3). 569 If host-independent, it can be based on a subdomain (2) of the 570 organization's domain name or, if such registration is convenient, 571 based on the domain name (1) itself. 573 A few examples of application instance names are: 575 uid=dirsrv0@acme.com, dc=sales, dc=acme, dc=com (1) 576 uid=certsrv0@sales.acme.com, dc=sales, dc=acme, dc=com (2) 577 uid=gnarlysrv0@surf.sales.acme.com, dc=sales, dc=acme, dc=com (3) 579 This name is used in the construction of the server's certificate. 581 A consequence of this method of constructing names is that application 582 instances have mailboxes. This can be thought of as an opportunity to 583 provide users with a predictable contact for resolution of operational 584 problems with the application much like postmaster@DOMAIN is the 585 predictable contact for e-mail problems at DOMAIN. 587 To address situations where it is inconvenient or inappropriate to use 588 an RFC822 mailbox identifier for the RDN of an application instance, 589 we propose the use of the conventional common name attribute, "cn". 591 6.3 Certification Authority Certificates 593 A certification authority (CA) is the trusted guarantor for a user or 594 server certificate. The CA's name appears in the "issuer" field of the 595 certificate it issues. The names of several CAs are already built into 596 popular Internet Web browsers such as the Netscape Navigator and the 597 Microsoft Internet Explorer. Some examples of such CA names are: 599 ou=Directory Services, o=AT&T, c=US 600 ou=Secure Server Certification Authority, o="RSA Data Security, Inc.", 601 c=US 603 These names use the traditional X.500 attributes for naming. These 604 attributes are organizational unit name (ou), organization name (o) 605 and country name (c). To maintain compatibility, the appropriate CAs 606 can be incorporated in any LDAP-based directory service with these 607 existing names. 609 In future, new certification authorities may be assigned names 610 following the structure described in section 5 of this 611 document. Examples of such new CA names are: 613 uid=certification-authority@CAs-R-us.com, dc=CAs-R-us, dc=com 614 cn=certification authority, dc=CAs-R-us, dc=com 615 dc=certification-authority, dc=CAs-R-us, dc=com 617 7.0 OTHER DIRECTORY OBJECTS 619 This subsection of the naming plan is concerned with other 620 miscellaneous directory objects for which a regular naming structure 621 is required. This collection of objects consists, at this point, only 622 of groups. Other documents may define the naming plans for representing 623 other kinds of objects in the directory. 625 7.1 Groups 627 A group is a directory object, and therefore has a directory name. It 628 expresses membership of other directory objects in a set. Examples of 629 groups are: a set of users permitted to modify the entries in a 630 subtree of the DIT; a set of users permitted to view a related set of 631 web pages; and a set of e-mail recipients interested in a particular 632 subject. Note that the latter example is, from a UNIX-centric 633 perspective, at this point a hypothetical directory oriented 634 example. In practice, groups in the UNIX-centric part of e-mail world, 635 more commonly termed mailing lists, are not represented by directory 636 group entries and members of the group are identified by an e-mail 637 address rather than a directory name. 639 Group objects in the directory are named following the same structure 640 as users and servers: the RDN of the object uses a uid attribute value 641 and the group object is placed under an appropriate domain object. As 642 in the case of users and servers, the uid attribute value must be a 643 valid RFC822 mailbox identifier. There is no particular requirement 644 and, in fact, it might even be undesirable, that e-mail sent to this 645 mailbox should be exploded to the mailboxes of the members of the group. 646 On the other hand, it might well be convenient that the uid used as 647 the RDN of a group object be the mailbox of a list rather than an 648 individual. 650 For example, suppose the directory administrators for the dc=acme, 651 dc=com subtree of the DIT have set up an e-mail list 652 ds-admin@acme.com. It might be convenient to create a directory group 653 with the name 655 uid=ds-admin@acme.com, dc=acme, dc=com 657 for the construction of access control lists in the acme subtree, 658 granting members of this list modification permissions on all the 659 entries. In this case e-mail sent to ds-admin@acme.com would typically 660 go, in a UNIX-centric environment, not to the members of the directory 661 group as defined by the attribute of the group's entry that identifies 662 the members, but to the list of mailboxes exploded at the host 663 acme.com. 665 To address situations where it is inconvenient or inappropriate to use 666 an RFC822 mailbox identifier for the RDN of a group object, we propose 667 the use of the conventional common name attribute, "cn". 669 8.0 IMPLEMENTATION ISSUES 671 8.1 Directory Services Considerations 673 This naming plan has been designed so that a user's entry can be found 674 unambiguously using nothing but the user's distinguished e-mail address -- 675 assuming that the query is sent to the right LDAP directory server. 676 Systems having the user's DN in hand can, of course, directly access 677 the user's entry via LDAP. 679 An LDAP search request with the following components will either (1) 680 find uniquely the entry of a user with the provided distinguished 681 e-mail address, or (2) indicate that no user has the provided e-mail 682 address as a distinguished e-mail address: 684 baseObject: root 685 scope: wholeSubtree 686 filter: equalityMatch (uid == distinguished e-mail address) 688 A search such as this is possible in LDAP servers being planned 689 because, unlike X.500 servers, the LDAP servers we envision are not 690 universally interconnected in one global system according to the X.500 691 knowledge model. In X.500 such a search would propagate to all the 692 servers in the system; in the envisioned LDAP system it would be 693 limited to one server (or potentially a small set of servers). 695 In a world of LDAP islands, the issue of finding the right island to 696 which to direct a directory query arises. The new version of LDAP 697 under design in the IETF [11] has a referral mechanism. Given a query, 698 a server can return a referral to an other LDAP server that might hold 699 the data. This approach can be used to tie together the servers holding 700 the distributed data of an LDAP island. By generalizing this concept 701 one can imagine building a simple referral server that knows about the 702 LDAP islands of the Internet. It would compare the naming information 703 in a query it receives with its knowledge of LDAP islands and return a 704 referral to the appropriate island. 706 It has been traditional in X.500 and LDAP directory services to employ 707 the common name (cn) attribute in naming. While this naming plan 708 doesn't require use of the cn attribute in naming, it should be 709 stressed that it is still quite important. It will play a significant 710 role in enabling searches to find user entries of interest. To this 711 end, what is typically done is to have multiple values of the common 712 name attribute in the user's entry. Thus the entry for 713 J.Smith@acme.com might well have the common name attribute values 714 "John Smith", "John Q. Smith" and "John Quincy Smith" to optimize 715 matching of search requests. 717 The attribute rfc822mailbox (or mail) is normally used to hold a user's 718 e-mail address in X.500 and LDAP directory services. A user with 719 multiple e-mail addresses will not be assigned multiple DNs simply 720 because of the multiple addresses. As described above, one of these 721 e-mail addresses -- a machine-independent and fairly static one -- will 722 be elected the distinguished e-mail address and used to construct the 723 DN. If it is desirable to make available the other e-mail addresses, 724 they can be stored in the user's rfc822mailbox attribute. It is 725 technically possible, although undesirable because potentially 726 confusing, that the rfc822mailbox attribute does NOT contain the 727 distinguished e-mail address as one of its values. 729 An important matter for directory administrators to consider with 730 respect to the use of RFC822 mailbox identifiers is that it is 731 possible to construct more than one DN using the same mailbox 732 identifier as the RDN. This may or may not have undesirable 733 consequences, depending on the expectations of specific applications 734 accessing the directory. The safest practice is probably to avoid such 735 multiple use of the same mailbox identifier. 737 Another less safe alternative might be to only permit such multiple 738 use in cases where the directory objects with the same uid as the RDN 739 have different base object classes. This would permit applications -- 740 which would need to be aware of this nuance -- to find objects based 741 on searches for specific uid values to distinguish between meaningful 742 and non-meaningful directory objects. 744 Consider the following example. Suppose two directory objects were to 745 be created by Acme, 747 uid=ds-dsadmin@acme.com, dc=engr, dc=acme, dc=com (1) 749 and 751 uid=ds-admin@acme.com, dc=acme, dc=com (2). 753 The first object represents an administrative user and is of object 754 class organizational role. The second represents a group and 755 represents a list of objects (expressed by the values of the member 756 attribute) who have been granted some form of administrative 757 permission. An application wishing to determine the group members and 758 knowing only the uid value "ds-admin@acme.com" might experience 759 problems if it naively expected expected the first match found under 760 dc=acme, dc=com to contain a member attribute. 762 8.2 Alternative DN Structures 764 Some organizations may wish to be represented by a scheme based upon a 765 more classic X.500/NADF naming system [12]. These organizations can be 766 accommodated in the scheme without significant problems or naming 767 conflicts. 769 The approach we take should not preclude participation in a larger 770 directory service, so names held in the stand-alone LDAP directory 771 shouldn't collide unnecessarily with names held by other directory 772 service operators. (If two directory service providers hold 773 information with respect to the same DN, these are two different views 774 of the same real world object, not two unrelated objects that 775 accidentally share a "name.") Naming based on DNS meets this 776 criterion. Disciplined use of X.500 naming can also meet this 777 criterion. 779 To enable a consistent searching strategy in a directory where objects 780 named according to the plan described here as well as the classic 781 X.500/NADF naming system, we strongly recommend the user ID (uid) 782 attribute, although not part of the DN, have a valid RFC822 identifier 783 for the user. The LDAP DIT structure will follow the typical 784 X.500/NADF approach as follows. 786 Organizations wishing to pursue this approach will need to register 787 their organization's name with the appropriate authority as generally 788 accepted in the X.500/NADF community. This means that US organizations 789 will register with ANSI. The resort to the civil naming 790 infrastructure of states and counties should be actively 791 discouraged. There may be cases where this sort of name construction 792 can make sense, so no absolute prohibition is made here. The names 793 constructed from this civil naming infrastructure (a la NADF), while 794 meeting the technical criteria for non-ambiguity and right to use, are 795 typically long and unwieldy. 797 Suppose the US company "XYZ Widgets" expressed a wish to follow this 798 approach. A typical user name might be 800 uid=J.User@xyzwidgets.com, o="XYZ Widgets, Inc.", c=US 802 where o="XYZ Widgets, Inc.", c=US is an ANSI registered name. (The 803 "alphanumeric string" registered with ANSI is 'XYZ Widgets, Inc.', 804 where the single quotes mark off what is registered but are not part of 805 the registered information.) 807 To support structured access control within the company, the analogous 808 form to the registration of a subdomain in the mainline approach is the 809 creation of an organizational unit node. 811 8.3 Directory Schema Implications of the Naming Plan 813 The traditional directory schema(s) developed for the X.500 standard 814 and its application to the Internet [3] require extension to be used 815 with the naming plan developed here. The extensions described below 816 attempt to reuse existing schema elements as much as possible. The 817 directory objects for which extensions are required are: organization, 818 organizational unit, ca, server (application) and group. 820 So as to continue to use existing structural object classes to the 821 extent possible, we propose supplementing entries based on these 822 classes with additional information from two new auxiliary object 823 classes, dcObject and uidObject. 825 The auxiliary object class dcObject is defined as: 827 name: dcObject 828 requires: dc 830 The auxiliary object class uidObject is defined as: 832 name: uidObject 833 requires: uid 835 In a pure X.500 context, our schema would also require the definition 836 of new name forms and structure rules. These concepts are not 837 required, however, for the specification of LDAP schemas. 839 8.3.1 Organization Schema 841 The dc attribute is employed to construct the RDN of an organization 842 object. This is enabled by adding the auxiliary class dcObject to the 843 organization's objectClass attribute. 845 8.3.2 Organizational Unit Schema 847 The dc attribute is employed to construct the RDN of an 848 organizationalUnit object (which is subordinate in the DIT to either 849 an organization or an organizationalUnit object). This is enabled by 850 adding the auxiliary class dcObject to the organizational unit's 851 objectClass attribute. 853 8.3.3 Person Schema 855 No schema extensions are required for person objects if either the 856 inetOrgPerson (preferred) or the newPilotPerson object classes are 857 used. The attribute uid is permissible in each class. For consistency, 858 the uidObject could be added to person entry objectClass attributes 859 to assist applications filtering on this attribute. 861 8.3.4 Certification Authority Schema 863 The certification authority (CA) object class is an auxiliary class, 864 meaning it is essentially a set of additional attributes for a base 865 class such as organizationalRole, organization, organizationalUnit or 866 person. Except in the case where the base structural class is 867 inetOrgPerson, use of the uid attribute to construct the RDN of a CA 868 will require the auxiliary class uidObject to permit the uid attribute 869 to be used. In the cases where organizationalUnit or organization is 870 the base class for a CA, use of the auxiliary class dcObject will 871 permit the RDN of the CA to be a domain component. 873 8.3.5 Server Application Schema 875 Server applications are typically represented by entries of the object 876 class applicationProcess (or a class derived from it). Sometimes the 877 class applicationEntity is used. In either case, the uid attribute 878 may be employed to construct the RDN of a server application object. 879 This is enabled by adding the auxiliary class uidObject to the server 880 application's objectClass attribute. 882 8.3.6 Group of Names Schema 884 The uid attribute may be employed to construct the RDN of a groupOfNames 885 object. This is enabled by adding the auxiliary class uidObject to the 886 groupOfNames' objectClass attribute. 888 9.0 SECURITY CONSIDERATIONS 890 Security considerations are not part of this paper. 892 10.0 ACKNOWLEDGMENTS 894 This plan has emerged in the course of a number of fruitful 895 discussions, especially with David Chadwick, John Dale, Joe Gajewski, 896 Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu. 898 11.0 REFERENCES 900 [1] X.500: The Directory -- Overview of Concepts, Models, and 901 Service, CCITT Recommendation X.500, December, 1988. 903 [2] P.Barker, and S. Kille, "The COSINE and Internet X.500 Schema", 904 RFC1274, 11/27/1991. 906 [3] The North American Directory Forum, "A Naming Scheme for c=US", 907 RFC1255, September 1991. 909 [4] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory Access 910 Protocol", RFC1777, 03/28/1995. (Work is also underway in the 911 IETF to produce an extended version of LDAP.) 913 [5] J. Postel, and C. Anderson, "White Pages Meeting Report", 914 RFC1588, February 1994. 916 [6] P. Mockapetris, "Domain names - concepts and facilities", 917 RFC1034. 919 [7] D. Crocker, "Standard for the format of ARPA Internet text 920 messages", RFC822. 922 [8] S. Kille, "A String Representation of Distinguished Names", 923 RFC1779, 03/28/1995. 925 [9] A. Freier, P. Karlton, and P. Kocher, "The SSL Protocol Version 926 3.0", Work in Progress, Internet Draft 927 , March 1996. 929 [10] S. Kille, "X.500 and Domains", RFC1279, 11/27/1991. 931 [11] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 932 Protocol (v3)", Work in Progress, Internet Draft 933 , February 17, 1997. 935 [12] The North American Directory Forum, "NADF Standing Documents: A 936 Brief Overview", RFC 1417, The North American Directory Forum", 937 NADF, February 1993. 939 12. Authors' Addresses 941 Al Grimstad 942 AT&T 943 Room 1C-429, 101 Crawfords Corner Road 944 Holmdel, NJ 07733-3030 945 USA 947 EMail: alg@att.com 949 Rick Huber 950 AT&T 951 Room 1B-433, 101 Crawfords Corner Road 952 Holmdel, NJ 07733-3030 953 USA 955 EMail: rvh@att.com 957 Sri Sataluri 958 AT&T 959 Room 4G-202, 101 Crawfords Corner Road 960 Holmdel, NJ 07733-3030 961 USA 963 EMail: sri@att.com 965 Steve Kille 966 Isode Limited 967 The Dome, The Square 968 Richmond 969 TW9 1DT 970 UK 972 Phone: +44-181-332-9091 973 EMail: S.Kille@isode.com 975 Mark Wahl 976 Critical Angle Inc. 977 4815 W Braker Lane #502-385 978 Austin, TX 78759 979 USA 981 EMail: M.Wahl@critical-angle.com