Murray S. Kucherawy wrote:
> 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.
The idea was to only do it for certain situations, i.e. when converted
to base64. Since a unbase64 function is already in your DKIM
repertoire, no extra library is require and it would be one additional
conditional statement.
> 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.
+1 (on the last sentence)
How would 7/8 bit be considered?
Personally, the STRIP C14N idea would work just fine by removing all
trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm
considering updating my 2006 I-D to include the QP decoding logic.
This, along with the et= idea, it would address at least three
additional cases I have encountered.
- MLM that add an extra line at the top (possibly because of any
empty
header file of size 2, crlf)
- Intermediaries that expand QP to 8 bit
- Intermediaries that reformat to BASE64
I personally have not seen anything else.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
