摘要

  • RFC 9925 于2026年2月作为 IETF 提议标准发布，定义了 id-alg-unsigned：参数必须省略、签名值长度为零的 X.509 签名算法标识。
  • 这种格式承载主体信息，却不提供签发者证明。签发者字段可以为兼容而填写，但对象仍然既非自签名，也非自签发。
  • 不需要验证 X.509 签名的应用可以在限定场景接收它；任何证书路径验证器都必须拒绝用 id-alg-unsigned 代替真实签名。
  • 去掉装饰性的自签名，可以减少后量子签名体积、避免跨协议复用密钥，也能容纳只能做密钥封装的公钥。它不是安全绕过，而是把缺失的信任边明确标出。
  • 因此，信任、完整性和授权必须由另一套机制提供。每次安装都应生成一份“信任来源与范围凭据”，记录精确字节、外部证据、安装者、目标信任库、允许用途、变更历史和移除路径。

一个故意把证明栏留空的证书

RFC 9925 最有力量的数值是零。

无签名证书使用对象标识符 1.3.6.1.5.5.7.6.36 表示 id-alg-unsigned。算法参数不出现，signatureValue 是零位长的 BIT STRING。主体名称、公钥和扩展仍被装在广泛兼容的 X.509 结构里，但解析器不再被要求假装某个签发者对这些字段作过密码学背书。

这和“忘记验签”完全不同。规范为缺失本身命名，并规定了处理分支：不执行证书签名验证的接收方可以接受该算法；需要验签的接收方必须拒绝；证书路径验证不得让空值占据签发者签名的位置。对象在语法上可以有用，在信任图上却不能充当边。

治理问题由此变得可见。安全界面很容易从熟悉的形状借来权威感。名为“证书”的文件可能显示签发者、有效期和绿色图标；资产清单可能把它与 CA 签发的凭据并列；运维人员记得它来自一个可信镜像，却找不到当初是谁批准了镜像。RFC 9925 没有要求产品制造这些错觉。相反，它精确地说明了空白，产品和组织因而更有责任精确地说明信任来自哪里。

节点仍在，边已经消失

RFC 9925 给出了一个清楚的图模型。普通 X.509 证书把两个实体联系起来：一端是主体信息，另一端是签发者给出的证明。在公钥基础设施图中，两者是节点，证书签名构成它们之间的边。

有些场景只需要节点。信任锚是验证路径的起点，并不需要再从上级证书获得权威；固定 TLS 部署可以通过独立的配置通道认定某个公钥或指纹；设备也可能需要用 X.509 容器装载无法签名的 KEM 公钥。为这些用途制造一个自签名，往往只是满足语法，并没有创造新的信任事实。

无签名格式删掉了虚构的边。这提高了表达的真实性，却也迫使组织回答一个曾被自签名包装遮住的问题：为什么这个节点在这里具有权威？

RFC 5280 早已揭示了答案的一部分。即使信任锚以自签名证书表示，该证书本身也不属于待验证路径；进入路径处理的是受信任的名称、算法、公钥和约束。它们之所以可信，是因为某个可信的带外程序交付了这些输入。选择哪些认证机构属于本地决定，而且可能因应用和验证路径而异。

所以，自签名从来不是终极信任来源。它最多证明相应私钥曾对同一对象签过名，也可能被部分软件用来发现存储损坏；它不能证明管理员应该安装这把钥匙、主体名称一定正确，更不能证明所有应用都应接受它。RFC 9925 把这层含混剥开：节点看得见，缺失的边也看得见，外部决定必须拿出自己的证据。

被填写的签发者仍可能只是占位符

最容易误导人的并不是空签名，而是非空的签发者名称。

X.509 语法要求签发者字段存在，不能留空；既有软件也可能假定信任锚的主体和签发者名称相同。因此，RFC 9925 允许发送方把主体名称复制到签发者字段，另提供一个专用的简短占位名称。但两种选择都不会产生签发者。没有签名，就不是自签名；没有签发关系，就不是自签发。

这正是 Lu Heng 在《The Policy Mirror》中要求避免的制度错读：记录应呈现真实存在的权力和事件，而不是让旧语法暗示出一段不存在的关系。如果软件仍把占位符显示为“签发者”，它就把必填槽位变成了机构声明；如果路径图画出主体指向自己的环，它就重新制造了标准有意删除的边。

扩展字段也应遵守同样纪律。authority key identifier 与 issuer alternative name 都在描述签发者，通常不应出现；key usage 和 basic constraints 可以描述主体具备何种能力，却不能替代安装授权。一个主体即使被标为可充当 CA，也只是拥有技术能力；是否把它放入某个信任库，仍由外部权力决定。

被登记不等于被验证

IANA 已登记 id-alg-unsigned。登记的作用，是让不同系统识别该值并找到规范；它不会让空签名变得有效，不会认证主体，也不会批准一次信任库变更。

这一点尤其重要，因为注册表经常被误读为认可名单。这里的登记恰恰帮助软件精确识别“这不是签名”，并在验签场景中执行拒绝。没有专门支持的传统验证器看到无法验证的算法，安全默认应当是失败关闭；只有原本就打算在外部认证条件下消费主体信息的有限功能，才需要显式处理。

RFC 9925 也点明了危险路径：若应用在证书路径中接受该标识，或在任何必须验证 X.509 签名的地方放行它，验签就被绕过。RFC 8725 对另一类令牌系统提出了相同的基础纪律——调用者必须能够限定可接受算法，声明的算法也必须与实际执行的操作绑定。注册表能定义状态，不能替每个产品证明状态转换正确；那份证明只能来自测试、配置和运行证据。

为什么删去签名反而可能更安全

“无签名证书”听上去像削弱安全。在 RFC 9925 的目标场景里，结论可能正好相反。

许多信任锚表示中的自签名根本不会被检查，只因 X.509 留有签名槽、软件又期待证书形状而存在。后量子算法会让这种不用的签名占据大量字节。若主体本是终端实体，生成自签名还会让同一把钥匙同时服务于 X.509 和实际业务协议，扩大跨协议攻击面。若公钥只支持密钥封装，它甚至没有能力签出这个占位物。

把未被依赖的密码学动作换成一个有名称的空值，可以减少安全表演。实现者被明确告知不能从该字段推导信任，路径验证器也有清楚的失败条件，密钥则不必承担设计之外的用途。这是对声明范围的收缩，而不是让验证任意消失。

但这套辩护只有在真实信任机制可查时成立。“带外”只是边界说明，并不是解释。它可能指当面核对指纹、签名固件、受保护配置仓库、企业设备管理事务、制造流程，或管理员手动选择。这些路径的负责人、适用范围和恢复能力并不相同，不能用一个模糊标签代替。

信任权移到了安装者手中

RFC 6024 为这层外部治理提供了一套实用词汇。信任锚以公钥和约束表示一个权威实体；信任锚管理者控制一个或多个信任库；信任库可以只服务某个应用、某台设备或多个共享服务；认可范围还可限定到部分用户或用途。管理操作不只是“导入”，还包括新增、删除、替换，以及验证提供变更者的身份和授权。

这揭示了权力转移：当文件不再包含签发者证明，执行安装的人或系统就不只是在搬运数据，而是在作出实际生效的信任决定。

安装链至少要回答四个问题：这是否是获批的精确字节？提供方是否有权提出这个锚？执行者是否有权修改目标信任库？这把钥匙可以为哪些应用、名称、政策和时间段建立信任？空签名不能回答任何一个问题。

哈希能证明字节一致，却不能解释用途范围；安全通道能认证来源，却不能证明来源有权绑定某项应用；管理员权限能完成写入，却不自动等于政策授权；路径验证成功能说明新增锚让一条路径通过，却不能证明允许它通过的决定合法。因此，外部信任需要一份记录，而不只是一套传输机制。

信任来源与范围凭据

一份可用的凭据应从对象本身开始，而不是从文件名开始。它记录精确文件摘要、无签名算法标识、主体公钥和关键角色字段，并明确声明：该对象不提供签发者签名，不能满足证书路径中的任何签名步骤。

第二部分记录来源：对象取自哪个仓库、设备镜像、软件包、仪式或管理员？是哪一个外部哈希、签名、保护通道或现场比对保证完整性？什么证据认证了提供方，什么规则证明该提供方有权提供信任信息？

第三部分记录决定：谁以什么职权批准安装，何时决定，写入哪个信任库，影响哪些应用或设备群？允许的命名空间、政策、用途和期限应被逐项列出，而不是让一个共享库中的“存在”变成普遍权威。

最后是生命周期：哪条记录替代本记录，什么事件触发更换或删除，谁负责下次复审，误装如何纠正，管理者或密钥失陷后如何恢复？公开或跨团队视图可以保持克制，不必暴露根库内容、管理员凭据或敏感分发路径，只需展示对象摘要、决策权威、限定范围、当前状态、变更沿革和纠错联系人。

凭据不会把对象变成有签名证书，也不会为本地信任创造一个全球中心。它只是防止一个已经存在的决定藏进熟悉的文件扩展名后面，最后无人负责。

证据边界

现有来源不能证明 RFC 9925 已被广泛部署，不能列出哪些产品支持它，也不能证明某个实现已经错误处理。LAMPS 工作组章程表明后量子 PKIX 和 S/MIME 机制仍在推进，但章程不是部署遥测；IANA 条目证明分配，不证明处理正确。

本文也没有断言所有自签名都毫无用途。RFC 9925 承认，部分应用用自签名检测意外存储损坏；采用无签名格式后，这类用途就需要另一套完整性机制。本文同样没有说每个无签名证书都是信任锚；它也可以在其他已受外部认证的场景中承载独立主体信息。

能够确证的结论更窄，但已足够重要：RFC 9925 有意把主体数据与签发者证明分离，要求路径验证器拒绝空签名，并把完整性与信任放到对象之外。这是一条合理而清晰的技术边界。治理也应让外部那一半同样可检查。

来源

  1. Lu Heng，《The Policy Mirror》
  2. RFC 9925，《Unsigned X.509 Certificates》
  3. RFC 5280，《Internet X.509 Public Key Infrastructure Certificate and CRL Profile》
  4. RFC 4158，《Internet X.509 Public Key Infrastructure: Certification Path Building》
  5. RFC 5914，《Trust Anchor Format》
  6. RFC 6024，《Trust Anchor Management Requirements》
  7. RFC 8446，《The Transport Layer Security (TLS) Protocol Version 1.3》
  8. RFC 8725，《JSON Web Token Best Current Practices》
  9. IANA，《Structure of Management Information (SMI) Numbers》
  10. IETF，LAMPS 工作组章程