摘要

  • draft-mittal-est-coap-ca-certs-00 提议让设备用出厂安装的制造商信任锚，验证一份包含运营 CA 证书的 CMS 签名对象。它只是个人提交的第 00 版 Internet-Draft，不是 RFC、IETF 共识或部署证明。
  • 引导服务器可能尚未获认证。TLS 或 DTLS 此时只提供传输；制造商签名只约束对象。客户端仍须核验签名用途、别名、序号、有效期和本地策略。
  • 安装运营信任锚不能追溯认证原连接，更不授权证书注册。客户端必须新建 TLS/DTLS 会话，在新锚下验证服务器，然后才可进行非引导 EST 操作。

很多自动化系统只有一个“已信任”状态。对引导流程而言，这个状态太粗。工厂预置的根、签名对象的真伪、本地信任库变更、服务器身份、注册资格以及证书签发结果，分别由不同主体、不同密钥和不同时间点决定。

个人草案 draft-mittal-est-coap-ca-certs-00 处理的是一个真实的先后矛盾：设备出厂时，最终运营者可能还没有选定 PKI。设备只认识制造商，尚不认识未来 EST 服务器的 CA；但通常又应当先认证服务器，才能安全取回 CA。

草案的办法是把授权放进对象。运营者选定 CA 后，由制造商或其授权签名机构制作 ManufacturerSignedCACerts，用 CMS SignedData 保护。EST 服务器只负责把预先签好的对象放在制造商专用别名之下。客户端即使暂时不能验证服务器证书，也可以只取回这个对象。

这并不自相矛盾。一个不可信的中继可以传递真实对象，正如不受信任的镜像可以分发可验证的软件包。危险发生在系统把“对象签名正确”升级成“传输端点可信”。草案明确禁止这种推理：在运营锚安装以前，连接对 EST 授权仍然是未认证的；安装以后，必须开一个新会话再认证服务器。

签名者授权的是对象，不是套接字

拟议结构包含版本、别名、递增序号、notBefore、notAfter 和一个或多个 CA 证书。CMS 签名覆盖完整结构，并携带签名证书及通向设备本地制造商锚所需的中间证书。

密码学验证回答的是窄问题：受认可且具备此用途的签名者，是否保护了这些确切字段与证书字节。它没有回答 DNS 名称由谁控制、IP 地址属于谁、当前 HTTP/CoAP 服务由谁运行，也没有赋予该端点接收 CSR、长期标识或客户端凭据的权力。

服务器可以给同一制造商信任域的所有设备返回相同静态对象。它无需持有制造商私钥；除非拥有明确授权的凭据或签名服务，也不得在请求时动态生成签名。分发权与签名权被有意拆开。

因此日志也要拆开。分发端日志只能说明某个 URI 返回了对象；签名系统日志说明谁批准了对象；设备日志说明它如何验证并是否安装。把三者合成“可信来源”会在事故时丢失责任链。

HTTPS 引导通道只能请求 /cacerts。EST-coaps 对应 /crts。客户端不得在尚未认证的连接中发送证书申请、重注册、CSR 属性请求、客户端凭据、长期标识或敏感数据。DTLS 即使提供了机密性，也不能让未验证的服务器身份凭空成立。

别名用于选路，不用于授权

路径可能是 /.well-known/est/{manufacturer-alias}/cacerts。部署可以用 IANA Private Enterprise Number 构造别名，但第 00 版没有规定唯一算法，也没有请求新的 IANA 注册。

外层路径很容易被误读成权力来源：既然设备访问了“某制造商”的目录，返回内容似乎就属于该制造商。草案不接受这种简化。别名也被写进签名结构，客户端必须比较受保护别名与请求别名或本地明确配置的等价别名。签名再正确，只要上下文不匹配，也必须拒绝。

这可以阻止多租户服务器把 A 厂商的有效包替换到 B 厂商路径。更一般地说，URI 选择上下文，签名绑定内容，本地规则决定可接受等价关系。这三层不能互相冒充。

可审计记录至少要包含配置别名、请求 URI、对象内别名、等价规则、CMS 哈希与判断结果。只记录 HTTP 200 无法证明对象；只记录“签名有效”也无法解释为什么它可以改写这台设备的信任库。

旧包可以完全真实，也完全危险

签名不会因为运营 CA 后来被攻破而自动失效。攻击者可以重放上一代仍有合法签名的包，把设备拉回已撤销的信任集合。恢复出厂设置尤其危险：设备可能清除了自己曾接受更高序号的记忆。

草案加入递增 sequenceNumber 与时间区间。客户端应按别名保存已接受的最高序号，并拒绝更低版本。有可靠时间时，必须检查开始与结束时间；没有可靠时间时，可以暂时依赖序号，待取得可信时间后再复核区间并执行本地策略。

这意味着序号存储本身就是安全状态。若它与普通配置一起被重置，防回滚机制会在最脆弱的重新引导时消失。运营者需要定义：序号放在哪里、备份恢复如何处理、相同序号不同哈希怎么办、紧急降级由谁批准、板卡更换如何继承历史。

缓存还引入另一只时钟。静态对象降低拒绝服务成本，却可能在撤回后继续被 CDN 忠实分发。内容未被篡改不等于内容仍然当前。签名证明完整性，序号与时间证明相对新鲜度，本地状态证明设备之前看过什么。

正确的收据应把对象哈希、保护序号、上一接受序号、时间可信度、有效期结果、缓存年龄、策略版本和变更后的锚集合哈希连接起来。单独一个“签名通过”灯会掩盖最现实的回滚路径。

本地策略是运营者最后的否决权

第 00 版允许验证后的包增加、替换或扩充运营信任锚，同时要求客户端应用本地信任锚管理策略。这不是多余条款，而是防止制造关系扩张成终身控制的关键。

制造商签名表示设备出厂时认可的主体提出了这次变更。它不能自行决定运营者是否允许删除旧根、是否要求重叠期、是否排除某些 CA、是否要在维护窗口内执行，或者某个站点是否应保持自己的根集合。

Lu Heng 的“最小初始规范”在这里具有直接含义。共同层只需规定可本地验证的最低事实：签名路径、专用用途、确切字节、别名、序号与时间。未来采用哪家运营 CA、何时轮换、出现妥协后如何处置，应由承担后果的运营者决定。

若实现看到任何制造商有效签名便自动安装，制造商密钥就成为远程信任库控制面。它不仅解决首次分发，还获得改变设备未来信任对象的能力。这种持续性权力超出了引导问题所需。

安全客户端应在密码学验证与实际变更之间暴露政策步骤：计算现有与拟议集合哈希，列出新增与删除项，运行分设备群规则，写入不可追加修改的变更收据，并允许明确拒绝。拒绝后必须停在注册前，不能回退到继续信任原来未认证的服务器。

新会话才是服务器身份的证明点

安装新锚后，客户端必须重新建立 TLS 或 DTLS。新的握手使用刚刚接受的锚验证服务器名称与证书链。这一步不是重复劳动，而是两个信任时代的分界线。

原服务器是在信任库改变前出现的。继续复用旧连接，会把此前未认证的通道与此后可验证的身份混为一谈。库可以在内存里重新检查证书，但对非引导 EST 操作而言，新连接提供了最清晰的证据边界，也避免沿用旧会话参数和状态。

RFC 7030 本来就允许为 /cacerts 暂时完成 TLS，再通过带外方式批准 CA 数据，并在正常操作前重连。新草案用制造商签名替代人工或带外批准对象的环节，没有取消第二次握手。

RFC 9148 把 EST 映射到受限设备的 CoAP/DTLS，并把 /cacerts 映射为 /crts。它还讨论信任锚更新后的服务器链复核。受限传输并不等于任何 /crts 应答者都是合法注册服务器。

新会话收据应记录会话标识、预期名称、服务器链指纹、实际采用的运营锚、验证策略、结果与时间。后续注册请求应引用这份收据，否则系统无法区分“我们接受了一个 CA 包”与“我们认证了接收 CSR 的服务器”。

注册不是引导步骤的自然尾声

服务器身份通过后，设备仍须提出 CSR、证明私钥持有并满足 CA 政策。正确的服务器可以拒绝注册；正确签发的证书也可能属性错误、无法安装或不能让业务上线。

草案说明它不修改 EST 注册语义、持有证明或 CA 政策。它只分发运营 CA。它不验证设备、不批准 CSR、不生成最终证书，更不证明现场服务成功。

编排器应保留多个终态：包已取回、签名者已授权、新鲜度通过、本地策略接受、信任库已变更、新会话认证成功、注册被批准、证书已安装、服务已观察。每个状态都能独立失败并有不同修复者。

制造商负责引导签名者，运营者负责本地政策，EST 服务负责服务器身份与请求处理，CA 负责签发，运行系统产生结果。任何一枚签名都不能合法地替这些主体完成决定。

制造商密钥会形成全设备群杠杆

草案坦率指出，制造商签名私钥一旦泄露，攻击者可制作设备会安装的恶意 CA 包。它建议用 HSM、KMS 或等价环境保护密钥，防止导出，并把证书专用于引导 CA 包，不能兼做 TLS 服务器认证、CA 签发、固件签名或其他用途。

用途隔离同时缩小事故半径并澄清客户端授权。仅仅“链到制造商”不够；软件必须知道该证书被允许执行哪一类机构行为。否则 PKIX 成功只是把角色模糊藏在数学正确后面。

真正的治理问题从疑似妥协开始：谁能禁用一个别名？如何接受紧急继任签名者？能否枚举所有安装过可疑包的设备？制造商破产或拒绝合作时，资产所有者如何继续轮换？若恢复仍依赖同一把可疑密钥，系统没有独立恢复路径。

RFC 8995 与 RFC 8366 的 voucher 机制提供了有用对照：它们绑定的是设备、域和相应断言，并有自己的新鲜度和本地接受规则。不能因为都有制造商签名，就把本草案说成 BRSKI、既成标准或已部署系统。

未认证端点必须廉价、静态、可隔离

引导请求发生在正常认证以前，服务器必须抗拒绝服务。草案建议预计算静态对象，避免每设备数据库查询和动态签名，按源地址、前缀、别名及实例限速，使用 DTLS cookie 或无状态重试，只允许 GET，限制响应与放大，并谨慎管理 Block-Wise 状态。

这些建议暴露了机制的本质：引导阶段更像公共签名对象仓库，而不是个性化注册服务。若端点需要客户查询、实时签名或敏感身份才能返回包，它已经扩大了攻击面，也偏离了最小设计。

明文模式还说明完整性与隐私不同。CMS 可以防篡改并证明对象来源，却不会隐藏别名与 CA 包。如果别名泄露客户、地区或迁移时间，运营者即使不接受服务器身份，也应使用 TLS/DTLS 保护旁观者可见性。

不要把八张收据压成“引导成功”

收据 最低证据 它不能证明
出厂来源 设备型号、锚指纹、存储、别名规则 当前制造商控制
对象授权 CMS 哈希、链、用途、签名结果 服务器身份或新鲜度
范围与新鲜度 内外别名、序号、时间、时钟可信度 本地接受
本地变更 策略、批准规则、前后锚哈希 新服务器认证
引导传输 URI、展示证书、加密、缓存、交付 EST 授权
新会话身份 名称、链、运营锚、结果 注册批准
注册 CSR、客户端身份、持有证明、CA 决定 业务可用
运行结果 证书安装、健康检查、明确服务观察 下一次包的合法性

拆分证据不是官僚负担，而是让恢复有选择。错别名时无需推翻 CA；服务器配置错时不必否定包；注册失败时可以保留正确的锚轮换；制造商密钥泄露时可以定位每一次受影响变更。

第 00 版最值得重视的边界因此很窄：经独立验证的签名对象可以穿过未信任传输，但不能把信任扩散给传输。只有本地策略批准后，信任库才改变；只有下一次握手成功后，服务器身份才成立。