-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Wednesday, March 11, 2009 2:13 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe
errataafter the consensus call
On Mar 11, 2009, at 10:15 AM, Dave CROCKER wrote:
Isn't it much simpler, and entirely sufficient, to have ADSP use
SDID (d=)?
I am not understanding the downside to the choice.
The alternatives all seem significantly more complicated and
probably problematic.
100% agreed. : ^)
Depending upon the interpretation given for Section 3.2 of ADSP, any
valid DKIM signature from the Author Domain may omit ADSP record
transactions.
The only logic for requiring either a DKIM signature that lacks an i=
value, or one that matches against the From header, would be there is
something special about a DKIM signature that lacks the i= value.
There does not appear to be any rational semantics to explain what is
implied when the i= value is missing. On that point, Dave is correct.
You are incorrect Doug. Look at RFC4871:
If the DKIM-Signature header field does not contain the "i=" tag, the
verifier MUST behave as though the value of that tag were "@d", where
"d" is the value from the "d=" tag.
There is nothing special about a DKIM signature missing an i= filed. One
simply uses the d= field. Seems pretty straight forward to me.
Since the ADSP draft is already internally in conflict on this point,
a simple solution would be to drop the i= value requirement in ADSP.
I see no conflict.
If the DKIM i= value becomes defined as always being opaque, then ADSP
will need to define some other tag to introduce a non-opaque namespace
if DKIM is to be seen a method to affirm an email-address. Defining
i= values as always being opaque is not really needed. After all, a
valid signature does indicate the entity applying the signature is
acting on behalf of the owners of the email-address namespace.
<SNIP>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html