摘要

  • RFC 9963 分配了三个 *_legacy 签名方案值，使 TLS 1.3 服务器能够向无法生成兼容 RSASSA-PSS 签名的客户端证书明确请求 RSASSA-PKCS1-v1_5。
  • 例外只属于客户端 CertificateVerify：它不用于服务器 CertificateVerify，不用于服务器证书，也不应默认开启。

David Benjamin 与 Andrei Popov 的 RFC 9963 处理的是一次迁移的具体断点。TLS 1.3 已在 CertificateVerify 中以 RSASSA-PSS 取代 RSASSA-PKCS1-v1_5。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