Summary

  • 11 月 2 日提交的 IETF 个人草案为 EST 增加基于远程证明的新凭证申领和既有凭证取回流程。EST 客户端与服务器负责传送，不能评估证明或批准发放。
  • 新凭证由凭证授权方核验密钥持有证明后签发；已有凭证由密钥库依据证明结果和自身策略挑选并加密交付。

一份申请从谁的柜台经过，不决定谁有权批准。这份 EST 远程证明草案把这层常被系统图掩盖的区别写成了明确限制：EST 客户端和服务器不得生成密钥、证明材料或证书请求，不得签发保鲜用的随机标记，不得评估证明结果，也不得批准凭证签发或释放。服务器能把一次请求与先前的标记对上号；草案特意指出，对号不等于授权。

要领一张新凭证，工作负载先生成签名密钥、证书请求和与二者绑定的运行状态证明。核验方检查证明，凭证授权方再检查申请者是否真正持有对应私钥，并依据核验结果决定能否签发。EST 服务器将各段信息送达，却没有替授权方做决定的票。

另一条路通向已有凭证。工作负载生成加密密钥，把公钥写入证明。密钥库读取核验结果，按自己的策略选出可交付的凭证组，再用该公钥封装凭证包。EST 中间环节必须把封装包当作不透明物转送。收件方打开前，还要核对目标、时效标记和凭证提示。提示可以在已获准的范围内帮助选择，不能把范围撑大。

共享凭证让多个副本拿到相同能力，也留下账本上的盲点。草案明说，共用一把密钥就失去了逐实例归责：事后即使知道哪个凭证组签了名，也未必知道是哪一个副本。若调查必须追到单个实例，可以给各实例配置独立密钥、保留相同身份声明，或改用集中签名服务。方便分发与精确归责，不能靠一个含糊的“安全”标签同时许诺。

IETF 文档记录显示它仍是个人提交的草案。文中有示例交互，没有独立的互通测试结果。下一项有用证据，是让实现真正拒绝服务器擅自改选凭证类型、篡改密钥绑定或用提示越过密钥库策略。这个提案先把权力线画清：递材料的人不发证。