[upofadown]

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]

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

Well:

> Category: Standards Track

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

[upofadown]

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]

> 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

[ekr____]

> It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters.

I don't think this is really true. A huge fraction of proposed documents just go nowhere, and it's really quite common to see a new proposal get presented and be shot down by one or two people (Source: I've been one of the people doing the shooting down on more than one occasion)

[tovej]

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.

[ekr____]

A few points about the IETF process:

- As a practical matter, anything that is a Proposed Standard RFC is a standard. In principle, there is a two-level system with PS and Internet Standard (down from three levels) but most WGs don't bother to advance specifications past PS. For example, TLS and QUIC are both PS.

- RFC 9580 obsoletes RFC 4880, so from the perspective of the IETF, it supersedes it. Of course, this doesn't make people do anything.