> On 5 Mar 2024, at 14:41, AJITOMI Daisuke <[email protected]> wrote: > > > I think we should use HPKE until there is reason not to use it. > > I agree.
I think there *are* lots of reasons not to use HPKE. I described some of them in my previous message to this list [1]. For a start, including all of HPKE is using a sledgehammer if all we want is a PQC option for JOSE, not to mention that it doesn't help at all with signatures. What it does do is create redundancy with existing JOSE ECDH algorithms and introduce some new ones that have glaring security issues when used in JOSE (refer to my previous message). > > Regarding ML-KEM, I was thinking that we should add X-Wing as a PQ/T Hybrid > KEM to the list of COSE-HPKE ciphersuites at first. > > X-Wing: general-purpose hybrid post-quantum KEM > https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/ > <https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/> > There are a bunch of proposals for hybrid schemes under discussion in CFRG. I agree that we should generally adopt one of those rather than ML-KEM on its own, but we should perhaps let the dust settle on those discussions before moving ahead with one here. Regarding this specific draft under discussion, I'm confused why everyone keeps wanting to cram things into the "enc" header? JWE is quite clear that this header "MUST be an AEAD algorithm"[2]. KEMs are not AEADs. If we are going to add ML-KEM as an encryption algorithm then we should have something like "alg":"ML-KEM-768","enc":"A256GCM" or "alg":"ML-KEM-768+A256KW" etc. (or "alg":"XWingXYZ+A256KW" or whatever we choose). -- Neil [1]: https://mailarchive.ietf.org/arch/msg/jose/-1rVajt_tnl2Ai-Cz3ioRI8BxtQ/ <https://mailarchive.ietf.org/arch/msg/jose/-1rVajt_tnl2Ai-Cz3ioRI8BxtQ/> [2]: https://www.rfc-editor.org/rfc/rfc7516.html#section-4.1.2 <https://www.rfc-editor.org/rfc/rfc7516.html#section-4.1.2>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
