On Tue, 26 Dec 2006 16:36:39 -0000, Michael Thomas <mike(_at_)mtcc(_dot_)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
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.
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
of 'z='.
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
Header-Type: UTF8
During transit, the headers may get downgraded, thus breaking all sorts of
signatures. But, at the same time, that header gets changed to
Header-Type: downgraded
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
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html