On Mon, 20 Mar 2006, Jim Fenton wrote:
I agree with you regarding the obscurity of the "r=" value. Typically
there will be a lot of messages floating around from which selector
names can be harvested (from certain mailing list archives, for
example); depending on confidentiality of selector names is a losing
battle.
For comparison: Do people actually get spam based on, for example, the
contact address published in SOA records at the top of a DNS zone? I've
never heard of such a thing.
However, the key record has the useful property that it is under the
control of the domain administrator, and not the signer (since they can
be different when keys are delegated). Things that affect the validity
of the signature like the hash algorithm(s) that are used in connection
with a given key are appropriate for the key record. This prevents a
delegate from using a weaker algorithm than is intended by the domain.
For a domain that has only a few selectors in use, sure. But suppose
someone starts using keys on a per-user basis (or any other method that
requires a huge number of signing keys), then changes the hash
requirements. Any large organization could then have an enormous number
of records to update. It sure would be nice to be able to change it in
just one place, like a signing policy.
It might well be the case that we just need to include this in the
specification to indicate we've thought about it, and explain why we
chose whatever location ends up holding it.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html