摘要

  • RFC 6920 于 2013 年 4 月定义 Named Information（ni）名称，以哈希算法和摘要值标识数字对象。比较两个名称时，算法、长度和摘要值决定是否指向同一对象；可选的服务器地址不参与身份判断。
  • ni 名称可以映射为 HTTP(S) 的 /.well-known/ni/ 地址，向服务器索取候选文件。IANA 登记表协调算法名称和长度，不保存文件，也不列出有哪些服务器存着它。
  • 文件是否被找到、收到的字节是否被实际校验、最初提供摘要的人是否可信，是三道不同工序。要证明某个服务使用了这套机制，需要有日期的名称交付、取件与客户端哈希比对记录。

地址能到门口，认不出包裹

普通 URL 的优势是灵活。一个主机名加一条路径，浏览器就能发起请求；网站更新文件，也不用逐一替换旧链接。对不断修改的页面来说，这很实用。对需要确定版本的程序、报告或数据集来说，问题随之出现：同一条链接今天拿到的字节，还是当初分享时指的那一份吗？

许多系统早已把哈希结果塞进标识符，却各写各的格式。RFC 6920 为这种做法定了一套共同语法。ni URI 写明算法，分号后接不带填充字符的 base64url 摘要。默认情况下，计算输入就是取回时期待得到的对象字节。若应用要哈希别的输入，就得由采用该名称的协议另行说明。

于是名称与地址开始分工。地址回答“去哪儿问”，摘要回答“要的是哪串字节”。同一份内容从一台服务器迁到另一台，摘要可以保持不变。服务器在原路径换了文件，新的字节就会得到另一个摘要。前提是客户端真的计算并比较，而不是把指纹当作页面装饰。

RFC 6920 对同名的判定相当干脆：只比较摘要算法和摘要值，连同明确标出的长度；URI 里可选的 authority 和查询参数都不算。两个不同主机给出的 ni 名称，只要这组值相同，就指向同一个对象。主机可以帮忙找货，却不能通过改主机名就宣布文件换了身份。

到送货环节，地址又回来了

有了指纹，并不等于有了分发网络。RFC 6920 规定可以把 ni 名称转换成 HTTP 或 HTTPS 下的 /.well-known/ni/ URL。名称带有 authority 时，它成为目标主机；没有时，应用可从使用环境挑选一个。目标服务器也可以返回重定向。经历这些地址之后，客户端才可能拿到文件并核对摘要。

标准说得清楚：映射出来的 HTTP 地址并不保证提供该对象。一枚正确的指纹贴在空仓库门口，仍然取不到货。若服务器返回了内容而摘要不符，问题变成了另一种：有货，但不是订的那件。把两者统称“链接坏了”，会掩盖到底该由运营方补文件，还是由客户端拒绝替换品。

这套机制把权力拆开。提供 ni 名称的一方指定预期内容；运营服务器的一方决定是否保存和供应候选字节；写客户端的一方决定是否执行校验。RFC 6920 允许应用处理名称而不在每次使用时验证名称与内容的绑定。标准把工具交了出来，运行中的程序要负责把它用上。

文档还定义了适合紧凑协议的二进制形式，以及便于口头传递的 nih 形式，后者使用十六进制字符和校验位。它们处理的是同一身份如何传达，不是同一文件由谁长期储存。一个名字有几种写法，仍需有人开仓、有人验货。

登记算法不等于保管文件

两套实现要读懂同一枚指纹，必须对算法名称和摘要长度达成共识。IANA Named Information 登记表列出这些名称、长度、参考文件及内容类型参数 ct。RFC 6920 要求实现支持完整 SHA-256，也允许明确标名的截短形式。截得越短，碰撞余地越大；名称本身必须把长度说清楚，不能让短值冒充完整值。

登记表是一部词典，不是文件仓库。它能让两个独立开发者对 sha-256 的拼写有共同理解，却不会把某份报告放到任何服务器上，也不会给客户端下载一份副本。把协调标识符的机构当成内容保管者，是把一项很窄的公共职责膨胀成它没有执行的工作。

安全边界同样尖锐。RFC 6920 指出，摘要对内容完整性的证明，取决于客户端最初拿到的那个名称有多可信。攻击者若同时交出恶意文件和与之匹配的摘要，两者可以完美一致。哈希证明“这两个东西相配”，不会自行证明“是谁选的这份文件”。公布摘要也不保证保密：容易猜到的内容可以被别人逐个试算。

官方 RFC 与 IANA 表能证明名称结构、比较规则和 HTTP 映射。它们没有替某个具体产品提供部署记录。要判断一项服务是否真的按此运行，还需它的有日期取件路径，以及客户端对收到字节所做的计算。2013 年这项设计留下的真正工具是：文件身份可以离开原服务器，而拿到手的东西有办法被重新认出来。