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 <https://www.ietf.org/archive/id/draft-ietf-hpke-pq-03.html> 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 <https://www.ietf.org/archive/id/draft-ietf-hpke-pq-03.html#name-updated-ml-kem-kem-entries> . S pozdravem, *Filip Skokan* On Tue, 2 Dec 2025 at 07:28, tirumal reddy <[email protected]> wrote: > 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: > >> Option 1 - AKP >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Thu, 13 Nov 2025 at 08:51, tirumal reddy <[email protected]> wrote: >> >>> Hi WG members, >>> >>> Following the presentation at IETF 124 in Montreal (slides >>> <https://datatracker.ietf.org/meeting/124/materials/slides-124-jose-pq-kems-for-cose-and-jose-00>), >>> 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: >>> >>> 1. >>> >>> *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. >>> 2. >>> >>> *OKP (Octet Key Pair)* >>> - >>> >>> Defined in RFC 8037 and allows reuse of the same key in both >>> modes. However, the use of “crv” for PQC KEMs is semantically >>> confusing, as >>> the construct is tied to elliptic-curve terminology. >>> 3. >>> >>> *New “KEM” Key Type* >>> - >>> >>> Proposed in PR #20 >>> <https://github.com/tireddy2/PQC_JOSE_COSE/pull/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] >>> >>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
