Hallam-Baker, Phillip wrote:
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.
It depends on what type of policy is being expressed. A signature at
mallet.com might be applied by the croquet-lovers(_at_)mallet(_dot_)com 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html