[openpgp] Re: Encryption subkey selection

[Daniel Huigens <[e-mail]>]

Hi all,

I would like to try to make a slightly more concrete proposal here,
justified in part by the parallel post about PQC key selection [1].

I would propose that we add a single flag to the certificate, in a
direct-key signature (for v6) or primary User ID binding signature (v4)
subpacket, which says: "please encrypt to all valid encryption subkeys
in this certificate". By default, the flag would be off.

If it's off (explicitly or implicitly), the implementation should select
the newest valid encryption subkey, or - if there are multiple valid
encryption subkeys with the same creation timestamp - the subkey with
the highest _algorithm ID_.

This is based on the assumption that we won't add new algorithms that we
consider to be less secure than the ones we already have. If we ever do,
we could carve out an exception at that point, or recommend that people
don't use it in parallel with a more secure algorithm in a subkey with
the same creation time.

This guidance would also be consistent with the recommendation in
draft-ietf-openpgp-pqc-07 to prefer PQC subkeys over traditional
subkeys, though that was removed in draft-08, but I think perhaps
we should bring it back (see [1]).

Finally, as discussed before, this would enable both multi-device setups
with one encryption subkey per device (when the flag is on), and also
encryption algorithm migrations without certificate rotation (when it's
off), just not both at the same time. I think wanting both at the same
time is quite an edge case that we shouldn't worry about. I know I said
before that we shouldn't worry about encryption algorithm migrations
without certificate rotation either, but if it's useful for PQC and
helps to get that draft out the door sooner, perhaps that's worth
reconsidering. Also, I think the mechanism above is still quite simple.

Hopefully this makes some sense, but let me know what you think!

Best,
Daniel

[1]: https://mailarchive.ietf.org/arch/msg/openpgp/ipOOKb5TKii_xtNxe3gifF50d2w/