| 123 | = Design = |
| 124 | |
| 125 | Things 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 |
| 136 | them directly as both pubkey identifiers and pubkey hints. But if we were |
| 137 | using, say, RSA-2048, then we might instead want to use the SHA-256 hash of |
| 138 | the pubkey as its identifier. If we are tight on space, we can use an |
| 139 | arbitrarily short prefix of the ECDSA-192 public key as the pubkey hint). |
| 140 | |
| 141 | == Lease Labels == |
| 142 | |
| 143 | Each lease will be labeled with a single public key. This identifies who is |
| 144 | responsible for the lease: which account should "pay" for the storage |
| 145 | required by this share. The actual definition of "pay" will depend upon the |
| 146 | server's policy: in most systems, simply being able to produce a total of the |
| 147 | sizes of all shares with leases held by a given user will be enough to make |
| 148 | decisions about that user (restrict to limit, pay-per-byte, nag-above-limit, |
| 149 | whatever). |
| 150 | |
| 151 | == Certificate Chain == |
| 152 | |
| 153 | The v1 cert chain format: each element in the chain has three parts: the |
| 154 | encoded certificate, the signature, and the pubkey hint. The encoded |
| 155 | certificate has a number of fields that describe what is being delegated, but |
| 156 | the most important is a pubkey identifier that indicates to whom this |
| 157 | authority 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=) |