[ietf-dkim] CNAME's + multiple selector labels

[Douglas Otis]

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 3.6.2.1 says that the  
>>> keys are
>>> ``"stored" in a subdomain named ""_domainkey""'', where that's  
>>> actually
>>> 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,  
> and
> 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."
'___

  change to:

: "A period contained within the The DKIM-Signature header field
: selector "s=" tag delineates separate domain node labels.


Also:
,---
| 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.
'___

  change to:

: 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.

-Doug