-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Monday, May 23, 2011 5:41 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk
Subject: Re: [ietf-dkim] New canonicalizations
Could you get the effect of this by including the
Content-Transfer-Encoding header in the 'h=' and doing some fancy checks
involving the 'bh=' (to detect whether it was the body or the headers or
both that were broken)?
No, of course not. The bh= and h= are just hashes, so all they can
tell you is whether the text being hash has changed, not how the body
has changed or which header changed. There's no separate hash for
individual header lines.
On the other hand, you might want to look at page 24 of RFC 4871.
If one were to encode somehow an extension indication that "this content was
subjected to 8-to-7 downgrade" as a hint that a verifier should do the reverse
before verifying, the verifier would have to manage to undo the downgrade in
precisely, i.e. byte-for-byte, the same manner that the downgrade was done for
it to work. That's a pretty high requirement for interoperability (i.e., it's
pretty error-prone), so it requires a specification and it would need to be
consistent with the MIME RFCs.
So assuming it's a useful endeavour, it seems to me there's a lot of work to be
done here. Our latest report says Content-Transfer-Encoding changes aren't
even in the top ten header field changes invalidating signatures, which means
there aren't that many downgrades happening, so this probably isn't a
significant problem right now. I don't really think this is worth the effort.
It also seems to me it would be easier to either do what the RFC says and
downgrade before signing, or perhaps if you're super-keen about it, generate a
signature for the 8-bit form and the downgraded form; if no downgrade occurs,
the 8-bit form will pass, and if one does, the 7-bit form will pass (all other
things being equal). But then there are those people that want to penalize
invalid signatures despite the advice of the RFC, so you'd have that to deal
with.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html