[openpgp] Re: Encryption subkey selection

[Daniel Huigens <[e-mail]>]

Hi Justus & all,

I agree that it would be good to reach a consensus on this, and that
if we assume that we want to support one-subkey-per-device setups
(e.g. for use with integrated HSMs, to be able to generate a key
on each of your devices in hardware), which seemed to be the
conclusion from the multi-device session at the summit,
then we probably need some mechanism for that.

_However_, I want to raise one specific potential solution that
Patrick Brunschwig proposed in that session, which is a variant of
"List of sets of subkeys", but rather than introducing some new
encoding for this, we could simply say: each certificate is such
a list of subkeys. In other words, we pick the first certificate,
see if it's usable, if so use all valid encryption subkeys in that
certificate. If not, try the next certificate. And so on.

This means that, to migrate to a new encryption algorithm, you also
need to generate a new certificate. Often we want to do that anyway:
in the migration from RSA to ECC, and ECC to PQC, we've introduced
both new encryption algorithms and new signing algorithms.

I know this goes a bit against what I've said previously and also
conflicts with the concept of "certificate equivalence" in the
key replacement draft (because multiple subkeys across linked certs
would then not behave the same as multiple subkeys in a single cert).
_But_ if we all agree that we need some mechanism for this then
I think it's best to pick the simplest possible mechanism.

---

Alternatively, as an intermediary solution, we could have a single
_per-certificate_ flag which says: please use all valid encryption
keys in this certificate. (And potentially also: if you don't
understand all encryption subkeys, please use the fallback
certificate instead, if there is one. That being said, I think
it would be a bit silly and a very niche edge case if you want
to e.g. use a mix of ML-KEM-768 and ML-KEM-1024 subkeys in
your latest cert, _especially_ you're going to ask the sender
to encrypt to all of them, as then there's no security advantage
to using ML-KEM-1024 in one/some of the subkeys).

That way, we could keep the existing behavior for a single cert,
if needed (so that you could still do a encryption algorithm
migration within a single cert if you only have a single device),
but could opt-in to the new behavior (from our perspective;
obviously for Sequoia it'd be the other way around) if you have
multiple devices.

The only thing you then can't do is an encryption(-only) algorithm
migration within a single certificate with per-device subkeys.
But, that kinda seems like an edge case within an edge case..

Best,
Daniel