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

Justus Winter <justus@sequoia-pgp.org> Fri, 08 July 2022 11:03 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 828E4C14F726 for <openpgp@ietfa.amsl.com>; Fri, 8 Jul 2022 04:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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] 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 D7KyghlhOiRT for <openpgp@ietfa.amsl.com>; Fri, 8 Jul 2022 04:03:48 -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 83A3EC14F720 for <openpgp@ietf.org>; Fri, 8 Jul 2022 04:03:47 -0700 (PDT)
Received: (qmail 11672 invoked by uid 500); 8 Jul 2022 11:03:45 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Daniel Huigens <d.huigens@protonmail.com>, Andrew Gallagher <andrewg@andrewg.com>
Cc: openpgp@ietf.org
In-Reply-To: <rFGQzFpo7YRJdeCEIqSDMYYZhf_svkyx8UHG3GE__VMZFj2pRAbcTa-G9jjQoppUln1XNblYl6Lbjn7wMDMLqwzTJxB-hO0RwAofwLJL7wc=@protonmail.com>
References: <d0483dcb-025b-37c2-9a26-e42133b506ac@andrewg.com> <rFGQzFpo7YRJdeCEIqSDMYYZhf_svkyx8UHG3GE__VMZFj2pRAbcTa-G9jjQoppUln1XNblYl6Lbjn7wMDMLqwzTJxB-hO0RwAofwLJL7wc=@protonmail.com>
Date: Fri, 08 Jul 2022 13:03:29 +0200
Message-ID: <87sfnbx3we.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(-1.284166)
X-Rspamd-Score: -3.484166
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Fri, 08 Jul 2022 13:03:45 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/BsoFOoJrfh2Fgn9tMitP7aVSyrk>
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 11:03:53 -0000

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

> FWIW, OpenPGP.js does this check as well. I agree it would be nice to
> unify the behavior here. In my opinion, doing the check makes more
> sense than not doing it, because as you said, otherwise why have those
> bytes in the signature; we might as well remove them from v5 signatures.

Sequoia uses the digest prefix as when canonicalizing certificates.  If
we encounter a third party certification for which we don't have the
issuers certificate, we use the digest prefix as a heuristic to check if
a signature is associated with the right component, and if not, use it
to find the right component (with a chance of 2^16 of getting it wrong,
in which case we duplicate the signature).

Therefore, I'd like to keep the digest prefix.  If anything, I'd suggest
to include the full digest instead.

Best,
Justus