process / update revoked and expired keys from WKD response

[tomholub]

related to #3017 . Here we build on this issue further, to look at revoked keys that were also received through the WKD. For example, if there is a revocation for the key we currently have in contacts database locally, and then another valid key, we can safely process the revocation (throw away the old local key?) and import the fresh, working key.

needed for upcoming key life-cycle functionality

I imagine this will be done after #3332

[rrrooommmaaa]

For example, if there is a revocation for the key we currently have in contacts database locally, and then another valid key, we can safely process the revocation (throw away the old local key?) and import the fresh, working key.

If we throw away the revoked key and then the user imports the old (unrevoked) version of it? Insecure.

[rrrooommmaaa]

Should we expect a situation when, for example, there are 2 subkeys of the key, and we receive 2 copies of the key, each of such copy has only a single subkey revoked? Then we need to somehow merge these packets to have both subkeys revoked in the storage.

[tomholub]

Should we expect a situation when, for example, there are 2 subkeys of the key, and we receive 2 copies of the key, each of such copy has only a single subkey revoked? Then we need to somehow merge these packets to have both subkeys revoked in the storage.

Great question - the answer is no. Our Email Key Manager does not create this situation - it revokes a whole key, not just some subkey. For users who host other type of WKD software, this situation is too esoteric to worry about right now. We could file an issue to think about it later, but for now think in terms of whole keys.

[tomholub]

For example, if there is a revocation for the key we currently have in contacts database locally, and then another valid key, we can safely process the revocation (throw away the old local key?) and import the fresh, working key.

If we throw away the revoked key and then the user imports the old (unrevoked) version of it? Insecure.

Good point - let's store the revocation locally instead of the original pubkey. With the revocation stored locally, we can take it into account when either updating pubkeys or when choosing pubkey to use, which is more secure. Thanks!

[rrrooommmaaa]

Do you mean to store revocation signature apart from the whole key? Or to store revoked keys separately?
We can just add a flag in the Key if there is revocation signature present