Public keys in request headers

[ddworken]

One thing that seems potentially useful to support is specifying the expected public key in request headers. For example, if an application specifies integrity="ed25519-[base64-encoded public key]", the request could include an Expected-Integrity: ed25519-[base64-encoded public key] request header to allow the backend to know that signature-based SRI is expected, and it will be validated against the given public key.

The concrete use case I have in mind is enabling an extremely basic form of key rotation. Suppose that a widely used library is signed with key A, but that key ends up getting compromised. The library owner would then want to start signing it with key B, but existing clients would already be pinning key A. If the backend knows what key the client has pinned, it could serve the corresponding signature.

This probably isn't critical for the MVP, so if it is controversial at all, I'd be inclined to skip this. But if it is non-controversial, this does seem like a nice capability that would be easy to support.

[mikewest]

Assuming we use the framework in #16, I think we'd get Accept-Signature for "free" (insofar as it's defined in https://www.rfc-editor.org/rfc/rfc9421.html#section-5.1, though implemented nowhere). I guess we'd send a hash as the keyid (though that doesn't seem to be how it's defined... hrm)?

Spelling aside, there's some interaction with CORS here if we attach this header to that @annevk might wish to weigh in on. I think we'd also want to think a little bit about whether this is a communication channel to the server that we need to worry about. I'm not sure it is any different than GET parameters, but folks have had feedback on other proposals in this area we should make sure we consider.

Marking this as enhancement, just because I don't think we'd wait to ship this on having this feature.

[mikewest]

Actually, reading that spec a little more closely, I'm not at all sure how Accept-Signature works. I clearly need to spend more than 5m skimming it, as it's somewhat complicated. :)

[mikewest]

If we add this, we should also add some developer-facing text to the security considerations section to note that some configurations might leak the public key used to sign the response, as @annevk noted in #26.