On Tue, 29 Jul 2025 at 20:49, Ilari Liusvaara <[email protected]> wrote:
> On Tue, Jul 29, 2025 at 05:50:04PM +0530, tirumal reddy wrote: > > On Mon, 28 Jul 2025 at 21:44, Filip Skokan <[email protected]> wrote: > > > > we can also define a new key type for KEMs, for instance > > > > { > > "kty": "KEM", > > "kem": "ML-KEM-512", > > "pub": "...", > > "priv": "...", > > "alg": "ML-KEM-512+AES128KW" // optional > > } > > > > This approach is similar to AKP but with a key difference, the "alg" > > parameter is optional, offering more flexibility. At this point, it seems > > the two viable paths are to either use "AKP" or define a new key type for > > KEMs. > > That is isomorphic to OKP, and there is no precedent for isomorphic > key types in JOSE or COSE (some are close, but not quite isomorphic). > While it resembles OKP, it avoids using the "crv" parameter, which despite RFC 8037 stating that it doesn’t imply an elliptic curve still still gives that impression when looking at the key type. The argument during the presentation at the WG meeting is that this can be confusing, especially for algorithms like PQ KEMs that are not curve-based. > > And I don't see using AKP is feasible unless Direct Key Agreement is > dropped. HPKE does not have this problem because dual-use alg values. > I don’t see a strong reason or clear support from the WG to drop Direct Key Agreement, aside from the double encoding issue in JOSE compact serialization. The main argument in favor of AKP at the WG meeting was that using the "alg" parameter avoids ambiguity, and that implementers reportedly don’t face difficulties using it. At this point, I see three possible directions for the WG: a) continue using "OKP" b) switch to "AKP" c) define a new key type for KEMs. > > Furthermore, using Direct Key Agreement or Key Agreement with Key > wrapping in JOSE compact encoding causes unavoidable double encoding > of the KEM key (which is the large part). I raised a PR https://github.com/tireddy2/PQC_JOSE_COSE/pull/16 to document the overhead. Cheers, -Tiru > > The simplest way to make the Key Agreement with Key Wrapping modes be > Key Encryption instead is to just mash together the KEM ciphertext and > key wrap output in JWE Encrypted Key / COSE layer ciphertext. > > Would not qualify as any of the present COSE modes, but as it does not > invoke any priviledged behavior, that is not an spec issue. > > > > > -Ilari > > _______________________________________________ > 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]
