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

[Douglas Otis]

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