<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2.2) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-message-signatures-19" number="9421" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title>HTTP Message Signatures</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-message-signatures-19"/> name="RFC" value="9421"/>
    <author initials="A." surname="Backman" fullname="Annabelle Backman" role="editor">
      <organization>Amazon</organization>
      <address>
        <postal>
          <street>P.O. Box 81226</street>
          <city>Seattle</city>
          <region>WA</region>
          <code>98108-1226</code>
          <country>United States of America</country>
        </postal>
        <email>richanna@amazon.com</email>
        <uri>https://www.amazon.com/</uri>
      </address>
    </author>
    <author initials="J." surname="Richer" fullname="Justin Richer" role="editor">
      <organization>Bespoke Engineering</organization>
      <address>
        <email>ietf@justin.richer.org</email>
        <uri>https://bspk.io/</uri>
      </address>
    </author>
    <author initials="M." surname="Sporny" fullname="Manu Sporny">
      <organization>Digital Bazaar</organization>
      <address>
        <postal>
          <street>203 Roanoke Street W.</street>
          <city>Blacksburg</city>
          <region>VA</region>
          <code>24060</code>
          <country>United States of America</country>
        </postal>
        <email>msporny@digitalbazaar.com</email>
        <uri>https://manu.sporny.org/</uri>
      </address>
    </author>

    <date year="2023" month="July" day="27"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup> year="2024" month="February"/>
    <area>art</area>
    <workgroup>httpbis</workgroup>
    <keyword>PKI</keyword>
    <abstract>
      <?line 129?>

<t>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer, signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier.
This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>),
        which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
        Working Group information can be found at <eref target="https://httpwg.org/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/signatures"/>.</t>
    </note>
  </front>
  <middle>
    <?line 134?>

<section anchor="intro">
      <name>Introduction</name>
      <t>Message integrity and authenticity are security properties that are critical to the secure operation of many HTTP applications.
Application developers typically rely on the transport layer to provide these properties, by operating their application over TLS <xref target="TLS"/>. target="RFC8446"/>. However, TLS only guarantees these properties over a single TLS connection, and the path between the client and application may be composed of multiple independent TLS connections (for example, if the application is hosted behind a TLS-terminating gateway or if the 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 environments present obstacles that make it impractical to use TLS (such as the presentation of client certificates from a browser), 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 authenticity needs for many HTTP-based applications, it is not a universal solution.</t>
      <t>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.</t>
      <t>Finally, object-based signature mechanisms such as JSON Web Signature <xref target="JWS"/> target="RFC7515"/> 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 the inclusion of a hash. This practice introduces complexity complexity, since the repeated information needs to be carefully checked for consistency when the signature is verified.</t>
      <t>This document defines a mechanism for providing end-to-end integrity and authenticity for components of an HTTP message by use of using a detached signature on HTTP messages. 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 many of the ways permitted by HTTP.</t>
      <t>The signing mechanism described in this document consists of three parts:</t>
      <ul spacing="normal">
        <li>A common nomenclature and canonicalization rule set for the different protocol elements and other components of HTTP messages, used to create the signature base. base (<xref target="covered-components"/>)</li> target="covered-components"/>).</li>
        <li>Algorithms for generating and verifying signatures over HTTP message components using this signature base through the application of cryptographic primitives. primitives (<xref target="message-signatures"/>)</li> target="message-signatures"/>).</li>
        <li>A mechanism for attaching a signature and related metadata to an HTTP message, message and for parsing attached signatures and metadata from HTTP messages. To facilitate this, this document defines the "Signature-Input" and "Signature" fields. fields (<xref target="attach-signature"/>)</li> target="attach-signature"/>).</li>
      </ul>
      <t>This document also provides a mechanism for negotiation negotiating the use of signatures in one or more subsequent messages via the "Accept-Signature" field (<xref target="request-signature"/>). This optional negotiation mechanism can be used along with opportunistic or application-driven message signatures by either party.</t>
      <t>The mechanisms defined in this document are important tools that can be used to build an overall security mechanism for an application. This toolkit provides some powerful capabilities, capabilities but does is not sufficient in creating an overall security story. In particular, the requirements listed in <xref target="application"/> and the security considerations discussed in <xref target="security"/> are of high importance to all implementors of this specification. For example, this specification does not define a means to directly cover HTTP message content (defined in <xref section="6.4" sectionFormat="of" target="HTTP"/>), but target="RFC9110"/>); rather, it relies on the <xref target="DIGEST"/> Digest specification <xref target="RFC9530"/> to provide a hash of the message content, as discussed in <xref target="security-message-content"/>.</t>
      <section anchor="definitions">
        <name>Conventions and Terminology</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14
        <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
        <?line -18?>
<t>The terms "HTTP message", "HTTP request", "HTTP response",
"target URI", "gateway", "header field", "intermediary", "request target",
"trailer field", "sender", "method", and "recipient" are used as defined in <xref target="HTTP"/>.</t> target="RFC9110"/>.</t>
        <t>For brevity, the term "signature" on its own is used in this document to refer to both digital signatures (which use asymmetric cryptography) and keyed MACs (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or keyed MAC over a given signature base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.</t>
        <t>This document uses the following terminology from <xref section="3" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/>
to specify data types: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, and Boolean.</t>
        <t>This document defines several string constructions using ABNF <xref target="ABNF"/> target="RFC5234"/> and uses the following ABNF rules: <tt>VCHAR</tt>, <tt>SP</tt>, <tt>DQUOTE</tt>, and <tt>LF</tt>. This document uses the following ABNF rules from <xref target="STRUCTURED-FIELDS"/>: target="RFC8941"/>: <tt>sf-string</tt>, <tt>inner-list</tt>, and <tt>parameters</tt>. This document uses the following ABNF rules from <xref target="HTTP"/> target="RFC9110"/> and <xref target="HTTP1"/>: target="RFC9112"/>: <tt>field-content</tt>, <tt>obs-fold</tt>, and <tt>obs-text</tt>.</t>
        <t>In addition to those listed above, this document uses the following terms:</t>
        <dl newline="true">
          <dt>HTTP Message Signature:</dt>
          <dd>
            <t>A digital signature or keyed MAC that covers one or more portions of an HTTP message. Note that a given HTTP Message message can contain multiple HTTP Message Signatures.</t> message signatures.</t>
          </dd>
          <dt>Signer:</dt>
          <dd>
            <t>The entity that is generating or has generated an HTTP Message Signature. message signature. Note that multiple entities can act as signers and apply separate HTTP Message Signatures message signatures to a given HTTP Message.</t> message.</t>
          </dd>
          <dt>Verifier:</dt>
          <dd>
            <t>An entity that is verifying or has verified an HTTP Message Signature message signature against an HTTP Message. message. Note that an HTTP Message Signature message signature may be verified multiple times, potentially by different entities.</t>
          </dd>
          <dt>HTTP Message Component:</dt>
          <dd>
            <t>A portion of an HTTP message that is capable of being covered by an HTTP Message Signature.</t> message signature.</t>
          </dd>
          <dt>Derived Component:</dt>
          <dd>
            <t>An HTTP Message Component message component derived from the HTTP message through the use of a specified algorithm or process. See <xref target="derived-components"/>.</t>
          </dd>
          <dt>HTTP Message Component Name:</dt>
          <dd>
            <t>A string String that identifies an HTTP Message Component's message component's source, such as a field name or derived component name.</t>
          </dd>
          <dt>HTTP Message Component Identifier:</dt>
          <dd>
            <t>The combination of an HTTP Message Component Name message component name and any parameters that parameters. This combination uniquely identifies a specific HTTP Message Component in message component with respect to a particular HTTP Message Signature message signature and the HTTP Message message it applies to.</t>
          </dd>
          <dt>HTTP Message Component Value:</dt>
          <dd>
            <t>The value associated with a given component identifier within the context of a particular HTTP Message. message. Component values are derived from the HTTP Message message and are usually subject to a canonicalization process.</t>
          </dd>
          <dt>Covered Components:</dt>
          <dd>
            <t>An ordered set of HTTP message component identifiers for fields (<xref target="http-fields"/>) and derived components (<xref target="derived-components"/>) that indicates the set of message components covered by the signature, never including the <tt>@signature-params</tt> identifier itself. The order of this set is preserved and communicated between the signer and verifier to facilitate reconstruction of the signature base.</t>
          </dd>
          <dt>Signature Base:</dt>
          <dd>
            <t>The sequence of bytes generated by the signer and verifier using the covered components set and the HTTP Message. message. The signature base is processed by the cryptographic algorithm to produce or verify the HTTP Message Signature.</t> message signature.</t>
          </dd>
          <dt>HTTP Message Signature Algorithm:</dt>
          <dd>
            <t>A cryptographic algorithm that describes the signing and verification process for the signature, defined in terms of the <tt>HTTP_SIGN</tt> and <tt>HTTP_VERIFY</tt> primitives described in <xref target="signature-methods"/>.</t>
          </dd>
          <dt>Key Material:</dt>
          <dd>
            <t>The key material required to create or verify the signature. The key material is often identified with an explicit key identifier, allowing the signer to indicate to the verifier which key was used.</t>
          </dd>
          <dt>Creation Time:</dt>
          <dd>
            <t>A timestamp representing the point in time that the signature was generated, as asserted by the signer.</t>
          </dd>
          <dt>Expiration Time:</dt>
          <dd>
            <t>A timestamp representing the point in time after which the signature should no longer be accepted by the verifier, as asserted by the signer.</t>
          </dd>
          <dt>Target Message:</dt>
          <dd>
            <t>The HTTP message to which an HTTP Message Signature message signature is applied.</t>
          </dd>
          <dt>Signature Context:</dt>
          <dd>
            <t>The data source from which the HTTP Message Component Values message component values are drawn. The context includes the target message and any additional information the signer or verifier might have, such as the full target URI of a request or the related request message for a response.</t>
          </dd>
        </dl>
        <t>The term "Unix "UNIX timestamp" refers to what Section 4.16 of <xref target="POSIX"/> calls "Seconds Since "seconds since the Epoch".</t>
        <t>This document contains non-normative examples of partial and complete HTTP messages. Some examples use a single trailing backslash <tt>\</tt> (<tt>\</tt>) to indicate line wrapping for long values, as per <xref target="RFC8792"/>. The <tt>\</tt> character and leading spaces on wrapped lines are not part of the value.</t>
      </section>
      <section anchor="requirements">
        <name>Requirements</name>
        <t>HTTP permits permits, and sometimes requires requires, intermediaries to transform messages in a variety of ways. This can 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 integrity protections 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 base. Since the exact raw bytes of the message cannot be relied upon as a reliable source for a signature base, the signer and verifier have to independently create the signature base 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.</t>
        <t>For a variety of reasons, it is impractical to strictly define what constitutes a safe change versus an unsafe one. 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 message content, the method, or a particular header field) is relevant. Thus, a general purpose general-purpose solution needs to provide signers with some degree of control over which message components are signed.</t>
        <t>HTTP applications may be running in environments that do not provide complete access to or control over HTTP messages (such as a web browser's JavaScript environment), environment) or may be using libraries that abstract away the details of the protocol (such as <eref target="https://openjdk.java.net/groups/net/httpclient/intro.html">the Java HTTPClient HTTP Client (HttpClient) library</eref>). These applications need to be able to generate and verify signatures despite incomplete knowledge of the HTTP message.</t>
      </section>
      <section anchor="transforms">
        <name>HTTP Message Transformations</name>
        <t>As mentioned earlier, HTTP explicitly permits permits, and in some cases requires requires, implementations to transform messages in a variety of ways. Implementations are required to tolerate many of these transformations. What follows is a non-normative and non-exhaustive list of transformations that could occur under HTTP, provided as context:</t>
        <ul spacing="normal">
          <li>Re-ordering
          <li>Reordering of fields with different field names (<xref section="5.3" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>Combination of fields with the same field name (<xref section="5.2" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>Removal of fields listed in the Connection header field (<xref section="7.6.1" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>Addition of fields that indicate control options (<xref section="7.6.1" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>Addition or removal of a transfer coding (<xref section="7.7" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>Addition of fields such as <tt>Via</tt> Via (<xref section="7.6.3" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) and <tt>Forwarded</tt> Forwarded (<xref section="4" sectionFormat="of" target="RFC7239"/>).</li>
          <li>Conversion between different versions of the HTTP protocol (e.g., HTTP/1.x to HTTP/2, or vice-versa).</li> vice versa).</li>
          <li>Changes in casing case (e.g., "Origin" to "origin") of any case-insensitive components such as field names, request URI scheme, or host.</li>
          <li>Changes to the request target and authority that that, when applied together together, do not
  result in a change to the message's target URI, as defined in <xref section="7.1" sectionFormat="of" target="HTTP"/>.</li> target="RFC9110"/>.</li>
        </ul>
        <t>Additionally, there are some transformations that are either deprecated or otherwise not allowed, allowed but still that could still occur in the wild. These transformations can still be handled without breaking the signature, and signature; they include things
such actions as:</t>
        <ul spacing="normal">
          <li>Use, addition, or removal of leading or trailing whitespace in a field value.</li>
          <li>Use, addition, or removal of <tt>obs-fold</tt> in field values (<xref section="5.2" sectionFormat="of" target="HTTP1"/>).</li> target="RFC9112"/>).</li>
        </ul>
        <t>We can identify these types of transformations as ones transformations that should not prevent signature verification, even when performed on message components covered by the signature. Additionally, all changes to components not covered by the signature should not prevent signature verification.</t>
        <t>Some examples of these kinds of transformations, and the effect they have on the message signature, are found in <xref target="example-transform"/>.</t>
        <t>Other transformations, such as parsing and re-serializing reserializing the field values of a covered component or changing the value of a derived component, can cause a signature to no longer validate against a target message. Applications of this specification need to take care to ensure that the transformations expected by the application are adequately handled by the choice of covered components.</t>
      </section>
      <section anchor="application">
        <name>Application of HTTP Message Signatures</name>
        <t>HTTP Message Signatures message signatures are designed to be a general-purpose tool applicable in a wide variety of circumstances and applications. In order to properly and safely apply HTTP Message Signatures, message signatures, an application or profile of this specification <bcp14>MUST</bcp14> specify specify, at least a minimum, all of the following items:</t>
        <ul spacing="normal">
          <li>The set of <xref target="covered-components">component identifiers</xref> and <xref target="signature-params">signature parameters</xref> that are expected and required to be included in the covered components list. For example, an authorization protocol could mandate that the Authorization field be covered to protect the authorization credentials and mandate that the signature parameters contain a <tt>created</tt> parameter, parameter (<xref target="signature-params"/>), while an API expecting semantically relevant HTTP message content could require the Content-Digest field defined in <xref target="DIGEST"/> target="RFC9530"/> to be present and covered as well as mandate a value for the <tt>tag</tt> parameter (<xref target="signature-params"/>) that is specific to the API being protected.</li>
          <li>The expected structured field Structured Field types (<xref target="STRUCTURED-FIELDS"/>) <xref target="RFC8941"/> of any required or expected covered component fields or parameters.</li>
          <li>A means of retrieving the key material used to verify the signature. An application will usually use the <tt>keyid</tt> parameter of the signature parameters (<xref target="signature-params"/>) and define rules for resolving a key from there, though the appropriate key could be known from other means such as pre-registration preregistration of a signer's key.</li>
          <li>The set of allowable signature algorithms to be used by signers and accepted by verifiers.</li>
          <li>A means of determining that the signature algorithm used to verify the signature is appropriate for the key material and context of the message. For example, the process could use the <tt>alg</tt> parameter of the signature parameters (<xref target="signature-params"/>) to state the algorithm explicitly, derive the algorithm from the key material, or use some pre-configured preconfigured algorithm agreed upon by the signer and verifier.</li>
          <li>A means of determining that a given key and algorithm used for a signature are appropriate for the context of the message. For example, a server expecting only ECDSA signatures should know to reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.</li>
          <li>A means of determining the context for derivation of message components from an HTTP message and its application context. While this is normally the target HTTP message itself, the context could include additional information known to the application through configuration, such as an external host name.</li> hostname.</li>
          <li>If binding between a request and response is needed using the mechanism provided in <xref target="content-request-response"/>, all elements of the request message and the response message that would be required to provide properties of such a binding.</li>
          <li>The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is inappropriate, the validity time window is out of specification, a component value cannot be calculated, or any other errors in occur during the signature verification process. For example, if a signature is being used as an authentication mechanism, an HTTP status code of 401 Unauthorized (Unauthorized) or 403 Forbidden (Forbidden) could be appropriate. If the response is from an HTTP API, a response with an HTTP status code of such as 400 Bad Request (Bad Request) could include more details as described in <xref target="RFC7807"/>, target="RFC7807"/> <xref target="RFC9457"/>, such as an indicator that the wrong key material was used.</li>
        </ul>
        <t>When choosing these parameters, an application of HTTP message signatures has to ensure that the verifier will have access to all required information needed to re-create recreate the signature base. For example, a server behind a reverse proxy would need to know the original request URI to make use of the derived component <tt>@target-uri</tt>, even though the apparent target URI would be changed by the reverse proxy (see also <xref target="security-message-component-context"/>). Additionally, an application using signatures in responses would need to ensure that clients receiving signed responses have access to all the signed portions of the message, including any portions of the request that were signed by the server using the related-response parameter.</t>
        <t>The details of <tt>req</tt> ("request-response") parameter (<xref target="content-request-response"/>).</t>
        <t>Details regarding this kind of profiling are within the purview of the application and outside the scope of this specification, however specification; however, some additional considerations are discussed in <xref target="security"/>. In particular, when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in <xref target="security-coverage"/>
Sections&nbsp;<xref target="security-coverage" format="counter"/> and  <xref target="security-message-content"/>. target="security-message-content" format="counter"/>. This specification defines only part of a full security system for an application. When building a complete security system based on this tool, it is important to perform a security analysis of the entire system system, of which HTTP Message Signatures message signatures is a part. Historical systems, such as AWS Signature Version 4 <xref target="AWS-SIGv4"/>, can provide inspiration and examples of how to apply similar mechanisms to an application, though review of such historical systems does not negate the need for a security analysis of an application of HTTP Message Signatures.</t> message signatures.</t>
      </section>
    </section>
    <section anchor="covered-components">
      <name>HTTP Message Components</name>
      <t>In order to allow signers and verifiers to establish which components are covered by a signature, this document defines component identifiers for components covered by an HTTP Message Signature, message signature, a set of rules for deriving and canonicalizing the values associated with these component identifiers from the HTTP Message, message, and the means for combining these canonicalized values into a signature base.</t>
      <t>The signature context for deriving these values <bcp14>MUST</bcp14> be accessible to both the signer and the verifier of the message. The context <bcp14>MUST</bcp14> be the same across all components in a given signature. For example, it would be an error to use the raw query string for the <tt>@query</tt> derived component but combined query and form parameters for the <tt>@query-param</tt> derived component. For more considerations of regarding the message component context, see <xref target="security-message-component-context"/>.</t>

      <t>A component identifier is composed of a component name and any parameters associated with that name. Each component name is either an HTTP field name (<xref target="http-fields"/>) or a registered derived component name (<xref target="derived-components"/>). The possible parameters for a component identifier are dependent on the component identifier, and the HTTP identifier. The "HTTP Signature Component Parameters registry cataloging Parameters" registry, which catalogs all possible parameters parameters, is defined in <xref target="component-param-registry"/>.</t>
      <t>Within a single list of covered components, each component identifier <bcp14>MUST</bcp14> occur only once. One component identifier is distinct from another if the component name differs, differs or if any of the parameters differ for the same component name. Multiple component identifiers having the same component name <bcp14>MAY</bcp14> be included if they have parameters that make them distinct, such as <tt>"foo";bar</tt> and <tt>"foo";baz</tt>. The order of parameters <bcp14>MUST</bcp14> be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality checks. That is to say, <tt>"foo";bar;baz</tt> cannot be in the same message as <tt>"foo";baz;bar</tt>, since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form.</t>
      <t>The component value associated with a component identifier is defined by the identifier itself. Component values <bcp14>MUST NOT</bcp14> contain newline (<tt>\n</tt>) characters. Some HTTP message components can undergo transformations that change the bitwise value without altering the meaning of the component's value (for example, when combining field values). Message component values therefore need to be canonicalized before they are signed, to ensure that a signature can be verified despite such intermediary transformations. This document defines rules for each component identifier that transform the identifier's associated component value into such a canonical form.</t>
      <t>The following sections define component identifier names, their parameters, their associated values, and the canonicalization rules for their values. The method for combining message components into the signature base is defined in <xref target="create-sig-input"/>.</t>
      <section anchor="http-fields">
        <name>HTTP Fields</name>
        <t>The component name for an HTTP field is the lowercased form of its field name as defined in <xref section="5.1" sectionFormat="of" target="HTTP"/>. target="RFC9110"/>. While HTTP field names are case-insensitive, case insensitive, implementations <bcp14>MUST</bcp14> use lowercased field names (e.g., <tt>content-type</tt>, <tt>date</tt>, <tt>etag</tt>) when using them as component names.</t>
        <t>The component value for an HTTP field is the field value for the named field as defined in <xref section="5.5" sectionFormat="of" target="HTTP"/>. target="RFC9110"/>. The field value <bcp14>MUST</bcp14> be taken from the named header field of the target message unless this behavior is overridden by additional parameters and rules, such as the <tt>req</tt> and <tt>tr</tt> flags, below. For most fields, the field value is an ASCII string as recommended by <xref target="HTTP"/>, target="RFC9110"/>, and the component value is exactly that string. Other encodings could exist in some implementations, and all non-ASCII field values <bcp14>MUST</bcp14> be encoded to ASCII before being added to the signature base. The <tt>bs</tt> parameter defined parameter, as described in <xref target="http-field-byte-sequence"/> target="http-field-byte-sequence"/>, provides a method for wrapping such problematic field values.</t>
        <t>Unless overridden by additional parameters and rules, HTTP field values <bcp14>MUST</bcp14> be combined into a single value as defined in <xref section="5.2" sectionFormat="of" target="HTTP"/> target="RFC9110"/> to create the component value. Specifically, HTTP fields sent as multiple fields <bcp14>MUST</bcp14> be combined by concatenating the values using a single comma and a single space as a separator ("," + " "). Note that intermediaries are allowed to combine values of HTTP fields with any amount of whitespace between the commas, and if this behavior is not accounted for by the verifier, the signature can fail fail, since the signer and verifier will see a different component value in their respective signature bases. For robustness, it is <bcp14>RECOMMENDED</bcp14> that signed messages include only a single instance of any field covered under the signature, particularly with the value for any list-based fields serialized using the algorithm below. This approach increases the chances of the field value remaining untouched through intermediaries. Where that approach is not possible and multiple instances of a field need to be sent separately, it is <bcp14>RECOMMENDED</bcp14> that signers and verifiers process any list-based fields taking all individual field values and combining them based on the strict algorithm below, to counter possible intermediary behavior. When the field in question is a structured field Structured Field of type List or Dictionary, this effect can be accomplished more directly by requiring the strict structured field Structured Field serialization of the field value, as described in <xref target="http-field-structured"/>.</t>
        <t>Note that some HTTP fields, such as Set-Cookie (<xref target="COOKIE"/>), <xref target="RFC6265"/>, do not follow a syntax that allows for the combination of field values in this manner (such that the combined output is unambiguous from multiple inputs). Even though the component value is never parsed by the message signature process and is used only as part of the signature base in <xref target="create-sig-input"/>, (<xref target="create-sig-input"/>), caution needs to be taken when including such fields in signatures signatures, since the combined value could be ambiguous. The <tt>bs</tt> parameter defined parameter, as described in <xref target="http-field-byte-sequence"/> target="http-field-byte-sequence"/>, provides a method for wrapping such problematic fields. See <xref target="security-non-list"/> for more discussion of regarding this issue.</t>
        <t>If the correctly combined value is not directly available for a given field by an implementation, the following algorithm will produce canonicalized results for list-based fields:</t>
        <ol spacing="normal" type="1"><li>Create an ordered list of the field values of each instance of the field in the message, in the order that they occur (or will occur) in the message.</li>
          <li>Strip leading and trailing whitespace from each item in the list. Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this will would be a no-op in a compliant implementation.</li>
          <li>Remove any obsolete line-folding line folding within the line line, and replace it with a single space (" "), as discussed in <xref section="5.2" sectionFormat="of" target="HTTP1"/>. target="RFC9112"/>. Note that this behavior is specific to HTTP/1.1 and does not apply to other versions of the HTTP specification specification, which do not allow internal line folding.</li>
          <li>Concatenate the list of values together with a single comma (",") and a single space (" ") between each item.</li>
        </ol>
        <t>The resulting string is the component value for the field.</t>
        <t>Note that some HTTP fields have values with multiple valid serializations that have equivalent semantics, such as allow allowing case-insensitive values that intermediaries could change. Applications signing and processing such fields <bcp14>MUST</bcp14> consider how to handle the values of such fields to ensure that the signer and verifier can derive the same value, as discussed in <xref target="security-field-values"/>.</t>
        <t>Following
        <t>The following are non-normative examples of component values for header fields, given the following example HTTP message fragment:</t>
        <sourcecode type="http-message"><![CDATA[
Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT
X-OWS-Header:   Leading and trailing whitespace.
X-Obs-Fold-Header: Obsolete
    line folding.
Cache-Control: max-age=60
Cache-Control:    must-revalidate
Example-Dict:  a=1,    b=2;x=1;y=2,   c=(a   b   c)
]]></sourcecode>
        <t>The following example shows the component values for these example header fields, presented using the signature base format defined in <xref target="create-sig-input"/>:</t>
        <artwork><![CDATA[
"host": www.example.com
"date": Tue, 20 Apr 2021 02:07:56 GMT
"x-ows-header": Leading and trailing whitespace.
"x-obs-fold-header": Obsolete line folding.
"cache-control": max-age=60, must-revalidate
"example-dict": a=1,    b=2;x=1;y=2,   c=(a   b   c)
]]></artwork>
        <t>Empty HTTP fields can also be signed when present in a message. The canonicalized value is the empty string. This means that the following empty header, header field, with (SP) indicating a single trailing space character before the empty field value:</t>
        <artwork><![CDATA[
X-Empty-Header:(SP)
]]></artwork>
        <t>Is
        <t>is serialized by the <xref target="create-sig-input">signature base generation algorithm</xref> with an empty string value following the colon and space added after the content component identifier.</t>
        <artwork><![CDATA[
"x-empty-header":(SP)
]]></artwork>
        <t>Any HTTP field component identifiers <bcp14>MAY</bcp14> have the following parameters in specific circumstances, each described in detail in their own sections:</t>
        <dl>
          <dt><tt>sf</tt></dt>
          <dd>
            <t>A boolean Boolean flag indicating that the component value is serialized using strict encoding
of the structured field Structured Field value (<xref target="http-field-structured"/>).</t>
          </dd>
          <dt><tt>key</tt></dt>
          <dd>
            <t>A string String parameter used to select a single member value from a Dictionary structured field Structured Field (<xref target="http-field-dictionary"/>).</t>
          </dd>
          <dt><tt>bs</tt></dt>
          <dd>
            <t>A boolean Boolean flag indicating that individual field values are encoded using Byte Sequence data structures before being combined into the component value (<xref target="http-field-byte-sequence"/>).</t>
          </dd>
          <dt><tt>req</tt></dt>
          <dd>
            <t>A boolean Boolean flag for signed responses indicating that the component value is derived from the request that triggered this response message and not from the response message directly. Note that this parameter can also be applied to any derived component identifiers that target the request (<xref target="content-request-response"/>).</t>
          </dd>
          <dt><tt>tr</tt></dt>
          <dd>
            <t>A boolean Boolean flag indicating that the field value is taken from the trailers of the message as defined in <xref section="6.5" sectionFormat="of" target="HTTP"/>. target="RFC9110"/>. If this flag is absent, the field value is taken from the headers header fields of the message as defined in <xref section="6.3" sectionFormat="of" target="HTTP"/> target="RFC9110"/> (<xref target="http-trailer"/>).</t>
          </dd>
        </dl>
        <t>Multiple parameters <bcp14>MAY</bcp14> be specified together, though some combinations are redundant or incompatible. For example, the <tt>sf</tt> parameter's functionality is already covered when the <tt>key</tt> parameter is used on a dictionary Dictionary item, since <tt>key</tt> requires strict serialization of the value. The <tt>bs</tt> parameter, which requires the raw bytes of the field values from the message, is not compatible with the use of the <tt>sf</tt> or <tt>key</tt> parameters, which require the parsed data structures of the field values after combination.</t>
        <t>Additional parameters can be defined in the HTTP "HTTP Signature Component Parameters Parameters" registry established in <xref target="component-param-registry"/>.</t>
        <section anchor="http-field-structured">
          <name>Strict Serialization of HTTP Structured Fields</name>
          <t>If the value of an HTTP field is known by the application to be a structured field Structured Field type (as defined in <xref target="STRUCTURED-FIELDS"/> target="RFC8941"/> or its extensions or updates), updates) and the expected type of the structured field Structured Field is known, the signer <bcp14>MAY</bcp14> include the <tt>sf</tt> parameter in the component identifier.
If this parameter is included with a component identifier, the HTTP field value <bcp14>MUST</bcp14> be serialized using the formal serialization rules specified in <xref section="4" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> (or the
applicable formal serialization section of its extensions or updates) applicable to
the type of the HTTP field. Note that this process
will replace any optional internal whitespace with a single space character, among other potential transformations of the value.</t>
          <t>If multiple field values occur within a message, these values <bcp14>MUST</bcp14> be combined into a single List or Dictionary structure before serialization.</t>
          <t>If the application does not know the type of the field, field or the application does not know how to serialize the type of the field, the use of this flag will produce an error. As a consequence, the signer can only reliably sign fields using this flag when the verifier's system knows the type as well.</t>
          <t>For example, the following dictionary Dictionary field is a valid serialization:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Dict:  a=1,    b=2;x=1;y=2,   c=(a   b   c)
]]></sourcecode>
          <t>If included in the signature base without parameters, its value would be:</t>
          <artwork><![CDATA[
"example-dict": a=1,    b=2;x=1;y=2,   c=(a   b   c)
]]></artwork>
          <t>However, if the <tt>sf</tt> parameter is added, the value is re-serialized reserialized as follows:</t>
          <artwork><![CDATA[
"example-dict";sf: a=1, b=2;x=1;y=2, c=(a b c)
]]></artwork>
          <t>The resulting string is used as the component value in value; see <xref target="http-fields"/>.</t>
        </section>
        <section anchor="http-field-dictionary">
          <name>Dictionary Structured Field Members</name>
          <t>If a given field is known by the application to be a Dictionary structured field, Structured Field, an individual member in the value of that Dictionary is identified by using the parameter <tt>key</tt> and the Dictionary member key as a String value.</t>
          <t>If multiple field values occur within a message, these values <bcp14>MUST</bcp14> be combined into a single Dictionary structure before serialization.</t>
          <t>An individual member value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in <xref section="4.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> on the <tt>member_value</tt> and its parameters, not including the dictionary Dictionary key itself. Specifically, the value is serialized as an Item or Inner List (the two possible values of a Dictionary member), with all parameters and possible sub-fields subfields serialized using the strict serialization rules defined in <xref section="4" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> (or the applicable section of its extensions or updates).</t>
          <t>Each parameterized key for a given field <bcp14>MUST NOT</bcp14> appear more than once in the signature base. Parameterized keys <bcp14>MAY</bcp14> appear in any order in the signature base, regardless of the order they occur in the source Dictionary.</t>
          <t>If a Dictionary key is named as a covered component but it does not occur in the Dictionary, this <bcp14>MUST</bcp14> cause an error in the signature base generation.</t>
          <t>Following
          <t>The following are non-normative examples of canonicalized values for Dictionary structured field members Structured Field members, given the following example header field, whose value is known by the application to be a Dictionary:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Dict:  a=1, b=2;x=1;y=2, c=(a   b    c), d
]]></sourcecode>
          <t>The following example shows canonicalized values for different component identifiers of this field, presented using the signature base format discussed in <xref target="create-sig-input"/>:</t>
          <artwork><![CDATA[
"example-dict";key="a": 1
"example-dict";key="d": ?1
"example-dict";key="b": 2;x=1;y=2
"example-dict";key="c": (a b c)
]]></artwork>
          <t>Note that the value for <tt>key="c"</tt> has been re-serialized reserialized according to the strict <tt>member_value</tt> algorithm, and the value for <tt>key="d"</tt> has been serialized as a Boolean value.</t>
        </section>
        <section anchor="http-field-byte-sequence">
          <name>Binary-wrapped
          <name>Binary-Wrapped HTTP Fields</name>
          <t>If the value of the HTTP field in question is known by the application to cause problems with serialization, particularly with the combination of multiple values into a single line as discussed in <xref target="security-non-list"/>, the signer <bcp14>SHOULD</bcp14> include the <tt>bs</tt> parameter in a component identifier to indicate that the values of the field need to be wrapped as binary structures before being combined.</t>
          <t>If this parameter is included with a component identifier, the component value <bcp14>MUST</bcp14> be calculated using the following algorithm:</t>
          <ol spacing="normal" type="1"><li>Let the input be the ordered set of values for a field, in the order they appear in the message.</li>
            <li>Create an empty List for accumulating processed field values.</li>
            <li>
              <t>For each field value in the set:
              </t>
              <ol spacing="normal" type="1"><li>Strip type="%p%d."><li>Strip leading and trailing whitespace from the field value. Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this will would be a no-op in a compliant implementation.</li>
                <li>Remove any obsolete line-folding line folding within the line line, and replace it with a single space (" "), as discussed in <xref section="5.2" sectionFormat="of" target="HTTP1"/>. target="RFC9112"/>. Note that this behavior is specific to <xref target="HTTP1"/> target="RFC9112"/> and does not apply to other versions of the HTTP specification.</li>
                <li>Encode the bytes of the resulting field value as a Byte Sequence. Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations.</li>
                <li>Add the Byte Sequence to the List accumulator.</li>
              </ol>
            </li>
            <li>The intermediate result is a List of Byte Sequence values.</li>
            <li>Follow the strict serialization of a List as described in <xref section="4.1.1" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/>, and return this output.</li>
          </ol>
          <t>For example, the following field with internal commas prevents the distinct field values from being safely combined:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots
Example-Header: of, commas
]]></sourcecode>
          <t>In our example, the same field can be sent with a semantically different single value:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots, of, commas
]]></sourcecode>
          <t>Both of these versions are treated differently by the application. However, if included in the signature base without parameters, the component value would be the same in both cases:</t>
          <artwork><![CDATA[
"example-header": value, with, lots, of, commas
]]></artwork>
          <t>However, if the <tt>bs</tt> parameter is added, the two separate instances are encoded and serialized as follows:</t>
          <artwork><![CDATA[
"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHM=:, :b2YsIGNvbW1hcw==:
]]></artwork>
          <t>For the single-instance field above, the encoding with the <tt>bs</tt> parameter is:</t>
          <artwork><![CDATA[
"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHMsIG9mLCBjb21tYXM=:
]]></artwork>
          <t>This component value is distinct from the multiple-instance field above, preventing a collision which that could potentially be exploited.</t>
        </section>
        <section anchor="http-trailer">
          <name>Trailer Fields</name>
          <t>If the signer wants to include a trailer field in the signature, the signer <bcp14>MUST</bcp14> include the <tt>tr</tt> boolean Boolean parameter to indicate that the value <bcp14>MUST</bcp14> be taken from the trailer fields and not from the header fields.</t>
          <t>For example, given the following message:</t>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires

4
HTTP
7
Message
a
Signatures
0
Expires: Wed, 9 Nov 2022 07:28:00 GMT
]]></sourcecode>
          <t>The signer decides to add both the Trailer header field as well as and the Expires trailer field to the signature base, along with the status code derived component:</t>
          <artwork><![CDATA[
"@status": 200
"trailer": Expires
"expires";tr: Wed, 9 Nov 2022 07:28:00 GMT
]]></artwork>
          <t>If a field is available as both a header and a trailer in a message, both values <bcp14>MAY</bcp14> be signed, but the values <bcp14>MUST</bcp14> be signed separately. The values of header fields and trailer fields of the same name <bcp14>MUST NOT</bcp14> be combined for purposes of the signature.</t>
          <t>Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per <xref section="6.5.1" sectionFormat="of" target="HTTP"/>, target="RFC9110"/>, it is <bcp14>NOT RECOMMENDED</bcp14> to include trailers in the signature unless the signer knows that the verifier will have access to the values of the trailers as sent.</t>
        </section>
      </section>
      <section anchor="derived-components">
        <name>Derived Components</name>
        <t>In addition to HTTP fields, there are a number of different components that can be derived from the control data, signature context, or other aspects of the HTTP message being signed. Such derived components can be included in the signature base by defining a component name, possible parameters, message target, targets, and the derivation method for its component value.</t>
        <t>Derived component names <bcp14>MUST</bcp14> start with the "at" <tt>@</tt> (<tt>@</tt>) character. This differentiates derived component names from HTTP field names, which cannot contain the <tt>@</tt> character as per <xref section="5.1" sectionFormat="of" target="HTTP"/>. target="RFC9110"/>. Processors of HTTP Message Signatures message signatures <bcp14>MUST</bcp14> treat derived component names separately from field names, as discussed in <xref target="security-lazy-header-parser"/>.</t>
        <t>This specification defines the following derived components:</t>
        <dl>
          <dt>@method</dt>
          <dd>
            <t>The method used for a request. request (<xref target="content-request-method"/>)</t> target="content-request-method"/>).</t>
          </dd>
          <dt>@target-uri</dt>
          <dd>
            <t>The full target URI for a request. request (<xref target="content-target-uri"/>)</t> target="content-target-uri"/>).</t>
          </dd>
          <dt>@authority</dt>
          <dd>
            <t>The authority of the target URI for a request. request (<xref target="content-request-authority"/>)</t> target="content-request-authority"/>).</t>
          </dd>
          <dt>@scheme</dt>
          <dd>
            <t>The scheme of the target URI for a request. request (<xref target="content-request-scheme"/>)</t> target="content-request-scheme"/>).</t>
          </dd>
          <dt>@request-target</dt>
          <dd>
            <t>The request target. target (<xref target="content-request-target"/>)</t> target="content-request-target"/>).</t>
          </dd>
          <dt>@path</dt>
          <dd>
            <t>The absolute path portion of the target URI for a request. request (<xref target="content-request-path"/>)</t> target="content-request-path"/>).</t>
          </dd>
          <dt>@query</dt>
          <dd>
            <t>The query portion of the target URI for a request. request (<xref target="content-request-query"/>)</t> target="content-request-query"/>).</t>
          </dd>
          <dt>@query-param</dt>
          <dd>
            <t>A parsed and encoded query parameter of the target URI for a request. request (<xref target="content-request-query-param"/>)</t> target="content-request-query-param"/>).</t>
          </dd>
          <dt>@status</dt>
          <dd>
            <t>The status code for a response. response (<xref target="content-status-code"/>)</t> target="content-status-code"/>).</t>
          </dd>
        </dl>
        <t>Additional derived component names are defined in the HTTP <xref target="content-registry">"HTTP Signature Derived Component Names Registry. (<xref target="content-registry"/>)</t> Names" registry</xref>.</t>
        <t>Derived component values are taken from the context of the target message for the signature. This context includes information about the message itself, such as its control data, as well as any additional state and context held by the signer or verifier. In particular, when signing a response, the signer can include any derived components from the originating request by using the <xref target="content-request-response">request-response target="content-request-response"><tt>req</tt> parameter</xref>.</t>
        <dl>
          <dt>request:</dt>
          <dd>
            <t>Values derived from from, and results applied to to, an HTTP request message as described in <xref section="3.4" sectionFormat="of" target="HTTP"/>. target="RFC9110"/>. If the target message of the signature is a response, derived components that target request messages can be included by using the <tt>req</tt> parameter allows a request-targeted derived component to be included as defined in the signature (see
<xref target="content-request-response"/>).</t> target="content-request-response"/>.</t>
          </dd>
          <dt>response:</dt>
          <dd>
            <t>Values derived from from, and results applied to to, an HTTP response message as described in <xref section="3.4" sectionFormat="of" target="HTTP"/>.</t> target="RFC9110"/>.</t>
          </dd>
          <dt>request, response:</dt>
          <dd>Values derived from, and results applied to, either a request message or a response message.</dd>
        </dl>
        <t>A derived component definition <bcp14>MUST</bcp14> define all target message types to which it can be applied.</t>
        <t>Derived component values <bcp14>MUST</bcp14> be limited to printable characters and spaces and <bcp14>MUST NOT</bcp14> contain any newline characters. Derived component values <bcp14>MUST NOT</bcp14> start or end with whitespace characters.</t>
        <section anchor="content-request-method">
          <name>Method</name>
          <t>The <tt>@method</tt> derived component refers to the HTTP method of a request message. The component value is canonicalized by taking the value of the method as a string. Note that the method name is case-sensitive case sensitive as per <xref section="9.1" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. While conventionally standardized method names are uppercase <xref target="ASCII"/>, target="RFC0020"/>, no transformation to the input method value's case is performed.</t>
          <t>For example, the following request message:</t>
          <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@method</tt> component value:</t>
          <artwork><![CDATA[
POST
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@method": POST
]]></artwork>
        </section>
        <section anchor="content-target-uri">
          <name>Target URI</name>
          <t>The <tt>@target-uri</tt> derived component refers to the target URI of a request message. The component value is the full absolute target URI of the request, potentially request (<xref section="7.1" sectionFormat="comma" target="RFC9110"/>), assembled from all available parts URI components, including the authority and request target as described in <xref section="7.1" sectionFormat="comma" target="HTTP"/>.</t> authority.</t>
          <t>For example, the following message sent over HTTPS:</t>
          <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@target-uri</tt> component value:</t>
          <artwork><![CDATA[
https://www.example.com/path?param=value
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@target-uri": https://www.example.com/path?param=value
]]></artwork>
        </section>
        <section anchor="content-request-authority">
          <name>Authority</name>
          <t>The <tt>@authority</tt> derived component refers to the authority component of the target URI of the HTTP request message, as defined in <xref section="7.2" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. In HTTP/1.1, this is usually conveyed using the Host header, header field, while in HTTP/2 and HTTP/3 it is conveyed using the :authority pseudo-header. The value is the fully-qualified fully qualified authority component of the request, comprised of the host and, optionally, port of the request target, as a string.
The component value <bcp14>MUST</bcp14> be normalized according to the rules provided in <xref section="4.2.3" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. Namely, the host name hostname is normalized to lowercase lowercase, and the default port is omitted.</t>
          <t>For example, the following request message:</t>
          <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@authority</tt> component value:</t>
          <artwork><![CDATA[
www.example.com
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@authority": www.example.com
]]></artwork>
          <t>The <tt>@authority</tt> derived component <bcp14>SHOULD</bcp14> be used instead of signing the Host header directly, see field directly.  See <xref target="security-not-fields"/>.</t>
        </section>
        <section anchor="content-request-scheme">
          <name>Scheme</name>
          <t>The <tt>@scheme</tt> derived component refers to the scheme of the target URL of the HTTP request message. The component value is the scheme as a lowercase string as defined in <xref section="4.2" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>.
While the scheme itself is case-insensitive, case insensitive, it <bcp14>MUST</bcp14> be normalized to lowercase for
inclusion in the signature base.</t>
          <t>For example, the following request message requested sent over plain HTTP:</t>
          <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@scheme</tt> component value:</t>
          <artwork><![CDATA[
http
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@scheme": http
]]></artwork>
        </section>
        <section anchor="content-request-target">
          <name>Request Target</name>
          <t>The <tt>@request-target</tt> derived component refers to the full request target of the HTTP request message,
as defined in <xref section="7.1" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. The component value of the request target can take different forms,
depending on the type of request, as described below.</t>
          <t>For HTTP/1.1, the component value is equivalent to the request target
portion of the request line. However, this value is more difficult to reliably construct in
other versions of HTTP. Therefore, it is <bcp14>NOT RECOMMENDED</bcp14> that this component be used
when versions of HTTP other than 1.1 might be in use.</t>
          <t>The origin form value is a combination of the absolute path and query components of the request URL. For URL.</t>
<t>For example, the following request message:</t>
          <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@request-target</tt> component value:</t>
          <artwork><![CDATA[
/path?param=value
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@request-target": /path?param=value
]]></artwork>
          <t>The following request to an HTTP proxy with the absolute-form value, containing the fully qualified target URI:</t>
          <sourcecode type="http-message"><![CDATA[
GET https://www.example.com/path?param=value HTTP/1.1
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@request-target</tt> component value:</t>
          <artwork><![CDATA[
https://www.example.com/path?param=value
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@request-target": https://www.example.com/path?param=value
]]></artwork>
          <t>The following CONNECT request with an authority-form value, containing the host and port of the target:</t>
          <sourcecode type="http-message"><![CDATA[
CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@request-target</tt> component value:</t>
          <artwork><![CDATA[
www.example.com:80
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@request-target": www.example.com:80
]]></artwork>
          <t>The following OPTIONS request message with the asterisk-form value, containing a single asterisk <tt>*</tt> (<tt>*</tt>) character:</t>
          <sourcecode type="http-message"><![CDATA[
OPTIONS * HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@request-target</tt> component value:</t>
          <artwork><![CDATA[
*
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@request-target": *
]]></artwork>
        </section>
        <section anchor="content-request-path">
          <name>Path</name>
          <t>The <tt>@path</tt> derived component refers to the target path of the HTTP request message. The component value is the absolute path of the request target defined by <xref target="URI"/>, target="RFC3986"/>, with no query component and no trailing <tt>?</tt> question mark (<tt>?</tt>) character. The value is normalized according to the rules provided in <xref section="4.2.3" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. Namely, an empty path string is normalized as a single slash <tt>/</tt> (<tt>/</tt>) character. Path components are represented by their values before decoding any percent-encoded octets, as described in the simple string comparison rules provided in <xref section="6.2.1" sectionFormat="of" target="URI"/>.</t> target="RFC3986"/>.</t>
          <t>For example, the following request message:</t>
          <sourcecode type="http-message"><![CDATA[
GET /path?param=value HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@path</tt> component value:</t>
          <artwork><![CDATA[
/path
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@path": /path
]]></artwork>
        </section>
        <section anchor="content-request-query">
          <name>Query</name>
          <t>The <tt>@query</tt> derived component refers to the query component of the HTTP request message. The component value is the entire normalized query string defined by <xref target="URI"/>, target="RFC3986"/>, including the leading <tt>?</tt> character. The value is read using the simple string comparison rules provided in <xref section="6.2.1" sectionFormat="of" target="URI"/>. target="RFC3986"/>. Namely, percent-encoded octets are not decoded.</t>
          <t>For example, the following request message:</t>
          <sourcecode type="http-message"><![CDATA[
GET /path?param=value&foo=bar&baz=bat%2Dman HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@query</tt> component value:</t>
          <artwork><![CDATA[
?param=value&foo=bar&baz=bat%2Dman
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@query": ?param=value&foo=bar&baz=bat%2Dman
]]></artwork>
          <t>The following request message:</t>
          <sourcecode type="http-message"><![CDATA[
POST /path?queryString HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@query</tt> component value:</t>
          <artwork><![CDATA[
?queryString
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@query": ?queryString
]]></artwork>
          <t>Just like including an empty path component, the signer can include an empty query component to indicate that this component is not used in the message. If the query string is absent from the request message, the component value is the leading <tt>?</tt> character alone:</t>
          <artwork><![CDATA[
?
]]></artwork>
          <t>Resulting
          <t>resulting in the following signature base line:</t>
          <artwork><![CDATA[
"@query": ?
]]></artwork>
        </section>

        <section anchor="content-request-query-param">
          <name>Query Parameters</name>
          <t>If the query portion of a request target URI uses HTML form parameters in the query string as format defined in the "application/x-www-form-urlencoded" section Section&nbsp;<xref target="HTMLURL" section="5"
relative="https://url.spec.whatwg.org/#application/x-www-form-urlencoded"
sectionFormat="bare">"application/x-www-form-urlencoded"</xref> of
<xref target="HTMLURL"/>,
the <tt>@query-param</tt> derived component allows addressing of these individual query parameters. The query parameters <bcp14>MUST</bcp14> be parsed according to the "application/x-www-form-urlencoded parsing" section
Section&nbsp;<xref target="HTMLURL" section="5.1" relative="https://url.spec.whatwg.org/#urlencoded-parsing" sectionFormat="bare">"application/x-www-form-urlencoded parsing"</xref>
of <xref target="HTMLURL"/>, resulting in a list of (<tt>nameString</tt>, <tt>valueString</tt>) tuples.
The <bcp14>REQUIRED</bcp14> <tt>name</tt> parameter of each component identifier contains the encoded <tt>nameString</tt> of a single query parameter as a String value.
The component value of a single named parameter is the encoded <tt>valueString</tt> of that single query parameter.
Several different named query parameters <bcp14>MAY</bcp14> be included in the covered components.
Single named parameters <bcp14>MAY</bcp14> occur in any order in the covered components, regardless of the order they occur in the query string.</t>
          <t>The value of the <tt>name</tt> parameter and the component value of a single named parameter are calculated by via the following process:</t>
          <ol spacing="normal" type="1"><li>Parse the <tt>nameString</tt> or <tt>valueString</tt> of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section
Section&nbsp;<xref target="HTMLURL" section="5.1" relative="https://url.spec.whatwg.org/#urlencoded-parsing" sectionFormat="bare">"application/x-www-form-urlencoded parsing"</xref>
of <xref target="HTMLURL"/>, which target="HTMLURL"/>; this is the value after percent-encoded octets are decoded.</li>
            <li>Encode the <tt>nameString</tt> or <tt>valueString</tt> using the "percent-encode after encoding" process defined by the "application/x-www-form-urlencoded serializing" section
Section&nbsp;<xref target="HTMLURL" section="5.2" relative="https://url.spec.whatwg.org/#urlencoded-serializing" sectionFormat="bare">"application/x-www-form-urlencoded serializing"</xref> of <xref target="HTMLURL"/>, which target="HTMLURL"/>; this results in an ASCII string <xref target="ASCII"/> string.</li> target="RFC0020"/>.</li>
            <li>Output the ASCII string,</li> string.</li>
          </ol>
          <t>Note that the component value does not include any leading <tt>?</tt> question mark (<tt>?</tt>) characters, equals sign <tt>=</tt>, (<tt>=</tt>) characters, or separating <tt>&amp;</tt> ampersand (<tt>&amp;</tt>) characters.
Named query parameters with an empty <tt>valueString</tt> have an empty string as the component value. Note that due to inconsistencies in implementations, some query parameter parsing libraries drop such empty values.</t>
          <t>If a query parameter is named as a covered component but it does not occur in the query parameters, this <bcp14>MUST</bcp14> cause an error in the signature base generation.</t>
          <t>For example example, for the following request:</t>
          <sourcecode type="http-message"><![CDATA[
GET /path?param=value&foo=bar&baz=batman&qux= HTTP/1.1
Host: www.example.com
]]></sourcecode>
          <t>Indicating the <tt>baz</tt>, <tt>qux</tt> <tt>qux</tt>, and <tt>param</tt> named query parameters would result in the following <tt>@query-param</tt> component values:</t>
          <t><em>baz</em>: <tt>batman</tt></t>
          <t><em>qux</em>: an empty string</t>
          <t><em>param</em>: <tt>value</tt></t>
          <t>And
          <t>and the following signature base lines, with (SP) indicating a single trailing space character before the empty component value:</t>
          <artwork><![CDATA[
"@query-param";name="baz": batman
"@query-param";name="qux":(SP)
"@query-param";name="param": value
]]></artwork>
          <t>This derived component has some limitations. Specifically, the algorithm algorithms provided in Section&nbsp;<xref target="HTMLURL" section="5"
relative="https://url.spec.whatwg.org/#application/x-www-form-urlencoded"
sectionFormat="bare">"application/x-www-form-urlencoded"</xref> of
<xref target="HTMLURL"/> only supports support query parameters using percent-escaped UTF-8 encoding. Other encodings are not supported.
Additionally, multiple instances of a named parameter are not reliably supported in the wild. If a parameter name occurs multiple times in a request, the named query parameter <bcp14>MUST NOT</bcp14> be included. If multiple parameters are common within an application, it is <bcp14>RECOMMENDED</bcp14> to sign the entire query string using the <tt>@query</tt> component identifier defined in <xref target="content-request-query"/>.</t>
          <t>The encoding process allows query parameters that include newlines or other problematic characters in their values, or with alternative encodings such as using the plus (+) character to represent spaces. For the query parameters in this message:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

GET /parameters?var=this%20is%20a%20big%0Amultiline%20value&\
  bar=with+plus+whitespace&fa%C3%A7ade%22%3A%20=something HTTP/1.1
Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT
]]></sourcecode>
          <t>The resulting values are encoded as follows:</t>
          <artwork><![CDATA[
"@query-param";name="var": this%20is%20a%20big%0Amultiline%20value
"@query-param";name="bar": with%20plus%20whitespace
"@query-param";name="fa%C3%A7ade%22%3A%20": something
]]></artwork>
          <t>If the encoding were not applied, the resultant values would be:</t>
          <artwork><![CDATA[
"@query-param";name="var": this is a big
multiline value
"@query-param";name="bar": with plus whitespace
"@query-param";name="façade\": ": something
]]></artwork>
          <t>This base string contains characters that violate the constraints on component names and values, values and is therefore invalid.</t>
        </section>
        <section anchor="content-status-code">
          <name>Status Code</name>
          <t>The <tt>@status</tt> derived component refers to the three-digit numeric HTTP status code of a response message as defined in <xref section="15" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. The component value is the serialized three-digit integer of the HTTP status code, with no descriptive text.</t>
          <t>For example, the following response message:</t>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
]]></sourcecode>
          <t>Would
          <t>would result in the following <tt>@status</tt> component value:</t>
          <artwork><![CDATA[
200
]]></artwork>
          <t>And
          <t>and the following signature base line:</t>
          <artwork><![CDATA[
"@status": 200
]]></artwork>
          <t>The <tt>@status</tt> component identifier <bcp14>MUST NOT</bcp14> be used in a request message.</t>
        </section>
      </section>
      <section anchor="signature-params">
        <name>Signature Parameters</name>
        <t>HTTP Message Signatures message signatures have metadata properties that provide information regarding the signature's generation and verification, consisting of the ordered set of covered components and the ordered set of parameters, where the parameters including include a timestamp of signature creation, identifiers for verification key material, and other utilities. This metadata is represented by a special message component in the signature base for signature parameters, and it parameters; this special message component is treated slightly differently from other message components. Specifically, the signature parameters message component is <bcp14>REQUIRED</bcp14> as the last line of the <xref target="create-sig-input">signature base</xref>, and the component identifier <bcp14>MUST NOT</bcp14> be enumerated within the set of covered components for any signature, including itself.</t>
        <t>The signature parameters component name is <tt>@signature-params</tt>.</t>
        <t>The signature parameters component value is the serialization of the signature parameters for this signature, including the covered components ordered set with all associated parameters. These parameters include any of the following:</t>
        <ul
        <dl spacing="normal">
          <li>
          <dt>
            <tt>created</tt>: Creation
	  </dt><dd>Creation time as an Integer a UNIX timestamp value. value of type Integer. Sub-second precision is not supported. Inclusion The inclusion of this parameter is <bcp14>RECOMMENDED</bcp14>.</li>
          <li> <bcp14>RECOMMENDED</bcp14>.</dd>
          <dt>
            <tt>expires</tt>: Expiration
	  </dt><dd>Expiration time as an Integer a UNIX timestamp value. value of type Integer. Sub-second precision is not supported.</li>
          <li> supported.</dd>
          <dt>
            <tt>nonce</tt>: A
	  </dt><dd>A random unique value generated for this signature as a String value.</li>
          <li> value.</dd>
          <dt>
            <tt>alg</tt>: The
	  </dt><dd>The HTTP message signature algorithm from the HTTP "HTTP Signature Algorithms Algorithms" registry, as a String value.</li>
          <li> value.</dd>
          <dt>
            <tt>keyid</tt>: The
	  </dt><dd>The identifier for the key material as a String value.</li>
          <li> value.</dd>
          <dt>
            <tt>tag</tt>: An
	  </dt><dd>An application-specific tag for the signature as a String value. This value is used by applications to help identify signatures relevant for specific applications or protocols.</li>
        </ul> protocols.</dd>
	</dl>
        <t>Additional parameters can be defined in the <xref target="param-registry">HTTP target="param-registry">"HTTP Signature Metadata Parameters Registry</xref>. Parameters" registry</xref>. Note that there is no general ordering to the parameters, parameters are not in any general order, but once an ordering is chosen for a given set of parameters, it cannot be changed without altering the signature parameters value.</t>
        <t>The signature parameters component value is serialized as a parameterized Inner List using the rules provided in <xref section="4" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> as follows:</t>
        <ol spacing="normal" type="1"><li>Let the output be an empty string.</li>
          <li>Determine an order for the component identifiers of the covered components, not including the <tt>@signature-params</tt> component identifier itself. Once this order is chosen, it cannot be changed. This order <bcp14>MUST</bcp14> be the same order as that used in creating the signature base
(<xref target="create-sig-input"/>).</li>
          <li>Serialize the component identifiers of the covered components, including all parameters, as an ordered Inner List of String values according to <xref section="4.1.1.1" sectionFormat="of" target="STRUCTURED-FIELDS"/> and target="RFC8941"/>; then, append this to the output. Note that the component identifiers can include their own parameters, and these parameters are ordered sets. Once an order is chosen for a component's parameters, the order cannot be changed.</li>
          <li>Determine an order for any signature parameters. Once this order is chosen, it cannot be changed.</li>
          <li>Append the parameters to the Inner List in order according to <xref section="4.1.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>, target="RFC8941"/>,
 skipping parameters that are not available or not used for this message signature.</li>
          <li>The output contains the signature parameters component value.</li>
        </ol>
        <t>Note that the Inner List serialization from <xref section="4.1.1.1" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> is used for the covered component value instead of the List serialization from <xref section="4.1.1" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/>
in order to facilitate parallelism with this value's inclusion in the Signature-Input field,
as discussed in <xref target="signature-input-header"/>.</t>
        <t>This example shows the serialized component value for the parameters of an example message signature:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

("@target-uri" "@authority" "date" "cache-control")\
  ;keyid="test-key-rsa-pss";alg="rsa-pss-sha512";\
  created=1618884475;expires=1618884775
]]></artwork>
        <t>Note that an HTTP message could contain <xref target="signature-multiple">multiple signatures</xref>, but only the signature parameters used for a single signature are included in a given signature parameters entry.</t>
      </section>
      <section anchor="content-request-response">
        <name>Signing Request Components in a Response Message</name>
        <t>When a request message results in a signed response message, the signer can include portions of the request message in the signature base by adding the <tt>req</tt> parameter to the component identifier.</t>
        <dl>
          <dt><tt>req</tt></dt>
          <dd>
            <t>A boolean Boolean flag indicating that the component value is derived from the request that triggered this response message and not from the response message directly.</t>
          </dd>
        </dl>
        <t>This parameter can be applied to both HTTP fields and derived components that target the request, with the same semantics. The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message instead of the target response message to which the signature is applied.</t>
        <t>Note that the same component name <bcp14>MAY</bcp14> be included with and without the <tt>req</tt> parameter in a single signature base, indicating the same named component from both the request message and the response message, respectively.</t> message.</t>
        <t>The <tt>req</tt> parameter <bcp14>MAY</bcp14> be combined with other parameters as appropriate for the component identifier, such as the <tt>key</tt> parameter for a dictionary Dictionary field.</t>
        <t>For example, when serving a response for this request:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18

{"hello": "world"}
]]></sourcecode>
        <t>This would result in the following unsigned response message:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:

{"busy": true, "message": "Your call is very important to us"}
]]></sourcecode>
        <t>The server signs the response with its own key, including the <tt>@status</tt> code and several header fields in the covered components. While this covers a reasonable amount of the response for this application, the server additionally includes several components derived from the original request message that triggered this response. In this example, the server includes the method, authority, path, and content digest from the request in the covered components of the response. The Content-Digest for both the request and the response are is included under the response signature. For the application in this example, the query is deemed not to be relevant to the response and is therefore not covered. Other applications would make different decisions based on application needs needs, as discussed in <xref target="application"/>.</t>
        <t>The signature base for this example is:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
]]></artwork>
        <t>The signed response message is:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU\
  4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==:

{"busy": true, "message": "Your call is very important to us"}
]]></sourcecode>
        <t>Note that the ECDSA signature algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
        <t>Since the component values from the request are not repeated in the response message, the requester <bcp14>MUST</bcp14> keep the original message component values around long enough to validate the signature of the response that uses this component identifier parameter. 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 values, as the client would not be able to validate the resulting signature.</t>
        <t>It is additionally also possible for a server to create a signed response in response to a signed request.  For example, this example of a signed request:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" "@query" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK\
  t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr\
  d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4\
  2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw\
  5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr\
  0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==:

{"hello": "world"}
]]></artwork>
        <t>The server could choose to sign portions of this response, including several portions of the request request, resulting in this signature base:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"@query";req: ?param=Value&Pet=dog
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type";req: application/json
"content-length";req: 18
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
]]></artwork>
        <t>And
        <t>and the following signed response:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym\
  dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==:

{"busy": true, "message": "Your call is very important to us"}
]]></sourcecode>
        <t>Note that the ECDSA signature algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
        <t>Applications signing a response to a signed request <bcp14>SHOULD</bcp14> sign all of the components of the request signature value to provide sufficient coverage and protection against a class of collision attacks, as discussed in <xref target="security-sign-signature"/>. The server in this example has included all components listed in the Signature-Input field of the client's signature on the request in the response signature, in addition to components of the response.</t>
        <t>While it is syntactically possible to include the Signature and Signature-Input fields of the request message in the signature components of a response to a message using this mechanism, this practice is <bcp14>NOT RECOMMENDED</bcp14>. This is because signatures of signatures do not provide transitive coverage of covered components as one might expect expect, and the practice is susceptible to several attacks as discussed in <xref target="security-sign-signature"/>. An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely.</t>
        <t>The response signature can only ever cover what is included in the request message when using this flag. Consequently, if an application needs to include the message content of the request under the signature of its response, the client needs to include a means for covering that content, such as a Content-Digest field. See the discussion in <xref target="security-message-content"/> for more information.</t>
        <t>The <tt>req</tt> parameter <bcp14>MUST NOT</bcp14> be used for any component in a signature that targets a request message.</t>
      </section>
      <section anchor="create-sig-input">
        <name>Creating the Signature Base</name>
        <t>The signature base is a <xref target="ASCII"/> an ASCII string <xref target="RFC0020"/> containing the canonicalized HTTP message components covered by the signature. The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in <xref target="signature-params"/>.</t>
        <t>Component identifiers are serialized using the strict serialization rules defined by <xref section="4" sectionFormat="comma" target="STRUCTURED-FIELDS"/>. target="RFC8941"/>.
The component identifier has a component name, which is a String Item value serialized using the <tt>sf-string</tt> ABNF rule. The component identifier <bcp14>MAY</bcp14> also include defined parameters which that are serialized using the <tt>parameters</tt> ABNF rule. The signature parameters line defined in <xref target="signature-params"/> follows this same pattern, but the component identifier is a String Item with a fixed value and no parameters, and the component value is always an Inner List with optional parameters.</t>
        <t>Note that this means the serialization of the component name itself is encased in double quotes, with parameters following as a semicolon-separated list, such as <tt>"cache-control"</tt>, <tt>"@authority"</tt>, <tt>"@signature-params"</tt>, or <tt>"example-dictionary";key="foo"</tt>.</t>
        <t>The output is the ordered set of bytes that form the signature base, which conforms to the following ABNF:</t>
        <sourcecode type="abnf"><![CDATA[
signature-base = *( signature-base-line LF ) signature-params-line
signature-base-line = component-identifier ":" SP
    ( derived-component-value / *field-content )
    ; no obs-fold nor obs-text
component-identifier = component-name parameters
component-name = sf-string
derived-component-value = *( VCHAR / SP )
signature-params-line = DQUOTE "@signature-params" DQUOTE
     ":" SP inner-list
]]></sourcecode>
        <t>To create the signature base, the signer or verifier concatenates together entries for each component identifier in the signature's covered components (including their parameters) using the following algorithm. All errors produced as described immediately <bcp14>MUST</bcp14> fail the algorithm with no immediately, without outputting a signature output base output.</t> base.</t>
        <ol spacing="normal" type="1"><li>Let the output be an empty string.</li>
          <li>
            <t>For each message component item in the covered components set (in order):  </t>
            <ol spacing="normal" type="1"><li>If type="%p%d."><li>If the component identifier (including its parameters) has already been added to the signature base, produce an error.</li>
              <li>Append the component identifier for the covered component serialized according to the <tt>component-identifier</tt> ABNF rule. Note that this serialization places the component name in double quotes and appends any parameters outside of the quotes.</li>
              <li>Append a single colon <tt>:</tt></li> (<tt>:</tt>).</li>
              <li>Append a single space " "</li> (" ").</li>
              <li>
                <t>Determine the component value for the component identifier.      </t>
                <ul spacing="normal">
                  <li>If the component identifier has a parameter that is not understood, produce an error.</li>
                  <li>If the component identifier has parameters that are mutually incompatible with one another, such as <tt>bs</tt> and <tt>sf</tt>, produce an error.</li>
                  <li>If the component identifier contains the <tt>req</tt> parameter and the target message is a request, produce an error.</li>
                  <li>If the component identifier contains the <tt>req</tt> parameter and the target message is a response, the context for the component value is the related request message of the target response message. Otherwise, the context for the component value is the target message.</li>
                  <li>If the component name starts with an "at" character (<tt>@</tt>), (<tt>@</tt>) character, derive the component's value from the message according to the specific rules defined for the derived component, as provided in <xref target="derived-components"/>, including processing of any known valid parameters. If the derived component name is unknown or the value cannot be derived, produce an error.</li>
                  <li>If the component name does not start with an "at" character (<tt>@</tt>), (<tt>@</tt>) character, canonicalize the HTTP field value as described in <xref target="http-fields"/>, including processing of any known valid parameters. If the field cannot be found in the message, message or the value cannot be obtained in the context, produce an error.</li>
                </ul>
              </li>
              <li>Append the covered component's canonicalized component value.</li>
              <li>Append a single newline <tt>\n</tt></li> (<tt>\n</tt>).</li>
            </ol>
          </li>
          <li>
            <t>Append the signature parameters component (<xref target="signature-params"/>) according to the <tt>signature-params-line</tt> rule as follows:  </t>
            <ol spacing="normal" type="1"><li>Append type="%p%d."><li>Append the component identifier for the signature parameters serialized according to the <tt>component-identifier</tt> rule, i.e. i.e., the exact value <tt>"@signature-params"</tt> (including double quotes)</li> quotes).</li>
              <li>Append a single colon <tt>:</tt></li> (<tt>:</tt>).</li>
              <li>Append a single space " "</li> (" ").</li>
              <li>Append the signature parameters' canonicalized component value values as defined in <xref target="signature-params"/>, i.e. an i.e., Inner List structured field value Structured Field values with parameters</li> parameters.</li>
            </ol>
          </li>
          <li>Produce an error if the output string contains any non-ASCII (<xref target="ASCII"/>) characters.</li> characters <xref target="RFC0020"/>.</li>
          <li>Return the output string.</li>
        </ol>
        <t>If covered components reference a component identifier that cannot be resolved to a component value in the message, the implementation <bcp14>MUST</bcp14> produce an error and not create a signature base. Such situations include, but are not limited to:</t> to, the following:</t>
        <ul spacing="normal">
          <li>The signer or verifier does not understand the derived component name.</li>
          <li>The component name identifies a field that is not present in the message or whose value is malformed.</li>
          <li>The component identifier includes a parameter that is unknown or does not apply to the component identifier to which it is attached.</li>
          <li>The component identifier indicates that a structured field Structured Field serialization is used (via the <tt>sf</tt> parameter), but the field in question is known to not be a structured field Structured Field or the type of structured field Structured Field is not known to the implementation.</li>
          <li>The component identifier is a dictionary Dictionary member identifier that references a field that is not present in the message, that is not a Dictionary Structured Field, or whose value is malformed.</li>
          <li>The component identifier is a dictionary Dictionary member identifier or a named query parameter identifier that references a member that is not present in the component value, value or whose value is malformed. E.g., For example, the identifier is <tt>"example-dict";key="c"</tt> <tt>"example-dict";key="c"</tt>, and the value of the Example-Dict header field is <tt>a=1, b=2</tt>, which does not have the <tt>c</tt> value.</li>
        </ul>
        <t>In the following non-normative example, the HTTP message being signed is the following request:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}
]]></sourcecode>
        <t>The covered components consist of the <tt>@method</tt>, <tt>@authority</tt>, and <tt>@path</tt> derived components followed by the <tt>Content-Digest</tt>, <tt>Content-Length</tt>, and <tt>Content-Type</tt> HTTP header fields, in order. The signature parameters consist of a creation timestamp of <tt>1618884473</tt> and a key identifier of <tt>test-key-rsa-pss</tt>. Note that no explicit <tt>alg</tt> parameter is given here here, since the verifier is known by the application to use the RSA PSS RSA-PSS algorithm based on the identified key. The signature base for this message with these parameters is:</t>
        <figure anchor="example-sig-input">
          <name>Non-normative example Example Signature Base</name>
          <sourcecode type="http-message" name="example-sig-input"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@method": POST
"@authority": example.com
"@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
  +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-length": 18
"content-type": application/json
"@signature-params": ("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884473;keyid="test-key-rsa-pss"
]]></sourcecode>
        </figure>
        <t>Note that the example signature base here, or anywhere else within this specification, above does not include the final newline that ends the displayed example.</t> example, nor do other example signature bases displayed elsewhere in this specification.</t>
      </section>
    </section>
    <section anchor="message-signatures">
      <name>HTTP Message Signatures</name>
      <t>An HTTP Message Signature message signature is a signature over a string generated from a subset of the components of an HTTP message in addition to metadata about the signature itself. When successfully verified against an HTTP message, an HTTP Message Signature message signature provides cryptographic proof that the message is semantically equivalent to the message for which the signature was generated, with respect to the subset of message components that was signed.</t>
      <section anchor="sign">
        <name>Creating a Signature</name>
        <t>Creation of an HTTP message signature is a process that takes as its input the signature context (including the target message) and the requirements for the application. The output is a signature value and set of signature parameters that can be communicated to the verifier by adding them to the message.</t>
        <t>In order to create a signature, a signer <bcp14>MUST</bcp14> follow apply the following algorithm:</t>
        <ol spacing="normal" type="1"><li>The signer chooses an HTTP signature algorithm and key material for signing from the set of potential signing algorithms.
 The set of potential algorithms is determined by the application and is out of scope for this document.
 The signer <bcp14>MUST</bcp14> choose key material that is appropriate
 for the signature's algorithm, algorithm and that conforms to any requirements defined by the algorithm, such as key size or format. The
 mechanism by which the signer chooses the algorithm and key material is out of scope for this document.</li>
          <li>The signer sets the signature's creation time to the current time.</li>
          <li>If applicable, the signer sets the signature's expiration time property to the time at which the signature is to expire. The expiration is a hint to the verifier, expressing the time at which the signer is no longer willing to vouch for the signature. An appropriate expiration length, and the processing requirements of this parameter, are application-specific.</li> application specific.</li>
          <li>
            <t>The signer creates an ordered set of component identifiers representing the message components to be covered by the signature, signature and attaches signature metadata parameters to this set. The serialized value of this set is later used as the value of the Signature-Input field as described in <xref target="signature-input-header"/>.
            </t> target="signature-input-header"/>.</t>
            <ul spacing="normal">
              <li>Once an order of covered components is chosen, the order <bcp14>MUST NOT</bcp14> change for the life of the signature.</li>
              <li>Each covered component identifier <bcp14>MUST</bcp14> be either an
(1)&nbsp;an HTTP field (<xref target="http-fields"/>) in the signature context <xref target="http-fields"/> or a
(2)&nbsp;a derived component listed in <xref target="derived-components"/> or in the HTTP "HTTP Signature Derived Component Names Names" registry.</li>
              <li>Signers of a request <bcp14>SHOULD</bcp14> include some or all of the message control data in the covered components, such as the <tt>@method</tt>, <tt>@authority</tt>, <tt>@target-uri</tt>, or some combination thereof.</li>
              <li>Signers <bcp14>SHOULD</bcp14> include the <tt>created</tt> signature metadata parameter to indicate when the signature was created.</li>
              <li>The <tt>@signature-params</tt> derived component identifier <bcp14>MUST NOT</bcp14> be listed present in the list of covered component identifiers. The derived component is required to always be the last line in the signature base, ensuring that a signature always covers its own metadata and the metadata cannot be substituted.</li>
              <li>Further guidance on what to include in this set and in what order is out of scope for this document.</li>
            </ul>
          </li>
          <li>The signer creates the signature base using these parameters and the signature base creation algorithm. algorithm (<xref target="create-sig-input"/>)</li> target="create-sig-input"/>).</li>
          <li>The signer uses the <tt>HTTP_SIGN</tt> primitive function to sign the signature base with the chosen signing algorithm using the key material chosen by the signer. The <tt>HTTP_SIGN</tt> primitive and several concrete applications of signing algorithms are defined in <xref target="signature-methods"/>.</li>
          <li>The byte array output of the signature function is the HTTP message signature output value to be included in the Signature field as defined in <xref target="signature-header"/>.</li>
        </ol>
        <t>For example, given the HTTP message and signature parameters in the example in <xref target="create-sig-input"/>, the example signature base is signed with the <tt>test-key-rsa-pss</tt> key in (see <xref target="example-key-rsa-pss-test"/> target="example-key-rsa-pss-test"/>) and the RSA PSS RSASSA-PSS algorithm described in <xref target="method-rsa-pss-sha512"/>, giving the following message signature output value, encoded in Base64:</t>
        <figure anchor="example-sig-value">
          <name>Non-normative example signature value</name> Example Signature Value</name>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrlFrCGUDih47vAxi4L2\
YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxHLMCy8uqK488o+9jrptQ\
+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSfSvzPuBCh+ARHBmWuNo1Uz\
VVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y9TP5FsZYzHvDqbInkTNigBc\
E9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7aXq6Am6sfOrpIC49yXjj3ae6H\
RalVc/g==
]]></artwork>
        </figure>
        <t>Note that the RSA PSS RSA-PSS algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
      </section>
      <section anchor="verify">
        <name>Verifying a Signature</name>
        <t>Verification of an HTTP message signature is a process that takes as its input the signature context (including the target message, particularly its Signature and Signature-Input fields) and the requirements for the application. The output of the verification is either a positive verification or an error.</t>
        <t>In order to verify a signature, a verifier <bcp14>MUST</bcp14> follow apply the following algorithm:</t>
        <ol spacing="normal" type="1"><li>
            <t>Parse the Signature and Signature-Input fields as described in <xref target="signature-input-header"/>
Sections&nbsp;<xref target="signature-input-header" format="counter"/> and <xref target="signature-header"/>, target="signature-header" format="counter"/>, and extract the signatures to be verified. verified and their labels.
            </t>
            <ol spacing="normal" type="1"><li>If type="%p%d."><li>If there is more than one signature value present, determine which signature should be processed
 for this message based on the policy and configuration of the verifier. If an applicable signature is not found, produce an error.</li>
              <li>If the chosen Signature field value does not have a corresponding Signature-Input value, field value (i.e., one with the same label),
 produce an error.</li>
            </ol>
          </li>
          <li>Parse the values of the chosen Signature-Input field as a parameterized Inner List to get the ordered list of covered components and the signature parameters for the signature to be verified.</li>
          <li>Parse the value of the corresponding Signature field to get the byte array value of the signature
 to be verified.</li>
          <li>Examine the signature parameters to confirm that the signature meets the requirements described
 in this document, as well as any additional requirements defined by the application such as which
 message components are required to be covered by the signature. signature (<xref target="verify-requirements"/>)</li> target="verify-requirements"/>).</li>
          <li>Determine the verification key material for this signature. If the key material is known through external
 means such as static configuration or external protocol negotiation, the verifier will use that. the applicable technique to obtain the key material from this external knowledge. If the key is
 identified in the signature parameters, the verifier will dereference this the key identifier to appropriate key material to use
 with the signature. The verifier has to determine the trustworthiness of the key material for the context
 in which the signature is presented. If a key is identified that the verifier does not know, does
 not know or trust for this request, request or that does not match something preconfigured, the verification <bcp14>MUST</bcp14> fail.</li>
          <li>
            <t>Determine the algorithm to apply for verification:
            </t>
            <ol spacing="normal" type="1"><li>Start type="%p%d."><li>Start with the set of allowable algorithms known to the application. If any of the following steps selects select an algorithm that is not in this set, the signature validation fails.</li>
              <li>If the algorithm is known through external means such as static configuration or external protocol
 negotiation, the verifier will use this that algorithm.</li>
              <li>If the algorithm can be determined from the keying material, such as through an algorithm field
 on the key value itself, the verifier will use this that algorithm.</li>
              <li>If the algorithm is explicitly stated in the signature parameters using a value from the
 HTTP
 "HTTP Signature Algorithms Algorithms" registry, the verifier will use the referenced algorithm.</li>
              <li>If the algorithm is specified in more than one location, such as through location (e.g.,
a combination of static configuration
 and configuration, the algorithm signature parameter, or the algorithm signature parameter and from the
key material itself, itself), the resolved algorithms <bcp14>MUST</bcp14> be the same. If the algorithms are
 not the same, the verifier <bcp14>MUST</bcp14> fail the verification.</li>
            </ol>
          </li>
          <li>Use the received HTTP message and the parsed signature parameters to re-create recreate the signature base, using
 the algorithm defined in <xref target="create-sig-input"/>. The value of the <tt>@signature-params</tt> input is
 the value of the Signature-Input field for this signature serialized according to the rules described
 in <xref target="signature-params"/>. Note that this does not include the signature's label from the Signature-Input field.</li>
          <li>If the key material is appropriate for the algorithm, apply the appropriate <tt>HTTP_VERIFY</tt> cryptographic verification algorithm to the signature,
 recalculated signature base, key material, and signature value. The <tt>HTTP_VERIFY</tt> primitive and several concrete algorithms are defined in
 <xref target="signature-methods"/>.</li>
          <li>The results of the verification algorithm function are the final results of the cryptographic verification function.</li>
        </ol>
        <t>If any of the above steps fail or produce an error, the signature validation fails.</t>
        <t>For example, verifying the signature with the key label <tt>sig1</tt> of the following message with the <tt>test-key-rsa-pss</tt> key in (see <xref target="example-key-rsa-pss-test"/> target="example-key-rsa-pss-test"/>) and the RSA PSS RSASSA-PSS algorithm described in <xref target="method-rsa-pss-sha512"/>:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig1=:HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrl\
  FrCGUDih47vAxi4L2YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxH\
  LMCy8uqK488o+9jrptQ+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSf\
  SvzPuBCh+ARHBmWuNo1UzVVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y\
  9TP5FsZYzHvDqbInkTNigBcE9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7\
  aXq6Am6sfOrpIC49yXjj3ae6HRalVc/g==:

{"hello": "world"}
]]></sourcecode>
        <t>With the additional requirements that at least the method, authority, path, content-digest, content-length, and content-type entries be signed, and that the signature creation timestamp is be recent enough at the time of verification, the verification passes.</t>
        <section anchor="verify-requirements">
          <name>Enforcing Application Requirements</name>
          <t>The verification requirements specified in this document are intended as a baseline set of restrictions that are generally applicable to all use cases. Applications using HTTP Message Signatures message signatures <bcp14>MAY</bcp14> impose requirements above and beyond those specified by this document, as appropriate for their use case.</t>
          <t>Some non-normative examples of additional requirements an application might define are:</t>
          <ul spacing="normal">
            <li>Requiring a specific set of header fields to be signed (e.g., Authorization, Digest).</li> Content-Digest).</li>
            <li>Enforcing a maximum signature age from the time of the <tt>created</tt> time stamp.</li>
            <li>Rejection of timestamp.</li>
            <li>Rejecting signatures past the expiration time in the <tt>expires</tt> time stamp. timestamp. Note that the expiration time is a hint from the signer and that a verifier can always reject a signature ahead of its expiration time.</li>
            <li>Prohibition of
            <li>Prohibiting certain signature metadata parameters, such as runtime algorithm signaling with the <tt>alg</tt> parameter when the algorithm is determined from the key information.</li>
            <li>Ensuring successful dereferencing of the <tt>keyid</tt> parameter to valid and appropriate key material.</li>
            <li>Prohibiting the use of certain algorithms, algorithms or mandating the use of a specific algorithm.</li>
            <li>Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 bits).</li>
            <li>Enforcing uniqueness of the <tt>nonce</tt> parameter.</li>
            <li>Requiring an application-specific value for the <tt>tag</tt> parameter.</li>
          </ul>
          <t>Application-specific requirements are expected and encouraged. When an application defines additional requirements, it <bcp14>MUST</bcp14> enforce them during the signature verification process, and signature verification <bcp14>MUST</bcp14> fail if the signature does not conform to the application's requirements.</t>
          <t>Applications <bcp14>MUST</bcp14> enforce the requirements defined in this document. Regardless of use case, applications <bcp14>MUST NOT</bcp14> accept signatures that do not conform to these requirements.</t>
        </section>
      </section>
      <section anchor="signature-methods">
        <name>Signature Algorithms</name>
        <t>An HTTP Message message signature <bcp14>MUST</bcp14> use a cryptographic digital signature or MAC method that is
appropriate for the key material, environment, and needs of the signer and verifier. This specification does not strictly limit the available signature algorithms, and any signature algorithm that meets these basic requirements <bcp14>MAY</bcp14> be used by an application of HTTP message signatures.</t>
        <t>Each
        <t>For each signing method method, <tt>HTTP_SIGN</tt> takes as its input the signature base defined in <xref target="create-sig-input"/> as a byte array (<tt>M</tt>), (<tt>M</tt>) and the signing key material
(<tt>Ks</tt>), and outputs the resultant signature output as a byte array (<tt>S</tt>):</t>
        <artwork><![CDATA[
HTTP_SIGN (M, Ks)  ->  S
]]></artwork>
        <t>Each
        <t>For each verification method method, <tt>HTTP_VERIFY</tt> takes as its input the re-generated regenerated signature base defined in <xref target="create-sig-input"/> as a byte array (<tt>M</tt>), the verification key
material (<tt>Kv</tt>), and the presented signature to be verified as a byte array (<tt>S</tt>) (<tt>S</tt>), and outputs the verification result (<tt>V</tt>) as a boolean:</t> Boolean:</t>
        <artwork><![CDATA[
HTTP_VERIFY (M, Kv, S) -> V
]]></artwork>
        <t>The following sections contain several common signature algorithms and demonstrate how these cryptographic primitives map to the <tt>HTTP_SIGN</tt> and <tt>HTTP_VERIFY</tt> definitions here. above. Which method to use can be communicated through the explicit algorithm (<tt>alg</tt>) signature parameter <tt>alg</tt>
defined in <xref target="signature-params"/>, (<xref target="signature-params"/>), by reference to the key material, or through mutual agreement between the signer and verifier. Signature algorithms selected using the <tt>alg</tt> parameter <bcp14>MUST</bcp14> use values from the <xref target="hsa-registry">HTTP target="hsa-registry">"HTTP Signature Algorithms Algorithms" registry</xref>.</t>
        <section anchor="method-rsa-pss-sha512">
          <name>RSASSA-PSS using Using SHA-512</name>
          <t>To sign using this algorithm, the signer applies the <tt>RSASSA-PSS-SIGN (K, M)</tt> function defined in <xref target="RFC8017"/> with the signer's private signing key (<tt>K</tt>) and the signature base (<tt>M</tt>)
(<xref target="create-sig-input"/>).
The mask generation function is <tt>MGF1</tt> as specified in <xref target="RFC8017"/> with a hash function of SHA-512 <xref target="RFC6234"/>.
The salt length (<tt>sLen</tt>) is 64 bytes.
The hash function (<tt>Hash</tt>) SHA-512 <xref target="RFC6234"/> is applied to the signature base to create
the digest content to which the digital signature is applied.
The resulting signed content byte array (<tt>S</tt>) is the HTTP message signature output used in <xref target="sign"/>.</t>
          <t>To verify using this algorithm, the verifier applies the <tt>RSASSA-PSS-VERIFY ((n, e), M, S)</tt> function <xref target="RFC8017"/> using the public key portion of the verification key material (<tt>(n, e)</tt>) (<tt>n, e</tt>) and the signature base (<tt>M</tt>) re-created recreated as described in <xref target="verify"/>.
The mask generation function is <tt>MGF1</tt> as specified in <xref target="RFC8017"/> with a hash function of SHA-512 <xref target="RFC6234"/>.
The salt length (<tt>sLen</tt>) is 64 bytes.
The hash function (<tt>Hash</tt>) SHA-512 <xref target="RFC6234"/> is applied to the signature base to create the digest content to which the verification function is applied.
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as described in <xref target="verify"/>.
The results of the verification function indicate if whether the signature presented is valid.</t>
          <t>Note that the output of RSA PSS algorithms are non-deterministic, and therefore the RSASSA-PSS algorithm is non-deterministic; therefore, it is not correct to re-calculate recalculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See <xref target="security-nondeterministic"/>.</t>
          <t>Use
          <t>The use of this algorithm can be indicated at runtime using the <tt>rsa-pss-sha512</tt> value for the <tt>alg</tt> signature parameter.</t>
        </section>
        <section anchor="method-rsa-v1_5-sha256">
          <name>RSASSA-PKCS1-v1_5 using Using SHA-256</name>
          <t>To sign using this algorithm, the signer applies the <tt>RSASSA-PKCS1-V1_5-SIGN (K, M)</tt> function defined in <xref target="RFC8017"/> with the signer's private signing key (<tt>K</tt>) and the
signature base (<tt>M</tt>) (<xref target="create-sig-input"/>).
The hash SHA-256 <xref target="RFC6234"/> is applied to the signature base to create
the digest content to which the digital signature is applied.
The resulting signed content byte array (<tt>S</tt>) is the HTTP message signature output used in <xref target="sign"/>.</t>
          <t>To verify using this algorithm, the verifier applies the <tt>RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)</tt> function <xref target="RFC8017"/> using the public key portion of the verification key material (<tt>(n, e)</tt>) (<tt>n, e</tt>) and the signature base (<tt>M</tt>) re-created recreated as described in <xref target="verify"/>.
The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature base to create the digest content to which the verification function is applied.
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as described in <xref target="verify"/>.
The results of the verification function indicate if whether the signature presented is valid.</t>
          <t>Use
          <t>The use of this algorithm can be indicated at runtime using the <tt>rsa-v1_5-sha256</tt> value for the <tt>alg</tt> signature parameter.</t>
        </section>
        <section anchor="method-hmac-sha256">
          <name>HMAC using Using SHA-256</name>
          <t>To sign and verify using this algorithm, the signer applies the <tt>HMAC</tt> function <xref target="RFC2104"/> with the shared signing key (<tt>K</tt>) and the
signature base (<tt>text</tt>) (<xref target="create-sig-input"/>).
The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature base to create the digest content to which the HMAC is applied, giving the signature result.</t>
          <t>For signing, the resulting value is the HTTP message signature output used in <xref target="sign"/>.</t>
          <t>For verification, the verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as described in <xref target="verify"/>.
The output of the HMAC function is compared bytewise to the value of the HTTP message signature, and the results of the comparison determine the validity of the signature presented.</t>
          <t>Use
          <t>The use of this algorithm can be indicated at runtime using the <tt>hmac-sha256</tt> value for the <tt>alg</tt> signature parameter.</t>
        </section>
        <section anchor="method-ecdsa-p256-sha256">
          <name>ECDSA using curve Using Curve P-256 DSS and SHA-256</name>
          <t>To sign using this algorithm, the signer applies the <tt>ECDSA</tt> signature algorithm defined in <xref target="FIPS186-4"/> target="FIPS186-5"/> using curve P-256 with the signer's private signing key and
the signature base (<xref target="create-sig-input"/>).
The hash SHA-256 <xref target="RFC6234"/> is applied to the signature base to create
the digest content to which the digital signature is applied, applied (<tt>M</tt>).
The signature algorithm returns two integer values, values: <tt>r</tt> and <tt>s</tt>. These are both encoded as big-endian unsigned integers, zero-padded to 32-octets 32 octets each. These encoded values are concatenated into a single 64-octet array consisting of the encoded value of <tt>r</tt> followed by the encoded value of <tt>s</tt>. The resulting concatenation of <tt>(r, s)</tt> is a byte array of the HTTP message signature output used in <xref target="sign"/>.</t>
          <t>To verify using this algorithm, the verifier applies the <tt>ECDSA</tt> signature algorithm defined in <xref target="FIPS186-4"/> target="FIPS186-5"/>  using the public key portion of the verification key material and the signature base re-created recreated as described in <xref target="verify"/>.
The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature base to create the digest content to which the signature verification function is applied, applied (<tt>M</tt>).
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as described in <xref target="verify"/>. This value is a 64-octet array consisting of the encoded values of <tt>r</tt> and <tt>s</tt> concatenated in order. These are both encoded in as big-endian unsigned integers, zero-padded to 32-octets 32 octets each. The resulting signature value <tt>(r, s)</tt> is used as input to the signature verification function.
The results of the verification function indicate if whether the signature presented is valid.</t>
          <t>Note that the output of ECDSA signature algorithms are non-deterministic, and therefore is non-deterministic; therefore, it is not correct to re-calculate recalculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See <xref target="security-nondeterministic"/>.</t>
          <t>Use
          <t>The use of this algorithm can be indicated at runtime using the <tt>ecdsa-p256-sha256</tt> value for the <tt>alg</tt> signature parameter.</t>
        </section>
        <section anchor="method-ecdsa-p384-sha384">
          <name>ECDSA using curve Using Curve P-384 DSS and SHA-384</name>
          <t>To sign using this algorithm, the signer applies the <tt>ECDSA</tt> signature algorithm defined in <xref target="FIPS186-4"/> target="FIPS186-5"/> using curve P-384 with the signer's private signing key and the
signature base (<xref target="create-sig-input"/>).
The hash SHA-384 <xref target="RFC6234"/> is applied to the signature base to create
the digest content to which the digital signature is applied, applied (<tt>M</tt>).
The signature algorithm returns two integer values, values: <tt>r</tt> and <tt>s</tt>. These are both encoded as big-endian unsigned integers, zero-padded to 48-octets 48 octets each. These encoded values are concatenated into a single 96-octet array consisting of the encoded value of <tt>r</tt> followed by the encoded value of <tt>s</tt>. The resulting concatenation of <tt>(r, s)</tt> is a byte array of the HTTP message signature output used in <xref target="sign"/>.</t>
          <t>To verify using this algorithm, the verifier applies the <tt>ECDSA</tt> signature algorithm defined in <xref target="FIPS186-4"/> target="FIPS186-5"/>  using the public key portion of the verification key material and the signature base re-created recreated as described in <xref target="verify"/>.
The hash function SHA-384 <xref target="RFC6234"/> is applied to the signature base to create the digest content to which the signature verification function is applied, applied (<tt>M</tt>).
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as described in <xref target="verify"/>. This value is a 96-octet array consisting of the encoded values of <tt>r</tt> and <tt>s</tt> concatenated in order. These are both encoded in as big-endian unsigned integers, zero-padded to 48-octets 48 octets each. The resulting signature value <tt>(r, s)</tt> is used as input to the signature verification function.
The results of the verification function indicate if whether the signature presented is valid.</t>
          <t>Note that the output of ECDSA signature algorithms are non-deterministic, and therefore is non-deterministic; therefore, it is not correct to re-calculate recalculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See <xref target="security-nondeterministic"/>.</t>
          <t>Use
          <t>The use of this algorithm can be indicated at runtime using the <tt>ecdsa-p384-sha384</tt> value for the <tt>alg</tt> signature parameter.</t>
        </section>
        <section anchor="method-ed25519">
          <name>EdDSA using curve Using Curve edwards25519</name>
          <t>To sign using this algorithm, the signer applies the <tt>Ed25519</tt> algorithm defined in <xref section="5.1.6" sectionFormat="of" target="RFC8032"/> with the signer's private signing key and
the signature base (<xref target="create-sig-input"/>).
The signature base is taken as the input message (<tt>M</tt>) with no pre-hash prehash function.
The signature is a 64-octet concatenation of <tt>R</tt> and <tt>S</tt> as specified in <xref section="5.1.6" sectionFormat="of" target="RFC8032"/>, and this is taken as a byte array for the HTTP message signature output used in <xref target="sign"/>.</t>
          <t>To verify using this algorithm, the signer applies the <tt>Ed25519</tt> algorithm defined in <xref section="5.1.7" sectionFormat="of" target="RFC8032"/> using the public key portion of the verification key material (<tt>A</tt>) and the signature base re-created recreated as described in <xref target="verify"/>.
The signature base is taken as the input message (<tt>M</tt>) with no pre-hash prehash function.
The signature to be verified is processed as the 64-octet concatenation of <tt>R</tt> and <tt>S</tt> as specified in <xref section="5.1.7" sectionFormat="of" target="RFC8032"/>.
The results of the verification function indicate if whether the signature presented is valid.</t>
          <t>Use
          <t>The use of this algorithm can be indicated at runtime using the <tt>ed25519</tt> value for the <tt>alg</tt> signature parameter.</t>
        </section>
        <section anchor="method-jose">
          <name>JSON Web Signature (JWS) algorithms</name> Algorithms</name>
          <t>If the signing algorithm is a JOSE JSON Object Signing and Encryption (JOSE) signing algorithm from the JSON "JSON Web Signature and Encryption Algorithms Registry Algorithms" registry established by <xref target="RFC7518"/>, the
JWS algorithm definition determines the signature and hashing algorithms to apply for both signing and verification.</t>
          <t>For both signing and verification, the HTTP messages message's signature base (<xref target="create-sig-input"/>) is used as the entire "JWS Signing Input".
The JOSE Header defined in <xref target="RFC7515"/> <xref target="RFC7517"/> is not used, and the signature base is not first encoded in Base64 before applying the algorithm.
The output of the JWS signature Signature is taken as a byte array prior to the Base64url encoding used in JOSE.</t>
          <t>The JWS algorithm <bcp14>MUST NOT</bcp14> be <tt>none</tt> "<tt>none</tt>" and <bcp14>MUST NOT</bcp14> be any algorithm with a JOSE Implementation Requirement of <tt>Prohibited</tt>.</t>
          <t>JWA algorithm "<tt>Prohibited</tt>".</t>
          <t>JSON Web Algorithm (JWA) values from the JSON "JSON Web Signature and Encryption Algorithms Registry Algorithms" registry are not included as signature parameters. Typically, the JWS algorithm can be signaled using JSON Web Keys (JWKs) or other mechanisms common to JOSE implementations. In fact, JWA algorithm values are not registered in the <xref target="hsa-registry">HTTP target="hsa-registry">"HTTP Signature Algorithms Algorithms" registry</xref>, and so the explicit <tt>alg</tt> signature parameter is not used at all when using JOSE signing algorithms.</t>
        </section>
      </section>
    </section>
    <section anchor="attach-signature">
      <name>Including a Message Signature in a Message</name>
      <t>HTTP message signatures can be included within an HTTP message via the Signature-Input and Signature fields, both defined within this specification.</t>
      <t>The Signature-Input field identifies the covered components and parameters that describe how the signature was generated, while the Signature field contains the signature value. Each field <bcp14>MAY</bcp14> contain multiple labeled values.</t>
      <t>An HTTP message signature is identified by a label within an HTTP message. This label <bcp14>MUST</bcp14> be unique within a given HTTP message and <bcp14>MUST</bcp14> be used in both the Signature-Input field and the Signature fields. field. The label is chosen by the signer, except where a specific label is dictated by protocol negotiations such as those described in <xref target="request-signature"/>.</t>
      <t>An HTTP message signature <bcp14>MUST</bcp14> use both the Signature-Input field and the Signature fields field, and each field <bcp14>MUST</bcp14> contain the same labels. The presence of a label in one field but not in the other is an error.</t>
      <section anchor="signature-input-header">
        <name>The Signature-Input HTTP Field</name>
        <t>The Signature-Input field is a Dictionary structured field Structured Field (defined in <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) target="RFC8941"/>) containing the metadata for one or more message signatures generated from components within the HTTP message. Each member describes a single message signature. The member's key is the label that uniquely identifies the message signature within the HTTP message. The member's value is the serialization of the covered components ordered set serialized as an Inner List plus List, including all signature metadata parameters identified by the label.</t> label:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig1=("@method" "@target-uri" "@authority" \
  "content-digest" "cache-control");\
  created=1618884475;keyid="test-key-rsa-pss"
]]></sourcecode>
        <t>To facilitate signature validation, the Signature-Input field value <bcp14>MUST</bcp14> contain the same serialized value used
in generating the signature base's <tt>@signature-params</tt> value defined in <xref target="signature-params"/>. Note that in a structured field Structured Field value, list order and parameter order have to be preserved.</t>
        <t>The signer <bcp14>MAY</bcp14> include the Signature-Input field as a trailer to facilitate signing a message after its content has been processed by the signer. However, since intermediaries are allowed to drop trailers as per <xref target="HTTP"/>, target="RFC9110"/>, it is <bcp14>RECOMMENDED</bcp14> that the Signature-Input field be included only as a header field to avoid signatures being inadvertently stripped from a message.</t>
        <t>Multiple Signature-Input fields <bcp14>MAY</bcp14> be included in a single HTTP message. The signature labels <bcp14>MUST</bcp14> be unique across all field values.</t>
      </section>
      <section anchor="signature-header">
        <name>The Signature HTTP Field</name>
        <t>The Signature field is a Dictionary structured field defined Structured Field (defined in <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/>) containing one or more message signatures generated from the signature context of the target message. The member's key is the label that uniquely identifies the message signature within the HTTP message. The member's value is a Byte Sequence containing the signature value for the message signature identified by the label.</t> label:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature: sig1=:P0wLUszWQjoi54udOtydf9IWTfNhy+r53jGFj9XZuP4uKwxyJo\
  1RSHi+oEF1FuX6O29d+lbxwwBao1BAgadijW+7O/PyezlTnqAOVPWx9GlyntiCiHz\
  C87qmSQjvu1CFyFuWSjdGa3qLYYlNm7pVaJFalQiKWnUaqfT4LyttaXyoyZW84jS8\
  gyarxAiWI97mPXU+OVM64+HVBHmnEsS+lTeIsEQo36T3NFf2CujWARPQg53r58Rmp\
  Z+J9eKR2CD6IJQvacn5A4Ix5BUAVGqlyp8JYm+S/CWJi31PNUjRRCusCVRj05NrxA\
  BNFv3r5S9IXf2fYJK+eyW4AiGVMvMcOg==:
]]></sourcecode>
        <t>The signer <bcp14>MAY</bcp14> include the Signature field as a trailer to facilitate signing a message after its content has been processed by the signer. However, since intermediaries are allowed to drop trailers as per <xref target="HTTP"/>, target="RFC9110"/>, it is <bcp14>RECOMMENDED</bcp14> that the Signature field be included only as a header field to avoid signatures being inadvertently stripped from a message.</t>
        <t>Multiple Signature fields <bcp14>MAY</bcp14> be included in a single HTTP message. The signature labels <bcp14>MUST</bcp14> be unique across all field values.</t>
      </section>
      <section anchor="signature-multiple">
        <name>Multiple Signatures</name>
        <t>Multiple distinct signatures <bcp14>MAY</bcp14> be included in a single message. Each distinct signature <bcp14>MUST</bcp14> have a unique label. These multiple signatures could all be added all by the same signer signer, or they could come from several different signers. For example, a signer may include multiple signatures signing the same message components with different keys or algorithms to support verifiers with different capabilities, or a reverse proxy may include information about the client in fields when forwarding the request to a service host, including a signature over the client's original signature values.</t>
        <t>The following non-normative example starts with a signed request from the client. A reverse proxy takes this request and validates the client's signature.</t> signature:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
  +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}
]]></sourcecode>
        <t>The proxy then alters the message before forwarding it on to the origin server, changing the target host and adding the Forwarded header field defined in <xref target="RFC7239"/>.</t> target="RFC7239"/>:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
  +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}
]]></sourcecode>
        <t>The proxy is in a position to validate the incoming client's signature and make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.
The proxy also includes all the elements from the original message that are relevant to the origin server's processing. In many cases, the proxy will want to cover all the same components that were covered by the client's signature, which is the case in this the following example. Note that in this example, the proxy is signing over the new authority value, which it has changed. The proxy also adds the Forwarded header field to its own signature value.
The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window. This results in a signature base of:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@method": POST
"@authority": origin.host.internal.example
"@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
  +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type": application/json
"content-length": 18
"forwarded": for=192.0.2.123;host=example.com;proto=https
"@signature-params": ("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length" "forwarded")\
  ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
  ;expires=1618884540
]]></artwork>
        <t>And
        <t>and a signature output value of:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy\
+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s\
x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn\
Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0\
B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w\
5o0LV/g==
]]></artwork>
        <t>These values are added to the HTTP request message by the proxy. The original signature is included under the identifier label <tt>sig1</tt>, and the reverse proxy's signature is included under the label <tt>proxy_sig</tt>. The proxy uses the key <tt>test-key-rsa</tt> to create its signature using the <tt>rsa-v1_5-sha256</tt> signature algorithm, while the client's original signature was made using the key id of <tt>test-key-rsa-pss</tt> and an RSA PSS RSA-PSS signature algorithm.</t> algorithm:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
    "content-digest" "content-type" "content-length")\
    ;created=1618884475;keyid="test-key-ecc-p256", \
  proxy_sig=("@method" "@authority" "@path" "content-digest" \
    "content-type" "content-length" "forwarded")\
    ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
    ;expires=1618884540
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
    +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:, \
  proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+\
    JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G\
    wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7\
    LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf\
    lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL\
    Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==:

{"hello": "world"}
]]></sourcecode>
        <t>While the proxy could additionally include the client's Signature field value and Signature-Input fields from the original message in the new signature's covered components, this practice is <bcp14>NOT RECOMMENDED</bcp14> due to known weaknesses in signing signature values as discussed in <xref target="security-sign-signature"/>. The proxy is in a position to validate the client's signature, signature; the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server. In this example, it is possible for the origin server to have additional information in its signature context to account for the change in authority, though this practice requires additional configuration and extra care as discussed in <xref target="security-context-multiple-signatures"/>. In other applications, the origin server will not be able to verify the original signature itself but will still want to verify that the proxy has done the appropriate validation of the client's signature. An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely.</t>
      </section>
    </section>
    <section anchor="request-signature">
      <name>Requesting Signatures</name>
      <t>While a signer is free to attach a signature to a request or response without prompting, it is often desirable for a potential verifier to signal that it expects a signature from a potential signer using the Accept-Signature field.</t>
      <t>When the Accept-Signature field is sent in an HTTP request message, the field indicates that the client desires the server to sign the response using the identified parameters, and the target message is the response to this request. All responses from resources that support such signature negotiation <bcp14>SHOULD</bcp14> either be uncacheable or contain a Vary header field that lists Accept-Signature, in order to prevent a cache from returning a response with a signature intended for a different request.</t>
      <t>When the Accept-Signature field is used in an HTTP response message, the field indicates that the server desires the client to sign its next request to the server with the identified parameters, and the target message is the client's next request. The client can choose to also continue signing future requests to the same server in the same way.</t>
      <t>The target message of an Accept-Signature field <bcp14>MUST</bcp14> include all labeled signatures indicated in the Accept-Header signature, Accept-Signature field, each covering the same identified components of the Accept-Signature field.</t>
      <t>The sender of an Accept-Signature field <bcp14>MUST</bcp14> include only identifiers that are appropriate for the type of the target message. For example, if the target message is a request, the covered components can not cannot include the <tt>@status</tt> component identifier.</t>
      <section anchor="accept-signature-header">
        <name>The Accept-Signature Field</name>
        <t>The Accept-Signature field is a Dictionary structured field Structured Field (defined in <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) target="RFC8941"/>) containing the metadata for one or more requested message signatures to be generated from message components of the target HTTP message. Each member describes a single message signature. The member's key is the label that uniquely identifies the requested message signature within the context of the target HTTP message.</t>
        <t>The member's value is the serialization of the desired covered components of the target message, including any allowed component metadata parameters, using the serialization process defined in <xref target="signature-params"/>.</t> target="signature-params"/>:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Accept-Signature: sig1=("@method" "@target-uri" "@authority" \
  "content-digest" "cache-control");\
  keyid="test-key-rsa-pss";created;tag="app-123"
]]></sourcecode>
        <t>The list of component identifiers indicates the exact set of component identifiers to be included in the requested signature, including all applicable component parameters.</t>
        <t>The signature request <bcp14>MAY</bcp14> include signature metadata parameters that indicate desired behavior for the signer. The following behavior is defined by this specification:</t>
        <ul
        <dl spacing="normal">
          <li>
            <tt>created</tt>: The
          <dt>
            <tt>created</tt>:</dt><dd>The signer is requested to generate and include a creation time. This parameter has no associated value when sent as a signature request.</li>
          <li>
            <tt>expires</tt>: The request.</dd>
          <dt>
            <tt>expires</tt>:</dt><dd>The signer is requested to generate and include an expiration time. This parameter has no associated value when sent as a signature request.</li>
          <li>
            <tt>nonce</tt>: The request.</dd>
          <dt>
            <tt>nonce</tt>:</dt><dd>The signer is requested to include the value of this parameter as the signature <tt>nonce</tt> in the target signature.</li>
          <li>
            <tt>alg</tt>: The signature.</dd>
          <dt>
            <tt>alg</tt>:</dt><dd>The signer is requested to use the indicated signature algorithm from the HTTP "HTTP Signature Algorithms Registry Algorithms" registry to create the target signature.</li>
          <li>
            <tt>keyid</tt>: The signature.</dd>
          <dt>
            <tt>keyid</tt>:</dt><dd>The signer is requested to use the indicated key material to create the target signature.</li>
          <li>
            <tt>tag</tt>: The signature.</dd>
          <dt>
            <tt>tag</tt>:</dt><dd>The signer is requested to include the value of this parameter as the signature <tt>tag</tt> in the target signature.</li>
        </ul> signature.</dd>
	</dl>
      </section>
      <section anchor="processing-an-accept-signature">
        <name>Processing an Accept-Signature</name>
        <t>The receiver of an Accept-Signature field fulfills that header as follows:</t>
        <ol spacing="normal" type="1"><li>Parse the field value as a Dictionary</li> Dictionary.</li>
          <li>
            <t>For each member of the dictionary: Dictionary:
            </t>
            <ol spacing="normal" type="1"><li>The type="%p%d."><li>The key is taken as the label of the output signature as specified in <xref target="signature-input-header"/>.</li>
              <li>Parse the value of the member to obtain the set of covered component identifiers.</li>
              <li>Determine that the covered components are applicable to the target message. If not, the process fails and returns an error.</li>
              <li>Process the requested parameters, such as the signing algorithm and key material. If any requested parameters cannot be fulfilled, fulfilled or if the requested parameters conflict with those deemed appropriate to the target message, the process fails and returns an error.</li>
              <li>Select and generate any additional parameters necessary for completing the signature.</li>
              <li>Create the HTTP message signature over the target message.</li>
              <li>Create the Signature-Input and Signature values field values, and associate them with the label.</li>
            </ol>
          </li>
          <li>Optionally create any additional Signature-Input and Signature field values, with unique labels not found in the Accept-Signature field.</li>
          <li>Combine all labeled Signature-Input and Signature values field values, and attach both fields to the target message.</li>
        </ol>
        <t>By this process, a signature applied to a target message <bcp14>MUST</bcp14> have the same label, <bcp14>MUST</bcp14> include the same set of covered component, components, <bcp14>MUST</bcp14> process all requested parameters, and <bcp14>MAY</bcp14> have additional parameters.</t>
        <t>The receiver of an Accept-Signature field <bcp14>MAY</bcp14> ignore any signature request that does not fit application parameters.</t>
        <t>The target message <bcp14>MAY</bcp14> include additional signatures not specified by the Accept-Signature field. For example, to cover additional message components, the signer can create a second signature that includes the additional components as well as the signature output of the requested signature.</t>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>IANA is asked to update has updated one registry and create created four new registries, according to the following sections.</t>
      <section anchor="http-field-name-registration">
        <name>HTTP Field Name Registration</name>
        <t>IANA is asked to update has updated the entries in the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry,
registering the following entries according as follows:
</t>
        <table>
         <name>Updates to the table below:</t>
        <table> Hypertext Transfer Protocol (HTTP) Field Name Registry</name>
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Signature-Input</td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="signature-input-header"/> of RFC nnnn</td> 9421</td>
            </tr>
            <tr>
              <td align="left">Signature</td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="signature-header"/> of RFC nnnn</td> 9421</td>
            </tr>
            <tr>
              <td align="left">Accept-Signature</td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="accept-signature-header"/> of RFC nnnn</td> 9421</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="hsa-registry">

        <name>HTTP Signature Algorithms Registry</name>
        <t>This document defines HTTP Signature Algorithms, signature algorithms, for which IANA is asked to create has created and maintain now maintains a new registry titled "HTTP Signature Algorithms". Initial values for this registry are given in <xref target="iana-hsa-contents"/>. Future assignments and modifications to existing assignment assignments are to be made through the Specification Required registration policy <xref target="RFC8126"/>.</t>
        <t>The algorithms listed in this registry identify some possible cryptographic algorithms for applications to use with this specification, but the entries neither represent an exhaustive list of possible algorithms nor indicate fitness for purpose with any particular application of this specification. An application is free to implement any algorithm that suits its needs, provided the signer and verifier can agree to the parameters of that algorithm in a secure and deterministic fashion. When an application has a need needs to signal the use of a particular algorithm at runtime using the <tt>alg</tt> signature parameter, this registry provides a mapping between the value of that parameter to and a particular algorithm. However, the use of the <tt>alg</tt> parameter needs to be treated with caution to avoid various forms of algorithm confusion and substitution attacks, such as discussed in <xref target="security-keydowngrade"/> and others.</t> target="security"/>.</t>
        <t>The Status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs. Standards Development Organizations (SDOs). When an algorithm is first registered, the Designated Expert designated expert (DE) should set the Status field to "Active" if there is consensus for the algorithm to be generally recommended as secure or "Provisional" if the algorithm has not reached that consensus, such as e.g., for an experimental algorithm. A status of "Provisional" does not mean that the algorithm is known to be insecure, insecure but instead indicates that the algorithm has not reached consensus regarding its properties. If at a future time the algorithm as registered is found to have flaws, the registry entry can be updated and the algorithm can be marked as "Deprecated" to indicate that the algorithm has been found to have problems. This status does not preclude an application from using a particular algorithm, but algorithm; rather, it serves to provide a warning of regarding possible known issues with an algorithm that need to be considered by the application. The DE can further ensure that the registration includes an explanation and reference for the Status value, which value; this is particularly important for deprecated algorithms.</t>
        <t>The DE is expected to ensure do the following:</t>
        <ul><li>Ensure that the algorithms referenced by a registered algorithm identifier are fully defined with all parameters (such as (e.g., salt, hash, required key length, etc) length) fixed by the defining text. The DE is expected to ensure text.</li>
        <li>Ensure that the algorithm definition fully specifies the <tt>HTTP_SIGN</tt> and <tt>HTTP_VERIFY</tt> primitive functions, including how all defined inputs and outputs map to the underlying cryptographic algorithm. The DE is expected to reject algorithm.</li>
        <li>Reject any registrations that are aliases of existing registrations. The DE is expected to ensure registrations.</li>
        <li>Ensure that all registrations follow the template presented in <xref target="iana-hsa-template"/>, including target="iana-hsa-template"/>; this includes ensuring that the length of the name is not excessive while still being unique and recognizable.</t> recognizable.</li>
</ul>
        <t>This specification creates algorithm identifiers by including major parameters in the identifier string String in order to make the algorithm name unique and recognizable by developers. However, algorithm identifiers in this registry are to be interpreted as whole string String values and not as a combination of parts. That is to say, it is expected that implementors understand <tt>rsa-pss-sha512</tt> as referring to one specific algorithm with its hash, mask, and salt values set as defined in the defining text that establishes this identifier. the identifier in question. Implementors do not parse out the <tt>rsa</tt>, <tt>pss</tt>, and <tt>sha512</tt> portions of the identifier to determine parameters of the signing algorithm from the string, String, and the registry registration of one combination of parameters does not imply the registration of other combinations.</t>
        <section anchor="iana-hsa-template">
          <name>Registration Template</name>
          <dl newline="true">
            <dt>Algorithm Name:</dt>
            <dd>
              <t>An identifier for the HTTP Signature Algorithm. signature algorithm. The name <bcp14>MUST</bcp14> be an ASCII string that conforms to the <tt>sf-string</tt> ABNF rule in <xref section="3.3.3" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> and <bcp14>SHOULD NOT</bcp14> exceed 20 characters in length. The identifier <bcp14>MUST</bcp14> be unique within the context of the registry.</t>
            </dd>
            <dt>Description:</dt>
            <dd>
              <t>A brief description of the algorithm used to sign the signature base.</t>
            </dd>
            <dt>Status:</dt>
            <dd>
              <t>The
              <dd><t>The status of the algorithm. <bcp14>MUST</bcp14> start with one of the following values and <bcp14>MAY</bcp14> contain additional explanatory text. The options are:
  - "Active": for are:</t>

  <dl newline="false" spacing="normal">
   <dt>"Active":</dt><dd>For algorithms without known problems. The signature algorithm is fully specified specified, and its security properties are understood.
  - "Provisional": for understood.</dd>
   <dt>"Provisional":</dt><dd>For unproven algorithms. The signature algorithm is fully specified specified, but its security properties are not known or proven.
  - "Deprecated": for proven.</dd>
   <dt>"Deprecated":</dt><dd>For algorithms with know known security issues. The signature algorithm is no longer recommended for general use and might be insecure or unsafe in some known circumstances.</t> circumstances.</dd>
  </dl>
 </dd>
            <dt>Specification document(s):</dt>

            <dt>Reference:</dt>
            <dd>
              <t>Reference to the document(s) document or documents that specify the
  algorithm, preferably including a URI that can be used
  to retrieve a copy of the document(s). An indication of the
  relevant sections may also be included but is not required.</t>
            </dd>
          </dl>
        </section>
        <section anchor="iana-hsa-contents">
          <name>Initial Contents</name>
          <t>The table below contains the initial contents of the "HTTP Signature Algorithms" registry.</t>
          <table>
            <name>Initial contents Contents of the HTTP Signature Algorithms Registry.</name> Registry</name>
            <thead>
              <tr>
                <th align="left">Algorithm Name</th>
                <th align="left">Description</th>
                <th align="left">Status</th>
                <th align="left">Specification document(s)</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>rsa-pss-sha512</tt></td>
                <td align="left">RSASSA-PSS using SHA-512</td>
                <td align="left">Active</td>
                <td align="left">
                  <xref target="method-rsa-pss-sha512"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>rsa-v1_5-sha256</tt></td>
                <td align="left">RSASSA-PKCS1-v1_5 using SHA-256</td>
                <td align="left">Active</td>
                <td align="left">
                  <xref target="method-rsa-v1_5-sha256"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>hmac-sha256</tt></td>
                <td align="left">HMAC using SHA-256</td>
                <td align="left">Active</td>
                <td align="left">
                  <xref target="method-hmac-sha256"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>ecdsa-p256-sha256</tt></td>
                <td align="left">ECDSA using curve P-256 DSS and SHA-256</td>
                <td align="left">Active</td>
                <td align="left">
                  <xref target="method-ecdsa-p256-sha256"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>ecdsa-p384-sha384</tt></td>
                <td align="left">ECDSA using curve P-384 DSS and SHA-384</td>
                <td align="left">Active</td>
                <td align="left">
                  <xref target="method-ecdsa-p384-sha384"/> of RFC nnnn</td> 9421</td>
              </tr>

              <tr>
                <td align="left">
                  <tt>ed25519</tt></td>
                <td align="left">Edwards Curve DSA align="left">EdDSA using curve edwards25519</td>
                <td align="left">Active</td>
                <td align="left">
                  <xref target="method-ed25519"/> of RFC nnnn</td> 9421</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="param-registry">

        <name>HTTP Signature Metadata Parameters Registry</name>
        <t>This document defines the signature parameters structure in <xref target="signature-params"/>, (<xref target="signature-params"/>), which may have parameters containing metadata about a message signature. IANA is asked to create has created and maintain now maintains a new registry titled "HTTP Signature Metadata Parameters" to record and maintain the set of parameters defined for use with member values in the signature parameters structure. Initial values for this registry are given in <xref target="iana-param-contents"/>. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy <xref target="RFC8126"/>.</t>
        <t>The DE is expected to ensure do the following:</t>
        <ul><li>Ensure that the name follows the template presented in <xref target="iana-param-template"/>, including target="iana-param-template"/>; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function. The DE is expected to ensure function.</li>
        <li>Ensure that the defined functionality is clear and does not conflict with other registered parameters. The DE is expected to ensure parameters.</li>
        <li>Ensure that the definition of the metadata parameter includes its behavior when used as part of the normal signature process as well as when used in an Accept-Signature field.</t> field.</li>
</ul>
        <section anchor="iana-param-template">
          <name>Registration Template</name>
          <dl newline="true">
            <dt>Name:</dt>
            <dd>
              <t>An identifier for the HTTP signature metadata parameter. The name <bcp14>MUST</bcp14> be an ASCII string that conforms to the <tt>key</tt> ABNF rule defined in <xref section="3.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> and <bcp14>SHOULD NOT</bcp14> exceed 20 characters in length. The identifier <bcp14>MUST</bcp14> be unique within the context of the registry.</t>
            </dd>
            <dt>Description:</dt>
            <dd>
              <t>A brief description of the metadata parameter and what it represents.</t>
            </dd>
            <dt>Specification document(s):</dt>
            <dt>Reference:</dt>
            <dd>
              <t>Reference to the document(s) document or documents that specify the
  parameter, preferably including a URI that can be used
  to retrieve a copy of the document(s). An indication of the
  relevant sections may also be included but is not required.</t>
            </dd>
          </dl>
        </section>
        <section anchor="iana-param-contents">
          <name>Initial Contents</name>
          <t>The table below contains the initial contents of the HTTP "HTTP Signature Metadata Parameters Registry. Parameters" registry. Each row in the table represents a distinct entry in the registry.</t>
          <table>
            <name>Initial contents Contents of the HTTP Signature Metadata Parameters Registry.</name> Registry</name>
            <thead>
              <tr>
                <th align="left">Name</th>
                <th align="left">Description</th>
                <th align="left">Specification document(s)</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>alg</tt></td>
                <td align="left">Explicitly declared signature algorithm</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>created</tt></td>
                <td align="left">Timestamp of signature creation</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>expires</tt></td>
                <td align="left">Timestamp of proposed signature expiration</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>keyid</tt></td>
                <td align="left">Key identifier for the signing and verification keys used to create this signature</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>nonce</tt></td>
                <td align="left">A single-use nonce value</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>tag</tt></td>
                <td align="left">An application-specific tag for a signature</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="content-registry">
        <name>HTTP Signature Derived Component Names Registry</name>
        <t>This document defines a method for canonicalizing HTTP message components, including components that can be derived from the context of the target message outside of the HTTP fields. These derived components are identified by a unique string, String, known as the component name. Component names for derived components always start with the "@" (at) "at" (@) symbol to distinguish them from HTTP field names. IANA is asked to create has created and maintain now maintains a new registry typed titled "HTTP Signature Derived Component Names" to record and maintain the set of non-field component names and the methods used to produce their associated component values. Initial values for this registry are given in <xref target="iana-content-contents"/>. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy <xref target="RFC8126"/>.</t>
        <t>The DE is expected to ensure do the following:</t>
        <ul><li>Ensure that the name follows the template presented in <xref target="iana-content-template"/>, including target="iana-content-template"/>; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function. The DE is expected to ensure function.</li>
        <li>Ensure that the component value represented by the registration request can be deterministically derived from the target HTTP message. The DE is expected to ensure message.</li>
        <li>Ensure that any parameters defined for the registration request are clearly documented, along with their effects on the component value. The value.</li>
</ul>
<t>The DE should also ensure that the a registration request is not sufficiently distinct from existing derived component definitions to warrant its registration. When registration.</t>
<t>When setting a registered item's status to "Deprecated", the DE should ensure that a reason for the deprecation is documented, along with instructions for moving away from the deprecated functionality.</t>
        <section anchor="iana-content-template">
          <name>Registration Template</name>
          <dl newline="true">
            <dt>Name:</dt>
            <dd>
              <t>A name for the HTTP derived component. The name <bcp14>MUST</bcp14> begin with the <tt>"@"</tt> "at" (<tt>@</tt>) character followed by an ASCII string consisting only of lower-case lowercase characters (<tt>"a"</tt> - <tt>"z"</tt>), (<tt>"a"</tt>-<tt>"z"</tt>), digits (<tt>"0"</tt> - <tt>"9"</tt>), (<tt>"0"</tt>-<tt>"9"</tt>), and hyphens (<tt>"-"</tt>), and <bcp14>SHOULD NOT</bcp14> exceed 20 characters in length. The name <bcp14>MUST</bcp14> be unique within the context of the registry.</t>
            </dd>
            <dt>Description:</dt>
            <dd>
              <t>A description of the derived component.</t>
            </dd>
            <dt>Status:</dt>
            <dd>
              <t>A brief text description of the status of the algorithm. The description <bcp14>MUST</bcp14> begin with one of "Active" or "Deprecated", "Deprecated" and <bcp14>MAY</bcp14> provide further context or explanation as to the reason for the status. A value of "Deprecated" indicates that the derived component name is no longer recommended for use.</t>
            </dd>
            <dt>Target:</dt>
            <dd>
              <t>The valid message targets for the derived parameter. <bcp14>MUST</bcp14> be one of the values "Request", "Response", or "Request, Response". The semantics of these entries are defined in <xref target="derived-components"/>.</t>
            </dd>
            <dt>Specification document(s):</dt>
            <dt>Reference:</dt>
            <dd>
              <t>Reference to the document(s) document or documents that specify the
  derived component, preferably including a URI that can be used
  to retrieve a copy of the document(s). An indication of the
  relevant sections may also be included but is not required.</t>
            </dd>
          </dl>
        </section>
        <section anchor="iana-content-contents">
          <name>Initial Contents</name>
          <t>The table below contains the initial contents of the HTTP "HTTP Signature Derived Component Names Registry.</t> Names" registry.</t>
          <table>
            <name>Initial contents Contents of the HTTP Signature Derived Component Names Registry.</name> Registry</name>
            <thead>
              <tr>
                <th align="left">Name</th>
                <th align="left">Description</th>
                <th align="left">Status</th>
                <th align="left">Target</th>
                <th align="left">Specification document(s)</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>@signature-params</tt></td>
                <td align="left">Reserved for signature parameters line in signature base</td>
                <td align="left">Active</td>
                <td align="left">Request, Response</td>
                <td align="left">
                  <xref target="signature-params"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@method</tt></td>
                <td align="left">The HTTP request method</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-method"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@authority</tt></td>
                <td align="left">The HTTP authority, or target host</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-authority"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@scheme</tt></td>
                <td align="left">The URI scheme of the request URI</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-scheme"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@target-uri</tt></td>
                <td align="left">The full target URI of the request</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-target-uri"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@request-target</tt></td>
                <td align="left">The request target of the request</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-target"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@path</tt></td>
                <td align="left">The full path of the request URI</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-path"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@query</tt></td>
                <td align="left">The full query of the request URI</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-query"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@query-param</tt></td>
                <td align="left">A single named query parameter</td>
                <td align="left">Active</td>
                <td align="left">Request</td>
                <td align="left">
                  <xref target="content-request-query-param"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>@status</tt></td>
                <td align="left">The status code of the response</td>
                <td align="left">Active</td>
                <td align="left">Response</td>
                <td align="left">
                  <xref target="content-status-code"/> of RFC nnnn</td> 9421</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="component-param-registry">
        <name>HTTP Signature Component Parameters Registry</name>
        <t>This document defines several kinds of component identifiers, some of which can be parameterized in specific circumstances to provide unique modified behavior. IANA is asked to create has created and maintain now maintains a new registry typed titled "HTTP Signature Component Parameters" to record and maintain the set of parameters parameter names, the component identifiers they are associated with, and the modifications these parameters make to the component value. Definitions of parameters <bcp14>MUST</bcp14> define the targets to which they apply (such as specific field types, derived components, or contexts). Initial values for this registry are given in <xref target="iana-component-param-contents"/>. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy <xref target="RFC8126"/>.</t>
        <t>The DE is expected to ensure do the following:</t>
        <ul><li>Ensure that the name follows the template presented in <xref target="iana-component-param-template"/>, including target="iana-component-param-template"/>; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function. The DE is expected to ensure function.</li>
        <li>Ensure that the definition of the field sufficiently defines any interactions or incompatibilities with other existing parameters known at the time of the registration request. If the parameter changes the component value, the DE is expected to ensure request.</li>
        <li>Ensure that the component value defined by the component identifier with the parameter applied can be deterministically derived from the target HTTP message.</t> message in cases where the parameter changes the component value.</li>
</ul>
        <section anchor="iana-component-param-template">
          <name>Registration Template</name>
          <dl newline="true">
            <dt>Name:</dt>
            <dd>
              <t>A name for the parameter. The name <bcp14>MUST</bcp14> be an ASCII string that conforms to the <tt>key</tt> ABNF rule defined in <xref section="3.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> and <bcp14>SHOULD NOT</bcp14> exceed 20 characters in length. The name <bcp14>MUST</bcp14> be unique within the context of the registry.</t>
            </dd>
            <dt>Description:</dt>
            <dd>
              <t>A description of the parameter's function.</t>
            </dd>
            <dt>Specification document(s):</dt>
            <dt>Reference:</dt>
            <dd>
              <t>Reference to the document(s) document or documents that specify the
  derived component, preferably including a URI that can be used
  to retrieve a copy of the document(s). An indication of the
  relevant sections may also be included but is not required.</t>
            </dd>
          </dl>
        </section>
        <section anchor="iana-component-param-contents">
          <name>Initial Contents</name>

          <t>The table below contains the initial contents of the HTTP "HTTP Signature Derived Component Names Registry.</t> Parameters" registry.</t>
          <table>
            <name>Initial contents Contents of the HTTP Signature Component Parameters Registry.</name> Registry</name>
            <thead>
              <tr>
                <th align="left">Name</th>
                <th align="left">Description</th>
                <th align="left">Specification document(s)</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>sf</tt></td>
                <td align="left">Strict structured field Structured Field serialization</td>
                <td align="left">
                  <xref target="http-field-structured"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>key</tt></td>
                <td align="left">Single key value of dictionary structured fields</td> Dictionary Structured Fields</td>
                <td align="left">
                  <xref target="http-field-dictionary"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>bs</tt></td>
                <td align="left">Byte Sequence wrapping indicator</td>
                <td align="left">
                  <xref target="http-field-byte-sequence"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>tr</tt></td>
                <td align="left">Trailer</td>
                <td align="left">
                  <xref target="http-trailer"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>req</tt></td>
                <td align="left">Related request indicator</td>
                <td align="left">
                  <xref target="content-request-scheme"/> target="content-request-response"/> of RFC nnnn</td> 9421</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>name</tt></td>
                <td align="left">Single named query parameter</td>
                <td align="left">
                  <xref target="content-request-query-param"/> of RFC nnnn</td> 9421</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>In order for an HTTP message to be considered <em>covered</em> by a signature, all of the following conditions have to be true:</t>
      <ul spacing="normal">
        <li>a
        <li>A signature is expected or allowed on the message by the verifier</li>
        <li>the verifier.</li>
        <li>The signature exists on the message</li>
        <li>the message.</li>
        <li>The signature is verified against the identified key material and algorithm</li>
        <li>the algorithm.</li>
        <li>The key material and algorithm are appropriate for the context of the message</li>
        <li>the message.</li>
        <li>The signature is within expected time boundaries</li>
        <li>the boundaries.</li>
        <li>The signature covers the expected content, including any critical components</li>
        <li>the components.</li>
        <li>The list of covered components is applicable to the context of the message</li> message.</li>
      </ul>
      <t>In addition to the application requirement definitions listed in <xref target="application"/>, the following security considerations provide discussion and context to regarding the requirements of creating and verifying signatures on HTTP messages.</t>
      <section anchor="general-considerations">
        <name>General Considerations</name>
        <section anchor="security-ignore">
          <name>Skipping Signature Verification</name>
          <t>HTTP Message Signatures message signatures only provide security if the signature is verified by the verifier. Since the message to which the signature is attached remains a valid HTTP message without the signature Signature or Signature-Input fields, it is possible for a verifier to ignore the output of the verification function and still process the message. Common reasons for this could be relaxed requirements in a development environment or a temporary suspension of enforcing verification during while debugging an overall system. Such temporary suspensions are difficult to detect under positive-example testing testing, since a good signature will always trigger a valid response whether or not it has been checked.</t>
          <t>To detect this, verifiers should be tested using both valid and invalid signatures, ensuring that the an invalid signature fails as expected.</t>
        </section>
        <section anchor="security-tls">
          <name>Use of TLS</name>
          <t>The use of HTTP Message Signatures message signatures does not negate the need for TLS or its equivalent to protect information in transit. Message signatures provide message integrity over the covered message components but do not provide any confidentiality for the communication between parties.</t>
          <t>TLS provides such confidentiality between the TLS endpoints. As part of this, TLS also protects the signature data itself from being captured by an attacker, which attacker.  This is an important step in preventing <xref target="security-replay">signature replay</xref>.</t>
          <t>When TLS is used, it needs to be deployed according to the recommendations provided in <xref target="BCP195"/>.</t>
        </section>
      </section>
      <section anchor="message-processing-and-selection">
        <name>Message Processing and Selection</name>
        <section anchor="security-coverage">
          <name>Insufficient Coverage</name>
          <t>Any portions of the message not covered by the signature are susceptible to modification by an attacker without affecting the signature. An attacker can take advantage of this by introducing or modifying a header field or other message component that will change the processing of the message but will not be covered by the signature. Such an altered message would still pass signature verification, but when the verifier processes the message as a whole, the unsigned content injected by the attacker would subvert the trust conveyed by the valid signature and change the outcome of processing the message.</t>
          <t>To combat this, an application of this specification should require as much of the message as possible to be signed, within the limits of the application and deployment. The verifier should only trust message components that have been signed. Verifiers could also strip out any sensitive unsigned portions of the message before processing of the message continues.</t>
        </section>
        <section anchor="security-replay">
          <name>Signature Replay</name>
          <t>Since HTTP Message Signatures allows message signatures allow sub-portions of the HTTP message to be signed, it is possible for two different HTTP messages to validate against the same signature. The most extreme form of this would be a signature over no message components. If such a signature were intercepted, it could be replayed at will by an attacker, attached to any HTTP message. Even with sufficient component coverage, a given signature could be applied to two similar HTTP messages, allowing a message to be replayed by an attacker with the signature intact.</t>
          <t>To counteract these kinds of attacks, it's first important for the signer to cover sufficient portions of the message to differentiate it from other messages. In addition, the signature can use the <tt>nonce</tt> signature parameter to provide a per-message unique value to allow the verifier to detect replay of the signature itself if a nonce value is repeated. Furthermore, the signer can provide a timestamp for when the signature was created and a time at which the signer considers the signature to be expired, limiting the utility of a captured signature value.</t>
          <t>If a verifier wants to trigger a new signature from a signer, it can send the <tt>Accept-Signature</tt> Accept-Signature header field with a new <tt>nonce</tt> parameter. An attacker that is simply replaying a signature would not be able to generate a new signature with the chosen nonce value.</t>
        </section>
        <section anchor="security-components">
          <name>Choosing Message Components</name>
          <t>Applications of HTTP Message Signatures message signatures need to decide which message components will be covered by the signature. Depending on the application, some components could be expected to be changed by intermediaries prior to the signature's verification. If these components are covered, such changes would, by design, break the signature.</t>
          <t>However, the HTTP Message Signature standard this document allows for flexibility in determining which components are signed precisely so that a given application can choose the appropriate portions of the message that need to be signed, avoiding problematic components. For example, a web application framework that relies on rewriting query parameters might avoid use of using the <tt>@query</tt> derived component in favor of sub-indexing the query value using <tt>@query-param</tt> derived components instead.</t>
          <t>Some components are expected to be changed by intermediaries and ought not to be signed under most circumstance. circumstances. The <tt>Via</tt> Via and <tt>Forwarded</tt> Forwarded header fields, for example, are expected to be manipulated by proxies and other middle-boxes, middleboxes, including replacing or entirely dropping existing values. These fields should not be covered by the signature signature, except in very limited and tightly-coupled tightly coupled scenarios.</t>
          <t>Additional considerations for choosing signature aspects are discussed in <xref target="application"/>.</t>
        </section>
        <section anchor="security-not-fields">
          <name>Choosing Signature Parameters and Derived Components over HTTP Fields</name>
          <t>Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components. In most cases, it is more desirable to sign the non-field alternative. In particular, the following fields should usually not be included in the signature unless the application specifically requires it:</t>
          <dl>
            <dt>"date"</dt>
            <dd>
              <t>The "date" Date header field value represents the timestamp of the HTTP message. However, the creation time of the signature itself is encoded in the <tt>created</tt> signature parameter. These two values can be different, depending on how the signature and the HTTP message are created and serialized. Applications processing signatures for valid time windows should use the <tt>created</tt> signature parameter for such calculations. An application could also put limits on how much skew there is between the "date" Date field and the <tt>created</tt> signature parameter, in order to limit the application of a generated signature to different HTTP messages. See also <xref target="security-replay"/> Sections&nbsp;<xref target="security-replay" format="counter"/> and <xref target="security-coverage"/>.</t> target="security-coverage" format="counter"/>.</t>
            </dd>
            <dt>"host"</dt>
            <dd>
              <t>The "host" Host header field is specific to HTTP/1.1, and its functionality is subsumed by the "@authority" <tt>@authority</tt> derived component, defined in <xref target="content-request-authority"/>. In order to preserve the value across different HTTP versions, applications should always use the "@authority" <tt>@authority</tt> derived component. See also <xref target="security-versions"/>.</t>
            </dd>
          </dl>
        </section>
        <section anchor="security-labels">
          <name>Signature Labels</name>
          <t>HTTP Message Signature message signature values are identified in the Signature and Signature-Input field values by unique labels. These labels are chosen only when attaching the signature values to the message and are not accounted for in during the signing process. An intermediary is allowed to re-label relabel an existing signature when processing the message.</t>
          <t>Therefore, applications should not rely on specific labels being present, and applications should not put semantic meaning on the labels themselves. Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached to to, and covered by by, the signature. In particular, the <tt>tag</tt> parameter can be used to define an application-specific value as described in <xref target="security-signature-tag"/>.</t>
        </section>
        <section anchor="security-multiple">
          <name>Multiple Signature Confusion</name>
          <t>Since <xref target="signature-multiple">multiple signatures can be applied to one message</xref>, it is possible for an attacker to attach their own signature to a captured message without modifying existing signatures. This new signature could be completely valid based on the attacker's key, or it could be an invalid signature for any number of reasons. Each of these situations need needs to be accounted for.</t>
          <t>A verifier processing a set of valid signatures needs to account for all of the signers, identified by the signing keys. Only signatures from expected signers should be accepted, regardless of the cryptographic validity of the signature itself.</t>
          <t>A verifier processing a set of signatures on a message also needs to determine what to do when one or more of the signatures are not valid. If a message is accepted when at least one signature is valid, then a verifier could drop all invalid signatures from the request before processing the message further. Alternatively, if the verifier rejects a message for a single invalid signature, an attacker could use this to deny service to otherwise valid messages by injecting invalid signatures alongside the valid ones.</t> signatures.</t>
        </section>
        <section anchor="security-signature-tag">
          <name>Collision of Application-Specific Signature Tag</name>
          <t>Multiple applications and protocols could apply HTTP signatures on the same message simultaneously. In fact, this is a desired feature in many circumstances as described in circumstances; see <xref target="signature-multiple"/>. A naive verifier could become confused in while processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the <tt>tag</tt> signature parameter as defined in <xref target="signature-params"/>. For example, a signature targeting an application gateway could require <tt>tag="app-gateway"</tt> as part of the signature parameters for that application.</t>
          <t>The use of the <tt>tag</tt> parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted. As a consequence, a verifier should only use a value of the <tt>tag</tt> parameter to limit which signatures to check. Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in <xref target="security-coverage"/>.</t>
        </section>
        <section anchor="security-message-content">
          <name>Message Content</name>
          <t>On its own, this specification does not provide coverage for the content of an HTTP message under the signature, either in either a request or a response. However, <xref target="DIGEST"/> target="RFC9530"/> 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 <xref target="http-fields"/>.</t>
          <t>For example, in the following response message:</t>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json

{"hello": "world"}
]]></sourcecode>
          <t>The digest of the content can be added to the Content-Digest field as follows:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}
]]></sourcecode>
          <t>This field can be included in a signature base just like any other field along with the basic signature parameters:</t>
          <artwork><![CDATA[
"@status": 200
"content-digest": \
  sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
"@signature-input": ("@status" "content-digest")
]]></artwork>
          <t>From here, the signing process proceeds as usual.</t>
          <t>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.</t>

          <t>As discussed in <xref target="DIGEST"/>, target="RFC9530"/>, 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, which 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 <xref target="signature-multiple"/>.</t>
          <t>Applications that make use of the <xref target="content-request-response">request-response target="content-request-response"><tt>req</tt> parameter</xref> also need to be aware of the limitations in 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.</t>
        </section>
      </section>
      <section anchor="cryptographic-considerations">
        <name>Cryptographic Considerations</name>
        <section anchor="security-collision">
          <name>Cryptography and Signature Collision</name>
          <t>The HTTP Message Signatures specification
          <t>This document does not define any of its own cryptographic primitives, primitives and instead relies on other specifications to define such elements. If the signature algorithm or key used to process the signature base is vulnerable to any attacks, the resulting signature will also be susceptible to these same attacks.</t>
          <t>A common attack against signature systems is to force a signature collision, where the same signature value successfully verifies against multiple different inputs. Since this specification relies on reconstruction of the signature base from an HTTP message, message and the list of components signed is fixed in the signature, it is difficult but not impossible for an attacker to effect such a collision. An attacker would need to manipulate the HTTP message and its covered message components in order to make the collision effective.</t>
          <t>To counter this, only vetted keys and signature algorithms should be used to sign HTTP messages. The HTTP Message Signatures Algorithm Registry "HTTP Signature Algorithms" registry is one source of trusted signature algorithms for applications to apply to their messages.</t>
          <t>While it is possible for an attacker to substitute the signature parameters value or the signature value separately, the <xref target="create-sig-input">signature base generation algorithm</xref> always covers the signature parameters as the final value in the signature base using a deterministic serialization method. This step strongly binds the signature base with the signature value in a way that makes it much more difficult for an attacker to perform a partial substitution on the signature bases.</t> base.</t>
        </section>
        <section anchor="security-keys">
          <name>Key Theft</name>
          <t>A foundational assumption of signature-based cryptographic systems is that the signing key is not compromised by an attacker. If the keys used to sign the message are exfiltrated or stolen, the attacker will be able to generate their own signatures using those keys. As a consequence, signers have to protect any signing key material from exfiltration, capture, and use by an attacker.</t>
          <t>To combat this, signers can rotate keys over time to limit the amount of time that stolen keys are useful. Signers can also use key escrow and storage systems to limit the attack surface against keys. Furthermore, the use of asymmetric signing algorithms exposes key material less than the use of <xref target="security-symmetric">symmetric signing algorithms</xref>.</t>
        </section>
        <section anchor="security-symmetric">
          <name>Symmetric Cryptography</name>
          <t>The HTTP Message Signatures specification
          <t>This document allows for both asymmetric and symmetric cryptography to be applied to HTTP messages. By its their nature, symmetric cryptographic methods require the same key material to be known by both the signer and verifier. This effectively means that a verifier is capable of generating a valid signature, since they have access to the same key material. An attacker that is able to compromise a verifier would be able to then impersonate a signer.</t>
          <t>Where possible, asymmetric methods or secure key agreement mechanisms should be used in order to avoid this type of attack. When symmetric methods are used, distribution of the key material needs to be protected by the overall system. One technique for this is the use of separate cryptographic modules that separate the verification process (and therefore the key material) from other code, minimizing the vulnerable attack surface. Another technique is the use of key derivation functions that allow the signer and verifier to agree on unique keys for each message without having to share the key values directly.</t>
          <t>Additionally, if symmetric algorithms are allowed within a system, special care must be taken to avoid <xref target="security-keydowngrade">key downgrade attacks</xref>.</t>
        </section>
        <section anchor="security-keymixup">
          <name>Key Specification Mix-Up</name> Mixup</name>
          <t>The existence of a valid signature on an HTTP message is not sufficient to prove that the message has been signed by the appropriate party. It is up to the verifier to ensure that a given key and algorithm are appropriate for the message in question. If the verifier does not perform such a step, an attacker could substitute their own signature using their own key on a message and force a verifier to accept and process it. To combat this, the verifier needs to ensure that not only does that the signature validate can be validated for a message, message but that the key and algorithm used are appropriate.</t>
        </section>
        <section anchor="security-nondeterministic">
          <name>Non-deterministic Signature Primitives</name>
          <t>Some cryptographic primitives primitives, such as RSA PSS RSA-PSS and ECDSA ECDSA, have non-deterministic outputs, which include some amount of entropy within the algorithm. For such algorithms, multiple signatures generated in succession will not match. A lazy implementation of a verifier could ignore this distinction and simply check for the same value being created by re-signing the signature base. Such an implementation would work for deterministic algorithms such as HMAC and EdDSA but fail to verify valid signatures made using non-deterministic algorithms. It is therefore important that a verifier always use the correctly-defined correctly defined verification function for the algorithm in question and not do a simple comparison.</t>
        </section>
        <section anchor="security-keydowngrade">
          <name>Key and Algorithm Specification Downgrades</name>
          <t>Applications of this specification need to protect against key specification downgrade attacks. For example, the same RSA key can be used for both RSA-PSS and RSA v1.5 signatures. If an application expects a key to only be used with RSA-PSS, it needs to reject signatures for that any key using that uses the weaker RSA 1.5 specification.</t>
          <t>Another example of a downgrade attack occurs would be when an asymmetric algorithm is expected, such as RSA-PSS, but an attacker substitutes a signature using a symmetric algorithm, such as HMAC. A naive verifier implementation could use the value of the public RSA key as the input to the HMAC verification function. Since the public key is known to the attacker, this would allow the attacker to create a valid HMAC signature against this known key. To prevent this, the verifier needs to ensure that both the key material and the algorithm are appropriate for the usage in question. Additionally, while this specification does allow runtime specification of the algorithm using the <tt>alg</tt> signature parameter, applications are encouraged to use other mechanisms such as static configuration or higher protocol-level a higher-protocol-level algorithm specification instead, preventing an attacker from substituting the algorithm specified.</t>
        </section>
        <section anchor="security-sign-signature">
          <name>Signing Signature Values</name>
          <t>When applying the <xref target="content-request-response">request-response target="content-request-response"><tt>req</tt>
parameter</xref> or <xref target="signature-multiple">multiple signatures</xref> 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 <xref target="JACKSON2019"/> can be used to impersonate a signature output value on an unrelated message.</t>
          <t>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.</t>
          <ol spacing="normal" type="1"><li>Alice creates a message, message <tt>Req_A</tt> and applies a signature <tt>Sig_A</tt> using her private key <tt>Key_A_Sign</tt>.</li>
            <li>Alice believes she is sending <tt>Req_A</tt> to Bob.</li>
            <li>Mallory intercepts <tt>Req_A</tt> and reads the value <tt>Sig_A</tt> from this message.</li>
            <li>Mallory generates a different message <tt>Req_M</tt> to send to Bob instead.</li>
            <li>Mallory crafts a signing key <tt>Key_M_Sign</tt> such that she can create a valid signature <tt>Sig_M</tt> over her request <tt>Req_M</tt> using this key, but the byte value of <tt>Sig_M</tt> exactly equals that of <tt>Sig_A</tt>.</li>
            <li>Mallory sends <tt>Req_M</tt> with <tt>Sig_M</tt> to Bob.</li>
            <li>Bob validates <tt>Sig_M</tt> against Mallory's verification key, key <tt>Key_M_Verify</tt>. At no time does Bob think that he's responding to Alice.</li>
            <li>Bob responds with response message <tt>Res_B</tt> to <tt>Req_M</tt> and creates signature <tt>Sig_B</tt> over this message using his key, key <tt>Key_B_Sign</tt>. Bob includes the value of <tt>Sig_M</tt> under <tt>Sig_B</tt>'s covered components, components but nothing elese does not include anything else from the request message.</li>
            <li>Mallory receives the response <tt>Res_B</tt> from Bob, including the signature <tt>Sig_B</tt> value. Mallory replays this response to Alice.</li>
            <li>Alice reads <tt>Res_B</tt> from Mallory and verifies <tt>Sig_B</tt> using Bob's verification key, key <tt>Key_B_Verify</tt>. Alice includes the bytes of her original signature <tt>Sig_A</tt> in the signature base, and the signature verifies.</li>
            <li>Alice is led to believe that Bob has responded to her message, 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.</li>
          </ol>
          <t>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.</t>
        </section>
      </section>
      <section anchor="matching-covered-components-to-message">
        <name>Matching Covered Components Signature Parameters to the Target Message</name>
        <section anchor="security-modify">
          <name>Modification of Required Message Parameters</name>
          <t>An attacker could effectively deny a service by modifying an otherwise benign signature parameter or signed message component. While rejecting a modified message is the desired behavior, consistently failing signatures could lead to the (1)&nbsp;the verifier turning off signature checking in order to make systems work again (see <xref target="security-ignore"/>), target="security-ignore"/>) or to the (2)&nbsp;the application minimizing the requirements related to the signed component requirements.</t> component.</t>
          <t>If such failures are common within an application, the signer and verifier should compare their generated signature bases with each other to determine which part of the message is being modified. If an expected modification is found, the signer and verifier can agree on an alternative set of requirements that will pass. However, the signer and verifier should not remove the requirement to sign the modified component when it is suspected that an attacker is modifying the component.</t>
        </section>
        <section anchor="security-mismatch">
          <name>Mismatch
          <name>Matching Values of Signature Parameters from Covered Components to Values in the Target Message</name>
          <t>The verifier needs to make sure that the signed message components match those in the message itself. For example, the <tt>@method</tt> derived component requires that the value within the signature base be the same as the HTTP method used when presenting this message. This specification encourages this by requiring the verifier to derive the signature base from the message, but lazy caching or conveyance of a raw signature base to a processing subsystem could lead to downstream verifiers accepting a message that does not match the presented signature.</t>
          <t>To counter this, the component that generates the signature base needs to be trusted by both the signer and verifier within a system.</t>
        </section>
        <section anchor="security-message-component-context">
          <name>Message Component Source and Context</name>
          <t>The signature context for deriving message component values includes the target HTTP Message message itself, any associated messages (such as the request that triggered a response), and additional information that the signer or verifier has access to. Both signers and verifiers need to carefully consider the source of all information when creating component values for the signature base and take care not to take information from untrusted sources. Otherwise, an attacker could leverage such a loosely-defined loosely defined message context to inject their own values into the signature base string, overriding or corrupting the intended values.</t>
          <t>For example, in most situations, the target URI of the message is as defined in <xref section="7.1" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. However, let's say that there is an application that requires signing of the <tt>@authority</tt> of the incoming request, but the application doing the processing is behind a reverse proxy. Such an application would expect a change in the <tt>@authority</tt> value, and it could be configured to know the external target URI as seen by the client on the other side of the proxy. This application would use this configured value as its target URI for the purposes of deriving message component values such as <tt>@authority</tt> instead of using the target URI of the incoming message.</t>
          <t>This approach is not without problems, as a misconfigured system could accept signed requests intended for different components in the system. For this scenario, an intermediary could instead add its own signature to be verified by the application directly, as demonstrated in <xref target="signature-multiple"/>. This alternative approach requires a more active intermediary but relies less on the target application knowing external configuration values.</t>
          <t>For
          <t>As another example, <xref target="content-request-response"/> defines a method for signing response messages but and also including portions of the request message that triggered the response. In this case, the context for component value calculation is the combination of the response and request message, messages, not just the single message to which the signature is applied. For this feature, the <tt>req</tt> flag allows both signer signers to explicitly signal which part of the context is being sourced for a component identifier's value. Implementations need to ensure that only the intended message is being referred to for each component, otherwise component; otherwise, an attacker could attempt to subvert a signature by manipulating one side or the other.</t>
        </section>
        <section anchor="security-context-multiple-signatures">
          <name>Multiple Message Component Contexts</name>
          <t>It is possible that the context for deriving message component values could be distinct for each signature present within a single message. This is particularly the case when proxies mutate messages and include signatures over the mutated values, in addition to any existing signatures. For example, a reverse proxy can replace a public hostname in a request to a service with the hostname for the individual service host that to which it is forwarding the request on to. request. If both the client and the reverse proxy add signatures covering <tt>@authority</tt>, the service host will see two signatures on the request, each signing different values for the <tt>@authority</tt> message component, reflecting the change to that component as the message made its way from the client to the service host.</t>
          <t>In such a case, it's common for the internal service to verify only one of the signatures or to use externally-configured externally configured information, as discussed in <xref target="security-message-component-context"/>. However, a verifier processing both signatures has to use a different message component context for each signature, since the component value for the <tt>@authority</tt> component will be different for each signature. Verifiers like this need to be aware of both the reverse proxy's context for incoming messages as well as and the target service's context for the message coming from the reverse proxy. The verifier needs to take particular care to apply the correct context to the correct signature, otherwise signature; otherwise, an attacker could use knowledge of this complex setup to confuse the inputs to the verifier.</t>
          <t>Such verifiers also need to ensure that any differences in message component contexts between signatures are expected and permitted. For example, in the above scenario, the reverse proxy could include the original hostname in a <tt>Forwarded</tt> Forwarded header field, field and could sign <tt>@authority</tt>, <tt>forwarded</tt>, forwarded, and the client's entry in the <tt>signature</tt> Signature field. The verifier can use the hostname from the <tt>Forwarded</tt> Forwarded header field to confirm that the hostname was transformed as expected.</t>
        </section>
      </section>
      <section anchor="http-processing">
        <name>HTTP Processing</name>
        <section anchor="security-lazy-header-parser">
          <name>Confusing
          <name>Processing Invalid HTTP Field Names for as Derived Component Names</name>
          <t>The definition of HTTP field names does not allow for the use of the
<tt>@</tt> character anywhere in the name. As such, since all derived component names start with the <tt>@</tt> character, these namespaces should be completely separate. However, some HTTP implementations are not sufficiently strict about the characters accepted in HTTP field names. In such implementations, a sender (or attacker) could inject a header field starting with an <tt>@</tt> character and have it passed through to the application code. These invalid header fields could be used to override a portion of the derived message content and substitute an arbitrary value, providing a potential place for an attacker to mount a <xref target="security-collision">signature collision</xref> attack or other functional substitution attack (such as using the signature from a GET request on a crafted POST request).</t>
          <t>To combat this, when selecting values for a message component, if the component name starts with the <tt>@</tt> character, it needs to be processed as a derived component and never taken processed as a fields. an HTTP field. Only if the component name does not start with the <tt>@</tt> character can it be taken from the fields of the message. The algorithm discussed in <xref target="create-sig-input"/> provides a safe order of operations.</t>
        </section>
        <section anchor="security-field-values">
          <name>Semantically Equivalent Field Values</name>
          <t>The <xref target="create-sig-input">signature base generation algorithm</xref> uses the value of an HTTP field as its component value. In the common case, this amounts to taking the actual bytes of the field value as the component value for both the signer and verifier. However, some field values allow for transformation of the values in semantically equivalent ways that alter the bytes used in the value itself. For example, a field definition can declare some or all of its value values to be case-insensitive, case insensitive or to have special handling of internal whitespace characters. Other fields have expected transformations from intermediaries, such as the removal of comments in the <tt>Via</tt> Via header field. In such cases, a verifier could be tripped up by using the equivalent transformed field value, which would differ from the byte value used by the signer. The verifier would have a difficult time finding this class of errors errors, since the value of the field is still acceptable for the application, application but the actual bytes required by the signature base would not match.</t>
          <t>When processing such fields, the signer and verifier have to agree on how to handle such transformations, if at all. One option is to not sign problematic fields, but care must be taken to ensure that there is still <xref target="security-coverage">sufficient signature coverage</xref> for the application. Another option is to define an application-specific canonicalization value for the field before it is added to the HTTP message, such as to always remove internal comments before signing, signing or to always transform values to lowercase. Since these transformations are applied prior to the field being used as input to the signature base generation algorithm, the signature base will still simply contain the byte value of the field as it appears within the message. If the transformations were to be applied after the value is extracted from the message but before it is added to the signature base, different attack surfaces such as value substitution attacks could be launched against the application. All application-specific additional rules are outside the scope of this specification, and by their very nature these transformations would harm interoperability of the implementation outside of this specific application. It is recommended that applications avoid the use of such additional rules wherever possible.</t>
        </section>
        <section anchor="security-structured">
          <name>Parsing Structured Field Values</name>
          <t>Several parts of this specification rely on the parsing of structured field Structured Field values <xref target="STRUCTURED-FIELDS"/>. In target="RFC8941"/> -- in particular, <xref target="http-field-structured">normalization target="http-field-structured">strict serialization of HTTP structured field Structured Field values</xref>, <xref target="http-field-dictionary">referencing members of a dictionary structured field</xref>, Dictionary Structured Field</xref>, and processing the <tt>@signature-input</tt> value when <xref target="verify">verifying a signature</xref>. While structured field Structured Field values are designed to be relatively simple to parse, a naive or broken implementation of such a parser could lead to subtle attack surfaces being exposed in the implementation.</t>
          <t>For example, if a buggy parser of the <tt>@signature-input</tt> value does not enforce proper closing of quotes around string values within the list of component identifiers, an attacker could take advantage of this and inject additional content into the signature base through manipulating the Signature-Input field value on a message.</t>
          <t>To counteract this, implementations should use fully compliant and trusted parsers for all structured field Structured Field processing, both on both the signer side and the verifier side.</t>
        </section>
        <section anchor="security-versions">
          <name>HTTP Versions and Component Ambiguity</name>
          <t>Some message components are expressed in different ways across HTTP versions. For example, the authority of the request target is sent using the <tt>Host</tt> Host header field in HTTP/1.1 but with the <tt>:authority</tt> pseudo-header in HTTP/2. If a signer sends an HTTP/1.1 message and signs the <tt>Host</tt> field, Host header field but the message is translated to HTTP/2 before it reaches the verifier, the signature will not validate validate, as the <tt>Host</tt> Host header field could be dropped.</t>
          <t>It is for this reason that HTTP Message Signatures defines message signatures define a set of derived components that define a single way to get the value in question, such as the <tt>@authority</tt> derived component (<xref target="content-request-authority"/>) in lieu of the <tt>Host</tt> Host header field. Applications should therefore prefer derived components for such options where possible.</t>
        </section>
        <section anchor="security-canonicalization">
          <name>Canonicalization Attacks</name>
          <t>Any ambiguity in the generation of the signature base could provide an attacker with leverage to substitute or break a signature on a message. Some message component values, particularly HTTP field values, are potentially susceptible to broken implementations that could lead to unexpected and insecure behavior. Naive implementations of this specification might implement HTTP field processing by taking the single value of a field and using it as the direct component value without processing it appropriately.</t>
          <t>For example, if the handling of <tt>obs-fold</tt> field values does not remove the internal line folding and whitespace, additional newlines could be introduced into the signature base by the signer, providing a potential place for an attacker to mount a <xref target="security-collision">signature collision</xref> attack. Alternatively, if header fields that appear multiple times are not joined into a single string value, as is required by this specification, similar attacks can be mounted mounted, as a signed component value would show up in the signature base more than once and could be substituted or otherwise attacked in this way.</t>
          <t>To counter this, the entire field value processing algorithm needs to be implemented by all implementations of signers and verifiers.</t>
        </section>
        <section anchor="security-non-list">
          <name>Non-List Field Values</name>
          <t>When an HTTP field occurs multiple times in a single message, these values need to be combined into a single one-line string value to be included in the HTTP signature base, as described in <xref target="create-sig-input"/>. Not all HTTP fields can be combined into a single value in this way and still be a valid value for the field. For the purposes of generating the signature base, the message component value is never meant to be read back out of the signature base string or used in the application. Therefore Therefore, it is considered best practice to treat the signature base generation algorithm separately from processing the field values by the application, particularly for fields that are known to have this property. If the field values that are being signed do not validate, the signed message should also be rejected.</t>
          <t>If an HTTP field allows for unquoted commas within its values, combining multiple field values can lead to a situation where two semantically different messages produce the same line in a signature base. For example, take the following hypothetical header field with an internal comma in its syntax, here used to define two separate lists of values:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots
Example-Header: of, commas
]]></sourcecode>
          <t>For this header field, sending all of these values as a single field value results in a single list of values:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots, of, commas
]]></sourcecode>
          <t>Both of these messages would create the following line in the signature base:</t>
          <artwork><![CDATA[
"example-header": value, with, lots, of, commas
]]></artwork>
          <t>Since two semantically distinct inputs can create the same output in the signature base, special care has to be taken when handling such values.</t>
          <t>Specifically, the Set-Cookie field <xref target="COOKIE"/> target="RFC6265"/> defines an internal syntax that does not conform to the List syntax provided in <xref target="STRUCTURED-FIELDS"/>. target="RFC8941"/>. In particular particular, some portions allow unquoted commas, and the field is typically sent as multiple separate field lines with distinct values when sending multiple cookies. When multiple Set-Cookie fields are sent in the same message, it is not generally possible to combine these into a single line and be able to parse and use the results, as discussed in <xref section="5.3" sectionFormat="comma" target="HTTP"/>. target="RFC9110"/>. Therefore, all the cookies need to be processed from their separate header field values, without being combined, while the signature base needs to be processed from the special combined value generated solely for this purpose. If the cookie value is invalid, the signed message ought to be rejected rejected, as this is a possible padding attack as described in <xref target="security-multiple-fields"/>.</t>
          <t>To deal with this, an application can choose to limit signing of problematic fields like Set-Cookie, such as including the field in a signature only when a single field value is present and the results would be unambiguous. Similar caution needs to be taken with all fields that could have non-deterministic mappings into the signature base. Signers can also make use of the <tt>bs</tt> parameter to armor such fields, as described in <xref target="http-field-byte-sequence"/>.</t>
        </section>
        <section anchor="security-multiple-fields">
          <name>Padding Attacks with Multiple Field Values</name>
          <t>Since HTTP field values need to be combined in into a single string value to be included in the HTTP signature base, as described in base (see <xref target="create-sig-input"/>, target="create-sig-input"/>), it is possible for an attacker to inject an additional value for a given field and add this to the signature base of the verifier.</t>
          <t>In most circumstances, this causes the signature validation to fail as expected, since the new signature base value will not match the one used by the signer to create the signature. However, it is theoretically possible for the attacker to inject both a garbage value to into a field and a desired value to into another field in order to force a particular input. This is a variation of the collision attack described in <xref target="security-collision"/>, where the attacker accomplishes their change in the message by adding to existing field values.</t>
          <t>To counter this, an application needs to validate the content of the fields covered in the signature in addition to ensuring that the signature itself validates. With such protections, the attacker's padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision.</t>
        </section>
        <section anchor="security-query-elements">
          <name>Ambiguous Handling of Query Elements</name>
          <t>The HTML form parameters format defined in the "application/x-www-form-urlencoded" section Section&nbsp;<xref target="HTMLURL" section="5" relative="https://url.spec.whatwg.org/#application/x-www-form-urlencoded"
sectionFormat="bare">"application/x-www-form-urlencoded"</xref> of
<xref target="HTMLURL"/>, target="HTMLURL"/> is widely deployed and supported by many application frameworks. For convenience, some of these frameworks in particular combine query parameters that are found in the HTTP query and those found in the message content, particularly for POST message messages with a Content-Type value of "application/x-www-form-urlencoded". The <tt>@query-param</tt> derived component identifier defined in <xref target="content-request-query-param"/> draws its values only from the query section of the target URI of the request. As such, it would be possible for an attacker to shadow or replace query parameters in a request by overriding the a signed query parameter with an unsigned form parameter, or vice versa.</t>
          <t>To counter this, an application needs to make sure that values used for the signature base and the application are drawn from a consistent context, in this case the query component of the target URI. Additionally, when the HTTP request has content, an application should sign the message content as well, as discussed in <xref target="security-message-content"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="privacy">
      <name>Privacy Considerations</name>
      <section anchor="privacy-identify-keys">
        <name>Identification through Keys</name>
        <t>If a signer uses the same key with multiple verifiers, verifiers or uses the same key over time with a single verifier, the ongoing use of that key can be used to track the signer throughout the set of verifiers that messages are sent to. Since cryptographic keys are meant to be functionally unique, the use of the same key over time is a strong indicator that it is the same party signing multiple messages.</t>
        <t>In many applications, this is a desirable trait, and it allows HTTP Message Signatures message signatures to be used as part of authenticating the signer to the verifier. However, it could be also result in unintentional tracking that a signer might not be aware of. To counter this kind of tracking, a signer can use a different key for each verifier that it is in communication with. Sometimes, a signer could also rotate their key when sending messages to a given verifier. These approaches do not negate the need for other anti-tracking techniques to be applied as necessary.</t>
      </section>
      <section anchor="privacy-confidentiality">
        <name>Signatures do not provide confidentiality</name>
        <t>HTTP Message Signatures message signatures do not provide confidentiality of for any of the information protected by the signature. The content of the HTTP message, including the value of all fields and the value of the signature itself, is presented in plaintext to any party with access to the message.</t>
        <t>To provide confidentiality at the transport level, TLS or its equivalent can be used used, as discussed in <xref target="security-tls"/>.</t>
      </section>
      <section anchor="privacy-oracle">
        <name>Oracles</name>
        <t>It is important to balance the need for providing useful feedback to developers on regarding error conditions without providing additional information to an attacker. For example, a naive but helpful server implementation might try to indicate the required key identifier needed for requesting a resource. If someone knows who controls that key, a correlation can be made between the resource's existence and the party identified by the key. Access to such information could be used by an attacker as a means to target the legitimate owner of the resource for further attacks.</t>
      </section>
      <section anchor="privacy-required">
        <name>Required Content</name>
        <t>A core design tenet of this specification is that all message components covered by the signature need to be available to the verifier in order to recreate the signature base and verify the signature. As a consequence, if an application of this specification requires that a particular field be signed, the verifier will need access to the value of that field.</t>
        <t>For example, in some complex systems with intermediary processors processors, this could cause the surprising behavior where, for fear of breaking the signature, an intermediary not being able to cannot remove privacy-sensitive information from a message before forwarding it on for processing, for fear of breaking the signature. A possible mitigation for processing. One way to mitigate this specific situation would be for the intermediary to verify the signature itself, itself and then modify the message to remove the privacy-sensitive information. The intermediary can add its own signature at this point to signal to the next destination that the incoming signature was validated, as is shown in the example in <xref target="signature-multiple"/>.</t>
      </section>
    </section>
  </middle>
  <back>

    <displayreference target="POSIX" to="POSIX.1"/>
    <displayreference target="HTTP1" target="RFC0020" to="ASCII"/>
    <displayreference target="RFC8941" to="STRUCTURED-FIELDS"/>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC9112" to="HTTP/1.1"/>
    <displayreference target="RFC3986" to="URI"/>
    <displayreference target="RFC5234" to="ABNF"/>
    <displayreference target="RFC7515" to="JWS"/>
    <displayreference target="RFC9440" to="CLIENT-CERT"/>
    <displayreference target="RFC6265" to="COOKIE"/>
    <displayreference target="RFC8446" to="TLS"/>
    <displayreference target="RFC9530" to="DIGEST"/>
    <displayreference target="I-D.cavage-http-signatures" to="SIGNING-HTTP-MESSAGES"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8941.xml"/>

        <reference anchor="ASCII">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>
        <reference anchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2104"/>
          <seriesInfo name="DOI" value="10.17487/RFC2104"/>
        </reference>
        <reference anchor="RFC6234">
          <front>
            <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="May" year="2011"/>
            <abstract>
              <t>Federal Information Processing Standard, FIPS</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6234"/>
          <seriesInfo name="DOI" value="10.17487/RFC6234"/>
        </reference>
        <reference anchor="RFC7517">
          <front>
            <title>JSON Web Key (JWK)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7517"/>
          <seriesInfo name="DOI" value="10.17487/RFC7517"/>
        </reference>
        <reference anchor="RFC7518">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7518"/>
          <seriesInfo name="DOI" value="10.17487/RFC7518"/>
        </reference>
        <reference anchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
            <author fullname="A. Rusch" initials="A." surname="Rusch"/>
            <date month="November" year="2016"/>
            <abstract>
              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
              <t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t>
              <t>This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8017"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/>
        </reference>
        <reference anchor="RFC8032">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8032"/>
          <seriesInfo name="DOI" value="10.17487/RFC8032"/>
        </reference>
        <reference anchor="STRUCTURED-FIELDS">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8941"/>
          <seriesInfo name="DOI" value="10.17487/RFC8941"/>
        </reference>
        <reference anchor="FIPS186-4" target="https://csrc.nist.gov/publications/detail/fips/186/4/final"> anchor="FIPS186-5" target="https://doi.org/10.6028/NIST.FIPS.186-5">
          <front>
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date year="2013"/> month="February" year="2023"/>
          </front>
         <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
        </reference>
        <reference anchor="POSIX" target="https://pubs.opengroup.org/onlinepubs/9699919799/">
          <front>
            <title>The Open Group Base Specifications Issue 7, 2018 edition</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date year="2018"/>
          </front>
        </reference>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="HTTP1">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t>This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="URI">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>

        <reference anchor="HTMLURL" target="https://url.spec.whatwg.org/#application/x-www-form-urlencoded"> target="https://url.spec.whatwg.org/">
          <front>
            <title>URL (Living Standard)</title>
            <author>
              <organization/>
              <organization>WHATWG</organization>
            </author>
            <date year="2021"/>
          </front>
        </reference>
        <reference anchor="ABNF">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract> year="2024"/>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7239">
          <front>
            <title>Forwarded HTTP Extension</title>
            <author fullname="A. Petersson" initials="A." surname="Petersson"/>
            <author fullname="M. Nilsson" initials="M." surname="Nilsson"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.</t>
              <t>This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7239"/>
          <seriesInfo name="DOI" value="10.17487/RFC7239"/>
        </reference>
        <reference anchor="JWS">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC7807">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <date month="March" year="2016"/>
            <abstract>
              <t>This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7807"/>
          <seriesInfo name="DOI" value="10.17487/RFC7807"/>
        </reference>
        <reference anchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7239.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7807.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9457.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>

        <referencegroup anchor="BCP195">
          <reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8996">
            <front>
              <title>Deprecating TLS 1.0 and TLS 1.1</title>
              <author fullname="K. Moriarty" initials="K." surname="Moriarty"/>
              <author fullname="S. Farrell" initials="S." surname="Farrell"/>
              <date month="March" year="2021"/>
              <abstract>
                <t>This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.</t>
                <t>This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
                <t>This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="8996"/>
            <seriesInfo name="DOI" value="10.17487/RFC8996"/>
          </reference>
          <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325">
            <front>
              <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
              <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
              <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
              <author fullname="T. Fossati" initials="T." surname="Fossati"/>
              <date month="November" year="2022"/>
              <abstract>
                <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
                <t>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="9325"/>
            <seriesInfo name="DOI" value="10.17487/RFC9325"/>
          </reference> anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

        </referencegroup>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9440.xml"/>

<!-- draft-ietf-httpbis-digest-headers (RFC 9530; AUTH48-DONE) -->
<reference anchor="CLIENT-CERT">
          <front>
            <title>Client-Cert HTTP Header Field</title>
            <author fullname="B. Campbell" initials="B." surname="Campbell"/>
            <author fullname="M. Bishop" initials="M." surname="Bishop"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9440"/>
          <seriesInfo name="DOI" value="10.17487/RFC9440"/>
        </reference>
        <reference anchor="DIGEST"> anchor="RFC9530"  target="https://www.rfc-editor.org/info/rfc9530">
   <front>
      <title>Digest Fields</title>
      <author fullname="Roberto Polli" initials="R." surname="Polli"> surname="Polli" fullname="Roberto Polli">
         <organization>Team Digitale, Italian Government</organization>
      </author>
      <author fullname="Lucas Pardue" initials="L." surname="Pardue"> surname="Pardue" fullname="Lucas Pardue">
         <organization>Cloudflare</organization>
      </author>
      <date day="10" month="July" year="2023"/>
            <abstract>
              <t>   This document defines HTTP fields that support integrity digests.
   The Content-Digest field can be used for the integrity of HTTP
   message content.  The Repr-Digest field can be used for the integrity
   of HTTP representations.  Want-Content-Digest and Want-Repr-Digest
   can be used to indicate a sender's interest and preferences for
   receiving the respective Integrity fields.

   This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP
   fields.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-digest-headers-13"/>
        </reference>
        <reference anchor="COOKIE">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]</t>
            </abstract> month="February" year="2024" />
   </front>
   <seriesInfo name="RFC" value="6265"/> value="9530"/>
   <seriesInfo name="DOI" value="10.17487/RFC6265"/> value="10.17487/RFC9530"/>
</reference>
        <reference anchor="I-D.cavage-http-signatures">
          <front>
            <title>Signing HTTP Messages</title>
            <author fullname="Mark Cavage" initials="M." surname="Cavage">
              <organization>Oracle</organization>
            </author>
            <author fullname="Manu Sporny" initials="M." surname="Sporny">
              <organization>Digital Bazaar</organization>
            </author>
            <date day="21" month="October" year="2019"/>
            <abstract>
              <t>   When communicating over the Internet using the HTTP protocol, it can
   be desirable for a server or client

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>

<!-- draft-cavage-http-signatures Replaced by
     draft-ietf-httpbis-message-signatures.
     (This doc. makes specific reference to authenticate the sender of a
   particular message.  It can also be desirable draft-cavage-http-signatures,
     so need to ensure that also list the
   message was not tampered with during transit.  This document
   describes a way for servers and clients to simultaneously add
   authentication and message integrity older version.) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.cavage-http-signatures.xml"/>

<!-- draft-ietf-oauth-signed-http-request (Expired)
     Have to HTTP messages by using a
   digital signature.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-cavage-http-signatures-12"/>
        </reference> do long way; one author is also editor. -->
<reference anchor="I-D.ietf-oauth-signed-http-request"> anchor="SIGNING-HTTP-REQS-OAUTH">
   <front>
      <title>A Method for Signing HTTP Requests for OAuth</title>
      <author initials="J." surname="Richer" fullname="Justin Richer" initials="J." surname="Richer"> role="editor">
         </author>
      <author fullname="John Bradley" initials="J." surname="Bradley"> surname="Bradley" fullname="John Bradley">
         <organization>Ping Identity</organization>
      </author>
      <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"> surname="Tschofenig" fullname="Hannes Tschofenig">
         <organization>ARM Limited</organization>
      </author>
      <date day="8" month="August" year="2016"/>
            <abstract>
              <t>   This document a method for offering data origin authentication and
   integrity protection of HTTP requests.  To convey the relevant data
   items in the request a JSON-based encapsulation is used and the JSON
   Web Signature (JWS) technique is re-used.  JWS offers integrity
   protection using symmetric as well as asymmetric cryptography.

              </t>
            </abstract> day="8" year="2016" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-oauth-signed-http-request-03"/> value="draft-ietf-oauth-signed-http-request-03" />
</reference>

        <reference anchor="AWS-SIGv4" target="https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html">
          <front>
            <title>Authenticating Requests (AWS Signature Version 4)</title>
            <author>
              <organization/>
              <organization>Amazon Simple Storage Service</organization>
            </author>
            <date>n.d.</date>
            <date month="March" year="2006"/>
          </front>
        </reference>

        <reference anchor="JACKSON2019" target="https://dennis-jackson.uk/assets/pdfs/signatures.pdf"> target="https://dl.acm.org/doi/10.1145/3319535.3339813">
          <front>
            <title>Seems Legit: Automated Analysis of Subtle Attacks on Protocols that Use Signatures</title>
            <author initials="D." surname="Jackson" fullname="Dennis Jackson">
              <organization>University of Oxford</organization>
            </author>
            <author initials="C." surname="Cremers" fullname="Cas Cremers">
              <organization>CISPA Helmholtz Center for Information Security</organization>
            </author>
            <author initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-Gordon">
              <organization>Independent Scholar</organization>
            </author>
            <author initials="R." surname="Sasse" fullname="Ralf Sasse">
              <organization>Department of Computer Science, ETH Zurich</organization>
            </author>
            <date year="2019" month="November"/>
          </front>
        </reference>
        <reference anchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation value="10.1145/3319535.3339813"/>
        <refcontent>CCS '19: Proceedings of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear 2019 ACM SIGSAC Conference on Computer and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/> Communications Security, pp. 2165-2180</refcontent>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7468.xml"/>
      </references>
    </references>
    <?line 2284?>

<section anchor="detection">
      <name>Detecting HTTP Message Signatures</name>
      <t>There have been many attempts to create signed HTTP messages in the past, including other non-standardized definitions of the Signature field, which field that is used within this specification. It is recommended that developers wishing to support both this specification and specification, other published documents, or other historical drafts do so carefully and deliberately, as incompatibilities between this specification and other documents or various versions of other drafts could lead to unexpected problems.</t>
      <t>It is recommended that implementers implementors first detect and validate the Signature-Input field defined in this specification to detect that the mechanism described in this standard document is in use and not an alternative. If the Signature-Input field is present, all Signature fields can be parsed and interpreted in the context of this specification.</t>
    </section>
    <section anchor="examples">
      <name>Examples</name>
      <t>The following non-normative examples are provided as a means of testing implementations of HTTP Message Signatures. message signatures. The signed messages given can be used to create the signature base with the stated parameters, creating signatures using the stated algorithms and keys.</t>
      <t>The private keys given can be used to generate signatures, though since several of the demonstrated algorithms are nondeterministic, non-deterministic, the results of a signature are expected to be different from the exact bytes of the examples. The public keys given can be used to validate all signed examples.</t>
      <section anchor="example-keys">
        <name>Example Keys</name>
        <t>This section provides cryptographic keys that are referenced in example signatures throughout this document. These keys <bcp14>MUST NOT</bcp14> be used for any purpose other than testing.</t>
        <t>The key identifiers for each key are used throughout the examples in this specification. It is assumed for these examples that the signer and verifier can unambiguously dereference all key identifiers used here, here and that the keys and algorithms used are appropriate for the context in which the signature is presented.</t>
        <t>The components for each private key key, in PEM format <xref target="RFC7468"/>, can be displayed by executing the following OpenSSL command:</t>
        <artwork><![CDATA[
openssl pkey -text
]]></artwork>
        <t>This command was tested with all the example keys on OpenSSL version 1.1.1m. Note that some systems cannot produce or use all of these keys directly, directly and may require additional processing. All keys are also made available in JWK format.</t>
        <section anchor="example-key-rsa-test">
          <name>Example Key RSA test</name> Key</name>
          <t>The following key is a 2048-bit RSA public and private key pair, referred to in this document
as <tt>test-key-rsa</tt>. This key is encoded in PEM Format, format, with no encryption.</t>
          <artwork><![CDATA[
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw
WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq
MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg
kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P
uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ
PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB
-----END RSA PUBLIC KEY-----

-----BEGIN RSA PRIVATE KEY-----
MIIEqAIBAAKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsP
BRrwWEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsd
JKFqMGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75
jfZgkne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKI
lE0PuKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZ
SFlQPSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQABAoIBAG/JZuSWdoVHbi56
vjgCgkjg3lkO1KrO3nrdm6nrgA9P9qaPjxuKoWaKO1cBQlE1pSWp/cKncYgD5WxE
CpAnRUXG2pG4zdkzCYzAh1i+c34L6oZoHsirK6oNcEnHveydfzJL5934egm6p8DW
+m1RQ70yUt4uRc0YSor+q1LGJvGQHReF0WmJBZHrhz5e63Pq7lE0gIwuBqL8SMaA
yRXtK+JGxZpImTq+NHvEWWCu09SCq0r838ceQI55SvzmTkwqtC+8AT2zFviMZkKR
Qo6SPsrqItxZWRty2izawTF0Bf5S2VAx7O+6t3wBsQ1sLptoSgX3QblELY5asI0J
YFz7LJECgYkAsqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOM
cCNq8SyYbTqgnWlB9ZfcAm/cFpA8tYci9m5vYK8HNxQr+8FS3Qo8N9RJ8d0U5Csw
DzMYfRghAfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1
mwJ5AL0pYF0G7x81prlARURwHo0Yf52kEw1dxpx+JXER7hQRWQki5/NsUEtv+8RT
qn2m6qte5DXLyn83b1qRscSdnCCwKtKWUug5q2ZbwVOCJCtmRwmnP131lWRYfj67
B/xJ1ZA6X3GEf4sNReNAtaucPEelgR2nsN0gKQKBiGoqHWbK1qYvBxX2X3kbPDkv
9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn
f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo
81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa
/2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG
IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m
qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P
WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ
EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0=
-----END RSA PRIVATE KEY-----
]]></artwork>
          <t>The same public and private keypair key pair in JWK format:</t>
          <sourcecode type="json"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

{
  "kty": "RSA",
  "kid": "test-key-rsa",
  "p": "sqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOMcCNq8Sy\
  YbTqgnWlB9ZfcAm_cFpA8tYci9m5vYK8HNxQr-8FS3Qo8N9RJ8d0U5CswDzMYfRgh\
  AfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1mw",
  "q": "vSlgXQbvHzWmuUBFRHAejRh_naQTDV3GnH4lcRHuFBFZCSLn82xQS2_7xFO\
  qfabqq17kNcvKfzdvWpGxxJ2cILAq0pZS6DmrZlvBU4IkK2ZHCac_XfWVZFh-PrsH\
  _EnVkDpfcYR_iw1F40C1q5w8R6WBHaew3SAp",
  "d": "b8lm5JZ2hUduLnq-OAKCSODeWQ7Uqs7eet2bqeuAD0_2po-PG4qhZoo7VwF\
  CUTWlJan9wqdxiAPlbEQKkCdFRcbakbjN2TMJjMCHWL5zfgvqhmgeyKsrqg1wSce9\
  7J1_Mkvn3fh6CbqnwNb6bVFDvTJS3i5FzRhKiv6rUsYm8ZAdF4XRaYkFkeuHPl7rc\
  -ruUTSAjC4GovxIxoDJFe0r4kbFmkiZOr40e8RZYK7T1IKrSvzfxx5AjnlK_OZOTC\
  q0L7wBPbMW-IxmQpFCjpI-yuoi3FlZG3LaLNrBMXQF_lLZUDHs77q3fAGxDWwum2h\
  KBfdBuUQtjlqwjQlgXPsskQ",
  "e": "AQAB",
  "qi": "PkbARLOwU_LcZrQy9mmfcPoQlAuCyeu1Q9nH7PYSnbHTFzmiud4Hl8bIXU\
  9a0_58blDoOl3PctF-b4rAEJYUpCODu5PFyN6uEFYRg-YQwpjBMkXk8Eb39128ctA\
  RB40Lx8caDhRdTyaEedIG3cQDXSpAl9EOzXkzfx4bZxjAHU9mkMdJwOcMDQ",
  "dp": "aiodZsrWpi8HFfZfeRs8OS_0L5x6WBl3Y9btoZgsIeruc9uZ8NXTIdxaM6\
  FdnyNEyOYA1VH94tDYR-xEt1br1ud_dkPslLV_Aac7d7EaYc7cdkb7oC9t6sphVg0\
  dqE0UTDlOwBxBYMtGmQbJsFzGpmjzVgKqWqJ3B947li2U7t63HXEvKprY2w",
  "dq": "b0DzpSMb5p42dcQgOTU8Mr4S6JOEhRr_YjErMkpaXUEqvZ3jEB9HRmcRi5\
  Gtt4NBiBMiY6V9br8a5gjEpiAQoIUcWokBMAYjEeurU8M6JLBd3YaZVVjISaFmdty\
  nwLFoQxCh6_EC1rSywwrfDpSwO29S9i8Xbaap",
  "n": "hAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrwWEBnez6\
  d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFqMGmXCQvE\
  G7YemcxDTRPxAleIAgYYRjTSd_QBwVW9OwNFhekro3RtlinV0a75jfZgkne_YiktS\
  vLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0PuKxI4T-HIa\
  Fpv8-rdV6eUgOrB2xeI1dSFFn_nnv5OoZJEIB-VmuKn3DCUcCZSFlQPSXSfBDiUGh\
  wOw76WuSSsf1D4b_vLoJ10w"
}
]]></sourcecode>
        </section>
        <section anchor="example-key-rsa-pss-test">
          <name>Example RSA PSS RSA-PSS Key</name>
          <t>The following key is a 2048-bit RSA public and private key pair, referred to in this document
as <tt>test-key-rsa-pss</tt>. This key is PCKS#8 PKCS #8 encoded in PEM format, with no encryption.</t>
          <artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4tmm3r20Wd/PbqvP1s2
+QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct+Lh1GH45x28Rw3Ry53mm+
oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7OyrFAHq
gDsznjPFmTOtCEcN2Z1FpWgchwuYLPL+Wokqltd11nqqzi+bJ9cvSKADYdUAAN5W
Utzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw9lq4
aOT9v6d+nb4bnNkQVklLQ3fVAvJm+xdDOp9LCNCN48V2pnDOkFV6+U9nV5oyc6XI
2wIDAQAB
-----END PUBLIC KEY-----

-----BEGIN PRIVATE KEY-----
MIIEvgIBADALBgkqhkiG9w0BAQoEggSqMIIEpgIBAAKCAQEAr4tmm3r20Wd/Pbqv
P1s2+QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct+Lh1GH45x28Rw3Ry5
3mm+oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7Oyr
FAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL+Wokqltd11nqqzi+bJ9cvSKADYdUA
AN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw
9lq4aOT9v6d+nb4bnNkQVklLQ3fVAvJm+xdDOp9LCNCN48V2pnDOkFV6+U9nV5oy
c6XI2wIDAQABAoIBAQCUB8ip+kJiiZVKF8AqfB/aUP0jTAqOQewK1kKJ/iQCXBCq
pbo360gvdt05H5VZ/RDVkEgO2k73VSsbulqezKs8RFs2tEmU+JgTI9MeQJPWcP6X
aKy6LIYs0E2cWgp8GADgoBs8llBq0UhX0KffglIeek3n7Z6Gt4YFge2TAcW2WbN4
XfK7lupFyo6HHyWRiYHMMARQXLJeOSdTn5aMBP0PO4bQyk5ORxTUSeOciPJUFktQ
HkvGbym7KryEfwH8Tks0L7WhzyP60PL3xS9FNOJi9m+zztwYIXGDQuKM2GDsITeD
2mI2oHoPMyAD0wdI7BwSVW18p1h+jgfc4dlexKYRAoGBAOVfuiEiOchGghV5vn5N
RDNscAFnpHj1QgMr6/UG05RTgmcLfVsI1I4bSkbrIuVKviGGf7atlkROALOG/xRx
DLadgBEeNyHL5lz6ihQaFJLVQ0u3U4SB67J0YtVO3R6lXcIjBDHuY8SjYJ7Ci6Z6
vuDcoaEujnlrtUhaMxvSfcUJAoGBAMPsCHXte1uWNAqYad2WdLjPDlKtQJK1diCm
rqmB2g8QE99hDOHItjDBEdpyFBKOIP+NpVtM2KLhRajjcL9Ph8jrID6XUqikQuVi
4J9FV2m42jXMuioTT13idAILanYg8D3idvy/3isDVkON0X3UAVKrgMEne0hJpkPL
FYqgetvDAoGBAKLQ6JZMbSe0pPIJkSamQhsehgL5Rs51iX4m1z7+sYFAJfhvN3Q/
OGIHDRp6HjMUcxHpHw7U+S1TETxePwKLnLKj6hw8jnX2/nZRgWHzgVcY+sPsReRx
NJVf+Cfh6yOtznfX00p+JWOXdSY8glSSHJwRAMog+hFGW1AYdt7w80XBAoGBAImR
NUugqapgaEA8TrFxkJmngXYaAqpA0iYRA7kv3S4QavPBUGtFJHBNULzitydkNtVZ
3w6hgce0h9YThTo/nKc+OZDZbgfN9s7cQ75x0PQCAO4fx2P91Q+mDzDUVTeG30mE
t2m3S0dGe47JiJxifV9P3wNBNrZGSIF3mrORBVNDAoGBAI0QKn2Iv7Sgo4T/XjND
dl2kZTXqGAk8dOhpUiw/HdM3OGWbhHj2NdCzBliOmPyQtAr770GITWvbAI+IRYyF
S7Fnk6ZVVVHsxjtaHy1uJGFlaZzKR4AGNaUTOJMs6NadzCmGPAxNQQOCqoUjn4XR
rOjr9w349JooGXhOxbu8nOxX
-----END PRIVATE KEY-----
]]></artwork>
          <t>The same public and private keypair key pair in JWK format:</t>
          <sourcecode type="json"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

{
  "kty": "RSA",
  "kid": "test-key-rsa-pss",
  "p": "5V-6ISI5yEaCFXm-fk1EM2xwAWekePVCAyvr9QbTlFOCZwt9WwjUjhtKRus\
  i5Uq-IYZ_tq2WRE4As4b_FHEMtp2AER43IcvmXPqKFBoUktVDS7dThIHrsnRi1U7d\
  HqVdwiMEMe5jxKNgnsKLpnq-4NyhoS6OeWu1SFozG9J9xQk",
  "q": "w-wIde17W5Y0Cphp3ZZ0uM8OUq1AkrV2IKauqYHaDxAT32EM4ci2MMER2nI\
  UEo4g_42lW0zYouFFqONwv0-HyOsgPpdSqKRC5WLgn0VXabjaNcy6KhNPXeJ0Agtq\
  diDwPeJ2_L_eKwNWQ43RfdQBUquAwSd7SEmmQ8sViqB628M",
  "d": "lAfIqfpCYomVShfAKnwf2lD9I0wKjkHsCtZCif4kAlwQqqW6N-tIL3bdOR-\
  VWf0Q1ZBIDtpO91UrG7pansyrPERbNrRJlPiYEyPTHkCT1nD-l2isuiyGLNBNnFoK\
  fBgA4KAbPJZQatFIV9Cn34JSHnpN5-2ehreGBYHtkwHFtlmzeF3yu5bqRcqOhx8lk\
  YmBzDAEUFyyXjknU5-WjAT9DzuG0MpOTkcU1EnjnIjyVBZLUB5Lxm8puyq8hH8B_E\
  5LNC-1oc8j-tDy98UvRTTiYvZvs87cGCFxg0LijNhg7CE3g9piNqB6DzMgA9MHSOw\
  cElVtfKdYfo4H3OHZXsSmEQ",
  "e": "AQAB",
  "qi": "jRAqfYi_tKCjhP9eM0N2XaRlNeoYCTx06GlSLD8d0zc4ZZuEePY10LMGWI\
  6Y_JC0CvvvQYhNa9sAj4hFjIVLsWeTplVVUezGO1ofLW4kYWVpnMpHgAY1pRM4kyz\
  o1p3MKYY8DE1BA4KqhSOfhdGs6Ov3Dfj0migZeE7Fu7yc7Fc",
  "dp": "otDolkxtJ7Sk8gmRJqZCGx6GAvlGznWJfibXPv6xgUAl-G83dD84YgcNGn\
  oeMxRzEekfDtT5LVMRPF4_AoucsqPqHDyOdfb-dlGBYfOBVxj6w-xF5HE0lV_4J-H\
  rI63Od9fTSn4lY5d1JjyCVJIcnBEAyiD6EUZbUBh23vDzRcE",
  "dq": "iZE1S6CpqmBoQDxOsXGQmaeBdhoCqkDSJhEDuS_dLhBq88FQa0UkcE1QvO\
  K3J2Q21VnfDqGBx7SH1hOFOj-cpz45kNluB832ztxDvnHQ9AIA7h_HY_3VD6YPMNR\
  VN4bfSYS3abdLR0Z7jsmInGJ9X0_fA0E2tkZIgXeas5EFU0M",
  "n": "r4tmm3r20Wd_PbqvP1s2-QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvM\
  s8ct-Lh1GH45x28Rw3Ry53mm-oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95An\
  dTrifbIFPNU8PPMO7OyrFAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL-Wokqltd11\
  nqqzi-bJ9cvSKADYdUAAN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSy\
  ZYoA485mqcO0GVAdVw9lq4aOT9v6d-nb4bnNkQVklLQ3fVAvJm-xdDOp9LCNCN48V\
  2pnDOkFV6-U9nV5oyc6XI2w"
}
]]></sourcecode>
        </section>
        <section anchor="example-key-ecc-p256">
          <name>Example ECC P-256 Test Key</name>
          <t>The following key is a public and private elliptical curve key pair over the curve P-256, referred
to in this document as `test-key-ecc-p256. <tt>test-key-ecc-p256</tt>. This key is encoded in PEM format, with no encryption.</t>
          <artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lf
w0EkjqF7xB4FivAxzic30tMM4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ==
-----END PUBLIC KEY-----

-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKbhfNZfpDsW43+0+JjUr9K+bTeuxopu653+hBaXGA7oAoGCCqGSM49
AwEHoUQDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lfw0EkjqF7xB4FivAxzic30tMM
4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ==
-----END EC PRIVATE KEY-----
]]></artwork>
          <t>The same public and private keypair key pair in JWK format:</t>
          <sourcecode type="json"><![CDATA[
{
  "kty": "EC",
  "crv": "P-256",
  "kid": "test-key-ecc-p256",
  "d": "UpuF81l-kOxbjf7T4mNSv0r5tN67Gim7rnf6EFpcYDs",
  "x": "qIVYZVLCrPZHGHjP17CTW0_-D9Lfw0EkjqF7xB4FivA",
  "y": "Mc4nN9LTDOBhfoUeg8Ye9WedFRhnZXZJA12Qp0zZ6F0"
}
]]></sourcecode>
        </section>
        <section anchor="example-key-ed25519">
          <name>Example Ed25519 Test Key</name>
          <t>The following key is an elliptical curve key over the Edwards curve ed25519, referred to in this document as <tt>test-key-ed25519</tt>. This key is PCKS#8 PKCS #8 encoded in PEM format, with no encryption.</t>
          <artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=
-----END PUBLIC KEY-----

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIJ+DYvh6SEqVTm50DFtMDoQikTmiCqirVv9mWG9qfSnF
-----END PRIVATE KEY-----
]]></artwork>
          <t>The same public and private keypair key pair in JWK format:</t>
          <sourcecode type="json"><![CDATA[
{
  "kty": "OKP",
  "crv": "Ed25519",
  "kid": "test-key-ed25519",
  "d": "n4Ni-HpISpVObnQMW0wOhCKROaIKqKtW_2ZYb2p9KcU",
  "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs"
}
]]></sourcecode>
        </section>
        <section anchor="example-shared-secret">
          <name>Example Shared Secret</name>
          <t>The following shared secret is 64 randomly-generated randomly generated bytes encoded in Base64,
referred to in this document as <tt>test-shared-secret</tt>.</t> <tt>test-shared-secret</tt>:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

uzvJfB4u3N0Jy4T7NZ75MDVcr8zSTInedJtkgcu46YW4XByzNJjxBdtjUkdJPBt\
  bmHhIDi6pcl8jsasjlTMtDQ==
]]></artwork>
        </section>
      </section>
      <section anchor="test-cases">
        <name>Test Cases</name>
        <t>This section provides non-normative examples that may be used as test cases to validate implementation correctness. These examples are based on the following HTTP messages:</t>
        <t>For requests, this <tt>test-request</tt> message is used:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}
]]></sourcecode>
        <t>For responses, this <tt>test-response</tt> message is used:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Digest: sha-512=:JlEy2bfUz7WrWIjc1qV6KVLpdr/7L5/L4h7Sxvh6sN\
  HpDQWDCL+GauFQWcZBvVDhiyOnAQsxzZFYwi0wDH+1pw==: sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ41Q\
  JgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
Content-Length: 23

{"message": "good dog"}
]]></sourcecode>
        <section anchor="minimal-signature-using-rsa-pss-sha512">
          <name>Minimal Signature Using rsa-pss-sha512</name>
          <t>This example presents a minimal signature using the <tt>rsa-pss-sha512</tt> algorithm over <tt>test-request</tt>, covering none
of the components of the HTTP message, message but providing a timestamped signature proof of possession of the key with a signer-provided nonce.</t>
          <t>The corresponding signature base is:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@signature-params": ();created=1618884473;keyid="test-key-rsa-pss"\
  ;nonce="b3k2pp5k7z-50gnwp.yemd"
]]></artwork>
          <t>This results in the following Signature-Input and Signature header fields being added to the message under the signature label <tt>sig-b21</tt>:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig-b21=();created=1618884473\
  ;keyid="test-key-rsa-pss";nonce="b3k2pp5k7z-50gnwp.yemd"
Signature: sig-b21=:d2pmTvmbncD3xQm8E9ZV2828BjQWGgiwAaw5bAkgibUopem\
  LJcWDy/lkbbHAve4cRAtx31Iq786U7it++wgGxbtRxf8Udx7zFZsckzXaJMkA7ChG\
  52eSkFxykJeNqsrWH5S+oxNFlD4dzVuwe8DhTSja8xxbR/Z2cOGdCbzR72rgFWhzx\
  2VjBqJzsPLMIQKhO4DGezXehhWwE56YCE+O6c0mKZsfxVrogUvA4HELjVKWmAvtl6\
  UnCh8jYzuVG5WSb/QEVPnP5TmcAnLH1g+s++v6d4s8m0gCw1fV5/SITLq9mhho8K3\
  +7EPYTU8IU1bLhdxO5Nyt8C8ssinQ98Xw9Q==:
]]></sourcecode>
          <t>Note that since the covered components list is empty, this signature could be applied by an attacker to an unrelated HTTP message. In this example, the <tt>nonce</tt> parameter is included to prevent the same signature from being replayed more than once, but if an attacker intercepts the signature and prevents its delivery to the verifier, the attacker could apply this signature to another message. Therefore, the use of an empty covered components set is discouraged. See <xref target="security-coverage"/> for more discussion.</t>
          <t>Note that the RSA PSS RSA-PSS algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
        </section>
        <section anchor="selective-covered-components-using-rsa-pss-sha512">
          <name>Selective Covered Components using Using rsa-pss-sha512</name>
          <t>This example covers additional components (the authority, the Content-Digest header field, and a single named query parameter) in <tt>test-request</tt> using the <tt>rsa-pss-sha512</tt> algorithm. This example also adds a <tt>tag</tt> parameter with the application-specific value of <tt>header-example</tt>.</t>
          <t>The corresponding signature base is:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@authority": example.com
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
  +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@query-param";name="Pet": dog
"@signature-params": ("@authority" "content-digest" \
  "@query-param";name="Pet")\
  ;created=1618884473;keyid="test-key-rsa-pss"\
  ;tag="header-example"
]]></artwork>
          <t>This results in the following Signature-Input and Signature header fields being added to the message under the label <tt>sig-b22</tt>:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig-b22=("@authority" "content-digest" \
  "@query-param";name="Pet");created=1618884473\
  ;keyid="test-key-rsa-pss";tag="header-example"
Signature: sig-b22=:LjbtqUbfmvjj5C5kr1Ugj4PmLYvx9wVjZvD9GsTT4F7GrcQ\
  EdJzgI9qHxICagShLRiLMlAJjtq6N4CDfKtjvuJyE5qH7KT8UCMkSowOB4+ECxCmT\
  8rtAmj/0PIXxi0A0nxKyB09RNrCQibbUjsLS/2YyFYXEu4TRJQzRw1rLEuEfY17SA\
  RYhpTlaqwZVtR8NV7+4UKkjqpcAoFqWFQh62s7Cl+H2fjBSpqfZUJcsIk4N6wiKYd\
  4je2U/lankenQ99PZfB4jY3I5rSV2DSBVkSFsURIjYErOs0tFTQosMTAoxk//0RoK\
  UqiYY8Bh0aaUEb0rQl3/XaVe4bXTugEjHSw==:
]]></sourcecode>
          <t>Note that the RSA PSS RSA-PSS algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
        </section>
        <section anchor="full-coverage-using-rsa-pss-sha512">
          <name>Full Coverage using Using rsa-pss-sha512</name>
          <t>This example covers all applicable message components in <tt>test-request</tt> (including the content type and length) plus many derived components, again using the <tt>rsa-pss-sha512</tt> algorithm. Note that the <tt>Host</tt> Host header field is not covered because the <tt>@authority</tt> derived component is included instead.</t>
          <t>The corresponding signature base is:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST
"@path": /foo
"@query": ?param=Value&Pet=dog
"@authority": example.com
"content-type": application/json
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
  +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@query" \
  "@authority" "content-type" "content-digest" "content-length")\
  ;created=1618884473;keyid="test-key-rsa-pss"
]]></artwork>
          <t>This results in the following Signature-Input and Signature header fields being added to the message under the label <tt>sig-b23</tt>:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig-b23=("date" "@method" "@path" "@query" \
  "@authority" "content-type" "content-digest" "content-length")\
  ;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig-b23=:bbN8oArOxYoyylQQUU6QYwrTuaxLwjAC9fbY2F6SVWvh0yB\
  iMIRGOnMYwZ/5MR6fb0Kh1rIRASVxFkeGt683+qRpRRU5p2voTp768ZrCUb38K0fU\
  xN0O0iC59DzYx8DFll5GmydPxSmme9v6ULbMFkl+V5B1TP/yPViV7KsLNmvKiLJH1\
  pFkh/aYA2HXXZzNBXmIkoQoLd7YfW91kE9o/CCoC1xMy7JA1ipwvKvfrs65ldmlu9\
  bpG6A9BmzhuzF8Eim5f8ui9eH8LZH896+QIF61ka39VBrohr9iyMUJpvRX2Zbhl5Z\
  JzSRxpJyoEZAFL2FUo5fTIztsDZKEgM4cUA==:
]]></sourcecode>
          <t>Note in this example that the value of the <tt>Date</tt> Date header field and the value of the <tt>created</tt> signature parameter need not be the same. This is due to the fact that the <tt>Date</tt> Date header field is added when creating the HTTP Message message and the <tt>created</tt> parameter is populated when creating the signature over that message, and these two times could vary. If the <tt>Date</tt> Date header field is covered by the signature, it is up to the verifier to determine whether its value has to match that of the <tt>created</tt> parameter or not. See <xref target="security-not-fields"/> for more discussion.</t>
          <t>Note that the RSA PSS RSA-PSS algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
        </section>
        <section anchor="signing-a-response-using-ecdsa-p256-sha256">
          <name>Signing a Response using Using ecdsa-p256-sha256</name>
          <t>This example covers portions of the <tt>test-response</tt> response message using the <tt>ecdsa-p256-sha256</tt> algorithm
and the key <tt>test-key-ecc-p256</tt>.</t>
          <t>The corresponding signature base is:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@status": 200
"content-type": application/json
"content-digest": sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ4\
  1QJgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
"content-length": 23
"@signature-params": ("@status" "content-type" "content-digest" \
  "content-length");created=1618884473;keyid="test-key-ecc-p256"
]]></artwork>
          <t>This results in the following Signature-Input and Signature header fields being added to the message under the label <tt>sig-b24</tt>:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig-b24=("@status" "content-type" \
  "content-digest" "content-length");created=1618884473\
  ;keyid="test-key-ecc-p256"
Signature: sig-b24=:wNmSUAhwb5LxtOtOpNa6W5xj067m5hFrj0XQ4fvpaCLx0NK\
  ocgPquLgyahnzDnDAUy5eCdlYUEkLIj+32oiasw==:
]]></sourcecode>
          <t>Note that the ECDSA signature algorithm in use here is non-deterministic, meaning that 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 newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
        </section>
        <section anchor="signing-a-request-using-hmac-sha256">
          <name>Signing a Request using Using hmac-sha256</name>
          <t>This example covers portions of the <tt>test-request</tt> message using the <tt>hmac-sha256</tt> algorithm and the
secret <tt>test-shared-secret</tt>.</t>
          <t>The corresponding signature base is:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"date": Tue, 20 Apr 2021 02:07:55 GMT
"@authority": example.com
"content-type": application/json
"@signature-params": ("date" "@authority" "content-type")\
  ;created=1618884473;keyid="test-shared-secret"
]]></artwork>
          <t>This results in the following Signature-Input and Signature header fields being added to the message under the label <tt>sig-b25</tt>:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig-b25=("date" "@authority" "content-type")\
  ;created=1618884473;keyid="test-shared-secret"
Signature: sig-b25=:pxcQw6G3AjtMBQjwo8XzkZf/bws5LelbaMk5rGIGtE8=:
]]></sourcecode>
          <t>Before using symmetric signatures in practice, see the discussion of the regarding security tradeoffs trade-offs in <xref target="security-symmetric"/>.</t>
        </section>
        <section anchor="signing-a-request-using-ed25519">
          <name>Signing a Request using Using ed25519</name>
          <t>This example covers portions of the <tt>test-request</tt> message using the <tt>ed25519</tt> <tt>Ed25519</tt> algorithm
and the key <tt>test-key-ed25519</tt>.</t>
          <t>The corresponding signature base is:</t>
          <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST
"@path": /foo
"@authority": example.com
"content-type": application/json
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@authority" \
  "content-type" "content-length");created=1618884473\
  ;keyid="test-key-ed25519"
]]></artwork>
          <t>This results in the following Signature-Input and Signature header fields being added to the message under the label <tt>sig-b26</tt>:</t>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig-b26=("date" "@method" "@path" "@authority" \
  "content-type" "content-length");created=1618884473\
  ;keyid="test-key-ed25519"
Signature: sig-b26=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1\
  u02Gb04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==:
]]></sourcecode>
        </section>
      </section>
      <section anchor="tls-terminating-proxies">
        <name>TLS-Terminating Proxies</name>
        <t>In this example, there is a TLS-terminating reverse proxy sitting in front of the resource. The client does not sign the request but instead uses mutual TLS to make its call. The terminating proxy validates the TLS stream and injects a <tt>Client-Cert</tt> Client-Cert header field according to <xref target="CLIENT-CERT"/>, target="RFC9440"/>, and then applies a signature to this field. By signing this header field, a reverse proxy can not only can attest to its own validation of the initial request's TLS parameters but can also authenticate itself to the backend system independently of the client's actions.</t>
        <t>The client makes the following request to the TLS terminating TLS-terminating proxy using mutual TLS:</t>
        <sourcecode type="http-message"><![CDATA[
POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18

{"hello": "world"}
]]></sourcecode>
        <t>The proxy processes the TLS connection and extracts the client's TLS certificate to a <tt>Client-Cert</tt> Client-Cert header field and passes it along to the internal service hosted at <tt>service.internal.example</tt>. This results in the following unsigned request:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
  AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
  wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
  C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
  R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
  8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
  4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
  bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:

{"hello": "world"}
]]></sourcecode>
        <t>Without a signature, the internal service would need to trust that the incoming connection has the right information. By signing the <tt>Client-Cert</tt> Client-Cert header field and other portions of the internal request, the internal service can be assured that the correct party, the trusted proxy, has processed the request and presented it to the correct service. The proxy's signature base consists of the following:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

"@path": /foo
"@query": ?param=Value&Pet=dog
"@method": POST
"@authority": service.internal.example
"client-cert": :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQ\
  KDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBD\
  QTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDM\
  FkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXm\
  ckC8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQY\
  DVR0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8B\
  Af8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQ\
  GV4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0\
  Q6bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
"@signature-params": ("@path" "@query" "@method" "@authority" \
  "client-cert");created=1618884473;keyid="test-key-ecc-p256"
]]></artwork>
        <t>This results in the following signature:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\
zhD9ah4JHRwMLOgmizw==
]]></artwork>
        <t>Which
        <t>which results in the following signed request sent from the proxy to the internal service with the proxy's signature under the label <tt>ttrp</tt>:</t>
        <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
  AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
  wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
  C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
  R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
  8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
  4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
  bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
Signature-Input: ttrp=("@path" "@query" "@method" "@authority" \
  "client-cert");created=1618884473;keyid="test-key-ecc-p256"
Signature: ttrp=:xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6\
  Mce9315T6xoklyy0yzhD9ah4JHRwMLOgmizw==:

{"hello": "world"}
]]></artwork>
        <t>The internal service can validate the proxy's signature and therefore be able to trust that the client's certificate has been appropriately processed.</t>
      </section>
      <section anchor="example-transform">
        <name>HTTP Message Transformations</name>
        <t>The HTTP protocol
        <t>HTTP allows intermediaries and applications to transform an HTTP message without affecting the semantics of the message itself. HTTP message signatures are designed to be robust against many of these transformations in different circumstances.</t>
        <t>For example, the following HTTP request message has been signed using the <tt>ed25519</tt> <tt>Ed25519</tt> algorithm
and the key <tt>test-key-ed25519</tt>.</t> <tt>test-key-ed25519</tt>:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode>
        <t>The signature base string for this message is:</t>
        <artwork><![CDATA[
"@method": GET
"@path": /demo
"@authority": example.org
"accept": application/json, */*
"@signature-params": ("@method" "@path" "@authority" "accept")\
  ;created=1618884473;keyid="test-key-ed25519"
]]></artwork>
        <t>The following message has been altered by adding the Accept-Language header field as well as adding a query parameter. However, since neither the Accept-Language header field nor the query are is covered by the signature, the same signature is still valid:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2&param=added HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Accept-Language: en-US,en;q=0.5
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode>
        <t>The following message has been altered by removing the Date header, header field, adding a Referer header, header field, and collapsing the Accept header field into a single line. The Date and Referrer headers Referer header fields are not covered by the signature, and the collapsing of the Accept header field is an allowed transformation that is already accounted for by the canonicalization algorithm for HTTP field values. The same signature is still valid:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Referer: https://developer.example.org/demo
Accept: application/json, */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode>
        <t>The following message has been altered by re-ordering reordering the field values of the original message, message but not re-ordering reordering the individual Accept headers. header fields. The same signature is still valid:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Accept: application/json
Accept: */*
Date: Fri, 15 Jul 2022 14:24:55 GMT
Host: example.org
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode>
        <t>The following message has been altered by changing the method to POST and the authority to "example.com" (inside the Host header). header field). Since both the method and authority are covered by the signature, the same signature is NOT still valid:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

POST /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.com
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode>
        <t>The following message has been altered by changing the order of the two instances of the Accept header. header field. Since the order of fields with the same name is semantically significant in HTTP, this changes the value used in the signature base, and the same signature is NOT still valid:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: */*
Accept: application/json
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This specification was initially based on the <xref target="I-D.cavage-http-signatures"/> internet draft. target="I-D.cavage-http-signatures"/>. The editors would like to thank the authors of that draft, Mark Cavage <xref target="I-D.cavage-http-signatures"/> -- <contact fullname="Mark Cavage"/> and Manu Sporny, <contact fullname="Manu Sporny"/> -- for their work on that draft Internet-Draft and their continuing contributions. The This specification also includes contributions from the <xref target="I-D.ietf-oauth-signed-http-request"/> internet draft target="SIGNING-HTTP-REQS-OAUTH"/> and other similar efforts.</t>
      <t>The editors would also like to thank the following individuals (listed in alphabetical order) for feedback, insight, and implementation of this draft document and its predecessors (in alphabetical order):
Mark Adamcin,
Mark Allen,
Paul Annesley, predecessors:
<contact fullname="Mark Adamcin"/>,
<contact fullname="Mark Allen"/>,
<contact fullname="Paul Annesley"/>,
<contact fullname="Karl Böhlmark"/>,
<contact fullname="Stéphane Bortzmeyer"/>,
Sarven Capadisli,
Liam Dennehy,
Stephen Farrell,
Phillip Hallam-Baker,
Tyler Ham,
Eric Holmes,
Andrey Kislyuk,
Adam Knight,
Dave Lehn,
Dave Longley,
Ilari Liusvaara,
James
<contact fullname="Sarven Capadisli"/>,
<contact fullname="Liam Dennehy"/>,
<contact fullname="Stephen Farrell"/>,
<contact fullname="Phillip Hallam-Baker"/>,
<contact fullname="Tyler Ham"/>,
<contact fullname="Eric Holmes"/>,
<contact fullname="Andrey Kislyuk"/>,
<contact fullname="Adam Knight"/>,
<contact fullname="Dave Lehn"/>,
<contact fullname="Ilari Liusvaara"/>,
<contact fullname="Dave Longley"/>,
<contact fullname="James H. Manger,
Kathleen Moriarty,
Mark Nottingham,
Yoav Nir,
Adrian Palmer,
Lucas Pardue,
Roberto Polli,
Julian Reschke,
Michael Richardson,
Wojciech Rygielski,
Rich Salz,
Adam Scarr,
Cory Manger"/>,
<contact fullname="Kathleen Moriarty"/>,
<contact fullname="Yoav Nir"/>,
<contact fullname="Mark Nottingham"/>,
<contact fullname="Adrian Palmer"/>,
<contact fullname="Lucas Pardue"/>,
<contact fullname="Roberto Polli"/>,
<contact fullname="Julian Reschke"/>,
<contact fullname="Michael Richardson"/>,
<contact fullname="Wojciech Rygielski"/>,
<contact fullname="Rich Salz"/>,
<contact fullname="Adam Scarr"/>,
<contact fullname="Cory J. Slep,
Dirk Stein,
Henry Story,
Lukasz Szewc,
Chris Webber, and
Jeffrey Yasskin.</t>
    </section>
    <section numbered="false" anchor="document-history">
      <name>Document History</name>
      <t><em>RFC EDITOR: please remove this section before publication</em></t>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-httpbis-message-signatures  </t>
          <ul spacing="normal">
            <li>
              <t>-19
              </t>
              <ul spacing="normal">
                <li>Update IANA registration instructions.</li>
              </ul>
            </li>
            <li>
              <t>-18
              </t>
              <ul spacing="normal">
                <li>Update IANA registration instructions.</li>
                <li>Editorial updates from IESG review.</li>
              </ul>
            </li>
            <li>
              <t>-17
              </t>
              <ul spacing="normal">
                <li>Change encoding</li>
                <li>Remove sign-the-signature examples and add explanations of why not to do that.</li>
                <li>Query parameter values must be re-encoded for safety.</li>
                <li>Query parameters now carry a warning of limitations.</li>
                <li>Address field value encodings.</li>
                <li>Discuss history and positioning of this specification.</li>
                <li>Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base</li>
              </ul>
            </li>
            <li>
              <t>-16
              </t>
              <ul spacing="normal">
                <li>Editorial cleanup from AD review.</li>
                <li>Clarified dependency on structured field serialization rules.</li>
                <li>Define use of all parameters in Accept-Signature.</li>
                <li>Update example signature calculations.</li>
                <li>Clarify how combined fields are handled.</li>
                <li>Add more detailed instructions for IANA DE's.</li>
                <li>Fix some references and anchors.</li>
              </ul>
            </li>
            <li>
              <t>-15
              </t>
              <ul spacing="normal">
                <li>Editorial cleanup.</li>
                <li>Defined "signature context".</li>
              </ul>
            </li>
            <li>
              <t>-14
              </t>
              <ul spacing="normal">
                <li>Target raw non-decoded values for "@query" and "@path".</li>
                <li>Add method for signing trailers.</li>
                <li>Call out potential issues of list-based field values.</li>
                <li>Update IANA registry for header fields.</li>
                <li>Call out potential issues with Content-Digest in example.</li>
                <li>Add JWK formats for all keys.</li>
              </ul>
            </li>
            <li>
              <t>-13
              </t>
              <ul spacing="normal">
                <li>Renamed "context" parameter to "tag".</li>
                <li>Added discussion on messages with multiple known contexts.</li>
              </ul>
            </li>
            <li>
              <t>-12
              </t>
              <ul spacing="normal">
                <li>Added "context" parameter.</li>
                <li>Added set of safe transformation examples.</li>
                <li>Added ECDSA over P-384.</li>
                <li>Expanded definiton of message component source context.</li>
                <li>Sorted security considerations into categories.</li>
              </ul>
            </li>
            <li>
              <t>-11
              </t>
              <ul spacing="normal">
                <li>Added ABNF references, coalesced ABNF rules.</li>
                <li>Editorial and formatting fixes.</li>
                <li>Update examples.</li>
                <li>Added Byte Sequence field value wrapping.</li>
              </ul>
            </li>
            <li>
              <t>-10
              </t>
              <ul spacing="normal">
                <li>Removed "related response" and "@request-response" in favor of generic "req" parameter.</li>
                <li>Editorial fixes to comply with HTTP extension style guidelines.</li>
                <li>Add security consideration on message content.</li>
              </ul>
            </li>
            <li>
              <t>-09
              </t>
              <ul spacing="normal">
                <li>Explained key formats better.</li>
                <li>Removed "host" and "date" from most examples.</li>
                <li>Fixed query component  generation.</li>
                <li>Renamed "signature input" and "signature input string" to "signature base".</li>
                <li>Added consideration for semantically equivalent field values.</li>
              </ul>
            </li>
            <li>
              <t>-08
              </t>
              <ul spacing="normal">
                <li>Editorial fixes.</li>
                <li>Changed "specialty component" to "derived component".</li>
                <li>Expanded signature input generation and ABNF rules.</li>
                <li>Added Ed25519 algorithm.</li>
                <li>Clarified encoding of ECDSA signature.</li>
                <li>Clarified use of non-deterministic algorithms.</li>
              </ul>
            </li>
            <li>
              <t>-07
              </t>
              <ul spacing="normal">
                <li>Added security and privacy considerations.</li>
                <li>Added pointers to algorithm values from definition sections.</li>
                <li>Expanded IANA registry sections.</li>
                <li>Clarified that the signing and verification algorithms take application requirements as inputs.</li>
                <li>Defined "signature targets" of request, response, and related-response for specialty components.</li>
              </ul>
            </li>
            <li>
              <t>-06
              </t>
              <ul spacing="normal">
                <li>Updated language for message components, including identifiers and values.</li>
                <li>Clarified that Signature-Input and Signature are fields which can be used as headers or trailers.</li>
                <li>Add "Accept-Signature" field and semantics for signature negotiation.</li>
                <li>Define new specialty content identifiers, re-defined request-target identifier.</li>
                <li>Added request-response binding.</li>
              </ul>
            </li>
            <li>
              <t>-05
              </t>
              <ul spacing="normal">
                <li>Remove list prefixes.</li>
                <li>Clarify signature algorithm parameters.</li>
                <li>Update and fix examples.</li>
                <li>Add examples for ECC and HMAC.</li>
              </ul>
            </li>
            <li>
              <t>-04
              </t>
              <ul spacing="normal">
                <li>Moved signature component definitions up to intro.</li>
                <li>Created formal function definitions for algorithms to fulfill.</li>
                <li>Updated all examples.</li>
                <li>Added nonce parameter field.</li>
              </ul>
            </li>
            <li>
              <t>-03
              </t>
              <ul spacing="normal">
                <li>Clarified signing and verification processes.</li>
                <li>Updated algorithm and key selection method.</li>
                <li>Clearly defined core algorithm set.</li>
                <li>Defined JOSE signature mapping process.</li>
                <li>Removed legacy signature methods.</li>
                <li>Define signature parameters separately from "signature" object model.</li>
                <li>Define serialization values for signature-input header based on signature input.</li>
              </ul>
            </li>
            <li>
              <t>-02
              </t>
              <ul spacing="normal">
                <li>Removed editorial comments on document sources.</li>
                <li>Removed in-document issues list in favor of tracked issues.</li>
                <li>Replaced unstructured <tt>Signature</tt> header with <tt>Signature-Input</tt> and <tt>Signature</tt> Dictionary Structured Header Fields.</li>
                <li>Defined content identifiers for individual Dictionary members, e.g., <tt>"x-dictionary-field";key=member-name</tt>.</li>
                <li>Defined content identifiers for first N members of a List, e.g., <tt>"x-list-field":prefix=4</tt>.</li>
                <li>Fixed up examples.</li>
                <li>Updated introduction now that it's adopted.</li>
                <li>Defined specialty content identifiers and a means to extend them.</li>
                <li>Required signature parameters to be included in signature.</li>
                <li>Added guidance on backwards compatibility, detection, and use of signature methods.</li>
              </ul>
            </li>
            <li>
              <t>-01
              </t>
              <ul spacing="normal">
                <li>Strengthened requirement for content identifiers for header fields to be lower-case (changed from <bcp14>SHOULD</bcp14> to <bcp14>MUST</bcp14>).</li>
                <li>Added real example values for Creation Time and Expiration Time.</li>
                <li>Minor editorial corrections and readability improvements.</li>
              </ul>
            </li>
            <li>
              <t>-00
              </t>
              <ul spacing="normal">
                <li>Initialized from draft-richanna-http-message-signatures-00, following adoption by the working group.</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>
          <t>draft-richanna-http-message-signatures  </t>
          <ul spacing="normal">
            <li>
              <t>-00
              </t>
              <ul spacing="normal">
                <li>Converted to xml2rfc v3 and reformatted to comply with RFC style guides.</li>
                <li>Removed Signature auth-scheme definition and related content.</li>
                <li>Removed conflicting normative requirements for use of algorithm parameter. Now <bcp14>MUST NOT</bcp14> be relied upon.</li>
                <li>Removed Extensions appendix.</li>
                <li>Rewrote abstract and introduction to explain context and need, and challenges inherent in signing HTTP messages.</li>
                <li>Rewrote and heavily expanded algorithm definition, retaining normative requirements.</li>
                <li>Added definitions for key terms, referenced RFC 7230 for HTTP terms.</li>
                <li>Added examples for canonicalization and signature generation steps.</li>
                <li>Rewrote Signature header definition, retaining normative requirements.</li>
                <li>Added default values for algorithm and expires parameters.</li>
                <li>Rewrote HTTP Signature Algorithms registry definition. Added change control policy and registry template. Removed suggested URI.</li>
                <li>Added IANA HTTP Signature Parameter registry.</li>
                <li>Added additional normative Slep"/>,
<contact fullname="Dirk Stein"/>,
<contact fullname="Henry Story"/>,
<contact fullname="Lukasz Szewc"/>,
<contact fullname="Chris Webber"/>, and informative references.</li>
                <li>Added Topics for Working Group Discussion section, to be removed prior to publication as an RFC.</li>
              </ul>
            </li>
          </ul>
        </li>
      </ul>
<contact fullname="Jeffrey Yasskin"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+y96XYTWboo+F9PEW1WnTSFJM9jXk6VsQ024AHLYMjKs8oh
KWwHSAoREbItWJxn6X/9Ht0v1t+0x9iSbcjMqnNv5lpVWFLEHr95bDQatTIt
e8lmtHd6ehwdJEURXyZRK70cxOUoT4paN+sM4j480M3ji7KRJuVF46osh+20
aPT58UahH28sbNQ6cZlcZvl4MyrKbq2WDvPNqMxHRbk4P78xv1iL8yTejLaG
w14Kj6bZoIjiQTc6SeJe4zTtJ7WbLP90mWejIa+q9ikZw1fdzWh/UCb5ICkb
O7gW8737VDe9TEsYy6zK/Hb8ar9WK0qY759xLxvAtsbwc9GP8/Kfn0dZmRSb
0SCrDdPN6B9l1qlH8H/poJsMynpUZHmZJxcF/DXuyx9lnnbgp07WH8byRx8e
hp/SQS8dJPUIzq8fD4fp4PK/arXrZDBKNmtRZG8visrxEFZyBtuGx6IX+Bt8
e5XhseNZF5tzc/jvzWUzyy/n4Ld+nPY2I30ZjZvLv98s4Y/wW5x3rsx7vbQo
iyb/OLcFP6XXSTF3PGrD6c/ZA+CweTLMzKtwjFejdhP2JLPTP43ktkwGBd7b
XC9uJ71izjrpGr/USItilDTod4AD6/d4VF5lOZ5BA84IjnurGT2LO5/68QC+
iyIGtq3BAF/tJc5vsAX4qR9/yfhzwscAd3AVwwt/j+knXDD9PMpTs5mbm5um
+X2OHoDrS5ISoKJ5BIvIbqP1hcXFVfqpk5YAwK0kLgE76Js8uYQ9wzVt8QNZ
F9a5sb4wv94wb2WjQYmQ/3aQlkk3apWAC0WUXcCqE1hmzCNliHBJNy2zvGYO
4mUzOoGdJLl1Di8BbdKB/T2dwbOkGGafkmh3cAlABiMPLu0DwWv9+0d6tZnT
qwIa3pm0i+GnZprNTVvVQTNqDbN8MLZWdRAPRva3tKYdRju4sC9xnNvL6Rf0
6N8FMdv0QPiW4KZHTX5cgbq5psX5pegkiwe48xZ9F501rdt61gNYKdoj2aq6
sHf2hS0uz6/O3/OuaoMs7wOFuiaUjaKt1vb+/mZ08nx7fn6RB4G/FxfmlzfV
h9XFJfNhbWVhzf6wrj+sz1u/rM8vLfKH1unJ2+3Ttye7O43n+7uvd1o02frG
8gL9/Hz/uLWwvtqQGfC/Ms4v8WjU+XWKvNMcAMo3L7PruSFhOdPYuW5Swm3M
XaTDYg5GmVuGPwdxzwzFfEBdo2YBeDCDbpx3o9mdVuuxfr4Lx4V3srBEXx0f
tfbfm4U1NqOZYVaktzPmhbQY9mI48Bl6trkwM3EbsPCimQ2TAdFJgoSM6Cn+
MLexurGxsbCxtrEx56/+9CqJjuA9JqIAiwWsf5h00gvNa/aRMkVrdVz6OsF7
KuTE2dU6fYUEmi5hY2FhXn+z4OzzakF/eqqeXQzsGt+cW1DbfnvCoLS0sb4q
Ax+8fnvyevLdjvIeoEbSad5cxaWwgkexYaNztw0gco0LANoGPJsMEOK7/gnB
FNHs6/QaOY262eqlLvKetp4dPqdVrgBc19LBhYsQCNaLSxv84eUZgysA+or+
dX3egvO1DYHzZ9vHCxsr/Pf26/3dw9PG9u7JKR/e8jIf9M7+i90WfLff2Gk6
UgeQkaQoG1dJ3E3yggc5Onq1v7vJGLjK0+N7nfga5RNiW4YJberfadwMWRL9
nHT50Tz5PIIpBOvPWo3W/ovrKVgHPL5oxjeFzWCYTbWWgEcCWSnnto73kU82
rpcbOB8ICXRtg0s1W9G8KvsVdJzZch4GKYkfjmZhXRaSvoOjABiIlh8zeL3c
2n7VOjoEQN6Ysu5kALSi8RHJJix79GkuLoqkLOaG3Qubqzfhc2VhrSTpF9Fr
ILIwIqwyA8gAMroFNGVcpERIW6M2PBttlSXOEMHyjvMMJKqsV0QlAHH0trBl
zRkPDA+z66TfTnJC1Q39o5EgBAX1X/gfc6gd2ln0knfmPEBcbacZ/I0YGfCD
azzNcox7OLoFoO9OnWw7LqLtPOkraHRm2m4Gf6OZtvdbx1vRXtLrX2W98ku0
naCAG8GEIOoKrsGhtZIOMMlyPHURr2KQRZNetJ1dDRovYMmhbb9qTvydFrQP
oi5QT5R3o1YHFiWMfNKkJ3EPbhmBpjrXSTPwC0sKyRDkbZST8YC3QXYe4bZb
nRRoFojMu6d70S8jFFzo3dPXwgeXl1drNcQFYPbwS2v3NRCnGfglGsB/M7Va
o9GI4jaICyCL12qnVwABgJojmqmbFJ08bQOHj6N+ggJjWvTpqDugjyBu1SMi
mfQXKiQABOnFGJFOBBdLjoWNRKL9RDY6w20h1YXf4W1SC0DJAH0ANxoPWMmS
95oRLdCspRgNQfCBZ0eAFR3gXEV0A6JbAqiSRBejXs95HVSAMagqZdROok+D
7GYAqgo9SYQs5y2Y9+234A04okGBEAYYO5s0L5v1qD2Ge4N7gK/SGECpeAwP
wiMJCFIxqA1wDjgQnUoKEqV3vnGvyLxDhinogIXA8QiA9bE5SFwLsTBYB6wf
fgEGj4/DiM5uQQiG88sGlxkOQz8lt3hycJB88f202wVRvfYI1cQ86446dB1f
H6X48VutdqCHAv0U8YmOSN8efQErKgTbomEOEkhewknIsuFH2B1edE8fNj6c
RPgg3z7cM8iwY16hxZyLZs3SeOGgrpMevlWg8ocj9sZwTvB/8CMOTBeE4BCB
8ACgBPPBeq7TLl0nAIhZHV2drIAvKc3tqRkWv34FPPr2rRntZTcwOQAIfIbZ
YMrLUQyzlQlt1B2b38ULG1wCJcdXOtlgkNDZMozhaodxeQVXWd4kIHp14DYR
IPBwrVUI5BFOFHDdeFKjXpkOe3glhu64cwCjQxBKbuM+PAhq9QVNaA8MUHiV
Fch72gmAKcyKYzQQlEHApTO5BH5yA/PDSDKALBLetV8C0EEJi4alKWIgSI+b
8DUAZueKsZJPrgMaJ2CfPjsgHt1GmTXgHwtoFaTBxA6gqbOyluKdVzPa6rJs
irCB1od+Yt1yMrhO82xAxga4L7g1pKZA++JOTwFsPwZFKYVN9odIERXcInnB
HczSlmL9ugZgWVAHQYDkZhjwIs/6cEbtPLspkvxxHXckY10kQhPhynDj+diG
1gqVhO03o+ejHD7mfSAvsjUbV4hipEK52nA7uGOkoNFVegmvNXqIPvYrjUKE
/OhTMlbIaRMQmAW5DuxFtgI4StdobxKIDGwIeeRAiBCe/M1VqkAfSFAf1c7q
BVdICajlXSZ/mh402jECvr3TOt1PQYQ8jkYseSCnyXojgoJazQUDGsw5K5wI
d4yUtA0LhT8vk0FCWzVszOZdQKWHoPLC6hEZe0nJHKSXdGFL2UXl7BBGCoRW
oU03Kd5ad5Sog0YogPd6aTsnzlHH27+lPzKXFF3kIDegfU/R1B5yfnjoCmEF
6R3tSRah5qcb89Ee3iZCmfZpctwfgUkuLEqh0SmRtOqRKQ7FsFoC1gspy8vK
AjT97wOhQTqdXAPSq+3bq7pJQTgdldFVTBoWPHGdZqgCMB3H7whURErhK36e
yu1m7Y+wDoETwyS1jFBECme/fgV969s3B1MAGmFIJJ7XyRgpl9oGUE/4PrVE
StrQDd4rqT3N6AwglzZCAg/NAkdyNch62SVxwMyXX0Bc6iV9JdxUYMYCy+6I
zwe+SBmCeJ9w1uNeFnejJEViAGJWDt/2iFqWV6DAX14hjPZGhRAmwP+4uBLB
SWgabZvYPayS4fkW8Q84VoePJQfWIpObA2D05PV14GZRvhpHnauk8wmeJLEQ
ICUFtjLojFGOGmjhiu8EViCiULdZlTUv0kFA0mSayORbM4spNISXMUWGRM4v
yBdHaOCBDdiAk7mPF4QN1qIA6oCeu8gBZ0IScfI9Yu/swdY2CI4kNZBsQQzO
2UIYrwAV4VzgFhQfBBEkT4lcEzQkLm9skeEdCXI2QL6WfuFV5CPkfsmgGOUy
ui2zEgEXeujeJvCTgRIN1OIA1gA68OItYTkdMAmWjYBQAZCIkkZJAggTegKI
RJMkc95KPhZEsGFGwE2OKE+EEm2CcBttkV8BoRY4JSAErxkPKngAQKxLfWzd
9OIClACYYSi6t8FbHCEj1HOvyIGZOkJY1wIL9+SQVjWj2a9fO3jpSbdhhvr2
7TEuvneZAXhf9ZkbCm9ShNAoWTaUIfg4cG6tb1SwlJsW3io0zXBkXxBn8vGw
zC7zeHgF8gFAFVwWOkFo1VUXlqzaQ90YbRikBNnaC+4AuAFRlz6gXzcu4yCp
xAeJAsQ5LZ+Hs3GVb0MPQizPx90suog7aS8t+RpSuJsySHjwima0YaWxPwAN
e4YmMN/ORIASvS4fA6/HnAIeQkjBE6muStoGyWVWpoq5aJHA2l6K8kNCFASV
SkvRUzsEVhnz0rc6nWRYNvy14kpFmXSWKhwhG7Kc5CzGLBORv50wNKPz75KY
NbyFYscIjeYAHq680ujmKVIGBYbWdgDVhW0hno4F5S1OzXcRwHSkdyCSw6Qs
Q2hrmL1ABiJEBKDRRif1gHLgUkU6BRzwU1qaqyLxeghaX47ktRMP4zbCEGuO
IKp0s4QF0GJ0AWIT60UDbRYJrqMos3xMehHuPu2MenFeF25LAgkTGBgGYMss
EQQWpTLqoYjwdUV/llfUj/h8ToCEgr8+tQ5JnrigFPk9zpXlQjmRLNgGf9A1
bP2x+oDZP9+YLRhqiaQTIknAuOGoZq2L/vq1JdrjanNZUVIAUD5ooBSkUjOG
fP3KFm7Yo7seS3ligcfnmjJzHeXAblp0RkWhplcHp13z8iwo/rXao0eo2Vwj
01ZO91NSklHIG0dfH9FOSNkovjE8ozaFnvMimjl42zqdqfO/0eER/X2y++bt
/snuDv7d2tt6/Vr/UZMnWntHb1/vmL/Mm9tHBwe7hzv8MnwbOV/VZg62Psww
4Zw5Oj7dPzrcej0TRiaW4sh4Baos0uK4qDms9tn28f/7fy8swwH9X+SxW9iA
U+cP6wtry/ABJTyejcQW/giHPq4B+CZxTgaoHqEPykQFHX5xhXY3tLHB6f71
H3gy/7UZ/a92Z7iw/J/yBW7Y+VKdmfMlnVn1m8rLfIiBrwLT6NN0vvdO2l3v
1gfnszp368v/9Td0w0WNhfW//WeNYQQNLQW7txSI4pXSZ6HW1udiiMo1XjB7
I9ARhj+LiQb/ZM8Ok3z8bJkl6XcZVNwZNFQeg45uvVKgMSnHv4CjXmVdBUmA
zukQKdwMQQ7zAodWf/3KOItqGRCOdp5cAz4xbcNlwNiGK6H1CUWmG7JCjYoQ
uQfoBPWCTXhtkLZCYvXsDYgmV8Q042LchzWDeGsLLuPHtH5AR5gCZWz7lQlv
gJQMog4Q5p4sH0hYm5c/w0sqlAarhDIWmISvxdWVInvUa1C2wUtikb5EiJDx
eQSC6QXZdunkKuPpdWgKiFqYLArUaBBbROsJHwt80nq/MsFWtLFRIRLRRYbq
DkmPFtkjScsQ7iVyXPmO+G/farAqXuU4YjFvPMRoodcgN9SBEcIByt87KY0E
wArfl0m/TtoKehUwfukSTa/PxiDAtUj86Yh0+AzYNrCdibpkkRAPppAj2AFy
zTIfiY2UZeKvX9FfKzw2sGv8lTWkzej83fbe1sl5PTpvHeP/77x5e3S6i3+9
fn4uksS0EzRj6QOsnhlMU1w0eMU4dIqn1MCIJPyE5ji4Urj+75uQ8ZQ2yx8W
aEaiAYrv4TxZu2jAOF31d5ncludwziC8xGJbY5DLAJdwcUgT2gDcvnQ9AZBQ
R/u6GV0Xw7iTPJ2Zn/lWCwfTbdY2Qa+4A6lYEkTUKhx52baNVTxJh1mplGlB
R2cFKFjigcSovSqb+4SAPziYFnmQcLWIxOxw49HhNCz9Dc12sf4GT20wYVR7
hXoBNDAKRLg8NFApc1ReaGP42JhtJ6yX3UbVTcM+3onaT+c+8DdiNE/ZhzLn
TN5GFF/CERal/4RzARNfFgeInkYfBJow0WaaIcSmRAJBuzCKuzoo2JIz9LZS
ihmwBEJCZiK1ZxL+eyRQtxMmI6S043yTL69W20lQD+p6M3ov6B+BZvHj2m7r
LYbVdEtNjBUDINVM7AURW8zQpwCsLEGJWQZ2bAwTTyU6RB81HY0QTT4G9DLh
VEVly/rVn1BrGuVIm5XBNRYVFB3fuDK1R70U+mXyYvbVtBqx4M02OajcOwvv
gzFiMI4M1eTtgOIKbARAxt6X5qeThgRCgKIYGb0Rf4wWNxH0RW9zfgY1k723
iIaT9/4u7o0Ste1r/AAnWmSdlKgGaeEKhc1x6v3k9IRYjomu37JUMGnVTWtq
mq0gYS8MlWq1dL4kEo4IA4sR26jpeCpmNgWXtdq2YJCeshDcAK2JfkBjnGdT
C+6SzWNsk0FDB0Ui8UfQIGl9FZijB0NI8VhgfdAV1xar3LSSgE3NIgOOda8e
DVDsYCt8V4UAnP9dP9AgcCzO7dsCiTjpXbAESIdgFPOEqBD5G/NrorS0mf5o
IP4B2y/KvMBYCVOWoS0TGEjzlhik1GRPEmV+xl9gPKCCw0LELyKGYzwjw8is
c/BXoMyPiT406xxxgyFE4cPwzJV0EgRGZkZXtjWkkG0C6OTQDq5xFYZtkj0B
jbU1lgnjxPkQekw0hzoMx2qr7BWyCW1xtqDHtoGRlihXdI6r+2dr/8XhOY3H
n9/tnuw//3BumWhdg/nXrwbuWK1j8v8qGUcHcG858E51u2i46Mt3yiZlG7Hd
UyyMoFJ5mULZSnQPKBBXJAtEils0bQEVxDcMCtTZsaIARcAIJlf4qFQcDVWs
zJG1JWZFEkkLWeDghDErgu+LRIUy7g/Rq8VuezXLMEuZsJNHVPs+DNDd2LIa
2S8wPCuvwDvMvHs7TPPvnju+KPWW3CUUV9kIeWgWof0VHkKnNdl6zSLUmUxf
4SkbDwTA1a27ckYma5gskqWFij5yyMQ2Mxk1Kql7LA8w8zBbm8bwhOvk8Q17
oTXvYmoqaCVWkL7NhtDFr73+nt9Wg5N2dMPf/fTyinzOlsCio8aMnYW5pjKf
CLoq/4X6Wjvd0cCsDTZNY+uJZt4O0lsDDrYxAUOTI6VKLzcXVnHKr18p4Bt0
NdTvCwwdhaMALtfSPtrdYda5mqkov6K0oHl20NDR+MqaS+SEZIC4p1gJhzN4
jpMWWsD1S2RlURFNZDlCMG5jOGgPra3nv547uEoGr5uck3joWMh5wJIFQemQ
4qskxBljrPCocJjOVYxeauEhoN8TDyVFkezANCqcfY/dxQAuaIfGLSlKSbOw
7fbEsqwLfWfPI6tLaOanO1HkrvDi+YjoKFemcbqgYROmgSc44BVdmqKPo2IG
44Cewk9p6xn+lXAMeVxRMigoMS1v0iJp4EpgC4kJlnCeRpIEHOeS4x8iJCkm
2CqmcCvlVVAz36QA0uglGahoF6Hjxo8u4RysLaP4QiPEN8LmlZhAJkKQ9D1P
XXFn4CfZ3/Qhk01vgqyCGGlFYBQoyPuGMoME/FBloVpe44izdsKOhG40GmIY
TEEX00vpOBSVynI3ylIfZGihvMrMjsJDl8ckb68WoNNcKRGIlNccge4vu05e
PdtdqOAE3k050gxNa/FFEnE8pyg23YyjoihCiAeMBxIIZo0vdloHhGHlhRVc
5cW/cdIe7FD8PTdscQFBMi1HJatPZjW0rxHpiqMBfQ8kvummLyJFISgiLLlB
z42HUOzcjVGrh0Wjdx+x/yoRQ6ulyACUs0xqk30aV8GBxOsGPUL8JYpGHHpl
j2yb1R/zBXAcE2L7CCmZiAe9aDjKMUhTh6GZcBnlmVKGGpKEyMPYTXhfF7Sa
POsx7jGvDOgcFGvL0UdCzZwwFLGW5KMBXXo6cEMebRBRa9LkH0WKgpbLcTxm
NQ5jMBGQcGlJWwU3/oR5A9dxCwTPYWnPylGPsjDWA3TImxh/JKwrijHalMIv
KOtKI4WOwdBT/wO/xvlobduMEDzs+L9mVaYG5kJ97H5qfoQHm4OknKPEqGIO
/8RnOGRzjkKhKI/k8ePJkW+/a7Ag8ypHLjpVTEcW8fWRZkPoZ9zCIHjyScLa
kjjvkfAnId4sXwOy2qwOgIFAjoPkDbtTzmATyXRvfrfvvRvniaM2lFmPT8mK
/imsOHoJ8o7OEAzYPlyQeOmJLrh8/Ca5vYoxQfOaTc40ondMYglGgTnrdEag
eiLDooOpK5gn71VHiau1BggJDdK5hVCKOYGw1BgUjSWLDAhKXltpLlk+6yaM
tu2aqOzRiC8gP7PMYs5Yi95YJ0k/A1HAGkds7WLZ2dYx3w6lsgdda642F7xh
VXisNa5j+jD4P5R48vuOh9xNLzmW66FYKZLinHHW7l6VQvjzd2l87q/CPnjW
iIGp3cRwk13nWQoqkLQ7fUcDYb3aemJu2mfKLDVqIsScRBITbxHO6e9FInTX
aSdpUDwyzyPMGUNDYiJ+8vrMEUlwM/j6DEtzM4/ZojkmFG2ABI8Z4wTttrVE
TsQCx7pWQ1BdKTpXgJO0GIzwt1ch0qTrCtYRlFmuLf03KrCVU0wumeUy55A0
YSPgCst3RVXgB0aFqlfcxeYaLVCqxG2XlIlDPA8pVxDX8VcVCosaNpvEYPMU
o4fytEhEQFxQg8eYEiAhGJVgUYlUBWn3uooF+LOhXM8vtjHMcdDtiU0DI5fb
ID19sk0XYsthwkuaK1rzBpf6AonwvEUJU2mtdQ97lOaDKqdSuEAwAGELVSE+
e4YC0XfuGM/49PBd681iAg1aIGSpnbEvTCw1Y0XE0ZMbosAxueDkdrTtAgUO
jBctLbnYNojVOZqUAA+4lgSOZoOHGF797A8KPTGgb42A65k0yv3XjOYPR0nW
HA5AoRs6HJP8kwCx4eD5MasSYqeoBM3VCcIvstFAUEdma+ihCXGOCAMq0+ls
FRVCSbGXjYKsdOkXBbEOMBDhrthpSSrEw9Q5beSSkCBqz8ReZ+9prKwG6vTK
zDJjwQBpl2Qo5SD07DqewhCMVNPCWYl5Ox2JbPJjmX0YBREJTt9cvpMigSSn
CyQSltYba0xXtuarLO2IwO5bslmK23IDaSd5YL/aWejfJpmelROGZX4lhCqV
o6FUDgxfVJto95KwStVJ886oX1AooHEW61Q7NCGw54E1FsDCHofXowLXG4tr
ecI6615cpfghL9JeMuHiKM5LBYfAPQG5K4hOK7ZrAgaA5vWZYJ4aj8w/gv6g
/5p9VI2pZungHwYOjT8Qnvf9Mo8txqLghPHGSLYUOkdkXYtiAc8GympeKCWe
EvNa4xRjuYLZUR+LC5QW6G45TzOits1sXiKOO3YHnmDvuNKl1eA2vbOcoyre
IY7O2ZIBvEL/rJK6YAtbx/tyNmSaS2Dg0uRjcp5PMO6TN2nn32zzL40dKlAg
G3RkBR3xyeeu8vbYdsmnABTuJgHIiQu9x1gIFFp1zsv48lybULSbVyQW3Aw7
9uUkUblmUNP3z/6yEc7FK2T2NxuM4NFynIYYggAZqkpZRdblSHe5iqaE08dM
+HKM4kquFe11fC0q9DnsmtkaeKlWvZ52144KvoNzGC+1r7rqFbSAZNZ2KTHK
GF8rGYck4ojEjyLrickTF62sYDlZ1nREg526go8xmOgkbXqLcy74RKwkzAZW
rEEDgg4JEDMLSKAwVNMlGiQGstHPOOlNrgVD2Eh8i05cjeVwUTZA/5K6CYfI
6agJ9wiNo3DajYl7pZLJ41w5w7526tuWPT9yO9GuRj5UfeewnB+8cTILKnpi
dmfsD3WRDLwHdCyBvSeSVikwkyLvc4rCvkgvCefMu2QHFCvuZIfzXRejAidw
AXS77tX4lmASCQJ3cq8rgIHQb59bBJOipXe3d1pbttFI5E4EeY5/pVAKpCMn
zoNipKyMOiEIdsq44RemHp7Z9IWK5zE5/FVRXdKGvcxYFGVLJ4NOjYq2IOQx
JC+QWwRktp6kxIl06JY4oLiJurMyBnSldk1wCjrlH+yVqEgrBX6inmirJzqw
saIejIf6tUQwNaL9C511rUwKxm3I8gN7BWlfAMQIxjouwlj6iecJv1Rlbhrq
3W/fWK3xs0iD87heI0VSbTFGGYHt2gUXypEku9G8MM9NImMhJKhr13kAJjXK
B3awkO3WsVA1nBmaDkgjqFfJHf1oIWBdKSBpl0wW6D8HQbELAI6BBxz/7Eib
dVJpnPgmyzUEkgta+8nDTxlCY+E2tOdCSXhhLdCE2zlon144JIRqJuBlq+h5
EQStZFANAnWNMUheRwWdM25peX4hejtQMh7LFcvzSzhxO+12KRJMbtk6rSaC
JgOJAUAHMUECqltuax2pEV7DfPQs7qqaSh6yKct9XIlCkcJWCMAWKonBkeip
MMybHB3Fzv1b4R2Ucg1KWKYwp7A5VVUL8WLILHKL0asBVdFEl6CkRKq58Ywg
6mn88TOjGaWQcU1O+QxzBl1NA80NOdcSuR0LyioFl+k3hYex79ex+sEDVLlC
YkPZi+IHW57/nUloY5Sn52JxcaWwmAygVvCDJhtsSNF6sLvS2SJJONcxmE0l
8zeEQFPyoWeqca+N6aKbB6mgs/DOxb5A9ugUlqddFGfzcuBGNWXqTiqmULeC
+Sie1HtMW1SJ0ibaSadFFL5nQ+4lfkTTdQPDEjPiuMAAX9GiRJEbpFPTOkSB
Go7y6zS5UUtxTBn4zqgspABOVHSAzIfV8TowMypxI4VFDNP0Ug3JHhHOn8Mg
Di+58cZHV4M+IpEHtfg6W3IERbH0EsD2QAO5i7GkUJEsUNjZmIEU+KnJf2oY
yY6YnhfIoR5eSqQknZB0p8JRYg4nMjmg46JMwomoRNrao7THYGY8s/7LXOki
k5wptP1YTnudIavMqERmZIDYqjNHVkg4cARWHhf9euR4nmSLItcc7qwZ7aWY
zUrRAfy2ZWz8+lWX/0Nyj6ZAJWikg0IHyeEp26bTK5ZPJYOBs7Ds3GDO7nWu
U4gXppsxBtASriprM+mqg+RS0WYiICLqhw5oAisJZn88mhDUhna+QI4/5dFo
YxsppY62qTVMInDAgdu9tLiS2/HCAexsBNtsHE5ynxxEHTawTwwDZPZFMG7U
fWI5ys5sxX87NuOiEsfObHzC0kKB58aObgqmcWaAkQqs6RNt204HXDDNj3Y+
dXh1RcUxo8o4ZLxsK0aSSlQARTV5KqkjU/iK4qmltaghtY847uQZMCnyYpi7
Ieuclz3oi56WtI/qCgnuUndKRXUBv8rHKsVDkcrzv9PX5wHRAd1mfMLwNb8s
5Rn6tqXAG4mNBYHxeMWUo+Xxl0ratlqBnBPWpEruKWagQzGcHJEWTk01WzkY
TEgcqQJtLMpftBvbaMkjwAwqJVRQyPX5e5kKEjeKpixCvXCmzMTMBQYl2A/D
oncjcfgQ2LWgSshlyoxdfdKgG23EjvlVDx+bGcUgh27sMsZKSEgPAIhDq0s9
v7C5RHpIGffGdJdnnNGiw1BVDEjV8g6yrXsl1q4Jz9jrS5w6G3TgCo8G4a3T
CrHKxaBTKqWJdUNVE8+9II4iYBtNylZgFcVkds0Pmdh/fNFLiYoOVKJbmCyq
Ulnh16ODrQ+uj+LCcjX62VAkU8HPfb1Tw8vPZy6ybObndpxL0oH6/OXcS1ax
RlWkzOSssF+XFWUj3VQOWwd48fPitOyOiErZSrcUhygnLEACain7Al8ZSEgD
tRzgrLabbAovTCgJu5TaVhTZy74DCroEfcUcCx2FZUtQtgK8BasUnDk3Osu6
KbWFRHniYsgJpcOBedOxktes88SkV6LFqiwehzu40VwoIw5UnjjBMH4t3M+3
jlRzzSaihyCw6DqBpKZKZpmq8aAdToPkhiLGZ89/HZw/NiHgKg59Ul2jDkWY
AgBcZhNCwSQ45SpR4dWyPxW5QaGyxgrnRMvqiX4q5C23rqaCKZE7bC86UOSD
CguT3ZP/g4rEWpGFrrgiRWQJZ03MZ93Xd21JRgrh6ExZFYNIKGVXg6jG34WT
541YN5mYshKmIcy9/58cpukDGIGijlmXzdsQafy/hQpMF/9ScCkSClVSiLVt
EuJvrJXoJARhahMKogl5TnN5QdWBw0BhT+IMQKbGtGoCm8vxyFiElZkaKVac
UkVnCOKfs2fw6yNbWvDxlQi+KJSWoJFyNgvSgbwTi1uDlDy0vVvCyKTYrBUn
NksM854kIyqIF69Wr0SVEsKj/Gkvxw6o5Ki4c2X3Rvcqlh5AVy7+m6AH9zEj
nLai9DmO0z6HYgI1m3g8Fs5qfowDqeVNPpwV+3BOvaG0ME92C63D8MhOpKaQ
Gi+jaTTokYHqimvtArPPiNaipJOzqbft5DvZgir6ABCC3bSm8zz5LDy8BGZ+
0YsvsZZVAjeipHHlf2ekcTaUkrmWmnkorSEmOxv17uky+VflJSzU8pG+4ISN
ngQa8lAgfrG5XUqJK19lcosSngpc9mCqLp67HoUG88qcOCZ1B9LTAWknPyXE
le3xcIbCJwPmWrzW83Zh+0kdaDBo2cDsk4ZKj/32zS36pkmGzoiim4FnQB5G
Mtxxlg5A/JYB4IH3bcG3dwhad9MaMInQitdPAnIrHtkrZujdbNN0DCGDrllJ
EXG4RmFqN8j3lbW1qbAZRnAOdFlutZFRoeoI0sIR7mKGAPUVh0VSYoLUv4AD
n52pz0RPoplo5rFdcMJL8iIHrxGZZEFWQJy9HfGOwHX0sRuOmM1UWKZTpBoX
KYCaXlSxmSS1DvXUEVNUJZ3ThUrk8Rdx2rMKtYZyk8h1QSZ5K6q5yn+Fu1np
SC78i0sLgHRUlCAR6NwgqxSWoDFbu610AXYHkYKlLwiD/FSFXTw/BlSlvXGg
vrPfumVLxvpiKoTepuljUgOl+q8GOA5vdDysxscvNI+kHvKTxSQhIXCrYjUo
NnZMNplNCXNs0ERcH64tG1FBSlN41wYrMulqUU1PxPeutWEKzDI13VV8HtuO
mUUaKZFQSVV3QTybdiEVY6KKBAmfWskRzFQhcNBNgXqNUCCzqYnkixo7m2OM
TiRLzD/qOuPUiPp06H07IqnCCrGCmzMHKOU+CFyzPq5GYuEVgbRAdaRQ67Yr
SRHGSaityMeIb8BI0gLvjQxQul5hW0Vsac2at1OZUsGXNgx7MFIP+D8tVmHG
I2HPUKVCqzqKDSsG3krKxnaWfUrJBMSde6hEomRzsaxMqiHwx1sBOU6oMaKq
m5NibKJ8Tv2Y6nGxDm55V4Q4S2UxLNkGYkw7vRxlIzHPWuALj6Dus+u5FgNy
ABfJQB3f6I4VN60Fsl12nTNJKZx8X1/EDsvV6InwEvO0hEaCpfHx0REIWqQD
2xFpCK8+GIkm0BZXdTZ/vPigS/5o4yiKRojpMOKFMriKA0yDLkXaFJQwva/0
3lyX8HQ2KbRLY0x8DcyIwunYzMh2aQlSJeeBK7SJXKkVO0MoiGWpah2uLsy5
JgzHFaq1WastULMgTsbTBWR0fthVNbo9YXpvmJFDbjy3r2VjUjgxFvPhbCas
lj4+9l5u1ha55PZQZ3KQVBxI5SAk4lWhXUfG4ehhizoQ6FVFPJUB7wgwbFa5
Y2IhkCo7HNPuGtlQsnqISqLlzL3CZm2pyWlpCVs320VGXkq031B6SSpFgvU2
Bqrm87BHiSulsig5gtssymghD204M8U+mYpgZYf4qg5yHKCq/IDsZcRkV9I8
gilfrnuXnW86wRrJLbEwlMZpj7L3Zm2ZmmGIGJvou8SxlQVIpVS5B8FCLYqs
j0OiLZ2QFjA1vIjKy2hCxIH1M9FwQ6qwBvip7IetxbJkWqkm9BR75fJBMbjR
O1YFAxUcbjEzPrxKkpu2jlXlcyau0rnIzQqxK+xYBlGbgpOeodxMys3MeR22
hqHcx0ocqsYGhWRtFCusKFey+1pCwIRgAyb6PLGUTdU0kdB5UuWOijERr9M2
KMA5MxV2Ka2M4RpSL/L4EhEbiOh///d/U4c75U6r7WVFuRlhA1h5lXqP7lCP
uVPc3eI8XERObQ+j+cXN+bXNldXoxcFp7X3j6KzV2KM1bUZR9Ho6EWriC+2i
ASfQ1W8dCVWhZEMXu7axBnxjmxNUN0FquW3Aep+uzvu/wH/9EcVOqkyj2q7k
TqGMCA/ETxfq+Fj76eLPt08Xfh4/XcTPnaezMX6Lfz7Gk/HtkeowsZRxEMm0
8bDQt+dfkqQxOCqKXzKCIOAucyFfXm0Gg1Fnqjc2gxufuevOZm4bsBVpDwlP
33ln+IKkE5q3jmxeYG5spkMXIznFM/ad1StXNKPy27pwR/Ds/e9otz8sxw79
ohqZGJXW1gFZ4ojiFBK7QoQ446tBA4qOJjS8MlhJG7pYkT0P2+hZPpc6k87Z
1vFjFe7oWDL08TKRN9VvjA9AxrO4vlz6+wZtWqENzsFnse8owSJd/8ODL6uA
sRbEMH/KA7HHpnKXdQSam9hFuzpZTwJ7xBhDxjUubVWqWAfHbN8U6L1t0OAa
lsxWtgb2pU7wk6G/U9eNMWuyXYIDIxU4mXDiK3bUNY6+MyYSDBVXTgg4+vPi
4pyqe7W5/jAZU+3LtbUnX++pGCdEy1TGz5pSanytUzxQE1VJzNXFTJ5zu3qn
0TxU0kmR9Cj+X8Ffn9qFquvkjmVGh64uw11AVz8pCwB15+6jmWhfyI25lg/H
KfosRcXUigrXkuuaOEOnPztN5aLVo428unwk5pVA0nted6WAphMrCpd0ecmJ
fFdc3ccN3efKF6X9tveE0sUq8rC5eZsM2n0jB+NAmImNVTwYeybspc9OS1Cg
cyzzeyKI52Pw/CVSor4SFTTJYL3qemX2Rb3l2QusNJOogj/TJ5Y+yfef16pF
ocFMVs9HouM57DgJjtIwZXyVXqAjG7liizHeqBor3dGgG3NSNteYgV9BDQ9k
fyGtMnP+BIcxGjDKUoADnkoPCH53rA2xOjuDiIkFR6paP5L4yCA+KSEqoIHf
0dVllAUtZDATv0HVSFIXXUuPooLWnApfDuHQF2c0d5Xlr86GuZgVH08ng9mh
7jYLb/pIgndw5z79CS2FuZ11Z05ZCyfbli2STs+bB4ZY6djQewVQPXr0SDUB
a/k3wtMaYh9wPdvcRtuKTBkA373KGVaBDHuVxR5Mqo1mK0hWzbAluC8LysQa
iOIOHG6IEmTx2KqyoJJuaeRJjFWt1Sn2hrhpKnf4eGSSvqt0s1lTdMdBHR2L
NSWcpm4gIORNDvo1SEvoeSjGEQyGsDjUiurhhE51lpWWmlVJIDi6iEIqliB8
C3Y9gjKrETm3bsFsssq5WI2vkV1KWY3I1qR6VWnDi2VEC9mUtDBdR2cdBvaQ
1UUXja/EDHkFJPcvPKelthWQAfBGBSRqqlOGgoQn+F6rDgsDmkqycc7dGGht
bNImLZ0gZB8zrbquypZOfk+sIhrCJg2Ef2oaqlirY7xVEcfNaKsgMB8oGcvB
rw51puaCAViGkdOtleZm9avjGRRPUnYXLDbPUXC4/MIsV0oBSIVDhxUavcBi
XpoExCGjVsgy8t1GhP2LStEITyNTQWk2M0IMk5A1cTEojf+7NWXdzTq9CNK2
ghW3ukXgSThtWAQIS1Bxxbbgcn4uLmRFznJoMW3HrBKyW6okyaBM7XpOCs3Z
LDzy+Vh0QEqOx84s3YUux/Vf3IeDTdGT6iq9UfQcUbPk3jXXJKpnDYOMwpTM
pk6lul60viCWWBSTs96WSSitHSG6Zanqvzc5ewgZ2wodjVVQaNpVcoldO1Zy
bHrwEk45vMq4mDyHrFVwmR0LQTlDJGFe4j9piec6gd1GU6SkbsV/i8hQpXMJ
hnXjZBwMc9EL4Gef0rJyq1NSNEuU7iYzjnS7bFMFFh6L+YkC8N2YIT1AMWo3
pkVOBIV4ljCC2tBd8oUtGdxLlMDi6mij0RugBVI9kYrbUYcWSwu6PtvQiNt0
kjDdbRrZWo3MypnVxg7FD/ICBkfAEnyXcd7loK0Lx2mo/YXqTS43bK6qKdRn
xwOYQuIF4yJYkAtjwVOrE6UzSSUKgp0gXJFL5QSFmZAxCz7ELxHKtrqYIN0o
wbsvVHmaw8I2m6NmlhUWwjyAQN+Xk1fZFfNO4Fn1qHu3N2DiQYQisWxji5ao
eKcP8A+4PqbJHgKXQQOIPZ2JQW5YCP7ShV/+Fv6pDT/pQwo+0YEnHEZvS/h2
/Na5PH5uGkd7YkanA3hEB5DZxMinyIrKG93Pn6RrT+JRWtVIzqoc/yh6liLc
NFS5+UkB2Z4dsaoYeyqdF9E0DYQZXSXMQ5WNtqnwpAA5L9zHdts6WZCSRjVI
pvkqTQyJI8BLC01HR3ZjXXQcQTVtwO7q4XhgjTnFinpTV4C3l7qkZIINWKlK
36+E+2Knln50rRBHB69EtADSzTej12I5JUxU2Z1ekyOLRsQK+724k2RssSIn
xsQJfmH/DIkJNBowhD6uVWqbSdccN9J4UWyGsfJ8O+GhuMZNcsLOPyiYxbOK
/TuGseCmFv5nhbLojo0/GMvCm4eb3yVfCz3l2FaNTmaDBFNK2yHjtCg06QNi
pGZSbUfem7wuTmXjBWfwTamCPAKVFTVAhtIAeC9LVFCEnnY9RsI1CCc0PmQ5
RTGdXtlRqKXaNhsDXkvEjjucwpplxBoKY5koIJM8zvNWgkFt3WNhkrTMgIYl
lRgqOABzumGDr4tgUtvIOApd1bItRDdRKa0VKzoTUqn5qejpNOlJxWxI1AtO
Xo96WVlUnsgu6rIaMYjAKY28vVjl0cU+Tq56hWZ2qUkjUdnZDN+11Hplbc8w
l18X9NU4RVVXuDSmmZ9jhz0G3oxsM8t3GH5CXEjn9eujgvGo7ACV9fclPR2Z
cY8NV4xCHjN3jEKogOomoyZo3fbfUhTAfexFssif28VmtNntPy+6Z2+L/b3u
sPvisth/cXvd3Tt4ulmPNtuLH+Dz4XX7bOGqc/P06SYv/LluoYZA0NCBnZLA
pZrSJtrDbuSkyh6/Z23w70b/9fazj+3FhfLD+wO1Lu4GFPAIO+nkxM1FPpuw
dsFclTfdA2HMBCQy1XTaoJLfo5elVMiURNlTafXtiq/KP6lFVlWeLSYykZkS
esoR60bJOsVGjOMEBSVHKsR0M+UINocdlAEnJc458xdVt7gTXOWTyJB62Vc9
0AKRbypgdHF+Pjp6VVMVak/Hw2QzwsoSc8D900HtVJobNHYFsDaBwY0Gn5Ju
TQ58M6KmcElRqy3TuLW1mqQF12LTO62ozdfkwc3oDHFsAxjrNcZpLUbza5uL
65uwFIzT0uqnHHYXuHpX+vkC/9MFSNSFO6mGVpVcfEZm1GcbzIHDcoOZjTJ2
ObhK9IBCn7/zU6gnzs/rTvMz5jgAweiPmZ/L/D5b3jfZMEiIdNh5LK2kYrVT
LSIq/UPbMuk5ZcoUx7tkVatSAp6hU0I+TLpN0/Ri5YpFNtQ5U8tXyuOIhJrr
MijrlG1HRVldKnmbV6yulNLsyh1aS0v9JL+0g17cRaHhIc9Ie+JiT8yr/Pw3
1Y7NCqSws39VnhGu3Mk1MjRCh2pUGJzOZdVQq1w29ym5V1UP9UwxpxZyvnSl
2zKSuUCtlEoLcyffptQdJ0CLGJFZGkugVk03qryAcuF7QT6qfwoGDNSrlYXq
ukEFbAJd1K6wrsJNRBTjfk9Ra0RhapVutrKGOySMtrTu8qtvIFjWQ7VZ6qZ+
KEUAGcuKVfXVyk1Jywq3s5pge2najAhAJfLSkJaZuJyJzv9udQBUpQnU+afU
ljdcG0fEVz9BXUVzSIUOpVISY/q702zQxwEv//2YFegsNwmhgRJptC8SECcu
09ATXrGz2Cl2mF78RcVHNigeJSfX15RKdJ7TswI6QK7/zjcoTTvlOq0iyBLf
1QzFfPHT3749hmFMYUkZyu+iOXk48yoPpXvRyEimN42bKz99VLVI/TYPzt1x
VDdj+vBdw/KrPKb6jgeQsd0mO8Ex+CceYxiXV2q/beogh7gIiGE1qH/wInEA
Hp6qccn4XL3rR8alEayBOdaIAv4kUIpq+4kiIPP5lcYfPiNPI/dIAoa6R0sm
8Tqw2oPxYw18jAaxorIm4SqXyJoWn1XhO9R5vohOJPDK246KxnocIo2WJcyT
f71K4161iEoTadWK1O+da5esBeVCxB6/lrbK02GKbjMyS4L0+u1yIXi7Lv2V
JAFafN/qvhuuFKqTefQFVmJGtE4Sil61AgGlSi5pTQoXHXf6P/zQVQOi1EQk
HN+Kvkj5Djsdv+Mbc/i/1OCmnEUn3JZBx28ZPNk6tNRcrkSzVu6+kgKbFs7x
mQ1zARCDh5IerBFP6FESKj4XbnliJp3lonzTo4LVp+8+OD84+p4nh1UAq1ti
aci0opHaQrFhW1r+oV4fujN2anLJdRvsibisdIkedmdPpOg6SN+kvRhzqMmZ
4D8rBbIQ3FWRLLs61vSJcQQWslAfHohl0DLWW0OxpeCAJYCvFQQQZs/a57mI
DaFKkaavtSXP0qCZ3Ujbq4FZsZJUYjxK02DNca3J4LEUB6DsHNfdKE+osoyU
eGjSDrXcxz0iFQhtNBdM1aMOtgscqHLVeKSDbpx3aWnW6Ey6R6BtUYkjLISL
Zm/UnwZ+fTJ1QOwZkkFoYz/xEnGpuhPadKuvd6Yho8bxEYDDHAoEfyMK8JTP
UNk6JqT7ke59Jj17VMc/d24DCt4lii0AJ1aJPF3vXU9FQeDWFgQedWYzMgOQ
JctIDQZGLQlSwadV6PxOGJ3U6/0uEC2VmKslNnek0oiBdcdCF4N032/3NN3D
IbRJA5miclTq2iVaBFaNqOz+jRUy6ELyGkHyVADSdRdwf7rnb+sPBiT7zsLA
pDr7esNXlvM9AGdmB6B72EQImFv6iqq00+ggCjz1N3dDp7l780RVhLbNBx78
Vrtv+vCxKJXb1SWKQ5UCMblTFBHAsePzxos2KY5EJlMZYpHAlP5cEstRYIBN
s7NhkYy6mSi3lpXNxrJxg4pyUlzklDPRCIe/5KkU+CXDWMYNUuo6jhwD8FAP
qpTxVwYPi6cEy8op7s5tasIBKxwoFzj35eZic4m8v8A6VCygbiljut/QsGVm
SudZhpiLGHGJ9oAeQpAxyn9vZmEBfhjFg6M+DJP1HIF0aG1AvwMHJbpFdQND
xwwAJ9UIEB3FwwGdiFcpUD3ISj9UucWGhyqlELOCWiJ/vJtGTDBkvJ5GFqay
NRmQEMDAnSn8N4WcLBM5qak+Tnos1i61AOaWiyxDqOTAPMhBNWKK5PsKh3E+
BO7VZ6QPVIgIXTp0UH8wRqg7nszxvgcHeFThZIZLqa49IkZVAVBsUgoA3a/v
BkQShzz5ZBprqt3FmhZUdU0fUIMkmxQz6gRr9W0HgCrqNS50nlKtZMYSSW7R
DMORo7hGHAOUzRbDJS1NuZNgi+2aZ2xTv+KNWWECxHT1oFKrCfuZIORQayHJ
lMGcGgqAgzOrVYN+cL10aFxleKLzRscbWTHFTO9qZI3xxxSPBQVTo3+0n15e
qZrXI91GgQ0vXGzWaHNuQGJZMXMiS2NDoWXM8Y4LCFogwfXfhbP5qBLG599E
VHWnAiSfMOpp8Hgsk4r0mVIOGHUlDXN5dWWB0KGOKIpFRhQzMmjovF/snt5b
lja38Bue9++pMVSu4WGTubezfXR4uLt9qm9J1dzQUsq0S1GirSPN8rJCt6Lm
8ta5uT7/B2JCdfLf5A4mDeue9tHx6f7RYasiFBhUwD4cafFp0qnriE/1YHT+
V8ubGDp1Nedf/8BD/utvcqZ/NQLEMRLrqthAniYlNOCHe1tdiPp/r5jq8pCw
SGC1J/j6FcgUWuPomgeZz3EkrsjEGJ//zXNGW3rpb6Pz6aht2oHJgLRHL6z4
4l5cXEXnc86y6E4stsnRtyaBhJ0wuo69ipjvJhIOR41uQMzGC1VOO47JrRYy
Zamb8114sR3uqVHonDCvMsYiu9Hp5H9YM0V+8vuwbwbaKUz7ezAJ31Ps2eDQ
G4K6KhKxW1Vh0cRWTC4a+SD8vajE0UE23DktokJY5NooVZD+NJzBQiNOPtN3
A5JGoDDg6mwCAvLfwCQSBLz/uMiyp+04/492/AX+Lf+yuNOPB78JOMrth+Hx
7jV8D7DSlJj1dc/Rw9Ll/YRvmkuyk3//47Jm+6GDqYzzckRa3KfEwgWXousV
TXFky/M+JrsBslVdTSrciH3K9uRrX7GDwroAUrUWlZ3wPYlABPGbokP1OfOh
nOjkkcpF3euUfUJp1b2ZQDMlMETCRD3+j9bxEUZW7p0evK40rJMlOgfl2iTw
5xkrrn/utgEgSnJhY5T3hO7M2JnMyPUPXoO6ClSSCp/c1Q5P++K73Vx1dLqw
U+S9GBqpLe1/q41oKgrHl0vu3odqujVxP1ZuEMXXqsq2s+dotWbkwI4tBDvy
8XFUjjBRmI3oJ7tv3u6f7O5E9Ma5Gxk0udWQCN+KW/Fq7UnZeSeCkh90FCiH
MMGqpIfg5GsnA8KZ2t6hLuUQnr5Za6GJBwONtF2Kh69eod+5TRUa8nvcNTEu
OLBOHkIng1cS10Pd8u6fvG4jihh8HHtc5U4ndYKZdtLcU0jnWUoQkVXWkUMx
ufb3McK6mVtfSB66oSR87H4Ps98CTyRYpLAiFrg02BSJRUsrbm7e9I0ZeWrG
HVrmU2kvM7qY/sN3qxJ57rFjFcFDsGdCIDTMLDWjI24lgHPbHYXqfp64DzM6
49EOAgvyJazqiTYqrg8dnT89p5BrCb2lx//j3Il+OQyjo1v61D14jlT3yqKG
q9bYISndUSKB81iSugB21klZ2q10OKKERx9WVVvEXtrOOXwfI/w5ao+XorIU
mR/67/9QXQn/gH60uoSWyU1dcl+k/G5xHCTV//g8un16Lwlz3y5OiZlh8Rdk
Y/C+NM0S3j2BbN/cR0BV/N8P1oId/hXm++smTovLPocvYGb4wgMv+J7GwEe5
9ME9hdnitytDHBayZ+wtzvyMx/R0BjYFEh3vKfwE7FKK/QZ/5g+Sv2il1VUl
KCztQOhCkXaqs2G12I6pByTmGSFfXIysGA3RhFpUL5iprCawRSfGnJq3p88b
65rCVvuYKTVUxkXSbqKOcUmTOv+EWCIOZKqlqREVtN2kWEqPMN68RpEEhMBW
+60y7SfSSFo7vyazRjtlSUklNE8/UNGUG5L3+5ieKNWkvJbtgYZFGRNpywrh
iONWBGtVz7MERK+RcDBkXUQWnQmq28uw/F25dalWzNxG4i8Lk7xjd2Cxgjl1
3WhGb2I9UoWJcrK5eo4GEhVvbZX66mE4u0ZB8v2pouUcJcqOsBBFjnQ/n8ma
OFzn7mb0068/cUkD3VYGAyFPnm9H62sbizVFZNXAf7uO86c48l8W5+n/Yvhf
O738y/wWgQIOBd8wKf61FgHe509x209wO09M1Ol/XMR/2V76y9Za3IUXFv+y
tAWvPUXkRYi50yBwnx4EgepyVnC9TlGu5CSHaBBsGyjQPTc+iQ7iEHgW8Bye
BvxjziP8TuiQYBB9TDoxsrQB+iZRZTQ4Nrkuej6eQmyig/1SgtP3zTHlsOOa
3m90r90yIN+90//v/4Fd/govVTdI5L5tRZ9oPdBCOELT6zTrme6E6CGHx9CL
PKimdQzcLrCp3ZQ3HVAhSF0vl3JLtlGeNuYHO5VEB+vQd/dwfFzlCVZLugRS
OBj14emO1Oiw0lgkEDUU8T4xWmJhZVKwhIrqMen49iIwGfTSJOb4azHuEvYE
DIl8YY7HXVZVd/X3ybVm3H6ep4Dbq9FBjLi9MB/Nz2/OrzgJwXdG1chlhIUV
zEr+nqAaO6vZiiSrTub3mxf+qWx11RhjymE1WUWOzUsvidEGc1gnpR+SSgIv
xlSpGtgTUPQyVV11pKmYkwbEqr+xyMtQPxVOewjd8UaxcdFdxFKlLQamqlHV
zKBNAd6TDuvSVlSWUkqALBV0Jxm0mFvJkoTXtN1eIBXQgx0SwDOOM8ceIfkq
06TQLTzkrMg74fjMYs6qpAKVfifvsG6j+gRI6zpLSeKKkYSHUjyk6GH0jF3F
ROWD8kKrLaVD0mxottByC2N1EwW1F0sAkro/rztIqBFIqK/vBEhPiLLp9vGm
mtQE2FDNPK2aEgYYpHSmqXxQ2bJL4HG/gJUe2pzfb4AgxXQil4IDsPqaFuEd
hA1vDiboMp1Wp3LP4FskVWSR0lUXLhlDjTI65wvsnm9yjTDKOkklrHMQ7QvZ
f3u4/97CNrFXtEbtRpEAmmNbLQC7QurVudoMDKJCMlX9QsfQYMn5TVyRlH04
l0oQv8uacJ4BFvs8x4TUHEAWkGo0SIHgyuUKZZMkZ/fWQpZiGBDUxnNONnUy
9K3XtF6pvStepuiWesLU769PmA2oV9qV+SwEUyYSm7hNGAH7pcP2HeWrYWqJ
SVMTF5qrIzGN1Bgxkladsd2ADXupJb2hWqeFwrjPXnIdcxCmqWTmvJ6RFlVm
naxXPLBTwj+8Az5QtNzinioNF8iZ2xDhsZcllktQhwBHj3HT8p3Y5Jxqlw06
puOk+Nc6WJ504FSlrTC5uiQQItC2E2lq19UVoEhFrLBj+zBUaYWH0DK/3qVb
SdcqL2x00IAPfmJhX0eRWjBlD6VnbLtiJiUL9w4uoM819cThoIBySonUsAej
Wn45wADCbEsVZj7izq5pofwl6j7DNybIwc/qskVXUu2Fv44LLfKx3FK5V5Ib
ZkNVWx+TqVz16fCbrt/zWCyByikAXRd6qxiQBQF4xRYNKFwvole7bnr1OqxZ
OZDWRoJFUsQummTot/dle8lL3YfLF6tKny+ihm8x1kJuVsOYj6d68p8Kz7Ct
rrF691gAcAL4OlKMw8EfCmC1Fep1mYjMZZul+DCtW0vVEqbe1qQ653Uqolh8
SsUM5BnAdGlOnaQI+9SxB5qHVphis7bK+qjQAceFex/S1fQ9QtaOXdGMmO69
gVPxMkNufCeIqjmp037wsXvOO2HWmr4juJmLuIOKSFzy9nu9pJcWfRV/qpju
TyLl2Tkvmt819il1mCvG1gKFY/SDRFEku87UjKl2sbS4hH8S6qSsu+KeP2qU
yuWL1nw/U+Osk38Z2TlcEXewjLwuko/RwvgzCUpPZ0o08cLfjbyIG8OimPkZ
xLGnM/KpUVzFKwuLMz/jKyITP11YXVhfX19eXlv5WYRS9dXa2opftFrFyxvN
ivrRSm7+P7Ql3Ig+IG+Y81e/P1aSQ288GQWs4jsq6NNIaLkbGaCFjNBAcHlU
W14MC3joKv3HKpJFo5woU40yKVQDbXQph1rtDJNDKiYMx/Hrt8tzI4wCUVCS
IVPJ+dC1SSYVtcIaJBMKXFS6ADptJyf0+vt3a+snyGp25daeoMocWNnO7ntK
1YGrtVEmtPOrW8X9UHTRHZvDtkQGzaqNwWrZ46iAViCHukScBeYYsISUlibg
Ge0aiCLKJDMc9XqhUzZg4RBo2VzlNHXtDheG0sIq4eEyGlqjZ1XwQ3MkNsDI
7iEgFGzwEJlLK6auz1mXCbTJL9fkVXUd1f6lVIqHW/gNMqLrRACnuhzZQ0fV
HqQ9iDPLEqHoYPJsmFNd5GlSuSkXRLv3WgYysPjtlny7Mdf+SfLr1Kn9YySL
KZEA9+MvHHp6kWUSL0DlZ/7jOCmfdrOKw+n+zqYVMkirAqE76SUuEhhq3AB+
83Tz7Jed4/jdYG7t/eVevDVeH/azj1ufXpxlJ7eLb59vXz1fXthaLK7fPzlF
zhQf959stW+2Lp+dDfL99EOvN1p7dng4TuJe993r65Ob3f7p3tn765c3CRW/
deuS2jE8H4tsoH9+nQwuy6vNaGG9Vvs6A6p6L0NHy02W97oz3ywny/QQhtFg
Akn//kvRxv+V+SVUdK5TkI/fDrSUeS9P3wNPYXVx8nXNf1hNt599eXG5kv9S
Zu9bGyv7H7/ML/WL3sXqq62D7V6229o7al/cDPC69l7utD99Ojt782X1+Orq
7can2+K0vXVSflg8Pn129OXz4vLo5fPhXnEw2rrE64LDb48KjHAtc9zRjBwW
XsYHLIONZl0kSdfoz037yBFjDgMeFeaiSErDhGW8jsJlHlz3G+2KN2QB9y2Q
tqeim0iFZo5LdKuGTg46jFReN4UiXxOxwLB+OGsuyNrPRnYxBh+TnViA0uwm
tqIiTL0ytTqLiVUYrxT66lV4wzROTOUuSksKdhaj58fvuBBN3STi1Smyu26K
nWExKYKlKp+aeJD+CTGvdUGTTi1I+p2zdYTC0UDiNs3vVlU4FTNg9xlJQwfB
QQUk5yTIj1BY4Rpg2qSnM53VMnw/KpfbpI2rwBjH8sf0pu9ma3fFrMs+X+41
ay0Wm4IUgSKZ1jM6yCPgnLE3aqp9349aWe4/oFe1GSUg89XPfAcdQSpyM3go
HdETYwL7TIDk2crTzwA1LkPTlZX4J6quJIlK/A1yycru+KcHMTbcHTO3hzK2
mYrlDtsJ6fOP/MVF7pFEOLN/CJGz78jacWU4/JK1y4quuFFROJNOpzFcXFmd
8UpzV/mkhrc/WeVdIO6ZODaR9qGC/m8PA3rhesmb3YPTua25tdXkKu8+O92Z
W3x/u/5m9Ord6vNs/GX3eG5/46r75dXh+us3L18fXn55i5Mun62tru29ml/J
bxfS9X5y+ObN5ZvjyzfD9ZvPi8D9lsp3K7+hUOFqPrvbO60tN0wSw3qNh2TQ
6IrlEwMAOlgnOpacaLsjhyK+0rhCmvPIcUYJLYg8f15UJjDp0YDZoT+IxC90
eTGiCFOwDo0ZX6JxkXfBdhFs5McKJcbujRvG8ecNbSI1TcvoDH1sojMqCgq4
59X2GTiHQcxH6rVXdeeiKiCYuM5hYuvIYcOJqlkjDodPSTJ0ZaCqWq63B3JZ
N6Ja/smAesvDBtXZeXqxL70RbFAOlZ+CZrwoJtcFRStqBkQtSerKNhxraVXt
gZk5LKO6j0qRVFq+ajJv25DYEneVYV9Au2XFYDzRpoSR9qWRBevVPClemSpU
Yvd04btlk4Uums5mf7uoPrVjIldewFAmEdUyiO7LpWrlkgxad2Ul1QyNatt0
FNCoyFnWwHG2xLTTkjyEXooXxbKW+BekJbd7+1YbXqv1wH4pjV+McO7uWonM
2K1L+pBVGGA6sEApsx/4zAWfvSAyccebJx4kp/2p6qOqX2GhcKILyECFA3om
dmaFkcrCZPZ5B4vVH3s07cwEfrky0Uhvs0ta3may/vblys1BehJng155tbJ7
Uu6uv9hPd/fWtj518uWNpcGb+bV3x4fZ6njp8/XH7iucs5y/yNbf7R2t377f
+dgvP2Rx+eLDsxcv3/UOLvaH86vJu4Pd8eHZ4v7y9eHa+52tL2v9leuFhfn1
6xdf4p3exxwH6c7vrT9pvVxcv1xrfxmsXi3eJq/n1j8/+fz2Jr4625p72d9e
j4+2N9J3g5v20avtzvxZK399efbm5vTD6rvXw2WSd9+Uax8/Xn04XTlbm7vZ
vr54tbG18K6/t7fQe/m+eLe+tvTL6tXwNim6K/PHrf7Rk9v4MPlwvfP6+l33
l95VeYODrBxvl28/fHn1ce/zTT9+s7qzOzpYH3VPPn4ossPPw8XbX151RttH
C4NXnfl3Sycfh58Pfnk9Go3ftfd2ttrbX2g788PLxe7iu4O5o+2lpZdbb9f6
ye7Hj/Hhlyfdtddnx0p4mGQO0qqwT1+J3riENbVJqTE4KN19EhXO3TRhJwYH
FbY/lbOJyplgKX8VInP/Yv3NOQSeunoQHvXgx4By/dHan3WYQbLn6gd6SxXy
9yNqYzgM2eKhf2qO/7aa478YfgIq5/ba0svlhRfvXnWenH54325l7etfLua3
+4edYXmSnh0+OfywcJTPby2t7rcuV8d9Yn8nh6u/XJ4svrnIy2z4/PDL563x
9ZPt5Cw/KA7bnXeLRx+Lyz9Vzn9XlXPLVhaqXTRCYrcqcUscHa9Mh5FNqr/o
nw31MuCMgmKEdSpJ1SCTr3JyY2inhMaoo4pBJ4m50IDpZRiXZdz5NL3/EU7f
0GtQqS7aZO8adzEdVBvFcXfWtrBkhdG0/XgadQykOP1kSyXZwFcjw3Z2at9s
txibYvavSaFcVgaL8QDOQfU31ZqW3WbNXjEdcTAe6P5xFO7aLJAxPn7Ls99P
MDgtLfqipw1zWm4SqC8q8ZHUzpgzw63AYDulA248IzxQwESNErg5gwamCRkl
mN2VSCFSRiPtH7GXVoyKTjIs1WEq0VSg7mFA58ZUMxHTlgx6socKOSr1F6Oe
0u8pUSaH0+0k6bBU1S/UJYh6Lko+6vdcZpNDpsdO3qi+As45KKSqLdsA9AJw
/SYKoAqjRMooEClhMR///4ayXS3ESQdBICJ/vQUVGDjTROdVQX2SqQh2euGl
/ppDsmHZGKzYkeaBrXFnOdYp13xj2Tkqc8RiecKjok3qwB6Z0cQvxBX3G8Uq
EP3FKQRExGdmwYjsoSEjfvtGs/U5l1BnWk0KyPDTw1QMqZNsZAOLFcZTVK1L
HPC1bUcbG3rxjLqSVBJ7vgUdZpT06dfv8CuPum1avCA506JQULftxb2pHtxU
DSTUflSne7nsWofmTsk3c0KJhSikuZ1dozNATYdTv6tVKK5uYpilZOchP94O
ryJ3YiytQnihBuIcgO8U3qtElVqVJXFeN17Lss5eSa0Pt+ujLlGj0z72y0RV
bQ4u9Ly4aBRS/mTr2eFzWqQfJ2anhG19gOMtDD6q7dilM2gVE8/m3DxamTN4
P6QNOWmy1StS6QpieMDAKxDpkciabrDhZAH/sKQx+UV6qyBKVRENBKqHIgnj
3k08luQnHdzMYVnDSiaMF6fmGNaDuWp+Ypwuwp8MOrHAcDcbtalmFYys6oQ4
mW1KKeVKpEk/BcEN04mkkWWXJCpDSM+9UF2so2JrVPy5ouVziZ5z3XvbRI3N
oP7zdOYiy2ZUEp9ElIdpQXtcqpRXqvdWpSu6K2hGBNrUr9d7RUgTrTtuDy5q
ZrlEl55Gf52N3O8aBHivn0ePI39v9FMt9PhTc0MNC8xmNmei1jFF5c+qkBfT
xbbBwDMX/ZVYlGI80WN64WcEvqxdNGAzCIg5fcB87VpwLnsJA8YEdfc175en
kcb/2qRV0cm8297bOoEFto5hUcHTgOd23rw9Ot2NAqAgP9F25CwAUAE7Gghp
YqTUHofQ9VouIqvrIN431lMcUB/ZMgMWyvVaSqqjhKx3cgE6X3T+qQiJpLNO
yFVqh1U+tqiahVSKsYFoCXoK1U4it1B31OF0LasAb5/cS9Q7lgSHizjtedqs
Sta3BCbJwkK4lfyb+2ZpYZrWc3UqgbxipICTY5wQHWdV1sNjwCa8znldnTJ4
yrNO2q9zesTEelhDFpvcJ6RjiVssAAFygroeVZOnX3ByaoJLmJwVYqfR+T7D
8xByORzLo9wuvR72qPlfiGZ7FNpKreI2nHZOxqgs0q724PILsvNFvXMdkEx0
PDrfPOcnlqpPcDWomWiGn3DSnkIMbVqosKwD/2tMhYErN0eRz0yVO0WNoCgz
DMmbcMX3myCU5NQflSMVgYjViFljZGZMeV4UKW1xunYh1cGKi/MfWI+TGOVr
CEp28LpSppbw/6+Z2tG/pOtr9f6dfHrQSUlg8DXK6fH7Ej54kz5wNnfZ04+E
UI16ZZqif9SQ3JRhmj3/+/njurBj9/WfVJa0DvDQkQs+ndBp0K58r7ZSydsg
mxiJsYFu9k4VbtvUcEGU4dMAI4HJXOlkIsruw12PKTtuwK/KonhvJkNRXnwo
2NHouq6g1f194lnb6iUNZrV3F2G70v2QnCSq4dYPnQ/PY7Z9QTE0bq3l+qQz
ytqIV4lVwZVgduKZrXiMyeM9P/ktUaupkjjKapWEq7ax579iXcElZ5o7kjBn
Q7rT4wDvC4p45wTibnL4A1lwcH3fwYVxIQAKTSAlYlvvKFoRVEVsMcRhvo9/
U156x038NP3KK+Wgqncle3aVS+4dNULwsjHJ0/tqmON87MEqmvUskdEvyUVd
ikEz5Kqus9p49NhtNAygfpLAAgbVsbhoaUCWpBpaCSVyh0GGjXoa/YCHZL1r
Fg/jKoPwcBg/uNVXWb72cVVn7jnBTkbsxBolIBoUKcgR7IwRwwebFZTHx3SD
RpT4q7ZleNqKJpUi9Ji+jyG63VQj+eRcnVFBdgq8cFugUnUF3SOhkoWYnG41
JIt7qhlxZSJHTZLkiZAEZ/EVvTm0EY+nJWs6rbdR9kCz/dXd6+Da+Uq8q4K9
K4CrnPDZ6zRWti5LFnpsDEP8NpwXyTDyLu+rzHSQXXU+oWmq8Vzld7kQPVIV
KO/YceHm2vWTfhu/9nBEY9JD4KGufo6jHTNDy2zhOaWh/wDY3Ll4CjcM1yid
ukUZacoePeowfRfRbvOyKRTDWb5ruRKbVWfmXEvRTqH0XXkWT9PJvqKh4qcL
AG9PF8+VoUpjC1V4Y053rjn/vp+th0R4wJ6H68RN7XFs9O3ECjYRqfleBZj/
jWIx7whK+ReFat4v7TJoNpHaerqkvuqwXnea1rJReWK3LSV0Ga/LuXsiOJy7
WDWkfbDnDC9OemBdVxuZYoW3NhEbL45T1O9cB7gsMZLEVNnKRnl4yA8bPbcN
KYMM3b5w8cAZqEaXm3vOIRkUumEixzV71VRbDshx62YUgoJfn7S2ouNWyzKx
6dQ0hwh0cfX+ibipZ36bOa+g2w8kCOkAJR01aHdBdmMMVVeqUKLXd+AJYskP
BAlK+BPH/t0dPhkODpwa1Tw9mFnm90K0JkRiLU0OZkaM/roJEF72kqczhyEC
7HliZ0AeLIEgfGpwHVzFPrRfdiZ6VPnumx88pcu4uDCHQE+MDGTyG8KApCcp
wjreVpWT5GzcSncFlnXQAaVUSJqU7I7iEB/2YmzqruCrVnsUTSpN+vWR8pOb
yI9vGPo44Q2WCCwrNqUJK5XDKuGHFhf4ftQuTLNhL6rFK9/ihefoGqBxW1Vx
sGpESHUwKnpi4jpAYhU6YoLAvGnq+ovq3iTUBchkPh6W2SUgNbB5/Fo1krFl
cTIWc1EOsk5W+w2rJy9IcqlWuriJC3Nk4uKTahHaLqUPMODApyXhICwqeEEG
sbUzLlcLF6tLTgYuwC3BoauwS2TDJ05fSamWzLByI8r453paPGPfYytPGk4r
Jxm60HYFJ6fH9SfaMGf8uXI0QVanNE8prNEfDUjx0J4JzXCccjV97+5YjNMF
oqoKZl2F8EnQCPP3Sd4kLsRnKZYcw1/ou7CqCmnGhjt1ikuqirY4tDZtqpKG
GZLLVMIknMlByUcLx2noYfMQ55eLN6Eb4sKSU55xWF7RyYYWM+1mnRHeqjWX
dTqSsuDsRqkAVm0TerdibfqpMMtUznsOGdLeYjR1OKDlNdWx3lfeAlxLgYbM
jAxcsCy6IFqCjurC910Mtu7O9fRVbuseR4UOPeuosD5e1avpFItVivkopyhb
/K5JZkRsNcF31e65HtfgqIlX8FWKU2vNn6vAlpMK9ZQZjyCRH9ZohLPA1Eof
3+r4lOqnNnkKaYmTUXIkRsGlvZ5YFK8zvLoKeKggQF0gx1oNixMm4sMyOjvg
UimXWyfrUKhca5NMcTYqE21wCjjqKKhQ3JEubK0OIkThMyZf4UAt3o8YXuyY
WFNr3KtOSDyr1DG6ymBr6cAcHIr+oJwtL7HdK0sYeTC6NWD0N2KhX+wOkOuv
XgXIcDCpVY6RzJKmsCeG53FRRg0LvfRCr9FKmKTJdjmEYHI8mi4XmqQllcUY
2H6NQIguMzzPtcEGkaot0IQ3h11Gyg7lVc/dkYFM6Noh9UpQBXNlcy0CQR0s
7ISSK8GR+vDg6kxUuR3nmWc9KfA1uSOdU1RqkgJ8bhUNlAZfWV8Vt1LhuTB0
duEt3lsvm1OkWPZU4HaaclIYbFXOkoFkytOrcCna6r1NqKTuRqurdotTwx0Z
6wIzFIoGsVmcI8+kbK0pCB+stQfEdFCMTPhs7AgQNJDUA1IFiIxYLaRQf2Gs
9Ch0gsY0Muf1fJQTTlyO0i72Q0I1m+KSraBercAkHO6dyiO6rOqdXHAlSE+r
uzYRO16N2YrXZkK0anNCcd+aKo0qSxgp9n6OaPnP1v6Lw3PgHegnQAXyYjTo
KHWFEjYCk+sqflLdtiKVWeFHjtggz1s0X1l2woux60ZhQFWelIlX1PsiIBNK
h8Ogv4oRnGNn13huDOKDV/J4rITzSvl9fSpiuZygY8jrOmkl0F7TkEGLwQRX
alVRddLW2dRUWQWdVUhpkIl1MSJqWlWBk/o0Fd/kyeurr1rL2KSGoytTgvVr
Ax+XYs1hU5fHZvmeGm5hVVwmbL8a2jb9Kuq6DxMMjfaQ1eUH5fzu7bc/7m2v
5K35Zx/ieON6+c3FzvLCxtLp0cnN2mgj6V6Ojq/mt86WugefN872+3nveb79
4u1OerW8dr11my6/Xvy19uHkl6X3By87C6OjV5/mXs7/0v/lyU2njJcHr/Yv
n3169Xk+P9i4Kpa234xv37+43Xt9sD1eH31+tby+nj3Z+JgPyze/1p7cPj/e
e7UWbxQnrxf23x/G8eX24eHSL7cviw/x8PnHJy/ft/vx/kpebnVbF63rL8ej
Z9tXT7ZO9p71z0aH2cLbL7/W3r3r7r3Pe+vJ8evlTqfzuRd/2X/Z3V5+s/sx
f/6kNVjev3325svpL8XrjfHG6fHK8+KXD1/2rnc+t/cHn04P08tnnV9ruxud
V0cfDp9vD5Z35s4O1p6vnh6Ofjna2L0svyTD12edj6fjfm/vCyz2/efVrf5q
cXGUD/e3lzfG7z9+XIqT1b1faydx711n7vLp03vZtDxt2bNZ0XcVm1UVzv5M
+bt6YMrfo0fRO1R0xlULDClAYzj1d3ZLnH+JHQaL5eWw5FEvzjGuDsa6T/ra
d5pvhEM4nYAw1l3EbMyoYxbmPMHVW1Qsjm2E4YP0jTDannNvM8yx7lF8r9y9
+6s3NEqIPbHCBteDURfuxSldT9kvmyooh6OeGBj63POTksRCKELqZN2Yb0Sn
Ng8WV9JizlS40aFhFX+I41AZZnC3Y1Ve8SK9HOVOSoM6frZADCwjhAvPVGCZ
ywZVQ64kiEeFqLEE1PK26TpdMYok59BEAnb/8pip6U1W51y0AUEIQhZegK/t
TunYUWLLktKorJKOcUcPrqBMUo268iFlqbIFY3EPno0KMDCLtOQ6ZwA9KZ2g
P/FykzzmKuw4bIfNGGAo4yP2yVU/UVYpz2wniEbTKs1CqQoUfHmT9LjNjpsc
NtX6ZxkxlSpLGCLGvor5BRmDrZtNscWQSsGUqWGvAbWKFT8+e2JTtEDrI40O
vlFRIlKucqobBkQFk1F7shVMP1JbxBoL2ArVRdtcv6Jb/QCnvMzK1KoDq4kq
8fCRVB1zlpQWfEfG4VrRVP3+He6oiB0qikw1JbHNeK6xmDzANKOpj+4mLurR
MZ68zCxqSIwwHxXo3kOHW1JoVA9cgualCgYn2EB1ezrp88uHYh+IhvtqDBle
Ijv5aBaqH4YrrFTZrjvRWSydmOas2HhLrld1F3VgTKelUPMPFxiN/MUHjx3v
vMZ9mypHpGWigy2fA/Xp5ULDRq90AqYc0WD/ItgdDeA0GaL5oAdCGJlRrZVZ
YUKWncFvtyfyILUAgc0WHhN1Rc0w/nwv7mgOcy8cSi1Xhs/2zCJ1gy3tjdHe
HnR4oy6nmyka0xzvxzk+Ivd6hcLREU4lkoq8qQ9Z7VL4SFXUBybJl05zgRBn
YMNH7MXo62Xep1HbpBUnJtis6699Obx2sevzml1Bq5cpb7x/yiHw0BtQXN1M
EzgGHak+9SkaC09ID17lCNYl6jBbCx/9ZljVUyB+Z+A4Mz0XvIN2k9xsQtFE
O9FbfQWdhGydFdsLCZQosUwww1Br7caUREICnZo6B9swYncbrxhuhEHYAk7I
Csx6lTC2ezo/Aj0Lp0XEqzQTT8wJJq77KWrBkBDbqdeL20nP0Irggpu19YmS
RajLhO155dBgJuv6QbZKvts92X/+4dyLoHB4kcNvnKWzmA5gY5qT+BfvdpD1
NCDbPKoWcpeBdJIhlJYywRi6wROp1joh/daivcocGud28I738pTzUgNwEL7F
OeM2yKLCNQkbuWujo9/czSFdg+m1Nl54LhTF8vECMLFk4bzKwP1Aun+V4fPP
0NgfC431CMY9y5T+MQF9em2qOunDDc44Z8Xo/FCTMw4SMDs/zOiMgwQNzw8x
O+MgE0zP9zc8E+RMMj5r0/OU6qRnCucn6eLsnyyjXhIXKpBuQg8PF4jMZzuK
wwYj8lmSz8UKC/LMotVYZ9KtOmiwltLb8hIZpoG2ua3VKxR+GBcFZXE/evQo
2sUQpA5VqLBsDCf2/pUB2LUOcLi5M7Bzao5U6hhBpMMIHEI3EWsUskiibqKX
AY+hEjbcEVilU0sr3d7YttGR45mlZyoQ3rQ3okT1SUGkWE8GSwoWnhWHGRTe
SDsZZ3Qx+IzZExlRfMNOQPpIc70yrOSO4QTBXAoOgJgAgF7hKy5PxgwfzwVg
uyE3xmqJTgmW03Sb8bA1SDx9swlln2wxIH8RkGFC/rgJ4xr4iEF8uU37I1vM
pxhRJa0p8CP+qcMf6FuC2yYt86MUGHJLtg0VavlhXaKG6U7f9niRH7nsvaoD
uUyoIXvHNapZxvcO6Z0UeJDTIt2QhCtpC4ceB28i3Ndxnl2l7VTtrJPk1Mpx
amCTUcry0YBjyVxNisLGjEji5SPocBFHGZygcruVw/BaJfjCKi1nzFmS0kyz
cu9wN2SFM5ylbkTQ3OWcichkiAjW2RgBljTJPgwX+89asGzpwja0o7NMQJpT
Q/TJf0kUdC/OL69Hbby5ayAPC/OLy/TJg29u6W6b1qTtu9WLwEW0Cd3Q3coV
1DrdHsIurmlechE+T4xLjxwvg042wsKFXYkc90gCE4NiEgWhhsCk+ya0XRLn
QSYdBTqDu6yCfS11L+4gbKFTybzmOa3vSaRrwKj2U+Gs1K896i86bCX3OQzm
A1/Gebcnl6lIsNcFQYdFgZKbDEubHhF1kDqS7uI9VmEaolaMPV8fVXWwaoKC
OS1azohKZbpKFUgTaemUj8uwFNq2yCHKxlgLab+u2pkMrtM8GwjHGnTdzhQW
dTROsdNKaoddcgGZNPBjSkDmq9U9nQMB4QJIbktrz1aq/SoFac4+akjDyZF0
uPDwADYSdkjjPVEcpYojkqOzI5Lu9FBTlMwdhhqRZ4xTavb8ACtPqJGEZuk7
qc2evyrwATwYdjv7gWPijK4O3Dp/LBEuehfR7EE9elU8jqLGf4KEzhIubdzB
WWf3yuAwYf8AvaEIhB89DN+TVNN2HDiRa3UiZG9TboqJjsTw2VSO1BNWqTHl
7Pk7fJLe57699pHy0fChXtej1mM81ncm29JyASQiraouzlavwX42CGKDNNaF
nwGREGmv2PFf+FYVbQrCxOGhrk1hwS4lWjq3SVeT8prQC0+tFqnqFtOMTKhi
IM1ETMQiU3E25HQjL8kmtTuLR7THVt0F2YVLoIhq8fRcPAlEzDwh3Id1ljeJ
FSJbIVWt0BmzV8YtAelJUprw+l2V/nG3Jf+/Zh9dgYavPj4WteqktdVqbTXQ
BsTztva20CZCaWsh0w8VoKNQTKsQrmW6tDdNPYYlvNNM1GD8f1WPDh6fG+Od
cyknz7fX5xfWADMdH2SS/4TewPQagdCmUoCKjEe1ACUkZJ4Qj8q1Q/tx8Unl
idkGQcpJP3jxfOGcPFW2plhZY4ze0CvzKpB4fZb47Orikq5VWsS9UjImYHXF
62QAC4S5Vpe5hiM/5Y43e74Hn+G5wKhWR+cJ9WR1ZhUdkLTtVPUTnTbRVSZu
Bm+qqspWy6TEdAOtELZ7xaeOnJKy3MZShyBNBjKtEE0CM0UTZ0FRxBb0B0gX
LYCzb9Dg3HDUBkJCQCUdXILWZ8egP3vOc5yb8K0gCGqPSyiTQ4LXvv0fB5HR
XRAZtNVXoFLDgwR/TQU9jy0LG77jTqZ5I8yyVJZERckw4kFasGZa6b5uwvkq
hnkVQ1mJDxWIy+3maqwN5LmkuSLcKYcP1hJJbmwsDAbVswGwP1QuFbV3ygCE
I8bJnZ5p0T63pA8ITVXnIUXb6ZrlIibfL/zzbWHSqCp+fHX4mLKljRUWP3V5
2bmvARO7DYgNHq98td1aaFwv/HPFYpmLK6suy8TfcR744Yd5Jk34Dgf892Od
RBL0CfzJkiazJHOL/6M5k8sDfuzm/48m/T9MySwS81BStodWmQnU66ofd6qU
S2sw0xAgRMRwKh+2Fxfmlx0CdRXnojbfkyxh1OB9KNMfBah0oGY8JzHIDMpg
JBEBslsdTyQEzKnk+mAy9dyLK/QI0++GIG4iAp2Gja4iSnSJHmM9W52zbsf9
hBdkDCx+RAcNmhbEAZ3gX8QwkCCqmXMmkvQH8c9CkofiHnf94rFA0rlOomOC
zB0U9zA5wkfIpNNFuQW++1GBgqY+nxTN9Xz/uLWwvtpY1mzHXt79pIlJCPtv
LEHUmQc2vV4w5pByqtkJR3iTkTsYiyWoHirnuSqEfU4hSwV5OqN2Boel0vwA
d9qwa2xYBMA1GoiIIkPBIF+SPGsMdVX3pcVG1inRuozl59WwajQro8qq6k/D
Zabm6uoyjyGyj1Qls/xlznBUcAx24pdOqz4k27TolVmESCTns1gpHOQZbIFl
JbNOw/HfRfC6P7T/oJQ1QbT6dxWqJvjHAuKVgxq/KxNh941pDvNAAC4UBAsu
+qhhle0LYSg88KMYGmokriotWwihCn5M6P00ISzxj7Y+eI0p/7Q9/Aa2hwoX
/y3khqX1ZUduwM++3ADf4Yzwzx8uN+Byfn+5gTb9p9wQLa//uNywsfqn3PA/
Wm74fmT430NueBgA/8FyQwBD/5Qb/pQb7iM3GC7+YLmh68sNSfcmzrvF4srK
woYlLnTpi+8XEvj9iYRTdexcaS40V8nHhUbupcV7eyq+Q0bwHkWrWvwJwxJ5
zYxNigqxKVz1kRtiVQmbvPojumpKlZ2dCFVphVy1kw9DYQeXCdTLdcKG1NX/
LkzxR+92zb3bH3VgbE32XTyAUf6egODxLEpYl9IfavzfAkzcc/039UskClAe
RqNeto4Oo7OkbcUwzb48az22eYkmVB+zAksr7ZvduOXeCDFfHrV2A7/pkKnA
jHgNuwOKaMNjs4KoTiRqKsLEFgDi4iqRzsRwH2srC+tSsawGa/ZRJBUXrRio
/aBJnBShy6sZ5xQKIJlD70WHkqmEYDL6T32m2gGjuB8VtUUPFp7KFN6YwX22
ZDLKYJtheKRT3+M0Dt8rDee0xgIptfYpTC5RCD2pik2aF2W1WhrAIckNdEAK
8qyw+6o/ApfrEO4wWQWmk+VKuOK5RnmPF0CR90JQcZfSj9e9cLt+JQblJ4zb
9tdUTMVtWirAuu/2YbJSm4hOqCyFpIu9gF+eWXJWJR7w+4BbFenSRQLjIoSy
WGZzPOSS7HV9vBVKQW/2dDyjXtIrTITA5rwoAJr6z4UKQIXjp+NwOwBhczpM
qO2U9Si4d7V4DnCkAjKSkvMdwZGSR8CA4DXaCJyIDdNIFzHPi7JeZOtBUkQR
+bApVUMsDrUCGFhff33EdYhNHwEgghOiyA25lquU/gd+ITTV80lPKQnsTpEu
3f6EaIxC64kdFQQz/CGlyK9pysUuvGClJr/IvGLtKvDYugS/wv9V2vMrjkk7
Q7vhp6dqNbl2MT+IkfsqOLqPqhlW+6OEf601Nk16RLCknFWZBmP/pVxA+A5E
heVHVAkJzvHRb0jBvUqVB/24ECa6oPveJ6ufPK+uAe1WQ8VK4pRxwp00rCwn
/Rr2fCJ5oD0OVjkyhV48+Uyq7ljQ/G3qsergZ9rkfTbIGUnWxVJ9fLlZ2iS2
iaOdyGGwPNSRFC3ZI1co4SGo2GGmG2gxDUsLu44eSDMh8KddUbMwJ9/GKWs3
FXEKtwVZpYvabFAgX2ouUtzn6cnb7dO3J7s7jef7u693WtSbkI/CFEeXzD8U
OXDLmOyGfDZAXrw2JBb6arKQeFC+y620qSeZAoXCGB4rk/CN8As/FarmU6lB
lggD40lv7NOVKvhMXJczixN84fbJ00EHFYplFaUb9kYFkX8zcahSvEsf9J6a
311VwYOZUD0BUzLcqy4woaoAVrxvSNnymcc/41OVKgIr09sCoboJLDvtpaXS
5TXRlRoZ9SC5sttzhrG2UlofSWANnlAx05XYGxQs4YZD1Wik6uH0rBA7i5do
cridaF2qEFIpTYeXyXfcyC7jCpFAbvJrikY51USXk72twjPh0yHhtcxj4Hck
s3oHLZnQillckJjCTdbIsoul26iZvNFVvULYe9kNpgZhDRgkiWjUxEaAaZyn
Im/FYvXHEnB5NlSrodwshM+vXxHVqBsrmfhOdrePDg52D3d2d4z1MLw7W3bJ
BphJT0nSrFmgcnSdpV2bInFHv3QQd2HNuEOqkJWnw2GieyWZjjMHiq8HZ9fZ
e3a5bE2pquTDABkzE5+Nx508K5guWJBSBJjFJDYRZhD3ZQ0P5Aw2Y3gYH3Ax
ThXKdZuchwnvH0ze4+gZqn0tlEEQuD1W6FvilRkjIOz9bpRcVV85nr95/bb4
cvbmY5auLI+6R+W4e7Gxf3Z6cXg1fpKvLH188fzjxvtfRsfLo1c3t+OXGZLq
hZPWXvok232+8Hz0fvVocaP7pNe+vbl5FmcLz7Yu42768ezJ2tHc8Tj50jsd
fN46end8drvxojeG7Wyne19wkO31tc/91puP16OF7efj56Oz1sfui3jp8+sP
H3qH/bXhu/jl87j3Jn11Nngbf744XX49Bg3l/Tgb/3K2vvyxtY6DXI7j/HYr
PdvfWOsfv3/75Ojdweryk713z/b6g92i9aR3muwXu2+ypdXTpcPnF4vbo49n
WyfHby5XlvKV9ZP+EAf55cnLjeTVyeL2zur+yzfXcWewsrW8f7vy7O3Wuxef
e+Ph+ssP/Setue2zl+nSwvHh248nJ9ujYvvdycf5lUOYHwd5dvj8GsZsbey/
v1i8+PDy1ZNkfLa8lb54d3B90Dmi6is6Y/IuWvy/KxX+V9HffwHlrS7Cy4WX
379Z6+2SE6nj5OBPW7Ir/lbf5gVLnWVZNFMQ8TlqDdRW7lWJaXYs4u4U1JBs
lKqO2vxgB6u50BWoXF+3kjyZdJwaZbrhWj8ea/APrUTBuJ47UOKXbFxmxk9i
/3GNncVoiD4B7SyuvNaJh3EbUStNuA4HduHBvitUaPt27CzVKiJiNTfs9FJp
fiywRjYaeBK9YWoXqrUPB0WAdJZ20OyARZJSy1ZjOVuuk9wa/ifcXHpJFeg8
NlI0/WTsYIkdLBqTq3OTm+jqdWk+y9M1oy3vHDg73i5sy+ZgKeRfuGs16tb/
6IpuVmm1f1GRt3toYA+u6EYF3CoF3iZUdKvqYkmnQ/FmgZJu71eK4bi7uv18
sPVi5c1gZ7x38TlrHe5vd588e3u8/PrDwZfFN/Mv3/fac3PL+x+HX4gLP/l0
nSzeLB/ujz8nW6ODtY+nO++fFIdx78vW+m6rFe/tLG1NLWHGNhaCUioO0xMT
n6EbYtq3kBKYVqarHDNqEV4iT6TmZF4DBsRVrt6hW04iccPhyItvdRyveCgW
lzbICvVHYAJvpYnLbRJXB4rRFPS4AzVWvxM19DFs4gE/XdhYbM43F5sLi0s/
4zKeWsj5M9nynuIhFH+i1P8IlEoLljy42QfjjKL64uSGi6UokAr1J4TpA+fQ
XcyounTfarXroJ7FVRUbvHDZJ5lJSN60cNk0gtXTVPkohvp45AArAQotiLFb
ZXBNTess4l6h26ax+EeenJ7qp6KYqGbVakJdwy+Hh6/jCdv/Sbv4YVXkmeqj
X4/q+rFFi5dB9bJvZJQOd3KWtZC0VOk0TJ133P4H1cuqS0ye6Msd8piKJ0a3
0nGMVfZP9vpSI8E5x6/RStm0ZEJWWLglZFeZzPV5w9UWYXKLPewqF86eFxuA
jZKvnpawH7f5a726JXPVA7vqXbCxhw6HQIUJJgEtJYlBNh4XAPCqCZB7hWjy
t3uimg5kCm6kLiD+cIVyLMVFgIwHE4iDR4VqiHbg+Luziwd1AJve9H4qYxEq
uUlsqubTye8g7UTETh9K2u9ueO9RaOJfMxcKsGYeyMFmKlZfGOH34CSRtcYw
V1mfDxnNZ34GEH8646X1ztAIUlJSjbCyPM+kfwsRoxr2pYKuHwRSrdVfvhy/
b3W3Do6OPx7Orb56f/H+7PBo7mLt3Wpnr7/27P2Ht1dLH3bmLk7i7vKz7fjk
l9vjJy/3nqy//7Cwv/pkfXv8a+3J9sHK5cZiund5W54cf3ly8HGQHsUf+t1P
O53B643O9vD9y17yvjjqfBq+Pektb7y4Scdvh78szL/auzzaTRYWil9rt0sv
Fi9v99db8/8/e2/anEiWpQl/51fIosymMltSBKANxWtp0+wgEDuSUNVYhAMO
OIs74KzKyP/+3nPOXd0dRURm1fS0zWRbd2cKuH79Lmd9znOm7qGZOW9sb1Pd
+90TE3Or+nM6X+9vapXK6zC1aRe2d9XMTS+9i7fSxUkmtVksd3d+wf1nrLy4
P57fvdzMXpojJ1V7tF6tdMpJvpb2y8xwfGfdZh9He9ddb0bzt93r8CXt566q
pWRnb++6558amcYu/s9Y5rb2WJvdX+27/qfd6GF3tM9723LqrtS9Ss1fS95+
8+b2q0/D5d1dvHz7VGrdPo/G7fvh8M1Zr/29n0/s/xm78eLVJ9lULkZOvYZZ
kNhgGboUKlTqwKMSR7zrV9jBROXP4w9bd8hludZa9StYKV/1WlrNaTRMgeih
KCr7Fb/+hX35qy7+ZRdP5C7Xz/VXDV8OQl095r1ids0uUdhEldp/z9MGPMCC
KZ1A008HSVEj2NKJ50/yrUQ8+f/5A//t/YE/6RH8pE9wgc+SN+S7MwvNKTDV
H9Qw/wodE61l/kU+zg97OcEF/PzntBI909BNP6+Z/sk7YAX0089pJxokUkf9
uIaiQU7qqR/TUjTIu7pKaipmOJwmoZdCmCQ/RZgVne/8aKRLpKRum2b/e10g
TztnPMFn1IL83Y/so46m+BLKjSB+y/4d4Jd65mNIPZGpRdXetmZAqGyjeS5c
omD4FkFMjj/Y+gpYL+o+4LsGlEnTjt91zKNcPPw7Olq+ttwLCu56RswMXRTH
NYYMV7soHm65nEA6qSBfpjMNTm3Ax0Jvnr2E7wBtrvCtzLgAmxolMxTBsx6M
Z180rQCRI4Zw+4AdJncjB6a3x6VT7QvYvxDlp769nHjXoJU2+4nJpqDMWwbd
fnoj+YRk8kdtKmJAoEsqgr50guaLiIWQfiOkaTj/Py+92Jww4bC9FELM8Mds
/7Togfyt4Z2COz70RJs5jVZZ60IjgEvhkP9Z2mQlxsFliRMBeHXidRXzgAQM
Np9abjj9uTpmKBFgFDT92HKzn0IyEKGDRwr6upTx0NC/sOu+TV00CTEoJwBb
Y8+PiJdtkXHs6L02IWsXRhMKWSVzWRCKWtvUiAGBtMa0Md8jTG98O2jqydvL
Q6yLvfxiuUHCHroJ3oipZYCyOWtLXAi45KCsoXRF1j2qtRRRMeJM940J8Byp
+j2ftrJj08j+fRlImX6EF+U3O/obdNEp8yXApwEng04w/zaPj2ihEJ45w3e1
JThup96NuxR8ydSUNXiE3k9AOCEmJEQEtOQ4KOdUHoud1/lcfsoVBTRi264H
YrYij4hHSC2uBkg9a5fq3WpONEfGXDGC3XATMWlKWDPr7AnQNEbGAJ8BAC8/
tNYXslwU5r0E/wpaiJzh2GKu7IscE2CcL+MgyI4jdKBUClQsww9tuIAEqw3n
z/uxHefbq+84PwRix0GOuyC6tYyp9ktZ0venjoAUVvoTSKfyaQDAfTDxPJ93
VvGxCS67n1uFvBhtcU34z6XeFABCmKaOKdxbR56hDUyKOoifWGtM4AubB6K7
AiqupclV1ZRj7BuvlNHUPsKV0aAx0uraImoxYy7ZT8oFREjY6ML/+Csg2kMF
DrS2NlG0/dgc6ATAy4AUOFHfISiW7L96Al8LWx1sxvf1PyFBscWKbf5FbdIK
WRd6Y4Gto1YKSl+YELvT9+q/CoTNF0kLOWvni+CkATBeBBTD3Kj/Qnz2O2+j
Q/miEYTGvGm/fgLATSJtGHXQIs+xgfvA4i2CW6lzF9kyR+lAcxbchvou2vhP
B52CR/ffhAU/BfwWsYj/b2ONf/vAZniZSF59ULlK1aM9fG19QxMhIAawUvY7
P6CTr0OvzOPl6+pZbiP0NVedudTIWo1bLFDkK7ScDgh8H+TPk2882SSOXd9m
/hGUGeq5KU4xoSGD5NecQI/1YLUVc9b/Q3Wx+ixRcWTwqoXYeFI+oO6VGsts
3MaTVQq0Dh6GyxSs73sDB4ULXTH0JtGqtEw7Vlop/6GaYf2Jabmh7lX/0plR
x6R356WrG42m0piDFSwnE62Y+EHkokRDWf0HlRG++2TRYVmZDRFhaRUnOV3f
KEs7TZKXyFlR/6yfnFewc/z3HgI9pv4Ni46tq04uOdgCDeW6RthBMV5Mj92U
v2MsMW92xBxzfr+5d2D5/O767D4mPp41oPWyZmHzoJdpPsSS3EbSNK9QUvJL
n0WD9Y7IZASoC0jb8t/xFKB2XEKUAkrXGLVnf8gm6WruBjkrnyDbI6+vanGE
bA7oUl1Gy37mOY2kVTiWEfWfa1sXztxmD9qW5RGYhBLLgCoV2+2iFBHMW6os
j7cl58cgoCSiWt2JE2bSB8DgRvu4M94wOGowMFx5BIgfGqhQBZk+OjkBjFux
d98IB8rD7kX2wjZ72EUuy88txw2Q18yxgSD7jiaFj3ocTZuaa8O4YPeO0E0G
wz5caEWD3348yypZcIqnRGBOAruLI9wZIwRjxWa9p4jPQi5PqAP42UK5obws
gx3D+lKGqrm4CrzyjzzrgkbWEducs8DbukE3L+SZsZOY9RZ97IupeYw//pIU
v8JKWNUtM2olY5mjCJaKDnm6dFDMYFbQNVPAdOmF4jwvTHdRc6ijRQH/vjiV
1nx+4uZhQTOzroLx45BR9mNyGg21sYtEEUYfNwOiJlvEjQBbpsVCQ08NLo9m
B2qT1ZwybDxnNmI9eSJMX1mBxdTAYW/OYOvBcAg/zRAx9Yw+iNwU5RgpjBXr
kXIle/2zvQ3G8YnWbl5QcBla9qycrqXZwXZ9Jv3XvPr79785lmsBXQt8CA60
P+PWxBKzFeDkriUFBVB40Wuwi7TGVA//EHH/kCPgWH067+HGZqTvtTq6GpxO
bgnhpE7PhY0Y+1A6LqGChbmdnbXl+iO2ug1R2P4LjPtrxMDMdxIvcRETHBRC
NqpJslWmup3ge2xQ2bHr5e2ZBfHtMuqfbyf+/Uf++Rb7ps9a/vPtrI1xFPr3
qH9ashFa8J9v/6Z5BsUgzY1tysJC2+LbO1YMHNHff/8f7Xy1APyMYp6aGNXf
/dSY742mxgzd5YgxT4WZoob+96ynvA3vewi/GwwoGAZztFbYonHryZEu0Cgg
nGjoekk9CyBjR4TXtcvNhKOzARX44eQDPkDyzaHMCqe7EVjMtc5gQ1QZaOqC
5LmE1+IRDczgFbbcMIY9EX2r2by8ofSpUZvKDKr6Jo5PEQeEGOkNCNtG51FO
3jMUU+M6xWPqBVij/ifQeCWSt8TJNjH6AEKAREQy9HfjFjXTZFDOJdOwZgNG
bRzMHuhdZLkDxy2iYBzhAhOPGHXhMsrlGZK1zWnCyCmfWFsfk3cikiOnoj3c
BStXhD6YasVuxTCj5XaNXcwp68H0MtOzGwdoHo3ZSq/PZJYJJiy1lJ6kCwow
LPGsELYKxYyFDUw2zBrZOQi8UypU79FIXbbHfGy0qpUdjHOz9FaThOnFPCXv
lalRQDJD3J/g7KM6Ik/QKRTpUpkn1DpL6yukHJFI9rVTBEUXgbPEX9/HXukU
RNSbVmp+n6UFxchMjJqOVqa69aXHGGxfqZNnbjhvH56DgbUVuAiqK91Za8fb
4olZUMd5xS7F/CP2xjyn72/7bIk39HO0imeaD3cqx888OAB+s0sztKH5K7Rf
haMuTD2uEmkZ/AkmtNf2CH0lfwP9v5nu5vFcSkPIdFZ/7UH/dbak/BTLOgLE
9IHdOWZCY+kbjmY53ymcYQKcz5D9Cpennav72rnRKe6IHE3RXZE5mLNp+9lv
8wewY85+yeV/FS8BNvpGvSDPaXpnH9IDuNIfuGdKIFCgzrVdf+vLUKV2q7SE
AzhSzCT3FgtKW0LIga4C+9mHBhw1Hy1NMbw2DsXw4DUgxMzzq/LBaidRmGFI
kF1QJAWb66cvLbaBLbj5RGnfL2zLVXEHYyUJAyQiyTR3EocO8cNGJUhPv4Na
tzU29xblLuC8sw1hopWiBpAc5hlKvMfmqJZ/plOZ+dyxFPia0dza+6J1kCAn
dOH/cuYvsmiH8mCG+NkW1npGu/UhBxIeA3ofzAKJ6JfFgnVzOuzdmAZY+KIN
N+2GXHwYXoR1deGHIUySX9GChbYBc7U+pdVRcJ3tLcqj6+qHttHxfbANuH4J
KgIhZ7GVMPkpyjfTZkbhtlweF2u0XaMihE1da6ti6PZABcrcchXySPUSFjdJ
lzBaOY9aAkiZLQDJYHFE1FDukUkhx+eJQK0lNRAG4yUwVUvnvOOT4dxk2inT
boUCjoPNQwgenfkN/XhNJ/4ibio0Er1ARssLgcuikBnBVy/O7M3gVyZ5Dmrd
iSYTdBhzuuTK/+gb6SybOtJINSB7r/u07Fgt6VJ9PVMEfHPwpipbh0269Ybd
WqNrRMsTJeUJs+zU263tKQXijsap0pPvcweqy+DES8vU+Op3Fo7iLvrQ5JWS
92kz6wluvEYIaxjQ4gvIIiFXR24GbxzL9b6LiAW6+cAfx+7nzubwfQK1EVmE
4GjAGzLwxi7Tqewif+S+h2H6cRfCjzyj0C9Am9bCmoKlqdFtkVmjHWqIJyBd
hULsYPWjebLwRU7MEh45ZCbPHIS6rxlA0RMMmfPKlUDDgC08pzHeTzxcp7Vs
BkfnDVYTbcUBRg6lmQwyAzffQlQaGJHWUWDU1EHAj4WN7LEZ4WFFaybcF9Xi
YmLNIxQQo5HUfwH2UlBtdN2hZzFnzoRuwnzuYHNYRr47dOdpdopbl9MXaHgO
RY4KUx96pFUwUSHqUOElvl6cfYWqjgvO589fh7NNywS/dhCgBlCmJYI2flQG
QPEc4Q7pBTV8Z9lPYb3C2yTGlmoR9uMYViUwACocbQgQ9dSEVv9mR9xbirKZ
VzUW+/3z2c5fWgP7tw/xD3/EpC+NMaDPsc/gTmlrYbCKR7jgJGHwUgiaFQi/
trPlsjivwn4jw52Lxa/+6JI+/3qWztQKzHOZ20GEDPufU3RU1NwGQXuA4gaR
wg5SMg4IYYAA8/tFQogmqb1VNKVmBLpEbCBb6RziX5aUX2fLxMx6xx5xWMxS
R5Oog4GAOx0OadZ4slFJ6cOAmACVFqsxzkeaMHKA0AVDFNAoEEjUBIPOV6qF
dYUR4kFwRSpWb0k3gYkfyixeSuP/M1nZylIQyFcyrHQTL7rfDRiphgIm6xMB
39yx0YxglIBcCHne8KOYjW6+05S2Lph9tqsbPj8zCbTk35kEXEV6R1Ab+Cg5
G800jlwf/KEamazPd2fnemdQwo6BFeU0wdDcnUIXGkNSzniy0Z2SM1wM3xrh
7cE4EM174KwH2wUI8wGyzJjBKBHE+8X/FQ6fCujy+6l9zsMlHKoN4XBYB80c
X6JeYHJaV7jWWbdV5nefex/Axgg/RdsG4klIcDTwlrKhj/ZUjOtwr0PdLfy9
dJ9FeB95fhDuqeN+cIuFG0ZGJ2eWFzFDXrPm66JShgVjsW+mcPymSYBvdG+/
nVzU2LegAv0mej6321qXXfbJN7pr337/XWsVrn4YCAt/4yPrtZHfvtOFPPIJ
ejPy8CP0Xqbfwp2BQyPqDYLDo4X7nH37wY6noQeFG5+efJzWHiXycRGN0k49
TuuXFvE43t/gW556qJxl8QHvdVgJP4c3WgmOztQ1RsF/+yAOrTigRhOsd+P4
Hz+c/REV8n8UALWGskO02D9aJ9+P/ptqTTNpJBD2FJ5ROLlweyliYEAeBARW
4uiIX8SKgp3+C7MLEavygUQWpOfMETW4i27LcbMW9ZSIa3OoDNfRTtAciFq3
P5ncoH37F6U3/PfyGzya2LJ3jlrY76U1vu/GozXJoVPfd0Xpdf93OqO4D2A8
yI0WTWB+ME4R/B3z49FOOBvMbYuSDtIfMLE/Hs++yPCM0YHhxx/u6PZqGKiq
IlfwmhJ3yvsXkE8KPqZcUCjm0+vWJLJDgQfUj6kC5WSFwnc9msCOh3yaH/Bk
3kPp/mmXZmYfdWfmBOw/cZpj9/9kpybikMB097x6TSYE/w2mppay+m9lar5r
awaktMATScSH2ZvC+THl/55G59Ucaza0RMXC09TOYWEZJyOlvIGEzssD8y1s
CZ/abIIunGn/h9lKkP77lufdUzB+PJhb62g087cooyFkfQmY+7eOs4Bw0WIJ
X9GqiTmU/VukDRI25jg83RwOvEPPN6apoOg/ODKBqb9V7GOUWJJRpUCbJuJG
FYEEiaV2tJrdH3w+odC/pXn1ziWYJvg3Mi9+cBSAVX8zU+6XMgzIPuQVij83
uZ+2ct896CfM3Rxb1R1bxqwEJMNZNkxeUeXyXaMXjFCw2wn1arFlhN5Hzhvs
oAFs1aF5SmIFOd642BryGSo+1/fY0iHKCdkqY4m0Ni6+GjAApQ62ouEaQ0Qv
KX5giW48YrVAI37UVs/F1aM8VPgx87119PWQFQz24T8/nP1ibX4984+LvofV
ASRxxlvHx6/wYKp6F3rMn7Twj8sIA//EOfgRIx+4eUXnIHMZRMSXjoXISw63
A8wfOGu9JEX9llMA/zk7XxzW/2ssfcmB89/J1g9stlK3KtdpLKdAIkuRoKGG
LMq4BoREZOXm9yfHgVZRTuvJSWGjcPBRYB5cJmLLPiTgFNecnXZ7NEIyA8+N
WgQ5PQ5BQXvq3Uy6mADfSH87YscZar5hIsJmwRWRJzsklDTPB+/AHhr8uRQG
1h/GsTXsym9EWb7CXLCz93eJZQCUjBYM5mgb+VrGagMUxNfoJ0XunkPWTqwm
gE0gGsCTs1D3u8NJ7aHjqzgBGg7AcCl/xJkKXarT7pS4rpofFVrksPME/CdS
AXxlGuCrcmeMJvFBJ0tv0w315+xCw3fXl0huqrlEv3z9YLFRL9nobx++/noB
DcthU9nf4/zv9/h37Kt5XLLdxQ8v5R9/0ukyfMO/5G5FOFrhJdWzRMJDwwdE
/PpkBqmDQ6vvB3eHZ5Qk6gtwWsbZFmklAbcRCBj5tmsT4yL94sDBpxkCPktC
Cg2wUQSuKnyVlVQ/lTjZYnqtg7JRpNeQAEfR+uJnvnYj6SlaIEDssZZu4yr6
AyedYQvD/pVoND5gIZf45OJM/p3nfuwFEzfOQOwObx5vhAn4HC6VJYXa9F/s
UIfW87+ZY/2eXx2yiv41nvX3nIdo15iSRHQIf8ZRNlzmEE3t129wtLBJGFEk
RUWRkQ7AcQMZ5zOoUEBo07ez0Dk9+0EXkJMGsGl0JiF+UvSKwk/BsZV7RcRM
9O2oJ0j6Af0hGuUXXFmN2v8HnycHiHqkP2Deh82fB+ee/hAkMYdPfvBxNEDU
sxTXAn8epKfFG8ETAg/9zgPVcFEPE9Ohb/EHyoI3eubPPc8cMeqZQGapvxr8
919YSfh51GPYp+uj/hz8w194EP7+5JPoSrDniRgK6qEhf6oKjP7Mw2jMyANJ
ZDbfdGQIdL1WryevrfY47SqL59FvL+G3fz3y8l1BeCL6or4fnW2UuujyB/OO
om/RjCkY/yQZyAVBItjHlGvkekzuFXaLBDEpQlgGbEKHF3M7j1xpjbTjXxma
iFqkn0w+YjhC0CZFsqNMbIonaBEJsAAVai0QLUBLRXsCgSK9aMcup/lY5sTQ
lqLN09xW8sRwa2hi2OBeIYfFtvCyBLZq7OXC8aYLQdLGLFGwO/5kQMU8gv8X
BVbMF/9vFWAJ5zPprJgxAhG3dY+ErbW41Yn9T5h6cUQfMT3PKjdTO8Y8OErP
xhoN080z4hVY1AEfKt2g87cGbo+MH/xkSMngAoq+9soD19J3vND/r0WafijE
cOJ4/Wio4b9navbfGiWQS/J3X92Y/+co/pSjeELa/1c6jD/pIjIz0R99hXr9
tYN1iAHqQZNmDmxCJI/DDy/Vt6OTlTAuWblQqiODNcPTVId+8BHquxGP6INt
a7bclfR1/Cx46+CIffb9S59/Pyo9uQaDmfdelb/l7U+joJT2Ct1pKq2UYWbj
8T/s18GNV6t2yjf4OUfgpw30dw1tbp2zFefg5BAzh4AtAzuHqIThlZZGYjNU
MPeFs7x8oZyiRrIHZUYhsDqwkXA7Uet+zg4UUwCxS5P8VlOHiLamkLFnMpdz
7SeqtdkYIq0u8vVI0Wv+KvQt9iw+ArO2x3DpSedqKVOD38xoRMVHO/2Fk5Sp
AWXwzuy4BlH2AZggfSi8xO6/oZ/grgjqRP4bfoKCLJZMDKHq1+xqPpwiaAxR
c4HfE2LmOvE6cKJENYL4ql76ySW3cvP4AVH0B7//rn0fzFPzUEnM/cA81sKH
48XfogZTI5oX8QL+eHIoETmiYzKOBns+Hib9UvCCnLMiB+2bl4vUUXvmkIhT
N/ZJh3uoG3hJTEXsIuIzHvk5b+uPn8u6fa3eYPTOmQ7cko8grChHrd9s6ZCZ
oxDFFMrJBepDi4fUDckgSkTMn5OCiOwYYBm06JyfCX5tMgwZqBhh81BpGboZ
S43HTeZBmTRc4MmCHITmCMp2yVBVf+CiX24++uu8kg9Po+3unLVHhB84Y7Bh
vTUqwS2zmlyfmy02GJ4DrMbRpzvcrikn2d+Ox5xw0MP4xZw3mWM7AT5v1Ljk
QALnN9QBb0R92mDDWzFRD4mdfSmaBW9s0ecB9tY6G3uejlzCTgIcoMEMhzGk
T8ROKgryiY0+EHtbLEvT+pKzIzCYoX3VkTOBRb3QOjXzFGifJsPWl5DwyE5G
TyJmT/p3daUuyNsx/M3QtwSNndIL3NbrEtFEp9rW79FmLow6TkRx6j5J0K1r
jwXJHFaHw7GBQbmrCkeFTckm5nPoggRLEOhpsQGiKIe5gI9BuLqSR6qJycYe
4+VVnaO5qI1gbAZbV5Q78oFQfEN3C1RThCdWumWx2LriJApODywrp/bT7MUk
+QcGXoIj6Twg8G3bHS49B7CeZ2kdCAxHAD5H65wvS7BAAFFbvK0FOpYUHRhY
SzIkKRFMtB2A+JR18OyvqvqdHaklLDKn1IcR/qGzuTH/8vi/fvmbxp0Bf/lV
0OTDJDkfPkoknYVkyL7qHUH9B/m4ZIrRErEDpo8y2Ubi/gZDM9A+nu+WQS06
5JyKSDNGLokKTjAJBXJgbOsndsD/9gc09DuGalXFmSB8uNEZVINRsv9lMgRA
1g5XzXq0KrDQUmpbiNwIMzgizY74Mjh5QDjKtDn4ZpwPHwUrVl1vEPrEe4Lg
U4/kJhqNE4DNHGVM6IzT3Uc5xTu+oM+rtRoxF0L2R+HUmqcWhQtZi7eZ1q4X
dSjhisTy9XY0uiAn7gnZNUfqLT4122xcjaXZWLtNhsrWRVohaYCxlZqSRSbY
JuRu0HS2/R1EBzH2st76GNjY2UdNjwcEI1o1asXYhg54+FtbPF1BogyHmmJL
yPAAHUck6ZIiwEGlCS+6gIUNbIulKXq6XPT+F3ocZA5kCwqxoD2aWJPgNi4k
skSuOJ8BmkC0NhGSkuh4wb1AxUVP/8gNLiozkvgjiB8tsXIcqSFB9WJSRW7a
qVso+hGfPJ2iB4XPtZSy/FoolvSbT4KK3Xuyy05pKosiu+yAXAanFeGliVWP
6ta097RuIoYxa7Sk0n0hovZUd6qDOQN/g92UbIrbLeTB2QtDwGhLCmrO9SL2
DEOmerMfMlmQfwgCtyDP+LtoNhwsGohsLgaCSkQarsAmxXY30OUA0gAYINXE
spJFQhgDTSqlDHTvSrycYk2FJfXZoQbSGmNBL2jbSBKaOyTfIEIqB+1wJm8H
G3FxtzyYzdM0Mhkmea8c6JhCvFAmeYwYlaxu4hbV3v/Uad9o58WhDp6kxw1R
jphW6etdBF4B1IfgDRfk6BEgBj37ZgGHouh6IKKpFJPCVi+CtUT3JLhpSmur
szfwhSQjxAE+NQ0HT/TjSywqgLwPopyg3UaIW1XNbSNrBUaiTMp8FnQg5YUK
FBEgvx3Oq+FqEZ4Kncag4UQHhcoT2PlHsSmk+XbjoKEGG69MKU2FUVvtGFBM
qSWCNmIUIpdOgNFGT7SfoonRlbOQRp/yhF+DJVxfTf3OuxjBmGKXtUi+bk9s
OFGJT+wXtGN0T7Q1pCZiZvs0RVEdmLu8OQOgy3b1HeZiOAudguAhQr5mleIw
bDEJxWLWmE6e+I4nITilhkxpDm1R5xpWUCSt3jNYcuwoUgc0HrnSNCRPbutt
cYQ80vNHfdE3b8itM3ae7aGD8SIgO/LWsguSeO7ffcPsEXks33iYtZYT56xs
IrmFW3VBdDgwJvtXdvhngXeLxSRBjlRcobWU5HpC58ENG83tA2XssEZJpq4A
NktpfnOWQoMzC97xofWM751xWC5JdN3s0LtITcxw3UmhGOAREwoXmQsxgUhE
GRZQP+q6zqB4Zrai3Q9wobHbsvfWM3rC2p47FHVa2/s1Xf9AfNnnDBHEmagT
L3KwTASYkq3giH0fubPBomA6hC0vFy00PklG8uFNMExU8QenyIN8VOB8Wuuf
OJrEqAVvA5deX1ke+ECjQwdskC3y9cmxOK+X7GZsiibOTKtWPjytheU6yy2l
BfoYZTvIOZGmc4bDuX3Z9w62UduDwkv4PqAkoU/h2ZCdIQz7yZyyqP3o4LXi
+RNu1X7HjcH04xI3bge7g7qAa5YNbP8cxNZ2iR3HBrYLzJlgfKaNVph6gBTL
mIQ81NwJn/ckXNtB4kwjDhuUqOr2ajkImF0oK+aTKaiouQ3Zy9aB8j4ge/Es
aUVOZNhrpDeSNCvIkyasMbazgepfnd0pqo4JzRg6ZsC0Jkxo7L6lujzqDD+q
REhraonDKCK/YNja3Pytv8X0Oz8EwT5GavJbdy7inbrQkJ4akXDyNqjO5nMs
9gFs+Q8cDU3/YTQj0WpBBbxBlkAGfQuN3gzVrN4x6LSx5bMrAUA0+TqyfjNq
V8TtAJOab7RAKwgbFNBAmoaccDvQdIlDfpElCkP5rRGJUjD5DB2veXVa/A6u
C7ne+LZsE4fojokNtL//aoTcRaVpzeFUcMK+AJux5qBCKFw4y/Si6HP7Mxtf
mUL0eqjO2GCxDO9OyuxXiQ8LHS+0MVVbOcNAPeFJQlMRm15CY9zlri5hK4xu
uzz4BWLlA+B75YnF/zCNTC00Ie73p8THxIWkmQqRLAA/8HahxKrR7CwC8WCA
Rd6BFFMjYK3ZJ0K0RZgGoE+DtQdd3sxFgvScgxSTBjO3LI3CML04Uu/PNXqd
xQOkmFbSuUo9SjSJS11LTuacpLg1q0j5XW4bl07+l97KWwzA1t7okyJuOu+a
gveTDHeM8KBLRV58KDQphtyYHbDRzeJMXryNNI/ka4KU22ZwxTkGRVogeFZE
rhlRLLQ4ROYa3Un7dJAN7ucIncioXSbYCtQ4aUhUvhQUH+dymY71qSGwzROv
MkFyY81t4KOxf10wSbwjDx3NtIvIXiWBnkUC00OxAghCIvWDHepIQg/lLbyQ
6JXsKTMEM3zH44lQldTMSwPRmRPiqFLrRFW6bLQlWlhGNWqnk8qeI6/JI+/2
bWArBNG4dmVEV3AZtPuH+IuuMviUtTgRFBXxEwKpCjkH8etfo5Olutssu1Zv
sOoSkImGPNaCAcHsrIrKhw+zoGw2PWrpW/IuT3BeSQlCZYnEY4jZUf9P6m2l
xeogjRPO5+GLMZNnKxqe8YQtJ62QBVO+s9nyc6+5W8b1Bjs3FJjnsQRCSwdz
jir9o7eb11ArFAAB688onNeFCLA0fDyrg6zS7QSqSOWOBR9Gy41SJxDwFIkW
HO05/lCTLRjnzEM8UZbV99/ahC2oACSqC7kCivgUmV3gLx7JNr3xbHASijMR
50lc5kZDX/6iQpCfzdn+bohD1sApwM/xzrt6pIpOD/hQuC3htLHCqAoIVzgq
rysHXrwI3cOlkT4/yo7E8sHEwexrLyPoLRDiFZrIhXE/B5o56PDlxdzCeucQ
ChNdyb3jB2oTeRptyjNxEe+LNcLI/qDSQGw1RYohy3wLR2ASNIP2UiAMNaHW
sca6ODOFYSwmxaChdUCEL3kHJJlGQey+6WFJwBUmDRRzGwg5y7W9rT8/osgf
WYMNb0mBHZVFb9SRLcLe4JIfA/UZEUI9JEfBMgNAMSRzAieqbw8oQAFinUbQ
DkyEGL8QLeLpQHMvn06JGdeXMhFi3a7o3QDCcK0grYbSk6bjxJ4vg2k4n7ry
UXRLPwe45gCbAbdgr8//ImS6gw7ihDtwhk39KHICpGujPBbr+x2KgwEtTRsh
dpxDX/RJAdICqtkHRkbxq2wVzD//8DVIOhZpqtBbWEbfto8G+CPKntCbEgCe
wLjFFAUHKan1b4bTrDXw5Mh4MzYrkVU6WFvmGJbb/hyYs0VACaUAnBQfwbzo
iRK1tyvwrhe6TNQToFs/0Jgz+ILSmwsdILDnAM/DNa1aVMqF68gI2Fe90EDP
teg1CkYWjYMbHAl6AXvzdBsWw/n7m4ao4PBtw/CijwRym8mquivuwUVU1lrb
ZsrcyOkZOEwXj1gQ8EohR+PgSWngKIYKFAeEodIiJL//nisX8+0O83YVhRBX
zKJZI7UPgkSWFVD+1HRbGgZ8jjJzqFf0WKJ5YJ0On+MrP5l7/jKRoweXppBB
nzszghJRhJMHDgK3XoGxyaM0bjx3rVRoS+LJ+DJ+juhhLnz2s2Q8flavxPhW
X3aOS/uzfqc+TX2A0Pz+gUnIuffh89mHvbeeDz/8oVqJRy+VML6HQ56incgD
dZmjX8iXVT17/2Sz9Z98HXMen7Hduj+xgPz2t88v16n8/aruzVar9W648VNu
/aH1ULuqP+e63vH5kBndzfrb+1ymkf/t83srI89BcOOpTZVZJP7OYTCIXuDb
7HhGCWJavtgHXsXKZsRWIxZsI/+X3vaDVhiPPTjYcL/IB4Za1v9KS1EAaQ7e
+IVhvwvwKP5/EHmWT4FYdsK77AQHUEDkmKmEusQqSpkokRMgbwilYugswBGh
UlHxIX5oIw8mj5/qMAxmMLH5nfHOpxJU9PGsq+LCyiOw17wiinrx2Et8CQnO
eM/HlA21TJywuFzwJsyc56GuyNnz9JG78bYiBoAgq4DnT+6zXCz9twjZPZEN
GTKDYbAB8x01mSSMCfhJQeoggVBEqBFfVwE8CbcQAwcrpLaEUL/40V30ebQa
dYxryCiMi4fRQ7ybtBmZMosIzd+LBlA+WK9suMBEaJK07zSMwFjS30CCb9fS
SRcwWAMIeDRnw88WhhAEvI6WlafsuadOturJRL3oTnX6BF3omRx6Swhuopd3
ICsIuYGCxkWUSxDI5eMFxspmzUz8h4jySi0mBdz/+uVvwVCw+NKvyqUW8Ym9
pZxmtMMUgpRUtMHapPpGzrlPygyCOR5Z1SaEtxkGAMAGY6Ikr4OrZ8bKBZ0n
J/7AjYUg9RrRsK5IZskexrr9TnWVspiED/J3X8odBMBmDcMlqgBC+8Yx0M1a
ea0G/oL/kWO4T0EuTph6MjaIoRPhJZn2lWz4xDtOixZvKt9OOtB4hK9FHvHY
29SMxpdFv1oOShYAMekK5UEicqnXLASUMERDtnPXlilG7GEpYF3mHQ9h+6k6
MgD/5SE0ayGCdJgTRny4FHNKEipHAOsTfN5ICMobzJMhNwgEib3W23+bIXpY
Jnhb6sXBVZMvnyjdbZUgodZaqkglZNHriAhwlARZWthHxDUlV8407BXvgapy
kslpDjdA6+kQkYMVloAqzgBtyPv4vKNSiR9PqBu5giYqypSeCpAQkc7kua53
igYi21rJB/MJQapaBxaeESQYtenO3myo+o2iPxGnWw9tGq1vAtnA966x6rkh
yUEcnwKF3haOHuws4H3tE1OI6nEroyQUJ9fKtZ6Rp+D7cfaADRQZe+D6P+Ak
irNvwzc3GGVE3RI4mjyjigaHeBlQMuizQVCObNxfRUZQE8WRk+H0rUw8CRqM
MIAAHyxaLZr9ac3KYSJqko0c7SWgpZknwBa1j4jTiHEjoKtyGtYZRHykzgV0
AiWzCVghL1PERnBjQ/SGhJSVbqx5Ue8ooqJAvczO3siIIsCBBmQfda+0eCKL
Wafbhay4VxYEhfVM9aELSOEHaHkBYXnCZWTyx/FDMF+pMQyuZwkp0UEL9mHk
zDdrEUz0N97c5vhaDTRMoMIQRjIiS+TLoBbg3SiLEQ47icyFqNQVJU+IlNfe
VFa98sQHnyvqBp6JInELRlZgDcKVCOKp4LKyB8Ib4AJRjRS2RzVACgvM3YB8
gM9oabi8WqNAYornI8oaMSqP6lHJLsSRIfiCBYUehoXEzprPIUXpb9cja6CQ
8bR2IbywaNnsHxcL4EEYyAXTZJZ9AHZx31xD7sRZrj7OP94bR694kt/7VWT9
5Q8NC+z3iJ/8lKWlwTKxuk97U1xK+V8D/bHcMFbZ0ICKyBypNTfXspGjYJKb
6JZF2FiaHsZK0sOIuYWdOpymyutplOuEOAKQklCHTMJBTluE55RDDQ6ptcQr
xrZFSG+UpKGckIwE8z431oCMPi96vtHYaHGblRgxsNwypaiMPSyYY0edCbSN
MNnwoj2jmSbU3YW+ZWJBReNpmhl2Pcfi14UNTqPjh3W9bmAQ+pSSXselrQoS
BLdu6Hn8hg4vkM537fS3uhln7KYekuaCSEUFgkW1dWCbYnMmrIks/3V8/VIJ
3Rw8XN5wOxc8pPI7KqzCL4Cw4X/hdiQBPULz/lUvkwAI3MUZaNsFkcbjqMrc
N2UMHAj6nXoV8w3gQQgHMqujjajyiROP+4Vd7T1XYHJQaCJC1tJw6wI6ALxn
VBXpTyztTTkOR4RjDMApd2Q12aCkH7WyJaANLwyz+AZekLABwCp8a7HFzC7W
Hmqt4f+Bry+6twvnRpeGenf3XzVrwCRceXQOl91lwDhYOIftkktEhEogUwmi
4IIwBsr2GZZ5OOrEi1o0PifxXVlgzb0O1YJaAdCZzQP5UpQIW9lk+FQmRsDb
8Q7/EBGFqkg+Q/9eA/+rp6g8CjfGRNgMw4rhDLhpPIeAKjKtxj+B2ZoQBXco
/U7j2GISVuSi8RJCwXXQjjDmLqWHvk4yRotvFjJaKQxGmX/pNfa3Wtg3vMDU
JslcZX7wap57aVrbGl5ahiJMHLRr/ECgoU+FMc4Ef16rnT5r8BZ31AIPFZAb
mgHvXC3rrbXwkmZY2VDZuzzq5ZsaxXRBIFrV3b6ISqJr6FFgXqSgAIYLRQkv
k5mDCWTt59bbUbUo1gCogUS+I0gj0BcnPnjJDkFFRRgbVpVvKoHLC9A5GrgP
mOlLYVuFfQlVQhyYFmlgLNagnhj68uouMt8abKqI+zKEfYHjBLQGWHWJXCNh
nBKyB9JtCe+g3giV5IPSRYFEhbZ8AXzpwFuT8L4UOb9o1g2xjFoXUyUwZGvq
oYdWB3JSIM3e2vExHS/EL3xROfymMM4Jee0HBLIU5BH1WBEhIhE/kT6LstdD
McOABgnAGeS5gVsFP9dhiNL+bfEen/Bu8MVd4uONAa2jeL4OgSCEGHhdMCpC
A8Gz5iOjI81HNdkKeIf4ADAdt5iCjOII720LpDFMB2ejvzaoaVfwHRJ/CN6w
4GqceQO2B7yPG7xAhC7XqZoudCFEc8ecl6YdlF7wjYgiTTxi/Avj9kTAegJ3
cmDg8Y38DIdfiK20BLkbYGi5VsUbGnn+ddocPhB39MnJENxGsgBZq4RWxpge
1hCUsYJQBx6thbdk2k8+gj0PNZ1ArPyoqpPOT4ilyrzPpwyEbdg8MK08Yv48
hb6gt18zfYI+uvGFYNMC7QBj37DoigUTlgYhEpdtO7jveO3RQN5QabJyXQS9
7IZX5LkjZ7wVrdbXZxNnPCEYJQLcLudABaRNzJy3I3DUGhtJCECkolT8lUKj
qZ5xba59lFnwRKZ1AKansHp/cGITDHSKJ/zZ9BVbgCgIczRImWDG0ioKRFL1
MJa8fjqAXr0ipqguSGn1jxTfFG8CrH8SGBsBvudEUdwkMfKLAnIFnicP9XJy
DebRCgMO0UmQsxyI1Chn76EIwEBj5ZEBdYUHYts4dkzwvKPgq0Rya/kTWQjP
tUsQufiQzlba9Voyjm2AAxD3sCdvvDlf2wDaUNUflHmiUeqy9BzeFdK4LskI
rOq2hOsh6eG9s4zXp5gd+xdVMq5q3+Uv+BljH9LgFLgQjUSDmCY2AO4n+w4M
jAUDMIIg3MEx/s4JeqkNMM+HP4IMWR/VXCQvBI84rC1wtjjTMBRj2nI03ZU9
Q3orgIoJx5bmTfYg5Ww1Dir+DLjw4KiRC4qjw7VNfOS/JkHu63fia8tefUl/
VaUbAXX3lV0C+JzEHQke8ORJRn9lhtKX9Be4KF/Zk5If5TTnQKoKcRh0M31e
BCeeRlvHfnGllky+hW9Mik2Zx/DpHIkJcVC142sn6VqNJsx4ahwpcnZiifEB
j1/l2aL5aLXBN2qkAduyjVgUEUzGF3+kFyeJTYGYCRFIBDRmYDnZg/HSUrtc
OsxiRkKtOLxCoc/J6kDKKCklhmFXBgxiIP2y5jygIj5Ow47cqvfw8TaJ5+Ah
E8PI7bj7iOsg3EpffkMoeT5YoASfpsrXBAlsjl/ZUQDfleLdqF5hZHDNeMH4
BM58xL1i00jRNPiHnPY6iNaDV/G/ZHD24q2weIcf8sCiZ74K/jJ1ZMSpFouN
b5Dhx5mfCC4iDCUhVoXELB/+7yrFqXO/85wrwiDsuS0SvRpMQTvA92q7OHRK
ABr4u4t3xjFQ+ukc6HbES3MFo4aFwkYOtQrJRTaFRFxcYrp5xhPFKFqMzpdP
osVkkzp9OjLa6eBCXltfqUmJ2y+kuMTVj8wVqlS5Fh7hU4TXkkKQvfdcoF9Q
SilBD7KTHzr6hsYaQ+Mbgm2CxClhxSF8vQkTqLaLsKf+llMZDDb60aanqEu1
sKD3rLf1VVc79EL5vF2P9ycAPDbPSkFUZSz6rl7g4EiEApYNZiyDvBCBU0dZ
HERVwqchm8fIzcN4hJAweXaCKkw/LH/3A2XLmojjBRQXWlHdnMgBIYbAzio7
2TyQvV1jGuqC3m6j4Aa8XaBm/cjqPn5QIo6SQKGIG6sy4PJ0AWZDE908hEQG
hWJNomcRaTDHa0t871qTbnJdjYJT2RRgbaBayCfi8pyHvR1M9gnnABljeGdP
UQgvgtW+p15L7zMgsInBFyNyQIhqESSPfqqxIMARFSy5CHvXqfrYK7TEekuG
QZXq1yHxWNWHtIHBIKye0sIyJEsWIrFZayR9rlaP0Gd3a+xGOV5noZ3S65DJ
1jbqYkTfFC0yDksl6nxEO5WLM973jxYUQmKB4nt6nTkAtELh7+2aal5HRgdo
gQoNYWBEfhejdqh/z35hfoFekECRxT/++JWaToVJiwNJHL4mil1FJ5YlCiY8
YPBisnKOQ7BE8sM1C0lOJW54Ao4iayK0HlWZjxgI0vCY0OG5JLPaD8K+enmN
tk9kEYsdFBEsWddo0EqCxAEgxelpY+JdJJwEFSOV4ImSCIOMV3FBAmY4QDvx
zrpQUfXC48BknVzaQFeIg6m2DENc5MkiC++AaCLUjUIKEHFhDL9QVK04Psaw
sZ2ECu5rdUoovfkS6xeY/5AnnMKxHDq3W903OXUNfYqjnxG2wzHBJLxsNBzh
lO3dIpiCJJuIwrsTnFjlAwIooL6Wk+cxNp4fw0ZxFOCk0nmsYpFqS+tkG4ok
yQgPt7H6R01HBPNh9BZRc5NGopHTwZTDgBMNUFehnX20ZNJvbe2DA2EIRGcK
2fZJsgRkFYRU/Q2z+RYaU7KqJLR0e0HD+opd1Jv36KolhNczTiQNpny1iIXQ
M+oCW/cdnEQwURuq1hJPbxNqD36b5XTrkSVcohkH52Tn519HmdKPZb9xLSag
vSzPQRs2r9625tE4/hcEqlWNsGT9rexApZtzdOqJLA8kgjTueRtZjQhBJ4M2
LypqTrmMYN9KOAj4Q5uJxD3p663q3SERTvah4HCisSU6kiqk1ePxekku+9BS
jUKARTwTaPaArBmI0m7QffAHfWy8QuzoCUAmTgIK4YUFEZUOntvciuNp4zlw
rWkpJ6PAhOj5qRb6TOWI5T4Hmeto9qKVPRhaa6Jgw6u8Xm+XMgJL0S9bcJJE
1LIh85PiHLjQj5PWplFTlUapHJy4izPRX+juYwIqZKX6mtuAnvcFEHIjKHwC
ySHO/MYFrwiQSFY31SlT/E1GzCTOXwQ49GGHnlgGTXChrmfXms62VluhESdr
Y1ColOwACPAR8bAgdtKnxss3CKesM0lQ4J1ONiQ2eIQXLQKjIyZE6wEbIZpc
UT0Eh3tyeL6jmiPyWaPyCE9ZluRrE5DVvIA70x4sm1Bx7wh74HxXAAnxYayC
qCtgI6jURvg4hUKevIAP0zEWsaHDhRRhS04u6F9QLTIzIbTXMhQRB0yYQV5f
XQQUrjKSZ6LH8ZZxVFVB4KgEu9xFuESJVxPRGzPJKGsvtJoS1DjB3hTGKZWl
XViGukCIv0AOnCr2p8XSrEq5cPIaWeRnW9Q305g4XBZeVkB0HK6+Tfrk4LwS
gQo/rmYeyZAqlplivYigkhLKxKgR5naSaPMbVVLr88iHiFH9QDBC12J67At5
COhiYLiHDAmleIOd5zTqMuHPAfLGcY2EnpwwxZqN2VzgSZahEc6r8QOtSAg5
qh1FGedA4QN9nc5Gc2ss8Kl9pVkxJXqAfXQ2gq9lHuEBiTeXHhCptyFHAkX1
2VPZprKRiVbqW8/FyipFeQFDThd2W+PyUQLyNHIy5aqH9Sz7T3ux3PDyBWSS
N0p9j6qmhGombS5C10qoBrmQwgYet+oCnLn4N3krVaISoPblQI5Q9TX8GRNP
KhGB91Hro4UryGDWrFXjgHFZ4fhmcAwnY/mK1AupPxdbhKDLW0eVYhwnpcIT
MldI3xfWBdoTevMjsDwjqZcCFBpmjSNi4XlSyxLYA6DFozacLv5A5u5UiEdW
Y8jvCr0Gvc52zhBKicWXsac2pe825NAji6rQWJLqwEWbtTxSngJXyyJMbM4d
lIARx+EZXl1HqqJEORF0/SEqQ8TqQWIZaeXIrYcxlRYLmLmGQg4dLgg2juZa
AwzRTIHzBatTaJmtHhCaBRoOClukY8mXQ9io2ltRTlbUf6GwdaiYEiNBanO4
atE4gzg6DIUHkjKFyJgoUAVGjlBNSAgrbQLNgn+XjOO0d6bbsRqaTDMlpbzl
c8KcKU0qKluo0+0rKWDeZp1SJaiJIrdXi+jwkhj14PDwel8ILKbdEAdauIxX
HnfjfItSWD73oBWHJVl7G8ozDbeU72zg1/rZ4uNoOS3DMo+OE6GrpqQauXGq
FE4Ezwcb3c3S/6wt+3tKBqtnmCE0t4daFxiiiDtAPI9QypxiiR9qgJoGg7fA
Fg3XQYuM6GXUBqzZVcmRAXqBp8+RokTVDqPB94zwYQiDbjbCoAjymVh9iCIq
Yzcs24S5S+rAyIiY0vkUJfWFLKoMyMOvI/kDlX8jwfJ3HxG5Mp/yVb7iV0ED
YxwOve+C0gPiWJ2amdg+Zy3xMtrPobMBgmVApNjDQFMu2QheNUQSBGXIpMiO
taJ+5h1S4fif6p5qMJW+HS9pnsA/xa4RjxmZDaEVYTS1RldhNYKiKVybRpX+
VbX1hcNGZc0CXcRGwRo5EN5CJEHMJRwupQf6G7AppQI2Rsej5NOg2AdZL6vR
eBZF7kwTu76kw3YCpqYI2BiZKWKVgpPMgwFa42LJzue4ofVClwD1VOAxSO9l
Y3b+F7CHuVj4VV6FKUUFjKOEa+EIChnLDa31kADqzO6AYD+6J7xZejjzAkU0
gjdWUOQZLO/KRhQwKh4PQtuJ3CTZjZjvXpDdBG+lql8AAbjuOxts0cejGoSF
ogju0ttgwnZO0KCoClZC01t6BbCsw9ZrVuQff5UIXNEwS/FFRFGVqOClRlim
cs7U1KOY7+iGnEUYHLYAjXpbfvJrRFUm2sRER6do7M3iCN2ecoQvpV8KOgf+
yUsRaMkmumsNKcARvmgIOEcuWoJl4dfoDHBSzuhpSFnw3h1FselodUdSYvJT
FiRsASGk0J0B4ypY0M28fdl8j10oa2TzHCWAHJaCOkPUcHJyX6R2z6suhCQ+
wyBR6plMW8Sl45+uO9+K7mY6jlOTFjxyFjDMeERBpjhFXAFceLwIwliRsFhi
NTIQnzoRkOUHNlLZf+/XdZqC0yCj1jSB0GRGAEMGmyW7Mm6A1gaSemlSrd2G
+3/0CqI2Uq1cZOaNH1ddeelsjThnRUoLCy2bH/XJWWX7JJuWiVw1ylJRQcc8
meGcx46lX7GfOBvSPJpC4PF7o8+Cao9hLBHPZJqdOxRMnwylhccmy5k1ZINV
vGfYqUOX2Urd8IYLoVIfzFE5yyWbCjMt+3qZg96XUzNJDAYhneuIbEh1nzUA
4NY3maZ4L4JgwS2V8+q9WR08XBxuh6bw3CJSX6Z5PGD/lT6MUY+g2OyRd5FU
siXbtJmqTwvp69dFgnJCFFnEyCDT4lRfxTHjRuISkAm8Q8qpzJ8gAaAcPjZc
8Ohw8YxO4IQQgxHaW1SP6y1lwJC6mKLVq7fIEVOAt4wu/NTdAZk5oaX7h1Zs
qatYSjqZGpb+9mvUGquiW2O+3+EaZ5fWg16rkjrDdE9plzk3MQVXDFJCk5hG
3iJP1GlxPIO8vvJC8SF5+EPcf9nkl2+IRpUP5bbrARW0iRMJrkHgdvMyEKzS
N1pFiTeBY7PlqtmonvkBPRPsC8d5QyDcgzspKveYKWZxiWFidNVEUPvATG1r
7et4BJ1GDb3uwAtiZ0GTjQDsoLUusH3sbGih+AuCBvCMnt7QIIBSBSDMEm+V
MRJUSSGzTjNn5xYzAIFIz+ADNM4uyJCoA6rlqNdY3W5RFYHkkvYH3lI58gbw
guMzUbg4a+o9JOnBok6PEJJrriHQoOnLXnUYDAgUd/KZBJ9vvh1FkGU/XnQT
TM5fX3IQqCp/XODg66NvB5ajiEdzU6vBzhGCCpFSCsNmp6wsX34F6nIxuT3H
0MupkkTR6gHTivw5MEH1KMM8+f33dqfVzXa6rXzuslDOV3Nt3m1E75PwDxfW
Xcod4fqeGJSJQUXkqr3BrxdQNkSRFQpeASO/z0sCHfI61sfQsOZ46oscGRGg
Yf/6nypzh0LjqwASgUL6B0U4OXu9+CJ7Av39VwEvPLVe2K3K5knOjSe6vHPs
I69HhRoWiBqAhUFFhGBBrr2ZHarslWeHfqFgDITqYVd1E6JsEPkbYnaRFqA5
cghxAIsMHeKP4kkyInFivaQDQ33n0VUCNtrB3BOnarX1sERjDag8DowQK2W0
4Q2Qn2lZLT8KxXGi/zNlRcj3N9qN8YbH0dpBePlGQgq+F43pVeVOwUbGWj9U
cFaDoRGtQ5PA0LBvOJbIWXAcC62+L/tAhE6azrKObofGOxWCI7KF5EIFb+QT
78fDMVFiudOLvjPegmTURIvs3cML/iMwfjyWubaFj6lUDCp/3nXI6DUUAfuT
Icdg2piHqanCaKPXZJY8f/M1xDAp6Y+pKbfwqD9rcfmlb2+HHg/eyd8kedsI
voZUS2NpA+p0EPAlX58GD6IKu1hHGYNSooI4zjP0Kalp7DVkAYRry/csaJhI
YgLVD9k/uQYqMQk9/zAMWhZptDNeEwLNTUhnnSJZCtGER/RZJJggN0hFahOZ
1YD0S7jGWq2u6ZgZuZJwUOWXd7td/QrjMnNpK2VUeCkCRQn88m0kLcESNU3U
m8nmaGR7czUd1NHZoLGd5oaSnooOfAex8cczS942Lv80+zSaO5K2VdY9Bps0
S1CbSRaISgVanxpFm7rgOou+2DJtbGSmtXiL+NzCdeFRR9BvJulnpErzRTZT
12Nb10iJQDgBCaAEMv/jWQ31ZHCoaBuH2pDK7+oz17OERz32w0+wCjBpvetI
7jgy8UrIoFAcSMNESVDbRi9kR16ioNbFjIYWHvnq9f3LkTcffjUtC6luNVy5
9MWQEx5+RFUUQy22YrTYcu39HK+2FBQO0KoMtwOU39EK0ghF/O8LOUc1yDFD
7MLwZn6X4nrBehmZh5h6HBJJiATaZN0QwSS0E4xfhL0Pwf4s/SGqkV7w5k+W
qCA1xJhOeO1DtGK7PMGEuSAKGSiAcTlkWW6RutJDGYanjCgt81ByOTP5ewqT
bWM3WMOG0Ts1yZCxHvuWN4izRgK4N3wBIyHDGt1QFay7U/4L1IGB+SdJBIy4
Lqf9COxtBJhG5LL4XdES54QJCx0Btj+XeGn0syBeO9D1NNC3lVcjhmrow9F1
JrUo12e0juUn58TENLpU2lBOCil4NXnJcURoR+DRTLioxg4YFRMI5PqNc4sI
hB2WSFpazw8Lmq5BRmgb0Q5HQ0DDWdUj0IYX3VH8QBsi2Cc8OVZj+RtFiQAi
CRb2R+M6eqkfxksC7l+wE2QouhkqVTSEzdpWNCsUjCQCB/B8kB0tlDXQfsmR
fCQlhp5h1WkxT5UIlI04fb72U5HcLodSIIoKc+ui34WCaGFJT0sG7qHIEg+f
ozeaMqYMZ1ToZkuh0AXJNoCh9GxECFODSwJahd4K8l142yI6fgT9AcEPrfq4
TI5LkHn4MNPcFZlcIyZpnfGX9Y9MTB0usONGsF8jvQKnVQQB5PPufOzto9qv
5Gl+lyV8/GcZ0WcTuDibexs/9A1vdME3gDf/EBa4ibwQ1Amq5Z8SY1ypoFzQ
BTeRr5uCUPjQf+EVLkJzxpIQOSu5t7yDA5EgmHsldjl8W0VXFr7T3AP78EPz
4FHi8LHj6EuO6tGoGeSxM+lZguLPYHjkMDEZ6seAkDTN0CWQuGqzTQJGC+zN
ZdbzZo7Yq99/z9brlXJex1RrR5VO55lZbgVYF4iVc0MMVSf/IuqY7wfjKF0n
cdiUXgxIBIXlkZmfzXHJF9XnCEPFwiOuCX2Z7Ee8eXL9RUiH0vN0oOXvB7go
PqdflX8OrhfZbD5FatT+Bdh9YJFI7MNcda4frk/5WTWV6pzSJgZJLcZZJCE0
RR3wWkXBEs1qmpuPV4T1V4112e2l1DC+q26AKACBCN87a7WmXBgIuSxcCM4L
yE0ERWz1bvlc+EnqfAtjgwSIVqjrzW2u50iTkekgFRm9kDIIONYlUltBFE2Z
CVPuzvE6SWysKPdrCT4JSD3e+OF0f1wJ49bafnVAjEMCmSI8Do8RBroNDiZQ
26X4s7XypXC+j1CX6kyqaIVJwCFDTaZPLdtER4lrNBAIC67AySTBJXXy1qWo
gLfFlhPkawysraQRDIgmVHzs0OnGyUClhcMUjQvqF3aybC2CnDzYkuZr3w/0
9bOAbNzM3Ia3UovNQwbtUlC7yzZ7DX4YRAQFX06i/k95DsGDIbREKExxwhuI
dgf/1S7Aj/RRFiFrV/fUlYEviHRVPALA7KKra4RMEMgRBW4t83JCo4Eph8Kw
QybQNRqzClmlvFwAuUEtg15RAgnMhkr4fBEN0QlV8buAGA+DGzQKQmMSGmzG
EZyiTNgK5W+sKFrx4SUlUvizsbXug4CSO6wHd1S7V/Wxq/ed05kbBBOwpm9x
o1UxBzhoa8cI5qlOJ1zcnZJ1qt3QH3o/G/li0CIaUgY+jxkzRWLWPcq8MBY8
cNYlWeihX4qoMEFAhkqpYzTj0rpUSnmomJFCZlag8AShEyRLQy4dbzMnyamY
wQCCAKWLapfmmw0n/u4HdYkUqVIF9cMt3biqBMoPoE0U8xaFN8GFJ8n6Tvsh
LsnSQoaflbSIXnMLyeo8b9Gky7AVfHIpmjfJ1geP1TO0As3esgsZcJfr/EHv
6Hi43O/3l/DFy+16ji3Z7OEH4IMRhxHsmMdqt1VFuQSCdkiMLMu5d+ShV3+7
BOORlg27HutnYgQTAsYSnsZBggLX4Z06ECgmvAX1VZitXg3ADTV8ef0dpZ+M
JB6G6KXvkvYEpW58IwCbjXDhEVdq8O+pZmXQGlOFfX9gRQmM9fU/afNw/lEp
DJXCNAuzg3kNbRjwFNbW3tdcdbItpD1H66BtKcJKQlW8fGwNKv7D/RYn1pA5
DNhJlkK6oW0yCr3YIdHq3DWjMPAz6apvXf4F84QjagirjCBPaP2MeAqwkvB1
k8TIEQpSMs5qw2Hini2+K0DKigpIlHNcyLDcwOIuA72l2vTQjoQZam3tWItV
RKYxcXqD3bcpBqQ4Y4Igcars+cFiKupWjJYX8L3vrMEx0CmPyaclffAHllCU
+TmWlACULa9Amwb51Ut+2mVLIz2bquwL0W0ED4P0BGXQ+IKHDAPfVj13+NUV
oVIjY+q5Y48Dws4Eu2eQKBuDiaAkdOuDXkiUJvCMp6oEok5Rso5K+KhQfUgG
p0kRJ3v+6EFThZmHhtlI+GV06DnxumhOULcrLJVkWyA4tqVFRL/D3gzSw5Er
qzUbK7shaS4sQEf2vCffeG05G8mXwOOKp1LF9H4ChCcqmCFXa2OYxgg82xLB
FwGN1rkZ2BLhQSVTGLdMGg3yWFGWDyxMrT6Od2BQcuNsBpQS2LiNRrlQI4ia
JL0oEHZA1ucpLh+15o6LUZStK2kd2KGkTCqmJ/TxVfSW95Aiow2vgBErEccL
bVMy9/WuQKBPBZEApgLxtV17LKwydHFGskYDQmSXatlE4xaxXRJsCL4R2EHW
+kg0cToIwAu0K3dHdMmxUah29QOf/EFdqCNxBe8PibB+Bc7TqF5CrXY0J6ET
NkpNJKvpwKsEr/KehT4wsJ1Bw/RC8+NJwDL96MjyRZg53UISUkabJQModOr1
uUGMkBEwwTCtz+R6p9oGuQg2gQYy18XaO5J/M/e5n31WZ+dhbutC28O/yKp4
rVMDOybW3FI+Hj9dKvVLHc3ORuwTTAZhZJ1NF/IgWB6NiHN4R9J+vp4dF+nj
E5RFntmfLlCrQIA5wNpM7PkSJiHayJrIORIPUKGI/iBKT4ONbUi8+cpMg9fk
L8oVMyW52Z4j+QIGxcDIBT8WskAQ8cT6RCaiBT0vkqFaVMk6V8GoPi/TFgWh
PAiE40IppWzuI84inSU5O3nykXs/LU8XVcdpq2eWnZl97jhHC/UU84SVAqPO
7THbCqDkB5oUBf4TU6REGPWX0xq4slMlySG5Pa0dL7HOf1CnV4mMZALJtTcn
sBuikSFczwjE2clG3Hqt9M5y5lovMq1Fg+bKr+2ooIMyEHmpe0DahPsTOqGW
GqeAtzp/nRFCEHh2bjsHWilQIAVezxQqmrSyODgxgkYKnTJZEi04J0FEmX20
hUPMw7V0jDA2REuwXbNtJdwMx+TwMixjGNLGeG34+nO0ijgTskwoTOWlSvg4
QE6jfnCwUJCLIIl+xEMJ4A+oiwekUyjLDW06pLvDqXQdyXGgY7y1HKe4QQYR
gnhDRYIQrST4/XU5SaNhsqvlwBv+3pKQXjNZjShAGMFlJPsIMANYEkxS70ES
3weIHIA4C5DCSZ4ADW5IZQAYghkKcAxgV2SQRHRqea+/+eXlJYIEwM3I2Rte
r3nKLvj9b0Obh3coBoLJOJDyICoXvPk08Mn4WrCQ+5FG80Yxx6Xlb3TNT2YR
RMUh+DmEU/Vm6xVvst5PMWbyBC1vSuWrhjjCCzRb2ZwqDNDU4t7xJzwox8Ms
om4wJC3gGNGk2WfM6sfc95Co6pkZ5etcfPDdoT13+rZo8mvx3gVLNhiWPDi2
r6meyKdB2BIiVwKni0WgOAP+2JOIPcEBJsGmoTVQQCIIZSEbMu04f7IWX4wG
XRtxr9D0N54YTvXUEPvMTfYtl+pYfG/wvspUV/STldFHWb7A+ZBwHkwnCvQi
G5z9aKMCdYLnIlI1oDPOs/M+xQBVQh3OrEtSYSfvHnmY3JAc6modHsANlwio
1okLSMLGzOb53A0JuM+ndabquUzUQypidKEYIDUeDK0+nH6gd2V0qdn3R1oN
rSXFiWnJNsPqAaBFMVJBuQqf18bIknuNzy3QDzLY8U7veM+rUTTZq9N5kP2h
Eb2IuB02cgi2kqGtpMVXnZxOvKFCf8/nYqvkEGiJ8RMkIjMCZ8EDMkRlywOH
suo7InYho7CiFIdOsZD62g4akRPgn/QGWzhvwmPF4R677c5Zrd4xmpWhs0SZ
ZkEIjb2G6eTyXTetc60nKPbMkpAeM3wjL8i7Qho7bKv4oK/9LkiYGqKP1jK1
GDuXy4Q7E5w0zhEUmrAMVNNGOuba2Ytq2yiNEEkI556ipZO+KV+/AKQdl05v
7sJGauQfRWaBHzfmR0IDCbKw7QNzI2UER8mk+tJ22+0qoUncIUf2MB3n+v78
bAmDX8JkCbzT4aQ8C8QlAx7AxkIXmcPWjQpqsu3KR3BtdJb4yP5ngYBKHudF
w1YYtGz2PLKAoDMKI5qYKhxZ43Rkk1lYgrzZ1p1RZWJSLaMM6fGs+FB3Mdgq
PjxX+CryNJB2E7HJG7yweSMv1751CX/+IyjveS836ywZv05d9pnhCyNw8UDl
bGoLl5azvjB4+sSxF3cxBjyg8CDx1K88Vcmfw5Ma4jAU8DUIhwLdXdjHICFI
ScFuXsI/mXyxXKP+nt1MtZw9q+R7+EHssVzOZMeVbLqZT0/Sld5w49neMfU2
SA9aqbvramrgvh4qb+nifni3u7pNN5Z3jd1tMzkd+o1Ma72PPeczrv12O4x3
c5Xcvtgf3LqHUf4lfbxZ9Cdja/q23l891vOb1DZ9szm0K14/s6zk7Ey17g8f
KoVV7LG4eMk2d/niXc9eDA65TqtxSM/tcnrc67WmnfbwUzOzf3q+r+9rhYk9
W3tXrc3ccZ/i1t3NdPQ6js1c+1PPmW3au2rx6nq+T76tXjK5TvamVmrVu6ti
Z/5YvW7Ma6/tm5aT7F5b2dohue42WoNKeZ6PN2LbyqF83Tkvla3Ccpc6Xw+f
bu3uuL7OJA92OTFsFwruJ9fd3dS914d8OXP+tNhW3KtctjvIvrYL82as0X5p
jzI5p1uc7Ov7u9vnbbvtjxK56/6nXdV7SMT35Vy6mc7QZuRrucitCG1Vq/yU
7uSNvcqv0uVMOv3n9isGG/ZX9isGG/ZX9isGG/ZX9isGG/ZX9isGG/aj+5X2
2GIXPz28btvPQ++p1HdubmO76Tg7nk3HV/NZPVFZ16/c9XBx667H6fvG/cpq
TA/bivdsVeqJQaY5zyeW7eflp0HFHfTGuZvnQz6WXabdVvelmFwWr9+Gs7ds
7y09STjng6vr6q336pV8Z1259WqDvFva2cfh6O2henN/dW2PF7fLVO45dr5I
tJp38WN3c71tDeK9trc+XyWqxYddsVlq2YX48+Ih81paT95u7NurxuqOLdq4
vN9mVtVU+9FKx46tl03l/KF4eF2WF53Vea20yz8/Z7fx+3Z2FV+nrlIDu1m+
uWnv3had2X61yZ6n0p3kW2HnPL7OKq1Y07ttN/z1qrw5vD63Nsek82btO4V4
ZnTTTj6lD3f189vN1T7jNxN+ldkr7fHLVbM/z1d7N5Zfjj/EeoW3u+pDPjvu
zdL+yu4+LFYv+atqI7XpeeXpYzldcTqLe+926Tfmg1R2XS3fZ0vxbn9rpZMP
2fpjbJCtrVLtY6/fWY3d53nm/nU0SC8+DQrLNBtj4Nwvbna9SqpUOzTX56lC
+6rppWr3rYcUO/g3WX8fy7099kat8SQ96hb3i/nz9GayTCybb+ntZN+vvxQ2
h0rpyX9sTN4S5cymcN9LTXfj1bhXqvYXR2ebiC32DzfpanzZK8SLd4dUYrme
p1vd1r7kxXujm+Qsv08MD8vD+cNLvnU3abaemzPn5lPN7+Y3u/NUqxNbucnF
7Wpj3+Reqkc3ddVPrFr+oD10s9l9ZVN57m7HN6vka3//VM8+ZDeL1n7hNhJX
iflzqzea3t7FMp8OD4nX9O3LVTE/uvZrLbuW3ljbQSNvz8etpOvX4uNKs5Jx
it6q9NyvJFa9Xebwkny5mvUbudkudp89H7Cvvg6Tjec7q9irZkurO7fRX4xy
T/FjafA8rU9eXlPT1uN0ka49tT7Z1WYyP/Jb1eHz7X3fjY2uXnN3D+3EaF90
61f2obgo1a9Kr8Xz2/SOObeV3lOvVrImtUJ+f9Px04Pmc67aWs6Kx35mcFi9
erFUopddzVfOcD+y6ze9zbx+Z28OiUP1uLKSNT9rF+/TqdvutHhu2TX3JV/O
zRKNXOU8v3U6k3LXin1Klpm4e6g8zxOZyjo5vD6kR634q5vvbVvrvp1r9sad
8qI+Hz3ffipue+zLvXG+ki2UCquHdCddjJUPpfWKjVl32vuXYbK4eHrqHfOL
yavbHyxT2YOVf2x69u7AVjbu+4+Vq/1t189tdt1db1dIJhexFaxw7qa4z7ff
/ELjeFW04o+71yWTOLf5h2Z17LvrTbfxejh/S+aXyUP8MLjx1q6duRkVj4VE
I/a8aZyPijfN29xy+HZVbY0W55V9JvtcqDSn47tt5zCY2utJ5jnfayzyj5Xe
vvNQuGlkivefhsNdqdqM5Zt2LZsalYrj6+5LN7WYlNx2ZnOVTyfiq+bDqJXz
EzePVym7mBz09plE43WZK7UHOTeXjv8WUElBlcPtQZG0jDRqwKYxrSqyL6e+
58aYI5H/fPb3f/6dIL37NaEagUPxrFXInqXu7pOx2O+xs7MPs83xw+ezD2we
Hy7wv50h/LduC9EHS/jzn5EaXGj8kw0SEBxfIgXHZYTgEHIDBvmzsmOxpxdZ
wYvs2vPxS7O/K709L7bdTKFVStvT1uSLazU7uaerolu6ng9apW0hU3jNtqtu
KnlotpNf7g6FOsxhNbL6q1XiblYb7Cqjt+HueVk8HB6Sg3I1vYovX9u3ucX6
db7LdK/Ls0rytZS1Bl9eRs9Pr4XJZWPtl2CQL3n3aZZbjga91hdnnyhcx7OJ
1c0+1bp9zpQse3/VTi9pyrgl/dR8cfPwmpx0h9uqu7qsM4OkXc/Zz8277sq/
s+1Nsr+yt+lc/Ety6V02iteryavn3T3tC/C0bLfzPH+w3Pv9anhw0o15P9+s
zLLDQmvQt2b9aS3ZeXyYPmZLz9Wbt9F4t5osxvaxwvTNOLFvD+x7GOTuIfHl
cbZzr0aT22x/5e5r/dv+UyG36zy0r5ybwltrUnF2t+uu31ukXtPDwvVLy+rN
CjN7W2rM79YDGORyve122ulp9rro7Q7lg5d7KNjx9fWsX1jMnNf6+jpup1qv
vcpdJ1GurJk+HB0ON+mpO698qb/WO1ncgXj1bp9p9B+fL8uHRXNZyE6X5cvj
1nOuCvPX4lXVqtbWmceXZuHLvPrazZX8u7vV1ShdPOSe99tFEo9SJTMaZrbd
5mY6X+2nTXYkGr4/a9Ki27DoYJDwY+PAfzdm/XSrWt93v1QHr+vm8X6xGA0a
XnOe3maP9jbRvHdLd41e2+2XOoW3hbMdXpfmqX75pQvPu7fiX25S/XnOq8+v
GoNN4bJ/vU7nH3rdZbae2940Csfa7TZf6LXGl73mfjnNPM5eZql8/+o+kUwN
NmkYpJW5jlcPqYGVm7SGnaOVt4fl4tWgmXtpL9Pz+3z97WXGVuy6/3qYpkvd
+8Xscfiwrw8ec/zFhniVLccbvvrr56WTKhVGryO75afq7S/x6s2Bnb/5Ve++
v/Fex37ZXm8H99vXVO2lUx4erMdbmERh6B5r+WO9l048le6vN7le6/KQ3yT6
68R2+GU4a/jz6tOXtDW4G97lrd7gbjCc9e+87P3m1l9OnsZxGGS4yse7ndy8
vs8cMr3HTXHR7D/4hbficjF9expXVs+rh6vM/fXdnFmkd5vbq9JLfldZrntJ
fpWHeJf78dzbsv3Yv1leJ4eD5rje6aYe19ft24d6ftJaf+lN8+vH2dJ66eZX
u9eraT5zX2otBi3nBiZR3Gyuaxkn8+j0bp/u++uUdTOe5pdOuumVu4Nnb5Z5
TLMR7O2ajXr7UM0Mr3rW69PTtNy2CovhBgWbu68WvOYhO7n9ks8m1u3jfr8e
5ZbtfT153753Ui99y+J32YUp/xmnj/sQuHB/1u8TbgS++ClX4sv7rh/zJL6g
JwGD/Envj5yJS+ZM4GFiDsVllEPxRXMoLoMOoOZPwCABn+IL9yk+xP4gfapH
HFDrttsYeQgHHJa+/18TdIAnBwIPjWyl/bdUMP4w+on4Q1TsoTxN1zLj2Woy
c4r3+3iG+bWFdLrO/NtUWo9NrK83i8XVOhl/Hn5q9Fe7RsJPxs6bzJZeblvW
U6q3uo6Pp91W6phsTQ/W7XBZTBZfSv3GaPfoM3l1Xp0kiqXrm0My1dpftY43
V4vFecxLv0yPzdRt3c3NXm9qqXmvPx7nruvMyHu8XaZ31dlkdn+TdoedtTPq
lwuNWjfVaDzW7+rHdSFdWsXGOf/NnTYKi059k80PasnXRGH5PB5M9ttetVE9
Z5d2Nd8MEwl3tXpzzvsP94Ndu5LO9YbddLp28xzrbt6GS+d4W+13xu1D484b
ON3rjhsf35Rvrdzrw106VX3z4pX28bXnpa9TN4vVoB4vPqWHT/v7+eo6ZtU7
97vb4bnbv+67tVnzaTavNq9GT+ndw+L8MMzVl/fVbC1bu049JZdurj4rPN2e
d+/dpxvvOLh9KceSoeDEe4GJyKDEbsz85Fy6am6klx+P2yv4fDlWQYvgRsZg
J//KRsZgJ//KRsZgJ//KRsZgJ//KRsZgJ//KRsZgJ5N61KKZ7WZSzvJ89uA4
r0+VQiq9GmU+Wd1GfNpJr+pNe19JzCoPn5xm9iWTXcWWfe/qNj7eDTfxm9LN
0+unVu5plh/Xk7O7q6e239/OV/ZbxU+1Cn5yk190zx+YX3X/aDcfGs+Dxu1L
zKqwdy/3/Hg+OXgeL1PFdG7sZfzUfJ5ZxbuTl3hlNBrPy7Y9u3LvXm+Lm+te
YWwnO+nBc/K5X7uOvYwqd/PtsnD0bkul43PL6ZUeH9Ot5kv1wa63hx33xnrM
NOKN+nW/eZzd1FuHTrdt1wdO46FbmG2asdJsV+wfF3eV9TE/2pdSnZnPLLPn
yduxcRtvVK8O7ftCrf7ALPzzt7fNvld+Keaa28pjspjzyx07F0suykmv5DUe
j8xy3Q/Ld5l9++k5kVomJufT8WhwPZzbzH9spb1iJl1/Gm2dvFMfTIrjydPN
zr2pxVq5mj9IF9xlaZpojh/Xt5+6xfhNqzNeDKqjJ7+cKF/327P+urx9quyc
YnF0Z23ms1Y9Xa0XPx1ah1iuag3HmbxdO5aqN/O3W2fStAoP1admfHvVvW5n
bu8e4r3NU/2qdTt/GZSnmVxp20u1p72Hu6xz+3ob221zA8/Kb5mFypzOifV4
2LVHg+4DTvmx4WdLLxs7sX2upVc9a5h8Hlanjdy8smk+VBJDJ7uIrVeLTHKc
aubv7ye5eqm8meYy+eHyWMhU6uXGeW35tHlMVqqTljWdDqr3jUlqui7nbl+6
K2fW3D45seuH+8JTcnGdnL48bh2v00lcOcN0uWq5vXEqx/59d/x05fjsdNVr
8Zerbvqpsh4/5l07PnlYzhrVWKG3GtubXQ6nXKk2bx9eH/ttO75slB9mbWvR
nPj2ZFy9afk3CeflepF4uzv3e4X0w2iyq101P8XqxXIp11relqaP3cGhtCzt
77rn7UQn3znYjX2l6lYr09vJPjV1X5Kf3NfW+Ln0Nn4a9M79ht+y2S7UHp5G
51nmVxzrmzd39BKPL88fnusvw3YvNZ6326WHfSv96I3PJ4XicyLNzKe7fSr+
ksEZlxetWK27Ha+s5djKp1OddeEwe1i445eelV4t03GHHaC72e6qfd20do1M
t7gpPJQytW71zdkch7Pa5uk1xsTWZDxgS3Lf60w63ie3Mjivv+Ze++NR7d6/
GzTvbg7xRjObrl+PDsnGfaJ5vsi95bpPHbt4FV/kY5vk4qodHxbt67sH5+Hg
jJ7uG1f7Wqa2fi22y4WrxbreyjzVaJHL8WbFTZZ3d+2xd9359DKt5WLDeXL2
2nlZFdOz1LA+WXad/afS8PGqXnzuT0rTZG2YfcvMnfqicWxu0uu7u3ix3Hne
9dPl83KrdyzE2ncFd3bLrNOnkn+YbqzSMbF9KBbm1utbpXWdLtasbqf+8Ojf
1qzhW3ZRbKQPtWaznl153anLfLXYuj5d3++vru8fPK/4Mqkf+tuUWz+8aHrq
//BoBRhRWsTi5unyttwu3xzzVrbwsrgczRL5x+Rhn362Z3bjKZs+7tb3zX5n
XqhnX/eb++f9tDudbCqtrQ9WpXPTXV2We69fNqvkcyt/nfaZaVko5R83y2Q6
37q+Kg92i5fGqlLIeN3Z5inXvht2JuXS2ndbTqJ7N4RBSqun4d55zD/aN9ND
pTZ2/Up1yTz469px4rVv6/bzNtEueG/F+4f7Q3OmhSn2l/vy0E7cPd/04tnl
ZHn1+hrfPqaYiZ1Iz9ZPyXLF2q56JSt3SHeukvnH64GTfHzMt5JuGR7czXvX
4y/Xyflz/K3nbQuFVb2238UvS8e6P24sh+1VpZW9ea6O3fjTi9WfWrXB8bYy
qTVe7Id4erxZobPh5PYN+yH5pfrFruxrz83rq9Zo2Mx0V9v0vj28a+cXi2bK
f3JWmdtk6lGLWMzTo/JqtMz2vMVTezJKV9z9KDnP3Zfj+8p0VvKzm9esM7qe
pef75mr1fFu73JSrV/1hvXUJD356HsWbiddMObdZ1u8T3XXxbmm5/nHdyLf6
tXXrYd5wevljo1OaZTsJN3c5Tzr+1jkWq+zKuQWvAoOMMuP0dSXdbzy8Nq1N
ofx0n3Wvrh/aJXdZu7lM2pO1Xcz0SpvZvlTYzBdvduHquL3pr1qDVX1ySM1n
GLdaZN5y6Xy3cDy+TGdu9+byeZru3OfetsX447LemQ26ibw7dcvT41PmtdrN
3FQPi9Rye1ylJqVU5gv6WzfVWvYy4Q1S08tN7nif6u5anY7T273u/NTdoJgt
HMbxqjOtTcZ32fzV+H7p1NiK5t4ex+n7x1K7vodBBvn502ZUGfZG3nXpql56
ffHbi/x7EYtpixkhPefLppKdThr39mO8lnyxWvOa7fWynUP8tjhvV3OpYfxt
cP36us3bjV4iXn0sPuMJuu19ecjGs7vdrtmb1Kx7Pz29nhSm5aeq/2x3lvOn
p679VqwnvFH1+XrWe35auo/L0jjdSyxbj9ez4xsM4iWWV4+VXi+VyycybDdW
k3Z9NBkW/dv67io3msYXzvjVzt8VtnfHwV1hoIcpvE3Om88Om4e79iw1XrQe
Vq/Z4uG2mN7Ni2/u88PI6b8wN/kw7qbnl8XU1TCXuu6NB7Wii0+2Hw+tt7w9
G+U2nZvq02OrUbj+kva2A3/VWJVyx/pw1L8cztkRGNUzT4fp7f7yULgp5ePz
py/XD5cYp1uXb6/qw/tRp+1ez3s3w8TD9Jh9eigP3Ew+fXRyt/nua7+bmSSv
drm31iCvxyac13yifZtdMgXvNXOHuv9SbC4sOzOceNnVLNd+mORz2/aXYXWS
WaVShaYV784G+URzh2HGytVDsplMPLmj3KqYOdy1S4lJvVCfXg6Wb9c3s9p8
m0ldJd82h9zOLTXv0+X03eRLqffl6il322s81lp4jWrX/VG7176y+sNqK/56
N/UXZbf4cP8S/zJKM8txM3stj19sy7/JF7rxRy1MobkNX4T/d/ljXgM8GTyH
ywgX8PJHHQcUPye8wO/4DpfSd8D4DPgPlyFH8MfdBxgk2hfkHsRllAdxaXoQ
MIj0Ii41dzAZHabIZ7Nnjcvkze1ZB6AR4WiFPRhcLtnnpyMVEerYns+dJbEE
DbbrnYpWqL549Hd8tAphxCJCGGdGCENM513sxF+KXRRm+/y+V6p4r+W3aZy5
tr0y/3fmhA1yzXE6vyo/9V6fqtl147VULE0bibts5zn+6Tx3Xx3F9vH8bLoq
3B0y1wVnlz68OYOr+Obx8bpYOJ+0bnOHyV3i9Sb+VCwO58PZLPfymnU7Ndd7
af7224+56vlshLdeGoAXni8XKv3JqPY6Wub85+ur8/j5w7S7vq+c9zv29uAt
t7c3V+eTjPVSTN95zEjMZlfF9uP1fSy9z5e8bvO773fq9WI/935R7/CXrTzd
fstnScgM1jsMqsNBizboxJHSrIrucltIJeaXM2acTkd3netFrb2Lr282tdu7
orO4W7uj23xhOejluB14gF9FL9uXy4hlo1/hRB8H127tvtrJ1TOTkde1x6me
ff9sDwutifv68vqQTiSby/jb620hHn2Dh8mbm8T9yftLH5+8vm70ZZX3ND8E
5L/PP+KjvR90DNxY+sm/P+iY9faZZi9XST7t08d8+mHdrE5vGp9S985Lvn1/
viuM1+Vj8n4wL9xns5+8RsPfXw1ucvG+/4P3Lnzpstfs0qXlYzPZcr78cJ7r
7Sa37fzqqbO4iecKm8ec13RmnYWTXTnrp9394rl4vxq13cK/0+PR70K90jAu
Az8yJ66D/iF+5F7XnMvSstxePtX7bvPxOb6vT7KVVt0qV1aVzfOX5Guvn1ze
VwZd7Tbw9f/C1//SXP8v+vpHnuv2xILz1YbiIB2z5+PfL338e+hY06dn9Ckc
tNvrszVbN28xP14qsiXC/2qnL2P59u31RezHzrUxh6/8bP6Yj7l92z2MMtfb
q1r84Xjduau93t085p4G69Rbu1N27eHDZjYebK9ve8/XL5njW+1hesgMN9Pu
bPjQyGxAv/cXpUk559wuB/PU1Lf86bzzuMmBeOWLSLIgC61zTsGNT4DZqcTa
OuoFjYiZxD48Bvo5UOTHG0a6tu8L1LEBkQdk+lAQpKv9MmpGPlPRlOhIzoui
acn5H7/qnN4wwyh+vR/bCaSi+DTyvP+JAPnfkNjofzTszW9Dbyz5xmNAaP1Z
vMvHgbeI5djrfz7rQOV4Mn6WXq7Z/0smzuLJz/G7zzc3Z8XHTkzntPis16R9
wtspPs457LXZ8OxAXd4kkr99fn7NNawn99Pdy7hkpY+p5cKbpmfFZ691SHYL
2UnhOpFO+ruX8w6cBKuxOE/39+lx5tldl53efL69y9RqR9uaD5+qu9Y+v+iU
nl92D3t7/9tvn+Vjq7Y73kw+nyVSsdjvHyZMA3gYCvDW8+GHPxRLoujZHdwK
+uu/cC8ku3syHj+rV76zxLd/aYkf5vljsj/qvt09r5/L00Fi9XRbeaouh+tP
d9WbT9XryV37wCS4X8PAyjLXfM5lq+dFa1toPg9eM/9/e1e6nDiyrP/7KQif
iHNmxsZmN3jCca/YwYDNauO4PyxAgECbJbF29APdF7gvcF7sVmZVSSUB3e51
JuL0/Jk2iFJVVlZulfnlelCcq7sHQ2o72/1LebhRY5ti9SJuHSVxIgkkZtQA
Is9MEyBHZ+eCzGuqhqrLYklLH2sy+FUhmTuZOjvLPEGbZZljxQn7vZ+FLgD0
Bwd5FQBaUckHj9el35CZiAjlzANO8jLYj1Z2j4LlxBQe2CXzVIRmz/AElDJN
sRAQ8rp95BQPi4KX7Ee9mhoDcJi9THqbct8kWCuHdS8qA9t8J8+dC+00UAI4
ZHt++/1PWlgzuYtn4tlsNpW6Sf5JZqdO7g5jgMAgf+L87s5HyWXCstLLm300
HZsZG+tqp+iTcyHzXgALDQrBcL0T6HmfFYJI26ymU+wuxE/hCttwBqsRNHmk
aNgSNjpKxF+//oSG5ngbYUPeHaUYEuYU1T5HMe9V/ktuJwlL7631kTEuJrdt
PVvKvQwS2UQ2v2g/VWbqRpI36ZG0nKmjvmkpOry/UR8/FXfX2nI0qkprJTXu
SO42Ga+93WQz/RvVvbjYzCrbkdvZTrP9yfZmX35xxsv9s1xvLqWbwryCEbWE
0l2Wt7tlXWm9OfZTNd29MLetslZMTfaD1UbJFue97kLObrejzvVLYvxQmRRG
+85Nwp6Vn+b7LTrkg0X+rb53HhvNWvt+/pAqVpT9szKfP21K6cywULp4yIxj
+v2LM90ObHPWX0upaqmxGNw/6dLa1TAho28U5tnFcL8aVNJP3dF1uzR4NB7T
PX0sGY1qfHbhXFysM5OUk9Vjs8ImPh2kr7u1XuMtp8/nZvYe9+TipvQ47PWz
tX581JhPtg/p1s7NFrJQY9HOZZ83uTYIMeRZocBDaLhNi74FeYBwtyCWdMvd
MT0h4nKxEl6OdBGqg6cQAysDS/RDNaSsa6Qv8mj51yuyj4h/qHJsSHomLGjl
ZLg+Jkuo7Sk9QoiqBOU1QcB3KstYKTmfJdYRQj+FMDoftcjxdRQrCqo/sSNW
qOA9iJXG8UhYF+4AxQTUO7GXKMc3ZTg14LcBwY/tiEMtXwCiMFfQjWJyRcxo
JYhvR/tUfPyIFUlIAgZcQZ0tf/Nh3jyZxVcdrJCT99w7QLm8xCpIqgz8KrwA
rCFHJgQwSCpAAAEOSAeIO0gu/3VEeq4MvzpSHMRTFDgZVj3lFU4HmqPRej6o
IqLbDE0YRLcgNLTfvECsK/RRFLlRGKZuuGzRw9fs0oa5xOIusG0r+Nu2+rzK
x21zgi2VvN//hiTjvVkowwWNoCOtxj0IJ+iEe4AVhu1dQvb3eywL5uvzaWO1
Fpk0mCqvrjx7DaORhSDA/D51HrLCK+vxzYZ8/SH2gEe886DBf86R4iZIxvOv
sNdR+Pa+1F4/F6HtiN4kNLs7Jx4KmQGxIE9YMOI6IuGpR2AiJ4f9HfX2lxpA
ZEfvzoP7w8yen233BKydBFg739ncSdx9E3m/2FI6StoD+4jwYWMxct/6o6m+
XizShfTSjvdni9Sj3hiut7nNYPGyLuYqTq+XKt9U7HEb3lqa1PezWu6tuq0V
5Fl33uiojaYm1RfuW6aVKhSn9+5ivarvSum36s19L9svNJddc/OQT12UCtuC
jh5o1nYlfXEde6w9b9WYFDO297t8LNdp2YW2Ohr1F06je50Y7srD59Iq1evU
2/vOJm43SqvSdBi/6dJ04+Hc6mny2+Zl4HayrcHNRap/v1y8WWPJLL89ldvz
TMK5KWgX1cR0ke9ab9OXfn3s1JapVmaj3g/xBjy1UBL9a002lgoxZXKPL9N8
ajFM1tJ2d5AodvODZbfs9Du1xbBkPzgxt9xrm06zJ5nb5fV1rEOvcvtv6nCY
zc9jstwvjWJ2W0teP8sDJTV67q1mpUW1uzliH/1Skd9PRZZXZL0FZp58iU70
W52OtKMt8g5V2W9BQDKOXeYCDinIIg19+N8jlrZyKPjJYZOyS0q9d6rFIM8c
7Z3H2w8wdCXFR/75TKc20QqG7SSj/ggtCSxz/rnw1/l/E+0+NyF8DGE28rcl
u3PyF8TbuFojfx4Lvb1HEcMWnR8J+vx1mpq/mPLMOcbWTuhnpGDEI1GEEYfr
Da5EjqkZXPeh1gm//Yv1+F8SpQho6+T3j00k7/6etD7Q38m729GolTUl+2E7
NHc7rd3u9zPt4cbureRtY7OQCrnpaJgoZ7qDp/U8tstj3liz1qk8GM3h5uU6
3exkpqPY/Txu1zpSd7AtL5WKm8kmL946VqfTT1uJtdmzbjLZF7vQHyWz97Ep
lgttW7GHmFpI54r74TZbLGtauqLvJo/brq4ruXWm3xg1y0vtYpDOx3uP17vH
gTq4uXcaLX19rzbqVUx9sMrL+bU8lBLV5+eXfSv/rNeWZttsTG6G06dcfFnK
mdeFglmIb5u7m7oUV63N+n49tZ1MWpvo2grrvkZWJSPl8vp+vtqXsyVVT0+z
KzWnVLONl2o2l7lo18qZ+FJO5gZ525zbOXXX7Netdec58TKaa+kXGKS+73a2
Vn1nll6kciNR7pvpaa+2d53iy31p1kyN+1JQf6vBCIMvmwMIlK8Qj/YE9VGQ
ylfGAa9ivNPzchA0jgGk8rCEj1Q/WXkAeVPZx04Kv9frKo6IpR6SjxeN5XBC
fH7+lAKhEsvE3rpHxxE6aaw52KoX5GXjOrT/D+0ARwMZa4At5ehNB5M+hRTI
uwmsrAN4QIYjBeYBwsBjOMTD4ub9gbiZIbuHu+Av2QS4MfeIBeJ6nUx+BUF+
ZhCEYSPLkQ67SGLGkzKegIhMpDNgOpH/Hbf0vI5KfM9Dl1L8X77G8U2zg1cI
1tkZPzdwF3GYcfRjQg6AuLUCsyARi32TeaOXnp5r3Zum3OisKrPtQ37yUJST
27dm/HlSWm/N4XytFcr1FEjJeLs+q49TlZ7zaCVyWtqsPGdym6fJ807f9WP2
or6S528pLS1XZtNG+7h5k0ieDD+wNX1Wk6LqDWvT92hSL2PnrzdbUt/fbEnd
naZhgGQnLZL3hhl8Oh6YJKm7201L7/al+WaUbmzdB/fBasmZp/R2Ecvc6Ol5
2V7Entup6dqSC41trIXuszmePb6tGrOdPDf2gEPQ36WVwkQb9kvLRm1xkUyY
quyccqFLhSIRsb/E6/cTr7SnAZV/c10ef5VcPYz7CkOJ18lMfp6x5JsTqTJ/
lUP69T7lp724k67DuxyDAHn+BvIs/f3lWfruBxHrQGil726t7bi9yVSS0sJt
5tuLjZl93i9fptejjZNuKNpIbi7TdqVWcUtZLoTyFOOY8rezI36PayMMsQev
CAjzrAsutAmlgsO3FD2cenY2ATh+opjTqROCgPcG/+xhZUl433pQee7l540c
nqT5dw0YfXtE6JsCMwLfBlRwyLL5YgXMci3/+nOf+f7nPvPJ8MuPpuiBcMgQ
i+ZtLL2N9GE9sVATM20qNeXOLjWzV8OhsU0YpXIrUW1lFrZRNNqFewxtrGKJ
yiiWWudKxdmm/6iuUlJsk1mv2uu0VrPST49W/r5T8C0aSL5sdKM9VMzUr360
za0KmZjHshls1lsGfuQKP4KcAuiKSgyPLbSTcSmQMAK0++01/H4IeGo1FQwg
r4Wt16jIaxGF7XcxMkyb++grdyVr2NeCt29SsXuvptEhxSnRqXhN4XBk+KUD
XcF1hrcMjd7wmreAk4kWFNuPcEPXPJs3w/vwodColVq9aKHU6UEbNA+vnaaK
OAFwX+Ri1eH91fN+i50jnZzlEPnAXgOCYAcvwC93EJudw7cLLRa9jicq9ALh
hPuXgwsVOm8BJemttt9fx+ubx04coK4r0McNkVGh8YViARK34WpeaxW6ZWR8
mbbU4/KX7iRsiBMSA3wv2Utw6w42iaoAf3ePne2/Q/rre/JQe3O+jbyrrs96
REoYLLMZuEfZQqcdlqTjkRYfJGxIsYdZ18mj/Om3orRkfA92XTIpv1K+4C2j
FRtbpM1NBNAlDswr++iKP3PlpSpEPi3YvT5sbGt/Ukbzqfn+oP0V6H0buQUE
mLdioSD1MzNpU8tLs1o+v5fu87PZ23y5eHhst4vSQso0O86m0h4WB+32fRHk
cb7efHluG+NdPj957pgvT+mY/NSaTyr9bWUvveRnrUFeajZLy22+VtJWk8pg
N3oaLOWncuylmy+28dJaUsqb2K5ZlLbNXnvXXPTjzX1Lxs965LNF0/usKcW2
hb1U5+NKy3qxWcaC3c9WiWWHxvPzVO7PdKPpPjz3r2vG+EnWOnNlZD/rYxyk
kF1PZvW4lc4r6fJ1cljIPrjzbTN1sYw3M3JJKpXHlf2yrrZ2mXo2tbtZ7c1c
M9PaNavSpgB0wevzWC8v1TZSUZrCPKvdZqlSlJ5m+Y6efFo05GRWG5WGhZVa
eBy7sRe5WyomitIDPtvO5qUpXuSXyPoKeUeCdRUHnZiWlzabwoysazPM59t9
8sbaptrG7zpSu3qdzzc3pWHpcah3Fu0KziQ1fIpvRpX+apjIuU2hvAzGlmIz
qVnqF2r56kS+tuNruUEM9YGmNlLXRTUzvI+1MdFx1Fwo3WUhOSkXHh7y2Z6k
lqTt9bLazadWRNC9xFrPaTv9LNv64zK20Ve7SX5g9lPz/OAlvpsviSY+KUue
WOcjWQxCHz3YtPUIb2Xj2itHCMt7zToE+YMhadC12Owo0D8koKyUE6rR6zIR
tu69qTHxcGLCLCYBeOq2IsCbs7oM2sWI/hZXQ7tFbMlHMHO/YbloL7DsRt5n
y1M6fEwuQiKejP6XE/YWWPNGbzme3PvCQOkX3R+HfQnRezgp986pxoiCrjj/
OhmFBdXFb5RRMEi7940yCjHPPl/J+mkZhWgAy2+UUTAIyIxvklEUlPMbZRQi
0g2+UUbh7mS+XUadCp6HrqdF1+nAZRL49fvHzb3pfdFB3Q6a1YElb2SpcB3r
jqr2fcfJqdlaUnlw0h2316wUnp7165yxftmbVac2yzTHSi4ZT/cyW3Op7Xax
3f+c7efFnDxP1audTbPxMNPV/YYXtz1hx4VPTtq3pGh/UK/1B7UiT5lyXiLq
oSA78Jld17Zev4guv0yzX6bZL9Ps9jBWBEfp7qfJPSEqhC++/XJ5BVM4kFlH
JdYnDNHeKRMu0IHrUBKxGAktBkF7jzdXDFqonvMrOr5g6GEfN6Grjea71RPa
vCiQStKDFqieKSs2M3L5N6wEG38G3WHNsanxXsVC1zwM6BiTQNdj1gWajgMl
LWL1j9emVJ5OWdc6GmTXoafu2DMovRpUDL5cBccQgviy1/XSaw9lmyOgGr+9
0/2et47iT4zNlega/5JxrNrjlQ6dzcbY9CnQ6zGokgLtxfm8vK1g8/nGmP1X
xgsqJaKToP/Wf0GOepwqpfg/W+SPxB3eTiZOBYJMe8a0UdlWLyPxdKS+0kAb
JSLx1G0ixbUR9Ee13CN6iH/xx/UfR4QCpz1Ihs/HjmUc652y4EiA2H/d7Usv
vjTNtlOqWi+xWry2KLy5bct60GtvWv1RMW+K1U6yazaNmJOuI2JPXOlUujHp
Yr0bPubc68azNk+3m+VyOzO2Gm5Cj1n6Itkq+nlnwftldJIcFytuvV6Yfl01
MzIEl4ZsmuAOwe6duB6BLeKkOdyAS6T8KSv0kzT36P3ezMfwNYd4PA5OBDYE
ZIWCEy83m7JLtCEbsxU+ztxmJ7JRIPPb4Q/L4RomobE5rWM0FNWdM3vuxLAG
a/VFh5Jt5RM5bDydL9gCzHEh7QCl+dfH895xPv9JzUl61fMzzmqIYuQtRrTf
vVSMP9/uYlfp/8Cz/D5exnaznJuLqI6R1y59xu1g/zrb/8KA9H5Nky0neAy8
3EoDY9msgg84iYZicHj4dYeimfAh/VyT0+zMdY3wYqZoQ+92aPdOsnTQpwFl
Se0QeEIjmzjZ4cXPCoNIIOLYS4m5YxoAO6TuWe9TL5MEnkK9SSPyNFGGZeb8
ZUftU8eLbd0tvtq5vb72es1eCY9RaX3qmF3+h+rC956fKDYM93ogCpzBOZTQ
YaaCRR3ApQB+D/8autCv1QlcjwXY+m/EZO+Sxu8R64fc+ovHjvPYeE60GmcR
SgbwFDB2w+WiRwv45ly4Fz2HcjJHnVDXDYjOeOr3q0gXDQ/WYdobGt0hb7iv
sTKgm+t34Uwanvo6+effCf9yBX4Oa6Io40IPajHAfUVX9Kiu5vwX+CnLFPJ7
RQNzwd6jtGNOtgxNzfHuCkIIBva8BS5gMB84KXYdT/NkETOMRWWDPo5vWfxA
Nv6JDq1vCx/h6P8sLv4HYbelYW40ZTJDRDiIE8mhjz6efbg1VvoIGPrufCpr
jnLuNcMO9JCHxsQsAYdwXwA37sOHWrR4NZbXhCWiyB9+gOfjRxZRU9zIxJan
tPl1RJmorkksX3qhq6lLlkskG0tBnrODI7OfXkaasr2MFPBFyLhN2VhFupZp
G7tL3glatcmo5DFu8OJPOZurNtYTq8aKXRQTF59YI5jkQ22MwKIxmYiV7zrB
x/0LDLp8VXGnURPmHaXRI0oJFmI6IINwteyouqrJdkSZkhW4PNkoSCGcyCGZ
fCnlm060m/VUUSaQ6nQJUgguv+lJD8EDInmh1M2bEmRfWYQZFAg+wvuJ+iRv
t+bySKFopCirfr89w72QJrI+Vo1L9pemKeTfjzI5o5JhKI6m7C7PPnz4cC/b
WiT/7/+bazp57uPHj/hp1/33/5KBieDIk4XvdWWn2PhdV7YhW78gW/JEdTT1
8qyhynqkqJAx52TErqtYkJJWlokbpWnkjXMV4FIjVcKcsh7Ny0viqZ31dhoh
b1XWL89KkDtcNTUiuC7PJGNiK7vIPRl6t1qSv8kiIvcGUolIm7USaShzg//T
BDeOvLRG9kiNNNSVs5aJd395Vpeh1K56BVw4g/fdE7mhgYZoEqmBF/uULC0T
8wTnMJGhKa8jLdWGt5KHjMijTCZF/mysxuSEPcr2ZKVcnnVMciTByCEbTJZP
hB4821Gc8XxJvm6qRMgrWqQD/7cn4KacPZmLsaqM55HObka0iLMkv4PvI11Z
27NFdseEYpdnBdPeRepEAWmKRZapkjkSksI2VhWDfNUlnLeDKS1lZx/p7pXN
mPxobhNOeVJGI+YFn9UJxwIhh7JD3galef+IFDkqZ1V1YJTj8uUPUA6lYq33
0LmNEI6EaBu64grlRw6MOaIRdQq0iiz7x9lZlLJrFE8cHLKR6nCNJEieMyI1
o5FoPEf+T/77I9K3MIRfk1oSedmMzM+mpwD0tL3yUv3oz7Jf+DP2dAmPLWQp
riyakIlyolbqViD9UVU23htu+G8KqLAp7inhE/5xhxIEVhQlh91fmgDhCbbq
BFLsLE02ZC9DZTPfoYMFBZsoL1xvgu1gHI77ajqE3CH4rkQ5/iqIEUeeKu7u
1I8hoXUTAZ4ihjLRELbBAhMaEWlUxPiUkSbk1DmO6CJ6S/afKtL8/cicsg9N
djEdBFbyoh5h5eT9uqZDnk7EHDlRIhonDBBZATOr341K3UKtdkleSlZGPsE/
owCNCqP6SdsAOsv3KHO4r2PCrsbKovsqFb1d5ZsJYmIKmGo8sXS8A11EeQWz
gCgFHAWG41EWe6UpAhWUKdhTHFWMmGACzYlAZuE+b85XIWblpQkC4pusjaG+
OLAldK67yBx20dRHqsFnR2NShC8nGtxA+VvI6nEVV1Y1hmjBzwAyDB6TYulf
/kvK6jbimLri7wXjW2MMKt47DumTpA6RZRI5F5HsiFrduufeMCn+cE+2Z0Tb
2vKG1ahRrmb8DnP1rjVhOszsC66VeoR4EHiqmA0LtwUawu7AhZhlwg0+TFt1
HBb+ABS+KLWVAjGzT8iWHb4uUDjwjnehwxCCFSN8ws1ocVE+LjWlAowJdXEe
BZO+AKLwY+ecyILYADfblWcBegHPC+U3hocgTKenrzRXBa4EE9TgO+e/NxEc
6shbQy8DRD1CZJBR4VAnl5ChX9BaRiyif4wmsylfbG8twgR4aKdg5VLb6ACu
JkIT+/ncvZ93idSh+Na01AjT6yaK7V1SEnLBZS9EUhV/xfHg7KR8qyycEgB9
lckaxt5XARnhHxNgX7p0vI+dqttDFjtBkPyOfNcFGxVkpCiauS/nTTYW1Etk
gzg6JC/t5geJ2bxR/3OokJDXJrq4WHNJrDHy87dje+uvCxcCnAb01xgSLQag
Ce0VA7nMcYmRF5mtVIB4NILrO7EfAmdycCG+yFhOYAhNRmED17v8vBAbWJyq
RwlIOGerp7U1qBx0iDYdEJ7IQw/Sz2esCCtFFbWZd/4EtxwcV/am0KfsuvIc
j2bQyw+f0iA5ULyJoQWyfSphAszSCkgtRqTsia3y5RQaNDBF0NKy5gorpfM7
wEk6PzyK4fX5FML1HzkS7JCz1gs+wNOhbuaGBzAkFQrOgS71n2Z6+KDU2X+F
T5ybsIxiLOh1CRiHxUNo+paJniIyvn/3wtUW8BWTUcj+Stj+5NQL6pSD5/zF
edkpXMXBTCnkxzh0A0TmBMVIQmAFUyhUm8UXMERAtipsyASY1UW97JwDRb3k
aS4qqJfKBIsnQCiLHvKST/VMUNxNIhq/O0YMkQPYscuIDzKmQvEPApxQwySk
o0OU+nTBH1hNPIaHOZEsAZyj9vMbPwhVhC0JkFjnYcvuXCh/8ZNsuEVCX2oQ
vUKMgYDsYBakoWwChKNQasKKgfTRCdslLrjpFgmPhVg0LOAjIxVrUr3tSAcl
JEUjtohqC4oJZn4KiVQev/v2bliTobYjNuUxjeZ7RkAh6KIET1ebUsGbmmcf
NlF0i5Ykl8X++eIoOORE2qY/b4ZZgFqByL6VQb1V8XfUsvLPjUke06aqpl2F
ORXsrxPaGSGVBaOLltnxlSQPOfTkEfaKtI68XgQKAGXnUDhc1JJg/wr7pci2
totwdhmbgS0j5tjBua8/dEsCjXUeH6bTOVCkmjID+Sj8AGdw4BgdAXOCoAH8
gclzKCZ9mUNkzQhKIIlGJmbCwWABR0zwD/wkHKqAmFHuxT5DCsrbmER4WYrv
0Zg6FZXALjxUQo3KQ2qoRN3wZ5idT2G9BWsKSuuW8Cx+LwxBzBcwHFeG4Hi+
emLFq3BBm+o1JNRekRfEp4sqcoSMwSFvvCodoxz0UooeexxIGySrcMsrDKsr
ECUi8ki5ml1dRl7Pt9GJ9y2FhDqHKPsdfTAKptHru985VW1CuBZ/C3rVkYYK
qsd/H3pr9E23VFjdpV5DdhuRBweHlR8llBIT6g1jZIQmXGAh6cS0XMGT5vP9
pGxmUNAAp4ISBK1eDGPrwkaj/p0cPxI0oVLAnzxi5lBRAxY03FUBY0LcmLWX
IjKRHIuRqiF2NRg/uDqqpplZdOS0soPg+TeEZzCxXeFahpkMuDen9ixYPE+X
AnktdhTa3kR+GzMrEw97t/rQbxThqWa/2/v9QGHJnpAVTzhKctitHgDPwJqI
/aTa/mfeOE0Vss/Eg4zFVijrqckiT2RKJwiy2+QA6wELxXOfavQSRd3zqdNo
pg2hXMOQo+IFmxDOJCNcCvF+ZCgMkdJLabjygM9ntgkBEy9I+rlhw7MrmAZR
HAzvZqtrCXs6jqyTbI3My6Tfil4ZxHMFV+xQlgkmEl6RjAkTK6IlK9h9vlcW
GoR8PtVUmnXst0kKmKCwq17Y7MCYAKjXDXII3m5ivBP7H6ysgN9FX1fiXqYD
Ji85eupWeGZjA0ySPHKwupkV2gsCAA8sOpE8XIDPQPEiSyKby3BfMkMokznN
YGYn9KAH0+F7DUA9ktcq+Gvc5vdX7BMWDDyXTOI0zcIhnJAVAyYB+DyOEE2d
4IbfJJIxPykMnwmNFTDHDjPLDFFsCe6d4yrW4ZIPYDW+bZHySnNFWRA0hBSQ
A+SbI3Yonw+u2p+U5Ft7ntvlz/CKu9401o9XiaZGnD3CzzvG/OxHrkJoRs7B
lceIzmoGET3yr36nFloJ+nmhqTx6FiMfNPQjoVWBTy7KwVOBfDwSFfp1z7S4
E/LExE4FxA4P3guO6SXP6WcrIR6wicFD4UoH04QN4Kirs/8Hgwz1CLRmAwA=

-->
</rfc>