After I wrote the CACM article and the Internet Draft, I
realized that the main use of cryptographically self-signed handles
in the DNS system is more likely to be public key sharing, rather than
establishment of permanent handles. Illness disrupted my writeup, so
it is only in the form of slides for a class. I would welcome any
co-author who could help me get the revised ideas into print.
Here is a brief description, with a pointer to the class slides:
Minimalist Public Key Infrastructure
Many proposals for public key infrastructure try to solve real
authentication problems, by associating keys with supposedly reliable
identities, using chains or webs of trust. This seems to violate a key
principle of infrastructure design: don't solve high-level problems,
just provide tools. I propose to apply ideas from specialized areas of
security to provide a minimalist PKI, providing an identity relation,
but no identities as objects. Trust may be constructed in many
different ways, at varying costs, depending on its importance in a
particular application. Pages 187-215 of the
slides with notes
for the Internet course treat this topic (slides numbered 131-150: the
notes increase the numbers in some viewers, but not in others).
The following proposal has most or all of the functionality desired
for a minimalist PKI. But, it presents the value of such an
infrastructure to provide permanent network handles, even if no
authentication nor encryption is needed between two communicating
The Internet community has suffered from recent conflict over
Top-Level Domains (TLD) in the Internet's Domain Name System (DNS),
and the Internet Corporation for Assigned Names and Numbers' (ICANN)
administration of them. The intensity of this conflict is partly due
to the inflated value of domain names, particularly at the top and
second levels. That inflated value derives partly from the historical
conflation of two logically separate functions into the DNS:
translation of handles for services available on the
Internet into Internet Protocol (IP) numbers for routing purposes,
directory lookup (DL) of somewhat mnemonic and guessable
names for services.
Most of the commercial value of domain names derives from their
suitability as names in the DL function. But, domain names
are actually used mostly as handles. DNS is currently the
sole provider of handles for the Internet, while
Google, Yahoo, and other independent agencies
compete to provide useful DL services for a variety of types of names,
some assigned and some derived from Web content. Those who only desire
handles are forced to compete with powerful corporations who
covet domain names for their value in DL services.
I propose to deflate the value of domain names by
providing numerical and non-mnemonic handles through an
independent service, separate from DNS and all other DLs. The new
service will provide handles promiscuously to all who ask for
them, either free of charge or for a tiny administrative fee to cover
costs. With this new service, DNS will compete separately for its
value as a handle resolution service and as a DL
name resolution service. I expect that, in the new regime,
DNS domains will have a very low commercial as well as technical
value, and will eventually be completely superseded. But I do
not propose to attack the use of DNS by any means other than
Without the market inefficiency due to bundling of handles
with names in DNS, I expect ICANN's administration of DNS to
provoke much less conflict, because its potential for unintended harm
will be much less.
Documents and Discussion
scooped me a year ago with his article,
DNS: A Safe Haven.
Essentially all of the ideas in my proposal are there. Now that I've
seen Frankston's article, I will try to extend his ideas instead of
I've been pitching a few people who seem likely to be favorable
I am working on documents describing and justifying the proposal
more thoroughly. ``Open Network Handles Implemented in DNS'' is
published as an Intenet Draft. ``A Proposal to Separate Handles from
Names on the Internet'' is submitted for publication. Both are
available in the
CoRR archive of CS reports.
I think that there's some useful prose scattered around in the other
drafts. But I haven't succeeded in focusing them well on particular
audiences, partly because I haven't figured out what audiences I need
to pitch. Help, anyone?
"A Proposal to Separate Handles from Names on the Internet" in
This one is published as a real Internet Draft (the plain text form,
derived from the nroff/ms source). That's why it's in the ID plain
text format. It's supposed to be concrete. I'd
especially appreciate technical critique uncovering
my misunderstandings of the security extensions to DNS (DNSSEC). The
LaTeX version (from which the HTML, DVI, PDF, and PostScript are
derived) is essentially the same, but pagination and formating
differ. It is archived in
"Open Network Handles---Definitions and Specifications" in
An earlier draft was called "Requirements" instead of "Definitions and
Specifications." I changed because of the specific meaning of
"requirements" in the RFC literature. You may dig out older drafts
from file detritus and the RCS directory.
I (firstname.lastname@example.org) welcome all comments,
but, if you are among those offended by lots of pedantic
detail, please cut me a bit of slack for now. There really are lots of
technical subtleties that need to be worked out with excessive care at
the beginning. I'll try to make the presentation more palatable later.
If you know of prior work that I should read, either for
standard terminology, or ideas that have already been worked out, or
just to be fair about credit, please send citations ASAP.
In version 0.1, this is just a slightly structured list of
observations and questions. I think that I will make the most progress
by sketching a design now, and backing out the specifications and
questions from the prototype design.
"Open Network Handles---Rough Design Prototype" in
I think that this one is worth reading and critiquing pretty
carefully, even in version 0.1. The design is pretty thoroughtly
sketched out, except for some tricky details about handle
reassignment. I'm pretty confident that implementation and design
details can be pieced together from DNS for the discovery part, and
systems like PGP and GPG for the authentication part. Perhaps this is
worthy to be cleaned up an made into an Internet Draft.
"Routes, Addresses, Handles, and Names in Networked Communications" in
This is still pretty rough, but it's getting close to something
objectively evaluatable. "Abstract" means that I specify what messages
need to be implemented, and what information they need to carry, but
not the format or syntax.
Copyright Michael J. O'Donnell <email@example.com>. Licensed for free use.