Tiru, I am in favor of option 1 (AKP) because it is consistent and to me the most understandable.
You say in your description “a key cannot be reused” but that is somewhat vague, it does not distinguish between the key material and the COSE_Key object. COSE_Key is about external representation of these data. If an implementation or user chooses to internally represent things differently that is fine. And if a use case requires multiple logical COSE_Key containing the same `pub`/`priv` key material (and same `kid`) with different `alg` I think that is also fine, and consistent with all current definitions (even `kid` is not required to be unique within an entity or domain per RFC 9052). I’m sure there are edge cases to this, but I don’t see a problem with using AKP. Brian S. From: tirumal reddy <[email protected]> Sent: Thursday, November 13, 2025 2:50 AM To: JOSE WG <[email protected]>; cose <[email protected]> Subject: [EXT] [COSE] Selecting Key Type for PQC KEMs 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: o "kty": "KEM" o "kem_param": <PQC KEM algorithm> o "pub": <public key> o "priv": <private key, optional> o "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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
