Summary

  • RFC 9963 allocates three *_legacy signature-scheme values to let a TLS 1.3 server explicitly request RSASSA-PKCS1-v1_5 from a client certificate that cannot make a compatible RSASSA-PSS signature.
  • The values have a deliberately narrow meaning: client CertificateVerify only, never server CertificateVerify, never server certificates, and normally disabled unless an implementation chooses the bounded exception.

David Benjamin and Andrei Popov’s RFC 9963 addresses an awkward migration boundary. TLS 1.3 removed RSASSA-PKCS1-v1_5 support in CertificateVerify in favor of RSASSA-PSS. The RFC identifies client-side hardware that may not produce a TLS-1.3-compatible PSS signature, including some TPMs, as a reason a connection can fail only after the endpoints have selected TLS 1.3 and the server asks for a client certificate.

The document’s answer is not “make the old signature scheme normal again.” It allocates three visibly marked values: rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy, and rsa_pkcs1_sha512_legacy. Each is scoped to a signature in the client CertificateVerify message. They are not defined for other contexts. That small grammatical boundary is the operating boundary: a code point says what an endpoint may mean in a particular exchanged message, not what every TLS participant may infer from the name of an algorithm.

The negotiation rules make the exception observable rather than ambient. A client must not advertise these values in its ClientHello signature_algorithms extension and must not accept them in a server CertificateVerify. A server that elects to support a client with a legacy-only key may put the values in CertificateRequest and accept one in the client’s response, but it must not accept a value it did not offer. A legacy client may use the route when offered. If its key supports PSS, it should not select the legacy route, although discovering that capability may itself be impractical in some applications. Implementations should disable the values by default.

The server boundary is equally direct. RFC 9963 says the migration problem it describes does not apply to server keys. The new values are forbidden for server certificates, and PSS remains required for TLS 1.3 servers using RSA keys. Nor is the exception a relaxation of implementation discipline. The RFC requires the RFC 8017 construction, the mandatory NULL parameter and valid DER encoding; servers must reject signatures that do not meet those requirements.

The record supports a much narrower conclusion than a deployment story. It says a server and client can intentionally negotiate a labelled compatibility exception under stated conditions. It does not show that a particular TPM, browser, library, enterprise fleet or server has done so. It does not certify a connection, establish a general safety result, or grant a broader operational mandate. The IETF profile links David Benjamin to the RFC, and his public site gives professional context; neither turns an author line into evidence about someone else’s running system.

That restraint is the useful part of the design. Compatibility pressure is real, but the exception is made visible, directional and revocable by default. An operator deciding whether to enable it can record the client need, the request context, the offered scheme and the exit condition. A code-point allocation then remains what it is: an exact protocol tool, not a substitute for a complete security or deployment account.

Sources