> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Monday, May 23, 2011 2:21 AM > To: DKIM > 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)?
I don't think so, because a re-encoding causes a change to Content-Transfer-Encoding itself, which in turn changes both hashes, not just one of them. You could use an extension tag to capture the original Content-Transfer-Encoding as a hint to the canonical form that was signed, but that means the verifier has to undo the conversion before computing the hashes, and it has to do that bytewise precisely as well as reconstructing the original MIME header fields. Getting that even a byte off (modulo "relaxed") means you're toast. At that point I suspect you may as well bite the bullet and start down the road of defining a new canonicalization that accommodates possible downgrades in transit, picking either 7-bit or 8-bit as the canonical form, and feeding that form to the hash to be used in signature generation. But once you consider that a multipart can have some 7-bit and some 8-bit, this can get real messy real fast. Once this becomes an actual problem, I imagine MIMEAUTH will start to get even more interesting. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html