Paul,
A question about the semantics bit.
What do we need to say about what a verifier MUST, SHOULD
or MAY do/NOT do, if sig1 has "h=foo+bar" but sig2 has "h=bar"
(or whatever other variant you prefer)?
Perhaps the right answer is "nothing": those fields are
meant for the verifier to get the crypto right, they're
not for anything else. Should we say that if we believe
it?
However, I suspect that some verifiers will tell someone
about what "h=" was when they see a single signature, in
which case should we say that such verifiers SHOULD present
info about all sigs or something. If a verifier reports
partial or confusing information there, then trouble may
well ensue. OTOH, this is close to designing an API, and
that's not generally IETF business.
There'll be variations on this question for other tags
too, e.g. "z=", "i=" and maybe more.
Stephen.
Paul Hoffman wrote:
Revised to:
- remove verification passthrough
- change the canonicalization to what is being used anyway
- removed the ordering requirement
- softened the wording about bid-down attack
---------------------
Summary:
A sender signing a message that already has one or more DKIM-Signature
headers keeps the earlier headers and signs over them.
---------------------
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 can
be done in a way to allow parallel signatures during transitions.
---------------------
Changes:
Add to section 3.5:
p= Earlier signatures (plain-text; REQUIRED if there is already one
or more DKIM-Signature headers in the message). This tag lists the
hashes of the DKIM-Signature headers that exist before this
DKIM-Signature header is added. The hash is computed using the hash
algorithm that is used in the signing algorithm (taken from the "a="
tag), using same header canonicalization on the DKIM-Signature
headers as is being used already. The order of the hashes is not
significant.
sig-p-tag = %x70 [FWS] "=" [FWS] sig-p-tag-hash
0*( *FWS ":" *FWS sig-p-tag-hash)
sig-p-tag-hash = base64string
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 signer applying multiple signatures with different signing
algorithms SHOULD first sign with the signer's 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. Note
that the recipient MAY ignore such removal, such as if the
recipient
is satisfied with the strength of the remaining signature(s).
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html