ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe errataafter the consensus call

2009-03-11 19:48:21

On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote:
On Mar 11, 2009 11:12 AM, Douglas Otis wrote:

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.

A signature lacking an i= value defaults to the d= value, but this  
does not represent a From email-address!   As someone said, domains do  
not write emails, which leaves the "on-behalf-of" identity *undefined*.

There is nothing special about a DKIM signature missing an i= filed.  
One simply uses the d= field. Seems pretty straight forward to me.

Why must an i= value only represent a From email-addresses when  
present, when it is equally okay for the i= value to be omitted?  When  
a DKIM public key imposes a g= restriction, the i= value MUST contain  
the restricted local-part or the DKIM signature WILL NOT be valid.    
It will be evident to an MUA whenever a restricted local-part does not  
match against a From header.  It should also be safe for an MUA to  
annotate signed headers that match against the i= value, but not those  
that do not match, such as when the i= value is omitted or it omits  
everything but the d= value.  In such cases, just the domain might be  
annotated.

In either case, the i= value (on-behalf-of identity) might become  
declared as being opaque and thus defined as not representing a  
specific email-address.  When the i= value is declared opaque, no  
email-address should be annotated, even when it happens to match  
against the i= value.

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.

Oops.  This has been corrected off-list since version 6.  Section 3.2  
now states Author Signature.  Well, Section 3.2 will need to change  
back to Author Domain if or when i= value dependence is removed.

By removing the i= dependency from ADSP, the assertions of "all" or  
"discardable" could then apply to any DKIM signature by the domain.

-Doug

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

<Prev in Thread] Current Thread [Next in Thread>