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

Justus Winter <justus@sequoia-pgp.org> Mon, 11 July 2022 09:53 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 C6887C16ECDE for <openpgp@ietfa.amsl.com>; Mon, 11 Jul 2022 02:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=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 6bb9dCEj1xU7 for <openpgp@ietfa.amsl.com>; Mon, 11 Jul 2022 02:53:28 -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 685F5C16ECD5 for <openpgp@ietf.org>; Mon, 11 Jul 2022 02:53:27 -0700 (PDT)
Received: (qmail 26436 invoked by uid 500); 11 Jul 2022 09:53:25 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Andrew Gallagher <andrewg@andrewg.com>, "openpgp@ietf.org" <openpgp@ietf.org>
In-Reply-To: <SY4PR01MB6251E246194F1667459EAC4FEE859@SY4PR01MB6251.ausprd01.prod.outlook.com>
References: <d0483dcb-025b-37c2-9a26-e42133b506ac@andrewg.com> <87y1x3x4hd.fsf@europ.lan> <SY4PR01MB6251E246194F1667459EAC4FEE859@SY4PR01MB6251.ausprd01.prod.outlook.com>
Date: Mon, 11 Jul 2022 11:53:16 +0200
Message-ID: <87bktwvuur.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.888321)
X-Rspamd-Score: -5.088321
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Mon, 11 Jul 2022 11:53:25 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/psfYXngis0_Hl5f3FPsiJOO04QQ>
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: Mon, 11 Jul 2022 09:53:32 -0000

Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:

> Justus Winter <justus@sequoia-pgp.org> writes:
>
>>I wrote a test to explore how the different implementations behave:
>>
>>  https://tests.sequoia-pgp.org/#Signature_digest_prefix
>>
>>Every implementation I test sets the digest prefix correctly (GPGME's support
>>for gpg1.4 seems to be faulty, we see a lot of unexpected failures for
>>gpg1.4.)
>
> You may want to indicate in the text whether a check means "handles an
> incorrect prefix" or "checks for and rejects an incorrect prefix".

In the test suite, a checkmark means that the test suite did an
operation, the operation succeeded, and the result of the operation was
not obviously incorrect (e.g. the test suite may check for a decryption
operation that the expected plaintext is returned to prevent
implementations from claiming success while producing no output at all).

This is orthogonal to whether we think the operation should succeed or
not.  Some test vectors have an expected outcome.  This is indicated in
the two rightmost columns "expectation" and "comment".  For the test
vectors that do have such an expectation, we check whether the
implementations match the expectation.  This is indicated by the green
and red background (and the left and right earmark).

See https://tests.sequoia-pgp.org/#how-to for a more verbose description
and a sample test result illustrating how the results are presented.

Best,
Justus