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

[tomholub]

We can just add a flag in the Key if there is revocation signature present

This is what I meant - add a revoked flag to ContactStore.

For the actual revocation, I think it can come as a stand-alone revocation signature, or as a revocation signature tagged onto the original key. Is that true? If yes, then we should ideally settle on which format should the FlowCrypt WKD serve, and then implement for that scenario on the client.

Do you mean to store revocation signature apart from the whole key?

I was thinking to store the whole public key that includes the revocation in it.

But actually, storing the revocation only next to the key, instead of in it, is also feasible. Then the presense of the revocation would also serve as a flag.

Did I understand you correctly? I'm not sure which is better.

[tomholub]

Presumably, we would not have to store the revocation on the client at all. And only store the flag. That would be the easiest.