-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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