Lightweight Directory Access Protocol (LDAP) Procedures and Schema Definitions for the Storage of X.660 Registration Information
draft-coretta-x660-ldap-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Jesse Coretta | ||
| Last updated | 2021-07-25 | ||
| Replaced by | draft-coretta-oiddir-schema | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-coretta-x660-ldap-07
X660LDAP J. Coretta
Internet-Draft July 24, 2021
Intended status: Standards Track
Expires: January 24, 2022
Lightweight Directory Access Protocol (LDAP)
Procedures and Schema Definitions for the
Storage of X.660 Registration Information
draft-coretta-x660-ldap-07.txt
Abstract
This specification defines models, procedures and schema definitions
meant to facilitate the storage of [X.660] registration data within
a Lightweight Directory Access Protocol Directory Information Tree.
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 January 24, 2022.
Copyright Notice
Copyright (c) 2021 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 January 24, 2022 [Page 1]
Internet-Draft X.660 LDAP Schema and Models July 2021
Table of Contents
1. Introduction ....................................................4
1.1. Conventions ................................................5
1.2. Acronyms Used ..............................................5
1.3. Intended Audience ..........................................5
1.4. OIDs Allocated .............................................5
1.5. Well-Known OIDs ............................................6
2. Schema Definitions ..............................................6
2.1. Attribute Types ............................................6
2.1.1. 'n' ...................................................7
2.1.2. 'dotNotation' .........................................7
2.1.3. 'iRI' .................................................7
2.1.4. 'asn1Notation' ........................................8
2.1.5. 'unicodeValue' ........................................8
2.1.6. 'identifier' ..........................................8
2.1.7. 'additionalIdentifier' ................................9
2.1.8. 'registrationInformation' .............................9
2.1.9. 'registrationURI' .....................................9
2.1.10. 'registrationCreated' ...............................10
2.1.11. 'registrationModified' ..............................10
2.1.12. 'registrationRange' .................................10
2.1.13. 'registrationStatus' ................................11
2.1.14. 'isLeafNode' ........................................12
2.1.15. 'isFrozen' ..........................................12
2.1.16. 'stdNameForm' .......................................13
2.1.17. 'nameAndNumberForm' .................................13
2.1.18. 'longArc' ...........................................14
2.1.19. 'supArc' ............................................14
2.1.20. 'topArc' ............................................14
2.1.21. 'subArc' ............................................15
2.1.22. 'leftArc' ...........................................15
2.1.23. 'firstArc' ..........................................16
2.1.24. 'rightArc' ..........................................16
2.1.25. 'finalArc' ..........................................17
2.1.26. 'discloseTo' ........................................17
2.1.27. 'registrantID .......................................18
2.1.28. 'currentAuthority' ..................................18
2.1.29. 'currentAuthorityStartTimestamp' ....................19
2.1.30. 'currentAuthorityCommonName' ........................19
2.1.31. 'currentAuthorityCountryCode' .......................19
2.1.32. 'currentAuthorityCountryName' .......................20
2.1.33. 'currentAuthorityEmail' .............................20
2.1.34. 'currentAuthorityFax' ...............................20
2.1.35. 'currentAuthorityLocality' ..........................21
2.1.36. 'currentAuthorityMobile' ............................21
2.1.37. 'currentAuthorityOrg' ...............................21
2.1.38. 'currentAuthorityPOBox' .............................22
2.1.39. 'currentAuthorityPostalAddress' .....................22
2.1.40. 'currentAuthorityPostalCode' ........................23
2.1.41. 'currentAuthorityState' .............................23
2.1.42. 'currentAuthorityStreet' ............................23
Coretta Expires January 24, 2022 [Page 2]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.43. 'currentAuthorityTelephone' .........................24
2.1.44. 'currentAuthorityTitle' .............................24
2.1.45. 'currentAuthorityURI' ...............................24
2.1.46. 'firstAuthority' ....................................25
2.1.47. 'firstAuthorityStartTimestamp' ......................25
2.1.48. 'firstAuthorityEndTimestamp' ........................25
2.1.49. 'firstAuthorityCommonName' ..........................26
2.1.50. 'firstAuthorityCountryCode' .........................26
2.1.51. 'firstAuthorityCountryName' .........................26
2.1.52. 'firstAuthorityEmail' ...............................27
2.1.53. 'firstAuthorityFax' .................................27
2.1.54. 'firstAuthorityLocality' ............................27
2.1.55. 'firstAuthorityMobile' ..............................28
2.1.56. 'firstAuthorityOrg' .................................28
2.1.57. 'firstAuthorityPOBox' ...............................28
2.1.58. 'firstAuthorityPostalAddress' .......................29
2.1.59. 'firstAuthorityPostalCode' ..........................29
2.1.60. 'firstAuthorityState' ...............................30
2.1.61. 'firstAuthorityStreet' ..............................30
2.1.62. 'firstAuthorityTelephone' ...........................30
2.1.63. 'firstAuthorityTitle' ...............................31
2.1.64. 'firstAuthorityURI' .................................31
2.1.65. 'sponsor' ...........................................31
2.1.66. 'sponsorStartTimestamp ..............................32
2.1.67. 'sponsorEndTimestamp ................................32
2.1.68. 'sponsorCommonName' .................................32
2.1.69. 'sponsorCountryCode' ................................33
2.1.70. 'sponsorCountryName' ................................33
2.1.71. 'sponsorEmail' ......................................33
2.1.72. 'sponsorFax' ........................................34
2.1.73. 'sponsorLocality' ...................................34
2.1.74. 'sponsorMobile' .....................................34
2.1.75. 'sponsorOrg' ........................................34
2.1.76. 'sponsorPOBox' ......................................35
2.1.77. 'sponsorPostalAddress' ..............................35
2.1.78. 'sponsorPostalCode' .................................35
2.1.79. 'sponsorState' ......................................36
2.1.80. 'sponsorStreet' .....................................36
2.1.81. 'sponsorTelephone' ..................................36
2.1.82. 'sponsorTitle' ......................................37
2.1.83. 'sponsorURI' ........................................37
2.1.84. 'rARegistrationBase' ................................37
2.1.85. 'rARegistrantBase' ..................................38
2.1.86. 'rADirectoryModel' ..................................38
2.1.87. 'rAServiceMail' .....................................39
2.1.88. 'rAServiceURI' ......................................39
2.2. Object Classes ............................................40
2.2.1. 'x660RootArc' ........................................40
2.2.2. 'x660SubArc' .........................................40
2.2.3. 'x660Registrant' .....................................41
2.2.4. 'x660DUAConfig' ......................................41
3. Directory Models and Procedures ................................42
Coretta Expires January 24, 2022 [Page 3]
Internet-Draft X.660 LDAP Schema and Models July 2021
3.1. Naming Context and Organization Entries ...................42
3.2. Two-Dimensional Model .....................................42
3.2.1. Requirements .........................................42
3.2.2. Distinguished Name Convention ........................43
3.2.3. Root Arc Entries .....................................43
3.3. Three-Dimensional Model ...................................44
3.3.1. Requirements .........................................44
3.3.2. Distinguished Name Convention ........................45
3.3.3. Root Arc Entries .....................................46
3.3.3.1. Lack of Root Arc Entries ........................46
3.4. Registrant Information ....................................48
3.4.1. Use of Collective or Virtual Attributes ..............48
3.4.2. Examples .............................................49
3.4.2.1. Combined Registration and Registrant
Entries .........................................49
3.4.2.2. Dedicated Registrant Entries ....................49
3.5. DUA Configuration .........................................51
3.5.1. Manual Configuration .................................51
3.5.2. Automatic Configuration ..............................51
3.5.2.1. Examples ........................................52
3.6. Spatial Orientation and Navigation ........................53
3.6.1. Client Capabilities ..................................53
3.6.1.1. Locating Individual Registrations ...............54
3.6.1.2. Traversing Adjacent or Ancestral
Registrations ...................................54
3.6.1.2.1. Use of the 'supArc' and 'topArc'
Attribute Types ............................55
3.6.1.2.2. Use of the 'subArc' Attribute Type .........56
3.6.1.2.2.1. Awareness of Subordinate
Registration Constraints ..............57
3.6.1.2.3. Use of Sibling Adjacency Attribute
Types ......................................57
3.7. DSA Resource Utilization and Administrative Costs .........59
3.7.1. Literal vs. Composite Values .........................59
3.7.2. Subtree Search Operations ............................60
4. IANA Considerations ............................................61
5. Security Considerations ........................................61
5.1. Modification Identity Obfuscation .........................62
5.2. Registrant Privacy ........................................62
6. References .....................................................62
6.1. Normative References ......................................62
6.2. Informative References ....................................63
Author's Address ..................................................64
1. Introduction
This specification describes a means for storing [X.660] registration
and OPTIONAL registrant data within an LDAP [RFC4510] implementation.
Some additional concepts and strategies are introduced that are not
explicitly defined in either [X.660] or [X.680]. These concepts are
meant to facilitate ease-of-implementation and sensible consumption.
Coretta Expires January 24, 2022 [Page 4]
Internet-Draft X.660 LDAP Schema and Models July 2021
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
This specification makes reference to several acronyms, each of which
are defined below.
DN Distinguished Name
RA Registration Authority
DIT Directory Information Tree
DSA Directory System Agent
DUA Directory User Agent (an LDAP client)
GUI Graphical User Interface
IRI Internationalized Resource Identifier
OID ASN.1 Object Identifier
PEN IANA Private Enterprise Number
RDN Relative Distinguished Name
TUI Textual User Interface
URI Uniform Resource Identifier
LDAP Lightweight Directory Access Protocol
ASN.1 Abstract Syntax Notation one
1.3. Intended Audience
This specification is intended for use by any entity or individual in
need of a means for storing and serving [X.660] data, in whole or in
part. The most likely candidates for use are RAs, whether internal to
an organization or public.
1.4. OIDs Allocated
This specification provides a dedicated registered OID branch for all
LDAP schema elements as defined in Section 2, as well as OIDs for two
(2) directory models defined in Section 3.
- 1.3.6.1.4.1.56521 (author root)
- 1.3.6.1.4.1.56521.101 (this specification)
- 1.3.6.1.4.1.56521.101.2 (schema)
- 1.3.6.1.4.1.56521.101.2.1 (attribute types)
- 1.3.6.1.4.1.56521.101.2.2 (object classes)
- 1.3.6.1.4.1.56521.101.3 (models)
- 1.3.6.1.4.1.56521.101.3.2 (twoDimensional)
- 1.3.6.1.4.1.56521.101.3.3 (threeDimensional)
Coretta Expires January 24, 2022 [Page 5]
Internet-Draft X.660 LDAP Schema and Models July 2021
1.5. Well-Known OIDs
This specification makes use of well-known OIDs defined by other
parties or institutions. These OIDs are mentioned for example
purposes and schema configuration only.
- 1.3 (Identified-Organization, per Section A.4.2 of [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.4.1.1466.115.121.1.12 (Distinguished Name syntax and
matching rule, per Section 4.2.15 of [RFC4517])
- 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 of
[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 specification.
These schema definitions described in this section are provided using
LDAP description formats [RFC4512]. These elements are line-wrapped
and indented for readability.
2.1. Attribute Types
The following subsections detail 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
Documents, and as such are dependencies:
- [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.
Coretta Expires January 24, 2022 [Page 6]
Internet-Draft X.660 LDAP Schema and Models July 2021
If a directory architect opts to extend certain definitions in this
Section for the purpose of Collective Attribute [RFC3671] support,
they are advised to adhere to the prescribed attribute type naming
prefix ("c-"), per Section 3 of [RFC3671].
Very few attribute types are actually REQUIRED for registrations and
not all types will necessarily apply to every situation. Directory
architects are advised to carefully identify what types are needed,
and make interactive procedures and "best practices" available and
well-documented for all relevant consuming entities.
2.1.1. 'n'
The 'n' attribute type allows the assignment of an unsigned integer,
meant to represent the primary identifier, or NumberForm [X.680], of
the entry.
This attribute type plays a crucial role with regards to DN syntax
used in the three-dimensional directory model described in Section
3.3.
( 1.3.6.1.4.1.56521.101.2.1.1
NAME ( 'n' 'numberForm' )
DESC 'A single unsigned integer value assigned to
a registration to represent its primary integer
identifier'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
Examples: "56521", "0"
2.1.2. 'dotNotation'
The 'dotNotation' attribute type allows the assignment of an OID
value [X.680] in dot-delimited form to a registration entry.
( 1.3.6.1.4.1.56521.101.2.1.2
NAME 'dotNotation'
DESC 'Dotted ASN.1 Object Identifier for a
registration'
EQUALITY objectIdentifierMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Examples: "1.3.6.1", "2.999"
2.1.3. 'iRI'
The 'iRI' attribute type allows the assignment of one or more IRI
values to an registration entry.
Coretta Expires January 24, 2022 [Page 7]
Internet-Draft X.660 LDAP Schema and Models July 2021
( 1.3.6.1.4.1.56521.101.2.1.3
NAME 'iRI'
DESC 'Internationalized Resource Identifiers
for a registration'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Examples: "/ITU-T", "/ISO/Identified-Organization", "/ASN.1"
2.1.4. 'asn1Notation'
The 'asn1Notation' attribute type allows the assignment of an OID
in ASN.1 notation to a registration entry.
( 1.3.6.1.4.1.56521.101.2.1.4
NAME 'asn1Notation'
DESC 'An ordered sequence of NameAndNumberForm
or NumberForm values, enclosed within curly
braces, that identify an OID'
SINGLE-VALUE
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Examples: "{itu-t(0)}", "{iso(1) identified-organization(3)}"
2.1.5. 'unicodeValue'
The 'unicodeValue' attribute type allows the assignment of one or
more Unicode-based primary identifiers (non-numeric) [X.660] to a
registration entry.
Although multi-value support is positive, cases in which any given
registration has multiple 'unicodeValue' values is extremely rare.
( 1.3.6.1.4.1.56521.101.2.1.5
NAME 'unicodeValue'
DESC 'Primary non-numeric Unicode identifiers
for a registration'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Examples: "ITU-T", "Identified-Organization"
2.1.6. 'identifier'
The 'identifier' attribute type allows the assignment of a single
non-Unicode, non-numeric identifier [X.660], or NameForm [X.680],
to a registration entry.
The first character MUST be a lowercase letter and MUST NOT include
any white space.
Coretta Expires January 24, 2022 [Page 8]
Internet-Draft X.660 LDAP Schema and Models July 2021
The same value can be applied to the 'nameAndNumberForm' attribute
as a partial value. See Section 2.1.17 for more information on this
attribute type.
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.1.6
NAME ( 'identifier' 'nameForm' )
DESC 'The non-Unicode secondary identifier
for a registration'
SINGLE-VALUE
SUP name )
Examples: "itu-t", "iso"
2.1.7. 'additionalIdentifier'
The 'additionalIdentifier' attribute type allows the assignment of
of one or more additional identifiers [X.660] in a registration.
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.1.7
NAME 'additionalIdentifier'
DESC 'The non-Unicode additional identifiers
or nameForms for a registration'
SUP name )
Examples: "enterprises", "ccitt"
2.1.8. 'registrationInformation'
The 'registrationInformation' attribute type allows the OPTIONAL
assignment of octet based values intended for extended information
relating to the registration in question.
( 1.3.6.1.4.1.56521.101.2.1.8
NAME 'registrationInformation'
DESC 'Extended octet-based data for
a registration'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{4096} )
2.1.9. 'registrationURI'
The 'registrationURI' attribute type allows for the assignment of
one or more URI values, with optional labels, to a registration.
Coretta Expires January 24, 2022 [Page 9]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.9
NAME 'registrationURI'
DESC 'URI, with an optional label, leading to
further related subject matter information'
SUP labeledURI )
Examples: "http://example.com Example", "http://example.com"
2.1.10. '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.
( 1.3.6.1.4.1.56521.101.2.1.10
NAME 'registrationCreated'
DESC 'Generalized timestamp for
registration creation'
SINGLE-VALUE
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Examples: "19951231115959Z", "20130109033116Z"
2.1.11. 'registrationModified'
The 'registrationModified' attribute type allows for the assignment
of one or more generalized timestamp values indicating the dates
and times of all applied updates to a registration.
Whether multiple dates, or only most recent date, are stored is
entirely up to the directory architect(s) involved.
( 1.3.6.1.4.1.56521.101.2.1.11
NAME 'registrationModified'
DESC 'Generalized timestamps for
registration modifications'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Examples: "19951231115959Z", "20130109033116Z"
2.1.12. 'registrationRange'
The 'registrationRange' attribute type allows for the expression of
an OID allocation range, such as "100" to indicate 'up to 100', as
well as "-1" to indicate 'to infinity'.
Coretta Expires January 24, 2022 [Page 10]
Internet-Draft X.660 LDAP Schema and Models July 2021
The implied start of a range is the 'n' value of the registration
entry that bears this attribute type, and would not need to be set
explicitly.
The value of this attribute MUST always be greater-than and NOT equal
to the value of 'n' EXCEPT when "-1" is used.
For example, if a 'rangeTermintor' 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'.
Similarly, keeping with the same example above, if a value of "-1"
were used instead, this MUST be interpreted as an all-encompassing
OID range starting at '2.999.44' with absolutely no upper limit.
DUAs used to manage and allocate registration entries MUST always
perform preemptive searches for occurrences of this attribute type
prior to allocating any sibling registrations, so as to avoid illegal
overlaps.
( 1.3.6.1.4.1.56521.101.2.1.12
NAME 'registrationRange'
DESC 'Sibling registration range expression'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
Examples: "-1", "1999", "1000000"
2.1.13. 'registrationStatus'
The 'registrationStatus' attribute type allows for the assignment
of status information, indicative of the current state of the
registration. Multiple values can be provided, however not all
combinations are meaningful.
In most cases, this is used to mark a registration as "obsolete",
"reserved", "private" or "deallocated", however values of "active"
or "in-force" are also applicable in some cases.
Absence of this attribute type within a given entry SHOULD be viewed
as an implied declaration of "active" or "in-force".
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. In addition,
it is possible to leverage the 'discloseTo' attribute type defined
in Section 2.1.26. See Section 5 for more information.
Other possible values not listed here MAY be used, however they would
be wholly proprietary in nature.
Coretta Expires January 24, 2022 [Page 11]
Internet-Draft X.660 LDAP Schema and Models July 2021
( 1.3.6.1.4.1.56521.101.2.1.13
NAME 'registrationStatus'
DESC 'Current status of a registration'
SINGLE-VALUE
SUP description )
Examples: "obsolete", "deallocated", "reserved"
2.1.14. '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.
Absence of this attribute type SHOULD be interpreted as an implicit
FALSE value.
A value of FALSE indicates there are no restrictions regarding the
allocation or enumeration of any child entries.
A value of TRUE forbids the enumeration of all existing subordinate
registrations, as well as the creation of new registrations.
When TRUE, this attribute type implies a TRUE value for 'isFrozen',
per Section 2.1.15. See Section 3.6.1.2.2.1 for considerations on
various combinations of these attribute types.
This attribute type is NOT meant to serve in a security capacity. If
it is desirable to limit the enumeration of subordinate registrations
with privacy or security in mind, the attribute types 'discloseTo'
(Section 2.1.26) and/or 'registrationStatus' (Section 2.1.13) would
be more appropriate.
( 1.3.6.1.4.1.56521.101.2.1.14
NAME 'isLeafNode'
DESC 'Whether a registration may allocate,
or allow the enumeration of, subordinate
registrations'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
Example: "TRUE", "FALSE", or UNDEFINED (implies "FALSE")
2.1.15. '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.
Coretta Expires January 24, 2022 [Page 12]
Internet-Draft X.660 LDAP Schema and Models July 2021
A value of TRUE indicates that the given registration MUST NOT have
any further children allocated, but that any entries that are already
allocated SHALL be enumerated.
A value of FALSE indicates there are no restrictions regarding the
allocation of any subsequent child entries, UNLESS a value of TRUE
is defined for the 'isLeafNode' attribute type, per Section 2.1.14.
Such a value supersedes any state of this attribute type. Please
see Section 3.6.1.2.2.1 for considerations on various combinations
of these attribute types.
( 1.3.6.1.4.1.56521.101.2.1.15
NAME 'isFrozen'
DESC 'Whether a registration may allocate
any additional subordinate registrations'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
Example: "TRUE", "FALSE", or UNDEFINED (implies "FALSE")
2.1.16. 'stdNameForm'
The 'stdNameForm' attribute type allows for the assignment of one
or more Standardized NameForm values, per [X.660] and [X.680], to
a registration.
( 1.3.6.1.4.1.56521.101.2.1.16
NAME 'stdNameForm'
DESC 'Standardized NameForm per X.680'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Example: "{itu-t}", "{0 0 d}"
2.1.17. 'nameAndNumberForm'
The 'nameAndNumberForm' attribute type allows for the assignment of
an [X.680] NameAndNumberForm value to a registration.
The value assigned to this attribute MUST manifest as a combination
of values of 'identifier' and/or (at a minimum) 'n'.
( 1.3.6.1.4.1.56521.101.2.1.17
NAME 'nameAndNumberForm'
DESC 'NameAndNumberForm value, per X.680'
EQUALITY caseExactMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Example: "private(4)", "itu-t(0)", "56521"
Coretta Expires January 24, 2022 [Page 13]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.18. 'longArc'
The 'longArc' attribute type allows the assignment of one or more
so-called "Long Arc" well-known identifiers to a registration.
Per [X.660], entries that bear values of this attribute type MUST
reside below the root joint-iso-itu-t(2) registration.
( 1.3.6.1.4.1.56521.101.2.1.18
NAME 'longArc'
DESC 'The well-known Long Arc names associated with,
and registered to, a Joint-ISO-ITU-T subordinate
registration'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Examples: "/Example", "/Ejemplo"
2.1.19. 'supArc'
The 'supArc' attribute type allows for the assignment of an LDAP DN
value to a registration, thereby identifying the DN of the immediate
superior (parent) registration entry.
For example, the OID registration for 2.1.4 (ecn) would possess a DN
value for this attribute type identifying its superior registration
entry as 2.1 (asn1).
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type. This sub type is
MULTI-VALUED so as to support Collective Attribute extensibility
[RFC3671], but is intended only for the storage of a single DN value
per registration.
( 1.3.6.1.4.1.56521.101.2.1.19
NAME 'supArc'
DESC 'LDAP Distinguished Name of the logically
superior immediate registration'
SUP distinguishedName )
Example: "n=1,n=2,ou=OID,ou=X660,dc=example,dc=com"
2.1.20. 'topArc'
The 'topArc' attribute type allows for the assignment of an LDAP DN
value to a registration identifying the superior root registration.
Coretta Expires January 24, 2022 [Page 14]
Internet-Draft X.660 LDAP Schema and Models July 2021
For example, the OID registration for 2.1.4 (ecn) would possess a DN
value for this attribute type identifying its root registration entry
as 2 (Joint-ISO-ITU-T).
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type. This sub type is
MULTI-VALUED so as to support Collective Attribute extensibility
[RFC3671], but is intended only for the storage of a single DN value
per registration.
( 1.3.6.1.4.1.56521.101.2.1.20
NAME 'topArc'
DESC 'LDAP Distinguished Name of the absolute
superior root registration'
SUP distinguishedName )
Example: "n=2,ou=OID,ou=X660,dc=example,dc=com"
2.1.21. 'subArc'
The 'subArc' attribute type allows for the assignment of one or
more LDAP DN values to a registration as a manifest of subordinate
registrations residing exactly one (1) logical level below.
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
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.1.21
NAME 'subArc'
DESC 'LDAP Distinguished Names of immediate
subordinate registrations'
SUP distinguishedName )
Example: "n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com"
2.1.22. 'leftArc'
The 'leftArc' attribute type allows for the assignment of an LDAP
DN value to a registration. The value SHOULD reference the nearest
lexically-antecedent (left-hand) sibling registration.
As an example, given a registration for the OID 2.6 (mhs), the DN
referencing the OID 2.5 (ds) is the lexically-nearest antecedent
sibling registration.
Coretta Expires January 24, 2022 [Page 15]
Internet-Draft X.660 LDAP Schema and Models July 2021
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
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.1.22
NAME 'leftArc'
DESC 'LDAP Distinguished Name of the nearest
lexically antecedent sibling registration'
SINGLE-VALUE
SUP distinguishedName )
Example: "n=5,n=2,ou=OID,ou=X660,dc=example,dc=com"
2.1.23. 'firstArc'
The 'firstArc' attribute type allows for the assignment of an LDAP
DN value to a registration. The value SHOULD reference the absolute
farthest antecedent sibling registration.
As an example, given a registration for the OID 2.6 (mhs), while
the DN referencing 2.0 (presentation) is the lexically-farthest
antecedent sibling registration.
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type. This sub type is
MULTI-VALUED so as to support Collective Attribute extensibility
[RFC3671], but is intended only for the storage of a single DN value
per registration.
( 1.3.6.1.4.1.56521.101.2.1.23
NAME 'firstArc'
DESC 'LDAP Distinguished Name of the farthest
lexically antecedent sibling registration'
SUP distinguishedName )
Example: "n=0,n=2,ou=OID,ou=X660,dc=example,dc=com"
2.1.24. 'rightArc'
The 'rightArc' attribute type allows for the assignment of an LDAP
DN value to a registration. The value SHOULD reference the nearest
subsequent sibling registration.
As an example, given a registration for the OID 2.1 (asn1), the DN
referencing OID 2.2 (association-control) is the lexically-nearest
subsequent sibling registration.
Coretta Expires January 24, 2022 [Page 16]
Internet-Draft X.660 LDAP Schema and Models July 2021
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
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.1.24
NAME 'rightArc'
DESC 'LDAP Distinguished Name of the nearest
lexically subsequent sibling registration'
SINGLE-VALUE
SUP distinguishedName )
Example: "n=2,n=2,ou=OID,ou=X660,dc=example,dc=com"
2.1.25. 'finalArc'
The 'finalArc' attribute type allows for the assignment of an LDAP
DN value to a registration. The value SHOULD reference the absolute
farthest subsequent sibling registration.
As an example, given a registration for the OID 2.1 (asn1), the DN
referencing OID 2.999 (example) is lexically-farthest subsequent
sibling registration.
This OPTIONAL attribute type is among the seven (7) spatial types
discussed in more detail in Section 3.6.
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type. This sub type is
MULTI-VALUED so as to support Collective Attribute extensibility
[RFC3671], but is intended only for the storage of a single DN value
per registration.
( 1.3.6.1.4.1.56521.101.2.1.25
NAME 'finalArc'
DESC 'LDAP Distinguished Name of the farthest
lexically subsequent sibling registration'
SUP distinguishedName )
Example: "n=999,n=2,ou=OID,ou=X660,dc=example,dc=com"
2.1.26. 'discloseTo'
The 'discloseTo' attribute type allows for the assignment of one or
more LDAP DN values to a registration, each of which reference an
identity that is authorized to access the entry's information in
read-only fashion. This MAY cover any depth of subordinate entry
disclosures as seen fit by the directory architect(s).
Coretta Expires January 24, 2022 [Page 17]
Internet-Draft X.660 LDAP Schema and Models July 2021
Identities referenced through use of this attribute type MAY be
single user entries, a 'groupOfNames'-based entry, per Section
3.5 of [RFC4519] or a current authority or sponsorship registrant.
Write-based access SHOULD NOT be governed by this attribute type, as
that is an intended function of the current registration authority.
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.1.26
NAME 'discloseTo'
DESC 'LDAP Distinguished Names of entries which
are granted access to a given registration
and its immediate children'
SUP distinguishedName )
Example: "cn=ClearanceLevel4,ou=Groups,dc=example,dc=com"
2.1.27. '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. When used, this value would act as an absolute
identifier for registration entries that may change in the future.
In larger, more complete implementations of this specification, it
is RECOMMENDED that this attribute type be the primary identifier
(or, RDN) for registrant entries. This allows for an absolute and
unambiguous reference to any registration entry by DN in terms of
authority and/or sponsorship.
( 1.3.6.1.4.1.56521.101.2.1.27
NAME 'registrantID'
DESC 'Random identifier assigned
to a registrant'
SINGLE-VALUE
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Examples: "rfc4519", "69118e61-cc02-4c50-bde7-5bdaf4e973e4"
2.1.28. 'currentAuthority'
The 'currentAuthority' attribute type allows for the assignment
of one 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.
Coretta Expires January 24, 2022 [Page 18]
Internet-Draft X.660 LDAP Schema and Models July 2021
This attribute type is only required if registrant information is
not stored within a given registration directly.
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.1.28
NAME 'currentAuthority'
DESC 'LDAP Distinguished Name of an entry
bearing current registration authority
information'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,ou=X660,dc=example,dc=com"
2.1.29. 'currentAuthorityStartTimestamp'
The 'currentAuthorityStartTimestamp' attribute type allows for the
assignment of a generalized timestamp value to a current registration
authority, indicative of the date and time at which the current
registration authority was, or will be, officiated.
( 1.3.6.1.4.1.56521.101.2.1.29
NAME 'currentAuthorityStartTimestamp'
DESC 'Generalized time stamp indicating the date
and time at which current authority commenced'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example: "19951231115959Z"
2.1.30. '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.
( 1.3.6.1.4.1.56521.101.2.1.30
NAME 'currentAuthorityCommonName'
DESC 'Common Name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP cn )
Example: "Jesse Coretta", "Jane Smith"
2.1.31. 'currentAuthorityCountryCode'
The 'currentAuthorityCountryCode' attribute type allows for the
assignment of a country code to a current authority entry.
Coretta Expires January 24, 2022 [Page 19]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'c', as defined in Section 2.2 of [RFC4519], is
a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.31
NAME 'currentAuthorityCountryCode'
DESC 'Country Code assigned to a current
registration authority entry'
SINGLE-VALUE
SUP c )
Examples: "US", "CA"
2.1.32. '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.
( 1.3.6.1.4.1.56521.101.2.1.32
NAME 'currentAuthorityCountryName'
DESC 'Country name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP co )
Examples: "United States", "Canada"
2.1.33. '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.
( 1.3.6.1.4.1.56521.101.2.1.33
NAME 'currentAuthorityEmail'
DESC 'Email address assigned to a current
registration authority entry'
SINGLE-VALUE
SUP mail )
Example: "jesse.coretta@icloud.com"
2.1.34. 'currentAuthorityFax'
The 'currentAuthorityFax' attribute type allows for the assignment
of a facsimile telephone number to a current authority entry.
Coretta Expires January 24, 2022 [Page 20]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'facsimileTelephoneNumber', as defined in Section
2.10 of [RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.34
NAME 'currentAuthorityFax'
DESC 'Facsimile telephone number assigned to
a current registration authority entry'
SINGLE-VALUE
SUP facsimileTelephoneNumber )
Example: "+11234567890"
2.1.35. 'currentAuthorityLocality'
The 'currentAuthorityLocality' attribute type allows for the
assignment of a locality name 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.
( 1.3.6.1.4.1.56521.101.2.1.35
NAME 'currentAuthorityLocality'
DESC 'Locality name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP l )
Example: "Palm Springs", "Anna Maria Island"
2.1.36. 'currentAuthorityMobile'
The 'currentAuthorityMobile' attribute type allows for the
assignment of a mobile telephone number to a current registration
authoritative entry.
The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.36
NAME 'currentAuthorityMobile'
DESC 'Mobile telephone number assigned to a
current registration authority entry'
SINGLE-VALUE
SUP mobile )
Example: "+11234567890"
2.1.37. 'currentAuthorityOrg'
The 'currentAuthorityOrg' attribute type allows for the assignment
of an organization name to a current authority entry.
Coretta Expires January 24, 2022 [Page 21]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'o', as defined in Section 2.19 of [RFC4519], is
a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.37
NAME 'currentAuthorityOrg'
DESC 'Organization name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP o )
Example: "Acme, Co."
2.1.38. 'currentAuthorityPOBox'
The 'currentAuthorityPOBox' attribute type allows for the
assignment of a post office box number to a current registration
authority entry.
The attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.38
NAME 'currentAuthorityPOBox'
DESC 'Post office box number assigned to a
current registration authority entry'
SINGLE-VALUE
SUP postOfficeBox )
Examples: "555", "475"
2.1.39. 'currentAuthorityPostalAddress'
The 'currentAuthorityPostalAddress' attribute type allows for the
assignment of a complete postal address to a current 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.
( 1.3.6.1.4.1.56521.101.2.1.39
NAME 'currentAuthorityPostalAddress'
DESC 'Full postal address assigned to a current
registration authority entry'
SINGLE-VALUE
SUP postalAddress )
Example: "1 Fake St$Anytown$CA$12345$US"
Coretta Expires January 24, 2022 [Page 22]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.40. 'currentAuthorityPostalCode'
The 'currentAuthorityPostalCode' attribute type allows for the
assignment of a postal code 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.
( 1.3.6.1.4.1.56521.101.2.1.40
NAME 'currentAuthorityPostalCode'
DESC 'Postal code assigned to a current
registration authority entry'
SINGLE-VALUE
SUP postalCode )
Examples: "92262", "34216"
2.1.41. 'currentAuthorityState'
The 'currentAuthorityState' attribute type allows for the
assignment of a state or province name to a current registration
authority entry.
The attribute type 'st', as defined in Section 2.33 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.41
NAME 'currentAuthorityState'
DESC 'State or province name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP st )
Examples: "California", "North Dakota"
2.1.42. 'currentAuthorityStreet'
The 'currentAuthorityStreet' attribute type allows for the
assignment of a street name and number to a current registration
authority entry.
The attribute type 'street', as defined in Section 2.34 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.42
NAME 'currentAuthorityStreet'
DESC 'Street name and number assigned to a current
registration authority entry'
SINGLE-VALUE
SUP street )
Example: "1 Fake Street"
Coretta Expires January 24, 2022 [Page 23]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.43. 'currentAuthorityTelephone'
The 'currentAuthorityTelephone' attribute type allows for the
assignment of a telephone number 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.
( 1.3.6.1.4.1.56521.101.2.1.43
NAME 'currentAuthorityTelephone'
DESC 'Telephone number assigned to a current
registration authority entry'
SINGLE-VALUE
SUP telephoneNumber )
Example: "+11234567890"
2.1.44. '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.
( 1.3.6.1.4.1.56521.101.2.1.44
NAME 'currentAuthorityTitle'
DESC 'Title assigned to a current
registration authority entry'
SINGLE-VALUE
SUP title )
Example: "Chief Engineer"
2.1.45. 'currentAuthorityURI'
The 'currentAuthorityURI' attribute type allows for the
assignment of one or more URI values, with optional labels,
to a current authority entry.
The attribute type 'labeledURI', as defined in [RFC2079], is
a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.45
NAME 'currentAuthorityURI'
DESC 'URI, with an optional label, leading
to a resource related to a current
registration authority'
SUP labeledURI )
Example: "http://example.com Example", "http://example.com"
Coretta Expires January 24, 2022 [Page 24]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.46. 'firstAuthority'
The 'firstAuthority' attribute type allows for the assignment
of one or more DN values to an registration entry.
The value(s) of this attribute type are meant to refer to distinct
entries that contain previous authority information.
This attribute type is only required if registrant information is
not stored within a given registration directly.
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.1.46
NAME 'firstAuthority'
DESC 'LDAP Distinguished Name of an entry
bearing previous registration authority
information'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,ou=X660,dc=example,dc=com"
2.1.47. 'firstAuthorityStartTimestamp'
The 'firstAuthorityStartTimestamp' attribute type allows for
the assignment of a generalized timestamp value to a previous
registration authority, indicative of the date and time at which
the previous registration authority was, or will be, officiated.
( 1.3.6.1.4.1.56521.101.2.1.47
NAME 'firstAuthorityStartTimestamp'
DESC 'Generalized timestamp indicating the date and
time at which a previous registration authority
commenced'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example: "20130105135904Z"
2.1.48. 'firstAuthorityEndTimestamp'
The 'firstAuthorityEndTimestamp' attribute type allows for
the assignment of a generalized timestamp value to a previous
registration authority, indicative of the date and time at which
an entity's authoritative role was, or will be, terminated.
Coretta Expires January 24, 2022 [Page 25]
Internet-Draft X.660 LDAP Schema and Models July 2021
( 1.3.6.1.4.1.56521.101.2.1.48
NAME 'firstAuthorityEndTimestamp'
DESC 'Generalized timestamp indicating the date and
time at which a previous registration authority
terminated'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example: "20170528110555Z"
2.1.49. 'firstAuthorityCommonName'
The 'firstAuthorityCommonName' attribute type allows for the
assignment of a common name to a previous registration authority
entry.
The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.49
NAME 'firstAuthorityCommonName'
DESC 'Common Name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP cn )
Examples: "Jesse Coretta", "Jane Smith"
2.1.50. 'firstAuthorityCountryCode'
The 'firstAuthorityCountryCode' attribute type allows for the
assignment of a country code 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.
( 1.3.6.1.4.1.56521.101.2.1.50
NAME 'firstAuthorityCountryCode'
DESC 'Country Code assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP c )
Examples: "US", "CA"
2.1.51. 'firstAuthorityCountryName'
The 'firstAuthorityCountryName' attribute type allows for the
assignment of a country name to a previous registration authority
entry.
Coretta Expires January 24, 2022 [Page 26]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'co', as defined in Section 2.4 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.51
NAME 'firstAuthorityCountryName'
DESC 'Country name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP co )
Examples: "United States", "Canada"
2.1.52. '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.
( 1.3.6.1.4.1.56521.101.2.1.52
NAME 'firstAuthorityEmail'
DESC 'Email address assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP mail )
Example: "jesse.coretta@icloud.com"
2.1.53. 'firstAuthorityFax'
The 'firstAuthorityFax' attribute type allows for the assignment of
a facsimile telephone number to a previous registration authority
entry.
The attribute type 'facsimileTelephoneNumber', as defined in Section
2.10 of [RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.53
NAME 'firstAuthorityFax'
DESC 'Facsimile telephone number assigned to
a previous registration authority entry'
SINGLE-VALUE
SUP facsimileTelephoneNumber )
Example: "+11234567890"
2.1.54. 'firstAuthorityLocality'
The 'firstAuthorityLocality' attribute type allows for the
assignment of a locality name to a previous registration authority
entry.
Coretta Expires January 24, 2022 [Page 27]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'l', as defined in Section 2.16 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.54
NAME 'firstAuthorityLocality'
DESC 'Locality name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP l )
Examples: "Palm Springs", "Anna Maria Island"
2.1.55. 'firstAuthorityMobile'
The 'firstAuthorityMobile' attribute type allows for the assignment
of a mobile telephone number to a previous registration authoritative
entry.
The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.55
NAME 'firstAuthorityMobile'
DESC 'Mobile telephone number assigned to a
previous registration authority entry'
SINGLE-VALUE
SUP mobile )
Example: "+11234567890"
2.1.56. 'firstAuthorityOrg'
The 'firstAuthorityOrg' attribute type allows for the assignment
of an organization name to a previous registration authority entry.
The attribute type 'o', as defined in Section 2.19 of [RFC4519], is
a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.56
NAME 'firstAuthorityOrg'
DESC 'Organization name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP o )
Example: "Acme, Co."
2.1.57. 'firstAuthorityPOBox'
The 'firstAuthorityPOBox' attribute type allows for the assignment
of a post office box number to a previous registration authority
entry.
Coretta Expires January 24, 2022 [Page 28]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.57
NAME 'firstAuthorityPOBox'
DESC 'Post office box number assigned to a
previous registration authority entry'
SINGLE-VALUE
SUP postOfficeBox )
Examples: "555", "475"
2.1.58. '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.
( 1.3.6.1.4.1.56521.101.2.1.58
NAME 'firstAuthorityPostalAddress'
DESC 'Full postal address assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP postalAddress )
Example: "1 Fake St$Anytown$CA$12345$US"
2.1.59. '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.
( 1.3.6.1.4.1.56521.101.2.1.59
NAME 'firstAuthorityPostalCode'
DESC 'Postal code assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP postalCode )
Examples: "92262", "34216"
Coretta Expires January 24, 2022 [Page 29]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.60. '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.
( 1.3.6.1.4.1.56521.101.2.1.60
NAME 'firstAuthorityState'
DESC 'State or province name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP st )
Examples: "California", "North Dakota"
2.1.61. 'firstAuthorityStreet'
The 'firstAuthorityStreet' attribute type allows for the
assignment of a street name and number to a previous registration
authority entry.
The attribute type 'street', as defined in Section 2.34 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.61
NAME 'firstAuthorityStreet'
DESC 'Street name and number assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP street )
Example: "1 Fake Street"
2.1.62. 'firstAuthorityTelephone'
The 'firstAuthorityTelephone' attribute type allows for the
assignment of a telephone number to a previous registration
authority entry.
The attribute type 'telephoneNumber', as defined in Section 2.35 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.62
NAME 'firstAuthorityTelephone'
DESC 'Telephone number assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP telephoneNumber )
Coretta Expires January 24, 2022 [Page 30]
Internet-Draft X.660 LDAP Schema and Models July 2021
Example: "+11234567890"
2.1.63. 'firstAuthorityTitle'
The 'firstAuthorityTitle' attribute type allows for the assignment
of an official or professional title to a previous registration
authority entry.
The attribute type 'title', as defined in Section 2.38 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.63
NAME 'firstAuthorityTitle'
DESC 'Title assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP title )
Example: "Chief Engineer"
2.1.64. 'firstAuthorityURI'
The 'firstAuthorityURI' attribute type allows for the assignment
of one or more URI values, with optional labels, to a previous
registration authority entry.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.64
NAME 'firstAuthorityURI'
DESC 'URI, with an optional label, leading
to a resource related to a previous
registration authority'
SUP labeledURI )
Examples: "http://example.com Example", "http://example.com"
2.1.65. 'sponsor'
The 'sponsor' attribute type allows for the assignment of one or
more DN values to a registration.
The value(s) of this attribute type are meant to refer to distinct
entries that contains sponsorship-related information for a given
registration.
This attribute type is only required if such information is not
stored within a given registration directly.
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
Coretta Expires January 24, 2022 [Page 31]
Internet-Draft X.660 LDAP Schema and Models July 2021
( 1.3.6.1.4.1.56521.101.2.1.65
NAME 'sponsor'
DESC 'LDAP Distinguished Name of an entry
bearing sponsorship information'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,ou=X660,dc=example,dc=com"
2.1.66. '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.
( 1.3.6.1.4.1.56521.101.2.1.66
NAME 'sponsorStartTimestamp'
DESC 'Generalized timestamp indicating the date
and time sponsorship commenced'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example: "20130105135904Z"
2.1.67. 'sponsorEndTimestamp'
The 'sponsorEndTimestamp' 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, terminated.
( 1.3.6.1.4.1.56521.101.2.1.67
NAME 'sponsorEndTimestamp'
DESC 'Generalized timestamp indicating the date
and time sponsorship terminated'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example: "20170528110555Z"
2.1.68. 'sponsorCommonName'
The 'sponsorCommonName' attribute type allows for the assignment
of a common name to a sponsor entry.
The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.68
NAME 'sponsorCommonName'
DESC 'Common Name of a sponsor entry'
SINGLE-VALUE
SUP cn )
Coretta Expires January 24, 2022 [Page 32]
Internet-Draft X.660 LDAP Schema and Models July 2021
Example: "Jane Sponsor"
2.1.69. 'sponsorCountryCode'
The 'sponsorCountryCode' attribute type allows for the assignment of
a two-letter country code to a sponsor entry.
The attribute type 'c', as defined in Section 2.2 of [RFC4519], is a
super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.69
NAME 'sponsorCountryCode'
DESC 'Country code for a sponsor entry'
SINGLE-VALUE
SUP c )
Examples: "US", "CA"
2.1.70. 'sponsorCountryName'
The 'sponsorCountryName' attribute type allows the assignment of a
country name to a sponsor entry.
The attribute type 'co', as defined in Section 2.4 of [RFC4524], is a
super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.70
NAME 'sponsorCountryName'
DESC 'Country name for a sponsor entry'
SINGLE-VALUE
SUP co )
Examples: "United States", "Canada"
2.1.71. 'sponsorEmail'
The 'sponsorEmail' attribute type allows for the assignment of an
email address to a sponsor entry.
The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.71
NAME 'sponsorEmail'
DESC 'Email address for a sponsor entry'
SINGLE-VALUE
SUP mail )
Example: "sponsor@example.com"
Coretta Expires January 24, 2022 [Page 33]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.1.72. 'sponsorFax'
The 'sponsorFax' attribute type allows for the assignment of a
facsimile telephone number to a sponsor entry.
The attribute type 'facsimileTelephoneNumber', as defined in Section
2.10 of [RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.72
NAME 'sponsorFax'
DESC 'Facsimile telephone number for a sponsor entry'
SINGLE-VALUE
SUP facsimileTelephoneNumber )
Example: "+11234567890"
2.1.73. 'sponsorLocality'
The 'sponsorLocality' attribute type allows for the assignment
of a locality name to a sponsor entry.
The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.73
NAME 'sponsorLocality'
DESC 'Locality name for a sponsor entry'
SINGLE-VALUE
SUP l )
Examples: "Palm Springs", "Anna Maria Island"
2.1.74. 'sponsorMobile'
The 'sponsorMobile' attribute type allows for the assignment of
a mobile telephone number to a sponsor entry.
The attribute type 'mobile', as defined in Section 2.18 of
[RFC4524], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.74
NAME 'sponsorMobile'
DESC 'Mobile telephone number for a sponsor entry'
SINGLE-VALUE
SUP mobile )
Example: "+11234567890"
2.1.75. 'sponsorOrg'
The 'sponsorOrg' attribute type allows for the assignment of an
organization name to a sponsor entry.
Coretta Expires January 24, 2022 [Page 34]
Internet-Draft X.660 LDAP Schema and Models July 2021
The attribute type 'o', as defined in Section 2.19 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.75
NAME 'sponsorOrg'
DESC 'Organization name for a sponsor entry'
SINGLE-VALUE
SUP o )
Example: "Sponsor, Co."
2.1.76. 'sponsorPOBox'
The 'sponsorPOBox' attribute type allows for the assignment of a
post office box number to a sponsor entry.
The attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.76
NAME 'sponsorPOBox'
DESC 'Post office box number for a sponsor entry'
SINGLE-VALUE
SUP postOfficeBox )
Examples: "555", "475"
2.1.77. 'sponsorPostalAddress'
The 'sponsorPostalAddress' attribute type allows for the assignment
of a complete postal address sponsor 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.
( 1.3.6.1.4.1.56521.101.2.1.77
NAME 'sponsorPostalAddress'
DESC 'Full postal address for a sponsor entry'
SINGLE-VALUE
SUP postalAddress )
Example: "1 Fake St$Anytown$CA$12345$US"
2.1.78. 'sponsorPostalCode'
The 'sponsorPostalCode' attribute type allows for a postal code
to be assigned to a sponsor entry.
The attribute type 'postalCode', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
Coretta Expires January 24, 2022 [Page 35]
Internet-Draft X.660 LDAP Schema and Models July 2021
( 1.3.6.1.4.1.56521.101.2.1.78
NAME 'sponsorPostalCode'
DESC 'Postal code for a sponsor entry'
SINGLE-VALUE
SUP postalCode )
Example: "92262", "34216"
2.1.79. 'sponsorState'
The 'sponsorState' attribute type allows for the assignment of a
state or province name to a sponsor entry.
The attribute type 'st', as defined in Section 2.33 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.79
NAME 'sponsorState'
DESC 'State or province name for a sponsor entry'
SINGLE-VALUE
SUP st )
Examples: "California", "North Dakota"
2.1.80. 'sponsorStreet'
The 'sponsorStreet' attribute type allows for the assignment of a
street name and number to a sponsor entry.
The attribute type 'street', as defined in Section 2.34 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.80
NAME 'sponsorStreet'
DESC 'Street name and number for a sponsor entry'
SINGLE-VALUE
SUP street )
Example: "1 Fake Street"
2.1.81. 'sponsorTelephone'
The 'sponsorTelephone' attribute type allows for the assignment of
a telephone number to a sponsor entry.
The attribute type 'telephoneNumber', as defined in Section 2.35 of
[RFC4519], is a super type of this attribute type.
Coretta Expires January 24, 2022 [Page 36]
Internet-Draft X.660 LDAP Schema and Models July 2021
( 1.3.6.1.4.1.56521.101.2.1.81
NAME 'sponsorTelephone'
DESC 'Telephone number for a sponsor entry'
SINGLE-VALUE
SUP telephoneNumber )
Example: "+11234567890"
2.1.82. 'sponsorTitle'
The 'sponsorTitle' attribute type allows for the assignment of an
official or professional title to a sponsor entry.
The attribute type 'title', as defined in Section 2.38 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.82
NAME 'sponsorTitle'
DESC 'Title for a sponsor entry'
SINGLE-VALUE
SUP title )
Example: "Executive Sponsor"
2.1.83. 'sponsorURI'
The 'sponsorURI' attribute type allows for the assignment of one or
more URI values, each with an optional label, to a sponsor entry.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.83
NAME 'sponsorURI'
DESC 'URI, with an optional label, for a
sponsor entry'
SUP labeledURI )
Examples: "http://example.com Example", "http://example.com"
2.1.84. 'rARegistrationBase'
The 'rARegistrationBase' attribute type allows for the storage
of an LDAP DN meant to store the location of registration entries
within the DIT. Clients SHOULD expect entries of types x660RootArc
or x660SubArc exactly one (1) level below this DN.
This is primarily used in scenarios where it is desirable for an
application to self-configure for maximum efficiency in terms of
registration location, management and retrieval.
Coretta Expires January 24, 2022 [Page 37]
Internet-Draft X.660 LDAP Schema and Models July 2021
An ideal location for this attribute type is within the DSA's
RootDSE.
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.1.84
NAME 'rARegistrationBase'
DESC 'LDAP Distinguished Name of the root X.660
registration entry storage location in a DIT'
SUP distinguishedName )
Example: "ou=OID,ou=X660,dc=example,dc=com"
2.1.85. 'rARegistrantBase'
The 'rARegistrantBase' attribute type allows for the storage of
an LDAP DN referencing the location of registrant (contact) entries
within the DIT. Clients SHOULD expect entries bearing the object
class of 'x660Registrant' exactly one (1) level below this DN.
This is primarily used in scenarios where it is desirable for an
application to self-configure for maximum efficiency in terms of
registrant location, management and retrieval.
An ideal location for this attribute type is within the DSA's
RootDSE.
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.1.85
NAME 'rARegistrantBase'
DESC 'LDAP Distinguished Name of the root X.660
registrant entry storage location in a DIT'
SUP distinguishedName )
Example: "ou=Registrants,ou=X660,dc=example,dc=com"
2.1.86. 'rADirectoryModel'
The 'rADirectoryModel' attribute type allows for the storage of
of an object identifier meant to declare the structural design of
the DIT content pertaining to this specification.
This is primarily used in scenarios where it is desirable for an
application to self-configure for maximum efficiency in terms of
registration location and retrieval.
The supported values for this attribute type are as follows and
correspond to Sections 3.2 and 3.3 of this specification:
Coretta Expires January 24, 2022 [Page 38]
Internet-Draft X.660 LDAP Schema and Models July 2021
- 1.3.6.1.4.1.56521.101.3.2 (twoDimensional)
- 1.3.6.1.4.1.56521.101.3.3 (threeDimensional)
An ideal location for this attribute type is within the DSA's
RootDSE.
( 1.3.6.1.4.1.56521.101.2.1.86
NAME 'rADirectoryModel'
DESC 'Object Identifier meant to advertise
the directory model governing the storage
of X.660 LDAP entries within the DIT'
EQUALITY objectIdentifierMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Example: "1.3.6.1.4.1.56521.101.3.3"
2.1.87. 'rAServiceMail'
The 'rAServiceMail' attribute type allows for the OPTIONAL assignment
of one or more email addresses to an 'x660DUAConfig' entry for the
purpose of email-based allocation request handling, error reporting
or general support for end-users.
The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.87
NAME 'rAServiceMail'
DESC 'Email address used for RA-level
registration requests, inquiries or
problem reports'
SUP mail )
Example: "ra@example.com"
2.1.88. 'rAServiceURI'
The 'rAServiceURI' attribute type allows for the OPTIONAL assignment
of one or more URI values to an 'x660DUAConfig' entry for the purpose
of directing users to appropriate RA endpoint for request handling.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.88
NAME 'rAServiceURI'
DESC 'URI, with an optional label, defining
an appropriate RA endpoint'
SUP labeledURI )
Example: "http://example.com/ra.html Registrations"
Coretta Expires January 24, 2022 [Page 39]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.2. Object Classes
The following subsections describes LDAP object classes made
available by this specification.
2.2.1. 'x660RootArc'
The 'x660RootArc' class is meant to define a maximum of three (3)
root registrations within a DIT, per Rec. ITU-T X.660 (ISO/IEC
9834-1).
( 1.3.6.1.4.1.56521.101.2.2.1
NAME 'x660RootArc'
DESC 'Top-level class for entries meant to represent
ITU-T, ISO or Joint-ISO-ITU-T root arcs as defined
in Section A.2 of the X.660 specification'
SUP top STRUCTURAL
MUST ( n $ unicodeValue $ identifier )
MAY ( registrationInformation $ additionalIdentifier $
asn1Notation $ iRI $ currentAuthority $ subArc $
stdNameForm $ description $ registrationURI $
registrationCreated $ registrationModified $
leftArc $ rightArc $ nameAndNumberForm $
firstAuthority ) )
2.2.2. 'x660SubArc'
The 'x660SubArc' object class makes a collection of attribute
types available for use when crafting subordinate registrations
within a DIT.
( 1.3.6.1.4.1.56521.101.2.2.2
NAME 'x660SubArc'
DESC 'A generalized class meant to represent sub arcs
beneath any root, as defined in X.660 Sections A.3-A.5'
SUP top STRUCTURAL
MUST ( n )
MAY ( nameAndNumberForm $ firstAuthority $ finalArc $
currentAuthority $ supArc $ subArc $ firstArc $
topArc $ description $ registrationURI $ iRI $
isFrozen $ discloseTo $ sponsor $ isLeafNode $
leftArc $ rightArc $ registrationInformation $
additionalIdentifier $ registrationCreated $
unicodeValue $ longArc $ registrationRange $
registrationModified $ registrationStatus $
identifier $ stdNameForm $ asn1Notation $
dotNotation ) )
Coretta Expires January 24, 2022 [Page 40]
Internet-Draft X.660 LDAP Schema and Models July 2021
2.2.3. 'x660Registrant'
The 'x660Registrant' object class allows for current, previous
(first) and/or sponsorship data to be stored within an entry.
( 1.3.6.1.4.1.56521.101.2.2.3
NAME 'x660Registrant'
DESC 'A generalized auxiliary class for
registrant contact information'
SUP top AUXILIARY
MAY ( currentAuthorityURI $ sponsorCommonName $ sponsorOrg $
firstAuthorityPOBox $ sponsorPOBox $ sponsorLocality $
sponsorCountryCode $ firstAuthorityURI $ description $
firstAuthorityStartTimestamp $ sponsorStartTimestamp $
firstAuthorityFax $ sponsorCountryName $ sponsorURI $
sponsorTelephone $ currentAuthorityOrg $ sponsorFax $
currentAuthorityCommonName $ firstAuthorityMobile $
currentAuthorityTitle $ firstAuthorityCountryCode $
currentAuthorityPostalAddress $ firstAuthorityOrg $
currentAuthorityFax $ firstAuthorityPostalAddress $
currentAuthorityCountryCode $ firstAuthorityState $
currentAuthorityCountryName $ firstAuthorityEmail $
currentAuthorityMobile $ firstAuthorityCommonName $
firstAuthorityCountryName $ currentAuthorityState $
currentAuthorityPostalCode $ firstAuthorityStreet $
currentAuthorityTelephone $ currentAuthorityEmail $
currentAuthorityLocality $ firstAuthorityLocality $
currentAuthorityStreet $ firstAuthorityPostalCode $
firstAuthorityTitle $ registrantID $ sponsorEmail $
firstAuthorityEndTimestamp $ sponsorEndTimestamp $
firstAuthorityTelephone $ currentAuthorityPOBox $
currentAuthorityStartTimestamp $ sponsorTitle $
sponsorStreet $ sponsorMobile $ sponsorState $
sponsorPostalCode $ sponsorPostalAddress ) )
2.2.4. 'x660DUAConfig'
The 'x660DUAConfig' object class allows for the storage of so-called
auto-configuration attribute types meant to guide various DUAs in
their attempt to access registration and/or registrant information
contained within the DIT hosted by the RA DSA. See Section 3.5 for
details.
( 1.3.6.1.4.1.56521.101.2.2.4
NAME 'x660DUAConfig'
DESC 'Entry class to facilitate advertisement
of optimal X.660 DUA configuration values'
SUP top AUXILIARY
MAY ( rADirectoryModel $ rARegistrantBase $
rAServiceMail $ rAServiceURI $
rARegistrationBase ) )
Coretta Expires January 24, 2022 [Page 41]
Internet-Draft X.660 LDAP Schema and Models July 2021
3. Directory Models and Procedures
This section offers two (2) distinct models, and some procedures, by
which both directory architects and application developers SHOULD be
guided in efforts to implement this specification.
Note that in various examples shown, some DNs are particularly long
and are line-wrapped and indented for readability.
3.1. Naming Context and Organization Entries
In these examples, a naming context of "ou=X660, dc=example, dc=com"
is used as the "suffix". Within this suffix are two (2) entries:
- "ou=OID, ou=X660, dc=example, dc=com" - Storage of all
registration entries (e.g.: 'rARegistrationBase')
- "ou=Registrants, ou=X660, dc=example, dc=com" - Storage
of all registrant (authority/sponsorship) entries (e.g.:
'rARegistrantBase')
Directory architects MAY choose to use models of their own design, so
long as noted requirements in the following sections are satisfied.
3.2. Two-Dimensional Model
This model suggests that registrations reside as siblings within an
LDAP DIT in singular, non-hierarchical locations.
This model is RECOMMENDED for small and/or sparse implementations.
The three-dimensional model (See Section 3.3) may be more appropriate
for larger, more robust implementations.
Use of this model is entirely at the discretion of the directory
architect(s) involved. It should be noted that if users will be
managing OID data directly through use of standard LDAP TUI or GUI
applications, this model would seem to be more convenient as opposed
to the three-dimensional model.
A DSA can advertise the use of this structural model using the
following attribute type and value in a location that is easily
discovered by clients (e.g.: the RootDSE [RFC4512]):
rADirectoryModel: 1.3.6.1.4.1.56521.101.3.2
3.2.1. Requirements
One requirement of this model is strict use of the 'dotNotation'
attribute type, covered in Section 2.1.2. This attribute MUST be
used on all non-root registrations.
Coretta Expires January 24, 2022 [Page 42]
Internet-Draft X.660 LDAP Schema and Models July 2021
Root registrations SHALL NOT bear an 'dotNotation' value, as the
syntax for OIDs (see Section 3.3.26 of [RFC4517]) requires at least
two (2) arcs in a given value.
Uniqueness of 'dotNotation' values within a directory structure
MUST always be enforced to ensure unambiguous results. The simplest
way to meet this requirement would be to adopt a DN structure based
on this attribute type, as shown in Section 3.2.2.
3.2.2. Distinguished Name Convention
Because all LDAP Search Requests [RFC4511] can be conducted using a
scope of singleLevel (per Section 4.5.1.2 of [RFC 4511]) below the
necessary directory branch, a DN structure of hierarchical nature is
wholly unnecessary. While the three-dimensional model (as shown in
Section 3.3) uses the integer-based 'n' attribute type (per Section
2.1.1) to form the effective LDAP RDN of an entry, this would not be
practical in this model.
The most sensible convention for DN involves use of the attribute
type 'dotNotation' as shown:
dn: dotNotation=1.3,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 3
unicodeValue: Identified-Organization
dotNotation: 1.3
Subsequent entries, regardless of their true [X.660] hierarchical
placement, manifest as sibling directory entries. For example, the
addition of "deeper" arcs would be procedurally identical:
dn: dotNotation=1.3.6.1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 1
identifier: internet
dotNotation: 1.3.6.1
3.2.3. Root Arc Entries
A maximum of three (3) root arcs MAY exist within the directory
landscape. If one or more are created, they SHOULD be identifiable
as follows:
- ITU-T (0)
- ISO (1)
- Joint-ISO-ITU-T (2)
As sibling entries, these root arcs MUST use the 'x660RootArc'
class, as shown in Section 2.2.1:
Coretta Expires January 24, 2022 [Page 43]
Internet-Draft X.660 LDAP Schema and Models July 2021
dn: n=0,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 0
unicodeValue: ITU-T
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 1
unicodeValue: ISO
dn: n=2,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 2
unicodeValue: Joint-ISO-ITU-T
Using root registrations is only useful in the two-dimensional model
if the administrator wishes to organize lists of OIDs beneath their
respective roots. This is likely unnecessary in implementations that
are small and sparse. In larger implementations, however, this model
may be convenient in situations where DIT content segmentation is in
effect.
3.3. Three-Dimensional Model
This model is hierarchical by nature, providing a means for storing
registrations in nested fashion, thereby reflecting the hierarchical
logic of the [X.660] specification itself.
This model is RECOMMENDED for thorough or complete implementations,
or implementations in which custom solutions (applications) have been
tailored for this purpose. This model may be prohibitively tedious
in sparse and/or small implementations.
Use of this model is entirely at the discretion of the directory
architect(s) involved. It should be noted that end-users that will
directly access or manage this data through standard LDAP TUI or GUI
applications alone may find this model tedious, and may prefer the
two-dimensional model as described in Section 3.2.
A DSA can advertise the use of this structural model using the
following attribute type and value in a location that is easily
discovered by clients (e.g.: the RootDSE [RFC4512]):
rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3
3.3.1. Requirements
In this model, interim arcs MUST exist even if they are otherwise
unnecessary.
Coretta Expires January 24, 2022 [Page 44]
Internet-Draft X.660 LDAP Schema and Models July 2021
For example, in order to add the well-known "internet" OID (1.3.6.1),
directory administrators MUST ensure the following registrations
exist beforehand:
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 1
identifier: iso
unicodeValue: ISO
dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 3
identifier: identified-organization
unicodeValue: Identified-Organization
dn: n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 6
identifier: dod
Only once this requirement is satisfied would the administrators
be able to create the desired registration, such as a registration
entry for the "internet" OID, as shown in [RFC1155]:
dn: n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 1
identifier: internet
3.3.2. Distinguished Name Convention
Under a strict interpretation of this model, its implementation
will provide a means for bidirectional resolution of registered
OIDs. LDAP DNs can be deduced from OIDs, and vice versa.
This is achieved by using the 'n' attribute type (as defined in
Section 2.1.1) as components in the effective LDAP DN, but in
reverse order to reflect the directory hierarchy.
For example: the "internet" OID would exist as an entry with a
DN as depicted below:
1.3.6.1
----------------
| | | |
dn: n=1, n=6, n=3, n=1, ou=OID, ou=X660, dc=example, dc=com
Coretta Expires January 24, 2022 [Page 45]
Internet-Draft X.660 LDAP Schema and Models July 2021
As a result, use of the 'dotNotation' attribute type becomes
unnecessary unless users wish to search for an OID using an LDAP
search filter.
3.3.3. Root Arc Entries
A maximum of three (3) root arcs SHOULD exist within the directory
landscape. If one or more are created, they MUST be identifiable
as follows:
- ITU-T (0)
- ISO (1)
- Joint-ISO-ITU-T (2)
As sibling entries, these root arcs MUST use the 'x660RootArc'
class, as shown in Section 2.2.1:
dn: n=0,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 0
unicodeValue: ITU-T
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 1
unicodeValue: ISO
dn: n=2,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 2
unicodeValue: Joint-ISO-ITU-T
Depending on the breadth and scope of an implementation, creation and
use of root registrations is RECOMMENDED, but not required for every
situation.
3.3.3.1. Lack of Root Arc Entries
In situations where a three-dimensional model is used, but only
contains a subset of subordinate registrations, root registrations
may not be necessary.
Instead, directories architects MAY choose to create a subordinate
registration as a false root, and store the relevant contents there.
For example, if a directory architect only wanted to store IANA
PEN registrations that are allocated below the OID 1.3.6.1.4.1,
the relevant DIT entries could manifest as follows:
Coretta Expires January 24, 2022 [Page 46]
Internet-Draft X.660 LDAP Schema and Models July 2021
dn: dotNotation=1.3.6.1.4.1,ou=OID,ou=X660,dc=example,
dc=com
objectClass: top
objectClass: x660SubArc
identifier: enterprise
additionalIdentifier: enterprises
registrationURI: https://www.iana.org/assignments/enterprise
-numbers
dn: n=56521,dotNotation=1.3.6.1.4.1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: top
objectClass: x660SubArc
... other sibling PEN entries ...
Alternatively, if the above non-standard DN syntax is undesirable,
directory architects MAY choose to honor the three-dimensional model
DN syntax, but limit creation of new entries to those that are direct
ancestors of the intended subset. In this situation use of a root
registration is necessary, but only relevant entries would need to be
created.
Keeping with the above scenario, the relevant DIT entries could
manifest as follows:
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArc
n: 1
unicodeValue: ISO
dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 3
unicodeValue: Identified-Organization
dn: n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 6
identifier: dod
dn: n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 1
identifier: internet
Coretta Expires January 24, 2022 [Page 47]
Internet-Draft X.660 LDAP Schema and Models July 2021
dn: n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 4
identifier: private
dn: n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArc
n: 1
identifier: enterprise
additionalIdentifier: enterprises
registrationURI: https://www.iana.org/assignments/enterprise
-numbers
dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,
dc=com
n: 56521
objectClass: top
objectClass: x660SubArc
... other sibling PEN entries ...
3.4. Registrant Information
Directory architects MAY choose to store registrant information in
one of two main ways:
- Store sponsor or authority registrant information within
registration entries themselves, or ...
- Store sponsor and/or authority registrant information within
dedicated entries, and reference the DNs of these entries
via the 'currentAuthority', 'sponsor' and/or 'firstAuthority'
attribute types assigned to registrations
The nature of these contacts will typically encompass three (3)
kinds of entities:
- An individual
- An organization, institution or working group
- A document (e.g.: a standard or draft)
3.4.1. Use of Collective or Virtual Attributes
In situations involving particularly large and/or distributed LDAP
DIT contexts, directory architects MAY choose to extend certain
attribute types within this specification to allow for Collective
Attributes [RFC3671] support, or some other proprietary feature for
the facilitation of so-called "virtual attributes" to allow for a
broad-scale and low-cost association of attribute values across
entire pools of entries.
Coretta Expires January 24, 2022 [Page 48]
Internet-Draft X.660 LDAP Schema and Models July 2021
While these concepts are out of scope for this specification, a few
attribute types defined in Section 2 MAY be used in situations that
involve one or more specific registrants being assigned to a very
large number of registrations, or an entire subtree in perpetuity:
- 'currentAuthority', defined in Section 2.1.28
- 'firstAuthority', defined in Section 2.1.46
- 'sponsor', defined in Section 2.1.65
3.4.2. Examples
3.4.2.1. Combined Registration and Registrant Entries
This is a basic two-dimensional example entry comprised of both
registration and registrant attribute types.
dn: dotNotation=1.3.6.1.4.1.56521,n=1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: x660SubArc
objectClass: x660Registrant
objectClass: top
currentAuthorityPostalAddress: 1 Fake St$Anywhere$CA$92262
currentAuthorityCommonName: Jesse Coretta
currentAuthorityEmail: jesse.coretta@example.com
currentAuthorityMobile: +11234567890
dotNotation: 1.3.6.1.4.1.56521
n: 56521
This is a basic three-dimensional example entry of the same design.
dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: x660SubArc
objectClass: x660Registrant
objectClass: top
currentAuthorityPostalAddress: 1 Fake St$Anywhere$CA$92262
currentAuthorityCommonName: Jesse Coretta
currentAuthorityEmail: jesse.coretta@example.com
currentAuthorityMobile: +11234567890
n: 56521
3.4.2.2. Dedicated Registrant Entries
This is a basic example of a single authority-based contact entry.
Please note that use of the 'organizationalRole' object class (per
Section 3.10 of [RFC4519]) is purely incidental here. Directory
architects MAY opt for another STRUCTURAL object class.
Coretta Expires January 24, 2022 [Page 49]
Internet-Draft X.660 LDAP Schema and Models July 2021
dn: registrantID=draft-coretta-x660-ldap,ou=Registrants,
ou=X660,dc=example,dc=com
registrantID: draft-coretta-x660-ldap
cn: draft-coretta-x660-ldap
objectClass: organizationalRole
objectClass: x660Registrant
objectClass: top
currentAuthorityPostalAddress: 1 Fake St$Palm Springs$
CA$92262
currentAuthorityCommonName: Jesse Coretta
currentAuthorityEmail: jesse.coretta@icloud.com
currentAuthorityMobile: +11234567890
currentAuthorityStartTimestamp: 20200229134901Z
In cases where multiple distinct individuals or addresses are used,
they can all be combined into a single entry:
dn: registrantID=draft-coretta-x660-ldap,ou=Registrants,
ou=X660,dc=example,dc=com
registrantID: draft-coretta-x660-ldap
cn: draft-coretta-x660-ldap
objectClass: organizationalRole
objectClass: x660Registrant
objectClass: top
currentAuthorityPostalAddress: 1 Fake St$Palm Springs$
CA$92262
currentAuthorityCommonName: Jesse Coretta
currentAuthorityEmail: jesse.coretta@icloud.com
currentAuthorityMobile: +11234567890
currentAuthorityStartTimestamp: 20200229134901Z
sponsorOrg: Sponsor, Co.
sponsorEmail: sponsor@example.com
sponsorMobile: +11234560987
sponsorStartTimestamp: 20010104120144Z
sponsorPostalAddress: 456 Fugazzi Ln$Anywhere$CA$92262
firstAuthorityPostalAddress: 1 Fake St$Palm Springs$
CA$92262
firstAuthorityCommonName: Jesse Coretta
firstAuthorityEmail: jesse.coretta@icloud.com
firstAuthorityMobile: +11234567890
firstAuthorityStartTimestamp: 20200229134901Z
Keeping with the example registration described in Section 3.4.2.2,
the three-dimensional registration would manifest as follows:
dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: x660SubArc
objectClass: top
currentAuthority: registrantID=draft-coretta-x660-ldap,
ou=Registrants,ou=X660,dc=example,dc=com
n: 56521
Coretta Expires January 24, 2022 [Page 50]
Internet-Draft X.660 LDAP Schema and Models July 2021
3.5. DUA Configuration
Two (2) distinct methods for client-side configuration are shown
in this section. Users and directory architects alike MAY opt
for one over the other, depending on the situation.
Regardless of the style of configuration, DUA observance of the
following constants is strongly RECOMMENDED when leveraging this
specification in the manner intended:
- An effective registration search base MUST be made available
- The condition of a missing or undefined registrant search base
MUST indicate that NO authority or sponsorship information is
stored or advertised
- The condition of a registration search base that is equal to
the registrant search base MUST indicate the use of so-called
Combined Registration and Registrant entries
- The condition of a registration search base that is not equal
to the registrant search base MUST indicate the use of so-called
Dedicated Registrant entries
3.5.1. Manual Configuration
Manual configuration MAY be used if:
- Advertisement of configuration information, as shown in Section
3.5.2, is unavailable, or ...
- The information advertised is somehow unreliable, or ...
- The DUA is not optimized for this specification
Assuming one of the above applies, the following conceptual runtime
settings are sufficient for basic interaction with the DSA acting as
an RA:
- Directory model object identifier (see Sections 3.2 and 3.3)
- Distinguished name(s) used for registration and registrant
LDAP search bases
3.5.2. Automatic Configuration
Any DUA optimized or designed with this specification in mind SHOULD
support the automatic retrieval of the following attribute types:
- 'rARegistrationBase', as defined in Section 2.1.84
- 'rARegistrantBase', as defined in Section 2.1.85
- 'rADirectoryModel', as defined in Section 2.1.86
- 'rAServiceMail', as defined in Section 2.1.87
- 'rAServiceURI', as defined in Section 2.1.88
Coretta Expires January 24, 2022 [Page 51]
Internet-Draft X.660 LDAP Schema and Models July 2021
Limitations pertaining to the artificial addition of attributes to
the RootDSE are implementation-specific, and thus the DUA SHOULD
allow manual configuration, as shown in Section 3.5.1, as a fallback
measure.
There are two techniques a DUA MAY use to locate the above attribute
types:
- Check the RootDSE advertised by the DSA(s)
- If a RootDSE check fails, fallback to a broad-level search
for a single LDAP entry bearing the 'x660DUAConfig' object
class, as shown in Section 2.2.4
3.5.2.1. Examples
This subsection shows examples for storing values assigned to the
attribute types mentioned in Section 3.5.2. Note these may not
be complete and legal LDAP entries, as their full contents may be
omitted for brevity.
RootDSE alterations may manifest as follows for an RA storing a
three-dimensional [X.660] DIT structure with dedicated registrant
entries:
dn:
objectClass: x660DUAConfig
rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3
rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com
rARegistrantBase: ou=Registrants,ou=X660,dc=example,dc=com
Alternatively, for an RA storing a two-dimensional [X.660] DIT
structure with combined registration and registrant entries:
dn:
objectClass: x660DUAConfig
rADirectoryModel: 1.3.6.1.4.1.56521.101.3.2
rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com
rARegistrantBase: ou=OID,ou=X660,dc=example,dc=com
If use of the RootDSE is not feasible for storing this information,
but automatic configuration is still desired, directory architects
MAY opt to store entries similar to those above within another DIT,
however the drawback to this approach is that the DUA (or its user)
would require foreknowledge of the relevant suffix.
dn: dc=example,dc=com
objectClass: x660DUAConfig
rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3
rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com
rARegistrantBase: ou=Registrants,ou=X660,dc=example,dc=com
Coretta Expires January 24, 2022 [Page 52]
Internet-Draft X.660 LDAP Schema and Models July 2021
Depending on the nature of the RA service indicated, the creation
or modification of registrations MAY require approval before such
changes can be committed to the directory. As such, a directory
architect MAY opt to advertise an appropriate email address and/or
URI as shown below.
DUAs or services optimized for this specification may be required to
alter their behavior as it relates to write operations against the
RA DSA if the 'rAServiceMail' and/or 'rAServiceURI' attribute
types are present:
dn:
objectClass: x660DUAConfig
rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3
rAServiceMail: ra@example.com
rAServiceURI: https://www.example.com/ra.html
rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com
rARegistrantBase: ou=Registrants,ou=X660,dc=example,dc=com
3.6. Spatial Orientation and Navigation
Some of the more complete RA services, whether public or private,
may offer a simple interface to facilitate intuitive contiguous
movement between logically adjacent registrations in terms of "up",
"down", "left" and "right"
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.
The main concerns on this topic are summarized as follows:
- DSA resource utilization
- DIT content model, complexity and footprint
The functionality discussed in this subsection is NOT officially
defined in [X.660], but is present in this specification so as to
mitigate or overcome certain challenges associated with the use of
directory services in this context.
3.6.1. Client Capabilities
In terms of this specification, a client will be most effective
when its implementer, or developer, takes care to understand the
nature of the DSA(s) it may use, as well as the DIT(s) in question.
Assuming a sound configuration is in place, per Section 3.5, a given
client needs to determine a means for the following actions by OID
alone:
- Locating individual registrations
- Traversing surrounding registrations (spatially)
Coretta Expires January 24, 2022 [Page 53]
Internet-Draft X.660 LDAP Schema and Models July 2021
3.6.1.1. Locating Individual Registrations
In sufficiently thorough three-dimensional implementations of this
specification, it is not uncommon to see an absence of literal
'dotNotation' values for registrations. The reason for this, as
shown in Section 3.3.2, is that the DN syntax alone is sufficient for
the "storage" of an OID. The drawback, however, is that the client
is now required to perform the following abstract actions to locate
(or extrapolate) an OID to an entry:
- Reverse OID (1.3.6 becomes 6.3.1)
- Transmute reversed OID to a partial RDN sequence using
the 'n' attribute type (n=6,n=3,n=1)
- Combine the appropriate registration suffix DN and RDNs
(n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com)
Procedurally, this is a simple operation and is beneficial when an
application is dealing with a particularly busy DSA, as a baseObject
LDAP Search Request (per Section 4.5.1.2 of [RFC4511]) will always
return either one (1) or zero (0) results. This would result in
lower DSA utilization overall when compared to broad search request
for a 'dotNotation' value, but because the composed DN is "inferred",
subsequent requests come with the risk of a 'noSuchObject (32)' error
being returned (per Appendix A, Section 2 of [RFC4511]) should the
entry not exist at said specified DN.
However, in two-dimensional implementations of this specification,
as shown in Section 3.2.2, a literal 'dotNotation' value exists which
the client can query one of two ways:
- If 'dotNotation' is used as a component in the relevant
DN syntax, call the extrapolated DN, or ...
- Perform broad filter-based searches for the desired OID
as a literal 'dotNotation' (e.g.: '(dotNotation=<oid>)')
The former option requires extra effort on part of the client, while
the latter option will require more DSA resources, and would require
the attribute type be populated for the given registration.
3.6.1.2. Traversing Adjacent or Ancestral Registrations
OIDs exist in lexically hierarchical relation to one another, and
with no absolutely no limits imposed on overall OID "depth" nor on
the magnitude of any single NumberForm [X.680] component (so long
as the magnitude is zero (0) or more).
An effective client intended for use in situations involving this
specification SHOULD have the capability to locate all applicable
adjacent entries without extraordinary effort. The subsections that
follow will cover attribute types and procedures to that end.
Coretta Expires January 24, 2022 [Page 54]
Internet-Draft X.660 LDAP Schema and Models July 2021
3.6.1.2.1. Use of the 'supArc' and 'topArc' Attribute Types
The 'supArc' and 'topArc' attribute types are used to describe the
vertical relationships between registrations in an ancestral sense.
One need only perform a baseObject LDAP Search Request (per Section
4.5.1.2 of [RFC4511]) upon the referenced DN to obtain the superior
entry in question.
If a registration possesses a DN value for the 'supArc' attribute
type, the DN MUST belong to the registration that is the immediate
superior (parent).
Similarly, if a registration possesses a DN value for the 'topArc'
attribute type, this DN MUST belong to the absolute root registration
entry within the directory. In this case, the registration entry
MUST ONLY be one (1) of itu-t(0), iso(1) or joint-iso-itu-t(2).
A directory architect MAY choose to leverage either of these types
virtually, depending on the situation. For example, if a certain
registration possesses tens of thousands of subordinate registration
entries, it may be prudent to assign the 'topArc' and/or 'supArc'
attribute types to those registrations through the use of Collective
Attribute [RFC3671] support, or some other proprietary means for the
assignment of virtual values to a vast number of entries. Both of
these concepts are out of scope for this document.
If a registration does not possess a value for either of the above
attribute types, this is indicative of one of these conditions:
- Registration is an 'x660RootArc'-based entry, and thus no
such superior registrations could ever possibly exist, or ...
- The DSA in question is intended only to host a subset of the
OID spectrum, and any superior references would violate such
constraints, or ...
- Client is expected to extrapolate the appropriate superior
registration using its own means
Assuming the client is expected to extrapolate the logically superior
registration, this can be handled in one of two ways:
- If a three-dimensional directory model is indicated, and the DN
syntax described in Section 3.3.2 is in use, the client should
attempt to truncate the leaf-node RDN to achieve its superior
(parent) DN, or ...
- If a two-dimensional directory model is indicated, and the DN
syntax described in Section 3.2.2 is in use, the client should
attempt to read the literal 'dotNotation' value from the entry
DN, truncate the value's leaf-node (right-hand) OID component,
and utilize the remaining contents for the basis of subsequent
entry location
Coretta Expires January 24, 2022 [Page 55]
Internet-Draft X.660 LDAP Schema and Models July 2021
In the former (three-dimensional) case, consider the following
example, in which the leaf-node (n=6) is truncated to obtain the
DN of the superior registration:
- n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
- n=3,n=1,ou=OID,ou=X660,dc=example,dc=com (parent)
In the latter (two-dimensional) case, consider the following example,
in which the 'dotNotation' RDN value is truncated to extrapolate the
DN of the superior registration:
- dotNotation=1.3.6,ou=OID,ou=X660,dc=example,dc=com
- dotNotation=1.3,ou=OID,ou=X660,dc=example,dc=com
3.6.1.2.2. Use of the 'subArc' Type
The 'subArc' attribute type is intended to hold one (1) or more LDAP
DNs for the purpose of enumerating all subordinate registrations that
reside beneath a given registration, or to reference the (lexically)
first subordinate registration only.
If a registration does not possess a value for 'subArc', this is
indicative of one of the following conditions:
- No subordinate registration manifest exists, and management
of such elements is wholly up to the client, or ...
- No subordinate registrations exist at this time, or ...
- Subordinate registrations exist, but are not visible to
the indicated identity (e.g.: access control)
If only a single 'subArc' value exists for the registration, this can
mean one of the following:
- There are a very large number of subordinate registrations,
and only the first registration is referenced, or ...
- There is only one (1) subordinate registration
dn: n=999,n=2,ou=OID,ou=X660,dc=example,dc=com
objectClass: x660SubArc
identifier: example
subArc: n=0,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com
If two (2) or more 'subArc' values exist for the registration, this
SHOULD be interpreted as a complete manifest of subordinate entries.
As such, costly enumeration of registrations (through a singleLevel
LDAP Search Request, per Section 4.5.1.2 of [RFC4511]) should not be
necessary.
Coretta Expires January 24, 2022 [Page 56]
Internet-Draft X.660 LDAP Schema and Models July 2021
dn: n=999,n=2,ou=OID,ou=X660,dc=example,dc=com
objectClass: x660SubArc
identifier: example
subArc: n=0,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com
subArc: n=1,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com
... many DNs omitted for brevity ...
subArc: n=200,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com
If the given 'subArc' manifest is perceived to be exceedingly large,
and DSA utilization and/or performance are concerns, it is strongly
RECOMMENDED the client application support the use of a local cache
to prevent repeated and wasteful calls of certain large entries.
This concept is out of scope for this document.
3.6.1.2.2.1. Awareness of Subordinate Registration Constraints
Any DUA or service interacting with RAs based upon this specification
for the purpose of enumerating and/or allocating registrations MUST
always check for the presence of definitions of both the 'isLeafNode'
attribute type (per Section 2.1.14) and the 'isFrozen' attribute type
(per Section 2.1.15) before any further subordinate traversals or
allocations may take place beneath a given registration.
If an 'isLeafNode' value of "TRUE" is present for a registration, the
requesting entity SHALL NOT enumerate any subordinate entries for any
reason, nor will any new subordinate allocations take place.
If an 'isFrozen' value of "TRUE" is present for a given registration,
but 'isLeafNode' is "FALSE" or otherwise UNDEFINED, the requesting
entity SHOULD enumerate any subordinate entries already present, but
SHALL NOT create any new registrations.
A value of "TRUE" for 'isLeafNode' attribute type SHALL ALWAYS imply
an equal value for 'isFrozen'.
Neither of these attribute types are meant for use in access control
contexts. Instead, see the 'registrationStatus' attribute type (per
Section 2.1.13), as well as the associated remarks in Section 5, for
information on security-specific restrictions relating to subordinate
registration access and privileges.
3.6.1.2.3. Use of Sibling Adjacency Attribute Types
Within the confines of this specification, sibling registration
adjacency can be depicted as follows:
Coretta Expires January 24, 2022 [Page 57]
Internet-Draft X.660 LDAP Schema and Models July 2021
current registration
(2.999.140)
|
<< antecedent/left V subsequent/right >>
+---+--------+---+---+---+--------+---+
| 0 |........|139|140|141|........|200|
+---+--------+---+---+---+--------+---+
| \ / |
farthest nearest farthest
In order to effectively express such horizontal relationships in a
logical hierarchical data structure, and to foster a low-cost means
for ascertaining these relationships, four (4) DN-based attribute
types are made available:
- 'leftArc', as defined in Section 2.1.22
- 'firstArc', as defined in Section 2.1.23
- 'rightArc', as defined in Section 2.1.24
- 'finalArc', as defined in Section 2.1.25
The 'leftArc' and 'rightArc' attribute types are assigned to entries
in a manual fashion, as the relationships are globally unique in that
no single registration will share the same "left" and "right" sibling
combination as any other registration. As such, the nature of these
two (2) attribute types precludes use of virtual value assignments.
The 'firstArc' and 'finalArc' attribute types MAY be assigned in one
(1) of the following three (3) ways:
- In literal fashion (manually), or ...
- Through the use of Collective Attribute [RFC3671] support, or ...
- Through the use of an implementation-specific attribute value
virtualization feature
Any given sibling registration pool, regardless of its size, will
always share the same 'firstArc' and 'finalArc' attribute values for
every registration contained therein. As such, Directory architects
MAY opt to leverage or otherwise extend these attribute types for
virtualization purposes, a topic out of scope for this document.
If these four (4) attribute types are not defined for a registration,
use of an ordered 'subArc' manifest derived from the registration's
parent, OR a (costly) singleLevel search (per Section 4.5.1.2 of
[RFC4511]) below the superior (parent) registration, are the only
other feasible ways to ascertain sibling adjacency. For more details
on this topic, see Section 3.6.1.2.2.
Another practical use for these attribute types is in case a finite
'registrationRange' value exists in a range of non-contiguous sibling
entries. Use of these attribute types may negate the need for costly
range "size checks". See Section 2.1.12 for more details.
Coretta Expires January 24, 2022 [Page 58]
Internet-Draft X.660 LDAP Schema and Models July 2021
In cases where a collection of sibling entries is prone to continued
growth, directory architects are advised to maintain the effective
'finalArc' value(s) regularly, if defined at all. Such growth will
continue in right-handed (subsequent) fashion, and thus the so-called
"final registration" will shift after a time, rendering a stale value
inaccurate in nature.
3.7. DSA Resource Utilization and Administrative Costs
Much of the previous subsection advocated the use of low-cost client
driven methods for finding and circumnavigating registrations using
only baseObject-scoped LDAP Search Requests (per Section 4.5.1.2 of
[RFC4511]). This section offers some considerations relating to the
DSA's relation to these concepts.
Directory architects who choose to adopt some or all of the precepts
defined in this specification will inevitably encounter a situation
in which they're forced to consider one or more of the following:
- Overall size of DIT is a concern (in terms of bytes
and/or entries)
- Effort required to maintain DIT content for all adopted
attribute types is not feasible
- Client-driven resource utilization is problematic
The following subsections covers these concerns from a variety of
standpoints.
3.7.1. Literal vs. Composite Values
Consider the following scenario:
A directory architect adopts certain elements from this specification
in minimalistic three-dimensional fashion. In this case, only the
'n', 'unicodeValue' and 'identifier' attribute types are maintained
for any given registration. This is due to the prohibitively costly
and/or time-consuming nature of maintaining any other attributes.
A user consuming this information wants to obtain 'iRI' as well as
'asn1Notation' values for any given registration. Because these
attribute types are not maintained in literal fashion, this forces
the user to traverse the directory through multiple individual LDAP
baseObject Search Requests (per Section 4.5.1.2 of [RFC4511]), so as
to derive the needed component values.
The drawbacks of this strategy are as follows:
- Tedious for the user
- Increased number of requests to DSA
- Extrapolation or prediction of composite values
is not always possible
Coretta Expires January 24, 2022 [Page 59]
Internet-Draft X.660 LDAP Schema and Models July 2021
The merits of this strategy are as follows:
- Smaller data footprint
- Lower overall data maintenance costs
There are several attributes that, in some form or another, contain
data that MAY reside in another attribute assigned to the same entry.
- 'identifier' (a.k.a.: 'nameForm') and 'n' (a.k.a.: 'numberForm')
are the sole components of 'nameAndNumberForm'
- 'nameAndNumberForm' is (often) the iterative component of the
'asn1Notation' type, with outer "curly brace encapsulation"
(e.g.: "{...}")
- 'unicodeValue' and 'n' are (often) the components of 'iRI', using
a solidus (/) prefix and delimitation scheme
- 'n' is the iterative component of 'dotNotation', using a dot (.)
delimitation scheme comprised of two (2) or more elements
- 'additionalIdentifier' is a multi-valued attribute type populated
solely by one or more non-primary 'identifier' (or 'nameForm')
values
With such cases in mind, directory architects are advised to plan
attribute support carefully, as well as manage expectations of the
end-user.
Directory architects SHOULD populate some of the above attribute
types in cases where their true value may not be possible to predict
or extrapolate. One example of this is the 'iRI' value for the OID
assigned to 'asn1' (2.1). While its logical 'unicodeValue'-based
path might produce an effective value of "/Joint-ISO-ITU-T/ASN.1",
which is not its true 'iRI' - the correct value is "/ASN.1".
3.7.2. Subtree Search Operations
Use of wholeSubtree, or Subtree, LDAP Search Operations (as defined
in Section 4.5.1.2 of [RFC4511]) MAY be required in cases where a
registration lookup is needed, but only a single abstract piece of
information is known by the user. Frequently sought-after attribute
types of this nature include:
- 'nameAndNumberForm'
- 'identifier'
- 'additionalIdentifier'
- 'iRI'
- 'longArc'
- 'stdNameForm'
- 'unicodeValue'
Coretta Expires January 24, 2022 [Page 60]
Internet-Draft X.660 LDAP Schema and Models July 2021
Given an effective LDAP Search baseObject (per Section 4.5.1.1 of
[RFC4511]), and depending on the nature of the information requested,
such operations may be especially expensive. Should these operations
be deemed necessary, directory administrators are STRONGLY advised
to take appropriate performance-level actions to ensure fast request
responses. This may be achieved through a variety of DSA-level
optimizations -- concepts that are out of scope for this document.
It may also be prudent for directory administrators to place limits
on the number of entries that can be returned as a result of a given
request. This is especially true if the RA DSA supports substring
search filters (e.g.: '(identifier=a*)') that would almost certainly
return many results.
4. IANA Considerations
There are no requests to IANA in this document.
5. Security Considerations
This document focuses on providing flexible directory models and LDAP
schema elements in order to serve OID-related entries, and to allow
for an LDAP-based means for OID resolution. No assumptions are made
with regards to confidentiality of entries.
If some or all of the [X.660] data in a given directory is sensitive
in nature, directory architects MUST take appropriate steps to secure
this information. Although such concepts are out of scope for this
document, specific attribute types were made available in Section
2 to aid directory architects in this regard.
- 'discloseTo', defined in Section 2.1.26, allows the declaration
of one or more LDAP DNs authorized to read the necessary content
- 'registrationStatus', defined in Section 2.1.13, facilitates
access control evaluations of subtrees with a top-level parent
that is assigned a value of "private"
- 'currentAuthority' and/or 'sponsor', defined in Sections 2.1.28
and 2.1.65 respectively, MAY be used to refer to identities that
are authorized to allocate new registrations, as well to make
certain changes to existing ones
Directory architects SHOULD employ custom attribute types and/or
an enhanced DSA configuration for access control purposes if the
above attribute types are unsuitable in some way.
Coretta Expires January 24, 2022 [Page 61]
Internet-Draft X.660 LDAP Schema and Models July 2021
5.1. Modification Identity Obfuscation
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 registration changes without exposing the true
authentication 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] functionality, a topic that is well out of scope
for this document.
5.2. Registrant Privacy
Some public RA services are known to offer privacy options that are
meant to allow redaction of contact-related attributes such as for
telephone numbers and/or email and postal addresses from public view.
In such cases, the directory architect(s) in question SHOULD take the
time to set appropriate security and access control mechanisms so as
to protect the data from undesirable entities, such as spammers. This
MAY include methodologies such as:
- Requiring account registration and authentication to access such
personal data via the RA DSA
- Limiting disclosure of personal data to administrative personnel
and the relevant registrant only
- Requiring deliberate baseObject LDAP Search requests only (per
Section 4.5.1.2 of [RFC4511]), which would result in registrant
entries only being reachable by singular references through an
OID registration
Overall, the public hosting of any contact information, regardless of
its nature, is an enormous responsibility that SHOULD NEVER be taken
lightly.
6. References
6.1. Normative References
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Coretta Expires January 24, 2022 [Page 62]
Internet-Draft X.660 LDAP Schema and Models July 2021
[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.
[RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight
Directory Access Protocol (LDAP) Directories", RFC 3296,
July 2002.
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[RFC4370] Weltman, R., "Lightweight Directory Access Protocol
(LDAP): Proxy Authorization Control", RFC 4370, February
2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
Coretta Expires January 24, 2022 [Page 63]
Internet-Draft X.660 LDAP Schema and Models July 2021
[X.501] International Telecommunication Union - Telecommunication
Standardization Sector, "The Directory: Models", ITU-T
X.501, October 2016.
[PRIVATE] IANA, "Private Enterprise Numbers",
https://www.iana.org/assignments/enterprise-numbers.
Author's Address
Jesse Coretta
Palm Springs, CA 92262
United States
Email: jesse.coretta@icloud.com
Coretta Expires January 24, 2022 [Page 64]