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