Skip to content
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

Key rotation within continuation #85

Closed
jricher opened this issue Nov 13, 2020 · 8 comments
Closed

Key rotation within continuation #85

jricher opened this issue Nov 13, 2020 · 8 comments

Comments

@jricher
Copy link
Collaborator

jricher commented Nov 13, 2020

§5 Continuing a Grant Request: Editor's note:

We need to have a secure way to rotate the key used for the continuation here. In most cases this will be a rotation for the client instance, since a client without an instance record would likely just present a new key for a new request. In that case it could go with the client management, above - but it doesn't necessarily have to be.

@TomCJones
Copy link

TomCJones commented Nov 30, 2020

See my comment on pull request #132
I think we need to find a single rotation recovery method.
I collected my ideas here: https://tcwiki.azurewebsites.net/index.php?title=Recovery#Proposed_for_Standardization

@fimbault
Copy link
Collaborator

This is close to what I was thinking about. I would also add as a reference what KERI is doing on key rotation, for discussion purposes.

@jricher
Copy link
Collaborator Author

jricher commented Oct 5, 2022

Key rotation is now handled on the continuation access token, not as part of the grant update. See #435

@jricher jricher closed this as completed Oct 5, 2022
@adeinega
Copy link
Contributor

adeinega commented Oct 5, 2022

Could you answer on #435 (comment) and other comments in this PR? Thank you.

@fimbault
Copy link
Collaborator

fimbault commented Oct 6, 2022

what do you mean by "more or less gracefully" ?

@adeinega
Copy link
Contributor

adeinega commented Oct 6, 2022

@fimbault, you can omit "more or less gracefully", I wanted to know if GNAP allows to address the use case I provided

It could be useful when there are multiple running instances of the client and it's tough, or even impossible, to update the keys on all these instances immediately (just as an example, the client instance could be deployed as a service in K8S).

and

am I right that previous_key becomes immediately invalid?

@fimbault
Copy link
Collaborator

fimbault commented Oct 7, 2022

Indeed the idea currently is that previous-key is replaced by the new key, for all what's coming afterwards.
I know of some systems that allow a delay during which both versions coexist, is that what you're after ?

@adeinega
Copy link
Contributor

adeinega commented Oct 7, 2022

There are plenty of systems where both, or even more versions coexist until an administrator or a client itself decides to remove/invalidate previous keys. That's correct.

The same approach arguably is even way more valuable for RSs. BTW, are you planning to allow them to rotate their own keys?

You are writing these specs, and IMO, you still have time to add & embed these features into the core of GNAP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants