RFC3185 日本語訳
3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner. October 2001. (Format: TXT=20404 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Farrell
Request for Comments: 3185 Baltimore Technologies
Category: Standards Track S. Turner
IECA
October 2001
コメントを求めるワーキンググループS.ファレル要求をネットワークでつないでください: 3185年のボルチモア技術カテゴリ: 標準化過程S.ターナーIECA2001年10月
Reuse of CMS Content Encryption Keys
cmの満足している暗号化キーの再利用
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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(暗号のMessage Syntax)のおおわれたデータ構造に主要な識別子を含む方法を述べます、一層のおおわれたデータ・パケットに満足している暗号化キーを再使用できるように。
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
1. 序論… 2 2. 適用性… 2 3. どうそれをするか… 3 4. 異なったCEKとKEKアルゴリズムを使用します… 4 5. 順応… 5 6. セキュリティ問題… 5 7. 参照… 6人の作者のアドレス… 6 付録A: ASN.1モジュール… 7 完全な著作権宣言文… 10
Farrell & Turner Standards Track [Page 1] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[1ページ]。
1. Introduction
1. 序論
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".
ここの基本的な考え方は後のメッセージのために、満足している暗号化の主要な暗号化を引き出すメッセージ(MSG1を言う)から主要な(CEK)キー(KEK)を再利用することです、(MSG2)、メッセージ1のCEKのための基準値、およびメッセージ2のためのそのKEKIdentifierと同じ値を含んでいることによって。 メッセージ1からのCEKは「参照をつけられたCEK」と呼ばれます。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
「必要で」、“SHOULD"の、そして、「お勧め」のキーワード“MUST"、およびこのドキュメントの「5月」は[RFC2119]で説明されるように解釈されることになっています。
2. Applicability
2. 適用性
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がどこで「失われたか」は、特に、この仕様を使用する創始者のものを定義するREQUIREDと受取人の振舞いです。
- This specification is not suitable for general group key
management.
- この仕様は一般的なグループ重要管理に適していません。
Farrell & Turner Standards Track [Page 2] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[2ページ]。
- 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は適当です: 完全にCMSからの暗号化キーのビットが層にする「獣皮」がそうするどんな暗号のAPIも参照をつけられたCEKの再利用を非常に防ぎそうです(彼らにはMSG1.CEKがMSG2.KEKに変えられるのを許容する基関数がないので)。
- 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が40ビットの暗号であるか、そして、およびMSG2.keyEncryptionAlgorithmが材料、次に、この仕様SHOULD NOTを合わせながら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値を含むcontent typeを定義することによって必要な左右対称の合わせることの材料を証明するために考えることができた他の道があります。 この体系は属性群かぎ管理よりはるかに簡単ですが、実装が既にグループ重要管理をサポートするなら、この体系は価値を高めません。 また、この体系もCMS図書館(新しい状態の参加はいくつかの実装のための問題であるかもしれませんが)での包含に適しています(例えば、どこに、内容はMSG2.KEKを含んでいますか)。(図書館は応用層体系よりいくつかの利点を示すことができます)。
3. How to do it
3. それをする方法
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 MUSTは、ただ一つの値でCEKReference構文を使用することでタイプイド-aa-CEKReferenceのunprotectedAttrs Attributeを含んでいます。
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属性しか使用できないだけです。
Farrell & Turner Standards Track [Page 3] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[3ページ]。
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.
2) CEKReference属性はRecipientInfoのための選択のどれかで起こることができます: ktri、kariまたはkekri。 作成者は、CEKReferenceがktriかkariが使用されているところに起こることができるだけであると仮定してはいけません。
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
イド-aa-CEKReferenceオブジェクト識別子:、:= イド-aa30、CEKReference:、:= 八重奏ストリング
id-aa is an object identifier defined in [CMS-MSG].
イド-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の「生涯」を示すのを許容するために、創始者はCEKMaxDecrypts属性を入れるかもしれません、EnvelopedDataのunprotectedAttrs分野でも。 INTEGER構文がこの属性にある、(値が最高に>=1でなければならない、2^31)、参照をつけられたCEKを使用するメッセージ(MSG1を除いた)の最大数を受取人に示します。 また、CEKReference属性を含んでいるとき、このAttributeを送るだけでよいです。
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.
受取人SHOULDがCEKReference情報を保守する、(最少量で、主要な識別子とCEK値) 首尾よくmaxDecryptメッセージ以下を受け取りましたが。 或るものが、以上を局所的に構成した後に受取人SHOULDはCEKReference情報を削除します。
When this attribute is not present, originators and recipients SHOULD behave as if a value of one had been sent.
創始者、この属性がいつ、存在していないか、そして、受取人SHOULDはまるで1の値を送ったかのように振る舞います。
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
イド-aa-CEKMaxDecryptsオブジェクト識別子:、:= イド-aa31CEKMaxDecrypts:、:= 整数
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はMSG[n].CEKのバイト反転になるでしょう。 そして、MSG[n-1].CEKがMSG[n+1]に影響力を全く持っていないことに注意してください、CEKsが手当たりしだいに生成される限り(例えばない、KEKsからどうにか派生する、)
4. Using different CEK and KEK algorithms
4. 異なったCEKとKEKアルゴリズムを使用します。
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を引き出すジェネリック方法を指定します。
Farrell & Turner Standards Track [Page 4] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[4ページ]。
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アルゴリズムが決して「同じこと」でない、例えば、イド-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]で定義されますが、MSG1.CEKを使用することでPBKDF2の主要な派生機能を使用することです。 PBKDF2機能の出力はMSG2.KEKです。 このために、新しい属性タイプは定義されます(必要なパラメタを通過させます)。
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params
}
イド-aa-KEKDerivationAlgオブジェクト識別子:、:= イド-aa32、KEKDerivationAlgorithm:、:= 系列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分野は寒けがしたhmacWithSHA1である[RFC2898]で指定されたデフォルトアルゴリズムを使用しなければなりません(したがって、prf分野を省略しなければなりません)。
5. Conformance
5. 順応
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属性が存在しているメッセージに適用されるだけです。 有効であって、新しい状態でaを含んでいて、それらがメッセージに存在していない場合無視されるか、または認識されて、すべての属性がここでSHOULDを指定しました、CEKReferenceの既存の値。 CEKMaxDecrypts属性がヒントとして受取人によって扱われることですが、創始者は光栄に思わなければなりません。
Farrell & Turner Standards Track [Page 5] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[5ページ]。
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が属性であると実装する任意が存在しているだけでよい、その場合、それは存在していなければなりません。 この属性を認識しますが、SHOULDが無視する機能性に属性をサポートしない実装。
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実装SHOULD、この失敗の特定の理由に呼ぶアプリケーションに合図できてください。
6. Security Considerations
6. セキュリティ問題
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).
暗号化は認証を提供しません、例えば、encryptedContentが本質的には無作為であるなら、CEKReference値は何でも立証します--だれでもEnvelopedDataを作成したかもしれないのを「知ってい」て、受取人はそれを仮定してはいけません。 保証(回復している平文は完全に無作為であるべきでない)とサービスの否定を避けるのにおいて、これは関連しています(受取人は、右の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.
非常に大きい値が受取人に長い間参照をつけられたCEKsを保存することによってメモリを消費させる試みで創始者によって入れられているか、または創始者が暗号文の示された数を決して送らないなら、maxDecrypts分野は潜在的サービス不能攻撃を提示します。 したがって、受取人SHOULDがmaxDecrypts値が大き過ぎる(地方の構成に従って)参照をつけられたCEKsを下げるか、または参照をつけられた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を解読することができるでしょう(MSG2.KEKが単にMSG1.CEKから計算されるので)。 Implementersはそのような場合、元のセットの受取人(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-
バイト反転の理由は以下の通りです: バイト反転がなければ、いくらかのMSG1.plaintext(例えば、分野の接頭語)を知っている攻撃者は次の暗号化されたCEKとして対応する暗号文ブロックを使用できます、すなわち、MSG2.KEKRecipientInfo.encryptedKeyとして。 今、攻撃者は次のCEKを知っています。 これは、この注意が保護すると主張していない何か(発生源認証)を攻撃しますが、バイト反転を使用することで容易に避けられます。 バイト反転に関して、ビットは選ばれました。
Farrell & Turner Standards Track [Page 6] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[6ページ]。
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.
ビット逆転以来の反転はDESベースのアルゴリズムにMSG2.KEKのためにビットを合わせるとしてMSG1.CEKからのパリティビットを使用するでしょう。しかしながら、パリティチェックが1つ以上の八重奏にかかっているならバイト反転が同様に同等に影響して、どんなよく知られるアルゴリズムもこのように作動しないことに注意してください。
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].KEKがMSG[n].CEKを引き出すのに使用されるなら実装がこの体系に非常に慎重であるはずである、例えば、MSG[n].CEKがMSG[n].KEKのバイト反転であるなら、この体系は不意に使用されることで固定キーをもたらすかもしれないでしょうに。
7. References
7. 参照
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[cm-MSG] Ramsdell、B.「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、2000年9月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Authors' Addresses
作者のアドレス
Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8 IRELAND
スティーブン・ファレル、ボルチモア技術、39Parkgate通り、ダブリン8アイルランド
Phone: +353-1-881-6000 EMail: stephen.farrell@baltimore.ie
以下に電話をしてください。 +353-1-881-6000 メールしてください: stephen.farrell@baltimore.ie
Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 USA
ショーンターナーIECA Inc.9010Edgepark Roadヴァージニア22182ウィーン(米国)
Phone: +1.703.628.3180 EMail: turners@ieca.com
以下に電話をしてください。 +1.703 .628 .3180 メール: turners@ieca.com
Farrell & Turner Standards Track [Page 7] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[7ページ]。
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) }
SMIMERcekiso(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.
-- このモジュールはメッセージが中でさらに通信させる属性(aから主要な満足している暗号化を再使用するために、使用される)の定義を含んでいます。
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
-- EXPORTS ALL --
始まり、--すべてをエクスポートします--
IMPORTS
輸入
AlgorithmIdentifier FROM
AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 } ;
AlgorithmIdentifier FROM AuthenticationFramework共同iso-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を定義するのに1993ASN.1を使用します。定義はそうです--以来にこの仕様は1988ASN.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}
-- これにおいて、DEFAULT prf分野価値は使用されているに違いありません--、仕様digestAlgorithm OBJECT IDENTIFIER:、:= iso(1)が(2) 私たち(840)rsadsi(113549)2をメンバーと同じくらい具体化させる、イド-hmacWithSHA1 OBJECT IDENTIFIER:、:= digestAlgorithm7
-- [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]は、1993ASN.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
}
PBKDF2-params:、:= 系列CHOICEに塩味を付けさせてください、OCTET STRING--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]
-- そして、イド-aaがすべてが新しい状態で認証されたアークである、--、非認証された属性が作り出されたS/MIME--作業部会。 また、それは中で定義されます。[cmエムエスジー]
Farrell & Turner Standards Track [Page 8] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[8ページ]。
id-aa OBJECT IDENTIFIER ::=
{iso(1) member-body(2) usa(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
イド-aa OBJECT IDENTIFIER:、:= iso(1)メンバーボディー(2)usa(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)は(2)を結果と考えます。
-- This attribute contains what will be the key identifier
-- for subsequent messages
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
-- この属性はその後のメッセージイド-aa-CEKReference OBJECT IDENTIFIERに、主要な識別子になることを含んでいます:、:= イド-aa30、CEKReference:、:= 八重奏ストリング
-- 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
-- この属性は受取人--創始者が何回使用を望んでいるかを示します--再中古のCEKイド-aa-CEKMaxDecrypts OBJECT IDENTIFIERに「ヒント」を含んでいます:、:= イド-aa31CEKMaxDecrypts:、:= 整数
-- 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 }
イド-aa-KEKDerivationAlgオブジェクト識別子:、:= イド-aa32、KEKDerivationAlgorithm:、:= 系列kekAlg AlgorithmIdentifier、pbkdf2Param PBKDF2-params
END
終わり
Farrell & Turner Standards Track [Page 9] RFC 3185 Reuse of CMS Content Encryption Keys October 2001
ファレルとターナーStandardsは暗号化キー2001年10月にcm内容のRFC3185再利用を追跡します[9ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Farrell & Turner Standards Track [Page 10]
ファレルとターナー標準化過程[10ページ]
一覧
スポンサーリンク
