Hi again Mohamed,
I understand your logic about the updated registrations, but in my view all of
4.1.1, 4.1.2, 4.2.1, and 4.2.2 are performing IANA registration actions, so the
introductory text in 4.1 and 4.2 applies. The fact that the registration
actions in 4.1.2 and 4.2.2 are replacing existing registrations doesn’t make
them not registrations.
Anway, thanks again for the very detailed and thoughtful review. In my view,
the changes we made in response to your comments significantly improved the
exposition in several ways!
-- Mike
From: [email protected] <[email protected]>
Sent: Sunday, May 4, 2025 11:57 PM
To: Michael Jones <[email protected]>; Deb Cooley
<[email protected]>
Cc: The IESG <[email protected]>;
[email protected]; [email protected];
[email protected]; [email protected]
Subject: RE: Mohamed Boucadair's Discuss on
draft-ietf-jose-fully-specified-algorithms-09: (with DISCUSS and COMMENT)
Hi Michael,
Thanks for the follow-up and clarifications. This version addresses the DISUCSS
points and most of the comments. Will update my ballot right now.
One quick comment on the IANA part, the reason I initially to move some text is
that we say in S4.1 that
This section registers the following values in the IANA "JSON Web
Signature and Encryption Algorithms" registry [IANA.JOSE] established
by [RFC7515].
Which is done in S4.1.1, but not S4.1.2. S4.1.2 is not about registering new
algorithm names but updating a statis as adequately indicated in the preamble
text:
The following registration is updated to change its status to
Deprecated.
Idem for 4.2.
I’m not insisting on making any further change here, but want to explain the
reasoning.
Cheers,
Med
De : Michael Jones
<[email protected]<mailto:[email protected]>>
Envoyé : lundi 5 mai 2025 08:39
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>; Deb Cooley
<[email protected]<mailto:[email protected]>>
Cc : The IESG <[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]>
Objet : RE: Mohamed Boucadair's Discuss on
draft-ietf-jose-fully-specified-algorithms-09: (with DISCUSS and COMMENT)
Thanks for your super-useful review, Mohamed. I believe addressing your
comments significantly improved the specification!
As you’ve probably seen, a draft incorporating the PR addressing your and
Roman’s comments has now been published at
https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-10.html.
Responses to your individual suggestions are below, prefixed by “Mike>”.
Can you please update your ballot position to “No objection” or “Yes”, based on
these resolutions?
Thanks again,
-- Mike
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Sunday, May 4, 2025 10:54 PM
To: Deb Cooley <[email protected]<mailto:[email protected]>>
Cc: The IESG <[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: Mohamed Boucadair's Discuss on
draft-ietf-jose-fully-specified-algorithms-09: (with DISCUSS and COMMENT)
Hi Deb,
Thanks for the note. I confirm that I have read that blob as part of the
write-up from Karen. I don’t think we need to go that path.
Michael’s PR is great
(https://github.com/ietf-wg-jose/draft-ietf-jose-fully-specified-algorithms/pull/31),though.
Looking forward seeing the new version.
Cheers,
Med
De : Deb Cooley <[email protected]<mailto:[email protected]>>
Envoyé : jeudi 1 mai 2025 21:28
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>
Cc : The IESG <[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]>
Objet : Re: Mohamed Boucadair's Discuss on
draft-ietf-jose-fully-specified-algorithms-09: (with DISCUSS and COMMENT)
Please note that the ballot text explains the update of an obsoleted RFC.
Deb
On Mon, Apr 28, 2025 at 11:56 AM Mohamed Boucadair via Datatracker
<[email protected]<mailto:[email protected]>> wrote:
Mohamed Boucadair has entered the following ballot position for
draft-ietf-jose-fully-specified-algorithms-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi Michael & Orie,
Thanks for the effort put into this specification.
I like the clarity provided by the definition of "deprecated" and "prohibited",
especially in reference to deployment impacts.
I have two DISCUSS points and some very minor comments.
# Update an obsoleted RFC
It seems weird to me that we are updating an obsoleted RFC (RFC8152). Maybe
cleaner to include a complete updated definition of the "Recommended" column.
Mike> We no longer update the obsoleted RFC.
# The update may not be complete
CURRENT:
(Note that [RFC9053] did not carry the definitions of
the "Recommended" registry columns forward, so [RFC8152] remains
definitive in this regard.)
I'd like to double check this part. RFC8152 says:
Recommended: Does the IETF have a consensus recommendation to use
the algorithm? The legal values are 'Yes', 'No', and
'Deprecated'.
However, other values are used in the registry (Filter Only, for example).
Where that value is defined as "legal"?
Mike> Per your suggestion Mohamed, there’s now a complete list of the
Recommended terms, with references to where they’re defined.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Expand JOSE/COSE in the title
Mike> I did this in the Abstract and Introduction, but not the title. It’s a
matter of taste, but expanding both JOSE and COSE in the title would have made
the title very long.
# Abstract
(1) Delete "etc." as "including" is expected to provide concrete examples.
Mike> Done
(2) s/being "fully specified"/being "fully-specified" (to be consistent with
the use in the document)
Mike> As I learned in past interactions with the RFC Editor, the hyphenated
form (fully-specified) is right for adjective phrases, where as the
unhyphenated form (full specified) is right for use as a standalone adjective.
This case is the latter.
# Introduction
CURRENT:
Fully Specified
Those that fully determine the cryptographic operations to be
performed, including any curve, key derivation function (KDF), and
hash functions, etc. Examples are RS256 and ES256K in both JOSE
and COSE and ES256 in JOSE.
* Delete "etc."
Mike> Done
* Cite authoritative references to COSE/JOSE
Mike> Done
# "current"
[RFC9053] defines the current use of the Elliptic Curve Digital
Signature Algorithm (ECDSA) by COSE.
and
[RFC8037] defines the current use of the Edwards-Curve Digital
Signature Algorithm (EdDSA) by JOSE and [RFC9053] defines its current
use by COSE.
What do we mean by "current" here? Do we mean "initial"?
Mike> Revised to eliminate "current"
# Section 3
(1) Please check the following
CURRENT:
This section describes the construction of fully-specified encryption
algorithm identifiers in the context of existing the JOSE and COSE
^^^^
Mike> Fixed
encryption schemes JSON Web Encryption, (JWE) as described in
^^^^^^^^
Mike> Fixed
(2) What is meant by "essential" in the following (and other similar
occurrences)? Do we mean "required"? Mandatory? something else?
CURRENT:
To perform fully-specified encryption in JOSE, the "alg" value MUST
specify all essential parameters for key establishment or derive some
of them from the accompanying "enc" value and the "enc" value MUST
specify all essential parameters for symmetric encryption.
Mike> Deleted "essential"
(3) cite where the outer "alg" is defined
CURRENT:
To perform fully-specified encryption in COSE, the outer "alg" value
Mike> Done
# Section 4.1
CURRENT:
This section registers the following values in the IANA "JSON Web
Signature and Encryption Algorithms" registry [IANA.JOSE] established
by [RFC7515].
Move the text to be under 4.1.1 given that 4.1.2 is about updating a
registration.
Mike> I didn’t do this because the text applies to both 4.1.1 and 4.1.2, since
both perform registrations. 4.1.1 performs new registrations and 4.1.2
performs registrations updating existing registraitons. So by my editorial
judgement, the current placement is appropriate.
# Section 4.2
CURRENT:
This section registers the following values in the IANA "COSE
Algorithms" registry [IANA.COSE].
Move to text to be under 4.2.1.
Mike> Ditto
# Section 4.4
CURRENT:
(Identifiers MAY be designated as "Prohibited" due to
security flaws, for instance.)
Inappropriate use of normative language as this is an example. s/MAY/may.
Mike> Fixed
# Section 6
This is a general comment for this section.
What is the value of having this in the final RFC? We don't document all points
discussed by WG, after all.
The final document will reflect the IETF consensus. I would delete at least all
mentions with "The working group has discussed".
Mike> Good point ! All the references to working group discussions have been
replaced by declarative sentences about what the specification actually does.
Cheers,
Med
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
