In short, "draft-ra-cose-hybrid-encrypt", registered "alg" values that are "suites", so you can switch on a single string or integer... and it makes the "alg" value mandatory for the new "kty" "HYBRID".
Inline for the rest: On Tue, Jul 11, 2023 at 10:47 AM AJITOMI Daisuke <[email protected]> wrote: > Hi Orie, > > Sorry for not keeping up with the recent discussion on the "alg" design > policy (I'll take some time this weekend to catch up). > > I'm a bit confused because it seems like you support this draft. > > This draft is identical to my proposal in that it limits the "kty" to KEM > ("HPKE-KEM" in my proposal), and in that it limits the "alg" design to the > scope of the KEM (not including KDF or AEAD, which are not related to its > key operation). > > Are you saying that you have dropped your argument that "all KEM-KDF-AEADs > should be included in the alg value" ? > I am saying I like this part of their draft: https://datatracker.ietf.org/doc/html/draft-ra-cose-hybrid-encrypt-00#name-kem-combiner I might be reading this wrong, but it seems that "x25519_kyber768", assumes a KDF and a Hash Function. It does not expose them as parameters that an implementer chooses to support. I also like this part: https://datatracker.ietf.org/doc/html/draft-ra-cose-hybrid-encrypt-00#section-6 For example: "secp384r1_kyber768+A256KW" - P-384 + Kyber768 parameter + CEK wrapped with "A256KW" ... ... I am assuming this also means "KMAC256" and "SHA3-384" are applied as well... given the definition above. In other words, they seem to have added KEMs in the most natural way to the existing ECDH-ES+A256KW ecosystem. I would still like to see HPKE support in JOSE do the same, but perhaps JOSE and COSE will part ways on encryption envelopes. Also, my proposal focuses only on algorithms that can be adopted in HPKE > (carefully selected for HPKE), whereas this draft is a proposal that more > strongly promotes crypto-agility, which you criticized. > I don't think that's correct. > Specifically, there are four KEMs proposed in this draft, excluding key > wrapping, but only one of these (X25519Kyber768) is adopted by HPKE. > Adopted in a CRFG registry... Not a COSE or JOSE registry.... meaning no expert review from COSE or JOSE experts. > The point is that in the HPKE world, the experts have been very selective > in choosing one quantum resistant KEM. > > I don't think HPKE registry maintainers are expected to be experts on JOSE or COSE, and I would expect HPKE registry to contain entries for all crypto that people want, not just crypto that we think is a good fit for JOSE and COSE. > I know you claimed that you wanted to reduce the number of algorithm > choices and use algorithms carefully selected by experts, does this mean > that you have changed your mind on this idea as well? > > No, hopefully the elaboration above clarifiers. > I don't think we want a bunch of JOSE / COSE algorithms that are "super >> close, but not compatible"... > > > At least, I very much agree with this view and think that the design > policy of "alg" and key representation for JOSE and COSE should be the same > (should be synchronized), which is why I wrote the following draft, > separated from the COSE-HPKE. > https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/ > I agree HPKE needs to be synchronized with JOSE and JOSE Key and Envelope formats. I think this draft is currently proposing a better path forward for key types and envelope formats. I am hopeful we can get alignment on the registry part of this, I see value in JOSE and COSE specific kem registry... since JOSE and COSE already have registries for elliptic curves. - https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves - https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve It seems more natural to do similar for KEMs, and less natural to rely directly on HPKE CFRG registry. I had originally suggested this approach for COSE HPKE... in a massive thread with Ilari that probably nobody read : ), and it was rejected because of the authors desire to rely on the HPKE CFRG registry, which I continue to assert is not a good design choice. Regardless of any final design solutions I do think we need to get some better conventions regarding registries for JOSE and COSE, and hopefully that will happen now that we have competing proposals for where KEMs are registered. > > Best, > Daisuke > > 2023年7月11日(火) 22:59 Ilari Liusvaara <[email protected]>: > >> On Tue, Jul 11, 2023 at 05:49:45PM +0530, tirumal reddy wrote: >> > Hi all, >> > >> > The new draft >> https://datatracker.ietf.org/doc/draft-ra-cose-hybrid-encrypt/ >> > defines the use of traditional and PQC algorithms, a hybrid post-quantum >> > KEM, for JOSE and COSE. Hybrid key exchange refers to using multiple key >> > exchange algorithms simultaneously and combining the result with the >> goal >> > of providing security even if all but one of the component algorithms is >> > broken. >> > >> > Comments and suggestions are welcome. >> >> To me, this seems greatly overcomplicated. >> >> >> 1) The mess of N algorithms can be reduced to just two by making >> method polymorphic in key, just like ECDH-ES has always been. >> >> - KEM >> - KEM+A256KW >> >> Only AES-256 because: >> >> - This is intended for post-quantum. >> - Security level of even Kyber512 could be significanly above AES128. >> - AES-192 is poorly supported. >> >> And for simplicity, fixedInfo should use the same format as for >> ECDH-ES. Specifically: >> >> - For COSE, Core Deterministic Encoding of the COSE_KDF_Context. >> - For JOSE, the concatenation format with the same inputs as used >> for ECDH. >> >> >> 2) It would be simpler for implemeters to always use KMAC256. Most of >> the code can be shared with Kyber, which is _not_ guaranteed for >> KMAC128. And the speed difference is minor. >> >> >> 3) The mess of the key format could be reduced to just concatenating >> the parts into OKP key with new "curves". >> >> Yes, OKP was designed for such stuff from the very begninning. >> >> And even if it is philosophically wrong, this could technically even be >> appiled to ciphertexts in order to stick the ciphertext into "eph". >> >> >> 4) I don't think the use of K is allowed by kem-combiners. AFAIK, the >> minimum length of K for KMAC256 is 32 bytes, but some of stuff using it >> has 21 byte K. >> >> >> >> > ---------- Forwarded message --------- >> > From: <[email protected]> >> > Date: Wed, 5 Jul 2023 at 17:56 >> > Subject: New Version Notification for >> draft-ra-cose-hybrid-encrypt-00.txt >> > >> > Name: draft-ra-cose-hybrid-encrypt >> > Revision: 00 >> > Title: Hybrid key exchange in JOSE and COSE >> > Document date: 2023-07-05 >> > Group: Individual Submission >> > Pages: 30 >> > URL: >> > https://www.ietf.org/archive/id/draft-ra-cose-hybrid-encrypt-00.txt >> > Status: >> > https://datatracker.ietf.org/doc/draft-ra-cose-hybrid-encrypt/ >> > Html: >> > https://www.ietf.org/archive/id/draft-ra-cose-hybrid-encrypt-00.html >> > Htmlized: >> > https://datatracker.ietf.org/doc/html/draft-ra-cose-hybrid-encrypt >> >> >> >> >> -Ilari >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
