Allow uncacheable responses / logical split between "response to unverified request" and "deterministic request"
This is not thought through, and more of a note to ponder a bit more; don't get hung up on this ;-)
Looking at how Group OSCORE Appendix F ("No Verification of Signature") was removed, I briefly contemplated what those who wanted it (including me) might use instead.
Of the scenarios in which something like that could have been practical, for some (in particular, when the servers ignore the signature on a GET to multicast) deterministic requests could be the answer:
- Client sends something deterministic-request-ish, but keeps its identity in to send the response to
- Server processes this as a request from the deterministic client (as it can't know who actually sent it), but protects the response in pairwise mode to the client-in-person.
This achieves
- No signatures need to be created or processed
- Request-response binding through the request's hash
- Source authentication for the response, because only server and client can derive the key for the response
- (but obviously it's not cachable in any practical way any more)
I have two opposing thoughts on this right now:
- This could just be tacked on later, it's just an add-on.
- This could point toward a generalization of request-response binding that could provide a barrier in the document, where one half is "request-response binding without source authentication" and the other is "building cachable responses based on that alternative binding"
Edited by chrysn