Standard URL safe digest form and hash algorithm list

Roman Volosatovs <roman@profian.com> Tue, 26 April 2022 09:31 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 B2D6FC3CC35F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Apr 2022 02:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.752
X-Spam-Level:
X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.248, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRmh8PIWpVbM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Apr 2022 02:31:15 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE86C157B3E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Apr 2022 02:31: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 1njHUz-0006UI-WB for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Apr 2022 09:28:46 +0000
Resent-Message-Id: <E1njHUz-0006UI-WB@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ylafon@w3.org>) id 1njHUx-0006Su-S3 for ietf-http-wg@listhub.w3.org; Tue, 26 Apr 2022 09:28:43 +0000
Received: from raoul.w3.org ([128.30.52.128]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ylafon@w3.org>) id 1njHUw-0003pg-Gn for ietf-http-wg@w3.org; Tue, 26 Apr 2022 09:28:43 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=smtpclient.apple) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ylafon@w3.org>) id 1njHUw-0003Qo-6N for ietf-http-wg@w3.org; Tue, 26 Apr 2022 09:28:42 +0000
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Content-Type: text/plain; charset="us-ascii"
From: Roman Volosatovs <roman@profian.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Tue, 29 Mar 2022 08:38:21 +0000
Cc: nathaniel@profian.com
Content-Transfer-Encoding: quoted-printable
Resent-Date: Tue, 26 Apr 2022 11:28:39 +0200
Message-Id: <e878f0c7-26d0-163b-def4-7b51c3e031c0@profian.com>
Resent-To: ietf-http-wg@w3.org
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-W3C-Hub-Spam-Status: No, score=-1.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, W3C_NW=1
X-W3C-Scan-Sig: titan.w3.org 1njHUw-0003pg-Gn a95bedb5dc250d0950708f291034b923
X-Original-To: ietf-http-wg@w3.org
Subject: Standard URL safe digest form and hash algorithm list
Archived-At: <https://www.w3.org/mid/e878f0c7-26d0-163b-def4-7b51c3e031c0@profian.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40006
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 Working Group,

Regarding the "Digest Fields" draft-ietf-httpbis-digest-headers-08:


1. The digest values, being binary data, are encoded as colon-delimited Base64 values as defined in RFC 8941. The digest values, therefore, are not safe for use in URL paths and require an additional encoding step for that particular use case, for example percent-encoding or base64url encoding.

This presents an issue in particular in context of content-addressable stores and usability of thereof. A content-addressable store exposing a REST API, for example, would require usage of two different encodings of the same digest - the `sf-binary` form specified in the headers and some alternative form safe to use in the URL path.

It does not seem feasible to remove the need for two different encodings of the digest due to the explicit usage of "base64" in RFC 8941, however it would greatly improve the situation if a canonical URL safe encoding of the digest values could be explicitly defined in the document.


2. Some of our customer use cases require usage of sha-384 and sha-224 algorithms, both of which are described in RFC 6234, however omitted in https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml and not explicitly mentioned in Section 5, Table 1 of the draft.

Would it be possible to add these two algorithms to the table to mark them as explicitly allowed and supported for use in the header?


Thanks,

Roman