[ietf-dkim] Base issue: multiple linked signatures
mike at mtcc.com
Tue Dec 26 08:36:39 PST 2006
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.
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
More information about the ietf-dkim