Re: [openpgp] algorithm specification for PQC

[Daniel Huigens <[e-mail]>]

I prefer option B. (Though personally I would ideally only have
algorithms 1, 2, 7, 8, and maybe 13, but even having all of them
I prefer it to option A.)

On Friday, July 22nd, 2022 at 23:57, brian m. carlson wrote:

> I would strongly prefer [option A]. This is what we already do for
> ECDH, ECDSA, and EdDSA and it avoids a giant multiplication in algorithm
> IDs (which is a problem if we have only one octet). Not that I love the
> proliferation of curves, but if, say, Germany wants to use Brainpool
> curves in conjunction with Kyber or Dilithium, it allows that to happen
> without us needing to issue more algorithm IDs.

I know that option A is more consistent with the existing spec, but this
is part of the advantage of option B that I see, that we can shed some
of the weirdness of ECDH-over-Curve25519 in favor of standard X25519,
for example. At some point in the future if all implementations support
these new algorithms, then a greenfield implementation could shed this
weirdness. If we bake the current ECDH into post-quantum algorithms,
then we'll be stuck with it for far longer.

I also don't think that algorithm IDs are likely to run out, and if they
do we can switch to two-octet algorithm IDs in v6 keys, or something
like that.

Best,
Daniel