Thunderbird and OpenPGP - Smartcard support
kaie at kuix.de
Tue Dec 3 21:14:39 UTC 2019
We initially said smartcard support isn't a priority and we might not
support it initially.
However, based on the feedback we've received after the blog post, this
is an important functionality for advanced users. Although it seems
realistic to assume that a majority of users will not use a smartcard
device, it would be good to support smartcards, too.
When not using GnuPG software, it seems difficult to support OpenPGP
smartcards in Thunderbird.
This statement might surprise those of you, who know what Thunderbird
already supports using smartcards with S/MIME and SSL/TLS client
However, that smartcard support is provided by the NSS software library
, which doesn't offer OpenPGP support.
We'll need to bring in an additional software library for OpenPGP
messaging. I'm not aware of any OpenPGP software that uses the NSS
library for cryptographic operations. (Because NSS never was developed
with the intention to support OpenPGP, NSS might even lack some of the
cryptographic primitives that are necessary to support OpenPGP.)
Currently, a potential candidate for adding OpenPGP support to
Thunderbird is the RNP library . (We're still exploring if it will be
sufficient for our needs, but we're making progress.)
RNP is a software library that provides OpenPGP data and key processing,
but it doesn't provide the lowlevel cryptographic operations. It has a
dependency on the Botan library .
(RNP cannot use the NSS library. Given the limited amount of time we
have available to produce the Thunderbird 78 implementation, and given
the amount of engineering resources available to the Thunderbird
project, it seems unrealistic to port the RNP library to use NSS, which
would potentially require to add more primitives to NSS.)
Although the Botan library supports the use of some smartcards, the RNP
library doesn't. We haven't yet researched if the Botan library already
offers all the functionality required for OpenPGP smartcards. Even if it
supported all we need, we'd still have to extend the RNP library to
offer that, too.
During a meeting in Berlin, Andre Heinecke and Kristian Fiskerstrand
suggested to use IPC to communicate with the scdaemon software. IIUC,
scdaemon is installed on systems that use an OpenPGP smartcard with
GnuPG. That's an interesting idea. If Botan doesn't yet support the
lowlevel functionality to talk to OpenPGP smartcards directly, a
volunteer who's willing to add such support could potentially use that
Once we're certain which library we'll use with Thunderbird, maybe some
smartcard vendors will volunteer to add that support to the Botan/RNP
stack? Even if someone steps up, it's difficult for me to guess how
quickly this could potentially happen, and whether it might reach
production quality in time for the summer 2020 release of Thunderbird.
However, we've been brainstorming, and here's an alternative idea, that
might be more practical to get implemented quickly.
For those users who wish to use a smartcard, it seems acceptable to
require them to setup and configure the GnuPG software accordingly
(without any integrated assistance from Thunderbird), and to use
external tools (separate from Thunderbird) to ensure the key material on
the smartcard has been prepared as necessary.
Thunderbird could offer an advanced configuration, to define that
external GnuPG will be used by Thunderbird for secret key operations of
an email account (also specifying the desired key ID). Thunderbird could
reuse Enigmail's existing code to implement that.
Whenever there's a need to decrypt, Thunderbird could call "gpg
--unwrap" to access the inner data of combined signed/encrypted
messages. If there's a signature inside, the verification would still be
done using Thunderbird's internal implementation for public key and
Likewise, if we produce a message that needs to be digitally signed,
we'd call gnupg to create the signature. If the result needs to be
encrypted, we'd use the code based on RNP and Thunderbird's public key
trust configuration to identify the keys used for encryption, and use
RNP to encrypt.
We're interested to hear your feedback on these thoughts.
We'll explore if the "use gnupg for smartcard private key operations,
only" approach is feasible. Limiting the use of GnuPG to the secret key
operations seems useful, to avoid having two different implementations
for public key and trust handling.
More information about the tb-planning