At 08:00 16-06-2009, Cullen Jennings wrote:
My focus is mostly on what this errata means to implementations in the
field. That would be implementations of both DKIM the narrow signing
protocol and implementations that use the information DKIM provides. I
think the document should be clear on
The proposed update does not affect the DKIM verification
process. It can affect the DKIM signing process and the
post-verification process. I'll use your message as an example. The
DKIM-Signature header for your message contains "d=cisco.com;
i=fluffy(_at_)cisco(_dot_)com;" According to RFC 4871, the domain is taken
from
the "i=" tag and in the absence of that tag, we fallback to the "d="
tag. For this message, we would use "cisco.com" for the
assessment. I'm taking a narrow view of the assessment.
It was pointed out that some DKIM signers use a DKIM-Signature header
such as "d=example.com; i=fluffy1(_at_)core5(_dot_)example(_dot_)com;".
According to
RFC 4871, we would use "core5.cisco.com" as the domain for the
assessment. With the proposed update, the "i=" tag and the fallback
behavior is ignored. We use "example.com" for the assessment.
Some DKIM signers may have to change the way they were signing
messages if they are passing domain related information through the
"i=" tag instead of the "d=" tag. The DKIM post-verification process
also has to be modified to pass the domain from the "d=" tag instead
of the one from the "i=" tag.
1) what is the interoperability problem. Can someone succinctly
See the above example.
summarize this? When I read the document, I get that there is a
problem but it less clear what it is or why some implementation would
end up doing something that did not work with other implementations.
Some people got creative. :-)
2) what needs to be changed in implementations to fix this? Again, can
anyone succinctly summarize this. I do not think an implementor that
See the above example.
did not follow the list could easily read the current draft and figure
out if there code was OK or not and what changes where needed to their
code to make it OK
To keep it simple I'd say "use the d= tag only".
I'm not really sure what you mean by a reputation intent and non-
repuation intent or when a signer or verifier would want one or the
other.
reputation intent - help us blacklist, whitelist you, etc.
non-reputation intent - the DKIM signer placed some obfuscated
information in the "i=" and it was probably not meant to be used for
reputation.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html