W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

Re: Standard URL safe digest form and hash algorithm list

From: Roberto Polli <roberto@teamdigitale.governo.it>
Date: Fri, 29 Apr 2022 08:41:27 +0200
Message-ID: <CAMRHeuzfTOEX_f70MogQXp+=BMRDLTgbmrvyv9Xs7m+5jcSqiw@mail.gmail.com>
To: Roman Volosatovs <roman@profian.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, nathaniel@profian.com
Hi Roman,

Can you please file a github issue requesting the registration of two more
digest algorithms?

About the encoding, we decided to delegate it to SF. I don't remember why
it was decided to use but instead of b64url though...

Isn't decode/encode a viable solution?

Kind regards,
R


Il mar 26 apr 2022, 11:31 Roman Volosatovs <roman@profian.com> ha scritto:

> 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
>
>
>
>
>
>
Received on Friday, 29 April 2022 06:41:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 29 April 2022 06:41:59 UTC