Date: Mon, 26 Jan 2026 09:54:05 +0000
To: IETF OpenPGP WG <openpgp@ietf.org>
From: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: 
 <KkQYkRhj-jf9WzOzUPCANDTYaYYGgWDJY27bnZl2GOe19_mgrFIO9-TmYwX_kYVE3KDP7OagceEdDhVgRBYG55fbsKmFGFKDIhhjm9QNGYg=@protonmail.com>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: QTYF5OZNKTF4IBK5U5XYWM222X2XFSEA
Precedence: list
Subject: =?utf-8?q?=5Bopenpgp=5D_Small_correction_for_draft-ietf-openpgp-pqc?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/KEBlD6t9RcO3NIHb4S7y0ZwDbn0>

Hi all,

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).

Best,
Daniel