4. 多重签名的语义

4.1. 示例场景

一条消息可能有多个签名, 原因有很多. 例如, 假设未来发现 SHA-256 强度不足, DKIM 使用转向 SHA-1024. Signer 可能会立即使用较新的算法签名, 但也继续使用较旧算法签名, 以便与尚未升级的 Verifier 保持互操作. Signer 会通过添加两个 DKIM-Signature header field 来做到这一点, 每个算法使用一个字段. 不把 SHA-1024 识别为可接受算法的旧 Verifier 会跳过该签名并使用较旧算法; 新 Verifier 可以任选任一签名, 在其他条件相同的情况下, 甚至可能不尝试验证另一个签名.

类似地, Signer 可能会对包含所有 header field 且没有 "l=" tag 的消息签名 (以满足严格 Verifier), 同时第二次使用有限 header field 集合和 "l=" tag 进行签名 (预期消息在通往其他 Verifier 的路径上可能被修改). Verifier 随后可以选择偏好的签名.

当然, 消息也可能因为经过多个 Signer 而具有多个签名. 一个预期的常见情况是, 已签名消息经过一个也会对所有消息签名的邮件列表. 假设两个签名都能验证, 如果其中任一签名已知来自可信来源, 收件人可能选择接受该消息.

特别是, 收件人可能选择把自己订阅且具有可接受反滥用策略的邮件列表加入白名单, 从而接受发送到该列表的消息, 即使作者未知. 他们也可能订阅可信度较低的邮件列表 (例如没有反滥用保护的列表), 并愿意接受来自特定作者的所有消息, 但坚持对其他消息执行额外滥用扫描.

另一个与多个 Signer 相关的示例是转发服务, 例如常与学校校友站点关联的服务. 例如, 收件人可能在 members.example.org 拥有地址, 该站点的反滥用保护效果低于收件人期望. 这类收件人可能有若干特定作者, 其消息会被完全信任; 但来自未知作者且通过转发方审查的消息只具有中等信任度.

4.2. 解释

向消息添加签名的 Signer 只是创建一个新的 DKIM-Signature header, 并使用 "h=" 选项的通常语义. Signer MAY 使用 Section 5.4 中描述的签署 trace header field 的方法, 对此前已存在的 DKIM-Signature header field 进行签名.

注意, Signer 应意识到, 对 DKIM-Signature header field 进行签名可能导致签名失败: 某些中间方不认识 DKIM-Signature header field 是 trace header field, 可能无意中对其重新排序, 从而破坏此类签名. 因此, 对现有 DKIM-Signature header field 进行签名虽然合法, 但不建议这样做.

INFORMATIVE NOTE: 如果对具有多个实例的 header field 进行签名, 这些 header field 始终自底向上签名. 因此, 不可能只签署特定的 DKIM-Signature header field. 例如, 如果正在签署的消息已经包含三个 DKIM-Signature header field A, B 和 C, 则可以签署全部字段, 仅签署 B 和 C, 或仅签署 C, 但不能仅签署 A, 仅签署 B, 仅签署 A 和 B, 或仅签署 A 和 C.

Signer MAY 使用不同参数添加多个 DKIM-Signature header field. 例如, 在过渡期间, Signer 可能希望使用两种不同哈希算法生成签名.

Signer SHOULD NOT 从其正在签名的消息中移除任何 DKIM-Signature header field, 即使它们知道这些签名无法验证.

评估具有多个签名的消息时, Verifier SHOULD 独立评估各签名并依据其自身情况判断. 例如, 如果 Verifier 按策略选择不接受使用已弃用加密算法的签名, 则会认为此类签名无效. Verifier MAY 按自己选择的任意顺序处理签名; 例如, 某些 Verifier 可能选择先处理与消息 header 中 From 字段对应的签名, 再处理其他签名. 关于签名选择的更多信息见 Section 6.1.

INFORMATIVE IMPLEMENTATION NOTE: Verifier 试图关联有效签名和无效签名以猜测签名失败原因, 这种做法并不明智. 特别是, Verifier 没有通用方法可以确定一个无效签名曾经有效.

Verifier SHOULD 持续检查签名, 直到某个签名成功验证并令 Verifier 满意. 为限制潜在拒绝服务攻击, Verifier MAY 限制其尝试验证的签名总数.

如果 Verifier 模块报告评估产生 PERMFAIL 结果的签名, Identity Assessor SHOULD 忽略这些签名 (见 Section 6.1), 如同它们不存在于消息中一样.