LibrePGP in Thunderbird, maybe treat it as optional

[Kai Engert]

As I understand it, LibrePGP wants to be treated completely separately 
from the upcoming OpenPGP/IETF (crypto-refresh) specification.

I haven't seen initiative from the LibrePGP side to respond to my past 
requests for reaching compromises.

Werner's recent email about "PQC public key format specification" (on 
this list) also suggests that LibrePGP will treat PQC using v5 keys 
differently, with even a clash in namespaces of identifiers as a 
potential consequence.

In my opinion it will be too complicated to handle both specifications 
in parallel in Thunderbird with a unified user experience.

I think it will become necessary that email applications, which want to 
support both specifications, will be required to clearly distinguish 
between the OpenPGP and LibrePGP technologies.

While I don't plan to rush, this very unfortunate topic keeps my mind 
busy. I'm continously brainstorming how this could be handled in a 
reasonable way.

I'd like to present you a potential approach that Thunderbird (TB) could 
use in the future.

As you may know, as of today (e.g. as implemented in TB version 115.x), 
TB uses integrated key management, and internal trust management for all 
public keys. It offers a fallback to optionally use the GnuPG software, 
but only for secret keys, and the fallback only works if the user 
configured extra pfererences, and has GnuPG and the GPGME library installed.

TB could potentially handle LibrePGP by treating it as a completely 
optional technology and message format, only available for users who 
install GnuPG and GPGME and use special settings in TB.

The idea is that TB could introduce a LibrePGP mode of operation. For 
each email account, TB could offer the user to set a preference whether 
the email account (or identity) will be used with LibrePGP or with 
OpenPGP/IETF.

As part of this model, TB would stop offering any integrated support for 
key or trust management for LibrePGP public keys. Users would be 
required to use an external application (either gpg or a related UI tool).

When using only the TB application, without having GnuPG/GPGME installed 
or configured, TB would offer integrated support OpenPGP (v6) support, only.

If RNP implements full support for OpenPGP v6 keys and messages, then TB 
could eventually enable support for it. TB would be careful to disable 
any LibrePGP related v5 keys or features when using the integrated mode.

Let me write that idea as a bullet list to make it easier to understand:

TB by default:
- only OpenPGP v4 + v6 support
- integrated key and trust management of v4 + v6 keys, only
- user can configure (in account settings) which key to use
   (same as today)
- when reading an email, TB would look at the configured account,
   and if it is configured as OpenPGP, would route the message through
   the v4+v6 processing code. If the message is actually in the LibrePGP
   format, processing will fail with an error.
- when composing an email, TB would only consider the list of
   public keys from TB's internal keyring, same as today.
- when composing, the UI technology choice would offer OpenPGP and
   S/MIME only.

All users of TB would have the above available.

Only users who manually install and configure GnuPG/GPGME may optionally 
use the following:

TB with GnuPG/GPGME:
- If a user wishes to make use of GnuPG, they will have to
   say so in the settings for a TB account/identity.
- the user will have to specify which external GnuPG secret key
   should be used with this account/identity (same as today)
- when reading an email, the message would be routed through
   external gnupg, only.
   (And processing will fail with an error if it's a v6 message,
   or if the required secret key is not available in the LibrePGP
   keyring.)
- when viewing the status of an email, TB might offer
   reduced information. For example, it might report the signature
   status based on feedback from GnuPG, and report the fingerprint
   of the signer key. But maybe it will not report anything else.
   Because TB would not offer key management for LibrePGP keys,
   there might be no viewer for those keys inside of TB.
- when composing an email, TB might try to query GPGME for the
   availability of keys, and maybe it could show in advance whether
   an email can be encrypted or not.
   However, TB wouldn't offer any assistance for resolving issues
   with missing keys. The user would be required to manually resolve
   such trouble with their external tool for LibrePGP key management.
   GnuPG's trust settings for public keys would be used.
- when composing, the technology offered in the menus would be
   limited to LibrePGP/GnuPGP and S/MIME
   (based on the configuration of the from/sender identity for the
   current email).

General:
- the internal key and trust management of TB would make it clear
   in the UI that it's limited to OpenPGP keys, and exclude
   GnuPG/LibrePGP keys

Summary:
- using OpenPGP/IETF would work in TB in the same way as today
- LibrePGP would be available in TB only after manual efforts
   to configure it, and its usability would be very limited
   and probably inconvenient.

This isn't yet a plan, but just a potential way to handle the separate 
specifications in TB, and still give a users a minimal workaround to use 
LibrePGP, if they have to.

I assume that in the upcoming TB release in 2024, TB will limits its 
*PGP support to RFC 4880, and not yet attempt to support any 
enhancements from the LibrePGP or OpenPGP/crypto-refresh specifications.

Regards
Kai