[secdir] Secdir telechat review of draft-ietf-httpbis-message-signatures-17
Daniel Migault via Datatracker <noreply@ietf.org> Tue, 16 May 2023 17:10 UTC
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/
- [secdir] Secdir telechat review of draft-ietf-htt… Daniel Migault via Datatracker