Re: [openpgp] To bind or not to bind

Andrew Gallagher <andrewg@andrewg.com> Fri, 22 March 2024 18:51 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 D88D9C17C882 for <openpgp@ietfa.amsl.com>; Fri, 22 Mar 2024 11:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, 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=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 kvBt8I1Ixhsc for <openpgp@ietfa.amsl.com>; Fri, 22 Mar 2024 11:51:48 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [IPv6:2a01:4f9:c011:23ad::1]) (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 2F10AC1519B7 for <openpgp@ietf.org>; Fri, 22 Mar 2024 11:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1711133503; bh=BRCFMENwmfO3XyXb1AF1vyTLfvpUMxamDpqJEooifBc=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=uWQDIuqvwXoGX0qXb7DV9Mmxw2++Yqu6AS+CyGsVNgTIRSz2Ij5dN/5XdWRLQJdCg hDCbdXBfz8fO7frVH1J0LA3bHAiVfbn1G9ZVTwpM120g1JHgZXZiEA1aS+c6jhi8Ev MOgk7B6ubt4r1BpbyahmaA3eQz7ZEFktFbt2af9dmqF68geE+Hz/K7s03R/yRsMl2M DA1VX8M8szz/84qPfSPn2uHc9mUw5vF/AVuOUSkXo/vv9Kr48W64szcexL0ftAp+tt OTxIhRDSyl9Rdct8S+kl6mYCLtwmmIwxSopx7JqzPQ3h6Tkpnmknyv849CkYDYq2V9 m+jIrYfXcDVzg==
Received: from smtpclient.apple (unknown [176.61.115.103]) (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) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id 342695DE45; Fri, 22 Mar 2024 18:51:43 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Andrew Gallagher <andrewg@andrewg.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 22 Mar 2024 18:51:30 +0000
Message-Id: <23B46D65-EAF7-43D0-A5F1-04D28B698559@andrewg.com>
References: <87a5mqi0xi.fsf@europ.lan>
Cc: Aron Wussler <aron@wussler.it>, openpgp@ietf.org
In-Reply-To: <87a5mqi0xi.fsf@europ.lan>
To: Justus Winter <justus@sequoia-pgp.org>
X-Mailer: iPhone Mail (21D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/7SzqOLcAaj3K_RhB42vNJVlYMxY>
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 18:51:52 -0000

Hi, Justus. 

On 22 Mar 2024, at 18:20, Justus Winter <justus@sequoia-pgp.org> wrote:
> 
> - v4 OpenPGP implementations are not robust enough to handle unknown
>  subkeys.  Adding PQC encryption subkeys to v4 certificates is not a
>  viable opportunistic upgrade path, but a way to make your existing
>  certificate unusable:
> 
>  https://tests.sequoia-pgp.org/#Mock_PQ_subkey

Is it possible to update this test with the optional flag that Falko mentioned, to see if it improves RNP’s score on line 3? If it does, I’d argue that this is no longer fatal - gopenpgp v2 has been superseded already, and pgpy is fairly niche.

There is still a potential issue with large subkeys, so maybe we could test to see where the size limit actually is for each if the implementations that fails line 4? We may still need to RECOMMEND that only “small” PQC encryption keys should be used with v4; but for the purposes of early adoption, one algo may be enough.

A