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.
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. 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. These continue pulling me towards merging the drafts and doing the work on JWKs when we do the JOSE HPKE work. LL > On Apr 19, 2023, at 1:37 PM, AJITOMI Daisuke <[email protected]> wrote: > > Hi Laurence, > > > I think it would be better to merge the two drafts. > > You originally mentioned that we should focus on defining COSE_Key, so this > opinion is not surprising. > > However, I'm considering defining the JWK representation at the same time, > like RFC8812 or the recent post-quantum key representation proposed by Mike > Prorock. > Even if we define the JWK representation in the same draft, do you think we > should merge the specifications? > > The point of contention is whether or not to include JWK representation in > this draft. > > If it is concluded that JWK should not be defined together, and that the > definition of key representation should be limited to the HPKE Base mode, and > that other HPKE modes should not be defined at this point, then it may indeed > be better to merge this draft into the COSE-HPKE spec. On the other hand, if > there is room for discussion on these issues, I think it would be appropriate > to consider it as an independent draft currently. We can merge it into the > COSE-HPKE spec at any time. > > As I mentioned before, if we have to focus on the COSE_Key representation, > then it would indeed be better to merge this draft into the COSE-HPKE spec. > > Best, > AJITOMI Daisuke > > > 2023年4月19日(水) 2:26 Laurence Lundblade <[email protected] > <mailto:[email protected]>>: > I think it would be better to merge the two drafts. > > - RFC 8230 <https://www.rfc-editor.org/rfc/rfc8230.html>, the definition of > RSA for COSE defines the key format, alg IDs and all in one > - There will be clarify and synergy from defining how to express a COSE > algorithm ID for all the uses of an algorithm ID in one place > > Appreciate the work on draft-ajitomi-cose-cose-key-jwk-hpke-kem to move > things forward. :-) > > LL > > >> On Apr 17, 2023, at 3:57 PM, AJITOMI Daisuke <[email protected] >> <mailto:[email protected]>> wrote: >> >> Mentioning the Apple thing was my fault (there is a lot I would like to say >> about this matter.), but I would like to clarify whether my draft can be >> merged into the existing COSE-HPKE spec before stepping down to the details >> of the key representation. >> >> My understanding is that you are in favor of defining both JWK and COSE_Key >> in the same document, and at the same time, you believe that my proposal >> document should be merged into the COSE-HPKE specification. >> >> Again, is your argument that the "Use of HPKE with COSE'' should be extended >> to "Use of HPKE with COSE and JOSE"? >> >> If this understanding is correct, you should first ask Hannes if he agrees >> with this before discussing the details. >> >> Best, >> AJITOMI Daisuke >> >> 2023年4月18日(火) 3:42 Orie Steele <[email protected] >> <mailto:[email protected]>>: >> >> >> On Mon, Apr 17, 2023 at 1:18 PM Ilari Liusvaara <[email protected] >> <mailto:[email protected]>> wrote: >> 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] >> > <mailto:[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. >> >> >> The "alg" (algorithm) parameter identifies the algorithm intended for >> use with the key. The values used should either be registered in the >> IANA "JSON Web Signature and Encryption Algorithms" registry >> established by [JWA] or be a value that contains a Collision- >> Resistant Name. The "alg" value is a case-sensitive ASCII string. >> Use of this member is OPTIONAL. >> >> https://www.rfc-editor.org/rfc/rfc7517#section-4.4 >> <https://www.rfc-editor.org/rfc/rfc7517#section-4.4> >> >> ES256 in a JWK works with ES256 in a COSE Sign1. >> >> >> >> >> > 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 <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. >> >> >> Yes, I agree. "alg" is optional, it can be inferred / agreed to, in more >> ways than having it restricted in a key or header. >> >> >> 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. >> >> I don't think this is true, it is the first attempt at restriction by >> parameterization. >> >> Restricting a key to a specific algorithm is not the same as negotiating for >> a specific algorithm. >> >> They are very similar though, and a key restricted to a single algorithm >> obviously makes considering negotiation a lot easier. >> >> 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. >> >> >> <Screen Shot 2023-04-17 at 1.37.53 PM.png> >> >> https://datatracker.ietf.org/doc/html/rfc8152#section-12.5.1 >> <https://datatracker.ietf.org/doc/html/rfc8152#section-12.5.1> >> >> I think we agree, adding "hkc" here would be revolutionary, making "hkc" not >> relevant by encoding it in an alg registration lik (-27) would not be >> revolutionary. >> >> >> > 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. >> >> >> I like your 3rd proposal. >> >> It is also compatible with a "suites" or "no suites" approach, given you can >> send "sender_info" as is, or you could send an integer value for "alg" that >> is mapped to the same "sender info" values. >> >> If the same "alg" value was present in the COSE Key or JWK, this would be >> 100% the way it is today. >> >> >> >> -Ilari >> >> _______________________________________________ >> COSE mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/cose >> <https://www.ietf.org/mailman/listinfo/cose> >> >> >> -- >> ORIE STEELE >> Chief Technical Officer >> www.transmute.industries <http://www.transmute.industries/> >> >> <https://www.transmute.industries/> >> _______________________________________________ >> COSE mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/cose >> <https://www.ietf.org/mailman/listinfo/cose> >> _______________________________________________ >> COSE mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/cose >> <https://www.ietf.org/mailman/listinfo/cose> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
