Clearly, you and I disagree about what’s broken. The negotiation algorithms
work as intended when fully-specified algorithm identifiers are used. The
thing that’s broken, as I see it, are the polymorphic algorithm identifiers.
-- Mike
From: Neil Madden <[email protected]>
Sent: Monday, May 6, 2024 1:58 PM
To: Michael Jones <[email protected]>
Cc: Karen ODonoghue <[email protected]>; JOSE WG <[email protected]>
Subject: Re: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms
On 6 May 2024, at 20:32, Michael Jones
<[email protected]<mailto:[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]
