Question on Integrity of Sequoia-PGP Developers

[Matt Borja]

Hi,

Yeah, so this is also totally understandable and I think to be expected with the evolution of technology itself.

In July of this year (2025), NIST announced the release of the latest major update to their Digital Identity Guidelines (NIST SP 800-63-4) that had not seen much activity since 2017:

https://www.nist.gov/identity-access-management/projects/nist-special-publication-800-63-digital-identity-guidelines

I think to your point, this is the sort of “stewardship” of a given standard (or any standard) that would be necessary to mitigate these types of schisms (e.g., when NIST goes to revise a standard, companies are normally expectant and eventually follow suit).

If in this space, the equivalent is IETF with the OpenPGP Working Group as the standards governing body, and this is how changes are managed for the industry, then fine. I would just clarify though that we don’t necessarily call it different things when dealing with NIST. It’s still “Digital Identity Guidelines” NIST SP 800-63 whether it’s the 2017 version or the massively overhauled 2025 version that current implementations may now be falling behind on. And “OpenPGP” should still mean “OpenPGP” whether now on the 2024 standard, or the 2007 version…or the 1998 version for that matter.

So, Vincent, to address your question, if RFC 9580 is the succeeding standard being ratified by this IETF group, then you will inevitably see my technology decisions and training materials moving towards that. I wasn’t aware of the 2024 update at the time I prepared my slides, but that doesn’t negate what I said earlier about staying truest to form, even when that form (standard) changes.

It’s one thing to have varying implementations of a given standard. We just can’t be having multiple standards surrounding the same thing. That just renders the whole thing meaningless. To wit, it’s going to be harder for me to sell something that has not been endorsed (by IETF standards process in this case) than something that could even be, let’s say, theoretically wrong, that is endorsed. But as an engineer, if I get in there and find out Koch was right about LibrePGP and that that should’ve been the next version, but we go end up ratifying the other one instead, I’m just going to rage quit :P It’s not that I wouldn’t agree with him at that point; there are just way too many hills to die on out there and not enough bodies. And I’ve already died on mine at this point.

The draft expires in 7 days and still has not been acknowledged it seems, but this is what I would have to look to: https://datatracker.ietf.org/doc/draft-koch-librepgp/

Trust me, I do know the feeling.

Hoping for the best,

Matt Borja

On Thu, Sep 11, 2025 at 02:24, Meik Michalke via Gnupg-devel < [gnupg-devel at gnupg.org](mailto:On Thu, Sep 11, 2025 at 02:24, Meik Michalke via Gnupg-devel <<a href=)> wrote:

> hi,
>
> Am Donnerstag, 11. September 2025, 05:54:44 CEST schrieb Matt Borja via Gnupg-
> devel:
>> But we also have to remember that it’s ultimately the standard we’re most
>> concerned with and need to be conformed to, not a specific implementation.
>
> actually, the schism does cut deeper than that. when we say "OpenPGP" today,
> unfortunately, it is no longer "the standard" it used to be for many years.
> the conflict lines weren't just about implementation, but about the evolution
> of that standard itself. at a certain point, the direction this discussion
> took was seen as so wrong by the GnuPG devs that they felt it pointless to try
> and hold on to what was about to be named "OpenPGP" in the future. they took
> what was originally discussed to become the new OpenPGP standard (a stable but
> necessary update without disruptive changes), and named it "LibrePGP". in that
> sense, LibrePGP is actually a fully compatible evolution of the old OpenPGP
> standard, while the new OpenPGP standard breaks continuity at certain points.
>
> it's a paradox, but if you want to continue to support what used to be OpenPGP
> in the past, you would now need to abandon OpenPGP and support LibrePGP
> instead. it's a bit like when an established brand is bought by another
> company that uses it to sell products that do not continue to uphold what made
> the brand in the first place. it would have been a much better and more
> transparent decision if LibrePGP had been the updated OpenPGP standard as was
> originally planned, and the disruptive, new standard would have been given its
> own new name.
>
> if you want to go into the details, there's a homepage explaining all of it:
>
> https://librepgp.org
>
> it is true what has been written here before, that compatibility and stability
> are values held up high by GnuPG. it is a pitty that it came to this. it
> wasn't necessary to be this nasty and painful a process.
>
> disclaimer: i do work for g10 code/GnuPG. but i joined the company long after
> this conflict emerged and had no part in that. but i do admit that personally,
> i do find the arguments for LibrePGP much more compelling.
>
> viele grüße :: m.eik_______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250911/b570d4a8/attachment-0001.html>