SUBNF J. Coretta
Internet-Draft September 30, 2024
Intended status: Informational
Expires: March 29, 2025
The Lightweight Directory Access Protocol (LDAP)
Subentry Name Form
draft-coretta-ldap-subnf-02.txt
Abstract
This informational Internet-Draft (I-D) clarifies certain aspects of
RFC3672, and provides commentary regarding the behavior of DIT
structure rules and name forms as they relate to, and interact with,
subentries present within various directory implementations.
This I-D also incorporates the 'subentryNameForm' derived from ITU-T
Rec. X.501.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 29, 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Coretta Expires March 29, 2025 [Page 1]
Internet-Draft The LDAP Subentry Name Form September 2024
Table of Contents
1. Introduction ....................................................2
1.1. Conventions ................................................3
1.2. Acronyms Used ..............................................3
1.3. About Name Forms and DIT Structure Rules ...................3
2. 'subentryNameForm' ..............................................3
3. Compliance Considerations .......................................4
4. IANA Considerations .............................................5
5. Security Considerations .........................................5
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informational References ...................................6
7. Acknowledgements ................................................6
Author's Address ...................................................6
1. Introduction
Over the years, there have been instances where certain directory
implementations mistakenly apply DIT structure rule governance to
[RFC3672] subentries beyond that which is permitted per ITU-T Rec.
[X.501].
Clause 14.2 of ITU-T Rec. [X.501] states:
Although subentry and subentryNameForm are specified using the
notation of clause 13, subentries are not regulated by DIT
structure or DIT content rules.
Clause 14.2.2 of the same document states:
No other name form shall be used for subentries.
However, in implementations which do not recognize or incorporate
this standard name form, attempts to create or relocate subentries
can fail due to a naming violation (64) wrongly being perceived by
the governing structure rule. This has resulted in individuals
making an assumption that manual creation of such subentry-focused
name forms is an expected and required procedure.
Under a strict interpretation of ITU-T Rec. [X.501], such behavior
is considered erroneous. It should not be necessary for individuals
to create their own incarnation of the name form cited in Section 2,
nor is it appropriate to deviate from the established naming policy
for subentries.
Unfortunately, this issue has prevailed for such a protracted period
of time that it has gradually become a routine, but unsanctioned,
procedure for those implementations that do not honor this mandate.
This I-D seeks to mitigate this issue by formally describing the
ITU-T Rec. [X.501] 'subentryNameForm' definition, per clause 14.2.2.
Coretta Expires March 29, 2025 [Page 2]
Internet-Draft The LDAP Subentry Name Form September 2024
Furthermore, this I-D reiterates that directory systems in which the
creation of properly named subentries, as described in Section 2, is
prevented by DIT structure rule governance is NOT TO BE REGARDED AS
FULLY COMPLIANT in the context of ITU-T Rec. [X.501] clauses 14.2 and
14.2.2.
Additionally, this I-D emphasizes that directory systems which allow
for the creation of subentry-focused name forms beyond that which is
described in Section 2 are also similarly NON-COMPLIANT.
1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
all capitals, as shown here.
1.2. Acronyms Used
ASN.1 Abstract Syntax Notation one
DIT Directory Information Tree
LDAP Lightweight Directory Access Protocol
RDN Relative Distinguished Name
1.3. About Name Forms and DIT Structure Rules
Name form definition per clause 13.1.8 of [X.501]:
A name form specifies a permissible RDN for entries of a
particular structural object class. A name form identifies a
named object class and one or more attribute types to be used
for naming (i.e., for the RDN). Name forms are primitive pieces
of specification used in the definition of DIT structure rules.
DIT structure rule definition per clause 13.1.6 of [X.501]:
DIT structure rule: A rule governing the structure of the DIT by
specifying a permitted superior to subordinate entry relationship.
A structure rule relates a name form, and therefore a structural
object class, to superior structure rules. This permits entries
of the structural object class identified by the name form to
exist in the DIT as subordinates to entries governed by the
indicated superior structure rules.
See Section 4.1.7.1 of [RFC4512] for descriptions of DIT structure
rules. See Section 4.1.7.2 of [RFC4512] for descriptions of name
forms.
2. 'subentryNameForm'
The 'subentryNameForm' name form definition manifests as follows:
Coretta Expires March 29, 2025 [Page 3]
Internet-Draft The LDAP Subentry Name Form September 2024
( 2.5.15.16
NAME 'subentryNameForm'
DESC 'X.501, cl. 14.2.2: the Subentry name form'
OC subentry
MUST cn )
The name form bears the STRUCTURAL 'subentry' class reference as its
OC clause value, meaning that entries residing in the administrative
area of the relevant structure rule AND which bear the 'subentry'
STRUCTURAL class shall be subject to naming enforcement.
Furthermore, in observance of this name form, the 'cn' attribute type
defined within Section 2.3 of [RFC4519] that is REQUIRED under all
circumstances by the 'subentry' class is also REQUIRED for use as the
principal RDN type. No other RDN attribute type will suffice.
For implementation reference, the ITU-T Rec. [X.501] ASN.1 equivalent
to the above definition is as follows:
subentryNameForm NAME-FORM ::= {
NAMES subentry
WITH ATTRIBUTES {commonName}
ID id-nf-subentryNameForm }
3. Compliance Considerations
First and foremost, the solution for this problem is to simply use
the above 'subentryNameForm' definition as an integrated component
of the directory product in question. To be clear, this is the ONLY
case in which a subentry-focused name form should EVER be integrated
in this fashion.
Unfortunately, the ramifications of this change may be negative if
not implemented in a sensible manner. This section covers various
actions that may be taken in that regard.
Should the issue be FULLY resolved in an abrupt manner, in that the
directory service no longer honors the use of any subentry-focused
name forms OTHER THAN that described in Section 2, and WITHOUT any
notice being given to users, the risk of errors in implementations
of the affected product will increase. As such, this would almost
certainly lead to a spike in support calls and trouble tickets for
directory product vendors and maintainers. This is undesirable.
Conversely, the choice NOT to fix this issue -- while it does have
the virtue of being the least disruptive option -- may harm or sully
common impressions of the affected product in terms of questionable
or incomplete standards compliance.
Coretta Expires March 29, 2025 [Page 4]
Internet-Draft The LDAP Subentry Name Form September 2024
Therefore, it is the opinion of this author that the BEST solution
is to allow this behavior to be OPTIONAL, or user-elected. In this
case, the "option" to control this behavior SHOULD favor the current
or "broken" state by default, so as to not introduce any change in
behavior until such time that it is deemed appropriate.
Not only would this method prove to be as non-disruptive as a choice
to take NO action, but it would also allow for maintainers to devise
the remainder of a mitigation plan in due course, allowing for ample
testing, as well as user input on the matter, if deemed appropriate.
Though NOT RECOMMENDED, this method also has the virtue of being more
favorable to users who MAY wish to purposely forego compliance for
some reason.
Beyond the modification of directory service behavior as it relates
to the interaction of DIT structure rules and subentries, maintainers
SHOULD augment the underlying schema subsystem or parser to ensure
that ANY attempt to introduce a subentry-focused name form -- OTHER
THAN that defined in Section 2 -- will be ignored.
It is also RECOMMENDED that in the event such a name form is added, a
warning should be raised to inform administrators of this condition.
4. IANA Considerations
There are no requests to IANA in this document at this time.
5. Security Considerations
There are no security considerations applicable to this I-D.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[X.501] International Telecommunication Union - Telecommunication
Standardization Sector, "The Directory: Models", ITU-T
X.501, October 2019.
Coretta Expires March 29, 2025 [Page 5]
Internet-Draft The LDAP Subentry Name Form September 2024
6.2. Informational References
[RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, June
2006.
7. Acknowledgements
The author of this I-D would like to extend her deepest appreciation
to Steven Legg, co-author of [RFC3672], for his invaluable subject
matter expertise on this issue.
Author's Address
Jesse Coretta
California, United States
Email: jesse.coretta@icloud.com
Coretta Expires March 29, 2025 [Page 6]