> a) and b) seems to be essentially the same thing? Yes, I was actually thinking the same thing while writing, that it's essentially the same thing :-)
> I think c) is a really bad idea. I understand your preference. However, as I mentioned in the previous post to Orie, I think defining all of alg values is not such a bad idea. All of the other HPKE modes are well-defined in RFC9180 and I think that they don't affect the definition of KEM key representation and hkc structure. Best, AJITOMI Daisuke 2023年4月17日(月) 0:10 Ilari Liusvaara <[email protected]>: > On Sun, Apr 16, 2023 at 09:05:54PM +0900, AJITOMI Daisuke wrote: > > > > I think there are several topics mixed in this thread, but first, I'd > like > > to comment on whether this draft should be merged into the existing > > COSE-HPKE spec. > > > > The reasons why I proposed this draft as an independent specification > > separate from COSE-HPKE are as follows: > > > > a) I wanted to define not only COSE_Key but also JWK representation > > together for HPKE. This is the biggest reason. > > > > b) Key representation is essentially independent of the COSE message > format > > and can be used for various applications unrelated to COSE or JOSE. As I > > mentioned in the slides for IETF116, I thought it would be beneficial for > > applications using HPKE for end-to-end encryption over HTTP if the HPKE > > recipient's public key could be published at the .well-known/jwks > endpoint. > > COSE_Key representation may also be useful for CoAP-based end-to-end > > encryption apps in the same way. > > a) and b) seems to be essentially the same thing? But yes, I agree > this should be something to work on. > > > > c) I wanted to consolidate the definitions of all expected alg values > > (HPKE-v1-{Base, Auth, PSK, AuthPSK}) into one document. Although I had > > agreed with the opinion that the COSE-HPKE should focus only on the Base > > mode, I thought it would be better to have all alg values for HPKE modes > > consolidated into one document. If this draft is adopted as a working > group > > document, I was thinking of proposing to move the definition of alg > values > > from the COSE-HPKE spec to this draft. > > I think c) is a really bad idea. Defining alg value requires specifying > how it would work. Which would imply extending scope into specifying > the other three modes of HPKE. Just the security considerations in > doing so are highly nontrivial. > > And doing this with JWK is even worse idea, because now you need full > definition of JOSE-HPKE, which is considerably harder task than the > entiere COSE-HPKE spec. > > > > 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. What do you think? > > I think the work should be split into two sub-tasks, both to be handled > in one document (if applicable): > > 1) Definition of minimal kty for generic HPKE keys in COSE_Key and JWK. > > E.g. (for JWK, the COSE_key version just replaces JOSEisms with > COSEisms): > > { > "kty":"HPKE", > "kem":48, > "priv":"ge...t5", > "pub":"cd...7i", > } > > > 2) If desired by the WG (since this is unprecedented), a negotiation > mechanism for HPKE algorithms. > > E.g. (again can replace JOSEisms with COSEisms for COSE_Key version): > > { > <other key fields> > "hpkeadv":[[],[1],[2,3]], > "cose-bulk":[2,3,24], > } > > The order in hpkeadv is supported KEMs, KDFs, AEADs. Every field allows > one or more values (if in kty=HPKE, then kem value is implicitly added > to the KEM list). > > "cose-bulk" is list of COSE algorithm IDs supported for bulk encryption > at layer 0 (integer or string, so fits JSON datamodel). > > > I wrote the examples for JWK because it is consderably easier to sketch > JSON than CBOR diagnostic notation, and the mapping to COSE_Key is > pretty much trivial. > > > > > -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
