GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1684

Network Working Group P. Jurg Request for Comments: 1684 SURFnet bv Category: Informational August 1994

        Introduction to White Pages Services based on X.500

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.

Abstract

 This document aims at organisations who are using local and global
 electronic communication on a day to day basis and for whom using an
 electronic White Pages Service is therefore indispensable.
 The document provides an introduction to the international ITU-T
 (formerly CCITT) X.500 and ISO 9594 standard, which is particularly
 suited for providing an integrated local and global electronic White
 Pages Service.
 In addition a short overview of the experience gained from the
 Paradise X.500 pilot is given. References to more detailed
 information are included.
 The document should be useful for managers of the above mentioned
 organisations who need to get the necessary executive commitment for
 making the address information of their organisation available by
 means of X.500.

Table Of Contents

 1. Introduction ................................................  2
 2. Concept of X.500 ............................................  3
   2.1  Directory Model .........................................  3
   2.2  Information Model .......................................  4
 3.  Benefits of X.500 ..........................................  5
 4.  Organisational aspects of X.500(experience from Paradise) ..  6
 5.  Applications of X.500 ......................................  8
 6.  References .................................................  9
 7.  Security Considerations .................................... 10
 8.  Author's Address ........................................... 10

RARE Working Group on Network Applications Support [Page 1] RFC 1684 Introduction to X.500 White Pages Services August 1994

1. Introduction

 Due to the tremendous growth and development of international
 computer networks we have nowadays the possibility to overcome -
 without having to travel - geographical distances when working
 together with other people. Besides the possibility of using the
 telephone we may use electronic data exchange to discuss working
 documents, new ideas, plans or whatsoever. One of the most popular
 means for this is electronic mail, which can be used to exchange
 all kinds of electronic data: from informal pure text messages to
 formatted and multi-media documents.
 As the number of people connected to computer networks grows (and
 it does continuously, it is at least doubling each year!), it
 becomes more difficult to track down people's electronic (mail)
 addresses. Hence, in order to make global communication over
 computer networks work, a global White Pages service is
 indispensable. Such a service should of course provide people's
 electronic mail addresses, but could also easily contain telephone
 and fax numbers and postal addresses.
 Currently, one technical solution for a globally distributed
 White Pages service is X.500 and there exists an international
 infrastructure based on X.500 technology called 'Paradise'
 (Piloting An inteRnationAl DIrectory SErvice), which contains about
 1.5 million entries belonging to persons and 3,000 belonging to
 organisations. Worldwide 35 countries are involved. Paradise is
 also a project of the EC. The project continues until September
 1994. Afterwards its operational tasks will be taken over by a
 European service provider for the R&D community (DANTE).
 The goal of Paradise and related national initiatives is to
 stimulate and extend the use of the X.500 White Pages service.
 Within the pilot attention is paid to technical and organisational
 aspects. The Paradise infrastructure is mainly based on the
 Internet Protocol. The specific issues that are related to the use
 of the Internet Protocol for X.500 can be found in [5].
 In the decision process of joining the international X.500
 infrastructure and opening (part) of the local (address)
 information to the outside world, it is important that an
 organisation fully understands the technical and organisational
 issues that are involved.
 This document tries to be of help in this matter first by
 explaining the main concepts of X.500 (section 2) and subsequently
 by pointing out its benefits (section 3), the organisational
 aspects that are involved (section 4), and for which other

RARE Working Group on Network Applications Support [Page 2] RFC 1684 Introduction to X.500 White Pages Services August 1994

 applications the X.500 infrastructure may be used in the near
 future (section 5).

2. Concept of X.500

 The X.500 standard describes a so-called 'Directory Service', which
 can be used for all types of electronic directories. This document
 focusses on the use of X.500 for a global White Pages Directory.
 The concept of X.500 may roughly be divided in the 'Directory
 model' and the 'Information model'.
 2.1  Directory model
 X.500 uses a distributed approach to achieve the goal of a global
 Directory Service. The idea is that local (communication oriented)
 information of an organisation is maintained locally in one or more
 so called Directory System Agents (DSA's). 'Locally' is a flexible
 expression here: it is possible that one DSA keeps information of
 more than one organisation. A DSA essentially is a database:
  1. in which the information is stored according to the X.500

standard (see section 2.2),

  1. that has the ability, where necessary, to exchange data

with other DSA's.

 Through the communication among each other the DSA's form the
 Directory Information Tree (DIT). The DIT is a virtual hierarchical
 datastructure consisting of a 'root', below which 'countries' are
 defined. Below the countries (usually) 'organisations' are defined,
 and below an organisation 'persons', or first additional
 'organisational units', are defined (see the simplified illustration
 below where only three countries and no organisational units are
 presented). The DIT is a representation of the global Directory.
           root                      o
                                    /|\
                                   / | \
                                  /  |  \
           countries            uk   de  fr
                               / |   /\   |\
                              /  |  /  \  | \
           organisations     a   b c    d e  f
                             |   | |    | |  |
           persons          ..  .. ...  .... ...

RARE Working Group on Network Applications Support [Page 3] RFC 1684 Introduction to X.500 White Pages Services August 1994

 Each DSA holds a part of the global Directory and is able to find
 out, through the hierarchical DIT structure, which DSA holds which
 parts of the Directory.
 The standard does not describe how to distribute different part of
 the Directory among DSA's. However, the information corresponding to
 a single node of the DIT (i.e., a country, organisation, person)
 cannot be distributed over several DSA's. In practice a large
 organisation will maintain one or more DSA's that hold its part of
 the Directory. Smaller organisations may share a DSA with other
 organisations.The distribution among the DSA's is totally transparent
 to the users of the Directory.
 A user of the Directory can be a person or a computer. A user
 accesses the Directory through a so-called Directory User Agent
 (DUA). The DUA automatically contacts a nearby DSA by means of which
 the user may search or browse through the DIT and retrieve
 corresponding information. A DUA can be implemented in all sorts of
 user interfaces. Therefore users may access the Directory through
 dedicated DUA interfaces or for example e-mail applications.
 Currently most DUA nterfaces to be used by persons are dedicated, but
 it is expected that in the near future a lot of DUA interfaces will
 be integrated with other applications.

2.2 Information Model

 Besides the Directory model, the X.500 standard also defines the
 information model used in the Directory Service.
 All information in the Directory is stored in 'entries', each of
 which belongs to at least one so-called 'object class'. In the White
 Pages application of X.500, on which we focus here, object classes
 are defined such as 'country', 'organisation', 'organisational unit'
 and 'person'.
 The actual information in an entry is determined by so-called
 'attributes' which are contained in that entry. The object classes to
 which an entry belongs define what types of attributes an entry may
 use and hence what information is specific for entries belonging to
 that object class. The object class 'person' for example allows
 attribute types like 'common name', 'telephone number', and 'e-mail
 address' to be used and the object class 'organisation' allows for
 attribute types like 'organisation name' and 'business category'.
 Dependent on its type an attribute can take one or more values.
 To specify the name of an entry in the DIT, at least one attribute
 value of the entry is used. The entry of a person is usually named
 after the value of the attribute type 'common name'. The name of an

RARE Working Group on Network Applications Support [Page 4] RFC 1684 Introduction to X.500 White Pages Services August 1994

 entry must be unique on the same level in the subtree of the DIT to
 which the entry belongs.
 An example of an entry belonging to the object class 'person' is:
     Attribute type              Attribute value
     --------------              --------------
     Object Class:               top
                                 person
     Common Name:                Thomas Lenggenhager
                                 T. Lenggenhager
     Surname:                    Lenggenhager
     Postal Address:             SWITCH
                                 Limmatquai 138
                                 CH-8001 Zuerich
     Telephone Number:           +41 1 268 1540
     Facsimile Telephone Number: +41 1 268 1568
     Mail:                       lenggenhager@switch.ch
 This entry corresponds to the node in the DIT that occurs below the
 node of the organisation 'SWITCH' and is named after the first value
 of the attribute type 'common name': 'Thomas Lenggenhager'.

3. Benefits of X.500

 Why should one use X.500 for a local White Pages service? Here are
 some good arguments:
  1. The distributed character of the service. A large

organisation may distribute the responsibility for the

      management of the information it presents through X.500 by
      distributing this information over several DSA's (without
      losing the overall structure)
  1. The flexibility of the service. Besides for public purposes,

X.500 may also be used for specific private Directory Service

      applications. Whereas the definitions of the DIT, object
      classes and attribute types of the public White Pages
      information within an organisation have to conform to those
      of the rest of world, the internal applications may use their
      own DIT structure and their own definitions of object classes
      and attributes (the values being only visible within (a part)
      of the organisation). Nevertheless one local infrastructure
      can be used for both the public and private computers.

RARE Working Group on Network Applications Support [Page 5] RFC 1684 Introduction to X.500 White Pages Services August 1994

  1. Good alternative for paper Directories. The provision of

White Pages services based on X.500 may be a good alternative

      for paper directories, because the latter directories are
      rarely up-to-date (due to the printing costs) and because
      X.500 not only can be used by humans but also by
      applications.
 Some important arguments in favour of X.500 for global use are:
  1. By its distributed nature X.500 is particularly suited for a

large global White Pages directory. Maintenance can take

      place in a distributed way.
  1. Good searching capabilities. X.500 offers the possibility to

do searches in any level or in any subtree of the DIT. In

      order to do a search an attribute type together with a value
      have to be specified. Then the Directory searches for all
      entries that contain an attribute of that type with the given
      value. For example one can search for all persons in an
      organisation having a particular common name, or all
      organisations within a country that have telecommunications
      as their business category. It is up to the organisations
      that maintain the DSA's to decide who may perform which
      searches and also how many levels deep a search may be.
      Searches can be done on the basis of an exact or approximate
      match. It is worthwile to note that distributed searches
      (that need connections to a lot of DSA's) may be expensive
      and are generally not encouraged.
  1. There are DUA interfaces for the White Pages service

availablefor all types of workstations (DOS, Macintosh OS,

      Unix). For an overview of X.500 available software see
      RFC 1292 [2] or updates of this document.
  1. X.500 is an international standard. Using a standard

obviously means less problems with interoperability and

      interworking.Also the standard is updated according to
      practical experience.

4. Organisational aspects of X.500 (experience from Paradise)

 The organisational aspects involved in operating a local X.500 (or
 any other electronic) Directory can roughly be divided in   three
 sub-aspects:datamanagement, legal issues and cost aspects. With
 respect to cost aspects there is no publicly known model or
 experience at the moment.

RARE Working Group on Network Applications Support [Page 6] RFC 1684 Introduction to X.500 White Pages Services August 1994

 Therefore the focus in this document is on datamanagement and legal
 issues.
 Data management refers to issues that are related to inserting
 appropriate information into the Directory and keeping it up to date.
 From the experience of participants in Paradise we obtain that the
 following items are of first importance:
  1. Executive commitment. Without this it is almost impossible to

create an organisation wide up-to-date electronic Directory.

  1. Structure of the local DIT. In joining the international

infrastructure an organisation has to conform to some rules

      for the local DIT structure as presented to the global X.500
      infrastructure. A recommendation on how to structure a local
      DIT and how to use the available attributes can be found in
      [7]. The most important recommendation in the latter document
      is to keep the local part of the DIT as simple (flat) as
      possible. The reason is that users from outside the
      organisation may otherwise have difficulties in finding
      entries of persons within the organisation (searches in the
      DIT are often only allowed one level deep).
  1. Attributes to be used. For the existing infrastructure the

objects and associated attributes that are globally used, are

      documented in [1].
  1. Sources of the data. An organisation has to find out where to

get what kind of data and develop procedures for uploading

      its DSA('s).
  1. Delegating responsibilities for updates. Procedures have to

bedeveloped for updates of the local Directory. These

      procedures have to include delegation of responsibilities.
  1. Security procedures. Rules have to be set for access and

security. Who may contact the DSA? Who will have access to

      which subtrees and what attributes?
 A study of the legal consequences of presenting (address) information
 via X.500 lead to the main conclusion that in Europe an organisation
 has to formally register its data collections.  Registration implies
 defining a goal for the application. This has to be done for the
 White Pages service as well as for any deviating local application of
 X.500. However, the different national laws may differ with respect
 to legal restrictions. For more information on this subject we refer
 to "Building a Directory Service, Final Report test phase SURFnet

RARE Working Group on Network Applications Support [Page 7] RFC 1684 Introduction to X.500 White Pages Services August 1994

 X.500 pilot project", E.  Huizer, SURFnet B.V., Utrecht NL, 1994.
 (copies available from SURFnet B.V.)
 Among the Paradise members there are several pilots running at the
 moment with the goal to evaluate the organisational aspects. Case
 studies coming from these pilots will be documented.
 Small or medium size organisations that have not too many entries to
 insert in the Directory may use one of the different national
 initiatives concerning a 'central DSA'. These central DSA's are
 operated by national service providers and contain the White Pages
 information of a lot of small and medium size organisations. For
 organisations in countries without such a national service there is
 also a European central DSA (Paradise) and an American central DSA
 (InterNIC). It is worth noting that the central DSA services are only
 technical services, i.e., a participating organisation still has to
 cover the organisational issues. However, part of a central DSA
 service may be consultancy with respect to datamanagement and legal
 issues.

5. Applications of X.500

 Besides for White Pages, X.500 can be useful for all kinds of
 distributed information storage from which humans or machines can
 benefit. Examples that are likely to use X.500 in the near future
 are: distribution list mechanism, public key distribution for Privacy
 Enhanced Mail (PEM), routing of X.400 messages, distribution of EDI
 identifiers, etc. For more information we refer to [7]. Below the
 first three applications are briefly discussed.
 The distribution list mechanism uses X.500 for finding the e-mail
 addresses of the persons that have subscribed to a list. The
 distributed approach of X.500 makes it possible that people change
 their e-mail address without having to change their subscription to
 distribution lists.
 PEM (see a.o. [8] or [4]) uses a public key mechanism for exchanging
 secure e-mail messages. For example: one will be able to end a secure
 message by encrypting a message with the publicly known (public) key
 of the recipient. Only the recipient of the message can decipher the
 message using his/her private key. In order to make such a mechanism
 work one must have access to the public keys of all possible
 recipients. X.500 can be used for this purpose.
 At this moment a world-wide pilot is running in which X.400 routing
 is done by means of X.500. X.400 MTA's use special DUA's to find via
 the Directory the MTA's to which the recipients of a message want
 their mail to be delivered. The distributed approach of X.500 will

RARE Working Group on Network Applications Support [Page 8] RFC 1684 Introduction to X.500 White Pages Services August 1994

 mean much less routing management (currently tables are used that
 have to be updated/exchanged periodically).

6. References

 [1] Barker, P., and S. Kille,"The COSINE and Internet X.500 Schema",
     RFC 1274, University College London, November 1991.
 [2] Getchell, A., and S. Sataluri, Editors, "A Revised Catalog of
     Available X.500 Implementations", FYI 11, RFC 1632, Lawrence
     Livermore National Laboratory, AT&T Bell Laboratories, May 1994.
 [3] Weider, C., and J. Reynolds, "Executive Introduction to Directory
     Services using the X.500 Protocol", FYI 13, RFC 1308, ANS,
     USC/Information Sciences Institute, March 1992.
 [4] Linn, J., "Privacy Enhancement for Internet Electronic Mail:Part
     I: Message Encryption and Authentication Procedures", RFC 1421,
     IAB IRTF PSRG, IETF PEM WGs, Feblruary 1993.
 [5] Hardcastle-Kille, S., Huizer, E., Cerf, V., Hobby, R., and S.
     Kent, "A Strategic Plan for Deploying an Internet X.500 Directory
     Service", RFC 1430, ISODE Consortium, SURFnet bv, Corporation for
     National Research Initiatives, University of California, Davis,
     Bolt, Beranek and Newman, February 1993.
 [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
     Protocol", RFC 1487, Performance Systems International,
     University of Michigan, ISODE Consortium, July 1993.
 [7] Weider, C., and R. Wright, R., "A Survey of Advanced Usages of
     X.500", FYI 21, RFC 1491, Merit Network, Inc, Lawrence Berkeley
     Laboratory, July 1993.
 [8] "Privacy Enhanced Mail in more detail", Zegwaart, E., Computer
     Networks for Research in Europe Vol. 2, pp.  63-71.
 [9] Barker, P., Kille, S., and T. Lenggenhager, T., "Naming and
     Structuring Guidelines for X.500 Directory Pilots", RTR 11/RFC
     1617, University College London, ISODE Consortium, SWITCH, May
     1994.   For a good technical introduction to X.500 we also
     recommend:
[10] Rose, M., "The Little Black Book", PSI Inc., Prentice Hall Inc.,
     New Jersey, 1992.
[11] Steedman, D., "The Directory standard and its application",
     Technology Appraisals, Twickenham (U.K.), 1993.

RARE Working Group on Network Applications Support [Page 9] RFC 1684 Introduction to X.500 White Pages Services August 1994

7. Security Considerations

 Security issues are not explicitly discussed in this memo.

8. Author's Address

 Peter Jurg
 SURFnet bv
 Postbus 19035
 NL-3501 DA Utrecht
 The Netherlands
 Phone: +31 30 310290
 Fax: +31 20 340903
 RFC822: Peter.Jurg@surfnet.nl
 X.400: C=nl; ADMD=400net; PRMD=surf; O=surfnet; S=jurg

RARE Working Group on Network Applications Support [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1684.txt · Last modified: 1994/08/08 23:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki