OpenDJ and The OID Directory I-D Series - A Case Study

[JesseCoretta]

OpenDJ and The OID Directory I-D Series - A Case Study

• Author: Jesse Coretta ^[EMAIL]
• Date: September 9, 2024

Introduction

This study covers the highlights of an implementation of the EXPERIMENTAL OID Directory I-D series using OpenDJ -- an open source Java-based LDAPv3 compliant directory service. ^{[SITE], [REPO]}

• Disclaimers
  • Unapproved Internet-Draft
  • Not an Endorsement
• About this study
  • Target Audience
  • Scope
  • Why OpenDJ?
  • Methodology
    • Data Collection
    • Environment and Tools
• Implementation
  • Installation
  • Schema Generation and Updates
  • Root DSE amendments
  • Indices
  • Content Load
    • Registrations
    • Registrants
• Post-implementation challenges
  • DN Complexity
  • Navigation
  • Content Efficiency
  • Performance
• Results
• Bug Reports
• Literature

Disclaimers

Unapproved Internet-Draft

As stated throughout all materials related the series ad nauseam, the concepts described and demonstrated here are for EXPERIMENTAL and TESTING use only. The OID Directory I-D series is not yet approved by any formal body, nor should it be used in any mission-critical capacity at this time.

Absolutely NO WARRANTY is implied.

Not an Endorsement

This study is not an endorsement of OpenDJ, nor its parent company "3A Systems, LLC.", in any way.

Inquiries

If you have questions, comments, concerns, etc., please contact the author directly.

About this study

Target audience

This document is written in a sort of "directory professional shorthand", thus it is intended for those individuals with a decent understanding of the bulk of the aforementioned literature and are comfortable with recent versions of OpenDJ.

Specifically, seasoned directory professionals of varying strata -- such as product developers, subject matter experts, architects, system administrators and operators -- are considered ideal audience members. Additionally, individuals who have, at some point, had to maintain and/or navigate large OID registration sets (by any means) are also applicable.

To prevent this study from becoming prohibitively long, basic minutia such as procedures for installing Java, managing OpenDJ indices, coping with SELinux, etc., are not covered, nor is the subject of directory services approached in an "ABC" or "ELI5" context.

Scope

The scope of this study is as follows:

• Basic overview of DSA and DIB setup
• Engagement and description of select server-side features deemed critical
• Creation, maintenance and interrogation of relevant RA DIT content
• Overview of challenges, pain-points and the means for their mitigation

Given a finished implementation, the following secondary objectives will be possible:

• Allow for proof (or disproof!) of concept and general viability with regards to potential real-life implementations of the proposed standard
• Allow for design flaws or perceived shortcomings within the proposed standard to be more easily fleshed-out than by virtue of theory alone
• To simply get the point of the proposed standard across to LDAP professionals who don't necessarily want to read 130+ pages of an extremely dry technical document series related to esoteric subject matters

While this document can aid those with a cursory interest in "the nuances of OID maintenance" (perhaps limited to private allocations only), it caters more to large and potentially public implementations simply because those scenarios will be far more likely to expose flaws (or at least shortcomings) in the overall philosophy of the series. Only with the approval of such institutions and organizations can this I-D series ever come to fruition.

It is also worth mentioning that large scale registries of this form have always represented the primary intended use case of the I-D series. ^{[RADIR § 1.4]}

Methodology

Data collection

Data samples related to this study are derived from numerous sources. Among them:

• ITU-T Rec. X.660 ^[DOC]
• IANA SMI-Registry ^[SITE]
• OID-Info ^[SITE]
• Alvestrand ^[SITE]
• The OID Directory I-D series ^{[SITE], [RADIR § 1.6], [RASCHEMA § 2], [RADIT § 3]}

The collected samples comprise the overall (example) "RA DIT" structure, from root contexts to various leaf registrations. Note that only public registrations of a particularly well-known nature, and registrations derived from the I-D series itself, were chosen. No private, proprietary or privileged registration content is included.

These files can be accessed through their respective ^[TYPE] links throughout this study, and will be used as a starting point for DIT content assembly. Some assembly is required.

Environment and tools

The environment for this study is as follows:

• Native Linux OS (Ubuntu 22, AMD64, no virtualization)
• Hardware: Dell Inspiron 3511 (i5-1135G7, 32GB DDR4 RAM)

OpenDJ (>=v4.8.1) is installed within /opt/opendj, which is its default install root. Beyond the tools included with OpenDJ, such as /opt/opendj/bin/control-panel and the included ldap<X> binaries, additional tools leveraged in this case study are as follows:

• oiddir-schema-extract.py
• OpenLDAP's ldap-utils package for CLI DUA interaction (due to popularity, and for compatibility checks)
• Apache's "Directory Studio" application for GUI DUA (secondary) interaction
• vim for configuration edits and manual creation of new text-based files

This study assumes that either or both of the above directory clients have been installed on a system from which LDAP operations, such as Search, Modify, Add, et al, are to be conducted.

Additionally, it is assumed the system on which the 99-oiddir.ldif file is generated (not necessarily used) already has an active python3 installation available, which is required by the oiddir-schema-extract.py utility.

Implementation

Installation

OpenDJ installation was completed using a download of the desired release ^[RELEASES] (.deb) followed by:

$ sudo dpkg -i <deb file>

Next, an non-interactive text setup process was triggered.

$ sudo /opt/opendj/setup --cli \
          --backendType je \
          --baseDN o=rA \
          --ldapPort 389 \
          --adminConnectorPort 4444 \
          --rootUserDN cn=Registration\ Authority \
          --rootUserPassword secret \
          --doNotStart \
          --no-prompt \
          --noPropertiesFile

Note

Root privileges may not necessarily be required.

If the --ldapPort value is not privileged (>1023), and the OpenDJ install root does not require root privileges for reading and writing files, the setup process can likely omit use of privilege escalation altogether.

Adjust the setup command as needed, but plan your changes carefully and consistently.

For a fresh install, the above command should trigger the creation of several files and directories below /opt/opendj, namely the config directory. This directory is particularly important, as it contains the config.ldif file and a schema subdirectory in which we will deposit the schema definitions set forth through the I-D series.

Though the above setup process was instructed not to initialize the service upon completion, it may be wise to check if it is running and stop the service if needed.

$ ps -ef | grep opendj
$ sudo /opt/opendj/bin/stop-ds

For an implementation that is to exist separately but in parallel to one or more other DITs on the same DSA, it is recommended one simply create a new backend instead, and scope their ministrations to that context accordingly, for instance:

sudo /opt/opendj/bin/dsconfig \
    create-backend \
    -D "cn=Registration Authority" \
    -w secret \
    --backend-name=rA \
    -t je \
    --set=base-dn:o=rA \
    --set=enabled:true \
    --no-prompt \
    --trustAll

However, for safety reasons, it is strongly recommended that this study be tested separately, and NOT using production resources of any kind.

Schema Generation and Updates

To use the oiddir-schema-extract.py ^[UTIL] python script, a copy of the most recent revision of the schema specifications ^[RASCHEMA] is required.

The script operates by way of applying a regular expression statement to the text form of the document. The result is a clean extraction of the needed definitions from the appropriate sections ^{[RASCHEMA § 2.3], [§ 2.5], [§ 2.7]}, thus producing a complete OID Directory schema, ready for integration. An alternative to using this script would be to simply extract all 123 definitions by hand.

Download the text form of the above document and place it anywhere (here we use ./ for simplicity). Once the aforementioned script is copied to a python3-enabled system, run:

$ chmod 0555 ./oiddir-schema-extract.py
$ ./oiddir-schema-extract.py -t opendj -f ./draft-coretta-oiddir-schema-NN.txt > 99-oiddir.ldif

... where NN signifies the two digit revision number, e.g. 02. The output will be written to 99-oiddir.ldif.

Tip

Use -n to omit newlines and hanging indents

Use -x to omit eXtensions

Use -s to leverage OpenDJ's "custom ldapSyntaxes" feature. Doing so can address many concerns regarding suitable value constraints for critical attribute types ^{[RASCHEMA § 2.1]} by replacing the standard LDAP syntaxes used by those attribute types with custom-tailored expression matchers based directly on the ABNF productions set forth in the draft.

When generated, place the resultant 99-oiddir.ldif file within /opt/opendj/config/schema on the appropriate OpenDJ server(s).

Though this schema file is not confidential, it need only be owned and readable by the POSIX service account that runs the OpenDJ service, and (optionally) any POSIX group that contains other users -- whether automated or human -- tasked with managing the system in a manner which requires select privileges for such content. YMMV.

Warning

DIT Structure Rule incorporation advisory

See Section 16.5.4 of the OpenDJ administration guide for important considerations with regards to implementing dITStructureRules definitions within an established DIT vs. an empty DIT.

nameForms definitions NOT referenced by any dITStructureRules instances can be freely implemented with no complications.

Root DSE amendments

The OID Directory I-D series introduces so-called "autoconfigration" abstracts, allowing optimized clients and scripts to "self-configure" ^{[RADUA § 2.2.2]} using optimal settings advertised ^{[RADSA § 2.3.6]} by the RA DSA meant to guide subsequent interactions with an RA DIT efficiently.

Alternatively, these settings may simply be consumed by individuals directly for manual input into any relevant applications.

For this to work, an edit needs to be made to the OpenDJ configuration LDIF to add select attribute types extended by way of the "rADUAConfig" AUXILIARY class.

On or around line 1532 of /opt/opendj/config/config.ldif (as of >=v4.8.0), the cn=Root DSE,cn=config entry should be modified as indicated ^[LDIF]. Depending on system configuration, the file may require root privileges to access and modify.

Be sure NOT to remove any of the Root DSE's preexisting values.

Tip

No RA DUA? Skip the Root DSE edits!

For those that are following along using their own environment, the Root DSE amendments may be skipped entirely if no RA DUAs, simple client scripts or even personnel are present to consume these settings.

Lack of these settings has no impact upon the behavior of the RA DSA itself. But, keep in mind that lack of such settings will result in unpredictable and inefficient user behavior should clients become part of the equation at some point. This may become especially problematic if the users also intend to make changes to DIT content.

Indices

Registration-specific performance indices ^[FILES] SHOULD be implemented alongside the factory-default OpenDJ indices within the same file edited during the last section, /opt/opendj/config/config.ldif. Be sure to organize them with any preexisting indices.

Note that performance indices here will mainly only benefit clients who are performing filter-based searches of the specified Attribute Types. While certain filters are necessary during certain allocation phases, as well as for administrative activities, this is generally discouraged as a matter of "general policy". In short, filters should not be needed 90% of the time.

On the other hand, implementing indices for unused types -- a practice referred to as negative indexing -- can speed up response times for searches targeting type instances that do not exist in the directory.

For example, if the directory does not contain "iRI" values, and a user crafts a search filter to target instances of this type, configuring an "iRI" search index will return 0 entries faster, thus leading to wasted resources (readers) being freed sooner.

As such, ones indexing policy should reflect the DIT content policies put in place in service to the I-D series, and should allow for periodic re-tuning based on typical user activities observed in monitoring systems and logs.

Content Load

Starting from the very top, we'll add this simple LDIF ^[FILE], which defines the top-level o=rA suffix and two (2) immediate children -- ou=Registrations and ou=Registrants.

Note

Depending on preference, LDIF content may be submitted via ldapadd, or by way of an offline import-ldif run. This study has no specific position on the manner in which DIT content is loaded, so long that all intended entries are present and intact within the directory.

Registrations

First, we'll tackle the ou=Registrations,o=rA directory branch, which serves as the root context for all OID allocations. Descending exactly one (1) level below this context should yield any or all of the official root arcs linked below as directory entries. Each of these root arcs bears a single RDN number form ("n") -- of which there can only be three (3) values at this hierarchy:

• ITU-T (n=0,ou=Registrations,o=rA) ^[FILE]
• ISO (n=1,ou=Registrations,o=rA) ^[FILE]
• Joint-ISO-ITU-T (n=2,ou=Registrations,o=rA) ^[FILE]

These are the only roots that should ever exist within an RA DIT -- identified not only by the specific naming conventions and values of these entries but also based on the presence of the "rootArc" STRUCTURAL class. No other form of entry shall ever bear instances of this class under any circumstances.

Subsequent non root allocations, bearing the "arc" STRUCTURAL class instead, are organized based on the leading numerical component of the effective "dotNotation" or "aSN1Notation" value ultimately corresponding to one (1) of the aforementioned roots. This manner of organization is common to both of the standard directory models, at least at this level of the hierarchy.

For example, the allocation for "Identified-Organization" (1.3) would manifest as a new "registration" entry (n=3,n=1,ou=Registrations,o=rA) directly subordinate to the ISO "1" (n=1,ou=Registrations,o=rA) root entry.

Similarly, a child of "Identified-Organization", such as the registration for the "Department of Defense" (1.3.6), would manifest as a similarly-composed direct subordinate entry, bearing a DN of n=6,n=3,n=1,ou=Registrations,o=rA.

Note

Take time to add (or simply amass) more data!

Using other files present within the above LDIF example entries ^[FILES], or by browsing public OID registry sites across the web, continue to build-out your tree as demonstrated thus far.

Additionally, take a look at IANA's SMI Numbers registry ^[SITE], and make an attempt to marshal their downloadable data files into proper LDIF entries. This may be an especially important resource for some readers, as there are many RANGED allocations ^[LDIF] present, which make use of the "registrationRange" type.

Warning

Never edit registrations that are not under your authority!

During the inevitable online registry browsing and content incorporation users will embark upon, informational errors may be perceived. These may include spelling errors, dead email addresses and other such imperfections.

DO NOT ATTEMPT TO REMEDY THESE ISSUES UNILATERALLY. Instead:

1. OPEN A TICKET WITH, OR OTHERWISE CONTACT, THE PROPER REGISTRANTS (AUTHORITIES)
2. INCORPORATE THIS CONTENT AS-IS, OR DELAY ITS INCORPORATION UNTIL SUCH TIME THAT THE AMENDMENT IS OFFICIATED

Furthermore, regarding content for which a user IS authoritative -- if errors for ones own registration(s) are found, it is critical that a remedy or a notice is propagated to all registries in which the flawed content presently resides. OID registries serve little purpose if they contain and serve conflicting data with inconsistent gaps.

Registrants

All registrant content is stored within ou=Registrants,o=rA. Also known as "authorities", registrants are individuals, documents, entities or bodies to which one or more OIDs have been allocated OR are responsible for in some way.

There are three (3) such authority forms, as defined in ITU-T Rec. X.660 ^[DOC]:

• First (and/or "previous") authorities
• Current authorities
• Sponsors

This I-D series implements two (2) styles of authority management: DEDICATED [^{RADIT § 3.2.1.1.1 or COMBINED [RADIT § 3.2.1.1.2].}

For the purposes of this study, the DEDICATED ^{[RADIT § 3.2.1.1.1]} style is used, which involves use of the "registrant" STRUCTURAL class. This choice has the merit of being the more scalable solution.

At the risk of oversimplification, within the terms of this I-D series, "registrant" entries are basically just address book entries. Most seasoned LDAP professionals testing an implementation of this series will regard the overall management of these entries to be among the easier elements in the series.

Each "registrant" entry should have at least one (1) of the following AUXILIARY classes, each of which extend a variety of contact-focused Attribute Types:

• "firstAuthorityContext"
• "currentAuthorityContext"
• "sponsorContext"

All OIDs have registrants of some form. For example, the IANA PEN number ^[SITE] "56521" which forms the complete OID "1.3.6.1.4.1.56521" allocated to the author of the I-D series (and this study), making her the "registrant".

The "registrant" entry in the above LDIF is referenced by the associated "registration" entry by way of a "firstAuthority" DN value. When composing "registrant" entries, users may also leverage "currentAuthority" and "sponsor", as well as the COLLECTIVE variants of these types, if supported in the given environment.

As shown in the "registration" LDIF, a "registrant" entry can also link back to any number of "registration" entries using the "seeAlso" Attribute Type, thereby facilitating reverse authority lookups through bidirectional references between "registration" and "registrant" entries alike.

While this is not an exciting feature, it can be extremely valuable in directory audit scenarios, and negates the need for potentially costly reverse searches, such as:

(|(firstAuthority=<regID>)(c-firstAuthority=<regID>)(currentAuthority=<regID>)(c-currentAuthority=<regID>)(sponsor=<regID>)(c-sponsor=<regID>))

The downside of the "seeAlso" approach is the effort required to maintain those necessary instances, as well as a proportional increase of storage utilization.

The manner in which "registrant" entries are stored within the ou=Registrants,o=rA branch is of little concern. These entries can be divided and organized within dedicated OUs in any manner desired. This is because, ultimately, they are linked unambiguously by their DN, allowing direct access to the associated entry regardless of its location.

The manner in which "registrant" entries are named, however, is a point of significant concern. Depending on the size of the implementation, managing a larger number of authorities is a daunting task. Therefore, use of the "registrantID" type is required by entries of this class, and is the recommend RDN type.

In most cases, the ideal value for instances of the "registrantID" type are UUIDs. However, authorities of significant note, such as a formal RFC or an IESG Study Group, MAY be named according to that official designation as opposed to a random generated value, e.g.:

• registrantID=SG17,ou=Registrants,o=rA

... versus ...

• registrantID=a467c6b2-20d4-4120-8af2-f8cfbd80b74e,ou=Registrants,o=rA

... although the safest approach is always to use randomly generated values as shown.

Tip

Test implementations of a purely internal nature, such as an in-company registry housing only private allocations, may implement any "registrant" naming convention seen fit.

Post-implementation challenges

At this point, users following along may have amassed quite a few entries for their RA DIT. With an ever-increasing number of entries, certain challenges come to light, each of which are covered in the following subsections.

DN Complexity

With respect to interaction with an RA DIT, relying upon a traditional LDAP CLI utility, such as OpenLDAP's ldap-utils package or OpenDJ's included tools will be extremely tedious, mainly due to the nature of how DNs are formed within implementations of this series.

Although necessary, the DNs of "registration" entries -- particularly in "3D" implementations ^{[RADIT § 3.1.3]} like this -- are long and very prone to typographical errors. And, worse yet, the OIDs described within a DN will manifest in reverse order to accommodate the descending structure of DNs. 😵

For example, the OID:

• 1.3.6.1.4.1.56521

... is equivalent to the DN:

• n=56521,n=1,n=4,n=1,n=6,n=3,n=1,<REGISTRATION BASE>

Under these conditions, manual RA DIT navigation quickly becomes a frustrating exercise. And, unfortunately, using a graphical LDAP client application -- such as Apache's Directory Studio -- will only ease the tedium slightly.

To help mitigate this difficulty, at least from a CLI standpoint, two (2) Bash-based OID/DN converters ^[SCRIPT] have been devised.

To offer a simple demonstration, consider that instead of doing this:

$ ldapsearch -xb n=94,n=3,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA -s base

... one can instead use oid2dn to convert an OID to a DN, making the target MUCH easier to read:

$ ldapsearch -xb $(oid2dn 1.3.6.1.4.1.56521.101.2.3.94) -s base

The reverse also works, converting a DN to an OID using dn2oid:

$ dn2oid n=94,n=3,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
1.3.6.1.4.1.56521.101.2.3.94

To utilize these functions, simply source the Bash script linked above from your local .bashrc or .bash_profile file.

Be sure to set (export) the REGISTRATION_BASE environment variable with the appropriate "rARegistrationBase" DN. Otherwise, the default ou=Registrations,o=rA value will apply.

See also the Java, Javascript, Go, Python and C variants of the above Bash script.

Alternatively, for those looking for a full-fledged framework to aid in such matters, there is an EXPERIMENTAL Go-based SDK which implements various subsets of the OID Directory I-D series: go-radir ^{[REPO], [GODOC]}

Navigation

Using conventional means, navigating an extensive OID tree expressed as LDAP content is very, very tedious. To assist clients in effective navigation, as well as to allow administrators to enforce the sequential (number form) association between sibling "registration" entries, eleven (11) Spatial Attribute Types were introduced in the series:

• "topArc" (or, COLLECTIVE "c-topArc")
• "supArc" (or, COLLECTIVE "c-supArc")
• "minArc" (or, COLLECTIVE "c-minArc")
• "maxArc" (or, COLLECTIVE "c-maxArc")
• "leftArc"
• "rightArc"
• "subArc"

Generally speaking, users interact with OIDs in an "TOP/UP/DOWN/LEFT/FAR-LEFT/RIGHT/FAR-RIGHT" context using popular OID management applications, or slick interfaces touted by certain OID registry sites. The types shown above implement a feasible means for implementing effective translation between adjacent or ancestral "registration" entries in a similar manner.

With the exception of COLLECTIVE attributes, the above spatial types are extended by way of the "spatialContext" AUXILIARY class. An RA DUA, encountering an entry bearing this class, is able to take certain measures:

• Shift to the previous (left) or next (right) sibling
• Leap to the minimum (far left) or maximum (far right) sibling
• Descend into, or enumerate, immediate subordinate(s) (down)
• Ascend to the root of the ancestry (top)

See also Spatial References ^{[RADIT § 3.2.4.19]}.

Content Efficiency

Continuing the topic of the previous section, Navigation, unless the RA DIT in question is fairly small, as convenient as these "spatialContext"-extended types are, it may still be a considerable effort to effectively implement these associations (and even more effort to ensure they remain accurate). Consider a horizontal set of siblings subordinate to the OID "1.3.6.1.4.1.56521.999", numbered "0" through "9999":

[0][1][2][3]...[9996][9997][9998][9999]

This means that if a reference to the parent entry "1.3.6.1.4.1.56521.999" is desired, it will involve the direct modification of all 10000 of those entries to add a "supArc" DN reference to n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA. That is a LOT of churn for something so simple!

We face the same problem again with regards to the "topArc" type, which allows a vertical association between the bearer and the absolute root DN (in this case, n=1,ou=Registrations,o=rA). 10000 times. 😮

And yet again, same problem applies to the "minArc" and "maxArc" types, which respectively define the minimum and maximum number forms (or "extremes") within a set of siblings. That is two values x 10000 entries. 😱

So, to recap, for this single set of siblings, there are 40000 values needing to be set. And we're not even done yet.

This is where Collective Attributes ^[RFC3671] tend to shine in directory services. Given specific satisfied criterion (which we'll cover later), a preset Collective value can be stored in a "subentry" instance bearing the "collectiveAttributeSubentry" AUXILIARY class, and then linked -- not written -- to any qualifying entries in "virtual fashion".

Consider the scenario above, where we need to assign the following to 10000 entries:

• minArc: n=0,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
• maxArc: n=9999,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
• supArc: n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
• topArc: n=1,ou=Registrations,o=rA

It is a good idea to decide on a "subentry" naming convention, as large implementations may end up creating a great many of these kinds of entries. Ideally, the "subentry" should be named according to the "identifier" assigned to the parent (n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA). But if the parent in question lacks such a name, use of "description" content or even "unicodeValue" may be necessary. Failing that, it is up to the directory architect(s) involved.

For instance, the "registration" for "1.3.6.1.4.1.56521.999" were named "xyzRegistration", our new "subentry" should manifest as follows:

dn: cn=xyzRegistration,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
objectClass: extensibleObject
objectClass: subentry
objectClass: top
objectClass: collectiveAttributeSubentry
c-minArc;collective: n=0,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
c-maxArc;collective: n=9999,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
c-supArc;collective: n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
subtreeSpecification: {minimum 1, maximum 1}

The Collective values held within this single entry will be applied to any number of "subtreeSpecification"-qualifying entries.

Warning

ITU-T Rec. X.501, clause 14.2 requires use of "cn" for all subentries.

But due to an implementation flaw in OpenDJ <=v4.8.1, subentries ^{[RFC 3672]} are wrongly subjected to DIT structure rule and name form governance where it should NOT be. This will be an issue for DITs which employ both collective attributes and DIT structure rules, and may or may not be resolved in a future release of OpenDJ. See the section on Working With DIT Structure Rules & Name Forms
in the OpenDJ administrators guide for details on mitigating this issue.

In order to utilize Collective Attributes, the types involved must be labeled COLLECTIVE within their schema of origin. Also note that OpenDJ requires use of the ;collective attribute tag, which MUST be present in "subentry" instances as shown.

For conformity with recommended procedures relating to collective attributes, all types defined within the I-D series utilize the recommended c- prefix to allow easy identification of COLLECTIVE types.

With the exception of "[topArc](https://datatracker.ietf.org/doc/html/draft-coretta-oiddir-schema#section-2.3.23" (or what will become "c-topArc", all of these newly added instances should really only apply to the local horizontal sibling range (for instance, not the children below those siblings). Additionally, we do not want these values being applied to the parent.

Therefore, we use minimum and maximum "base distances" of "1" within a "subtreeSpecification" instance to limit the influence of these directives to a single level below the prescribed parent entry n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA.

To apply the "c-topArc" Attribute Type to ALL entries below its DN, we create another "subentry" instance as before, only in a different location. Here, it is only sensible to label it "iso", as it will be placed directly beneath the ISO "rootArc" entry:

dn: cn=iso,n=1,ou=Registrations,o=rA
objectClass: extensibleObject
objectClass: subentry
objectClass: top
objectClass: collectiveAttributeSubentry
c-topArc;collective: n=1,ou=Registrations,o=rA
subtreeSpecification: {minimum 1}

Here, we want to apply the "c-topArc" attribute type to ALL entries below n=1,ou=Registrations,o=rA -- without applying the value to the parent itself. As such, we need only use the minimum base distance value of "1". This means that, starting one level below the parent, the value will be applied to all children indefinitely.

Once successfully added, Collective Attributes sourced by qualifying entries will begin to appear in subsequent search results. Restarting the OpenDJ process is not necessary.

Important

Avoid collective insanity

Collective Attributes are exceptionally useful, especially in large directories in which many entries share common values.

However, these should not be used too liberally, as not all situations call for for Collective Attributes, and (sometimes) more memory is used to facilitate these types as opposed to non-Collective types stored within a database in the traditional manner.

Directory architects and administrators should formulate criteria meant to help determine when a context is to be collectively managed, and when not.

Often, this can involve setting thresholds which might indicate that sets of sibling registrations less than 100 entries in length (for example) are to be manually managed, while sets greater or equal to that threshold might qualify for Collective Attribute intervention. This is just one possible avenue, and such policies will vary wildly among various organizations.

It is also worth mentioning that a few of the types mentioned previously are NOT eligible for Collective population due to their relative and unique nature. Consider the following scenario:

One encounters a set of ten (10) sibling registrations, bearing number forms "0" through "9". No matter which individual registration is queried, each one will have separate and distinct "leftArc" and "rightArc" values. Thus, there is no feasible means for Collective population in this scenario, thus no c- variants exist for these types.

Similarly, consider a registration with ten (10) subordinate (child) registrations. Each of these subordinate registration have their DN recorded as a "subArc" value assigned to the parent entry. Because children are unique and relative to their parent, again, Collective Attributes cannot serve any purpose here.

As such, this remains a definite challenge of note to which there is likely no simple, universal solution. The act of managing literal "leftArc", "rightArc" and "subArc" instances for potentially large numbers of entries individually will almost certainly require scripted automation, and perhaps maintenance of "incremental number form pools" to avoid costly searches and tedious trial-and-error to identify adjacent number forms.

Performance

The OID Directory I-D philosophy is such that the more costly (non-administrative) operations are discouraged precisely because there are better ways of achieving the same effect.

The most obvious example of this is the continued discouragement of any Search Scope that is NOT baseObject. Requesting singular entries in Read context as opposed to List or Search context is a much easier pill for the RA DSA to swallow. This is especially true for entries with a great many direct subordinates.

This approach also has the added benefit of reducing the importance of performance indices. When performing a Read operation upon a single entry with no filter, nothing (besides objectClass) is compared internally. The result is a fast return at essentially the lowest cost possible.

These savings can be stretched even further by limiting the values that are transmitted over the wire through use of AttributeSelection, or by use of typesOnly to omit values entirely ^{[RFC4511 § 4.5.1]}. Such techniques are ideal in situations where verifying the mere presence of an entry is the focus, as opposed the disclosure of its contents. One practical example of this is the Number Form Uniqueness check ^{[RADUA § 2.2.4.1.2]} exercised by the RA DUA during the pre-allocation phase ^{[RADUA § 2.2.4]}.

Consider the act of enumerating 60000 immediate subordinate entries. While this may sound extreme, this is not dissimilar to the number of IANA PEN registrations in existence at this moment.

The most common and inefficient means for this is doing something like a List Operation or singleLevel Search Operation:

$ ldapsearch -xb $(oid2dn 1.3.6.1.4.1) -s one dn

Even if one limits their attribute selector to something singular like dn as shown, AND disables extra frills like result comments, the operation is still hugely inefficient. Users normally query a single OID and move on from there in incremental steps. Getting a massive list in this manner is typically unhelpful outside of administrative or audit activities, and otherwise is a waste of resources from most standpoints.

Therefore, the OID Directory schema offers an alternative: the "subArc" attribute type. By maintaining an effective "list" of immediate subordinate DNs assigned directly to the parent, the enumeration of child DNs is notably faster and imposes less strain upon the RA DSA because only the baseObject is requested:

$ ldapsearch -xb $(oid2dn 1.3.6.1.4.1) -s base

Thus, given the previous mention of the IANA PEN registry, such an entry might appear as follows:

dn: n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
objectClass: x680Context
objectClass: spatialContext
objectClass: registration
objectClass: arc
objectClass: top
dotNotation: 1.3.6.1.4.1
description: IANA PEN Registry
iRI: /ISO/Identified-Organization/6/1/4/1
subArc: n=0,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
subArc: n=1,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
subArc: n=2,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
subArc: n=3,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
<tens of thousands of child DNs omitted>
subArc: n=59999,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA

Given this single entry, an RA DUA can simply perform a subsequent Read upon a DN of their choice, again returning a single entry of baseObject scope.

This can be further streamlined simply by requesting "subArc" through selection:

$ ldapsearch -xb $(oid2dn 1.3.6.1.4.1) -s base subArc

Of course, this lower utilization and improved user experience come at the cost of administrative tedium. As mentioned in the previous subsection, the "subArc" type is not eligible for Collective population.

It is also worth mentioning that this style of entry interaction is likely to produce more individual log events, even with reduced utilization compared to that of singleLevel or wholeSubtree scoped contexts. As heavy log events can, in some cases, diminish DSA performance, appropriate safeguards SHOULD be implemented.

Results

OpenDJ is SUITABLE for use relating to this I-D series.

Based on the actual implementation upon which this study is based, as well as the impressions of the author, the results were exactly as hoped and expected.

OpenDJ's support for features that were necessary -- even critical -- for large installations of this I-D series is indeed suitable.

Part of the difficulty in not only writing this study, but also the I-D series as a whole, was the profound lack of suitable directory products for use in service to any PoC. This required an unfortunate degree of reliance upon ITU-T X-Series 500 documents, which are largely focused on abstract theory as opposed to offering practical content.

And while this isn't meant to suggest that those directory products that were evaluated and subsequently dismissed from the study are "bad", the whole point of the I-D series was (primarily) to cater to particularly large and official registries. In this context, the very features that would allow the series to live up to that claim were either partially implemented, or missing altogether.

Bug reports

In performing this study, certain OpenDJ bugs came to light, were reported by the author and addressed by the OpenDJ maintainers:

• #382 - dITStructureRules implementation
• #383 - Documentation error
• #384 - Control Panel: empty help URL values
• #392 - Root DSE missing objectClass additions
• #393 - Schema parser for DITStructureRules violates RFC 4512 Section 4.1.7.1
• #394 - dsconfig --help options inconsistent

Literature

The following documents are particularly relevant to this study:

• The OID Directory I-D series ^{[RADIR], [RADIT], [RADSA], [RADUA], [RASCHEMA]}
• OpenDJ Documentation ^{[INSTALL], [ADMIN]}
• ITU-T X-Series ^{[500], [501], [511], [660], [680]}
• Request for Comments ^{[3671], [3672], [4370], [4511], [4512]}