Re: [openpgp] To bind or not to bind

Kai Engert <KaiE@kuix.de> Fri, 22 March 2024 11:50 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 D2F8FC1516E9 for <openpgp@ietfa.amsl.com>; Fri, 22 Mar 2024 04:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 O3PsQn2O4wjx for <openpgp@ietfa.amsl.com>; Fri, 22 Mar 2024 04:50:09 -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 1E29EC151998 for <openpgp@ietf.org>; Fri, 22 Mar 2024 04:50:08 -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 7E848194469; Fri, 22 Mar 2024 11:50:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1711108205; bh=rgz99oNQEBCxWd5M5wT0nxHf9ZFWWjLPcag6EpdqjI8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Y1UK/3NFb74ZTikahagBcIFZmR3ugKpVnf1pkRaWWSIle7yPEkaZOVyPbb5ljKfSs L8A1Fme6dUFWFHf5aU8dSQh/6UGaBpUuCb8q7xB+UuHdV6tkvTPIr0+LmjhekCV1Ii 7T4NKVchPSy3ZkxBJbW2LHwziTLqkISnY0rv+ymaqMr6CRYLNMbrZtYjvufKtc5UjB em01qqPpaak0tUjEZSC/oB+lpBPw//agwotyIl66o0ZemmKkg9fZmCYCBqYplBLFqv bsUPxzn35OhbwcRSb8gcFZZinj9qarQz23Ne2eEpAF8WRra397uLxBAql/jX/zmRGG uLzIICvF+5bkw==
Message-ID: <8d5636f9-9cbb-433d-b6e2-cac85d929919@kuix.de>
Date: Fri, 22 Mar 2024 12:50:05 +0100
MIME-Version: 1.0
User-Agent: Thunderbird Daily
Content-Language: en-US
To: Aron Wussler <aron@wussler.it>, "openpgp@ietf.org" <openpgp@ietf.org>
References: <EGivTgyfjNm_TAvhds1OPA2c0O6LP9lFnkwWHHKLJY8ReJOgtDh3tnYsCSR8yrrBLbpeehtUgIJEhynae8L3daRimNiGO7BAb3cVvC66q-4=@wussler.it>
From: Kai Engert <KaiE@kuix.de>
In-Reply-To: <EGivTgyfjNm_TAvhds1OPA2c0O6LP9lFnkwWHHKLJY8ReJOgtDh3tnYsCSR8yrrBLbpeehtUgIJEhynae8L3daRimNiGO7BAb3cVvC66q-4=@wussler.it>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/kxbItPeFQQabATlo7Zlfgmf1dPo>
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 11:50:14 -0000

On 21.03.24 21:26, Aron Wussler wrote:
>   - (1) may be justified because some implementations fail parsing keys [1]. Of this plot is particularly relevant the 3rd line (Unknown algo, opaque encoding, small), that would be equivalent to attach an ML-KEM + X25519 subkey to an existing v4 certificate. All V6 implementations are required not to choke on unknown algorithms.

What kind of failures can be seen with those implementations?

Will they allow importing it, but then run into a failure later on when 
trying to use it? That would be an argument for not distributing such 
keys at all.

Or will ALL of them detect the incompatibilityat import time, and refuse 
the import? That would be less problematic. Then probably v4-pqc and v6 
keys would be rejected in the same way.

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.

Kai