Changes between Version 4 and Version 5 of AccountingDesign


Ignore:
Timestamp:
2008-06-30T22:39:57Z (16 years ago)
Author:
warner
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AccountingDesign

    v4 v5  
    9595= Design Pieces =
    9696
     97Rough design tasks that need to be done.
     98
    9799 * Add cred= to upload API
    98100  * client.upload() needs a cred= argument
     
    119121   * petname database / display
    120122
     123= Design =
     124
     125Things that we've come to an agreement about.
     126
     127== Terminology ==
     128
     129 * pubkey: enough data to securely verify a signature
     130 * pubkey identifier: enough data to securely identify a pubkey
     131 * pubkey hint: when trying to find a pubkey that validates a signature,
     132                the pubkey hint provides enough data to reduce the search
     133                space to an acceptable level.
     134
     135(Since we're planning to use ECDSA-192, public keys are short enough to use
     136them directly as both pubkey identifiers and pubkey hints. But if we were
     137using, say, RSA-2048, then we might instead want to use the SHA-256 hash of
     138the pubkey as its identifier. If we are tight on space, we can use an
     139arbitrarily short prefix of the ECDSA-192 public key as the pubkey hint).
     140
     141== Lease Labels ==
     142
     143Each lease will be labeled with a single public key. This identifies who is
     144responsible for the lease: which account should "pay" for the storage
     145required by this share. The actual definition of "pay" will depend upon the
     146server's policy: in most systems, simply being able to produce a total of the
     147sizes of all shares with leases held by a given user will be enough to make
     148decisions about that user (restrict to limit, pay-per-byte, nag-above-limit,
     149whatever).
     150
     151== Certificate Chain ==
     152
     153The v1 cert chain format: each element in the chain has three parts: the
     154encoded certificate, the signature, and the pubkey hint. The encoded
     155certificate has a number of fields that describe what is being delegated, but
     156the most important is a pubkey identifier that indicates to whom this
     157authority is being delegated. The fields we'll define for v1 are:
     158
     159 * delegate-pubkey: (string) a pubkey identifier. The holder of the
     160                    corresponding private key is hereby authorized to use the
     161                    authority of the signer, as attenuated by the remainder
     162                    of the fields in this certificate.
     163 * signer-gets-lease: (bool) if True, the signer of this certificate will
     164                      be given a lease on the resulting shares. A privkey
     165                      authorized by this chain will have control over a
     166                      single full column of the lease table (all leases
     167                      labeled with the signer's pubkey). In a full request
     168                      chain (which contains a signed operation as well as the
     169                      certificate chain), there must be exactly one True
     170                      signer-gets-lease field, to make sure that there is
     171                      exactly one lease on the resulting share.
     172 * other attenuations: TBD (things like until=, SI=, UEBhash=, operation=,
     173                       max-size=)