From nobody Tue May 16 10:10:57 2023
Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1])
 by ietfa.amsl.com (Postfix) with ESMTP id 3DDADC13AE4C;
 Tue, 16 May 2023 10:10:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Migault via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-httpbis-message-signatures.all@ietf.org, ietf-http-wg@w3.org,
 last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168425705624.57537.3782894753130682249@ietfa.amsl.com>
Reply-To: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 16 May 2023 10:10:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/6ywyw0oE14ZYZbwqVPu7KiW-UMI>
Subject: [secdir] Secdir telechat review of
 draft-ietf-httpbis-message-signatures-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>,
 <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>,
 <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2023 17:10:56 -0000

Reviewer: Daniel Migault
Review result: Ready

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

The document seems to me ready with what it is trying to achieve.

I re-iterate my comments from version 15 [1]. To me, the critical aspect of
this specification remains - in my opinion -  in the canonical representation
of the HTTP message.

Some comments.

"""
For example, this specification does not define a
means to directly cover HTTP message content (defined in Section 6.4
of [HTTP]), but relies on the [DIGEST] specification to provide a
hash of the message content, as discussed in Section 7.2.8.
"""

I am reading this text as saying replacing content by its digest is an issue
which I find misleading. I think was is meant here is that he content is
replaced by specific fields.

[1] https://mailarchive.ietf.org/arch/msg/secdir/BaILKroC2MdOvoEkMi3KHnbMb7w/