IETF Logo Mail Archive

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

Justus Winter <justus@sequoia-pgp.org> Fri, 08 July 2022 13:15 UTC

Return-Path: <justus@sequoia-pgp.org>
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 13C35C157908 for <openpgp@ietfa.amsl.com>; Fri, 8 Jul 2022 06:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 c19bLW-9tOZ2 for <openpgp@ietfa.amsl.com>; Fri, 8 Jul 2022 06:15:10 -0700 (PDT)
Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (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 69D0AC14CF01 for <openpgp@ietf.org>; Fri, 8 Jul 2022 06:15:08 -0700 (PDT)
Received: (qmail 26841 invoked by uid 500); 8 Jul 2022 13:15:06 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Daniel Huigens <d.huigens@protonmail.com>
Cc: Andrew Gallagher <andrewg@andrewg.com>, openpgp@ietf.org
In-Reply-To: <Gjz95aE4GW3B-PIIf3VWobfxKwlSPyI-yU5L7B5zM-6QBv48RXZrrXvIkFQ5NUd9g64Ai9Adzqxahueo5LEqWRCY-Hjj9dRZeI2JYlaWqd4=@protonmail.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>
Date: Fri, 08 Jul 2022 15:14:48 +0200
Message-ID: <87let3wxtj.fsf@europ.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Rspamd-Bar: ----
X-Rspamd-Report: MIME_GOOD(-0.2) SIGNED_PGP(-2) BAYES_HAM(-2.741877)
X-Rspamd-Score: -4.941877
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Fri, 08 Jul 2022 15:15:05 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/LCIoXC-op1ncWEEd1Ty6DPaGbj8>
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: Fri, 08 Jul 2022 13:15:15 -0000

Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org> writes:

> On Friday, July 8th, 2022 at 13:32, Justus Winter wrote:
>
>> Note that this can happen even if producer of the signature and consumer
>> are acting correctly. In fact, that is exactly what happened before:
>>
>> https://dev.gnupg.org/T2236
>>
>> AIUI it was a SKS bug that messed up the certificate.
>
> Interesting, thanks. I hadn't seen that before, but yeah, I would still
> prefer to fix these keys on keyservers instead, if at all possible.

You said before that you prefer not to use the reordering heuristic.
But how else should the keyserver fix the certificate?

Best,
Justus

v2.23.0 | Report a Bug | By Email