ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: Delegating responsibility: a make vs. buydesigndecision

2006-08-24 11:11:45
This discussion seems to be going round in circles.

Lets go back to some basic principles that we try to make general laws:

1) Each party that claims responsibility for a message does so in their own name

2) If a party wishes to delegate signing capability (in effect a PP signature) 
then this structure should be visible in the policy architecture

3) The only DKIM policy record useful to a recipient states 'everything I send 
has a DKIM header'


These principles seem to me to suggest the following approach:

1) The domain owner adds a dummy DKIM header
2) The actual sender accepts responsibility in their own name.


OK so what might a dummy header look like?

* The signature is not 100% effective
* It has a selector

If the email sender is sending out identical content to every recipient then it 
would make sense for the domain name owner to sign the content but not the 
sender field to create the dummy header.

If the messages are going to be customized for each recipient then the dummy 
header would not cover either the content or the sender. If this practice is to 
be widespread we should define a NULL algorithm to save the recipient the need 
to check a useless signature.


The selector can contain statements that are in effect policy language. For 
example:

* This key record can only be used with the outbound email address 
billing(_at_)example(_dot_)com
* If this key record is used there MUST also be a signature from party Y.


I think that the above meets the use cases described. Each key record is in 
effect a policy statement insofar as publishing a key record means that you are 
defining a set of acceptable criteria for authentication.

The SSP record contains only the statement that everything has a DKIM header. 


As I see it there are only two useful routes to extending the policy record 
beyond that.

* The SSP record states that every message sent has 1...n DKIM headers where 
the key selectors meet stated criteria.

* If no header is present then a key record can be obtained by applying a given 
set of rules. (this is a powerful idea but the complexity does not seem to be 
justified by the return).

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

<Prev in Thread] Current Thread [Next in Thread>