7.2.8. Message Content

7.2.8. Message Content

On its own, this specification does not provide coverage for the content of an HTTP message under the signature, in either a request or a response. However, [DIGEST] defines a set of fields that allow a cryptographic digest of the content to be represented in a field. Once this field is created, it can be included just like any other field as defined in Section 2.1.

For example, in the following response message:

HTTP/1.1 200 OK Content-Type: application/json

{"hello": "world"}

The digest of the content can be added to the Content-Digest field as follows:

NOTE: '' line wrapping per RFC 8792

HTTP/1.1 200 OK Content-Type: application/json Content-Digest:
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:

{"hello": "world"}

This field can be included in a signature base just like any other field along with the basic signature parameters:

"@status": 200 "content-digest":
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=: "@signature-input": ("@status" "content-digest")

From here, the signing process proceeds as usual.

Upon verification, it is important that the verifier validate not only the signature but also the value of the Content-Digest field itself against the actual received content. Unless the verifier performs this step, it would be possible for an attacker to substitute the message content but leave the Content-Digest field value untouched to pass the signature. Since only the field value is covered by the signature directly, checking only the signature is not sufficient protection against such a substitution attack.

As discussed in [DIGEST], the value of the Content-Digest field is dependent on the content encoding of the message. If an intermediary changes the content encoding, the resulting Content-Digest value would change. This would in turn invalidate the signature. Any intermediary performing such an action would need to apply a new signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in Section 4.3.

Applications that make use of the req parameter (Section 2.4) also need to be aware of the limitations of this functionality. Specifically, if a client does not include something like a Content- Digest header field in the request, the server is unable to include a signature that covers the request's content.