IETF Logo Mail Archive

Re: [openpgp] v5 interoperability

Daniel Huigens <d.huigens@protonmail.com> Wed, 03 April 2024 09:54 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 646E0C15198D for <openpgp@ietfa.amsl.com>; Wed, 3 Apr 2024 02:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=protonmail.com
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 U9C6KVt-RxsA for <openpgp@ietfa.amsl.com>; Wed, 3 Apr 2024 02:54:08 -0700 (PDT)
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 09BBBC151984 for <openpgp@ietf.org>; Wed, 3 Apr 2024 02:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1712138045; x=1712397245; bh=Kgqn4qCicjoezLDqg/Ms7gRLnyXAXDv+iiUiB9rG/XM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=estPNl/kFEl+1uqiWT5jPTOoieb2Rf/6BLbu4rtpZczObZkVt4qOCgSw0/IV7u751 yv3wWyu03jonKq5TcDQ4lO+9IfCdr7Q1mRcyaChaCFvV0WT4ctw5G5x4Dnu+TiS5iv zVuiiyiAv/EtPmrUkRR846KBO9corT2BkzFVn04tmJoxn4vJ6Ud2goTwm0sa5i9oGT 2zP5Hau34tbljSPLOWWr/kSkPrN0n9s+/cTSGdEkqg6C88wAc1XPvOyfYbP0kCkkcV SOkkq074xEIEaywwbftqAQFn2/JMmL9tryntuH0HNX7xnV8xVwwqqpaSf/NEYIcZIJ QLWu9XHAa2hDg==
Date: Wed, 03 Apr 2024 09:54:01 +0000
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: IETF OpenPGP WG <openpgp@ietf.org>
Message-ID: <OxwBjPxjKr9c6TLimy66G_sd1gcTenXtbtwSQptBwxo2sBL2fzpeKa-PB59ANTeNWvLXrLJWWu2bEq1tR4WAizV4R56qemPwxTB4rAe4Km8=@protonmail.com>
In-Reply-To: <B756ABD1-7036-4D40-BE89-8BCE940CA133@andrewg.com>
References: <EAE8D81F-05F6-4551-8878-80555709A4EF@andrewg.com> <2OonUbUZ9iR9hDOxXli1u20qpPYokvk2XJ5-7O6XNryRr02pfydpgMFcyfwzYGb2NgmsD-H9cqvIc2CpW8CQlHu2i-E3Dqsts4ch1ECvs_A=@protonmail.com> <B756ABD1-7036-4D40-BE89-8BCE940CA133@andrewg.com>
Feedback-ID: 2934448:user:proton
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/s3f1R8TLWH9CHJV2e25wdK20PIk>
Subject: Re: [openpgp] v5 interoperability
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 03 Apr 2024 09:54:12 -0000

On Wednesday, April 3rd, 2024 at 11:40, Andrew Gallagher wrote:
> But can I serve such a v5-subpacket key indiscriminately, and trust that non-librepgp clients will silently ignore the subkey, or do I have to strip it myself before serving it, in case a client will treat the v5 subkey as invalidating the primary?

Since the crypto refresh considers them noncompliant, I don't think we
can guarantee anything about how non-librepgp implementations should/
would handle them.

More practically speaking, [1] has a test about certificates with a
subkey of an unknown version (in the second-to-last row), and various
implementations reject the certificate - so indeed I wouldn't rely on
anything else.

Whether that means you should strip subkeys, or just warn the uploader
that the key might not be compatible with all implementations, I'm not
sure, though.

Best,
Daniel

[1]: https://tests.sequoia-pgp.org/#Perturbed_certificates

v2.23.0 | Report a Bug | By Email