On Sat, 2006-03-18 at 21:29 -0600, Paul Hoffman wrote: > At 4:20 PM -0800 3/17/06, Douglas Otis wrote: > >With respect to 2048 bit keys, there is already a placeholder in the > >base draft for developing a much needed binary DKIM key. > > Why is a binary representation "much needed"? A 2048-bit key will > only take up 320 of the 512 bytes allowed. Or am I missing something?
The DNS Message is constrained to 512 bytes. 12 bytes are part of the DNS message header, the query has 5 bytes plus the name size plus one byte per label overhead, the answer has 9 bytes + 1 byte per label followed by the RR data. Not including the name space, there are only 486 bytes available for data. As defined using base64 (6 bits per byte) and ASCII parsing syntax, using TXT character-strings to store this 2048 bit key consumes 345 bytes (plus two bytes for defining the two character-string lengths) and leaves 139 remaining bytes. Of those bytes, 8 bytes are used to the version of the TXT record, leaving 131 bytes. The "_domainkeys" label consumes another 14 bytes (assuming pointer compression in the answer section) and that leaves 117 bytes for name space. From this space, one or more selector labels with together with the labels for the parent domain must be accommodated which consumes an additional one byte per label plus the label sizes. This might seem okay until subtracting from this remainder the overhead of comparatively wasteful text methods for expressing allowed hash values and other parameters, and then there is then a much higher probability this will exceed the DNS UDP message constraint. The RFC2538 Cert RR can store binary keys needed for DKIM. The 5 byte CERT header overhead specifying the type of key, key-tag, and algorithm is already less than the Version tag used for the TXT record. The CERT header clearly assures the algorithm has been defined without resorting to default or mandated parameters, which may cause a potential security problem for future upgrades or introduce problematic size constraint issues confounding an upgrade. Using binary to store the key should only require 258 bytes which saves 87 bytes from that used by the TXT RR approach. This savings, together with binary algorithm definitions, ensures future algorithm upgrades or features or even utilizing some of the current features are not be in jeopardy. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
