RFC 9151 - Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 (RFC 9151) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9151.html
タイトル : RFC 9151 - TLSおよびDTLS 1.2および1.3（RFC 9151）の商業国家安全保障アルゴリズム（CNSA）スイートプロファイル
翻訳編集 : 自動生成

[要約] RFC 9151は、TLSおよびDTLS 1.2と1.3における商用国家安全保障アルゴリズム(CNSA)スイートのプロファイルを定義しています。この文書の目的は、高度なセキュリティ要件を持つ情報システムでの使用を目指して、強化された暗号化プロトコルを提供することです。主に、国家安全保障に関連する通信や、高度なセキュリティが求められる商用環境での利用が想定されています。

Independent Submission                                         D. Cooley
Request for Comments: 9151                                           NSA
Category: Informational                                       April 2022
ISSN: 2070-1721

Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3

TLSおよびDTLS 1.2および1.3の商業国家安全保障アルゴリズム（CNSA）スイートプロファイル

Abstract

概要

This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite.

このドキュメントでは、米国の商業国家安全保障アルゴリズム（CNSA）スイートで使用するためのDTLSプロトコルバージョン1.2および1.3のTLSプロトコルバージョン1.2および1.3のベースプロファイルを定義します。

The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS or DTLS. It is also appropriate for all other US Government systems that process high-value information.

このプロファイルは、TLSまたはDTLSを使用する米国の国家安全保障システムのすべてのコンポーネントの機能、構成、および動作に適用されます。また、高価値情報を処理する他のすべての米国政府システムにも適しています。

The profile is made publicly available here for use by developers and operators of these and any other system deployments.

プロファイルは、これらおよびその他のシステムの展開の開発者とオペレーターが使用するためにここで公開されています。

Status of This Memo

本文書の位置付け

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

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

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エディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。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/rfc9151.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9151で取得できます。

著作権表示

著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。

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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

   1.  Introduction
   2.  CNSA
   3.  Terminology
   4.  CNSA Suites
     4.1.  CNSA (D)TLS Key Establishment Algorithms
     4.2.  CNSA TLS Authentication
   5.  CNSA Compliance and Interoperability Requirements
     5.1.  Acceptable Elliptic Curve Cryptography (ECC) Curves
     5.2.  Acceptable RSA Schemes, Parameters, and Checks
     5.3.  Acceptable Finite Field Groups
     5.4.  Certificates
   6.  (D)TLS 1.2 Requirements
     6.1.  The "extended_master_secret" Extension
     6.2.  The "signature_algorithms" Extension
     6.3.  The "signature_algorithms_cert" Extension
     6.4.  The CertificateRequest Message
     6.5.  The CertificateVerify Message
     6.6.  The Signature in the ServerKeyExchange Message
     6.7.  Certificate Status
   7.  (D)TLS 1.3 Requirements
     7.1.  The "signature_algorithms" Extension
     7.2.  The "signature_algorithms_cert" Extension
     7.3.  The "early_data" Extension
     7.4.  Resumption
     7.5.  Certificate Status
   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 a profile of TLS version 1.2 [RFC5246] and TLS version 1.3 [RFC8446] as well as DTLS version 1.2 [RFC6347] and DTLS version 1.3 [RFC9147] for use by applications that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite [CNSA]. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [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.

このドキュメントは、TLSバージョン1.2 [RFC5246]およびTLSバージョン1.3 [RFC8446]のプロファイル、およびDTLSバージョン1.2 [RFC6347]およびDTLSバージョン1.3 [RFC9147]を、国家安全保障機関（NSA）をサポートするアプリケーション（NSA）をサポートするアプリケーションで使用するためのDTLSバージョン1.3 [RFC9147]を指定しています。セキュリティアルゴリズム（CNSA）スイート[CNSA]。このプロファイルは、米国の国家安全保障システムのすべてのコンポーネントの機能、構成、および動作に適用されます[SP80059]。また、高価値情報を処理する他のすべての米国政府システムにも適しています。これらおよびその他のシステムの展開の開発者やオペレーターが公開できるようになりました。

This document does not define any new cipher suites; instead, it defines a CNSA-compliant profile of TLS and DTLS, and the cipher suites defined in [RFC5288], [RFC5289], and [RFC8446]. This profile uses only algorithms in the CNSA Suite.

このドキュメントは、新しい暗号スイートを定義しません。代わりに、TLSおよびDTLSのCNSA準拠プロファイル、[RFC5288]、[RFC5289]、および[RFC8446]で定義されている暗号スイートを定義します。このプロファイルは、CNSAスイートのアルゴリズムのみを使用します。

The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], [RFC8446], [RFC6347], and [RFC9147], respectively. All MUST-level requirements from the protocol documents apply throughout this profile; they are generally not repeated. This profile contains changes that elevate some SHOULD-level options to MUST-level; this profile also contains changes that elevate some MAY-level options to SHOULD-level or MUST-level. All options that are not mentioned in this profile remain at their original requirement level.

読者は、TLS 1.2および1.3、およびDTLS 1.2と1.3のプロトコル仕様に精通していると想定されています：[RFC5246]、[RFC8446]、[RFC6347]、[RFC9147]。プロトコルドキュメントからの必須レベルの要件はすべて、このプロファイル全体に適用されます。それらは一般的に繰り返されません。このプロファイルには、いくつかのレベルのオプションを必須レベルに引き上げる変更が含まれています。このプロファイルには、5月レベルのオプションをレベルまたは必見のレベルに昇格させる変更も含まれています。このプロファイルで言及されていないすべてのオプションは、元の要件レベルのままです。

2. CNSA

The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US 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 CNSA Suite to provide vendors and IT users near-term flexibility in meeting their Information Assurance (IA) 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は、ベンダーとITユーザーに情報保証（IA）の相互運用性要件を満たすために、ベンダーとITユーザーに近い柔軟性を提供するためのCNSAスイートを設立しました。この柔軟性の背後にある目的は、ベンダーと顧客が比較的短い時間枠で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 National Security Systems.

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

3. Terminology

3. 用語

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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. ECDSA and ECDH are used with the NIST P-384 curve (which is based on a 384-bit prime modulus) and the SHA-384 hash function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH are used with a 3072-bit or 4096-bit modulus. When RSA is used for digital signature, it is used with the SHA-384 hash function.

「ECDSA」と「ECDH」は、それぞれ楕円曲線デジタル署名アルゴリズム（ECDSA）と楕円曲線Diffie Hellman（ECDH）の使用を指します。ECDSAとECDHは、NIST P-384曲線（384ビットプライムモジュラスに基づいています）およびSHA-384ハッシュ関数で使用されます。同様に、「RSA」と「DH」は、それぞれRivest-Shamir-Adleman（RSA）と有限のフィールドDiffie-Hellman（DH）を指します。RSAとDHは、3072ビットまたは4096ビットモジュラスで使用されます。RSAがデジタル署名に使用される場合、SHA-384ハッシュ関数とともに使用されます。

Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS versions 1.2 and 1.3 collectively as "(D)TLS".

今後、このドキュメントは、TLSバージョン1.2および1.3およびDTLSバージョン1.2および1.3を「（d）TLS」と総称して言及しています。

4. CNSA Suites

4. CNSAスイート

[CNSA] approves the use of both Finite Field and elliptic curve versions of the DH key agreement algorithm as well as RSA-based key establishment. [CNSA] also approves certain versions of the RSA and elliptic curve digital signature algorithms. The approved encryption techniques include the Advanced Encryption Standard (AES) used with a 256-bit key in an Authenticated Encryption with Associated Data (AEAD) mode.

[CNSA]は、DHキー契約アルゴリズムとRSAベースの主要な確立の有限フィールドバージョンと楕円曲線バージョンの両方の使用を承認します。[CNSA]は、RSAおよび楕円曲線デジタル署名アルゴリズムの特定のバージョンも承認します。承認された暗号化手法には、関連データ（AEAD）モードを備えた認証された暗号化で256ビットキーで使用される高度な暗号化標準（AES）が含まれます。

In particular, CNSA includes the following:

特に、CNSAには次のものが含まれています。

Encryption: AES [AES] (with key size 256 bits), operating in Galois/Counter Mode (GCM) [GCM]

暗号化：AES [AES]（キーサイズ256ビット）、ガロア/カウンターモード（GCM）[GCM]で動作する

Digital Signature: ECDSA [DSS] (using the NIST P-384 elliptic curve)

デジタル署名：ECDSA [DSS]（NIST P-384楕円曲線を使用）

RSA [DSS] (with a modulus of 3072 bits or 4096 bits)

RSA [DSS]（3072ビットまたは4096ビットのモジュラス付き）

Key Establishment (includes key agreement and key transport): ECDH [PWKE-A] (using the NIST P-384 elliptic curve)

キー設立（キー契約とキートランスポートを含む）：ECDH [PWKE-A]（NIST P-384楕円曲線を使用）

DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits)

DH [PWKE-A]（3072または4096ビットのプライムモジュラス付き）

RSA [PWKE-B] (with a modulus of 3072 or 4096 bits, but only in (D)TLS 1.2)

rsa [pwke-b]（3072または4096ビットのモジュラスで、しかし（d）TLS 1.2でのみ）

[CNSA] also approves the use of SHA-384 [SHS] as the hash algorithm for mask generation, signature generation, Pseudorandom Function (PRF) in TLS 1.2 and HMAC-based Key Derivation Function (HKDF) in TLS 1.3.

[CNSA]は、TLS 1.2のハッシュアルゴリズム、署名生成、擬似ランダム関数（PRF）、およびTLS 1.3のHMACベースのキー誘導関数（HKDF）としてのSHA-384 [SHS]の使用も承認します。

4.1. CNSA (D)TLS Key Establishment Algorithms

4.1. CNSA（D）TLSキー確立アルゴリズム

The following combination of algorithms and key sizes are used in CNSA (D)TLS:

アルゴリズムとキーサイズの以下の組み合わせは、CNSA（d）TLSで使用されています。

AES with 256-bit key, operating in GCM mode

GCMモードで動作する256ビットキーを持つAES

ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with cofactor set to 1 (see Section 6.1.2.2 in [PWKE-A])

ECDH [PWKE-A]は、補助を1に設定した短命統一モデルスキームを使用しています（[PWKE-A]のセクション6.1.2.2を参照）

TLS PRF/HKDF with SHA-384 [SHS]

SHA-384を備えたTLS PRF/HKDF [SHS]

または

AES with 256-bit key, operating in GCM mode

GCMモードで動作する256ビットキーを持つAES

RSA key transport using 3072-bit or 4096-bit modulus [PWKE-B][RFC8017]

3072ビットまたは4096ビットモジュラスを使用したRSAキートランスポート[PWKE-B] [RFC8017]

TLS PRF/HKDF with SHA-384 [SHS]

SHA-384を備えたTLS PRF/HKDF [SHS]

または

AES with 256-bit key, operating in GCM mode

GCMモードで動作する256ビットキーを持つAES

DH using dhEphem with domain parameters specified below in Section 5.3 (see Section 6.1.2.1 in [PWKE-A])

DHは、セクション5.3で以下に指定されたドメインパラメーターを使用してDHEPHEMを使用しています（[PWKE-A]のセクション6.1.2.1を参照）

TLS PRF/HKDF with SHA-384 [SHS]

SHA-384を備えたTLS PRF/HKDF [SHS]

The specific CNSA-compliant cipher suites are listed in Section 5.

特定のCNSA準拠の暗号スイートは、セクション5にリストされています。

4.2. CNSA TLS Authentication

4.2. CNSA TLS認証

For server and/or client authentication, CNSA (D)TLS MUST generate and verify either ECDSA signatures or RSA signatures.

サーバーおよび/またはクライアント認証の場合、CNSA（D）TLSは、ECDSA署名またはRSA署名のいずれかを生成および検証する必要があります。

In all cases, the client MUST authenticate the server. The server MAY also authenticate the client, as needed by the specific application.

いずれの場合も、クライアントはサーバーを認証する必要があります。サーバーは、特定のアプリケーションで必要に応じて、クライアントを認証することもできます。

The public keys used to verify these signatures MUST be contained in a certificate (see Section 5.4 for more information).

これらの署名を確認するために使用されるパブリックキーは、証明書に含める必要があります（詳細については、セクション5.4を参照）。

5. CNSA Compliance and Interoperability Requirements

5. CNSAコンプライアンスと相互運用性の要件

CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA-compliant system. CNSA (D)TLS servers and clients MUST implement and use either (D)TLS version 1.2 [RFC5246] [RFC6347] or (D)TLS version 1.3 [RFC8446] [RFC9147].

CNSA（d）TLSは、CNSA準拠システムで（d）TLS 1.2の前にTLSバージョンを使用してはなりません。CNSA（D）TLSサーバーとクライアントは、（d）TLSバージョン1.2 [RFC5246] [RFC6347]または（D）TLSバージョン1.3 [RFC8446] [RFC9147]のいずれかを実装および使用する必要があります。

5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves

5.1. 許容可能な楕円曲線暗号化（ECC）曲線

The elliptic curves used in the CNSA Suite appear in the literature under two different names [DSS] [SECG]. For the sake of clarity, both names are listed below:

CNSAスイートで使用される楕円曲線は、2つの異なる名前[DSS] [SECG]の下で文献に表示されます。明確にするために、両方の名前を以下にリストします。

                     +=======+===========+===========+
                     | Curve | NIST name | SECG name |
                     +=======+===========+===========+
                     | P-384 | nistp384  | secp384r1 |
                     +-------+-----------+-----------+

Table 1: Elliptic Curves in CNSA Suite

表1：CNSAスイートの楕円曲線

[RFC8422] defines a variety of elliptic curves. CNSA (D)TLS connections MUST use secp384r1 (also called nistp384), and the uncompressed form MUST be used, as required by [RFC8422] and [RFC8446].

[RFC8422]は、さまざまな楕円曲線を定義します。CNSA（d）TLS接続は、SECP384R1（NISTP384とも呼ばれます）を使用する必要があり、[RFC8422]および[RFC8446]で要求されるように、非圧縮フォームを使用する必要があります。

Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A].

[PWKE-A]のセクション5.6.1.2に従って、キーペアを生成する必要があります。

5.2. Acceptable RSA Schemes, Parameters, and Checks

5.2. 許容可能なRSAスキーム、パラメーター、およびチェック

[CNSA] specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile.

[CNSA]は、3072ビットの最小弾性サイズを指定します。ただし、このプロファイルによってサポートされている2つのモジュラスサイズ（3072ビットと4096ビット）のみがサポートされています。

For (D)TLS 1.2: For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported.

（d）TLS 1.2：証明書署名の場合、RSASSA-PKCS1-V1_5 [RFC8017]をサポートする必要があり、RSASSA-PSS [DSS]をサポートする必要があります。

For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported.

TLSハンドシェイクメッセージの署名の場合、rsassa-pkcs1-v1_5 [rfc8017]をサポートする必要があり、rsassa-pss [dss]をサポートする必要があります。

For key transport, RSAES-PKCS1-v1_5 [RFC8017] MUST be supported.

キートランスポートの場合、RSAES-PKCS1-V1_5 [RFC8017]をサポートする必要があります。

For (D)TLS 1.3: For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported.

（d）TLS 1.3：証明書署名の場合、RSASSA-PKCS1-V1_5 [RFC8017]をサポートする必要があり、RSASSA-PSS [DSS]をサポートする必要があります。

For signatures in TLS handshake messages, RSASSA-PSS [DSS] MUST be supported.

TLSハンドシェイクメッセージの署名の場合、rsassa-pss [dss]をサポートする必要があります。

For key transport, TLS 1.3 does not support RSA key transport.

キートランスポートの場合、TLS 1.3はRSAキートランスポートをサポートしていません。

For all versions of (D)TLS: RSA exponent e MUST satisfy 2^16<e<2^256 and be odd per [DSS].

（d）TLSのすべてのバージョンについて：RSA指数Eは2^16 <e <2^256を満たし、[DSS]ごとに奇数でなければなりません。

If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then the implementation MUST assert rsaEncryption as the public key algorithm, the hash algorithm (used for both mask generation and signature generation) MUST be SHA-384, the mask generation function 1 (MGF1) from [RFC8017] MUST be used, and the salt length MUST be 48 octets.

RSASSA-PSSがサポートされている場合（たとえばRSA_PSS_RSAE_SHA384を使用）、実装は公開キーアルゴリズムとしてRSAECHRIPTを主張する必要があります。ハッシュアルゴリズム（マスク生成と署名生成の両方に使用）は、Mask Generation Function 1（[RFC8017]からのMGF1）を使用する必要があり、塩の長さは48オクテットでなければなりません。

5.3. Acceptable Finite Field Groups

5.3. 許容可能な有限フィールドグループ

[CNSA] specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile.

Ephemeral key pairs MUST be generated following Section 5.6.1.1.1 of [PWKE-A] using the approved safe prime groups specified in [RFC7919] for DH ephemeral key agreement. The named groups are:

DH Ephemeral Key契約のために[RFC7919]で指定された承認された安全なプライムグループを使用して、[PWKE-A]のセクション5.6.1.1.1に従って、一時的なキーペアを生成する必要があります。指名されたグループは次のとおりです。

ffdhe3072 (ID=257)

ffdhe3072（id = 257）

ffdhe4096 (ID=258)

ffdhe4096（id = 258）

5.4. Certificates

5.4. 証明書

Certificates used to establish a CNSA (D)TLS connection MUST be signed with ECDSA or RSA and MUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile [RFC8603].

CNSA（D）TLS接続の確立に使用される証明書は、ECDSAまたはRSAと署名する必要があり、CNSAスイート証明書および証明書取消リスト（CRL）プロファイル[RFC8603]に準拠する必要があります。

6. (D)TLS 1.2 Requirements

6. （d）TLS 1.2要件

Although TLS 1.2 has technically been obsoleted by the IETF in favor of TLS 1.3, many implementations and deployments of TLS 1.2 will continue to exist. For the cases where TLS 1.2 continues to be used, implementations MUST use [RFC5246] and SHOULD implement the updates specified in [RFC8446] (outlined in Section 1.3 of that document).

TLS 1.2はTLS 1.3を支持してIETFによって技術的に廃止されましたが、TLS 1.2の多くの実装と展開は引き続き存在します。TLS 1.2が引き続き使用されている場合、実装は[RFC5246]を使用する必要があり、[RFC8446]で指定された更新を実装する必要があります（そのドキュメントのセクション1.3で概説されています）。

The CNSA (D)TLS 1.2 client MUST offer at least one of these cipher suites:

CNSA（D）TLS 1.2クライアントは、これらの暗号スイートの少なくとも1つを提供する必要があります。

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 [RFC5289] [RFC8422]

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5289] [RFC8422]

TLS_RSA_WITH_AES_256_GCM_SHA384 [RFC5288]

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5288] [RFC7919]

The CNSA cipher suites listed above MUST be the first (most preferred) cipher suites in the ClientHello message.

上記のCNSA暗号スイートは、ClientHelloメッセージの最初の（最も好ましい）暗号スイートでなければなりません。

A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant MAY offer additional cipher suites, but any additional cipher suites MUST appear after the CNSA cipher suites in the ClientHello message.

CNSAに準拠していないサーバーとの相互運用性を提供するCNSA（d）TLSクライアントは、追加の暗号スイートを提供する場合がありますが、CNSA暗号スイートの後に追加の暗号スイートが表示される必要があります。

A CNSA (D)TLS server MUST accept one of the CNSA Suites above if they are offered in the ClientHello message before accepting a non-CNSA-compliant suite.

CNSA（D）TLSサーバーは、非CNSAに準拠していないスイートを受け入れる前に、ClientHelloメッセージで提供される場合、上記のCNSAスイートの1つを受け入れる必要があります。

If interoperability is not desired with non-CNSA-compliant clients or servers, then the session MUST fail if no CNSA Suites are offered or accepted.

非CNSA準拠のクライアントまたはサーバーで相互運用性が望まれない場合、CNSAスイートが提供または受け入れられない場合、セッションが失敗する必要があります。

6.1. The "extended_master_secret" Extension

6.1. 「extended_master_secret」拡張機能

A CNSA (D)TLS client SHOULD include and a CNSA (D)TLS server SHOULD accept the "extended_master_secret" extension as specified in [RFC7627]. See Section 1 of [RFC7627] for security concerns when this extension is not used.

CNSA（d）TLSクライアントが含める必要があり、CNSA（D）TLSサーバーは[RFC7627]で指定されている「Extended_Master_Secret」拡張機能を受け入れる必要があります。この拡張機能を使用していない場合のセキュリティに関する懸念については、[RFC7627]のセクション1を参照してください。

6.2. The "signature_algorithms" Extension

6.2. 「signature_algorithms」拡張子

A CNSA (D)TLS client MUST include and a CNSA (D)TLS server MUST also accept the "signature_algorithms" extension. The CNSA (D)TLS client MUST offer and the CNSA (D)TLS server MUST also accept at least one of the following values in the "signature_algorithms" extensions as specified in [RFC8446]:

CNSA（d）TLSクライアントが含まれる必要があり、CNSA（d）TLSサーバーも「signature_algorithms」拡張子を受け入れる必要があります。CNSA（d）TLSクライアントは提供する必要があり、CNSA（d）TLSサーバーは、[RFC8446]で指定されている「Signature_Algorithms」拡張機能の次の値の少なくとも1つも受け入れる必要があります。

ecdsa_secp384r1_sha384

ECDSA_SECP384R1_SHA384

rsa_pkcs1_sha384

RSA_PKCS1_SHA384

And, if supported, the client SHOULD offer and/or the server SHOULD also accept:

また、サポートされている場合、クライアントは提供する必要があります。また、サーバーも受け入れる必要があります。

rsa_pss_pss_sha384

RSA_PSS_PSS_SHA384

rsa_pss_rsae_sha384

RSA_PSS_RSAE_SHA384

Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for certification path validation.

[RFC8603]のガイダンスに続いて、CNSA（D）TLSサーバーは、ServerKeyExchangeメッセージの署名および認定パス検証についてのみECDSAまたはRSAを受け入れる必要があります。

Other client offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA and to indicate the signature algorithms that are acceptable for ServerKeyExchange messages and for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server.

CNSAに準拠していないサーバーとの相互運用性のために提供される暗号スイートの許容可能な署名アルゴリズムを示すために、他のクライアント製品を含めることができ、ServerKeyExchangeメッセージと非準拠CNSAの認定パス検証に許容できる署名アルゴリズムを示すために）TLS接続。これらの提供は、CNSA準拠（d）TLSサーバーによって受け入れられてはなりません。

6.3. The "signature_algorithms_cert" Extension

6.3. 「signature_algorithms_cert」拡張子

A CNSA (D)TLS client MAY include the "signature_algorithms_cert" extension. CNSA (D)TLS servers MUST process the "signature_algorithms_cert" extension if it is offered per Section 4.2.3 of [RFC8446].

CNSA（d）TLSクライアントには、「signature_algorithms_cert」拡張子を含めることができます。CNSA（d）TLSサーバーは、[RFC8446]のセクション4.2.3に従って提供されている場合、「signature_algorithms_cert」拡張機能を処理する必要があります。

Both CNSA (D)TLS clients and servers MUST use one of the following values for certificate path validation:

CNSA（D）TLSクライアントとサーバーの両方は、証明書パス検証に次の値のいずれかを使用する必要があります。

ecdsa_secp384r1_sha384

ECDSA_SECP384R1_SHA384

rsa_pkcs1_sha384

RSA_PKCS1_SHA384

And, if supported, SHOULD offer/accept:

そして、サポートされている場合は、提供/受け入れる必要があります。

rsa_pss_pss_sha384

RSA_PSS_PSS_SHA384

rsa_pss_rsae_sha384

RSA_PSS_RSAE_SHA384

6.4. The CertificateRequest Message

6.4. CertificateRequestメッセージ

When a CNSA (D)TLS server is configured to authenticate the client, the server MUST include the following values in its CertificateRequest.supported_signature_algorithms [RFC5246] offer:

CNSA（d）TLSサーバーがクライアントを認証するように構成されている場合、サーバーはそのcirtermaterequest.supported_signature_algorithms [rfc5246]オファーに次の値を含める必要があります。

ecdsa_secp384r1_sha384

ECDSA_SECP384R1_SHA384

rsa_pkcs1_sha384

RSA_PKCS1_SHA384

And, if supported as specified in [RFC8446], SHOULD offer/accept:

また、[RFC8446]で指定されているようにサポートされている場合は、以下を提供/受け入れる必要があります。

rsa_pss_pss_sha384

RSA_PSS_PSS_SHA384

rsa_pss_rsae_sha384

RSA_PSS_RSAE_SHA384

6.5. The CertificateVerify Message

6.5. CertimateVerifyメッセージ

A CNSA (D)TLS client MUST use ECDSA or RSA when sending the CertificateVerify message. CNSA (D)TLS servers MUST only accept ECDSA or RSA in the CertificateVerify message.

CNSA（d）TLSクライアントは、certifateverifyメッセージを送信する際にECDSAまたはRSAを使用する必要があります。CNSA（d）TLSサーバーは、certifateverifyメッセージでECDSAまたはRSAのみを受け入れる必要があります。

6.6. The Signature in the ServerKeyExchange Message

6.6. ServerKeyExchangeメッセージの署名

A CNSA (D)TLS server MUST sign the ServerKeyExchange message using ECDSA or RSA.

CNSA（D）TLSサーバーは、ECDSAまたはRSAを使用してServerKeyExchangeメッセージに署名する必要があります。

6.7. Certificate Status

6.7. 証明書ステータス

Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or client MUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA client SHOULD request it according to Section 4.4.2.1 of [RFC8446]. If OCSP is supported, the (D)TLS server SHOULD provide OCSP responses in the CertificateStatus message.

CNSA（D）TLSサーバーまたはクライアントに証明書を提供する証明書当局（CAS）は、証明書取消リスト（CRL）配布ポイントを介して証明書の取り消しステータス情報を提供するか、オンライン証明書ステータスプロトコル（OCSP）を使用する必要があります。CNSAクライアントは、[RFC8446]のセクション4.4.2.1に従ってそれを要求する必要があります。OCSPがサポートされている場合、（d）TLSサーバーは、証明書メッセージにOCSP応答を提供する必要があります。

7. (D)TLS 1.3 Requirements

7. （d）TLS 1.3要件

The CNSA (D)TLS client MUST offer the following cipher suite in the ClientHello:

CNSA（d）TLSクライアントは、クライアントヘロで次の暗号スイートを提供する必要があります。

TLS_AES_256_GCM_SHA384

The CNSA (D)TLS client MUST include at least one of the following values in the "supported_groups" extension:

CNSA（d）TLSクライアントには、「supported_groups」拡張機能に次の値の少なくとも1つを含める必要があります。

ECDHE: secp384r1

ECDHE：SECP384R1

DHE: ffdhe3072

DHE：FFDHE3072

DHE: ffdhe4096

DHE：FFDHE4096

The CNSA cipher suite MUST be the first (most preferred) cipher suite in the ClientHello message and in the extensions.

CNSA暗号スイートは、ClientHelloメッセージおよび拡張機能の最初の（最も優先される）暗号スイートでなければなりません。

CNSAに準拠していないサーバーとの相互運用性を提供するCNSA（D）TLSクライアントは、追加の暗号スイートを提供する場合がありますが、CNSA準拠の暗号スイートの後に追加の暗号スイートが表示される必要があります。

A CNSA (D)TLS server MUST accept one of the CNSA algorithms listed above if they are offered in the ClientHello message.

CNSA（D）TLSサーバーは、ClientHelloメッセージに提供されている場合、上記のCNSAアルゴリズムの1つを受け入れる必要があります。

If interoperability is not desired with non-CNSA-compliant clients or servers, then the session MUST fail if no CNSA Suites are offered or accepted.

7.1. The "signature_algorithms" Extension

7.1. 「signature_algorithms」拡張子

A CNSA (D)TLS client MUST include the "signature_algorithms" extension. The CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms" extension:

CNSA（d）TLSクライアントには、「signature_algorithms」拡張子を含める必要があります。CNSA（d）TLSクライアントは、「signature_algorithms」拡張子で次の値の少なくとも1つを提供する必要があります。

ecdsa_secp384r1_sha384

ECDSA_SECP384R1_SHA384

rsa_pss_pss_sha384

RSA_PSS_PSS_SHA384

rsa_pss_rsae_sha384

RSA_PSS_RSAE_SHA384

Clients that allow negotiating TLS 1.2 MAY offer rsa_pkcs1_sha384 for use with TLS 1.2. Other offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server.

TLS 1.2の交渉を許可するクライアントは、TLS 1.2で使用するためにRSA_PKCS1_SHA384を提供する場合があります。他の製品は、非準拠CNSA（D）TLS接続のCNSAに準拠していないサーバーとの相互運用性のために提供される暗号スイートの許容可能な署名アルゴリズムを示すために含めることができます。これらの提供は、CNSA準拠（d）TLSサーバーによって受け入れられてはなりません。

7.2. The "signature_algorithms_cert" Extension

7.2. 「signature_algorithms_cert」拡張子

A CNSA (D)TLS client SHOULD include the "signature_algorithms_cert" extension. And, if offered, the CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms_cert" extension:

CNSA（d）TLSクライアントには、「signature_algorithms_cert」拡張子を含める必要があります。そして、提供された場合、CNSA（d）TLSクライアントは、「signature_algorithms_cert」拡張機能の少なくとも1つを次の値のうち少なくとも提供する必要があります。

ecdsa_secp384r1_sha384

ECDSA_SECP384R1_SHA384

rsa_pkcs1_sha384

RSA_PKCS1_SHA384

And, if supported, SHOULD offer:

そして、サポートされている場合は、以下を提供する必要があります。

rsa_pss_pss_sha384

RSA_PSS_PSS_SHA384

rsa_pss_rsae_sha384

RSA_PSS_RSAE_SHA384

Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only accept ECDSA or RSA for certificate path validation.

[RFC8603]のガイダンスに従って、CNSA（D）TLSサーバーは、証明書パス検証のためにECDSAまたはRSAのみを受け入れる必要があります。

Other offerings MAY be included to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server.

非準拠CNSA（D）TLS接続の認証パス検証に許容できる署名アルゴリズムを示すために、他の製品を含めることができます。これらの提供は、CNSA準拠（d）TLSサーバーによって受け入れられてはなりません。

7.3. The "early_data" Extension

7.3. 「Early_Data」拡張機能

A CNSA (D)TLS client or server MUST NOT include the "early_data" extension. See Section 2.3 of [RFC8446] for security concerns.

CNSA（d）TLSクライアントまたはサーバーには、「初期_DATA」拡張機能を含めてはなりません。セキュリティの懸念については、[RFC8446]のセクション2.3を参照してください。

7.4. Resumption

7.4. 再開

A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket message to enable resumption. A CNSA (D)TLS client MUST request "psk_dhe_ke" via the "psk_key_exchange_modes" ClientHello extension to resume a session. A CNSA (D)TLS client MUST offer Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) with SHA-384 and/or Ephemeral Diffie-Hellman (DHE) with SHA-384 in the "supported_groups" and/or "key_share" extensions.

CNSA（d）TLSサーバーは、CNSA（d）TLSクライアントにNewsessionTicketメッセージを送信して、再開できるようにする場合があります。CNSA（d）TLSクライアントは、「psk_key_exchange_modes」clienthello拡張機能を介して「psk_dhe_ke」を要求する必要があります。CNSA（d）TLSクライアントは、「supported_groups」および/または "key_share" endionsにSHA-384を備えたSHA-384および/またはEPHEMERAL DIFFIE-HELLMAN（DHE）を備えた短命の楕円曲線Diffie-Hellman（ECDHE）を提供する必要があります。

7.5. Certificate Status

7.5. 証明書ステータス

CNSA（D）TLSサーバーまたはクライアントに証明書を提供する証明書当局（CAS）は、証明書取消リスト（CRL）配布ポイントを介して証明書の取り消しステータス情報を提供するか、オンライン証明書ステータスプロトコル（OCSP）を使用する必要があります。CNSAクライアントは、[RFC8446]のセクション4.4.2.1に従ってそれを要求する必要があります。OCSPがサポートされている場合、（d）TLSサーバーは「証明書」でOCSP応答を提供する必要があります。

8. Security Considerations

8. セキュリティ上の考慮事項

Most of the security considerations for this document are described in [RFC5246], [RFC8446], [RFC6347], and [RFC9147]. In addition, the security considerations for Elliptic Curve Cryptography (ECC) related to TLS are described in [RFC8422], [RFC5288], and [RFC5289]. Readers should consult those documents.

このドキュメントのセキュリティ上の考慮事項のほとんどは、[RFC5246]、[RFC8446]、[RFC6347]、および[RFC9147]で説明されています。さらに、TLSに関連する楕円曲線暗号（ECC）のセキュリティに関する考慮事項は、[RFC8422]、[RFC5288]、および[RFC5289]に記載されています。読者はこれらの文書を参照する必要があります。

In order to meet the goal of a consistent security level for the entire cipher suite, CNSA (D)TLS implementations MUST only use the elliptic curves, RSA schemes, and Finite Fields defined in Section 5.1, Section 5.2, and Section 5.3, respectively. If this is not the case, then security may be weaker than is required.

暗号スイート全体の一貫したセキュリティレベルの目標を達成するには、CNSA（D）TLS実装は、それぞれセクション5.1、セクション5.2、およびセクション5.3で定義されている楕円曲線、RSAスキーム、および有限フィールドのみを使用する必要があります。そうでない場合、セキュリティは必要以上に弱くなる可能性があります。

As noted in TLS version 1.3 [RFC8446], TLS does not provide inherent replay protections for early data. For this reason, this profile forbids the use of early data.

TLSバージョン1.3 [RFC8446]で述べたように、TLSは初期データに固有のリプレイ保護を提供しません。このため、このプロファイルは初期データの使用を禁止しています。

9. IANA Considerations

9. IANAの考慮事項

This document has no IANA actions.

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

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[AES] National Institute of Standards and Technology, "Announcing the ADVANCED ENCRYPTION STANDARD (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001, <https://nvlpubs.nist.gov/nistpubs/fips/ NIST.FIPS.197.pdf>.

[AES]国立標準技術研究所、「高度な暗号化標準（AES）の発表」、FIPS 197、doi 10.6028/nist.fips.197、2001年11月、<https://nvlpubs.gov/nistpubs/fips/ nist.fips.197.pdf>。

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

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

[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.

[DSS]国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS Pub 186-4、DOI 10.6028/nist.fips.186-4、2013年7月、<https://nvlpubs.nist.gov/nistpubs/ fips/ nist.fips.186-4.pdf>。

[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-38d.pdf>.

[GCM] Dworkin、M。、「操作のブロックモードの推奨：ガロア/カウンターモード（GCM）およびGMAC」、NIST Special Publication 800-38D、DOI 10.6028/nist.sp.800-38d、2007年11月、<<<https://nvlpubs.nist.gov/nistpubs/legacy/sp/ nistspecialpublication800-38d.pdf>。

[PWKE-A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A Revision 3, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>.

[Pwke-A] Barker、E.、Chen、L.、Roginsky、A.、Vassilev、A。、およびR. Davis、「離散対数暗号化を使用したペアワイズの重要な確立スキームの推奨」、Nist Special Publication 800-56Aリビジョン3、DOI 10.6028/nist.sp.800-56ar3、2018年4月、<https://nvlpubs.nist.gov/nistpubs/specialpublications/ nist.sp.800-56ar3.pdf>。

[PWKE-B] Barker, E., Chen, L., Roginsky, A., Vassilev, A., Davis, R., and S. Simon, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography", NIST Special Publication 800-56B Revision 2, DOI 10.6028/NIST.SP.800-56Br2, March 2019, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Br2.pdf>.

[Pwke-B] Barker、E.、Chen、L.、Roginsky、A.、Vassilev、A.、Davis、R。、およびS. Simon、「整数因子化暗号化を使用したペアワイズの重要な確立スキームの推奨」、NIST Special Publication 800-56B Revision 2、doi 10.6028/nist.sp.800-56br2、2019年3月、<https://nvlpubs.nist.gov/nistpubs/speacialpublications/ nist.sp.800-56br2.pdf>。

[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>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、DOI 10.17487/RFC5246、2008年8月、<https://www.rfc-editor.org/info/RFC5246>。

[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <https://www.rfc-editor.org/info/rfc5288>.

[RFC5288] Salowey、J.、Choudhury、A。、およびD. McGrew、「AES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、DOI 10.17487/RFC5288、2008年8月、<https：// www。rfc-editor.org/info/rfc5288>。

[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <https://www.rfc-editor.org/info/rfc5289>.

[RFC5289] Rescorla、E。、「SHA-256/384およびAES Galoisカウンターモード（GCM）を備えたTLS楕円曲線暗号」、RFC 5289、DOI 10.17487/RFC5289、2008年8月、<HTTPS：//WW.RFC-editor.org/info/rfc5289>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC6347] Rescorla、E。およびN. Modadugu、「データグラムトランスポートレイヤーセキュリティバージョン1.2」、RFC 6347、DOI 10.17487/RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>

[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.

[RFC7627] Bhargavan、K.、Ed。、Delignat-Lavaud、A.、Pironti、A.、Langley、A.、およびM. Ray、「Transport Layer Security（TLS）セッションハッシュおよび拡張マスターシークレットエクステンション」、RFC7627、doi 10.17487/rfc7627、2015年9月、<https://www.rfc-editor.org/info/rfc7627>。

[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.

[RFC7919] Gillmor、D。、「輸送層のセキュリティ（TLS）のための有限界面ディフェルマンの短命パラメーター」、RFC 7919、DOI 10.17487/RFC7919、2016年8月、<https://www.rfc-editor.org///情報/RFC7919>。

[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.、A。Rusch、 "PKCS＃1：RSA暗号仕様バージョン2.2"、RFC 8017、DOI 10.17487/RFC8017、2016年11月、<<<<<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>。

[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.

[RFC8422] Nir、Y.、Josefsson、S。、およびM. Pegourie-Gonnard、「輸送層セキュリティ（TLS）バージョン（TLS）バージョン用の楕円曲線暗号化（ECC）暗号スイート」、RFC 8422、DOI 10.17487/RFC8422、2018年8月、<https://www.rfc-editor.org/info/rfc8422>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>

[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。and L. Zieglar、「商業国家安全保障アルゴリズム（CNSA）スイート証明書および証明書取消リスト（CRL）プロファイル」、RFC 8603、DOI 10.17487/RFC8603、2019年5月、<https：// www。rfc-editor.org/info/rfc8603>。

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。

[SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, FIPS PUB 180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.

[SHS]国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、doi 10.6028/nist.fips.180-4、Fips Pub 180-4、2015年8月、<https：//nvlpubs.nist.gov/nistpubs/fips/nist.fips.180-4.pdf>。

10.2. Informative References

10.2. 参考引用

[SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, February 2010, <https://www.secg.org/sec2-v2.pdf>.

[Secg] Brown、D。、「Sec 2：推奨される楕円曲線ドメインパラメーター」、バージョン2.0、2010年2月、<https://www.secg.org/sec2-v2.pdf>。

[SP80059] Barker, W., "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, NIST Special Publication 800-59, August 2003, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-59.pdf>.

[SP80059] Barker、W。、「情報システムを国家安全保障システムとして特定するためのガイドライン」、DOI 10.6028/nist.sp.800-59、NIST Special Publication 800-59、2003年8月、<https：// nvlpubs。nist.gov/nistpubs/legacy/sp/ nistspecialpublication800-59.pdf>。

Author's Address

著者の住所

Dorothy Cooley National Security Agency Email: decoole@nsa.gov

Dorothy Cooley国家安全保障局メール：decoole@nsa.gov