Hi Orie, >I would say there is disagreement on the binding between keys and algorithms, >and >positions vary depending on which working group you ask.
My understanding talking to people is that there seems to be support to register new Fully-Specified Algorithms also in COSE. >Signatures being not fully specified seem to have less of an impact, but >guidance >moving forward should be clear, especially for PQ and Hybrid >Algorithms. Yes. I fully agree with the goal of specifying Fully-Specified Algorithms for everything people wants to use and to provide clear guidance for future registrations. >Perhaps a compromise would be to only register new code points for >Ed25519EdDSA / >Ed448EdDSA in JOSE and COSE and simply deprecate the other >algorithms without >additional allocations? I am very sure a lot of people want to continue to use ECDSA in COSE. My problem was not with registering new ECDSA algs, it was with deprecating the old algorithms that many people are using without problems. I also quite sure that people in COSE/JOSE want to continue to use RSA. Thinking more about RSA, one way to solve the negotiation problem for the RSA algorithms is if draft-ietf-jose-fully-specified-algorithms updates RFC 7518 and RFC 9053 to limit key lenghts to a subset and to specify that this subset must be supported. If we cannot agree on such a subset, then the current algorithms are clearly not fully specified. >Will be marking all the ECDSA / EdDSA / ECDH / DH stuff deprecated when a CRQC >arrives >anway. Yes, but but that is likely decades away if it ever happens at all. Cheers, John Preuß Mattsson From: Orie Steele <[email protected]> Date: Monday, 25 March 2024 at 18:24 To: John Mattsson <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [jose] Review of draft-ietf-jose-fully-specified-algorithms-02 I wouldn't say there is nothing wrong with those algorithms. I would say there is disagreement on the binding between keys and algorithms, and positions vary depending on which working group you ask. For example: https://mailarchive.ietf.org/arch/msg/tls/4CryTBuFG64IlMhpCEvE2tLjeeg/ Not all the changes COSE made were improvements, some of the differences from JOSE are mistakes, and have gone against security guidance, and leaned into the "a-la-carte" cryptographic suite approach, which I believe we have learned to avoid in protocols. In COSE, algorithms such as ECDH-ES + HKDF-256 and ECDH-ES + A128KW not committing to the algorithm used with the content encryption key, have introduced attacks, which we are still discussing how to clean up: https://www.rfc-editor.org/rfc/rfc9459.html#section-8 As evidenced above ^ deprecation without replacement is possible... when there is no other option. Signatures being not fully specified seem to have less of an impact, but guidance moving forward should be clear, especially for PQ and Hybrid Algorithms. Perhaps a compromise would be to only register new code points for Ed25519EdDSA / Ed448EdDSA in JOSE and COSE and simply deprecate the other algorithms without additional allocations? Will be marking all the ECDSA / EdDSA / ECDH / DH stuff deprecated when a CRQC arrives anway. Regards, OS On Wed, Mar 20, 2024 at 6:17 PM John Mattsson <[email protected]<mailto:[email protected]>> wrote: Hi, It would be good with more discussion of the draft in COSE. Some people go to both COSE and JOSE, but many people are strictly interested in one of them. One more comment: I think the deprecations are problematic: - JOSE EdDSA - COSE ES256 (-7) - COSE ES384 (-35) - COSE ES512 (-36) - COSE EdDSA (-8) - There is nothing wrong with these algorithms in systems that do not need to do negotiate capabilities using the algorithm identifiers. A lot of systems are using these algorithms without problem. They are also hardcoded in other RFCs and external specifications. - COSE: Deprecating ES256 (-7) and EdDSA (-8) and registering ESP256 (-9) and Ed25519 (-50) adds one (or more) byte for people using Ed25519 in COSE and uses one more of the rare 1 byte identifiers. Cheers, John Preuß Mattsson From: jose <[email protected]<mailto:[email protected]>> on behalf of John Mattsson <[email protected]<mailto:[email protected]>> Date: Thursday, 21 March 2024 at 09:55 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [jose] Review of draft-ietf-jose-fully-specified-algorithms-02 Hi, - “6.1. Algorithms for Signing with RSASSA-PKCS1-v1_5” Probably better to call this “6.1 RSA Algorithms” as is applies to RS*, PS*, and RSAES-OAEP. - “The working group has discussed whether the RS256, RS384, and RS512 algorithms should be considered fully-specified or not” I think the groups needs to decide if registrations like this should be allowed in the future. This should be clear if someone want to specify similar algorithms. - “This is not a problem in practice, because RSA libraries accommodate keys of different sizes without having to use different code.” This is not always true. I know of still deployed RSA implementations that only support up to RSA-2048. But this was not COSE/JOSE. I would however not be surprised if COSE implementations on very constrained devices run out of memory if they are given a large RSA key. - HSS-LMS is not fully specified. Maybe that should be mentioned. Cheers, John Preuß Mattsson _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose -- ORIE STEELE Chief Technology Officer www.transmute.industries [Image removed by sender.]<https://transmute.industries/>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
