Re: Post-quantum defaults

On 27/04/2026 11:26, Werner Koch wrote:
 >
 > The MTG and BSI folks eventually came up
 > with a draft and - according to personal communication - on suggestion
 > from certain attendees at an IETF meeting

Which particular attendees? You keep blaming things on unnamed people. 
Maybe you think it's impolite to name names, but it reads like a 
conspiracy theory. I've been at most of the meetings you mention, and 
they're not as sinister as you make out.

The IETF WG is mostly a bunch of goofy nerds. I count many of them as 
personal friends. They're trying to do the right thing, in the face of 
the inevitable disagreements and technical challenges and 
backwards-compatibility nightmares. We don't get everything right, and 
that's OK. That's why we rely on each other to point out blatant 
mistakes and missed opportunities, and the ways we can all do better 
next time. It's difficult, but it's healthy. Nobody can be expected to 
do critical infosec work by themselves. We need each other, and mostly 
we enjoy it.

(It might not seem that way on the mailing list sometimes, but family 
arguments aren't the end of the world!)

 > to change from the usual PGP
 > way to the uncommon thing of assigning a public key algorithm id to
 > each combination of algorithms and parameters.

The rough consensus in the WG during the drafting of RFC9580 was that 
parameterised algorithm code points cause more problems than they solve. 
The new algorithms in RFC9580 (but not the existing ones!) follow this 
convention, so it makes sense for the PQC draft to do the same.

Most implementers agree that the new convention is cleaner. However, 
this point is obviously not crucial for any security properties. It's 
surely not necessary for GnuPG to diverge from how the rest of the 
OpenPGP ecosystem represents PQC keys on the wire, which is largely a 
minor matter of taste.

Is this the hill that you're willing to die on? A numbering convention? 
*Really*?

 > The WG later changed more
 > things which I did not follow in particular because the important
 > Brainpool support was also removed by them.

There was some initial disagreement about how many curves in total to 
specify, so the document was split to avoid getting bogged down. The 
first document specifies curves 25519 and 448, and the second document 
specifies the NIST and Brainpool curves:

* https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
* https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-nist-bp-comp

Brainpool support was always a goal of the process. Remember, the BSI 
are co-authors of both documents. There was surely no need to fork the 
PQC draft in order to satisfy the additional curve requirements of your 
client (i.e. the BSI)?

 > I later had a meeting at the BSI (iirc, due the projects goal of
 > implementing the algorithms in Libgcrypt).  It was important to them
 > that their key combiner needs to be used.

It is also important to remember that BSI have agreed to the updated KEM 
combiner from draft-ietf-openpgp-pqc, so there is no reason for GnuPG 
not to implement it. I find it totally bizarre that you are using a 
private meeting with the BSI as an argument *against* implementing a 
BSI-instigated and BSI-approved specification.

 > And that is what Niibe-san
 > and me implemented in GnuPG and later specified in LibrePGP.

I can never tell whether your recurring name-dropping of Niibe-san in 
these arguments is meant to credit him for his achievements, or use him 
as a scapegoat.

I have not forgotten how you let him put his name to RFC9580 and then 
threw him under the bus by condemning the results of his work, after you 
had quit the design team in a huff because you could no longer work with 
the WG. It is none of my business whether you have ever apologised to 
him in private, but your lack of public remorse has not helped the PGP 
ecosystem shed its toxic public image.

We need to foster a more inviting community, or it will die with us.

 > The changes affected only protocol format details and not the actual
 > crypto.

I agree the security properties are the same. I just feel it is a 
disastrous situation to specify two almost-identical KEM combiners for 
two almost-identical protocols, simply because communication channels 
have broken down.

You don't engage with other implementers, you miss meetings, you rely on 
second-hand information, you implement and ship outdated specs, and then 
you throw shade at everyone else for making decisions that you don't 
agree with. Decisions that, when viewed from outside this little bubble, 
*don't matter*. But this tinpot disagreement is escalating to the point 
where end users are abandoning the PGP ecosystem entirely. Is that the 
outcome we want?

Please, for the love of all that is good and beautiful in the world, can 
we work together to implement algorithm 35 from draft-ietf-openpgp-pqc 
in GnuPG, so that we can at least have one point of commonality between 
PQC implementations? *I will help you*. I will work for free. I just 
want this to be over.

A

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