[dkim-ops] key validation question
tony at att.com
Mon Apr 11 08:07:35 PDT 2011
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.'
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.
More information about the dkim-ops