[ietf-dkim] Wildcards and signatures, a moveable feast
Hallam-Baker, Phillip
pbaker at verisign.com
Tue Jun 5 10:30:46 PDT 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20070605/c03efa3f/attachment.html
More information about the ietf-dkim
mailing list