Re: [openpgp] To bind or not to bind

[Aron Wussler <[e-mail]>]

Hi Justus,

I can't see the irreparable damage that you're referring to. Making a key that a few implementations can't parse IMO offers the same friction than having an expired old key around, and having to distribute a new one to the contacts still using the old one.

On the other hand, I think the argument "whatever is compatible with PQC should also be compatible with V6" is a valid one - and this may boil down to Kai's point, that they're not ready to move to V6.

I agree that adding a V4 PQC key is a bit of a dirty hack, but mandating their refusal may be a too hard solution.

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Wednesday, 27 March 2024 at 13:22, Justus Winter <[e-mail]> wrote:

> 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
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp