摘要

  • 第 21 版草案定义两类 C509：一类可逆还原为原始 DER 后验签，另一类直接对 CBOR 签名。
  • 能解析、能验签不等于可信；RFC 5280 路径验证仍是必需步骤，COSE 携带的证书材料仍是不可信输入。
  • IANA 代码点回答“这个数字代表什么”，不回答“这个算法是否应被启用”。

两种紧凑证书，两份不同的验签收据

第 3 类 C509 是 DER X.509 证书的可逆 CBOR 重编码。接收方恢复原始 DER 对象，再用旧有软件验证原签名。第 2 类是原生 C509，签名直接覆盖 CBOR TBSCertificate。二者可表达相同的 X.509 语义，却不能只用一个“C509 解析成功”状态概括：前者应保存还原后参与验签的 DER 字节，后者应保存规范化的 CBOR 签名字节。

节省来自对证书结构的理解：静态和重复字段被省略，许多 OID 变为短整数，时间值和部分椭圆曲线点得到紧凑表示。这是编码和传输层成果，不证明私钥今天由谁控制、签发者是否有权处理该用途、证书是否仍在时效内，更不代表应用应当执行某项操作。

草案明确保留 X.509 的安全假设。证书被视为可信之前，仍必须运行 RFC 5280 第 6 节的路径验证，检查信任锚、签发约束、时间、名称、策略、关键扩展与用途。验签只回答完整性问题，不能独自完成信任判断。

被封装的自签名证书不能任命自己

COSE 的 c5b、c5c、c5t、c5u 参数可携带证书或引用，但内容仍是不可信输入。收到一张自签名证书，不得自动把它加入信任锚。即使参数位于受保护的 COSE 头中，也只是外层消息得到认证；内层对象没有因此获得修改根信任的权力。

C509 还增加媒体类型、CoAP 内容格式、TLS 证书类型和 TLSA 选择器。这些登记让新表示可被识别和协商，并不取代 DNSSEC 与 DANE 使用规则、服务身份核对或应用授权。

草案专门提醒：IANA 登记不等于算法推荐。有些已弃用算法保留代码点，只为无损表达既有证书。当前 TLS Certificate Types 表把 C509 Certificate 列为数值 4，Recommended = N。这个 N 不是“有缺陷”的判决，但也不是普遍启用许可。命名、标准进展、推荐信号和本地准入是四层不同事实。

尺寸表不能替代生产测量

草案样例中，C509 对部分经过 RFC 7925 剪裁的物联网证书压缩明显；Brotli 还能利用整条链中的重复信息。FN-DSA 与 ML-DSA 链由体积很大的公钥和签名主导，这些近似随机的字节很难再压缩，因此收益有限。样例不能证明某个真实网络节能、降时延或提高成功率。

为兼容旧系统，边界网关可以把 C509 转回 X.509，让受限链路传小对象、旧服务继续收 DER。但草案指出，这一方案要求证书未加密，可能破坏身份保护。对端到端加密证书的协议，转换能力必须进入端点。转换保真、解析安全和信任决策仍要分别取证。

第 21 版发布于 2026 年 9 月 24 日，已经 IESG 批准并进入 RFC Editor 队列，目前因等待作者输入而阻塞。这是出版流程状态，不是技术否决，也不是 RFC 编号、部署证明或互操作报告。

来源