Summary

  • An OpenPGP Working Group Last Call on eight composite post-quantum algorithms was scheduled to close on 9 September 2026. The document remains an active Internet-Draft intended as Informational; the date alone does not establish a Last Call result or IETF approval.
  • Revision 04 uses experimental identifiers 100–107. A working branch and implementation work use proposed values 37–44, while the captured IANA registry still shows 37–99 as unassigned.
  • The identifier is an input to the composite KEM key-combining function. Renumbering therefore changes the derived key-encryption key, wrapped session-key material and test vectors; signature packet values also change fingerprints and related artifacts.
  • Every interoperability result should carry an algorithm-state receipt that identifies the draft revision, registry state, branch commit, vector hash, implementation build and exact number used.

The Working Group Last Call opened on 19 August and requested comments by 9 September. That deadline marks a review window, not a verdict. The current Datatracker record still describes draft-ietf-openpgp-nist-bp-comp as an active Internet-Draft in WG Last Call, with IESG state I-D Exists. The revision history records process movement, but no shepherd, responsible Area Director or telechat is shown in the captured record. Its intended status is Informational.

The document’s purpose is practical: specify combinations of NIST post-quantum algorithms with established elliptic-curve algorithms for OpenPGP. Revision 04 assigns four composite KEM choices and four composite signature choices the values 100 through 107. Each is optional. The same text classifies those numbers as experimental and says private or experimental points are for non-released software and interoperability experiments. Formal releases must not use them. It also says the document will not be sent to IANA until every listed algorithm has a non-experimental identifier.

That creates a normal standards transition with an unusual operational consequence. A working-group proposal lays out permanent-looking values 37 through 44. Daniel Kahn Gillmor’s reply calls the arrangement plausible while telling implementers to continue with experimental identifiers until a released draft actually carries non-experimental ones. That advice keeps the released specification and released software aligned while editors test the next state.

The repository has already moved further. GitHub pull request 50 is open, not a draft and not merged in the captured API response. Its head commit is 577adce5255e7382e5d4b0c9e52be626deb77126; it changes the eight values from 100–107 to 37–44 and regenerates fingerprints, KEM outputs and test vectors across 27 files. An author message announces vectors using what it calls the “assigned” codepoints. An rPGP report says the implementation was updated to 37–44 and agrees with the NIST vectors, while the interoperability-suite update is waiting for confirmation.

That wait is visible in GitLab merge request 255. It is open, marked draft and unmerged; its description says it should not merge before the codepoints are officially assigned. This is not inactivity. It is a deliberate boundary between useful branch-level evidence and a shared test suite that other implementers may treat as authoritative.

The number enters the computation

Why regenerate so much material for a number change? In the composite KEM procedure, the implementation parses the public-key algorithm identifier from the key packet and passes it as algId into multiKeyCombine. The resulting key-encryption key wraps the session-key material. Replace 100 with 37, for example, and that input changes. A recipient using the old identifier will not reproduce the same wrapping key as a sender using the new one, even when the component ML-KEM and ECDH values are otherwise the same.

For the signature combinations, the algorithm value also appears in OpenPGP key packets. A different packet encoding changes the bytes over which fingerprints and other reproducible artifacts are calculated. The mathematical definitions of ML-KEM, ECDH and the signature primitives have not been rewritten. Their OpenPGP binding has. The regenerated vectors are evidence of that distinction.

Three states are simultaneously true

The public IANA OpenPGP registry, captured with a last-updated date of 2 July 2026, lists values 35 and 36 for RFC 9980. It lists 37–99 as Unassigned and 100–110 as Private or Experimental Use. Against that record, “assigned” in a developer message describes an anticipated or working state, not the current public registry state.

RFC 9580 provides the modern OpenPGP packet and registry framework. RFC 8126 explains the policy vocabulary used around registries. Together they make the boundary legible: a plausible allocation, an editor’s branch, an implementation branch and an IANA row are different governance facts. Registration does not certify an algorithm’s security, require deployment or declare a production release ready. Conversely, an unassigned row does not erase laboratory interoperability work; it limits what that work can honestly claim about its identifier state.

Give each result a state receipt

The durable remedy is small. Every vector bundle, interoperability result and implementation claim should name the document revision and standards state; the experimental identifier in the released draft; any proposed identifier in a branch; the PR or MR state and exact commit; the live registry row and observed update time; the vector commit and hash; the implementation build; the exact identifier exercised; and whether the draft permits formal release with it.

Call that an algorithm-state receipt. It does not decide whether 37–44 are good allocations. It makes the transition auditable. A tester can reproduce an apparent mismatch without guessing whether the peer used revision 04, PR 50 or a later registry-backed draft. A release manager can distinguish “cryptographically interoperable in a branch” from “eligible for a formal release under the cited document.” An archive can retain the old vectors as valid evidence about the old experimental state instead of silently overwriting them.

Sources