From the GnuPG prospective RFC-9580 is a deliberate fork away from what agreement could be achieved. Basically the faction that is now called RFC-9580 (mostly Sequoia and Proton) wanted to make a lot of changes to the existing standard but the faction that is now called LibrePGP (mostly GnuPG and RNP) was not convinced that those changes were necessary.

Traditionally the OpenPGP standards process has been very conservative and minimalistic. GnuPG comes from that tradition. So the RFC-9580 faction created their own maximalist version of the standard and are actively promoting it as the standard.

So from a user perspective, there are two incompatible proposals out there. It's a mess. So it is better to aggressively ignore them both and maintain interoperability by sticking with RFC-4880 (OpenPGP). That might be a problem if you for some reason are still concerned about a quantum attack against cryptography as the post quantum stuff has gotten caught in this schism. It is certainly something that the users need to keep in mind.

▲

throw0101a 4 hours ago | parent [-]

> […] and are actively promoting it as the standard.

Well:

> Category: Standards Track

* https://datatracker.ietf.org/doc/html/rfc9580

▲

upofadown 4 hours ago | parent | next [-]

It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters. FWIW, here is the LibrePGP proposal:

* https://datatracker.ietf.org/doc/draft-koch-librepgp/

Observing the OpenPGP schism mess I think I have gained some insight as to why some RFCs become so bloated. For example it has been recently pointed out that there are 60 RFCs for TLS (with 31 drafts in progress)[1]. The RFC process seems to be more optimal during the design phase. Once we have an established standard there should to be some way to force those that propose changes/extensions to provide appropriately strong justifications for those changes/extensions. Right now it is a popularity contest and there will always be more people out there in favour of changes/extensions than those willing to endlessly fight against those changes/extensions. Because cryptography is so specialized and obscure, the users tend to get left out of the discussion.

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

	▲	throw0101a an hour ago \| parent [-]
		> https://datatracker.ietf.org/doc/draft-koch-librepgp/ "Intended Status: Informational" And anyone can put forward a draft. Here's one for "IPv8" with increased security where "manageable element in an IPv8 network is authorised via OAuth2 JWT tokens" * https://www.ietf.org/archive/id/draft-thain-ipv8-00.html

▲

tovej 4 hours ago | parent | prev [-]

It is a standard proposal, which is why it's in the standards track. The point was that it is not the only (the) standard, and not the universally accepted one.