Subject: Standard URL safe digest form and hash algorithm list

From: Roman Volosatovs <[email-masked]>
Date: Tue, 29 Mar 2022 08:38:21 +0000

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

---

From: Roberto Polli <[email-masked]>
Date: Fri, 29 Apr 2022 08:41:27 +0200

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 <[email-masked]> ha scritto:

> 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
>
>
>
>
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 29 Apr 2022 07:59:19 +0100

Hey,

> Isn't decode/encode a viable solution?

I don't really see the issue here. The computed digest bytestring is the
same regardless of the serialization format for sending it over the wire.
The problem seems to be with trying to send the Structured Fields Byte
Sequence type in a URL. There's doesn't seem any need to do that, instead
you can just send the base64 encoding of the computed digest without the
colons.

Cheers
Lucas