Lightweight Directory Access Protocol (LDAP) Procedures and Schema Definitions for the Storage of X.660 Registration Information
draft-coretta-x660-ldap-06
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-05-15 | ||
| 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-06
X660LDAP J. Coretta
Internet-Draft May 15, 2021
Intended status: Standards Track
Expires: November 15, 2021
Lightweight Directory Access Protocol (LDAP)
Procedures and Schema Definitions for the
Storage of X.660 Registration Information
draft-coretta-x660-ldap-06.txt
Abstract
This specification defines models and schema definitions facilitating
the storage of [X.660] registration data in 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 November 15, 2021.
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 November 15, 2021 [Page 1]
Internet-Draft X.660 LDAP Schema and Models May 2021
Table of Contents
1. Introduction ....................................................4
1.1. Conventions ................................................4
1.2. Acronyms Used ..............................................4
1.3. Intended Audience ..........................................4
1.4. OIDs Allocated .............................................4
1.5. Well-Known OIDs ............................................5
2. Schema Definitions ..............................................5
2.1. Attribute Types ............................................5
2.1.1. 'n' ...................................................5
2.1.2. 'dottedNotation' ......................................6
2.1.3. 'iRI' .................................................6
2.1.4. 'asn1Notation' ........................................7
2.1.5. 'unicodeValue' ........................................7
2.1.6. 'identifier' ..........................................7
2.1.7. 'additionalIdentifier' ................................8
2.1.8. 'longArc' .............................................8
2.1.9. 'arcInformation' ......................................8
2.1.10. 'arcURI' .............................................9
2.1.11. 'arcRegId' ...........................................9
2.1.12. 'arcCreateTimestamp' ................................10
2.1.13. 'arcModifyTimestamp' ................................10
2.1.14. 'currentRegAuthority' ...............................11
2.1.15. 'currentRegAuthorityStartTimestamp' .................11
2.1.16. 'currentRegAuthorityCommonName' .....................11
2.1.17. 'currentRegAuthorityCountryCode' ....................12
2.1.18. 'currentRegAuthorityCountryName' ....................12
2.1.19. 'currentRegAuthorityEmail' ..........................13
2.1.20. 'currentRegAuthorityFax' ............................13
2.1.21. 'currentRegAuthorityLocality' .......................13
2.1.22. 'currentRegAuthorityMobile' .........................14
2.1.23. 'currentRegAuthorityOrg' ............................14
2.1.24. 'currentRegAuthorityPOBox' ..........................15
2.1.25. 'currentRegAuthorityPostalAddress' ..................15
2.1.26. 'currentRegAuthorityPostalCode' .....................15
2.1.27. 'currentRegAuthorityState' ..........................16
2.1.28. 'currentRegAuthorityStreet' .........................16
2.1.29. 'currentRegAuthorityTelephone' ......................17
2.1.30. 'currentRegAuthorityTitle' ..........................17
2.1.31. 'currentRegAuthorityURI' ............................17
2.1.32. 'firstRegAuthority' .................................18
2.1.33. 'firstRegAuthorityStartTimestamp' ...................18
2.1.34. 'firstRegAuthorityEndTimestamp' .....................19
2.1.35. 'firstRegAuthorityCommonName' .......................19
2.1.36. 'firstRegAuthorityCountryCode' ......................19
2.1.37. 'firstRegAuthorityCountryName' ......................20
2.1.38. 'firstRegAuthorityEmail' ............................20
2.1.39. 'firstRegAuthorityFax' ..............................21
2.1.40. 'firstRegAuthorityLocality' .........................21
2.1.41. 'firstRegAuthorityMobile' ...........................21
2.1.42. 'firstRegAuthorityOrg' ..............................22
Coretta Expires November 15, 2021 [Page 2]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.43. 'firstRegAuthorityPOBox' ............................22
2.1.44. 'firstRegAuthorityPostalAddress' ....................23
2.1.45. 'firstRegAuthorityPostalCode' .......................23
2.1.46. 'firstRegAuthorityState' ............................23
2.1.47. 'firstRegAuthorityStreet' ...........................24
2.1.48. 'firstRegAuthorityTelephone' ........................24
2.1.49. 'firstRegAuthorityTitle' ............................25
2.1.50. 'firstRegAuthorityURI' ..............................25
2.1.51. 'sponsor' ...........................................25
2.1.52. 'sponsorStartTimestamp ..............................26
2.1.53. 'sponsorEndTimestamp ................................26
2.1.54. 'sponsorCommonName' .................................26
2.1.55. 'sponsorCountryCode' ................................27
2.1.56. 'sponsorCountryName' ................................27
2.1.57. 'sponsorEmail' ......................................28
2.1.58. 'sponsorFax' ........................................28
2.1.59. 'sponsorLocality' ...................................28
2.1.60. 'sponsorMobile' .....................................29
2.1.61. 'sponsorOrg' ........................................29
2.1.62. 'sponsorPOBox' ......................................29
2.1.63. 'sponsorPostalAddress' ..............................30
2.1.64. 'sponsorPostalCode' .................................30
2.1.65. 'sponsorState' ......................................30
2.1.66. 'sponsorStreet' .....................................31
2.1.67. 'sponsorTelephone' ..................................31
2.1.68. 'sponsorTitle' ......................................32
2.1.69. 'sponsorURI' ........................................32
2.2. Object Classes ............................................32
2.2.1. 'x660RootArcEntry' ...................................32
2.2.2. 'x660SubArcEntry' ....................................33
2.2.3. 'x660ContactEntry' ...................................33
3. Directory Models ...............................................34
3.1. Naming Context and Organization Entries ...................34
3.2. Two-Dimensional Model .....................................35
3.2.1. Requirements .........................................35
3.2.2. Distinguished Name Convention ........................35
3.2.3. Root Arc Entries .....................................36
3.2.4. Arc IRI and ASN.1 Value Storage ......................37
3.3. Three-Dimensional Model ...................................37
3.3.1. Requirements .........................................37
3.3.2. Distinguished Name Convention ........................38
3.3.3. Root Arc Entries .....................................38
3.3.3.1. Lack of Root Arc Entries ........................39
3.3.4. Arc IRI and ASN.1 Value Storage ......................41
3.4. Authority and Sponsorship Contact Info ....................41
3.4.1. Examples .............................................42
3.4.1.1. Combined OID and Contact Entries ................42
3.4.1.2. Dedicated Contact Entries .......................42
4. References .....................................................44
4.1. Normative References ......................................44
5. IANA Considerations ............................................45
6. Security Considerations ........................................45
Coretta Expires November 15, 2021 [Page 3]
Internet-Draft X.660 LDAP Schema and Models May 2021
Author's Address ..................................................43
1. Introduction
This specification describes a means for storing [X.660] registration
and contextual data within an LDAP [RFC4510] implementation.
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
PEN IANA Private Enterprise Number
IRI Internationalized Resource Identifier
RDN Relative Distinguished Name
DUA Directory User Agent (an LDAP client)
DIT Directory Information Tree
OID ASN.1 Object Identifier
GUI Graphical User Interface
TUI Textual User Interface
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.
- 1.3.6.1.4.1.56521 (author root)
- 1.3.6.1.4.1.56521.101 (specification OID)
- 1.3.6.1.4.1.56521.101.2 (schema OID)
- 1.3.6.1.4.1.56521.101.2.1 (attribute types OID)
Coretta Expires November 15, 2021 [Page 4]
Internet-Draft X.660 LDAP Schema and Models May 2021
- 1.3.6.1.4.1.56521.101.2.2 (object classes OID)
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.
2.1.1. 'n'
The 'n' attribute type allows the assignment of an unsigned integer,
meant to represent the primary identifier 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.
Coretta Expires November 15, 2021 [Page 5]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.1
NAME 'n'
DESC 'A single unsigned integer value assigned to an OID arc
to represent its primary integer identifier'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
As a usage example, consider the RECOMMENDED distinguished name
structure for three-dimensional implementations as described in
Section 3.3:
dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
2.1.2. 'dottedNotation'
The 'dottedNotation' attribute type allows the assignment of an OID
value [X.680] in dot-delimited form to an arc entry.
Please note this attribute type is only required in two-dimensional
directory model implementations of this specification.
( 1.3.6.1.4.1.56521.101.2.1.2
NAME 'dottedNotation'
DESC 'Dotted ASN.1 Object Identifier for non-root OIDs'
EQUALITY objectIdentifierMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Example:
dottedNotation: 1.3.6.1
2.1.3. 'iRI'
The 'iRI' attribute type allows the assignment of one or more IRI
values to an arc entry.
Please note this attribute type is only required in two-dimensional
directory model implementations of this specification, or if clients
will not automatically discover a given IRI value by traversal.
( 1.3.6.1.4.1.56521.101.2.1.3
NAME 'iRI'
DESC 'Internationalized Resource Identifiers for an OID'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Example:
iRI: /ISO/Identified-Organization
Coretta Expires November 15, 2021 [Page 6]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.4. 'asn1Notation'
The 'asn1Notation' attribute type allows the assignment of an OID
in ASN.1 notation to an arc entry.
Please note this attribute type is only required in two-dimensional
directory model implementations of this specification, or if clients
will not automatically discover a given ASN.1 value by traversal.
( 1.3.6.1.4.1.56521.101.2.1.4
NAME 'asn1Notation'
DESC 'ASN.1 values, encapsulated between curly
braces, for an OID'
SINGLE-VALUE
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Example:
asn1Notation: {iso(1) identified-organization(3)}
2.1.5. 'unicodeValue'
The 'unicodeValue' attribute type allows the assignment of the
Unicode-based primary identifier (non-numeric) [X.660] to an arc
entry.
( 1.3.6.1.4.1.56521.101.2.1.5
NAME 'unicodeValue'
DESC 'The primary non-numeric Unicode identifier
for an arc'
SINGLE-VALUE
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Example:
unicodeValue: itu-t
2.1.6. 'identifier'
The 'identifier' attribute type allows the assignment of a single
non-Unicode, non-numeric identifier [X.660] to an arc entry.
The attribute type 'name', as defined in Section 2.18 of [RFC4519],
is a super type of this attribute type.
Coretta Expires November 15, 2021 [Page 7]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.6
NAME 'identifier'
DESC 'The non-Unicode secondary identifier
for an arc'
SINGLE-VALUE
SUP name )
Example:
identifier: itu-t
2.1.7. 'additionalIdentifier'
The 'additionalIdentifier' attribute type allows the assignment of
of one or more additional identifiers [X.660] in an arc entry.
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 identifier for an arc'
SUP name )
Example:
additionalIdentifier: ccitt
2.1.8. 'longArc'
The 'longArc' attribute type allows the assignment of one or more
so-called "Long Arc" well-known identifiers to an arc entry.
Per [X.660], entries that bear values of this attribute type MUST
reside below the root joint-iso-itu-t (2) arc entry.
( 1.3.6.1.4.1.56521.101.2.1.8
NAME 'longArc'
DESC 'The well-known Long Arc names associated with, and
registered to, a Joint-ISO-ITU-T subordinate arc'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Example:
longArc: /Example
2.1.9. 'arcInformation'
The 'arcInformation' attribute type allows the OPTIONAL assignment
of octet based values intended for extended documentation or notes
in an arc entry.
Coretta Expires November 15, 2021 [Page 8]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.9
NAME 'arcInformation'
DESC 'Extended information for an arc'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2.1.10. 'arcURI'
The 'arcURI' attribute type allows for the assignment of one or more
URI values, with optional labels, to an arc entry.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attrubute type.
( 1.3.6.1.4.1.56521.101.2.1.10
NAME 'arcURI'
DESC 'URI, with an optional label, leading to
further related subject matter information'
SUP labeledURI )
Example:
arcURI: http://www.example.com Example
2.1.11. 'arcRegId'
The 'arcRegId' attribute type is intended to allow for the singular
assignment of a UUID or GUID to a contact 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 contact entries. This allows for an absolute and
unambiguous reference to any registration entry by DN.
Please note the intended use of this attribute type SHOULD NOT be
confused with the act of numbering an arc entry using the numerical
form of a GUID or UUID value, such as:
2.25.483275873209587983492589328598493854833
Such an act can be achieved through standard use of the 'n'
attribute type (defined in Section 2.1.1) as it allows an integer
value of suitable size to accommodate such a value.
Coretta Expires November 15, 2021 [Page 9]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.11
NAME 'arcRegId'
DESC 'GUID or UUID assigned to a past or
present registration authority or a
sponsor entry'
SINGLE-VALUE
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Example:
arcRegId: 4ab9c766-a875-4045-8df2-d4505193cca5
2.1.12. 'arcCreateTimestamp'
The 'arcCreateTimestamp' attribute type allows for the assignment of
a generalized timestamp indicating the date and time at which an arc
entry was created.
( 1.3.6.1.4.1.56521.101.2.1.12
NAME 'arcCreateTimestamp'
DESC 'Generalized timestamp for arc entry creation'
SINGLE-VALUE
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example:
arcCreateTimestamp: 20130109033116Z
2.1.13. 'arcModifyTimestamp'
The 'arcModifyTimestamp' attribute type allows for the assignment
of one or more generalized timestamp values indicating the dates
and times of all applied updates to an arc entry.
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.13
NAME 'arcModifyTimestamp'
DESC 'Generalized timestamps for arc entry modification'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Example:
arcModifyTimestamp: 20130109033116Z
Coretta Expires November 15, 2021 [Page 10]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.14. 'currentRegAuthority'
The 'currentRegAuthority' attribute type allows for the assignment
of one or more DN values to an arc entry.
The value(s) of this attribute type are meant to refer to distinct
entries that contain current registration authority information for
the indicated arc.
This attribute type is only required if such information is not
stored within a given arc entry directly.
( 1.3.6.1.4.1.56521.101.2.1.14
NAME 'currentRegAuthority'
DESC 'LDAP Distinguished Name of an entry
bearing current registration authority
information'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
Example:
currentRegAuthority: arcRegId=4ab9c766-a875-4045-8df2-d450
5193cca5,ou=Registry,ou=X660,dc=example,dc=com
2.1.15. 'currentRegAuthorityStartTimestamp'
The 'currentRegAuthorityStartTimestamp' 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.15
NAME 'currentRegAuthorityStartTimestamp'
DESC 'Generalized timestamp 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:
currentRegAuthorityStartTimestamp: 20130105135904Z
2.1.16. 'currentRegAuthorityCommonName'
The 'currentRegAuthorityCommonName' attribute type allows for the
assignment of a common name to a current registration authority
entry.
The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
is a super type of this attribute type.
Coretta Expires November 15, 2021 [Page 11]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.16
NAME 'currentRegAuthorityCommonName'
DESC 'Common Name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP cn )
Example:
currentRegAuthorityCommonName: Jesse Coretta
2.1.17. 'currentRegAuthorityCountryCode'
The 'currentRegAuthorityCountryCode' attribute type allows for the
assignment of a country code to a current 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.17
NAME 'currentRegAuthorityCountryCode'
DESC 'Country Code assigned to a current
registration authority entry'
SINGLE-VALUE
SUP c )
Example:
currentRegAuthorityCountry: US
2.1.18. 'currentRegAuthorityCountryName'
The 'currentRegAuthorityCountryName' attribute type allows for the
assignment of a country name to a current registration 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.18
NAME 'currentRegAuthorityCountryName'
DESC 'Country name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP co )
Example:
currentRegAuthorityCountryName: United States
Coretta Expires November 15, 2021 [Page 12]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.19. 'currentRegAuthorityEmail'
The 'currentRegAuthorityEmail' 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.19
NAME 'currentRegAuthorityEmail'
DESC 'Email address assigned to a current
registration authority entry'
SINGLE-VALUE
SUP mail )
Example:
currentRegAuthorityEmail: jesse.coretta@icloud.com
2.1.20. 'currentRegAuthorityFax'
The 'currentRegAuthorityFax' attribute type allows for the assignment
of a facsimile telephone number to a current 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.20
NAME 'currentRegAuthorityFax'
DESC 'Facsimile telephone number assigned to
a current registration authority entry'
SINGLE-VALUE
SUP facsimileTelephoneNumber )
Example:
currentRegAuthorityFax: +11234567890
2.1.21. 'currentRegAuthorityLocality'
The 'currentRegAuthorityLocality' attribute type allows for the
assignment of a locality name to a current registration authority
entry.
The attribute type 'l', as defined in Section 2.16 of [RFC4519],
is a super type of this attribute type.
Coretta Expires November 15, 2021 [Page 13]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.21
NAME 'currentRegAuthorityLocality'
DESC 'Locality name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP l )
Example:
currentRegAuthorityLocality: Palm Springs
2.1.22. 'currentRegAuthorityMobile'
The 'currentRegAuthorityMobile' 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.22
NAME 'currentRegAuthorityMobile'
DESC 'Mobile telephone number assigned to a
current registration authority entry'
SINGLE-VALUE
SUP mobile )
Example:
currentRegAuthorityMobile: +11234567890
2.1.23. 'currentRegAuthorityOrg'
The 'currentRegAuthorityOrg' attribute type allows for the assignment
of an organization name to a current 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.23
NAME 'currentRegAuthorityOrg'
DESC 'Organization name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP o )
Example:
currentRegAuthorityOrg: Acme, Co.
Coretta Expires November 15, 2021 [Page 14]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.24. 'currentRegAuthorityPOBox'
The 'currentRegAuthorityPOBox' 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.24
NAME 'currentRegAuthorityPOBox'
DESC 'Post office box number assigned to a
current registration authority entry'
SINGLE-VALUE
SUP postOfficeBox )
Example:
currentRegAuthorityPOBox: 555
2.1.25. 'currentRegAuthorityPostalAddress'
The 'currentRegAuthorityPostalAddress' 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.
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.25
NAME 'currentRegAuthorityPostalAddress'
DESC 'Full postal address assigned to a current
registration authority entry'
SINGLE-VALUE
SUP postalAddress )
Example:
currentRegAuthorityPostalAddress: 1 Fake St$Anytown$
CA$12345$US
2.1.26. 'currentRegAuthorityPostalCode'
The 'currentRegAuthorityPostalCode' attribute type allows for the
assignment of a postal code to a current registration authority
entry.
The attribute type 'postalCode', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
Coretta Expires November 15, 2021 [Page 15]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.26
NAME 'currentRegAuthorityPostalCode'
DESC 'Postal code assigned to a current
registration authority entry'
SINGLE-VALUE
SUP postalCode )
Example:
currentRegAuthorityPostalCode: 92262
2.1.27. 'currentRegAuthorityState'
The 'currentRegAuthorityState' 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.27
NAME 'currentRegAuthorityState'
DESC 'State or province name assigned to a current
registration authority entry'
SINGLE-VALUE
SUP st )
Example:
currentRegAuthorityState: California
2.1.28. 'currentRegAuthorityStreet'
The 'currentRegAuthorityStreet' 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.28
NAME 'currentRegAuthorityStreet'
DESC 'Street name and number assigned to a current
registration authority entry'
SINGLE-VALUE
SUP street )
Example:
currentRegAuthorityStreet: 1 Fake Street
Coretta Expires November 15, 2021 [Page 16]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.29. 'currentRegAuthorityTelephone'
The 'currentRegAuthorityTelephone' attribute type allows for the
assignment of a telephone number to a current 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.29
NAME 'currentRegAuthorityTelephone'
DESC 'Telephone number assigned to a current
registration authority entry'
SINGLE-VALUE
SUP telephoneNumber )
Example:
currentRegAuthorityTelephone: +11234567890
2.1.30. 'currentRegAuthorityTitle'
The 'currentRegAuthorityTitle' attribute type allows for the
assignment of an official or professional title to a current
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.30
NAME 'currentRegAuthorityTitle'
DESC 'Title assigned to a current
registration authority entry'
SINGLE-VALUE
SUP title )
Example:
currentRegAuthorityTitle: Chief Engineer
2.1.31. 'currentRegAuthorityURI'
The 'currentRegAuthorityURI' attribute type allows for the
assignment of one or more URI values, with optional labels,
to a current registration authority entry.
The attribute type 'labeledURI', as defined in [RFC2079], is
a super type of this attribute type.
Coretta Expires November 15, 2021 [Page 17]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.31
NAME 'currentRegAuthorityURI'
DESC 'URI, with an optional label, leading
to a resource related to a current
registration authority'
SUP labeledURI )
Example:
currentRegAuthorityURI: http://www.example.com
2.1.32. 'firstRegAuthority'
The 'firstRegAuthority' attribute type allows for the assignment
of one or more DN values to an arc entry.
The value(s) of this attribute type are meant to refer to distinct
entries that contains previous registration authority information
for the indicated arc.
This attribute type is only required if such information is not
stored within a given arc entry directly.
( 1.3.6.1.4.1.56521.101.2.1.32
NAME 'firstRegAuthority'
DESC 'LDAP Distinguished Name of an entry
bearing previous registration authority
information'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
Example:
firstRegAuthority: arcRegId=4fb7ca10-b100-b33f-aee1-e101
1261ae79,ou=Registry,ou=X660,dc=example,dc=com
2.1.33. 'firstRegAuthorityStartTimestamp'
The 'firstRegAuthorityStartTimestamp' 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.33
NAME 'firstRegAuthorityStartTimestamp'
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 )
Coretta Expires November 15, 2021 [Page 18]
Internet-Draft X.660 LDAP Schema and Models May 2021
Example:
firstRegAuthorityStartTimestamp: 20130105135904Z
2.1.34. 'firstRegAuthorityEndTimestamp'
The 'firstRegAuthorityEndTimestamp' 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.
( 1.3.6.1.4.1.56521.101.2.1.34
NAME 'firstRegAuthorityEndTimestamp'
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:
firstRegAuthorityEndTimestamp: 20170528110555Z
2.1.35. 'firstRegAuthorityCommonName'
The 'firstRegAuthorityCommonName' 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.35
NAME 'firstRegAuthorityCommonName'
DESC 'Common Name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP cn )
Example:
firstRegAuthorityCommonName: Jesse Coretta
2.1.36. 'firstRegAuthorityCountryCode'
The 'firstRegAuthorityCountryCode' 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.
Coretta Expires November 15, 2021 [Page 19]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.36
NAME 'firstRegAuthorityCountryCode'
DESC 'Country Code assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP c )
Example:
firstRegAuthorityCountry: US
2.1.37. 'firstRegAuthorityCountryName'
The 'firstRegAuthorityCountryName' attribute type allows for the
assignment of a country name to a previous registration authority
entry.
The attribute type 'co', as defined in Section 2.4 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.1.37
NAME 'firstRegAuthorityCountryName'
DESC 'Country name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP co )
Example:
firstRegAuthorityCountryName: United States
2.1.38. 'firstRegAuthorityEmail'
The 'firstRegAuthorityEmail' 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.38
NAME 'firstRegAuthorityEmail'
DESC 'Email address assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP mail )
Example:
firstRegAuthorityEmail: jesse.coretta@icloud.com
Coretta Expires November 15, 2021 [Page 20]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.39. 'firstRegAuthorityFax'
The 'firstRegAuthorityFax' 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.39
NAME 'firstRegAuthorityFax'
DESC 'Facsimile telephone number assigned to
a previous registration authority entry'
SINGLE-VALUE
SUP facsimileTelephoneNumber )
Example:
firstRegAuthorityFax: +11234567890
2.1.40. 'firstRegAuthorityLocality'
The 'firstRegAuthorityLocality' attribute type allows for the
assignment of a locality name to a previous registration 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.40
NAME 'firstRegAuthorityLocality'
DESC 'Locality name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP l )
Example:
firstRegAuthorityLocality: Palm Springs
2.1.41. 'firstRegAuthorityMobile'
The 'firstRegAuthorityMobile' 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.
Coretta Expires November 15, 2021 [Page 21]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.41
NAME 'firstRegAuthorityMobile'
DESC 'Mobile telephone number assigned to a
previous registration authority entry'
SINGLE-VALUE
SUP mobile )
Example:
firstRegAuthorityMobile: +11234567890
2.1.42. 'firstRegAuthorityOrg'
The 'firstRegAuthorityOrg' 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.42
NAME 'firstRegAuthorityOrg'
DESC 'Organization name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP o )
Example:
firstRegAuthorityOrg: Acme, Co.
2.1.43. 'firstRegAuthorityPOBox'
The 'firstRegAuthorityPOBox' attribute type allows for the assignment
of a post office box number to a previous 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.43
NAME 'firstRegAuthorityPOBox'
DESC 'Post office box number assigned to a
previous registration authority entry'
SINGLE-VALUE
SUP postOfficeBox )
Example:
firstRegAuthorityPOBox: 555
Coretta Expires November 15, 2021 [Page 22]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.44. 'firstRegAuthorityPostalAddress'
The 'firstRegAuthorityPostalAddress' 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.
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.44
NAME 'firstRegAuthorityPostalAddress'
DESC 'Full postal address assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP postalAddress )
Example:
firstRegAuthorityPostalAddress: 1 Fake St$Anytown$
CA$12345$US
2.1.45. 'firstRegAuthorityPostalCode'
The 'firstRegAuthorityPostalCode' 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.45
NAME 'firstRegAuthorityPostalCode'
DESC 'Postal code assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP postalCode )
Example:
firstRegAuthorityPostalCode: 92262
2.1.46. 'firstRegAuthorityState'
The 'firstRegAuthorityState' 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.
Coretta Expires November 15, 2021 [Page 23]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.46
NAME 'firstRegAuthorityState'
DESC 'State or province name assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP st )
Example:
firstRegAuthorityState: California
2.1.47. 'firstRegAuthorityStreet'
The 'firstRegAuthorityStreet' 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.47
NAME 'firstRegAuthorityStreet'
DESC 'Street name and number assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP street )
Example:
firstRegAuthorityStreet: 1 Fake Street
2.1.48. 'firstRegAuthorityTelephone'
The 'firstRegAuthorityTelephone' 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.48
NAME 'firstRegAuthorityTelephone'
DESC 'Telephone number assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP telephoneNumber )
Example:
firstRegAuthorityTelephone: +11234567890
Coretta Expires November 15, 2021 [Page 24]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.49. 'firstRegAuthorityTitle'
The 'firstRegAuthorityTitle' 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.49
NAME 'firstRegAuthorityTitle'
DESC 'Title assigned to a previous
registration authority entry'
SINGLE-VALUE
SUP title )
Example:
firstRegAuthorityTitle: Chief Engineer
2.1.50. 'firstRegAuthorityURI'
The 'firstRegAuthorityURI' 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.50
NAME 'firstRegAuthorityURI'
DESC 'URI, with an optional label, leading
to a resource related to a previous
registration authority'
SUP labeledURI )
Example:
firstRegAuthorityURI: http://www.example.com
2.1.51. 'sponsor'
The 'sponsor' attribute type allows for the assignment
of one or more DN values to an arc entry.
The value(s) of this attribute type are meant to refer to distinct
entries that contains sponsorship-related information for a given
arc.
This attribute type is only required if such information is not
stored within a given arc entry directly.
Coretta Expires November 15, 2021 [Page 25]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.51
NAME 'sponsor'
DESC 'LDAP Distinguished Name of an entry
bearing sponsorship information'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
Example:
sponsor: arcRegId=1ea6ac09-c200-c11a-c430-c3p0
3211ffff,ou=Registry,ou=X660,dc=example,dc=com
2.1.52. '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.52
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:
sponsorStartTimestamp: 20130105135904Z
2.1.53. '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.53
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:
sponsorEndTimestamp: 20170528110555Z
2.1.54. 'sponsorCommonName'
The 'sponsorCommonName' attribute type allows for the assignment
of a common name to a sponsor entry.
Coretta Expires November 15, 2021 [Page 26]
Internet-Draft X.660 LDAP Schema and Models May 2021
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.54
NAME 'sponsorCommonName'
DESC 'Common Name of a sponsor entry'
SINGLE-VALUE
SUP cn )
Example:
sponsorCommonName: Jane Sponsor
2.1.55. '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.55
NAME 'sponsorCountryCode'
DESC 'Country code for a sponsor entry'
SINGLE-VALUE
SUP c )
Example:
sponsorCountryCode: US
2.1.56. '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.56
NAME 'sponsorCountryName'
DESC 'Country name for a sponsor entry'
SINGLE-VALUE
SUP co )
Example:
sponsorCountryName: United States
Coretta Expires November 15, 2021 [Page 27]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.57. '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.57
NAME 'sponsorEmail'
DESC 'Email address for a sponsor entry'
SINGLE-VALUE
SUP mail )
Example:
sponsorEmail: sponsor@example.com
2.1.58. '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.58
NAME 'sponsorFax'
DESC 'Facsimile telephone number for a sponsor entry'
SINGLE-VALUE
SUP facsimileTelephoneNumber )
Example:
sponsorFax: +11234567890
2.1.59. '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.59
NAME 'sponsorLocality'
DESC 'Locality name for a sponsor entry'
SINGLE-VALUE
SUP l )
Coretta Expires November 15, 2021 [Page 28]
Internet-Draft X.660 LDAP Schema and Models May 2021
Example:
sponsorLocality: Anytown
2.1.60. '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.60
NAME 'sponsorMobile'
DESC 'Mobile telephone number for a sponsor entry'
SINGLE-VALUE
SUP mobile )
Example:
sponsorMobile: +11234567890
2.1.61. 'sponsorOrg'
The 'sponsorOrg' attribute type allows for the assignment of an
organization name to a sponsor 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.61
NAME 'sponsorOrg'
DESC 'Organization name for a sponsor entry'
SINGLE-VALUE
SUP o )
Example:
sponsorOrg: Sponsor Co.
2.1.62. 'sponsorPOBox'
The 'sponsorPOBox' attribute type allows for the assignment of a
post office box number to a sponsor entry.
Thie attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
Coretta Expires November 15, 2021 [Page 29]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.1.62
NAME 'sponsorPOBox'
DESC 'Post office box number for a sponsor entry'
SINGLE-VALUE
SUP postOfficeBox )
Example:
sponsorPOBox: 1255
2.1.63. '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.
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.63
NAME 'sponsorPostalAddress'
DESC 'Full postal address for a sponsor entry'
SINGLE-VALUE
SUP postalAddress )
Example:
sponsorPostalAddress: 1 Fake St$Anytown$CA$12345$US
2.1.64. '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.
( 1.3.6.1.4.1.56521.101.2.1.64
NAME 'sponsorPostalCode'
DESC 'Postal code for a sponsor entry'
SINGLE-VALUE
SUP postalCode )
Example:
sponsorPostalCode: 92262
2.1.65. 'sponsorState'
The 'sponsorState' attribute type allows for the assignment of a
state or province name to a sponsor entry.
Coretta Expires November 15, 2021 [Page 30]
Internet-Draft X.660 LDAP Schema and Models May 2021
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.65
NAME 'sponsorState'
DESC 'State or province name for a sponsor entry'
SINGLE-VALUE
SUP st )
Example:
sponsorState: California
2.1.66. '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.66
NAME 'sponsorStreet'
DESC 'Street name and number for a sponsor entry'
SINGLE-VALUE
SUP street )
Example:
sponsorStreet: 1 Fake Street
2.1.67. '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.
( 1.3.6.1.4.1.56521.101.2.1.67
NAME 'sponsorTelephone'
DESC 'Telephone number for a sponsor entry'
SINGLE-VALUE
SUP telephoneNumber )
Example:
sponsorTelephone: +11234567890
Coretta Expires November 15, 2021 [Page 31]
Internet-Draft X.660 LDAP Schema and Models May 2021
2.1.68. '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.68
NAME 'sponsorTitle'
DESC 'Title for a sponsor entry'
SINGLE-VALUE
SUP title )
Example:
sponsorTitle: Executive Sponsor
2.1.69. '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.69
NAME 'sponsorURI'
DESC 'URI, with an optional label, for a
sponsor entry'
SUP labeledURI )
Example:
sponsorURI: http://www.example.com Sponsor
2.2. Object Classes
The following subsections describes LDAP object classes made
available by this specification.
2.2.1. 'x660RootArcEntry'
The 'x660RootArcEntry' class is meant to define a maximum of three
(3) root arcs within a DIT, per Rec. ITU-T X.660 (ISO/IEC 9834-1).
Coretta Expires November 15, 2021 [Page 32]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.2.1
NAME 'x660RootArcEntry'
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 )
MAY ( identifier $ firstRegAuthority $ arcURI $
arcCreateTimestamp $ arcModifyTimestamp $
arcInformation $ additionalIdentifier $
additionalIdentifier $ asn1Notation $
currentRegAuthority $ sponsor $
description ) )
2.2.2. 'x660SubArcEntry'
The 'x660SubArcEntry' object class makes a collection of attribute
types available for use when crafting sub arc entries within a DIT.
( 1.3.6.1.4.1.56521.101.2.2.2
NAME 'x660SubArcEntry'
DESC 'A generalized class meant to represent
subordinate arcs beneath any root, as defined
in X.660 Sections A.3-A.5'
SUP top
STRUCTURAL
MUST ( n )
MAY ( asn1Notation $ iRI $ dottedNotation $
unicodeValue $ currentRegAuthority $
firstRegAuthority $ arcInformation $
identifier $ additionalIdentifier $
arcModifyTimestamp $ sponsor $
longArc $ arcCreateTimestamp $
description $ arcURI ) )
2.2.3. 'x660ContactEntry'
The 'x660ContactEntry' object class allows for current, previous
(first) and/or sponsorship contact information to be stored within
an entry.
In larger, more complete implementations of this specification, it
is RECOMMENDED that registration data be stored in dedicated entries
that bear this class. In contrast, sparse implementations MAY opt
to assign this class directly to entries bearing 'x660RootArcEntry'
and 'x660SubArcEntry' object classes, though this is not required.
Coretta Expires November 15, 2021 [Page 33]
Internet-Draft X.660 LDAP Schema and Models May 2021
( 1.3.6.1.4.1.56521.101.2.2.3
NAME 'x660ContactEntry'
DESC 'A generalized auxiliary class for arc
registration contact information'
SUP top
AUXILIARY
MAY ( currentRegAuthorityCommonName $ firstRegAuthorityMobile $
currentRegAuthorityTitle $ firstRegAuthorityCountryCode $
currentRegAuthorityPostalAddress $ firstRegAuthorityOrg $
currentRegAuthorityFax $ firstRegAuthorityPostalAddress $
currentRegAuthorityURI $ sponsorCommonName $ sponsorOrg $
currentRegAuthorityCountryCode $ firstRegAuthorityState $
currentRegAuthorityCountryName $ firstRegAuthorityEmail $
currentRegAuthorityMobile $ firstRegAuthorityCommonName $
firstRegAuthorityPOBox $ sponsorPOBox $ sponsorLocality $
firstRegAuthorityCountryName $ currentRegAuthorityState $
sponsorStreet $ sponsorMobile $ sponsorState $ arcRegId $
sponsorPostalCode $ sponsorPostalAddress $ sponsorEmail $
currentRegAuthorityPostalCode $ firstRegAuthorityStreet $
currentRegAuthorityTelephone $ currentRegAuthorityEmail $
currentRegAuthorityLocality $ firstRegAuthorityLocality $
currentRegAuthorityStreet $ firstRegAuthorityPostalCode $
sponsorCountryCode $ firstRegAuthorityURI $ description $
firstRegAuthorityStartTimestamp $ sponsorStartTimestamp $
firstRegAuthorityFax $ sponsorCountryName $ sponsorURI $
sponsorTelephone $ currentRegAuthorityOrg $ sponsorFax $
firstRegAuthorityTelephone $ currentRegAuthorityPOBox $
firstRegAuthorityEndTimestamp $ sponsorEndTimestamp $
currentRegAuthorityStartTimestamp $ sponsorTitle $
firstRegAuthorityTitle ) )
3. Directory Models
This specification offers two (2) distinct models by which directory
architects and application developers SHOULD be guided during their
efforts for implementation.
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 arc
registration entries.
- "ou=Registry, ou=X660, dc=example, dc=com" - Storage of all arc
authority and sponsorship registration contact entries
(OPTIONAL).
Coretta Expires November 15, 2021 [Page 34]
Internet-Draft X.660 LDAP Schema and Models May 2021
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 arc entries 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.
3.2.1. Requirements
One requirement of this model is strict use of the 'dottedNotation'
attribute type, covered in Section 2.1.2. This attribute MUST be
used on all non-root arc entries.
Root arc entries SHALL NOT bear an 'dottedNotation' 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 'dottedNotation' 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 the next section.
3.2.2. Distinguished Name Convention
Because all LDAP search requests can be conducted using a "one-level
scope" below the circumscribing directory branch, a hierarchical DN
structure is unnecessary. While the three-dimensional model (shown
in Section 3.3) uses the integer-based 'n' attribute type (as defined
in Section 2.1.1) to form the effective LDAP RDN of an entry, it is
not practical in this model.
The most sensible convention for DN involves use of the attribute
type 'dottedNotation' as shown:
dn: dottedNotation=1.3,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 3
unicodeValue: identified-organization
dottedNotation: 1.3
Coretta Expires November 15, 2021 [Page 35]
Internet-Draft X.660 LDAP Schema and Models May 2021
Subsequent entries, regardless of hierarchical superiority, manifest
as sibling entries. For example, the addition of deeper arcs would
be procedurally identical:
dn: dottedNotation=1.3.6.1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 1
unicodeValue: internet
dottedNotation: 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 'x660RootArcEntry'
class, as shown in Section 2.2.1:
dn: n=0,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 0
unicodeValue: itu-t
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 1
unicodeValue: iso
dn: n=2,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 2
unicodeValue: joint-iso-itu-t
Using root arc entries is only useful in the two-dimensional model if
the administrator wishes to organize lists of OIDs beneath their
respective root arcs. 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.
Coretta Expires November 15, 2021 [Page 36]
Internet-Draft X.660 LDAP Schema and Models May 2021
3.2.4. Arc IRI and ASN.1 Value Storage
Following this directory model implementation, storage of literal
IRI and/or ASN.1 values is required if such values are expected to
be present for a given arc entry.
Unlike the three-dimensional model defined in Section 3.3, there is
no inherent hierarchy to traverse for the purpose of reading interim
'unicodeValue' values and composing a resultant IRI or ASN.1 value
in this directory model. As a result, use of the 'iRI' and/or
'asn1Notation' attribute types is necessary.
3.3. Three-Dimensional Model
This model is hierarchical by nature, providing a means for storing
arc entries 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 is NOT RECOMMENDED for 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.
3.3.1. Requirements
In this model, interim arcs MUST exist even if they are otherwise
unnecessary.
For example, in order to add the well-known arc "internet" OID,
directory administrators MUST ensure these registrations exist
beforehand:
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 1
unicodeValue: iso
dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 3
unicodeValue: identified-organization
Coretta Expires November 15, 2021 [Page 37]
Internet-Draft X.660 LDAP Schema and Models May 2021
dn: n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 6
unicodeValue: 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: x660SubArcEntry
n: 1
unicodeValue: 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 arc 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
As a result, use of the 'dottedNotation' attribute type becomes
unnecessary.
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 'x660RootArcEntry'
class, as shown in Section 2.2.1:
Coretta Expires November 15, 2021 [Page 38]
Internet-Draft X.660 LDAP Schema and Models May 2021
dn: n=0,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 0
unicodeValue: itu-t
dn: n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 1
unicodeValue: iso
dn: n=2,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660RootArcEntry
n: 2
unicodeValue: joint-iso-itu-t
Depending on the breadth and scope of an implementation, creation and
use of root arc entries 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 sub arc entries, true root arc entries may
not be necessary.
Instead, directories architects MAY choose to create a sub arc
entry 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:
dn: dottedNotation=1.3.6.1.4.1,ou=OID,ou=X660,dc=example,
dc=com
objectClass: top
objectClass: x660SubArcEntry
arcURI: https://www.iana.org/assignments/enterprise-numbers/
enterprise-numbers
dn: n=56521,dottedNotation=1.3.6.1.4.1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
unicodeValue: Jesse Coretta
... other sibling PEN entries ...
Coretta Expires November 15, 2021 [Page 39]
Internet-Draft X.660 LDAP Schema and Models May 2021
Alternatively, if the above non-standard DN syntax is undesirable,
directory architects MAY choose to honor the three-dimensional model
DN syntax, but limit created entries to those that are direct
ancestors of the intended subset. In this situation use of a root
arc entry 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: x660RootArcEntry
n: 1
unicodeValue: iso
dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 3
unicodeValue: identified-organization
dn: n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 6
unicodeValue: dod
dn: n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 1
unicodeValue: internet
dn: n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 4
unicodeValue: enterprise
dn: n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com
objectClass: top
objectClass: x660SubArcEntry
n: 1
unicodeValue: private
arcURI: https://www.iana.org/assignments/enterprise-numbers/
enterprise-numbers
Coretta Expires November 15, 2021 [Page 40]
Internet-Draft X.660 LDAP Schema and Models May 2021
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: x660SubArcEntry
unicodeValue: Jesse Coretta
... other sibling PEN entries ...
3.3.4. Arc IRI and ASN.1 Value Storage
Following this directory model implementation, storage of IRI and
ASN.1 values is not required, but may still be desirable.
It is assumed that a suitable DUA (one optimized with this specific
specification in mind) would be capable of extrapolating any fully
qualified IRI or ASN.1 value by way of traversal of all arcs defined
in a given branch path. In other words, a DUA can deduce the iRI for
the OID '1.3' is '/iso/identified-organization' by reading the value
of the attribute type 'unicodeValue' from both the iso root 'n' (1)
as well as the specified subordinate 'n' (3), in that order.
However this may not be a desirable action from some points of view.
It may be more administratively feasible to simply store the literal
IRI and/or ASN.1 values for any given arc entry by way of 'iRI'
or 'asn1Notation' attribute type usage respectively.
In terms of a reasonably sound DUA design, it is RECOMMENDED the
client check if the 'iRI' and/or 'asn1Notation' attribute types are
present and, if not, attempt to extrapolate such values as a fall
back or optional action.
3.4. Authority and Sponsorship Contact Info
Directory architects MAY choose to store authority and/or sponsor
contact information in one of two main ways:
- Store sponsor or authority contact information within arc
entries themselves, or ...
- Store sponsor or authority contact information within
dedicated entries, and reference the DNs of these entries
via the 'currentRegAuthority', 'sponsor' and/or
'firstRegAuthority' attribute types assigned to arc entries.
The nature of these contacts will typically encompass three (3)
kinds of entities:
Coretta Expires November 15, 2021 [Page 41]
Internet-Draft X.660 LDAP Schema and Models May 2021
- An individual
- An organization, institution or working group
- A document (e.g.: a standard or draft)
3.4.1. Examples
3.4.1.1. Combined OID and Contact Entries
This is a basic two-dimensional example entry comprised of both OID
and contact attribute types.
dn: dottedNotation=1.3.6.1.4.1.56521,n=1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: x660SubArcEntry
objectClass: x660ContactEntry
objectClass: top
currentRegAuthorityPostalAddress: 1 Fake St$Anywhere$CA$92262
currentRegAuthorityCommonName: Jesse Coretta
currentRegAuthorityEmail: jesse.coretta@example.com
currentRegAuthorityMobile: +11234567890
dottedNotation: 1.3.6.1.4.1.56521
unicodeValue: Jesse Coretta
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: x660SubArcEntry
objectClass: x660ContactEntry
objectClass: top
currentRegAuthorityPostalAddress: 1 Fake St$Anywhere$CA$92262
currentRegAuthorityCommonName: Jesse Coretta
currentRegAuthorityEmail: jesse.coretta@example.com
currentRegAuthorityMobile: +11234567890
unicodeValue: Jesse Coretta
n: 56521
3.4.1.2. Dedicated Contact 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 November 15, 2021 [Page 42]
Internet-Draft X.660 LDAP Schema and Models May 2021
dn: arcRegId=draft-coretta-x660-ldap,ou=Registry,
ou=X660,dc=example,dc=com
arcRegId: draft-coretta-x660-ldap
cn: draft-coretta-x660-ldap
objectClass: organizationalRole
objectClass: x660ContactEntry
objectClass: top
currentRegAuthorityPostalAddress: 1 Fake St$Palm Springs$
CA$92262
currentRegAuthorityCommonName: Jesse Coretta
currentRegAuthorityEmail: jesse.coretta@icloud.com
currentRegAuthorityMobile: +11234567890
currentRegAuthorityStartTimestamp: 20200229134901Z
In cases where multiple distinct individuals or addresses are used,
they can all be combined into a single record:
dn: arcRegId=draft-coretta-x660-ldap,ou=Registry,
ou=X660,dc=example,dc=com
arcRegId: draft-coretta-x660-ldap
cn: draft-coretta-x660-ldap
objectClass: organizationalRole
objectClass: x660ContactEntry
objectClass: top
currentRegAuthorityPostalAddress: 1 Fake St$Palm Springs$
CA$92262
currentRegAuthorityCommonName: Jesse Coretta
currentRegAuthorityEmail: jesse.coretta@icloud.com
currentRegAuthorityMobile: +11234567890
currentRegAuthorityStartTimestamp: 20200229134901Z
sponsorOrg: Sponsor, Co.
sponsorEmail: sponsor@example.com
sponsorMobile: +11234560987
sponsorStartTimestamp: 20010104120144Z
sponsorPostalAddress: 456 Fugazi Ln$Anywhere$CA$92262
firstRegAuthorityPostalAddress: 1 Fake St$Palm Springs$
CA$92262
firstRegAuthorityCommonName: Jesse Coretta
firstRegAuthorityEmail: jesse.coretta@icloud.com
firstRegAuthorityMobile: +11234567890
firstRegAuthorityStartTimestamp: 20200229134901Z
Keeping with the example arc described in Section 3.4.1.1, the
three-dimensional arc entry would manifest as follows:
Coretta Expires November 15, 2021 [Page 43]
Internet-Draft X.660 LDAP Schema and Models May 2021
dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,
dc=example,dc=com
objectClass: x660SubArcEntry
objectClass: top
currentRegAuthority: arcRegId=draft-coretta-x660-ldap,
ou=Registry,ou=X660,dc=example,dc=com
unicodeValue: Jesse Coretta
n: 56521
4. References
4.1. Normative References
[RFC1155] Rose, M., "Structure and Identification of Management
Information for TCP/IP-based Internets", RFC 1155, May
1990.
[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.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4517] Legg, Ed., S., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, June
2006.
[RFC4524] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): COSINE LDAP/X.500 Schema", RFC 4524, June 2006.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[X.660] International Telecommunication Union - Telecommunication
Standardization Sector, "General procedures and top arcs
of the international object identifier tree", ITU-T X.660,
July 2011.
Coretta Expires November 15, 2021 [Page 44]
Internet-Draft X.660 LDAP Schema and Models May 2021
[X.680] International Telecommunication Union - Telecommunication
Standardization Sector, "Abstract Syntax Notation One
(ASN.1): Specification of basic notation", ITU-T X.680,
July 2002.
5. IANA Considerations
There are no requests to IANA in this document.
6. 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.
If some or all of the data in the directory is sensitive in nature,
directory architects MUST take appropriate steps to secure this
information. This concept is out of scope for this document.
Beyond this, there are no specific concerns in the area of security.
Author's Address
Jesse Coretta
Palm Springs, CA 92262
United States
Email: jesse.coretta@icloud.com
Coretta Expires November 15, 2021 [Page 45]