RFC 8103 - Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8103
タイトル : RFC 8103 - 暗号メッセージ構文（CMS）でのChaCha20-Poly1305 Authenticated Encryptionの使用
翻訳編集 : 自動生成

[要約] RFC 8103は、ChaCha20-Poly1305認証付き暗号化アルゴリズムをCryptographic Message Syntax (CMS)で使用する方法について説明しています。この文書の目的は、セキュリティが強化されたデータ交換のために、より現代的で効率的な暗号化手段をCMSに統合することにあります。ChaCha20-Poly1305は、特にモバイルデバイスや低パワー環境での利用を念頭に置いて設計されており、AESベースの暗号化方式に代わる選択肢を提供します。関連するRFCには、CMSを定義するRFC 5652や、他の暗号化アルゴリズムの使用を説明するRFCが含まれます。RFC 8103は、セキュリティを必要とする様々なアプリケーションやプロトコルでの使用を想定しています。

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8103                                Vigil Security
Category: Standards Track                                  February 2017
ISSN: 2070-1721

Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)

暗号メッセージ構文（CMS）でのChaCha20-Poly1305 Authenticated Encryptionの使用

Abstract

概要

This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.

このドキュメントでは、ChaCha20-Poly1305 Authenticated Encryptionを暗号化メッセージ構文（CMS）で使用するための規則について説明します。 ChaCha20-Poly1305は、ChaChaストリーム暗号とPoly1305オーセンティケーターで構成される認証済み暗号化アルゴリズムです。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8103.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8103で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
      1.1. The ChaCha20 and Poly1305 AEAD Construction ................3
      1.2. ASN.1 ......................................................3
      1.3. Terminology ................................................3
   2. Key Management ..................................................4
   3. Using the AEAD_CHACHA20_POLY1305 Algorithm with
      AuthEnvelopedData ...............................................4
   4. S/MIME Capabilities Attribute ...................................5
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................8
   Appendix A. ASN.1 Module ...........................................9
   Acknowledgements ...................................................9
   Author's Address ...................................................9

1. Introduction

1. はじめに

This document specifies the conventions for using ChaCha20-Poly1305 Authenticated Encryption with the Cryptographic Message Syntax (CMS) [CMS] authenticated-enveloped-data content type [AUTHENV].

このドキュメントでは、ChaCha20-Poly1305 Authenticated Encryptionを暗号化メッセージ構文（CMS）[CMS] authentication-enveloped-dataコンテンツタイプ[AUTHENV]で使用するための規則を指定します。

ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 2008. It is a refinement of Salsa20, which is one of the ciphers in the eSTREAM portfolio [ESTREAM].

ChaCha [CHACHA]は、2008年にD. J. Bernsteinによって開発されたストリーム暗号です。これは、eSTREAMポートフォリオ[ESTREAM]の暗号の1つであるSalsa20の改良版です。

ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key and a 96-bit nonce. [FORIETF] provides a detailed algorithm description, examples, and test vectors of ChaCha20.

ChaCha20は、ChaChaの20ラウンドバリアントです。 256ビットの鍵と96ビットのナンスが必要です。 [FORIETF]は、ChaCha20の詳細なアルゴリズムの説明、例、およびテストベクトルを提供します。

Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator designed by D. J. Bernstein. Poly1305 produces a 16-byte authentication tag; it requires a 256-bit, single-use key. [FORIETF] also provides a detailed algorithm description, examples, and test vectors of Poly1305.

Poly1305 [POLY1305]は、D。J.バーンスタインが設計した1回限りの認証システムであるウェグマンカーターです。 Poly1305は16バイトの認証タグを生成します。 256ビットの使い捨てキーが必要です。 [FORIETF]は、Poly1305の詳細なアルゴリズムの説明、例、およびテストベクトルも提供します。

ChaCha20 and Poly1305 have been designed for high-performance software implementations. They can typically be implemented with few resources and inexpensive operations, making them suitable on a wide range of systems. They have also been designed to minimize leakage of information through side channels.

ChaCha20とPoly1305は、高性能ソフトウェアの実装用に設計されています。これらは通常、少ないリソースと安価な操作で実装できるため、幅広いシステムに適しています。また、サイドチャネルを介した情報の漏洩を最小限に抑えるように設計されています。

1.1. The ChaCha20 and Poly1305 AEAD Construction

1.1. ChaCha20およびPoly1305 AEAD構造

ChaCha20 and Poly1305 have been combined to create an Authenticated Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is described in [FORIETF].

ChaCha20とPoly1305が組み合わされて、関連データ付き認証暗号化（AEAD）アルゴリズム[AEAD]が作成されました。このAEADアルゴリズムはAEAD_CHACHA20_POLY1305と呼ばれることが多く、[FORIETF]で説明されています。

AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit nonce, an arbitrary-length plaintext, and an arbitrary-length additional authenticated data (AAD). As the name implies, a nonce value cannot be used securely more than once with the same key.

AEAD_CHACHA20_POLY1305は、256ビットキー、96ビットナンス、任意長のプレーンテキスト、および任意長の追加認証データ（AAD）の4つの入力を受け入れます。名前が示すように、ナンス値は同じキーで複数回安全に使用できません。

AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same length as the plaintext and a 128-bit authentication tag.

AEAD_CHACHA20_POLY1305は2つの出力を生成します。プレーンテキストと同じ長さの暗号文と128ビットの認証タグです。

AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar to the encryption processing. Of course, the roles of ciphertext and plaintext are reversed, so the ChaCha20 encryption function is applied to the ciphertext, producing the plaintext. The Poly1305 function is run over the AAD and the ciphertext, not the plaintext, and the resulting authentication tag is bitwise compared to the received authentication tag. The message is authenticated if and only if the calculated and received authentication tags match.

AEAD_CHACHA20_POLY1305認証済みの復号化処理は、暗号化処理に似ています。もちろん、暗号文と平文の役割は逆なので、ChaCha20暗号化機能が暗号文に適用され、平文が生成されます。 Poly1305関数は、プレーンテキストではなくAADと暗号文で実行され、結果の認証タグは受信した認証タグとビット単位で比較されます。計算されて受信された認証タグが一致する場合にのみ、メッセージが認証されます。

1.2. ASN.1

CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690].

CMS値は、ASN.1 [X680]を使用して生成されます。ASN.1は、基本エンコーディングルール（BER）およびDistinguished Encodingルール（DER）[X690]を使用します。

1.3. Terminology

1.3. 用語

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]で説明されているように解釈されます。

2. Key Management

2. キー管理

The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees. It can be extremely difficult to use a statically configured AEAD_CHACHA20_POLY1305 key and never repeat a nonce value; however, the CMS authenticated-enveloped-data content type supports four key management techniques that allow a fresh AEAD_CHACHA20_POLY1305 key to be used as the content-authenticated-encryption key for a single protected content:

同じキーでAEAD_CHACHA20_POLY1305 nonce値を再利用すると、セキュリティが保証されなくなります。静的に構成されたAEAD_CHACHA20_POLY1305キーを使用してnonce値を繰り返すことは非常に困難です。ただし、CMS authentication-enveloped-dataコンテンツタイプは、新しいAEAD_CHACHA20_POLY1305鍵を単一の保護されたコンテンツのcontent-authenticated-encryption鍵として使用できるようにする4つの鍵管理技術をサポートしています。

Key Transport: the fresh 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 fresh content-authenticated-encryption key is encrypted in the pairwise symmetric key;

鍵の合意：受信者の公開鍵と送信者の秘密鍵を使用してペアワイズ対称鍵暗号鍵が生成され、次に、新しいコンテンツ認証済み暗号鍵がペアワイズ対称鍵で暗号化されます。

Symmetric Key-Encryption Keys: the fresh content-authenticated-encryption key is encrypted in a previously distributed symmetric key-encryption key; and

対称キー暗号化キー：新しいコンテンツ認証暗号化キーは、以前に配布された対称キー暗号化キーで暗号化されます。そして

Passwords: the fresh content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.

パスワード：新しいコンテンツ認証済み暗号化キーは、パスワードまたは他の共有秘密値から導出されたキー暗号化キーで暗号化されます。

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 about their support of fresh content-authenticated-encryption keys can be made. 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つがサポートされている場合、設計者と実装者は独自の分析を実行する必要があります。

3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData

3. AuthEnvelopedDataでのAEAD_CHACHA20_POLY1305アルゴリズムの使用

This section specifies the conventions employed by CMS implementations that support the authenticated-enveloped-data content type and the AEAD_CHACHA20_POLY1305 algorithm.

このセクションでは、認証済みエンベロープデータコンテンツタイプとAEAD_CHACHA20_POLY1305アルゴリズムをサポートするCMS実装で採用されている規則を指定します。

The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.

AEAD_CHACHA20_POLY1305アルゴリズム識別子は、AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithmフィールドにあります。

The AEAD_CHACHA20_POLY1305 algorithm is used to (1) authenticate the attributes located in the AuthEnvelopedData authAttrs field, if any are present, (2) encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and (3) provide the message authentication code (MAC) located in the AuthEnvelopedData mac field. The authenticated attributes are DER encoded to produce the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called the authentication tag in [FORIETF], provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent.

AEAD_CHACHA20_POLY1305アルゴリズムは、（1）AuthEnvelopedData authAttrsフィールドにある属性が存在する場合はそれを認証し、（2）AuthEnvelopedData EncryptedContentInfo encryptedContentフィールドにあるコンテンツを暗号化し、（3）メッセージ認証コード（MAC）を提供するために使用されます。 AuthEnvelopedData macフィールドにあります。認証された属性はDERエンコードされ、AEAD_CHACHA20_POLY1305アルゴリズムへのAAD入力値を生成します。暗号文とMACは、AEAD_CHACHA20_POLY1305アルゴリズムの2つの出力です。 [FORIETF]で認証タグと呼ばれるMACは、AuthEnvelopedData authAttrsとAuthEnvelopedData EncryptedContentInfo encryptedContentの両方に整合性保護を提供することに注意してください。

Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm.

AEAD_CHACHA20_POLY1305アルゴリズムを呼び出す前に、平文コンテンツもオプションのAAD入力もパディングする必要はありません。

There is one algorithm identifier for the AEAD_CHACHA20_POLY1305 algorithm:

AEAD_CHACHA20_POLY1305アルゴリズムには、1つのアルゴリズム識別子があります。

      id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs9(9) smime(16) alg(3) 18 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain an AEADChaCha20Poly1305Nonce:

AlgorithmIdentifierパラメーターフィールドが存在する必要があり、パラメーターフィールドにはAEADChaCha20Poly1305Nonceが含まれている必要があります。

      AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the CMS, the content-authenticated-encryption key is normally used for a single content. 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.

AEADChaCha20Poly1305Nonceには、12オクテットのノンスが含まれています。 CMSでは、通常、コンテンツ認証された暗号化キーが単一のコンテンツに使用されます。 content-authenticated-encryptionキーのスコープ内では、nonce値は一意である必要があります。つまり、特定のキーで使用されるnonce値のセットには、重複する値を含めることはできません。

4. S/MIME Capabilities Attribute

4. S / MIME機能属性

Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities attribute, which is used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a CMS signed-data content type, compliant software MAY include the SMIMECapabilities signed attribute to announce support for the AEAD_CHACHA20_POLY1305 algorithm.

RFC 5751 [MSG]のセクション2.5.2は、SMIMECapabilities属性を定義しています。これは、SMIMECapabilitiesを通知するソフトウェアがサポートできるアルゴリズムの部分的なリストを指定するために使用されます。 CMS署名付きデータコンテンツタイプを構築するとき、準拠ソフトウェアは、AEAD_CHACHA20_POLY1305アルゴリズムのサポートを通知するためにSMIMECapabilities署名済み属性を含めることができます。

The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305 algorithm MUST include the id-alg-AEADChaCha20Poly1305 object identifier in the capabilityID field and MUST omit the parameters field.

AEAD_CHACHA20_POLY1305アルゴリズムを表すSMIMECapability SEQUENCEは、capabilityIDフィールドにid-alg-AEADChaCha20Poly1305オブジェクト識別子を含めなければならず、パラメーターフィールドを省略しなければなりません（MUST）。

The DER encoding of an SMIMECapability SEQUENCE is the same as the DER encoding of an AlgorithmIdentifier. The DER encoding for the AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in hexadecimal) is:

SMIMECapability SEQUENCEのDERエンコードは、AlgorithmIdentifierのDERエンコードと同じです。 SMIMECapability SEQUENCE（16進数）でのAEAD_CHACHA20_POLY1305アルゴリズムのDERエンコードは次のとおりです。

30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 12

5. IANA Considerations

5. IANAに関する考慮事項

IANA has added the following entry in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry:

IANAは、「SMI Security for S / MIME Algorithms（1.2.840.113549.1.9.16.3）」レジストリに次のエントリを追加しました。

18 id-alg-AEADChaCha20Poly1305 RFC 8103

IANA has added the following entry in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:

IANAは、「SMI Security for S / MIME Module Identifier（1.2.840.113549.1.9.16.0）」レジストリに次のエントリを追加しました。

66 id-mod-CMS-AEADChaCha20Poly1305 RFC 8103

6. Security Considerations

6. セキュリティに関する考慮事項

The CMS AuthEnvelopedData provides all of the tools needed to avoid reuse of the same nonce value under the same key. See the discussion in Section 2 of this document. RFC 7539 [FORIETF] describes the consequences of using a nonce value more than once:

CMS AuthEnvelopedDataは、同じキーで同じnonce値が再利用されないようにするために必要なすべてのツールを提供します。このドキュメントのセクション2の説明を参照してください。 RFC 7539 [FORIETF]は、nonce値を複数回使用した場合の結果について説明しています。

Consequences of repeating a nonce: If a nonce is repeated, then both the one-time Poly1305 key and the keystream are identical between the messages. This reveals the XOR of the plaintexts, because the XOR of the plaintexts is equal to the XOR of the ciphertexts.

nonceを繰り返すことの結果：nonceが繰り返される場合、1回限りのPoly1305キーとキーストリームの両方がメッセージ間で同一です。これは、平文のXORが暗号文のXORと等しいため、平文のXORを明らかにします。

When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always the same size as the original plaintext. Some other mechanism needs to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure of the size of the plaintext is a concern.

AEAD_CHACHA20_POLY1305を使用する場合、結果の暗号文は常に元の平文と同じサイズになります。平文のサイズの開示が懸念される場合は、他のメカニズムをAEAD_CHACHA20_POLY1305と組み合わせて使用する必要があります。

The amount of encrypted data possible in a single invocation of AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of the size of the block counter field in the ChaCha20 block function. This gives a total of 247,877,906,880 octets, which is likely to be sufficient to handle the size of any CMS content type. Note that the ciphertext length field in the authentication buffer will accommodate 2^64 octets, which is much larger than necessary.

ChaCha20ブロック関数のブロックカウンターフィールドのサイズのため、AEAD_CHACHA20_POLY1305の1回の呼び出しで可能な暗号化データの量は、それぞれ64オクテットの2 ^ 32-1ブロックです。これにより、合計247,877,906,880オクテットが得られます。これは、CMSコンテンツタイプのサイズを処理するのに十分であると思われます。認証バッファの暗号文の長さフィールドは、必要以上に大きい2 ^ 64オクテットに対応することに注意してください。

The AEAD_CHACHA20_POLY1305 construction is a novel composition of ChaCha20 and Poly1305. A security analysis of this composition is given in [PROCTER].

AEAD_CHACHA20_POLY1305構造は、ChaCha20とPoly1305の新しい構成です。この構成のセキュリティ分析は、[PROCTER]で提供されています。

Implementations must randomly generate content-authenticated-encryption keys. The use of inadequate pseudorandom 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, 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 [ランダム]は、この分野で重要なガイダンスを提供しています。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, <http://www.rfc-editor.org/info/rfc5083>.

[AUTHENV] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、DOI 10.17487 / RFC5083、2007年11月、<http://www.rfc-editor.org/info/ rfc5083>。

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.

[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。

[FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>.

[FORIETF] Nir、Y。、およびA. Langley、「IETFプロトコル用のChaCha20およびPoly1305」、RFC 7539、DOI 10.17487 / RFC7539、2015年5月、<http://www.rfc-editor.org/info/rfc7539>。

[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.

[MSG] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<http：//www.rfc- editor.org/info/rfc5751>。

[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[STDWORDS] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[X680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.

[X680] ITU-T、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、ISO / IEC 8824-1、2015年8月、<https：// www.itu.int/rec/T-REC-X.680/en>。

[X690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.

[X690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690、ISO / IEC 8825-1、2015年8月、<https://www.itu.int/rec/T-REC-X.690/en>。

7.2. Informative References

7.2. 参考引用

[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.

[AEAD] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<http://www.rfc-editor.org/info/rfc5116>。

[CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.

[CHACHA] Bernstein、D。、「ChaCha、Salsa20のバリアント」、2008年1月、<http://cr.yp.to/chacha/chacha-20080128.pdf>。

[ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., Gilbert, H., Johansson, T., Parker, M., Preneel, B., Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 1)", September 2008, <http://www.ecrypt.eu.org/stream/finallist.html>.

[ESTREAM]バベッジ、S。、デカンニエール、C。、カンテノート、A。、シド、C。、ギルバート、H。、ヨハンソン、T。、パーカー、M。、プレニール、B。、ライメン、V。、およびM 。Robshaw、「The eSTREAM Portfolio（rev。1）」、2008年9月、<http://www.ecrypt.eu.org/stream/finallist.html>。

[POLY1305] Bernstein, D., "The Poly1305-AES message-authentication code", March 2005, <http://cr.yp.to/mac/poly1305-20050329.pdf>.

[POLY1305] Bernstein、D。、「The Poly1305-AES message-authentication code」、2005年3月、<http://cr.yp.to/mac/poly1305-20050329.pdf>。

[PROCTER] Procter, G., "A Security Analysis of the Composition of ChaCha20 and Poly1305", August 2014, <http://eprint.iacr.org/2014/613.pdf>.

[PROCTER]プロクター、G。、「ChaCha20とPoly1305の構成のセキュリティ分析」、2014年8月、<http://eprint.iacr.org/2014/613.pdf>。

[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.

[ランダム] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。

Appendix A. ASN.1 Module

付録A. ASN.1モジュール

   CMS-AEADChaCha20Poly1305
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) 66 }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS
      CONTENT-ENCRYPTION
      FROM AlgorithmInformation-2009
          { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-mod-algorithmInformation-02(58) };

-- EXPORTS All

-すべてをエクスポート

   AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::=
       { cea-AEADChaCha20Poly1305, ... }

   cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= {
       IDENTIFIER id-alg-AEADChaCha20Poly1305
       PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required
       SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }

   id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs9(9) smime(16) alg(3) 18 }

   AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

END

終わり

Acknowledgements

謝辞

Thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and Niclas Comstedt for their review and insightful comments.

レビューと洞察に満ちたコメントを提供してくれたJim Schaad、Daniel Migault、Stephen Farrell、Yoav Nir、Niclas Comstedtに感謝します。

Author's Address

著者のアドレス

Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America

Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ合衆国

   Email: housley@vigilsec.com