What do you gain by signing the response headers? Ctrl+F for "body" yielded only 2 results. Wouldn't signing the response body be a bit more useful or am I missing something?
They keep talking about HTTP message and then they say:
> Applications use HTTP in a wide variety of ways, and may disagree on whether a particular piece of information in a message (e.g., the body, or the Date header field) is relevant.
And further down they say:
> For example, an authorization protocol could mandate that the Authorization header be covered to protect the authorization credentials and mandate the signature parameters contain a created parameter, while an API expecting HTTP message bodies could require the Digest header to be present and covered.
So to me it sounds like when the body is important, include a hash digest of it, and then include the digest header in the set of headers to sign.
Earlier they also explain why you can’t simply sign everything all together:
> HTTP permits and sometimes requires intermediaries to transform messages in a variety of ways. This may result in a recipient receiving a message that is not bitwise equivalent to the message that was originally sent. In such a case, the recipient will be unable to verify a signature over the raw bytes of the sender's HTTP message, as verifying digital signatures or MACs requires both signer and verifier to have the exact same signature input. Since the exact raw bytes of the message cannot be relied upon as a reliable source of signature input, the signer and verifier must derive the signature input from their respective versions of the message, via a mechanism that is resilient to safe changes that do not alter the meaning of the message.
If you are connecting over TLS, the server is already trusted and I see no reason to validate the response.
The theory may be the ability to tamper the response before it hits your code (such as in SDK), but even then a malicious SDK can make everything look legit.
> Applications use HTTP in a wide variety of ways, and may disagree on whether a particular piece of information in a message (e.g., the body, or the Date header field) is relevant.
And further down they say:
> For example, an authorization protocol could mandate that the Authorization header be covered to protect the authorization credentials and mandate the signature parameters contain a created parameter, while an API expecting HTTP message bodies could require the Digest header to be present and covered.
So to me it sounds like when the body is important, include a hash digest of it, and then include the digest header in the set of headers to sign.
Earlier they also explain why you can’t simply sign everything all together:
> HTTP permits and sometimes requires intermediaries to transform messages in a variety of ways. This may result in a recipient receiving a message that is not bitwise equivalent to the message that was originally sent. In such a case, the recipient will be unable to verify a signature over the raw bytes of the sender's HTTP message, as verifying digital signatures or MACs requires both signer and verifier to have the exact same signature input. Since the exact raw bytes of the message cannot be relied upon as a reliable source of signature input, the signer and verifier must derive the signature input from their respective versions of the message, via a mechanism that is resilient to safe changes that do not alter the meaning of the message.