Re: [openpgp] v5 interoperability

Paul Schaub <vanitasvitae@riseup.net> Fri, 12 April 2024 17:28 UTC

Return-Path: <vanitasvitae@riseup.net>
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 CBC0DC14F6B8 for <openpgp@ietfa.amsl.com>; Fri, 12 Apr 2024 10:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 (1024-bit key) header.d=riseup.net
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 CWIBuYzh_AU3 for <openpgp@ietfa.amsl.com>; Fri, 12 Apr 2024 10:28:07 -0700 (PDT)
Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (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 1DBB4C14F614 for <openpgp@ietf.org>; Fri, 12 Apr 2024 10:28:07 -0700 (PDT)
Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (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 mx0.riseup.net (Postfix) with ESMTPS id 4VGNnL3zcHz9t9S for <openpgp@ietf.org>; Fri, 12 Apr 2024 17:28:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1712942886; bh=5e3+dGCvhxfjZpx28pYmv6kfPsrUh7/mIRBh6lkpnEE=; h=Date:From:To:Subject:In-Reply-To:References:From; b=CJFHgTu2szcocJlMdglbwgB4Pu/vjmOexmCzz+v/I99/GVp+mFYN5h6guLeCRRLOQ R4lvtVBPXe0mqVDTbjxAqFzZ/HM5Br6oUiMk11qzA9ii3wtomK4vg2Jp8V2NDxgf/a BIxAOxRHp06rq3KmaqHplv5PAM1Z80rm6lFyjmtQ=
X-Riseup-User-ID: 33E0F3D6F14D9FBC3016125AFE33E8CC7D4208114333BDF6B4E491A2E309D00B
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4VGNnK65VMzJrmG for <openpgp@ietf.org>; Fri, 12 Apr 2024 17:28:05 +0000 (UTC)
Date: Fri, 12 Apr 2024 19:28:01 +0200
From: Paul Schaub <vanitasvitae@riseup.net>
To: openpgp@ietf.org
In-Reply-To: <325d0a3c-9a89-4158-9719-473a7e21ade1@kuix.de>
References: <EAE8D81F-05F6-4551-8878-80555709A4EF@andrewg.com> <325d0a3c-9a89-4158-9719-473a7e21ade1@kuix.de>
Message-ID: <AF3B73A2-09D7-4BB3-9826-92E6CA18C6A9@riseup.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----IZ9J1ZE5FQAYRS1OC0GG1TRG0KHEY7"
Content-Transfer-Encoding: 7bit
Autocrypt: addr=vanitasvitae@riseup.net; keydata= mQINBFfz1ucBEADXSvUjnOWSzgW5hXki1xUpGv7vacT8XqqGbO9Z32P3eFxa4E9JvveJmx+voxRW pleZ/L6XCYYmCKnagjF0fMxFD1Zxicp5tzbruC1cm/Els0IJVjFVRLke3SegTHxHncA8+BYn2k/V nTKwDXzP0ZLyc7mUbDl8CCtWGGUkXpaa7WyZIA/qmvUqh7671Vr4vJlq0kFbUibsFblZjk9uydHv vqaVpmBzbr/gWDyirHXwPl5lCnWpORjT7tc8hjyt+dxpmnGdqlDIcqUjdCWoN6NxffLtKz/XpJ+d BvA8rXT/QaPSaVCGo0DbgybvRF1HvX30udx4FF9fFsVAbYP1mvZx4fHy+Z1rJJhODZv1YpH7YY1b mG02vfFkwpW4AyAdsONA+n/XdMCsA006/pljNd3GxjcqB5D6BhpdUvcgUslkuELsVYWbEyhxKzzJ vZNjQ/iHsaThooy9SFHc71PgYdyEL/WzoGr421GwpCL6BuE0rlumgaTmjoU/9ydLO6zpbV4RYDgt saGQxOxVc0y1Lj8CWTi/XYIVRnmqrjGmubRV7q8pTxrgoyk2zwQ+twyxp/8ZRHzl5ISiDLKSDlcM K1oa7NqyL+MCwiswpaObk56HxgF2ZwEbJZYCwetxyTK7HX4/WV0V6TaPzS7dHAsb6t1Aq8IS1JdG jWKRPkjkhR95nQARAQABtCVQYXVsIFNjaGF1YiA8dmFuaXRhc3ZpdGFlQHJpc2V1cC5uZXQ+iQS+ BBMBCgKoAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAFiEEf5EW/qkKWYOTbHz6oCfbLz4eEYoF AmAMGzk1FIAAAAAAEgAacHJvb2ZAbWV0YWNvZGUuYml6ZG5zOmphYmJlcmhlYWQudGs/dHlwZT1U WFQ+FIAAAAAAEgAjcHJvb2ZAbWV0YWNvZGUuYml6aHR0cHM6Ly9mb3NzdG9kb24ub3JnL0B2YW5p dGFzdml0YWWQFIAAAAAAEgB1cHJvb2ZAbWV0YWNvZGUuYml6eG1wcDp2YW5pdGFzdml0YWVAamFi YmVyaGVhZC50az9vbWVtby1zaWQtMjA5MzY4MTU0NT02Mjg5YWEzYmQ4YTUwMWEzNjMyMmEwZjg5 NGY4ZDFkOTcxOGRlZDAzNjE2MDM5ZjFjZjQ4YjJhNDFlZTM1OTIwjxSAAAAAABIAdHByb29mQG1l dGFjb2RlLmJpenhtcHA6dmFuaXRhc3ZpdGFlQGphYmJlcmhlYWQudGs/b21lbW8tc2lkLTE5OTE0 MTgyMD1mNGE4ZmY4NDAwNDM5M2E4N2Y3MDEzYzYwMDY1YmRjODliMTE2OWViY2ZiODA2MGM0Zjk2 NjliNDNiYTBjODE0kBSAAAAAABIAdXByb29mQG1ldGFjb2RlLmJpenhtcHA6dmFuaXRhc3ZpdGFl QGphYmJlcmhlYWQudGs/b21lbW8tc2lkLTE0Mjk2NzcxMjU9ZThhN2IxMjM2Yjg1MGI0NjdhNTA5 MmMwYmRmZWE4NmE1M2UzNjg0MjgzYTFkNWZlMjZlZjU4NzJkZDBhZWY0MUgUgAAAAAASAC1wcm9v ZkBtZXRhY29kZS5iaXpodHRwczovL2NvZGViZXJnLm9yZy92YW5pdGFzdml0YWUvZ2l0ZWFfcHJv b2YACgkQoCfbLz4eEYrCxQ//Wjn7sEx+1rWCxVIQG9qqYJkMrSMvsyjeDZJrKLD5o5XIVQhjL/9g t3hBkYiOftarTXmmMD+xLAAS1netQTvgAJuLb1gypKqB8wG+4Po7e7ZO9XTLkjqjMZSTA/ZyJw2V fGdw40oGl8NEZrVUMiDiCEYzv8CXgBoEwiE0BA4lLUWKh9dnuonuMornsFjx7W5R+DQoKE+//G7b XCuErLwO6wHPs9K3xLwoG2Kyy3wyr57DystEVtnQX+XlWC9251VJpHWaZJOhG+YqCLZEeMizuGUQ TBGv51YY71JpbSjE1tXKAyU/+ksSfVH1T3i0DEMteCZoNgvY01fDKRrm4EouzLV0depe6Qo9LynL Y9mG7YUkwtTT6aX6zaRNsDYHN7uyVE66IY8mD1bOi8JBhUNqbx5p8YMwLpDf3cdcf6DGrb0tGDYu 6V/g0m2iw7glVs7LN55F3kWVmRSInu9uJWojMY3yN6Xwyv800oJyhyTCavLW7ckCvCA1KpH5S/4J 4fjjpuaV9nomvApZBFy4pVF+tca5PjpiagVJomOOVMBNRXFxS5A2QWVDpuJuZ3MSYVoqlVJBR/yB ecSMuHvwruR3HzVz1yYhTgau6Ura7MZBQu3dSArK3Kth/kQ7CqdusMOEBhEXByVthGO89RlKVNag Kji7vaA67F1FYODJr0hzRie5Ag0EV/PW5wEQALNTc5Gh0TR1rtmIkJPJU3LXIhY8jJVR/1ctvMmU n6R1q7ezAs4ZGitT2LFpZyYnzpQp788g1tuqLi6mz0edZc0RbPVCA9Xc4OEQrjzLNE8JSH3FAmwU XN5atwJ/eNbBMA9PoILhqINaCLptq3oAH7Z20qEI/9fjqGWc9M6ng5B6K0HAg03NxH2LC47MIhYq IqDj1oD4xug0mt/cX9O2Ha1tAzsKSfzPjAlaD8URKm1wv6AmFEPOYeFeumvGDGK5pHh86tZLl+x1 7qCSrV/Ft7xwoj6P7FP8Be+G9KA4rJH3l8DGmaEYVT5GBgRCIQDup/balrbks8VpjFh/0w8PIdhj OoQmuu2D1bok587TXa/BUfQ91haXIs6WzSRY+hwXK3zuiMA+TSvIeX4qhXiEACH6NTy/PDgvIw1Y 7HBdGKCXgoiPLERYz/9cvzG2GiiEeHwPj26IHlv5JRniPG6ePXRkGvvHJ64A3J8zUtU14dWXGqG/ R/gwx3Ugjd+4R7X66BQwQq+ikUOeVswU3Ufs5om2Q45BmOE9LmkIxUABrITzRnK+t6wklsmZyJ8d R+FlsJ7FKrk7e0/qrdEwDn3fvbIYD6s/3SypJBfO5gbUuNt3RnQ6egWSebeJaZfCxokrpPaf3JKA eDBE/tYi42lPhRAixciIPeb+hpNTmBcXg55xABEBAAGJAn4EGAEIAHIFgl/4kEMJEKAn2y8+HhGK RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZ2FgE3f7bnBndxQ4h2+ACXWf TabWwHHHGpI9ZqZhZTBJAhsMFiEEf5EW/qkKWYOTbHz6oCfbLz4eEYoAADAdD/0Szb4rHGgdyItG SzLOsEDrGJCfztXOH5vGo5s/meZYBIYFW3hYZrKiRyIJP54uFHHRwLCiAcH3FcWT80fpx9YOQiHf xNpmVwnAoufOmfI8p/G9+Fcf62HSVZKsgS9zrUvhDjAUTrwOVbDVqyFZtAaxqsxI5tJilLkZXaWc ozUcw9m3iEyZDgpNR/1arfmwl5sW9mpG/tOmwdDaihvpI0b5Qp0sAb2fkcol1aznnqI+Dg4BsrWt FvkbZ6GvgF6a+SROrgXN2fr4Gaw53agYA/0mVF4zQv/2NzOqsX44vOHvB15hc7mXHJks8B/jqejJ YeF4j4asZi+fwCaBPEMQlJwm+JhDXJ3xnZp5Zlhq2wKTZHZm94Vw16WQic0WIHT7VBLlief5pZtP e/f2xfG9BzdHghtOlaqDYvp0jW3rYe3/+ILHqutA6XCWn+JRlbPQII1xTRlksmZh7hcDPlKXx2Yk V36a24pQe2QYX4cfXdDGe5bshQGtSHQo2926Xb2TD0ksfMaFuKG3LhMVWsicyc9RwnlsK98GLs1e EpFm0pt2FjgXyvRGhnNkaIE7vPXrJsgsFtrrJXEq52Eug6dJQnAtQl7CpWSlldhmYG2QFCPsO0+9 VE+A8Pz+Kjr7iiH6rw9kidGX6CqFdaGuWDR6qbCVJpnPlF5n02YHz9eMcwVMlQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/IsmbK4EWXWkqi7OfPYmqnrFjZUA>
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:28:10 -0000

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...

Am 12. April 2024 19:21:42 MESZ schrieb Kai Engert <KaiE@kuix.de>:
>On 02.04.24 20:50, Andrew Gallagher wrote:
>> It came to my attention recently that recent versions of GnuPG are (under certain conditions) creating v5 subkeys and binding them to v4 keys. The use of mismatched subkey versions was not explicitly forbidden by rfc4880, but is forbidden in crypto-refresh.
>> 
>> So what is the proper way to treat such keys? They exist in the wild already, so cannot be ignored.
>
>Wait, if this is actually a reality, could this be a way to achieve interoperability?
>
>Create a v4 signature key.
>Bind a v5 encryption key.
>Bind a v6 signature key.
>Bind a v6 encryption key.
>
>Amend crypto-refresh to allow that.
>
>Email clients could generate this mixed key for maximum interoperability.
>
>Crypto-Refresh implementations use the v6 subkeys for messages, and ignore the v5 subkey.
>
>LibrePGP implementations could use v4 + v5 and will have to ignore the unknown v6 subkeys.
>
>Thanks
>Kai
>
>_______________________________________________
>openpgp mailing list
>openpgp@ietf.org
>https://www.ietf.org/mailman/listinfo/openpgp