Signature representation.

[mikewest]

In WICG/proposals#175 (comment), @LPardue suggested that we rely upon HTTP Message Signatures (https://www.rfc-editor.org/rfc/rfc9421.html) rather than inventing a new header, which sounds like a wonderful idea indeed. That would look something like the following:

1. HTML indicates the expected key:

   <script src="https://my.cdn/script.js"
           crossorigin="anonymous"
           integrity="ed25519-[base64-encoded-public-key]"></script>

2. The request/response would look like:

   GET /script.js HTTP/1.1
   Host: my.cdn

   HTTP/1.1 200 OK
   Identity-Digest: sha-256=[Structured Field Byte Sequence aka :[base64 of computed digest]:]
   Signature-Input: sig1=("identity-digest" ;created=1618884475;keyid="ed25519-[base64-encoded-public-key]"
   Signature: sig1=[Structured Field Byte Sequence aka :[base64 of computed signature value basd on signature-input]:];

I'm not interested in inventing something new here if we don't have to, so I'm happy to rely on the mechanism described here. It's pretty verbose (I'll dig through the spec to figure out which parts are required/optional, but I guess that's more or less the minimal set?), but would do what we need it to.

That said, I'm a little confused about the differences between Repr-Digest on the one hand, and the proposed Identity-Digest on the other. SRI currently operates over the bytes that remain after the content is decoded per its content-encoding. @annevk to keep me honest on this, but that's my recollection and read of the current flow in Fetch (we handle content codings in HTTP-network Fetch, and pass those bytes back down to perform the SRI check at the bottom of Main Fetch). Does one of the headers described here represent those decoded bytes?

[mikewest]

cc @igrigorik @ddworken

[mikewest]

(This would also address @ddworken's request for some kind of Integrity-Public-Key header, insofar as it seems like that's what Signature-Input contains.)

[annevk]

That's correct. And browsers would have a hard(er) time implementing checks before content codings are handled.

[mikewest]

Reading more carefully, it looks like both Content-Digest and Repr-Digest would indeed represent a digest over the encoded content, and Identity-Digest is what we're looking for (https://www.ietf.org/archive/id/draft-pardue-http-identity-digest-01.html#section-1-2). That said, I find the examples in Appendix A and B of RFC somewhat difficult to parse for this question specifically, but I think https://datatracker.ietf.org/doc/html/rfc9530#appendix-B.4 demonstrates the discrepancy?

In any event, if the description of the headers above matches your understanding, @LPardue, then I'd like to help you get draft-pardue-http-identity-digest over the line. :)

[ddworken]

(This would also address @ddworken's request for some kind of Integrity-Public-Key header, insofar as it seems like that's what Signature-Input contains.)

For reference, see #21 for a separate issue to discuss the need for this.

[mikewest]

I took a pass at shifting the proposal over to the mechanism proposed here. @LPardue (and anyone else who's interested!), would you mind skimming https://wicg.github.io/signature-based-sri/#validation and suggesting any improvements that occur to you?

[mikewest]

Closing this out. For the moment, the approach in https://wicg.github.io/signature-based-sri/#validation seems like a reasonable way to approach this. There's likely followup work, but we can address it in more specific bugs.