Reaction to potential PGP schism

[Stephan Verbücheln]

Hello everyone

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

The OpenPGP Working Group at IETF is currently working on a new
standard.

https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

Due to different opinions, some people (including notably the GnuPG
team) have quit the IETF Working Group and proposed their own LibrePGP
standard.

https://librepgp.org/

Notably remaining in the IETF Working Group are people from Proton Mail
(maintaining OpenPGP.JS) and Sequoia PGP (free implementation in Rust).

The disagreements are about details such as algorithms and file formats
which make both standards incompatible.

How can Debian deal with this? Should Debian intervene to prevent the
worst?

Regards
Stephan

[Pierre-Elliott Bécue]

Hi,

Personal view here.

Stephan Verbücheln <verbu...@posteo.de> wrote on 14/12/2023 at 11:29:17+0100:

> [[PGP Signed Part:No public key for 603542590A3C7C62 created at 2023-12-14T11:29:17+0100 using EDDSA]]

By doing nothing.

> Should Debian intervene to prevent the worst?

No.

--
PEB

[Joerg Jaspert]

On 17077 March 1977, Stephan Verbücheln wrote:

> How can Debian deal with this? Should Debian intervene to prevent the
> worst?

We, as Debian, look and wait what comes out. And then *MAY* at some
point decide to add (or switch to) a new thing, if that appears better.
Also, it will be a high bar for that.[1]

Individuals, including Debian developers, are - of course - free to jump
in and take part in this.

[1] not counting the usage/scriptability of gnupg, that bar is somewhere
down DEEEP in the earth, its so horrible.

--
bye, Joerg

[Daniel Kahn Gillmor]

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.

[Christoph Biedl]

Daniel Kahn Gillmor wrote...

(...)

Thanks for your exhaustive description. I'd just like to point out one
point:

> 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/

There was a presentation at the recent MiniDebconf in Cambridge about
post-quantum cryptography, including the consequences for Debian (that
was by Andy Simpkins):

https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Simpkins

The key point AIUI is Debian must take precautions *very* *soon* as
there's a realistic chance QC will - within the lifetime of trixie -
evolve to a point where it seriously weakens the cryptographic security
as we know it. In other words, Debian must prepare for PQC within the
trixie development cycle, so within 2024.

Therefore, my answer to "How can Debian deal with this [schism]?" is
basically: Debian needs to change things in that area anyway, let's
first find an implementation that provides what we need and has a sane
implementation. If that means turning away from GnuPG, so be it. The
transition will be painful anyway.

Christoph

[Gioele Barabucci]

On 21/12/23 04:16, Daniel Kahn Gillmor wrote:
> # 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/

Hi, thanks for the detailed overview.

As the Uploader of rust-sequoia-openpgp, what do you think of the
related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg
that uses sequoia internally)?

Would it work as a stop-gap measure while the Debian infrastructure
moves from GnuPG to something else (to `sop`, for instance)?

Regards,

[1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in
Debian AFAIK

--
Gioele Barabucci

[Enrico Zini]

On Wed, Dec 20, 2023 at 10:16:28PM -0500, Daniel Kahn Gillmor wrote:

> # Why is GnuPG on Debian's Critical Path?
>

> 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.

I maintain critical code that calls out to gnupg, in part because at the
time I wrote it that was the only thing available, and in part because
I'm supposed to offer the broadest possible compatibility with what
other people in Debian are using, so if everyone else seems to use
gnupg, gnupg is the first thing I would consider.

I hated and still hate every single moment I spent having to interface
with gnupg. The protocol to interact with it is custom, hydiosincratic,
poorly documented, and very hard to speak correctly. When in the end I
managed to make things work, I was always left with the feeling that
there would still be a corner case that I missed, or that will be
introduced in a future gnupg release, waiting to become a security issue
in our infrastructure, despite having asked for peer review from
appropriate people in Debian.

New releases make things harder rather than easier. Now gnupg is a
mini-ecosystem of security-critical daemons that need to be brought up
and killed, that may time out or run partly off sync with configuration,
which adds even more know-how to the amount require to survive as
downstream consumer of that one single "API".

I've been wanting for literally decades something with language
bindings, or with a protocol that is built on existing well-known
standards, outputting data that I can parse with an existing and tested
parser library, using I/O channels that I can manage using an existing
and tested communication library.

I hate it every single time I need to use gnupg, but still I use it
because I understand it's what Debian has been expecting me to use, so I
add that requirement to the pile of historical quirks that geologically
accrete in our community, which make our barrier of entry so stylishly
high, and make us appear oh so fearfully smart.

> # What Can Debian Do About This?
>

> 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!

This.

I don't know if it should be sop or a protocol or a standard, but I'd
like to see Debian clearly document its expectations on its crypto
requirements, and stand behind it.

I personally believe that we should depend, for our core security, on an
interoperable standard with multiple implementations rather than a
project that follows the hydiosincracies of a single isolated upstream.

Whatever we do, though, I want that to be official. As things stand I'll
keep suffering with gnupg until at a DebConf I'll have at least 5 people
look at me wide-eyed and say "are you still using THAT? Everyone moved
to THIS instead!"

I'd like to ask for what mature OpenPGP implementations exist today,
pick one I feel I can confidently control, and then when somebody comes
and says "my gpg/$TOOL segfaults on your input", I want to be able to
point them at a documented decision and say "please report a bug to
$TOOL" instead of taking a week off to port everything again to gpg.

Thank you for all the work you've done on this over the years! I've
appreciated it with great gratitude and a big hope that some day, thanks
to you and others like you, those >=5 people at a DebConf will really
look at me wide-eyed and show me a way out of the pit.


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>

[Stephan Verbücheln]

Interesting point in this talk: The APT team is already working on non-
PGP signatures.

https://wiki.debian.org/Teams/Apt/Spec/AptSign

I can see the advantages of that for release signatures which use a
rarely changing set of keys.
However, I do not see any good alternative for PGP for personal
signatures such as developer communication and maintainer uploads. PGP
is really handy because once trust of the key fingerprint for a person
is established, the person can easily make changes such as adding
subkeys, editing the expiration date, revoking keys, etc. at any time.

This would also be less convenient with a CMS-PKI-CA-hierarchy based
system.

Regards
Stephan

[Daniel Kahn Gillmor]

Hi Gioele--

On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote:
> On 21/12/23 04:16, Daniel Kahn Gillmor wrote:
> As the Uploader of rust-sequoia-openpgp, what do you think of the
> related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg
> that uses sequoia internally)?
>
> Would it work as a stop-gap measure while the Debian infrastructure
> moves from GnuPG to something else (to `sop`, for instance)?
>

> [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in
> Debian AFAIK

Thanks for pointing this out! It looks interesting, but i've never used
it (or even tested it) myself. I don't think it can be a completely
perfect, feature-for-feature replacement for GnuPG, given the
overwhelming complexity and peculiarity of the GnuPG interface, but I
imagine it would work for some people, for some purposes.

I certainly wouldn't object to anyone packaging it for debian as long as
it ships its binary interface someplace other than /usr/bin/gpg. Modulo
dealing with the rust dependencies, that seems like an obviously
reasonable and straightforward thing to try to do.

I don't know how the "chameleon" would compare with GnuPG itself in
terms of performance or some of the scaling concerns i mentioned in my
earlier e-mail, but such a straightforward deployment should make it
easy to test.

If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users. This
would be the kind of thing that the experimental archive is designed
for.

One of the ongoing challenges with GnuPG development is the fear of
dropping or mis-handling some feature or flag or option or configuration
that someone has stuffed into some script somewhere and completely
forgotten about. GnuPG itself deals with this kind of problem
regularly, and sometimes things like this do break during an upgrade.
Clawing the way back from such a break actually ends up making the
interface even more complex and surprising to those people who haven't
seen how it accreted in the first place :/ It was scary enough to change
/usr/bin/gpg to move from the 1.4 branch to the 2.x branch many years
ago (we shipped the 2.0 branch as /usr/bin/gpg2, and only finally made
/usr/bin/gpg update when the 2.1.x branch was sufficiently mature). And
even thenm we dealt with the fallout from that change for years
(e.g. see /usr/bin/migrate-pubring-from-classic-gpg in the gnupg-utils
package). The differences were enough that I resisted using
/etc/alternatives to let each installation decide which package offered
/usr/bin/gpg1, because of the dangerous side effects of switching back
and forth (see #806904 for example, and the conversations at DebConf14).
I can only imagine that trying to ship the "chameleon" as /usr/bin/gpg
would face some of the same challenges, probably even more severely.

At best, something like this would be a stop-gap, as you say. i
wouldn't want the long-term health of *PGP functionality in debian to
depend specifically on the command-line interface for /usr/bin/gpg,
regardless of who is implementing it. Even GnuPG upstream appears to
agree with this sentiment, as they encourage programmatic users of GnuPG
to use libgpgme, which is supposed to hide some of the command-line
complexity.

--dkg

[Cyril Brulebois]

Hi Daniel,

Quick backstory: I stayed away from hardware crypto for a long while
since there were so many incompatibilities, partial support, or side
patches to get basic things to work. Over time, it seems it got to a
point where it's mainstream enough that you can buy a Yubikey without
much of a second thought, and get GPG to work out of the box on it…

Daniel Kahn Gillmor <d...@fifthhorseman.net> (2023-12-20):

> 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

… what does this mean for anything that involves hardware-backed crypto?
I'm thinking Yubikeys and the like, but also HSMs that might be on the
critical path to sign things like GRUB, linux (at least for now), etc.

Even if we end up with a brand new gnupg release on the relevant signing
host(s), I fear hardware devices might not feature all the bits that are
needed for those new features?


Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[Guillem Jover]

Hi!

Daniel thanks for all your work on the OpenPGP working group,
and on SOP! :)

On Wed, 2023-12-20 at 22:16:28 -0500, Daniel Kahn Gillmor wrote:
> # 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/

> 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 !

I think this is the way to go, and to try to support that goal I
started a wiki page to track what might need to be switched:

https://gitlab.com/dkg/openpgp-stateless-cli/-/wikis/Stateless-OpenPGP-status

I listed there some potential issues I could come up with for such
migrations. Also at the time, something that felt like a soft blocker
was that the schism was not widely known, so having to give that full
context first for every contacted project seemed a bit awkward, which
now should be out of the way, and a reference to some of the published
articles should be enough.

Time and energy permitting, I'd like to start at least filing issues
for these projects, and ideally provide patches. Help with any of that
would be highly appreciated! Including how to best integrate SOP into
a distribution (I'll be updating one of the tickets for a potentially
better «alternatives» usage pattern).

Also if a project uses perl, and using the Dpkg::OpenPGP modules would
make sense there, please reach out so that we can see what might be
missing so that they can be stabilized to make them public interfaces.

Thanks,
Guillem