[tahoe-dev] Tahoe and restricting uploads

[Brian Warner]

On Sat, 22 Nov 2008 17:16:33 -0800
Nathan <nejucomo at gmail.com> wrote:

> The idea is to represent the ability to create a new file or directory
> as a capability.

Yeah, our basic plan is to express this "allocate storage" capability as a
private key (or a certificate chain that references some private key).

> The alteration would only change the mkdir and new_file operations to:
> mkdir(creationcap) -> writecap
> new_file(creationcap) -> writecap

Yeah, but my current thinking is to require the creationcap for update_file()
and update_directory() too. I'm intrigued by the properties we get if that's
not required, though. OTOH, if you can't upload a new file, that reduces the
number of ways you might usefully update_directory() (you could only delete a
child or add some pre-existing child that you already knew about).

> A minimal implementation might configure the creationcap by requiring
> the user to place a public key representing the grid-wide creation
> capability prover into their tahoe config.  The grid owner would
> carefully hand out the private key.

I think that matches what our plans are, except that I'd express it as:

 The storage server operator places a public key in their tahoe config.

The storage server operator is thus saying "I am willing to provide storage
space to anyone who holds the corresponding private key, or has been
authorized by someone who holds that key". A lot of the Accounting work is
tied into how the authorization/delegation process is tracked.

For allmydata, we'd have a single master private key, and the storage servers
would be configured with the matching public key. Each account-holder has
their own personal private key, and when you sign up for an account, we sign
your personal key with the master one. The account-holder then presents a
chain of (signature, personal key) to the storage server, which validates the
chain and accepts the write request.

In practice, there are a lot of details involved: getting from posession of
an authorized private key to a server accepting your request takes several
steps, and there are replay attacks and server-1-spoofs-user-to-server-2
attacks to be dealt with. We're using the term "furlification" for this
process: getting from public/private keys to a secure reference to some
empowered object facet.

> Is implementing this simple?  Does it represent a meaningful axis for
> representing capabilities?

Not simple, but yes, I think it's basically the direction we're heading.

We need the delegation / certificate-chain bit, so we can keep track of who
created each share, for accounting. It seems natural to combine this with
storage authority: the key represents the right to create shares that are
labeled "Bob" (you can't create shares labeled Alice, you can't create
unlabeled shares).

cheers,
 -Brian