Re: [openpgp] To bind or not to bind

[Justus Winter <[e-mail]>]

Hi Andrew :)

Andrew Gallagher <[e-mail]> writes:

> On 27 Mar 2024, at 11:03, Justus Winter <[e-mail]> wrote:
>> 
>> I could also add a PQC encryption subkey to my *existing* v4 key.
>> In this case, I think it is not unreasonable to expect it to continue to
>> work with PGPy (or GopenPGPv2), but it does not.
>
> I think this is a valid concern, however the impact is highly
> dependent on how many deployed clients rely on these libs. If Proton
> and Thunderbird were able to migrate themselves within a reasonable
> timeframe, what would be left outstanding? Are we getting worked up
> over something that has a relatively straightforward fix?

I don't think the fix is as straight forward.  Because there are a great
number of v4 implementations out there, some of which we don't even know
exist.  How can we know how these are sufficiently robust to support
this opportunistic upgrade path?

We can not, of course, but we can make an educated guess based on the
available data.  I survey a subset of implementations, among them the
most notable ones.  And the results indicate that even among the most
notable ones (which are presumably of higher quality), we don't see the
required robustness that we'd need to do this right now.

This leads me to believe that many of the unknown implementations (which
are presumably of lower quality, not because of a lack of skill, but due
to a lower amount of (public) exposure) will also not be robust enough.

As a single data point, we know that Github uses an implementation
derived from Google's OpenPGP implementation for Go (which aiui GopenPGP
is also derived from).  Assuming the test results for GopenPGPv2 hold
for x/crypto/openpgp, adding a PQC encryption subkey to a v4 key would
break Github's signature verification.

Best,
Justus