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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html