[jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)

[Michael Jones <[e-mail]>]

Thanks for your comments, Filip.  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, prefixed by "Mike>".

From: Filip Skokan <[e-mail]>
Sent: Monday, September 9, 2024 1:28 PM
To: [e-mail]; [e-mail]
Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)

I would like to thank the authors for their diligent work on the document. Here's my 2nd WGLC feedback

I am comparing the document status before the first WGLC (draft 02) and now<https://author-tools.ietf.org/iddiff?url1=draft-ietf-jose-fully-specified-algorithms-02&url2=draft-ietf-jose-fully-specified-algorithms-05&difftype=--html>. I appreciate the new section 4.4. Defining Deprecated and Prohibited and am also recognizing the new COSE ECDSA registrations that enable continued use of Brainpool curves with COSE in a fully-specified manner.

Mike> Thanks for your support of the specification.

I am not certain about which discussion led to the entirety of section 3. Fully-Specified Encryption, nevertheless in its language it states

> Each of these multiple algorithms must be independently fully specified.  The operations performed by each of them MUST NOT vary when used alongside other algorithms.  So for instance, for JOSE, alg values and enc values MUST each be fully specified, and their behaviors MUST NOT depend upon one another.

This would not be the case for either one of the JOSE ECDH-ES proposed algorithms (which were presented at the last meeting), in each of them "enc" informs "alg" about the expected CEK length output. Additionally, in ECDH-ES direct the "enc" value is directly used in ConcatKDF too.
I'm not sure whether the contradiction between this text in section 3.1. and the above is okay or not given that the document no longer specifies any new ECDH algorithm identifiers. FWIW in 3.3.1. it clearly states the existing algorithms are not fully-specified but are polymorphic so this text wouldn't disqualify them. It is nevertheless confusing.

Mike> Both you and Neil pointed out this vestigial erroneous text, which has now been removed.  Furthermore, the exposition in Section 3 has been significantly tightened.

>From section 3.3.1.  Elliptic Curve Diffie-Hellman (ECDH)

> While Appendix A describes possible fully-specified ECDH algorithms that could be registered for JOSE and COSE, the working group decided to leave decisions about which fully-specified ECDH algorithms to register to future specifications, if needed.

This is not true because these would not be fully-specified; the "alg" ConcatKDF always use of elements from "enc", i.e. they depend on one another. While I asked that at least the algorithm identifiers be removed from Appendix A (which was done and it fulfilled my feedback from the IETF meeting during which granted, I was remote and half asleep), I came to think the entirety of Appendix A should probably be removed instead.

Mike> This inheritance is now explicitly described in the specification.

>From section 3.2. Analysis of Modes of Encryption

> It does register a small set of new fully-specified encryption algorithms, so that polymorphic encryption algorithms need not be used.

It doesn't anymore.

Mike> Corrected

Because the list feedback seems to circle around the encryption bits over and over again and even contradicting itself at one point, I would like to propose to remove section 3 and only focus on the Fully-Specified Digital Signature Algorithm Identifiers. I'm hoping to be able to start transitioning away from the "EdDSA" algorithm identifier soon.

Mike> There's no doubt that the situation for encryption is more complicated than that for signing - in part, because multiple algorithms are used in combination.  That's exactly why the encryption discussion (having corrected it and tightened it) provides valuable information to readers.  And again, other reviewers have explicitly thanked us for including the discussion of encryption and consider it to be in scope.

Mike> As for transitioning away from ECDH, I'll suggest that it would be useful to have your help advancing draft-ietf-jose-hpke-encrypt. ;-)

                                                                Děkuju,
                                                                -- Mike
S pozdravem,
Filip Skokan


On Thu, 5 Sept 2024 at 10:29, Göran Selander <goran.selander=[e-mail]<mailto:[e-mail]>> wrote:
(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.)

With reference to a previous thread on this topic:
https://www.mail-archive.com/[e-mail]/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.

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.


In summary


  *   use a different term
  *   make it clear that current algorithms may be used in case a separate specification adds the necessary information to make them fully specified


Göran


From: John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>>
Date: Thursday, 22 August 2024 at 11:10
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [COSE] FW: [jose] 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)
Forwarding to the COSE list as the document updates both RFC 8152 and RFC 9053.

Cheers,
John

From: Karen ODonoghue <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 21 August 2024 at 16:12
To: JOSE WG <[e-mail]<mailto:[e-mail]>>
Subject: [jose] 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)
JOSE working group members,

This email initiates a second working group last call for the Fully
Specified Algorithms document:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-jose-fully-specified-algorithms%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4d5ca1448df945ce272908dcc1eb446e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638598463418037480%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lC1d%2Bvw9fTh%2FG2brNNztghIYFbp4pnGwjqvfN%2Bbqrn8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/>

The authors have updated the draft based on WGLC comments and
discussions at IETF 120, and the chairs have polled the working group
about the readiness for WGLC. Seeing no opposition, we've decided to
proceed with a second WGLC.

Please review the document in detail and reply to this message
(keeping the subject line intact) with your opinion on the readiness
of this document for publication and any additional comments that you
have.

This will be a three week WGLC. Please submit your responses by 13
September 2024.

Thank you,
Karen (for the JOSE WG chairs)

_______________________________________________
jose mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
jose mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>