This issue derives from a conversation I had with Peter Koch at the end
of the week in Dallas.
In -base, section 3.5, the description of the d= tag allows the domain
of the signing entity to be a parent of the signing address itself. In
other words, d=example.com and i=user(_at_)sub(_dot_)example(_dot_)com is
legal. This
was done largely as a convenience; it allows domains to sign using keys
at the higher domain level when they employ subdomains to aid mail
routing, rather than having to publish key records in each subdomain.
This gives rise to the attack described in -threats section 4.1.18, "Key
Publication by Higher Level Domain". On one hand, this isn't a very
worrisome threat, since domains need to trust the publisher of their NS
records. But it's possible to construct situations where this might be
a bigger concern. For example, a higher level domain, not under the
same administrative control as its subdomains, starts signing messages
it sends on its own behalf, and a key is compromised. All of a sudden
the subdomains are vulnerable too. The problem is that there's no way
to tell where the administrative boundaries are between levels in the
domain hierarchy.
The solution to this would be to remove the language in section 3.5, "or
a parent domain of", and the threat goes away.
It seems like a small benefit we're getting through "parental" signing,
offset by a small threat. How do others feel about this?
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html