Potential DSR/NF implementation flaws and an RFC 3672 violation

[JesseCoretta]

Note this revision will be uploaded soon, but I wrote it to not only address the issue I originally sought to resolve, but also the plight of any LDAP maintainer who suffers from this issue.

NOTE: Sections 2 and 3 are the most useful to LDAP maintainers, as they offer an abstract look at what actions should be taken, and how.

I will create PR for review for this fix once I get the final blessing from Steven Legg (co-author of RFC 3672) tonight, but I figure we should huddle as a team to make sure we're on the same page.

Link: Internet-Draft.

[JesseCoretta]

UPDATE: I have spoken once again with Steven Legg, and aside from a few minor changes, the draft seems ready for publishing.

@vharseko / @maximthomas - I am going to work on a potential fix this week. This will also result in documentation updates, which I will also handle. Will let you know when PR is sent. Let know if you require clarification on any elements.

[JesseCoretta]

OK @vharseko / @maximthomas -- I require some input on a proper course of action in terms of implementation procedure.

Summary of the problem

Directory servers should neither allow nor require the creation of name form definitions which contain 'subentry' as the OC clause value. Instead, the directory server is expected to enforce X.501's 'subentryNameForm' (clause 14.2.2) on its own.

The OFFICIAL name form in question is as follows. I did not "create this" -- my paper merely cites this definition and clarifies what should (and should not) be done with it. It also adds a helpful description.

      ( 2.5.15.16
          NAME 'subentryNameForm'
          DESC 'X.501, cl. 14.2.2: the Subentry name form'
          OC subentry
          MUST cn )

In short, this is the ONLY such name form that is legal in the world of X.500/LDAP on this topic.

Commentary and some questions

In principal, the fix is likely a simple matter. However I am conflicted as to how WE (the OpenDJ team) want this implemented.

I should also point out that while I am a programmer, Java is not my strong suit. Just a disclaimer in case any subsequent Java-focused questions may seem stupid :)

• Is there any precedent for hard-coding schema definitions in OpenDJ, or are ALL such definitions expected to be placed in the included schema file collection as a matter of policy?
  • I am asking because I am trying to anticipate the pros and cons of hard-coding vs. standard schema file-based maintenance procedures
• Because there is no specific guideline as to whether the X.501 'subentryNameForm' should be visible in the subschema (e.g.: to users performing an ldapsearch against "cn=schema"), I am wondering about how you guys feel about it
  • One argument AGAINST listing this name form in the schema is that it is supposed to be immutable, and need not be visible because the user should have NO SAY in how subentries are named
  • One argument FOR listing this name form in the schema is that it would help users proactively plan for the naming of a subentry, and would serve to educate users regarding the source of this name form, as well as its purpose; it may also help uninformed users in their troubleshooting efforts
• Because of the fundamental nature of this particular name form, I am wondering if we should be processing it like other name forms, OR if we should "cheat" early in the process and do something like:

        // from ./opendj-core/src/main/java/org/forgerock/opendj/ldap/schema/NameForm.java
        private NameForm(final Builder builder) {                           
             super(builder);
        ...
        ...
        if (builder.structuralObjectClassOID == "2.5.17.0" {
             <some non-fatal error error> // "Name form attempts to override X.501 cl. 14.2.2 subentryNameForm; ignoring attempt";
             // server still starts, but the user has (hopefully) seen the warning and taken appropriate action
        }
        ...

Of course the above excerpt only ensures that the attempt is ignored -- it does NOT prevent a user from editing the schema file in question manually. Naturally, there is nothing stopping the user from downloading our source and then hacking the code directly, which may render my concerns moot in this regard.

Furthermore, given the above excerpt (or something similar), how are we (the OpenDJ team) supposed to incorporate the CORRECT X.501 name form without tripping our own warnings? This stems from my initial question, as to whether these elements should (or should NOT) be "hard-coded", which could bypass that shortcoming.

In closing

Regardless of whether my I-D is accepted, rejected or (as is historically the case, outright ignored) by the IETF, the premise is sound and has been proven. Even if rejected, this does not alter the fact that in terms of X.501, the situation described would render any impacted directory system as non-compliant.

Additionally, the co-author of RFC 3672 even mentioned he would be willing to chime-in on any IETF-pushback, as we seemed to be in full agreement on the topic. In short, the ITU-T specification, and by necessity my paper, are definitely correct.

Some may argue the paper is moot simply because all it does is reiterate what many know to be fact. Again, this changes nothing and my own counterargument would be simply that "several well known directory products are afflicted with this deficiency, so even if it is a known fact to some, many others seem not to have received that particular memo."

Looking for some high-level implementation guidance.

Thanks guys 😃

Jesse

[vharseko]

can be done in many different ways
the realization is easier to discuss after I-D is accepted

[JesseCoretta]

Quoting my previous reply

Regardless of whether my I-D is accepted, rejected or (as is historically the case, outright ignored) by the IETF, the premise is sound and has been proven. Even if rejected, this does not alter the fact that in terms of X.501, the situation described would render any impacted directory system as non-compliant.

@vharseko -- this may be years away. Even with the blessing of the co-author of RFC 3672, its likely a long way off.

With this in mind, are you saying you'd rather let OpenDJ remain non-compliant in this fashion?

Whether or not the I-D is accepted, OpenDJ still in violation of X.501 in this regard -- if you guys are OK with this, let me know.

[JesseCoretta]

So be it.

Before I close this discussion, I would recommend one of you at least update the docs.