Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 5756                                          IECA
Updates: 4055                                                   D. Brown
Category: Standards Track                                       Certicom
ISSN: 2070-1721                                                   K. Yiu
                                                               Microsoft
                                                              R. Housley
                                                          Vigil Security
                                                                 T. Polk
                                                                    NIST
                                                            January 2010
        
Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 5756                                          IECA
Updates: 4055                                                   D. Brown
Category: Standards Track                                       Certicom
ISSN: 2070-1721                                                   K. Yiu
                                                               Microsoft
                                                              R. Housley
                                                          Vigil Security
                                                                 T. Polk
                                                                    NIST
                                                            January 2010
        

Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters

RSAES-OAEP和RSASSA-PSS算法参数的更新

Abstract

摘要

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field.

本文件更新了RFC 4055。它更新了在Internet X.509公钥基础设施(PKI)中使用RSA加密方案-最优非对称加密填充(RSAES-OAEP)密钥传输算法的约定。具体来说,它更新了X.509证书的subjectPublicKeyInfo字段中算法参数的约定。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5756.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc5756.

Copyright Notice

版权公告

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您在以下方面的权利和限制:

to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下,不得在IETF标准流程之外修改本文件,也不得在IETF标准流程之外创建其衍生作品,除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。

1. Introduction
1. 介绍

RFC 4055 specifies conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). It provides algorithm identifiers and parameters for RSAES-OAEP.

RFC 4055规定了在Internet X.509公钥基础设施(PKI)中使用RSA加密方案-最优非对称加密填充(RSAES-OAEP)密钥传输算法的约定。它为RSAES-OAEP提供算法标识符和参数。

This document updates the conventions for RSAES-OAEP parameters in the subjectPublicKeyInfo field of an X.509 certificate. The PKIX WG Elliptic Curve Cryptography (ECC) design team recommended that Key Derivation Functions (KDFs) should not be constrained within a certificate; rather, KDF constraints should be negotiated in protocols that need to employ certificates.

本文档更新X.509证书subjectPublicKeyInfo字段中RSAES-OAEP参数的约定。PKIX WG椭圆曲线密码(ECC)设计团队建议密钥派生函数(KDF)不应限制在证书内;相反,应该在需要使用证书的协议中协商KDF约束。

Only two paragraphs in [RFC4055] discuss RSAES-OAEP parameters in X.509 certificates: the second paragraph of Section 4 and the first paragraph of Section 4.1. This document only updates these two paragraphs. Section 3 updates the second paragraph in Section 4 of [RFC4055], while Section 4 updates the second paragraph in Section 4.1 of [RFC4055]. "Old:" prefaces the text to be replaced and "New:" prefaces the replacement text.

[RFC4055]中只有两段讨论了X.509证书中的RSAES-OAEP参数:第4节第二段和第4.1节第一段。本文件仅更新了这两段内容。第3节更新了[RFC4055]第4节中的第二段,而第4节更新了[RFC4055]第4.1节中的第二段。“Old:”作为要替换的文本的开头,“New:”作为替换文本的开头。

This document also replaces incorrect references to the publicKeyAlgorithms field in Section 3 with references to the parameters field in the subjectPublicKeyInfo algorithm field. Section 3 also rewords the second and third paragraphs for clarity.

本文档还将第3节中对PublicKeyInfo算法字段的错误引用替换为对subjectPublicKeyInfo算法字段中参数字段的引用。第3节还改写了第二段和第三段,以便于澄清。

1.1. Conventions Used in This Document
1.1. 本文件中使用的公约

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

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

2. Changes to Section 3 (Second and Third Paragraphs)
2. 对第3节(第二和第三段)的修改

This change clarifies the placement of RSASSA-PSS-params in the signature, signatureAlgorithm, and subjectPublicKeyInfo fields for certification authority (CA) and end-entity (EE) certificates. It also clarifies the placement of RSASSA-PSS-params in the signatureAlgorithm field in certificate revocation lists (CRLs).

此更改澄清了RSASSA PSS参数在证书颁发机构(CA)和最终实体(EE)证书的签名、签名算法和subjectPublicKeyInfo字段中的位置。它还澄清了RSASSA PSS参数在证书吊销列表(CRL)的signatureAlgorithm字段中的位置。

Old:

旧的:

CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD require the presence of parameters in the publicKeyAlgorithms field if the cA boolean flag is set in the basic constraints certificate extension. CAs MAY require that the parameters be present in the publicKeyAlgorithms field for end-entity certificates.

如果在基本约束证书扩展中设置了cA布尔标志,则颁发id为RSASSA PSS算法标识符的证书的cA应要求publicKeyAlgorithms字段中存在参数。CAs可能要求终端实体证书的publicKeyAlgorithms字段中存在参数。

CAs that use the RSASSA-PSS algorithm for signing certificates SHOULD include RSASSA-PSS-params in the subjectPublicKeyInfo algorithm parameters in their own certificates. CAs that use the RSASSA-PSS algorithm for signing certificates or CRLs MUST include RSASSA-PSS-params in the signatureAlgorithm parameters in the TBSCertificate or TBSCertList structures.

使用RSASSA-PSS算法对证书进行签名的CA应在其自己的证书中的subjectPublicKeyInfo算法参数中包含RSASSA PSS参数。使用RSASSA-PSS算法对证书或CRL进行签名的CA必须在TBSCertificate或TBSCertList结构的signatureAlgorithm参数中包含RSASSA PSS参数。

New:

新的:

When the id-RSASSA-PSS object identifier appears in the TBSCertificate or TBSCertList signature algorithm field, then the RSASSA-PSS-params structure MUST be included in the TBSCertificate or TBSCertList signature parameters field.

当id RSASSA PSS对象标识符出现在TBSCertificate或TBSCertList签名算法字段中时,则必须在TBSCertificate或TBSCertList签名参数字段中包含RSASSA PSS参数结构。

When the id-RSASSA-PSS object identifier appears in the TBSCertificate subjectPublicKeyInfo algorithm field of CA certificates, then the parameters field SHOULD include the RSASSA-PSS-params structure. When the id-RSASSA-PSS object identifier appears in the TBSCertificate subjectPublicKeyInfo algorithm field of EE certificates, then the parameters field MAY include the RSASSA-PSS-params structure.

当id RSASSA PSS对象标识符出现在CA证书的TBSCertificate subjectPublicKeyInfo算法字段中时,参数字段应包括RSASSA PSS params结构。当id RSASSA PSS对象标识符出现在EE证书的TBSCertificate subjectPublicKeyInfo算法字段中时,参数字段可能包括RSASSA PSS params结构。

All certificates and CRLs signed by a CA that supports the id-RSASSA-PSS algorithm MUST include the RSASSA-PSS-params in the signatureAlgorithm parameters in Certificate and CertList structures, respectively.

由支持id RSASSA PSS算法的CA签名的所有证书和CRL必须分别在证书和证书列表结构的signatureAlgorithm参数中包含RSASSA PSS参数。

3. Changes to Section 4 (Second Paragraph)
3. 对第4节(第二段)的修改

This change prohibits the inclusion of RSAES-OAEP-params in the subjectPublicKeyInfo field. This was done because a) it does not affect interoperability and b) it aligns with PKIX practice to not include limitations on how the public key can be used in subjectPublicKeyInfo. A poll of implementers was taken and there were no objections to this change as it did not affect current implementations.

此更改禁止在subjectPublicKeyInfo字段中包含RSAES OAEP参数。这样做是因为a)它不影响互操作性,b)它符合PKIX实践,不包括对如何在subjectPublicKeyInfo中使用公钥的限制。对实施者进行了民意调查,没有人反对这一更改,因为它不会影响当前的实施。

Old:

旧的:

CAs that issue certificates with the id-RSAES-OAEP algorithm identifier SHOULD require the presence of parameters in the publicKeyAlgorithms field for all certificates. Entities that use a certificate with a publicKeyAlgorithm value of id-RSA-OAEP where the parameters are absent SHOULD use the default set of parameters for RSAES-OAEP-params. Entities that use a certificate with a publicKeyAlgorithm value of rsaEncryption SHOULD use the default set of parameters for RSAES-OAEP-params.

颁发id为RSAES OAEP算法标识符的证书的CA应要求在publicKeyAlgorithms字段中为所有证书提供参数。在缺少参数的情况下,使用公钥算法值id为RSA OAEP的证书的实体应使用RSAES OAEP参数的默认参数集。使用publicKeyAlgorithm值为RSAEP Encryption的证书的实体应使用RSAES OAEP参数的默认参数集。

New:

新的:

CAs that issue certificates with the id-RSAES-OAEP algorithm identifier MUST NOT include parameters in the subjectPublicKeyInfo algorithm field.

颁发id为RSAES OAEP算法标识符的证书的CA不得在subjectPublicKeyInfo算法字段中包含参数。

4. Changes to Section 4.1 (First Paragraph)
4. 第4.1节(第一段)的变更

This change prohibits the inclusion of parameters in the subjectPublicKeyInfo field. This was done because a) it does not affect interoperability and b) it aligns with PKIX practice to not include limitations on how the public key can be used in subjectPublicKeyInfo. A poll of implementers was taken and there were no objections to this change as it did not affect current implementations.

此更改禁止在subjectPublicKeyInfo字段中包含参数。这样做是因为a)它不影响互操作性,b)它符合PKIX实践,不包括对如何在subjectPublicKeyInfo中使用公钥的限制。对实施者进行了民意调查,没有人反对这一更改,因为它不会影响当前的实施。

Old:

旧的:

When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters MUST employ the RSAES-OAEP-params syntax. The parameters may be either absent or present when used as subject public key information.

在算法标识符中使用id RSAES OAEP时,参数必须采用RSAES OAEP参数语法。当用作主体公钥信息时,参数可能不存在或存在。

The parameters MUST be present when used in the algorithm identifier associated with an encrypted value.

在与加密值关联的算法标识符中使用时,参数必须存在。

New:

新的:

When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters MUST employ the RSAES-OAEP-params syntax. The parameters MUST be absent when used in the subjectPublicKeyInfo field. The parameters MUST be present when used in the algorithm identifier associated with an encrypted value.

在算法标识符中使用id RSAES OAEP时,参数必须采用RSAES OAEP参数语法。在subjectPublicKeyInfo字段中使用时,必须缺少参数。在与加密值关联的算法标识符中使用时,参数必须存在。

5. Security Considerations
5. 安全考虑

The security considerations from [RFC4055] apply.

[RFC4055]中的安全注意事项适用。

If the RSAES-OAEP-params are negotiated, then the negotiation mechanism needs to provide integrity for these parameters. For example, an S/MIME Agent can advertise their capabilities in the SMIMECapabilities attribute, which is either a signed attribute [RFC5751] or a certificate extension [RFC4262].

如果协商RSAES OAEP参数,则协商机制需要为这些参数提供完整性。例如,S/MIME代理可以在SMIMECapabilities属性中公布其功能,该属性是签名属性[RFC5751]或证书扩展[RFC4262]。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

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

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

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

[RFC4055]Schaad,J.,Kaliski,B.,和R.Housley,“Internet X.509公钥基础设施证书和证书撤销列表(CRL)配置文件中使用的RSA加密的其他算法和标识符”,RFC 4055,2005年6月。

6.2. Informative References
6.2. 资料性引用

[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, December 2005.

[RFC4262]Santesson,S.,“用于安全/多用途Internet邮件扩展(S/MIME)功能的X.509证书扩展”,RFC 42622005年12月。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

[RFC5751]Ramsdell,B.和S.Turner,“安全/多用途Internet邮件扩展(S/MIME)版本3.2消息规范”,RFC 57512010年1月。

Authors' Addresses

作者地址

Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA

Sean Turner IECA,Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室,邮编22031

   EMail: turners@ieca.com
        
   EMail: turners@ieca.com
        

Kelvin Yiu Microsoft One Microsoft Way Redmond, WA 98052-6399 USA

开尔文姚微软一路微软雷德蒙德,华盛顿州98052-6399美国

   EMail: kelviny@microsoft.com
        
   EMail: kelviny@microsoft.com
        

Daniel R. L. Brown Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1 CANADA

Daniel R.L.Brown Certicom Corp 5520探索者大道#400号,位于加拿大密西西比州的L4W 5L1

   EMail: dbrown@certicom.com
        
   EMail: dbrown@certicom.com
        

Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA

Russ Housley Vigil Security,LLC 918 Spring Knoll Drive Herndon,弗吉尼亚州,邮编20170

   EMail: housley@vigilsec.com
        
   EMail: housley@vigilsec.com
        

Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899 USA

美国马里兰州盖瑟斯堡426室820号NIST大楼Tim Polk 20899

   EMail: wpolk@nist.gov
        
   EMail: wpolk@nist.gov