Ideally, the OpenPGP engine we use should offer management of private keys on disk, using the library's own file format. This could avoid that we have to spend lots of engineering time on this detail.

The storage of private key material should be consistent with other parts of the Thunderbird application. Its current model is that such keys are located in the Thunderbird profile folder, and can be protected using the TB master password.

When using TB with OpenPGP for the first time, the user might already own one or more private keys, for example imported from external GnuPG, based on an existing Enigmail configuration (see also bug 1595228).

If we use our own integrated storage (managed by an integrated OpenPGP engine), then the user won't have any other way to view the keys that are available. Therefor it's important that TB allows the user to discover which keys are available.

I suggest that we reuse the existing key management user interface implemented in Enigmail, for listing keys, deleting keys, viewing the properties of keys.

We'll also require a way to generate new private keys. I think we should implement a new key generation wizard, which is easier to understand than Enigmail's current key generation dialog. I'll file a separate bug to track that.

Storage of private keys works with the RNP library. Stored in the profile directory. Key is secured with the master password (indirectly).

I'm sorry to be posting this here, but I'm not sure where else to post this. I just read about the intent to have TB 78 handle PGP encryption natively. I think that's a great thing, and as a long time user of Enigmail, I'm happy to hear of its author being onboard.

HOWEVER, I also read in https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#Key_storage this:

To process OpenPGP messages, GnuPG stores secret keys, public keys of correspondents, and trust information for public keys in its own file format. Thunderbird 78 will not reuse the GnuPG file format, but will rather implement its own storage for keys and trust.

That is potentially a TERRIBLE idea. What if I use my GPG key for more than encrypting email, say, for signing code commits or signing packages or distributions of software? Do I really have to manage my keys in two separate places?

Please tell me I've read that wrong and I'll still be able to use a single keyring by some magic means so I don't have to duplicate effort.

(In reply to eric.engstrom from comment #3)

I'm sorry to be posting this here, but I'm not sure where else to post this.

A good place for general discussion is:
https://thunderbird.topicbox.com/groups/e2ee

Please tell me I've read that wrong

No, you have read correctly.
The GnuPG storage is defined by the GnuPG software, and the on disk file format was changed multiple times.
Because we cannot use GnuPG software for all users, we cannot use it to read and write from that key storage.
Because of the risk of file formats changing, it's seems unwise to try to attempt to implement separate software for accessing GnuPG's files, and we risk having to catch up and running into incompatibilities.
It's less risk to use our own storage.

My understanding was, per bug 1627911 private keys will be directly usable by calling the user's preexisting GnuPG installation. Only public keys will be forced to reside within Thunderbird's private keystore implementation.

I'm somewhat conflicted about the whole "don't use my actively managed external GnuPG trust store" thing. It really seems like the wrong approach for Linux users. But if I have to store my private key inside Thunderbird there isn't even a question in my mind: my Thunderbird days will have come to an end and I need to find a new email client which I find pleasant to use but also offers GnuPG integration.

Is bug 1627911 suitable to let me keep my private key inside GnuPG? Is it going to be arbitrarily limited to smartcards?

(In reply to Eschwartz from comment #5)

I'm somewhat conflicted about the whole "don't use my actively managed external GnuPG trust store" thing. It really seems like the wrong approach for Linux users.

I am long Linux user. I used OpenPGP ever only for email (one exception when checking the signature of the hash a software package in a script, which I do with gpg). And therefore I am OK with key-management all within TB. I am happy if it is just easy to use for a broad band of people.

But if I have to store my private key inside Thunderbird there isn't even a question in my mind: my Thunderbird days will have come to an

Could You explain why?

(In reply to Eschwartz from comment #5)

My understanding was, per bug 1627911 private keys will be directly usable by calling the user's preexisting GnuPG installation. Only public keys will be forced to reside within Thunderbird's private keystore implementation.

Only for advanced users. Only for those who go the extra mile to have GnuPG and GPGME installed on their system. Only for those who understand the difference between TB internal storage and separate GnuPG storage. Only for those who know all that, have done all that, and opt in by setting a pref.

I'm somewhat conflicted about the whole "don't use my actively managed external GnuPG trust store" thing. It really seems like the wrong approach for Linux users.

Thunderbird is cross platform. The default solution should behave the same on all platforms. We had to the pick the approach that's possible, doesn't mean extra complexity, and is allowed (licenses).

Is bug 1627911 suitable to let me keep my private key inside GnuPG? Is it going to be arbitrarily limited to smartcards?

Currently I don't see a need to limit it to physical smartcards.

(In reply to bugzilla0248 from comment #6)

But if I have to store my private key inside Thunderbird there isn't even a question in my mind: my Thunderbird days will have come to an
Could You explain why?

Please limit bugzilla discussions to the technical aspects.

(In reply to Kai Engert (:KaiE:) from comment #7)

Only for advanced users. Only for those who go the extra mile to have GnuPG and GPGME installed on their system. Only for those who understand the difference between TB internal storage and separate GnuPG storage. Only for those who know all that, have done all that, and opt in by setting a pref.

Thank you for clarifying. So the answer to eric.engstrom's question is:

Please tell me I've read that wrong and I'll still be able to use a single keyring by some magic means so I don't have to duplicate effort.

"You read that right, but this is describing the default experience. There will be an advanced option to do what you want, at a minimum for private keys."

Is bug 1627911 suitable to let me keep my private key inside GnuPG? Is it going to be arbitrarily limited to smartcards?

Currently I don't see a need to limit it to physical smartcards.

Thank you.

(In reply to bugzilla0248 from comment #6)

(In reply to Eschwartz from comment #5)

I'm somewhat conflicted about the whole "don't use my actively managed external GnuPG trust store" thing. It really seems like the wrong approach for Linux users.

I am long Linux user. I used OpenPGP ever only for email (one exception when checking the signature of the hash a software package in a script, which I do with gpg). And therefore I am OK with key-management all within TB. I am happy if it is just easy to use for a broad band of people.

I'm not a broad band of people, I use my key for many things including signing and publishing software. I have baseline requirements external to Thunderbird, which you don't have. Your use case doesn't care where or how it is stored, as long as Thunderbird works, so either approach would satisfy you.

As a result, my opinions about the technical correctness of one over the other don't really change how you do things.

But if I have to store my private key inside Thunderbird there isn't even a question in my mind: my Thunderbird days will have come to an

Could You explain why?

Due to technical and security considerations unrelated to Thunderbird. The people who this applies to already know who they are, and don't need explaining to understand why they want to do key management, but most importantly private key management, outside of Thunderbird.

At that point, it's simply a matter of using software which integrates with requirements.

This META bug should also depend on bug 1657901. I don't think I have the perms to do this yet.