hey folks-- [ This message won't make sense unless the reader distinguishes clearly between OpenPGP the protocol and GnuPG the implementation! As a community we have a history of fuzzily conflating the two terms, which is one of the reasons that we're in this mess today. Please read explicitly. ]
[ Background: for those who don't know, i've been a maintainer in debian of GnuPG and other OpenPGP-related tooling for several years, and i'm also the co-chair of the IETF's OpenPGP working group; i participated in many of the discussions that led to the current sorry situation, and it is happening despite my best efforts to avoid this problem. I'm probably as responsible for this situation as anyone in Debian is. My apologies. ] The best outcome, in my opinion, would be for GnuPG to go ahead and implement the pending updated OpenPGP specification (the so-called "crypto-refresh"). I say this despite personally preferring some of the concrete ways that i think the GnuPG project would have preferred to (as indicated by the latest "LibrePGP" Internet-Draft, at least) diverge from the OpenPGP specification. There are enough other advantages to the OpenPGP crypto-refresh that it doesn't make sense for GnuPG to deliberately avoid implementing the community consensus. The GnuPG project clearly has all the underlying cryptographic and engineering capability to do this, if it wants to, and the OpenPGP crypto-refresh process took deliberate measures to avoid collisions with any prematurely deployed code that implements a draft that hadn't managed to reach a rough consensus. Can debian make GnuPG interoperate with the rest of the OpenPGP ecosystem? Probably not without GnuPG's cooperation: it would be a substantial patchset to carry in Debian, and even trickier to do if GnuPG upstream sees such a patchset as hostile. Read on below if you want to consider some other options. Stephan Verbücheln wrote: > As you probably know, Debian relies heavily on GnuPG for various > purposes, including: > - developer communication > - signing of tarballs and patches > - automated processes such as update validation by APT Debian by policy and by mechanism relies heavily on the OpenPGP protocol for these things. And i'd also add certificate verification, aka "web of trust" for Debian developer identities to the list as well. In particular, we use OpenPGP for cryptographic signing of software source, packaging information, archive control, and distribution mechanisms; for developer identities; and for cryptographic verification of all of these things. As a project, we don't make much use of the encryption/decryption parts of OpenPGP, since we develop mainly in the open. But not everyone uses GnuPG for these purposes. There are multiple interoperable OpenPGP implementations in Debian beyond the GnuPG family (C), including RNP (C/C++), pgpainless (java), pgpy (Python), GOpenPGP (Go), hOpenPGP (haskell), and Sequoia (Rust). But it is also true that the GnuPG implementation specifically is baked into some of our infrastructure. I'll get into why that is below (see "Why is GnuPG on Debian's Critical Path?"). > How can Debian deal with this? Should Debian intervene to prevent the > worst? I don't think Debian can make a specific intervention that will avoid the global problem, but i think there are things we can consider going forward. One possible approach is to drop the use of OpenPGP (or "LibrePGP") entirely, and instead base our internal cryptographic dependencies on bespoke cryptographic implementations. I think that would be a mistake. I do not want Debian's long-term health to depend on any particular implementation. If the implementation fails then we would have to (as a project) decide on our own upgrade path. For a failure due to cryptanalytic advances, that can be particularly harrowing: I don't think we as a project have the necessary expertise to do that well. For failures due to buggy implementations, we can always patch, but i wonder about the amount of cryptanalytic review a bespoke implementation will have as opposed to publicly audited generic tooling. If we have to decide as a project on LibrePGP vs. OpenPGP, i'd prefer the wider community project with a stable reference, functioning (albeit sometimes rough) consensus, a range of diverse implementations, and substantial public interoperability testing. That means OpenPGP. To be clear, the IETF OpenPGP working group actively solicited input from the GnuPG team, and tried to work with the project as one significant implementation among many. But ultimately, the GnuPG project decided to break away from the community process, and created this "LibrePGP" split, which threatens interoperability for the *PGP ecosystem as a whole. Maybe the end result of this will be to put a nail in *PGP's coffin, and we'll all just go back to bespoke cryptographic implementations that have no stable reference other than the source code, and little interoperability or reusability across contexts. Or maybe we should switch to X.509 for certificates and CMS as the cryptographic object model (though that ecosystem is even more of a fragmented disaster than OpenPGP, from what i've seen). I'd be sad about any of these outcomes though. Using minimally patched, highly visible, publicly vetted tooling with simple and straightforward semantics, where there are multiple available, active implementations seems like the safest approach. The OpenPGP protocol, as designed, is intended to offer a smooth upgrade path to new cryptographic algorithms and features, while keeping a reasonably stable, minimal set of semantics as the underlying cryptographic algorithms improve. In the past, that hasn't worked out as well as i would have liked for us, largely because of our dependence on GnuPG as an overwhelmingly dominant implementation, which didn't test the upgrade path as well as it should have. For example, the transition from RSA to Ed25519 was a rough one, since older versions of GnuPG choked on certificates that contained unknown algorithms rather than ignoring them gracefully. OpenPGP implementations have generally learned from those failures, and many of them are now much more resilient and can support the kinds of upgrade path that we need to consider. For most of our signing/verifying-focused work, that means: - verifying tools should ignore signatures and certificates that they don't understand, while still validating signatures from certificates that they do understand - signing tools can make pairs of signatures, one "compatibility" signature and one "modern" signature This means that for a debian signing/verification context, like package distribution, which has a global workflow, starting from an existing OpenPGP implementation, signing key and corresponding verification certificate, it looks like: 0) upgrade the signing tool, and start upgrading some of the verification tooling. 1) create a new signing certificate with the new version, algorithm, or feature. 2) distribute the old+new certificates for the verifiers. 3) make signatures with old+new in parallel 4) complete upgrade of all verification tooling 5) stop making signatures with old signing certificates These steps map reasonably well into the Debian release cycle. Any part of the debian ecosystem that requires these sorts of semantics should be able to just adopt a generic OpenPGP implementation and make this work. In practice, i think it makes the most sense to engage with well-documented, community-reviewed, interoperably-tested standards, and the implementations that try to follow them. From my vantage point, that looks like the OpenPGP projects that have continued to actively engage in the IETF process, and have put in work to improve their interoperability on the most sophisticated suite of OpenPGP tests that we have (https://tests.sequoia-pgp.org/, maintained by the Sequoia project for the community's benefit). Projects that work in that way are also likely to benefit from smoother upgrades to upcoming work in the IETF like post-quantum cryptographic schemes: https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/ Is GnuPG (or "LibrePGP") a good choice for this kind of long-term ecosystem health? I want it to be, but I worry that it currently is not. In particular, "LibrePGP" doesn't appear to have a stable reference, or even multiple implementations that agree on the semantics of all the major parts of it. And GnuPG might be too complex or too fragile to rely on in the long term, particularly if it doesn't intend to support interoperation with other OpenPGP implementations, which i understand to be the currently stated intent of the project. I've written to the pkg-gnupg-maint mailing list about my concerns about the long-term health of the GnuPG project, and why i've found it difficult going as a downstream maintainer in the last several years: https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2023-August/008968.html We've had to carry lots of patches in debian (e.g. cryptographic default updates, performance or hardening patches), and not had a lot of support from upstream for healthy integration in common debian or Internet infrastructure (e.g. systemd support for the increasingly daemonized family of tools, or certificate cryptographic updates or revocations that ship without user IDs). There are also significant performance problems when the tool tries to scale up (e.g. large numbers of concurrent secret key operations, many successive signature verifications/decryptions, or large keyrings). These might not affect everyone directly (indeed, GnuPG upstream has in the past discouraged users from trying to scale up, saying that the tool is designed for selective and deliberate use), but if your tooling depends on GnuPG then you're asking those few users who do try to scale up to switch toolchains entirely. That's a shame, and likely a source of bugs or even cryptographic errors. I've been trying to encourage core pieces of infrastructure to adopt "OpenPGP" as a technology, rather than requiring "GnuPG" as an implementation, even if the underlying tooling remains GnuPG. This is mostly other people's work, but i'm very pleased to see, for example, that dpkg now has a more flexible "openpgp backend" mechanism. # Why is GnuPG on Debian's Critical Path? GnuPG has been a longstanding, stalwart presence in the F/LOSS community. It provided cryptographic integrity checks for our ecosystem for ages, long before many proprietary systems even considered defending against some of the attacks that OpenPGP can defend against. That said, the GnuPG codebase is difficult to maintain, the semantics its interfaces offer are ill-understood, some bugs can be difficult to get fixed, and system integration is tricky. In 2023, I believe GnuPG is baked into our infrastructure largely due to that project's idiosyncratic interface. It is challenging even for a sophisticated engineer to figure out how to get GnuPG to (probably, hopefully!) fulfill a cryptographic task in their project. Once that is done, it's especially painful to consider moving to a different OpenPGP implementation, because the interface to another implementation rarely lines up cleanly with GnuPG's interface. This is not unlike the situation we've had in the past with the TLS protocol (Transport Layer Security), where one widely-used implementation (OpenSSL) has such a historically peculiar interface that it was a real challenge to port a dependent project from that implementation to another implementation and still remain functional, even when the desired cryptographic goals of the dependent project are relatively straightforward, as they usually are (for an implementation that wants to act as a TLS client, the desired semantics are typically: "instead of a cleartext bidirectional stream to foo.example, i want an encrypted, authenticated, integrity-checked bidirectional stream to foo.example"). Arguably, we're still beholden to OpenSSL in many ways, despite better TLS implementations being available in many contexts. # What Can Debian Do About This? I've attempted to chart one possible path out of part of this situation by proposing a minimized, simplified interface to some common baseline OpenPGP semantics -- in particular, the "Stateless OpenPGP" interface, or "sop", as documented here: https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ We have a few implementations of this interface in debian already: pgpainless-cli, sqop, and gosop, plus a partial implementation in haskell (/usr/bin/hop, from hopenpgp-tools). sop is a command-line interface, but there has been some (still immature) discussion about a C-based library interface as well. I would absolutely love to see the GnuPG project produce a native sop implementation, but the only one i've seen is built by an outsider around the GpgME library (itself a delicate interface), and hasn't been formally released. If your part of Debian's infrastructure depends on GnuPG, consider making it depend on a sop implementation instead, so we don't end up stuck on a single OpenPGP implementation in the future. If the sop semantics are insufficient for your purposes, please report your needs at https://gitlab.com/dkg/openpgp-stateless-cli ! If you are implementing or maintaining an OpenPGP implementation in debian, please consider encouraging upsteam to add a sop frontend, and get it tested in the interop test suite! # The Bottom Line Interoperability and engagement with the broader ecosystem matters, especially in a store-and-forward ecosystem like OpenPGP. I'd love to see a historically important implementation like GnuPG collaborate with the wider ecosystem. I don't know how to convince them to do that. I think it would be irresponsible of debian to endorse (by adoption) a cryptographic project that has chosen to opt out of public participation and consensus building for this critical bit of infrastructure, even if the public consensus isn't exactly what they wanted. Hopefully --dkg PS For standards nerds who are interested in yet another TLS analogy: it would be a mistake for Debian to adopt [ETS] for its infrastructure instead of [TLS 1.3]: [ETS] https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf#page=8 [TLS 1.3] https://datatracker.ietf.org/doc/html/rfc8446 For the avoidance of doubt, i see LibrePGP as the ETS analogue, and the pending OpenPGP crypto-refresh as the TLS 1.3 analogue here. This situation isn't quite as bad as that one: i don't believe the "LibrePGP" schism is directly trying to sabotage a community security goal, the way that ETS is trying to sabotage TLS 1.3's forward secrecy. But in some ways it's worse: ETS is at least a stable standard that multiple implementers can interop against, whereas LibrePGP appears to be shifting based on one implementor's unvetted decisions (i've seen very little discussion of LibrePGP from the RNP folks, who are the other claimed participant in LibrePGP). The reason that we have community consensus and review of standards is specifically to ensure interoperability and avoid cryptographic failures.
signature.asc
Description: PGP signature