Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Hector Santos <[e-mail]>]

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.

If the "issue" relates to non-author domain signatures, then of 
course, I will always continue to believe we have neglected to resolve 
the 3rd party design issue from a "Fraud Protection" standpoint. Not 
the whitelisting part of that design, the blacklisting.  No one wants 
to hear that (at least here) and thats unfortunate because in all my 
engineering experience and logic tells me, that is will continue to be 
a thorn on (DKIM) side and in my view, the #1 threat to DKIM wide 
acceptance and adoption. I would think that would mean something to 
the marketing of DKIM. But thats me.

If the i= is suppose to address that Jim, then I will love to hear and 
understand it because currently I don't see how that helps.

-- 
Sincerely

Hector Santos
http://www.santronics.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html