Skip to main content

IETF Last Call Review of draft-ietf-scitt-architecture-20
review-ietf-scitt-architecture-20-secdir-lc-lonvick-2025-09-10-00

Request Review of draft-ietf-scitt-architecture
Requested revision No specific revision (document currently at 22)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-08-29
Requested 2025-08-15
Authors Henk Birkholz , Antoine Delignat-Lavaud , Cedric Fournet , Yogesh Deshpande , Steve Lasker
I-D last updated 2025-10-21 (Latest revision 2025-10-10)
Completed reviews Httpdir Early review of -01 by Darrel Miller (diff)
Genart IETF Last Call review of -18 by Roni Even (diff)
Secdir IETF Last Call review of -20 by Chris M. Lonvick (diff)
Iotdir Telechat review of -20 by Jason Livingood (diff)
Assignment Reviewer Chris M. Lonvick
State Completed
Request IETF Last Call review on draft-ietf-scitt-architecture by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/NvE0VvRTDEt-FyEmXDysiazhBLA
Reviewed revision 20 (document currently at 22)
Result Ready
Completed 2025-09-10
review-ietf-scitt-architecture-20-secdir-lc-lonvick-2025-09-10-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is READY (with nits).

It is clear that the authors, contributors, and the Working Group have
extensively discussed this and have arrived at consensus for this document. My
compliments to them for pulling together a single document that covers such a
large concept.

I am not familiar with the workings of supply chains to be able to provide a
comprehensive review. However, I found the Shepherd's writeup to be very
helpful. I believe that I can't add anything more useful than what was written
there concerning discussions around security. For convenience, I'll post it
here:

There was a substantial amount of discussion around Security, some of which
were resolved by using a known signing format with provision for agility
(COSE). Discussion took place around steps that service operators could take to
secure their instances, and converged on a clear, minimal text. The definition
of the bytes to be signed was discussed extensively, and the tradeoffs and
benefits of including unprotected headers weighed at length, before consensus
was reached. Statement identification and references were also discussed, but
consensus could not be reached, and it was agreed that it may be addressed in a
separate, later document.

I agree that it is ready to be handed off to the responsible Area Director.

Best regards,
Chris