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

[Stephen Farrell]

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
>