IETF Logo Mail Archive

[openpgp] Re: Encryption subkey selection

Bart Butler <bart+ietf@pm.me> Mon, 07 April 2025 08:19 UTC

Return-Path: <bart+ietf@pm.me>
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 672CF1846AB9 for <openpgp@mail2.ietf.org>; Mon, 7 Apr 2025 01:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=pm.me
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 IdqvEdBJ240h for <openpgp@mail2.ietf.org>; Mon, 7 Apr 2025 01:19:29 -0700 (PDT)
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (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 570C21846A95 for <openpgp@ietf.org>; Mon, 7 Apr 2025 01:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1744013967; x=1744273167; bh=E8XJBpeJ52BlumKDuOfm1+vREGItfjoEwXLN/vGRNVQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=My8l73DIVxquCU1qluIk/5j3PSS4B3C+4ReAOG6epZ0PyF9SU71C0t5e4jlYQgfGy 4tQJDfbBBvmkIBecRBakW9hUxvdXl7I45DopJ6MI2L7DWz7uAuen4DtQxcuFXS1xZt lgEABpM6iTg20gWoHrPPQZR0l6GSITKy9rjd7KsK1RKaJhD6BDlmDDToHS9Z557fs1 fAdcpPMYPwB4cqTnLxav8HTMgdd6sm5wHwsx2dxjNqJdYraKOygAcOd3z8OoIsQX96 8bBiCLfi6jsa7WJOuVe3Cf3pW4V89BSKPxiF6msw5exWUZ86iDgYUOXqup5T+ADTX4 hXq72wrVYXiWg==
Date: Mon, 07 Apr 2025 08:19:24 +0000
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
From: Bart Butler <bart+ietf@pm.me>
Message-ID: <-r7DKP-up_y2Y19C3aR7UREiHK6ddwWmMF9wJ55R52gaDYWBiRBQYI5rMI6HXFbuWqZC9ykPncT3fj9Mu48g6S6P4wahJDwziqDkFZ0i5cc=@pm.me>
In-Reply-To: <E84CD5EE-DAAF-44D6-BCEE-CB92AE6CBBEC@andrewg.com>
References: <26f46aef-dde6-4564-92b2-2914aa574944@mtg.de> <E84CD5EE-DAAF-44D6-BCEE-CB92AE6CBBEC@andrewg.com>
Feedback-ID: 5683226:user:proton
X-Pm-Message-ID: dcb57b3f8079c00060764860fbf032c79ec664ee
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------bee8b11327ca7f790afb4abb6922c92d518054d325e50d14ee8824bed005c76d"; charset="utf-8"
Message-ID-Hash: FDXOCKZA5FRFF2VONT6RPCT2XVOJ6JA4
X-Message-ID-Hash: FDXOCKZA5FRFF2VONT6RPCT2XVOJ6JA4
X-MailFrom: bart+ietf@pm.me
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
CC: Falko Strenzke <falko.strenzke@mtg.de>, Justus Winter <justus@sequoia-pgp.org>, "openpgp\\@ietf.org" <openpgp@ietf.org>
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/P9DLV82IaHYKvQ0eG4XRLwHHAn8>
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 Andrew and Falko,
I think “use existing implementation behavior” would be better for cases where no suitable subkeys with ESS are found. Assigning zero would seemingly mandate that if the subkeys with nonzero ESS were found to be unusable every other subkey that was usable would have to be used together, which is in general different than current implementation behavior and is an odd side effect.  -Bart
On Mon, Apr 7, 2025 at 9:36 AM, Andrew Gallagher &lt;andrewg=40andrewg.com@dmarc.ietf.org&gt; wrote:  Hi, Falko.



On 7 Apr 2025, at 07:50, Falko Strenzke &lt;falko.strenzke@mtg.de&gt; wrote:

&gt;

&gt; 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".



This would be reasonable. Another option would be to treat such encryption subkeys as “do not automatically select”. This might seem to render the subkey unusable, but some clients allow the user to manually override the default subkey selection algorithm, in which case it could still be used. It’s worth noting that gnupg appears to now interpret the “reserved for adsk” key flag this way.



A

_______________________________________________

openpgp mailing list -- openpgp@ietf.org

To unsubscribe send an email to openpgp-leave@ietf.org

v2.30.2 | Report a Bug | By Email | System Status