Sounds like a problem caused by “fully-specified” algorithms to me. With JWE HPKE, we already need 2 (Integrated and Key Encryption). But with AKP, because alg includes KEM + KDF + AEAD, the same KEM key would require many key objects. For example, with 3 KDFs and 2 AEADs, that becomes 6 representations instead of 2. That extra proliferation is what I want to avoid.
-Tiru This is exactly the same side of the coin we've been through with PQ KEMs, just in different words. The argument and its outcome doesn't change just because the "alg" in HPKE is fully specified. The outcome shouldn't be any different just because the argument gets re-stated.
My concern with using AKP is how the "alg" parameter works. In HPKE, "alg" includes the KEM, the KDF, and the AEAD. If we use AKP, the same KEM key would need multiple COSE/JOSE key objects just because the KDF or AEAD changes. This does not make sense, because the KEM key is independent of those choices. This is why I do not want to use AKP: the key should not appear to change simply because the selected KDF or AEAD changes. A KEM key should be represented independently of the full HPKE algorithm identifier. -Tiru Hello Tiru,
> PQ/T HPKE for JWE will be updated to use the "OKP" key type, consistent with existing HPKE usage in JWE.
Can you please elaborate? Existing OKP/EC registrations cannot be used to represent the draft-ietf-hpke-pq-03 keys, not their public composite component, nor the private seed component. No P-256/P-384/X25519 JWK parser could deal with those values if they were OKP. AKP is perfectly fitting for this. OKP is not.
Define the HPKE-X(-KE) algs, say they use AKP, pub is the result of HPKE's SerializePublicKey in base64url, priv is the result of HPKE's SerializePrivateKey in base64url. And it's matching the AKP pub/priv that we'll end up with for PQC KEMs if you also chose to register HPKE algs with the HPKE ML-KEM KEM entries.
Based on the clear consensus, I will update the draft text to reflect the decision to use AKP. The draft already discusses AKP, and the upcoming revision will make this choice more clear. This consensus applies only to PQC KEMs; PQ/T HPKE for JWE will be updated to use the "OKP" key type, consistent with existing HPKE usage in JWE. -Tiru On Mon, 17 Nov 2025 at 17:38, Filip Skokan <[email protected]> wrote:
Hi WG members,
Following the presentation at IETF 124 in Montreal (slides), we would like to seek the WG input on the choice of key type for representing PQC KEM keys in COSE and JOSE for https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/.
Listing the three options below:
-
AKP (Asymmetric Key Pair)
-
Defined in ietf-cose-dilithium. Requires the “alg” parameter and enforces strict one-algorithm usage, in line with NIST SP 800-57 guidance.
-
This becomes restrictive since a key cannot be reused across direct key agreement and KEM with key wrapping modes. For PQ/T HPKE, it leads to multiple keys per AEAD.
-
OKP (Octet Key Pair)
-
New “KEM” Key Type
-
Proposed in PR #20.
-
Purpose-built for PQC KEMs with the structure:
"kty": "KEM"
"kem_param": <PQC KEM algorithm>
"pub": <public key>
"priv": <private key, optional>
"alg": <optional JOSE algorithm>
-
This approach avoids the semantic overload of OKP and the restrictive coupling of AKP, while maintaining flexibility by making "alg" optional and clear PQC alignment.
We invite the WG to review the above options and share opinions on which direction to pursue. Reaching consensus on this will allow us to finalize the key representation and progress the draft.
-Tiru
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
|
