Douglas Otis wrote:
On Thu, 2006-06-01 at 15:02 -0700, Michael Thomas wrote:
Doug. I didn't write this. It was taken directly from the -threats draft.
Mike
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