[openpgp] Multi-algo pubkey, or how to create future-proof keys

Ángel <angel@16bits.net> Mon, 21 June 2021 01:16 UTC

Return-Path: <angel@16bits.net>
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 D9C4C3A1B17 for <openpgp@ietfa.amsl.com>; Sun, 20 Jun 2021 18:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDuWcQnnX0gY for <openpgp@ietfa.amsl.com>; Sun, 20 Jun 2021 18:16:48 -0700 (PDT)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF453A1B15 for <openpgp@ietf.org>; Sun, 20 Jun 2021 18:16:48 -0700 (PDT)
Message-ID: <cbf99ad67b5de1b7c4e0051e76b3b8d73f5192ff.camel@16bits.net>
From: =?ISO-8859-1?Q?=C1ngel?= <angel@16bits.net>
To: openpgp@ietf.org
Date: Mon, 21 Jun 2021 03:16:42 +0200
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/e4CvQzRCUhwD8Fc_aOavIJxA6Rc>
Subject: [openpgp] Multi-algo pubkey, or how to create future-proof keys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 21 Jun 2021 01:16:51 -0000

Hello all

I would like to bring up a point I had noticed some time ago, about
having multiple public keys combined. A few days ago, we have been
talking about v5 keys, potential Post-Quantum algorithms, etc.

In OpenPGP, when creating a new key one faces a first-mover
disadvantage. Since the openpgp key itself is identified by the primary
public key, only one public key algorithm can be used.
Then, when a new algorithm appears which is -hopefully- more secure,
choosing the new algorithm means that the key cannot be used by people
with old clients (in some cases, prehistoric ones). Whereas using an
old algorithm with better support leads to no incentive to implement
the new algorithm, or to use it.

This also means that if a critical vulnerability appears in an existing
algorithm (such as a Quantumcalypse), finally forcing the use of the
better algorithm, everyone will need to create new keys and the WOT
will have to be re-created from scratch.

Note that subkeys don't help here, since if the master key is
newer/stronger than the subkey, the key won't be accepted by old
clients. And if you use a subkey stronger than the main key, an
attacker could just add a new subkey under their control.


The solution I foresee is to spec a way to have a key with *multiple*
public keys. When signing, the signer MUST provide signatures with all
of them. When verifying, unsupported algorithms SHOULD be ignored, as
long as one of them is known and least verifies correctly, it's
considered valid. Note that if a client sees a valid signature with
algo A and an invalid signature with algo B, it MUST be rejected.
Skipping is only for the cases when the algorithm is unknown /
disabled, not for ignoring invalid signatures.

I initially considered this would need to be included natively in v5,
but it can be implemented as a special pubkey algorithm (e.g. 255)
defined as a concatenation of two or more public-key packets (using
algorithms other than 255) and whose signature is a concatenation of as
many signature packets as present in the key definition.

This is just a high-level description, it obviously needs to be
formalized, but hopefully it conveys the idea.


Regarding scope, it seems suitable to include into the cryptography
revision and, although not strictly required, being included with a
major version would probably be helpful.


Does anyone have any comment about including this?
(either about the general idea or using that special "pubkey")


Best regards

Ángel