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]>: > 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]> >> 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]> >>> 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 >> >> 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 >>> >>> 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] >>> https://www.ietf.org/mailman/listinfo/cose >>> >> >> >> -- >> *ORIE STEELE* >> Chief Technical Officer >> www.transmute.industries >> >> <https://www.transmute.industries/> >> _______________________________________________ >> COSE mailing list >> [email protected] >> 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
