[tahoe-dev] Accounting, 2010 edition

[Greg Troxel]

Brian Warner <warner at lothar.com> writes:

> On 12/20/10 7:53 AM, Greg Troxel wrote:
>> 
>> As a concrete situation, it would be nice to target a friendnet grid
>> where we aren't particularly worried about malicious attempts to
>> cheat, but we do want to be able to observe how much space is person
>> is taking up.
>> 
>> That means we can leave out of increment 1:
>> 
>>   distribution of keys (can be manual)
>>   how to prove alice really is providing 3GB to the grid
>
> Absolutely. In fact, the first phase will just automatically create an
> "account" for any key that shows up, without even pushing the idea that
> the server should reject strangers. I guess the 1.5th phase is to
> provide manual keying and start rejecting newcomers.

Even if I could do a 'tahoe show-usage' and get something that is

blocks pubkey

and then a 'tahoe remove-all offending-pubkey' as a server admin that
would be a great start.

>> It's probably worth figuring out how to deal with keying, since it
>> seems like there is
>> 
>>   x509,  openpgp,  roll our own
>
> Yeah, I hear what you're saying, but I'm leaning away from both x509 and
> openpgp because I think they're a lot more complex than we need. All we
> really want is a signing/verifying keypair, and a way to express the
> verifying pubkey as an account identifier: no "Subject Names", no
> chained signatures, no need for encryption. PGP's web-of-trust scheme
> feels off, since we're talking about making "store data for this client
> or not" decisions, rather than "I think key X is really owned by person
> Y" decisions. There are similarities, but I'd worry that we'd be trying
> to mold Tahoe's Accounting needs into the framework offered by one of
> those keying schemes, rather than the other way around. Plus, I want to
> avoid adding new dependencies (like libgcrypt bindings, or some sort of
> x509 thing), or dragging too much new code into tahoe.

The WOT is what lets me as a server operator know that some pubkey
actually belongs to someone that I want to let store shares.  People who
are into tahoe are probably also doing pgp, and one can use the existing
checked keys for mails to bootstrap the tahoe access keys, distribute
the introducer URI, etc.

So perhaps we could just have a way to import a pgp key on the client to
use as the authenticator, and on the server to match up users/keys or to
have an allowed users acl, or something.  I didn't mean to use all of
pgp inside tahoe - just to use the same format and semantics so that one
could easily inject keys managed by opengpg into tahoe - and then tahoe
could decline to provide all the management/generation options.

> But take a look at the proposal and see what you think.. maybe there's
> some easy-enough way to leverage an existing format.

Is this in a file/ticket/web-page, or did you mean your recent long
email?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101220/dcf6c64c/attachment.pgp>