On Mon, Jul 03, 2006 at 09:34:37AM +0200, Peter Koch allegedly wrote:
On Sat, Jul 01, 2006 at 11:27:37PM +0100, Stephen Farrell wrote:
#2 3.1 Just checking. This part says: "Periods are allowed in selectors and
are component separators. If keys are stored in DNS, the period defines
sub-domain boundaries." Does that mean that the lookup for tcd.ie's foo.bar
selector is in foo.bar_domainkey.tcd.ie? I assume so. If it means something
else then I'm confused.
first, I think you meant "foo.bar._domainkey.tcd.ie"?
Then, while "." is the DNS label separator, it is possible to have "."
within a label, but that needs proper escaping. Also, I'm not sure that
it works in all cases, although modern implementations should avoid those
pitfalls that arose from converting back and forth between wire and
presentation
format in earlier days. This is similar to having one of these
firstname(_dot_)lastname(_at_)example(_dot_)org addresses in the DNS SOA
RNAME field.
Logically speaking, the "." in your example would really belong into the
label.
The original text could probably benefit from using more accurate DNS
terminology.
The intent is that the string foo.bar is valid selector syntax and
that "foo" is one dns label and "bar" is another dns label. In other
words, a selector is not constrained to be a single label.
Back to Peter's concerns and example, I think the case is that the "."
in the Selector syntax is always interpreted as a dns label separator
as the syntax does not allow for that distinction between the two
interpretations. To do that, we would have to invent something like
"foo.bar"._domainkey syntax to mean that "foo.bar" is a single dns
label or maybe foo\.bar._domainkey.
That seems ugly and unnecessary - especially since DKIM already
imposed constraints on the contents of labels, this seems like another
acceptable constraint.
I hope that's the obvious interpretation. I base that on the likelihood
that a lot of people probably don't even realize you can have periods
in labels.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html