Rotation of Root Keys

[sabada]

Hi,

I just had a quick question regarding the rotation of root keys. I see that when I rotate a root key, I must sign it with the old key, and I then need both root keys otherwise I get an error saying it is missing. (If I do a rotation then I need all previous root keys)

I looked through previous issues and I wasn't sure if I 100% was understanding, but I believe from also reading the TUF spec that both the old and new key should continue to work separately but once the client updates the old key won't work anymore.

Am I just misunderstanding something here or is there any way I can remove the old root key without any future errors occurring?

Thank You!

[riyazdf]

hi @sabada - yes indeed, you will need to sign with the previous key when performing a root rotation to a new key.

There's some discussion in this related issue #835 about our current design decisions in notary to version old root roles and keep keys in those roles, as well as a proposal to change that mechanism. If you'd like to follow up here, or in that issue (and close this one), either way is fine :)

[sabada]

Thanks for the response,

So looking at this comment the reason I am being asked for all my root keys is because after rotating is that root.json has not been signed by the new key so it asks for all the keys in between?

[riyazdf]

Hi @sabada - the comment you linked to is a proposal for changing the current mechanism.

Currently as specified by TUF, it's required to sign with all old keys until all clients have seen the new version -- but it's unreasonable to make any assumptions about when clients will see the new root.json, so it's advisable to additionally sign with old root keys forever.

This comment on the issue you linked to contains more details about how root rotations are currently implemented in notary.

[sabada]

Ahh that makes sense, so if I really wanted to completely get rid of old keys I would have to manually edit root.json, otherwise I should be using old keys as well every time?

[riyazdf]

Yes - the list of keys in the keys section of root.json is used to enumerate the valid keys that could be used for signing -- so you could indeed remove the old keys from the root.json.

However, if you manually remove the old keys (or just choose not to bring the private key material online at signing-time) you will not sign the root with the old keys and therefore risk breaking clients who have not updated in a while and have only seen those old keys (and not the new ones).

[sabada]

So whenever I rotate my root key, it should add to my root.json correct? Because I noticed when I rotate once, root.json is not touched, but then when I rotate a second time, then it is modified.

[riyazdf]

@sabada - this is because your notary client will auto-publish to the server but does not have the same root.json cached locally. If you run a notary list <GUN> your local root.json should update accordingly.

[sabada]

Ahh, that makes sense. I know see it being updated. So then if I wanted to edit root.json locally, I would then have to publish the changes to the server? Otherwise my cached version would eventually get overwritten?

So right now if I edit root.json and then try to do like notary list <GUN> I get an error saying fatal: could not validate the path to a trusted root: failed to validate integrity of roots but if I delete my root.json and then do notary list <GUN> it works fine and creates a root.json

[riyazdf]

Ok, glad that you were able to see the updates. For root, snapshot, and timestamp key rotations, we publish the change directly to the notary server. Running notary list or any other online notary command will make your client fetch the latest updates from the notary server before mutating or presenting any data.

Right now, the error you're running into is that the new root that you've modified on disk does not have valid signatures that verify against its listed keys to reach its threshold - and when you delete the root and notary list, you're getting back the root.json before it was edited because the edited version was never published.

If you were able to manually edit around that, you'd probably run into another error because the hash of the root would not match any published hash in a snapshot file. Currently, we don't have a notary CLI workflow for removing keys from a root.json and publishing that removal to the notary server with a proper snapshot, though the issue I linked to earlier has some ideas and proposals.

[endophage]

Conversation seems to have wrapped up here and there are no actionable items as far as I can tell. Closing the issue. Feel free to reopen or file a new issue if there's something I'm missing.