Digest: defining an additional field for message content

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 18 June 2021 00:08 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4CF3A33D6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Jun 2021 17:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5Ys4SUQ7Ds3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Jun 2021 17:08:12 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B6D3A2AF3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 17 Jun 2021 17:08:11 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1lu1zh-0006w0-Ej for ietf-http-wg-dist@listhub.w3.org; Fri, 18 Jun 2021 00:04:26 +0000
Resent-Date: Fri, 18 Jun 2021 00:04:21 +0000
Resent-Message-Id: <E1lu1zh-0006w0-Ej@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1lu1yq-0006oY-Nz for ietf-http-wg@listhub.w3.org; Fri, 18 Jun 2021 00:03:40 +0000
Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1lu1yJ-00043B-Qn for ietf-http-wg@w3.org; Fri, 18 Jun 2021 00:03:28 +0000
Received: by mail-ej1-x634.google.com with SMTP id og14so12820875ejc.5 for <ietf-http-wg@w3.org>; Thu, 17 Jun 2021 17:02:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2gO85SCxU92S6MaFCSW/89bbX5xstopFqVmo/bbdM/A=; b=cpktuquezCCheggMDg8rAh3zo6GCHpdJIGBBylsXHIlcaRmi1XGBFwAgBpMLPUugBb 5uVsipCAnzKLoAiuWmTYOblnCHd6QBonIyGmnVdPRpYfdOQSM9eLU3dFDGjPVe8Urtsw 4smQw1bhjsrcvhhYFMJqQ+caT70C9SOr1Mc4CwMR7qSEbxp/026SP/pFxKoVeLg4Z1W9 /0LF6oYd2JnbrS4g3LNnFeTmaHvglH8MLlvVWJa1SJj9YA6G7IShXYYmF0w+zSL54SR7 1qWNas4vGCjAVa+MfaOfM9q0YSpq0MBaz5a4tlf+8Ivdic45/Um2YKHWyTSdn20xlj9+ Q6KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2gO85SCxU92S6MaFCSW/89bbX5xstopFqVmo/bbdM/A=; b=CQ89YyJDow8wf0DcvBfOlEDU/ROY8HMm5KwlNmgsARlhIUU4RDUdqN00oa6PJLnqdu V2WFFYElG5y290UNTDS3ZhaX64JUw4X4QERrzI2l1PVr5yj1CDyUcOfFiG/oTBBupa3Z 7V6z/ArpHS90wSb+x3A+kylJhgcHoOsfTiuqpakJkOzf95xtVJ04g7DfkIU4BiI+4iQH SNAnruZKAtT/eFcWwHTFppNNHikzK+6Wio3uyV6lScC+nO13uS/+HPrtVMcBgxzrCpF2 g+zxo/CQ8Br00ZsLEOOM6YkXYvE37fi0YIQ2ZZ4TzzBp3H6Vjh6DKPqf5tyn3W3IgEUL xSTQ==
X-Gm-Message-State: AOAM5333xT4d/Gctqvmmey3G7Jx/bl3ParlTGGbUuxg2Sth+qHPr/q4U SuzTb3DW3p9HhEIJXbmrUw7LNxgzaXXVXx5oRXxH/bLCpZ8=
X-Google-Smtp-Source: ABdhPJxp2OkTnLbaCib3nHwU/AmaBzSEGP1QGb+TFlXGDrgHepiMmEPSPk4RqVcBYWfnYzEAmL9dCG8uyTEYMOmjamA=
X-Received: by 2002:a17:907:2648:: with SMTP id ar8mr7959050ejc.67.1623974564353; Thu, 17 Jun 2021 17:02:44 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 18 Jun 2021 01:02:33 +0100
Message-ID: <CALGR9obLN4zfiucBTvSbbq9LTwuL2qSVRLD1ZLRvojXpUHmUXg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Roberto Polli <roberto@teamdigitale.governo.it>
Content-Type: multipart/alternative; boundary="00000000000008584e05c4ff0b91"
Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-ej1-x634.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=lucaspardue.24.7@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1lu1yJ-00043B-Qn 739657cc4d2eccc481647b6f3f9f2a3b
X-Original-To: ietf-http-wg@w3.org
Subject: Digest: defining an additional field for message content
Archived-At: <https://www.w3.org/mid/CALGR9obLN4zfiucBTvSbbq9LTwuL2qSVRLD1ZLRvojXpUHmUXg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38917
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hello HTTP WG,

TL;DR: please take a look at this Digest spec PR -
https://github.com/httpwg/http-extensions/pull/1543 and let me know what
you think over the next week or so.

The Digest draft [1] updates RFC 3230 to describe how to use checksums of
selected representations for integrity checking. We've heard from a few
people that the way this turns out behaving can be surprising, even if is
entirely correct and consistent with HTTP semantics. For example, a HEAD
request for /foo could yield a response that contains a digest header; but
without any message content there is no integrity checksum to compute?!

Based on feedback before, during and after the February interim, it became
clear that some people have use cases that would benefit from a checksum of
the message content. This is a much simpler concept in comparison. A
receiver merely checks the thing they just received.

Changing the Digest field away from representation digests risks breaking
use cases that depend on it. We know in the IETF Metalink (RFC 6249) [2]
has a dependency on RFC 3230, The wider ecosystem is harder to
characterise. Breaking stuff is bad. Let's not do that.

As a path forward, it was suggested that a new field be defined, used only
for content checksums. The editors have a proposal PR at
https://github.com/httpwg/http-extensions/pull/1543. It defines the
Content-Digest header, which uses exactly the same syntax for expressing
algorithms and computed checksums. All that is different is the input data.

During today's interim there seemed to be support for adding this new
Content-Digest field. At the same time, we recognise the name probably
needs some bikeshedding and the PR probably needs a few more gaps filled
before we land it. So we encourage the WG to take a look. We'd appreciate
thoughts on the design question - do we want to add "Want-Content-Digest"
too?

Cheers,
Lucas and Roberto
Digest editors

[1] https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers
[2] https://datatracker.ietf.org/doc/html/rfc6249