メインコンテンツまでスキップ

1.2. Terminology and Applicability (用語と適用性)

1.2. Terminology and Applicability (用語と適用性)

この文書は, 構文と解析を指定するために[STRUCTURED-FIELDS]のセクション3から以下の用語を使用します: List (リスト) とByte Sequence (バイトシーケンス)。

"TLSクライアント証明書認証" または "相互認証されたTLS" などのフレーズは, この文書全体を通じて, 証明書を使用した通常のTLSサーバー認証に加えて, クライアントがTLS接続またはそのような接続の再開を交渉する際にそのX.509証明書[RFC5280]を提示し, 対応する秘密鍵の所有を証明するプロセスを指すために使用されます。現代版のTLS [TLS] [TLS1.2]では, 相互認証にはクライアントがハンドシェイク中にCertificateおよびCertificateVerifyメッセージを送信し, サーバーがCertificateVerifyおよびFinishedメッセージを検証する必要があります。

HTTP/2はTLS 1.2の再交渉 (renegotiation) を制限し ([HTTP/2]のセクション9.2.1), TLS 1.3のハンドシェイク後認証 (post-handshake authentication) を禁止します ([HTTP/2]のセクション9.2.3)。しかし, これらはHTTP/1.1 [HTTP/1.1]でリアクティブクライアント証明書認証 (reactive client certificate authentication) を実装するために使用されることがあります。ここでは, サーバーがHTTPリクエストに基づいてクライアント証明書を要求するかどうかを決定します。クライアント証明書の受信と検証の後にそのような接続で送信されるHTTPアプリケーションデータも相互認証されており, したがってこの文書で説明されているメカニズムに適しています。ハンドシェイク後認証では, 実際にはありそうにありませんが, 接続上でクライアントから複数の証明書と証明書チェーンが存在する可能性もあります。この場合, 最後のハンドシェイク後認証の証明書とチェーンのみが本文書で説明されるヘッダーフィールドに使用されます。