[要約] RFC 9090は、オブジェクト識別子のためのCBORタグを定義します。この文書の目的は、効率的なバイナリ形式での識別子の表現を可能にすることです。利用場面には、セキュリティプロトコルやデータ交換フォーマットの最適化が含まれます。
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 9090 Universität Bremen TZI
Category: Standards Track July 2021
ISSN: 2070-1721
Concise Binary Object Representation (CBOR) Tags for Object Identifiers
オブジェクト識別子のための簡潔なバイナリオブジェクト表現（CBOR）タグ
Abstract
概要
The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
RFC 8949で定義されている簡潔なバイナリオブジェクト表現（CBOR）は、設計目標には、極めて小さいコードサイズ、かなり小さなメッセージサイズ、およびバージョンネゴシエーションを必要とせずに拡張性が含まれています。
This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.
この文書は、オブジェクト識別子（OID）のためのCBORタグを定義し、そのように定義されたCBORタグのIANA登録のための参照文書です。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9090.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9090で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
2. Object Identifiers
2.1. Requirements on the Byte String Being Tagged
2.2. Preferred Serialization Considerations
2.3. Discussion
3. Basic Examples
3.1. Encoding of the SHA-256 OID
3.2. Encoding of a MIB Relative OID
4. Tag Factoring with Arrays and Maps
4.1. Preferred Serialization Considerations
4.2. Tag Factoring Example: X.500 Distinguished Name
5. CDDL Control Operators
6. CDDL Type Names
7. IANA Considerations
7.1. CBOR Tags
7.2. CDDL Control Operators
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Author's Address
The Concise Binary Object Representation (CBOR) [RFC8949] provides for the interchange of structured data without a requirement for a pre-agreed schema. [RFC8949] defines a basic set of data types, as well as a tagging mechanism that enables extending the set of data types supported via an IANA registry.
簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]は、事前合意されたスキーマに対する要件なしに構造化データの交換を提供します。[RFC8949]データ型の基本的なセットと、IANAレジストリを介してサポートされているデータ型のセットを拡張できるタグ付けメカニズムを定義します。
This document defines CBOR tags for object identifiers (OIDs) [X.660], which many IETF protocols carry. The ASN.1 Basic Encoding Rules (BER) [X.690] specify binary encodings of both (absolute) object identifiers and relative object identifiers. The contents of these encodings (the "value" part of BER's type-length-value structure) can be carried in a CBOR byte string. This document defines two CBOR tags that cover the two kinds of ASN.1 object identifiers encoded in this way and a third one to enable a common optimization. The tags can also be applied to arrays and maps to efficiently tag all elements of an array or all keys of a map. This document is the reference document for the IANA registration of the tags so defined.
このドキュメントは、オブジェクト識別子（OID）[X.660]のCBORタグを定義しています。その多くのIETFプロトコルはキャリーです。ASN.1基本エンコーディング規則（BER）[X.690]は、両方の（絶対）オブジェクト識別子と相対オブジェクト識別子のバイナリエンコードを指定します。これらのエンコーディングの内容（BERのType-Length-Value-Value構造の "値）は、CBOBORバイト文字列で実行できます。このドキュメントでは、この方法で符号化された2種類のASN.1オブジェクト識別子をカバーする2つのCBORタグと、共通の最適化を可能にするための3番目のCBORタグが定義されています。タグを配列およびマッピングして、マップのアレイまたはすべてのキーのすべての要素を効率的にタグにタグを付けることもできます。この文書は、定義されたタグのIANA登録のための参照文書です。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The terminology of [RFC8949] applies; in particular, the term "byte" is used in its now-customary sense as a synonym for "octet". The verb "to tag (something)" is used to express the construction of a CBOR tag, with the object (something) as the tag content and a tag number indicated elsewhere in the sentence (for instance, in a "with" clause or by the shorthand "an NNN tag" for "a tag with tag number NNN"). The term "SDNV" (Self-Delimiting Numeric Value) is used as defined in [RFC6256], with the additional restriction detailed in Section 2.1 (no leading zeros).
[RFC8949]の用語が適用されます。特に、「バイト」という用語は、「オクテット」の同義語として、現在慣習的な意味で使用されています。「タグへのタグ（何か）」は、CBOBORタグの構築をタグの内容として（何か）、および文の他の場所で示されたタグ番号（たとえば、 "with"句で）を表現するために使用されます。「タグ番号NNNのタグ」の略「NNNタグ」である。「SDNV」（自己区切り数値）という用語は、[RFC6256]で定義されているとおりで、セクション2.1（主要ゼロなし）に詳述されている追加の制限があります。
The International Object Identifier tree [X.660] is a hierarchically managed space of identifiers, each of which is uniquely represented as a sequence of unsigned integer values [X.680]. (These integer values are called "primary integer values" in [X.660] because they can be accompanied by (not necessarily unambiguous) secondary identifiers. We ignore the latter and simply use the term "integer values" here, occasionally calling out their unsignedness. We also use the term "arc" when the focus is on the edge of the tree labeled by such an integer value, as well as in the sense of a "long arc", i.e., a (sub)sequence of such integer values.)
国際オブジェクト識別子ツリー[X.660]は、識別子の階層的に管理されたスペースであり、それぞれの符号なし整数値のシーケンスとして一意に表されます[X.680]。（これらの整数値は、必ずしも明白な識別ではない）2次識別子を伴うことができるため、「1次整数値」と呼ばれます。後者を無視し、ここで「整数値」という用語を使用してください。網状。また、焦点がそのような整数値でラベル付けされたツリーの端、ならびに「長い弧」、すなわちそのような整数の（サブ）シーケンスの意味でも、「ARC」という用語を使用します。値。）
While these sequences can easily be represented in CBOR arrays of unsigned integers, a more compact representation can often be achieved by adopting the widely used representation of object identifiers defined in BER; this representation may also be more amenable to processing by other software that makes use of object identifiers.
これらのシーケンスは符号なし整数のCBORアレイで容易に表現することができるが、BERで定義されたオブジェクト識別子の広く使用されている表現を採用することによって、よりコンパクトな表現がしばしば達成され得る。この表現は、オブジェクト識別子を利用する他のソフトウェアによる処理にも適している可能性があります。
BER represents the sequence of unsigned integers by concatenating self-delimiting representations [RFC6256] of each of the integer values in sequence.
BERは、順番に各整数値の自己区切り表現[RFC6256]を連結することによって、符号なし整数のシーケンスを表します。
ASN.1 distinguishes absolute object identifiers (ASN.1 type "OBJECT IDENTIFIER"), which begin at a root arc ([X.660], Clause 3.5.21), from relative object identifiers (ASN.1 type "RELATIVE-OID"), which begin relative to some object identifier known from context ([X.680], Clause 3.8.63). As a special optimization, BER combines the first two integers in an absolute object identifier into one numeric identifier by making use of the property of the hierarchy that the first arc has only three integer values (0, 1, and 2) and the second arcs under 0 and 1 are limited to the integer values between 0 and 39. (The root arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) If X and Y are the first two integer values, the single integer value actually encoded is computed as:
ASN.1は、Root Arc（[X.660]、3.5.21項）から始まるAbsoluteオブジェクト識別子（ASN.1 "オブジェクト識別子"）を相対オブジェクト識別子（ASN.1 type "alid-oidと区別します。"）。これは、コンテキストから知られているいくつかのオブジェクト識別子（[X.680]、3.8.63）を基準にしています。特別な最適化として、BERは、最初のアークが3つの整数値（0,1、および2）しかない階層のプロパティを使用して、絶対オブジェクト識別子内の最初の2つの整数を1つの数値識別子に組み合わせています（0,1,2）と2番目の円弧0と1の下は、0から39の間の整数値に制限されています。（ルートアーク "ジョイントISO-ITU-T（2）"はその2番目の円弧にそのような制限はありません。）xとyが最初の2つの整数値、実際にエンコードされた単一の整数値は次のように計算されます。
X * 40 + Y
X * 40 Y
The inverse transformation (again making use of the known ranges of X and Y) is applied when decoding the object identifier.
オブジェクト識別子を復号するときに、逆変換（XおよびYの既知の範囲を利用する）が適用される。
Since the semantics of absolute and relative object identifiers differ and since it is very common for companies to use self-assigned numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number OID [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded OID value, this specification defines three tags, collectively called the "OID tags" here:
絶対オブジェクト識別子のセマンティクスは異なるため、ARC「1.3.6.1.4.1」（IANAプライベートエンタープライズ番号OID [IANA.ENTERPRISE番号]）の下に自己割り当て番号を使用することが一般的であるため、5エンコードされたOID値への固定バイト、この仕様は3つのタグを定義し、まとめて「OIDタグ」と呼びます。
Tag number 111: Used to tag a byte string as the BER encoding [X.690] of an absolute object identifier (simply "object identifier" or "OID").
タグ番号111：絶対オブジェクト識別子のBERエンコーディング[X.690]としてバイト文字列をタグ付けするために使用されます（単に「オブジェクト識別子」または「OID」）。
Tag number 110: Used to tag a byte string as the BER encoding [X.690] of a relative object identifier (also called "relative OID"). Since the encoding of each number is the same as for Self-Delimiting Numeric Values (SDNVs) [RFC6256], this tag can also be used for tagging a byte string that contains a sequence of zero or more SDNVs (or a more application-specific tag can be created for such an application).
タグ番号110：相対オブジェクト識別子のBERエンコーディング[X.690]としてバイト文字列をタグ付けするために使用されます（「Relative OID」とも呼ばれます）。各数の符号化は、自己区切り数値（SDNV）[RFC6256]と同じであるため、このタグは、ゼロ以上のSDNV（またはより多くのアプリケーション固有）を含むバイト文字列をタグ付けするためにも使用できます。そのようなアプリケーションのためにタグを作成することができます）。
Tag number 112: Structurally like tag 110 but understood to be relative to "1.3.6.1.4.1" (IANA Private Enterprise Number OID [IANA.enterprise-numbers]). Hence, the semantics of the result are that of an absolute object identifier.
タグ番号112：タグ110のように構造的には「1.3.6.1.4.1」（IANA民間企業番号OID [IANA.Enterprise-Numbers]）に対するものであると理解されている。したがって、結果のセマンティクスは絶対オブジェクト識別子の意味です。
To form a valid tag, a byte string tagged with 111, 110, or 112 MUST be syntactically valid contents (the value part) for a BER representation of an object identifier (see Table 1):
有効なタグを形成するには、111,110、または112をタグ付けしたバイト文字列は、オブジェクト識別子のBER表現の構文的に有効な内容（値部分）でなければなりません（表1参照）。
+============+====================+
| Tag number | Section of [X.690] |
+============+====================+
| 111 | 8.19 |
+------------+--------------------+
| 110 | 8.20 |
+------------+--------------------+
| 112 | 8.20 |
+------------+--------------------+
Table 1: Tag Number and Section of X.690 Governing Tag Content
表1：X.690のタグ番号とセクションを管理する
This is a concatenation of zero or more SDNV values, where each SDNV value is a sequence of one or more bytes that all have their most significant bit set, except for the last byte, where it is unset. Also, the first byte of each SDNV cannot be a leading zero in SDNV's base-128 arithmetic, so it cannot take the value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]).
これは0個以上のSDNV値の連結です。ここで、各SDNV値は、最後のバイトを除いて、最後のバイトを除いてすべてのビットセットを持つ1つ以上のバイトのシーケンスです。また、SDNVのBase 128演算では、各SDNVの最初のバイトを先行ゼロにすることはできませんので、0x80（x.690のセクション8.1.2.2.4.2）に値0x80（セクション（C））を取得できません。
In other words:
言い換えると：
* The byte string's first byte, and any byte that follows a byte that has the most significant bit unset, MUST NOT be 0x80 (this requirement requires expressing the integer values in their shortest form, with no leading zeroes).
* バイト文字列の最初のバイト、および最上位ビット設定解除を持つバイトに続くバイトは、0x80にしてはいけません（この要件では、先頭のゼロなしで、最短の形式で整数値を表現する必要があります）。
* The byte string's last byte MUST NOT have the most significant bit set (this requirement excludes an incomplete final integer value).
* バイト文字列の最後のバイトには、最上位ビットセットが必要ありません（この要件は不完全な最終整数値を除外します）。
If either of these invalid conditions are encountered, the tag is invalid.
これらの無効な条件のいずれかが発生した場合、タグは無効です。
[X.680] restricts RELATIVE-OID values to having at least one arc, i.e., their encoding would have at least one SDNV. This specification permits empty relative object identifiers; they may still be excluded by application semantics.
[X.680]少なくとも1つの円弧、すなわちそれらの符号化は少なくとも1つのSDNVを有することに相対的なOID値を制限する。この仕様では、空の相対オブジェクト識別子が許可されています。それらはまだアプリケーションセマンティクスによって除外されるかもしれません。
To facilitate the search for specific object ID values, it is RECOMMENDED that definite length encoding (see Section 3.2.3 of [RFC8949]) be used for the byte strings that are used as tag content for these tags.
特定のオブジェクトID値の検索を容易にするために、これらのタグのタグコンテンツとして使用されるバイト文字列には、明確な長さのエンコーディング（[RFC8949]のセクション3.2.3を参照）を使用することをお勧めします。
The valid set of byte strings can also be expressed using regular expressions on bytes, using no specific notation but resembling Perl Compatible Regular Expressions [PCRE]. Unlike typical regular expressions that operate on character sequences, the following regular expressions take bytes as their domain, so they can be applied directly to CBOR byte strings.
有効なバイト文字列のセットは、特定の表記を使用して正規表現を使用して、PERL互換の正規表現[PCRE]に似ています。文字シーケンスで動作する標準的な正規表現とは異なり、次の正規表現はドメインとしてバイトを取りますので、CBORバイト文字列に直接適用できます。
For byte strings with tag 111:
タグ111を使用したバイト文字列の場合：
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/"
For byte strings with tags 110 or 112:
タグ110または112のバイト文字列の場合：
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/"
A tag with tagged content that does not conform to the applicable regular expression is invalid.
適用される正規表現に準拠していないタグ付きコンテンツを持つタグが無効です。
For an absolute OID with a prefix of "1.3.6.1.4.1", representations with both the 111 and 112 tags are applicable, where the representation with 112 will be five bytes shorter (by leaving out the prefix h'2b06010401' from the enclosed byte string). This specification makes that shorter representation the preferred serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that this also implies that the Core Deterministic Encoding Requirements (Section 4.2.1 of [RFC8949]) require the use of 112 tags instead of 111 tags wherever that is possible.
「1.3.6.1.4.1」の接頭辞を持つ絶対OIDの場合、111と112のタグの両方を持つ表現が適用されます。ここで、112の表現は短く5バイト短くなります（プレフィックスH'2B06010401 'を囲んで除外することによって）。バイト文字列）。この仕様は、より短い表現に好ましいシリアル化を表します（[RFC8949のセクション3.4と4.1）。これにより、コア決定論的エンコーディング要件（[RFC8949]のセクション4.2.1）が可能な限り111タグの代わりに112タグを使用する必要があることに注意してください。
Staying close to the way object identifiers are encoded in ASN.1 BER makes back-and-forth translation easy; otherwise, we would choose a more efficient encoding. Object identifiers in IETF protocols are serialized in dotted decimal form or BER form, so there is an advantage in not inventing a third form. Also, expectations of the cost of encoding object identifiers are based on BER; using a different encoding might not be aligned with these expectations. If additional information about an OID is desired, lookup services such as the OID Resolution Service (ORS) [X.672] and the OID Repository [OID-INFO] are available.
ASN.1 BERでオブジェクト識別子がエンコードされている方法の近くに滞在すると、事後翻訳が簡単になります。それ以外の場合は、より効率的なエンコーディングを選択します。IETFプロトコルのオブジェクト識別子は、点線の10進形式またはBER形式でシリアル化されているため、3番目のフォームを発明しないという利点があります。また、オブジェクト識別子を符号化するコストの期待はBERに基づいている。別のエンコーディングを使用すると、これらの期待とは整列されない可能性があります。OIDに関する追加情報が必要な場合は、OID解決サービス（ORS）[X.672]などのルックアップサービスとOIDリポジトリ[OID-INFO]などの検索サービスがあります。
This section gives simple examples of an absolute and a relative object identifier, represented via tag numbers 111 and 110, respectively.
このセクションでは、それぞれタグ番号111および110を介して表される絶対オブジェクト識別子の簡単な例をそれぞれ説明します。
ASN.1 Value Notation:
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) sha256(1) }
Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1
点線10進表記：2.16.840.1.101.3.4.2.1
06 # UNIVERSAL TAG 6 09 # 9 bytes, primitive 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 # | 840 1 | 3 4 2 1 show component encoding # 2.16 101
06＃ユニバーサルタグ6 09＃9バイト、プリミティブ60 86 48 01 65 03 04 02 01＃x.690第8.19＃|840 1 |3 4 2 1コンポーネントエンコーディング＃2.16 101
Figure 1: SHA-256 OID in BER
図1：SHA-256 BERのOID
D8 6F # tag(111)
49 # 0b010_01001: mt 2, 9 bytes
60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19
Figure 2: SHA-256 OID in CBOR
図2：CBORのSHA-256 OID
Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" [RFC7388]), to which the following is added:
いくつかのOID（例えば、「lowpanmib」は、1.3.6.1.2.1.226 "[RFC7388]）であると仮定されています。
ASN.1 Value Notation:
{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }
Dotted Decimal Notation: .1.1.29
点線10進表記：.1.1.29
0D # UNIVERSAL TAG 13 03 # 3 bytes, primitive 01 01 1D # X.690 Clause 8.20 # 1 1 29 show component encoding
0D＃ユニバーサルタグ13 03＃3バイト、プリミティブ01 01 1D＃x.690第8章8.20＃1 1 29コンポーネントエンコーディング
Figure 3: MIB Relative Object Identifier in BER
図3：BERのMIB相対オブジェクト識別子
D8 6E # tag(110)
43 # 0b010_00011: mt 2 (bstr), 3 bytes
01 01 1D # X.690 Clause 8.20
Figure 4: MIB Relative Object Identifier in CBOR
図4：CBORのMIB相対オブジェクト識別子
This relative OID saves seven bytes compared to the full OID encoding.
この相対OIDは、フルOIDエンコードと比較して7バイトを保存します。
The tag content of OID tags can be byte strings (as discussed above) but also CBOR arrays and maps. The idea in the latter case is that the tag construct is factored out from each individual item in the container; the tag is placed on the array or map instead.
OIDタグのタグ内容は、（上記のように）バイト文字列だけでなく、CBOR配列およびマップもできます。後者の場合の考えは、タグ構成がコンテナ内の各個々の項目から算出されることである。タグは代わりに配列またはマップに配置されます。
When the tag content of an OID tag is an array, this means that the respective tag is imputed to all elements of the array that are byte strings, arrays, or maps. (There is no effect on other elements, including text strings or tags.) For example, when the tag content of a 111 tag is an array, every array element that is a byte string is an OID, and every element that is an array or map is, in turn, treated as discussed here.
OIDタグのタグ内容が配列である場合、これはそれぞれのタグがバイト文字列、配列、またはマップのすべての要素に対してimputedされることを意味します。（テキスト文字列やタグを含む他の要素には影響はありません。）たとえば、111タグのタグ内容が配列である場合、バイト文字列であるすべての配列要素はOID、および配列であるすべての要素です。またはマップは、ここで説明したように扱われます。
When the tag content of an OID tag is a map, this means that a tag with the same tag number is imputed to all keys in the map that are byte strings, arrays, or maps; again, there is no effect on keys of other major types. Note that there is also no effect on the values in the map.
OIDタグのタグ内容が地図である場合、これは、同じタグ番号を持つタグが、バイト文字列、配列、またはマップのすべてのキーに対してすべてのキーに通されます。繰り返しますが、他の主要なタイプのキーには影響しません。マップ内の値にも影響がないことに注意してください。
As a result of these rules, tag factoring in nested arrays and maps is supported. For example, a 3-dimensional array of OIDs can be composed by using a single 111 tag containing an array of arrays of arrays of byte strings. All such byte strings are then considered OIDs.
これらの規則の結果として、ネストされた配列とマップでのタグファクタがサポートされています。例えば、3次元アレイのOIDは、バイト文字列アレイのアレイの配列を含む単一の111タグを使用することによって構成することができる。そのようなバイト文字列はすべてOIDと見なされます。
Where tag factoring with tag number 111 is used, some OIDs enclosed in the tag may be encoded in a shorter way by using tag number 112 instead of encoding an unadorned byte string. This remains the preferred serialization (see also Section 2.2). However, this specification does not make the presence or absence of tag factoring a preferred serialization; application protocols can define where tag factoring is to be used or not (and will need to do so if they have deterministic encoding requirements).
タグ番号111を用いたタグファクタが使用される場合、タグ内に囲まれたいくつかのOIDは、解読されていないバイト文字列をエンコードする代わりにタグ番号112を使用することによって短い方法で符号化されてもよい。これは推奨される直列化のままです（セクション2.2も参照）。しかしながら、この仕様は、タグファクタリングの有無を好ましい直列化にしない。アプリケーションプロトコルは、タグファクタリングが使用される場合（およびそれらが決定論的なエンコーディング要件がある場合はそうする必要がある）。
Consider the X.500 distinguished name:
X.500識別名を考慮してください。
+==============================+=============+
| Attribute Types | Attribute |
| | Values |
+==============================+=============+
| c (2.5.4.6) | US |
+------------------------------+-------------+
| l (2.5.4.7) | Los Angeles |
| s (2.5.4.8) | CA |
| postalCode (2.5.4.17) | 90013 |
+------------------------------+-------------+
| street (2.5.4.9) | 532 S Olive |
| | St |
+------------------------------+-------------+
| businessCategory (2.5.4.15) | Public Park |
| buildingName | Pershing |
| (0.9.2342.19200300.100.1.48) | Square |
+------------------------------+-------------+
Table 2: Example X.500 Distinguished Name
表2：X.500識別名の例
Table 2 has four "relative distinguished names" (RDNs). The country (first) and street (third) RDNs are single valued. The second and fourth RDNs are multivalued.
表2は、4つの「相対的な識別名」（RDNS）を持っています。国（最初の）と街路（3番目）のRDNは単一値です。2番目と4番目のRDNは多値です。
The equivalent representations in CBOR diagnostic notation (Section 8 of [RFC8949]) and CBOR are:
CBOR診断表記の等価表現（[RFC8949]のセクション8）とCBOBORは次のとおりです。
111([{ h'550406': "US" },
{ h'550407': "Los Angeles",
h'550408': "CA",
h'550411': "90013" },
{ h'550409': "532 S Olive St" },
{ h'55040f': "Public Park",
h'0992268993f22c640130': "Pershing Square" }])
Figure 5: Distinguished Name in CBOR Diagnostic Notation
図5：CBOR診断表記の識別名
d8 6f # tag(111)
84 # array(4)
a1 # map(1)
43 550406 # 2.5.4.6 (4)
62 # text(2)
5553 # "US"
a3 # map(3)
43 550407 # 2.5.4.7 (4)
6b # text(11)
4c6f7320416e67656c6573 # "Los Angeles"
43 550408 # 2.5.4.8 (4)
62 # text(2)
4341 # "CA"
43 550411 # 2.5.4.17 (4)
65 # text(5)
3930303133 # "90013"
a1 # map(1)
43 550409 # 2.5.4.9 (4)
6e # text(14)
3533322053204f6c697665205374 # "532 S Olive St"
a2 # map(2)
43 55040f # 2.5.4.15 (4)
6b # text(11)
5075626c6963205061726b # "Public Park"
4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11)
6f # text(15)
5065727368696e6720537175617265 # "Pershing Square"
Figure 6: Distinguished Name in CBOR (109 Bytes)
図6：CBORの識別名（109バイト）
(This example encoding assumes that all attribute values are UTF-8 strings or can be represented as UTF-8 strings with no loss of information.)
（このエンコード例は、すべての属性値がUTF-8文字列であることを前提としているか、情報の損失なしにUTF-8文字列として表すことができます。）
Concise Data Definition Language (CDDL) specifications [RFC8610] may want to specify the use of SDNVs or SDNV sequences (as defined for the tag content for tag 110). This document introduces two new control operators that can be applied to a target value that is a byte string:
簡潔なデータ定義言語（CDDL）の仕様[RFC8610]（タグ110のタグ内容に定義されているように）SDNVSまたはSDNVシーケンスの使用を指定することをお勧めします。この文書では、バイト文字列であるターゲット値に適用できる2つの新しい制御演算子が紹介されています。
* ".sdnv", with a control type that contains unsigned integers. The byte string is specified to be encoded as an SDNV (BER encoding) [RFC6256] for the matching values of the control type.
* ".sdnv"、符号なし整数を含むコントロールタイプを持つ。バイト文字列は、コントロールタイプのマッチング値に対してSDNV（BERエンコーディング）[RFC6256]としてエンコードされるように指定されています。
* ".sdnvseq", with a control type that contains arrays of unsigned integers. The byte string is specified to be encoded as a sequence of SDNVs (BER encoding) [RFC6256] that decodes to an array of unsigned integers matching the control type.
* ".sdnvseq"、符号なし整数の配列を含むコントロールタイプを持つ。バイト文字列は、コントロールタイプに一致する符号なし整数の配列をデコードするSDNVS（BER ENCODING）のシーケンスとしてエンコードされるように指定されています。
* ".oid", like ".sdnvseq", except that the X*40+Y translation for absolute OIDs is included (see Figure 8).
* 「.sdnvseq」のように、絶対的なOIDのx * 40 y並進が含まれていることを除いて、 ".oid"が含まれている（図8を参照）。
Figure 7 shows an example for the use of ".sdnvseq" for a part of a structure using OIDs that could be used in Figure 6; Figure 8 shows the same with the ".oid" operator.
図6で使用できるOIDを使用した構造の一部に対して「.SDNVSEQ」を使用するための例を示します。図8は「.oid」演算子と同じを示しています。
country-rdn = {country-oid => country-value}
country-oid = bytes .sdnvseq [85, 4, 6]
country-value = text .size 2
Figure 7: Using .sdnvseq
図7：.SDNVSEQを使用しています
country-rdn = {country-oid => country-value}
country-oid = bytes .oid [2, 5, 4, 6]
country-value = text .size 2
Figure 8: Using .oid
図8：.oidの使用
Note that the control type need not be a literal; for example, "bytes .oid [2, 5, 4, *uint]" matches all OIDs inside OID arc "2.5.4", "attributeType".
コントロールタイプはリテラルである必要はありません。たとえば、 "バイト.OID [2,5,4、* UINT]" "" OID ARC "2.5.4"、 "AttributeType"内のすべてのOIDと一致します。
For the use with CDDL, the type names defined in Figure 9 are recommended:
CDDLで使用するには、図9で定義されているタイプ名をお勧めします。
oid = #6.111(bstr)
roid = #6.110(bstr)
pen = #6.112(bstr)
Figure 9: Recommended Type Names for CDDL
図9：CDDLの推奨タイプ名
IANA has assigned the CBOR tag numbers in Table 3 in the 1+1 byte space (24..255) of the "CBOR Tags" registry [IANA.cbor-tags], with this document as the specification reference.
IANAには、この文書を仕様参照として、「CBORタグ」レジストリ[IANA.cbobobour-Tag]の1 1バイトスペース（24..255）のCBORタグ番号を割り当てました。
+=====+===============+============================+===========+
| Tag | Data Item | Semantics | Reference |
+=====+===============+============================+===========+
| 111 | byte string, | object identifier (BER | RFC 9090 |
| | array, or map | encoding) | |
+-----+---------------+----------------------------+-----------+
| 110 | byte string, | relative object identifier | RFC 9090 |
| | array, or map | (BER encoding); SDNV | |
| | | [RFC6256] sequence | |
+-----+---------------+----------------------------+-----------+
| 112 | byte string, | object identifier (BER | RFC 9090 |
| | array, or map | encoding), relative to | |
| | | 1.3.6.1.4.1 | |
+-----+---------------+----------------------------+-----------+
Table 3: New Tag Numbers
表3：新しいタグ番号
IANA has assigned the CDDL control operators in Table 4 in the "CDDL Control Operators" registry [IANA.cddl], with this document as the specification reference.
このドキュメントを指定リファレンスとして、「CDDL制御演算子」レジストリ[IANA.CDDL]の「CDDL制御演算子」レジストリ[IANA.CDDL]のCDDL制御演算子を割り当てました。
+==========+===========+
| Name | Reference |
+==========+===========+
| .sdnv | RFC 9090 |
+----------+-----------+
| .sdnvseq | RFC 9090 |
+----------+-----------+
| .oid | RFC 9090 |
+----------+-----------+
Table 4: New CDDL Control Operators
表4：新しいCDDL制御演算子
The security considerations of [RFC8949] apply.
[RFC8949]のセキュリティ上の考慮事項が適用されます。
The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact and unambiguous but MUST be followed precisely to avoid security pitfalls. In particular, the requirements set out in Section 2.1 of this document need to be followed; otherwise, an attacker may be able to subvert a checking process by submitting alternative representations that are later taken as the original (or even something else entirely) by another decoder that is intended to be protected by the checking process.
[X.690]の句8.19および8.20のエンコーディングは非常にコンパクトで明確ですが、セキュリティの落とし穴を避けるために正確に追跡する必要があります。特に、この文書のセクション2.1に記載されている要件に従う必要があります。さもなければ、攻撃者は、検査プロセスによって保護されることを意図している他のデコーダによって後で、後で元の表現を提出することによってチェックプロセスをまとめることができるかもしれない。
OIDs and relative OIDs can always be treated as opaque byte strings. Actually understanding the structure that was used for generating them is not necessary, and, except for checking the structure requirements, it is strongly NOT RECOMMENDED to perform any processing of this kind (e.g., converting into dotted notation and back) unless absolutely necessary. If the OIDs are translated into other representations, the usual security considerations for non-trivial representation conversions apply; the integer values are unlimited in range.
OIDと相対的なOIDは常に不透明バイト文字列として扱うことができます。実際にそれらを生成するために使用された構造を理解する必要はなく、構造要件をチェックすることを除いて、絶対に必要な場合を除き、この種の処理を実行することを強く推奨されません（例えば、ドット付き表記表記および背面に変換する）。OIDが他の表現に翻訳されている場合は、非些細な表現変換に関する通常のセキュリティ上の考慮事項が適用されます。整数値は範囲内で無制限です。
An attacker might trick an application into using a byte string inside a tag-factored data item, where the byte string is not actually intended to fall under one of the tags defined here. This may cause the application to emit data with semantics different from what was intended. Applications therefore need to be restrictive with respect to what data items they apply tag factoring to.
攻撃者は、タグファクタドデータ項目内のバイト文字列を使用してアプリケーションをトリックすることができます。ここで、バイト文字列は実際にはここで定義されたタグの1つの下にあることを意図していません。これにより、アプリケーションが意図されたものとは異なる意味でデータを発行させる可能性があります。したがって、アプリケーションは、タグファクタリングを適用するデータ項目に関して制限的である必要があります。
[IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
[IANA.CBOR-TAGS] IANA、「簡潔なバイナリオブジェクト表現（CBOR）タグ」、<https：//www.iana.org/assignments/cbor-tags>。
[IANA.cddl] IANA, "Concise Data Definition Language (CDDL)", <https://www.iana.org/assignments/cddl>.
[IANA.CDDL] IANA、「簡潔なデータ定義言語（CDDL）」、<https：//www.iana.org/assignments/cddl>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 2011, <https://www.rfc-editor.org/info/rfc6256>.
[RFC6256] EDDY、W.およびE.DAVIES、「プロトコルの自己区切りの数値の使用」、RFC 6256、DOI 10.17487 / RFC6256、2011年5月、<https：//www.rfc-editor.org/info/rfc6256>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[X.660] ITU-T, "Information technology - Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree", ITU-T Recommendation X.660, July 2011, <https://www.itu.int/rec/T-REC-X.660>.
[X.660] ITU-T、「情報技術 - オブジェクト識別子登録当局の操作の手順：国際オブジェクト識別子ツリーの一般手順とトップアーク」、ITU-T勧告X.660、2011年7月、<https：//www.itu.int/rec/t-rec-x.660>。
[X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, August 2015, <https://www.itu.int/rec/T-REC-X.680>.
[X.680] ITU-T、「情報技術 - 抽象構文表記1（ASN.1）：基本表記の仕様」、ITU-T勧告X.680、2015年8月、<https：//www.itu.int/rec/t-rec-x.680>。
[X.690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015, <https://www.itu.int/rec/T-REC-X.690>.
[X.690] ITU-T、「情報技術 - ASN.1符号化規則：基本符号化規則（BER）、正規符号化規則（CER）および識別符号化規則（DER）」の仕様ITU-T勧告X.6902015年8月、<https：//www.itu.int/rec/t-rec-x.690>。
[IANA.enterprise-numbers] IANA, "Private Enterprise Numbers", <https://www.iana.org/assignments/enterprise-numbers>.
[IANA.ENTERPRISE番号] IANA、「プライベートエンタープライズ番号」、<https://www.iana.org/ashignments/Etterprise-Numbers>。
[OID-INFO] Orange SA, "Object Identifier (OID) Repository", <http://www.oid-info.com/>.
[OID-Info] Orange SA、「オブジェクト識別子（OID）リポジトリ」、<http://www.oid-info.com/>。
[PCRE] "PCRE - Perl Compatible Regular Expressions", <http://www.pcre.org/>.
[PCRE] "PCRE - Perl互換式"、<http://www.pcre.org/>。
[RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, "Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7388, DOI 10.17487/RFC7388, October 2014, <https://www.rfc-editor.org/info/rfc7388>.
[RFC7388] Schoenwaelder、J.、Sehgal、A。、TSOU、T.、およびC.Zhou、「低電力無線パーソナルエリアネットワーク上のIPv6の管理対象オブジェクトの定義（6lowpans）」、RFC 7388、DOI 10.17487 / RFC73882014年10月、<https://www.rfc-editor.org/info/rfc7388>。
[X.672] ITU-T, "Information technology - Open systems interconnection - Object identifier resolution system (ORS)", ITU-T Recommendation X.672, August 2010, <https://www.itu.int/rec/T-REC-X.672>.
[X.672] ITU-T、「情報技術 - オープンシステム相互接続 - オブジェクト識別子解決システム（ORS）」、ITU-T勧告X.672、2010年8月、<https：//www.itu.int/rec/T-Rec-X.672>。
Acknowledgments
謝辞
Sean Leonard started the work on this document in 2014 with an elaborate proposal. Jim Schaad provided a significant review of this document. Rob Wilton's IESG review prompted us to provide preferred serialization considerations.
Sean Leonardは、2014年にこの文書の作業を詳しく提案しました。Jim Schaadはこの文書の重要なレビューを提供しました。Rob WiltonのIESGレビューは、優先シリアル化の考慮事項を提供するように促しました。
Contributors
貢献者
Sean Leonard Penango, Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles, CA 90036 United States of America
Sean Leonard Penango、Inc。5900 Wilshire Boulevard 21階ロサンゼルス、CA 90036アメリカ
Email: dev+ietf@seantek.com
Author's Address
著者の住所
Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany
Bremen Tzi Postfach 330440 D-28359ブレーメンドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org