Summary

  • 一份个人互联网草案的第 04 版新增一项实现状态记录：CygnetSSL 的 CA 驱动在一个由单一管理员管理的环境中运行，软件为专有实现，尚无独立互操作测试。
  • 记录中的 22 张终端实体证书、DER 格式 CRL 和一次 OCSP 状态变化均属于 CA 操作观测；它们没有验证草案所列的 TLS、DNSSEC、证书算法分布、QUIC 和跨协议汇总能力。
  • Daniel Kade 建议用“缺口闭合证据矩阵”逐项管理结论。该矩阵是本文的编辑性建议，不是 IETF 要求，也不否定这项实现本身的价值。

新增的是可审计线索，不是就绪度结论

第 04 版草案在 9 月 13 日增加了 Implementation Status 一节。第 03 版没有这一节，官方差异页也清楚显示了新增内容。按照 RFC 7942 的思路，公开实现状态可以帮助读者判断设计与运行代码之间的距离，但它不会把有限试验自动升级为规范成熟度或广泛部署证明。

程序状态同样必须写清。Datatracker 页面将文档列为活跃的个人互联网草案；元数据接口显示版本为 04、IESG 状态为 I-D Exists，且没有 IETF stream。页眉请求的是 Informational。因而，本文讨论的是作者提出的治理机制及其证据，不把草案表述成工作组共识、IESG 批准或 RFC。

一组 CA 观测回答不了五个网络问题

新增条目描述 CygnetSSL 的 CA 驱动：专有软件、一个管理员控制的环境、没有独立互操作测试。它报告了两个配置档案中的 22 张终端实体证书，签名均为 ECDSA P-384 / ECDSA-SHA384；还观察到 DER 格式的证书撤销列表，以及一条 OCSP 响应从 good 变为 revoked。

这些数据对验证 CA 的签发与撤销操作有用。但草案的 REQ-RG-1 至 REQ-RG-5 问的是另外五件事：每次 TLS 会话能否导出所协商算法；每个 DNSSEC 区域能否导出算法；证书算法能否在 OCSP 与 CRL 的证据中形成可统计分布；QUIC 能否提供同类信号；最后，各协议的结果能否汇总，并与密码材料清单（CBOM）互操作。RFC 8446、RFC 4034、RFC 5280、RFC 6960和 RFC 9000分别界定了这些协议对象所处的技术语境。

22 张经典算法证书不是后量子部署。它们也不是某个 TLS 会话、DNSSEC 区域或 QUIC 连接的导出记录。NIST 已将 ML-DSA 与 SLH-DSA 分别标准化为 FIPS 204 和 FIPS 205，但标准存在本身仍不能替代一处网络环境中的部署证据。这里要守住的不是术语，而是分母：观测了什么总体中的多少对象，又遗漏了哪些对象。

每项“已闭合”都应有自己的证据链

较稳妥的治理工具是一张逐项矩阵。每一行只对应一个缺口，并记录：要求、观测机制及版本、产物、稳定位置、环境与运营者、测试方法、总体与分母、结果、限制、日期、责任人、下次复核时间，以及能否由独立人员复现。若某个字段缺失，状态可以是“有实验”“部分覆盖”或“待复核”，而不是笼统的“就绪”。

草案给出的实现链接指向一个名为 CygnetLib 的 GitHub 地址。在本文截点，从生产主机访问该精确地址返回 HTTP 404。这只是一次有时间和路径边界的可用性观测：它不能证明仓库从未存在，也不能推断作者意图，更不能判定软件无效。它说明的治理问题很具体——如果外部读者无法取得被引用的产物，独立复现这一列就不能标记为完成。

这种证据矩阵延续了《The Policy Mirror》对可核验制度镜像的要求，也符合《Minimum Initial Specification》从最小可执行规格开始的路径。《Why BTW Media Exists》强调把可见事实与主张分开；在这里，这意味着同时保留两句话：实现记录很有价值，五项缺口仍未被它闭合。

Sources

  1. PQC 就绪度缺口草案第 04 版
  2. PQC 就绪度缺口草案第 03 版
  3. 官方 03–04 差异
  4. Datatracker 文档页
  5. Datatracker 元数据接口
  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 链接
  15. The Policy Mirror
  16. Minimum Initial Specification
  17. Why BTW Media Exists