A few pub keys for a recipient. Creating an encrypted message

[DenBond7]

Creating an encrypted message

When we create a new message we check if a user has a pub key. But before we had one user <-> one pub key.
After changes a user can have a few pub keys with different states, for example:

1. one good + one expired
2. one good + one good
3. one expired + one expired

How to handle such cases?
What color should I use for chips in these cases?

Originally posted by @DenBond7 in #1188 (comment)

[tomholub]

For color choice, see public key ordering + coloring: #1188 (comment) . As before, if color of any recipient is non-green, then they don't have any good public key and therefore message cannot be sent - they should see a modal.

Here are also some test emails for manual testing: FlowCrypt/flowcrypt-ios#744

Here are modal messages listed: FlowCrypt/flowcrypt-ios#732

For public key choice during encryption, filter recipient keys to only choose the valid ones.

Let's say that your example are three recipients:

A: one good + one expired
B: one good + one good
C: one expired + one expired

These happen to be correctly ordered public keys as per #1188 (comment) (valid first). Based on that, first user is green (per first already ordered key), second key also green, third is orange. Because of C, the user will se an error modal.

For this example:

A: one good + one expired
B: one good + one good

The message will be encrypted for 3 public keys for recipients which is [A-good-1, B-good-1, B-good-2] plus also all of my own public keys that are valid & match by the matching logic based on sender email that we already have. So if I have two such matching keys of my own, then in this situation I could be encrypting for 5 pubkeys total to send to these two recipients.

[DenBond7]

Based on all info that I read I'd like to add more details. I see the following(if not first, then second, and so on)

• GREEN -> a recipient has at least one usable key (non-revoked, non-expired, well parsed. To be short - a good key)
• ORANGE -> a recipient has at least one usable key, but it's expired or revoked
• RED -> a recipient has at least one pub key, but it's not usable(wrongly parsed and so on)
• GRAY -> a recipient has no pub keys

on this stage, I don't need to sort keys. Just need to check conditions to define a color.

[tomholub]

By sorting and then evaluating the first (best) key, it makes the logic simple and fool-proof. Also consistent with other platforms.

Your list doesn't mention revoked keys. Is the current code checking if the key is revoked?

[tomholub]

You can test manually with this email. Can also load this public key into your mocks / automated tests.

[tomholub]

[DenBond7]

Is the current code checking if the key is revoked?

No, we don't support that on Android. Could you share details how to do that?

[tomholub]

PGPainless should give you information about whether a public key is revoked or not. If not sure how, ask Paul. Maybe the PGPainless readme needs a section about parsing keys and getting details out of them?

[DenBond7]

Got it, thanks. I will check.

[IvanPizhenko]

What about revoked keys? As I remember, browser extension takes them into account too. Do they fall into category of keys marked with RED?

[DenBond7]

[tomholub]

very good