RADSA J. Coretta Internet-Draft August 27, 2024 Intended status: Experimental Obsoletes: X660LDAP Expires: February 23, 2025 The OID Directory: The RA DSA draft-coretta-oiddir-radsa-01.txt Abstract In service to the "OID Directory" I-D series, this I-D covers design considerations and basic requirements for the server component of the OID Directory Registration Authority client/server model. See the RADIR I-D for a complete draft series manifest. 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 February 23, 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 February 23, 2025 [Page 1] Internet-Draft The OID Directory: RA Server August 2024 Table of Contents 1. Introduction ....................................................2 1.1. Conventions ................................................2 1.2. Acronyms Used ..............................................2 1.2.1. Definitions ...........................................3 1.3. Intended Audience ..........................................3 2. The RA DSA ......................................................3 2.1. Defined Parameters .........................................3 2.2. Core Capabilities ..........................................4 2.2.1. Schema Availability ...................................4 2.2.2. Content Facility ......................................5 2.2.3. Access Medium .........................................5 2.2.4. Operations ............................................5 2.3. Optimizations ..............................................6 2.3.1. Collective Attributes .................................6 2.3.2. Attribute Value Uniqueness ............................6 2.3.3. Attribute Value Constraints ...........................7 2.3.4. Proxy Authorization ...................................7 2.3.5. Distribution ..........................................7 2.3.6. Root DSE Extensibility ................................8 2.3.7. Content Replication ...................................9 3. IANA Considerations .............................................9 4. Security Considerations .........................................9 4.1. Confidentiality ............................................9 4.2. Network Exposure ...........................................9 4.3. Access Control ............................................10 5. References .....................................................10 5.1. Normative References ......................................10 5.2. Informative References ....................................11 Author's Address ..................................................12 1. Introduction The X.500 Directory System Agent represents the provider of directory services to be leveraged by clients. Within the context of this I-D series, it houses an information base and potentially extends certain features meant to facilitate effective management of and/or access to OID registration and registrant content. 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 See Section 1.3 of the RADIR I-D for all acronym references. Coretta Expires February 23, 2025 [Page 2] Internet-Draft The OID Directory: RA Server August 2024 1.2.1. Definitions The composite acronym "RA DSA" is hereby introduced within this I-D. The acronym abbreviates the aforementioned 'Registration Authority Directory System Agent' term, which describes the 'server' component implied within the client/server model construct relevant to this I-D series. The composite acronym "RA DIT" used throughout this I-D is defined in Section 1.2.1 of the RADIT I-D. The composite acronym "RA DUA" used throughout this I-D is defined in Section 1.2.1 of the RADUA I-D. 1.3. Intended Audience This I-D is intended for X.500/LDAP architects and administrative personnel tasked with designing, supporting and/or maintaining any number of RA DSAs within the terms of this I-D series. General familiarity with the broad X.500/LDAP specification, as well as with the RASCHEMA, RADUA and RADIT I-Ds is STRONGLY RECOMMENDED. 2. The RA DSA The RA DSA is a traditional X.500/LDAP server -- fully compliant with the core standards defined throughout ITU-T Rec. [X.500], [RFC4510], et al, that has been OPTIMIZED for use within the terms of this I-D series. 2.1. Defined Parameters The RA DSA MAY support either DAP or LDAP operation, or both. No specific recommendations are made with regards to the nature of any networking elements, such as use of the OSI stack or TCP/IP. Native services and protocols managed in parallel by the RA DSA -- such as DOP or DSP -- have no specific function within the terms of this I-D series and thus are unimportant. Replication services such as DISP, however, may be indicated in certain scenarios to enhance the performance and reliability of an implementation; a concept that is largely out of scope for this I-D series. No particular software license applied to the RA DSA is assumed. In the operational terms of this I-D series, the RA DSA MUST fully support the Search and Read operations -- as executed by any RA DUAs interacting with the service -- for the purpose of entry retrieval as it pertains to registration and registrant contexts. This is a hard requirement. Coretta Expires February 23, 2025 [Page 3] Internet-Draft The OID Directory: RA Server August 2024 The RA DSA may or may not allow write-based operations -- such as Add or Modify -- to be executed by client entities. This may be due to the access control model employed by the RA DSA, shadowing contexts or some other condition in effect that would preclude writes. 2.2. Core Capabilities The core capabilities defined in this section represent features that are assumed to be common to virtually any practical implementation of the RA DSA component. These are REQUIRED in all cases. 2.2.1. Schema Availability The RA DSA cannot effectively serve or manage an RA DIT without the appropriate directory schema definitions. The RA DSA MUST allow for the inclusion of such definitions. Section 2 of the RASCHEMA I-D defines many suitable attribute type, object class and name form definitions for use in creating a viable RA DIT to be served by way of the RA DSA. Examples involving use of these definitions can be found throughout the RADIT I-D as well as this document. The RA DSA MUST have up-to-date knowledge of all attribute types and object classes defined in Sections 2.3 and 2.5 of the RASCHEMA I-D respectively. This is a critical requirement. The RA DSA MUST also be prepared to support sub typed attribute types. See the beginning of Section 2.3 of the RASCHEMA I-D for dependency details. Sections 4.1.1 and 4.1.2 of [RFC4512] and clauses 13.3.3 and 13.4.8 of ITU-T Rec. [X.501] define the object class and attribute type definition syntaxes respectively. The inclusion of name form definitions defined in Section 2.7 of the RASCHEMA I-D is ONLY RECOMMENDED if support for DIT structure rules is positive within the directory architecture. These name forms are designed to enforce the certain recommended DN syntax schemes based on the intended directory structure, however they serve no purpose if they are not referenced by any active DIT structure rules. This I-D series does not officially define any DIT structure rules, leaving that task to RA DSA administrative personnel because of the significant variations in their creation that are likely to manifest among the various implementations of this I-D. Section 4.1.7 of [RFC4512] and clause 13.7 of ITU-T Rec. [X.501] cover the DIT structure rule and name form definitions. No DIT content rule definitions are defined in this I-D series for the same reasons stated regarding DIT structure rules. These types of definitions are better suited for tailored design rather than mass adoption. Coretta Expires February 23, 2025 [Page 4] Internet-Draft The OID Directory: RA Server August 2024 DIT content rules are covered in Section 4.1.6 of [RFC4512] as well as within clause 13.8 of ITU-T Rec. [X.501]. 2.2.2. Content Facility The RA DSA has no practical purpose unless usable content exists and is facilitated in some manner, likely for consumption by clients and other DSAs. Facilitation may involve local storage of content, or distributed sourcing from external sources into a backend or storage area. This I-D makes no recommendations that specifically influence the design or operation of any content source facility. These concepts, and the available options, may differ greatly among the various X.500/LDAP DSA products available today. 2.2.3. Access Medium Although no specific medium or protocol is implied, this I-D assumes that any implemented RA DSA service is accessible and fosters some manner of interaction with relevant individuals, entities or local services. 2.2.4. Operations Depending on both the nature of the implementation and the RA DSA itself, certain operations -- such as those defined throughout ITU-T Rec. [X.511] and [RFC4511], et al -- to be executed by the RA DUA MUST be supported. This section identifies operations common between DAP and LDAP, and establishes generalized terms for the purpose of brevity throughout this I-D. As these operations apply to both RA DUAs and RA DSAs, they are cited through Sections 1.7 and 1.8 of the RADIR I-D. Note that operations not explicitly used for any procedure defined in this I-D series -- such as the Bind Operation -- are not covered. The DAP Search, DAP List and LDAP Search operations are the most critical of those required by the RA DUA construct, and is necessary for a variety of procedures involving registration and registrant contexts. Often, search operations may be used as a prelude to the execution of other actions, such as registration allocations. The DAP Add Entry or LDAP Add operations represent the means of creating new registration and registrant entries within the RA DIT. The DAP Modify DN or LDAP Modify DN operations are only used within the terms of this I-D series for the purpose of relocating submitted registration or registrant entries previously located in a request staging area following an approval process. Coretta Expires February 23, 2025 [Page 5] Internet-Draft The OID Directory: RA Server August 2024 The DAP Modify Entry or LDAP Modify operations are used for the routine modification of authority-related contact information and occasionally registrations. The DAP Remove Entry or LDAP Delete operations are used for the occasional removal of registrant information, and in considerably rare cases the removal of registrations. 2.3. Optimizations Throughout the I-D series, certain specialized capabilities are cited in reference to a particular condition or task within the RA DIT and the RA DUA. The following subsections briefly describe features that may be facilitated by way of the RA DSA, and how they fit into the "OID Directory" philosophy. Please note that while some of these topics are DIT focused, certain features must first be supported and somehow enabled within the RA DSA(s) in question. Directory architects may use these subsections when considering a potential X.500/LDAP directory product for use related to this I-D series, given specific requirements. 2.3.1. Collective Attributes Attribute types can be applied for an entire subtree context by way of collective attributes, described within [RFC3671], [RFC3672] and ITU-T Rec. [X.501]. In particularly large and mission-critical implementations of this I-D series, this may be a CRITICAL feature. This may also benefit large implementations which are maintained by engineers subject to significant time constraints. The RASCHEMA I-D defines several collective types for use within the terms of this I-D series. The RADIT I-D provides examples regarding use of the 'subtreeSpecification' type to that end. 2.3.2. Attribute Value Uniqueness Depending on the indicated attribute type(s) and relative context, it may be necessary to limit content to singular instances within the RA DIT or a specific subtree. One example of this is ensuring that only unique instances of the 'aSN1Notation' or 'iRI' attribute types exist within the relevant portions of the directory. If it is not possible to ensure uniqueness among specified values as recommended by some reasonable means, this I-D series may not be practical for adoption in certain mission-critical scenarios. Coretta Expires February 23, 2025 [Page 6] Internet-Draft The OID Directory: RA Server August 2024 2.3.3. Attribute Value Constraints The syntactical constraints afforded by the OID Directory schema, as defined in Section 2 of the RASCHEMA I-D, do not thoroughly conform to the constraints defined by the underlying standards -- for example ITU-T Recommendations [X.660] and [X.680] -- upon which this I-D series is conceptually based. This concern is mentioned in Section 2.1 of the RASCHEMA I-D. Section 2.3 of the RASCHEMA I-D references, or devises, appropriate ABNF productions for every attribute type defined. This is done to aid adopters in constraining values for conformance with originating standards, as opposed to reliance upon attribute syntax alone. If it is not possible to constrain values using the ABNF productions as recommended, by some reasonable means, this I-D series may not be practical for adoption in certain mission-critical scenarios. 2.3.4. Proxy Authorization In certain implementations of this I-D series, it may be advantageous for the RA DSA to support the Proxy Authorization Control [RFC4370] and the capability it extends. In scenarios where end users are authorized to modify certain entries for which they are authoritative or responsible in some manner, it is often desirable for personal details -- such as a DN reference which contains a full legal name -- to remain unexposed through instances of certain attribute types such as 'modifiersName' or 'creatorsName' that may be visible to a large user base. 2.3.5. Distribution Though not specifically recommended through this I-D series, the RA DIT may represent only a single component of a larger information base. This may be especially common in the case of official public facing RAs, where the information base as a whole is fractured in the contexts of origin and authority. Depending on the implementation factors, the nature of distribution could manifest through any combination of referrals, chaining and replication. While no recommendations for or against any of these features can be made, this I-D series acknowledges the likelihood and importance of such design strategies. At no point in this I-D series do any of the concepts or procedures set forth conflict with, preclude or require any of these capabilities. The concepts of the distributed directory are covered throughout ITU-T Rec. [X.518]. Directory replication is discussed throughout ITU-T Rec. [X.525]. Coretta Expires February 23, 2025 [Page 7] Internet-Draft The OID Directory: RA Server August 2024 2.3.6. Root DSE Extensibility For advertisement of optimal settings for consumption by clients in order to effectively interact with an RA DIT, the root DSE served by the relevant RA DSA(s) MUST support entry extensions of the Root DSE. This involves the addition of relevant attribute types extended by way of the 'rADUAConfig' AUXILIARY object class defined in Section 2.5 of the RASCHEMA I-D. RA DUAs that comply with Section 2.2.2 of the RADUA I-D will attempt retrieval of this additive content from the root DSE -- by way of the Read Operation -- and will adjust their behaviors accordingly. The root DSE is discussed in Section 5 of [RFC4512] and in Section 10 Clause 23.4.2 of ITU-T Rec. [X.501]. The following subsections offer examples regarding the extension of the root DSE and the distinct RA DUA configuration options available. These examples are expressed as LDIF. Note that other attribute type and object class instances unrelated to this I-D series may be found within the root DSE and may be disregarded. 2.3.6.1. Single RA DIT The following example is the partial representation of the root DSE as it pertains to the advertisement of RA DUA configuration settings for implementations involving a single RA DIT. dn: objectClass: rADUAConfig rARegistrationBase: ou=Registrations,o=rA 2.3.6.2. Multiple RA DITs The following example is the partial representation of the root DSE as it pertains to the advertisement of RA DUA configuration settings for implementations involving multiple RA DITs. dn: objectClass: rADUAConfig rADITProfile: dc=example,dc=com rADITProfile: o=example The following examples are the example root suffix entries referenced by way of the 'rADITProfile' attribute type instances added to the root DSE. These example entries have been modified to include the 'rADUAConfig' AUXILIARY object class, which is expected and required by the RA DUA. Coretta Expires February 23, 2025 [Page 8] Internet-Draft The OID Directory: RA Server August 2024 dn: dc=example,dc=com objectClass: domain objectClass: rADUAConfig rARegistrationBase: ou=Registrations,dc=example,dc=com dn: o=example objectClass: organization objectClass: rADUAConfig rARegistrationBase: ou=OIDs,o=example The 'domain' STRUCTURAL object class is defined in Section 3.4 of [RFC4524]. The 'organization' STRUCTURAL object class is defined in Section 3.8 of [RFC4519]. These classes are used here merely for the sake of example, and will vary among real-life DITs in the wild. 2.3.7. Content Replication Depending on the desired fault tolerance of an implementation, as well as the authoritative layout and placement of registration data, use of a directory replication system -- such as DISP or some other proprietary solution of a similar design -- may be indicated. This may be especially important in public-facing RA implementations in which various registration subtrees are sourced from appropriate authorities and served as shadowed contexts. DISP originates in ITU-T Rec. [X.525]. 3. IANA Considerations There are no requests to IANA in this document at this time. 4. Security Considerations 4.1. Confidentiality Network security mechanisms -- such as TLS or IPSEC VPN -- may be indicated when an RA DSA allows authenticated logins or disclosure of sensitive entries by authorized parties. This is especially true for cases in which the RA DUA is not local to the RA DSA. The I-D makes no recommendations regarding "Best Practices", strength factors or key generation strategies, nor does any of subject matter set forth in this I-D necessarily rely on any such concepts. 4.2. Network Exposure Historically, it is unusual for an X.500/LDAP service to be directly accessible over public networks in an overt or advertised fashion. While there may be precedents for this sort of exposure, this I-D has no official position regarding this strategy. Coretta Expires February 23, 2025 [Page 9] Internet-Draft The OID Directory: RA Server August 2024 Depending on the scope of implementation as well as the potential use of referrals and/or synchronization, limited levels of exposure could be required of any number of RA DSAs. 4.3. Access Control It is RECOMMENDED that potentially sensitive content within an RA DIT -- such as any personal authority contact details or private subtrees of registrations -- be safeguarded from unauthorized access. It is also RECOMMENDED that RA DIT content modifications be limited only to authorized entities, such as administrative personnel and/or parties serving in authority for the respective entries. The topic of access control mechanisms available through the various X.500/LDAP products available today is well outside of scope for this I-D series. Generally, adoption of the models defined in clause 8 of ITU-T. Rec. [X.501], or some other mechanism, is indicated. 5. References 5.1. Normative References RADIR Coretta, J., "The OID Directory: A Technical Roadmap", draft-coretta-oiddir-roadmap, August 2024. RADIT Coretta, J., "The OID Directory: The RA DIT", draft-coretta-oiddir-radit, August 2024. RADUA Coretta, J., "The OID Directory: The RA DUA", draft-coretta-oiddir-radua, August 2024. RASCHEMA Coretta, J., "The OID Directory: The RA Schema", draft-coretta-oiddir-schema, August 2024. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003. [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003. [RFC4511] J. Sermersheim, Ed. "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. Coretta Expires February 23, 2025 [Page 10] Internet-Draft The OID Directory: RA Server August 2024 [RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP): Proxy Authorization Control", RFC 4370, February 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. [X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract service definition", ITU-T X.511, October 2019. [X.518] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Procedures for distributed operation", ITU-T X.518, October 2019. [X.525] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Replication", ITU-T X.525, October 2019. 5.2. Informative References [RFC4510] Zeilenga, K. "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [RFC4524] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): COSINE LDAP/X.500 Schema", RFC 4524, June 2006. [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Overview of concepts, models and services", ITU-T X.500, October 2019. [X.660] International Telecommunication Union - Telecommunication Standardization Sector, "General procedures and top arcs of the international object identifier tree", ITU-T X.660, July 2011. [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T X.680, July 2002. Coretta Expires February 23, 2025 [Page 11] Internet-Draft The OID Directory: RA Server August 2024 Author's Address Jesse Coretta California, United States Email: jesse.coretta@icloud.com Coretta Expires February 23, 2025 [Page 12]