[ietf-dkim] Re: 1368 straw-poll :
pbaker at verisign.com
Mon Feb 26 07:51:22 PST 2007
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Michael Thomas
> Well, I have one small quibble in that I don't understand
> what the actual problem is. While that's not a huge problem
> in the global scope of things, I do need to understand this
> enough to transcribe the outcome. In particular, I haven't
> seen any clarification as to why the algorithm bindings in
> -base are not sufficient to cover this attack; having -base
> already solve the problem is the best outcome, right?
The policy language needs to be expressive enough to be able to reference them, that is all.
If you only support algorithm A then your policy and key records would be:
_dkim_policy.example.com TXT "DKIM"
keya._dkim_keys.example.com TXT "alg=RSASHA1 v=32q4qtiuhwq"
If you always use algorithm A but also support B then you would have:
_dkim_policy.example.com TXT "DKIM=a._dkim_keys.example.com"
k1.a._dkim_keys.example.com TXT "alg=RSASHA1 v=32q4qtiuhwq"
k1.b._dkim_keys.example.com TXT "alg=RSASHA256 v=aqjqhj32qafoiju4qtiuhwq"
If you always use algorithm A and B then you would have:
Just to be clear here: nobody is arguing for the ability to specify the algorithm in the policy record or anything like it. There lies the road to madness. We do all of that using base.
Also the most likely near term change would be a new cannonicalization algorithm rather than a digest.
More information about the ietf-dkim