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]> 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. > > # 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]
