How to handle cache in signatures

[jricher]

What should the requirements for cache be in signatures?

See some context:

Originally posted by @jricher in https://github.com/httpwg/http-extensions/pull/2105#discussion_r882977703

[jricher]

Still needs input from the WG to make sure current text is ok.

[mnot]

@jricher you mentioned that there's already text for this -- can you point to it?

[jricher]

We've got this paragraph in §5 about Accept-Signature:

When the Accept-Signature field is sent in an HTTP request message, the field indicates that the client desires the server to sign the response using the identified parameters, and the target message is the response to this request. All responses from resources that support such signature negotiation SHOULD either be uncacheable or contain a Vary header field that lists Accept-Signature, in order to prevent a cache from returning a response with a signature intended for a different request.

But apart from that and an oblique mention of lazy caching in the security considerations, we remain pretty silent about what to do about cache for both request and response. Maybe that's ok, but I want to make sure we don't need to say something more specific. For example:

• If a request is signed, is it OK to return a cached response? Do you need to check the signature on the request at the cache?
• If a response is signed, is it OK to return that signed response from a cache?

[mnot]

I think the current text works fine; it should be OK for responses to be cacheable as long as that advice is followed.

Your questions are a bit malformed -- we can't create special rules for caches regarding signatures, because they're generic software that's already widely deployed.

[jricher]

OK, closing the issue based on that feedback.