Fwd: Re: [ietf-dkim] Introducing myself
dhc at dcrocker.net
Wed Dec 6 09:51:30 PST 2006
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
That said, as Stephen notes, anyone is of course free to write an Internet-Draft
proposing additional schemes.
More information about the ietf-dkim