[ietf-dkim] DKIM errata 1532 and 1596
Murray S. Kucherawy
msk at cloudmark.com
Fri Jul 23 19:50:13 PDT 2010
I'm not clear on the objection here. In particular, it seems to me Barry's proposed language lines up nicely with what you said starting "but rather".
As for the statement that the result would be undefined, I'm also unclear. Are you saying two different implementers might do two different things because of that MAY? If that's the case, then I think we're in some trouble because (for example) there's a MAY in the definition of "x=" that permits two results if the signature has expired.
From: ietf-dkim-bounces at mipassoc.org [ietf-dkim-bounces at mipassoc.org] On Behalf Of Jim Fenton [fenton at cisco.com]
Sent: Friday, July 23, 2010 3:43 PM
To: barryleiba at computer.org
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM errata 1532 and 1596
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
for a discussion of this. The error we're talking about here is
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
NOTE WELL: This list operates according to
More information about the ietf-dkim