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

[Michael Thomas]

[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.

		Mike