[要約] RFC 5084は、CMSでAES-CCMとAES-GCM認証暗号化を使用するためのガイドラインです。このRFCの目的は、セキュアなメッセージの暗号化と認証を実現するための方法を提供することです。
Network Working Group R. Housley
Request for Comments: 5084 Vigil Security
Category: Standards Track November 2007
Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
暗号メッセージ構文（CMS）でのAES-CCMおよびAES-GCM Authenticated Encryptionの使用
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 specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type.
このドキュメントでは、AES-CCMおよびAES-GCM認証暗号化アルゴリズムを暗号化メッセージ構文（CMS）authentication-enveloped-dataコンテンツタイプで使用するための規則を指定します。
This document specifies the conventions for using Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and AES-Galois/Counter Mode (GCM) authenticated encryption algorithms as the content-authenticated-encryption algorithm with the Cryptographic Message Syntax [CMS] authenticated-enveloped-data content type [AuthEnv].
このドキュメントでは、暗号化メッセージのコンテンツ認証暗号化アルゴリズムとして、暗号化ブロックチェーンメッセージ認証コード（AES-CCM）およびAES-Galois / Counter Mode（GCM）認証暗号化アルゴリズムでAdvanced Encryption Standard-Counterを使用するための規則を指定します構文[CMS] authentication-enveloped-dataコンテンツタイプ[AuthEnv]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [STDWORDS]で説明されているように解釈されます。
CMS values are generated using ASN.1 [X.208-88], which uses the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88].
CMS値は、ASN.1 [X.208-88]を使用して生成されます。これは、基本エンコーディングルール（BER）[X.209-88]およびDistinguished Encodingルール（DER）[X.509-88]を使用します。
Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed the Rijndael block cipher algorithm, and they submitted it for consideration as the Advanced Encryption Standard (AES). Rijndael was selected by the National Institute for Standards and Technology (NIST), and it is specified in a U.S. Federal Information Processing Standard (FIPS) Publication [AES]. NIST selected the Rijndael algorithm for AES because it offers a combination of security, performance, efficiency, ease of implementation, and flexibility. Specifically, the algorithm performs well in both hardware and software across a wide range of computing environments. Also, the very low memory requirements of the algorithm make it very well suited for restricted-space environments. The AES is widely used by organizations, institutions, and individuals outside of the U.S. Government.
ベルギー出身のJoan Daemen博士とVincent Rijmen博士はRijndaelブロック暗号アルゴリズムを開発し、それらをAdvanced Encryption Standard（AES）として検討するために提出しました。 Rijndaelは、米国連邦情報・技術局（NIST）によって選択され、米国連邦情報処理標準（FIPS）出版物[AES]で指定されています。 NISTは、セキュリティ、パフォーマンス、効率、実装の容易さ、および柔軟性の組み合わせを提供するため、AESにラインダールアルゴリズムを選択しました。具体的には、アルゴリズムは、幅広いコンピューティング環境のハードウェアとソフトウェアの両方で適切に機能します。また、アルゴリズムのメモリ要件が非常に低いため、スペースが制限された環境に非常に適しています。 AESは、米国政府以外の組織、機関、および個人によって広く使用されています。
The AES specifies three key sizes: 128, 192, and 256 bits.
AESは、128、192、および256ビットの3つの鍵サイズを指定します。
The Counter with CBC-MAC (CCM) mode of operation is specified in [CCM]. CCM is a generic authenticated encryption block cipher mode. CCM is defined for use with any 128-bit block cipher, but in this document, CCM is used with the AES block cipher.
CBC-MAC（CCM）動作モードのカウンターは、[CCM]で指定されます。 CCMは、一般的な認証済み暗号化ブロック暗号モードです。 CCMは128ビットのブロック暗号で使用するように定義されていますが、このドキュメントでは、CCMはAESブロック暗号で使用されています。
AES-CCM has four inputs: an AES key, a nonce, a plaintext, and optional additional authenticated data (AAD). AES-CCM generates two outputs: a ciphertext and a message authentication code (also called an authentication tag).
AES-CCMには4つの入力があります。AESキー、ノンス、プレーンテキスト、およびオプションの追加認証データ（AAD）です。 AES-CCMは、暗号文とメッセージ認証コード（認証タグとも呼ばれる）の2つの出力を生成します。
The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties.
nonceは、認証された暗号化操作を実行するパーティによって生成されます。認証された暗号化キーの範囲内で、nonce値は一意である必要があります。つまり、特定のキーで使用されるnonce値のセットには、重複する値を含めることはできません。同じキーで暗号化された2つの異なるメッセージに同じナンスを使用すると、セキュリティプロパティが破壊されます。
AAD is authenticated but not encrypted. Thus, the AAD is not included in the AES-CCM output. It can be used to authenticate plaintext packet headers. In the CMS authenticated-enveloped-data content type, authenticated attributes comprise the AAD.
AADは認証されますが、暗号化されません。したがって、AADはAES-CCM出力には含まれません。プレーンテキストパケットヘッダーの認証に使用できます。 CMS認証済みエンベロープデータコンテンツタイプでは、認証済み属性がAADを構成します。
The Galois/Counter Mode (GCM) is specified in [GCM]. GCM is a generic authenticated encryption block cipher mode. GCM is defined for use with any 128-bit block cipher, but in this document, GCM is used with the AES block cipher.
ガロア/カウンターモード（GCM）は[GCM]で指定されます。 GCMは、一般的な認証済み暗号化ブロック暗号モードです。 GCMは128ビットのブロック暗号で使用するように定義されていますが、このドキュメントでは、GCMはAESブロック暗号で使用されています。
AES-GCM has four inputs: an AES key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). AES-GCM generates two outputs: a ciphertext and message authentication code (also called an authentication tag). To have a common set of terms for AES-CCM and AES-GCM, the AES-GCM IV is referred to as a nonce in the remainder of this document.
AES-GCMには4つの入力があります。AESキー、初期化ベクトル（IV）、プレーンテキストコンテンツ、およびオプションの追加認証データ（AAD）です。 AES-GCMは、暗号テキストとメッセージ認証コード（認証タグとも呼ばれる）の2つの出力を生成します。 AES-CCMおよびAES-GCMに共通の用語セットを使用するために、AES-GCM IVは、このドキュメントの残りの部分ではナンスと呼ばれます。
The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties.
nonceは、認証された暗号化操作を実行するパーティによって生成されます。認証された暗号化キーの範囲内で、nonce値は一意である必要があります。つまり、特定のキーで使用されるnonce値のセットには、重複する値を含めることはできません。同じキーで暗号化された2つの異なるメッセージに同じナンスを使用すると、セキュリティプロパティが破壊されます。
AAD is authenticated but not encrypted. Thus, the AAD is not included in the AES-GCM output. It can be used to authenticate plaintext packet headers. In the CMS authenticated-enveloped-data content type, authenticated attributes comprise the AAD.
AADは認証されますが、暗号化されません。したがって、AADはAES-GCM出力には含まれません。プレーンテキストパケットヘッダーの認証に使用できます。 CMS認証済みエンベロープデータコンテンツタイプでは、認証済み属性がAADを構成します。
The reuse of an AES-CCM or AES-GCM nonce/key combination destroys the security guarantees. As a result, it can be extremely difficult to use AES-CCM or AES-GCM securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system [KEYMGMT].
AES-CCMまたはAES-GCM nonce / keyの組み合わせを再利用すると、セキュリティが保証されなくなります。その結果、静的に構成されたキーを使用する場合、AES-CCMまたはAES-GCMを安全に使用することは非常に難しい場合があります。安全のため、実装では自動キー管理システム[KEYMGMT]を使用する必要があります。
The CMS authenticated-enveloped-data content type supports four general key management techniques:
CMS認証済みエンベロープデータコンテンツタイプは、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, then the content-authenticated-encryption key is encrypted in the pairwise symmetric 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キーは、パスワードまたは他の共有秘密値から派生したキー暗号化キーで暗号化されます。
All of these key management techniques meet the automated key management system requirement as long as a fresh content-authenticated-encryption key is generated for the protection of each content. Note that some of these key management techniques use one key-encryption key to encrypt more than one content-authenticated- encryption key during the system life cycle. As long as fresh content-authenticated-encryption key is used each time, AES-CCM and AES-GCM can be used safely with the CMS authenticated-enveloped-data content type.
これらのすべてのキー管理手法は、各コンテンツの保護のために新しいコンテンツ認証済み暗号化キーが生成される限り、自動化されたキー管理システム要件を満たします。これらのキー管理手法のいくつかは、システムライフサイクル中に1つのキー暗号化キーを使用して、複数のコンテンツ認証済み暗号化キーを暗号化することに注意してください。新しいコンテンツ認証暗号化キーが毎回使用される限り、AES-CCMおよびAES-GCMは、CMS認証エンベロープデータコンテンツタイプで安全に使用できます。
In addition to these four general key management techniques, CMS supports other key management techniques. See Section 6.2.5 of [CMS]. Since the properties of these key management techniques are unknown, no statement can be made about whether these key management techniques meet the automated key management system requirement. Designers and implementers must perform their own analysis if one of these other key management techniques is supported.
これらの4つの一般的なキー管理手法に加えて、CMSは他のキー管理手法をサポートしています。 [CMS]のセクション6.2.5を参照してください。これらの鍵管理手法の特性は不明であるため、これらの鍵管理手法が自動化された鍵管理システムの要件を満たしているかどうかについては言及できません。これらの他の主要な管理手法の1つがサポートされている場合、設計者と実装者は独自の分析を実行する必要があります。
This section specifies the conventions employed by CMS implementations that support content-authenticated encryption using AES-CCM or AES-GCM.
このセクションでは、AES-CCMまたはAES-GCMを使用したコンテンツ認証暗号化をサポートするCMS実装で採用されている規則を指定します。
Content-authenticated encryption algorithm identifiers are located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.
コンテンツ認証された暗号化アルゴリズムの識別子は、AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithmフィールドにあります。
Content-authenticated encryption algorithms are used to encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field and to provide the message authentication code for the AuthEnvelopedData mac field. Note that the message authentication code provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent.
コンテンツで認証された暗号化アルゴリズムは、AuthEnvelopedData EncryptedContentInfo encryptedContentフィールドにあるコンテンツを暗号化し、AuthEnvelopedData macフィールドにメッセージ認証コードを提供するために使用されます。メッセージ認証コードは、AuthEnvelopedData authAttrsとAuthEnvelopedData EncryptedContentInfo encryptedContentの両方の整合性保護を提供することに注意してください。
The AES-CCM authenticated encryption algorithm is described in [CCM]. A brief summary of the properties of AES-CCM is provided in Section 1.4.
AES-CCM認証の暗号化アルゴリズムは、[CCM]で説明されています。 AES-CCMのプロパティの簡単な概要は、セクション1.4に記載されています。
Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking AES-CCM.
プレーンテキストコンテンツもオプションのAAD入力も、AES-CCMを呼び出す前にパディングする必要はありません。
There are three algorithm identifiers for AES-CCM, one for each AES key size:
AES-CCMには3つのアルゴリズム識別子があり、AES鍵サイズごとに1つあります。
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 }
id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 }
id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 }
With all three AES-CCM algorithm identifiers, the AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a CCMParameter:
3つすべてのAES-CCMアルゴリズム識別子では、AlgorithmIdentifierパラメーターフィールドが存在する必要があり、パラメーターフィールドにはCCMParameterが含まれている必要があります。
CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
The aes-nonce parameter field contains 15-L octets, where L is the size of the length field. With the CMS, the normal situation is for the content-authenticated-encryption key to be used for a single content; therefore, L=8 is RECOMMENDED. See [CCM] for a discussion of the trade-off between the maximum content size and the size of the nonce. Within the scope of any content-authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values.
aes-nonceパラメータフィールドには15-Lオクテットが含まれます。Lは長さフィールドのサイズです。 CMSでは、通常の状況では、コンテンツ認証された暗号化キーが単一のコンテンツに使用されます。したがって、L = 8が推奨されます。最大コンテンツサイズとナンスのサイズのトレードオフについては、[CCM]を参照してください。 content-authenticated-encryptionキーのスコープ内では、nonce値は一意である必要があります。つまり、特定のキーで使用されるnonce値のセットには、重複する値を含めることはできません。
The aes-ICVlen parameter field tells the size of the message authentication code. It MUST match the size in octets of the value in the AuthEnvelopedData mac field. A length of 12 octets is RECOMMENDED.
aes-ICVlenパラメータフィールドは、メッセージ認証コードのサイズを示します。 AuthEnvelopedData macフィールドの値のオクテット単位のサイズと一致する必要があります。 12オクテットの長さが推奨されます。
The AES-GCM authenticated encryption algorithm is described in [GCM]. A brief summary of the properties of AES-CCM is provided in Section 1.5.
AES-GCM認証の暗号化アルゴリズムについては、[GCM]で説明されています。 AES-CCMのプロパティの簡単な概要は、セクション1.5に記載されています。
Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking AES-GCM.
プレーンテキストコンテンツもオプションのAAD入力も、AES-GCMを呼び出す前にパディングする必要はありません。
There are three algorithm identifiers for AES-GCM, one for each AES key size:
AES-GCMには3つのアルゴリズム識別子があり、AESキーのサイズごとに1つあります。
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }
id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }
id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }
With all three AES-GCM algorithm identifiers, the AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a GCMParameter:
3つすべてのAES-GCMアルゴリズム識別子では、AlgorithmIdentifierパラメーターフィールドが存在する必要があり、パラメーターフィールドにはGCMParameterが含まれている必要があります。
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
The aes-nonce is the AES-GCM initialization vector. The algorithm specification permits the nonce to have any number of bits between 1 and 2^64. However, the use of OCTET STRING within GCMParameters requires the nonce to be a multiple of 8 bits. Within the scope of any content-authenticated-encryption key, the nonce value MUST be unique, but need not have equal lengths. A nonce value of 12 octets can be processed more efficiently, so that length is RECOMMENDED.
aes-nonceはAES-GCM初期化ベクトルです。アルゴリズムの仕様により、ノンスは1から2 ^ 64までの任意のビット数を持つことができます。ただし、GCMParameters内でOCTET STRINGを使用するには、nonceが8ビットの倍数である必要があります。 content-authenticated-encryptionキーのスコープ内では、nonce値は一意である必要がありますが、同じ長さである必要はありません。 12オクテットのnonce値はより効率的に処理できるため、長さはRECOMMENDEDになります。
The aes-ICVlen parameter field tells the size of the message authentication code. It MUST match the size in octets of the value in the AuthEnvelopedData mac field. A length of 12 octets is RECOMMENDED.
aes-ICVlenパラメータフィールドは、メッセージ認証コードのサイズを示します。 AuthEnvelopedData macフィールドの値のオクテット単位のサイズと一致する必要があります。 12オクテットの長さが推奨されます。
AES-CCM and AES-GCM make use of the AES 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.
AES-CCMおよびAES-GCMは、カウンターモードでAESブロック暗号を利用して暗号化を提供します。適切に使用すると、カウンターモードは強力な機密性を提供します。 Bellade、Desai、Jokipii、およびRogawayは、[BDJR]で、同じブロック暗号を使用する場合、カウンターモードによって提供されるプライバシー保証が少なくとも暗号ブロックチェーン（CBC）モードのプライバシー保証と同じくらい強いことを示しています。
Unfortunately, it is easy to misuse counter mode. If counter block values are ever used for more than 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 AuthEnvelopedData provides all the tools needed to avoid misuse of counter mode. Automated key management is discussed in Section 2.
幸い、CMS AuthEnvelopedDataは、カウンターモードの誤用を回避するために必要なすべてのツールを提供します。自動鍵管理については、セクション2で説明します。
There are fairly generic precomputation attacks against the use of any block cipher in counter mode that allow a meet-in-the-middle attack against the key [H][B][MF]. AES-CCM and AES-GCM both make use of counter mode for encryption. These precomputation attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of any block cipher in counter mode is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. Use of an unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful precomputation attack.
カウンターモードでのブロック暗号の使用に対するかなり一般的な事前計算攻撃があり、キー[H] [B] [MF]に対するミドルインザミドル攻撃を可能にします。 AES-CCMとAES-GCMはどちらも暗号化にカウンターモードを使用します。これらの事前計算攻撃では、既知の平文と既知の鍵に関連付けられた暗号文の巨大なテーブルを作成して検索する必要があります。メモリとプロセッサのリソースが事前計算攻撃に利用できると仮定すると、カウンターモードでのブロック暗号の理論上の強度は2 ^（n / 2）ビットに制限されます。ここで、nはキーのビット数です。長いキーの使用は、事前計算攻撃への最善の対策です。カウンターブロックで予測できないナンス値を使用すると、攻撃者が事前計算攻撃を成功させるために計算する必要があるテーブルのサイズが大幅に増加します。
Implementations must randomly generate content-authenticated-encryption keys. 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 [ランダム]は、この分野で重要なガイダンスを提供しています。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001.
[AES] NIST、FIPS PUB 197、「Advanced Encryption Standard（AES）」、2001年11月。
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[CCM] Whiting、D.、Housley、R。、およびN. Ferguson、「Counter with CBC-MAC（CCM）」、RFC 3610、2003年9月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3852、2004年7月。
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC." , U.S. National
Institute of Standards and Technology
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-
800-38D.pdf
[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。
[AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[AuthEnv] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、2007年11月。
[B] Biham, E., "How to Forge DES-Encrypted Messages in 2^28 Steps", Technion Computer Science Department Technical Report CS0884, 1996.
[B] Biham、E。、「2 ^ 28ステップでDES暗号化メッセージを偽造する方法」、Technion Computer Science Department Technical Report CS0884、1996。
[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年
[H] Hellman, M. E., "A cryptanalytic time-memory trade-off", IEEE Transactions on Information Theory, July 1980, pp. 401-406.
[H] Hellman、M。E。、「A cryptanalytic time-memory trade-off」、IEEE Transactions on Information Theory、1980年7月、401-406ページ。
[KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[KEYMGMT] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[MF] McGrew, D., and S. Fluhrer, "Attacks on Additive Encryption of Redundant Plaintext and Implications on Internet Security", The Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000), Springer-Verlag, August, 2000.
[MF] McGrew、D。、およびS. Fluhrer、「冗長な平文の付加的暗号化とインターネットセキュリティへの影響に関する攻撃」、暗号化の選択された領域に関する第7回年次ワークショップの議事録（SAC 2000）、Springer-Verlag、8月、2000。
[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月。
Appendix: ASN.1 Module
付録：ASN.1モジュール
CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS All
-すべてをエクスポート
-- Object Identifiers
-オブジェクト識別子
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 }
id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 }
id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 }
id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }
id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }
id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }
-- Parameters for AigorithmIdentifier
-AigorithmIdentifierのパラメーター
CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
END
終わり
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ
EMail: 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に情報を送信してください。