摘要

  • FCI.DelegatedCredentials 公布下游 CDN 能接收的凭据上限及可选加密公钥，MI.DelegatedCredentials 交付凭据与可选私钥；两者都不是逐节点安装回执。
  • RFC 所说的“支持数量”并不必然等于服务器数量，同一凭据可以部署到多个端点，私钥也可能由下游本地生成，因此交接成功无法推出全网状态一致。
  • 可审计的证据链必须分别保存证书授权、凭据有效期、私钥来源、元数据版本、节点安装、路由选择、客户端能力、握手算法、备用路径与内容结果。

最危险的节点，往往只占流量的千分之一

设想一次看似顺利的轮换。上游 CDN 在旧凭据到期前两小时发布新对象，下游控制面顺利拉取，绝大多数边缘节点在几分钟内完成更新。监控显示成功率 99.9%。剩下的一个节点仍被一个小区域的路由选择，而且它的 TLS 进程从未加载新私钥。

平均值很好，客户却仍可能在到期时遇到拒绝，或者悄悄走回普通证书路径。这个例子说明为何“对象已交付”和“服务已切换”必须由不同收据证明。RFC 9677 没有承诺前者能够代表后者；把两者合并，是运营系统自行扩大了协议语义。

委派凭据的价值很明确。证书所有者可以授权短期密钥终止 TLS，而不必把证书长期私钥复制到每个合作方和每台边缘服务器。CDNI 又为上游与下游 CDN 提供通用的交换格式。减少长期秘密扩散是一项真实改进，但它没有消除短期秘密的发放、保管和部署责任。

能力公告只描述入口条件

下游 CDN 可以通过 FCI.Metadata 声明支持 MI.DelegatedCredentials，再通过 FCI.DelegatedCredentials 公布最多支持多少份委派凭据。对象还可以带一个 JWK 形式的 PrivateKeyEncryptionKey，供上游加密需要传输的私钥。

这里的数字是上限，不是节点清单。RFC 说明，它通常但不一定对应支持委派凭据的服务器数量。下游可以让多台端点共享一份凭据，也可以给每台端点分配不同凭据。公告没有说明有多少空闲容量、哪些端点处于活动状态、哪个区域收敛，也没有为某次发放预留资源。

因此，“下游宣布支持十份”只能帮助上游控制发送规模。它不能证明十台机器存在，更不能证明十台机器已经安装。若控制台把这个数直接绘制成部署覆盖率，图表就制造了消息中从未出现过的拓扑事实。

私钥可以跨接口，也可以根本不跨接口

MI.DelegatedCredentials 包含一个数组。每项凭据是经 base64 编码的 TLS CertificateEntry，其中带 RFC 9345 定义的 DelegatedCredential。与公钥匹配的私钥字段是可选的。

如果包含私钥，它必须装入紧凑序列化的 JWE，并使用下游公告的加密公钥保护。如果不包含，合理解释不是“这份凭据没有私钥”，而是下游可能已经本地生成密钥对，并通过带外机制把公钥提供给上游。上游再用证书私钥为这个公钥签发短期凭据。

两条路线的风险不同。跨接口路线需要证明 JWK 版本、加密算法、接收方、解密组件与秘密存储；本地生成路线需要证明带外公钥请求与本地私钥之间的绑定。统一写成“凭据收到”会抹去事故调查最需要的来源信息。

JWE 保护这次传输，不保护所有历史密文

RFC 9677 不建议通过元数据接口发送私钥。如果运营者仍选择发送，用于 JWE 的加密密钥强度必须不低于被保护私钥。加密可以防止传输过程中的明文暴露，却不提供前向保密。下游的解密私钥未来一旦失陷，过去被保存的 JWE 也可能被打开。

委派凭据寿命短，限制了攻击者利用“凭据加私钥”冒充端点的时间。但短寿命并不能证明旧密文没有被保存、接收密钥没有被复制、私钥已经从缓存删除，或秘密进入了预定的硬件边界。

合格日志应保留凭据与证书指纹、JWE 算法、接收密钥标识、生成与获取时间、验证结果和执行组件，不得记录私钥本身。还要明确区分“凭据对象可解析”和“匹配私钥可用于签名”。只有前者时，TLS 委派路径仍然无法工作。

客户端决定这份凭据能否进入握手

RFC 9345 要求客户端在 ClientHello 中声明支持委派凭据，并给出可接受的签名方案。客户端没有声明时，服务器不得发送委派凭据。客户端仍然要验证证书链与目标服务身份，验证委派签名、有效期和算法匹配，再用委派公钥检查 CertificateVerify。

默认情况下，委派凭据的最长有效期为七天，而且不能超出委派证书的到期时间。它还绑定一个用于握手的签名方案。因此，一份对象可以正确越过 CDNI，却因为客户端算法集合、节点时钟、证书授权或有效期而在现场被拒绝。

即使客户端支持，服务器也可以不发送委派凭据。为兼容旧客户端或提供故障退路，运营者可能保留普通证书、远程签名或其他终止方式。一次成功的 TLS 连接只证明观察到的那条路径可用；若没有握手级证据，它不能证明委派凭据被采用。

RFC 的调用流程没有伪造“全网已完成”消息

RFC 9677 的示意流程依次展示能力公告、元数据获取、客户端握手与到期前更新。元数据获取和客户端握手之间没有逐端点的规范化确认。这一空白留给下游实现，也意味着运营者不能从上一步推断下一步。

真实系统会经历格式验证、JWE 解密、秘密库写入、配置生成、分批发布、进程重载、健康检查和路由切换。队列接收不等于任务执行，秘密写入不等于进程加载，进程加载不等于路由会选中该端点，路由选中也不等于客户端支持对应算法。

所谓“全网 99.9% 完成”必须说明分母：计划节点集合、被排除和排空的节点、各节点最后观测时间、安装指纹、激活状态与路由状态。否则，最高风险的那台节点会被漂亮的平均值隐藏。

到期让模糊状态变成确定拒绝

FCI 能力对象不处理到期或续期。RFC 要求上游监视已发放凭据并及时更新。若下游服务器只有已经过期的委派凭据，它必须拒绝需要有效委派凭据的新 TLS 连接。

这项拒绝规则保持了密码学诚实：服务器不能拿过期材料伪装成功。但一台节点的拒绝只证明该节点在该时间的状态。其他节点可能已经安装继任者，仍在合法重叠期，走备用证书路径，被排空，或者根本无法到达。

短寿命减少被盗后的可用窗口，同时提高轮换频率。每一次轮换都会重新触发那些平时不常走到的依赖。真正的可用性指标不是“上游按时签发”，而是“继任凭据在旧路径失去作用前，已在全部仍被路由的目标集合上可用，并有经过验证的退路”。

十级收据把控制面与客户结果连起来

第一层保存委派证书：身份、指纹、授权扩展与有效期。第二层保存委派凭据：公钥、算法、指纹和到期。第三层记录私钥来源：下游本地生成，还是由上游经 JWE 交付。

第四层是 FCI 公告，包含作用范围、上限与加密密钥标识。第五层是精确版本的 MI 获取与完整性结果。第六层来自每个目标节点的验证和安装。第七层描述全网收敛，并列出失败、过期、排空、未观测与备用节点。

第八层记录具体请求如何被路由到具体端点。第九层保留握手证据：客户端能力、TLS 版本、所选算法、证书链、委派扩展与验证结果。第十层才是 HTTP 响应和应用结果。

这些事实可以相互引用，却不能相互替代。上游交付日志不应被重写成节点事件，节点事件也不应被重写成客户体验。

在第一次轮换之前设计失败语义

若下游没有公告能力，就选择明确支持的路径。若公告上限低于需求，就缩小凭据集合或改变拓扑，不要把上限当作预留。若缺少匹配私钥或 JWE 解密失败，应隔离对象并保留失败原因，而不是无限重试到来源不明。

混合状态的边缘网络要么排空落后节点，要么保留经过验证的备用路径。金丝雀测试应覆盖支持和不支持 RFC 9345 的客户端、不同签名方案、接近到期的凭据以及每个发布批次。备用路径成功必须标成“备用成功”，不能计入委派部署成功。

若怀疑下游解密密钥失陷，需要轮换接收密钥和相关凭据，并评估历史 JWE 是否可能被捕获。七天的有效期是使用边界，不是完整的事件响应方案。

严守边界，才是对标准最大的尊重

RFC 9677 不签发证书、不提供撤销、不决定请求路由、不证明节点收敛，也不确认内容已交付。它把本来可能高度私有、难以互操作的跨 CDN 凭据交换变成公共协议对象，这已经足够重要。

Lu Heng 关于现实层和运行代码优先的笔记给出一个适用原则：配置意图是一个事实，运行中的节点状态是另一个事实，客户端结果又是第三个事实。最小共同规范协调共享部分，本地运营者仍需决定发布、回退、证据保留与事故权限。

所以，CDN 可以凭交接收据说“对象已送达”。要说“边缘已经使用”，必须拿出边缘和客户端自己的收据。

来源