I haven't participated much on these lists nor looked closely at these identifiers in question, but one thing I've picked up in my yet short experience with crypto standards is that parseable algorithm identifiers seem like an anti-feature. As I've understood it, modern best practice is to consider algorithm suites as atomic, because you can't just swap out pieces and assume that security properties still hold for the new combination. In my mind, that's a good argument against fully-descriptive algorithm (suite) identifiers and in favour of shorter names meant to be looked up in a registry (but long enough that the most common ones can be distinctly memorable), because then people are less likely to attempt to parse them and introduce downgrade attacks/etc that way.
Cheers, Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den tors 12 dec. 2024 kl 19:17 skrev Ilari Liusvaara < [email protected]>: > On Thu, Dec 12, 2024 at 10:52:03AM -0600, Orie Steele wrote: > > +1 to your point Neil, and that is an option in COSE. > > > > https://datatracker.ietf.org/doc/html/rfc9052#section-3.1-6 (although > not > > obvious, alg is an optional header in COSE). > > > > Sadly it would be a breaking change to JOSE to do that: > > > > https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.1 > > Funkily enough, COSE-HPKE seemingly allows omitting alg for recipient > encryption (can't find any requirement) but not direct content > encryption: > > "The sender MUST set the alg parameter in the protected header, which > indicates the use of HPKE." > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
