Original text:
This would result in the following unsigned response message:  To cryptographically link the response to the request, the server <del> signs the response with its own key and includes the method, authority, and the signature value "sig1" from the request in the covered components of the response.  The signature base for this example is: </del>  The signed response message is: <del> Since the request's signature value itself is not repeated in the response, the requester MUST keep the original signature value around long enough to validate the signature of the response that uses this component identifier. </del> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic.  The "req" parameter MUST NOT be used in a signature that targets a request message.

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
This would result in the following unsigned response message: <ins> The server signs the response with its own key, including the "@status" code and several header fields in the covered components. </ins> To cryptographically link the response to the request, the server  <ins> includes the method, authority, and the signature and signature input labeled "sig1" from the request in the covered components of the response.  The signature base for this example is: </ins> The signed response message is:  Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. <ins> Since the signature component values from the request are not repeated in the response, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier.  In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application. Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values as the client would not be able to validate the resulting signature. Applications needing this type of binding have to sign sufficient portion the request to ensure that it is uniquely tied to the response.  Signing the signature value of a signed request alone does not provide sufficient coverage in most cases, as discussed in security-sign-signature. The response signature can only cover what is included in the request.  Therefore, if an application needs to bind the message content of the request in its response, the client needs to include a means for covering that content, such as a Content-Digest field.  See the discussion in security-message-content for more information. </ins> The "req" parameter MUST NOT be used in a signature that targets a request message.