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?
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.
@cjwatson Note I went back on that above, and suggested a more clear cut implementation which rejects anything going in for a disabled key. I will strike the first suggestion to avoid misunderstandings.
With that said, I’m hoping we can do better on real expiration of the key, per some exchanges we already had on the topic. Timestamps would indeed be part of it, and we can also introduce a mechanism that lists known signatures at the time of expiration and prevents at least a well defined class of assertions from being accepted if they’re not on that list. This would be a way to prevent stolen keys from being used to sign documents seemingly in the past.
I think --disabled Is the right term. I think we should detect when there are disabled keys and note that they are not shown, to guide people to this option.
We need to document the signing journey on snapcraft.io/docs. Giving end users a vendor signature on the revision they can verify came up at the Rally and we had to invite people into the room to explain it.
Any updates on documenting the signing journey? I’m working with @arunlee on signing images and we have an account where we would like to revoke the key. Even if it’s not documented, please guide on how to proceed to revoke the key and create a replacement signing key for image.
I was looking for the same thing, but still don’t see a way of doing it at this moment.