📄 rfc1430.txt
字号:
Network Working Group S. Hardcastle-KilleRequest 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 ServiceStatus 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 10Hardcastle-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 201. 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).
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -