On Jul 11, 2005, at 11:24 AM, william(at)elan.net wrote:
3. Key Size
From section 3.3.2 -
"The practical constraint that a 2048 bit key is the largest key that
fits within a 512 byte DNS UDP response packet"
That is not entirely true. Because you use BASE64 within DNS TXT
record
and because respose is not really 512byte dns udp for data (i.e. it
would include dns "question" and "authority" in addition to
"answer").
The 2048 bit key will not fit in dns.
Having not actually broken out tcpdump and actually done this, I
might regret saying this later. That being said, it would seem a
2048 bit key could fit into a 512 octet DNS packet if that DNS packet
contained a domain name of no more than 60 characters and only two NS
records in the authority section referring to 3 character hostnames
under the same domain.
6. DNS RR
From section 3.7.2.2 -
"Verifiers SHOULD search for a DKIM RR first, if possible,
followed by a
TXT RR. If the verifier is unable to search for a DKK RR or a DKK
RR is
not found, the verifier MUST search for a TXT RR."
First of what is "DKIM RR" - I assume you meant "DKK RR". Second
is that
above system (copied from SPF) would lead to double the necessary
number
of queries. This is not SPF and you have email message with data
space
available where you can actually say which RR to check (something
that
I saw and took care of immediatly even in absolute MTA Signatures
first
spec year ago). The simplest for DKIM syntax is to specify type of
record
as part of "q" tag and instead of using "dns" to mean above search in
DKK RR and TXT RR, specify that "dns/dkk" means search dkk rr is
present
and "dns/txt" means that txt record is present. You can still do
default
"dns" and specify that with your search algorithm if you want, but
I'd
say that having particular available RR specified should be
considered
RECOMMENDED.
This sounds like a pretty good idea.
-andy