…
Old: Literal Data Packet(tag 11)(3914 bytes)
Format - binary
Filename - File.txt
File modified time - Thu Jan 30 23:40:48 CET 2020
Literal - ...
…
That "File modified time" label in a signature dump suggests the timestamp is the modified time of the file that got signed ("File.txt"), but it actually seems to be the "Created" date of the signature itself (that's how GnuPG does it here at least.) So the used label "File modified time" in this case is misleading, IMHO. Similar for the "Format".
RFC 4880 states the following: "A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time."; I assume there's no way to distinguish between an actual file creation date vs. the packet creation date, so the label should be open to both interpretations, I guess.
My recommendation to make dumped information more clear to the user:
…
Old: Literal Data Packet(tag 11)(3914 bytes)
Packet data format - binary
Creation time - Thu Jan 30 23:40:48 CET 2020
Filename - File.txt
Literal - ...
…
That "File modified time" label in a signature dump suggests the timestamp is the modified time of the file that got signed ("File.txt"), but it actually seems to be the "Created" date of the signature itself (that's how GnuPG does it here at least.) So the used label "File modified time" in this case is misleading, IMHO. Similar for the "Format".
RFC 4880 states the following: "A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time."; I assume there's no way to distinguish between an actual file creation date vs. the packet creation date, so the label should be open to both interpretations, I guess.
My recommendation to make dumped information more clear to the user: