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

[Jim Fenton <[e-mail]>]

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