[openpgp] Re: Encryption subkey selection
Falko Strenzke <falko.strenzke@mtg.de> Mon, 07 April 2025 06:48 UTC
Return-Path: <falko.strenzke@mtg.de>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CF010183EDB7 for <openpgp@mail2.ietf.org>; Sun, 6 Apr 2025 23:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=mtg.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeIC4ZzXwTdO for <openpgp@mail2.ietf.org>; Sun, 6 Apr 2025 23:48:41 -0700 (PDT)
Received: from www.mtg.de (www.mtg.de [IPv6:2a02:b98:8:2::2]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 665F6183ED55 for <openpgp@ietf.org>; Sun, 6 Apr 2025 23:48:41 -0700 (PDT)
Received: from minka.mtg.de (minka [IPv6:2a02:b98:8:1:0:0:0:9]) by www.mtg.de (8.18.1/8.18.1) with ESMTPS id 5376mcus001101 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Mon, 7 Apr 2025 08:48:38 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mtg.de; s=mail201801; t=1744008518; bh=L/7IAALdy1krIYiansnUdyAf+VKdTFoCvjLvJrbFPW4=; h=Date:Subject:To:References:From:In-Reply-To; b=btE0YFZgxkCJiiCi2zED3KDiQbDz9utcSjIeW0uDF41bnTiJHAoFpWSXLthvDiZOZ nl6rKXDQReufaoQ9NPlLLuaqzwlK2JK//oUWRYWZNiFctjybz3CSbM4fd2x2TLi1cj 2q3PQ1Awd+gct/B/4r9QqDuWbJ7rFDwBiJSJqCRC3Rn23UW74UQH1JLG25l6OVOryH YuPqSY2g54lihX4riUy5flC4BnDVMZDSNil3ZvoqOBQx/llvxNfuC6eETE6ve9GLdS IMPc4eriOTKKeIiEY4WlcX2HlE+t+WPrPw/l19/kokIWU10wOg7yHQAImUcIbFDrIR lERN1KuV6WTTg==
Received: from [10.8.0.100] (vpn-10-8-0-100 [10.8.0.100]) by minka.mtg.de (8.18.1/8.18.1) with ESMTPS id 5376mbSo028760 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Mon, 7 Apr 2025 08:48:37 +0200
Message-ID: <26f46aef-dde6-4564-92b2-2914aa574944@mtg.de>
Date: Mon, 07 Apr 2025 08:48:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Justus Winter <justus@sequoia-pgp.org>, openpgp@ietf.org
References: <87h631mvol.fsf@thinbox>
Content-Language: en-GB
From: Falko Strenzke <falko.strenzke@mtg.de>
Organization: MTG AG
In-Reply-To: <87h631mvol.fsf@thinbox>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020203070900080300020808"
Message-ID-Hash: 56HAYWKINT4DANWSQAQXUAM5T6TBWQX6
X-Message-ID-Hash: 56HAYWKINT4DANWSQAQXUAM5T6TBWQX6
X-MailFrom: falko.strenzke@mtg.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Re: Encryption subkey selection
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/iLGv1BBoGeQY0xZJSHz7dZuu_a8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>
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 --openpgp@ietf.org > To unsubscribe send an email toopenpgp-leave@ietf.org -- *MTG AG* Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: falko.strenzke@mtg.de 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] Encryption subkey selection Justus Winter
- [openpgp] Re: Encryption subkey selection Andrew Gallagher
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Bart Butler
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Andrew Gallagher
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Daniel Huigens
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Daniel Huigens
- [openpgp] Re: Encryption subkey selection Andrew Gallagher
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Andrew Gallagher
- [openpgp] Re: Encryption subkey selection Justus Winter
- [openpgp] Re: Encryption subkey selection Daniel Huigens
- [openpgp] Re: Encryption subkey selection Daniel Kahn Gillmor
- [openpgp] Re: Encryption subkey selection Falko Strenzke
- [openpgp] Re: Encryption subkey selection Daniel Huigens
- [openpgp] Re: Encryption subkey selection Daniel Huigens
- [openpgp] Re: Encryption subkey selection Johannes Roth
- [openpgp] Re: Encryption subkey selection Daniel Huigens