RFC4056 日本語訳

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

Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: カテゴリに相談する4056年の高く昇っているタカ: 標準化過程2005年6月

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

暗号のメッセージ構文におけるRSASSA-PSS署名アルゴリズムの使用(cm)

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

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

このドキュメントはCryptographic Message Syntax(CMS)と共にRSASSA-PSS(RSA Probabilistic Signature Scheme)デジタル署名アルゴリズムを使用するのにコンベンションを指定します。

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.

このドキュメントはCryptographic Message Syntax[CMS]署名しているデータcontent typeでRSA Probabilistic Signature Scheme(RSASSA-PSS)[P1v2.1]デジタル署名アルゴリズムを使用するのにコンベンションを指定します。

   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].

ASN.1[X.208-88]を使用するのはCMS値に生成されます、Basic Encoding Rules(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.

このドキュメントは、RFC4055[RSA-ALGS]に関連して使用されるために書かれています。 本書では参照をつけられるASN.1構造のすべてがRFC4055で定義されます。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[STDWORDS]で説明されるように本書では解釈されることであるべきですか?

Schaad                      Standards Track                     [Page 1]

RFC 4056                 CMS and PSS Signature                 June 2005

4056cmのSchaad標準化過程[1ページ]RFCとPSS署名2005年6月

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#1v1.5[P1v1.5]署名アルゴリズムがある欠陥が知られていませんでしたが、RSASSA-PSS[P1v2.1]は、より数学的に証明可能なセキュリティを持つために取り組みで開発されました。 PKCS#1v1.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署名アルゴリズムはRFC3447[P1v2.1]で定義されます。 公開鍵をコード化するためのコンベンションはRFC4055[RSA-ALGS]で定義されます。

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

証明書のRSAの対象の公開鍵のための2つのアルゴリズム識別子が使用されています。 これらは以下の通りです。

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

rsaEncryptionオブジェクト識別子:、:= pkcs-1 1

   and

そして

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

イド-RSASSA-PSSオブジェクト識別子:、:= 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].

イド-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.

どちらの場合も、RSAPublicKeyタイプを使用して、RSA公開鍵(係数と公共の解説者で構成される)をコード化しなければなりません。 このコード化の出力は証明書対象公開鍵で運ばれます。

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

RSAPublicKey:、:= SEQUENCE、係数INTEGER--、n publicExponent INTEGER、--、e

Schaad                      Standards Track                     [Page 2]

RFC 4056                 CMS and PSS Signature                 June 2005

4056cmのSchaad標準化過程[2ページ]RFCとPSS署名2005年6月

2.2.  Signature Identifiers

2.2. 署名識別子

   The algorithm identifier for RSASAA-PSS signatures is:

RSASAA-PSS署名のためのアルゴリズム識別子は以下の通りです。

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

イド-RSASSA-PSSオブジェクト識別子:、:= 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].

イド-RSASSA-PSSアルゴリズム識別子が署名に使用されるとき、AlgorithmIdentifierパラメタ分野はRSASSA-PSS- paramsを含まなければなりません。[RSA- ALGS]でRSASSA-PSS-paramsに関する情報は見つけることができます。

   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 SHOULDはeContent値でメッセージダイジェストを計算するのに使用される一方向ハッシュ関数を含んでいます。

   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.

機能SHOULDを論じ尽くしてください。同じである、一方向、signedAttributesが存在しているならeContentとsignedAttributes値の両方でメッセージダイジェストを計算するには、使用されてください。

   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とhashAlgorithmとしてRSA- PSS-params構造でメッセージダイジェストを計算するのに同じ一方向ハッシュ関数を使用しなければなりません。

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

signatureAlgorithmはイド-RSASSA-PSSを含まなければなりません。 アルゴリズムパラメタ分野はRSASSA-PSS-paramsを含まなければなりません。

   signature contains the single value resulting from the signing
   operation.

署名は署名操作から生じるただ一つの値を含んでいます。

   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アルゴリズム識別子がイド-RSASSA-PSSとパラメタであるなら存在している、署名合法化の一部として以下の追加ステップをしなければなりません:

   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分野は同じであるに違いありません。

Schaad                      Standards Track                     [Page 3]

RFC 4056                 CMS and PSS Signature                 June 2005

4056cmのSchaad標準化過程[3ページ]RFCとPSS署名2005年6月

   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秘密鍵の世代は乱数を当てにします。 これらの値を生成する不十分な疑似乱数生成器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、キーを生産したPRNG環境を再生させるのがはるかに簡単であることがわかるかもしれません、全体の主要なスペースを捜す馬鹿力よりむしろ結果として起こる小さい可能性を捜して。 上質の乱数の世代は難しいです。 RFC1750[RANDOM]はこの領域で重要な指導を提供します。

   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#1v1.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セットのパラメタ値だけが使用されていることに注意するはずです。

Schaad                      Standards Track                     [Page 4]

RFC 4056                 CMS and PSS Signature                 June 2005

4056cmのSchaad標準化過程[4ページ]RFCとPSS署名2005年6月

5.  Normative References

5. 引用規格

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

[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日

   [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公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)が輪郭を描く使用のためのRSA Cryptographyのための追加AlgorithmsとIdentifiers」、RFC4055(2005年6月)

   [STDWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[X.208-88]CCITT推薦X.208: 抽象構文記法1(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:」 1.5インチ(RFC2313)が1998に行進させるRSA暗号化バージョン

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

イーストレーク[無作為]の3番目、D.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750、1994年12月。

Author' Address

'作者'というアドレス

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

ジムSchaad高く昇るタカのコンサルティング私書箱675金の延べ棒、ワシントン 98251

   EMail: jimsch@exmsft.com

メール: jimsch@exmsft.com

Schaad                      Standards Track                     [Page 5]

RFC 4056                 CMS and PSS Signature                 June 2005

4056cmのSchaad標準化過程[5ページ]RFCとPSS署名2005年6月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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はこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Schaad                      Standards Track                     [Page 6]

Schaad標準化過程[6ページ]