Ballot for draft-ietf-rats-uccs
Discuss
Yes
No Objection
No Record
Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Updating my second comment to DISCUSS, because I'd really like to see an answer to it. Appendix C: I was surprised to see "Unprotected JWT Claims Set" defined here, while the main body of the document specifies that JWT with algorithm:none is equivalent to the UCCS. What is the difference, and why is this definition of UJCS useful or needed?
Thank you for the work on this document. I have only two comments:
Section 6.3:
Please fix the IANA request, by using the correct registry terminology for the CoAP Content-Formats registry ("Content Type" and "Content Coding" instead of "Media Type" and Encoding"). Yes, IANA has understood the request, but it would be good that the text matched the registry as well.
Thank you for having forwarded the media type registration request to the media types mailing list (noted and appreciated).
### JSON Support without media types or content formats ``` 733 Appendix C. JSON Support 735 This appendix is informative. 737 The above definitions, concepts and security considerations all may 738 be applied to define a JSON-encoded Claims-Set. Such an unsigned 739 Claims-Set can be referred to as a "UJCS", an "Unprotected JWT Claims 740 Set". The CDDL definition in Figure 1 can be used for a "UJCS". ``` There are no registrations that end in +json in this document. Should there be? For example, eat media types draft contains: https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-media-type-10#name-media-types
# Orie Steele, ART AD, comments for draft-ietf-rats-uccs-10 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rats-uccs-10.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### OHTTP? ``` 318 5.2. Privacy Preservation ``` Are there any examples of such privacy preserving secure channels that should be mentioned here? ## Nits ### Expand on first use: EAT ``` 291 The Secure Channel context does not govern fully formed CWTs in the 292 same way it governs UCCS. As with EATs nested in other EATs ``` ### Informative appendix ``` 642 This appendix is informative. ``` Not sure that this sentence is needed... its also repeated a lot. I think its ok to note that an appendix is normative, if its referenced as normative (with BCP14) from the body. ### JC order ``` 688 JSON-ONLY<J> = J .feature "json" 689 CBOR-ONLY<C> = C .feature "cbor" 690 JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C> ``` I might move these definitions above the first use of JC, so the reader doesn't need to backtrack.
An easy but important issue to consider is to add guidance to the Security Considerations Section to make it clear that the Secure Channel cryptographic strength should be at least as strong as the cryptographic keys it is transporting through this Secure Channel. Similarly, I think when mentioning the algorithms in this section, that it could be clarified these are not the algorithms of the Secure Channel, but the content relayed through it.
I have one easy comment: Section 7.2, 7.3, 7.4, and 7.5: The bullets from these sections are all selected or paraphrased from RFC9053. In some cases the paraphrasing is imprecise. I'd almost rather see the bullets eliminated, leaving the section numbers of RFC9053. This might ensure that a developer actually consults with RFC9053 vice assuming the bullets are complete.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-rats-uccs-10 # line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rats-uccs-10.txt # After reviewing the document, I did not identify any significant typographical errors. The text is well-written. # idnits gives some warnings about the references #DETAILED COMMENTS #================= ## classified as [minor] and [major] 15 Abstract 16 17 When transported over secure channels, CBOR Web Token (CWT, RFC 8392) 18 Claims Sets may not need the protection afforded by wrapping them 19 into COSE, as is required for a true CWT. This specification defines 20 a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses 21 conditions for its proper use. [minor] GV> What about the following rewrite making the abstract more higher level descriptive: " This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without a signature, message authentication code (MAC), or encryption. UCCS enables the use of CWT claims in environments where data protection is provided by other means, such as secure communication channels or trusted execution environments. This specification describes the UCCS format, its encoding, and processing considerations, and discusses the security implications of using unprotected claims sets. "
Supporting Orie's Dicsuss.
Thanks for the work done in this document. To be honest, I was about to ballot ABSTAIN because CWT at rest (e.g., in audit trails or logs) are no more secure and the secure channel transport entity could be different than the CWT producer/consumer, but I am trusting the SEC ADs in their ballot (i.e., I probably do not understand the use cases), hence a NoObjection ballot. Some non-blocking comments anyway: # Section 1 s/A true CWT/A RFC8392 CWT/ ? Unsure whether 'true' is applicable here. Should there be a reference for "PCIe IDE" ? # Section 2 Please expand "RATS" # Section 4 Please expand "EAT" # Section 7.1 Even if by default the text is normative, should BCP14 terms be used ? # Sections 7.2 to 7.5 These sections are specific to currently used crypto algorithms, should these section be more condensed in a generic one ? or should there be a section about future algorithms ? # Appendix A How can `This appendix is informative.` and `this specification shows how to use CDDL` appear in the same section ? s/this specification shows how to use CDDL/this example shows how to use CDDL/