IETF Logo Mail Archive

[openpgp] Re: Encryption subkey selection

Andrew Gallagher <andrewg@andrewg.com> Thu, 10 April 2025 07:39 UTC

Return-Path: <andrewg@andrewg.com>
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 9B2711A07F89 for <openpgp@mail2.ietf.org>; Thu, 10 Apr 2025 00:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com
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 hny7oz7OTsYm for <openpgp@mail2.ietf.org>; Thu, 10 Apr 2025 00:39:50 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [IPv6:2a01:4f9:c011:23ad::1]) (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 6DDB51A07D29 for <openpgp@ietf.org>; Thu, 10 Apr 2025 00:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1744270764; bh=c82df8u6ca+RM/VTZqDvMThVomqGZ9bsTkg2dpO07Yk=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=pKyVS0Pm7026y845DC+qBCzPfZDWyDl403KTqwjRMTLLmBLvpY9/f5o68ioL/tcaf m9eSH+rq2xcdK42ADfwZ54KPm6azWMg//SZgb8PWISmwo58+458Nau7c2Vfh5Ku8ft i6g2U2+nTa6Ka7sb3EPssn5xPMBSMcckWvf4KdQh/bBucBabh8ZL+wjA4I/NqEBxXr z405LexcAkPJKWNGjBTCufdQXQsbIRMqKq3+e/Sk5hKbGfAuwxZ1xMlNnWzzAhjbEV tEnu/MWMcp23EYLlrRgExzUu6GtNDui79awMhRnEtXzzBTrwb/Lv7ARA0IMpyXysyX nHdqBbIcgBaaA==
Received: from smtpclient.apple (unknown [176.61.115.103]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id 243DE5EDF7; Thu, 10 Apr 2025 07:39:24 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Andrew Gallagher <andrewg@andrewg.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 10 Apr 2025 08:39:12 +0100
Message-Id: <625C7FAF-91F8-4864-8C44-4F4BC738A1FC@andrewg.com>
References: <4460b180-8b55-4a5b-b631-657a1e8d8ed6@mtg.de>
In-Reply-To: <4460b180-8b55-4a5b-b631-657a1e8d8ed6@mtg.de>
To: Falko Strenzke <falko.strenzke@mtg.de>
X-Mailer: iPhone Mail (22D82)
Message-ID-Hash: 7AG34VW524FXM4IERKX5FK56IKCZW5PF
X-Message-ID-Hash: 7AG34VW524FXM4IERKX5FK56IKCZW5PF
X-MailFrom: andrewg@andrewg.com
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: Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org>, Justus Winter <justus@sequoia-pgp.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/jY9HbUwRc8w_lVykFba1qtWtiDw>
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>

On 10 Apr 2025, at 08:28, Falko Strenzke <falko.strenzke@mtg.de> wrote:
> 
> In general I think it will be better to specs for the mechanism for encryption subkey selection per certificate and the replacement key mechanism separate. The reason is that if they are linked to closely, it will be unclear what an implementation does when it supports one but not the other.

Right now, the key replacement draft specifically says that when selecting encryption subkeys, the subkeys of the preferred certificate are considered first, then the first original, and so on. If this conflicts with what we want to do here, it would be best to sync the language before replacementkey goes to wglc…

A

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