At the DKIM Interoperability Event in Dallas a couple of weeks ago I was
nominated as scribe during the discussions among the participants about
what parts of RFC4871 people found troublesome. This is the distillation
of those notes. They should be considered for possible inclusion in a
future "DKIM Errata" draft, if any.
1. "s=" in key records: There is no explicit guidance about what to do
with clearly bogus values. Examples given:
s=*:email
s=foo:email:bar
The normative text covering "s=" doesn't say what to do if one of the
colon-separated words is a word not enumerated in the "currently defined
service types". It also doesn't specify what to do with absurd values
like the first example. The consensus is to ignore any colon-separated
value not recognized and only pay attention to "*" and "email" for DKIM
e-mail implementations.
2. Empty bodies: Although the "simple" body canonicalization says
precisely what to do in the case of an empty message body, "relaxed" does
not. The consensus is that the "relaxed" body canonicalization of the
null body is the null input, but it was conspicuous that "simple" was
explicit while "relaxed" was not.
3. Multiple replies to TXT records: RFC4871 defines the handling of such
cases as "undefined", but it still came up in conversation several times.
Also noteworthy is that SSP has not yet added any discussion on this
topic.
4. Empty local parts can be problematic: RFC4871 discusses the "g=" (key)
vs. "i=" (signature) comparison including the default for the local-part
to be used when "i=" is undefined, but it's possible a signer could
explicitly say "i=(_at_)example(_dot_)com" and there's no way for "g=" to match that
other than using a wildcard (or the default).
5. "x=" must be compared to a local time base instead of to "t=": I'm not
remembering the context about why I was asked to include this, so maybe
someone can refresh my memory here.
6. "h=" (key) vs. "a=" (signature): One participant felt the requirement
to corellate these two values was not sufficiently normative.
7. There is insufficient guidance about whether the domain in "i=" or the
domain in "d=" should be used when generating a domain reputation query
based on a DKIM signature verification. At the end of this discussion,
participants were asked to think about this and try to generate language
for inclusion in later specifications to provide such guidance.
--
Murray S. Kucherawy =========================================
msk(_at_)sendmail(_dot_)com
Principal Engineer Sendmail, Inc. Emeryville, CA, USA
(510) 594-5400 http://www.sendmail.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html