PQC Continuity: Downgrade Protection for TLS Servers Migrating to PQC
draft-sheffer-tls-pqc-continuity-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yaron Sheffer , Tirumaleswar Reddy.K | ||
| Last updated | 2026-06-09 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sheffer-tls-pqc-continuity-02
Transport Layer Security Y. Sheffer
Internet-Draft Intuit
Intended status: Standards Track T. Reddy
Expires: 11 December 2026 Nokia
9 June 2026
PQC Continuity: Downgrade Protection for TLS Servers Migrating to PQC
draft-sheffer-tls-pqc-continuity-02
Abstract
As the Internet transitions toward post-quantum cryptography (PQC),
many TLS servers will continue supporting traditional certificates to
maintain compatibility with legacy clients. However, this
coexistence introduces a significant vulnerability: an undetected
rollback attack, where a malicious actor strips the PQC or composite
certificate and forces the use of a classical certificate once
quantum-capable adversaries exist.
To defend against this, this document defines a TLS extension that
allows a TLS client to cache a server's declared commitment to
present PQC or composite certificates for a specified duration. On
subsequent connections, the client enforces that cached commitment
and rejects traditional-only certificates that conflict with it.
This mechanism, inspired by HTTP Strict Transport Security (HSTS) but
operating at the TLS layer, provides PQC downgrade protection without
requiring changes to certificate authority (CA) infrastructure.
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://yaronf.github.io/draft-sheffer-tls-pqc-continuity/draft-
sheffer-tls-pqc-continuity.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
sheffer-tls-pqc-continuity/.
Source for this draft and an issue tracker can be found at
https://github.com/yaronf/draft-sheffer-tls-pqc-continuity.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Sheffer & Reddy Expires 11 December 2026 [Page 1]
Internet-Draft PQC Continuity June 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. The pq_cert_available Extension . . . . . . . . . . . . . . . 4
3.1. PQC end-entity certificate . . . . . . . . . . . . . . . 4
3.2. Certificate chain . . . . . . . . . . . . . . . . . . . . 5
3.3. Extension Definition . . . . . . . . . . . . . . . . . . 5
3.4. Cache indexing . . . . . . . . . . . . . . . . . . . . . 6
3.5. Algorithm Selection . . . . . . . . . . . . . . . . . . . 6
3.6. Client behavior . . . . . . . . . . . . . . . . . . . . . 7
3.7. Server behavior . . . . . . . . . . . . . . . . . . . . . 7
4. Operational Considerations . . . . . . . . . . . . . . . . . 8
4.1. CDNs and changing certificate chains . . . . . . . . . . 8
4.2. TLS-terminating intermediaries . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. First connection and cached state . . . . . . . . . . . . 9
5.2. Cache churn and denial of service . . . . . . . . . . . . 10
5.3. Related threats . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Document History . . . . . . . . . . . . . . . . . . . . . . 10
7.1. draft-sheffer-tls-pqc-continuity-02 . . . . . . . . . . . 10
Sheffer & Reddy Expires 11 December 2026 [Page 2]
Internet-Draft PQC Continuity June 2026
7.2. draft-sheffer-tls-pqc-continuity-01 . . . . . . . . . . . 11
7.3. draft-sheffer-tls-pqc-continuity-00 . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Comparison with the Certificate-Based Solution . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The migration to post-quantum cryptography (PQC) will be gradual.
Servers will likely host both traditional and PQC (or composite)
certificates to maintain compatibility: legacy clients can still
connect, while updated ones benefit from PQC authentication. The
size of the legacy client base often drives the decision to keep
traditional certificates. Relevant PQC work includes
[I-D.ietf-lamps-dilithium-certificates] (ML-DSA),
[I-D.ietf-lamps-x509-slhdsa] (SLH-DSA), and
[I-D.ietf-lamps-pq-composite-sigs] (composites). Not only must
legacy clients be supported by servers for years, new clients that
support PQC are also incented to accept traditional certificates, to
retain connectivity to legacy servers.
Once a cryptographically relevant quantum computer (CRQC) emerges
publicly, traditional certificates become insecure and must be
revoked, regardless of legacy disruption. However, a CRQC may remain
undisclosed, allowing attackers to exploit classical algorithms
secretly. In such cases, adversaries could strip PQC or composite
certificates, present only traditional ones, and conduct MitM
attacks. Relying parties therefore need mechanisms to detect when
servers claiming PQC support revert to traditional credentials only.
[RescorlaPQEmergency] is an informal, accessible description of the
threat of CRQC emergence and the difficulties of mounting a
coordinated response.
To prevent such downgrade attacks, this document defines a TLS
extension that enables a TLS client to cache an indication that the
server is able to present a (composite or pure) PQC certificate, for
some duration of time, e.g. one year. As a result:
* Clients reconnecting to an already known server within the
validity period are protected from rollback to classical
certificates.
Sheffer & Reddy Expires 11 December 2026 [Page 3]
Internet-Draft PQC Continuity June 2026
* A client begins enforcing the server's PQC commitment only after
it has successfully connected to the legitimate server at least
once (i.e., a connection not intercepted by a MitM). Earlier
connections that are intercepted or downgraded do not prevent the
client from gaining protection once it later observes a PQC
commitment from a legitimate server.
The explicitly communicated caching time allows clients and server
operators to implement a caching policy with no risk of sudden
breakage, and allows certificate holders to revert to traditional
certificates if they ever see the need to do so.
This extension is modeled on HSTS [RFC6797], but whereas HSTS is at
the HTTP layer, this extension is implemented at the TLS layer.
Normative requirements in this document apply to TLS clients caching
server commitments only. A symmetric design (TLS servers caching
client certificate commitments in mutual TLS) is not specified here
since it would add significant complexity and we believe this
complexity is not justified in most use cases.
An alternative approach to downgrade attacks, described in
[I-D.reddy-lamps-x509-pq-commit], uses specially marked certificates
to denote the server's long-term commitment to use PQC algorithms.
See Appendix A for a comparison between the two approaches.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The pq_cert_available Extension
The following section defines a TLS extension that describes a
server's commitment to present PQC credentials to clients that
support this mechanism.
3.1. PQC end-entity certificate
For this document, a PQC end-entity certificate is one that is not
traditional-only: the EE signature employs post-quantum cryptography,
whether as a pure PQ algorithm (for example PKIX profiles in
[I-D.ietf-lamps-dilithium-certificates] and related LAMPS work) or as
a composite PQ algorithm [I-D.ietf-lamps-pq-composite-sigs]. Pure PQ
and composite PQ are treated identically by this document. Which EE
Sheffer & Reddy Expires 11 December 2026 [Page 4]
Internet-Draft PQC Continuity June 2026
certificates satisfy that classification in a deployment is left to
client policy; this text is informative context, not a closed list of
algorithms.
3.2. Certificate chain
Post-quantum authentication requires signatures along the entire path
to be resistant to quantum-capable adversaries; a PQC end-entity
certificate paired with a classically signed intermediate does not
provide this property. For a fully PQ-signed path through the PKI,
trust anchors would also need to be PQ-capable where they participate
in validation; this document does not specify trust-store policy.
When the client requires a PQC end-entity certificate for that
handshake (including because the server sends non-empty
pq_cert_available extension data on the first CertificateEntry, or
because the client holds unexpired cached information for this server
per Client behavior), the client MUST apply its PQC policy to every
CertificateEntry in the server's Certificate message using the same
criterion as in Section 3.1. If any CertificateEntry does not
satisfy this requirement, the client MUST abort the handshake with a
certificate_unknown alert.
3.3. Extension Definition
This is a TLS extension, as per sec. 4.2 of [RFC8446]. The extension
type for pq_cert_available is TBD by IANA. It MAY appear in the
ClientHello (CH) message and in the server's Certificate message.
A supporting client MUST include this extension in its ClientHello
message, with no extension data.
If the client indicates support, the server MAY include the extension
in its Certificate message.
The extension data when sent in the server's Certificate message is
either empty (no octets) or:
struct {
uint32 algorithm_validity_period;
}
This extension follows the format of TLS 1.3 Certificate message
extensions as defined in Sec. 4.4.2 of [RFC8446].
The algorithm_validity_period field is the time duration, in seconds,
that the server commits to continue to present a PQC end-entity
certificate. The time duration is measured starting from the current
Sheffer & Reddy Expires 11 December 2026 [Page 5]
Internet-Draft PQC Continuity June 2026
TLS handshake and is unrelated to any particular certificate or its
lifecycle. A duration of zero indicates no positive commitment (not
a new validity window). When the end-entity certificate is PQC, that
is how the server withdraws a prior commitment (see Client behavior).
A client that receives pq_cert_available in the server's Certificate
message MUST reject extension data whose length is neither zero nor
four octets; it MUST abort the handshake with a decode_error alert.
A server that receives pq_cert_available in the ClientHello MUST
reject extension data whose length is not zero; it MUST abort the
handshake with a decode_error alert.
In the server's Certificate message, pq_cert_available MUST appear
only in the extensions field of the first CertificateEntry (the end-
entity certificate) [RFC8446]. A server MUST NOT attach this
extension to any other CertificateEntry. A client that finds
pq_cert_available on any other CertificateEntry MUST abort the
handshake with an illegal_parameter alert.
3.4. Cache indexing
The client MUST key each cache entry by the authenticated TLS server
identity from [RFC9525], the port, and whether the handshake is
connection-oriented (TLS) or datagram (DTLS). Entries that differ in
any of these MUST NOT be merged.
3.5. Algorithm Selection
If the client holds unexpired cached information for the server:
* The client MUST NOT offer legacy-only values in
signature_algorithms: it MUST include one or more PQC-capable
schemes.
* It SHOULD include schemes consistent with enforcing the
commitment, e.g. those it derived from the server's certificate on
a prior connection or those it uses for this cache entry, all
subject to local policy.
* It MAY include additional PQC signature algorithms according to
local policy.
As a result, the handshake would fail if a rollback attack is
attempted.
Sheffer & Reddy Expires 11 December 2026 [Page 6]
Internet-Draft PQC Continuity June 2026
3.6. Client behavior
A client that supports this extension MUST behave as follows:
1. If the client holds no cached information for the server, and the
server includes a non-empty extension:
* If the algorithm_validity_period is zero, the client MUST NOT
cache the information.
* Otherwise, the client SHOULD cache the commitment after the
handshake completes successfully.
* The client SHOULD record the server's actual signature
algorithm for subsequent ClientHello signature_algorithms
selection.
* The client MAY choose to cache for a shorter period than
specified.
2. If the client holds unexpired cached information for the server,
and receives the extension from the server:
* If the algorithm_validity_period is zero, the client MUST
clear the cached information for this server.
* Otherwise, the client MUST apply Section 3.2 and SHOULD extend
its cache period if the received time value would expire later
than its current cache expiry.
* It SHOULD silently ignore an algorithm_validity_period value
if it would decrease its existing cached expiry.
3. If the client holds unexpired cached information for the server,
and receives no extension from the server in the Certificate
message, the client SHOULD NOT modify its cache.
3.7. Server behavior
1. A server that receives client support for this extension SHOULD
send this extension in the extensions field of the first
CertificateEntry only when it uses a PQC signature algorithm.
2. The server MUST keep track of the time duration it has committed
to, and use a PQC certificate to authenticate itself for that
entire duration. The server MAY change its certificates and may
switch between PQC signature algorithms at will, provided the
client indicates acceptance of these algorithms.
Sheffer & Reddy Expires 11 December 2026 [Page 7]
Internet-Draft PQC Continuity June 2026
This obligation is analogous to maintaining HSTS continuity: once a
commitment is made, the server MUST avoid reverting to classical
certificates until expiry of algorithm_validity_period.
If a traditional (non-PQC) certificate is used, the server SHOULD
send the extension with no extension data on the first
CertificateEntry only. If a PQC certificate is used, the server MUST
send exactly the four-octet algorithm_validity_period on the first
CertificateEntry only (not an empty extension).
When the server sends non-empty pq_cert_available extension data on
the first CertificateEntry, every CertificateEntry in the server's
Certificate message MUST be PQC under the same definition as in
Section 3.1.
4. Operational Considerations
This extension establishes a (potentially) long-term commitment of
the server to support PQC signature algorithms. As such, we
recommend that deployers first experiment with short validity periods
(e.g. one day), and only when satisfied that clients populate and
depopulate their cache correctly, they can move to a longer duration.
In the case of HSTS, lifetimes are commonly set to one year.
Advertising algorithm_validity_period of zero does not clear every
client's cache at the same instant. Clients that never complete
another handshake to this server keep enforcing until their earlier
cached expiry or until they observe zero on a completed handshake.
Operators should assume overlap up to the longest validity they
previously published while clients may still have been caching.
4.1. CDNs and changing certificate chains
The same logical server (same DNS name and application identity) may
present different certificate chains over time, for example when
using a CDN with different points of presence, or multiple CAs.
Cache entries are keyed by authenticated server identity
(Section 3.4), not by a particular chain. Operators SHOULD ensure
that every chain presented while a non-empty commitment is in effect
satisfies Section 3.2 when PQC is required.
Sheffer & Reddy Expires 11 December 2026 [Page 8]
Internet-Draft PQC Continuity June 2026
4.2. TLS-terminating intermediaries
Enterprise inspection proxies are common in practice: they terminate
TLS toward the client and present a certificate issued under a
locally trusted CA rather than the origin's Web PKI chain. The same
normative constraint applies to any on-path endpoint that is not
operated by the origin but presents a server Certificate message to
the client.
An endpoint that terminates TLS toward the client and is not operated
by the origin MUST NOT send non-empty pq_cert_available extension
data unless it presents a PQC end-entity certificate chain toward the
client that satisfies Section 3.2 and can honor the commitment for
algorithm_validity_period on that client-facing connection.
Otherwise it MUST NOT inject a non-empty commitment on behalf of the
origin.
Many TLS clients only ever connect over paths validated with public
Web PKI; for them, the rules elsewhere in this document apply without
additional policy. Clients that are configured to trust an
enterprise or security appliance for inspection typically see most or
all origins through that appliance unless the deployment makes an
explicit exception; the user or organization has already accepted
that the appliance terminates TLS and can present its own
certificates. Implementations in such environments MAY choose how to
cache or enforce pq_cert_available when validation uses only
inspection roots---for example by not applying a commitment recorded
on an inspection path when the same name is later reached on a direct
Web PKI path, or by accepting traditional chains when the path chains
only to inspection CAs. This document does not mandate those
details. HTTP Public Key Pinning [RFC7469] (Historic) described an
analogous exception in Section 2.6: user agents could disable pin
validation when the validated chain terminated at a user-defined
trust anchor rather than a built-in anchor.
5. Security Considerations
5.1. First connection and cached state
Protection against downgrade applies only after the client has
completed a handshake to the legitimate server and recorded a
commitment (see Section 1). Until then, behavior matches the usual
trust-on-first-use limitation of channel-based pinning, analogous to
HTTP Strict Transport Security (HSTS) [RFC6797]: an active adversary
who controls an earlier connection can prevent useful cache
population or cause the client to store parameters chosen by the
adversary. Cached entries are only as reliable as the authenticated
channel that produced them.
Sheffer & Reddy Expires 11 December 2026 [Page 9]
Internet-Draft PQC Continuity June 2026
Operationally, the damage is limited. If cache population is
suppressed, the client would realize that the server is PQC-capable
as soon as it connects directly to the server.
5.2. Cache churn and denial of service
A malicious or compromised server can send a different
algorithm_validity_period (or alternate between zero and non-zero
values) on every successful handshake, causing the client to update
persistent cache state repeatedly. That can amplify storage I/O and
resource use and become a denial-of-service vector against the
client. Implementations SHOULD rate-limit or coalesce cache updates
per server key (see Section 3.4), and SHOULD avoid writing to durable
storage when the update is minor compared to what is already stored:
for example when the received algorithm_validity_period differs by at
most one day (86400 seconds) from the value already associated with
this cache entry, such as from small jitter or rounding.
5.3. Related threats
This mechanism does not replace PKIX validation, name verification,
or trust anchor policy; it adds downgrade protection once a
legitimate commitment has been observed. Traditional certificate
chains remain out of scope except where this document already
requires rejection (see Section 3.2).
6. IANA Considerations
IANA is requested to assign a new value from the “TLS ExtensionType
Values” registry.
+=======+===================+=========+=============+===============+
| Value | Extension Name | TLS 1.3 | Recommended | Reference |
+=======+===================+=========+=============+===============+
| TBD | pq_cert_available | CH, CT | Y | This |
| | | | | document |
+-------+-------------------+---------+-------------+---------------+
Table 1
7. Document History
RFC Editor: please remove before publication.
7.1. draft-sheffer-tls-pqc-continuity-02
Implemented comments received on the mailing list and learnings from
an implementation.
Sheffer & Reddy Expires 11 December 2026 [Page 10]
Internet-Draft PQC Continuity June 2026
* Normative scope: TLS clients caching server commitments only;
cache indexing (RFC 9525). Informative note on out-of-scope
symmetric use case. GitHub #4 closed with repository comment only
(CertificateRequest / mutual-TLS client caching path obsolete; no
further draft change).
* Certificate extension: algorithm_validity_period only (GitHub #9).
* Malformed extension length: decode_error (GitHub #11).
* EE-only Certificate extension placement: illegal_parameter if
misplaced (GitHub #12).
* Cache key: RFC 9525 identity, port, TLS vs DTLS (GitHub #13).
* Remove "few seconds" tolerance when decreasing cached validity
(GitHub #15).
* algorithm_validity_period zero: withdrawal semantics; stale-cache
operations (GitHub #16).
* Define PQC EE cert: pure PQ and composite PQ one class (GitHub
#17).
* Certificate chain: client MUST reject non-PQC or mixed chains when
commitment applies; certificate_unknown (GitHub #6; supersedes #12
commitment/EE mismatch alert).
* Security Considerations: first-connection trust, cache churn / DoS
(GitHub #18).
* Operational: CDNs; TLS-terminating intermediaries (commitment
injection, optional client behavior) (GitHub #7).
* Acknowledgments (GitHub #19).
7.2. draft-sheffer-tls-pqc-continuity-01
* Language consistency improvements (terminology, field names,
formatting).
* Technical consistency improvements (bidirectional scope, cache
semantics, validation requirements).
7.3. draft-sheffer-tls-pqc-continuity-00
Initial version.
Sheffer & Reddy Expires 11 December 2026 [Page 11]
Internet-Draft PQC Continuity June 2026
Acknowledgments
Thanks to Eric Rescorla, Yaroslav Rosomakho, Muhammad Usama Sardar,
and Scott Fluhrer for helpful discussion on the TLS mailing list.
References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
Informative References
[I-D.ietf-lamps-dilithium-certificates]
Massimo, J., Kampanakis, P., Turner, S., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", Work in Progress, Internet-
Draft, draft-ietf-lamps-dilithium-certificates-13, 30
September 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-dilithium-certificates-13>.
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
Sheffer & Reddy Expires 11 December 2026 [Page 12]
Internet-Draft PQC Continuity June 2026
[I-D.ietf-lamps-x509-slhdsa]
Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and
S. Kousidis, "Internet X.509 Public Key Infrastructure:
Algorithm Identifiers for SLH-DSA", Work in Progress,
Internet-Draft, draft-ietf-lamps-x509-slhdsa-09, 30 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-x509-slhdsa-09>.
[I-D.reddy-lamps-x509-pq-commit]
Reddy.K, T., Gray, J., and Y. Sheffer, "X.509 Extensions
for PQC or Composite Certificate Hosting Continuity", Work
in Progress, Internet-Draft, draft-reddy-lamps-x509-pq-
commit-01, 25 February 2026,
<https://datatracker.ietf.org/doc/html/draft-reddy-lamps-
x509-pq-commit-01>.
[RescorlaPQEmergency]
Rescorla, E., "PQ emergency (Educated Guesswork)", n.d.,
<https://educatedguesswork.org/posts/pq-emergency/>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/rfc/rfc6797>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/rfc/rfc7469>.
Appendix A. Comparison with the Certificate-Based Solution
This section is a comparison with an analogous solution
[I-D.reddy-lamps-x509-pq-commit] for the same rollback problem, one
that signals server continuity using certificates rather than the TLS
connection itself.
* The certificate-based solution does not change the TLS handshake,
which potentially makes adoption easier. However, changes to the
Web Public Key Infrastructure would also affect adoption.
* The certificate-based solution is independent of TLS and thus can
be used by other protocols.
* Operationally, it may be harder to manage the “commitment” through
certificates vs. TLS configuration. For example, in the HSTS
space, it is common to experiment first with very short durations,
e.g. 1 day, before moving to a longer commitment. This could have
a significant effect on real-life adoption.
Sheffer & Reddy Expires 11 December 2026 [Page 13]
Internet-Draft PQC Continuity June 2026
* The revocation checking aspect of the certificate-based solution
relies upon other mechanisms (e.g. CRLs, OCSP) to also be signed
with PQC/composite. Those other RFCs and implementations are
likely to take even longer to materialize.
Authors' Addresses
Yaron Sheffer
Intuit
Email: yaronf.ietf@gmail.com
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: k.tirumaleswar_reddy@nokia.com
Sheffer & Reddy Expires 11 December 2026 [Page 14]