Support for v5 keys is being seen as endorsement, is used to delegitimize the IETF standardization effort

[teythoon]

• OpenPGP.js version: 5.5.0

OpenPGP.js supports draft-koch-openpgp-2015-rfc4880bis (aka "v5 OpenPGP"), at least partially, to increase compatibility with newer versions of GnuPG 2.4.x. This is a noble cause, but is unfortunately seen and sold as an endorsement of "v5" and is being used to delegitimize the standardization effort of the IETF OpenPGP working group.

For example, librepgp.org says:

The updated specification, soon to be dubbed LibrePGP, as implemented by RNP (Thunderbird), GnuPG, and OpenPGP.js [...]

And, https://mstdn.social/@GnuPG/111453574118631875 says:

The v5 format is also implemented by OpenPGP.js (backed by Protonmail) [...]

Please drop support for "v5", alternatively disable it by default and put it behind a configuration flag.

[larabr]

Hi Justus, thanks for bringing this to our attention.
Generation of v5 keys is already behind feature flag (off by default), and won't be possible in the coming version of OpenPGP.js.
The reason why we are keeping support for processing the packets is primarily because we have supported generating v5 messages and keys in the current and previous versions of OpenPGP.js tho, and dropping support would be disruptive for the OpenPGP.js userbase who has used them.

We could add a notice in the README clarifying how we keep support for v5 for legacy reasons only, as the format is deprecated. @twiss other ideas?

[teythoon]

The reason why we are keeping support for processing the packets is primarily because we have supported generating v5 messages and keys in the current and previous versions of OpenPGP.js tho, and dropping support would be disruptive for the OpenPGP.js userbase who has used them.

Well, another way to look at the issue is that we are in a bad spot already, and the "v5" rift is already disruptive for OpenPGP.js users, and indeed all OpenPGP users, and acknowledging that releasing support for "v5" in stable versions was a mistake (we all did that, to some extend), and the best way forward for everyone, including existing OpenPGP.js users, is to decisively correct that mistake by rejecting these artifacts now by default.

And I realize that this is not an easy decision to make, and this has the potential to annoy downstream users. When Sequoia started rejecting SHA1-based binding signatures, we lost a very high-profile user due to that. Nevertheless, we believe that rejecting SHA1-based binding signatures improves the overall security of OpenPGP users everywhere, and is a benefit for the ecosystem as a whole, and we'd do that again.

But, it is important that we act in unison on this kind of issues, or else we risk a race to the bottom: every implementation can try to "increase their market" share by being more permissive, but this has a detrimental effect for the ecosystem.

[larabr]

It seems to me that dropping support for v5 in the new versions of OpenPGP.js will encourage users (who need v5) to stick to older versions of the lib which supports v5. As a result, they will not get to take advantage of the crypto-refresh support, nor will they automatically benefit from v6 key generation once that's on by default.

I don't think releasing v5 support (without automatically generating new keys) was a mistake, it's a choice that made sense at the time, when there were no clear sign that the IETF standardisation effort would restart. I want to reiterate that OpenPGP.js never automatically generated v5 keys or [legacy] AEAD-encrypted messages, as these were always behind feature flags. That said, I don't blame users for enabling those features, and I think the best way forward is providing everyone with a smooth transition to v6 keys & co.
The inability of generating v5 keys will mean we won't "onboard" anyone into the non-standard part of the ecosystem.
Deciding not to drop code that we already implemented is also not a promise that we will keep up with future developments, nor should it be seen as endorsement.

FWIW, for the current OpenPGP.js version, we should probably also mark @deprecated the feature flag that enables v5 key generation, as well as the ones which control features based on the draft RFC4880bis (e.g. AEAD), which will change in format with the new lib version. After all, we know that AEAD key encryption suffers from security issues when it comes to public key integrity (kopenpgp.com), and the AEAD-encrypted message format opens up the possibility of a backwards compatibility attack if GCM is used.