diff --git a/docs/release-notes.html b/docs/release-notes.html
index bdcddbd8c..46179c156 100644
--- a/docs/release-notes.html
+++ b/docs/release-notes.html
@@ -145,6 +145,22 @@ Version 7.0.0
if necessary.
+
+
+ Updated the documentation to include the latest revisions of
+ draft-ietf-kitten-scram-2fa, draft-melnikov-scram-bis,
+ draft-melnikov-scram-sha-512, and draft-melnikov-scram-sha3-512 in the set of
+ LDAP-related specifications.
+
+
+
+
+ Updated the documentation to include draft-coretta-oiddir-radit,
+ draft-coretta-oiddir-radsa, draft-coretta-oiddir-radua,
+ draft-coretta-oiddir-roadmap, and draft-coretta-oiddir-schema in the set of
+ LDAP-related specifications.
+
+
diff --git a/docs/specs/draft-coretta-oiddir-radit-00.txt b/docs/specs/draft-coretta-oiddir-radit-00.txt
new file mode 100644
index 000000000..71cd282d3
--- /dev/null
+++ b/docs/specs/draft-coretta-oiddir-radit-00.txt
@@ -0,0 +1,2205 @@
+
+
+RADIT J. Coretta
+Internet-Draft February 29, 2024
+Intended status: Experimental
+Obsoletes: X660LDAP
+Expires: August 27, 2024
+
+
+ The OID Directory: The RA DIT
+ draft-coretta-oiddir-radit-00.txt
+
+Abstract
+
+ In service to the "OID Directory" ID series, this ID covers design
+ strategies and requirements relating to the Registration Authority
+ Directory Information Tree.
+
+ 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 DIT February 2024
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Conventions ................................................2
+ 1.2. Acronyms Used ..............................................3
+ 1.2.1. Definitions ...........................................3
+ 1.3. Intended Audience ..........................................3
+ 1.4. Allocations ................................................3
+ 2. Assessments .....................................................3
+ 2.1. Schema Availability ........................................4
+ 2.2. Spectral Coverage ..........................................4
+ 2.3. Content Capacity and Location ..............................5
+ 2.4. User Base ..................................................5
+ 2.5. Class and Attribute Usage ..................................5
+ 2.6. Content Sourcing ...........................................6
+ 3. The RA DIT ......................................................6
+ 3.1. Directory Models ...........................................7
+ 3.1.1. Choosing the Appropriate Model ........................7
+ 3.1.2. The Two Dimensional Model .............................7
+ 3.1.3. The Three Dimensional Model ...........................9
+ 3.2. Entry Content ..............................................9
+ 3.2.1. Registrants ..........................................10
+ 3.2.2. Registrations ........................................13
+ 3.2.3. Value Forms ..........................................23
+ 3.2.4. Special Attributes ...................................25
+ 4. IANA Considerations ............................................36
+ 5. Security Considerations ........................................36
+ 5.1. Access Control ............................................36
+ 5.2. Creation and Modification Identities ......................36
+ 6. References .....................................................36
+ 6.1. Normative References ......................................36
+ 6.2. Informative References ....................................37
+ Author's Address ..................................................38
+
+1. Introduction
+
+ The X.500 Directory Information Tree is an abstract data structure
+ comprised of hierarchical contexts called entries. Each entry bears
+ an unambiguous reference -- a distinguished name -- to its location
+ within the structure.
+
+ Within the terms of this ID series, this structure represents -- or
+ houses -- an information base of OID registrations and registrants
+ in the context of ITU-T Recommendations X.660 and X.680, et al.
+
+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.
+
+Coretta Expires August 27, 2024 [Page 2]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+1.2. Acronyms Used
+
+ See Section 1.3 of the RADIR ID for all acronym references.
+
+1.2.1. Definitions
+
+ The composite acronym, "RA DIT", is hereby introduced within this ID.
+ The acronym abbreviates the 'Registration Authority Directory
+ Information Tree' term, which describes the directory tree structure
+ that has been created or leveraged for storage of registration and
+ registrant data in accordance with this ID series.
+
+ The composite acronym "RA DSA" used throughout this ID is defined in
+ Section 1.2.1 of the RADSA 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 specifically geared towards X.500/LDAP professionals, such
+ as administrators, architects or application developers tasked with
+ managing and/or implementing an RA DIT.
+
+ General familiarity with the standards of X.500 and LDAP, as well as
+ with the RASCHEMA, RADUA and RADSA IDs is STRONGLY RECOMMENDED.
+
+1.4. Allocations
+
+ This specification extends the previously defined ID series OID root
+ '1.3.6.1.4.1.56521.101', defined in Section 1.6 of the RADIR ID, in
+ the following manner:
+
+ - 1.3.6.1.4.1.56521.101.3 (rA-DIT)
+ - 1.3.6.1.4.1.56521.101.3.1 (models)
+ - 1.3.6.1.4.1.56521.101.3.1.2 (twoDimensional)
+ - 1.3.6.1.4.1.56521.101.3.1.3 (threeDimensional)
+
+ OIDs defined in this ID correlate to their section numbers of origin.
+
+ Should this ID be elevated to RFC status, the aforementioned ID root
+ OID prefix shall be rendered obsolete in favor of an IANA-assigned
+ OID, at which point this ID will be updated to reference the literal
+ 'IANA-ASSIGNED-OID' placeholder prefix where appropriate.
+
+2. Assessments
+
+ Implementation of this ID should not be taken lightly. Certain key
+ design decisions need to be made well in advance of use.
+
+ To aid in this process, the following subsections outline relevant
+ assessment categories for consideration.
+
+Coretta Expires August 27, 2024 [Page 3]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+2.1. Schema Availability
+
+ Complete access and usage capabilities for all schema definitions
+ found throughout Section 2 of the RASCHEMA ID is REQUIRED for
+ the design and ongoing maintenance of the RA DIT.
+
+ Adopters MUST confirm positive access to these definitions.
+
+ Adopters are also advised to confirm positive support for DIT
+ Content Rule, DIT Structure Rule and Name Form definitions by the
+ respective RA DSA implementation if their use is necessary.
+
+ At an absolute minimum, access to all attribute types and object
+ classes defined within Sections 2.3 and 2.5 of the RASCHEMA ID
+ respectively are REQUIRED for the effective construction of the RA
+ DIT.
+
+2.2. Spectral Coverage
+
+ The overall "size" of the planned implementation is a very important
+ consideration. Adopters should decide how thorough their planned
+ RA DIT shall be in terms of content.
+
+ - Which of the three (3) ITU-T Rec. X.660 root arcs will
+ be implemented?
+ - Will subordinate registrations be retained indiscriminately, or
+ are only specific arcs targeted?
+
+ Root arc entries, ostensibly those bearing the 'rootArc' STRUCTURAL
+ class defined in Section 2.5.2 of the RASCHEMA ID, are intended to
+ store registrations of like ancestry only.
+
+ In the RECOMMENDED three dimensional model, this is REQUIRED. Here,
+ all registrations of the same ancestry or "lineage" of the desired
+ entry -- from root to immediate parent -- MUST be created in order to
+ conform to the requisite tree structure. In other words, if '1.3.6'
+ is desired for registration, '1.3' and '1' MUST exist hierarchically
+ beforehand, even if they are unnecessary in context.
+
+ When using the STRONGLY DISCOURAGED two dimensional model, only
+ specific (desired) registrations need to be created -- NOT their
+ entire ancestry. The result is a collection of sibling entries
+ with no hierarchically significant placement.
+
+ With these considerations in mind, adopters should decide the
+ extent to which adoption shall occur in terms of directory content
+ maintained and its effective footprint.
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 4]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+2.3. Content Capacity and Location
+
+ Adopters are advised to consider the long-term implications of
+ the planned RA DIT in terms of capacity provided by the hosting RA
+ DSA(s) and take measures to ensure a suitable operating environment.
+
+ Based on the assessments made in Section 2.2, adopters may wish
+ to consider whether a particularly large RA DIT may be better suited
+ for context segmentation, whether or not distribution is indicated,
+ to allow for larger portions of the RA DIT to function independently
+ and with dedicated resources and specialized security policies.
+
+ ITU-T Rec. X.518 defines the concepts of the distributed directory.
+
+2.4. User Base
+
+ The targeted user base of an implementation can influence its nature.
+
+ A private RA -- for example, one administered under the governance of
+ a private corporation for internal use -- may be exposed to a largely
+ vetted and fairly small user base. If so, it may be acceptable to
+ relax certain restrictions, such as registrant privacy controls.
+
+ In the case of public-facing RA -- for example, one meant to serve an
+ unvetted and potentially hostile user base -- the requirements for a
+ practical and secure implementation become far more complicated.
+
+ Lack of an effective access control model employed by the RA DSA MUST
+ preclude the storage of sensitive content within any RA DIT that is
+ potentially vulnerable to hostile entities. Design of the RA DIT in
+ this manner depends on positive support for suitable access controls
+ by the RA DSA. Adopters are advised to confirm availability and
+ effective operation of such controls under the expected conditions.
+
+ The effective mass and vitality of the user base is also a point of
+ consideration. Adopters are advised to consider whether subtrees
+ of a particularly volatile nature may be better suited for placement
+ within a separate RA DSA or environment, which may or may not involve
+ use of a distributed model or shadowed context.
+
+2.5. Class and Attribute Usage
+
+ Not all attribute types defined in the RASCHEMA ID are required
+ for use within an RA DIT. For example, only one (1) attribute type
+ -- 'n', per Section 2.3.1 of the RASCHEMA ID -- is truly REQUIRED
+ for all registrations. Naturally, such stringent use of the types
+ made available may result in an unhelpful implementation.
+
+ While attribute types have been defined for most contingencies, the
+ adoption of these types is entirely up to the adopter(s).
+
+
+
+Coretta Expires August 27, 2024 [Page 5]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Consult Section 2.3 of the RASCHEMA ID for the particulars of the
+ named attribute types in the following subsections.
+
+ Consult Section 2.5 of the RASCHEMA ID for definitions of object
+ class instances which allow assignment of these types to eligible
+ entries.
+
+ Consult Section 3.2 for examples of object class and attribute type
+ usage as complete entries, as well as an overview of use cases for
+ specific types.
+
+2.6. Content Sourcing
+
+ This ID acknowledges that -- even in complete implementations -- no
+ single RA manages ALL of the OID spectrum directly. Most, if not all
+ of this content is under the authority of external entities.
+
+ In lieu of this, this ID assumes some mechanism may be in place meant
+ to obtain and synchronize content from appropriate sources. While
+ the specifics are well outside the intended scope, this process may
+ resemble any of the following:
+
+ - Native replication agreements spanning implementations of this ID
+ - Regular data file receipt and processing (e.g.: LDIF, XML, CSV)
+ - Direct parsing of originating standard, ID or module
+ - Remote (proprietary) API requests
+ - Remote AXFR or IXFR requests [RFC5936] in the context of ORS
+
+ While the particulars of such synchronization and/or incorporation of
+ content external to this ID are well outside of the scope intended,
+ this ID acknowledges that such sourcing methods are often necessary.
+ Adopters SHOULD determine if any external registration content
+ is worthy of incorporation and in what manner.
+
+ Conversely, if the RA is responsible for any number of registrations
+ that are public-facing in nature, the RA SHOULD make registrations
+ available for consumption by external parties by some means.
+
+3. The RA DIT
+
+ The RA DIT is a traditional X.500/LDAP directory information tree
+ served by way of an RA DSA with which clients may interact.
+
+ The RA DIT may or may not contain unrelated content such as employee
+ accounts, user groups or system data. This ID series has no official
+ position as it relates to the presence of such content.
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 6]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.1. Directory Models
+
+ The appropriate DIT structure for any scenario depends upon the scope
+ of implementation in the long-term. Directory models defined within
+ this ID series are meant to provide an indication to clients (DUAs)
+ regarding the governing structure of the implementation.
+
+ DUAs optimized for use within the terms of this ID series, known as
+ RA DUAs, will use this information to define the operating methods
+ exercised during routine operation.
+
+3.1.1. Choosing the Appropriate Model
+
+ This introductory section aids the reader in choosing the appropriate
+ model for their implementation. Generally this decision is made well
+ in advance of any tangible implementation.
+
+ The three dimensional model, as defined in Section 3.1.3, is the most
+ likely candidate for adoption if ANY of the following are considered
+ TRUE:
+
+ - The RA is operating as an official, or widely recognized, public
+ service that conforms to all relevant standards
+ - Consistent, unambiguous DN-based registration references for an
+ entire ancestry is desired
+ - Reliable, bidirectional client-based conversion (or "resolution")
+ between DNs and numeric OIDs for an entire ancestry is desired
+ - RA DIT scalability and flexibility is a non-trivial concern
+ - The distribution (or "segmentation") of select DIT content is
+ in effect, or may be desirable, across multiple RA DSAs
+ - A single RA DIT is logically divided into multiple subordinate
+ naming contexts within an RA DSA
+ - The implementation will be thorough, spanning more than a single
+ root arc, with an ever-increasing number of registrations being
+ stored and served
+ - Collective Attribute support is desired
+ - Content privileges are complex, highly regimented and/or will
+ vary across different registration hierarchies
+ - Sparse or fractional replication agreements are possible
+ - Ranged registrations are present or expected
+
+ Should NONE of the above scenarios apply, the implementation is to
+ be regarded as non-standard and may be an appropriate candidate for
+ the two dimensional model described in Section 3.1.2.
+
+3.1.2. The Two Dimensional Model
+
+ The two dimensional model is advertised, or identified, using the
+ following OID assigned to an instance of 'rADirectoryMode':
+
+ 1.3.6.1.4.1.56521.101.3.1.2
+
+
+Coretta Expires August 27, 2024 [Page 7]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Per Section 3.1.1, this model is available for informal, unofficial
+ or otherwise non-standard implementations of this ID. Use of this
+ model is STRONGLY DISCOURAGED.
+
+ The two dimensional model describes a simple "list" of registration
+ entries, all accessible exactly one (1) level below the top-level
+ registration root. The concept of subtrees beyond this magnitude
+ does not apply in this model.
+
+ The ideal DN syntax for use with this model involves use of the
+ 'dotNotation' attribute type as the principal RDN component of the
+ entry DN.
+
+ For example, the following DN would reference the OID registration
+ for "dod":
+
+ dotNotation=1.3.6,ou=Registrations,o=rA
+
+ If the DN syntax used the 'identifier' value, it might appear as:
+
+ identifier=dod,ou=Registrations,o=rA
+
+ Registrations are stored with no regard for vertical or horizontal
+ relationships. Sibling, subordinate and superior registrations may
+ be stored within the same naming context and the same hierarchical
+ "level":
+
+ dotNotation=2.1,ou=Registrations,o=rA
+ dotNotation=1.3.6,ou=Registrations,o=rA
+ n=0,ou=Registrations,o=rA
+ dotNotation=1.3,ou=Registrations,o=rA
+ dotNotation=0.9,ou=Registrations,o=rA
+
+ This model does NOT scale well. Beyond the basic organization of OID
+ registrations within their respective roots, hierarchically-based OID
+ registration organization is NOT practical, as this technique would
+ almost certainly produce absurdly long and/or counterintuitive DNs.
+
+ Contiguity of superior registrations is not implicitly guaranteed as
+ it is when using the three dimensional model. For example, if the
+ registration for '1.3.6' ("dod") is present, this does not guarantee
+ the superior registration '1.3' ("identified-organization") exists in
+ the RA DIT.
+
+ This model is NEVER RECOMMENDED for official implementations, nor
+ in any scenario even approaching the severity of mission-critical.
+
+ Only private implementations of especially weak definition or those
+ of an ephemeral nature should ever truly consider adoption of this
+ directory model.
+
+
+
+Coretta Expires August 27, 2024 [Page 8]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.1.3. The Three Dimensional Model
+
+ The three dimensional model is advertised, or identified, using the
+ following OID assigned to an instance of 'rADirectoryModel':
+
+ 1.3.6.1.4.1.56521.101.3.1.3
+
+ The three dimensional model describes a registration hierarchy that
+ mirrors the hierarchical nature of the OIDs directly, with absolute
+ root arc registrations superior to all subordinate arc registrations.
+
+ Per Section 3.1.1, this model is STRONGLY RECOMMENDED for complete,
+ thorough or official implementations of this ID. It is also quite
+ suitable for general use, though at the risk of some administrative
+ tedium if a suitable RA DUA is not made available.
+
+ The three dimensional model imposes very strict and well-defined DN
+ syntax requirements. In particular, the 'n' attribute type is an
+ important component in the formation of a valid and unambiguous
+ reference to a single registration and its ancestry.
+
+ The result is a model that fosters seamless bidirectional conversion
+ -- performed by the RA DUA -- between DNs and numeric OIDs.
+
+ For example, the following DN represents OID '1.3.6.1.4.1.56521.999'.
+ In this syntax, a DN is divided into two (2) logical abstractions:
+
+ n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1 ,ou=Registrations,o=rA
+ ------------------------------------- ----------------------
+ Registration Ancestry Registration Base
+
+ The conversion process from OID to DN is as follows:
+
+ 1. Reverse OID (becomes 999.56521.1.4.1.6.3.1)
+ 2. Swap all ASCII "%x2e" (".") instances with ASCII "%x2c" (",")
+ 3. Preface each ASCII "%x2c"-delimited integer with 'n=', which
+ completes assembly of the registration ancestry
+ 4. Append ASCII "%x2c" (",") and appropriate registration base
+
+ In the obverse -- or "unreversed" -- context, the following process
+ converts a DN to a numeric OID:
+
+ 1. Discard registration base leading ASCII "%x2c" delimiter (","),
+ leaving only the registration ancestry
+ 2. Discard all occurrences of 'n='
+ 3. Swap all ASCII "%x2c" (",") instances with ASCII "%x2e" (".")
+ 4. Reverse values (becomes OID 1.3.6.1.4.1.56521.999)
+
+3.2. Entry Content
+
+ The following subsections discuss various topics that pertain to DIT
+ content management within the spirit of this ID series.
+
+Coretta Expires August 27, 2024 [Page 9]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Certain examples are defined for consumption by adopters of this ID.
+ These examples are expressed as LDIF, and may employ indenting and
+ line-wrapping of attribute values whose lengths exceed the maximum
+ size permitted by the RFC ID standard format.
+
+ This condition does not invalidate the usability or syntactical
+ conformity of these instances.
+
+3.2.1. Registrants
+
+ Registrants are documented authorities of various forms involved
+ in the ownership, allocation and/or general management of an OID.
+
+ Whether directly or through inheritance, all OIDs have an authority
+ of some form. This ID allows for flexible and scalable management
+ of such content.
+
+3.2.1.1. Registrant Strategy
+
+ Per ITU-T Rec. X.660, there are three (3) types of authorities:
+
+ - Current
+ - Previous (First)
+ - Sponsor
+
+ To parallel these authority types, three (3) AUXILIARY object classes
+ are defined within Section 2.5 of the RASCHEMA ID:
+
+ - 'currentAuthorityContext'
+ - 'firstAuthorityContext'
+ - 'sponsorContext'
+
+ Use of any number of these object classes will result in related
+ contact and identity attribute types being made available for use
+ within the class bearing entry.
+
+ Generally, authorities manifest as any of the following entities:
+
+ - An individual
+ - A public or private organization, institution or working group
+ - A document (e.g.: a standard or ID, e.g.: [RFC4519])
+
+ Implementations of this ID may choose either of the following models
+ to govern registrant-related DIT content:
+
+ - Dedicated (independent) entry model
+ - Combined (inline) entry model
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 10]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.1.1.1. Dedicated Registrants
+
+ In this model, every distinct registrant is expressed using a single
+ dedicated directory entry bearing the 'registrant' STRUCTURAL object
+ class and is uniquely identifiable by way of a 'registrantID' value,
+ ideally assigned as the leaf-node RDN component of the entry.
+
+ This is the RECOMMENDED strategy for all implementations and models
+ in which registrant information is present.
+
+ For any practical use, each 'registrant' entry SHOULD bear one (1) or
+ more of the following AUXILIARY object class definitions previously
+ mentioned:
+
+ - 'currentAuthorityContext'
+ - 'firstAuthorityContext'
+ - 'sponsorContext'
+
+ For example, consider the following 'registrant' entry describing the
+ author of this ID series:
+
+ dn: registrantID=a0efcce18a,ou=Registrants,o=rA
+ objectClass: registrant
+ objectClass: firstAuthorityContext
+ firstAuthorityStartTimestamp: 20210930124105Z
+ firstAuthorityCommonName: Jesse Coretta
+ firstAuthorityEmail: jesse.coretta@icloud.com
+
+ Use of the 'registrantID' attribute type as the principal RDN type
+ is STRONGLY RECOMMENDED as shown.
+
+
+ The concept of a dedicated registrant entry is unfixed. Attribute
+ types related to authority information extended via the RASCHEMA
+ ID are present largely for convenience and reasons of clarity.
+
+ Adopters of the RA DIT MAY choose to forego use of some or all of
+ these types in favor of those defined within official standards such
+ as [RFC4519] and [RFC4524].
+
+ It is RECOMMENDED that in this case, use of such attribute types that
+ serve as super types of the replaced RASCHEMA types be observed.
+ For example, the appropriate replacement type for 'sponsorCommonName'
+ is 'cn', because 'cn' is its super type.
+
+ Some types defined within the RASCHEMA ID are unique in nature and
+ may not be derived from a super type. An example of this is the
+ 'firstAuthorityStartTimestamp' attribute type. Continued use of
+ these types is likely indicated.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 11]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Use of the 'extensibleObject' AUXILIARY object class defined within
+ Section 4.3 of [RFC4512] is likely indicated where this replacement
+ strategy is employed. Continued use of the 'registrant' STRUCTURAL
+ object class is REQUIRED for compatibility reasons relating to the
+ RA DUA.
+
+ To offer a more complete example of this alternative use, the above
+ 'registrant' entry bearing the 'registrantID' value of 'a0efcce18a'
+ implements 'cn' and 'mail' over their sub typed counterparts defined
+ within the RASCHEMA ID.
+
+ dn: registrantID=e2ef220b3b,ou=Registrants,o=rA
+ objectClass: registrant
+ objectClass: extensibleObject
+ objectClass: firstAuthorityContext
+ firstAuthorityStartTimestamp: 20210930124105Z
+ cn: Jesse Coretta
+ mail: jesse.coretta@icloud.com
+
+ The drawback of this replacement strategy is that this 'registrant'
+ entry cannot combine the ITU-T Rec. X.660 authority classifications
+ within the bounds of a single 'registrant' entry any longer.
+
+ For example, observe how two (2) distinct authority contexts reside
+ within this single 'registrant' entry:
+
+ dn: registrantID=aec17eef17,ou=Registrants,o=rA
+ objectClass: registrant
+ objectClass: firstAuthorityContext
+ objectClass: currentAuthorityContext
+ currentAuthorityOrg: ITU-T SG 17 & ISO/IEC JTC 1/SC 6
+ firstAuthorityOrg: ITU-T SG 7 & ISO/IEC JTC 1/SC 33
+
+ If the implementation, instead, favors use of the indicated super
+ types, the context of the above 'registrant' entry will have to
+ be split into two (2) distinct entries:
+
+ dn: registrantID=b7ea16ef5e,ou=Registrants,o=rA
+ objectClass: registrant
+ objectClass: extensibleObject
+ objectClass: currentAuthorityContext
+ o: ITU-T SG 17 & ISO/IEC JTC 1/SC 6
+
+ dn: registrantID=e1f0ffb677,ou=Registrants,o=rA
+ objectClass: registrant
+ objectClass: extensibleObject
+ objectClass: firstAuthorityContext
+ o: ITU-T SG 7 & ISO/IEC JTC 1/SC 33
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 12]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ With a cogent "dedicated registrant" policy devised, 'registration'
+ entries may reference appropriate entries through DN referencing in
+ the context of appropriate authority classification by way of the
+ following attribute types:
+
+ - 'currentAuthority' and/or 'c-currentAuthority'
+ - 'firstAuthority' and/or 'c-firstAuthority'
+ - 'sponsor' and/or 'c-sponsor'
+
+ It is permitted for 'registration' entries to bear both collective
+ and non-collective equivalent instances of these attribute types.
+ For example, the presence of instances of both the 'sponsor' and
+ 'c-sponsor' types within a single 'registration' entry is permitted.
+
+ A practical use case might involve collective value assignment to a
+ large number of entries, with non-collective supplemental authority
+ references added in ad hoc fashion, as needed.
+
+3.2.1.1.2. Combined Registrants
+
+ In this model, 'registration' entries are assigned one (1) or more of
+ the following AUXILIARY object class definitions:
+
+ - 'currentAuthorityContext'
+ - 'firstAuthorityContext'
+ - 'sponsorContext'
+
+ Unlike the RECOMMENDED registrant approach shown in Section 3.2.1,
+ contact and identity attribute types are stored directly within the
+ given 'registration' entry. Essentially, this merges the ideas of
+ 'registration' entries and 'registrant' entries into a singular
+ context.
+
+ This model is highly inefficient, and would only apply to limited
+ use-cases within the STRONGLY DISCOURAGED two dimensional model,
+ and ONLY if the footprint is particularly small with registrant
+ data that is unique and non-repeating in form.
+
+ Limited examples of this registrant model are shown in Section 3.2.2.
+
+ In general, use of this model is STRONGLY DISCOURAGED.
+
+3.2.2. Registrations
+
+ Registrations are official allocations of ASN.1 object identifiers.
+ Within the context of this ID, a registration manifests through a
+ directory entry bearing the 'registration' STRUCTURAL class and
+ any number of supporting attribute type instances.
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 13]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.2.1. Root Arcs
+
+ Regardless of the implemented dimensional model, certain scenarios
+ will call for the creation of so-called root registrations, or root
+ arcs. These are special entries -- of which there can only be three
+ (3) -- meant to represent the absolute superior root context of any
+ and all registrations of origin.
+
+ The three (3) root arcs -- defined in ITU-T Rec. X.660 -- are covered
+ in the following subsections and are expressed as LDIF entries. Some
+ attribute values are both line-wrapped and indented due to character
+ lengths, which is permitted using LDIF.
+
+ These registration forms are dimension neutral, meaning they manifest
+ no differently regardless of directory model employed.
+
+ Root 'registration' entries are based upon the 'rootArc' STRUCTURAL
+ object class. Be advised that root registration entries cannot bear
+ instances of the 'dotNotation' attribute type due to syntactical
+ limitations. The standard OID syntax for LDAP requires at least two
+ (2) number form instances in dot notation for a legal OID value.
+
+ Because 'dotNotation' was defined upon this syntax, this precludes
+ any single root arc -- such as 2 -- being used to identify a root
+ OID. This is why the 'n' attribute type is RECOMMENDED for the leaf
+ node RDN component of all 'registration' entries -- including roots.
+
+ It is generally discouraged to use any attribute type OTHER THAN 'n'
+ for the RDN attribute type of the 'registration' DN within the three
+ dimensional model. Using types such as 'identifier', 'unicodeValue'
+ or others, can interfere with DN/OID conversion and extrapolation.
+
+3.2.2.1.1. ITU-T
+
+ dn: n=0,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: rootArc
+ objectClass: x660Context
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: International Telecommunication Union -
+ Telecommunication standardization sector (ITU-T)
+ unicodeValue: ITU-T
+ identifier: itu-t
+ iRI: /ITU-T
+ iRI: /ITU-R
+ aSN1Notation: {itu-t(0)}
+ secondaryIdentifier: ccitt
+ standardizedNameForm: {itu-t}
+ additionalUnicodeValue: ITU-R
+ registrationClassification: Standards development organization
+
+
+Coretta Expires August 27, 2024 [Page 14]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ This registration may also be expressed in minimalistic form:
+
+ dn: n=0,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: rootArc
+
+3.2.2.1.2. ISO
+
+ dn: n=1,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: rootArc
+ objectClass: x660Context
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: International Organization for Standardization (ISO)
+ unicodeValue: ISO
+ identifier: iso
+ iRI: /ISO
+ aSN1Notation: {iso(1)}
+ standardizedNameForm: {iso}
+ registrationClassification: Standards development organization
+
+ This registration may also be expressed in minimalistic form:
+
+ dn: n=1,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: rootArc
+
+3.2.2.1.3. Joint ISO/ITU-T
+
+ dn: n=2,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: rootArc
+ objectClass: x660Context
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: Areas of joint work between ISO/IEC (International
+ Organization for Standardization/International Electrotechnical
+ Commission) and ITU-T (International Telecommunication Union -
+ Telecommunication standardization sector), and other intl. work
+ firstAuthority: registrantID=e1f0ffb677,ou=Registrants,o=rA
+ currentAuthority: registrantID=b7ea16ef5e,ou=Registrants,o=rA
+ unicodeValue: Joint-ISO-ITU-T
+ identifier: joint-iso-itu-t
+ iRI: /Joint-ISO-ITU-T
+ aSN1Notation: {joint-iso-itu-t(2)}
+ secondaryIdentifier: joint-iso-ccitt
+ standardizedNameForm: {joint-iso-itu-t}
+ registrationClassification: Standards development organization
+
+
+
+
+Coretta Expires August 27, 2024 [Page 15]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ See Section 3.2.1.1.1 for authority entry examples referenced here.
+ If using the (generally) DISCOURAGED "combined registrants" strategy,
+ the following object classes and attribute types may be added to this
+ entry instead of the above authority-related DN references:
+
+ objectClass: firstAuthorityContext
+ objectClass: currentAuthorityContext
+ currentAuthorityOrg: ITU-T SG 17 & ISO/IEC JTC 1/SC 6
+ firstAuthorityOrg: ITU-T SG 7 & ISO/IEC JTC 1/SC 33
+
+ This registration may also be expressed in minimalistic form:
+
+ dn: n=2,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: rootArc
+
+3.2.2.2. Subordinate Arcs
+
+ Also referred to as 'sub arcs' and 'non-root arcs', these entries
+ represent the majority of content that comprises the typical RA DIT.
+
+ These registration forms -- unlike their root counterparts -- may
+ manifest in slightly different manners depending on the directory
+ model employed by the RA DIT in question. The following sections
+ that outline examples of these entries will include remarks which
+ relate to any indicated dimensional considerations. These sections
+ also cite certain well-known registrations relevant to the examples.
+
+ Subordinate arcs may incorporate additional attribute types and
+ object classes not permitted for use by root arcs described within
+ Section 3.2.2.1 -- whether due to schema restrictions or by virtue
+ of logical context.
+
+ In particular, arcs bear the 'arc' STRUCTURAL object class instead of
+ the 'rootArc' object class, and MAY bear one (1) of the following
+ AUXILIARY classes only, and would be based upon the leading digit of
+ the registration's effective OID:
+
+ - 'iTUTRegistration' (0)
+ - 'iSORegistration' (1)
+ - 'jointISOITUTRegistration' (2)
+
+ Additional permitted attribute types include, but are not limited to:
+
+ - 'dotNotation'
+ - 'isLeafNode'
+ - 'registrationRange'
+ - '[c-]topArc'
+ - '[c-]supArc'
+
+
+
+
+Coretta Expires August 27, 2024 [Page 16]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.2.2.1. Identified-Organization
+
+ dn: n=3,n=1,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x660Context
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: Organization identification schemes registered
+ according to ISO/IEC 6523-2
+ aSN1Notation: {iso(1) identified-organization(3)}
+ isFrozen: TRUE
+ dotNotation: 1.3
+ unicodeValue: Identified-Organization
+ registrationModified: 20120101000000Z
+ registrationCreated: 19870101000000Z
+ standardizedNameForm: {identified-organization}
+ iRI: /ISO/Identified-Organization
+
+ If using the STRONGLY DISCOURAGED two dimensional directory model,
+ "Identified-Organization" SHOULD express the RECOMMENDED DN syntax
+ for this model:
+
+ dotNotation=1.3,ou=Registrations,o=rA
+
+3.2.2.2.2. ASN.1
+
+ dn: n=1,n=2,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: jointISOITUTRegistration
+ objectClass: x660Context
+ objectClass: x680Context
+ n: 1
+ description: ASN.1 standards
+ aSN1Notation: {joint-iso-itu-t(2) asn1(1)}
+ dotNotation: 2.1
+ iRI: /ASN.1
+ longArc: /ASN.1
+ unicodeValue: ASN.1
+
+ If using the STRONGLY DISCOURAGED two dimensional directory model,
+ "ASN.1" SHOULD express the RECOMMENDED DN syntax indicated:
+
+ dotNotation=2.1,ou=Registrations,o=rA
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 17]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.2.2.3. X
+
+ dn: n=24,n=0,n=0,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iTUTRegistration
+ objectClass: x660Context
+ objectClass: x680Context
+ n: 24
+ description: Series X of ITU-T Recommendations "Data networks,
+ open system communications and security"
+ aSN1Notation: {itu-t(0) recommendation(0) x(24)}
+ dotNotation: 0.0.24
+ iRI: /ITU-T/Recommendations/X
+ standardizedNameForm: {x}
+ unicodeValue: X
+
+ If using the STRONGLY DISCOURAGED two dimensional directory model,
+ "X" SHOULD bear the RECOMMENDED DN syntax for this model:
+
+ dn: dotNotation=0.0.24,ou=Registrations,o=rA
+
+3.2.2.2.4. The "OID Directory"
+
+ This section describes a small portion of the OID registrations
+ officiated by this ID series. Note that the entire ancestry is
+ not shown for reasons of significant brevity.
+
+ The same twoDimensional DN syntax scheme shall apply, as mentioned
+ in previous sections, when using the STRONGLY DISCOURAGED two
+ dimensional directory model.
+
+ Note the referenced 'firstAuthority' entry DN, which bears the value
+ "a0efcce18a" for 'registrantID', is defined in Section 3.2.1.1.1.
+
+ dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x660Context
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ firstAuthority: registrantID=a0efcce18a,ou=Registrants,o=rA
+ registrationURI: https://www.iana.org/assignments/enterprise-
+ numbers/
+ description: Jesse Coretta
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521}
+ dotNotation: 1.3.6.1.4.1.56521
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521
+
+
+
+Coretta Expires August 27, 2024 [Page 18]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ dn: n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: The OID Directory
+ identifier: oid-directory
+ nameAndNumberForm: oid-directory(101)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)}
+ dotNotation: 1.3.6.1.4.1.56521.101
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101
+
+ dn: n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: Directory Schema
+ identifier: schema
+ nameAndNumberForm: schema(2)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2
+
+ dn: n=3,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: Attribute Types
+ identifier: attributeTypes
+ nameAndNumberForm: at(3)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2) attributeTypes(3)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2.3
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2/3
+
+
+
+
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 19]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ dn: n=1,n=3,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: Number Form
+ isLeafNode: TRUE
+ identifier: n
+ secondaryIdentifier: numberForm
+ nameAndNumberForm: n(1)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2) attributeTypes(3) n(1)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2.3.1
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2/3/1
+
+ dn: n=5,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: Object Classes
+ identifier: objectClasses
+ nameAndNumberForm: objectClasses(5)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2) objectClasses(5)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2.5
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2/5
+
+ dn: n=1,n=5,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: Registration AUXILIARY Class
+ isLeafNode: TRUE
+ identifier: registration
+ nameAndNumberForm: registration(1)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2) objectClasses(5) registration(1)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2.5.1
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2/5/1
+
+
+
+
+Coretta Expires August 27, 2024 [Page 20]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ dn: n=7,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: Name Forms
+ identifier: nameForms
+ nameAndNumberForm: nameForms(7)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2) nameForms(7)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2.7
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2/7
+
+ dn: n=1,n=7,n=2,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: Root Arc Name Form
+ isLeafNode: TRUE
+ identifier: nRootArcForm
+ nameAndNumberForm: nRootArcForm(1)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ schema(2) nameForms(7) nRootArcForm(1)}
+ dotNotation: 1.3.6.1.4.1.56521.101.2.7.1
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/2/7/1
+
+ dn: n=3,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: The RA DIT
+ identifier: rA-DIT
+ secondaryIdentifier: dIT
+ nameAndNumberForm: rA-DIT(3)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ rA-DIT(3)}
+ dotNotation: 1.3.6.1.4.1.56521.101.3
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/3
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 21]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ dn: n=1,n=3,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ description: Directory Models
+ identifier: models
+ nameAndNumberForm: models(1)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ rA-DIT(3) models(1)}
+ dotNotation: 1.3.6.1.4.1.56521.101.3.1
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/3/1
+
+ dn: n=2,n=1,n=3,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: The Two Dimensional Model
+ isLeafNode: TRUE
+ identifier: twoDimensional
+ nameAndNumberForm: twoDimensional(2)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ rA-DIT(3) models(1) twoDimensional(2)}
+ dotNotation: 1.3.6.1.4.1.56521.101.3.1.2
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/3/1/2
+
+ dn: n=3,n=1,n=3,n=101,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: x680Context
+ objectClass: registrationSupplement
+ description: The Three Dimensional Model
+ isLeafNode: TRUE
+ identifier: threeDimensional
+ nameAndNumberForm: threeDimensional(3)
+ aSN1Notation: {iso(1) identified-organization(3) dod(6)
+ internet(1) private(4) enterprise(1) 56521 oid-directory(101)
+ rA-DIT(3) models(1) threeDimensional(3)}
+ dotNotation: 1.3.6.1.4.1.56521.101.3.1.3
+ iRI: /ISO/Identified-Organization/6/1/4/1/56521/101/3/1/3
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 22]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.2.2.5. Registration Ranges
+
+ This section demonstrates finite and infinite registration ranges.
+
+ dn: n=0,n=171,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: registrationSupplement
+ description: Total/Infinite Range (1.3.6.1.4.1.56521.999.171.*)
+ registrationRange: -1
+
+ dn: n=10,n=401,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: iSORegistration
+ objectClass: registrationSupplement
+ description: Finite Range (1.3.6.1.4.1.56521.999.401.10-19)
+ registrationRange: 19
+
+3.2.3. Value Forms
+
+ Attribute type instances residing within the RA DIT may, or may not,
+ manifest in a few different ways, each of which are covered in the
+ following subsections.
+
+3.2.3.1. Composite
+
+ Consider the 'nameAndNumberForm' attribute type, per Section 2.3.19
+ of the RASCHEMA ID. This attribute type combines the 'identifier'
+ and 'n' attribute types to form a complete value, for instance:
+
+ identified-organization(3)
+
+ The RA DIT MAY opt for composite or "virtual" assembly of an instance
+ of this attribute type by the RA DUA. This negates the need for this
+ instance to be stored within an entry in literal fashion, though ONLY
+ if the aforementioned constituent types are present within the entry.
+
+ In addition to the 'nameAndNumberForm' attribute type, 'aSN1Notation'
+ also qualifies for this design strategy. This type is a sequence of
+ one (1) or more 'nameAndNumberForm' or 'numberForm' values -- whether
+ composite or literal -- as derived from multiple superior entries.
+ Note this is only practical within three dimensional implementations,
+ and only when the entire ancestry is thoroughly populated and mapped
+ spatially using attribute types extended via the 'spatialContext'
+ AUXILIARY object class.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 23]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ The most obvious benefit to the composite approach is the reduced
+ storage space required for preservation of literal attribute values.
+ The degree of "savings" is naturally proportional to the overall size
+ of the RA DIT.
+
+ A significant drawback, however, is (likely) limited client support.
+ In order for composite values to be extrapolated by any client, the
+ client must first be aware of the necessary "component" types which
+ are required in order to produce a composite value.
+
+ Performance may also be a concern when composite values are assembled
+ using a lengthy sequence of superior entries, or if the operational
+ state of the RA DSA is suboptimal in some manner.
+
+3.2.3.2. Literal
+
+ Contrary to the theory described in Section 3.2.3.1, literal values
+ are set to provide clients with access to needed information without
+ any "assembly" required. This is the standard approach to managing
+ an attribute type value.
+
+ The benefits and drawbacks of this approach are the direct inverse of
+ those described in Section 3.2.3.1. Storage space requirements would
+ increase, while client capability and performance issues are abated.
+
+ In general, this is the RECOMMENDED approach for RA DIT population
+ as opposed to composite values.
+
+3.2.3.3. Collective
+
+ Section 2.3 of the RASCHEMA ID defines collective attribute types
+ to parallel certain attribute types which may apply to a great many
+ entries in the context of a subtree within the RA DIT.
+
+ In thorough implementations of this ID series, this can often provide
+ considerable savings in terms of administrative effort in addition to
+ reduced risk relating to potentially content updates applied manually
+ to the RA DIT. In such cases, collective attributes are RECOMMENDED.
+
+ Every attribute type in collective form is conceptually based upon a
+ non-collective equivalent attribute type, both in use and in context
+ (e.g.: 'topArc' and 'c-topArc').
+
+ Configuration for [RFC3671] support varies across X.500/LDAP products
+ but most situations involve use of the 'subtreeSpecification' type in
+ some fashion. This type is used to limit the influence of collective
+ attribute operations within the context of a subtree.
+
+ While this ID series does not delve into the particulars of specific
+ implementation steps for any given X.500/LDAP product, it does offer
+ certain 'subtreeSpecification' examples where appropriate.
+
+
+Coretta Expires August 27, 2024 [Page 24]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Specific methodologies relating to use varies greatly among the
+ potential X.500/LDAP DSA products available today. For the purposes
+ of simplicity, this ID assumes that 'subtreeSpecification' instances
+ are assigned to subentries of the relevant directory entry.
+
+3.2.4. Special Attributes
+
+ This section outlines certain important attribute types extended via
+ Section 2.3 of the RASCHEMA ID.
+
+3.2.4.1. 'n'
+
+ This attribute type plays a CRUCIAL role with regards to the syntax
+ of DNs used in the three dimensional directory model. It is the only
+ attribute type defined in this ID REQUIRED for ALL registrations --
+ root or not -- without exception.
+
+ Instances of this attribute type SHALL NOT be negative, and SHALL NOT
+ appear on entries other than 'registration' entries. Instances of
+ this type MUST remain unique among horizontal (sibling) entries.
+
+ UUID-based OID registrations, by way of ITU-T Rec. [X.667], are
+ dependent upon proper underlying ASN.1 INTEGER syntax support. The
+ value of 'n' MUST be the integer form of the hexadecimal UUID value.
+
+ X.500/LDAP implementations or architectures incapable of supporting
+ unsigned integers greater than or equal to 128 bits in length are
+ ineligible for support and processing of such registrations by way
+ of this type.
+
+ Instances of this attribute type represent the start of a range of
+ registration allocations when present in entries that also bear an
+ instance of the 'registrationRange' attribute type, which signifies
+ the terminus of an allocated OID range.
+
+ This attribute type is defined in Section 2.3.1 of the RASCHEMA ID.
+
+3.2.4.2. 'dotNotation'
+
+ This attribute type plays a crucial role with regards to DN syntax
+ used in the two dimensional directory model described within the
+ RADIT ID. It cannot be assigned to registration entries which bear
+ the 'rootArc' STRUCTURAL object class.
+
+ Instances of this attribute type SHALL NOT appear on entries other
+ than 'registration' entries, and MUST be unique throughout an RA DIT.
+
+ Use of this attribute type is entirely OPTIONAL within RA DITs based
+ upon the RECOMMENDED three dimensional directory model.
+
+ This attribute type is defined in Section 2.3.2 of the RASCHEMA ID.
+
+
+Coretta Expires August 27, 2024 [Page 25]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.4.3. 'registrationInformation'
+
+ This attribute type allows extended information to be assigned to
+ any registration. It is based upon the ASN.1 OCTET STRING syntax.
+
+ While use of this syntax does allow for NULL values, it is considered
+ invalid within the context of this ID. In cases where no extended
+ information is available for a given registration, instances of this
+ attribute type SHOULD NOT be set for the entry.
+
+ This attribute type is defined in Section 2.3.9 of the RASCHEMA ID.
+
+3.2.4.4. 'registrationModified'
+
+ This attribute type identifies any number of generalized timestamps
+ that pinpoint previous modifications to a registration.
+
+ When appropriate, this attribute type may be used to represent the
+ "LAST-UPDATED" definition as shown in Section 2 of [RFC2578], but
+ may also be used to record any known modification date.
+
+ Whether multiple dates, or merely the most recent date, are stored in
+ the directory is entirely up to the administrator(s) involved.
+
+ This type is defined in Section 2.3.12 of the RASCHEMA ID.
+
+3.2.4.5. 'registrationRange'
+
+ This attribute type stores the numerical representation of the end
+ of an allocation range. The start of the range is defined using
+ the 'n' attribute type value.
+
+ The value of this attribute MUST always be greater than the value
+ of 'n' EXCEPT when using "-1".
+
+ For example, if a 'registrationRange' attribute value of '999' were
+ set for the OID '2.999.44', it MUST be interpreted as an entire range
+ of OIDs starting at '2.999.44' up to and including '2.999.999'. This
+ represents a finite range and means, without exception, that further
+ sibling allocations MUST be defined outside of this, and any other,
+ defined boundary.
+
+ Similarly, keeping with the same example above, if the value of "-1"
+ were used instead, this MUST be interpreted as an all-encompassing
+ OID range starting at '2.999.44' with no upper limit, representing
+ an infinite range. This means, without exception, that no further
+ sibling allocations greater than 'n' will be permitted.
+
+ This type is defined in Section 2.3.13 of the RASCHEMA ID.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 26]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.4.6. 'registrationStatus'
+
+ This attribute type associates a particular allocation status value
+ to a registration.
+
+ Multiple values can be provided, provided they remain meaningful in
+ the particular combination.
+
+ In most cases, the attribute type is used in order to mark an OID
+ registration as OBSOLETE, RESERVED, PRIVATE or DEALLOCATED.
+
+ Section 2 of [RFC2578] also defines "current" and "deprecated" for
+ use in this context.
+
+ Values of "active" or "in-force" may be used, though generally this
+ is OPTIONAL.
+
+ Absence of this attribute type within a given entry MAY be viewed
+ as an implied deference to the 'registrationStatus' value held by
+ a relevant ancestral registration, if applicable. In the absence
+ of information to the contrary, lack of this value could imply the
+ "active", "current" or "in-force" declarations, however this is not
+ definitive and may vary across implementations.
+
+ A value of "private" MAY be used a component in any access control
+ mechanics defined by the directory architect(s), but at the risk of
+ possible performance costs depending on implementation.
+
+ Other possible values not listed here MAY be used, however they would
+ be wholly proprietary in nature.
+
+ This type is defined in Section 2.3.14 of the RASCHEMA ID.
+
+3.2.4.7. 'registrationClassification'
+
+ This attribute type associates a classification with a registration.
+
+ While independent of the 'registrationStatus' attribute type defined
+ in Section 2.3.14, there may be cases of overlap with respect to the
+ declaration of obsolescence or deallocation for a given registration,
+ as both attribute types recognize and express such states.
+
+ This type is defined in Section 2.3.15 of the RASCHEMA ID.
+
+3.2.4.8. 'isLeafNode'
+
+ This attribute type serves to declare a registration as the terminus
+ of an ancestry using a Boolean TRUE or FALSE.
+
+ Absence of this attribute type SHOULD be interpreted as an implicit
+ FALSE value. This is the most common scenario.
+
+
+Coretta Expires August 27, 2024 [Page 27]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ A value of FALSE indicates there are no restrictions regarding the
+ allocation of child entries.
+
+ A value of TRUE indicates the registration SHALL NOT be a parent of
+ any subordinate registrations whatsoever.
+
+ Instances of this attribute type are not to be interpreted in any
+ recursive context. Leaf-node status of a registration precludes
+ any additional subtree context.
+
+ This attribute type is NOT intended to serve in a security capacity.
+ Presence of this attribute type is mainly used to alert any RA DUA
+ that is optimized for this ID that neither subordinate enumeration,
+ nor subordinate allocation, be attempted below the indicated entry.
+
+ A registration that lacks subordinate entries is not necessarily a
+ leaf-node. Lack of this status could mean subordinate allocations
+ might occur in the future. Leaf-node status is meant for use in
+ permanent contexts.
+
+ This type is defined in Section 2.3.16 of the RASCHEMA ID.
+
+3.2.4.9. 'isFrozen'
+
+ This attribute type serves to identify a registration as frozen using
+ a Boolean TRUE or FALSE.
+
+ The condition of a registration being frozen indicates allocations of
+ subordinate registrations of the bearer will not be honored.
+
+ The condition of a frozen state is not necessarily permanent.
+
+ A value of TRUE indicates that the given registration SHALL NOT honor
+ any subordinate allocations. Preexisting subordinate registration
+ entries will be unaffected and may be queried freely by the RA DUA.
+
+ Preexisting subordinate registration entries are considered frozen,
+ regardless of vertical distance from the bearer of this type.
+
+ A value of FALSE indicates there are no restrictions regarding the
+ allocation of any subsequent child entries.
+
+ An administratively-focused RA DUA MAY override the semantics of this
+ attribute type in the context of historical input or another similar
+ use case.
+
+ This type is defined in Section 2.3.17 of the RASCHEMA ID.
+
+3.2.4.10. 'longArc'
+
+ This attribute type allows Long Arc instances to be assigned to a
+ registration.
+
+Coretta Expires August 27, 2024 [Page 28]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Per [X.660], entries that bear values of this attribute type MUST
+ ONLY reside below the root joint-iso-itu-t(2) registration.
+
+ In other words, OID registrations subordinate to either the itu-t(0)
+ or iso(1) roots that bear a 'longArc' instance are considered bogus.
+
+ DUAs optimized for this ID SHALL NOT allow routine presentation or
+ modification (beyond corrective removal) of bogus 'longArc' values
+ in this context.
+
+ This type is defined in Section 2.3.20 the of the RASCHEMA ID.
+
+ The 'minArc' and 'c-minArc' attribute types are defined in Section
+ 2.3.27 and 2.3.28 of the RASCHEMA ID.
+
+ The 'maxArc' and 'c-maxArc' attribute types are defined in Section
+ 2.3.30 and 2.3.31 of the RASCHEMA ID.
+
+3.2.4.11. 'discloseTo'
+
+ This attribute type -- and its collective counterpart -- is used to
+ identify authorized readers of otherwise private entries, typically
+ registrations.
+
+ This MAY cover any depth of subordinate entry disclosures as seen fit
+ by the directory architect(s) or administrator(s).
+
+ Identities referenced through instances of this attribute type can be
+ single user entries, a 'groupOfNames'-based entry, per Section 3.5 of
+ [RFC4519], a current authority or sponsorship registrant, or even an
+ effective Proxy Authorization identity, per [RFC4370].
+
+ Write-based access SHOULD NOT be governed by this attribute type, as
+ that is an intended function of a (current) registration authority.
+
+ The 'discloseTo' and 'c-discloseTo' attribute types are defined in
+ Section 2.3.32 and 2.3.33 of the RASCHEMA ID respectively.
+
+3.2.4.12. 'registrantID'
+
+ This attribute type is meant for assignment to registrant entries for
+ the purpose of unambiguous reference.
+
+ In larger, more complete implementations of this specification, it
+ is RECOMMENDED that this attribute type be the primary identifier
+ (or, RDN) for dedicated registrant entries.
+
+ Combined registrant entries have no particular use for this attribute
+ type. Instances of this type SHALL NOT appear on entries bearing the
+ 'registration' ABSTRACT class, defined within Section 2.5.1 of the
+ RASCHEMA ID.
+
+
+Coretta Expires August 27, 2024 [Page 29]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ For distinguished registrants -- such as an RFC or ID -- the official
+ identifier MAY be used as an alternative to an auto-generated value.
+
+ This type is defined in Section 2.3.34 of the RASCHEMA ID.
+
+3.2.4.13. 'firstAuthority', 'currentAuthority' and 'sponsor'
+
+ These attribute types -- and their collective counterparts -- are for
+ use in identifying registrant entries which describe individuals,
+ groups and other entities that serve in authority over registrations.
+
+ These attribute types are only intended for use in referencing
+ dedicated registrants, which each bear the 'registrant' STRUCTURAL
+ object class. Instances of these types are meant for assignment
+ to 'registration' entries of any kind.
+
+ The 'firstAuthority' and 'c-firstAuthority' attribute types are
+ defined in Sections 2.3.35 and 2.3.36 of the RASCHEMA ID.
+
+ The 'currentAuthority' and 'c-currentAuthority' attribute types are
+ defined in Sections 2.3.55 and 2.3.56 of the RASCHEMA ID.
+
+ The 'sponsor' and 'c-sponsor' attribute types are defined in Sections
+ 2.3.74 and 2.3.75 of the RASCHEMA ID.
+
+ Any combination of these attribute types and their collective forms
+ as instances within a common 'registration' entry is acceptable so
+ long as the respective reference values are unique in context.
+
+3.2.4.14. 'rADITProfile'
+
+ This attribute type references optimal 'rADUAConfig' configuration
+ settings stored within entries in an RA DIT. This information is
+ meant for direct consumption by RA DUAs.
+
+ Use of this attribute type is only meaningful in situations where
+ multiple independent RA DITs are served by a single RA DSA.
+
+ Instances of this type MUST NOT be assigned to entries which bear the
+ 'rARegistration' and/or 'rARegistrant' attribute types.
+
+ See the RADSA ID for details regarding use of this attribute type.
+
+ This type is defined in Section 2.3.94 of the RASCHEMA ID.
+
+3.2.4.15. 'rARegistrationBase' and 'rARegistrantBase'
+
+ These attribute types contain references to the registration and
+ registrant bases within an RA DIT. The RA DUA reads these values
+ to determine where particular operations shall be conducted.
+
+
+
+Coretta Expires August 27, 2024 [Page 30]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Instances of these types MUST NOT be assigned to entries which bear
+ the instances of the 'rADITProfile' attribute type.
+
+ See the RADSA ID for details regarding use of this attribute type.
+
+ These attribute types are defined in Sections 2.3.95 and 2.3.96 of
+ the RASCHEMA ID respectively.
+
+3.2.4.16. 'registeredUUID'
+
+ This attribute type is intended to store a UUID value in hexadecimal
+ form that is equivalent to the 'n' value held by the same entry.
+
+ For example, consider the registration "{joint-iso-itu-t(2) uuid(25)
+ ans(987895962269883002155146617097157934)}":
+
+ 'n' - 987895962269883002155146617097157934
+ 'registeredUUID' - 00be4308-0c89-1085-8ea0-0002a5d5fd2e
+
+ The two values are identical; 'n' is simply being represented as an
+ unsigned 128-bit integer and 'registeredUUID' is the equivalent value
+ represented via hexadecimal encoding.
+
+ This type is meant for use in the context of ITU-T Rec. X.667 and is
+ defined within Section 2.3.102 of the RASCHEMA ID.
+
+3.2.4.17. 'description'
+
+ The 'description' attribute type is defined within Section 2.5 of
+ [RFC4519] and clause 6.5.1 of ITU-T Rec. X.520. This attribute type
+ is included within the MAY clauses of certain object classes extended
+ by this ID series.
+
+ The purpose of the 'description' attribute type in the context of a
+ 'registration' entry is to assign the effective "title" of the entry.
+
+ For example, the 'description' of the '1.3.6.1.4.1.56521.101.3.1.3'
+ OID would read 'The Three Dimensional Model'. This value is meant
+ to be distinct from, and far less verbose than, any value assigned to
+ the 'registrationInformation' type.
+
+ While there is no specific use case for 'registrant' entries within
+ the terms of this ID series, the 'description' attribute type is
+ nonetheless permitted.
+
+3.2.4.18. 'seeAlso'
+
+ The 'seeAlso' attribute type is defined in Section 2.30 of [RFC4519]
+ and clause 6.10.6 of ITU-T Rec. X.520.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 31]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Under the terms of this ID series, the 'seeAlso' attribute type is
+ used to describe associations between multiple entries of related
+ context, and is made available through use of certain object classes
+ extended by this ID series.
+
+ To offer a practical use case, the OID which identifies the Kingdom
+ of the Netherlands Registration Authority (0.2.205) also refers to
+ the OID 0.2.204 and vice versa. This is the most common use case.
+
+ The 'seeAlso' attribute type may also be used to provide a reverse
+ associative context to registrants in terms of which registrations
+ are subject to its ministrations. This is the reversed concept of
+ 'firstAuthority', 'currentAuthority' and 'sponsor' type instances,
+ however this use case is typically not required outside of certain
+ audit related activities.
+
+3.2.4.19. Spatial References
+
+ Section 2.3 of the RASCHEMA ID extends eleven (11) attribute types
+ that describe both the horizontal and vertical arrangement of various
+ sibling, superior and subordinate registrations using the respective
+ DNs of entries. These attribute types may be used in any directory
+ model defined in this ID series, and many are extended by way of the
+ 'spatialContext' class defined in Section 2.5 of the RASCHEMA ID.
+
+ The RA DIT SHALL NOT utilize both a non-collective and collective
+ spatial attribute type of the same spirit. For example, it is NOT
+ permitted for a registration entry to bear instances of both the
+ 'topArc' and 'c-topArc' types -- regardless of respective values.
+
+ The RA DIT MAY, however, utilize both non-collective and collective
+ spatial types of differing forms. For example, it is permitted for a
+ registration to bear instances of the 'c-topArc' and 'supArc' types.
+
+ References of any attribute type prefaced with the 'c-' flag implies
+ Collective Attribute operation. Positive support for this feature on
+ part of the RA DSA(s) in question is REQUIRED for use of these types.
+
+ With the exception of the 'subArc' attribute type, all spatial types
+ extended through this ID series are meant for SINGLE-VALUE contextual
+ use cases -- including collective spatial types.
+
+3.2.4.19.1. Horizontal Sibling References
+
+ The 'minArc', 'maxArc', 'leftArc' and 'rightArc' attribute types are
+ defined in order to describe horizontal relationships among sibling
+ registrations. The following diagram describes these relationships:
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 32]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ example registration
+ (1.3.6.1.4.1.56521.999.140)
+ |
+ less than < | > greater than
+ +---+--------+---+---+---+--------+---+
+ | 0 |........|139|140|141|........|200|
+ +---+--------+---+---+---+--------+---+
+ | | | |
+ minimum left right maximum
+
+ To offer an example of these relationships expressed as an LDIF:
+
+ dn: n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: spatialContext
+ ou=Registrations,o=rA
+ leftArc: n=139,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ rightArc: n=141,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ minArc: n=0,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ maxArc: n=200,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+
+ The 'minArc' and 'maxArc' types describe the absolute extremes of a
+ set of sibling registrations, where 'minArc' describes the absolute
+ "first" registration in a set of sibling registrations and 'maxArc'
+ describes the absolute "final" registration. The 'c-minArc' and
+ 'c-maxArc' collective variants serve the same function, except they
+ are meant for assignment to an entire set of sibling registrations.
+
+ Determination of so-called "first" and "final" status is based upon
+ the lowest and highest values of the 'n' attribute type present in
+ the set of sibling registrations. The definitive values MUST ALWAYS
+ be consistent for ALL sibling registration entries without exception.
+
+ See the RADUA ID for considerations relating to RA DUA queries
+ of a set of siblings terminated using a 'registrationRange' value,
+ whether the range is finite or infinite in nature.
+
+ The 'leftArc' and 'rightArc' types describe the immediate sibling
+ registrations horizontally adjacent to the bearer. The 'leftArc'
+ type references the DN of the nearest sibling registration with an
+ 'n' value less than that of the bearer, while the 'rightArc' type
+ references the DN of the nearest sibling registration with an 'n'
+ value greater than that of the bearer.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 33]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Contrary to minimum and maximum values, the effective left and right
+ values are always registration specific, and shall not be considered
+ valid candidates for collective assignment. This exposes a potential
+ administrative challenge in the midst of many sibling entries.
+
+ In cases where 'leftArc' and 'minArc' would share a common value,
+ both values should be specified for optimal client support.
+
+ In cases where 'rightArc' and 'maxArc' would share a common value,
+ both values should be specified for optimal client support.
+
+3.2.4.19.1.1. Collective Use
+
+ The 'minArc' and 'maxArc' attribute types have collective variants,
+ identified by identical names prefaced with the requisite 'c-' flag.
+ Use of these collective attributes instead of their non-collective
+ incarnations can greatly ease the cost and tedium of the management
+ of potentially huge sets of sibling entries.
+
+ As the 'c-minArc' and 'c-maxArc' attribute types relate to a minimum
+ and maximum number form common to multiple siblings, the appropriate
+ 'subtreeSpecification' value MUST be limited to ONLY the immediate
+ children of the specified parent:
+
+ "{ base 'n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1',
+ minimum 1, maximum 1 }"
+
+3.2.4.19.2. Superior Vertical References
+
+ The 'supArc' and 'topArc' attribute types are used to reference the
+ DNs of the immediate superior registration as well as the appropriate
+ root registration.
+
+ dn: n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: spatialContext
+ topArc: n=1,ou=Registrations,o=rA
+ supArc: n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+
+ Superior vertical references, in general, are far simpler to manage
+ and implement as compared to subordinate vertical references because
+ of their unchanging nature.
+
+ In cases where 'supArc' and 'topArc' would share a common value,
+ both values should be specified for optimal client support.
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 34]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+3.2.4.19.2.1. Collective Use
+
+ The collective form of these types, as identified by identical names
+ prefaced with the requisite 'c-' flag, serve an identical function
+ but on a grand scale. Using the 'c-topArc' attribute type can allow
+ potentially millions of subordinate registrations to bear the correct
+ root arc DN without the need for manual input.
+
+ As the 'c-supArc' attribute type relates to the immediate vertical
+ association, the appropriate 'subtreeSpecification' value MUST be
+ limited to ONLY the immediate children of the specified parent:
+
+ "{ base 'n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1',
+ minimum 1, maximum 1 }"
+
+ As the 'c-topArc' attribute type is in service to a vertically global
+ association for ALL subordinate registrations without exception, the
+ appropriate 'subtreeSpecification' value MUST NOT be limited to any
+ particular hierarchical depth. Assuming the three dimensional model
+ is in use, the 'subtreeSpecification' setting should reflect the
+ following value for all ISO ("{iso(1)}") registrations:
+
+ "{ base 'n=1' }"
+
+3.2.4.19.3. Subordinate Vertical References
+
+ The multi-valued 'subArc' attribute type defined in the RASCHEMA ID
+ allows the storage of immediate subordinate registration DNs for a
+ (parent) registration. Client architectures which read the values
+ assigned to this type will receive an effective "list" of any and
+ all subordinate registrations for the given registration.
+
+ This attribute type exists solely to facilitate a performant means of
+ subordinate registration DN enumeration. This is the RECOMMENDED
+ alternative to explicit List Operations, which may prove to be costly
+ in the midst of particularly large sets of subordinate registrations.
+
+ For instance:
+
+ dn: n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ objectClass: registration
+ objectClass: arc
+ objectClass: spatialContext
+ subArc: n=1,n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ subArc: n=2,n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+ subArc: n=3,n=140,n=999,n=56521,n=1,n=4,n=1,n=6,n=3,n=1,
+ ou=Registrations,o=rA
+
+
+
+Coretta Expires August 27, 2024 [Page 35]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ Instead, enumerated subordinate registration DNs may be retrieved
+ by way of the Read Operation of the superior entry. When retrieved,
+ the RA DUA reads subordinate entries using DN references alone.
+
+ One of the administrative challenges of this approach is the (proper)
+ ordering of respective DNs assigned to this type. Depending on the
+ manner in which data was originally written to the RA DIT, sequential
+ ordering of numeric (leaf-node) values may not manifest as expected.
+
+ Certain X.500/LDAP implementations allow sorting of DN-based entry
+ values, such as 'member' (per Section 2.17 of [RFC4519]) for large
+ groups or email distribution lists. Sorting of this form may be
+ possible, though at the risk of RA DSA performance penalties.
+
+ Alternatively, the RA DUA MAY perform the necessary sort operation if
+ it is given this capability.
+
+4. IANA Considerations
+
+ There are no requests to IANA in this document.
+
+5. Security Considerations
+
+5.1. Access Control
+
+ See Section 4.3 of the RADSA ID for access control considerations.
+
+5.2. Creation and Modification Identities
+
+ If the operational attributes 'creatorsName' and/or' 'modifiersName'
+ (as defined in Sections 3.4.1 and 3.4.3 of [RFC4512] respectively)
+ are exposed, directory architects MAY opt to use Proxy Authorization
+ Controls, per [RFC4370], to allow an asserted (proxied) identity to
+ effect the necessary changes without exposing the true identity.
+
+ An appropriate proxy identity could be the distinguished name of the
+ registrant referenced by the 'currentAuthority' or 'sponsor' types,
+ or even a given registration entry itself. In either case, this will
+ require [RFC4370] support -- a topic out of scope for this ID.
+
+6. References
+
+6.1. Normative References
+
+ RADIR Coretta, J., "The OID Directory: A Technical Roadmap",
+ draft-coretta-oiddir-roadmap, February 2024.
+
+ RADSA Coretta, J., "The OID Directory: The RA DSA",
+ draft-coretta-oiddir-radsa, February 2024.
+
+ RADUA Coretta, J., "The OID Directory: The RA DUA",
+ draft-coretta-oiddir-radua, February 2024.
+
+Coretta Expires August 27, 2024 [Page 36]
+
+ Internet-Draft The OID Directory: RA DIT 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.
+
+ [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.
+
+ [RFC4517] Legg, Ed., S., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, June
+ 2006.
+
+ [RFC4524] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): COSINE LDAP/X.500 Schema", RFC 4524, June 2006.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", RFC 8174, May 2017.
+
+ [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.
+
+6.2. Informative References
+
+ [RFC1155] Rose, M., "Structure and Identification of Management
+ Information for TCP/IP-based Internets", RFC 1155, May
+ 1990.
+
+ [RFC2696] C. Weider, A. Herron, A. Anantha, Microsoft, T. Howes
+ and Netscape, "LDAP Control Extension for Simple Paged
+ Results Manipulation", RFC 2696, September 1999.
+
+
+
+Coretta Expires August 27, 2024 [Page 37]
+
+ Internet-Draft The OID Directory: RA DIT February 2024
+
+
+ [RFC4370] Weltman, R., "Lightweight Directory Access Protocol
+ (LDAP): Proxy Authorization Control", RFC 4370, February
+ 2006.
+
+ [X.500] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Overview of
+ concepts, models and services", ITU-T X.500, October 2019.
+
+ [X.501] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Models", ITU-T
+ X.501, October 2016.
+
+ [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.
+
+ [X.672] International Telecommunication Union - Telecommunication
+ Standardization Sector, "OID resolution system: Problems,
+ requirements and potential solutions", ITU-T X.672, March
+ 2020.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ https://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Jesse Coretta
+ California, United States
+
+ Email: jesse.coretta@icloud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 38]
diff --git a/docs/specs/draft-coretta-oiddir-radsa-00.txt b/docs/specs/draft-coretta-oiddir-radsa-00.txt
new file mode 100644
index 000000000..5e0093735
--- /dev/null
+++ b/docs/specs/draft-coretta-oiddir-radsa-00.txt
@@ -0,0 +1,697 @@
+
+
+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]
diff --git a/docs/specs/draft-coretta-oiddir-radua-00.txt b/docs/specs/draft-coretta-oiddir-radua-00.txt
new file mode 100644
index 000000000..b5bf82b64
--- /dev/null
+++ b/docs/specs/draft-coretta-oiddir-radua-00.txt
@@ -0,0 +1,1451 @@
+
+
+RADUA J. Coretta
+Internet-Draft February 29, 2024
+Intended status: Experimental
+Obsoletes: X660LDAP
+Expires: August 27, 2024
+
+
+ The OID Directory: The RA DUA
+ draft-coretta-oiddir-radua-00.txt
+
+Abstract
+
+ In service to the "OID Directory" ID series, this ID covers design
+ strategies, requirements and procedures for the client 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 Client 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
+ 1.5. Parameter Abstraction ......................................3
+ 2. The RA DUA ......................................................3
+ 2.1. Defined Parameters .........................................4
+ 2.2. Procedures .................................................5
+ 2.2.1. Schema Availability ...................................5
+ 2.2.2. Configuration .........................................5
+ 2.2.3. Queries ..............................................10
+ 2.2.4. New Allocations ......................................17
+ 2.2.5. Allocation Updates ...................................22
+ 3. IANA Considerations ............................................23
+ 4. Security Considerations ........................................23
+ 5. References .....................................................23
+ 5.1. Normative References ......................................23
+ 5.2. Informative References ....................................24
+ Author's Address ..................................................25
+
+1. Introduction
+
+ The X.500 Directory User Agent represents the client component within
+ the traditional client/server model that interacts with any number of
+ X.500 Directory System Agents for the purposes of information access.
+
+ Within the terms of this ID series, the Directory User Agent serves
+ as a client of OID registration and registrant content, as retrieved
+ from a Registration Authority Directory Information Tree.
+
+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. Also,
+ see Sections 1.7 and 1.8 of the RADIR ID for generalized terms and
+ descriptions of significance to this ID series.
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 2]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+1.2.1. Definitions
+
+ The composite acronym "RA DUA" is hereby introduced within this ID.
+ The acronym abbreviates the aforementioned 'Registration Authority
+ Directory User Agent' term, which describes the 'client' component
+ implied within the client/server model relevant to this ID series.
+
+ The composite acronym "RA DSA" used throughout this ID is defined in
+ Section 1.2.1 of the RADSA ID.
+
+ The composite acronym "RA DIT" used throughout this ID is defined in
+ Section 1.2.1 of the RADIT ID.
+
+1.3. Intended Audience
+
+ This ID is intended for application designers, X.500/LDAP architects,
+ and other personnel tasked with supporting or designing components
+ related to the RA client/server model in service to this ID series.
+
+ General familiarity with the broad X.500/LDAP specification, as well
+ all supporting IDs cited in Section 2 of the RADIR ID is STRONGLY
+ RECOMMENDED.
+
+1.4. Parameter Abstraction
+
+ For simplicity in describing certain request or argument parameters
+ involving either DAP or LDAP operations in this ID, a simplified
+ abstraction of ASN.1 parameters is shown to aid RA DUA adopter.
+
+ For example, the following structure may be used to outline the
+ parameters of a Read or Search Operation to be conducted as part
+ of an RA DUA managed procedure.
+
+ baseObject = dn ; DN: see RFC4514 and X.501
+ scope = 0/1/2 ; eq. X.511 'subset'
+ typesOnly = bool or int ; see. X.511 'EntryInformationSelection'
+ ; and RFC4512 'SearchRequest'
+ filter = filter ; see X.511 and RFC4515
+ attributes = selection(s); see. X.511 'EntryInformationSelection'
+ ; and RFC4512 'AttributeSelector'
+
+ While the abstraction has favored the use of LDAP-focused parameters
+ derived from [RFC4511], adopters MAY assume similar directives
+ are applicable within the context of DAP unless otherwise indicated.
+
+2. The RA DUA
+
+ The RA DUA is a traditional X.500/LDAP client -- supporting most or
+ all of the standard operations defined throughout clauses 9 through
+ 12 of ITU-T Rec. X.511, and throughout Section 4 of [RFC4511] --
+ that has been OPTIMIZED for use within the terms of this ID series.
+
+
+Coretta Expires August 27, 2024 [Page 3]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.1. Defined Parameters
+
+ The RA DUA is expected to support the directory protocols facilitated
+ by the endpoint RA DSA(s), whether DAP, LDAP or both. Support for
+ connectivity via the OSI networking stack, TCP/IP or IPC socket by
+ the RA DUA is determined by the operational requirements of the RA
+ DSA(s) in question.
+
+ Support for parallel X.500 protocols -- such as DOP or DSP -- is not
+ specifically indicated.
+
+ No recommendations are made regarding the "appearance" or interactive
+ nature of the RA DUA (i.e.: TUI vs. GUI), nor are any recommendations
+ made regarding the specific language or framework used in its design.
+
+ No particular software license applied to the RA DUA is assumed.
+
+ The intended application may be for any end user in general, or it
+ may be administratively focused. The RA DUA may be obtained by the
+ general public, or it may be wholly proprietary and for internal use
+ only.
+
+ The capabilities of the RA DUA MAY be flexible to suit the end user,
+ or it may be strictly regimented, allowing few variations of behavior
+ in routine operations.
+
+ In situations where an RA DUA is designed solely for the query and
+ presentation of entries with no possibility of support for entry
+ modifications, adopters MAY forego implementation of operational
+ capabilities that are Write-focused in nature.
+
+ Application designers SHOULD make use of ONLY industry-recognized
+ X.500/LDAP APIs, SDKs or libraries in a manner compliant with all
+ "Best Practices" suggested by both the maintainer(s) and the authors
+ of the standards indicated.
+
+ The RA DUA is not necessarily user-managed. An RA DUA may manifest
+ in "clientless" form -- for example, facilitated through a web-based
+ application interface residing on the RA DSA(s) directly, thus acting
+ in the context of an abstract protocol gateway. These strategies may
+ prove useful in reducing both the effort required by the end-user in
+ order to access the service, as well as the costs of supporting the
+ end user.
+
+ Regardless of the design and deployment philosophies employed, the
+ primary focus of the RA DUA -- with particular emphasis on any and
+ all proposed optimizations -- is to reduce the tedium of access and
+ administration of potentially large registration and authority bases,
+ and to introduce protective controls meant to ensure integrity of all
+ relevant content within the RA DIT.
+
+
+
+Coretta Expires August 27, 2024 [Page 4]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.2. Procedures
+
+ The RA DUA SHALL observe the procedures defined in the following
+ subsections as it pertains to the query, allocation and maintenance
+ of 'registration' and 'registrant' entries within an RA DSA.
+
+2.2.1. Schema Availability
+
+ The RA DUA MUST obtain -- or possess complete foreknowledge of -- all
+ schema definitions officially defined in Section 2 of the RASCHEMA
+ ID as well as the schema definitions serving as super types for many
+ of the attribute types defined in Section 2.3 of the RASCHEMA ID.
+
+ In addition, the RA DUA MUST both recognize and honor any additional
+ DIT content rules, DIT structure rules and/or (additional) name forms
+ created by the directory architects or administrators after-the-fact.
+
+ Obtaining the necessary schema definitions is typically conducted in
+ either of the following manners, shown in order of preference.
+
+ - Through a direct Read of the 'subschemaSubentry' of the RA DSA
+ - Through manual processing of the (approved) schema file(s) based
+ upon the complete contents of the RASCHEMA ID
+
+ When obtaining the schema through use of a Read or Search Operation,
+ the schema SHOULD be refreshed at the commencement of a new RA DUA
+ session. This accounts for changes to the schema definitions that
+ may have taken place during runtime.
+
+ If the RA DSA has no apparent knowledge of the definitions to be used
+ for the query and/or allocation of registrations and/or registrants
+ within the RA DIT, the RA DUA MUST abandon attempts to interact with
+ the RA DSA. It is RECOMMENDED that, in this case, the RA DUA present
+ the user with error information describing the problem. This could
+ suggest an RA DSA configuration problem, or possibly that the wrong
+ RA DSA has been targeted by the RA DUA.
+
+2.2.2. Configuration
+
+ There are two (2) modes of RA DUA configuration: automatic or manual.
+
+ Section 2.3 of the RASCHEMA ID introduces a small handful of types
+ intended for "advertisement" by the RA DSA and for consumption by the
+ RA DUA. These attributes are as follows:
+
+ - 'rARegistrationBase' ; ex.: ou=Registrations,o=rA
+ - 'rARegistrantBase' ; ex.: ou=Registrants,o=rA
+ - 'rADirectoryModel' ; ex.: 1.3.6.1.4.1.56521.101.3.1.3
+ - 'rAServiceMail' ; ex.: support@ra.example.com
+ - 'rAServiceURI' ; ex.: https://ra.example.com
+ - 'rADITProfile' ; ex.: dc=example,dc=com
+ - 'rATTL' ; ex.: 86400
+
+Coretta Expires August 27, 2024 [Page 5]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ These attribute types are extended through use of the 'rADUAConfig'
+ AUXILIARY object class. See Section 2.3.6 of the RADSA ID for
+ usable examples involving this class.
+
+ Auto-discovery of these attribute types will require disclosure
+ privileges for the root DSE and any other entries that bear the
+ 'rADUAConfig' object class.
+
+ Though the particulars of the root DSE are well outside the scope of
+ this ID series, it is typically accessed by way of the Read Operation
+ executed upon a NULL baseObject.
+
+ Retrieval SHOULD be made conditional using the 'rADUAConfig' object
+ class as the filter AVA, and SHOULD involve attribute selection of
+ the types shown below.
+
+ filter = objectClass=rADUAConfig ; Require 'rADUAConfig'
+ attributes = rARegistrationBase
+ rARegistrantBase
+ rADirectoryModel
+ rAServiceMail
+ rAServiceURI
+ rADITProfile
+ rATTL
+
+ If zero (0) entries are returned as a result of the Read Operation,
+ this indicates any of the following:
+
+ - The RA DSA is not available
+ - The root DSE is not accessible, possibly due to access rights
+ - The root DSE is accessible, but lacks the 'rADUAConfig' class
+
+ Given any of these conditions, automatic parameter input has failed.
+ The RA DUA has no alternative other than manual parameter input.
+
+ If one (1) entry is returned, the root DSE is accessible and has been
+ configured for automatic input. The RA DUA SHOULD choose to proceed
+ with configuration using the values provided.
+
+ See Section 2.3.6 of the RADSA ID regarding the possible methods
+ for implementation of this entry with respect to multiple RA DITs
+ served by an RA DSA as opposed to a single RA DIT.
+
+ If manual input of configuration values is required, typically this
+ would require foreknowledge of the correct values, or access to an
+ informational resource which makes those values available.
+
+ In this scenario, the RA DUA MUST request the user follow a procedure
+ for manual input prior to use. Lack of proper configuration values
+ precludes any RA DUA session.
+
+
+
+Coretta Expires August 27, 2024 [Page 6]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.2.2.1. Processing
+
+ Following value input -- whether automatic or manual -- the acquired
+ values MUST be processed and validated.
+
+ The following subsections cover each 'rADUAConfig'-extended attribute
+ type in the context of runtime configuration of the RA DUA.
+
+2.2.2.1.1. 'rADITProfile'
+
+ The 'rADITProfile' attribute type stores any number of DN values,
+ each acting as a reference to a DIT-housed 'rADUAConfig' entry
+ which contains the standard configuration parameters required by
+ the RA DUA.
+
+ The 'rADITProfile' attribute type is a CRITICAL component within any
+ implementation in which the following conditions apply:
+
+ - Multiple RA DITs reside on a single RA DSA, with each RA DIT
+ accessed using potentially different configuration values
+ - Single RA DITs which bear usable configuration settings within
+ DIT entry contexts -- as opposed to storage within the root DSE
+
+ In either case, the root DSE SHALL NOT contain any of the attribute
+ types extended by the MAY clauses of the 'rADUAConfig' AUXILIARY
+ object class OTHER THAN the 'rADITProfile', 'rATTL', 'rAServiceMail',
+ and 'rAServiceURI' attribute types.
+
+ Similarly, referenced 'rADUAConfig' entries within an RA DIT SHALL
+ NOT bear instances of the 'rADITProfile' attribute type.
+
+ Instances where these attribute types are improperly combined within
+ entries is considered a "Duplicate RA Context Error" and represents
+ a serious operational deficiency that MUST be reported to the end
+ user. The RA DUA SHOULD fail the session or (optionally) allow for
+ administrative override if corrective measures are to be taken.
+
+2.2.2.1.2. 'rARegistrationBase'
+
+ The 'rARegistrationBase' attribute type is the most CRITICAL of all
+ attribute types related to RA DUA configuration.
+
+ The purpose of this multi-valued type is to store the DN(s) in which
+ 'registration' entries are stored. This parameter is REQUIRED, as it
+ prevents the need for inefficient broad-level Search Operations,
+ potentially within a particularly large directory information tree.
+
+ The RA DUA MUST handle the instance value(s) as follows:
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 7]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ 1. Verify presence and accessibility of entries identified by the
+ respective DN values using the Read Operation
+ 2. Determine whether the given entries bear the 'registration'
+ ABSTRACT object class
+ 2a. If the named entries DO NOT bear the 'registration' class, the
+ RA DUA must interpret the entries as simple organizational
+ containers housing 'registration' entries one (1) level below
+ 2b. If the named entries bear the 'registration' class, this is
+ indicative of an official starting-point for registration
+ content within the "OID Directory"
+ 3. Preserve these DNs for the remainder of the session, as they
+ will influence the various operations that may take place
+
+ In the case of condition "2a", a read-only RA DUA MAY opt to fail the
+ session if no 'registration' entries reside exactly one (1) level
+ beneath the apparent "organizational container" entry. The RA DUA
+ MAY allow for administrative override of this behavior, thereby
+ allowing retroactive registration creation within an implementation
+ not yet populated.
+
+2.2.2.1.3. 'rARegistrantBase'
+
+ The 'rARegistrantBase' attribute type is OPTIONAL in terms of RA DUA
+ configuration. It identifies one (1) or more DNs which lead to the
+ location of authority-related entries within the RA DIT.
+
+ The RA DUA MUST handle the value(s) associated with this type as
+ follows:
+
+ 1. Verify presence and accessibility of entries identified by the
+ respective DN values using the Read Operation
+ 2. Compare the DN values to those within the 'rARegistrationBase'
+ attribute type instance
+ 2a. If the DN values are identical, this implies use of combined
+ authority/registration entries in a single location within the
+ RA DIT -- a procedure that is generally discouraged
+ 2b. If the DN values are different, this implies use of dedicated
+ authority entries, which bear the 'registrant' STRUCTURAL
+ object class and reside in a location separate from that which
+ houses entries bearing the 'registration' STRUCTURAL Object
+ Class
+ 2c. If no DN values are specified within the 'rARegistrantBase'
+ attribute type instance, the RA DUA MAY interpret this as an
+ indication that no authority information is available within
+ the RA DIT, and associated authority attribute types SHOULD
+ NOT be requested by the RA DUA
+
+ In the case of "2a", the RA DUA SHOULD include all attribute types
+ specified within the 'currentAuthorityContext', 'sponsorContext' and
+ 'firstAuthorityContext' 'MAY' clauses for subsequent Read Operations
+ of 'registration' entries.
+
+
+Coretta Expires August 27, 2024 [Page 8]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ In the case of "2b", the RA DUA SHOULD include all attribute types
+ specified within 'currentAuthorityContext', 'sponsorContext' and
+ 'firstAuthorityContext' 'MAY' clauses for subsequent Read Operations
+ of 'registrant' entries.
+
+ Dedicated authority entries bearing the 'registrant' STRUCTURAL
+ object class should be located exactly one (1) level below each
+ specified 'rARegistrantBase' DN value within the RA DIT.
+
+ Depending on the nature of implementation of this ID series, it may
+ or may not be advisable to populate the 'rARegistrantBase' Attribute
+ Type for consumption by all clients indiscriminately. See Section
+ 5.2 of the RADIT ID for security considerations on this topic.
+
+2.2.2.1.4. 'rADirectoryModel'
+
+ The 'rADirectoryModel' type describes the abstract structure of the
+ RA DIT in terms of 'registration' layout and probable DN syntax. The
+ employed model shall have a profound influence on the manner in which
+ the RA DUA shall interact with the RA DIT.
+
+ A specified directory model is REQUIRED for proper functioning of the
+ RA DUA, whether directly or indirectly. The decided model specifier,
+ which MUST be a numeric OID, is declared using the 'rADirectoryModel'
+ attribute type.
+
+ Sections 3.1.2 and 3.1.3 of the RADIT ID define two (2) official
+ directory models and DN syntax schemes identified by the following
+ numeric OIDs:
+
+ - 'twoDimensional' (1.3.6.1.4.1.56521.101.3.1.2)
+ - 'threeDimensional' (1.3.6.1.4.1.56521.101.3.1.3)
+
+ In virtually every case, the 'threeDimensional' model is STRONGLY
+ RECOMMENDED for implementation and use, however RA DUAs SHOULD be
+ prepared to incorporate other models that could be defined in any
+ future extensions to this ID series.
+
+ The RA DUA MUST support use of the 'threeDimensional' model without
+ exception and to the letter of every recommendation set forth within
+ this ID series.
+
+ As stated clearly and in no uncertain terms within the originating
+ document, the 'twoDimensional' model is STRONGLY DISCOURAGED aside
+ from use in non-standard or particularly unusual scenarios.
+
+ The RA DUA MAY support use of the 'twoDimensional' model at the
+ discretion of the application designer. Support for this model
+ is purely OPTIONAL.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 9]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ The RA DUA MUST handle the value of this instance as follows:
+
+ 1. Determine whether the 'rADirectoryModel' attribute type has
+ been set with an explicit numeric OID
+ 1a. If NO numeric OID has been specified, use of the RECOMMENDED
+ 'threeDimensional' model is to be enforced by DEFAULT
+ 1b. If a numeric OID has been specified, identify the value as a
+ known and supported model OID and adjust RA DUA behavior in
+ accordance with prescribed procedures of the RADIT ID
+ 1c. If a numeric OID has been specified and is not immediately
+ identifiable within the terms of this ID series -- such as
+ a future extension of this standard -- the RA DUA MAY defer
+ to the specifics of the recommendation or ID from which the
+ OID originates OR the RA DUA MAY choose to fail the session
+ 2. Preserve the value for the remainder of the session, as it
+ will influence the specifics of operations that may occur
+
+ In the case of condition "1c", if the RA DUA chooses to fail the
+ session, the RA DUA SHOULD present the user with an error message
+ indicating the encounter with an unknown or as-of-yet unsupported
+ directory model identifier.
+
+2.2.2.1.5. Additional Parameters
+
+ The 'rAServiceMail' attribute type, when defined, contains any number
+ of email addresses meant for support or request purposes. Use of
+ this type in the RA DIT is OPTIONAL, but SHOULD be recognized by the
+ RA DUA when present.
+
+ The 'rAServiceURI' attribute type, when defined, contains any number
+ of URI values related to the service, such as terms of use, support
+ information, documentation and other resources. Use of this type in
+ the RA DIT is OPTIONAL, but SHOULD be recognized by the RA DUA when
+ present.
+
+ The 'rATTL' attribute type, when defined for an entry bearing the
+ 'rADUAConfig' class, imposes a global entry caching TTL value meant
+ for consumption and observance by qualified RA DUA implementations.
+ See Section 2.2.3.4 for details and semantics regarding assignment
+ and precedence strategies for a TTL.
+
+2.2.3. Queries
+
+ This subsection covers strictly read-related operations, such as the
+ location and presentation of a given 'registration' entry.
+
+2.2.3.1. Retrieving Entries
+
+ The RECOMMENDED procedure for retrieving an entry -- in any directory
+ model defined in this ID series -- is a Read Operation of the entry
+ by way of its DN. This will return either one (1) entry, or none.
+
+
+Coretta Expires August 27, 2024 [Page 10]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ Foreknowledge of the DN is required for a Read Operation attempt of
+ this fashion.
+
+ If the entry is a 'registration', the DN may be resolved by way of
+ the associated numeric OID using the appropriate process defined in
+ Section 3.1.
+
+ 'registration' entries may reference other 'registration' entries
+ using the spatial attribute types defined in Section 2.3 of the
+ RASCHEMA ID and discussed further in Section 2.2.3.3.
+
+ 'registrant' entries, however, aren't resolvable in any standard
+ manner. These are dedicated authority entries that are normally
+ accessed through references held by any associated 'registration'
+ entries.
+
+ - 'firstAuthority' and/or 'c-firstAuthority'
+ - 'currentAuthority' and/or 'c-currentAuthority'
+ - 'sponsor' and/or 'c-sponsor'
+
+ However, in cases where direct referencing of DNs within the context
+ of a Read Operation is not practical, possibly due to any of the
+ following ...
+
+ - Lack of assigned spatial reference types
+ - An unsupported or incoherent DN syntax is indicated
+ - Administrative operations are underway
+
+ Use of a List Operation or subtree Search Operation may be indicated.
+
+ While this method of searching is not generally recommended within
+ the spirit of this ID series, the RA DUA MAY allow this capability
+ where appropriate.
+
+ If the RA DUA encounters difficulty relating to a particularly large
+ number of entries retrieved through a Search Operation, support for
+ Simple Paged Results Manipulation by the RA DUA may be indicated if
+ supported by the RA DSA. For details, see clause 7.9 of ITU-T Rec.
+ X.511 and the entirety of [RFC2696].
+
+2.2.3.2. Reading Entries
+
+ The following subsections outline the procedures involved in the
+ presentation and analysis of a 'registration' or 'registrant' entry
+ successfully retrieved by way of the Read or Search Operation.
+
+2.2.3.2.1. Entry 'objectClass' Analysis
+
+ Given a successfully conducted Read or Search Operation, and assuming
+ a single entry -- whether 'registration' or 'registrant' -- has been
+ returned, the RA DUA SHOULD first read the 'objectClass' values and
+ make note of all that originate in Section 2.5 of the RASCHEMA ID.
+
+Coretta Expires August 27, 2024 [Page 11]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ The 'registration' ABSTRACT object class is a required class for any
+ OID allocation. This class MUST only appear on entries which bear
+ the 'rootArc' or 'arc' STRUCTURAL class. It is a sub type of the
+ 'top' ABSTRACT class, defined in Section 2.4.1 of [RFC4512] and in
+ clause 13.3.3 of ITU-T Rec. X.501.
+
+ The 'registrant' STRUCTURAL object class is only used for dedicated
+ registrants, which are associated through DN references held by
+ associated 'registration' entries, if any. Appearance upon any
+ other form of entry is a suboptimal or illogical state.
+
+ Presence of the 'x660Context' and/or 'x680Context' AUXILIARY classes
+ for a 'registration' entry is permitted. These object classes extend
+ multiple attribute types which conceptually relate to ITU-T Rec.
+ X.660 and X.680 respectively.
+
+ Presence of the 'x667Context' AUXILIARY class for a 'registration'
+ entry is only expected in cases where an OID allocation involves a
+ 'registeredUUID' attribute type instance and where the assigned 'n'
+ value is the equivalent unsigned 128-bit integer.
+
+ Presence of the 'iTUTRegistration' AUXILIARY class is only permitted
+ for allocations bearing the 'arc' STRUCTURAL class and describe an
+ OID beginning with zero (0). It extends no attribute types.
+
+ Presence of the 'iSORegistration' AUXILIARY class is only permitted
+ for allocations bearing the 'arc' STRUCTURAL class and describe an
+ OID beginning with one (1) It extends no attribute types.
+
+ Presence of the 'jointISOITUTRegistration' AUXILIARY class is only
+ permitted for allocations bearing the 'arc' STRUCTURAL class and
+ describe an OID beginning with two (2). It extends the 'longArc'
+ attribute type.
+
+ Entries SHALL NOT bear more than one (1) of the 'iTUTRegistration',
+ 'iSORegistration' or 'jointISOITUTRegistration' classes.
+
+ Presence of the 'spatialContext' AUXILIARY class is only permitted
+ for 'registration' entries. It extends seven (7) spatial reference
+ attribute types used to describe arrangement of allocations within
+ the spectrum. Additional collective incarnations of some of these
+ attribute types may be indicated.
+
+ Presence of the 'registrationSupplement' AUXILIARY class is only
+ permitted for 'registration' entries. It extends miscellaneous
+ attribute types which extend from no official standards meant for
+ ease-of-use only.
+
+ Collective Attributes are described in [RFC3671].
+
+
+
+
+Coretta Expires August 27, 2024 [Page 12]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ Presence of the 'firstAuthorityContext', 'currentAuthorityContext',
+ and 'sponsorContext' AUXILIARY classes is permitted for 'registrant'
+ entries and 'registration' entries alike, and would depend upon the
+ 'registrant' model employed within the RA DIT. Each of these classes
+ extends several identity and contact related attribute types for use
+ within the context of sponsorship, current authorities and previous
+ authorities.
+
+ Presence of the 'rADUAConfig' AUXILIARY class SHOULD NOT be permitted
+ for 'registration' or 'registrant' entries and indicates a suboptimal
+ or illogical state.
+
+ Assuming no violations were perceived as outlined above, the state of
+ the entry's object class stack is apparently copacetic.
+
+2.2.3.2.2. Attribute Types Used
+
+ At a minimum, the RA DUA SHOULD only expect Attribute Types defined
+ within Section 2.3 of the RASCHEMA ID, and/or their respective
+ super types defined in [RFC4519], [RFC4524] and [RFC2079], to be
+ assigned to entries within the terms of this ID series.
+
+ See Section 3.2 of the RADIT ID for numerous examples regarding
+ various attribute type use cases and requirements.
+
+ The RA DIT MAY use other attribute type and object class definitions
+ unrelated to this ID series, for supplemental reasons, however their
+ incorporation would be wholly proprietary and would have no official
+ standing per this ID series.
+
+2.2.3.2.3. Value Syntax
+
+ Each attribute type, whether directly or indirectly, is governed via
+ a syntax definition in terms of the allowed value(s) to be set for
+ an entry.
+
+ As mentioned in Section 2.1 of the RASCHEMA ID, standard syntaxes
+ do not necessarily align perfectly with the syntactical requirements
+ of the standards upon which this ID series is based -- namely ITU-T
+ Recommendations X.660 and X.680.
+
+ To ease the difficulty in implementing an RA DUA which honors the
+ syntactical characteristics of the underlying subject matter -- as
+ opposed to only recognizing the syntax alone -- Section 2.3 of the
+ RASCHEMA ID includes ABNF productions for every attribute type
+ defined, whether by reference or in literal form, intended for use by
+ those tasked with implementation of this ID series in some manner.
+
+ The RA DUA MUST recognize these ABNF productions when reading values
+ that were retrieved through use of the Read or Search Operation.
+
+
+
+Coretta Expires August 27, 2024 [Page 13]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ The RA DUA MAY decide how to handle the case of reading a previously
+ set attribute value of invalid or non-compliant form. The RA DUA may
+ warn the end-user of a value that is not well-formed, or it may opt
+ to omit the value from visibility altogether. If the RA DUA is of an
+ administrative focus, the opportunity for corrective measures MAY be
+ facilitated.
+
+2.2.3.3. Navigating Registration Entries
+
+ Some of the more complete RA services, whether public or private,
+ may offer a simple interface to facilitate intuitive incremental
+ movement among registrations that are associated horizontally or
+ vertically in terms of "up", "down", "left", "right", "min", "max"
+ and "top".
+
+ Depending on the needs of the intended audience, as well as the
+ manner in which this specification is adopted, this can be an
+ exceptionally difficult feature to implement for the RA DUA, but
+ is one that can dramatically improve the user experience.
+
+ The RA DUA SHOULD NOT assume positive support for this practice in
+ all implementations of this ID series.
+
+2.2.3.3.1. Superior Vertical References
+
+ During the Read or Search Operation executed in order to obtain a
+ 'registration' entry, the RA DUA MAY request any of the following
+ attribute types:
+
+ - 'supArc'
+ - 'c-supArc'
+ - 'topArc'
+ - 'c-topArc'
+
+ The 'supArc' and 'c-supArc' attribute types describe the immediate
+ superior (parent) registration in terms of ancestral lineage. Only
+ one (1) of each of these attribute types should be present for any
+ given 'registration' entry, never both.
+
+ The 'topArc' and 'c-topArc' attribute types describe the absolute
+ root registration in terms of ancestral lineage. Only one (1) of
+ each of these attribute types should be present for any given
+ 'registration' entry, never both.
+
+ Use of Collective attribute types -- namely those prefaced using the
+ requisite 'c-' flag -- is not practical in the two dimensional model
+ and thus need not be requested.
+
+ At no point are the above attribute types to be requested for entries
+ that bear the 'rootArc' STRUCTURAL object class. Root registrations
+ do not have superiors.
+
+
+Coretta Expires August 27, 2024 [Page 14]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.2.3.3.2. Subordinate Vertical References
+
+ Subordinate vertical references tend to be the most challenging among
+ all the various attribute types related to spatial navigation within
+ the terms of this ID series.
+
+ The RA DUA MAY request the 'subArc' attribute type as part of the
+ Read or Search Operation used for retrieval of a 'registration'
+ entry from the RA DIT.
+
+ At no point should an entry bear the 'subArc' attribute type if it
+ bears an 'isLeafNode' instance with a value of TRUE. This indicates
+ an illogical RA DIT condition.
+
+ When defined, the 'subArc' attribute type instance SHOULD reflect
+ a complete manifest of all references for 'registration' entries
+ that are direct subordinates of the bearer. This instance SHOULD
+ be requested in baseObject-scoped context, and is the only multi
+ valued spatial attribute type defined within this ID series.
+
+ The RA DUA SHOULD prefer 'subArc' enumeration to a List Operation
+ beneath a 'registration'. This method of searching is a potentially
+ costly request in the face of particularly large sets of subordinate
+ 'registration' entries present within the RA DIT.
+
+ The RA DUA SHOULD be prepared to manually sort the set of 'subArc'
+ DN references based on its OID or NumberForm value, however this
+ responsibility may be handled by the RA DSA.
+
+2.2.3.3.3. Horizontal References
+
+ Horizontal (sibling) references describe both adjacent as well as
+ minimum and maximum 'registration' contexts.
+
+ During a Search Operation intended to obtain a 'registration' entry,
+ the RA DUA SHOULD request the following attribute types:
+
+ - 'leftArc'
+ - 'rightArc'
+ - 'minArc'
+ - 'c-minArc'
+ - 'maxArc'
+ - 'c-maxArc'
+
+ The 'leftArc' attribute type describes the sibling 'registration'
+ entry that is nearest but less than that of the bearer in terms of
+ Number Form ('n') numerical magnitude.
+
+ The 'rightArc' attribute type describes the sibling 'registration'
+ entry that is nearest but greater than that of the bearer in terms
+ of Number Form ('n') numerical magnitude.
+
+
+Coretta Expires August 27, 2024 [Page 15]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ The 'minArc' and 'c-minArc' attribute types are used to reference the
+ 'registration' entry bearing the lowest magnitude Number Form ('n')
+ value within a set of siblings. Only one (1) of these Attribute
+ Types should be present for any given 'registration' entry, never
+ both.
+
+ The 'maxArc' and 'c-maxArc' attribute types are used to reference the
+ 'registration' entry bearing the highest magnitude Number Form ('n')
+ value within a set of siblings. Only one (1) of these Attribute
+ Types should be present for any given 'registration' entry, never
+ both.
+
+2.2.3.4. Client Entry Caching
+
+ For particularly large or busy implementations of this ID series, the
+ RA DUA MAY support basic client-driven entry caching of any retrieved
+ 'registration' and 'registrant' entries by way of either the 'rATTL'
+ or 'c-rATTL' integer attribute types, as defined within Section 2.3
+ of the RASCHEMA ID.
+
+ A valid use case for caching involves serving IANA PEN registrations
+ [PRIVATE], which number in the tens of thousands. Caching may yield
+ tremendous savings in terms of resource utilization associated with
+ particularly large numbers of static entries being retrieved in a
+ repeating manner.
+
+ This ID makes no assumptions regarding the design or implementation
+ of the underlying caching subsystem. The only abstract requirement
+ relates to the ability to cache a single directory entry for a span
+ of time equivalent to the effective TTL value in minutes.
+
+ The RA DUA SHOULD allow for the user to determine whether an entry
+ being presented is derived from a cache.
+
+2.2.3.4.1. Semantics
+
+ An 'rATTL' may be found in the following contexts wherever the
+ 'rADUAConfig', 'registration' or 'registrant' classes are present.
+
+ - A root DSE
+ - An RA DIT context
+ - An individual leaf-node entry
+
+ The collective counterpart attribute type, 'c-rATTL', may be found on
+ all of the above EXCEPT the root DSE.
+
+ Presence of an instance of either of these attribute types for any
+ entry serves as an indicator to the RA DUA that a caching directive
+ may be in effect depending on the value.
+
+ The significance of value magnitude -- whether collective or not --
+ is as follows:
+
+Coretta Expires August 27, 2024 [Page 16]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ - A value less than or equal to "0" is equivalent to a TTL being
+ undefined: NO cached lifespan is specified
+ - A value greater than or equal to "1" indicates a TTL lifespan
+ expressed by that value (e.g.: "1440" for a 24-hour TTL)
+
+ Countdown of a timespan commences at the same time the indicated
+ entry is retrieved and cached by the RA DUA according to the value.
+
+ Presence of the 'rATTL' attribute type within the RA DSA's root DSE
+ indicates use of global caching, a condition in which all entries
+ are cached for a fixed amount of time unless they are subjected to
+ an individual override by the 'rATTL' or 'c-rATTL' types.
+
+ Presence of the 'rATTL' attribute type within separate 'rADUAConfig'
+ class profile instances indicates context-specific entry caching (for
+ example, a single RA DIT in the midst of others served by a common RA
+ DSA).
+
+ The 'c-rATTL' attribute type is only present for entries when served
+ by an RA DSA which supports collective attributes. No instance of
+ the 'c-rATTL' attribute type shall be present within the root DSE.
+
+ In the face of multiple overlapping TTLs implied for an entry, these
+ rules of precedence can guide the RA DUA in determining the correct
+ TTL:
+
+ - DSE-based TTL overrides nothing (lowest common denominator)
+ - Contextual TTL overrides DSE TTL
+ - Collective TTL overrides a subtree of a contextual TTL
+ - Non-collective leaf entry TTL overrides all of the above
+
+ If deemed appropriate within the spirit of an implementation, or if
+ potentially necessary in an administrative context, the RA DUA MAY
+ allow for arbitrary cache bypass, whereas the cached entry may be
+ refreshed ahead of its scheduled TTL expiry.
+
+2.2.4. New Allocations
+
+ The following subsections involve considerations and procedures which
+ are related to the incorporation of new registration allocations into
+ an RA DIT.
+
+ Each "OID Directory" implementation will almost certainly adopt only
+ certain attribute types for use in entries.
+
+ Such restrictions may be exercised based on use of only select object
+ classes within an entry, through observance of any DIT content rules
+ that may be in effect, or through a form of access control.
+
+ The RA DUA is expected to honor any policies imposed by the service
+ that would influence or mandate the composition of new entries in a
+ particular way.
+
+Coretta Expires August 27, 2024 [Page 17]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.2.4.1. Verification
+
+ Certain preallocation checks MUST be conducted prior to any attempt
+ at creating an allocation. The following subsections describe these
+ procedures. Please note that only the three dimensional directory
+ model is covered due to its STRONGLY RECOMMENDED status over the
+ alternative model.
+
+ While the RA DSA may implement 'registration' integrity controls of
+ its own, the RA DUA SHALL NOT rely on such elements to mitigate bogus
+ or ill-advised requests alone. The RA DUA is REQUIRED to submit only
+ well-formed and sanctioned requests, and SHALL NOT be designed under
+ the unfounded assumption that the RA DSA will conduct post-operative
+ or custodial amendments of any kind.
+
+ Adopters of the RA DUA construct should remember that the context of
+ an allocation request can greatly influence the perception of the
+ various outcomes discussed in the following subsections.
+
+ For example, consider the entry of retroactive 'registration' entries
+ -- obsolete and wholly invalid by today's standards -- by an end user
+ simply to build a thorough and well-formed implementation of the OID
+ spectrum, versus a new registration being created today, and governed
+ by today's standards. The two scenarios have radically different
+ implications, yet the effective action is unchanged.
+
+ Depending on the nature and intended audience of an RA DUA solution,
+ this distinction may be particularly important. It may prove useful
+ to allow for effective "overrides" for authorized identities or modes
+ of operating, for example, to allow the creation of registrations
+ beneath an obsolete superior context.
+
+ It is important to note that the procedures defined in the following
+ subsections do not account for any internal governance or approval
+ process related to allocation request handling.
+
+2.2.4.1.1. Ancestral Viability
+
+ Given an intended registration DN of:
+
+ n=9999,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
+
+ The RA DUA MUST first verify the presence of the intended superior
+ registration DN.
+
+ n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
+
+ This search can be conducted using the following SearchRequest
+ parameters:
+
+
+
+
+Coretta Expires August 27, 2024 [Page 18]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ baseObject = n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
+ scope = 0
+ filter = objectClass=registration
+ attributes = registrationStatus
+ registrationClassification
+ isLeafNode
+ isFrozen
+ objectClass
+
+ If exactly one (1) entry is returned with no apparent error, the
+ superior entry is confirmed to be present. In this case, the RA DUA
+ should read the values of the requested attribute types.
+
+ If the 'registrationStatus' and/or 'registrationClassification' value
+ is OBSOLETE, DEALLOCATED or some other (known) declaration of a state
+ of non-operation, this MUST fail the allocation request unless the
+ attempt was made in (approved) retroactive context. The case folding
+ scheme in effect for these values is not significant.
+
+ Similarly, if the 'isFrozen' and/or 'isLeafNode' attribute types bear
+ a Boolean value of TRUE, the allocation request MUST fail unless the
+ attempt was made in (approved) retroactive context.
+
+ The error 'noSuchObject' indicates the requested entry was not found.
+ When using LDAP, this bears the resultCode value of "32".
+
+ 'noSuchObject' SHOULD be investigated by the RA DUA by way of an
+ ancestral traversal -- a process in which each successive ancestor
+ entry is subjected to a similar presence check as described above
+ in incremental fashion. Ordering of ancestral traversal checks is
+ not significant, as either ordering scheme will ultimately lead to
+ the same conclusion.
+
+ Each ancestor entry is referenced using a DN value which lacks the
+ leaf-node RDN component of the previously-checked descendant entry.
+
+ For instance, continuing with the above superior DN's lineage:
+
+ - n=1,n=6,n=3,n=1,ou=Registrations,o=rA
+ - n=6,n=3,n=1,ou=Registrations,o=rA
+ - n=3,n=1,ou=Registrations,o=rA
+ - n=1,ou=Registrations,o=rA
+
+ Following this procedure allows the RA DUA or the end user to locate
+ where the apparent ancestral discontinuity begins within the RA DIT.
+
+ The terminus of a registration lineage -- such as the one described
+ above -- is determined based on the presence of the STRUCTURAL object
+ class 'rootArc' for an entry (e.g.: "n=1,ou=Registrations,o=rA").
+
+
+
+
+Coretta Expires August 27, 2024 [Page 19]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.2.4.1.2. Number Form Uniqueness
+
+ Within a set of sibling 'registration' entries, it is CRITICAL that
+ any new allocation involve use of a horizontally-unique 'n' value.
+
+ Using one of the RECOMMENDED DN syntaxes described in Section 3.1,
+ the proper procedure simply involves a Read-based presence check of
+ the intended 'registration' DN.
+
+ For instance, if the desired allocation shall bear the DN:
+
+ n=9999,n=3,n=1,ou=Registrations,o=rA
+
+ A preemptive Read Operation MUST be executed in the following manner:
+
+ baseObject = n=9999,n=3,n=1,ou=Registrations,o=rA
+ scope = 0
+ typesOnly = TRUE
+ attributes = objectClass
+
+ Use of the 'typesOnly' option is merely for bandwidth efficiency,
+ as the goal of this request is to see if ANY entry exists by this
+ DN -- not to examine any particular attribute type values.
+
+ If zero (0) entries are returned alongside a 'noSuchObject' error,
+ the Number Form is unique.
+
+ Any non-zero number of entries that are returned with no apparent
+ error indicates the Number Form is NOT unique and the attempt at
+ allocation MUST fail. The RA DUA SHOULD inform the user of this
+ outcome.
+
+ There are no practical override use cases for this condition.
+
+ If using a 'registration' DN syntax other than those RECOMMENDED in
+ Section 3.1, use of a filter within a List Operation executed upon
+ the intended parent registration may be required at the risk of
+ performance penalties proportional to the number of entries present:
+
+ baseObject: = n=3,n=1,ou=Registrations,o=rA
+ scope = 1
+ typesOnly = TRUE
+ filter = n=9999
+ attributes = objectClass
+
+ The same entry count semantics as described above will apply.
+
+ See Section 2.2.4.1.3 for considerations regarding the presence
+ of ranges of allocations within the set of sibling registrations.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 20]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+2.2.4.1.3. Ranged Allocations
+
+ During the creation of new registrations, RA DUAs MUST preemptively
+ search for any range-based registrations present that might overlap
+ with the intended 'n' value of the entry. This requirement MAY be
+ relaxed if it is known that ranged allocations are not supported in
+ the target location.
+
+ For example, to determine if a ranged allocation resides within the
+ 1.3 OID registration that would overlap with a desired Number Form,
+ the RA DUA MUST perform a List Operation of the following form:
+
+ baseObject = n=3,n=1,ou=Registrations,o=rA
+ scope = 1
+ typesOnly = TRUE
+ filter = (&(n<=X)
+ (|(registrationRange>=X)(registrationRange=-1)))
+ attributes = registrationRange
+
+ Given these parameters, where the filter AVA "X" represents the 'n'
+ (Number Form) chosen -- for example "100" -- the search will return
+ zero (0) entries if no range violation is detected involving value
+ "X". This behavior is unchanged in the midst of multiple finite
+ and/or infinite ranges, regardless of contiguity.
+
+ Please note that integer "X" MUST be chosen or selected by some means
+ by the RA DUA or its end user for this procedure to work as intended.
+ "X" SHALL NOT be negative.
+
+ An infinite range SHALL ONLY appear once in any sibling context, and
+ the associated entry DN SHALL ALWAYS represent the true 'maxArc' or
+ 'c-maxArc' value in the same sibling context, if specified.
+
+ If ANY number of entries are returned as a result of this allocation
+ check, the registration MUST fail. The RA DUA MAY opt to make other
+ attempts using another Number Form in place of "X", or it may simply
+ inform the user of an overlapping allocation attempt.
+
+ This procedure assumes the preemptive Number Form Uniqueness check
+ procedures described in Section 2.2.4.1.2 have been conducted with
+ a favorable outcome as described.
+
+ However, in certain use cases, it may be advantageous to replace the
+ above 'filter' with:
+
+ (|(&(n<=X)(|(registrationRange>=X)(registrationRange=-1)))(n=X))
+
+ Doing so accomplishes the goals of this section and Section 2.2.4.1.2
+ in a single action.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 21]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ The RA DUA MAY opt to impose a 'typesOnly' value of FALSE to allow
+ the user to manually observe the range structure(s) present within
+ a set of siblings directly (by way of the 'registrationRange' type)
+ if and when an overlapping allocation attempt was made. This allows
+ the user to select an appropriate Number Form value in an informed
+ manner -- as opposed to trial-and-error methodology, for instance.
+
+2.2.4.2. Submission
+
+ Assuming the verification procedures covered in Section 2.2.4.1 were
+ of a favorable outcome, the submission of the allocation details may
+ be indicated.
+
+ This ID assumes that any requisite review or approval processes that
+ are practiced by those who serve in authority over the RA have been
+ performed.
+
+ Creation of a directory entry, based upon decided allocation details,
+ is the last step necessary for a proper submission. Please see the
+ RADIT ID for details and many examples regarding entry composition.
+
+ The Add Operation is the intended means for submission of the entry.
+
+ If the particular implementation of this ID series does not support
+ this operation in this manner, the RA DSA may be expected to support
+ another means out of scope for this ID series.
+
+ Upon submission of the composed entry to the receiving RA DSA, the
+ RA DUA SHOULD retrieve the newly added entry to verify attribute type
+ and object class content is present as intended. This should precede
+ any declarations of successful submission to the end user.
+
+2.2.5. Allocation Updates
+
+ Updates to 'registration' entries, as mentioned previously, is often
+ ill-advised outside of extraordinary circumstances, likely involving
+ corrections to entries deemed to be of poor form, or created in bad
+ faith. A general rule-of-thumb suggests that any 'registration' is
+ typically static.
+
+ Updates to 'registrant' entries or attributes, however, is far more
+ likely if contact information, which changes over time, is present.
+
+ Nevertheless, alterations to the content of entries in either context
+ is facilitated through use of the Modify Operation for any of the
+ following desired actions:
+
+ - Addition of object class values
+ - Addition of attribute type instances or values
+ - Removal of undesirable or invalid attribute instances or values
+ - Correction of bogus attribute type values
+ - Relegation of a currentAuthority to a firstAuthority
+
+Coretta Expires August 27, 2024 [Page 22]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ In an even more exceptional (and unlikely) scenario, the correction
+ of an invalid Number Form or OID RDN value is facilitated through
+ use of the Modify DN Operation, which is intended for the "renaming"
+ and/or "relocation" of a specified entry. This is almost certainly
+ an administratively focused use case.
+
+ The semantics for either of these operations are well outside the
+ scope of this ID series.
+
+3. IANA Considerations
+
+ There are no requests to IANA in this document at this time.
+
+4. Security Considerations
+
+ The RA DUA MUST possess the capability to honor any authentication
+ and/or confidentiality policies imposed by the RA DSA. This would
+ imply Bind and Unbind capabilities, at the least.
+
+ This may involve strategies related to TLS, 2FA, OTP and others. TLS
+ support may include facilities for mutual authentication. Support of
+ password-related operations -- such as those defined in [RFC3062] --
+ may be indicated.
+
+ Certain directory implementations may require these capabilities be
+ exercised prior to interaction with ANY facet of the directory -- no
+ matter how innocuous a request may be perceived (for instance, basic
+ query of the root DSE only). This is an especially common practice
+ in high-security X.500/LDAP implementations. Adopters are advised to
+ be prepared for such conditions.
+
+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.
+
+ RADSA Coretta, J., "The OID Directory: The RA DSA",
+ draft-coretta-oiddir-radsa, 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.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 23]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ [RFC2696] C. Weider, A. Herron, A. Anantha, Microsoft, T. Howes
+ and Netscape, "LDAP Control Extension for Simple Paged
+ Results Manipulation", RFC 2696, September 1999.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, 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.
+
+ [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.
+
+5.2. Informative References
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ https://www.iana.org/assignments/enterprise-numbers.
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, 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.
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 24]
+
+ Internet-Draft The OID Directory: RA Client February 2024
+
+
+ [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.
+
+Author's Address
+
+ Jesse Coretta
+ California, United States
+
+ Email: jesse.coretta@icloud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 25]
diff --git a/docs/specs/draft-coretta-oiddir-roadmap-00.txt b/docs/specs/draft-coretta-oiddir-roadmap-00.txt
new file mode 100644
index 000000000..ffbce0ba4
--- /dev/null
+++ b/docs/specs/draft-coretta-oiddir-roadmap-00.txt
@@ -0,0 +1,754 @@
+
+
+RADIR J. Coretta
+Internet-Draft February 29, 2024
+Intended status: Experimental
+Obsoletes: X660LDAP
+Expires: August 27, 2024
+
+
+ The OID Directory:
+ A Technical Roadmap
+ draft-coretta-oiddir-roadmap-00.txt
+
+Abstract
+
+ This ID outlines a series of experimental standards documents which
+ define the abstracts of the "OID Directory": a proposed philosophy
+ and set of procedures used to facilitate the storage and management
+ of the "OID spectrum" -- in part or in whole -- within an X.500/LDAP
+ service implementation.
+
+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: Roadmap February 2024
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Relation to draft-coretta-x660-ldap ........................2
+ 1.2. Conventions ................................................3
+ 1.3. Acronyms Used ..............................................4
+ 1.4. Intended Audience ..........................................4
+ 1.5. Alternatives ...............................................5
+ 1.6. Allocations ................................................5
+ 1.7. Key Citations and Generalizations ..........................5
+ 1.8. Common Operations and Concepts .............................7
+ 1.8.1. Read and Search .......................................7
+ 1.8.2. Modify ................................................9
+ 1.8.3. Add ...................................................9
+ 1.8.4. Delete ................................................9
+ 1.8.5. Modify DN ............................................10
+ 2. Supporting IDs .................................................10
+ 2.1. 'draft-coretta-oiddir-schema' .............................10
+ 2.2. 'draft-coretta-oiddir-radua' ..............................10
+ 2.3. 'draft-coretta-oiddir-radsa' ..............................11
+ 2.4. 'draft-coretta-oiddir-radit' ..............................11
+ 3. IANA Considerations ............................................11
+ 4. Security Considerations ........................................11
+ 5. References .....................................................11
+ 5.1. Normative References ......................................11
+ 5.2. Informative References ....................................11
+ 6. Ongoing Collaborative Resources ................................13
+ 6.1. The 'oid-directory' Repositories ..........................13
+ 6.2. The 'oid.directory' Internet Domain .......................13
+ Author's Address ..................................................13
+
+1. Introduction
+
+ This ID series combines relevant components of ITU-T Recommendations
+ [X.500], [X.660], [X.680], [RFC4510] and many others to define models
+ and procedures of the "OID Directory" construct.
+
+ The "OID Directory" is the X.500/LDAP facility for managing the "OID
+ Spectrum" -- in part or in whole -- in the context of Registration
+ Authority operations, whether public or private.
+
+ Additionally, unofficial components have been devised or appropriated
+ specifically to aid adopters in overcoming various feasibility and
+ logistical challenges that may arise during an implementation.
+
+ This ID series OBSOLETES all revisions of 'draft-coretta-x660-ldap'
+ (X660LDAP). See Section 1.1 for details.
+
+ This ID series -- as a whole -- is EXPERIMENTAL. Implementations of
+ any component set forth within this series SHOULD NOT manifest EXCEPT
+ for any testing or proof-of-concept efforts.
+
+
+Coretta Expires August 27, 2024 [Page 2]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+1.1. Relation to 'draft-coretta-x660-ldap'
+
+ This ID was first published towards the end of 2020 under the formal
+ name 'draft-coretta-x660-ldap' (X660LDAP) and had reached nine (9)
+ revisions. It originally held the title:
+
+ "Lightweight Directory Access Protocol (LDAP) Procedures and
+ Schema Definitions for the Storage of X.660 Registration
+ Information"
+
+ Subsequent community feedback -- although generally favorable --
+ suggested that some of the proposed subject matter was external to
+ the core precepts of ITU-T Rec. [X.660], which confused some readers.
+
+ Eventually, it was decided this document should be re-submitted with
+ a more generalized title. This single change satisfied nearly all
+ instances of criticism while preserving the intended spirit of the
+ ID without misleading readers as it relates to the true scope of
+ relevant standards.
+
+ Furthermore, it was decided that, due to the overall breadth and
+ complexity of the standards proposed, the ID should be divided into
+ multiple supporting IDs in a more focused manner. This has the
+ secondary effect of allowing potential extensions of this concept
+ in the future to be set forth in a more modular manner.
+
+ Aside from the correction of typographical and formatting errors
+ previously identified, the following additional changes have been
+ made to the new ID(s):
+
+ - Collective Attribute [RFC3671] support within this ID series is
+ now more well-defined.
+
+ - Administrative procedures and considerations have been expanded
+ throughout many areas of the ID series.
+
+ - The scope of potential candidates for adoption of the ID series
+ has been expanded in Section 1.4.
+
+ - Added new schema definitions and optimized several existing
+ definitions within the RASCHEMA ID.
+
+ - A short list of alternative solutions to this ID series has been
+ added in Section 1.5.
+
+ - The status of the ID is 'Experimental' (prev. 'Standards Track').
+
+ - Citations and references now favor current editions of certain
+ ITU-T Recommendations of relevance.
+
+ - Author's physical address has reduced specificity.
+
+
+Coretta Expires August 27, 2024 [Page 3]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+1.2. 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.
+
+ The convention "ID series" describes the entire suite of IDs which
+ constitute the overall philosophy of the "OID Directory". The term
+ implies not only those IDs cited in Section 2, but also any future
+ IDs that may be submitted as extensions by any author.
+
+ The conventions "OID spectrum" and "OID tree" -- while not defined in
+ any document within this standard -- are terms used frequently within
+ the ID series. These terms describe the hypothetical data structure
+ that houses or represents all known public or private registrations
+ that have ever been allocated.
+
+1.3. Acronyms Used
+
+ The "OID Directory" ID series makes reference to many acronyms, each
+ of which are defined as follows:
+
+ 2FA Two-Factor Authentication
+ ABNF Augmented Backus-Naur Form
+ API Application Programming Interface
+ ASCII American Standard Code for Information Interchange
+ ASN.1 Abstract Syntax Notation one
+ AVA Attribute Value Assertion
+ AXFR (DNS) Authoritative Zone Transfer
+ DAP Directory Access Protocol
+ DIB Directory Information Base
+ DISP Directory Information Shadowing Protocol
+ DIT Directory Information Tree
+ DN Distinguished Name
+ DNS Domain Name System
+ DOP Directory Operational Binding Management Protocol
+ DSA Directory System Agent
+ DSE DSA-Specific Entry
+ DSP Directory System Protocol
+ DUA Directory User Agent
+ GUI Graphical User Interface
+ GUID Globally Unique Identifier
+ ID Internet Draft (of this series)
+ IPC Interprocess Communication
+ IRI Internationalized Resource Identifier
+ IXFR (DNS) Incremental Zone Transfer
+ LDAP Lightweight Directory Access Protocol
+ LDIF LDAP Data Interchange Format
+ OID ASN.1 Object Identifier
+ ORS OID Resolution Service
+
+Coretta Expires August 27, 2024 [Page 4]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ OTP One-Time Pass
+ PEN IANA Private Enterprise Number
+ RA Registration Authority
+ RDN Relative Distinguished Name
+ SDK Software Development Kit
+ TLS Transport Layer Security
+ TTL Time to Live
+ TUI Textual User Interface
+ URI Uniform Resource Identifier
+ UUID Universal Unique Identifier
+
+1.4. Intended Audience
+
+ This ID series will be most useful to an RA of any context, whether
+ public or private. This was, and shall always be, the primary goal
+ of this effort.
+
+ Other potential candidates include, but are not limited to:
+
+ - Hardware manufacturers
+ - Weather Services
+ - Major internet technology companies
+ - Internet Service Providers
+ - Military/Allied directories
+ - Healthcare service providers
+ - Mainstream directory software product maintainers/vendors
+ - ASN.1 professionals, particularly developers tasked with
+ maintaining certain types of encoders and decoders
+
+ Sufficed to say, any entity or individual that directly queries or
+ uses ASN.1 object identifier information in frequent or critical
+ fashion may be a candidate for this ID series.
+
+1.5. Alternatives
+
+ Alternatives to this ID series include, but are not limited to:
+
+ - Implementation of ORS, per [X.672]
+ - Use of proprietary end-user applications
+ - Use of third party OID registration authority websites
+ - Reference raw ASN.1 definitions or relevant standards
+ - Implementation of a custom, in-house solution
+
+1.6. Allocations
+
+ This ID series has been allocated the following numeric OID prefix:
+
+ - 1.3.6.1.4.1.56521.101
+
+ Other IDs in this series extend this registration further.
+
+
+
+Coretta Expires August 27, 2024 [Page 5]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ Should this ID series be elevated to RFC status, the aforementioned
+ OID prefix shall be rendered obsolete in favor of an IANA-assigned
+ OID, at which point this ID series will be updated to reference the
+ literal 'IANA-ASSIGNED-OID' placeholder prefix where appropriate.
+
+1.7. Key Citations and Generalizations
+
+ Certain constructs and operations are cited frequently throughout
+ this ID series, each of which are covered below.
+
+ Generalized phrasing is meaningful only within the bounds of this ID
+ series and only where specificity is not relevant in context.
+
+ The DAP Modify Operation is defined in clause 12.3 of ITU-T Rec.
+ X.511. The LDAP Modify Operation is defined in Section 4.6 of
+ [RFC4511]. The term "Modify Operation" is used to describe either
+ of these operations.
+
+ The DAP Modify DN Operation is defined in clause 12.4 of ITU-T Rec.
+ X.511. The LDAP Modify DN Operation is defined within Section 4.9
+ of [RFC4511]. The term "Modify DN Operation" is used to describe
+ either of these operations.
+
+ The DAP Search Operation is defined in clause 11.2 of ITU-T Rec.
+ X.511. The DAP List Operation, considered an alternative form of
+ DAP Search, is defined in clause 11.1 of ITU-T Rec. X.511. The
+ LDAP Search Operation is defined in Section 4.5 of [RFC4511]. The
+ term "Search Operation" is used to describe either DAP or LDAP Search
+ Operations. Similarly, "List Operation" is the term used to describe
+ either the DAP List Operation or an LDAP Search Operation using the
+ singleLevel scope.
+
+ The DAP Read Operation is defined in clause 10.1 of ITU-T Rec. X.511.
+ The term "Read Operation" is used to describe either this operation
+ or a baseObject-scoped LDAP Search Operation.
+
+ The DAP Remove Entry Operation is defined in clause 12.2 of ITU-T
+ Rec. X.511. The LDAP Delete Operation is defined in Section 4.8 of
+ [RFC4511]. The term "Delete Operation" is used to describe either
+ of these operations.
+
+ The DAP Add Entry Operation is defined in clause 12.1 of ITU-T Rec.
+ X.511. The LDAP Add Operation is defined within Section 4.7 of
+ [RFC4511]. The term "Add Operation" is used to describe either
+ of these operations.
+
+ The DAP SearchArgumentData.subset parameter is defined in clause
+ 11.2.1 of ITU-T Rec. X.511. The LDAP SearchRequest.scope parameter
+ is defined in Section 4.5.1 of [RFC4511]. The terms "scope" and
+ "scoped" describe either of these components in the context of a
+ "Search Operation".
+
+
+Coretta Expires August 27, 2024 [Page 6]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ The DAP EntryInformationSelection ASN.1 SET is defined in clause 7.6
+ of ITU-T Rec. X.511. The LDAP SearchRequest.attributeSelector is
+ defined in Section 4.5.1.8 in [RFC4511]. The terms "selection" and
+ "selector" describe either of these components in the context of
+ refining the presentation of attribute types derived from entries
+ obtained by way of the Search or Read Operations.
+
+ The DAP EntryInformationSelection.infoTypes.attributeTypesOnly
+ parameter is defined within clause 7.6 of ITU-T Rec. X.511. The
+ equivalent LDAP SearchRequest.typesOnly parameter is defined in
+ Section 4.5.1 of [RFC4511]. The term 'typesOnly' refers to either
+ of these constructs in the context of occluding values during the
+ presentation of entries retrieved using Read or Search Operations.
+
+ The concepts of DIT Content Rules, DIT Structure Rules and Name Forms
+ are defined throughout Section 6 of ITU-T Rec. X.501 and in Section
+ 4.1 of [RFC4512].
+
+ The term "Write Operation" is an informal term used within this ID
+ series. In context, it can be used to refer to any of "Modify DN",
+ "Modify", "Add" and "Delete" operation generalizations defined above
+ wherever specificity is not required.
+
+ The root DSE is discussed in Section 5 of [RFC4512] and within clause
+ 23.4.2 of ITU-T Rec. X.501.
+
+ The 'subschemaSubentry' is defined in Section 4.2 of [RFC4512].
+
+ Collective attributes, including associated subtree and subentry
+ mechanics -- including the 'subtreeSpecification' attribute type --
+ are defined throughout [RFC3671], [RFC3672] and ITU-T Rec. X.501.
+
+1.8. Common Operations and Concepts
+
+ The following subsections describe where the standard DAP and LDAP
+ Operations itemized in Section 1.7 apply within this ID series, and
+ in what manner.
+
+ Not all Operations will necessarily have a direct correlation to any
+ specific procedures set forth within this ID series. For instance,
+ none of the procedures have any specific associations with Extended,
+ Bind or Unbind Operations defined within both ITU-T Rec. X.511 and
+ RFC4511.
+
+1.8.1. Read and Search
+
+ The Search and Read Operations are the most critical used within this
+ ID series, regardless of the nature of implementation.
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 7]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ The Read Operation is used to retrieve or "call" specific individual
+ entries from the RA DIT. This requires foreknowledge of the target
+ DN, but is RECOMMENDED as standard procedure in the intended spirit
+ of this ID series. This operation should ONLY return either one (1)
+ entry or none.
+
+ The Search Operation is used to retrieve multiple entries within a
+ request, typically in the context of a directory subtree. Specific
+ foreknowledge of the desired entries is not required, however input
+ of SearchRequest (LDAP) or SearchArgumentData (DAP) will require
+ added specificity in terms of the scope (LDAP) or subset (DAP) in
+ use, the filter supplied, and other parameters such as a selector.
+
+ The Search Operation is usually discouraged for use by end users
+ unless baseObject-scoped. Use in administratively-focused RA DUA
+ implementations is acceptable.
+
+ The following subsections cover relevant parameters extended by the
+ SearchRequest and SearchArgumentData constructs.
+
+1.8.1.1. baseObject
+
+ The baseObject parameter defined within the SearchRequest (LDAP) and
+ SearchArgumentData constructs defines the Name of the targeted entry
+ as a DN.
+
+ There is no default value within the context of this ID series, as
+ this will be influenced based on the activities of the RA DUA.
+
+1.8.1.2. scope and subset
+
+ The scope of a Search Operation defines the depth of the intended
+ operation in terms of 'baseObject' (0), 'singleLevel' (1) and
+ 'wholeSubtree' (2).
+
+ The default scope or subset for the RA DUA SHOULD be 'baseObject'.
+ This is analogous to the Read Operation. The RA DUA MAY allow user
+ override of this parameter when appropriate.
+
+1.8.1.3. typesOnly and attributeTypesOnly
+
+ During the presentation of a retrieved entry, the specification of
+ (LDAP) typesOnly or (DAP) attributeTypesOnly parameters results in
+ the discarding of values.
+
+ This is often desirable in cases where the presence of entries alone
+ is the focus -- not their content.
+
+1.8.1.4. filter
+
+ Use of a filter adds conditions to the successful matching of entries
+ to be retrieved by way of the Read or Search Operations.
+
+Coretta Expires August 27, 2024 [Page 8]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ Although generally not required of the user, certain procedures set
+ forth in this ID require use of a filter, for example during a range
+ check to be conducted prior to allocation of an OID. Generally the
+ RA DUA is expected to manage such activities.
+
+ The RA DUA may allow user-defined statements to be used for routine
+ or administrative operation, if appropriate.
+
+1.8.1.5. attribute selection
+
+ The attribute selection parameters may be used to specify desired
+ attribute types to be retrieved, if defined, as a result of a Read
+ or Search Operation upon an entry.
+
+ Use of a selector by the RA DUA in virtually all cases is STRONGLY
+ RECOMMENDED.
+
+ The RA DUA MAY allow user-defined overrides, such as '+', '*', '1.1'
+ or explicit attribute type descriptions if appropriate in context.
+
+1.8.2. Modify
+
+ The Modify Operation is usually among the lesser-used operations in
+ the terms of this ID series.
+
+ Aside from unusual or extraordinary circumstances, 'registration'
+ entries themselves are not typically edited.
+
+ 'registrant' entries, however, may be prone to updates, as they will
+ contain contact information -- such as email addresses and telephone
+ numbers -- for the respective authority.
+
+ The nature of this ID series does not impose any particular practice
+ or recommended procedure relating to the Modify Operation itself.
+
+ Modification operations, in general, SHOULD be limited to authorized
+ personnel or the respective "owners" of certain 'registration' and/or
+ 'registrant' entries as deemed appropriate.
+
+1.8.3. Add
+
+ The Add Operation is used for the creation of new 'registration' or
+ 'registrant' entries.
+
+ Generally this operation would be conducted by either the owner of
+ the respective allocation, or the RA administrative personnel in the
+ event the RA DSA supports this operation.
+
+ The addition of new 'registration' entries MUST ONLY occur below the
+ appropriate 'rARegistrationBase' value. Similarly, the addition of
+ new 'registrant' entries MUST ONLY occur below the appropriate
+ 'rARegistrantBase' value.
+
+Coretta Expires August 27, 2024 [Page 9]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ RA DUAs MUST observe the MAY and MUST clauses of the object class
+ definitions within Section 2.5 of the RASCHEMA ID. These provide
+ a rough inventory of the absolute minimum requirements for entry
+ composition, as well as the OPTIONAL types available for use.
+
+ The RA DUA MUST be prepared to observe additional restrictions or
+ extensions that may be imposed through the use of DIT Content Rules,
+ DIT Structure Rules and Name Forms held by the RA DSA. This will
+ influence the content of entries as well as the entry's DN structure.
+
+1.8.4. Delete
+
+ The Delete Operation is among the least-used operations within the
+ terms of this ID series.
+
+ 'registration' entries themselves are generally not deleted outright,
+ especially when public-facing. Any given 'registration' entry SHOULD
+ be labeled as OBSOLETE, DEALLOCATED or some other such designation of
+ non-operation and left intact indefinitely. The act of deleting a
+ 'registration' entry directly is often discouraged outside of unusual
+ or extraordinary circumstances, and may have disastrous consequences
+ if executed in cavalier fashion.
+
+ The same point may or may not apply to 'registrant' entries. Given
+ the costs associated with modern storage options, RAs may not deem it
+ worthwhile to preserve so-called orphaned 'registrant' entries -- in
+ other words, 'registrant' entries not currently serving in authority
+ for any registrations. Use of the Delete Operation may be indicated.
+
+ This ID series makes no recommendation on the proper usage of the
+ Delete Operation by appropriate personnel in the event of unusual or
+ extraordinary circumstances. Beyond purely administrative concerns,
+ RA DUA adopters are STRONGLY ADVISED to consider the specifics of
+ how and when deletion support should or should not be supported.
+
+1.8.5. Modify DN
+
+ The Modify DN Operation is likely the least-used operation within the
+ terms of this ID series.
+
+ Aside from unrelated administrative uses of this operation, such as
+ an effort to "move" entries from "ou=OIDs,o=rA" into a newly created
+ context "ou=Registrations,o=rA", or for the correction of a bogus DN,
+ the Modify DN operation is not indicated within the ID series.
+
+2. Supporting IDs
+
+ The following subsections each identify and describe various IDs
+ that comprise and support this proposed standard as a whole.
+
+ Should any of these IDs be updated or revised in any way, the highest
+ revision number supersedes any previous revision.
+
+Coretta Expires August 27, 2024 [Page 10]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+2.1. 'draft-coretta-oiddir-schema'
+
+ The 'draft-coretta-oiddir-schema' ID contains many useful definitions
+ that comprise the supporting schema for the so-called RA DIT.
+
+ This ID is hereafter cited and referenced as RASCHEMA.
+
+2.2. 'draft-coretta-oiddir-radua'
+
+ The 'draft-coretta-oiddir-radua' ID describes the RA client within
+ the traditional client/server model in terms of high-level concepts
+ and procedures for proper interaction with the RA DSA.
+
+ This ID is hereafter cited and referenced as RADUA.
+
+2.3. 'draft-coretta-oiddir-radsa'
+
+ The 'draft-coretta-oiddir-radsa' ID describes the RA server within
+ the traditional client/server model in terms of high-level concepts
+ and procedures for managing activities related to the RA DUA and RA
+ DIT.
+
+ This ID is hereafter cited and referenced as RADSA.
+
+2.4. 'draft-coretta-oiddir-radit'
+
+ The 'draft-coretta-oiddir-radit' ID defines guidelines and procedures
+ relating to the so-called RA DIT in terms of design considerations,
+ model structures, storage and operating states, et al.
+
+ This ID is hereafter cited and referenced as RADIT.
+
+3. IANA Considerations
+
+ There are no requests to IANA in this document at this time.
+
+4. Security Considerations
+
+ See the RADUA, RADSA and RADIT IDs for security considerations.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", RFC 8174, May 2017.
+
+
+
+
+Coretta Expires August 27, 2024 [Page 11]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+5.2. Informative References
+
+ RADIT Coretta, J., "The OID Directory: The RA DIT",
+ draft-coretta-oiddir-radit, February 2024.
+
+ RADSA Coretta, J., "The OID Directory: The RA DSA",
+ draft-coretta-oiddir-radsa, February 2024.
+
+ RADUA Coretta, J., "The OID Directory: The RA DUA",
+ draft-coretta-oiddir-radua, February 2024.
+
+ RASCHEMA Coretta, J., "The OID Directory: The Schema",
+ draft-coretta-oiddir-schema, February 2024.
+
+ [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.
+
+ [RFC4510] Zeilenga, K. "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [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.
+
+ [X.500] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Overview of
+ concepts, models and services", ITU-T X.500, October 2019.
+
+ [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.660] International Telecommunication Union - Telecommunication
+ Standardization Sector, "General procedures and top arcs
+ of the international object identifier tree", ITU-T X.660,
+ July 2011.
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 12]
+
+ Internet-Draft The OID Directory: Roadmap February 2024
+
+
+ [X.667] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Information technology -
+ Procedures for the operation of object identifier
+ registration authorities: Generation of universally unique
+ identifiers and their use in object identifiers", ITU-T
+ X.667, October 2012.
+
+ [X.672] International Telecommunication Union - Telecommunication
+ Standardization Sector, "OID resolution system: Problems,
+ requirements and potential solutions", ITU-T X.672, March
+ 2020.
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation", ITU-T X.680,
+ July 2002.
+
+6. Ongoing Collaborative Resources
+
+ This section contains information regarding resources, repositories
+ and websites related to ongoing collaboration and participation for
+ community members and experts alike with respect to this ID series.
+
+6.1. The 'oid-directory' Repositories
+
+ The following URL refers to a GitHub repository dedicated solely for
+ management of each ID in the (immediate) series:
+
+ https://github.com/oid-directory/id
+
+ The following URL refers to a GitHub repository dedicated for content
+ relating to the RASCHEMA ID:
+
+ https://github.com/oid-directory/definitions
+
+ Individuals or other parties interested in participating in this ID
+ series are encouraged to visit any or all of these repositories.
+
+6.2. The 'oid.directory' Internet Domain
+
+ The public internet domain 'oid.directory' has been reserved for any
+ relevant endeavors related to the ID series in the future.
+
+ Should the ID be accepted and elevated to the status of RFC, this
+ domain may be turned over to an appropriate entity or working group.
+
+Author's Address
+
+ Jesse Coretta
+ California, United States
+
+ Email: jesse.coretta@icloud.com
+
+Coretta Expires August 27, 2024 [Page 13]
diff --git a/docs/specs/draft-coretta-oiddir-schema-01.txt b/docs/specs/draft-coretta-oiddir-schema-01.txt
new file mode 100644
index 000000000..59cde136f
--- /dev/null
+++ b/docs/specs/draft-coretta-oiddir-schema-01.txt
@@ -0,0 +1,3246 @@
+
+
+RASCHEMA J. Coretta
+Internet-Draft February 29, 2024
+Intended status: Experimental
+Obsoletes: X660LDAP
+Expires: August 27, 2024
+
+
+ The OID Directory: The Schema
+ draft-coretta-oiddir-schema-01.txt
+
+Abstract
+
+ In service to the "OID Directory" ID series, this ID declares schema
+ definitions for use within an implementation of the Registration
+ Authority Directory Information Tree.
+
+ 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: Schema February 2024
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Conventions ................................................5
+ 1.2. Acronyms Used ..............................................5
+ 1.3. Allocations ................................................5
+ 1.4. Well-Known Numeric OIDs ....................................5
+ 2. Schema Definitions ..............................................6
+ 2.1. LDAP Syntaxes ..............................................6
+ 2.2. Matching Rules .............................................6
+ 2.3. Attribute Types ............................................6
+ 2.3.1. 'n' ...................................................7
+ 2.3.2. 'dotNotation' .........................................7
+ 2.3.3. 'iRI' .................................................7
+ 2.3.4. 'aSN1Notation' ........................................8
+ 2.3.5. 'unicodeValue' ........................................8
+ 2.3.6. 'additionalUnicodeValue' ..............................9
+ 2.3.7. 'identifier' ..........................................9
+ 2.3.8. 'secondaryIdentifier' ................................10
+ 2.3.9. 'registrationInformation' ............................10
+ 2.3.10. 'registrationURI' ...................................10
+ 2.3.11. 'registrationCreated' ...............................11
+ 2.3.12. 'registrationModified' ..............................11
+ 2.3.13. 'registrationRange' .................................12
+ 2.3.14. 'registrationStatus' ................................12
+ 2.3.15. 'registrationClassification' ........................12
+ 2.3.16. 'isLeafNode' ........................................13
+ 2.3.17. 'isFrozen' ..........................................13
+ 2.3.18. 'standardizedNameForm' ..............................13
+ 2.3.19. 'nameAndNumberForm' .................................14
+ 2.3.20. 'longArc' ...........................................14
+ 2.3.21. 'supArc' ............................................15
+ 2.3.22. 'c-supArc' ..........................................15
+ 2.3.23. 'topArc' ............................................16
+ 2.3.24. 'c-topArc' ..........................................16
+ 2.3.25. 'subArc' ............................................17
+ 2.3.26. 'leftArc' ...........................................17
+ 2.3.27. 'minArc' ............................................17
+ 2.3.28. 'c-minArc' ..........................................18
+ 2.3.29. 'rightArc' ..........................................18
+ 2.3.30. 'maxArc' ............................................19
+ 2.3.31. 'c-maxArc' ..........................................19
+ 2.3.32. 'discloseTo' ........................................20
+ 2.3.33. 'c-discloseTo' ......................................20
+ 2.3.34. 'registrantID .......................................20
+ 2.3.35. 'currentAuthority' ..................................21
+ 2.3.36. 'c-currentAuthority' ................................21
+ 2.3.37. 'currentAuthorityStartTimestamp' ....................22
+ 2.3.38. 'currentAuthorityCommonName' ........................22
+ 2.3.39. 'currentAuthorityCountryCode' .......................22
+ 2.3.40. 'currentAuthorityCountryName' .......................23
+ 2.3.41. 'currentAuthorityEmail' .............................23
+
+Coretta Expires August 27, 2024 [Page 2]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ 2.3.42. 'currentAuthorityFax' ...............................23
+ 2.3.43. 'currentAuthorityLocality' ..........................24
+ 2.3.44. 'currentAuthorityMobile' ............................24
+ 2.3.45. 'currentAuthorityOrg' ...............................25
+ 2.3.46. 'currentAuthorityPOBox' .............................25
+ 2.3.47. 'currentAuthorityPostalAddress' .....................25
+ 2.3.48. 'currentAuthorityPostalCode' ........................26
+ 2.3.49. 'currentAuthorityState' .............................26
+ 2.3.50. 'currentAuthorityStreet' ............................26
+ 2.3.51. 'currentAuthorityTelephone' .........................27
+ 2.3.52. 'currentAuthorityTitle' .............................27
+ 2.3.53. 'currentAuthorityURI' ...............................27
+ 2.3.54. 'firstAuthority' ....................................28
+ 2.3.55. 'c-firstAuthority' ..................................28
+ 2.3.56. 'firstAuthorityStartTimestamp' ......................29
+ 2.3.57. 'firstAuthorityEndTimestamp' ........................29
+ 2.3.58. 'firstAuthorityCommonName' ..........................29
+ 2.3.59. 'firstAuthorityCountryCode' .........................30
+ 2.3.60. 'firstAuthorityCountryName' .........................30
+ 2.3.61. 'firstAuthorityEmail' ...............................31
+ 2.3.62. 'firstAuthorityFax' .................................31
+ 2.3.63. 'firstAuthorityLocality' ............................31
+ 2.3.64. 'firstAuthorityMobile' ..............................32
+ 2.3.65. 'firstAuthorityOrg' .................................32
+ 2.3.66. 'firstAuthorityPOBox' ...............................32
+ 2.3.67. 'firstAuthorityPostalAddress' .......................33
+ 2.3.68. 'firstAuthorityPostalCode' ..........................33
+ 2.3.69. 'firstAuthorityState' ...............................34
+ 2.3.70. 'firstAuthorityStreet' ..............................34
+ 2.3.71. 'firstAuthorityTelephone' ...........................34
+ 2.3.72. 'firstAuthorityTitle' ...............................35
+ 2.3.73. 'firstAuthorityURI' .................................35
+ 2.3.74. 'sponsor' ...........................................35
+ 2.3.75. 'c-sponsor' .........................................36
+ 2.3.76. 'sponsorStartTimestamp ..............................36
+ 2.3.77. 'sponsorEndTimestamp ................................37
+ 2.3.78. 'sponsorCommonName' .................................37
+ 2.3.79. 'sponsorCountryCode' ................................37
+ 2.3.80. 'sponsorCountryName' ................................38
+ 2.3.81. 'sponsorEmail' ......................................38
+ 2.3.82. 'sponsorFax' ........................................38
+ 2.3.83. 'sponsorLocality' ...................................39
+ 2.3.84. 'sponsorMobile' .....................................39
+ 2.3.85. 'sponsorOrg' ........................................39
+ 2.3.86. 'sponsorPOBox' ......................................40
+ 2.3.87. 'sponsorPostalAddress' ..............................40
+ 2.3.88. 'sponsorPostalCode' .................................41
+ 2.3.89. 'sponsorState' ......................................41
+ 2.3.90. 'sponsorStreet' .....................................41
+ 2.3.91. 'sponsorTelephone' ..................................42
+ 2.3.92. 'sponsorTitle' ......................................42
+ 2.3.93. 'sponsorURI' ........................................42
+
+Coretta Expires August 27, 2024 [Page 3]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ 2.3.94. 'rADITProfile' ......................................43
+ 2.3.95. 'rARegistrationBase' ................................43
+ 2.3.96. 'rARegistrantBase' ..................................43
+ 2.3.97. 'rADirectoryModel' ..................................44
+ 2.3.98. 'rAServiceMail' .....................................44
+ 2.3.99. 'rAServiceURI' ......................................44
+ 2.3.100. 'rATTL' ............................................45
+ 2.3.101. 'c-rATTL' ..........................................45
+ 2.3.102. 'registeredUUID' ...................................46
+ 2.4. Matching Rule Uses ........................................46
+ 2.5. Object Classes ............................................46
+ 2.5.1. 'registration' .......................................46
+ 2.5.2. 'rootArc' ............................................46
+ 2.5.3. 'arc' ................................................47
+ 2.5.4. 'x660Context .........................................47
+ 2.5.5. 'x667Context .........................................47
+ 2.5.6. 'x680Context .........................................47
+ 2.5.7. 'iTUTRegistration' ...................................48
+ 2.5.8. 'iSORegistration' ....................................48
+ 2.5.9. 'jointISOITUTRegistration' ...........................49
+ 2.5.10. 'spatialContext' ....................................49
+ 2.5.11. 'registrationSupplement' ............................50
+ 2.5.12. 'firstAuthorityContext' .............................50
+ 2.5.13. 'currentAuthorityContext' ...........................51
+ 2.5.14. 'sponsorContext' ....................................51
+ 2.5.15. 'registrant' ........................................52
+ 2.5.16. 'rADUAConfig' .......................................52
+ 2.6. DIT Content Rules .........................................52
+ 2.7. Name Forms ................................................53
+ 2.7.1. 'nRootArcForm' .......................................53
+ 2.7.2. 'nArcForm' ...........................................53
+ 2.7.3. 'dotNotationArcForm' .................................53
+ 2.8. DIT Structure Rules .......................................53
+ 3. IANA Considerations ............................................54
+ 4. Security Considerations ........................................54
+ 5. References .....................................................54
+ 5.1. Normative References ......................................54
+ 5.2. Informative References ....................................55
+ Author's Address ..................................................56
+
+1. Introduction
+
+ The information bases meant to house registration and registrant data
+ by way of modern directory standards as outlined within this series
+ is dependent upon a comprehensive directory schema.
+
+ The schema is used to define content and -- to a degree -- structure
+ within the directory.
+
+ In context, the definitions set forth are based on concepts derived
+ from ITU-T Recommendations [X.660], [X.680], [RFC2578] et al.
+
+
+Coretta Expires August 27, 2024 [Page 4]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The intended end result is a directory service specially suited to
+ operate as an object identifier registration authority service.
+
+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.
+
+1.3. Allocations
+
+ This specification extends the previously defined ID series OID root
+ '1.3.6.1.4.1.56521.101', defined in Section 1.6 of the RADIR ID:
+
+ - 1.3.6.1.4.1.56521.101.2 (schema)
+ - 1.3.6.1.4.1.56521.101.2.3 (attributeTypes)
+ - 1.3.6.1.4.1.56521.101.2.5 (objectClasses)
+ - 1.3.6.1.4.1.56521.101.2.7 (nameForms)
+
+ All OIDs defined in this ID correlate to the section numbers in which
+ they originate. For example, the 'n' attribute type defined within
+ Section 2.3.1 is associated with the OID 1.3.6.1.4.1.56521.101.2.3.1.
+
+ Should this ID be elevated to RFC status, the aforementioned ID root
+ OID prefix shall be rendered obsolete in favor of an IANA-assigned
+ OID, at which point this ID will be updated to reference the literal
+ 'IANA-ASSIGNED-OID' placeholder prefix, where appropriate.
+
+1.4. Well-Known Numeric OIDs
+
+ This ID references several well-known numeric OIDs defined by other
+ parties or institutions, particularly as it pertains to the content
+ within all of Section 2.3. These numeric OIDs are shown below:
+
+ - 1.3 (Identified-Organization, per clause A.4.2 of ITU-T Rec.
+ [X.660])
+
+ - 1.3.6 (dod, per Section 3.1 of [RFC1155])
+
+ - 1.3.6.1 (Internet OID, per Section 3.1 of [RFC1155])
+
+ - 1.3.6.1.1.16.1 (UUID syntax, matching rule and ordering rule, per
+ Sections 2.1, 2.2 and 2.3 of [RFC4530] respectively)
+
+ - 1.3.6.1.4.1.1466.115.121.1.12 (DN syntax and matching rule, per
+ Section 4.2.15 of [RFC4517])
+
+Coretta Expires August 27, 2024 [Page 5]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ - 1.3.6.1.4.1.1466.115.121.1.24 (Generalized Time syntax, per
+ Section 3.3.13 of [RFC4517])
+
+ - 1.3.6.1.4.1.1466.115.121.1.27 (Integer syntax, per Section 3.3.16
+ of [RFC4517])
+
+ - 1.3.6.1.4.1.1466.115.121.1.38 (OID syntax, per Section 3.3.26
+ [RFC4517])
+
+ - 1.3.6.1.4.1.1466.115.121.1.40 (Octet String syntax, per Section
+ 3.3.25 of [RFC4517])
+
+2. Schema Definitions
+
+ This section discusses the particulars of the LDAP schema definitions
+ made available through this ID.
+
+ These schema definitions described in this section are provided using
+ LDAP description formats [RFC4512]. These elements are line-wrapped
+ and indented for readability when needed.
+
+2.1. LDAP Syntaxes
+
+ No LDAP syntaxes are defined anywhere in this ID series. However,
+ the topic of syntax is a recurring theme in ITU-T Recommendations
+ [X.660], [X.680] and many other standards relevant to this series.
+
+ This section serves only to advise the reader to consider the many
+ defined (or cited) ABNF productions throughout Section 2.3. While
+ the base LDAP syntaxes used within this ID are often insufficient
+ in enforcing complete compliance with relevant syntax standards,
+ most modern X.500/LDAP products support use of constraining rules
+ of some form to narrow their scope.
+
+ While the particulars of such product features are out of scope for
+ this ID series, the reader is nonetheless advised to make an effort
+ to sufficiently constrain attribute value input so as to honor the
+ relevant standard(s) in question.
+
+2.2. Matching Rules
+
+ No LDAP matching rule definitions are defined anywhere in this
+ ID series.
+
+2.3. Attribute Types
+
+ The following subsections detail one hundred two (102) LDAP attribute
+ types created for use within implementations of this specification.
+
+ Please note that a great many of these attribute type definitions are
+ sub types of attribute types defined in the following Standards, and
+ as such are considered dependencies:
+
+Coretta Expires August 27, 2024 [Page 6]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ - [RFC2079] for URI support
+ - [RFC4519] for so-called "core" schema elements
+ - [RFC4524] for Cosine schema elements
+
+ If the nature of a particular directory implementation precludes the
+ use of sub typed attributes, this specification may not be practical
+ for adoption.
+
+2.3.1. 'n'
+
+ The 'n' attribute type allows the assignment of an unsigned integer
+ used to represent the Number Form of a registration per ITU-T Rec.
+ [X.680].
+
+ A practical ABNF production, labeled 'number', is defined in Section
+ 1.4 of [RFC4512].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.1
+ NAME ( 'n' 'numberForm' )
+ DESC 'X.680, cl. 32.3: NumberForm'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ Examples: "56521", "0"
+
+2.3.2. 'dotNotation'
+
+ The 'dotNotation' attribute type allows the assignment of one (1) OID
+ to any non root registration.
+
+ A practical ABNF production, labeled 'numericoid', is defined within
+ Section 1.4 of [RFC4512].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.2
+ NAME 'dotNotation'
+ DESC 'X.680: OID in dotted notation'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE )
+
+ Examples: "1.3.6.1", "2.999"
+
+2.3.3. 'iRI'
+
+ The 'iRI' attribute type allows the assignment of one (1) or more
+ OID-IRI values to a registration.
+
+ A practical ABNF production for this attribute type, as derived from
+ clause 34.3 of ITU-T Rec. [X.680], is as follows:
+
+
+Coretta Expires August 27, 2024 [Page 7]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ subArcId = SOLIDUS arcId [ subArcId ]
+ arcId = SOLIDUS ( intUV / nintUV )
+ nintUV = 1*iunreserved ; non-integer unicode value
+ intUV = number ; integer unicode value
+
+ SOLIDUS = "%x2f" ; "/"
+
+ The 'number' ABNF production originates in Section 1.4 of [RFC4512].
+ The 'iunreserved' ABNR production originates within Section 2.2 of
+ [RFC3987].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.3
+ NAME 'iRI'
+ DESC 'X.680, cl. 34: OID-IRI'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ Examples: "/ITU-T", "/ISO/Identified-Organization", "/ASN.1"
+
+2.3.4. 'aSN1Notation'
+
+ The 'aSN1Notation' attribute type allows the assignment of an OID in
+ ASN.1, or ITU-T Rec. [X.680] ObjectIdentifierValue, notation.
+
+ A practical ABNF production for this attribute type is as follows:
+
+ asn1notation = LCURL forms RCURL
+ forms = nanf *( SPACE nanf )
+
+ SPACE = "%x20" ; " "
+ LCURL = "%x7b" ; "{"
+ RCURL = "%x7d" ; "}"
+
+ The 'nanf' ABNF originates in Section 2.3.19.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.4
+ NAME 'aSN1Notation'
+ DESC 'X.680, cl. 32.3: ObjectIdentifierValue'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ Examples: "{itu-t(0)}", "{iso(1) identified-organization(3)}"
+
+2.3.5. 'unicodeValue'
+
+ The 'unicodeValue' attribute type allows the assignment of a single
+ non-integer Unicode label to a registration, per ITU-T Rec. [X.660].
+
+ A practical ABNF production for this attribute type is as follows:
+
+ uval = 1*iunreserved
+
+Coretta Expires August 27, 2024 [Page 8]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The ABNF production 'iunreserved' is defined in Section 2.2 of
+ [RFC3987].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.5
+ NAME 'unicodeValue'
+ DESC 'X.660, cl. 7.5: non-integer Unicode label'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ SINGLE-VALUE )
+
+ Examples: "ITU-T", "Identified-Organization"
+
+2.3.6. 'additionalUnicodeValue'
+
+ The 'additionalUnicodeValue' attribute type allows for the assignment
+ of one (1) or more additional non-integer Unicode labels, per clause
+ 3.5.2 of ITU-T Rec. [X.660], to a registration.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 2.3.5.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.6
+ NAME 'additionalUnicodeValue'
+ DESC 'X.660, cl. 3.5.2: additional non-integer Unicode labels'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+2.3.7. 'identifier'
+
+ The 'identifier' attribute type allows for the assignment of one (1)
+ non-numeric, non-Unicode identifier, or nameForm, to a registration.
+
+ Per clause 12.3 of ITU-T Rec. [X.680]:
+
+ An "identifier" shall consist of an arbitrary number (one or more)
+ of letters, digits, and hyphens. The initial character shall be a
+ lower-case letter. A hyphen shall not be the last character. A
+ hyphen shall not be immediately followed by another hyphen.
+
+ As a practical ABNF production, the above clause translates as
+ follows:
+
+ identifier = leadkeychar *keychar
+ leadkeychar = LOWER
+ keychar = *( [ HYPHEN ] ( ALPHA / DIGIT ) )
+
+ ALPHA = ( LOWER / UPPER ) ; a-z / A-Z
+ UPPER = "%x41-%x5a" ; A-Z
+ LOWER = "%x61-%x7a" ; a-z
+ DIGIT = "%x30-%x39" ; 0-9
+ HYPHEN = "%x2d" ; "-"
+
+
+Coretta Expires August 27, 2024 [Page 9]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'name', as defined in Section 2.18 of [RFC4519],
+ is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.7
+ NAME ( 'identifier' 'nameForm' )
+ DESC 'X.680, cl. 12.3: Identifier'
+ SUP name
+ SINGLE-VALUE )
+
+ Examples: "itu-t", "iso"
+
+2.3.8. 'secondaryIdentifier'
+
+ The 'secondaryIdentifier' attribute type allows the assignment of
+ one (1) or more additional secondary non-numeric non-Unicode values,
+ per clause 3.5.1 of ITU-T Rec. [X.660], to a registration.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 2.3.7.
+
+ The attribute type 'name', as defined in Section 2.18 of [RFC4519],
+ is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.8
+ NAME 'secondaryIdentifier'
+ DESC 'X.660, cl. 3.5.1: Additional Identifiers'
+ SUP name )
+
+ Examples: "enterprises", "ccitt"
+
+2.3.9. 'registrationInformation'
+
+ The 'registrationInformation' attribute type allows the OPTIONAL
+ assignment of octet-based values intended for extended information
+ relating to the registration in question.
+
+ The 'OCTET' ABNF production defined in Section 1.4 of [RFC4512] is
+ applicable in any non-zero quantity or combination, as no defined
+ syntax or standard exists to govern this type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.9
+ NAME 'registrationInformation'
+ DESC 'Extended octet-based registration data'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ Example: "Acme, Co., Research & Development, Copyright (c) 2024"
+
+
+2.3.10. 'registrationURI'
+
+ The 'registrationURI' attribute type allows for the assignment of one
+ (1) or more URI values, with optional labels, to a registration.
+
+Coretta Expires August 27, 2024 [Page 10]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'labeledURI', as defined in [RFC2079], is a super
+ type of this attribute type.
+
+ A practical ABNF production for this attribute type is defined within
+ Appendix A of [RFC3986].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.10
+ NAME 'registrationURI'
+ DESC 'Uniform Resource Identifier for a registration'
+ SUP labeledURI )
+
+ Examples: "http://example.com Example", "ftp://example.com"
+
+2.3.11. 'registrationCreated'
+
+ The 'registrationCreated' attribute type allows for the assignment
+ of a generalized timestamp indicating the date and time at which a
+ registration was, or will be, created or officiated.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.11
+ NAME 'registrationCreated'
+ DESC 'Generalized timestamp for a registration creation'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE )
+
+ Examples: "19800229114853Z", "20130109033116Z"
+
+2.3.12. 'registrationModified'
+
+ The 'registrationModified' attribute type allows for the assignment
+ of one (1) or more generalized timestamp values indicating the dates
+ and times of all applied updates to a registration.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.12
+ NAME 'registrationModified'
+ DESC 'Generalized timestamps for registration modifications'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ Examples: "19951231115959Z", "20130109033116Z"
+
+
+
+
+Coretta Expires August 27, 2024 [Page 11]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.13. 'registrationRange'
+
+ The 'registrationRange' attribute type allows for the expression of
+ an OID sibling allocation range, such as "100" to indicate 'up to
+ 100', or "-1" to indicate 'to infinity'.
+
+ A practical ABNF production, labeled 'number', is defined in Section
+ 1.4 of [RFC4512]. This satisfies the unsigned form of instances of
+ this type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.13
+ NAME 'registrationRange'
+ DESC 'Numerical registration range expression'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ Examples: "-1", "1999", "1000000"
+
+2.3.14. 'registrationStatus'
+
+ The 'registrationStatus' attribute type allows for the assignment of
+ status information meant to define the state of the registration.
+
+ A practical ABNF production for the super type, 'description', is
+ found within Section 3.3.6 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.14
+ NAME 'registrationStatus'
+ DESC 'Current registration status'
+ SUP description )
+
+ Examples: "OBSOLETE", "DEALLOCATED", "RESERVED"
+
+2.3.15. 'registrationClassification'
+
+ The 'registrationClassification' attribute type allows a registration
+ to bear an informal classification value, thereby describing an OID's
+ context or category.
+
+ A practical ABNF production for the super type, 'description', can be
+ found within Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.15
+ NAME 'registrationClassification'
+ DESC 'Known registration classification'
+ SUP description
+ SINGLE-VALUE )
+
+ Examples: "Standard", "Individual", "ASN.1 Modules"
+
+
+Coretta Expires August 27, 2024 [Page 12]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.16. 'isLeafNode'
+
+ The 'isLeafNode' attribute type allows for the assignment of a single
+ Boolean value indicative of whether a registration can be a parent to
+ any subordinate registrations.
+
+ A practical ABNF production for this attribute type is found within
+ Section 3.3.3 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.16
+ NAME 'isLeafNode'
+ DESC 'Whether a registration may allocate sub arcs'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+ Examples: "TRUE", "FALSE", or Undefined (implies "FALSE")
+
+2.3.17. 'isFrozen'
+
+ The 'isFrozen' attribute type allows for the assignment of a single
+ Boolean value indicative of whether a registration can be a parent
+ to any further subordinate registrations beyond those that already
+ exist at present.
+
+ A practical ABNF production for this attribute type is found within
+ Section 3.3.3 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.17
+ NAME 'isFrozen'
+ DESC 'Whether additional sub arcs are permitted'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+ Examples: "TRUE", "FALSE", or Undefined (implies "FALSE")
+
+2.3.18. 'standardizedNameForm'
+
+ The 'standardizedNameForm' attribute type allows for the assignment
+ of one (1) or more Standardized NameForm values, per clauses A.2 and
+ A.3 of ITU-T Rec. [X.660], to a registration only if its 'identifier'
+ value is considered standardized.
+
+ A practical ABNF production for this attribute type is as follows:
+
+ stdnf = LCURL nonfs RCURL
+ nonfs = nonf *( SPACE nonf )
+ nonf = ( identifier / number ) ; name OR number
+
+
+
+
+Coretta Expires August 27, 2024 [Page 13]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ SPACE = "%x20" ; " "
+ LCURL = "%x7b" ; "{"
+ RCURL = "%x7d" ; "}"
+
+ The 'identifier' ABNF originates in Section 2.3.7. The 'number' ABNF
+ production can be found within Section 1.4 of [RFC4512].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.18
+ NAME 'standardizedNameForm'
+ DESC 'X.660, cl. A.2-A-3: Standardized Identifier or NameForm'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ Examples: "{itu-t}", "{0 0 d}"
+
+2.3.19. 'nameAndNumberForm'
+
+ The 'nameAndNumberForm' attribute type allows for the assignment of
+ an ITU-T Rec. [X.680] NameAndNumberForm value to a registration.
+
+ A practical ABNF production for this attribute type is as follows:
+
+ nonf = ( nanf / number ) ; nanf OR numberForm
+ nanf = name LPAREN number RPAREN ; name AND numberForm
+ name = identifier ; name form
+
+ LPAREN = "%x28" ; "("
+ RPAREN = "%x29" ; ")"
+
+ The 'identifier' ABNF production can be found in Section 2.3.7. The
+ 'number' ABNF production is defined in Section 1.4 of [RFC4512].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.19
+ NAME 'nameAndNumberForm'
+ DESC 'X.680, cl. 32.3: NameAndNumberForm'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ Examples: "private(4)", "itu-t(0)", "56521"
+
+2.3.20. 'longArc'
+
+ The 'longArc' attribute type allows for the assignment of one (1) or
+ more so-called "Long Arc" well-known identifiers to a registration.
+
+ A practical ABNF production for this attribute type is as follows:
+
+ longArc = SOLIDUS ( intUV / nintUV )
+ nintUV = 1*iunreserved ; non-integer unicode value
+ intUV = number ; integer unicode value
+
+
+Coretta Expires August 27, 2024 [Page 14]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.20
+ NAME 'longArc'
+ DESC 'X.660, cl. A.7: Long Arc'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ Examples: "/Example", "/Ejemplo"
+
+2.3.21. 'supArc'
+
+ The 'supArc' attribute type allows for the assignment of an LDAP DN
+ value to any non-root registration, thereby identifying the DN of the
+ immediate superior (parent) registration.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.21
+ NAME 'supArc'
+ DESC 'Immediate superior registration DN'
+ SUP distinguishedName
+ SINGLE-VALUE )
+
+ Example: "n=1,n=2,ou=Registrations,o=rA"
+
+2.3.22. 'c-supArc'
+
+ The 'c-supArc' attribute type is the manifestation of the 'supArc'
+ attribute type defined in Section 2.3.21 with Collective Attribute
+ [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MUST NOT be present for entries that also bear
+ a 'supArc' attribute type instance. The value MUST be singular.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.22
+ NAME 'c-supArc'
+ DESC 'Collective immediate superior registration DN'
+ SUP distinguishedName
+ COLLECTIVE )
+
+
+Coretta Expires August 27, 2024 [Page 15]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ Example: "n=1,n=2,ou=Registrations,o=rA"
+
+2.3.23. 'topArc'
+
+ The 'topArc' attribute type allows for the assignment of an LDAP DN
+ value to any non-root registration, thereby identifying the superior
+ root registration.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.23
+ NAME 'topArc'
+ DESC 'Superior root registration DN'
+ SUP distinguishedName
+ SINGLE-VALUE )
+
+ Example: "n=2,ou=Registrations,o=rA"
+
+2.3.24. 'c-topArc'
+
+ The 'c-topArc' attribute type is the manifestation of the 'topArc'
+ attribute type defined in Section 2.3.23 with Collective Attribute
+ [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MUST NOT be present for entries that also bear
+ a 'topArc' attribute type instance. The value MUST be singular.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.24
+ NAME 'c-topArc'
+ DESC 'Collective superior root registration DN'
+ SUP distinguishedName
+ COLLECTIVE )
+
+ Example: "n=2,ou=Registrations,o=rA"
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 16]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.25. 'subArc'
+
+ The 'subArc' attribute type allows for the assignment of one (1) or
+ more LDAP DN values to a registration as a manifest of subordinate
+ registrations residing exactly one (1) logical level below, if any.
+
+ In robust implementations of this ID that cover most (or all) of the
+ OID Tree, use of this attribute type will require careful, long-term
+ planning.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.25
+ NAME 'subArc'
+ DESC 'Subordinate registration DN'
+ SUP distinguishedName )
+
+ Example: "n=1,n=6,n=3,n=1,ou=Registrations,o=rA"
+
+2.3.26. 'leftArc'
+
+ The 'leftArc' attribute type allows for the assignment of a DN value
+ to a registration, referencing a registration positioned to the left
+ side of the bearer in terms of (lesser) 'n' magnitude.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.26
+ NAME 'leftArc'
+ DESC 'Nearest antecedent registration DN'
+ SUP distinguishedName
+ SINGLE-VALUE )
+
+ Example: "n=5,n=2,ou=Registrations,o=rA"
+
+2.3.27. 'minArc'
+
+ The 'minArc' attribute type allows for the assignment of a DN value
+ to a registration. The value SHOULD reference the entry which bears
+ the lowest 'n' value of any of its siblings.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+
+Coretta Expires August 27, 2024 [Page 17]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.27
+ NAME 'minArc'
+ DESC 'First or left-most sibling registration DN'
+ SUP distinguishedName
+ SINGLE-VALUE )
+
+ Example: "n=0,n=2,ou=Registrations,o=rA"
+
+2.3.28. 'c-minArc'
+
+ The 'c-minArc' attribute type is the manifestation of the attribute
+ type 'minArc', defined in Section 2.3.27 with Collective Attribute
+ [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MUST NOT be present for entries that also bear
+ a 'minArc' attribute type instance. The value MUST be singular.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.28
+ NAME 'c-minArc'
+ DESC 'Collective first or left-most sibling registration DN'
+ SUP distinguishedName
+ COLLECTIVE )
+
+ Example: "n=0,n=2,ou=Registrations,o=rA"
+
+2.3.29. 'rightArc'
+
+ The 'rightArc' attribute type allows for the assignment of a DN value
+ to a registration, referencing a registration positioned to the right
+ side of the bearer in terms of (greater) 'n' magnitude.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 18]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.29
+ NAME 'rightArc'
+ DESC 'Nearest subsequent registration DN'
+ SINGLE-VALUE
+ SUP distinguishedName )
+
+ Example: "n=2,n=2,ou=Registrations,o=rA"
+
+2.3.30. 'maxArc'
+
+ The 'maxArc' attribute type allows for the assignment of a DN value
+ to a registration. The value SHOULD reference the entry which bears
+ the highest 'n' value of any of its siblings.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.30
+ NAME 'maxArc'
+ DESC 'Final or right-most sibling registration DN'
+ SUP distinguishedName
+ SINGLE-VALUE )
+
+ Example: "n=999,n=2,ou=Registrations,o=rA"
+
+2.3.31. 'c-maxArc'
+
+ The 'c-maxArc' attribute type is the manifestation of the attribute
+ type 'maxArc', defined in Section 2.3.30 with Collective Attribute
+ [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ This attribute type MUST NOT be present for entries that also bear
+ a 'maxArc' attribute type instance. The value MUST be singular.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.31
+ NAME 'c-maxArc'
+ DESC 'Collective final or right-most sibling registration DN'
+ SUP distinguishedName
+ COLLECTIVE )
+
+ Example: "n=999,n=2,ou=Registrations,o=rA"
+
+
+
+Coretta Expires August 27, 2024 [Page 19]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.32. 'discloseTo'
+
+ The 'discloseTo' attribute type allows for the assignment of one (1)
+ or more LDAP DN values to a registration, each of which reference an
+ identity that is authorized to access one (1) or more confidential
+ registrations in read-only fashion.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.32
+ NAME 'discloseTo'
+ DESC 'Authorized registration reader'
+ SUP distinguishedName )
+
+ Example: "cn=AuthorizedReader,ou=Groups,o=rA"
+
+2.3.33. 'c-discloseTo'
+
+ The 'c-discloseTo' attribute type is the COLLECTIVE manifestation of
+ the attribute type 'discloseTo', defined in Section 2.3.32.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MAY be present for entries that also bear a
+ 'discloseTo' attribute type instance.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.33
+ NAME 'c-discloseTo'
+ DESC 'Collective authorized registration reader'
+ SUP distinguishedName
+ COLLECTIVE )
+
+ Example: "cn=ClearanceLevel4,ou=Groups,o=rA"
+
+2.3.34. 'registrantID'
+
+ The 'registrantID' attribute type is intended to allow for singular
+ assignment of a UUID, GUID or some other auto-generated value to a
+ registrant entry.
+
+ No specific syntax is implied for values of this type.
+
+Coretta Expires August 27, 2024 [Page 20]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.34
+ NAME 'registrantID'
+ DESC 'Unambiguous identifier assigned to an authority'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ SINGLE-VALUE )
+
+ Examples: "rfc4519", "65116e61-cc02-4c50-bde7-5bdaf4e973e4"
+
+2.3.35. 'currentAuthority'
+
+ The 'currentAuthority' attribute type allows for the assignment of
+ one (1) or more DN values to a registration.
+
+ The value(s) of this attribute type are meant to refer to distinct
+ entries that contain current registrant authority information for
+ the registration to which it is linked.
+
+ This attribute type is only required if registrant information is not
+ stored within a given registration directly.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.35
+ NAME 'currentAuthority'
+ DESC 'DN for a registrant serving as the current authority'
+ SUP distinguishedName )
+
+ Example: "registrantID=XYZ,ou=Registrants,o=rA"
+
+2.3.36. 'c-currentAuthority'
+
+ The 'c-currentAuthority' attribute type is the manifestation of the
+ 'currentAuthority' attribute type, defined in Section 2.3.35 with
+ Collective Attribute [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MAY be present for entries that also bear
+ a 'currentAuthority' attribute type instance.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+
+Coretta Expires August 27, 2024 [Page 21]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.36
+ NAME 'c-currentAuthority'
+ DESC 'Collective DN for a current authority'
+ SUP distinguishedName )
+
+ Example: "registrantID=XYZ,ou=Registrants,o=rA"
+
+2.3.37. 'currentAuthorityStartTimestamp'
+
+ The 'currentAuthorityStartTimestamp' attribute type allows for the
+ assignment of a generalized timestamp value to a current registration
+ authority. The value is indicative of the date and time at which the
+ current registration authority was, or will be, officiated.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.37
+ NAME 'currentAuthorityStartTimestamp'
+ DESC 'Registration authority commencement timestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE )
+
+ Example: "19951231115959Z"
+
+2.3.38. 'currentAuthorityCommonName'
+
+ The 'currentAuthorityCommonName' attribute type allows for the
+ assignment of a common name to a current authority entry.
+
+ The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.38
+ NAME 'currentAuthorityCommonName'
+ DESC 'Common Name for a current authority'
+ SUP cn
+ SINGLE-VALUE )
+
+ Example: "Jesse Coretta", "Jane Smith"
+
+2.3.39. 'currentAuthorityCountryCode'
+
+ The 'currentAuthorityCountryCode' attribute type allows for the
+ assignment of a country code to a current authority entry.
+
+ The attribute type 'c', as defined in Section 2.2 of [RFC4519],
+ is a super type of this attribute type.
+
+Coretta Expires August 27, 2024 [Page 22]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ A practical ABNF production is found in Section 3.3.4 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.39
+ NAME 'currentAuthorityCountryCode'
+ DESC 'Country Code for a current authority'
+ SUP c
+ SINGLE-VALUE )
+
+ Examples: "US", "CA"
+
+2.3.40. 'currentAuthorityCountryName'
+
+ The 'currentAuthorityCountryName' attribute type allows for the
+ assignment of a country name to a current authority entry.
+
+ The attribute type 'co', as defined in Section 2.4 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.40
+ NAME 'currentAuthorityCountryName'
+ DESC 'Country name for a current authority'
+ SUP co
+ SINGLE-VALUE )
+
+ Examples: "United States", "Canada"
+
+2.3.41. 'currentAuthorityEmail'
+
+ The 'currentAuthorityEmail' attribute type allows for the assignment
+ of an email address to the current registration authority entry.
+
+ The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'IA5String'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.41
+ NAME 'currentAuthorityEmail'
+ DESC 'Email address for a current authority'
+ SUP mail
+ SINGLE-VALUE )
+
+ Example: "jesse.coretta@icloud.com"
+
+2.3.42. 'currentAuthorityFax'
+
+ The 'currentAuthorityFax' attribute type allows for the assignment
+ of a facsimile telephone number to a current authority entry.
+
+
+Coretta Expires August 27, 2024 [Page 23]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'facsimileTelephoneNumber', as defined in Section
+ 2.10 of [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production can be found within Section 3.3.11 of
+ [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.42
+ NAME 'currentAuthorityFax'
+ DESC 'Facsimile telephone number for a current authority'
+ SUP facsimileTelephoneNumber
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.43. 'currentAuthorityLocality'
+
+ The 'currentAuthorityLocality' attribute type allows for a locality
+ name to be assigned to a current authority entry.
+
+ The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.43
+ NAME 'currentAuthorityLocality'
+ DESC 'Locality name for a current authority'
+ SUP l
+ SINGLE-VALUE )
+
+ Example: "Palm Springs", "Anna Maria Island"
+
+2.3.44. 'currentAuthorityMobile'
+
+ The 'currentAuthorityMobile' attribute type allows for the assignment
+ of a mobile telephone number to a current authority entry.
+
+ The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'PrintableString'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.44
+ NAME 'currentAuthorityMobile'
+ DESC 'Mobile telephone number for a current authority'
+ SUP mobile
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+
+
+Coretta Expires August 27, 2024 [Page 24]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.45. 'currentAuthorityOrg'
+
+ The 'currentAuthorityOrg' attribute type allows for the assignment of
+ an organization name to a current authority entry.
+
+ The attribute type 'o', as defined in Section 2.19 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.45
+ NAME 'currentAuthorityOrg'
+ DESC 'Organization name for a current authority'
+ SUP o
+ SINGLE-VALUE )
+
+ Example: "Acme, Co."
+
+2.3.46. 'currentAuthorityPOBox'
+
+ The 'currentAuthorityPOBox' attribute type allows for the assignment
+ of a post office box number to a current authority entry.
+
+ The attribute type 'postOfficeBox', as defined in Section 2.25 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.46
+ NAME 'currentAuthorityPOBox'
+ DESC 'Post office box number for a current authority'
+ SUP postOfficeBox
+ SINGLE-VALUE )
+
+ Examples: "555", "475"
+
+2.3.47. 'currentAuthorityPostalAddress'
+
+ The 'currentAuthorityPostalAddress' attribute type allows for the
+ assignment of a complete postal address to a current authority entry.
+ This single attribute may be used instead of other individual address
+ component attribute types, but will require field parsing on part of
+ the client.
+
+ The attribute type 'postalAddress', as defined in Section 2.23 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.28 in [RFC4517].
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 25]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.47
+ NAME 'currentAuthorityPostalAddress'
+ DESC 'Full postal address for a current authority'
+ SUP postalAddress
+ SINGLE-VALUE )
+
+ Example: "1 Fake St$Anytown$CA$12345$US"
+
+2.3.48. 'currentAuthorityPostalCode'
+
+ The 'currentAuthorityPostalCode' attribute type allows for a postal
+ code to be assigned to a current authority entry.
+
+ The attribute type 'postalCode', as defined in Section 2.23 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.48
+ NAME 'currentAuthorityPostalCode'
+ DESC 'Postal code for a current authority'
+ SUP postalCode
+ SINGLE-VALUE )
+
+ Examples: "92262", "34216"
+
+2.3.49. 'currentAuthorityState'
+
+ The 'currentAuthorityState' attribute type allows for a state or
+ province name to be assigned to a current authority entry.
+
+ The attribute type 'st', as defined in Section 2.33 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.49
+ NAME 'currentAuthorityState'
+ DESC 'State or province name for a current authority'
+ SUP st
+ SINGLE-VALUE )
+
+ Examples: "California", "North Dakota"
+
+2.3.50. 'currentAuthorityStreet'
+
+ The 'currentAuthorityStreet' attribute type allows for the assignment
+ of a street name and number to a current authority entry.
+
+ The attribute type 'street', as defined in Section 2.34 of [RFC4519],
+ is a super type of this attribute type.
+
+
+Coretta Expires August 27, 2024 [Page 26]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.50
+ NAME 'currentAuthorityStreet'
+ DESC 'Street name and number for a current authority'
+ SUP street
+ SINGLE-VALUE )
+
+ Example: "1 Fake Street"
+
+2.3.51. 'currentAuthorityTelephone'
+
+ The 'currentAuthorityTelephone' attribute type allows for a telephone
+ number to be assigned to a current authority entry.
+
+ The attribute type 'telephoneNumber', as defined in Section 2.35 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'PrintableString'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.51
+ NAME 'currentAuthorityTelephone'
+ DESC 'Telephone number assigned to a current authority'
+ SUP telephoneNumber
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.52. 'currentAuthorityTitle'
+
+ The 'currentAuthorityTitle' attribute type allows for the assignment
+ of an official or professional title to a current authority entry.
+
+ The attribute type 'title', as defined in Section 2.38 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.52
+ NAME 'currentAuthorityTitle'
+ DESC 'Title assigned to a current authority'
+ SUP title
+ SINGLE-VALUE )
+
+ Example: "Chief Engineer"
+
+2.3.53. 'currentAuthorityURI'
+
+ The 'currentAuthorityURI' attribute type allows for the assignment of
+ one (1) or more URI values to a current authority entry.
+
+
+Coretta Expires August 27, 2024 [Page 27]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'labeledURI', as defined in [RFC2079], is a super
+ type of this attribute type.
+
+ A practical ABNF production for this attribute type is defined within
+ Appendix A of [RFC3986].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.53
+ NAME 'currentAuthorityURI'
+ DESC 'Uniform Resource Identifier for a current authority'
+ SUP labeledURI )
+
+ Example: "http://example.com Example", "http://example.com"
+
+2.3.54. 'firstAuthority'
+
+ The 'firstAuthority' attribute type allows for the assignment of one
+ (1) or more DN values to a registration entry.
+
+ The value(s) of this attribute type are meant to refer to distinct
+ entries that contain previous authority information.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.54
+ NAME 'firstAuthority'
+ DESC 'DN of a previous authority'
+ SUP distinguishedName )
+
+ Example: "registrantID=XYZ,ou=Registrants,o=rA"
+
+2.3.55. 'c-firstAuthority'
+
+ The 'c-firstAuthority' attribute type is the manifestation of the
+ 'firstAuthority' attribute type, defined in Section 2.3.54 with
+ Collective Attribute [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MAY be present for entries that also bear
+ a 'firstAuthority' attribute type instance.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 28]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.55
+ NAME 'c-firstAuthority'
+ DESC 'Collective DN of a previous authority'
+ SUP distinguishedName
+ COLLECTIVE )
+
+ Example: "registrantID=XYZ,ou=Registrants,o=rA"
+
+2.3.56. 'firstAuthorityStartTimestamp'
+
+ The 'firstAuthorityStartTimestamp' attribute type allows for the
+ assignment of a generalized timestamp value to a previous authority,
+ indicative of the date and time at which the previous authority was
+ officiated.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.56
+ NAME 'firstAuthorityStartTimestamp'
+ DESC 'Previous registration authority commencement timestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE )
+
+ Example: "20130105135904Z"
+
+2.3.57. 'firstAuthorityEndTimestamp'
+
+ The 'firstAuthorityEndTimestamp' attribute type allows the assignment
+ of a generalized timestamp value to a previous authority, indicative
+ of the date and time at which an entity's authoritative role was, or
+ will be, terminated.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.57
+ NAME 'firstAuthorityEndTimestamp'
+ DESC 'Previous registration authority termination timestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE )
+
+ Example: "20170528110555Z"
+
+2.3.58. 'firstAuthorityCommonName'
+
+ The 'firstAuthorityCommonName' attribute type allows for a common
+ name to be assigned to a previous registration authority entry.
+
+Coretta Expires August 27, 2024 [Page 29]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'cn', as defined in Section 2.3 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.58
+ NAME 'firstAuthorityCommonName'
+ DESC 'Common Name for a previous authority'
+ SUP cn
+ SINGLE-VALUE )
+
+ Examples: "Jesse Coretta", "Jane Smith"
+
+2.3.59. 'firstAuthorityCountryCode'
+
+ The 'firstAuthorityCountryCode' attribute type allows for a country
+ code to be assigned to a previous registration authority entry.
+
+ The attribute type 'c', as defined in Section 2.2 of [RFC4519], is a
+ super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.4 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.59
+ NAME 'firstAuthorityCountryCode'
+ DESC 'Country Code for a previous authority'
+ SUP c
+ SINGLE-VALUE )
+
+ Examples: "US", "CA"
+
+2.3.60. 'firstAuthorityCountryName'
+
+ The 'firstAuthorityCountryName' attribute type allows for a country
+ name to be assigned to a previous registration authority entry.
+
+ The attribute type 'co', as defined in Section 2.4 of [RFC4519], is a
+ super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.60
+ NAME 'firstAuthorityCountryName'
+ DESC 'Country name for a previous authority'
+ SUP co
+ SINGLE-VALUE )
+
+ Examples: "United States", "Canada"
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 30]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.61. 'firstAuthorityEmail'
+
+ The 'firstAuthorityEmail' attribute type allows for the assignment
+ of an email address to a previous registration authority entry.
+
+ The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'IA5String'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.61
+ NAME 'firstAuthorityEmail'
+ DESC 'Email address for a previous authority'
+ SUP mail
+ SINGLE-VALUE )
+
+ Example: "jesse.coretta@icloud.com"
+
+2.3.62. 'firstAuthorityFax'
+
+ The 'firstAuthorityFax' attribute type allows for the assignment of a
+ facsimile telephone number to a previous authority entry.
+
+ The attribute type 'facsimileTelephoneNumber', as defined in Section
+ 2.10 of [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production can be found within Section 3.3.11 of
+ [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.62
+ NAME 'firstAuthorityFax'
+ DESC 'Facsimile telephone number for a previous authority'
+ SUP facsimileTelephoneNumber
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.63. 'firstAuthorityLocality'
+
+ The 'firstAuthorityLocality' attribute type allows the assignment of
+ a locality name to a previous authority entry.
+
+ The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 31]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.63
+ NAME 'firstAuthorityLocality'
+ DESC 'Locality name for a previous authority'
+ SUP l
+ SINGLE-VALUE )
+
+ Examples: "Palm Springs", "Anna Maria Island"
+
+2.3.64. 'firstAuthorityMobile'
+
+ The 'firstAuthorityMobile' attribute type allows for the assignment
+ of a mobile telephone number to a previous authority entry.
+
+ The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'PrintableString'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.64
+ NAME 'firstAuthorityMobile'
+ DESC 'Mobile telephone number for a previous authority'
+ SUP mobile
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.65. 'firstAuthorityOrg'
+
+ The 'firstAuthorityOrg' attribute type allows for the assignment
+ of an organization name to a previous authority entry.
+
+ The attribute type 'o', as defined in Section 2.19 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.65
+ NAME 'firstAuthorityOrg'
+ DESC 'Organization name for a previous authority'
+ SUP o
+ SINGLE-VALUE )
+
+ Example: "Acme, Co."
+
+2.3.66. 'firstAuthorityPOBox'
+
+ The 'firstAuthorityPOBox' attribute type allows for the assignment
+ of a post office box number to a previous registration authority
+ entry.
+
+
+
+Coretta Expires August 27, 2024 [Page 32]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'postOfficeBox', as defined in Section 2.25 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.66
+ NAME 'firstAuthorityPOBox'
+ DESC 'Post office box number for a previous authority'
+ SUP postOfficeBox
+ SINGLE-VALUE )
+
+ Examples: "555", "475"
+
+2.3.67. 'firstAuthorityPostalAddress'
+
+ The 'firstAuthorityPostalAddress' attribute type allows for the
+ assignment of a complete postal address to a previous registration
+ authority entry. This single attribute may be used instead of other
+ individual address component attribute types, but will require field
+ parsing on the client side.
+
+ The attribute type 'postalAddress', as defined in Section 2.23 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.28 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.67
+ NAME 'firstAuthorityPostalAddress'
+ DESC 'Full postal address for a previous authority'
+ SUP postalAddress
+ SINGLE-VALUE )
+
+ Example: "1 Fake St$Anytown$CA$12345$US"
+
+2.3.68. 'firstAuthorityPostalCode'
+
+ The 'firstAuthorityPostalCode' attribute type allows for the
+ assignment of a postal code to a previous registration authority
+ entry.
+
+ The attribute type 'postalCode', as defined in Section 2.23 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.68
+ NAME 'firstAuthorityPostalCode'
+ DESC 'Postal code for a previous authority'
+ SUP postalCode
+ SINGLE-VALUE )
+
+ Examples: "92262", "34216"
+
+Coretta Expires August 27, 2024 [Page 33]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.69. 'firstAuthorityState'
+
+ The 'firstAuthorityState' attribute type allows for the assignment
+ of a state or province name to a previous registration authority
+ entry.
+
+ The attribute type 'st', as defined in Section 2.33 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.69
+ NAME 'firstAuthorityState'
+ DESC 'State or province name for a previous authority'
+ SUP st
+ SINGLE-VALUE )
+
+ Examples: "California", "North Dakota"
+
+2.3.70. 'firstAuthorityStreet'
+
+ The 'firstAuthorityStreet' attribute type allows for the assignment
+ of a street name and number to a previous authority entry.
+
+ The attribute type 'street', as defined in Section 2.34 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.70
+ NAME 'firstAuthorityStreet'
+ DESC 'Street name and number for a previous authority'
+ SUP street
+ SINGLE-VALUE )
+
+ Example: "1 Fake Street"
+
+2.3.71. 'firstAuthorityTelephone'
+
+ The 'firstAuthorityTelephone' attribute type allows the assignment of
+ a telephone number to a previous authority entry.
+
+ The attribute type 'telephoneNumber', as defined in Section 2.35 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'PrintableString'.
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 34]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.71
+ NAME 'firstAuthorityTelephone'
+ DESC 'Telephone number for a previous authority'
+ SUP telephoneNumber
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.72. 'firstAuthorityTitle'
+
+
+ The 'firstAuthorityTitle' attribute type allows for the assignment
+ of an official or professional title to a previous authority entry.
+
+ The attribute type 'title', as defined in Section 2.38 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.72
+ NAME 'firstAuthorityTitle'
+ DESC 'Title of a previous authority'
+ SUP title
+ SINGLE-VALUE )
+
+ Example: "Chief Engineer"
+
+2.3.73. 'firstAuthorityURI'
+
+ The 'firstAuthorityURI' attribute type allows the assignment of one
+ (1) or more URI values to a previous authority entry.
+
+ The attribute type 'labeledURI', as defined in [RFC2079], is a super
+ type of this attribute type.
+
+ A practical ABNF production for this attribute type is defined within
+ Appendix A of [RFC3986].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.73
+ NAME 'firstAuthorityURI'
+ DESC 'Uniform Resource Identifier for a previous authority'
+ SUP labeledURI )
+
+ Examples: "http://example.com Example", "http://example.com"
+
+2.3.74. 'sponsor'
+
+ The 'sponsor' attribute type allows for the assignment of one (1)
+ or more DN values to a registration.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+Coretta Expires August 27, 2024 [Page 35]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'distinguishedName', as defined in Section 2.7 of
+ [RFC4519], is a super type of this attribute type.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.74
+ NAME 'sponsor'
+ DESC 'DN of a sponsoring authority'
+ SUP distinguishedName )
+
+ Example: "registrantID=XYZ,ou=Registrants,o=rA"
+
+2.3.75. 'c-sponsor'
+
+ The 'c-sponsor' attribute type is the manifestation of the 'sponsor'
+ attribute type, defined in Section 2.3.74 with Collective Attribute
+ [RFC3671] support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ This attribute type MAY be present for entries that also bear
+ a 'sponsor' attribute type instance.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.75
+ NAME 'c-sponsor'
+ DESC 'Collective DN of a sponsoring authority'
+ SUP distinguishedName
+ COLLECTIVE )
+
+ Example: "registrantID=XYZ,ou=Registrants,o=rA"
+
+2.3.76. 'sponsorStartTimestamp'
+
+ The 'sponsorStartTimestamp' attribute type allows for the assignment
+ of a generalized timestamp value to a sponsor entry, indicative of
+ the date and time at which sponsorship was, or will be, officiated.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.76
+ NAME 'sponsorStartTimestamp'
+ DESC 'Sponsoring authority commencement timestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE )
+
+ Example: "20130105135904Z"
+
+
+Coretta Expires August 27, 2024 [Page 36]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.77. 'sponsorEndTimestamp'
+
+ The 'sponsorEndTimestamp' attribute type allows for the assignment
+ of a generalized timestamp value to a sponsor entry, indicative the
+ date and time at which sponsorship was, or will be, terminated.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3.3.13 of [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.77
+ NAME 'sponsorEndTimestamp'
+ DESC 'Sponsoring authority termination timestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE )
+
+ Example: "20170528110555Z"
+
+2.3.78. 'sponsorCommonName'
+
+ The 'sponsorCommonName' attribute type allows for the assignment
+ of a common name to a sponsor.
+
+ The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.78
+ NAME 'sponsorCommonName'
+ DESC 'Common Name of a sponsor'
+ SUP cn
+ SINGLE-VALUE )
+
+ Example: "Jane Sponsor"
+
+2.3.79. 'sponsorCountryCode'
+
+ The 'sponsorCountryCode' attribute type allows for the assignment of
+ a two-letter country code to a sponsor.
+
+ The attribute type 'c', as defined in Section 2.2 of [RFC4519], is a
+ super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.4 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.79
+ NAME 'sponsorCountryCode'
+ DESC 'Country code for a sponsor'
+ SUP c
+ SINGLE-VALUE )
+
+Coretta Expires August 27, 2024 [Page 37]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ Examples: "US", "CA"
+
+2.3.80. 'sponsorCountryName'
+
+ The 'sponsorCountryName' attribute type allows the assignment of a
+ country name to a sponsor.
+
+ The attribute type 'co', as defined in Section 2.4 of [RFC4524], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.80
+ NAME 'sponsorCountryName'
+ DESC 'Country name for a sponsor'
+ SUP co
+ SINGLE-VALUE )
+
+ Examples: "United States", "Canada"
+
+2.3.81. 'sponsorEmail'
+
+ The 'sponsorEmail' attribute type allows for the assignment of an
+ email address to a sponsor.
+
+ The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'IA5String'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.81
+ NAME 'sponsorEmail'
+ DESC 'Email address for a sponsor'
+ SUP mail
+ SINGLE-VALUE )
+
+ Example: "sponsor@example.com"
+
+2.3.82. 'sponsorFax'
+
+ The 'sponsorFax' attribute type allows for the assignment of a
+ facsimile telephone number to a sponsor.
+
+ The attribute type 'facsimileTelephoneNumber', as defined in Section
+ 2.10 of [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production can be found within Section 3.3.11 of
+ [RFC4517].
+
+
+
+
+Coretta Expires August 27, 2024 [Page 38]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.82
+ NAME 'sponsorFax'
+ DESC 'Facsimile telephone number for a sponsor'
+ SUP facsimileTelephoneNumber
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.83. 'sponsorLocality'
+
+ The 'sponsorLocality' attribute type allows for the assignment of
+ a locality name to a sponsor.
+
+ The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
+ a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.83
+ NAME 'sponsorLocality'
+ DESC 'Locality name for a sponsor'
+ SUP l
+ SINGLE-VALUE )
+
+ Examples: "Palm Springs", "Anna Maria Island"
+
+2.3.84. 'sponsorMobile'
+
+ The 'sponsorMobile' attribute type allows for the assignment of a
+ mobile telephone number to a sponsor.
+
+ The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'PrintableString'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.84
+ NAME 'sponsorMobile'
+ DESC 'Mobile telephone number for a sponsor'
+ SUP mobile
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.85. 'sponsorOrg'
+
+ The 'sponsorOrg' attribute type allows for the assignment of an
+ organization name to a sponsor.
+
+ The attribute type 'o', as defined in Section 2.19 of [RFC4519],
+ is a super type of this attribute type.
+
+Coretta Expires August 27, 2024 [Page 39]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.85
+ NAME 'sponsorOrg'
+ DESC 'Organization name for a sponsor'
+ SUP o
+ SINGLE-VALUE )
+
+ Example: "Sponsor, Co."
+
+2.3.86. 'sponsorPOBox'
+
+ The 'sponsorPOBox' attribute type allows for the assignment of a
+ post office box number to a sponsor.
+
+ The attribute type 'postOfficeBox', as defined in Section 2.25 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.86
+ NAME 'sponsorPOBox'
+ DESC 'Post office box number for a sponsor'
+ SUP postOfficeBox
+ SINGLE-VALUE )
+
+ Examples: "555", "475"
+
+2.3.87. 'sponsorPostalAddress'
+
+ The 'sponsorPostalAddress' attribute type allows for the assignment
+ of a complete postal address sponsor. This single attribute may be
+ used instead of other individual address component attribute types,
+ but will require field parsing on the client side.
+
+ The attribute type 'postalAddress', as defined in Section 2.23 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.28 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.87
+ NAME 'sponsorPostalAddress'
+ DESC 'Full postal address for a sponsor'
+ SUP postalAddress
+ SINGLE-VALUE )
+
+ Example: "1 Fake St$Anytown$CA$12345$US"
+
+2.3.88. 'sponsorPostalCode'
+
+ The 'sponsorPostalCode' attribute type allows for a postal code
+ to be assigned to a sponsor.
+
+Coretta Expires August 27, 2024 [Page 40]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The attribute type 'postalCode', as defined in Section 2.23 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.88
+ NAME 'sponsorPostalCode'
+ DESC 'Postal code for a sponsor'
+ SUP postalCode
+ SINGLE-VALUE )
+
+ Example: "92262", "34216"
+
+2.3.89. 'sponsorState'
+
+ The 'sponsorState' attribute type allows for the assignment of a
+ state or province name to a sponsor.
+
+ The attribute type 'st', as defined in Section 2.33 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.89
+ NAME 'sponsorState'
+ DESC 'State or province name for a sponsor'
+ SUP st
+ SINGLE-VALUE )
+
+ Examples: "California", "North Dakota"
+
+2.3.90. 'sponsorStreet'
+
+ The 'sponsorStreet' attribute type allows for the assignment of a
+ street name and number to a sponsor.
+
+ The attribute type 'street', as defined in Section 2.34 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.90
+ NAME 'sponsorStreet'
+ DESC 'Street name and number for a sponsor'
+ SUP street
+ SINGLE-VALUE )
+
+ Example: "1 Fake Street"
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 41]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.91. 'sponsorTelephone'
+
+ The 'sponsorTelephone' attribute type allows for the assignment of
+ a telephone number to a sponsor.
+
+ The attribute type 'telephoneNumber', as defined in Section 2.35 of
+ [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'PrintableString'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.91
+ NAME 'sponsorTelephone'
+ DESC 'Telephone number for a sponsor'
+ SUP telephoneNumber
+ SINGLE-VALUE )
+
+ Example: "+11234567890"
+
+2.3.92. 'sponsorTitle'
+
+ The 'sponsorTitle' attribute type allows for the assignment of an
+ official or professional title to a sponsor.
+
+ The attribute type 'title', as defined in Section 2.38 of [RFC4519],
+ is a super type of this attribute type.
+
+ A practical ABNF production is found in Section 3.3.6 in [RFC4517].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.92
+ NAME 'sponsorTitle'
+ DESC 'Title of a sponsor'
+ SUP title
+ SINGLE-VALUE )
+
+ Example: "Executive Sponsor"
+
+2.3.93. 'sponsorURI'
+
+ The 'sponsorURI' attribute type allows for the assignment of one (1)
+ or more URI values, each with an optional label, to a sponsor.
+
+ The attribute type 'labeledURI', as defined in [RFC2079], is a super
+ type of this attribute type.
+
+ A practical ABNF production for this attribute type is defined within
+ Appendix A of [RFC3986].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.93
+ NAME 'sponsorURI'
+ DESC 'Uniform Resource Identifier for a sponsor'
+ SUP labeledURI )
+
+Coretta Expires August 27, 2024 [Page 42]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ Examples: "http://example.com Example", "http://example.com"
+
+2.3.94. 'rADITProfile'
+
+ The 'rADITProfile' attribute type references entries which contain
+ optimal 'rADUAConfig' configuration settings for client consumption.
+
+ The attribute type 'distinguishedName', as defined in Section 2.7
+ of [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.94
+ NAME 'rADITProfile'
+ DESC 'Advertised RA DIT profile DNs served by an RA DSA'
+ SUP distinguishedName )
+
+ Examples: "n=1,dc=example,dc=com" "n=1,n=4,n=1,n=6,n=3,n=1"
+
+2.3.95. 'rARegistrationBase'
+
+ The 'rARegistrationBase' attribute type allows for the storage of one
+ (1) or more DNs that refer to entries under which 'registration'
+ entries reside.
+
+ The attribute type 'distinguishedName', as defined in Section 2.7
+ of [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.95
+ NAME 'rARegistrationBase'
+ DESC 'DN of a registration base within an RA DIT'
+ SUP distinguishedName )
+
+ Example: "ou=Registrations,o=rA"
+
+2.3.96. 'rARegistrantBase'
+
+ The 'rARegistrantBase' attribute type allows for the storage of one
+ (1) or more LDAP DNs that refer to entries under which 'registrant'
+ entries reside.
+
+ The attribute type 'distinguishedName', as defined in Section 2.7
+ of [RFC4519], is a super type of this attribute type.
+
+ A practical ABNF production for this attribute type can be found in
+ Section 3 of [RFC4514].
+
+
+
+Coretta Expires August 27, 2024 [Page 43]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.3.96
+ NAME 'rARegistrantBase'
+ DESC 'DN of a registrant base within an RA DIT'
+ SUP distinguishedName )
+
+ Example: "ou=Registrants,o=rA"
+
+2.3.97. 'rADirectoryModel'
+
+ The 'rADirectoryModel' attribute type allows for the storage of a
+ numerical OID meant to declare the structural design of the RA DIT.
+
+ A practical ABNF production, labeled 'numericoid', is defined within
+ Section 1.4 of [RFC4512].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.97
+ NAME 'rADirectoryModel'
+ DESC 'Governing directory model OID'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE )
+
+ Example: "1.3.6.1.4.1.56521.101.3.3"
+
+2.3.98. 'rAServiceMail'
+
+ The 'rAServiceMail' attribute type allows for the assignment of an
+ email address to an 'rADUAConfig' entry for the purpose of support
+ or error reporting.
+
+ The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
+ is a super type of this attribute type.
+
+ A practical ABNF production can be found in Section 3.2 of [RFC4517],
+ labeled 'IA5String'.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.98
+ NAME 'rAServiceMail'
+ DESC 'Registration Authority contact email address'
+ SUP mail )
+
+ Example: "ra@example.com"
+
+2.3.99. 'rAServiceURI'
+
+ The 'rAServiceURI' attribute type allows for the assignment of one
+ (1) or more URI values to an 'rADUAConfig' entry for the purpose of
+ directing users to an appropriate RA endpoint for request handling.
+
+ The attribute type 'labeledURI', as defined in [RFC2079], is a super
+ type of this attribute type.
+
+
+Coretta Expires August 27, 2024 [Page 44]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ A practical ABNF production for this attribute type is defined within
+ Appendix A of [RFC3986].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.99
+ NAME 'rAServiceURI'
+ DESC 'Registration Authority URI'
+ SUP labeledURI )
+
+ Example: "http://example.com/ra.html Registrations"
+
+2.3.100. 'rATTL'
+
+ The 'rATTL' attribute type allows for the specification of a TTL
+ value, expressed in seconds.
+
+ A practical ABNF production, labeled 'number', can be found within
+ Section 1.4 of [RFC4512].
+
+ See the RADUA ID for details relating to client-driven entry
+ caching and practical value implementation.
+
+ ( 1.3.6.1.4.1.56521.101.2.3.100
+ NAME 'rATTL'
+ DESC 'RA entry Time to Live, expressed in seconds'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ Examples: "0", "3600", "-1", "86400"
+
+2.3.101. 'c-rATTL'
+
+ The 'c-rATTL' attribute type is the manifestation of the 'rATTL'
+ type, defined in Section 2.3.99 with Collective Attribute support.
+
+ This attribute type should only be used in directory environments
+ which actively support and require [RFC3671] capabilities.
+
+ See the RADUA ID for details relating to client-driven entry
+ caching and practical value implementation.
+
+ A practical ABNF production, labeled 'number', can be found within
+ Section 1.4 of [RFC4512].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.101
+ NAME 'c-rATTL'
+ DESC 'Collective RA entry Time to Live, expressed in seconds'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ COLLECTIVE )
+
+Coretta Expires August 27, 2024 [Page 45]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.3.102. 'registeredUUID'
+
+ The 'registeredUUID' attribute type assigns a hexadecimal UUID value
+ to a registration.
+
+ A practical ABNF production for this attribute type is defined within
+ Section 3 of [RFC4122].
+
+ ( 1.3.6.1.4.1.56521.101.2.3.102
+ NAME 'registeredUUID'
+ DESC 'X.667 registered UUID'
+ EQUALITY UUIDMatch
+ ORDERING UUIDOrderingMatch
+ SYNTAX 1.3.6.1.1.16.1
+ SINGLE-VALUE )
+
+ Example: "e6bcf22c-00bf-4b3d-b11f-36ec0522aa93"
+
+2.4. Matching Rule Uses
+
+ No LDAP Matching Rule Uses definitions are defined anywhere in this
+ ID series.
+
+2.5. Object Classes
+
+ The following subsections describe sixteen (16) LDAP object classes
+ defined within this ID.
+
+2.5.1. 'registration'
+
+ The 'registration' ABSTRACT class, which is a sub type of 'top', per
+ Section 2.4.1 of [RFC4512], serves as the foundation for ALL entries
+ intended to represent OID registrations within the spirit of this ID.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.1
+ NAME 'registration'
+ DESC 'Abstract OID arc class'
+ SUP top ABSTRACT
+ MUST n
+ MAY ( description $ seeAlso $ rATTL ) )
+
+2.5.2. 'rootArc'
+
+ The 'rootArc' STRUCTURAL class is meant to define a maximum of three
+ (3) root registrations for an RA DIT, per ITU-T Rec. [X.660].
+
+ Entries that bear this class SHALL ONLY represent the following root
+ registrations:
+
+ - ITU-T ({itu-t(0)})
+ - ISO ({iso(1)})
+ - Joint-ISO-ITU-T ({joint-iso-itu-t(2)})
+
+Coretta Expires August 27, 2024 [Page 46]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.5.2
+ NAME 'rootArc'
+ DESC 'X.660, cl. A.2: root arc class'
+ SUP registration STRUCTURAL )
+
+2.5.3. 'arc'
+
+ The 'arc' STRUCTURAL object class extends a collection of attribute
+ types for use when allocating subordinate registrations in an RA DIT.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.3
+ NAME 'arc'
+ DESC 'X.660, cl. A.3-A.5: subordinate arc class'
+ SUP registration STRUCTURAL )
+
+2.5.4. 'x660Context'
+
+ The 'x660Context' AUXILIARY class extends a collection of attribute
+ types derived from Rec. ITU-T [X.660].
+
+ ( 1.3.6.1.4.1.56521.101.2.5.4
+ NAME 'x660Context'
+ DESC 'X.660 contextual class'
+ SUP registration AUXILIARY
+ MAY ( additionalUnicodeValue $
+ currentAuthority $
+ firstAuthority $
+ secondaryIdentifier $
+ sponsor $
+ standardizedNameForm $
+ unicodeValue ) )
+
+2.5.5. 'x667Context'
+
+ The 'x667Context' AUXILIARY class extends a single attribute type,
+ 'registeredUUID' as defined in Section 2.3.101, for use within the
+ context of an ITU-T Rec. [X.667] (UUID) registration.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.5
+ NAME 'x667Context'
+ DESC 'X.667 contextual class'
+ SUP registration AUXILIARY
+ MUST registeredUUID )
+
+2.5.6. 'x680Context'
+
+ The 'x680Context' AUXILIARY class extends a collection of attribute
+ types derived from ITU-T Rec. [X.680].
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 47]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.5.6
+ NAME 'x680Context'
+ DESC 'X.680 contextual class'
+ SUP registration AUXILIARY
+ MAY ( aSN1Notation $
+ dotNotation $
+ identifier $
+ iRI $
+ nameAndNumberForm ) )
+
+2.5.7. 'iTUTRegistration'
+
+ The 'iTUTRegistration' AUXILIARY class labels the registration as
+ belonging to the International Telecommunications Union (ITU-T) in
+ subordinate form.
+
+ It is NOT RECOMMENDED to assign this class to any entry which bears
+ the 'rootArc' STRUCTURAL object class, per in Section 2.5.1. This
+ class SHALL NOT appear on entries bearing the 'iSORegistration' (per
+ Section 2.5.8) or 'jointISOITUTRegistration' (per Section 2.5.9)
+ class.
+
+ The 'x660Context' (Section 2.5.4) and 'x680Context' (Section 2.5.6)
+ are super classes of this class.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.7
+ NAME 'iTUTRegistration'
+ DESC 'X.660, cl. A.2: ITU-T'
+ SUP ( x660Context $
+ x680Context )
+ AUXILIARY )
+
+2.5.8. 'iSORegistration'
+
+ The 'iSORegistration' AUXILIARY class labels the OID registration as
+ belonging to the International Organization for Standardization (ISO)
+ in subordinate form.
+
+ It is NOT RECOMMENDED to assign this class to any entry which bears
+ the 'rootArc' STRUCTURAL object class, per Section 2.5.1. This class
+ SHALL NOT appear on entries bearing the 'iTUTRegistration' (defined
+ in Section 2.5.7) or 'jointISOITUTRegistration' (per Section 2.5.9)
+ class.
+
+ The 'x660Context' (Section 2.5.4) and 'x680Context' (Section 2.5.6)
+ are super classes of this class.
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 48]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.5.8
+ NAME 'iSORegistration'
+ DESC 'X.660, cl. A.2: ISO'
+ SUP ( x660Context $
+ x680Context )
+ AUXILIARY )
+
+2.5.9. 'jointISOITUTRegistration'
+
+ The 'jointISOITUTRegistration' AUXILIARY class labels a registration
+ as being jointly administered by the International Organization for
+ Standardization (ISO) and the International Telecommunications Union
+ (ITU-T) in cooperative fashion.
+
+ It is NOT RECOMMENDED to assign this class to any entry which bears
+ the 'rootArc' STRUCTURAL object class, per Section 2.5.1. This class
+ SHALL NOT appear on entries bearing the 'iTUTRegistration' (defined
+ in Section 2.5.7) or 'iSORegistration' (per Section 2.5.8) class.
+
+ This class extends use of the 'longArc' attribute type, as defined in
+ Section 2.3.20.
+
+ The 'x660Context' (Section 2.5.4) and 'x680Context' (Section 2.5.6)
+ are super classes of this class.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.9
+ NAME 'jointISOITUTRegistration'
+ DESC 'X.660, cl. A.2: Joint ISO/ITU-T Administration'
+ SUP ( x660Context $
+ x680Context )
+ AUXILIARY
+ MAY longArc )
+
+2.5.10. 'spatialContext'
+
+ The 'spatialContext' AUXILIARY class extends vertical and horizontal
+ associative attribute types intended to describe the logical position
+ of a registration in relation to adjacent registrations.
+
+ Use of this class is entirely OPTIONAL, but can greatly aid in the
+ creation of navigational interfaces which allow both horizontal and
+ vertical movement across entire ancestries.
+
+ See the RADIT ID for further details on this topic.
+
+
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 49]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ ( 1.3.6.1.4.1.56521.101.2.5.10
+ NAME 'spatialContext'
+ DESC 'Logical spatial orientation and association class'
+ SUP registration AUXILIARY
+ MAY ( topArc $ supArc $ subArc $
+ minArc $ maxArc $
+ leftArc $ rightArc ) )
+
+2.5.11. 'registrationSupplement'
+
+ The 'registrationSupplement' AUXILIARY class extends a variety of
+ miscellaneous and non-standard attribute types for OPTIONAL.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.11
+ NAME 'registrationSupplement'
+ DESC 'Supplemental registration class'
+ SUP registration AUXILIARY
+ MAY ( discloseTo $ isFrozen $ isLeafNode $
+ registrationClassification $
+ registrationCreated $
+ registrationInformation $
+ registrationModified $
+ registrationRange $
+ registrationStatus $
+ registrationURI ) )
+
+2.5.12. 'firstAuthorityContext'
+
+ The 'firstAuthorityContext' AUXILIARY class extends attribute types
+ intended to store previous authority information.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.12
+ NAME 'firstAuthorityContext'
+ DESC 'Initial registration authority class'
+ SUP top AUXILIARY
+ MAY ( firstAuthorityCommonName $
+ firstAuthorityCountryCode $
+ firstAuthorityCountryName $
+ firstAuthorityCountryName $
+ firstAuthorityEmail $
+ firstAuthorityEndTimestamp $
+ firstAuthorityFax $
+ firstAuthorityLocality $
+ firstAuthorityMobile $
+ firstAuthorityOrg $
+ firstAuthorityPostalCode $
+ firstAuthorityStartTimestamp $
+ firstAuthorityState $
+ firstAuthorityStreet $
+ firstAuthorityTelephone $
+ firstAuthorityTitle $
+ firstAuthorityURI ) )
+
+Coretta Expires August 27, 2024 [Page 50]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.5.13. 'currentAuthorityContext'
+
+ The 'currentAuthorityContext' AUXILIARY class extends attribute types
+ intended to store current authority information.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.13
+ NAME 'currentAuthorityContext'
+ DESC 'Current registration authority class'
+ SUP top AUXILIARY
+ MAY ( currentAuthorityCommonName $
+ currentAuthorityCountryCode $
+ currentAuthorityCountryName $
+ currentAuthorityCountryName $
+ currentAuthorityEmail $
+ currentAuthorityFax $
+ currentAuthorityLocality $
+ currentAuthorityMobile $
+ currentAuthorityOrg $
+ currentAuthorityPostalCode $
+ currentAuthorityStartTimestamp $
+ currentAuthorityState $
+ currentAuthorityStreet $
+ currentAuthorityTelephone $
+ currentAuthorityTitle $
+ currentAuthorityURI ) )
+
+2.5.14. 'sponsorContext'
+
+ The 'currentAuthorityContext' AUXILIARY class extends attribute types
+ intended to store sponsoring authority information.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.14
+ NAME 'sponsorContext'
+ DESC 'Registration sponsoring authority class'
+ SUP top AUXILIARY
+ MAY ( sponsorCommonName $
+ sponsorCountryCode $
+ sponsorCountryName $
+ sponsorCountryName $
+ sponsorEmail $
+ sponsorEndTimestamp $
+ sponsorFax $
+ sponsorLocality $
+ sponsorMobile $
+ sponsorOrg $
+ sponsorPostalCode $
+ sponsorStartTimestamp $
+ sponsorState $
+ sponsorStreet $
+ sponsorTelephone $
+ sponsorTitle $
+ sponsorURI ) )
+
+Coretta Expires August 27, 2024 [Page 51]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.5.15. 'registrant'
+
+ The 'registrant' object class allows for current, previous (first)
+ and/or sponsorship data to be stored within an entry.
+
+ This object class is STRUCTURAL, and cannot be combined with the
+ 'registration' object class within a single entry.
+
+ Use of the 'registrant' object class within an RA DIT implies use
+ of so-called dedicated authority entries, as described within the
+ RADIT ID.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.15
+ NAME 'registrant'
+ DESC 'Generalized auxiliary class for registrant data'
+ SUP top STRUCTURAL
+ MUST registrantID
+ MAY ( description $ seeAlso $ rATTL ) )
+
+2.5.16. 'rADUAConfig'
+
+ The 'rADUAConfig' object class allows for the storage of so-called
+ auto-discovered attribute types meant to guide the RA DUA in its
+ attempt to access registration and/or registrant information stored
+ within the RA DIT served by the RA DSA.
+
+ ( 1.3.6.1.4.1.56521.101.2.5.16
+ NAME 'rADUAConfig'
+ DESC 'RA DUA configuration advertisement class'
+ SUP top AUXILIARY
+ MAY ( description $
+ rADITProfile $
+ rADirectoryModel $
+ rARegistrationBase $
+ rARegistrantBase $
+ rAServiceMail $
+ rAServiceURI $
+ rATTL ) )
+
+2.6. DIT Content Rules
+
+ No DIT Content Rules are officially defined anywhere in this ID
+ series.
+
+ If the X.500/LDAP product(s) in question registers positive support
+ for these kinds of definitions, per Section 4.1.6 of [RFC4512], and
+ the reader desires the ability to control the contents of any and all
+ individual registration and/or registrant entries in a more granular
+ manner, they are advised to consider the composition and use of one
+ (1) or more custom rules of this design.
+
+
+
+Coretta Expires August 27, 2024 [Page 52]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+2.7. Name Forms
+
+ This section defines three (3) Name Forms for use in the composition
+ of any DIT Structure Rules required, if supported by the X.500/LDAP
+ product(s) in question. See Section 4.1.7.2 of [RFC4512] for
+ details.
+
+2.7.1. 'nRootArcForm'
+
+ The 'nRootArcForm' name form is devised to control the RDN of the
+ entries bearing the 'rootArc' STRUCTURAL object class. Within the
+ RECOMMENDED three dimensional model of this ID series, use the 'n'
+ (Number Form) attribute type is the preferred RDN component.
+
+ ( 1.3.6.1.4.1.56521.101.2.7.1
+ NAME 'nRootArcForm'
+ DESC 'root arc name form for a number form RDN'
+ OC rootArc
+ MUST n )
+
+2.7.2. 'nArcForm'
+
+ The 'nArcForm' name form is devised to control the RDN of the entries
+ bearing the 'arc' STRUCTURAL object class. Within the RECOMMENDED
+ three dimensional model of this ID series, the 'n' (Number Form)
+ attribute type is the preferred RDN component.
+
+ ( 1.3.6.1.4.1.56521.101.2.7.2
+ NAME 'nArcForm'
+ DESC 'arc name form for a number form RDN'
+ OC arc
+ MUST n )
+
+2.7.3. 'dotNotationArcForm'
+
+ The 'dotNotationArcForm' name form is devised to control the RDN
+ of the bearings bearing the 'arc' STRUCTURAL object class. Within
+ the STRONGLY DISCOURAGED two dimensional model of this ID series,
+ the 'dotNotation' (numeric OID) attribute type is the preferred RDN
+ component.
+
+ ( 1.3.6.1.4.1.56521.101.2.7.3
+ NAME 'dotNotationArcForm'
+ DESC 'arc name form for a numeric OID RDN'
+ OC arc
+ MUST dotNotation )
+
+2.8. DIT Structure Rules
+
+ No DIT structure rules are officially defined anywhere in this ID
+ series.
+
+
+Coretta Expires August 27, 2024 [Page 53]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ The name form definitions per Section 2.7 may be used in the creation
+ of custom DIT structure rules by the directory administrator(s) if
+ desired. See Section 4.1.7.1 of [RFC4512] for details.
+
+3. IANA Considerations
+
+ There are no requests to IANA in this document at this time.
+
+4. Security Considerations
+
+ There are no security considerations applicable to this ID.
+
+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.
+
+ RADSA Coretta, J., "The OID Directory: The RA DSA",
+ draft-coretta-oiddir-radsa, February 2024.
+
+ RADUA Coretta, J., "The OID Directory: The RA DUA",
+ draft-coretta-oiddir-radua, February 2024.
+
+ [RFC2079] Smith, M., "Definition of an X.500 attribute type and an
+ object class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+ [RFC2578] Rose, M., et al, "Structure of Management Information
+ Version 2 (SMIv2)", RFC 2578, April 1999.
+
+ [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.
+
+ [RFC3986] Lee-Berners, T., "Uniform Resource Identifier (URI):
+ Generic Syntax", RFC 3986, January 2005.
+
+ [RFC3987] Duerst, M., "Internationalized Resource Identifiers
+ (IRIs)", RFC 3987, January 2005.
+
+ [RFC4122] Leach, P., "A Universally Unique IDentifier (UUID) URN
+ Namespace", RFC 4122, July 2005.
+
+
+
+Coretta Expires August 27, 2024 [Page 54]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names",
+ RFC 4514, June 2006.
+
+ [RFC4517] Legg, Ed., S., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, June
+ 2006.
+
+ [RFC4524] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): COSINE LDAP/X.500 Schema", RFC 4524, June 2006.
+
+ [RFC4530] Zeilenga, K,. "Lightweight Directory Access Protocol
+ (LDAP) entryUUID Operational Attribute", RFC 4530, June
+ 2006.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", RFC 8174, May 2017.
+
+ [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.667] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Information technology -
+ Procedures for the operation of object identifier
+ registration authorities: Generation of universally unique
+ identifiers and their use in object identifiers", ITU-T
+ X.667, October 2012.
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation", ITU-T X.680,
+ July 2002.
+
+5.2. Informative References
+
+ [RFC1155] Rose, M., "Structure and Identification of Management
+ Information for TCP/IP-based Internets", RFC 1155, May
+ 1990.
+
+ [X.500] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Overview of
+ concepts, models and services", ITU-T X.500, October 2019.
+
+Coretta Expires August 27, 2024 [Page 55]
+
+ Internet-Draft The OID Directory: Schema February 2024
+
+
+ [X.672] International Telecommunication Union - Telecommunication
+ Standardization Sector, "OID resolution system: Problems,
+ requirements and potential solutions", ITU-T X.672, March
+ 2020.
+
+Author's Address
+
+ Jesse Coretta
+ California, United States
+
+ Email: jesse.coretta@icloud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coretta Expires August 27, 2024 [Page 56]
diff --git a/docs/specs/draft-ietf-kitten-scram-2fa-03.txt b/docs/specs/draft-ietf-kitten-scram-2fa-04.txt
similarity index 92%
rename from docs/specs/draft-ietf-kitten-scram-2fa-03.txt
rename to docs/specs/draft-ietf-kitten-scram-2fa-04.txt
index ca8fe7eaf..62081e547 100644
--- a/docs/specs/draft-ietf-kitten-scram-2fa-03.txt
+++ b/docs/specs/draft-ietf-kitten-scram-2fa-04.txt
@@ -4,13 +4,13 @@
Network Working Group A. Melnikov
Internet-Draft Isode Ltd
-Intended status: Standards Track 24 August 2023
-Expires: 25 February 2024
+Intended status: Standards Track 4 March 2024
+Expires: 5 September 2024
Extensions to Salted Challenge Response (SCRAM) for 2 factor
authentication
- draft-ietf-kitten-scram-2fa-03
+ draft-ietf-kitten-scram-2fa-04
Abstract
@@ -22,7 +22,7 @@ Abstract
reauthentication.
This specification also gives 2 examples of second factors: TOTP (RFC
- 6238) and FIDO CTAP1/U2F.
+ 6238) and FIDO CTAP1/U2F (Passkey).
Status of This Memo
@@ -39,11 +39,11 @@ Status of This Memo
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 25 February 2024.
+ This Internet-Draft will expire on 5 September 2024.
Copyright Notice
- Copyright (c) 2023 IETF Trust and the persons identified as the
+ 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
@@ -53,9 +53,9 @@ Copyright Notice
-Melnikov Expires 25 February 2024 [Page 1]
+Melnikov Expires 5 September 2024 [Page 1]
-Internet-Draft SCRAM 2FA extensions August 2023
+Internet-Draft SCRAM 2FA extensions March 2024
and restrictions with respect to this document. Code Components
@@ -68,7 +68,6 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SCRAM Extension for 2FA . . . . . . . . . . . . . . . . . . . 3
4. SCRAM Extension for reauthentication . . . . . . . . . . . . 4
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4
@@ -109,9 +108,10 @@ Table of Contents
-Melnikov Expires 25 February 2024 [Page 2]
+
+Melnikov Expires 5 September 2024 [Page 2]
-Internet-Draft SCRAM 2FA extensions August 2023
+Internet-Draft SCRAM 2FA extensions March 2024
2. Conventions Used in This Document
@@ -143,10 +143,6 @@ Internet-Draft SCRAM 2FA extensions August 2023
reference. Other terms defined in [RFC5802] are also used in this
document.
-2.2. Notation
-
- This document reuses notation defined in SCRAM.
-
3. SCRAM Extension for 2FA
This extension doesn't add any extra roundtrips to SCRAM
@@ -160,22 +156,20 @@ Internet-Draft SCRAM 2FA extensions August 2023
server. This extension also doesn't cover enrollment with a 2FA
system, such enrollment happends out-of-band.
-
-
-
-
-
-Melnikov Expires 25 February 2024 [Page 3]
-
-Internet-Draft SCRAM 2FA extensions August 2023
-
-
The server authenticates the client after receiving the second
message as described in Section 3 of [RFC5802]. If the client
included "type" and "second-factor" attributes defined in this
document (see Section 5) and the server supports the specified second
factor type, the server verifies content of the "second-factor"
according to the "type". If the second factor verification fails,
+
+
+
+Melnikov Expires 5 September 2024 [Page 3]
+
+Internet-Draft SCRAM 2FA extensions March 2024
+
+
the server MUST fail authentication and SHOULD return either
"replayed-second-factor" or "invalid-second-factor" error in the "e"
attribute. [[It would be possible to make the extra attributes
@@ -215,24 +209,22 @@ Internet-Draft SCRAM 2FA extensions August 2023
"ctap1" (see Section 8). If this attribute is specified, the "f"
attribute MUST also be specified.
+ * f: This attribute specifies the value of the second factor. For
+ "t=totp" it is 6 digit decimal number. [[Use 8 digits per Rick
+ van Rein?]] This attribute MUST be ignored unless the "t"
+ attribute is also specified.
+ * l: This attribute is used by some second factors (e.g. CTAP1) to
+ specify the challenge returned by the SCRAM server.
-Melnikov Expires 25 February 2024 [Page 4]
+Melnikov Expires 5 September 2024 [Page 4]
-Internet-Draft SCRAM 2FA extensions August 2023
-
+Internet-Draft SCRAM 2FA extensions March 2024
- * f: This attribute specifies the value of the second factor. For
- "t=totp" it is 6 digit decimal number. [[Use 8 digits per Rick
- van Rein?]] This attribute MUST be ignored unless the "t"
- attribute is also specified.
-
- * l: This attribute is used by some second factors (e.g. CTAP1) to
- specify the challenge returned by the SCRAM server.
* o: This attribute specifies the base64-encoded value of the
reauthentication token.
@@ -274,14 +266,6 @@ Internet-Draft SCRAM 2FA extensions August 2023
When TOTP is used with SCRAM, the following values for "t" and "f"
attributes (see Section 5 for their generic syntax) are used:
-
-
-
-Melnikov Expires 25 February 2024 [Page 5]
-
-Internet-Draft SCRAM 2FA extensions August 2023
-
-
* t: This attribute specifies the type of second factor. For TOTP
the value is "totp". If this attribute is specified, the "f"
attribute MUST also be specified.
@@ -290,6 +274,14 @@ Internet-Draft SCRAM 2FA extensions August 2023
"t=totp" it is 6 digit decimal number. This attribute MUST be
ignored unless the "t" attribute is also specified.
+
+
+
+Melnikov Expires 5 September 2024 [Page 5]
+
+Internet-Draft SCRAM 2FA extensions March 2024
+
+
A TOTP URI is specified with the following ABNF:
totp-uri = "otpauth" "://" "totp/" label "?secret=" secret
@@ -331,13 +323,6 @@ Internet-Draft SCRAM 2FA extensions August 2023
CTAP1/U2F the value is "ctap1". If this attribute is specified,
the "f" attribute MUST also be specified.
-
-
-Melnikov Expires 25 February 2024 [Page 6]
-
-Internet-Draft SCRAM 2FA extensions August 2023
-
-
* l: base64-encoded challenge as returned by SCRAM server.
* f: This attribute specifies the value of the second factor. For
@@ -346,6 +331,13 @@ Internet-Draft SCRAM 2FA extensions August 2023
attribute MUST be ignored unless the "t" attribute is also
specified.
+
+
+Melnikov Expires 5 September 2024 [Page 6]
+
+Internet-Draft SCRAM 2FA extensions March 2024
+
+
SCRAM client sends U2F_AUTHENTICATE command formatted as specified in
[FIDO-U2F-Raw-Message-Formats] to the authenticator (e.g. a USB or
NFC device).
@@ -387,13 +379,6 @@ Internet-Draft SCRAM 2FA extensions August 2023
- Other fields are specified in Section 5.8.1 of
[W3C_webauthn_3].
-
-
-Melnikov Expires 25 February 2024 [Page 7]
-
-Internet-Draft SCRAM 2FA extensions August 2023
-
-
* Use clientDataHash parameter of [CTAP2] request as CTAP1/U2F
challenge parameter (32 bytes).
@@ -402,6 +387,13 @@ Internet-Draft SCRAM 2FA extensions August 2023
bytes). (The rp.id parameter is the hostname of the SCRAM
server.)
+
+
+Melnikov Expires 5 September 2024 [Page 7]
+
+Internet-Draft SCRAM 2FA extensions March 2024
+
+
* Let credentialId is the byte string initialized with the id for
this PublicKeyCredentialDescriptor.
@@ -442,15 +434,21 @@ Internet-Draft SCRAM 2FA extensions August 2023
* Let signCount be a 4-byte unsigned integer initialized with CTAP1/
U2F response counter field.
+ Let authenticatorData is a byte string of following structure:
-Melnikov Expires 25 February 2024 [Page 8]
-
-Internet-Draft SCRAM 2FA extensions August 2023
- Let authenticatorData is a byte string of following structure:
+
+
+
+
+
+Melnikov Expires 5 September 2024 [Page 8]
+
+Internet-Draft SCRAM 2FA extensions March 2024
+
+===================+============================+==================+
| Length (in bytes) | Description | Value |
@@ -501,9 +499,11 @@ Internet-Draft SCRAM 2FA extensions August 2023
-Melnikov Expires 25 February 2024 [Page 9]
+
+
+Melnikov Expires 5 September 2024 [Page 9]
-Internet-Draft SCRAM 2FA extensions August 2023
+Internet-Draft SCRAM 2FA extensions March 2024
11. IANA Considerations
@@ -557,9 +557,9 @@ Internet-Draft SCRAM 2FA extensions August 2023
-Melnikov Expires 25 February 2024 [Page 10]
+Melnikov Expires 5 September 2024 [Page 10]
-Internet-Draft SCRAM 2FA extensions August 2023
+Internet-Draft SCRAM 2FA extensions March 2024
[draft-schmaus-kitten-sasl-ht]
@@ -613,9 +613,9 @@ Internet-Draft SCRAM 2FA extensions August 2023
-Melnikov Expires 25 February 2024 [Page 11]
+Melnikov Expires 5 September 2024 [Page 11]
-Internet-Draft SCRAM 2FA extensions August 2023
+Internet-Draft SCRAM 2FA extensions March 2024
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
@@ -669,4 +669,4 @@ Author's Address
-Melnikov Expires 25 February 2024 [Page 12]
+Melnikov Expires 5 September 2024 [Page 12]
diff --git a/docs/specs/draft-melnikov-scram-bis-03.txt b/docs/specs/draft-melnikov-scram-bis-04.txt
similarity index 89%
rename from docs/specs/draft-melnikov-scram-bis-03.txt
rename to docs/specs/draft-melnikov-scram-bis-04.txt
index 0e0506fee..d65be87e2 100644
--- a/docs/specs/draft-melnikov-scram-bis-03.txt
+++ b/docs/specs/draft-melnikov-scram-bis-04.txt
@@ -4,14 +4,14 @@
Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd
-Updates: 5802, 7677 (if approved) 24 August 2023
+Updates: 5802, 7677 (if approved) 4 March 2024
Intended status: Standards Track
-Expires: 25 February 2024
+Expires: 5 September 2024
Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-
API Mechanisms
- draft-melnikov-scram-bis-03
+ draft-melnikov-scram-bis-04
Abstract
@@ -35,11 +35,11 @@ Status of This Memo
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 25 February 2024.
+ This Internet-Draft will expire on 5 September 2024.
Copyright Notice
- Copyright (c) 2023 IETF Trust and the persons identified as the
+ 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
@@ -53,9 +53,9 @@ Copyright Notice
-Melnikov Expires 25 February 2024 [Page 1]
+Melnikov Expires 5 September 2024 [Page 1]
-Internet-Draft SASL SCRAM August 2023
+Internet-Draft SASL SCRAM March 2024
Table of Contents
@@ -109,9 +109,9 @@ Table of Contents
-Melnikov Expires 25 February 2024 [Page 2]
+Melnikov Expires 5 September 2024 [Page 2]
-Internet-Draft SASL SCRAM August 2023
+Internet-Draft SASL SCRAM March 2024
3. Implementation Recommendations
@@ -165,9 +165,9 @@ Internet-Draft SASL SCRAM August 2023
-Melnikov Expires 25 February 2024 [Page 3]
+Melnikov Expires 5 September 2024 [Page 3]
-Internet-Draft SASL SCRAM August 2023
+Internet-Draft SASL SCRAM March 2024
(assuming the Salt and hash iteration-count is stable). Therefore,
@@ -221,9 +221,9 @@ Internet-Draft SASL SCRAM August 2023
-Melnikov Expires 25 February 2024 [Page 4]
+Melnikov Expires 5 September 2024 [Page 4]
-Internet-Draft SASL SCRAM August 2023
+Internet-Draft SASL SCRAM March 2024
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
@@ -252,24 +252,24 @@ Internet-Draft SASL SCRAM August 2023
[I-D.kitten-scram-2fa]
Melnikov, A., "Extensions to Salted Challenge Response
(SCRAM) for 2 factor authentication", Work in Progress,
- Internet-Draft, draft-ietf-kitten-scram-2fa-03, 24 August
+ Internet-Draft, draft-ietf-kitten-scram-2fa-04, 24 August
2023, .
+ scram-2fa-04.txt>.
[I-D.melnikov-scram-sha-512]
Melnikov, A., "SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple
Authentication and Security Layer (SASL) Mechanisms", Work
in Progress, Internet-Draft, draft-melnikov-scram-sha-
- 512-03, 10 March 2022, .
+ 512-04, 10 March 2022, .
[I-D.melnikov-scram-sha3-512]
Melnikov, A., "SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS
Simple Authentication and Security Layer (SASL)
Mechanisms", Work in Progress, Internet-Draft, draft-
- melnikov-scram-sha3-512-03, 24 August 2023,
+ melnikov-scram-sha3-512-04, 24 August 2023,
.
+ scram-sha3-512-04.txt>.
6.2. Informative References
@@ -277,9 +277,9 @@ Internet-Draft SASL SCRAM August 2023
-Melnikov Expires 25 February 2024 [Page 5]
+Melnikov Expires 5 September 2024 [Page 5]
-Internet-Draft SASL SCRAM August 2023
+Internet-Draft SASL SCRAM March 2024
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
@@ -333,4 +333,4 @@ Author's Address
-Melnikov Expires 25 February 2024 [Page 6]
+Melnikov Expires 5 September 2024 [Page 6]
diff --git a/docs/specs/draft-melnikov-scram-sha-512-03.txt b/docs/specs/draft-melnikov-scram-sha-512-04.txt
similarity index 88%
rename from docs/specs/draft-melnikov-scram-sha-512-03.txt
rename to docs/specs/draft-melnikov-scram-sha-512-04.txt
index e1c5ad02e..7072f3093 100644
--- a/docs/specs/draft-melnikov-scram-sha-512-03.txt
+++ b/docs/specs/draft-melnikov-scram-sha-512-04.txt
@@ -4,13 +4,13 @@
Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd
-Intended status: Standards Track 10 March 2023
-Expires: 11 September 2023
+Intended status: Standards Track 4 March 2024
+Expires: 5 September 2024
SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security
Layer (SASL) Mechanisms
- draft-melnikov-scram-sha-512-03
+ draft-melnikov-scram-sha-512-04
Abstract
@@ -32,11 +32,11 @@ Status of This Memo
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 11 September 2023.
+ This Internet-Draft will expire on 5 September 2024.
Copyright Notice
- Copyright (c) 2023 IETF Trust and the persons identified as the
+ 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
@@ -53,9 +53,9 @@ Copyright Notice
-Melnikov Expires 11 September 2023 [Page 1]
+Melnikov Expires 5 September 2024 [Page 1]
-Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
+Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2024
Table of Contents
@@ -63,7 +63,7 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Word Definitions . . . . . . . . . . . . . . . . . . . . 2
3. SCRAM-SHA-512 and SCRAM-SHA-512-PLUS . . . . . . . . . . . . 2
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 2
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
@@ -73,11 +73,12 @@ Table of Contents
1. Introduction
- This document registers the SASL [RFC4422] mechanisms SCRAM-SHA-512
- and SCRAM-SHA-512-PLUS. SHA-512 has stronger security properties
- than SHA-1, and it is expected that SCRAM mechanisms based on it will
- have greater predicted longevity than the SCRAM mechanisms based on
- SHA-1.
+ This document registers 2 new SASL [RFC4422] mechanisms SCRAM-SHA-512
+ and SCRAM-SHA-512-PLUS, which are variants of Salted Challenge
+ Response Authentication Mechanism (SCRAM) [RFC5802]. SHA-512 has
+ stronger security properties than SHA-1, and it is expected that
+ SCRAM mechanisms based on it will have greater predicted longevity
+ than the SCRAM mechanisms based on SHA-1.
2. Key Word Definitions
@@ -99,24 +100,19 @@ Table of Contents
The GSS-API mechanism OID for SCRAM-SHA-512 is 1.3.6.1.5.5. (see
Section 5).
- This is a simple example of a SCRAM-SHA-512 authentication exchange
- when the client doesn't support channel bindings. The username
- 'user' and password 'pencil' are being used.
-
[[TBD: Add an example]]
+4. Security Considerations
+ The security considerations from [RFC5802] still apply.
-Melnikov Expires 11 September 2023 [Page 2]
-
-Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
-
-4. Security Considerations
+Melnikov Expires 5 September 2024 [Page 2]
+
+Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2024
- The security considerations from [RFC5802] still apply.
To be secure, SCRAM-SHA-512-PLUS MUST be used over a TLS channel that
has had the session hash extension [RFC7627] negotiated, or session
@@ -162,17 +158,17 @@ Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
Published specification (optional, recommended): RFC XXXX
+ Minimum iteration-count: 10000
+ OID: 1.3.6.1.5.5.
-Melnikov Expires 11 September 2023 [Page 3]
-
-Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
- Minimum iteration-count: 10000
+Melnikov Expires 5 September 2024 [Page 3]
+
+Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2024
- OID: 1.3.6.1.5.5.
Person & email address to contact for further information: IETF
KITTEN WG
@@ -188,8 +184,8 @@ Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
Subject: Registration of a new SASL SCRAM Family mechanism SCRAM-
SHA-512-PLUS
- SASL mechanism name (or prefix for the family): SCRAM-SHA-
- 512-PLUS
+ SASL mechanism name (or prefix for the family):
+ SCRAM-SHA-512-PLUS
Security considerations: Section 4 of RFC XXXX
@@ -217,19 +213,18 @@ Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
DOI 10.17487/RFC2119, March 1997,
.
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ DOI 10.17487/RFC4422, June 2006,
+ .
-Melnikov Expires 11 September 2023 [Page 4]
+Melnikov Expires 5 September 2024 [Page 4]
-Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
-
+Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2024
- [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
- Authentication and Security Layer (SASL)", RFC 4422,
- DOI 10.17487/RFC4422, June 2006,
- .
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
@@ -272,21 +267,21 @@ Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
DOI 10.17487/RFC4270, November 2005,
.
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ .
+
-Melnikov Expires 11 September 2023 [Page 5]
+Melnikov Expires 5 September 2024 [Page 5]
-Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2023
+Internet-Draft SASL SCRAM-SHA-512/SCRAM-SHA-512-PLUS March 2024
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", RFC 5226,
- DOI 10.17487/RFC5226, May 2008,
- .
-
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
@@ -333,4 +328,9 @@ Author's Address
-Melnikov Expires 11 September 2023 [Page 6]
+
+
+
+
+
+Melnikov Expires 5 September 2024 [Page 6]
diff --git a/docs/specs/draft-melnikov-scram-sha3-512-03.txt b/docs/specs/draft-melnikov-scram-sha3-512-04.txt
similarity index 84%
rename from docs/specs/draft-melnikov-scram-sha3-512-03.txt
rename to docs/specs/draft-melnikov-scram-sha3-512-04.txt
index ffa08a8c5..d70c20198 100644
--- a/docs/specs/draft-melnikov-scram-sha3-512-03.txt
+++ b/docs/specs/draft-melnikov-scram-sha3-512-04.txt
@@ -4,13 +4,13 @@
Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd
-Intended status: Standards Track 24 August 2023
-Expires: 25 February 2024
+Intended status: Standards Track 4 March 2024
+Expires: 5 September 2024
SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and
Security Layer (SASL) Mechanisms
- draft-melnikov-scram-sha3-512-03
+ draft-melnikov-scram-sha3-512-04
Abstract
@@ -32,11 +32,11 @@ Status of This Memo
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 25 February 2024.
+ This Internet-Draft will expire on 5 September 2024.
Copyright Notice
- Copyright (c) 2023 IETF Trust and the persons identified as the
+ 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
@@ -53,9 +53,9 @@ Copyright Notice
-Melnikov Expires 25 February 2024 [Page 1]
+Melnikov Expires 5 September 2024 [Page 1]
-Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
+Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS March 2024
Table of Contents
@@ -73,14 +73,15 @@ Table of Contents
1. Introduction
- This document registers the SASL [RFC4422] mechanisms SCRAM-SHA3-512
- and SCRAM-SHA3-512-PLUS. SHA3-512 has stronger security properties
- than SHA-1, and it is expected that SCRAM mechanisms based on it will
- have greater predicted longevity than the SCRAM mechanisms based on
- SHA-1. SHA3-512 works differently from SHA-2 family of hash
- functions, so it is also expected that vulnerabilities in SHA-2 hash
- functions are not going to necessarily affect SHA-3 family of hash
- functions.
+ This document registers 2 new SASL [RFC4422] mechanisms SCRAM-
+ SHA3-512 and SCRAM-SHA3-512-PLUS, which are variants of Salted
+ Challenge Response Authentication Mechanism (SCRAM) [RFC5802].
+ SHA3-512 has stronger security properties than SHA-1, and it is
+ expected that SCRAM mechanisms based on it will have greater
+ predicted longevity than the SCRAM mechanisms based on SHA-1.
+ SHA3-512 works differently from SHA-2 family of hash functions, so it
+ is also expected that vulnerabilities in SHA-2 hash functions are not
+ going to necessarily affect SHA-3 family of hash functions.
2. Key Word Definitions
@@ -102,16 +103,15 @@ Table of Contents
The GSS-API mechanism OID for SCRAM-SHA3-512 is 1.3.6.1.5.5.
(see Section 5).
- This is a simple example of a SCRAM-SHA3-512 authentication exchange
- when the client doesn't support channel bindings. The username
- 'user' and password 'pencil' are being used.
+ [[TBD: add an example.]]
-Melnikov Expires 25 February 2024 [Page 2]
+
+Melnikov Expires 5 September 2024 [Page 2]
-Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
+Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS March 2024
4. Security Considerations
@@ -165,9 +165,9 @@ Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
-Melnikov Expires 25 February 2024 [Page 3]
+Melnikov Expires 5 September 2024 [Page 3]
-Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
+Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS March 2024
Minimum iteration-count: 10000
@@ -188,8 +188,8 @@ Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
Subject: Registration of a new SASL SCRAM Family mechanism SCRAM-
SHA3-512-PLUS
- SASL mechanism name (or prefix for the family): SCRAM-
- SHA3-512-PLUS
+ SASL mechanism name (or prefix for the family):
+ SCRAM-SHA3-512-PLUS
Security considerations: Section 4 of RFC XXXX
@@ -221,9 +221,9 @@ Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
-Melnikov Expires 25 February 2024 [Page 4]
+Melnikov Expires 5 September 2024 [Page 4]
-Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
+Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS March 2024
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
@@ -277,9 +277,9 @@ Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
-Melnikov Expires 25 February 2024 [Page 5]
+Melnikov Expires 5 September 2024 [Page 5]
-Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS August 2023
+Internet-Draft SASL SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS March 2024
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
@@ -333,4 +333,4 @@ Author's Address
-Melnikov Expires 25 February 2024 [Page 6]
+Melnikov Expires 5 September 2024 [Page 6]
diff --git a/docs/specs/internet-drafts.html b/docs/specs/internet-drafts.html
index 3804b3ae9..f593ff47b 100644
--- a/docs/specs/internet-drafts.html
+++ b/docs/specs/internet-drafts.html
@@ -152,6 +152,40 @@ LDAP Specifications Defined in Internet Drafts
+
+ draft-coretta-oiddir-radit-00: The OID Directory: The RA DIT
+ Expiration Date: August 27, 2024
+
+
+
+
+ draft-coretta-oiddir-radsa-00: The OID Directory: The RA DSA
+
+ Expiration Date: August 27, 2024
+
+
+
+
+ draft-coretta-oiddir-radua-00: The OID Directory: The RA DUA
+
+ Expiration Date: August 27, 2024
+
+
+
+
+ draft-coretta-oiddir-roadmap-00: The OID Directory: A Technical Roadmap
+
+ Expiration Date: August 27, 2024
+
+
+
+
+ draft-coretta-oiddir-schema-01: The OID Directory: The Schema
+
+ Expiration Date: August 27, 2024
+
+
+
draft-coretta-x660-ldap-08: Lightweight Directory Access Protocol (LDAP) Procedures and Schema Definitions for the Storage of X.660 Registration Information
@@ -356,9 +390,9 @@ LDAP Specifications Defined in Internet Drafts
- draft-ietf-kitten-scram-2fa-03: Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication
+ draft-ietf-kitten-scram-2fa-04: Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication
- Expiration Date: February 25, 2024
+ Expiration Date: September 5, 2024
@@ -623,23 +657,23 @@ LDAP Specifications Defined in Internet Drafts
- draft-melnikov-scram-bis-03: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
+ draft-melnikov-scram-bis-04: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
- Expiration Date: February 25, 2024
+ Expiration Date: September 5, 2024
- draft-melnikov-scram-sha-513-02: SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
+ draft-melnikov-scram-sha-512-04: SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
- Expiration Date: September 11, 2023
+ Expiration Date: September 5, 2024
- draft-melnikov-scram-sha3-512-03: SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
+ draft-melnikov-scram-sha3-512-04: SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
- Expiration Date: February 25, 2024
+ Expiration Date: September 5, 2024