Legacy RSASSA-PKCS1-v1_5 Code Points for TLS 1.3
Extracted elements (16)
Because TLS negotiates versions before client certificate authentication, clients and servers cannot know each other's key capabilities at handshake time; disabling TLS 1.3 globally or using external fallbacks both introduce security problems (e.g., POODLE-class vulnerabilities), motivating dedicated code points instead.
Remaining on TLS 1.2 for compatibility leaks client certificates to network observers and forecloses post-quantum protections against retroactive decryption, making a TLS 1.3 migration path necessary.
TLS 1.3 dropped RSASSA-PKCS1-v1_5 in CertificateVerify in favor of RSASSA-PSS, but legacy hardware cryptographic devices—most notably TPMs—often cannot produce RSASSA-PSS signatures compatible with TLS 1.3, blocking migration for affected deployments.
The rsa_pkcs1_*_legacy code points are exclusively defined for client CertificateVerify; servers that wish to advertise support for RSASSA-PKCS1-v1_5 in certificates should use the existing rsa_pkcs1_* constants from RFC 8446, not these new ones.
TPM specifications prior to 2.0 did not define RSASSA-PSS support; TPM 2.0 devices are only reliable for TLS 1.3-compatible PSS (salt length matching digest length) when they conform to FIPS 186-4, making a large installed base of TPMs incompatible with TLS 1.3 client certificate authentication.
Clients MUST include the mandatory NULL parameter in the DigestInfo structure and produce a valid DER encoding. Servers MUST reject signatures that do not meet these requirements.
Clients MUST NOT accept rsa_pkcs1_*_legacy values in the server CertificateVerify message; these code points are strictly client-only.
Clients MUST NOT advertise rsa_pkcs1_*_legacy values in the signature_algorithms extension of the ClientHello message.
Clients SHOULD NOT negotiate rsa_pkcs1_*_legacy with keys that support RSASSA-PSS, though this may not be practical to determine in all applications (e.g., testing a key for support might produce side effects).
Implementations producing or verifying signatures with the legacy algorithms MUST implement RSASSA-PKCS1-v1_5 as specified in Section 8.2 of RFC 8017 to avoid signature forgeries.
Servers MAY send these legacy code points in the signature_algorithms extension of the CertificateRequest message, but MUST NOT accept them in the client CertificateVerify unless they were previously offered in the CertificateRequest.
TLS implementations SHOULD disable these code points by default, given the security risks associated with RSASSA-PKCS1-v1_5 when not strictly necessary.
Three new SignatureScheme values are defined for use with TLS 1.3 client certificates: rsa_pkcs1_sha256_legacy (0x0420), rsa_pkcs1_sha384_legacy (0x0520), and rsa_pkcs1_sha512_legacy (0x0620). Each indicates RSASSA-PKCS1-v1_5 with the corresponding hash algorithm. They are exclusively for use in the client CertificateVerify message.
IANA has added three entries to the 'TLS SignatureScheme' registry: rsa_pkcs1_sha256_legacy (0x0420), rsa_pkcs1_sha384_legacy (0x0520), and rsa_pkcs1_sha512_legacy (0x0620), all with Recommended set to 'N'.
RSASSA-PKCS1-v1_5 admits signature forgeries when implemented incorrectly (as demonstrated by MFSA 2014-73). Strict conformance to RFC 8017 Section 8.2, including the NULL parameter in DigestInfo and valid DER encoding, is required to prevent such attacks.
The new legacy code points are forbidden for server certificates; RSASSA-PSS remains required for TLS 1.3 servers using RSA keys. This limits the security impact to only the cases necessary to unblock TLS 1.3 deployment.