ability to store more than one public key per recipient

[tomholub]

Right now the extension will store only one public key per recipient email address.

For a smooth user experience with key rotations we need to add the ability to store more than one public key per recipient in the extension. That, combined with the WKD improvements in #3017 and #3018 will allow for a smooth experience during key rotation.

I haven't investigated exactly how the email-to-pubkey relationship is handled on the storage level, it could be a unique index on IDBDatabase. Maybe the index could be simiply dropped without migration. And then the following will need to be updated:

• Store method used to retrieve one public key for one recipient should start to return an array of public keys
• all code that uses that method downstream should start expecting that too
• when the called from compose window, additional code needs to be added to decide which of the retrieved keys to use (some may be expired, some may be revoked - I'd recommend to use whichever valid key that has the most recent signature on it)
• when called from pgp decrypt window to verify a signed message, key should be chosen by key id (therefore presumably no change there)

[tomholub]

@rrrooommmaaa please have a look to see how involved this change may be - particularly the database / unique index part.

[rrrooommmaaa]

@tomholub First refactoring thought:
In Contact structure we have fields longid and longids and corresponding indexes: index_longid and index_longids.
longid is used to search for primary key and longids is used to search among primary and subkeys.
As we're going to have multiple pubkeys in contact, I suggest to drop longid field and index_longid index and use longids field to search.

[tomholub]

Instead of having multiple public keys in one contact, can we have one contact per public key?

…

On Thu, 11 Feb 2021, 12:59 Roman, ***@***.***> wrote: @tomholub <https://github.com/tomholub> First refactoring thought: In Contact structure we have fields longid and longids and corresponding indexes: index_longid and index_longids. longid is used to search for primary key and longids is used to search among primary and subkeys. As we're going to have multiple pubkeys in contact, I suggest to drop longid field and index_longid index and use longids field to search. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQDZEJDFDHTWPKG6QCZKF3S6PBCVANCNFSM4WJA72DQ> .

[rrrooommmaaa]

Currently, email is the key field for the Contact's object store. So we'll need to refactor this store to have a different key. I'm not an expert, but it may slow down the search by e-mail. The positive effect would be that there will be less refactoring in other portions of code.