RFC 4056 - Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4056
タイトル : RFC 4056 - 暗号メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用
翻訳編集 : 自動生成

[要約] RFC 4056は、CMSでRSASSA-PSS署名アルゴリズムを使用するためのガイドラインです。その目的は、より強力な署名アルゴリズムの使用を促進し、セキュリティを向上させることです。

Network Working Group                                          J. Schaad
Request for Comments: 4056                       Soaring Hawk Consulting
Category: Standards Track                                      June 2005

Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)

暗号メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS).

このドキュメントでは、RSASSA-PSS（RSA確率的署名方式）デジタル署名アルゴリズムを暗号化メッセージ構文（CMS）で使用するための規則を指定します。

1. Overview

1. 概観

This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) [P1v2.1] digital signature algorithm with the Cryptographic Message Syntax [CMS] signed-data content type.

このドキュメントでは、RSA確率的署名方式（RSASSA-PSS）[P1v2.1]デジタル署名アルゴリズムを暗号化メッセージ構文[CMS]署名付きデータコンテンツタイプで使用するための規則を指定します。

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]を使用して生成されます。

This document is written to be used in conjunction with RFC 4055 [RSA-ALGS]. All of the ASN.1 structures referenced in this document are defined in RFC 4055.

このドキュメントは、RFC 4055 [RSA-ALGS]と組み合わせて使用するように作成されています。このドキュメントで参照されているすべてのASN.1構造は、RFC 4055で定義されています。

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 RFC 2119 [STDWORDS].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [STDWORDS]で説明されているように解釈されます。

1.1. PSS Algorithm

1.1. PSSアルゴリズム

Although there are no known defects with the PKCS #1 v1.5 [P1v1.5] signature algorithm, RSASSA-PSS [P1v2.1] was developed in an effort to have more mathematically provable security. PKCS #1 v1.5 signatures were developed in an ad hoc manner; RSASSA-PSS was developed based on mathematical foundations.

PKCS＃1 v1.5 [P1v1.5]署名アルゴリズムには既知の欠陥はありませんが、RSASSA-PSS [P1v2.1]は、より数学的に証明可能なセキュリティを確保するために開発されました。 PKCS＃1 v1.5シグネチャはアドホックな方法で開発されました。 RSASSA-PSSは、数学的な基礎に基づいて開発されました。

2. Algorithm Identifiers and Parameters

2. アルゴリズムの識別子とパラメーター

2.1. Certificate Identifiers

2.1. 証明書識別子

The RSASSA-PSS signature algorithm is defined in RFC 3447 [P1v2.1]. Conventions for encoding the public key are defined in RFC 4055 [RSA-ALGS].

RSASSA-PSS署名アルゴリズムはRFC 3447 [P1v2.1]で定義されています。公開鍵をエンコードするための規則は、RFC 4055 [RSA-ALGS]で定義されています。

Two algorithm identifiers for RSA subject public keys in certificates are used. These are:

証明書のRSAサブジェクト公開鍵には2つのアルゴリズム識別子が使用されます。これらは：

      rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }

and

そして

      id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }

When the rsaEncryption algorithm identifier is used for a public key, the AlgorithmIdentifier parameters field MUST contain NULL. Complete details can be found in [RSA-ALGS].

rsaEncryptionアルゴリズム識別子が公開鍵に使用される場合、AlgorithmIdentifierパラメータフィールドにはNULLが含まれている必要があります。詳細については、[RSA-ALGS]をご覧ください。

When the id-RSASSA-PSS algorithm identifier is used for a public key, the AlgorithmIdentifier parameters field MUST either be absent or contain RSASSA-PSS-params. Again, complete details can be found in [RSA-ALGS].

id-RSASSA-PSSアルゴリズム識別子が公開鍵に使用される場合、AlgorithmIdentifierパラメータフィールドは存在しないか、RSASSA-PSS-paramsを含んでいる必要があります。繰り返しますが、完全な詳細は[RSA-ALGS]にあります。

In both cases, 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.

どちらの場合も、モジュラスと公開指数で構成されるRSA公開鍵は、RSAPublicKeyタイプを使用してエンコードする必要があります。このエンコーディングの出力は、証明書のサブジェクトの公開鍵で運ばれます。

         RSAPublicKey ::= SEQUENCE {
            modulus INTEGER, -- n
            publicExponent INTEGER } -- e

2.2. Signature Identifiers

2.2. 署名識別子

The algorithm identifier for RSASAA-PSS signatures is:

RSASAA-PSS署名のアルゴリズム識別子は次のとおりです。

      id-RSASSA-PSS OBJECT IDENTIFIER ::= {pkcs-1 10 }

When the id-RSASSA-PSS algorithm identifier is used for a signature, the AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-params. Information about RSASSA-PSS-params can be found in [RSA-ALGS].

id-RSASSA-PSSアルゴリズム識別子が署名に使用される場合、AlgorithmIdentifierパラメータフィールドにはRSASSA-PSS-paramsが含まれている必要があります。 RSASSA-PSS-paramsに関する情報は、[RSA-ALGS]にあります。

When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value.

署名するとき、RSAアルゴリズムは単一の値を生成し、その値は署名値として直接使用されます。

3. Signed-data Conventions

3. 署名済みデータの規約

digestAlgorithms SHOULD contain the one-way hash function used to compute the message digest on the eContent value.

digestAlgorithmsには、eContent値のメッセージダイジェストを計算するために使用される一方向ハッシュ関数が含まれている必要があります（SHOULD）。

The same one-way hash function SHOULD be used for computing the message digest on both the eContent and the signedAttributes value if signedAttributes exist.

同じ一方向ハッシュ関数は、signedAttributesが存在する場合、eContentとsignedAttributes値の両方でメッセージダイジェストを計算するために使用する必要があります（SHOULD）。

The same one-way hash function MUST be used for computing the message digest on the signedAttributes and as the hashAlgorithm in the RSA-PSS-params structure.

signedAttributesのメッセージダイジェストを計算する場合、およびRSA-PSS-params構造のhashAlgorithmと同じ一方向ハッシュ関数を使用する必要があります。

signatureAlgorithm MUST contain id-RSASSA-PSS. The algorithm parameters field MUST contain RSASSA-PSS-params.

signatureAlgorithmにはid-RSASSA-PSSが含まれている必要があります。アルゴリズムパラメータフィールドには、RSASSA-PSS-paramsが含まれている必要があります。

signature contains the single value resulting from the signing operation.

signatureには、署名操作の結果の単一の値が含まれます。

If the subjectPublicKeyInfo algorithm identifier for the public key in the certificate is id-RSASSA-PSS and the parameters field is present, the following additional steps MUST be done as part of signature validation:

証明書の公開鍵のsubjectPublicKeyInfoアルゴリズム識別子がid-RSASSA-PSSで、parametersフィールドが存在する場合、署名検証の一部として次の追加手順を実行する必要があります。

1. The hashAlgorithm field in the certificate subjectPublicKey.algorithm parameters and the signatureAlgorithm parameters MUST be the same.

1. 証明書のsubjectPublicKey.algorithmパラメーターとsignatureAlgorithmパラメーターのhashAlgorithmフィールドは同じでなければなりません。

2. The maskGenAlgorithm field in the certificate subjectPublicKey.algorithm parameters and the signatureAlgorithm parameters MUST be the same.

2. 証明書のsubjectPublicKey.algorithmパラメーターとsignatureAlgorithmパラメーターのmaskGenAlgorithmフィールドは同じでなければなりません。

3. The saltLength in the signatureAlgorithm parameters MUST be greater or equal to the saltLength in the certificate subjectPublicKey.algorithm parameters.

3. signatureAlgorithmパラメーターのsaltLengthは、証明書のsubjectPublicKey.algorithmパラメーターのsaltLength以上でなければなりません。

4. The trailerField in the certificate subjectPublicKey.algorithm parameters and signatureAlgorithm parameters MUST be the same.

4. 証明書のsubjectPublicKey.algorithmパラメータとsignatureAlgorithmパラメータのTrailerFieldは同じである必要があります。

In doing the above comparisons, default values are considered to be the same as extant values. If any of the above four steps is not true, the signature checking algorithm MUST fail validation.

上記の比較では、デフォルト値は現存の値と同じであると見なされます。上記の4つのステップのいずれかが当てはまらない場合、署名チェックアルゴリズムは検証に失敗する必要があります。

4. Security Considerations

4. セキュリティに関する考慮事項

Implementations must protect the RSA private key. Compromise of the RSA private key may result in the ability to forge signatures.

実装では、RSA秘密鍵を保護する必要があります。 RSA秘密鍵の侵害により、署名を偽造できる可能性があります。

The generation of RSA private key 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.

RSA秘密鍵の生成は、乱数に依存します。これらの値を生成するために不適切な疑似乱数ジェネレータ（PRNG）を使用すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、キーを生成したPRNG環境を再現し、結果として生じる可能性の小さなセットを検索する方がはるかに簡単であることに気付くでしょう。高品質の乱数の生成は困難です。 RFC 1750 [ランダム]は、この分野で重要なガイダンスを提供しています。

Using the same private key for different algorithms has the potential of allowing an attacker to get extra information about the key. It is strongly suggested that the same key not be used for both the PKCS #1 v1.5 and RSASSA-PSS signature algorithms.

異なるアルゴリズムに同じ秘密鍵を使用すると、攻撃者が鍵に関する追加情報を入手できる可能性があります。 PKCS＃1 v1.5とRSASSA-PSS署名アルゴリズムの両方に同じ鍵を使用しないことを強くお勧めします。

When computing signatures, the same hash function should be used for all operations. This reduces the number of failure points in the signature process.

署名を計算するときは、すべての操作で同じハッシュ関数を使用する必要があります。これにより、署名プロセスの失敗ポイントの数が減少します。

The parameter checking procedures outlined in section 3 are of special importance. It is possible to forge signatures by changing (especially to weaker values) these parameter values. Signers using this algorithm should take care that only one set of parameter values is used as this decreases the possibility of leaking information.

セクション3で説明されているパラメータチェック手順は、特に重要です。これらのパラメーター値を（特により弱い値に）変更することにより、署名を偽造することが可能です。このアルゴリズムを使用する署名者は、情報の漏洩の可能性を減らすため、パラメーター値の1つのセットのみが使用されるように注意する必要があります。

5. Normative References

5. 引用文献

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.

[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3852、2004年7月。

[P1v2.1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.

[P1v2.1] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。

[RSA-ALGS] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.

[RSA-ALGS] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムおよび識別子」、 RFC 4055、2005年6月。

[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月。

[X.208-88] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1998.

[X.208-88] CCITT勧告X.208：Abstract Syntax Notation One（ASN.1）の仕様、1998年。

[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。

6. Informative References

6. 参考引用

[P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.

[P1v1.5] Kaliski、B。、「PKCS＃1：RSA Encryption Version 1.5」、RFC 2313、1998年3月。

[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

[ランダム] Eastlake 3rd、D.、Crocker、S。、およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。

Author' Address

著者のアドレス

Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251

じｍＳちゃあｄそありんｇはｗｋこんすｌちんｇぽぼｘ６７５ごｌｄばｒ、わ９８２５１

   EMail: jimsch@exmsft.com

Full Copyright Statement

完全な著作権表示

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。