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

[Andrew Gallagher]

On 8 Jan 2024, at 11:20, Nickolay Olshevsky <o.nickolay at gmail.com> wrote:
> 
> 5. Yes, however this brought the following discussion, which, as for me, dramatically overcomplicate things:https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE/

I agree, which is why I proposed an alternative format for the Literal Data Meta packet in https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-literal-metadata :

—
The first octet of the subpacket contents indicates the encoding of the subpacket. A value of 0 indicates Hashed encoding, and a value of 1 indicates Verbatim encoding. The remaining octets of the subpacket are encoding-dependent.

…

3.2. Literal Data Meta (Verbatim)

The remainder of the packet contains a verbatim copy of the metadata as specified above. When an implementation has successfully validated a signature containing a Literal Data Meta (Verbatim) subpacket in its hashed-subpackets area, the metadata section of the Literal Data Packet that is signed over MUST be replaced with the copy from the Literal Data Meta subpacket.
—

I believe this addresses the technical concerns raised in the linked discussion. It moves the canonical location of the metadata from the beginning of the Literal Data packet to a signature subpacket, but leaves the content unchanged. As a subpacket in the hashed area, it is automatically protected by the signature, and being a verbatim copy it is lossless (and thus re-attachable), unlike the hashed encoding specified by the current librepgp draft.

Since it is merely a rearrangement of the fields on the wire, nothing should need to be changed at the application layer - the signature either validates, in which case the subpacket metadata is (transparently) returned to the application instead of the literal packet metadata, or it does not, in which case it should be treated like any other verification failure.

(Alternatively, we could put the metadata in a notations subpacket, which would be functionally equivalent but more flexible, and wouldn’t require a new subpacket type)

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240108/22ace290/attachment.sig>