Dave CROCKER's proposed text version:
INFORMATIVE NOTE: Although use of rsa-sha256 is strongly encouraged,
some senders might prefer to use rsa-sha1 when balancing security
strength against performance, complexity, or other needs. However,
compliant verifiers might not implement rsa-sha1; they will treat
such messages as unsigned.
While I agree with your version, if there is anything else to
reconsider it would be the last sentence:
However, compliant verifiers might not implement rsa-sha1;
they will treat such messages as unsigned.
If the intent is to encourage removing/adding software support for
rsa-sha1, then the text is good. However, if that is not your intent,
changing it to:
However, compliant verifiers who have not enabled rsa-sha1
will treat such messages as unsigned.
may better reflect all paths an implementator may take with this note.
Reasoning:
The "might not implement" text implies the idea updated verifiers may
decide to completely pull SHA1 support from existing code and future
new verifiers deciding to not bother to add and implement sha1 support.
IMO, this is a lesser practical path for new and updated systems
because new implementators not adding sha1 support will be cutting
itself off from the total market potential and any current
implementators pulling sha1 support or current sha1 mail streams will
break down when the receiver software are updated to RFC4871bis level.
It would be more practical for implementators to consider the least
surprise, the least code change expensive route by just adding a
single logical condition for a "Just in Case" global failsafe turn off
switch:
if (Signature.UsingSHA1 && verifier.opts.FailSHA1)
return DKIM_SIGNATURE_INVALID;
IMO, the new suggested text should cover all the RFC4871bis paths an
implementator may take with this particular note:
- Updated systems pulling sha1 support,
- New systems never adding sha1 support, or
- All systems adding a failsafe switch to disable sha1.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html