Network Working Group S. Farrell
Request for Comments: 3185 Baltimore Technologies
Category: Standards Track S. Turner
IECA
October 2001
Reuse of CMS Content Encryption Keys
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 describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets.
この文書は、データパケットを包囲するためのコンテンツ暗号化鍵を再使用することができるように、データ構造をエンベロープCMS（暗号メッセージ構文）にキー識別子を含める方法を記載しています。
Table Of Contents
目次
1. Introduction................................................... 2
2. Applicability.................................................. 2
3. How to do it................................................... 3
4. Using different CEK and KEK algorithms......................... 4
5. Conformance.................................................... 5
6. Security Considerations........................................ 5
7. References..................................................... 6
Authors' Addresses................................................ 6
Appendix A: ASN.1 Module.......................................... 7
Full Copyright Statement.......................................... 10
CMS [CMS] specifies EnvelopedData. EnvelopedData supports data encryption using either symmetric or asymmetric key management techniques. Since asymmetric key establishment is relatively expensive, it is desirable in some environments to re-use a shared content-encryption key established using asymmetric mechanisms for encryption operations in subsequent messages.
CMS [CMS]はEnvelopedDataのを指定します。 EnvelopedDataのは、対称または非対称鍵管理手法のいずれかを使用してデータの暗号化をサポートしています。非対称鍵確立は比較的高価であるため、いくつかの環境では、後続のメッセージに暗号化動作のための非対称の機構を使用して確立された共有されたコンテンツ暗号化キーを再利用するには望ましいです。
The basic idea here is to reuse the content-encryption key (CEK) from a message (say MSG1) to derive the key-encryption key (KEK) for a later message, (MSG2), by including a reference value for the CEK in message 1, and that same value as the KEKIdentifier for message 2. The CEK from message 1 is called the "referenced CEK".
ここでの基本的な考え方はでCEKの基準値を含むことによって、後でメッセージ（MSG2）のキー暗号化キー（KEK）を導出するためのメッセージ（MSG1と言う）からコンテンツ暗号化キー（CEK）を再利用することですメッセージ1、メッセージ1からメッセージ2 CEKためKEKIdentifierとして同じ値が「参照CEK」と呼ばれています。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「必須」、「推奨」、「SHOULD」とは、本書では[RFC2119]で説明されるように解釈される「場合があります」。
This specification is intended to be used to provide more efficient selective field confidentiality between communicating peers, in particular in the cases where:
この仕様は、場合には、特に、通信ピア間でより効率的な選択フィールド機密性を提供するために使用されることを意図しています。
- The originator is a client that wishes to send a number of fields to a server (the recipient) in a single transaction, where the referenced CEK is used for the separate encryption of each field.
- 発信者は、参照CEKは、各フィールドの別々の暗号化に使用される単一のトランザクションにサーバ（受信者）にフィールドの数を送信することを希望するクライアントです。
- The originator and recipient are servers that communicate very frequently and use this specification purely for efficiency.
- 創始者と受信者は非常に頻繁に通信し、効率化のために純粋にこの仕様を使用するサーバです。
This specification is not intended to be applicable in all cases. It is suited for use where:
この仕様は、すべての場合に適用できることを意図したものではありません。これは、使用場所に適しています：
- Its use is further scoped: that is, this specification doesn't define a protocol but merely a trick that can be used in a larger context and additional specification will be needed for each such case. In particular, in order to use this specification, it is REQUIRED to define the originators' and recipients' behavior where a referenced CEK has been "lost".
- その使用はさらにスコープれる：つまり、この仕様は、プロトコルが定義されていないが、単に、より大きなコンテキストおよび追加明細書中で使用することができるトリックは、それぞれ、このような場合に必要とされるであろう。具体的には、この仕様を利用するためには、参照CEKは 『失われた』されていますオリジネーターと受信者の振る舞いを定義するために必要とされます。
- This specification is not suitable for general group key management.
- この仕様は、一般的なグループ鍵管理には適していません。
- The underlying cryptographic API is suitable: it is very likely that any cryptographic API that completely "hides" the bits of cryptographic keys from the CMS layer will prevent reuse of a referenced CEK (since they won't have a primitive that allows MSG1.CEK to be transformed to MSG2.KEK).
- 基本的な暗号化APIが適している：彼らがMSG1を可能にするプリミティブを持っていないので、完全に「隠す」いずれかの暗号化APIは、CMS層からの暗号鍵のビットが（参照CEKの再利用を防ぐことができます可能性が非常に高いです。 MSG2.KEKに変換するためのCEK）。
- The algorithms for content and key encryption have compatible key values and strengths, that is, if MSG1.contentEncryptionAlgorithm is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 bits of keying material, then this specification SHOULD NOT be used.
- コンテンツと鍵の暗号化のためのアルゴリズムはMSG1.contentEncryptionAlgorithmが40bitの暗号であり、MSG2.keyEncryptionAlgorithmが材料を合わせるの168ビットを必要とする場合、この仕様を使用すべきでない、つまり、互換性のあるキー値および強度を有します。
There are other ways that could be envisaged to establish the required symmetric keying material, e.g., by leveraging a group keying scheme or by defining a content type that contains a KEK value. Although this scheme is much simpler than generic group key management, if an implementation already supports group key management then this scheme doesn't add value. This scheme is also suitable for inclusion in CMS libraries (though the addition of new state might be a problem for some implementations), which can offer some advantages over application layer schemes (e.g., where the content includes MSG2.KEK).
スキームキーインググループを活用することによって、またはKEK値を含むコンテンツタイプを定義することによって、例えば、必要な対称鍵材料を確立するために想定され得る他の方法があります。この方式は、一般的なグループ鍵管理よりもはるかに簡単ですが、実装は、すでにグループ鍵管理をサポートしている場合は、この方式では、値を追加しません。 （コンテンツMSG2.KEKを含ん例えば、）アプリケーション層スキーム上いくつかの利点を提供することができ、（新しい状態の添加は、いくつかのインプリメンテーションにとって問題であるかもしれないが）この方式は、CMSライブラリに含めるのに適しています。
In order to reference the content-encryption key (CEK) used in an EnvelopedData, a key identifier can be included in the unprotectedAttrs field of MSG1. This key can then be used to derive the key-encryption key (KEK) for other instances of EnvelopedData or for other purposes. If the CEK from MSG1 is to be used to derive the KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute of type id-aa-CEKReference with a single value using the CEKReference syntax.
EnvelopedDataで使用されるコンテンツ暗号鍵（CEK）を参照するために、キー識別子は、MSG1のunprotectedAttrsフィールドに含めることができます。このキーは、その後のEnvelopedDataの他のインスタンスのためまたは他の目的のためのキー暗号化キー（KEK）を導出するために使用することができます。 MSG1からCEKがMSG2ためのKEKを導出するために使用される場合、MSG1はCEKReference構文を使用して単一の値を持つタイプID-AA-CEKReferenceのunprotectedAttrs属性を含まなければなりません。
MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK. The byte reversal is to avoid an attack where the attacker has a known plaintext and the related ciphertext (encrypted with MSG1.CEK) that (otherwise) could be directly used as a MSG2.KEK.
MSG2.KEKはMSG1.CEKのバイトを逆にすることによって導出されます。バイト反転は、攻撃者が（それ以外）直接MSG2.KEKとして使用することができることが知られて平文と（MSG1.CEKで暗号化された）関連する暗号文を持って攻撃を回避することです。
The application MUST ensure that the relevant algorithms are compatible. That is, a CEKReference attribute alone can only be used where the content-encryption algorithm from MSG1 employs the same type of symmetric key as the key-encryption algorithm from MSG2.
アプリケーションは、関連するアルゴリズムが互換性があることを確認しなければなりません。 MSG1からコンテンツ暗号化アルゴリズムがMSG2からキー暗号化アルゴリズムなどの対称鍵の同じタイプを使用ところは、単独でCEKReference属性にのみ使用することができるされています。
Notes:
ノート：
1) There is nothing to prevent inclusion of a CEKReference attribute in MSG2 as well as in MSG1. That is, an originator could "roll" the referenced CEK with every message.
1）MSG2ならびにMSG1でCEKReference属性の混入を防止するためには何もありません。これは、発信者は「ロール」すべてのメッセージでCEKを参照することができ、あります。
2) The CEKReference attribute can occur with any of the choices for RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume that CEKReference can only occur where ktri or kari is used.
ktri、がkari又はkekri：2）CEKReference属性は、のRecipientInfoの選択肢のいずれかで起こり得ます。実装者はktriかがkariが使用されているところCEKReferenceにのみ発生する可能性があることを仮定してはいけません。
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
id-aa is an object identifier defined in [CMS-MSG].
ID-AAは[CMS-MSG]で定義されたオブジェクト識別子です。
In order to allow the originator of MSG1 to indicate the "lifetime" of the CEK, the originator MAY include a CEKMaxDecrypts attribute, also in the unprotectedAttrs field of EnvelopedData. This attribute has an INTEGER syntax (the value MUST be >=1 and maximally 2^31), and indicates to the recipient the maximum number of messages (excluding MSG1) that will use the referenced CEK. This Attribute MUST only be sent when a CEKReference attribute is also included.
MSG1の発信元がCEKの「寿命」を示すことを可能にするために、発信元ものEnvelopedDataのunprotectedAttrsフィールドに、CEKMaxDecrypts属性を含むかもしれません。この属性は、整数の構文を有する（値は> = 1、最大2 ^ 31でなければなりません）、および受信者を基準CEKを使用する（MSG1を除く）メッセージの最大数を示しています。 CEKReference属性も含まれている場合は、この属性にのみ送らなければなりません。
The recipient SHOULD maintain the CEKReference information (minimally the key identifier and the CEK value) while less than maxDecrypt messages have been successfully received. Recipients SHOULD delete the CEKReference information after some locally configured period.
受信者は、より少ないmaxDecryptメッセージが正常に受信されているがCEKReference情報（最小キー識別子とCEK値）を維持すべきです。受信者は、いくつかのローカルに設定された期間の後CEKReference情報を削除する必要があります。
When this attribute is not present, originators and recipients SHOULD behave as if a value of one had been sent.
この属性が存在しない場合は、創始者と受信者は、1の値が送られていたかのように振る舞うべきです。
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
If CEKMaxDecrypts is missing, or has the value one, then each CEK will be re-used once as the KEK for the next message. This means that MSG[n].KEK is the byte-reversal of MSG[n-1].CEK; subsequently MSG[n+1].KEK will be the byte-reversal of MSG[n].CEK. Note that MSG[n-1].CEK has no impact whatsoever to MSG[n+1], so long as CEKs are generated randomly (and not e.g., derived from KEKs somehow).
CEKMaxDecryptsが欠落、または値1を有する場合、各CEKは、次のメッセージをKEKとして一度再利用されるであろう。これは、MSG [n]は.KEKはMSG [N-1] .CEKのバイト反転であることを意味します。その後MSG [N + 1] .KEK [n]は.CEK MSGのバイト反転あろう。限りたCEKが（何らかの形のKEKに由来する、例えばなく）ランダムに生成されるように、MSG [N-1] .CEKはMSG [N + 1]に何ら影響を与えないことに留意されたいです。
Where MSG1.content-encryption algorithm and MSG2.key-encryption algorithm are the same then the MSG2.KEK is the byte-reverse of MSG1.CEK. However, in general, these algorithms MAY differ, e.g., requiring different key lengths. This section specifies a generic way to derive MSG2.KEK for such cases.
MSG1.content-暗号化アルゴリズムとMSG2.key-暗号化アルゴリズムが同じである場合、その後MSG2.KEKはMSG1.CEKのバイトは逆です。しかし、一般的に、これらのアルゴリズムは、異なる鍵の長さを必要とする、例えば、異なっていてもよいです。このセクションでは、このような場合のためMSG2.KEKを導出する一般的な方法を指定します。
Note: In some sense, the CEK and KEK algorithms are never the "same", e.g., id-alg-CMS3DESwrap and des-ede3-cbc differ. However, for the purposes of this specification, all we care about is that the algorithms use the same format and size of keying material (see also security considerations) and that they do not differ significantly in terms of the resulting cryptographic "strength." In that sense the two algorithms in the example above are the "same."
注：ある意味では、CEKとKEKアルゴリズムは、 "同じ"、例えば、ID-ALG-CMS3DESwrapとDES-EDE3-CBCが異なることはありません。しかし、本明細書の目的のために、私たちは気にすべてのアルゴリズムは（もセキュリティの考慮事項を参照してください）素材をキーイングの同じ形式とサイズを使用することを、彼らは結果として、暗号の面で大きく異なっていないということである「強さ」。その意味での例では2つのアルゴリズムは、上記の「同じ」です。
Implementations MAY include this functionality.
実装は、この機能を含むことができます。
The basic approach is to use the PBKDF2 key derivation function defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of a password. The output of the PBKDF2 function is MSG2.KEK. To this end, a new attribute type is defined which allows passing of the required parameters.
基本的なアプローチは、PKCS＃5 [RFC2898]で定義されたPBKDF2鍵導出関数を使用することであるが、代わりにパスワードの入力としてMSG1.CEKを使用します。 PBKDF2関数の出力はMSG2.KEKです。このため、新しい属性タイプは、必要なパラメータを渡すことができますが定義されます。
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params
}
kekAlg is the algorithm identifier (and associated parameters, if any), for the MSG2 key encryption algorithm. Note that it is not necessary to protect this field since modification of keyAlg only represents a denial-of-service attack.
（もしあれば、関連パラメータ）kekAlgはMSG2鍵暗号化アルゴリズムでは、アルゴリズム識別子です。 keyAlgの変更が唯一のサービス拒否攻撃を表しているので、このフィールドを保護する必要はないことに注意してください。
The PBKDF2 algorithm parameters are to be handled as follows:
PBKDF2アルゴリズムのパラメータは、次のように処理されます。
- The salt MUST use the "specified" element of the CHOICE. - The message originator selects the iterationCount. - The value of keyLength is determined by the kekAlg and MUST be present. - The prf field MUST use the default algorithm specified in [RFC2898] which is algid-hmacWithSHA1 (and so the prf field MUST be omitted).
- 塩はCHOICEの「指定」要素を使用しなければなりません。 - メッセージの発信者はiterationCountを選択します。 - KEYLENGTHの値はkekAlgによって決定され、存在しなければなりません。 - PRFフィールドはalgid-hmacWithSHA1は[RFC2898]で指定されたデフォルトのアルゴリズムを使用しなければならない（そしてPRFフィールドを省略しなければなりません）。
This specification only applies to messages where the CEKReference attribute is present. All attributes specified here SHOULD be ignored unless they are present in a message containing a valid, new or recognized, existing value of CEKReference. The CEKMaxDecrypts attribute is to be treated by the recipient as a hint, but MUST be honored by the originator.
この仕様はCEKReference属性が存在しているメッセージに適用されます。彼らはCEKReferenceの有効な、新規または認識し、既存の値を含むメッセージ中に存在しない限り、ここで指定したすべての属性が無視されるべきです。 CEKMaxDecrypts属性は、ヒントとして、受信者によって処理されるが、創始者によって名誉を与えなければなりません。
The optional to implement KEKDerivationAlgorithm attribute MUST only be present when MSG1.content-encryption algorithm differs from MSG2.key-encryption algorithm, in which case it MUST be present. Implementations that recognize this attribute, but do not support the functionality SHOULD ignore the attribute.
MSG1.content-暗号化アルゴリズムは、それが存在しなければならない場合にはMSG2.key、暗号化アルゴリズム、異なる場合KEKDerivationAlgorithm属性を実装するために、オプションは存在しなければなりません。この属性を認識しますが、機能をサポートしていない実装は属性を無視すべきです。
Ignoring attributes as discussed above, will lead to decryption failures. CMS implementations SHOULD be able to signal the particular reason for this failure to the calling application.
上述したように、属性を無視すると、復号化の失敗につながります。 CMSの実装は、呼び出し元のアプリケーションにこの失敗の特定の理由を通知することができるべきです。
Encryption does not provide authentication, for example, if the encryptedContent is essentially random then recipients MUST NOT assume that "knowing" a CEKReference value proves anything - anyone could have created the EnvelopedData. This is relevant both for security (the recovered plaintext should not be entirely random) and for avoiding denial of service (the recipient MUST NOT assume that using the right CEKReference means that message originator is genuine).
誰もがEnvelopedDataのを作成している可能性 - 暗号化は、暗号化コンテンツは、本質的にランダムであるならば、受信者がCEKReference値は何を証明し、「知っている」と仮定してはいけません、例えば、認証を提供していません。これは、セキュリティ（回復平文が完全にランダムであってはならない）のため、サービスの拒否を回避するために、両方の関連性がある（受信者が右CEKReferenceを使用すると、そのメッセージの発信が本物であることを意味すると仮定してはいけません）。
Similarly, using the correct CEKReference does not mean that a message has not been replayed or inserted, and recipients MUST NOT assume that replay has been avoided.
同様に、正しいCEKReferenceを使用すると、メッセージが再生または挿入されていないことを意味するものではありません。また、受信者はその再生が回避されたと仮定してはいけません。
The maxDecrypts field presents a potential denial-of-service attack if a very large value is included by an originator in an attempt to get a recipient to consume memory by storing the referenced CEKs for a long period or if the originator never sends the indicated number of ciphertexts. Recipients SHOULD therefore drop referenced CEKs where the maxDecrypts value is too large (according to local configuration) or the referenced CEK has been held for too long a period.
発信元が示された番号を送信したことがない長期間場合や、非常に大きな値が参照たCEKを格納することで、メモリを消費するため、受信者を取得しようとする試みで発信者によって含まれている場合maxDecryptsフィールドは、潜在的なサービス拒否攻撃を提示します暗号文の。受信者は、したがってmaxDecrypts値（ローカルコンフィギュレーションに応じて）が大きすぎるまたは参照CEKは、あまりにも長い期間保持された参照たCEKを削除すべきです。
Suppose MSG1 is sent to a set S1 of users. In the case where MSG2 is sent to only a subset of users in S1, all users from S1 will still be able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK). Implementers should be aware that in such cases, all members of the original set of recipients (S1) can access the plaintext of MSG2 and subsequent messages.
MSG1は、ユーザーの集合S1に送信されると仮定します。 MSG2は、S1でユーザのサブセットのみに送信された場合には、S1からのすべてのユーザーがまだ（MSG2.KEKためのみMSG1.CEKから計算される）MSG2を復号することができるであろう。実装者は、このような場合には、受信者（S1）の元のセットのすべてのメンバーがMSG2及びその後のメッセージの平文にアクセスすることができることに注意すべきです。
The reason for the byte reversal is as follows: without the byte reversal, an attacker knowing some of MSG1.plaintext (a prefix in a field for instance) can use the corresponding ciphertext block as the next encrypted CEK, i.e., as MSG2.KEKRecipientInfo.encryptedKey. Now the attacker knows the next CEK. This attacks something this note is not claiming to protect (origin authentication), but is easily avoided using the byte reversal. Byte-reversal was chosen over bit- reversal since bit-reversal would cause parity bits from MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based algorithms. Note that byte reversal would similarly affect parity if parity checks spanned more than one octet, however no well-known algorithms operate in this way.
次のようにバイト反転する理由は次のとおりバイト反転することなく、MSG1.plaintextの一部（例えば、フィールドに接頭辞）を知っている攻撃者はMSG2.KEKRecipientInfoとして、すなわち、次の暗号化CEKように、対応する暗号文ブロックを使用することができ.encryptedKey。今、攻撃者は次のCEKを知っています。これは、このノートは、（元の認証）を保護するために主張されていませんが、簡単にバイト反転を使用して回避することができる何かを攻撃します。ビット反転は、DESベースのアルゴリズムのためMSG2.KEKためのビットを鍵として使用するMSG1.CEKからパリティビットを引き起こすので、バイト反転がbit-反転上に選択しました。パリティチェックは、複数のオクテットをまたがる場合はそのバイト反転は同様にパリティに影響を与える注意してください、しかし無周知のアルゴリズムは、このように動作します。
Implementations should be very careful with this scheme if MSG[n].KEK is used to derive MSG[n].CEK, e.g., if MSG[n].CEK were the byte-reversal of MSG[n].KEK, then this scheme could result in a fixed key being unexpectedly used.
MSG [n]は.CEKはこの後、[n]は.KEK MSGのバイト反転した場合にはMSG [n]は.KEKは、MSG [n]は.CEK、例えばを導出するために使用されている場合、実装は、このスキームに非常に注意しなければなりませんスキームは、予想外に使用されている固定キーにつながる可能性があります。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[CMS-MSG] Ramsdell、B. "S / MIMEバージョン3メッセージ仕様"、RFC 2633、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月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[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月。
Authors' Addresses
著者のアドレス
Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8 IRELAND
スティーブン・ファレル、ボルチモアテクノロジーズ、39 Parkgateのストリート、ダブリン8 IRELAND
Phone: +353-1-881-6000 EMail: stephen.farrell@baltimore.ie
電話：+ 353-1-881-6000 Eメール：stephen.farrell@baltimore.ie
Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 USA
ショーン・ターナーIECA株式会社9010 Edgepark道路ウィーン、VA 22182 USA
Phone: +1.703.628.3180 EMail: turners@ieca.com
電話：+1.703.628.3180電子メール：turners@ieca.com
Appendix A: ASN.1 Module
付録A：ASN.1モジュール
SMIMERcek { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) rcek(13) }
SMIMERcek {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）rcek（13）}
-- This module contains the definitions of the attributes -- used for re-using the content encryption key from a -- message in further messages.
- このモジュールは、属性の定義が含まれている - さらに、メッセージ内のメッセージ - からコンテンツ暗号化キーを再使用するために使用します。
DEFINITIONS IMPLICIT TAGS ::=
BEGIN -- EXPORTS ALL --
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}。
-- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since -- this specification only uses 1988 ASN.1, the definition is -- repeated here for completeness.
- [RFC2898]はPBKDF2-paramsはを定義する1993 ASN.1を使用します。この仕様は唯一の1988 ASN.1を使用して、定義がされて - - ので、完全を期すためにここで繰り返します。
-- The DEFAULT prf field value, MUST be used for this
-- specification
digestAlgorithm OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) 2}
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
-- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which -- results in the same encoding as produced by the definition -- below. See [RFC2898] for that definition.
- 下 - 定義によって生成される同じ符号化における結果 - [RFC2898]は1993 ASN.1、使用PBKDF2-paramsはを定義します。その定義については、[RFC2898]を参照してください。
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING, -- MUST BE USED
otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
}
-- id-aa is the arc with all new authenticated and -- unauthenticated attributes produced the by S/MIME -- Working Group. It is also defined in [CMS-MSG]
- ワーキンググループ - 認証されていない属性は、S / MIMEによって生成 - ID-AAは、すべての認証新しく、とアークです。また、[CMS-MSG]で定義されています
id-aa OBJECT IDENTIFIER ::=
{iso(1) member-body(2) usa(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- This attribute contains what will be the key identifier
-- for subsequent messages
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
-- This attribute contains a "hint" to the recipient
-- indicating how many times the originator will use
-- the re-used CEK
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
-- This attribute specifies the key derivation function -- to be used when the default byte reversal operation cannot -- be used.
- 使用する - デフォルトのバイト反転動作ができない場合に使用する - この属性は、鍵導出関数を指定します。
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params }
END
終わり
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機能のための基金は現在、インターネット協会によって提供されます。