[openpgp] Re: Problem in RFC 9580

[Andrew Gallagher <[e-mail]>]

On 20/07/2026 13:11, Peter Gutmann wrote:
> I was reading RFC 9580 and noticed this arbitrary requirement that's been
> quietly added to section 3.2 on MPIs, which I hadn't looked at before because
> MPIs haven't changed for over 30 years (40 years if you start counting from
> Phil's original design of MPIs):
> 
>    When parsing an MPI in a version 6 Key, Signature, or Public Key Encrypted
>    Session Key (PKESK) packet, the implementation MUST check that the encoded
>    length matches the length starting from the most significant non-zero bit;
>    if it doesn't match, reject the packet as malformed.

Quietly? It was discussed at IETF114:

https://mailarchive.ietf.org/arch/msg/openpgp/05E3ii19CujKjvSLGbv3_pjIdUo/

https://mailarchive.ietf.org/arch/msg/openpgp/x3jmuOynnUnkQECQ7I6dhTwULmQ/

> Why was this added, and what purpose does it serve? 

It ensures that there is only one way to encode an MPI on the wire, and 
it was introduced to prevent the further recurrence of issues where an 
MPI is parsed and reserialised, and the reserialisation breaks the 
signature. GitHub did this to multiple keys.

> Everything in existence
> stores and processes MPIs as byte strings, why is it now necessary to encode
> lengths to the individual-bit level? 

It has always been necessary to encode MPI lengths to the bit level. I 
agree that this design is ridiculous, but it is not new.
> This means that an encoded MPI that's
> been perfectly valid for over 30 (or 40) years is suddenly deemed to be
> invalid if it has a version number of 6 associated with it, which seems crazy.
Such an MPI has *never* been valid. The following text has been in the 
spec since RFC2440 (section 3.2 
https://datatracker.ietf.org/doc/html/rfc2440#section-3.2)

 > The length field of an MPI describes the length starting from its
 > most significant non-zero bit. Thus, the MPI [00 02 01] is not formed
 > correctly. It should be [00 01 01].

An MPI that's been perfectly valid for 30 years can't have a version 
number of 6 associated with it, because version 6 didn't exist 30 years 
ago. The only thing that has changed is that receiving implementations 
are now required (for new v6 artifacts only) to enforce correct MPI 
formatting. This is perfectly backwards-compatible with existing code.

A