Hello, Apologies in advance for starting a thread about the proper way to name things.
We've been discussing the TLS naming conventions in relation to JOSE and COSE naming conventions for suites. Here is the start of the full thread: https://mailarchive.ietf.org/arch/msg/jose/66xvb1EgD-bf7V-XyAgDgRuUTJk/ We've been comparing "trends in suite names", between TLS, JOSE and COSE. For example, we see the following: /* ECDSA algorithms */ ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), ecdsa_secp521r1_sha512(0x0603), /* EdDSA algorithms */ ed25519(0x0807), ed448(0x0808), In JOSE, ES256 means ~ " ecdsa_secp256r1_sha256(0x0403)," In COSE, ES256 means ~ "ecdsa with some curve + sha256" In JOSE, EdDSA means ~ "EdDSA with some curve" in COSE, EdDSA means ~ "EdDSA with some curve" This draft is in call for adoption, and argues for a convention: https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/ The convention is essentially, when we "name a suite", it should fully specify all the parameters. "ecdsa_secp256r1_sha256" is fully specified... "eddsa" or "ecdsa with sha256" is not (curve parameter is not specified). 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. I see that "ed25519(0x0807)," could have been "eddsa_ed25519", and I assume "0x0807" actually means "eddsa with ed25519", and "0x0808" actually means "eddsa with ed448". I don't expect a hash function here, because I know SHA-512 is used internally. Key representations in JOSE and COSE have parameters, and one parameter is the "alg" field, which restricts the use of the key. In the case of a fully specified algorithm, this "alg" parameter contains redundant information to the other key parameters. In the case of a partially specified algorithm, this "alg" parameter contains non redundant information (such as dsa and hash, there are curves that support multiple dsas, and of course everyone has a favorite hash function). Neil also made several compelling arguments not to adopt the draft because fully specified identifiers for partially specified things are already partially understood. Assuming we dropped new registrations, and just made recommendations for how to specify algorithms, how might JOSE and COSE align our registry guidance with the current thinking in TLS? Should we recommend against fully specifying things, and argue that negotiation should be for keys, not algorithms, and keys can choose to restrict to achieve full specification? Should we recommend fully specifying things, and then decide if redundant code points should also be assigned, or if the guidance should just be forward facing? Regards, OS -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
