Network Working Group J. Schaad
Request for Comments: 4056 Soaring Hawk Consulting
Category: Standards Track June 2005
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（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).
本文件规定了使用带有加密消息语法（CMS）的RSASSA-PSS（RSA概率签名方案）数字签名算法的约定。
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]和可分辨编码规则（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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
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是基于数学基础开发的。
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主题公钥使用了两个算法标识符。这些是：
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
and
和
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
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].
当RSA加密算法标识符用于公钥时，AlgorithmIdentifier parameters字段必须包含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 parameters字段必须不存在或包含RSASSA PSS参数。同样，完整的详细信息可以在[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
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
The algorithm identifier for RSASAA-PSS signatures is:
RSASAA-PSS签名的算法标识符为：
id-RSASSA-PSS OBJECT IDENTIFIER ::= {pkcs-1 10 }
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参数。有关RSASSA PSS参数的信息可在[RSA-ALGS]中找到。
When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value.
签名时，RSA算法生成一个值，该值直接用作签名值。
digestAlgorithms SHOULD contain the one-way hash function used to compute the message digest on the eContent value.
digestAlgorithms应该包含用于计算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.
如果存在SignedAttribute，则应使用相同的单向哈希函数计算eContent和SignedAttribute值上的消息摘要。
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.
必须使用相同的单向散列函数来计算SignedAttribute上的消息摘要，以及RSA PSS params结构中的散列算法。
signatureAlgorithm MUST contain id-RSASSA-PSS. The algorithm parameters field MUST contain RSASSA-PSS-params.
签名算法必须包含id RSASSA PSS。算法参数字段必须包含RSASSA PSS参数。
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算法标识符为id RSASSA PSS且存在参数字段，则必须执行以下附加步骤作为签名验证的一部分：
1. The hashAlgorithm field in the certificate subjectPublicKey.algorithm parameters and the signatureAlgorithm parameters MUST be the same.
1. 证书subjectPublicKey.algorithm参数中的hashAlgorithm字段和signatureAlgorithm参数必须相同。
2. The maskGenAlgorithm field in the certificate subjectPublicKey.algorithm parameters and the signatureAlgorithm parameters MUST be the same.
2. 证书主题PublicKey.algorithm参数和signatureAlgorithm参数中的MaskGetAlgorithm字段必须相同。
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. 证书主题PublicKey.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.
在进行上述比较时，默认值被视为与现有值相同。如果上述四个步骤中的任何一个不正确，签名检查算法必须通过验证。
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节中概述的参数检查程序特别重要。可以通过更改（尤其是更改为较弱的值）这些参数值来伪造签名。使用此算法的签名者应注意只使用一组参数值，因为这降低了信息泄漏的可能性。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年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，“公钥密码标准（PKCS）#1:RSA密码规范版本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：抽象语法符号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年。
[P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[P1v1.5]Kaliski，B.，“PKCS#1:RSA加密版本1.5”，RFC 2313，1998年3月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RANDOM]Eastlake 3rd，D.，Crocker，S.，和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
Author' Address
作者地址
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Smalling Hawk咨询公司华盛顿金条675号邮政信箱98251
EMail: jimsch@exmsft.com
EMail: jimsch@exmsft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（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.
本文件受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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。