#1207: Signature Negotiation and Want-Signature

The editors of the signatures draft are looking at what it would take to add a negotiation feature to the Message Signatures draft, as it’s been requested a number of times and tracked specifically in http-extensions issue #1207. I want to give our rough strawman here and gather feedback, which we’ll then incorporate into a more concrete PR. None of this is meant to be spec-level text, but we’re looking for feedback on the approach, applicability, and extent of this feature.


We’re proposing a “Want-Signature” header that can be used in both requests and responses. The value of this header is a Dictionary structured field, mimicking the “Signature-Input” header’s contents today, using named signature identifiers as keys and signature parameters structures as values (note that these are defined as inner-lists with named parameters). The sender of the Want-Signature header would need to choose a signature identifier for each included element.


When used in a request, the Want-Signature header indicates that the client wants the server to sign the response using the signature parameters. The server should (must?) sign all of the listed identifiers, using the identified key and algorithm if present. The resulting signature should (must?) be returned using the same signature identifier as in the request. The client can here indicate identifiers that bind the response to the request, including the @request-response identifier (recently added in the editors copy[2], if you haven’t seen it). 


When used in a response, the Want-Signature header indicates that the server wants the client to sign its :next: request using the signature parameters. The client should (must?) sign all of the listed identifiers, using the identified key and algorithm if present. The resulting signature should (must?) be presented using the same signature identifier as in the response header in the next request.


A responder on either end can always send multiple signatures, one that meets requested parameters and one that might not (signs more, signs less, uses different algorithms, uses different keys, etc). It will always be up to the receiver of a signature to determine if the signature meets their needs, regardless of what was requested.


A few core open questions we aren’t sure on (or, quite frankly, the editors disagree on where to start):

- When multiple values are sent, is this an AND or an OR of parameters? Do I have to send something that fits only one, or one for each, or one for all of them, or … ?
- Could a signature response include additional fields as opposed to just what’s listed? So let’s say I ask for (a b c), is it OK if I get (a b c d) in response? Ordering of the signed elements isn’t an issue here with how signatures are generated, more an issue of set math.
 - Similarly, what about parameters on the signed request? Can I fill in a “keyid" if none is specified? What about “alg”? I would assume “created” would always be added. Could I substitute a parameter value?
 - How do we handle error conditions if the responder is unable to fulfill the parameters of the requested signature? Should this be handled with an all out error or could we reply “successfully” but have a separate signature that doesn’t meet parameters?
 - Bikeshedding: should this be Want-Signature? Accept-Signature? Really-Need-You-To-Sign-This?

And finally this brings up another higher-level question: how does this align with, or possibly subsume, the http-origin-signed-responses[3] work from WEBPACK? Now that Message Signatures more properly covers responses and has clearer algorithm and key identifiers, the kinds of signed exchange defined in that draft are more able to be expressed using Message Signatures. This “Want-Signature” element is perhaps the last missing piece, as the WEBPACK proposal defines an “Accept-Signature” header with similar functions.

Thanks,

 — Justin

[1] https://github.com/httpwg/http-extensions/issues/1207 <https://github.com/httpwg/http-extensions/issues/1207>
[2] https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-2.3.11 <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-2.3.11>
[3] https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html <https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html>