On Mar 30, 2006, at 10:09 AM, Jim Fenton wrote:
There's a different situation for key records and policy/practice/
(petunia?) records. The choice of whether to use a new RR or a TXT
key record should be retrieved is something that can be represented
in the signature (the query type, q=, tag has been suggested which
makes sense).
Agreed. The WG can do the right thing and define a binary key for
future use. If there are few impediments, the future might be sooner
than later.
The retrieval of "P" records is more of a problem, since in general
there's nothing in the message to tell the verifier what to look
for. This argues in favor of not having two ways to do this.
Alternatively, a verifier could cache (even beyond the TTL of the
DNS records) the type of record favored by a given domain, as a
hint to what to look for first.
The policy records might also use PTR RRsets rather than a TXT RR or
some other new record. Defining an open or closed-ended list of
third-party signers provides more essential information than found
using the current TXT record approach. The "r=" element should be
removed.
_tps._dkim.<email-domain>. labels can offer the following information:
"*." = Open-ended. (Non-exclusive list covering "-" and "~")
"." = Closed-ended (Exclusive and no list that covers "!")
"-." = Never sends email. (Never and no list that covers ".")
Depending upon whether just the "." is seen or a "*." is found within
the list, this scheme offers more useful information related to the
sending domain.
Although a better approach would be to associate the EHLO with the
signing-domain, the same strategy could be used to associate email-
address domains with the signing-domain and essentially indicate who
directly signs this domain's messages.
Here is an example of an exclusive list of signing domains for <email-
domain>.
_tps._dkim.<email-domain>. PTR my-provider.com.
PTR my-other-provider.com.
A list of third-party signers could be used to adjust handling when
rate-limiting might not be in place, or when the message does not
appear to be properly signed.
Although this does not scale beyond what can be contained within a
DNS response, there is name compression. For large organizations
wishing to remain silent on who they use, they could either publish a
list that with just "*." which means others will be signing their
messages (perhaps the default assumed when no list is seen). If the
organization used the "." label, this would mean only that
organization signs their messages (perhaps they also use key
delegation).
Just as there were concerns expressed regarding the opaque-identifier
revocation overhead, the "^" per-user record represents even a
greater concern!
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html