[openpgp] Re: Analysis document

Andrew Gallagher <[email protected]> Thu, 10 Jul 2025 15:58:02 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
On 10 Jul 2025, at 13:13, Daniel Kahn Gillmor <[email protected]> wrote:
> 
> On Wed 2025-07-09 10:13:14 +0200, Falko Strenzke wrote:
>> Daniel Huigens wrote:
>>> There is also a proposal to address this
>>> <https://andrewgdotcom.gitlab.io/draft-gallagher-openpgp-literal-metadata>,
>>> though not adopted yet.
>> 
>> The proposal seems fine.
> 
> Without my chair hat on, but as an implementer and maintainer, i'll to
> say that i don't think this is a great proposal.
> 
> It has an unnecessary degree of freedom (hashed vs. verbatim).  Why
> should someone implement one or the other when sending?  Why must
> receivers be able to handle both?

It was written at a time when specifying both LibrePGP- and OpenPGP-compatible wire formats appeared to be a reasonable path towards healing the schism. If I was writing it again today I would omit the hashed variant entirely, as it has since emerged that not even GnuPG plan to implement it.

> - There is no clear interpretation of the octet string of the
>   "filename" -- is it UTF-8?  does it use / for path separators?  what if
>   it contains a NULL char?

All text in OpenPGP is assumed to be valid UTF-8, and we could make this (and other concerns) explicit as necessary.

> - The timestamp is just one second resolution, and its range caps out
>   at the OpenPGP limit in 2106-02-07 (1970-01-01 + 2^32 seconds).
>   Modern filesystems offer much higher resolution (e.g., ext4 offers
>   nanosecond timestamps) and wider range.

Sure, but how often would this be an issue in practice? Locally, being able to compare timestamps to nanosecond precision is very useful. For files obtained over the network or from encrypted archives, sub-second precision is less likely to be crucial. And if we’re all still around in 50 years, fixing the 32-bit timestamp issue is going to have much bigger consequences than this subpacket. I see no advantage in specifying a novel wire format for timestamps unless it’s going to be used everywhere.

> - No other metadata is possible (e.g. what about MIME type?
>   filesystem ownership or permissions? extended attributes?)

The lack of some of that metadata could be considered a feature. It might not be a good idea for a decrypted file to automatically have its executable bit set, for example. At least when you unpack a tgz file the possibility of executable files is already expected…!

> Clearly, it's there to echo the fields in the literal data packet, but
> those fields share the same inadequacies.  But the most important
> security outcome of this draft is that receiving implementation MUST
> ignore the baked in metadata information on its own; either ignore it
> entirely, or ignore it in favor of this new metadata field.

The draft directly echoes the fields in the literal data packet because it is intended to provide a drop-in replacement for those workflows that currently rely on them.

> But at that point, why bother?  Just sign or encrypt one of those
> archive formats directly, and leave it out of the OpenPGP layer!

Requiring applications (or users) wrap single files in an otherwise unnecessary archive layer to achieve the same functionality that they previously got for free (even if insecurely) feels like a kludgy and expensive solution to a relatively minor problem - and it is not a drop-in replacement for existing workflows. If you are writing a greenfield application that has stricter requirements, for example nanosecond precision, using an archive layer is still possible, and we should probably RECOMMEND it.

A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 833 B)