At 11:49 AM -0400 6/17/02, Keith Moore wrote:
> I think you raise a valid concern, but it's one we always face when
transitioning from an insecure system to a more secure system. People
may misuse any security technology by imbuing it with more
capabilities than the developers of the technology intended. However,
if we always let that concern deter us, we will rarely make progress.
Also, this is not a suggestion to deploy a DNS-based PKI in lieu of
other PKIs; I am a believer in multiple. independent PKIs.
so am I, but I also believe that a DNS-based PKI will displace other PKIs -
if we really want multiple independent PKIs we shouldn't try to make one
that is based on the DNS hierarchy. using DNS to return certs might be okay,
(assuming you can work out the protocol warts), using DNS delegation as
the framework for a distinguished PKI isn't.
Keith
Keith,
Yes, one could use the DNS merely as a repository for certs from any
PKI. But, the DNS provides a unique opportunity to take advantage of
an existing name system that is very widely used and which is
precisely the way we usually communicate the name of the machine to
which we wish to connect (or the name of the person to whom we wish
to send a message). Any time we try to create a new naming system we
run into lots of problems. Any time we try to map from a PKI name
space to a different name space used by an application, we get into
trouble. Ultimately I do not think there is any substitute for a
DNS-based PKI to support most of our Internet communication, because
that communication is naturally expressed in terms of DNS names.
Now, having said that, I acknowledge that one can have such a PKI but
not choose to have a single root for it. One could have each TLDs act
as its own root and cross certify (using name constraints) to link
the TLDs together. There are a small enough number of TLDs to make
this feasible. The number of second tier domains is way to big to
make this work well. It would be much simpler to have a single root,
but ...
Steve
Steve