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

[Michael Jones <[e-mail]>]

Hi Gunter,

Thanks for taking the time to review the specification.  My responses are inline below, prefixed by "Mike>".

-----Original Message-----
From: Gunter Van de Velde via Datatracker <[e-mail]>
Sent: Friday, March 29, 2024 6:27 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Gunter Van de Velde's No Objection on draft-ietf-cose-typ-header-parameter-04: (with COMMENT)

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.

Mike> We've been following the practice of spelling out acronyms on first use and providing citations.  The one exception to providing citations in the Appendix, which I'll address below.

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.

Mike> When reviewing one of my early IETF drafts that became an RFC, an IETF old hand told me that the Abstract shouldn't contain citations.  That's because it will sometimes be published in places without the rest of the document, so the references there can't be followed.  Rather, all the references that would otherwise appear in the Abstract normally appear in the Introduction.  That's what we've done.

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.

Mike> Good suggestion.  I've broken it into two sentences.

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)

Mike> There's a reference to explicit typing in the Introduction.

What is CBOR acronym? When
reading the abstract, as a generalist, it is unclear what exactly the document
is trying to achieve.

Mike> CBOR stands for Concise Binary Object Representation.  It's become so pervasively used that some IETF contexts don't expand the acronym.  For instance, the working group name "CBOR Object Signing and Encryption (COSE)" doesn't expand it.  (And it would be weird to do so because you'd end up with the nested expansion "Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE)", which to me seems down-right odd and confusing.)

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).)

Mike> Again, there's a citation for COSE at its first use in the Introduction.  And at that reference, there's a citation for 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?

Mike> This follows the typographical conventions in RFC 7515, which defines the "typ" (type) header parameter.

RFC8725 for example seems to have fixed this with
consistent usage of "typ" to avoid always writing the combination of typ (type)

Mike> Either choice is reasonable.  We chose to follow the original typography.

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?

Mike> I've expanded this on first use in the Introduction to "JSON Web Tokens (JWTs) [RFC7519]".

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?

Mike> I agree that this wording could be improved.  I've changed it to "The term "COSE object" is used as defined in [RFC9052]."

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?

Mike> This intentionally parallels the definition in RFC 7515.

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?

Mike> Indeed, this language intentionally mirrors the language in BCP 225 (which is also RFC 8725).

Mike> The changes described above are in https://github.com/selfissued/draft-ietf-cose-typ-header-parameter/pull/10 (as are changes motivated by two other reviews).  I plan to merge it and publish mid-day Wednesday US Pacific Time unless I hear objections so that the new draft is ready for Thursday's IESG telechat.

                                Best wishes,
                                -- Mike