[要約] RFC 9277は、CBORデータアイテムのためのファイル形式を定義し、Unixのfile(1)コマンドなどの一般的なシステムで認識されるようにすることを目的としています。
Internet Engineering Task Force (IETF) M. Richardson
Request for Comments: 9277 Sandelman Software Works
Category: Standards Track C. Bormann
ISSN: 2070-1721 Universität Bremen TZI
August 2022
On Stable Storage for Items in Concise Binary Object Representation (CBOR)
簡潔なバイナリオブジェクト表現のアイテムの安定したストレージ（CBOR）
Abstract
概要
This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.
このドキュメントでは、UNIXファイル（1）コマンドなどのファイルタイプを認識する一般的なシステムに友好的なコンザシックバイナリオブジェクト表現（CBOR）データの保存された（「ファイル」）形式を定義します。
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/rfc9277.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9277で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Requirements for a Magic Number
2. Protocol
2.1. The CBOR-Protocol-Specific Tag
2.2. Enveloping Method: CBOR Tag Wrapped
2.2.1. Example
2.3. Enveloping Method: Labeled CBOR Sequence
2.3.1. Example
3. Security Considerations
4. IANA Considerations
4.1. Labeled CBOR Sequence Tag
4.2. CBOR-Labeled Non-CBOR Data Tag
4.3. CBOR Tags for CoAP Content-Format Numbers
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Advice to Protocol Designer
A.1. Is the on-wire format new?
A.2. Can many items be trivially concatenated?
A.3. Are there tags at the start?
Appendix B. CBOR Tags for CoAP Content Formats
B.1. Content-Format Tag Examples
Appendix C. Example from Openswan
Appendix D. Using CBOR Labels for Non-CBOR Data
D.1. Content-Format Tag Examples
Acknowledgements
Contributors
Authors' Addresses
Since very early in computing, operating systems have sought ways to mark which files could be processed by which programs. In Unix, everything is a stream of bytes; identifying the contents of a stream of bytes became a heuristic activity.
コンピューティングの非常に早い段階から、オペレーティングシステムは、どのプログラムで処理できるファイルをマークする方法を求めてきました。UNIXでは、すべてがバイトの流れです。バイトの流れの内容を識別することは、ヒューリスティックな活動になりました。
For instance, the Unix file(1) command, which has existed since 1973 [FILE], has been able to identify many file formats based upon the contents of the file for decades.
たとえば、1973年[ファイル]以来存在していたUNIXファイル（1）コマンドは、ファイルの内容に基づいて多くのファイル形式を識別することができました。
Many systems (Linux, macOS, Windows) will select the correct application based upon the file contents if the system cannot determine it by other means. For instance, in classical Mac OS, a resource fork was maintained separately from the file data that included file type information; this way, the OS ideally never needed to know anything about the file data contents to determine the media type.
多くのシステム（Linux、MacOS、Windows）は、システムが他の手段でそれを決定できない場合、ファイルの内容に基づいて正しいアプリケーションを選択します。たとえば、古典的なMac OSでは、ファイルタイプ情報を含むファイルデータとは別にリソースフォークが維持されました。これにより、OSは、メディアタイプを決定するためにファイルデータの内容について何も知る必要はありませんでした。
Many other systems do this by using file extensions. Many common Web servers derive the media-type information from file extensions.
他の多くのシステムは、ファイル拡張子を使用してこれを行います。多くの一般的なWebサーバーは、ファイル拡張機能からメディアタイプの情報を導き出します。
Having a media type associated with the file contents can avoid some of the brittleness of this approach. When files become disconnected from their type information, such as when attempting to do forensics on a damaged system, being able to identify the type of information stored in a file can become very important.
ファイルのコンテンツに関連付けられたメディアタイプを持つことで、このアプローチの脆弱性の一部を回避できます。破損したシステムで法医学を実行しようとするときなど、ファイルがタイプ情報から切断されると、ファイルに保存されている情報の種類を識別できるようになると、非常に重要になります。
A common way to identify the type of a file from its contents is to place a "magic number" at the start of the file contents [MAGIC]. In the media type registration template [RFC6838], a magic number is asked for, if available, as is a file extension.
そのコンテンツからファイルのタイプを識別する一般的な方法は、ファイルコンテンツ[魔法]の開始時に「魔法番号」を配置することです。メディアタイプの登録テンプレート[RFC6838]では、ファイル拡張子と同様に、魔法の番号が求められます。
A challenge for the file(1) command is often that it can be confused by recognizing the overall encoding but not the content being encoded. For instance, an Android Package Kit APK (as used to transfer and store an application) may be identified as a ZIP file. Additionally, both OpenOffice and MSOffice files are ZIP files of XML files; the identification may stop at identifying them as ZIP files.
ファイル（1）コマンドの課題は、多くの場合、エンコード全体を認識することで混乱させることができるが、エンコードされているコンテンツではないことです。たとえば、AndroidパッケージキットAPK（アプリケーションの転送と保存に使用）は、ZIPファイルとして識別される場合があります。さらに、OpenOfficeファイルとMSOFFICEファイルはどちらもXMLファイルのZIPファイルです。識別は、それらをzipファイルとして識別することに停止する場合があります。
As CBOR becomes a more and more common encoding for a wide variety of artifacts, identifying them as just "CBOR" is probably not sufficient. This document provides a way to encode a magic number into the beginning of a CBOR format file. As a CBOR format may use a single CBOR data item or a CBOR sequence of data items [RFC8742], two possible methods of enveloping data are presented; a CBOR Protocol designer will specify one. (A CBOR Protocol is a specification that uses CBOR as its encoding.)
CBORは、さまざまなアーティファクトのためにますます一般的なエンコードになるため、それらを単に「CBOR」と特定するだけでは十分ではありません。このドキュメントは、魔法の数字をCBOR形式ファイルの先頭にエンコードする方法を提供します。CBOR形式は、単一のCBORデータ項目またはCBORシーケンスのデータ項目[RFC8742]を使用する可能性があるため、2つの可能な包括的なデータが表示されます。CBORプロトコルデザイナーが指定します。（CBORプロトコルは、CBORをエンコードとして使用する仕様です。）
This document also gives advice to designers of CBOR Protocols on choosing one of these mechanisms for identifying their contents. This advice is informative.
このドキュメントは、CBORプロトコルの設計者に、内容を識別するためのこれらのメカニズムの1つを選択することについてのアドバイスも提供します。このアドバイスは有益です。
A third method is also proposed by which a CBOR format tag is prepended to identify non-CBOR files. Further information on this method appears in Appendix D because it is not about identifying media types containing CBOR-encoded data items. This includes a simple way to derive a magic number for content-formats as defined in [RFC7252], even if the file is not in CBOR form.
CBOR形式のタグが非CBORファイルを識別するために準備される3番目の方法も提案されています。この方法の詳細は、CBORエンコードデータ項目を含むメディアタイプを識別することではないため、付録Dに表示されます。これには、ファイルがCBOR形式でなくても、[RFC7252]で定義されているコンテンツフォーマットのマジック番号を導き出す簡単な方法が含まれます。
Examples of CBOR Protocols currently under development include Concise Software Identification Tags [CoSWID] and Entity Attestation Tokens [EAT]. CBOR Object Signing and Encryption (COSE) itself [RFC8152] is considered infrastructure. The encoding of public keys in CBOR as _C509_ as described in [C509-CERT] would benefit from being an identified CBOR Protocol.
現在開発中のCBORプロトコルの例には、簡潔なソフトウェア識別タグ[CosWID]およびエンティティの証明トークン[EAT]が含まれます。CBORオブジェクトの署名と暗号化（COSE）自体[RFC8152]は、インフラストラクチャと見なされます。[C509-CERT]に記載されているように、_C509_としてのCBORでのパブリックキーのエンコードは、特定されたCBORプロトコルであることから恩恵を受けるでしょう。
A major inspiration for this document is observing the disarray in certain ASN.1-based systems where most files are Privacy-Enhanced Mail (PEM) encoded; these files are all identified by the extension "pem", which confounds public keys, private keys, certificate requests, and S/MIME content.
このドキュメントの主要なインスピレーションは、ほとんどのファイルがプライバシー強化メール（PEM）エンコードされている特定のASN.1ベースのシステムで混乱を観察することです。これらのファイルはすべて、公開キー、プライベートキー、証明書リクエスト、およびS/MIMEコンテンツを混乱させる拡張機能「PEM」によって識別されます。
While the envelopes defined in this specification add information to how data conforming to CBOR Protocols are stored in files, there is no requirement that either type of envelope be transferred on the wire. However, there are some protocols that may benefit from having such a magic number on the wire if they are presently using a different (legacy) encoding scheme. The presence of the identifiable magic sequence can be used to signal that a CBOR Protocol is being used as opposed to a legacy scheme.
この仕様で定義されている封筒は、CBORプロトコルに適合するデータがファイルに保存される方法についての情報を追加しますが、どちらのタイプのエンベロープをワイヤに転送する必要はありません。ただし、現在別の（レガシー）エンコードスキームを使用している場合、このような魔法の数字をワイヤーに持っていることから利益を得ることができるプロトコルがいくつかあります。識別可能なマジックシーケンスの存在を使用して、レガシースキームとは対照的に、CBORプロトコルが使用されていることを示すことができます。
Byte is a synonym for octet. The term "byte string" refers to the data item defined in [STD94].
ByteはOctetの同義語です。「バイト文字列」という用語は、[std94]で定義されているデータ項目を指します。
The term "file" is understood to stand in a general way for a stored representation that is somewhat detached from the original context of usage of that representation; its usage in this document encompasses similar units of storage that may have different identification schemes such as partitions or media blocks.
「ファイル」という用語は、その表現の使用法の元のコンテキストから多少切り離された保存された表現の一般的な方法で立つことが理解されています。このドキュメントでの使用は、パーティションやメディアブロックなどの異なる識別スキームを持つ可能性のある同様のストレージ単位を網羅しています。
The term "diagnostic notation" refers to the human-readable notation for CBOR data items defined in Section 8 of [STD94] and Appendix G of [RFC8610].
「診断表記」という用語は、[STD94]のセクション8および[RFC8610]の付録Gで定義されているCBORデータ項目のヒューマン読み取り可能な表記を指します。
The term "CDDL" (Concise Data Definition Language) refers to the language defined in [RFC8610].
「CDDL」という用語（Sciseデータ定義言語）は、[RFC8610]で定義されている言語を指します。
The function TN(ct) is defined in Appendix B.
関数TN（CT）は付録Bで定義されています。
Ideally, a magic number is a fingerprint that is unique to a specific CBOR Protocol, is present in the first few (small multiple of 4) bytes of the file and does not change when the contents change, and does not depend upon the length of the file.
理想的には、マジック番号は特定のCBORプロトコルに固有の指紋であり、ファイルの最初の数バイト（4の小さな倍数）に存在し、内容が変化したときに変化し、変化せず、の長さに依存しません。ファイル。
Less ideal solutions have a pattern that needs to be matched, but in which some bytes need to be ignored. While the Unix file(1) command can be told to ignore certain bytes, this can lead to ambiguities.
あまり理想的なソリューションには、一致する必要があるパターンがありますが、一部のバイトを無視する必要があります。UNIXファイル（1）コマンドは特定のバイトを無視するように指示することができますが、これは曖昧さにつながる可能性があります。
This section presents two enveloping methods. Both use CBOR tags in a way that results in a deterministic first 8 to 12 bytes. The Protocol designer determines which one to use; see Appendix A for some guidance.
このセクションでは、2つの包括的な方法を紹介します。どちらもCBORタグを使用して、決定論的な最初の8〜12バイトをもたらす方法で使用します。プロトコル設計者は、使用するものを決定します。いくつかのガイダンスについては、付録Aを参照してください。
In both enveloping methods, CBOR Protocol designers need to obtain a CBOR tag for each kind of object that they might store in files. As there are more than 4 billion available 4-byte tags, there should be little issue in allocating a few to each available CBOR Protocol.
両方の包括的な方法で、CBORプロトコル設計者は、ファイルに保存する可能性のある各種類のオブジェクトのCBORタグを取得する必要があります。利用可能な4バイトのタグは40億を超えるため、利用可能な各CBORプロトコルにいくつかを割り当てる際にはほとんど問題がないはずです。
The IANA policy for 4-byte CBOR tags is First Come First Served [RFC8126] so only a simple interaction (e.g., via Web or email) with IANA is required. The interaction includes filling in the small template provided in Section 9.2 of [STD94]. In the template, a reference to this specification (RFC 9277) alongside the Description of semantics is suggested.
4バイトのCBORタグのIANAポリシーが最初に提供される[RFC8126]ため、IANAとの単純な相互作用（例：Webまたは電子メールを介して）のみが必要です。相互作用には、[STD94]のセクション9.2に記載されている小さなテンプレートへの記入が含まれます。テンプレートでは、セマンティクスの説明とともにこの仕様（RFC 9277）への参照が提案されています。
Allocation of the CBOR tag needs to be initiated by the designer of the CBOR Protocol, who can provide a proposed tag number. In order to be in the 4-byte range, and so that there are no leading zero bytes in the 4-byte encoding of the tag number, the value needs to be in the range 0x01000000 (decimal 16777216) to 0xFFFFFFFF (decimal 4294967295) inclusive. It is further suggested to avoid values that have an embedded zero byte in the 4 bytes of their binary representation (such as 0x12003456), as these may confuse implementations that treat the magic number as a C string.
CBORタグの割り当ては、提案されたタグ番号を提供できるCBORプロトコルのデザイナーによって開始する必要があります。4バイトの範囲になり、タグ番号の4バイトエンコードにゼロバイトがゼロバイトがないようにするには、値は0x01000000（小数16777216）から0xffffffff（小数4294967295）の範囲である必要があります。包括的。さらに、バイナリ表現の4バイトにゼロバイトが埋め込まれている値（0x12003456など）を回避することをお勧めします。
The use of a sequence of four ASCII [RFC20] codes which are mnemonic to the protocol is encouraged, but not required (there may be reasons to encode other information into the tag; see Appendix B for an example). For instance, Appendix C uses "OPSN", which translates to the tag number 1330664270 registered for it.
プロトコルにニーモニックである4つのASCII [RFC20]コードのシーケンスの使用が奨励されますが、必須ではありません（他の情報をタグにエンコードする理由があります。例については付録Bを参照）。たとえば、付録Cでは「OPSN」を使用しています。これは、登録されているタグ番号1330664270に変換されます。
In [IANA.CORE-PARAMETERS], the Constrained Application Protocol (CoAP) defines the "CoAP Content-Formats" registry to assign Content-Format Numbers (Section 12.3 of [RFC7252]) to Content Types in a specific Content Coding. For CBOR data items that form a representation that is already described by such a Content-Format Number, a tag number has proactively been allocated in Section 4.3 (see Appendix B for details and examples).
[IANA.Core-Parameters]では、制約付きアプリケーションプロトコル（COAP）は、「COAPコンテンツフォーマット」レジストリを定義して、コンテンツフォーマット番号（[RFC7252]のセクション12.3）を特定のコンテンツコーディングのコンテンツタイプに割り当てます。このようなコンテンツフォーマット番号ですでに説明されている表現を形成するCBORデータ項目の場合、タグ番号はセクション4.3に積極的に割り当てられています（詳細と例については、付録Bを参照）。
The CBOR Tag Wrapped method is appropriate for use with CBOR Protocols that encode a single CBOR data item. This data item is enveloped into two nested tags:
CBORタグラップメソッドは、単一のCBORデータ項目をエンコードするCBORプロトコルで使用するのに適しています。このデータ項目は、2つのネストされたタグに包まれています。
The outer tag is a self-described CBOR tag, 55799, as described in Section 3.4.6 of [STD94].
外側のタグは、[STD94]のセクション3.4.6で説明されているように、自称CBORタグ55799です。
The tag content of the outer tag is a second CBOR tag whose tag number has been allocated to describe the specific Protocol involved, as discussed in Section 2.1. The tag content of this inner tag is the single CBOR data item.
アウタータグのタグ内容は、セクション2.1で説明されているように、関連する特定のプロトコルを記述するためにタグ番号が割り当てられた2番目のCBORタグです。この内側タグのタグ内容は、単一のCBORデータ項目です。
This method wraps the CBOR data item as CBOR tags usually do. Applications that need to send the stored CBOR data item across a constrained network may wish to remove the two tags if the type is understood from the protocol context, e.g., from a CoAP Content-Format Option (Section 5.10.3 of [RFC7252]). Therefore, a CBOR Protocol specification may pick the specific cases where the CBOR Tag Wrapped enveloping method is to be used. For instance, it might specify its use for storing the representation in a local file or for Web access, but not within protocol messages that already provide the necessary context.
このメソッドは、CBORタグが通常行うようにCBORデータ項目をラップします。制約付きネットワーク全体で保存されたCBORデータアイテムを送信する必要があるアプリケーションは、タイプがプロトコルコンテキストから理解されている場合、たとえばCOAPコンテンツフォーマットオプション（[RFC7252]のセクション5.10.3）から理解されている場合、2つのタグを削除することをお勧めします。。したがって、CBORプロトコル仕様は、CBORタグラップ包装方法を使用する特定のケースを選択する場合があります。たとえば、ローカルファイルまたはWebアクセスに表現を保存するための使用を指定する可能性がありますが、すでに必要なコンテキストを提供するプロトコルメッセージ内ではありません。
To construct an example without registering a new tag, we use the Content-Format ID assigned for application/senml+cbor (112) [RFC8428] of the "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS]).
新しいタグを登録せずに例を構築するには、「Coapコンテンツフォーマット」レジストリ[IANA.CORE-PARAMETERS]のアプリケーション/senml Cbor（112）[RFC8428]に割り当てられたコンテンツフォーマットIDを使用します。
Using the technique described in Appendix B, this translates into the tag TN(112) = 1668546929.
付録Bで説明した手法を使用して、これはタグTN（112）= 1668546929に変換されます。
With this tag, the SenML-CBOR pack [{0: "current", 6: 3, 2: 1.5}] would be enveloped as follows (in diagnostic notation):
このタグを使用すると、senml-cborパック[{0： "current"、6：3、2：1.5}]は次のように包み込まれます（診断表記で）：
55799(1668546929([{0: "current", 6: 3, 2: 1.5}]))
Or in hex:
または六角：
d9 d9f7 # tag(55799)
da 63740171 # tag(1668546929)
81 # array(1)
a3 # map(3)
00 # unsigned(0)
67 # text(7)
63757272656e74 # "current"
06 # unsigned(6)
03 # unsigned(3)
02 # unsigned(2)
f9 3e00 # primitive(15872)
At the representation level, the unique fingerprint for application/ senml+cbor is composed of the 8 bytes d9d9f7da63740171 hex, after which the unadorned CBOR data (81... for the SenML data) is appended.
表現レベルでは、アプリケーション/ SENML CBORのユニークな指紋は、8バイトD9D9F7DA63740171 HEXで構成されており、その後、装飾されていないCBORデータ（SENMLデータの場合は81 ...）が追加されます。
The Labeled CBOR Sequence method is appropriate for use with CBOR Sequences as described in [RFC8742].
[RFC8742]に記載されているように、CBORシーケンス法では、CBORシーケンスで使用するのに適しています。
This method prepends a newly constructed, separate data item to the CBOR Sequence, the _label_.
このメソッドは、新しく構築された個別のデータ項目をCBORシーケンス、_Label_にプレイエンドします。
The label is a nesting of two tags, similar to but distinct from the CBOR Tag Wrapped methods, with an inner tag content of a constant byte string. The total length of the label is 12 bytes.
ラベルは、CBORタグラップメソッドとは異なるが、一定のバイト文字列の内側のタグコンテンツを持つ2つのタグのネストです。ラベルの全長は12バイトです。
1. The outer tag is the self-described CBOR Sequence tag, 55800.
1. 外側のタグは、自称CBORシーケンスタグ55800です。
2. The inner tag is a CBOR tag from the First Come First Served space that uniquely identifies the CBOR Protocol. As with the CBOR Tag Wrapped method, the use of a 4-byte tag that encodes without zero bytes is encouraged.
2. 内側のタグは、CBORプロトコルを独自に識別する最初の到着した最初に提供されるスペースのCBORタグです。CBORタグラップメソッドと同様に、ゼロバイトなしでエンコードする4バイトタグの使用が推奨されます。
3. The tag content is a 3-byte CBOR byte string containing 0x42_4f_52 ('BOR' in diagnostic notation).
3. タグコンテンツは、0x42_4f_52（診断表記では「bor」）を含む3バイトのCborバイト文字列です。
The outer tag in the label identifies the file as being a CBOR Sequence and does so with all the desirable properties explained in Section 3.4.6 of [STD94]. Specifically, it does not appear to conflict with any known file types, and it is not valid Unicode in any Unicode encoding.
ラベルの外側タグは、ファイルをCBORシーケンスであると識別し、[STD94]のセクション3.4.6で説明されているすべての望ましいプロパティを使用してそれを行います。具体的には、既知のファイルタイプと競合するようには見えず、Unicodeエンコードでは有効なUnicodeではありません。
The inner tag in the label identifies which CBOR Protocol is used, as described above.
ラベルの内側タグは、上記のように使用されるCBORプロトコルを識別します。
The inner tag content is a constant byte string that is represented as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR-encoded data item for the 3-byte string 0x42_4f_52 ('BOR' in diagnostic notation).
内側のタグコンテンツは、0x43_42_4f_52、ASCII文字「CBOR」として表される一定のバイト文字列です。これは、3バイトの文字列0x42_4F_52（診断表記の「bor」）のcborエンコードデータ項目です。
The actual CBOR Protocol data then follows as the next data item(s) in the CBOR Sequence, without a need for any further specific tag. The use of a CBOR Sequence allows the application to trivially remove the first item with the two tags.
実際のCBORプロトコルデータは、CBORシーケンスの次のデータ項目として、さらに特定のタグを必要とせずに続きます。CBORシーケンスを使用すると、アプリケーションは2つのタグで最初のアイテムを簡単に削除できます。
Should this file be reviewed by a human (directly in an editor or in a hexdump display), it will include the ASCII characters "CBOR" prominently. This value is also included simply because the inner nested tag needs to tag something.
このファイルが人間（編集者またはhexdumpディスプレイ）によってレビューされた場合、ASCII文字「Cbor」を際立たせて含めます。この値は、内側のネストされたタグが何かにタグを付ける必要があるという理由だけで含まれています。
To construct an example without registering a new tag, we use ID 272 as assigned for application/missing-blocks+cbor-seq of the "CoAP Content-Formats" registry [RFC9177].
新しいタグを登録せずに例を構築するには、「COAPコンテンツフォーマット」レジストリ[RFC9177]のアプリケーション/欠落ブロックCBOR-seqに割り当てられたID 272を使用します。
Using the technique described in Appendix B, this translates into the tag TN(272) = 1668547090.
付録Bで説明した手法を使用して、これはタグTN（272）= 1668547090に変換されます。
This is a somewhat contrived example, as this is not a media type that is likely to be committed to storage. Nonetheless, with this tag, missing blocks list 0, 8, 15 would be enveloped as (in diagnostic notation):
これはやや不自然な例です。これは、ストレージにコミットする可能性が高いメディアタイプではないためです。それにもかかわらず、このタグを使用して、欠落ブロックリスト0、8、15は（診断表記で）として包み込まれます。
55800(1668547090('BOR')), 0, 8, 15
55800（1668547090（ 'bor'））、0、8、15
Or in hex:
または六角：
# CBOR sequence with 4 elements
d9 d9f8 # tag(55800)
da 63740212 # tag(1668547090)
43 # bytes(3)
424f52 # "BOR"
00 # unsigned(0)
08 # unsigned(8)
0f # unsigned(15)
At the representation level, the unique fingerprint for application/ missing-blocks+cbor-seq is composed of the 8 bytes d9d9f8da63740212 hex, after which the unadorned CBOR sequence (00... for the missing block list given) is appended.
表現レベルでは、アプリケーション/ミッシングブロックCBOR-seqのユニークな指紋は、8バイトD9D9F8DA63740212 HEXで構成されており、その後、装飾されていないCBORシーケンス（00 ...
This document provides a way to identify CBOR Protocol objects. Clearly identifying CBOR contents in files may have a variety of impacts.
このドキュメントは、CBORプロトコルオブジェクトを識別する方法を提供します。ファイル内のCBORコンテンツを明確に識別するには、さまざまな影響がある場合があります。
The most obvious is that it may allow malware to identify interesting stored objects, and then exfiltrate or corrupt them.
最も明白なのは、マルウェアが興味深い保存されたオブジェクトを識別し、それらを除去または破損する可能性があることです。
Protective applications (that check data) cannot rely on the applications they try to protect (that use the data) to make exactly the same decisions in recognizing file formats. (This is an instance of a check versus use issue.) For example, end-point assessment technologies should not solely rely on the labeling approaches described in this document to decide whether to inspect a given file. Similarly, depending on operating system configurations and related properties of the execution environment, the labeling might influence the default application used to process a file in a way that may not be predicted by a protective application.
保護アプリケーション（データをチェックする）は、ファイル形式を認識する際にまったく同じ決定を下すために、保護しようとするアプリケーション（データを使用）に依存することはできません。（これはチェックと使用問題のインスタンスです。）たとえば、エンドポイント評価技術は、このドキュメントで説明されているラベル付けアプローチに依存して、特定のファイルを検査するかどうかを決定する必要があります。同様に、オペレーティングシステムの構成と実行環境の関連プロパティに応じて、ラベル付けは、保護アプリケーションで予測されない方法でファイルを処理するために使用されるデフォルトのアプリケーションに影響を与える可能性があります。
These IANA considerations are entirely about CBOR tags in the "Concise Binary Object Representation (CBOR) Tags" registry [IANA.CBOR-TAGS].
これらのIANAの考慮事項は、完全に「簡潔なバイナリオブジェクト表現（CBOR）タグ」レジストリ[IANA.CBOR-TAGS]のCBORタグに関するものです。
Section 4.1 documents the allocation for a CBOR tag to be used in a CBOR sequence to identify the sequence (an example for using this tag is found in Appendix C). Section 4.2 documents the allocation for a CBOR tag to be used in the CBOR-Labeled Non-CBOR Data Enveloping Method (Appendix D, which also shows examples). Section 4.3 allocates a CBOR tag for each actual or potential CoAP Content-Format number (examples are in Appendix B).
セクション4.1には、CBORタグの割り当てがCBORシーケンスで使用されてシーケンスを識別することを文書化します（このタグを使用する例は、付録Cにあります）。セクション4.2には、CBOR標識以外の非CBORデータエンベロープ方法で使用されるCBORタグの割り当てを文書化します（付録Dも示しています）。セクション4.3では、実際のまたは潜在的なCOAPコンテンツ形式の各数にCBORタグを割り当てます（例は付録Bにあります）。
IANA has allocated tag 55800 for the Labeled CBOR Sequence Enveloping Method from the "CBOR Tags" registry. IANA has updated this tag registration to point to this document.
IANAは、「CBORタグ」レジストリからラベル付きCBORシーケンス封筒にタグ55800を割り当てました。IANAはこのタグ登録を更新して、このドキュメントを指しています。
This tag is from the First Come First Served area.
このタグは、最初に来る最初のサービスエリアからです。
The value has been picked to have properties similar to the 55799 tag (Section 3.4.6 of [STD94]).
値は、55799タグ（[STD94]のセクション3.4.6）と同様のプロパティを持つように選択されています。
The hexadecimal representation of the encoded tag head is 0xd9_d9_f8.
エンコードされたタグヘッドの16進表現は0xD9_D9_F8です。
This is not valid UTF-8: the first 0xd9 introduces a 3-byte sequence in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.
これは有効ではありませんutf-8：最初の0xd9はUTF-8に3バイトシーケンスを導入しますが、2番目の値として0xD9はUTF-8の有効な2番目のバイトではありません。
This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that this is a 32-bit Unicode value. However, the following 16-bit big-endian value 0xf8_xx is not a valid second sequence according to [RFC2781]. On a little-endian system, it would be necessary to examine the fourth byte to determine if it is valid. That next byte is determined by the subsequent encoding, and Section 3.4.6 of [STD94] has already determined that no valid CBOR encodings result in valid UTF-16.
これは有効ではありませんutf-16：バイトシーケンス0xd9d9（いずれかのエンディアン順）は、この値をUTF-16ハーフゾーンに入れます。これは、これが32ビットのユニコード値であることを示します。ただし、[RFC2781]によると、次の16ビットのBig-Endian値0xf8_xxは有効な2番目のシーケンスではありません。小さなエンディアンシステムでは、4番目のバイトを調べて有効かどうかを判断する必要があります。次のバイトは後続のエンコーディングによって決定され、[STD94]のセクション3.4.6は、有効なCBORエンコーディングが有効なUTF-16をもたらさないことをすでに決定しています。
Data Item: tagged byte string
データ項目：タグ付きバイト文字列
Semantics: indicates that the file contains CBOR Sequences
セマンティクス：ファイルにCBORシーケンスが含まれていることを示します
IANA has allocated tag 55801 for the CBOR-Labeled Non-CBOR Data Enveloping Method (Appendix D) from the "CBOR Tags" registry. IANA updated this tag registration to point to this document.
IANAは、「CBORタグ」レジストリからCBOR標識非CBORデータエンベロープメソッド（付録D）にタグ55801を割り当てました。IANAはこのタグ登録を更新して、このドキュメントを指しています。
This tag is from the First Come First Served area.
このタグは、最初に来る最初のサービスエリアからです。
The value has been picked to have properties similar to the 55799 tag (Section 3.4.6 of [STD94]).
値は、55799タグ（[STD94]のセクション3.4.6）と同様のプロパティを持つように選択されています。
The hexadecimal representation of the encoded tag head is 0xd9_d9_f9.
エンコードされたタグヘッドの16進表現は0xD9_D9_F9です。
This is not valid UTF-8: the first 0xd9 introduces a 3-byte sequence in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.
これは有効ではありませんutf-8：最初の0xd9はUTF-8に3バイトシーケンスを導入しますが、2番目の値として0xD9はUTF-8の有効な2番目のバイトではありません。
This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that this is a 32-bit Unicode value. However, the following 16-bit big-endian value 0xf9_xx is not a valid second sequence according to [RFC2781]. On a little-endian system, it would be necessary to examine the fourth byte to determine if it is valid. That next byte is determined by the subsequent encoding, and Section 3.4.6 of [STD94] has already determined that no valid CBOR encodings result in valid UTF-16.
これは有効ではありませんutf-16：バイトシーケンス0xd9d9（いずれかのエンディアン順）は、この値をUTF-16ハーフゾーンに入れます。これは、これが32ビットのユニコード値であることを示します。ただし、次の16ビットのビッグエンディアン値0xf9_xxは、[RFC2781]に従って有効な2番目のシーケンスではありません。小さなエンディアンシステムでは、4番目のバイトを調べて有効かどうかを判断する必要があります。次のバイトは後続のエンコーディングによって決定され、[STD94]のセクション3.4.6は、有効なCBORエンコーディングが有効なUTF-16をもたらさないことをすでに決定しています。
Data Item: tagged byte string
データ項目：タグ付きバイト文字列
Semantics: indicates that the file starts with a CBOR-Labeled Non-CBOR Data label.
セマンティクス：ファイルがCBor標識非CBORデータラベルで始まることを示します。
IANA allocated the tag numbers 1668546817 (0x63740101) to 1668612095 (0x6374ffff) as follows:
IANAは、次のように、タグ番号1668546817（0x63740101）を1668612095（0x6374ffff）に割り当てました。
Data Item: byte string or any CBOR data item (see Appendix B)
データ項目：バイト文字列またはCBORデータ項目（付録Bを参照）
Semantics:
the representation of content-format ct < 65025 is indicated by
tag number
TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255
Reference: RFC 9277
参照：RFC 9277
The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] is defined in Section 12.3 of [RFC7252].
「COAPコンテンツフォーマット」レジストリ[IANA.CORE-PARAMETERS]は、[RFC7252]のセクション12.3で定義されています。
[C] International Organization for Standardization, "Information technology -- Programming languages -- C", ISO/IEC 9899:2018, Fourth Edition, June 2018, <https://www.iso.org/standard/74528.html>.
[c]国際標準化機関、「情報技術 - プログラミング言語-C」、ISO/IEC 9899：2018、第4版、2018年6月、<https://www.iso.org/standard/74528.html>。
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/info/rfc8742>.
[RFC8742] Bormann、C。、「Scise Binary Object（CBOR）シーケンス」、RFC 8742、DOI 10.17487/RFC8742、2020年2月、<https://www.rfc-editor.org/info/rfc8742>
[STD94] 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/std94>.
[STD94] Bormann、C。and P. Hoffman、「Concise Binary Object Lepressation（CBOR）」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/std94>。
[C509-CERT] Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-04, 10 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-04>.
[C509-CERT] Mattsson、J。P.、Selander、G.、Raza、S.、Höglund、J。、およびM. Furuhed、「CborエンコードX.509証明書（C509証明書）」、進行中の作業、インターネットドラフト、Draft-ITETF-COSE-CBOR-ENCODED-CERT-04、2022年7月10日、<https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-04>。
[CoSWID] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", Work in Progress, Internet-Draft, draft-ietf-sacm-coswid-22, 20 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-22>.
[Coswid] Birkholz、H.、Fitzgerald-Mckay、J.、Schmidt、C。、およびD. Waltermire、「Scusise Software Identification Tags」、Work in Progress、Internet-Draft、Draft-Sacm-Coswid-22、2022年7月20日、<https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-22>。
[EAT] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-14, 10 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-14>.
[Eat] Lundblade、L.、Mandyam、G.、およびJ. O'Donoghue、「The Entity Atestation Token（Eat）」、Work in Progress、Internter-Draft、Draft-Itf-Rats-Eat-14、10 7月10日2022、<https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-14>。
[FILE] Wikipedia, "file (command)", 2 July 2022, <https://en.wikipedia.org/w/ index.php?title=File_(command)&oldid=1096086462>.
[ファイル] Wikipedia、 "file（command）"、2022年7月2日、<https://en.wikipedia.org/w/ index.php？title = file_（command）＆oldid = 1096086462>。
[IANA.CBOR-TAGS] IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
[iana.cbor-tags] iana、 "Concise binary Object Lespressation（CBOR）Tags"、<https://www.iana.org/assignments/cbor-tags>。
[IANA.CORE-PARAMETERS] IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[iana.core-parameters] iana、「制約付きの安らかな環境（コア）パラメーター」、<https://www.iana.org/assignments/core-parameters>。
[MAGIC] Bell Labs, "archive (library) file format", Unix Programmer's Manual, First Edition: File Formats, 3 November 1971, <https://www.bell-labs.com/usr/dmr/www/man51.pdf#page=4>.
[Magic] Bell Labs、「Archive（Library）File Format」、UNIX Programmer's Manual、初版：ファイルフォーマット、1971年11月3日、<https://www.bell-labs.com/usr/dmr/www/man51。PDF＃ページ= 4>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワークインターチェンジ用ASCII形式」、STD 80、RFC 20、DOI 10.17487/RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, <https://www.rfc-editor.org/info/rfc2781>.
[RFC2781] Hoffman、P。and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、DOI 10.17487/RFC2781、2000年2月、<https://www.rfc-editor.org/info/RFC2781>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487/RFC6838、2013年1月、<https：//www.rfc-editor.org/info/rfc6838>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「制約付きアプリケーションプロトコル（COAP）」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https：//www.rfc-editor。org/info/rfc7252>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、A。Rusch、 "PKCS＃1：RSA暗号仕様バージョン2.2"、RFC 8017、DOI 10.17487/RFC8017、2016年11月、<<<<<https://www.rfc-editor.org/info/rfc8017>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J。、「Cborオブジェクトの署名と暗号化（COSE）」、RFC 8152、DOI 10.17487/RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428] Jennings、C.、Shelby、Z.、Arkko、J.、Keranen、A。、およびC. Bormann、「センサー測定リスト（SENML）」、RFC 8428、DOI 10.17487/RFC8428、2018年8月、<httpsps：//www.rfc-editor.org/info/rfc8428>。
[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。、およびC. Bormann、「Scise Data Definition Language（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission", RFC 9177, DOI 10.17487/RFC9177, March 2022, <https://www.rfc-editor.org/info/rfc9177>.
[RFC9177] Boucadair、M。and J. Shallow、「制約付きアプリケーションプロトコル（COAP）堅牢な伝送をサポートするブロックワイズトランスファーオプション」、RFC 9177、DOI 10.17487/RFC9177、2022年3月、<https：//www.rfc-editor.org/info/rfc9177>。
[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, ISO/IEC 8825-1, February 2021, <https://www.itu.int/rec/T-REC-X.690>.
[X.690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコードルール（CER）および識別型エンコードルール（DER）の仕様」、ITU-T推奨X.690、ISO/IEC 8825-1、2021年2月、<https://www.itu.int/rec/t-rec-x.690>。
This document introduces a choice between wrapping a single CBOR data item into a pair of identifying CBOR tags or prepending an identifying encoded CBOR data item (which, in turn, contains a pair of identifying CBOR tags) to a CBOR Sequence (which might be a single data item).
このドキュメントでは、単一のCBORデータ項目を識別するCBORタグのペアにラッピングするか、識別されるエンコードされたCBORデータ項目（これには、識別するCBORタグのペアが含まれています）をCBORシーケンス（単一のデータ項目）。
Which should a protocol designer use?
プロトコル設計者はどちらを使用すべきですか？
In this discussion, one assumes that there is an object stored in a file, perhaps specified by a system operator in a configuration file.
この議論では、ファイルに保存されているオブジェクトがあると仮定します。おそらく、構成ファイルのシステム演算子によって指定されています。
For example: a private key used in COSE operations, a public key/ certificate in C509 [C509-CERT] or CBOR format, a recorded sensor reading stored for later transmission, or a COVID-19 vaccination certificate that needs to be displayed in QR code form.
例：COSE操作で使用される秘密鍵、C509 [C509-CERT]またはCBOR形式の公開キー/証明書、後の送信用に保存された録音センサーの読み取り、またはQRで表示する必要があるCOVID-19ワクチン接種証明書コードフォーム。
Both the Labeled CBOR Sequence and the wrapped tag can be trivially removed by an application before sending the CBOR content out on the wire.
ラベル付きのCBORシーケンスとラップされたタグの両方を、ワイヤー上にCBORコンテンツを送信する前に、アプリケーションによって簡単に削除できます。
The Labeled CBOR Sequence can be slightly easier to remove as, in most cases, CBOR parsers will return it as a unit and then return the actual CBOR item, which could be anything at all and could include CBOR tags that _do_ need to be sent on the wire.
ラベル付きのCBORシーケンスは、ほとんどの場合、CBORパーサーがユニットとして返品し、実際のCBORアイテムを返すため、削除をやや簡単に削除できます。ワイヤー。
On the other hand, having the Labeled CBOR Sequence in the file requires that all programs that expect to examine that file be able to skip what appears to be a CBOR item with two tags nested around a 3-byte byte string. The 3-byte entry is not of the format the program would normally have processed, so it may be a surprise. On the other hand, CBOR parsers are generally tolerant of tags that appear: many of them will process extra tags, making unknown tags available as meta information. A program that is not expecting those tags may just ignore them.
一方、ファイルにラベル付きのCBORシーケンスを使用するには、そのファイルを調べることを期待するすべてのプログラムが、3バイトのバイト文字列の周りにネストされた2つのタグを持つCBORアイテムのように見えるものをスキップできることが必要です。3バイトのエントリは、プログラムが通常処理する形式ではないため、驚きかもしれません。一方、CBORパーサーは一般に、表示されるタグに耐性があります。それらの多くは追加タグを処理し、未知のタグをメタ情報として使用できるようにします。これらのタグを期待していないプログラムは、それらを無視するだけかもしれません。
As an example of where there was a problem with previous security systems, "PEM" format certificate files grew to be able to contain multiple certificates by simple concatenation. The PKCS1 format [RFC8017] could also contain a private key object followed by one or more certificate objects, but only when in PEM format. Annoyingly, when in binary DER format ([X.690], which like CBOR is self-delimiting), concatenation of certificates was not compatible with most programs as they did not expect to read more than one item in the file.
以前のセキュリティシステムに問題があった場所の例として、「PEM」形式の証明書ファイルは、単純な連結によって複数の証明書を含めることができるようになりました。PKCS1形式[RFC8017]には、PEM形式の場合にのみ、1つ以上の証明書オブジェクトが続く秘密キーオブジェクトが含まれます。面倒なことに、バイナリDer形式（[x.690]、CBORのように自己緩和）では、証明書の連結は、ファイル内の複数のアイテムを読むとは思わなかったため、ほとんどのプログラムと互換性がありませんでした。
The use of CBOR Tag Wrapped format is easier to retrofit to an existing format with existing and unchangeable stored format for a single CBOR data item. This new sequence of tags is expected to be trivially ignored by many existing programs when reading CBOR from files or similar units of storage, even if the program only supports decoding a single data item (and not a CBOR sequence). But, a naive program might also then transmit the additional tags across the network. Removing the CBOR Tag Wrapped format requires knowledge of the two tags involved. Other tags present might be needed.
CBORタグラップフォーマットの使用は、単一のCBORデータ項目の既存の不変の保存形式を使用して、既存のフォーマットに簡単に後付けできます。この新しいシーケンスのシーケンスは、プログラムが単一のデータ項目のデコードのみをサポートしている場合でも（CBORシーケンスではなく）、ファイルまたは同様のストレージユニットからCBORを読み取るときに、多くの既存のプログラムによって簡単に無視されると予想されます。しかし、ナイーブプログラムは、ネットワーク全体に追加のタグを送信する可能性もあります。CBORタグラップフォーマットを削除するには、関連する2つのタグの知識が必要です。存在する他のタグが必要になる場合があります。
For a representation matching a specific media-type that is carried in a CBOR byte string, the byte string head will already have to be removed for use as such a representation, so it should be easy to remove the enclosing tag heads as well. This is of particular interest with the predefined tags provided in Appendix B for media types with CoAP Content-Format numbers.
CBORバイト文字列で運ばれる特定のメディアタイプに一致する表現の場合、そのような表現として使用するためにバイト文字列ヘッドを既に削除する必要があるため、囲まれたタグヘッドも簡単に削除できます。これは、COAPコンテンツ形式の数字を持つメディアタイプの付録Bに記載されている事前定義されたタグで特に興味深いものです。
Some considerations in the form of survey questions follow.
調査の質問の形でいくつかの考慮事項が続きます。
If the on-wire format is new, then it could be specified with the CBOR Tag Wrapped format if the extra 8 bytes are not a problem. The stored format is then identical to the on-wire format.
オンワイヤー形式が新品の場合、追加の8バイトが問題にならない場合は、CBORタグラップ形式で指定できます。保存された形式は、オンワイヤ形式と同じです。
If the 8 bytes are a problem on the wire (and they often are if CBOR is being considered), then the Labeled CBOR Sequence format should be adopted for the stored format.
8バイトがワイヤーの問題である場合（およびCBORが考慮されている場合にしばしばそうである）、保存された形式にラベル付きCBORシーケンス形式を採用する必要があります。
If the programs that read the contents of the file already expect to process all of the CBOR data items in the file (not just the first), then the Labeled CBOR Sequence format may be easily retrofitted.
ファイルの内容を読み取るプログラムが、ファイルだけでなく、ファイル内のすべてのCBORデータ項目を処理することを既に予想している場合、ラベル付きのCBORシーケンス形式は簡単に再生される場合があります。
The programs involved may throw errors or warnings on the Labeled CBOR Sequence if they have not yet been updated, but this may not be a problem.
関係するプログラムは、まだ更新されていない場合、ラベル付きCBORシーケンスにエラーまたは警告を投げることができますが、これは問題ではない場合があります。
There are situations where multiple objects may be concatenated into a single file. If each object is preceded by a Labeled CBOR Sequence label, then there may be multiple such labels in the file.
複数のオブジェクトが単一のファイルに連結される可能性がある状況があります。各オブジェクトの前にラベル付きのCBORシーケンスラベルがある場合、ファイルには複数のそのようなラベルが存在する場合があります。
A protocol based on CBOR Sequences may specify that Labeled CBOR Sequence labels can occur within a CBOR Sequence, possibly even to switch to data items following in the sequence that are of a different type.
CBORシーケンスに基づくプロトコルは、CBORシーケンスラベルがCBORシーケンス内で発生する可能性があることを指定する場合があり、おそらく異なるタイプのシーケンスに続くデータ項目に切り替えることもできます。
If the CBOR-Sequence-based protocol does not define the semantics for or at least tolerate embedded labels, care must be taken when concatenating Labeled CBOR Sequences to remove the label from all but the first part.
CBORシーケンスベースのプロトコルが、埋め込みラベルのセマンティクスを定義していない、または少なくとも許容するラベルのCBORシーケンスを連結する場合は、最初の部分を除くすべてのラベルを削除する場合は注意を払う必要があります。
| As an example from legacy PEM-encoded PKIX certificates, many
| programs accept a series of PKIX certificates in a single file
| in order to set up a certificate chain. The file would contain
| not just the End-Entity (EE) certificate, but also any
| subordinate certification authorities (CAs) needed to validate
| the EE. This mechanism actually only works for PEM-encoded
| certificates, and not DER-encoded certificates. One of the
| reasons for this specification is to make sure that CBOR-
| encoded certificates do not suffer from this problem.
|
| As an example of mixing of types, some TLS server programs also
| can accept both their PEM-encoded private key and their PEM-
| encoded certificate in the same file.
If only one item is ever expected in the file, the use of the Labeled CBOR Sequence may present an implementation hurdle to programs that previously just read a single data item and used it.
ファイルに1つのアイテムのみが予想される場合、ラベル付きのCBORシーケンスの使用は、以前に単一のデータ項目を読んで使用したプログラムに実装ハードルを提示する場合があります。
If the Protocol expects to use other tags at its top level, then the use of the CBOR Tag Wrapped format may be easy to explain at the same place in the protocol description.
プロトコルがそのトップレベルで他のタグを使用することを期待している場合、CBORタグラップ形式の使用は、プロトコルの説明の同じ場所で簡単に説明できる場合があります。
Section 5.10.3 of [RFC7252] defines the concept of a Content-Format, which is a short, 16-bit unsigned integer that identifies a specific content type (media type plus (optionally) parameters), optionally together with a content coding (see Section 8.4.1 of [RFC9110]).
[RFC7252]のセクション5.10.3は、コンテンツフォーマットの概念を定義します。コンテンツフォーマットは、特定のコンテンツタイプ（メディアタイプPlus（オプション）パラメーター）を識別する短い16ビットの署名されていない整数です。[RFC9110]のセクション8.4.1を参照してください。
Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the representation when it is stored in a file, in firmware, or when debugging.
表現のコンテンツフォーマットを示す転送プロトコルの外では、ファイル、ファームウェア、またはデバッグ時に保存されているときに、表現のコンテンツ形式を識別する必要がある場合があります。
This specification allocates CBOR tag numbers 1668546817 (0x63740101) to 1668612095 (0x6374FFFF) for the tagging of representations of specific content formats.
この仕様は、特定のコンテンツ形式の表現のタグ付けに、Cborタグ番号1668546817（0x63740101）に1668612095（0x6374ffff）に割り当てられます。
Using tags from this range, a byte string that is to be interpreted as a representation of Content-Format number ct, with ct < 65025 (255*255), can be identified by enclosing it in a tag with tag number TN(ct) where:
この範囲のタグを使用して、CT <65025（255*255）のコンテンツ形式番号CTの表現として解釈されるバイト文字どこ：
TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255.
TN（CT）= 0x63740101（CT / 255） * 256 CT％255。
(where +, *, / and % stand for integer addition, multiplication, division, and remainder as in the programming language C [C].)
（ *、 /および％は、整数の追加、乗算、分裂、および残りのプログラミング言語c [c]の略です。）
| This formula avoids the use of zero bytes in the representation
| of the tag number.
|
| Note that no tag numbers are assigned for Content-Format
| numbers in the following range:
|
| 65025 ≤ ct ≤ 65535
|
| (This range is in the range reserved for Experimental Use
| [RFC8126] by Section 12.3 of [RFC7252]. The overlap of 25 code
| points between this experimental range with the range this
| appendix defines tag numbers for can be used for experiments
| that want to employ a tag number.)
Exceptionally, when used immediately as tag content of one of the tags 55799, 55800, or 55801, the tag content is as follows:
例外的に、タグ55799、55800、または55801の1つのタグコンテンツとしてすぐに使用する場合、タグの内容は次のとおりです。
Tag 55799 (Section 2.2): One of:
タグ55799（セクション2.2）：1つ：
1. The CBOR data item within the representation (without byte-string wrapping). This only works for Content-Formats that are represented by a single CBOR data item in identity content-coding.
1. 表現内のCBORデータ項目（バイトストリングラッピングなし）。これは、IDコンテンツコーディングの単一のCBORデータ項目で表されるコンテンツフォーマットでのみ機能します。
2. The data items in the CBOR sequence within the representation, without byte string wrapping, but wrapped in a CBOR array. This works for Content-Formats that are represented by a CBOR sequence in identity content-coding.
2. バイト文字列を包むことなく、表現内のCBORシーケンス内のデータ項目は、CBORアレイに包まれています。これは、アイデンティティコンテンツコーディングのCBORシーケンスで表されるコンテンツフォーマットで機能します。
Tags 55800 (Section 2.3) or 55801 (Appendix D): the byte string 'BOR', signifying that the representation of the given content-format follows in the file, in the way defined for these tags.
タグ55800（セクション2.3）または55801（付録D）：バイト文字列「BOR」。特定のコンテンツフォーマットの表現が、これらのタグの定義方法でファイルに続くことを意味します。
The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] defines content formats that can be used as examples:
「COAPコンテンツフォーマット」レジストリ[IANA.CORE-PARAMETERS]は、例として使用できるコンテンツ形式を定義します。
* As discussed in Section 2.2.1, Content-Format ID 112 represents the application/senml+cbor media type (no parameters). The corresponding tag number is TN(112) = 1668546929.
* セクション2.2.1で説明したように、コンテンツフォーマットID 112は、アプリケーション/SENML CBORメディアタイプ（パラメーターなし）を表します。対応するタグ番号はTN（112）= 1668546929です。
The following CDDL snippet can be used to identify application/ senml+cbor representations:
次のCDDLスニペットを使用して、アプリケーション/ SENML CBOR表現を識別できます。
senml-cbor = #6.1668546929(bstr)
Note that a byte string is used as the type of the tag content because a media type representation in general can be any byte string.
一般的なメディアタイプの表現は任意のバイト文字列になる可能性があるため、バイト文字列はタグコンテンツのタイプとして使用されることに注意してください。
* Content-Format ID 272 represents the application/missing-blocks+cbor-seq media type, which is a CBOR sequence [RFC9177].
* Content-Format ID 272は、CBORシーケンス[RFC9177]であるアプリケーション/欠落ブロックCBOR-SEQメディアタイプを表します。
The corresponding tag number is TN(272) = 1668547090.
対応するタグ番号はTN（272）= 1668547090です。
The following CDDL snippet can be used to identify application/ missing-blocks+cbor-seq representations as embedded in a CBOR byte string:
次のCDDLスニペットを使用して、CBORバイト文字列に埋め込まれているアプリケーション/欠落ブロックCBOR-seq表現を識別できます。
missing-blocks = #6.1668547090(bstr)
The Openswan IPsec project has a daemon ("pluto") and two control programs ("addconn" and "whack"). They communicate via a Unix-domain socket, over which a C-structure containing pointers to strings is serialized using a bespoke mechanism. This is normally not a problem as the structure is compiled by the same compiler; but when there are upgrades, it is possible for the daemon and the control programs to get out of sync by the bespoke serialization. As a result, there are extra compensations to deal with shutting the daemon down. During testing, it is sometimes the case that upgrades are backed out.
OpenSwan IPSECプロジェクトには、デーモン（「Pluto」）と2つの制御プログラム（「AddConn」と「Whack」）があります。それらは、unixドメインソケットを介して通信します。このソケットでは、文字列へのポインターを含むC構造がオーダーメイドのメカニズムを使用してシリアル化されます。これは通常、構造が同じコンパイラによってコンパイルされるため、問題ではありません。しかし、アップグレードがある場合、デーモンと制御プログラムがオーダーメイドのシリアル化によって同期しなくなる可能性があります。その結果、デーモンを閉めることに対処するための追加の補償があります。テスト中、アップグレードがバックアウトされる場合があります。
In addition, when doing unit testing, the easiest way to load policy is to use the normal policy-reading process, but that is not normally loaded in the daemon. Instead, the IPC that is normally sent across the wire is compiled, serialized, and placed in a file. The above magic number is included in the file and on the IPC in order to distinguish the "shutdown" command CBOR operation.
さらに、単体テストを実行する場合、ポリシーをロードする最も簡単な方法は、通常のポリシー読解プロセスを使用することですが、通常はデーモンにはロードされません。代わりに、通常、ワイヤー全体に送信されるIPCがコンパイルされ、シリアル化され、ファイルに配置されます。上記のマジック番号は、「シャットダウン」コマンドCBOR操作を区別するために、ファイルとIPCに含まれています。
In order to reduce the problems due to serialization, the serialization is being changed to CBOR. Additionally, this change allows the IPC to be described by CDDL and any implementation language to be used that can encode CBOR.
シリアル化による問題を減らすために、シリアル化はCBORに変更されています。さらに、この変更により、IPCはCDDLおよびCBORをエンコードできる実装言語を使用することができます。
IANA has allocated the tag 1330664270 or 0x4f_50_53_4e for this purpose. As a result, each file and each IPC is prefixed with a CBOR Sequence tag.
IANAは、この目的のためにタグ1330664270または0x4F_50_53_4Eを割り当てました。その結果、各ファイルと各IPCにはCBORシーケンスタグが付いています。
In diagnostic notation:
診断表記：
55800(1330664270(h'424F52'))
55800（1330664270（h'424f52 '））
Or in hex:
または六角：
d9 d9f8 # tag(55800)
da 4f50534e # tag(1330664270)
43 # bytes(3)
424f52 # "BOR"
The CBOR-Labeled Non-CBOR data method is appropriate for adding a magic number to a Non-CBOR data format, particularly one that can be described by a Content-Format tag (Appendix B).
CBOR標識非CBORデータ法は、特にコンテンツフォーマットタグ（付録B）で説明できるマジック番号を非CBORデータ形式に追加するのに適しています。
This method prepends a CBOR data item to the Non-CBOR data; this data item is called the "header" and, similar to the Labeled CBOR-Sequence label, consists of two nested tags around a constant byte string for a total of 12 bytes.
このメソッドは、CBORデータ項目を非CBORデータにプレップします。このデータ項目は「ヘッダー」と呼ばれ、ラベル付きのCborシーケンスラベルと同様に、合計12バイトの定数バイト文字列の周りに2つのネストされたタグで構成されています。
1. The outer tag is the CBOR-Labeled Non-CBOR Data tag, 55801.
1. 外側のタグは、CBOR標識非cborデータタグ55801です。
2. The inner tag is a CBOR tag from the First Come First Served space that uniquely identifies the CBOR Protocol. As with CBOR Tag Wrapped, the use of a 4-byte tag is encouraged that encodes without zero bytes.
2. 内側のタグは、CBORプロトコルを独自に識別する最初の到着した最初に提供されるスペースのCBORタグです。cborタグラップと同様に、4バイトのタグの使用は、ゼロバイトなしでエンコードすることをお勧めします。
3. The tag content is a 3-byte CBOR byte string containing 0x42_4F_52 ('BOR' in diagnostic notation).
3. タグコンテンツは、0x42_4f_52（診断表記では「bor」）を含む3バイトのCborバイト文字列です。
The outer tag in the label identifies the file as being prefixed by a Non-CBOR data label and does so with all the desirable properties explained in Section 3.4.6 of [STD94]. Specifically, it does not appear to conflict with any known file types, and it is not valid Unicode in any Unicode encoding.
ラベルの外側のタグは、ファイルが非cborデータラベルが付いていると識別し、[std94]のセクション3.4.6で説明されているすべての望ましいプロパティを使用して識別します。具体的には、既知のファイルタイプと競合するようには見えず、Unicodeエンコードでは有効なUnicodeではありません。
The inner tag in the label identifies which Non-CBOR Protocol is used.
ラベルの内側のタグは、どの非cborプロトコルが使用されているかを識別します。
The inner tag content is a constant byte string that is represented as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR-encoded data item for the 3-byte string 0x42_4f_52 ('BOR' in diagnostic notation).
内側のタグコンテンツは、0x43_42_4f_52、ASCII文字「CBOR」として表される一定のバイト文字列です。これは、3バイトの文字列0x42_4F_52（診断表記の「bor」）のcborエンコードデータ項目です。
The actual Non-CBOR Protocol data then follow directly appended to the CBOR representation of the header. This allows the application to trivially remove the header item with the two nested tags and the byte string.
実際の非CBORプロトコルデータは、ヘッダーのCBOR表現に直接追加された後に続きます。これにより、アプリケーションは2つのネストされたタグとバイト文字列を使用してヘッダーアイテムを簡単に削除できます。
As with the Labeled CBOR Sequence {#sequences}, this choice of the tag content places the ASCII characters "CBOR" prominently into the header.
ラベル付きのCBORシーケンス{#Sequences}と同様に、タグコンテンツのこの選択は、ASCII文字「CBOR」をヘッダーに顕著に配置します。
The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] defines content formats that can be used as examples:
「COAPコンテンツフォーマット」レジストリ[IANA.CORE-PARAMETERS]は、例として使用できるコンテンツ形式を定義します。
* Content-Format ID 432 represents the application/td+json media type (no parameters).
* コンテンツフォーマットID 432は、アプリケーション/TD JSONメディアタイプ（パラメーターなし）を表します。
The corresponding tag number is TN(432) = 1668547250.
対応するタグ番号はTN（432）= 1668547250です。
The following CDDL snippet can be used to identify a CBOR-Labeled Non-CBOR data for application/td+json representations:
次のCDDLスニペットを使用して、アプリケーション/TD JSON表現のCBOR標識非CBORデータを識別できます。
td-json-header = #6.55801(#6.1668547250('BOR'))
* Content-Format 11050 represents the application/json media type in deflate content-coding.
* コンテンツフォーマット11050は、デフレートコンテンツコーディングのアプリケーション/JSONメディアタイプを表します。
The corresponding tag number is TN(11050) = 1668557910.
対応するタグ番号はTN（11050）= 1668557910です。
The following CDDL snippet can be used to identify a CBOR-Labeled Non-CBOR data for application/json representations compressed in deflate content-coding:
次のCDDLスニペットを使用して、DEFLATEコンテンツコーディングで圧縮されたアプリケーション/JSON表現のCBOR標識非CBORデータを識別できます。
json-deflate-header = #6.55801(#6.1668557910('BOR'))
Acknowledgements
謝辞
The CBOR WG brainstormed this protocol on January 20, 2021 via a number of productive email exchanges on the mailing list.
CBOR WGは、2021年1月20日にメーリングリストの多くの生産的な電子メール交換を介してこのプロトコルをブレインストーミングしました。
Contributors
貢献者
Josef 'Jeff' Sipek Email: jeffpc@josefsipek.net
Josef 'Jeff' Sipekメール：jeffpc@josefsipek.net
Authors' Addresses
著者のアドレス
Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca
Michael Richardson Sandelman Software Works Email：mcr ietf@sandelman.ca
Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org
Carsten BormannUniversitätBremenTziPostfach 330440 D-28359 Bremen Germany電話：49-421-218-63921メール：cabo@tzi.org