Greetings again. This follows up on the desire to allow multiple
signatures in the same message.
---------------------
Summary:
A sender signing a message that already has one or more DKIM-Signature
headers keeps the earlier headers, signs over them, and optionally says
whether or not they were verified before signing.
---------------------
Rationale:
Signers need a way to attach multiple signatures when transitioning from
one signature algorithm to another, when transitioning from one hash
algorithm to another, and even from one protocol version to another.
Further, there are many scenarios where a sender is forwarding a message
that is already signed, and wants to add its own signature. This must
be done in a way to prevent bid-down attacks during transitions, and
also must be done in a way so the recipient can unambiguously determine
the order in which the signatures appeared.
---------------------
Changes:
Add to section 3.5:
p= Earlier signatures (plain-text; REQUIRED if there is already one
or more DKIM-Signature header in the message). This tag lists the
hashes of the DKIM-Signature headers that exist before this
DKIM-Signature header is added, possibly adding the result of a
verification of done by the party creating the current
DKIM-Signature header. The hash is computed using the hash algorithm
that is used in the signing algorithm (taken from the "a=" tag),
using "simple" header canonicalization on the DKIM-Signature header.
The signer MAY include an indication of whether or not a particular
DKIM-Signature header was verified; the absence of this indication
is interpreted by the recipient that the verification was not
performed. The order of the hashes MUST be from the last
DKIM-Signature header in the message to the first.
sig-p-tag = %x70 [FWS] "=" [FWS] sig-p-tag-body
0*( *FWS ":" *FWS sig-p-tag-body)
sig-p-tag-body = sig-p-tag-hash [ "," sig-p-tag-result ]
sig-p-tag-hash = base64string
sig-p-tag-result = "verified-ok" / "verified-failed"
/ "not-verified" / x-sig-p-tag-result
Change in the "h=" description of section 3.5:
OLD:
The field MUST NOT include the DKIM-Signature header field that is
being created or verified.
NEW:
The field MUST NOT include any DKIM-Signature header field.
Change section 4 to read:
4. Semantics of Multiple Signatures
A signer that is adding a signature to a message inherently signs
all DKIM-Signature headers that exist in the message before the new
signature using the "p=" tag. If a single signer adds multiple
signatures, such as using different signing or hashing algorithms,
each signature stands on its own, meaning each signature covers all
of the previous signatures, even ones from the same signer.
A receiver can always determine the order in which the signatures
were applied based on the "p=" tag. If the tag is absent, that
signature is the first signature on the message. If the tag is
present, the number of hashes in the value indicate how many
signatures were present before this signature was applied.
A signer applying multiple signatures with different signing
algorithms SHOULD first sign with its most-preferred algorithm, then
with the next-most-preferred, and so on. This ordering prevents an
attacker from removing more-preferred signatures from a message
without the recipient being able to detect the removal.
Signers MUST NOT remove any DKIM-Signature headers from messages
they are signing, even if they know that the headers cannot be
verified. Doing so would break the chain of signatures.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html