On 4/9/2011 3:17 AM, SM wrote:
The text in Section 3.6.1 is confusing due to the MUST. It mixes
implementation and operations. It can be read as:
If you have the h= in the DNS record, you MUST include "sha1" and
"sha256" in the list of acceptable hash algorithms.
Murray mentioned a case when "h=" may be useful. Even if you rewrite
the "MUST", people reading the RFC might still be confused. It would
be clearer if the following was removed:
'Signers and Verifiers MUST support the "sha256" hash algorithm.
Verifiers MUST also support the "sha1" hash algorithm.'
-1
I think the text is needed.
IMV, the issue here is not considering the key OP concern regarding
declaration mismatches and not correctly spelling out why and when h=
can be used.
There is only one practical reason - security, using policy semantics
to exclude insecure methods a DKIM Bad Guy can exploit.
Even if another possible "flexibility" reason to declare new
additional hash methods it would be still about security using a
matching or better hash method that may be supported by some
verifiers. e.g.;
h=sha256;future-method
That would allow a deployment with an high interest in security to
send signed mail to standard verifiers expected to honor only sha256
messages or exclusive targeted verifiers known to support a
non-standard but better future-method.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops