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]> Envoyé : lundi 5 mai 2025 08:39 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Deb Cooley <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [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]
