Re: [openpgp] To bind or not to bind

Kai Engert <KaiE@kuix.de> Fri, 22 March 2024 21: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 E651CC151551 for <openpgp@ietfa.amsl.com>; Fri, 22 Mar 2024 14:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 T9NWdRdgBo7t for <openpgp@ietfa.amsl.com>; Fri, 22 Mar 2024 14:21:31 -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 EF1DDC151099 for <openpgp@ietf.org>; Fri, 22 Mar 2024 14:21:30 -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 E54AE1944F0; Fri, 22 Mar 2024 21:21:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1711142488; bh=U8vDW3uPOWIG2Yh97L1EGceQtiaqRBnFnz63H+ZApJ8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SE8GDRixxt9IJcEvL9d+Wbjbj+IolugToFVizWTfuLHU+592xL82zULofLUmR/kzC MghltnVgE1whF9KepNM23ebC2szt6lkJpQo2fIMOfz5y53UwfFPsRSnd3ztdYylhCX jMeteo4OdYiIy/vplWVOTP6+D9dfekTF0GhMT7Rc1uOlth5Msktq4l1fgxNj/6vYHI SPQr2EL8P5UGrHp7ERMlk/I6cOE7isQNKBqbjzrnE4SzMp41VPiqNRENcKgAOe0WgE XUoo4HDjnxf2BmtlSe+0jIRaqCsukE1zLSOLJyWnbGLsdyb3thEWYEW1t4GxqueAhE gpUQbP0xtIIDw==
Message-ID: <cb6dfd95-bd48-4392-854a-ab8219f3108b@kuix.de>
Date: Fri, 22 Mar 2024 22:21:28 +0100
MIME-Version: 1.0
User-Agent: Thunderbird Daily
Content-Language: en-US
To: Justus Winter <justus@sequoia-pgp.org>
Cc: Aron Wussler <aron@wussler.it>, "openpgp@ietf.org" <openpgp@ietf.org>
References: <EGivTgyfjNm_TAvhds1OPA2c0O6LP9lFnkwWHHKLJY8ReJOgtDh3tnYsCSR8yrrBLbpeehtUgIJEhynae8L3daRimNiGO7BAb3cVvC66q-4=@wussler.it> <8d5636f9-9cbb-433d-b6e2-cac85d929919@kuix.de> <87edc2i1k2.fsf@europ.lan>
From: Kai Engert <KaiE@kuix.de>
In-Reply-To: <87edc2i1k2.fsf@europ.lan>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/YhFydF6-VrzuURTRsRxrvcjuJMU>
Subject: Re: [openpgp] To bind or not to bind
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, 22 Mar 2024 21:21:35 -0000

On 22.03.24 19:06, Justus Winter wrote:
>> Users of both v4-pqc and v6 keys would equally have the problem that
>> they need to provide classic v4 keys for their incompatible correspondents.
>>
>> However, if v4-pqc is allowed, it might allow some implementations to
>> become compatible with pqc more easily.
> 
> That seems to be optimistic speculation, whereas the data says that such
> a cert is not a viable opportunistic upgrade path.

We don't have data on what today's intolerant implementations would do 
when their users were commonly faced with users complaining about 
nonworking keys.

Given that we don't have that data, all we can do is speculate.

I don't know whether today's intolerant implementations will fix the 
intolerance bug when users complain that they cannot use their 
correspondent's keys.

But implementing such a compatibility fix can probably be done much more 
easily and quickly by implementations than adding support for v6 keys.

If we start with v4-pqc keys, it might push implementations to improve 
their treatment of unsupported keys in general, and check which keys 
they can support easily.

And they probably can add support for v4-pqc keys, at least in a 
non-breaking tolerant way, much more easily.

Kai