On Jun 1, 2006, at 11:33 AM, william(at)elan.net wrote:
On Thu, 1 Jun 2006, Douglas Otis wrote:
There should be a security consideration mentioning an unintended
consequence when a different entity controls sub-domains of a high
level domain. This could be viewed as an ICANN, ARIN, APNIC,
LACNIC, AfricNIC, RIPE NCC,
Could you explain what the ip registries (ARIN, APNIC, LACNIC,
AfriNIC,
RIPE) have to do with domain-based authentication protocol?
Note: they do indirectly if somebody hijacks ip address of dns
server, but
the what Doug is talking about does not seem to be it.
The current obligations are strictly related to domain delegations,
as you suggest. However DKIM introduces new business opportunities
for these organizations. Only regulatory bodies would be in a
position to establish any requisite limitations regarding the use of
sub-domains as related to DKIM within their domain.
Parent signing introduces currently non-existent contractual
obligations and liabilities related to the publishing of DKIM keys.
Simple prohibition of any such publishing by global and regional
Internet Registries would be the simplest solution. Whether these
organizations view publishing DKIM keys within their prerogative may
depend upon whether there is a business model that exploits their
control of domains considered authoritative for all email-addresses
below this domain.
Speculating on the possible business model, outbound SMTP services
could be offered to those able to authenticates with a certificate
from a recognized CA that identifies their email-address, for
example. These messages could then be signed by the TLD domain where
the i= parameter would indicate the identity found within the
certificate. These TLD signed messages could then be considered an
elite assurance that the message will not be abusive. The location
of these keys however introduces the possibility of catastrophic
failure which should involve regulatory oversight.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html