I watched the video recordings, and the WG chair decided to continue the
discussion on the mailing list. I'm listing the pros and cons here to
invite further input from the WG:

OKP
===

Pros:

1. Already defined in RFC 8037 and supported by JOSE implementations.
2. Allows flexible alg assignment, the same key can be valid for use in
both modes: Direct key agreement and KEM with key wrapping.

Cons:

1. The opposition to "OKP" has been that it looks odd.  However, RFC 8037
states that it doesn’t imply an elliptic curve.

AKP
===

Defined in draft-ietf-cose-dilithium, AKP is tightly bound to a specific
alg, meaning the key is intended for only one mode.

Cons:

If the same key needs to be usable with multiple alg values (e.g.,
ML-KEM-768 and ML-KEM-768+AES128KW), it must be published multiple times in
the JWK, once for each alg.
This duplication increases operational complexity. Key lifecycle management
must be tracked across multiple JWKs with identical key material.
Each duplicated key requires a distinct kid, adding further overhead.

New Key Type (e.g., KEM)
====================
{
  "kty": "KEM",
  "kem": "ML-KEM-512",
  "pub": "...",
  "priv": "...",
  "alg": "ML-KEM-512+AES128KW" // optional
}


Pros:
=====
1. Similar to "OKP", it avoids the need for key duplication across
different alg values.

Cons:
=====
Existing JOSE/COSE libraries would need to be updated to support it.
Slightly more work in the short term, but offers long-term clarity and
simplicity.

Cheers,
-Tiru

On Thu, 7 Aug 2025 at 17:31, Filip Skokan <panva...@gmail.com> wrote:

> Thank you Tiru,
>
> Please publish a revision that reverts back to using AKP. There was no
> consensus on switching away from AKP in the first place, and the vote that
> was requested on whether to use OKP resulted in a clear "No". I ask that
> you publish with AKP again because the longer a latest draft shows the use
> of OKP the more likely it is that implementations will pick up on it, which
> they shouldn't.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 7 Aug 2025 at 09:15, tirumal reddy <kond...@gmail.com> wrote:
>
>> The revised draft addresses all comments received from the WG, including
>> those raised during the presentation at IETF-123. The only remaining issue
>> is the choice between using "OKP", "AKP", or defining a new key type.
>>
>> Cheers,
>> -Tiru
>>
>> On Thu, 7 Aug 2025 at 12:42, <internet-dra...@ietf.org> wrote:
>>
>>> Internet-Draft draft-ietf-jose-pqc-kem-03.txt is now available. It is a
>>> work
>>> item of the Javascript Object Signing and Encryption (JOSE) WG of the
>>> IETF.
>>>
>>>    Title:   Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE
>>> and COSE
>>>    Authors: Tirumaleswar Reddy
>>>             Aritra Banerjee
>>>             Hannes Tschofenig
>>>    Name:    draft-ietf-jose-pqc-kem-03.txt
>>>    Pages:   23
>>>    Dates:   2025-08-07
>>>
>>> Abstract:
>>>
>>>    This document describes the conventions for using Post-Quantum Key
>>>    Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE.
>>>
>>> About This Document
>>>
>>>    This note is to be removed before publishing as an RFC.
>>>
>>>    Status information for this document may be found at
>>>    https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/.
>>>
>>>    Discussion of this document takes place on the jose Working Group
>>>    mailing list (mailto:jose@ietf.org), which is archived at
>>>    https://mailarchive.ietf.org/arch/browse/cose/.  Subscribe at
>>>    https://www.ietf.org/mailman/listinfo/jose/.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-jose-pqc-kem-03.html
>>>
>>> A diff from the previous version is available at:
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-pqc-kem-03
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> jose mailing list -- jose@ietf.org
>>> To unsubscribe send an email to jose-le...@ietf.org
>>>
>> _______________________________________________
>> jose mailing list -- jose@ietf.org
>> To unsubscribe send an email to jose-le...@ietf.org
>>
>
_______________________________________________
jose mailing list -- jose@ietf.org
To unsubscribe send an email to jose-le...@ietf.org

Reply via email to