[要約] RFC 3560は、暗号メッセージ構文（CMS）でのRSAES-OAEPキー輸送アルゴリズムの使用に関する規格です。このRFCの目的は、CMSでの安全なキー輸送を実現するために、RSAES-OAEPアルゴリズムの使用方法を定義することです。
Network Working Group R. Housley
Request for Comments: 3560 Vigil Security
Category: Standards Track July 2003
Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
暗号化メッセージ構文（CMS）でのRSAES-OAEPキー転送アルゴリズムの使用
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 (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients.
このドキュメントでは、暗号化メッセージ構文（CMS）でRSAES-OAEPキー転送アルゴリズムを使用するための規則について説明します。 CMSは、1つ以上の受信者用の暗号化されたコンテンツと暗号化されたコンテンツ暗号化キーで構成される、エンベロープデータコンテンツタイプを指定します。 RSAES-OAEPキー転送アルゴリズムを使用して、目的の受信者のコンテンツ暗号化キーを暗号化できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Enveloped-data Conventions . . . . . . . . . . . . . . . . . . 3
2.1. EnvelopedData Fields . . . . . . . . . . . . . . . . . . 3
2.2. KeyTransRecipientInfo Fields . . . . . . . . . . . . . . 4
3. RSAES-OAEP Algorithm Identifiers and Parameters. . . . . . . . 4
4. Certificate Conventions. . . . . . . . . . . . . . . . . . . . 6
5. SMIMECapabilities Attribute Conventions. . . . . . . . . . . . 8
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Statement . . . . . . . . . . . . 11
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References. . . . . . . . . . . . . . . . . . 11
10.2. Informative References. . . . . . . . . . . . . . . . . 12
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 18
PKCS #1 Version 1.5 [PKCS#1v1.5] specifies a widely deployed variant of the RSA key transport algorithm. PKCS #1 Version 1.5 key transport is vulnerable to adaptive chosen ciphertext attacks, especially when it is used to for key management in interactive applications. This attack is often referred to as the "Million Message Attack," and it explained in [RSALABS] and [CRYPTO98]. Exploitation of this vulnerability, which reveals the result of a particular RSA decryption, requires access to an oracle which will respond to hundreds of thousands of ciphertexts, which are constructed adaptively in response to previously received replies that provide information on the successes or failures of attempted decryption operations.
PKCS＃1バージョン1.5 [PKCS＃1v1.5]は、RSAキートランスポートアルゴリズムの広く展開されているバリアントを指定します。 PKCS＃1バージョン1.5のキートランスポートは、特にインタラクティブアプリケーションでのキー管理に使用されている場合に、選択された適応暗号文攻撃に対して脆弱です。この攻撃は「ミリオンメッセージ攻撃」と呼ばれることが多く、[RSALABS]と[CRYPTO98]で説明されています。特定のRSA復号化の結果を明らかにするこの脆弱性の悪用には、試行された成功または失敗に関する情報を提供する以前に受信した応答に応じて適応的に構築される数十万の暗号文に応答するオラクルへのアクセスが必要です復号化操作。
The attack is significantly less feasible in store-and-forward environments, such as S/MIME. RFC 3218 [MMA] discussed the countermeasures to this attack that are available when PKCS #1 Version 1.5 key transport is used in conjunction with the Cryptographic Message Syntax (CMS) [CMS].
この攻撃は、S / MIMEなどのストアアンドフォワード環境では実行可能性が大幅に低下します。 RFC 3218 [MMA]は、PKCS＃1バージョン1.5キートランスポートが暗号化メッセージ構文（CMS）[CMS]と組み合わせて使用される場合に利用可能なこの攻撃への対策について説明しました。
When PKCS #1 Version 1.5 key transport is applied as an intermediate encryption layer within an interactive request-response communications environment, exploitation could be more feasible. However, Secure Sockets Layer (SSL) [SSL] and Transport Layer Security (TLS) [TLS] protocol implementations could include countermeasures that detect and prevent the Million Message Attack and other chosen-ciphertext attacks. These countermeasures are performed within the protocol level.
PKCS＃1バージョン1.5のキートランスポートが、対話型の要求と応答の通信環境内の中間暗号化層として適用されると、悪用がより現実的になる可能性があります。ただし、Secure Sockets Layer（SSL）[SSL]およびTransport Layer Security（TLS）[TLS]プロトコルの実装には、ミリオンメッセージ攻撃およびその他の選択された暗号文攻撃を検出および防止する対策を含めることができます。これらの対策は、プロトコルレベルで実行されます。
In the interest of long-term security assurance, it is prudent to adopt an improved cryptographic technique rather than embedding countermeasures within protocols. To this end, an updated version of PKCS #1 has been published. PKCS #1 Version 2.1 [PKCS#1v2.1] supersedes RFC 2313. It preserves support for the PKCS #1 Version 1.5 encryption padding format, and it also defines a new one. To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 Version 2.1 specifies and recommends use of Optimal Asymmetric Encryption Padding (OAEP) for RSA key transport.
長期的なセキュリティ保証のために、プロトコル内に対策を組み込むのではなく、改良された暗号化技術を採用することが賢明です。この目的のために、PKCS＃1の更新バージョンが公開されました。 PKCS＃1バージョン2.1 [PKCS＃1v2.1]は、RFC 2313に取って代わります。PKCS＃1バージョン1.5暗号化パディング形式のサポートを維持し、新しい形式も定義します。選択された適応暗号文の脆弱性を解決するために、PKCS＃1バージョン2.1は、RSAキー転送に最適な非対称暗号化パディング（OAEP）の使用を指定および推奨しています。
This document specifies the use of RSAES-OAEP key transport algorithm in the CMS. The CMS can be used in either a store-and-forward or an interactive request-response environment.
このドキュメントでは、CMSでのRSAES-OAEPキー転送アルゴリズムの使用について説明します。 CMSは、ストアアンドフォワードまたはインタラクティブな要求/応答環境で使用できます。
The CMS supports variety of architectures for certificate-based key management, particularly the one defined by the PKIX working group [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.1 require the same RSA public key information. Thus, a certified RSA public key may be used with either RSA key transport technique.
CMSは、証明書ベースのキー管理のためのさまざまなアーキテクチャ、特にPKIXワーキンググループ[プロファイル]によって定義されたものをサポートしています。 PKCS＃1バージョン1.5およびPKCS＃1バージョン2.1では、同じRSA公開鍵情報が必要です。したがって、認定されたRSA公開鍵は、どちらのRSA鍵転送技術でも使用できます。
The CMS uses ASN.1 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88].
CMSは、ASN.1 [X.208-88]、Basic Encoding Rules（BER）[X.209-88]、およびDistinguished Encoding Rules（DER）[X.509-88]を使用します。
Throughout this document, when the terms "MUST", "MUST NOT", "SHOULD", and "MAY" are used in capital letters, their use conforms to the definitions in RFC 2119 [STDWORDS]. These key word definitions help make the intent of standards documents as clear as possible. These key words are used in this document to help implementers achieve interoperability.
このドキュメント全体で、「MUST」、「MUST NOT」、「SHOULD」、および「MAY」という用語が大文字で使用されている場合、それらの使用はRFC 2119 [STDWORDS]の定義に準拠しています。これらのキーワードの定義は、標準文書の意図を可能な限り明確にするのに役立ちます。このドキュメントでは、これらのキーワードを使用して、実装者が相互運用性を実現できるようにしています。
The CMS enveloped-data content type consists of an encrypted content and wrapped content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm is used to wrap the content-encryption key for one recipient.
CMSエンベロープデータコンテンツタイプは、暗号化されたコンテンツと1人以上の受信者用のラップされたコンテンツ暗号化キーで構成されます。 RSAES-OAEPキー転送アルゴリズムは、1人の受信者のコンテンツ暗号化キーをラップするために使用されます。
Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 6, "Enveloped-data Content Type".
準拠ソフトウェアは、[CMS]セクション6「エンベロープデータコンテンツタイプ」で述べられているエンベロープデータコンテンツタイプを構築するための要件を満たさなければなりません。
A content-encryption key MUST be randomly generated for each instance of an enveloped-data content type. The content-encryption key is used to encipher the content.
コンテンツ暗号化キーは、エンベロープデータコンテンツタイプのインスタンスごとにランダムに生成する必要があります。コンテンツ暗号化キーは、コンテンツを暗号化するために使用されます。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as described in this section when RSAES-OAEP key transport is employed for one or more recipients.
エンベロープデータコンテンツタイプは、EnvelopedData構文を使用してエンコードされたASN.1です。 EnvelopedData構文のフィールドは、RSAES-OAEPキートランスポートが1人以上の受信者に使用される場合、このセクションで説明されているように入力する必要があります。
The EnvelopedData version MUST be 0, 2, or 3.
EnvelopedDataのバージョンは0、2、または3でなければなりません。
The EnvelopedData originatorInfo field is not used for the RSAES-OAEP key transport algorithm. However, this field MAY be present to support recipients using other key management algorithms.
EnvelopedData originatorInfoフィールドは、RSAES-OAEPキー転送アルゴリズムでは使用されません。ただし、このフィールドは、他のキー管理アルゴリズムを使用する受信者をサポートするために存在する場合があります。
The EnvelopedData recipientInfos CHOICE MUST be KeyTransRecipientInfo. See section 2.2 for further discussion of KeyTransRecipientInfo.
EnvelopedData recipientInfos CHOICEはKeyTransRecipientInfoでなければなりません。 KeyTransRecipientInfoの詳細については、セクション2.2を参照してください。
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm field MUST be a symmetric encryption algorithm identifier.
EnvelopedData encryptedContentInfo contentEncryptionAlgorithmフィールドは、対称暗号化アルゴリズムの識別子でなければなりません。
The EnvelopedData unprotectedAttrs MAY be present.
EnvelopedData unprotectedAttrsが存在する場合があります。
The fields of the KeyTransRecipientInfo syntax MUST be populated as described in this section when RSAES-OAEP key transport is employed for one or more recipients.
RSAES-OAEPキートランスポートが1人以上の受信者に採用されている場合、KeyTransRecipientInfo構文のフィールドは、このセクションで説明されているように入力する必要があります。
The KeyTransRecipientInfo version MUST be 0 or 2. If the RecipientIdentifier uses the issuerAndSerialNumber alternative, then the version MUST be 0. If the RecipientIdentifier uses the subjectKeyIdentifier alternative, then the version MUST be 2.
KeyTransRecipientInfoのバージョンは0または2でなければなりません。RecipientIdentifierがissuerAndSerialNumber代替を使用する場合、バージョンは0でなければなりません。RecipientIdentifierがsubjectKeyIdentifier代替を使用する場合、バージョンは2でなければなりません。
The KeyTransRecipientInfo RecipientIdentifier provides two alternatives for specifying the recipient's certificate, and thereby the recipient's public key. The recipient's certificate MUST contain a RSA public key. The content-encryption key is encrypted with the recipient's RSA public key. The issuerAndSerialNumber alternative identifies the recipient's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier identifies the recipient's certificate by the X.509 subjectKeyIdentifier extension value.
KeyTransRecipientInfo RecipientIdentifierは、受信者の証明書を指定するための2つの代替手段を提供し、それにより受信者の公開鍵を提供します。受信者の証明書には、RSA公開鍵が含まれている必要があります。コンテンツ暗号化キーは、受信者のRSA公開キーで暗号化されます。 issuerAndSerialNumber代替では、発行者の識別名と証明書のシリアル番号によって受信者の証明書を識別します。 subjectKeyIdentifierは、X.509 subjectKeyIdentifier拡張値によって受信者の証明書を識別します。
The KeyTransRecipientInfo keyEncryptionAlgorithm specifies use of the RSAES-OAEP algorithm, and its associated parameters, to encrypt the content-encryption key for the recipient. The key-encryption process is described in [PKCS#1v2.1]. See section 3 of this document for the algorithm identifier and the parameter syntax.
KeyTransRecipientInfo keyEncryptionAlgorithmは、RSAES-OAEPアルゴリズムとその関連パラメーターの使用を指定して、受信者のコンテンツ暗号化キーを暗号化します。鍵暗号化プロセスは、[PKCS＃1v2.1]で説明されています。アルゴリズム識別子とパラメーター構文については、このドキュメントのセクション3を参照してください。
The KeyTransRecipientInfo encryptedKey is the result of encrypting the content-encryption key in the recipient's RSA public key using the RSAES-OAEP algorithm. The RSA public key MUST be at least 1024 bits in length. When using a Triple-DES [3DES] content-encryption key, implementations MUST adjust the parity bits to ensure odd parity for each octet of each DES key comprising the Triple-DES key prior to RSAES-OAEP encryption.
KeyTransRecipientInfo encryptedKeyは、RSAES-OAEPアルゴリズムを使用して受信者のRSA公開鍵のコンテンツ暗号化鍵を暗号化した結果です。 RSA公開鍵の長さは少なくとも1024ビットでなければなりません。 Triple-DES [3DES]コンテンツ暗号化キーを使用する場合、RSAES-OAEP暗号化の前に、実装はパリティビットを調整して、Triple-DESキーを構成する各DESキーの各オクテットの奇数パリティを保証する必要があります。
The RSAES-OAEP key transport algorithm is the RSA encryption scheme
defined in RFC 3447 [PKCS#1v2.1], where the message to be encrypted
is the content-encryption key. The algorithm identifier for
RSAES-OAEP is:
id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain RSAES-OAEP-params. RSAES-OAEP-params has the following syntax:
AlgorithmIdentifierパラメーターフィールドが存在する必要があり、パラメーターフィールドにはRSAES-OAEP-paramsが含まれている必要があります。 RSAES-OAEP-paramsの構文は次のとおりです。
RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier }
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
mgf1SHA1Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha1Identifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=
{ id-pSpecified, nullOctetString }
nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
id-sha1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26 }
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) }
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
The fields within RSAES-OAEP-params have the following meanings:
RSAES-OAEP-params内のフィールドには次の意味があります。
hashFunc identifies the one-way hash function. Implementations MUST support SHA-1 [SHA1], and implementations MAY support other one-way hash functions. The SHA-1 algorithm identifier is comprised of the id-sha1 object identifier and a parameter of NULL. 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 id-sha1 object identifier and an absent hashFunc field as an indication that SHA-1 was used.
hashFuncは一方向ハッシュ関数を識別します。実装はSHA-1 [SHA1]をサポートする必要があり、実装は他の一方向ハッシュ関数をサポートしてもよい（MAY）。 SHA-1アルゴリズム識別子は、id-sha1オブジェクト識別子とNULLのパラメーターで構成されます。暗号化を実行する実装は、SHA-1が使用されている場合、デフォルトのアルゴリズムが使用されたことを示すhashFuncフィールドを省略しなければなりません（MUST）。復号化を実行する実装は、id-sha1オブジェクト識別子と存在しないhashFuncフィールドの両方を、SHA-1が使用されたことを示すものとして認識しなければなりません（MUST）。
maskGenFunc identifies the mask generation function. Implementations MUST support MFG1 [PKCS#1v2.1]. MFG1 requires a one-way hash function, and it is identified in the parameter field of the MFG1 algorithm identifier. Implementations MUST support SHA-1 [SHA1], and implementations MAY support other one-way hash functions. The MFG1 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 MFG1. The SHA-1 algorithm identifier is comprised of the id-sha1 object identifier and a parameter of NULL. Implementations that perform encryption MUST omit the maskGenFunc field when MFG1 with SHA-1 is used, indicating that the default algorithm was used. Implementations that perform decryption MUST recognize both the id-mgf1 and id-sha1 object identifiers as well as an absent maskGenFunc field as an indication that MFG1 with SHA-1 was used.
maskGenFuncは、マスク生成関数を識別します。実装はMFG1 [PKCS＃1v2.1]をサポートする必要があります。 MFG1には一方向ハッシュ関数が必要であり、MFG1アルゴリズム識別子のパラメーターフィールドで識別されます。実装はSHA-1 [SHA1]をサポートする必要があり、実装は他の一方向ハッシュ関数をサポートしてもよい（MAY）。 MFG1アルゴリズム識別子は、id-mgf1オブジェクト識別子と、MFG1で使用される一方向ハッシュ関数のアルゴリズム識別子を含むパラメーターで構成されます。 SHA-1アルゴリズム識別子は、id-sha1オブジェクト識別子とNULLのパラメーターで構成されます。暗号化を実行する実装は、デフォルトのアルゴリズムが使用されたことを示す、SHA-1を備えたMFG1が使用される場合、maskGenFuncフィールドを省略しなければなりません（MUST）。復号化を実行する実装は、id-mgf1とid-sha1の両方のオブジェクト識別子と、SHA-1を備えたMFG1が使用されたことを示すための欠落したmaskGenFuncフィールドを認識しなければなりません（MUST）。
pSourceFunc identifies the source (and possibly the value) of the encoding parameters, commonly called P. Implementations MUST represent P by the 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.
pSourceFuncは、一般にPと呼ばれるエンコーディングパラメータのソース（および場合によっては値）を識別します。実装では、Pをアルゴリズム識別子id-pSpecifiedで表現する必要があります。これは、PがパラメータのOCTET STRINGとして明示的に提供されていることを示します。 Pのデフォルト値は空の文字列です。この場合、EME-OAEPのpHashには、長さがゼロの文字列のハッシュが含まれています。実装では、長さゼロのP値をサポートする必要があります。暗号化を実行する実装では、長さがゼロのP値が使用されている場合、pSourceFuncフィールドを省略しなければなりません。これは、デフォルト値が使用されたことを示します。復号化を実行する実装は、id-pSpecifiedオブジェクト識別子と存在しないpSourceFuncフィールドの両方を、長さゼロのP値が使用されたことを示すものとして認識しなければなりません（MUST）。
RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates in Internet applications. When a RSA public key will be used for RSAES-OAEP key transport, the conventions specified in this section augment RFC 3280.
RFC 3280 [PROFILE]は、インターネットアプリケーションでX.509証明書を使用するためのプロファイルを指定しています。 RSA公開鍵を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 the Security Considerations section of this document (see section 6), the certificate user needs to be able to determine the form of key transport that the RSA private key owner associates with the public key.
従来、rsaEncryptionオブジェクト識別子は、RSA公開鍵を識別するために使用されていました。ただし、このドキュメントのセキュリティに関する考慮事項セクション（セクション6を参照）で説明されているすべての推奨事項を実装するには、証明書ユーザーは、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 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秘密鍵の所有者が公開鍵の使用をRSAES-OAEPに限定することを望まない場合、rsaEncryptionオブジェクト識別子は引き続き対象の公開鍵を識別します。この場合、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 [CERTALGS], section 2.3.1).
rsaEncryptionオブジェクト識別子の使用に関連する規則の詳細については、RFC 3279を参照してください（[CERTALGS]、セクション2.3.1を参照）。
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 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 3 of this document.
RSA秘密鍵の所有者が公開鍵の使用をRSAES-OAEPのみに制限したい場合、id-RSAES-OAEPオブジェクト識別子をサブジェクトの公開鍵情報内のアルゴリズムフィールドで使用する必要があり、パラメータフィールドには必ず含める必要があります。 RSAES-OAEP-params。 id-RSAES-OAEPオブジェクト識別子の値とRSAES-OAEP-params構文については、このドキュメントのセクション3で詳しく説明しています。
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 BIT STRINGに含まれています。
The intended application for the key MAY be indicated in the key usage certificate extension (see [PROFILE], section 4.2.1.3). If the keyUsage extension is present in a certificate that conveys an RSA public key with the id-RSAES-OAEP object identifier, then the key usage extension MUST contain a combination of the following values:
鍵の意図されたアプリケーションは、鍵使用証明書拡張で示されるかもしれません（[プロファイル]、セクション4.2.1.3を参照）。 keyUsage拡張が、id-RSAES-OAEPオブジェクト識別子を持つRSA公開鍵を伝達する証明書に存在する場合、鍵使用拡張には、次の値の組み合わせが含まれている必要があります。
keyEncipherment; and dataEncipherment.
keyEncipherment;およびdataEncipherment。
However, both keyEncipherment and dataEncipherment SHOULD NOT be present.
ただし、keyEnciphermentとdataEnciphermentの両方が存在してはなりません（SHOULD NOT）。
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 the certificate user MUST perform those operations using the parameters identified in the certificate.
id-RSAES-OAEPオブジェクト識別子を使用してRSA公開鍵を伝達する証明書の場合、証明書ユーザーは、RSAES-OAEP操作に認定されたRSA公開鍵のみを使用する必要があり、証明書ユーザーは、証明書。
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a signedData object, compliant software MAY include the SMIMECapabilities signed attribute announcing that it supports the RSAES-OAEP algorithm.
RFC 2633 [MSG]、セクション2.5.2は、SMIMECapabilitiesを通知するソフトウェアがサポートできるアルゴリズムの部分的なリストを指定するために使用するSMIMECapabilities署名属性（SMIMECapability SEQUENCEのSEQUENCEとして定義）を定義します。 signedDataオブジェクトを作成するとき、準拠ソフトウェアは、RSAES-OAEPアルゴリズムをサポートすることを通知するSMIMECapabilities署名属性を含めることができます（MAY）。
When all of the default settings are selected, the SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the id-RSAES-OAEP object identifier in the capabilityID field and MUST include an empty SEQUENCE in the parameters field. In this case, RSAES-OAEP is represented by the rSAES-OAEP-Default-Identifier:
すべてのデフォルト設定が選択されている場合、RSAES-OAEPを表すSMIMECapability SEQUENCEは、capabilityIDフィールドにid-RSAES-OAEPオブジェクト識別子を含める必要があり、パラメーターフィールドに空のSEQUENCEを含める必要があります。この場合、RSAES-OAEPはrSAES-OAEP-Default-Identifierで表されます。
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha1Identifier,
mgf1SHA1Identifier,
pSpecifiedEmptyIdentifier } }
The SMIMECapability SEQUENCE representing rSAES-OAEP-Default-Identifier MUST be DER-encoded as the following hexadecimal string:
rSAES-OAEP-Default-Identifierを表すSMIMECapability SEQUENCEは、次の16進文字列としてDERエンコードする必要があります。
30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00
30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00
When settings other than the defaults are selected, the SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the id-RSAES-OAEP object identifier in the capabilityID field and MUST include the RSAES-OAEP-params SEQUENCE that identifies the non-default settings in the parameters field.
デフォルト以外の設定が選択されている場合、RSAES-OAEPを表すSMIMECapability SEQUENCEは、capabilityIDフィールドにid-RSAES-OAEPオブジェクト識別子を含める必要があり、パラメーターにデフォルト以外の設定を識別するRSAES-OAEP-params SEQUENCEを含める必要がありますフィールド。
When SHA-256 is used in the hashFunc and SHA-256 is used with MGF1 in the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP is the rSAES-OAEP-SHA256-Identifier, as specified in Appendix A. The SMIMECapability SEQUENCE representing rSAES-OAEP-SHA256-Identifier MUST be DER-encoded as the following hexadecimal string:
SHA-256がhashFuncで使用され、SHA-256がmaskGenFuncでMGF1と共に使用される場合、RSAES-OAEPを表すSMIMECapability SEQUENCEは、付録Aで指定されているように、rSAES-OAEP-SHA256-Identifierです。rSAES-を表すSMIMECapability SEQUENCE OAEP-SHA256-Identifierは、次の16進文字列としてDERエンコードする必要があります。
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00
When SHA-384 is used in the hashFunc and SHA-384 is used with MGF1 in the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP is the rSAES-OAEP-SHA384-Identifier, as specified in Appendix A. The
SHA-384がhashFuncで使用され、SHA-384がmaskGenFuncでMGF1と共に使用される場合、RSAES-OAEPを表すSMIMECapability SEQUENCEは、付録Aで指定されているように、rSAES-OAEP-SHA384-Identifierです。
SMIMECapability SEQUENCE representing rSAES-OAEP-SHA384-Identifier MUST be DER-encoded as the following hexadecimal string:
rSAES-OAEP-SHA384-Identifierを表すSMIMECapability SEQUENCEは、次の16進文字列としてDERエンコードする必要があります。
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 0D 06 09 60 86 48 01 65 03 04 02 05 00 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00
When SHA-512 is used in the hashFunc and SHA-512 is used with MGF1 in the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP is the rSAES-OAEP-SHA512-Identifier, as specified in Appendix A. The SMIMECapability SEQUENCE representing rSAES-OAEP-SHA512-Identifier MUST be DER-encoded as the following hexadecimal string:
SHA-512がhashFuncで使用され、SHA-512がmaskGenFuncでMGF1と共に使用される場合、RSAES-OAEPを表すSMIMECapability SEQUENCEは、付録Aで指定されているように、rSAES-OAEP-SHA512-Identifierです。rSAES-を表すSMIMECapability SEQUENCE OAEP-SHA512-Identifierは、次の16進文字列としてDERエンコードする必要があります。
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00
Implementations must protect the RSA private key and the content-encryption key. Compromise of the RSA private key may result in the disclosure of all messages protected with that key. Compromise of the content-encryption key may result in disclosure of the associated encrypted content.
実装では、RSA秘密鍵とコンテンツ暗号化鍵を保護する必要があります。 RSA秘密鍵の侵害により、その鍵で保護されているすべてのメッセージが漏洩する可能性があります。コンテンツ暗号化キーが侵害されると、関連する暗号化コンテンツが漏洩する可能性があります。
The generation of RSA public/private key pairs relies on a random numbers. The use of 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, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 1750 [RANDOM] offers important guidance in this area.
RSA公開/秘密鍵ペアの生成は、乱数に依存します。不十分な疑似乱数ジェネレーター（PRNG）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、キーを生成した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 [PKCS#1v1.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 RSAES-OAEP key transport should not also be used for other purposes. For similar reasons, one RSA key pair should always be used with the same RSAES-OAEP parameters.
一般に、優れた暗号化プラクティスでは、1つのスキームのみで特定のRSAキーペアを使用します。この方法は、1つのスキームの脆弱性が他のスキームのセキュリティを危険にさらす可能性があるリスクを回避し、証明可能なセキュリティを維持するために不可欠である可能性があります。 PKCS＃1バージョン1.5 [PKCS＃1v1.5]は既知の悪い相互作用なしにキー転送とデジタル署名の両方に採用されていますが、RSAキーペアのこのような併用は将来推奨されません。したがって、RSAES-OAEPキートランスポートに使用されるRSAキーペアを他の目的に使用しないでください。同様の理由で、1つのRSAキーペアは常に同じRSAES-OAEPパラメータで使用する必要があります。
This specification requires implementation to support the SHA-1 one-way hash function for interoperability, but support for other one-way hash function is permitted. At the time of this writing, the best (known) collision attacks against SHA-1 are generic attacks with complexity 2^80, where 80 is one-half the bit length of the hash value. When a one-way hash function is used with a digital signature scheme, a collision attack is easily translated into a signature forgery. Therefore, the use of SHA-1 in a digital signature scheme provides a security level of no more than 80 bits. 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 likely candidates [SHA2].
この仕様では、相互運用性のためにSHA-1一方向ハッシュ関数をサポートするための実装が必要ですが、他の一方向ハッシュ関数のサポートは許可されています。この記事の執筆時点で、SHA-1に対する最良の（既知の）衝突攻撃は、複雑さ2 ^ 80の一般的な攻撃であり、80はハッシュ値のビット長の半分です。一方向ハッシュ関数をデジタル署名方式で使用すると、衝突攻撃は簡単に署名偽造に変換されます。したがって、デジタル署名方式でSHA-1を使用すると、セキュリティレベルは80ビット以下になります。より高いレベルのセキュリティが必要な場合は、より長いハッシュ値を持つ安全な一方向ハッシュ関数が必要です。 SHA-256、SHA-384、およびSHA-512が候補になりそうです[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 varies (in which case a collision 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 selection of 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倍になるように選択する必要があります。
A 1024-bit RSA public key and SHA-1 both provide a security level of about 80 bits. In [NISTGUIDE], the National Institute of Standards and Technology suggests that a security level of 80 bits is adequate for most applications until 2015. 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. Again, SHA-256, SHA-384, and SHA-512 are likely candidates for such a one-way hash function. For this reason, the algorithm identifiers for these one-way hash functions are included in the ASN.1 module in Appendix A.
1024ビットのRSA公開鍵とSHA-1はどちらも約80ビットのセキュリティレベルを提供します。 [NISTGUIDE]で、国立標準技術研究所は、2015年までのほとんどのアプリケーションに80ビットのセキュリティレベルが適切であると提案しています。80ビットを超えるセキュリティレベルが必要な場合は、より長いRSA公開鍵と安全な1長いハッシュ値を持つハッシュ関数が必要です。この場合も、SHA-256、SHA-384、およびSHA-512は、このような一方向ハッシュ関数の候補である可能性があります。このため、これらの一方向ハッシュ関数のアルゴリズム識別子は、付録AのASN.1モジュールに含まれています。
The same one-way hash function should be employed for the hashFunc and the maskGenFunc, but it is not required. Using the same one-way hash function reduces the potential for implementation errors.
同じ一方向ハッシュ関数をhashFuncとmaskGenFuncに使用する必要がありますが、必須ではありません。同じ一方向ハッシュ関数を使用すると、実装エラーの可能性が減少します。
Within the CMS, algorithms are identified by object identifiers (OIDs). All of the OIDs 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.
CMS内では、アルゴリズムはオブジェクト識別子（OID）によって識別されます。このドキュメントで使用されているすべてのOIDは、公開鍵暗号化標準（PKCS）ドキュメントまたは国立標準技術研究所（NIST）によって割り当てられました。このドキュメントまたは予想される更新については、IANAによるさらなるアクションは必要ありません。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開のために利用可能にされた権利の主張および利用可能にされるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、この規格を実践するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IETF Executive Directorに情報を送信してください。
This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. Further, I extend a special thanks to Burt Kaliski, Jakob Jonsson, Francois Rousseau, and Jim Schaad.
このドキュメントは、多くの専門家からの寄稿の結果です。 IETF S / MIMEワーキンググループのすべてのメンバーのハードワークに感謝します。さらに、バートカリスキ、ヤコブジョンソン、フランソワルソー、ジムシャードに特に感謝します。
This section provides normative and informative references.
このセクションでは、規範的で有益なリファレンスを提供します。
[3DES] American National Standards Institute. ANSI X9.52- 1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
[3DES] American National Standards Institute。 ANSI X9.52- 1998、トリプルデータ暗号化アルゴリズムの動作モード。 1998年
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3369、2002年8月。
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG] Ramsdell、B。、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[PKCS#1v2.1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications, Version 2.1", RFC 3447, February 2003.
[PKCS＃1v2.1] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications、Version 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月。
[SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: "Secure Hash Standard." April 1995.
[SHA1]国立標準技術研究所。 FIPS Pub 180-1：「Secure Hash Standard」。 1995年4月。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、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。
[CERTALGS] 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.
[CERTALGS] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月。
[CRYPTO98] Bleichenbacher, D. "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1", in H. Krawczyk (editor), Advances in Cryptology - CRYPTO '98 Proceedings, Lecture Notes in Computer Science 1462 (1998), Springer-Verlag, pp. 1-12.
[CRYPTO98]ブライチェンバッハ、D。「RSA暗号化標準PKCS＃1に基づくプロトコルに対する選択された暗号文攻撃」、H。クローチク（編集者）、暗号学の進歩-CRYPTO '98 Proceedings、Lecture Notes in Computer Science 1462（1998） 、Springer-Verlag、1〜12ページ。
[MMA] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.
[MMA] Rescorla、E。、「暗号化メッセージ構文に対するミリオンメッセージ攻撃の防止」、RFC 3218、2002年1月。
[NISTGUIDE] 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]
[PKCS#1v1.5] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, March 1998.
[PKCS＃1v1.5] Kaliski、B。、「PKCS＃1：RSA Encryption、バージョン1.5」、RFC 2313、1998年3月。
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[ランダム] Eastlake、D.、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RSALABS] Bleichenbacher, D., B. Kaliski, and J. Staddon. Recent
Results on PKCS #1: RSA Encryption Standard. RSA
Laboratories' Bulletin No. 7, June 26, 1998.
[http://www.rsasecurity.com/rsalabs/bulletins]
[SHA2] National Institute of Standards and Technology. Draft
FIPS Pub 180-2: "Specifications for the Secure Hash
Standard." May 2001.
[http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf]
[SSL] Freier, A., P. Karlton, and P. Kocher. The SSL
Protocol, Version 3.0. Netscape Communications.
November 1996.
[http://wp.netscape.com/eng/ssl3/draft302.txt]
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
CMS-RSAES-OAEP
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-rsaes-oaep(20) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS ALL --
-すべてエクスポート-
IMPORTS
AlgorithmIdentifier
FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) }
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
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}
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }
mgf1SHA1Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha1Identifier }
mgf1SHA256Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha256Identifier }
mgf1SHA384Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha384Identifier }
mgf1SHA512Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha512Identifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=
{ id-pSpecified, nullOctetString }
nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
id-sha1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26 }
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 }
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha1Identifier,
mgf1SHA1Identifier,
pSpecifiedEmptyIdentifier } }
rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha256Identifier,
mgf1SHA256Identifier,
pSpecifiedEmptyIdentifier } }
rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha384Identifier,
mgf1SHA384Identifier,
pSpecifiedEmptyIdentifier } }
rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha512Identifier, mgf1SHA512Identifier, pSpecifiedEmptyIdentifier } }
{sha512Identifier、mgf1SHA512Identifier、pSpecifiedEmptyIdentifier}}
END
終わり
Author's Address
著者のアドレス
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アメリカ
EMail: housley@vigilsec.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその継承者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。