Keys placed within sub-domains of an email-address are unable to list
this email-address within the signature. Hence this "identity" is
_not_ to be considered "signed" by a recognized authority.
Otherwise a message signed by a key referenced from example-company-
b.co.uk could appear authoritative for example-company-a.uk when
allowances for sub-domain keys are made as means to confirm an
identity within a parent domain. Of course, such allowance must be
excluded.
There is a desire to employ sub-domain keys as a means to bifurcate
reputations based upon signing domains to avoid creating email-
addresses have several sub-domains which ironically increases
susceptibility to phishing. After all, _only_ the signing domain is
confirmed by the DKIM process. The SSP policy as conceived is only
able to indicate that _any_ signature might be added, or that
signatures are limited to parent domains and the domain of the email-
address. The expectation of such an assertion is that acceptance of
third-party signatures can be controlled in this manner. This would
also preclude use of "third-party" sub-domain signatures as well.
The DOSP proposal offers a solution for this problem. The methods
used in this solution creates less overhead when adopted as the
initial method for policy publication, as the "normal" method becomes
a secondary default. The DOSP proposal offers a method for any
email-address domain to directly and specifically authorize _any_
specific third-party signing domain. This method scales to any
number of third-party domains without incurring a higher overhead due
to this increased number of authorized domains, and without
increasing the DNS record size.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html