Paul,
Another (littler) question, nearly a nit.
Currently "h=foo" is usable to say "I didn't sign foo cause it
wasn't there" (or some better wording), effectively meaning
that if someone adds a foo header field then the sig breaks.
Ought your proposal make reference to this, even if only
to include a reminder that making use of this feature/trick
is liable to be problematic if such a field is likely to be
added by a later MTA/signer?
Stephen.
PS: Out of interest - is anyone planning to use that trick?
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