John, Regarding your last comment in: https://mailarchive.ietf.org/arch/msg/cose/eRn8vShjqW83JEGXwIVjzrIyA4M/
> For security purposes fully-specified keys are likely much more important than fully specified algorithms. In JOSE and COSE, we use "alg" to "restrict a key to a specific algorithm". Is your proposal to have RSA parameters be considered part of RSA algorithms? Let's set aside any potential registry updates for a moment.... Knowing what we know now, regarding interoperability, and parameter errors, and best practices for using cryptographic keys, wouldn't we fully specify RSA keys and algorithms, if we could? If you had a fully specified RSA algorithm identifier, and you used that identifier in an RSA key... wouldn't that make the RSA key fully specified? The high level goal of the draft is to ensure that if 2 parties say they support an algorithm identifier, that is all they need to ensure they can interoperate. I would consider failing to interoperate based on different RSA parameters not being supported on both sides, in the same category as failing to interoperate based on different edwards curves not being supported on both sides (EdDSA in JOSE and COSE)... or failing to interoperate based on different p curves being supported on both sides (ES256 in COSE ... not in JOSE). ... or in a nightmarish future where we encoded custom curve parameters directly into JWKs, and those curve parameters did not match on both sides, or one side implemented support for custom parameters differently... see also curveball: https://thomasandolf.medium.com/what-is-cve-2020-0601-aka-curveball-and-why-is-it-so-dangerous-8664f8c8e9e9 <https://thomasandolf.medium.com/what-is-cve-2020-0601-aka-curveball-and-why-is-it-so-dangerous-8664f8c8e9e9> If we agree there is an interoperability problem for EdDSA and RSA, we don't need to solve them both the same way (or even solve them at all). The primary mission of the document is to ensure we do not create such interoperability or security problems in the future. The primary mission is accomplished with new guidance to designated experts. The secondary mission is to allow for implementations that need to resolve these interoperability problems that exist today to do so. The secondary mission can be accomplished with new registry entries, if and only if, the working groups consider it to be "worth it". If folks considered EdDSA to be worth it, and RSA to be "not worth it", I wouldn't object to that... But I would object to an inconsistent definition of parameters and their relationship to fully specified algorithms... we don't want to set up future curveball attacks on lattice or unbalanced oil and vinegar signature schemes and their associated keys, by allowing for parameters to differ for the same algorithm identifier. OS -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
