On May 29, 2006, at 8:07 PM, Barry Leiba wrote:
indeed. which prompts the obvious question: why are folks
pursuing this.
And I think the thread has gone on long enough with enough
participants for me to say that I see strong consensus that this
particular concern is not shared.
This subtopic is closed. Let's look at any other reasons to remove
the parent-domain point. Is there one?
There should be a security consideration mentioning an unintended
consequence when a different entity controls sub-domains of a high
level domain. This could be viewed as an ICANN, ARIN, APNIC, LACNIC,
and AfricNIC consideration advice. RFC1591 makes the following
statement:
,---
| There are no requirements on subdomains of top-level domains
| beyond the requirements on higher-level domains themselves. That
| is, the requirements in this memo are applied recursively. In
| particular, all subdomains shall be allowed to operate their own
| domain name servers, providing in them whatever information the
| subdomain manager sees fit (as long as it is true and correct).
'___
There did appear to be consensus this could be viewed as requiring
contractual rather than technical considerations. This requirement
should be indicated within the security consideration section at least.
: Security Considerations:
:
: Keys published by common higher-level domains
:
: Although TLD managers are trustees for the delegated domain, DKIM
: introduces a security concern unrelated to domain delegation.
: Currently there are no contractual obligations barring gTLD, ccTLD,
: or SLD managers from publishing DKIM accessible keys within a
:"_domainkey" sub-domain. While this sub-domain can not be
: delegated as a domain due to the underscore character '_',
: unqualified sub-domains in the 'i=' parameter can be constructed
: to reference a key published by a higher level domain. These
: higher level keys expose all sub-domains to possible harm from
: a possible security breach at these higher levels. The only
: protection available to owners of all sub-domains would be
: established contractual obligations that currently do not exist.
: The simplest remedy would be to ban inclusion of any sub-domain
: beginning with the underscore '_' within these common higher-level
: domains.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html