[ietf-dkim] Alternative text for semantics of multiple signatures

[Paul Hoffman]

At 1:09 PM -0700 4/4/06, Michael Thomas wrote:
>[transmogrified from Paul's original text]
>
>>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.
>
>Change section 4 to read:
>
>     4.  Semantics of Multiple Signatures
>
>     A signer that is adding a signature to a message merely creates
>     a new DKIM-Signature header, using the usual semantics of the
>     h= option. A signer MAY sign previously existing DKIM-Signature
>     headers using the method described in section NN to sign trace
>     headers. Signers should be cognizant that signing DKIM-Signature
>     headers may result in signature failures with intermediaries that
>     do not recognize that DKIM-Signature's are trace headers and
>     unwittingly reorder them.
>
>     When evaluating a message with multiple signatures, a receiver
>     SHOULD evaluate signatures independently and on their own merits.
>     For example, a receiver that by policy chooses not to accept
>     signatures with deprecated crypto algorithms should consider such
>     signatures invalid. As with messages with a single signature,
>     receievers are at liberty to use the presence of valid signatures
>     as an input to local policy; likewise, the interpretation of
>     multiple valid signatures in combination is a local policy
>     decision of the receiver.
>
>     Signers MUST NOT remove any DKIM-Signature headers from messages
>     they are signing, even if they know that the headers cannot be
>     verified.

This works for me, as long as people are not worried about reordering 
of multiple DKIM-Signature headers in messages where the signer has 
included those headers in h=. If people are concerned about 
reordering of DKIM-Signature headers under a signature, then this 
change is insufficient on a technical level.