Oh man. It's been almost a week, and no reply at all 😂

The "Libre" draft has always felt rather unserious to me, in various ways. This seems like one more bit of empirical underpinning for my preconceptions.

Yay! This in itself is already an excellent result of this little distributed PGP activity of the past few days. There's always one more strange wrinkle 🫣

Nice digging, but also ... oh no. That's a rather long time for this encoding to exist without any footprint in any of the drafts :-/ *sigh*

I'd love to hear more about that, too! (I did dig into libgcrypt earlier today to try and see what's going on with these prefix-less ECC points. But my C reading comprehension was insufficient to get to the bottom of that.)

I don't want to argue against Andrew, but personally, I honestly wonder if it wouldn't be better to leave all of these potential changes parked on the sidelines, for the time being.

To dump some more information here:

The v6 format is totally done, it lives in www.rfc-editor.org/rfc/rfc9580, and there are at least 6 interoperable implementations of it

The IETF side of the PQC-specific schism is datatracker.ietf.org/doc/draft-ie..., and that's in the last stages of the process

The highest profile opinionated public information that I'm aware of is at wiki.archlinux.org/title/GnuPG#...

That would be really good to have, at this point. right.

For the longest time, some hope remained for a (partial at least) good faith collaborative truce of sorts with GnuPG. But after their (rather recent) break from the PQC standardization, we are probably past any hope for reconciliation.

OpenPGP semantics already is a scary can of worms as it is 😅 but agreed, "detaching" subkeys from a primary might be nice UX for some cases.

One similar practical thing that people have been doing is moving subkeys from one primary to the next. Binding them to a new "root of trust", so to speak.

As a higher profile user you would probably get a heads up that shenanigans are happening. But that won't stop tools from showing green checkmarks in all the wrong places.

The "S" flag denotes if *data signatures* should be considered valid by recipients.

Analogously, "C" for third-party identity certifications from your primary.

But you can't really stop other users from trusting new subkeys that your primary has bound to itself.

The primary always implicitly acts as a trust anchor.

There is no meaningful defense within the OpenPGP model of trust against an attacker who brute forces the private parameters of your primary key.

Yeah, right now you can move on from DSA 1024 as the effective weakest point for practical attacks to Curve 25519. Nothing to sneeze at, I'd say. But sure, it's far less sexy than a hybrid with PQC.

In a less stupid timeline, we'd have this by now. Alas 😩

GnuPG has effectively totally self-isolated. There is just one other (minor) implementation (RNP) that has signaled any degree of positive interest in GnuPG's "LibrePGP" fork of the standard

However, even RNP has shown no intent to implement GnuPG's PQC (or bare Ed448) formats, as far as I can tell

But I don't see how that attempt could get serious traction in the floss world. It's just a massive pain in the neck and distraction.
All large distros have moved away from GnuPG for package signature checking, or are in the process of doing so.

This trend seems unlikely to slow down after gpg.fail

A number of humans are trying hard to improve on this, but the problem is much less a technical one than one of collective action, in a rather ... unfortunate overall situation.

GnuPG is doing its best to muddy the waters with its attempt at speedrunning its non-IETF PQC design.

As a pragmatic note: For use in an "infrastructure" context (in which a broad range of tools - such as git, and distro tooling -interact with OpenPGP signatures), the currently best common denominator are v4 keys with Curve 25519 over EdDSA and ECDH.