On Mon, Apr 17, 2023 at 05:23:54AM +0900, AJITOMI Daisuke wrote: > > > 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.
The problem with this is that any alg registered SHALL be defined. And this includes any security considerations. >From the relevant BCP laying out the requirements: "<...> the values and their meanings must be documented in <...> specification, in sufficient detail so that interoperability between independent implementations is possible." For COSE, what this means is that in order to define the alg values, COSE-HPKE MUST be extended to all four modes. Which is something that COSE-HPKE draft itself seems unwilling to do. For JOSE, the implications are even worse. It means that the entiere JOSE-HPKE MUST be defined, a task harder than defining COSE-HPKE. One can not assume that the alg definitions will be the same. As examples of differences between use of algorithms in COSE-HPKE and JOSE-HPKE, I think that (after the breakthrough in JOSE-HPKE I was waiting for): - JOSE-HPKE requires two algorithms for the base mode, in contrast to COSE-HPKE, that only has one. - Auth mode can not be used at all in JOSE-HPKE, due to vulnerability that is unfixable without extending JWE in highly nontrivial ways. And there are very much nontrivial security considerations. For example, I think the same vulnerability as above requires restricting auth modes in COSE-HPKE to just COSE_Encrypt0. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
