Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9629 Vigil Security
Updates: 5652 J. Gray
Category: Standards Track Entrust
ISSN: 2070-1721 大久保 智史 (T. Okubo)
Penguin Securities Pte. Ltd.
August 2024
The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652.
暗号化メッセージ構文（CMS）は、主要な輸送および主要な合意アルゴリズムをサポートしています。近年、暗号統計学者は、量子セキュアKEMアルゴリズムを含む重要なカプセル化メカニズム（KEM）アルゴリズムを指定しています。このドキュメントでは、CMSコンテンツを暗号化および復号化するために、発信者と受信者によるKEMアルゴリズムの使用に関する規則を定義します。このドキュメントは、RFC 5652を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9629.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9629で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
1.2. ASN.1
1.3. CMS Version Numbers
2. KEM Processing Overview
3. KEM Recipient Information
4. KEM Algorithm Identifier
5. Key Derivation
6. ASN.1 Modules
6.1. KEMAlgorithmInformation-2023 ASN.1 Module
6.2. CMS-KEMRecipientInfo-2023 ASN.1 Module
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
This document updates "Cryptographic Message Syntax (CMS)" [RFC5652].
このドキュメントは、「暗号化メッセージ構文（CMS）」[RFC5652]を更新します。
The CMS enveloped-data content type [RFC5652] and the CMS authenticated-enveloped-data content type [RFC5083] support both key transport and key agreement algorithms to establish the key used to encrypt and decrypt the content. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms for the CMS enveloped-data content type and the CMS authenticated-enveloped-data content type.
CMSエンベロープDATAコンテンツタイプ[RFC5652]とCMS認証エンベロープDATAコンテンツタイプ[RFC5083]は、キートランスポートとキー契約アルゴリズムの両方をサポートして、コンテンツを暗号化および解読するために使用されるキーを確立します。近年、暗号統計学者は、量子セキュアKEMアルゴリズムを含む重要なカプセル化メカニズム（KEM）アルゴリズムを指定しています。このドキュメントでは、CMSエンベロープDATAコンテンツタイプとCMS認証エンベロープDATAコンテンツタイプにKEMアルゴリズムを使用するための規則を定義します。
A KEM algorithm is a one-pass (store-and-forward) mechanism for transporting random keying material to a recipient using the recipient's public key. This means that the originator and the recipients do not need to be online at the same time. The recipient's private key is needed to recover the random keying material, which is then treated as a pairwise shared secret (ss) between the originator and recipient.
KEMアルゴリズムは、レシピエントの公開キーを使用してレシピエントにランダムキーイン材を輸送するためのワンパス（ストアアンドフォワード）メカニズムです。これは、発信者と受信者が同時にオンラインである必要がないことを意味します。受信者の秘密鍵は、ランダムキーイング材料を回復するために必要です。ランダムキーイング材料は、オリジネーターと受信者の間でペアワイズ共有秘密（SS）として扱われます。
The KEMRecipientInfo structure defined in this document uses the pairwise shared secret as an input to a key derivation function (KDF) to produce a pairwise key-encryption key (KEK). Then, the pairwise KEK is used to encrypt a content-encryption key (CEK) or a content-authenticated-encryption key (CAEK) for that recipient. All of the recipients receive the same CEK or CAEK.
このドキュメントで定義されているKemrecipientInfo構造は、ペアワイズ共有シークレットをキー派生関数（KDF）への入力として使用して、ペアワイズキー暗号化キー（KEK）を生成します。次に、ペアワイズケックを使用して、その受信者のコンテンツ暗号化キー（CEK）またはコンテンツ照会誘発キー（CAEK）を暗号化します。すべての受信者は同じCEKまたはCAEKを受け取ります。
In this environment, security depends on three things. First, the KEM algorithm must be secure against adaptive chosen ciphertext attacks. Second, the key-encryption algorithm must provide confidentiality and integrity protection. Third, the choices of the KDF and the key-encryption algorithm need to provide the same level of security as the KEM algorithm.
この環境では、セキュリティは3つのことに依存します。まず、KEMアルゴリズムは、適応選択した暗号文攻撃に対して安全でなければなりません。第二に、キー暗号化アルゴリズムは、機密性と整合性の保護を提供する必要があります。第三に、KDFの選択とキー暗号化アルゴリズムは、KEMアルゴリズムと同じレベルのセキュリティを提供する必要があります。
A KEM algorithm provides three functions:
KEMアルゴリズムは3つの関数を提供します。
KeyGen() -> (pk, sk):
keygen（） - >（pk、sk）：
Generate the public key (pk) and a private key (sk).
公開キー（PK）と秘密鍵（SK）を生成します。
Encapsulate(pk) -> (ct, ss):
cancapsulate（pk） - >（ct、ss）：
Given the recipient's public key (pk), produce a ciphertext (ct) to be passed to the recipient and shared secret (ss) for the originator.
受信者の公開キー（PK）を考えると、受信者のレシピエントと共有秘密（SS）に渡される暗号文（CT）を作成します。
Decapsulate(sk, ct) -> ss:
Decapsulate（SK、CT） - > SS：
Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss) for the recipient.
秘密鍵（SK）と暗号文（CT）を考えると、受信者に共有秘密（SS）が生成されます。
To support a particular KEM algorithm, the CMS originator MUST implement the KEM Encapsulate() function.
特定のKEMアルゴリズムをサポートするには、CMSオリジネーターはKEM Encapsulate（）関数を実装する必要があります。
To support a particular KEM algorithm, the CMS recipient MUST implement the KEM KeyGen() function and the KEM Decapsulate() function. The recipient's public key is usually carried in a certificate [RFC5280].
特定のKEMアルゴリズムをサポートするには、CMSレシピエントはKEM KeyGen（）関数とKEM Decapsulate（）関数を実装する必要があります。受信者の公開キーは通常、証明書[RFC5280]に掲載されます。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
CMS values are generated using ASN.1 [X.680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690].
CMS値は、asn.1 [x.680]を使用して生成されます。これは、基本的なエンコーディングルール（BER）と識別式エンコードルール（der）[x.690]を使用します。
As described in Section 1.3 of [RFC5652], the major data structures include a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of the error-handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the originator.
[RFC5652]のセクション1.3で説明されているように、主要なデータ構造には、データ構造の最初の項目としてバージョン番号が含まれています。バージョン番号は、ASN.1デコードエラーを回避することを目的としています。一部の実装では、デコードを試行する前にバージョン番号を確認しません。デコードエラーが発生した場合、バージョン番号はエラー処理ルーチンの一部としてチェックされます。これは合理的なアプローチです。エラー処理は高速パスの外側に配置されます。このアプローチは、オリジネーターが誤ったバージョン番号を使用している場合にも寛容です。
Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used.
構造が更新されるたびに、より高いバージョン番号が割り当てられます。ただし、最大の相互運用性を確保するために、より高いバージョン数は、新しい構文機能が採用されている場合にのみ使用されます。つまり、生成された構文をサポートする最低バージョン番号が使用されます。
KEM algorithms can be used with three CMS content types: the enveloped-data content type [RFC5652], the authenticated-data content type [RFC5652], or the authenticated-enveloped-data content type [RFC5083]. For simplicity, the terminology associated with the enveloped-data content type will be used in this overview.
KEMアルゴリズムは、3つのCMSコンテンツタイプで使用できます：封筒DATAコンテンツタイプ[RFC5652]、認証されたDATAコンテンツタイプ[RFC5652]、または認証されたエンベロープDATAコンテンツタイプ[RFC5083]。簡単にするために、この概要では、封筒のコンテンツタイプに関連付けられた用語を使用します。
The originator randomly generates the CEK (or the CAEK), and then all recipients obtain that key as an encrypted object within the KEMRecipientInfo encryptedKey field explained in Section 3. All recipients use the originator-generated symmetric key to decrypt the CMS message.
オリジネーターはCEK（またはCAEK）をランダムに生成し、その後、すべての受信者がセクション3で説明されているKemrecipientInfo暗号化されたキーフィールド内の暗号化されたオブジェクトとしてそのキーを取得します。
A KEM algorithm and a key derivation function are used to securely establish a pairwise symmetric KEK, which is used to encrypt the originator-generated CEK (or the CAEK).
KEMアルゴリズムとキー導出関数を使用して、ペアワイズ対称KEKを安全に確立します。これは、オリジネーターで生成されたCEK（またはCAEK）を暗号化するために使用されます。
In advance, each recipient uses the KEM KeyGen() function to create a key pair. The recipient will often obtain a certificate [RFC5280] that includes the newly generated public key. Whether the public key is certified or not, the newly generated public key is made available to potential originators.
事前に、各受信者はKem keygen（）関数を使用してキーペアを作成します。受信者は、多くの場合、新しく生成された公開キーを含む証明書[RFC5280]を取得します。公開キーが認定されているかどうかにかかわらず、新しく生成された公開キーは潜在的な創始者が利用できるようになります。
The originator establishes the CEK (or the CAEK) using these steps:
オリジネーターは、これらの手順を使用してCEK（またはCAEK）を確立します。
1. The CEK (or the CAEK) is generated at random.
1. CEK（またはCAEK）はランダムに生成されます。
2. For each recipient:
2. 各受信者に対して：
* The recipient's public key is used with the KEM Encapsulate() function to obtain a pairwise shared secret (ss) and the ciphertext for the recipient.
* 受信者の公開キーは、KEM cankapsulate（）関数で使用され、ペアワイズ共有秘密（SS）と受信者の暗号文を取得します。
* The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.
* キー導出関数は、ペアワイズSSおよびオプションでUKMフィールドで送信される他のデータから、ペアワイズ対称kekを導出するために使用されます。
* The KEK is used to encrypt the CEK for this recipient.
* KEKは、この受信者のCEKを暗号化するために使用されます。
3. The CEK (or the CAEK) is used to encrypt the content for all recipients.
3. CEK（またはCAEK）は、すべての受信者のコンテンツを暗号化するために使用されます。
The recipient obtains the CEK (or the CAEK) using these steps:
受信者は、これらの手順を使用してCEK（またはCAEK）を取得します。
1. The recipient's private key and the ciphertext are used with the KEM Decapsulate() function to obtain a pairwise ss.
1. 受信者の秘密鍵とciphertextは、KEM Decapsulate（）関数で使用され、ペアワイズSSを取得します。
2. The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.
2. キー導出関数は、ペアワイズSSおよびオプションでUKMフィールドで送信される他のデータから、ペアワイズ対称kekを導出するために使用されます。
3. The KEK is used to decrypt the CEK (or the CAEK).
3. KEKは、CEK（またはCAEK）を復号化するために使用されます。
4. The CEK (or the CAEK) is used to decrypt the content.
4. CEK（またはCAEK）は、コンテンツを復号化するために使用されます。
This document defines KEMRecipientInfo for use with KEM algorithms. As specified in Section 6.2.5 of [RFC5652], recipient information for additional key management techniques is represented in the OtherRecipientInfo type. Each key management technique is identified by a unique ASN.1 object identifier.
このドキュメントでは、KemRecipientInfoがKem Algorithmsで使用することを定義しています。[RFC5652]のセクション6.2.5で指定されているように、追加の主要な管理手法のレシピエント情報は、他のRecipientInfoタイプで表されます。各重要な管理手法は、一意のASN.1オブジェクト識別子によって識別されます。
The object identifier associated with KEMRecipientInfo is:
KemrecipientInfoに関連付けられているオブジェクト識別子は次のとおりです。
id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }
id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }
The KEMRecipientInfo type is:
kemrecipientinfoタイプは次のとおりです。
KEMRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0
rid RecipientIdentifier,
kem KEMAlgorithmIdentifier,
kemct OCTET STRING,
kdf KeyDerivationAlgorithmIdentifier,
kekLength INTEGER (1..65535),
ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
wrap KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
The fields of the KEMRecipientInfo type have the following meanings:
KemrecipientInfoタイプのフィールドには、次の意味があります。
version is the syntax version number. The version MUST be 0. The CMSVersion type is described in Section 10.2.5 of [RFC5652].
バージョンは構文バージョン番号です。バージョンは0でなければなりません。CMSバージョンタイプは、[RFC5652]のセクション10.2.5で説明されています。
rid specifies the recipient's certificate or key that was used by the originator with the KEM Encapsulate() function. The RecipientIdentifier provides two alternatives for specifying the recipient's certificate [RFC5280], and thereby the recipient's public key. The recipient's certificate MUST contain a KEM public key. Therefore, a recipient X.509 version 3 certificate that contains a key usage extension MUST assert the keyEncipherment bit. The issuerAndSerialNumber alternative identifies the recipient's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier alternative identifies the recipient's certificate by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. For recipient processing, implementations MUST support both of these alternatives for specifying the recipient's certificate. For originator processing, implementations MUST support at least one of these alternatives.
RIDは、KEM Encapsulate（）関数を使用して発信者が使用した受信者の証明書またはキーを指定します。受信者は、受信者の証明書[RFC5280]を指定するための2つの代替手段を提供し、それにより受信者の公開キーを提供します。受信者の証明書には、KEMの公開キーが含まれている必要があります。したがって、主要な使用法拡張機能を含む受信者X.509バージョン3証明書は、KeyEciphermentビットをアサートする必要があります。発行者の代替案は、発行者の著名な名前と証明書のシリアル番号による受信者の証明書を識別します。subjecteyidentifierの代替手段は、キー識別子による受信者の証明書を識別します。X.509証明書が参照されると、キー識別子はX.509件名の拡張機能値と一致します。他の証明書形式が参照される場合、証明書形式を指定するドキュメントとCMSでの使用を指定するドキュメントには、キー識別子の適切な証明書フィールドを一致させる詳細を含める必要があります。受信者の処理のために、実装は、受信者の証明書を指定するためのこれらの代替案の両方をサポートする必要があります。オリジネーター処理のために、実装はこれらの代替案の少なくとも1つをサポートする必要があります。
kem identifies the KEM algorithm, and any associated parameters, used by the originator. The KEMAlgorithmIdentifier is described in Section 4.
KEMは、発信者が使用するKEMアルゴリズムと、関連するパラメーターを識別します。Kemalgorithmidentifierについては、セクション4で説明します。
kemct is the ciphertext produced by the KEM Encapsulate() function for this recipient.
KEMCTは、この受信者のKEM capsulate（）関数によって生成される暗号文です。
kdf identifies the key derivation function, and any associated parameters, used by the originator to generate the KEK. The KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [RFC5652].
KDFは、KEKを生成するためにオリジネーターが使用するキー派生関数と関連するパラメーターを識別します。KeyDerivationalGorithMidentifierは、[RFC5652]のセクション10.1.6で説明されています。
kekLength is the size of the KEK in octets. This value is one of the inputs to the key derivation function. The upper bound on the integer value is provided to make it clear to implementers that support for very large integer values is not needed. Implementations MUST confirm that the value provided is consistent with the key-encryption algorithm identified in the wrap field below.
Keklengthは、オクテットのKekのサイズです。この値は、キー導出関数への入力の1つです。整数値の上限は、非常に大きな整数値をサポートする必要がないことを実装者に明確にするために提供されます。実装は、提供された値が、以下のラップフィールドで識別されたキー暗号化アルゴリズムと一致していることを確認する必要があります。
ukm is optional user keying material. When the ukm value is provided, it is used as part of the info structure described in Section 5 to provide a context input to the key derivation function. For example, the ukm value could include a nonce, application-specific context information, or an identifier for the originator. A KEM algorithm may place requirements on the ukm value. Implementations that do not support the ukm field SHOULD gracefully discontinue processing when the ukm field is present. Note that this requirement expands the original purpose of the ukm described in Section 10.2.6 of [RFC5652]; it is not limited to being used with key agreement algorithms.
UKMはオプションのユーザーキーイング素材です。UKM値が提供されると、セクション5で説明されている情報構造の一部として使用され、キー派生関数へのコンテキスト入力を提供します。たとえば、UKM値には、非CE、アプリケーション固有のコンテキスト情報、またはオリジネーターの識別子が含まれます。KEMアルゴリズムは、UKM値に要件を配置する場合があります。UKMフィールドをサポートしていない実装は、UKMフィールドが存在する場合に処理を優雅に中止する必要があります。この要件は、[RFC5652]のセクション10.2.6で説明されているUKMの本来の目的を拡大することに注意してください。キー契約アルゴリズムで使用されることに限定されません。
wrap identifies a key-encryption algorithm used to encrypt the CEK. The KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of [RFC5652].
LAPは、CEKを暗号化するために使用されるキー暗号化アルゴリズムを識別します。KeyEncryptionalgorithmidentifierは、[RFC5652]のセクション10.1.3で説明されています。
encryptedKey is the result of encrypting the CEK or the CAEK (the content-authenticated-encryption key, as discussed in [RFC5083]) with the KEK. EncryptedKey is an OCTET STRING.
暗号化されたKeyは、CEKまたはCAEK（[RFC5083]で説明されているように、コンテンツ - 認証された暗号化キー）をKEKで暗号化した結果です。暗号化されたKeyはOctet Stringです。
The KEMAlgorithmIdentifier type identifies a KEM algorithm used to establish a pairwise ss. The details of establishment depend on the KEM algorithm used. A key derivation function is used to transform the pairwise ss value into a KEK.
Kemalgorithmidentifierタイプは、ペアワイズSSの確立に使用されるKEMアルゴリズムを識別します。確立の詳細は、使用されるKEMアルゴリズムに依存します。キー派生関数を使用して、ペアワイズSS値をKEKに変換します。
KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} }
This section describes the conventions of using the KDF to compute the KEK for KEMRecipientInfo. For simplicity, the terminology used in the HKDF specification [RFC5869] is used here.
このセクションでは、KDFを使用してKemrecipientInfoのKEKを計算する慣習について説明します。簡単にするために、HKDF仕様[RFC5869]で使用される用語がここで使用されます。
Many KDFs internally employ a one-way hash function. When this is the case, the hash function that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. Other KDFs internally employ an encryption algorithm. When this is the case, the encryption that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier.
多くのKDFは、一元配置ハッシュ関数を内部的に採用しています。この場合、使用されるハッシュ関数は、KeyDerivationalGorithMidentifierによって間接的に示されます。他のKDFは、暗号化アルゴリズムを内部的に採用しています。これが当てはまる場合、使用される暗号化は、KeyDerivationalGorithMidentifierによって間接的に示されます。
The KDF inputs are as follows:
KDF入力は次のとおりです。
IKM is the input keying material. It is a symmetric secret input to the KDF. The KDF may use a hash function or an encryption algorithm to generate a pseudorandom key. The algorithm used to derive the IKM is dependent on the algorithm identified in the KeyDerivationAlgorithmIdentifier.
IKMは入力キーイング素材です。これは、KDFへの対称的な秘密の入力です。KDFは、ハッシュ関数または暗号化アルゴリズムを使用して、擬似ランダムキーを生成する場合があります。IKMの導出に使用されるアルゴリズムは、KeyDerivationalGorithMidentifierで識別されたアルゴリズムに依存します。
L is the length of the output keying material in octets. L is identified in the kekLength of the KEMRecipientInfo. The value is dependent on the key-encryption algorithm used; the key-encryption algorithm is identified in the KeyEncryptionAlgorithmIdentifier.
Lは、オクテットの出力キーイン材料の長さです。lは、Kemrecipientinfoのkeklengthで識別されます。値は、使用されるキー暗号化アルゴリズムに依存します。KeyEncryptingAlgorithMidentifierでキー暗号化アルゴリズムが識別されます。
info is contextual input to the KDF. The DER-encoded CMSORIforKEMOtherInfo structure is created from elements of the KEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as:
情報は、KDFへのコンテキスト入力です。der-Encoded cmsoriforkemotherinfo構造は、Kemrecipientinfo構造の要素から作成されます。cmsoriforkemotherinfoは次のように定義されています。
CMSORIforKEMOtherInfo ::= SEQUENCE {
wrap KeyEncryptionAlgorithmIdentifier,
kekLength INTEGER (1..65535),
ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The CMSORIforKEMOtherInfo structure contains the following:
CMSORIFORKEMOTHERINFO構造には、次のものが含まれています。
wrap identifies a key-encryption algorithm; the output of the key derivation function will be used as a key for this algorithm.
LAPは、キー暗号化アルゴリズムを識別します。キー導出関数の出力は、このアルゴリズムのキーとして使用されます。
kekLength is the length of the KEK in octets; the output of the key derivation function will be exactly this size.
Keklengthは、オクテットのKekの長さです。キー導入関数の出力はまさにこのサイズになります。
ukm is optional user keying material; see Section 3.
UKMはオプションのユーザーキーイング素材です。セクション3を参照してください。
The KDF output is as follows:
KDF出力は次のとおりです。
OKM is the output keying material with the exact length of L octets. The OKM is the KEK that is used to encrypt the CEK or the CAEK.
OKMは、lオクテットの正確な長さの出力キーイン材料です。OKMは、CEKまたはCAEKを暗号化するために使用されるKEKです。
An acceptable KDF MUST accept an IKM, L, and info as inputs. An acceptable KDF MAY also accept a salt input value, which is carried as a parameter to the KeyDerivationAlgorithmIdentifier if present. All of these inputs MUST influence the output of the KDF.
許容可能なKDFは、IKM、L、および情報を入力として受け入れる必要があります。許容可能なKDFは、存在する場合はkeyderivationalgorithmidentifierにパラメーターとして運ばれる塩入力値を受け入れる場合があります。これらの入力はすべて、KDFの出力に影響を与える必要があります。
This section provides two ASN.1 modules [X.680]. The first ASN.1 module is an extension to the AlgorithmInformation-2009 module discussed in [RFC5912]; it defines the KEM-ALGORITHM CLASS. The second ASN.1 module defines the structures needed to use KEM algorithms with CMS [RFC5652].
このセクションでは、2つのasn.1モジュール[x.680]を提供します。最初のASN.1モジュールは、[RFC5912]で説明されているアルゴリズムFormation-2009モジュールの拡張です。KEM-Algorithmクラスを定義します。2番目のASN.1モジュールは、CMS [RFC5652]でKEMアルゴリズムを使用するために必要な構造を定義します。
The first ASN.1 module uses EXPLICIT tagging, and the second ASN.1 module uses IMPLICIT tagging.
最初のASN.1モジュールは明示的なタグ付けを使用し、2番目のASN.1モジュールは暗黙のタグ付けを使用します。
Both ASN.1 modules follow the conventions established in [RFC5911], [RFC5912], and [RFC6268].
両方のASN.1モジュールは、[RFC5911]、[RFC5912]、および[RFC6268]で確立された規則に従います。
KEMAlgorithmInformation-2023
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-kemAlgorithmInformation-2023(109) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
ParamOptions, PUBLIC-KEY, SMIME-CAPS
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ;
-- KEM-ALGORITHM
--
-- Describes the basic properties of a KEM algorithm
--
-- Suggested prefix for KEM algorithm objects is: kema-
--
-- &id - contains the OID identifying the KEM algorithm
-- &Value - if present, contains a type definition for the kemct;
-- if absent, implies that no ASN.1 encoding is
-- performed on the kemct value
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &PublicKeySet - specifies which public keys are used with
-- this algorithm
-- &Ukm - if absent, type for user keying material
-- &ukmPresence - specifies the requirements to define the UKM
-- field
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- kema-kem-rsa KEM-ALGORITHM ::= {
-- IDENTIFIER id-kem-rsa
-- PARAMS TYPE RsaKemParameters ARE optional
-- PUBLIC-KEYS { pk-rsa | pk-rsa-kem }
-- UKM ARE optional
-- SMIME-CAPS { TYPE GenericHybridParameters
-- IDENTIFIED BY id-rsa-kem }
-- }
KEM-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Value OPTIONAL,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&PublicKeySet PUBLIC-KEY OPTIONAL,
&Ukm OPTIONAL,
&ukmPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[VALUE &Value]
[PARAMS [TYPE &Params] ARE ¶mPresence]
[PUBLIC-KEYS &PublicKeySet]
[UKM [TYPE &Ukm] ARE &ukmPresence]
[SMIME-CAPS &smimeCaps]
}
END
CMS-KEMRecipientInfo-2023
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-kemri-2023(77) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
OTHER-RECIPIENT, CMSVersion, RecipientIdentifier,
EncryptedKey, KeyDerivationAlgorithmIdentifier,
KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial
FROM CryptographicMessageSyntax-2010 -- RFC 6268
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) }
KEM-ALGORITHM
FROM KEMAlgorithmInformation-2023 -- RFC 9629
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-kemAlgorithmInformation-2023(109) }
AlgorithmIdentifier{}
FROM AlgorithmInformation-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ;
--
-- OtherRecipientInfo Types (ori-)
--
SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... }
ori-KEM OTHER-RECIPIENT ::= {
KEMRecipientInfo IDENTIFIED BY id-ori-kem }
id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }
id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }
--
-- KEMRecipientInfo
--
KEMRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0
rid RecipientIdentifier,
kem KEMAlgorithmIdentifier,
kemct OCTET STRING,
kdf KeyDerivationAlgorithmIdentifier,
kekLength INTEGER (1..65535),
ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
wrap KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEMAlgSet KEM-ALGORITHM ::= { ... }
KEMAlgorithmIdentifier ::=
AlgorithmIdentifier{ KEM-ALGORITHM, {KEMAlgSet} }
--
-- CMSORIforKEMOtherInfo
--
CMSORIforKEMOtherInfo ::= SEQUENCE {
wrap KeyEncryptionAlgorithmIdentifier,
kekLength INTEGER (1..65535),
ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
END
The security considerations discussed in [RFC5652] are applicable to this document.
[RFC5652]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用できます。
To be appropriate for use with this specification, the KEM algorithm MUST explicitly be designed to be secure when the public key is used many times. For example, a KEM algorithm with a single-use public key is not appropriate, because the public key is expected to be carried in a long-lived certificate [RFC5280] and used over and over. Thus, KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are appropriate. A common design pattern for obtaining IND-CCA2 security with public key reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant of the FO transform [HHK].
この仕様で使用するのに適しているため、公開キーを何度も使用する場合、KEMアルゴリズムを明示的に安全にするように設計する必要があります。たとえば、公開キーは長寿命の証明書[RFC5280]で運ばれ、何度も使用されると予想されるため、単一使用の公開キーを備えたKEMアルゴリズムは適切ではありません。したがって、適応的に選択されたCiphertext攻撃（IND-CCA2）セキュリティの下で区別不可能を提供するKEMアルゴリズムが適切です。公開キーの再利用を使用してIND-CCA2セキュリティを取得するための一般的な設計パターンは、富士キサキオカモト（FO）変換[FO]またはFO変換[HHK]のバリアントを適用することです。
The KDF SHOULD offer at least the security level of the KEM.
KDFは、少なくともKEMのセキュリティレベルを提供する必要があります。
The choice of the key-encryption algorithm and the size of the KEK SHOULD be made based on the security level provided by the KEM. The key-encryption algorithm and the KEK SHOULD offer at least the security level of the KEM.
KEMが提供するセキュリティレベルに基づいて、キー暗号化アルゴリズムの選択とKEKのサイズを作成する必要があります。キー暗号化アルゴリズムとKEKは、少なくともKEMのセキュリティレベルを提供する必要があります。
KEM algorithms do not provide data origin authentication; therefore, when a KEM algorithm is used with the authenticated-data content type, the contents are delivered with integrity from an unknown source.
KEMアルゴリズムは、データの起源認証を提供しません。したがって、認証されたDATAコンテンツタイプでKEMアルゴリズムが使用される場合、コンテンツは未知のソースから完全性を持って配信されます。
Implementations MUST protect the KEM private key, the KEK, and the CEK (or the CAEK). Compromise of the KEM private key may result in the disclosure of all contents protected with that KEM private key. However, compromise of the KEK, the CEK, or the CAEK may result in disclosure of the encrypted content of a single message.
実装は、KEMの秘密鍵、KEK、およびCEK（またはCAEK）を保護する必要があります。KEMの秘密鍵の妥協は、そのKEMの秘密鍵で保護されているすべてのコンテンツの開示をもたらす可能性があります。ただし、Kek、CEK、またはCaekの妥協により、単一のメッセージの暗号化されたコンテンツが開示される可能性があります。
The KEM produces the IKM input value for the KDF. This IKM value MUST NOT be reused for any other purpose. Likewise, any random value used by the KEM algorithm to produce the shared secret or its encapsulation MUST NOT be reused for any other purpose. That is, the originator MUST generate a fresh KEM shared secret for each recipient in the KEMRecipientInfo structure, including any random value used by the KEM algorithm to produce the KEM shared secret. In addition, the originator MUST discard the KEM shared secret, including any random value used by the KEM algorithm to produce the KEM shared secret, after constructing the entry in the KEMRecipientInfo structure for the corresponding recipient. Similarly, the recipient MUST discard the KEM shared secret, including any random value used by the KEM algorithm to produce the KEM shared secret, after constructing the KEK from the KEMRecipientInfo structure.
KEMは、KDFのIKM入力値を生成します。このIKM値は、他の目的のために再利用してはなりません。同様に、共有秘密またはそのカプセル化を生成するためにKEMアルゴリズムによって使用されるランダムな値は、他の目的のために再利用してはなりません。つまり、発信元は、KemRecipientInfo構造の各受信者に対して、KEMアルゴリズムで使用されるランダムな値を含む、KEM共有秘密を生成するためのランダムな値を含む、新鮮なKEM共有秘密を生成する必要があります。さらに、対応する受信者のKemrecipientInfo構造のエントリを構築した後、KEMアルゴリズムで使用されるKEM共有秘密を作成するためにKEMアルゴリズムが使用するランダムな値を含む、発信者はKEM共有秘密を廃棄する必要があります。同様に、受信者は、Kemrecipientinfo構造からKEKを構築した後、KEMアルゴリズムが使用するKEM共有秘密を生成するために使用するランダムな値を含む、KEM共有秘密を廃棄する必要があります。
Implementations MUST randomly generate content-encryption keys, content-authenticated-encryption keys, and message-authentication keys. Also, the generation of KEM key pairs relies on random numbers. The use of inadequate pseudorandom number generators (PRNGs) to generate these keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area.
実装では、コンテンツエンクションキー、Content-Authenticated-Incryption Keys、およびMessage-Authentication Keysをランダムに生成する必要があります。また、KEMキーペアの生成は乱数に依存しています。これらのキーを生成するために不十分な擬似ランダム数ジェネレーター（PRNG）を使用すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成したPRNG環境を再現する方がはるかに簡単になる場合があり、キー空間全体を検索するのではなく、結果として生じる小さな可能性のセットを検索します。品質の乱数の生成は困難です。[RFC4086]は、この分野で重要なガイダンスを提供します。
If the cipher and key sizes used for the key-encryption algorithm and the content-encryption algorithm are different, the effective security is determined by the weaker of the two algorithms. If, for example, the content is encrypted with AES-CBC using a 128-bit CEK and the CEK is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits of protection is provided.
キー暗号化アルゴリズムとコンテンツ暗号化アルゴリズムに使用される暗号サイズとキーサイズが異なる場合、効果的なセキュリティは2つのアルゴリズムの弱い方によって決定されます。たとえば、コンテンツが128ビットCEKを使用してAES-CBCで暗号化され、CEKが256ビットKEKを使用してAES-KeyWrapでラップされている場合、最大128ビットの保護が提供されます。
If the cipher and key sizes used for the key-encryption algorithm and the content-authenticated-encryption algorithm are different, the effective security is determined by the weaker of the two algorithms. If, for example, the content is encrypted with AES-GCM using a 128-bit CAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then at most 128 bits of protection is provided.
キー暗号化アルゴリズムに使用される暗号サイズとキーサイズが、コンテンツ因果関係のある暗号化アルゴリズムが異なる場合、効果的なセキュリティは2つのアルゴリズムの弱い方によって決定されます。たとえば、コンテンツが128ビットCAEKを使用してAES-GCMで暗号化され、CAEKが192ビットKEKを使用してAES-KeeWrapで包まれている場合、最大128ビットの保護が提供されます。
If the cipher and key sizes used for the key-encryption algorithm and the message-authentication algorithm are different, the effective security is determined by the weaker of the two algorithms. If, for example, the content is authenticated with HMAC-SHA256 using a 512-bit message-authentication key and the message-authentication key is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 256 bits of protection is provided.
キー暗号化アルゴリズムに使用される暗号サイズとキーサイズとメッセージ認証アルゴリズムが異なる場合、効果的なセキュリティは2つのアルゴリズムの弱い方によって決定されます。たとえば、コンテンツが512ビットのメッセージオーセティテンションキーを使用してHMAC-Sha256で認証され、メッセージauthenticationキーが256ビットKEKを使用してAES-KeyWrapで包まれている場合、最大256ビットの保護が提供されます。。
Implementers should be aware that cryptographic algorithms, including KEM algorithms, become weaker with time. As new cryptoanalysis techniques are developed and computing capabilities advance, the work factor to break a particular cryptographic algorithm will be reduced. As a result, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of supported algorithms to change over time.
実装者は、KEMアルゴリズムを含む暗号化アルゴリズムが時間とともに弱くなることに注意する必要があります。新しい暗号分析技術が開発され、コンピューティング機能が進むにつれて、特定の暗号化アルゴリズムを破る作業要因が削減されます。その結果、暗号化アルゴリズムの実装はモジュール式である必要があり、新しいアルゴリズムを容易に挿入できるようにします。つまり、実装者は、サポートされているアルゴリズムのセットが時間の経過とともに変更されるように準備する必要があります。
For KEMRecipientInfo as defined in Section 3, IANA has assigned the following OID in the "SMI Security for S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" registry:
セクション3で定義されているKemrecipientInfoの場合、IANAは次のOIDを「S/MIMEのSMIセキュリティの他の受信者情報識別子（1.2.840.113549.1.9.16.13）」に割り当てました。
+=========+=============+============+
| Decimal | Description | References |
+=========+=============+============+
| 3 | id-ori-kem | RFC 9629 |
+---------+-------------+------------+
Table 1
For the ASN.1 module defined in Section 6.1, IANA has assigned the following OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
セクション6.1で定義されているASN.1モジュールの場合、IANAは次のOIDを「PKIXモジュール識別子のSMIセキュリティ」レジストリ（1.3.6.1.1.5.5.7.0）に割り当てました。
+=========+=====================================+============+
| Decimal | Description | References |
+=========+=====================================+============+
| 109 | id-mod-kemAlgorithmInformation-2023 | RFC 9629 |
+---------+-------------------------------------+------------+
Table 2
For the ASN.1 module defined in Section 6.2, IANA has assigned the following OID in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
セクション6.2で定義されているASN.1モジュールの場合、IANAは次のOIDを「S/MIMEモジュール識別子のSMIセキュリティ（1.2.840.113549.1.9.16.0）」に割り当てました。
+=========+=======================+============+
| Decimal | Description | References |
+=========+=======================+============+
| 77 | id-mod-cms-kemri-2023 | RFC 9629 |
+---------+-----------------------+------------+
Table 3
[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>.
[RFC5083] 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>.
[RFC5280] 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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5911] 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>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[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>.
[X.680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
[FO] Fujisaki, E. and T. Okamoto, "Secure Integration of
Asymmetric and Symmetric Encryption Schemes", Springer
Science and Business Media LLC, Journal of Cryptology,
vol. 26, no. 1, pp. 80-101, DOI 10.1007/s00145-011-9114-1,
December 2011,
<https://doi.org/10.1007/s00145-011-9114-1>.
[HHK] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular
Analysis of the Fujisaki-Okamoto Transformation", Springer
International Publishing, Theory of Cryptography, TCC
2017, Lecture Notes in Computer Science, vol. 10677, pp.
341-371, Print ISBN 9783319704999, Online ISBN
9783319705002, DOI 10.1007/978-3-319-70500-2_12, November
2017, <https://doi.org/10.1007/978-3-319-70500-2_12>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[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>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
Our thanks to Burt Kaliski for his guidance and design review.
彼の指導とデザインのレビューをしてくれたBurt Kaliskiに感謝します。
Our thanks to Carl Wallace for his careful review of the ASN.1 modules.
ASN.1モジュールを慎重にレビューしてくれたCarl Wallaceに感謝します。
Our thanks to Hendrik Brockhaus, Jonathan Hammell, Mike Jenkins, David von Oheimb, Francois Rousseau, and Linda Dunbar for their careful reviews and thoughtful comments.
Hendrik Brockhaus、Jonathan Hammell、Mike Jenkins、David Von Oheimb、Francois Rousseau、Linda Dunbarに感謝します。
Russ Housley
Vigil Security, LLC
Herndon, VA
United States of America
Email: housley@vigilsec.com
John Gray
Entrust
Minneapolis, MN
United States of America
Email: john.gray@entrust.com
Tomofumi Okubo
Penguin Securities Pte. Ltd.
Singapore
Email: tomofumi.okubo+ietf@gmail.com
Additional contact information:
大久保 智史
Penguin Securities Pte. Ltd.
Singapore