摘要

  • OpenPGP 工作组 9 月 4 日启动采纳征集，讨论一份用 External 标记私钥材料位于外部、并允许可转移密钥携带可选定位提示的草案。征集 9 月 18 日结束，本文不预判采纳结果。
  • 定位提示只是建议。实现即使收到提示也可以进行“尽力而为”探测；不认识提示时可以忽略。03 版没有定义任何具体提示方案，现行 IANA OpenPGP 注册表也尚无拟议的 252 条目和新提示注册表。
  • 存根能携带密码学身份，却不能携带驱动支持、设备在场、操作授权和恢复能力。迁移应另存受隐私约束的本地交接记录，而不是把敏感设备标识塞进公开格式。

征集正在进行，注册项仍不存在

OpenPGP 联合主席 Stephen Farrell 于 9 月 4 日发出工作组采纳征集，截止日为 9 月 18 日。征集对象是 draft-dkg-openpgp-external-secrets-03。这份草案此前在 IETF 126 介绍过，目标是让不同实现以统一方式表示：某个 OpenPGP 非对称密钥的私密部分并不在可转移文件里，而是由硬件或其他外部子系统保存并执行操作。

Datatracker 页面把两个状态分得很清楚。工作组状态是 Call For Adoption By WG Issued，IESG 状态是 I-D Exists；文档仍是活跃的个人 Internet-Draft，未获 IETF 背书。03 版日期为 2026 年 7 月 22 日，2027 年 1 月 23 日到期。

Daniel Kahn Gillmor、Andrew Gallagher 与 Heiko Schäfer 已公开支持采纳，Paul Schaub 表示愿在采纳后共同编辑。这些邮件说明参与者的理由与编辑意愿，不是投票结果，也不能替主席宣告共识。

技术编号同样要保持现在时。草案暂以 252? 表示新的 S2K Usage Octet，并请求建立“OpenPGP External Secret Key Locator Hints”注册表。IANA 现行注册表只有既有的 S2K 使用值，没有 External 的 252 条目，也没有这张新表。草案中的 IANA Considerations 是请求，不是已经完成的注册。

存根用公钥材料找候选者

RFC 9580定义了 OpenPGP Secret Key Packet 与 Transferable Secret Key。新草案 03 版提出：数据包保留关联的公钥参数，把 S2K 使用值设为 External，随后可以附上一段可选的定位提示。私密参数本身不进入文件。

“尽力而为”发现依赖相应公钥材料。实现可以询问它支持的智能卡、TPM、HSM 或其他子系统，看哪个候选者列出了匹配的公钥。这样，迁移不必完全依赖“办公室抽屉里的第二张卡”这类只对一个人有效的描述。

但匹配对象与使用能力是两回事。草案明确说定位提示完全是 advisory。没有提示时，消费者进行尽力而为探测；提示无法识别或没有指向有用设备时，也可以探测；即使理解提示，消费者仍可选择尽力而为。生产方如果没有有意义的提示，就不应在 External 值后添加尾随数据。

03 版刻意不定义具体提示方案。它只提出一个初始为空的 IANA 注册表，把 96–111 留给私用或实验，并让其他分配遵循 Specification Required。这是一处可扩展接口，还不是全球通用的硬件地址簿。

“在这里没找到”不是“世界上不存在”

同一份私钥材料可能存在于多个设备。智能卡从一台电脑移到另一台电脑后，USB 路径会变化；一套实现支持 OpenPGP Card，另一套只会调用平台 TPM；一个 PKCS #11 URI能在相应体系内标识对象，却不能自动覆盖所有外部子系统。若把物理槽位或序列号固化进存根，局部定位可能更快，跨平台迁移反而更脆弱。

因此，探测成功只能说明：某一时刻、某一实现可接触的候选子系统声称拥有与公钥匹配的私密材料。它没有证明谁是合法持有人，没有证明本次操作得到组织授权，也没有证明不存在第二份副本。

探测失败的含义也很窄。设备可能未连接、驱动可能缺失、账户可能过期、令牌可能锁定。设备可以列出公钥，却在真正签名或解密时拒绝访问。它也可能等待 PIN、生物特征、触按或 NFC 接触，最后因超时而失败。正确表述是“本实现未在这些条件下取得能力”，而不是“私钥已经丢失”。

草案把这些差别写进可用性要求。列举公钥和检查匹配不应要求授权；私密操作则可以要求。若两个设备都有同一密钥，优先尝试无需授权者可能降低误输 PIN 导致锁定的风险。界面还应提示需要哪种交互，设置合理超时，并把可处理的错误交给用户。

企业交接尤其容易把三个状态压缩成一句“密钥已迁移”：文件被导入；匹配子系统被找到；授权后操作成功。前两步都不能替代第三步。一个备份只要漏掉外部能力，就可能把“可验证的引用”误当成“可恢复的服务”。

硬件隔离不是全栈安全证明

外部密钥确有价值。有些设备不会导出私密材料，可以限制调用频率、要求用户可见动作，或证明密钥在卡内生成。可移动令牌还能让使用者换电脑而不扩大私钥明文副本数量。

草案也保存了反证。硬件可能有设计缺陷，可能遭受电压、温度等物理攻击。宿主机若被攻破，即使拿不到长期私钥，也能偷走解密后的明文或对称会话密钥。签名时，用户按下按钮并不保证硬件收到的对象就是屏幕上显示的对象；被控制的宿主软件可能偷换输入。

Gillmor 在回复中说，硬件设备对几乎所有 OpenPGP 用户都不是合理权衡，但一些人确实需要一种简单、标准的表示方式。Schäfer 则在回复中强调某些场景实际离不开硬件支持。工作组是否采纳这项互操作工作，与是否建议所有人使用同一托管模式，是两项不同决定。

把操作交接收据放在格式之外

不应为了治理便利，把企业设备清单装入 OpenPGP 数据包。卡号、HSM 分区、账户、人员权限和恢复路径既会变化，也可能泄露安全信息。全球格式应保持窄小；本地迁移则需要一份独立的外部密钥交接收据。这是 Daniel Kade 的编辑建议，不是 IETF、OpenPGP 或草案要求。

受保护的收据可以绑定证书与相关子密钥指纹、草案或未来 RFC 版本、实际使用的代码点状态、已理解的提示方案及版本、实现与可探测子系统类别、观察时间、公钥匹配方式、是否发起授权、请求何种操作，以及返回结果或有边界的错误。替换或恢复时，新记录应链接旧记录，而不是静默覆盖。

公开层只需披露不透明的收据引用、能力类别和已验证结果。设备序列号、PIN、生物信息与内部拓扑留在权限控制之内。收据记录一次本地观察，不授予签名权，也不代替组织的所有权与保留政策。

Heng Lu 的 Policy Mirror提醒机构把行动者、规则和证据分开；最小初始规范允许全球共同核心保持精简，把本地扩展留给真正负责的人；Why BTW Media Exists则规定报道边界：征集尚未结束，代码点尚未分配，互操作效果尚待证实。

External 这个词的诚实之处，在于它承认文件之外还有决定性部分。标准能让这项缺席变得可读；只有本地证据能说明它下一次是否可用。

来源

  1. OpenPGP 工作组采纳征集
  2. Datatracker 当前记录
  3. OpenPGP External Secret Keys 03 版
  4. IETF 126 演示文稿
  5. Daniel Kahn Gillmor 的回复
  6. Andrew Gallagher 的回复
  7. Heiko Schäfer 的回复
  8. Paul Schaub 的回复
  9. IANA OpenPGP 注册表
  10. RFC 9580 — OpenPGP
  11. RFC 8126 — 注册政策
  12. RFC 7512 — PKCS #11 URI
  13. Heng Lu — The Policy Mirror
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Why BTW Media Exists