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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html