[要約] RFC 3370は、CMS（Cryptographic Message Syntax）アルゴリズムに関する仕様であり、暗号化メッセージの構文とアルゴリズムを定義しています。その目的は、セキュアな通信やデータの保護を実現するために、一貫性のある暗号化手法を提供することです。
Network Working Group R. Housley
Request for Comments: 3370 RSA Laboratories
Obsoletes: 2630, 3211 August 2002
Category: Standards Track
Cryptographic Message Syntax (CMS) Algorithms
暗号化メッセージ構文（CMS）アルゴリズム
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 (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS). The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents.
このドキュメントでは、暗号化メッセージ構文（CMS）でいくつかの暗号化アルゴリズムを使用するための規則について説明します。 CMSは、任意のメッセージコンテンツのデジタル署名、ダイジェスト、認証、または暗号化に使用されます。
Table of Contents
目次
1 Introduction ............................................... 2
1.1 Changes Since RFC 2630 ..................................... 2
1.2 Terminology ................................................ 2
2 Message Digest Algorithms .................................. 3
2.1 SHA-1 ...................................................... 3
2.2 MD5 ........................................................ 3
3 Signature Algorithms ....................................... 4
3.1 DSA ........................................................ 4
3.2 RSA ........................................................ 5
4 Key Management Algorithms .................................. 6
4.1 Key Agreement Algorithms ................................... 6
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ...................... 7
4.1.2 X9.42 Static-Static Diffie-Hellman ......................... 8
4.2 Key Transport Algorithms ................................... 9
4.2.1 RSA (PKCS #1 v1.5) ......................................... 10
4.3 Symmetric Key-Encryption Key Algorithms .................... 10
4.3.1 Triple-DES Key Wrap ........................................ 11
4.3.2 RC2 Key Wrap ............................................... 12
4.4 Key Derivation Algorithms .................................. 12
4.4.1 PBKDF2 ..................................................... 13
5 Content Encryption Algorithms .............................. 13
5.1 Triple-DES CBC ............................................. 14
5.2 RC2 CBC .................................................... 14
6 Message Authentication Code (MAC) Algorithms ............... 15
6.1 HMAC with SHA-1 ............................................ 15
7 ASN.1 Module ............................................... 16
8 References ................................................. 18
9 Security Considerations .................................... 20
10 Acknowledgments ............................................ 22
11 Author's Address ........................................... 23
12 Full Copyright Statement ................................... 24
1 Introduction
1はじめに
The Cryptographic Message Syntax (CMS) [CMS] is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. This companion specification describes the use of common cryptographic algorithms with the CMS. Implementations of the CMS may support these algorithms; implementations of the CMS may also support other algorithms as well. However, if an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document.
暗号化メッセージ構文（CMS）[CMS]は、任意のメッセージコンテンツのデジタル署名、ダイジェスト、認証、または暗号化に使用されます。このコンパニオン仕様では、CMSでの一般的な暗号化アルゴリズムの使用について説明しています。 CMSの実装は、これらのアルゴリズムをサポートする場合があります。 CMSの実装は、他のアルゴリズムもサポートする場合があります。ただし、実装がこのドキュメントで説明されているアルゴリズムの1つをサポートすることを選択した場合、実装はこのドキュメントで説明されているようにサポートする必要があります。
The CMS values are generated using ASN.1 [X.208-88], using BER-encoding [X.209-88]. Algorithm identifiers (which include ASN.1 object identifiers) identify cryptographic algorithms, and some algorithms require additional parameters. When needed, parameters are specified with an ASN.1 structure. The algorithm identifier for each algorithm is specified, and when needed, the parameter structure is specified. The fields in the CMS employed by each algorithm are identified.
CMS値は、BERエンコード[X.209-88]を使用して、ASN.1 [X.208-88]を使用して生成されます。アルゴリズム識別子（ASN.1オブジェクト識別子を含む）は暗号アルゴリズムを識別し、一部のアルゴリズムには追加のパラメーターが必要です。必要に応じて、パラメーターはASN.1構造で指定されます。各アルゴリズムのアルゴリズム識別子が指定され、必要に応じてパラメーター構造が指定されます。各アルゴリズムで使用されるCMSのフィールドが識別されます。
This document obsoletes section 12 of RFC 2630 [OLDCMS]. RFC 3369 [CMS] obsoletes the rest of RFC 2630. Separation of the protocol and algorithm specifications allows each one to be updated without impacting the other. However, the conventions for using additional algorithms with the CMS are likely to be specified in separate documents.
このドキュメントはRFC 2630 [OLDCMS]のセクション12を廃止します。 RFC 3369 [CMS]はRFC 2630の残りの部分を廃止します。プロトコルとアルゴリズムの仕様の分離により、お互いに影響を与えることなく、それぞれを更新できます。ただし、CMSで追加のアルゴリズムを使用するための規則は、別のドキュメントで指定されている可能性があります。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described in [STDWORDS].
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必須」、「非推奨」、「推奨」、および「MAY」は、[STDWORDS]で説明されているように解釈されます。
2 Message Digest Algorithms
2メッセージダイジェストアルゴリズム
This section specifies the conventions employed by CMS implementations that support SHA-1 or MD5.
このセクションでは、SHA-1またはMD5をサポートするCMS実装で採用されている規則を指定します。
Digest algorithm identifiers are located in the SignedData digestAlgorithms field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, and the AuthenticatedData digestAlgorithm field.
ダイジェストアルゴリズムの識別子は、SignedData digestAlgorithmsフィールド、SignerInfo digestAlgorithmフィールド、DigestedData digestAlgorithmフィールド、およびAuthenticatedData digestAlgorithmフィールドにあります。
Digest values are located in the DigestedData digest field and the Message Digest authenticated attribute. In addition, digest values are input to signature algorithms.
ダイジェスト値は、DigestedDataダイジェストフィールドとMessage Digest認証済み属性にあります。さらに、ダイジェスト値は署名アルゴリズムに入力されます。
The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is:
SHA-1メッセージダイジェストアルゴリズムは、FIPS Pub 180-1 [SHA1]で定義されています。 SHA-1のアルゴリズム識別子は次のとおりです。
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
There are two possible encodings for the SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding is to omit the parameters field; however, implementations MUST also handle a SHA-1 AlgorithmIdentifier parameters field which contains a NULL.
SHA-1 AlgorithmIdentifierパラメータフィールドには、2つの可能なエンコーディングがあります。 2つの選択肢は、1988年のAlgorithmIdentifierの構文が1997年の構文に変換されたときに、AlgorithmIdentifierパラメーターに関連付けられたOPTIONALが失われたという事実から生じています。その後、OPTIONALは欠陥レポートによって回復しましたが、それまでに多くの人がアルゴリズムパラメータは必須であると考えていました。この履歴があるため、一部の実装はパラメーターをNULL要素としてエンコードし、他の実装はそれらを完全に省略します。正しいエンコーディングは、parametersフィールドを省略することです。ただし、実装では、NULLを含むSHA-1 AlgorithmIdentifierパラメータフィールドも処理する必要があります。
The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters.
AlgorithmIdentifierパラメータフィールドはオプションです。存在する場合、パラメータフィールドにはNULLが含まれている必要があります。実装は、パラメータのないSHA-1 AlgorithmIdentifiersを受け入れる必要があります。実装は、NULLパラメータを持つSHA-1 AlgorithmIdentifiersを受け入れる必要があります。実装は、パラメータのないSHA-1 AlgorithmIdentifiersを生成する必要があります（SHOULD）。
The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm identifier for MD5 is:
MD5ダイジェストアルゴリズムはRFC 1321 [MD5]で定義されています。 MD5のアルゴリズム識別子は次のとおりです。
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL. Implementations MAY accept the MD5 AlgorithmIdentifiers with absent parameters as well as NULL parameters.
AlgorithmIdentifierパラメータフィールドが存在しなければならず、パラメータフィールドはNULLを含んでいる必要があります。実装は、パラメータのないMD5 AlgorithmIdentifiersとNULLパラメータを受け入れることができます。
3 Signature Algorithms
3つの署名アルゴリズム
This section specifies the conventions employed by CMS implementations that support DSA or RSA (PKCS #1 v1.5).
このセクションでは、DSAまたはRSA（PKCS＃1 v1.5）をサポートするCMS実装で採用されている規則を指定します。
Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. Also, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
署名アルゴリズム識別子は、SignedDataのSignerInfo signatureAlgorithmフィールドにあります。また、署名アルゴリズム識別子は、副署名属性のSignerInfo signatureAlgorithmフィールドにあります。
Signature values are located in the SignerInfo signature field of SignedData. Also, signature values are located in the SignerInfo signature field of countersignature attributes.
署名の値は、SignedDataのSignerInfo署名フィールドにあります。また、署名値は、副署名属性のSignerInfo署名フィールドにあります。
The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA MUST be used with the SHA-1 message digest algorithm.
DSA署名アルゴリズムは、FIPS Pub 186 [DSS]で定義されています。 DSAは、SHA-1メッセージダイジェストアルゴリズムで使用する必要があります。
The algorithm identifier for DSA subject public keys in certificates is:
証明書のDSAサブジェクト公開鍵のアルゴリズム識別子は次のとおりです。
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 1 }
DSA signature validation requires three parameters, commonly called p, q, and g. When the id-dsa algorithm identifier is used, the AlgorithmIdentifier parameters field is optional. If present, the AlgorithmIdentifier parameters field MUST contain the three DSA parameter values encoded using the Dss-Parms type. If absent, the subject DSA public key uses the same DSA parameters as the certificate issuer.
DSA署名の検証には、一般的にp、q、gと呼ばれる3つのパラメーターが必要です。 id-dsaアルゴリズム識別子を使用する場合、AlgorithmIdentifierパラメータフィールドはオプションです。存在する場合、AlgorithmIdentifierパラメータフィールドには、Dss-Parmsタイプを使用してエンコードされた3つのDSAパラメータ値を含める必要があります。存在しない場合、サブジェクトDSA公開鍵は、証明書発行者と同じDSAパラメーターを使用します。
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
When the id-dsa algorithm identifier is used, the DSA public key, commonly called Y, MUST be encoded as an INTEGER. The output of this encoding is carried in the certificate subject public key.
id-dsaアルゴリズム識別子を使用する場合、一般にYと呼ばれるDSA公開鍵をINTEGERとしてエンコードする必要があります。このエンコーディングの出力は、証明書のサブジェクトの公開鍵で運ばれます。
Dss-Pub-Key ::= INTEGER -- Y
The algorithm identifier for DSA with SHA-1 signature values is:
SHA-1シグネチャ値を持つDSAのアルゴリズム識別子は次のとおりです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
When the id-dsa-with-sha1 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
id-dsa-with-sha1アルゴリズム識別子を使用する場合、AlgorithmIdentifierパラメータフィールドは存在しない必要があります。
When signing, the DSA algorithm generates two values, commonly called r and s. To transfer these two values as one signature, they MUST be encoded using the Dss-Sig-Value type:
署名時に、DSAアルゴリズムは、一般にrおよびsと呼ばれる2つの値を生成します。これら2つの値を1つの署名として転送するには、Dss-Sig-Valueタイプを使用してエンコードする必要があります。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
The RSA (PKCS #1 v1.5) signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 2437 specifies the use of the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms.
RSA（PKCS＃1 v1.5）署名アルゴリズムはRFC 2437 [NEWPKCS＃1]で定義されています。 RFC 2437は、SHA-1およびMD5メッセージダイジェストアルゴリズムでのRSA署名アルゴリズムの使用を指定しています。
The algorithm identifier for RSA subject public keys in certificates is:
証明書のRSAサブジェクト公開鍵のアルゴリズム識別子は次のとおりです。
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
When the rsaEncryption algorithm identifier is used, the AlgorithmIdentifier parameters field MUST contain NULL.
rsaEncryptionアルゴリズム識別子を使用する場合、AlgorithmIdentifierパラメータフィールドにはNULLを含める必要があります。
When the rsaEncryption algorithm identifier is used, the RSA public key, which is composed of a modulus and a public exponent, MUST be encoded using the RSAPublicKey type. The output of this encoding is carried in the certificate subject public key.
rsaEncryptionアルゴリズム識別子を使用する場合、モジュラスと公開指数で構成されるRSA公開鍵は、RSAPublicKeyタイプを使用してエンコードする必要があります。このエンコーディングの出力は、証明書のサブジェクトの公開鍵で運ばれます。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST also implement the SHA-1 message digest algorithm. Such implementations SHOULD also support the MD5 message digest algorithm.
RSA（PKCS＃1 v1.5）署名アルゴリズムを含むCMS実装は、SHA-1メッセージダイジェストアルゴリズムも実装する必要があります。このような実装は、MD5メッセージダイジェストアルゴリズムもサポートする必要があります（SHOULD）。
The rsaEncryption algorithm identifier is used to identify RSA (PKCS #1 v1.5) signature values regardless of the message digest algorithm employed. CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST support the rsaEncryption signature value algorithm identifier, and CMS implementations MAY support RSA (PKCS #1 v1.5) signature value algorithm identifiers that specify both the RSA (PKCS #1 v1.5) signature algorithm and the message digest algorithm.
rsaEncryptionアルゴリズム識別子は、採用されているメッセージダイジェストアルゴリズムに関係なく、RSA（PKCS＃1 v1.5）署名値を識別するために使用されます。 RSA（PKCS＃1 v1.5）署名アルゴリズムを含むCMS実装は、rsaEncryption署名値アルゴリズム識別子をサポートする必要があり、CMS実装は、RSA（PKCS＃1 v1.5）の両方のRSA（PKCS ＃1 v1.5）署名アルゴリズムとメッセージダイジェストアルゴリズム。
The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature values is:
SHA-1シグネチャ値を持つRSA（PKCS＃1 v1.5）のアルゴリズム識別子は次のとおりです。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature values is:
MD5シグネチャ値を持つRSA（PKCS＃1 v1.5）のアルゴリズム識別子は次のとおりです。
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
When the rsaEncryption, sha1WithRSAEncryption, or md5WithRSAEncryption signature value algorithm identifiers are used, the AlgorithmIdentifier parameters field MUST be NULL.
rsaEncryption、sha1WithRSAEncryption、またはmd5WithRSAEncryption署名値アルゴリズム識別子が使用される場合、AlgorithmIdentifierパラメータフィールドはNULLでなければなりません。
When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value.
署名するとき、RSAアルゴリズムは単一の値を生成し、その値は署名値として直接使用されます。
4 Key Management Algorithms
4つのキー管理アルゴリズム
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords.
CMSは、鍵の合意、鍵の転送、以前に配布された対称鍵暗号鍵、およびパスワードの一般的な鍵管理手法に対応しています。
This section specifies the conventions employed by CMS implementations that support key agreement using X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H).
このセクションでは、X9.42 Ephemeral-Static Diffie-Hellman（X9.42 E-S D-H）およびX9.42 Static-Static Diffie-Hellman（X9.42 S-S D-H）を使用した鍵合意をサポートするCMS実装で採用されている規則を指定します。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. Therefore, when key agreement is supported, a key-encryption algorithm MUST be provided for each content-encryption algorithm. The key wrap algorithms for Triple-DES and RC2 are described in RFC 3217 [WRAP].
鍵合意アルゴリズムを使用する場合は、鍵暗号化アルゴリズムも必要です。したがって、鍵の合意がサポートされている場合は、コンテンツ暗号化アルゴリズムごとに鍵暗号化アルゴリズムを提供する必要があります。 Triple-DESおよびRC2のキーラップアルゴリズムは、RFC 3217 [WRAP]で説明されています。
For key agreement of RC2 key-encryption keys, 128 bits MUST be generated as input to the key expansion process used to compute the RC2 effective key [RC2].
RC2キー暗号化キーのキー合意では、RC2有効キーの計算に使用されるキー拡張プロセスへの入力として128ビットを生成する必要があります[RC2]。
Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
鍵合意アルゴリズム識別子は、EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmおよびAuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールドにあります。
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
キーラップアルゴリズム識別子は、EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmおよびAuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールド内のKeyWrapAlgorithmパラメータにあります。
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
ラップされたコンテンツ暗号化キーは、EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKeyフィールドにあります。ラップされたメッセージ認証キーは、AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKeyフィールドにあります。
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as follows:
Ephemeral-Static Diffie-Hellman鍵合意は、RFC 2631 [DH-X9.42]で定義されています。 Ephemeral-Static Diffie-Hellmanを使用する場合、EnvelopedData RecipientInfos KeyAgreeRecipientInfoフィールドは次のように使用されます。
version MUST be 3.
バージョンは3でなければなりません。
originator MUST be the originatorKey alternative. The originatorKey algorithm field MUST contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey field MUST contain the sender's ephemeral public key. The dh-public-number object identifier is:
originatorはoriginatorKeyの代替である必要があります。 originatorKeyアルゴリズムフィールドには、パラメータのないdh-public-numberオブジェクト識別子を含める必要があります。 originatorKey publicKeyフィールドには、送信者の一時的な公開鍵を含める必要があります。 dh-public-numberオブジェクト識別子は次のとおりです。
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
ukm may be present or absent. CMS implementations MUST support ukm being absent, and CMS implementations SHOULD support ukm being present. When present, the ukm is used to ensure that a different key-encryption key is generated when the ephemeral private key might be used more than once.
ukmは存在する場合と存在しない場合があります。 CMS実装はukmが存在しないことをサポートする必要があり、CMS実装はukmが存在することをサポートする必要があります（SHOULD）。存在する場合、ukmは、一時的な秘密鍵が複数回使用される可能性がある場合に、別の鍵暗号鍵が確実に生成されるようにするために使用されます。
keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm identifier. The algorithm identifier parameter field for id-alg-ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The KeyWrapAlgorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the X9.42 Ephemeral-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are described in RFC 3217 [WRAP]. The id-alg-ESDH algorithm identifier and parameter syntax is:
keyEncryptionAlgorithmはid-alg-ESDHアルゴリズム識別子である必要があります。 id-alg-ESDHのアルゴリズム識別子パラメーターフィールドはKeyWrapAlgorithmであり、このパラメーターが存在する必要があります。 KeyWrapAlgorithmは、X9.42 Ephemeral-Static Diffie-Hellmanキー合意アルゴリズムを使用して生成されたペアワイズキー暗号化キーでコンテンツ暗号化キーを暗号化するために使用される対称暗号化アルゴリズムを示します。 Triple-DESおよびRC2キーラップアルゴリズムは、RFC 3217 [WRAP]で説明されています。 id-alg-ESDHアルゴリズムの識別子とパラメーターの構文は次のとおりです。
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. 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 public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the X9.42 Ephemeral-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
recipientEncryptedKeysには、各受信者の識別子と暗号化されたキーが含まれています。 RecipientEncryptedKey KeyAgreeRecipientIdentifierには、受信者の証明書を識別するissuerAndSerialNumberまたは受信者の証明書のサブジェクトキー識別子を含むRecipientKeyIdentifierのいずれかが含まれている必要があります。どちらの場合も、受信者の証明書には受信者の静的公開鍵が含まれています。 RecipientEncryptedKey EncryptedKeyには、KeyWrapAlgorithmで指定されたアルゴリズムを使用して、X9.42 Ephemeral-Static Diffie-Hellmanが生成したペアワイズキー暗号化キーで暗号化されたコンテンツ暗号化キーを含める必要があります。
Static-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Static-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are used as follows:
Static-Static Diffie-Hellman鍵協定はRFC 2631 [DH-X9.42]で定義されています。 Static-Static Diffie-Hellmanを使用する場合、EnvelopedData RecipientInfos KeyAgreeRecipientInfoおよびAuthenticatedData RecipientInfos KeyAgreeRecipientInfoフィールドは次のように使用されます。
version MUST be 3.
バージョンは3でなければなりません。
originator MUST be either the issuerAndSerialNumber or subjectKeyIdentifier alternative. In both cases, the originator's certificate contains the sender's static public key. RFC 3279 [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and values that are included in the originator's certificate. The originator's certificate subject public key information field MUST contain the dh-public-number object identifier:
originatorは、issuerAndSerialNumberまたはsubjectKeyIdentifierのいずれかでなければなりません。どちらの場合も、発信者の証明書には送信者の静的公開鍵が含まれています。 RFC 3279 [CERTALGS]は、発信者の証明書に含まれるAlgorithmIdentifierパラメータの構文と値を指定しています。発信者の証明書サブジェクト公開鍵情報フィールドには、dh-public-numberオブジェクト識別子が含まれている必要があります。
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
ukm MUST be present. The ukm ensures that a different key-encryption key is generated for each message between the same sender and recipient.
ukmが存在する必要があります。 ukmにより、同じ送信者と受信者の間のメッセージごとに異なるキー暗号化キーが生成されます。
keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm identifier. The algorithm identifier parameter field for id-alg-SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The KeyWrapAlgorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the X9.42 Static-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are described in RFC 3217 [WRAP]. The id-alg-SSDH algorithm identifier and parameter syntax is:
keyEncryptionAlgorithmは、id-alg-SSDHアルゴリズム識別子である必要があります。 id-alg-SSDHのアルゴリズム識別子パラメーターフィールドはKeyWrapAlgorihtmであり、このパラメーターが存在する必要があります。 KeyWrapAlgorithmは、X9.42 Static-Static Diffie-Hellmanキー合意アルゴリズムを使用して生成されたペアワイズキー暗号化キーでコンテンツ暗号化キーを暗号化するために使用される対称暗号化アルゴリズムを示します。 Triple-DESおよびRC2キーラップアルゴリズムは、RFC 3217 [WRAP]で説明されています。 id-alg-SSDHアルゴリズムの識別子とパラメーターの構文は次のとおりです。
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 10 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. 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 public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the X9.42 Static-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgortihm.
recipientEncryptedKeysには、各受信者の識別子と暗号化されたキーが含まれています。 RecipientEncryptedKey KeyAgreeRecipientIdentifierには、受信者の証明書を識別するissuerAndSerialNumberまたは受信者の証明書のサブジェクトキー識別子を含むRecipientKeyIdentifierのいずれかが含まれている必要があります。どちらの場合も、受信者の証明書には受信者の静的公開鍵が含まれています。 RecipientEncryptedKey EncryptedKeyには、KeyWrapAlgortihmで指定されたアルゴリズムを使用して、X9.42 Static-Static Diffie-Hellmanが生成したペアワイズキー暗号化キーで暗号化されたコンテンツ暗号化キーを含める必要があります。
This section specifies the conventions employed by CMS implementations that support key transport using RSA (PKCS #1 v1.5).
このセクションでは、RSA（PKCS＃1 v1.5）を使用したキー転送をサポートするCMS実装で採用されている規則を指定します。
Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
鍵転送アルゴリズムの識別子は、EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithmフィールドにあります。
Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field.
キートランスポートで暗号化されたコンテンツ暗号化キーは、EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKeyフィールドにあります。
The RSA key transport algorithm is the RSA encryption scheme defined in RFC 2313 [PKCS#1], block type is 02, where the message to be encrypted is the content-encryption key. The algorithm identifier for RSA (PKCS #1 v1.5) is:
RSAキートランスポートアルゴリズムは、RFC 2313 [PKCS＃1]で定義されたRSA暗号化スキームであり、ブロックタイプは02です。ここで、暗号化されるメッセージはコンテンツ暗号化キーです。 RSA（PKCS＃1 v1.5）のアルゴリズム識別子は次のとおりです。
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL.
AlgorithmIdentifierパラメータフィールドが存在しなければならず、パラメータフィールドはNULLを含んでいる必要があります。
When using a Triple-DES content-encryption key, CMS implementations MUST adjust the parity bits for each DES key comprising the Triple-DES key prior to RSA encryption.
Triple-DESコンテンツ暗号化キーを使用する場合、CMS実装は、RSA暗号化の前にTriple-DESキーを構成する各DESキーのパリティビットを調整する必要があります。
The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 [PKCS#1], to provide confidentiality has a known vulnerability. The vulnerability is primarily relevant to usage in interactive applications rather than to store-and-forward environments. Further information and proposed countermeasures are discussed in the Security Considerations section of this document and RFC 3218 [MMA].
RFC 2313 [PKCS＃1]で定義されているRSA（PKCS＃1 v1.5）暗号化を使用して機密性を提供することには、既知の脆弱性があります。この脆弱性は、ストアアンドフォワード環境ではなく、主にインタラクティブアプリケーションでの使用に関連しています。詳細情報と提案された対策については、このドキュメントのセキュリティに関する考慮事項セクションとRFC 3218 [MMA]で説明されています。
Note that the same RSA encryption scheme is also defined in RFC 2437 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called RSAES-PKCS1-v1_5.
同じRSA暗号化スキームもRFC 2437 [NEWPKCS＃1]で定義されていることに注意してください。 RFC 2437では、このRSA暗号化スキームはRSAES-PKCS1-v1_5と呼ばれています。
This section specifies the conventions employed by CMS implementations that support symmetric key-encryption key management using Triple-DES or RC2 key-encryption keys. When RC2 is supported, RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58. A CMS implementation MAY support mixed key-encryption and content-encryptionalgorithms. For example, a 40-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption key.
このセクションでは、Triple-DESまたはRC2キー暗号化キーを使用した対称キー暗号化キー管理をサポートするCMS実装で採用されている規則を指定します。 RC2がサポートされている場合、RC2 128ビットキーはキー暗号化キーとして使用する必要があり、RC2ParameterVersionパラメータを58に設定して使用する必要があります。CMS実装は、キー暗号化とコンテンツ暗号化アルゴリズムの混合をサポートする場合があります。たとえば、40ビットのRC2コンテンツ暗号化キーは、168ビットのTriple-DESキー暗号化キーまたは128ビットのRC2キー暗号化キーでラップされる場合があります。
Key wrap algorithm identifiers are located in the EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm fields.
キーラップアルゴリズム識別子は、EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithmおよびAuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithmフィールドにあります。
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey field.
ラップされたコンテンツ暗号化キーは、EnvelopedData RecipientInfos KEKRecipientInfo encryptedKeyフィールドにあります。ラップされたメッセージ認証キーは、AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKeyフィールドにあります。
The output of a key agreement algorithm is a key-encryption key, and this key-encryption key is used to encrypt the content-encryption key. To support key agreement, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. However, only key agreement algorithms that inherently provide authentication ought to be used with AuthenticatedData. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
鍵合意アルゴリズムの出力は鍵暗号鍵であり、この鍵暗号鍵はコンテンツ暗号鍵の暗号化に使用されます。鍵合意をサポートするために、鍵ラップアルゴリズム識別子は、EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmおよびAuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールドのKeyWrapAlgorithmパラメーターにあります。ただし、AuthenticatedDataでは、本質的に認証を提供する鍵合意アルゴリズムのみを使用する必要があります。ラップされたコンテンツ暗号化キーはEnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKeyフィールドにあり、ラップされたメッセージ認証キーはAuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKeyフィールドにあります。
A CMS implementation MAY support mixed key-encryption and content-encryption algorithms. For example, a 128-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key.
CMS実装は、キー暗号化アルゴリズムとコンテンツ暗号化アルゴリズムの混合をサポートする場合があります。たとえば、128ビットのRC2コンテンツ暗号化キーは、168ビットのTriple-DESキー暗号化キーでラップされる場合があります。
Triple-DES key encryption has the algorithm identifier:
Triple-DESキー暗号化には、アルゴリズム識別子があります。
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifierパラメータフィールドはNULLでなければなりません。
The key wrap algorithm used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key is specified in section 3.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified in section 3.2 of RFC 3217 [WRAP].
Triple-DESコンテンツ暗号化キーをTriple-DESキー暗号化キーで暗号化するために使用されるキーラップアルゴリズムは、RFC 3217 [WRAP]のセクション3.1で指定されています。対応するキーアンラップアルゴリズムは、RFC 3217 [WRAP]のセクション3.2で指定されています。
Out-of-band distribution of the Triple-DES key-encryption key used to encrypt the Triple-DES content-encryption key is beyond the scope of this document.
Triple-DESコンテンツ暗号化キーの暗号化に使用されるTriple-DESキー暗号化キーの帯域外配布は、このドキュメントの範囲外です。
A CMS implementation MAY support mixed key-encryption and content-encryption algorithms. For example, a 128-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key. Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with a 128-bit RC2 key-encryption key.
CMS実装は、キー暗号化アルゴリズムとコンテンツ暗号化アルゴリズムの混合をサポートする場合があります。たとえば、128ビットのRC2コンテンツ暗号化キーは、168ビットのTriple-DESキー暗号化キーでラップされる場合があります。同様に、40ビットのRC2コンテンツ暗号化キーは、128ビットのRC2キー暗号化キーでラップしてもよい（MAY）。
RC2 key encryption has the algorithm identifier:
RC2キー暗号化には、アルゴリズム識別子があります。
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:
AlgorithmIdentifierパラメーターフィールドはRC2wrapParameterである必要があります。
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the RC2ParameterVersion. For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), because the one octet (A0) encoding represents a negative number.
RC2ParameterVersionでは、32より大きく256より小さいRC2有効キービット（キーサイズ）がエンコードされます。 40、64、および128の有効キービットの場合、rc2ParameterVersion値はそれぞれ160、120、および58です。これらの値は、単にRC2キーの長さではありません。 1オクテット（A0）エンコードは負の数を表すため、値160は2オクテット（00 A0）としてエンコードする必要があることに注意してください。
RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58.
RC2 128ビットキーはキー暗号化キーとして使用する必要があり、RC2ParameterVersionパラメータを58に設定して使用する必要があります。
The key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2 key-encryption key is specified in section 4.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified 4.2 of RFC 3217 [WRAP].
RC2コンテンツ暗号化キーをRC2キー暗号化キーで暗号化するために使用されるキーラップアルゴリズムは、RFC 3217 [WRAP]のセクション4.1で指定されています。対応するキーアンラップアルゴリズムは、RFC 3217 [WRAP]の4.2で指定されています。
Out-of-band distribution of the RC2 key-encryption key used to encrypt the RC2 content-encryption key is beyond of the scope of this document.
RC2コンテンツ暗号化キーの暗号化に使用されるRC2キー暗号化キーの帯域外配布は、このドキュメントの範囲外です。
This section specifies the conventions employed by CMS implementations that support password-based key management using PBKDF2.
このセクションでは、PBKDF2を使用したパスワードベースのキー管理をサポートするCMS実装で採用されている規則を指定します。
Key derivation algorithms are used to convert a password into a key-encryption key as part of the password-based key management technique.
鍵導出アルゴリズムは、パスワードベースの鍵管理手法の一部として、パスワードを鍵暗号鍵に変換するために使用されます。
Key derivation algorithm identifiers are located in the EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm fields.
鍵導出アルゴリズム識別子は、EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithmおよびAuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithmフィールドにあります。
The key-encryption key that is derived from the password is used to encrypt the content-encryption key.
パスワードから派生したキー暗号化キーは、コンテンツ暗号化キーの暗号化に使用されます。
The content-encryption keys encrypted with password-derived key-encryption keys are located in the EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey field. The message-authentication keys encrypted with password-derived key-encryption keys are located in the AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.
パスワード派生キー暗号化キーで暗号化されたコンテンツ暗号化キーは、EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKeyフィールドにあります。パスワード派生のキー暗号化キーで暗号化されたメッセージ認証キーは、AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKeyフィールドにあります。
The PBKDF2 key derivation algorithm is specified in RFC 2898 [PKCS#5]. The KeyDerivationAlgorithmIdentifer identifies the key-derivation algorithm, and any associated parameters used to derive the key-encryption key from the user-supplied password. The algorithm identifier for the PBKDF2 key derivation algorithm is:
PBKDF2鍵導出アルゴリズムは、RFC 2898 [PKCS＃5]で指定されています。 KeyDerivationAlgorithmIdentiferは、キー派生アルゴリズム、およびユーザー指定のパスワードからキー暗号化キーを導出するために使用される関連パラメーターを識別します。 PBKDF2鍵導出アルゴリズムのアルゴリズム識別子は次のとおりです。
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
The AlgorithmIdentifier parameter field MUST be PBKDF2-params:
AlgorithmIdentifierパラメータフィールドはPBKDF2-paramsでなければなりません：
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
Within the PBKDF2-params, the salt MUST use the specified OCTET STRING.
PBKDF2-params内で、ソルトは指定されたOCTET STRINGを使用する必要があります。
5 Content Encryption Algorithms
5コンテンツ暗号化アルゴリズム
This section specifies the conventions employed by CMS implementations that support content encryption using Three-Key Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC mode.
このセクションでは、CBCモードでの3キートリプルDES、CBCモードでの2キートリプルDES、またはCBCモードでのRC2を使用したコンテンツ暗号化をサポートするCMS実装で採用されている規則を指定します。
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 encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent field.
コンテンツ暗号化アルゴリズムは、EnvelopedData EncryptedContentInfo encryptedContentフィールドとEncryptedData EncryptedContentInfo encryptedContentフィールドにあるコンテンツを暗号化するために使用されます。
The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The Triple-DES is composed from three sequential DES [DES] operations: encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different key for each DES operation. Two-Key Triple-DES uses one key for the two encrypt operations and a different key for the decrypt operation. The same algorithm identifiers are used for Three-Key Triple-DES and Two-Key Triple-DES. The algorithm identifier for Triple-DES in Cipher Block Chaining (CBC) mode is:
Triple-DESアルゴリズムは、ANSI X9.52 [3DES]で説明されています。 Triple-DESは、暗号化、復号化、および暗号化の3つの順次DES [DES]操作で構成されています。 Three-Key Triple-DESは、DES操作ごとに異なるキーを使用します。 Two-Key Triple-DESは、2つの暗号化操作に1つのキーを使用し、復号化操作に別のキーを使用します。 Three-Key Triple-DESおよびTwo-Key Triple-DESにも同じアルゴリズム識別子が使用されます。暗号ブロック連鎖（CBC）モードのTriple-DESのアルゴリズム識別子は次のとおりです。
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a CBCParameter:
AlgorithmIdentifierパラメータフィールドが存在する必要があり、パラメータフィールドにはCBCParameterが含まれている必要があります。
CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets
The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm identifier for RC2 in CBC mode is:
RC2アルゴリズムはRFC 2268 [RC2]で説明されています。 CBCモードのRC2のアルゴリズム識別子は次のとおりです。
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a RC2CBCParameter:
AlgorithmIdentifierパラメーターフィールドが存在する必要があり、パラメーターフィールドにはRC2CBCParameterが含まれている必要があります。
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the rc2ParameterVersion. For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), since the one octet (A0) encoding represents a negative number.
RC2ParameterVersionには、32より大きく256未満のRC2有効キービット（キーサイズ）がエンコードされています。 40、64、および128の有効キービットの場合、rc2ParameterVersion値はそれぞれ160、120、および58です。これらの値は、単にRC2キーの長さではありません。 1オクテット（A0）エンコードは負の数を表すため、値160は2オクテット（00 A0）としてエンコードする必要があることに注意してください。
6 Message Authentication Code Algorithms
6メッセージ認証コードアルゴリズム
This section specifies the conventions employed by CMS implementations that support the HMAC with SHA-1 message authentication code (MAC).
このセクションでは、SHA-1メッセージ認証コード（MAC）でHMACをサポートするCMS実装で採用されている規則を指定します。
MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field.
MACアルゴリズム識別子は、AuthenticatedData macAlgorithmフィールドにあります。
MAC values are located in the AuthenticatedData mac field.
MAC値は、AuthenticatedData macフィールドにあります。
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The algorithm identifier for HMAC with SHA-1 is:
SHA-1アルゴリズムを使用したHMACは、RFC 2104 [HMAC]で説明されています。 SHA-1を使用するHMACのアルゴリズム識別子は次のとおりです。
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) 8 1 2 }
There are two possible encodings for the HMAC with SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for the AlgorithmIdentifier type was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations may encode parameters as a NULL while others omit them entirely.
SMAC-1 AlgorithmIdentifierパラメータフィールドを持つHMACには、2つの可能なエンコーディングがあります。 2つの選択肢は、AlgorithmIdentifierタイプの1988構文が1997構文に変換されたときに、AlgorithmIdentifierパラメーターに関連付けられたOPTIONALが失われたという事実から生じます。その後、OPTIONALは欠陥レポートによって回復しましたが、それまでに多くの人がアルゴリズムパラメータは必須であると考えていました。この履歴があるため、一部の実装ではパラメータをNULLとしてエンコードする場合があり、他の実装では完全に省略される場合があります。
The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate HMAC with SHA-1 AlgorithmIdentifiers with absent parameters.
AlgorithmIdentifierパラメータフィールドはオプションです。存在する場合、パラメータフィールドにはNULLが含まれている必要があります。実装は、パラメータのないSHA-1 AlgorithmIdentifiersでHMACを受け入れる必要があります。実装は、NULLパラメータを持つSHA-1 AlgorithmIdentifiersでHMACを受け入れる必要があります。実装は、パラメータのないSHA-1 AlgorithmIdentifiersでHMACを生成する必要があります。
7 ASN.1 Module
7 ASN.1モジュール
CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } ;
-- Algorithm Identifiers
-アルゴリズム識別子
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9cm(4) 1 }
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57(10040) x9cm(4) 3 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
-- Public Key Types
-公開鍵のタイプ
Dss-Pub-Key ::= INTEGER -- Y
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
DHPublicKey ::= INTEGER -- y = g^x mod p
-- Signature Value Types
-署名値タイプ
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
-- Algorithm Identifier Parameter Types
-アルゴリズム識別子のパラメータータイプ
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
DHDomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor
validationParms ValidationParms OPTIONAL }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
KeyWrapAlgorithm ::= AlgorithmIdentifier
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
END -- of CryptographicMessageSyntaxAlgorithms
8 References
8参照
[3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
[3DES] American National Standards Institute。 ANSI X9.52-1998、トリプルデータ暗号化アルゴリズムの動作モード。 1998年
[CERTALGS] Bassham, L., Housley, R. and W. Polk, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[CERTALGS] Bassham、L.、Housley、R。およびW. Polk、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3269, August 2002.
[CMS] Housley、R。、「Cryptographic Message Syntax」、RFC 3269、2002年8月。
[DES] American National Standards Institute. ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption". 1983.
[DES] American National Standards Institute。 ANSI X3.106、「情報システムの米国規格-データリンク暗号化」。 1983。
[DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[DH-X9.42] Rescorla、E。、「Diffie-Hellman Key Agreement Method」、RFC 2631、1999年6月。
[DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[DSS]国立標準技術研究所。 FIPS Pub 186：デジタル署名標準。 1994年5月19日。
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H。、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[MMA] Rescorla, E., "Preventing the Million Message Attack on CMS", RFC 3218, January 2002.
[MMA] Rescorla、E。、「CMSに対するミリオンメッセージ攻撃の防止」、RFC 3218、2002年1月。
[MODES] National Institute of Standards and Technology. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
[モード]国立標準技術研究所。 FIPS Pub 81：DESの動作モード。 1980年12月2日。
[NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Encryption, Version 2.0, RFC 2437, October 1998.
[NEWPKCS＃1] Kaliski、B。およびJ. Staddon、「PKCS＃1：RSA Encryption、バージョン2.0、RFC 2437、1998年10月。
[OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[OLDCMS] Housley、R。、「Cryptographic Message Syntax」、RFC 2630、1999年6月。
[PKCS#1] Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October, 1998.
[PKCS＃1] Kaliski、B、「PKCS＃1：RSA Encryption、バージョン2.0」、RFC 2437、1998年10月。
[PKCS#5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification", RFC 2898, September 2000.
[PKCS＃5] Kaliski、B。、「PKCS＃5：Password-Based Cryptography Specification」、RFC 2898、2000年9月。
[PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[プロファイル] Housley、R.、Ford、W.、Polk、W。、およびD. Solo、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[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、December 1994。
[RC2] Rivest, R., "A Description of the RC2 (r) Encryption Algorithm", RFC 2268, March 1998.
[RC2] Rivest、R。、「A Description of the RC2（r）Encryption Algorithm」、RFC 2268、March 1998。
[SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
[SHA1]国立標準技術研究所。 FIPS Pub 180-1：Secure Hash Standard。 1995年4月17日。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[WRAP] Housley、R。、「Triple-DES and RC2 Key Wrapping」、RFC 3217、2001年12月。
[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。
9 Security Considerations
9セキュリティに関する考慮事項
The CMS provides a method for digitally signing data, digesting data, encrypting data, and authenticating data. This document identifies the conventions for using several cryptographic algorithms for use with the CMS.
CMSは、データのデジタル署名、データのダイジェスト、データの暗号化、およびデータの認証を行う方法を提供します。このドキュメントでは、CMSで使用するためのいくつかの暗号化アルゴリズムを使用するための規則を識別します。
Implementations must protect the signer's private key. Compromise of the signer's private key permits masquerade.
実装では、署名者の秘密鍵を保護する必要があります。署名者の秘密鍵の侵害により、なりすましが許可されます。
Implementations must protect the key management private key, the key-encryption key, and the content-encryption key. Compromise of the key management private key or the key-encryption key may result in the disclosure of all contents protected with that key. Similarly, compromise of the content-encryption key may result in disclosure of the associated encrypted content.
実装では、キー管理秘密キー、キー暗号化キー、およびコンテンツ暗号化キーを保護する必要があります。鍵管理の秘密鍵または鍵暗号化鍵が侵害されると、その鍵で保護されているすべてのコンテンツが漏洩する可能性があります。同様に、コンテンツ暗号化キーの侵害により、関連する暗号化コンテンツが開示される可能性があります。
Implementations must protect the key management private key and the message-authentication key. Compromise of the key management private key permits masquerade of authenticated data. Similarly, compromise of the message-authentication key may result in undetectable modification of the authenticated content.
実装では、鍵管理の秘密鍵とメッセージ認証鍵を保護する必要があります。鍵管理の秘密鍵の侵害により、認証されたデータのなりすましが許可されます。同様に、メッセージ認証キーの侵害は、認証されたコンテンツの検出不可能な変更をもたらす可能性があります。
The key management technique employed to distribute message-authentication keys must itself provide authentication, otherwise the content is delivered with integrity from an unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provide the necessary data origin authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary data origin authentication when both the originator and recipient public keys are bound to appropriate identities in X.509 certificates [PROFILE].
メッセージ認証キーを配布するために使用されるキー管理技術は、それ自体が認証を提供する必要があります。そうでない場合、コンテンツは不明なソースから整合性を保って配信されます。 RSA [PKCS＃1、NEWPKCS＃1]もEphemeral-Static Diffie-Hellman [DH-X9.42]も、必要なデータオリジン認証を提供しません。 Static-Static Diffie-Hellman [DH-X9.42]は、発信者と受信者の両方の公開鍵がX.509証明書[PROFILE]の適切なIDにバインドされている場合に、必要なデータ発信元認証を提供します。
When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties.
3つ以上のパーティが同じメッセージ認証キーを共有する場合、データ発信元認証は提供されません。メッセージ認証キーを知っているすべての関係者が有効なMACを計算できるため、コンテンツはいずれかの関係者から発信されます。
Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), one-time values (such as the k value when generating a DSA signature), and padding. Also, the generation of public/private key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic such 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, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
実装では、コンテンツ暗号化キー、メッセージ認証キー、初期化ベクトル（IV）、1回限りの値（DSA署名を生成するときのk値など）、およびパディングをランダムに生成する必要があります。また、公開鍵と秘密鍵のペアの生成は、乱数に依存しています。不適切な疑似乱数ジェネレーター（PRNG）を使用してこのような値を暗号化すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、キーを生成したPRNG環境を再現し、結果として生じる可能性の小さなセットを検索する方がはるかに簡単であることに気付くでしょう。高品質の乱数の生成は困難です。 RFC 1750 [ランダム]はこの分野で重要なガイダンスを提供し、FIPS Pub 186 [DSS]の付録3は1つの高品質なPRNG技術を提供します。
When using key agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with 168-bit Triple-DES and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms.
鍵合意アルゴリズムまたは以前に配布された対称鍵暗号鍵を使用する場合、鍵暗号鍵を使用してコンテンツ暗号鍵を暗号化します。キー暗号化アルゴリズムとコンテンツ暗号化アルゴリズムが異なる場合、効果的なセキュリティは2つのアルゴリズムのうち弱い方によって決定されます。たとえば、コンテンツが168ビットのTriple-DESで暗号化され、Triple-DESコンテンツ暗号化キーが40ビットのRC2キーでラップされている場合、最大40ビットの保護が提供されます。 40ビットのRC2鍵の値を判別するための簡単な検索で、Triple-DES鍵をリカバリーできます。次に、Triple-DES鍵を使用してコンテンツを暗号化解除できます。したがって、実装者は、キー暗号化アルゴリズムがコンテンツ暗号化アルゴリズムと同じかそれよりも強力であることを確認する必要があります。
RFC 3217 [WRAP] specifies key wrap algorithms used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key-encryption key [RC2]. The key wrap algorithms makes use of CBC mode [MODES]. These key wrap algorithms have been reviewed for use with Triple-DES and RC2. They have not been reviewed for use with other cryptographic modes or other encryption algorithms. Therefore, if a CMS implementation wishes to support ciphers in addition to Triple-DES or RC2, then additional key wrap algorithms need to be defined to support the additional ciphers.
RFC 3217 [WRAP]は、トリプルDESコンテンツ暗号化キーをトリプルDESキー暗号化キー[3DES]で暗号化するか、RC2コンテンツ暗号化キーをRC2キー暗号化キー[RC2]で暗号化するために使用されるキーラップアルゴリズムを指定します]。キーラップアルゴリズムは、CBCモード[モード]を使用します。これらのキーラップアルゴリズムは、Triple-DESおよびRC2で使用するために確認されています。他の暗号化モードや他の暗号化アルゴリズムでの使用については確認されていません。したがって、CMS実装がTriple-DESまたはRC2に加えて暗号をサポートすることを望む場合、追加の暗号をサポートするために追加のキーラップアルゴリズムを定義する必要があります。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should be modular allowing new algorithms to be readily inserted. That is, implementers should be prepared to regularly update the set of algorithms in their implementations.
実装者は、暗号化アルゴリズムが時間とともに弱くなることを認識する必要があります。新しい暗号解読技術が開発され、コンピューティングパフォーマンスが向上すると、特定の暗号化アルゴリズムを解読する作業要素が減少します。したがって、暗号化アルゴリズムの実装は、新しいアルゴリズムを簡単に挿入できるようにモジュール化する必要があります。つまり、実装者は、実装のアルゴリズムセットを定期的に更新する準備を整える必要があります。
Users of the CMS, particularly those employing the CMS to support interactive applications, should be aware that RSA (PKCS #1 v1.5), as specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen ciphertext attacks when applied for encryption purposes. Exploitation of this identified vulnerability, revealing the result of a particular RSA decryption, requires access to an oracle which will respond to a large number of ciphertexts (based on currently available results, hundreds of thousands or more), which are constructed adaptively in response to previously-received replies providing information on the successes or failures of attempted decryption operations. As a result, the attack appears significantly less feasible to perpetrate for store-and-forward S/MIME environments than for directly interactive protocols. Where the CMS constructs are applied as an intermediate encryption layer within an interactive request-response communications environment, exploitation could be more feasible.
CMSのユーザー、特にインタラクティブアプリケーションをサポートするためにCMSを使用しているユーザーは、RSA（PKCS＃1 v1.5）がRFC 2313 [PKCS＃1]で指定されているように、適用時に選択された適応暗号文攻撃に対して脆弱であることを認識する必要があります。暗号化の目的。特定のRSA復号の結果を明らかにするこの特定された脆弱性の悪用には、多数の暗号文に応答するオラクルへのアクセスが必要です（現在利用可能な結果、数十万以上に基づいて）。以前に受信した応答で、解読操作の試行の成功または失敗に関する情報が提供されます。その結果、ストアアンドフォワードS / MIME環境では、直接対話型プロトコルよりも攻撃の実行可能性が大幅に低下します。 CMSコンストラクトが対話型の要求と応答の通信環境内の中間暗号化層として適用される場合、悪用はより現実的になる可能性があります。
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1 Version 2.0 preserves support for the encryption padding format defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 Version 2.0 specifies and recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption is used to provide confidentiality. Designers of protocols and systems employing CMS for interactive environments should either consider usage of OAEP, or should ensure that information which could reveal the success or failure of attempted PKCS #1 Version 1.5 decryption operations is not provided. Support for OAEP will likely be added to a future version of the CMS algorithm specification.
PKCS＃1の更新バージョン、PKCS＃1バージョン2.0 [NEWPKCS＃1]が公開されました。この更新されたドキュメントは、RFC 2313に取って代わります。PKCS＃1バージョン2.0は、PKCS＃1バージョン1.5 [PKCS＃1]で定義された暗号化パディングフォーマットのサポートを維持し、新しい代替も定義します。選択された適応暗号文の脆弱性を解決するために、PKCS＃1バージョン2.0は、RSA暗号化を使用して機密性を提供するときに、最適な非対称暗号化パディング（OAEP）の使用を指定および推奨しています。対話型環境でCMSを使用するプロトコルとシステムの設計者は、OAEPの使用を検討するか、試行されたPKCS＃1バージョン1.5復号化操作の成功または失敗を明らかにする情報が提供されないようにする必要があります。 OAEPのサポートは、CMSアルゴリズム仕様の将来のバージョンに追加される可能性があります。
See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations.
PKCS＃1バージョン1.5の実装における適応型暗号文の脆弱性の阻止について詳しくは、RFC 3218 [MMA]をご覧ください。
10 Acknowledgments
10謝辞
This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave Solo for their efforts and support.
このドキュメントは、多くの専門家からの寄稿の結果です。 IETF S / MIMEワーキンググループのすべてのメンバーのハードワークに感謝します。 Rich Ankney、Simon Blake-Wilson、Tim Dean、Steve Dusse、Carl Ellison、Peter Gutmann、Bob Jueneman、Stephen Henson、Paul Hoffman、Scott Hollenbeck、Don Johnson、Burt Kaliski、John Linn、John Pawling、 Blake Ramsdell、Francois Rousseau、Jim Schaad、Dave Soloの努力とサポートに感謝します。
11 Author Address
11著者アドレス
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 EMail: rhousley@rsasecurity.com
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon、VA 20170 Eメール：rhousley@rsasecurity.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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 assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
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から提供されています。