rfc9963.original   rfc9963.txt 
Transport Layer Security D. Benjamin Internet Engineering Task Force (IETF) D. Benjamin
Internet-Draft Google LLC Request for Comments: 9963 Google LLC
Intended status: Standards Track A. Popov Category: Standards Track A. Popov
Expires: 5 June 2026 Microsoft Corp. ISSN: 2070-1721 Microsoft Corp.
2 December 2025 April 2026
Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 Legacy RSASSA-PKCS1-v1_5 Code Points for TLS 1.3
draft-ietf-tls-tls13-pkcs1-07
Abstract Abstract
This document allocates code points for the use of RSASSA-PKCS1-v1_5 This document allocates code points for the use of RSASSA-PKCS1-v1_5
with client certificates in TLS 1.3. This removes an obstacle for with client certificates in TLS 1.3. This removes an obstacle for
some deployments to migrate to TLS 1.3. some deployments to migrate to TLS 1.3.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://tlswg.github.io/tls13-pkcs1/draft-ietf-tls-tls13-pkcs1.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/.
Discussion of this document takes place on the Transport Layer
Security Working Group mailing list (mailto:tls@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe
at https://www.ietf.org/mailman/listinfo/tls/.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/tls13-pkcs1.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9963.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 June 2026.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. PKCS#1 v1.5 SignatureScheme Types . . . . . . . . . . . . . . 3 3. PKCS#1 v1.5 SignatureScheme Types
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Informative References
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses
1. Introduction 1. Introduction
TLS 1.3 [RFC8446] removed support for RSASSA-PKCS1-v1_5 [RFC8017] in TLS 1.3 [RFC8446] removed support for RSASSA-PKCS1-v1_5 [RFC8017] in
CertificateVerify messages in favor of RSASSA-PSS. While RSASSA-PSS CertificateVerify messages in favor of RSASSA-PSS. While RSASSA-PSS
is a long-established signature algorithm, some legacy hardware is a long-established signature algorithm, some legacy hardware
cryptographic devices lack support for it. While uncommon in TLS cryptographic devices lack support for it. While uncommon in TLS
servers, these devices are sometimes used by TLS clients for client servers, these devices are sometimes used by TLS clients for client
certificates. certificates.
skipping to change at page 3, line 9 skipping to change at line 81
specifications prior to 2.0 did not define RSASSA-PSS support (see specifications prior to 2.0 did not define RSASSA-PSS support (see
Section 5.8.1 of [TPM12]). TPM 2.0 includes RSASSA-PSS, but only Section 5.8.1 of [TPM12]). TPM 2.0 includes RSASSA-PSS, but only
those TPM 2.0 devices compatible with US FIPS 186-4 can be relied those TPM 2.0 devices compatible with US FIPS 186-4 can be relied
upon to use the salt length matching the digest length, as required upon to use the salt length matching the digest length, as required
for compatibility with TLS 1.3 (see Appendix B.7 of [TPM2]). for compatibility with TLS 1.3 (see Appendix B.7 of [TPM2]).
TLS connections that rely on such devices cannot migrate to TLS 1.3. TLS connections that rely on such devices cannot migrate to TLS 1.3.
Staying on TLS 1.2 leaks the client certificate to network attackers Staying on TLS 1.2 leaks the client certificate to network attackers
[PRIVACY] and additionally prevents such deployments from protecting [PRIVACY] and additionally prevents such deployments from protecting
traffic against retroactive decryption by an attacker with a quantum traffic against retroactive decryption by an attacker with a quantum
computer [I-D.ietf-tls-hybrid-design]. computer [RFC9954].
Additionally, TLS negotiates protocol versions before client Additionally, TLS negotiates protocol versions before client
certificates. Clients send ClientHellos without knowing whether the certificates. Clients send ClientHellos without knowing whether the
server will request to authenticate with legacy keys. Conversely, server will request to authenticate with legacy keys. Conversely,
servers respond with a TLS version and CertificateRequest without servers respond with a TLS version and CertificateRequest without
knowing if the client will then respond with a legacy key. If the knowing if the client will then respond with a legacy key. If the
client and server, respectively, offer and negotiate TLS 1.3, the client and server, respectively, offer and negotiate TLS 1.3, the
connection will fail due to the legacy key, when it previously connection will fail due to the legacy key, when it previously
succeeded at TLS 1.2. succeeded at TLS 1.2.
skipping to change at page 3, line 35 skipping to change at line 107
This document allocates code points to use these legacy keys with This document allocates code points to use these legacy keys with
client certificates in TLS 1.3. This reduces the pressure on client certificates in TLS 1.3. This reduces the pressure on
implementations to select one of these problematic mitigations and implementations to select one of these problematic mitigations and
unblocks TLS 1.3 deployment. unblocks TLS 1.3 deployment.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. PKCS#1 v1.5 SignatureScheme Types 3. PKCS#1 v1.5 SignatureScheme Types
The following SignatureScheme values are defined for use with TLS The following SignatureScheme values are defined for use with TLS
1.3. 1.3.
enum { enum {
rsa_pkcs1_sha256_legacy(0x0420), rsa_pkcs1_sha256_legacy(0x0420),
rsa_pkcs1_sha384_legacy(0x0520), rsa_pkcs1_sha384_legacy(0x0520),
rsa_pkcs1_sha512_legacy(0x0620), rsa_pkcs1_sha512_legacy(0x0620),
} SignatureScheme; } SignatureScheme;
The above code points indicate a signature algorithm using RSASSA- The above code points indicate a signature algorithm using RSASSA-
PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm as defined PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm as defined
in [SHS]. They are only defined for signatures in the client in [SHS]. They are only defined for signatures in the client
CertificateVerify message and are not defined for use in other CertificateVerify message and are not defined for use in other
contexts. In particular, servers intending to advertise support for contexts. In particular, servers that intend to advertise support
RSASSA-PKCS1-v1_5 signatures in the certificates themselves should for RSASSA-PKCS1-v1_5 signatures in the certificates themselves
use the rsa_pkcs1_* constants defined in [RFC8446]. should use the rsa_pkcs1_* constants defined in [RFC8446].
Clients MUST NOT advertise these values in the signature_algorithms Clients MUST NOT advertise these values in the signature_algorithms
extension of the ClientHello. They MUST NOT accept these values in extension of the ClientHello. They MUST NOT accept these values in
the server CertificateVerify message. the server CertificateVerify message.
Servers that wish to support clients authenticating with legacy Servers that wish to support clients authenticating with legacy
RSASSA-PKCS1-v1_5-only keys MAY send these values in the RSASSA-PKCS1-v1_5-only keys MAY send these values in the
signature_algorithms extension of the CertificateRequest message and signature_algorithms extension of the CertificateRequest message and
accept them in the client CertificateVerify message. Servers MUST accept them in the client CertificateVerify message. Servers MUST
NOT accept these code points if not offered in the CertificateRequest NOT accept these code points if not offered in the CertificateRequest
skipping to change at page 4, line 35 skipping to change at line 156
user or have other side effects. user or have other side effects.
TLS implementations SHOULD disable these code points by default. See TLS implementations SHOULD disable these code points by default. See
Section 4. Section 4.
4. Security Considerations 4. Security Considerations
The considerations in Section 1 do not apply to server keys, so these The considerations in Section 1 do not apply to server keys, so these
new code points are forbidden for use with server certificates. new code points are forbidden for use with server certificates.
RSASSA-PSS continues to be required for TLS 1.3 servers using RSA RSASSA-PSS continues to be required for TLS 1.3 servers using RSA
keys. This minimizes the impact to only those cases necessary to keys. This minimizes the impact to only those cases in which it is
unblock TLS 1.3 deployment. necessary to unblock deployment of TLS 1.3.
When implemented incorrectly, RSASSA-PKCS1-v1_5 admits signature When implemented incorrectly, RSASSA-PKCS1-v1_5 admits signature
forgeries [MFSA201473]. Implementations producing or verifying forgeries [MFSA201473]. Implementations producing or verifying
signatures with these algorithms MUST implement RSASSA-PKCS1-v1_5 as signatures with these algorithms MUST implement RSASSA-PKCS1-v1_5 as
specified in section 8.2 of [RFC8017]. In particular, clients MUST specified in Section 8.2 of [RFC8017]. In particular, clients MUST
include the mandatory NULL parameter in the DigestInfo structure and include the mandatory NULL parameter in the DigestInfo structure and
produce a valid DER [X690] encoding. Servers MUST reject signatures produce a valid DER [X690] encoding. Servers MUST reject signatures
which do not meet these requirements. which do not meet these requirements.
5. IANA Considerations 5. IANA Considerations
IANA is requested to create the following entries in the TLS IANA has created the following entries in the "TLS SignatureScheme"
SignatureScheme registry. The "Recommended" column should be set to registry. The "Recommended" column has been set to "N", and the
"N", and the "Reference" column should be set to this document. "Reference" column refers to this document.
+========+=========================+ +========+=========================+
| Value | Description | | Value | Description |
+========+=========================+ +========+=========================+
| 0x0420 | rsa_pkcs1_sha256_legacy | | 0x0420 | rsa_pkcs1_sha256_legacy |
+--------+-------------------------+ +--------+-------------------------+
| 0x0520 | rsa_pkcs1_sha384_legacy | | 0x0520 | rsa_pkcs1_sha384_legacy |
+--------+-------------------------+ +--------+-------------------------+
| 0x0620 | rsa_pkcs1_sha512_legacy | | 0x0620 | rsa_pkcs1_sha512_legacy |
+--------+-------------------------+ +--------+-------------------------+
Table 1 Table 1
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[SHS] "Secure hash standard", National Institute of Standards [SHS] NIST, "Secure Hash Standard", NIST FIPS 180-4,
and Technology (U.S.), DOI 10.6028/nist.fips.180-4, 2015, DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/nist.fips.180-4>. <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[TPM12] Trusted Computing Group, "TPM Main Specification Level 2 [TPM12] Trusted Computing Group, "TPM Main, Part 2 - Structures of
Version 1.2, Revision 116, Part 2 - Structures of the the TPM", Level 2, Version 1.2, Revision 116, 1 March
TPM", 1 March 2011, <https://trustedcomputinggroup.org/wp- 2011, <https://trustedcomputinggroup.org/wp-
content/uploads/TPM-Main-Part-2-TPM- content/uploads/TPM-Main-Part-2-TPM-
Structures_v1.2_rev116_01032011.pdf>. Structures_v1.2_rev116_01032011.pdf>.
[TPM2] Trusted Computing Group, "Trusted Platform Module Library [TPM2] Trusted Computing Group, "Trusted Platform Module Library,
Specification, Family 2.0, Level 00, Revision 01.59, Part Part 1: Architecture", Family 2.0, Level 00, Revision
1: Architecture", 8 November 2019, 01.59, 8 November 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>. TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
6.2. Informative References 6.2. Informative References
[I-D.ietf-tls-hybrid-design]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-16, 7 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-16>.
[MFSA201473] [MFSA201473]
Delignat-Lavaud, A., "RSA Signature Forgery in NSS", 23 Delignat-Lavaud, A., "Mozilla Foundation Security Advisory
September 2014, <https://www.mozilla.org/en- 2014-73: RSA Signature Forgery in NSS", 24 September 2014,
US/security/advisories/mfsa2014-73/>. <https://www.mozilla.org/en-US/security/advisories/
mfsa2014-73/>.
[POODLE] Moeller, B., "This POODLE bites: exploiting the SSL 3.0 [POODLE] Moeller, B., "This POODLE bites: exploiting the SSL 3.0
fallback", 14 October 2014, fallback", Google Security Blog, 14 October 2014,
<https://security.googleblog.com/2014/10/this-poodle- <https://security.googleblog.com/2014/10/this-poodle-
bites-exploiting-ssl-30.html>. bites-exploiting-ssl-30.html>.
[PRIVACY] Wachs, M., Scheitle, Q., and G. Carle, "Push away your [PRIVACY] Wachs, M., Scheitle, Q., and G. Carle, "Push away your
privacy: Precise user tracking based on TLS client privacy: Precise user tracking based on TLS client
certificate authentication", IEEE, 2017 Network Traffic certificate authentication", 2017 Network Traffic
Measurement and Analysis Conference (TMA) pp. 1-9, Measurement and Analysis Conference (TMA). pp. 1-9,
DOI 10.23919/tma.2017.8002897, June 2017, DOI 10.23919/tma.2017.8002897, June 2017,
<https://doi.org/10.23919/tma.2017.8002897>. <https://doi.org/10.23919/tma.2017.8002897>.
[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954,
April 2026, <https://www.rfc-editor.org/info/rfc9954>.
Acknowledgements Acknowledgements
Thanks to Rifaat Shekh-Yusef, Martin Thomson, and Paul Wouters for Thanks to Rifaat Shekh-Yusef, Martin Thomson, and Paul Wouters for
providing feedback on this document. providing feedback on this document.
Authors' Addresses Authors' Addresses
David Benjamin David Benjamin
Google LLC Google LLC
Email: davidben@google.com Email: davidben@google.com
 End of changes. 29 change blocks. 
93 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.48.