RFC 5756 - Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5756
タイトル : RFC 5756 - RSAES-OAEPおよびRSASSA-PSSアルゴリズムパラメーターの更新
翻訳編集 : 自動生成

[要約] RFC 5756は、RSAES-OAEPとRSASSA-PSSアルゴリズムのパラメータに関する更新を提供しています。このRFCの目的は、これらのアルゴリズムのセキュリティと互換性を向上させることです。

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を更新します。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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5756で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.

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 RSA暗号化スキーム - 最適な非対称暗号化パディング（RSAES -OAEP）のキートランスポートアルゴリズムをインターネットX.509公開インフラストラクチャ（PKI）を使用するための規則を指定します。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証明書の件名PublicKeyInfoフィールドのRSAES-OAEPパラメーターの規則を更新します。PKIX WG Elliptic Curve Cryptography（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]の2つの段落のみがX.509証明書のRSAES-OAEPパラメーターについて説明します。セクション4の2番目の段落とセクション4.1の最初の段落。このドキュメントは、これら2つの段落のみを更新します。セクション3では、[RFC4055]のセクション4の2番目の段落を更新し、セクション4で[RFC4055]のセクション4.1の2番目の段落を更新します。「古い：」交換するテキストのプレフィェスと「新品：」は、交換テキストをプレハーフします。

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のpublicKeyalgorithmsフィールドへの誤った参照を、subjectpublickeyinfoアルゴリズムフィールドのパラメーターフィールドへの参照に置き換えます。セクション3は、明確にするために2番目と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].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

2. Changes to Section 3 (Second and Third Paragraphs)

2. セクション3の変更（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).

この変更により、署名、SignatureAlgorithm、およびSubjectPublicKeyInfoフィールドのRSASSA-PSS-PARAMSが認証局（CA）およびエンドエンティティ（EE）証明書に配置されます。また、証明書取消リスト（CRL）のSignatureAlgorithmフィールドに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.

ID-RSASSA-PSSアルゴリズム識別子で証明書を発行するCAS CAS BOOLEANフラグが基本制約証明書拡張に設定されている場合、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アルゴリズムを使用して証明書に署名するCASには、subjectpublickeyinfoアルゴリズムパラメーターにRSassa-pss-paramsを独自の証明書に含める必要があります。RSASSA-PSSアルゴリズムを使用して証明書またはCRLSに署名するCASは、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 Signature Parametersフィールドに含める必要があります。

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件名PublicKeyInfoアルゴリズムフィールドに表示されると、パラメーターフィールドには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-Paramsを含める必要があります。

3. Changes to Section 4 (Second Paragraph)

3. セクション4の変更（2番目の段落）

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.

この変更は、件名PublicKeyInfoフィールドにRSAES-OAEP-PARAMSを含めることを禁止しています。これは、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アルゴリズム識別子で証明書を発行するCASは、すべての証明書の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 CASは、件名PublicKeyInfoアルゴリズムフィールドにパラメーターを含めてはなりません。

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.

この変更は、件名PublicKeyInfoフィールドにパラメーターを含めることを禁止しています。これは、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がアルゴリズムIdentifierで使用される場合、パラメーターは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がアルゴリズムIdentifierで使用される場合、パラメーターはRSAES-OAEP-PARAMS構文を使用する必要があります。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-PARAMSがネゴシエートされている場合、交渉メカニズムはこれらのパラメーターに完全性を提供する必要があります。たとえば、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、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、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。、 "Secure/Multipurpose Internet Mail Extensions（S/MIME）機能のX.509証明書拡張機能"、RFC 4262、2005年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、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。

Authors' Addresses

著者のアドレス

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

Sean Turner IECA、Inc。3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA

   EMail: turners@ieca.com

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

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

   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 Explorer Drive＃400 Mississauga、L4W 5L1 Canada

   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、VA 20170 USA

   EMail: housley@vigilsec.com

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

Tim Polk Nist Building 820、Room 426 Gaithersburg、MD 20899 USA

   EMail: wpolk@nist.gov