Skip to main content

Last Call Review of draft-ietf-rats-uccs-10
review-ietf-rats-uccs-10-genart-lc-yee-2024-09-25-00

Request Review of draft-ietf-rats-uccs
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-09-18
Requested 2024-09-04
Authors Henk Birkholz , Jeremy O'Donoghue , Nancy Cam-Winget , Carsten Bormann
I-D last updated 2024-09-25
Completed reviews Secdir Last Call review of -10 by Vincent Roca
Genart Last Call review of -10 by Peter E. Yee
Opsdir Last Call review of -10 by Per Andersson
Assignment Reviewer Peter E. Yee
State Completed
Request Last Call review on draft-ietf-rats-uccs by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/3VRG2GGPt-OSQKgaLaqoqo3L8P8
Reviewed revision 10
Result Ready w/issues
Completed 2024-09-25
review-ietf-rats-uccs-10-genart-lc-yee-2024-09-25-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-rats-uccs-10
Reviewer: Peter Yee
Review Date: 2024-09-25
IETF LC End Date: 2024-09-18
IESG Telechat date: 2024-10-03

Summary: This is a well-written specification for the substitution of a Secure
Channel for the COSE envelope normally employed with a CWT Claim Set to protect
a CWT, here specified for RATS uses cases. There are some minor issues with the
introductory text that might be addressed to clarify the case being made for
the transposability of a Secure Channel for COSE envelope. [Ready with issues.]
Major issues: None

Minor issues:

In general, I find the concept of using a Secure Channel in place of a COSE
envelope for protecting a CWT reasonable. As the draft notes, once delivered to
the receiver, the UCCS is merely unprotected data. Not being overly familiar
with RATS, I ask whether there should be a more cautionary note that a true CWT
should be employed by the sender instead of a Secure Channel if there is an
expectation that it will be sent on to another party by the receiver.
Certainly, the last paragraph on page 6 hints at this.

On page 5, section 4, 2nd sentence: “leaflets”? Really? Folded pieces of paper.
Maybe just change “instruction leaflets” to “instructions”.

Nits/editorial comments:

Page 4, 1st paragraph in Secure Channel definition after the NIST quotation,
last sentence: delete the comma.

Page 4, section 2, last (partial) sentence: change “resource constrained” to
“resource-constrained”.

Page 6, 5th paragraph, 1st sentence: delete “to” after “and”. At least I think
it parses better that way.

Page 11, section 7.2, 3rd bullet: insert “the” before “IV”.