要約

  • RFC 9963 は、互換性のある RSASSA-PSS 署名を生成できないクライアント証明書に対して、TLS 1.3 サーバーが RSASSA-PKCS1-v1_5 を明示的に求めるための三つの *_legacy 値を割り当てる。
  • その意味はクライアント CertificateVerify に限られる。サーバー CertificateVerify やサーバー証明書には使えず、実装では既定で無効にすべきである。

David Benjamin と Andrei Popov による RFC 9963 は、移行時の限定された摩擦を扱う。TLS 1.3 は CertificateVerify で RSASSA-PKCS1-v1_5 を RSASSA-PSS に置き換えた。RFC は、いくつかの TPM を含むクライアント側の暗号ハードウェアが、TLS 1.3 と互換な PSS 署名を作れないことがあると説明する。端点が TLS 1.3 を選択した後、サーバーがクライアント証明書を要求した時点で接続が失敗することがある。

答えは旧方式を通常の選択肢へ戻すことではない。文書は rsa_pkcs1_sha256_legacy、rsa_pkcs1_sha384_legacy、rsa_pkcs1_sha512_legacy を定める。これらはクライアントの CertificateVerify 内の署名についてだけ定義され、他の文脈には定義されない。ここでの小さな文言が実運用の境界である。コードポイントは、特定のメッセージで端点が何を表せるかを示すのであって、アルゴリズム名だけから全 TLS 参加者が一般許可を得るものではない。

協商規則は例外を周囲に拡散させない。クライアントは ClientHello の signature_algorithms 拡張でこれらを広告してはならず、サーバーの CertificateVerify で受理してもならない。旧式鍵だけを持つクライアントを支えるサーバーは CertificateRequest に値を入れ、クライアント応答で受理できるが、自ら提示しなかった値を受理してはならない。該当クライアントは提示された場合に使える。鍵が PSS をサポートするなら旧経路を選ぶべきではないが、その判定が実用的でない場合もある。実装は既定で無効にすべきである。

サーバー側の境界も明白だ。RFC が扱う移行問題はサーバー鍵には当てはまらない。新しい値はサーバー証明書に禁止され、RSA を使う TLS 1.3 サーバーでは PSS が引き続き必要である。実装要件も緩まない。RFC 8017 に従い、必須の NULL パラメータと有効な DER 符号化を使い、サーバーは条件を満たさない署名を拒否しなければならない。

従って、記録が支える結論も狭い。サーバーとクライアントは、指定された条件でラベル付きの互換例外を意図して協商できる。それは特定の TPM、ブラウザ、ライブラリ、組織、サーバーでの導入を示さず、接続を認証せず、一般的な安全性の結論にもならない。IETF の記録は David Benjamin を RFC に結び、公開サイトは職業上の文脈を示す。しかし第三者の稼働システムを証明するものではない。

この抑制こそが設計の強みである。互換性の圧力は現実だが、経路は明示的で方向があり、既定で閉じている。運用者はクライアントの必要性、サーバーの提示、協商結果、終了条件を記録できる。コードポイントは、完全な導入物語の代わりではなく、精密なプロトコル道具にとどまる。

Sources