On Thu, 2006-06-01 at 15:02 -0700, Michael Thomas wrote: > Higher level domains already have ultimate power over their > subdomains: they could change the name server delegation for the > domain or disenfranchise it entirely. So it is unlikely that a higher > level domain would intentionally compromise a subdomain in this > manner.
Domain delegation of Registered Names is within global and regional Internet Registries current obligations. However a "_domainkey" sub-domain label is not. How such a label is to be handled remains a matter of conjecture without additional regulatory clarification or policy changes that might impact existing agreements. The threat draft appears incorrect to dismiss these concerns as representing a continuation of current obligations. This appears to be another error that will remain uncorrected in the threat draft. : ( > However, if higher level domains send mail on their own behalf, they > may wish to publish keys at their own level. Higher level domains > must employ special care in the delegation of keys they publish to > ensure that any of their subdomains are not compromised by misuse of > such keys. Individual DKIM implementers at lower levels will be unable to assert much influence in such a matter. Should publishing keys at the higher level provide a lucrative revenue stream for Registries, the force of such influence becomes doubtful. DKIM implementers may find themselves in competition with a coalition of Registries and Certification Authorities issuing one-time verified email-certificates. This may be viewed as an unintended consequence, or a "good thing" depending upon who benefits. Such problems, as well as being unable to protect the local name space between sub-domains when allowing MUA signing, remains an open issue. Either the WG attempts to quickly solve these complex issues, or the WG requires keys to be located at the same level as the assured email-address. Simple is safer, and better from an abuse standpoint. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
