[ietf-dkim] Base issue: multiple linked signatures

[Michael Thomas]

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