[要約] RFC 8418は、Elliptic Curve Diffie-Hellman (ECDH) キー合意アルゴリズムを、X25519およびX448曲線を使用してCryptographic Message Syntax (CMS)で利用する方法について定義しています。この文書の目的は、安全な鍵交換メカニズムを提供し、デジタル署名、暗号化、認証などのセキュリティサービスを強化することにあります。主にセキュアなメッセージング、データ保護、システム間通信のセキュリティ強化に利用されます。関連するRFCには、RFC 5280 (X.509の公開鍵インフラストラクチャ) や RFC 5753 (CMSの使用に関するガイドライン) などがあります。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8418 Vigil Security
Category: Standards Track August 2018
ISSN: 2070-1721
Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)
暗号メッセージ構文（CMS）におけるX25519およびX448での楕円曲線Diffie-Hellman鍵合意アルゴリズムの使用
Abstract
概要
This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).
このドキュメントでは、暗号化メッセージ構文（CMS）で、curve25519およびcurve448で楕円曲線Diffie-Hellman（ECDH）鍵合意アルゴリズムを使用するための規則について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8418.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8418で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. ASN.1 ......................................................3
2. Key Agreement ...................................................3
2.1. ANSI-X9.63-KDF .............................................4
2.2. HKDF .......................................................5
3. Enveloped-data Conventions ......................................5
3.1. EnvelopedData Fields .......................................6
3.2. KeyAgreeRecipientInfo Fields ...............................6
4. Authenticated-data Conventions ..................................7
4.1. AuthenticatedData Fields ...................................8
4.2. KeyAgreeRecipientInfo Fields ...............................8
5. Authenticated-enveloped-data Conventions ........................8
5.1. AuthEnvelopedData Fields ...................................8
5.2. KeyAgreeRecipientInfo Fields ...............................8
6. Certificate Conventions .........................................9
7. Key Agreement Algorithm Identifiers .............................9
8. SMIMECapabilities Attribute Conventions ........................10
9. Security Considerations ........................................11
10. IANA Considerations ...........................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
Appendix A. ASN.1 Module ..........................................16
Acknowledgements ..................................................18
Author's Address ..................................................18
This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement using curve25519 and curve448 [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key agreement is supported in three CMS content types: the enveloped-data content type [CMS], authenticated-data content type [CMS], and the authenticated-enveloped-data content type [AUTHENV].
このドキュメントでは、Cryptographic Message Syntax（CMS）[CMS]でcurve25519およびcurve448 [CURVES]を使用して楕円曲線Diffie-Hellman（ECDH）鍵合意を使用するための規則について説明します。鍵合意は、3つのCMSコンテンツタイプ（エンベロープデータコンテンツタイプ[CMS]、認証済みデータコンテンツタイプ[CMS]、および認証済みエンベロープデータコンテンツタイプ[AUTHENV]）でサポートされています。
The conventions for using some Elliptic Curve Cryptography (ECC) algorithms in CMS are described in [CMSECC]. These conventions cover the use of ECDH with some curves other than curve25519 and curve448 [CURVES]. Those other curves are not deprecated.
CMSでいくつかの楕円曲線暗号（ECC）アルゴリズムを使用するための規則は、[CMSECC]で説明されています。これらの規則は、curve25519およびcurve448 [CURVES]以外のいくつかの曲線でのECDHの使用をカバーしています。これらの他の曲線は非推奨ではありません。
Using curve25519 with Diffie-Hellman key agreement is referred to as "X25519". Using curve448 with Diffie-Hellman key agreement is referred to as "X448".
Diffie-Hellman鍵合意でcurve25519を使用することは、「X25519」と呼ばれます。 Diffie-Hellman鍵合意でcurve448を使用することを「X448」と呼びます。
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]で説明されているように解釈されます。
CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
CMS値は、ASN.1 [X680]を使用して生成されます。ASN.1は、基本エンコーディングルール（BER）およびDistinguished Encodingルール（DER）[X690]を使用します。
In 1976, Diffie and Hellman described a means for two parties to agree upon a shared secret value in a manner that prevents eavesdroppers from learning the shared secret value [DH1976]. This secret may then be converted into pairwise symmetric keying material for use with other cryptographic algorithms. Over the years, many variants of this fundamental technique have been developed. This document describes the conventions for using Ephemeral-Static Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and X448 [CURVES].
1976年に、DiffieとHellmanは、盗聴者が共有秘密値を学習できないように共有秘密値に合意するための2つの当事者のための手段を説明しました[DH1976]。このシークレットは、他の暗号化アルゴリズムで使用するためにペアワイズ対称キーイングマテリアルに変換できます。長年にわたって、この基本的な技術の多くの変形が開発されてきました。このドキュメントでは、X25519とX448を使用したエフェメラル静的楕円曲線Diffie-Hellman（ECDH）鍵協定を使用するための規則について説明します[曲線]。
The originator MUST use an ephemeral public/private key pair that is generated on the same elliptic curve as the public key of the recipient. The ephemeral key pair MUST be used for a single CMS-protected content type, and then it MUST be discarded. The originator obtains the recipient's static public key from the recipient's certificate [PROFILE].
発信者は、受信者の公開鍵と同じ楕円曲線上に生成される一時的な公開鍵と秘密鍵のペアを使用する必要があります。エフェメラルキーペアは、CMSで保護された単一のコンテンツタイプに使用する必要があり、破棄する必要があります。発信者は、受信者の証明書[PROFILE]から受信者の静的公開鍵を取得します。
X25519 is described in Section 6.1 of [CURVES], and X448 is described in Section 6.2 of [CURVES]. Conforming implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value, and abort if so, as described in Section 6 of [CURVES]. If an alternative implementation of these elliptic curves to that documented in Section 6 of [CURVES] is employed, then the additional checks specified in Section 7 of [CURVES] SHOULD be performed.
X25519は[CURVES]のセクション6.1で説明されており、X448は[CURVES]のセクション6.2で説明されています。準拠する実装は、[CURVES]のセクション6で説明されているように、計算されたDiffie-Hellman共有秘密がすべてゼロの値であるかどうかをチェックし、そうである場合は中止する必要があります。 [CURVES]のセクション6に記載されている楕円曲線の代替実装が採用されている場合、[CURVES]のセクション7で指定されている追加のチェックを実行する必要があります（SHOULD）。
In [CURVES], the shared secret value that is produced by ECDH is called K. (In some other specifications, the shared secret value is called Z.) A Key Derivation Function (KDF) is used to produce a pairwise key-encryption key (KEK) from the shared secret value (K), the length of the KEK, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC].
[CURVES]では、ECDHによって生成される共有秘密値はKと呼ばれます（他の一部の仕様では、共有秘密値はZと呼ばれます）。鍵導出関数（KDF）は、ペアワイズ鍵暗号鍵を生成するために使用されます（KEK）共有秘密値（K）、KEKの長さ、およびDERエンコードされたECC-CMS-SharedInfo構造[CMSECC]から。
The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for convenience.
[CMSECC]のECC-CMS-SharedInfo定義は、便宜上ここで繰り返されます。
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
The ECC-CMS-SharedInfo keyInfo field contains the object identifier of the key-encryption algorithm and associated parameters. This algorithm will be used to wrap the content-encryption key. For example, the AES Key Wrap algorithm [AESKW] does not need parameters, so the algorithm identifier parameters are absent.
ECC-CMS-SharedInfo keyInfoフィールドには、キー暗号化アルゴリズムのオブジェクト識別子と関連パラメーターが含まれています。このアルゴリズムは、コンテンツ暗号化キーをラップするために使用されます。たとえば、AESキーラップアルゴリズム[AESKW]はパラメーターを必要としないため、アルゴリズム識別子パラメーターはありません。
The ECC-CMS-SharedInfo entityUInfo field optionally contains additional keying material supplied by the sending agent. Note that [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If the ukm field is present, the ukm is placed in the entityUInfo field. By including the ukm, a different KEK is generated even when the originator ephemeral private key is improperly used more than once. Therefore, if the ukm field is present, it MUST be selected in a manner that provides, with very high probability, a unique value; however, there is no security benefit to using a ukm value that is longer than the KEK that will be produced by the KDF.
ECC-CMS-SharedInfoのentityUInfoフィールドには、オプションで、送信エージェントから提供された追加のキー情報が含まれます。 [CMS]では、実装がukmフィールドを含むKeyAgreeRecipientInfo SEQUENCEを受け入れる必要があることに注意してください。 ukmフィールドが存在する場合、ukmはentityUInfoフィールドに配置されます。 ukmを含めることにより、発信元の一時的な秘密鍵が誤って複数回使用された場合でも、別のKEKが生成されます。したがって、ukmフィールドが存在する場合、非常に高い確率で一意の値を提供する方法で選択する必要があります。ただし、KDFによって生成されるKEKよりも長いukm値を使用しても、セキュリティ上の利点はありません。
The ECC-CMS-SharedInfo suppPubInfo field contains the length of the generated KEK, in bits, represented as a 32-bit number in network byte order. For example, the key length for AES-256 [AES] would be 0x00000100.
ECC-CMS-SharedInfo suppPubInfoフィールドには、生成されたKEKの長さがビット単位で含まれ、ネットワークバイトオーダーの32ビット数として表されます。たとえば、AES-256 [AES]のキーの長さは0x00000100になります。
The ANSI-X9.63-KDF key derivation function is a simple construct based on a one-way hash function described in American National Standard X9.63 [X963]. This KDF is also described in Section 3.6.1 of [SEC1].
ANSI-X9.63-KDF鍵導出関数は、米国国家規格X9.63 [X963]で説明されている一方向ハッシュ関数に基づく単純な構造です。このKDFは、[SEC1]のセクション3.6.1でも説明されています。
Three values are concatenated to produce the input string to the KDF: 1. The shared secret value generated by ECDH, K. 2. The iteration counter, starting with one, as described below. 3. The DER-encoded ECC-CMS-SharedInfo structure.
3つの値が連結されて、KDFへの入力文字列が生成されます。1. ECDHによって生成された共有秘密値K。2。以下で説明するように、1から始まる反復カウンター。 3. DERエンコードされたECC-CMS-SharedInfo構造。
To generate a key-encryption key (KEK), the KDF generates one or more keying material (KM) blocks, with the counter starting at 0x00000001, and incrementing the counter for each subsequent KM block until enough material has been generated. The 32-bit counter is represented in network byte order. The KM blocks are concatenated left to right, and then the leftmost portion of the result is used as the pairwise key-encryption key, KEK:
キー暗号化キー（KEK）を生成するために、KDFは1つ以上のキーイングマテリアル（KM）ブロックを生成します。カウンターは0x00000001から始まり、十分なマテリアルが生成されるまで後続の各KMブロックのカウンターをインクリメントします。 32ビットカウンターは、ネットワークバイトオーダーで表されます。 KMブロックは左から右に連結され、結果の左端の部分がペアワイズキー暗号化キーKEKとして使用されます。
KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))
KEK = KM(counter=1) || KM(counter=2) ...
KEK = KM（カウンター= 1）|| KM（カウンター= 2）...
The Extract-and-Expand HMAC-based Key Derivation Function (HKDF) is a robust construct based on a one-way hash function described in RFC 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed by HKDF-Expand.
Extract-and-Expand HMAC-based Key Derivation Function（HKDF）は、RFC 5869 [HKDF]で説明されている一方向ハッシュ関数に基づく堅牢な構造です。 HKDFは、HKDF-Extractに続いてHKDF-Expandの2つのステップで構成されます。
Three values are used as inputs to the HKDF: 1. The shared secret value generated by ECDH, K. 2. The length in octets of the keying data to be generated. 3. The DER-encoded ECC-CMS-SharedInfo structure.
3つの値がHKDFへの入力として使用されます。1. ECDH、Kによって生成された共有秘密値。2.生成されるキーイングデータのオクテット単位の長さ。 3. DERエンコードされたECC-CMS-SharedInfo構造。
The ECC-CMS-SharedInfo structure optionally includes the ukm. If the ukm is present, the ukm is also used as the HKDF salt. HKDF uses an appropriate number of zero octets when no salt is provided.
ECC-CMS-SharedInfo構造には、オプションでukmが含まれます。 ukmが存在する場合、ukmはHKDFソルトとしても使用されます。ソルトが提供されない場合、HKDFは適切な数のゼロオクテットを使用します。
The length of the generated KEK is used in two places, once in bits and once in octets. The ECC-CMS-SharedInfo structure includes the length of the generated KEK in bits. The HKDF-Expand function takes an argument for the length of the generated KEK in octets.
生成されたKEKの長さは、ビットとオクテットの2か所で使用されます。 ECC-CMS-SharedInfo構造には、生成されたKEKの長さがビット単位で含まれます。 HKDF-Expand関数は、生成されたKEKの長さのオクテット単位の引数を取ります。
In summary, to produce the pairwise key-encryption key, KEK:
要約すると、ペアワイズキー暗号化キーKEKを生成するには、次のようにします。
if ukm is provided, then salt = ukm, else salt is not provided PRK = HKDF-Extract(salt, K)
ukmが指定されている場合、salt = ukm、そうでない場合、saltは提供されませんPRK = HKDF-Extract（salt、K）
KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))
The CMS enveloped-data content type [CMS] consists of an encrypted content and wrapped content-encryption keys for one or more recipients. The ECDH key agreement algorithm is used to generate a pairwise KEK between the originator and a particular recipient. Then, the KEK is used to wrap the content-encryption key for that recipient. When there is more than one recipient, the same content-encryption key MUST be wrapped for each of them.
CMSエンベロープデータコンテンツタイプ[CMS]は、暗号化されたコンテンツと、1人以上の受信者用のラップされたコンテンツ暗号化キーで構成されます。 ECDH鍵合意アルゴリズムは、発信者と特定の受信者の間でペアワイズKEKを生成するために使用されます。次に、KEKを使用して、その受信者のコンテンツ暗号化キーをラップします。受信者が複数いる場合は、それぞれに同じコンテンツ暗号化キーをラップする必要があります。
A compliant implementation MUST meet the requirements for constructing an enveloped-data content type in Section 6 of [CMS].
準拠した実装は、[CMS]のセクション6でエンベロープデータコンテンツタイプを構築するための要件を満たさなければなりません（MUST）。
A content-encryption key MUST be randomly generated for each instance of an enveloped-data content type. The content-encryption key is used to encrypt the content.
コンテンツ暗号化キーは、エンベロープデータコンテンツタイプのインスタンスごとにランダムに生成する必要があります。コンテンツ暗号化キーは、コンテンツを暗号化するために使用されます。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as described in Section 6 of [CMS]. The RecipientInfo choice is described in Section 6.2 of [CMS], and repeated here for convenience.
エンベロープデータコンテンツタイプは、EnvelopedData構文を使用してエンコードされたASN.1です。 EnvelopedData構文のフィールドは、[CMS]のセクション6で説明されているように入力する必要があります。 RecipientInfoの選択については、[CMS]のセクション6.2で説明されており、便宜上ここで繰り返されています。
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
For the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used.
X25519またはX448を使用する受信者には、RecipientInfo kariの選択を使用する必要があります。
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in this section when X25519 or X448 is employed for one or more recipients.
KeyAgreeRecipientInfo構文のフィールドは、1つ以上の受信者にX25519またはX448が採用されている場合、このセクションで説明されているように入力する必要があります。
The KeyAgreeRecipientInfo version MUST be 3.
KeyAgreeRecipientInfoのバージョンは3でなければなりません。
The KeyAgreeRecipientInfo originator provides three alternatives for identifying the originator's public key, and the originatorKey alternative MUST be used. The originatorKey MUST contain an ephemeral key for the originator. The originatorKey algorithm field MUST contain the id-X25519 or the id-X448 object identifier. The originator's ephemeral public key MUST be encoded as an OCTET STRING.
KeyAgreeRecipientInfoオリジネーターは、オリジネーターの公開鍵を識別するための3つの代替手段を提供し、originatorKey代替手段を使用する必要があります。 originatorKeyには、発信元の一時キーが含まれている必要があります。 originatorKeyアルゴリズムフィールドには、id-X25519またはid-X448オブジェクト識別子を含める必要があります。発信者の一時的な公開鍵は、OCTET STRINGとしてエンコードする必要があります。
The object identifiers for X25519 and X448 have been assigned in [RFC8410]. They are repeated below for convenience.
X25519とX448のオブジェクト識別子は[RFC8410]で割り当てられています。便宜上、以下に繰り返します。
When using X25519, the public key contains exactly 32 octets, and the id-X25519 object identifier is used:
X25519を使用する場合、公開鍵には正確に32オクテットが含まれ、id-X25519オブジェクト識別子が使用されます。
id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
When using X448, the public key contains exactly 56 octets, and the id-X448 object identifier is used:
X448を使用する場合、公開鍵には正確に56オクテットが含まれ、id-X448オブジェクト識別子が使用されます。
id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
KeyAgreeRecipientInfo ukm is optional. The processing of the ukm with the ANSI-X9.63-KDF key derivation function is described in Section 2.1, and the processing of the ukm with the HKDF key derivation function is described in Section 2.2.
KeyAgreeRecipientInfo ukmはオプションです。 ANSI-X9.63-KDF鍵導出関数を使用したukmの処理については2.1節で説明し、HKDF鍵導出関数を使用したukmの処理については2.2節で説明します。
The KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm that will be used to wrap the content-encryption key. The conventions for using AES-128, AES-192, and AES-256 in the key wrap mode are specified in [CMSAES].
KeyAgreeRecipientInfo keyEncryptionAlgorithmには、コンテンツ暗号化キーのラップに使用されるキー暗号化アルゴリズムのオブジェクト識別子が含まれている必要があります。キーラップモードでAES-128、AES-192、およびAES-256を使用するための規則は、[CMSAES]で指定されています。
The KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient identifier and encrypted key for one or more recipients. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static X25519 or X448 public key. The RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
KeyAgreeRecipientInfo recipientEncryptedKeysには、1人以上の受信者の受信者識別子と暗号化されたキーが含まれています。 RecipientEncryptedKey KeyAgreeRecipientIdentifierには、受信者の証明書を識別するissuerAndSerialNumberまたは受信者の証明書のサブジェクトキー識別子を含むRecipientKeyIdentifierのいずれかが含まれている必要があります。どちらの場合も、受信者の証明書には、受信者の静的なX25519またはX448公開鍵が含まれています。 RecipientEncryptedKey EncryptedKeyには、KeyWrapAlgorithmで指定されたアルゴリズムを使用してペアワイズキー暗号化キーで暗号化されたコンテンツ暗号化キーを含める必要があります。
The CMS authenticated-data content type [CMS] consists of an authenticated content, a message authentication code (MAC), and encrypted authentication keys for one or more recipients. The ECDH key agreement algorithm is used to generate a pairwise KEK between the originator and a particular recipient. Then, the KEK is used to wrap the authentication key for that recipient. When there is more than one recipient, the same authentication key MUST be wrapped for each of them.
CMS認証データコンテンツタイプ[CMS]は、認証されたコンテンツ、メッセージ認証コード（MAC）、および1人以上の受信者用の暗号化された認証キーで構成されます。 ECDH鍵合意アルゴリズムは、発信者と特定の受信者の間でペアワイズKEKを生成するために使用されます。次に、KEKを使用して、その受信者の認証キーをラップします。受信者が複数いる場合は、それぞれに対して同じ認証キーをラップする必要があります。
A compliant implementation MUST meet the requirements for constructing an authenticated-data content type in Section 9 of [CMS].
準拠した実装は、[CMS]のセクション9の認証済みデータコンテンツタイプを構築するための要件を満たさなければならない（MUST）。
An authentication key MUST be randomly generated for each instance of an authenticated-data content type. The authentication key is used to compute the MAC over the content.
認証キーは、authenticated-dataコンテンツタイプのインスタンスごとにランダムに生成する必要があります。認証キーは、コンテンツのMACを計算するために使用されます。
The authenticated-data content type is ASN.1 encoded using the AuthenticatedData syntax. The fields of the AuthenticatedData syntax MUST be populated as described in [CMS]; for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used.
authentication-dataコンテンツタイプは、AuthenticatedData構文を使用してエンコードされたASN.1です。 AuthenticatedData構文のフィールドは、[CMS]で説明されているように入力する必要があります。 X25519またはX448を使用する受信者には、RecipientInfo kariの選択を使用する必要があります。
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in Section 3.2 of this document.
KeyAgreeRecipientInfo構文のフィールドは、このドキュメントのセクション3.2で説明されているように入力する必要があります。
The CMS authenticated-enveloped-data content type [AUTHENV] consists of an authenticated and encrypted content and encrypted content-authenticated-encryption keys for one or more recipients. The ECDH key agreement algorithm is used to generate a pairwise KEK between the originator and a particular recipient. Then, the KEK is used to wrap the content-authenticated-encryption key for that recipient. When there is more than one recipient, the same content-authenticated-encryption key MUST be wrapped for each of them.
CMS authentication-enveloped-dataコンテンツタイプ[AUTHENV]は、1人以上の受信者に対する認証および暗号化されたコンテンツと暗号化されたコンテンツ認証済み暗号化キーで構成されます。 ECDH鍵合意アルゴリズムは、発信者と特定の受信者の間でペアワイズKEKを生成するために使用されます。次に、KEKを使用して、その受信者のcontent-authenticated-encryptionキーをラップします。受信者が複数いる場合は、それぞれのコンテンツ認証済み暗号化キーをラップする必要があります。
A compliant implementation MUST meet the requirements for constructing an authenticated-data content type in Section 2 of [AUTHENV].
準拠した実装は、[AUTHENV]のセクション2の認証データコンテンツタイプを構築するための要件を満たさなければならない（MUST）。
A content-authenticated-encryption key MUST be randomly generated for each instance of an authenticated-enveloped-data content type. The content-authenticated-encryption key is used to authenticate and encrypt the content.
content-authenticated-encryptionキーは、authenticated-enveloped-dataコンテンツタイプのインスタンスごとにランダムに生成する必要があります。 content-authenticated-encryptionキーは、コンテンツの認証と暗号化に使用されます。
The authenticated-enveloped-data content type is ASN.1 encoded using the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData syntax MUST be populated as described in [AUTHENV]; for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used.
authentication-enveloped-dataコンテンツタイプは、AuthEnvelopedData構文を使用してエンコードされたASN.1です。 AuthEnvelopedData構文のフィールドは、[AUTHENV]で説明されているように入力する必要があります。 X25519またはX448を使用する受信者には、RecipientInfo kariの選択を使用する必要があります。
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in Section 3.2 of this document.
KeyAgreeRecipientInfo構文のフィールドは、このドキュメントのセクション3.2で説明されているように入力する必要があります。
RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates in Internet applications. A recipient static public key is needed for X25519 or X448, and the originator obtains that public key from the recipient's certificate. The conventions for carrying X25519 and X448 public keys are specified in [RFC8410].
RFC 5280 [PROFILE]は、インターネットアプリケーションでX.509証明書を使用するためのプロファイルを指定しています。 X25519またはX448には受信者の静的公開鍵が必要であり、発信者は受信者の証明書からその公開鍵を取得します。 X25519およびX448公開鍵を運ぶための規則は、[RFC8410]で指定されています。
The following object identifiers are assigned in [CMSECC] to indicate ECDH with ANSI-X9.63-KDF using various one-way hash functions. These are expected to be used as AlgorithmIdentifiers with a parameter that specifies the key-encryption algorithm. These are repeated here for convenience.
[CMSECC]では、さまざまな一方向ハッシュ関数を使用してANSI-X9.63-KDFでECDHを示す次のオブジェクト識別子が割り当てられています。これらは、鍵暗号化アルゴリズムを指定するパラメーターを持つAlgorithmIdentifiersとして使用されることが期待されています。これらは、便宜上ここで繰り返されます。
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
The following object identifiers are assigned to indicate ECDH with HKDF using various one-way hash functions. These are expected to be used as AlgorithmIdentifiers with a parameter that specifies the key-encryption algorithm.
次のオブジェクト識別子は、さまざまな一方向ハッシュ関数を使用してHKDFでECDHを示すために割り当てられます。これらは、鍵暗号化アルゴリズムを指定するパラメーターを持つAlgorithmIdentifiersとして使用されることが期待されています。
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
A sending agent MAY announce to other agents that it supports ECDH key agreement using the SMIMECapabilities signed attribute in a signed message [SMIME] or a certificate [CERTCAP]. Following the pattern established in [CMSECC], the SMIMECapabilities associated with ECDH carries a DER-encoded object identifier that identifies support for ECDH in conjunction with a particular KDF, and it includes a parameter that names the key wrap algorithm.
送信エージェントは、署名されたメッセージ[SMIME]または証明書[CERTCAP]のSMIMECapabilities署名属性を使用してECDH鍵合意をサポートすることを他のエージェントに通知してもよい（MAY）。 [CMSECC]で確立されたパターンに従って、ECDHに関連付けられたSMIMECapabilitiesは、特定のKDFと組み合わせたECDHのサポートを識別するDERエンコードされたオブジェクト識別子を伝達し、キーラップアルゴリズムに名前を付けるパラメーターを含みます。
The following SMIMECapabilities values (in hexadecimal) from [CMSECC] might be of interest to implementations that support X25519 and X448:
[CMSECC]からの次のSMIMECapabilities値（16進数）は、X25519およびX448をサポートする実装に関係している可能性があります。
ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 05
SHA-256を使用するANSI-X9.63-KDFを備えたECDH; AES-128キーラップを使用：30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECHAとANSI-X9.63-KDF、SHA-384を使用。 AES-128キーラップを使用：30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 05
SHA-512を使用するANSI-X9.63-KDFを使用するECDH。 AES-128キーラップを使用：30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 2D
SHA-256を使用するANSI-X9.63-KDFを備えたECDH; AES-256キーラップを使用：30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECHAとANSI-X9.63-KDF、SHA-384を使用。 AES-256キーラップを使用：30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 2D
SHA-512を使用するANSI-X9.63-KDFを使用するECDH。 AES-256キーラップを使用：30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 2D
The following SMIMECapabilities values (in hexadecimal) based on the algorithm identifiers in Section 7 of this document might be of interest to implementations that support X25519 and X448:
このドキュメントのセクション7のアルゴリズム識別子に基づく次のSMIMECapabilities値（16進数）は、X25519およびX448をサポートする実装に関係している可能性があります。
ECDH with HKDF using SHA-256; uses AES-128 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 05
SHA-256を使用したECDFとHKDF。 AES-128キーラップを使用：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with HKDF using SHA-384; uses AES-128 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECHAとSHA-384を使用したHKDF。 AES-128キーラップを使用：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with HKDF using SHA-512; uses AES-128 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 05
SHA-512を使用したHKDFによるECDH。 AES-128キーラップを使用：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with HKDF using SHA-256; uses AES-256 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 2D
SHA-256を使用したECDFとHKDF。 AES-256キーラップを使用：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with HKDF using SHA-384; uses AES-256 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECHAとSHA-384を使用したHKDF。 AES-256キーラップを使用：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with HKDF using SHA-512; uses AES-256 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 2D
SHA-512を使用したHKDFによるECDH。 AES-256キーラップを使用：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 2D
Please consult the security considerations of [CMS] for security considerations related to the enveloped-data content type and the authenticated-data content type.
エンベロープデータコンテンツタイプと認証データコンテンツタイプに関連するセキュリティの考慮事項については、[CMS]のセキュリティに関する考慮事項を参照してください。
Please consult the security considerations of [AUTHENV] for security considerations related to the authenticated-enveloped-data content type.
authentication-enveloped-dataコンテンツタイプに関連するセキュリティの考慮事項については、[AUTHENV]のセキュリティの考慮事項を参照してください。
Please consult the security considerations of [CURVES] for security considerations related to the use of X25519 and X448.
X25519およびX448の使用に関連するセキュリティの考慮事項については、[CURVES]のセキュリティの考慮事項を参照してください。
The originator uses an ephemeral public/private key pair that is generated on the same elliptic curve as the public key of the recipient. The ephemeral key pair is used for a single CMS protected content type, and then it is discarded. If the originator wants to be able to decrypt the content (for enveloped-data and authenticated-enveloped-data) or check the authentication (for authenticated-data), then the originator needs to treat themselves as a recipient.
発信者は、受信者の公開鍵と同じ楕円曲線上に生成される一時的な公開鍵と秘密鍵のペアを使用します。エフェメラルキーペアは、単一のCMS保護コンテンツタイプに使用され、その後破棄されます。発信者がコンテンツを復号化（エンベロープデータと認証済みエンベロープデータの場合）または認証をチェック（認証データの場合）できるようにしたい場合、発信者は自身を受信者として扱う必要があります。
As specified in [CMS], implementations MUST support processing of the KeyAgreeRecipientInfo ukm field; this ensures that interoperability is not a concern whether the ukm is present or absent. The ukm is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. When present, the ukm ensures that a different key-encryption key is generated, even when the originator ephemeral private key is improperly used more than once.
[CMS]で指定されているように、実装はKeyAgreeRecipientInfo ukmフィールドの処理をサポートする必要があります。これにより、ukmの有無にかかわらず、相互運用性が問題になることはありません。 ukmは、ECC-CMS-SharedInfo構造のentityUInfoフィールドに配置されます。存在する場合、ukmは、発信元の一時的な秘密鍵が誤って複数回使用された場合でも、異なる鍵暗号鍵が生成されることを保証します。
One object identifier for the ASN.1 module in Appendix A was assigned in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)" registry on [IANA-SMI]:
[IANA-SMI]の「SMI Security for S / MIME Module Identifiers（1.2.840.113549.1.9.16.0）」レジストリで、付録AのASN.1モジュールの1つのオブジェクト識別子が割り当てられました。
id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) mod(0) 67 }
Three object identifiers for the Key Agreement Algorithm Identifiers in Section 7 were assigned in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry on [IANA-SMI]:
[IANA-SMI]の「SMI Security for S / MIME Algorithms（1.2.840.113549.1.9.16.3）」レジストリで、セクション7の鍵合意アルゴリズム識別子の3つのオブジェクト識別子が割り当てられました。
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, <https://www.rfc-editor.org/info/rfc5083>.
[AUTHENV] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、DOI 10.17487 / RFC5083、2007年11月、<https://www.rfc-editor.org/info/ rfc5083>。
[CERTCAP] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, <https://www.rfc-editor.org/info/rfc4262>.
[CERTCAP] Santesson、S。、「Secure / Multipurpose Internet Mail Extensions（S / MIME）CapabilitiesのX.509 Certificate Extension」、RFC 4262、DOI 10.17487 / RFC4262、2005年12月、<https：//www.rfc-editor .org / info / rfc4262>。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, <https://www.rfc-editor.org/info/rfc5911>.
[CMSASN1] Hoffman、P。およびJ. Schaad、「暗号化メッセージ構文（CMS）およびS / MIMEの新しいASN.1モジュール」、RFC 5911、DOI 10.17487 / RFC5911、2010年6月、<https：//www.rfc -editor.org/info/rfc5911>。
[CMSECC] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.
[CMSECC]ターナーS.およびD.ブラウン、「暗号化メッセージ構文（CMS）での楕円曲線暗号（ECC）アルゴリズムの使用」、RFC 5753、DOI 10.17487 / RFC5753、2010年1月、<https：//www.rfc -editor.org/info/rfc5753>。
[CURVES] 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>.
[曲線]ラングレー、A。、ハンブルク、M。、およびS.ターナー、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<https://www.rfc-editor.org/info / rfc7748>。
[HKDF] 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>.
[HKDF] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<https：//www.rfc-editor .org / info / rfc5869>。
[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[プロフィール] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8410] Josefsson, S., and J. Schaad, "Algorithm Identifiers for Ed25519,Ed448, Ed448ph, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.
[RFC8410] Josefsson、S。、およびJ. Schaad、「インターネットX.509公開鍵インフラストラクチャで使用するEd25519、Ed448、Ed448ph、X25519、およびX448のアルゴリズム識別子」、RFC 8410、DOI 10.17487 / RFC8410、2018年8月、<https://www.rfc-editor.org/info/rfc8410>。
[SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic Curve Cryptography", Cericom Research, version 2.0, May 2009, <http://www.secg.org/sec1-v2.pdf>.
[SEC1] Efficient Cryptographyの標準、「SEC 1：Elliptic Curve Cryptography」、Cericom Research、バージョン2.0、2009年5月、<http://www.secg.org/sec1-v2.pdf>。
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[SMIME] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<https：//www.rfc- editor.org/info/rfc5751>。
[X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.
[X680] ITU-T、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、ISO / IEC 8824-1、2015年8月、<https：/ /www.itu.int/rec/T-REC-X.680/en>。
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
[X690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690、 ISO / IEC 8825-1、2015年8月、<https://www.itu.int/rec/T-REC-X.690/en>。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AES]米国国立標準技術研究所、「Advanced Encryption Standard（AES）」、FIPS PUB 197、2001年11月。
[AESKW] 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>.
[AESKW] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、DOI 10.17487 / RFC3394、2002年9月、<https://www.rfc-editor.org/info/ rfc3394>。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.
[CMSAES] Schaad、J。、「暗号化メッセージ構文（CMS）でのAdvanced Encryption Standard（AES）暗号化アルゴリズムの使用」、RFC 3565、DOI 10.17487 / RFC3565、2003年7月、<https：//www.rfc-editor .org / info / rfc3565>。
[DH1976] Diffie, W., and M. E. Hellman, "New Directions in Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, November 1976, pp. 644-654.
[DH1976] Diffie、W。、およびM. E. Hellman、「暗号化の新しい方向性」、IEEEトランス。情報について理論、Vol。 IT-22、1976年11月、ページ644-654。
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", <https://www.iana.org/assignments/smi-numbers>.
[IANA-SMI] IANA、「Structure of Management Information（SMI）Numbers（MIB Module Registrations）」、<https://www.iana.org/assignments/smi-numbers>。
[X963] American National Standards Institute, "Public-Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", American National Standard X9.63-2001, November 2001.
[X963] American National Standards Institute、「金融サービス業界の公開鍵暗号化：楕円曲線暗号を使用した鍵合意および鍵転送」、American National Standard X9.63-2001、2001年11月。
CMSECDHAlgs-2017
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecdh-alg-2017(67) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
-すべてエクスポート
IMPORTS
輸入
KeyWrapAlgorithm
FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
KEY-AGREE, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
dhSinglePass-stdDH-sha256kdf-scheme,
dhSinglePass-stdDH-sha384kdf-scheme,
dhSinglePass-stdDH-sha512kdf-scheme,
kaa-dhSinglePass-stdDH-sha256kdf-scheme,
kaa-dhSinglePass-stdDH-sha384kdf-scheme,
kaa-dhSinglePass-stdDH-sha512kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
FROM CMSECCAlgs-2009-02 -- in [CMSECC]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-cms-ecc-alg-2009-02(46) }
;
-- -- Object Identifiers --
--オブジェクト識別子-
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
-- -- Extend the Key Agreement Algorithms in [CMSECC] --
--[CMSECC]の鍵合意アルゴリズムを拡張-
KeyAgreementAlgs KEY-AGREE ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme |
kaa-dhSinglePass-stdDH-sha384kdf-scheme |
kaa-dhSinglePass-stdDH-sha512kdf-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
-- -- Extend the S/MIME CAPS in [CMSECC] --
--[CMSECC]でS / MIME CAPSを拡張-
SMimeCAPS SMIME-CAPS ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps }
cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme }
cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}
cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }
END
終わり
Acknowledgements
謝辞
Many thanks to Roni Even, Daniel Migault, Eric Rescorla, Jim Schaad, Stefan Santesson, and Sean Turner for their review and insightful suggestions.
Roni Even、Daniel Migault、Eric Rescorla、Jim Schaad、Stefan Santesson、およびSean Turnerのレビューと洞察に富んだ提案に感謝します。
Author's Address
著者のアドレス
Russ Housley 918 Spring Knoll Drive Herndon, VA 20170 United States of America
Russ Housley 918 Spring Knoll Drive Herndon、VA 20170アメリカ合衆国
Email: housley@vigilsec.com