Re: [openpgp] Possible to define a common key format for LibrePGP and OpenPGP-IETF?

Andrew Gallagher <> Fri, 15 December 2023 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9276C14F74E for <>; Fri, 15 Dec 2023 04:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
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, HTML_MESSAGE=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gtyLIbt6xgnE for <>; Fri, 15 Dec 2023 04:41:28 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 7D263C14F5E8 for <>; Fri, 15 Dec 2023 04:41:27 -0800 (PST)
Received: from (serenity [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1E9FF5ED7E; Fri, 15 Dec 2023 12:41:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=andrewg-com; t=1702644084; bh=NuuS6yPTugY1Zw73blKNLP1pISMPsw8vBXSE8DtwFUw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=iHe6pQHQINxzbQzlgSg6UQFYnt1GpybCVzxt00lh/l4+G6L2e9ihhgpUDeOaRlIP7 +CHFjXxkEVfb3dZHClSWr6IQ8wquayTwluZOIaMYLRfkx6B6FfcGTE8OLblu7djk4c A50JQchZquckMUkoiY7uPCFz2mbE6Yzr6KT2//aQR6loAZXXWZVp7RqBvVomaHF6i/ AqZ+bbpLuBhlTbfo/OwSaAUmVyGcL6bF3/95e2Cv9YCHa/AZeZrtjOaOBGZmsmZ3Bn oo9zeIKjUt0+Ie+9L9prl0mBR3HqqHxWVM1E4qVxlckftLI5aemkLMJ25Do4xAnaWp Xuts+uW9dRtOQ==
From: Andrew Gallagher <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_ADFC1620-A352-4005-8519-73496D2312CC"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Fri, 15 Dec 2023 12:41:07 +0000
In-Reply-To: <>
Cc: Justus Winter <>, Werner Koch <>
To: Kai Engert <>, "" <>
References: <> <87v88zbtub.fsf@europ.lan> <>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <>
Subject: Re: [openpgp] Possible to define a common key format for LibrePGP and OpenPGP-IETF?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Dec 2023 12:41:33 -0000

On 15 Dec 2023, at 12:20, Kai Engert <> wrote:
> However, if a common key format is possible, then I would like to suggest that both sides take a step back to think about this idea.
> If both sides, LibrePGP and crypto-refresh, actively agreed to specify a common key format, that allows both sides to implement applications according to the divergent PGP specifications, then I think it would be a huge win for the ecosystem and users. The common keyformat would avoid the complexity of having to handle multiple keys in parallel - for those users who wish to have interoperability with all implementations.

Hi, Kai.

AIUI, the key format and the signature format are tightly linked (a v6 key MUST only create v6 sigs, etc). This effectively means that to have a common key format we would need to agree a common signature format. Message formats such as SEIPDv2 are less tightly bound to the key format, and we should in principle be able to manage them through existing preference mechanisms.

The two main points of difference between the signature formats are the random seed and the metadata hash. I don’t believe these are insuperable, but it would require some choreography to reconcile them without reopening the draft.

So I am cautiously hopeful that what you suggest is technically possible, perhaps via a “first amendment” type document that we could potentially have a draft of before the RFC is officially published? This could perhaps describe optional extensions that would bridge the gap between the functionality of the two signature formats.