Post-Quantum Use In Protocols (pquip) B. Vicente Internet-Draft Sanctum SecOps LLC Intended status: Informational 5 June 2026 Expires: 7 December 2026 Gaps in Operational Visibility for Post-Quantum Cryptographic Readiness in Networked Computing Environments draft-vicente-pquip-pqc-readiness-gaps-00 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Vicente Expires 7 December 2026 [Page 1] Internet-Draft PQC Readiness Observability Gaps June 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2.1. The Operational Visibility Gap . . . . . . . . . . . . . 3 2.2. Hybrid Algorithm Complexity . . . . . . . . . . . . . . . 4 2.3. Algorithm Agility Without Visibility . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Gaps in Existing Standards . . . . . . . . . . . . . . . . . 5 4.1. OCSP Algorithm Agility (RFC 6277) . . . . . . . . . . . . 5 4.2. Certificate Transparency (RFC 9162) . . . . . . . . . . . 5 4.3. IPFIX and Flow Telemetry (RFC 7011) . . . . . . . . . . . 5 4.4. TLS 1.3 Hybrid Key Exchange . . . . . . . . . . . . . . . 5 5. Functional Requirements for a PQC Readiness Observability Framework . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Telemetry Collection . . . . . . . . . . . . . . . . . . 6 5.2. Algorithm Classification . . . . . . . . . . . . . . . . 6 5.3. Readiness Assessment . . . . . . . . . . . . . . . . . . 6 5.4. Compliance Mapping . . . . . . . . . . . . . . . . . . . 7 5.5. Remediation Guidance . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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 Vicente Expires 7 December 2026 [Page 2] Internet-Draft PQC Readiness Observability Gaps June 2026 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. 1.1. Requirements Language 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. 2. Problem Statement 2.1. The Operational Visibility Gap 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. Vicente Expires 7 December 2026 [Page 3] Internet-Draft PQC Readiness Observability Gaps June 2026 2.2. Hybrid Algorithm Complexity 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. 2.3. Algorithm Agility Without Visibility 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. 3. Terminology PQC Readiness: The degree to which a networked computing environment's cryptographic algorithm usage in active protocol negotiations and certificate infrastructure is consistent with post-quantum cryptographic requirements. Quantum-Vulnerable Algorithm: A cryptographic algorithm whose security is broken or significantly weakened by a CRQC, including RSA, ECDSA, ECDH, and DSA. Hybrid-Transitional Configuration: A cryptographic configuration combining a classical algorithm and a post-quantum algorithm as defined in [RFC9794]. PQC-Compliant Algorithm: A cryptographic algorithm standardized by NIST in FIPS 203, FIPS 204, or FIPS 205 (ML-KEM, ML-DSA, or SLH- DSA), used without classical algorithm dependency. CRQC: Cryptographically Relevant Quantum Computer, as defined in context of Mosca's inequality [MOSCA]. HNDL: Harvest Now, Decrypt Later. A threat model in which an adversary records encrypted data today for future decryption once a CRQC becomes available. Vicente Expires 7 December 2026 [Page 4] Internet-Draft PQC Readiness Observability Gaps June 2026 Algorithm Observation Point: A network location at which cryptographic protocol metadata — cipher suite, key exchange algorithm, signature algorithm — can be passively observed from live protocol negotiations without decrypting application payloads. 4. Gaps in Existing Standards 4.1. OCSP Algorithm Agility (RFC 6277) 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. 4.2. Certificate Transparency (RFC 9162) 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: * Real-time observation of the algorithms actually negotiated in live TLS handshakes. * Aggregated readiness metrics across an organization's infrastructure. * Mapping of observed posture against compliance deadline profiles. 4.3. IPFIX and Flow Telemetry (RFC 7011) 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. 4.4. TLS 1.3 Hybrid Key Exchange 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. Vicente Expires 7 December 2026 [Page 5] Internet-Draft PQC Readiness Observability Gaps June 2026 5. Functional Requirements for a PQC Readiness Observability Framework 5.1. Telemetry Collection 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. 5.2. Algorithm Classification 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. 5.3. Readiness Assessment 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. Vicente Expires 7 December 2026 [Page 6] Internet-Draft PQC Readiness Observability Gaps June 2026 5.4. Compliance Mapping 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. 5.5. Remediation Guidance 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. 6. Security Considerations 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. Vicente Expires 7 December 2026 [Page 7] Internet-Draft PQC Readiness Observability Gaps June 2026 7. IANA Considerations 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. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC5280] Cooper, D., "Internet X.509 PKI Certificate and CRL Profile", RFC 5280, May 2008, . [RFC8555] Barnes, R., "Automatic Certificate Management Environment (ACME)", RFC 8555, March 2019, . [RFC7011] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol", RFC 7011, September 2013, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility", RFC 7696, November 2015, . [RFC9794] Hale, N., "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, June 2025, . [RFC6960] Santesson, S., "X.509 Internet PKI Online Certificate Status Protocol (OCSP)", RFC 6960, June 2013, . [RFC6277] Santesson, S., "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011, . Vicente Expires 7 December 2026 [Page 8] Internet-Draft PQC Readiness Observability Gaps June 2026 [RFC9162] Laurie, B., "Certificate Transparency Version 2.0", RFC 9162, December 2021, . 8.2. Informative References [RFC9763] Ounsworth, M., "Related Certificates for Use in Multiple Authentications", RFC 9763, April 2025, . [HYBRID-TLS] Stebila, D., "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 2025, . [MOSCA] Mosca, M., "Cybersecurity in an Era with Quantum Computers: Will We Be Ready?", IEEE Security and Privacy 16(5):38-41, 2018. [CNSA20] NSA, "Commercial National Security Algorithm Suite 2.0", NSA CNSA 2.0, September 2022. [NIST-PQC] NIST, "Post-Quantum Cryptography Standards: FIPS 203, 204, 205", NIST FIPS 203/204/205, August 2024. Author's Address Brian Vicente Sanctum SecOps LLC Horseheads, NY United States of America Email: info@sanctumsecops.com Vicente Expires 7 December 2026 [Page 9]