]> Sanctum SecOps LLC

128 Dry Run Rd Pine City NY 14871 United States of America bvicente@sanctumsecops.com https://orcid.org/0009-0006-6395-5308

Security Post-Quantum Use In Protocols post-quantum PQC readiness observability crypto inventory algorithm agility CBOM 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. 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/. Source maintained at https://github.com/Sanc-Admin/pquip-pqc-readiness-gaps. Author ORCID iD: https://orcid.org/0009-0006-6395-5308. 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.

Introduction

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 ; and which have been or are actively being migrated to NIST-approved PQC algorithms (FIPS 204, FIPS 205). Current network protocols — TLS , QUIC , 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.

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:

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

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 .

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.

Identified Readiness Gaps

Gap 1: No Structured Algorithm Negotiation Export from TLS TLS 1.3 negotiates cipher suites and key exchange groups via ClientHello/ServerHello. The negotiated algorithms are observable in the TLS handshake but:

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

Gap 2: No DNSSEC Algorithm Inventory Export DNSSEC 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.

Gap 3: No Certificate Algorithm Inventory in OCSP/CRL Infrastructure OCSP responses and CRL 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.

Gap 4: No PQC Readiness Signal in QUIC Transport QUIC 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.

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.

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.

Implementation Status 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 . A listing here does not imply endorsement by the IETF, and this section is expected to be removed by the RFC Editor before publication.

Implementation:

CygnetSSL certification authority driver, Sanctum SecOps LLC.

Description:

Certificate issuance, revocation, chain and profile verification, CRL generation and publication, and OCSP status responses, built on OpenSSL 3 with the FIPS provider active.

Maturity:

Operated on a single administrator-managed estate. No interoperability testing against independent implementations has been performed.

Licensing:

Proprietary; source not publicly available.

Contact:

bvicente@sanctumsecops.com

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.

Security Considerations 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.

IANA Considerations 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.

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