On Mar 20, 2006, at 4:33 PM, Murray S. Kucherawy wrote:
I'm a little concerned about the trend of sticking more and more
stuff in the selector (key) record. Today at the IETF we talked
about both "r=" and the "we sign with these hashes" stuff in
selector records.
The argument in favour of this is that the "r=" in there shields a
spam target via obscurity, and the "hashes" stuff there keeps us
from having to do two queries to get that information.
It seems to me though that this creates a problem of keeping that
data up-to-date at sites where there are large numbers of selectors
in use. Perhaps in the "r=" case and probably in the "hashes" case,
these are really originator/signer policy issues, and not things
that are specific to a particular key or selector.
This could just be my software developer side talking, under which
I generally think copying a value into "n" (for large "n") places
in code is simply a no-no, but it also seems that domain policy
issues are out of scope for selector records.
In the dkim-options draft, there are two other issues associated with
the key. Creating a key tag holding a domain for locating a means to
confirm the continued validity of a signature conveyed policy, for
example, could also locate a reporting vector as well. This could
allow aggregation of multiple keys under a common set of parameters.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html