[openpgp] Re: Encryption subkey selection

[Falko Strenzke <[e-mail]>]

Am 06.05.25 um 00:57 schrieb Daniel Kahn Gillmor:
> 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).

Preferring the higher algorithm ID doesn't work for a simple reason: 
there are different security levels for each algorithm stacked one after 
another as code points (2 for ML-KEM currently). This means that the 
suggested selection mechanism might result in the preference of strictly 
weaker keys.

Best regards,
Falko

>
> 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
>
> _______________________________________________
> openpgp mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>