[ietf-dkim] Suggested alternate algorithm specification language, for now

[Ned Freed]

> If we say that a signer SHOULD use SHA-256, then I think we have solved the
> security-strength concerns, for the moment.

Agreed.

> If the security community converges on a different preference, prior to our WG
> Last Call for the base, then we can plug in something other than SHA-256.  It's
> a minor change.

> However I think the model for the spec language is clear:

>     A validator MUST support {SHA-1, SHA-256}.

>     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.

> We can, of course, add discussion about the trade-offs.  This might lead to the
> somewhat unusual alternative for signer language, along the lines of:

>     A signer MAY use {SHA-1} for its lower overhead, in spite of potentially
> reduced security strength.  A signer SHOULD use {SHA-256} for its higher
> security strength.

It may be unusual, but I like it.

				Ned