Subject: Digests: deprecating parameters?

From: Lucas Pardue <[email-masked]>
Date: Tue, 18 Aug 2020 10:49:05 +0100

Hello folks,

We're wondering what the group might think about deprecating the Digest
parameters. Please respond for or against the idea, either here or on the
GitHub issue https://github.com/httpwg/http-extensions/issues/850

*Background*
While updating the Digests spec we've found somewhat of a gap when it comes
to "parameters". These are mentioned in RFC 3230:

   For some algorithms, one or more parameters may be
   supplied.

      digest-algorithm = token

   The BNF for "parameter" is as is used in RFC 2616 [4].  All digest-
   algorithm values are case-insensitive.

It seems wrong to define parameters as part of the algorithm, so we started
on a PR to fix things up. But the discussion moved on to examples and
real-world usage; as far as we can tell there are no canonical examples
either in the specification or on the wild Internet.

Keeping this spec gap seems wrong, so one option we could consider is to
simply deprecate "parameters". For use cases that might have a future need
of such a thing, they could easily define a new algorithm that encodes
their parameters in the digest-value (the encoded checksum) itself.

Please let us know what you think.

Lucas and Roberto
Digest Editors

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 19 Aug 2020 00:37:21 +1200

On 18/08/20 9:49 pm, Lucas Pardue wrote:
> parameters. Please respond for or against the idea, either here or on
> the GitHub issue https://github.com/httpwg/http-extensions/issues/850
> 
> _Background_
> While updating the Digests spec we've found somewhat of a gap when it
> comes to "parameters". These are mentioned in RFC 3230:
> 
> |For some algorithms, one or more parameters may be supplied.
> digest-algorithm = token The BNF for "parameter" is as is used in RFC
> 2616 [4]. All digest- algorithm values are case-insensitive.|
> 
> It seems wrong to define parameters as part of the algorithm, so we
> started on a PR to fix things up.

I do not see any indication in RFC 3230 that the parameters have to be
defined with the algorithm. There could be a specification which defines
a parameter which is relevant to all algorithms but is optional. Eg a
"q=" or "charset=" parameters.

Such a parameter may be *sent* on some algorithms entries, but not on
others depending on the sender implementation.

So IMO, that particular line of argument against parameters is not a
valid one.

> But the discussion moved on to
> examples and real-world usage; as far as we can tell there are no
> canonical examples either in the specification or on the wild Internet.
> 
> simply deprecate "parameters". For use cases that might have a future
> need of such a thing, they could easily define a new algorithm that
> encodes their parameters in the digest-value (the encoded checksum) itself.
> 

I think this would be a good time to refer to the structured headers
document as a syntax basis
<https://tools.ietf.org/html/draft-ietf-httpbis-header-structure>.

That documents the possible existence of parameters even when they are
not specifically defined by the header document (eg RFC 3230). Which
allows dropping the mention of them from RFC 3230 successor document
without formally deprecating or requiring any implementation changes.

Amos

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 18 Aug 2020 14:16:12 +0100

Hey Amos,

> So IMO, that particular line of argument against parameters is not a

This is probably where the gap leads to interpretation, and maybe I
misinterpreted things.

I think the terminology is the annoying thing here, since digest is a tuple
of algorithm and computed value. The BNF in 3230 doesn't make it super
clear where a parameter would be expressed. For instance, is it reasonable
to assume that the intended digest parameter delimiter was ';'? I do agree
with your "global parameter" concept, which could apply to all digests
independent of the algorithm used.

> without formally deprecating or requiring any implementation changes.

That sounds reasonable, especially given the previous point. Does that work
for others?

Cheers,
Lucas

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Aug 2020 15:39:00 +0200

Am 18.08.2020 um 15:16 schrieb Lucas Pardue:
> ...
> I think the terminology is the annoying thing here, since digest is a
> tuple of algorithm and computed value. The BNF in 3230 doesn't make it
> super clear where a parameter would be expressed. For instance, is it
> ...

s/doesn't make it super clear/does not even mention/

Best regards, Julian

---

From: Roberto Polli <[email-masked]>
Date: Tue, 18 Aug 2020 17:01:24 +0200

Il giorno mar 18 ago 2020 alle ore 14:42 Amos Jeffries
<[email-masked]> ha scritto:
> there could be a specification which defines

While this seems to me an overthought respect to RFC3230,
 I cannot exclude this remote possibility.

> not specifically defined by the header document (eg RFC 3230

Can be a solution, but how can we express this field-value with
structured headers?

Digest: sha-256=ababbababab;q=1,  sha-512=bfbfbfbfbf

Thanks to everybody,
R.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 18 Aug 2020 15:24:27 +0000

--------

> Digest: sha-256=ababbababab;q=1,  sha-512=bfbfbfbfbf

almost exactly the way you did (with OWS for clarity):

	Digest: sha-256 = :ababbababab=: ; q=1 , sha-512 = :bfbfbfbfbf==:

sf-binary is there for precisely a use-case like this.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Roberto Polli <[email-masked]>
Date: Tue, 18 Aug 2020 17:53:58 +0200

> sf-binary is there for precisely a use-case like this.

While I like sf-binary, actual digest-algorithms define their own serialization
method (in this case it's accidentally the same of structured headers) but other
algorithms use eg. integer.

To support SF we could say that digest-algorithms like sha-256 and
sha-512 should be supported
in both sf-binary and the traditional token format.

I don't know if this can bring confusion or not though.

R:

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 18 Aug 2020 16:20:14 +0000

--------

> in both sf-binary and the traditional token format.

The most sensible way (IMO) is to define that *all* digests are *always* sf-binary.

That makes for simpler parsing and simpler APIs to plug new digest algorithms into.

The alternative is that the digest algorithms are allowed a
choice from (a subset of) sf-item (= sh-integer / sh-decimal /
sh-string / sh-token / sh-binary / sh-boolean).

I have a hard time seing any non-speculative advantages in that ?

I dont know of any contemporary digest algorithms, and have a very
hard time even imagining future digest algorithms, which do not
output a finite sequence of binary 8-bit bytes, ready to stuff into
a sf-binary.

If some past/future/speculative digest algorithm wants a particular
serialization, only sf-binary is 100% certain to be able to carry it
anyway, it might for instance contain newlines.

---

From: Roberto Polli <[email-masked]>
Date: Tue, 18 Aug 2020 18:39:21 +0200

> The most sensible way (IMO) is to define that *all* digests are *always* sf-binary.

I certainly agree on all your statements, but we cannot break current
implementations
of sha-256 and sha-512 for fixing the parameters issue.

So:
-  ok to prepare Digest to be SF-ready
- ok if there's a way do describe the current Digest syntax with SF,
so that we can later obsolete non sf-binary algoritms
- not sure that fixing the parameters issue is a valid reason to
introduce SF now

My 2c,
R.

---

From: Roberto Polli <[email-masked]>
Date: Wed, 26 Aug 2020 16:48:25 +0200

Hi @all,

today me and Lucas had a brief meeting on the parameters subject,
and considering those feedback we decided the following:

- given this comment from @Mark Nottingham
https://github.com/httpwg/http-extensions/issues/1211#issuecomment-675208548
  and as this specification is a refresh of RFC3230, we cannot *still*
switch to S-F. We would really like to switch in the future,
  and we both agree with @Poul-Henning Kamp considerations;
- given that digest-algorithms are case insensitive, we'll make a PR
saying that they SHOULD
  be used in *lowercase*, to ease a future transition to S-F;
- in absence of implementation, we'll follow @Julian Reschke  propose
to DEPRECATE http-parameters usage and
  wait for implementor feedback. We think that @Amos Jeffries
considerations are reasonable, but decided to make
  an attempt to simplify the spec.

Related PRs will land on the repo: feel free to provide more feedback
or suggest implementers to engage with the WG.

Clearly further feedback is always welcome!

Have a nice day,
R: