[COSE] Gunter Van de Velde's No Objection on draft-ietf-cose-typ-header-parameter-04: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-cose-typ-header-parameter-04: No Objection

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-cose-typ-header-parameter/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please find here some observations during processing of the draft. Please use
or ignore as you find appropriate.

The document uses a significant number abbreviations. For generalists as
myself, maybe consider adding a section to spell out the three letter acronyms
together with pointers to references.

This review uses line numbers as found with the idnits tool.

13         This specification adds the equivalent of the JSON Object Signing and
14         Encryption (JOSE) typ (type) header parameter to CBOR Object Signing
15         and Encryption (COSE) so that the benefits of explicit typing, as
16         defined in the JSON Web Token Best Current Practices BCP, can be
17         brought to COSE objects.  The syntax of the COSE type header
18         parameter value is the same as the existing COSE content type header
19         parameter.

This complete paragraph does not have any reference pointers, making it rather
difficult for generalists to process. The abstract has a single giant phrase
stretching from line 13 through 17 making the abstract intense to process.
consider cutting up in smaller chunks for readability. What are 'the benefits
of explicit' typing being referred towards? What is 'explicit typing'? Maybe i
do not know because i am not familiar with these technologies? (there seems a
short pointer in a later section in the document) What is CBOR acronym? When
reading the abstract, as a generalist, it is unclear what exactly the document
is trying to achieve.

I had to look up what 'CBOR Object Signing and Encryption (COSE)' stands for.
consider for generalists to spell out abbreviations to help better understand.
(I had to research and discover that COSE it is a specification that defines a
data format for encoding and processing cryptographic objects using Concise
Binary Object Representation (CBOR).)

74         typ (type) header parameter, which is used for declaring the type of
75         the entire JOSE data structure.  The security benefits of having typ
76         (type) are described in Section 3.11 of the JSON Web Token Best

Is there a particular reason why 'typ (type)' are always used together? i
assume it is for readability? RFC8725 for example seems to have fixed this with
consistent usage of "typ" to avoid always writing the combination of typ (type)

77         Current Practices [RFC8725], which recommends its use for "explicit
78         typing" -- using typ values to distinguish between different kinds of
79         JWTs.

What is a JWT?

89         The term "COSE object" is used in the same manner as in [RFC9052].
90         An example of a COSE object is a COSE_Sign1 structure, as described
91         in Section 4.2 of [RFC9052].

This text seems to be written as if there are multiple manners to use the term
"COSE object"? If there are multiple manners, should that be more explicit
identified for clarity?

101     2.  COSE "typ" (type) header parameter

103        The typ (type) header parameter is used by COSE applications to
104        declare the type of this complete COSE object, as compared to the
105        content type header parameter, which declares the type of the COSE

There seems to be mixed usage of "typ" and typ. it distracts reading the
document due to inconsistency. Also line105 references the type, but should
that not be typ header parameter to be correct with the naming of the field?

143        COSE applications employing explicit typing should reject COSE
144        objects with a type header parameter value different than values that
145        they expect in that application context.  They should also reject
146        COSE objects without a type header parameter when one is expected.

is there benefit for BCP14 style language in this section?