draft-coretta-oiddir-radsa-01.txt

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]