INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may
prefer to use rsa-sha1 because of reduced CPU requirements to
compute a SHA1 hash. MTAs with compliant verifierst that do not
implement rsa-sha1 will treat such messages as unsigned. {DKIM 13}
In general, rsa-sha256 should always be used whenever possible.
but I would like to
proposed a modified text:
INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged
and in general, should always be used whenever possible, some
senders may prefer to use rsa-sha1 when balancing higher security
strength versus reducing CPU-bound signed mail loads. Compliant
Verifiers may not implement rsa-sha1 and will treat such messages
as unsigned.
Reasoning: A routine could be anything commonly done and it may
include a high strength requirement as the spec strongly encourages
and recommends should always be used in general. So IMO, it may help
to be more general by removing the "routine newsletter" example and
the connotation any "routine" mail stream is any less secured
(low-security).
Like your suggestion about 2.3, I fail to see how including an example makes
a statement less general. Given that, your suggested paragraph reads exactly
the same to me as the one we have now.
Actually, with one important correction (below), I like Hector's text
better. I do think the attempt at a concrete example is a red
herring, and I prefer more abstract statement. For that matter, I
even think the "CPU-bound" part is too specific, so I'll offer a small
tweak.
The important correction is to change "may", which could be
interpreted as RFC 2119 language, to something else ("might", say).
That's particularly significant in "verifiers may not implement",
which might be incorrectly read as "verifiers MUST NOT implement", or
some such. It's easy to avoid that.
My suggestion:
INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged
and should, in general, be used whenever possible, some
senders might prefer to use rsa-sha1 when balancing security
strength against performance, complexity, or other needs.
Compliant verifiers might not implement rsa-sha1, and they will
treat such messages as unsigned.
Barry
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html