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 On Tue, 2 Dec 2025 at 13:04, Filip Skokan <[email protected]> wrote: > 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]
