Original text:
level algorithm specification instead, preventing an attacker from substituting the algorithm specified.  7.4. 7.4.1.

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:
level algorithm specification instead, preventing an attacker from substituting the algorithm specified. <ins> 7.3.7. When applying content-request-response or signature-multiple to a message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value.  While it would seem that this practice would transitively cover the components under the original signature in a verifiable fashion, the attacks described in JACKSON2019 can be used to impersonate a signature output value on an unrelated message. In this example, Alice intends to send a signed request to Bob, and Bob wants to provide a signed response to Alice that includes a cryptographic proof that Bob is responding to Alice's incoming message.  Mallory wants to intercept this traffic and replace Alice's message with her own, without Alice being aware that the interception has taken place. Alice creates a message, "Req_A" and applies a signature "Sig_A" using her private key "Key_A_Sign". Alice believes she is sending "Req_A" to Bob. Mallory intercepts "Req_A" and reads the value "Sig_A" from this message. Mallory generates a different message "Req_M" to send to Bob instead. Mallory crafts a signing key "Key_M_Sign" such that she can create a valid signature "Sig_M" over her request "Req_M" using this key, but the byte value of "Sig_M" exactly equals that of "Sig_A". Mallory sends "Req_M" with "Sig_M" to Bob. Bob validates "Sig_M" against Mallory's verification key, "Key_M_Verify".  At no time does Bob think that he's responding to Alice. Bob responds with response message "Res_B" to "Req_M" and creates signature "Sig_B" over this message using his key, "Key_B_Sign". Bob includes the value of "Sig_M" under "Sig_B"'s covered components, but nothing elese from the request message. Mallory receives the response "Res_B" from Bob, including the signature "Sig_B" value.  Mallory replays this response to Alice. Alice reads "Res_B" from Mallory and verifies "Sig_B" using Bob's verification key, "Key_B_Verify".  Alice includes the bytes of her original signature "Sig_A" in the signature base, and the signature verifies. Alice is led to believe that Bob has responded to her message, and believes she has cryptographic proof of this happening, but in fact Bob responded to Mallory's malicious request and Alice is none the wiser. To mitigate this, Bob can sign more portions of the request message than just the Signature field, in order to more fully differentiate Alice's message from Mallory's.  Applications using this feature, particularly for non-repudiation purposes, can stipulate that any components required in the original signature also be covered separately in the second signature.  For signed messages, requiring coverage of the corresponding Signature-Input field of the first signature ensures that unique items such as nonces and timestamps are also covered sufficiently by the second signature. </ins> 7.4. 7.4.1.