Summary

  • RFC 9963 assigns rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy and rsa_pkcs1_sha512_legacy to one TLS 1.3 context: a client CertificateVerify after the server offers them in CertificateRequest.
  • A client must not advertise them in ClientHello, must not accept them from a server, and an implementation should disable them by default. The server must not accept a value it did not offer.
  • Registry status, a scoped server offer, a legacy client-key capability and an authenticated session are separate evidence records. None proves application permission or a completed change.

A number appeared in the registry; the exception remained small

TLS 1.3 replaced RSASSA-PKCS1-v1_5 in CertificateVerify with RSASSA-PSS. RFC 9963 addresses one consequence for legacy hardware-backed client keys: a TLS 1.3 connection can fail only after version negotiation and a later request for client authentication reveal that the key cannot produce the required PSS form. The RFC creates three values rather than asking a deployment to disable TLS 1.3 globally or improvise an external fallback.

The direction is the point. A server that wants to accept a legacy-only client key may put one of the values in the signature_algorithms extension of CertificateRequest. Only then may the client use it in its own CertificateVerify; only then may the server accept it. The client may not advertise the values in its ClientHello, and it must reject their use in the server's CertificateVerify.

That is not syntactic decoration. The server asks which client-authentication signature it can verify. It does not receive permission to use the same exception when authenticating itself. RFC 9963 keeps RSASSA-PSS required for TLS 1.3 RSA server authentication and says the new values are not for server certificates.

Four records prevent one misleading green badge

An operator should resist the label “legacy RSA enabled.” It fuses facts that the protocol keeps apart.

  1. The registry record says a value is specified and marked Recommended: N.
  2. The server configuration and captured CertificateRequest say whether this limited exception was actually offered.
  3. The client-key record says whether that particular key is genuinely unable to use RSASSA-PSS, rather than merely being inconvenient to test.
  4. The handshake trace says which offered value, if any, the client selected and whether the transcript then authenticated.

Each has a different owner. Standards and registry maintainers define the public vocabulary. The service operator accepts or rejects an exception. The key owner inventories the key and its replacement path. The relying service decides what an authenticated client account may do. A successful CertificateVerify does not merge those roles.

The encoding boundary also remains real. RFC 9963 requires PKCS#1 v1.5 producers and verifiers to follow RFC 8017 Section 8.2, including the mandatory NULL parameter and valid DER; servers must reject signatures that do not. “Legacy required” is not a waiver from exact verification.

Keep the migration exception reversible

The useful decision is not whether old RSA is good or bad in the abstract. It is whether one identified client key needs this narrowly offered bridge while its owner moves to a key that supports PSS. Record the server policy revision, the client-key identifier, the exact CertificateRequest, the selected scheme, the validation result, the account mapping and an expiry decision. Test the negative cases: no offer, a server-side attempt, malformed DER and a client key that can use PSS.

That produces a migration record rather than a permanent compatibility fog. It also keeps the RFC's shared minimum in its proper place: it tells interoperating endpoints how to express a limited exception, not whether a local application should keep trusting a client, approve a request or preserve the exception forever.