On Fri, 8 Aug 2025 at 12:17, Filip Skokan <[email protected]> wrote:
> 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. > I hear you, it sounds like you are saying you want to restrict the key to a single mode of use. Cheers, -Tiru > > 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]
