摘要

  • COSE 工作组于 2026 年 9 月 24 日提交 C509 草案第 21 版。IESG 在 7 月批准的是第 20 版；文件仍在 RFC 编辑队列，尚未成为正式 RFC。
  • 新版把证书数组、待签名序列、序列号的字节串编码，以及颁发者与主体完全同字节时才可使用的 null 缩写说得更明确。
  • 可逆转换的第 3 类证书保留原 DER 签名；原生第 2 类则签署 CBOR。二者都不能绕过 X.509 证书路径验证，也不能假定老式 DER 验证器兼容原生类型。

把证书送上带宽紧张的链路，先想到的通常是大小。可是缩小一份凭证，并不像缩小照片：压缩器、签发者、验证器如果对“被签名的内容”有不同理解，即使字段名称都对得上，也不能凭肉眼认定同一条签名仍被正确验证。C509 要处理的恰是这种格式交接，而不是代替任何机构决定信任谁。

草案设定两种路线。第 3 类从已经签署的 DER 编码 X.509 证书出发，生成可逆的 CBOR 表示，并带着原来的签名。验证时可以重建 DER，检查原签名。第 2 类则直接对 CBOR 表示签名，因而在某些封闭的设备生态里可以避免 ASN.1／DER 解析；代价是只懂 DER 的现有验证器不能被默认为兼容。两种类型的证书语义相同，并不意味着软件能力相同。

9 月 24 日版本的增量不是又宣布一种信任体系。它明确整个 C509 证书是 CBOR 数组，其元素构成序列；TBSCertificate 组除去末尾的签名值后，是原生证书的待签名序列。更细处，即使序列号很小，编码时也要使用 CBOR 字节串，不直接换成普通无符号整数。第 3 类还规定：重建 X.509 时若首字节最高位为 1，要补回 DER 所需的前导零。颁发者字段只有在与主体逐字节完全一致时才能压成 null；显示名称相像不足以满足条件。

这些规则适合拿来设计测试向量，却不证明此前有产品出错，更不能据此编造攻击事件。IESG 于 7 月 20 日批准第 20 版，文档随后进入 RFC 编辑队列。第 21 版是该队列中的新草案；截至本次核查，Datatracker 仍显示编辑环节等待作者输入、IANA 行动等待作者，正式 RFC 尚未发布。草案列出的大小比较是示例，不是各行业采用率调查。

真正需要分开的还有两种“通过”：解析器能读入较短证书，和验证器认定签名、证书链及信任锚有效。草案的安全章节要求沿用 RFC 5280 路径验证，把 COSE 头里的证书材料先视为未可信输入；登记了算法编号也不等于推荐使用该算法。运营方若要试用 C509，可以自行保留类型、转换器版本、准确待签名字节、DER 重建结果及各类验证器响应。那是本文提出的验收记录，不是 IETF 新设表格。

来源