----- Original Message -----
From: "Dave Crocker" <dcrocker(_at_)bbiw(_dot_)net>
To: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
Cc: "IETF MASS WG" <ietf-mailsig(_at_)imc(_dot_)org>
Sent: Wednesday, July 27, 2005 6:22 PM
Subject: Re: revised Proposed Charter
Public keys stored in DNS records are much larger than DNS records
tnx.
how do folks feel about including this?
Well, the reality will be that DKIM is not alone in the new dawn of
dumping/exposing server policies in TXT records, i.e, SPF, SENDERID and now
DKIM and I'm sure others to come.
From my perspective (as a vendor) who needs to offer the options to
customers, the question of DNS lookup redundancy comes into play.
So you begin to think about the idea is an univeral TXT record lookup to get
all the various policies in one shot.
Well, that would be nice, ideal, but this is where a potential size issue
comes into play so maybe it is probably best to separate the TXT records by
specialty subdomains, especially one like DKIM that has greater than normal
information.
So I think the specs is ok as is. By using a specialty subdomain lookup, you
don't have (or reduce) the potential of overflowing 512 bytes.
Idea: I'm just throwing this up for sizing.
Possibly offer a "redirection" concept:
p=http;
p=url;
p=http will tell the verifier to perform a direct http lookup
http://domainkey.domain/selector
p=url will tell the verifier to perform a direct specified url lookup.
This will reduce size issues with DKIM, but yes, will introduce additional
lookups and possibly some other security issues. This also touches base
with the "q=" query method issues.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com