Subject: [ietf-dkim] Signer referenced DNS vector

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Mar 2006 10:26:54 -0600

The r= construct found in SSP is referenced from an email-address  
domain contained within some message header field.  One justification  
for this mechanism was for phish reporting.  Such reporting is better  
done using an email-address convention such as dkim-abuse@ where  
perhaps reports are also signed using DKIM (and perhaps formatted per  
ARF) to be accepted.  This added signature requirement would be to  
avoid abuse of the abuse report vector and to provide better evidence  
of abuse.

When mechanisms are intended to be specific to that of the key/ 
algorithm/access, allowing a unique location for publishing related  
information allows groups or categories within the domain to be  
established.  For example, the construct of including a w=<group- 
label> parameter within key indicates where within the domain this  
group related information is published.

The access of this information could be based upon label prefixes to  
further isolate various RRs.

The key is located using the construct found within the message as  
follows:

signature parameters:
s=<label-a>.<label-b>  d=<label-c>.<label-d>.<label-e>

The key is located at the following location:

<label-a>.<label-b>._domainkeys.<label-c>.<label-d>.<label-e>.

key parameter:
w=<group>

The group information is at the following location:

<group>._dkim_group.<label-c>.<label-d>.<label-e>.

In addition to this label being simply to group the keys, this also  
allows reporting information to be specific tailored for the group.

At this location, various sub-grouping of keys could be  
accomplished.  Conventions established for group labels can  
communicate associated vetting involved with this group of keys.   
These standardized groups could be used in conjunction with message  
annotations.

Some conventions for standardized labels could be:

admin: (restricted access)
user:  (general access)
guest: (unrestricted access)
list:  (list)
auto:  (auto-response)
info:  (promotional or general status information)
test:  (for test only)
void:  (no longer a valid group)

A large ISP could still have messages with the key within the admin  
annotated as trustworthy, perhaps to indicate account status needs to  
be updated or that the users system has been compromised.  This added  
level of trust would be desired when otherwise risky actions are  
recommended.  This type of message should be recognized separately  
from those of just user, guest, list, auto, or info for example.   
When non-standard groups are used, the annotation would be specific  
for intra-domain use.

RR type TXT may provide the report vector.  Other RR types could be  
defined for future use.

-Doug

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