]> Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Intuit

7 HaPsagot St. Petah Tikva Israel yaronf.ietf@gmail.com

Security LAMPS Internet-Draft This document specifies a new X.509 certificate extension, Post-Quantum or Composite Hosting Continuity (PQCHC), which enables a certificate subject to signal a intent to continue serving PQC or composite certificates for a defined continuity period after certificate expiration. This extension helps relying parties detect downgrade and man-in-the-middle (MitM) attacks during transition phases, where a cryptographically relevant quantum computer (CRQC) would make traditional certificates insecure.

Introduction The migration to post-quantum cryptography (PQC) will not happen instantly. During the transition, servers are expected to host both traditional and PQC or composite certificates. This dual-hosting strategy ensures that services remain reachable by legacy clients that do not yet support PQC while also providing PQ or PQ/T authentication to updated clients. The decision to continue offering traditional certificates often depends on the size of the installed legacy base, the larger the base, the stronger the incentive to maintain traditional certificate support for accessibility. Relevant work on PQC certificates includes for ML-DSA and for SLH-DSA and for composite certificates. However, the continued use of traditional certificates becomes untenable once a cryptographically relevant quantum computer (CRQC) is known to exist. A publicly available CRQC would render classical public-key algorithms insecure, forcing server operators to revoke traditional certificates immediately, even if this disrupts access for legacy clients. In practice, though, the availability of a CRQC may not be disclosed. Like a zero-day vulnerability, an adversary could secretly use a CRQC to compromise traditional certificates without alerting the wider ecosystem. In such a scenario, an attacker could suppress PQC or composite certificates and present only traditional ones to targeted clients, enabling an active MitM attack and giving the attacker full control over the encrypted session. Relying parties need a way to detect when a server that claims to support PQC or composite certificates suddenly offers only traditional credentials. This document specifies a new X.509 certificate extension, Post-Quantum/Composite Hosting Continuity (PQCHC), which enables a certificate subject and its Certification Authority (CA) to assert an intent to continue serving PQC or composite credentials for a defined period beyond the nominal expiration of a certificate. This extension provides an operational signal that helps relying parties identify inconsistencies, for example, when a PQC-capable server unexpectedly stops advertising PQC or composite certificates and to take appropriate action to mitigate downgrade attacks. The PQCHC extension is protocol-agnostic and applies to any PKI-based authentication context where a subject wishes to indicate continued availability of PQC or composite credentials to relying parties. The PQCHC extension does not change certificate validation semantics and does not extend a certificate's validity period. Instead, it provides an informational assurance of server behavior to help relying parties make security decisions during the transition to PQC.

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 when, and only when, they appear in all capitals, as shown here.

X.509 Certificate Extension This section specifies the syntax and semantics of the PQC or composite Hosting Continuity (PQCHC) extension for X.509 public key certificates. This extension provides an informational assertion, made by the certificate subject, regarding the continued availability of pure PQC or composite credentials beyond the expiration date of the certificate that contains the extension.

Extension Overview The PQCHC extension is an optional, non-critical X.509 certificate extension. When present, it indicates that the subject intends to continue deploying and presenting valid PQC or composite certificates both during the certificate’s validity period and for the declared "continuityPeriod" after the certificate’s "notAfter" date. This extension does not extend the certificate’s validity period and does not modify path validation procedures as defined in . The extension allows relying parties to detect inconsistencies during the PQC migration phase. For example, if a server previously declared an intent to keep its PQC certificate available for 12 months after expiry but suddenly presents only a traditional certificate, a relying party can infer potential misbehavior or active suppression of PQC credentials.

PQCHC Certificate Extension Definition The PQCHC certificate extension MAY be included in public key certificates . The PQCHC certificate extension MUST be identified by the following object identifier (OID): The extension MUST have the following syntax: The extension value is an ASN.1 SEQUENCE containing:

• continuityPeriod : an INTEGER (measured in days) indicating the number of days after the certificate’s "notAfter" date that the subject intends to continue presenting valid PQC/composite certificates. A value of zero explicitly indicates that no intent exists beyond the certificate’s expiry.
• policyURI (OPTIONAL): an IA5String containing a URI where the operator publishes additional information related to PQC deployment, such as migration information.

The extension MUST be marked non-critical so that relying parties that do not understand it will ignore it, consistent with guidance for informational extensions.

Certificate Extension Processing When this extension is present:

• The certificate subject asserts that the subject’s server(s) will continue deploying and presenting valid PQC or composite certificates for at least the indicated continuity period after this certificate’s expiration.
• The extension is a CA-signed declaration of the subject's operational intent and does not create a contractual service-level agreement between the subject and any relying party. Relying parties MAY use the indicated "continuityPeriod" to trigger local policy decisions, for example, by monitoring the revocation status of the declared PQC or composite certificate. If, during the stated period, the PQC or composite certificate remains unrevoked but is not observed in use, this may indicate a downgrade and MitM attack.

The extension does not imply that the CA will automatically issue new certificates, nor does it extend the cryptographic validity of an expired certificate. Rather, it signals the server operator's operational intent to maintain PQC or composite credentials in parallel with traditional credentials for the indicated transition period. After successful certificate path validation , a relying party that observes a certificate containing the PQCHC extension can cache the following information:

• the server identity (as indicated in the certificate’s SubjectAltName),
• the PQC or composite algorithm identifier (e.g., an OID such as id-ml-dsa-44 ) associated with the end-entity certificate,
• the remaining lifetime of the certificate at the time of observation (i.e., the time between observation and the certificate’s "notAfter" date).

The effective continuity window is the sum of the remaining lifetime and the "continuityPeriod". During this window, the relying party can expect the server to present certificates for the same subjectAltName that use the cached PQC or composite algorithm. If, within the effective continuity window, a relying party observes only a traditional certificate while the cached PQC/composite certificate remains unrevoked, the relying party SHOULD treat the behavior as suspicious and terminate the connection. The relying party MAY apply local downgrade-detection policy, which can range from logging or raising an alert, to attempting an alternate network path. If the operator changes from one PQC algorithm to another, the cached algorithm identifier will not match. In this case, the relying party MUST start a new continuity period. This also helps detect algorithm upgrades or downgrades (e.g., from ML-DSA-44 to ML-DSA-87). Note: PQCHC may also apply to PQC-to-PQC transitions. For example, an operator might switch from ML-DSA to SLH-DSA in response to deployment guidance. The security implications of treating PQC-to-PQC changes as continuity events remain an open question and require further analysis as NIST’s standardization process progresses.

Applicability and Deployment Considerations PQCHC is an informational mechanism and not a cryptographic guarantee. It must be combined with traditional mechanisms such as revocation checking. Its effectiveness depends on both correct configuration by servers and correct interpretation by relying parties. PQCHC can also appear in certificates used for CRL signing or OCSP response signing to assert that any successor certificate for these roles will use a PQC or composite algorithm. If, within the declared continuity period, a new CRL signing or OCSP responder certificate is issued using only a traditional algorithm, relying parties can interpret this as a potential downgrade. PQCHC cannot detect all failure modes. In particular, if a server silently ceases to present PQC or composite certificates without revoking them, relying parties will continue to observe only traditional certificates and have no authoritative indication whether the change was intentional or the result of an attack. In such cases PQCHC can only highlight the inconsistency. Operators should choose "continuityPeriod" values that balance the detection benefit against operational flexibility. A "continuityPeriod" that is too short increases the window in which an attacker can cause an undetected downgrade; a "continuityPeriod" that is overly long may unduly constrain the operator's ability to phase out an algorithm in response to new cryptanalytic evidence.

Security Considerations

Certificate Caching Versus PQCHC This section compares PQCHC to relying solely on client-side caching of previously observed PQC certificates and describes how PQCHC mitigates downgrade attacks. A relying party could, in principle, remember that it previously observed a PQC or composite certificate and enforce that expectation in subsequent connections. However, such caching is limited by certificate expiration: once the cached certificate passes its "notAfter" date, the relying party can no longer rely on it for validation, and any enforced expectation is effectively lost. An attacker who can suppress PQC or composite certificates at that moment could cause a downgrade to traditional certificates without detection. The PQCHC extension mitigates this limitation by providing a CA-signed assertion that the subject intends to continue deploying valid PQC or composite certificates for the configured continuityPeriod beyond the certificate’s expiration. Because this assertion is signed by the issuing CA and carried in the certificate, it provides a durable, authenticated basis for relying parties to detect inconsistencies that simple client-side caching cannot address.

Downgrade attack detection The PQCHC certificate extension provides a signal analogous to HTTP Strict Transport Security (HSTS) mechanism. Once a relying party has successfully observed a server presenting a PQC or composite certificate containing the PQCHC extension, it can "pin" the expectation that the server will continue to offer PQC or composite credentials until the date indicated by the extension. This mechanism helps relying parties detect inconsistent server behavior:

• If a PQC or composite certificate carrying PQCHC is expected to remain valid until a stated date but is revoked early, the change can be interpreted as a legitimate operational decision by the server operator.
• If the certificate remains unrevoked yet is not observed by clients in subsequent connections, this anomaly may indicate an active downgrade attack in which a MitM suppresses the PQC or composite certificate and presents only traditional credentials.

Bootstrap limitation Like HSTS mechanism, the PQCHC extension cannot provide protection on the very first connection. If an attacker successfully downgrades that initial handshake so the client never sees a PQC or composite certificate with PQCHC, the client will not learn the expected behavior and gains no additional assurance from this extension.

Revocation check Because an active MitM can block PQC or composite certificates, relying parties cannot confirm server behavior solely by observing TLS handshakes. Certificate revocation remains the most reliable mechanism for determining when a server has intentionally stopped using a PQC or composite certificate. Revocation can be signaled through CRLs published by CAs, OCSP, Browser curated revocation lists (e.g., CRLSet), or by relying on short-lived certificates that naturally expire quickly. During the transition to PQC, revocation information must remain verifiable by both legacy and upgraded clients. This requires that CRLs and OCSP responses be signed using both a traditional algorithm (e.g., RSA or ECDSA) for compatibility with legacy clients, and a PQC or composite algorithm for protection against CRQC adversaries. Legacy clients will continue to validate the traditional signature, while PQ-aware clients MUST verify the PQC or composite signature to ensure that revocation signaling itself cannot be forged. Curated browser/OS revocation lists can provide emergency coverage but generally do not cover all domains, limiting their completeness. OCSP stapling is also insufficient in this setting, since although an OCSP response itself provides freshness, stapling relies on the server to deliver that response and cannot guarantee that PQC certificates are included when a CRQC-capable adversary acts as a MitM and suppresses them. The PQCHC extension provides an informational signal that can support policy decisions, monitoring, and detection of possible downgrades. However, it is not a cryptographic proof of server behavior, and relying parties must continue to perform revocation checks to verify certificate validity. When inconsistencies are detected, relying parties may apply fallback mechanisms such as attempting connection through a different network interface or a VPN tunnel to help distinguish between genuine server changes and MitM downgrade attack. A PQC certificate may be revoked for legitimate reasons such as key compromise, operational error, or migration to a new CA. An operator using the PQCHC facility SHOULD obtain and serve a new PQC certificate for the remainder of the declared continuity period. This enables relying parties to continue to observe PQC credentials without requiring real-time revocation checking to distinguish legitimate operator actions from active downgrade attacks. In addition, this simplifies PQCHC by focusing on continuity of PQC credential availability rather than revocation mechanisms.

Privacy Considerations Relying parties need to perform certificate revocation checks to determine whether the PQC or composite certificate has been intentionally withdrawn by the server. Revocation mechanisms such as Online Certificate Status Protocol (OCSP) queries to the CA can expose which servers a client is contacting, leading to privacy leaks. To mitigate this, revocation checking can be performed using privacy-preserving techniques such as Oblivious HTTP (OHAI) , where queries are relayed through intermediaries in a way that hides the client identity from the CA.

IANA Considerations For the certificate extension in , IANA is requested to assign an object identifier (OID) for the extension (TBD2) with a Description of "id-pe-pqchc". The OID for the extension should be allocated in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1). For the ASN.1 module in , IANA is requested to assign an object identifier (OID) for the module identifier (TBD1) with a Description of "id-mod-pqchc". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

Acknowledgments Thanks to Mike Ounsworth for the discussion, review and comments.

Normative References ITU-T ITU-T AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. BSI Cisco Systems genua GmbH CryptoNext Security BSI Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST ML-DSA in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.

ASN.1 Module The following module adheres to ASN.1 specifications and .