Try to switch to HTTP Message Signatures

[jyasskin]

The HTTPWG has been working on https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures, and it's probably sufficient to replace our local Signature header definition.

[hayatoito]

[Issue Triage] The upstream issue is https://github.com/wpack-wg/bundled-responses/issues/18.

Let me close this issue, in favor of that.

[irori]

I think this issue is not about WebBundles but about SignedExchange's Signature header.

[davidben]

Just because HTTP message signatures says "HTTP" and "signatures" doesn't mean it is appropriate for every HTTP-adjacent signature use case. Indeed it is not a good fit here. Moving to HTTP message signatures would leave SXGs more complex and dramatically increase the risk of security bugs in software around SXGs.

HTTP message signatures is an extremely complex draft that falls into a lot classic, well-known security pitfalls with incorporating complex canonicalization and transforms into a signature-based protocol. This is because they're trying to solve for a number of constraints that don't apply to SXGs. They want to sign content that was delivered across HTTP fields, with signer and intermediary content interleaved, while accounting for the wide range of HTTP wire formats and transforms by intermediaries. If that is truly your application's constraints, then perhaps you may be stuck with this kind of risky design. (Even then a far better strategy is to rearchitect your application to avoid this.) If not, HTTP message signatures is not a good choice.

SXG, in contrast, has no need of this. It doesn't need the HTTP headers in the signed payload to be sent directly over HTTP. If anything, doing so adds risk for SXG because you don't want headers from the intermediate to get mixed up with headers from the publisher! It's critical for security that publisher and intermediary content are clearly separated. In that situation, the correct design is to simply take the data from the publisher, encode it in some well-defined format, sign the encoding, and transmit encoding + signature together. That's what SXG currently does.

If we want to repurpose some existing building blocks, consider moving the encoding to RFC 9292, used by draft-ietf-ohai-ohttp. OHTTP, like SXG, is another example of how the HTTP message signatures architecture is rarely necessary. OHTTP wants to encrypt HTTP-like payloads (headers + body). But rather than build something complex, it simply designs some encoding for such payloads, and then encrypts it.