Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt

["Murray S. Kucherawy" <[e-mail]>]

On Sun, Jun 11, 2017 at 1:40 AM, Martin Thomson <[e-mail]>
wrote:

> https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1
>
> I think that I got the essence of your changes there.  And it's a lot
> shorter.
>

Can you explain what you mean by "rely on"?

Second, you can fit a key larger than 1024 bits in less than 256
> octets.  A 1536-bit key isn't that great, but it's a huge amount
> better than 1024.  I haven't done the math, but I'm sure that you
> could find a number that maximizes key length without blowing the 256
> octet limit.  This might be good advice to add (which would also mean
> that you can keep the paragraph).
>

Interesting.  And there's a bit of a variability since the key record can
have other stuff in it (3.6.1 of RFC6376) which reduces the amount of space
available for the "p=" value.

My possibly ignorant run at the math:
- my 1024-bit public key encodes to base64 in 217 characters
- there are 255 octets available in a character-string in a TXT record
- subtracting 10 from that for "v=DKIM1;p=" which are required, leaves 245
assuming there's no other cruft or spaces in the record
- for 217:1024 = 245:x, x=1156

So by that logic, you can put a 1156-bit key in a record now without
changing anything.  For anything bigger you will need multiple
character-strings in the TXT field which I believe is one of the things
John says doesn't fly in current provisioning software.

-MSK