Management canister API for threshold key derivation (vetKD)#3763
Management canister API for threshold key derivation (vetKD)#3763
Conversation
…ints (#2633) This PR defines names and arguments of the new functions: - ReshareChainKey - VetKdPublicKey - VetKdEncryptedKey A corresponding interface spec PR can be found [here](dfinity/portal#3763). For now, all functions remain unimplemented. In addition, we implement routing of these methods by calling `route_idkg_message` with the correct `MasterPublicKeyId`. This function will be renamed and tested for the vet KD case in a follow up PR.
…ints (#2633) This PR defines names and arguments of the new functions: - ReshareChainKey - VetKdPublicKey - VetKdEncryptedKey A corresponding interface spec PR can be found [here](dfinity/portal#3763). For now, all functions remain unimplemented. In addition, we implement routing of these methods by calling `route_idkg_message` with the correct `MasterPublicKeyId`. This function will be renamed and tested for the vet KD case in a follow up PR.
fspreiss
changed the title
…crypted_key -> vetkd_derive_key; encryption_public_key -> transport_public_key
Performs the following renamings in the vetKD API in accordance with the [latest changes](dfinity/portal@add1c71) in the [spec PR](dfinity/portal#3763): * `derivation_id` --> `input` * The name `derivation_id` often caused confusion and `input` is a more standard name in the context of key derivation schemes. * `derivation_domain` ([previously](#4049) `derivation_path`) --> `context` * The main use case for the derivation domain/path is to do domain separation, i.e., to specify the context in which the derived keys are to be used. Given this, directly calling it context seems beneficial in that it makes the meaning of the field more clear and intuitive, and thus the API easier to use. * `vetkd_derive_encrypted_key` --> `vetkd_derive_key` * Although the fact that the returned key is encrypted is relevant in that it ensures that nodes cannot see the key in clear text, this can be considered an implementation detail. Also, the name `vetkd_derive_encrypted_key` is somewhat long. In any case, in the returned struct the (single) field is still called `encrypted_key`, so it is still explicit that the returned key is encrypted. * `encryption_public_key` --> `transport_public_key` * Everyone everywhere (in publications, slides, demos, etc.) called this "transport public key". The reason this was not called transport_public_key in the API so far was because the containing API method was called `vetkd_derive_encrypted_key` and the name `encryption_public_key` should have made it clear that it is this very public key under which the _encrypted key_ is encrypted. Now that we are removing the part `encrypted_` from the API name, this reason is obsolete and we are free to call it `transport_public_key`.
|
The merged PR #4110 introduced the system API for vetKD cost, including a reference to the management canister endpoint. I noticed that the names for both the system API and the management canister endpoint were updated in this PR. Could you please ensure the documentation reflects these changes to avoid any inconsistencies? https://github.com/dfinity/portal/blame/d21d728fce42875832202d46c4410172514dfe3d/docs/references/ic-interface-spec.md#L1549 |
@fspreiss It seems you renamed the API from derive_encrypted_key to derive_key in this PR incl. the system API to get the cost. Could you please perform this renaming in this spec PR, too? |
5 participants
Proposes two new system APIs for the prospective threshold key derivation (vetKD) feature in the management canister.
Notes
Alternatives considered
We considered the following alternative API, where one would have two sets of API pairs: one pair for threshold key derivation, and a second one for threshold BLS signatures.
This alternative was discarded, however, because there is a concern that not all possible future use cases can be covered with this split API approach.
TODOs