Thanks for your thoughts, Göran and Marco. We added this qualifying language to the Deprecated definition exactly to make it clear that situations like that for EDHOC are fine: "unless there exist documented operational or regulatory requirements that prevent migration away from the deprecated identifier". Göran, as I see it the "operational requirement" that EDHOC has is that the existing EDHOC cipher suites be used. I'll note that these already appear to already be fully-specified. For instance EDHOC suite 0 specifies that X25519 is used with EdDSA. So I think you're already well covered by the existing language. I don't see a need to call out EDHOC in specific in the definition, as its situation is already covered by the general language.
Marco, I'm not comfortable with your proposed language changing the qualifier to "unless the deprecated identifier is used in constructs that fully specify the cryptographic operations to be performed" because that's narrower than the existing qualifying language and doesn't cover all the use cases. Remember that the definition is intended to be general. There are lots of reasons that an algorithm identifier might be deprecated - not just because it isn't fully-specified. Indeed, the recently adopted draft-madden-jose-deprecate-none-rsa15<https://datatracker.ietf.org/doc/draft-madden-jose-deprecate-none-rsa15/> is an example of deprecating algorithms for other reasons. That said, I'm here at IETF 121 and would be glad to talk with both of you in person to work on refining the qualifying language in the definition. I would want any revisions to it to be general-purpose, covering all the use cases, and not be specific to any particular specifications. Best wishes, -- Mike From: Marco Tiloca <[email protected]> Sent: Saturday, November 2, 2024 4:51 PM To: Göran Selander <[email protected]>; Michael Jones <[email protected]>; [email protected]; [email protected] Subject: [COSE] Re: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms) Hi all, I have the same concerns that Göran raised on the definition of "Deprecated". I find the latest text from Göran to be better and more appropriate. Building on that, I suggest a further, slightly shorter version: NEW_MT: 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 the deprecated identifier is used in constructs that fully specify the cryptographic operations to be performed, for example in EDHOC cipher suites. Best, /Marco On 2024-10-31 09:55, Göran Selander wrote: Hi Mike, My remaining issue at the end below. From: Michael Jones <[email protected]><mailto:[email protected]> Date: Monday, 21 October 2024 at 21:47 To: Göran Selander <[email protected]><mailto:[email protected]>, [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>, [email protected]<mailto:[email protected]> <[email protected]><mailto:[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]><mailto:[email protected]> Sent: Thursday, September 5, 2024 1:30 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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 _______________________________________________ COSE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se<https://www.ri.se/>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
