Summary

  • Revision 04 of an individual PQC-readiness Internet-Draft adds one implementation-status entry: a proprietary CA driver used in one administrator-managed estate, with no independent interoperability test.
  • The entry records 22 classical ECDSA certificates, CRL publication and one OCSP status transition. None of those observations demonstrates the TLS, DNSSEC, certificate-distribution, aggregation or CBOM-interoperability exports named by the draft's five requirements.
  • Daniel Kade proposes a gap-closure evidence matrix that keeps a running-code disclosure valuable without turning it into an environment-wide readiness claim. This is editorial guidance, not an IETF requirement.

A new section changes what readers can infer

The 13 September revision of PQC Readiness Observability Gaps in Networked Computing Environments adds an Implementation Status section. The previous revision had none; the official comparison shows the section as the principal substantive addition.

The process state matters. The Datatracker record calls this an active individual Internet-Draft. The metadata record identifies revision 04, records I-D Exists, and shows no IETF stream. The header asks for Informational status. None of those facts makes the proposal a working-group position, an IESG approval or an RFC.

The new entry names the CygnetSSL certification-authority driver from Sanctum SecOps. It describes issuance, revocation, chain and profile verification, CRL generation and publication, and OCSP status responses. Its declared environment is narrow: one administrator-managed estate. Its licensing is proprietary, source is not publicly available, and no interoperability test against an independent implementation has been performed.

That disclosure is useful. It tells a reviewer who operated what, under which broad conditions, and where the limits begin. It also provides unusually specific observations dated 12 September: 22 end-entity certificates were issued and verified across two profiles; all used ECDSA on P-384 with ECDSA-SHA384 signatures; a DER CRL was published; and one newly issued certificate moved from OCSP good to revoked after revocation.

Those facts show a CA workflow operating inside a bounded estate. They do not show post-quantum algorithms in use. Use of an OpenSSL FIPS provider is not, by itself, evidence of PQC readiness. The draft correctly points to FIPS 204 and FIPS 205 as standardized post-quantum signature references, but the recorded certificates are classical ECDSA.

The requirements ask five different questions

The draft's first gap is the absence of a standard, structured export of the algorithms actually negotiated in TLS 1.3 sessions. Its second asks how resolvers could export per-zone algorithm use observed through DNSSEC records. Its third asks for an aggregate certificate-algorithm distribution across the X.509 and CRL and OCSP surfaces. The fourth carries the TLS problem into QUIC. The fifth asks for a standard cross-protocol readiness state that can interoperate with cryptography bills of materials.

A working CA driver is adjacent to the third question, but adjacency is not closure. The new entry does not say that it exports the algorithm family for the population of certificates checked across an OCSP/CRL infrastructure. It reports 22 issuance observations in two profiles. It gives no population denominator, export schema, consumer, aggregation interval or independent reproduction. It does not claim to implement REQ-RG-3, and readers should not silently promote it into such a claim.

The other four gaps are even further away. There is no recorded TLS per-session export, DNSSEC resolver inventory, QUIC signal, environment-level aggregation or CBOM interoperability test. This does not mean the implementation failed. It means the evidence object and the requirements answer different questions.

RFC 7942 makes that boundary explicit

The entry cites RFC 7942, which gives Internet-Drafts a disciplined place to disclose running code. It recommends recording maturity, implemented coverage, compatible draft versions, licensing, implementation experience, contact, update date and any interoperability reports. It also warns that contributor-supplied information is not independently verified merely because it appears in a draft, and that listing does not imply IETF endorsement.

That is why an implementation-status section is removed before RFC publication: it is time-dependent evidence for deliberation, not a permanent conformance register. The draft repeats the no-endorsement and removal boundaries. Its maturity and licensing disclosures are clear. The missing join is a row-by-row statement of which, if any, of REQ-RG-1 through REQ-RG-5 the implementation is intended to exercise.

Availability is part of that join. The appendix says the CygnetLib repository contains JSON evidence. At the research cutoff, that exact link returned HTTP 404 from the production host. A 404 is a dated observation, not proof that the repository never existed or will not return. It does mean a reader could not inspect the cited evidence at that moment.

Give each closure claim its own row

Daniel Kade proposes a gap-closure evidence matrix. One row should name the gap and requirement, the mechanism implemented, the implementation and draft version, the stable evidence artifact, the operator and environment, the test method, the observed population and denominator, the result, limitations, evidence date, owner and next review. An independent reproducer belongs in the row when one exists; its absence should remain visible when none has tested the implementation.

The matrix would not downgrade running code. It would stop a valuable implementation disclosure from being asked to prove a different system. “A CA issued and revoked 22 classical certificates in one estate” can stand as a precise observation. “REQ-RG-3 is closed” would require evidence about the proposed export and its coverage. “This environment is PQC-ready” would require the remaining protocol and aggregation rows as well.

Heng Lu's Policy Mirror is useful here because the interface between evidence and authority is itself a governance surface. The Minimum Initial Specification argues for a small common record that preserves local choice without hiding who can change it. Why BTW Media Exists supplies the reporting discipline: one new implementation entry is real news, but its limits are also part of the news.

Sources

  1. PQC Readiness Gaps, revision 04
  2. PQC Readiness Gaps, revision 03
  3. Official 03–04 diff
  4. Datatracker record
  5. Datatracker metadata API
  6. RFC 7942
  7. RFC 8446
  8. RFC 4034
  9. RFC 5280
  10. RFC 6960
  11. RFC 9000
  12. NIST FIPS 204
  13. NIST FIPS 205
  14. CygnetLib link cited by the draft
  15. The Policy Mirror
  16. Minimum Initial Specification
  17. Why BTW Media Exists