Skip to Content.
Sympa Menu

bluesky - Naming via SDSI

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: hal AT finney.org
  • To: bluesky AT franklin.oit.unc.edu
  • Subject: Naming via SDSI
  • Date: Wed, 28 Feb 2001 15:03:01 -0800


I've been studying OceanStore [1], which uses a SDSI [2] like system for
"friendly names". This is similar to what Ted Anderson proposed in an
earlier message. Here is how one of the OceanStore papers describes it:

Certain OceanStore objects act as directories, mapping human-readable
names to GUIDs. To allow arbitrary directory hierarchies to be
built, we allow directories to contain pointers to other directories.
A user of the OceanStore can choose several directories as "roots"
and secure thsoe directories through external methods, such as a
public key authority. Note, however, that such root directoreis are
only roots with respect to the clients that use them; the system as
a whole has no one root. This scheme does not solve the problem of
generating a secure GUID mapping, but rather reduces it to a problem
of secure key lookup. We addresss this problem using the locally
linked name spaces from the SDSI framework.

The idea, then, is to have a directory hierarchy similar to what we are
familiar with from file systems. As with Unix, files can be linked into
more than one directory (and unlike with Unix, directories can be, too).
Ted gave examples like /com/us/microsoft or /entertainment/music/jazz.

With SDSI, each component of such names is associated with a public key.
The public key signs bindings of the names below it in the hierarchy
to their own keys. In the example above, the key associated with "/us"
signs a certificate binding "com" to its own key; and that key signs a
certificate binding "microsoft" to the Microsoft key.

The certified information would also include hints about where in the
network to find the directories associated with each name, and possibly
other data. So to use it, if someone gave you the name /com/us/microsoft,
and you knew (or could find) the top-level address and key of /com,
you'd look up there and ask for the cert for "us". You would check the
sig on this cert (signed by the "com" key) and then go to the address for
"us" and repeat the process to get the cert for "microsoft".

This is also similar to how the Secure DNS system will work.
microsoft.us.com would be looked up by starting with the key and DNS
server for ".com", and finding the sig on the record for "us", which
includes the key for "us" as well as its IP address. Then you'd go to
"us" and get the same information for "microsoft", etc.

This scheme has a lot of nice properties, including security and
flexibility. Each person can have his own chunk of name space where he
can manage any filenames he wants below it. And multiple hierarchies
can exist at once, overlayed on the same data. Both directories and
files can be mapped into multiple other directories.

However I think it has significant drawbacks as well.

One is the special handling necessary for top-level directories (I
will call them TLDs as they play essentially the same role in DNS).
For a global name like those above to be meaningful, the user of the
name must have the key and address of the TLD. If you see a name like
"/bluesky/mailinglist/archives" and you've never heard of "/bluesky",
it will be a problem for you to find the data. Some other mechanism
may have to be introduced to index TLDs.

Furthermore, this scheme seems likely to inherit some of the same problems
of TLDs in the DNS world. In practice it has not proven possible to
easily expand the set of widely recognized TLDs. There are a number of
organizations providing name service which let anyone add their own TLDs,
but few people use them because few people use them. In other words, if
you use an oddball TLD that nobody else knows, your address won't work.
So there is social and economic pressure to converge on a single set of
TLDs that everyone recognizes.

Then, in this situation, the political problems surrounding DNS TLDs
may become present as well. Getting a new TLD established may require
convincing some kind of standards body to approve it so that everyone
will start supporting it. The controversies over the actions of ICANN
show what a bad situation this is.

There is also the problem of forcing higher level directories
(including but not limited to TLDs) to remove entries which lead
down to controversial data. We see this to some extent with the IP
hierarchy, where censors go after ISPs or upstream providers to try to
silence users who refuse to shut up. Similar problems arise with the
"blackhole lists" used to punish spammers; these are used for all network
connectivity, not just email, and sometimes wipe out innocent bystanders.
The peacefire.org site is unavailable to many internet users because it
is hosted by a provider who has also had some spammers.

If your data is widely known by a certain address, and a component of
that gets knocked out, the data may become effectively unavailable.
Even if an alternate hierarchy points to it, if that hierarchy is not
widely supported it won't help, and at best it will take time to circulate
information about the new address. Controversial sites today are often
forced to hop all over the net, able to stay at any one address for only
a few weeks until someone complains. This makes them almost impossible
to find.

Another problem with this scheme is that I don't see that it extends very
well to metadata. Binding a directory name to a key is a mechanical
process and doesn't imply any endorsement. Binding metadata to a file
is another matter and probably requires human interaction, at least if
the binding is going to mean anything.

You might also see some of the other problems with DNS, like an ultra-wide
hierarchy to allow shorter names. There are something like 10 million
.com addresses. You need a whole infrastructure just to service that one
TLD. Such a system is not an attractive prospect for a SDSI name space.

Hal

[1] http://oceanstore.cs.berkeley.edu
[2] http://theory.lcs.mit.edu/~cis/sdsi.html




Archive powered by MHonArc 2.6.24.

Top of Page