On Sat, 12 Jan 2008, Alin N?~Cstac wrote:
 - verify-subdomain.patch correct dkim_policy()
It will return DKIM_PRESULT_VALIDOSIG state if sender domain address is
a subdomain of the signer domain and used key TXT entry don't have "t=s"
in it. I didn't take into account the SSP's "t" tag (IMO there is no
need to do it) and I was forced to use dkim_param_get(..,"i") because
dkim->dkim_signer is not set when dkim-filter verifies a signature. A
proper way of doing that would be to populate dkim_signer with "i" value
before dkim_policy() is called.

It seems to me that this change within dkim_policy() causes it to deviate from the most recent published draft for SSP, which does not take into account the "t" flag on the key itself. The extent of "t=s" in the key record in particular is to consider the signature invalid if the message signed for a subdomain when the published key record explicitly prohibits such. This is part of RFC4871 and thus that decision process is complete before dkim_policy() is ever called. dkim_policy() is meant only to implement SSP, so making this change inside dkim_policy() isn't quite the right place to do it as the libdkim API is currently designed.

The question now becomes one of how DKIM and SSP interact on this point. One could argue that SSP's definition of "Originator Signature" should take this into account. One could also argue that a site which wants to sign for subdomains with a "strict" policy should be publishing keys for each subdomain and not relying on this inheritance to be implicit.

Perhaps if Jim is still monitoring this list he could comment?

-MSK
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
dkim-milter-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss

Reply via email to