Hi Orie, >In JOSE and COSE, we use "alg" to "restrict a key to a specific algorithm".
Yes, but "alg" in both COSE_Key and JWK is OPTIONAL, and I don't think there are any security considerations. If you agree, and the draft is about security, I think it would good if the draft shortly discussed why "alg" in COSE_Key and JWK is a good thing and recommended that it is present, unless using the same key for different algs has been proven secure. https://eprint.iacr.org/2021/509 >Is your proposal to have RSA parameters be considered part of RSA algorithms? I was not proposing much at all. I just provided more details on why ”This is not a problem in practice, because RSA libraries accommodate keys of different sizes without having to use different code.” is not correct in general, which also Neil Madden pointed out. I am fine with just removing the above sentence or adding changing to "because COSE and JOSE RSA libraries" if there is data to back that up. >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? Yes. >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? Yes. Actually I think the current RSA algorithms identifiers would do as the domain parameters are already in the key. >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. That was my understanding as well. But there does not seem to be agreement regarding this: "I disagree with your statement that the draft is about interoperability, not security." https://mailarchive.ietf.org/arch/msg/jose/J7KC750Ka-73V-eYt957DX2ymIs/ Cheers, John (as an individual) From: Orie Steele <[email protected]> Date: Wednesday, 18 September 2024 at 19:12 To: cose <[email protected]>, JOSE WG <[email protected]> Cc: John Mattsson <[email protected]> Subject: Fully Specified Keys and draft-ietf-jose-fully-specified-algorithms 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 [Image removed by sender.]<https://transmute.industries/>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
