IETF Logo Mail Archive

Re: [openpgp] v5 interoperability

Kai Engert <KaiE@kuix.de> Fri, 12 April 2024 17:21 UTC

Return-Path: <KaiE@kuix.de>
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 AAB85C14F697 for <openpgp@ietfa.amsl.com>; Fri, 12 Apr 2024 10:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=kuix.de
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 99Ejb0AYQUmj for <openpgp@ietfa.amsl.com>; Fri, 12 Apr 2024 10:21:44 -0700 (PDT)
Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (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 B23CDC14F708 for <openpgp@ietf.org>; Fri, 12 Apr 2024 10:21:44 -0700 (PDT)
Received: from [IPV6:2003:c8:af2a:a300:2b6a:161a:5cd:1ba] (p200300c8af2aa3002b6a161a05cd01ba.dip0.t-ipconnect.de [IPv6:2003:c8:af2a:a300:2b6a:161a:5cd:1ba]) by cloud.kuix.de (Postfix) with ESMTPSA id 66DDB194F50; Fri, 12 Apr 2024 17:21:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1712942502; bh=QyK68HNaPMZ/SEgNRYAc+KGbfI/w2Z/M4O0VWOHlOwE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ARKXF2nHBTxF9r7Frei7Hlm0ssZmJvx1p7E69a6OH124nW5H7RENiPOfXn3xwpLp5 LmK1ys6ZGrC/TM9I91+vxBfo+T2Vkj+IsvV5/cjfNdY60Qc2vOTM1PMqNN+usajStS bW4t0Vn55azMWhH5k8Lv6ryACC8z/UV86FnFVl+LA4c1a2dCqtPHZHeBXuU7h3fkYT 83SNwqRtUfOTq8cQ/8/mppYJn1o1vdsoklGbZZUcKb78EdhAnxb1jEW7vCRT59nZ6Z tI/EURif71Bv5TUwRjf677CXSngxvXid1oNwrelUYGW2Wqa9ej58bwL3LaFpM1ZRdp SA0ZrZm/rU/9A==
Message-ID: <325d0a3c-9a89-4158-9719-473a7e21ade1@kuix.de>
Date: Fri, 12 Apr 2024 19:21:42 +0200
MIME-Version: 1.0
User-Agent: Thunderbird Daily
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>, IETF OpenPGP WG <openpgp@ietf.org>
References: <EAE8D81F-05F6-4551-8878-80555709A4EF@andrewg.com>
From: Kai Engert <KaiE@kuix.de>
Content-Language: en-US
In-Reply-To: <EAE8D81F-05F6-4551-8878-80555709A4EF@andrewg.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/r6Z8lG2ZkKG2da6ywcJnoB4X1iw>
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: Fri, 12 Apr 2024 17:21:48 -0000

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.

Thanks
Kai

v2.23.0 | Report a Bug | By Email