Re: [openpgp] v5 in the crypto-refresh draft

Daniel Huigens <d.huigens@protonmail.com> Fri, 04 June 2021 17:12 UTC

Return-Path: <d.huigens@protonmail.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 8508D3A19A3 for <openpgp@ietfa.amsl.com>; Fri, 4 Jun 2021 10:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
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 32rDRHtwbAW0 for <openpgp@ietfa.amsl.com>; Fri, 4 Jun 2021 10:12:12 -0700 (PDT)
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (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 6B7C43A199C for <openpgp@ietf.org>; Fri, 4 Jun 2021 10:12:12 -0700 (PDT)
Date: Fri, 04 Jun 2021 17:12:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1622826729; bh=9Z0L4cReCmtW/S5IHBVtTK6//s3dsccy5YBAsckkK5k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=FnX/X/XFUwRWwtl6YT1UWSqT5qLLj3qy8QWMvjJvgjEzTb9/7qS+B+mu9ouVzIYWk uddgbg/qnhBDZI3/4kqWvht9tzH40I0ebQvEZf1Gq1XzNbXNmdeb3lmbYS4XGTZ9uu TFYnr8wZG1CTStwmLlgizra83FFHfuPeSAszWw3Q=
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: openpgp@ietf.org
Reply-To: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <CehzUzKNsBcldCQuRadnyAgV7hLQR1cve61qHfJYP-_cTKGeKTAMVo1GUdmbIL0AumFM9-XizsIiI8KAZvs44WILEG3FbHxM6aSTk7tSGzg=@protonmail.com>
In-Reply-To: <87lf7q6sh0.fsf@fifthhorseman.net>
References: <87lf7q6sh0.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/r9QNdb9SK9mU4k2tVOh4Rsk0ctc>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
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: Fri, 04 Jun 2021 17:12:18 -0000

Just as one data point, we (OpenPGP.js) have fully implemented v5 from
rfc4880bis, but always behind a flag with a stern warning that using it
may break compatibility in the future. So we are in principle fine with
doing so and changing the meaning of v5, indeed.

As an alternative option, if the only goal is to fix SHA1 fingerprints,
one thing that we have started doing internally at ProtonMail is giving
keys "SHA256 fingerprints", defined simply as calculating the
fingerprint but using SHA256 instead of SHA1. Obviously, for v5 keys
this is equivalent, but if we want, we could introduce this as a concept
for v4 keys in the crypto-refresh, and reserve v5 for a later spec.

We might then also want an "Issuer SHA256 Fingerprint" subpacket, and
allow it to be used for v4 keys as well. Similarly, we might want a
version 2 of the KDF parameters, indicating that SHA256 is to be used
for the fingerprint in the KDF. This would require modifying the public
key, somewhat diminishing the benefits, but at least the primary key
could remain the same. (I also don't think either of these are really
security-critical, compared to the main use case of identifying keys,
but I might be missing something.)

Obviously, there's then additional work to be done in the public APIs of
libraries, to expose SHA256 fingerprints, and making sure that people
(and applications) use that instead of the SHA1 fingerprint wherever
possible. Whether that is more or less work than transitioning from v4
to v5 keys, I'll leave up for debate :)

(If we want to give them a more user friendly name, we could call them
"long fingerprints", in contrast to "short key IDs" etc.)

Best,
Daniel