> On 6 May 2024, at 20:32, Michael Jones <[email protected]> wrote: > Others had also suggested something along the lines of > “id_token_encryption_crv_values_supported”, but the problem is that that’s > playing a game of whack-a-mole. Yes, if the missing information to make an > algorithm fully-specified is a curve, then this helps. But cryptographers > are clever (a good thing!) and regularly come up with new ways of > parameterizing cryptographic functions. Parameters include hash functions, > key derivation functions, mask generation functions, curves, and more. We > could either keep adding ad-hoc metadata parameters for each new kind of > parameterization that arises or we can use fully-specified algorithms. > You are suggesting cramming everything that might possibly be useful into a single identifier. *That* is paying whack-a-mole. What is a relevant parameter changes over time. Do we need to deprecate and re-register algorithms every time somebody decides there is a new dimension that is relevant to them? For example, several blockchain consensus protocols based on Ed25519 require additional constraints to ensure canonical signatures and public keys - does that need to be encoded into the algorithm identifier? EdDSA is not fully-specified without it!
The only entities that are guaranteed to be fully specified are keys. > The fully-specified algorithms approach works with all current > parameterizations *and* all the new creative parameterizations that > cryptographers will invent in the future and so is future-proof, unlike the > keep-adding-metadata-parameters-as-needed approach. > But it *doesn’t* really work with anything other than the elliptic curve algorithms you are specifying. It doesn’t work for ECDH without an explosion of new algorithm identifiers. And if you’re only going to do it for ES* and EdDSA then the new metadata parameter also works just as well and doesn’t require causing conflicts and interoperability issues. > Obviously, hardware will and software can keep using deprecated algorithms as > long as they choose if they continue to meet a need. (Heck, we even > registered the deprecated RSA-SHA-1 for COSE because TPMs use it!). That’s > reality. > But this is different. The algorithm is not deprecated, just the identifier for it. You are causing needless churn and incompatibility in the ecosystem just to change the name of an algorithm rather than fixing the broken negotiation mechanisms. Literally adding a single extra metadata parameter would fix all of the issues you’ve raised without half the pain. — Neil
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
