Re: [openpgp] v5 interoperability

Heiko Schäfer <heiko.schaefer@posteo.de> Fri, 12 April 2024 17:40 UTC

Return-Path: <heiko.schaefer@posteo.de>
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 DF540C14F6A9 for <openpgp@ietfa.amsl.com>; Fri, 12 Apr 2024 10:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=posteo.de
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 ixNC6PYKxL_X for <openpgp@ietfa.amsl.com>; Fri, 12 Apr 2024 10:40:13 -0700 (PDT)
Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 C5E6CC14F693 for <openpgp@ietf.org>; Fri, 12 Apr 2024 10:40:13 -0700 (PDT)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 99EF9240107 for <openpgp@ietf.org>; Fri, 12 Apr 2024 19:40:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1712943610; bh=N5JYgwcDzhHpVAoGqo/dWhmxKuQCq6vrumEfYfgtr5c=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding:From; b=BRVbUx9LpTlIDe6N3370BE1zhvTqOJACojjftcBZGw7OhMnK6HERjhPnN+ZUYFvL3 Eiw1xLd8UH3uFxUGFIkRNOYall6EeWf/U75b0sPwzUWacskNqRZe36CyDjQKCpjUHy 3ylt1UHqiKmF2MfZShNY9ec98cr44+sXYpjYqr2xPvyySlzED5SYG1l1+/hqDRmyRW JzfEnUXN2Qq4QSwoQreGhyVRf2CAEY43VUDpXgYraJtPy6MRXyQ0IBbbdCVKCw0+VK PBiQKVeUj02G4HxRhlLOmpsk4EAuz0Ll6TI2QEc+SM65PN8LGUOgpt08f7IZrA4SQh 51bJA+itapgfQ==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VGP334lkDz9rxM for <openpgp@ietf.org>; Fri, 12 Apr 2024 19:39:59 +0200 (CEST)
Received: from services.foundation.hs (services.foundation.hs [192.168.21.4]) by mail.foundation.hs (Postfix) with ESMTP id 1C8B64EA82 for <openpgp@ietf.org>; Fri, 12 Apr 2024 19:39:59 +0200 (CEST)
Message-ID: <63326282-e216-40d9-9ce4-da717f8d42c1@posteo.de>
Date: Fri, 12 Apr 2024 17:39:58 +0000
MIME-Version: 1.0
To: openpgp@ietf.org
References: <EAE8D81F-05F6-4551-8878-80555709A4EF@andrewg.com> <325d0a3c-9a89-4158-9719-473a7e21ade1@kuix.de> <AF3B73A2-09D7-4BB3-9826-92E6CA18C6A9@riseup.net>
Content-Language: en-US
From: Heiko Schäfer <heiko.schaefer@posteo.de>
In-Reply-To: <AF3B73A2-09D7-4BB3-9826-92E6CA18C6A9@riseup.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/fwOWPfbCEGJ-HgK9c-DxIhN6LWk>
Subject: Re: [openpgp] v5 interoperability
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, 12 Apr 2024 17:40:18 -0000

On 4/12/24 19:28, Paul Schaub wrote:
> I recently took a look at the LibrePGP document and found some more 
> things that would result in  inconsistent behavior.
>
> CR states that only v6 keys shall create v6 signatures. LibrePGP on 
> the other hand allows any key to create v6 signatures.
> It also allows v6 sigs to have zero length padding (the way this ought 
> to be encoded is imho underspecified), while CR binds padding length 
> strictly to the digest algorithm.
>
> I'm sure there are more of these inconsistencies which will make 
> interop and parser design a pain...

I share these concerns, but wonder if Kai's suggestion adds any pain to 
what we're already looking forward to, on the parser front, without 
Kai's suggestion:
An ecosystem that will possibly contain artifacts with formats that may 
not be reliably parsable based on just the version number of a packet.

For example: Let's imagine GnuPG were to emit "slightly different v6 
signatures" in the future. Parsers will then have to deal with that 
format (if only just by rejecting the signature).

At least on the parser side I struggle to imagine how mixing versions 
(as per Kai's mail) makes things worse (which is not to say that I think 
there are *no* serious problems with the idea).