[要約] RFC 5083は、CMS Authenticated-Enveloped-Dataコンテンツタイプに関する仕様です。このRFCの目的は、デジタル署名と暗号化を組み合わせたセキュアなメッセージの送信と受信を可能にすることです。
Network Working Group R. Housley
Request for Comments: 5083 Vigil Security
Updates: 3852 November 2007
Category: Standards Track
Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
暗号化メッセージ構文（CMS）Authenticated-Enveloped-Data Content Type
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.
このドキュメントでは、暗号化メッセージ構文（CMS）の追加のコンテンツタイプについて説明します。 authentication-enveloped-dataコンテンツタイプは、認証済み暗号化モードでの使用を目的としています。 CMSエンベロープデータコンテンツタイプでサポートされているさまざまなキー管理手法はすべて、CMS認証エンベロープデータコンテンツタイプでもサポートされています。
This document describes an additional content type for the Cryptographic Message Syntax (CMS) [CMS]. The authenticated-enveloped-data content type is intended for use with authenticated encryption modes, where an arbitrary content is both authenticated and encrypted. Also, some associated data in the form of authenticated attributes can also be authenticated. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.
このドキュメントでは、暗号化メッセージ構文（CMS）[CMS]の追加のコンテンツタイプについて説明します。 authentication-enveloped-dataコンテンツタイプは、任意のコンテンツが認証および暗号化される認証済み暗号化モードでの使用を目的としています。また、認証された属性の形式の一部の関連データも認証できます。 CMSエンベロープデータコンテンツタイプでサポートされているさまざまなキー管理手法はすべて、CMS認証エンベロープデータコンテンツタイプでもサポートされています。
The conventions for using the Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and the AES-Galois/Counter Mode (GCM) authenticated encryption algorithms with the CMS authenticated-enveloped-data content type defined in this document can be found in [AESALGS].
暗号ブロックチェーンメッセージ認証コード（AES-CCM）でAES-Galois / Counter Mode（GCM）認証済み暗号化アルゴリズムを使用するAdvanced Encryption Standard-Counterを使用するための規則ドキュメントは[AESALGS]にあります。
The authenticated-enveloped-data content type, like all of the other CMS content types, employs ASN.1 [X.208-88], and it uses both the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88].
他のすべてのCMSコンテンツタイプと同様に、authenticated-enveloped-dataコンテンツタイプはASN.1 [X.208-88]を採用しており、Basic Encoding Rules（BER）[X.209-88]とDistinguished Encoding Rules（DER）[X.509-88]。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS].
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必須」、「必須」、「推奨」、「必須」、および「オプション」は、[STDWORDS]で説明されているように解釈されます。
The major data structure (AuthEnvelopedData) includes a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender.
主要なデータ構造（AuthEnvelopedData）には、データ構造の最初の項目としてバージョン番号が含まれています。バージョン番号は、ASN.1デコードエラーを回避するためのものです。一部の実装では、デコードを試みる前にバージョン番号をチェックせず、デコードエラーが発生した場合、エラー処理ルーチンの一部としてバージョン番号がチェックされます。これは合理的なアプローチです。エラー処理を高速パスの外に置きます。このアプローチは、送信者が誤ったバージョン番号を使用した場合にも許容されます。
Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used.
構造が更新されるたびに、より高いバージョン番号が割り当てられます。ただし、最大の相互運用性を確保するために、新しい構文機能が採用されている場合にのみ、より高いバージョン番号が使用されます。つまり、生成された構文をサポートする最も低いバージョン番号が使用されます。
The authenticated-enveloped-data content type consists of an authenticated and encrypted content of any type and encrypted content-authenticated-encryption keys for one or more recipients. The combination of the authenticated and encrypted content and one encrypted content-authenticated-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for an arbitrary number of recipients using any of the supported key management techniques for each recipient. In addition, authenticated but not encrypted attributes may be provided by the originator.
authentication-enveloped-dataコンテンツタイプは、任意のタイプの認証および暗号化されたコンテンツと、1人以上の受信者用の暗号化されたコンテンツ認証暗号化キーで構成されます。認証および暗号化されたコンテンツと、受信者用の1つの暗号化されたコンテンツ認証済み暗号化キーの組み合わせは、その受信者の「デジタルエンベロープ」です。各受信者に対してサポートされているキー管理技術を使用して、任意のタイプのコンテンツを任意の数の受信者にエンベロープできます。さらに、認証されたが暗号化されていない属性が発信者によって提供される場合があります。
The typical application of the authenticated-enveloped-data content type will represent one or more recipients' digital envelopes on an encapsulated content.
認証エンベロープデータコンテンツタイプの一般的なアプリケーションは、カプセル化されたコンテンツの1人以上の受信者のデジタルエンベロープを表します。
Authenticated-enveloped-data is constructed by the following steps:
Authenticated-enveloped-dataは、次の手順で作成されます。
1. A content-authenticated-encryption key for a particular content-authenticated-encryption algorithm is generated at random.
1. 特定のコンテンツ認証暗号化アルゴリズムのコンテンツ認証暗号化キーはランダムに生成されます。
2. The content-authenticated-encryption key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used, but four general techniques are supported:
2. content-authenticated-encryptionキーは、受信者ごとに暗号化されます。この暗号化の詳細は、使用される鍵管理アルゴリズムによって異なりますが、4つの一般的な手法がサポートされています。
Key Transport: the content-authenticated-encryption key is encrypted in the recipient's public key;
キートランスポート：コンテンツ認証された暗号化キーは、受信者の公開キーで暗号化されます。
Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key-encryption key, then the content-authenticated-encryption key is encrypted in the pairwise symmetric key-encryption key;
鍵合意：受信者の公開鍵と送信者の秘密鍵を使用してペアワイズ対称鍵暗号鍵が生成され、次にコンテンツ認証暗号鍵がペアワイズ対称鍵暗号鍵で暗号化されます。
Symmetric Key-Encryption Keys: the content-authenticated-encryption key is encrypted in a previously distributed symmetric key-encryption key; and
対称キー暗号化キー：コンテンツ認証暗号化キーは、以前に配布された対称キー暗号化キーで暗号化されます。そして
Passwords: the content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.
パスワード：content-authenticated-encryptionキーは、パスワードまたは他の共有秘密値から派生したキー暗号化キーで暗号化されます。
3. For each recipient, the encrypted content-authenticated-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2 of [CMS].
3. 受信者ごとに、暗号化されたコンテンツ認証暗号化キーとその他の受信者固有の情報が、[CMS]のセクション6.2で定義されているRecipientInfo値に収集されます。
4. Any attributes that are to be authenticated but not encrypted are collected in the authenticated attributes.
4. 認証されるが暗号化されない属性は、認証された属性に収集されます。
5. The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the content-authenticated-encryption key. If the authenticated encryption algorithm requires either the additional authenticated data (AAD) or the content to be padded to a multiple of some block size, then the padding is added as described in Section 6.3 of [CMS].
5. 手順4で収集された属性が認証され、CMSコンテンツが認証され、content-authenticated-encryptionキーで暗号化されます。認証された暗号化アルゴリズムで、追加の認証データ（AAD）またはコンテンツをブロックサイズの倍数にパディングする必要がある場合は、[CMS]のセクション6.3で説明されているようにパディングが追加されます。
6. Any attributes that are to be provided without authentication or encryption are collected in the unauthenticated attributes.
6. 認証または暗号化なしで提供される属性は、非認証属性に収集されます。
7. The RecipientInfo values for all the recipients, the authenticated attributes, the unauthenticated attributes, and the authenticated and encrypted content are collected together to form an AuthEnvelopedData value as defined in Section 2.1.
7. すべての受信者のRecipientInfo値、認証された属性、非認証の属性、および認証および暗号化されたコンテンツが一緒に収集され、セクション2.1で定義されているAuthEnvelopedData値を形成します。
A recipient opens the digital envelope by decrypting one of the encrypted content-authenticated-encryption keys, and then using the recovered key to decrypt and verify the integrity of the authenticated and encrypted content as well as to verify the integrity of the authenticated attributes.
受信者は、暗号化されたコンテンツで認証された暗号化キーの1つを復号化してデジタルエンベロープを開き、復元されたキーを使用して、認証および暗号化されたコンテンツの完全性を復号化および検証し、認証された属性の整合性を検証します。
The recipient MUST verify the integrity of the received content before releasing any information, especially the plaintext of the content. If the integrity verification fails, the receiver MUST destroy all of the plaintext of the content.
受信者は、情報、特にコンテンツの平文をリリースする前に、受信したコンテンツの整合性を検証する必要があります。完全性の検証が失敗した場合、受信者はコンテンツの平文をすべて破棄しなければなりません（MUST）。
This section is divided into three parts. The first part describes the AuthEnvelopedData content type, the second part describes the authentication and encryption process, and the third part describes the key encryption process.
このセクションは3つの部分に分かれています。最初の部分はAuthEnvelopedDataコンテンツタイプを説明し、2番目の部分は認証と暗号化プロセスを説明し、3番目の部分はキー暗号化プロセスを説明します。
The following object identifier identifies the authenticated-enveloped-data content type:
次のオブジェクト識別子は、authenticated-enveloped-dataコンテンツタイプを識別します。
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 }
The authenticated-enveloped-data content type MUST have ASN.1 type AuthEnvelopedData:
authentication-enveloped-dataコンテンツタイプには、ASN.1タイプのAuthEnvelopedDataが必要です。
AuthEnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
The fields of type AuthEnvelopedData have the following meanings:
タイプAuthEnvelopedDataのフィールドには次の意味があります。
version is the syntax version number. It MUST be set to 0.
versionは構文のバージョン番号です。 0に設定する必要があります。
originatorInfo optionally provides information about the originator. It is present only if required by the key management algorithm. It may contain certificates and Certificate Revocation Lists (CRLs), and the OriginatorInfo type is defined in Section 6.1 of [CMS].
originatorInfoは、オプションで発信者に関する情報を提供します。これは、鍵管理アルゴリズムで必要な場合にのみ存在します。証明書と証明書失効リスト（CRL）が含まれる場合があり、OriginatorInfoタイプは[CMS]のセクション6.1で定義されています。
recipientInfos is a collection of per-recipient information. There MUST be at least one element in the collection. The RecipientInfo type is defined in Section 6.2 of [CMS].
recipientInfosは、受信者ごとの情報のコレクションです。コレクションには少なくとも1つの要素が必要です。 RecipientInfoタイプは、[CMS]のセクション6.2で定義されています。
authEncryptedContentInfo is the authenticated and encrypted content. The CMS enveloped-data content type uses the same type to carry the encrypted content. The EncryptedContentInfo type is defined in Section 6.1 of [CMS].
authEncryptedContentInfoは、認証および暗号化されたコンテンツです。 CMSエンベロープデータコンテンツタイプは、同じタイプを使用して暗号化されたコンテンツを伝送します。 EncryptedContentInfoタイプは、[CMS]のセクション6.1で定義されています。
authAttrs optionally contains the authenticated attributes. The CMS authenticated-data content type uses the same type to carry authenticated attributes. The authAttrs MUST be present if the content type carried in EncryptedContentInfo is not id-data. AuthAttributes MUST be DER encoded, even if the rest of the AuthEnvelopedData structure is BER encoded. The AuthAttributes type is defined in Section 9.1 of [CMS]; however, in this case, the message-digest attribute SHOULD NOT be included. Useful attribute types are defined in Section 11 of [CMS].
authAttrsには、オプションで認証済み属性が含まれています。 CMS認証データコンテンツタイプは、同じタイプを使用して認証済み属性を伝送します。 EncryptedContentInfoに含まれるコンテンツタイプがid-dataでない場合は、authAttrsが存在する必要があります。 AuthEnvelopedData構造の残りがBERエンコードされている場合でも、AuthAttributesはDERエンコードされている必要があります。 AuthAttributesタイプは[CMS]のセクション9.1で定義されています。ただし、この場合、message-digest属性は含めないでください。有用な属性タイプは、[CMS]のセクション11で定義されています。
mac is the integrity check value (ICV) or message authentication code (MAC) that is generated by the authenticated encryption algorithm. The CMS authenticated-data content type uses the same type to carry a MAC. In this case, the MAC covers the authenticated attributes and the content directly, and a digest algorithm is not used. The MessageAuthenticationCode type is defined in Section 9.1 of [CMS].
macは、認証された暗号化アルゴリズムによって生成される整合性チェック値（ICV）またはメッセージ認証コード（MAC）です。 CMS認証データコンテンツタイプは、同じタイプを使用してMACを伝送します。この場合、MACは認証された属性とコンテンツを直接カバーし、ダイジェストアルゴリズムは使用されません。 MessageAuthenticationCodeタイプは、[CMS]のセクション9.1で定義されています。
unauthAttrs optionally contains the unauthenticated attributes. The CMS authenticated-data content type uses the same type to carry unauthenticated attributes. The UnauthAttributes type is defined in Section 9.1 of [CMS]. Useful attribute types are defined in Section 11 of [CMS].
unauthAttrsには、オプションで非認証属性が含まれています。 CMS認証データコンテンツタイプは、同じタイプを使用して、認証されていない属性を伝達します。 UnauthAttributesタイプは、[CMS]のセクション9.1で定義されています。有用な属性タイプは、[CMS]のセクション11で定義されています。
The content-authenticated-encryption key for the desired content-authenticated-encryption algorithm is randomly generated.
目的のコンテンツ認証暗号化アルゴリズムのコンテンツ認証暗号化キーがランダムに生成されます。
If the authenticated encryption algorithm requires the content to be padded to a multiple of some block size, then the padding MUST be added as described in Section 6.3 of [CMS]. This padding method is well defined if and only if the block size is less than 256 octets.
認証された暗号化アルゴリズムで、コンテンツをいくつかのブロックサイズの倍数にパディングする必要がある場合は、[CMS]のセクション6.3で説明されているように、パディングを追加する必要があります。このパディング方法は、ブロックサイズが256オクテット未満の場合にのみ明確に定義されています。
If optional authenticated attributes are present, then they are DER encoded. A separate encoding of the authAttrs field is performed to construct the authenticated associated data (AAD) input to the authenticated encryption algorithm. For the purposes of constructing the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for the DER encoding: rather a universal SET OF tag is used. That is, the DER encoding of the SET OF tag, rather than of the IMPLICIT [1] tag, is to be included in the construction for the AAD along with the length and content octets of the authAttrs value. If the authenticated encryption algorithm requires the AAD to be padded to a multiple of some block size, then the padding MUST be added as described in Section 6.3 of [CMS]. This padding method is well defined if and only if the block size is less than 256 octets.
オプションの認証済み属性が存在する場合、それらはDERエンコードされます。 authAttrsフィールドの個別のエンコードが実行され、認証済み暗号化アルゴリズムへの認証済み関連データ（AAD）入力が構成されます。 AADを構築するために、authAttrsフィールドのIMPLICIT [1]タグはDERエンコーディングに使用されません。ユニバーサルSET OFタグが使用されます。つまり、IMPLICIT [1]タグではなく、SET OFタグのDERエンコードが、authAttrs値の長さとコンテンツのオクテットとともにAADの構築に含まれます。認証された暗号化アルゴリズムでAADをいくつかのブロックサイズの倍数に埋め込む必要がある場合は、[CMS]のセクション6.3で説明されているように、埋め込みを追加する必要があります。このパディング方法は、ブロックサイズが256オクテット未満の場合にのみ明確に定義されています。
If optional authenticated attributes are absent, then zero bits of input are provided for the AAD input to the authenticated encryption algorithm.
オプションの認証済み属性が存在しない場合は、認証済み暗号化アルゴリズムへのAAD入力に0ビットの入力が提供されます。
The inputs to the authenticated encryption algorithm are the content (the data, which is padded if necessary), the DER-encoded authenticated attributes (the AAD, which is padded if necessary), and the content-authenticated-encryption key. Under control of a content-authenticated-encryption key, the authenticated encryption operation maps an arbitrary string of octets (the data) to another string of octets (the ciphertext) and it computes an authentication tag over the AAD and the data. The encrypted data is included in the AuthEnvelopedData authEncryptedContentInfo encryptedContent as an OCTET STRING, and the authentication tag is included in the AuthEnvelopedData mac.
認証済み暗号化アルゴリズムへの入力は、コンテンツ（必要に応じて埋め込まれるデータ）、DERエンコードされた認証済み属性（必要に応じて埋め込まれるAAD）、およびcontent-authenticated-encryptionキーです。コンテンツ認証された暗号化キーの制御下で、認証された暗号化操作は、オクテットの任意の文字列（データ）を別のオクテットの文字列（暗号文）にマッピングし、AADおよびデータに対して認証タグを計算します。暗号化されたデータは、AuthEnvelopedData authEncryptedContentInfo encryptedContentにOCTET STRINGとして含まれ、認証タグはAuthEnvelopedData macに含まれます。
The input to the key encryption process -- the value supplied to the recipient's key-encryption algorithm -- is just the "value" of the content-authenticated-encryption key.
キー暗号化プロセスへの入力（受信者のキー暗号化アルゴリズムに提供される値）は、コンテンツ認証された暗号化キーの単なる「値」です。
Any of the aforementioned key management techniques can be used for each recipient of the same encrypted content.
前述の鍵管理手法はどれも、同じ暗号化コンテンツの各受信者に使用できます。
This specification defines an additional CMS content type. The security considerations provided in [CMS] apply to this content type as well.
この仕様は、追加のCMSコンテンツタイプを定義します。 [CMS]で提供されるセキュリティの考慮事項は、このコンテンツタイプにも適用されます。
Many authenticated encryption algorithms make use of a block cipher in counter mode to provide encryption. When used properly, counter mode provides strong confidentiality. Bellare, Desai, Jokipii, and Rogaway show in [BDJR] that the privacy guarantees provided by counter mode are at least as strong as those for Cipher Block Chaining (CBC) mode when using the same block cipher.
多くの認証済み暗号化アルゴリズムは、カウンターモードでブロック暗号を使用して暗号化を提供します。適切に使用すると、カウンターモードは強力な機密性を提供します。 Bellade、Desai、Jokipii、およびRogawayは、[BDJR]で、同じブロック暗号を使用する場合、カウンターモードによって提供されるプライバシー保証が少なくとも暗号ブロックチェーン（CBC）モードのプライバシー保証と同じくらい強いことを示しています。
Unfortunately, it is easy to misuse counter mode. If counter block values are ever used for more that one encryption operation with the same key, then the same key stream will be used to encrypt both plaintexts, and the confidentiality guarantees are voided.
残念ながら、カウンタモードは誤用しやすいです。カウンターブロック値が同じキーを使用する複数の暗号化操作に使用される場合、同じキーストリームが両方の平文の暗号化に使用され、機密性の保証は無効になります。
Fortunately, the CMS authenticated-enveloped-data content type provides all of the tools needed to avoid misuse of counter mode. All of the existing key management techniques permit a fresh content-encryption key to be generated for each content. In addition, existing authenticated encryption algorithms that make use of counter mode support the use of an unpredictable nonce value in the counter block. This unpredictable nonce value (sometimes called a "salt") should be carried in an algorithm identifier parameter.
さいわい、CMSの認証済みエンベロープデータコンテンツタイプは、カウンターモードの誤用を避けるために必要なすべてのツールを提供します。既存のすべてのキー管理手法では、コンテンツごとに新しいコンテンツ暗号化キーを生成できます。さらに、カウンターモードを利用する既存の認証済み暗号化アルゴリズムは、カウンターブロックでの予測できないナンス値の使用をサポートしています。この予測不可能なノンス値（「塩」と呼ばれることもあります）は、アルゴリズム識別子パラメーターで伝達する必要があります。
Implementations must randomly generate content-authenticated-encryption keys, padding, and unpredictable nonce values. Also, the generation of public/private key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, and then searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area.
実装では、コンテンツ認証された暗号化キー、パディング、および予測できないナンス値をランダムに生成する必要があります。また、公開鍵と秘密鍵のペアの生成は、乱数に依存しています。不十分な疑似乱数ジェネレーター（PRNG）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、キーを生成したPRNG環境を再現して、その結果の可能性の小さなセットを検索する方がはるかに簡単であることに気付く場合があります。高品質の乱数の生成は困難です。 RFC 4086 [ランダム]は、この分野で重要なガイダンスを提供しています。
If the message-digest attribute is included in the AuthAttributes, then the attribute value will contain the unencrypted one-way hash value of the plaintext of the content. Disclosure of this hash value enables content tracking, and it can be used to determine if the plaintext matches one or more candidate contents. For these reasons, the AuthAttributes SHOULD NOT contain the message-digest attribute.
メッセージダイジェスト属性がAuthAttributesに含まれている場合、属性値にはコンテンツの平文の暗号化されていない一方向ハッシュ値が含まれます。このハッシュ値の開示によりコンテンツ追跡が可能になり、プレーンテキストが1つ以上の候補コンテンツと一致するかどうかを判断するために使用できます。これらの理由により、AuthAttributesにはメッセージダイジェスト属性を含めるべきではありません（SHOULD NOT）。
CMS is often used to provide encryption in messaging environments. In messaging environments, various forms of unsolicited messages (such as spam and phishing) represent a significant volume of unwanted traffic. Present mitigation strategies for unwanted message traffic involve analysis of message plaintext. When recipients accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many present mitigation strategies will be unable to access the plaintext. Therefore, software that receives messages that have been encrypted using CMS needs to provide one or more mechanisms to handle the unwanted message traffic. One approach that does not require disclosure of keying material to a server is to reject or discard encrypted messages unless they purport to come from a member of a white list.
CMSは、メッセージング環境で暗号化を提供するためによく使用されます。メッセージング環境では、さまざまな形式の迷惑メッセージ（スパムやフィッシングなど）が大量の不要なトラフィックを表しています。不要なメッセージトラフィックの現在の緩和戦略には、メッセージの平文の分析が含まれます。受信者が迷惑な暗号化されたメッセージを受け入れると、現在の多くの軽減策ではプレーンテキストにアクセスできなくなるため、不要なトラフィックに対してさらに脆弱になります。したがって、CMSを使用して暗号化されたメッセージを受信するソフトウェアは、不要なメッセージトラフィックを処理するための1つ以上のメカニズムを提供する必要があります。キー情報のサーバーへの開示を必要としない1つのアプローチは、ホワイトリストのメンバーからのものであると主張しない限り、暗号化されたメッセージを拒否または破棄することです。
CMS-AuthEnvelopedData-2007
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
輸入
-- Imports from RFC 3852 [CMS], Section 12.1
AuthAttributes, CMSVersion, EncryptedContentInfo,
MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
UnauthAttributes
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) } ;
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 }
AuthEnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
END -- of CMS-AuthEnvelopedData-2007
END-CMS-AuthEnvelopedData-2007の
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3852、2004年7月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88] CCITT。勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT。推奨事項X.209：抽象構文記法1（ASN.1）の基本的なエンコーディングルールの仕様。 1988。
[X.509-88] CCITT. Recommendation X.509: The Directory-Authentication Framework. 1988.
[X.509-88] CCITT。推奨事項X.509：ディレクトリ認証フレームワーク。 1988。
[AESALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
[AESALGS] Housley、R。、「暗号化メッセージ構文（CMS）でのAES-CCMおよびAES-GCM Authenticated Encryptionの使用」、RFC 5084、2007年11月。
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", Proceedings 38th Annual Symposium on Foundations of Computer Science, 1997.
[BDJR] Bellare、M.、Desai、A.、Jokipii、E。、およびP. Rogaway、「対称暗号化の具体的なセキュリティ処理：DES動作モードの分析」、第38回コンピュータサイエンスの基礎に関する年次シンポジウム、1997年。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA Eメール：housley@vigilsec.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。