On 4/9/2011 3:17 AM, SM wrote:
Hi Tony,
At 19:39 08-04-2011, Tony Hansen wrote:
The value of h= does *not* indicate what is *implemented* by the signer
-- it *only* indicates what is currently being *used* to sign with.
Nowhere does the spec say that h= indicates what has been implemented by
the signer.
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.'
Interesting suggestion.
The MUSTs *are* redundant with section 3.3's first paragraph. However,
it's still important.
If this section were rewritten, I'd suggest something like this:
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash
algorithms that might be used.
As stated in section 3.3, Signers and Verifiers MUST
support the "sha256" hash algorithm, and Verifiers MUST also support
the "sha1" hash algorithm. Which algorithms are listed
in h= is an operational choice by the sender.
Tony Hansen
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops