Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9973 Vigil Security
Obsoletes: 8773 July 2026
Category: Standards Track
ISSN: 2070-1721
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC obsoletes RFC 8773, which was an Experimental RFC.
この文書では、TLS クライアントとサーバーが証明書を使用して認証し、通常の鍵協定アルゴリズムからの対称鍵と外部事前共有鍵 (PSK) を使用した暗号化に基づいて機密性を提供できるようにする TLS 1.3 拡張機能を指定します。この Standards Track RFC は、実験的 RFC であった RFC 8773 を廃止します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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 https://www.rfc-editor.org/info/rfc9973.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9973 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Requirements Language
3. Motivation and Design Rationale
4. Extension Overview
5. Certificate with External PSK Extension
5.1. Companion Extensions
5.2. Authentication
5.3. Keying Material
6. IANA Considerations
7. Security Considerations
8. Privacy Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Changes Since RFC 8773
Acknowledgments
Author's Address
The TLS 1.3 [RFC9846] handshake protocol provides two mutually exclusive forms of server authentication. First, the server can be authenticated by providing a signature certificate and creating a valid digital signature to demonstrate that it possesses the corresponding private key. Second, the server can be authenticated by demonstrating that it possesses a pre-shared key (PSK) that was established by a previous handshake. A PSK that is established in this fashion is called a resumption PSK. A PSK that is established by any other means is called an external PSK.
TLS 1.3 [RFC9846] ハンドシェイク プロトコルは、相互に排他的な 2 つの形式のサーバー認証を提供します。まず、サーバーは、署名証明書を提供し、対応する秘密キーを所有していることを証明する有効なデジタル署名を作成することによって認証できます。次に、サーバーは、以前のハンドシェイクによって確立された事前共有キー (PSK) を所有していることを証明することで認証できます。このようにして確立された PSK を再開 PSK と呼びます。他の手段によって確立された PSK は、外部 PSK と呼ばれます。
A TLS 1.3 server that is authenticating with a certificate may optionally request a certificate from the TLS 1.3 client for authentication, as described in Section 4.3.2 of [RFC9846].
[RFC9846] のセクション 4.3.2 で説明されているように、証明書で認証している TLS 1.3 サーバーは、オプションで認証のために TLS 1.3 クライアントに証明書を要求できます。
This document specifies a TLS 1.3 extension permitting certificate-based authentication and providing an external PSK to be input to the TLS 1.3 key schedule.
この文書では、証明書ベースの認証を許可し、TLS 1.3 鍵スケジュールに入力される外部 PSK を提供する TLS 1.3 拡張機能を指定します。
Please see Appendix A for a list of changes since the publication of [RFC8773].
[RFC8773] の公開以降の変更点のリストについては、付録 A を参照してください。
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] で説明されているように解釈されます。
There are two motivations for using a certificate with an external PSK.
外部 PSK を使用した証明書を使用する理由は 2 つあります。
One motivation is confidentiality protection against the future invention of a Cryptographically Relevant Quantum Computer (CRQC), which would pose a serious challenge for the asymmetric cryptographic algorithms that are widely deployed today, including the digital signature algorithms that are used to authenticate the server in the TLS 1.3 handshake protocol and key agreement algorithm used to establish a pairwise shared secret between the client and server. It is an open question whether or not it is feasible to build such a quantum computer and, if so, when that might happen. However, if such a quantum computer is invented, many of the cryptographic algorithms and the security protocols that use them would become vulnerable. In particular, the TLS 1.3 handshake protocol employs key agreement algorithms that could be broken by the invention of a CRQC [RFC9958]. Including a strong external PSK in the TLS 1.3 key schedule offers confidentiality protection against the long-term quantum computing threat; it requires the attacker to learn the external PSK as well as the shared secret produced by the key agreement algorithm to break confidentiality.
動機の 1 つは、暗号関連量子コンピュータ (CRQC) の将来の発明に対する機密保護です。CRQC は、TLS 1.3 ハンドシェイク プロトコルでサーバーを認証するために使用されるデジタル署名アルゴリズムや、クライアントとサーバーの間でペアごとの共有秘密を確立するために使用される鍵合意アルゴリズムなど、現在広く導入されている非対称暗号アルゴリズムにとって深刻な課題を引き起こす可能性があります。そのような量子コンピューターを構築することが実現可能かどうか、また実現可能であればいつ実現するかについては未解決の問題です。しかし、そのような量子コンピューターが発明された場合、暗号アルゴリズムとそれを使用するセキュリティ プロトコルの多くが脆弱になるでしょう。特に、TLS 1.3 ハンドシェイク プロトコルは、CRQC [RFC9958] の発明によって破られる可能性がある鍵合意アルゴリズムを採用しています。TLS 1.3 鍵スケジュールに強力な外部 PSK を含めることで、長期的な量子コンピューティングの脅威に対する機密保護が提供されます。機密性を破るために、攻撃者は外部 PSK と鍵合意アルゴリズムによって生成された共有秘密を学習する必要があります。
The term "strong external PSK" is used to mean that the PSK that has been generated and distributed in such a way that the invention of a CRQC will not allow the owner of that quantum computer to learn the PSK. While generation and distribution of the PSK are outside the scope of this document, in the context of a CRQC, security of the TLS 1.3 session using the strong external PSK relies on and is implicitly tied to the confidentiality, entropy, and authenticity of the PSK. Thus, the security claims in this document depend on generation and distribution of the strong external PSK.
「強力な外部 PSK」という用語は、CRQC の発明によって量子コンピューターの所有者が PSK を学習できないような方法で生成および配布された PSK を意味するために使用されます。PSK の生成と配布はこのドキュメントの範囲外ですが、CRQC のコンテキストでは、強力な外部 PSK を使用する TLS 1.3 セッションのセキュリティは、PSK の機密性、エントロピー、および信頼性に依存し、暗黙的に関連付けられています。したがって、この文書のセキュリティに関する主張は、強力な外部 PSK の生成と配布に依存します。
When a certificate is used for authentication, the authentication is provided by the existing certificate and digital signature mechanisms. This authentication cannot be relied upon if a CRQC is ever invented. The addition of a strong external PSK in the TLS 1.3 key schedule does not offer improvement against the long-term quantum computing threat regarding authentication.
認証に証明書が使用される場合、認証は既存の証明書およびデジタル署名メカニズムによって提供されます。CRQC が発明されたとしても、この認証は信頼できません。TLS 1.3 鍵スケジュールに強力な外部 PSK を追加しても、認証に関する長期的な量子コンピューティングの脅威に対する改善は得られません。
Likewise, a raw public key can be provided, as described in [RFC7250].
同様に、[RFC7250] で説明されているように、生の公開鍵を提供することもできます。
Quantum-resistant public-key cryptographic algorithms are becoming standards, but it will take many years for TLS 1.3 ciphersuites that use these algorithms to be developed and deployed. In some environments, deployment of a strong external PSK provides protection until these quantum-resistant algorithms are deployed.
耐量子性公開キー暗号アルゴリズムは標準になりつつありますが、これらのアルゴリズムを使用する TLS 1.3 暗号スイートが開発され、展開されるまでには何年もかかります。一部の環境では、強力な外部 PSK を導入すると、これらの耐量子アルゴリズムが導入されるまで保護が提供されます。
Another motivation is the use of a public key with a factory-provisioned secret value for the initial enrollment of a device in an enterprise network [RFC9966].
もう 1 つの動機は、企業ネットワークへのデバイスの初期登録に工場でプロビジョニングされた秘密値を持つ公開キーを使用することです [RFC9966]。
This section provides a brief overview of the "tls_cert_with_extern_psk" extension.
このセクションでは、「tls_cert_with_extern_psk」拡張機能の概要を説明します。
The client includes the "tls_cert_with_extern_psk" extension in the ClientHello message. The "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share", "supported_groups", "psk_key_exchange_modes", and "pre_shared_key" extensions. Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension. These extensions are all described in Section 4.2 of [RFC9846], which also requires the "pre_shared_key" extension to be the last extension in the ClientHello message.
クライアントは、ClientHello メッセージに「tls_cert_with_extern_psk」拡張子を含めます。「tls_cert_with_extern_psk」拡張子には、「key_share」、「supported_groups」、「psk_key_exchange_modes」、および「pre_shared_key」拡張子を付ける必要があります。「tls_cert_with_extern_psk」拡張機能は初期ハンドシェイクでのみ使用することを目的としているため、「early_data」拡張機能と一緒に送信してはなりません。これらの拡張機能はすべて [RFC9846] のセクション 4.2 で説明されており、「pre_shared_key」拡張機能が ClientHello メッセージの最後の拡張機能であることも必要です。
If the client includes both the "tls_cert_with_extern_psk" extension and the "early_data" extension, then the server MUST terminate the connection with an "illegal_parameter" alert.
クライアントに「tls_cert_with_extern_psk」拡張機能と「early_data」拡張機能の両方が含まれている場合、サーバーは「illegal_parameter」アラートで接続を終了しなければなりません。
If the server is willing to use one of the external PSKs listed in the "pre_shared_key" extension and perform certificate-based authentication, then the server includes the "tls_cert_with_extern_psk" extension in the ServerHello message. The "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share" and "pre_shared_key" extensions. If none of the external PSKs in the list provided by the client is acceptable to the server, then the "tls_cert_with_extern_psk" extension is omitted from the ServerHello message.
サーバーが「pre_shared_key」拡張機能にリストされている外部 PSK のいずれかを使用して証明書ベースの認証を実行する場合、サーバーは ServerHello メッセージに「tls_cert_with_extern_psk」拡張機能を含めます。「tls_cert_with_extern_psk」拡張子には、「key_share」拡張子と「pre_shared_key」拡張子を付ける必要があります。クライアントによって提供されたリスト内の外部 PSK がサーバーに受け入れられない場合、「tls_cert_with_extern_psk」拡張子は ServerHello メッセージから省略されます。
When the "tls_cert_with_extern_psk" extension is successfully negotiated, the TLS 1.3 key schedule processing includes both the selected external PSK and the (EC)DHE shared secret value. (EC)DHE refers to Diffie-Hellman over either finite fields or elliptic curves. As a result, the Early Secret, Handshake Secret, and Main Secret (previously known as the Master Secret) values all depend upon the value of the selected external PSK. Of course, the Early Secret does not depend upon the (EC)DHE shared secret.
「tls_cert_with_extern_psk」拡張子のネゴシエーションが成功すると、TLS 1.3 鍵スケジュール処理には、選択された外部 PSK と (EC)DHE 共有秘密値の両方が含まれます。(EC)DHE は、有限体または楕円曲線上の Diffie-Hellman を指します。その結果、Early Secret、Handshake Secret、Main Secret (以前は Master Secret と呼ばれていた) の値はすべて、選択された外部 PSK の値に依存します。もちろん、Early Secret は (EC)DHE 共有秘密に依存しません。
The authentication of the server and optional authentication of the client depend upon the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK. As a result, if a CRQC is ever invented, the digital signature algorithm will need to be replaced with a quantum-resistant one. Failure to do so will result in vulnerable entity and data authentication mechanisms.
サーバーの認証とオプションのクライアントの認証は、証明書内の公開キーを使用して検証できる署名を生成できるかどうかに依存します。認証処理は、選択された外部 PSK によってまったく変更されません。その結果、CRQC が発明された場合には、デジタル署名アルゴリズムを耐量子アルゴリズムに置き換える必要があります。そうしないと、エンティティとデータの認証メカニズムが脆弱になってしまいます。
Each external PSK is associated with a single hash algorithm, which is required by Section 4.2.11 of [RFC9846]. The hash algorithm MUST be set when the PSK is established, with a default of SHA-256.
各外部 PSK は、[RFC9846] のセクション 4.2.11 で要求される単一のハッシュ アルゴリズムに関連付けられます。ハッシュ アルゴリズムは、PSK の確立時に設定する必要があり、デフォルトは SHA-256 です。
This section specifies the "tls_cert_with_extern_psk" extension, which MAY appear in the ClientHello message and ServerHello message. It MUST NOT appear in any other messages. The "tls_cert_with_extern_psk" extension MUST NOT appear in the ServerHello message unless the "tls_cert_with_extern_psk" extension appeared in the preceding ClientHello message. If an implementation recognizes the "tls_cert_with_extern_psk" extension and receives it in any other message, then the implementation MUST abort the handshake with an "illegal_parameter" alert.
このセクションでは、「tls_cert_with_extern_psk」拡張子を指定します。これは、ClientHello メッセージと ServerHello メッセージに表示される場合があります。他のメッセージに表示されてはなりません。「tls_cert_with_extern_psk」拡張子が前述の ClientHello メッセージに出現しない限り、ServerHello メッセージに「tls_cert_with_extern_psk」拡張子を出現させてはなりません (MUST NOT)。実装が「tls_cert_with_extern_psk」拡張を認識し、それを他のメッセージで受信した場合、実装は「illegal_parameter」アラートでハンドシェイクを中止しなければなりません。
The general extension mechanisms enable clients and servers to negotiate the use of specific extensions. Clients request extended functionality from servers with the extensions field in the ClientHello message. If the server responds with a HelloRetryRequest message, then the client sends another ClientHello message as described in Section 4.1.2 of [RFC9846], including the same "tls_cert_with_extern_psk" extension as the original ClientHello message, or aborts the handshake.
一般的な拡張メカニズムにより、クライアントとサーバーは特定の拡張の使用をネゴシエートできます。クライアントは、ClientHello メッセージの拡張フィールドを使用して、サーバーに拡張機能を要求します。サーバーが HelloRetryRequest メッセージで応答した場合、クライアントは [RFC9846] のセクション 4.1.2 で説明されているように、元の ClientHello メッセージと同じ "tls_cert_with_extern_psk" 拡張子を含む別の ClientHello メッセージを送信するか、ハンドシェイクを中止します。
Many server extensions are carried in the EncryptedExtensions message; however, the "tls_cert_with_extern_psk" extension is carried in the ServerHello message. Successful negotiation of the "pre_shared_key" extension enables certificate verification to take place in addition to the inclusion of the external PSK in the key schedule. The external PSK is identified by the "key_share" extension, and the inclusion of the external PSK in the key schedule affects the key used for encryption. The "tls_cert_with_extern_psk" extension is only present in the ServerHello message if the server recognizes the "tls_cert_with_extern_psk" extension and the server possesses one of the external PSKs offered by the client in the "pre_shared_key" extension in the ClientHello message.
多くのサーバー拡張機能は EncryptedExtensions メッセージで伝送されます。ただし、「tls_cert_with_extern_psk」拡張子は ServerHello メッセージに含まれます。「pre_shared_key」拡張機能のネゴシエーションが成功すると、キー スケジュールに外部 PSK を含めるだけでなく、証明書の検証も実行できるようになります。外部 PSK は「key_share」拡張子によって識別され、キー スケジュールに外部 PSK を含めると、暗号化に使用されるキーに影響します。「tls_cert_with_extern_psk」拡張子は、サーバーが「tls_cert_with_extern_psk」拡張子を認識し、サーバーが ClientHello メッセージの「pre_shared_key」拡張子でクライアントによって提供された外部 PSK の 1 つを所有している場合にのみ、ServerHello メッセージに存在します。
The Extension structure is defined in [RFC9846]; it is repeated here for convenience.
拡張構造は [RFC9846] で定義されています。便宜上、ここで繰り返します。
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
The "extension_type" identifies the particular extension type, and the "extension_data" contains information specific to the particular extension type.
「extension_type」は特定の拡張タイプを識別し、「extension_data」には特定の拡張タイプに固有の情報が含まれます。
This document specifies the "tls_cert_with_extern_psk" extension, adding one new type to ExtensionType:
このドキュメントでは、「tls_cert_with_extern_psk」拡張機能を指定し、ExtensionType に 1 つの新しいタイプを追加します。
enum {
tls_cert_with_extern_psk(33), (65535)
} ExtensionType;
The "tls_cert_with_extern_psk" extension is relevant when the client and server possess an external PSK in common that can be used as an input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk" extension is essentially a flag to use the external PSK in the key schedule, and it has the following syntax:
「tls_cert_with_extern_psk」拡張子は、クライアントとサーバーが TLS 1.3 鍵スケジュールへの入力として使用できる共通の外部 PSK を所有する場合に関連します。「tls_cert_with_extern_psk」拡張機能は基本的に、キー スケジュールで外部 PSK を使用するためのフラグであり、次の構文を持ちます。
struct {
select (Handshake.msg_type) {
case client_hello: Empty;
case server_hello: Empty;
};
} CertWithExternPSK;
Section 4 lists the extensions that are required to accompany the "tls_cert_with_extern_psk" extension. Most of those extensions are not impacted in any way by this specification. However, this section discusses the extensions that require additional consideration.
セクション 4 では、「tls_cert_with_extern_psk」拡張機能に付随する必要がある拡張機能をリストします。これらの拡張機能のほとんどは、この仕様による影響をまったく受けません。ただし、このセクションでは追加の考慮が必要な拡張機能について説明します。
The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of [RFC9846]. The "psk_key_exchange_modes" extension restricts the use of both the PSKs offered in this ClientHello and those that the server might supply via a subsequent NewSessionTicket. As a result, when the "psk_key_exchange_modes" extension is included in the ClientHello message, clients MUST include psk_dhe_ke mode. In addition, clients MAY also include psk_ke mode to support a subsequent NewSessionTicket. When the "psk_key_exchange_modes" extension is included in the ClientHello message, servers MUST select the psk_dhe_ke mode for the initial handshake. Servers MUST select a key exchange mode that is listed by the client for subsequent handshakes that include the resumption PSK from the initial handshake.
「psk_key_exchange_modes」拡張は、[RFC9846] のセクション 4.2.9 で定義されています。「psk_key_exchange_modes」拡張機能は、この ClientHello で提供される PSK と、サーバーが後続の NewSessionTicket 経由で提供する PSK の両方の使用を制限します。その結果、「psk_key_exchange_modes」拡張子が ClientHello メッセージに含まれている場合、クライアントは psk_dhe_ke モードを含めなければなりません (MUST)。さらに、クライアントは後続の NewSessionTicket をサポートするために psk_ke モードを含めることもできます (MAY)。「psk_key_exchange_modes」拡張子が ClientHello メッセージに含まれている場合、サーバーは初期ハンドシェイクに psk_dhe_ke モードを選択しなければなりません (MUST)。サーバーは、最初のハンドシェイクからの再開 PSK を含む後続のハンドシェイクに対して、クライアントによってリストされた鍵交換モードを選択しなければなりません (MUST)。
The "pre_shared_key" extension is defined in Section 4.2.11 of [RFC9846]. The syntax is repeated below for convenience. All of the listed PSKs MUST be external PSKs. If a resumption PSK is listed along with the "tls_cert_with_extern_psk" extension, the server MUST abort the handshake with an "illegal_parameter" alert.
「pre_shared_key」拡張子は、[RFC9846] のセクション 4.2.11 で定義されています。便宜上、構文を以下で繰り返します。リストされているすべての PSK は外部 PSK である必要があります。再開 PSK が "tls_cert_with_extern_psk" 拡張子とともにリストされている場合、サーバーは "illegal_parameter" アラートでハンドシェイクを中止しなければなりません (MUST)。
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32..255>;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
"OfferedPsks" contains the list of PSK identities and associated binders for the external PSKs that the client is willing to use with the server.
「OfferedPsks」には、PSK ID のリストと、クライアントがサーバーで使用する外部 PSK の関連バインダーが含まれています。
The identities are a list of external PSK identities that the client is willing to negotiate with the server. Each external PSK has an associated identity that is known to the client and the server; the associated identities may be known to other parties as well. In addition, the binder validation (see below) confirms that the client and server have the same key associated with the identity.
ID は、クライアントがサーバーとネゴシエートする外部 PSK ID のリストです。各外部 PSK には、クライアントとサーバーが認識している関連付けられた ID があります。関連する ID は他の当事者にも知られる可能性があります。さらに、バインダーの検証 (以下を参照) により、クライアントとサーバーが ID に関連付けられた同じキーを持っていることが確認されます。
The "obfuscated_ticket_age" is not used for external PSKs. As stated in Section 4.2.11 of [RFC9846], clients SHOULD set this value to 0, and servers MUST ignore the value.
「obfuscated_ticket_age」は外部 PSK には使用されません。[RFC9846] のセクション 4.2.11 に記載されているように、クライアントはこの値を 0 に設定する必要があり (SHOULD)、サーバーはこの値を無視しなければなりません (MUST)。
The binders are a series of HMAC [RFC2104] values, one for each external PSK offered by the client, in the same order as the identities list. The HMAC value is computed using the binder_key, which is derived from the external PSK, and a partial transcript of the current handshake. Generation of the binder_key from the external PSK is described in Section 7.1 of [RFC9846]. The partial transcript of the current handshake includes a partial ClientHello up to and including the PreSharedKeyExtension.identities field, as described in Section 4.2.11.2 of [RFC9846].
バインダーは一連の HMAC [RFC2104] 値であり、クライアントによって提供される外部 PSK ごとに 1 つずつ、ID リストと同じ順序で並んでいます。HMAC 値は、外部 PSK から派生した binding_key と現在のハンドシェイクの部分的なトランスクリプトを使用して計算されます。外部 PSK からの binding_key の生成については、[RFC9846] のセクション 7.1 で説明されています。[RFC9846] のセクション 4.2.11.2 で説明されているように、現在のハンドシェイクの部分的な転写には、PreSharedKeyExtension.identities フィールドまでの部分的な ClientHello が含まれます。
The "selected_identity" contains the index of the external PSK identity that the server selected from the list offered by the client. As described in Section 4.2.11 of [RFC9846], the server MUST validate the binder value that corresponds to the selected external PSK, and if the binder does not validate, the server MUST abort the handshake with an "illegal_parameter" alert.
「selected_identity」には、サーバーがクライアントから提供されたリストから選択した外部 PSK ID のインデックスが含まれています。[RFC9846] のセクション 4.2.11 に記載されているように、サーバーは選択された外部 PSK に対応するバインダー値を検証しなければなりません (MUST)。バインダーが検証されない場合、サーバーは "illegal_parameter" アラートでハンドシェイクを中止しなければなりません (MUST)。
When the "tls_cert_with_extern_psk" extension is successfully negotiated, authentication of the server depends upon the ability to generate a signature that can be validated with the public key. When the server uses a certificate, this is accomplished by the server sending the Certificate and CertificateVerify messages, as described in Sections 4.4.2 and 4.4.3 of [RFC9846]. Alternatively, the server can use a raw public key, as described in [RFC7250].
「tls_cert_with_extern_psk」拡張子のネゴシエーションが成功すると、サーバーの認証は、公開キーで検証できる署名を生成できるかどうかに依存します。サーバーが証明書を使用する場合、これは、[RFC9846] のセクション 4.4.2 および 4.4.3 で説明されているように、サーバーが Certificate および CertificateVerify メッセージを送信することによって実現されます。あるいは、[RFC7250] で説明されているように、サーバーは生の公開鍵を使用することもできます。
TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. If certificate-based client authentication is desired, this is accomplished by the client sending the Certificate and CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 of [RFC9846].
TLS 1.3 では、PSK が使用されている場合、サーバーが CertificateRequest メッセージを送信することは許可されません。この制限は、「tls_cert_with_extern_psk」拡張機能がネゴシエートされるときに削除され、クライアントとサーバーの両方で証明書ベースの認証が可能になります。証明書ベースのクライアント認証が必要な場合、これは、[RFC9846] のセクション 4.4.2 および 4.4.3 で説明されているように、クライアントが Certificate および CertificateVerify メッセージを送信することによって実現されます。
Section 7.1 of [RFC9846] specifies the TLS 1.3 key schedule. The successful negotiation of the "tls_cert_with_extern_psk" extension requires the key schedule processing to include both the external PSK and the (EC)DHE shared secret value.
[RFC9846] のセクション 7.1 では、TLS 1.3 鍵スケジュールが指定されています。「tls_cert_with_extern_psk」拡張機能のネゴシエーションが成功するには、キー スケジュール処理に外部 PSK と (EC)DHE 共有秘密値の両方を含める必要があります。
If the client and the server have different values associated with the selected external PSK identifier, then the client and the server will compute different values for every entry in the key schedule, which will lead to the client aborting the handshake with a "decrypt_error" alert.
クライアントとサーバーが、選択した外部 PSK 識別子に関連付けられた異なる値を持っている場合、クライアントとサーバーはキー スケジュールのすべてのエントリに対して異なる値を計算するため、クライアントは「decrypt_error」アラートでハンドシェイクを中止することになります。
IANA has updated the "TLS ExtensionType Values" registry [IANA] entry for the "tls_cert_with_extern_psk" extension to reference this document.
IANA は、このドキュメントを参照するために、「tls_cert_with_extern_psk」拡張機能の「TLS ExtensionType Values」レジストリ [IANA] エントリを更新しました。
The Security Considerations in [RFC9846] remain relevant.
[RFC9846] のセキュリティに関する考慮事項は引き続き有効です。
TLS 1.3 [RFC9846] does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is offered by the client and accepted by the server. However, TLS 1.3 does not permit an external PSK to be used in the same fashion as a resumption PSK, and this extension preserves that restriction.
TLS 1.3 [RFC9846] では、PSK が使用されている場合にサーバーが CertificateRequest メッセージを送信することを許可していません。この制限は、「tls_cert_with_extern_psk」拡張機能がクライアントによって提供され、サーバーによって受け入れられると削除されます。ただし、TLS 1.3 では、外部 PSK を再開 PSK と同じ方法で使用することは許可されておらず、この拡張機能ではその制限が維持されています。
Implementations must protect the external PSK. Compromise of the external PSK will make the encrypted session content vulnerable to the future development of a CRQC. However, the generation, distribution, and management of the external PSKs is out of scope for this specification.
実装では外部 PSK を保護する必要があります。外部 PSK が侵害されると、暗号化されたセッション コンテンツが将来の CRQC の開発に対して脆弱になります。ただし、外部 PSK の生成、配布、管理はこの仕様の範囲外です。
Implementers should not transmit the same content on a connection that is protected with an external PSK and a connection that is not. Doing so may allow an eavesdropper to correlate the connections, making the content vulnerable to the future invention of a CRQC.
実装者は、外部 PSK で保護されている接続とそうでない接続で同じコンテンツを送信しないでください。そうすると、盗聴者が接続を関連付けることができ、コンテンツが将来の CRQC の発明に対して脆弱になる可能性があります。
Implementations must generate external PSKs with a secure key-management technique, such as pseudorandom generation of the key or derivation of the key from one or more other secure keys. The use of inadequate pseudorandom number generators (PRNGs) to generate external PSKs can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the external PSKs and search the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area.
実装では、キーの擬似ランダム生成や 1 つ以上の他の安全なキーからのキーの導出など、安全なキー管理技術を使用して外部 PSK を生成する必要があります。外部 PSK を生成するために不適切な擬似乱数ジェネレーター (PRNG) を使用すると、セキュリティがほとんど、またはまったく得られない可能性があります。攻撃者は、キー空間全体をブルートフォースで検索するよりも、外部 PSK を生成した PRNG 環境を再現し、その結果として得られる小さな可能性のセットを検索する方がはるかに簡単であると考える可能性があります。高品質の乱数を生成するのは困難です。[RFC4086] は、この分野に関する重要な指針を提供します。
Implementations must use a ciphersuite that includes a symmetric encryption algorithm with sufficiently large keys. For protection against the future invention of a CRQC, the symmetric key needs to be at least 128 bits. While Grover's algorithm (described in Section 3.1 of [RFC9958]) allows a quantum computer to perform a brute force key search using quadratically fewer steps than would be required with classical computers, there are a number of mitigating factors suggesting that Grover's algorithm will not speed up a brute force symmetric key search as dramatically as one might suspect. First, quantum computing hardware will likely be more expensive to build and use than classical hardware. Second, to obtain the full quadratic speedup, all the steps of Grover's algorithm must be performed in series. However, attacks on cryptography use massively parallel processing; the advantage of Grover's algorithm will be smaller.
実装では、十分に大きなキーを持つ対称暗号化アルゴリズムを含む暗号スイートを使用する必要があります。将来の CRQC の発明から保護するには、対称キーは少なくとも 128 ビットである必要があります。Grover のアルゴリズム ([RFC9958] のセクション 3.1 で説明) を使用すると、量子コンピュータは古典的なコンピュータで必要とされるよりも 2 次的に少ないステップを使用してブルート フォース キー検索を実行できますが、Grover のアルゴリズムではブルート フォース対称キー検索が予想されるほど劇的に高速化されないことを示唆する緩和要因が多数あります。まず、量子コンピューティング ハードウェアは、従来のハードウェアよりも構築および使用にコストがかかる可能性があります。第 2 に、二次関数の完全な高速化を実現するには、Grover アルゴリズムのすべてのステップを連続して実行する必要があります。ただし、暗号化に対する攻撃では大規模な並列処理が使用されます。グローバーのアルゴリズムの利点は小さくなります。
Implementations must use sufficiently large external PSKs. For protection against the future invention of a CRQC, the external PSK needs to be at least 128 bits.
実装では、十分に大きな外部 PSK を使用する必要があります。将来の CRQC の発明から保護するには、外部 PSK は少なくとも 128 ビットである必要があります。
TLS 1.3 [RFC9846] has received careful security analysis, and the following informal reasoning shows that the addition of this extension does not introduce any security defects in the threat model of a traditional adversary, that is, an adversary that does not have access to a CRQC. This extension requires the use of certificates for authentication, but the processing of certificates is unchanged by this extension. This extension requires an external PSK in the key schedule as part of the computation of the Early Secret. In the initial handshake without an external PSK in [RFC9846], the Early Secret is computed as:
TLS 1.3 [RFC9846] は慎重なセキュリティ分析を受けており、次の非公式の推論は、この拡張機能の追加によって、従来の攻撃者、つまり CRQC にアクセスできない攻撃者の脅威モデルにセキュリティ上の欠陥が導入されないことを示しています。この拡張機能では認証に証明書を使用する必要がありますが、証明書の処理はこの拡張機能によって変更されません。この拡張機能では、Early Secret の計算の一部としてキー スケジュールに外部 PSK が必要です。[RFC9846] の外部 PSK を使用しない最初のハンドシェイクでは、Early Secret は次のように計算されます。
Early Secret = HKDF-Extract(0, 0)
With this extension, the Early Secret is computed as:
この拡張機能を使用すると、Early Secret は次のように計算されます。
Early Secret = HKDF-Extract(0, External PSK)
Any entropy contributed by the external PSK can only make the Early Secret better; the external PSK cannot make it worse. Thus, TLS 1.3 continues to meet well-studied confidentiality goals when this extension is used.
外部 PSK によって提供されるエントロピーは、Early Secret をより良くすることしかできません。外部 PSK によって状況が悪化することはありません。したがって、TLS 1.3 は、この拡張機能が使用されている場合でも、十分に研究された機密性の目標を引き続き満たします。
Even when the external PSK is not known to any party other than the client and the server, the external PSK MUST NOT be the sole basis for authentication. The reasoning is explained in Section 4.2 of [K2016]. The authentication of the server and optional authentication of the client depend upon the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK.
外部 PSK がクライアントとサーバー以外の当事者に知られていない場合でも、外部 PSK を認証の唯一の基礎にしてはなりません (MUST NOT)。その理由は、[K2016] のセクション 4.2 で説明されています。サーバーの認証とオプションのクライアントの認証は、証明書内の公開キーを使用して検証できる署名を生成できるかどうかに依存します。認証処理は、選択された外部 PSK によってまったく変更されません。
This external PSK preserves some confidentiality and authentication even if the (EC)DH key agreement is broken by cryptanalysis or the future invention of a CRQC. As long as the attacker does not know the PSK and the key derivation algorithm remains unbroken, the attacker cannot derive the session secrets, even if the attacker is able to compute the (EC)DH shared secret. While the ephemeral (EC)DH private key used during a given TLS 1.3 session is destroyed before the end of a session, the (EC)DH private key would nevertheless be recoverable due to the break of the (EC)DH algorithm. However, a more general notion of "secrecy after key material is destroyed" would still be achievable using external PSKs, if they are managed in a way that ensures their destruction when they are no longer needed, and with the assumption that the symmetric algorithms remain safe against the invention of a CRQC.
この外部 PSK は、(EC)DH 鍵の合意が暗号解読や将来の CRQC の発明によって破られた場合でも、ある程度の機密性と認証を保持します。攻撃者が PSK を知らず、キー導出アルゴリズムが壊れていない限り、たとえ (EC)DH 共有シークレットを計算できたとしても、攻撃者はセッション シークレットを導出することができません。特定の TLS 1.3 セッション中に使用される一時的な (EC)DH 秘密キーはセッションの終了前に破棄されますが、(EC)DH アルゴリズムの中断により (EC)DH 秘密キーは回復可能です。ただし、「鍵マテリアルが破棄された後の機密性」というより一般的な概念は、外部 PSK が不要になったときに破棄されることを保証する方法で管理されており、対称アルゴリズムが CRQC の発明に対して安全であるという前提があれば、外部 PSK を使用しても依然として達成可能です。
The forward-secrecy advantages traditionally associated with ephemeral (EC)DH keys are not easily replaced by external PSKs. The confidentiality and authentication provided by the external PSK depend on whether the external PSK is used for more than one TLS 1.3 session and the parties that know the external PSK. Assuming the (EC)DH key agreement is broken:
従来、一時 (EC)DH キーに関連付けられていた前方秘匿性の利点は、外部 PSK によって簡単に置き換えられるものではありません。外部 PSK によって提供される機密性と認証は、外部 PSK が複数の TLS 1.3 セッションで使用されるかどうか、および外部 PSK を認識している当事者によって異なります。(EC)DH 鍵合意が壊れていると仮定すると、次のようになります。
* If the external PSK is used for a single TLS 1.3 session and it is known only by the client and server, then the usual TLS 1.3 confidentiality and authentication is provided, including the cryptographic separation between TLS 1.3 sessions. Of course, this places a significant burden on the generation and distribution of external PSKs.
* 外部 PSK が単一の TLS 1.3 セッションに使用され、それがクライアントとサーバーのみに知られている場合、TLS 1.3 セッション間の暗号化分離を含む、通常の TLS 1.3 機密性と認証が提供されます。もちろん、これにより、外部 PSK の生成と配布に大きな負担がかかります。
* If the external PSK is used for more than one TLS 1.3 session and it is known only by the client and server, then the confidentiality is limited to the client and server, but there is no cryptographic separation between TLS 1.3 sessions.
* 外部 PSK が複数の TLS 1.3 セッションに使用され、それがクライアントとサーバーのみに知られている場合、機密性はクライアントとサーバーに限定されますが、TLS 1.3 セッション間には暗号化による分離はありません。
* If the external PSK is used for more than one TLS 1.3 session and it is known by the client, server, and others, then the confidentiality is limited to the group that knows the external PSK, but there is no cryptographic separation between TLS 1.3 sessions.
* 外部 PSK が複数の TLS 1.3 セッションで使用され、それがクライアント、サーバー、その他によって知られている場合、機密性は外部 PSK を知っているグループに限定されますが、TLS 1.3 セッション間には暗号化による分離はありません。
This specification does not require that the external PSK is known only by the client and server. The external PSK may be known to a group. Since authentication depends on the public key in a certificate, knowledge of the external PSK by other parties does not enable impersonation. The authentication of the server and optional authentication of the client depend upon the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK.
この仕様では、外部 PSK がクライアントとサーバーのみに知られている必要はありません。外部 PSK はグループに知られている可能性があります。認証は証明書内の公開キーに依存するため、他の当事者が外部 PSK を知っていても偽装は可能になりません。サーバーの認証とオプションのクライアントの認証は、証明書内の公開キーを使用して検証できる署名を生成できるかどうかに依存します。認証処理は、選択された外部 PSK によってまったく変更されません。
Confidentiality depends on the shared secret from (EC)DH, so knowledge of the external PSK by other parties does not enable eavesdropping. However, group members can record the traffic of other members and then decrypt that traffic if they ever gain access to a CRQC. Also, when many parties know the external PSK, there are many opportunities for theft of the external PSK by an attacker. Once an attacker has the external PSK, if they ever gain access to a CRQC, they can decrypt stored traffic in the same manner as a legitimate group member.
機密性は (EC)DH からの共有秘密に依存するため、他の当事者による外部 PSK の知識によって盗聴が可能になることはありません。ただし、グループ メンバーは他のメンバーのトラフィックを記録し、CRQC にアクセスできた場合にはそのトラフィックを復号化できます。また、多くの関係者が外部 PSK を知っている場合、攻撃者によって外部 PSK が盗まれる機会が多くなります。攻撃者が外部 PSK を取得すると、CRQC にアクセスできるようになると、正規のグループ メンバーと同じ方法で保存されたトラフィックを復号化できます。
TLS 1.3 key derivation makes use of the HMAC-based Key Derivation Function (HKDF) algorithm, which depends upon the HMAC [RFC2104] construction and a hash function. This extension provides the desired protection for the session secrets, as long as HMAC with the selected hash function is a pseudorandom function (PRF) [GGM1986].
TLS 1.3 鍵導出では、HMAC [RFC2104] 構造とハッシュ関数に依存する HMAC ベースの鍵導出関数 (HKDF) アルゴリズムが利用されます。この拡張機能は、選択されたハッシュ関数を持つ HMAC が擬似乱数関数 (PRF) である限り、セッション秘密に必要な保護を提供します [GGM1986]。
TLS 1.3 [RFC9846] takes a conservative approach to PSKs; they are bound to a specific hash function and KDF. By contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive another PSK for exclusive use with TLS 1.3 using the mechanism specified in [RFC9258].
TLS 1.3 [RFC9846] は PSK に対して保守的なアプローチを採用しています。それらは特定のハッシュ関数と KDF にバインドされています。対照的に、TLS 1.2 [RFC5246] では、PSK を任意のハッシュ関数および TLS 1.2 PRF で使用することができます。したがって、最も安全なアプローチは、PSK を TLS 1.2 のみ、または TLS 1.3 のみで使用することです。1 つの PSK が与えられると、[RFC9258] で指定されたメカニズムを使用して、TLS 1.2 専用の PSK を導出し、TLS 1.3 専用の別の PSK を導出できます。
Appendix F.6 of [RFC9846] discusses identity-exposure attacks on PSKs. Also, Appendix C.4 of [RFC9846] discusses tracking prevention. The guidance in these sections remain relevant.
[RFC9846] の付録 F.6 では、PSK に対する ID 暴露攻撃について説明しています。また、[RFC9846] の付録 C.4 では追跡防止について説明しています。これらのセクションのガイダンスは引き続き有効です。
If an external PSK identity is used for multiple connections, then an observer will generally be able track clients and/or servers across connections. The rotation of the external PSK identity or the use of the "encrypted_client_hello" extension [RFC9849] can mitigate this risk.
外部 PSK ID が複数の接続に使用される場合、オブザーバーは通常、接続全体でクライアントやサーバーを追跡できます。外部 PSK ID のローテーション、または「encrypted_client_hello」拡張 [RFC9849] の使用により、このリスクを軽減できます。
This extension makes use of external PSKs to improve resilience against attackers that gain access to a CRQC in the future and provides authentication for initial enrollment of devices in an enterprise network. This extension is always accompanied by the "pre_shared_key" extension to provide the PSK identities in plaintext in the ClientHello message. Passive observation of the these PSK identities will aid an attacker in tracking users or devices that make use of this extension.
この拡張機能は外部 PSK を利用して、将来 CRQC にアクセスする攻撃者に対する回復力を向上させ、企業ネットワークへのデバイスの初期登録の認証を提供します。この拡張機能には常に「pre_shared_key」拡張機能が付属しており、ClientHello メッセージに平文で PSK ID を提供します。これらの PSK ID を受動的に観察すると、攻撃者がこの拡張機能を利用するユーザーやデバイスを追跡するのに役立ちます。
[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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[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>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[Err7598] RFC Errata, Erratum ID 7598, RFC 8773,
<https://www.rfc-editor.org/errata/eid7598>.
[Err8888] RFC Errata, Erratum ID 8888, RFC 8773,
<https://www.rfc-editor.org/errata/eid8888>.
[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to
construct random functions", Journal of the ACM (JACM),
vol. 33, no. 4, pp. 792-807, DOI 10.1145/6490.6503, August
1986, <https://dl.acm.org/doi/10.1145/6490.6503>.
[IANA] IANA, "TLS ExtensionType Values",
<https://www.iana.org/assignments/tls-extensiontype-
values>.
[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3)", Cryptology ePrint Archive,
Paper 2016/711, 2016, <https://eprint.iacr.org/2016/711>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[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>.
[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>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/info/rfc9258>.
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
<https://www.rfc-editor.org/info/rfc9958>.
[RFC9966] Friel, O. and D. Harkins, "Bootstrapped TLS Authentication
with Proof of Knowledge", RFC 9966, DOI 10.17487/RFC9966,
May 2026, <https://www.rfc-editor.org/info/rfc9966>.
The status elevation from Experimental RFC to Standards Track RFC is the most significant change in this document.
Experimental RFC から Standards Track RFC へのステータスの昇格は、この文書における最も重要な変更です。
In addition to minor editorial updates, which include a change to the title, the following changes were made:
タイトルの変更を含む小規模な編集上の更新に加えて、次の変更が加えられました。
* Correct the order of the arguments to HKDF-Extract when an external PSK is present [Err8888].
* 外部 PSK が存在する場合、HKDF-Extract への引数の順序を修正します [Err8888]。
* The client must include the "supported_groups" extension in the ClientHello message.
* クライアントは、ClientHello メッセージに「supported_groups」拡張子を含める必要があります。
* Expand the motivation discussion to talk about protection against the future development of a CRQC and enrollment in enterprise networks.
* 動機付けの議論を拡大して、将来の CRQC の開発と企業ネットワークへの登録に対する保護について話し合います。
* Separate the discussion of confidentiality and authentication. The inclusion of the external PSK offers some confidentiality protection against the future invention of a CRQC, but the external PSK does not improve authentication.
* 機密性と認証については分けて説明します。外部 PSK を含めることで、将来の CRQC の発明に対する機密性の保護が提供されますが、外部 PSK によって認証が向上するわけではありません。
* Correct RFC Erratum 7598 [Err7598].
* RFC 正誤表 7598 [Err7598] を修正します。
* Add a discussion of TLS Encrypted Client Hello to the Privacy Considerations section.
* TLS 暗号化 Client Hello に関する説明を「プライバシーに関する考慮事項」セクションに追加します。
* Adopt terminology that has become widely accepted, such as CRQC and Main Secret (instead of Master Secret).
* CRQC や (マスター シークレットの代わりに) メイン シークレットなど、広く受け入れられている用語を採用します。
* Provide URLs for all references.
* すべての参考文献の URL を提供します。
Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind, Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for their review and comments on the Internet-Drafts that eventually became RFC 8773; their efforts have improved the document.
最終的に RFC 8773 となったインターネット ドラフトに関するレビューとコメントをくださった Liliya Akhmetzyanova、Roman Danyliw、Christian Huitema、Ben Kaduk、Geoffrey Keating、Hugo Krawczyk、Mirja Kühlewind、Nikos Mavrogiannopoulos、Nick Sullivan、Martin Thomson、および Peter Yee に多大な感謝を申し上げます。彼らの努力により文書は改善されました。
Many thanks to Mike Bishop, Deb Cooley, Owen Friel, Britta Hale, Dan Harkins, Christian Huitema, Joe Mandel, John Preuß Mattsson, Eric Rescorla, Joe Salowey, Muhammad Usama Sardar, Paul Wouters, and Peter Yee for their review and comments on the updates to RFC 8773 that became this document; their efforts have improved the document.
この文書となった RFC 8773 の更新に関するレビューとコメントをくださった Mike Bishop、Deb Cooley、Owen Friel、Britta Hale、Dan Harkins、Christian Huitema、Joe Mandel、John Preuß Mattsson、Eric Rescorla、Joe Salowey、Muhammad Usama Sardar、Paul Wouters、Peter Yee に多大な感謝を申し上げます。彼らの努力により文書は改善されました。
Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
United States of America
Email: housley@vigilsec.com