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

Daniel Huigens <d.huigens@protonmail.com> Mon, 26 January 2026 09:54 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6F46BACFE60A for <openpgp@mail2.ietf.org>; Mon, 26 Jan 2026 01:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY1ieI92FX65 for <openpgp@mail2.ietf.org>; Mon, 26 Jan 2026 01:54:18 -0800 (PST)
Received: from mail-106119.protonmail.ch (mail-106119.protonmail.ch [79.135.106.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0AABFACFE605 for <openpgp@ietf.org>; Mon, 26 Jan 2026 01:54:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1769421250; x=1769680450; bh=xgx1dfGvqg8JBfHLnrdRzvY25zg0N7z4xX679KPQIno=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=WwxmCCnMalabisXJ6+vksBkyirwhx3wfBJysnRdk2GQP+xD8396g2SQV/yJv0zIeX 0jppJY8pZj27oPA737yacW2qezukIEZ9aVSrr+KlAim4UyJRBX6eNgm/3dd8SBWpGT LPWbNTzsB07YCdAcIGlLqsZy7H8uIWfogXPlwKZ60SBK9hw2U71ZPTJ+nqU+6/BAT1 sWkb23Sw2nmq1GVwG0l7m7uCkFFpVHZTBvXR+X+AptJQJQqkyHRpwa31Fhijx5tei8 SYVlih/79vjKC2FRzA75QTmpAE0W5RrOJd7EjZc8OVhvYXMHjgJZWznNSyVQVKeYba YoerqcZ4/bixA==
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
X-Pm-Message-ID: c8b465529a757f4d7db9e63256f3f3cafb9023c1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: QTYF5OZNKTF4IBK5U5XYWM222X2XFSEA
X-Message-ID-Hash: QTYF5OZNKTF4IBK5U5XYWM222X2XFSEA
X-MailFrom: d.huigens@protonmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Small correction for draft-ietf-openpgp-pqc
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/KEBlD6t9RcO3NIHb4S7y0ZwDbn0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

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