> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of John Levine > Sent: Monday, May 23, 2011 5:41 AM > To: [email protected] > Cc: [email protected] > 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
