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