Barry Leiba wrote:
----------- 1532
What Tony says is not consistent with the WG consensus, which was NOT
to REQUIRE the presence of "v=DKIM1", and the text (Tony's "N/A"
notwithstanding) makes it clear that the absence of v= is interpreted
as "v=DKIM1".
He's correct, though, that the intent was for the DKIM key record to
be backward compatible with DK (RFC 4870, Historical), but that the g=
tag screws that up. Perhaps what would be correct to say is this,
added after the g= paragraph and before its ABNF:
Exception: if "g=" is specified with an empty value AND there is NO "v="
specified at all, implementations MAY interpret this in the context of
DomainKeys [RFC4870], treating it as DKIM's "g=*".
I disagree with this proposed resolution. I don't interpret backward
compatibility as meaning that every DK selector must be usable with
DKIM, but rather that it should be possible for the same selector record
to be used by both DK and DKIM.
In any case, the change you're proposing introduces an ambiguity in the
specification: Under the circumstances cited, the verification result
from DKIM is undefined. That's a poor statement for a standard to make.
It's true that key records with empty g= values do contribute to
verification failures; see
http://blogs.cisco.com/security/comments/common_errors_causing_dkim_verification_failures/
for a discussion of this. The error we're talking about here is
"inapplicable key".
As the discussion notes, there's an ESP out there that is giving their
customers key records to publish that have empty g= values. Yesterday,
this single ESP accounted for 72% of all the Inapplicable Key errors we
saw at Cisco. I contacted this ESP last fall, and they have not
corrected the problem.
There are lots of other syntax errors we see as well. I don't think
it's worth introducing an ambiguity in the specification to compensate
for an easily correctable problem. Do we next introduce a change in the
spec to compensate for those that are publishing key records with
extraneous backslashes?
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html