[tahoe-dev] Accounting, 2010 edition

[Brian Warner]

On 12/21/10 5:56 AM, Greg Troxel wrote:
> 
> and avoid reinventing the trust management wheel
> 
> Your comment made me realize more crisply that the real property I want
> From pgp is to be able to manage keys via pgp and then easily insert
> them into tahoe.  I really do mean "manage via and insert", not "send
> email with keys as content that people will cut/paste".

Hmmm. The first step is probably visualizing the UI. Like David-Sarah, I
too am wary of sharing key material between uncoordinated protocols, but
that shouldn't rule out an easy-to-use workflow.

Alice and Bob already know each others PGP keys (they're present in the
keyrings, and have some non-zero quantity of trust associated with
them). Alice wants to tell her tahoe storage server to accept shares
from Bob. She could run a tahoe command like:

 tahoe admin accept-shares-from pgp=Bob

where "Bob" can be used as a PGP key identifier (so it could be a hex
keyid, or an email address, or anything such that 'gpg --list-keys Bob'
will return a single value). She's telling her storage server to accept
shares from any tahoe client key for which there's an authorizing
signature from Bob's PGP key. Her node stores this in a table of keys to
accept, with the "pgp=" marker reminding her that this is a PGP key, not
a native ECDSA tahoe client key.

For Bob's side, his PGP key needs to make that signed message. So maybe:

 tahoe admin pgp-sign-clientkey -u Bob

which would generate a correctly-formatted authorization, invoke 'gpg
--sign -u Bob' on it to generate an ascii-armored message, then store
that message in the tahoe node's basedir. Later, when Bob's client
connects to Alice's server and negotiates to get access to his
RIAccountableStorageServer instance, his client includes this message as
an argument (maybe in a "reasons you should accept my shares" dictionary
named "why=", so the server can only pay attention to the reasons that
they'll accept.. other parts of the dictionary could include other
reasons, like third-party introductions, offers of money, or proof of
storage-in-kind). If Alice's table of keys-to-accept includes a pgp=
marker, her node forks off a copy of GPG to check the why["PGP"]
message, and accepts the client-key if it is signed by Bob.

The authorization message that Bob PGP-signs would probably be a JSON
blob with a distinctive format and magic number, so no other messages
that Bob has signed could accidentally be interpreted as an
authorization. Maybe something like:

 { "this-is-my-Tahoe-client-key": 123abc456def,
   "please-store-shares-from-it": true }


When we get around to handling the other direction (telling your node
which *servers* you're willing to upload shares to), we could use this
same scheme, but the signed message would be included as an extra field
in the #466-based Announcement dictionary. Clients who receive
storage-server announcements and are deciding whether to use them will
compare each one against the which-servers-do-i-use table, which can
include pgp= markers like above.

Ideally, the non-PGP case (using native ECDSA clientkeys) has a very
similar UI:

 tahoe admin get-my-clientkey
 tahoe admin accept-shares-from 123abc456def

(where Bob runs the first command to find out what his clientkey is, so
he can mail it to Alice)

Some other thoughts:

 * the clientkeys will need a distinctive prefix, like "pub-", so you
   know what it means to share them with someone. Private key material
   should be visibly obvious, so you don't share it by accident.

 * most interactions should reference petnames instead of raw keys.
   Associating a petname with a key should happen as soon as the key is
   added. So maybe:
    tahoe admin accept-shares-from bob pub-123abc456def
   Then you could do:
    tahoe admin get-usage bob
    tahoe admin freeze-storage bob

 * should clientkeys and serverkeys be the same? I think it's easiest to
   think of these keys as proxies for people ("let Bob store shares on
   my box", not "let Bob's computer store shares on my box"). If we
   treat them that way, then using just one key for both client-side and
   server-side makes a lot of sense. But we should be clear as to what
   these keys represent: if we really want them to represent computers,
   not people, then maybe there should be two distinct keys.


cheers,
 -Brian