PQC Readiness Observability Gaps in Networked Computing Environments

Internet-Draft	PQC Readiness Gaps	September 2026
Vicente	Expires 15 March 2027	[Page]

Abstract

This document identifies observability gaps that prevent network operators and security teams from determining the post-quantum cryptography (PQC) readiness state of networked computing environments. PQC readiness requires knowing which cryptographic algorithms are in use across the environment, which are vulnerable to quantum attack, and which have been or are being migrated to NIST-approved PQC algorithms. Current network protocols and management frameworks do not provide sufficient visibility to answer these questions at scale.¶

This revision (-03) adds a Posture B IPR notice, differentiates from adjacent Cryptography Bill of Materials (CBOM) work, and adds machine-readable JSON evidence. The gaps identified in this document are observability gaps — the absence of machine-readable, network-layer signals that enable automated PQC readiness assessment. This differs from CBOM, which focuses on software composition and supply-chain inventory.¶

Supplementary Materials

This note is to be removed before publishing as an RFC.¶

Reference implementation: CygnetLib (https://github.com/sanctumsecopsmssp/CygnetLib). JSON evidence: algorithm registry, CNSA 2.0 compliance matrix, IETF PQC interoperability status, and ACTV test vectors are in the evidence/ directory. CAGE/NCAGE: 20XS3. Apex website: https://www.sanctumsecops.com/.¶

IPR Considerations

This note is to be removed before publishing as an RFC.¶

Sanctum IP Co (a Delaware corporation, assignee of Sanctum SecOps LLC) holds or intends to file patent or other intellectual property rights covering subject matter described in this document, including the PQC readiness observability gap taxonomy, the network-layer readiness signal model, and the automated readiness assessment framework. The public disclosure of this Internet-Draft constitutes prior art as of its submission date with respect to the specific combination of features described herein. By posting this Internet-Draft, the author submits to the IETF Trust the rights described in BCP 78 and BCP 79. Implementers MUST consult the IETF Datatracker IPR page for this document before implementation.¶

All intellectual property described in this document is owned by Sanctum IP Co, 128 Dry Run Rd, Pine City, NY 14871. Contact: bvicente@sanctumsecops.com.¶

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 15 March 2027.¶

Copyright Notice

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

1. Introduction

1.1. Motivation

Preparing a networked computing environment for the post-quantum era requires operators to know: which cryptographic algorithms are currently in use across all network endpoints, services, and protocols; which of those algorithms are vulnerable to attacks by a Cryptographically Relevant Quantum Computer (CRQC) using Shor's algorithm [SHOR1994]; and which have been or are actively being migrated to NIST-approved PQC algorithms (FIPS 204, FIPS 205).¶

Current network protocols — TLS [RFC8446], QUIC [RFC9000], SSH, DNSSEC — do not provide machine-readable, network-layer signals that enable automated aggregation of cryptographic algorithm usage across an environment. SNMP MIBs, NetFlow/IPFIX, and syslog carry no structured cryptographic algorithm inventory. This creates five distinct observability gaps that prevent automated PQC readiness assessment at scale.¶

1.2. Differentiation from CBOM and Software Inventory Approaches

Cryptography Bill of Materials (CBOM) work — as developed in the context of software supply chain security and SBOM frameworks — addresses the inventory of cryptographic libraries and algorithms as software components within application and OS stacks. CBOM answers: "which cryptographic libraries does this software use?"¶

This document addresses a distinct and complementary problem: the absence of network-layer observability signals that would allow a network security monitor to determine, from traffic analysis and protocol metadata alone, which cryptographic algorithms are in active use across live network sessions — regardless of what the software stack reports. Network-layer observability gaps persist even when CBOM is fully deployed, because:¶

CBOM reflects software composition at build/install time; network-layer signals reflect algorithm use at session time.¶
CBOM cannot detect algorithm downgrade attacks or negotiation outcomes that differ from the declared software capability.¶
CBOM requires agent deployment on endpoints; network-layer observability can be achieved passively via traffic analysis without endpoint agents.¶

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

PQC Readiness State:: The assessed condition of a network environment with respect to its preparedness to operate securely in the presence of a CRQC, determined by the current distribution of classical vs. PQC algorithm usage across active network sessions.¶
Network-Layer Readiness Signal:: A machine-readable signal extractable from network traffic or protocol metadata — without endpoint agent access — that contributes to determining the PQC Readiness State of a session, endpoint, or service.¶
Algorithm Negotiation Record:: A structured log record capturing the cryptographic algorithm negotiated in a specific protocol session (e.g., TLS cipher suite, SSH key exchange method, DNSSEC algorithm).¶
Readiness Gap:: An absence of a normative mechanism for generating, transmitting, or aggregating a Network-Layer Readiness Signal that would contribute to PQC Readiness State assessment.¶

3. Identified Readiness Gaps

3.1. Gap 1: No Structured Algorithm Negotiation Export from TLS

TLS 1.3 [RFC8446] negotiates cipher suites and key exchange groups via ClientHello/ServerHello. The negotiated algorithms are observable in the TLS handshake but:¶

No IETF-standard mechanism exports structured Algorithm Negotiation Records from TLS implementations to a network management system.¶
IPFIX/NetFlow record types do not include TLS cipher suite as a standard information element available in all major implementations.¶
Passive TLS inspection (where legally permissible) requires decryption or relies on handshake metadata only — which is increasingly encrypted in TLS 1.3 via ECH.¶

3.2. Gap 2: No DNSSEC Algorithm Inventory Export

DNSSEC [RFC4034] zone signing uses algorithm identifiers (RSA/SHA-256, ECDSA P-256/SHA-256, etc.) recorded in DNSKEY and RRSIG records. No standard mechanism aggregates DNSSEC algorithm usage across zones in a resolver's cache into a machine-readable inventory exportable to a network management system.¶

3.3. Gap 3: No Certificate Algorithm Inventory in OCSP/CRL Infrastructure

OCSP [RFC6960] responses and CRL [RFC5280] distributions carry certificate revocation status but do not carry structured information about the algorithm family of the certificate being checked. No IETF-standard mechanism aggregates certificate algorithm distribution across an OCSP/CRL infrastructure into a readiness inventory.¶

3.4. Gap 4: No PQC Readiness Signal in QUIC Transport

QUIC [RFC9000] uses TLS 1.3 for its cryptographic handshake. The same Gap 1 issues apply to QUIC sessions. Additionally, QUIC's encrypted header format further reduces the visibility of handshake metadata to passive monitors.¶

3.5. Gap 5: No Aggregated Readiness State Export Protocol

Even if individual gaps 1-4 were addressed by adding algorithm-negotiation export to each protocol, no IETF-standard aggregation protocol exists for collecting per-session Algorithm Negotiation Records across protocols, computing a PQC Readiness State for an environment, and exporting that state to a security operations platform in a structured, machine-readable format.¶

4. Requirements for Closing the Gaps

REQ-RG-1: A normative mechanism SHOULD be defined for TLS implementations to export structured Algorithm Negotiation Records to a local collector without requiring decryption of session content.¶

REQ-RG-2: DNSSEC resolvers SHOULD export per-zone algorithm usage records in a structured format to enable environment-wide DNSSEC algorithm inventory.¶

REQ-RG-3: OCSP and CRL infrastructure SHOULD record and export the algorithm family of certificates for which status is checked, enabling a CA to monitor the classical-vs-PQC distribution of its actively-checked certificate population.¶

REQ-RG-4: A structured PQC Readiness State data model SHOULD be defined that aggregates per-session Algorithm Negotiation Records into an environment-level readiness score or distribution, exportable via an IETF-standard protocol (e.g., YANG/NETCONF, IPFIX extension).¶

REQ-RG-5: The aggregated PQC Readiness State data model MUST be complementary to and interoperable with CBOM outputs, not duplicative of them. Implementers SHOULD combine CBOM software inventory with network-layer Algorithm Negotiation Records for complete readiness coverage.¶

8. Informative References

[RFC4034]: Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC6960]: Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[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/info/rfc8446>.
[RFC9000]: Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[SHOR1994]: Shor, P., "Algorithms for quantum computation: discrete logarithms and factoring", Proceedings of the 35th Annual Symposium on Foundations of Computer Science pp. 124-134, 1994.

Appendix A. Acknowledgements

The author thanks Mike Ounsworth (Entrust) for valuable feedback on draft structure and boilerplate compliance, and the IETF PQUIP, LAMPS, and OAuth working groups for their ongoing work on post-quantum cryptography standardization.¶

CygnetLib (https://github.com/sanctumsecopsmssp/CygnetLib) serves as the reference implementation for algorithms described in this document. JSON evidence files including the algorithm registry, CNSA 2.0 compliance matrix, IETF PQC interoperability status, and ACTV test vector results are available in the evidence/ directory of the CygnetLib repository.¶