1.1. Design Changes from JOSE

1.1. JOSEからのデザイン変更

• Define a single top message structure so that encrypted, signed, and MACed messages can easily be identified and still have a consistent view.

• 暗号化された、署名された、およびMACを付与されたメッセージを簡単に識別し、一貫した表示を提供するために、単一のトップメッセージ構造を定義します。

• Signed messages distinguish between the protected and unprotected parameters that relate to the content from those that relate to the signature.

• 署名付きメッセージは、内容に関連する保護されたパラメーターとシグネチャに関連するパラメーターを区別します。

• MACed messages are separated from signed messages.

• MAC付きのメッセージは署名されたメッセージから分離されています。

• MACed messages have the ability to use the same set of recipient algorithms as enveloped messages for obtaining the MAC authentication key.

• MAC認証されたメッセージは、MAC認証キーを取得するために、封入されたメッセージと同じ受信者アルゴリズムのセットを使用する能力を持っています。

• Use binary encodings for binary data rather than base64url encodings.

• バイナリーデータには、base64urlエンコーディングではなく、バイナリーエンコーディングを使用してください。

• Combine the authentication tag for encryption algorithms with the ciphertext.

• 暗号化アルゴリズムの認証タグを暗号文と組み合わせます。

• The set of cryptographic algorithms has been expanded in some directions and trimmed in others.

• 暗号アルゴリズムのセットは、一部の方向で拡張され、他の方向で削減されました。

1.2. Requirements Terminology

1.2. 要件用語

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]で説明されているように解釈されます。

When the words appear in lowercase, this interpretation does not apply.

小文字で表示される場合、この解釈は適用されません。

1.3. CBOR Grammar

1.3. CBORの文法

There is currently no standard CBOR grammar available for use by specifications. The CBOR structures are therefore described in prose.

現在、仕様で使用するための標準的なCBOR文法は存在しません。そのため、CBOR構造は文章で説明されています。

The 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 CBOR Data Definition Language (CDDL) [CDDL]. In this specification, the following primitive types are used:

ドキュメントは、まず文法を作成し、それに続いてそれに対応する散文を開発することで作成されました。これによって、散文は、CBORデータ定義言語（CDDL）[CDDL]で定義されたプリミティブ型の文字列を使用して書かれました。この仕様では、以下のプリミティブ型が使用されます：

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

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

As well as the prose description, a version of a CBOR grammar is presented in CDDL. Since CDDL has not been published in an RFC, this grammar may not work with the final version of CDDL. The CDDL grammar is informational; the prose description is normative.

プローズ説明に加えて、CBORのグラマーのバージョンがCDDLで示されています。CDDLはRFCで公開されていないため、このグラマーがCDDLの最終バージョンで動作しない可能性があります。CDDLグラマーは情報提供ですが、プローズ説明が規範です。

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

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

//artwork[@type='CDDL']/text()

//artwork[@type='CDDL']/text()

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

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

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

; This is defined to make the tool quieter: Internal_Types = Sig_structure / Enc_structure / MAC_structure / COSE_KDF_Context

; これは、ツールを静かにするために定義されています：Internal_Types = Sig_structure / Enc_structure / MAC_structure / COSE_KDF_Context

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

非終端記号「Internal_Types」は、このドキュメントの作成中に使用される自動検証ツールの処理のために定義されています。それは、セキュリティー計算に使用されるが、輸送には出力されない非終端記号を参照しています。

1.4. CBOR-Related Terminology

1.4. CBOR関連用語

In JSON, maps are called objects and only have one kind of map key: a string. In COSE, we use strings, negative integers, and unsigned integers as map keys. The integers are used for compactness of encoding and easy comparison. The inclusion of 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では、マップキーとして文字列、負の整数、および非負の整数を使用します。整数はエンコードの効率化と簡単な比較のために使用されます。文字列の含まれることで、追加の範囲の短いエンコード値も使用できます。単語「キー」は、主に別の意味である暗号鍵として使用されるため、マップキーのこの使用法には「ラベル」という用語を使用します。

The presence of a label in a COSE map that is not a string or an integer is an error. Applications can either fail processing or process messages with incorrect labels; however, they MUST NOT create messages with incorrect labels.

COSEマップ内に文字列または整数でないラベルが存在する場合、それはエラーです。アプリケーションは処理を失敗させるか、または不正なラベルを持つメッセージを処理することができますが、ただし、不正なラベルを持つメッセージを作成してはなりません（MUST NOT）。

A CDDL grammar fragment defines the non-terminal 'label', as in the previous paragraph, and 'values', which permits any value to be used.

CDDLの文法断片には、前の段落のように非終端記号「label」と「values」が定義されており、それは任意の値の使用を許可します。

label = int / tstr values = any

label = int / tstr values = any

1.5. Document Terminology

1.5. ドキュメント用語

In this document, we use the following terminology:

このドキュメントでは、以下の用語を使用します：

Byte is a synonym for octet.

バイトはオクテットの同義語です。

Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252].

制約付きアプリケーションプロトコル（CoAP）は、制約のあるシステムで使用するための特殊なウェブ転送プロトコルです。それは、[RFC7252] で定義されています。

Authenticated Encryption (AE) [RFC5116] algorithms are those encryption algorithms that provide an authentication check of the contents algorithm with the encryption service.

認証付き暗号化（AE）[RFC5116]アルゴリズムは、暗号化サービスと共に内容アルゴリズムの認証チェックを提供する暗号化アルゴリズムです。

Authenticated Encryption with Authenticated Data (AEAD) [RFC5116] algorithms provide the same content authentication service as AE algorithms, but they additionally provide for authentication of non- encrypted data as well.

認証付き暗号化（AEAD）[RFC5116]アルゴリズムは、AEアルゴリズムと同じ内容認証サービスを提供しますが、さらに非暗号化データの認証も提供します。

3.1. Common COSE Headers Parameters

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

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

このセクションでは、一連の共通ヘッダーパラメーターが定義されます。これらのパラメーターの概要は、表2に記載されています。labelの値とその値のタイプを特定するために、この表を参照する必要があります。

The set of header parameters defined in this section are:

このセクションで定義されているヘッダーパラメーターのセットは以下の通りです：

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

alg: このパラメーターは、セキュリティー処理に使用されるアルゴリズムを示すために使用されます。このパラメーターは、その能力が存在する場合には認証される必要があります（MUST）。このサポートは、AEADアルゴリズムまたは構造（COSE_Sign、COSE_Sign0、COSE_Mac、およびCOSE_Mac0）によって提供されます。この認証は、保護されたヘッダーバケットにヘッダーを配置するか、外部から供給されたデータの一部として行うことができます。値は「COSE Algorithms」レジストリから取得されます（セクション16.4を参照）。

crit: The parameter is used to indicate which protected header labels an application that is processing a message is required to understand. Parameters defined in this document do not need to be included as they should be understood by all implementations. When present, this parameter MUST be placed in the protected header bucket. The array MUST have at least one value in it. Not all labels need to be included in the 'crit' parameter. The rules for deciding which header labels are placed in the array are:

crit: このパラメーターは、メッセージを処理しているアプリケーションが理解する必要がある保護ヘッダーラベルを示すために使用されます。このドキュメントで定義されたパラメーターは、すべての実装によって理解される必要があるため、含める必要はありません。存在する場合、このパラメーターは保護ヘッダーバケットに配置される必要があります（MUST）。配列には少なくとも1つの値が含まれている必要があります（MUST）。すべてのラベルを 'crit' パラメーターに含める必要はありません。配列に配置されるヘッダーラベルを決定するためのルールは次のとおりです：

content type: This parameter is used to indicate the content type of the data in the payload or ciphertext fields. Integers are from the "CoAP Content-Formats" IANA registry table [COAP.Formats]. Text values following 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 also omitted. Textual content values along with parameters and subparameters can be located using the IANA "Media Types" registry. Applications SHOULD provide this parameter if the content structure is potentially ambiguous.

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

kid: This parameter identifies one piece of data that can be used as input to find the needed cryptographic key. The value of this 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 headers bucket.

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

IV: This 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 header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled.

IV: このパラメーターは、初期化ベクトル (IV) の値を保持します。対称暗号化アルゴリズムにおいては、これはノンスと呼ばれる場合もあります。IVは、IVの修正によって復号化結果が乱れたテキストとして容易に検出できるため、保護されていないヘッダーに配置されることがあります。

Partial IV: This 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. This field is used to carry a value that causes the IV to be changed for each message. The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled. The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT both be present in the same security layer.

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

counter signature: This parameter holds one or more counter signature values. Counter signatures provide a method of having a second party sign some data. The counter signature parameter can occur as an unprotected attribute in any of the following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These structures all have the same beginning elements, so that a consistent calculation of the counter signature can be computed. Details on computing counter signatures are found in Section 4.5.

カウンターシグネチャ：このパラメーターには1つ以上のカウンターシグネチャ値が格納されます。カウンターシグネチャは、第二の当事者がデータに署名する方法を提供します。カウンターシグネチャパラメーターは、次のいずれかの構造体に非保護属性として出現することができます：COSE_Sign1、COSE_Signature、COSE_Encrypt、COSE_recipient、COSE_Encrypt0、COSE_Mac、およびCOSE_Mac0。これらの構造体はすべて同じ開始要素を持っているため、カウンターシグネチャの一貫した計算が行われます。カウンターシグネチャの計算方法の詳細については、セクション4.5を参照してください。

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

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

Generic_Headers = ( ? 1 => int / tstr, ; algorithm identifier ? 2 => [+label], ; criticality ? 3 => tstr / int, ; content type ? 4 => bstr, ; key identifier ? 5 => bstr, ; IV ? 6 => bstr, ; Partial IV ? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature )

Generic_Headers = ( ? 1 => int / tstr, ; algorithm identifier ? 2 => [+label], ; criticality ? 3 => tstr / int, ; content type ? 4 => bstr, ; key identifier ? 5 => bstr, ; IV ? 6 => bstr, ; Partial IV ? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature )

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. Parameters relating to the content and parameters relating to the signature are carried along with the signature itself. These parameters may be authenticated by the signature, or just present. An example of a parameter about the content is the content type. Examples of parameters about the signature would be the algorithm and key used to create the signature and counter signatures.

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

RFC 5652 indicates that:

RFC 5652は次のように示しています：

For example, the COSE_Sign structure might include signatures generated with the Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032] and with 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構造体には、Edwards-curve Digital Signature Algorithm（EdDSA）で生成された署名と、Elliptic Curve Digital Signature Algorithm（ECDSA）で生成された署名が含まれているかもしれません。これにより、受信者は、どちらかのアルゴリズムに関連する署名を検証することができます。複数の署名評価に関する詳細な情報については、[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フラグメントは次のとおりです。

COSE_Sign_Tagged = #6.98(COSE_Sign)

COSE_Sign_Tagged = #6.98(COSE_Sign) COSE_Sign_Tagged = #6.98(COSE_Sign)

A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the body 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署名メッセージの例は付録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.

protected: これはセクション3で説明されているものです。

unprotected: This is as described in Section 3.

unprotected：これはセクション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.

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

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

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

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

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

COSE_Sign = [ Headers, payload : bstr / nil, signatures : [+ COSE_Signature] ]

COSE_Sign = [ Headers, payload : bstr / nil, signatures : [+ COSE_Signature] ]

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.

protected：これはセクション3で説明されているとおりです。

unprotected: This is as described in Section 3.

unprotected：これはセクション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.

signature：このフィールドには計算された署名値が含まれます。フィールドのタイプはバイナリー文字列（bstr）です。署名値が8ビットの倍数でない場合、アルゴリズムはパディングを指定しなければなりません（MUST）。

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

上記のテキストの COSE_Signature に対する CDDL フラグメントは次のようになります。

COSE_Signature = [ Headers, signature : bstr ]

COSE_Signature = [ Headers, signature : bstr ]

4.2. Signing with One Signer

4.2. １つの署名者での署名

The COSE_Sign1 signature structure is used when only one signature is going to be placed on a message. The 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フラグメントは次のようになります：

COSE_Sign1_Tagged = #6.18(COSE_Sign1)

COSE_Sign1_Tagged = #6.18(COSE_Sign1) 「COSE_Sign1_Tagged」は、#6.18（COSE_Sign1）です。

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.

本文、署名、本文と署名に関する情報を運ぶCBORオブジェクトは「COSE_Sign1」構造体と呼ばれます。COSE_Sign1メッセージの例は、付録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.

protected: これはセクション3で説明されている通りです。

unprotected: This is as described in Section 3.

unprotected：これはセクション3で説明されているものです。

payload: This is as described in Section 4.1.

payload：これはセクション4.1で説明されているようにです。

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

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

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

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

COSE_Sign1 = [ Headers, payload : bstr / nil, signature : bstr ]

COSE_Signature = [ Headers, signature : bstr ]

4.3. Externally Supplied Data

4.3. 外部から提供されたデータ

One of the features offered in the COSE document is the ability for applications to provide additional data to be authenticated, but that 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 header section, then it is available for proxies to help in performing its operations. For example, the Accept Option can be used by a proxy to determine if an appropriate value is in the proxy's cache. But the sender can prevent a proxy from changing the set of values that it will accept by including that value in the resulting authentication tag. However, it may also be desired to protect these values so that if they are modified in transit, it can be detected.

COSEドキュメントで提供される機能の1つは、アプリケーションがCOSEオブジェクトの一部として運ばれないが、認証される追加データを提供する能力です。これをサポートする主な理由は、CoAPメッセージ構造[RFC7252]を見ることで明確になります。この構造では、ペイロードの前にオプションを運ぶための仕組みが存在します。この場所に配置できるデータの例としては、CoAPコードやCoAPオプションがあります。データがヘッダーセクションにある場合、プロキシが操作を行う際に使用するために利用可能です。例えば、Acceptオプションはプロキシがキャッシュ内に適切な値があるかどうかを判断するために使用できます。しかし、送信者はその値を認証タグに含めることでプロキシが受け入れる値のセットを変更することを防ぐこともできます。ただし、これらの値を保護して、送信中に変更された場合に検出できるようにすることも望まれる場合があります。

This document describes the process for using a byte array of externally supplied authenticated data; however, 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 is not produced if there are different inputs. This could occur by appending the strings 'AB' and 'CDE' or by appending the 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.

• 複数の項目が含まれている場合、異なる入力がある場合に同じバイト文字列が生成されないように、アプリケーションは確認する必要があります。これは、文字列 'AB' と 'CDE' を追加するか、文字列 'ABC' と 'DE' を追加することによって発生する可能性があります。通常、これはフィールドを固定幅にするか、フィールドの長さを出力の一部として符号化することによって対処されます。CoAP [RFC7252] のオプションを例に挙げると、これらのフィールドはTLV構造を使用しているため、問題なく連結することができます。

• 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.

• 複数のアイテムを含む場合、アイテムの順序を定義する必要があります。CoAPのオプションを例に挙げると、アプリケーションはフィールドをオプション番号で順序付ける必要があると述べることができます。

• Applications need to ensure that the byte stream 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 number 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.

• アプリケーションは、バイトストリームが両側で同じになることを確認する必要があります。CoAPのオプションを使用すると、同じ相対番号が保持される場合に問題が発生する可能性があります。中間ノードはオプションを挿入または削除することができ、相対番号の方法を変更することがあります。アプリケーションは、相対番号が外部データに存在するオプションにのみ相対的であるため、相対番号が再エンコードされる必要があることを指定する必要があります。

4.4. Signing and Verification Process

4.4. 署名および検証プロセス

In order to create a signature, a well-defined byte stream 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 text string identifying the context of the signature. The context string is:

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

2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used.

2. ボディ構造でエンコードされた保護された属性は、bstrタイプで表されます。保護された属性が存在しない場合は、長さゼロのbstrが使用されます。

3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. This field is omitted for the COSE_Sign1 signature structure.

3. プロテクトされた属性は、bstr型でエンコードされた署名者構造から取得されます。もしプロテクトされた属性が存在しない場合は、長さゼロのbstrが使用されます。このフィールドは、COSE_Sign1署名構造には含まれません。

4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero- length binary string. (See Section 4.3 for application guidance on constructing this field.)

4. アプリケーションからエンコードされた保護属性が、bstr型で与えられます。このフィールドが提供されない場合、長さゼロのバイナリー文字列がデフォルトとなります。（このフィールドを構築するためのアプリケーション上のガイダンスについては、セクション4.3を参照してください。）

5. The payload to be signed encoded in a bstr type. The payload is placed here independent of how it is transported.

5. ペイロードは bstr タイプでエンコードされ、署名する必要があります。ペイロードは、輸送方法に関係なく、ここに配置されます。

The CDDL fragment that describes the above text is:

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

Sig_structure = [ context : "Signature" / "Signature1" / "CounterSignature", body_protected : empty_or_serialized_map, ? sign_protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ]

Sig_structure = [ context : "シグネチャ" / "シグネチャ1" / "カウンターシグネチャ", body_protected : empty_or_serialized_map, ? sign_protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ]

How to compute a signature:

署名の計算方法:

1. Create a Sig_structure and populate it with the appropriate fields.

1. 適切なフィールドでSig_structureを作成し、情報を入れます。

2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14.

2. セクション14で説明されているエンコーディングを使用して、Sig_structureをバイト文字列にエンコードすることにより、値ToBeSignedを作成します。

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).

3. K (署名するためのキー)、alg(署名に使用するアルゴリズム)、ToBeSigned (署名する値)を渡して署名作成アルゴリズムを呼び出します。

4. Place the resulting signature value in the 'signature' field of the array.

4. 結果の署名値を配列の 'signature' フィールドに配置します。

The steps for verifying a signature are:

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

1. Create a Sig_structure object and populate it with the appropriate fields.

1. Sig_structureオブジェクトを作成し、適切なフィールドで埋めます。

2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14.

２．セクション14で述べられているエンコード方法を使用して、Sig_structureをバイト文字列にエンコードして値ToBeSignedを作成します。

3. Call the signature verification algorithm passing in K (the key to verify with), alg (the algorithm used sign with), ToBeSigned (the value to sign), and sig (the signature to be verified).

3. K (検証に使用するキー)、alg (署名に使用されたアルゴリズム)、ToBeSigned (署名する値)、および sig (検証する署名) を渡して署名の検証アルゴリズムを呼び出します。

In addition to performing the signature verification, the application may also perform 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.

署名の検証を行うだけでなく、アプリケーションはキーが正しく署名される識別子とペアになっていること、および署名される識別子がアクションを実行する前に承認されていることを確認するための適切なチェックも実行する場合があります。

4.5. Computing Counter Signatures

4.5. コンピューティングカウンターサインはします

Counter signatures provide a method of associating a different signature generated by different signers with some piece of content. This is normally used to provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a Timestamp). In this document, we allow for counter signatures to exist in a greater number of environments. As an example, it is possible to place a counter signature in the unprotected attributes of a COSE_Encrypt object. This would allow for an intermediary to either verify that the encrypted byte stream has not been modified, without being able to decrypt it, or assert that an encrypted byte stream either existed at a given time or passed through it in terms of routing (i.e., a proxy signature).

カウンタ署名は、異なるサイン作成者によって生成された別の署名と特定のコンテンツを関連付ける方法を提供します。通常、これは、ある時点で署名が存在したことを証明するために、署名上の署名を提供するために使用されます（タイムスタンプなど）。この文書では、カウンタ署名をさらに多くの環境で存在させることを許可しています。例えば、COSE_Encryptオブジェクトの保護されていない属性にカウンタ署名を配置することが可能です。これにより、中間者が暗号化されたバイトストリームが変更されていないことを検証することができるが、解読することはできない、または特定の時点で暗号化されたバイトストリームが存在したこと、または経由したことを示すことができます（プロキシ署名）。

An example of a counter signature on a signature can be found in Appendix C.1.3. An example of a counter signature in an encryption object can be found in Appendix C.3.3.

署名に対するカウンタ署名の例は、付録C.1.3に記載されています。暗号化オブジェクトにおけるカウンタ署名の例は、付録C.3.3に記載されています。

The creation and validation of counter signatures over the different items relies on the fact that the objects have the same structure. The elements are a set of protected attributes, a set of unprotected attributes, and a body, in that order. This means that the Sig_structure can be used in a uniform manner to get the byte stream for processing a signature. If the counter signature is going to be computed over a COSE_Encrypt structure, the body_protected and payload items can be mapped into the Sig_structure in the same manner as from the COSE_Sign structure.

異なるアイテムのカウンタ署名の作成と検証は、オブジェクトが同じ構造を持っていることに依存します。要素は、保護された属性のセット、保護されていない属性のセット、および本体の順になります。これは、Sig_structureが署名の処理のためのバイトストリームを一様な方法で取得するために使用できることを意味します。カウンタ署名がCOSE_Encrypt構造上で計算される場合、body_protectedおよびpayloadアイテムはCOSE_Sign構造からのものと同じ方法でSig_structureにマッピングできます。

It should be noted that only a signature algorithm with appendix (see Section 8) can be used for counter signatures. This is because the body should be able to be processed without having to evaluate the counter signature, and this is not possible for signature schemes with message recovery.

コンターサインには、追加情報を持つ署名アルゴリズム（セクション8を参照）のみ使用できることに注意する必要があります。これは、本文がコンターサインを評価せずに処理できるようにする必要があり、メッセージ回復を伴う署名スキームでは不可能です。

5.1. Enveloped COSE Structure

5.1. 暗号化されたCOSE構造

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

この封筒構造では、メッセージの一人以上の受信者が可能です。メッセージには、コンテンツに関するパラメーターと受信者情報に関するパラメーターが含まれるように規定されています。コンテンツに関連する保護パラメーターは、コンテンツ暗号化アルゴリズムによって認証されます。受信者に関連する保護パラメーターは、受信者アルゴリズムによって認証されます（アルゴリズムがサポートしている場合）。コンテンツに関するパラメーターの例は、コンテンツの種類とコンテンツ暗号化アルゴリズムです。受信者に関するパラメーターの例は、受信者の鍵識別子と受信者の暗号化アルゴリズムです。

The same techniques and structures 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 for 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 encrypted messages can be found in Appendix C.3.

暗号化には、平文と鍵の両方に同じ技術と構造が使用されます。これは、"Cryptographic Message Syntax (CMS)" [RFC5652] および "JSON Web Encryption (JWE)" [RFC7516] で異なる構造がコンテンツ層と受信者層の両方に使用されるのとは異なります。2つの構造が定義されています。COSE_Encryptは暗号化されたコンテンツを保持し、COSE_recipientは受信者の暗号化された鍵を保持します。暗号化されたメッセージの例については、付録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構造体は、使用される文脈に応じて、タグ付きまたはタグなしでエンコードされることがあります。タグ付きのCOSE_Encrypt構造体は、CBORタグ96によって識別されます。これを表すCDDLフラグメントは以下の通りです：

COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)

COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)

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.

protected: これはセクション3で説明されているとおりです。

unprotected: This is as described in Section 3.

unprotected: これはセクション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.

ciphertext: このフィールドには、bstrとしてエンコードされた暗号文が含まれています。もし暗号文が暗号化プロセスに関する制御情報と独立して転送される場合（すなわち、切り離されたコンテンツの場合）、このフィールドはnil値としてエンコードされます。

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

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

The CDDL fragment that corresponds to the above text is:

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

COSE_Encrypt = [ Headers, ciphertext : bstr / nil, recipients : [+COSE_recipient] ]

COSE_Encrypt = [ Headers, ciphertext : bstr / nil, recipients : [+COSE_recipient] ]

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.

protected: これはセクション3で説明されています。

unprotected: This is as described in Section 3.

unprotected: これはセクション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.

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

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.

recipients: このフィールドには、受信者情報の構造体の配列が含まれています。受信者情報の構造体の型はCOSE_recipientです（この一例は付録Bにあります）。受信者情報の構造体が存在しない場合、この要素は存在しません。

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

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

COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ]

COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ]

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.3.

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

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フラグメントは次の通りです：

COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

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.

保護されました: これはセクション3で説明されているとおりです。

unprotected: This is as described in Section 3.

未保護：これはセクション3で説明されているようになります。

ciphertext: This is as described in Section 5.1.

暗号文：これはセクション5.1で説明されているものです。

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

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

COSE_Encrypt0 = [ Headers, ciphertext : bstr / nil, ]

COSE_Encrypt0 = [ Headers, ciphertext : bstr / nil, ] COSE_Encrypt0 = [Headers、ciphertext : bstr / nil]

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 stream 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 text string identifying the context of the authenticated data structure. The context string is:

1. 認証されたデータ構造の文脈を識別するテキスト文字列です。文脈文字列は次の通りです:

2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used.

2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used.

3. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero- length bstr. (See Section 4.3 for application guidance on constructing this field.)

3. アプリケーションからエンコードされた保護された属性は、bstr タイプで提供されます。このフィールドが提供されていない場合、長さゼロの bstr がデフォルトで使用されます（このフィールドの構築に関するアプリケーションのガイダンスについては、セクション4.3を参照してください）。

The CDDL fragment that describes the above text is:

上記のテキストを記述するCDDLの断片は以下の通りです：

Enc_structure = [ context : "Encrypt" / "Encrypt0" / "Enc_Recipient" / "Mac_Recipient" / "Rec_Recipient", protected : empty_or_serialized_map, external_aad : bstr ]

Enc_structure = [ context : 「暗号化」/「Encrypt0」/「受信者の暗号化」/「受信者のMAC」/「受信者の記録」, protected : empty_or_serialized_map, external_aad : bstr ]

How to encrypt a message:

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

1. Create an Enc_structure and populate it with the appropriate fields.

1. 適切なフィールドで Enc_structure を作成し、それに値を入れます。

2. Encode the Enc_structure to a byte stream (Additional Authenticated Data (AAD)), using the encoding described in Section 14.

2. Enc_structureをバイトストリーム（追加認証データ（AAD））にエンコードします。エンコード方法は、セクション14で説明されています。

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

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

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.

4. K（暗号化キー）、P（平文）、およびAADで暗号化アルゴリズムを呼び出します。返された暗号文を構造体の「ciphertext」フィールドに配置します。

5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plaintext.

5. メッセージの受信者に対して、K（暗号化キー）を平文として、その受信者のために再帰的に暗号化アルゴリズムを実行します。

How to decrypt a message:

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

1. Create an Enc_structure and populate it with the appropriate fields.

1. 適切なフィールドで Enc_structure を作成し、それを埋める。

2. Encode the Enc_structure to a byte stream (AAD), using the encoding described in Section 14.

2. Enc_structure をバイトストリーム (AAD) にエンコードします。エンコードの詳細については、セクション14を参照してください。

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

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

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

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 empty.

1. 「'protected' フィールドが空であることを確認します。」

2. Verify that there was no external additional authenticated data supplied for this operation.

2. この操作に対して外部からの追加認証データが提供されていないことを確認します。

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

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

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.

4. K（使用する暗号化キー）およびP（平文）と共に、暗号化アルゴリズムを呼び出します。返された暗号文を、構造体の「ciphertext」フィールドに配置します。

5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plaintext.

5. メッセージの受信者に対して、暗号化アルゴリズムを再帰的に実行し、平文として暗号化鍵である K を使用します。

How to decrypt a message:

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

1. Verify that the 'protected' field is empty.

1. 'protected' フィールドが空であることを確認します。

2. Verify that there was no external additional authenticated data supplied for this operation.

2. この操作に対して外部から追加の認証データが提供されていないことを確認してください。

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

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

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

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

6.1. MACed Message with Recipients

6.1. MACed Message with Recipients

The 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構造体と、MAC計算に使用される鍵を保持するためのCOSE_recipient構造体（セクション5.1）です。MAC付きメッセージの例は、付録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フラグメントは次のとおりです：

COSE_Mac_Tagged = #6.97(COSE_Mac)

COSE_Mac_Tagged = #6.97(COSE_Mac)

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.

保護されています: これはセクション3で説明されている通りです。

unprotected: This is as described in Section 3.

未保護: これはセクション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.

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

tag: This field contains the MAC value.

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

recipients: This is as described in Section 5.1.

受信者: これはセクション5.1で説明されているようにします。

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

上記のテキストを表すCOSE_MacのためのCDDLフラグメントは次のとおりです。

COSE_Mac = [ Headers, payload : bstr / nil, tag : bstr, recipients :[+COSE_recipient] ]

COSE_Mac = [ Headers, payload : bstr / nil, tag : bstr, recipients :[+COSE_recipient] ] COSE_Mac = [ ヘッダー, ペイロード : バイナリーストリング / 無し, タグ : バイナリーストリング, 受信者 :[+COSE_recipient] ]

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.

MACされたメッセージは、このセクションで定義されているCOSE_Mac0構造体を使用して本文を運びます。暗黙のキーを持つMACされたメッセージの例は、付録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フラグメントは次のとおりです：

COSE_Mac0_Tagged = #6.17(COSE_Mac0)

COSE_Mac0_Tagged = #6.17(COSE_Mac0)

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.

保護されています：これはセクション3で説明されているものです。

unprotected: This is as described in Section 3.

未保護：これはセクション3で説明されているものです。

payload: This is as described in Section 6.1.

payload: これはセクション6.1に記載されているとおりです。

tag: This field contains the MAC value.

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

The CDDL fragment that corresponds to the above text is:

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

COSE_Mac0 = [ Headers, payload : bstr / nil, tag : bstr, ]

COSE_Mac0 = [ Headers, payload : bstr / nil, tag : bstr, ] COSE_Mac0 = [ ヘッダー, ペイロード : bstr / nil, タグ : bstr, ]

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 have a 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 text string that identifies the structure that is being encoded. This string is "MAC" for the COSE_Mac structure. This string is "MAC0" for the COSE_Mac0 structure.

1. エンコードされている構造を識別するテキスト文字列です。COSE_Mac 構造体の場合、この文字列は「MAC」です。COSE_Mac0 構造体の場合、この文字列は「MAC0」です。

2. The protected attributes from the COSE_MAC structure. If there are no protected attributes, a zero-length bstr is used.

2. COSE_MAC構造から保護された属性です。保護された属性がない場合は、長さゼロのbstrが使用されます。

3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero- length binary string. (See Section 4.3 for application guidance on constructing this field.)

3. アプリケーションから保護された属性を、bstr タイプとしてエンコードします。このフィールドが指定されていない場合、長さがゼロのバイナリー文字列にデフォルトで設定されます（このフィールドの構築に関するアプリケーションのガイダンスについては、セクション4.3を参照してください）。

4. The payload to be MACed encoded in a bstr type. The payload is placed here independent of how it is transported.

4. ここに運搬方法に関係なく配置される、bstr型でエンコードされたMACを持つペイロード。

The CDDL fragment that corresponds to the above text is:

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

MAC_structure = [ context : "MAC" / "MAC0", protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ]

MAC_structure = [ context : 「MAC」または「MAC0」, protected : 空またはシリアライズされたマップ, external_aad : バイナリー文字列, payload : バイナリー文字列 ]

The steps to compute a MAC are:

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

1. Create a MAC_structure and populate it with the appropriate fields.

1. 適切なフィールドでMAC_structureを作成し、それを埋める。

2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14.

2. 値ToBeMacedを作成します。MAC_structureをバイトストリームにエンコードし、セクション14で説明されているエンコーディングを使用します。

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).

3. K（使用するキー）、alg（MACを作成するアルゴリズム）、および ToBeMaced（MACを計算する値）を渡してMAC作成アルゴリズムを呼び出します。

4. Place the resulting MAC in the 'tag' field of the COSE_Mac or COSE_Mac0 structure.

4. 生成されたMACをCOSE_MacまたはCOSE_Mac0構造体の'tag'フィールドに配置します。

5. Encrypt and encode the MAC key for each recipient of the message.

5. メッセージの各受信者のためにMACキーを暗号化して符号化します。

The steps to verify a MAC are:

MACを検証する手順は以下の通りです：

1. Create a MAC_structure object and populate it with the appropriate fields.

1. MAC_structureオブジェクトを作成し、適切なフィールドで埋める。

2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14.

2. 値ToBeMacedを作成します。MAC_structureをバイトストリームにエンコードし、Section 14で説明されているエンコードを使用します。

3. Obtain the cryptographic key from one of the recipients of the message.

3. メッセー ジの受信者のうちの一人から暗号鍵を取得します。

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).

4. K（使用するキー）、alg（MACを生成するアルゴリズム）、ToBeMaced（MACを計算する値）を渡してMAC作成アルゴリズムを呼び出します。

5. Compare the MAC value to the 'tag' field of the COSE_Mac or COSE_Mac0 structure.

5. COSE_MacまたはCOSE_Mac0構造体の'tag'フィールドとMAC値を比較します。

7.1. COSE Key Common Parameters

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

This document defines a set of common parameters for a COSE Key object. Table 3 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 Section 13.

このドキュメントは、COSEキーオブジェクトの共通パラメーターセットを定義しています。テーブル3は、このセクションで定義されているパラメーターの概要を提供しています。また、特定のキータイプに対して定義されたパラメーターもあります。キータイプ固有のパラメーターは、セクション13に記載されています。

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 Table 21. 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.

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

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.

alg：このパラメーターは、鍵と一緒に使用されるアルゴリズムを制限するために使用されます。もし鍵構造にこのパラメーターが存在する場合、アプリケーションはこのアルゴリズムが鍵が使用されるアルゴリズムと一致していることを確認しなければなりません（MUST）。もしアルゴリズムが一致しない場合、この鍵オブジェクトは暗号操作を実行するためにしてはなりません（MUST NOT）。同じ鍵は異なるアルゴリズムが指定されている別の鍵構造に存在するかもしれませんが、これはセキュリティーの観点からは望ましくない行為とされます。

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 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.

kid: このパラメーターは、キーに識別子を与えるために使用されます。識別子は構造化されておらず、ユーザーが提供した文字列からキーの公開部分で計算された値まで、何でも良いです。このフィールドは、確認する必要のあるキーのセットを絞り込むために、メッセージの中の 'kid' パラメーターと一致させるために意図されています。

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 4. 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].

key_ops（キーオプス）：このパラメーターは、キーに使用する操作の集合を制限するために定義されています。フィールドの値は、テーブル4の値の配列です。アルゴリズムは、出現を許可されるキーの操作の値を定義し、特定の操作には必要です。値のセットは、[RFC7517]および[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 Partial IV with a key that is then modified on a per message basis with the Partial IV.

Base IV: このパラメーターは、IVのベース部分を運ぶために定義されています。これは、セクション3.1で定義されたPartial IVヘッダーパラメーターと共に使用するように設計されています。このフィールドは、Partial IVとキーを関連付け、メッセージごとにPartial IVで修正されるキーを提供します。

8.1. ECDSA

8.1. ECDSA

ECDSA [DSS] defines a signature algorithm using ECC. Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithm allows for systems to avoid relying on random number generators in order to avoid generating the same value of 'k' (the per-message random value). Biased generation of the value 'k' can be attacked, and collisions of this value leads to leaked keys. It additionally allows for doing deterministic tests for the signature algorithm. The use of deterministic ECDSA does not lessen the need to have good random number generation when creating the private key.

ECDSAはECCを使用した署名アルゴリズムを定義しています。実装はすべきです（SHOULD）決定論的ECDSAのバージョンを使用することをお勧めします。このバージョンは[RFC6979]で定義されています。決定論的署名アルゴリズムの使用により、システムはランダム数生成器に依存せずに、同じ値の 'k'（メッセージ毎のランダム値）を生成することを回避できます。値 'k' の偏りがある生成は攻撃され、この値の衝突は鍵の漏洩につながります。さらに、決定論的ECDSAは署名アルゴリズムの決定論的なテストを行うことも可能にします。決定論的ECDSAの使用は、プライベートキーを作成する際の良好なランダム数生成の必要性を減じるものではありません。

The ECDSA signature algorithm is parameterized with a hash function (h). In the event that the length of the hash function output is greater than the group of the key, the leftmost bytes of the hash output are used.

ECDSA署名アルゴリズムはハッシュ関数（h）でパラメーター化されます。ハッシュ関数の出力の長さが鍵のグループよりも大きい場合、ハッシュ出力の左端のバイトが使用されます。

The algorithms defined in this document can be found in Table 5.

このドキュメントで定義されたアルゴリズムは、表5に記載されています。

This document defines ECDSA to work only with the curves P-256, P-384, and P-521. This document requires that the curves be encoded using the 'EC2' (2 coordinate elliptic curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Other documents can define it to work with other curves and points in the future.

このドキュメントは、ECDSAが曲線P-256、P-384、およびP-521だけで動作するように定義しています。このドキュメントでは、曲線を 'EC2'（2座標楕円曲線）キータイプを使用してエンコードすることが要求されています。実装は、署名の作成と検証時にキータイプと曲線が正しいことを確認する必要があります。他のドキュメントでは、将来的に他の曲線や点との連携を定義することができます。

In order to promote interoperability, it is suggested that SHA-256 be used only with curve P-256, SHA-384 be used only with curve P-384, and SHA-512 be used with curve P-521. This is aligned with the recommendation in Section 4 of [RFC5480].

相互運用性を促進するために、SHA-256はカーブP-256とのみ使用されることが提案されており、SHA-384はカーブP-384とのみ使用され、SHA-512はカーブP-521と使用されることが推奨されています。これは、[RFC5480]のSection 4での推奨事項と一致しています。

The signature algorithm results in a pair of integers (R, S). These integers will be the same length as the length of the key used for the signature process. The signature is encoded by converting the integers into byte strings of the same length as the key size. The length is rounded up to the nearest byte and is left padded with zero bits to get to the correct length. The two integers are then concatenated together to form a byte string that is the resulting signature.

署名アルゴリズムは、整数のペア（R、S）を生成します。これらの整数の長さは、署名プロセスに使用される鍵の長さと同じです。署名は、整数を鍵の長さと同じ長さのバイト列に変換してエンコードされます。長さは最も近いバイトに切り上げられ、正しい長さに到達するためにゼロビットで左パディングされます。その後、2つの整数は連結され、結果の署名が形成されます。

Using the function defined in [RFC8017], the signature is: Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8)

[RFC8017]で定義された関数を使用して、署名は以下のようになります：署名 = I2OSP(R, n) | I2OSP(S, n)、ただし n = key_length / 8 の上限付き整数部分

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムでCOSEキーを使用する場合、次のチェックが行われます：します（MUST）。

• The 'kty' field MUST be present, and it MUST be 'EC2'.

• 「'kty'フィールドは存在しなければなりません（MUST）、かつ『EC2』でなければなりません（MUST）」

• If the 'alg' field is present, it MUST match the ECDSA signature algorithm being used.

• もし「'alg'」フィールドが存在する場合、それは使用されているECDSA署名アルゴリズムと一致しなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'sign' when creating an ECDSA signature.

• もし 'key_ops' フィールドが存在する場合、ECDSA 署名を作成する際には、'key_ops' フィールドに 'sign' を含める必要があります。

• If the 'key_ops' field is present, it MUST include 'verify' when verifying an ECDSA signature.

• もし 'key_ops' フィールドが存在する場合、ECDSA 署名の検証時に 'verify' を含める必要があります。

8.2. Edwards-Curve Digital Signature Algorithms (EdDSAs)

8.2. エドワーズ曲線デジタル署名アルゴリズム（EdDSA）

[RFC8032] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing, and HashEdDSA, where a hash function is applied to the content before signing and the result of that hash function is signed. For EdDSA, the content to be signed (either the message or the pre-hash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. This means that there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE object (with the hash value) and the content as separate items.

[RFC8032]は、楕円曲線署名方式であるEdwards-curve Digital Signature Algorithm (EdDSA)について説明しています。この文書では、署名アルゴリズムはedwards25519とedwards448の曲線のパラメーターを使用してインスタンス化されます。さらに、EdDSAアルゴリズムの2つのバリアント（Pure EdDSAおよびHashEdDSA）についても説明しています。Pure EdDSAでは、署名前にコンテンツにハッシュ関数を適用しない場合、HashEdDSAでは署名前にコンテンツにハッシュ関数を適用し、そのハッシュ関数の結果を署名します。EdDSAでは、署名アルゴリズム内で署名対象となるコンテンツ（メッセージまたはプリハッシュ値）が2回処理されます。COSEとの使用においては、純粋なEdDSAバージョンのみが使用されます。これは、非常に大きなコンテンツが必要とされることは予想されておらず、メッセージ構造の配置に基づいて、署名を作成または検証するためにメモリにメッセージ全体を保持する必要があるためです。つまり、ハッシュのブロック更新を行い、その後メッセージをメモリから削除する必要性はないようです。アプリケーションは、メッセージの内容をハッシュ値として定義し、COSEオブジェクト（ハッシュ値と共に）とコンテンツを別々に転送することで同じ機能を提供することができます。

The algorithms defined in this document can be found in Table 6. A single signature algorithm is defined, which can be used for multiple curves.

このドキュメントで定義されたアルゴリズムは、表6に記載されています。複数の曲線で使用できる、単一の署名アルゴリズムが定義されています。

[RFC8032] describes the method of encoding the signature value.

[RFC8032]は、署名値のエンコード方法について説明しています。

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムでCOSEキーを使用する場合、以下のチェックが行われます：

• The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key Pair).

• 'kty'フィールドは存在しなければならず、'OKP'（オクテットキーペア）でなければなりません。

• The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm.

• 「crv」フィールドは存在しなければならず、この署名アルゴリズムに定義された曲線である必要があります。

• If the 'alg' field is present, it MUST match 'EdDSA'.

• もし'alg'フィールドが存在する場合、それは'EdDSA'と一致しなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature.

• key_opsフィールドが存在する場合、EdDSA署名を作成する際にsignを含まなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature.

• もし 'key_ops' フィールドが存在する場合、EdDSA 署名を検証する際に 'verify' を含む必要があります。

9.1. Hash-Based Message Authentication Codes (HMACs)

9.1. メッセージ認証コード（HMAC）

HMAC [RFC2104] [RFC4231] was designed to deal with length extension attacks. The algorithm was also designed to allow for new hash algorithms to be directly plugged in without changes to the hash function. The HMAC design process has been shown as solid since, while the security of hash algorithms such as MD5 has decreased over time; the security of HMAC combined with MD5 has not yet been shown to be compromised [RFC6151].

HMAC [RFC2104] [RFC4231]は、長さ拡張攻撃に対処するために設計されています。このアルゴリズムはまた、新しいハッシュアルゴリズムをハッシュ関数を変更することなしに直接組み込むことを可能にするために設計されています。HMACの設計プロセスは、MD5などのハッシュアルゴリズムのセキュリティーが時間とともに低下している一方で、HMACとMD5を組み合わせたセキュリティーがまだ妥協されていないことが示されています[RFC6151]。

The HMAC algorithm is parameterized by an inner and outer padding, a hash function (h), and an authentication tag value length. For this specification, the inner and outer padding are fixed to the values set in [RFC2104]. The length of the authentication tag corresponds to the difficulty of producing a forgery. For use in constrained environments, we define a set of HMAC algorithms that are truncated.

HMACアルゴリズムは、内部および外部のパディング、ハッシュ関数（h）、および認証タグ値の長さによってパラメーター化されます。この仕様では、内部および外部のパディングは、[RFC2104]で設定された値で固定されています。認証タグの長さは、偽造を生成する難度に対応します。制約のある環境での使用のために、切り詰められた一連のHMACアルゴリズムを定義します。

There are currently no known issues with truncation; however, the security strength of the message tag is correspondingly reduced in strength. When truncating, the leftmost tag length bits are kept and transmitted.

現在、切り捨てに関する既知の問題はありません。ただし、メッセージタグのセキュリティー強度はそれに応じて弱体化します。切り捨てる場合、左端のタグの長さビットが保持され、送信されます。

The algorithms defined in this document can be found in Table 7.

このドキュメントで定義されているアルゴリズムは、テーブル7にあります。

Some recipient algorithms carry the key while others derive a key from secret data. For those algorithms that carry the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function.

一部の受信者アルゴリズムは鍵を保持し、他のものは秘密データから鍵を導出します。鍵を保持するアルゴリズム（AES Key Wrapなど）においては、HMAC鍵のサイズは底層のハッシュ関数と同じサイズであるべきです（SHOULD）。鍵を導出するアルゴリズム（ECDHなど）においては、導出された鍵のサイズは底層のハッシュ関数と同じサイズでなければなりません（MUST）。

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムにCOSEキーを使用する場合、以下のチェックが行われます：しなければなりません（MUST）

• The 'kty' field MUST be present, and it MUST be 'Symmetric'.

• 'kty'フィールドはしなければなりません（MUST）存在し、'Symmetric'でなければなりません（MUST）。

• If the 'alg' field is present, it MUST match the HMAC algorithm being used.

• もし「alg」フィールドが存在する場合、それは使用中のHMACアルゴリズムと一致しなければなりません（MUST match）。

• If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag.

• key_opsフィールドが存在する場合、HMAC認証タグを作成する際に、key_opsフィールドには必ず「MAC create」を含める必要があります。

• If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag.

• もし「key_ops」のフィールドが存在する場合、HMAC認証タグを検証する際に、「MACの検証」を含めなければなりません。

Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

実装は、MAC値を作成および検証する場合、関係するエンティティに対してキーのタイプ、キーの長さ、およびアルゴリズムが正しいか適切であることを確認しなければなりません（MUST）。

9.2. AES Message Authentication Code (AES-CBC-MAC)

9.2. AESメッセージ認証コード（AES-CBC-MAC）

AES-CBC-MAC is defined in [MAC]. (Note that this is not the same algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) [RFC4493].)

AES-CBC-MACは、[MAC]で定義されています。（AES Cipher-Based Message Authentication Code（AES-CMAC）[RFC4493]とは異なるアルゴリズムであることに注意してください。）

AES-CBC-MAC is parameterized by the key length, the authentication tag length, and the IV used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key lengths and tag lengths. The algorithms defined in this document are found in Table 8.

AES-CBC-MACは、キーの長さ、認証タグの長さ、および使用されるIVによってパラメーター化されます。これらのすべてのアルゴリズムにおいて、IVはすべてゼロで固定されています。私たちは、さまざまなキーの長さとタグの長さに対して、アルゴリズムの配列を提供しています。このドキュメントで定義されているアルゴリズムは、表8にあります。

Keys may be obtained either from a key structure or from a recipient structure. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

キーは、キー構造または受信者構造から取得することができます。MAC値を作成および検証する実装は、キーのタイプ、キーの長さ、アルゴリズムが正しいかつ関連するエンティティに適切であることを必ずしも確認しなければなりません（MUST）。

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムでCOSEキーを使用する場合、次のチェックが行われます：

• The 'kty' field MUST be present, and it MUST be 'Symmetric'.

• 「kty」フィールドは存在しなければならず、その値は「Symmetric」でなければなりません。

• If the 'alg' field is present, it MUST match the AES-MAC algorithm being used.

• algフィールドが存在する場合、それは使用されているAES-MACアルゴリズムと一致しなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag.

• もし「key_ops」フィールドが存在するなら、AES-MAC認証タグを作成する際には「MAC作成」を含めなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag.

• もし 'key_ops' フィールドが存在する場合、AES-MAC 認証タグを検証する際に、'MAC verify' を含めなければなりません（MUST）。

10.1. AES GCM

10.1. AES GCM

The Galois/Counter Mode (GCM) mode is a generic authenticated encryption block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher.

Galois/Counter Mode（GCM）モードは、[AES-GCM]で定義された一般的な認証付き暗号化ブロック暗号モードです。GCMモードは、AESブロック暗号アルゴリズムと組み合わせてAEAD暗号を定義します。

The GCM mode is parameterized by the size of the authentication tag and the size of the nonce. This document fixes the size of the nonce at 96 bits. The size of the authentication tag is limited to a small set of values. For this document however, the size of the authentication tag is fixed at 128 bits.

GCMモードは認証タグのサイズとノンスのサイズによってパラメーター化されます。このドキュメントでは、ノンスのサイズを96ビットに固定します。認証タグのサイズは、一部の値に制限されます。ただし、本ドキュメントでは認証タグのサイズが128ビットに固定されます。

The set of algorithms defined in this document are in Table 9.

このドキュメントで定義されているアルゴリズムのセットは、表9にあります。

Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

鍵は、鍵の構造または受信者の構造から取得できます。暗号化および復号化を行う実装は、鍵のタイプ、鍵の長さ、およびアルゴリズムが関係するエンティティに対して正しいか適切かを確認しなければなりません（MUST）。

When using a COSE key for this algorithm, the following checks are made:

When using a COSE key for this algorithm, the following checks are made:

• The 'kty' field MUST be present, and it MUST be 'Symmetric'.

• 「'kty'フィールドはしなければなりません（MUST）、そして「Symmetric」であるしなければなりません（MUST）。」

• If the 'alg' field is present, it MUST match the AES-GCM algorithm being used.

• もし「alg」フィールドが存在する場合、使用されているAES-GCMアルゴリズムと一致しなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.

• もし 'key_ops' フィールドが存在する場合、暗号化する際に 'encrypt' または 'wrap key' を含めるべきです（MUST）。

• If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.

• もし'key_ops'フィールドが存在する場合、復号化する際には'decrypt'または'unwrap key'を含まなければなりません。

10.2. AES CCM

10.2. AES CCM

CCM is a generic authentication encryption block cipher mode defined in [RFC3610]. The CCM mode is combined with the AES block encryption algorithm to define a commonly used content encryption algorithm used in constrained devices.

CCMは、[RFC3610]で定義された一般的な認証暗号化ブロック暗号モードです。CCMモードはAESブロック暗号アルゴリズムと組み合わされ、制約されたデバイスでよく使用されるコンテンツ暗号化アルゴリズムを定義します。

The CCM mode has two parameter choices. The first choice is M, the size of the authentication field. The choice of the value for M involves a trade-off between message growth (from the tag) and the probability that an attacker can undetectably modify a message. The second choice is L, the size of the length field. This value requires a trade-off between the maximum message size and the size of the Nonce.

CCMモードには2つのパラメーターの選択があります。最初の選択肢は、認証フィールドのサイズであるMです。Mの値の選択は、メッセージの成長（タグからの成長）と、攻撃者がメッセージを検知されずに変更できる確率とのトレードオフを含みます。2番目の選択肢は、長さフィールドのサイズであるLです。この値は、最大メッセージサイズとNonceのサイズとの間でトレードオフを必要とします。

It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunderstandings where AES-CCM-8 is frequently used to refer to a version of CCM mode where the size of the authentication is 64 bits and not 8 bits. These values have traditionally been specified as bit counts rather than byte counts. This document will follow the convention of using bit counts so that it is easier to compare the different algorithms presented in this document.

CCMの仕様では、LおよびMがバイト数ではなくビット数のカウントとして指定されるという点が残念です。これにより、AES-CCM-8がCCMモードの認証のサイズが8ビットではなく64ビットであるバージョンを指すことが頻繁にあるため、誤解が生じる可能性があります。これらの値は従来、バイト数ではなくビット数として指定されてきました。本書では、異なるアルゴリズムを比較しやすくするために、ビット数のカウントの慣習に従います。

We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient- specific cryptographic operations. This favors smaller values of both L and M. Less-constrained devices will want to be able to use larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M.

このドキュメントでは、LとMの値にわたるアルゴリズムの行列を定義します。制約のあるデバイスは通常、短いメッセージを使用し、受信者固有の暗号操作を避けたいと考えています。これにより、LとMの両方の値が小さくなることが望まれます。制約の少ないデバイスでは、より大きなメッセージを使用したいと考え、各操作ごとに新しいキーを生成することにも積極的です。これにより、LとMの値が大きくなることが望まれます。

The following values are used for L:

Lには次の値が使用されます。

16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. This is sufficiently long for messages in the constrained world. The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating.

16ビット（2）：これにより、メッセージの長さは2^16バイト（64 KiB）に制限されます。これは制約のある世界のメッセージに十分な長さです。ノンスの長さは13バイトであり、繰り返すことなく2^(13*8)通りのノンスの値を許容します。

64 bits (8): This limits messages to 2^64 bytes in length. The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without repeating.

64ビット（8）：これにより、メッセージの長さは2^64バイトに制限されます。ノンスの長さは7バイトであり、繰り返しのないノンスの2^56通りの値が可能です。

The following values are used for M:

次の値は M に使用されます：

64 bits (8): This produces a 64-bit authentication tag. This implies that there is a 1 in 2^64 chance that a modified message will authenticate.

64ビット（8）：これにより、64ビットの認証タグが生成されます。これは、変更されたメッセージが認証される確率が2^64の1の可能性があることを意味します。

128 bits (16): This produces a 128-bit authentication tag. This implies that there is a 1 in 2^128 chance that a modified message will authenticate.

128ビット（16）：これにより、128ビットの認証タグが生成されます。これは、変更されたメッセージが認証される確率が2^128のうち1であることを意味します。

Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

キーはキー構造または受信者構造から取得することができます。暗号化および復号化を行う実装は、キータイプ、キー長、およびアルゴリズムが関係するエンティティに対して正しいか適切であることを確認しなければなりません（MUST）。

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムでCOSEキーを使用する場合、以下のチェックが行われます：MUST

• The 'kty' field MUST be present, and it MUST be 'Symmetric'.

• 'kty' フィールドは存在しなければならず、それは 'Symmetric' でなければなりません。

• If the 'alg' field is present, it MUST match the AES-CCM algorithm being used.

• 'alg' フィールドが存在する場合、使用されている AES-CCM アルゴリズムと一致しなければなりません（MUST）。

• If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.

• 'key_ops'フィールドが存在する場合、暗号化する際には、'encrypt'または'wrap key'を含める必要があります。

• If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.

• もし"key_ops"フィールドが存在する場合、復号化する際には"decrypt"または"unwrap key"を含めなければなりません（MUST）。

10.3. ChaCha20 and Poly1305

10.3. ChaCha20とPoly1305

ChaCha20 and Poly1305 combined together is an AEAD mode that is defined in [RFC7539]. This is an algorithm defined to be a cipher that is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implementations.

ChaCha20とPoly1305を組み合わせたものは、[RFC7539]で定義されているAEADモードです。これは、AESではない暗号方式であり、したがってAESで見つかった将来の脆弱性には影響を受けません。これらの暗号機能は、ソフトウェアのみで高速に動作するように設計されています。

The ChaCha20/Poly1305 AEAD construction defined in [RFC7539] has no parameterization. It takes a 256-bit key and a 96-bit nonce, as well as the plaintext and additional data as inputs and produces the ciphertext as an option. We define one algorithm identifier for this algorithm in Table 11.

ChaCha20/Poly1305 AEAD構造は、[RFC7539]で定義されており、パラメーター化されていません。これは256ビットのキーと96ビットのノンスを取り、またプレーンテキストと追加データを入力として、オプションとして暗号文を生成します。このアルゴリズムに対して、Table 11で1つのアルゴリズム識別子を定義します。

Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

キーはキー構造体または受信者構造体から取得することができます。 暗号化および復号化を実装する場合、キーの種類、キーの長さ、およびアルゴリズムが正しいかつ関連するエンティティに適切であることをしなければなりません（MUST）。

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムに対してCOSEキーを使用する場合、以下のチェックが行われます：

• The 'kty' field MUST be present, and it MUST be 'Symmetric'.

• 「kty」フィールドは存在しなければなりません（MUST）し、それは「Symmetric」である必要があります。

• If the 'alg' field is present, it MUST match the ChaCha20/Poly1305 algorithm being used.

• もし 'alg' フィールドが存在する場合、それは使用されているChaCha20/Poly1305アルゴリズムと一致しなければなりません。

• If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.

• もし「key_ops」フィールドが存在する場合、暗号化時には必ず「encrypt」または「wrap key」を含む必要があります。

• If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.

• もし 'key_ops' フィールドが存在する場合、復号化する際には 'decrypt' または 'wrap key' を含まなければなりません。

11.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF)

11.1. HMACベースの抽出および拡張キー導出関数（HKDF）

The HKDF key derivation algorithm is defined in [RFC5869].

HKDFキー派生アルゴリズムは、[RFC5869]で定義されています。

The HKDF algorithm takes these inputs:

HKDFアルゴリズムは、次の入力を受け取ります：

HKDF is defined to use HMAC as the underlying PRF. However, it is possible to use other functions in the same construct to provide a different KDF that is more appropriate in the constrained world. Specifically, one can use AES-CBC-MAC as the PRF for the expand step, but not for the extract step. When using a good random shared secret of the correct length, the extract step can be skipped. For the AES algorithm versions, the extract step is always skipped.

HKDFは、基のPRFとしてHMACを使用するように定義されています。ただし、制約のある世界により適した異なるKDFを提供するために、同じ構造で他の関数を使用することも可能です。具体的には、AES-CBC-MACをPRFとしてexpandステップに使用することができますが、extractステップには使用できません。適切な長さの良質なランダム共有秘密を使用する場合、extractステップはスキップできます。AESアルゴリズムのバージョンでは、必ずextractステップはスキップされます。

The extract step cannot be skipped if the secret is not uniformly random, for example, if it is the result of an ECDH key agreement step. This implies that the AES HKDF version cannot be used with ECDH. If the extract step is skipped, the 'salt' value is not used as part of the HKDF functionality.

抽出ステップは、秘密が均一なランダムでない場合にはスキップすることはできません。例えば、ECDH鍵合意ステップの結果である場合などです。これにより、AES HKDFバージョンはECDHとは使用できません。抽出ステップをスキップすると、「salt」値はHKDF機能の一部として使用されません。

The algorithms defined in this document are found in Table 12.

このドキュメントで定義されたアルゴリズムは、表12に記載されています。

11.2. Context Information Structure

11.2. コンテキスト情報構造

The context information structure is used to ensure that the derived keying material is "bound" to the context of the transaction. The context information structure used here is based on that defined in [SP800-56A]. By using CBOR for the encoding of the context information structure, we automatically get the same type and length separation of fields that is obtained by the use of ASN.1. This means that there is no need to encode the lengths for the base elements, as it is done by the encoding used in JOSE (Section 4.6.2 of [RFC7518]).

コンテキスト情報構造は、派生キー素材がトランザクションのコンテキストに「バインド」されることを保証するために使用されます。ここで使用されるコンテキスト情報構造は、[SP800-56A]で定義されています。コンテキスト情報構造のエンコーディングにCBORを使用することで、ASN.1の使用によって得られるフィールドの型と長さの分離と同じものを自動的に得ることができます。これにより、基本要素の長さをエンコードする必要がなくなります。JOSEで使用されているエンコーディングと同様に、（[RFC7518]のSection 4.6.2）。

The context information structure refers to PartyU and PartyV as the two parties that are doing the key derivation. Unless the application protocol defines differently, we assign PartyU to the entity that is creating the message and PartyV to the entity that is receiving the message. By doing this association, different keys will be derived for each direction as the context information is different in each direction.

コンテキスト情報構造は、キー導出を行っている2つのパーティであるPartyUとPartyVを参照しています。アプリケーションプロトコルが異なる定義を行っていない限り、メッセージを作成しているエンティティにPartyUを割り当て、メッセージを受信しているエンティティにPartyVを割り当てます。この関連付けを行うことで、コンテキスト情報が各方向で異なるため、異なるキーが各方向に導出されます。

The context structure is built from information that is known to both entities. This information can be obtained from a variety of sources:

コンテキスト構造は、両者に共通の情報に基づいて構築されます。この情報は、さまざまなソースから取得できます。

• Fields can be defined by the application. This is commonly used to assign fixed names to parties, but it can be used for other items such as nonces.

• アプリケーションによってフィールドを定義することができます。これは通常、当事者に固定の名前を割り当てるために使用されますが、ノンスなどの他のアイテムにも使用することができます。

• Fields can be defined by usage of the output. Examples of this are the algorithm and key size that are being generated.

• フィールドは出力の使用によって定義することができます。生成されているアルゴリズムや鍵のサイズの例がこれに該当します。

• Fields can be defined by parameters from the message. We define a set of parameters in Table 14 that can be used to carry the values associated with the context structure. Examples of this are identities and nonce values. These parameters are designed to be placed in the unprotected bucket of the recipient structure; they do not need to be in the protected bucket since they already are included in the cryptographic computation by virtue of being included in the context structure.

• メッセージからパラメーターによってフィールドを定義することができます。表14に、コンテキスト構造に関連する値を運ぶために使用できるパラメーターのセットを定義します。アイデンティティや nonce の値などがこれにあたります。これらのパラメーターは、受信者構造の保護されていないバケットに配置することが想定されています。これらは保護されたバケットに含める必要はありません。なぜなら、コンテキスト構造に含まれることから、すでに暗号計算に含まれているからです。

We define a CBOR object to hold the context information. This object is referred to as COSE_KDF_Context. The object is based on a CBOR array type. The fields in the array are:

私たちは、コンテキスト情報を保持するためのCBORオブジェクトを定義します。このオブジェクトはCOSE_KDF_Contextと呼ばれます。このオブジェクトはCBOR配列型を基にしています。配列内のフィールドは以下の通りです：

AlgorithmID: This field indicates the algorithm for which the key material will be used. This normally is either a key wrap algorithm identifier or a content encryption algorithm identifier. The values are from the "COSE Algorithms" registry. This field is required to be present. The field exists in the context information so that if the same environment is used for different algorithms, then completely different keys will be generated for each of those algorithms. This practice means if algorithm A is broken and thus is easier to find, the key derived for algorithm B will not be the same as the key derived for algorithm A.

AlgorithmID（アルゴリズムID）：このフィールドは、キーマテリアルが使用されるアルゴリズムを示します。通常、これはキーラップアルゴリズム識別子またはコンテンツ暗号化アルゴリズム識別子のいずれかです。値は「COSE Algorithms（COSEアルゴリズム）」レジストリから取得されます。このフィールドは存在する必要があります。同じ環境で異なるアルゴリズムに使用される場合、各アルゴリズムごとに完全に異なるキーが生成されるため、このフィールドはコンテキスト情報に存在します。この実践により、アルゴリズムAが破損している場合、より容易に発見できるため、アルゴリズムBのために派生したキーはアルゴリズムAのために派生したキーとは異なります。

PartyUInfo: This field holds information about party U. The PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo are encoded in the order presented. The elements of the PartyUInfo array are:

PartyUInfo：このフィールドには、パーティUに関する情報が格納されます。PartyUInfoはCBOR配列としてエンコードされます。PartyUInfoの要素は提示された順序でエンコードされます。PartyUInfo配列の要素は次の通りです：

PartyVInfo: This field holds information about party V. The content of the structure is the same as for the PartyUInfo but for party V.

PartyVInfo：このフィールドはパーティーVに関する情報を保持します。この構造体の内容は、PartyUInfoと同じですが、パーティーV用です。

SuppPubInfo: This field contains public information that is mutually known to both parties.

SuppPubInfo：このフィールドには、双方の当事者に共有されている公開情報が含まれています。

SuppPrivInfo: This field contains private information that is mutually known private information. An example of this information would be a preexisting shared secret. (This could, for example, be used in combination with an ECDH key agreement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included.

SuppPrivInfo: This field contains private information that is mutually known private information. An example of this information would be a preexisting shared secret. (This could, for example, be used in combination with an ECDH key agreement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included.

The following CDDL fragment corresponds to the text above.

次のCDDLフラグメントは、上記のテキストに対応します。

PartyInfo = ( identity : bstr / nil, nonce : bstr / int / nil, other : bstr / nil )

PartyInfo = ( identity : bstr / nil, nonce : bstr / int / nil, other : bstr / nil ) PartyInfo =（identity：bstr / nil、nonce：bstr / int / nil、other：bstr / nil）

COSE_KDF_Context = [ AlgorithmID : int / tstr, PartyUInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ], SuppPubInfo : [ keyDataLength : uint, protected : empty_or_serialized_map, ? other : bstr ], ? SuppPrivInfo : bstr ]

COSE_KDF_Context = [ AlgorithmID : int / tstr, PartyUInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ], SuppPubInfo : [ keyDataLength : uint, protected : empty_or_serialized_map, ? other : bstr ], ? SuppPrivInfo : bstr ] COSE_KDF_Context = [ AlgorithmID : int / tstr, PartyUInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ], SuppPubInfo : [ keyDataLength : uint, protected : empty_or_serialized_map, ? other : bstr ], ? SuppPrivInfo : bstr ] COSE_KDF_Context = [ AlgorithmID : int / tstr, PartyUInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ], SuppPubInfo : [ keyDataLength : uint, protected : empty_or_serialized_map, ? other : bstr ], ? SuppPrivInfo : bstr ]

12.1. Direct Encryption

12.1. 直接暗号化

The direct encryption class algorithms share a secret between the sender and the recipient that is used either directly or after manipulation as the CEK. When direct encryption mode is used, it MUST be the only mode used on the message.

直接暗号化クラスのアルゴリズムは、送信者と受信者の間で共有される秘密を、CEKとして直接または変更後に使用します。直接暗号化モードが使用される場合、そのモードはメッセージでしなければなりません（MUST）。

The COSE_Recipient structure for the recipient is organized as follows:

受信者に対するCOSE_Recipient構造は、以下のように構成されます：

• The 'protected' field MUST be a zero-length item unless it is used in the computation of the content key.

• ``「protected」 フィールドは、コンテンツキーの計算に使用されない限り、長さゼロのアイテムでなければなりません。

• The 'alg' parameter MUST be present.

• 'alg'パラメーターは必ず存在しなければなりません（MUST）。

• A parameter identifying the shared secret SHOULD be present.

• 共有秘密を識別するパラメーターが存在するべきです（SHOULD）。

• The 'ciphertext' field MUST be a zero-length item.

• 「'ciphertext'フィールドは長さゼロのアイテムでなければなりません（MUST）」

• The 'recipients' field MUST be absent.

• 「recipients（受信者）」フィールドは存在してはなりません。

12.2. Key Wrap

12.2. キーラップ

In key wrap mode, the CEK is randomly generated and that key is then encrypted by a shared secret between the sender and the recipient. All of the currently defined key wrap algorithms for COSE are AE algorithms. Key wrap mode is considered to be superior to direct encryption if the system has any capability for doing random key generation. This is because the shared key is used to wrap random data rather than data that has some degree of organization and may in fact be repeating the same content. The use of key wrap loses the weak data origination that is provided by the direct encryption algorithms.

キーラップモードでは、CEKはランダムに生成され、そのキーは送信者と受信者の間で共有された秘密鍵によって暗号化されます。COSEで現在定義されているすべてのキーラップアルゴリズムはAEアルゴリズムです。キーラップモードは、システムがランダムキーの生成を行う能力を持っている場合には、直接暗号化よりも優れていると考えられています。これは、共有鍵がいくらかの組織化されたデータではなく、実際に同じ内容を繰り返す可能性があるデータではなく、ランダムデータをラップするために使用されるためです。キーラップの使用により、直接暗号化アルゴリズムによって提供される弱いデータの起源が失われます。

The COSE_Encrypt structure for the recipient is organized as follows:

受信者のためのCOSE_Encrypt構造は、以下のように構成されます：

• The 'protected' field MUST be absent if the key wrap algorithm is an AE algorithm.

• キーラップアルゴリズムがAEアルゴリズムの場合、'protected'フィールドは存在しない必要があります。

• The 'recipients' field is normally absent, but can be used. Applications MUST deal with a recipient field being present, not being able to decrypt that recipient is an acceptable way of dealing with it. Failing to process the message is not an acceptable way of dealing with it.

• 「受信者（recipients）」フィールドは通常存在しませんが、使用することができます。アプリケーションは、受信者フィールドが存在する場合に対応する必要があります。その受信者を復号化できないことは、それに対処する受け入れられる方法です。メッセージの処理に失敗することは、受け入れられる方法ではありません。

• The plaintext to be encrypted is the key from next layer down (usually the content layer).

• 平文を暗号化するのは、通常、下位のレイヤー（通常はコンテンツレイヤー）からのキーです。

• At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret.

• 少なくとも、「unprotected」フィールドには「alg」パラメーターを含む必要があり、共有シークレットを識別するパラメーターを含むべきです。

12.3. Key Transport

12.3. 主キー伝送

Key transport mode is also called key encryption mode in some standards. Key transport mode differs from key wrap mode in that it uses an asymmetric encryption algorithm rather than a symmetric encryption algorithm to protect the key. This document does not define any key transport mode algorithms.

鍵伝送モードは、一部の規格では鍵暗号化モードとも呼ばれています。鍵伝送モードは、鍵を保護するために対称暗号化アルゴリズムではなく、非対称暗号化アルゴリズムを使用する点で鍵包装モードと異なります。このドキュメントでは、鍵伝送モードのアルゴリズムを定義していません。

When using a key transport algorithm, the COSE_Encrypt structure for the recipient is organized as follows:

キー転送アルゴリズムを使用する場合、受信者のためのCOSE_Encrypt構造体は、次のように編成されます：

• The 'protected' field MUST be absent.

• 「'protected' フィールドは存在してはなりません（MUST NOT）」

• The plaintext to be encrypted is the key from the next layer down (usually the content layer).

• 平文を暗号化するための鍵は、通常、下位の次のレイヤー（通常はコンテンツ層）から取得されます。

• At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the asymmetric key.

• 少なくとも、「unprotected」フィールドには「alg」パラメーターが含まれている必要があり、非対称キーを識別するパラメーターが含まれるべきです。

12.4. Direct Key Agreement

12.4. 直接鍵確立

The 'direct key agreement' class of recipient algorithms uses a key agreement method to create a shared secret. A KDF is then applied to the shared secret to derive a key to be used in protecting the data. This key is normally used as a CEK or MAC key, but could be used for other purposes if more than two layers are in use (see Appendix B).

受信者アルゴリズムの「直接鍵合意」クラスは、共有秘密鍵を作成するために鍵合意手法を使用します。その後、共有秘密鍵にKDFを適用して、データの保護に使用される鍵を派生させます。この鍵は通常、CEKまたはMAC鍵として使用されますが、複数のレイヤーが使用されている場合には他の目的にも使用できます（付録Bを参照）。

The most commonly used key agreement algorithm is Diffie-Hellman, but other variants exist. Since COSE is designed for a store and forward environment rather than an online environment, many of the DH variants cannot be used as the receiver of the message cannot provide any dynamic key material. One side effect of this is that perfect forward secrecy (see [RFC4949]) is not achievable. A static key will always be used for the receiver of the COSE object.

最も一般的に使用される鍵合意アルゴリズムはディフィー・ヘルマンですが、他のバリアントも存在します。COSEはオンライン環境ではなく、ストアアンドフォワード環境を対象として設計されているため、DHの多くのバリアントはメッセージの受信者が動的鍵素材を提供できないため使用することができません。これの副作用の1つは、完全な順次送信保証（詳細はRFC4949を参照してください）が実現できないということです。COSEオブジェクトの受信者には常に静的鍵が使用されます。

Two variants of DH that are supported are:

サポートされているDHの2つのバリアントは次のとおりです：

When direct key agreement mode is used, there MUST be only one recipient in the message. This method creates the key directly, and that makes it difficult to mix with additional recipients. If multiple recipients are needed, then the version with key wrap needs to be used.

直接鍵合意モードを使用する場合、メッセージにはしなければなりません（MUST）、1つの受信者のみが存在する必要があります。この方法は鍵を直接生成するため、他の受信者との組み合わせが難しくなります。複数の受信者が必要な場合は、鍵包装を使用するバージョンを使う必要があります。

The COSE_Encrypt structure for the recipient is organized as follows:

受信者のためのCOSE_Encrypt構造は、以下のように構成されます：

• At a minimum, headers MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the recipient's asymmetric key.

• 少なくとも、ヘッダーは 'alg' パラメーターを含み、受信者の非対称キーを識別するパラメーターを含むべきです。

• The headers SHOULD identify the sender's key for the static-static versions and MUST contain the sender's ephemeral key for the ephemeral-static versions.

• ヘッダーは、静的-静的バージョンでは送信者のキーを識別するべきです。また、一時的-静的バージョンでは送信者の一時的なキーを含む必要があります。

12.5. Key Agreement with Key Wrap

12.5. キーラップを伴うキーアグリーメント

Key Agreement with Key Wrap uses a randomly generated CEK. The CEK is then encrypted using a key wrap algorithm and a key derived from the shared secret computed by the key agreement algorithm. The function for this would be:

キー交換とキーラップは、ランダムに生成されたCEKを使用します。そのCEKは、キーラップアルゴリズムと、キー交換アルゴリズムによって計算される共有秘密から派生したキーを使用して暗号化されます。このための関数は次のとおりです：

encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK) The COSE_Encrypt structure for the recipient is organized as follows:

encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK) 受信者向けのCOSE_Encrypt構造体は、次のように構成されます:

• The 'protected' field is fed into the KDF context structure.

• 「'protected' フィールドは、KDF コンテキスト構造に入力されます。」

• The plaintext to be encrypted is the key from the next layer down (usually the content layer).

• 平文を暗号化するのは、通常、下の階層からのキー（通常はコンテンツ層）です。

• The 'alg' parameter MUST be present in the layer.

• レイヤーには、'alg'パラメーターがしなければなりません（MUST）存在している必要があります。

• A parameter identifying the recipient's key SHOULD be present. A parameter identifying the sender's key SHOULD be present.

• 受信者のキーを識別するパラメーターは、存在するべきです（SHOULD）。送信者のキーを識別するパラメーターは、存在するべきです（SHOULD）。

13.1. Elliptic Curve Keys

13.1. 楕円曲線鍵

Two different key structures are defined for elliptic curve keys. One version uses both an x-coordinate and a y-coordinate, potentially with point compression ('EC2'). This is the traditional EC point representation that is used in [RFC5480]. The other version uses only the x-coordinate as the y-coordinate is either to be recomputed or not needed for the key agreement operation ('OKP').

Applications MUST check that the curve and the key type are consistent and reject a key if they are not.

アプリケーションは、曲線と鍵の種類が一致しているかどうかを確認し、一致していない場合は鍵を拒否するしなければなりません（MUST）。

13.2. Octet Key Pair

13.2. オクテットキーペア

A new key type is defined for Octet Key Pairs (OKP). Do not assume that keys using this type are elliptic curves. This key type could be used for other curve types (for example, mathematics based on hyper-elliptic surfaces).

新しい鍵タイプがOctet Key Pairs (OKP)のために定義されています。このタイプの鍵が楕円曲線であるとは限りませんので、そのように想定しないでください。この鍵タイプは他の曲線タイプ（例えば、超楕円曲面に基づく数学）にも使用される可能性があります。

The key parameters defined in this section are summarized in Table 24. The members that are defined for this key type are:

このセクションで定義された主なパラメーターは、表24にまとめられています。このキータイプに定義されたメンバーは以下の通りです：

crv: This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 22. Other curves may be registered in the future and private curves can be used as well.

crv: キーと一緒に使用される曲線の識別子を含んでいます。このキータイプに対してこのドキュメントで定義された曲線は、テーブル22にあります。将来的に他の曲線が登録されることがあり、また、プライベートな曲線も使用できます。

x: This contains the x-coordinate for the EC point. The octet string represents a little-endian encoding of x.

x：このフィールドは、ECポイントのx座標を含みます。オクテット文字列は、xのリトルエンディアンエンコーディングを表します。

d: This contains the private key.

d: これにはプライベートキーが含まれています。

For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space.

公開鍵については、構造内に「crv」と「x」が存在することが「要求されています（REQUIRED）」。秘密鍵については、構造内に「crv」と「d」が存在することが「要求されています（REQUIRED）」。秘密鍵については、「x」も存在することが「推奨されます（RECOMMENDED）」が、必要な要素から再計算することができるため、省略するとスペースを節約できます。

13.3. Symmetric Keys

13.3. 対称鍵

Occasionally it is required that a symmetric key be transported between entities. This key structure allows for that to happen.

時折、エンティティ間で対称キーを転送する必要があります。このキー構造はその要件を満たすことができます。

For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The member that is defined for this key type is:

対称キーの場合、'kty'メンバーは4（'Symmetric'）に設定されます。このキータイプには定義されているメンバーはありません。

k: This contains the value of the key.

k: これにはキーの値が含まれています。

This key structure does not have a form that contains only public members. As it is expected that this key structure is going to be transmitted, care must be taken that it is never transmitted accidentally or insecurely. For symmetric keys, it is REQUIRED that 'k' be present in the structure.

このキー構造には、公開メンバーのみを含む形式はありません。このキー構造が送信されることが予想されるため、誤ってまたは安全ではない状態で送信されないように注意する必要があります。対称キーの場合、構造内に 'k' が存在することが要求されています（REQUIRED）。