Network Working Group P. Gutmann
Request for Comments: 3211 University of Auckland
Category: Standards Track December 2001
Password-based Encryption for CMS
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption.
このドキュメントは、拡張により、必ずしもアルゴリズム固有の固定フォーマットのキーではない可変長鍵材料の任意の形式をユーザが提供するパスワードを使用してデータを暗号化する方法を提供します。暗号メッセージ構文のデータ・フォーマットは、現在、パスワードベースのデータ暗号化のためのいずれかの条項が含まれていません。
This document describes a password-based content encryption mechanism for CMS. This is implemented as a new RecipientInfo type and is an extension to the RecipientInfo types currently defined in RFC 2630.
この文書では、CMSのパスワードベースのコンテンツの暗号化メカニズムを説明しています。これは、新しいのRecipientInfoタイプとして実装され、現在はRFC 2630で定義されているのRecipientInfoタイプの拡張機能です。
The format of the messages are described in ASN.1 [ASN1].
メッセージのフォーマットは、ASN.1 [ASN1]に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード「MUST」、「REQUIRED」、「べきではない」「べきである」、「推奨」「てはならない」、「MAY」、「OPTIONAL」は、RFC 2119で説明したように解釈されるべきです。
CMS currently defined three recipient information types for public-key key wrapping (KeyTransRecipientInfo), conventional key wrapping (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The recipient information described here adds a fourth type, PasswordRecipientInfo, which provides for password-based key wrapping.
CMSは現在、公開鍵の鍵ラッピング（KeyTransRecipientInfo）、従来のキーラッピング（KEKRecipientInfo）、およびキー合意（KeyAgreeRecipientInfo）のための3つの受信者情報の種類を定義しました。ここで説明した受信者の情報は、パスワードベースのキーラッピングを提供第4のタイプ、PasswordRecipientInfoを追加します。
The new recipient information type is an extension to the RecipientInfo type defined in section 6.2 of CMS, extending the types to:
新しい受信者情報タイプにタイプを拡張する、CMSのセクション6.2で定義されたのRecipientInfoタイプの拡張です。
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type
}
Although the recipient information generation process is described in terms of a password-based operation (since this will be its most common use), the transformation employed is a general-purpose key derivation one which allows any type of keying material to be converted into a key specific to a particular content-encryption algorithm. Since the most common use for password-based encryption is to encrypt files which are stored locally (rather than being transmitted across a network), the term "recipient" is somewhat misleading, but is used here because the other key transport mechanisms have always been described in similar terms.
受信者情報生成処理（これは最も一般的な用途であるので）、パスワードベースの動作に関して説明されるが、使用変換は、キーイング材料の任意のタイプに変換することを可能にする汎用の鍵導出一つであります特定のコンテンツの暗号化アルゴリズムの鍵と特定。パスワードベースの暗号化のための最も一般的な使用は、用語「受信者は」やや紛らわしいです（むしろ、ネットワークを介して送信されるより）ローカルに保存されたファイルを暗号化することであるが、他の主要なトランスポートメカニズムは常にされているので、ここで使用されているので、同様の観点から説明。
Recipient information using a user-supplied password or previously agreed-upon key is represented in the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo will transfer the content-encryption key (CEK) to one or more recipients who have the previously agreed-upon password or key-encryption key (KEK).
受信者のユーザーが入力したパスワードを使用して情報または以前に合意されたキーは、タイプPasswordRecipientInfoで表現されます。 PasswordRecipientInfoの各インスタンスは、以前に合意されているパスワードやキー暗号化キー（KEK）は、1つまたは複数の受信者に、コンテンツ暗号化キー（CEK）を転送します。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings:
タイプPasswordRecipientInfoのフィールドは以下の意味があります。
version is the syntax version number. It MUST be 0. Details of the CMSVersion type are discussed in CMS [RFC2630], section 10.2.5.
バージョンは構文バージョン番号です。これはCMSVersion型の0詳細はCMS [RFC2630]、セクション10.2.5で説明されていなければなりません。
keyDerivationAlgorithm identifies the key-derivation algorithm, and any associated parameters, used to derive the KEK from the user-supplied password. If this field is absent, the KEK is supplied from an external source, for example a crypto token such as a smart card.
keyDerivationAlgorithmは、キー導出アルゴリズムを識別し、ユーザが入力したパスワードからKEKを導出するために使用される任意の関連パラメータ、。このフィールドが存在しない場合、KEKは、スマートカードのような、例えば、外部ソースからの暗号トークンが供給されます。
keyEncryptionAlgorithm identifies the key-encryption algorithm, and any associated parameters, used to encrypt the CEK with the KEK.
keyEncryptionAlgorithmは、キー暗号化アルゴリズムを特定し、KEKを用いてCEKを暗号化するために使用される任意の関連パラメータ、。
encryptedKey is the result of encrypting the content-encryption key with the KEK.
EncryptedKeyにはKEKと、コンテンツ暗号化キーを暗号化した結果です。
Password-based key wrapping is a two-stage process, a first stage in which a user-supplied password is converted into a KEK if required, and a second stage in which the KEK is used to encrypt a CEK. These two stages are identified by the two algorithm identifiers. Although the PKCS #5v2 standard [RFC2898] goes one step further to wrap these up into a single algorithm identifier, this design is particular to that standard and may not be applicable for other key wrapping mechanisms. For this reason the two steps are specified separately.
パスワードベースのキーラッピングは、二段階プロセス、必要に応じてユーザが入力したパスワードは、KEKに変換する第一段階、及びKEKは、CEKを暗号化するために使用される第二段階です。これらの二つの段階は、二つのアルゴリズム識別子によって識別されます。 PKCS＃5V2標準[RFC2898]は、単一のアルゴリズム識別子にこれらを包むために一歩進むが、この設計は、標準に特定され、他の鍵ラッピングメカニズムに適用可能でないかもしれません。この理由のために2つのステップが個別に指定されています。
The current format doesn't provide any means of differentiating between multiple password recipient infos, which would occur for example if two passwords are used to encrypt the same data. Unfortunately there is a lack of existing practice in this area, since typical applications follow the model of encrypting data such as a file with a single password obtained from the user. Without any clear requirements, an appropriate multiple password mechanism would be difficult (perhaps impossible) to define at this time. If sufficient demand emerges then this may be addressed in a future version of this document, for example by adding an optional identification field of an appropriate form.
現在の形式は、二つのパスワードが同一のデータを暗号化するために使用される場合、例えば発生する複数のパスワードの受信者に関する情報、区別の任意の手段を提供しません。典型的なアプリケーションは、ユーザーから取得した単一のパスワードを使用してファイルなどのデータを暗号化するモデルに従うので、残念ながら、この分野における既存の慣行の欠如は、そこにあります。明確な要件がなければ、適切な複数のパスワードメカニズムは、この時点で定義するために（おそらく不可能）ことは困難であろう。十分な需要が出てくる場合、これは適切な形式の任意識別フィールドを追加することによって、例えば、この文書の将来のバージョンで対処することができます。
2 Supported Algorithms
2個のサポートされるアルゴリズム
This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included.
このセクションでは、実装しなければならないアルゴリズムを示します。実装されるべきさらなるアルゴリズムも含まれています。
These algorithms are used to convert the password into a KEK. The key derivation algorithms are:
これらのアルゴリズムは、KEKにパスワードを変換するために使用されています。キー導出アルゴリズムは以下のとおりです。
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B contains a more precise definition of the allowed algorithm type than is possible using 1988 ASN.1.
適合実装はPBKDF2 [RFC2898]を含まなければなりません。付録Bは、1988 ASN.1を使用して可能であるよりも、許可されたアルゴリズム型のより正確な定義が含まれています。
These algorithms are used to encrypt the CEK using the derived KEK. The key encryption algorithms are:
これらのアルゴリズムは、派生KEKを使用してCEKを暗号化するために使用されています。キー暗号化アルゴリズムは、以下のとおりです。
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
The PasswordRecipientInfo key encryption algorithm identifier is:
PasswordRecipientInfo鍵暗号化アルゴリズム識別子は以下のとおりです。
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
The AlgorithmIdentifier parameters field for this algorithm contains the KEK encryption algorithm used with the the key wrap algorithm specified in section 2.3.
このアルゴリズムのためのAlgorithmIdentifierパラメータ・フィールドは、セクション2.3で指定されたキーラップアルゴリズムで使用されるKEK暗号化アルゴリズムが含まれています。
There is no requirement that the CEK algorithm match the KEK encryption algorithm, although care should be taken to ensure that, if different algorithms are used, they offer an equivalent level of security (for example wrapping a Triple-DES key with an RC2/40 key leads to a severe impedance mismatch in encryption strength).
ケアは、それを確実にするために取られるべきであるが、異なるアルゴリズムが使用されている場合CEKアルゴリズムマッチKEK暗号化アルゴリズムは、彼らはRC2とトリプルDESのキーを包む（たとえば、セキュリティの同等レベルを提供する必要はありません/ 40キー）は、暗号化強度の深刻なインピーダンス不整合につながります。
Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap algorithm. For the KEK encryption algorithms used by id-alg-PWRI-KEK, conforming implementations MUST include Triple-DES in CBC mode and MAY include other algorithms such as AES, CAST-128, RC5, IDEA, Skipjack, Blowfish, and encryption modes as required. Implementations SHOULD NOT include any KSG (keystream generator) ciphers such as RC4 or a block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB mode.
準拠した実装は、ID-ALG-PWRI - KEKキーラップアルゴリズムを実装しなければなりません。 ID-ALG-PWRI - KEKによって使用されるKEK暗号化アルゴリズムのためのCBCモードでトリプルDESを含まなければならないし、そのようなAES、CAST-128、RC5、IDEA、カツオ、フグ、および暗号化モードなどのような他のアルゴリズムを含むかもしれ実装を従わ必須。実装は任意KSG（キーストリームジェネレータ）は、RC4またはOFBモードでブロック暗号などの暗号を含んではならない、とECBモードでブロック暗号を含むべきではありません。
The use of a level of indirection in specifying the KeyEncryptionAlgorithmIdentifier allows alternative wrapping algorithms to be used in the future. If the KEK algorithm were specified directly in this field then any use of an alternative wrapping algorithm would require a change to the PasswordRecipientInfo structure rather than simply a change to the key encryption algorithm identifier.
KeyEncryptionAlgorithmIdentifier指定に間接のレベルの使用は、別のラッピングアルゴリズムは、将来的に使用することが可能になります。 KEKアルゴリズムは、このフィールドに直接指定した場合は、代替ラッピングアルゴリズムのいずれかの使用はPasswordRecipientInfo構造への変更ではなく、単に鍵暗号化アルゴリズム識別子への変更が必要となります。
The parameter field for this algorithm identifier could be specified to default to triple-DES, however due to the confusion over NULL vs absent parameters in algorithm identifiers it's left explicit with no default value.
このアルゴリズム識別子のためのパラメータフィールドは、しかし、原因、それがデフォルト値を持たない明示的な左のアルゴリズム識別子には存在しないパラメータ対NULLの混乱に、トリプルDESをデフォルトに指定することができます。
The key wrap algorithm encrypts a CEK with a KEK in a manner which ensures that every bit of plaintext effects every bit of ciphertext. This makes it equivalent in function to the package transform [PACKAGE] without requiring additional mechanisms or resources such as hash functions or cryptographically strong random numbers. The key wrap algorithm is performed in two phases, a first phase which formats the CEK into a form suitable for encryption by the KEK, and a second phase which wraps the formatted CEK using the KEK.
キーラップアルゴリズムは、暗号文の平文効果のすべてのビットは、すべてのビットことを保証した方法でKEKとCEKを暗号化します。これは、ハッシュ関数または暗号的に強い乱数のような追加の機構またはリソースを必要とすることなく、[PACKAGE]を変換パッケージと機能的に、それは同等となります。キーラップアルゴリズムは、2つのフェーズ、KEKによって暗号化するのに適した形にCEKをフォーマットする最初の段階、及びKEKを使用してフォーマットされたCEKを包む第2段階で行われます。
Key formatting: Create a formatted CEK block consisting of the following:
キーフォーマット：以下からなるフォーマットされたCEKブロックを作成します。
2. A check value containing the bitwise complement of the first three bytes of the CEK.
CEKの最初の3バイトのビット単位の補数を含む2チェック値。
4. Enough random padding data to make the CEK data block a multiple of the KEK block length and at least two KEK cipher blocks long (the fact that 32 bits of count+check value are used means that even with a 40-bit CEK, the resulting data size will always be at least two (64-bit) cipher blocks long). The padding data does not have to be cryptographically strong, although unpredictability helps. Note that PKCS #5 padding is not used, since the length of the data is already known.
十分CEKデータを作るためにランダムなパディングデータは、KEKのブロック長の倍数をブロックし、少なくとも二つのKEK暗号ブロック長（カウント+検査値の32ビットが使用されるという事実があっても40ビットCEKであることを意味4。結果のデータサイズは常に）は、少なくとも2つ（64ビット）暗号ブロック長くなります。予測不可能性が役立ちますが、パディングデータは、暗号用に強化している必要はありません。データの長さが既知であるので、PKCS＃5パディングが、使用されないことに留意されたいです。
The formatted CEK block then looks as follows:
次のようにフォーマットされたCEKブロックはその後になります。
CEK byte count || check value || CEK || padding (if required)
CEKバイト数||値をチェック|| CEK ||パディング（必要な場合）
Key wrapping:
主なラッピング：
2. Without resetting the IV (that is, using the last ciphertext block as the IV), encrypt the encrypted padded key a second time.
IVをリセットせずに2、暗号化されたパッド入りのキーをもう一度暗号化する（そのIVとして最後の暗号文ブロックを使用して、あります）。
The resulting double-encrypted data is the EncryptedKey.
得られた二暗号化されたデータは、EncryptedKeyにあります。
Key unwrapping:
キーアンラップ：
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th ciphertext block.
1. IVように、n-1番目の暗号文ブロックを用いて、n番目の暗号文ブロックを復号化します。
2. Using the decrypted n'th ciphertext block as the IV, decrypt the 1st ... n-1'th ciphertext blocks. This strips the outer layer of encryption.
2. IVとして復号化されたn番目の暗号文ブロックを使用して、第一...のn-1番目の暗号文ブロックを復号化します。これは、暗号化の外側の層を取り除きます。
Key format verification:
キーの形式検証：
1a. If the CEK byte count is less than the minimum allowed key size (usually 5 bytes for 40-bit keys) or greater than the wrapped CEK length or not valid for the CEK algorithm (eg not 16 or 24 bytes for triple DES), the KEK was invalid.
図1a。 CEKのバイト数は、CEKアルゴリズム（トリプルDES用などない16または24バイト）のキーのサイズ（40ビットキーのために通常は5バイト）やラップCEKの長さよりも大きいか有効でない許容される最小よりも小さい場合は、 KEKが無効でした。
1b. If the bitwise complement of the key check value doesn't match the first three bytes of the key, the KEK was invalid.
図1b。キーチェック値のビットごとの補数は、キーの最初の3バイトと一致しない場合は、KEKが無効でした。
Given a content-encryption algorithm of Skipjack and a KEK algorithm of Triple-DES, the wrap steps are as follows:
次のようにカツオのコンテンツ暗号化アルゴリズムおよびトリプルDESのKEKアルゴリズムを考えると、ラップ手順は次のとおりです。
1. Set the first 4 bytes of the CEK block to the Skipjack key size (10 bytes) and the bitwise complement of the first three bytes of the CEK.
1.カツオ鍵サイズ（10バイト）と、CEKの最初の3バイトのビット単位の補数にCEKブロックの最初の4つのバイトを設定します。
2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16 bytes (two triple-DES blocks) using 2 bytes of random data.
2.ランダムデータの2つのバイトを使用して16バイト（二トリプルDESブロック）に80ビット（10バイト）カツオCEKとパッド合計を追加します。
2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, encrypted the padded Skipjack key.
2. KeyEncryptionAlgorithmIdentiferで与えられたIVを使用して、パッド入りのカツオのキーを暗号化。
3. Without resetting the IV, encrypt the encrypted padded key a second time.
3. IVをリセットせずに、暗号化されたパッド入りのキーをもう一度暗号化します。
The unwrap steps are as follows:
次のようにアンラップ手順は次のとおりです。
1. Using the first 8 bytes of the double-encrypted key as the IV, decrypt the second 8 bytes.
1. IVとして二重暗号化キーの最初の8つのバイトを使用し、2番目の8つのバイトを復号化します。
3. Decrypt the inner layer of encryption using the the IV given in the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack key.
3.パッド入りのカツオキーを回復するためにKeyEncryptionAlgorithmIdentiferで与えられたIVを使用して暗号化の内層を復号化。
4. If the length byte isn't equal to the Skipjack key size (80 bits or 10 bytes) or the bitwise complement of the check bytes doesn't match the first three bytes of the CEK, the KEK was invalid.
4.長さバイトはカツオキーサイズ（80ビット又は10バイト）に等しくないか、チェックバイトのビットごとの補数がCEKの最初の3バイトに一致しない場合は、KEKが無効でした。
If many CEKs are encrypted in a standard way with the same KEK and the KEK has a 64-bit block size then after about 2^32 encryptions there is a high probability of a collision between different blocks of encrypted CEKs. If an opponent manages to obtain a CEK, they may be able to solve for other CEKs. The double-encryption wrapping process, which makes every bit of ciphertext dependent on every bit of the CEK, eliminates this collision problem (as well as preventing other potential problems such as bit-flipping attacks). Since the IV is applied to the inner layer of encryption, even wrapping the same CEK with the same KEK will result in a completely different wrapped key each time.
多くたCEKが同じKEKとKEKと標準的な方法で暗号化されている場合、64ビットのブロックサイズは、約2 ^ 32暗号化した後、暗号化されたCEKの異なるブロック間の衝突の可能性が高いしています。相手がCEKを取得するために管理している場合、彼らは他たCEKのために解決することができるかもしれません。 CEKのすべてのビットの暗号文のすべてのビットが依存させる二重暗号化ラッピングプロセスは、この衝突問題（ならびにビットフリップ攻撃など、他の潜在的な問題を防止すること）を排除します。 IVは、暗号化の内側の層に適用されているので、も全く異なる包まキーたびになり同じKEKと同一のCEKを包みます。
An additional feature of the double wrapping is that it doesn't require the use of any extra algorithms such as hash algorithms in addition to the wrapping algorithm itself, allowing it to be implemented in devices which only support one type of encryption algorithm. A typical example of such a device is a crypto token such as a smart card which often only supports a single block cipher and a single public-key algorithm, making it impossible to wrap keys if the use of an additional algorithm were required.
ダブルラッピングのさらなる特徴は、それが唯一の暗号化アルゴリズムのいずれかのタイプをサポートするデバイスに実装することができるように、ラッピングアルゴリズム自体に加えて、このようなハッシュアルゴリズムとして余分なアルゴリズムの使用を必要としないことです。このようなデバイスの典型的な例は、このような多くの場合にのみ、追加のアルゴリズムを使用することが要求された場合、それは不可能キーをラップすること、単一のブロック暗号と単一の公開鍵アルゴリズムをサポートし、スマートカードのような暗号トークンです。
This section contains two sets of test vectors, a very basic set for DES which can be used to verify correctness and which uses an algorithm which is freely exportable from the US, and a stress-test version which uses very long passphrase and key sizes and a mixture of algorithms which can be used to verify the behaviour in extreme cases.
このセクションでは、テストベクトルの二組、正しさを検証するために使用することができますDESのための非常に基本的なセットが含まれており、これは米国から自由にエクスポートされたアルゴリズムを使用し、非常に長いパスフレーズと鍵のサイズを使用してストレステストバージョンと極端な場合には動作を確認するために使用することができるアルゴリズムの混合物。
The basic test contains two subtests, a known-answer test for the key derivation stage and a full test of the key wrapping. Both tests use a DES-CBC key derived from the password "password" with salt { 12 34 56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known answer test the IV is set to all zeroes (equivalent to using ECB) and used to encrypt an all-zero data block.
基本的なテストは2つのサブテスト、鍵導出段階のための既知解テストとキーラップの完全なテストが含まれています。両試験はPBKDF2の5回の反復を用いて塩{12 34 56 78 78 56 34 12}とパスワード "パスワード" に由来DES-CBCキーを使用します。既知の答え試験でIVは（ECBを使用することと等価）全てゼロに設定され、すべてゼロデータブロックを暗号化するために使用されます。
The following values are obtained for the known-answer test:
以下の値が既知解テストのために得られます。
PKCS #5v2 values:
PKCS＃の5V2値：
input 70 61 73 73 77 6f 72 64 passphrase: "password" input salt: 12 34 56 78 78 56 34 12 iterations: 5
入力70 61 73 73 77 72 64 6Fパスフレーズ： "パスワード" 入力塩：12 34 56 78 78 56 34 12回の反復：5
output key: D1 DA A7 86 15 F2 87 E6 known answer: 9B BD 78 FC 11 A3 A9 08
出力キー：D1 DA A7 86 15 F2 87 E6既知の答え：9B BD 78 FC 11 A3 A9 08
The following values are obtained when wrapping a 64-bit (parity-adjusted) DES-EBC key:
64ビット（パリティ調整）DES-EBC鍵をラップするとき、以下の値が得られます。
PKCS #5v2 values:
PKCS＃の5V2値：
input 70 61 73 73 77 6f 72 64 passphrase: "password" input salt: 12 34 56 78 78 56 34 12 iterations: 5
入力70 61 73 73 77 72 64 6Fパスフレーズ： "パスワード" 入力塩：12 34 56 78 78 56 34 12回の反復：5
output key: D1 DA A7 86 15 F2 87 E6
出力キー：D1 DA A7 86 15 F2 87 E6
CEK formatting phase:
CEKフォーマット相：
length byte: 08 key check: 73 9D 83 CEK: 8C 62 7C 89 73 23 A2 F8 padding: C4 36 F5 41
長さバイト：08キーチェック：73 9D 83 CEK：8C 62 7C 89 73 23 A2 F8パディング：C4 36 F5 41
complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 CEK block:
62 7C 89 73 23 A2 F8 C4 36 F5 08 73 9D 83（c）完全な41 CEKブロック：
Key wrap phase (wrap CEK block using DES key):
（DESのキーを使用してラップCEKブロック）キーラップ相：
IV: EF E5 98 EF 21 B3 3D 6D
IV：EF E5 98 EF 21 B3 3D 6D
first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4 pass output: second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 pass output:
最初ENCR。 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76の10 00 D4パス出力：ENCR秒。 B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17の8B 0C 10パス出力：
ASN.1 encoded PasswordRecipientInfo:
ASN.1はPasswordRecipientInfoをエンコード：
0 A3 68: [3] { 2 02 1: INTEGER 0 5 A0 26: [0] { 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 18 30 13: SEQUENCE { 20 04 8: OCTET STRING : 12 34 56 78 78 56 34 12 30 02 1: INTEGER 5 : } : } 34 30 32: SEQUENCE { 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK : (1 2 840 113549 1 9 16 3 9) 33 30 17: SEQUENCE { 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) 42 04 8: OCTET STRING : EF E5 98 EF 21 B3 3D 6D : } : } 68 04 16: OCTET STRING : B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 : }
0 A3 68：[3] {2 02 1：INTEGER 0~5 A0 26：[0] {7 06 9：オブジェクトの識別子ID-PBKDF2（1 2 840 113549 1 5 12）18 30 13：SEQUENCE {20 04 8：オクテットSTRING：12 34 56 78 78 56 34 12 30 02 1：INTEGER 5：}} 34 30 32：SEQUENCE {36 06 11：オブジェクト識別子ID-ALG-PWRI - KEK：（1 2 840 113549 1 9 16 3 9）33 30 17：SEQUENCE {35 06 5：オブジェクト識別子DES-CBC（1 3 14 3 2 7）42 04 8：オクテットSTRING：EF E5 98 EF 21 B3 3D 6D：}} 68 04 16：OCTET STRING ：B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10：}
The following values are obtained when wrapping a 256-bit key (for example one for AES or Blowfish) using a triple DES-CBC key derived from the passphrase "All n-entities must communicate with other n-entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12 } using 500 iterations of PBKDF2.
パスフレーズに由来トリプルDES-CBCの鍵を使用して（AESまたはフグのために一例用）256ビットの鍵をラップするとき、以下の値が得られ、「全てのN-エンティティは、n-1 entiteeheeheesを介して他のN-エンティティと通信しなければなりません」 PBKDF2の500回の反復を用いて塩{12 34 56 78 78 56 34 12}を有します。
PKCS #5v2 values:
PKCS＃の5V2値：
input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 74 69 74 65 65 68 65 65 68 65 65 73 "All n-entities must communicate with other " "n-entities via n-1 entiteeheehees" input salt: 12 34 56 78 78 56 34 12 iterations: 500
入力41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6Dパスフレーズ：75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 77 69 74 68 20 6F 74 68 65 72 20 6E 2D 65 6E N-1 entiteeheehees "入力を介して" N-エンティティ "全てNエンティティが相互に通信しなければならない" 74 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 74 69 74 65 65 68 65 65 68 65 65 73塩：12 34 56 78 78 56 34 12回の反復：500
output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 3DES key: 07 12 63 80 CC 47 AB 2D
キー出力6A 89の70 BF 68のC9 2C AE A8 4A 8D F2 85の10 85 86 3DES：07 12 63 80 47 CC AB 2D
CEK formatting phase:
CEKフォーマット相：
length byte: 20 key check: 73 9C 82 CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B padding: FA 06 0A 45
長さバイト：20キーチェック：73 9C 82 CEK：8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3Bパディング：FA 06 0A 45
complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B FA 06 0A 45
Smbelt 2073器具は司祭のTa Z右葉TKH行為の光を制限IのIbb SCブロック潮吹き以下：01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B FA 06 0A 45
Key wrap phase (wrap CEK block using 3DES key):
キーラップ相（3DESキーを使用してラップCEKブロック）：
IV: BA F1 CA 79 31 21 3C 4E
IV：F1 CA 79 31 21 3C 4E
first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 96 9E 65 27 9E 12 6A EB
最初ENCR。 F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CDパス出力：27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 96 9E 65 27 9E 12 6A EB
second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 EC 74 E6 CA D7 DB 26 0C
二ENCR。 C0 3C 51 4A BD B9 E2 C5 AA C0 38の57 5E 2B 24 55パス出力：38 76 77 B3 AA FB 82 EC A5 A9 D7 3F 8AのB1 43 D9 EC 74 E6 CA D7 DB 26 0C
ASN.1 encoded PasswordRecipientInfo:
ASN.1はPasswordRecipientInfoをエンコード：
0 A3 96: [3] { 2 02 1: INTEGER 0 5 A0 27: [0] { 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 18 30 14: SEQUENCE { 20 04 8: OCTET STRING : 12 34 56 78 78 56 34 12 30 02 2: INTEGER 500 : } : } 34 30 35: SEQUENCE { 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK : (1 2 840 113549 1 9 16 3 9) 34 30 20: SEQUENCE { 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) 46 04 8: OCTET STRING : BA F1 CA 79 31 21 3C 4E : } : } 71 04 40: OCTET STRING : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 : EC 74 E6 CA D7 DB 26 0C : }
0 A3 96：[3] {2 02 1：INTEGER 0~5 A0 27：[0] {7 06 9：オブジェクトの識別子ID-PBKDF2（1 2 840 113549 1 5 12）18 30 14：SEQUENCE {20 04 8：オクテットSTRING：12 34 56 78 78 56 34 12 30 02 2：INTEGER 500：}} 34 30 35：SEQUENCE {36 06 11：オブジェクト識別子ID-ALG-PWRI - KEK：（1 2 840 113549 1 9 16 3 9）34 30 20：SEQUENCE {36 06 8：オブジェクト識別子DES-EDE3-CBC（1 2 840 113549 3 7）46 04 8：オクテットSTRING：BA F1 CA 79 31 21 3C 4E：}} 71 04 40：オクテットSTRING：C0 3C 51 4A BD B9 E2 C5 AA C0 38 57（b）（e）24 55 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8aはB1 43 D9：EC 74 E6 CA D7 DB 26 0C：}
The security of this recipient information type rests on the security of the underlying mechanisms employed, for which further information can be found in RFC 2630 and PKCS5v2. More importantly, however, when used with a password the security of this information type rests on the entropy of the user-selected password, which is typically quite low. Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, although it should be recognized that even with pass phrases it will be difficult to use this recipient information type to derive a KEK with sufficient entropy to properly protect a 128-bit (or higher) CEK.
この受信者情報タイプのセキュリティは、さらに情報がRFC 2630とPKCS5v2に見出すことができるために用いる基礎となるメカニズムのセキュリティ上に載っています。パスワードで使用される場合、より重要なことに、しかし、この情報タイプのセキュリティは、典型的には、非常に低いユーザ選択パスワードのエントロピー上に載っています。それにもパスフレーズと、適切に128ビットを保護するのに十分なエントロピーとKEKを導出するために、この受信者情報のタイプを使用することが困難になることを認識すべきであるが、強く推奨される（単純なパスワードとは対照的に）パスフレーズ（またはそれ以上）CEK。
The PasswordRecipientInfo key encryption algorithms are identified by object identifiers (OIDs). OIDs were assigned from an arc contributed to the S/MIME Working Group by the RSA Security. Should additional encryption algorithms be introduced, the advocates for such algorithms are expected to assign the necessary OIDs from their own arcs. No action by the IANA is necessary for this document or any anticipated updates.
PasswordRecipientInfo鍵暗号化アルゴリズムはオブジェクト識別子（OID）によって識別されます。 OIDは、アークから割り当てられたRSA SecurityがS / MIME作業部会に貢献しました。追加の暗号化アルゴリズムを導入しなければならない、そのようなアルゴリズムのための支持者は、独自のアークから必要なOIDを割り当てることが期待されています。 IANAによってアクションは、この文書または任意の予想されるアップデートの必要はありません。
Acknowledgments
謝辞
The author would like to thank Jim Schaad, Phil Griffin, and the members of the S/MIME Working Group for their comments and feedback on this document.
作者はこのドキュメントの彼らのコメントやフィードバックのためにジムSchaad、フィル・グリフィン、およびS / MIME作業部会のメンバーに感謝したいと思います。
Author Address
著者の住所
Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand
オークランドプライベートバッグのピーター・ガットマン大学92019オークランド、ニュージーランド
EMail: pgut001@cs.auckland.ac.nz
メールアドレス：pgut001@cs.auckland.ac.nz
References
リファレンス
[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1] CCITT勧告X.208：抽象構文記法1（ASN.1）、1988の仕様。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification, Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B.、 "PKCS＃5：パスワードベースの暗号化仕様バージョン2.0"、RFC 2898、2000年9月。
[PACKAGE] All-or-Nothing Encryption and the Package Transform, R. Rivest, Proceedings of Fast Software Encryption '97, Haifa, Israel, January 1997.
[PACKAGE]オール・オア・ナッシングの暗号化とパッケージ変換、R. Rivest氏、高速ソフトウェア暗号化'97の議事録、ハイファ、イスラエル、1997年1月。
Appendix A: ASN.1:1988 Module
付録A：ASN.1：1988モジュール
PasswordRecipientInfo-88 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) pwri(17) }
PasswordRecipientInfo-88 {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）土木研究所（17）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
AlgorithmIdentifier FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }
AuthenticationFramework FROMのAlgorithmIdentifier {関節イソITU-T DS（5）モジュール（1）authenticationFramework（7）3}
CMSVersion, EncryptedKey FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };
CMSVersion、EncryptedKeyに暗号メッセージ構文FROM {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）CMS（1）}。
-- The following PDU is defined in PKCS5 { iso(1) member-body(2) -- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16) -- pkcs5v2-0(1) }, however it can't be imported because because -- it's specified in 1994/1997 ASN.1. Because of this it's copied -- here from the source but rephrased as 1988 ASN.1. Further -- details are given in [RFC 2898].
- 米国（840）RSADSI（113549）PKCS（1）PKCS-5（5）モジュール（16） - - pkcs5v2-0（以下PDUはPKCS5 {ISO（1）部材本体（2）に定義されていますそれは1997分の1994 ASN.1で指定されています - ので、1）}、しかし、それはなぜならインポートすることができません。ソースからここが、1988 ASN.1と言い換える - このため、それがコピーされます。さらに - 詳細は、[RFC 2898]に記載されています。
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
-- The PRF algorithm is also defined in PKCS5 and can neither be -- imported nor expressed in 1988 ASN.1, however it is encoded as -- an AlgorithmIdentifier with the OID:
しかしながら、それはとしてエンコードされ、インポートされたことも、1988 ASN.1で発現 - - - PRFアルゴリズムはまた、PKCS5で定義されていることができ、どちらもOIDとのAlgorithmIdentifier。
id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 7 }
-- and NULL parameters. Further details are given in [RFC 2898].
- とNULLパラメータ。さらなる詳細は、[RFC 2898]に記載されています。
-- Implementation note: Because of the inability to precisely -- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is -- likely that implementors will also encounter alternative -- interpretations of these parameters, usually using an alternate -- OID from the IPsec arc which is generally used for HMAC-SHA1:
- 実装上の注意：正確にすることができないのなので - 1988 ASN.1でPBKDF2 PDUまたはそのパラメータを指定し、それがある - 実装者が、代替に遭遇する可能性が高いことを - 通常の代替を使用して、これらのパラメータの解釈 - 一般にHMAC-SHA1のために使用されるIPsecのアークからOID：
--
-- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
-- identified-organization(3) dod(6) internet(1) security(5)
-- mechanisms(5) 8 1 2 }
--
-- with absent (rather than NULL) parameters.
-- The PasswordRecipientInfo
- PasswordRecipientInfo
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
END -- PasswordRecipientInfo-88 --
END - PasswordRecipientInfo - 88 -
Appendix B: ASN.1:1997 Module
付録B：ASN.1：1997モジュール
This appendix contains the same information as Appendix A in a more recent (and precise) ASN.1 notation, however Appendix A takes precedence in case of conflict.
この付録では、より最近の（かつ正確な）ASN.1表記の付録Aと同じ情報が含まれている、しかし、付録Aは、競合の場合に優先されます。
PasswordRecipientInfo-97 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) pwri(18) }
PasswordRecipientInfo-97 {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）土木研究所（18）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
id-PBKDF2, PBKDF2-params, FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) }
PKCS5からID-PBKDF2、PBKDF2-paramsは、{ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-5（5）}
CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };
CMSVersion、EncryptedKeyに、DES-EDE3-CBC、暗号メッセージ構文FROM CBCParameter {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0） CMS（1）}。
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyDerivationAlgorithms }}
KeyDerivationAlgorithms ALGORITHM ::= {
{ OID id-PBKDF2 PARMS PBKDF2-params },
...
}
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyEncryptionAlgorithms }}
KeyEncryptionAlgorithms ALGORITHM ::= {
{ OID id-alg-PWRI-KEK PARMS
AlgorithmIdentifier {{ PWRIAlgorithms }} },
...
}
-- Algorithm identifiers for algorithms used with the -- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a -- MUST, all others are optional
- ID-ALG-PWRI - KEKキーラップアルゴリズム - で使用されるアルゴリズムのためのアルゴリズム識別子。現在、唯一の3DESがある - MUSTは、他のすべてはオプションです
PWRIAlgorithms ALGORITHM ::= {
{ OID des-ede3-cbc PARMS CBCParameter },
...
}
-- Supporting definitions. We could also pull in the -- AlgorithmIdentifier from an appropriately recent X.500 module (or -- wherever) but it's just as easy (and more convenient for readers) -- to provide a definition here
- 定義をサポートします。適切最近のX.500モジュールからのAlgorithmIdentifier（または - - どこ）が、それは同じように簡単（と読者にとってより便利）だ - 我々はまた、中に引くことができ、ここで定義を提供するために、
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL } WITH SYNTAX { OID &id [PARMS &Type] }
構文で＆タイプOPTIONAL} {OID＆ID [PARMS＆タイプ]}
END -- PasswordRecipientInfo-97 --
END - PasswordRecipientInfo - 97 -
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。