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.
S pozdravem, *Filip Skokan* On Tue, 2 Dec 2025 at 08:01, tirumal reddy <[email protected]> wrote: > 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 > On Tue, 2 Dec 2025 at 12:17, Filip Skokan <[email protected]> wrote: > >> 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]
