Re: [openpgp] To bind or not to bind

[Justus Winter <[e-mail]>]

Aron Wussler <[e-mail]> writes:

> And add an explanation, the test failures are:
> - pgpy that is a fairly niche implementation
> - gopenpgp that is mostly in control of a single provider (and we should take care of updating our clients to v3)

I had a closer look at the test past-me wrote.  Quoting the description:

> The test verifies a signature with a certificate containing a mock key
> using an unsupported algorithm or curve. The signature is made using
> the primary key over the message Hello World :). The mock subkey is
> not involved in any way, besides being present in the certificate.

So the test is trying to verify a signature using the certificate that
contains the PQC encryption key, it is not only affecting encryption.

For example, this will likely affect Github, who is using an
implementation related to gopenpgp, and, given that they haven't even
managed to migrate to gopenpgp v2, I doubt that they will in due time
migrate to the not yet released gopenpgp v3.

I don't want to pick on gopenpgp too much, but I have been identifying
forward compatibility problems in gopenpgp and other implementations for
years, and right now, as I'm writing this, there are open issues in the
tracker:

- https://github.com/ProtonMail/gopenpgp/issues/69
- https://github.com/ProtonMail/gopenpgp/issues/70
- https://github.com/ProtonMail/gopenpgp/issues/72

All these issues include the words "Unknown versions [...] should be
ignored to allow for a smooth evolution of the OpenPGP message format",
or words to that effect.

I think it would have been great to allow PQC encryption subkeys in v4
certificates.  But now I fear that this ship has sailed, and introducing
PQC encryption subkeys to v4 certificates will break in unexpected
places and this will outweigh the benefits that you see.

> - rnp, that AFAIK mostly affects Thunderbird. Given that Kai seems to be fairly supportive of v4, it's in his interest adding that flag to the packaged build.

And then we tell every downstream consumer of RNP that they must use
this one weird trick when importing certificates or RNP will choke on
PQC-enabled v4 keys?  That doesn't seem viable to me.

Best,
Justus