home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2120 < prev    next >
Text File  |  1997-03-28  |  31KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        D. Chadwick
  8. Request for Comments: 2120                         University of Salford
  9. Category: Experimental                                        March 1997
  10.  
  11.  
  12.                  Managing the X.500 Root Naming Context
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The X.500 Standard [X.500 93] has the concept of first level DSAs,
  24.    whose administrators must collectively manage the root naming context
  25.    through bi-lateral agreements or other private means which are
  26.    outside the scope of the X.500 Standard.
  27.  
  28.    The NameFLOW-Paradise X.500 service has an established procedure for
  29.    managing the root naming context, which currently uses Quipu
  30.    proprietary replication mechanisms and a root DSA. The benefits that
  31.    derive from this are twofold:
  32.  
  33.       - firstly it is much easier to co-ordinate the management of the
  34.       root context information, when there is a central point of
  35.       administration,
  36.  
  37.       - secondly the performance of one-level Search operations is
  38.       greatly improved because the Quipu distribution and replication
  39.       mechanism does not have a restriction that exists in the 1988 and
  40.       1993 X.500 Standard.
  41.  
  42.    The NameFLOW-Paradise project is moving towards 1993 ISO X.500
  43.    Standard replication protocols and wants to standardise the protocol
  44.    and procedure for managing the root naming context which will be
  45.    based on 1993 X.500 Standard protocols. Such a protocol and procedure
  46.    will be useful to private X.500 domains as well as to the Internet
  47.    X.500 public domain. It is imperative that overall system performance
  48.    is not degraded by this transition.
  49.  
  50.    This document describes the use of 1993 ISO X.500 Standard protocols
  51.    for managing the root context. Whilst the ASN.1 is compatible with
  52.    that of the X.500 Standard, the actual settings of the parameters are
  53.    supplementary to that of the X.500 Standard.
  54.  
  55.  
  56.  
  57.  
  58. Chadwick                      Experimental                      [Page 1]
  59.  
  60. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1 Introduction.............................................   2
  66.    2 Migration Plan...........................................   3
  67.    3 Technical Solutions......................................   3
  68.    4 The Fast Track Solution..................................   4
  69.    5 The Slower Track Solution................................   6
  70.    6 The Long Term Solution...................................   7
  71.    7 Security Considerations..................................   8
  72.    8 Acknowledgments..........................................   9
  73.    9 References...............................................   9
  74.    10 Author's Address........................................  10
  75.    Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-
  76.         T by the UK...........................................  11
  77.    Annex 2 Defect Report on 1993 X.500 Standard for Adding
  78.         full ACIs to DISP for Subordinate References, so that
  79.         Secure List Operation can be performed in Shadow DSAs.  12
  80.    Annex 3 Defect Report on 1997 X.500 Standard Proposing
  81.         an Enhancement to the Shadowing Agreement in order to
  82.         support 1 Level Searches in Shadow DSAs...............  14
  83.  
  84. 1     Introduction
  85.  
  86.    The NameFLOW-Paradise service has a proprietary way of managing the
  87.    set of first level DSAs and the root naming context. There is a
  88.    single root DSA (Giant Tortoise) which holds all of the country
  89.    entries, and the country entries are then replicated to every country
  90.    (first level) DSA and other DSAs by Quipu replication [RFC 1276] from
  91.    the root DSA. In June 1996 there were 770 DSAs replicating this
  92.    information over the Internet. The root DSA is not a feature of the
  93.    X.500 Standard [X.500 93]. It was introduced because of the non-
  94.    standard nature of the original Quipu knowledge model (also described
  95.    in RFC 1276). However, it does have significant advantages both in
  96.    managing the root naming context and in the performance of one-level
  97.    Searches of the root.  Performance is increased because each country
  98.    DSA holds all the entry information of every country.
  99.  
  100.    By comparison, the 1988 X.500 Standard root context which is
  101.    replicated to all the country DSAs, only holds knowledge information
  102.    and a boolean (to say if the entry is an alias or not) for each
  103.    country entry. This is sufficient to perform an insecure List
  104.    operation, but not a one-level Search operation. When access controls
  105.    were added to the 1993 X.500 Standard, the root context information
  106.    was increased (erroneously as it happens - this is the subject of
  107.    defect report 140 - see Annex 1) to hold the access controls for each
  108.    country entry, but a note in the X.500 Standard restricted its use to
  109.    the List operation, in order to remain compatible with the 1988
  110.    edition of the X.500 Standard.
  111.  
  112.  
  113.  
  114. Chadwick                      Experimental                      [Page 2]
  115.  
  116. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  117.  
  118.  
  119. 2     Migration Plan
  120.  
  121.    The NameFLOW-Paradise service is now migrating to X.500 Standard
  122.    [X.500 93] conforming products, and it is essential to replace the
  123.    Quipu replication protocol with the 1993 shadowing and operational
  124.    binding protocols, but without losing the performance improvement
  125.    that has been gained for one-level Searches.
  126.  
  127.    It is still the intention of the NameFLOW-Paradise service to have
  128.    one master root DSA. This root DSA will not support user Directory
  129.    operations via the LDAP, the DAP or the DSP, but each country (first
  130.    level) DSA will be able to shadow the root context from this root
  131.    DSA, using the DISP. Each first level DSA then only needs to have one
  132.    bi-lateral agreement, between itself and the root DSA. This agreement
  133.    will ensure that the first level DSA keeps the root DSA up to date
  134.    with its country level information, and in turn, that the root DSA
  135.    keeps the first level DSA up to date with the complete root naming
  136.    context. When a new first level DSA comes on line, it only needs to
  137.    establish a bi-lateral agreement with the root DSA, in order to
  138.    obtain the complete root context.
  139.  
  140.    This is a much easier configuration to manage than simply a set of
  141.    first level DSAs without a root DSA, as suggested in the ISO X.500
  142.    Standard. In the X.500 Standard case each first level DSA must have
  143.    bi-lateral agreements with all of the other first level DSAs. When a
  144.    new first level DSA comes on line, it must establish agreements with
  145.    all the existing first level DSAs. As the number of first level DSAs
  146.    grows, the process becomes unmanageable.
  147.  
  148.    However, it is also important to increase the amount of information
  149.    that is held about every country entry, so that a one-level Search
  150.    operation can be performed in each first level DSA, without it
  151.    needing to chain or refer the operation to all the other first level
  152.    DSAs (as is currently the case with a X.500 Standard conforming
  153.    system.)
  154.  
  155. 3     Technical Solutions
  156.  
  157.    3.1 The solution at first appears to be relatively straight forward,
  158.    and involves two steps. Firstly, create a root DSA, and establish
  159.    hierarchical operational bindings using the DOP, between it and each
  160.    master first level DSA. Secondly, each master first level DSA enters
  161.    into a shadowing agreement with the root DSA, to shadow the enlarged
  162.    root context information. In this way each first level DSA is then
  163.    capable of independently performing List and one-level Search
  164.    operations, and name resolving to all other first level DSAs.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Chadwick                      Experimental                      [Page 3]
  171.  
  172. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  173.  
  174.  
  175.    3.2 Unfortunately there are a number of complications that inhibit a
  176.    quick implementation of this solution. Firstly, few DSA suppliers
  177.    have implemented the DOP. Secondly there are several defects in the
  178.    X.500 Standard that currently stop the above solution from working.
  179.  
  180.    3.3 At a meeting chaired by DANTE in the UK on 18 June 1996[Mins], at
  181.    which several DSA suppliers were present, the following pragmatic
  182.    technical solution was proposed. This comprises a fast track partial
  183.    solution and a slower track fuller solution. Both the fast and slower
  184.    tracks use the shadowing protocol (DISP) for both steps of the
  185.    solution, and do not rely on the DOP to establish HOBs. The fast
  186.    track solution, described in section 4, will support knowledge
  187.    distribution of the root context, and the (insecure) List operation
  188.    of the root's subordinates. The List operation will be insecure
  189.    because access control information will not be present in the shadow
  190.    DSEs. (However, since it is generally thought that first level
  191.    entries, in particular country entries, are publicly accessible, this
  192.    is not considered to be a serious problem.) Suppliers expect to have
  193.    the fast track solution available before the end of 1996. The slower
  194.    track solution, described in section 5, will in addition support
  195.    fully secure one level Search and List operations of the root
  196.    (without the need to chain to the master DSAs). Suppliers at the
  197.    DANTE meeting did not realistically expect this to be in their
  198.    products much sooner than mid 1998.
  199.  
  200.    3.4 The long term solution, which relies on the DOP to establish
  201.    HOBs, is described in section 6 of this document.
  202.  
  203.    (Note. It is strongly recommended that non-specific subordinate
  204.    references should not be allowed in the root context for efficiency
  205.    reasons. This is directed by the European functional X.500 Standard
  206.    [ENV 41215] and the NADF standing document [NADF 7]. It is also
  207.    preferred by the International X.500 Standardized Profile [ISP
  208.    10615-6].)
  209.  
  210. 4     The Fast Track Solution
  211.  
  212.    4.1 The fast track solution provides root knowledge collection and
  213.    insecure List operations for first level DSAs, and will be of use to
  214.    systems which do not yet support the DOP for managing hierarchical
  215.    operational bindings. The fast track solution relies upon the DISP
  216.    with very few changes to the 1993 edition of the X.500 Standard.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Chadwick                      Experimental                      [Page 4]
  227.  
  228. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  229.  
  230.  
  231.    4.2 Each master first level DSA administrator will make available to
  232.    the administrator of the root DSA, sufficient information to allow
  233.    the root DSA to configure a subordinate reference to their DSA. In
  234.    the simplest case, this can be via a telephone call, and the
  235.    information comprises the access point of their DSA and the RDNs of
  236.    the first level entries that they master.
  237.  
  238.    4.3 Each master first level DSA enters into a shadowing agreement
  239.    with the root DSA, for the purpose of shadowing the root naming
  240.    context.
  241.  
  242.    The 1993 edition of the X.500 Standard explicitly recognises that
  243.    there can be master and shadow first level DSAs (X.501 Section 18.5).
  244.    (The 1988 edition of the X.500 Standard does not explicitly recognise
  245.    this, since it does not recognise shadowing.) A shadow first level
  246.    DSA holds a copy of the root context, provided by a master first
  247.    level DSA. In addition it holds shadow copies of the (one or more)
  248.    country entries that the master first level DSA holds. There is
  249.    currently an outstanding defect report [UK 142] on the 1993 X.500
  250.    Standard to clarify how a shadowing agreement is established between
  251.    first level DSAs. Once this has been ratified, the only additional
  252.    text needed in order to establish a shadowing agreement between the
  253.    root DSA and a master first level DSA is as follows:
  254.  
  255.    "When clause 9.2 of ISO/IEC 9594-9:1993 is applied to the
  256.    shadowing of the root context by a first level DSA from the root
  257.    DSA of a domain, then UnitOfReplication shall be set as follows:
  258.  
  259.    contextPrefix of AreaSpecification shall be null,
  260.  
  261.    replicationArea of AreaSpecification shall be set to
  262.                        SEQUENCE {
  263.         specificExclusions  [1]  SET OF {
  264.              chopBefore          [0]  FirstLevelEntry},
  265.         maximum             [3]  1 }
  266.  
  267.    where FirstLevelEntry is the RDN of a first level entry (e.g.
  268.    country, locality or international organisation) held by the
  269.    master first level DSA. specificExclusions shall contain one
  270.  
  271.    FirstLevelEntry for each first level entry mastered by this DSA,
  272.  
  273.    attributes of UnitofReplication shall be an empty SET OF SEQUENCE,
  274.  
  275.    knowledge of UnitofReplication shall be set to both (shadow and
  276.    master).
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Chadwick                      Experimental                      [Page 5]
  283.  
  284. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  285.  
  286.  
  287.    In other words, the information that will be replicated will be an
  288.    empty root entry plus all the attributes of the complete set of
  289.    subordinate DSEs of the root that are held in the root DSA excluding
  290.    the DSEs that the first level DSA already masters, plus a complete
  291.    set of subordinate reference."
  292.  
  293.    Note that the maximum component of replicationArea, although not
  294.    strictly necessary, is there for pragmatic reasons, for example,
  295.    where a community of users wish to use the root DSA to hold some
  296.    country specific entries.
  297.  
  298. 5     The Slower Track Solution
  299.  
  300.    5.1 The slower track solution provides support for fully secure one
  301.    level Search and List operations of the root in first level DSAs, and
  302.    comprises of two steps for HOB establishment between the root DSA and
  303.    master first level DSAs, using the DISP instead of the DOP. Step one,
  304.    described in 5.3, allows the root DSA to shadow first level entries
  305.    from a master first level DSA. Step two, described in 5.4, requires
  306.    either the root DSA administrator or the root DSA implementation to
  307.    massage the shadow first level entries so that they appear to have
  308.    been created by a HOB.  Managing the root context then continues as
  309.    in 4.3 above.
  310.  
  311.    5.2 This solution requires two significant defects in the ISO X.500
  312.    Standard to be corrected. Firstly, access control information needs
  313.    to be added to subordinate references in the DISP to allow the List
  314.    operation to work securely in a shadowed DSA. (The ACI are held in
  315.    both the subr DSE and in its subentry.) This requires a defect report
  316.    on the 93 X.500 Standard to be submitted. The text of this defect
  317.    report (that has been submitted to ISO) is given in Annex 2.
  318.  
  319.    Secondly, a new type of shadowing agreement will need to be
  320.    established between the supplier and consumer DSAs, to copy
  321.    subordinate entries rather than simply subordinate references, so
  322.    that one level Search operations can work in the shadowing DSA.  This
  323.    procedure should have been part of the 1997 edition of the X.500
  324.    Standard, but due to an omission is not. Consequently  a defect
  325.    report on the 1997 X.500 Standard has been submitted. The text of
  326.    this defect report is given in Annex 3.
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Chadwick                      Experimental                      [Page 6]
  339.  
  340. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  341.  
  342.  
  343.    5.3 The hierarchical operational binding between the root DSA and a
  344.    master first level DSA can be replaced by a set of "spot" shadowing
  345.    agreements, in which the first level DSA acts as the supplier, and
  346.    the root DSA as the consumer. Each "spot" shadowing agreement
  347.    replicates a first level entry which is mastered by the first level
  348.    DSA. The UnitOfReplication shall be set as follows:
  349.  
  350.    contextPrefix of AreaSpecification shall be FirstLevelEntry,
  351.  
  352.    replicationArea of AreaSpecification shall be set to
  353.                        SEQUENCE {
  354.         specificExclusions  [1]  SET OF {
  355.                        chopAfter [1]  {null} } }
  356.  
  357.    where FirstLevelEntry is the Distinguished Name of a first level
  358.    entry (e.g. country, locality or international organisation) held by
  359.    the master first level DSA.
  360.  
  361.    attributes of UnitofReplication shall be an empty SET OF SEQUENCE,
  362.  
  363.    knowledge of UnitofReplication shall be absent.
  364.  
  365.    5.4 The root DSA administrator, or the root DSA implementation
  366.    (suitably tailored) must then administratively update each shadowed
  367.    first level entry, so that they appear to have been created by a HOB,
  368.    i.e. it is necessary to add a subordinate reference to each one of
  369.    them. The subordinate reference will point to the respective master
  370.    first level DSA, and will comprise of a specific knowledge attribute,
  371.    and the DSE bit of type subr being set. The contents of the specific
  372.    knowledge attribute can be created from the contents of the supplier
  373.    knowledge attribute already present in the first level entry and
  374.    created by the "spot" shadowing agreement.
  375.  
  376. 6     The Long Term Solution
  377.  
  378.    6.1 Each master first level DSA will have a hierarchical operational
  379.    binding with the root DSA of the domain. Each master first level DSA
  380.    will master one or more first level entries. The hierarchical
  381.    operational binding will keep the appropriate subordinate
  382.    reference(s) (of category shadow and master) up to date, as well as
  383.    the other entry information that is needed for one-level Search
  384.    operations (such as access controls, and attributes used in
  385.    filtering).
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Chadwick                      Experimental                      [Page 7]
  395.  
  396. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  397.  
  398.  
  399.    Whilst hierarchical agreements are standardised, this particular
  400.    novel use of a HOB is not specifically recognised in the X.500
  401.    Standard.  Although the ASN.1 will support it, there is no supporting
  402.    text in the X.500 Standard. The following text supplements that in
  403.    the X.500 Standard, and describes how a first level DSA may have a
  404.    hierarchical operational binding with the root DSA of its domain.
  405.  
  406.    "Clause 24 of ISO/IEC 9594-4:1993 shall also apply when a first level
  407.    DSA is a subordinate DSA, and the root DSA of the domain is the
  408.    superior DSA. The naming context held by the superior (root) DSA is
  409.    the root naming context (or root context - the terms are synonymous)
  410.    of the domain. The root context consists of the root entry of the DIT
  411.    (which is empty) plus a complete set of subordinate DSEs (i.e. first
  412.    level DSEs), one for each first level naming context in the domain,
  413.    and their corresponding subentries.  The first level DSEs and their
  414.    subentries will contain, in addition to specific knowledge attribute
  415.    values of category master and shadow, sufficient attributes and
  416.    collective attributes, including access control information, to allow
  417.    List and one-level Search operations to be performed on them.
  418.  
  419.    In clause 24.1.2, the DistinguishedName of the immediateSuperior
  420.    component of HierarchicalAgreement shall be null."
  421.  
  422.    6.2 The ASN.1 of hierarchical operational bindings already allows any
  423.    attributes to be passed from the subordinate DSA to the superior DSA
  424.    (SubordinateToSuperior parameter in clause 24.1.4.2 of X.518).
  425.    However, a note in the 1993 edition of the X.500 Standard limits this
  426.    to those which are required to perform a List operation. In the 1997
  427.    edition of the X.500 Standard [DAM User] this restriction has been
  428.    removed, so that the attributes may also be used for a one-level
  429.    Search operation.
  430.  
  431.    1993 implementations of X.500 conforming to this RFC, shall also
  432.    remove this restriction.
  433.  
  434. 7     Security Considerations
  435.  
  436.    Security considerations are discussed in this memo in relation to
  437.    List and one-level Search operations. Each DSE has access control
  438.    information associated with it, and these must be adhered to when the
  439.    operations are performed.
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Chadwick                      Experimental                      [Page 8]
  451.  
  452. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  453.  
  454.  
  455. 8     Acknowledgments
  456.  
  457.    The author would like to thank DANTE, without whose funding this work
  458.    would not have been possible.
  459.  
  460.    The author would also like to thank Nexor, who reviewed the first
  461.    version of this document in detail and provided valuable comments,
  462.    and who first suggested the use of the DISP as a pragmatic solution
  463.    for HOB establishment until the DOP becomes widely implemented.
  464.  
  465.    The author would also like to thank John Farrell from the ISODE
  466.    Consortium, Andrew Palk   from Digital and Keith Richardson from ICL
  467.    who attended the DANTE meeting, and contributed to the technical
  468.    contents of the defect reports in Annexes 2 and 3.
  469.  
  470. 9     References
  471.  
  472.    [DAM User] Draft Amendments on Minor Extensions to OSI Directory
  473.    Service to support User Requirements, August 1995.
  474.  
  475.    [ENV 41215] "Behaviour of DSAs for Distributed Operations",
  476.    European X.500 Pre-Standard, Dec 1992
  477.  
  478.    [ISP 10615-6] "DSA Support of Distributed Operations", 5th draft
  479.    pDISP, Oct 1994
  480.  
  481.    [Mins] "Notes of DANTE meeting to discuss Managing the Root Naming
  482.    Context. 18 June 1996." D W Chadwick, circulated to IDS mailing
  483.    list
  484.  
  485.    [NADF 7] SD-7 "Mapping the North American DIT onto Directory
  486.    Management Domains", North American Directory Forum, V 8.0, Jan
  487.    1993
  488.  
  489.    [RFC 1276] Kille, S., "Replication and Distributed Operations
  490.    extensions to provide an Internet Directory using X.500", UCL,
  491.    November 1991.
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Chadwick                      Experimental                      [Page 9]
  507.  
  508. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  509.  
  510.  
  511.    [UK 142] Defect report number 142, submitted by the UK to ISO,
  512.    March 1995. (Proposed solution text included in Annex 1)
  513.  
  514.    [X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models and
  515.    Services
  516.    X.501 | 9594.Part 2 Models
  517.    X.511 | 9594.Part 3 Abstract Service Definition
  518.    X.518 | 9594.Part 4 Procedures for Distributed Operations
  519.    X.519 | 9594.Part 5 Protocol Specifications
  520.    X.520 | 9594.Part 6 Selected Attribute Types
  521.    X.521 | 9594.Part 7 Selected Object Classes
  522.    X.509 | 9594.Part 8 Authentication Framework
  523.    X.525 | 9594.Part 9 Replication
  524.  
  525. 10     Author's Address
  526.  
  527.    D W Chadwick
  528.    IT Institute
  529.    University of Salford
  530.    Salford
  531.    M5 4WT
  532.    England
  533.    Phone: +44 161 745 5351
  534.    Fax: +44 161 745 8169
  535.    E-mail: D.W.Chadwick@iti.salford.ac.uk
  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. Chadwick                      Experimental                     [Page 10]
  563.  
  564. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  565.  
  566.  
  567. Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T by
  568.    the UK
  569.  
  570. Defect Report 140
  571.  
  572.    Nature of Defect
  573.  
  574.    In section 24.1.4.2 it is defined that the SubordinateToSuperior
  575.    parameter of a HOB can pass an entryInfo parameter. This should
  576.    contain entryACI which may be used in the resolution of the List
  577.    operation.
  578.  
  579.    This is not correct as the prescriptive ACI from the relevant
  580.    subentries is also required in the superior DSA.
  581.  
  582.    Solution Proposed by Source
  583.  
  584.    It is proposed that the following is added to the
  585.    SubordinateToSuperior SEQUENCE of section 24.1.4.2 of X.518:
  586.  
  587.         subentries     [2] SET OF SubentryInfo OPTIONAL
  588.  
  589.    This is used to pass the relevant subentries from the subordinate to
  590.    the superior. This is similar to the way subentry information is
  591.    passed in the SuperiorToSubordinate parameter defined in 24.1.4.1.
  592.  
  593. Defect Report 142
  594.  
  595.    Nature of Defect
  596.  
  597.    The text which describes AreaSpecification in clause 9.2 of X.525 is
  598.    completely general. However, for the special case of replicating
  599.    first level knowledge references between first level DSAs, a
  600.    clarifying sentence should be added.
  601.  
  602.    Solution Proposed by Source
  603.  
  604.    In Section 9.2, under the ASN.1, after the description of area, and
  605.    before the description of SubtreeSpecification, add the sentence:
  606.  
  607.       "For the case where a DSA is shadowing first level knowledge from
  608.       a first level DSA, the contextPrefix component is empty."
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Chadwick                      Experimental                     [Page 11]
  619.  
  620. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  621.  
  622.  
  623. Annex 2 Defect Report on 1993 X.500 Standard for Adding full ACIs to
  624.       DISP for Subordinate References, so that Secure List Operation can
  625.       be performed in Shadow DSAs
  626.  
  627.    Nature of Defect:
  628.  
  629.    The List operation may be carried out in a superior DSA using
  630.    subordinate reference information, providing that the fromEntry flag
  631.    is set to false in the response. However, in order to do this
  632.    securely, complete access control information is needed for the RDN
  633.    of the subordinate entry. The existing text assumes that this is held
  634.    in entry ACI (e.g. see 9.2.4.1 c) or in prescriptive ACI held in
  635.    subentries above the DSE (e.g. see 9.2.4.1 b). In the case of a
  636.    subordinate reference, the prescriptive ACI may be held below the
  637.    DSE, if the subordinate reference points to a new administrative
  638.    point. The shadowing document needs to make it clear that this can be
  639.    the case, and needs to allow for this additional access control
  640.    information to be shadowed.
  641.  
  642.    A related defect report (140) has already suggested that this same
  643.    omission should be added to operational bindings.
  644.  
  645.    Solution Proposed by the Source:
  646.  
  647.    All the following changes are to X.525|ISO 9594-9.
  648.  
  649.    I) Insert the following text into 7.2.2.3, at the end of both the
  650.    second paragraph and the first sentence of the third paragraph (after
  651.    "appropriate knowledge"): "and access control information."
  652.  
  653.    II) Insert a new third paragraph into 7.2.2.3: "If  subordinate
  654.    knowledge is supplied, and the supplying DSE (of type subr) is also
  655.    of type admPoint, then the SDSE shall additionally be of type
  656.    admPoint and the administrativeRole attribute shall be supplied.  If
  657.    such a DSE has any immediately subordinate subentries containing
  658.    PrescriptiveACI relating to the administrative point, then they shall
  659.    also be supplied as SDSEs in the shadowed information.
  660.  
  661.    Note. A DSE can be of type subr and admPoint in a superior DSA, when
  662.    the naming context in the subordinate DSA is the start of a new
  663.    administrative area."
  664.  
  665.    III) Update figure 3 to show a subentry immediately below a
  666.    subordinate reference. The subentry contains prescriptiveACI and is
  667.    part of the shadowed information.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Chadwick                      Experimental                     [Page 12]
  675.  
  676. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  677.  
  678.  
  679.                             .
  680.     Etc.                   / \
  681.                           /   \
  682.                          /  o  \
  683.                         /  / \  \
  684.    Replicated          /  /   \  \
  685.    Area --------------/--/->   \  \
  686.                      /  /       \  \
  687.                     /  /         \  \
  688.                    /  /           \  \
  689.    Subordinate    /__/_____________\__\
  690.    knowledge--------/-> o   o    o  \
  691.                    /   /          \  \
  692.    Prescriptive---/-> o            o  \
  693.    ACI Subentries/                     \
  694.                    Unit of Replication
  695.  
  696.  
  697.                 Etc.
  698.                  o
  699.                 / \
  700.                /   \
  701.               /     \
  702.              /       \
  703.             /         \
  704.            /           \
  705.           /_____________\
  706.            o    o     o
  707.           /            \
  708.          o              o
  709.        Shadowed Information
  710.  
  711.                  ADDITIONS TO FIGURE 3, SECTION 7.2, X.525
  712.  
  713.    IV) Add supporting text to section 7.2 in the paragraph after Figure
  714.    3. Insert after the sentence "Subordinate knowledge may also be
  715.    replicated" the following sentences "Implicit in the Add supporting
  716.    text to section 7.2 in the paragraph after Figure 3.  Insert after
  717.    the sentence subordinate knowledge is the access control information
  718.    which governs access to the RDN of the subordinate knowledge. When
  719.    the subordinate entry is an administrative point in another DSA, then
  720.    part of this access control information may be held in
  721.    prescriptiveACI subentries beneath the subordinate knowledge."
  722.  
  723.    v) Add a new point d) to 9.2.4.1: "if subordinate knowledge (not
  724.    extended knowledge) is shadowed then any prescriptiveACI in
  725.    subordinate subentries shall also be copied."
  726.  
  727.  
  728.  
  729.  
  730. Chadwick                      Experimental                     [Page 13]
  731.  
  732. RFC 2120         Managing the X.500 Root Naming Context       March 1997
  733.  
  734.  
  735. Annex 3 Defect Report on 1997 X.500 Standard Proposing an Enhancement to
  736. the Shadowing Agreement in order to support 1 Level Searches in Shadow
  737. DSAs.
  738.  
  739.    Nature of Defect:
  740.  
  741.    The 1997 edition of the X.500 Standard has allowed, for reasons of
  742.    operational efficiency, one level Searches to be carried out in the
  743.    superior DSA, when the actual entries are context prefixes in
  744.    subordinate DSAs. The HOBs have been extended to allow this entry
  745.    information to be carried up to the superior DSA. Unfortunately, we
  746.    forgot to add the corresponding text to Part 9, so that shadow DSAs
  747.    are able to copy this additional information from the supplier DSA.
  748.    This defect report proposes the additional text for Part 9.
  749.  
  750.    Solution Proposed by the Source:
  751.  
  752.    All the following changes are to X.525|ISO 9594-9.
  753.  
  754.    I) Section 9.2, add a new subordinates parameter to
  755.    UnitOfReplication, viz:
  756.  
  757.    UnitOfReplication   ::= SEQUENCE{
  758.    area                AreaSpecification,
  759.    attributes          AttributeSelection,
  760.    knowledge           Knowledge OPTIONAL,
  761.    subordinates        BOOLEAN DEFAULT FALSE }
  762.  
  763.    subordinates is used to indicate that subordinate entries, rather
  764.    than simply subordinate references, are to be copied to the
  765.    consumer DSA. subordinates may only be TRUE if knowledge is
  766.    requested and extendedKnowledge is FALSE.
  767.  
  768.    II) Insert a new fourth paragraph (assuming previous defect for
  769.    List was accepted) into 7.2.2.3:
  770.  
  771.    "If subordinates is specified, then the supplier shall send
  772.    subordinate entries rather than subordinate references, and the
  773.    SDSEs will be of type subr, entry and cp. The subordinate entries
  774.    will contain attributes according to the attribute selection.
  775.  
  776.    In addition, if the supplying DSE is of type admPoint, then the
  777.    SDSE shall additionally be of type admPoint and the
  778.    administrativeRole attribute shall be supplied. All appropriate
  779.    subentries below the admPoint DSE shall also be supplied as SDSEs
  780.    in the shadowed information."
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Chadwick                      Experimental                     [Page 14]
  787.  
  788.