Arvel Hathcock wrote:
> > In that case I would suggest that we make SHA256 a MUST support for
> > signature verifiers and a SHOULD for signature generators.
> >
> > SHA-1 should probably also be a MUST for verifiers and a SHOULD for
> > signers.
>
> For the record, I'm fine with this.
I don't think I understand what it means for a signer to be required to support
two different "SHOULD" requirements for the same function.
Hmmm.
Perhaps there is a distinction between saying that the signing implementation
MUST *support* a core set of algorithms, versus that a signer SHOULD *use* one
of them?
There clearly is a distinction, but I don't think that's the problem here. As a
rule I think we should avoid saying something MUST be used no matter what.
We're concerned that implementations be _able_ to interoperate, not with
constraining all forms of operation everywhere to use the same algorithm.
The problem here isn't that someone could configure the use of some random
signature algorithm and still remain compliant, but rather that someone can
write an implementation which supports generation of neither SHA-1 nor SHA-256
signatures and still be compliant. As such, I suggest making support for SHA-256
on generation a MUST and SHA-1 a SHOULD. Both SHA-1 and SHA-256 need to be
a MUST for verifiers.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html