Skip to Content.
Sympa Menu

bluesky - Re: the three-services model

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Ted Anderson <ota AT transarc.com>
  • To: hal AT finney.org
  • Cc: bluesky AT franklin.oit.unc.edu
  • Subject: Re: the three-services model
  • Date: Mon, 26 Feb 2001 07:35:55 -0500 (EST)


On 18 Feb 2001 16:51:33 PST regarding "the three-services model"
hal AT finney.org wrote:
> Ted Anderson writes:
> > There is still the matter of attaching human readable names to
> > content hashes.
...
> The same problem arises with search systems. Freenet is using a
> metadata concept where each document has associated with it a set of
> attribute-value pairs. These could include title, author, keywords,
> etc. and be a target for searches. The question is, how do you know
> that a particular set of metadata accurately describes a document.

I think it is certainly reasonable to attach metadata to an object
either directly or by CHK reference, but this, of course, just puts off
the problem. Do you trust a particular collection of metadata
annotations or not?

> > Ultimately, I don't think there is any avoiding the need to use
> > digital signatures to investing trust in this mapping.

> I would question this on two counts. First, digital signature based
> systems don't appear to me to be workable, at least in some approaches
> I've seen. And second, perhaps there are alternatives that will work
> and scale better.

This is a key (:-) area of disagreement that we should endeavor to
resolve. I believe that an important benefit of a decentralized storage
system is that it puts security in the hands of the data producers.
They control the data by encrypting it and managing the keys as they see
fit. They do not *have to* rely on the security of a centralized file
server to protect their data; though they *can* entrust the encryption
keys to a key server if centralized management is desirable. The
trade-off is that revocation of permission is difficult: data must be
re-encrypted in a new key. However, this difficulty only mirrors the
state of the real world. If you entrust your data to someone, you have
to assume they will keep a copy for themselves if they want to. This is
just caching and replication after all.

Any scalable scheme for end-to-end encryption by individual data
producers and consumers is going to depend on public keys, which then
can be easily used for digital signatures.

> Freenet considered a digital signature approach called mappings.
> Essentially, individuals would sign the name-to-address (or metadata
> to CHK) mappings. Each such entry would collect signatures by all the
> people who had investigated it and found it valid. Then you would
> list the people whom you had found to give trustworthy signatures on
> the mappings, and the software would check new mappings to see if they
> were signed by one of the people you trusted. You could perhaps
> extend this with some transitive trust model (where people could share
> their recommendations about whom to trust).

> I don't think this system can scale. You will have the same problem
> as with the PGP web of trust, namely that most people you want to
> communicate with are not signed by anyone you have ever heard of. The
> number of people in the world and the diversity of their interests
> makes me doubtful that you can expect to find a signature on a mapping
> that you will respect. Furthermore the number of signatures that
> would have to be kept on each mapping is huge.

I agree that this system cannot scale without some structure imposed
upon it. Instead of having anyone and everyone sign everything they
believe, a network of specialists would evolve to add value by creating
meaningful names for objects or evaluating useful metadata describing
them. I imagine that several services would provide top-level directory
trees which provide convenient and logical organizations for most
popular categories of data. The leaves of these top-level trees would
delegate well-known names to subsidiary organizations
(e.g. /com/us/microsoft would map to a value updated periodically to
reflect Microsoft's desired content). Competing outfits might offer
alternative layouts or specialize in particular subjects
(e.g. /entertainment/music/jazz/top-ten). Individual users would adopt
one or more of these under their private root so that they can obtain
access to global resources. In addition they can organize private parts
of their namespace as they see fit, such as recently referenced objects,
or favorite reviewers and commentators. In the www domain, this would
be like a combination of history list, bookmarks, and a weblog.

To handle dynamic content some objects, especially the leaf nodes in the
top-level trees, might really be certificates, containing a public key,
a CHK for a recent object instance, and a list of server addresses that
would provide signed, up-to-date contents.

> > You can think of these mappings (e.g. directory entries or web
> > links) as statements. Namely, principal A *says* name N *means*
> > content C. A signature connects "N -> C" to "A", it is essentially
> > a certificate.
...
> I'm not sure what you are proposing here, whether it is similar to the
> mappings concept Freenet explored, or perhaps a more direct use of
> crypto keys to control namespace. Freenet has a key namespace called
> SVKs (Signature Verification Keys) where a public key hash can be the
> root of a namespace, and the key holder can create any names he
> desires within that namespace. You can have a whole heirarchy rooted
> at a name which is essentially the hash of the public key. (Hence
> this is not a "friendly" naming system in itself.) This is useful for
> some purposes but does not solve the general problem of name mapping.

My proposal is somewhat like this, except I would use the certificates,
described above, instead of special casing hashes of public keys. In a
similar way, related groups of name mappings are collected into
"directories" and signed by specialists at multiple levels. Ultimately,
the user decides who he trusts to provide name mappings in his personal
root. I assume that reputation and widely used conventions will provide
order to the global namespace, so that most people will have the same
names for most objects.

> The non-crypto idea that Freenet has been exploring is essentially a
> voting scheme. Whenever you fetch a document you find out whether the
> name (or metadata) was good. You can then give some feedback about
> this fact back into the system, which will raise or lower the
> probability that the mapping will be found in the future.

This could work as long as someone with a well-known key and a
reputation collects the votes and periodically publishes the results.
Without this it seems that the scheme has no defense against
manipulation.

> You could have a hybrid scheme with signed mappings, and a voting
> based PKI similar to that proposed by Stubblebine and Reiter (where
> the amount you trust a key depends on how many certification paths
> there are to it). But in any system that will scale, you're going to
> end up trusting a lot of keys without much justification. In that
> case it is questionable if the crypto is buying you anything.

This is a pretty fundamental issue that needs exploration. I don't
claim to be an expert on the issue by any means, however, I don't think
the situation is this hopeless. In the SPKI (or is it SDSI?) model,
every name mapping is relative to the key which signs it: the "principal
A *says* name N *means* content C" business. This limitation bounds the
trust problem. You need a few widely trusted keys, redundantly signing
a few top-level directories and the rest takes care of itself in a
cross-linked flexible hierarchy of names and keys certifying other names
and keys. What crypto buys you is a way to understand the trust you
invest in these links. The reputation of the key depends on the care
with which it is used to sign things. While this isn't perfect, it is a
lot more than you have without crypto.

Ted Anderson




Archive powered by MHonArc 2.6.24.

Top of Page