[ietf-dkim] Re: Third-Party Signature Authorizations and Email-Address R

On Nov 28, 2007, at 3:00 PM, Jim Fenton wrote:

> Douglas Otis wrote:
> > The question is who taking responsibility and for what?
> >
> > Does the signing domain indicated From email-address use is  
> > restricted?  If so, this could then shift content responsibility  
> > onto the From email-address identity.  If not, the signing domain  
> > is only responsible for permitting some unknown users access.   
> > Clearly, granting access says very little about content.  Just  
> > granting access without email-address restrictions requires  
> > reputations to be based upon a collective behaviour of users to  
> > which they grant access.
> SSP does, indeed, deal specifically with the From email address.  I  
> have no idea what this might have to do with responsibility for  
> content.
All headers are found in message content.  DKIM is unrelated to the  
envelope.
An identity associated with an email-address within message content  
should not be assumed authenticated when a signing domain matches an  
email-address domain found within the From, Sender, or Resent-*  
headers.  After all, asserting an SSP "ALL" might be to mitigate  
spoofing complaints caused by messages submitted from other domains.
Signatures may only assure recipients where the particular message had  
been submitted, but not whether the identity of the email-address  
matching the domain of the signature has been authenticated.  This is  
what was meant by not being responsible for content.
A DKIM signature may only attest to the domain's stewardship at  
excluding access to those who spam (spamming is a behaviour unrelated  
to content).  Excluding access does not require the authentication of  
email-address identities.  The account used for access and the email- 
addresses submitted are often independent items.  There are ways these  
two items can be joined, but normally they are not.  See Frank's note.
> Let me state it differently then:  If you're publishing an SSP  
> record other than "unknown", make sure you're not applying an  
> Originator Signature to spoofed mail.
Your use of "Originator Signature" seems to imply a signature that  
contains a matching i= parameter and a domain or parent domain d=  
parameter of the email-address found within the From header.
Per SSP draft:
,---
| The "Originator Address" is the email address in the From header
| field of a message [RFC2822], or if and only if the From header field
| contains multiple addresses, the first address in the From header
| field.
'---

A mailing-list can easily conform to an SSP "ALL" policy and yet sign  
messages containing From headers where the owners of email-addresses  
have not been authenticated.  Adding scope that specifically asserts  
authentication could be useful.  I assume you mean the i= parameter  
should not include the localpart.  There is a corner case for a  
semantic that asserts when i=localpart, this means the associated  
identity has been authenticated.  The problematic case would be with  
g= wildcard restricted keys.  For these keys, i= localpart inclusion  
becomes _necessary_, even when the identity associated with the  
localpart is not authenticated.
> > In other words, use of From email-addresses has been restricted to  
> > authenticated owners.  What happens when they wish to send a  
> > message where a user is not authenticated, but where use of some  
> > critical email-addresses are restricted.  There are currently no  
> > existing semantics to permit a mixed assertion, however actual use  
> > is likely to confront such a mixture.  And this must include  
> > assertions about third-party domains (which includes sub-domains).
> I'm not sure what "restricted" means, but I suppose I'll find out  
> when I read your draft.
You typically make an indirect assertion regarding whether an  
Originator Address is "valid".  I interpret this to be saying that the  
provider restricts signing email-addresses where the localpart is  
contained within the i= parameter to specific authenticated  
identities.  (Perhaps these identities would be defined as those who  
have exclusive access to a mailbox associated with the email- 
address.)  The TPA-SSP draft defines the "-i" suffix added to the  
"scope=" parameter to assert identities for the scoped headers are  
authenticated.  The TPA-SSP draft assumed rules regarding which header  
was signed will apply when the signing and email-address domains  
match.  There are two different scopes for message content, the  
(F)rom, and (O)ther being the Sender, or Resent-* headers.   Only when  
the From header is signed by a third-party domain would the TPA-SSP  
scope indicating authentication of identities become critical for  
domain parity.
-Doug




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