Thanks to those who provided references to the definitions of the fields for
JOSE and COSE. Indeed, as Orie and I have discussed, one of the sources of
confusion is the differences between the JOSE and COSE definitions, which I
consider to be unfortunate.
In JOSE, there's a clear distinction between "Deprecated" and "Prohibited".
Identifiers such as "EdDSA" are being marked "Deprecated" - not "Prohibited",
therefore they can continue being used as needed.
The intent is the same for COSE, however the lack of a "Prohibited" value for
COSE makes the intent ambiguous. As both Jeremy and John suggest, we can look
at expanding the COSE definitions and clearly defining them to remove this
ambiguity in the next version of the draft.
Thanks all,
-- Mike
From: John Mattsson <[email protected]>
Sent: Thursday, June 13, 2024 6:07 AM
To: Jeremy O'Donoghue <[email protected]>; Michael Jones
<[email protected]>; Göran Selander <[email protected]>;
Karen ODonoghue <[email protected]>; [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms
Jeremy O'Donoghue wrote:
>It is not clear to me where the set of possible values for "Implementation
>Requirements" is defined
The set of possible values for "JOSE Implementation Requirements" is defined in
RFC 7518. The currently allowed values are Required, Recommended, Optional,
Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or
"-"."
The set of possible valies for the COSE "Recommended" is defined in RFC 8152
and RFC 9054. The currently allowed values are 'Yes', 'No', 'Deprecated', and
"Filter Only".
Jeremy O'Donoghue wrote:
>it seems to me that defining the older values as something like "Backward
>Compatibility" or "Recommended-" might offer a way forward.
+1 for this idea. I think both of these suggestions would be suitable.
"Recommended-" is already allowed. "Updated" might be a third alternative.
Cheers,
John Preuß Mattsson
From: Jeremy O'Donoghue
<[email protected]<mailto:[email protected]>>
Date: Thursday, 13 June 2024 at 12:04
To: John Mattsson
<[email protected]<mailto:[email protected]>>, Michael Jones
<[email protected]<mailto:[email protected]>>, Göran
Selander <[email protected]<mailto:[email protected]>>,
Karen ODonoghue <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: Re: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms
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]<mailto:[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]<mailto:[email protected]>>
Date: Wednesday, 12 June 2024 at 19:13
To: Göran Selander
<[email protected]<mailto:[email protected]>>,
Karen ODonoghue <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto:[email protected]>>
Sent: Wednesday, June 12, 2024 1:14 AM
To: Karen ODonoghue <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]
