home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ids-dirnaming-02.txt < prev    next >
Text File  |  1997-09-11  |  34KB  |  898 lines
  1.  
  2.  
  3. IDS Working Group                                            Al Grimstad
  4. INTERNET-DRAFT                                                Rick Huber
  5.                                                             Sri Sataluri
  6.                                                                     AT&T
  7.                                                              Steve Kille
  8.                                                               Isode Ltd.
  9.                                                                Mark Wahl
  10.                                                      Critical Angle Inc.
  11.  
  12.                                                          August 28, 1997
  13.  
  14.         Naming Plan for Internet Directory-Enabled Applications
  15.                Filename: draft-ietf-ids-dirnaming-02.txt
  16.  
  17. Status of this Memo
  18.  
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet- Drafts as reference
  28.    material or to cite them other than as ``work in progress.''
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  32.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36.    Distribution of this document is unlimited.  Editorial comments
  37.    should be sent directly to the authors.  Technical discussion will
  38.    take place on the IETF Integrated Directory Services mailing list,
  39.    ietf-ids@umich.edu.
  40.  
  41. Abstract
  42.  
  43.    Application of the conventional X.500 approach to naming has
  44.    heretofore, in the experience of the authors, proven to be an
  45.    obstacle to the wide deployment of directory-enabled applications on
  46.    the Internet.  We propose a new directory naming plan that leverages
  47.    the strengths of the most popular and successful Internet naming
  48.    schemes for naming objects in a hierarchical directory.  This plan
  49.    can, we believe, facilitate the creation of an Internet White Pages
  50.    Service (IWPS) and other directory-enabled applications by overcoming
  51.  
  52.  
  53.  
  54. Grimstad, et al.                                                [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60. INTERNET-DRAFT                Naming Plan                    August 1997
  61.  
  62.  
  63.    the problems encountered by those using the conventional X.500
  64.    approach to naming.
  65.  
  66. 1.0 Executive Summary
  67.  
  68.    Application of the conventional X.500 approach to naming has
  69.    heretofore, in the experience of the authors, proven to be an
  70.    obstacle to the wide deployment of directory-enabled applications on
  71.    the Internet.  The required registration infrastructure is either
  72.    non-existent or largely ignored.  The infrastructure that does exist
  73.    is cumbersome to use and tends to produce counterproductive results.
  74.    The attributes used for naming have been confusing for users and
  75.    inflexible to managers and operators of directory servers.
  76.  
  77.    This paper describes an alternative directory naming plan for the
  78.    construction of an Internet directory infrastructure to support
  79.    directory-enabled applications.
  80.  
  81.    The plan has the following two main features.  First, it bases the
  82.    root and upper portions of the name hierarchy on the existing
  83.    infrastructure of names from the Domain Name System (DNS). This
  84.    component of the plan makes use of the ideas described in the
  85.    companion paper to this plan, "Using Domains in LDAP Distinguished
  86.    Names" [1].  And second, it provides a number of options for the
  87.    assignment of names to directory leaf objects such as person objects,
  88.    including an option that allows the reuse of existing Internet
  89.    identifiers for people.
  90.  
  91.    Here, in summary, is our proposal.
  92.  
  93.    The upper portions of the hierarchical directory tree should be
  94.    constructed using the components of registered DNS names using the
  95.    domain component attribute "dc".  The directory name for the
  96.    organization having the domain name "acme.com" will then be, e.g.,
  97.  
  98.        dc=acme, dc=com
  99.  
  100.    Organizations can add additional directory structure, for example to
  101.    support implementation of access control lists or partitioning of
  102.    their directory information, by using registered subdomains of DNS
  103.    names, e.g., the subdomain "corporate.acme.com" can be used as the
  104.    basis for the directory name
  105.  
  106.        dc=corporate, dc=acme, dc=com
  107.  
  108.    For naming directory leaf objects such as persons, groups, server
  109.    applications and certification authorities in a hierarchical
  110.    directory, we propose the use of either the "uid" (user identifier)
  111.  
  112.  
  113.  
  114. Grimstad, et al.                                                [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120. INTERNET-DRAFT                Naming Plan                    August 1997
  121.  
  122.  
  123.    or the "cn" (common name) attribute for the relative distinguished
  124.    name. This plan does not constrain how these two attributes are used.
  125.  
  126.    One approach to their use, for example, is to employ the uid
  127.    attribute as the RDN when reusing an existing store of identifiers
  128.    and the cn attribute as the RDN when creating new identifiers
  129.    specifically for the directory.  A convenient existing identification
  130.    scheme for person objects is the RFC822 mailbox identifier. So an RDN
  131.    for person employing this store of identifiers would be, e.g.,
  132.  
  133.        uid=John.Smith@acme.com
  134.  
  135.    For leaf objects not conveniently identified with such a scheme, the
  136.    "cn" attribute is used, e.g.,
  137.  
  138.        cn=Reading Room
  139.  
  140.    Directory distinguished names will thus have the following structure,
  141.    e.g.,
  142.  
  143.        uid=John.Smith@acme.com, dc=acme, dc=com
  144.        uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
  145.        uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
  146.        cn=Reading Room, dc=physics, dc=national-lab, dc=edu
  147.  
  148. 2.0 The Problem
  149.  
  150.    The X.500 Directory model [2] can be used to create a world-wide
  151.    distributed directory. The Internet X.500 Directory Pilot has been
  152.    operational for several years and has grown to a size of about 1.5
  153.    million entries of varying quality.  The rate of growth of the pilot
  154.    is far lower than the rate of growth of the Internet during the pilot
  155.    period.
  156.  
  157.    There are a substantial number of contributing factors that have
  158.    inhibited the growth of this pilot.  The common X.500 approach to
  159.    naming, while not the preponderant problem, has contributed in
  160.    several ways to limit the growth of an Internet White Pages Service
  161.    based on X.500.
  162.  
  163.    The conventional way to construct names in the X.500 community is
  164.    documented as an informative (i.e., not officially standardized)
  165.    Annex B to X.521. The relative distinguished name (RDN) of a user
  166.    consists of a common name (cn) attribute. This is meant to be what --
  167.    in the user's particular society -- is customarily understood to be
  168.    the name of that user. The distinguished name of a user is the
  169.    combination of the name of some general object, such as an
  170.    organization or a geographical unit, with the common name. There are
  171.  
  172.  
  173.  
  174. Grimstad, et al.                                                [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180. INTERNET-DRAFT                Naming Plan                    August 1997
  181.  
  182.  
  183.    two main problems with this style of name construction.
  184.  
  185.    First, the common name attribute, while seeming to be user-friendly,
  186.    cannot be used generally as an RDN in practice.  In any significant
  187.    set of users to be named under the same Directory Information Tree
  188.    (DIT) node there will be collisions on common name.  There is no way
  189.    to overcome this other than either by forcing uniqueness on common
  190.    names, something they do not possess, or by using an additional
  191.    attribute to prevent collisions.  This additional attribute normally
  192.    needs to be unique in a much larger context to have any practical
  193.    value.  The end result is a RDN that is very long and unpopular with
  194.    users.
  195.  
  196.    Second, and more serious, X.500 has not been able to use any
  197.    significant number of pre-existing names.  Since X.500 naming models
  198.    typically use organization names as part of the hierarchy [2, 3],
  199.    organization names must be registered.  As organization names are
  200.    frequently tied to trademarks and are used in sales and promotions,
  201.    registration can be a difficult and acrimonious process.
  202.  
  203.    The North American Directory Forum (NADF, now the North Atlantic
  204.    Directory Forum but still the NADF) proposed to avoid the problem of
  205.    registration by using names that were already registered in the
  206.    "civil naming infrastructure" [4][5].  Directory distinguished names
  207.    would be based on an organization's legal name as recognized by some
  208.    governmental agency (county clerk, state secretary of state, etc.) or
  209.    other registering entity such as ANSI.
  210.  
  211.    This scheme has the significant advantage of keeping directory
  212.    service providers out of disputes about the right to use a particular
  213.    name, but it leads to rather obscure names.  Among these obscurities,
  214.    the legal name almost invariably takes a form that is less familiar
  215.    and longer than what users typically associate with the organization.
  216.    For example, in the US a large proportion of legal organization names
  217.    end with the text ", Inc." as in "Acme, Inc."  Moreover, in the case
  218.    of the US, the civil naming infrastructure does not operate
  219.    nationally, so the organization names it provides must be located
  220.    under state and regional DIT nodes, making them difficult to find
  221.    while browsing the directory.  NADF proposes a way to algorithmically
  222.    derive multi-attribute RDNs which would allow placement of entries or
  223.    aliases in more convenient places in the DIT, but these derived names
  224.    are cumbersome and unpopular.  For example, suppose Nadir is an
  225.    organization that is registered in New Jersey civil naming
  226.    infrastructure under the name "Nadir Networks, Inc."  Its civil
  227.    distinguished name (DN) would then be
  228.  
  229.        o="Nadir Networks, Inc.", st=New Jersey, c=US
  230.  
  231.  
  232.  
  233.  
  234. Grimstad, et al.                                                [Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240. INTERNET-DRAFT                Naming Plan                    August 1997
  241.  
  242.  
  243.    while its derived name which is unambiguous under c=US directly is
  244.  
  245.        o="Nadir Networks, Inc." + st=New Jersey, c=US
  246.  
  247.    More generally, the requirement for registration of organizations in
  248.    X.500 naming has led to the establishment of national registration
  249.    authorities whose function is mainly limited to assignment of X.500
  250.    organization names.  Because of the very limited attraction of X.500,
  251.    interest in registering an organization with one of these national
  252.    authorities has been minimal.  Finally, multi-national organizations
  253.    are frustrated by a lack of an international registration authority.
  254.  
  255. 3.0 Requirements
  256.  
  257.    A directory naming plan must provide for names of directory objects
  258.    that are unambiguous (identify only one object) within some context,
  259.    at a minimum within one isolated directory server.
  260.  
  261.    The following additional naming characteristics are requirements that
  262.    this naming plan seeks to satisfy:
  263.  
  264.    a) hierarchical
  265.  
  266.    The Internet, consisting of a very large number of objects and
  267.    management domains, requires hierarchical names.  Such names permit
  268.    delegation in the name assignment process and partitioning of
  269.    directory information among directory servers.
  270.  
  271.    b) friendly to loose coupling of directory servers
  272.  
  273.    One purpose of this naming plan is to define a naming pattern that
  274.    will facilitate one form or another of loose coupling of potentially
  275.    autonomous directory servers into a larger system.  A name in such a
  276.    system should unambiguously identify one real-world object.  The
  277.    object may, however, be represented differently (i.e. have different
  278.    attributes) in different (e.g. independently managed) servers in the
  279.    system.  The plan does not attempt to produce names to overcome this
  280.    likely scenario.
  281.  
  282.    c) readily usable by LDAP clients and servers
  283.  
  284.    As of this writing, a substantial number of the Lightweight Directory
  285.    Access Protocol (LDAP) [6][7] implementations are currently available
  286.    or soon will be.  The names specified by this naming plan should be
  287.    readily usable by these implementations and applications based on
  288.    them.
  289.  
  290.    d) friendly to re-use of existing Internet name registries
  291.  
  292.  
  293.  
  294. Grimstad, et al.                                                [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. INTERNET-DRAFT                Naming Plan                    August 1997
  301.  
  302.  
  303.    As described in Section 2 above, creation of new global name
  304.    registries has been highly problematic.  Therefore, a fundamental
  305.    requirement this plan addresses is to enable the reuse of existing
  306.    Internet name registries such as DNS names and RFC822 mailbox
  307.    identifiers when constructing directory names.
  308.  
  309.    e) minimally user-friendly
  310.  
  311.    Although we expect that user interfaces of directory-enabled
  312.    applications will avoid exposing users to DNs, it is unlikely that
  313.    users can be totally insulated from them.  For this reason, the
  314.    naming plan should permit use of familiar information in name
  315.    construction.  Minimally, a user should be capable of recognizing the
  316.    information encoded in his/her own DN.  Names that are totally opaque
  317.    to users cannot meet this requirement.
  318.  
  319. 4.0 Name Construction
  320.  
  321.    The paper assumes familiarity with the terminology and concepts
  322.    behind the terms distinguished name (DN) and relative distinguished
  323.    name (RDN) [2][8][9].
  324.  
  325.    We describe how DNs can be constructed using three attribute types,
  326.    domainComponent (dc), userID (uid) and commonName (cn).  They are
  327.    each described in turn.
  328.  
  329. 4.1 Domain Component (dc)
  330.  
  331.    The domain component attribute is defined and registered in RFC1274
  332.    [3][10].  It is used in the construction of a DN from a domain name.
  333.    Details of the construction algorithm is described in "Using Domains
  334.    in LDAP Distinguished Names" [1].
  335.  
  336.    An organization wishing to deploy a directory following this naming
  337.    plan would proceed as follows.  Consider an organization, for example
  338.    "Acme, Inc.", having the registered domain name "acme.com".  It would
  339.    construct the DN
  340.  
  341.        dc=acme, dc=com
  342.  
  343.    from its domain name.  It would then use this DN as the root of its
  344.    subtree of directory information.
  345.  
  346.    The DN itself can be used to identify a directory organization object
  347.    that represents information about the organization. The directory
  348.    schema required to enable this is described below in section 5.2.
  349.  
  350.    The subordinates of the DN will be directory objects related to the
  351.  
  352.  
  353.  
  354. Grimstad, et al.                                                [Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360. INTERNET-DRAFT                Naming Plan                    August 1997
  361.  
  362.  
  363.    organization.  The domain component attribute can be used to name
  364.    subdivisions of the organization such as organizational units and
  365.    localities.  Acme, for example, might use the domain names
  366.    "corporate.acme.com" and "engineering.acme.com" to construct the
  367.    names
  368.  
  369.        dc=corporate, dc=acme, dc=com
  370.        dc=engineering, dc=acme, dc=com
  371.  
  372.    under which to place its directory objects.  The directory schema
  373.    required to name organizationalUnit and locality objects in this way
  374.    is described below in section 5.2.
  375.  
  376.    Use of this attribute for the RDN of directory objects of class
  377.    "domain" is also possible [1].
  378.  
  379. 4.2 User ID (uid)
  380.  
  381.    The userid (uid) attribute is defined and registered in RFC1274
  382.    [3][10].
  383.  
  384.    This attribute may be used to construct the RDN for directory objects
  385.    subordinate to objects named according to the procedure described in
  386.    Section 4.1.  This plan does not constrain how this attribute is
  387.    used.
  388.  
  389. 4.3 Common Name (cn)
  390.  
  391.    The commonName (cn) attribute is defined and registered in X.500
  392.    [3][11].
  393.  
  394.    This attribute may be used to construct the RDN for directory objects
  395.    subordinate to objects named according to the procedure described in
  396.    Section 4.1.  This plan does not constrain how this attribute is
  397.    used.
  398.  
  399. 4.4 Examples of uid and cn Usage
  400.  
  401.    Although this plan places no constraints on the use of the uid and cn
  402.    attributes for name construction, we would like to offer some
  403.    suggestions by way of examples.
  404.  
  405.    In practice, we have used uid for the RDN for person objects were we
  406.    could make use of an existing registry of names and cn for other
  407.    objects.
  408.  
  409.    Examples of existing registries of identifiers for person objects are
  410.    RFC822 mailbox identifiers, employee numbers and employee "handles".
  411.  
  412.  
  413.  
  414. Grimstad, et al.                                                [Page 7]
  415.  
  416.  
  417.  
  418.  
  419.  
  420. INTERNET-DRAFT                Naming Plan                    August 1997
  421.  
  422.  
  423.    Aside from the convenience to administrators of re-use of an existing
  424.    store of identifiers, if it is ever necessary to display to a user
  425.    his/her DN, there is some hope that it will be recognizable when such
  426.    identifiers are used.
  427.  
  428.    We have found RFC822 mailbox identifiers a particularly convenient
  429.    source for name construction.  When a person has several e-mail
  430.    addresses, one will be selected for the purpose of user
  431.    identification.  We call this the "distinguished" e-mail address or
  432.    the "distinguished" RFC822 mailbox identifier for the user.
  433.  
  434.    For example, if there is a user affiliated with the organization Acme
  435.    having distinguished e-mail address J.Smith@acme.com, the uid
  436.    attribute will be:
  437.  
  438.        uid=J.Smith@acme.com
  439.  
  440.    The domain component attributes of a user's DN will normally be
  441.    constructed from the domain name of his/her distinguished e-mail
  442.    address.  That is, for the user uid=J.Smith@acme.com the domain
  443.    component attributes would typically be:
  444.  
  445.        dc=acme, dc=com
  446.  
  447.    The full LDAP DN for this user would then be:
  448.  
  449.        uid=J.Smith@acme.com, dc=acme, dc=com
  450.  
  451.    Directory administrators having several RFC822 identifiers to choose
  452.    from when constructing a DN for a user should consider the following
  453.    factors:
  454.  
  455.        o Machine-independent addresses are likely to be more stable,
  456.          resulting in directory names that change less. Thus an
  457.    identifier
  458.          such as:
  459.  
  460.              js@acme.com
  461.  
  462.          may well be preferable to one such as:
  463.  
  464.             js@blaster.third-floor.acme.com.
  465.  
  466.        o Use of some form of "handle" for the "local" part that is
  467.          distinct from a user's real name may result in fewer collisions
  468.          and thereby lessen user pain and suffering.  Thus the
  469.          identifier:
  470.  
  471.  
  472.  
  473.  
  474. Grimstad, et al.                                                [Page 8]
  475.  
  476.  
  477.  
  478.  
  479.  
  480. INTERNET-DRAFT                Naming Plan                    August 1997
  481.  
  482.  
  483.              js@acme.com
  484.  
  485.          may well be preferable to one such as:
  486.  
  487.              J.Smith@acme.com
  488.  
  489.    Practical experience with use of the RFC822 mailbox identifier scheme
  490.    described here has shown that there are situations where it is
  491.    convenient to use such identifies for all users in a particular
  492.    population, although a few users do not, in fact, possess working
  493.    mailboxes.  For example, an organization may have a existing unique
  494.    identification scheme for all employees that is used as a alias to
  495.    the employees' real mailboxes -- which may be quite heterogeneous in
  496.    structure.  The identification scheme works for all employees to
  497.    identify unambiguously each employee; it only works as an e-mail
  498.    alias for those employees having real mailboxes.  For this reason it
  499.    would be a bad assumption for directory-enabled applications to
  500.    assume the uid to be a valid mailbox; the value(s) of the mail
  501.    attribute should always be checked.
  502.  
  503.    It is important to emphasize that the elements of the domain name of
  504.    an RFC822 identifier may, BUT NEED NOT, be the same as the domain
  505.    components of the DN.  This means that the domain components provide
  506.    a degree of freedom to support access control or other directory
  507.    structuring requirements that need not be mechanically reflected in
  508.    the user's e-mail address.  We do not want under any condition to
  509.    force the user's e-mail address to change just to facilitate a new
  510.    system requirement such as a modification in an access control
  511.    structure.  It should also be noted that while we do not require that
  512.    the domain components match the RFC822 identifier, we DO require that
  513.    the concatenated domain components form a registered domain name,
  514.    that is, one that is represented in the DNS. This automatically
  515.    avoids name conflicts in the directory hierarchy.
  516.  
  517.    To provide an example of a DN which deviates from what might be
  518.    considered the default structure, consider the following scenario.
  519.  
  520.    Suppose that J.Smith needs to be granted special permissions to
  521.    information in the dc=acme, dc=com part of the LDAP DIT.  Since it
  522.    will be, in general, easier to organize special users by their name
  523.    structure than via groups (an arbitrary collection of DNs), we use
  524.    subdomains for this purpose.  Suppose the special permissions were
  525.    required by users in the MIS organizational unit.  A subdomain
  526.    "mis.acme.com" is established, if it does not already exist,
  527.    according to normal DNS procedures.  The special permissions will be
  528.    granted to users with the name structure:
  529.  
  530.        uid=*, dc=mis, dc=acme, dc=com
  531.  
  532.  
  533.  
  534. Grimstad, et al.                                                [Page 9]
  535.  
  536.  
  537.  
  538.  
  539.  
  540. INTERNET-DRAFT                Naming Plan                    August 1997
  541.  
  542.  
  543.    The DN of J.Smith in this case will be:
  544.  
  545.        uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
  546.  
  547.    In principal, there is nothing to prevent the domain name elements of
  548.    the RFC822 identifier from being completely different from the domain
  549.    components of the DN.  For instance, the DN for a J.Smith could be:
  550.  
  551.        uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
  552.  
  553.    While we do not REQUIRE that the domain name part of the uid match
  554.    the dc components of the directory distinguished name, we suggest
  555.    that this be done where possible. At a minimum, if the most
  556.    significant pieces of the DN and the uid are the same (i.e.,
  557.    "dc=acme, dc=com" and "acme.com") the likelihood, based on a
  558.    knowledge of a user's e-mail address, of discovering an appropriate
  559.    directory system to contact to find information about the user is
  560.    greatly enhanced.
  561.  
  562.    The example above represents a situation where this suggestion isn't
  563.    possible because some of the users in a population have mailbox
  564.    identifiers that differ from the pattern of the rest of the users,
  565.    e.g., most mailboxes are of the form local@acme.com, but a
  566.    subpopulation have mailboxes from an ISP and therefore mailboxes of
  567.    the form local@worldnet.att.net.
  568.  
  569. 5.0 Implementation Issues
  570.  
  571. 5.1 Directory Services Considerations
  572.  
  573.    We envision the deployment of LDAP-based directory services on the
  574.    Internet to take the form of LDAP servers loosely connected into
  575.    islands by means of LDAP referral [12] information configured into
  576.    the servers.  By generalizing this concept one can imagine building a
  577.    simple referral server that knows about the LDAP islands of the
  578.    Internet.  It would compare the naming or search information in a
  579.    query it receives with its knowledge of LDAP islands and return a
  580.    referral to the appropriate island.
  581.  
  582.    We do not envision the X.500 model of a single DIT to viable in an
  583.    environment of competing service providers.  This naming plan does
  584.    not attempt to produce names to hide the possibility that a given DN
  585.    may have independently managed entries associated with it. Referral
  586.    servers such as those envisioned in the previous paragraph can help
  587.    to deal with this situation: a) first, because referrals are
  588.    expressed as LDAP URLs [13] which can identify both a host server and
  589.    a DN; and b) second, because referrals can be multi-valued.  Future
  590.    LDAP v3 clients can be expected to support such referrals.
  591.  
  592.  
  593.  
  594. Grimstad, et al.                                               [Page 10]
  595.  
  596.  
  597.  
  598.  
  599.  
  600. INTERNET-DRAFT                Naming Plan                    August 1997
  601.  
  602.  
  603. 5.2 Directory Schema Implications of the Naming Plan
  604.  
  605.    The traditional directory schema(s) developed for the X.500 standard
  606.    and its application to the Internet [4] require extension to be used
  607.    with the naming plan developed here. The extensions described below
  608.    attempt to reuse existing schema elements as much as possible. The
  609.    directory objects for which extensions are required are:
  610.    organization, organizational unit, and various classes of leaf
  611.    objects. We describe the schema modifications below for organization,
  612.    organizationalUnit and selected leaf classes.
  613.  
  614.    So as to continue to use existing structural object classes to the
  615.    extent possible, we propose supplementing entries based on these
  616.    classes with additional information from two new auxiliary object
  617.    classes, dcObject and uidObject. They are specified using the
  618.    notation in Section 4 of [14].
  619.  
  620.    The auxiliary object class dcObject is defined in "Using Domains in
  621.    LDAP Distinguished Names" [1].
  622.  
  623.    The auxiliary object class uidObject is defined as:
  624.  
  625.    ( OID-TBD NAME 'uidObject' SUP top AUXILIARY MUST uid )
  626.  
  627.    In a pure X.500 context, our schema would also require the definition
  628.    of new name forms and structure rules. These concepts are not
  629.    required, however, for the specification of LDAP schemas.
  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.  
  652.  
  653.  
  654. Grimstad, et al.                                               [Page 11]
  655.  
  656.  
  657.  
  658.  
  659.  
  660. INTERNET-DRAFT                Naming Plan                    August 1997
  661.  
  662.  
  663.    attributes to assist applications filtering on this attribute. Use of
  664.    other classes for person objects with RDN constructed with the uid
  665.    attribute such as organizationalPerson requires the use of the
  666.    uidObject class.
  667.  
  668.    It has been traditional in X.500 and LDAP directory services to
  669.    employ the common name (cn) attribute in naming.  While this naming
  670.    plan doesn't require use of the cn attribute in naming, it should be
  671.    stressed that it is a required attribute in any class derived from
  672.    the person class and is still quite important.  It will play a
  673.    significant role in enabling searches to find user entries of
  674.    interest.
  675.  
  676.  
  677. 5.2.4 Certification Authority Schema
  678.  
  679.    The certification authority (CA) object class is an auxiliary class,
  680.    meaning it is essentially a set of additional attributes for a base
  681.    class such as organizationalRole, organization, organizationalUnit or
  682.    person.  Except in the case where the base structural class is
  683.    inetOrgPerson, use of the uid attribute to construct the RDN of a CA
  684.    will require the auxiliary class uidObject to permit the uid
  685.    attribute to be used. In the cases where organizationalUnit or
  686.    organization is the base class for a CA, use of the auxiliary class
  687.    dcObject will permit the RDN of the CA to be a domain component.
  688.  
  689. 5.2.5 Server and Server Application Schema
  690.  
  691.    Servers and server applications are typically represented, for want
  692.    of anything better, by entries of the object class applicationProcess
  693.    (or a class derived from it).  Sometimes the class applicationEntity
  694.    is used.  In either case, the uid attribute should probably not be
  695.    employed to construct the RDN of a server or server application
  696.    object.  The standard schema uses the attribute cn for such RDNs.
  697.  
  698.    Suppose one wants to use this naming plan both in the construction of
  699.    DNs for SSL server certificates and for their storage in a directory.
  700.    It is customary for clients connecting via SSL to compare the
  701.    server's domain name (e.g. from the URL used to contact the server)
  702.    with the value of the cn attribute in the subject field (i.e.
  703.    subject's DN) of the server's certificate. For this reason, it is
  704.    common practice to set the cn attribute to the server's domain name.
  705.  
  706.    The naming and schema to handle this situation is best explained by
  707.    an example. Consider the server "host.acme.com". Following the
  708.    algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
  709.    dc=host, dc=acme, dc=com is constructed. To conform to the existing
  710.    practices just described, the server's subject DN for the SSL server
  711.  
  712.  
  713.  
  714. Grimstad, et al.                                               [Page 12]
  715.  
  716.  
  717.  
  718.  
  719.  
  720. INTERNET-DRAFT                Naming Plan                    August 1997
  721.  
  722.  
  723.    certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
  724.    the server's certificate should be stored in a directory entry with
  725.    this name. This entry should use application process or application
  726.    entity as its structural object class and strong authentication user
  727.    as is auxiliary class.
  728.  
  729. 6.0 Security Considerations
  730.  
  731.    Although access controls may be placed on portions of the DIT to deny
  732.    browse access to unauthorized clients, it may be possible to infer
  733.    directory names and DIT structure in such sensitive portions of the
  734.    DIT from the results of DNS queries. Providing public visibility to
  735.    some portions of the DIT may assist those make such inferences.
  736.  
  737. 7.0 Acknowledgments
  738.  
  739.    This plan has emerged in the course of a number of fruitful
  740.    discussions, especially with David Chadwick, John Dale, Joe Gajewski,
  741.    Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
  742.  
  743.  
  744. 8.0 References
  745.  
  746.    [1]     S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
  747.            "Using Domains in LDAP Distinguished Names", Internet
  748.            Draft <draft-ietf-asid-ldap-domains-02.txt>, August
  749.            1997.
  750.  
  751.    [2]     X.500: The Directory -- Overview of Concepts, Models, and
  752.            Service, CCITT Recommendation X.500, December, 1988.
  753.  
  754.    [3]     P. Barker, and S. Kille, "The COSINE and Internet X.500
  755.            Schema", RFC1274, 11/27/1991.
  756.  
  757.    [4]     The North American Directory Forum, "A Naming Scheme for
  758.            c=US", RFC1255, September 1991.
  759.  
  760.    [5]     The North American Directory Forum, "NADF Standing Documents:
  761.            A Brief Overview", RFC 1417, The North American Directory
  762.            Forum", NADF, February 1993.
  763.  
  764.    [6]     W. Yeong, T. Howes, and S. Kille, "Lightweight Directory
  765.            Access Protocol", RFC1777, 03/28/1995.
  766.  
  767.    [7]     M. Wahl, T. Howes, and S. Kille, "Lightweight Directory
  768.            Access Protocol (v3)", Internet Draft <draft-ietf-asid-
  769.            ldapv3-protocol-04.txt>, March 1997.
  770.  
  771.  
  772.  
  773.  
  774. Grimstad, et al.                                               [Page 13]
  775.  
  776.  
  777.  
  778.  
  779.  
  780. INTERNET-DRAFT                Naming Plan                    August 1997
  781.  
  782.  
  783.    [8]     S. Kille, "A String Representation of Distinguished Names",
  784.            RFC1779, 03/28/1995.
  785.  
  786.    [9]     M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
  787.            Protocol (v3): UTF-8 String Representation of Distinguished
  788.            Names", Internet Draft <draft-ietf-asid-ldapv3-dn-03.txt>,
  789.            April, 1997.
  790.  
  791.    [10]    M. Wahl, "A Summary of the Pilot X.500 Schema for use in
  792.            LDAPv3", Internet Draft <draft-ietf-asid-schema-pilot-
  793.            00.txt>, March 1997.
  794.  
  795.    [11]    M. Wahl, "A Summary of the X.500 User Schema for use with
  796.            LDAPv3", Internet Draft <draft-ietf-asid-ldapv3schema-x500
  797.            01.txt>, July 1997.
  798.  
  799.    [12]    T. Howes, M. Wahl, "Referrals and Knowledge References in
  800.            LDAP Directories", Internet Draft, <draft-ietf-asid-ldapv3-
  801.            referral-00.txt>, May 1997.
  802.  
  803.    [13]    T. Howes, M. Smith, "The LDAP URL Format", Internet Draft,
  804.            <draft-ietf-asid-ldapv3-url-04.txt>, August 1997.
  805.  
  806.    [14]    M. Wahl, A. Coulbeck, T. Howes, S. Kille,  "Lightweight
  807.            Directory Access Protocol (v3): Attribute Syntax
  808.            Definitions", Internet Draft <draft-ietf-asid-ldapv3-
  809.            attributes-07.txt>, August 1997.
  810.  
  811.    [15]    M. Smith, "Definition of the inetOrgPerson Object Class",
  812.            Internet Draft <draft-ietf-asid-inetorgperson-01.txt>,
  813.            July 1997.
  814.  
  815. 12.  Authors' Addresses
  816.  
  817.  
  818.        Al Grimstad
  819.        AT&T
  820.        Room 1C-429, 101 Crawfords Corner Road
  821.        Holmdel, NJ 07733-3030
  822.        USA
  823.  
  824.        EMail:  alg@att.com
  825.  
  826.        Rick Huber
  827.        AT&T
  828.        Room 1B-433, 101 Crawfords Corner Road
  829.        Holmdel, NJ 07733-3030
  830.        USA
  831.  
  832.  
  833.  
  834. Grimstad, et al.                                               [Page 14]
  835.  
  836.  
  837.  
  838.  
  839.  
  840. INTERNET-DRAFT                Naming Plan                    August 1997
  841.  
  842.  
  843.        EMail:  rvh@att.com
  844.  
  845.        Sri Sataluri
  846.        AT&T
  847.        Room 4G-202, 101 Crawfords Corner Road
  848.        Holmdel, NJ 07733-3030
  849.        USA
  850.  
  851.        EMail:  sri@att.com
  852.  
  853.        Steve Kille
  854.        Isode Limited
  855.        The Dome, The Square
  856.        Richmond
  857.        TW9 1DT
  858.        UK
  859.  
  860.        Phone:  +44-181-332-9091
  861.        EMail:  S.Kille@isode.com
  862.  
  863.        Mark Wahl
  864.        Critical Angle Inc.
  865.        4815 W Braker Lane #502-385
  866.        Austin, TX 78759
  867.        USA
  868.  
  869.        EMail:  M.Wahl@critical-angle.com
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894. Grimstad, et al.                                               [Page 15]
  895.  
  896.  
  897.  
  898.