摘要

  • RFC 3709 允许证书关联颁发者、主体或社区标志，却明确禁止这些图形参与证书路径的自动验证。
  • 哈希值能确认取回的文件与证书所指的字节一致；它既不能证明证书路径有效，也不能证明标志确实属于所写的组织。

同一张证书，面对两种读者

软件读取证书时，会依照既定策略构建并验证证书路径。人看到证书时，可能需要辨认对方，或从几张都符合机器条件的证书中作出选择。RFC 3709 处理的是后一种情境：证书字段面向机器而写，并不总适合人快速识别；有些场景最终仍要由用户挑选。

把一张图像塞进与证书相连的签名数据，很容易让人以为它也成为了自动验证的依据。RFC 3709 特意挡住了这种推论：标志面向人的解释，不得成为证书路径验证的主动组成部分。2023 年取代 RFC 3709 和 RFC 6170 的 RFC 9399 延续了这条原则。机器验证与人的识别可以互补，但目标并不相同。前者判断证书路径是否符合规则；后者帮助人理解眼前是谁。 RFC 3709 §1.3 RFC 9399 §§1.3、6

证书保存的是线索，不一定是整张图

RFC 3709 不要求把每一种图像或音频文件都塞进证书。扩展可以记录一个或多个 URI，以及相应数据的单向哈希。客户端取回文件后自行计算哈希；若结果与扩展中的值不符，就必须丢弃该标志。直接引用可列出具体文件，间接引用则指向包含多种格式或尺寸信息的结构；多个 URI 还可作为同一资源的备选取回位置。

这项校验的边界很窄，却很重要：它核对下载到的字节是不是证书所引用的文件。它不能单独证明图中的商标真属于证书里写的公司，也不能证明颁发者有权使用它，更无法保证读者认对了图案。哈希匹配不能挽救一条验证失败的证书路径。文件完整性、路径有效性和人对图像的理解，是三个不同问题。RFC 9399 后来更新了哈希规则；RFC 3709 中历史性的 SHA-1 要求不应当被误读成今天的算法建议。 RFC 3709 §4.2 RFC 9399 §4.2

证书不过关，标志就不能上屏

RFC 3709 也把验证结果与显示动作连起来：依赖方软件若无法成功验证证书，就不得显示该证书关联的任何标志。图像只能与其他身份信息并列，不能替代它们。规范还提醒，失当或不诚实的颁发者可能给证书附上自己无权声称的名称或图案，让熟悉感变成诱导用户的工具。

规范并没有说图形无关紧要；它承认标志可能影响用户是否愿意信任或使用证书。正因如此，机器验证与人工识别才必须分开。机器先给出证书策略所定义的验证结果；随后，人可以结合身份信息、具体场景和用途作判断。标志可以是判断材料，却不是密码学验证的一环。 RFC 3709 §§1.3、5–7

修订之后，边界仍在

RFC 6170 于 2011 年更新了这项扩展，RFC 9399 则在 2023 年取代两份旧文档。后继规范保留了核心区分，还补上今天更显眼的隐私问题：取回远端标志，可能暴露客户端正在使用哪一张证书。在 TLS 1.3 中，即使服务器证书已加密，客户端请求远程图像仍可能让网络观察者推断服务器身份。缓存改变的是暴露发生的时机，并不会改变图像能证明什么。 RFC 6170 RFC 9399 §9

RFC 3709 的历史意义，不只是给证书加了一层图形。它同时为这层图形划定证据边界：可校验的图片仍是给人看的线索，不是验证器默默给出的结论。

来源