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
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.それは、RSA暗号化スキームを使用するための規則を更新 - 最適な非対称暗号パディング（RSAES-OAEP）キートランスポートアルゴリズムをインターネットX.509公開鍵基盤（PKI）に。具体的には、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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
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.
インターネットX.509公開鍵基盤（PKI）に最適な非対称暗号化パディング（RSAES-OAEP）キートランスポートアルゴリズム - RFC 4055は、RSA暗号化スキームを使用するための規則を指定します。これは、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）のデザインチームは、鍵導出関数（KDFs）は、証明書内に拘束されるべきでないことをお勧めします。むしろ、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.
で唯一の2つの段落[RFC4055] X.509証明書におけるRSAES-OAEPパラメータについて説明します。第4の第2段落とセクション4.1の最初の段落を。この文書では、これらの二つの段落を更新します。セクション4は、[RFC4055]のセクション4.1の第二段落を更新しながら、第3節では、[RFC4055]のセクション4番目の段落を更新します。 「旧：」テキストを交換する前置すると、「新：」置換テキストを前置します。
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.
この文書はまた、SubjectPublicKeyInfoでアルゴリズムフィールドのパラメータフィールドへの参照を持つ第3節でpublicKeyAlgorithmsフィールドへの不正な参照を置き換えます。セクション3はまた、明確にするために第二および第三段落をrewords。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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).
この変更は、認証局（CA）およびエンドエンティティ（EE）証明書の署名、のsignatureAlgorithm、およびSubjectPublicKeyInfoでフィールドにRSASSA-PSS-のparamsの配置を明確にしています。また、証明書失効リスト内のsignatureAlgorithmフィールド（CRL）の中RSASSA-PSS-のparamsの配置を明確にしています。
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アルゴリズム識別子と、その証明書を発行CAS publicKeyAlgorithmsフィールド内のパラメータの存在を必要とすべきです。 CAは、パラメータがエンドエンティティ証明書の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-のparamsを含むべきです。署名証明書やCRLをRSASSA-PSSアルゴリズムを使用するCAはたtbsCertificateまたはたtbsCertList構造中のsignatureAlgorithmパラメータのRSASSA-PSS-のparamsを含まなければなりません。
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署名アルゴリズムフィールドに表示されたら、次にRSASSA-PSS-paramsは構造たtbsCertificateあるいはたtbsCertListシグニチャパラメータフィールドに含まれなければなりません。
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は、それぞれ、証明書とCERTLIST構造中のsignatureAlgorithmパラメタにRSASSA-PSS-のparamsを含まなければなりません。
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-のparamsを含めることを禁止しています。 A）それは相互運用性には影響しないと、b）それは公開鍵がSubjectPublicKeyInfoでどのように使用できるかの制限が含まれていないためにPKIXの練習に整列するので、これが行われました。実装者の投票を採取し、それが現在の実装に影響を与えなかったとして異議はこの変更にありませんでした。
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.
その問題CAS ID-RSAES-OAEPアルゴリズム識別子を持つ証明書はすべての証明書のためのpublicKeyAlgorithmsフィールドにパラメータの存在を必要とすべきです。パラメータが存在しないID-RSA-OAEPのpublicKeyAlgorithm値と証明書を使用するエンティティはRSAES-OAEP-paramsはのためのパラメータのデフォルトセットを使用すべきです。 rsaEncryptionのpublicKeyAlgorithm値で証明書を使用するエンティティはRSAES-OAEP-のparamsのパラメータのデフォルトセットを使用すべきです。
New:
新着：
CAs that issue certificates with the id-RSAES-OAEP algorithm identifier MUST NOT include parameters in the subjectPublicKeyInfo algorithm field.
ID-RSAES-OAEPアルゴリズム識別子とその証明書を発行CAS SubjectPublicKeyInfoでアルゴリズムフィールドにパラメータを含めることはできません。
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）それは公開鍵がSubjectPublicKeyInfoでどのように使用できるかの制限が含まれていないためにPKIXの練習に整列するので、これが行われました。実装者の投票を採取し、それが現在の実装に影響を与えなかったとして異議はこの変更にありませんでした。
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をのAlgorithmIdentifierで使用する場合、パラメータは、RSAES-OAEP-paramsは構文を使用しなければなりません。サブジェクト公開鍵情報として使用される場合のパラメータが存在しないか、存在のいずれであってもよいです。
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をのAlgorithmIdentifierで使用する場合、パラメータは、RSAES-OAEP-paramsは構文を使用しなければなりません。 SubjectPublicKeyInfoでフィールドで使用される場合、パラメータが存在してはなりません。暗号化された値に関連付けられたアルゴリズム識別子で使用する場合のパラメータが存在しなければなりません。
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 - paramsを交渉している場合には、交渉のメカニズムは、これらのパラメータの整合性を提供する必要があります。例えば、S / MIMEエージェントはSMIMEケーパビリティにおけるそれらの機能はいずれかの署名された属性[RFC5751]または証明書拡張[RFC4262]である、属性を広告することができます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールで使用するRSA暗号のための追加のアルゴリズムと識別子"、RFC 4055 、2005年6月。
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, December 2005.
[RFC4262] Santesson、S.、RFC 4262、2005年12月 "/セキュア多目的インターネットメール拡張（S / MIME）機能のためのX.509証明書拡張"。
[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.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
ショーン・ターナーIECA株式会社3057ナトリーストリート、スイート106バージニア州フェアファクス22031 USA
EMail: turners@ieca.com
メールアドレス：turners@ieca.com
Kelvin Yiu Microsoft One Microsoft Way Redmond, WA 98052-6399 USA
ケルビン耀輝マイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052-6399 USA
EMail: kelviny@microsoft.com
メールアドレス：kelviny@microsoft.com
Daniel R. L. Brown Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1 CANADA
L4W 5L1 CANADA ONダニエル・R. L.ブラウンのCerticom社5520エクスプローラドライブ＃400ミシソーガ、
EMail: dbrown@certicom.com
メールアドレス：dbrown@certicom.com
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラスHousleyビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899 USA
ティムポークNISTビル820、ルーム426ゲーサーズバーグ、MD 20899 USA
EMail: wpolk@nist.gov
メールアドレス：wpolk@nist.gov