+1 to Niel’s question.
> " the general consensus in CFRG seems to be towards hybrid KEMs (eg some > combo of X25519/P-256 + ML-KEM), so is there a need for a “naked” ML-KEM > option?” JWEs / CWEs certainly can be used to carry data with long confidentiality lifetimes (PII, financial data, etc), but can also be used for extremely short-lived data like auth tokens. But of those use-cases that I’ve run into in $dayjob where data sensitivity is extremely short-lived, the overwhelming majority are JWS (RS256 / HS256), followed by AES-only tokens (ie the server encrypts an auth token for itself). So I would be interested to hear from operators who: A) use JWE asymmetric key exchange with short-lived data. B) can’t tolerate the extra like 64 bytes for the X25519 / P256. Those are the use cases that would make an argument for a naked ML-KEM option. Do any exist? --- Mike Ounsworth From: Neil Madden <[email protected]> Sent: Tuesday, September 17, 2024 4:38 AM To: Karen ODonoghue <[email protected]> Cc: JOSE WG <[email protected]> Subject: [EXTERNAL] [jose] Re: Call for adoption: https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-kem/ I’ll try and give this a proper read through today, but a couple of initial questions: - the general consensus in CFRG seems to be towards hybrid KEMs (eg some combo of X25519/P-256 + ML-KEM), so is there a need for a “naked” ML-KEM option? I’ll try and give this a proper read through today, but a couple of initial questions: - the general consensus in CFRG seems to be towards hybrid KEMs (eg some combo of X25519/P-256 + ML-KEM), so is there a need for a “naked” ML-KEM option? - more broadly, unless we’re actually going to merge the COSE and JOSE WGs, it seems procedurally awkward to have drafts in the JOSE WG that dictate COSE algorithms. Is it really that hard to have two drafts? — Neil > On 14 Sep 2024, at 21:50, Karen ODonoghue <[email protected] > <mailto:[email protected]> > wrote: > > JOSE and COSE working group members, > > The following draft has been submitted for consideration by the JOSE > working group. The chairs agreed, at IETF 120, to issue a call for > adoption. > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-kem/__;!!FJ-Y8qCqXTj2!cTqypVN0cPPcG9K-tOrwMuqDaPnjPspDsEq7itGEXZc0WSIaRgbBvPFWiPB3UjFdCSFhAKdhlfQFyoOND2mBaC75kWoE$ > > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-kem/__;!!FJ-Y8qCqXTj2!cTqypVN0cPPcG9K-tOrwMuqDaPnjPspDsEq7itGEXZc0WSIaRgbBvPFWiPB3UjFdCSFhAKdhlfQFyoOND2mBaC75kWoE$> > > > Please review the document and indicate (by responding to this email > and keeping the subject line intact) whether or not you think this is > a good place to start the development of this document. Please provide > comments. > > This call for adoption will close on Monday 30 September. > > Thank you, > Karen > > _______________________________________________ > jose mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> _______________________________________________ jose mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
