In <437A1D33(_dot_)3090605(_at_)mtcc(_dot_)com> Michael Thomas
Why the three months between the SSP I-D and the DNS recourse record?
Can't we just use a TXT RR clone the way SPF did?
The main reason is so that we don't have to b64 encode the public
key. Beyond that, it may well be just a drop in TXT clone of the
Won't people have to b64 encode the public key anyway to put it into
their zone file?
I went through and looked at the DKIM records (DKK and DKP), and a
great deal of the data can only be lists of arbitrary strings. The
only real savings is going to be from the 8/6 expansion caused by
using base64 instead of binary. Even if you consider the 25%
reduction in the key to be significant, that percent is going to drop
dramatically once you include all the other stuff in the DKK record,
along with DNS overhead, UDP overhead, IP overhead, etc.
I think there are strong reasons to just keep it simple. Just use a
clone of the TXT record for the DKK and DKP records. Define this in
the -base and -ssp documents and be done with it. The SPF spec does
it this way and it is really very trivial.
All the implementations are going to have to support the parsing of
TXT records anyway, so adding support for TXT record clones saves a
lot of extra work. That, and we can cut out an entire I-D and 3
months out of the development process.
ietf-dkim mailing list