[Imported from Trac: page AccountingDesign, version 5]
parent
f039d4ae8c
commit
f9f7061b5c
|
@ -94,6 +94,8 @@ the upload.
|
|||
|
||||
# Design Pieces
|
||||
|
||||
Rough design tasks that need to be done.
|
||||
|
||||
* Add cred= to upload API
|
||||
* client.upload() needs a cred= argument
|
||||
* the webapi PUT/POST commands need a cred= argument
|
||||
|
@ -118,3 +120,54 @@ the upload.
|
|||
* web interface
|
||||
* 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=)
|
||||
|
|
Loading…
Reference in a new issue