On Thu, Jul 20, 2023 at 11:53:35AM -0500, Orie Steele wrote: > Inline: > > On Thu, Jul 20, 2023 at 10:42 AM AJITOMI Daisuke <[email protected]> wrote: > > > The point here is... If I tell you -7 (ES256), you know 2 (kty EC2) and 1 > >> (crv P-256) > > > > > > ... No. In COSE, ES256 can be used not only with P-256 but also with other > > curves (P-521, etc.). > > > > https://datatracker.ietf.org/doc/html/rfc9053#section-8.3 > > I think you are correct. > > It's *extremely* unfortunate naming choices, because that's not how JOSE > works: > > https://datatracker.ietf.org/doc/html/rfc7518#section-3.1 > > It's also probably not a "good idea" to use "sha256 with P-521" (mismatch > in hash and curve strength) > ... Why does COSE encourage this kind of thing, I can't answer that...
I don't think it encourages it, just allows. I think the reason is that there is no good technical reason to disallow it. COSE is not the only one to allow it. E.g., TLS 1.2 and PKIX both allow things like SHA-256 with P-521. > It leads to devices needing to support a kitchen sink, or only certain > protocols, ... it impacts agility. Combinations of things already supported are very cheap (or sometimes even negative cost). And there is no reason to support any things that would otherwise not be supported. > It seems that COSE created even more flexibility than JOSE, and encouraged > protocols to lock things down... > in other words, it punted responsibility, in a way that JOSE did not. However, flexibility is very useful when facing new situations. E.g., integrating HPKE. COSE-HPKE is something truly exceptional. JOSE-HPKE is at most a pale shadow of that. > > Constrained devices won't ship support for both 6 and 7... so advertising > >> -8 is therefore ambiguous / not helpful (by itself) > > > > ... Now consider advertising "HPKE-Base"... How does this help you know > >> how to talk to a firmware or relying party? > > > > > > ES256 is also ambiguous... let's use key information. > > > > Seems you are required to use key information to use COSE... > But not in JOSE... I'm sorta shocked by how bad that is... > COSE "alg" values are NEVER enough information. Upside is that one needs to get it right for it to work at all. It is much perferable to be missing a check disallowing "weird" algorithm combinations than trying to force wrong algorithm. Even when something is seemingly "no way this could possibly work", someone can make it work with disasterous consequences. E.g., see the signature-MAC confusion bugs in JOSE. > Just for clarity... a receiver needs to advertise a list like this [ kty, > crv, alg, hkc ]. > > And then the sender needs to iterate that list to find a match they > support, in order to send. > > And this is "better" than iterating one list of "advertised algorithms" in > the sense that it is "more compact" and "safer" ? Presumably only high-powered highly general implementations would do that. And such implementations could very much afford such things. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
