[openpgp] Re: Small correction for draft-ietf-openpgp-pqc

[Aron Wussler <[e-mail]>]

Hey Paul,

Section
4.3.1.  Public Key Encrypted Session Key Packets (Packet Type ID 1)

Original Text
-------------
Instead, it is placed in plaintext after the `mlkemCipherText` and before the length octet preceding the wrapped session key.

Corrected Text
--------------
Instead, it is prepended to the wrapped session key in plaintext and its length is included in the preceding length field.

--------------

I've also attached the git diff for the change we propose.

How do we get this to the editor?

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Tuesday, 27 January 2026 at 16:11, Paul Wouters <paul=[e-mail]> wrote:

> On Tue, 27 Jan 2026, Johannes Roth wrote:
>
> > I have created a PR [1] to fix the description in the PQC draft and we will
> > release a new version soon.
>
>
> As the document is now with the RFC Editor, I would recommend not
> releasing a new version, as they will have to go back and do extra
> work. It is best to have a textual fixup eg with CURRENT and NEW
> markers that we can send to the RFC Editor.
>
> Paul
>
> > Thanks for catching the error!
> >
> > Best,
> > Johannes
> >
> > [1] https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/266
> >
> > On 26.01.2026 14:02, Daniel Kahn Gillmor wrote:
> >
> > > On Mon 2026-01-26 09:54:05 +0000, Daniel Huigens wrote:
> > >
> > > > Apologies for the last minute (last second?) comment, but there's a
> > > > small error in Section 4.3.1 of draft-ietf-openpgp-pqc, which states:
> > > >
> > > > > Note that like in the case of the algorithms X25519 and X448 specified
> > > > > in [RFC9580], for the ML-KEM composite schemes, in the case of a v3
> > > > > PKESK packet, the symmetric algorithm identifier is not encrypted.
> > > > > Instead, it is placed in plaintext after the mlkemCipherText and
> > > > > before the length octet preceding the wrapped session key.
> > > >
> > > > However, according to the preceding list and the test vectors, and more
> > > > in line with X25519 and X448, the symmetric algorithm ID is placed
> > > > after the length octet (and included in that length).
> > > >
> > > > The proposed additions to the IANA registry also place the octet
> > > > correctly, which actually is not true for RFC9580, which failed to
> > > > include it in the table (mea culpa for that one, I'll file an erratum).
> > >
> > > Thanks for catching this! Please propose concrete text to be
> > > incorporated during the RFC Editor's phase, and file that erratum.
> > > We'll get it sorted.
> > >
> > > --dkg
> > >
> > > _______________________________________________
> > > openpgp mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]