[ietf-dkim] Base issue: multiple linked signatures
chl at clerew.man.ac.uk
Sat Dec 30 04:43:10 PST 2006
On Tue, 26 Dec 2006 16:36:39 -0000, Michael Thomas <mike at mtcc.com> wrote:
> DKIM Chair wrote:
>> 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.
ISTM that this sort of requirement can only arise where the original
signer has some expectation that some header WILL get altered during
transit, and wants to cover both possibilities.
> One can already do this by copying the relevant headers into the
> 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
And that was my reaction when I read this suggestion. Anything that can be
done with two signatures can probably be done as well with imaginative use
The only snag is that the draft says, of the 'z=':
Verifiers MUST NOT use the header field names or copied values for
chacking signatures in any way. ...
Whyever not? If the verifier can get soe useful infornmation out of the
'z=' (such as by restoring the 'z=' version of the header and seeing
whether that mends the broken signature, then why forbid it? Just what the
verifier might deduce from that situation I am not sure, but that is the
verifier's problem, not ours.
Here is another example where the 'z=' might actually be useful.
Under EAI, there is a header
During transit, the headers may get downgraded, thus breaking all sorts of
signatures. But, at the same time, that header gets changed to
So if the original signature recorded 'z=Header-Type: UTF8' (OK, that SP
should have been dkim-quoted, but you know what I mean) then the verifier
at least knows what has happened and do somethig intelligent (even if only
to say, "sorry, this message has been UTF8 downgraded - you will have to
resolves your suspicions yourself" - or else it might try to upgrade the
message and then try the signature again). All seemingly reasonable,
except that dkim-base syas it MUST NOT do such sensible things. Why not?
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Email: chl at clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-dkim