search

boltlabs-inc / key-mgmt-spec

Formal specification for the key management project
MIT License
3 stars 2 forks source link

Rewrite generate and import protocols #143

Open marsella opened 1 year ago

marsella commented 1 year ago

The generate and import protocols are very similar for different key types (arbitrary secrets, signing keys). Right now, there is a single "full" protocol written for arbitrary secrets, and the signing key section has a list of modifications necessary to modify the protocol.

These should be combined into a single protocol write-up with options at each step that requires different behavior for different key types.

Furthermore, generate and import both have two protocol versions: one where the client encrypts the secret and uses the server for encrypted storage only, and one where the server knows and encrypts the secret (and still stores it). These should also be combined into a single protocol.

While rewriting these, update the names for secrets to something more general. Right now, the secret value is usually called arbitrary_key, but it could be changed to key or another appropriate name.

indomitableSwan commented 1 year ago

We probably also want to combine e.g., both types of "generate" protocols and both types of "import" protocols.

marsella commented 1 year ago

Aren't there some key types were we don't want to support both types of generate protocol? E.g. we said it doesn't make sense to do server-generated arbitrary keys (EDIT: #139).

indomitableSwan commented 1 year ago

Aren't there some key types were we don't want to support both types of generate protocol? E.g. we said it doesn't make sense to do server-generated arbitrary keys (EDIT: #139).

Looking ahead: when we have key types that support shared control, we will not want to support local-only generation of keys for that key type. Right now we've only been talking about building "unilateral control" type keys. (As an aside, I do not think this terminology is the best and I think we ought to try to clarify custody versus control-via-policy-engine concepts for key types soon.)

In terms of the specific question you raised and the linked issue #139: I definitely didn't want to devote resources right now to implementing support for server-generated arbitrary keys. And it's true that I'm unclear about the use case for this feature. But I'm not ready to make a firm decision on this point: for example, there may be some related use cases we haven't thought about yet for the MPC case. That is, I'm fine with removing this from the spec for now as per #139, but see the following point:

I want us to have a strategy for specification and implementation where it's easy to support functionalities for multiple key types (or not, as the case may be). i.e., we should combine protocols where possible, reduce overlap between protocols, and keep things as simple and extensible as possible. That is, if we want to build in support for the use case removed in #139 at a future date, it shouldn't be difficult and it shouldn't involve writing a whole new protocol.