Skip to main content

IETF Last Call Review of draft-ietf-scitt-scrapi-09
review-ietf-scitt-scrapi-09-secdir-lc-melnikov-2026-04-22-00

Request Review of draft-ietf-scitt-scrapi-07
Requested revision 07 (document currently at 09)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-04-10
Requested 2026-02-25
Requested by Jon Geater
Authors Henk Birkholz , Jon Geater , Antoine Delignat-Lavaud
I-D last updated 2026-04-26 (Latest revision 2026-04-21)
Completed reviews Httpdir Early review of -01 by Darrel Miller (diff)
Secdir IETF Last Call review of -09 by Alexey Melnikov
Opsdir IETF Last Call review of -08 by Nick Buraglio (diff)
Genart IETF Last Call review of -08 by Gyan Mishra (diff)
Secdir IETF Last Call review of -08 by Valery Smyslov (diff)
Comments
I hope a one-month deadline isn't too aggressive for the reviewer rotations. It's quite arbitrary so do push back if you can't get it done by then. We're just trying to move things along.
Assignment Reviewer Alexey Melnikov
State Completed
Request IETF Last Call review on draft-ietf-scitt-scrapi by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/0QKx9Wj7GIEiZpaG7znLzTJ-EBQ
Reviewed revision 09
Result Has nits
Completed 2026-04-22
review-ietf-scitt-scrapi-09-secdir-lc-melnikov-2026-04-22-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.

I was the originally assigned SecDir reviewer who missed the deadline, so
Valery Smyslov provided a good SecDir review. I read -09 and also checked
changes between -08 and -09 which addressed most of Valery's comments.
I think the latest version has improved on Security Considerations.

I have only a small thing on the latest version. Section on the Denial
of Service attacks (4.4.1.1) has now the following text:

   The impact of DoS attacks can be detected by a client checking that
   the Transparency Service has registered any submitted Signed
   Statement and returned a Receipt.

I agree so far.

   Since verification of Receipts
   does not require the involvement of the Transparency Service,

If you mean that clients can verify digital signatures on Receipts, I agree.

   a DoS attack cannot cause the silent loss of a registration.

I am not entirely sure this follows. It only follows if the client maintains
state about Signed Statements it submitted. Is it worth clarifying?

   However, this
   relies on clients actively checking for Receipts and does not prevent
   the disruption itself.