Post-Quantum Use In Protocols B. Vicente, Ed. Internet-Draft Sanctum SecOps LLC Intended status: Informational 13 September 2026 Expires: 17 March 2027 PQC Readiness Observability Gaps in Networked Computing Environments draft-vicente-pquip-pqc-readiness-gaps-05 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. Supplementary Materials This note is to be removed before publishing as an RFC. Reference implementation: CygnetLib (https://github.com/sanctumsecopsmssp/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/ (https://www.sanctumsecops.com/). Source and Archival This note is to be removed before publishing as an RFC. Source maintained at https://github.com/Sanc-Admin/pquip-pqc- readiness-gaps (https://github.com/Sanc-Admin/pquip-pqc-readiness- gaps). Author ORCID iD: https://orcid.org/0009-0006-6395-5308 (https://orcid.org/0009-0006-6395-5308). IPR Considerations This note is to be removed before publishing as an RFC. Vicente Expires 17 March 2027 [Page 1] Internet-Draft PQC Readiness Gaps September 2026 Certain technology described in this document is covered or may be covered by pending United States patent applications owned by Sanctum SecOps LLC, including U.S. Application Nos. 64/080,137 and 19/698,870. Brian Vicente is the inventor. Patent pending. Sanctum SecOps LLC is prepared to grant to all implementers, under a separate written agreement, a non-exclusive, worldwide license on reasonable and non-discriminatory terms that may include reasonable fees or royalties, under Necessary Patent Claims owned or controlled by Sanctum SecOps LLC. "Necessary Patent Claims" means claims subject to the applicable IETF disclosure that would necessarily be infringed by implementing technology required by this specification and for which no technically and commercially feasible non-infringing alternative is available. The license applies only to the compliant portion of a product or service implementing required technology. It does not extend to optional features, proprietary enhancements, noncompliant implementations, methods not required by the specification, unrelated Sanctum SecOps LLC products, hosted control planes, managed services, trade secrets or claims that are not Necessary Patent Claims. Licensing may be conditioned on reciprocal licensing on reasonable and non-discriminatory terms for necessary claims owned or controlled by the licensee. Sanctum SecOps LLC reserves defensive suspension and available remedies if the licensee or an affiliate asserts patents against Sanctum SecOps LLC, its affiliates, licensees, customers, compliant products or compliant services, except for a defensive claim compelled by a prior assertion. Nothing in this document admits or warrants issuance, validity, enforceability, infringement, essentiality, claim scope, absence of alternatives or freedom to operate. No patent license arises merely from publication of this specification. The controlling IETF Datatracker IPR disclosures remain authoritative. 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/. Vicente Expires 17 March 2027 [Page 2] Internet-Draft PQC Readiness Gaps September 2026 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Differentiation from CBOM and Software Inventory Approaches . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Identified Readiness Gaps . . . . . . . . . . . . . . . . . . 5 3.1. Gap 1: No Structured Algorithm Negotiation Export from TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Gap 2: No DNSSEC Algorithm Inventory Export . . . . . . . 6 3.3. Gap 3: No Certificate Algorithm Inventory in OCSP/CRL Infrastructure . . . . . . . . . . . . . . . . . . . . . 6 3.4. Gap 4: No PQC Readiness Signal in QUIC Transport . . . . 6 3.5. Gap 5: No Aggregated Readiness State Export Protocol . . 6 4. Requirements for Closing the Gaps . . . . . . . . . . . . . . 6 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Vicente Expires 17 March 2027 [Page 3] Internet-Draft PQC Readiness Gaps September 2026 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: 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. Vicente Expires 17 March 2027 [Page 4] Internet-Draft PQC Readiness Gaps September 2026 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: 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. Vicente Expires 17 March 2027 [Page 5] Internet-Draft PQC Readiness Gaps September 2026 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. Vicente Expires 17 March 2027 [Page 6] Internet-Draft PQC Readiness Gaps September 2026 *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. 5. 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 [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. 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. Vicente Expires 17 March 2027 [Page 7] Internet-Draft PQC Readiness Gaps September 2026 6. 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. 7. 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. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9. 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, . [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, . [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, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Vicente Expires 17 March 2027 [Page 8] Internet-Draft PQC Readiness Gaps September 2026 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [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. [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . 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 (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. Changelog 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. Author's Address Brian Vicente (editor) Sanctum SecOps LLC 128 Dry Run Rd Pine City, NY 14871 United States of America Email: bvicente@sanctumsecops.com Vicente Expires 17 March 2027 [Page 9] Internet-Draft PQC Readiness Gaps September 2026 URI: https://orcid.org/0009-0006-6395-5308 Vicente Expires 17 March 2027 [Page 10]