[openpgp] Hashing literal (meta)data fields

Daniel Huigens <d.huigens@protonmail.com> Mon, 10 October 2022 11:34 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C5C53C1522D7 for <openpgp@ietfa.amsl.com>; Mon, 10 Oct 2022 04:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Status: No, score=-7.109 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=protonmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aq4t2XLNWWmT for <openpgp@ietfa.amsl.com>; Mon, 10 Oct 2022 04:33:58 -0700 (PDT)
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch []) (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 98D9EC1522B1 for <openpgp@ietf.org>; Mon, 10 Oct 2022 04:33:58 -0700 (PDT)
Date: Mon, 10 Oct 2022 11:33:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1665401636; x=1665660836; bh=EEJ/MFhkhOCadD2zt/D82H1kk3fwXjafQs1ldNwtQSA=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID; b=bQuKwzCxViWk9dWEKBZPTsPG5SUIDsSs8H4aGtSrQhAbYJXVLYDysObJo8jIrlmRs VDx/Ef9U6Ek6IGg247LooYt6+7RNxa/ehRpy+HNHRUH3OVAYC1ViPQRlREp8Zgn6S5 M6y8jvlZyPeZ6PTNjLQ+CBMLzO+xM4nyfiBgT5Nb4KxrV2YGx5MztF9yxPuOrXym1M SmFKp+ZUFoUCy/e0SvaiwNSWyCS1srZpri8nRnt5mpYQhxcUWQ3nhCNrV7dIm8X4vK 2/y/V0z0cNzov4CIl6XQDAJONlaW+ZeEIB5svhJ2dmig3Cm/HRuLSgVAGPzDraRZyK 4MP25p0ImQ0BQ==
To: IETF OpenPGP WG <openpgp@ietf.org>
From: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <QiAK3LsKi6K_UDPKI3S2vWACTHIL2CWil-AmjadkkA9XQrrdoDSuAT5UwwQCqseLMaStR4XuM04rfSoTSzXZEsNLIp3Z8_7C7Xu4Nxab1eE=@protonmail.com>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE>
Subject: [openpgp] Hashing literal (meta)data fields
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, 10 Oct 2022 11:34:02 -0000

Hi all,

[The following is an attempt to discuss one of the concrete differences
between the various drafts that have been created, and hopefully reach
a consensus on this small piece, in order to make it slightly easier, or
even slightly less important, to reach consensus on what to do overall.]

In OpenPGP, the Literal Data packet has a content format octet (binary
or text, for example), and a "file name" and date field. The latter two
are not very strongly specified, and can be left blank / zero, but when
encrypting a file, it can be useful to store its file name and
modification date, for example.

In RFC4880, these fields are not signed (even if the message is signed).

In draft-ietf-openpgp-rfc4880bis-06 through -10, v5 signatures do hash
the metadata fields into the signature. [1]

In draft-ietf-openpgp-crypto-refresh, this change was not kept, and
instead, it is encouraged to leave these fields blank / zero. [2]
This was discussed in [4], I'll quote the reasons from there:

- it's not clear how to populate the fields in an encrypt-then-sign
- they make it impossible to be able to cleanly detach and reattach
- when those fields are sometimes signed (v5) and sometimes not (v4),
  it's difficult to act on them safely

(I'll refrain from giving too much further commentary here, but will say
that for us, the second point is concretely relevant, as we do so in
certain situations, for example when encrypting already-signed messages
on arrival.)

In draft-koch-openpgp-2015-rfc4880bis-00, v5 signatures hash the
metadata fields, and v4 signatures can optionally hash the metadata
fields by adding a "Literal Data Meta Hash" signature subpacket, which
includes a hash of the metadata fields (and the subpacket is then
hashed into the signature). It is disallowed for v5 signatures. [3]

Now, for my concrete proposal: let's use the "Literal Data Meta Hash"
subpacket for both v4 and v5 signatures, to allow (but not force) the
signer to hash these fields. This maintains the possibility to convert
a detached signature (that doesn't have this subpacket) to an attached
one (if we don't require it), and similarly, to convert an attached
signature (that does have it) to a detached one (if we ignore this
subpacket for detached signatures).

Let me know what you think!


[1]: https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.html#section-5.2.4-
[2]: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-06.html#section-5.9-4
[3]: https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-00.html#section-
[4]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/86