摘要

  • RFC 9963 定义的三个 *_legacy 值只属于一个场景：服务器在 CertificateRequest 中提出后，客户端在 TLS 1.3 的 CertificateVerify 中使用。
  • 客户端不得在 ClientHello 中宣告这些值，也不得接受服务器用它们签名；服务器若未在请求中提出，也不得接受。实现默认应关闭该例外。
  • 注册记录、服务器邀约、某把客户端密钥的真实能力和一条认证成功的会话是不同证据，不能压缩成“遗留 RSA 已开启”。

服务器提出的问题，不是给自己开的许可

TLS 1.3 用 RSASSA-PSS 取代了 CertificateVerify 中的 RSASSA-PKCS1-v1_5。RFC 9963 处理的是一个具体迁移障碍：某些受旧硬件保护的客户端证书密钥无法产生兼容的 PSS 签名。问题常在 TLS 版本已协商后才显现——服务器随后要求客户端认证，密钥却无法回应。

三枚新数值避免了两种粗糙做法：为所有连接关掉 TLS 1.3，或在协议外自行设计回退。需要容纳特定旧客户端密钥的服务器，可以在 CertificateRequest 的 signature_algorithms 中提出一个数值。客户端可在自己的 CertificateVerify 中选择它；服务器只可接受自己已经提出过的数值。

反向路径被标准明确封住。客户端不得在 ClientHello 中宣告这些数值，也必须拒绝服务器在 CertificateVerify 中使用它们。TLS 1.3 的 RSA 服务器认证仍要求 PSS。算法名称相同不等于权限对称；消息方向和签名位置才决定例外的边界。

不要让一盏绿灯吞掉四份记录

注册表证明的是“数值被定义且不推荐”。保存下来的 CertificateRequest 与服务器配置证明的是“某个监听器确实提出了狭窄例外”。密钥清单证明的是“这把客户端密钥确实不能使用 PSS”。握手轨迹证明的是“哪个被提出的数值实际被选中并完成校验”。

这四层分别归不同的人负责。标准和注册表提供公共词汇；平台团队决定在哪个监听器提出例外；身份或设备负责人说明旧密钥与替换计划；服务负责人决定认证后的账户能做什么。一次 CertificateVerify 成功，并不会代替后面的账户授权、请求范围或变更批准。

例外也不免除编码纪律。RFC 9963 要求遵守 RFC 8017 第 8.2 节：必须有 NULL 参数，DER 必须有效，不符合者服务器必须拒绝。旧兼容不是让验证变得含糊。

把退出条件写进启用记录

应当同时记录策略版本、客户端密钥标识、实际 CertificateRequest、所选方案、校验结果、账户映射与终止日期。再用未被邀约的方案、服务器侧使用、错误 DER 和可用 PSS 的替换密钥演练拒绝路径。这样，团队知道的是哪一条窄桥仍在使用，而不是笼统地以为“旧 RSA 还在”。

RFC 9963 提供可验证的最小互操作性；是否继续信任客户端、何时撤销例外及会话可以触发什么动作，仍是本地且可追责的决定。