> 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.
I am not sure whether your text covers the point I want to pursue, in this note.
I believe it does.
Since I think it is a core requirement, I want to make this explicit:
A signer needs to have at least one algorithm that I can use that they can be
positive will supported by *all* validators.
Exactly so, and given the current hash function situation that algorithm needs
to be SHA-256. This is why I said both generators and verifiers MUST support
it.
However, others have noted that there are sometimes good reasons to use SHA-1 -
hardware accelerator support being the most obvious. This argues for making
SHA-1 a SHOULD for generators, but it has to be a MUST for verifiers so it can
be checked when someone does use it.
I'm personally not a fan of the effort the IETF goes to to provide numerous
alternatives for crypto functions. So specifying things like, I don't know,
Tiger or GOST-MAC or whatever is of no interest to me. That said, I don't think
it is appropriate to enjoin people from specifying such things for use if
there is sufficient support for it.
Whether there is only one and whether it is "preferred" are separate issues,
to me.
That's why I distinguished between "MUST support" vs. "SHOULD use".
THey are indeed distinct, but I think we need to be more concened about what
implementors have to put in their implementations than about how users of those
implementations actually set things up. Of course the universal presence of
support for SHA-256 will make it the perferred algorithm to actually use on the
open Internet, which is as it should be. We could even put in a SHOULD default
to using SHA-256" if that would make folks happier.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html