摘要

  • draft-birkholz-did-x509-03 要求解析器按“叶证书在前、锚点在后”的顺序验证提交的证书链，以最后一张证书作为本次路径算法的信任锚，再核对非叶证书指纹和叶证书谓词。
  • 算法采用的锚点不会因此自动成为依赖方信任库中的锚点。本地信任库、DID 或 CA 指纹允许列表以及具体用途政策必须单独作出接受决定。
  • 解析、依赖方信任、消息签名验证、用途授权、持久提交和外部结果需要独立凭据。03 版是独立提交的 Informational Internet-Draft，不是 RFC 或 IETF 标准。

一套解析系统收到一个 DID 和一串证书。它从第一张叶证书一路检查到最后一张证书，所有签名都成立；DID 里的指纹命中中间 CA，主题和 SAN 条件也与叶证书吻合。系统由叶证书公钥生成 DID 文档，返回成功。

此时最重要的事实不是它完成了多少检查，而是它尚未回答什么：最后那张证书是谁决定信任的？

did:x509 03 版把这个边界写得相当清楚。该方法不依赖持久化的 DID 文档注册表；标识符本身描述一类证书，解析时另行提供证书链。这样可以确定性地得到验证材料，也很容易在接口层把“材料内部自洽”压缩成“身份可信”。两者并不是同一件事。

DID 描述的是证书集合

核心格式以 did:x509:0 开头，随后是指纹算法、指纹和至少一个谓词。可用算法包括 SHA-256、SHA-384 和 SHA-512。指纹针对链中某张非叶证书，可能是中间 CA，也可能是最后的锚点证书。谓词则约束叶证书。

subject 检查所列主题名称属性是否构成叶证书主题的子集；san 匹配一个电子邮件、DNS 名称或 URI；eku 匹配扩展密钥用途 OID；fulcio-issuer 在补回 https:// 后匹配 Fulcio 发行者扩展，并要求该扩展存在且不是 critical。

这种表达方式没有把 DID 锁死在一张叶证书上。证书轮换之后，只要新的链仍经过同一类非叶证书且满足全部谓词，同一个 DID 仍可解析。稳定性来自“描述一类合格证书”，而不是固定一把钥匙。

集合越宽，治理问题越大。只写一个宽泛的 subject 子集，可能让远超预期的叶证书都符合条件。出现某个 EKU 只能说明证书声明了一类密钥用途，不能证明持证者获准上线软件、登记制品或转移资产。谓词完成的是选择，不是授权。

链尾证书只在本次算法里充当锚点

解析选项 x509chain 包含逗号分隔的完整 DER 证书，使用 base64url 编码，叶证书在前，根或锚点在后；少于两张必须拒绝。解析器依照 RFC 5280执行证书路径验证，处理签名、名称和基本约束、证书政策、密钥用途、critical 扩展、算法以及验证时间。之后再逐项检查 CA 指纹与叶证书谓词，最后从叶公钥推导 JWK 和 DID 文档。

在路径算法的术语中，最后一张证书确实是 trust anchor。但它是调用者随链提供给这次运算的输入，并不因此进入接收机构长期维护的信任库。若把两者混成一个状态，提交证据的一方就顺手选定了审判证据的权威。

RFC 9360对 COSE 携带证书链提出了相邻且关键的纪律：收到的证书材料不得悄悄修改应用配置的信任锚。链可以帮助验证自己的结构，不能任命自己的主权。

凭据阶段 能证明什么 仍然不能证明什么
DID 语法解析 版本、指纹算法和谓词编码合法 真实证书链是否满足它
提交链路径验证 叶证书在给定参数下连到最后一张证书 本地是否信任这张终点证书
指纹与谓词匹配 该链属于 DID 描述的证书集合 集合对目标动作是否足够严格
本地信任判断 本依赖方在某一场景接受该 CA 或 DID 具体消息的签名是否通过
消息签名验证 覆盖的字节由解析出的钥匙验证成功 签名者是否有权执行请求
用途授权与提交 特定主体可对特定资源执行特定动作 外部世界是否出现宣称的结果

把整张表压成 resolved=true，只会把未知变成未经说明的肯定。

直接读取标识符会制造自报身份通道

DID 里的主题、域名或电子邮件片段人眼可读，开发者很容易绕过解析，直接提取这些文字作为角色或组织名。03 版明确要求不要在经过验证的链上完成解析之前，用标识符组件做授权。

任何人都能拼出语法正确、包含知名机构名称的字符串。没有证书链，字符串里的属性没有发行者背书；有了自洽的链，也还需要本地接受该发行者。若应用直接相信可见文本，就把公共语法改造成了未签名的身份声明接口。

正确顺序应当留下每一步的记录：原始 DID 字节、完整证书链、路径结果、指纹和谓词结果、本地信任政策、实际签名覆盖范围、用途授权、提交记录和外部观测。中间任何一步没有完成，都不能借下一步的绿色图标补齐。

时间与吊销不是附注

证书路径验证必须选择时间。草案允许用当前时间，也允许用与上下文相关的时间，例如制品签名时刻。同一条链在不同时间可能产生不同结论。JWT 或 CWT 里的 iat 即使存在，也不会自动成为可信时钟；RFC 7519与 RFC 8392定义了字段，但完整性和采用政策仍须另证。

吊销检查是“应用需要时”执行，可使用 CRL、OCSP或其他机制。应用还可以要求证书透明度、背书证据或禁用不安全算法。因此“路径有效”必须绑定验证时间、吊销要求、所用响应和算法政策，才是可复现结论。

RFC 9597与 RFC 9943所涉及的透明度和登记凭据也说明同一道理：携带一个证明对象，不等于同时携带了接受该对象的制度。

没有 DID 注册表，不等于没有控制者

did:x509 没有 DID 文档更新操作，也没有更新授权；它同样没有停用操作或停用授权。创建是本地行为，解析依靠 DID 与提交的链。

如果所有符合条件的叶证书过期或被吊销，DID 可能暂时无法解析，看起来像已停用。但这不是技术上不可逆的停用：有能力的 CA 可以再签发一张满足谓词的新证书。真正掌握身份延续权的，是 CA 控制者、谓词宽度和各依赖方的信任政策。

同一个 DID 可能对应多条链，也可能在不同链下得到不同叶公钥。只记录稳定 DID 会丢失当时实际验证消息的钥匙。证据包必须保存解析所用的具体链和生成的 verification method。

实现列表不能替代互操作证据

03 版称该方法已由 Microsoft 实现，也列出 Nuts Foundation 以及签名、SCITT、CCF 和机密容器等使用场景。Microsoft README、仓库规范和测试向量提供了可以运行和比较的材料。

草案同时指出 Nuts 实现在 eku 覆盖和 otherName SAN 扩展上与 03 版存在可见差异。这恰恰是重要证据：它指出两套程序可能把不同证书判入同一 DID 集合。实现状态由贡献者提供，不构成 IETF 背书，也不是完整功能清单。

02 版曾把预期状态写为 Standards Track；03 版改为 Informational，并大幅增加信任模型、方法操作、解析、隐私和实现状态章节。Datatracker 页面、历史记录和 I-D 公告共同限定了它的地位：独立提交、正在演进、不是 RFC，也不是 IETF 产品。

W3C DID Core解释 DID 文档和 verification relationship，DID 规范注册表登记方法与属性命名空间；二者不改变这份具体草案的共识级别。

应当保存的决策账本

每次判断都应保存：原始 DID、方法版本和 percent-decoding 后的谓词字节；按原顺序排列的全部 DER 证书；证据包哈希；路径构建与验证结果；验证时间；名称、政策、约束、密钥用途、critical 扩展和算法决定；吊销及透明度状态；命中的非叶证书指纹；每个谓词的结果；本地信任库或允许列表规则及版本；生成的 DID 文档和叶 JWK；实际签名对象与覆盖字节；签名结果；主体、资源、动作和有效期明确的用途授权；持久提交标识；以及可外部观测的结果。

没有检查就写没有检查。未要求吊销查询应记为 not_required_by_policy，而不是 good；没有评估本地锚点应记为 not_evaluated，而不是 trusted。

Lu Heng 的最小初始规范要求共享层只承担必要且可验证的机制，把未来决定留给本地。运行代码优先要求用实现结果和效果轨迹检验规范。政策之镜让信任库背后的授权者现形。现实分层则防止字符串、证书、政策、签名、授权与结果被一个成功状态吞并。

来源