Support ML-KEM-768+X25519 (algorithm ID 35) in the default build configuration

[kaie]

Thunderbird considers to support v4 OpenPGP keys with an (additional) v4 encryption subkey that uses algorithm ID 35 (ML-KEM-768+X25519).

It would be great if RNP could have code that supports it, being compatible with that algorithm as it is specified for v4 keys in draft-ietf-openpgp-pqc.

As I understand it, PR #2355 has code that implements the necessary compatibility (based on the most recent draft). It would be great if it could be merged.

I've done some experiments (see also https://bugzilla.mozilla.org/show_bug.cgi?id=1848103 ).

I've learned that RNP v0.17.1, or v0.18.0 with PQC disabled, doesn't have forward compatibility to tolerate keys in its keyring that contain such a subkey with algorithm ID 35. Rather, when attempting to load such a keyring, RNP will abort loading it with an error, complaining about the unknown algorithm ID.

Would you consider to change RNP so that algorithm ID 35 is enabled by default, without requiring a special build time option?
(I understand that it would be reasonable to wait until after the above draft is finalized.)

The scenario that I'm worried about are users, who might switch between using binaries from thunderbird.net and binaries from another distributor. While we could ensure that software from thunderbird.net is always built with PQC enabled, distributions might not be aware of that need. And if the user has generated a algorithm 35 subkey, a user of another RNP binary distribution might unexpectedly experience an empty list of OpenPGP keys in Thunderbird.

Supporting keys with algorithm ID 35 by default could avoid that problem.

Should you have concerns about enabling full support for that algorithm by default, I could understand.
However, in that case, it would be really nice it those subkeys could be silently carried along (kept available, even if unused), instead of aborting load.