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 <john.mattsson= [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]> on behalf of John Mattsson > <[email protected]> > *Date: *Thursday, 21 March 2024 at 09:55 > *To: *[email protected] <[email protected]>, [email protected] <[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] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
