Using Digest in signatures

[ioggstream]

I expect

To better detail the usage of Digest in signatures, including:

• what should be included in signature for integrity (representation metadata)
• issues with signing partial representations (eg. Range-Request, PATCH, ..)
• using strong crypto algorithms

Questions

• should we explicit here further requirements (eg timestamps, request-target, :method:, ..) or that's off-topic?

• should we warn about algorithm-based attacks (eg. MAC signatures are vulnerable to Length-Extension attacks)

• consider signing Content-Length too (it's a representation-metadata in http-core), though it would eliminate the ability to do things like chunked transfer-encoding, which is quite common. @dlongley

Notes

Split from #15

[ioggstream]

For now, we only warn that:

• you need a transport-layer integrity mechanism for the whole message;
• you should sign the whole representation (data + metadata);
• you should avoid broken crypto algorithms.

[LPardue]

The challenge here is to add useful guidance that is relevant to Digest and expected usages but without also defining the expected usages completely.

The dependency model is that a signature doesn't need to include a digest but it can, a digest doesn't include a signature. Attempting to explain too much of signature risks inverting the dependency (or at least coupling too tightly).

I think what we have today is sufficient but am open to compelling reasons on what would be really helpful to define in this document.

[ioggstream]

Agree. My point is just avoiding all the problematic usage of Digest in signatures.

Feel free to highlight what is in-scope and what it is not.

[ioggstream]

moved to https://github.com/httpwg/http-extensions/issues/851