Hi Mike, My remaining issue at the end below.
From: Michael Jones <[email protected]> Date: Monday, 21 October 2024 at 21:47 To: Göran Selander <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms) Thanks for your comments, Göran. See the updates to the specification in https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-06.html. My replies are inline below, prefixed by “Mike>”. -- Mike From: Göran Selander <[email protected]> Sent: Thursday, September 5, 2024 1:30 AM To: [email protected]; [email protected] Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms) (About target audience: This draft is proposing to deprecate algorithms in the COSE IANA registry. It would be great if it by default was circulated also on the COSE WG mailing list to enable a timely discussion among those affected.) Mike> Agreed With reference to a previous thread on this topic: https://www.mail-archive.com/[email protected]/msg03799.html The term “deprecated” is still used in this draft with a different meaning compared to RFC8996 and RFC9325. It doesn’t help that you in this document point out that you are using the word with a different meaning that people are used to, very much fewer people will read this document than those that stumble on the term used in registries and understand it from other contexts. Moreover, this overload of terminology is actually unnecessary: Section 4.4 > The terms "Deprecated" and "Prohibited" as used by JOSE and COSE > registrations are currently undefined. So, in fact this provides a unique opportunity to disambiguate and avoid the otherwise inevitable confusion that will come up over and over again arising from the use of the same term with different meanings. A number of perfectly good alternative terms were suggested in the referenced mail thread. Mike> Yes, there were not definitions of “Deprecated” and “Prohibited” previously in the specifications, but I will observe that the use of both terms in RFC 7518 makes the distinction pretty clear in context based on the plain English meanings of the terms. “Prohibited” means that an algorithm must not be used. “Deprecated” means that an alternative algorithm should be used, when possible. The specification clearly and consistently defines both of those terms in a way that’s applicable to both JOSE and COSE. Mike> Furthermore, and I consider this a big plus. these definitions don’t require any changes to existing JOSE or COSE registrations. Nor do they require defining new terms that were not already in use. Many of the other terminology proposals don’t share these advantages, which is why we went with this one. I’ll also observe that some reviewers explicitly thanked us for the clear terminology definitions. Moreover, for systems that makes use of the COSE IANA registry and specifies algorithms with enough parameters to make them completely determined, for example EDHOC cipher suites, there is no need to change or abandon the use of the current algorithms. Hence the recommendation (“SHOULD”) in the definition does not apply to such systems, and that circumstance should be stated as an exception to the recommendation. Mike> We added text describing circumstances in which it makes sense to continue using deprecated algorithms, per your suggestion. GS: I maintain that “deprecated” is not a good choice of terminology, and it will lead to misunderstandings for example from people coming from the TLS world. But I’m happy to note that you acknowledge and describe a setting for the continued use of these algorithms. However, the text following “unless” does not capture all cases when this is true: OLD Deprecated There is a preferred mechanism to achieve similar functionality to that referenced by the identifier; this replacement functionality SHOULD be utilized in new deployments in preference to the deprecated identifier, unless there exist documented operational or regulatory requirments that prevent migration away from the deprecated identifier. GS: For example in case of EDHOC, there are no documented operational or regulatory requirements that prevent migration; there is simply no need to change or use other algorithms for new deployments because the algorithms are used in ciphersuites which are fully specified. Here is a proposed rephrasing: NEW There is a preferred mechanism to achieve similar functionality to that referenced by the identifier; this replacement functionality SHOULD be utilized in new deployments in preference to the deprecated identifier, unless they are used in constructs where the cryptographic algorithm identifiers fully specify the cryptographic operations to be performed, for example in EDHOC ciphersuites. GS: The explicit reference to EDHOC is needed to mitigate the inevitable confusion that will come when people wonder why deprecated algorithms are used, following this choice of terminology. Göran
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
