[openpgp] Re: Encryption subkey selection

Daniel Huigens <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <7A1MlNotxZz2mOzBwnGav1Ozae9RCILINWm9i08ifsvuCiqFo7-e0qLeztMckwmC-et2Na2dvjUv9i_9uyZZJ33x1j_kLEzn6rG5QegEeak=@protonmail.com>
Hi dkg,

On Tuesday, May 6th, 2025 at 00:58, Daniel Kahn Gillmor wrote:
> Are you imagining this as a flag in the Features subpacket? or some
> other way to implement the flag?

I was thinking we could define a new signature subpacket for this;
maybe "Key Usage/Selection Preferences" in case we want to reserve
the possibility to define other similar preferences in the future?

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

Yeah, I think it's fine to leave certain very specific cases undefined,
and the implementation can either do something clever or just pick the
first one, if it prefers.

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

Yeah, indeed; from the perspective of the older implementation, the newer
subkey wouldn't be valid because it doesn't understand it.

Best,
Daniel

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.