Support multiple Submission Keys

[zenmonkeykstop]

In some cases, SD instances may have multiple Submission Keys in use - the latest active one as deployed on the server, plus an arbitrary number of old Submission Keys in the SVS or SDW's sd-gpg, kept around to decrypt old submissions.

SecureDrop Client doesn't distinguish between keys. If submissions encrypted against older keys are present, and the keys in question are in sd-gpg, they will be decrypted and displayed as normal. sdw-admin, however, only supports configuring with a single key at a time. If you want to add multiple keys via sdw-admin --apply, you need to update config.json (and thereby qubesdb) with each new key's details and rerun the command.

This is suboptimal for a number of reasons: short of deleting and reprovisioning sd-gpg from scratch, there's no way to ensure that only the expected keys are present; config.json doesn't actually describe the state of the system; and it's just a bad UX in general with lots of potential for errors.

Instead:

• config.json should support listing multiple key FPRs instead of just one.
• sdw-admin --apply should ensure that all listed keys and only listed keys should be present in sd-gpg
• (optional) it should not be necessary to keep secret keys in dom0 - if they're already in sd-gpg then they would not be updated. If they're not in sd-gpg they should be temporarily available in the dom0 sdw config dir, and removed after successful provisioning to sd-gpg (struck after comments)
• (optional) it should be possible to provision either a full key or a key stub associated with a private key on a smartcard (like a Yubikey).

[deeplow]

This feels like a potentially relatively small and well-scoped problem to tackle and possibly include in the next workstation release.

config.json should support listing multiple key FPRs instead of just one.

👍

sdw-admin --apply should ensure that all listed keys and only listed keys should be present in sd-gpg

What would be the downside of keeping old keys? We could also just reconsider recreating sd-gpg but for that it would be useful for the keys to also exist in dom0.

(optional) it should not be necessary to keep secret keys in dom0 - if they're already in sd-gpg then they would not be updated. If they're not in sd-gpg they should be temporarily available in the dom0 sdw config dir, and removed after successful provisioning to sd-gpg

Would the argument for this be that the less places we have the key in, the better? In general I find that having one source of truth (i.e. dom0 in this case) and being able to recreate things at will, to be a pretty useful position to be in. Also, when someone does sdw-admin --uninstall it nukes everything except for the config and keys and that can save a lot of time in some situations when an admin is just trying to rebuild the system and without needing through the effort of retrieving a potential backup of the key from cold storage. Without having it in dom0 it could be a bigger headache (and asking to send the GPG from sd-gpg back to dom0 would not be a very good idea, methinks).

Btw, looking at this I've realized that we're currently importing the key via salt file.managed but we could even make use of the qubes.GpgImportKey RPC service which basically does the same thing.

[zenmonkeykstop]

To the first point, IMO it's better in general to be able to define what keys are expected to be present, so you can tell if there are are deviations from state.

But I now realize that this actually is in conflict with the second point you mention (questioning not keeping key copies in dom0) so maybe that one needs to be struck? If you both have the exact expected fingerprints in the config, and the keys backed up in dom0, you're rigght, we could recreate sd-gpg consistently anytime.

[deeplow]

When we tackle this, it could be a good chance to do also improve #1197