On Tue, 17 Sept 2024 at 19:04, Mike Ounsworth <Mike.Ounsworth= [email protected]> wrote:
> +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. > I see several use cases that use JWE with asymmetric keys for short-lived data, for example, see https://auth0.com/docs/secure/tokens/access-tokens/json-web-encryption -Tiru > > 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]> 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] > > > 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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
