This bug has several parts.

(a) We need raw storage of public keys. Ideally, the OpenPGP library we use should offer that. The file should be located in the TB profile folder.

(b) we need a way to view the set of public keys (of correspondents) that we have already obtained and which are stored locally on the user's system. For that, we should reuse the Enigmail key management UI.

(c) we need the ability to manage the verification status, or trust status, of the available public keys.

(d) ownertrust / web of trust

For (c), I suggest that we distinguish the following states:
(i) keys that are new, regardless of the way they have been obtained
(ii) keys that have been used at least once, because the user has opted in to use it
(iii) keys that have been verified by the user, e.g. by comparing the fingerprint

Alice attempts to send an encrypted email to Bob. But there's no key available that Alice has used before.
(Alice might have never sent encrypted email to Bob. Or, the keys that Alice used in the past have all either expired or revoked.)

In this scenario, if TB has found keys of level (i), TB can offer Alice to use that key (or present a list of potential keys having Bob's user ID). At this time, TB would also remind Alice to verify that the key indeed belongs to Bob, but Alice is allowed to ignore that. Once Alice allows the use, the key moves to level (ii).

We could import level (ii) keys into the public key storage offered by the OpenPGP engine.

For level (iii), I suggest that we use "key certification" (key signing) to record the fact that the user has fully verified the ownership of a correspondent's key.

Keys of level (i) could be kept in a more temporary storage location, which TB manages itself, which might be limited by size or age.

We're currently exploring the use of the RNP library, which supports saving and loading lists of keys from disk. If we stay with RNP, regarding (a) I'd like to use that for convenience.

Regarding (b), bug 1598478 landed a port of the enigmail key manager, which was changed to display keys loaded from RNP. Viewing the list is possible, also deleting. But most other operations aren't adjusted yet.

Initially, we probably won't support (d).

I'll file a separate, dependent bug with more thoughts for initial work on (c).