At 8:27 AM -0800 3/19/06, Douglas Otis wrote:
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.
That sounds correct. And thanks for correcting my miscalcuation of
base64ing the key.
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.
...and here is where I get confused. I don't see anything in the base
spec that uses any other hashed values, and the other parameters take
up small tens of bytes.
I'm not saying that a binary representation is not good, just
questioning the "need" for it. It doesn't seem needed by the current
spec, and the current implementations seem just fine (although that
is probably due to using 1024-bit keys, freeing up 170 bytes).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html