idnits 2.17.1 draft-hodges-ldap-dir-dn-reqs-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-03-28) 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. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: R1.0. Distinguished Names (DNs) of entries in a given "local directory service context" MUST be able to perform as unique primary keys. This is essentially "by definition" of a DN. Local-context DNs MAY OR MAY NOT be unique across other autonomous directory servers or other LLDSs. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LDAP' is mentioned on line 110, but not defined == Missing Reference: 'DNS' is mentioned on line 158, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Dirnaming' ** Obsolete normative reference: RFC 1959 (ref. 'LDAPurls') (Obsoleted by RFC 2255) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jeff Hodges, Stanford University 3 INTERNET-DRAFT October, 1997 4 Category: Standards Track 6 Requirements for Distinguished Names in Autonomous to 7 Loosely-coupled LDAP-based Directory Services 8 10 Status of this Document 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 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 material 20 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 ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 This document expires in April 1998. 29 Abstract 31 This document analyzes the issues involved in the Distinguished Name- 32 spaces of autonomous to loosely-coupled, LDAP-based directory services 33 (LLDSs). It folds in experience learned from the global X.500-based Dis- 34 tinguished Name-space, and proposes requirements for the construction of 35 Distinguished Names for LLDSs of varying scopes. 37 1. Introduction 39 LDAP-based directory services provide a "named entry with attributes" 40 model -- an entry's attributes may be retrieved by looking up its name 41 in the directory. In order to provide a directory service in which por- 42 tions of the namespace are contributed by relatively autonomous servers, 43 there must be agreements on how the namespace's topology, properties, 44 and allocation work. 46 This document provides general background on naming in LDAP-based direc- 47 tory services, analyzes the specific case of loosely-coupled, LDAP-based 48 directory services (LLDSs), examines experience gleaned from the X.500- 49 based global directory, postulates some future applications for LLDSs, 50 and then proposes requirements for such a directory service's Dis- 51 tinguished Name-space. 53 Note that this document does not address requirements for an LLDS Dis- 54 tinguished Name-space in the context of their utilization as part of 55 LDAP URLs [LDAPurls] or LDAP Uniform Resource Names (URNs). See the fol- 56 lowing section for details. 58 This is a requirements definition document. It does not define a partic- 59 ular solution or its implementation. These topics will either be 60 addressed in other Internet-Drafts or this document will be merged with 61 ones addressing them. 63 1.1. What this Document Doesn't Address 65 This document does not address the specific cases of.. 67 1. The details of entry Relative Distinguished Name (RDN) construction 68 and "entry naming" in general. They both are ostensibly pieces of 69 overall "entry naming schemes". Such schemes may address not only how 70 RDNs are selected, but also issues such as how to accomodate 71 representing "names" of entries utilizing non-distinguished attri- 72 butes. Entry naming schemes are thus decidedly site-specific and 73 potentially complex in their own right. 75 2. How, given the DN of an entry and/or some attribute value from the 76 entry, e.g. the value of the "mail" attribute, one would go about 77 locating a specific directory service or server hosting the entry. 79 3. How DNs and thus entries in an autonomous or loosely-coupled direc- 80 tory service are mapped to so-called "real world objects". This is 81 entirely site- and entry-specific. 83 4. Distinguished Name-space requirements in the context of LDAP URLs 84 or URNs. The requirements proposed in this document are based on the 85 assumption of Distinguished Names being utilized on their own, not 86 specifically as part of LDAP URLs or other amalgamations such as URNs. 87 LDAP URLs/URNs may be considered and utilized, in some contexts, as 88 "meta-Distinguished Names" which would explicitly contain more 89 specific directory service context than Distinguished Names can on 90 their own. Determining requirements for such utilization of Dis- 91 tinguished Names is outside the (current) scope of this document. 93 All of the above concepts are outside of the (current) scope of this 94 document. They may be addressed in other Internet-Drafts, or the scope 95 of this document may be widened to include them. 97 2. Document Conventions 99 The key words "MUST", "SHOULD", and "MAY" used in this document are to 100 be interpreted as described in [ReqsKeywords]. 102 3. Background: Concepts of Naming in an LDAP-based Directory Service 104 Directory services provide a lookup capability -- knowing something 105 about an object, such as one of its names, one may lookup additional 106 information about it in the directory. Thus a name in the directory ser- 107 vices context is analogous to the concept of "keys" in the relational 108 database management systems (RDBMS) context. 110 X.500 [X.500], and thus LDAP [LDAP], employ a hierarchical namespace. 111 This namespace is analogous to the "keyspace" a specific RDBMS-based 112 database may have. An entry may have a name that relates only unto 113 itself, with the only requirement being that the name is unique at that 114 level of that particular branch of the hierarchy -- i.e. among its 115 siblings. However, one must be able to locate the name at its position 116 in the hierarchy before the name is meaningful in a context beyond that 117 of the entry itself. 119 Thus in X.500 and LDAP, names have the concepts of being "relative" or 120 "distinguished". A relative name is the entry's name unto itself, and 121 isn't required to have any relation to other entries at that point in 122 the hierarchy. There is a fully-qualified form of an entry's name, 123 called the Distinguished Name (DN). DNs are quite similar to fully- 124 qualified Internet domain names [DNS] in that their components trace the 125 path from the root of the namespace hierarchy down to the entry. The 126 entry's relative name is simply a component of the entry's Distinguished 127 Name, much the same way that an Internet host's name is just a component 128 of the host's fully-qualified domain name. An entry's relative name is 129 known as its Relative Distinguished Name (RDN). 131 Given that RDNs must be unique at each level in the hierarchy (i.e. 132 among their siblings), then each DN derived from that naming hierarchy 133 will be unique, relative to that hierarchy. 135 One uses different forms of an entry's name to look it up, depending 136 upon one's context relative to the naming hierarchy. If one's context is 137 the same as that of the entry, one may refer to it using only its RDN. 138 If one's context is different, e.g. perhaps being outside the directory 139 context and "looking in", then one (essentially) uses the entry's DN 140 (which is fully-qualified by definition). 142 4. The Specific Problem Space: Loosely-coupled, LDAP-based Directory 143 Services 145 Loosely-coupled, LDAP-based directory services (LLDS) are being postu- 146 lated by various working groups within the IETF. Specifically, such 147 directory services will be made up of coalitions of cooperating, but 148 essentially autonomous, site-specific directory services belonging to 149 distinct and independent administrative domains. One of the primary pur- 150 poses of such directory services will be to provide for lookup of, and 151 searching for, entries across administrative domains. This, in essence, 152 calls for a unified "distinguished name"-space in an LLDS's context, 153 which we'll term in this document a "LLDS distinguished name-space". 155 The autonomous directory services making up an LLDS will be contributing 156 to portions of the LLDS distinguished name-space in much the same way 157 that various administrative domains' DNS services contribute portions of 158 the DNS namespace [DNS]. Given the characteristics of naming in LDAP- 159 based directory services described above, the DNs contributed to a LLDS 160 by the cooperating participants must be at least distinctly unambiguous, 161 if not distinctly unique. This is similar to how Domain Names contri- 162 buted to the DNS namespace must be unambiguous, i.e. they and their 163 associated entry may be hosted on more than one server, if not dis- 164 tinctly unique. 166 5. Prior Work: The X.500 Directory 168 The X.500 standard proposes a global directory naming scheme in 169 [X.500Naming]. In this scheme, the DN hierarchy, known as the Directory 170 Information Tree (DIT), is based upon combinations of the names of geo- 171 political (e.g. countries, states, provinces, etc.) and organizational 172 (e.g. companies, governments, universities, etc.) entities. 174 In practice, this has proved quite unwieldy, though not entirely unwork- 175 able, in many geopolitical and organizational contexts because conflicts 176 abound when trying to allocate globally distinct and unique DNs directly 177 from the patchwork quilt of real-world namespaces -- specifically, there 178 is ~noone~ with the authority to consistently mediate them all. This 179 situation can be summarized as.. 181 There is no overarching, international naming authority for 182 geopolitical and organizational entities in the global, 183 real-world context. 185 [Amen. -- ed.] 187 6. The Future: Applications of LLDSs 189 There are many potential applications for LLDSs. A broad-based, 190 Internet-wide whitepages listing for people is arguably the most com- 191 monly promoted one. Other high-leverage, emerging applications will be 192 in the context of Internet-based electronic commerce and security 193 infrastructures. In this context, DNs, and/or URLs based on the DNs 194 [LDAPurls], will likely be cached for later use, where "later" might be 195 on a scale of (potentially many) years. 197 Also, products are already emerging, e.g. Netscape Communicator, which 198 directly utilize and cache LDAP URLs and DNs. Certainly, more are likely 199 to follow, and broad-based usage of such tools to increase. 201 7. Definitions of Directory Service Contexts 203 7.1. Local Directory Service Context 205 A "local directory service context" may range from a single autonomous 206 directory server to a set of loosely-coupled directory servers, i.e. an 207 LLDS. 209 7.2. General LLDS Context 211 A "general LLDS context" may range from a small set of LLDSs to a set of 212 arbitrary size. 214 8. Requirements for LLDS Distinguished Name-spaces 216 Given LDAP's distinguished name-space model, the movement towards creat- 217 ing LLDSs, the lessons from X.500, and envisioned applications for 218 LLDSs, these are requirements for distinguished names in the context of 219 loosely-coupled, LDAP-based directory services... 221 8.1. The Primary Requirements 223 R1.0. Distinguished Names (DNs) of entries in a given "local directory 224 service context" MUST be able to perform as unique primary keys. This 225 is essentially "by definition" of a DN. Local-context DNs MAY OR MAY 226 NOT be unique across other autonomous directory servers or other 227 LLDSs. 229 R1.1. Distinguished Names (DNs) of entries in a given "general LLDS 230 context" MAY be able to perform as unique primary keys. If a given DN 231 is not unique, then a non-null set of entries within the general LLDS 232 context will have that same DN. However, this DN SHOULD be unambiguous 233 within the general LLDS context -- i.e. distinct entries in a general 234 LLDS context MAY have the same DN IF there is an explicitly esta- 235 blished relationship among them, otherwise distinct entries SHOULD 236 have DNs which are unique within the general LLDS context. 238 8.2. Overall Derived Requirements for DNs in a General LLDS Context 240 R2. DNs contributed to a general LLDS distinguished name-space by oth- 241 erwise autonomous directory service instances MUST satisfy R1.1. 243 R3. DNs in a local directory context, which MAY potentially become a 244 part of a general LLDS context, SHOULD utilize DNs that satisfy R1.1. 246 R4. DNs in a local directory context, which may or may not become a 247 part of a general LLDS context, MAY utilize DNs that satisfy R1.1. 249 R5. A general LLDS context's distinguished name-space hierarchy, from 250 which DNs are allocated (and modulo the specific requirements for RDNs 251 below), SHOULD be based on some pre-existing heirarchical naming 252 infrastructure having these specific properties... 254 R5.1. It is available across the administrative domains participat- 255 ing in the general LLDS context. 257 R5.2. It is well-understood, and has a low-cost registration process 258 (in both monetary and effort terms). 260 R5.3. It is widely subscribed-to. 262 R5.4. It is actively and effectively managed and has clearly defined 263 procedures that are published across participating administrative 264 domains. 266 R5.5. It provides names that are guaranteed-unique across the parti- 267 cipating administrative domains. 269 R5.6. It provides names that change relatively infrequently, by some 270 established, well-documented procedure, or not at all. 272 8.3. Requirements for Entry RDNs 274 R6. Entry RDNs MUST be unique among their siblings (this is by defini- 275 tion, but worth reiterating). 277 R7. Entry RDNs SHOULD be immutable. 279 R8. Entry RDNs MAY be based on any attribute type, subject to the 280 entry's object class restrictions, and the attribute's value SHOULD be 281 sourced from a documented, site-specific scheme that provides well- 282 managed, guaranteed-unique names. 284 R9. Entry RDNs MAY be constructed using only one attribute type and 285 value pair, or MAY be constructed of an amalgamation of attributes. If 286 the latter option is used, the involved attributes and their values 287 SHOULD satisfy R8. 289 9. Summary 291 This document has presented LDAP-based directory service naming con- 292 cepts, analyzed naming issues involved in loosely-coupled LDAP-based 293 directory services, and briefly summarized prior X.500-based experience 294 with naming. 296 The presented LLDS Distinguished Name-space requirements seek to satisfy 297 the issues involved in LLDS naming as well as ameliorate the naming 298 issues experienced with the global X.500-based directory. 300 The intent is that in using these requirements as guidelines, we can 301 reasonably and manageably design and construct Distinguished Name-spaces 302 for LLDSs of arbitary and evolving scope. 304 10. Security Considerations 306 This document expresses requirements for Distinguished Names in contexts 307 ranging from an autonomous directory server to a loosely-coupled direc- 308 tory service of potentially Internet-wide scope. Other documents which 309 specify designs for systems and/or protocols seeking to satisfy these 310 requirements should consider security implications from at least this 311 perspective.. 313 DNs and/or URLs based upon them are publicly consummable and cache- 314 able. Each one will conceivably expose some of a LLDS's structure. 315 What are the implications for the security and authorization facili- 316 ties of the individual directory services participating in the LLDS, 317 and the various client systems based upon the LLDS? 319 11. Acknowledgements 321 Many of the concepts in this document are drawn from [Dirnaming]. Al 322 Grimstad, Chris Apple, and Chris Weider contributed valuable comments 323 and perspectives to this document. 325 12. References 327 [Dirnaming] 328 Naming Plan for Internet Directory-Enabled Applications. A. Grim- 329 stad, R. Huber, S. Sataluri, S. Kille, M. Wahl. Internet-Draft, 330 work-in-progress. August 1997. Available as: 333 [DNS]Domain Name System Structure and Delegation. J. Postel. RFC 1951. 334 March 1994. 336 [LDAP]Lightweight Directory Access Protocol. W. Yeong, T. Howes & S. 337 Kille. RFC 1777, Draft Standard. March 1995. 339 [LDAPurls] 340 An LDAP URL Format. T. Howes & M. Smith. RFC 1959. June 1996. 342 [ReqsKeywords] 343 Scott Bradner, "Key Words for use in RFCs to Indicate Requirement 344 Levels", RFC 2119. 346 [X.500] 347 The Directory: Overview of Concepts, Models and Service. CCITT 348 Recommendation X.500, 1993. 350 [X.500Naming] 351 Annex B to CCITT Recommendation X.521, 1993. 353 13. Author's Address 355 Jeff Hodges 356 Computing & Communication Services 357 Stanford University 358 Pine Hall 359 241 Panama Street 360 Stanford, CA 94305-4122 361 USA 363 Phone: +1-650-723-2452 364 EMail: Jeff.Hodges@Stanford.edu 365 URL: http://www.stanford.edu/~hodges/