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

Simon Josefsson <simon@josefsson.org> Mon, 08 April 2024 09:42 UTC

Return-Path: <simon@josefsson.org>
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 03A36C14F71E; Mon, 8 Apr 2024 02:42:25 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="CfL3ecil"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="TmvLFAeu"
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 GpjLzYK0t032; Mon, 8 Apr 2024 02:42:19 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956F2C14F695; Mon, 8 Apr 2024 02:42:17 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=WWQnpCpKsYdCR6kyOCIsv7STNAHRtS8m3G4TTjSAPZI=; t=1712569325; x=1713778925; b=CfL3ecilTorSdGnBDEC5+5tRDWiiDp9jRhoznA1/IyoX6Mef5w0DJQYUqZP0SvAjWDVquTKV+kS Wrjv1JJ3LCw==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WWQnpCpKsYdCR6kyOCIsv7STNAHRtS8m3G4TTjSAPZI=; t=1712569325; x=1713778925; b=TmvLFAeud1wT9v3FiaxDqidkIeBh9wirN+qJs1yMEVvHW8Jz6BvU/j0giFXjQiyCN+SSs/67L8/ +T0hwtofR2P3WcEldxplxVuGR7x3zP2j8wQAkE39jyd+KlSuCe+rznKAkGrX5xdqlEq3FYhXx968C xerbcUlvhhtqmY1ipye6HG1tlT8pyqbdy3arLrKW0gggblViuIyemUoMQLlHG7nMHwWIK78BcRFfz +YtZ354ZsE7JKyr1OFWOQOWLQlsPJOVevrkPsppt/6G8k4lp4kpSJ6etK/DMICIhjZttYSENGrohk r/Gyg1W9TZJYeaC3vygqnOr5SHnbKqD8CtTTZ4XIN3PisMR29J9sWNjNL9G7PNoSfPIGGVOgBVXdK Eq2tlpcQDENPWVv2s3tr7VPpuq5cWtbcbHrzXghGZp4BbWG4u7Lad1rSZr1grQlMaANancu7R;
Received: from [2001:9b1:41ac:ff00:823f:5dff:fe09:16ac] (port=39396 helo=kaka) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1rtlVp-00C86C-8f; Mon, 08 Apr 2024 09:42:01 +0000
From: Simon Josefsson <simon@josefsson.org>
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, IETF OpenPGP WG <openpgp@ietf.org>
References: <87ttkdr5e0.fsf@kaka.sjd.se> <F0D472E0-0B37-416A-9587-F64FF646B0E1@andrewg.com> <87plv1r2sf.fsf@kaka.sjd.se> <874jcdi0em.fsf@fifthhorseman.net> <87edbhqdof.fsf@kaka.sjd.se> <00E3FD5F-F5DE-4B85-A34D-E3E12EFD5DB7@andrewg.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:23:240408:openpgp@ietf.org::uVOAXHYPvZ7rnhm5:WvSY
X-Hashcash: 1:23:240408:simon=40josefsson.org@dmarc.ietf.org::yUDKrjJVXAExchtJ:nMxs
X-Hashcash: 1:23:240408:andrewg=40andrewg.com@dmarc.ietf.org::vnM5gcaefyj4fehW:0pcla
X-Hashcash: 1:23:240408:dkg@fifthhorseman.net::VBxt1kZJ+hFWeQ54:0Dhiv
Date: Mon, 08 Apr 2024 11:41:18 +0200
In-Reply-To: <00E3FD5F-F5DE-4B85-A34D-E3E12EFD5DB7@andrewg.com> (Andrew Gallagher's message of "Sun, 7 Apr 2024 20:15:10 +0100")
Message-ID: <87a5m4qji9.fsf@kaka.sjd.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/SB0dAjdz1_cUCiLRNL0xmFZWjZc>
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: Mon, 08 Apr 2024 09:42:25 -0000

Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org> writes:

> On 7 Apr 2024, at 18:34, Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org> wrote:
>> 
>> Is this intended to replace or augment human-written key transition statements?
>
> Yes.
>
>> Doing so would be useful, and
>> quite important to ease key roll-over to PQC keys, but transition
>> statements are usually not published when keys are expired or revoked.
>
> Indeed, this subpacket gives a key owner the means to make such a
> transition statement in machine-readable form, and distribute it
> through the customary key update mechanisms.

That seems useful, and I think it would be useful to address that
problem, however key transition is a complex problem as it interacts
with trust settings which PGP historically largely have left outside of
scope for the protocol.  This reinforce my feeling that there is a gap
between the current state of the draft and whatever the goals may be,
and that the effort would be helped by taking a step back and describing
the goals more clearly first.  I do think it is wortwhile to explore,
and will try to help by participating in discussions.

One aspect is that a machine readable form is only useful if machines
can make useful decisions based on the data.  Is that the case?  There
are security concerns with automated key transition mechanisms.
Consider if someone manages to get me to sign a replacementkey binding
to a new vulnerable RSA1024 key, how to revoke that statement?  How to
evaluate it on the recieving side?

/Simon