[要約] RFC 4055は、インターネットX.509公開鍵基盤証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号に関する追加のアルゴリズムと識別子についての要約です。このRFCの目的は、RSA暗号に関連する新しいアルゴリズムと識別子を定義し、インターネット上でのセキュリティを向上させることです。
Network Working Group J. Schaad
Request for Comments: 4055 Soaring Hawk Consulting
Updates: 3279 B. Kaliski
Category: Standards Track RSA Laboratories
R. Housley
Vigil Security
June 2005
Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル
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).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified.
この文書はRFC3279に補足されています。RSA確率的署名スキーム（RSASSA-PSS）署名アルゴリズム、RSA暗号化スキーム - 最適な非対称暗号化パディング（RSAES-OAEP）キートランスポートアルゴリズム、および追加の1つのハス機能を備えた追加のハス機能を伴う追加パブリックキー暗号化標準（PKCS）＃1バージョン1.5インターネットX.509公開キーインフラストラクチャ（PKI）の署名アルゴリズム。エンコード形式、アルゴリズム識別子、およびパラメーター形式が指定されています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. RSA Public Keys ............................................3
2. Common Functions ................................................5
2.1. One-way Hash Functions .....................................5
2.2. Mask Generation Functions ..................................6
3. RSASSA-PSS Signature Algorithm ..................................7
3.1. RSASSA-PSS Public Keys .....................................8
3.2. RSASSA-PSS Signature Values ...............................10
3.3. RSASSA-PSS Signature Parameter Validation .................10
4. RSAES-OAEP Key Transport Algorithm .............................10
4.1. RSAES-OAEP Public Keys ....................................11
5. PKCS #1 Version 1.5 Signature Algorithm ........................13
6. ASN.1 Module ...................................................14
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
8. Security Considerations ........................................21
9. IANA Considerations ............................................24
This document supplements RFC 3279 [PKALGS]. This document describes the conventions for using the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI) [PROFILE]. Both of these RSA-based algorithms are specified in [P1v2.1]. The algorithm identifiers and associated parameters for subject public keys that employ either of these algorithms, and the encoding format for RSASSA-PSS signatures are specified. Also, the algorithm identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions with the PKCS #1 version 1.5 signature algorithm [P1v1.5] are specified.
この文書は、RFC 3279 [PKALGS]を補完します。このドキュメントでは、RSASSA-PSS署名アルゴリズムとインターネットX.509公開キーインフラストラクチャ（PKI）[プロファイル]におけるRSAES-OAEPキートランスポートアルゴリズムを使用するための規則について説明します。これらのRSAベースのアルゴリズムは両方とも[P1v2.1]で指定されています。これらのアルゴリズムのいずれかを採用しているサブジェクトパブリックキーのアルゴリズム識別子と関連するパラメーター、およびRSASSA-PSS署名のエンコード形式が指定されています。また、PKCS＃1バージョン1.5署名アルゴリズム[P1v1.5]を使用して、SHA-224、SHA-256、SHA-384、およびSHA-512の一方向ハッシュ関数を使用するためのアルゴリズム識別子が指定されています。
This specification supplements RFC 3280 [PROFILE] which profiles the X.509 Certificates and Certificate Revocation Lists (CRLs) for use in the Internet. This specification extends the list of algorithms discussed in RFC 3279 [PKALGS]. The X.509 Certificate and CRL definitions use ASN.1 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88].
この仕様は、インターネットで使用するためのX.509証明書と証明書の取り消しリスト（CRL）をプロファイルするRFC 3280 [プロファイル]をサプリメントします。この仕様は、RFC 3279 [PKALGS]で説明されているアルゴリズムのリストを拡張します。X.509証明書とCRL定義は、ASN.1 [X.208-88]、基本エンコードルール（BER）[X.209-88]、および著名なエンコードルール（DER）[X.509-88]を使用しています。。
This specification defines the contents of the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 Certificates and CRLs. For each algorithm, the appropriate alternatives for the keyUsage certificate extension are provided.
この仕様は、インターネットX.509証明書およびCRL内のSignatureAlgorithm、SignatureValue、Signature、およびSubjectPublicKeyInfoフィールドの内容を定義します。各アルゴリズムについて、KeyUSAGE証明書拡張の適切な代替案が提供されます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [stdwords]に記載されているとおりに解釈されます。
RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates in Internet applications. When an RSA public key is used for RSASSA-PSS digital signatures or RSAES-OAEP key transport, the conventions specified in this section augment RFC 3280.
RFC 3280 [プロファイル]インターネットアプリケーションでX.509証明書を使用するためのプロファイルを指定します。RSAの公開キーがRSASSA-PSSデジタル署名またはRSAES-OAEPキートランスポートに使用されている場合、このセクションで指定された規則はRFC 3280を強化します。
Traditionally, the rsaEncryption object identifier is used to identify RSA public keys. However, to implement all of the recommendations described in Security Considerations (Section 8), the certificate user needs to be able to determine the form of digital signature or key transport that the RSA private key owner associates with the public key.
伝統的に、RSAECHRYPTIONオブジェクト識別子は、RSAパブリックキーを識別するために使用されていました。ただし、セキュリティに関する考慮事項（セクション8）で説明されているすべての推奨事項を実装するには、証明書ユーザーは、RSA秘密キーの所有者が公開キーに関連付けるデジタル署名またはキートランスポートの形式を決定できる必要があります。
The rsaEncryption object identifier continues to identify the subject public key when the RSA private key owner does not wish to limit the use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. In this case, the rsaEncryption object identifier MUST be used in the algorithm field within the subject public key information, and the parameters field MUST contain NULL.
RSAの秘密鍵の所有者が、RSassa-PSSまたはRSAES-OAEPのいずれかにのみ公開キーの使用を制限したくない場合、RSAECNICNIPTIONオブジェクト識別子は、主題の公開キーを識別し続けます。この場合、rsaEcryptionオブジェクト識別子は、サブジェクト公開情報内のアルゴリズムフィールドで使用する必要があり、パラメーターフィールドにはnullを含める必要があります。
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
Further discussion of the conventions associated with use of the rsaEncryption object identifier can be found in RFC 3279 (see [PKALGS], Section 2.3.1).
RSAENCryptionオブジェクト識別子の使用に関連する規則のさらなる議論は、RFC 3279（[PKALGS]、セクション2.3.1を参照）に記載されています。
When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object identifier MUST be used in the algorithm field within the subject public key information, and, if present, the parameters field MUST contain RSASSA-PSS-params. The id-RSASSA-PSS object identifier value and the RSASSA-PSS-params syntax are fully described in Section 3.
RSAの秘密鍵の所有者が公開キーの使用をRSASSA-PSSのみに制限したい場合、ID-RSassa-PSSオブジェクト識別子は、サブジェクト公開情報内のアルゴリズムフィールドで使用する必要があります。パラメーターフィールドには、rsassa-pss-paramsを含める必要があります。ID-RSASSA-PSSオブジェクト識別子値とRSASSA-PSS-PARAMS構文は、セクション3で完全に説明されています。
When the RSA private key owner wishes to limit the use of the public key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object identifier MUST be used in the algorithm field within the subject public key information, and, if present, the parameters field MUST contain RSAES-OAEP-params. The id-RSAES-OAEP object identifier value and the RSAES-OAEP-params syntax are fully described in Section 4.
RSAの秘密鍵所有者がRSAES-OAEPにのみ公開キーの使用を制限したい場合、ID-RSAES-OAEPオブジェクト識別子は、主題の公開情報内のアルゴリズムフィールドで使用する必要があります。パラメーターフィールドには、RSAES-OAEP-PARAMSを含める必要があります。ID-RSAES-OAEPオブジェクト識別子値とRSAES-OAEP-PARAMS構文は、セクション4で完全に説明されています。
Note: It is not possible to restrict the use of a key to a set of algorithms (i.e., RSASSA-PSS and RSAES-OAEP).
注：キーの使用を一連のアルゴリズム（つまり、RSASSA-PSSおよびRSAES-OAEP）に制限することはできません。
Regardless of the object identifier used, the RSA public key is encoded in the same manner in the subject public key information. The RSA public key MUST be encoded using the type RSAPublicKey type:
使用されるオブジェクト識別子に関係なく、RSAの公開キーは、サブジェクトの公開キー情報で同じ方法でエンコードされます。RSAの公開キーは、型rsapublickeyタイプを使用してエンコードする必要があります。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
Here, the modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is carried in the subjectPublicKey BIT STRING within the subject public key information.
ここで、モジュラスは弾性率nであり、publicexponentは公開指数eです。derエンコードされたrsapublickeyは、件名の公開鍵情報内のsubjectpublickeyビット文字列に掲載されています。
The intended application for the key MAY be indicated in the keyUsage certificate extension (see [PROFILE], Section 4.2.1.3).
キーの意図されたアプリケーションは、キーユーザー証明書延長に示される場合があります（[プロファイル]、セクション4.2.1.3を参照）。
If the keyUsage extension is present in an end-entity certificate that conveys an RSA public key with the id-RSASSA-PSS object identifier, then the keyUsage extension MUST contain one or both of the following values:
KeyUSAGE拡張機能が、ID-RSassa-PSSオブジェクト識別子を使用してRSAの公開キーを伝えるエンドエンティティ証明書に存在する場合、KeyUSAGE拡張には次の値の1つまたは両方を含める必要があります。
nonRepudiation; and digitalSignature.
非控除;およびdigitalSignature。
If the keyUsage extension is present in a certification authority certificate that conveys an RSA public key with the id-RSASSA-PSS object identifier, then the keyUsage extension MUST contain one or more of the following values:
KeyUSAGE拡張機能が、ID-RSassa-PSSオブジェクト識別子を使用してRSAの公開キーを伝える認定機関証明書に存在する場合、KeyUSAGE拡張には次の値の1つ以上を含める必要があります。
nonRepudiation; digitalSignature; keyCertSign; and cRLSign.
非控除;デジタル署名;keycertsign;とcrlsign。
When a certificate conveys an RSA public key with the id-RSASSA-PSS object identifier, the certificate user MUST only use the certified RSA public key for RSASSA-PSS operations, and, if RSASSA-PSS-params is present, the certificate user MUST perform those operations using the one-way hash function, mask generation function, and trailer field identified in the subject public key algorithm identifier parameters within the certificate.
証明書がID-RSASSA-PSSオブジェクト識別子を使用してRSAの公開キーを伝える場合、証明書ユーザーはRSASSA-PSS操作に認定RSA公開キーのみを使用する必要があります。証明書内の対象の公開キーアルゴリズム識別子パラメーターで識別された一方向ハッシュ関数、マスク生成関数、およびトレーラーフィールドを使用して、これらの操作を実行します。
If the keyUsage extension is present in a certificate conveys an RSA public key with the id-RSAES-OAEP object identifier, then the keyUsage extension MUST contain only the following values:
証明書にkeyUSAGE拡張機能が存在する場合、ID-RSAES-OAEPオブジェクト識別子を使用してRSAの公開キーを伝えている場合、KeyUSAGE拡張には次の値のみを含める必要があります。
keyEncipherment; and dataEncipherment.
KeyEncipherment;およびDataEncipherment。
However, both keyEncipherment and dataEncipherment SHOULD NOT be present.
ただし、KeyenciphermentとDataEnciphermentの両方が存在するべきではありません。
When a certificate that conveys an RSA public key with the id-RSAES-OAEP object identifier, the certificate user MUST only use the certified RSA public key for RSAES-OAEP operations, and, if RSAES-OAEP-params is present, the certificate user MUST perform those operations using the one-way hash function and mask generation function identified in the subject public key algorithm identifier parameters within the certificate.
ID-RSAES-OAEPオブジェクト識別子を使用してRSAの公開キーを伝える証明書がある場合、証明書ユーザーはRSAES-OAEP操作に認定RSA公開キーのみを使用する必要があります。証明書内の対象の公開キーアルゴリズム識別子パラメーターで識別された一方向ハッシュ関数とマスク生成関数を使用して、これらの操作を実行する必要があります。
The RSASSA-PSS signature and the RSAES-OAEP key transport algorithms make use of one-way hash functions and mask generation functions.
RSASSA-PSS署名とRSAES-OAEPキートランスポートアルゴリズムは、一方向ハッシュ関数とマスク生成関数を使用します。
PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions for use with the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 [SHA2]. This document adds support for SHA-224 [SHA-224] with both the RSASSA-PSS and the RSAES-OAEP algorithms. While support for additional one-way hash functions could be added in the future, no other one-way hash functions are supported by this specification.
PKCS＃1バージョン2.1 [P1V2.1]は、RSASSA-PSS署名アルゴリズムとRSAES-OAEPキートランスポートアルゴリズムで使用する4つの一方向ハッシュ関数をサポートしています：SHA-1、SHA-256、SHA-384、およびSHA-512 [SHA2]。このドキュメントは、RSASSA-PSSとRSAES-OAEPアルゴリズムの両方を使用して、SHA-224 [SHA-224]のサポートを追加します。追加の一方向ハッシュ関数のサポートは将来追加される可能性がありますが、この仕様によって他の一方向ハッシュ関数はサポートされていません。
These one-way hash functions are identified by the following object identifiers:
これらの一方向ハッシュ関数は、次のオブジェクト識別子によって識別されます。
id-sha1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26 }
id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
There are two possible encodings for the AlgorithmIdentifier parameters field associated with these object identifiers. The two alternatives arise from the loss of the OPTIONAL associated with the algorithm identifier parameters when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element while others omit them entirely. The correct encoding is to omit the parameters field; however, when RSASSA-PSS and RSAES-OAEP were defined, it was done using the NULL parameters rather than absent parameters.
これらのオブジェクト識別子に関連付けられているアルゴリズムIDIDIFIERパラメーターフィールドには、2つの可能なエンコーディングがあります。2つの代替案は、1988年のアルゴリズムIdentifierの構文が1997年の構文に変換されたときに、アルゴリズム識別子パラメーターに関連付けられたオプションの損失から生じます。その後、オプションは欠陥レポートを介して回復されましたが、それまでに多くの人々はアルゴリズムパラメーターが必須であると考えていました。この履歴により、一部の実装はパラメーターをヌル要素としてエンコードし、他のものは完全に省略します。正しいエンコーディングは、パラメーターフィールドを省略することです。ただし、RSassa-PSSとRSAES-OAEPが定義された場合、パラメーターがないのではなく、ヌルパラメーターを使用して行われました。
All implementations MUST accept both NULL and absent parameters as legal and equivalent encodings.
すべての実装は、法的および同等のエンコーディングとして、nullパラメーターと存在パラメーターの両方を受け入れる必要があります。
To be clear, the following algorithm identifiers are used when a NULL parameter MUST be present:
明確にするために、NULLパラメーターが存在する必要がある場合に、次のアルゴリズム識別子が使用されます。
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }
One mask generation function is used with the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1]. No other mask generation functions are supported by this specification.
1つのマスク生成関数は、RSASSA-PSS署名アルゴリズムとRSAES-OAEPキートランスポートアルゴリズムであるMGF1 [P1V2.1]で使用されます。この仕様では、他のマスク生成関数はサポートされていません。
MGF1 is identified by the following object identifier:
MGF1は、次のオブジェクト識別子によって識別されます。
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
The parameters field associated with id-mgf1 MUST have a hashAlgorithm value which identifies the hash function being used with MGF1. This value MUST be sha1Identifier, sha224Identifier, sha256Identifier, sha384Identifier, or sha512Identifier, as specified in Section 2.1. Implementations MUST support the default value, sha1Identifier, and MAY support the other four values.
ID-MGF1に関連付けられているパラメーターフィールドには、MGF1で使用されているハッシュ関数を識別するハスハルゴリズム値が必要です。この値は、セクション2.1で指定されているように、sha1identifier、sha224identifier、sha256identifier、sha384identifier、またはsha512identifierでなければなりません。実装は、デフォルト値、sha1identifierをサポートする必要があり、他の4つの値をサポートする必要があります。
The following algorithm identifiers have been assigned for each of these alternatives:
次のアルゴリズム識別子が、これらの代替品のそれぞれに割り当てられています。
mgf1SHA1Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha1Identifier }
mgf1SHA224Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha224Identifier }
mgf1SHA256Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha256Identifier }
mgf1SHA384Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha384Identifier }
mgf1SHA512Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha512Identifier }
This section describes the conventions for using the RSASSA-PSS signature algorithm with the Internet X.509 Certificate and CRL profile [PROFILE]. The RSASSA-PSS signature algorithm is specified in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions discussed in Section 2.1 and the one mask generation function discussed in Section 2.2 can be used with RSASSA-PSS.
このセクションでは、インターネットX.509証明書とCRLプロファイル[プロファイル]を使用してRSASSA-PSS署名アルゴリズムを使用するための規則について説明します。RSASSA-PSS署名アルゴリズムは、PKCS＃1バージョン2.1 [P1V2.1]で指定されています。セクション2.1で説明されている5つの一方向ハッシュ関数とセクション2.2で説明する1つのマスク生成関数は、RSASSA-PSSで使用できます。
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を含める必要があります。
Entities that validate RSASSA-PSS signatures MUST support SHA-1. They MAY also support any other one-way hash functions in Section 2.1.
RSASSA-PSS署名を検証するエンティティは、SHA-1をサポートする必要があります。また、セクション2.1の他の一方向ハッシュ関数をサポートする場合があります。
The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA decryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in the signatureValue field. Section 3.2 specifies the format of RSASSA-PSS signature values.
署名されるデータ（一方向ハッシュ関数出力値など）は、使用する署名アルゴリズムのフォーマットされています。次に、署名値を生成するために、秘密キー操作（RSA復号化など）が実行されます。この署名値は、asn.1がビット文字列としてエンコードされ、署名バリューフィールドの証明書または証明書に含まれています。セクション3.2は、RSASSA-PSS署名値の形式を指定します。
When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters MUST employ the RSASSA-PSS-params syntax. The parameters may be either absent or present when used as subject public key information. The parameters MUST be present when used in the algorithm identifier associated with a signature value.
rsassa-PSSがアルゴリズムIdentifierで使用される場合、パラメーターはrsassa-pss-params構文を使用する必要があります。パラメーターは、対象の公開情報として使用される場合、存在しないか、存在する場合があります。署名値に関連付けられたアルゴリズム識別子で使用する場合、パラメーターを存在する必要があります。
When signing, it is RECOMMENDED that the parameters, except for possibly saltLength, remain fixed for all usages of a given RSA key pair.
署名する場合、特定のRSAキーペアのすべての使用に対して、おそらくSaltLengthを除くパラメーターが固定されたままであることが推奨されます。
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 }
The fields of type RSASSA-PSS-params have the following meanings:
タイプのrsassa-pss-paramsのフィールドには、次の意味があります。
hashAlgorithm
ハスハルゴリズム
The hashAlgorithm field identifies the hash function. It MUST be one of the algorithm identifiers listed in Section 2.1, and the default hash function is SHA-1. Implementations MUST support SHA-1 and MAY support any of the other one-way hash functions listed in Section 2.1. Implementations that perform signature generation MUST omit the hashAlgorithm field when SHA-1 is used, indicating that the default algorithm was used. Implementations that perform signature validation MUST recognize both the sha1Identifier algorithm identifier and an absent hashAlgorithm field as an indication that SHA-1 was used.
ハスハルゴリズムフィールドは、ハッシュ関数を識別します。セクション2.1にリストされているアルゴリズム識別子の1つでなければならず、デフォルトのハッシュ関数はSHA-1です。実装はSHA-1をサポートする必要があり、セクション2.1にリストされている他の一方向ハッシュ関数のいずれかをサポートする場合があります。署名生成を実行する実装は、SHA-1を使用したときにハサルゴリズムフィールドを省略する必要があり、デフォルトのアルゴリズムが使用されたことを示しています。署名検証を実行する実装は、SHA-1が使用されたことを示すこととして、Sha1Identifierアルゴリズム識別子と存在しないハサルゴリズムフィールドの両方を認識する必要があります。
maskGenAlgorithm
Maskgenalgorithm
The maskGenAlgorithm field identifies the mask generation function. The default mask generation function is MGF1 with SHA-1. For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashAlgorithm. Implementations MUST support MGF1. MGF1 requires a one-way hash function that is identified in the parameters field of the MGF1 algorithm identifier. Implementations MUST support SHA-1 and MAY support any of the other one-way hash functions listed in section Section 2.1. The MGF1 algorithm identifier is comprised of the id-mgf1 object identifier and a parameter that contains the algorithm identifier of the one-way hash function employed with MGF1. The SHA-1 algorithm identifier is comprised of the id-sha1 object identifier and an (optional) parameter of NULL. Implementations that perform signature generation MUST omit the maskGenAlgorithm field when MGF1 with SHA-1 is used, indicating that the default algorithm was used.
MaskGenalgorithmフィールドは、マスク生成関数を識別します。デフォルトのマスク生成関数は、SHA-1のMGF1です。MGF1の場合、基礎となるハッシュ関数は、ハスハルゴリズムによって識別されたものと同じであることを強くお勧めします。実装はMGF1をサポートする必要があります。MGF1には、MGF1アルゴリズム識別子のパラメーターフィールドで識別される一方向ハッシュ関数が必要です。実装はSHA-1をサポートする必要があり、セクション2.1にリストされている他の一方向ハッシュ関数のいずれかをサポートする場合があります。MGF1アルゴリズム識別子は、ID-MGF1オブジェクト識別子と、MGF1で使用される一方向ハッシュ関数のアルゴリズム識別子を含むパラメーターで構成されています。SHA-1アルゴリズム識別子は、ID-Sha1オブジェクト識別子とnullの（オプションの）パラメーターで構成されています。署名生成を実行する実装は、SHA-1を使用したMGF1が使用されている場合、マスクゲナルゴリズムフィールドを省略する必要があり、デフォルトのアルゴリズムが使用されたことを示しています。
Although mfg1SHA1Identifier is defined as the default value for this field, implementations MUST accept both the default value encoding (i.e., an absent field) and mfg1SHA1Identifier to be explicitly present in the encoding.
MFG1SHA1IDENTIFIERはこのフィールドのデフォルト値として定義されていますが、実装は、エンコードに明示的に存在するデフォルト値エンコード（つまり、存在しないフィールド）とMFG1SHA1IDENTIFIERの両方を受け入れる必要があります。
saltLength
saltlength
The saltLength field is the octet length of the salt. For a given hashAlgorithm, the recommended value of saltLength is the number of octets in the hash value. Unlike the other fields of type RSASSA-PSS-params, saltLength does not need to be fixed for a given RSA key pair; a different value could be used for each RSASSA-PSS signature generated.
Saltlengthフィールドは、塩のオクテットの長さです。特定のハスハルゴリズムの場合、saltlengthの推奨値は、ハッシュ値のオクテットの数です。型rsassa-pss-paramsの他のフィールドとは異なり、saltlengthを特定のRSAキーペアに対して修正する必要はありません。生成されたRSASSA-PSS署名ごとに異なる値を使用できます。
trailerField
トレーラーフィールド
The trailerField field is an integer. It provides compatibility with IEEE Std 1363a-2004 [P1363A]. The value MUST be 1, which represents the trailer field with hexadecimal value 0xBC. Other trailer fields, including the trailer field composed of HashID concatenated with 0xCC that is specified in IEEE Std 1363a, are not supported. Implementations that perform signature generation MUST omit the trailerField field, indicating that the default trailer field value was used. Implementations that perform signature validation MUST recognize both a present trailerField field with value 1 and an absent trailerField field.
トレーラーフィールドフィールドは整数です。IEEE STD 1363A-2004 [P1363A]との互換性を提供します。値は1でなければなりません。これは、16進価値0xBCのトレーラーフィールドを表します。IEEE STD 1363aで指定されている0xccで連結されたハシドで構成されるトレーラーフィールドを含む他のトレーラーフィールドはサポートされていません。署名生成を実行する実装は、デフォルトのトレーラーフィールド値が使用されたことを示すトレーラーフィールドフィールドを省略する必要があります。署名検証を実行する実装は、値1の現在のトレーラーフィールドフィールドと不在のトレーラーフィールドフィールドの両方を認識する必要があります。
If the default values of the hashAlgorithm, maskGenAlgorithm, and trailerField fields of RSASSA-PSS-params are used, then the algorithm identifier will have the following value:
rsassa-PSS-Paramsのハサルゴリズム、Maskgenalgorithm、およびTrailerfieldフィールドのデフォルト値が使用される場合、アルゴリズム識別子には次の値があります。
rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= {
id-RSASSA-PSS, rSASSA-PSS-Default-Params }
rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {
sha1Identifier, mgf1SHA1Identifier, 20, 1}
The output of the RSASSA-PSS signature algorithm is an octet string, which has the same length in octets as the RSA modulus n.
RSASSA-PSS署名アルゴリズムの出力は、RSAモジュラスnと同じ長さを持つオクテット文字列です。
Signature values in CMS [CMS] are represented as octet strings, and the output is used directly. However, signature values in certificates and CRLs [PROFILE] are represented as bit strings, and conversion is needed.
CMS [CMS]の署名値はオクテット文字列として表され、出力は直接使用されます。ただし、証明書とCRL [プロファイル]の署名値はビット文字列として表され、変換が必要です。
To convert a signature value to a bit string, the most significant bit of the first octet of the signature value SHALL become the first bit of the bit string, and so on through the least significant bit of the last octet of the signature value, which SHALL become the last bit of the bit string.
署名値をビット文字列に変換するには、署名値の最初のオクテットの最も重要なビットは、ビット文字列の最初のビットになります。ビット文字列の最後のビットになります。
Three possible parameter validation scenarios exist for RSASSA-PSS signature values.
RSASSA-PSS署名値には、3つの可能なパラメーター検証シナリオが存在します。
1. The key is identified by the rsaEncryption algorithm identifier. In this case no parameter validation is needed.
1. キーは、rsaencryptionアルゴリズム識別子によって識別されます。この場合、パラメーター検証は必要ありません。
2. The key is identified by the id-RSASSA-PSS signature algorithm identifier, but the parameters field is absent. In this case no parameter validation is needed.
2. キーは、ID-RSassa-PSS署名アルゴリズム識別子によって識別されますが、パラメーターフィールドはありません。この場合、パラメーター検証は必要ありません。
3. The key is identified by the id-RSASSA-PSS signature algorithm identifier and the parameters are present. In this case all parameters in the signature structure algorithm identifier MUST match the parameters in the key structure algorithm identifier except the saltLength field. The saltLength field in the signature parameters MUST be greater or equal to that in the key parameters field.
3. キーは、ID-RSASSA-PSS署名アルゴリズム識別子によって識別され、パラメーターが存在します。この場合、署名構造アルゴリズム識別子のすべてのパラメーターは、saltlengthフィールドを除くキー構造アルゴリズム識別子のパラメーターと一致する必要があります。署名パラメーターのsaltlengthフィールドは、キーパラメーターフィールドのshirg式パラメーターと等しくなければなりません。
This section describes the conventions for using the RSAES-OAEP key transport algorithm with the Internet X.509 Certificate and CRL profile [PROFILE]. RSAES-OAEP is specified in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions discussed in Section 2.1 and the one mask generation function discussed in Section 2.2 can be used with RSAES-OAEP. Conforming CAs and applications MUST support RSAES-OAEP key transport algorithm using SHA-1. The other four one-way hash functions MAY also be supported.
このセクションでは、インターネットX.509証明書とCRLプロファイル[プロファイル]を使用して、RSAES-OAEPキートランスポートアルゴリズムを使用するための規則について説明します。RSAES-OAEPは、PKCS＃1バージョン2.1 [P1V2.1]で指定されています。セクション2.1で説明されている5つの一方向ハッシュ関数とセクション2.2で説明する1つのマスク生成関数は、RSAES-OAEPで使用できます。CASおよびアプリケーションの適合は、SHA-1を使用してRSAES-OAEPキートランスポートアルゴリズムをサポートする必要があります。他の4つの一方向ハッシュ関数もサポートされる場合があります。
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のパラメーターのデフォルトセットを使用する必要があります。
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. The parameters MUST be present when used in the algorithm identifier associated with an encrypted value.
ID-RSAES-OAEPがアルゴリズムIDIDIDIFIERで使用される場合、パラメーターはRSAES-OAEP-PARAMS構文を使用する必要があります。パラメーターは、対象の公開情報として使用される場合、存在しないか、存在する場合があります。暗号化された値に関連付けられたアルゴリズム識別子で使用する場合、パラメーターを存在する必要があります。
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT
sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT
mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=
{ id-pSpecified, nullOctetString }
nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
The fields of type RSAES-OAEP-params have the following meanings:
タイプRSAES-OAEP-PARAMSのフィールドには、次の意味があります。
hashFunc
Hashfunc
The hashFunc field identifies the one-way hash function. It MUST be one of the algorithm identifiers listed in Section 2.1, and the default hash function is SHA-1. Implementations MUST support SHA-1 and MAY support other one-way hash functions listed in Section 2.1. Implementations that perform encryption MUST omit the hashFunc field when SHA-1 is used, indicating that the default algorithm was used. Implementations that perform decryption MUST recognize both the sha1Identifier algorithm identifier and an absent hashFunc field as an indication that SHA-1 was used.
HashFuncフィールドは、一方向ハッシュ関数を識別します。セクション2.1にリストされているアルゴリズム識別子の1つでなければならず、デフォルトのハッシュ関数はSHA-1です。実装はSHA-1をサポートする必要があり、セクション2.1にリストされている他の一方向ハッシュ関数をサポートする場合があります。暗号化を実行する実装は、SHA-1を使用したときにハッシュファンクフィールドを省略する必要があり、デフォルトのアルゴリズムが使用されたことを示しています。復号化を実行する実装は、SHA-1が使用されたことを示すこととして、Sha1Identifierアルゴリズム識別子と存在しないハッシュファンクフィールドの両方を認識する必要があります。
maskGenFunc
maskgenfunc
The maskGenFunc field identifies the mask generation function. The default mask generation function is MGF1 with SHA-1. For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashFunc. Implementations MUST support MGF1. MGF1 requires a one-way hash function that is identified in the parameter field of the MGF1 algorithm identifier. Implementations MUST support SHA-1 and MAY support any of the other one-way hash functions listed in Section 2.1. The MGF1 algorithm identifier is comprised of the id-mgf1 object identifier and a parameter that contains the algorithm identifier of the one-way hash function employed with MGF1. The SHA-1 algorithm identifier is comprised of the id-sha1 object identifier and an (optional) parameter of NULL. Implementations that perform encryption MUST omit the maskGenFunc field when MGF1 with SHA-1 is used, indicating that the default algorithm was used.
MaskGenFUNCフィールドは、マスク生成関数を識別します。デフォルトのマスク生成関数は、SHA-1のMGF1です。MGF1の場合、基礎となるハッシュ関数がHashFuncによって識別されたものと同じであることを強くお勧めします。実装はMGF1をサポートする必要があります。MGF1には、MGF1アルゴリズム識別子のパラメーターフィールドで識別される一方向ハッシュ関数が必要です。実装はSHA-1をサポートする必要があり、セクション2.1にリストされている他の一方向ハッシュ関数のいずれかをサポートする場合があります。MGF1アルゴリズム識別子は、ID-MGF1オブジェクト識別子と、MGF1で使用される一方向ハッシュ関数のアルゴリズム識別子を含むパラメーターで構成されています。SHA-1アルゴリズム識別子は、ID-Sha1オブジェクト識別子とnullの（オプションの）パラメーターで構成されています。暗号化を実行する実装は、SHA-1を使用したMGF1が使用されているときにMaskGenFuncフィールドを省略する必要があり、デフォルトのアルゴリズムが使用されたことを示しています。
Although mfg1SHA1Identifier is defined as the default value for this field, implementations MUST accept both the default value encoding (i.e., an absent field) and the mfg1SHA1Identifier to be explicitly present in the encoding.
MFG1SHA1IDENTIFIERはこのフィールドのデフォルト値として定義されていますが、実装はエンコードに明示的に存在するデフォルト値エンコード（つまり、存在しないフィールド）とMFG1SHA1IDENIDEFIERの両方を受け入れる必要があります。
pSourceFunc
psourcefunc
The pSourceFunc field identifies the source (and possibly the value) of the encoding parameters, commonly called P. Implementations MUST represent P by an algorithm identifier, id-pSpecified, indicating that P is explicitly provided as an OCTET STRING in the parameters. The default value for P is an empty string. In this case, pHash in EME-OAEP contains the hash of a zero length string. Implementations MUST support a zero length P value. Implementations that perform encryption MUST omit the pSourceFunc field when a zero length P value is used, indicating that the default value was used. Implementations that perform decryption MUST recognize both the id-pSpecified object identifier and an absent pSourceFunc field as an indication that a zero length P value was used. Implementations that perform decryption MUST support a zero length P value and MAY support other values. Compliant implementations MUST NOT use any value other than id-pSpecified for pSourceFunc.
psourcefuncフィールドは、一般的にPと呼ばれるエンコードパラメーターのソース（および場合によっては、値）を識別します。実装は、パラメーター内のオクテット文字列としてPが明示的に提供されることを示すアルゴリズム識別子でpを表す必要があります。pのデフォルト値は空の文字列です。この場合、EME-OAEPのPhashにはゼロ長さの弦のハッシュが含まれています。実装は、ゼロの長さのp値をサポートする必要があります。暗号化を実行する実装は、ゼロの長さp値が使用されている場合にpsourcefuncフィールドを省略する必要があり、デフォルト値が使用されたことを示します。復号化を実行する実装は、ゼロ長さのp値が使用されたことを示すこととして、ID-PSICIFIEDオブジェクト識別子と存在しないpsourceFUNCフィールドの両方を認識する必要があります。復号化を実行する実装は、ゼロの長さP値をサポートし、他の値をサポートする必要があります。準拠の実装は、psourcefuncにID-psizefied以外の値を使用してはなりません。
If the default values of the hashFunc, maskGenFunc, and pSourceFunc fields of RSAES-OAEP-params are used, then the algorithm identifier will have the following value:
Hashfunc、MaskGenfunc、およびPsourceFuncフィールドのデフォルト値がRSAES-OAEP-PARAMSを使用している場合、アルゴリズム識別子には次の値があります。
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
rSAES-OAEP-Default-Params }
rSAES-OAEP-Default-Params RSASSA-OAEP-params ::=
{ sha1Identifier,
mgf1SHA1Identifier,
pSpecifiedEmptyIdentifier }
RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature algorithm. This specification is also included in PKCS #1 Version 2.1 [P1v2.1]. RFC 3279 [PKALGS] specifies the use of the PKCS #1 Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1 one-way hash functions. This section specifies the algorithm identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions with the PKCS #1 version 1.5 signature algorithm.
RFC 2313 [P1V1.5] PKCS＃1バージョン1.5署名アルゴリズムを指定します。この仕様は、PKCS＃1バージョン2.1 [P1V2.1]にも含まれています。RFC 3279 [PKALGS]は、MD2、MD5、およびSHA-1一方向ハッシュ関数を備えたPKCS＃1バージョン1.5署名アルゴリズムの使用を指定します。このセクションでは、PKCS＃1バージョン1.5署名アルゴリズムを使用して、SHA-224、SHA-256、SHA-384、およびSHA-512一元配置ハッシュ機能を使用するためのアルゴリズム識別子を指定します。
The RSASSA-PSS signature algorithm is preferred over the PKCS #1 Version 1.5 signature algorithm. Although no attacks are known against PKCS #1 Version 1.5 signature algorithm, in the interest of increased robustness, RSASSA-PSS signature algorithm is recommended for eventual adoption, especially by new applications. This section is included for compatibility with existing applications, and while still appropriate for new applications, a gradual transition to the RSASSA-PSS signature algorithm is encouraged.
RSASSA-PSS署名アルゴリズムは、PKCS＃1バージョン1.5署名アルゴリズムよりも推奨されます。PKCS＃1バージョン1.5の署名アルゴリズムに対して攻撃は知られていませんが、堅牢性の向上のために、特に新しいアプリケーションによって、最終的な採用にはRSassa-PSS署名アルゴリズムが推奨されます。このセクションは、既存のアプリケーションとの互換性のために含まれており、新しいアプリケーションに適していますが、RSASSA-PSS署名アルゴリズムへの段階的な移行が推奨されます。
The PKCS #1 Version 1.5 signature algorithm with these one-way hash functions and the RSA cryptosystem is implemented using the padding and encoding conventions described in RFC 2313 [P1v1.5].
これらの一方向ハッシュ関数を備えたPKCS＃1バージョン1.5署名アルゴリズムとRSA暗号システムは、RFC 2313 [P1v1.5]に記載されているパディングとエンコード規則を使用して実装されます。
The message digest is computed using the SHA-224, SHA-256, SHA-384, or SHA-512 one-way hash function.
メッセージダイジェストは、SHA-224、SHA-256、SHA-384、またはSHA-512一元配置ハッシュ関数を使用して計算されます。
The PKCS #1 version 1.5 signature algorithm, as specified in RFC 2313, includes a data encoding step. In this step, the message digest and the object identifier for the one-way hash function used to compute the message digest are combined. When performing the data encoding step, the id-sha224, id-sha256, id-sha384, and id-sha512 object identifiers (see Section 2.1) MUST be used to specify the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions, respectively.
RFC 2313で指定されているPKCS＃1バージョン1.5署名アルゴリズムには、データエンコーディングステップが含まれています。このステップでは、メッセージダイジェストと、メッセージダイジェストの計算に使用される一方向ハッシュ関数のオブジェクト識別子が組み合わされます。データエンコーディングステップを実行する場合、ID-SHA224、ID-SHA256、ID-SHA384、およびID-SHA512オブジェクト識別子（セクション2.1を参照）を使用して、SHA-224、SHA-256、SHA-384、およびSHA-384、およびSHA-512一方向ハッシュ関数。
The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-224 is:
PKCS＃1バージョン1.5署名アルゴリズムをSHA-224の識別に使用するオブジェクト識別子は次のとおりです。
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-256 is:
SHA-256を使用したPKCS＃1バージョン1.5署名アルゴリズムを識別するために使用されるオブジェクト識別子は次のとおりです。
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-384 is:
SHA-384を使用したPKCS＃1バージョン1.5署名アルゴリズムを識別するために使用されるオブジェクト識別子は次のとおりです。
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-512 is:
PKCS＃1バージョン1.5署名アルゴリズムをSHA-512の識別に識別するために使用されるオブジェクト識別子は次のとおりです。
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
When any of these four object identifiers appears within an AlgorithmIdentifier, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present.
これらの4つのオブジェクト識別子のいずれかがアルゴリズムIdentifierに表示される場合、パラメーターはnullでなければなりません。実装は、存在すると同時にパラメーターを受け入れる必要があります。
The RSA signature generation process and the encoding of the result are described in detail in RFC 2313 [P1v1.5].
RSA署名生成プロセスと結果のエンコードについては、RFC 2313 [P1v1.5]で詳しく説明しています。
PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS All;
- すべてをエクスポートします。
IMPORTS
輸入
AlgorithmIdentifier
FROM PKIX1Explicit88 -- Found in [PROFILE]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) } ;
-- ============================
-- Basic object identifiers
-- ============================
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) 1 }
-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-- When id-RSAES-OAEP is used in an AlgorithmIdentifier,
-- and the parameters field is present, it MUST be
-- RSAES-OAEP-params
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
-- When id-pSpecified is used in an AlgorithmIdentifier the
-- parameters MUST be an OCTET STRING.
id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
-- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the
-- parameters field is present, it MUST be RSASSA-PSS-params.
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
-- When id-mgf1 is used in an AlgorithmIdentifier the parameters
-- MUST be present and MUST be a HashAlgorithm.
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
-- When the following OIDs are used in an AlgorithmIdentifier, the
-- parameters MUST be present and MUST be NULL.
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters SHOULD be absent, but if the parameters are present,
-- they MUST be NULL.
id-sha1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26 }
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
-- =============
-- Constants
-- =============
nullOctetString OCTET STRING (SIZE (0)) ::= ''H
nullParameters NULL ::= NULL
-- =========================
-- Algorithm Identifiers
-- =========================
sha1Identifier AlgorithmIdentifier ::= {
algorithm id-sha1,
parameters nullParameters }
sha224Identifier AlgorithmIdentifier ::= {
algorithm id-sha224,
parameters nullParameters }
sha256Identifier AlgorithmIdentifier ::= {
algorithm id-sha256,
parameters nullParameters }
sha384Identifier AlgorithmIdentifier ::= {
algorithm id-sha384,
parameters nullParameters }
sha512Identifier AlgorithmIdentifier ::= {
algorithm id-sha512,
parameters nullParameters }
mgf1SHA1Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha1Identifier }
mgf1SHA224Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha224Identifier }
mgf1SHA256Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha256Identifier }
mgf1SHA384Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha384Identifier }
mgf1SHA512Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha512Identifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= {
algorithm id-pSpecified,
parameters nullOctetString }
rSASSA-PSS-Default-Params RSASSA-PSS-params ::= {
hashAlgorithm sha1Identifier,
maskGenAlgorithm mgf1SHA1Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-Default-Params }
rSASSA-PSS-SHA224-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-SHA224-Params }
rSASSA-PSS-SHA224-Params RSASSA-PSS-params ::= {
hashAlgorithm sha224Identifier,
maskGenAlgorithm mgf1SHA224Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-SHA256-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-SHA256-Params }
rSASSA-PSS-SHA256-Params RSASSA-PSS-params ::= {
hashAlgorithm sha256Identifier,
maskGenAlgorithm mgf1SHA256Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-SHA384-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-SHA384-Params }
rSASSA-PSS-SHA384-Params RSASSA-PSS-params ::= {
hashAlgorithm sha384Identifier,
maskGenAlgorithm mgf1SHA384Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSSASSA-PSS-SHA512-params }
rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= {
hashAlgorithm sha512Identifier,
maskGenAlgorithm mgf1SHA512Identifier,
saltLength 20,
trailerField 1 }
rSAES-OAEP-Default-Params RSAES-OAEP-params ::= {
hashFunc sha1Identifier,
maskGenFunc mgf1SHA1Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-Default-Params }
rSAES-OAEP-SHA224-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA224-Params }
rSAES-OAEP-SHA224-Params RSAES-OAEP-params ::= {
hashFunc sha224Identifier,
maskGenFunc mgf1SHA224Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA256-Params }
rSAES-OAEP-SHA256-Params RSAES-OAEP-params ::= {
hashFunc sha256Identifier,
maskGenFunc mgf1SHA256Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA384-Params }
rSAES-OAEP-SHA384-Params RSAES-OAEP-params ::= {
hashFunc sha384Identifier,
maskGenFunc mgf1SHA384Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA512-Params }
rSAES-OAEP-SHA512-Params RSAES-OAEP-params ::= {
hashFunc sha512Identifier,
maskGenFunc mgf1SHA512Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
-- ===================
-- Main structures
-- ===================
-- Used in SubjectPublicKeyInfo of X.509 Certificate.
-X.509証明書のsubjectpublickeyinfoで使用されます。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
-- AlgorithmIdentifier parameters for id-RSASSA-PSS.
-- Note that the tags in this Sequence are explicit.
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 }
HashAlgorithm ::= AlgorithmIdentifier
MaskGenAlgorithm ::= AlgorithmIdentifier
-- AlgorithmIdentifier parameters for id-RSAES-OAEP.
-- Note that the tags in this Sequence are explicit.
RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT
sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT
mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier }
END
終わり
[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月。
[P1v2.1] Jonsson, J. and B. Kaliski, "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月。
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[プロファイル] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[SHA2] National Institute of Standards and Technology (NIST), FIPS 180-2: Secure Hash Standard, 1 August 2002.
[SHA2]国立標準技術研究所（NIST）、FIPS 180-2：Secure Hash Standard、2002年8月1日。
[SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004.
[Sha224] Housley、R。、「224ビットの一方向のハッシュ関数：SHA-224」、RFC 3874、2004年9月。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[stdwords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[X.208-88] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[X.208-88] CCITTの推奨X.208：抽象的構文表記の仕様（ASN.1）、1988。
[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。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[GUIDE] National Institute of Standards and Technology, Second Draft: "Key Management Guideline, Part 1: General Guidance." June 2002. [http://csrc.nist.gov/encryption/kms/guideline-1.pdf]
[ガイド]国立標準技術研究所、第2草案：「主要な管理ガイドライン、パート1：一般ガイダンス。」2002年6月。[http://csrc.nist.gov/encryption/kms/guideline-1.pdf]
[P1363A] IEEE Std 1363a-2004, Standard Specifications for Public Key Cryptography - Amendment 1: Additional Techniques, 2004.
[P1363A] IEEE STD 1363A -2004、公開キー暗号化の標準仕様 - 修正1：追加の手法、2004年。
[PKALGS] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[PKALGS] Bassham、L.、Polk、W。、およびR. Housley、「インターネットのアルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3279、2002年4月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[ランダム] Eastlake 3rd、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[SHA-1-ATTACK] Wang, X., Yin, Y.L., and H. Yu, "Finding Collisions in the Full SHA1", to appear, CRYPTO 2005. Preprint available at http://theory.csail.mit.edu/~yiqun/shanote.pdf.
[Sha-1-attack] Wang、X.、Yin、Y.L。、およびH. Yu、「Full Sha1で衝突を見つける」、登場する、Crypto 2005. http://theory.csail.mit.eduで入手可能/~yiqun/shanote.pdf。
This specification supplements RFC 3280 [PROFILE]. The Security Considerations section of that document applies to this specification as well.
この仕様はRFC 3280 [プロファイル]をサプリメントします。そのドキュメントのセキュリティ上の考慮事項セクションは、この仕様にも適用されます。
Implementations must protect the RSA private key. Compromising the RSA private key may result in the disclosure of all messages protected with that key.
実装は、RSAの秘密鍵を保護する必要があります。RSAの秘密鍵を侵害すると、そのキーで保護されているすべてのメッセージが開示される可能性があります。
The generation of RSA public/private key pairs relies on a random numbers. Using inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys and search the resulting small set of possibilities, than to brute force search the whole key space. The generation of quality random numbers is difficult and RFC 1750 [RANDOM] offers important guidance in this area.
RSAパブリック/秘密鍵のペアの生成は、乱数に依存しています。不十分な擬似ランダム数ジェネレーター（PRNGS）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成するキーを生成したPRNG環境を再現し、キースペース全体をブルートフォースに検索するよりも、結果として生じる小さな可能性を検索する方がはるかに簡単になる場合があります。品質の乱数の生成は困難であり、RFC 1750 [ランダム]はこの分野で重要なガイダンスを提供します。
Generally, good cryptographic practice employs a given RSA key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security. While PKCS #1 Version 1.5 [P1v1.5] has been employed for both key transport and digital signature without any known bad interactions, such a combined use of an RSA key pair is not recommended in the future. Therefore, an RSA key pair used for RSASSA-PSS signature generation should not be used for other purposes. For similar reasons, one RSA key pair should always be used with the same RSASSA-PSS parameters (except possibly for the salt length). Likewise, an RSA key pair used for RSAES-OAEP key transport should not be used for other purposes. For similar reasons, one RSA key pair should always be used with the same RSAES-OAEP parameters.
一般的に、優れた暗号化の実践は、1つのスキームのみで特定のRSAキーペアを採用しています。このプラクティスは、あるスキームの脆弱性が他のスキームのセキュリティを損なう可能性があるというリスクを回避し、証明可能なセキュリティを維持するために不可欠である可能性があります。PKCS＃1バージョン1.5 [P1V1.5]は、既知の悪い相互作用なしに、主要な輸送とデジタル署名の両方に採用されていますが、RSAキーペアの組み合わせを将来使用することは推奨されません。したがって、RSASSA-PSS署名生成に使用されるRSAキーペアは、他の目的には使用しないでください。同様の理由で、1つのRSAキーペアは、同じRSASSA-PSSパラメーター（おそらく塩の長さを除く）で常に使用する必要があります。同様に、RSAES-OAEPキートランスポートに使用されるRSAキーペアは、他の目的に使用しないでください。同様の理由で、同じRSA-OAEPパラメーターで常に1つのRSAキーペアを使用する必要があります。
This specification requires implementations to support the SHA-1 one-way hash function for interoperability, but support for other one-way hash functions is permitted. Wang et al. [SHA-1-ATTACK] have recently discovered a collision attack against SHA-1 with complexity 2^69. This attack, which can produce two new messages with the same hash value, is the first attack on SHA-1 faster than the generic attack with complexity 2^80, where 80 is one-half the bit length of the hash value.
この仕様では、相互運用性のためにSHA-1一元配置ハッシュ関数をサポートするための実装が必要ですが、他の一方向ハッシュ関数のサポートが許可されています。Wang et al。[SHA-1-attack]は最近、複雑さ2^69でSHA-1に対する衝突攻撃を発見しました。同じハッシュ値を持つ2つの新しいメッセージを生成できるこの攻撃は、複雑さ2^80の一般的な攻撃よりもSHA-1に対する最初の攻撃であり、80はハッシュ値のビット長が半分です。
In general, when a one-way hash function is used with a digital signature scheme, a collision attack is easily translated into a signature forgery. Therefore, using SHA-1 in a digital signature scheme provides a security level of no more than 69 bits if the attacker can persuade the signer to sign a message resulting from a collision attack. If the attacker can't persuade the signer to sign such a message, however, then SHA-1 still provides a security level of at least 80 bits since the best (known) inversion attack (which produces a new message with a previous hash value) is the generic attack with complexity 2^160. If a greater level of security is desired, then a secure one-way hash function with a longer hash value is needed. SHA-256, SHA-384, and SHA-512 are reasonable choices [SHA2], although their security needs to be reconfirmed in light of the SHA-1 results.
一般に、一方向ハッシュ関数がデジタル署名スキームで使用される場合、衝突攻撃は署名の偽造に簡単に変換されます。したがって、デジタル署名スキームでSHA-1を使用すると、攻撃者が署名者に衝突攻撃に起因するメッセージに署名するよう説得する場合、69ビット以下のセキュリティレベルを提供します。ただし、攻撃者が署名者にそのようなメッセージに署名するよう説得できない場合、SHA-1は、最良の（既知の）反転攻撃から少なくとも80ビットのセキュリティレベルを提供します（以前のハッシュ値で新しいメッセージを生成します）複雑さ2^160の一般的な攻撃です。より大きなレベルのセキュリティが必要な場合、より長いハッシュ値を持つ安全な一方向ハッシュ関数が必要です。SHA-256、SHA-384、およびSHA-512は合理的な選択[SHA2]ですが、SHA-1の結果に照らしてセキュリティを再確認する必要があります。
The metrics for choosing a one-way hash function for use in digital signatures do not directly apply to the RSAES-OAEP key transport algorithm, since a collision attack on the one-way hash function does not directly translate into an attack on the key transport algorithm, unless the encoding parameters P vary (in which case a collision of the hash value for different encoding parameters might be exploited).
一元配置署名で使用するための一元配置ハッシュ関数を選択するためのメトリックは、一元配置ハッシュ関数への衝突攻撃が主要なトランスポートへの攻撃に直接変換されないため、RSAES-OAEPキートランスポートアルゴリズムに直接適用されません。アルゴリズム、エンコードパラメーターが異なる場合を除き（この場合、異なるエンコードパラメーターのハッシュ値の衝突が悪用される可能性があります）。
Nevertheless, for consistency with the practice for digital signature schemes, and in case the encoding parameters P is not the empty string, it is recommended that the same rule of thumb be applied to selecting a one-way hash function for use with RSAES-OAEP. That is, the one-way hash function should be selected so that the bit length of the hash value is at least twice as long as the desired security level in bits.
それにもかかわらず、デジタル署名スキームのプラクティスとの一貫性、およびエンコードパラメーターPが空の文字列ではない場合は、RSAES-OAEPで使用する一方向ハッシュ関数を選択するために同じ経験則を適用することをお勧めします。つまり、ハッシュ値のビット長がビットの目的のセキュリティレベルの少なくとも2倍の長さになるように、一元配置ハッシュ関数を選択する必要があります。
The key size selected impacts the strength achieved when implementing cryptographic services. Thus, selecting appropriate key sizes is critical to implementing appropriate security. A 1024-bit RSA public key is considered to provide a security level of about 80 bits. In [GUIDE], the National Institute of Standards and Technology (NIST) suggests that a security level of 80 bits is adequate for the protection of sensitive information until 2015. This recommendation is likely to be revised based on recent advances, and is expected to be more conservative, suggesting that a security level of 80 bits is adequate protection of sensitive information until 2010. If a security level greater than 80 bits is needed, then a longer RSA public key and a secure one-way hash function with a longer hash value are needed. SHA-224, SHA-256, SHA-384, and SHA-512 are reasonable choices for such a one-way hash function, modulo the reconfirmation noted above. For this reason, the algorithm identifiers for these one-way hash functions are included in the ASN.1 module in Section 6.
選択されたキーサイズは、暗号化サービスを実装するときに達成される強度に影響を与えます。したがって、適切なキーサイズを選択することは、適切なセキュリティを実装するために重要です。1024ビットRSA公開キーは、約80ビットのセキュリティレベルを提供すると見なされます。[ガイド]では、国立標準技術研究所（NIST）は、2015年までの機密情報の保護には80ビットのセキュリティレベルが適切であることを示唆しています。この推奨は、最近の進歩に基づいて修正される可能性が高く、セキュリティレベルの80ビットが2010年まで敏感な情報の適切な保護であることを示唆しています。80ビットを超えるセキュリティレベルが必要な場合は、より長いRSAの公開キーと、より長いハッシュを使用した安全な一方向ハッシュ関数が必要です。価値が必要です。SHA-224、SHA-256、SHA-384、およびSHA-512は、そのような一方向のハッシュ関数の合理的な選択です。このため、これらの一方向ハッシュ関数のアルゴリズム識別子は、セクション6のASN.1モジュールに含まれています。
Current implementations MUST support 1024-bit RSA public key sizes. Before the end of 2007, implementations SHOULD support RSA public key sizes of at least 2048 bits and SHOULD support SHA-256. This requirement is intended to allow adequate time for users to deploy the stronger digital signature capability by 2010.
現在の実装は、1024ビットRSA公開キーのサイズをサポートする必要があります。2007年末までに、実装は少なくとも2048ビットのRSA公開キーサイズをサポートし、SHA-256をサポートする必要があります。この要件は、2010年までにユーザーがより強力なデジタル署名機能を展開できるのに十分な時間を確保することを目的としています。
When using RSASSA-PSS, the same one-way hash function should be employed for the hashAlgorithm and the maskGenAlgorithm, but it is not required. When using RSAES-OAEP, the same one-way hash function should be employed for the hashFunc and the maskGenFunc, but it is not required. In each case, using the same one-way hash function helps with security analysis and reduces implementation complexity.
RSASSA-PSSを使用する場合、ハサルゴリズムとMaskGenalgorithmに同じ一方向ハッシュ関数を使用する必要がありますが、必須ではありません。RSAES-OAEPを使用する場合、HashfuncとMaskgenfuncに同じ一方向ハッシュ関数を使用する必要がありますが、必要ありません。いずれの場合も、同じ一方向ハッシュ関数を使用すると、セキュリティ分析に役立ち、実装の複雑さが低下します。
Within the certificates and CRLs, algorithms are identified by object identifiers. All object identifiers used in this document were assigned in Public-Key Cryptography Standards (PKCS) documents or by the National Institute of Standards and Technology (NIST). No further action by the IANA is necessary for this document or any anticipated updates.
証明書とCRL内で、オブジェクト識別子によってアルゴリズムが識別されます。このドキュメントで使用されているすべてのオブジェクト識別子は、パブリックキー暗号化基準（PKCS）ドキュメントまたは国立標準技術研究所（NIST）に割り当てられました。このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
Authors' Addresses
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com
Burt Kaliski RSA Laboratories 174 Middlesex Turnpike Bedford, MA 01730 USA
Burt Kaliski RSA Laboratories 174 Middlesex Turnpike Bedford、MA 01730 USA
EMail: bkaliski@rsasecurity.com
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251 USA
Jim Schaad Soaring Hawk Consulting Po Box 675 Gold Bar、WA 98251 USA
EMail: jimsch@exmsft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。