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

[Hector Santos]

----- Original Message -----
From: "Arvel Hathcock" <arvel.hathcock at altn.com>
To: <ietf-dkim at mipassoc.org>

> would it?  So, I agree with Tony and don't see a particular problem
> with adopting Dave's language even though it doesn't have a MUST
> for signers.
>
> Isn't the MUST implicit by virtue of the requirements on the verifier
> coupled with the assumption that the author of the signing software
> desires to create something that's useful?  Am I missing the point here?

Yes, I think the MUST is implicit:

   Signer SHOULD use SHA-256.  If not, signer MUST use SHA1.

Since there seems to lack of confidence that no SHA based algorithm would be
secured enough for certain domains (in the future), that is why I suggest
the specs should indicate instead:

   Signer SHOULD use the highest security possible.

Howewver, unless we use a "receiver" capability logic to allow for growth,
the specs will need to define which current algorithms are considered
possible choices to select from.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com