Hi Orie,
I am not sure whether the comparison between JOSE/COSE and TLS is appropriate when the latter uses a handshake and the former is a one-shot message (or a payload). In a TLS handshake there are so many things that get negotiated, such as the algorithms and parameters for protecting the record layer (e.g. TLS_AES_128_GCM_SHA256), the curve and parameters of the key share (e.g. secp256r1), the digital signature algorithms (like ecdsa_secp256r1_sha256) used in the handshake and the signature algorithm used for cerificates, version, extensions and other features. On top of the above, the design has a long history and didn't radically change from version to version (except for the cipershite that was changed to separate the authentication and key exchange mechanism from the symmetric key algorithm and hash function used at the record layer). Hence, I am not sure what the benefit of aligning the registries are. To me, this entire ciphersuite vs. à la carte discussion is largely a matter of taste. Ciao Hannes PS: Regarding your question below about "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". Since these values are in the signature algorithm registry, those are could have been prefixed with "eddsa". Am 06.01.2024 um 15:49 schrieb Orie Steele:
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 STEELEChief Technology Officerwww.transmute.industries <https://transmute.industries> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
