IETF Logo Mail Archive

Re: [openpgp] Expected client behaviour ambiguity in signature verification

Andrew Gallagher <andrewg@andrewg.com> Tue, 12 July 2022 17:38 UTC

Return-Path: <andrewg@andrewg.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 B18B3C157903 for <openpgp@ietfa.amsl.com>; Tue, 12 Jul 2022 10:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=andrewg.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 gvhRpyPrMPtj for <openpgp@ietfa.amsl.com>; Tue, 12 Jul 2022 10:38:21 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (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 A790FC14F747 for <openpgp@ietf.org>; Tue, 12 Jul 2022 10:38:20 -0700 (PDT)
Received: from smtpclient.apple (unknown [176.61.115.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by fum.andrewg.com (Postfix) with ESMTPSA id AACDB5ECAC; Tue, 12 Jul 2022 17:38:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1657647496; bh=kiCmiXe+iAj0ASKvLJAjXvkcq9E+Q+V2MIP7jAhx1vo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=LzoQOaYYns6HjSyLYadHcipmOOr94pdqmRvGojMWSdrP8erxx+3QBhIg9/AJKMULA 4pz98Slc2N/55khQhDv26Tej3nZ3GX08/eH/XYvm9K0gb6e2FAsSM8Q1v4R/Bldh52 wpKr5XlfzLGP6dLGqEuZ6KB6DTNBm4Bgyh3ycm3Qq/cBUtIt+zZaxCE0R6nJaE9hZl 3/agHfD2iHBk0C0Taa2APJlVBEhgrOc9A68eeAJeUn+eu4L7DXgKqy3KMpT7N0yxN+ z8stMDWuA8YvjChUwrcuMjQI7v6hA3ISd5AUjQ8SxDSkKZKUL/5nR414oWHi31oBBk 3jU3Ip39XOz3Q==
Content-Type: multipart/signed; boundary="Apple-Mail=_558AD80F-5E3F-4F6D-9198-E5A77ED59DFD"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Andrew Gallagher <andrewg@andrewg.com>
In-Reply-To: <ejV91k6cLZSWu6XKlMLLyVhrwpYOJWOD6q4Ekp6veU53kVA4kSNM1zZ1EoCJG2QJLlYoq2Rylxd7LWxssmPji5ozUn8iZHiD1f3x8vqJ2wc=@protonmail.com>
Date: Tue, 12 Jul 2022 18:38:05 +0100
Cc: Justus Winter <justus@sequoia-pgp.org>, openpgp@ietf.org
Message-Id: <637768CF-CD88-4A2C-BC58-EE2945A1F008@andrewg.com>
References: <d0483dcb-025b-37c2-9a26-e42133b506ac@andrewg.com> <rFGQzFpo7YRJdeCEIqSDMYYZhf_svkyx8UHG3GE__VMZFj2pRAbcTa-G9jjQoppUln1XNblYl6Lbjn7wMDMLqwzTJxB-hO0RwAofwLJL7wc=@protonmail.com> <87sfnbx3we.fsf@europ.lan> <HcMPnSrBDMEb2UqLScL9OTrornuJln5O0WG0ZBe2FLW3Q3YbJ9plFBKGJGdWYyVF-Wz9HA6supa9tXH5y8DfJTe05cUD5Uk0VciCnGuQNMo=@protonmail.com> <87pmifx2km.fsf@europ.lan> <Gjz95aE4GW3B-PIIf3VWobfxKwlSPyI-yU5L7B5zM-6QBv48RXZrrXvIkFQ5NUd9g64Ai9Adzqxahueo5LEqWRCY-Hjj9dRZeI2JYlaWqd4=@protonmail.com> <87let3wxtj.fsf@europ.lan> <ejV91k6cLZSWu6XKlMLLyVhrwpYOJWOD6q4Ekp6veU53kVA4kSNM1zZ1EoCJG2QJLlYoq2Rylxd7LWxssmPji5ozUn8iZHiD1f3x8vqJ2wc=@protonmail.com>
To: Daniel Huigens <d.huigens@protonmail.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/ATzJKNWZODhLwzaJ0nrX7dlgwtU>
Subject: Re: [openpgp] Expected client behaviour ambiguity in signature verification
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: Tue, 12 Jul 2022 17:38:26 -0000

On 8 Jul 2022, at 15:22, Daniel Huigens <d.huigens@protonmail.com> wrote:
> 
> On Friday, July 8th, 2022 at 15:14, Justus Winter wrote:
> 
>> You said before that you prefer not to use the reordering heuristic.
>> But how else should the keyserver fix the certificate?
> 
> I meant more that they could do a manual intervention for the keys where
> that happened, perhaps. (Particularly in the case where the keyserver
> itself broke the key, I didn't mean that they should fix up these keys
> in general.) Then, they could also verify the signature packets with
> each of the components, to check where it should be placed.

Hockeypuck already fixes such badly-ordered sigs, because it uses go-crypto to parse the key material before serving to clients, and AIUI this normalises signatures implicitly. (There are knock-on issues about how to deal with the non-normalised back end storage but those are orthogonal to this discussion…)

A

v2.23.0 | Report a Bug | By Email