On Fri, Apr 21, 2023 at 06:15:31PM -0700, Laurence Lundblade wrote: > A couple of observations: > > HPKE isn’t an algorithm like RSA or the PQ algorithms or EC. It’s a > user of those algs (except RSA). We’re not defining new a key type the > way RFC 8230, RFC 8812 and RFC 9053 do. We already have the key types > to work with HPKE KEMs. Seems like the sole thing is to define how > alg restriction with the alg parameter works for HPKE.
I do not think this is correct. - We do not have key tpyes to work with HPKE KEMs. All the current ones yes, but that is one expert review away from changing. In contrast, the HPKE kty truly offers key type for all HPKE KEMs. - The documents already define how alg restriction works, by defaulting to standard COSE rules. This turns out to be enough for soundness. - AFAICT, the reason why alg restriction exists is cryptographic soundness (mixing cryptographic algorithms with the same key material is generically unsound). The above impiles that the present rules are enough for HPKE. > Seems like the situation with JWK is similar. There are already > definitions for key types and curves for a JWK that can work with HPKE > KEMs. So again, it’s mostly about the “alg” parameter that restricts > use of the key. It doesn’t seem necessary to define alg restriction > for JOSE_HPKE until we have JOSE_HPKE. The situation for JOSE is a bit different from COSE, due to some low- level differences between JOSE and COSE. The situation with keys is the same: Current ones can be expressed, but one that can not be may appear at any time. Again, HPKE kty offers key type for all HPKE KEMs. Also, the alg restriction rules in JOSE are the same as in COSE. Where things differ is alg restrictions being problematic. - Alg restrictions can not be used without JOSE-HPKE being defined. - It turns out that JOSE-HPKE has to work in a way that makes alg restrictions problematic. One way around this would be to use "use" restrictions instead of "alg" restrictions. Then there is the issue that using the same key in multiple protocols is much more hair-raising than using the same key in multiple algorithms. However, I don't think COSE and JOSE have bad interactions, and using HPKE for both greatly reduces probability of bad interactions. > It seems like there might be some benefit and clarity for the reader > from defining the “hkc” parameter for COSE_Key in the same place as > HPKE_sender_info. One should be very clear if hkc is supposed to be restriction or advert. I do not think the former is needed, and it is not sufficient as the latter (since bulk encryption algorithms are missing!). > These continue pulling me towards merging the drafts and doing the > work on JWKs when we do the JOSE HPKE work. If JOSE HPKE work gets done. Even with all the hard questions solved, it will be very challenging. And the nasty part is that a lot of that work is to get something that survives adoption call. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
