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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document 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.
このドキュメントのサプリメントのRFC 3279.これは、RSA確率の署名方式（RSASSA-PSS）署名アルゴリズム、RSA暗号化スキーム使用するための規則を説明 - で最適な非対称暗号パディング（RSAES-OAEP）キートランスポートアルゴリズムと追加の一方向ハッシュ関数を公開鍵暗号規格（PKCS）＃1バージョンのインターネットX.509公開鍵基盤（PKI）で1.5署名アルゴリズム。エンコーディングフォーマット、アルゴリズム識別子、およびパラメータのフォーマットが指定されています。
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.
この文書では、[PKALGS] RFC 3279を補足します。この文書では、RSASSA-PSS署名アルゴリズムとインターネットX.509公開鍵インフラストラクチャ（PKI）[PROFILE]でRSAES-OAEPキートランスポート・アルゴリズムを使用するための規則について説明します。これらのRSAベースのアルゴリズムの両方が[P1v2.1]で指定されています。これらのアルゴリズムのいずれかを採用する対象の公開鍵、及びRSASSA-PSS署名の符号化フォーマットのためのアルゴリズム識別子および関連パラメータが指定されています。 【P1v1.5]が指定されているPKCS＃1バージョン1.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 [PROFILE]。この仕様は、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、署名、及び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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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 [PROFILE]はインターネットアプリケーションで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.
伝統的に、rsaEncryptionオブジェクト識別子は、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.
rsaEncryptionオブジェクト識別子は、RSA秘密鍵の所有者がRSASSA-PSSまたはRSAES-OAEPのいずれかのみに公開鍵の使用を制限したくないときサブジェクトの公開鍵を識別するために続けています。この場合、rsaEncryptionオブジェクト識別子は、サブジェクト公開鍵情報内のアルゴリズム分野で使用する必要があり、およびパラメータフィールドが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オブジェクト識別子の使用に関連する規則のさらなる議論は、（[PKALGS]セクション2.3.1を参照）RFC 3279に見出すことができます。
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).
鍵の意図される用途には、（[PROFILE]、セクション4.2.1.3を参照）のkeyUsage証明書拡張で示されてもよいです。
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拡張子は、次の値のいずれかまたは両方を含まなければなりません。
nonRepudiation; and 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拡張子は、次の値の一つ以上を含める必要があります。
nonRepudiation;
digitalSignature;
keyCertSign; and
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公開鍵を使用しなければなりません、そして、RSASSA-PSS-paramsはが存在する場合、証明書のユーザは必須証明書内のサブジェクト公開鍵アルゴリズム識別子パラメータで識別された一方向ハッシュ関数、マスク生成関数、およびトレーラフィールドを使用してこれらの操作を行います。
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公開鍵を使用しなければならず、RSAES-OAEP-paramsはが存在する場合、証明書のユーザ証明書内のサブジェクト公開鍵アルゴリズム識別子パラメータで識別された一方向ハッシュ関数とマスク生成関数を使用してこれらの操作を実行しなければなりません。
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.
SHA-1、SHA-256、SHA-384およびSHA-：PKCS＃1バージョン2.1 [P1v2.1] RSASSA-PSS署名アルゴリズム及びRSAES-OAEPキートランスポートアルゴリズムと共に使用するための4つの一方向ハッシュ関数をサポート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.
これらのオブジェクト識別子に関連付けられているAlgorithmIdentifierパラメータフィールドのための2つの可能なエンコーディングがあります。 2つの選択肢がいるAlgorithmIdentifierのための1988年の構文が1997年の構文に翻訳されたとき、アルゴリズム識別子パラメータに関連付けられたオプションの損失から生じます。その後、オプションは、不具合報告を経て回収されたが、その後で、多くの人々は、アルゴリズムパラメータが必須だと考えました。他の人がそれらを完全に省略しながらこのため履歴の一部の実施形態は、NULL要素などのパラメータを符号化します。正しいエンコーディングパラメータフィールドを省略することです。 RSASSA-PSS及びRSAES-OAEPが定義された場合しかし、それは存在しないパラメータではなく、NULLパラメータを使用して行きました。
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.
MGF1 [P1v2.1]：1つのマスク生成関数はRSASSA-PSS署名アルゴリズム及びRSAES-OAEPキートランスポートアルゴリズムで使用されます。他のマスク生成関数は、この仕様でサポートされていません。
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で使用されるハッシュ関数を識別するhashAlgorithm値を持たなければなりません。この値は、セクション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プロフィール[PROFILE]でRSASSA-PSS署名アルゴリズムを使用するための規則について説明します。 RSASSA-PSS署名アルゴリズムはPKCS＃1バージョン2.1 [P1v2.1]で指定されています。セクション2.1およびセクション2.2で説明した1つのマスク生成関数で議論5一方向ハッシュ関数は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.
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を含まなければなりません。
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復号）が署名値を生成するために実行されます。この署名値はsignatureValueフィールドのビット列と証明書またはCertificateListの中に含まれる符号化された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をのAlgorithmIdentifierで使用する場合、パラメータは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.
署名するとき、おそらくsaltLength以外のパラメータは、所与のRSA鍵ペアのすべての用途のために固定されたままであることが推奨されます。
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
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.
hashAlgorithmフィールドには、ハッシュ関数を識別します。これは、セクション2.1に記載されているアルゴリズム識別子のいずれかである必要があり、デフォルトのハッシュ関数は、SHA-1です。実装は、SHA-1をサポートしなければならない、セクション2.1に記載されている他の一方向ハッシュ関数のいずれかをサポートするかもしれません。 SHA-1を用いた場合、署名生成を行う実装はデフォルトのアルゴリズムが使用されたことを示す、hashAlgorithmフィールドを省略しなければなりません。署名検証を行う実装はSHA-1を使用したことの指標としてsha1Identifierアルゴリズム識別子及び不在hashAlgorithmフィールドの両方を認識しなければなりません。
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のために、強く根本的なハッシュ関数はhashAlgorithmで識別されるものと同じであることが推奨されます。実装はMGF1をサポートしなければなりません。 MGF1はMGF1アルゴリズム識別子のパラメータフィールドで識別された一方向ハッシュ関数を必要とします。実装は、SHA-1をサポートしなければなりません、セクション、セクション2.1に記載されている他の一方向ハッシュ関数のいずれかをサポートするかもしれません。 MGF1アルゴリズム識別子は、ID-MGF1オブジェクト識別子とMGF1と共に使用一方向ハッシュ関数のアルゴリズム識別子が含まれているパラメータで構成されています。 SHA-1アルゴリズム識別子は、ID-SHA1オブジェクト識別子とNULLの（オプション）のパラメータで構成されています。 SHA-1とMGF1が使用される場合、署名生成を行う実装はデフォルトのアルゴリズムが使用されたことを示す、maskGenAlgorithmフィールドを省略しなければなりません。
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
ソルト長
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フィールドは、塩のオクテット長です。与えられたhashAlgorithmについて、saltLengthの推奨値は、ハッシュ値のオクテットの数です。タイプRSASSA-PSS-paramsは、他の分野とは異なり、saltLengthは、所与のRSA鍵ペアのために固定する必要がありません。異なる値が生成された各RSASSA-PSS署名に使用することができます。
trailerField
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.
trailerFieldフィールドは整数です。これは、IEEE規格の1363a-2004 [P1363A]との互換性を提供します。値は、16進数値の0xBCとトレーラフィールドを表す1でなければなりません。 IEEE STDの1363aに指定されている0xCCと連結HashIDで構成されるトレーラフィールドを含む他のトレーラーのフィールドは、サポートされていません。署名生成を実行する実装は、デフォルトのトレーラフィールド値が使用されたことを示す、trailerFieldフィールドを省略しなければなりません。署名検証を行う実装が値1を有する本trailerFieldフィールドおよび不在trailerFieldフィールドの両方を認識しなければなりません。
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のhashAlgorithm、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 [PROFILE]で署名値をビット列として表され、そして変換が必要です。
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.
ビット文字列に署名値を変換するために、署名値の最初のオクテットの最上位ビットはビット列の最初のビットになるなど、署名値の最後のオクテットの最下位ビットを介して、どのSHALLビット列の最後のビットになるもの。
Three possible parameter validation scenarios exist for RSASSA-PSS signature values.
三つの可能なパラメータの検証シナリオはRSASSA-PSS署名値のために存在します。
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フィールドは、より大きな又は重要なパラメータフィールドのそれと等しくなければなりません。
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プロフィール[PROFILE]でRSAES-OAEPキートランスポート・アルゴリズムを使用するための規則について説明します。 RSAES-OAEPは、PKCS＃1バージョン2.1 [P1v2.1]で指定されています。セクション2.1およびセクション2.2で説明した1つのマスク生成関数で議論5一方向ハッシュ関数は、RSAES-OAEPと共に使用することができます。準拠CAおよびアプリケーションは、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.
その問題CAS ID-RSAES-OAEPアルゴリズム識別子を持つ証明書はすべての証明書のための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をのAlgorithmIdentifierで使用する場合、パラメータは、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に記載されているアルゴリズム識別子のいずれかである必要があり、デフォルトのハッシュ関数は、SHA-1です。実装は、SHA-1をサポートしなければならない、セクション2.1に記載されている他の一方向ハッシュ機能をサポートすることができます。 SHA-1を用いた場合、暗号化を行う実装はデフォルトのアルゴリズムが使用されたことを示す、hashFuncフィールドを省略しなければなりません。復号化を実行する実装は、SHA-1を使用したことの指標としてsha1Identifierアルゴリズム識別子及び不在hashFuncフィールドの両方を認識しなければなりません。
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このフィールドのデフォルト値として定義されているが、実装は、符号化中に明示的に存在するデフォルト値の符号（すなわち、存在しないフィールド）とmfg1SHA1Identifier両方を受け入れなければなりません。
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が明示的パラメータのOCTET STRINGとして設けられていることを示す、アルゴリズム識別子、ID-pSpecifiedによってPを表現しなければなりません。 Pのデフォルト値は空の文字列です。この場合には、EME-OAEPでpHashはゼロ長の文字列のハッシュを含んでいます。実装はゼロ長P値をサポートしなければなりません。長さがゼロのP値が使用される場合、暗号化を行う実装では、デフォルト値が使用されたことを示す、pSourceFuncフィールドを省略しなければなりません。復号化を実行する実装はゼロ長P値が使用されたことの表示としてID-pSpecifiedオブジェクト識別子と不在pSourceFuncフィールドの両方を認識しなければなりません。復号化を実行する実装はゼロ長P値をサポートしなければならないし、他の値をサポートするかもしれません。準拠実装はpSourceFuncのid-pSpecified以外の値を使用してはなりません。
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:
RSAES-OAEP-のparamsのhashFunc、maskGenFunc、およびpSourceFuncフィールドのデフォルト値が使用されている場合には、アルゴリズム識別子は、次の値を持つことになります。
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.
PKCS＃1バージョン1.5署名アルゴリズム、RFC 2313で指定されるように、データ符号化ステップとを含みます。このステップでは、メッセージダイジェストと一方向ハッシュ関数のオブジェクト識別子は、ダイジェストを組み合わせたメッセージを計算するために使用されます。データ符号化ステップを実行する際に、ID-SHA224、ID-SHA256、ID-SHA384、及びID-SHA512オブジェクト識別子（セクション2.1を参照）はSHA-224、SHA-256、SHA-384を指定するために使用しなければならずSHA-512それぞれ一方向ハッシュ関数、。
The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-224 is:
SHA-224とPKCS＃1バージョン1.5署名アルゴリズムを識別するために使用されるオブジェクト識別子です。
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:
SHA-512とPKCS＃1バージョン1.5署名アルゴリズムを識別するために使用されるオブジェクト識別子です。
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.
これら四つのオブジェクト識別子のいずれかがのAlgorithmIdentifierの中に表示されたら、パラメータは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) }
PKIX1-PSS-OAEP-アルゴリズム{ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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) } ;
PKIX1Explicit88 FROMのAlgorithmIdentifier - [PROFILE] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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をのAlgorithmIdentifierで使用する場合 - - パラメータが存在しなければならないと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
- RSAES-OAEP-paramsは - ID-RSAES-OAEPは、のAlgorithmIdentifierで使用する場合 - およびパラメータフィールドが存在し、それがなければなりません
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をのAlgorithmIdentifierで使用する場合 - - パラメータは、オクテットストリングでなければなりません。
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をのAlgorithmIdentifierで使用された場合 - - パラメータフィールドが存在し、それは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がのAlgorithmIdentifierパラメータで使用する場合 - 存在していなければなりませんと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.
以下のOIDをのAlgorithmIdentifierで使用される場合、 - - パラメータが存在しなければならないと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.
- 以下のOIDをのAlgorithmIdentifierで使用される場合 - パラメータが存在しないはずであるが、パラメータが存在する場合、 - それらは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.
- ID-RSASSA-PSSのためのAlgorithmIdentifierパラメータ。 - このシーケンスのタグが明示的であることに注意してください。
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.
- ID-RSAES-OAEPのためのAlgorithmIdentifierパラメータ。 - このシーケンスのタグが明示的であることに注意してください。
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]ジョンソン、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.
[PROFILE] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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）は、180-2をFIPS：ハッシュ標準、2002年8月1日を固定します。
[SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004.
[SHA224] Housley氏、R.、 "224ビットの一方向ハッシュ関数：SHA224"、RFC 3874、2004年9月。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[STDWORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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：抽象構文記法1（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]
[ガイド]アメリカ国立標準技術研究所、セカンドドラフト：「キー管理ガイドライン、パート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]、RFC 3279 Bassham、L.、ポーク、W.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"、2002年4月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RANDOM]イーストレーク第3、D.、クロッカー、S.、およびJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、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.
[SHA1-ATTACK]王、X.、殷、YL、およびH.ユー、 "フルSHA1で検索衝突" は、表示されるように、http://theory.csail.mit.eduで利用可能CRYPTO 2005予稿集/~yiqun/shanote.pdf。
This specification supplements RFC 3280 [PROFILE]. The Security Considerations section of that document applies to this specification as well.
この仕様のサプリメントのRFC 3280 [PROFILE]。そのドキュメントのSecurity Considerations部は、同様に、この仕様に適用されます。
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公開鍵/秘密鍵ペアの生成は、乱数に依存しています。暗号鍵を生成するために不十分な疑似乱数発生器（のPRNG）を使用すると、ほとんどまたは全くセキュリティをもたらすことができます。攻撃者は、ブルートフォースに全体の鍵空間を検索するよりも、それははるかに簡単に鍵を生成PRNG環境を再現し、結果として起こる小さい可能性を探索するために見つけることがあります。品質の乱数の生成が困難とRFC 1750で[RANDOM]はこの領域で重要な指導を提供しています。
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.
一般的に、優れた暗号の練習は、唯一の方式で与えられたRSAキーのペアを採用しています。この方法は1つのスキームの脆弱性は、他のセキュリティを損なう可能性があり、かつ証明可能安全性を維持するために不可欠かもしれないリスクを回避することができます。 PKCS＃1バージョン1.5 [P1v1.5】任意の既知の悪い相互作用せずに両方主要な輸送およびデジタル署名のために使用されてきたが、RSA鍵ペアのこのような併用は、将来推奨されません。したがって、RSASSA-PSS署名生成のために使用されるRSA鍵ペアは、他の目的のために使用すべきではありません。同様の理由で、あるRSA鍵ペアは、常に（おそらく塩長さを除いて）同じRSASSA-PSSのパラメータを用いて使用されるべきです。同様に、RSAES-OAEPキー輸送のために使用されるRSA鍵のペアは、他の目的のために使用すべきではありません。同様の理由で、あるRSA鍵ペアは、常に同じRSAES-OAEPパラメータを用いて使用されるべきです。
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ら。 [SHA-1-ATTACK]は最近、複雑2 ^ 69でSHA-1の衝突攻撃を発見しました。同じハッシュ値を持つ2つの新しいメッセージを生成することができ、この攻撃は、80は、ハッシュ値の半分のビット長であり、複雑さ2 ^ 80とジェネリック攻撃よりSHA-1高速の最初の攻撃です。
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、セキュリティはSHA-1の結果に照らして再確認する必要があるが、合理的な選択肢[SHA2]です。
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キートランスポートアルゴリズムには適用されません。アルゴリズム、符号化パラメータPが変化しない限り（その場合、異なる符号化パラメータのハッシュ値の衝突が利用されるかもしれません）。
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を使用する場合は、同じ一方向ハッシュ関数はhashAlgorithmと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
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Burt Kaliski RSA Laboratories 174 Middlesex Turnpike Bedford, MA 01730 USA
バート・カリスキーRSA Laboratories社174ミドルターンパイクベッドフォード、MA 01730 USA
EMail: bkaliski@rsasecurity.com
メールアドレス：bkaliski@rsasecurity.com
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251 USA
ジムSchaad高騰ホークコンサルティング私書箱675ゴールドバー、WA 98251 USA
EMail: jimsch@exmsft.com
メールアドレス：jimsch@exmsft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。