ietf-dkim
[Top] [All Lists]

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

2007-12-12 15:58:20
Douglas Otis wrote:

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".

A syntactically valid List-ID doesn't have the form of an email
address or Message-Id, no "@".  

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.

RFC 4409 6.1 and 8.1 won't help with "first author" constructs,
and 8.1 arguably does not yet support PRA.  But it's not an
untypical request, compare op=auth for SPF proposed by Scott.

The "all" assertion DOES NOT imply an identity associated 
with an email-addresses has been authenticated!

It implies whatever the SSP spec. says.  If it says something
in the direction of op=auth it has to state what signers are
supposed to do to enforce it.  

Such an assertion violates DKIM's charter, where DKIM is not  
sufficiently suited for such use.

It mentions the issue as out of scope, yes, but I'm not sure
if that also limits what an SSP can state.  IMO intra-domain
spoofing isn't an interesting problem, but if an MSA offers
its sending and signing services to more than one domain then
excluding "cross-user forgery" between them is relevant.

RFC 4409 has options for SPF (6.1) and a part of PRA (8.1).
Or is that beside the point ?  Actually a service provider
offering sending and signing for more than one domain has to
do something about "cross-user forgery" for DKIM, no matter
what SSP specifies.

The "all" assertion only indicates to receivers, they can 
expect all messages originating from this domain to have 
been signed.

Kind of tough if they get a message signed by the MSA, but
actually submitted by another domain (ab)using this MSA :-(
 
 Frank

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