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]> 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]>: > > > 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 > > <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] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
