4. Semantics of Multiple Signatures

4.1. Example Scenarios

There are many reasons why a message might have multiple signatures. For example, suppose SHA-256 is in the future found to be insufficiently strong, and DKIM usage transitions to SHA-1024. A Signer might immediately sign using the newer algorithm but also continue to sign using the older algorithm for interoperability with Verifiers that had not yet upgraded. The Signer would do this by adding two DKIM-Signature header fields, one using each algorithm. Older Verifiers that did not recognize SHA-1024 as an acceptable algorithm would skip that signature and use the older algorithm; newer Verifiers could use either signature at their option and, all other things being equal, might not even attempt to verify the other signature.

Similarly, a Signer might sign a message including all header fields and no "l=" tag (to satisfy strict Verifiers) and a second time with a limited set of header fields and an "l=" tag (in anticipation of possible message modifications en route to other Verifiers). Verifiers could then choose which signature they prefer.

Of course, a message might also have multiple signatures because it passed through multiple Signers. A common case is expected to be that of a signed message that passes through a mailing list that also signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources.

In particular, recipients might choose to whitelist mailing lists to which they have subscribed and that have acceptable anti-abuse policies so as to accept messages sent to that list even from unknown authors. They might also subscribe to less trusted mailing lists (e.g., those without anti-abuse protection) and be willing to accept all messages from specific authors but insist on doing additional abuse scanning for other messages.

Another related example of multiple Signers might be forwarding services, such as those commonly associated with academic alumni sites. For example, a recipient might have an address at members.example.org, a site that has anti-abuse protection that is somewhat less effective than the recipient would prefer. Such a recipient might have specific authors whose messages would be trusted absolutely, but messages from unknown authors that had passed the forwarder's scrutiny would have only medium trust.

4.2. Interpretation

A Signer that is adding a signature to a message merely creates a new DKIM-Signature header, using the usual semantics of the "h=" option. A Signer MAY sign previously existing DKIM-Signature header fields using the method described in Section 5.4 to sign trace header fields.

Note that Signers should be cognizant that signing DKIM-Signature header fields may result in signature failures with intermediaries that do not recognize that DKIM-Signature header fields are trace header fields and unwittingly reorder them, thus breaking such signatures. For this reason, signing existing DKIM-Signature header fields is unadvised, albeit legal.

INFORMATIVE NOTE: If a header field with multiple instances is signed, those header fields are always signed from the bottom up. Thus, it is not possible to sign only specific DKIM-Signature header fields. For example, if the message being signed already contains three DKIM-Signature header fields A, B, and C, it is possible to sign all of them, B and C only, or C only, but not A only, B only, A and B only, or A and C only.

A Signer MAY add more than one DKIM-Signature header field using different parameters. For example, during a transition period, a Signer might want to produce signatures using two different hash algorithms.

Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified.

When evaluating a message with multiple signatures, a Verifier SHOULD evaluate signatures independently and on their own merits. For example, a Verifier that by policy chooses not to accept signatures with deprecated cryptographic algorithms would consider such signatures invalid. Verifiers MAY process signatures in any order of their choice; for example, some Verifiers might choose to process signatures corresponding to the From field in the message header before other signatures. See Section 6.1 for more information about signature choices.

INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate valid signatures with invalid signatures in an attempt to guess why a signature failed are ill-advised. In particular, there is no general way that a Verifier can determine that an invalid signature was ever valid.

Verifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the Verifier. To limit potential denial-of-service attacks, Verifiers MAY limit the total number of signatures they will attempt to verify.

If a Verifier module reports signatures whose evaluations produced PERMFAIL results, Identity Assessors SHOULD ignore those signatures (see Section 6.1), acting as though they were not present in the message.