On Mon, Apr 17, 2023 at 08:11:28AM -0500, Orie Steele wrote: > > On Mon, Apr 17, 2023 at 7:25 AM AJITOMI Daisuke <[email protected]> wrote: > > > > Now, if we extend this specification to "Use of HPKE with COSE and JOSE," > > we will also need to decide how to represent HPKE_Sender_Info on JOSE. This > > is completely different from RFC8812, which only registers parameters with > > the IANA registry. We need to define what we have been doing with COSE-HPKE > > within the constraints specific to JOSE. Ilari says this is very difficult, > > but to be honest, I don't understand the extent of the difficulty. However, > > at least, it is certain that this is not a matter that can be settled with > > just registering parameters with the IANA registry.
Actually, I think I have figured out how to solve all the hard issues. However, it is still a lot of work, as it is not going to be simpler than COSE-HPKE. > This is not true, I showed a counter example using your library. > > There may be difficulty in "adding HPKE to JWE", but it is not difficult to > make a JWK / COSE Key that supports HPKE regardless of if you are using a > COSE HPKE library or a regular one, like hpke-js. I have posted at least one mail that states exactly what is needed for this. > I am not saying the COSE WG needs to do more than define keys consistently > and define how "alg" relates to them when it is in "cose headers". I think the COSE_Key case is easy: Unless there are strong justfications otherwise, follow the standard COSE rules. It is JWK case which is problematic: Alg in JWKs refers to JOSE algorithms, which would require JOSE-HPKE. And it is pretty clear to me that algorithms in JOSE-HPKE can not work like they do in COSE-HPKE due to restrictions in JWE. > There are 2 options on the table: > > 1. parameterize "alg" with "hkc" and relate it to "sender_info"... which > is * revolutionary *. > 2. register "alg" values that map to "hkc", like Apple does, and as I have > shown on https://hpke.dev There is also third option: 3. Omit "hkc" (only include what is strictly technically necressary in keys), transmit parameters used in sender_info. This is completely precedented in both COSE and JOSE. Now, turns out 1. is revolutionary, but probably not for reason you think: It is the first attempt of any kind of algorithm negotiation mechanism in COSE/JOSE. However, turns out the mechanism is flawed. For 2., if the goal is to have "alg" signal recipient key preferences, that is flawed as well. The flaw in both cases is the same: There is another algorithm component, and there is no way to either constrain nor advertise it in COSE nor JOSE. Adding restriction here would be a revolutionary change, if it is possible at all. > We are currently doing 1, and if I am in the minority on this point, I > expect 1 to proceed... I still think the key side should be handled in the > same document if 1 is taken, and hence another draft is a mistake. > > I think 1 is a mistake, and I see Ilari, and Daisuke advocating for it, > Laurence seems neutral so far, but has noted we should try to follow > conventions that COSE has set, let's assume for the sake of argument that > Laurence is pro option 1 and anti option 2. I am not advocating for 1. I am advocating either for 3., or 3. plus negotiation mechanism that is not flawed (not related to sender_info). And my test code, the key storage is very hacky, but the end result is equivalent to 3. above. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
