A few pub keys for a recipient. Importing pub keys on the compose screen

[DenBond7]

Importing pub keys

Here we can have two cases:

1. key with a single user id: for example key for A@flowcrypt.test It's a simple case.

Here we have the same behavior as before.

2. key with a few user ids: for example key for A@flowcrypt.test, B@flowcrypt.test

Here we have 2 theoretical recipients: A@flowcrypt.test, B@flowcrypt.test. Should I add 2 entries to the local database

1| FINGERPRINT| A@flowcrypt.test | KEY
2| FINGERPRINT| B@flowcrypt.test | KEY

Originally posted by @DenBond7 in #1188 (comment)

[tomholub]

here: #1542

[DenBond7]

I've updated the subject. It will relate to the compose screen.

[DenBond7]

@tomholub by the way, is there a situation when we can receive a response from API that contains a few keys(attester)?

[tomholub]

Not yet, but may be in the future. I will warn you ahead of time if that was the case, but I recommend that internally the method starts returning an array of public keys (that for now contain zero or one element), even if from the API it received a single key.

[tomholub]

Btw on compose screen it's somewhat different than manual import.

Because on compose screen, you always know which exact recipient email you're looking up.

So if I look up joe@flowcrypt.test - because it's one of the recipients, then I'm saving the received keys for joe@flowcrypt.test. In that situation, it doesn't matter what pgp user ids the receivd public key have. I'm saving them for the email I was looking up.

Manual import at #1542 is different because there I don't know who I'm looking up. I just have a list of public keys to import for many people. There, we will be looing at primary uid to decide who to import for. But not on compose screen.

[DenBond7]

For case "recipient without pub keys in the local database" we have the following

1. Fetch recipient pub keys from a server(attester/wkd)
2. Parse the received result as a list of pub keys(zero or one for now as you said. What to do if there will be more than one? save all?)
3. Save parsed pub keys in the local database where recipient == email

@tomholub Am I right?

[tomholub]

You should fetch the recipient's public keys in compose regardless if we already have them in database. If a recipient was added, their public keys will be updated every time.

Fetch recipient pub keys from a server(attester/wkd)

Yes, using pubLookup to respect the settings

Parse the received result as a list of pub keys(zero or one for now as you said. What to do if there will be more than one? save all?)

While attester may only have zero or one, WKD may already have zero to many. Basically there is almost no place in the app left where we only deal with one pubkey, it's always potentially many. Almost always arrays.

Here: #1396 (comment)

The array you get from pubLookup gets saved into local storage one by one. It no longer matters whether it's zero, one or more than one: it's an array and it gets iterated over. For each key, see by fingerprint if we already have it for that recipient we were originally looking up.

If we already have that key for that recipient by fingerprint, we compare which one is newer (by date last modified / last signature) and if the remote key is newer than local key, we replace the key (for that recipient). If we didn't have that key for that recipient, then we save it.

We save keys regardless if they are usable, expired or revoked - save them all. Only don't save if they are completely unusuable eg cannot be parsed.

Save parsed pub keys in the local database where recipient == email

yes, the recipient we were trying to originally look up, is used for storing into database.

[tomholub]

Btw if we already have valid public keys in local storage for a recipient, and a call to pubLookup fails for that recipient, we can ignore the failure that time. And use the keys we already have.

But if we don't have any public keys for a person or the ones we have are not usable (expired, revoked) then a failing request to pubLookup should be surfaced to user to retry.

[DenBond7]

@tomholub one more question. For now, we have the following logic

1. If a recipient doesn't have any pub keys we make an API call by email
2. if a recipient has a key(one key, because we don't have multiple keys logic yet) we make an API call by fingerprint.

But it seems we can't use this logic from now. Because there can be a situation when we can miss new keys for some recipient. Should I always make an API call by email?

[tomholub]

But it seems we can't use this logic from now. Because there can be a situation when we can miss new keys for some recipient. Should I always make an API call by email?

That's exactly right 👍