[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]