There are several ways to offer the DKIM key size expectation for
Receiver local policies to deal with:
1) Report the bit size in Authentication-Results (Auth-Res) header.
Authentication-Results: mail.example.com
dkim=pass ..... bitsize=num-bits;
2) Add a DMARC tag extension "ess=" Expected Signature Strength with
values
ess=std76, default, tell receivers to follow DKIM STD76.(RFC6376)
ess=num-bits, num-bits key size is or higher is acceptable
3) Or use "ess=" as a DKIM tag extension:
DKIM-Signature: d=signer.domain; ess=1024; ......
Any method allows for local policy filtering engines to deal with it.
--
HLS
On 5/13/2015 2:13 PM, Dave Crocker wrote:
On 5/12/2015 10:25 PM, Roland Turner wrote:
On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with
what I'm saying above. When talking about unacceptably small keys,
the "unacceptable" decision is not made by the protocol, but by the
receiver.
+1
(I haven't been tracking this thread in detail, so please forgive my
missing some nuance.)
I think the issue separates between 'interoperability' vs. 'usage
policy'. The former is the protocol. The latter is either
Internet-wide BCP or local policy, depending upon strong community
consensus.
I did a quick search for (rfc ietf minimum key size cryptograph) and
found a series of RFCs that do indeed talk about minimum key size. All
of them are Informational, rather than standards track or BCP.
As a non-crypto-geek, the solid constant I've observed is that crypto
algorithm and key size choices are highly malleable: they change over
time. So a protocol needs some agility with respect to these and MUST
NOT be locked in too tightly.
DKIM is algorithm-agile. It needs to also be key-length-agile.
If there is strong community consensus on the choices of algorithm and
key-length, it needs to be asserted as an operational convention, not in
the base protocol
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html