[ietf-dkim] Revised proposal for specifying syntax and semantics for multiple signatures

[Stephen Farrell]

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
>