DKIM Chair wrote:
In discussions with the IESG to sort through their "discuss" comments,
I had a talk with Lisa Dusseault, and she had one point that I want to
bring back to the mailing list: I don't think we considered, in our
discussions of multiple signatures, multiple *linked* signatures,
which could work TOGETHER to convey information, and the protocol
doesn't allow that sort of thing. The way dkim-base is set up, I
don't think this could easily be added as an extension, and it'd be a
significant change at this point. Here's the concept:
* Signer puts on two signatures (maybe as two header records, maybe as
one that contains two sigs).
* One of the signatures has minimal scope, maybe signing only "from:",
with l=0.
* The other signature covers as much of the message as possible...
most headers, all the boby.
* The two signatures work together. If one verifies and the other
doesn't, the verifier can consider what was changed in the message,
and possibly use that information to deal with mailing list
modifications or whatnot.
One way this might be used is to have one signature that covers the
subject header and one that doesn't, to allow the verifier to detect a
subject change and decide whether it's OK. As the spec is now, the
verifier would just find the one signature (that doesn't cover the
subject) that works, and use that, not considering the other.
The WG did discuss related things, so maybe we'll decide that this was
covered and dismissed, but it's a wrinkle that I want to make sure we
look at. Let's beat this around for a week or so, and see where we
are with it, and what we do or don't want to do with it.
One can already do this by copying the relevant headers into the signature
using z=. I already do this and it works just fine for mailing lists.
Since it
involves a whole boat load of heuristics, I don't think it really belongs in
the base spec which should, IMO, just define the mechanics of the protocol.
Whether we wanted to outline such strategies in a BCP seems like a
reasonable
question though.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html