Summary

  • 10 月 23 日提交的一份 IETF 个人草案，拟用 DNS 记录核验内容发布者的签名密钥，以及身份资料是否已经撤销。
  • 发布者可在自有域名下列出认可的核心资料签发方；名单经 DNSSEC 验证后，名单外的签发方不能仅凭一张有效证件替它说话。

一家报社门口来了位客人，证件是真的，发证机构也有名气。门卫仍该问一句：报社请过这家机构代表自己发证吗？Shigeya Suzuki 于 10 月 23 日提交的原始草案，把这句口头盘问写进 DNS。IETF 档案明确标注它是个人 Internet-Draft，没有获得 IETF 正式认可；拟议状态为实验性。新闻是控制权的设计，而非一项已经通行的互联网规则。

设计中的 Originator Profile 用于说明数字内容出自谁手。核心资料由签发方发给发布者，载有发布者用于签名的公钥；其他签发方可添加经过核实的属性。读者拿到内容和资料，能核对签名，却还要知道密钥现在是否有效。草案新设 OPKEY 记录，把密钥摘要放在 _op 名称下，由签发方的记录表示核心资料是否仍然有效；注释资料的撤销另用 TXT 记录。完整资料不塞进 DNS。

真正有意思的是发布者自己域名下的 SVCB 记录。它可以写明哪些核心资料签发方获准为这个发布者发证。验证者拿到经过 DNSSEC 认证的名单，就要把资料上的签发方与名单逐一对照。即使某家机构在整个框架中被认可，也不能自动替名单外的发布者作证。不过，名单在这份草案里是可选项；适用规则没有强制要求、域名下也没有可信名单时，发布者便没有固定签发方。这道门要由主人亲手装上。

门锁还得分辨“屋里没人”和“线路坏了”。查询 OPKEY 时，未签名、验证失败或解析故障都使核验失败，不能被解释成记录不存在。可选的 SVCB 名单有自己的规则：可信的不存在证明可让发布者保持未固定状态，伪造的回答或超时则要停止核验。草案对这两个路径分得很细，因为错误地把故障当作空名单，会替冒名者开门。

撤销之后，旧证件也不会瞬间从每台机器的记忆里消失。草案以一小时的记录生存时间和否定缓存时间作为部署假设；缓存里的旧答案在有效期内仍可被接受，已经签过名的旧答案还可能在签名过期前重放。在设置为 60 秒的实验环境中，增删记录经验证解析器可在 63 秒内看见。那是一次实验观察，不是全网撤销服务承诺。