1.1. Requirements Terminology

1.1. 要件用語

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）」、「推奨されません（NOT RECOMMENDED）」、 「してもよいです（MAY）」、「選択できます（OPTIONAL）」は、 BCP 14 [RFC2119] [RFC8174]に記載されているとおりに解釈されるものとします。 ただし、ここに示すようにすべて大文字で表示される場合に限ります。

1.2. Changes from RFC 8152

1.2. RFC 8152からの変更点

• Split the original document into this document and [RFC9053].
• Added some text describing why there is no digest structure defined by COSE.
• Made text clarifications and changes in terminology.
• Removed all of the details relating to countersignatures and placed them in [COSE-COUNTERSIGN].

• 元の文書をこの文書と[RFC9053]に分割します。
• COSEによってダイジェスト構造が定義されていない理由について説明するテキストを追加しました。
• 用語の明確化や変更を行いました。
• [COSE-COUNTERSIGN]に関連するすべての詳細を削除しました。

1.3. Design Changes from JOSE

1.3. JOSEからの設計変更

• A single overall message structure has been defined so that encrypted, signed, and MACed messages can easily be identified and still have a consistent view.
• Signed messages distinguish between the protected and unprotected header parameters that relate to the content and those that relate to the signature.
• MACed messages are separated from signed messages.
• MACed messages have the ability to use the same set of recipient algorithms as enveloped messages for obtaining the MAC authentication key.
• Binary encodings are used, rather than base64url encodings, to encode binary data.
• The authentication tag for encryption algorithms has been combined with the ciphertext.
• The set of cryptographic algorithms has been expanded in some directions and trimmed in others.

• 暗号化、署名、およびMACが行われたメッセージを簡単に特定できるように、1つの完全なメッセージ構造が定義されています。これにより、一貫した表示が可能になります。
• 署名付きメッセージは、コンテンツに関連する保護されたヘッダーパラメーターと、署名に関連するものとを区別します。
• MACしたメッセージは署名付きメッセージから分離されます。
• MAC認証を行うメッセージは、MAC認証キーを取得するために、封入されたメッセージと同じ受信者アルゴリズムを使用することができます。
• バイナリーエンコーディングは、バイナリーデータをエンコードするために使用されます。base64urlエンコーディングではなく、バイナリーエンコーディングが使用されます。
• 暗号化アルゴリズムの認証タグは、暗号文と組み合わせられました。
• 暗号アルゴリズムのセットは、いくつかの方向で拡大され、他の方向では縮小されています。

1.4. CDDL Grammar for CBOR Data Structures

1.4. CBORデータ構造のためのCDDL文法

When COSE was originally written, the Concise Data Definition Language (CDDL) [RFC8610] had not yet been published in an RFC, so it could not be used as the data description language to normatively describe the CBOR data structures employed by COSE. For that reason, the CBOR data objects defined here are described in prose. Additional (non-normative) descriptions of the COSE data objects are provided in a subset of CDDL, described below.

COSEが最初に作成されたとき、簡潔なデータ定義言語（CDDL）[RFC8610]はまだRFCとして公開されていなかったため、COSEで使用されるCBORデータ構造を形式的に説明するためのデータ記述言語として使用することはできませんでした。そのため、ここで定義されているCBORデータオブジェクトは、文章で説明されています。COSEデータオブジェクトの追加の（非規範的な）説明は、以下で述べるCDDLのサブセットで提供されます。

This document was developed by first working on the grammar and then developing the prose to go with it. An artifact of this is that the prose was written using the primitive-type strings defined by Concise Data Definition Language (CDDL) [RFC8610]. In this specification, the following primitive types are used:

このドキュメントは、まず文法を作成し、それに関連する文書を作成することで開発されました。これにより、この文書はConcise Data Definition Language（CDDL）で定義されたプリミティブ型の文字列を使用して書かれました。この仕様では、以下のプリミティブ型が使用されます：

any:

A nonspecific value that permits all CBOR values to be placed here.

bool:

A boolean value (true: major type 7, value 21; false: major type 7, value 20).

bstr:

Byte string (major type 2).

int:

An unsigned integer or a negative integer.

nil:

A null value (major type 7, value 22).

nint:

A negative integer (major type 1).

tstr:

A UTF-8 text string (major type 3).

uint:

An unsigned integer (major type 0).

any:

すべてのCBOR値をここに配置することを許可する非特異的な値。

bool:

ブール値（true: メジャータイプ7、値21; false: メジャータイプ7、値20）。

bstr:

バイト文字列（メジャータイプ2）。

int:

符号なし整数または負の整数。

nil:

null値（メジャータイプ7、値22）。

nint:

負の整数（メジャータイプ1）。

tstr:

UTF-8テキスト文字列（メジャータイプ3）。

uint:

符号なし整数（メジャータイプ0）。

Three syntaxes from CDDL appear in this document as shorthand. These are:

このドキュメントでは、CDDLからの3つの構文が省略形として表示されます。これらは次の通りです：

FOO / BAR:

Indicates that either FOO or BAR can appear here.

[+ FOO]:

Indicates that the type FOO appears one or more times in an array.

* FOO:

Indicates that the type FOO appears zero or more times.

FOO / BAR:

ここにはFOOまたはBARが表示できることを示します。

[+ FOO]:

型FOOが配列内に1回以上現れることを示します。

* FOO:

型FOOが0回以上現れることを示します。

Two of the constraints defined by CDDL are also used in this document. These are:

このドキュメントでも、CDDLで定義されている制約のうち2つが使用されています。これらは次のとおりです：

type1 .cbor type2:

Indicates that the contents of type1, usually bstr, contains a value of type2.

type1 .size integer:

Indicates that the contents of type1 is integer bytes long.

type1 .cbor type2:

type1の内容（通常はbstr）がtype2の値を含むことを示します。

type1 .size integer:

type1の内容がintegerバイトであることを示します。

As well as the prose description, a grammar for the CBOR data structures is presented in the subset of CDDL described previously. The CDDL grammar is informational; the prose description is normative.

CBORデータ構造に関しては、これまでに述べたCDDLの一部において、プローズ記述に加えて文法の説明も提供されます。CDDLの文法は情報提供的ですが、プローズ記述は規範的です。

The collected CDDL can be extracted from the XML version of this document via the XPath expression below. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.)

次のXPath式を使用して、このドキュメントのXMLバージョンから収集されたCDDLを抽出できます（使用しているXPath評価器によっては、">"を実体として扱う必要がある場合もあります）。

CDDL expects the initial nonterminal symbol to be the first symbol in the file. For this reason, the first fragment of CDDL is presented here.

CDDLは、初期の非終端記号がファイル内の最初の記号であることを期待しています。そのため、最初のCDDLのフラグメントをここに示します。

The nonterminal Internal_Types is defined for dealing with the automated validation tools used during the writing of this document. It references those nonterminals that are used for security computations but are not emitted for transport.

非終端記号 Internal_Types は、この文書の作成中に使用される自動検証ツールの処理を行うために定義されます。これはセキュリティー計算に使用される非終端記号を参照しますが、輸送用には出力されません。

1.5. CBOR-Related Terminology

1.5. CBOR関連の用語

In JSON, maps are called objects and only have one kind of map key: a text string. In COSE, we use text strings, negative integers, and unsigned integers as map keys. The integers are used for compactness of encoding and easy comparison. The inclusion of text strings allows for an additional range of short encoded values to be used as well. Since the word "key" is mainly used in its other meaning, as a cryptographic key, we use the term "label" for this usage as a map key.

JSONでは、マップは「オブジェクト」と呼ばれ、テキスト文字列の一種しか持ちません。COSEでは、マップのキーとしてテキスト文字列、負の整数、および符号なし整数を使用します。整数はエンコードのコンパクトさと簡単な比較のために使用されます。テキスト文字列の含まれていることにより、追加の範囲の短いエンコード値が使用されることも可能です。単語「キー」は、主に暗号鍵としての意味で使用されるため、このマップのキーの用途には「ラベル」という用語を使用します。

In a CBOR map defined by this specification, the presence a label that is neither a text string nor an integer is an error. Applications can either fail processing or process messages by ignoring incorrect labels; however, they MUST NOT create messages with incorrect labels.

この仕様で定義されたCBORマップにおいて、テキスト文字列または整数ではないラベルの存在はエラーです。アプリケーションは処理を失敗するか、不正なラベルを無視してメッセージを処理することができますが、不正なラベルを持つメッセージを作成してはなりません（MUST NOT）。

A CDDL grammar fragment defines the nonterminal "label", as in the previous paragraph, and "values", which permits any value to be used.

CDDLの文法フラグメントでは、前の段落と同様に非終端記号 "label" と "values" が定義されており、"values" は任意の値の使用を許可しています。

1.6. Document Terminology

1.6. 文書の用語

In this document, we use the following terminology:

この文書では、以下の用語を使用します:

Byte:

A synonym for octet.

Constrained Application Protocol (CoAP):

A specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252].

Authenticated Encryption (AE) algorithms [RFC5116]:

Encryption algorithms that provide an authentication check of the contents along with the encryption service. An example of an AE algorithm used in COSE is AES Key Wrap [RFC3394]. These algorithms are used for key encryption, but Authenticated Encryption with Associated Data (AEAD) algorithms would be preferred.

AEAD algorithms [RFC5116]:

Encryption algorithms that provide the same authentication service of the content as AE algorithms do, and also allow associated data that is not part of the encrypted body to be included in the authentication service. An example of an AEAD algorithm used in COSE is AES-GCM [RFC5116]. These algorithms are used for content encryption and can be used for key encryption as well.

Byte:

オクテットの同義語。

Constrained Application Protocol (CoAP):

制約システムで使用するための特化したウェブ転送プロトコル。これは[RFC7252]で定義されています。

Authenticated Encryption (AE) algorithms [RFC5116]:

内容の認証チェックと暗号化サービスを提供する暗号化アルゴリズム。 COSEで使用されるAEアルゴリズムの一例はAES Key Wrap [RFC3394]です。 これらのアルゴリズムはキー暗号化に使用されますが、関連データ付きの認証暗号化（AEAD）アルゴリズムが好まれます。

AEAD algorithms [RFC5116]:

AEアルゴリズムと同じ認証サービスを内容に提供し、暗号化された本文の一部ではない関連データを認証サービスに含めることを可能にする暗号化アルゴリズム。COSEで使用されるAEADアルゴリズムの一例はAES-GCM [RFC5116]です。これらのアルゴリズムは内容の暗号化に使用され、キーの暗号化にも使用できます。

"Context" is used throughout the document to represent information that is not part of the COSE message. Information that is part of the context can come from several different sources, including protocol interactions, associated key structures, and program configuration. The context to use can be implicit, identified using the "kid context" header parameter defined in [RFC8613], or identified by a protocol-specific identifier. Context should generally be included in the cryptographic construction; for more details, see Section 4.3.

「コンテキスト」は、COSEメッセージの一部ではない情報を表すために文書全体で使用されます。コンテキストの一部となる情報は、プロトコルの相互作用、関連するキー構造、およびプログラムの構成など、複数の異なるソースから提供されることがあります。使用するコンテキストは、暗黙的なものであるか、[RFC8613]で定義された「kid context」ヘッダーパラメーターを使用して特定することもできます。または、プロトコル固有の識別子によって特定されることもあります。一般的には、暗号構築にコンテキストを含めるべきです。詳細については、Section 4.3を参照してください。

The term "byte string" is used for sequences of bytes, while the term "text string" is used for sequences of characters.

「バイト列」という用語は、バイトの連続性を表すために使用されます。一方、「テキスト文字列」という用語は、文字の連続性を表すために使用されます。

3.1. Common COSE Header Parameters

3.1. 共通のCOSEヘッダーパラメーター

This section defines a set of common header parameters. A summary of these header parameters can be found in Table 3. This table should be consulted to determine the value of the label and the type of the value.

このセクションでは、一連の共通ヘッダーパラメーターを定義します。これらのヘッダーパラメーターの概要は、Table 3に記載されています。このテーブルは、ラベルの値と値のタイプを判断するために参照する必要があります。

The set of header parameters defined in this section is as follows:

このセクションで定義されたヘッダーパラメーターのセットは以下のとおりです：

alg:

This header parameter is used to indicate the algorithm used for the security processing. This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (e.g., COSE_Sign and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected-header-parameters bucket or as part of the externally supplied data (Section 4.3). The value is taken from the "COSE Algorithms" registry (see [COSE.Algorithms]).

crit:

This header parameter is used to indicate which protected header parameters an application that is processing a message is required to understand. Header parameters defined in this document do not need to be included, as they should be understood by all implementations. Additionally, the header parameter "counter signature" (label 7) defined by [RFC8152] must be understood by new implementations, to remain compatible with senders that adhere to that document and assume all implementations will understand it. When present, the "crit" header parameter MUST be placed in the protected-header-parameters bucket. The array MUST have at least one value in it.

Not all header-parameter labels need to be included in the "crit" header parameter. The rules for deciding which header parameters are placed in the array are:

• Integer labels in the range of 0 to 7 SHOULD be omitted.
• Integer labels in the range -1 to -128 can be omitted. Algorithms can assign labels in this range where the ability to process the content of the label is considered to be core to implementing the algorithm. Algorithms can assign labels outside of this range and include them in the "crit" header parameter when the ability to process the content of the label is not considered to be core functionality of the algorithm but does need to be understood to correctly process this instance. Integer labels in the range -129 to -65536 SHOULD be included, as these would be less common header parameters that might not be generally supported.
• Labels for header parameters required for an application MAY be omitted. Applications should have a statement declaring whether or not the label can be omitted.

The header parameters indicated by "crit" can be processed by either the security-library code or an application using a security library; the only requirement is that the header parameter is processed. If the "crit" value list includes a label for which the header parameter is not in the protected-header-parameters bucket, this is a fatal error in processing the message.

content type:

This header parameter is used to indicate the content type of the data in the "payload" or "ciphertext" field. Integers are from the "CoAP Content-Formats" IANA registry table [COAP.Formats]. Text values follow the syntax of "<type-name>/<subtype-name>", where <type-name> and <subtype-name> are defined in Section 4.2 of [RFC6838]. Leading and trailing whitespace is not permitted. Textual content type values, along with parameters and subparameters, can be located using the IANA "Media Types" registry. Applications SHOULD provide this header parameter if the content structure is potentially ambiguous.

kid:

This header parameter identifies one piece of data that can be used as input to find the needed cryptographic key. The value of this header parameter can be matched against the "kid" member in a COSE_Key structure. Other methods of key distribution can define an equivalent field to be matched. Applications MUST NOT assume that "kid" values are unique. There may be more than one key with the same "kid" value, so all of the keys associated with this "kid" may need to be checked. The internal structure of "kid" values is not defined and cannot be relied on by applications. Key identifier values are hints about which key to use. This is not a security-critical field. For this reason, it can be placed in the unprotected-header-parameters bucket.

IV:

This header parameter holds the Initialization Vector (IV) value. For some symmetric encryption algorithms, this may be referred to as a nonce. The IV can be placed in the unprotected bucket, since for AE and AEAD algorithms, modifying the IV will cause the decryption to fail.

Partial IV:

This header parameter holds a part of the IV value. When using the COSE_Encrypt0 structure, a portion of the IV can be part of the context associated with the key (Context IV), while a portion can be changed with each message (Partial IV). This field is used to carry a value that causes the IV to be changed for each message. The Partial IV can be placed in the unprotected bucket, as modifying the value will cause the decryption to yield plaintext that is readily detectable as garbled. The "Initialization Vector" and "Partial Initialization Vector" header parameters MUST NOT both be present in the same security layer.

The message IV is generated by the following steps:

1. Left-pad the Partial IV with zeros to the length of IV (determined by the algorithm).
2. XOR the padded Partial IV with the Context IV.

alg:

このヘッダーパラメーターは、セキュリティー処理に使用されるアルゴリズムを示すために使用されます。このヘッダーパラメーターは、その能力が存在する場所で認証されなければなりません（MUST）。このサポートは、AEADアルゴリズムまたは構造（例：COSE_SignおよびCOSE_Mac0）によって提供されます。この認証は、ヘッダーパラメーターを保護されたヘッダーパラメーターバケットに配置するか、外部から提供されるデータの一部として行うことができます（Section 4.3参照）。値は"COSE Algorithms"レジストリから取得されます（[COSE.Algorithms]参照）。

crit:

このヘッダーパラメーターは、メッセージを処理しているアプリケーションが理解する必要がある保護ヘッダーパラメーターを示すために使用されます。このドキュメントで定義されたヘッダーパラメーターは、すべての実装が理解できる必要があるため、含める必要はありません。さらに、[RFC8152]で定義されたヘッダーパラメーター「counter signature」（ラベル7）は、新しい実装が理解する必要があります。これは、そのドキュメントに従っており、すべての実装がそれを理解すると想定されている送信者との互換性を維持するためです。存在する場合、「crit」ヘッダーパラメーターは保護ヘッダーパラメーターのバケット内に配置される必要があります（MUST）。配列は少なくとも1つの値を持つ必要があります（MUST）。

「crit」ヘッダーパラメーターには、すべてのヘッダーパラメーターラベルを含める必要はありません。配列にどのヘッダーパラメーターが配置されるかを決定するルールは次のとおりです：

• 0から7の範囲内の整数ラベルは省略すべきです（SHOULD）
• 整数ラベルの範囲が-1から-128の場合、省略することができます。 アルゴリズムは、ラベルのコンテンツを処理する能力がアルゴリズムの実装の中核であると考えられる場合、この範囲内でラベルを割り当てることができます。 アルゴリズムは、ラベルのコンテンツの処理能力がコアの機能ではないが、このインスタンスを正しく処理するために理解する必要がある場合に、この範囲外でラベルを割り当て、それらを「crit」ヘッダーパラメーターに含めることができます。 -129から-65536の範囲内の整数ラベルを含むべきです（SHOULD）。 これらのラベルは一般的にサポートされない可能性のある一般的でないヘッダーパラメーターです。
• headerパラメーターに必要なラベルは、省略してもよいです（MAY）。アプリケーションは、ラベルを省略できるかどうかを宣言する文を持つべきです。

"crit"によって示されるヘッダーパラメーターは、セキュリティーライブラリを使用するアプリケーションまたはセキュリティーライブラリコードによって処理することができます。唯一の要件は、ヘッダーパラメーターが処理されることです。"crit"の値リストに、保護されたヘッダーパラメーターのバケットにないヘッダーパラメーターのラベルが含まれている場合、これはメッセージの処理における致命的なエラーです。

content type:

このヘッダーパラメーターは、"payload"または"ciphertext"フィールドのデータのコンテンツタイプを示すために使用されます。整数は"CoAP Content-Formats" IANAレジストリテーブル[COAP.Formats]から取得されます。テキスト値は"<type-name>/<subtype-name>"の構文に従います。ここで、<type-name>と<subtype-name>は[RFC6838]のSection 4.2で定義されています。先頭と末尾の空白は許可されません。テキストのコンテンツタイプ値、パラメーター、およびサブパラメーターは、IANAの"Media Types"レジストリを使用して検索できます。コンテンツ構造が曖昧になる可能性がある場合、アプリケーションはこのヘッダーパラメーターを提供すべきです（SHOULD）。

kid:

このヘッダーパラメーターは、必要な暗号化キーを見つけるための入力として使用できるデータの一部を識別します。このヘッダーパラメーターの値は、COSE_Key構造の"kid"メンバーと一致させることができます。他のキー配布方法は、一致させるための同等のフィールドを定義できます。アプリケーションは"kid"値が一意であると仮定してはなりません（MUST NOT）。同じ"kid"値を持つキーが複数存在する可能性があるため、この"kid"に関連するすべてのキーをチェックする必要があるかもしれません。"kid"値の内部構造は定義されておらず、アプリケーションによって依存されてはなりません。キー識別子の値は、どのキーを使用するべきかについてのヒントです。これはセキュリティー上重要なフィールドではありません。このため、保護されていないヘッダーパラメーターバケットに配置することができます。

IV:

このヘッダーパラメーターは初期化ベクトル（IV）の値を保持します。一部の対称暗号化アルゴリズムでは、これをnonceと呼ぶこともあります。IVは保護されていないバケットに配置することができ、なぜならAEおよびAEADアルゴリズムでは、IVを変更すると復号化が失敗するからです。

Partial IV:

このヘッダーパラメーターはIV値の一部を保持します。COSE_Encrypt0構造を使用する場合、IVの一部はキーと関連付けられたコンテキストIVであり、一部は各メッセージごとに変更されることができる（部分IV）。このフィールドは、IVが各メッセージごとに変更される原因となる値を運ぶために使用されます。部分IVは保護されていないバケットに配置することができますが、値を変更すると、復号化結果の平文が乱れたものとして容易に検出できます。"Initialization Vector"および"Partial Initialization Vector"のヘッダーパラメーターは、同じセキュリティーレイヤー内にしてはなりません（MUST NOT）。

メッセージIVは、次の手順で生成されます：

1. Partial IVをゼロで左側をパディングして、IVの長さ（アルゴリズムによって決定される）に合わせてください。
2. パディングされた部分IVをコンテキストIVとXORします。

The CDDL fragment that represents the set of header parameters defined in this section is given below. Each of the header parameters is tagged as optional, because they do not need to be in every map; header parameters required in specific maps are discussed above.

このセクションで定義されたヘッダーパラメーターのセットを表すCDDLフラグメントは以下の通りです。各ヘッダーパラメーターはオプションとしてタグ付けされています。なぜなら、すべてのマップに含まれる必要はないためです。特定のマップで必要とされるヘッダーパラメーターについては、上記で説明されています。

4.1. Signing with One or More Signers

4.1. 1人以上の署名者で署名する

The COSE_Sign structure allows for one or more signatures to be applied to a message payload. Header parameters relating to the content and header parameters relating to the signature are carried along with the signature itself. These header parameters may be authenticated by the signature, or just be present. An example of a header parameter about the content is the content type header parameter. An example of a header parameter about the signature would be the algorithm and key used to create the signature.

COSE_Sign構造体では、1つ以上の署名をメッセージのペイロードに適用することができます。コンテンツに関連するヘッダーパラメーターと署名に関連するヘッダーパラメーターは、署名自体と共に運ばれます。これらのヘッダーパラメーターは、署名によって認証される場合もあれば、単に存在するだけの場合もあります。コンテンツに関するヘッダーパラメーターの例としては、コンテンツタイプのヘッダーパラメーターがあります。署名に関するヘッダーパラメーターの例としては、署名を作成するために使用されるアルゴリズムと鍵があります。

[RFC5652] indicates that:

[RFC5652] は、次のことを示しています：

For example, the COSE_Sign structure might include signatures generated with the Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032] and the Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS]. This allows recipients to verify the signature associated with one algorithm or the other. More detailed information on multiple signature evaluations can be found in [RFC5752].

たとえば、COSE_Sign構造は、エドワーズ曲線デジタル署名アルゴリズム（EdDSA）[RFC8032]および楕円曲線デジタル署名アルゴリズム（ECDSA）[DSS]で生成された署名を含む場合があります。これにより、受信者はどちらかのアルゴリズムに関連付けられた署名を検証することができます。複数の署名評価に関する詳細は、[RFC5752]で見つけることができます。

The signature structure can be encoded as either tagged or untagged, depending on the context it will be used in. A tagged COSE_Sign structure is identified by the CBOR tag 98. The CDDL fragment that represents this is:

署名構造は、使用される文脈に応じて、タグ付きまたはタグなしでエンコードすることができます。タグ付きのCOSE_Sign構造は、CBORタグ98で識別されます。これを表すCDDLフラグメントは次のとおりです：

A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the message is called the COSE_Sign structure. The CBOR object that carries the signature and information about the signature is called the COSE_Signature structure. Examples of COSE Signed Messages can be found in Appendix C.1.

COSE署名メッセージは2つの部分で定義されています。メッセージの本体と情報を運ぶCBORオブジェクトはCOSE_Sign構造と呼ばれます。署名と署名に関する情報を運ぶCBORオブジェクトはCOSE_Signature構造と呼ばれます。COSE署名メッセージの例は、Appendix C.1で見つけることができます。

The COSE_Sign structure is a CBOR array. The fields of the array, in order, are:

COSE_Sign構造体は、CBOR配列です。配列のフィールドは、順に以下の通りです：

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

payload:

This field contains the serialized content to be signed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately ("detached content"), then a nil CBOR object is placed in this location, and it is the responsibility of the application to ensure that it will be transported without changes.

Note: When a signature with a message recovery algorithm is used (Section 8.1), the maximum number of bytes that can be recovered is the length of the original payload. The size of the encoded payload is reduced by the number of bytes that will be recovered. If all of the bytes of the original payload are consumed, then the transmitted payload is encoded as a zero-length byte string rather than as being absent.

signatures:

This field is an array of signatures. Each signature is represented as a COSE_Signature structure.

protected:

これはSection 3で説明されている通りです。

unprotected:

これはSection 3で説明されている通りです。

payload:

このフィールドには署名されるシリアライズされたコンテンツが含まれています。メッセージにペイロードが存在しない場合は、アプリケーションは別途ペイロードを提供する必要があります。ペイロードは、変更なしで輸送されることを確保するために、bstrでラップされます。ペイロードが別途輸送される場合（「分離されたコンテンツ」）、この場所には nil のCBORオブジェクトが配置され、アプリケーションはそれが変更なしで輸送されることを保証する責任を持つ必要があります。

注：メッセージ回復アルゴリズムを使用した場合（Section 8.1）、回復できる最大バイト数は元のペイロードの長さです。エンコードされたペイロードのサイズは、回復されるバイト数だけ減少します。元のペイロードのすべてのバイトが消費された場合、送信ペイロードは不在ではなく、長さゼロのバイト文字列としてエンコードされます。

signatures:

このフィールドは署名の配列です。各署名はCOSE_Signature構造として表されます。

The CDDL fragment that represents the above text for COSE_Sign follows.

上記のテキストのCOSE_Sign用のCDDLフラグメントは、次のようになります。

The COSE_Signature structure is a CBOR array. The fields of the array, in order, are:

COSE_Signature構造体はCBOR配列です。配列のフィールドは、次の順序で配置されます。

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

signature:

This field contains the computed signature value. The type of the field is a bstr. Algorithms MUST specify padding if the signature value is not a multiple of 8 bits.

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

signature:

This field contains the computed signature value. The type of the field is a bstr. Algorithms MUST specify padding if the signature value is not a multiple of 8 bits.

The CDDL fragment that represents the above text for COSE_Signature follows.

上記のテキストを表すCOSE_SignatureのCDDLフラグメントは次の通りです。

4.2. Signing with One Signer

4.2. 1人の署名者で署名する

The COSE_Sign1 signature structure is used when only one signature is going to be placed on a message. The header parameters dealing with the content and the signature are placed in the same pair of buckets, rather than having the separation of COSE_Sign.

COSE_Sign1署名構造は、メッセージに1つの署名のみを配置する場合に使用されます。コンテンツおよび署名に関連するヘッダーパラメーターは、COSE_Signの分離ではなく、同じブケットに配置されます。

The structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Sign1 structure is identified by the CBOR tag 18. The CDDL fragment that represents this is:

構造は、使用されるコンテキストに応じてタグ付きまたはタグなしでエンコードできます。タグ付きのCOSE_Sign1構造は、CBORタグ18で識別されます。これを示すCDDLフラグメントは次のようになります：

The CBOR object that carries the body, the signature, and the information about the body and signature is called the COSE_Sign1 structure. Examples of COSE_Sign1 messages can be found in Appendix C.2.

COSE_Sign1構造体は、本文、署名、本文と署名に関する情報を含むCBORオブジェクトを運ぶものです。COSE_Sign1メッセージの例は、Appendix C.2にあります。

The COSE_Sign1 structure is a CBOR array. The fields of the array, in order, are:

COSE_Sign1構造体は、CBOR配列です。配列の順序でフィールドが以下になります：

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

payload:

This is as described in Section 4.1.

signature:

This field contains the computed signature value. The type of the field is a bstr.

protected:

これはSection 3で説明されている通りです。

unprotected:

これはSection 3で説明されている通りです。

payload:

これはSection 4.1で説明されている通りです。

signature:

このフィールドには計算された署名値が含まれます。フィールドのタイプはbstrです。

The CDDL fragment that represents the above text for COSE_Sign1 follows.

上記のテキストに対応するCOSE_Sign1のCDDLフラグメントは以下の通りです。

4.3. Externally Supplied Data

4.3. 外部から供給されるデータ

One of the features offered in COSE is the ability for applications to provide additional data that is to be authenticated but is not carried as part of the COSE object. The primary reason for supporting this can be seen by looking at the CoAP message structure [RFC7252], where the facility exists for options to be carried before the payload. Examples of data that can be placed in this location would be the CoAP code or CoAP options. If the data is in the headers of the CoAP message, then it is available for proxies to help in performing proxying operations. For example, the Accept option can be used by a proxy to determine if an appropriate value is in the proxy's cache. The sender can use the additional-data functionality to enable detection of any changes to the set of Accept values made by a proxy or an attacker. By including the field in the externally supplied data, any subsequent modification will cause the server processing of the message to result in failure.

COSEで提供される機能の1つは、COSEオブジェクトの一部として運ばれることはないが、認証される追加データをアプリケーションが提供する能力です。これをサポートする主な理由は、CoAPメッセージ構造[RFC7252]を見ることで理解できます。CoAPメッセージのペイロードの前にオプションを運ぶための仕組みが存在します。この場所に配置できるデータの例としては、CoAPコードやCoAPオプションがあります。データがCoAPメッセージのヘッダーにある場合、プロキシがプロキシ操作を行う際に使用することができます。たとえば、プロキシはAcceptオプションを使用して、プロキシのキャッシュに適切な値が含まれているかどうかを判断することができます。送信者は、追加データの機能を使用して、プロキシまたは攻撃者によってAccept値のセットに行われた変更を検出することができます。外部から提供されたデータにフィールドを含めることで、後続の変更はサーバーのメッセージ処理に失敗を引き起こします。

This document describes the process for using a byte array of externally supplied authenticated data; the method of constructing the byte array is a function of the application. Applications that use this feature need to define how the externally supplied authenticated data is to be constructed. Such a construction needs to take into account the following issues:

この文書は、外部から供給された認証データのバイト配列を使用するプロセスについて説明します。バイト配列の構築方法は、アプリケーションの関数です。この機能を使用するアプリケーションは、外部から供給された認証データの構築方法を定義する必要があります。そのような構築は、以下の問題を考慮する必要があります：しなければなりません（MUST）。

• If multiple items are included, applications need to ensure that the same byte string cannot be produced if there are different inputs. An example of how the problematic scenario could arise would be by concatenating the text strings "AB" and "CDE" or by concatenating the text strings "ABC" and "DE". This is usually addressed by making fields a fixed width and/or encoding the length of the field as part of the output. Using options from CoAP [RFC7252] as an example, these fields use a TLV structure so they can be concatenated without any problems.
• If multiple items are included, an order for the items needs to be defined. Using options from CoAP as an example, an application could state that the fields are to be ordered by the option number.
• Applications need to ensure that the byte string is going to be the same on both sides. Using options from CoAP might give a problem if the same relative numbering is kept. An intermediate node could insert or remove an option, changing how the relative numbering is done. An application would need to specify that the relative number must be re-encoded to be relative only to the options that are in the external data.

• 複数のアイテムが含まれている場合、アプリケーションは、異なる入力がある場合に同じバイト文字列が生成されないようにする必要があります。問題が発生する可能性のあるシナリオの例として、「AB」と「CDE」というテキスト文字列を連結するか、「ABC」と「DE」というテキスト文字列を連結することが挙げられます。これは通常、フィールドを固定幅にするか、出力の一部としてフィールドの長さをエンコードすることで対処されます。CoAPのオプションを使用する場合、これらのフィールドはTLV構造を使用して連結することができ、問題はありません。
• 複数の項目が含まれる場合、各項目の順序が定義される必要があります。CoAPのオプションを例にすると、アプリケーションはフィールドの順序をオプション番号で指定することができます。
• アプリケーションは、バイト文字列が両側で同じになることを確認する必要があります。CoAPのオプションを使用すると、同じ相対番号が保持される場合に問題が発生する可能性があります。中間ノードはオプションを挿入または削除することができ、相対番号付けが変更されます。アプリケーションは、相対番号が外部データにあるオプションにのみ相対的であるように再エンコードされる必要があることを指定する必要があります。

4.4. Signing and Verification Process

4.4. 署名と検証プロセス

In order to create a signature, a well-defined byte string is needed. The Sig_structure is used to create the canonical form. This signing and verification process takes in the body information (COSE_Sign or COSE_Sign1), the signer information (COSE_Signature), and the application data (external source). A Sig_structure is a CBOR array. The fields of the Sig_structure, in order, are:

署名を作成するためには、明確に定義されたバイト文字列が必要です。Sig_structureは正規形を作成するために使用されます。この署名および検証プロセスでは、本文情報（COSE_SignまたはCOSE_Sign1）、署名者情報（COSE_Signature）、およびアプリケーションデータ（外部ソース）を受け取ります。Sig_structureはCBOR配列です。Sig_structureのフィールドは、順序どおりに次のとおりです：

1. A context text string identifying the context of the signature. The context text string is:

   • "Signature" for signatures using the COSE_Signature structure.
   • "Signature1" for signatures using the COSE_Sign1 structure.
2. The protected attributes from the body structure, encoded in a bstr type. If there are no protected attributes, a zero-length byte string is used.
3. The protected attributes from the signer structure, encoded in a bstr type. If there are no protected attributes, a zero-length byte string is used. This field is omitted for the COSE_Sign1 signature structure.
4. The externally supplied data from the application, encoded in a bstr type. If this field is not supplied, it defaults to a zero-length byte string. (See Section 4.3 for application guidance on constructing this field.)
5. The payload to be signed, encoded in a bstr type. The full payload is used here, independent of how it is transported.

1.   承認の文脈を識別する文脈テキスト文字列です。文脈テキスト文字列は次のとおりです：

   • COSE_Signature構造を使用する署名の場合、「Signature」とします。
   • COSE_Sign1構造を使用する署名の場合、「Signature1」とします。
2. 本文構造から保護された属性を、bstrタイプでエンコードします。保護された属性がない場合は、長さゼロのバイト列が使用されます。
3. 署名者構造体からの保護属性は、bstr型でエンコードされます。保護属性が存在しない場合は、長さがゼロのバイト列が使用されます。このフィールドは、COSE_Sign1署名構造体では省略されます。
4. アプリケーションからの外部で提供されるデータは、bstr型でエンコードされます。このフィールドが提供されていない場合、長さがゼロのバイト文字列としてデフォルト値が設定されます。このフィールドの構築に関するアプリケーションのガイダンスについては、Section 4.3を参照してください。
5. 署名されるべきペイロードは、bstr型でエンコードされます。ここでは、それがどのように輸送されるかに関係なく、完全なペイロードが使用されます。

The CDDL fragment that describes the above text is:

上記のテキストを記述するCDDLフラグメントは次の通りです：

How to compute a signature:

署名の計算方法:

1. Create a Sig_structure and populate it with the appropriate fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 9.
3. Call the signature creation algorithm, passing in K (the key to sign with), alg (the algorithm to sign with), and ToBeSigned (the value to sign).
4. Place the resulting signature value in the correct location. This is the "signature" field of the COSE_Signature or COSE_Sign1 structure.

1. Sig_structureを作成し、適切なフィールドでそれを埋めます。
2. Section 9で説明されているエンコーディングを使用して、Sig_structureをバイト文字列にエンコードして、値ToBeSignedを作成します。
3. K (署名に使用するキー)、alg (署名に使用するアルゴリズム)、および ToBeSigned (署名する値) を指定して、署名作成アルゴリズムを呼び出します。
4. 生成された署名値を適切な位置に配置します。これは、COSE_SignatureまたはCOSE_Sign1構造体の「signature」フィールドです。

The steps for verifying a signature are:

署名を検証する手順は次の通りです：

1. Create a Sig_structure and populate it with the appropriate fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 9.
3. Call the signature verification algorithm, passing in K (the key to verify with), alg (the algorithm used to sign with), ToBeSigned (the value to sign), and sig (the signature to be verified).

1. 適切なフィールドを持つSig_structureを作成し、それを埋める。
2. Sig_structureをバイト文字列にエンコードして、encodingにSection 9で説明されたエンコーディングを使用して、ToBeSignedの値を作成します。
3. 署名検証アルゴリズムを呼び出し、K（検証に使用するキー）、alg（署名に使用するアルゴリズム）、ToBeSigned（署名する値）、sig（検証する署名）を渡します。

In addition to performing the signature verification, the application performs the appropriate checks to ensure that the key is correctly paired with the signing identity and that the signing identity is authorized before performing actions.

アプリケーションは、署名の検証を行うだけでなく、アクションを実行する前に、キーが署名者の身元と正しくペアリングされていること、および署名者の身元が認証されていることを確認するための適切なチェックを行います。

5.1. Enveloped COSE Structure

5.1. 包含されたCOSE構造

The enveloped structure allows for one or more recipients of a message. There are provisions for header parameters about the content and header parameters about the recipient information to be carried in the message. The protected header parameters associated with the content are authenticated by the content encryption algorithm. The protected header parameters associated with the recipient (when the algorithm supports it) are authenticated by the recipient algorithm. Examples of header parameters about the content are the type of the content and the content encryption algorithm. Examples of header parameters about the recipient are the recipient's key identifier and the recipient's encryption algorithm.

送られるメッセージには、1人以上の受信者が存在する場合、封入構造が利用されます。メッセージ内には、コンテンツに関するヘッダーパラメーターと受信者情報に関するヘッダーパラメーターに関する規定があります。コンテンツに関連する保護されたヘッダーパラメーターは、コンテンツの暗号化アルゴリズムによって認証されます。受信者に関連する保護されたヘッダーパラメーター（アルゴリズムがサポートしている場合）は、受信者のアルゴリズムによって認証されます。コンテンツに関するヘッダーパラメーターの例は、コンテンツの種類とコンテンツの暗号化アルゴリズムです。受信者に関するヘッダーパラメーターの例は、受信者の鍵識別子と受信者の暗号化アルゴリズムです。

The same techniques and nearly the same structure are used for encrypting both the plaintext and the keys. This is different from the approach used by both "Cryptographic Message Syntax (CMS)" [RFC5652] and "JSON Web Encryption (JWE)" [RFC7516], where different structures are used for the content layer and the recipient layer. Two structures are defined: COSE_Encrypt to hold the encrypted content and COSE_recipient to hold the encrypted keys for recipients. Examples of enveloped messages can be found in Appendix C.3.

同じ技術とほぼ同じ構造が、平文とキーの両方を暗号化するために使用されます。これは、「暗号メッセージ構文（CMS）」[RFC5652]と「JSON Web Encryption（JWE）」[RFC7516]の両方が使用するアプローチとは異なります。異なる構造がコンテンツ層と受信者層に使用されるのに対して、2つの構造が定義されています。COSE_Encryptは暗号化されたコンテンツを保持し、COSE_recipientは受信者の暗号化されたキーを保持します。封入されたメッセージの例は、Appendix C.3で見つけることができます。

The COSE_Encrypt structure can be encoded as either tagged or untagged, depending on the context it will be used in. A tagged COSE_Encrypt structure is identified by the CBOR tag 96. The CDDL fragment that represents this is:

COSE_Encrypt構造体は、使用されるコンテキストに応じて、taggedまたはuntaggedのいずれかとしてエンコードされることがあります。taggedなCOSE_Encrypt構造体は、CBORタグ96によって識別されます。これを表すCDDLフラグメントは次の通りです：

The COSE_Encrypt structure is a CBOR array. The fields of the array, in order, are:

COSE_Encrypt構造体はCBOR配列です。配列のフィールドは、以下の順序であります：

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

ciphertext:

This field contains the ciphertext, encoded as a bstr. If the ciphertext is to be transported independently of the control information about the encryption process (i.e., detached content), then the field is encoded as a nil value.

recipients:

This field contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient.

protected:

これは、Section 3で説明されている通りです。

unprotected:

これは、Section 3で説明されている通りです。

ciphertext:

このフィールドには、bstrとしてエンコードされた暗号文が含まれています。暗号文が暗号化プロセスの制御情報（つまり、分離されたコンテンツ）から独立して輸送される場合、このフィールドはnil値としてエンコードされます。

recipients:

このフィールドには、受信者情報構造の配列が含まれています。受信者情報構造のタイプはCOSE_recipientです。

The CDDL fragment that corresponds to the above text is:

上記のテキストに対応するCDDLフラグメントは以下の通りです：

The COSE_recipient structure is a CBOR array. The fields of the array, in order, are:

COSE_recipient構造はCBOR配列です。配列のフィールドは、順に次の通りです。

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

ciphertext:

This field contains the encrypted key, encoded as a bstr. All encoded keys are symmetric keys; the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value.

recipients:

This field contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient (an example of this can be found in Appendix B). If there are no recipient information structures, this element is absent.

protected:

これは、Section 3で説明されている通りです。

unprotected:

これは、Section 3で説明されている通りです。

ciphertext:

このフィールドには、bstrとしてエンコードされた暗号化キーが含まれています。すべてのエンコードされたキーは対称キーであり、キーのバイナリ値が内容です。暗号化キーがない場合、このフィールドはnil値としてエンコードされます。

recipients:

このフィールドには、受信者情報構造の配列が含まれています。受信者情報構造のタイプはCOSE_recipientであり、その例はAppendix Bにあります。受信者情報構造がない場合、この要素は存在しません。

The CDDL fragment that corresponds to the above text for COSE_recipient is:

上記のテキストに対応するCOSE_recipientのCDDLフラグメントは次の通りです：

5.2. Single Recipient Encrypted

5.2. 単一受信者暗号化

The COSE_Encrypt0 encrypted structure does not have the ability to specify recipients of the message. The structure assumes that the recipient of the object will already know the identity of the key to be used in order to decrypt the message. If a key needs to be identified to the recipient, the enveloped structure ought to be used.

COSE_Encrypt0の暗号化された構造体には、メッセージの受信者を指定する機能がありません。この構造体は、オブジェクトの受信者がメッセージを復号化するために使用されるキーの識別子をすでに知っていることを前提としています。受信者にキーを識別する必要がある場合は、封入された構造体を使用するべきです。

Examples of encrypted messages can be found in Appendix C.4.

暗号化されたメッセージの例は、Appendix C.4にあります。

The COSE_Encrypt0 structure can be encoded as either tagged or untagged, depending on the context it will be used in. A tagged COSE_Encrypt0 structure is identified by the CBOR tag 16. The CDDL fragment that represents this is:

COSE_Encrypt0の構造は、使用されるコンテキストに応じて、タグ付きまたはタグなしでエンコードすることができます。タグ付きのCOSE_Encrypt0構造は、CBORタグ16によって識別されます。これを示すCDDLフラグメントは次のとおりです:

The COSE_Encrypt0 structure is a CBOR array. The fields of the array, in order, are:

COSE_Encrypt0構造体はCBOR配列です。配列のフィールドは以下の順序であります:

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

ciphertext:

This is as described in Section 5.1.

protected:

これは、Section 3で説明されている通りです。

unprotected:

これは、Section 3で説明されている通りです。

ciphertext:

これは、Section 5.1で説明されている通りです。

The CDDL fragment for COSE_Encrypt0 that corresponds to the above text is:

上記のテキストに対応するCOSE_Encrypt0のCDDLフラグメントは以下の通りです：

5.3. How to Encrypt and Decrypt for AEAD Algorithms

5.3. AEADアルゴリズムの暗号化と復号化の方法

The encryption algorithm for AEAD algorithms is fairly simple. The first step is to create a consistent byte string for the authenticated data structure. For this purpose, we use an Enc_structure. The Enc_structure is a CBOR array. The fields of the Enc_structure, in order, are:

AEADアルゴリズムの暗号化アルゴリズムは非常にシンプルです。最初のステップは、認証データ構造のために一貫性のあるバイト文字列を作成することです。この目的のために、Enc_structureを使用します。Enc_structureはCBOR配列です。Enc_structureのフィールドは、順番に以下の通りです：

1. A context text string identifying the context of the authenticated data structure. The context text string is:

   • "Encrypt0" for the content encryption of a COSE_Encrypt0 data structure.
   • "Encrypt" for the first layer of a COSE_Encrypt data structure (i.e., for content encryption).
   • "Enc_Recipient" for a recipient encoding to be placed in a COSE_Encrypt data structure.
   • "Mac_Recipient" for a recipient encoding to be placed in a MACed message structure.
   • "Rec_Recipient" for a recipient encoding to be placed in a recipient structure.
2. The protected attributes from the body structure, encoded in a bstr type. If there are no protected attributes, a zero-length byte string is used.
3. The externally supplied data from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero-length byte string. (See Section 4.3 for application guidance on constructing this field.)

1. 認証されたデータ構造のコンテキストを識別するためのコンテキストテキスト文字列です。コンテキストテキスト文字列は次のとおりです：

   • COSE_Encrypt0データ構造のコンテンツ暗号化のための「Encrypt0」。
   • COSE_Encryptデータ構造の最初のレイヤー（つまり、コンテンツの暗号化）のための「Encrypt」。
   • COSE_Encryptデータ構造に配置するための受信者エンコーディングのための「Enc_Recipient」。
   • MAC付きメッセージ構造に配置するための受信者エンコーディングのための「Mac_Recipient」。
   • 受信者構造に配置するための受信者エンコーディングのための「Rec_Recipient」。
2. 本文構造から保護された属性は、bstr型でエンコードされます。保護された属性がない場合、長さゼロのバイト文字列が使用されます。
3. アプリケーションから提供される外部データは、bstr型でエンコードされます。このフィールドが提供されていない場合、ゼロ長のバイト文字列にデフォルトで設定されます。（このフィールドの作成に関するアプリケーションガイドラインについては、Section 4.3を参照してください。）

The CDDL fragment that describes the above text is:

上記のテキストを記述するCDDLフラグメントは次の通りです：

How to encrypt a message:

メッセージを暗号化する方法：

1. Create an Enc_structure and populate it with the appropriate fields.
2. Encode the Enc_structure to a byte string (Additional Authenticated Data (AAD)), using the encoding described in Section 9.

3. Determine the encryption key (K). This step is dependent on the class of recipient algorithm being used. For:

   No Recipients:

   The key to be used is determined by the algorithm and key at the current layer. Examples are key wrap keys (Section 8.5.2) and preshared secrets.

   Direct Encryption and Direct Key Agreement:

   The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections RFC9053 and RFC9053 of [RFC9053].

   Other:

   The key is randomly generated.

4. Call the encryption algorithm with K (the encryption key), P (the plaintext), and AAD. Place the returned ciphertext into the "ciphertext" field of the structure.
5. For recipients of the message using non-direct algorithms, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plaintext.

1. 適切なフィールドでEnc_structureを作成して、それを埋めます。
2. Enc_structureをバイト文字列（追加認証データ（AAD））にエンコードし、Section 9 で説明されているエンコーディングを使用してください。

3. 暗号化鍵（K）を決定します。このステップは、使用されている受信者のアルゴリズムのクラスに依存します。次の場合について：

   受信者なし：

   使用される鍵は、現在のレイヤーのアルゴリズムと鍵によって決定されます。例えば、キーラップキー（セクション 8.5.2）や事前共有の秘密です。

   直接暗号化および直接鍵合意：

   鍵は、受信者構造内の鍵とアルゴリズムによって決定されます。使用される暗号化アルゴリズムと鍵のサイズは、受信者のために使用されるKDFの入力です。 （直接の場合、KDFは同一演算と考えることができます。） これらのアルゴリズムの例は、RFC9053およびRFC9053のセクションで見つけることができます。

   その他：

   鍵はランダムに生成されます。

4. 暗号化キーK、平文P、およびAADで暗号化アルゴリズムを呼び出します。構造体の「ciphertext」フィールドに返された暗号文を格納します。
5. メッセージの受信者が非直接アルゴリズムを使用している場合、暗号化キーKを平文として、その受信者のために暗号化アルゴリズムを再帰的に実行してください。

How to decrypt a message:

メッセージを復号化する方法：

1. Create an Enc_structure and populate it with the appropriate fields.
2. Encode the Enc_structure to a byte string (AAD), using the encoding described in Section 9.

3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For:

   No Recipients:

   The key to be used is determined by the algorithm and key at the current layer. Examples are key wrap keys (Section 8.5.2) and preshared secrets.

   Direct Encryption and Direct Key Agreement:

   The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.)

   Other:

   The key is determined by decoding and decrypting one of the recipient structures.

4. Call the decryption algorithm with K (the decryption key to use), C (the ciphertext), and AAD.

1. 適切なフィールドでEnc_structureを作成し、それを埋める。
2. AADとして、Section 9で記述されたエンコーディングを使用して、Enc_structureをバイト文字列にエンコードします。

3. 暗号化の鍵を決定します。このステップは受取人アルゴリズムのクラスに依存しています。対象が以下の場合:

   受取人がいない場合:

   使用する鍵は、現在のレイヤーのアルゴリズムと鍵によって決定されます。例として、キーラップキー（セクション8.5.2）や事前共有された秘密などがあります。

   直接暗号化および直接鍵合意の場合:

   鍵は、受取人構造内の鍵とアルゴリズムによって決定されます。 使用する暗号化アルゴリズムと鍵のサイズは、受取人のために使用されるKDFの入力です。 （ダイレクトの場合、KDFは同一演算と考えることができます。）

   その他の場合:

   鍵は、受取人構造の1つをデコードおよび復号することによって決定されます。

4. K (使用する復号鍵)、C (暗号文)、および AAD で復号アルゴリズムを呼び出します。

5.4. How to Encrypt and Decrypt for AE Algorithms

5.4. AEアルゴリズムの暗号化と復号化の方法

How to encrypt a message:

メッセージを暗号化する方法：

1. Verify that the "protected" field is a zero-length byte string.
2. Verify that there was no external additional authenticated data supplied for this operation.

3. Determine the encryption key. This step is dependent on the class of recipient algorithm being used. For:

   No Recipients:

   The key to be used is determined by the algorithm and key at the current layer. Examples are key wrap keys (Section 8.5.2) and preshared secrets.

   Direct Encryption and Direct Key Agreement:

   The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections RFC9053 and RFC9053 of [RFC9053].

   Other:

   The key is randomly generated.

4. Call the encryption algorithm with K (the encryption key to use) and P (the plaintext). Place the returned ciphertext into the "ciphertext" field of the structure.
5. For recipients of the message using non-direct algorithms, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plaintext.

1. 「protected」フィールドがゼロ長のバイト文字列であることを確認してください。
2. この操作に対して外部から追加の認証データが提供されていないことを確認してください。

3. 暗号化キーを決定します。このステップは使用されている受信者アルゴリズムのクラスに依存します。次の場合について：

   受信者がない場合：

   使用されるキーは、現在のレイヤーでのアルゴリズムとキーによって決定されます。キーラップキー（Section 8.5.2）や共有シークレットが例です。

   直接暗号化および直接鍵合意の場合：

   キーは、受信者構造のキーとアルゴリズムによって決定されます。使用される暗号化アルゴリズムとキーのサイズは、受信者向けに使用されるKDF（鍵導出関数）の入力となります。直接の場合、KDFは同一操作と考えることができます。これらのアルゴリズムの例は、RFC9053およびRFC9053の[RFC9053]に記載されています。

   その他：

   キーはランダムに生成されます。

4. 暗号化アルゴリズムを呼び出し、K（使用する暗号化キー）とP（平文）を渡します。返された暗号文を構造体の「暗号文」フィールドに配置します。
5. 非ダイレクトアルゴリズムを使用するメッセージの受信者に対しては、平文として暗号化キーKを使用して、その受信者のために再帰的に暗号化アルゴリズムを実行してください。

How to decrypt a message:

メッセージを復号化する方法：

1. Verify that the "protected" field is a zero-length byte string.
2. Verify that there was no external additional authenticated data supplied for this operation.

3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For:

   No Recipients:

   The key to be used is determined by the algorithm and key at the current layer. Examples are key wrap keys (Section 8.5.2) and preshared secrets.

   Direct Encryption and Direct Key Agreement:

   The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections RFC9053 and RFC9053 of [RFC9053].

   Other:

   The key is determined by decoding and decrypting one of the recipient structures.

4. Call the decryption algorithm with K (the decryption key to use) and C (the ciphertext).

1. 「protected」フィールドがゼロの長さのバイト列であることを確認してください。
2. この操作に対して、外部からの追加の認証データが供給されていないことを確認してください。

3. 復号キーを決定します。このステップは使用されている受信者アルゴリズムのクラスに依存します。具体的には以下のとおりです：

   受信者がいない場合：

   使用するキーは、現在の層のアルゴリズムとキーによって決定されます。例として、キーラップキー（Section 8.5.2）や事前共有キーがあります。

   直接暗号化と直接鍵合意の場合：

   キーは、受信者構造のキーとアルゴリズムによって決定されます。暗号化アルゴリズムおよび使用するキーのサイズは、受信者用のKDF（派生鍵導出関数）の入力です。（直接鍵合意の場合、KDFは恒等演算と考えることができます。） これらのアルゴリズムの例は、RFC9053およびRFC9053の[RFC9053]で見つけることができます。

   その他の場合：

   キーは、受信者構造の1つをデコードおよび復号化することによって決定されます。

4. K（使用する復号鍵）とC（暗号文）を用いて復号化アルゴリズムを呼び出します。

6.1. MACed Message with Recipients

6.1. 受信者付きMACメッセージ

A multiple-recipient MACed message uses two structures: the COSE_Mac structure defined in this section for carrying the body and the COSE_recipient structure (Section 5.1) to hold the key used for the MAC computation. Examples of MACed messages can be found in Appendix C.5.

複数の受信者のMAC付きメッセージでは、2つの構造を使用します。このセクションで定義されているCOSE_Mac構造は、本体を運ぶために使用され、COSE_recipient構造（Section 5.1で定義されています）は、MAC計算に使用されるキーを保持します。MAC付きメッセージの例はAppendix C.5にあります。

The MAC structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac structure is identified by the CBOR tag 97. The CDDL fragment that represents this is:

MAC構造は、使用される文脈に応じて、タグ付きまたはタグなしでエンコードすることができます。タグ付きのCOSE_Mac構造は、CBORタグ97によって識別されます。これを表すCDDLフラグメントは次のようです:

The COSE_Mac structure is a CBOR array. The fields of the array, in order, are:

COSE_Mac構造体は、CBOR配列です。配列のフィールドは、順番に次の通りです：

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

payload:

This field contains the serialized content to be MACed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately (i.e., detached content), then a nil CBOR value is placed in this location, and it is the responsibility of the application to ensure that it will be transported without changes.

tag:

This field contains the MAC value.

recipients:

This is as described in Section 5.1.

protected:

これは、Section 3で説明されている通りです。

unprotected:

これは、Section 3で説明されている通りです。

payload:

このフィールドには、MAC化されるべきシリアライズされたコンテンツが含まれています。ペイロードがメッセージに存在しない場合、アプリケーションはペイロードを別途提供する必要があります。ペイロードはbstrにラップされて、変更なしで転送されることを保証します。ペイロードが別途転送される場合（つまり、分離されたコンテンツ）、この位置にはnilのCBOR値が配置され、変更なしで転送されることをアプリケーションが保証する責任があります。

tag:

このフィールドにはMAC値が含まれています。

recipients:

これは、Section 5.1で説明されている通りです。

The CDDL fragment that represents the above text for COSE_Mac follows.

上記のテキストに対応するCOSE_Mac用のCDDLフラグメントは次のとおりです。

6.2. MACed Messages with Implicit Key

6.2. 暗黙のキーを持つMACメッセージ

In this section, we describe the structure and methods to be used when doing MAC authentication for those cases where the recipient is implicitly known.

このセクションでは、受信者が暗黙的にわかっている場合にMAC認証を行う際に使用される構造と方法について説明します。

The MACed message uses the COSE_Mac0 structure defined in this section for carrying the body. Examples of MACed messages with an implicit key can be found in Appendix C.6.

以下は、このセクションで定義されたCOSE_Mac0構造を使用して本文を運ぶMAC付きメッセージです。暗黙の鍵を持つMAC付きメッセージの例は、Appendix C.6に記載されています。

The MAC structure can be encoded as either tagged or untagged, depending on the context it will be used in. A tagged COSE_Mac0 structure is identified by the CBOR tag 17. The CDDL fragment that represents this is:

MAC構造体は、使用されるコンテキストに応じて、タグの付いた形式またはタグのない形式でエンコードされることがあります。タグ付きのCOSE_Mac0構造体は、CBORタグ17で識別されます。これを表すCDDLフラグメントは次のとおりです：

The COSE_Mac0 structure is a CBOR array. The fields of the array, in order, are:

COSE_Mac0構造体はCBOR配列です。配列のフィールドは、順番に次のとおりです：

protected:

This is as described in Section 3.

unprotected:

This is as described in Section 3.

payload:

This is as described in Section 6.1.

tag:

This field contains the MAC value.

protected:

これは、Section 3で説明されている通りです。

unprotected:

これは、Section 3で説明されている通りです。

payload:

これは、Section 6.1で説明されている通りです。

tag:

このフィールドにはMAC値が含まれています。

The CDDL fragment that corresponds to the above text is:

上記のテキストに対応するCDDLフラグメントは次のとおりです：

6.3. How to Compute and Verify a MAC

6.3. MACの計算と検証方法

In order to get a consistent encoding of the data to be authenticated, the MAC_structure is used to create the canonical form. The MAC_structure is a CBOR array. The fields of the MAC_structure, in order, are:

データを認証するための一貫したエンコーディングを得るために、MAC_structureは正規形を作成するために使用されます。MAC_structureはCBOR配列です。MAC_structureのフィールドは、順番に以下の通りです：

1. A context text string that identifies the structure that is being encoded. This context text string is "MAC" for the COSE_Mac structure. This context text string is "MAC0" for the COSE_Mac0 structure.
2. The protected attributes from the body structure. If there are no protected attributes, a zero-length bstr is used.
3. The externally supplied data from the application, encoded as a bstr type. If this field is not supplied, it defaults to a zero-length byte string. (See Section 4.3 for application guidance on constructing this field.)
4. The payload to be MACed, encoded in a bstr type. The full payload is used here, independent of how it is transported.

1. 符号化されている構造を識別するコンテキストテキスト文字列。COSE_Mac構造の場合、このコンテキストテキスト文字列は「MAC」です。COSE_Mac0構造の場合、このコンテキストテキスト文字列は「MAC0」です。
2. 本文構造から保護された属性。保護された属性がない場合、長さゼロのbstrが使用されます。
3. アプリケーションから外部に供給されるデータで、bstr型でエンコードされます。このフィールドが提供されていない場合、長さ0のバイト文字列にデフォルトで設定されます。（このフィールドの構築に関するアプリケーションのガイダンスについては、Section 4.3を参照してください。）
4. MACを計算するためのペイロードは、bstr型でエンコードされます。ペイロードはどのように転送されるかに関係なく、ここでは完全なペイロードが使用されます。

The CDDL fragment that corresponds to the above text is:

上記のテキストに対応するCDDLフラグメントは次のとおりです：

The steps to compute a MAC are:

MACを計算する手順は次のとおりです：

1. Create a MAC_structure and populate it with the appropriate fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a byte string, using the encoding described in Section 9.
3. Call the MAC creation algorithm, passing in K (the key to use), alg (the algorithm to MAC with), and ToBeMaced (the value to compute the MAC on).
4. Place the resulting MAC in the "tag" field of the COSE_Mac or COSE_Mac0 structure.
5. For COSE_Mac structures, encrypt and encode the MAC key for each recipient of the message.

1. MAC_structureを作成し、適切なフィールドでそれを埋めます。
2. MAC_structureをバイト文字列にエンコードしてToBeMacedの値を作成します。エンコードには、Section 9で説明されているエンコードを使用します。
3. MAC作成アルゴリズムを呼び出し、K（使用するキー）、alg（MACに使用するアルゴリズム）、ToBeMaced（MACを計算する値）を渡します。
4. 結果のMACをCOSE_MacまたはCOSE_Mac0構造体の"tag"フィールドに配置します。
5. COSE_Mac構造体の場合、メッセージの各受信者に対してMACキーを暗号化し、エンコードします。

The steps to verify a MAC are:

MACの検証手順は次のとおりです：

1. Create a MAC_structure and populate it with the appropriate fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a byte string, using the encoding described in Section 9.
3. For COSE_Mac structures, obtain the cryptographic key by decoding and decrypting one of the recipient structures.
4. Call the MAC creation algorithm, passing in K (the key to use), alg (the algorithm to MAC with), and ToBeMaced (the value to compute the MAC on).
5. Compare the MAC value to the "tag" field of the COSE_Mac or COSE_Mac0 structure.

1. MAC_structureを作成し、適切なフィールドでそれを埋めます。
2. MAC_structureをバイト文字列にエンコードしてToBeMacedの値を作成します。エンコードには、Section 9で説明されているエンコードを使用します。
3. COSE_Mac構造体の場合、受信者構造体の一つを復号化して解読し、暗号化キーを取得します。
4. MAC作成アルゴリズムを呼び出し、K（使用するキー）、alg（MACに使用するアルゴリズム）、ToBeMaced（MACを計算する値）を渡します。
5. MAC値をCOSE_MacまたはCOSE_Mac0構造体の"tag"フィールドと比較します。

7.1. COSE Key Common Parameters

7.1. COSEキー共通パラメーター

This document defines a set of common parameters for a COSE Key object. Table 4 provides a summary of the parameters defined in this section. There are also parameters that are defined for specific key types. Key-type-specific parameters can be found in [RFC9053].

この文書は、COSEキー オブジェクトの一連の共通パラメーターを定義します。このセクションで定義されているパラメーターの概要については、Table 4 を参照してください。また、特定のキータイプに対して定義されているパラメーターもあります。キータイプ固有のパラメーターについては、[RFC9053] を参照してください。

kty:

This parameter is used to identify the family of keys for this structure and, thus, the set of key-type-specific parameters to be found. The set of values defined in this document can be found in [COSE.KeyTypes]. This parameter MUST be present in a key object. Implementations MUST verify that the key type is appropriate for the algorithm being processed. The key type MUST be included as part of the trust-decision process.

alg:

This parameter is used to restrict the algorithm that is used with the key. If this parameter is present in the key structure, the application MUST verify that this algorithm matches the algorithm for which the key is being used. If the algorithms do not match, then this key object MUST NOT be used to perform the cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice.

kid:

This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user-provided byte string to a value computed on the public portion of the key. This field is intended for matching against a "kid" parameter in a message in order to filter down the set of keys that need to be checked. The value of the identifier is not a unique value and can occur in other key objects, even for different keys.

key_ops:

This parameter is defined to restrict the set of operations that a key is to be used for. The value of the field is an array of values from Table 5. Algorithms define the values of key ops that are permitted to appear and are required for specific operations. The set of values matches that in [RFC7517] and [W3C.WebCrypto].

Base IV:

This parameter is defined to carry the base portion of an IV. It is designed to be used with the Partial IV header parameter defined in Section 3.1. This field provides the ability to associate a Base IV with a key that is then modified on a per-message basis with the Partial IV.

Extreme care needs to be taken when using a Base IV in an application. Many encryption algorithms lose security if the same IV is used twice.

If different keys are derived for each sender, starting at the same Base IV is likely to satisfy this condition. If the same key is used for multiple senders, then the application needs to provide for a method of dividing the IV space up between the senders. This could be done by providing a different base point to start from or a different Partial IV to start with and restricting the number of messages to be sent before rekeying.

kty:

このパラメーターは、この構造のキーのファミリーを識別し、したがって、見つけるべきキータイプ固有のパラメーターのセットを識別するために使用されます。このドキュメントで定義されている値のセットは、[COSE.KeyTypes]で見つけることができます。このパラメーターはキーオブジェクトに存在しなければなりません（MUST）。実装は、キータイプが処理されているアルゴリズムに適していることを確認しなければなりません（MUST）。キータイプは信頼決定プロセスの一部として含まれている必要があります（MUST）。

alg:

このパラメーターは、キーと一緒に使用されるアルゴリズムを制限するために使用されます。このパラメーターがキー構造に存在する場合、アプリケーションは必ずこのアルゴリズムがキーが使用されているアルゴリズムと一致することを確認しなければなりません。アルゴリズムが一致しない場合、このキーオブジェクトは暗号化操作を実行するために使用してはならない。同じキーが異なるキー構造にあり、異なるアルゴリズムが指定されているか、アルゴリズムが指定されていない場合がありますが、これはセキュリティー上の良くない実践と考えられます。

kid:

このパラメーターは、キーの識別子を提供するために使用されます。識別子は構造化されておらず、ユーザーが提供したバイト文字列から公開キーの部分に対して計算された値まで何でも可能です。このフィールドは、メッセージ内の"kid"パラメーターと一致させるために、チェックする必要があるキーセットを絞り込むために意図されています。 識別子の値は一意の値ではなく、他のキーオブジェクト、さらには異なるキーでも発生することがあります。

key_ops:

このパラメーターは、キーが使用される操作のセットを制限するために定義されています。フィールドの値は、Table 5からの値の配列です。アルゴリズムは、特定の操作に必要で、表示されることが許可されているkey opsの値を定義します。値のセットは、[RFC7517]および[W3C.WebCrypto]と一致します。

Base IV:

このパラメーターは、IVの基本部分を運ぶために定義されています。これは、Section 3.1で定義されているPartial IVヘッダーパラメーターと一緒に使用するように設計されています。このフィールドは、キーにBase IVを関連付け、それをメッセージごとにPartial IVで変更する能力を提供します。

アプリケーションでBase IVを使用する際には極度の注意が必要です。多くの暗号化アルゴリズムは、同じIVが二度使用されるとセキュリティーが失われます。

各送信者に異なるキーが派生される場合、同じBase IVから開始することでこの条件を満たす可能性があります。 同じキーが複数の送信者で使用される場合、アプリケーションは送信者間でIV空間を分割する方法を提供する必要があります。 これは、異なる基点から開始するか、異なるPartial IVから開始し、再キー化する前に送信するメッセージの数を制限することで行うことができます。

8.1. Signature Algorithms

8.1. 署名アルゴリズム

Signature algorithms provide data-origination and data-integrity services. Data origination provides the ability to infer who originated the data based on who signed the data. Data integrity provides the ability to verify that the data has not been modified since it was signed.

署名アルゴリズムは、データの生成とデータの完全性のサービスを提供します。 データ生成は、データに署名を行った人物を推測する能力を提供します。 データの完全性は、データが署名された後に変更されていないことを検証する能力を提供します。

There are two general signature algorithm schemes. The first is signature with appendix. In this scheme, the message content is processed and a signature is produced; the signature is called the appendix. This is the scheme used by algorithms such as ECDSA and the RSA Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the SSA in RSASSA-PSS stands for Signature Scheme with Appendix.)

二つの一般的な署名アルゴリズムスキームが存在します。最初のスキームは、付録を持つ署名です。このスキームでは、メッセージの内容が処理され、署名が生成されます。この署名は付録と呼ばれます。このスキームは、ECDSAやRSA確率的署名スキーム（RSASSA-PSS）などのアルゴリズムで使用されます。（実際、RSASSA-PSSのSSAは「付録を持つ署名スキーム」を表しています。）

The signature functions for this scheme are:

このスキームの署名関数は次の通りです：

The second scheme is signature with message recovery; an example of such an algorithm is [PVSig]. In this scheme, the message content is processed, but part of it is included in the signature. Moving bytes of the message content into the signature allows for smaller signed messages; the signature size is still potentially large, but the message content has shrunk. This has implications for systems implementing these algorithms and applications that use them. The first is that the message content is not fully available until after a signature has been validated. Until that point, the part of the message contained inside of the signature is unrecoverable. The second implication is that the security analysis of the strength of the signature can be very much dependent on the structure of the message content. Finally, in the event that multiple signatures are applied to a message, all of the signature algorithms are going to be required to consume the same bytes of message content. This means that the mixing of the signature-with-message-recovery and signature-with-appendix schemes in a single message is not supported.

二つ目のスキームはメッセージ復元付き署名で、その一例として[PVSig]があります。 このスキームでは、メッセージ内容が処理されますが、その一部が署名に含まれます。 メッセージ内容のバイトを署名に移動させることで、署名付きメッセージを小さくすることができます。署名のサイズは依然として大きい可能性がありますが、メッセージ内容は縮小します。 これは、これらのアルゴリズムを実装するシステムとそれを使用するアプリケーションに影響を与えます。 最初の影響は、署名が検証されるまでメッセージ内容が完全には利用できないということです。 その時点まで、署名内に含まれるメッセージの一部は回復不可能です。 二つ目の影響は、署名の強度のセキュリティ分析がメッセージ内容の構造に大きく依存する可能性があるということです。 最後に、メッセージに複数の署名が適用される場合、すべての署名アルゴリズムはメッセージ内容の同じバイトを消費する必要があります。 これは、単一のメッセージ内でメッセージ復元付き署名と付録付き署名のスキームを混在させることはサポートされていないことを意味します。

The signature functions for this scheme are:

このスキームの署名関数は次のとおりです：

No message recovery signature algorithms have been formally defined for COSE yet. Given the new constraints arising from this scheme, while some issues have already been identified, there is a high probability that additional issues will arise when integrating message recovery signature algorithms. The first algorithm defined is going to need to make decisions about these issues, and those decisions are likely to be binding on any further algorithms defined.

COSEには、メッセージの回復に関する署名アルゴリズムがまだ正式に定義されていません。この仕組みから生じる新たな制約があるため、既にいくつかの問題が特定されていますが、メッセージの回復署名アルゴリズムを統合する際には追加の問題が発生する可能性が非常に高いです。最初に定義されるアルゴリズムは、これらの問題についての決定を行う必要があり、それらの決定は今後定義される他のアルゴリズムにも拘束力を持つ可能性があります。

We use the following terms below:

私たちは以下の用語を使用します:

message content bytes:

The byte string provided by the application to be signed.

to-be-signed bytes:

The byte string passed into the signature algorithm.

recovered bytes:

The bytes recovered during the signature verification process.

message content bytes:

アプリケーションから提供され、署名されるバイト文字列。

to-be-signed bytes:

署名アルゴリズムに渡されるバイト文字列。

recovered bytes:

署名検証プロセス中に回復されるバイト。

Some of the issues that have already been identified are:

すでに特定されている問題の一部は以下の通りです：

• The to-be-signed bytes are not the same as the message content bytes. This is because we build a larger to-be-signed message during the signature processing. The length of the recovered bytes may exceed the length of the message content, but not the length of the to-be-signed bytes. This may lead to privacy considerations if, for example, the externally supplied data contains confidential information.
• There may be difficulties in determining where the recovered bytes match up with the to-be-signed bytes, because the recovered bytes contain data not in the message content bytes. One possible option would be to create a padding scheme to prevent that.
• Not all message recovery signature algorithms take the recovered bytes from the end of the to-be-signed bytes. This is a problem, because the message content bytes are at the end of the to-be-signed bytes. If the bytes to be recovered are taken from the start of the to-be-signed bytes, then, by default, none of the message content bytes may be included in the recovered bytes. One possible option to deal with this is to reverse the to-be-signed data in the event that recovered bytes are taken from the start rather than the end of the to-be-signed bytes.

• 署名前のバイトは、メッセージの内容のバイトとは異なります。これは、署名処理中に大きな署名前メッセージを構築するためです。回復したバイトの長さは、メッセージの内容の長さを超える場合がありますが、署名前のバイトの長さを超えることはありません。例えば、外部から提供されるデータに機密情報が含まれる場合、これはプライバシーに関する考慮事項につながる可能性があります。
• 復元されたバイトが署名対象のバイトと一致する場所を特定することに困難があるかもしれません。なぜなら、復元されたバイトにはメッセージ内容のバイトに含まれていないデータが含まれているからです。そのような場合、一つの選択肢としてパディングスキームを作成してそれを防ぐことが考えられます。
• すべてのメッセージ復元署名アルゴリズムが、回復されるバイトを署名対象バイトの末尾から取得するわけではありません。 これは問題であり、なぜならメッセージ内容のバイトは署名対象バイトの末尾にあるからです。 回復されるべきバイトが署名対象バイトの先頭から取得される場合、デフォルトでは、メッセージ内容のバイトは回復バイトに含まれない可能性があります。 これに対処する一つの可能なオプションは、回復バイトが署名対象バイトの先頭ではなく末尾から取得される場合、署名対象データを逆順にすることです。

Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures. At the time of this writing, only signatures with appendices are defined for use with COSE; however, considerable interest has been expressed in using a signature-with-message-recovery algorithm, due to the effective size reduction that is possible.

署名アルゴリズムはCOSE_SignatureとCOSE_Sign1の構造と共に使用されます。本文執筆時点では、COSEとの使用のために付録を持った署名のみが定義されていますが、有効なサイズの削減が可能となる署名-メッセージ回復アルゴリズムの使用に関して、非常に興味が示されています。

8.2. Message Authentication Code (MAC) Algorithms

8.2. メッセージ認証コード（MAC）アルゴリズム

Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, cannot be used to prove the identity of the sender to a third party.

メッセージ認証コード（MAC）はデータの認証と整合性保護を提供します。MACはデータの発信元を証明するためには使用できません（あるいは非常に制限されています）。例えば、MACは送信者の身元を第三者に証明するために使用することはできません。

MACs use the same scheme as signature-with-appendix algorithms. The message content is processed, and an authentication code is produced. The authentication code is frequently called a tag.

MAC（メッセージ認証コード）は、署名と同様の方式を使用します。メッセージの内容が処理され、認証コードが生成されます。この認証コードは、しばしば「タグ」と呼ばれます。

The MAC functions are:

MAC（メッセージ認証符号）の機能は、次のとおりです：

MAC algorithms can be based on either a block cipher algorithm (i.e., AES-MAC) or a hash algorithm (i.e., a Hash-based Message Authentication Code (HMAC)). [RFC9053] defines a MAC algorithm using each of these constructions.

MACアルゴリズムは、ブロック暗号アルゴリズム（すなわち、AES-MAC）またはハッシュアルゴリズム（すなわち、ハッシュベースのメッセージ認証コード（HMAC））に基づいています。 [RFC9053]は、これらの構築を使用したMACアルゴリズムを定義しています。

MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures.

MACアルゴリズムは、COSE_MacおよびCOSE_Mac0構造体で使用されます。

8.3. Content Encryption Algorithms

8.3. コンテンツ暗号化アルゴリズム

Content encryption algorithms provide data confidentiality for potentially large blocks of data using a symmetric key. They provide integrity on the data that was encrypted; however, they provide either no or very limited data origination. (One cannot, for example, be used to prove the identity of the sender to a third party.) The ability to provide data origination is linked to how the CEK is obtained.

コンテンツ暗号化アルゴリズムは、対称キーを使用して、潜在的に大きなデータブロックのデータ機密性を提供します。これらは、暗号化されたデータの整合性を提供しますが、送信者のアイデンティティを第三者に証明するために使用することはできません（例えば、使用することはできません）。データの発生源を提供する能力は、CEKの取得方法に関連しています。

COSE restricts the set of legal content encryption algorithms to those that support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition. For simplicity's sake, the authentication code will normally be defined as being appended to the ciphertext stream. The encryption functions are:

COSEは、コンテンツおよび追加データの両方の認証をサポートする暗号化アルゴリズムのセットを制限します。暗号化プロセスは、認証値のある種類を生成しますが、その値はアルゴリズムの定義において明示的または暗黙的にすることができます。単純化のために、認証コードは通常、暗号文のストリームに追加されるように定義されます。暗号化関数は以下の通りです：

Most AEAD algorithms are logically defined as returning the message content only if the decryption is valid. Many, but not all, implementations will follow this convention. The message content MUST NOT be used if the decryption does not validate.

ほとんどのAEADアルゴリズムは、論理的には復号化が有効である場合にのみメッセージ内容を返すように定義されています。多くの実装では、しかしすべてではなく、この規則に従います。復号化が検証されない場合、メッセージ内容を使用してはなりません（MUST NOT）。

These algorithms are used in COSE_Encrypt and COSE_Encrypt0.

これらのアルゴリズムは、COSE_EncryptおよびCOSE_Encrypt0で使用されます。

8.4. Key Derivation Functions (KDFs)

8.4. 鍵導出関数（KDFs）

KDFs are used to take some secret value and generate a different one. The secret value comes in three flavors:

KDF（鍵導出関数）は、いくつかの秘密値を入力として別の値を生成するために使用されます。秘密値には3つの種類があります：

• Secrets that are uniformly random. This is the type of secret that is created by a good random number generator.
• Secrets that are not uniformly random. This is the type of secret that is created by operations like key agreement.
• Secrets that are not random. This is the type of secret that people generate for things like passwords.

• 一様にランダムな秘密情報。これは、良好な乱数生成器によって作成される種類の秘密情報です。
• 一様にランダムではない秘密。これは、鍵共有などの操作によって作成されるタイプの秘密です。
• ランダムでない秘密。これは、パスワードなどのために人々が生成するタイプの秘密です。

General KDFs work well with the first type of secret, can do reasonably well with the second type of secret, and generally do poorly with the last type of secret. Functions like Argon2 [RFC9106] need to be used for nonrandom secrets.

一般的なKDF（キーダービベレーション関数）は、最初のタイプの秘密とうまく機能します。第二のタイプの秘密についてもそれなりの結果を得ることができ、最後のタイプの秘密に対しては一般的にうまく機能しません。Argon2などの関数は、ランダムでない秘密に使用する必要があります。

The same KDF can be set up to deal with the first two types of secrets in different ways. The KDF defined in Section 5.1 of [RFC9053] is such a function. This is reflected in the set of algorithms defined around the HMAC-based Extract-and-Expand Key Derivation Function (HKDF).

同じKDFは、最初の2つの種類の秘密情報に異なる方法で対応するために設定できます。 [RFC9053]のSection 5.1で定義されたKDFは、そのような機能です。これは、HMACベースのExtract-and-Expand鍵派生関数（HKDF）を中心としたアルゴリズムのセットに反映されています。

When using KDFs, one component that is included is context information. Context information is used to allow for different keying information to be derived from the same secret. The use of context-based keying material is considered to be a good security practice.

KDFを使用する際には、コンテキスト情報という要素が含まれます。コンテキスト情報は、同じ秘密から異なる鍵情報を派生させるために使用されます。コンテキストベースの鍵材料の使用は、良いセキュリティーの実践と考えられています。

8.5. Content Key Distribution Methods

8.5. コンテンツキー配布方法

Content key distribution methods (recipient algorithms) can be defined into a number of different classes. COSE has the ability to support many classes of recipient algorithms. In this section, a number of classes are listed. For the recipient algorithm classes defined in [RFC7516], the same names are used. Other specifications use different terms for the recipient algorithm classes or do not support some of the recipient algorithm classes.

コンテンツキー配布方法（受信者アルゴリズム）は、いくつかの異なるクラスに定義することができます。 COSEは多くのクラスの受信者アルゴリズムをサポートする能力を持っています。 このセクションでは、いくつかのクラスがリストされています。[RFC7516]で定義されている受信者アルゴリズムクラスと同じ名前が使用されています。 他の仕様では、受信者アルゴリズムクラスに対して異なる用語を使用するか、または一部の受信者アルゴリズムクラスをサポートしていません。

11.1. COSE Header Parameters Registry

11.1. COSE Header Parameters Registry

The "COSE Header Parameters" registry was defined by [RFC8152]. IANA has updated the reference for this registry to point to this document instead of [RFC8152]. IANA has also updated all entries that referenced [RFC8152], except "counter signature" and "CounterSignature0", to refer to this document. The references for "counter signature" and "CounterSignature0" continue to reference [RFC8152].

「COSEヘッダーパラメーター」レジストリは、[RFC8152] によって定義されました。IANAは、このレジストリの参照を[RFC8152]ではなくこの文書を指すように更新しました。また、IANAは「カウンタ署名」と「CounterSignature0」を除くすべてのエントリを、[RFC8152]への参照ではなく、この文書を参照するように更新しました。「カウンタ署名」と「CounterSignature0」の参照は引き続き[RFC8152]を参照しています。

11.2. COSE Key Common Parameters Registry

11.2. COSE Key Common Parameters Registry

The "COSE Key Common Parameters" registry [COSE.KeyParameters] was defined in [RFC8152]. IANA has updated the reference for this registry to point to this document instead of [RFC8152]. IANA has also updated the entries that referenced [RFC8152] to refer to this document.

「COSE Key Common Parameters」レジストリは、[COSE.KeyParameters]で定義されていました。IANAはこのレジストリの参照を、[RFC8152]ではなく、このドキュメントを指すように更新しました。IANAはまた、[RFC8152]を参照していたエントリをこのドキュメントを参照するように更新しました。

11.3. Media Type Registrations

11.3. Media Type Registrations

11.4. CoAP Content-Formats Registry

11.4. CoAP Content-Formats Registry

IANA added entries to the "CoAP Content-Formats" registry as indicated in [RFC8152]. IANA has updated the reference to point to this document instead of [RFC8152].

IANAは、「CoAPコンテンツフォーマット」登録にエントリーを追加しました。これは[RFC8152]で示されています。 IANAは、参照をこのドキュメントに更新し、[RFC8152]の代わりにこのドキュメントを指すようにしました。

11.5. CBOR Tags Registry

11.5. CBOR Tags Registry

IANA added entries to the "CBOR Tags" registry as indicated in [RFC8152]. IANA has updated the references to point to this document instead of [RFC8152].

IANAは、[RFC8152]で示されているように、「CBOR タグ」レジストリへのエントリを追加しました。 IANAは、参照をこのドキュメントを指すように更新しました。以前の参照先は[RFC8152]でした。

11.6. Expert Review Instructions

11.6. Expert Review Instructions

All of the IANA registries established by [RFC8152] are, at least in part, defined as Expert Review [RFC8126]. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.

RFC8152で設立されたすべてのIANAレジストリは、少なくとも一部がExpert Review [RFC8126]として定義されています。このセクションでは、専門家が探すべき一般的なガイドラインを提供しますが、彼らは専門家として指定されているため、大きな裁量を与える必要があります。

Expert reviewers should take the following into consideration:

専門的なレビューアは、以下を考慮する必要があります：

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate an existing registration and that the code point is likely to be used in deployments. The ranges tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.
• Standards Track or BCP RFCs are required to register a code point in the Standards Action range. Specifications should exist for Specification Required ranges, but early assignment before an RFC is available is considered to be permissible. Specifications are needed for the first-come, first-served range if the points are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
• Experts should take into account the expected usage of fields when approving code point assignment. The fact that the Standards Action range is only available to Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left and the size of device it will be used on.
• When algorithms are registered, vanity registrations should be discouraged. One way to do this is to require registrations to provide additional documentation on security analysis of the algorithm. Another thing that should be considered is requesting an opinion on the algorithm from the Crypto Forum Research Group (CFRG). Algorithms are expected to meet the security requirements of the community and the requirements of the message structures in order to be suitable for registration.

• ポイントのスクワッティングは desu。レビュアーが登録リクエストのための十分な情報を取得することが推奨されています。これにより、使用が既存の登録と重複せず、コードポイントが展開で使用される可能性が高いことが確認されます。プライベート使用とタグ付けされた範囲は、テスト目的および閉じられた環境向けです。他の範囲のコードポイントはテストに割り当てられるべきではありません。
• Standards TrackまたはBCP RFCは、Standards Action範囲でコードポイントを登録することが必要です。Specification Required範囲には仕様が存在するべきですが、RFCが利用可能になる前の早期割り当ては許容されるものと見なされます。仕様は、クローズド環境外で相互運用可能に利用される場合に、ファーストカム・ファーストサーブ範囲についても必要です。仕様が提供されない場合、提供された記述には、ポイントがどのように使用されているかを識別するための十分な情報が必要です。
• 専門家は、コードポイントの割り当てを承認する際に、フィールドの予想使用状況を考慮すべきです。Standards Action範囲がStandards Trackドキュメントにのみ利用可能であるという事実は、Standards Trackドキュメントがその範囲外にポイントを割り当てることができないという意味ではありません。符号化された値の長さは、その長さのコードポイントが残っている数と、それが使用されるデバイスのサイズとのバランスを考慮すべきです。
• アルゴリズムが登録される際は、自己満足的な登録を desync Preftechdis 後りするべきです。これを実現するためには、アルゴリズムのセキュリティー分析に関する追加の文書提出を登録に要求することがあります。また、Crypto Forum Research Group（CFRG）からアルゴリズムに関する意見を求めることも検討すべきです。登録に適しているためには、アルゴリズムがコミュニティのセキュリティー要件とメッセージ構造の要件を満たすことが期待されます。

C.1. Examples of Signed Messages

C.1. Examples of Signed Messages

C.2. Single Signer Examples

C.2. Single Signer Examples

C.3. Examples of Enveloped Messages

C.3. Examples of Enveloped Messages

C.4. Examples of Encrypted Messages

C.4. Examples of Encrypted Messages

C.5. Examples of MACed Messages

C.5. Examples of MACed Messages

C.6. Examples of MAC0 Messages

C.6. Examples of MAC0 Messages

C.7. COSE Keys

C.7. COSE Keys