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
