Skip to main content

Early Review of draft-deshpande-secevent-http-multi-set-push-00
review-deshpande-secevent-http-multi-set-push-00-secdir-early-kelly-2025-12-12-00

Request Review of draft-deshpande-secevent-http-multi-set-push
Requested revision No specific revision (document currently at 05)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2025-11-21
Requested 2025-10-31
Requested by Deb Cooley
Authors Apoorva Deshpande , Aaron Parecki
I-D last updated 2026-10-15 (Latest revision 2026-10-09)
Completed reviews Httpdir Early review of -00 by Darrel Miller (diff)
Genart Early review of -00 by Russ Housley (diff)
Secdir Early review of -00 by Scott G. Kelly (diff)
Secdir IETF Last Call review of -03 by Scott G. Kelly (diff)
Tsvart IETF Last Call review of -03 by Martin Duke (diff)
Httpdir Telechat review of -05 by Mark Nottingham
Assignment Reviewer Scott G. Kelly
State Completed
Request Early review on draft-deshpande-secevent-http-multi-set-push by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/grqFQ9jZGAs9Z_wdwTn1Dzpr-bo
Reviewed revision 00 (document currently at 05)
Result Has nits
Completed 2025-12-12
review-deshpande-secevent-http-multi-set-push-00-secdir-early-kelly-2025-12-12-00
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.

This is an early review that was requested on Nov 21 with a due date of the
same day. I hope this is still useful given that a few weeks have passed.

From the abstract, "This specification defines how multiple Security Event
Tokens (SETs) can be delivered to an intended recipient using HTTP POST over
TLS." SETs are defined in RFC 8417, and delivery of a SET via TLS/HTTP is
defined in RFC 8935. This document extends 8935 by allowing delivery of more
than one SET in a single message.

I think the document is generally progressing well. I have one minor comment: I
think the security considerations section should begin by stating that all
security considerations of 8417 and 8935 apply to this document. This
document's security considerations subsection 7.6 explicitly calls out "Section
5 of [RFC8935]", but this might lead a reader to conclude that this is the only
8417/8935 security consideration that applies to this document.