Forbid "(request-target)" in response signature

[liamdennehy]

Right now there is no way for a response to transport all the parameters required to reconstruct the (request-target) signing string component.

As the messages are exchanged obviously both the client and server know the values, as one transmitted and the other reacted to those in the other half of the conversation, but any signature should be verifiable given only the evidence of the content it protects.

Since this information is not present on a response, (request-target) should be prohibited from appearing in a response signature's headers. If required the server should construct a header specifically for this purpose, which could be as simple as Request-Target, and so no special handling is required to sign it.

[ioggstream]

A complex matter indeed :)

Can you please provide some more context on that?

afaik:

• it is common for a server providing an Authoritative Response A-R, to access the request context.
  • this may not happen if the Authoritative A-R is not provided by the application server.
  • In this case the A-R should provide the validation of the signature and the signature response.

[liamdennehy]

When I validate any digital signature I should have all the information to hand that goes into that signature to construct the signed data consistently. Compare S/MIME, Signed PDFs, JWS etc.

However the :method, :path and :query parms are not transmitted in a response, so we need an independent source. For now the assumption is simply the state known to the server (responding to a request presenting this info) and the client (expecting a response to the request just transmitted with this info).

Two cases present issues:

1. An intermediate wishing to validate a signature needs to hold on to these parameters in their own state to add them to the canonicalised string - again, cannot be derived from a response itself as they are not present. This adds complexity.
2. A validator may also be an offline activity e.g. an auditor or a review following a dispute about a request (ie non-repudiation). Both would need to retrieve the parameters in (request-target) in addition to the HTTP response itself, meaning any store of these artefacts need to do the same. Again, more complexity.

Simply adding it as a header makes the most sense. This doesn't mean the value is correct (a response may present a different representation of the URI) but is an unequivocal source for the pseudo-header's value.

Omitting this information as a whole from any signed response doesn't make too much sense. All we would have is a signed representation, but without the request info there is insufficient context to know what the data means unless the content expresses this explicitly.

[ioggstream]

See https://github.com/WICG/webpackage/blob/master/draft-yasskin-httpbis-origin-signed-exchanges-impl.md#signature-validity--signature-validity

We are asymptotically tending to signed-exchanges :P