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

Aron Wussler <[email protected]> Tue, 27 Jan 2026 18:09:52 +0000

Newsgroups	gmane.ietf.openpgp
Message-ID	<uLItWhgCyWQ0eoIRDKO3fihOZKzqDlyiQ215SwKPYwCg1kT-gU4HSxPwJslaE3Vc3BBMrdINAhwpoJbui_Gr3h07fPhbfYtjkNwPMrKwaas=@wussler.it>

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 <[email protected]> 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 -- [email protected]
> > > To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

openpgp_pqc.patch (text/x-patch, 1.1 KB)

diff --git a/draft-ietf-openpgp-pqc.md b/draft-ietf-openpgp-pqc.md
index 18e01b8..01ad47e 100644
--- a/draft-ietf-openpgp-pqc.md
+++ b/draft-ietf-openpgp-pqc.md
@@ -627,7 +627,7 @@ The algorithm-specific fields consist of the output of the encryption procedure
  - The wrapped session key represented as an octet string.
 
 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.
+Instead, it is prepended to the wrapped session key in plaintext and its length is included in the preceding length field.
 In the case of v3 PKESK packets for ML-KEM composite schemes, the symmetric algorithm used MUST be AES-128, AES-192 or AES-256 (algorithm ID 7, 8 or 9).
 
 In the case of a v3 PKESK, a receiving implementation MUST check if the length of the unwrapped symmetric key matches the symmetric algorithm identifier, and abort if this is not the case.

signature.asc (application/pgp-signature, 343 B)