On Mon, 28 Jul 2025 at 21:44, Filip Skokan <[email protected]> wrote:
> Following up on the presentation > <https://datatracker.ietf.org/meeting/123/materials/slides-123-jose-pq-kems-for-cose-and-jose-01> > from > last week I've opened two new issues in the draft's github tracker for > topics we didn't discuss yet following the request for more feedback. > > - "alg" values proposal > <https://github.com/tireddy2/PQC_JOSE_COSE/issues/14>, fairly > inconsequential but it does align the alg values with the rest of JOSE algs > - Private JWK should be seed-only proposal > <https://github.com/tireddy2/PQC_JOSE_COSE/issues/13>, this is to > align ML-KEM private JWK format with what the outcome has been for ML-DSA > private JWK format - to only use seeds > > As far as the other questions from the presentation to the working group > go I believe this is fair summary > > - Input updates to the context in KDF - I believe we agreed on pulling > the definition of AlgorithmID, concat(AlgorithmID, SuppPubInfo, > SuppPrivInfo) into the main body of jose-pqc-kem instead of referencing > parts of RFC7518's ECDH section. > - Why not Use AKP Slide - Use of AKP doesn't introduce ambiguity, it > removes it. Not being able to use the same JWK for both modes when using > AKP is a problem that doesn't need solving. The WG poll on "Should OKP be > used for ML-KEM JWKs" resulted in "Yes 0 / No 5 / No Opinion 7", on "Should > we use AKP" was "Yes 5 / No 1 / No Opinion 10". Introducing a brand new key > type was proposed but that only solves the optics problem of using OKP > (i.e. having crv and x), I believe the next version should revert back to > using AKP since the change to use of OKP was not grounded in any form of > consensus on the mailing list prior to the meeting). > > 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. Cheers, -Tiru > Thank you for pushing the draft forward with solid momentum. > > Best, > *Filip Skokan* > > > On Tue, 22 Jul 2025 at 09:42, <[email protected]> wrote: > >> Internet-Draft draft-ietf-jose-pqc-kem-02.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-02.txt >> Pages: 23 >> Dates: 2025-07-22 >> >> 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-02.html >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-pqc-kem-02 >> >> 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]
