| Internet-Draft | PQC Readiness Observability Gaps | June 2026 |
| Vicente | Expires 7 December 2026 | [Page] |
Network operators, PKI administrators, and compliance officers currently lack standardized mechanisms for continuously observing the post-quantum cryptographic (PQC) readiness posture of networked computing infrastructure. Existing network monitoring standards, PKI management protocols, and certificate status protocols do not define data models, collection methods, or scoring frameworks for assessing whether TLS endpoints, certificate authority infrastructure, and associated protocol components have migrated to quantum-resistant algorithms. This document describes the observability gap and derives the functional requirements that a standards-based PQC readiness monitoring framework must satisfy.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 7 December 2026.¶
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.¶
The migration from classical to post-quantum cryptographic algorithms is operationally complex. An organization may operate hundreds or thousands of TLS endpoints, certificate authority responders, API gateways, and load balancers, each independently negotiating cryptographic algorithms. Compliance with mandates such as NSA CNSA 2.0 requires not only deploying PQC-capable infrastructure but also verifying, continuously, that deployed infrastructure is actually using PQC algorithms in practice.¶
Existing network monitoring frameworks — including IPFIX [RFC7011], SNMP-based management, and flow-based telemetry — do not define data models or collection semantics for cryptographic algorithm metadata extracted from live protocol negotiations. Certificate management protocols such as ACME [RFC8555] and OCSP [RFC6960] convey certificate status but not operational algorithm usage at runtime.¶
This document identifies the functional requirements that a standards-compliant PQC readiness observability framework must satisfy, describes gaps in existing standards, and motivates future protocol work. No new protocol mechanisms are specified.¶
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.¶
An administrator seeking to determine the PQC readiness posture of their infrastructure today must manually inspect individual TLS handshakes, parse certificate chain metadata, and cross-reference OCSP and CRL signing algorithms. No existing standard defines:¶
A telemetry data model for cryptographic algorithm observations extracted from live network protocol negotiations.¶
A readiness classification taxonomy distinguishing quantum-vulnerable, hybrid-transitional, and fully PQC-compliant configurations.¶
A method for aggregating per-endpoint algorithm observations into an organization-level PQC readiness metric suitable for reporting to management or regulators.¶
A mechanism for mapping observed algorithm posture against regulatory compliance deadline frameworks and generating gap analyses.¶
The IETF hybrid key exchange draft [HYBRID-TLS] and RFC 9794 [RFC9794] define hybrid cryptographic configurations combining classical and PQC algorithms (e.g., X25519+ML-KEM-768, ECDSA-P256+ML-DSA-65). These hybrid configurations occupy a transitional security posture — stronger than purely classical configurations but not yet fully PQC-compliant. Existing monitoring tools provide no mechanism to detect hybrid configurations, distinguish them from classical or fully PQC configurations, or assign them an appropriate intermediate compliance status.¶
RFC 7696 [RFC7696] provides protocol design guidelines for algorithm agility — enabling selection of algorithms without hard-coded dependencies. However, algorithm agility without operational visibility creates a compliance risk: infrastructure that is algorithm-agile by design may silently negotiate quantum-vulnerable algorithms in production, with no monitoring system capable of detecting this condition.¶
RFC 6277 [RFC6277] specifies rules for server signature algorithm selection in OCSP responses. While this enables algorithm agility in certificate status responses, it does not define a mechanism for monitoring whether OCSP responders are issuing responses signed with PQC algorithms, or for aggregating OCSP signing algorithm observations across an infrastructure.¶
RFC 9162 [RFC9162] defines Certificate Transparency (CT) as an append-only log mechanism for public accountability of CA issuance. CT logs record issued certificates but do not provide:¶
The IP Flow Information Export (IPFIX) protocol [RFC7011] defines a framework for exporting flow-based network telemetry. The IPFIX information elements do not include fields for cryptographic algorithm identifiers observed in TLS handshakes, preventing existing flow telemetry infrastructure from being used for PQC readiness monitoring without extension.¶
The IETF draft for hybrid key exchange in TLS 1.3 [HYBRID-TLS] defines NamedGroup code points for hybrid constructions such as X25519MLKEM768. While this enables hybrid key exchange negotiation, no monitoring standard defines how to collect, aggregate, or report on the prevalence and distribution of these hybrid algorithm selections across a deployed infrastructure.¶
REQ-OBS-1: The framework MUST define a data model for cryptographic algorithm observations extracted from live network protocol negotiations, including at minimum: cipher suite identifiers, key exchange algorithm identifiers, digital signature algorithm identifiers, and certificate chain algorithm attributes.¶
REQ-OBS-2: The framework MUST support passive observation of cryptographic protocol metadata without requiring decryption of application-layer payload data.¶
REQ-OBS-3: The framework SHOULD support observation at multiple infrastructure tiers, including TLS termination points, certificate authority endpoints, OCSP responders, CRL distribution points, API gateways, and load balancers.¶
REQ-CLASS-1: The framework MUST classify each observed cryptographic algorithm into one of at least three readiness categories: quantum-vulnerable, hybrid-transitional, and PQC-compliant.¶
REQ-CLASS-2: The framework MUST correctly identify and classify hybrid cryptographic configurations as defined in [RFC9794], including at minimum ML-KEM-based hybrid key exchange and ML-DSA-based hybrid signature configurations.¶
REQ-SCORE-1: The framework SHOULD support computation of a per-endpoint readiness metric derived from the classified algorithms observed at that endpoint.¶
REQ-SCORE-2: The framework SHOULD support computation of an aggregate organizational readiness metric from per-endpoint observations, with the ability to weight endpoints by operational criticality.¶
REQ-SCORE-3: The framework MUST support time-series storage of readiness observations to enable historical trend analysis of PQC migration progress.¶
REQ-COMP-1: The framework MUST support mapping of per-endpoint readiness observations against configurable compliance deadline profiles, including at minimum the CNSA 2.0 migration timeline.¶
REQ-COMP-2: The framework MUST generate gap reports identifying endpoints and certificate infrastructure components that require algorithm migration before applicable deadlines.¶
REQ-REM-1: The framework SHOULD produce prioritized remediation guidance identifying which endpoints require migration action, ordered by the combination of compliance deadline proximity and operational risk exposure.¶
REQ-REM-2: The framework SHOULD support analysis of the dependency relationships between endpoints to assist operators in planning safe migration sequences.¶
The primary threat model motivating this document is HNDL: adversaries that capture data encrypted with quantum-vulnerable algorithms today can decrypt it once a CRQC becomes available. For PKI infrastructure, the additional concern is that a CA signing key protected by a quantum-vulnerable algorithm compromises the entire certificate hierarchy under that key, affecting all relying parties.¶
Mosca's inequality [MOSCA] quantifies the urgency: if the estimated time to CRQC is less than the sum of the time required to complete migration and the required confidentiality lifetime of the protected data, then the organization is already at risk. A readiness observability framework enables operators to measure their current posture against this threshold continuously.¶
Passive observation of cryptographic metadata from live network traffic introduces a privacy consideration: the metadata observed (certificate fingerprints, endpoint identifiers, algorithm selections) may be sensitive in some deployment contexts. Implementations MUST apply appropriate access controls to telemetry collection and storage infrastructure.¶
A readiness observability framework MUST NOT require decryption of application-layer payload data. Observation MUST be limited to cryptographic protocol metadata visible in plaintext during the handshake phase.¶
This document has no IANA actions. Future work specifying a concrete PQC readiness telemetry data model may require IANA registration of new IPFIX Information Elements or YANG data model namespaces.¶