Internet DRAFT - draft-coretta-oiddir-radsa
draft-coretta-oiddir-radsa
RADSA J. Coretta
Internet-Draft February 29, 2024
Intended status: Experimental
Obsoletes: X660LDAP
Expires: August 27, 2024
The OID Directory: The RA DSA
draft-coretta-oiddir-radsa-00.txt
Abstract
In service to the "OID Directory" ID series, this ID covers design
considerations and basic requirements for the server component of
the OID Directory Registration Authority client/server model.
See the RADIR ID 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 August 27, 2024.
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 August 27, 2024 [Page 1]
Internet-Draft The OID Directory: RA Server February 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 ID
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 ID for all acronym references.
Coretta Expires August 27, 2024 [Page 2]
Internet-Draft The OID Directory: RA Server February 2024
1.2.1. Definitions
The composite acronym "RA DSA" is hereby introduced within this ID.
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 ID
series.
The composite acronym "RA DIT" used throughout this ID is defined in
Section 1.2.1 of the RADIT ID.
The composite acronym "RA DUA" used throughout this ID is defined in
Section 1.2.1 of the RADUA ID.
1.3. Intended Audience
This ID 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 ID series.
General familiarity with the broad X.500/LDAP specification, as well
as with the RASCHEMA, RADUA and RADIT IDs 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 ID
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 ID 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 ID series.
No particular software license applied to the RA DSA is assumed.
Within the operational terms of this ID 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.
Coretta Expires August 27, 2024 [Page 3]
Internet-Draft The OID Directory: RA Server February 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.
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 virtually 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 ID 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 ID 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 ID
respectively. This is an absolute requirement. The RA DSA MUST also
be prepared to support sub typed attribute types. See the beginning
of Section 2.3 of the RASCHEMA ID 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 ID is RECOMMENDED ONLY 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 DIT structure rules.
This ID 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 various implementations of this ID.
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 within this ID 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 August 27, 2024 [Page 4]
Internet-Draft The OID Directory: RA Server February 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 ID 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 ID 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 ID. As these operations apply to both RA DUAs and RA DSAs, they
are cited through Sections 1.7 and 1.8 of the RADIR ID.
Note that operations not explicitly used for any procedure defined
in this ID 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 ID series for the purpose of relocating submitted
registration or registrant entries previously located in a request
staging area following an approval process.
Coretta Expires August 27, 2024 [Page 5]
Internet-Draft The OID Directory: RA Server February 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 this ID 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 ID
series, given specific requirements.
2.3.1. Collective Attributes
Attribute types can be applied for an entire subtree context by way
of collective attributes, defined within [RFC3671], [RFC3672] and
ITU-T Rec. [X.501].
In particularly large and mission-critical implementations of this ID
series, this may be a CRITICAL feature.
The RASCHEMA ID defines several collective types for use within the
terms of this ID series. The RADIT ID 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 ID series may not be
practical for adoption in certain mission-critical scenarios.
Coretta Expires August 27, 2024 [Page 6]
Internet-Draft The OID Directory: RA Server February 2024
2.3.3. Attribute Value Constraints
The syntactical constraints afforded by the OID Directory schema, as
defined in Section 2 of the RASCHEMA ID, 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 ID
series is conceptually based. This concern is mentioned in Section
2.1 of the RASCHEMA ID.
Section 2.3 of the RASCHEMA ID references or defines appropriate
ABNF productions for every attribute type defined. This is done to
aid adopters in constraining values to conform 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 ID series may not be
practical for adoption in certain mission-critical scenarios.
2.3.4. Proxy Authorization
In certain implementations of this ID 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 ID 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 ID series acknowledges the likelihood and importance of
such design strategies. At no point in this ID 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 August 27, 2024 [Page 7]
Internet-Draft The OID Directory: RA Server February 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 ID.
RA DUAs that comply with Section 2.2.2 of the RADUA ID 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 ID series may be present
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 August 27, 2024 [Page 8]
Internet-Draft The OID Directory: RA Server February 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].
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 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 information.
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.
This ID makes no recommendations regarding "Best Practices", strength
factors or key generation strategies, nor does any of subject matter
set forth in this ID 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 ID has
no official position regarding this strategy.
Coretta Expires August 27, 2024 [Page 9]
Internet-Draft The OID Directory: RA Server February 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
ID 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, February 2024.
RADIT Coretta, J., "The OID Directory: The RA DIT",
draft-coretta-oiddir-radit, February 2024.
RADUA Coretta, J., "The OID Directory: The RA DUA",
draft-coretta-oiddir-radua, February 2024.
RASCHEMA Coretta, J., "The OID Directory: The RA Schema",
draft-coretta-oiddir-schema, February 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 August 27, 2024 [Page 10]
Internet-Draft The OID Directory: RA Server February 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 August 27, 2024 [Page 11]
Internet-Draft The OID Directory: RA Server February 2024
Author's Address
Jesse Coretta
California, United States
Email: jesse.coretta@icloud.com
Coretta Expires August 27, 2024 [Page 12]
