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