Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms

Daniel Huigens <> Fri, 04 June 2021 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 860CB3A1DFA for <>; Fri, 4 Jun 2021 12:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TES_Tcwyg_EH for <>; Fri, 4 Jun 2021 12:27:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7E7B3A1DFB for <>; Fri, 4 Jun 2021 12:27:20 -0700 (PDT)
Date: Fri, 04 Jun 2021 19:27:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail; t=1622834837; bh=Pl/GK8Ov31rTRCqw5mqryuhIkbc1sc4J+xd1Fg9SaXU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=OtA7vw9lWVFXLkZaz4ew4l2adoRS/nHqW/WUGTKMh7/icUxZIEFhZ//AE4ox7kwMc VFvyJ1tIiBjNS/1+t0wDAGFFv3bcnEDOw4q4yBMhsUlOOHqMToMpm8ZaVgdH3TdCmT Y0yNyk10koTtFTX1PNAAa7agpuGcsjm+Q+bOpiJ4=
To: Daniel Kahn Gillmor <>
From: Daniel Huigens <>
Cc: IETF OpenPGP WG <>
Reply-To: Daniel Huigens <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jun 2021 19:27:28 -0000

I'll be a bit contrarian here and say that, while I'm of course fine
with binding the wire format to the public key algorithm, I'd prefer not
to bind the wire format to the curve. Especially when it comes to
Curve25519 and Curve448, they are specified together so often (see
RFC7748, RFC8032, RFC8422, RFC8031, etc) that to me it seems strange to
specify them in a different way in OpenPGP, especially given that this
crypto-refresh will officially be the first place for both curves to
appear. Of course, Curve25519 has been around in implementations for
much longer, but still, from the perspective of the spec it seems

(Probably I should've brought up this concern sooner, when SOS was being
discussed etc, but this patch made me realize the above.)

For what it's worth, I fully agree that the current situation with
Curve25519 is non-ideal and confusing, and that a simple byte string
would be better. However, we'll likely be stuck with it forever, and I'm
not sure if specifying a different wire format for Curve448 makes things
any simpler.

That being said, I don't think anything in this patch so far is really
"incorrect", and if everyone else feels that it makes things clearer,
(and, thanks dkg, indeed, for trying to make things clearer!) I'm OK
with specifying things that way, just perhaps with the exception of the
language saying that future algorithms should use a different encoding
(even though I do agree with that as written, but it seems like a note
for the future editors, not a note for current implementers.)

Once we do specify a new public key algorithm (e.g. post-quantum), as
opposed to just a new curve (my expectation is that adding post-quantum
algorithms will be the next "crypto refresh", and that we will never
need a new curve after Curve448), I fully agree that we definitely
shouldn't do this byte-string-in-MPI thing again. When we do so, we
could specify a new octet string type, or something else. But I'm not
sure that between Curve25519 and Curve448 is the correct place to "draw
the line in the sand".