On 18 Dec 2024, at 09:07, Werner Koch via Gnupg-devel <[email protected]> 
wrote:
> 
> It then got stuck by people who
> wanted to completely overhaul the spec and do an OpenPGP 2.

Anyone who has worked with OpenPGP for any length of time and who doesn’t have 
a burning desire to completely overhaul the spec IMO hasn’t been paying 
attention. Yes, some of the newer implementations have got it wrong at times. 
But you either find some imperfect way to work with the youngsters and their 
new-fangled ideas, or they will ignore you and leave you behind. That’s the 
great, timeless tragedy of existence.

> Search the
> WG ML for this (sometime around 2017/2018).  The end result of the WG is
> an extensive rework of the specification and not the planned move to
> newer algorithms (SHA-2, Modern AE) and integration of the ECC RFC.

It’s true that crypto-refresh performed a significant overhaul of the 
*structure* of the document, which does make detailed comparisons more 
difficult than perhaps they could have been. But the end result of the WG *was* 
the planned move to newer algorithms, and it *did not* extensively rework the 
semantics.

For the record, there’s a great (if slightly outdated) summary of the 
non-editorial differences between “crypto-refresh” (now RFC9580) and 
“rfc4880-bis” (now LibrePGP) here:

https://mailarchive.ietf.org/arch/msg/openpgp/aqBy97lj2P4DVxTds0eKZDVdmms/

NB at the time of writing, both crypto-refresh and rfc4880bis specified 
conflicting “v5” formats. To fix the ambiguity, crypto-refresh's v5 => 
RFC9580’s v6. In addition, both specs have since adopted some ideas from each 
other, so the differences are not as great as the above summary suggests.

The fundamental incompatibility between the two specifications is not 
technical. The irreconcilable difference is that one person has a veto over 
LibrePGP, but nobody has a veto in the IETF WG. Most implementors consider this 
a positive development.

>> forward is for you to continue to evolve rfc4880bis (now under your
>> new "LibrePGP" banner).
> 
> Not mine.  LibrePGP is a specification agred upon by the major real
> world implementations.

LibrePGP is a specification agreed upon by *two* implementations. If you 
arbitrarily include RNP (i.e. Thunderbird) but not openpgp.js (i.e. Protonmail, 
Mailvelope, FlowCrypt) in the “major real world implementation” category then 
I’m not sure what else to say.

A

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Reply via email to