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 <jodon...@qti.qualcomm.com> Date: Thursday, 13 June 2024 at 12:04 To: John Mattsson <john.matts...@ericsson.com>, Michael Jones <michael_b_jo...@hotmail.com>, Göran Selander <goran.selan...@ericsson.com>, Karen ODonoghue <kodo...@gmail.com>, j...@ietf.org <j...@ietf.org> Cc: cose@ietf.org <cose@ietf.org>, l...@ietf.org <l...@ietf.org> 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" <john.mattsson=40ericsson....@dmarc.ietf.org> 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 <michael_b_jo...@hotmail.com> Date: Wednesday, 12 June 2024 at 19:13 To: Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org>, Karen ODonoghue <kodo...@gmail.com>, j...@ietf.org <j...@ietf.org> Cc: cose@ietf.org <cose@ietf.org>, l...@ietf.org <l...@ietf.org> 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 <goran.selander=40ericsson....@dmarc.ietf.org> Sent: Wednesday, June 12, 2024 1:14 AM To: Karen ODonoghue <kodo...@gmail.com>; j...@ietf.org Cc: cose@ietf.org; l...@ietf.org 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 <jose-boun...@ietf.org<mailto:jose-boun...@ietf.org>> on behalf of Karen ODonoghue <kodo...@gmail.com<mailto:kodo...@gmail.com>> Date: Monday, 6 May 2024 at 07:31 To: j...@ietf.org<mailto:j...@ietf.org> <j...@ietf.org<mailto:j...@ietf.org>> 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
_______________________________________________ COSE mailing list -- cose@ietf.org To unsubscribe send an email to cose-le...@ietf.org
