ISO/IEC 29168-1:2023
(Main)Information technology — Open systems interconnection — Part 1: Object identifier resolution system
Information technology — Open systems interconnection — Part 1: Object identifier resolution system
This document specifies the OID resolution system, including the overall architecture and a DNS-based resolution mechanism. It specifies the means for inserting any application-defined information associated with an OID node into the DNS (see clause 6) and the means of retrieval of that information using the ORS (see clause 7). It does not restrict the number of applications it can support. It specifies the required operation of an ORS client (see clause 7), including the mapping of an OID-IRI value by the ORS client into a DNS name to produce a DNS query for the specified application information and the processing of any returned information. The ORS has no role in the allocation or registration of OID nodes. The required behaviour of an ORS client is specified, but the interfaces to it are specified only in terms of the semantics of the interaction. A bit-level application program interface is platform and software dependent, and is not in the scope of this document. A special behaviour of an ORS client is specified to cache OID information in order to reduce the response time of OID resolution. This document also specifies a mechanism to resolve an OID node when one of its superior OID nodes is not ORS-supported. It does not include a tutorial or complete specification on the management of DNS zone files (for that, see IETF RFC 1035 and IETF RFC 3403); it specifies (only) the DNS resource records (see 6.3) that need to be inserted in the zone files in order to support ORS access to the information associated with an OID node. This document specifies required DNS zone file resource records, and prohibits the use of other resource records of a similar form but with different semantics (in DNS zone files in the ORS domain) – see 6.2. It does not otherwise restrict the general use of DNS zone files.
Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Partie 1: Système de résolution d'identificateur d'objet
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29168-1
Second edition
2023-03
Information technology — Open
systems interconnection —
Part 1:
Object identifier resolution system
Technologies de l'information — Interconnexion de systèmes ouverts
(OSI) —
Partie 1: Système de résolution d'identificateur d'objet
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted. This document was drafted in accordance with the editorial
rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs)
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT)
see www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by ITU-T as ITU-T X.672 and drafted in accordance with its editorial rules,
in collaboration with Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee
SC 6, Telecommunications and information exchange between systems.
This second edition cancels and replaces the first edition (ISO/IEC 29168-1:2011), which has been
technically revised.
A list of all parts in the ISO/IEC 29168 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
INTERNATIONAL STANDARD ISO/IEC 29168-1
RECOMMENDATION ITU-T X.672
Information technology – Open systems interconnection –
Object identifier resolution system
Summary
Recommendation ITU-T X.672 | International Standard ISO/IEC 29168-1 specifies the object identifier (OID) resolution
system (ORS). This enables (arbitrary) information to be associated with any ORS-supported OID node (of the
international OID tree defined in Rec. ITU-T X.660 | ISO/IEC 9834-1). This associated information is identified by an
application specification that may have a requirement for instances of that application (running on any computer system)
to obtain the associated information by an ORS search, using an Abstract Syntax Notation One (ASN.1)
OID-internationalized resource identifier value to identify the node.
Currently defined application information for a node includes the canonical form of an international OID, child node
information, registration information about the owner of the node, a reference to an ASN.1 module identified by the node,
information supporting tag-based applications and information supporting cybersecurity.
History
*
Edition Recommendation Approval Study Group Unique ID
1.0 ITU-T X.672 2010-08-29 17 11.1002/1000/10831
2.0 ITU-T X.672 2022-06-06 17 11.1002/1000/14780
Keywords
Object identifier resolution system, object identifier, OID, ORS.
____________________
*
To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11830-en.
Rec. ITU-T X.672 (06/2022) i
© ISO/IEC 2023 – All rights reserved
FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes
the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other
obligatory language such as "must" and the negative equivalents are used to express requirements. The use of
such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS
ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve
the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or
applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of
the Recommendation development process.
As of the date of approval of this Recommendation, ITU had not received notice of intellectual property,
protected by patents/software copyrights, which may be required to implement this Recommendation.
However, implementers are cautioned that this may not represent the latest information and are therefore
strongly urged to consult the appropriate ITU-T databases available via the ITU-T website at
http://www.itu.int/ITU-T/ipr/.
ITU 2023
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.
ii Rec. ITU-T X.672 (06/2022)
© ISO/IEC 2023 – All rights reserved
CONTENTS
Page
1 Scope . 1
2 Normative references. 1
2.1 Identical Recommendations | International Standards . 1
2.2 Additional references . 1
3 Definitions . 2
3.1 Imported definitions . 2
3.2 Additional definitions . 2
4 Abbreviations and acronyms . 4
5 OID resolution system architecture . 5
5.1 OID resolution process . 5
5.2 Interactions between components in the general OID resolution process . 5
6 DNS zone files for the ORS domain. 6
6.1 Overview . 6
6.2 Requirements and restrictions on DNS zone files in the ORS domain . 7
6.3 Use of DNS resource records for ORS services . 7
6.4 Security considerations . 8
7 Operation of an ORS client . 8
7.1 Functional interfaces . 8
7.2 Processing a query . 8
7.3 Converting an OID-IRI value to an FQDN . 8
7.4 Processing DNS results . 9
7.5 Security considerations . 9
7.6 Local performance considerations . 9
8 Requirements for ORS service specifications . 10
8.1 Specification of NAPTR information . 10
8.2 Recommendations for ORS application processing . 10
Annex A – Assigned ORS service types. 11
Annex B – Specification of the canonical OID (COID) ORS service . 12
Annex C – Specification of the child information (CINF) ORS service . 13
C.1 General . 13
C.2 CINF XML file . 13
Annex D – Specification of the registration information (RINF) ORS service . 15
D.1 General . 15
D.2 RINF XML file . 15
Annex E – Specification of the module information (MINF) ORS service . 17
Annex F – Description of use cases . 18
F.1 Canonical OID (COID) ORS service . 18
F.2 Child information (CINF) ORS service . 18
F.3 Registration information (RINF) ORS service . 18
F.4 Module information (MINF) ORS service . 18
Annex G – Examples of ORS operation . 19
G.1 Example of DNS zone files for the ORS . 19
G.2 Examples of NAPTR resource records. 20
Annex H – Implementation guidance for a local cache and copies of ORS zones . 21
H.1 Local cache for OID resolution . 21
H.2 Local copies of ORS zones . 21
H.3 Local copies of ORS zones independent of the local DNS . 21
Annex I – Operational guidance for ORS operators . 23
Annex J – Changes and compatibility of this edition of this Recommendation | International Standard . 24
Rec. ITU-T X.672 (06/2022) iii
© ISO/IEC 2023 – All rights reserved
Page
Annex K – History of object identifiers . 25
Bibliography . 26
iv Rec. ITU-T X.672 (06/2022)
© ISO/IEC 2023 – All rights reserved
Introduction
This Recommendation | International Standard specifies the object identifier (OID) resolution system (ORS). This
provides the return (using an ORS client) of information associated with an OID node.
It uses a mapping of the International OID tree naming scheme (using OID-internationalized resource identifier (OID-IRI)
values) on to the domain name system (DNS) naming scheme (see 7.3).
This Recommendation | International Standard specifies requirements for the management of DNS zone files that are
mapped from ORS-supported OID nodes to provide (standardized) information related to an international OID tree node
for a variety of applications, and on the behaviour of an ORS client that interacts with the DNS system to obtain that
information and provide it to an application.
Six requirements emerged in the mid/late-2000s:
– an application to be able to translate any OID-IRI value into a canonical OID-IRI (a unique string of
numeric Unicode labels that would identify a node): the canonical OID (COID) ORS service, supporting
IRI comparison of names in the IETF "oid" IRI scheme (see Annex B);
– an application to determine child information (CINF) from an OID node: the CINF service (see Annex C);
– an application to obtain registration information (such as contact information about the owner of the OID
node and how to request a child node; RINF): the RINF service (see Annex D);
– an application to obtain a reference to the Abstract Syntax Notation One (ASN.1) module (if any)
associated with a node: the module information (MINF) service (see Annex E);
– support for access to multimedia information (triggered by tag-based identification) using the ORS;
– support for access to information contained in an OID node that relates to cybersecurity features.
Three requirements emerged in 2019-2020:
– enhancement of the local performance of OID resolution to reduce the response time;
– high availability of the ORS;
– resolution of ORS-supported OID nodes for which not all superior OID nodes are ORS supported.
There are probably other applications that will require further information (specified by an application standard) contained
in an ORS-supported OID node and accessible by the ORS.
To meet these needs, it was decided to map the OID tree into a part of the DNS tree (see IETF RFC 1035), with the root
of the international OID tree mapped into .oid-res.org (see 7.3).
The mapping is from any OID-IRI value that identifies an international OID node into a DNS name (in the ORS domain).
The information about an ORS-supported OID node is inserted into DNS zone files and can then be retrieved by any ORS
client (running on any computer system with DNS access), using any of the OID-IRI identifications for that international
OID tree node.
The associated information is specified by those applications that choose to use the ORS. The requirements on such
applications are included in this Recommendation | International Standard. Some application specifications are included
as normative annexes to this Recommendation | International Standard. Others are specified externally.
All DNS zone files for the ORS domain correspond to ORS-supported OID nodes, but not all DNS names algorithmically
mapped from an OID-IRI are present in the DNS. All DNS zone files in the ORS domain are required to conform to this
Recommendation | International Standard.
Information for an international OID tree node (for each application) is specified by the owner of that node, and determines
the appropriate configuration of DNS zone files, in accordance with the specification for each ORS service (see Annex A),
and would be retrieved by an application using a local ORS client implementation interacting with a local DNS client
(see clause 7). The information would be included in naming authority pointer (NAPTR) resource records, qualified by
the ORS service type.
An ORS client takes as input any OID-IRI value, together with an ORS service type. It will return node information for
that OID-IRI value and ORS service type (based on the configuration of the DNS zone files, and particularly of NAPTR
resource records). Each resource record will consist of one or more pieces of information together with the requested ORS
service type.
The procedures for the appointment of the ORS operational agency are contained in ISO/IEC 29168-2. These procedures
involve only ISO/IEC for appointment and contractual purposes. They do not have any ITU-T involvement.
Clause 5 provides an overview of the ORS architecture and its interaction with the DNS.
Rec. ITU-T X.672 (06/2022) v
© ISO/IEC 2023 – All rights reserved
Clause 6 specifies the requirements and restrictions on DNS zone files in the ORS domain in order to support navigation
to DNS names mapped from the international OID tree (including the use of long arcs) and the provision of information
needed for the ORS resolution process using any specified ORS service type.
NOTE – This Specification relates only to the use of delegation name (DNAME) DNS resource records and NAPTR resource
records using a service field commencing "ORS+". Use of other DNS resource records lie outside the scope of this
Recommendation | International Standard, and are neither forbidden (except when they would conflict with the use for the ORS)
nor are they required.
Clause 7 specifies the operation of an ORS client, including the mapping of an OID-IRI value into a DNS name.
Clause 8 specifies the requirements for an ORS application specification, including specification of NAPTR information
and recommendations on ORS application processing.
Security considerations are discussed and specified in 5.2.3 to 5.2.6, 6.4, 7.5 and 8.2.2.
Annex A (normative) specifies the assigned ORS service types at the time of publication of this Recommendation |
International Standard.
Annex B (normative) specifies the COID service.
Annex C (normative) specifies the requirements for the CINF service.
Annex D (normative) specifies the requirements for the RINF service.
Annex E (normative) specifies the requirements for the MINF service.
Annex F (informative) provides a description of the use cases for the ORS, referencing each application that has a
specified ORS service type (see Annex A).
Annex G (informative) provides examples of possible DNS zone files to support the ORS and additional examples of
NAPTR resource records.
Annex H (informative) provides implementation guidance for a local cache and copies of ORS zones.
Annex I (informative) provides operational guidance for ORS operators.
Annex J (informative) explains the changes introduced in this edition of this Recommendation | International Standard.
Annex K (informative) provides a short history of the development of the international OID tree.
Annex L (informative) provides bibliographic references.
vi Rec. ITU-T X.672 (06/2022)
© ISO/IEC 2023 – All rights reserved
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology – Open systems interconnection –
Object identifier resolution system
1 Scope
This Recommendation | International Standard specifies the object identifier (OID) resolution system (ORS), including
the overall architecture and a resolution mechanism based on the domain name system (DNS).
This Recommendation | International Standard specifies the means for inserting any application-defined information
associated with an OID node into the DNS (see clause 6) and the means of retrieval of that information using the ORS
(see clause 7).
This Recommendation | International Standard does not restrict the number of applications it can support.
This Recommendation | International Standard specifies the required operation of an ORS client (see clause 7), including
the mapping of an OID-IRI value by the ORS client into a DNS name to produce a DNS query for the specified application
information and the processing of any returned information. The ORS has no role in the allocation or registration of OID
nodes.
The required behaviour of an ORS client is specified, but the interfaces to it are specified only in terms of the semantics
of the interaction. A bit-level application program interface is platform and software dependent, and lies outside the scope
of this Recommendation | International Standard.
A special behaviour of an ORS client is specified to cache OID information in order to reduce the response time of OID
resolution. This Recommendation | International Standard also specifies a mechanism to resolve an OID node when one
of its superior OID nodes is not ORS supported.
This Recommendation | International Standard does not include a tutorial or complete specification on the management
of DNS zone files (for that, see IETF RFC 1035 and IETF RFC 3403); it specifies (only) the DNS resource records (see
6.3) that need to be inserted in the zone files in order to support ORS access to the information associated with an OID
node.
This Recommendation | International Standard specifies required DNS zone file resource records, and prohibits the use
of other resource records of a similar form but with different semantics (in DNS zone files in the ORS domain) – see 6.2.
It does not otherwise restrict the general use of DNS zone files.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition
of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently valid
International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid
ITU-T Recommendations.
2.1 Identical Recommendations | International Standards
– Recommendations ITU-T X.660 (2011) | ISO/IEC 9834-1:2012, Information technology – Procedures for
the operation of object identifier registration authorities: General procedures and top arcs of the
international object identifier tree.
– Recommendation ITU-T X.693 (2021) | ISO/IEC 8825-4:2021, Information technology – ASN.1 encoding
rules: XML Encoding Rules (XER).
2.2 Additional references
– Recommendation ITU-T X.675 (2015), OID-based resolution framework for heterogeneous identifiers
and locators.
– IETF RFC 1034 (1987), Domain names – Concepts and facilities.
Rec. ITU-T X.672 (06/2022) 1
© ISO/IEC 2023 – All rights reserved
– IETF RFC 1035 (1987), Domain names – Implementation and specification.
– IETF RFC 3403 (2002), Dynamic delegation discovery system (DDDS) – Part Three: The domain name
system (DNS) database.
– IETF RFC 3490 (2003), Internationalizing domain names in applications (IDNA).
– IETF RFC 3492 (2003), Punycode: A bootstring encoding of Unicode for internationalized domain names
in applications (IDNA).
– IETF RFC 4033 (2005), DNS security introduction and requirements.
– IETF RFC 5155 (2008), DNS security (DNSSEC) hashed authenticated denial of existence.
NOTE – It is recommended that the IETF RFC index be consulted for updates to its entries listed in this clause.
– IETF RFC 7564 (2015), PRECIS framework: Preparation, enforcement, and comparison of
internationalized strings in application protocols.
– Unicode Consortium (2021). Unicode standard, Version 14.0.0. Mountain View, CA: Unicode
Consortium. Available [viewed 2022-07-27] at: https://www.unicode.org/versions/Unicode14.0.0/UnicodeStandard-
14.0.pdf.
3 Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply.
3.1 Imported definitions
This Recommendation | International Standard uses the following terms defined in Rec. ITU-T X.660 | ISO/IEC 9834-1:
a) object identifier;
b) integer-valued Unicode label;
c) international object identifier tree;
d) long arc;
e) OID-internationalized resource identifier;
f) Registration Authority;
g) Unicode label.
3.2 Additional definitions
3.2.1 application-specific OID resolution process: Actions by an application to retrieve application-specific
information from the information returned by the general OID resolution process.
3.2.2 AXFR: DNS zone transfer protocol.
NOTE – See IETF RFC 5936.
3.2.3 canonical form (of an OID-IRI): A form which uses only integer-valued Unicode labels.
NOTE – An OID-IRI is an ASN.1 type defined in Rec. ITU-T X.680 | ISO/IEC 8824-1. The term OID-IRI value refers to the
ASN.1 value notation that is the same as the Internet Assigned Numbers Authority (IANA) "oid:" internationalized resource
identifier/uniform resource identifier (IRI/URI) scheme, with the omission of the initial "oid:".
3.2.4 delegation name (DNAME): A DNS resource record used to create an alias for a domain name and all of its
subdomains.
3.2.5 DNS delegation: The process to create a separate zone in the DNS name space beneath the top name of a given
domain.
NOTE 1 – See IETF RFC 7719.
NOTE 2 - Delegation happens when a name server RRset is added in the parent zone for the child origin, which is the domain name
that appears at the top of the child zone.
3.2.6 DNS-mapped name: The result of transforming an OID-IRI value to an FQDN.
NOTE 1 – See 7.3.
NOTE 2 – The DNS-mapped name may not exist in the DNS. If it does not, then an ORS query will result in an error message (see
7.4) and the node identified by the OID-IRI is not ORS supported.
2 Rec. ITU-T X.672 (06/2022)
© ISO/IEC 2023 – All rights reserved
3.2.7 DNS name server (NS): A DNS resource record providing the authoritative name server for a domain.
3.2.8 DNS resource record: A component of a DNS zone file.
3.2.9 DNS zone file: A text file that describes a portion of the DNS.
NOTE – The format of a DNS zone file is specified in section 5 of IETF RFC 1035 and section 3.6.1 of IETF RFC 1034.
3.2.10 fully qualified domain name: The name used in a DNS look-up operation.
NOTE – See IETF RFC 1594.
3.2.11 general OID resolution process: That part of the ORS where an ORS client obtains information from the DNS
(recorded in a zone file) about any specified OID and returns it to an application.
3.2.12 local cache: A DNS cache server which synchronizes and hosts an ORS zone locally, based on a local
configuration.
3.2.13 local resolution: ORS resolution using a local cache.
3.2.14 NAPTR resource record: A DNS resource record used to store rules which can be retrieved by a DNS look-
up for use by an application.
3.2.15 OID resolution process: Process which provides information associated with an OID.
NOTE – This information can be application-specific (see Figure 1 and the annexes).
3.2.16 OID resolution system: Implementation of the OID resolution process in accordance with this
Recommendation | International Standard.
3.2.17 operational agency procedure: The specification of an action required by the .oid-res.org operational agency.
3.2.18 ORS client: Entity that interfaces between an application and a DNS client.
3.2.19 ORS domain: The .oid-res.org domain.
3.2.20 ORS root: OID resolution system hosted at the ORS domain.
3.2.21 ORS root operational agency: Organization that manages the DNS server for the ORS root and some
subordinate nodes.
3.2.22 ORS service: A character string (used in NAPTR resource records) that identifies an ORS service.
NOTE – see Annex A.
3.2.23 ORS-supported OID node: An OID node for which the DNS-mapped names for all of the OID-IRI values that
identify the OID node exist in the DNS, and have all necessary DNS zone files configured as specified in this
Recommendation | International Standard, including mandatory requirements for all ORS services.
NOTE 1 – See Annex A.
NOTE 2 – The canonical OID service specified in Annex B requires the presence of a NAPTR record in the associated DNS zone
file.
NOTE 3 – The ORS root operational agency is required by the operational procedures to provide ORS support for all the OID
nodes listed in those procedures. ORS support for nodes beneath these depends on agreements between that OID node and its parent
or one of its superior OID nodes, which is able to set up a delegation for that OID node.
3.2.24 ORS zone: Part of a DNS zone containing authoritative information about one or more OID nodes.
NOTE 1 – For DNS zone, see section 2.4 of IETF RFC 1034.
3.2.25 parent OID node: The OID node that is immediately above an OID node towards the root of the international
object identifier tree.
3.2.26 resource record set (RRset): A set of resource records with the same label, class and type, but with different
data.
NOTE 1 – See IETF RFC 7719.
3.2.27 secondary server (slave): An authoritative server which uses zone transfer to retrieve the zone.
NOTE – See section 2.1 of IETF RFC 1996.
3.2.28 superior OID node: Any OID node that is above an OID node (including its parent OID) towards the root of
the international object identifier tree.
Rec. ITU-T X.672 (06/2022) 3
© ISO/IEC 2023 – All rights reserved
4 Abbreviations and acronyms
This Recommendation uses the following abbreviations and acronyms:
ASN.1 Abstract Syntax Notation One
ASCII American Standard Code for Information Interchange
CD Checking Disabled
CINF Child Information
COID Canonical OID
CYBEX Cybersecurity Exchange information
DNAME Delegation Name
DNS Domain Name System
DNSSEC Domain Name System Security
DO DNS security OK
FQDN Fully Qualified Domain Name
HTTPs Hypertext Transfer Protocol secure
IRI Internationalized Resource Identifier
ISP Internet Service Provider
LINF Locator Information
MINF Module Information
NAPTR Naming Authority Pointer
NFKC Normalization Form KC
NS Name Server
OID Object Identifier
OID-IRI OID-Internationalized Resource Identifier
ORS OID Resolution System
RCODE Return Code
RINF Registration Information
RRset Resource Record set
sFTP secure File Transfer Protocol
SOA Start Of Authority
TINF Tag-based multimedia access Information
UINF URI Information
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML Extensible Markup Language
XSD XML Schema Definition
4 Rec. ITU-T X.672 (06/2022)
© ISO/IEC 2023 – All rights reserved
5 OID resolution system architecture
5.1 OID resolution process
5.1.1 The OID resolution process is illustrated in Figure 1. It consists of two processes: a general OID resolution
process; and an application-specific OID resolution process.
5.1.2 The general OID resolution process uses the DNS (see IETF RFC 1035) and DNS resource records (see
IETF RFC 3403). It involves an interaction between the application and an ORS client to retrieve information (specified
by that application) from the DNS system. The general OID resolution process normally returns a uniform resource locator
(URL) for a document, a canonical OID-IRI or a DNS name, but there is no restriction on what could be returned. This
is usually followed by an application-specific OID resolution process, where the application uses the information obtained
from the general resolution process to obtain the final information required by the application.
NOTE – For some services, e.g., the canonical OID (COID) service (see Annex B), the information returned from the ORS client
will be sufficient, and there will be no application-specific OID resolution process.
OID-IRI + ORS service type
+ security flag
General OID resolution
process DNS NAPTR resource records
DNS with zone files
(1)
for ORS support
Application
(2) Application-specific request
Application-specific OID Application-specific
Application-specific information
resolution process servers
X.672(10)_F01
Figure 1 – OID resolution process
5.2 Interactions between components in the general OID resolution process
5.2.1 Figure 2 shows the functional interfaces between the components of the general OID resolution process and the
semantics of the interactions. Bit-level encoding of these interfaces and interactions is platform and software dependent,
and lies outside the scope of this Recommendation | International Standard. The realization of this architecture in hardware
or software and its partitioning into separate modules is not constrained by this Recommendation | International Standard.
ORS client interface DNS client interface
(1) OID-IRI + ORS service type (2) OID-IRI as an FQDN
+ security flag + security parameters
Application
ORS client DNS client DNS
(3) 0 or more NAPTR
(4) 0 or more of (ORS
resource records or error
information of the specified
service type + preference
values) or error
X.672(10)_F02
Figure 2 – Components of the general OID resolution system
5.2.2 There are three main actors: the application; an ORS client; and the DNS system.
Rec. ITU-T X.672 (06/2022) 5
© ISO/IEC 2023 – All rights reserved
5.2.3 (Step 1) The application makes a request to the ORS client for information about an OID, giving one of the
OID-IRI values that identifies that OID node and the ORS service type that it is interested in (see Annex A). It also sets
a security flag, which determines whether a domain name system security (DNSSEC) extension – if available – is to be
used (see 5.2.4).
NOTE 1 – The application has to trust the ORS client and the DNS client to pass on the security flag setting, and for the DNS
servers to correctly implement IETF RFC 4033 and IETF RFC 5155 (NSEC3). If the application does not trust the ORS client or
the DNS client that it is using, it should not set the security flag, as it will not provide any security benefit.
NOTE 2 – It is a requirement of the operational agency procedures that the ORS root operational agency provide full support for
security as required by IETF RFC 4033 and IETF RFC 5155.
5.2.4 (Step 2) The ORS client transforms the OID-IRI value into an FQDN as specified in 7.3 and sends a query
request to a DNS client for NAPTR resource records containing the requested ORS information type, as specified in 7.2.
If the security flag is 1, then the DNS security OK (DO) parameter of the DNS query request shall be 1 and the checking
disabled (CD) parameter shall be 0 (specified in IETF RFC 4033); otherwise, the DO and CD parameters are not passed.
5.2.5 (Step 3) The DNS client returns either zero or more NAPTR resource records, or an error (specified as a non-
zero DNS return code (RCODE) – see IETF RFC 1035).
5.2.6 (Step 4) The ORS client processes the NAPTR resource records as specified in 7.4 and returns to the application
zero or more information fields with preference values, and the DNS RCODE (the appropriate interpretation of the
RCODE is given in Table 1). If the security flag was 1 (see 5.2.4), then only NAPTR resource records with an
authenticated data flag (specified in IETF RFC 4033) set to 1 are returned; otherwise, all NAPTR resource records are
returned.
Table 1 – Interpretation of DNS RCODE values
RCODE value Interpretation by the application
0 OK
1 ORS system failure
2 DNS system failure
3 No such domain name
Retrieval of NAPTR resource records not supported for this domain name (the DNS is not correctly configured
for ORS-support of this OID-IRI value)
5 Security policy restriction
6 upwards No interpretation available
6 DNS zone files for the ORS domain
6.1 Overview
NOTE – This Recommendation | International Standard does not provide a tutorial. A complete specification on the use of DNS
zone files lies outside the scope of this Recommendation | International Standard. It is assumed that zone file managers supporting
the ORS will understand such issues.
6.1.1 An OID node may not be ORS supported.
6.1.2 For an OID node to be ORS supported, all its DNS-mapped names have to be available for retrieval of
information from DNS zone files. The DNS-mapped names of an OID node can be either listed in the zone of its parent
OID node or listed in its own zone if the owner of the OID node decides to administer the ORS-supported DNS zone
itself (see clause 6.2.5 about the requirement for zone delegation in an ORS).
NOTE – The DNS is designed to allow divisions between the name hierarchy and the DNS authority structure to be created. The
hierarchy DNS authority (zone) is not necessarily the same as the DNS name hierarchy. A more flattened structure of a DNS/ORS
authority will make the OID resolution more efficient (an example is shown in Annex G).
6.1.3 If an OID node is not ORS supported, any ORS query using some of the OID-IRI values that identify that OID
node should return a DNS RCODE value of 3 (no such domain name), and information associated with that OID node
cannot be obtained by an ORS query to an ORS client. Its parent OID node may not be ORS supported.
6.1.4 If the OID node is ORS supported, any of its DNS-mapped names can be used to obtain NAPTR resource
records. Each of its child OID nodes may not be ORS supported.
6.1.5 The ORS root operational agency manages and maintains the DNS zone files corresponding to the OID nodes
of the OID tree specified in the operational agency procedures in accordance with 6.2.
6 Rec. ITU-T X.672 (06/2022)
© ISO/IEC 2023 – All rights reserved
NOTE – This means that all those OID nodes are ORS supported.
6.1.6 The ORS root operational agency is required (by operational agency procedures) to add an NS resource record
for any child OID node (of any OID node that it supports) if that child OID node wishes to become ORS supported. Any
child OID node that wishes to become ORS supported shall arrange for the management of the corresponding DNS zone
files in accordance with 6.2.
6.1.7 Any OID node that is not one of those supported by the ORS root operational agency, but which is itself ORS
supported, shall determine by mutual agreement between that OID node and each of its child OID nodes whether the child
becomes ORS supported. The requirements of 6.2 shall then be recursively applied.
6.1.8 The requirements to use DNAME resource records (as specified in 6.2) ensure that there is only a single DNS
zone file accessed for the return of NAPTR resource records for all the ORS queries that use any of the OID-IRI values
that identify an ORS-supported OID node.
6.1.9 Any OID node whose parent is not ORS supported can still implement the ORS with the help of one of its
superior ORS-supported nodes. An example is given in Figure G.2. To avoid false information being published in the
ORS, the inferior OID node should provide proof of ownership of the corresponding OID. The superior node is
responsible for deciding what kind of proof is acceptable. The proof of ownership should include full path registration
information (RINF) down to the inferior OID node.
NOTE – There should be an agreement between the node whose parent is not ORS supported and its superior ORS-supported
nodes. The nature of the agreement lies outside the scope of this Recommendation | International Standard.
6.1.10 In order to enhance the high availability of the ORS root, the ORS root operational agency can implement
secondary servers.
6.2 Requirements and restrictions on DNS zone files in the ORS domain
6.2.1 These requirements are placed on the ORS root operational agency (and recursively on all DNS zone files in
the ORS domain).
6.2.2 Names in the ORS domain shall not be allocated unless they are DNS-mapped names.
6.2.3 All DNS zone files in the ORS domain shall (with appropriate use of DNAME resource records as specified in
6.3) support DNS queries using any of the Unicode labels on the arcs leading to an ORS-supported OID node.
6.2.4 A DNS zone f
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...