IETF Logo Mail Archive

Re: [openpgp] v5 interoperability

Andrew Gallagher <andrewg@andrewg.com> Tue, 16 April 2024 13:25 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 602FCC14F5F9 for <openpgp@ietfa.amsl.com>; Tue, 16 Apr 2024 06:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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 n6yPWs199um5 for <openpgp@ietfa.amsl.com>; Tue, 16 Apr 2024 06:25:27 -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 1F2A0C14F5E4 for <openpgp@ietf.org>; Tue, 16 Apr 2024 06:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1713273923; bh=P1ayCXjXTwWrnpnF5HNa9Xq/9Vr7H5ZZCvXTClE5F/o=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=RyWclrYPntgHsk5Xa3xKCmMwVeWYppILzmmPP22L8noSeN7IOVFk0ALzwgleQKOvY ud8oevIXmZ237mNu73lDB6m1TlLTn0IrojwUPsYivGP3BgkUOYXD+ysGJOSniUtaQJ Yw86uX6Ltbj9CASuGTAZFzFZ667hC2ZIWpu/N1d9zuGDqacYkfBgW5l4qG5vqcNWco PkzictA6q/NQ1phUbGqp7OKnnLQe/aJ2GW780GWsr/tYsK2cRS4OV0bo04cJEwKJo/ 6HX4KrurNDRJ7Xp1ejNBFKLRnhYpMzEWZ9i1O+cMnE0RxtdX/V7VE/I3Xv6PmlEJQb pXbfQoCdArkEA==
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 83BF05DE70; Tue, 16 Apr 2024 13:25:23 +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: Tue, 16 Apr 2024 14:25:11 +0100
Message-Id: <35495467-EB54-4610-B4E0-5421AC41BB12@andrewg.com>
References: <875xwhlboi.fsf@jacob.g10code.de>
Cc: Kai Engert <kaie@kuix.de>, IETF OpenPGP WG <openpgp@ietf.org>
In-Reply-To: <875xwhlboi.fsf@jacob.g10code.de>
To: Werner Koch <wk@gnupg.org>
X-Mailer: iPhone Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/yez5ZccLezBQ6OKIYRsPc3JbA0o>
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: Tue, 16 Apr 2024 13:25:32 -0000

On 16 Apr 2024, at 13:46, Werner Koch <wk@gnupg.org> wrote:
> 
> On Tue, 16 Apr 2024 08:50, Andrew Gallagher said:
> 
>> In the current draft of openpgp-pqc, it looks like only the algid is required
>> in the fixedinfo:
> 
> That is correct.  However, this was done because all parameters of the
> algos are identified by the algoid.  We don't do this as explained in my
> mail
> 
>  https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000043.html
> 
> and thus we need to identify the Kyber version and the curve which can
> easily be done using the fingerprint.

This is only necessary because of the differences in code point allocation strategy between this unpublished spec and the BSI PQC draft. Once again I question whether tinkering with code points is worth the knock-on effects, in particular the duplication of specification and implementation. Are we not all safer in principle with a single PQC spec that has twice as many critical eyes on it?

> I'll post an updated specs in a few days.

Thanks, I look forward to it.

A

v2.23.0 | Report a Bug | By Email