[ietf-dkim] 1360: ssp-requirements-01 // Designated Signing Domain Scenario missing

Stephen Farrell stephen.farrell at cs.tcd.ie
Wed Oct 11 07:06:54 PDT 2006


There was also clear opposition in the jabber to including this.

However, on balance I don't feel comfortable saying where the
consensus lies here, so I've asked Barry to look over the logs
and list to see what he thinks,

Stephen.

Douglas Otis wrote:
> https://rt.psg.com/Ticket/Display.html?id=1360
> 
> There has been support on the list for ensuring a designated signing 
> domain mode of operation be retained as a viable option.  This added 
> scenario clarifies that policy is able to make such designations.
> 
> Policy's designated signing domains can independently indicate that:
> 
> 1) the signature is valid for the referenced email-address.
> 
> 2) the referenced email-address is also valid.
> 
> This ability to designate a signing domain enables these two modes of 
> operation, where the first mode does not modify how the MSA operates.  
> The first mode thus enables simpler compliance with an "all messages are 
> signed" assertion while allowing free use of outside providers.  This 
> would also be a continuation of 1359.  This mode of operation eliminates 
> ISP coordination and specialized services for each email-address domain 
> owner.
> 
> 
> Designated domains over delegation offer significant advantages:
> 
> 1) the domain authenticating outbound access and signing the
>    message is identified.
> 
> 2) abuse reporting is directed to the affected and actionable
>    domain.
> 
> 3) no additional administration is required for "all messages
>    are signed" compliance.
> 
> 4) private keys are never transferred to or held by a third-party.
> 
> 5) validated email-addresses are bound to the access-account
>    rather than the domain-owner's keys when asserting the
>    email-address is valid.
> 
> 6) the level of trust when asserting valid email-addresses
>    remains within the control of the email-address domain owner.
> 
> 7) Allowing ISPs to use a common key reduces key caching.
> 
> 8) Policy assertions and email-address validity can be multiplexed
>    with different designated signing domains.
> 
> -Doug
> 
> _______________________________________________
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
> 



More information about the ietf-dkim mailing list