[openpgp] Re: OpenPGP grammar concerns (fwd: [Peter Gutmann] Re: [oss-security] Retrospective by 'gpg.fail' authors)

[Andrew Gallagher <[e-mail]>]

On 26 Oct 2026, at 01:52, Peter Gutmann <[e-mail]> wrote:
> 
> Andrew Gallagher <[e-mail]> writes:
> 
>> That's exactly what PGP does, there's no second encapsulation on this level.
>> The literal data packet is inside the decrypted cleartext.
> 
> No, it's not what PGP does.  With CMS the packaging is:
> 
>  Sign( data )
> 
> With PGP it's:
> 
>  Sign( Literal( data ) )

This is quite far removed from how the packets appear on the wire though, and if we’re viewing it on a higher level of API abstraction it’s just as valid to view it as (say) “SignLiteral( data )” and abstract away the fact that there is a literal packet in there.

> with a completely unnecessary double-encapsulation of the data.  All you need
> to do is change the Sign() to include a length and you can do away with the
> unnecessary double-encapsulation.

I’m struggling to see what the practical difference would be. There’s still a leading length parameter, followed by a data stream. That’s equivalent to an encapsulation format, just with the length prefixes moved around a little.

To take a counterfactual, the data stream could have been a length-prefixed field inside the OPS packet rather than a length-prefixed packet. But then you would have a length encoding of the OPS packet that included the length of the data stream, which would add one more nested length encoding rather than remove one.

A slightly better (but equivalent) design would be an OPS packet that contained the signed data but didn’t have an explicit length for it, letting it extend to the end of the OPS packet itself. But in this scenario you would also need to know where the signed data started, particularly in the multi-signature case, so you would still need some way of determining the length of the metadata part of the OPS packet - and the easiest way to do this is a length parameter. So we still have the same number of length parameters as the spec, just in different places and covering different things.

You could conceivably reduce the number of length parameters by relying on the OPS packet having a known internal structure and omitting its packet framing. But this sacrifices forward compatibility - you can’t then do nice things like signing over the same data with both a v4 and v6 key if legacy code doesn’t know the structure (and therefore the length) of a v6 OPS packet.

So yes, some of the length prefixes in PGP may seem redundant if you assume there is no need for forward compatibility. But the vast majority of length prefixes in PGP are there because we cannot assume that objects have fixed sizes, and parsers need to be able to gracefully ignore stuff from the future.

> CMS supports streaming data, and has (via ASN.1 BER) since before PGP existed.

I stand corrected. My knowledge of BER is limited.

A