X.509 Extensions for PQC or Composite Certificate Hosting Continuity

3.1. 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 [RFC5280].¶

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.¶

3.2. PQCHC Certificate Extension Definition

The PQCHC certificate extension MAY be included in public key certificates [RFC5280]. The PQCHC certificate extension MUST be identified by the following object identifier (OID):¶

id-pe-pqchc OBJECT IDENTIFIER ::= {
    iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-pe(1) TBD2
}

The extension MUST have the following syntax:¶

PQCHC ::= SEQUENCE {
continuityPeriod INTEGER (0..MAX),
policyURI IA5String OPTIONAL
}

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 [RFC5280] guidance for informational extensions.¶

3.3. 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 [RFC5280], 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 [I-D.ietf-lamps-dilithium-certificates]) 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.¶

5.1. 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.¶

5.2. 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.¶

5.3. 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.¶

5.4. 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.¶