Charles Lindsey:
That was quite some time ago, so to refresh your memories, I had been
claiming that DKIM-base would fail to verify if some message had its
Content-Transfer-Encoding changed en route, and that it proposed to get
around this by saying that all messages SHOULD be sent as 7bit, or encoded
into 7bit. In these days when 8BITMIME is now almost universally supported
and widely used (with BINARYMIME coming along as well), that seemed to be
a very backward step. So I proposed a canonicalization that would reverse
all those encodings before hashing.
...
So it was an issue of whether such a canonicalization really would be
"orders of magnitude more complicated". Anyway, I have been working off
and on on this since then, and I have written a demonstration
implementation, as promised, of what it would take, which you can find at
<http://www.cs.man.ac.uk/~chl/uncode/uncode.html>.
It is less that 140 lines of Perl (excluding comments and empty lines).
Hardly any "orders of magnitude" in evidence there.
Actually, it's 128 lines. But that's a minor detail.
With real production MTAs such as Sendmail and Postfix, the MIME
processor takes about 900 lines of C code (sans comments, formatted
in the K&R coding style). That's 900 lines of opportunity for error.
My concern is about interoperabilitity. With the present design,
senders and recipients who exchange QP or Base64 content only need
bug-compatible MIME processors in their respective MUAs.
When DKIM signers and verifiers are requird to up-convert QP or
Base64 content before computing signatures, we also require that
all DKIM signers and verifiers have bug-compatible MIME processors.
That is, bug-compatible with every MUA.
Introducing this extra requirement is unlikely to help with the
successful adoption of DKIM.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html