[要約] RFC 9053は、CBOR Object Signing and Encryption (COSE)に関する文書で、初期のアルゴリズムセットを定義しています。この文書の目的は、デジタル署名、メッセージ認証コード（MAC）、およびデータの暗号化に使用されるアルゴリズムの標準セットを提供することです。これらのアルゴリズムは、IoTデバイスや軽量アプリケーションなど、リソースが限られた環境でのセキュリティ保護に特に有用です。関連するRFCには、COSEの使用を定義するRFC 8152や、さらなるアルゴリズムや拡張機能を追加する後続のRFCが含まれます。RFC 9053は、セキュアな通信を実現するための基礎的なアルゴリズムを提供し、COSEの実装と普及を促進します。
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 9053 August Cellars
Obsoletes: 8152 August 2022
Category: Informational
ISSN: 2070-1721
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).
Concise Binary Object Representation (CBOR) は、小さなコードサイズと小さなメッセージサイズを目指して設計されたデータ形式です。このデータ形式に基本的なセキュリティサービスを定義できる必要があります。この文書は、CBOR Object Signing and Encryption (COSE) プロトコル（RFC 9052）で使用できるアルゴリズムのセットを定義します。
This document, along with RFC 9052, obsoletes RFC 8152.
この文書は、RFC 9052とともにRFC 8152を廃止します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準トラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はInternet Engineering Task Force（IETF）の製品です。IETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group（IESG）による出版承認を受けています。IESGによって承認されたすべての文書がインターネット標準のいずれかの候補となるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9053.
この文書の現在の状況、誤植、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc9053 で入手できます。
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書の著者として特定された人々。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関するIETF信託の法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書を注意深く確認してください。これらは、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、信託法的規定のセクション4.eに記載されているように改訂されたBSDライセンステキストを含める必要があり、改訂されたBSDライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Terminology
1.2. Changes from RFC 8152
1.3. Document Terminology
1.4. CDDL Grammar for CBOR Data Structures
1.5. Examples
2. Signature Algorithms
2.1. ECDSA
2.1.1. Security Considerations for ECDSA
2.2. Edwards-Curve Digital Signature Algorithm (EdDSA)
2.2.1. Security Considerations for EdDSA
3. Message Authentication Code (MAC) Algorithms
3.1. Hash-Based Message Authentication Codes (HMACs)
3.1.1. Security Considerations for HMAC
3.2. AES Message Authentication Code (AES-CBC-MAC)
3.2.1. Security Considerations for AES-CBC-MAC
4. Content Encryption Algorithms
4.1. AES-GCM
4.1.1. Security Considerations for AES-GCM
4.2. AES-CCM
4.2.1. Security Considerations for AES-CCM
4.3. ChaCha20 and Poly1305
4.3.1. Security Considerations for ChaCha20/Poly1305
5. Key Derivation Functions (KDFs)
5.1. HMAC-Based Extract-and-Expand Key Derivation Function
(HKDF)
5.2. Context Information Structure
6. Content Key Distribution Methods
6.1. Direct Encryption
6.1.1. Direct Key
6.1.2. Direct Key with KDF
6.2. Key Wrap
6.2.1. AES Key Wrap
6.3. Direct Key Agreement
6.3.1. Direct ECDH
6.4. Key Agreement with Key Wrap
6.4.1. ECDH with Key Wrap
7. Key Object Parameters
7.1. Elliptic Curve Keys
7.1.1. Double Coordinate Curves
7.2. Octet Key Pair
7.3. Symmetric Keys
8. COSE Capabilities
8.1. Assignments for Existing Algorithms
8.2. Assignments for Existing Key Types
8.3. Examples
9. CBOR Encoding Restrictions
10. IANA Considerations
10.1. Changes to the "COSE Key Types" Registry
10.2. Changes to the "COSE Algorithms" Registry
10.3. Changes to the "COSE Key Type Parameters" Registry
10.4. Expert Review Instructions
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgments
Author's Address
There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). One of the standards that has come out of this process is "Concise Binary Object Representation (CBOR)" [STD94]. CBOR extended the data model of JavaScript Object Notation (JSON) [STD90] by allowing for binary data, among other changes. CBOR has been adopted by several of the IETF working groups dealing with the IoT world as their method of encoding data structures. CBOR was designed specifically to be small in terms of both messages transported and implementation size and to have a schema-free decoder. A need exists to provide message security services for IoT, and using CBOR as the message-encoding format makes sense.
このプロセスから生まれた標準の1つが「Concise Binary Object Representation (CBOR)」です。CBORは、JSONのデータモデルを拡張し、バイナリデータを含むことができるようになりました。CBORは、いくつかのIETFワーキンググループによって採用され、メッセージの輸送量や実装サイズが小さく、スキーマフリーのデコーダーを持つように設計されています。IoT向けのメッセージセキュリティサービスを提供する必要があり、CBORをメッセージエンコーディング形式として使用することは理にかなっています。
The core COSE specification consists of two documents. [RFC9052] contains the serialization structures and the procedures for using the different cryptographic algorithms. This document provides an initial set of algorithms for use with those structures.
COSE仕様の中核は2つの文書で構成されています。[RFC9052]にはシリアル化構造と異なる暗号アルゴリズムを使用する手順が含まれています。この文書は、これらの構造と使用するための初期のアルゴリズムセットを提供します。
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] で説明されているように解釈されるべきです。
* Extracted the sections dealing with specific algorithms and placed them into this document. The sections dealing with structure and general processing rules are placed in [RFC9052].
* 特定のアルゴリズムに関するセクションを抽出し、このドキュメントに配置しました。構造と一般的な処理ルールに関するセクションは[RFC9052]に配置されています。
* Made text clarifications and changes in terminology.
* 用語の説明と変更を行いました。
* Removed all of the details relating to countersignatures and placed them in [COUNTERSIGN].
* カウンターサインに関連するすべての詳細を削除し、[COUNTERSIGN]に配置しました。
In this document, we use the following terminology:
この文書では、以下の用語を使用しています。
Byte:
バイト
A synonym for octet.
8つ組
Constrained Application Protocol (CoAP):
Constrained Application Protocol (CoAP):
A specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252].
[RFC7252] で定義された制約のあるシステムで使用するための専用のWeb転送プロトコル。
Authenticated Encryption (AE) algorithms [RFC5116]:
認証付き暗号（AE）アルゴリズム[RFC5116]:
Encryption algorithms that provide an authentication check of the contents along with the encryption service. An example of an AE algorithm used in COSE is AES Key Wrap [RFC3394]. These algorithms are used for key encryption, but Authenticated Encryption with Associated Data (AEAD) algorithms would be preferred.
コンテンツと一緒に認証チェックを提供する暗号化アルゴリズム。COSEで使用されるAEアルゴリズムの例はAES Key Wrap [RFC3394]です。これらのアルゴリズムは鍵の暗号化に使用されますが、関連データを持つ認証付き暗号化（AEAD）アルゴリズムが好ましいです。
AEAD algorithms [RFC5116]:
AEADアルゴリズム[RFC5116]:
Encryption algorithms that provide the same authentication service of the content as AE algorithms do, and also allow associated data that is not part of the encrypted body to be included in the authentication service. An example of an AEAD algorithm used in COSE is AES-GCM [RFC5116]. These algorithms are used for content encryption and can be used for key encryption as well.
AEアルゴリズムと同じ認証サービスを提供し、暗号化された本文の一部ではない関連データを認証サービスに含めることができる暗号化アルゴリズム。COSEで使用されるAEADアルゴリズムの例としては、AES-GCM [RFC5116] があります。これらのアルゴリズムはコンテンツの暗号化に使用され、キーの暗号化にも使用できます。
The term "byte string" is used for sequences of bytes, while the term "text string" is used for sequences of characters.
「バイト列」という用語はバイトの連続を指し、「テキスト列」という用語は文字の連続を指します。
The tables for algorithms contain the following columns:
アルゴリズムのテーブルには、次の列が含まれています：
* A name for the algorithm for use in documents.
* 文書で使用するアルゴリズムの名前。
* The value used on the wire for the algorithm. One place this is used is the algorithm header parameter of a message.
* アルゴリズムで使用されるワイヤー上の値。これが使用される場所の1つは、メッセージのアルゴリズムヘッダーパラメータです。
* A short description so that the algorithm can be easily identified when scanning the IANA registry.
* IANAレジストリをスキャンする際にアルゴリズムを簡単に特定できるようにするための簡単な説明。
Additional columns may be present in a table depending on the algorithms.
アルゴリズムによっては、テーブルに追加の列が存在する場合があります。
When COSE was originally written, the Concise Data Definition Language (CDDL) [RFC8610] had not yet been published in an RFC, so it could not be used as the data description language to normatively describe the CBOR data structures employed by COSE. For that reason, the CBOR data objects defined here are described in prose. Additional (non-normative) descriptions of the COSE data objects are provided in a subset of CDDL, described in [RFC9052].
COSEが最初に書かれたとき、Concise Data Definition Language（CDDL）[RFC8610]がまだRFCで公開されていなかったため、COSEで使用されるCBORデータ構造を規範的に記述するためのデータ記述言語として使用することはできませんでした。そのため、ここで定義されたCBORデータオブジェクトは文章で説明されています。COSEデータオブジェクトの追加（非規範的な）説明は、[RFC9052]で説明されているCDDLのサブセットで提供されています。
A GitHub project has been created at [GitHub-Examples] that contains a set of testing examples. Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used for debugging, and the output of the example. The results are encoded using both hexadecimal and CBOR diagnostic notation format.
[GitHub-Examples]でGitHubプロジェクトが作成され、テスト例が含まれています。各例は、例を作成するために使用される入力、デバッグに使用できるいくつかの中間値、および例の出力が含まれるJSONファイルに見つかります。結果は16進数とCBOR診断表記形式の両方を使用してエンコードされています。
Some of the examples are designed to be failure-testing cases; these are clearly marked as such in the JSON file.
いくつかの例は失敗テストケースを想定して設計されています。これらはJSONファイルで明示的にそのようにマークされています。
Section 8.1 of [RFC9052] contains a generic description of signature algorithms. This document defines signature algorithm identifiers for two signature algorithms.
[RFC9052]のセクション8.1には、署名アルゴリズムの一般的な説明が含まれています。この文書は、2つの署名アルゴリズムのための署名アルゴリズム識別子を定義しています。
The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] defines a signature algorithm using Elliptic Curve Cryptography (ECC). Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithm allows 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 lead to leaked keys. It additionally allows performing 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）[DSS]は、楕円曲線暗号（ECC）を使用した署名アルゴリズムを定義します。実装は[RFC6979]で定義されているようなECDSAの決定論的バージョンを使用するべきです。決定論的署名アルゴリズムの使用により、システムはランダム数生成器に依存せずに"k"（メッセージごとのランダム値）の同じ値を生成することを避けることができます。値"k"のバイアス生成は攻撃され、この値の衝突は鍵の漏洩につながります。さらに、署名アルゴリズムの決定論的テストを実行することができます。決定論的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 1.
この文書で定義されたアルゴリズムは、表1に記載されています。
+=======+=======+=========+==================+
| Name | Value | Hash | Description |
+=======+=======+=========+==================+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
+-------+-------+---------+------------------+
| ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 |
+-------+-------+---------+------------------+
| ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+
Table 1: ECDSA Algorithm Values
表1：ECDSAアルゴリズムの値
This document defines ECDSA as working only with the curves P-256, P-384, and P-521. This document requires that the curves be encoded using the "EC2" (two coordinate elliptic curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Future documents may define it to work with other curves and key types 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 only 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]のセクション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:
[RFC8017] で定義された関数を使用すると、署名は次のようになります。
Signature = I2OSP(R, n) | I2OSP(S, n)
Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8)
n = ceiling(key_length / 8) となります。
When using a COSE key for this algorithm, the following checks are made:
このアルゴリズムでCOSEキーを使用する場合、次のチェックが行われます：
* The "kty" field MUST be present, and it MUST be "EC2".
* "kty"フィールドは必ず存在し、"EC2"である必要があります。
* If the "alg" field is present, it MUST match the ECDSA signature algorithm being used.
* "alg" フィールドが存在する場合、使用されている ECDSA 署名アルゴリズムと一致している必要があります。
* If the "key_ops" field is present, it MUST include "sign" when creating an ECDSA signature.
* "key_ops" フィールドが存在する場合、ECDSA 署名を作成する際には、"sign" を含める必要があります。
* If the "key_ops" field is present, it MUST include "verify" when verifying an ECDSA signature.
* もし「key_ops」フィールドが存在する場合、ECDSA署名を検証する際には「verify」を含めなければなりません。
The security strength of the signature is no greater than the minimum of the security strength associated with the bit length of the key and the security strength of the hash function.
署名のセキュリティ強度は、鍵のビット長に関連付けられたセキュリティ強度とハッシュ関数のセキュリティ強度の最小値以下です。
Note: Use of a deterministic signature technique is a good idea even when good random number generation exists. Doing so both reduces the possibility of having the same value of "k" in two signature operations and allows for reproducible signature values, which helps testing. There have been recent attacks involving faulting the device in order to extract the key. This can be addressed by combining both randomness and determinism [CFRG-DET-SIGS].
注意：良好な乱数生成が存在する場合でも、確定的署名技術の使用は良い考えです。これにより、2つの署名操作で同じ「k」の値を持つ可能性が低くなり、テストを支援する再現可能な署名値が可能になります。最近、デバイスを故障させて鍵を抽出する攻撃が発生しています。これはランダム性と決定論を組み合わせることで対処できます。
There are two substitution attacks that can theoretically be mounted against the ECDSA signature algorithm.
ECDSA署名アルゴリズムに対して理論的に実行可能な2つの置換攻撃があります。
* Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have two messages with the same signature, each computed under a different curve. The only requirements on the new curve are that its order be the same as the old one and that it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit curves.) We currently do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used.
* 署名を検証するために使用される曲線を変更すると、同じ署名を持つ2つのメッセージが可能になるかもしれません。新しい曲線には、古い曲線と同じ次数であり、クライアントに受け入れられる必要があります。例えば、曲線secp256r1（別名P-256）からsecp256k1を使用するように変更することが考えられます（どちらも256ビットの曲線です）。現在、この攻撃のバージョンに対処する方法は、使用できる曲線の全体セットを制限する以外にありません。
* Changing the hash function used to validate the signature: If one either has two different hash functions of the same length or can truncate a hash function, then one could potentially find collisions between the hash functions rather than within a single hash function. For example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value. As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including a signature algorithm identifier in the protected-header bucket.
* 署名を検証するために使用されるハッシュ関数を変更する場合：同じ長さの2つの異なるハッシュ関数を持っているか、ハッシュ関数を切り捨てることができる場合、1つのハッシュ関数内ではなく、ハッシュ関数間で衝突を見つける可能性があります。たとえば、SHA-512を256ビットに切り捨てると、SHA-256ビットハッシュ値と衝突する可能性があります。ハッシュアルゴリズムは署名アルゴリズム識別子の一部であるため、この攻撃は保護ヘッダーバケットに署名アルゴリズム識別子を含めることで緩和されます。
[RFC8032] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for the 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 prehash 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. Therefore, 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つのバリアントについても説明があります：純粋なEdDSAでは、署名前にコンテンツにハッシュ関数が適用されず、HashEdDSAでは、署名前にコンテンツにハッシュ関数が適用され、そのハッシュ関数の結果が署名されます。EdDSAでは、署名アルゴリズム内で署名されるコンテンツ（メッセージまたは事前ハッシュ値）が2回処理されます。COSEとの使用では、純粋なEdDSAバージョンのみが使用されます。これは、非常に大きなコンテンツが必要とされることはないと予想され、メッセージ構造の配置に基づいて、署名を作成または検証するためにメモリにメッセージ全体を保持する必要があるためです。したがって、ハッシュのブロック更新を行い、その後メッセージをメモリから削除する必要があるという必要性は見られません。アプリケーションは、メッセージの内容をハッシュ値として定義し、COSEオブジェクト（ハッシュ値を含む）とコンテンツを別々のアイテムとして輸送することで同じ機能を提供できます。
The algorithm defined in this document can be found in Table 2. A single signature algorithm is defined, which can be used for multiple curves.
この文書で定義されたアルゴリズムは、表2に見つけることができます。1つの署名アルゴリズムが定義されており、複数の曲線に使用することができます。
+=======+=======+=============+
| Name | Value | Description |
+=======+=======+=============+
| EdDSA | -8 | EdDSA |
+-------+-------+-------------+
Table 2: EdDSA Algorithm Value
表2: EdDSAアルゴリズムの値
[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"（Octet Key Pair）である必要があります。
* 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" と一致する必要があります。
* If the "key_ops" field is present, it MUST include "sign" when creating an EdDSA signature.
* "key_ops" フィールドが存在する場合、EdDSA 署名を作成する際には "sign" を含める必要があります。
* If the "key_ops" field is present, it MUST include "verify" when verifying an EdDSA signature.
* "key_ops" フィールドが存在する場合、EdDSA 署名を検証する際には、"verify" を含める必要があります。
Public values are computed differently in EdDSA and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public key from one should not be used with the other algorithm.
EdDSAと楕円曲線Diffie-Hellman（ECDH）では、公開値が異なる方法で計算されるため、片方の公開鍵を他方のアルゴリズムで使用すべきではありません。
If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED (Section 8.2 of [RFC8032]). Signing and nonbatch signature verification are deterministic operations and do not need random numbers of any kind.
バッチ署名検証が行われる場合、適切にシードされた暗号論的乱数生成器が必要です（[RFC8032]のセクション8.2）。署名と非バッチ署名検証は決定論的な操作であり、どんな種類の乱数も必要ありません。
Section 8.2 of [RFC9052] contains a generic description of MAC algorithms. This section defines the conventions for two MAC algorithms.
[RFC9052]のセクション8.2には、MACアルゴリズムの一般的な説明が含まれています。このセクションでは、2つのMACアルゴリズムの規則が定義されています。
HMAC [RFC2104] [RFC4231] was designed to deal with length extension attacks. The HMAC algorithm was also designed to allow new hash functions to be directly plugged in without changes to the hash function. The HMAC design process has been shown to be solid; although the security of hash functions 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 アルゴリズムは、新しいハッシュ関数を変更せずに直接接続できるように設計されています。HMAC の設計プロセスは堅実であることが示されています。MD5 などのハッシュ関数のセキュリティは時間とともに低下していますが、MD5 と組み合わせた HMAC のセキュリティはまだ compromised されていないことが示されています [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 one HMAC algorithm that is truncated. 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.
HMACアルゴリズムは、内部および外部のパディング、ハッシュ関数（h）、および認証タグの値の長さによってパラメータ化されます。この仕様では、内部および外部のパディングは[RFC2104]で設定された値に固定されています。認証タグの長さは、偽造を生成する難しさに対応しています。制約のある環境で使用するために、切り捨てられた1つのHMACアルゴリズムを定義します。現在、切り捨てに関する既知の問題はありませんが、メッセージタグのセキュリティ強度が対応して低下します。切り捨てる場合、左端のタグ長のビットが保持されて送信されます。
The algorithms defined in this document can be found in Table 3.
この文書で定義されたアルゴリズムは、表3に記載されています。
+=============+=======+=========+============+======================+
| Name | Value | Hash | Tag Length | Description |
+=============+=======+=========+============+======================+
| HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 |
| 256/64 | | | | truncated to 64 bits |
+-------------+-------+---------+------------+----------------------+
| HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 |
| 256/256 | | | | |
+-------------+-------+---------+------------+----------------------+
| HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 |
| 384/384 | | | | |
+-------------+-------+---------+------------+----------------------+
| HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 |
| 512/512 | | | | |
+-------------+-------+---------+------------+----------------------+
Table 3: HMAC Algorithm Values
表3: HMACアルゴリズムの値
Some recipient algorithms transport the key, while others derive a key from secret data. For those algorithms that transport the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the output of the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the output of the underlying hash function.
一部の受信者アルゴリズムは鍵を輸送し、他のものは秘密データから鍵を導出します。鍵を輸送するアルゴリズム（AES Key Wrapなど）の場合、HMAC鍵のサイズは基礎となるハッシュ関数の出力と同じサイズであるべきです。鍵を導出するアルゴリズム（ECDHなど）の場合、導出された鍵は基礎となるハッシュ関数の出力と同じサイズでなければなりません。
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 HMAC algorithm being used.
* もし"alg"フィールドが存在する場合、それは使用されているHMACアルゴリズムと一致しなければなりません。
* If the "key_ops" field is present, it MUST include "MAC create" when creating an HMAC authentication tag.
* もし「key_ops」フィールドが存在する場合、HMAC 認証タグを作成する際には「MAC create」を含める必要があります。
* If the "key_ops" field is present, it MUST include "MAC verify" when verifying an HMAC authentication tag.
* もし「key_ops」フィールドが存在する場合、HMAC 認証タグを検証する際には「MAC verify」を含めなければなりません。
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値を作成および検証する実装は、関係するエンティティに適切であることを確認する必要があります。
HMAC has proved to be resistant to attack even when used with weakened hash algorithms. The current best known attack is to brute force the key. This means that key size is going to be directly related to the security of an HMAC operation.
HMACは、弱体化されたハッシュアルゴリズムと組み合わせて使用されていても攻撃に耐えることが証明されています。現在知られている最良の攻撃方法は、鍵を総当たりで探すことです。これは、鍵のサイズがHMAC操作のセキュリティに直接関係してくることを意味します。
AES-CBC-MAC is the instantiation of the CBC-MAC construction (defined in [MAC]) using AES as the block cipher. For brevity, we also use "AES-MAC" to refer to AES-CBC-MAC. (Note that this is not the same algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) [RFC4493].)
AES-CBC-MACは、AESをブロック暗号として使用するCBC-MAC構築の具体化です。簡潔にするため、私たちはAES-CBC-MACを指す際に「AES-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 Initialization Vector (IV) used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key and tag lengths. The algorithms defined in this document are found in Table 4.
AES-CBC-MACは、鍵長、認証タグ長、および使用される初期化ベクトル（IV）によってパラメータ化されます。これらのアルゴリズムすべてにおいて、IVはすべてゼロに固定されています。さまざまな鍵長とタグ長のアルゴリズムの配列を提供します。この文書で定義されているアルゴリズムは、表4にあります。
+=========+=======+============+============+==================+
| Name | Value | Key Length | Tag Length | Description |
+=========+=======+============+============+==================+
| AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit |
| 128/64 | | | | key, 64-bit tag |
+---------+-------+------------+------------+------------------+
| AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit |
| 256/64 | | | | key, 64-bit tag |
+---------+-------+------------+------------+------------------+
| AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit |
| 128/128 | | | | key, 128-bit tag |
+---------+-------+------------+------------+------------------+
| AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit |
| 256/128 | | | | key, 128-bit tag |
+---------+-------+------------+------------+------------------+
Table 4: AES-MAC Algorithm Values
表4：AES-MACアルゴリズムの値
Keys may be obtained from either a key structure or 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値を作成および検証する実装は、キーの種類、キーの長さ、およびアルゴリズムが正確で適切であることを検証する必要があります。
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アルゴリズムと一致しなければなりません。
* If the "key_ops" field is present, it MUST include "MAC create" when creating an AES-MAC authentication tag.
* もし「key_ops」フィールドが存在する場合、AES-MAC認証タグを作成する際には「MAC create」を含める必要があります。
* 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」を含めなければなりません。
A number of attacks exist against Cipher Block Chaining Message Authentication Code (CBC-MAC) that need to be considered.
Cipher Block Chaining Message Authentication Code（CBC-MAC）に対する攻撃手法がいくつか存在し、考慮する必要があります。
* A single key must only be used for messages of a fixed or known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for messages of different lengths. The current structure mitigates this problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.)
* 単一のキーは、固定または既知の長さのメッセージにのみ使用する必要があります。そうでない場合、攻撃者は、2つのメッセージとタグのペアが与えられた場合に有効なタグを持つメッセージを生成できます。これは、異なる長さのメッセージに対して異なるキーを使用することで対処できます。現在の構造は、特定の長さを含むエンコーディング構造が構築され、署名されるため、この問題を軽減します。（CMACもこの問題に対処します。）
* In Cipher Block Chaining (CBC) mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code.
* Cipher Block Chaining（CBC）モードでは、同じキーが暗号化と認証操作の両方に使用される場合、攻撃者は有効な認証コードを持つメッセージを生成できます。
* If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros.
* IV が変更可能な場合、メッセージを偽造することができます。これは IV をすべてゼロに固定することで解決されます。
Section 8.3 of [RFC9052] contains a generic description of content encryption algorithms. This document defines the identifier and usages for three content encryption algorithms.
[RFC9052]のセクション8.3には、コンテンツ暗号化アルゴリズムの一般的な説明が含まれています。この文書は、3つのコンテンツ暗号化アルゴリズムの識別子と使用法を定義しています。
The Galois/Counter Mode (GCM) mode is a generic AEAD 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]で定義された一般的なAEADブロック暗号モードです。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 is in Table 5.
この文書で定義されたアルゴリズムのセットは、表5にあります。
+=========+=======+==========================================+
| Name | Value | Description |
+=========+=======+==========================================+
| A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag |
+---------+-------+------------------------------------------+
| A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag |
+---------+-------+------------------------------------------+
| A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag |
+---------+-------+------------------------------------------+
Table 5: Algorithm Values for AES-GCM
表5：AES-GCMのアルゴリズム値
Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
キーは、キー構造または受信者構造から取得できます。暗号化または復号を行う実装は、キーの種類、長さ、およびアルゴリズムが正しいかつ関連するエンティティに適していることを検証する必要があります。
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-GCM algorithm being used.
* もし「alg」フィールドが存在する場合、それは使用されているAES-GCMアルゴリズムと一致しなければなりません。
* 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" を含める必要があります。
When using AES-GCM, the following restrictions MUST be enforced:
AES-GCMを使用する際は、次の制限を必ず遵守する必要があります。
* The key and nonce pair MUST be unique for every message encrypted.
* メッセージごとに、鍵とナンスのペアは一意である必要があります。
* The total number of messages encrypted for a single key MUST NOT exceed 2^32 [SP800-38D]. An explicit check is required only in environments where it is expected that this limit might be exceeded.
* 単一のキーで暗号化されたメッセージの総数は、2^32を超えてはなりません[SP800-38D]。この制限を超える可能性がある環境では、明示的なチェックが必要です。
* [RFC8446] contains an analysis on the use of AES-CGM for its environment. Based on that recommendation, one should restrict the number of messages encrypted to 2^24.5.
* [RFC8446]には、その環境でAES-CGMを使用する際の分析が含まれています。その推奨に基づいて、暗号化されるメッセージの数を2^24.5に制限する必要があります。
* A more recent analysis in [ROBUST] indicates that the number of failed decryptions needs to be taken into account as part of determining when a key rollover is to be done. Following the recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of failed message decryptions should be limited to 2^36.
* [ROBUST]におけるより最近の分析では、鍵の切り替えが行われるタイミングの一部として、失敗した復号化の回数を考慮する必要があることが示されています。DTLSの推奨事項（[RFC9147]のセクション4.5.3）に従い、失敗したメッセージの復号化回数は2^36に制限されるべきです。
Consideration was given to supporting smaller tag values; the constrained community would desire tag sizes in the 64-bit range. Such use drastically changes both the maximum message size (generally not an issue) and the number of times that a key can be used. Given that Counter with CBC-MAC (CCM) is the usual mode for constrained environments, restricted modes are not supported.
制約のあるコミュニティは、64ビットの範囲内でのタグサイズのサポートを希望しています。このような使用は、通常は問題にならない最大メッセージサイズと、キーを使用できる回数を大幅に変更します。制約のある環境では、Counter with CBC-MAC（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 an AEAD cipher that is commonly used in constrained devices.
CCMは[RFC3610]で定義された一般的な認証暗号化ブロック暗号モードです。CCMモードはAESブロック暗号アルゴリズムと組み合わせて、制約のあるデバイスで一般的に使用されるAEAD暗号を定義します。
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で、長さフィールドのサイズです。この値は、最大メッセージサイズとナンスのサイズとの間のトレードオフが必要です。
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. In most cryptographic algorithm specifications, 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が認証のサイズが8ビットではなく64ビットであるCCMモードのバージョンを指すことがよくあります。ほとんどの暗号アルゴリズムの仕様では、これらの値は従来、バイト数ではなくビット数として指定されてきました。この文書では、異なるアルゴリズムを比較しやすくするために、ビット数を使用する慣習に従います。
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):
16 ビット（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^104 possible values of the nonce without repeating.
このメッセージの長さは2^16バイト（64 KiB）に制限されています。これは制約のある世界のメッセージには十分に長いです。ノンスの長さは13バイトで、繰り返すことなく2^104通りの可能な値を持つことができます。
64 bits (8):
64 ビット（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.
このメッセージの長さは2^64バイトに制限されています。ノンスの長さは7バイトで、ノンスの値は2^56通りありますが、繰り返しはありません。
The following values are used for M:
次の値はMに使用されます。
64 bits (8):
64 ビット（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ビットの認証タグが生成されます。これは、変更されたメッセージが認証される可能性が2^64分の1であることを意味します。
128 bits (16):
128 ビット（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ビットの認証タグが生成されます。これは、修正されたメッセージが認証される可能性が2^128分の1であることを意味します。
+====================+=======+====+=====+========+===============+
| Name | Value | L | M | Key | Description |
| | | | | Length | |
+====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 64-bit tag, |
| | | | | | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 64-bit tag, |
| | | | | | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 64-bit tag, |
| | | | | | 7-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 64-bit tag, |
| | | | | | 7-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 7-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 7-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
Table 6: Algorithm Values for AES-CCM
表6：AES-CCMのアルゴリズム値
Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
キーは、キー構造または受信者構造から取得できます。暗号化または復号を行う実装は、キーの種類、キーの長さ、およびアルゴリズムが正しいかつ関連するエンティティに適していることを検証する必要があります。
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-CCM algorithm being used.
* もし "alg" フィールドが存在する場合、それは使用されているAES-CCMアルゴリズムと一致しなければなりません。
* 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" を含める必要があります。
When using AES-CCM, the following restrictions MUST be enforced:
AES-CCMを使用する際は、次の制限を必ず遵守する必要があります。
* The key and nonce pair MUST be unique for every message encrypted. Note that the value of L influences the number of unique nonces.
* キーとナンスのペアは、暗号化されるメッセージごとにユニークである必要があります。Lの値がユニークなナンスの数に影響を与えることに注意してください。
* The total number of times the AES block cipher is used MUST NOT exceed 2^61 operations. This limit is the sum of times the block cipher is used in computing the MAC value and performing stream encryption operations. An explicit check is required only in environments where it is expected that this limit might be exceeded.
* AESブロック暗号が使用される回数の合計は、2^61回を超えてはなりません。この制限は、MAC値を計算する際やストリーム暗号化操作を実行する際にブロック暗号が使用される回数の合計です。この制限を超える可能性がある環境では、明示的なチェックが必要です。
* [RFC9147] contains an analysis on the use of AES-CCM for its environment. Based on that recommendation, one should restrict the number of messages encrypted to 2^23.
* [RFC9147]には、その環境でAES-CCMを使用する際の分析が含まれています。その推奨に基づいて、暗号化されるメッセージの数を2^23に制限する必要があります。
* In addition to the number of messages successfully decrypted, the number of failed decryptions needs to be tracked as well. Following the recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of failed message decryptions should be limited to 2^23.5. If one is using the 64-bit tag, then the limits are significantly smaller if one wants to keep the same integrity limits. A protocol recommending this needs to analyze what level of integrity is acceptable for the smaller tag size. It may be that, to keep the desired level of integrity, one needs to rekey as often as every 2^7 messages.
* メッセージの復号に成功した数に加えて、失敗した復号の数も追跡する必要があります。DTLSの推奨に従うと、失敗したメッセージの復号の数は2^23.5に制限されるべきです。64ビットのタグを使用している場合、同じ整合性の制限を保持したい場合、制限はかなり小さくなります。このようなプロトコルを推奨する場合、より小さなタグサイズに対して許容できる整合性のレベルを分析する必要があります。望ましい整合性のレベルを維持するためには、2^7メッセージごとに再鍵を行う必要があるかもしれません。
[RFC3610] additionally calls out one other consideration of note. It is possible to do a precomputation attack against the algorithm in cases where portions of the plaintext are highly predictable. This reduces the security of the key size by half. Ways to deal with this attack include adding a random portion to the nonce value and/or increasing the key size used. Using a portion of the nonce for a random value will decrease the number of messages that a single key can be used for. Increasing the key size may require more resources in the constrained device. See Sections 5 and 10 of [RFC3610] for more information.
[RFC3610]には、注意すべきもう1つの考慮事項があります。平文の一部が非常に予測可能な場合、アルゴリズムに対する事前計算攻撃が可能です。これにより、鍵サイズのセキュリティが半分になります。この攻撃に対処する方法には、ノンス値にランダムな部分を追加することや、使用する鍵サイズを増やすことが含まれます。ノンスの一部をランダムな値に使用すると、単一の鍵で使用できるメッセージの数が減少します。鍵サイズを増やすと、制約のあるデバイスでより多くのリソースが必要になる場合があります。詳細については、[RFC3610]のセクション5と10を参照してください。
ChaCha20 and Poly1305 combined together is an AEAD mode that is defined in [RFC8439]. This is an algorithm defined using 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を組み合わせたものは、[RFC8439]で定義されているAEADモードです。これはAESではない暗号を使用して定義されたアルゴリズムであり、したがってAESで見つかった将来の弱点には影響されません。これらの暗号関数は、ソフトウェアのみで高速に動作するように設計されています。
The ChaCha20/Poly1305 AEAD construction defined in [RFC8439] has no parameterization. It takes as inputs a 256-bit key and a 96-bit nonce, as well as the plaintext and additional data, and produces the ciphertext as an output. We define one algorithm identifier for this algorithm in Table 7.
[RFC8439] で定義されている ChaCha20/Poly1305 AEAD 構築にはパラメータ化がありません。入力として 256 ビットの鍵と 96 ビットのナンス、さらに平文と追加データを取り、暗号文を出力します。このアルゴリズムについては、表 7 で 1 つのアルゴリズム識別子を定義します。
+===================+=======+==========================+
| Name | Value | Description |
+===================+=======+==========================+
| ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ |
| | | 256-bit key, 128-bit tag |
+-------------------+-------+--------------------------+
Table 7: Algorithm Value for ChaCha20/Poly1305
表7: ChaCha20/Poly1305のアルゴリズム値
Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
キーは、キー構造または受信者構造から取得できます。暗号化または復号を行う実装は、キーの種類、キーの長さ、およびアルゴリズムが正しいかつ関連するエンティティに適していることを検証する必要があります。
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 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" または "unwrap key" を含める必要があります。
The key and nonce values MUST be a unique pair for every invocation of the algorithm. Nonce counters are considered to be an acceptable way of ensuring that they are unique.
鍵とナンスの値は、アルゴリズムの各呼び出しに対してユニークなペアでなければなりません。ナンスカウンターは、それらがユニークであることを確実にするための受け入れられる方法と見なされます。
A more recent analysis in [ROBUST] indicates that the number of failed decryptions needs to be taken into account as part of determining when a key rollover is to be done. Following the recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of failed message decryptions should be limited to 2^36.
[ROBUST]におけるより最近の分析では、鍵の切り替えが行われるタイミングの一部として、失敗した復号化の回数を考慮する必要があることが示されています。DTLSの推奨に従い（[RFC9147]のセクション4.5.3）、失敗したメッセージの復号回数は2^36に制限されるべきです。
[RFC8446] notes that the (64-bit) record sequence number would wrap before the safety limit is reached for ChaCha20/Poly1305. COSE implementations should not send more than 2^64 messages encrypted using a single ChaCha20/Poly1305 key.
[RFC8446]は、（64ビットの）レコードシーケンス番号が、ChaCha20/Poly1305の安全限界に達する前にラップする可能性があることに言及しています。COSEの実装では、単一のChaCha20/Poly1305キーを使用して暗号化されたメッセージを2^64件以上送信すべきではありません。
Section 8.4 of [RFC9052] contains a generic description of key derivation functions. This document defines a single context structure and a single KDF. These elements are used for all of the recipient algorithms defined in this document that require a KDF process. These algorithms are defined in Sections 6.1.2, 6.3.1, and 6.4.1.
[RFC9052]のセクション8.4には、鍵導出関数の一般的な説明が含まれています。この文書では、単一のコンテキスト構造と単一のKDFが定義されています。これらの要素は、KDFプロセスが必要なこの文書で定義されている受信者アルゴリズムすべてに使用されます。これらのアルゴリズムは、セクション6.1.2、6.3.1、および6.4.1で定義されています。
The HKDF key derivation algorithm is defined in [RFC5869] and [HKDF].
HKDF鍵導出アルゴリズムは[RFC5869]および[HKDF]で定義されています。
The HKDF algorithm takes these inputs:
HKDFアルゴリズムはこれらの入力を取ります。
secret:
秘密:
A shared value that is secret. Secrets may be either previously shared or derived from operations like a Diffie-Hellman (DH) key agreement.
秘密の共有値。秘密は以前に共有されたものであっても、Diffie-Hellman（DH）鍵合意のような操作から派生している可能性があります。
salt:
塩
An optional value that is used to change the generation process. The salt value can be either public or private. If the salt is public and carried in the message, then the "salt" algorithm header parameter defined in Table 9 is used. While [RFC5869] suggests that the length of the salt be the same as the length of the underlying hash value, any positive salt length will improve the security, as different key values will be generated. This parameter is protected by being included in the key computation and does not need to be separately authenticated. The salt value does not need to be unique for every message sent.
生成プロセスを変更するために使用されるオプションの値。ソルト値は公開または非公開のいずれかにすることができます。ソルトが公開され、メッセージに含まれている場合、表9で定義されている「salt」アルゴリズムヘッダーパラメータが使用されます。[RFC5869]では、ソルトの長さは基礎となるハッシュ値の長さと同じであるべきであると示唆していますが、正のソルトの長さはセキュリティを向上させます。異なるキー値が生成されるためです。このパラメータはキー計算に含まれて保護されており、別途認証する必要はありません。ソルト値は送信されるすべてのメッセージごとに一意である必要はありません。
length:
長さ
The number of bytes of output that need to be generated.
生成する必要がある出力のバイト数。
context information:
context information:
Information that describes the context in which the resulting value will be used. Making this information specific to the context in which the material is going to be used ensures that the resulting material will always be tied to that usage. The context structure defined in Section 5.2 is used by the KDFs in this document.
結果の値が使用されるコンテキストを説明する情報。この情報を使用される素材のコンテキストに特化させることで、常にその使用に結びついた素材が得られるようになります。この文書では、セクション5.2で定義されたコンテキスト構造がKDFsによって使用されます。
PRF:
PRF:
The underlying pseudorandom function to be used in the HKDF algorithm. The PRF is encoded into the HKDF algorithm selection.
HKDFアルゴリズムで使用される基礎となる疑似乱数関数。PRFは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は、基礎としてHMACを使用するように定義されています。ただし、同じ構造で他の関数を使用して、制約のある世界に適した異なるKDFを提供することも可能です。具体的には、AES-CBC-MACをPRFとして使用して、拡張ステップには使用できますが、抽出ステップには使用できません。適切な長さの良好なランダム共有秘密を使用する場合、抽出ステップをスキップできます。AESアルゴリズムのバージョンでは、抽出ステップは常にスキップされます。
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 8.
この文書で定義されたアルゴリズムは、表8に見つかります。
+==============+===================+========================+
| Name | PRF | Description |
+==============+===================+========================+
| HKDF SHA-256 | HMAC with SHA-256 | HKDF using HMAC |
| | | SHA-256 as the PRF |
+--------------+-------------------+------------------------+
| HKDF SHA-512 | HMAC with SHA-512 | HKDF using HMAC |
| | | SHA-512 as the PRF |
+--------------+-------------------+------------------------+
| HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as |
| MAC-128 | | the PRF w/ 128-bit key |
+--------------+-------------------+------------------------+
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as |
| MAC-256 | | the PRF w/ 256-bit key |
+--------------+-------------------+------------------------+
Table 8: HKDF Algorithms
表8：HKDFアルゴリズム
+======+=======+======+============================+=============+
| Name | Label | Type | Algorithm | Description |
+======+=======+======+============================+=============+
| salt | -20 | bstr | direct+HKDF-SHA-256, | Random salt |
| | | | direct+HKDF-SHA-512, | |
| | | | direct+HKDF-AES-128, | |
| | | | direct+HKDF-AES-256, ECDH- | |
| | | | ES+HKDF-256, ECDH-ES+HKDF- | |
| | | | 512, ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+------+-------+------+----------------------------+-------------+
Table 9: HKDF Algorithm Parameters
表9：HKDFアルゴリズムパラメータ
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 JSON Object Signing and Encryption (JOSE) (Section 4.6.2 of [RFC7518]).
コンテキスト情報構造は、導出された鍵素材が取引のコンテキストに「結びつく」ことを確認するために使用されます。ここで使用されているコンテキスト情報構造は、[SP800-56A]で定義されているものに基づいています。コンテキスト情報構造のエンコーディングにCBORを使用することで、ASN.1の使用によって得られるフィールドの同じタイプと長さの分離が自動的に得られます。これは、JSON Object Signing and Encryption（JOSE）のエンコーディングで行われる長さのエンコードを行う必要がないことを意味します（[RFC7518]のセクション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 defining 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.
* フィールドはアプリケーションによって定義されることができます。これは一般的に当事者に固定の名前を割り当てるために使用されますが、nonceなどの他のアイテムにも使用できます。
* 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 header parameters in Table 10 that can be used to carry the values associated with the context structure. Examples of this are identities and nonce values. These header 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 are already included in the cryptographic computation by virtue of being included in the context structure.
* フィールドはメッセージからのパラメータによって定義されることができます。私たちは、コンテキスト構造に関連する値を運ぶために使用できる一連のヘッダーパラメータを表10に定義します。これには、アイデンティティやナンス値などの例があります。これらのヘッダーパラメータは、受信者構造の保護されていないバケットに配置されるように設計されています。これらは保護されたバケットに含まれる必要はありません。なぜなら、これらはすでにコンテキスト構造に含まれているため、暗号計算に含まれているからです。
+==========+=======+======+===========================+=============+
| Name | Label | Type | Algorithm | Description |
+==========+=======+======+===========================+=============+
| PartyU | -21 | bstr | direct+HKDF-SHA-256, | PartyU |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | |
| | | | ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, | |
| | | | ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyU | -22 | bstr | direct+HKDF-SHA-256, | PartyU |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | |
| | | | ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, | |
| | | | ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyU | -23 | bstr | direct+HKDF-SHA-256, | PartyU |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | |
| | | | ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, | |
| | | | ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -24 | bstr | direct+HKDF-SHA-256, | PartyV |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | |
| | | | ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, | |
| | | | ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -25 | bstr | direct+HKDF-SHA-256, | PartyV |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | |
| | | | ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, | |
| | | | ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -26 | bstr | direct+HKDF-SHA-256, | PartyV |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | |
| | | | ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, | |
| | | | ECDH-ES+A256KW, | |
| | | | ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
Table 10: Context Algorithm Parameters
表10：コンテキストアルゴリズムパラメータ
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:
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 a different key is generated for each algorithm even if all of the other context information is the same. In practice, this means if algorithm A is broken and thus finding the key is relatively easy, the key derived for algorithm B will not be the same as the key derived for algorithm A.
このフィールドは、キー素材が使用されるアルゴリズムを示します。通常、これはキーラップアルゴリズム識別子またはコンテンツ暗号化アルゴリズム識別子のいずれかです。値は「COSE Algorithms」レジストリから取得されます。このフィールドは存在する必要があります。このフィールドはコンテキスト情報に存在し、他のすべてのコンテキスト情報が同じでも、異なるアルゴリズムごとに異なるキーが生成されるようになっています。実際には、これはアルゴリズムAが破られてキーを比較的簡単に見つけることができる場合、アルゴリズムB用に導出されたキーはアルゴリズムA用に導出されたキーと同じではないことを意味します。
PartyUInfo:
PartyUInfo:
This field holds information about PartyU. The PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo are encoded in the order presented below. The elements of the PartyUInfo array are:
このフィールドにはPartyUに関する情報が格納されています。PartyUInfoはCBOR配列としてエンコードされています。PartyUInfoの要素は以下に示す順序でエンコードされています。PartyUInfo配列の要素は次の通りです。
identity:
アイデンティティ
This contains the identity information for PartyU. The identities can be assigned in one of two manners. First, a protocol can assign identities based on roles. For example, the roles of "client" and "server" may be assigned to different entities in the protocol. Each entity would then use the correct label for the data it sends or receives. The second way for a protocol to assign identities is to use a name based on a naming system (i.e., DNS or X.509 names).
これにはPartyUの識別情報が含まれています。識別情報は2つの方法のいずれかで割り当てることができます。まず、プロトコルは役割に基づいて識別情報を割り当てることができます。たとえば、プロトコル内の異なるエンティティに「クライアント」と「サーバー」の役割を割り当てることができます。その後、各エンティティは送受信するデータに適切なラベルを使用します。プロトコルが識別情報を割り当てるための2番目の方法は、名前に基づいた命名システム（つまり、DNSまたはX.509名）を使用することです。
We define an algorithm parameter, "PartyU identity", that can be used to carry identity information in the message. However, identity information is often known as part of the protocol and can thus be inferred rather than made explicit. If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information. The identity information does not need to be specified and is set to nil in that case.
私たちは、メッセージ内での識別情報の携帯に使用できるアルゴリズムパラメーター「PartyU identity」を定義します。ただし、識別情報はプロトコルの一部として通常知られており、明示的に作成されるのではなく推論されることがよくあります。識別情報がメッセージに含まれている場合、アプリケーションは提供された識別情報を検証する方法を持っているべきです。その場合、識別情報は指定する必要はなく、nilに設定されます。
nonce:
nonce:
This contains a nonce value. The nonce can be either implicit from the protocol or carried as a value in the unprotected header bucket.
これには一意の値が含まれています。ノンスはプロトコルから暗黙的に取得されるか、保護されていないヘッダーバケット内の値として運ばれることがあります。
We define an algorithm parameter, "PartyU nonce", that can be used to carry this value in the message; however, the nonce value could be determined by the application and its value obtained in a different manner.
私たちは、メッセージでこの値を運ぶために使用できるアルゴリズムパラメーター「PartyU nonce」を定義します。ただし、nonceの値はアプリケーションによって決定され、その値は異なる方法で取得される可能性があります。
This option does not need to be specified; if not needed, it is set to nil.
このオプションは指定する必要はありません。必要ない場合は、nilに設定されます。
other:
他
This contains other information that is defined by the protocol. This option does not need to be specified; if not needed, it is set to nil.
このオプションには、プロトコルで定義された他の情報が含まれています。このオプションは指定する必要はありません。必要がない場合は、nilに設定されます。
PartyVInfo:
PartyVInfo:
This field holds information about PartyV. The content of the structure is the same as for the PartyUInfo but for PartyV.
このフィールドにはPartyVに関する情報が格納されています。構造体の内容はPartyUInfoと同じですが、PartyV用です。
SuppPubInfo:
SuppPubInfo:
This field contains public information that is mutually known to both parties, and is encoded as a CBOR array.
このフィールドには、両当事者に共通に知られている公開情報が含まれており、CBOR配列としてエンコードされています。
keyDataLength:
keyDataLength:
This is set to the number of bits of the desired output value. This practice means if algorithm A can use two different key lengths, the key derived for the longer key size will not contain the key for the shorter key size as a prefix.
これは、出力値のビット数に設定されています。この実践は、アルゴリズムAが2つの異なるキー長を使用できる場合、より長いキーサイズ用に導出されたキーには、より短いキーサイズのキーが接頭辞として含まれないことを意味します。
protected:
保護された
This field contains the protected parameter field. If there are no elements in the "protected" field, then use a zero-length bstr.
このフィールドには保護されたパラメーターフィールドが含まれています。 "protected" フィールドに要素がない場合は、長さゼロの bstr を使用してください。
other:
そのまま出力します。
This field is for free-form data defined by the application. For example, an application could define two different byte strings to be placed here to generate different keys for a data stream versus a control stream. This 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.
このフィールドは、アプリケーションによって定義された自由形式のデータ用です。たとえば、アプリケーションは、データストリームと制御ストリーム用の異なるキーを生成するために、ここに配置する2つの異なるバイト文字列を定義できます。このフィールドはオプションであり、アプリケーションがこの情報の構造を定義している場合にのみ存在します。このように定義するアプリケーションは、データをエンコードするために CBOR を使用するべきです。これにより、タイプと長さが正しく含まれます。
SuppPrivInfo:
SuppPrivInfo:
This field contains private information that is mutually known private information. An example of this information would be a pre-existing 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.
このフィールドには、共有された秘密情報である相互に知られた秘密情報が含まれています。この情報の例としては、事前に共有された秘密が挙げられます。（これは、例えばECDH鍵合意と組み合わせて、二次的な身元の証明を提供するために使用できます。）このフィールドはオプションであり、アプリケーションがこの情報の構造を定義している場合にのみ存在します。これを定義するアプリケーションは、データをエンコードするためにCBORを使用するべきであり、タイプと長さが正しく含まれるようにする必要があります。
The following CDDL fragment corresponds to the text above.
次の CDDL フラグメントは、上記のテキストに対応します。
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
]
Section 8.5 of [RFC9052] contains a generic description of content key distribution methods. This document defines the identifiers and usage for a number of content key distribution methods.
[RFC9052]のセクション8.5には、コンテンツキー配布方法の一般的な説明が含まれています。この文書は、いくつかのコンテンツキー配布方法の識別子と使用法を定義しています。
A direct encryption algorithm is defined in Section 8.5.1 of [RFC9052]. Information about how to fill in the COSE_Recipient structure is detailed there.
[RFC9052]のセクション8.5.1で直接暗号化アルゴリズムが定義されています。COSE_Recipient構造体の入力方法に関する情報が詳細に記載されています。
This recipient algorithm is the simplest; the identified key is directly used as the key for the next layer down in the message. There are no algorithm parameters defined for this algorithm. The algorithm identifier value is assigned in Table 11.
この受信者アルゴリズムは、最も単純なものです。識別されたキーは、メッセージの下位レイヤーで直接使用されます。このアルゴリズムには定義されたアルゴリズムパラメータはありません。アルゴリズム識別子の値は、表11に割り当てられます。
When this algorithm is used, the "protected" field MUST be zero length. The key type MUST be "Symmetric".
このアルゴリズムが使用される場合、"protected" フィールドはゼロ長でなければなりません。キーの種類は「対称的」でなければなりません。
+========+=======+============================================+
| Name | Value | Description |
+========+=======+============================================+
| direct | -6 | Direct use of content encryption key (CEK) |
+--------+-------+--------------------------------------------+
Table 11: Direct Key
表11：直接キー
This recipient algorithm has several potential problems that need to be considered:
この受信者アルゴリズムには考慮すべき潜在的な問題がいくつかあります。
* These keys need to have some method of being regularly updated over time. All of the content encryption algorithms specified in this document have limits on how many times a key can be used without significant loss of security.
* これらのキーは、時間の経過とともに定期的に更新される必要があります。この文書で指定されたすべてのコンテンツ暗号化アルゴリズムには、セキュリティの著しい損失なしにキーを使用できる回数に制限があります。
* These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key for both the CBC encryption mode and the CBC-MAC authentication mode.
* これらのキーは1つのアルゴリズムに専用される必要があります。1つのキーが複数の異なるアルゴリズムに使用されると、時間の経過とともにいくつかの攻撃が開発されてきました。その1つの例は、CBC暗号化モードとCBC-MAC認証モードの両方に同じキーを使用することです。
* Breaking one message means all messages are broken. If an adversary succeeds in determining the key for a single message, then the key for all messages is also determined.
* 1つのメッセージが壊れると、すべてのメッセージが壊れます。敵が1つのメッセージの鍵を特定に成功した場合、すべてのメッセージの鍵も特定されます。
These recipient algorithms take a common shared secret between the two parties and apply the HKDF function (Section 5.1), using the context structure defined in Section 5.2 to transform the shared secret into the CEK. The "protected" field can be of nonzero length. Either the "salt" parameter for HKDF (Table 9) or the "PartyU nonce" parameter for the context structure (Table 10) MUST be present (both can be present if desired). The value in the "salt"/"nonce" parameter can be generated either randomly or deterministically. The requirement is that it be a unique value for the shared secret in question.
これらの受信者アルゴリズムは、2つの当事者間で共有された共通の秘密を取り、セクション5.2で定義されたコンテキスト構造を使用して、共有された秘密をCEKに変換するためにHKDF関数（セクション5.1）を適用します。 "protected"フィールドはゼロでない長さにすることができます。 HKDFのための「salt」パラメータ（表9）またはコンテキスト構造の「PartyU nonce」パラメータ（表10）のいずれかが存在している必要があります（必要に応じて両方が存在しても構いません）。 "salt" / "nonce"パラメータの値はランダムに生成されるか、決定論的に生成されるかのいずれかです。要件は、それが問題の共有された秘密に対して一意の値であることです。
If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the output of the hash function underlying HKDF. While there is no way to guarantee that it will be unique, there is a high probability that it will be unique. If the salt/nonce value is generated deterministically, it can be guaranteed to be unique, and thus there is no length requirement.
塩/ナンス値がランダムに生成される場合、そのランダム値の長さはHKDFのハッシュ関数の出力と同じ長さであることが推奨されます。一意であることを保証する方法はありませんが、高い確率で一意である可能性があります。塩/ナンス値が決定論的に生成される場合、一意であることが保証されるため、長さの要件はありません。
A new IV must be used for each message if the same key is used. The IV can be modified in a predictable manner, a random manner, or an unpredictable manner (e.g., encrypting a counter).
同じキーを使用する場合は、各メッセージに新しいIVを使用する必要があります。IVは予測可能な方法、ランダムな方法、または予測不可能な方法（例：カウンターを暗号化する）で変更できます。
The IV used for a key can also be generated using the same HKDF functionality used to generate the key. If HKDF is used for generating the IV, the algorithm identifier is set to 34 ("IV-GENERATION").
鍵に使用されるIVも、鍵を生成するために使用されるHKDF機能を使用して生成することができます。IVを生成するためにHKDFが使用される場合、アルゴリズム識別子は34（「IV-GENERATION」）に設定されます。
The set of algorithms defined in this document can be found in Table 12.
この文書で定義されたアルゴリズムのセットは、表12にあります。
+=====================+=======+==============+=====================+
| Name | Value | KDF | Description |
+=====================+=======+==============+=====================+
| direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ |
| | | | HKDF and SHA-256 |
+---------------------+-------+--------------+---------------------+
| direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ |
| | | | HKDF and SHA-512 |
+---------------------+-------+--------------+---------------------+
| direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ |
| | | MAC-128 | AES-MAC 128-bit key |
+---------------------+-------+--------------+---------------------+
| direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ |
| | | MAC-256 | AES-MAC 256-bit key |
+---------------------+-------+--------------+---------------------+
Table 12: Direct Key with KDF
表12：KDFを使用したダイレクトキー
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 algorithm being used.
* もし "alg" フィールドが存在する場合、それは使用されているアルゴリズムと一致していなければなりません。
* If the "key_ops" field is present, it MUST include "derive key" or "derive bits".
* "key_ops" フィールドが存在する場合、"derive key" または "derive bits" を含める必要があります。
The shared secret needs to have some method of being regularly updated over time. The shared secret forms the basis of trust. Although not used directly, it should still be subject to scheduled rotation.
共有された秘密は、時間の経過とともに定期的に更新される方法を持つ必要があります。共有された秘密は信頼の基盤を形成します。直接使用されない場合でも、定期的なローテーションの対象とすべきです。
These methods do not provide for perfect forward secrecy, as the same shared secret is used for all of the keys generated; however, if the key for any single message is discovered, only the message or series of messages using that derived key are compromised. A new key derivation step will generate a new key that requires the same amount of work to get the key.
これらの方法は完全な前方秘匿性を提供しませんが、生成されたすべてのキーに同じ共有秘密が使用されます。ただし、単一のメッセージのキーが発見された場合、その派生キーを使用するメッセージまたは一連のメッセージのみが危険にさらされます。新しいキー派生ステップにより、同じ作業量でキーを取得する必要がある新しいキーが生成されます。
Key wrap is defined in Section 8.5.2 of [RFC9052]. Information about how to fill in the COSE_Recipient structure is detailed there.
キーのラップは[RFC9052]のセクション8.5.2で定義されています。COSE_Recipient構造体の入力方法に関する情報がそこに詳細に記載されています。
The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm uses an AES key to wrap a value that is a multiple of 64 bits. As such, it can be used to wrap a key for any of the content encryption algorithms defined in this document. The algorithm requires a single fixed parameter, the initial value. This is fixed to the value specified in Section 2.2.3.1 of [RFC3394]. There are no public key parameters that vary on a per-invocation basis. The protected header bucket MUST be empty.
AESキー包装アルゴリズムは[RFC3394]で定義されています。このアルゴリズムは、64ビットの倍数である値を包むためにAESキーを使用します。そのため、このドキュメントで定義されているコンテンツ暗号化アルゴリズムのいずれかのキーを包むために使用できます。このアルゴリズムには、1つの固定パラメータ、初期値が必要です。これは[RFC3394]のセクション2.2.3.1で指定された値に固定されています。呼び出し毎に異なる公開鍵パラメータはありません。保護されたヘッダーバケットは空でなければなりません。
Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
キーは、キー構造または受信者構造から取得できます。暗号化または復号を行う実装は、キーの種類、長さ、およびアルゴリズムが正しいかつ関連するエンティティに適していることを検証する必要があります。
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 Key Wrap algorithm being used.
* もし「alg」フィールドが存在する場合、それは使用されているAES Key Wrapアルゴリズムと一致しなければなりません。
* 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" を含める必要があります。
+========+=======+==========+=============================+
| Name | Value | Key Size | Description |
+========+=======+==========+=============================+
| A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key |
+--------+-------+----------+-----------------------------+
| A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key |
+--------+-------+----------+-----------------------------+
| A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key |
+--------+-------+----------+-----------------------------+
Table 13: AES Key Wrap Algorithm Values
表13：AESキー包装アルゴリズムの値
The shared secret needs to have some method of being regularly updated over time. The shared secret is the basis of trust.
共有された秘密は、時間の経過とともに定期的に更新される方法が必要です。共有された秘密は信頼の基盤です。
Direct Key Agreement is defined in Section 8.5.4 of [RFC9052]. Information about how to fill in the COSE_Recipient structure is detailed there.
Direct Key Agreementは[RFC9052]のセクション8.5.4で定義されています。COSE_Recipient構造体の記入方法に関する情報がそこに詳細に記載されています。
The mathematics for ECDH can be found in [RFC6090]. In this document, the algorithm is extended to be used with the two curves defined in [RFC7748].
ECDHの数学は[RFC6090]にあります。この文書では、アルゴリズムが[RFC7748]で定義された2つの曲線と共に使用されるように拡張されています。
ECDH is parameterized by the following:
ECDHは以下でパラメータ化されます。
Curve Type/Curve:
曲線タイプ/曲線:
The curve selected controls not only the size of the shared secret, but the mathematics for computing the shared secret. The curve selected also controls how a point in the curve is represented and what happens for the identity points on the curve. In this specification, we allow for a number of different curves to be used. A set of curves is defined in Table 18.
選択された曲線は、共有秘密のサイズだけでなく、共有秘密を計算するための数学を制御します。選択された曲線はまた、曲線上の点の表現方法や、曲線上の単位点に対する動作も制御します。この仕様では、複数の異なる曲線を使用することが許可されています。曲線のセットは、表18に定義されています。
The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm. For this reason, a new algorithm does not need to be defined for each of the curves.
計算された秘密を取得するために使用される数学は、選択された曲線に基づいており、ECDHアルゴリズムに基づいていません。このため、各曲線ごとに新しいアルゴリズムを定義する必要はありません。
Computed Secret to Shared Secret:
計算された秘密を共有秘密に変換します。
Once the computed secret is known, the resulting value needs to be converted to a byte string to run the KDF. The x-coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly, as it is a byte string of a known length. For the P-256, P-384, and P-521 curves, the x-coordinate is run through the Integer-to-Octet-String primitive (I2OSP) function defined in [RFC8017], using the same computation for n as is defined in Section 2.1.
計算された秘密がわかったら、結果の値をバイト文字列に変換してKDFを実行する必要があります。このドキュメントで定義されたすべての曲線についてx座標が使用されます。X25519およびX448の曲線では、結果の値が既知の長さのバイト文字列であるため、直接使用されます。P-256、P-384、およびP-521の曲線では、x座標は、[RFC8017]で定義された整数からオクテット文字列への変換（I2OSP）関数を使用して、セクション2.1で定義されているnに対して同じ計算が行われます。
Ephemeral-Static or Static-Static:
Ephemeral-StaticまたはStatic-Static:
The key agreement process may be done using either a static or an ephemeral key for the sender's side. When using ephemeral keys, the sender MUST generate a new ephemeral key for every key agreement operation. The ephemeral key is placed in the "ephemeral key" parameter and MUST be present for all algorithm identifiers that use ephemeral keys. When using static keys, the sender MUST either generate a new random value or create a unique value for use as a KDF input. For the KDFs used, this means that either the "salt" parameter for HKDF (Table 9) or the "PartyU nonce" parameter for the context structure (Table 10) MUST be present (both can be present if desired). The value in the parameter MUST be unique for the pair of keys being used. It is acceptable to use a global counter that is incremented for every Static-Static operation and use the resulting value. Care must be taken that the counter is saved to permanent storage in a way that avoids reuse of that counter value. When using static keys, the static key should be identified to the recipient. The static key can be identified by providing either the key ("static key") or a key identifier for the static key ("static key id"). Both of these header parameters are defined in Table 15.
鍵合意プロセスは、送信側に対して静的キーまたはエフェメラルキーのいずれかを使用して行うことができます。エフェメラルキーを使用する場合、送信者はすべての鍵合意操作ごとに新しいエフェメラルキーを生成する必要があります。エフェメラルキーは「ephemeral key」パラメータに配置され、エフェメラルキーを使用するすべてのアルゴリズム識別子に存在する必要があります。静的キーを使用する場合、送信者は新しいランダム値を生成するか、KDF入力として使用するための一意の値を作成する必要があります。使用されるKDFに対して、HKDF（表9）の「salt」パラメータまたはコンテキスト構造（表10）の「PartyU nonce」パラメータのいずれかが存在する必要があります（必要に応じて両方が存在することもできます）。パラメータ内の値は使用される鍵のペアに対して一意である必要があります。静的キーを使用する場合、静的キーは受信者に識別されるべきです。静的キーは、キー（「static key」）または静的キーのためのキー識別子（「static key id」）のいずれかを提供することで識別できます。これらのヘッダーパラメータは、表15で定義されています。
Key Derivation Algorithm:
鍵導出アルゴリズム:
The result of an ECDH key agreement process does not provide a uniformly random secret. As such, it needs to be run through a KDF in order to produce a usable key. Processing the secret through a KDF also allows for the introduction of context material: how the key is going to be used and one-time material for Static-Static key agreement. All of the algorithms defined in this document use one of the HKDF algorithms defined in Section 5.1 with the context structure defined in Section 5.2.
ECDH鍵合意プロセスの結果は一様ランダムな秘密を提供しません。そのため、使用可能な鍵を生成するためにKDFを通過する必要があります。秘密をKDFを通じて処理することは、鍵の使用方法やStatic-Static鍵合意のための一度限りの素材を導入することも可能にします。この文書で定義されているすべてのアルゴリズムは、セクション5.1で定義されているHKDFアルゴリズムのいずれかを使用し、セクション5.2で定義されているコンテキスト構造を使用します。
Key Wrap Algorithm:
キー包装アルゴリズム:
No key wrap algorithm is used. This is represented in Table 14 as "none". The key size for the context structure is the content layer encryption algorithm size.
キー ラップ アルゴリズムは使用されません。これは「なし」として表14に表されています。コンテキスト構造のキー サイズはコンテンツ レイヤーの暗号化アルゴリズムのサイズです。
COSE does not have an Ephemeral-Ephemeral version defined. The reason for this is that COSE is not an online protocol by itself and thus does not have a method of establishing ephemeral secrets on both sides. The expectation is that a protocol would establish the secrets for both sides, and then they would be used as Static-Static for the purposes of COSE, or that the protocol would generate a shared secret and a direct encryption would be used.
COSEにはエフェメラル-エフェメラルバージョンが定義されていません。これは、COSE自体がオンラインプロトコルではなく、したがって両側でエフェメラルシークレットを確立する方法がないためです。期待されるのは、プロトコルが両側のシークレットを確立し、それらがCOSEの目的のためにStatic-Staticとして使用されるか、プロトコルが共有シークレットを生成し、直接暗号化が使用されることです。
The set of direct ECDH algorithms defined in this document is found in Table 14.
この文書で定義されている直接ECDHアルゴリズムのセットは、表14にあります。
+==========+=======+=========+==================+====+==============+
| Name | Value | KDF | Ephemeral-Static |Key | Description |
| | | | |Wrap| |
+==========+=======+=========+==================+====+==============+
| ECDH-ES | -25 | HKDF -- | yes |none| ECDH ES w/ |
| + | | SHA-256 | | | HKDF -- |
| HKDF-256 | | | | | generate |
| | | | | | key |
| | | | | | directly |
+----------+-------+---------+------------------+----+--------------+
| ECDH-ES | -26 | HKDF -- | yes |none| ECDH ES w/ |
| + | | SHA-512 | | | HKDF -- |
| HKDF-512 | | | | | generate |
| | | | | | key |
| | | | | | directly |
+----------+-------+---------+------------------+----+--------------+
| ECDH-SS | -27 | HKDF -- | no |none| ECDH SS w/ |
| + | | SHA-256 | | | HKDF -- |
| HKDF-256 | | | | | generate |
| | | | | | key |
| | | | | | directly |
+----------+-------+---------+------------------+----+--------------+
| ECDH-SS | -28 | HKDF -- | no |none| ECDH SS w/ |
| + | | SHA-512 | | | HKDF -- |
| HKDF-512 | | | | | generate |
| | | | | | key |
| | | | | | directly |
+----------+-------+---------+------------------+----+--------------+
Table 14: ECDH Algorithm Values
表14：ECDHアルゴリズムの値
+===========+=======+==========+===================+=============+
| Name | Label | Type | Algorithm | Description |
+===========+=======+==========+===================+=============+
| ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral |
| key | | | ECDH-ES+HKDF-512, | public key |
| | | | ECDH-ES+A128KW, | for the |
| | | | ECDH-ES+A192KW, | sender |
| | | | ECDH-ES+A256KW | |
+-----------+-------+----------+-------------------+-------------+
| static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static |
| key | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A128KW, | for the |
| | | | ECDH-SS+A192KW, | sender |
| | | | ECDH-SS+A256KW | |
+-----------+-------+----------+-------------------+-------------+
| static | -3 | bstr | ECDH-SS+HKDF-256, | Static |
| key id | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A128KW, | identifier |
| | | | ECDH-SS+A192KW, | for the |
| | | | ECDH-SS+A256KW | sender |
+-----------+-------+----------+-------------------+-------------+
Table 15: ECDH Algorithm Parameters
表15：ECDHアルゴリズムパラメータ
This document defines these algorithms to be used with the curves P-256, P-384, P-521, X25519, and X448. Implementations MUST verify that the key type and curve are correct. Different curves are restricted to different key types. Implementations MUST verify that the curve and algorithm are appropriate for the entities involved.
この文書は、曲線P-256、P-384、P-521、X25519、およびX448と使用するためにこれらのアルゴリズムを定義します。実装は、キーの種類と曲線が正しいことを検証する必要があります。異なる曲線は異なるキーの種類に制限されています。実装は、曲線とアルゴリズムが関係するエンティティに適していることを検証する必要があります。
When using a COSE key for this algorithm, the following checks are made:
このアルゴリズムでCOSEキーを使用する場合、以下のチェックが行われます。
* The "kty" field MUST be present, and it MUST be "EC2" or "OKP".
* "kty"フィールドは必ず存在し、"EC2"または"OKP"でなければなりません。
* If the "alg" field is present, it MUST match the key agreement algorithm being used.
* もし「alg」フィールドが存在する場合、それは使用されている鍵合意アルゴリズムと一致しなければなりません。
* If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key.
* もし「key_ops」フィールドが存在する場合、それは必ず「derive key」または「derive bits」を含まなければなりません。
* If the "key_ops" field is present, it MUST be empty for the public key.
* もし "key_ops" フィールドが存在する場合、公開鍵の場合は空でなければなりません。
There is a method of checking that points provided from external entities are valid. For the "EC2" key format, this can be done by checking that the x and y values form a point on the curve. For the "OKP" format, there is no simple way to perform point validation.
外部エンティティから提供されたポイントが有効であるかを確認する方法があります。 "EC2"キー形式の場合、xとyの値が曲線上のポイントを形成しているかどうかを確認することができます。 "OKP"形式の場合、ポイントの検証を行う簡単な方法はありません。
Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process (as recommended in Section 6.1 of [RFC7748]). This was not done, because COSE is used in a store-and-forward format rather than in online key exchange. In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious. In either case, all security evaporates anyway.
両者の公開鍵が鍵導出プロセスの一部として提供されることを要求することが検討されました（[RFC7748]のセクション6.1で推奨されています）。これは行われませんでした。なぜなら、COSEはオンライン鍵交換ではなく、ストア・アンド・フォワード形式で使用されているからです。これが問題になるためには、受信者の公開鍵が悪意を持って選択されるか、送信者が悪意を持っている必要があります。いずれの場合も、すべてのセキュリティが消失します。
A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted (either by the end user or by the entity that is responsible for making trust statements on keys).
公開鍵に関連付けられた秘密鍵の所有を証明することが推奨されます。鍵が信頼されていない状態から信頼された状態に移動する際（最終ユーザーまたは鍵に関する信頼ステートメントを行うエンティティによって）、
Key Agreement with Key Wrap is defined in Section 8.5.5 of [RFC9052]. Information about how to fill in the COSE_Recipient structure is detailed there.
[RFC9052]のセクション8.5.5でKey Agreement with Key Wrapが定義されています。COSE_Recipient構造体の記入方法に関する情報がそこに詳細に記載されています。
These algorithms are defined in Table 16.
これらのアルゴリズムは表16に定義されています。
ECDH with Key Agreement is parameterized by the same header parameters as for ECDH; see Section 6.3.1, with the following modifications:
ECDH with Key Agreementは、ECDHと同じヘッダーパラメーターでパラメータ化されます。セクション6.3.1を参照してください。以下の修正が加えられています。
Key Wrap Algorithm:
キー包装アルゴリズム:
Any of the key wrap algorithms defined in Section 6.2 are supported. The size of the key used for the key wrap algorithm is fed into the KDF. The set of identifiers is found in Table 16.
セクション6.2で定義されたキーラップアルゴリズムのいずれもサポートされています。キーラップアルゴリズムに使用されるキーのサイズがKDFに供給されます。識別子のセットは表16にあります。
+=========+=====+=========+==================+======+==============+
| Name |Value| KDF | Ephemeral-Static |Key | Description |
| | | | |Wrap | |
+=========+=====+=========+==================+======+==============+
| ECDH-ES |-29 | HKDF -- | yes |A128KW| ECDH ES w/ |
| + | | SHA-256 | | | HKDF and AES |
| A128KW | | | | | Key Wrap w/ |
| | | | | | 128-bit key |
+---------+-----+---------+------------------+------+--------------+
| ECDH-ES |-30 | HKDF -- | yes |A192KW| ECDH ES w/ |
| + | | SHA-256 | | | HKDF and AES |
| A192KW | | | | | Key Wrap w/ |
| | | | | | 192-bit key |
+---------+-----+---------+------------------+------+--------------+
| ECDH-ES |-31 | HKDF -- | yes |A256KW| ECDH ES w/ |
| + | | SHA-256 | | | HKDF and AES |
| A256KW | | | | | Key Wrap w/ |
| | | | | | 256-bit key |
+---------+-----+---------+------------------+------+--------------+
| ECDH-SS |-32 | HKDF -- | no |A128KW| ECDH SS w/ |
| + | | SHA-256 | | | HKDF and AES |
| A128KW | | | | | Key Wrap w/ |
| | | | | | 128-bit key |
+---------+-----+---------+------------------+------+--------------+
| ECDH-SS |-33 | HKDF -- | no |A192KW| ECDH SS w/ |
| + | | SHA-256 | | | HKDF and AES |
| A192KW | | | | | Key Wrap w/ |
| | | | | | 192-bit key |
+---------+-----+---------+------------------+------+--------------+
| ECDH-SS |-34 | HKDF -- | no |A256KW| ECDH SS w/ |
| + | | SHA-256 | | | HKDF and AES |
| A256KW | | | | | Key Wrap w/ |
| | | | | | 256-bit key |
+---------+-----+---------+------------------+------+--------------+
Table 16: ECDH Algorithm Values with Key Wrap
表16：キー包装付きのECDHアルゴリズム値
When using a COSE key for this algorithm, the following checks are made:
このアルゴリズムでCOSEキーを使用する場合、以下のチェックが行われます。
* The "kty" field MUST be present, and it MUST be "EC2" or "OKP".
* "kty"フィールドは必ず存在し、"EC2"または"OKP"でなければなりません。
* If the "alg" field is present, it MUST match the key agreement algorithm being used.
* もし「alg」フィールドが存在する場合、それは使用されている鍵合意アルゴリズムと一致しなければなりません。
* If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key.
* もし "key_ops" フィールドが存在する場合、それは必ず "derive key" または "derive bits" を含まなければなりません。
* If the "key_ops" field is present, it MUST be empty for the public key.
* "key_ops" フィールドが存在する場合、公開鍵の場合は空でなければなりません。
The COSE_Key object defines a way to hold a single key object. It is still required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key types.
COSE_Keyオブジェクトは単一のキーオブジェクトを保持する方法を定義します。個々のキータイプのメンバーが定義されている必要があります。このドキュメントのこのセクションでは、特定のキータイプの初期メンバーを定義します。
For each of the key types, we define both public and private members. The public members are what is transmitted to others for their usage. Private members allow individuals to archive keys. However, there are some circumstances in which private keys may be distributed to entities in a protocol. Examples include: entities that have poor random number generation, centralized key creation for multicast-type operations, and protocols in which a shared secret is used as a bearer token for authorization purposes.
各キータイプについて、公開メンバーと非公開メンバーを定義します。公開メンバーは他の人に送信され、使用されます。非公開メンバーは個人がキーをアーカイブできるようにします。ただし、プロトコルで非公開キーがエンティティに配布される場合もあります。例には、ランダムな数値生成が不十分なエンティティ、マルチキャスト型操作のための中央集権的なキー作成、共有シークレットが認証目的のベアラートークンとして使用されるプロトコルなどがあります。
Key types are identified by the "kty" member of the COSE_Key object. In this document, we define four values for the member:
キーの種類は、COSE_Keyオブジェクトの"kty"メンバーによって識別されます。このドキュメントでは、そのメンバーに対して4つの値を定義します。
+===========+=======+==========================+
| Name | Value | Description |
+===========+=======+==========================+
| OKP | 1 | Octet Key Pair |
+-----------+-------+--------------------------+
| EC2 | 2 | Elliptic Curve Keys w/ |
| | | x- and y-coordinate pair |
+-----------+-------+--------------------------+
| Symmetric | 4 | Symmetric Keys |
+-----------+-------+--------------------------+
| Reserved | 0 | This value is reserved |
+-----------+-------+--------------------------+
Table 17: Key Type Values
表17：キータイプの値
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 conventional elliptic curve (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").
2つの異なる鍵構造が楕円曲線鍵のために定義されています。1つのバージョンはx座標とy座標の両方を使用し、ポイント圧縮を行うことがあります（「EC2」）。これは[RFC5480]で使用されている従来の楕円曲線（EC）ポイント表現です。もう1つのバージョンはx座標のみを使用し、y座標は鍵合意操作に再計算されるか必要ないかのどちらかです（「OKP」）。
Applications MUST check that the curve and the key type are consistent and reject a key if they are not.
アプリケーションは、曲線とキーの種類が一致しているかどうかを確認し、一致していない場合はキーを拒否する必要があります。
+=========+=======+==========+=====================================+
| Name | Value | Key Type | Description |
+=========+=======+==========+=====================================+
| P-256 | 1 | EC2 | NIST P-256, also known as secp256r1 |
+---------+-------+----------+-------------------------------------+
| P-384 | 2 | EC2 | NIST P-384, also known as secp384r1 |
+---------+-------+----------+-------------------------------------+
| P-521 | 3 | EC2 | NIST P-521, also known as secp521r1 |
+---------+-------+----------+-------------------------------------+
| X25519 | 4 | OKP | X25519 for use w/ ECDH only |
+---------+-------+----------+-------------------------------------+
| X448 | 5 | OKP | X448 for use w/ ECDH only |
+---------+-------+----------+-------------------------------------+
| Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only |
+---------+-------+----------+-------------------------------------+
| Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only |
+---------+-------+----------+-------------------------------------+
Table 18: Elliptic Curves
表18：楕円曲線
Generally, protocols transmit elliptic-curve points as either the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding has not been recommended by the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y-coordinate is potentially useful.
一般的に、プロトコルは楕円曲線の点をx座標とy座標、またはx座標とy座標の符号ビットとして送信します。後者のエンコーディングは、潜在的なIPRの問題のためにIETFによって推奨されていません。ただし、制約のある環境での操作では、y座標を送信しないことでメッセージを縮小できる能力が潜在的に有用です。
For EC keys with both coordinates, the "kty" member is set to 2 (EC2). The key parameters defined in this section are summarized in Table 19. The members that are defined for this key type are:
ECキーの両座標を持つ場合、"kty"メンバーは2（EC2）に設定されます。このセクションで定義されたキーのパラメータは、表19にまとめられています。このキータイプに定義されたメンバーは次のとおりです。
crv:
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 18. Other curves may be registered in the future, and private curves can be used as well.
これには、キーと一緒に使用する曲線の識別子が含まれています。このキータイプのためにこの文書で定義された曲線は、表18にあります。将来他の曲線が登録される可能性があり、プライベート曲線も使用できます。
x:
x:
This contains the x-coordinate for the EC point. The integer is converted to a byte string as defined in [SEC1]. Leading-zero octets MUST be preserved.
このテキストにはECポイントのx座標が含まれています。整数は[SEC1]で定義されたバイト文字列に変換されます。先頭のゼロのオクテットは保持されなければなりません。
y:
y:
This contains either the sign bit or the value of the y-coordinate for the EC point. When encoding the value y, the integer is converted to a byte string (as defined in [SEC1]) and encoded as a CBOR bstr. Leading-zero octets MUST be preserved. Compressed point encoding is also supported. Compute the sign bit as laid out in the Elliptic-Curve-Point-to-Octet-String Conversion function of [SEC1]. If the sign bit is zero, then encode y as a CBOR false value; otherwise, encode y as a CBOR true value. The encoding of the infinity point is not supported.
これには、ECポイントのy座標の符号ビットまたは値が含まれています。 yの値をエンコードするときは、整数をバイト文字列に変換し（[SEC1]で定義されている）、CBOR bstrとしてエンコードします。 先頭のゼロオクテットは保持する必要があります。 圧縮ポイントエンコーディングもサポートされています。 [SEC1]のElliptic-Curve-Point-to-Octet-String変換関数で指定されたように符号ビットを計算します。 符号ビットがゼロの場合、yをCBOR false値としてエンコードします。 それ以外の場合、yをCBOR true値としてエンコードします。 無限ポイントのエンコーディングはサポートされていません。
d:
d:
This contains the private key.
これには秘密鍵が含まれています。
For public keys, it is REQUIRED that "crv", "x", and "y" 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" and "y" also be present, but they can be recomputed from the required elements, and omitting them saves on space.
公開鍵の場合、構造体に「crv」、「x」、および「y」が存在している必要があります。秘密鍵の場合、構造体に「crv」と「d」が存在している必要があります。秘密鍵の場合、「x」と「y」も存在していることが推奨されますが、必要な要素から再計算することができ、それらを省略することでスペースを節約できます。
+======+======+=======+========+=================================+
| Key | Name | Label | CBOR | Description |
| Type | | | Type | |
+======+======+=======+========+=================================+
| 2 | crv | -1 | int / | EC identifier -- Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry |
+------+------+-------+--------+---------------------------------+
| 2 | x | -2 | bstr | x-coordinate |
+------+------+-------+--------+---------------------------------+
| 2 | y | -3 | bstr / | y-coordinate |
| | | | bool | |
+------+------+-------+--------+---------------------------------+
| 2 | d | -4 | bstr | Private key |
+------+------+-------+--------+---------------------------------+
Table 19: EC Key Parameters
表19：ECキーのパラメータ
A new key type is defined for Octet Key Pairs (OKPs). 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（OKPs）用に新しいキータイプが定義されています。このタイプのキーが楕円曲線であるとは限りません。このキータイプは他の曲線タイプにも使用される可能性があります（例：超楕円曲面に基づく数学）。
The key parameters defined in this section are summarized in Table 20. The members that are defined for this key type are:
このセクションで定義された主要なパラメータは、表20にまとめられています。このキータイプに定義されているメンバーは次のとおりです。
crv:
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 18. Other curves may be registered in the future, and private curves can be used as well.
これには、キーと一緒に使用する曲線の識別子が含まれています。このキー種別のためにこの文書で定義された曲線は、表18にあります。将来他の曲線が登録される可能性があり、プライベート曲線も使用できます。
x:
x:
This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25519, internally it is a little-endian integer.)
これには公開鍵が含まれています。バイト文字列には、アルゴリズムで定義された公開鍵が含まれています。（X25519の場合、内部的にはリトルエンディアンの整数です。）
d:
d:
This contains the private key.
これには秘密鍵が含まれています。
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」が存在することが必要です。秘密鍵の場合、構造に「crv」と「d」が存在することが必要です。秘密鍵の場合、「x」も存在することが推奨されますが、必要な要素から再計算でき、省略することでスペースを節約できます。
+======+==========+=======+=======+=================================+
| Name | Key | Label | Type | Description |
| | Type | | | |
+======+==========+=======+=======+=================================+
| crv | 1 | -1 | int / | EC identifier -- Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry |
+------+----------+-------+-------+---------------------------------+
| x | 1 | -2 | bstr | Public Key |
+------+----------+-------+-------+---------------------------------+
| d | 1 | -4 | bstr | Private key |
+------+----------+-------+-------+---------------------------------+
Table 20: Octet Key Pair Parameters
表20：オクテットキーペアパラメータ
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:
k:
This contains the value of the key.
これはキーの値を含んでいます。
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" が存在することが必要です。
+======+==========+=======+======+=============+
| Name | Key Type | Label | Type | Description |
+======+==========+=======+======+=============+
| k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+
Table 21: Symmetric Key Parameters
表21：対称鍵パラメータ
The capabilities of an algorithm or key type need to be specified in some situations. This has a counterpart in the S/MIME specifications, where SMIMECapabilities is defined in Section 2.5.2 of [RFC8551]. This document defines the same concept for COSE.
アルゴリズムや鍵の種類の機能は、特定の状況で指定する必要があります。これは、S/MIME仕様において対応するものがあり、[RFC8551]のセクション2.5.2でSMIMECapabilitiesが定義されています。この文書は、COSEに対して同じ概念を定義しています。
The algorithm identifier is not included in the capabilities data, as it should be encoded elsewhere in the message. The key type identifier is included in the capabilities data, as it is not expected to be encoded elsewhere.
アルゴリズム識別子は、メッセージの他の場所にエンコードされるべきであるため、機能データに含まれていません。キータイプ識別子は、他の場所にエンコードされることは期待されていないため、機能データに含まれています。
Two different types of capabilities are defined: capabilities for algorithms and capabilities for key type. Once defined by registration with IANA, the list of capabilities for an algorithm or key type is immutable. If it is later found that a new capability is needed for a key type or algorithm, it will require that a new code point be assigned to deal with that. As a general rule, the capabilities are going to map to algorithm-specific header parameters or key parameters, but they do not need to do so. An example of this is the HSS-LMS key type capabilities defined below, where the hash algorithm used is included.
2つの異なるタイプの機能が定義されています：アルゴリズム用の機能とキータイプ用の機能。 IANAに登録された後、アルゴリズムまたはキータイプの機能のリストは不変です。後でキータイプまたはアルゴリズムに新しい機能が必要になった場合、それに対処するために新しいコードポイントが割り当てられる必要があります。一般的なルールとして、機能はアルゴリズム固有のヘッダーパラメータやキーパラメータにマッピングされる可能性がありますが、必ずしもそうである必要はありません。以下に定義されているHSS-LMSキータイプの機能の例を示します。使用されるハッシュアルゴリズムが含まれています。
The capability structure is an array of values; the values included in the structure are dependent on a specific algorithm or key type. For algorithm capabilities, the first element should always be a key type value if applicable, but the items that are specific to a key (for example, a curve) should not be included in the algorithm capabilities. This means that if one wishes to enumerate all of the capabilities for a device that implements ECDH, it requires that all of the combinations of algorithms and key pairs be specified. The last example of Section 8.3 provides a case where this is done by allowing for a cross product to be specified between an array of algorithm capabilities and key type capabilities (see the ECDH-ES+A25KW element). For a key, the first element should be the key type value. While this means that the key type value will be duplicated if both an algorithm and key capability are used, the key type is needed in order to understand the rest of the values.
能力構造は値の配列です。構造に含まれる値は特定のアルゴリズムまたはキータイプに依存します。アルゴリズムの能力については、該当する場合は常に最初の要素がキータイプの値であるべきですが、キーに固有の項目（たとえば、曲線）はアルゴリズムの能力に含めてはいけません。これは、ECDHを実装するデバイスのすべての能力を列挙する場合、アルゴリズムとキーペアのすべての組み合わせを指定する必要があることを意味します。セクション8.3の最後の例は、アルゴリズムの能力の配列とキータイプの能力の間でクロスプロダクトを指定することでこれを実現しています（ECDH-ES+A25KW要素を参照）。キーについては、最初の要素はキータイプの値であるべきです。これは、アルゴリズムとキーの能力の両方が使用される場合、キータイプの値が重複することを意味しますが、残りの値を理解するためにはキータイプが必要です。
For the current set of algorithms in the registry other than IV-GENERATION (those in this document as well as those in [RFC8230], [RFC8778], and [RFC9021]), the capabilities list is an array with one element, the key type (from the "COSE Key Types" Registry). It is expected that future registered algorithms could have zero, one, or multiple elements.
登録されているアルゴリズムの現在のセットについて、IV-GENERATION以外のもの（この文書および[RFC8230]、[RFC8778]、[RFC9021]に含まれるもの）について、機能リストは1つの要素、つまりキーの種類（「COSE Key Types」レジストリから）を持つ配列です。将来登録されるアルゴリズムには、要素がゼロ個、1個、または複数個ある可能性があります。
There are a number of pre-existing key types; the following deals with creating the capability definition for those structures:
事前に存在するいくつかのキータイプがあります。次の内容は、それらの構造に対する能力定義の作成に関わります。
* OKP, EC2: The list of capabilities is:
* OKP、EC2：機能のリストは次のとおりです。
- The key type value. (1 for OKP or 2 for EC2.)
- 鍵の種類の値。 (OKP の場合は 1、EC2 の場合は 2。)
- One curve for that key type from the "COSE Elliptic Curves" registry.
- 「COSE楕円曲線」レジストリからその鍵タイプ用の1つの曲線。
* RSA: The list of capabilities is:
* RSA: 機能のリストは次のとおりです。
- The key type value (3).
- キーのタイプ値（3）。
* Symmetric: The list of capabilities is:
* 対称的：機能のリストは：
- The key type value (4).
- キーのタイプ値（4）。
* HSS-LMS: The list of capabilities is:
* HSS-LMS：機能のリストは次のとおりです。
- The key type value (5).
- キーの種類の値（5）。
- Algorithm identifier for the underlying hash function from the "COSE Algorithms" registry.
- "COSE Algorithms" レジストリから基礎となるハッシュ関数のアルゴリズム識別子。
* WalnutDSA: The list of capabilities is:
* WalnutDSA: 機能のリストは次のとおりです。
- The key type value (6).
- キータイプの値（6）。
- The N value (group and matrix size) for the key, a uint.
- キーのN値（グループと行列のサイズ）、uint用。
- The q value (finite field order) for the key, a uint.
- キーのq値（有限体の次数）、uint用。
Capabilities can be used in a key derivation process to make sure that both sides are using the same parameters. The three examples below show different ways that one might utilize parameters in specifying an application protocol:
能力は、両側が同じパラメータを使用していることを確認するために鍵導出プロセスで使用できます。以下の3つの例は、アプリケーションプロトコルを指定する際にパラメータを利用する異なる方法を示しています。
* Only an algorithm capability: This is useful if the protocol wants to require a specific algorithm, such as ES256, but it is agnostic about which curve is being used. This requires that the algorithm identifier be specified in the protocol. See the first example.
* アルゴリズムの能力のみ：プロトコルが特定のアルゴリズム（例：ES256）を要求したい場合に便利ですが、使用されている曲線については無関心です。これには、プロトコルでアルゴリズム識別子を指定する必要があります。最初の例を参照してください。
* Only a key type capability: This is useful if the protocol wants to require a specific key type and curve, such as P-256, but will accept any algorithm using that curve (e.g., both ECDSA and ECDH). See the second example.
* キーの種類のみ: プロトコルが特定のキーの種類と曲線（たとえば P-256）を要求するが、その曲線を使用する任意のアルゴリズム（例: ECDSA と ECDH の両方）を受け入れる場合に便利です。2番目の例を参照してください。
* Both algorithm and key type capabilities: This is used if the protocol needs to nail down all of the options surrounding an algorithm -- e.g., EdDSA with the curve Ed25519. As with the first example, the algorithm identifier needs to be specified in the protocol. See the third example, which just concatenates the two capabilities together.
* アルゴリズムとキータイプの機能の両方: プロトコルがアルゴリズムに関するすべてのオプションを確定する必要がある場合に使用されます-- 例: Ed25519曲線を使用したEdDSA。最初の例と同様に、プロトコルでアルゴリズム識別子を指定する必要があります。2つの機能を単に連結する第3の例を参照してください。
Algorithm ES256
0x8102 / [2 \ EC2 \ ] /
Key type EC2 with P-256 curve:
0x820201 / [2 \ EC2 \, 1 \ P-256 \] /
ECDH-ES + A256KW with an X25519 curve:
0x8101820104 / [1 \ OKP \],[1 \ OKP \, 4 \ X25519 \] /
The capabilities can also be used by an entity to advertise what it is capable of doing. The decoded example below is one of many encodings that could be used for that purpose. Each array element includes three fields: the algorithm identifier, one or more algorithm capabilities, and one or more key type capabilities.
その機能は、エンティティが何ができるかを広告するためにも使用できます。以下のデコードされた例は、その目的に使用できる多くのエンコーディングの1つです。各配列要素には、アルゴリズム識別子、1つ以上のアルゴリズムの機能、および1つ以上のキータイプの機能が含まれています。
[
[-8 / EdDSA /,
[1 / OKP key type /],
[
[1 / OKP /, 6 / Ed25519 / ],
[1 /OKP/, 7 /Ed448 /]
]
],
[-7 / ECDSA with SHA-256/,
[2 /EC2 key type/],
[
[2 /EC2/, 1 /P-256/],
[2 /EC2/, 3 /P-521/]
]
],
[ -31 / ECDH-ES+A256KW/,
[
[ 2 /EC2/],
[1 /OKP/ ]
],
[
[2 /EC2/, 1 /P-256/],
[1 /OKP/, 4 / X25519/ ]
]
],
[ 1 / A128GCM /,
[ 4 / Symmetric / ],
[ 4 / Symmetric /]
]
]
Examining the above:
上記を検討する:
* The first element indicates that the entity supports EdDSA with curves Ed25519 and Ed448.
* 最初の要素は、エンティティが曲線Ed25519とEd448を使用したEdDSAをサポートしていることを示しています。
* The second element indicates that the entity supports ECDSA with SHA-256 with curves P-256 and P-521.
* 2番目の要素は、エンティティがP-256とP-521の曲線を使用したSHA-256でのECDSAをサポートしていることを示しています。
* The third element indicates that the entity supports Ephemeral-Static ECDH using AES256 key wrap. The entity can support the P-256 curve with an EC2 key type and the X25519 curve with an OKP key type.
* 第3要素は、エンティティがAES256キーwrapを使用したエフェメラル-スタティックECDHをサポートしていることを示しています。エンティティは、EC2キータイプでP-256曲線と、OKPキータイプでX25519曲線をサポートできます。
* The last element indicates that the entity supports AES-GCM of 128 bits for content encryption.
* 最後の要素は、エンティティがコンテンツの暗号化に128ビットのAES-GCMをサポートしていることを示しています。
The entity does not advertise that it supports any MAC algorithms.
そのエンティティは、任意のMACアルゴリズムをサポートしていることを広告していません。
This document limits the restrictions it imposes on how the CBOR Encoder needs to work. The new encoding restrictions are aligned with the Core Deterministic Encoding Requirements specified in Section 4.2.1 of RFC 8949 [STD94]. It has been narrowed down to the following restrictions:
この文書は、CBORエンコーダが動作する制限に課せられる制限を限定しています。新しいエンコード制限は、RFC 8949 [STD94]のセクション4.2.1で指定されたコア決定論的エンコーディング要件と一致しています。以下の制限に絞られています。
* The restriction applies to the encoding of the COSE_KDF_Context.
* 制限は、COSE_KDF_Contextのエンコーディングに適用されます。
* Encoding MUST be done using definite lengths, and the length of the (encoded) argument MUST be the minimum possible length. This means that the integer 1 is encoded as "0x01" and not "0x1801".
* エンコーディングは必ず確定長で行われ、（エンコードされた）引数の長さは可能な限り最小限である必要があります。これは、整数1が「0x01」とエンコードされることを意味し、「0x1801」とはなりません。
* Applications MUST NOT generate messages with the same label used twice as a key in a single map. Applications MUST NOT parse and process messages with the same label used twice as a key in a single map. Applications can enforce the parse-and-process requirement by using parsers that will fail the parse step or by using parsers that will pass all keys to the application, and the application can perform the check for duplicate keys.
* アプリケーションは、1つのマップ内で2回使用される同じラベルをキーとして持つメッセージを生成してはなりません。アプリケーションは、1つのマップ内で2回使用される同じラベルをキーとして持つメッセージを解析および処理してはなりません。アプリケーションは、解析および処理の要件を強制するために、解析ステップに失敗するパーサーを使用するか、すべてのキーをアプリケーションに渡すパーサーを使用して、アプリケーションが重複するキーをチェックできます。
IANA has updated all COSE registries except for "COSE Header Parameters" and "COSE Key Common Parameters" to point to this document instead of [RFC8152].
IANAは、「COSEヘッダーパラメータ」と「COSEキーコモンパラメータ」を除くすべてのCOSEレジストリを、[RFC8152]の代わりにこの文書を指すように更新しました。
IANA has added a new column in the "COSE Key Types" registry. The new column is labeled "Capabilities" and has been populated according to the entries in Table 22.
IANAは「COSE Key Types」レジストリに新しい列を追加しました。新しい列は「Capabilities」とラベルされ、表22のエントリに従って埋められました。
+=======+===========+============================+
| Value | Name | Capabilities |
+=======+===========+============================+
| 1 | OKP | [kty(1), crv] |
+-------+-----------+----------------------------+
| 2 | EC2 | [kty(2), crv] |
+-------+-----------+----------------------------+
| 3 | RSA | [kty(3)] |
+-------+-----------+----------------------------+
| 4 | Symmetric | [kty(4)] |
+-------+-----------+----------------------------+
| 5 | HSS-LMS | [kty(5), hash algorithm] |
+-------+-----------+----------------------------+
| 6 | WalnutDSA | [kty(6), N value, q value] |
+-------+-----------+----------------------------+
Table 22: Key Type Capabilities
表22：キータイプの機能
IANA has added a new column in the "COSE Algorithms" registry. The new column is labeled "Capabilities" and has been populated with "[kty]" for all current, nonprovisional registrations.
IANAは「COSE Algorithms」レジストリに新しい列を追加しました。新しい列は「Capabilities」とラベル付けされ、すべての現在の非プロビジョニング登録に対して「[kty]」が入力されています。
IANA has updated the Reference column in the "COSE Algorithms" registry to include this document as a reference for all rows where it was not already present.
IANAは、「COSE Algorithms」レジストリの「Reference」列を更新し、この文書を参照として追加しました。それが既に存在していないすべての行について。
IANA has added a new row to the "COSE Algorithms" registry.
IANAは「COSE Algorithms」レジストリに新しい行を追加しました。
+===============+=======+===============+===========+=============+
| Name | Value | Description | Reference | Recommended |
+===============+=======+===============+===========+=============+
| IV-GENERATION | 34 | For doing IV | RFC 9053 | No |
| | | generation | | |
| | | for symmetric | | |
| | | algorithms. | | |
+---------------+-------+---------------+-----------+-------------+
Table 23: New entry in the COSE Algorithms registry
表23：COSEアルゴリズムレジストリへの新規エントリ
The Capabilities column for this registration is to be empty.
この登録の「Capabilities」列は空白にする必要があります。
IANA has modified the description to "Public Key" for the line with "Key Type" of 1 and the "Name" of "x". See Table 20, which has been modified with this change.
IANAは、「Key Type」が1で「Name」が「x」の行の説明を「公開鍵」に変更しました。この変更が加えられたTable 20を参照してください。
All of the IANA registries established by [RFC8152] are, at least in part, defined as Expert Review [RFC8126]. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.
[RFC8152] で設立されたすべての IANA レジストリは、少なくとも部分的には Expert Review [RFC8126] として定義されています。このセクションでは、専門家が何を探しているかについて一般的なガイドラインを示していますが、彼らは理由があって専門家として指定されているため、かなりの裁量を与えられるべきです。
Expert reviewers should take the following into consideration:
専門家のレビュアーは、以下を考慮すべきです。
* Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate an existing registration and that the code point is likely to be used in deployments. The ranges tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.
* ポイント・スクワッティングは desu されるべきではありません。レビュアーは、登録リクエストのために十分な情報を取得するように奨励され、使用が既存の登録と重複しないこと、およびコードポイントが展開で使用される可能性が高いことを確認するようにしてください。プライベート・ユースとしてタグ付けされた範囲は、テスト目的および閉じられた環境向けです。他の範囲のコードポイントはテスト用に割り当てられるべきではありません。
* Standards Track or BCP RFCs are required to register a code point in the Standards Action range. Specifications should exist for Specification Required ranges, but early assignment before an RFC is available is considered to be permissible. Specifications are needed for the first-come, first-served range if the points are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
* Standards TrackまたはBCP RFCは、Standards Action範囲でコードポイントを登録する必要があります。Specification Required範囲には仕様が存在する必要がありますが、RFCが利用可能になる前の早期割り当ては許容されると見なされます。仕様が提供されていない場合、提供された説明には、ポイントがどのように使用されているかを識別するための十分な情報が必要です。
* Experts should take into account the expected usage of fields when approving code point assignment. The fact that the Standards Action range is only available to Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left and the size of device it will be used on.
* 専門家は、コードポイントの割り当てを承認する際に、フィールドの予想される使用法を考慮すべきです。標準アクション範囲が標準トラックドキュメントにのみ利用可能であるという事実は、標準トラックドキュメントがその範囲外にポイントを割り当てることができないことを意味しません。符号化された値の長さは、その長さのコードポイントが残っている数と、それが使用されるデバイスのサイズに対して検討されるべきです。
* When algorithms are registered, vanity registrations should be discouraged. One way to do this is to require registrations to provide additional documentation on security analysis of the algorithm. Another thing that should be considered is requesting an opinion on the algorithm from the Crypto Forum Research Group (CFRG). Algorithms are expected to meet the security requirements of the community and the requirements of the message structures in order to be suitable for registration.
* アルゴリズムが登録される際には、虚栄心に基づく登録は desu されるべきではありません。これを防ぐ方法の一つは、アルゴリズムのセキュリティ分析に関する追加の文書提出を求めることです。また、アルゴリズムについて Crypto Forum Research Group (CFRG) からの意見を求めることも検討すべきです。アルゴリズムは、コミュニティのセキュリティ要件とメッセージ構造の要件を満たすことが期待され、登録に適しているとされます。
There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additional considerations may be found in the documents listed in the references.
この仕様を実装する際に考慮すべきセキュリティに関する考慮事項がいくつかあります。個々のアルゴリズムに特有のセキュリティに関する考慮事項は、アルゴリズムの説明の隣に配置されます。ここで強調されている考慮事項もありますが、追加の考慮事項は参照文献にリストされている文書にも見つかるかもしれません。
Implementations need to protect the private key material for all individuals. Some cases in this document need to be highlighted with regard to this issue.
実装はすべての個人の秘密鍵情報を保護する必要があります。この文書の一部については、この問題に関して強調する必要があります。
* Use of the same key for two different algorithms can leak information about the key. It is therefore recommended that keys be restricted to a single algorithm.
* 同じキーを2つの異なるアルゴリズムで使用すると、キーに関する情報が漏洩する可能性があります。そのため、キーは1つのアルゴリズムに制限されることが推奨されています。
* Use of "direct" as a recipient algorithm combined with a second recipient algorithm exposes the direct key to the second recipient; Section 8.5 of [RFC9052] forbids combining "direct" recipient algorithms with other modes.
* 「直接」という受信者アルゴリズムを第二の受信者アルゴリズムと組み合わせることで、直接キーが第二の受信者に露出します。[RFC9052]のセクション8.5は、「直接」受信者アルゴリズムを他のモードと組み合わせることを禁止しています。
* Several of the algorithms in this document have limits on the number of times that a key can be used without leaking information about the key.
* この文書のいくつかのアルゴリズムには、キーが使用される回数に制限があり、キーに関する情報が漏洩することがあります。
The use of ECDH and direct plus KDF (with no key wrap) will not directly lead to the private key being leaked; the one-way function of the KDF will prevent that. There is, however, a different issue that needs to be addressed. Having two recipients requires that the CEK be shared between two recipients. The second recipient therefore has a CEK that was derived from material that can be used for the weak proof of origin. The second recipient could create a message using the same CEK and send it to the first recipient; the first recipient would, for either Static-Static ECDH or direct plus KDF, make an assumption that the CEK could be used for proof of origin, even though it is from the wrong entity. If the key wrap step is added, then no proof of origin is implied and this is not an issue.
ECDHの使用と直接プラスKDF（キーのラップなし）は、秘密鍵が漏洩することに直接つながるわけではありません。KDFの一方向関数がそれを防ぎます。ただし、対処する必要がある別の問題があります。2つの受信者がいる場合、CEKは2つの受信者間で共有される必要があります。したがって、第2の受信者は、弱い起源の証明に使用できる材料から派生したCEKを持っています。第2の受信者は、同じCEKを使用してメッセージを作成し、最初の受信者に送信することができます。最初の受信者は、Static-Static ECDHまたは直接プラスKDFのいずれかの場合、CEKが起源の証明に使用できると仮定するでしょうが、それは誤ったエンティティから来ています。キーのラップステップが追加されると、起源の証明は暗示されず、これは問題ではありません。
Although it has been mentioned before, it bears repeating that the use of a single key for multiple algorithms has been demonstrated in some cases to leak information about a key, providing the opportunity for attackers to forge integrity tags or gain information about encrypted content. Binding a key to a single algorithm prevents these problems. Key creators and key consumers are strongly encouraged to not only create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure. In addition to checking that algorithms are correct, the key form needs to be checked as well. Do not use an "EC2" key where an "OKP" key is expected.
以前に言及されていますが、1つのキーを複数のアルゴリズムに使用することは、いくつかのケースでキーに関する情報を漏洩させる可能性があることが示されており、攻撃者が整合性タグを偽造したり、暗号化されたコンテンツに関する情報を入手する機会を提供しています。キーを1つのアルゴリズムにバインドすることで、これらの問題を防ぐことができます。キーの作成者とキーの利用者は、異なるアルゴリズムごとに新しいキーを作成するだけでなく、そのアルゴリズムの選択をキー素材の配布に含め、キー構造内のアルゴリズムとメッセージ構造内のアルゴリズムを厳密に一致させることを強くお勧めします。アルゴリズムが正しいかどうかを確認するだけでなく、キー形式も確認する必要があります。期待される"OKP"キーの場所で"EC2"キーを使用しないでください。
Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made. Is the data or action something that the entity associated with the key has a right to see or a right to request? A number of factors are associated with this trust decision. Some highlighted here are:
鍵を使用して情報を送信する前、または受信した情報に対して行動する前に、鍵に関する信頼決定を行う必要があります。データや行動が、鍵に関連するエンティティが見る権利や要求する権利があるものであるかどうか。この信頼決定にはいくつかの要因が関連しています。ここで強調されているいくつかは次のとおりです：
* What are the permissions associated with the key owner?
* キー所有者に関連付けられた権限は何ですか？
* Is the cryptographic algorithm acceptable in the current context?
* 現在のコンテキストで暗号化アルゴリズムは受け入れ可能ですか？
* Have the restrictions associated with the key, such as algorithm or freshness, been checked, and are they correct?
* 鍵に関連する制限事項（アルゴリズムや新鮮さなど）が確認され、正しいですか？
* Is the request something that is reasonable, given the current state of the application?
* 現在のアプリケーションの状態を考えると、そのリクエストは妥当なものですか？
* Have any security considerations that are part of the message been enforced (as specified by the application or "crit" header parameter)?
* メッセージの一部として指定されたセキュリティ考慮事項は適用されていますか（アプリケーションまたは "crit" ヘッダーパラメーターで指定されたものに従って）？
There are a large number of algorithms presented in this document that use nonce values. For all of the nonces defined in this document, there is some type of restriction on the nonce being a unique value for either a key or some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable; under these circumstances, it's reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be unpredictable as well as unique, one can use a key created for that purpose and encrypt the counter to produce the nonce value.
この文書には、ノンス値を使用する多数のアルゴリズムが示されています。この文書で定義されたすべてのノンスには、キーまたはその他の条件に対してノンスが一意の値であるという制限があります。これらのケースでは、ノンスが一意かつ予測不可能である必要はなく、そのような状況下では、ノンスの作成にカウンターを使用することが合理的です。ノンスのパターンを予測不可能かつ一意にしたい場合は、その目的のために作成されたキーを使用して、カウンターを暗号化してノンス値を生成することができます。
One area that has been getting exposure is traffic analysis of encrypted messages based on the length of the message. This specification does not provide a uniform method for providing padding as part of the message structure. An observer can distinguish between two different messages (for example, "YES" and "NO") based on the length for all of the content encryption algorithms that are defined in this document. This means that it is up to the applications to document how content padding is to be done in order to prevent or discourage such analysis. (For example, the text strings could be defined as "YES" and "NO ".)
暗号化されたメッセージのトラフィック解析が注目されている分野の1つは、メッセージの長さに基づいています。この仕様では、メッセージ構造の一部としてパディングを提供するための一貫した方法を提供していません。この文書で定義されているすべてのコンテンツ暗号化アルゴリズムに基づいて、観察者は2つの異なるメッセージ（たとえば、「YES」と「NO」）を区別することができます。つまり、アプリケーションがどのようにコンテンツのパディングを行うかを文書化することが、そのような解析を防止または妨げるために必要です。（たとえば、テキスト文字列を「YES」と「NO 」と定義できます。）
The analysis done in [RFC9147] is based on the number of records that are sent. This should map well to the number of messages sent when using COSE, so that analysis should hold here as well, under the assumption that the COSE messages are roughly the same size as DTLS records. It needs to be noted that the limits are based on the number of messages, but QUIC and DTLS are always pairwise-based endpoints. In contrast, [OSCORE-GROUPCOMM] uses COSE in a group communication scenario. Under these circumstances, it may be that no one single entity will see all of the messages that are encrypted, and therefore no single entity can trigger the rekey operation.
[RFC9147]で行われた分析は送信されるレコードの数に基づいています。これはCOSEを使用する際に送信されるメッセージの数に適合するはずなので、COSEメッセージがDTLSレコードとほぼ同じサイズであると仮定すると、この分析はここでも成立するはずです。制限はメッセージの数に基づいていることに注意する必要がありますが、QUICとDTLSは常にペアベースのエンドポイントです。一方、[OSCORE-GROUPCOMM]はグループ通信シナリオでCOSEを使用しています。このような状況下では、暗号化されたすべてのメッセージを見ることができる単一のエンティティがいない可能性があり、したがって単一のエンティティが再鍵操作をトリガーすることはできません。
[AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
November 2007, <https://csrc.nist.gov/publications/
nistpubs/800-38D/SP-800-38D.pdf>.
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[MAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press, Boca Raton, 1996,
<https://cacr.uwaterloo.ca/hac/>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography, May 2009,
<https://www.secg.org/sec1-v2.pdf>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/std94>.
[CFRG-DET-SIGS]
Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
"Deterministic ECDSA and EdDSA Signatures with Additional
Randomness", Work in Progress, Internet-Draft, draft-
mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022,
<https://datatracker.ietf.org/doc/html/draft-mattsson-
cfrg-det-sigs-with-noise-04>.
[COUNTERSIGN]
Schaad, J. and R. Housley, "CBOR Object Signing and
Encryption (COSE): Countersignatures", Work in Progress,
Internet-Draft, draft-ietf-cose-countersign-08, 22 August
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
cose-countersign-08>.
[GitHub-Examples]
"GitHub Examples of COSE", commit 3221310, 3 June 2020,
<https://github.com/cose-wg/Examples>.
[HKDF] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", 2010,
<https://eprint.iacr.org/2010/264.pdf>.
[OSCORE-GROUPCOMM]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group OSCORE - Secure Group Communication
for CoAP", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-groupcomm-14, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-groupcomm-14>.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005,
<https://www.rfc-editor.org/info/rfc4231>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
and Encryption (COSE) Messages", RFC 8230,
DOI 10.17487/RFC8230, September 2017,
<https://www.rfc-editor.org/info/rfc8230>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature
Algorithm with CBOR Object Signing and Encryption (COSE)",
RFC 8778, DOI 10.17487/RFC8778, April 2020,
<https://www.rfc-editor.org/info/rfc8778>.
[RFC9021] Atkins, D., "Use of the Walnut Digital Signature Algorithm
with CBOR Object Signing and Encryption (COSE)", RFC 9021,
DOI 10.17487/RFC9021, May 2021,
<https://www.rfc-editor.org/info/rfc9021>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust
Channels: Handling Unreliable Networks in the Record
Layers of QUIC and DTLS", February 2020,
<https://eprint.iacr.org/2020/718.pdf>.
[SP800-38D]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, November 2007,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38d.pdf>.
[SP800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography", NIST
Special Publication 800-56A, Revision 3,
DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
[STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/std90>.
This document is a product of the COSE Working Group of the IETF.
このドキュメントはIETFのCOSE Working Groupの成果物です。
The following individuals are to blame for getting me started on this project in the first place: Richard Barnes, Matt Miller, and Martin Thomson.
次の個人が最初にこのプロジェクトを始める原因となった責任があります：Richard Barnes、Matt Miller、およびMartin Thomson。
The initial draft version of the specification was based to some degree on the outputs of the JOSE and S/MIME Working Groups.
仕様の初期ドラフトバージョンは、ある程度、JOSEおよびS/MIMEワーキンググループの成果に基づいていました。
The following individuals provided input into the final form of the document: Carsten Bormann, John Bradley, Brian Campbell, Michael B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and Göran Selander.
次の個人が文書の最終形に入力を提供しました：Carsten Bormann、John Bradley、Brian Campbell、Michael B. Jones、Ilari Liusvaara、Francesca Palombini、Ludwig Seitz、およびGöran Selander。
Jim Schaad
August Cellars