Reading new key packages (Re: Coexistence with OpenPGP/IETF)

Heiko Schäfer heiko at schaefer.name
Sun Jan 7 02:52:27 CET 2024


On 1/6/24 14:47, Werner Koch wrote:
> On Fri,  5 Jan 2024 23:18, Heiko Schäfer said:
>
>> How common is the use case of having meaningful metadata for a literal
>> data packet?
> The major problem here is the one of surprise: You get a report that the
> data has been signed and the report also shows the file name as meta
> information.  It is entirely counter-intuitive that the file name is not
> covered by the signature.  It is further hard to explain in a report that
> one can't rely on the file name or its creation date.
>
> Yes, there are real world scenarios.  The use cases come from scenarios
> where existing systems are secured by digital signatures or encryption.
> Sometimes for messages which are valid only for a few minutes and where
> MitM are a real concern due to broadcasting, dead zones, and relaying.

Right, that all makes sense to me, thanks! It seems to me that everyone 
agrees there should be a mechanism to secure this metadata, when it is set.
But clearly there are currently multiple ideas for how best to address 
this problem.

I think Andrew is trying to figure out which paths exist to avoid 
redundant mechanisms between *PGP flavors, and I'd also very much like 
to see this happen.

As you pointed out, the crypto-refresh draft doesn't currently define a 
mechanism for securing literal metadata (presumably because this was not 
covered by the charter). However, discussion on the IETF list [1] seems 
to indicate that after rechartering, a mechanism will be worked on.

Do you see room for adjusting/aligning the LibrePGP draft to be 
wire-format compatible, as the WG specifies an approach for literal 
packet metadata? That would seem like a big step towards removing 
complexity between the drafts.

Thanks!
Heiko


[1]: 
https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE/



More information about the LibrePGP-discuss mailing list