[openpgp] Re: Encryption subkey selection

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

Hi Daniel--

Thanks for this concrete proposal.  With no hats on, I really like the
simplicity.  A few questions below about wire format, algorithmic
selection details, and semantics.

I note that this proposal is a mix of hard-coded ecosystem-wide
assumptions (dates matter; higher algo-ids are preferable) and minimal
explicit signalling (one cert-wide flag).

I think it can successfully communicate several reasonable simple
strategies that keyholders might want to opt into.  I don't see any
plausibly executable strategies that are superior to the supported ones
that wouldn't be supported by this scheme.  Maybe if such a strategy
does turn up, we could have some additional mode to support it, if it's
worth the additional complexity?

On Thu 2025-05-01 17:10:46 +0000, Daniel Huigens wrote:

> 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.

Are you imagining this as a flag in the Features subpacket?  or some
other way to implement the flag?

> 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_.

Some algorithm IDs support multiple security levels, right?  for
example, an RSA encryption key (algo ID 1) can have a 1024-bit modulus
or a 3072-bit modulus.  Or a generic "ECDH" key (algo ID 18) can
(depending on OID) offer brainpoolP256r1, Curve25519Legacy, or NIST
p521.  It seems not impossible to have two ECDH subkeys with different
curves on the same certificate (possibly even created at the same time).
What should happen in that case?  Maybe we should explicitly allow the
implementer to choose their own preference ordering between curve OIDs
for this legacy EDCH case rather than bikeshedding over some strict
ordering?

Semantically, i think when you say "valid encryption subkey" you mean
"supported valid encryption subkey", right?  that is, the sender allows
fallback to "older" keys (or "lower" algorithm IDs) when the newest (or
highest by algorithm ID) isn't supported.

This would allow a very ambitiously-backward-compatible certificate to
publish a cert with six encryption-capable subkeys with increasing
timesteps:

  K0: RSA
  K1: ECDH/Curve25519Legacy
  K2: X25519
  K3: X448
  K4: ML-KEM-768+X25519
  K5: ML-KEM-1024+X448

I'm not recommending anyone actually create such a monstrosity, but the
scheme described would certainly support this use case.

What do other folks think about Daniel's proposed scheme?

     --dkg