Re: [openpgp] Hashing literal (meta)data fields

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2022-10-12 08:04:35 +0000, Daniel Huigens wrote:
> On Wednesday, October 12th, 2022 at 09:14, Daniel Kahn Gillmor wrote:
>
>> With no hats on, I am not convinced that the proposed hashed literal
>> data meta packet solves any of these points.
>
>> it clearly doesn't address (1) or (2),
>
> I tried to describe in my original email how it could address (2).
> Could you elaborate on why you think it doesn't? :')

aiui, your suggestion of how it matches it would work requires ignoring
this field for detached signatures.  But that means it isn't
round-trippable:  if you detach and then reattach the signature, you've
lost the metadata and the reattached signature will now fail.

That is a subtly ugly property that seems likely to cause mystifying
failures.  Not a great thing to bake into the standard.

> (Though, if we all think that notations are better and do address it,
> the point is a bit moot.)

fair :)

>> and for (3), it only makes it
>> possible to add this metadata to v4 signatures, but of course it's not
>> guaranteed that it'll be there. What should a consuming implementation
>> do that wants to use these fields?
>
> I think this is a bit inherent in protecting some fields that previously
> weren't protected. There's no backwards compatible way to add this that
> guarantees it's there, since it currently isn't - but I don't think
> that's a very strong argument against doing it. Anyway, the concrete
> guidance could be to only rely on these fields if this subpacket is
> there - and similarly, in the case of notations, the guidance could
> just be to only rely on those notation fields (if any), and not on the
> literal data packet metadata fields.
>
> One thing to note is that to fully replicate the original proposal,
> we would also need a notation field for the data format (binary, text,
> etc.) I'm not sure how important that is, but - doing so might raise
> questions about what to do if they don't match, etc. For the filename
> and date fields, I suppose the notations would trump the literal data
> packet fields, so that the latter can be left blank - but the data
> format field can't be left blank, so there we should probably say that
> they must match, if we do add a notation for it.

Even simpler guidance about the metadata fields in the literal data
packet is: "when generating, never populate; when consuming, always
ignore" (this is what crypto-refresh says, fwiw).  Then if we want to
introduce any notations which contain any metadata, we can just define
them orthogonally to anything in the literal data packet.

This seems simple, clear and unambiguous.  Implementers that want to do
something with that data can just work directly with the notation.

          --dkg