[openpgp] Re: Encryption subkey selection

[Daniel Huigens <[e-mail]>]

Hi Johannes,

On Tuesday, May 6th, 2025 at 11:29, Johannes Roth wrote:
> I agree with Falko that the ordering by algorithm ID is not ideal.
> Currently, with ML-KEM only, this is not a problem. As soon as we add a
> new algorithm that also has two IDs with different security levels, the
> logic doesn't guarantee the preference of the stronger keys.

If we do so, I would expect the certificate holder to want to pair the
two algorithm variants of equal strength. Otherwise, why would you add
a new subkey that's weaker and presumably less well-supported than the
one you already have? Alternatively, as I said before, we can tweak the
encryption subkey selection algorithm once we add those new algorithms,
if there's a concrete reason for it at that point. But also note again
that I'm not claiming that this algorithm will select the strongest/
best/most awesome subkey in all possible scenarios, just that it gives
a reasonable baseline for certificate holders to be able to reason
about which subkey(s) will be selected, and then act accordingly.

> Personally I am a bit skeptical about specifying the subkey creation
> time as a primary selection criterion. It somewhat overloads the simple
> statement about the creation time. If you have a PQC-only certificate
> and realize you need an ECDH key for backwards compatibility, you would
> need to set the creation time to an earlier date than your PQC keys
> which is counter-intuitive, and also requires you to add this delta to
> your expiry time, otherwise it will expire earlier than intended. At
> this point, I would consider it more sensible to let the certificate
> holder express his order preferred order explicitly.

I think that if an implementation of OpenPGP today (or in the near
future) gives you a PQC-only certificate, and you don't already have an
ECC fallback certificate, then that's a very strange choice and the
implementation should've warned you against that. If it does happen,
you could always add a fallback ECC certificate (rather than a subkey)
and bind them together using Andrew's replacement key draft (with the
ECC cert as the fallback).

> Bottom line: I think having such a default logic makes sense, but I also
> think it won't reliably solve the problems it addresses. In case we only
> specify PQC algorithms from now on, it would at least ensure the
> prefernce of PQC keys.

I think it's likely we'll only specify PQC algorithms from now on;
doing anything else would be strange, unless some major changes in
the predictions about cryptographically relevant quantum computers
occur, in which case we can reevaluate.

Best,
Daniel