Original text:
client is behind a TLS Inspection appliance).  In such cases, TLS cannot guarantee end-to-end message integrity or authenticity between the client and application.  Additionally, some operating <del> environments present obstacles that make it impractical to use TLS, or to use features necessary to provide message authenticity. Furthermore, some applications require the binding of an application- level key to the HTTP message, separate from any TLS certificates in use.  Consequently, while TLS can meet message integrity and </del>  authenticity needs for many HTTP-based applications, it is not a universal solution.  This document defines a mechanism for providing end-to-end integrity <del> and authenticity for components of an HTTP message.  The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application.  Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in any of the many ways permitted by HTTP. </del>  The signing mechanism described in this document consists of three parts: A common nomenclature and canonicalization rule set for the different protocol elements and other components of HTTP messages, <del> used to create the signature base. </del>  Algorithms for generating and verifying signatures over HTTP message components using this signature base through application <del> of cryptographic primitives. </del>  A mechanism for attaching a signature and related metadata to an HTTP message, and for parsing attached signatures and metadata from HTTP messages.  To facilitate this, this document defines the <del> "Signature-Input" and "Signature" fields. </del>  This document also provides a mechanism for negotiation the use of signatures in one or more subsequent messages via the "Accept- <del> Signature" field.  This optional negotiation mechanism can be used along with opportunistic or application-driven message signatures by either party. </del>  1.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:
client is behind a TLS Inspection appliance).  In such cases, TLS cannot guarantee end-to-end message integrity or authenticity between the client and application.  Additionally, some operating  <ins> environments present obstacles that make it impractical to use TLS (such as presentation of client certificates from a browser), or to use features necessary to provide message authenticity.  Furthermore, some applications require the binding of a higher-level application- specific key to the HTTP message, separate from any TLS certificates in use.  Consequently, while TLS can meet message integrity and </ins> authenticity needs for many HTTP-based applications, it is not a universal solution. <ins> Additionally, many applications need to be able to generate and verify signatures despite incomplete knowledge of the HTTP message as seen on the wire, due to the use of libraries, proxies, or application frameworks that alter or hide portions of the message from the application at the time of signing or verification.  These applications need a means to protect the parts of the message that are most relevant to the application without having to violate layering and abstraction. Finally, object-based signature mechanisms such as JWS require the intact conveyance of the exact information that was signed.  When applying such technologies to an HTTP message, elements of the HTTP message need to be duplicated in the object payload either directly or through inclusion of a hash.  This practice introduces complexity since the repeated information needs to be carefully checked for consistency when the signature is verified. </ins> This document defines a mechanism for providing end-to-end integrity  <ins> and authenticity for components of an HTTP message by use of a detached signature.  The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application.  Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in any of the many ways permitted by HTTP. </ins> The signing mechanism described in this document consists of three parts: A common nomenclature and canonicalization rule set for the different protocol elements and other components of HTTP messages,  <ins> used to create the signature base. (covered-components) </ins> Algorithms for generating and verifying signatures over HTTP message components using this signature base through application  <ins> of cryptographic primitives. (message-signatures) </ins> A mechanism for attaching a signature and related metadata to an HTTP message, and for parsing attached signatures and metadata from HTTP messages.  To facilitate this, this document defines the  <ins> "Signature-Input" and "Signature" fields. (attach-signature) </ins> This document also provides a mechanism for negotiation the use of signatures in one or more subsequent messages via the "Accept-  <ins> Signature" field (request-signature).  This optional negotiation mechanism can be used along with opportunistic or application-driven message signatures by either party. </ins> 1.1.