RFC 8755 - Using Commercial National Security Algorithm Suite Algorithms in Secure/ Multipurpose Internet Mail Extensions 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8755.html
タイトル : RFC 8755 - Secure / Multipurpose Internet Mail Extensionsで商用National Security Algorithm Suiteアルゴリズムを使用する
翻訳編集 : 自動生成

[要約] 要約：RFC 8755は、商用の国家安全保障アルゴリズムスイートのアルゴリズムを安全な/多目的なインターネットメール拡張（S/MIME）で使用するためのガイドラインを提供しています。目的：このRFCの目的は、商用の国家安全保障アルゴリズムスイートのアルゴリズムをS/MIMEで使用する際のベストプラクティスとセキュリティ上の考慮事項を示すことです。

Independent Submission                                        M. Jenkins
Request for Comments: 8755                                           NSA
Category: Informational                                       March 2020
ISSN: 2070-1721

Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions

Secure / Multipurpose Internet Mail Extensionsで商用National Security Algorithm Suiteアルゴリズムを使用する

Abstract

概要

The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

アメリカ合衆国政府は、国家安全保障局（NSA）の商用国家安全保障アルゴリズム（CNSA）スイートを公開しています。これは、国家安全保障アプリケーションの暗号アルゴリズムポリシーを定義しています。このドキュメントでは、RFC 8551で指定されているSecure / Multipurpose Internet Mail Extensions（S / MIME）で米国国家安全保障局のCNSA Suiteアルゴリズムを使用するための規則を指定します。これは、US Nationalのすべてのコンポーネントの機能、構成、および操作に適用されますS / MIMEメッセージングを使用するセキュリティシステム。米国国家安全保障システムは、NIST Special Publication 800-59に記載されています。また、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよびその他のシステム展開の開発者およびオペレーターが使用できるように公開されています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

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

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

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1.  Introduction
     1.1.  Terminology
   2.  The Commercial National Security Algorithm Suite
   3.  Requirements and Assumptions
   4.  SHA-384 Message Digest Algorithm
   5.  Digital Signature
     5.1.  ECDSA Signature
     5.2.  RSA Signature
   6.  Key Establishment
     6.1.  Elliptic Curve Key Agreement
     6.2.  RSA Key Transport
   7.  Content Encryption
     7.1.  AES-GCM Content Encryption
     7.2.  AES-CBC Content Encryption
   8.  Security Considerations
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Author's Address

1. Introduction

1. はじめに

This document specifies the conventions for using the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite algorithms [CNSA] in Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC8551]. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59 [SP80059]. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

このドキュメントでは、米国国家安全保障局の商用国家安全保障アルゴリズム（CNSA）スイートアルゴリズム[CNSA]をSecure / Multipurpose Internet Mail Extensions（S / MIME）[RFC8551]で使用するための規則を指定します。これは、S / MIMEメッセージングを採用する米国国家安全保障システムのすべてのコンポーネントの機能、構成、および操作に適用されます。米国の国家安全保障システムは、NIST Special Publication 800-59 [SP80059]で説明されています。また、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよびその他のシステム展開の開発者およびオペレーターが使用できるように公開されています。

S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652] [RFC5083]. In particular, the signed-data, enveloped-data, and authenticated-enveloped-data content types are used. This document only addresses CNSA Suite compliance for S/MIME. Other applications of CMS are outside the scope of this document.

S / MIMEは、暗号化メッセージ構文（CMS）[RFC5652] [RFC5083]を利用しています。特に、signed-data、enveloped-data、およびauthentication-enveloped-dataのコンテンツタイプが使用されます。このドキュメントでは、S / MIMEのCNSA Suiteコンプライアンスのみを扱います。 CMSの他のアプリケーションは、このドキュメントの範囲外です。

This document does not define any new cryptographic algorithm suites; instead, it defines a CNSA-compliant profile of S/MIME. Since many of the CNSA Suite algorithms enjoy uses in other environments as well, the majority of the conventions needed for these algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support the CNSA Suite. Where details have been repeated, the cited documents are authoritative.

このドキュメントでは、新しい暗号化アルゴリズムスイートを定義していません。代わりに、CNSA準拠のS / MIMEプロファイルを定義します。 CNSA Suiteアルゴリズムの多くは他の環境でも使用できるため、これらのアルゴリズムに必要な規則の大部分はすでに他のドキュメントで指定されています。このドキュメントは、CNSA Suiteのサポートを選択する開発者を支援するために繰り返される関連詳細の一部とともに、これらの規則の出典を参照しています。詳細が繰り返されている場合、引用された文書は信頼できるものです。

1.1. Terminology

1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. The Commercial National Security Algorithm Suite

2. 商用国家安全保障アルゴリズムスイート

The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance both to assist with the US Government transition to new algorithms and to provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration.

国家安全保障局（NSA）は、米国政府の国家安全保障システムのための安全で相互運用可能な通信をサポートするという使命の一環として、商用暗号アルゴリズムとプロトコルをプロファイルしています。この目的のために、新しいアルゴリズムへの米国政府の移行を支援し、ベンダー（およびインターネットコミュニティ全般）に適切な使用と構成に関する情報を提供するためのガイダンスを発行しています。

Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their cybersecurity interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.

最近、暗号化の移行計画は、暗号化に関連する量子コンピューターの開発の見通しに影を落としました。 NSAは商用の国家安全保障アルゴリズム（CNSA）スイートを確立して、サイバーセキュリティの相互運用性の要件を満たすベンダーとITユーザーに近い将来の柔軟性を提供します。この柔軟性の背後にある目的は、近い将来量子耐性暗号に移行する必要があると予想されるため、ベンダーと顧客が比較的短い時間枠で2つの主要な移行を行うことを回避することです。

The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems.

NSAは、IETFプロトコルで一般的に利用可能な特定の商用アルゴリズムの使用に関する最新のガイダンスを提供するために、これを含む一連のRFCを作成しています。これらのRFCは、他のRFCおよび暗号化ガイダンス（NIST特別出版物など）と組み合わせて使用して、米国政府の国家安全保障システムのインターネットトラフィックと保管データを適切に保護できます。

3. Requirements and Assumptions

3. 要件と前提条件

CMS values are generated using ASN.1 [X208], the Basic Encoding Rules (BER) [X209], and the Distinguished Encoding Rules (DER) [X509].

CMS値は、ASN.1 [X208]、Basic Encoding Rules（BER）[X209]、Distinguished Encoding Rules（DER）[X509]を使用して生成されます。

The elliptic curve used in the CNSA Suite is specified in [FIPS186] and appears in the literature under two different names. For the sake of clarity, we list both names below:

CNSA Suiteで使用される楕円曲線は[FIPS186]で指定されており、2つの異なる名前で文献に記載されています。わかりやすくするために、両方の名前を以下に示します。

   +----------+-----------+-----------+---------------+
   | Curve    | NIST Name | SECG Name | OID [FIPS186] |
   +==========+===========+===========+===============+
   | nistp384 | P-384     | secp384r1 | 1.3.132.0.34  |
   +----------+-----------+-----------+---------------+

Table 1

表1

For CNSA Suite applications, public key certificates used to verify S/MIME signatures MUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) profile specified in [RFC8603].

CNSA Suiteアプリケーションの場合、S / MIME署名の検証に使用される公開鍵証明書は、[RFC8603]で指定されているCNSA Suite証明書および証明書失効リスト（CRL）プロファイルに準拠している必要があります。

Within the CMS signed-data content type, signature algorithm identifiers are located in the signatureAlgorithm field of SignerInfo structures contained within the SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes. Specific requirements for digital signatures are given in Section 5; compliant implementations MUST consider signatures not meeting these requirements as invalid.

CMS署名付きデータコンテンツタイプ内では、署名アルゴリズム識別子は、SignedData内に含まれるSignerInfo構造のsignatureAlgorithmフィールドにあります。さらに、署名アルゴリズム識別子は、副署名属性のSignerInfo signatureAlgorithmフィールドにあります。デジタル署名の具体的な要件は、セクション5に記載されています。準拠した実装は、これらの要件を満たさない署名を無効と見なさなければなりません（MUST）。

Implementations based on Elliptic Curve Cryptography (ECC) also require specification of schemes for key derivation and key wrap. Requirements for these schemes are in Sections 6.1.1 and 6.1.2, respectively.

Elliptic Curve Cryptography（ECC）に基づく実装では、キー導出とキーラップのスキームの仕様も必要です。これらのスキームの要件は、それぞれセクション6.1.1および6.1.2にあります。

RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 bits, respectively.

RSA鍵のペア（公開、秘密）は、ビット単位で表される係数サイズによって識別されます。 RSA-3072およびRSA-4096は、それぞれ3072ビットおよび4096ビットの係数を使用して計算されます。

RSA signature key pairs used in CNSA Suite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2^(16) < e < 2^(256) and be odd per [FIPS186].

CNSA Suite準拠の実装で使用されるRSA署名鍵ペアは、RSA-3072またはRSA-4096のいずれかです。 RSA指数eは2 ^（16）<e <2 ^（256）を満たし、[FIPS186]ごとに奇数でなければなりません。

It is recognized that, while the vast majority of RSA signatures are currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certificates will be issued in accordance with [RFC8603], and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's RSA key pair can be used to generate and validate signatures appropriate for either signing scheme. Where use of RSASSA-PSS is indicated in this document, the parameters in Section 5.2.2 apply.

現在、RSA署名の大部分はRSASSA-PKCS1-v1_5アルゴリズムを使用して作成されていますが、新しいアプリケーションに推奨されるRSA署名方式はRSASSA-PSSです。 CNSA Suite準拠のX.509証明書は[RFC8603]に従って発行され、これらの証明書はRSASSA-PKCS1-v1_5を使用して署名および検証される必要がありますが、サブジェクトのRSA鍵ペアを使用して、いずれかに適切な署名を生成および検証できます署名スキーム。このドキュメントでRSASSA-PSSの使用が示されている場合、セクション5.2.2のパラメーターが適用されます。

This document assumes that the required trust anchors have been securely provisioned to the client.

このドキュメントでは、必要なトラストアンカーがクライアントに安全にプロビジョニングされていることを前提としています。

All implementations use SHA-384 for hashing and either AES-CBC or AES-GCM for encryption, the requirements for which are given in Section 4 and Section 7, respectively.

すべての実装では、ハッシュにSHA-384を使用し、暗号化にAES-CBCまたはAES-GCMを使用します。これらの要件は、それぞれセクション4およびセクション7に記載されています。

4. SHA-384 Message Digest Algorithm

4. SHA-384メッセージダイジェストアルゴリズム

SHA-384 is the sole CNSA Suite message digest algorithm. [RFC5754] specifies the conventions for using SHA-384 with the Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations MUST follow the conventions in [RFC5754].

SHA-384は、唯一のCNSA Suiteメッセージダイジェストアルゴリズムです。 [RFC5754]は、暗号化メッセージ構文（CMS）でSHA-384を使用するための規則を指定しています。 CNSA Suite準拠のS / MIME実装は、[RFC5754]の規則に従う必要があります。

Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field.

CMS署名付きデータコンテンツタイプ内では、メッセージダイジェストアルゴリズム識別子はSignedData digestAlgorithmsフィールドとSignerInfo digestAlgorithmフィールドにあります。

The SHA-384 message digest algorithm is defined in FIPS Pub 180 [FIPS180]. The algorithm identifier for SHA-384 is defined in [RFC5754] as follows:

SHA-384メッセージダイジェストアルゴリズムは、FIPS Pub 180 [FIPS180]で定義されています。 SHA-384のアルゴリズム識別子は、[RFC5754]で次のように定義されています。

         id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
             country(16) us(840) organization(1) gov(101) csor(3)
             nistalgorithm(4) hashalgs(2) 2 }

For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL, and if present, the parameters field MUST contain a NULL. As specified in [RFC5754], implementations MUST generate SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-384 AlgorithmIdentifiers with absent parameters or with NULL parameters.

SHA-384の場合、AlgorithmIdentifierパラメーターフィールドはオプションであり、存在する場合、パラメーターフィールドにはNULLが含まれている必要があります。 [RFC5754]で指定されているように、実装では、パラメータのないSHA-384 AlgorithmIdentifierを生成する必要があります。実装は、パラメーターがないか、またはNULLパラメーターを持つSHA-384 AlgorithmIdentifierを受け入れる必要があります。

5. Digital Signature

5. デジタル署名

5.1. ECDSA Signature

5.1. ECDSA署名

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Suite digital signature algorithm based on ECC. [RFC5753] specifies the conventions for using ECDSA with the Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations MUST follow the conventions in [RFC5753].

楕円曲線デジタル署名アルゴリズム（ECDSA）は、ECCに基づくCNSA Suiteデジタル署名アルゴリズムです。 [RFC5753]は、暗号化メッセージ構文（CMS）でECDSAを使用するための規則を指定します。 CNSA Suite準拠のS / MIME実装は、[RFC5753]の規則に従う必要があります。

[RFC5480] defines the signature algorithm identifier used in CMS for ECDSA with SHA-384 as follows:

[RFC5480]は、SHA-384を使用するECDSAのCMSで使用される署名アルゴリズム識別子を次のように定義します。

         ecdsa-with-SHA384  OBJECT IDENTIFIER  ::=  { iso(1)
            member-body(2) us(840) ansi-X9-62(10045) signatures(4)
            ecdsa-with-sha2(3) 3 }

When the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.

ecdsa-with-SHA384アルゴリズム識別子を使用する場合、AlgorithmIdentifierパラメータフィールドは存在しない必要があります。

When signing, the ECDSA algorithm generates two values, commonly called r and s. These two values MUST be encoded using the ECDSA-Sig-Value type specified in [RFC5480]:

署名時に、ECDSAアルゴリズムは、一般にrおよびsと呼ばれる2つの値を生成します。これらの2つの値は、[RFC5480]で指定されているECDSA-Sig-Valueタイプを使用してエンコードする必要があります。

         ECDSA-Sig-Value  ::=  SEQUENCE {
            r  INTEGER,
            s  INTEGER }

5.2. RSA Signature

5.2. RSA署名

The RSA signature generation process and the encoding of the result is either RSASSA-PKCS1-v1_5 or RSA-PSS, as described in detail in PKCS #1 version 2.2 [RFC8017].

PKCS＃1バージョン2.2 [RFC8017]で詳細に説明されているように、RSA署名生成プロセスと結果のエンコードはRSASSA-PKCS1-v1_5またはRSA-PSSのいずれかです。

5.2.1. RSA-PKCS1-v1_5

5.2.1. RSA PKCS1-v1_5

[RFC5754] defines the signature algorithm identifier used in CMS for an RSA signature with SHA-384 as follows:

[RFC5754]は、CMSでSHA-384を使用したRSA署名に使用される署名アルゴリズム識別子を次のように定義します。

         sha384WithRSAEncryption  OBJECT IDENTIFIER  ::= { iso(1)
           member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }

When the sha384WithRSAEncryption algorithm identifier is used, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present.

sha384WithRSAEncryptionアルゴリズム識別子を使用する場合、パラメーターはNULLでなければなりません。実装は、存在するだけでなく、存在しないパラメーターを受け入れる必要があります。

5.2.2. RSA-PSS

[RFC4056] defines the signature algorithm identifier used in CMS for an RSA-PSS signature as follows (presented here in expanded form):

[RFC4056]は、RSA-PSS署名のCMSで使用される署名アルゴリズム識別子を次のように定義します（ここでは展開形式で示します）。

         RSASSA-PSS  OBJECT IDENTIFIER  ::= { iso(1)
           member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }

The parameters field of an AlgorithmIdentifier that identifies RSASSA-PSS is defined in [RFC4055] as follows:

RSASSA-PSSを識別するAlgorithmIdentifierのパラメータフィールドは、[RFC4055]で次のように定義されています。

          RSASSA-PSS-params  ::=  SEQUENCE  {
             hashAlgorithm      [0] HashAlgorithm DEFAULT
                                       sha1Identifier,
             maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
                                       mgf1SHA1Identifier,
             saltLength         [2] INTEGER DEFAULT 20,
             trailerField       [3] INTEGER DEFAULT 1  }

The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-params with the following values:

AlgorithmIdentifierパラメーターフィールドには、次の値を持つRSASSA-PSS-paramsが含まれている必要があります。

* The hash algorithm MUST be id-sha384 as defined in [RFC8017];

* [RFC8017]で定義されているように、ハッシュアルゴリズムはid-sha384でなければなりません。

* The mask generation function MUST use the algorithm identifier mfg1SHA384Identifier as defined in [RFC4055];

* マスク生成関数は、[RFC4055]で定義されているアルゴリズム識別子mfg1SHA384Identifierを使用する必要があります。

* The salt length MUST be 48 octets (the same length as the SHA-384 output); and

* ソルトの長さは48オクテットでなければなりません（SHA-384出力と同じ長さ）。そして

* The trailerField MUST have value 1.

* TrailerFieldの値は1でなければなりません。

6. Key Establishment

6. 重要な確立

6.1. Elliptic Curve Key Agreement

6.1. 楕円曲線の鍵の一致

Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement algorithm. Since S/MIME is used in store-and-forward communications, ephemeral-static ECDH is always employed. This means that the message originator possesses an ephemeral ECDH key pair and that the message recipient possesses a static ECDH key pair whose public key is provided in an X.509 certificate. The certificate used to obtain the recipient's public key MUST be compliant with [RFC8603].

Elliptic Curve Diffie-Hellman（ECDH）は、CNSA Suiteの鍵合意アルゴリズムです。 S / MIMEはストアアンドフォワード通信で使用されるため、一時的な静的ECDHが常に使用されます。つまり、メッセージの発信者はエフェメラルECDHキーペアを所有し、メッセージの受信者はX.509証明書で公開キーが提供される静的ECDHキーペアを所有しています。受信者の公開鍵を取得するために使用される証明書は、[RFC8603]に準拠している必要があります。

When a key agreement algorithm is used, the following steps are performed:

鍵合意アルゴリズムを使用すると、次の手順が実行されます。

1. A content-encryption key (CEK) for a particular content-encryption algorithm is generated at random.

1. 特定のコンテンツ暗号化アルゴリズムのコンテンツ暗号化キー（CEK）はランダムに生成されます。

2. The recipient's public key and sender's private key are used with a key agreement scheme to generate a shared secret (Z).

2. 受信者の公開鍵と送信者の秘密鍵は、共有秘密（Z）を生成するための鍵合意スキームとともに使用されます。

3. The shared secret is used with a key derivation function (KDF) to produce a key-encryption key (KEK).

3. 共有秘密は、鍵導出関数（KDF）とともに使用され、鍵暗号鍵（KEK）を生成します。

4. The KEK is used with a key wrap algorithm to encrypt the CEK.

4. KEKは、CEKを暗号化するための鍵ラップアルゴリズムとともに使用されます。

Key derivation is discussed in Section 6.1.1. Key wrapping is discussed in Section 6.1.2.

鍵の導出については、セクション6.1.1で説明します。鍵の折り返しについては、セクション6.1.2で説明します。

Section 3.1 of [RFC5753] specifies the conventions for using ECDH with the CMS. CNSA Suite-compliant S/MIME implementations MUST follow these conventions.

[RFC5753]のセクション3.1は、CMSでECDHを使用するための規則を指定しています。 CNSA Suite準拠のS / MIME実装は、これらの規則に従う必要があります。

Within the CMS enveloped-data and authenticated-enveloped-data content types, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.

CMSエンベロープデータおよび認証済みエンベロープデータのコンテンツタイプ内では、鍵合意アルゴリズム識別子はEnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールドにあります。

The keyEncryptionAlgorithm field comprises two fields, an algorithm field and a parameter field. The algorithm field MUST identify dhSinglePass-stdDH-sha384kdf-scheme. The algorithm identifier for the dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4 of [RFC5753], is (presented here in expanded form):

keyEncryptionAlgorithmフィールドは、アルゴリズムフィールドとパラメータフィールドの2つのフィールドで構成されます。アルゴリズムフィールドは、dhSinglePass-stdDH-sha384kdf-schemeを識別する必要があります。 [RFC5753]のセクション7.1.4から繰り返されたdhSinglePass-stdDH-sha384kdf-schemeのアルゴリズム識別子は、次のとおりです（ここでは展開形式で示しています）。

         dhSinglePass-stdDH-sha384kdf-scheme  OBJECT IDENTIFIER  ::=
             { iso(1) identified-organization(3) certicom(132)
               schemes(1) 11 2 }

The keyEncryptionAlgorithm parameter field MUST be constructed as described in Section 6.1.2.

keyEncryptionAlgorithmパラメータフィールドは、セクション6.1.2の説明に従って構築する必要があります。

6.1.1. Key Derivation Functions

6.1.1. 主要な派生関数

KDFs based on SHA-384 are used to derive a pairwise key-encryption key from the shared secret produced by ephemeral-static ECDH. Sections 7.1.8 and 7.2 in [RFC5753] specify the CMS conventions for using a KDF with the shared secret generated during ephemeral-static ECDH. CNSA Suite-compliant S/MIME implementations MUST follow these conventions.

SHA-384に基づくKDFは、一時的な静的ECDHによって生成された共有秘密からペアワイズキー暗号化キーを導出するために使用されます。 [RFC5753]のセクション7.1.8および7.2は、一時的静的ECDH中に生成された共有秘密でKDFを使用するためのCMS規則を指定します。 CNSA Suite準拠のS / MIME実装は、これらの規則に従う必要があります。

As specified in Section 7.1.8 of [RFC5753], the ANSI-X9.63-KDF described in Section 3.6.1 of [SEC1] and based on SHA-384 MUST be used.

[RFC5753]のセクション7.1.8で指定されているように、[SEC1]のセクション3.6.1で説明され、SHA-384に基づくANSI-X9.63-KDFを使用する必要があります。

As specified in Section 7.2 of [RFC5753], when using ECDH with the CMS enveloped-data or authenticated-enveloped-data content type, the derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo type:

[RFC5753]のセクション7.2で指定されているように、CMSエンベロープデータまたは認証済みエンベロープデータのコンテンツタイプでECDHを使用する場合、キー暗号化キーの派生では、ECC-CMS-SharedInfoタイプを使用します。

         ECC-CMS-SharedInfo  ::=  SEQUENCE {
            keyInfo      AlgorithmIdentifier,
            entityUInfo  [0] EXPLICIT OCTET STRING OPTIONAL,
            suppPubInfo  [2] EXPLICIT OCTET STRING }

In the CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used as follows:

CNSA Suite for S / MIMEでは、ECC-CMS-SharedInfoのフィールドは次のように使用されます。

* keyInfo contains the object identifier of the key-encryption algorithm used to wrap the content-encryption key. If AES-256 Key Wrap is used, then the keyInfo will contain id-aes256-wrap-pad, and the parameters will be absent.

* keyInfoには、コンテンツ暗号化キーのラップに使用されるキー暗号化アルゴリズムのオブジェクト識別子が含まれています。 AES-256キーラップが使用されている場合、keyInfoにはid-aes256-wrap-padが含まれ、パラメーターは存在しません。

* entityUInfo optionally contains a random value provided by the message originator. If user keying material (ukm) is included in the KeyAgreeRecipientInfo, then the entityUInfo MUST be present, and it MUST contain the ukm value. If the ukm is not present, then the entityUInfo MUST be absent.

* entityUInfoにはオプションで、メッセージの発信者から提供されたランダムな値が含まれます。ユーザーのキー情報（ukm）がKeyAgreeRecipientInfoに含まれている場合、entityUInfoが存在しなければならず、ukm値を含んでいる必要があります。 ukmが存在しない場合、entityUInfoは存在しない必要があります。

* suppPubInfo contains the length of the generated key-encryption key in bits, represented as a 32-bit unsigned number, as described in [RFC2631]. When a 256-bit AES key is used, the length MUST be 0x00000100.

* [RFC2631]で説明されているように、suppPubInfoには、生成されたキー暗号化キーの長さが32ビットの符号なし数値として表されるビット単位で含まれています。 256ビットのAESキーが使用される場合、長さは0x00000100でなければなりません。

ECC-CMS-SharedInfo is DER encoded and is used as input to the key derivation function, as specified in Section 3.6.1 of [SEC1]. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in [RFC2631]. Here, a counter value is not included in the keyInfo field because the KDF specified in [SEC1] ensures that sufficient keying data is provided.

[SEC1]のセクション3.6.1で指定されているように、ECC-CMS-SharedInfoはDERエンコードされ、鍵導出関数への入力として使用されます。 ECC-CMS-SharedInfoは、[RFC2631]で指定されているOtherInfoとは異なることに注意してください。ここで、[SEC1]で指定されたKDFが十分なキーイングデータが提供されることを保証するため、カウンター値はkeyInfoフィールドに含まれていません。

The KDF specified in Section 3.6.1 of [SEC1] describes how to generate an essentially arbitrary amount of keying material from a shared secret, Z, produced by ephemeral-static ECDH. To generate an L-bit key-encryption key (KEK), blocks of key material (KM) are computed by incrementing Counter appropriately until enough material has been generated:

[SEC1]のセクション3.6.1で指定されているKDFは、一時的な静的ECDHによって生成された共有シークレットZから本質的に任意の量のキー生成情報を生成する方法を説明しています。 Lビットキー暗号化キー（KEK）を生成するには、十分なマテリアルが生成されるまで、カウンターを適切にインクリメントして、キーマテリアル（KM）のブロックを計算します。

KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )

KM（Counter）= Hash（Z || Counter || ECC-CMS-SharedInfo）

The KM blocks are concatenated left to right as they are generated, and the first (leftmost) L bits are used as the KEK:

KMブロックは生成時に左から右に連結され、最初（左端）のLビットがKEKとして使用されます。

KEK = the leftmost L bits of [KM ( counter=1 ) || KM ( counter=2 ) ...]

KEK = [KM（counter = 1）の左端のLビット|| KM（カウンター= 2）...]

In the CNSA Suite for S/MIME, the elements of the KDF are defined as follows:

CNSA Suite for S / MIMEでは、KDFの要素は次のように定義されています。

* Hash is a one-way hash function. The SHA-384 hash MUST be used.

* ハッシュは一方向のハッシュ関数です。 SHA-384ハッシュを使用する必要があります。

* Z is the shared secret value generated during ephemeral-static ECDH. Z MUST be exactly 384 bits, i.e., leading zero bits MUST be preserved.

* Zは、一時的な静的ECDH中に生成される共有秘密値です。 Zは正確に384ビットにする必要があります。つまり、先行ゼロビットを保持する必要があります。

* Counter is a 32-bit unsigned number represented in network byte order. Its initial value MUST be 0x00000001 for any key derivation operation.

* カウンタは、ネットワークバイトオーダーで表される32ビットの符号なし数値です。鍵導出操作では、その初期値を0x00000001にする必要があります。

* ECC-CMS-SharedInfo is composed as described above. It MUST be DER encoded.

* ECC-CMS-SharedInfoは、上記のように構成されています。 DERエンコードする必要があります。

In the CNSA Suite for S/MIME, exactly one iteration is needed; the Counter is not incremented. The key-encryption key (KEK) MUST be the first (leftmost) 256 bits of the SHA-384 output value:

CNSA Suite for S / MIMEでは、正確に1回の反復が必要です。カウンターは増分されません。鍵暗号鍵（KEK）は、SHA-384出力値の最初（左端）の256ビットである必要があります。

KEK = the leftmost 256 bits of SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )

KEK = SHA-384の左端の256ビット（Z || 0x00000001 || ECC-CMS-SharedInfo）

Note that the only source of secret entropy in this computation is Z.

この計算における秘密のエントロピーの唯一のソースはZであることに注意してください。

6.1.2. AES Key Wrap

6.1.2. AESキーラップ

The AES Key Wrap with Padding key-encryption algorithm, as specified in [RFC5649] and [SP80038F], is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. Section 8 of [RFC5753] specifies the CMS conventions for using AES Key Wrap with a pairwise key generated through ephemeral-static ECDH. CNSA Suite-compliant S/MIME implementations MUST follow these conventions.

[RFC5649]と[SP80038F]で指定されている、AES Key Wrap with Paddingキー暗号化アルゴリズムを使用して、一時的静的ECDHを使用して生成されるペアワイズキー暗号化キーでコンテンツ暗号化キーを暗号化します。 [RFC5753]のセクション8は、AESキーラップを短命静的ECDHによって生成されたペアワイズキーで使用するためのCMS規則を指定しています。 CNSA Suite準拠のS / MIME実装は、これらの規則に従う必要があります。

Within the CMS enveloped-data content type, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.

CMSのエンベロープデータコンテンツタイプ内では、キーラップアルゴリズム識別子は、EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールド内のKeyWrapAlgorithmパラメータにあります。

The KeyWrapAlgorithm MUST be id-aes256-wrap-pad. The required algorithm identifier, specified in [RFC5649], is:

KeyWrapAlgorithmはid-aes256-wrap-padでなければなりません。 [RFC5649]で指定されている必要なアルゴリズム識別子は次のとおりです。

         id-aes256-wrap-pad  OBJECT IDENTIFIER ::=  { joint-iso-itu-t(2)
            country(16) us(840) organization(1) gov(101) csor(3)
            nistAlgorithm(4) aes(1) 48 }

6.2. RSA Key Transport

6.2. RSAキートランスポート

RSA encryption (RSA) is the CNSA Suite key transport algorithm. The RSA key transport algorithm is the RSA encryption scheme defined in [RFC8017], where the message to be encrypted is the content-encryption key.

RSA暗号化（RSA）は、CNSA Suiteの鍵転送アルゴリズムです。 RSAキートランスポートアルゴリズムは、[RFC8017]で定義されているRSA暗号化スキームであり、暗号化されるメッセージはコンテンツ暗号化キーです。

The recipient of an S/MIME message possesses an RSA key pair whose public key is represented by an X.509 certificate. The certificate used to obtain the recipient's public key MUST be compliant with [RFC8603]. These certificates are suitable for use with either RSAES-OAEP or RSAES-PKCS1-v1_5.

S / MIMEメッセージの受信者は、公開鍵がX.509証明書で表されるRSA鍵ペアを所有しています。受信者の公開鍵を取得するために使用される証明書は、[RFC8603]に準拠している必要があります。これらの証明書は、RSAES-OAEPまたはRSAES-PKCS1-v1_5での使用に適しています。

6.2.1. RSAES-PKCS1-v1_5

Section 4.2 of [RFC3370] specifies the conventions for using RSAES-PKCS1-v1_5 with the CMS. S/MIME implementations employing this form of key transport MUST follow these conventions.

[RFC3370]のセクション4.2は、CMSでRSAES-PKCS1-v1_5を使用するための規則を指定しています。この形式のキー転送を使用するS / MIME実装は、これらの規則に従う必要があります。

Within the CMS enveloped-data and authenticated-enveloped-data content types, key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.

CMSエンベロープデータおよび認証済みエンベロープデータのコンテンツタイプ内では、キー転送アルゴリズムの識別子はEnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithmフィールドにあります。

The algorithm identifier for RSA (PKCS #1 v1.5) is:

RSA（PKCS＃1 v1.5）のアルゴリズム識別子は次のとおりです。

         rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL.

AlgorithmIdentifierパラメータフィールドが存在しなければならず、パラメータフィールドはNULLを含んでいる必要があります。

6.2.2. RSAES-OAEP

[RFC3560] specifies the conventions for using RSAES-OAEP with the CMS. CNSA Suite-compliant S/MIME implementations employing this form of key transport MUST follow these conventions.

[RFC3560]は、CMSでRSAES-OAEPを使用するための規則を指定します。この形式のキー転送を使用するCNSA Suite準拠のS / MIME実装は、これらの規則に従う必要があります。

The algorithm identifier for RSA (OAEP) is:

RSA（OAEP）のアルゴリズム識別子は次のとおりです。

         id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }

The parameters field of an AlgorithmIdentifier that identifies RSAES-OAEP is defined in [RFC4055] as follows:

RSAES-OAEPを識別するAlgorithmIdentifierのパラメータフィールドは、[RFC4055]で次のように定義されています。

          RSAES-OAEP-params  ::=  SEQUENCE  {
             hashFunc          [0] AlgorithmIdentifier DEFAULT
                                      sha1Identifier,
             maskGenFunc       [1] AlgorithmIdentifier DEFAULT
                                      mgf1SHA1Identifier,
             pSourceFunc       [2] AlgorithmIdentifier DEFAULT
                                      pSpecifiedEmptyIdentifier  }

          pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
                               { id-pSpecified, nullOctetString }

          nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain RSAES-OAEP-params with values as follows:

AlgorithmIdentifierパラメーターフィールドが存在する必要があり、パラメーターフィールドには、次の値を持つRSAES-OAEP-paramsが含まれている必要があります。

* The hashFunc algorithm must be id-sha384 as defined in [RFC8017];

* [RFC8017]で定義されているように、hashFuncアルゴリズムはid-sha384でなければなりません。

* The mask generation function must use the algorithm identifier mfg1SHA384Identifier as defined in [RFC4055];

* マスク生成関数は、[RFC4055]で定義されているアルゴリズム識別子mfg1SHA384Identifierを使用する必要があります。

* The pSourceFunc field must be absent.

* pSourceFuncフィールドは存在しない必要があります。

The SMIMECapabilities signed attribute is used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. If the SMIMECapabilities signed attribute is included to announce support for the RSAES-OAEP algorithm, it MUST be constructed as defined in Section 5 of [RFC3560], with the sequence representing the rSAES-OAEP-SHA384-Identifier.

SMIMECapabilities署名済み属性は、SMIMECapabilitiesを通知するソフトウェアがサポートできるアルゴリズムの部分的なリストを指定するために使用されます。 RSAES-OAEPアルゴリズムのサポートをアナウンスするためにSMIMECapabilities署名属性が含まれている場合は、[RFC3560]のセクション5で定義されているように、rSAES-OAEP-SHA384-Identifierを表すシーケンスを使用して構築する必要があります。

7. Content Encryption

7. コンテンツの暗号化

AES-GCM is the preferred mode for CNSA Suite applications, as described in the Security Considerations (Section 8). AES-CBC is acceptable where AES-GCM is not yet available.

AES-GCMは、セキュリティの考慮事項（セクション8）で説明されているように、CNSA Suiteアプリケーションの優先モードです。 AES-CCMは、AES-GCMがまだ利用できない場合に受け入れられます。

7.1. AES-GCM Content Encryption

7.1. AES-GCMコンテンツ暗号化

CNSA Suite-compliant S/MIME implementations using the authenticated-enveloped-data content type [RFC5083] MUST use AES [FIPS197] in Galois Counter Mode (GCM) [SP80038D] as the content-authenticated encryption algorithm and MUST follow the conventions for using AES-GCM with the CMS defined in [RFC5084].

CNSA Suite準拠のS / MIME実装では、authenticated-enveloped-dataコンテンツタイプ[RFC5083]を使用して、コンテンツ認証暗号化アルゴリズムとしてGalois Counter Mode（GCM）[SP80038D]でAES [FIPS197]を使用する必要があり、使用に関する規則に従う必要があります。 [RFC5084]で定義されているCMSを使用したAES-GCM。

Within the CMS authenticated-enveloped-data content type, content-authenticated encryption algorithm identifiers are located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-authenticated encryption algorithm is used to encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field.

CMS authentication-enveloped-dataコンテンツタイプ内で、コンテンツ認証された暗号化アルゴリズム識別子はAuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithmフィールドにあります。コンテンツ認証された暗号化アルゴリズムは、AuthEnvelopedData EncryptedContentInfo encryptedContentフィールドにあるコンテンツを暗号化するために使用されます。

The AES-GCM content-authenticated encryption algorithm is described in [FIPS197] and [SP80038D]. The algorithm identifier for AES-256 in GCM mode is:

AES-GCMコンテンツ認証暗号化アルゴリズムは、[FIPS197]および[SP80038D]で説明されています。 GCMモードのAES-256のアルゴリズム識別子は次のとおりです。

            id-aes256-GCM  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
               country(16) us(840) organization(1) gov(101) csor(3)
               nistAlgorithm(4) aes(1) 46 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain GCMParameters:

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

         GCMParameters ::= SEQUENCE {
           aes-nonce        OCTET STRING,
           aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

The authentication tag length (aes-ICVlen) SHALL be 16 (indicating a tag length of 128 bits).

認証タグの長さ（aes-ICVlen）は16でなければなりません（128ビットのタグの長さを示します）。

The initialization vector (aes-nonce) MUST be generated in accordance with Section 8.2 of [SP80038D]. AES-GCM loses security catastrophically if a nonce is reused with a given key on more than one distinct set of input data. Therefore, a fresh content-authenticated encryption key MUST be generated for each message.

[SP80038D]のセクション8.2に従って、初期化ベクトル（aes-nonce）を生成する必要があります。 AES-GCMは、ナンスが指定されたキーで複数の異なる入力データのセットで再利用されると、壊滅的にセキュリティを失います。したがって、メッセージごとに新しいコンテンツ認証済みの暗号化キーを生成する必要があります。

7.2. AES-CBC Content Encryption

7.2. AES-CBCコンテンツ暗号化

CNSA Suite-compliant S/MIME implementations using the enveloped-data content type MUST use AES-256 [FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] as the content-encryption algorithm and MUST follow the conventions for using AES with the CMS defined in [RFC3565].

エンベロープデータコンテンツタイプを使用するCNSA Suite準拠のS / MIME実装は、コンテンツ暗号化アルゴリズムとして暗号ブロックチェーン（CBC）モード[SP80038A]でAES-256 [FIPS197]を使用する必要があり、AESを[RFC3565]で定義されているCMS。

Within the CMS enveloped-data content type, content-encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-encryption algorithm is used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field.

CMSエンベロープデータコンテンツタイプ内では、コンテンツ暗号化アルゴリズム識別子はEnvelopedData EncryptedContentInfo contentEncryptionAlgorithmフィールドにあります。コンテンツ暗号化アルゴリズムは、EnvelopedData EncryptedContentInfo encryptedContentフィールドにあるコンテンツを暗号化するために使用されます。

The AES-CBC content-encryption algorithm is described in [FIPS197] and [SP80038A]. The algorithm identifier for AES-256 in CBC mode is:

AES-CBCコンテンツ暗号化アルゴリズムは、[FIPS197]と[SP80038A]で説明されています。 CBCモードのAES-256のアルゴリズム識別子は次のとおりです。

         id-aes256-CBC  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
            country(16) us(840) organization(1) gov(101) csor(3)
            nistAlgorithm(4) aes(1) 42 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain AES-IV:

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

         AES-IV  ::=  OCTET STRING (SIZE(16))

The 16-octet initialization vector is generated at random by the originator. See [RFC4086] for guidance on generation of random values.

16オクテットの初期化ベクトルは、発信者によってランダムに生成されます。ランダム値の生成に関するガイダンスについては、[RFC4086]を参照してください。

8. Security Considerations

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

This document specifies the conventions for using the NSA's CNSA Suite algorithms in S/MIME. All of the algorithms and algorithm identifiers have been specified in previous documents.

このドキュメントは、S / MIMEでNSAのCNSA Suiteアルゴリズムを使用するための規則を指定します。すべてのアルゴリズムとアルゴリズム識別子は、以前のドキュメントで指定されています。

See [RFC4086] for guidance on generation of random values.

ランダム値の生成に関するガイダンスについては、[RFC4086]を参照してください。

The security considerations in [RFC5652] discuss the CMS as a method for digitally signing data and encrypting data.

[RFC5652]のセキュリティに関する考慮事項では、データにデジタル署名し、データを暗号化する方法としてのCMSについて説明しています。

The security considerations in [RFC3370] discuss cryptographic algorithm implementation concerns in the context of the CMS.

[RFC3370]のセキュリティに関する考慮事項では、CMSのコンテキストでの暗号化アルゴリズムの実装に関する問題について説明しています。

The security considerations in [RFC5753] discuss the use of elliptic curve cryptography (ECC) in the CMS.

[RFC5753]のセキュリティに関する考慮事項では、CMSでの楕円曲線暗号（ECC）の使用について説明しています。

The security considerations in [RFC3565] discuss the use of AES in the CMS.

[RFC3565]のセキュリティに関する考慮事項では、CMSでのAESの使用について説明しています。

The security considerations in [RFC8551] apply to this profile, particularly the recommendation to use authenticated encryption modes (i.e., use authenticated-enveloped-data with AES-GCM rather than enveloped-data with AES-CBC).

[RFC8551]のセキュリティに関する考慮事項がこのプロファイルに適用されます。特に、認証された暗号化モードを使用することが推奨されます（つまり、AES-CBCでエンベロープされたデータではなく、AES-GCMでauthentication-enveloped-dataを使用します）。

9. IANA Considerations

9. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[CNSA] Committee for National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSS Policy 15, October 2016, <https://www.cnss.gov/CNSS/Issuances/Policies.cfm>.

[CNSA]国家安全保障システム委員会、「安全な情報共有のための公的基準の使用」、2016年10月のCNSSポリシー15、<https://www.cnss.gov/CNSS/Issuances/Policies.cfm>。

[FIPS180] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard 180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/ final>.

[FIPS180]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、連邦情報処理標準180-4、2015年8月、<https://csrc.nist.gov/publications/detail/fips/180/4 / final>。

[FIPS186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, FIPS PUB 186-4, July 2013, <https://csrc.nist.gov/publications/detail/fips/186/4/ final>.

[FIPS186]米国国立標準技術研究所、「デジタル署名標準（DSS）」、DOI 10.6028 / NIST.FIPS.186-4、FIPS PUB 186-4、2013年7月、<https://csrc.nist.gov/出版物/詳細/ fips / 186/4 /最終>。

[FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", DOI 10.6028/NIST.FIPS.197, FIPS PUB 197, November 2001, <https://csrc.nist.gov/publications/detail/fips/197/ final>.

[FIPS197]米国国立標準技術研究所、「Advanced Encryption Standard（AES）」、DOI 10.6028 / NIST.FIPS.197、FIPS PUB 197、2001年11月、<https://csrc.nist.gov/publications/detail/ fips / 197 / final>。

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

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

[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <https://www.rfc-editor.org/info/rfc2631>.

[RFC2631] Rescorla、E。、「Diffie-Hellman Key Agreement Method」、RFC 2631、DOI 10.17487 / RFC2631、1999年6月、<https://www.rfc-editor.org/info/rfc2631>。

[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, <https://www.rfc-editor.org/info/rfc3370>.

[RFC3370] Housley、R。、「Cryptographic Message Syntax（CMS）Algorithms」、RFC 3370、DOI 10.17487 / RFC3370、2002年8月、<https://www.rfc-editor.org/info/rfc3370>。

[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, DOI 10.17487/RFC3560, July 2003, <https://www.rfc-editor.org/info/rfc3560>.

[RFC3560] Housley、R。、「暗号化メッセージ構文（CMS）でのRSAES-OAEPキー転送アルゴリズムの使用」、RFC 3560、DOI 10.17487 / RFC3560、2003年7月、<https://www.rfc-editor.org / info / rfc3560>。

[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.

[RFC3565] Schaad、J。、「暗号化メッセージ構文（CMS）でのAdvanced Encryption Standard（AES）暗号化アルゴリズムの使用」、RFC 3565、DOI 10.17487 / RFC3565、2003年7月、<https：//www.rfc-editor .org / info / rfc3565>。

[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, <https://www.rfc-editor.org/info/rfc4055>.

[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムおよび識別子」、RFC 4055 、DOI 10.17487 / RFC4055、2005年6月、<https://www.rfc-editor.org/info/rfc4055>。

[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, <https://www.rfc-editor.org/info/rfc4056>.

[RFC4056] Schaad、J。、「暗号化メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用」、RFC 4056、DOI 10.17487 / RFC4056、2005年6月、<https://www.rfc-editor.org/ info / rfc4056>。

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

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

[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, <https://www.rfc-editor.org/info/rfc5084>.

[RFC5084] Housley、R。、「暗号化メッセージ構文（CMS）でのAES-CCMおよびAES-GCM認証済み暗号化の使用」、RFC 5084、DOI 10.17487 / RFC5084、2007年11月、<https：//www.rfc-editor .org / info / rfc5084>。

[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.

[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、DOI 10.17487 / RFC5480、2009年3月、< https://www.rfc-editor.org/info/rfc5480>。

[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-editor.org/info/rfc5649>.

[RFC5649] Housley、R。およびM. Dworkin、「Advanced Encryption Standard（AES）Key Wrap with Padding Algorithm」、RFC 5649、DOI 10.17487 / RFC5649、2009年9月、<https://www.rfc-editor.org/ info / rfc5649>。

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

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

[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.

[RFC5753]ターナーS.およびD.ブラウン、「Cryptographic Message Syntax（CMS）での楕円曲線暗号（ECC）アルゴリズムの使用」、RFC 5753、DOI 10.17487 / RFC5753、2010年1月、<https：//www.rfc -editor.org/info/rfc5753>。

[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.

[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、DOI 10.17487 / RFC5754、2010年1月、<https://www.rfc-editor.org/info/rfc5754>。

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.

[RFC8551] Schaad、J.、Ramsdell、B。、およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 4.0 Message Specification」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https： //www.rfc-editor.org/info/rfc8551>。

[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, DOI 10.17487/RFC8603, May 2019, <https://www.rfc-editor.org/info/rfc8603>.

[RFC8603] Jenkins、M。およびL. Zieglar、「Commercial National Security Algorithm（CNSA）Suite Certificate and Certificate Revocation List（CRL）Profile」、RFC 8603、DOI 10.17487 / RFC8603、2019年5月、<https：// www。 rfc-editor.org/info/rfc8603>。

[SEC1] Standards for Efficient Cryptography Group, "SEC1: Elliptic Curve Cryptography", May 2009, <https://www.secg.org/sec1-v2.pdf>.

[SEC1] Standards for Efficient Cryptography Group、「SEC1：Elliptic Curve Cryptography」、2009年5月、<https://www.secg.org/sec1-v2.pdf>。

[SP80038A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", DOI 10.6028/NIST.SP.800-38A, Special Publication 800-38A, December 2001, <https://csrc.nist.gov/publications/detail/ sp/800-38a/final>.

[SP80038A] Dworkin、M。、「ブロック暗号の動作モードの推奨：方法と手法」、DOI 10.6028 / NIST.SP.800-38A、特別刊行物800-38A、2001年12月、<https：//csrc.nist .gov / publications / detail / sp / 800-38a / final>。

[SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", DOI 10.6028/NIST.SP.800-38D, Special Publication 800-38D, November 2007, <https://csrc.nist.gov/publications/detail/ sp/800-38d/final>.

[SP80038D] Dworkin、M。、「ブロック暗号操作モードの推奨：ガロア/カウンターモード（GCM）およびGMAC」、DOI 10.6028 / NIST.SP.800-38D、特別刊行物800-38D、2007年11月、<https ：//csrc.nist.gov/publications/detail/ sp / 800-38d / final>。

[SP80038F] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping", DOI 10.6028/NIST.SP.800-38F, Special Publication 800-38F, December 2012, <https://csrc.nist.gov/publications/detail/ sp/800-38f/final>.

[SP80038F] Dworkin、M。、「ブロック暗号モードの操作の推奨：鍵ラッピングの方法」、DOI 10.6028 / NIST.SP.800-38F、特別刊行物800-38F、2012年12月、<https：// csrc。 nist.gov/publications/detail/sp/800-38f/final>。

[X208] CCITT, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, 1988, <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.

[X208] CCITT、「Specification of Abstract Syntax Notation One（ASN.1）」、CCITT Recommendation X.208、1988、<https://www.itu.int/rec/T-REC-X.208-198811- W / en>。

[X209] CCITT, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, 1988, <https://www.itu.int/rec/T-REC-X.209-198811-W/en>.

[X209] CCITT、「抽象構文記法1（ASN.1）の基本的なエンコーディングルールの仕様」、CCITT勧告X.209、1988、<https://www.itu.int/rec/T-REC-X。 209-198811-W / en>。

[X509] CCITT, "The Directory - Authentication Framework", CCITT Recommendation X.509, 1988, <https://www.itu.int/rec/T-REC-X.509-198811-S>.

[X509] CCITT、「The Directory-Authentication Framework」、CCITT勧告X.509、1988、<https://www.itu.int/rec/T-REC-X.509-198811-S>。

10.2. Informative References

10.2. 参考引用

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

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

[SP80059] Barker, W., "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, Special Publication 800-59, August 2003, <https://csrc.nist.gov/publications/detail/ sp/800-59/final>.

[SP80059] Barker、W.、「情報システムを国家安全保障システムとして特定するためのガイドライン」、DOI 10.6028 / NIST.SP.800-59、特別刊行物800-59、2003年8月、<https：//csrc.nist .gov / publications / detail / sp / 800-59 / final>。

Author's Address

著者のアドレス

Michael Jenkins National Security Agency

マイケルジェンキンス国家安全保障局

   Email: mjjenki@nsa.gov