| Internet-Draft | PQC Readiness Gaps | September 2026 |
| Vicente | Expires 17 March 2027 | [Page] |
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 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/.¶
This note is to be removed before publishing as an RFC.¶
Source maintained at https://github.com/Sanc-Admin/pquip-pqc-readiness-gaps. Author ORCID iD: https://orcid.org/0009-0006-6395-5308.¶
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 should 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.¶
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 17 March 2027.¶
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. 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.¶
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.¶
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:¶
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].¶
TLS 1.3 [RFC8446] negotiates cipher suites and key exchange groups via ClientHello/ServerHello. The negotiated algorithms are observable in the TLS handshake but:¶
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.¶
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.¶
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.¶
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.¶
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.¶
This section records the status of known implementations of the mechanisms described in this document at the time of posting, based on the proposal in [RFC7942]. A listing here does not imply endorsement by the IETF, and this section is expected to be removed by the RFC Editor before publication.¶
Observations recorded on 2026-09-12 on that implementation: the OpenSSL base, default and FIPS providers were active with the kernel FIPS indicator set; 22 end-entity certificates were issued and verified across two profiles; all certificates used ECDSA on P-384 with ecdsa-with-SHA384 signatures and carried non-sequential 20-octet serial numbers drawn from a CSPRNG; the certificate revocation list was published in DER form at the URI named in the CRL distribution points extension; and a newly issued certificate returned an OCSP status of "good" and, following revocation with reason cessationOfOperation, returned "revoked" with a matching revocation time.¶
Algorithm Negotiation Records may reveal information about the cryptographic capabilities of endpoints in a network. Aggregated readiness inventories MUST be protected as sensitive security metadata. Access to readiness state exports MUST be restricted to authorized security operations personnel. Exporters MUST NOT include session content or key material in Algorithm Negotiation Records.¶
This document has no IANA actions. Future documents closing the identified gaps may require IANA registrations for IPFIX information elements, YANG module names, or algorithm identifier registries.¶
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.¶
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.¶