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]> 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]> > Sent: Thursday, May 8, 2025 3:56 AM > To: The IESG <[email protected]> > Cc: [email protected]; > [email protected]; [email protected]; [email protected]; [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]
