摘要

  • RFC 1805 让文件内容哈希和日期由可信第三方签章，文件与证书可以一起流转，完整性核验不再绑死原始存放地点。
  • 协议把作者身份核验方法留给具体应用；Bellcore 的 Betsi 实例曾通过当地电话查号和回拨确认登记信息与公钥。

文件在互联网上搬家，信任却没有快递标签。1995 年，Aviel Rubin 在 RFC 1805 里提出一个办法：作者可以把文件放在不同站点，甚至经由不可靠的网络传送；读者拿到文件和可信第三方签发的证书，再核对内容哈希与日期。最有年代感的细节不在加密算法里，而在作者身份这一关。文中描述的 Bellcore Betsi 实例，会向作者所在地的查号服务要电话号码，然后打过去核对资料。

这个电话不是为了给数字系统添复古摆设。Rubin 先指出另一处麻烦：负责检查文件的程序本身也可能被人改掉。一个从同一渠道拿来的验证器说“没问题”，不能自动成为自己的担保人。于是方案采用 ASCII 消息和既有签名技术，让使用者能够自己写验证程序，或从可信来源取得。系统里的三方很清楚：作者 A、使用者 U，以及第三方 T。每个人管的事不同，不能把一枚签章当成全部答案。

流程分五段：作者登记、作者身份核验、文件认证、文件分发、完整性核验。第二段在协议里故意不写死；不同场合可以有不同的身份核验办法，但证书必须交代究竟采用了哪一种。因为签名能证明某把密钥签了消息，不能凭空证明密钥属于登记表上的那个人。Betsi 在美国运行时，第三方查询作者城市的电话号码，回拨并确认登记资料，尤其是公钥。RFC 明白写出这个美国实例；电话回拨是实例的做法，不是所有部署的统一命令。

作者完成登记后，先计算文件的加密哈希，再签署认证请求交给 T。T 核对请求，制作并签署一份证书，记录哈希、所用哈希函数、日期、作者姓名以及身份核验方法。请求里的文件位置可以不填。这个小小的可选项揭示了整套设计：被认证的是文件内容与时间，不是某台 FTP 服务器的门牌。文件和证书一起发出去，读者即使从不可信站点取得副本，也能独立比较字节。

读者的功课比“看到封印就点运行”长得多。要从独立来源取得 T 的公钥，验证 T 对证书的签名，判断证书标明的作者核验办法是否值得信任，再对实际拿到的文件重新计算哈希并比对。日期重要就核对日期；最后还要查看 T 发布的最新、完整、带签名的撤销名单，确认这张证书没有被撤销。任何一步被省掉，绿灯都可能只是界面颜色。

这条链能够支持具体结论：在接受第三方公钥、身份核验方法和撤销状态的前提下，手里的字节与某个日期由 T 认证的字节一致。它不会替软件评选品行，也不会保证运行安全。RFC 1805 的历史趣味正在于此：文件位置可以脱钩，身份与责任却需要有落点。互联网让文件飞快远行，信任仍得知道电话要打给谁。