Subject: [ietf-dkim] Wildcards and signatures, a moveable feast

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 10:30:46 -0700

OK please help me with the following point of semantics:
 
I have a mail with some form of 'sender' address, lets call it 'mail.example.com'
 
I have a DKIM policy 'I sign all mail' bound to mail.example.com
    1) as a policy record at example.com
    2) as a policy record at *.example.com
    3) as a policy record discovered at example.com by means of upwards traversal

What does the DKIM policy mean with respect to the placement of DKIM keys? There must be some form of constraint or any signature with keys anywhere will work, I don't think the policy is satisfied by a signature at mallet.com.
 
Implicit in the tree traversal approach is a re-positioning of the start root for the key constraint. So if I eventually find my policy at example.com that is where I constrain my key records to.
 
This is one of the reasons I don't like the upwards traversal semantics, the semantics of the policy now depend on where it is found. Everything becomes a moveable feast and is confusion.

The solution is to specify the anchor point for the key record in the policy statement as proposed previously for other reasons. 
 
For example "DKIM=_keys.example.com" means you will always find a DKIM signature that is positioned at a subnode of the specified DNS node.
 
This approach now works fine with wildcards. If someone misses out the key anchor then the default is the sender domain being verified. Otherwise the absolute value specified is used.
 
As a bonus this gives the policy specification the power to deal with issues such as when the policy of XYZ.com is that all their mail is DKIM signed by comcast.net.
 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Jun 2007 23:21:11 -0700

Hallam-Baker, Phillip wrote:
> What does the DKIM policy mean with respect to the placement of DKIM
> keys? There must be some form of constraint or any signature with keys
> anywhere will work, I don't think the policy is satisfied by
> a signature at mallet.com.

It depends on what type of policy is being expressed.  A signature at
mallet.com might be applied by the [email-masked] mailing
list, and would be acceptable as a third-party signature if
example.com's policy permits it.  In practice, third-party signatures
are more dependent on reputation and accreditation, since they're (IMO)
more prone to abuse.

A DKIM policy that specifies "no third parties" should place a
constraint on the signing identity, not the location of keys.  Key
locations are already constrained by the rules in DKIM-base, in
particular that they must be in the same domain as the signing identity,
or a parent domain if certain flags are not specified.  I don't see any
need for the key record location to change even if the policy record is
discovered via upward traversal.
>  
> Implicit in the tree traversal approach is a re-positioning of the
> start root for the key constraint. So if I eventually find my policy
> at example.com that is where I constrain my key records to.
>  
> This is one of the reasons I don't like the upwards traversal
> semantics, the semantics of the policy now depend on where it is
> found. Everything becomes a moveable feast and is confusion.
>  
>  
> The solution is to specify the anchor point for the key record in the
> policy statement as proposed previously for other reasons.
>  
> For example "DKIM=_keys.example.com" means you will always find a DKIM
> signature that is positioned at a subnode of the specified DNS node.
>  
> This approach now works fine with wildcards. If someone misses out the
> key anchor then the default is the sender domain being verified.
> Otherwise the absolute value specified is used.
>  
> As a bonus this gives the policy specification the power to deal with
> issues such as when the policy of XYZ.com is that all their mail is
> DKIM signed by comcast.net.

This is getting back to the "designated signing domains" proposal from
several months back.  I thought (?) we had decided not to do that.

-Jim