要約

  • RFC 9963 の *_legacy 三値は、サーバーが CertificateRequest で提示した後の、クライアント CertificateVerify 専用である。
  • クライアントは ClientHello で提示できず、サーバー署名として受け入れてもならない。サーバーも自ら提示しなかった値を受け入れられず、実装は既定で無効にすべきである。
  • 登録、提示、鍵の能力、認証済みセッションは別々の事実であり、アプリケーション上の権限にはならない。

どちらが求めた署名かで意味が決まる

TLS 1.3 は CertificateVerify から RSASSA-PKCS1-v1_5 を外し、RSASSA-PSS を選んだ。しかし、古いハードウェアで保護されたクライアント証明書鍵の一部は、互換する PSS を作れない。TLS 1.3 の版が決まった後、サーバーがクライアント認証を要求した時点で初めて接続が止まる場合がある。

RFC 9963 は、すべての接続で TLS 1.3 を止めることも、外側に独自フォールバックを足すことも求めない。必要なサーバーだけが CertificateRequest の signature_algorithms に値を置く。該当するクライアントは自分の CertificateVerify で選べる。提示されなかった値をサーバーが受理することは禁止される。

反対方向には進めない。クライアントは ClientHello で値を広告せず、サーバーの CertificateVerify に現れた値を拒否する。TLS 1.3 の RSA サーバー認証は PSS のままである。同じ RSA という語ではなく、どのメッセージで誰が誰に証明するのかが境界を定める。

「有効」という一語を四つの記録に戻す

IANA の記録は、値が仕様化され、推奨でないことを示す。設定と保存した CertificateRequest は、そのリスナーが例外を提示したことを示す。鍵台帳は、そのクライアント鍵が本当に PSS を使えないかを示す。ハンドシェーク記録は、提示された値のどれが選ばれ、検証されたかを示す。

四つの責任者も違う。標準は共通の語彙を定め、運用者は例外を開け、鍵の所有者は置換計画を持ち、サービス所有者は認証後のアカウント権限を決める。クライアント署名が成功しても、要求内容の承認や変更の責任を代行しない。

RFC 9963 は RFC 8017 第 8.2 節にも従わせる。NULL パラメータと正しい DER が必要で、違反する署名はサーバーが拒否する。互換性は検証を曖昧にする理由ではない。

入口と一緒に出口を記録する

例外には、ポリシー版、鍵識別子、正確な CertificateRequest、選択値、検証結果、アカウント対応、終了日を結び付ける。未提示値、サーバー側利用、不正 DER、PSS 対応の置換鍵を拒む試験も必要である。そうすれば、レガシー RSA があるという抽象的な表示ではなく、いつ閉じるべき細い経路が見える。

共通仕様は小さな相互運用性を与える。信頼の継続、操作の許可、例外の廃止は、依然としてローカルの決定である。