IETF Logo Mail Archive

Re: [openpgp] Call for adoption of draft-gallagher-openpgp-replacementkey

Andrew Gallagher <andrewg@andrewg.com> Sun, 07 April 2024 08:07 UTC

Return-Path: <andrewg@andrewg.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF388C14F6A2 for <openpgp@ietfa.amsl.com>; Sun, 7 Apr 2024 01:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aT9Nj23hlsg for <openpgp@ietfa.amsl.com>; Sun, 7 Apr 2024 01:07:33 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AADC14F6AC for <openpgp@ietf.org>; Sun, 7 Apr 2024 01:07:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1712477248; bh=uH+Qf/g4XR/A/IErwcK4aBnMOYtjPam3mXs/GxogujA=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=EmRrzionPFhqLzdpD1pYlDOSNoBLhQJI4LCMn9iOGTn/tmvTS+r1cMO8u4nCHCW7L UPe/Owc99LSPg4qYHMasnWaqpojx0ZGSvxBhXLj/seFZ/a7wPKqbJrkp0Kz2OW6Mqx ScjiALZoM5SnIlV24biJUaykR4si0GLS+fp3BPKvkxiYjxoxrmWzECaUfEeX66HW9H W54J+sLG77C2HMQpvv9kJXx8q1MpllZT0fjQeJH/rFdRZjQoU0NP52o7uSdxx/g3u8 6a6jTai+hIbEH5DpJUkpWXvJxaYoOcL4Zmk2WdGHDq4P1eaD4a5FXTOtNONPuGg5Pf u6A+jIMrbGIDg==
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 8EE8F5DE4F; Sun, 7 Apr 2024 08:07:28 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Andrew Gallagher <andrewg@andrewg.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 07 Apr 2024 09:07:17 +0100
Message-Id: <F0D472E0-0B37-416A-9587-F64FF646B0E1@andrewg.com>
References: <87ttkdr5e0.fsf@kaka.sjd.se>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, openpgp@ietf.org
In-Reply-To: <87ttkdr5e0.fsf@kaka.sjd.se>
To: Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org>
X-Mailer: iPhone Mail (21D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/K-uOI0Z8gfmlS3dCQdUpcRC6rDo>
Subject: Re: [openpgp] Call for adoption of draft-gallagher-openpgp-replacementkey
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2024 08:07:37 -0000

On 7 Apr 2024, at 08:37, Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org> wrote:
> 
> There seems to be a gap between the draft and the motivation above,
> regarding one crucial aspect: the draft does not suggest that any
> automatic processing of the new key should be done, but instead rather
> recommends against that, saying that the replacement key should be
> validated as any other key.  

There is no conflict here - trust calculations are generally performed automatically, as are key discovery and key selection. The draft merely says that the new subpacket conveys no *extra* trust to the new key that it would not otherwise have. It does not prevent automatic processing.

a) if a trusted key has a replacement key subpacket pointing to an unknown key, that key can be automatically obtained (by the usual means), and

b) if two trusted keys are available, and one has a replacement key subpacket pointing to the other, the second should be preferred

Neither of these require explicit user intervention.

A

v2.23.0 | Report a Bug | By Email