home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / ldapsdk.zip / doc / rfc / rfc2377.txt < prev    next >
Text File  |  1998-10-28  |  38KB  |  1,012 lines
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  1012.