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

[Stephen Farrell]

Paul Hoffman wrote:
> 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.

Is that really a SHOULD? How could it be tested? Perhaps "should"
is ok in this case.

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

That looks pretty good.	

>>     Signers MUST NOT remove any DKIM-Signature headers from messages
>>     they are signing, even if they know that the headers cannot be
>>     verified.

Is MUST NOT ok there, as opposed to SHOULD NOT? I seem to recall someone
wanting to be able to remove signatures to hide internal structure. Not
sure if that was on the list or not, and it does seem a little bit of a
corner case (one could in any case wriggle out of the problem by saying
it wasn't the signer that removed the sig, but it was some other bit of
code:-) No real opinion myself, just asking.

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

If no-one wants to insist on signatures having to be sequential,
then this could be fairly easy!

S.