[Imported from Trac: page AccountingDesign, version 5]

warner 2008-06-30 22:39:57 +00:00
parent f039d4ae8c
commit f9f7061b5c

@ -94,6 +94,8 @@ the upload.
# Design Pieces # Design Pieces
Rough design tasks that need to be done.
* Add cred= to upload API * Add cred= to upload API
* client.upload() needs a cred= argument * client.upload() needs a cred= argument
* the webapi PUT/POST commands need a cred= argument * the webapi PUT/POST commands need a cred= argument
@ -118,3 +120,54 @@ the upload.
* web interface * web interface
* petname database / display * petname database / display
# Design
Things that we've come to an agreement about.
## Terminology
* pubkey: enough data to securely verify a signature
* pubkey identifier: enough data to securely identify a pubkey
* pubkey hint: when trying to find a pubkey that validates a signature,
the pubkey hint provides enough data to reduce the search
space to an acceptable level.
(Since we're planning to use ECDSA-192, public keys are short enough to use
them directly as both pubkey identifiers and pubkey hints. But if we were
using, say, RSA-2048, then we might instead want to use the SHA-256 hash of
the pubkey as its identifier. If we are tight on space, we can use an
arbitrarily short prefix of the ECDSA-192 public key as the pubkey hint).
## Lease Labels
Each lease will be labeled with a single public key. This identifies who is
responsible for the lease: which account should "pay" for the storage
required by this share. The actual definition of "pay" will depend upon the
server's policy: in most systems, simply being able to produce a total of the
sizes of all shares with leases held by a given user will be enough to make
decisions about that user (restrict to limit, pay-per-byte, nag-above-limit,
whatever).
## Certificate Chain
The v1 cert chain format: each element in the chain has three parts: the
encoded certificate, the signature, and the pubkey hint. The encoded
certificate has a number of fields that describe what is being delegated, but
the most important is a pubkey identifier that indicates to whom this
authority is being delegated. The fields we'll define for v1 are:
* delegate-pubkey: (string) a pubkey identifier. The holder of the
corresponding private key is hereby authorized to use the
authority of the signer, as attenuated by the remainder
of the fields in this certificate.
* signer-gets-lease: (bool) if True, the signer of this certificate will
be given a lease on the resulting shares. A privkey
authorized by this chain will have control over a
single full column of the lease table (all leases
labeled with the signer's pubkey). In a full request
chain (which contains a signed operation as well as the
certificate chain), there must be exactly one True
signer-gets-lease field, to make sure that there is
exactly one lease on the resulting share.
* other attenuations: TBD (things like until=, SI=, UEBhash=, operation=,
max-size=)