@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.
