Re: [ietf-dkim] Issue #1524: Signature semantics

On Dec 12, 2007, at 9:42 AM, Jim Fenton wrote:

> If their web form didn't block the use of example.com as a From  
> address, the message would be non-Suspicious (I think that's what  
> you mean by "compliant" in this context), which would violate the  
> likely intent of the publication of SSP "all".  They could deal with  
> this in several ways:
> - Prohibit example.com from being used in the web form
> - Sign using a different domain or a subdomain, e.g.,
> i=(_at_)articles(_dot_)example(_dot_)com
In this case, "articles.example.com" will obscure which header the  
signature had been added "on-behalf-of".  If the signing domain was  
also "articles.example.com", this would be a third-party signature and  
might make the message somewhat questionable.  Mailing-list may sign  
"on-behalf-of" the List-ID header, where any email-address might be  
allowed in the From header (common for many mailing lists).  The  
mailing-list may wish to exclude the list-id email-address from being  
allowed within the From header to prevent confusion as to which header  
the message was signed "on-behalf-of".  The domain may not care  
whether an ambiguous "on-behalf-of" causes confusion.  The email- 
address could be that of some innocuous role that is never used for  
other messages, where the Subject line also clearly indicates that the  
message is from a list.
> - If comparison of the local-part of the address continues in the  
> draft, sign with a specific address, e.g., i=articles(_at_)example(_dot_)com,  
> and have the web form prohibit that specific address

A domain can be completely compliant with an "all" assertion _without_  
prohibiting specific email-address from being signed!  A mailing-list  
is often unable to authenticate identities, even those signed by  
DKIM!  DKIM is _prohibited_ in the charter from asserting identities,  
nor would identity authentication represent a safe assumption.   
Defaults allowed for the i= parameter permits an "on-behalf-of" header  
to remain ambiguous.  While some domains may wish to prevent intra- 
domain spoofing by employing email-address constraints, such  
constraints are not typically, nor is this defined for use with DKIM.
When a message contains a header where the From contains an email- 
address within the signing domain, acceptance depends upon internal  
signing domain policies.  The "all" assertion DOES NOT imply an  
identity associated with an email-addresses has been authenticated!   
Such an assertion violates DKIM's charter, where DKIM is not  
sufficiently suited for such use.  DKIM lacks a means to distribute  
per-user keys, lacks any mandate regarding identity authentication,  
mechanisms to restrict email-address use, etc.   Procedures and  
policies to restrict the use of email-addresses, and whether messages  
are permitted to include From headers containing other email-addresses  
within the domain is completely a matter of internal policy.  This  
internal policy has nothing to do with an "all" assertion.  The "all"  
assertion only indicates to receivers, they can expect all messages  
originating from this domain to have been signed.
Ensuring who can use an email-address is an entirely different problem  
unrelated to "all" or "strict" policy assertions.  Attempting to  
extend DKIM in this manner appears to violate the charter as well.
-Doug



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