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]> 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]> Date: Wednesday, 12 June 2024 at 19:13 To: Göran Selander <[email protected]>, Karen ODonoghue <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[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]> Sent: Wednesday, June 12, 2024 1:14 AM To: Karen ODonoghue <[email protected]>; [email protected] Cc: [email protected]; [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]
