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. # 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"? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Expand JOSE/COSE in the title # Abstract (1) Delete "etc." as "including" is expected to provide concrete examples. (2) s/being "fully specified"/being "fully-specified" (to be consistent with the use in the document) # 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." * Cite authoritative references to COSE/JOSE # "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"? # 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 ^^^^ encryption schemes JSON Web Encryption, (JWE) as described in ^^^^^^^^ (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. (3) cite where the outer "alg" is defined CURRENT: To perform fully-specified encryption in COSE, the outer "alg" value # 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. # 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. # 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. # 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". Cheers, Med _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
