Re: [openpgp] To bind or not to bind

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2024-03-22 18:51:30 +0000, Andrew Gallagher wrote:
> On 22 Mar 2024, at 18:20, Justus Winter <[e-mail]> wrote:
> 
>>  https://tests.sequoia-pgp.org/#Mock_PQ_subkey
>
> Is it possible to update this test with the optional flag that Falko
> mentioned, to see if it improves RNP’s score on line 3?

See https://gitlab.com/sequoia-pgp/rnp-sop/-/issues/2

> If it does, I’d argue that this is no longer fatal - gopenpgp v2 has
> been superseded already,

Has it?  https://github.com/ProtonMail/gopenpgp/tags suggests that the
latest non-alpha release of gopenpgp is 2.7.5.

> pgpy is fairly niche.

pgpy upstream has also been unresponsive for nearly a year, sadly.  the
branch i worked on for the crypto-refresh probably has the most active
maintenance, and i haven't even tried to release it :( I should probably
consider releasing it myself (maybe under another python module name) at
some point if upstream remains unresponsive.  I don't really want to
shoulder the full maintainer burden though.

> There is still a potential issue with large subkeys, so maybe we could
> test to see where the size limit actually is for each if the
> implementations that fails line 4? We may still need to RECOMMEND that
> only “small” PQC encryption keys should be used with v4; but for the
> purposes of early adoption, one algo may be enough.

I think the "big" mock keys in the Mock PQ Subkey tests are "huge data
(unrepresentable as MPI)", which aiui means > 8KiB, but the test doesn't
produce those artifacts for inspection:

https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/134

If that's right, then it would put SLH-DSA-SHAKE-128f and
SLH-DSA-SHAKE-256s out of reach, but all the other proposals would fit.

               --dkg