4. Semantics of Multiple Signatures (多重签名的语义)

4.1. Example Scenarios (示例场景)

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

同样, Signer 可能会签名一条消息, 包括所有头字段且没有 "l=" 标签 (以满足严格的 Verifier), 并使用有限的头字段集和 "l=" 标签进行第二次签名 (以预测可能在途中对其他 Verifier 进行的消息修改)。然后 Verifier 可以选择他们偏好的签名。

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

特别是, 收件人可能选择将他们订阅的具有可接受的反滥用政策的邮件列表列入白名单, 以便接受发送到该列表的消息, 即使来自未知作者。他们也可能订阅不太受信任的邮件列表 (例如, 那些没有反滥用保护的列表), 并愿意接受来自特定作者的所有消息, 但坚持对其他消息进行额外的滥用扫描。

多个 Signer 的另一个相关示例可能是转发服务, 例如通常与学术校友网站相关的转发服务。例如, 收件人可能在 members.example.org 拥有一个地址, 该网站的反滥用保护效果略逊于收件人所希望的。这样的收件人可能有特定的作者, 其消息将被绝对信任, 但来自未知作者且通过转发者审查的消息仅具有中等信任度。

4.2. Interpretation (解释)

向消息添加签名的 Signer 只需使用 "h=" 选项的常规语义创建一个新的 DKIM-Signature 头。Signer 可以使用 Section 5.4 中描述的方法签名先前存在的 DKIM-Signature 头字段, 以签名跟踪头字段。

请注意, Signer 应该认识到, 签名 DKIM-Signature 头字段可能会导致与中介的签名失败, 这些中介不认识 DKIM-Signature 头字段是跟踪头字段, 并无意中对其重新排序, 从而破坏此类签名。因此, 不建议签名现有的 DKIM-Signature 头字段, 尽管这是合法的。

信息性注释: 如果签名具有多个实例的头字段, 则这些头字段始终从下到上签名。因此, 不可能只签名特定的 DKIM-Signature 头字段。例如, 如果要签名的消息已经包含三个 DKIM-Signature 头字段 A, B 和 C, 则可以签名所有这些字段, 仅签名 B 和 C, 或仅签名 C, 但不能仅签名 A, 仅签名 B, 仅签名 A 和 B, 或仅签名 A 和 C。

Signer 可以使用不同的参数添加多个 DKIM-Signature 头字段。例如, 在过渡期间, Signer 可能希望使用两种不同的哈希算法生成签名。

Signer 不应从他们正在签名的消息中删除任何 DKIM-Signature 头字段, 即使他们知道这些签名无法验证。

在评估具有多个签名的消息时, Verifier 应独立评估签名并根据其自身的优点进行评估。例如, 根据策略选择不接受具有已弃用加密算法的签名的 Verifier 会认为此类签名无效。Verifier 可以按他们选择的任何顺序处理签名; 例如, 一些 Verifier 可能选择在其他签名之前处理与消息头中的 From 字段对应的签名。有关签名选择的更多信息, 请参阅 Section 6.1。

信息性实现注释: Verifier 尝试将有效签名与无效签名关联以猜测签名失败原因的做法是不明智的。特别是, Verifier 无法通过通用方式确定无效签名曾经有效。

Verifier 应继续检查签名, 直到签名成功验证以满足 Verifier 的要求。为了限制潜在的拒绝服务攻击, Verifier 可以限制他们将尝试验证的签名总数。

如果 Verifier 模块报告其评估产生 PERMFAIL 结果的签名, Identity Assessor 应忽略这些签名 (参见 Section 6.1), 就好像它们不存在于消息中一样。