Wietse Venema wrote:
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
...
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.
Canonicalization has been recognized as a *very* challenging topic for at least
15 years of Internet mail work. It was a major focus for MIME, it was a major
focus for DomainKeys and it was a major focus for DKIM. (I'm sure it's been a
major focus elsewhere, but this list will suffice.)
My own summary is that we know we can trade between high qualitysimplicity and
robustness/fragility. There seems to be no perfect choice.
This invites infinite discussion. We should decline the invitation.
DKIM permits more than one canonicalization scheme to be defined. The current
set is the result of lengthy discussion and even experience. As Stephen notes,
the list can be extended, without requiring that we replace any existing entry.
If the current set proves problematic *in the field* then we can add more...
later.
We most certainly do *not* need to add consideration of additional schemes to
the current public discussion, given that the focus now should be on adoption
and use of the current specification that has benefited from a couple of years
substantial effort.
That said, as Stephen notes, anyone is of course free to write an Internet-Draft
proposing additional schemes.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html