[tahoe-dev] Accounting, 2010 edition

[David-Sarah Hopwood]

On 2010-12-20 23:42, Greg Troxel wrote:
> 
> 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.

-1 on having Tahoe depend on use of PGP.

It's a strictly weaker assumption that users have some way of communicating
Tahoe pubkeys with authenticity, than to assume that they are using PGP.
If they *are* using PGP, then they can communicate the Tahoe pubkeys in
PGP-signed emails; that's not really any less usable than having them
directly be PGP keys.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101221/3bf1cc22/attachment.pgp>