要約

  • TLS 1.3のcertificate_request_contextは、クライアントの認証ブロックがどのCertificateRequestへの応答かを示す。とくにハンドシェイク後の複数応答が異なる順序で届く場面で重要だが、接続内の一意性と予測困難性が守るのはプロトコル上の対応関係であり、アプリケーションの認可範囲ではない。
  • 説明可能な認証記録には、TLSコンテキスト、秘密鍵の所持証明、証明書経路の判断、アプリケーション主体、資源、操作、適用規則、決定、有効期限、失効状態を別々に残す必要がある。不透明な値でこの結合を代用すると、正確な照合結果が、実際には存在しない権限判断に見えてしまう。

長時間維持される接続で、サービスが二つのクライアント証明書要求を送る場面を考える。一つは口座の照会前、もう一つは管理設定の変更前である。プログラムは二つのコンテキストを「照会」と「管理」と呼ぶ一時表に入れる。クライアントは暗号デバイスを待つため、逆順で応答する。TLSはそれぞれを正しく照合できる。しかし一年後の監査記録に「二番目のコンテキストは認証成功」としか残っていなければ、対象口座、当時の規則、鍵の保持者に管理操作が許可されていたかは分からない。

RFC 9846は2026年7月のProposed Standardであり、RFC 8446を置き換えた。この仕様はフィールドの役割を明確に限定している。CertificateRequestには0から255オクテットの不透明なcertificate_request_contextと、要求する認証パラメーターを示す拡張が入る。クライアントはCertificate応答に受け取ったコンテキストをそのまま入れる。サーバーはこれによって、応答を発端となった要求へ結び付ける。

コンテキストは一つの接続の中で一意でなければならない。同じ値を複数の要求に用いると、あるCertificateVerifyが別の要求への応答に見えるおそれがある。最初のハンドシェイクではコンテキストは空であり、空でない値はハンドシェイク後認証に使われる。重要なのは範囲である。一意性は現在の接続に限られ、別の接続、組織、利用者、資源、証明書の寿命全体には及ばない。

ハンドシェイク後の要求では、サーバーはクライアントが予測しにくいコンテキストを作るべきでもある。ランダム生成が分かりやすい方法だ。これは、一時的に秘密鍵へ触れた攻撃者が、将来の予測可能な要求に対する有効なCertificateVerifyを先に作っておくことを難しくする。予測困難性は応答の鮮度と結合を守るが、ランダム値を秘密の能力、アクセストークン、役割や委任状にはしない。

要求の拡張はTLSレベルの選択条件を伝える。signature_algorithmsは必須で、ほかの拡張は許容する認証局、オブジェクト識別子のフィルター、証明書署名方式などを示し得る。これらはクライアントが返す認証材料を制約する。それでも、ある人が文書を読めるか、送金を実行できるか、別テナントを管理できるかは答えない。

クライアントが認証を行う場合は、Certificate、CertificateVerify、Finishedを送る。CertificateVerifyは証明書に対応する秘密鍵の所持を証明し、関係するハンドシェイク記録を保護する。Finishedは認証ブロックをTLS状態に結び付ける。証拠は強力だが、その強さが主題を広げるわけではない。鍵をこの暗号対話で制御したという事実は、上位の業務規則がすべて満たされたことを示さない。

クライアントは証明書を提示しないという正規の応答もできる。空のCertificateに続いてFinishedを送れば、TLSはその要求に証明書が返らなかったと判断する。これは自動的にアプリケーションからのログアウト、同意の撤回、取引拒否、別資格情報の無効化を意味しない。匿名の継続を許すか、ほかの要素を求めるか、接続を閉じるかは上位プロトコルの判断である。

コンテキストが必要になる背景には時間差がある。クライアントは利用者への確認や暗号デバイスの応答を待つかもしれない。その間にも別のメッセージは流れ、複数要求が同時に未解決になり得る。応答順は要求順と一致しなくてもよい。一意なコンテキストは、通信順序を本人性と誤認せずに曖昧さをなくす。

サーバーがハンドシェイク後証明書認証を要求できるのは、クライアントが空のpost_handshake_auth拡張を提示した場合だけである。提示がなければ、後のCertificateRequestは予期しないメッセージとして致命的アラートを生む。しかし、能力を提示したからといって、すべてのアプリケーションプロトコルで利用が許されるわけではない。

RFC 9113はこの分離を具体的に示す。HTTP/2サーバーはTLS 1.3のハンドシェイク後CertificateRequestを送ってはならず、クライアントは受信すると接続エラーとして扱う。クライアントがpost_handshake_authを提示していても同じである。その能力は別のアプリケーションプロトコルのために提示された可能性がある。TLSで可能なことが、HTTP/2の多重化や接続規則を上書きすることはない。

証明書経路の有効性も別の判断である。RFC 5280の経路検証は、証明書制約、選択したトラストアンカー、依拠当事者の入力の下で、名前と公開鍵の結合を検証する。トラストアンカーの選択自体がポリシーであり、アプリケーションは有効な経路をさらに制限できる。要求コンテキストを正しく返しても、アンカーは選ばれず、ある場所で有効な経路がすべての用途で適格になるわけでもない。

したがって三つの述語を分けるべきだ。第一に、所持証明は端点が秘密鍵を制御することを示す。第二に、選択された経路ポリシーは、その鍵を特定の信頼枠組みの下で証明済みの名前に結び付けることがある。第三に、アプリケーションが結果を主体へ写像し、その主体が特定資源に何をできるかを決める。前の述語が真でも、後の述語の答えは決まらない。

RFC 9525は、TLSを使うアプリケーションプロトコルがサービス本人性の検証方法を定めなければならないことを示している。中心はサーバー本人性であり、普遍的なクライアント認可モデルではない。それでも構造的な教訓は明瞭である。TLSは認証機構を提供し、利用側が参照する本人性と一致した場合の効果を定義する。

OAuthの相互TLSは役割分担をさらに分かりやすくする。RFC 8705は、相互TLSによるクライアント認証と、証明書に結び付けたアクセストークンを区別する。認可サーバーは登録済みclient_idとローカルポリシーを用いて証明書を確認し、トークンを鍵の所持証明に結び付けられる。資源サーバーでは、認可判断を運ぶのはなおトークンであり、TLS証明書と要求コンテキストだけでは許可資源の一覧にならない。

RFC 6749はOAuthのscopeを認可層に置く。RFC 7662により、資源サーバーはトークンがactiveかを問い合わせ、関連メタデータを得られる。TLSコンテキストが正しく一致しても、トークンの期限切れ、失効、範囲縮小は分からない。両者を混同すると、永続接続の途中で変わったポリシーを反映できなくなる。

RFC 9325はTLSとDTLSの安全な版、アルゴリズム、運用慣行について推奨するが、普遍的な役割と権限の体系を定義しない。同様に、IANAのTLSパラメーター登録簿は相互運用のための名称とコードを調整するもので、特定組織の職員やサービスに何を許すかは決めない。

運用者は適用した規範を後から確認できるよう、RFC 9846の情報ページと正誤表も証跡に含めるべきである。RFC 8446は置き換え前の文言と移行を理解するうえで有用だ。こうした来歴は参照した仕様を示すが、個々の取引に適用した認可ポリシーの代わりにはならない。

この境界はLu Hengの二つの考え方とも響き合う。最小の初期仕様は必要な調整を可能にしつつ、将来の局所的判断を先取りしない。ポリシーの鏡は、技術的な痕跡ではなく、実際に決定が行われる場所を見るよう促す。certificate_request_contextは優れた最小調整である。メッセージの帰属だけを解決し、TLSが知り得ない権限はアプリケーションに残す。

失敗はこの控えめな役割を忘れたときに始まる。開発者がコンテキストを「scope」と呼び、一時写像を「session role」と呼び、認証成功を「authorized」と表示する。やがて監視画面、顧客対応、監査出力が同じ言葉を受け継ぐ。最初はメモリー内だけの便宜的な呼び名が、仕様で保証された意味のように扱われるが、接続を越える意味を規定した標準はない。

新しいコンテキストを権限更新と見るのも危険である。ハンドシェイク後認証は鍵の所持を再度示せるが、口座状態、契約、トークン範囲、失効情報を自動で再評価しない。逆に、古い認証を理由に接続開始時の権限を永久に固定してもいけない。認証イベントと認可決定には別の有効時刻が必要で、再評価を起こす条件を明示しなければならない。

明確な設計は少なくとも四つの名前空間を維持する。TLSは接続、要求、コンテキスト、トランスクリプト、証明結果を記録する。PKIは証明書、経路、トラストアンカー、制約を記録する。アプリケーション本人性層は主体、アカウント、テナント、結合方法を記録する。認可層は資源、操作、規則、決定、有効期間を記録する。関連識別子で結べるが、一つの識別子が別層の意味を奪ってはならない。

分離は事故対応にも役立つ。秘密鍵が侵害されたとき、その鍵に依存したアプリケーション判断を追跡でき、コンテキストの出現すべてに同じ権限があったと仮定せずに済む。ポリシー変更時にはTLS接続を維持したまま将来の操作を止められる。本人性の写像が争点なら、証明書から主体への結合を調べつつ、トランスクリプトが示す暗号上の事実を改変せずに済む。

情報源