Hi Paul,
The proposed resolutions to your feedback have been incorporated into https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-13.html. Thanks again, -- Mike From: Paul Wouters <[email protected]> Sent: Thursday, May 8, 2025 6:56 AM To: Michael Jones <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Paul Wouters' Discuss on draft-ietf-jose-fully-specified-algorithms-11: (with DISCUSS and COMMENT) Hi Mike, Thanks for discussing and addressing my concerns. I will update my ballot to No Objection once the new draft lands. Paul On Thu, May 8, 2025 at 8:18 AM Michael Jones <[email protected]<mailto:[email protected]>> wrote: Hi Paul. Thanks for your diligent review. My replies are inline below, prefixed by "Mike>". -----Original Message----- From: Paul Wouters via Datatracker <[email protected]<mailto:[email protected]>> Sent: Thursday, May 8, 2025 3:56 AM To: The IESG <[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]>; [email protected]<mailto:[email protected]> Subject: Paul Wouters' Discuss on draft-ietf-jose-fully-specified-algorithms-11: (with DISCUSS and COMMENT) Paul Wouters has entered the following ballot position for draft-ietf-jose-fully-specified-algorithms-11: 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: ---------------------------------------------------------------------- Thanks to Kathleen Moriarty for the SecDir review. Thanks to the authors for resolving her comments. I have a few hopefully minor DISCUSS items I would like to raise: I think the Abstract should say a little more on what it updates on the mentioned RFCs? eg the Recommended status of some algorithms specified? Mike> Agreed - will do. Some of the updates were to deprecate registered algorithms. Some of the updates were to the instructions to the designated experts. Section 2.1: What does "COSE Recommended" mean? Is this defined anywhere? Eg for TLS this is defined in the IANA registry. It needs to be clear whether it means mandatory to implement or not. Mike> This is defined in https://www.rfc-editor.org/rfc/rfc8152#section-16.4, with the definition: Recommended: Does the IETF have a consensus recommendation to use the algorithm? The legal values are 'Yes', 'No', and 'Deprecated'. Mike> Of course, this spec expands the set of legal values, as described in Section 4.4. Notably, this definition was not carried forward into the specifications that obsoleted RFC 8152. I think it makes sense to carry this definition forward into this specification, with the corresponding updates made. Section 2.2: See above, but in addition also "JOSE Implementation Requirements". Are "Recommended" and "Implementation Requirements" different things or the same thing? Mike> They are similar things. The "JOSE Implementation Requirements" definition from https://www.rfc-editor.org/rfc/rfc7518.html#section-7.1 is: JOSE Implementation Requirements: The algorithm implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-". The use of "+" indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification. Any identifiers registered for non-authenticated encryption algorithms or other algorithms that are otherwise unsuitable for direct use as JWS or JWE algorithms must be registered as "Prohibited". Mike> This document doesn't update this definition, nor is RFC 7518 obsoleted, so I don't feel the need to carry it forward here. Perhaps this document can ask IANA to add a Note: similar to TLS at the top of their registry explaining this? I am also puzzled that for example ed25519 is "Recommended Y" for COSE but "Optional" for JOSE? Is this difference by design? Mike> This carries forward the existing recommendation values in the JOSE and COSE registries, applying them as-is to the corresponding fully-specified algorithms. The working group scoped this work only to making it possible to use fully-specified algorithms. It did not take on re-evaluating any existing algorithm recommendations. Section 6.1: How does an implementation know the RSA key size of the peer ? I assume since this doc isn't fixing it, that implementations have either a common unspecified default (in which case why not mention that here) or a way to deduce this (in which case why not mention that here) ? Why not help implementations interoperate by clarifying what is done when processing these incomplete polymorphic identifiers? Mike> The implementation knows the RSA key size by inspecting the key. It does not know, in general, if the other party is capable of using a key of that size. In practice, for RSA software implementations, they tend to work with all key sizes. Only for HSMs and highly controlled environments might some key sizes not work. (Also, for security reasons, https://www.rfc-editor.org/rfc/rfc7518.html#section-3.3 already says "A key of size 2048 bits or larger MUST be used with these algorithms.".) Section 7: A cryptographic key SHOULD be used with only a single algorithm unless the use of the same key with different algorithms is proven secure. I would use MUST instead of SHOULD here. The _only_ valid escape is the unless proven clause. No other unmentioned clauses exist, so MUST is more appropriate. Mike> Will do ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract: This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers and deprecates those polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. Please split up this runaway sentence. With the many "and"'s it is too hard to parse. Mike> OK. (It was shorter before the acronyms JOSE and COSE were expanded in response to another IESG comment. :-) ) Allow only authenticated content encryption algorithms. Maybe add "(e.g. an AEAD)" to give people a hint what this means? Mike> Sure Thanks again for your useful review! -- Mike P.S. As I also write in my response to Mike Bishop, I plan to make these updates soon after the telechat - possibly later today. I normally get these kinds of updates done before the telechat, but I was giving a keynote this morning at the European Identity Conference and am moderating sessions most of the day, so my bandwidth has been temporarily limited.
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
