[openpgp] Hashing literal (meta)data fields

[Daniel Huigens <[e-mail]>]

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
  scenario
- they make it impossible to be able to cleanly detach and reattach
  signatures
- 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!

Best,
Daniel


[1]: https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.html#section-5.2.4-8.3.2.7.1
[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-5.2.3.32
[4]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/86