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? 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. Section 2.2: See above, but in addition also "JOSE Implementation Requirements". Are "Recommended" and "Implementation Requirements" different things or the same thing? 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? 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? 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. ---------------------------------------------------------------------- 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. Allow only authenticated content encryption algorithms. Maybe add "(e.g. an AEAD)" to give people a hint what this means? _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
