IETF Logo Mail Archive

Re: [openpgp] v5 interoperability

Andrew Gallagher <andrewg@andrewg.com> Sun, 14 April 2024 09:57 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 D1C35C14F69E for <openpgp@ietfa.amsl.com>; Sun, 14 Apr 2024 02:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=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 uBO7JrJMO8hs for <openpgp@ietfa.amsl.com>; Sun, 14 Apr 2024 02:57:30 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (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 96F4BC14F60D for <openpgp@ietf.org>; Sun, 14 Apr 2024 02:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1713088647; bh=qGsvYWrWq41WtyeAyQWVTGBzYXsiPZcTVkB1+fkJqD4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=o+epkt0Y/38hGWY6HazUts48BTpNZthDs/a3No5g9HplfZXa08J4sCPzNlyZyaQuB Yj5z9gMsn79PJen3QYjb2NVYNi36RZiPGw7f78aKjnhcmMxRdxMOCoUg2tzToWC5ha 4+1wpFed2Q7QNV1LhBS+/8kqTE74AvevGnZxxFXA/MCmej+HEIprkbxoMpBZvjEEnM JsliHrCkbf4QRBugfxcMBDUyI/PPJwYkCvZ79T/dqQ2P2Iy6AnGVJhvpW3MCWm5q0c /jB9003vL8ptS2KlLq3yp4wytRaHRpMI7J6OJO9AnN9X2gYGJBm0oV4kz240VElA6J HuruQYSgf6X0A==
Received: from smtpclient.apple (serenity [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id 95C0A5DCA6; Sun, 14 Apr 2024 09:57:27 +0000 (UTC)
Content-Type: multipart/signed; boundary="Apple-Mail=_82A651C7-4C97-40B1-928A-84847EF1B87A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Andrew Gallagher <andrewg@andrewg.com>
In-Reply-To: <325d0a3c-9a89-4158-9719-473a7e21ade1@kuix.de>
Date: Sun, 14 Apr 2024 10:57:15 +0100
Cc: IETF OpenPGP WG <openpgp@ietf.org>
Message-Id: <384DAE55-1099-4913-9C6A-8E808400A81E@andrewg.com>
References: <EAE8D81F-05F6-4551-8878-80555709A4EF@andrewg.com> <325d0a3c-9a89-4158-9719-473a7e21ade1@kuix.de>
To: Kai Engert <KaiE@kuix.de>, Werner Koch <wk@gnupg.org>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/n8T7TjLNyyCQin6-3X-WzICc6B8>
Subject: Re: [openpgp] v5 interoperability
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, 14 Apr 2024 09:57:34 -0000

On 12 Apr 2024, at 18:21, Kai Engert <KaiE@kuix.de> wrote:
> 
> On 02.04.24 20:50, Andrew Gallagher wrote:
>> It came to my attention recently that recent versions of GnuPG are (under certain conditions) creating v5 subkeys and binding them to v4 keys. The use of mismatched subkey versions was not explicitly forbidden by rfc4880, but is forbidden in crypto-refresh.
>> So what is the proper way to treat such keys? They exist in the wild already, so cannot be ignored.
> 
> Wait, if this is actually a reality, could this be a way to achieve interoperability?
> 
> Create a v4 signature key.
> Bind a v5 encryption key.
> Bind a v6 signature key.
> Bind a v6 encryption key.
> 
> Amend crypto-refresh to allow that.
> 
> Email clients could generate this mixed key for maximum interoperability.
> 
> Crypto-Refresh implementations use the v6 subkeys for messages, and ignore the v5 subkey.
> 
> LibrePGP implementations could use v4 + v5 and will have to ignore the unknown v6 subkeys.

IMO the only compelling reason to add a v6 subkey to a v4 primary (leaving aside v5 for now) is that it would allow a PQC signing subkey to be used with a v4 key (we’re already considering allowing v4 PQC *encryption* subkeys). But in order to make a quantum-safe signature, the entire trust chain must be quantum-safe, including the primary. If we’re not going to upgrade the entire trust chain to v6 and/or PQC, I don’t see any great advantage in doing it piecemeal.

Werner, do you plan to allow v4 PQC keys in librepgp? Both encryption and/or signing? Or do you see PQC as a v5-only thing, like X448?

A

v2.23.0 | Report a Bug | By Email