From f9f7061b5cae9e2169505d3f5f22560673e0b613 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Mon, 30 Jun 2008 22:39:57 +0000
Subject: [PATCH] [Imported from Trac: page AccountingDesign, version 5]

---
 AccountingDesign.md | 53 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/AccountingDesign.md b/AccountingDesign.md
index 25522dd..210bbeb 100644
--- a/AccountingDesign.md
+++ b/AccountingDesign.md
@@ -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=)