> > 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. >
Multiple participants have come forth saying that this isn't a concern. I for one see not being able to use a JWK with multiple algs as a Pro, not a Con. S pozdravem, *Filip Skokan* On Fri, 8 Aug 2025 at 08:42, tirumal reddy <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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, <[email protected]> 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:[email protected]), 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >>> jose 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]
