How to unregister a store signature key

Hi,

I am trying to make my own core image as in https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#3.

How do i un-register an already existing key?

Thanks for the help

regards
Arun

In theory, this should be possible assuming you never signed anything in the store. If you did sign something, you’d need to be more clear about what you mean by removing the key, as the signed things can’t just sit there with an unknown key. It would likely need to be revoked instead.

But I would say we likely don’t support removing keys today, for those reasons. Needs proper handling instead of just deleting a key.

@sergiusens @evan ?

I have not published anything yet, but have some keys which i have created , but want it to be cleaned up.

This case should be easier to handle, but the store still needs to make sure that there’s nothing signed, so perhaps it wasn’t implemented yet.

@pedronis Do you know what’s the status of that?

Implementation was started but is not finished yet, Colin was working on it initially.

The most straightforward implementation would be to just flag it with some sort of tombstone, stop listing it, but still having it available through the assertion API.

@cjwatson Do you have news on that front?

This was the related PR that was closed long ago: https://github.com/snapcore/snapd/pull/2083

It’s related, but that PR sounds more like the conversation we were having today in the call. The case here sounds simpler, and it’s more of a usability one. The key was uploaded, and now it’s being listed, but we don’t care about this key anymore and don’t want to see it listed. We should probably just flag it somehow and ignore it otherwise. In fact, it’s a good thing not to remove it completely from the server, not only because there might be signed things that we want to understand in the future, but also because the user may later decide to come back and issue a more definitive revocation request that invalidates signed things.

ok, we have no design atm for that sort of thing. Also leaving a key active but ignored seems dangerous to me.

It would definitely not be active anymore, for potential meanings of “active” I can think of.

I’m probably not understanding, if the public key is around (and can be obtained by assertion service) and there’s not revocation, it’s active. You probably mean something else with “active”.

Yeah, in that sense it would be active indeed. I meant the store would not accept any further content signed with that key, but the key was not revoked and anything signed with it continues to be valid. It’s a lightweight solution to the usability issue we see reported in this topic, when someone uploads a key but then want to get rid of it as it ended up not being used, or used for trivial things which are not important.

The key should not be completely deleted both because we may end up seeing data in the wild that we’d like to be able to at least associate with that key (whether we consider it valid or not), and also because we should preserve the ability of creating a more formal revocation notice for the key if it is found (probably by the user) to have been abused.

Once we have that mechanism we discussed today, we might also create a more clear tombstone for the lightweight operation which lists the specific things that were knowingly signed and should be accepted from there on.

the issue is here is that the most important things signed with 3rd party keys at the moment are models, those are not distributed by the store but via images, the store sees them as a side-effect

That shouldn’t be much of an issue considering the ideas above still. Also, most important depends on the observer.

As I said I don’t think I understand the ideas, it sound like expiration (vs revocation) but only internal to the store? flagged where, in the account-key assertion? just in the store? (but the store is not the only user of keys)

As mentioned, the goal here is solving a usability issue. This is not expiration or revocation. It simply interprets the action as the user would like to stop using this key. Think disabled, and consequences falloff from that. We won’t list the key (unless –disabled or something), but we also won’t reject data that was previously signed with it. Given the lightweight nature of the operation, we might accept timestamps here as an indicator of whether it should be accepted or not, and in cases where data is being newly created (e.g. a signed snap is being uploaded) we’d reject it. (update: per notes below, it’d be better to have a more clear no-new-data policy for disabled keys)

This would not be a replacement for real expiration and real revocation. We still want those.

Or maybe to define a clearer line, we just don’t take new data at all that was signed with the key. We still serve existing assertions, if any, but we wouldn’t accept any new data signed with such a disabled key, model or otherwise.

ok, very store centric, so the store would reject something new, but a device wouldn’t because the info is only local to where the key is kept and in the store?, that’s a bit of a confusing state, anyway it needs input from more store people than just me

Yes, very store centric, which I think is exactly the usability issue at hand. You upload a key, and then you regret, and today this is a very expensive operation to undo and even to understand how to get out off. This would solve it, without any additional security issues that don’t exist today already with that key lingering in the store. Actually, the current situation is worse because we still take new data for that key and distribute it, if it comes.

The suggested behavior is very easy to understand as well, which is a good property security-wise: we just won’t take further data signed with that key. Nothing else changes. That also means, once more, that expiration and revocation still need proper handling.

I’m afraid I haven’t done anything with it since my previous PR. (build.snapcraft.io kind of happened in between.)

I don’t really see a difference between your proposals downthread and what I understood to be planned for expiration. You say “Given the lightweight nature of the operation, we might accept timestamps here as an indicator of whether it should be accepted or not, and in cases where data is being newly created (e.g. a signed snap is being uploaded) we’d reject it”, which is exactly the semantics I understood expiration to be intended to have.