RFC 9261 - Exported Authenticators in TLS (RFC 9261) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9261.html
タイトル : RFC 9261 - TLSのエクスポートされた認証者（RFC 9261）
翻訳編集 : 自動生成

[要約] RFC 9261は、TLSやDTLSを拡張し、ピアがX.509証明書などの身元を証明できるメカニズムを提供します。これにより、ピアが証明をエクスポートし、他のピアに転送して検証できます。

Internet Engineering Task Force (IETF)                       N. Sullivan
Request for Comments: 9261                               Cloudflare Inc.
Category: Standards Track                                      July 2022
ISSN: 2070-1721

Exported Authenticators in TLS

TLSでエクスポートされた認証器

Abstract

概要

This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer.

このドキュメントでは、輸送層のセキュリティ（TLS）またはデータグラムトランスポートレイヤーセキュリティ（DTLS）に基づいて構築され、ピアがX.509証明書などのアイデンティティの所有権の証明を提供できるようにします。この証明は、1つのピアによってエクスポートされ、バンドから他のピアに送信され、受信ピアによって検証されます。

Status of This Memo

本文書の位置付け

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.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。

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

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

著作権表示

著作権（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. 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。

Table of Contents

   1.  Introduction
   2.  Conventions and Terminology
   3.  Message Sequences
   4.  Authenticator Request
   5.  Authenticator
     5.1.  Authenticator Keys
     5.2.  Authenticator Construction
       5.2.1.  Certificate
       5.2.2.  CertificateVerify
       5.2.3.  Finished
       5.2.4.  Authenticator Creation
   6.  Empty Authenticator
   7.  API Considerations
     7.1.  The "request" API
     7.2.  The "get context" API
     7.3.  The "authenticate" API
     7.4.  The "validate" API
   8.  IANA Considerations
     8.1.  Update of the TLS ExtensionType Registry
     8.2.  Update of the TLS Exporter Labels Registry
     8.3.  Update of the TLS HandshakeType Registry
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

This document provides a way to authenticate one party of a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) connection to its peer using authentication messages created after the session has been established. This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed. This proof of authentication can be exported and transmitted out of band from one party to be validated by its peer.

このドキュメントは、セッションが確立された後に作成された認証メッセージを使用して、トランスポートレイヤーセキュリティ（TLS）またはDatagram Transport Layer Security（DTLS）接続をピアに認証する方法を提供します。これにより、クライアントとサーバーの両方が、握手が完了した後、いつでも追加のアイデンティティの所有権を証明することができます。この認証の証明は、1つの当事者からバンドから送信して、そのピアによって検証されることができます。

This mechanism provides two advantages over the authentication that TLS and DTLS natively provide:

このメカニズムは、TLSとDTLSがネイティブに提供する認証よりも2つの利点を提供します。

multiple identities: Endpoints that are authoritative for multiple identities, but that do not have a single certificate that includes all of the identities, can authenticate additional identities over a single connection.

複数のアイデンティティ：複数のアイデンティティに対して権威あるエンドポイントですが、すべてのIDを含む単一の証明書を持っていないため、単一の接続で追加のIDを認証できます。

spontaneous authentication: After a connection is established, endpoints can authenticate in response to events in a higher-layer protocol; they can also integrate more context (such as context from the application).

自発認証：接続が確立された後、エンドポイントは、高層プロトコルのイベントに応じて認証できます。また、より多くのコンテキスト（アプリケーションからのコンテキストなど）を統合することもできます。

Versions of TLS prior to TLS 1.3 used renegotiation as a way to enable post-handshake client authentication given an existing TLS connection. The mechanism described in this document may be used to replace the post-handshake authentication functionality provided by renegotiation. Unlike renegotiation, Exported Authenticator-based post-handshake authentication does not require any changes at the TLS layer.

TLS 1.3の前のTLSのバージョンは、既存のTLS接続を考慮して、ポストハンドシェイククライアント認証を有効にする方法として再交渉を使用しました。このドキュメントで説明されているメカニズムは、再交渉によって提供されるポストハンドシェイク認証機能を置き換えるために使用できます。再交渉とは異なり、エクスポートされた認証機ベースのポストハンドシェイク認証は、TLSレイヤーで変更を必要としません。

Post-handshake authentication is defined in TLS 1.3 Section 4.6.2 of [RFC8446], but it has the disadvantage of requiring additional state to be stored as part of the TLS state machine. Furthermore, the authentication boundaries of TLS 1.3 post-handshake authentication align with TLS record boundaries, which are often not aligned with the authentication boundaries of the higher-layer protocol. For example, multiplexed connection protocols like HTTP/2 [RFC9113] do not have a notion of which TLS record a given message is a part of.

ポストハンドシェイク認証は、[RFC8446]のTLS 1.3セクション4.6.2で定義されていますが、TLS状態マシンの一部として追加の状態を保存する必要があるという不利な点があります。さらに、TLS 1.3ポストハンドシェイク認証の認証境界は、TLSの記録境界に沿っています。たとえば、HTTP/2 [RFC9113]のような多重化接続プロトコルには、特定のメッセージが一部であるTLSを記録する概念はありません。

Exported Authenticators are meant to be used as a building block for application protocols. Mechanisms such as those required to advertise support and handle authentication errors are not handled by TLS (or DTLS).

エクスポートされた認証機は、アプリケーションプロトコルのビルディングブロックとして使用することを目的としています。サポートを宣伝して認証エラーを処理するために必要なメカニズムは、TLS（またはDTL）によって処理されません。

The minimum version of TLS and DTLS required to implement the mechanisms described in this document are TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]. (These were obsoleted by TLS 1.3 [RFC8446] and DTLS 1.3 [RFC9147].)

このドキュメントで説明されているメカニズムを実装するために必要なTLSおよびDTLの最小バージョンは、TLS 1.2 [RFC5246]およびDTLS 1.2 [RFC6347]です。（これらはTLS 1.3 [RFC8446]およびDTLS 1.3 [RFC9147]によって廃止されました。）

2. Conventions and Terminology

2. 慣習と用語

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

This document uses terminology such as client, server, connection, handshake, endpoint, and peer that are defined in Section 1.1 of [RFC8446]. The term "initial connection" refers to the (D)TLS connection from which the Exported Authenticator messages are derived.

このドキュメントでは、[RFC8446]のセクション1.1で定義されているクライアント、サーバー、接続、ハンドシェイク、エンドポイント、ピアなどの用語を使用します。「初期接続」という用語は、エクスポートされた認証装置メッセージが導出される（d）TLS接続を指します。

3. Message Sequences

3. メッセージシーケンス

There are two types of messages defined in this document: authenticator requests and authenticators. These can be combined in the following three sequences:

このドキュメントには、Authenticator RequestsとAuthenticatorsの2種類のメッセージが定義されています。これらは、次の3つのシーケンスで組み合わせることができます。

Client Authentication

クライアント認証

* Server generates authenticator request

* サーバーは認証機リクエストを生成します

* Client generates Authenticator from Server's authenticator request

* クライアントは、ServerのAuthenticatorリクエストからAuthenticatorを生成します

* Server validates Client's authenticator

* サーバーはクライアントの認証器を検証します

Server Authentication

サーバー認証

* Client generates authenticator request

* クライアントは認証機リクエストを生成します

* Server generates authenticator from Client's authenticator request

* サーバーは、クライアントのAuthenticatorリクエストから認証器を生成します

* Client validates Server's authenticator

* クライアントはサーバーの認証器を検証します

Spontaneous Server Authentication

自発的なサーバー認証

* Server generates authenticator

* サーバーは認証器を生成します

* Client validates Server's authenticator

* クライアントはサーバーの認証器を検証します

4. Authenticator Request

4. Authenticatorリクエスト

The authenticator request is a structured message that can be created by either party of a (D)TLS connection using data exported from that connection. It can be transmitted to the other party of the (D)TLS connection at the application layer. The application-layer protocol used to send the authenticator request SHOULD use a secure transport channel with equivalent security to TLS, such as QUIC [RFC9001], as its underlying transport to keep the request confidential. The application MAY use the existing (D)TLS connection to transport the authenticator.

Authenticatorリクエストは、その接続からエクスポートされたデータを使用して（d）TLS接続のいずれかのパーティによって作成できる構造化されたメッセージです。アプリケーションレイヤーで（d）TLS接続の相手に送信できます。Authenticator Requestの送信に使用されるアプリケーション層プロトコルは、リクエストを機密保持するための基礎となるトランスポートとして、QUIC [RFC9001]などのTLSに同等のセキュリティを備えた安全なトランスポートチャネルを使用する必要があります。アプリケーションは、既存の（d）TLS接続を使用して、認証器を輸送できます。

An authenticator request message can be constructed by either the client or the server. Server-generated authenticator requests use the CertificateRequest message from Section 4.3.2 of [RFC8446]. Client-generated authenticator requests use a new message, called the "ClientCertificateRequest", that uses the same structure as CertificateRequest. (Note that the latter is not a request for a client certificate, but rather a certificate request generated by the client.) These message structures are used even if the connection protocol is TLS 1.2 or DTLS 1.2.

認証者要求メッセージは、クライアントまたはサーバーのいずれかによって作成できます。サーバーで生成された認証機リクエスト[RFC8446]のセクション4.3.2からのCertificateRequestメッセージを使用します。クライアントで生成されたAuthenticatorリクエストは、cirtimateRequestと同じ構造を使用する「clientCertificAterequest」と呼ばれる新しいメッセージを使用します。（後者はクライアント証明書のリクエストではなく、クライアントによって生成された証明書要求であることに注意してください。）これらのメッセージ構造は、接続プロトコルがTLS 1.2またはDTLS 1.2である場合でも使用されます。

The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator. These are encoded as TLS handshake messages, including length and type fields. They do not include any TLS record-layer framing and are not encrypted with a handshake or application-data key.

cirtimaterateRequestおよびclientCertificateRequestメッセージは、認証者のリクエストでパラメーターを定義するために使用されます。これらは、長さや型フィールドを含むTLSハンドシェイクメッセージとしてエンコードされます。TLSレコードレイヤーフレーミングは含まれておらず、握手またはアプリケーションデータキーで暗号化されていません。

The structures are defined to be:

構造は次のように定義されています。

      struct {
         opaque certificate_request_context<0..2^8-1>;
         Extension extensions<2..2^16-1>;
      } ClientCertificateRequest;

      struct {
         opaque certificate_request_context<0..2^8-1>;
         Extension extensions<2..2^16-1>;
      } CertificateRequest;

certificate_request_context: An opaque string that identifies the authenticator request and that will be echoed in the authenticator message. A certificate_request_context value MUST be unique for each authenticator request within the scope of a connection (preventing replay and context confusion). The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from precomputing valid authenticators. For example, the application may choose this value to correspond to a value used in an existing data structure in the software to simplify implementation.

certificate_request_context：Authenticatorリクエストを識別し、Authenticatorメッセージにエコーされる不透明な文字列。Certificate_Request_Context値は、接続の範囲内で認証機リクエストごとに一意でなければなりません（リプレイとコンテキストの混乱の防止）。証明書_REQUEST_CONTEXTは、ピアが有効な認証を事前に計算することからピアの秘密鍵に一時的にアクセスできる攻撃者を防ぐために、ピアにとって予測不可能（ランダムにそれを生成することによって）を選択する必要があります。たとえば、アプリケーションは、ソフトウェアの既存のデータ構造で使用される値に対応するようにこの値を選択して、実装を簡素化する場合があります。

extensions: The set of extensions allowed in the structures of CertificateRequest and ClientCertificateRequest is comprised of those defined in the "TLS ExtensionType Values" IANA registry containing CR in the "TLS 1.3" column (see [IANA-TLS] and [RFC8447]). In addition, the set of extensions in the ClientCertificateRequest structure MAY include the server_name extension [RFC6066].

エクステンション：証明書およびClientCertificaterequestの構造で許可される拡張機能のセットは、「TLS 1.3」列にCRを含む「TLS拡張タイプ値」で定義されたもので構成されています（[IANA-TLS]および[RFC8447]を参照）。さらに、ClientCertificAtereQuest構造の拡張セットには、Server_Name拡張子[RFC6066]が含まれる場合があります。

The uniqueness requirements of the certificate_request_context apply across CertificateRequest and ClientCertificateRequest messages that are used as part of authenticator requests. A certificate_request_context value used in a ClientCertificateRequest cannot be used in an authenticator CertificateRequest on the same connection, and vice versa. There is no impact if the value of a certificate_request_context used in an authenticator request matches the value of a certificate_request_context in the handshake or in a post-handshake message.

certificate_request_contextの一意性要件は、Authenticatorリクエストの一部として使用されるCertificateRecerequestおよびclientCertificateRequestメッセージに適用されます。Client CertificAterequestで使用される証明書_Request_Context値は、同じ接続のAuthenticator ErcidenterateRequestで使用することはできません。その逆も同様です。Authenticatorリクエストで使用されている証明書_REQUEST_CONTEXTの値が、ハンドシェイクまたはポストハンドシェイクメッセージの証明書_REQUEST_CONTEXTの値と一致する場合に影響はありません。

5. Authenticator

5. 認証者

The authenticator is a structured message that can be exported from either party of a (D)TLS connection. It can be transmitted to the other party of the (D)TLS connection at the application layer. The application-layer protocol used to send the authenticator SHOULD use a secure transport channel with equivalent security to TLS, such as QUIC [RFC9001], as its underlying transport to keep the authenticator confidential. The application MAY use the existing (D)TLS connection to transport the authenticator.

Authenticatorは、（d）TLS接続のいずれかの当事者からエクスポートできる構造化されたメッセージです。アプリケーションレイヤーで（d）TLS接続の相手に送信できます。Authenticatorの送信に使用されるアプリケーション層プロトコルは、Authenticatorの機密を維持するための基礎となるトランスポートとして、QUIC [RFC9001]などのTLSに同等のセキュリティを備えた安全な輸送チャネルを使用する必要があります。アプリケーションは、既存の（d）TLS接続を使用して、認証器を輸送できます。

An authenticator message can be constructed by either the client or the server given an established (D)TLS connection; an identity, such as an X.509 certificate; and a corresponding private key. Clients MUST NOT send an authenticator without a preceding authenticator request; for servers, an authenticator request is optional. For authenticators that do not correspond to authenticator requests, the certificate_request_context is chosen by the server.

確立された（d）TLS接続が与えられたクライアントまたはサーバーのいずれかによって認証器メッセージを構築できます。X.509証明書などのID。対応する秘密鍵。クライアントは、先行認証要求なしで認証機を送信してはなりません。サーバーの場合、Authenticatorリクエストはオプションです。Authenticatorリクエストに対応しない認証機の場合、certificate_request_contextがサーバーによって選択されます。

5.1. Authenticator Keys

5.1. 認証キー

Each authenticator is computed using a Handshake Context and Finished MAC (Message Authentication Code) Key derived from the (D)TLS connection. These values are derived using an exporter as described in Section 4 of [RFC5705] (for (D)TLS 1.2) or Section 7.5 of [RFC8446] (for (D)TLS 1.3). For (D)TLS 1.3, the exporter_master_secret MUST be used, not the early_exporter_master_secret. These values use different labels depending on the role of the sender:

各認証機は、（d）TLS接続から派生した握手コンテキストと完成したMac（メッセージ認証コード）キーを使用して計算されます。これらの値は、[RFC5705]のセクション4（（d）TLS 1.2の場合）または[RFC8446]のセクション7.5（（d）TLS 1.3）のセクション7.5で説明されているように輸出者を使用して導出されます。（d）1.3の場合、exporter_master_secretを使用する必要があります。これらの値は、送信者の役割に応じて異なるラベルを使用します。

* The Handshake Context is an exporter value that is derived using the label "EXPORTER-client authenticator handshake context" or "EXPORTER-server authenticator handshake context" for authenticators sent by the client or server, respectively.

* ハンドシェイクコンテキストは、クライアントまたはサーバーがそれぞれ送信した認証機の「Exporter-Client Authenticator Handshake Context」または「Exporter-Server Authentacator Handshake Context」というラベル「Exporter Client Authenticator Context」または「Exporter-Server Authentacator Context」を使用して導出される輸出者値です。

* The Finished MAC Key is an exporter value derived using the label "EXPORTER-client authenticator finished key" or "EXPORTER-server authenticator finished key" for authenticators sent by the client or server, respectively.

* 完成したMACキーは、クライアントまたはサーバーがそれぞれ送信した認証機の「Exporter-Client Authenticator Finisht Key」または「Exporter-Server Autherver Autherver Autherver Finisht Key」を使用して導出された輸出者値です。

The context_value used for the exporter is empty (zero length) for all four values. There is no need to include additional context information at this stage because the application-supplied context is included in the authenticator itself. The length of the exported value is equal to the length of the output of the hash function associated with the selected ciphersuite (for TLS 1.3) or the hash function used for the pseudorandom function (PRF) (for (D)TLS 1.2). Exported Authenticators cannot be used with (D)TLS 1.2 ciphersuites that do not use the TLS PRF and with TLS 1.3 ciphersuites that do not have an associated hash function. This hash is referred to as the "authenticator hash".

Exporterに使用されるContext_Valueは、4つの値すべてに対して空（ゼロの長さ）です。アプリケーションサプライコンテキストが認証器自体に含まれているため、この段階で追加のコンテキスト情報を含める必要はありません。エクスポートされた値の長さは、選択された暗号化（TLS 1.3の場合）に関連付けられたハッシュ関数の出力の長さまたは擬似ランダム関数（PRF）に使用されるハッシュ関数（（d）TLS 1.2）に等しくなります。エクスポートされた認証器は、（d）TLS PRFを使用していないTLS 1.2シファースーツと、関連するハッシュ関数を持たないTLS 1.3 cipherSuitesで使用することはできません。このハッシュは「認証機ハッシュ」と呼ばれます。

To avoid key synchronization attacks, Exported Authenticators MUST NOT be generated or accepted on (D)TLS 1.2 connections that did not negotiate the extended master secret extension [RFC7627].

主要な同期攻撃を回避するには、エクスポートされた認証器を（d）拡張マスターシークレットエクステンション[RFC7627]を交渉しなかった（d）TLS 1.2接続で生成または受け入れてはなりません。

5.2. Authenticator Construction

5.2. 認証機の構造

An authenticator is formed from the concatenation of TLS 1.3 Certificate, CertificateVerify, and Finished messages [RFC8446]. These messages are encoded as TLS handshake messages, including length and type fields. They do not include any TLS record-layer framing and are not encrypted with a handshake or application-data key.

Authenticatorは、TLS 1.3証明書、CertificateVerify、および完成したメッセージ[RFC8446]の連結から形成されます。これらのメッセージは、長さや型フィールドを含むTLSハンドシェイクメッセージとしてエンコードされます。TLSレコードレイヤーフレーミングは含まれておらず、握手またはアプリケーションデータキーで暗号化されていません。

If the peer populating the certificate_request_context field in an authenticator's Certificate message has already created or correctly validated an authenticator with the same value, then no authenticator should be constructed. If there is no authenticator request, the extensions are chosen from those presented in the (D)TLS handshake's ClientHello. Only servers can provide an authenticator without a corresponding request.

Authenticatorの証明書メッセージでcertificate_Request_Contextフィールドを入力しているピアが、同じ値で認証器をすでに作成または正しく検証している場合、認証機を構築する必要はありません。Authenticatorリクエストがない場合、拡張機能は（d）TLSハンドシェイクのclienthelloで提示されたものから選択されます。対応するリクエストなしで認証器を提供できるサーバーのみが可能です。

ClientHello extensions are used to determine permissible extensions in the server's unsolicited Certificate message in order to follow the general model for extensions in (D)TLS in which extensions can only be included as part of a Certificate message if they were previously sent as part of a CertificateRequest message or ClientHello message. This ensures that the recipient will be able to process such extensions.

clienthello拡張機能は、（d）TLSの拡張機能の一般的なモデルに従うために、サーバーの未承諾の証明書メッセージの許容拡張機能を決定するために使用されます。certificaterequestメッセージまたはclienthelloメッセージ。これにより、受信者がそのような拡張機能を処理できるようになります。

5.2.1. Certificate

5.2.1. 証明書

The Certificate message contains the identity to be used for authentication, such as the end-entity certificate and any supporting certificates in the chain. This structure is defined in Section 4.4.2 of [RFC8446].

証明書メッセージには、エンドエンティティ証明書やチェーン内のサポート証明書など、認証に使用されるIDが含まれています。この構造は、[RFC8446]のセクション4.4.2で定義されています。

The Certificate message contains an opaque string called "certificate_request_context", which is extracted from the authenticator request, if present. If no authenticator request is provided, the certificate_request_context can be chosen arbitrarily; however, it MUST be unique within the scope of the connection and be unpredictable to the peer.

証明書メッセージには、「certificate_request_context」と呼ばれる不透明な文字列が含まれています。Authenticatorリクエストが提供されていない場合、certificate_request_contextを任意に選択できます。ただし、接続の範囲内で一意であり、ピアにとって予測不可能でなければなりません。

Certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of (D)TLS. In particular, the entries of certificate_list MUST be valid for the signature algorithms indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert" extensions, as described in Section 4.2.3 of [RFC8446] for (D)TLS 1.3 or in Sections 7.4.2 and 7.4.6 of [RFC5246] for (D)TLS 1.2.

証明書メッセージで選択された証明書は、（d）TLSのネゴシエートバージョンの証明書メッセージの要件に準拠する必要があります。特に、certificate_listのエントリは、「signature_algorithms」および「signature_algorithms_cert」拡張機能のピアによって示される署名アルゴリズムに対して有効でなければなりません。（d）TLS 1.2の[RFC5246]の.2および7.4.6。

In addition to "signature_algorithms" and "signature_algorithms_cert", the "server_name" [RFC6066], "certificate_authorities" (Section 4.2.4 of [RFC8446]), and "oid_filters" (Section 4.2.5 of [RFC8446]) extensions are used to guide certificate selection.

「signature_algorithms」および「signature_algorithms_cert」、「server_name」[rfc6066]、「certificate_authorities」（[rfc8446]のセクション4.2.4）、および「oid_filters」（rfc846]のセクション4.2.5）に加えて、拡張は使用されます。証明書の選択をガイドする。

Only the X.509 certificate type defined in [RFC8446] is supported. Alternative certificate formats such as Raw Public Keys as described in [RFC7250] are not supported in this version of the specification and their use in this context has not yet been analyzed.

[RFC8446]で定義されたX.509証明書タイプのみがサポートされています。[RFC7250]で説明されている生の公開キーなどの代替証明書形式は、このバージョンの仕様ではサポートされておらず、このコンテキストでの使用はまだ分析されていません。

If an authenticator request was provided, the Certificate message MUST contain only extensions present in the authenticator request. Otherwise, the Certificate message MUST contain only extensions present in the (D)TLS ClientHello. Unrecognized extensions in the authenticator request MUST be ignored.

Authenticatorリクエストが提供された場合、証明書メッセージには、Authenticatorリクエストに存在する拡張機能のみを含める必要があります。それ以外の場合、証明書メッセージには（d）TLS clienthelloに存在する拡張機能のみを含める必要があります。認証機リクエストの認識されていない拡張機能は無視する必要があります。

5.2.2. CertificateVerify

5.2.2. cermostverify

This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its identity. The format of this message is taken from TLS 1.3:

このメッセージは、エンドポイントがそのアイデンティティに対応する秘密鍵を持っていることを明示的に証明するために使用されます。このメッセージの形式は、TLS 1.3から取得されます。

      struct {
         SignatureScheme algorithm;
         opaque signature<0..2^16-1>;
      } CertificateVerify;

The algorithm field specifies the signature algorithm used (see Section 4.2.3 of [RFC8446] for the definition of this field). The signature is a digital signature using that algorithm.

アルゴリズムフィールドは、使用される署名アルゴリズムを指定します（このフィールドの定義については、[RFC8446]のセクション4.2.3を参照）。署名は、そのアルゴリズムを使用したデジタル署名です。

The signature scheme MUST be a valid signature scheme for TLS 1.3. This excludes all RSASSA-PKCS1-v1_5 algorithms and combinations of Elliptic Curve Digital Signature Algorithm (ECDSA) and hash algorithms that are not supported in TLS 1.3.

署名スキームは、TLS 1.3の有効な署名スキームでなければなりません。これは、TLS 1.3でサポートされていない楕円曲線デジタル署名アルゴリズム（ECDSA）およびハッシュアルゴリズムのすべてのRSASSA-PKCS1-V1_5アルゴリズムと組み合わせを除外します。

If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes present in the "signature_algorithms" extension of the authenticator request. Otherwise, with spontaneous server authentication, the signature algorithm used MUST be chosen from the "signature_algorithms" sent by the peer in the ClientHello of the (D)TLS handshake. If there are no available signature algorithms, then no authenticator should be constructed.

Authenticatorリクエストが存在する場合、署名アルゴリズムは、Authenticatorリクエストの「signature_algorithms」拡張に存在する署名スキームの1つから選択する必要があります。それ以外の場合、自発的なサーバー認証を使用して、使用される署名アルゴリズムは、（d）TLSハンドシェイクのクライアントヘロでピアが送信した「signature_algorithms」から選択する必要があります。利用可能な署名アルゴリズムがない場合は、認証器を構築する必要はありません。

The signature is computed using the chosen signature scheme over the concatenation of:

署名は、以下の連結に関する選択された署名スキームを使用して計算されます。

* a string that consists of octet 32 (0x20) repeated 64 times,

* 64回繰り返されるオクテット32（0x20）で構成される文字列、

* the context string "Exported Authenticator" (which is not NUL-terminated),

* コンテキスト文字列「Export Authenticator」（Null-Terminatedではありません）、

* a single 0 octet that serves as the separator, and

* セパレーターとして機能する単一の0オクテット、そして

* the hashed authenticator transcript.

* ハッシュされた認証因子トランスクリプト。

The authenticator transcript is the hash of the concatenated Handshake Context, authenticator request (if present), and Certificate message:

認証器のトランスクリプトは、連結された握手コンテキスト、認証機リクエスト（存在する場合）、および証明書メッセージのハッシュです。

Hash(Handshake Context || authenticator request || Certificate)

ハッシュ（ハンドシェイクコンテキスト||認証者リクエスト||証明書）

Where Hash is the authenticator hash defined in Section 5.1. If the authenticator request is not present, it is omitted from this construction, i.e., it is zero-length.

ここで、ハッシュはセクション5.1で定義されている認証機ハッシュです。Authenticatorリクエストが存在しない場合、この構造から省略されます。つまり、ゼロ長です。

If the party that generates the authenticator does so with a different connection than the party that is validating it, then the Handshake Context will not match, resulting in a CertificateVerify message that does not validate. This includes situations in which the application data is sent via TLS-terminating proxy. Given a failed CertificateVerify validation, it may be helpful for the application to confirm that both peers share the same connection using a value derived from the connection secrets (such as the Handshake Context) before taking a user-visible action.

認証者を生成する当事者がそれを検証している当事者とは異なる接続でそうする場合、握手のコンテキストは一致しないため、検証されていないCertimateVerifyメッセージが生じます。これには、アプリケーションデータがTLS終了プロキシを介して送信される状況が含まれます。失敗したCertifativeVerify検証があれば、ユーザーに可視アクションを実行する前に、接続シークレット（ハンドシェイクコンテキストなど）から派生した値を使用して両方のピアが同じ接続を共有していることをアプリケーションが確認することが役立つ場合があります。

5.2.3. Finished

5.2.3. 終了した

An HMAC [HMAC] over the hashed authenticator transcript is the concatenation of the Handshake Context, authenticator request (if present), Certificate, and CertificateVerify. The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key.

ハッシュされた認証因子トランスクリプトを介したHMAC [HMAC]は、ハンドシェイクコンテキスト、認証因子要求（存在する場合）、証明書、および証明書の連結です。HMACは、完成したMacキーをキーとして使用して、Authenticator Hashを使用して計算されます。

Finished = HMAC(Finished MAC Key, Hash(Handshake Context || authenticator request || Certificate || CertificateVerify))

finited = hmac（完成MACキー、ハッシュ（ハンドシェイクコンテキスト||認証者リクエスト||証明書||証明書verify））

5.2.4. Authenticator Creation

5.2.4. 認証機の作成

An endpoint constructs an authenticator by serializing the Certificate, CertificateVerify, and Finished as TLS handshake messages and concatenating the octets:

エンドポイントは、証明書をシリアル化し、証明書verifyを作成し、TLSハンドシェイクメッセージとして完成し、オクテットを連結することにより認証器を構築します。

Certificate || CertificateVerify || Finished

証明書||CertimationVerify ||終了した

An authenticator is valid if the CertificateVerify message is correctly constructed given the authenticator request (if used) and the Finished message matches the expected value. When validating an authenticator, constant-time comparisons SHOULD be used for signature and MAC validation.

Authenticatorリクエスト（使用されている場合）を考慮して、CertimateVerifyメッセージが正しく構築され、完成したメッセージが期待値と一致する場合、Authenticatorは有効です。認証器を検証する場合、署名とMACの検証には一定の時間比較を使用する必要があります。

6. Empty Authenticator

6. 空の認証器

If, given an authenticator request, the endpoint does not have an appropriate identity or does not want to return one, it constructs an authenticated refusal called an "empty authenticator". This is a Finished message sent without a Certificate or CertificateVerify. This message is an HMAC over the hashed authenticator transcript with a Certificate message containing no CertificateEntries and the CertificateVerify message omitted. The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key. This message is encoded as a TLS handshake message, including length and type field. It does not include TLS record-layer framing and is not encrypted with a handshake or application-data key.

認証機のリクエストが与えられた場合、エンドポイントに適切なアイデンティティがないか、それを返したくない場合、「空の認証者」と呼ばれる認証された拒否を構築します。これは、証明書またはcortermyverifyなしで送信された完成したメッセージです。このメッセージは、証明書が省略されていない証明書メッセージを含む証明書メッセージを備えたハッシュされた認証因子トランスクリプトを介したHMACです。HMACは、完成したMacキーをキーとして使用して、Authenticator Hashを使用して計算されます。このメッセージは、長さと型フィールドを含むTLSハンドシェイクメッセージとしてエンコードされています。TLSレコード層フレーミングは含まれておらず、握手またはアプリケーションデータキーで暗号化されていません。

Finished = HMAC(Finished MAC Key, Hash(Handshake Context || authenticator request || Certificate))

finited = hmac（完成MACキー、ハッシュ（ハンドシェイクコンテキスト||認証要求||証明書））

7. API Considerations

7. APIの考慮事項

The creation and validation of both authenticator requests and authenticators SHOULD be implemented inside the (D)TLS library even if it is possible to implement it at the application layer. (D)TLS implementations supporting the use of Exported Authenticators SHOULD provide application programming interfaces by which clients and servers may request and verify Exported Authenticator messages.

Authenticator RequestsとAuthenticatorの両方の作成と検証は、アプリケーションレイヤーに実装できる場合でも、（d）TLSライブラリ内に実装する必要があります。（d）エクスポートされた認証機の使用をサポートするTLS実装では、クライアントとサーバーがエクスポートされた認証装置メッセージを要求および検証できるアプリケーションプログラミングインターフェイスを提供する必要があります。

Notwithstanding the success conditions described below, all APIs MUST fail if:

以下で説明する成功条件にもかかわらず、すべてのAPIが失敗する必要があります。

* the connection uses a (D)TLS version of 1.1 or earlier, or

* 接続は、1.1以前の（d）TLSバージョンを使用するか、

* the connection is (D)TLS 1.2 and the extended master secret extension [RFC7627] was not negotiated

* 接続は（d）TLS 1.2であり、拡張マスターシークレットエクステンション[RFC7627]は交渉されませんでした

The following sections describe APIs that are considered necessary to implement Exported Authenticators. These are informative only.

次のセクションでは、エクスポートされた認証器を実装するために必要と思われるAPIについて説明します。これらは有益です。

7.1. The "request" API

7.1. 「リクエスト」API

The "request" API takes as input:

「リクエスト」APIは入力として取得します：

* certificate_request_context (from 0 to 255 octets)

* certificate_request_context（0〜255オクテット）

* the set of extensions to include (this MUST include signature_algorithms) and the contents thereof

* 拡張機能のセットを含む（これにはsignature_algorithmsを含める必要があります）とその内容

It returns an authenticator request, which is a sequence of octets that comprises a CertificateRequest or ClientCertificateRequest message.

Authenticatorリクエストを返します。これは、CertificateRequestまたはClientCertificAterequestメッセージを含むOctetsのシーケンスです。

7.2. The "get context" API

7.2. 「コンテキストを取得」API

The "get context" API takes as input:

「get context」APIは入力として取得します。

* authenticator or authenticator request

* AuthenticatorまたはAuthenticatorリクエスト

It returns the certificate_request_context.

certificate_request_contextを返します。

7.3. The "authenticate" API

7.3. 「認証」API

The "authenticate" API takes as input:

「認証」APIは入力として取得されます。

* a reference to the initial connection

* 初期接続への参照

* an identity, such as a set of certificate chains and associated extensions (OCSP [RFC6960], SCT [RFC6962] (obsoleted by [RFC9162]), etc.)

* 証明書チェーンのセットや関連する拡張（OCSP [RFC6960]、SCT [RFC6962]（[RFC9162]で廃止）などのアイデンティティ。

* a signer (either the private key associated with the identity or the interface to perform private key operations) for each chain

* 各チェーンの署名者（IDに関連付けられている秘密鍵または秘密鍵操作を実行するためのインターフェイスのいずれか）

* an authenticator request or certificate_request_context (from 0 to 255 octets)

* Authenticator Requestまたはcertifartion_request_context（0〜255オクテット）

It returns either the authenticator or an empty authenticator as a sequence of octets. It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter be implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic, and the implementer can more easily remember which extensions were sent in the ClientHello.

オクテットのシーケンスとして、認証器または空の認証器のいずれかを返します。Exporterに含める証明書と拡張機能を選択するためのロジックをTLSライブラリに実装することをお勧めします。TLSライブラリでこれを実装することにより、実装者は既存の拡張機能と証明書の選択ロジックを利用でき、実装者はclienthelloでどの拡張機能が送信されたかをより簡単に覚えることができます。

It is also possible to implement this API outside of the TLS library using TLS exporters. This may be preferable in cases where the application does not have access to a TLS library with these APIs or when TLS is handled independently of the application-layer protocol.

TLS輸出業者を使用してTLSライブラリの外にこのAPIを実装することもできます。これは、アプリケーションがこれらのAPIを使用してTLSライブラリにアクセスできない場合、またはアプリケーション層プロトコルとは独立してTLSが処理される場合に望ましい場合があります。

7.4. The "validate" API

7.4. 「検証」API

The "validate" API takes as input:

「検証」APIは入力として取得します。

* a reference to the initial connection

* 初期接続への参照

* an optional authenticator request

* オプションの認証要求リクエスト

* an authenticator

* 認証者

* a function for validating a certificate chain

* 証明書チェーンを検証するための関数

It returns a status to indicate whether or not the authenticator is valid after applying the function for validating the certificate chain to the chain contained in the authenticator. If validation is successful, it also returns the identity, such as the certificate chain and its extensions.

ステータスを返して、認証チェーンを検証するための機能を適用した後に認証器が有効であるかどうかを示します。検証が成功した場合、証明書チェーンやその拡張などのアイデンティティも返します。

The API should return a failure if the certificate_request_context of the authenticator was used in a different authenticator that was previously validated. Well-formed empty authenticators are returned as invalid.

APIは、以前に検証された別の認証機で使用されているcertificate_request_contextが使用された場合、障害を返す必要があります。整形式の空の認証器は無効として返されます。

When validating an authenticator, constant-time comparison should be used.

認証器を検証する場合は、一定の時間比較を使用する必要があります。

8. IANA Considerations

8. IANAの考慮事項

8.1. Update of the TLS ExtensionType Registry

8.1. TLS ExtensionTypeレジストリの更新

IANA has updated the entry for server_name(0) in the "TLS ExtensionType Values" registry [IANA-TLS] (defined in [RFC8446]) by replacing the value in the "TLS 1.3" column with the value "CH, EE, CR" and listing this document in the "Reference" column.

IANAは、「TLS ExtensionType値」レジストリ[IANA-TLS]（[RFC8446]で定義）のserver_name（0）のエントリを更新しました。「このドキュメントを「参照」列にリストします。

IANA has also added the following note to the registry:

IANAはまた、次のメモをレジストリに追加しました。

   |  The addition of the "CR" to the "TLS 1.3" column for the
   |  server_name(0) extension only marks the extension as valid in a
   |  ClientCertificateRequest created as part of client-generated
   |  authenticator requests.

8.2. Update of the TLS Exporter Labels Registry

8.2. TLS Exporter Labelsレジストリの更新

IANA has added the following entries to the "TLS Exporter Labels" registry [IANA-EXPORT] (defined in [RFC5705]): "EXPORTER-client authenticator handshake context", "EXPORTER-server authenticator handshake context", "EXPORTER-client authenticator finished key" and "EXPORTER-server authenticator finished key" with "DTLS-OK" and "Recommended" set to "Y" and this document listed as the reference.

IANAは、「TLS輸出業者ラベル」レジストリ[IANA-Export]（[RFC5705]で定義）に次のエントリを追加しました。「dtls-ok」と「推奨」セットを「y」に設定し、このドキュメントが参照としてリストされている「dtls-ok」と「推奨」を備えた「exporter-server Autherver Authenticator finite key」が完成しました。

8.3. Update of the TLS HandshakeType Registry

8.3. TLS HandShakeTypeレジストリの更新

IANA has added the following entry to the "TLS HandshakeType" registry [IANA-HANDSHAKE] (defined in [RFC8446]): "client_certificate_request" (17) with "DTLS-OK" set to "Y" and this document listed as the reference. In addition, the following appears in the "Comment" column:

IANAは、「TLS HandShakeType」レジストリ[IANAハンドシェイク]（[RFC8446]で定義）に次のエントリを追加しました：「client_certificate_request」（17）が「y」に設定されており、このドキュメントは参照としてリストされています。さらに、「コメント」列に次のように表示されます。

| Used in TLS versions prior to 1.3.

|1.3より前のTLSバージョンで使用されます。

9. Security Considerations

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

The Certificate/Verify/Finished pattern intentionally looks like the TLS 1.3 pattern that now has been analyzed several times. For example, [SIGMAC] presents a relevant framework for analysis, and Appendix E.1.6 of [RFC8446] contains a comprehensive set of references.

証明書/検証/完成パターンは、意図的に数回分析されているTLS 1.3パターンのように見えます。たとえば、[Sigmac]は分析に関連するフレームワークを提示し、[RFC8446]の付録E.1.6には包括的な参照セットが含まれています。

Authenticators are independent and unidirectional. There is no explicit state change inside TLS when an authenticator is either created or validated. The application in possession of a validated authenticator can rely on any semantics associated with data in the certificate_request_context.

認証者は独立しており、一方向です。Authenticatorが作成または検証されている場合、TLS内に明示的な状態変更はありません。検証済みの認証装置を所有するアプリケーションは、certificate_request_contextのデータに関連付けられたセマンティクスに依存できます。

* This property makes it difficult to formally prove that a server is jointly authoritative over multiple identities, rather than individually authoritative over each.

* このプロパティにより、サーバーは、それぞれよりも個別に権威あるものではなく、複数のアイデンティティに対して共同で権威あることを正式に証明することが困難です。

* There is no indication in (D)TLS about which point in time an authenticator was computed. Any feedback about the time of creation or validation of the authenticator should be tracked as part of the application-layer semantics if required.

* （d）TLSには、認証器が計算された時点についての兆候はありません。認証器の作成または検証の時間に関するフィードバックは、必要に応じてアプリケーション層セマンティクスの一部として追跡する必要があります。

The signatures generated with this API cover the context string "Exported Authenticator"; therefore, they cannot be transplanted into other protocols.

このAPIで生成された署名は、コンテキスト文字列「エクスポートされたAuthenticator」をカバーします。したがって、他のプロトコルに移植することはできません。

In TLS 1.3, the client cannot explicitly learn from the TLS layer whether its Finished message was accepted. Because the application traffic keys are not dependent on the client's final flight, receiving messages from the server does not prove that the server received the client's Finished message. To avoid disagreement between the client and server on the authentication status of Exported Authenticators, servers MUST verify the client Finished message before sending an EA or processing a received Exported Authenticator.

TLS 1.3では、クライアントは、完成したメッセージが受け入れられたかどうかをTLSレイヤーから明示的に学習できません。アプリケーショントラフィックキーはクライアントの最終フライトに依存していないため、サーバーからメッセージを受信しても、サーバーがクライアントの完成したメッセージを受信したことは証明されません。エクスポートされた認証機の認証ステータスに関するクライアントとサーバー間の意見の不一致を回避するには、サーバーはEAを送信する前にクライアントの完成メッセージを確認するか、受信したエクスポート認証器を処理する必要があります。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[HMAC] 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>.

[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、DOI 10.17487/RFC2104、1997年2月、<https：//www.rfc-editor.org/info/rfc2104>。

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

[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.

[RFC5705] Rescorla、E。、「輸送層のセキュリティ（TLS）のためのキーキーリングマテリアル輸出業者」、RFC 5705、DOI 10.17487/RFC5705、2010年3月、<https://www.rfc-editor.org/info/rfc5705>

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6066] EastLake 3rd、D。、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487/RFC6066、2011年1月、<https://www.rfc-editor.org/info/RFC6066>。

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

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

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

[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

[RFC8447] Salowey、J。およびS. Turner、「TLSおよびDTLSのIANAレジストリの更新」、RFC 8447、DOI 10.17487/RFC8447、2018年8月、<https://www.rfc-editor.org/info/rfc8447>。

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

10.2. Informative References

10.2. 参考引用

[IANA-EXPORT] IANA, "TLS Exporter Labels", <https://www.iana.org/assignments/tls-parameters/>.

[IANA-Export] IANA、「TLS Exporter Labels」、<https://www.iana.org/assignments/tls-parameters/>。

[IANA-HANDSHAKE] IANA, "TLS HandshakeType", <https://www.iana.org/assignments/tls-parameters/>.

[Iana Handshake] iana、 "tls handshaketype"、<https://www.iana.org/assignments/tls-parameters/>。

[IANA-TLS] IANA, "TLS ExtensionType Values", <https://www.iana.org/assignments/tls-extensiontype-values/>.

[iana-tls] iana、 "tls extensionType値"、<https://www.iana.org/assignments/tls-extiontype-values/>。

[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.

[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、 "x.509インターネット公開キーインフラオンライン証明書ステータスプロトコル-OCSP"、RFC6960、doi 10.17487/rfc6960、2013年6月、<https://www.rfc-editor.org/info/rfc6960>。

[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.

[RFC6962] Laurie、B.、Langley、A。、およびE. Kasper、「証明書の透明性」、RFC 6962、DOI 10.17487/RFC6962、2013年6月、<https://www.rfc-editor.org/info/RFC69622>。

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

[RFC7250] Wouters、P.、ed。、Tschofenig、H.、Ed。、Gilmore、J.、Weiler、S。、およびT. Kivinen、「TLAPERIER LAYER SECURET（TLS）およびDatagram Transport Layerの生の公共キーを使用するSecurity（DTLS） "、RFC 7250、DOI 10.17487/RFC7250、2014年6月、<https://www.rfc-editor.org/info/rfc7250>。

[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[RFC9001] Thomson、M.、ed。and S. Turner、ed。、「TLSを使用してQUICを確保する」、RFC 9001、DOI 10.17487/RFC9001、2021年5月、<https://www.rfc-editor.org/info/rfc9001>。

[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.

[RFC9113] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。

[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/info/rfc9162>.

[RFC9162] Laurie、B.、Messeri、E。、およびR. Stradling、「証明書透明性バージョン2.0」、RFC 9162、DOI 10.17487/RFC9162、2021年12月、<https://www.rfc-editor.org/info/rfc9162>。

[SIGMAC] Krawczyk, H., "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3)", Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, DOI 10.1145/2976749.2978325, August 2016, <https://eprint.iacr.org/2016/711.pdf>.

[Sigmac] Krawczyk、H。、「キー交換用の一方的な認証コンパイラ（TLS 1.3でのクライアント認証へのアプリケーションを使用）」、2016 ACM SIGSAC Conference on Computer and Communications Security、DOI 10.1145/2976749.298325、2016年8月、<https://eprint.iacr.org/2016/711.pdf>。

Acknowledgements

謝辞

Comments on this proposal were provided by Martin Thomson. Suggestions for Section 9 were provided by Karthikeyan Bhargavan.

この提案に関するコメントは、マーティン・トムソンによって提供されました。セクション9の提案は、Karthikeyan Bhargavanによって提供されました。

Author's Address

著者の住所

Nick Sullivan Cloudflare Inc. Email: nick@cloudflare.com

Nick Sullivan Cloudflare Inc.メール：nick@cloudflare.com