> When a 2048 bit key is to be handled, with the 'g=' parameter > and a new hash callout, the space remaining is 93 bytes, > assuming a domain with 4 labels with a selector. From these > 93 bytes, 5 labels, the local-part and hash function must be > defined where the average item size must be less than 14 > bytes. When a binary DKIM Key RR is used, the remaining > available space is 192 bytes, which then allows an average > item size to be greater than 27 bytes. This provides twice > the available space, which is _not_ insignificant. The cases > where the DNS payload overflows would be much fewer.
Irrelevant, there is no space for a DNSSEC signature in either case, unless DNSSEC itself supported either ECC or some form of signature compression a la Schnorr. > There was not a suggestion to use a new binary record. The > proposal was to employ an existing record in a binary fashion. It may exist on paper, it is not supported in the running code and getting support is a long time off. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
