rfc2120.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        D. Chadwick
Request for Comments: 2120                         University of Salford
Category: Experimental                                        March 1997


                 Managing the X.500 Root Naming Context

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   The X.500 Standard [X.500 93] has the concept of first level DSAs,
   whose administrators must collectively manage the root naming context
   through bi-lateral agreements or other private means which are
   outside the scope of the X.500 Standard.

   The NameFLOW-Paradise X.500 service has an established procedure for
   managing the root naming context, which currently uses Quipu
   proprietary replication mechanisms and a root DSA. The benefits that
   derive from this are twofold:

      - firstly it is much easier to co-ordinate the management of the
      root context information, when there is a central point of
      administration,

      - secondly the performance of one-level Search operations is
      greatly improved because the Quipu distribution and replication
      mechanism does not have a restriction that exists in the 1988 and
      1993 X.500 Standard.

   The NameFLOW-Paradise project is moving towards 1993 ISO X.500
   Standard replication protocols and wants to standardise the protocol
   and procedure for managing the root naming context which will be
   based on 1993 X.500 Standard protocols. Such a protocol and procedure
   will be useful to private X.500 domains as well as to the Internet
   X.500 public domain. It is imperative that overall system performance
   is not degraded by this transition.

   This document describes the use of 1993 ISO X.500 Standard protocols
   for managing the root context. Whilst the ASN.1 is compatible with
   that of the X.500 Standard, the actual settings of the parameters are
   supplementary to that of the X.500 Standard.




Chadwick                      Experimental                      [Page 1]

RFC 2120         Managing the X.500 Root Naming Context       March 1997


Table of Contents

   1 Introduction.............................................   2
   2 Migration Plan...........................................   3
   3 Technical Solutions......................................   3
   4 The Fast Track Solution..................................   4
   5 The Slower Track Solution................................   6
   6 The Long Term Solution...................................   7
   7 Security Considerations..................................   8
   8 Acknowledgments..........................................   9
   9 References...............................................   9
   10 Author's Address........................................  10
   Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-
        T by the UK...........................................  11
   Annex 2 Defect Report on 1993 X.500 Standard for Adding
        full ACIs to DISP for Subordinate References, so that
        Secure List Operation can be performed in Shadow DSAs.  12
   Annex 3 Defect Report on 1997 X.500 Standard Proposing
        an Enhancement to the Shadowing Agreement in order to
        support 1 Level Searches in Shadow DSAs...............  14

1     Introduction

   The NameFLOW-Paradise service has a proprietary way of managing the
   set of first level DSAs and the root naming context. There is a
   single root DSA (Giant Tortoise) which holds all of the country
   entries, and the country entries are then replicated to every country
   (first level) DSA and other DSAs by Quipu replication [RFC 1276] from
   the root DSA. In June 1996 there were 770 DSAs replicating this
   information over the Internet. The root DSA is not a feature of the
   X.500 Standard [X.500 93]. It was introduced because of the non-
   standard nature of the original Quipu knowledge model (also described
   in RFC 1276). However, it does have significant advantages both in
   managing the root naming context and in the performance of one-level
   Searches of the root.  Performance is increased because each country
   DSA holds all the entry information of every country.

   By comparison, the 1988 X.500 Standard root context which is
   replicated to all the country DSAs, only holds knowledge information
   and a boolean (to say if the entry is an alias or not) for each
   country entry. This is sufficient to perform an insecure List
   operation, but not a one-level Search operation. When access controls
   were added to the 1993 X.500 Standard, the root context information
   was increased (erroneously as it happens - this is the subject of
   defect report 140 - see Annex 1) to hold the access controls for each
   country entry, but a note in the X.500 Standard restricted its use to
   the List operation, in order to remain compatible with the 1988
   edition of the X.500 Standard.



Chadwick                      Experimental                      [Page 2]

RFC 2120         Managing the X.500 Root Naming Context       March 1997


2     Migration Plan

   The NameFLOW-Paradise service is now migrating to X.500 Standard
   [X.500 93] conforming products, and it is essential to replace the
   Quipu replication protocol with the 1993 shadowing and operational
   binding protocols, but without losing the performance improvement
   that has been gained for one-level Searches.

   It is still the intention of the NameFLOW-Paradise service to have
   one master root DSA. This root DSA will not support user Directory
   operations via the LDAP, the DAP or the DSP, but each country (first
   level) DSA will be able to shadow the root context from this root
   DSA, using the DISP. Each first level DSA then only needs to have one
   bi-lateral agreement, between itself and the root DSA. This agreement
   will ensure that the first level DSA keeps the root DSA up to date
   with its country level information, and in turn, that the root DSA
   keeps the first level DSA up to date with the complete root naming
   context. When a new first level DSA comes on line, it only needs to
   establish a bi-lateral agreement with the root DSA, in order to
   obtain the complete root context.

   This is a much easier configuration to manage than simply a set of
   first level DSAs without a root DSA, as suggested in the ISO X.500
   Standard. In the X.500 Standard case each first level DSA must have
   bi-lateral agreements with all of the other first level DSAs. When a
   new first level DSA comes on line, it must establish agreements with
   all the existing first level DSAs. As the number of first level DSAs
   grows, the process becomes unmanageable.

   However, it is also important to increase the amount of information
   that is held about every country entry, so that a one-level Search
   operation can be performed in each first level DSA, without it
   needing to chain or refer the operation to all the other first level
   DSAs (as is currently the case with a X.500 Standard conforming
   system.)

3     Technical Solutions

   3.1 The solution at first appears to be relatively straight forward,
   and involves two steps. Firstly, create a root DSA, and establish
   hierarchical operational bindings using the DOP, between it and each
   master first level DSA. Secondly, each master first level DSA enters
   into a shadowing agreement with the root DSA, to shadow the enlarged
   root context information. In this way each first level DSA is then
   capable of independently performing List and one-level Search
   operations, and name resolving to all other first level DSAs.





Chadwick                      Experimental                      [Page 3]

RFC 2120         Managing the X.500 Root Naming Context       March 1997


   3.2 Unfortunately there are a number of complications that inhibit a
   quick implementation of this solution. Firstly, few DSA suppliers
   have implemented the DOP. Secondly there are several defects in the
   X.500 Standard that currently stop the above solution from working.

   3.3 At a meeting chaired by DANTE in the UK on 18 June 1996[Mins], at
   which several DSA suppliers were present, the following pragmatic
   technical solution was proposed. This comprises a fast track partial
   solution and a slower track fuller solution. Both the fast and slower
   tracks use the shadowing protocol (DISP) for both steps of the
   solution, and do not rely on the DOP to establish HOBs. The fast
   track solution, described in section 4, will support knowledge
   distribution of the root context, and the (insecure) List operation
   of the root's subordinates. The List operation will be insecure
   because access control information will not be present in the shadow
   DSEs. (However, since it is generally thought that first level
   entries, in particular country entries, are publicly accessible, this
   is not considered to be a serious problem.) Suppliers expect to have
   the fast track solution available before the end of 1996. The slower
   track solution, described in section 5, will in addition support
   fully secure one level Search and List operations of the root
   (without the need to chain to the master DSAs). Suppliers at the
   DANTE meeting did not realistically expect this to be in their
   products much sooner than mid 1998.

   3.4 The long term solution, which relies on the DOP to establish
   HOBs, is described in section 6 of this document.

   (Note. It is strongly recommended that non-specific subordinate
   references should not be allowed in the root context for efficiency
   reasons. This is directed by the European functional X.500 Standard
   [ENV 41215] and the NADF standing document [NADF 7]. It is also
   preferred by the International X.500 Standardized Profile [ISP
   10615-6].)

4     The Fast Track Solution

   4.1 The fast track solution provides root knowledge collection and
   insecure List operations for first level DSAs, and will be of use to
   systems which do not yet support the DOP for managing hierarchical
   operational bindings. The fast track solution relies upon the DISP
   with very few changes to the 1993 edition of the X.500 Standard.









Chadwick                      Experimental                      [Page 4]

RFC 2120         Managing the X.500 Root Naming Context       March 1997


   4.2 Each master first level DSA administrator will make available to
   the administrator of the root DSA, sufficient information to allow
   the root DSA to configure a subordinate reference to their DSA. In
   the simplest case, this can be via a telephone call, and the
   information comprises the access point of their DSA and the RDNs of
   the first level entries that they master.

   4.3 Each master first level DSA enters into a shadowing agreement
   with the root DSA, for the purpose of shadowing the root naming
   context.

   The 1993 edition of the X.500 Standard explicitly recognises that
   there can be master and shadow first level DSAs (X.501 Section 18.5).
   (The 1988 edition of the X.500 Standard does not explicitly recognise
   this, since it does not recognise shadowing.) A shadow first level
   DSA holds a copy of the root context, provided by a master first
   level DSA. In addition it holds shadow copies of the (one or more)
   country entries that the master first level DSA holds. There is
   currently an outstanding defect report [UK 142] on the 1993 X.500
   Standard to clarify how a shadowing agreement is established between
   first level DSAs. Once this has been ratified, the only additional
   text needed in order to establish a shadowing agreement between the
   root DSA and a master first level DSA is as follows:

   "When clause 9.2 of ISO/IEC 9594-9:1993 is applied to the
   shadowing of the root context by a first level DSA from the root
   DSA of a domain, then UnitOfReplication shall be set as follows:

   contextPrefix of AreaSpecification shall be null,

   replicationArea of AreaSpecification shall be set to
                       SEQUENCE {
        specificExclusions  [1]  SET OF {