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

[Filip Skokan <[e-mail]>]

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.

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.

>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.

>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.

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.

S pozdravem,
*Filip Skokan*


On Thu, 5 Sept 2024 at 10:29, Göran Selander <goran.selander=
[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]>
> *Date: *Thursday, 22 August 2024 at 11:10
> *To: *[e-mail] <[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]>
> *Date: *Wednesday, 21 August 2024 at 16:12
> *To: *JOSE WG <[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]
> To unsubscribe send an email to [e-mail]
> _______________________________________________
> jose mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>