Just quoting from the refenced thread, since I don't agree with your interpretation of it:
> > In the thread, Neil said that it is better to negotiate for key (representations), instead of algorithms, and that TLS has been moving away from fully specifying things. > This is the exact opposite of what TLS 1.3 has done. I see the JOSE email claims we've moved away from fully specifying things by citing the cipher suite change, but that is misunderstanding what changed. > When you say "Ed25519", it *already* implies EdDSA. EdDSA is a family of signature schemes. That is, it is a way to construct a signature scheme given some parameters. Ed25519 is a particular instantiation of that. > The fact that Ed25519 and Ed448 are both EdDSA instantiations, or that the X25519 algorithm and the Ed25519 algorithm have a similar structure are just useful properties when analyzing, specifying, or implementing a primitive. It is not relevant to protocols that *use* a primitive. As far as we're concerned, these are just names that conform to the signature scheme interface (KeyGen() -> (pk, sk), Sign(sk, msg) -> sig, and Verify(pk, msg, sig)). To me this last part is most compelling. If changing a part of the named algorithm, breaks this interface, then the algorithm is fully specified. key-gen (signature type) --> private-key --> public-key --> signature (signature type) in data integrity, changing the hash function used, or the canonicalization algorithm breaks the signature verification. the attacker can change these before verification succeeds. As a practical matter, I cannot generate a key pair with just the word "EdDSA", I need to know the curve. The same is also true of ECDSA. Differences in registries for algorithms can impact how easy it is to build safe APIs or negotiate, for example: https://github.com/panva/jose/blob/main/docs/functions/key_generate_key_pair.generateKeyPair.md For none fully specified algorithms, the crv property is required to generate a key. Regards, OS On Mon, Jan 8, 2024 at 9:05 AM Manu Sporny <[email protected]> wrote: > On Mon, Jan 8, 2024 at 9:52 AM Orie Steele <[email protected]> > wrote: > > > > We got some good responses from the TLS list on the interpretation of > their suites, please review them: > > > > https://mailarchive.ietf.org/arch/msg/tls/LXBUvjMdhEpgIEC1CEzTuDKZNwY/ > > Yes, that summarizes exactly what the JOSE group was warned about many > years ago wrt. the polymorphic approach. > > The experiences with TLS 1.2 and 1.3 further underscores the reasons > that the Data Integrity work at the W3C has decided to NOT go down the > "polymorphic" algorithm path. > > The problem with the "fully specified" specification is that it's > attempting to slap a bandaid on the problem which is only going to > make the problem worse. Banning polymorphic algorithm identifiers > would be the way to go, but as I said, the JOSE group made the > decision to go down the polymorphic algorithm identifier route long > ago and supporting both polymorphic and fully-specified will just make > everything more complicated for JOSE developers and lead to > interoperability failures. > > -- manu > > -- > Manu Sporny - https://www.linkedin.com/in/manusporny/ > Founder/CEO - Digital Bazaar, Inc. > https://www.digitalbazaar.com/ > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
