Hector Santos wrote:
Jim Fenton wrote:
There remains some disagreement on whether the "informative note"
contained in the last paragraph of the text I proposed on March 27
should appear in the ADSP draft. The note said:
Informative Note: ADSP is incompatible with DKIM signing by parent
domains described in section 3.8 of [RFC4871] in which a signer uses
"i=" to assert that a parent domain is signing for a subdomain.
This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.
Thus far, I feel it should be included and John Levine and Dave Crocker
feel it shouldn't. May we have guidance from others in the Working
Group, please?
My input:
Maybe I don't quite see the issues, but I've been doing more testing
later to see how this is all going to fit, and there seems to be a
need to deal with issues for the high potential cases:
1) same primary domain name spaces
From: user @ subdomain.primary-domain.com
DKIM-Signature: d=primary-domain.com
or
From: user @ primary-domain.com
DKIM-Signature: d=subdomain.primary-domain.com
2) "3rd party" or non-author domain name space
From: user @ primary-domain.com
DKIM-Signature: d=some-other-domain.com
As far as the i= is concern, as long as the h= binds the From: header
(as it must per 4871) the i= appears to me as an "extra" bit of
information that is not required for DKIM 4871 verification.
Lacking applications for usage, I don't see how i= "helps". I think I
understand some people want to use it as feed to some future or
current trust service in the works. But I see that as gravy information.
Since there is indeed no defined application for the i= value, "gravy
information" is not a bad description. Nevertheless, Section 3.8 of RFC
4871 says that it's possible to sign messages where the domain part of
the i= value is a subdomain of the d= value, which of course it is. But
since such a signature won't serve as an Author Domain Signature in ADSP
(when the From address is in the subdomain), I think it's important that
the ADSP specification point that out.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html