on 6/14/2002 11:29 AM Ed Gerck wrote:
since Verisign de facto controls the DNS name space
Having any [registry-X] control [TLD-Y] at any given moment is a whole
'nother set of issues. EG, if the registry operator for a TLD changes,
would the private key linked to the TLD also need to be changed?
I'd say that the only way to meld these technologies is to use DNS as a
locator for a self-signed root certificate associated with a domain.
Caveat being that even then you are at the mercy of the signer. You don't
know if you are talking with fred(_at_)example(_dot_)com or if you are really
talking
to bofh(_at_)example(_dot_)com who has access to the repository. Likewise, you
don't
know if you are talking with mailserver.example.com or if you are talking
to bofh-pc.example.com. And there's still the problem of ensuring the
integrity of the link between the DNS referral and how you get to the CA
authority; maybe bofh(_at_)hosting(_dot_)example(_dot_)net has hijacked the
target machine,
or maybe he is running a different copy of the zone and is happy to
redirect "only" half of the traffic.
About the only thing you could use this for is to prove that you aren't
talking to something -- they haven't been able to obtain a copy of the
private key, legitimately or otherwise -- meaning that it would
essentially be PTR/A validation on steriods. It could also be useful for
negotiating transport security services and a limited amount of identity
information (similar to what you get from PTR/A validation) but would not
be useful for any explicit identity information. Some sort of external
notary service is still necessary for that.
Of course the universe is at the mercy of network operator integrity
already so maybe this is ok.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/