Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Andrew Gallagher <andrewg@andrewg.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 26 Oct 2026 12:36:06 +0000
Message-Id: <86B3DB48-79F3-43E7-8696-53DCBC519E56@andrewg.com>
References: 
 <SY9P300MB881477C78D3D07FE72D736AC75EE612@SY9P300MB881477.AUSP300.PROD.OUTLOOK.COM>
In-Reply-To: 
 <SY9P300MB881477C78D3D07FE72D736AC75EE612@SY9P300MB881477.AUSP300.PROD.OUTLOOK.COM>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID-Hash: 4AJ6ETE6YWDR6LYJAJZPLKDUP2B56QZB
CC: openpgp@ietf.org
Precedence: list
Subject: [openpgp] Re: OpenPGP grammar concerns (fwd: [Peter Gutmann] Re:
 [oss-security] Retrospective by 'gpg.fail' authors)
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/SvMnKki8_SwhulE9Og9mtMtKkX4>

On 26 Oct 2026, at 01:52, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>=20
> =EF=BB=BFAndrew Gallagher <andrewg@andrewg.com> writes:
>=20
>> That's exactly what PGP does, there's no second encapsulation on this lev=
el.
>> The literal data packet is inside the decrypted cleartext.
>=20
> No, it's not what PGP does.  With CMS the packaging is:
>=20
>  Sign( data )
>=20
> With PGP it's:
>=20
>  Sign( Literal( data ) )

This is quite far removed from how the packets appear on the wire though, an=
d if we=E2=80=99re viewing it on a higher level of API abstraction it=E2=80=99=
s just as valid to view it as (say) =E2=80=9CSignLiteral( data )=E2=80=9D an=
d abstract away the fact that there is a literal packet in there.

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

I=E2=80=99m struggling to see what the practical difference would be. There=E2=
=80=99s still a leading length parameter, followed by a data stream. That=E2=
=80=99s 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 f=
ield inside the OPS packet rather than a length-prefixed packet. But then yo=
u 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 tha=
n remove one.

A slightly better (but equivalent) design would be an OPS packet that contai=
ned the signed data but didn=E2=80=99t have an explicit length for it, letti=
ng it extend to the end of the OPS packet itself. But in this scenario you w=
ould also need to know where the signed data started, particularly in the mu=
lti-signature case, so you would still need some way of determining the leng=
th of the metadata part of the OPS packet - and the easiest way to do this i=
s a length parameter. So we still have the same number of length parameters a=
s the spec, just in different places and covering different things.

You could conceivably reduce the number of length parameters by relying on t=
he OPS packet having a known internal structure and omitting its packet fram=
ing. But this sacrifices forward compatibility - you can=E2=80=99t then do n=
ice things like signing over the same data with both a v4 and v6 key if lega=
cy code doesn=E2=80=99t know the structure (and therefore the length) of a v=
6 OPS packet.

So yes, some of the length prefixes in PGP may seem redundant if you assume t=
here is no need for forward compatibility. But the vast majority of length p=
refixes in PGP are there because we cannot assume that objects have fixed si=
zes, 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 exis=
ted.

I stand corrected. My knowledge of BER is limited.

A=