Mike Jones wrote: >one of the sources of confusion is the differences between the JOSE and COSE >definitions, which I consider to be unfortunate.
Yes, COSE has already aligned with how the rest of the IETF like BCP 195 (RFC8996 and RFC9325) uses the term deprecated. I think it would be good if JOSE did the same. Cheers, John From: Michael Jones <[email protected]> Date: Thursday, 13 June 2024 at 18:12 To: John Mattsson <[email protected]>, Jeremy O'Donoghue <[email protected]>, Göran Selander <[email protected]>, Karen ODonoghue <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms Thanks to those who provided references to the definitions of the fields for JOSE and COSE. Indeed, as Orie and I have discussed, one of the sources of confusion is the differences between the JOSE and COSE definitions, which I consider to be unfortunate. In JOSE, there’s a clear distinction between “Deprecated” and “Prohibited”. Identifiers such as “EdDSA” are being marked “Deprecated” – not “Prohibited”, therefore they can continue being used as needed. The intent is the same for COSE, however the lack of a “Prohibited” value for COSE makes the intent ambiguous. As both Jeremy and John suggest, we can look at expanding the COSE definitions and clearly defining them to remove this ambiguity in the next version of the draft. Thanks all, -- Mike From: John Mattsson <[email protected]> Sent: Thursday, June 13, 2024 6:07 AM To: Jeremy O'Donoghue <[email protected]>; Michael Jones <[email protected]>; Göran Selander <[email protected]>; Karen ODonoghue <[email protected]>; [email protected] Cc: [email protected]; [email protected] Subject: Re: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms Jeremy O'Donoghue wrote: >It is not clear to me where the set of possible values for “Implementation >Requirements” is defined The set of possible values for "JOSE Implementation Requirements" is defined in RFC 7518. The currently allowed values are Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-"." The set of possible valies for the COSE "Recommended" is defined in RFC 8152 and RFC 9054. The currently allowed values are 'Yes', 'No', 'Deprecated', and "Filter Only". Jeremy O'Donoghue wrote: >it seems to me that defining the older values as something like “Backward >Compatibility” or “Recommended-“ might offer a way forward. +1 for this idea. I think both of these suggestions would be suitable. “Recommended-“ is already allowed. "Updated" might be a third alternative. Cheers, John Preuß Mattsson From: Jeremy O'Donoghue <[email protected]<mailto:[email protected]>> Date: Thursday, 13 June 2024 at 12:04 To: John Mattsson <[email protected]<mailto:[email protected]>>, Michael Jones <[email protected]<mailto:[email protected]>>, Göran Selander <[email protected]<mailto:[email protected]>>, Karen ODonoghue <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms Having read the I-D and RFC8996, I agree with John and Göran. Strong “-1” on the term “deprecated” The meaning of the term “deprecated” needs to be well-defined before it can be used. It seems to me that definition used in RFC8996 and RFC9325 is very clear-cut. The text says: “Removing support for older versions from implementations…” Pretty clear that recent IETF usage of “deprecated” is equivalent to “remove support for as soon as reasonably practicable”. I know of other organizations that have different interpretations for the word, but they define their usage within a glossary. It is not clear to me where the set of possible values for “Implementation Requirements” is defined, but it seems to me that defining the older values as something like “Backward Compatibility” or “Recommended-“ might offer a way forward. Best regards Jeremy On 13/06/2024, 09:23, "John Mattsson" <[email protected]<mailto:[email protected]>> wrote: WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Mike Jones wrote: >What deprecation DOES do is indicate that new applications and specifications >should choose the >fully-specified algorithms instead. What do you base this on? My understanding is that JOSE and COSE documents does not define the term “deprecated” at all. Typical use of the term “deprecated” in IETF is extremely negative. In the recent BCP 195 (2021) deprecated means MUST not offer, MUST not permit negotiation, and MUST not use. https://www.rfc-editor.org/rfc/rfc8996.html Readers of the JOSE and COSE registries are very likely to interpret “deprecated” based on how it is typically used in the IETF, i.e., like in BCP 195. I think marking algorithms as deprecated would lead to huge problems in deployed systems. Cheers, John Preuß Mattsson From: Michael Jones <[email protected]<mailto:[email protected]>> Date: Wednesday, 12 June 2024 at 19:13 To: Göran Selander <[email protected]<mailto:[email protected]>>, Karen ODonoghue <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms Deprecation of the polymorphic signing algorithms WILL NOT break existing usages that already work, including those in RFC 9528. They can continue without any impact. What deprecation DOES do is indicate that new applications and specifications should choose the fully-specified algorithms instead. I’ll note that RFC 9528 states that “Algorithms need to be specified with enough parameters to make them completely determined.” This is exactly the purpose of the Fully-Specified Algorithms specification. I hope this clears up any confusion. -- Mike From: Göran Selander <[email protected]<mailto:[email protected]>> Sent: Wednesday, June 12, 2024 1:14 AM To: Karen ODonoghue <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Lake] Re: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms (Adding cose and lake) Apologies for a late response, I just realized this also has an impact on registered COSE algs. The deprecation of COSE algorithm registrations in section 3.2.2 of draft-ietf-jose-fully-specified-algorithms-02 breaks the construction of cipher suites in RFC 9528/9529. This is implemented in products on the market so the train has already left for this type of rearrangements of the IANA registry. I have nothing against registering more specified algorithms, but the existing registrations in 3.2.2 must not be deprecated. Göran From: jose <[email protected]<mailto:[email protected]>> on behalf of Karen ODonoghue <[email protected]<mailto:[email protected]>> Date: Monday, 6 May 2024 at 07:31 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms JOSE working group members, This email initiates a three week working group last call on the following document: https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/ All open issues have been resolved. Additionally there does not appear to be general support for including fully-specified ECDH algorithms. https://mailarchive.ietf.org/arch/msg/jose/ZHDlXENvTwjlWxTVQQ2hkNBX4dw/ Please review the document and post any final comments along with your recommendation on whether or not it is ready to proceed by the Monday 27 May. Thank you, JOSE chairs
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
