Summary

  • Revision 05 of draft-ietf-openpgp-nist-bp-comp says experimental identifiers 100–107 were replaced by assigned identifiers 37–44. The IANA OpenPGP Public Key Algorithms registry retrieved on 1 October 2026 still showed 37–99 as unassigned. That is a time-bounded authority mismatch, not evidence of assignment, refusal or implementation support.
  • The proposal makes every composite algorithm optional. A recognized identifier is therefore only the beginning of the proof: a receiver must bind the correct v6 object, parse fixed component lengths, validate attacker-controlled elliptic-curve points, execute both cryptographic components and apply local policy.
  • For signatures, ECDSA and ML-DSA must pass. For the composite KEM, both ECDH and ML-KEM contribute to the combiner before AES-256 key unwrap. One green component, one reproduced vector or one successful application action cannot stand in for the complete chain.

The two documents did not yet describe one namespace

The change log for draft-ietf-openpgp-nist-bp-comp-05 makes a crisp revision claim: experimental public-key algorithm identifiers 100–107 were replaced with identifiers 37–44, described there as assigned. The revision also regenerated fingerprints, KEM intermediates and other vectors around the new values, and added detached-signature vectors for all four proposed signature constructions. Its HTML rendering and XML source expose the same mechanism.

The frozen OpenPGP Parameters registry did not yet tell the same story. It listed the public-key algorithms standardized by RFC 9580 and RFC 9980 through value 36, then marked 37–99 unassigned. That observation is dated. A later registry view may differ. It is also deliberately silent about cause: the available public evidence does not establish whether an allocation was pending, the registry update lagged, the draft text anticipated a decision, or another process state applied.

This is precisely why a code point should be retained with its authority receipt. A parser can accept the octet 37. A draft can define what 37 is meant to mean. A test corpus can label an object 37. None of those acts alone gives every counterparty a common, registry-backed interpretation. The operating record should therefore include the registry URL and retrieval time, the draft revision and hash, the object’s algorithm identifier and the implementation version that interpreted it.

The Datatracker record reinforces the need for restraint. As frozen for this research, the document was an active OpenPGP working-group Internet-Draft dated 24 September 2026 and expiring 28 March 2027. The document API carried no intended RFC status, while the header called the document Informational. The history recorded the working-group state as waiting for chair go-ahead with a revised draft needed. It was not an RFC or an approved standard.

Eight identifiers describe eight constructions, not eight deployments

The proposal divides cleanly into four composite KEMs and four composite signatures. Values 37 and 38 pair ML-KEM-768 or ML-KEM-1024 with ECDH on NIST P-384 or P-521. Values 39 and 40 pair the same ML-KEM levels with Brainpool P-384 or P-512. Values 41 through 44 make the analogous signature pairings: ML-DSA-65 or ML-DSA-87 with ECDSA on the NIST or Brainpool curves.

That list is useful because an identifier fixes component choices and artifact sizes. It is not a support declaration. Every algorithm is specified as MAY. A library may implement none, one or several. A product may contain code without enabling it. A policy may permit signatures but not encryption, or one curve family but not the other. A key store may reject version 6 objects even when its packet parser recognizes the new number.

The draft limits the proposed algorithms to version 6 or newer keys and certificates. Composite signatures likewise require version 6 or newer signatures and a digest of at least 256 bits. Those bindings matter: reporting only “algorithm 43 verified” drops the object version and digest constraints that make 43 meaningful in this proposal. The receipt needs the packet and key versions, exact algorithm identifier, digest algorithm and size, component lengths, parser build and disposition.

RFC 9580 supplies the current OpenPGP packet, key and signature architecture. RFC 9980 adds ML-KEM and ML-DSA algorithms and the multi-key combiner used here. The new draft composes those primitives with traditional elliptic-curve components. It does not turn optional composition into a universal OpenPGP capability.

A composite KEM is an execution chain

For encryption, the receiver’s composite public key contains an ECDH point and an ML-KEM encapsulation key. The sender must run both paths. It performs ECDH, encapsulates to ML-KEM, and passes both shared-secret contributions—together with the ECDH ciphertext, ECDH public key and algorithm identifier—into RFC 9980’s multiKeyCombine. The resulting key-encryption key wraps the session key with AES-256 key wrap.

Decryption reverses more than one mathematical operation. The implementation must match the PKESK algorithm identifier to the local secret-key algorithm, parse algorithm-specific fixed lengths, decapsulate both components, reconstruct the combiner context, unwrap the session key and abort if the 64-bit AES key-wrap integrity check fails. With a version 3 PKESK, the symmetric algorithm identifier remains outside the wrapped value, so the receiver must also compare the unwrapped key length with that algorithm and reject a mismatch.

FIPS 203 defines ML-KEM, while SP 800-56A Revision 3 provides the traditional elliptic-curve key-establishment context. Their coexistence in one identifier does not erase their separate execution. An unwrap success is downstream evidence, but it cannot by itself say whether a parser silently skipped a field, whether both decapsulations executed or which combiner context was used. Those are facts for a bounded KEM receipt.

This article is not revisiting the separate recipient-set question already governed by RFC 9980. It asks what must be shown inside one proposed NIST/Brainpool composite algorithm. A message encrypted to a mixture of recipients raises another proof boundary. Here, the narrower issue is whether one composite PKESK was interpreted and executed as specified.

The curve point must be proved before the secret scalar touches it

Revision 04 added a security boundary that can disappear in a high-level success metric. The NIST and Brainpool curves used by the proposal are short-Weierstrass curves. Any elliptic-curve point received from an attacker must be fully validated before secret-scalar multiplication.

During encapsulation, that means validating the recipient’s ECDH public-key point. During decapsulation, it means validating the ephemeral ECDH ciphertext point. The checks establish that the point is not at infinity, that both coordinates lie in the field and that the point satisfies the curve equation. Failure requires abort. The draft warns that multiplying a secret scalar by an off-curve attacker-controlled point can enable an invalid-curve attack and recovery of the ECDH secret key.

The curve definitions and validation context are not invented by the draft. FIPS 186-5 covers the Digital Signature Standard, SP 800-186 specifies recommended elliptic curves, RFC 5639 describes Brainpool curves for the Internet, and SEC 1 version 2 sets out elliptic-curve cryptography and public-key validation. A packet whose fields have the expected length has not thereby passed those checks.

That makes EC validation a separate receipt field, not an inferred property of a later unwrap. Record which point was checked, against which curve and validation routine, in which implementation build, and whether each predicate passed. Do not log the secret. Do preserve enough identity to distinguish “the packet parsed” from “the hostile mathematical input was accepted as a member of the intended group.”

A composite signature has an AND gate, not a preferred path

The four signature constructions concatenate an ECDSA result with an ML-DSA result over the OpenPGP data digest. The verifier must validate both. ECDSA success plus an unsupported ML-DSA component is not a composite success. ML-DSA success plus malformed ECDSA is not a composite success. A policy engine that stops after its familiar component has changed the proposition being verified.

Parsing is part of that boundary. ECDSA’s fixed R and S lengths depend on the selected curve. The ML-DSA signature is 3,309 octets for ML-DSA-65 or 4,627 octets for ML-DSA-87. The digest must be at least 256 bits. FIPS 204 defines ML-DSA. RFC 9794 provides broader terminology for hybrid post-quantum and traditional schemes. Neither source authorizes a verifier to convert one component verdict into the compound verdict.

Revision 05’s detached-signature vectors are valuable. They let developers reproduce the specified encodings and intermediate results. But a reproduced vector does not identify the signer of a production object, prove authorization, establish key provenance or show that an application accepted the intended content. A serious verification record keeps the data digest, digest algorithm, ECDSA verdict, ML-DSA verdict, composite AND result, key fingerprint, signer policy and application decision as different fields.

Test vectors are specification evidence, not a fleet census

The regenerated vectors show how the current revision expects its bytes and computations to line up. They can catch incompatible encoders, length mistakes, incorrect labels and combiner inputs. Negative and malformed vectors can show that an implementation fails safely. They cannot show which versions are deployed, which optional algorithms are enabled, whether hardware paths apply the same validation, or whether an old client interprets an identifier differently.

That distinction becomes critical during a code-point transition. A rollback from a build that recognizes 37–44 to one that does not must fail visibly. It must not reinterpret a packet, fall through to a different algorithm or report a generic success around an opaque object. Likewise, a mixed fleet needs telemetry that distinguishes unsupported algorithm, wrong object version, length failure, EC-point validation failure, component failure, unwrap-integrity failure and policy rejection. “OpenPGP error” is not enough to govern a migration.

No source examined for this article establishes a named implementation, deployment, interoperability event, packet capture, attack, incident, performance result or adoption rate. The proposal may change. The registry may update. Products may implement only a subset or none. The value of the current mismatch is not scandal; it is a practical demonstration that a draft label, a registry fact and a runtime fact occupy different layers.

Sources and evidentiary limits

The protocol analysis uses the current draft artifacts and status sources linked above, alongside the relevant OpenPGP RFCs and NIST/elliptic-curve publications. No private implementation data was used. The frozen evidence says what the draft proposed and what the public registry displayed on the retrieval date. It does not prove IANA action or inaction beyond that display, and it does not prove any product’s behaviour.