[openpgp] Re: v4+v6

Johannes Roth <johannes.roth@mtg.de> Mon, 10 February 2025 10:48 UTC

Return-Path: <johannes.roth@mtg.de>
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 05028C1D52E7; Mon, 10 Feb 2025 02:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=mtg.de
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 3HHevP0oZwDS; Mon, 10 Feb 2025 02:48:53 -0800 (PST)
Received: from www.mtg.de (www.mtg.de [IPv6:2a02:b98:8:2::2]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C870BC14F5E2; Mon, 10 Feb 2025 02:48:52 -0800 (PST)
Received: from minka.mtg.de (minka [IPv6:2a02:b98:8:1:0:0:0:9]) by www.mtg.de (8.18.1/8.18.1) with ESMTPS id 51AAmmcm011211 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Mon, 10 Feb 2025 11:48:48 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mtg.de; s=mail201801; t=1739184528; bh=T7P5fBEkV2unyANOOGwhglcUwThPFp0o1fGi84hqGZs=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=LWvUyMSk39VA5orvBhnLSOhWvg4Ply7+gJGgR1JXSakocIAWZKzwd1LQzD2BZlVC5 7bvQI72/PZcp1w4mo+j1TfWLLpUCFFeQ301eNyYgokoTClWHEGLCiN3IC3iWYy3DMP 04/wQw+2DNPQsWELLMNq2noya9g/WYvKOMytz/ny8qzkTERER/Cwj/6AKJPamcTHeg 9E4MJ54IkH4/BC25B9moeM9qfxXfLDS74rHLdje58TaU143Mgc4x0v0L1K9aMK+Wv8 2kEZCcrcXblQXc0hXfaAyEMF60Qhd0TbaxJze0RXwZ/e8ztqnnyQnSKS293wlDuBVh pAJ45uzWAeo/A==
Received: from [199.99.99.52] (abahachi [199.99.99.52]) by minka.mtg.de (8.18.1/8.18.1) with ESMTPS id 51AAmm8h019779 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Mon, 10 Feb 2025 11:48:48 +0100
Message-ID: <38472df3-5d8c-46fb-9b29-5d1fedfa19ef@mtg.de>
Date: Mon, 10 Feb 2025 11:48:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org>, "Neal H. Walfield" <neal@walfield.org>
References: <87h653fd5p.wl-neal@walfield.org> <2TILmXlRqQuH38CSPgkT_AH9aB3GlY1QD3Ij69k1EpvBHkdE4z7KAIG1JzQqPv6z48ePIbIbRaf0dkmo88c_7kOlIjhvB5b8W8-oYG2mg4o=@protonmail.com>
From: Johannes Roth <johannes.roth@mtg.de>
Organization: MTG AG
In-Reply-To: <2TILmXlRqQuH38CSPgkT_AH9aB3GlY1QD3Ij69k1EpvBHkdE4z7KAIG1JzQqPv6z48ePIbIbRaf0dkmo88c_7kOlIjhvB5b8W8-oYG2mg4o=@protonmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms090602050703030705010200"
Message-ID-Hash: MDGIYUCCE4ABDXQONEWOUMLFHTA27AJ7
X-Message-ID-Hash: MDGIYUCCE4ABDXQONEWOUMLFHTA27AJ7
X-MailFrom: johannes.roth@mtg.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF OpenPGP <openpgp@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Re: v4+v6
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rusDUHI2Sb09pKZhxkIYNfbrfLM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Hi all,

I support what Daniel says. I see the appeal for the simple 1-to-1 
mapping across OpenPGP versions. However, given that we probably want 
people to move towards PQC, the limitations are unfortunate and will 
lead to additional complexity.

I fear we will still need the replacement key mechanism and then we have 
two different mechanisms and thus more complexity and not less.

If there are serious concerns with the complexity of the replacement key 
draft, perhaps the right approach is to try to simplify it (if possible).

Best,
Johannes

On 10.02.2025 11:04, Daniel Huigens wrote:
> Hi Neal :)
> 
>>From my point of view, the most important use case for having a v6 key
> will be PQC. So, I'll focus on that part of your email:
> 
> On Sunday, February 9th, 2025 at 14:41, Neal H. Walfield wrote:
>> This scheme works, because it it possible to use the same key material
>> for both v4 and v6 keys. It works less well for PQC, but I think it
>> still partially works, because some PQC algorithms use a composite
>> scheme.
>>
>> Given a certificate with an ML-DSA-65+Ed25519 primary key, (I think)
>> it is possible to extract just the Ed25519 public key, and compute the
>> corresponding v4 or v6 key. So we can go from a PQC certificate to v4
>> or v6 certificate.
> 
> The PQC draft says not to do this:
> https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-06.html#name-key-generation-2.
> Generally, reusing key material in different contexts is not advised,
> though I don't know whether there's a practical attack in this case,
> but it'd make the security analysis harder (or even fail to hold,
> formally speaking, as the text suggests).
> 
>> Given a v4 or v6 key, we can't figure out the fingerprint of the
>> corresponding PQC key, because we don't have the PQC public key. But
>> if the PQC certificate is available, we can look it up by its Ed25519
>> public key.
> 
> Looking up the v6 (PQC) key from a keyserver when you only have a v4 key
> would seem like the most useful/important part of this, but this would
> only be possible if keyservers would allow looking up PQC keys by the
> Ed25519 public key, which seems complicated.
> 
> Also, in general (even in the non-PQC case) this seems like a somewhat
> fragile way to look up a v6 key from a v4 key, because you don't know
> whether they reused the key material as you suggest, so the request
> might be insufficient (and conversely they might not have a v6 key
> at all, so the request might also be wasted).
> 
> In essence, compared to this proposal, the key replacement draft places
> additional work on the key holder, to make things more straightforward
> and reliable for the key "consumers", so to speak. And I'd argue that's
> probably a good trade-off to make.
> 
> Best,
> Daniel
> 
> _______________________________________________
> openpgp mailing list -- openpgp@ietf.org
> To unsubscribe send an email to openpgp-leave@ietf.org