RFC 2120
Managing the X.500 Root Naming Context
RFC 2120: Managing the X.500 Root Naming Context 💖
okay bestie, this one is from March 1997, written by D. Chadwick at the University of Salford 🎀. It's an Experimental doc, which means it's a "try it and tell us" kind of thing. It was published under the Network Working Group, and it's all about how to manage the X.500 root naming context 🌸.
Status of this Memo 🎀
ok so this memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🙈. They want feedback and suggestions for improvement, and it can be shared as much as you like 💜.
Abstract ✨
okay so here's the vibe. The X.500 Standard [X.500 93] has this concept of first level DSAs, and their admins have to manage the root naming context together through bi-lateral agreements or other private arrangements that are totally outside the X.500 Standard 💅.
The NameFLOW-Paradise X.500 service already has a procedure for managing the root naming context. It currently uses Quipu proprietary replication and a root DSA 🦋. There are two big perks:
- firstly, it's way easier to coordinate root context info when there's one central point of administration 👑,
- secondly, one-level Search operations get a huge performance boost, because Quipu's distribution and replication doesn't have the restriction that exists in the 1988 and 1993 X.500 Standard 🔥.
The NameFLOW-Paradise project is moving toward the 1993 ISO X.500 Standard replication protocols, and they want to standardise the protocol and procedure for managing the root naming context based on 1993 X.500 Standard protocols 🌈. This would be useful for private X.500 domains and for the Internet X.500 public domain too ✨. Overall system performance must not be degraded during this transition 😭.
This document describes how to use the 1993 ISO X.500 Standard protocols to manage the root context 🧚. The ASN.1 is compatible with the X.500 Standard, but the actual parameter settings are supplementary to it 💖.
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............... 141. Introduction ✨
okay so the NameFLOW-Paradise service has its own proprietary way of managing the set of first level DSAs and the root naming context 💅. There's one root DSA called Giant Tortoise 🐢, and it holds all of the country entries. Those country entries get replicated to every country (first level) DSA and other DSAs via Quipu replication [RFC 1276] from the root DSA 🦋. As of June 1996, there were 770 DSAs replicating this info over the Internet 🔥. The root DSA isn't 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) 🙈. But it's seriously a big deal for both managing the root naming context and for the performance of one-level Searches of the root 👑. The performance goes up because each country DSA holds all the entry information of every country 💖.
Compare that to the 1988 X.500 Standard root context, which gets replicated to all the country DSAs 🌸. It only holds knowledge info and a boolean (to say whether the entry is an alias or not) for each country entry 🎀. That's enough for an insecure List operation, but not a one-level Search operation 💀. When access controls were added in the 1993 X.500 Standard, the root context info got bigger. It was supposed to hold the access controls for each country entry 🧚, but that was an error (this is the subject of defect report 140, see Annex 1) 🙈. A note in the X.500 Standard then restricted their use to the List operation, so it'd stay compatible with the 1988 edition 💅.
2. Migration Plan 🦋
The NameFLOW-Paradise service is migrating to products that conform to the X.500 Standard [X.500 93] right now ✨. It's essential to replace the Quipu replication protocol with the 1993 shadowing and operational binding protocols 🔥. But they can't lose the performance improvement they've gained for one-level Searches 👑.
They still plan to have one master root DSA 💖. This root DSA won't support user Directory operations via the LDAP, the DAP or the DSP 🌈. Instead, each country (first level) DSA can shadow the root context from this root DSA, using the DISP 🧚. So each first level DSA only needs one bi-lateral agreement, between itself and the root DSA 💅. That agreement makes sure the first level DSA keeps the root DSA up to date with its country level info, and in turn, the root DSA keeps the first level DSA up to date with the complete root naming context 🫶. When a new first level DSA comes online, it only needs to set up a bi-lateral agreement with the root DSA to get the complete root context ⭐.
This is way easier to manage than just a set of first level DSAs with no root DSA, which is what the ISO X.500 Standard suggests 😭. 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 online, it must set up agreements with all the existing first level DSAs 🙈. As the number of first level DSAs grows, the process becomes unmanageable 💔.
It's also important to increase the amount of info held about every country entry 🎀. That way, a one-level Search operation can happen in each first level DSA without needing to chain or refer the operation to all the other first level DSAs 🦋. (That's currently the case with an X.500 Standard conforming system.) 💅
3. Technical Solutions 🌈
3.1 The solution at first looks pretty straightforward and has two steps 🧚. First, create a root DSA and set up hierarchical operational bindings using the DOP between it and each master first level DSA 👑. Second, each master first level DSA sets up a shadowing agreement with the root DSA, to shadow the enlarged root context info 🔥. This way, each first level DSA can independently do List and one-level Search operations, and name resolution to all the other first level DSAs ✨.
3.2 Unfortunately, there are a bunch of complications that make it hard to implement this quickly 😭. First, few DSA suppliers have implemented the DOP 💀. Second, 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], several DSA suppliers were there 🌸. They came up with this pragmatic technical solution: a fast track partial solution and a slower track fuller solution 🎀. Both tracks use the shadowing protocol (DISP) for both steps, and neither relies on the DOP to establish HOBs 💖. The fast track solution, described in section 4, supports knowledge distribution of the root context, and the (insecure) List operation of the root's subordinates 🦋. The List operation is insecure because access control info won't be present in the shadow DSEs 🙈. (However, since it's generally thought that first level entries, especially country entries, are publicly accessible, this isn't considered 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, adds fully secure one-level Search and List operations of the root (without needing to chain to the master DSAs) 🧚. The suppliers at the DANTE meeting didn't realistically expect this 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 🌸. It's useful for systems that don't yet support the DOP for managing hierarchical operational bindings 🎀. It relies on the DISP with very few changes to the 1993 edition of the X.500 Standard ✨.
4.2 Each master first level DSA administrator makes enough info available to the root DSA administrator so the root DSA can set up a subordinate reference to their DSA 🦋. In the simplest case, this can be done via a phone call 📞, and the info is the access point of their DSA and the RDNs of the first level entries that they master 🧚.
4.3 Each master first level DSA sets up a shadowing agreement with the root DSA, to shadow 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 doesn't explicitly recognise this, since it doesn't recognise shadowing 🙈.) A shadow first level DSA holds a copy of the root context, provided by a master first level DSA 💅. On top of that, it holds shadow copies of the (one or more) country entries that the master first level DSA holds 💖. There's currently an outstanding defect report [UK 142] on the 1993 X.500 Standard to clarify how a shadowing agreement gets established between first level DSAs 🌈. Once that's ratified, the only extra text needed to set up a shadowing agreement between the root DSA and a master first level DSA is this 🧚:
"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 {
chopBefore [0] FirstLevelEntry},
maximum [3] 1 }okay so picking up right where we left off 💅 FirstLevelEntry is the RDN of a first level entry (think country, locality or international organisation) that's held by the master first level DSA. And specificExclusions SHALL contain one FirstLevelEntry for each first level entry mastered by this DSA 🌸
attributes of UnitofReplication SHALL be an empty SET OF SEQUENCE, and knowledge of UnitofReplication SHALL be set to both (shadow and master) 🎀
so in other words, the info that gets replicated is an empty root entry, plus all the attributes of the complete set of subordinate DSEs of the root that are held in the root DSA, excluding the DSEs the first level DSA already masters, plus a complete set of subordinate reference." ✨
Note that the maximum component of replicationArea is not strictly necessary, but it's there for pragmatic reasons. For example, a community of users might want to use the root DSA to hold some country specific entries 🌍
5. The Slower Track Solution 🐢
5.1. Overview 💖
The slower track solution gives you fully secure one level Search and List operations of the root in first level DSAs 🔐 It comprises two steps for HOB establishment between the root DSA and master first level DSAs, and it uses the DISP instead of the DOP. Step one (described in 5.3) lets the root DSA shadow first level entries from a master first level DSA. Step two (described in 5.4) requires either the root DSA administrator or the root DSA implementation to massage the shadow first level entries so that they look like they were created by a HOB 💅 Managing the root context then continues as in 4.3 above.
5.2. Two defects to fix 🐞
This solution needs two significant defects in the ISO X.500 Standard to be corrected 😭
First, access control information needs to be added to subordinate references in the DISP, so the List operation can work securely in a shadowed DSA. (The ACI are held in both the subr DSE and in its subentry.) This requires a defect report on the 93 X.500 Standard to be submitted. The text of this defect report, which has been submitted to ISO, is given in Annex 2.
Second, a new type of shadowing agreement will need to be established between the supplier and consumer DSAs. It has to copy subordinate entries rather than simply subordinate references, so that one level Search operations can work in the shadowing DSA. This procedure should have been part of the 1997 edition of the X.500 Standard, but due to an omission it isn't. So a defect report on the 1997 X.500 Standard has been submitted. The text of this defect report is given in Annex 3 🙈
5.3. Spot shadowing agreements 🌸
The hierarchical operational binding between the root DSA and a master first level DSA can be replaced by a set of "spot" shadowing agreements. In these, the first level DSA acts as the supplier and the root DSA acts as the consumer. Each "spot" shadowing agreement replicates a first level entry that is mastered by the first level DSA. The UnitOfReplication SHALL be set as follows:
contextPrefixofAreaSpecificationSHALL beFirstLevelEntry,replicationAreaofAreaSpecificationSHALL be set to the following:
SEQUENCE {
specificExclusions [1] SET OF {
chopAfter [1] {null} } }where FirstLevelEntry is the Distinguished Name of a first level entry (e.g. country, locality or international organisation) held by the master first level DSA.
attributesofUnitofReplicationSHALL be an emptySET OF SEQUENCE,knowledgeofUnitofReplicationSHALL be absent.
5.4. Making it look like a HOB 🎀
The root DSA administrator, or the root DSA implementation (suitably tailored), MUST then administratively update each shadowed first level entry so that it looks like it was created by a HOB. In other words, it's necessary to add a subordinate reference to each one of them 🧚 The subordinate reference points to the respective master first level DSA, and comprises a specific knowledge attribute, with the DSE bit of type subr set. The contents of the specific knowledge attribute can be created from the contents of the supplier knowledge attribute that is already present in the first level entry and was created by the "spot" shadowing agreement 💜
6. The Long Term Solution 👑
6.1. Hierarchical agreements, but make it long term 🌈
Each master first level DSA will have a hierarchical operational binding with the root DSA of the domain. Each master first level DSA will master one or more first level entries. The hierarchical operational binding keeps the appropriate subordinate reference(s) (of category shadow and master) up to date, along with the other entry information needed for one-level Search operations (such as access controls, and attributes used in filtering) ✨
Whilst hierarchical agreements are standardised, this particular novel use of a HOB is not specifically recognised in the X.500 Standard 😳 Although the ASN.1 supports it, there is no supporting text in the X.500 Standard. The following text supplements that in the X.500 Standard, and describes how a first level DSA may have a hierarchical operational binding with the root DSA of its domain:
"Clause 24 of ISO/IEC 9594-4:1993 SHALL also apply when a first level DSA is a subordinate DSA, and the root DSA of the domain is the superior DSA. The naming context held by the superior (root) DSA is the root naming context (or root context, the terms are synonymous) of the domain. The root context consists of the root entry of the DIT (which is empty) plus a complete set of subordinate DSEs (i.e. first level DSEs), one for each first level naming context in the domain, and their corresponding subentries. The first level DSEs and their subentries will contain, in addition to specific knowledge attribute values of category master and shadow, sufficient attributes and collective attributes, including access control information, to allow List and one-level Search operations to be performed on them.
In clause 24.1.2, the DistinguishedName of the immediateSuperior component of HierarchicalAgreement SHALL be null."
6.2. Attributes going up to the superior DSA 🦋
The ASN.1 of hierarchical operational bindings already allows any attributes to be passed from the subordinate DSA to the superior DSA (SubordinateToSuperior parameter in clause 24.1.4.2 of X.518). However, a note in the 1993 edition of the X.500 Standard limits this to those which are required to perform a List operation. In the 1997 edition of the X.500 Standard [DAM User] this restriction has been removed, so the attributes may also be used for a one-level Search operation 🙌
1993 implementations of X.500 conforming to this RFC SHALL also remove this restriction.
7. Security Considerations 🔐
Security considerations are discussed in this memo in relation to List and one-level Search operations. Each DSE has access control information associated with it, and these MUST be adhered to when the operations are performed 🚨 This one's serious, bestie, don't skip it 😤
8. Acknowledgments 🫶
The author would like to thank DANTE, without whose funding this work would not have been possible 💖
The author would also like to thank Nexor, who reviewed the first version of this document in detail, provided valuable comments, and first suggested the use of the DISP as a pragmatic solution for HOB establishment until the DOP becomes widely implemented 👏
The author would also like to thank John Farrell from the ISODE Consortium, Andrew Palk from Digital and Keith Richardson from ICL, who attended the DANTE meeting and contributed to the technical contents of the defect reports in Annexes 2 and 3 🥰
9. References 📚
[DAM User] Draft Amendments on Minor Extensions to OSI Directory Service to support User Requirements, August 1995.
[ENV 41215] "Behaviour of DSAs for Distributed Operations", European X.500 Pre-Standard, Dec 1992
[ISP 10615-6] "DSA Support of Distributed Operations", 5th draft pDISP, Oct 1994
[Mins] "Notes of DANTE meeting to discuss Managing the Root Naming Context. 18 June 1996." D W Chadwick, circulated to IDS mailing list
[NADF 7] SD-7 "Mapping the North American DIT onto Directory Management Domains", North American Directory Forum, V 8.0, Jan 1993
[RFC 1276] Kille, S., "Replication and Distributed Operations extensions to provide an Internet Directory using X.500", UCL, November 1991.
[UK 142] Defect report number 142, submitted by the UK to ISO, March 1995. (Proposed solution text included in Annex 1)
[X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models and Services X.501 | 9594.Part 2 Models X.511 | 9594.Part 3 Abstract Service Definition X.518 | 9594.Part 4 Procedures for Distributed Operations X.519 | 9594.Part 5 Protocol Specifications X.520 | 9594.Part 6 Selected Attribute Types X.521 | 9594.Part 7 Selected Object Classes X.509 | 9594.Part 8 Authentication Framework X.525 | 9594.Part 9 Replication
10. Author's Address 🧳
D W Chadwick IT Institute University of Salford Salford M5 4WT England Phone: +44 161 745 5351 Fax: +44 161 745 8169 E-mail: D.W.Chadwick@iti.salford.ac.uk
Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T by the UK 🇬🇧
Defect Report 140 🐛
Nature of Defect
In section 24.1.4.2 it is defined that the SubordinateToSuperior parameter of a HOB can pass an entryInfo parameter. This should contain entryACI, which may be used in the resolution of the List operation.
This is not correct, as the prescriptive ACI from the relevant subentries is also required in the superior DSA 😬
Solution Proposed by Source
It is proposed that the following is added to the SubordinateToSuperior SEQUENCE of section 24.1.4.2 of X.518:
subentries [2] SET OF SubentryInfo OPTIONALThis is used to pass the relevant subentries from the subordinate to the superior. It's similar to the way subentry information is passed in the SuperiorToSubordinate parameter defined in 24.1.4.1 ✨
Defect Report 142 🌟
Nature of Defect
The text which describes AreaSpecification in clause 9.2 of X.525 is completely general. However, for the special case of replicating first level knowledge references between first level DSAs, a clarifying sentence should be added 🙏
Solution Proposed by Source
In Section 9.2, under the ASN.1, after the description of area and before the description of SubtreeSpecification, add the sentence:
"For the case where a DSA is shadowing first level knowledge from a first level DSA, the contextPrefix component is empty."
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 ✨
Nature of Defect 🔍
okay so the List operation may be run in a superior DSA using subordinate reference info 🌸 as long as the fromEntry flag is set to false in the response. but to do that securely, you need the complete access control info for the RDN of the subordinate entry 🔐. the current text assumes that lives in entry ACI (see 9.2.4.1 c) or in prescriptive ACI held in subentries above the DSE (see 9.2.4.1 b). but for a subordinate reference, the prescriptive ACI can sit below the DSE if the subordinate reference points to a new administrative point 😳. the shadowing doc needs to say clearly that this can happen, and it needs to let that extra access control info get shadowed too 💅
a related defect report (140) already suggested this same omission should be fixed in operational bindings 🦋
Solution Proposed by the Source 🎀
all of these changes are to X.525|ISO 9594-9 💖
I) put this text into 7.2.2.3, at the end of both the second paragraph and the first sentence of the third paragraph (right after "appropriate knowledge"):
"and access control information."II) add a brand new third paragraph to 7.2.2.3:
"If subordinate
knowledge is supplied, and the supplying DSE (of type subr) is also
of type admPoint, then the SDSE shall additionally be of type
admPoint and the administrativeRole attribute shall be supplied. If
such a DSE has any immediately subordinate subentries containing
PrescriptiveACI relating to the administrative point, then they shall
also be supplied as SDSEs in the shadowed information."
Note. A DSE can be of type subr and admPoint in a superior DSA, when
the naming context in the subordinate DSA is the start of a new
administrative area.III) update figure 3 so it shows a subentry sitting right below a subordinate reference 🧚. that subentry holds prescriptiveACI and is part of the shadowed information ✨
.
Etc. / \
/ \
/ o \
/ / \ \
Replicated / / \ \
Area --------------/--/-> \ \
/ / \ \
/ / \ \
/ / \ \
Subordinate /__/_____________\__\
knowledge--------/-> o o o \
/ / \ \
Prescriptive---/-> o o \
ACI Subentries/ \
Unit of Replication
Etc.
o
/ \
/ \
/ \
/ \
/ \
/ \
/_____________\
o o o
/ \
o o
Shadowed Information
ADDITIONS TO FIGURE 3, SECTION 7.2, X.525IV) add supporting text to section 7.2 in the paragraph after Figure 3 🌈. this is the exact wording from the source, garbled bits and all:
Insert after the sentence "Subordinate knowledge may also be
replicated" the following sentences "Implicit in the Add supporting
text to section 7.2 in the paragraph after Figure 3. Insert after
the sentence subordinate knowledge is the access control information
which governs access to the RDN of the subordinate knowledge. When
the subordinate entry is an administrative point in another DSA, then
part of this access control information may be held in
prescriptiveACI subentries beneath the subordinate knowledge."v) add a new point d) to 9.2.4.1:
"if subordinate knowledge (not
extended knowledge) is shadowed then any prescriptiveACI in
subordinate subentries shall also be copied."the fix here is basically: if the subordinate knowledge comes with its access control, the prescriptive ACI in those subordinate subentries has to come along for the ride too 🫶
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. 🦋
Nature of Defect 🧐
so the 1997 edition of X.500 allowed one level Searches to run in the superior DSA, for operational efficiency 🚀. this happens when the actual entries are context prefixes in subordinate DSAs. the HOBs got extended so this entry info can be carried up to the superior DSA 💜. the problem? nobody added the matching text to Part 9 😭. so shadow DSAs can't copy this extra info from the supplier DSA. this defect report proposes that missing text for Part 9 🎀
Solution Proposed by the Source 💖
all of these changes are to X.525|ISO 9594-9 ✨
I) in Section 9.2, add a new subordinates parameter to UnitOfReplication, like this:
UnitOfReplication ::= SEQUENCE{
area AreaSpecification,
attributes AttributeSelection,
knowledge Knowledge OPTIONAL,
subordinates BOOLEAN DEFAULT FALSE }so, subordinates tells the consumer DSA that subordinate entries, not just subordinate references, should be copied 🫶. subordinates may only be TRUE if knowledge is requested and extendedKnowledge is FALSE 🌸
II) insert a new fourth paragraph into 7.2.2.3 (this assumes the earlier defect for List was accepted) 🌈:
"If subordinates is specified, then the supplier shall send
subordinate entries rather than subordinate references, and the
SDSEs will be of type subr, entry and cp. The subordinate entries
will contain attributes according to the attribute selection.
In addition, if the supplying DSE is of type admPoint, then the
SDSE shall additionally be of type admPoint and the
administrativeRole attribute shall be supplied. All appropriate
subentries below the admPoint DSE shall also be supplied as SDSEs
in the shadowed information."bestie, the whole point is that shadow DSAs can finally keep up with the supplier when it comes to one level Searches 👑
📦 where this page comes from
- ietf: rfc2120 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms