[要約] RFC 3185は、CMS(Cryptographic Message Syntax)のコンテンツ暗号化キーの再利用に関するガイドラインです。その目的は、セキュリティを維持しながら、CMSで使用されるキーを効果的に再利用する方法を提供することです。

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

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.

Copyright(c)The Internet Society(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
        
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".

ここでの基本的なアイデアは、コンテンツ暗号化キー(CEK)をメッセージ(MSG1など)から再利用して、CEKの参照値を含むことにより、後のメッセージ(MSG2)のキー暗号化キー(KEK)を導出することです。メッセージ1、およびメッセージ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].

このドキュメントの「必須」、「必須」、「必須」、「必要」、「推奨」、および「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.

- Originatorは、単一のトランザクションで多くのフィールドをサーバー(受信者)に送信したいクライアントであり、参照される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が適しています。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には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値を含むコンテンツタイプを定義することにより、必要な対称キーミー材料を確立するために想定できる他の方法があります。このスキームは一般的なグループキー管理よりもはるかに簡単ですが、実装がグループキー管理を既にサポートしている場合、このスキームは価値を追加しません。このスキームは、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の保護されていない識別子を保護できない識別子を含めることができます。このキーを使用して、EnvelopedDataの他のインスタンスまたは他の目的のために、キー暗号化キー(KEK)を導き出すことができます。MSG1のCEKがMSG2のKEKを導出するために使用する場合、MSG1は、CEKReference Syntaxを使用して単一の値を使用して、タイプID-AA-CEKReferenceの非保護されていない属性を含める必要があります。

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のバイトを逆にすることにより導出されます。バイトの反転は、攻撃者が既知のプレーンテキストを持っている攻撃を回避し、関連する暗号文(msg1.cekで暗号化)を(それ以外の場合)msg2.kekとして直接使用できる攻撃を回避することです。

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.

2) cekReference属性は、recipientinfoの選択のいずれかで発生する可能性があります:Ktri、Kari、またはKekri。実装者は、CTRIまたは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の保護されていない分野でも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メッセージよりも少ないものが正常に受信されている間に、CEKREFERANCE情報(最小限にキー識別子と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が欠落している場合、または値がない場合、各CEKは次のメッセージのKEKとして一度再利用されます。これは、msg [n] .kekがmsg [n-1] .cekのバイト反転であることを意味します。その後、msg [n 1] .kekは、msg [n] .cekのバイト反転になります。MSG [N-1] .CEKは、CEKがランダムに生成される限り(たとえば、KEKから派生したものではない)、MSG [n 1]にまったく影響を与えないことに注意してください。

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-Incryption AlgorithmとMSG2.Key-Encryption Algorithmが同じである場合、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).

- 塩は、選択の「指定された」要素を使用する必要があります。 - メッセージオリジネーターがiterationCountを選択します。-KeyLengthの値はKekalgによって決定され、存在する必要があります。-PRFフィールドは、algid-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属性が存在するメッセージにのみ適用されます。ここで指定されているすべての属性は、有効、新規、または認識されている既存の既存の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.

KekderivationalGorithm属性を実装するオプションは、MSG1.Content-IncryptionアルゴリズムがMSG2.Key-Incryptionアルゴリズムとは異なる場合にのみ存在する必要があります。その場合、存在する必要があります。この属性を認識しているが、機能をサポートしない実装は、属性を無視する必要があります。

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の実装は、呼び出しアプリケーションにこの失敗の特定の理由を示すことができるはずです。

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).

暗号化は認証を提供しません。たとえば、暗号化されたコンテンツが本質的にランダムである場合、受信者はセクレファレンス値を「知る」ことが何でも証明すると仮定してはなりません - 誰もが封筒を作成できたでしょう。これは、セキュリティ(回復されたプレーンテキストは完全にランダムであるべきではない)とサービスの拒否を回避するために関連するものです(受信者は、適切な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.

MaxDeCryptsフィールドは、参照されたCEKを長期間保存することで受信者にメモリを消費するために、またはオリジネーターが指定された番号を送信しない場合、受信者にメモリを消費するために、非常に大きな価値が発信者に含まれている場合、潜在的なサービス拒否攻撃を提示します。暗号文の。したがって、受信者は、MaxDecryptsの値が大きすぎる(ローカル構成による)または参照されるCEKが期間あまりにも長い間保持されている参照CEKSをドロップする必要があります。

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に送信されたとします。S1のユーザーのサブセットのみにMSG2が送信される場合、S1のすべてのユーザーはMSG2を解読することができます(MSG2.KekはMSG1.CEKからのみ計算されるため)。実装者は、そのような場合、元の受信者セット(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(たとえばフィールドの接頭辞)の一部を知っている攻撃者が、次の暗号化されたCEKとして、つまりmsg2.kekrecipientinfoとして、次の暗号化されたCEKとして使用できます。.EncryptedKey。これで、攻撃者は次のCEKを知っています。これは、このメモが保護すると主張するものではないもの(Origin Authentication)を攻撃しますが、バイト反転を使用して簡単に回避できます。ビット反転によりMSG1.CEKのパリティビットがDESベースのアルゴリズムのMSG2.KEKのキーイングビットとして使用されるため、バイト反転はビット反転よりも選択されました。パリティチェックが複数のオクテットにまたがる場合、バイトの反転は同様にパリティに影響を与えることに注意してください。ただし、このようによく知られているアルゴリズムは動作しません。

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のバイトリバーサルである場合、msg [n] .kekを使用する場合は、このスキームには非常に注意する必要があります。スキームにより、固定キーが予期せず使用される可能性があります。

7. References
7. 参考文献

[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] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

Authors' Addresses

著者のアドレス

Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8 IRELAND

スティーブンファレル、ボルチモアテクノロジーズ、39パークゲートストリート、ダブリン8アイルランド

   Phone: +353-1-881-6000
   EMail: stephen.farrell@baltimore.ie
        

Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 USA

Sean Turner IECA、Inc。9010 EdgePark Road Vienna、VA 22182 USA

   Phone: +1.703.628.3180
   EMail: 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) }
        
     -- 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 } ;
        
       -- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params.  Since
       -- this specification only uses 1988 ASN.1, the definition is
       -- repeated here for completeness.
        
       -- 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.
        
       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]
                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.

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。