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]

Reply via email to