From 05ca9f579c9c22276ea0d4fa61c9cbb7101dd5fe Mon Sep 17 00:00:00 2001 From: Neil Wilson Date: Mon, 4 Mar 2024 10:33:58 -0600 Subject: [PATCH] Documentation updates for LDAP-related specs 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. --- docs/release-notes.html | 16 + docs/specs/draft-coretta-oiddir-radit-00.txt | 2205 +++++++++++ docs/specs/draft-coretta-oiddir-radsa-00.txt | 697 ++++ docs/specs/draft-coretta-oiddir-radua-00.txt | 1451 ++++++++ .../specs/draft-coretta-oiddir-roadmap-00.txt | 754 ++++ docs/specs/draft-coretta-oiddir-schema-01.txt | 3246 +++++++++++++++++ ...txt => draft-ietf-kitten-scram-2fa-04.txt} | 136 +- ...03.txt => draft-melnikov-scram-bis-04.txt} | 44 +- ...xt => draft-melnikov-scram-sha-512-04.txt} | 90 +- ...t => draft-melnikov-scram-sha3-512-04.txt} | 58 +- docs/specs/internet-drafts.html | 50 +- 11 files changed, 8575 insertions(+), 172 deletions(-) create mode 100644 docs/specs/draft-coretta-oiddir-radit-00.txt create mode 100644 docs/specs/draft-coretta-oiddir-radsa-00.txt create mode 100644 docs/specs/draft-coretta-oiddir-radua-00.txt create mode 100644 docs/specs/draft-coretta-oiddir-roadmap-00.txt create mode 100644 docs/specs/draft-coretta-oiddir-schema-01.txt rename docs/specs/{draft-ietf-kitten-scram-2fa-03.txt => draft-ietf-kitten-scram-2fa-04.txt} (92%) rename docs/specs/{draft-melnikov-scram-bis-03.txt => draft-melnikov-scram-bis-04.txt} (89%) rename docs/specs/{draft-melnikov-scram-sha-512-03.txt => draft-melnikov-scram-sha-512-04.txt} (88%) rename docs/specs/{draft-melnikov-scram-sha3-512-03.txt => draft-melnikov-scram-sha3-512-04.txt} (84%) 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