Subject: Re: [ietf-dkim] Consensus point on ADSP

From: Dave CROCKER <[email-masked]>
Date: Wed, 01 Apr 2009 13:38:14 -0700

John Levine wrote:
>> 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.
> 
> That's not fine, since we've just gone around and agreed that the
> signing identity is d=.  leave this paragraph out.

Yes, please, on two counts:

1.  The definitions that the group has just agreed to no longer calls i= a 
signing domain of any sort.  I am hoping that no one is suggesting that ADSP 
redefine core constructs of the revised DKIM signing specification.

2.  By its nature, ADSP imposes some constrain on DKIM use.  It is, after all, 
defining an equivalence between a DKIM value and a RFC5322.From value.  The 
question is which DKIM value.  As soon as there is ANY equivalence with the From 
field, a number of scenarios will be incompatible.  The one that Jim is citing 
is just that:  merely one.  And it's one that might not be correct (see below.) 
  If we are going to add an Informative Note like he is suggesting, we are going 
to have to do an extensive audit to make sure we cover all of the implications 
-- and there really will be more than just this one.  I don't see the benefit of 
doing that and suggest, instead, we leave off such efforts at being selectively 
helpful.

As for possibly not being correct, the phrase "parend domain is signing for a 
subdomain" hinges on the "for".  It goes to intent as well as implying some 
details about the i= value that well might not be applicable.  Yet DKIM does not 
specify that anything about deeper semantics, such as intent, about the 
relationship between SDID and AUID values.  So, again, we would do well not to 
rely on any particular ones.

In general, I suggest that suggestions for interpreting DKIM start by explaining 
how a receiver is going to know that that explanation holds true.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html