GitLab

In an attempt to cover the metadata (format, filename, and timestamp) of literal data packets, v5 signatures hash this information (see https://openpgp-wg.gitlab.io/rfc4880bis/#name-computing-signatures):

- A V5 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data and a final extra trailer.
  Thus, the hashed fields are:
[...]
  - Only for document signatures (type 0x00 or 0x01) the following three data items are hashed here:

    - the one-octet content format,

    - the file name as a string (one octet length, followed by the file name),

    - a four-octet number that indicates a date,

I don't think that this is advisable because it breaks the symmetry between signed messages and detached signatures. Previously, it was possible to "detach" a signature from a signed message yielding a data file with a detached signature, and vice-versa.

Further, I don't think that it is possible in general. First, what should be hashed when producing a detached signature? A file has no content format, the file name can change easily making the signature incredibly brittle, what date should be used (mtime, atime, ctime), do we really want the signature to break if the timestamp changes?

Second, if we consider signing OpenPGP messages, the signer may not have access to that metadata. OpenPGP supports encrypt-then-sign (see https://openpgp-wg.gitlab.io/rfc4880bis/#name-openpgp-messages), so the signer may only have access to the encrypted message, and cannot know the literal data packet's metadata.