[要約] RFC 3565は、暗号メッセージ構文（CMS）での高度暗号化標準（AES）の使用に関するものです。このRFCの目的は、CMSでAESを使用するためのガイドラインとセキュリティ上の考慮事項を提供することです。
Network Working Group J. Schaad
Request for Comments: 3565 Soaring Hawk Consulting
Category: Standards Track July 2003
Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)
暗号化メッセージ構文（CMS）でのAdvanced Encryption Standard（AES）暗号化アルゴリズムの使用
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS).
このドキュメントでは、暗号化メッセージ構文（CMS）での暗号化にAdvanced Encryption Standard（AES）アルゴリズムを使用するための規則を指定します。
Conventions used in this document
このドキュメントで使用される規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [MUSTSHOULD].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [MUSTSHOULD]で説明されているように解釈されます。
This document specifies the conventions for using Advanced Encryption Standard (AES) content encryption algorithm with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types.
このドキュメントでは、暗号化メッセージ構文[CMS]のエンベロープデータと暗号化データのコンテンツタイプでAdvanced Encryption Standard（AES）コンテンツ暗号化アルゴリズムを使用するための規則を指定します。
CMS values are generated using ASN.1 [X.208-88], using the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88].
CMS値は、ASN.1 [X.208-88]を使用して、基本エンコーディングルール（BER）[X.209-88]とDistinguished Encoding Rules（DER）[X.509-88]を使用して生成されます。
The Advanced Encryption Standard (AES) [AES] was developed to replace DES [DES]. The AES Federal Information Processing Standard (FIPS) Publication specifies a cryptographic algorithm for use by U.S. Government organizations. However, the AES will also be widely used by organizations, institutions, and individuals outside of the U.S. Government.
Advanced Encryption Standard（AES）[AES]は、DES [DES]を置き換えるために開発されました。 AES連邦情報処理標準（FIPS）出版物は、米国政府機関が使用する暗号化アルゴリズムを指定しています。ただし、AESは米国政府以外の組織、機関、個人でも広く使用されます。
Two researchers who developed and submitted the Rijndael algorithm for consideration are both cryptographers from Belgium: Dr. Joan Daemen of Proton World International and Dr. Vincent Rijmen, a postdoctoral researcher in the Electrical Engineering Department of Katholieke Universiteit Leuven.
Rijndaelアルゴリズムを検討のために開発して提出した2人の研究者は、どちらもベルギーの暗号学者です。ProtonWorld InternationalのJoan Daemen博士と、Katholiek Universiteit Leuvenの電気工学部の博士研究員であるVincent Rijmen博士です。
The National Institute of Standards and technology (NIST) selected the Rijndael algorithm for AES because it offers a combination of security, performance, efficiency, ease of implementation, and flexibility. Specifically, Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. The very low memory requirements of the Rijndael algorithm make it very well suited for restricted-space environments, in which it also demonstrates excellent performance. The Rijndael algorithm operations are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting the algorithm's performance. Finally, the algorithm's internal round structure appears to have good potential to benefit from instruction-level parallelism.
米国国立標準技術研究所（NIST）は、セキュリティ、パフォーマンス、効率、実装の容易さ、および柔軟性の組み合わせを提供するため、AESにラインダールアルゴリズムを選択しました。具体的には、Rijndaelは、フィードバックモードまたは非フィードバックモードでの使用に関係なく、幅広いコンピューティング環境にわたってハードウェアとソフトウェアの両方で一貫して非常に優れたパフォーマンスを発揮するようです。キーのセットアップ時間は優れており、キーの俊敏性は優れています。 Rijndaelアルゴリズムはメモリ要件が非常に低いため、制限されたスペース環境に非常に適しています。この場合、優れたパフォーマンスも発揮されます。 Rijndaelアルゴリズムの操作は、電力攻撃とタイミング攻撃からの防御が最も簡単なものの1つです。さらに、アルゴリズムのパフォーマンスに大きな影響を与えることなく、このような攻撃に対してある程度の防御を提供できるようです。最後に、アルゴリズムの内部ラウンド構造は、命令レベルの並列処理の恩恵を受ける可能性が高いようです。
The AES specifies three key sizes: 128, 192 and 256 bits.
AESは、128、192、および256ビットの3つの鍵サイズを指定します。
The CMS enveloped-data content type consists of encrypted content and wrapped content-encryption keys for one or more recipients. The AES algorithm is used to encrypt the content.
CMSエンベロープデータコンテンツタイプは、暗号化されたコンテンツと1人以上の受信者用のラップされたコンテンツ暗号化キーで構成されます。コンテンツの暗号化にはAESアルゴリズムが使用されます。
Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 6, "Enveloped-data Content Type".
準拠ソフトウェアは、[CMS]セクション6「エンベロープデータコンテンツタイプ」で述べられているエンベロープデータコンテンツタイプを構築するための要件を満たさなければなりません。
The AES content-encryption key MUST be randomly generated for each instance of an enveloped-data content type. The content-encryption key (CEK) is used to encrypt the content.
AESコンテンツ暗号化キーは、エンベロープデータコンテンツタイプのインスタンスごとにランダムに生成する必要があります。コンテンツ暗号化キー（CEK）は、コンテンツの暗号化に使用されます。
AES can be used with the enveloped-data content type using any of the following key management techniques defined in [CMS] Section 6.
AESは、[CMS]セクション6で定義されている以下のキー管理手法のいずれかを使用して、エンベロープデータコンテンツタイプで使用できます。
1) Key Transport: The AES CEK is uniquely wrapped for each recipient using the recipient's public RSA key and other values. Section 2.2 provides additional details.
1）キートランスポート：AES CEKは、受信者の公開RSAキーおよびその他の値を使用して、受信者ごとに一意にラップされます。セクション2.2で詳細を説明します。
2) Key Agreement: The AES CEK is uniquely wrapped for each recipient using a pairwise symmetric key-encryption key (KEK) generated using an originator's randomly generated private key (ES-DH [DH]) or previously generated private key (SS-DH [DH]), the recipient's public DH key, and other values. Section 2.3 provides additional details.
2）鍵合意：AES CEKは、発信者のランダムに生成された秘密鍵（ES-DH [DH]）または以前に生成された秘密鍵（SS-DH）を使用して生成されたペアワイズ対称鍵暗号鍵（KEK）を使用して、各受信者に対して一意にラップされます。 [DH]）、受信者の公開DHキー、およびその他の値。セクション2.3で詳細を説明します。
3) Previously Distributed Symmetric KEK: The AES CEK is wrapped using a previously distributed symmetric KEK (such as a Mail List Key). The methods by which the symmetric KEK is generated and distributed are beyond the scope of this document. Section 2.4 provides additional details.
3）以前に配布された対称KEK：AES CEKは、以前に配布された対称KEK（メールリストキーなど）を使用してラップされます。対称KEKを生成および配布する方法は、このドキュメントの範囲外です。セクション2.4で詳細を説明します。
4) Password Encryption: The AES CEK is wrapped using a KEK derived from a password or other shared secret. Section 2.5 provides additional details.
4）パスワード暗号化：AES CEKは、パスワードまたは他の共有秘密から導出されたKEKを使用してラップされます。セクション2.5で詳細を説明します。
Documents defining the use of the Other Recipient Info structure will need to define the proper use for the AES algorithm if desired.
Other Recipient Info構造の使用を定義するドキュメントでは、必要に応じてAESアルゴリズムの適切な使用を定義する必要があります。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as follows:
エンベロープデータコンテンツタイプは、EnvelopedData構文を使用してエンコードされたASN.1です。 EnvelopedData構文のフィールドには、次のように入力する必要があります。
The EnvelopedData version is determined based on a number of factors.
EnvelopedDataのバージョンは、いくつかの要因に基づいて決定されます。
See [CMS] section 6.1 for the algorithm to determine this value.
この値を決定するアルゴリズムについては、[CMS]セクション6.1を参照してください。
The EnvelopedData recipientInfos CHOICE is dependent on the key management technique used. Section 2.2, 2.3, 2.4 and 2.5 provide additional information.
EnvelopedData recipientInfos CHOICEは、使用されるキー管理技術に依存しています。セクション2.2、2.3、2.4、および2.5は、追加情報を提供します。
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm field MUST specify a symmetric encryption algorithm. Implementations MUST support content encryption with AES, but implementations MAY support other algorithms as well.
EnvelopedData encryptedContentInfo contentEncryptionAlgorithmフィールドは、対称暗号化アルゴリズムを指定する必要があります。実装はAESによるコンテンツの暗号化をサポートする必要がありますが、実装は他のアルゴリズムもサポートする場合があります（MAY）。
The EnvelopedData unprotectedAttrs MAY be present.
EnvelopedData unprotectedAttrsが存在する場合があります。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as follows:
エンベロープデータコンテンツタイプは、EnvelopedData構文を使用してエンコードされたASN.1です。 EnvelopedData構文のフィールドには、次のように入力する必要があります。
The KeyTransRecipientInfo version MUST be either 0 or 2. If the RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the version MUST be 0. If the RecipientIdentifier is subjectKeyIdentifier, then the version MUST be 2.
KeyTransRecipientInfoのバージョンは0または2でなければなりません。RecipientIdentifierがCHOICE issuerAndSerialNumberの場合、バージョンは0でなければなりません。RecipientIdentifierがsubjectKeyIdentifierの場合、バージョンは2でなければなりません。
The KeyTransRecipientInfo RecipientIdentifier provides two alternatives for specifying the recipient's certificate, and thereby the recipient's public key. The recipient's certificate MUST contain a RSA public key. The CEK is encrypted with the recipient's RSA public key. The issuerAndSerialNumber alternative identifies the recipient's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier identifies the recipient's certificate by the X.509 subjectKeyIdentifier extension value.
KeyTransRecipientInfo RecipientIdentifierは、受信者の証明書を指定するための2つの代替手段を提供し、それにより受信者の公開鍵を提供します。受信者の証明書には、RSA公開鍵が含まれている必要があります。 CEKは、受信者のRSA公開鍵で暗号化されます。 issuerAndSerialNumber代替では、発行者の識別名と証明書のシリアル番号によって受信者の証明書を識別します。 subjectKeyIdentifierは、X.509 subjectKeyIdentifier拡張値によって受信者の証明書を識別します。
The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the key transport algorithm (i.e., RSAES-OAEP [RSA-OAEP]), and the associated parameters used to encrypt the CEK for the recipient.
KeyTransRecipientInfo keyEncryptionAlgorithmフィールドは、鍵転送アルゴリズム（つまり、RSAES-OAEP [RSA-OAEP]）と、受信者のCEKを暗号化するために使用される関連パラメーターを指定します。
The KeyTransRecipientInfo encryptedKey is the result of encrypting the CEK with the recipient's RSA public key.
KeyTransRecipientInfo encryptedKeyは、CEKを受信者のRSA公開鍵で暗号化した結果です。
This section describes the conventions for using ES-DH or SS-DH and AES with the CMS enveloped-data content type to support key agreement. When key agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE MUST be used.
このセクションでは、CMSエンベロープデータコンテンツタイプでES-DHまたはSS-DHおよびAESを使用して、鍵合意をサポートするための規則について説明します。鍵合意が使用される場合、RecipientInfo keyAgreeRecipientInfo CHOICEを使用する必要があります。
The KeyAgreeRecipient version MUST be 3.
KeyAgreeRecipientのバージョンは3でなければなりません。
The EnvelopedData originatorInfo field MUST be the originatorKey alternative. The originatorKey algorithm fields MUST contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey MUST contain the originator's ephemeral public key.
EnvelopedData originatorInfoフィールドは、originatorKeyの代替である必要があります。 originatorKeyアルゴリズムフィールドには、パラメーターのないdh-public-numberオブジェクト識別子を含める必要があります。 originatorKey publicKeyには、発信者の一時的な公開鍵が含まれている必要があります。
The EnvelopedData ukm MAY be present.
EnvelopedData ukmが存在する場合があります。
The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH algorithm identifier [CMSALG].
EnvelopedData keyEncrytionAlgorithmは、id-alg-ESDHアルゴリズム識別子[CMSALG]である必要があります。
Generation of the AES KEK to be used with the AES-key wrap algorithm is done using the method described in [DH].
AESキーラップアルゴリズムで使用されるAES KEKの生成は、[DH]で説明されている方法を使用して行われます。
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
ZZは20バイトです00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
The key wrap algorithm is AES-128 wrap, so we need 128 bits (16 bytes) of keying material.
鍵ラップアルゴリズムはAES-128ラップであるため、128ビット（16バイト）の鍵情報が必要です。
No partyAInfo is used.
partyAInfoは使用されません。
Consequently, the input to SHA-1 is:
したがって、SHA-1への入力は次のとおりです。
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 1b 30 11 06 09 60 86 48 01 65 03 04 01 05 ; AES-128 wrap OID 04 04 00 00 00 01 ; Counter a2 06 04 04 00 00 00 80 ; key length
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13; ZZ 30 1b 30 11 06 09 60 86 48 01 65 03 04 01 05; AES-128ラップOID 04 04 00 00 00 01;カウンタa2 06 04 04 00 00 00 80;キーの長さ
And the output is the 32 bytes:
そして出力は32バイトです：
d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9
d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9
Consequently,
したがって、
K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64
K = d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
ZZは20バイトです00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
The key wrap algorithm is AES-256 key wrap, so we need 256 bits (32 bytes) of keying material.
鍵ラップアルゴリズムはAES-256鍵ラップであるため、256ビット（32バイト）の鍵情報が必要です。
The partyAInfo used is the 64 bytes
使用されるpartyAInfoは64バイトです
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
Consequently, the input to first invocation of SHA-1 is:
したがって、SHA-1の最初の呼び出しへの入力は次のとおりです。
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d ; AES-256 wrap OID 04 04 00 00 00 01 ; Counter a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13; ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d; AES-256ラップOID 04 04 00 00 00 01;カウンタa0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01; partyAInfo
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 01 00 ; key length
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 01 00;キーの長さ
And the output is the 20 bytes:
そして出力は20バイトです：
88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93 The input to second invocation of SHA-1 is:
88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93 SHA-1の2回目の呼び出しへの入力は次のとおりです。
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d ; AES-256 wrap OID 04 04 00 00 00 02 ; Counter a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13; ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d; AES-256ラップOID 04 04 00 00 00 02;カウンタa0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01; partyAInfo
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 01 00 ; key length
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 01 00;キーの長さ
And the output is the 20 bytes:
そして出力は20バイトです：
CB A8 F9 22 BD 1B 56 A0 71 C9 6F 90 36 C6 04 2C AA 20 94 37
CB A8 F9 22 BD 1B 56 A0 71 C9 6F 90 36 C6 04 2C AA 20 94 37
Consequently,
したがって、
K = 88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93 CB A8 F9 22 BD 1B 56 A0
K = 88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93 CB A8 F9 22 BD 1B 56 A0
The AES key wrap algorithm encrypts one AES key in another AES key. The algorithm produces an output 64-bits longer than the input AES CEK, the additional bits are a checksum. The algorithm uses 6*n AES encryption/decryption operations where n is number of 64-bit blocks in the AES CEK. Full details of the AES key wrap algorithm are available at [AES-WRAP].
AESキーラップアルゴリズムは、1つのAESキーを別のAESキーに暗号化します。このアルゴリズムは、入力AES CEKよりも64ビット長い出力を生成します。追加のビットはチェックサムです。アルゴリズムは6 * n AES暗号化/復号化操作を使用します。nはAES CEKの64ビットブロックの数です。 AESキーラップアルゴリズムの詳細については、[AES-WRAP]をご覧ください。
NIST has assigned the following OIDs to define the AES key wrap algorithm.
NISTは、AESキーラップアルゴリズムを定義するために次のOIDを割り当てています。
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
In all cases the parameters field MUST be absent. The OID gives the KEK key size, but does not make any statements as to the size of the wrapped AES CEK. Implementations MAY use different KEK and CEK sizes. Implements MUST support the CEK and the KEK having the same length. If different lengths are supported, the KEK MUST be of equal or greater length than the CEK.
すべての場合において、parametersフィールドは存在しない必要があります。 OIDはKEKキーのサイズを示しますが、ラップされたAES CEKのサイズについては何も述べていません。実装は、異なるKEKおよびCEKサイズを使用する場合があります。実装は、同じ長さのCEKとKEKをサポートする必要があります。異なる長さがサポートされている場合、KEKはCEKと同じかそれより長くなければなりません。
This section describes the conventions for using AES with the CMS enveloped-data content type to support previously distributed symmetric KEKs. When a previously distributed symmetric KEK is used to wrap the AES CEK, then the RecipientInfo KEKRecipientInfo CHOICE MUST be used. The methods used to generate and distribute the symmetric KEK are beyond the scope of this document. One possible method of distributing keys is documented in [SYMKEYDIST].
このセクションでは、CMSエンベロープデータコンテンツタイプでAESを使用して、以前に配布された対称KEKをサポートするための規則について説明します。以前に配布された対称KEKを使用してAES CEKをラップする場合は、RecipientInfo KEKRecipientInfo CHOICEを使用する必要があります。対称KEKの生成と配布に使用される方法は、このドキュメントの範囲外です。キーを配布する1つの可能な方法は、[SYMKEYDIST]に文書化されています。
The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section 6.2.3, KEKRecipientInfo Type.
KEKRecipientInfoフィールドは、[CMS]セクション6.2.3、KEKRecipientInfoタイプで指定されているように入力する必要があります。
The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be one of the OIDs defined in section 2.3.2 indicating that the AES wrap function is used to wrap the AES CEK. The KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent.
KEKRecipientInfo keyEncryptionAlgorithmアルゴリズムフィールドは、AESラップ関数がAES CEKをラップするために使用されることを示す、セクション2.3.2で定義されたOIDの1つである必要があります。 KEKRecipientInfo keyEncryptionAlgorithmパラメータフィールドは存在しない必要があります。
The KEKRecipientInfo encryptedKey field MUST include the AES CEK wrapped using the previously distributed symmetric KEK as input to the AES wrap function.
KEKRecipientInfo encryptedKeyフィールドには、以前に配布された対称KEKをAESラップ関数への入力として使用してラップされたAES CEKを含める必要があります。
This section describes the conventions for using AES with the CMS enveloped-data content type to support password-based key management.
このセクションでは、CMSエンベロープデータコンテンツタイプでAESを使用して、パスワードベースのキー管理をサポートするための規則について説明します。
When a password derived KEK is used to wrap the AES CEK, then the RecipientInfo PasswordRecipientInfo CHOICE MUST be used.
パスワードから派生したKEKを使用してAES CEKをラップする場合、RecipientInfo PasswordRecipientInfo CHOICEを使用する必要があります。
The keyEncryptionAlgorithm algorithm field MUST be one of the OIDs defined in section 2.3.2 indicating the AES wrap function is used to wrap the AES CEK. The keyEncryptionAlgorithm parameters field MUST be absent.
keyEncryptionAlgorithmアルゴリズムフィールドは、AESラップ機能がAES CEKをラップするために使用されることを示す、セクション2.3.2で定義されたOIDの1つである必要があります。 keyEncryptionAlgorithmパラメータフィールドは存在しない必要があります。
The encryptedKey field MUST be the result of the AES key wrap algorithm applied to the AES CEK value.
encryptedKeyフィールドは、AES CEK値に適用されるAESキーラップアルゴリズムの結果である必要があります。
The CMS encrypted-data content type consists of encrypted content with implicit key management. The AES algorithm is used to encrypt the content.
CMS暗号化データコンテンツタイプは、暗黙的なキー管理を備えた暗号化コンテンツで構成されます。コンテンツの暗号化にはAESアルゴリズムが使用されます。
Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 8, "Encrypted-data Content Type".
準拠ソフトウェアは、[CMS]セクション8「暗号化されたデータのコンテンツタイプ」で述べられているエンベロープデータコンテンツタイプを構築するための要件を満たさなければなりません。
The encrypted-data content type is ASN.1 encoded using the EncryptededData syntax. The fields of the EncryptedData syntax MUST be populated as follows:
暗号化されたデータのコンテンツタイプは、EncryptededData構文を使用してエンコードされたASN.1です。 EncryptedData構文のフィールドには、次のように入力する必要があります。
The EncryptedData version is determined based on a number of factors.
EncryptedDataのバージョンは、いくつかの要因に基づいて決定されます。
See [CMS] section 9.1 for the algorithm to determine this value.
この値を決定するアルゴリズムについては、[CMS]セクション9.1を参照してください。
The EncryptedData encryptedContentInfo contentEncryptionAlgorithm field MUST specify a symmetric encryption algorithm. Implementations MUST support encryption using AES, but implementations MAY support other algorithms as well.
EncryptedData encryptedContentInfo contentEncryptionAlgorithmフィールドは、対称暗号化アルゴリズムを指定する必要があります。実装はAESを使用した暗号化をサポートする必要がありますが、実装は他のアルゴリズムもサポートする場合があります（MAY）。
The EncryptedData unprotectedAttrs MAY be present.
EncryptedData unprotectedAttrsが存在する場合があります。
This section specified algorithm identifiers for the AES encryption algorithm.
このセクションでは、AES暗号化アルゴリズムのアルゴリズム識別子を指定しました。
The AES algorithm is defined in [AES]. RSAES-OAEP [RSA-OAEP] MAY be used to transport AES keys.
AESアルゴリズムは[AES]で定義されています。 RSAES-OAEP [RSA-OAEP]は、AESキーの転送に使用できます。
AES is added to the set of symmetric content encryption algorithms defined in [CMSALG]. The AES content-encryption algorithm, in Cipher Block Chaining (CBC) mode, for the three different key sizes are identified by the following object identifiers:
[CMSALG]で定義されている対称コンテンツ暗号化アルゴリズムのセットにAESが追加されました。暗号ブロックチェーン（CBC）モードの3つの異なるキーサイズのAESコンテンツ暗号化アルゴリズムは、次のオブジェクト識別子によって識別されます。
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a AES-IV:
AlgorithmIdentifierパラメータフィールドが存在しなければならず、パラメータフィールドにはAES-IVが含まれている必要があります。
AES-IV ::= OCTET STRING (SIZE(16))
Content encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.
コンテンツ暗号化アルゴリズムの識別子は、EnvelopedData EncryptedContentInfo contentEncryptionAlgorithmおよびEncryptedData EncryptedContentInfo contentEncryptionAlgorithmフィールドにあります。
Content encryption algorithms are used to encrypt the content located in the EnvelopedData EncryptedContentInfo encryptedContent and the EncryptedData EncryptedContentInfo encryptedContent fields.
コンテンツ暗号化アルゴリズムは、EnvelopedData EncryptedContentInfo encryptedContentおよびEncryptedData EncryptedContentInfo encryptedContentフィールドにあるコンテンツを暗号化するために使用されます。
An S/MIME client SHOULD announce the set of cryptographic functions it supports by using the S/MIME capabilities attribute. This attribute provides a partial list of object identifiers of cryptographic functions and MUST be signed by the client. The algorithm OIDs SHOULD be logically separated in functional categories and MUST be ordered with respect to their preference.
S / MIMEクライアントは、S / MIME機能属性を使用して、サポートする暗号化機能のセットを通知する必要があります（SHOULD）。この属性は、暗号化機能のオブジェクト識別子の部分的なリストを提供し、クライアントによって署名されなければなりません（MUST）。アルゴリズムOIDは機能カテゴリで論理的に分離する必要があり（SHOULD）、それらの優先順位に従って順序付けする必要があります。
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support.
RFC 2633 [MSG]、セクション2.5.2は、SMIMECapabilitiesを通知するソフトウェアがサポートできるアルゴリズムの部分的なリストを指定するために使用するSMIMECapabilities署名属性（SMIMECapability SEQUENCEのSEQUENCEとして定義）を定義します。
If an S/MIME client is required to support symmetric encryption with AES, the capabilities attribute MUST contain the AES object identifier specified above in the category of symmetric algorithms. The parameter with this encoding MUST be absent.
S / MIMEクライアントがAESによる対称暗号化をサポートする必要がある場合、capabilities属性には、対称アルゴリズムのカテゴリで上で指定されたAESオブジェクト識別子が含まれている必要があります。このエンコーディングのパラメータは存在しない必要があります。
The encodings for the mandatory key sizes are:
必須のキーサイズのエンコーディングは次のとおりです。
Key Size Capability 128 30 0B 06 09 60 86 48 01 65 03 04 01 02 196 30 0B 06 09 60 86 48 01 65 03 04 01 16 256 30 0B 06 09 60 86 48 01 65 03 04 01 2A
キーサイズ機能128 30 0B 06 09 60 86 48 01 65 03 04 01 02 196 30 0B 06 09 60 86 48 01 65 03 04 01 16 256 30 0B 06 09 60 86 48 01 65 03 04 01 2A
When a sending agent creates an encrypted message, it has to decide which type of encryption algorithm to use. In general the decision process involves information obtained from the capabilities lists included in messages received from the recipient, as well as other information such as private agreements, user preferences, legal restrictions, and so on. If users require AES for symmetric encryption, the S/MIME clients on both the sending and receiving side MUST support it, and it MUST be set in the user preferences.
送信エージェントは、暗号化されたメッセージを作成するときに、使用する暗号化アルゴリズムのタイプを決定する必要があります。一般に、決定プロセスには、受信者から受信したメッセージに含まれる機能リストから取得した情報、および私的な合意、ユーザー設定、法的制限などの他の情報が含まれます。ユーザーが対称暗号化にAESを必要とする場合、送信側と受信側の両方のS / MIMEクライアントがそれをサポートする必要があり、ユーザー設定で設定する必要があります。
If RSA-OAEP [PKCS#1v2.0] and RSA PKCS #1 v1.5 [PKCS#1v1.5] are both used to transport the same CEK, then an attacker can still use the Bleichenbacher attack against the RSA PKCS #1 v1.5 encrypted key. It is generally unadvisable to mix both RSA-OAEP and RSA PKCS#1 v1.5 in the same set of recipients.
RSA-OAEP [PKCS＃1v2.0]とRSA PKCS＃1 v1.5 [PKCS＃1v1.5]の両方が同じCEKの転送に使用されている場合、攻撃者は引き続きRSA PKCS＃1に対してブライチェンバッハ攻撃を使用できますv1.5暗号化キー。通常、RSA-OAEPとRSA PKCS＃1 v1.5の両方を同じ受信者のセットに混在させることはお勧めできません。
Implementations must protect the RSA private key and the CEK. Compromise of the RSA private key may result in the disclosure of all messages protected with that key. Compromise of the CEK may result in disclosure of the associated encrypted content.
実装では、RSA秘密鍵とCEKを保護する必要があります。 RSA秘密鍵の侵害により、その鍵で保護されているすべてのメッセージが漏洩する可能性があります。 CEKの侵害により、関連する暗号化されたコンテンツが開示される可能性があります。
The generation of AES CEKs relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate these values 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. RFC 1750 [RANDOM] offers important guidance in this area.
AES CEKの生成は、乱数に依存しています。これらの値を生成するために不適切な疑似乱数ジェネレータ（PRNG）を使用すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、キーを生成したPRNG環境を再現し、結果として生じる可能性の小さなセットを検索する方がはるかに簡単であることに気付くでしょう。高品質の乱数の生成は困難です。 RFC 1750 [ランダム]は、この分野で重要なガイダンスを提供しています。
When wrapping a CEK with a KEK, the KEK MUST always be at least the same length as the CEK. An attacker will generally work at the weakest point in an encryption system. This would be the smaller of the two key sizes for a brute force attack.
CEKをKEKでラップする場合、KEKは常に少なくともCEKと同じ長さでなければなりません。攻撃者は通常、暗号化システムの最も弱い場所で動作します。これは、ブルートフォース攻撃の2つのキーサイズのうち小さい方になります。
Normative References
引用文献
[AES] National Institute of Standards. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001.
[AES]国立標準研究所。 FIPS Pub 197：Advanced Encryption Standard（AES）。 2001年11月26日。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3369、2002年8月。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-WRAP] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms, RFC 3370, August 2002.
[CMSALG] Housley、R。、「暗号メッセージ構文（CMS）アルゴリズム、RFC 3370、2002年8月。
[DES] National Institute of Standards and Technology. FIPS Pub 46: Data Encryption Standard. 15 January 1977.
[DES]米国国立標準技術研究所。 FIPS Pub 46：Data Encryption Standard。 1977年1月15日。
[DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[DH] Rescorla、E。、「Diffie-Hellman Key Agreement Method」、RFC 2631、1999年6月。
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[必須] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RSA-OAEP] Housley, R. "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RSA-OAEP] Housley、R。「暗号化メッセージ構文（CMS）でのRSAES-OAEPキー転送アルゴリズムの使用」、RFC 3560、2003年7月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88] CCITT。勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT。推奨事項X.209：抽象構文記法1（ASN.1）の基本的なエンコーディングルールの仕様。 1988。
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
[X.509-88] CCITT。推奨事項X.509：ディレクトリ-認証フレームワーク。 1988。
Informational References
参考資料
[MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG] Ramsdell、B。、編集者、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[PKCS#1v1.5] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, March 1998.
[PKCS＃1v1.5] Kaliski、B。、「PKCS＃1：RSA Encryption、バージョン1.5」、RFC 2313、1998年3月。
[PKCS#1v2.0] Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October 1998.
[PKCS＃1v2.0] Kaliski、B。、「PKCS＃1：RSA Encryption、Version 2.0」、RFC 2437、1998年10月。
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[ランダム] Eastlake、D.、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[SYMKEYDIST] Turner, S., "CMS Symmetric Key Management and Distribution", Work in Progress, January 2003.
[SYMKEYDIST]ターナー、S。、「CMS対称鍵の管理と配布」、進行中の作業、2003年1月。
Acknowledgements
謝辞
This document is the result of contributions from many professionals. We appreciate the hard work of all members of the IETF S/MIME Working Group.
このドキュメントは、多くの専門家からの寄稿の結果です。 IETF S / MIMEワーキンググループのすべてのメンバーのハードワークに感謝します。
Appendix A ASN.1 Module
付録A ASN.1モジュール
CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- PKIX
AlgorithmIdentifier
FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)};
-- AES information object identifiers --
-AES情報オブジェクト識別子-
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 }
-- AES using CBC-chaining mode for key sizes of 128, 192, 256
-128、192、256のキーサイズに対してCBCチェーンモードを使用するAES
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
-- AES-IV is a the parameter for all the above object identifiers.
-AES-IVは、上記のすべてのオブジェクト識別子のパラメーターです。
AES-IV ::= OCTET STRING (SIZE(16))
-- AES Key Wrap Algorithm Identifiers - Parameter is absent
-AESキーラップアルゴリズム識別子-パラメーターがありません
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
END
終わり
Author's Address
著者のアドレス
Jim Schaad Soaring Hawk Consulting
ジムシャードソアリングホークコンサルティング
EMail: jimsch@exmsft.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその継承者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。