[openpgp] Re: Encryption subkey selection

Falko Strenzke <[email protected]>
Newsgroups gmane.ietf.openpgp
Organization MTG AG
Message-ID <[email protected]>
Hi Justus,

thanks for the summary of the discussion and writing up a concrete 
proposal. See my comments inline.

Am 06.04.25 um 12:27 schrieb Justus Winter:
>    - We add a signature subpacket that can be added to subkey binding
>      signatures.  The subpacket body is a single octet representing an
>      unsigned integer, the rank.

I think the rank model does indeed pretty much do the job. There is one 
conceivable type of preference structure that it cannot model, though:

Assume that I have two devices with individual encryption subkeys and I 
want to offer a two alternative subkeys for each device. In that case, I 
would have to give the two preferred subkeys on each device the rank, 
let's say, 2 and the other two alternative subkey the rank 1. This means 
that a sender that can't use one of the rank 2 subkeys, let's say that 
of device A, would switch to the less preferred key on both devices, 
even though he could encrypt to device B with the preferred subkey.

But I tend to think that this scenario doesn't really matter. The most 
complex use case that I can think of is that a user has alternative keys 
of different strength on each device. In that case it wouldn't help them 
if the sender picks the stronger one for one device but uses the weaker 
one on the other (i.e., using differently ranked keys for each device). 
One relevant example is of course ranking PQC keys higher than 
traditional keys.

Thus it seems to me that the rank model is sufficient and a more refined 
model (i.e., parallel chains of preference) is unnecessary.

>    - Open questions (that I can immediately think of, but please speak
>      up if you have more):
>
>      - I think this can be extended to encryption subkey selection over
>        certificate equivalence groups (see the OpenPGP Key Replacement
>        draft) by adding a rank parameter to every equivalence binding
>        signature (essrank_cert), then modify the above procedure to
>        sort by (essrank_cert, essrank_subkey).

I am not sure I understand: Isn't the ranking of certs already given by 
the pointing direction from old to new, i.e. "prefer new over old"? I 
think the existence of a replacement cert should imply: "if you can work 
with this, use it, then the older one can be ignored".

In general I tend to think that keeping the two mechanisms separate is 
preferable, as an implementation may choose to implement one but not the 
other.

>
>      - What should we do for existing certificates that do not use this
>        mechanism?  I guess the path of least resistance is to keep
>        doing whatever the implementation currently does.

Yes, I think the absence of the encryption subkey selection packet (ESS 
as you call it above) should not imply any default selection strategy 
but leave the selection entirely to the implementation. That ensures 
that implementations not supporting the new mechanism are always 
conforming to it when they process certificates not containing the ESS.

But I think we need to define a default rank that is assigned to a 
subkey in the case that at least one encryption subkey in the 
certificate carries the ESS. That would probably be "0".

One more subtlety that comes to my mind is the criticality of the 
preferred encryption subkey packet. If it is not critical, then the 
certificate holder can't rely on the sender encrypting with the 
preferences indicated in the subpacket. If it is critical, then it might 
render the whole certificate unusable (correct? or only the subkey?).

Best regards,
Falko

>
> [Notes from the session:
>   https://www.openpgp.org/community/email-summit/2025/minutes/#encryption-subkey-selection-justus ]
>
>
> Best,
> Justus
>
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
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>

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
smime.p7s (application/pkcs7-signature, 4.9 KB) - not displayed
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.