>> A signer SHOULD use {SHA-256}.
>
> This leaves out what the signer MUST support: I believe you need to have a
> MUST support SHA-256 in there. I'm ambivalent about whether or not there
> should be a signer SHOULD support SHA-1 in there. I figure that signers that
> want to use > SHA-1 will do so as long as they can be assured of verifier
support.
Indeed, I was struck by that oddness, when I wrote it, too.
As I thought about it more, I realized that I do not know what it means to
declare a requirement for signer "support", whereas signer "use" is clear.
It means that the software implementation supports it as a selectable option.
If you don't say this what's to prevent someone from writing an implementation
that only supports Camilla-MAC hashing and calling it compliant?
Stated differently:
The language for the validator says what incoming bits it has to be able
to process.
Equivalently, the language for the signer says what outgoing bits is
"should" generate.
In that context, I can't figure out what it means to talk about signer
"support".
Implementation requirements make sense for both ends here.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html