[ietf-dkim] Revised proposal for specifying syntax and semantics for multiple signatures

[Stephen Farrell]

Paul Hoffman wrote:
> At 5:27 PM +0100 4/4/06, Stephen Farrell wrote:
>> Currently "h=foo" is usable to say "I didn't sign foo cause it
>> wasn't there" (or some better wording), effectively meaning
>> that if someone adds a foo header field then the sig breaks.
>>
>> Ought your proposal make reference to this, even if only
>> to include a reminder that making use of this feature/trick
>> is liable to be problematic if such a field is likely to be
>> added by a later MTA/signer?
> 
> No, because it doesn't seem related to signing the DKIM-Signature 
> header. There is no sensible way to use DKIM-Signature in h= to indicate 
> "there will be no future DKIM-Signature headers".
> 
> Maybe I'm misunderstanding your question.

I think so.

Take some list related header field and two signers - the 1st signer
being the 1st outbound MTA and the 2nd signer being the list s/w (or
some other adjacent signer, whatever).

For some reason the originator doesn't want that list header field to
be signed, so he puts "h=<<list-field>>" even though there's on such
header on the message he signed.

Later the list adds a list-field header field and then adds its
signature (over whatever header fields, doesn't matter).

Now, as I understand it, its guaranteed that the 1st signature will
not verify. The second will, or won't, depending on the usual stuff.

My question was whether or not a reminder about this behaviour
would be useful.

S.