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

[Nickolay Olshevsky]

Hi Andrew,

Sorry, somehow missed that draft (it's easy to miss things at Jan, 2).

As for me it looks good as would solve problems brought up in the list 
(however, I doubt whether those problems are real).


On 08.01.2024 19:25, Andrew Gallagher wrote:
> 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
>
-- 
   Best regards,
   Nickolay Olshevsky
   o.nickolay at gmail.com