[ietf-dkim] CNAME's + multiple selector labels
dotis at mail-abuse.org
Wed Jul 5 12:11:03 PDT 2006
On Jul 5, 2006, at 9:31 AM, Steve Atkins wrote:
> On Jul 5, 2006, at 9:16 AM, Mark Delany wrote:
>> On Wed, Jul 05, 2006 at 10:11:35AM +0200, Peter Koch allegedly wrote:
>>> The problem might be one of wording, since 188.8.131.52 says that the
>>> keys are
>>> ``"stored" in a subdomain named ""_domainkey""'', where that's
>>> the (sub)domain used to query for them. An example using CNAME
>>> might be
>>> helpful as well.
>> Yep. In light of the possible confusion I also wonder whether a
>> multi-label Selector should also be discussed or inferred by example.
> Definitely. In order to do stunt-dns-server tricks, as will be
> needed to make
> key management for ESPs tolerable, multi-atom selectors are a must,
> it would be annoying if we had to go through a phase where some DKIM
> validators got that case wrong.
The need for multi-label selectors could support the segregation of
key delegations as suggested in the last sentence of section 1.1.
In section 3.1,
| "Periods are allowed in selectors and are component separators."
: "A period contained within the The DKIM-Signature header field
: selector "s=" tag delineates separate domain node labels.
| While some domains may wish to make selector values well known,
| others will want to take care not to allocate selector names in a way
| that allows harvesting of data by outside parties. E.g., if per-user
| keys are issued, the domain owner will need to make the decision as
| to whether to associate this selector directly with the user name, or
| make it some unassociated random value, such as a fingerprint of the
| public key.
: While some domains may wish to make right-most selector labels
: represent well known values, others will want to take care not to
: allocate selector names in a way that allows harvesting of data by
: outside parties. E.g., if per-user keys are issued, the domain
: owner will need to make the decision as to whether to associate
: selector labels directly with the user name or a category of messages,
: or make it some unassociated random value, such as a fingerprint of
: the public key.
Adding a right-most label clarification allows the selector to offer
both separate accruals and key updates without conflict.
I don't see any specific concerns related to the use of CNAMES except
to suggest this as a technique for consolidating keys, which in
general seems like a bad practice. Not offering CNAME examples seems
like a good choice.
More information about the ietf-dkim