home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1684 < prev    next >
Text File  |  1994-08-09  |  23KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            P. Jurg
  8. Request for Comments: 1684                                    SURFnet bv
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.           Introduction to White Pages Services based on X.500
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document aims at organisations who are using local and global
  23.    electronic communication on a day to day basis and for whom using an
  24.    electronic White Pages Service is therefore indispensable.
  25.  
  26.    The document provides an introduction to the international ITU-T
  27.    (formerly CCITT) X.500 and ISO 9594 standard, which is particularly
  28.    suited for providing an integrated local and global electronic White
  29.    Pages Service.
  30.  
  31.    In addition a short overview of the experience gained from the
  32.    Paradise X.500 pilot is given. References to more detailed
  33.    information are included.
  34.  
  35.    The document should be useful for managers of the above mentioned
  36.    organisations who need to get the necessary executive commitment for
  37.    making the address information of their organisation available by
  38.    means of X.500.
  39.  
  40. Table Of Contents
  41.  
  42.    1. Introduction ................................................  2
  43.    2. Concept of X.500 ............................................  3
  44.      2.1  Directory Model .........................................  3
  45.      2.2  Information Model .......................................  4
  46.    3.  Benefits of X.500 ..........................................  5
  47.    4.  Organisational aspects of X.500(experience from Paradise) ..  6
  48.    5.  Applications of X.500 ......................................  8
  49.    6.  References .................................................  9
  50.    7.  Security Considerations .................................... 10
  51.    8.  Author's Address ........................................... 10
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. RARE Working Group on Network Applications Support              [Page 1]
  59.  
  60. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  61.  
  62.  
  63. 1. Introduction
  64.  
  65.    Due to the tremendous growth and development of international
  66.    computer networks we have nowadays the possibility to overcome -
  67.    without having to travel - geographical distances when working
  68.    together with other people. Besides the possibility of using the
  69.    telephone we may use electronic data exchange to discuss working
  70.    documents, new ideas, plans or whatsoever. One of the most popular
  71.    means for this is electronic mail, which can be used to exchange
  72.    all kinds of electronic data: from informal pure text messages to
  73.    formatted and multi-media documents.
  74.  
  75.    As the number of people connected to computer networks grows (and
  76.    it does continuously, it is at least doubling each year!), it
  77.    becomes more difficult to track down people's electronic (mail)
  78.    addresses. Hence, in order to make global communication over
  79.    computer networks work, a global White Pages service is
  80.    indispensable. Such a service should of course provide people's
  81.    electronic mail addresses, but could also easily contain telephone
  82.    and fax numbers and postal addresses.
  83.  
  84.    Currently, one technical solution for a globally distributed
  85.    White Pages service is X.500 and there exists an international
  86.    infrastructure based on X.500 technology called 'Paradise'
  87.    (Piloting An inteRnationAl DIrectory SErvice), which contains about
  88.    1.5 million entries belonging to persons and 3,000 belonging to
  89.    organisations. Worldwide 35 countries are involved. Paradise is
  90.    also a project of the EC. The project continues until September
  91.    1994. Afterwards its operational tasks will be taken over by a
  92.    European service provider for the R&D community (DANTE).
  93.  
  94.    The goal of Paradise and related national initiatives is to
  95.    stimulate and extend the use of the X.500 White Pages service.
  96.    Within the pilot attention is paid to technical and organisational
  97.    aspects. The Paradise infrastructure is mainly based on the
  98.    Internet Protocol. The specific issues that are related to the use
  99.    of the Internet Protocol for X.500 can be found in [5].
  100.  
  101.    In the decision process of joining the international X.500
  102.    infrastructure and opening (part) of the local (address)
  103.    information to the outside world, it is important that an
  104.    organisation fully understands the technical and organisational
  105.    issues that are involved.
  106.  
  107.    This document tries to be of help in this matter first by
  108.    explaining the main concepts of X.500 (section 2) and subsequently
  109.    by pointing out its benefits (section 3), the organisational
  110.    aspects that are involved (section 4), and for which other
  111.  
  112.  
  113.  
  114. RARE Working Group on Network Applications Support              [Page 2]
  115.  
  116. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  117.  
  118.  
  119.    applications the X.500 infrastructure may be used in the near
  120.    future (section 5).
  121.  
  122. 2. Concept of X.500
  123.  
  124.    The X.500 standard describes a so-called 'Directory Service', which
  125.    can be used for all types of electronic directories. This document
  126.    focusses on the use of X.500 for a global White Pages Directory.
  127.    The concept of X.500 may roughly be divided in the 'Directory
  128.    model' and the 'Information model'.
  129.  
  130.    2.1  Directory model
  131.  
  132.    X.500 uses a distributed approach to achieve the goal of a global
  133.    Directory Service. The idea is that local (communication oriented)
  134.    information of an organisation is maintained locally in one or more
  135.    so called Directory System Agents (DSA's). 'Locally' is a flexible
  136.    expression here: it is possible that one DSA keeps information of
  137.    more than one organisation. A DSA essentially is a database:
  138.  
  139.       - in which the information is stored according to the X.500
  140.         standard (see section 2.2),
  141.  
  142.       - that has the ability, where necessary, to exchange data
  143.         with other DSA's.
  144.  
  145.    Through the communication among each other the DSA's form the
  146.    Directory Information Tree (DIT). The DIT is a virtual hierarchical
  147.    datastructure consisting of a 'root', below which 'countries' are
  148.    defined. Below the countries (usually) 'organisations' are defined,
  149.    and below an organisation 'persons', or first additional
  150.    'organisational units', are defined (see the simplified illustration
  151.    below where only three countries and no organisational units are
  152.    presented). The DIT is a representation of the global Directory.
  153.  
  154.              root                      o
  155.                                       /|\
  156.                                      / | \
  157.                                     /  |  \
  158.              countries            uk   de  fr
  159.                                  / |   /\   |\
  160.                                 /  |  /  \  | \
  161.              organisations     a   b c    d e  f
  162.                                |   | |    | |  |
  163.              persons          ..  .. ...  .... ...
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. RARE Working Group on Network Applications Support              [Page 3]
  171.  
  172. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  173.  
  174.  
  175.    Each DSA holds a part of the global Directory and is able to find
  176.    out, through the hierarchical DIT structure, which DSA holds which
  177.    parts of the Directory.
  178.  
  179.    The standard does not describe how to distribute different part of
  180.    the Directory among DSA's. However, the information corresponding to
  181.    a single node of the DIT (i.e., a country, organisation, person)
  182.    cannot be distributed over several DSA's. In practice a large
  183.    organisation will maintain one or more DSA's that hold its part of
  184.    the Directory. Smaller organisations may share a DSA with other
  185.    organisations.The distribution among the DSA's is totally transparent
  186.    to the users of the Directory.
  187.  
  188.    A user of the Directory can be a person or a computer. A user
  189.    accesses the Directory through a so-called Directory User Agent
  190.    (DUA). The DUA automatically contacts a nearby DSA by means of which
  191.    the user may search or browse through the DIT and retrieve
  192.    corresponding information. A DUA can be implemented in all sorts of
  193.    user interfaces. Therefore users may access the Directory through
  194.    dedicated DUA interfaces or for example e-mail applications.
  195.    Currently most DUA nterfaces to be used by persons are dedicated, but
  196.    it is expected that in the near future a lot of DUA interfaces will
  197.    be integrated with other applications.
  198.  
  199. 2.2 Information Model
  200.  
  201.    Besides the Directory model, the X.500 standard also defines the
  202.    information model used in the Directory Service.
  203.  
  204.    All information in the Directory is stored in 'entries', each of
  205.    which belongs to at least one so-called 'object class'. In the White
  206.    Pages application of X.500, on which we focus here, object classes
  207.    are defined such as 'country', 'organisation', 'organisational unit'
  208.    and 'person'.
  209.  
  210.    The actual information in an entry is determined by so-called
  211.    'attributes' which are contained in that entry. The object classes to
  212.    which an entry belongs define what types of attributes an entry may
  213.    use and hence what information is specific for entries belonging to
  214.    that object class. The object class 'person' for example allows
  215.    attribute types like 'common name', 'telephone number', and 'e-mail
  216.    address' to be used and the object class 'organisation' allows for
  217.    attribute types like 'organisation name' and 'business category'.
  218.    Dependent on its type an attribute can take one or more values.
  219.  
  220.    To specify the name of an entry in the DIT, at least one attribute
  221.    value of the entry is used. The entry of a person is usually named
  222.    after the value of the attribute type 'common name'. The name of an
  223.  
  224.  
  225.  
  226. RARE Working Group on Network Applications Support              [Page 4]
  227.  
  228. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  229.  
  230.  
  231.    entry must be unique on the same level in the subtree of the DIT to
  232.    which the entry belongs.
  233.  
  234.    An example of an entry belonging to the object class 'person' is:
  235.  
  236.        Attribute type              Attribute value
  237.        --------------              --------------
  238.  
  239.        Object Class:               top
  240.                                    person
  241.        Common Name:                Thomas Lenggenhager
  242.                                    T. Lenggenhager
  243.        Surname:                    Lenggenhager
  244.        Postal Address:             SWITCH
  245.                                    Limmatquai 138
  246.                                    CH-8001 Zuerich
  247.        Telephone Number:           +41 1 268 1540
  248.        Facsimile Telephone Number: +41 1 268 1568
  249.        Mail:                       lenggenhager@switch.ch
  250.  
  251.    This entry corresponds to the node in the DIT that occurs below the
  252.    node of the organisation 'SWITCH' and is named after the first value
  253.    of the attribute type 'common name': 'Thomas Lenggenhager'.
  254.  
  255. 3.  Benefits of X.500
  256.  
  257.    Why should one use X.500 for a local White Pages service? Here are
  258.    some good arguments:
  259.  
  260.       - The distributed character of the service. A large
  261.         organisation may distribute the responsibility for the
  262.         management of the information it presents through X.500 by
  263.         distributing this information over several DSA's (without
  264.         losing the overall structure)
  265.  
  266.       - The flexibility of the service. Besides for public purposes,
  267.         X.500 may also be used for specific private Directory Service
  268.         applications. Whereas the definitions of the DIT, object
  269.         classes and attribute types of the public White Pages
  270.         information within an organisation have to conform to those
  271.         of the rest of world, the internal applications may use their
  272.         own DIT structure and their own definitions of object classes
  273.         and attributes (the values being only visible within (a part)
  274.         of the organisation). Nevertheless one local infrastructure
  275.         can be used for both the public and private computers.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. RARE Working Group on Network Applications Support              [Page 5]
  283.  
  284. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  285.  
  286.  
  287.       - Good alternative for paper Directories. The provision of
  288.         White Pages services based on X.500 may be a good alternative
  289.         for paper directories, because the latter directories are
  290.         rarely up-to-date (due to the printing costs) and because
  291.         X.500 not only can be used by humans but also by
  292.         applications.
  293.  
  294.    Some important arguments in favour of X.500 for global use are:
  295.  
  296.       - By its distributed nature X.500 is particularly suited for a
  297.         large global White Pages directory. Maintenance can take
  298.         place in a distributed way.
  299.  
  300.       - Good searching capabilities. X.500 offers the possibility to
  301.         do searches in any level or in any subtree of the DIT. In
  302.         order to do a search an attribute type together with a value
  303.         have to be specified. Then the Directory searches for all
  304.         entries that contain an attribute of that type with the given
  305.         value. For example one can search for all persons in an
  306.         organisation having a particular common name, or all
  307.         organisations within a country that have telecommunications
  308.         as their business category. It is up to the organisations
  309.         that maintain the DSA's to decide who may perform which
  310.         searches and also how many levels deep a search may be.
  311.  
  312.         Searches can be done on the basis of an exact or approximate
  313.         match. It is worthwile to note that distributed searches
  314.         (that need connections to a lot of DSA's) may be expensive
  315.         and are generally not encouraged.
  316.  
  317.       - There are DUA interfaces for the White Pages service
  318.         availablefor all types of workstations (DOS, Macintosh OS,
  319.         Unix). For an overview of X.500 available software see
  320.         RFC 1292 [2] or updates of this document.
  321.  
  322.       - X.500 is an international standard. Using a standard
  323.         obviously means less problems with interoperability and
  324.         interworking.Also the standard is updated according to
  325.         practical experience.
  326.  
  327. 4.  Organisational aspects of X.500 (experience from Paradise)
  328.  
  329.    The organisational aspects involved in operating a local X.500 (or
  330.    any other electronic) Directory can roughly be divided in   three
  331.    sub-aspects:datamanagement, legal issues and cost aspects. With
  332.    respect to cost aspects there is no publicly known model or
  333.    experience at the moment.
  334.  
  335.  
  336.  
  337.  
  338. RARE Working Group on Network Applications Support              [Page 6]
  339.  
  340. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  341.  
  342.  
  343.    Therefore the focus in this document is on datamanagement and legal
  344.    issues.
  345.  
  346.    Data management refers to issues that are related to inserting
  347.    appropriate information into the Directory and keeping it up to date.
  348.  
  349.    From the experience of participants in Paradise we obtain that the
  350.    following items are of first importance:
  351.  
  352.       - Executive commitment. Without this it is almost impossible to
  353.         create an organisation wide up-to-date electronic Directory.
  354.  
  355.       - Structure of the local DIT. In joining the international
  356.         infrastructure an organisation has to conform to some rules
  357.         for the local DIT structure as presented to the global X.500
  358.         infrastructure. A recommendation on how to structure a local
  359.         DIT and how to use the available attributes can be found in
  360.         [7]. The most important recommendation in the latter document
  361.         is to keep the local part of the DIT as simple (flat) as
  362.         possible. The reason is that users from outside the
  363.         organisation may otherwise have difficulties in finding
  364.         entries of persons within the organisation (searches in the
  365.         DIT are often only allowed one level deep).
  366.  
  367.       - Attributes to be used. For the existing infrastructure the
  368.         objects and associated attributes that are globally used, are
  369.         documented in [1].
  370.  
  371.       - Sources of the data. An organisation has to find out where to
  372.         get what kind of data and develop procedures for uploading
  373.         its DSA('s).
  374.  
  375.       - Delegating responsibilities for updates. Procedures have to
  376.         bedeveloped for updates of the local Directory. These
  377.         procedures have to include delegation of responsibilities.
  378.  
  379.       - Security procedures. Rules have to be set for access and
  380.         security. Who may contact the DSA? Who will have access to
  381.         which subtrees and what attributes?
  382.  
  383.    A study of the legal consequences of presenting (address) information
  384.    via X.500 lead to the main conclusion that in Europe an organisation
  385.    has to formally register its data collections.  Registration implies
  386.    defining a goal for the application. This has to be done for the
  387.    White Pages service as well as for any deviating local application of
  388.    X.500. However, the different national laws may differ with respect
  389.    to legal restrictions. For more information on this subject we refer
  390.    to "Building a Directory Service, Final Report test phase SURFnet
  391.  
  392.  
  393.  
  394. RARE Working Group on Network Applications Support              [Page 7]
  395.  
  396. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  397.  
  398.  
  399.    X.500 pilot project", E.  Huizer, SURFnet B.V., Utrecht NL, 1994.
  400.    (copies available from SURFnet B.V.)
  401.  
  402.    Among the Paradise members there are several pilots running at the
  403.    moment with the goal to evaluate the organisational aspects. Case
  404.    studies coming from these pilots will be documented.
  405.  
  406.    Small or medium size organisations that have not too many entries to
  407.    insert in the Directory may use one of the different national
  408.    initiatives concerning a 'central DSA'. These central DSA's are
  409.    operated by national service providers and contain the White Pages
  410.    information of a lot of small and medium size organisations. For
  411.    organisations in countries without such a national service there is
  412.    also a European central DSA (Paradise) and an American central DSA
  413.    (InterNIC). It is worth noting that the central DSA services are only
  414.    technical services, i.e., a participating organisation still has to
  415.    cover the organisational issues. However, part of a central DSA
  416.    service may be consultancy with respect to datamanagement and legal
  417.    issues.
  418.  
  419. 5.  Applications of X.500
  420.  
  421.    Besides for White Pages, X.500 can be useful for all kinds of
  422.    distributed information storage from which humans or machines can
  423.    benefit. Examples that are likely to use X.500 in the near future
  424.    are: distribution list mechanism, public key distribution for Privacy
  425.    Enhanced Mail (PEM), routing of X.400 messages, distribution of EDI
  426.    identifiers, etc. For more information we refer to [7]. Below the
  427.    first three applications are briefly discussed.
  428.  
  429.    The distribution list mechanism uses X.500 for finding the e-mail
  430.    addresses of the persons that have subscribed to a list. The
  431.    distributed approach of X.500 makes it possible that people change
  432.    their e-mail address without having to change their subscription to
  433.    distribution lists.
  434.  
  435.    PEM (see a.o. [8] or [4]) uses a public key mechanism for exchanging
  436.    secure e-mail messages. For example: one will be able to end a secure
  437.    message by encrypting a message with the publicly known (public) key
  438.    of the recipient. Only the recipient of the message can decipher the
  439.    message using his/her private key. In order to make such a mechanism
  440.    work one must have access to the public keys of all possible
  441.    recipients. X.500 can be used for this purpose.
  442.  
  443.    At this moment a world-wide pilot is running in which X.400 routing
  444.    is done by means of X.500. X.400 MTA's use special DUA's to find via
  445.    the Directory the MTA's to which the recipients of a message want
  446.    their mail to be delivered. The distributed approach of X.500 will
  447.  
  448.  
  449.  
  450. RARE Working Group on Network Applications Support              [Page 8]
  451.  
  452. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  453.  
  454.  
  455.    mean much less routing management (currently tables are used that
  456.    have to be updated/exchanged periodically).
  457.  
  458. 6.  References
  459.  
  460.    [1] Barker, P., and S. Kille,"The COSINE and Internet X.500 Schema",
  461.        RFC 1274, University College London, November 1991.
  462.  
  463.    [2] Getchell, A., and S. Sataluri, Editors, "A Revised Catalog of
  464.        Available X.500 Implementations", FYI 11, RFC 1632, Lawrence
  465.        Livermore National Laboratory, AT&T Bell Laboratories, May 1994.
  466.  
  467.    [3] Weider, C., and J. Reynolds, "Executive Introduction to Directory
  468.        Services using the X.500 Protocol", FYI 13, RFC 1308, ANS,
  469.        USC/Information Sciences Institute, March 1992.
  470.  
  471.    [4] Linn, J., "Privacy Enhancement for Internet Electronic Mail:Part
  472.        I: Message Encryption and Authentication Procedures", RFC 1421,
  473.        IAB IRTF PSRG, IETF PEM WGs, Feblruary 1993.
  474.  
  475.    [5] Hardcastle-Kille, S., Huizer, E., Cerf, V., Hobby, R., and S.
  476.        Kent, "A Strategic Plan for Deploying an Internet X.500 Directory
  477.        Service", RFC 1430, ISODE Consortium, SURFnet bv, Corporation for
  478.        National Research Initiatives, University of California, Davis,
  479.        Bolt, Beranek and Newman, February 1993.
  480.  
  481.    [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
  482.        Protocol", RFC 1487, Performance Systems International,
  483.        University of Michigan, ISODE Consortium, July 1993.
  484.  
  485.    [7] Weider, C., and R. Wright, R., "A Survey of Advanced Usages of
  486.        X.500", FYI 21, RFC 1491, Merit Network, Inc, Lawrence Berkeley
  487.        Laboratory, July 1993.
  488.  
  489.    [8] "Privacy Enhanced Mail in more detail", Zegwaart, E., Computer
  490.        Networks for Research in Europe Vol. 2, pp.  63-71.
  491.  
  492.    [9] Barker, P., Kille, S., and T. Lenggenhager, T., "Naming and
  493.        Structuring Guidelines for X.500 Directory Pilots", RTR 11/RFC
  494.        1617, University College London, ISODE Consortium, SWITCH, May
  495.        1994.   For a good technical introduction to X.500 we also
  496.        recommend:
  497.  
  498.   [10] Rose, M., "The Little Black Book", PSI Inc., Prentice Hall Inc.,
  499.        New Jersey, 1992.
  500.  
  501.   [11] Steedman, D., "The Directory standard and its application",
  502.        Technology Appraisals, Twickenham (U.K.), 1993.
  503.  
  504.  
  505.  
  506. RARE Working Group on Network Applications Support              [Page 9]
  507.  
  508. RFC 1684       Introduction to X.500 White Pages Services    August 1994
  509.  
  510.  
  511. 7.  Security Considerations
  512.  
  513.    Security issues are not explicitly discussed in this memo.
  514.  
  515. 8.  Author's Address
  516.  
  517.    Peter Jurg
  518.    SURFnet bv
  519.    Postbus 19035
  520.    NL-3501 DA Utrecht
  521.    The Netherlands
  522.  
  523.    Phone: +31 30 310290
  524.    Fax: +31 20 340903
  525.    RFC822: Peter.Jurg@surfnet.nl
  526.    X.400: C=nl; ADMD=400net; PRMD=surf; O=surfnet; S=jurg
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. RARE Working Group on Network Applications Support             [Page 10]
  563.  
  564.