On Wed, Jul 05, 2023 at 05:38:31PM -0400, Michael Richardson wrote: > > lgl island-resort.com <[email protected]> wrote: > > The short version is that I *strongly* prefer a single “alg” integer to > > further parameterise the key usage space. The use of a construction > > like “hkc” is almost certain to complicate interoperability and > > testing. Large-scale systems may be able to support many options, but > > constrained systems rarely have that luxury. While configuration or > > profile documents can help, there is generally a risk over time of > > there being a large enough number of configurations that they no longer > > help very much as everyone chooses his/her favourite. > > I concur. > > Parameterization look like a nice optimization for our process, but are not > helpful to interoperability. While people sometimes get afraid about how > many combinations there could be, in practice, there never are that many, and > getting a COSE artifact with alg=IDONTKNOWTHISONE is the same as getting it > with parameter YOUDONTKNOW.
As, to how many one would need at _minimum_: Current: 12 Compact: 18 AEGIS: 18 Compact+AEGIS: 27 (Then there are some foreseeable extensions with even worse effects.) Then, these "parameters" are actually inputs to HPKE and integral to its operation. So if the values are not explicitly transported, one has to decode those somehow. Which certainly does not help interoperability. HPKE implementation complexity is proportional to number of algorithms implemented. Since any reasonable set covers everything, ciphersuites will not simplify implementation. Profiling does, but it simplifies the same. Then, message structure can vary by alg, opening the door for somebody doing something "smart", causing implementation complexity to explode. And getting unknown alg is not the same as getting unknown parameters. With first, you are stuck. With second, you can at least ask HPKE code if it knows what those mean (my prototype code absolutely does that). If it does not know either, there is no way that can be supported either way. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
