> > 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. Agree. My proposal includes not only 'hkc' but also a generic kty for HPKE KEM and the latter of which is also important. At least regarding the latter, I'm confident that there are no major issues in defining the kty both for JWK and COSE_Key. One should be very clear if hkc is supposed to be restriction or advert. I may not fully understand the difference between the restriction and the advert, but I think it's more natural to consider the "hkc" as being for advertisement purposes. In my presentation at IETF116, I highlighted .well-known/jwks as a typical use case, positioning it as primarily for advertising the recipient's capabilities. One way around this would be to use "use" restrictions instead of "alg" > restrictions. It may indeed be more natural to consider "hkc" as additional information for "use/key_ops", rather than as additional information for "alg". As is evident from the fact that this draft names the key type as "HPKE-KEM", the keys targeted by this draft are (needless to say) for KEM. There is a reason why "alg" includes mode information (e.g., "HPKE-v1-Base"), which is because the modes in HPKE only apply to the KEM step. On the other hand, information about KDFs or AEADs is essentially unrelated to the KEM key and therefore has no relation to "alg". On the contrary, it may be more natural to consider "hkc" as additional information for "use": "enc" or "key_ops": "deriveBits". At least, I've started to feel that it might be better not to consider "hkc" as an extension of information for "alg". Ilari, I understand your argument as follows, is this correct? If so, I can agree with your opinion: - This draft should define a generic key type for HPKE KEM for both JWK and COSE_Key, as well as the "hkc" parameter (ignoring any current definition shortcomings or issues). - This draft should not define "alg" and related things at all. The "alg"s will be defined in COSE-HPKE and any future JOSE-HPKE. - The "hkc" should not be regarded as an extension of information for "alg". If anything, it is additional information for "use/key_ops" and it's basically for advertising the recipient's preference/capability for HPKE operation. - The "hkc" should be able to be used not only with newly defined "HPKE-KEM" but also with existing key types (EC, OKP). Best, AJITOMI Daisuke 2023年4月22日(土) 16:54 Ilari Liusvaara <[email protected]>: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
