-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable moving keys #283
Comments
9 tasks
13 tasks
This could easily be achieved using #[derive(Procedure, Debug, Clone, Serialize, Deserialize)]
pub struct MoveKey {
#[source]
source: Location,
#[target]
target: Location
}
...
#[execute_procedure]
impl DeriveSecret for MoveKey {
type Input = ();
type Output = ();
fn derive(self, _: Self::Input, guard: GuardedVec<u8>) -> Result<Products<()>, FatalProcedureError> {
OK((*guard.borrow()).to_vec())
}
} |
6 tasks
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Add a function to move a key from one location to another. This way we can generate a key at some random location
xyz
, use the some part of the key (e.g. public key) to generate the actual locationlocation
, and then move the key fromxyz
tolocation
.Motivation
We would like to have this in identity.rs for two reasons.
We would like to use a DID of an identity in the locations for everything that is stored for that identity. The DID itself is the hash of the public key of the initial keypair. So if we want to store the initial keypair at a location that is based on the DID, we have a circular dependency. Currently, we generate the keypair in-memory to work around this limitation, but this is less secure than being able to generate it in Stronghold directly.
When creating a new verification method
key-1
, we generate a new key in stronghold. If we later want to update the key material of the methodkey-1
, we cannot use a location that is only based on the uniquekey-1
identifier. This is because we may need the old key in order to sign a new document update, and only then could we get rid of the old key. Our current solution is to keep some extra state which is part of the location. We might move to a new approach where the public key together with the fragment is used as the location, so that twokey-1
's with different underlying key materials yield two different locations. That way, we don't have to keep the additional state, reducing complexity.Requirements
Add a method along the lines of
that moves the key (names are suggestions, feel free to change).
Are you planning to do it yourself in a pull request?
No.
The text was updated successfully, but these errors were encountered: