Dave Crocker wrote:
> My proposal for language to cover supported text was confounded by
> suggesting some alternative language. Discussion since then has
> frequently expressed agreement with my text, but even I am not sure
> what exact text folks are agreeing with. I also think that Ned's
> point about the benefit of citing sender-side support, versus what is
> actually sent, is significant.
>
> Based on all that, here is what I think reflects groups consensus.
> Those agreeing should say something simple, like "agree". Those
> disagreeing, should say something simple, like, "I proposal the
> following alternate text...".
>
> Here goes:
>
> A validator MUST support {SHA-1, SHA-256}.
>
> A signer MUST support {SHA-1, SHA-26}. A signer SHOULD use
> {SHA-256} for its higher security strength. However a signer MAY use
> {SHA-1}, such as for compatibility with an installed base, lower
> computational cost, or easier implementation effort.
>
>
> Consensus?
[Just back from vacation, otherwise I would have chimed in earlier.]
I presume that the syntax {x, y} means "x and y".
I have read the discussion on "implement" vs. "use". A signer could
follow the recommendation and use SHA-256 all the time; in that case why
MUST it implement SHA-1? On the signing side, what's implemented makes
a difference if an algorithm is being negotiated, but there is no
negotiation here.
The word "However" in the next sentence makes it sound like SHA-1 is to
be used as an alternative to SHA-256. This would have to be the case if
the motive is computational cost or implementation effort [is that
really a consideration?]. But compatibility would be maximized by the
inclusion of both signatures.
I propose the following alternate text:
Signers MUST use SHA-256. A signer MAY additionally sign with SHA-1 for
compatibility with an installed base or to provide lower computational
cost for verifiers that wish to use it.
Verifiers MUST be capable of verifying signatures using SHA-256.
Verifiers MAY verify signatures using SHA-1 for compatibility with a
legacy installed base of signers or to provide lower cost verification
when a SHA-1 signature is included.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
