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

Andrew Gallagher <andrewg@andrewg.com> Sun, 17 July 2022 20:17 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 3177CC14F724 for <openpgp@ietfa.amsl.com>; Sun, 17 Jul 2022 13:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=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=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 rbcSPQmOii1R for <openpgp@ietfa.amsl.com>; Sun, 17 Jul 2022 13:17:00 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [IPv6:2a01:4f9:c011:23ad::1]) (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 1A764C14F718 for <openpgp@ietf.org>; Sun, 17 Jul 2022 13:16:59 -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 B6FAD5ECC0; Sun, 17 Jul 2022 20:16:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1658089014; bh=eSVRtlEAxHhanBiScFCiFZY8bJfsQfuaskAlkcwjx5M=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=oswU0o/gJ/FsKaGXZ/Y2Fx7uIZq4h7V5ACoklFTbBuYjNIDDcvYlYWcX6gQU2QfXT 1aSZpHUP4gd1+ie2/GHqzdbQX9pn6n0J01M9IBUvsZDB5ZIpa0jDFxWkIb6p0mi72x icPGGL0yU76GFQfoWixuJGfQs7O/p9auTquxn5AXHRlH15D6eKvIvOKxD4Ry5R2h/h CEI5DNu+Txp4sPieYYOh/DC8Vrdu8USMlLu3/LbME1uCeo6lDg0eRnzoHJ7CKrDsy6 bGseqQXfOK1LaSWoqYJ2DIOi2PbM+UUJjmp0lrjIl3ngmLqrIGhBjE6Z4Ph182NGUO zHVWnZVM+zfnQ==
From: Andrew Gallagher <andrewg@andrewg.com>
Message-Id: <028B9CE1-85A7-4A3C-844D-59583D8AD6BC@andrewg.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_094ED207-8BE5-4FAC-8FDB-4110774A977E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Sun, 17 Jul 2022 21:16:31 +0100
In-Reply-To: <359D3E38-0EF5-4B7A-B473-701E0ED2A0CE@andrewg.com>
Cc: openpgp@ietf.org
To: Daniel Huigens <d.huigens@protonmail.com>
References: <d0483dcb-025b-37c2-9a26-e42133b506ac@andrewg.com> <HcMPnSrBDMEb2UqLScL9OTrornuJln5O0WG0ZBe2FLW3Q3YbJ9plFBKGJGdWYyVF-Wz9HA6supa9tXH5y8DfJTe05cUD5Uk0VciCnGuQNMo=@protonmail.com> <87pmifx2km.fsf@europ.lan> <Gjz95aE4GW3B-PIIf3VWobfxKwlSPyI-yU5L7B5zM-6QBv48RXZrrXvIkFQ5NUd9g64Ai9Adzqxahueo5LEqWRCY-Hjj9dRZeI2JYlaWqd4=@protonmail.com> <87let3wxtj.fsf@europ.lan> <ejV91k6cLZSWu6XKlMLLyVhrwpYOJWOD6q4Ekp6veU53kVA4kSNM1zZ1EoCJG2QJLlYoq2Rylxd7LWxssmPji5ozUn8iZHiD1f3x8vqJ2wc=@protonmail.com> <637768CF-CD88-4A2C-BC58-EE2945A1F008@andrewg.com> <IdS0-BxA6w80HLI578WI9YpxpzFb0MbynW3DOEhCWSF825_1qT6Dj6KlYX5CYs9-VYOJoNlj-8KZ6dd6ywX3xufc11_k_vScRCI-F1ik9XM=@protonmail.com> <25F2FE86-5B9E-4211-A526-FBCBD18EAA30@andrewg.com> <Xsi4cfl-3WekivJxtTFaLQnzwmNPn6RF3nHdF99G1qZU_e1iLB7ewnR-zRZP9HbdWQvIEQZqTb9CrniOKvufk8mkleyV2PZs8XLDfCQXrFo=@protonmail.com> <359D3E38-0EF5-4B7A-B473-701E0ED2A0CE@andrewg.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/5-alLLt3DXaGO19l4ryer_5Vcko>
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: Sun, 17 Jul 2022 20:17:05 -0000

On 15 Jul 2022, at 16:45, Andrew Gallagher <andrewg@andrewg.com> wrote:
> 
> Signed PGP part
> On 15 Jul 2022, at 15:25, Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org <mailto:d.huigens=40protonmail.com@dmarc.ietf.org>> wrote:
>> 
>> Are there many keys out
>> there that fail this check? I understood that GitHub has one, generated
>> using OpenPGP.php, would it be possible to ask them to generate a new
>> key, or modify their existing one? (Someone could do that for them, I
>> guess :)) Or are there too many keys like this out there?
> 
> I hotpatched hockeypuck to log this particular error against a primary key identifier and loaded an SKS dump. It has only been running a few minutes but it is already at several hundred unique primary keys affected, and counting at ~ 50 keys per batch of 15000. Scaling that up gives a ballpark of 22,000 keys in the full SKS dataset with bad hashtag self-signatures.


I need to clarify and correct the above, sorry.

The figure of 22k keys is an estimate of the total number of primary keys that throw a bad UID self-signature warning on import to hockeypuck. This includes misplaced signature packets as well as badly-constructed high-16-bit fields. The number of keys with high-16-bit errors only is considerably smaller than this total. Unfortunately due to a glitch in docker, my system dropped a large chunk of the import logs, and I'll have to run the test again to get the real numbers, but based on conversations with other hockeypuck operators in the last couple of days, the total number of unusable keys is unlikely to be more than a few hundred.

Of the few keys with high-16-bit errors that I did detect, most are of the form `<wordpress@domain>`, and the other is for a software project that I know uses Wordpress to host their website - all consistent with the theory that openpgp-php is creating them.

A