Hi all, Please find below some comments on this draft. Hope it helps!
Best, /Marco ================= [Title] I think that the title should not include the words "Chains of".A title that reflects the document content (and is also more closely aligned with that of the analogous RFC 9360) would be: "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing CBOR Web Tokens (CWTs)"
In fact: "carrying" applies to chains but also to bags; "referencing" does not apply to chains or bags, but rather to the end entity CWT.
[Abstract and Section 1]As a follow-up to the previous comment, the abstract and Section 1 can be revised to not focus specifically on chains, but on carrying/referencing CWTs.
[Section 2]* The key words are actually from BCP 14, so both RFC 2119 and RFC 8174 (not only RFC 2119).
[Section 4]
* It says:
> The referenced resource can be any of the following media types:
>
> * application/cwt {{RFC8392}}
>
> * application/cwt usage=chain (see {{chain}})
>
> When the application/cwt media type is used, the data is a encoded
according to RFC 8392. If the parameter "usage" is set to "chain", this
sequence indicates a CWT chain.
It should say:> The referenced resource uses the media type "application/cwt" {{RFC8392}}, either with no parameters or with the parameter "usage" with value "chain". That is, the referenced resource can be of any of the following content types:
>
> * application/cwt {{RFC8392}}
>
> * application/cwt; usage="chain" (see {{chain}})
>
> If no parameter is set, the data is encoded according to RFC 8392.
If the parameter "usage" is set to "chain", the representation of the
retrieved resource is a CWT chain encoded as a CBOR sequence [RFC8742],
each element of which is the corresponding CWT in the chain.
(The *media type* is "application/cwt" in both cases. The *content type* is application/cwt in the first case and application/cwt; usage="chain" in the second case.)
(The proposed new text also builds on what comes only later in Section 8.3)
* "GET request" I would say more generally "message exchange". * "should be used" (2 instances)Why not "SHOULD"? And what are possible exceptions to skip secure communication?
* Figure 1 can be turned into an actual table. [Section 5] * Figure 2 can be turned into an actual table. [Section 8.1] * s/has registered/is requested to register [Section 8.2] * s/has registered/is requested to register [Section 8.3] * It says:> When the application/cwt media type is used, the data is a CBOR sequence of single-entry COSE_CWT structures (encoding "bstr").
I would not use > (encoding "bstr") but instead> (encoding "binary"), as also used in the media type definition. That avoids possible confusion and erroneously thinking about wrapping the CWTs in CBOR byte strings.
* I think that you also need to create a new "Media Type Sub-Parameter" registry for the parameters of the media type application/ctw, under the registry group at [1]. The parameter "usage" is the registry entry added by this document as first.
[1] https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml
* I think that this document should also register CWT confirmation methods corresponding to the four COSE header parameters "cwt-bag", "cwt-chain", "cwt-t", and "cwt-u". That's something for the "CWT Confirmation Methods" registry at [2].
That's useful, for example, in the ACE framework (RFC 9200) when using CWTs as proof-of-possession (PoP) access tokens. The new registrations above enable such "main CWTs" to convey in the confirmation claim ('cnf') the ACE client's authentication credential as the end entity CWT within a chain or bag, specified by value or by reference.
[2] https://www.iana.org/assignments/cwt/cwt.xhtml#confirmation-methods [Appendices]The "Acknowledgements" and "Contributors" sections are usually two unnumbered sections (in that order), after the appendices (if any), see RFC 7322.
[Nits] * Section 1 --- s/a X.509/an X.509 * Section 3 --- s/CWTs that have/CWTs need to have --- s/; and/. --- s/validatity/validity * Section 4 --- s/contain CWT/contain CWTs --- s/of CWT needed/of CWTs needed --- s/or add CWT/or add a CWT (2 instances) --- s/an 'cwt-bag'/a 'cwt-bag' (2 instances) --- s/an 'cwt-t'/a 'cwt-t' (2 instances) --- s/bag of CWT/bag of CWTs --- s/present in the element/present in the array --- s/integer or a string/integer or a text string --- s/binary string/byte string --- s/data is a encoded/data is encoded * Section 7 --- s/statys/status --- s/end entity CWTs/End entity CWTs -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
