[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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:
_dkim_policy.example.com TXT
"DKIM=a._dkim_keys.example.com DKIM=b._dkim_keys.example.com"
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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html