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 [EMAIL PROTECTED] 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
