rfc1430.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,123 行 · 第 1/4 页

Network Working Group                                S. Hardcastle-Kille
Request for Comments: 1430                              ISODE-Consortium
                                                               E. Huizer
                                                              SURFnet bv
                                                                 V. Cerf
                           Corporation for National Research Initiatives
                                                                R. Hobby
                                         University of California, Davis
                                                                 S. Kent
                                                Bolt, Beranek and Newman
                                                           February 1993


                   A Strategic Plan for Deploying an
                    Internet X.500 Directory Service

Status of this Memo

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

Abstract

   There are a number of reasons why a new Internet Directory Service is
   required.  This document describes an overall strategy for deploying
   a Directory Service on the Internet, based on the OSI X.500 Directory
   Service.  It then describes in more detail the initial steps which
   need to be taken in order to achieve these goals, and how work
   already undertaken by Internet Engineering Task Force Working Groups
   (IETF WGs) is working towards these goals.

Table of Contents

   1.    REQUIREMENTS                                                  2
   2.    SUMMARY OF SOLUTION                                           3
   3.    INFORMATION FRAMEWORK                                         3
   3.1   The Technical Model                                           3
   3.2   Extending the Technical Model                                 4
   3.3   The Operational Model                                         5
   4.    NAME ASSIGNMENT                                               5
   5.    DIRECTORY INFRASTRUCTURE                                      6
   5.1   Short Term Requirements                                       7
   5.2   Medium Term Requirements                                      9
   5.3   Long Term Requirements                                        9
   6.    DATAMANAGEMENT                                                9
   6.1   Legal Issues                                                 10
   7.    TECHNICAL ISSUES                                             10



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 1]

RFC 1430                     X.500 Strategy                February 1993


   7.1   Schema                                                       11
   7.2   Use on the Internet                                          11
   7.3   Replication of Knowledge and Data                            12
   7.4   Presentation of Directory Names                              13
   7.5   DSA Naming and MD Structure                                  13
   8.    SECURITY                                                     13
   8.1   Directory Provision of Authentication                        14
   8.2   Directory Security                                           15
   9.    RELATION TO DNS                                              16
   10.   EXTERNAL CONNECTIONS                                         16
   11.   REFERENCES                                                   17
   12.   Security Considerations                                      19
   13.   Authors' Addresses                                           20

1.  REQUIREMENTS

   There is substantial interest in establishing a new Directory Service
   on the Internet. In the short term, there is pressure to establish
   two new services:

   -  White Pages lookup of users;

   -  Support for X.509 Authentication for a range of applications in
      particular for Privacy Enhanced mail [Lin89].

   In the medium term, there are likely to be many requirements for
   Directory Services, including:

   - General resource lookup, for information ranging from committee
     structures to bibliographic data;

   - Support of management of the Internet infrastructure, and
     integration of configuration information into the higher level
     directory;

   - Support of applications on the Internet. For example:

      o  Electronic distribution lists;
      o  Capability information on advanced user agents;
      o  Location of files and archive services.

   - Support for Mail Handling Systems; Be they RFC-822 based or X.400
     based (IETF MHS-DS WG), e.g.,:

      o  Support for routing;
      o  Info on User agent capabilities; essential for a usage of
         Multimedia mail like MIME (Multipurpose Internet Mail
         Extensions).



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 2]

RFC 1430                     X.500 Strategy                February 1993


   For the longer term, more sophisticated usages of X.500 are possible
   extending it into a useful and fast yellow pages service.

2. SUMMARY OF SOLUTION

   In principle, the current Internet Domain Name System (DNS) could be
   used for many of these functions, with appropriate extensions.
   However, it is suggested that a higher level of directory service is
   needed. It is proposed to establish an Internet Directory Service
   based on X.500.  This provides appropriate functionality for the
   services envisaged and gives flexibility for future extension. This
   extension could be achieved either by tracking the evolution of the
   OSI Standard or by work specific to the Internet. In practice, it is
   likely to be a mixture of both.

   By deploying X.500 in some form on the Internet, a truly global and
   universal Directory Service can be built that will provide Internet
   users with fast access to all kinds of data. The X.500 Directory
   Service in this case may range from a simple white pages service
   (information on people and services) to coupling various existing
   databases and information repositories in a universal way.

   Currently, several different but cooperating X.500 Directory Services
   pilots are taking place on the Internet. These pilots form an
   important base for experimenting with this new service. Starting with
   these pilots, with the X.500 products arriving on the market today,
   and given sufficient funding for the central services described in
   this paper an operational X.500 Directory Service can be deployed.

   The final goal of the strategy described in this paper is to deploy a
   fully operational Directory Service on the Internet, providing the
   functions mentioned in the previous section.

3.  INFORMATION FRAMEWORK

   The most critical aspect of the Directory Service is to establish an
   Internet Information Framework. When establishing a sophisticated
   distributed directory with a coherent information framework, it
   involves substantial effort to map data onto this framework. This
   effort is an operational effort and far outweighs the technical
   effort of establishing servers and user agents.

3.1   The Technical Model

   By choosing the X.500 model as a basis for the information framework,
   it will also be part of a (future) global information framework. The
   key aspects of this model are:




Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 3]

RFC 1430                     X.500 Strategy                February 1993


   - A hierarchical navigational system that couples distributed
     databases (of various kinds), which allows for management of the
     data by the organization/person responsible for the data;

   - Each object in this information structure (called the Directory
     Information Tree, DIT) is represented as an entry;

   - Objects are typed by an "object class", which permits multiple
     inheritance;

   - An object is described by a set of attributes;

   - Each attribute is typed. Attribute types are hierarchical;

   - Each attribute type has an associated attribute syntax, which may
     be generic or shared with other attributes (e.g., Integer Syntax;
     Distinguished name Syntax); This allows for representation of
     simple attributes (e.g., strings or bitmaps) or complex ones with
     detailed structures.

   - Each entry has an unambiguous and unique global name;

   - Alternate hierarchies may be built by use of aliases or pointers of
     distinguished name syntax.

   This framework allows for representation of basic objects such as
   users within organizations. It is also highly extensible, and so can
   be used for a range of other applications.

3.2   Extending the Technical Model

   In the longer term, the model could be extended to deal with a number
   of other requirements which potentially must be met by an Internet
   Directory Service. Possible extensions include:

   - Support of ordered attributes (needed by some applications such as
     message storage);

   - Extensions to allow unification with management information,
     associated with SNMP (Simple Network Management Protocol) [CFSD90]
     or other management protocols;

   - Handling of non-hierarchical data in a better manner for searching
     and retrieval, whilst retaining the basic hierarchy for management
     purposes.  This is essentially building a general purpose resource
     location service on top of the basic infrastructure. It will need
     work on the information model, and not just the access protocols.




Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 4]

RFC 1430                     X.500 Strategy                February 1993


   It is noted that although X.500 may not provide the ultimate solution
   to information retrieval, it has good potential for solving a lot of
   information service related problems.

3.3   The Operational Model

   To make the Directory Service with a coherent information framework
   really operational requires a lot of effort. The most probable
   operational model is one where larger organizations on the Internet
   maintain their part of the DIT on their own DSA (Directory System
   Agent). Smaller organizations will "rent" DSA space from regional
   networks or other service providers. Together these DSAs will form
   the Internet Directory Service Infrastructure. To couple the various
   parts of the DIT that are contained on these Internet DSAs, a special
   DSA containing the Root for the naming hierarchy within the DIT has
   to be established and maintained.

   The following tasks can be foreseen:

   -  Defining the naming hierarchy; See section 4.
   -  Creating the Directory Infrastructure; See section 5.
   -  Getting the Data into the directory; and
   -  Managing the data in the Directory. See section 6.

4.  NAME ASSIGNMENT

   In order to deploy the Internet Directory Service, it is important to
   define how the naming hierarchy will be structured. Although the
   basic model suggests a simple monolithic "database" containing all of
   the Internet's information infrastructure, with a namespace divided
   along geographic boundaries, this may not be the definite model that
   turns out to be the most appropriate to the Internet. Different
   models may evolve according to the needs of the Internet and the
   applications used on the Internet (i.e., some parts of the DIT may be
   assigned at the root for the Internet). Below this one can envisage
   several loosely coupled namespaces each with their own area of
   applicability. This should be handled as a part of the general
   operation of a directory service. An example of this might be
   assignment of a representation of the Domain Namespace under the root
   of the DIT. This is further discussed in [BHK91a].

   However, the core DIT information will be nationally assigned. The
   parts of the DIT below country level will be managed differently in
   each country. In many countries, registration authorities will be
   established according to the OSI Standard [ISO]. This has been done
   in some countries by the national ISO member body representative (for
   example in the UK by BSI).