rfc9421.original.xml   rfc9421.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2. 2) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc compact="yes"?> -ietf-httpbis-message-signatures-19" number="9421" submissionType="IETF" categor
<?rfc comments="yes"?> y="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" update
<?rfc inline="yes"?> s="" obsoletes="" xml:lang="en" version="3">
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-message-signatures-19" category="std" consensus="true" tocInclude=
"true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 --> <!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title>HTTP Message Signatures</title> <title>HTTP Message Signatures</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-message-signatur es-19"/> <seriesInfo name="RFC" value="9421"/>
<author initials="A." surname="Backman" fullname="Annabelle Backman" role="e ditor"> <author initials="A." surname="Backman" fullname="Annabelle Backman" role="e ditor">
<organization>Amazon</organization> <organization>Amazon</organization>
<address> <address>
<postal> <postal>
<street>P.O. Box 81226</street> <street>P.O. Box 81226</street>
<city>Seattle</city> <city>Seattle</city>
<region>WA</region> <region>WA</region>
<code>98108-1226</code> <code>98108-1226</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
skipping to change at line 53 skipping to change at line 52
<organization>Digital Bazaar</organization> <organization>Digital Bazaar</organization>
<address> <address>
<postal> <postal>
<street>203 Roanoke Street W.</street> <street>203 Roanoke Street W.</street>
<city>Blacksburg</city> <city>Blacksburg</city>
<region>VA</region> <region>VA</region>
<code>24060</code> <code>24060</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>msporny@digitalbazaar.com</email> <email>msporny@digitalbazaar.com</email>
<uri>https://manu.sporny.org/</uri>
</address> </address>
</author> </author>
<date year="2023" month="July" day="27"/>
<area>Applications and Real-Time</area> <date year="2024" month="February"/>
<workgroup>HTTP</workgroup> <area>art</area>
<workgroup>httpbis</workgroup>
<keyword>PKI</keyword> <keyword>PKI</keyword>
<abstract> <abstract>
<?line 129?>
<t>This document describes a mechanism for creating, encoding, and verifying dig ital signatures or message authentication codes over components of an HTTP messa ge. This mechanism supports use cases where the full HTTP message may not be kno wn to the signer, and where the message may be transformed (e.g., by intermediar ies) before reaching the verifier. <t>This document describes a mechanism for creating, encoding, and verifying dig ital signatures or message authentication codes over components of an HTTP messa ge. This mechanism supports use cases where the full HTTP message may not be kno wn to the signer and where the message may be transformed (e.g., by intermediari es) 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> 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> </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.or
g"/>),
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.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/signature
s"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 134?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>Message integrity and authenticity are security properties that are cri tical to the secure operation of many HTTP applications. <t>Message integrity and authenticity are security properties that are cri tical to the secure operation of many HTTP applications.
Application developers typically rely on the transport layer to provide these pr operties, by operating their application over <xref target="TLS"/>. However, TLS only guarantees these properties over a single TLS connection, and the path bet ween client and application may be composed of multiple independent TLS connecti ons (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 canno t guarantee end-to-end message integrity or authenticity between the client and application. Additionally, some operating environments present obstacles that ma ke it impractical to use TLS (such as presentation of client certificates from a browser), or to use features necessary to provide message authenticity. Further more, some applications require the binding of a higher-level application-specif ic key to the HTTP message, separate from any TLS certificates in use. Consequen tly, while TLS can meet message integrity and authenticity needs for many HTTP-b ased applications, it is not a universal solution.</t> Application developers typically rely on the transport layer to provide these pr operties, by operating their application over TLS <xref target="RFC8446"/>. Howe ver, 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-terminat ing gateway or if the client is behind a TLS Inspection appliance). In such case s, TLS cannot guarantee end-to-end message integrity or authenticity between the client and application. Additionally, some operating environments present obsta cles that make it impractical to use TLS (such as the presentation of client cer tificates from a browser) or to use features necessary to provide message authen ticity. Furthermore, some applications require the binding of a higher-level app lication-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 h ide portions of the message from the application at the time of signing or verif ication. These applications need a means to protect the parts of the message tha t are most relevant to the application without having to violate layering and ab straction.</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 h ide portions of the message from the application at the time of signing or verif ication. These applications need a means to protect the parts of the message tha t are most relevant to the application without having to violate layering and ab straction.</t>
<t>Finally, object-based signature mechanisms such as <xref target="JWS"/> <t>Finally, object-based signature mechanisms such as JSON Web Signature <
require the intact conveyance of the exact information that was signed. When ap xref target="RFC7515"/> require the intact conveyance of the exact information t
plying such technologies to an HTTP message, elements of the HTTP message need t hat was signed. When applying such technologies to an HTTP message, elements of
o be duplicated in the object payload either directly or through inclusion of a the HTTP message need to be duplicated in the object payload either directly or
hash. This practice introduces complexity since the repeated information needs t through the inclusion of a hash. This practice introduces complexity, since the
o be carefully checked for consistency when the signature is verified.</t> repeated information needs to be carefully checked for consistency when the sign
<t>This document defines a mechanism for providing end-to-end integrity an ature is verified.</t>
d authenticity for components of an HTTP message by use of a detached signature <t>This document defines a mechanism for providing end-to-end integrity an
on HTTP messages. The mechanism allows applications to create digital signatures d authenticity for components of an HTTP message by using a detached signature o
or message authentication codes (MACs) over only the components of the message n HTTP messages. The mechanism allows applications to create digital signatures
that are meaningful and appropriate for the application. Strict canonicalization or message authentication codes (MACs) over only the components of the message t
rules ensure that the verifier can verify the signature even if the message has hat are meaningful and appropriate for the application. Strict canonicalization
been transformed in many of the ways permitted by HTTP.</t> 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 part s:</t> <t>The signing mechanism described in this document consists of three part s:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A common nomenclature and canonicalization rule set for the differen <li>A common nomenclature and canonicalization rule set for the differen
t protocol elements and other components of HTTP messages, used to create the si t protocol elements and other components of HTTP messages, used to create the si
gnature base. (<xref target="covered-components"/>)</li> gnature base (<xref target="covered-components"/>).</li>
<li>Algorithms for generating and verifying signatures over HTTP message <li>Algorithms for generating and verifying signatures over HTTP message
components using this signature base through application of cryptographic primi components using this signature base through the application of cryptographic p
tives. (<xref target="message-signatures"/>)</li> rimitives (<xref target="message-signatures"/>).</li>
<li>A mechanism for attaching a signature and related metadata to an HTT <li>A mechanism for attaching a signature and related metadata to an HTT
P message, and for parsing attached signatures and metadata from HTTP messages. P message and for parsing attached signatures and metadata from HTTP messages. T
To facilitate this, this document defines the "Signature-Input" and "Signature" o facilitate this, this document defines the "Signature-Input" and "Signature" f
fields. (<xref target="attach-signature"/>)</li> ields (<xref target="attach-signature"/>).</li>
</ul> </ul>
<t>This document also provides a mechanism for negotiation the use of sign <t>This document also provides a mechanism for negotiating the use of sign
atures in one or more subsequent messages via the "Accept-Signature" field (<xre atures in one or more subsequent messages via the "Accept-Signature" field (<xre
f target="request-signature"/>). This optional negotiation mechanism can be used f target="request-signature"/>). This optional negotiation mechanism can be used
along with opportunistic or application-driven message signatures by either par along with opportunistic or application-driven message signatures by either par
ty.</t> ty.</t>
<t>The mechanisms defined in this document are important tools that can be <t>The mechanisms defined in this document are important tools that can be
used to an overall security mechanism for an application. This toolkit provides used to build an overall security mechanism for an application. This toolkit pr
some powerful capabilities, but does not sufficient in creating an overall secu ovides some powerful capabilities but is not sufficient in creating an overall s
rity story. In particular, the requirements in <xref target="application"/> and ecurity story. In particular, the requirements listed in <xref target="applicati
the security considerations in <xref target="security"/> are of high importance on"/> and the security considerations discussed in <xref target="security"/> are
to all implementors of this specification. For example, this specification does of high importance to all implementors of this specification. For example, this
not define a means to directly cover HTTP message content (defined in <xref sect specification does not define a means to directly cover HTTP message content (d
ion="6.4" sectionFormat="of" target="HTTP"/>), but relies on the <xref target="D efined in <xref section="6.4" sectionFormat="of" target="RFC9110"/>); rather, it
IGEST"/> specification to provide a hash of the message content, as discussed in relies on the Digest specification <xref target="RFC9530"/> to provide a hash o
<xref target="security-message-content"/>.</t> f the message content, as discussed in <xref target="security-message-content"/>
.</t>
<section anchor="definitions"> <section anchor="definitions">
<name>Conventions and Terminology</name> <name>Conventions and Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<?line -18?>
<t>The terms "HTTP message", "HTTP request", "HTTP response", <t>The terms "HTTP message", "HTTP request", "HTTP response",
"target URI", "gateway", "header field", "intermediary", "request target", "target URI", "gateway", "header field", "intermediary", "request target",
"trailer field", "sender", "method", and "recipient" are used as defined in <xre f target="HTTP"/>.</t> "trailer field", "sender", "method", and "recipient" are used as defined in <xre f 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 key ed MACs (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or keyed MAC over a given signatur e base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.</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 key ed MACs (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or keyed MAC over a given signatur e 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" s ectionFormat="of" target="STRUCTURED-FIELDS"/> <t>This document uses the following terminology from <xref section="3" s ectionFormat="of" target="RFC8941"/>
to specify data types: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, and Boolean.</t> to specify data types: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, and Boolean.</t>
<t>This document defines several string constructions using <xref target ="ABNF"/> and uses the following ABNF rules: <tt>VCHAR</tt>, <tt>SP</tt>, <tt>DQ UOTE</tt>, <tt>LF</tt>. This document uses the following ABNF rules from <xref t arget="STRUCTURED-FIELDS"/>: <tt>sf-string</tt>, <tt>inner-list</tt>, <tt>parame ters</tt>. This document uses the following ABNF rules from <xref target="HTTP"/ > and <xref target="HTTP1"/>: <tt>field-content</tt>, <tt>obs-fold</tt>, <tt>obs -text</tt>.</t> <t>This document defines several string constructions using ABNF <xref t arget="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="RFC8941"/>: <tt>sf-string</tt>, <tt>inner-list</tt>, and <tt> parameters</tt>. This document uses the following ABNF rules from <xref target=" RFC9110"/> and <xref target="RFC9112"/>: <tt>field-content</tt>, <tt>obs-fold</t t>, and <tt>obs-text</tt>.</t>
<t>In addition to those listed above, this document uses the following t erms:</t> <t>In addition to those listed above, this document uses the following t erms:</t>
<dl newline="true"> <dl newline="true">
<dt>HTTP Message Signature:</dt> <dt>HTTP Message Signature:</dt>
<dd> <dd>
<t>A digital signature or keyed MAC that covers one or more portions of an HTTP message. Note that a given HTTP Message can contain multiple HTTP Me ssage Signatures.</t> <t>A digital signature or keyed MAC that covers one or more portions of an HTTP message. Note that a given HTTP message can contain multiple HTTP me ssage signatures.</t>
</dd> </dd>
<dt>Signer:</dt> <dt>Signer:</dt>
<dd> <dd>
<t>The entity that is generating or has generated an HTTP Message Si gnature. Note that multiple entities can act as signers and apply separate HTTP Message Signatures to a given HTTP Message.</t> <t>The entity that is generating or has generated an HTTP message si gnature. Note that multiple entities can act as signers and apply separate HTTP message signatures to a given HTTP message.</t>
</dd> </dd>
<dt>Verifier:</dt> <dt>Verifier:</dt>
<dd> <dd>
<t>An entity that is verifying or has verified an HTTP Message Signa ture against an HTTP Message. Note that an HTTP Message Signature may be verifie d multiple times, potentially by different entities.</t> <t>An entity that is verifying or has verified an HTTP message signa ture against an HTTP message. Note that an HTTP message signature may be verifie d multiple times, potentially by different entities.</t>
</dd> </dd>
<dt>HTTP Message Component:</dt> <dt>HTTP Message Component:</dt>
<dd> <dd>
<t>A portion of an HTTP message that is capable of being covered by an HTTP Message Signature.</t> <t>A portion of an HTTP message that is capable of being covered by an HTTP message signature.</t>
</dd> </dd>
<dt>Derived Component:</dt> <dt>Derived Component:</dt>
<dd> <dd>
<t>An HTTP Message Component derived from the HTTP message through t he use of a specified algorithm or process. See <xref target="derived-components "/>.</t> <t>An HTTP message component derived from the HTTP message through t he use of a specified algorithm or process. See <xref target="derived-components "/>.</t>
</dd> </dd>
<dt>HTTP Message Component Name:</dt> <dt>HTTP Message Component Name:</dt>
<dd> <dd>
<t>A string that identifies an HTTP Message Component's source, such as a field name or derived component name.</t> <t>A String that identifies an HTTP message component's source, such as a field name or derived component name.</t>
</dd> </dd>
<dt>HTTP Message Component Identifier:</dt> <dt>HTTP Message Component Identifier:</dt>
<dd> <dd>
<t>The combination of an HTTP Message Component Name and any paramet ers that uniquely identifies a specific HTTP Message Component in respect to a p articular HTTP Message Signature and the HTTP Message it applies to.</t> <t>The combination of an HTTP message component name and any paramet ers. This combination uniquely identifies a specific HTTP message component with respect to a particular HTTP message signature and the HTTP message it applies to.</t>
</dd> </dd>
<dt>HTTP Message Component Value:</dt> <dt>HTTP Message Component Value:</dt>
<dd> <dd>
<t>The value associated with a given component identifier within the context of a particular HTTP Message. Component values are derived from the HTT P Message and are usually subject to a canonicalization process.</t> <t>The value associated with a given component identifier within the context of a particular HTTP message. Component values are derived from the HTT P message and are usually subject to a canonicalization process.</t>
</dd> </dd>
<dt>Covered Components:</dt> <dt>Covered Components:</dt>
<dd> <dd>
<t>An ordered set of HTTP message component identifiers for fields ( <xref target="http-fields"/>) and derived components (<xref target="derived-comp onents"/>) 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 facil itate reconstruction of the signature base.</t> <t>An ordered set of HTTP message component identifiers for fields ( <xref target="http-fields"/>) and derived components (<xref target="derived-comp onents"/>) 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 facil itate reconstruction of the signature base.</t>
</dd> </dd>
<dt>Signature Base:</dt> <dt>Signature Base:</dt>
<dd> <dd>
<t>The sequence of bytes generated by the signer and verifier using the covered components set and the HTTP Message. The signature base is processed by the cryptographic algorithm to produce or verify the HTTP Message Signature. </t> <t>The sequence of bytes generated by the signer and verifier using the covered components set and the HTTP message. The signature base is processed by the cryptographic algorithm to produce or verify the HTTP message signature. </t>
</dd> </dd>
<dt>HTTP Message Signature Algorithm:</dt> <dt>HTTP Message Signature Algorithm:</dt>
<dd> <dd>
<t>A cryptographic algorithm that describes the signing and verifica tion 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> <t>A cryptographic algorithm that describes the signing and verifica tion 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> </dd>
<dt>Key Material:</dt> <dt>Key Material:</dt>
<dd> <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 s igner to indicate to the verifier which key was used.</t> <t>The key material required to create or verify the signature. The key material is often identified with an explicit key identifier, allowing the s igner to indicate to the verifier which key was used.</t>
</dd> </dd>
<dt>Creation Time:</dt> <dt>Creation Time:</dt>
<dd> <dd>
<t>A timestamp representing the point in time that the signature was generated, as asserted by the signer.</t> <t>A timestamp representing the point in time that the signature was generated, as asserted by the signer.</t>
</dd> </dd>
<dt>Expiration Time:</dt> <dt>Expiration Time:</dt>
<dd> <dd>
<t>A timestamp representing the point in time after which the signat ure should no longer be accepted by the verifier, as asserted by the signer.</t> <t>A timestamp representing the point in time after which the signat ure should no longer be accepted by the verifier, as asserted by the signer.</t>
</dd> </dd>
<dt>Target Message:</dt> <dt>Target Message:</dt>
<dd> <dd>
<t>The HTTP message to which an HTTP Message Signature is applied.</ t> <t>The HTTP message to which an HTTP message signature is applied.</ t>
</dd> </dd>
<dt>Signature Context:</dt> <dt>Signature Context:</dt>
<dd> <dd>
<t>The data source from which the HTTP Message Component Values are drawn. The context includes the target message and any additional information th e signer or verifier might have, such as the full target URI of a request or the related request message for a response.</t> <t>The data source from which the HTTP message component values are drawn. The context includes the target message and any additional information th e signer or verifier might have, such as the full target URI of a request or the related request message for a response.</t>
</dd> </dd>
</dl> </dl>
<t>The term "Unix timestamp" refers to what Section 4.16 of <xref target <t>The term "UNIX timestamp" refers to what Section 4.16 of <xref target
="POSIX"/> calls "Seconds Since the Epoch".</t> ="POSIX"/> calls "seconds since the Epoch".</t>
<t>This document contains non-normative examples of partial and complete <t>This document contains non-normative examples of partial and complete
HTTP messages. Some examples use a single trailing backslash <tt>\</tt> to indi HTTP messages. Some examples use a single trailing backslash (<tt>\</tt>) to in
cate line wrapping for long values, as per <xref target="RFC8792"/>. The <tt>\</ dicate 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> </tt> character and leading spaces on wrapped lines are not part of the value.</
t>
</section> </section>
<section anchor="requirements"> <section anchor="requirements">
<name>Requirements</name> <name>Requirements</name>
<t>HTTP permits and sometimes requires intermediaries to transform messa <t>HTTP permits, and sometimes requires, intermediaries to transform mes
ges in a variety of ways. This can result in a recipient receiving a message tha sages in a variety of ways. This can result in a recipient receiving a message t
t is not bitwise-equivalent to the message that was originally sent. In such a c hat is not bitwise-equivalent to the message that was originally sent. In such a
ase, the recipient will be unable to verify integrity protections over the raw b case, the recipient will be unable to verify integrity protections over the raw
ytes of the sender's HTTP message, as verifying digital signatures or MACs requi bytes of the sender's HTTP message, as verifying digital signatures or MACs req
res both signer and verifier to have the exact same signature base. Since the ex uires both signer and verifier to have the exact same signature base. Since the
act raw bytes of the message cannot be relied upon as a reliable source for a si exact raw bytes of the message cannot be relied upon as a reliable source for a
gnature base, the signer and verifier have to independently create the signature signature base, the signer and verifier have to independently create the signatu
base from their respective versions of the message, via a mechanism that is res re base from their respective versions of the message, via a mechanism that is r
ilient to safe changes that do not alter the meaning of the message.</t> esilient 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 c <t>For a variety of reasons, it is impractical to strictly define what c
onstitutes a safe change versus an unsafe one. Applications use HTTP in a wide v onstitutes a safe change versus an unsafe one. Applications use HTTP in a wide v
ariety of ways and may disagree on whether a particular piece of information in ariety 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) a message (e.g., the message content, the method, or a particular header field)
is relevant. Thus, a general purpose solution needs to provide signers with some is relevant. Thus, a general-purpose solution needs to provide signers with some
degree of control over which message components are signed.</t> degree of control over which message components are signed.</t>
<t>HTTP applications may be running in environments that do not provide <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 JavaSc complete access to or control over HTTP messages (such as a web browser's JavaSc
ript environment), or may be using libraries that abstract away the details of t ript environment) or may be using libraries that abstract away the details of th
he protocol (such as <eref target="https://openjdk.java.net/groups/net/httpclien e protocol (such as <eref target="https://openjdk.java.net/groups/net/httpclient
t/intro.html">the Java HTTPClient library</eref>). These applications need to be /intro.html">the Java HTTP Client (HttpClient) library</eref>). These applicatio
able to generate and verify signatures despite incomplete knowledge of the HTTP ns need to be able to generate and verify signatures despite incomplete knowledg
message.</t> e of the HTTP message.</t>
</section> </section>
<section anchor="transforms"> <section anchor="transforms">
<name>HTTP Message Transformations</name> <name>HTTP Message Transformations</name>
<t>As mentioned earlier, HTTP explicitly permits and in some cases requi res implementations to transform messages in a variety of ways. Implementations are required to tolerate many of these transformations. What follows is a non-no rmative and non-exhaustive list of transformations that could occur under HTTP, provided as context:</t> <t>As mentioned earlier, HTTP explicitly permits, and in some cases requ ires, implementations to transform messages in a variety of ways. Implementation s 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"> <ul spacing="normal">
<li>Re-ordering of fields with different field names (<xref section="5 <li>Reordering of fields with different field names (<xref section="5.
.3" sectionFormat="of" target="HTTP"/>).</li> 3" sectionFormat="of" target="RFC9110"/>).</li>
<li>Combination of fields with the same field name (<xref section="5.2 <li>Combination of fields with the same field name (<xref section="5.2
" sectionFormat="of" target="HTTP"/>).</li> " sectionFormat="of" target="RFC9110"/>).</li>
<li>Removal of fields listed in the Connection header field (<xref sec <li>Removal of fields listed in the Connection header field (<xref sec
tion="7.6.1" sectionFormat="of" target="HTTP"/>).</li> tion="7.6.1" sectionFormat="of" target="RFC9110"/>).</li>
<li>Addition of fields that indicate control options (<xref section="7 <li>Addition of fields that indicate control options (<xref section="7
.6.1" sectionFormat="of" target="HTTP"/>).</li> .6.1" sectionFormat="of" target="RFC9110"/>).</li>
<li>Addition or removal of a transfer coding (<xref section="7.7" sect <li>Addition or removal of a transfer coding (<xref section="7.7" sect
ionFormat="of" target="HTTP"/>).</li> ionFormat="of" target="RFC9110"/>).</li>
<li>Addition of fields such as <tt>Via</tt> (<xref section="7.6.3" sec <li>Addition of fields such as Via (<xref section="7.6.3" sectionForma
tionFormat="of" target="HTTP"/>) and <tt>Forwarded</tt> (<xref section="4" secti t="of" target="RFC9110"/>) and Forwarded (<xref section="4" sectionFormat="of" t
onFormat="of" target="RFC7239"/>).</li> arget="RFC7239"/>).</li>
<li>Conversion between different versions of the HTTP protocol (e.g., <li>Conversion between different versions of HTTP (e.g., HTTP/1.x to H
HTTP/1.x to HTTP/2, or vice-versa).</li> TTP/2, or vice versa).</li>
<li>Changes in casing (e.g., "Origin" to "origin") of any case-insensi <li>Changes in case (e.g., "Origin" to "origin") of any case-insensiti
tive components such as field names, request URI scheme, or host.</li> ve components such as field names, request URI scheme, or host.</li>
<li>Changes to the request target and authority that when applied toge <li>Changes to the request target and authority that, when applied tog
ther do not ether, do not
result in a change to the message's target URI, as defined in <xref section="7 result in a change to the message's target URI, as defined in <xref section="7
.1" sectionFormat="of" target="HTTP"/>.</li> .1" sectionFormat="of" target="RFC9110"/>.</li>
</ul> </ul>
<t>Additionally, there are some transformations that are either deprecat <t>Additionally, there are some transformations that are either deprecat
ed or otherwise not allowed, but still could occur in the wild. These transforma ed or otherwise not allowed but that could still occur in the wild. These transf
tions can still be handled without breaking the signature, and include things su ormations can still be handled without breaking the signature; they include
ch as:</t> such actions as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Use, addition, or removal of leading or trailing whitespace in a f ield value.</li> <li>Use, addition, or removal of leading or trailing whitespace in a f ield value.</li>
<li>Use, addition, or removal of <tt>obs-fold</tt> in field values (<x ref section="5.2" sectionFormat="of" target="HTTP1"/>).</li> <li>Use, addition, or removal of <tt>obs-fold</tt> in field values (<x ref section="5.2" sectionFormat="of" target="RFC9112"/>).</li>
</ul> </ul>
<t>We can identify these types of transformations as ones that should no t prevent signature verification, even when performed on message components cove red by the signature. Additionally, all changes to components not covered by the signature should not prevent signature verification.</t> <t>We can identify these types of transformations as transformations tha t should not prevent signature verification, even when performed on message comp onents covered by the signature. Additionally, all changes to components not cov ered 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>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 the field v alues of a covered component or changing the value of a derived component, can c ause a signature to no longer validate against a target message. Applications of this specification need to take care to ensure that the transformations expecte d by the application are adequately handled by the choice of covered components. </t> <t>Other transformations, such as parsing and reserializing the field va lues of a covered component or changing the value of a derived component, can ca use 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>
<section anchor="application"> <section anchor="application">
<name>Application of HTTP Message Signatures</name> <name>Application of HTTP Message Signatures</name>
<t>HTTP Message Signatures are designed to be a general-purpose tool app licable in a wide variety of circumstances and applications. In order to properl y and safely apply HTTP Message Signatures, an application or profile of this sp ecification <bcp14>MUST</bcp14> specify at least all of the following items:</t> <t>HTTP message signatures are designed to be a general-purpose tool app licable in a wide variety of circumstances and applications. In order to properl y and safely apply HTTP message signatures, an application or profile of this sp ecification <bcp14>MUST</bcp14> specify, at a minimum, all of the following item s:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The set of <xref target="covered-components">component identifiers <li>The set of <xref target="covered-components">component identifiers
</xref> and <xref target="signature-params">signature parameters</xref> that are </xref> and <xref target="signature-params">signature parameters</xref> that are
expected and required to be included in the covered components list. For exampl expected and required to be included in the covered components list. For exampl
e, an authorization protocol could mandate that the Authorization field be cover e, an authorization protocol could mandate that the Authorization field be cover
ed to protect the authorization credentials and mandate the signature parameters ed to protect the authorization credentials and mandate that the signature param
contain a <tt>created</tt> parameter, while an API expecting semantically relev eters contain a <tt>created</tt> parameter (<xref target="signature-params"/>),
ant HTTP message content could require the Content-Digest field defined in <xref while an API expecting semantically relevant HTTP message content could require
target="DIGEST"/> to be present and covered as well as mandate a value for <tt> the Content-Digest field defined in <xref target="RFC9530"/> to be present and c
tag</tt> that is specific to the API being protected.</li> overed as well as mandate a value for the <tt>tag</tt> parameter (<xref target="
<li>The expected structured field types (<xref target="STRUCTURED-FIEL signature-params"/>) that is specific to the API being protected.</li>
DS"/>) of any required or expected covered component fields or parameters.</li> <li>The expected Structured Field types <xref target="RFC8941"/> of an
<li>A means of retrieving the key material used to verify the signatur y required or expected covered component fields or parameters.</li>
e. An application will usually use the <tt>keyid</tt> parameter of the signature <li>A means of retrieving the key material used to verify the signatur
parameters (<xref target="signature-params"/>) and define rules for resolving a e. An application will usually use the <tt>keyid</tt> parameter of the signature
key from there, though the appropriate key could be known from other means such parameters (<xref target="signature-params"/>) and define rules for resolving a
as pre-registration of a signer's key.</li> key from there, though the appropriate key could be known from other means such
as preregistration of a signer's key.</li>
<li>The set of allowable signature algorithms to be used by signers an d accepted by verifiers.</li> <li>The set of allowable signature algorithms to be used by signers an d 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. F or example, the process could use the <tt>alg</tt> parameter of the signature pa rameters (<xref target="signature-params"/>) to state the algorithm explicitly, derive the algorithm from the key material, or use some pre-configured algorithm agreed upon by the signer and verifier.</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. F or example, the process could use the <tt>alg</tt> parameter of the signature pa rameters (<xref target="signature-params"/>) to state the algorithm explicitly, derive the algorithm from the key material, or use some preconfigured algorithm agreed upon by the signer and verifier.</li>
<li>A means of determining that a given key and algorithm used for a s ignature are appropriate for the context of the message. For example, a server e xpecting only ECDSA signatures should know to reject any RSA signatures, or a se rver expecting asymmetric cryptography should know to reject any symmetric crypt ography.</li> <li>A means of determining that a given key and algorithm used for a s ignature are appropriate for the context of the message. For example, a server e xpecting only ECDSA signatures should know to reject any RSA signatures, or a se rver expecting asymmetric cryptography should know to reject any symmetric crypt ography.</li>
<li>A means of determining the context for derivation of message compo <li>A means of determining the context for derivation of message compo
nents from an HTTP message and its application context. While this is normally t nents from an HTTP message and its application context. While this is normally t
he target HTTP message itself, the context could include additional information he target HTTP message itself, the context could include additional information
known to the application through configuration, such as an external host name.</ known to the application through configuration, such as an external hostname.</l
li> i>
<li>If binding between a request and response is needed using the mech <li>If binding between a request and response is needed using the mech
anism in <xref target="content-request-response"/>, all elements of the request anism provided in <xref target="content-request-response"/>, all elements of the
and response message that would be required to provide properties of such a bind request message and the response message that would be required to provide prop
ing.</li> erties of such a binding.</li>
<li>The error messages and codes that are returned from the verifier t <li>The error messages and codes that are returned from the verifier t
o the signer when the signature is invalid, the key material is inappropriate, t o the signer when the signature is invalid, the key material is inappropriate, t
he validity time window is out of specification, a component value cannot be cal he validity time window is out of specification, a component value cannot be cal
culated, or any other errors in the signature verification process. For example, culated, or any other errors occur during the signature verification process. Fo
if a signature is being used as an authentication mechanism, an HTTP status cod r example, if a signature is being used as an authentication mechanism, an HTTP
e of 401 Unauthorized or 403 Forbidden could be appropriate. If the response is status code of 401 (Unauthorized) or 403 (Forbidden) could be appropriate. If th
from an HTTP API, a response with an HTTP status code of 400 Bad Request could i e response is from an HTTP API, a response with an HTTP status code such as 400
nclude details as described in <xref target="RFC7807"/>, such as an indicator th (Bad Request) could include more details <xref target="RFC7807"/> <xref target="
at the wrong key material was used.</li> RFC9457"/>, such as an indicator that the wrong key material was used.</li>
</ul> </ul>
<t>When choosing these parameters, an application of HTTP message signat <t>When choosing these parameters, an application of HTTP message signat
ures has to ensure that the verifier will have access to all required informatio ures has to ensure that the verifier will have access to all required informatio
n needed to re-create the signature base. For example, a server behind a reverse n needed to 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 co proxy would need to know the original request URI to make use of the derived com
mponent <tt>@target-uri</tt>, even though the apparent target URI would be chang ponent <tt>@target-uri</tt>, even though the apparent target URI would be change
ed by the reverse proxy (see also <xref target="security-message-component-conte d by the reverse proxy (see also <xref target="security-message-component-contex
xt"/>). Additionally, an application using signatures in responses would need to t"/>). Additionally, an application using signatures in responses would need to
ensure that clients receiving signed responses have access to all the signed po ensure that clients receiving signed responses have access to all the signed por
rtions of the message, including any portions of the request that were signed by tions of the message, including any portions of the request that were signed by
the server using the related-response parameter.</t> the server using the <tt>req</tt> ("request-response") parameter (<xref target="
<t>The details of this kind of profiling are the purview of the applicat content-request-response"/>).</t>
ion and outside the scope of this specification, however some additional conside <t>Details regarding this kind of profiling are within the purview of th
rations are discussed in <xref target="security"/>. In particular, when choosing e application and outside the scope of this specification; however, some additio
the required set of component identifiers, care has to be taken to make sure th nal considerations are discussed in <xref target="security"/>. In particular, wh
at the coverage is sufficient for the application, as discussed in <xref target= en choosing the required set of component identifiers, care has to be taken to m
"security-coverage"/> and <xref target="security-message-content"/>. This speci ake sure that the coverage is sufficient for the application, as discussed in
fication defines only part of a full security system for an application. When bu Sections&nbsp;<xref target="security-coverage" format="counter"/> and <xref tar
ilding a complete security system based on this tool, it is important to perform get="security-message-content" format="counter"/>. This specification defines on
a security analysis of the entire system of which HTTP Message Signatures is a ly part of a full security system for an application. When building a complete s
part. Historical systems, such as <xref target="AWS-SIGv4"/>, can provide inspir ecurity system based on this tool, it is important to perform a security analysi
ation and examples of how to apply similar mechanisms to an application, though s of the entire system, of which HTTP message signatures is a part. Historical s
review of such historical systems does not negate the need for a security analys ystems, such as AWS Signature Version 4 <xref target="AWS-SIGv4"/>, can provide
is of an application of HTTP Message Signatures.</t> inspiration and examples of how to apply similar mechanisms to an application, t
hough review of such historical systems does not negate the need for a security
analysis of an application of HTTP message signatures.</t>
</section> </section>
</section> </section>
<section anchor="covered-components"> <section anchor="covered-components">
<name>HTTP Message Components</name> <name>HTTP Message Components</name>
<t>In order to allow signers and verifiers to establish which components a <t>In order to allow signers and verifiers to establish which components a
re covered by a signature, this document defines component identifiers for compo re covered by a signature, this document defines component identifiers for compo
nents covered by an HTTP Message Signature, a set of rules for deriving and cano nents covered by an HTTP message signature, a set of rules for deriving and cano
nicalizing the values associated with these component identifiers from the HTTP nicalizing the values associated with these component identifiers from the HTTP
Message, and the means for combining these canonicalized values into a signature message, and the means for combining these canonicalized values into a signature
base.</t> base.</t>
<t>The signature context for deriving these values <bcp14>MUST</bcp14> be <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 <bcp1 accessible to both the signer and the verifier of the message. The context <bcp1
4>MUST</bcp14> be the same across all components in a given signature. For examp 4>MUST</bcp14> be the same across all components in a given signature. For examp
le, it would be an error to use the raw query string for the <tt>@query</tt> der le, it would be an error to use the raw query string for the <tt>@query</tt> der
ived component but combined query and form parameters for the <tt>@query-param</ ived component but combined query and form parameters for the <tt>@query-param</
tt> derived component. For more considerations of the message component context, tt> derived component. For more considerations regarding the message component c
see <xref target="security-message-component-context"/>.</t> ontext, see <xref target="security-message-component-context"/>.</t>
<t>A component identifier is composed of a component name and any paramete
rs associated with that name. Each component name is either an HTTP field name ( <t>A component identifier is composed of a component name and any paramete
<xref target="http-fields"/>) or a registered derived component name (<xref targ rs associated with that name. Each component name is either an HTTP field name (
et="derived-components"/>). The possible parameters for a component identifier a <xref target="http-fields"/>) or a registered derived component name (<xref targ
re dependent on the component identifier, and the HTTP Signature Component Param et="derived-components"/>). The possible parameters for a component identifier a
eters registry cataloging all possible parameters is defined in <xref target="co re dependent on the component identifier. The "HTTP Signature Component Paramete
mponent-param-registry"/>.</t> rs" registry, which catalogs all possible parameters, is defined in <xref target
<t>Within a single list of covered components, each component identifier < ="component-param-registry"/>.</t>
bcp14>MUST</bcp14> occur only once. One component identifier is distinct from an <t>Within a single list of covered components, each component identifier <
other if the component name differs, or if any of the parameters differ for the bcp14>MUST</bcp14> occur only once. One component identifier is distinct from an
same component name. Multiple component identifiers having the same component na other if the component name differs or if any of the parameters differ for the s
me <bcp14>MAY</bcp14> be included if they have parameters that make them distinc ame component name. Multiple component identifiers having the same component nam
t, such as <tt>"foo";bar</tt> and <tt>"foo";baz</tt>. The order of parameters <b e <bcp14>MAY</bcp14> be included if they have parameters that make them distinct
cp14>MUST</bcp14> be preserved when processing a component identifier (such as w , such as <tt>"foo";bar</tt> and <tt>"foo";baz</tt>. The order of parameters <bc
hen parsing during verification), but the order of parameters is not significant p14>MUST</bcp14> be preserved when processing a component identifier (such as wh
when comparing two component identifiers for equality checks. That is to say, < en parsing during verification), but the order of parameters is not significant
tt>"foo";bar;baz</tt> cannot be in the same message as <tt>"foo";baz;bar</tt>, s when comparing two component identifiers for equality checks. That is to say, <t
ince these two component identifiers are equivalent, but a system processing one t>"foo";bar;baz</tt> cannot be in the same message as <tt>"foo";baz;bar</tt>, si
form is not allowed to transform it into the other form.</t> nce 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 b y the identifier itself. Component values <bcp14>MUST NOT</bcp14> contain newlin e (<tt>\n</tt>) characters. Some HTTP message components can undergo transformat ions that change the bitwise value without altering the meaning of the component 's value (for example, when combining field values). Message component values th erefore need to be canonicalized before they are signed, to ensure that a signat ure can be verified despite such intermediary transformations. This document def ines rules for each component identifier that transform the identifier's associa ted component value into such a canonical form.</t> <t>The component value associated with a component identifier is defined b y the identifier itself. Component values <bcp14>MUST NOT</bcp14> contain newlin e (<tt>\n</tt>) characters. Some HTTP message components can undergo transformat ions that change the bitwise value without altering the meaning of the component 's value (for example, when combining field values). Message component values th erefore need to be canonicalized before they are signed, to ensure that a signat ure can be verified despite such intermediary transformations. This document def ines rules for each component identifier that transform the identifier's associa ted component value into such a canonical form.</t>
<t>The following sections define component identifier names, their paramet ers, their associated values, and the canonicalization rules for their values. T he method for combining message components into the signature base is defined in <xref target="create-sig-input"/>.</t> <t>The following sections define component identifier names, their paramet ers, their associated values, and the canonicalization rules for their values. T he method for combining message components into the signature base is defined in <xref target="create-sig-input"/>.</t>
<section anchor="http-fields"> <section anchor="http-fields">
<name>HTTP Fields</name> <name>HTTP Fields</name>
<t>The component name for an HTTP field is the lowercased form of its fi <t>The component name for an HTTP field is the lowercased form of its fi
eld name as defined in <xref section="5.1" sectionFormat="of" target="HTTP"/>. W eld name as defined in <xref section="5.1" sectionFormat="of" target="RFC9110"/>
hile HTTP field names are case-insensitive, implementations <bcp14>MUST</bcp14> . While HTTP field names are case insensitive, implementations <bcp14>MUST</bcp1
use lowercased field names (e.g., <tt>content-type</tt>, <tt>date</tt>, <tt>etag 4> use lowercased field names (e.g., <tt>content-type</tt>, <tt>date</tt>, <tt>e
</tt>) when using them as component names.</t> tag</tt>) when using them as component names.</t>
<t>The component value for an HTTP field is the field value for the name <t>The component value for an HTTP field is the field value for the name
d field as defined in <xref section="5.5" sectionFormat="of" target="HTTP"/>. Th d field as defined in <xref section="5.5" sectionFormat="of" target="RFC9110"/>.
e field value <bcp14>MUST</bcp14> be taken from the named header field of the ta The field value <bcp14>MUST</bcp14> be taken from the named header field of the
rget message unless this behavior is overridden by additional parameters and rul target message unless this behavior is overridden by additional parameters and
es, such as the <tt>req</tt> and <tt>tr</tt> flags, below. For most fields, the rules, such as the <tt>req</tt> and <tt>tr</tt> flags, below. For most fields, t
field value is an ASCII string as recommended by <xref target="HTTP"/>, and the he field value is an ASCII string as recommended by <xref target="RFC9110"/>, an
component value is exactly that string. Other encodings could exist in some impl d the component value is exactly that string. Other encodings could exist in som
ementations, and all non-ASCII field values <bcp14>MUST</bcp14> be encoded to AS e implementations, and all non-ASCII field values <bcp14>MUST</bcp14> be encoded
CII before being added to the signature base. The <tt>bs</tt> parameter defined to ASCII before being added to the signature base. The <tt>bs</tt> parameter, a
in <xref target="http-field-byte-sequence"/> provides a method for wrapping such s described in <xref target="http-field-byte-sequence"/>, provides a method for
problematic field values.</t> wrapping such problematic field values.</t>
<t>Unless overridden by additional parameters and rules, HTTP field valu <t>Unless overridden by additional parameters and rules, HTTP field valu
es <bcp14>MUST</bcp14> be combined into a single value as defined in <xref secti es <bcp14>MUST</bcp14> be combined into a single value as defined in <xref secti
on="5.2" sectionFormat="of" target="HTTP"/> to create the component value. Speci on="5.2" sectionFormat="of" target="RFC9110"/> to create the component value. Sp
fically, HTTP fields sent as multiple fields <bcp14>MUST</bcp14> be combined by ecifically, HTTP fields sent as multiple fields <bcp14>MUST</bcp14> be combined
concatenating the values using a single comma and a single space as a separator by concatenating the values using a single comma and a single space as a separat
("," + " "). Note that intermediaries are allowed to combine values of HTTP fiel or ("," + " "). Note that intermediaries are allowed to combine values of HTTP f
ds with any amount of whitespace between the commas, and if this behavior is not ields with any amount of whitespace between the commas, and if this behavior is
accounted for by the verifier, the signature can fail since the signer and veri not accounted for by the verifier, the signature can fail, since the signer and
fier will see a different component value in their respective signature bases. F verifier will see a different component value in their respective signature base
or robustness, it is <bcp14>RECOMMENDED</bcp14> that signed messages include onl s. For robustness, it is <bcp14>RECOMMENDED</bcp14> that signed messages include
y a single instance of any field covered under the signature, particularly with only a single instance of any field covered under the signature, particularly w
the value for any list-based fields serialized using the algorithm below. This a ith the value for any list-based fields serialized using the algorithm below. Th
pproach increases the chances of the field value remaining untouched through int is approach increases the chances of the field value remaining untouched through
ermediaries. Where that approach is not possible and multiple instances of a fie intermediaries. Where that approach is not possible and multiple instances of a
ld need to be sent separately, it is <bcp14>RECOMMENDED</bcp14> that signers and field need to be sent separately, it is <bcp14>RECOMMENDED</bcp14> that signers
verifiers process any list-based fields taking all individual field values and and verifiers process any list-based fields taking all individual field values
combining them based on the strict algorithm below, to counter possible intermed and combining them based on the strict algorithm below, to counter possible inte
iary behavior. When the field in question is a structured field of type List or rmediary behavior. When the field in question is a Structured Field of type List
Dictionary, this effect can be accomplished more directly by requiring the stric or Dictionary, this effect can be accomplished more directly by requiring the s
t structured field serialization of the field value, as described in <xref targe trict Structured Field serialization of the field value, as described in <xref t
t="http-field-structured"/>.</t> arget="http-field-structured"/>.</t>
<t>Note that some HTTP fields, such as Set-Cookie (<xref target="COOKIE" <t>Note that some HTTP fields, such as Set-Cookie <xref target="RFC6265"
/>), do not follow a syntax that allows for combination of field values in this />, do not follow a syntax that allows for the combination of field values in th
manner (such that the combined output is unambiguous from multiple inputs). Even is manner (such that the combined output is unambiguous from multiple inputs). E
though the component value is never parsed by the message signature process and ven though the component value is never parsed by the message signature process
used only as part of the signature base in <xref target="create-sig-input"/>, c and is used only as part of the signature base (<xref target="create-sig-input"/
aution needs to be taken when including such fields in signatures since the comb >), caution needs to be taken when including such fields in signatures, since th
ined value could be ambiguous. The <tt>bs</tt> parameter defined in <xref target e combined value could be ambiguous. The <tt>bs</tt> parameter, as described in
="http-field-byte-sequence"/> provides a method for wrapping such problematic fi <xref target="http-field-byte-sequence"/>, provides a method for wrapping such p
elds. See <xref target="security-non-list"/> for more discussion of this issue.< roblematic fields. See <xref target="security-non-list"/> for more discussion re
/t> garding 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> <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 va <ol spacing="normal" type="1"><li>Create an ordered list of the field va
lues of each instance of the field in the message, in the order that they occur lues of each instance of the field in the message, in the order they occur (or w
(or will occur) in the message.</li> ill occur) in the message.</li>
<li>Strip leading and trailing whitespace from each item in the list. <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 trailin Note that since HTTP field values are not allowed to contain leading and trailin
g whitespace, this will be a no-op in a compliant implementation.</li> g whitespace, this would be a no-op in a compliant implementation.</li>
<li>Remove any obsolete line-folding within the line and replace it wi <li>Remove any obsolete line folding within the line, and replace it w
th a single space (" "), as discussed in <xref section="5.2" sectionFormat="of" ith a single space (" "), as discussed in <xref section="5.2" sectionFormat="of"
target="HTTP1"/>. Note that this behavior is specific to HTTP/1.1 and does not a target="RFC9112"/>. Note that this behavior is specific to HTTP/1.1 and does no
pply to other versions of the HTTP specification which do not allow internal lin t apply to other versions of the HTTP specification, which do not allow internal
e folding.</li> line folding.</li>
<li>Concatenate the list of values together with a single comma (",") <li>Concatenate the list of values with a single comma (",") and a sin
and a single space (" ") between each item.</li> gle space (" ") between each item.</li>
</ol> </ol>
<t>The resulting string is the component value for the field.</t> <t>The resulting string is the component value for the field.</t>
<t>Note that some HTTP fields have values with multiple valid serializat <t>Note that some HTTP fields have values with multiple valid serializat
ions that have equivalent semantics, such as allow case-insensitive values that ions that have equivalent semantics, such as allowing case-insensitive values th
intermediaries could change. Applications signing and processing such fields <bc at intermediaries could change. Applications signing and processing such fields
p14>MUST</bcp14> consider how to handle the values of such fields to ensure that <bcp14>MUST</bcp14> consider how to handle the values of such fields to ensure t
the signer and verifier can derive the same value, as discussed in <xref target hat the signer and verifier can derive the same value, as discussed in <xref tar
="security-field-values"/>.</t> get="security-field-values"/>.</t>
<t>Following are non-normative examples of component values for header f <t>The following are non-normative examples of component values for head
ields, given the following example HTTP message fragment:</t> er fields, given the following example HTTP message fragment:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Host: www.example.com Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
X-OWS-Header: Leading and trailing whitespace. X-OWS-Header: Leading and trailing whitespace.
X-Obs-Fold-Header: Obsolete X-Obs-Fold-Header: Obsolete
line folding. line folding.
Cache-Control: max-age=60 Cache-Control: max-age=60
Cache-Control: must-revalidate Cache-Control: must-revalidate
Example-Dict: a=1, b=2;x=1;y=2, c=(a b c) Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)
]]></sourcecode> ]]></sourcecode>
<t>The following example shows the component values for these example he ader fields, presented using the signature base format defined in <xref target=" create-sig-input"/>:</t> <t>The following example shows the component values for these example he ader fields, presented using the signature base format defined in <xref target=" create-sig-input"/>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"host": www.example.com "host": www.example.com
"date": Tue, 20 Apr 2021 02:07:56 GMT "date": Tue, 20 Apr 2021 02:07:56 GMT
"x-ows-header": Leading and trailing whitespace. "x-ows-header": Leading and trailing whitespace.
"x-obs-fold-header": Obsolete line folding. "x-obs-fold-header": Obsolete line folding.
"cache-control": max-age=60, must-revalidate "cache-control": max-age=60, must-revalidate
"example-dict": a=1, b=2;x=1;y=2, c=(a b c) "example-dict": a=1, b=2;x=1;y=2, c=(a b c)
]]></artwork> ]]></artwork>
<t>Empty HTTP fields can also be signed when present in a message. The c anonicalized value is the empty string. This means that the following empty head er, with (SP) indicating a single trailing space character before the empty fiel d value:</t> <t>Empty HTTP fields can also be signed when present in a message. The c anonicalized value is the empty string. This means that the following empty head er field, with (SP) indicating a single trailing space character before the empt y field value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
X-Empty-Header:(SP) X-Empty-Header:(SP)
]]></artwork> ]]></artwork>
<t>Is serialized by the <xref target="create-sig-input">signature base g eneration algorithm</xref> with an empty string value following the colon and sp ace added after the content identifier.</t> <t>is serialized by the <xref target="create-sig-input">signature base g eneration algorithm</xref> with an empty string value following the colon and sp ace added after the component identifier.</t>
<artwork><![CDATA[ <artwork><![CDATA[
"x-empty-header":(SP) "x-empty-header":(SP)
]]></artwork> ]]></artwork>
<t>Any HTTP field component identifiers <bcp14>MAY</bcp14> have the foll owing parameters in specific circumstances, each described in detail in their ow n sections:</t> <t>Any HTTP field component identifiers <bcp14>MAY</bcp14> have the foll owing parameters in specific circumstances, each described in detail in their ow n sections:</t>
<dl> <dl>
<dt><tt>sf</tt></dt> <dt><tt>sf</tt></dt>
<dd> <dd>
<t>A boolean flag indicating that the component value is serialized <t>A Boolean flag indicating that the component value is serialized
using strict encoding using strict encoding
of the structured field value (<xref target="http-field-structured"/>).</t> of the Structured Field value (<xref target="http-field-structured"/>).</t>
</dd> </dd>
<dt><tt>key</tt></dt> <dt><tt>key</tt></dt>
<dd> <dd>
<t>A string parameter used to select a single member value from a Di ctionary structured field (<xref target="http-field-dictionary"/>).</t> <t>A String parameter used to select a single member value from a Di ctionary Structured Field (<xref target="http-field-dictionary"/>).</t>
</dd> </dd>
<dt><tt>bs</tt></dt> <dt><tt>bs</tt></dt>
<dd> <dd>
<t>A boolean flag indicating that individual field values are encode d using Byte Sequence data structures before being combined into the component v alue (<xref target="http-field-byte-sequence"/>).</t> <t>A Boolean flag indicating that individual field values are encode d using Byte Sequence data structures before being combined into the component v alue (<xref target="http-field-byte-sequence"/>).</t>
</dd> </dd>
<dt><tt>req</tt></dt> <dt><tt>req</tt></dt>
<dd> <dd>
<t>A 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="con tent-request-response"/>).</t> <t>A 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="con tent-request-response"/>).</t>
</dd> </dd>
<dt><tt>tr</tt></dt> <dt><tt>tr</tt></dt>
<dd> <dd>
<t>A boolean flag indicating that the field value is taken from the trailers of the message as defined in <xref section="6.5" sectionFormat="of" tar get="HTTP"/>. If this flag is absent, the field value is taken from the headers of the message as defined in <xref section="6.3" sectionFormat="of" target="HTTP "/> (<xref target="http-trailer"/>).</t> <t>A Boolean flag indicating that the field value is taken from the trailers of the message as defined in <xref section="6.5" sectionFormat="of" tar get="RFC9110"/>. If this flag is absent, the field value is taken from the heade r fields of the message as defined in <xref section="6.3" sectionFormat="of" tar get="RFC9110"/> (<xref target="http-trailer"/>).</t>
</dd> </dd>
</dl> </dl>
<t>Multiple parameters <bcp14>MAY</bcp14> be specified together, though <t>Multiple parameters <bcp14>MAY</bcp14> be specified together, though
some combinations are redundant or incompatible. For example, the <tt>sf</tt> pa some combinations are redundant or incompatible. For example, the <tt>sf</tt> pa
rameter's functionality is already covered when the <tt>key</tt> parameter is us rameter's functionality is already covered when the <tt>key</tt> parameter is us
ed on a dictionary item, since <tt>key</tt> requires strict serialization of the ed on a 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 val value. The <tt>bs</tt> parameter, which requires the raw bytes of the field val
ues from the message, is not compatible with use of the <tt>sf</tt> or <tt>key</ ues from the message, is not compatible with the use of the <tt>sf</tt> or <tt>k
tt> parameters, which require the parsed data structures of the field values aft ey</tt> parameters, which require the parsed data structures of the field values
er combination.</t> after combination.</t>
<t>Additional parameters can be defined in the HTTP Signature Component <t>Additional parameters can be defined in the "HTTP Signature Component
Parameters registry established in <xref target="component-param-registry"/>.</t Parameters" registry established in <xref target="component-param-registry"/>.<
> /t>
<section anchor="http-field-structured"> <section anchor="http-field-structured">
<name>Strict Serialization of HTTP Structured Fields</name> <name>Strict Serialization of HTTP Structured Fields</name>
<t>If the value of an HTTP field is known by the application to be a s <t>If the value of an HTTP field is known by the application to be a S
tructured field type (as defined in <xref target="STRUCTURED-FIELDS"/> or its ex tructured Field type (as defined in <xref target="RFC8941"/> or its extensions o
tensions or updates), and the expected type of the structured field is known, th r updates) and the expected type of the Structured Field is known, the signer <b
e signer <bcp14>MAY</bcp14> include the <tt>sf</tt> parameter in the component i cp14>MAY</bcp14> include the <tt>sf</tt> parameter in the component identifier.
dentifier. If this parameter is included with a component identifier, the HTTP field value
If this parameter is included with a component identifier, the HTTP field value <bcp14>MUST</bcp14> be serialized using the formal serialization rules specified
<bcp14>MUST</bcp14> be serialized using the formal serialization rules specified in <xref section="4" sectionFormat="of" target="RFC8941"/> (or the
in <xref section="4" sectionFormat="of" target="STRUCTURED-FIELDS"/> (or the
applicable formal serialization section of its extensions or updates) applicable to applicable formal serialization section of its extensions or updates) applicable to
the type of the HTTP field. Note that this process the type of the HTTP field. Note that this process
will replace any optional internal whitespace with a single space character, amo ng other potential transformations of the value.</t> will replace any optional internal whitespace with a single space character, amo ng other potential transformations of the value.</t>
<t>If multiple field values occur within a message, these values <bcp1 4>MUST</bcp14> be combined into a single List or Dictionary structure before ser ialization.</t> <t>If multiple field values occur within a message, these values <bcp1 4>MUST</bcp14> be combined into a single List or Dictionary structure before ser ialization.</t>
<t>If the application does not know the type of the field, or the appl <t>If the application does not know the type of the field or does not
ication does not know how to serialize the type of the field, the use of this fl know how to serialize the type of the field, the use of this flag will produce a
ag will produce an error. As a consequence, the signer can only reliably sign fi n error. As a consequence, the signer can only reliably sign fields using this f
elds using this flag when the verifier's system knows the type as well.</t> lag when the verifier's system knows the type as well.</t>
<t>For example, the following dictionary field is a valid serializatio <t>For example, the following Dictionary field is a valid serializatio
n:</t> n:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Dict: a=1, b=2;x=1;y=2, c=(a b c) Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)
]]></sourcecode> ]]></sourcecode>
<t>If included in the signature base without parameters, its value wou ld be:</t> <t>If included in the signature base without parameters, its value wou ld be:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"example-dict": a=1, b=2;x=1;y=2, c=(a b c) "example-dict": a=1, b=2;x=1;y=2, c=(a b c)
]]></artwork> ]]></artwork>
<t>However, if the <tt>sf</tt> parameter is added, the value is re-ser ialized as follows:</t> <t>However, if the <tt>sf</tt> parameter is added, the value is reseri alized as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"example-dict";sf: a=1, b=2;x=1;y=2, c=(a b c) "example-dict";sf: a=1, b=2;x=1;y=2, c=(a b c)
]]></artwork> ]]></artwork>
<t>The resulting string is used as the component value in <xref target ="http-fields"/>.</t> <t>The resulting string is used as the component value; see <xref targ et="http-fields"/>.</t>
</section> </section>
<section anchor="http-field-dictionary"> <section anchor="http-field-dictionary">
<name>Dictionary Structured Field Members</name> <name>Dictionary Structured Field Members</name>
<t>If a given field is known by the application to be a Dictionary str uctured field, an individual member in the value of that Dictionary is identifie d by using the parameter <tt>key</tt> and the Dictionary member key as a String value.</t> <t>If a given field is known by the application to be a Dictionary Str uctured Field, an individual member in the value of that Dictionary is identifie d 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 <bcp1 4>MUST</bcp14> be combined into a single Dictionary structure before serializati on.</t> <t>If multiple field values occur within a message, these values <bcp1 4>MUST</bcp14> be combined into a single Dictionary structure before serializati on.</t>
<t>An individual member value of a Dictionary Structured Field is cano nicalized by applying the serialization algorithm described in <xref section="4. 1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> on the <tt>member_value</tt > and its parameters, not including the dictionary key itself. Specifically, the value is serialized as an Item or Inner List (the two possible values of a Dict ionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in <xref section="4" sectionFormat="of" targ et="STRUCTURED-FIELDS"/> (or the applicable section of its extensions or updates ).</t> <t>An individual member value of a Dictionary Structured Field is cano nicalized by applying the serialization algorithm described in <xref section="4. 1.2" sectionFormat="of" target="RFC8941"/> on the <tt>member_value</tt> and its parameters, not including the Dictionary key itself. Specifically, the value is serialized as an Item or Inner List (the two possible values of a Dictionary mem ber), with all parameters and possible subfields serialized using the strict ser ialization rules defined in <xref section="4" sectionFormat="of" target="RFC8941 "/> (or the applicable section of its extensions or updates).</t>
<t>Each parameterized key for a given field <bcp14>MUST NOT</bcp14> ap pear 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 i n the source Dictionary.</t> <t>Each parameterized key for a given field <bcp14>MUST NOT</bcp14> ap pear 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 i n 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 signatu re base generation.</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 signatu re base generation.</t>
<t>Following are non-normative examples of canonicalized values for Di ctionary structured field members given the following example header field, whos e value is known by the application to be a Dictionary:</t> <t>The following are non-normative examples of canonicalized values fo r Dictionary 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[ <sourcecode type="http-message"><![CDATA[
Example-Dict: a=1, b=2;x=1;y=2, c=(a b c), d Example-Dict: a=1, b=2;x=1;y=2, c=(a b c), d
]]></sourcecode> ]]></sourcecode>
<t>The following example shows canonicalized values for different comp onent identifiers of this field, presented using the signature base format discu ssed in <xref target="create-sig-input"/>:</t> <t>The following example shows canonicalized values for different comp onent identifiers of this field, presented using the signature base format discu ssed in <xref target="create-sig-input"/>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"example-dict";key="a": 1 "example-dict";key="a": 1
"example-dict";key="d": ?1 "example-dict";key="d": ?1
"example-dict";key="b": 2;x=1;y=2 "example-dict";key="b": 2;x=1;y=2
"example-dict";key="c": (a b c) "example-dict";key="c": (a b c)
]]></artwork> ]]></artwork>
<t>Note that the value for <tt>key="c"</tt> has been re-serialized acc ording to the strict <tt>member_value</tt> algorithm, and the value for <tt>key= "d"</tt> has been serialized as a Boolean value.</t> <t>Note that the value for <tt>key="c"</tt> has been reserialized acco rding 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>
<section anchor="http-field-byte-sequence"> <section anchor="http-field-byte-sequence">
<name>Binary-wrapped HTTP Fields</name> <name>Binary-Wrapped HTTP Fields</name>
<t>If the value of the HTTP field in question is known by the applicat <t>If the value of the HTTP field in question is known by the applicat
ion to cause problems with serialization, particularly with the combination of m ion to cause problems with serialization, particularly with the combination of m
ultiple values into a single line as discussed in <xref target="security-non-lis ultiple values into a single line as discussed in <xref target="security-non-lis
t"/>, the signer <bcp14>SHOULD</bcp14> include the <tt>bs</tt> parameter in a co t"/>, the signer <bcp14>SHOULD</bcp14> include the <tt>bs</tt> parameter in a co
mponent identifier to indicate the values of the field need to be wrapped as bin mponent identifier to indicate that the values of the field need to be wrapped a
ary structures before being combined.</t> s binary structures before being combined.</t>
<t>If this parameter is included with a component identifier, the comp onent value <bcp14>MUST</bcp14> be calculated using the following algorithm:</t> <t>If this parameter is included with a component identifier, the comp onent 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> <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.</l i> <li>Create an empty List for accumulating processed field values.</l i>
<li> <li>
<t>For each field value in the set: <t>For each field value in the set:
</t> </t>
<ol spacing="normal" type="1"><li>Strip leading and trailing white <ol spacing="normal" type="%p%d."><li>Strip leading and trailing w
space from the field value. Note that since HTTP field values are not allowed to hitespace from the field value. Note that since HTTP field values are not allowe
contain leading and trailing whitespace, this will be a no-op in a compliant im d to contain leading and trailing whitespace, this would be a no-op in a complia
plementation.</li> nt implementation.</li>
<li>Remove any obsolete line-folding within the line and replace <li>Remove any obsolete line folding within the line, and replac
it with a single space (" "), as discussed in <xref section="5.2" sectionFormat e it with a single space (" "), as discussed in <xref section="5.2" sectionForma
="of" target="HTTP1"/>. Note that this behavior is specific to <xref target="HTT t="of" target="RFC9112"/>. Note that this behavior is specific to <xref target="
P1"/> and does not apply to other versions of the HTTP specification.</li> 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 Sequ ence. Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations.</li> <li>Encode the bytes of the resulting field value as a Byte Sequ ence. 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> <li>Add the Byte Sequence to the List accumulator.</li>
</ol> </ol>
</li> </li>
<li>The intermediate result is a List of Byte Sequence values.</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"/> and return this output.</li> <li>Follow the strict serialization of a List as described in <xref section="4.1.1" sectionFormat="of" target="RFC8941"/>, and return this output.</ li>
</ol> </ol>
<t>For example, the following field with internal commas prevents the distinct field values from being safely combined:</t> <t>For example, the following field with internal commas prevents the distinct field values from being safely combined:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots Example-Header: value, with, lots
Example-Header: of, commas Example-Header: of, commas
]]></sourcecode> ]]></sourcecode>
<t>In our example, the same field can be sent with a semantically diff erent single value:</t> <t>In our example, the same field can be sent with a semantically diff erent single value:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots, of, commas Example-Header: value, with, lots, of, commas
]]></sourcecode> ]]></sourcecode>
skipping to change at line 391 skipping to change at line 379
"example-header": value, with, lots, of, commas "example-header": value, with, lots, of, commas
]]></artwork> ]]></artwork>
<t>However, if the <tt>bs</tt> parameter is added, the two separate in stances are encoded and serialized as follows:</t> <t>However, if the <tt>bs</tt> parameter is added, the two separate in stances are encoded and serialized as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHM=:, :b2YsIGNvbW1hcw==: "example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHM=:, :b2YsIGNvbW1hcw==:
]]></artwork> ]]></artwork>
<t>For the single-instance field above, the encoding with the <tt>bs</ tt> parameter is:</t> <t>For the single-instance field above, the encoding with the <tt>bs</ tt> parameter is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHMsIG9mLCBjb21tYXM=: "example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHMsIG9mLCBjb21tYXM=:
]]></artwork> ]]></artwork>
<t>This component value is distinct from the multiple-instance field a bove, preventing a collision which could potentially be exploited.</t> <t>This component value is distinct from the multiple-instance field a bove, preventing a collision that could potentially be exploited.</t>
</section> </section>
<section anchor="http-trailer"> <section anchor="http-trailer">
<name>Trailer Fields</name> <name>Trailer Fields</name>
<t>If the signer wants to include a trailer field in the signature, th e signer <bcp14>MUST</bcp14> include the <tt>tr</tt> boolean parameter to indica te the value <bcp14>MUST</bcp14> be taken from the trailer fields and not from t he header fields.</t> <t>If the signer wants to include a trailer field in the signature, th e signer <bcp14>MUST</bcp14> include the <tt>tr</tt> Boolean parameter to indica te that the value <bcp14>MUST</bcp14> be taken from the trailer fields and not f rom the header fields.</t>
<t>For example, given the following message:</t> <t>For example, given the following message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/plain Content-Type: text/plain
Transfer-Encoding: chunked Transfer-Encoding: chunked
Trailer: Expires Trailer: Expires
4 4
HTTP HTTP
7 7
Message Message
a a
Signatures Signatures
0 0
Expires: Wed, 9 Nov 2022 07:28:00 GMT Expires: Wed, 9 Nov 2022 07:28:00 GMT
]]></sourcecode> ]]></sourcecode>
<t>The signer decides to add both the Trailer header field as well as the Expires trailer to the signature base, along with the status code derived co mponent:</t> <t>The signer decides to add both the Trailer header field and the Exp ires trailer field to the signature base, along with the status code derived com ponent:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@status": 200 "@status": 200
"trailer": Expires "trailer": Expires
"expires";tr: Wed, 9 Nov 2022 07:28:00 GMT "expires";tr: Wed, 9 Nov 2022 07:28:00 GMT
]]></artwork> ]]></artwork>
<t>If a field is available as both a header and trailer in a message, <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 , both values <bcp14>MAY</bcp14> be signed, but the values <bcp14>MUST</bcp14> b
signed separately. The values of header fields and trailer fields of the same na e signed separately. The values of header fields and trailer fields of the same
me <bcp14>MUST NOT</bcp14> be combined for purposes of the signature.</t> 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 drop <t>Since trailer fields could be merged into the header fields or drop
ped entirely by intermediaries as per <xref section="6.5.1" sectionFormat="of" t ped entirely by intermediaries as per <xref section="6.5.1" sectionFormat="of" t
arget="HTTP"/>, it is <bcp14>NOT RECOMMENDED</bcp14> to include trailers in the arget="RFC9110"/>, it is <bcp14>NOT RECOMMENDED</bcp14> to include trailers in t
signature unless the signer knows that the verifier will have access to the valu he signature unless the signer knows that the verifier will have access to the v
es of the trailers as sent.</t> alues of the trailers as sent.</t>
</section> </section>
</section> </section>
<section anchor="derived-components"> <section anchor="derived-components">
<name>Derived Components</name> <name>Derived Components</name>
<t>In addition to HTTP fields, there are a number of different component <t>In addition to HTTP fields, there are a number of different component
s that can be derived from the control data, signature context, or other aspects s 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 th of the HTTP message being signed. Such derived components can be included in th
e signature base by defining a component name, possible parameters, message targ e signature base by defining a component name, possible parameters, message targ
et, and the derivation method for its component value.</t> ets, and the derivation method for its component value.</t>
<t>Derived component names <bcp14>MUST</bcp14> start with the "at" <tt>@ <t>Derived component names <bcp14>MUST</bcp14> start with the "at" (<tt>
</tt> character. This differentiates derived component names from HTTP field nam @</tt>) character. This differentiates derived component names from HTTP field n
es, which cannot contain the <tt>@</tt> character as per <xref section="5.1" sec ames, which cannot contain the <tt>@</tt> character as per <xref section="5.1" s
tionFormat="of" target="HTTP"/>. Processors of HTTP Message Signatures <bcp14>MU ectionFormat="of" target="RFC9110"/>. Processors of HTTP message signatures <bcp
ST</bcp14> treat derived component names separately from field names, as discuss 14>MUST</bcp14> treat derived component names separately from field names, as di
ed in <xref target="security-lazy-header-parser"/>.</t> scussed in <xref target="security-lazy-header-parser"/>.</t>
<t>This specification defines the following derived components:</t> <t>This specification defines the following derived components:</t>
<dl> <dl>
<dt>@method</dt> <dt>@method</dt>
<dd> <dd>
<t>The method used for a request. (<xref target="content-request-met hod"/>)</t> <t>The method used for a request (<xref target="content-request-meth od"/>).</t>
</dd> </dd>
<dt>@target-uri</dt> <dt>@target-uri</dt>
<dd> <dd>
<t>The full target URI for a request. (<xref target="content-target- uri"/>)</t> <t>The full target URI for a request (<xref target="content-target-u ri"/>).</t>
</dd> </dd>
<dt>@authority</dt> <dt>@authority</dt>
<dd> <dd>
<t>The authority of the target URI for a request. (<xref target="con tent-request-authority"/>)</t> <t>The authority of the target URI for a request (<xref target="cont ent-request-authority"/>).</t>
</dd> </dd>
<dt>@scheme</dt> <dt>@scheme</dt>
<dd> <dd>
<t>The scheme of the target URI for a request. (<xref target="conten t-request-scheme"/>)</t> <t>The scheme of the target URI for a request (<xref target="content -request-scheme"/>).</t>
</dd> </dd>
<dt>@request-target</dt> <dt>@request-target</dt>
<dd> <dd>
<t>The request target. (<xref target="content-request-target"/>)</t> <t>The request target (<xref target="content-request-target"/>).</t>
</dd> </dd>
<dt>@path</dt> <dt>@path</dt>
<dd> <dd>
<t>The absolute path portion of the target URI for a request. (<xref target="content-request-path"/>)</t> <t>The absolute path portion of the target URI for a request (<xref target="content-request-path"/>).</t>
</dd> </dd>
<dt>@query</dt> <dt>@query</dt>
<dd> <dd>
<t>The query portion of the target URI for a request. (<xref target= "content-request-query"/>)</t> <t>The query portion of the target URI for a request (<xref target=" content-request-query"/>).</t>
</dd> </dd>
<dt>@query-param</dt> <dt>@query-param</dt>
<dd> <dd>
<t>A parsed and encoded query parameter of the target URI for a requ est. (<xref target="content-request-query-param"/>)</t> <t>A parsed and encoded query parameter of the target URI for a requ est (<xref target="content-request-query-param"/>).</t>
</dd> </dd>
<dt>@status</dt> <dt>@status</dt>
<dd> <dd>
<t>The status code for a response. (<xref target="content-status-cod e"/>)</t> <t>The status code for a response (<xref target="content-status-code "/>).</t>
</dd> </dd>
</dl> </dl>
<t>Additional derived component names are defined in the HTTP Signature <t>Additional derived component names are defined in the <xref target="c
Derived Component Names Registry. (<xref target="content-registry"/>)</t> ontent-registry">"HTTP Signature Derived Component Names" registry</xref>.</t>
<t>Derived component values are taken from the context of the target mes <t>Derived component values are taken from the context of the target mes
sage for the signature. This context includes information about the message itse sage for the signature. This context includes information about the message itse
lf, such as its control data, as well as any additional state and context held b lf, such as its control data, as well as any additional state and context held b
y the signer or verifier. In particular, when signing a response, the signer can y 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 include any derived components from the originating request by using the <xref
target="content-request-response">request-response parameter</xref>.</t> target="content-request-response"><tt>req</tt> parameter</xref>.</t>
<dl> <dl>
<dt>request:</dt> <dt>request:</dt>
<dd> <dd>
<t>Values derived from and results applied to an HTTP request messag <t>Values derived from, and results applied to, an HTTP request mess
e as described in <xref section="3.4" sectionFormat="of" target="HTTP"/>. If the age as described in <xref section="3.4" sectionFormat="of" target="RFC9110"/>. I
target message of the signature is a response, using the <tt>req</tt> parameter f the target message of the signature is a response, derived components that tar
allows a request-targeted derived component to be included in the signature (se get request messages can be included by using the <tt>req</tt> parameter as defi
e <xref target="content-request-response"/>).</t> ned in
<xref target="content-request-response"/>.</t>
</dd> </dd>
<dt>response:</dt> <dt>response:</dt>
<dd> <dd>
<t>Values derived from and results applied to an HTTP response messa ge as described in <xref section="3.4" sectionFormat="of" target="HTTP"/>.</t> <t>Values derived from, and results applied to, an HTTP response mes sage as described in <xref section="3.4" sectionFormat="of" target="RFC9110"/>.< /t>
</dd> </dd>
<dt>request, response:</dt>
<dd>Values derived from, and results applied to, either a request mess
age or a response message.</dd>
</dl> </dl>
<t>A derived component definition <bcp14>MUST</bcp14> define all target message types to which it can be applied.</t> <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> <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"> <section anchor="content-request-method">
<name>Method</name> <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 as per <xref section="9.1" sectionFormat="comma" target="HTTP"/>. While conventionally stand ardized method names are uppercase <xref target="ASCII"/>, no transformation to the input method value's case is performed.</t> <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 as per <xref section="9.1" sectionFormat="comma" target="RFC9110"/>. While conventionally st andardized method names are uppercase <xref target="RFC0020"/>, no transformatio n to the input method value's case is performed.</t>
<t>For example, the following request message:</t> <t>For example, the following request message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1 POST /path?param=value HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@method</tt> component value:</t> <t>would result in the following <tt>@method</tt> component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
POST POST
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@method": POST "@method": POST
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="content-target-uri"> <section anchor="content-target-uri">
<name>Target URI</name> <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 th e request, potentially assembled from all available parts including the authorit y and request target as described in <xref section="7.1" sectionFormat="comma" t arget="HTTP"/>.</t> <t>The <tt>@target-uri</tt> derived component refers to the target URI of a request message. The component value is the target URI of the request (<xr ef section="7.1" sectionFormat="comma" target="RFC9110"/>), assembled from all a vailable URI components, including the authority.</t>
<t>For example, the following message sent over HTTPS:</t> <t>For example, the following message sent over HTTPS:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1 POST /path?param=value HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@target-uri</tt> component value: </t> <t>would result in the following <tt>@target-uri</tt> component value: </t>
<artwork><![CDATA[ <artwork><![CDATA[
https://www.example.com/path?param=value https://www.example.com/path?param=value
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@target-uri": https://www.example.com/path?param=value "@target-uri": https://www.example.com/path?param=value
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="content-request-authority"> <section anchor="content-request-authority">
<name>Authority</name> <name>Authority</name>
<t>The <tt>@authority</tt> derived component refers to the authority c <t>The <tt>@authority</tt> derived component refers to the authority c
omponent of the target URI of the HTTP request message, as defined in <xref sect omponent of the target URI of the HTTP request message, as defined in <xref sect
ion="7.2" sectionFormat="comma" target="HTTP"/>. In HTTP/1.1, this is usually co ion="7.2" sectionFormat="comma" target="RFC9110"/>. In HTTP/1.1, this is usually
nveyed using the Host header, while in HTTP/2 and HTTP/3 it is conveyed using th conveyed using the Host header field, while in HTTP/2 and HTTP/3 it is conveyed
e :authority pseudo-header. The value is the fully-qualified authority component using the :authority pseudo-header. The value is the fully qualified authority
of the request, comprised of the host and, optionally, port of the request targ component of the request, comprised of the host and, optionally, port of the req
et, as a string. uest target, as a string.
The component value <bcp14>MUST</bcp14> be normalized according to the rules in The component value <bcp14>MUST</bcp14> be normalized according to the rules pro
<xref section="4.2.3" sectionFormat="comma" target="HTTP"/>. Namely, the host na vided in <xref section="4.2.3" sectionFormat="comma" target="RFC9110"/>. Namely,
me is normalized to lowercase and the default port is omitted.</t> the hostname is normalized to lowercase, and the default port is omitted.</t>
<t>For example, the following request message:</t> <t>For example, the following request message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1 POST /path?param=value HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@authority</tt> component value:< /t> <t>would result in the following <tt>@authority</tt> component value:< /t>
<artwork><![CDATA[ <artwork><![CDATA[
www.example.com www.example.com
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@authority": www.example.com "@authority": www.example.com
]]></artwork> ]]></artwork>
<t>The <tt>@authority</tt> derived component <bcp14>SHOULD</bcp14> be used instead of signing the Host header directly, see <xref target="security-not -fields"/>.</t> <t>The <tt>@authority</tt> derived component <bcp14>SHOULD</bcp14> be used instead of signing the Host header field directly. See <xref target="secur ity-not-fields"/>.</t>
</section> </section>
<section anchor="content-request-scheme"> <section anchor="content-request-scheme">
<name>Scheme</name> <name>Scheme</name>
<t>The <tt>@scheme</tt> derived component refers to the scheme of the <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 l target URL of the HTTP request message. The component value is the scheme as a l
owercase string as defined in <xref section="4.2" sectionFormat="comma" target=" owercase string as defined in <xref section="4.2" sectionFormat="comma" target="
HTTP"/>. RFC9110"/>.
While the scheme itself is case-insensitive, it <bcp14>MUST</bcp14> be normalize While the scheme itself is case insensitive, it <bcp14>MUST</bcp14> be normalize
d to lowercase for d to lowercase for
inclusion in the signature base.</t> inclusion in the signature base.</t>
<t>For example, the following request message requested over plain HTT P:</t> <t>For example, the following request message sent over plain HTTP:</t >
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1 POST /path?param=value HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@scheme</tt> component value:</t> <t>would result in the following <tt>@scheme</tt> component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
http http
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@scheme": http "@scheme": http
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="content-request-target"> <section anchor="content-request-target">
<name>Request Target</name> <name>Request Target</name>
<t>The <tt>@request-target</tt> derived component refers to the full r equest target of the HTTP request message, <t>The <tt>@request-target</tt> derived component refers to the full r equest target of the HTTP request message,
as defined in <xref section="7.1" sectionFormat="comma" target="HTTP"/>. The com ponent value of the request target can take different forms, as defined in <xref section="7.1" sectionFormat="comma" target="RFC9110"/>. The component value of the request target can take different forms,
depending on the type of request, as described below.</t> depending on the type of request, as described below.</t>
<t>For HTTP/1.1, the component value is equivalent to the request targ et <t>For HTTP/1.1, the component value is equivalent to the request targ et
portion of the request line. However, this value is more difficult to reliably c onstruct in portion of the request line. However, this value is more difficult to reliably c onstruct in
other versions of HTTP. Therefore, it is <bcp14>NOT RECOMMENDED</bcp14> that thi s component be used other versions of HTTP. Therefore, it is <bcp14>NOT RECOMMENDED</bcp14> that thi s component be used
when versions of HTTP other than 1.1 might be in use.</t> when versions of HTTP other than 1.1 might be in use.</t>
<t>The origin form value is combination of the absolute path and query <t>The origin form value is a combination of the absolute path and que
components of the request URL. For example, the following request message:</t> ry components of the request URL.</t>
<t>For example, the following request message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /path?param=value HTTP/1.1 POST /path?param=value HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@request-target</tt> component va lue:</t> <t>would result in the following <tt>@request-target</tt> component va lue:</t>
<artwork><![CDATA[ <artwork><![CDATA[
/path?param=value /path?param=value
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@request-target": /path?param=value "@request-target": /path?param=value
]]></artwork> ]]></artwork>
<t>The following request to an HTTP proxy with the absolute-form value , containing the fully qualified target URI:</t> <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[ <sourcecode type="http-message"><![CDATA[
GET https://www.example.com/path?param=value HTTP/1.1 GET https://www.example.com/path?param=value HTTP/1.1
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@request-target</tt> component va lue:</t> <t>would result in the following <tt>@request-target</tt> component va lue:</t>
<artwork><![CDATA[ <artwork><![CDATA[
https://www.example.com/path?param=value https://www.example.com/path?param=value
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@request-target": https://www.example.com/path?param=value "@request-target": https://www.example.com/path?param=value
]]></artwork> ]]></artwork>
<t>The following CONNECT request with an authority-form value, contain ing the host and port of the target:</t> <t>The following CONNECT request with an authority-form value, contain ing the host and port of the target:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
CONNECT www.example.com:80 HTTP/1.1 CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@request-target</tt> component va lue:</t> <t>would result in the following <tt>@request-target</tt> component va lue:</t>
<artwork><![CDATA[ <artwork><![CDATA[
www.example.com:80 www.example.com:80
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@request-target": www.example.com:80 "@request-target": www.example.com:80
]]></artwork> ]]></artwork>
<t>The following OPTIONS request message with the asterisk-form value, containing a single asterisk <tt>*</tt> character:</t> <t>The following OPTIONS request message with the asterisk-form value, containing a single asterisk (<tt>*</tt>) character:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@request-target</tt> component va lue:</t> <t>would result in the following <tt>@request-target</tt> component va lue:</t>
<artwork><![CDATA[ <artwork><![CDATA[
* *
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@request-target": * "@request-target": *
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="content-request-path"> <section anchor="content-request-path">
<name>Path</name> <name>Path</name>
<t>The <tt>@path</tt> derived component refers to the target path of t he HTTP request message. The component value is the absolute path of the request target defined by <xref target="URI"/>, with no query component and no trailing <tt>?</tt> character. The value is normalized according to the rules in <xref s ection="4.2.3" sectionFormat="comma" target="HTTP"/>. Namely, an empty path stri ng is normalized as a single slash <tt>/</tt> character. Path components are rep resented by their values before decoding any percent-encoded octets, as describe d in the simple string comparison rules in <xref section="6.2.1" sectionFormat=" of" target="URI"/>.</t> <t>The <tt>@path</tt> derived component refers to the target path of t he HTTP request message. The component value is the absolute path of the request target defined by <xref target="RFC3986"/>, with no query component and no trai ling question mark (<tt>?</tt>) character. The value is normalized according to the rules provided in <xref section="4.2.3" sectionFormat="comma" target="RFC911 0"/>. Namely, an empty path string is normalized as a single slash (<tt>/</tt>) character. Path components are represented by their values before decoding any p ercent-encoded octets, as described in the simple string comparison rules provid ed in <xref section="6.2.1" sectionFormat="of" target="RFC3986"/>.</t>
<t>For example, the following request message:</t> <t>For example, the following request message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
GET /path?param=value HTTP/1.1 GET /path?param=value HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@path</tt> component value:</t> <t>would result in the following <tt>@path</tt> component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
/path /path
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@path": /path "@path": /path
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="content-request-query"> <section anchor="content-request-query">
<name>Query</name> <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"/>, including the leading <tt>?</tt> charac ter. The value is read using the simple string comparison rules in <xref section ="6.2.1" sectionFormat="of" target="URI"/>. Namely, percent-encoded octets are n ot decoded.</t> <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="RFC3986"/>, including the leading <tt>?</tt> ch aracter. The value is read using the simple string comparison rules provided in <xref section="6.2.1" sectionFormat="of" target="RFC3986"/>. Namely, percent-enc oded octets are not decoded.</t>
<t>For example, the following request message:</t> <t>For example, the following request message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
GET /path?param=value&foo=bar&baz=bat%2Dman HTTP/1.1 GET /path?param=value&foo=bar&baz=bat%2Dman HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@query</tt> component value:</t> <t>would result in the following <tt>@query</tt> component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
?param=value&foo=bar&baz=bat%2Dman ?param=value&foo=bar&baz=bat%2Dman
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@query": ?param=value&foo=bar&baz=bat%2Dman "@query": ?param=value&foo=bar&baz=bat%2Dman
]]></artwork> ]]></artwork>
<t>The following request message:</t> <t>The following request message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /path?queryString HTTP/1.1 POST /path?queryString HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@query</tt> component value:</t> <t>would result in the following <tt>@query</tt> component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
?queryString ?queryString
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@query": ?queryString "@query": ?queryString
]]></artwork> ]]></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 mes sage. If the query string is absent from the request message, the component valu e is the leading <tt>?</tt> character alone:</t> <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 mes sage. If the query string is absent from the request message, the component valu e is the leading <tt>?</tt> character alone:</t>
<artwork><![CDATA[ <artwork><![CDATA[
? ?
]]></artwork> ]]></artwork>
<t>Resulting in the following signature base line:</t> <t>resulting in the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@query": ? "@query": ?
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="content-request-query-param"> <section anchor="content-request-query-param">
<name>Query Parameters</name> <name>Query Parameters</name>
<t>If a request target URI uses HTML form parameters in the query stri <t>If the query portion of a request target URI uses HTML form paramet
ng as defined in the "application/x-www-form-urlencoded" section of <xref target ers in the format defined in Section&nbsp;<xref target="HTMLURL" section="5"
="HTMLURL"/>, relative="https://url.spec.whatwg.org/#application/x-www-form-urlencoded"
the <tt>@query-param</tt> derived component allows addressing of individual quer sectionFormat="bare">"application/x-www-form-urlencoded"</xref> of
y parameters. The query parameters <bcp14>MUST</bcp14> be parsed according to th <xref target="HTMLURL"/>,
e "application/x-www-form-urlencoded parsing" section of <xref target="HTMLURL"/ the <tt>@query-param</tt> derived component allows addressing of these individua
>, resulting in a list of (<tt>nameString</tt>, <tt>valueString</tt>) tuples. l query parameters. The query parameters <bcp14>MUST</bcp14> be parsed according
to
Section&nbsp;<xref target="HTMLURL" section="5.1" relative="https://url.spec.wha
twg.org/#urlencoded-parsing" sectionFormat="bare">"application/x-www-form-urlenc
oded parsing"</xref>
of <xref target="HTMLURL"/>, resulting in a list of (<tt>nameString</tt>, <tt>va
lueString</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 Strin g value. 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 Strin g value.
The component value of a single named parameter is the encoded <tt>valueString</ tt> of that single query parameter. 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 c overed components. Several different named query parameters <bcp14>MAY</bcp14> be included in the c overed components.
Single named parameters <bcp14>MAY</bcp14> occur in any order in the covered com ponents, regardless of the order they occur in the query string.</t> Single named parameters <bcp14>MAY</bcp14> occur in any order in the covered com ponents, 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 <t>The value of the <tt>name</tt> parameter and the component value of
a single named parameter are calculated by the following process:</t> a single named parameter are calculated via the following process:</t>
<ol spacing="normal" type="1"><li>Parse the <tt>nameString</tt> or <tt <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 >valueString</tt> of the named query parameter defined by
-form-urlencoded parsing" section of <xref target="HTMLURL"/>, which is the valu Section&nbsp;<xref target="HTMLURL" section="5.1" relative="https://url.spec.wha
e after percent-encoded octets are decoded.</li> twg.org/#urlencoded-parsing" sectionFormat="bare">"application/x-www-form-urlenc
<li>Encode the <tt>nameString</tt> or <tt>valueString</tt> using the oded parsing"</xref>
"percent-encode after encoding" process defined by the "application/x-www-form- of <xref target="HTMLURL"/>; this is the value after percent-encoded octets are
urlencoded serializing" section of <xref target="HTMLURL"/>, which results in an decoded.</li>
<xref target="ASCII"/> string.</li> <li>Encode the <tt>nameString</tt> or <tt>valueString</tt> using the
<li>Output the ASCII string,</li> "percent-encode after encoding" process defined by
Section&nbsp;<xref target="HTMLURL" section="5.2" relative="https://url.spec.wha
twg.org/#urlencoded-serializing" sectionFormat="bare">"application/x-www-form-ur
lencoded serializing"</xref> of <xref target="HTMLURL"/>; this results in an ASC
II string <xref target="RFC0020"/>.</li>
<li>Output the ASCII string.</li>
</ol> </ol>
<t>Note that the component value does not include any leading <tt>?</t t> characters, equals sign <tt>=</tt>, or separating <tt>&amp;</tt> characters. <t>Note that the component value does not include any leading question mark (<tt>?</tt>) characters, equals sign (<tt>=</tt>) characters, or separatin g ampersand (<tt>&amp;</tt>) characters.
Named query parameters with an empty <tt>valueString</tt> have an empty string a s the component value. Note that due to inconsistencies in implementations, some query parameter parsing libraries drop such empty values.</t> Named query parameters with an empty <tt>valueString</tt> have an empty string a s 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 no t occur in the query parameters, this <bcp14>MUST</bcp14> cause an error in the signature base generation.</t> <t>If a query parameter is named as a covered component but it does no t occur in the query parameters, this <bcp14>MUST</bcp14> cause an error in the signature base generation.</t>
<t>For example for the following request:</t> <t>For example, for the following request:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
GET /path?param=value&foo=bar&baz=batman&qux= HTTP/1.1 GET /path?param=value&foo=bar&baz=batman&qux= HTTP/1.1
Host: www.example.com Host: www.example.com
]]></sourcecode> ]]></sourcecode>
<t>Indicating the <tt>baz</tt>, <tt>qux</tt> and <tt>param</tt> named query parameters would result in the following <tt>@query-param</tt> component v alues:</t> <t>Indicating the <tt>baz</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>baz</em>: <tt>batman</tt></t>
<t><em>qux</em>: an empty string</t> <t><em>qux</em>: an empty string</t>
<t><em>param</em>: <tt>value</tt></t> <t><em>param</em>: <tt>value</tt></t>
<t>And the following signature base lines, with (SP) indicating a sing le trailing space character before the empty component value:</t> <t>and the following signature base lines, with (SP) indicating a sing le trailing space character before the empty component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@query-param";name="baz": batman "@query-param";name="baz": batman
"@query-param";name="qux":(SP) "@query-param";name="qux":(SP)
"@query-param";name="param": value "@query-param";name="param": value
]]></artwork> ]]></artwork>
<t>This derived component has some limitations. Specifically, the algo <t>This derived component has some limitations. Specifically, the algo
rithm in <xref target="HTMLURL"/> only supports query parameters using percent-e rithms provided in Section&nbsp;<xref target="HTMLURL" section="5"
scaped UTF-8 encoding. Other encodings are not supported. relative="https://url.spec.whatwg.org/#application/x-www-form-urlencoded"
sectionFormat="bare">"application/x-www-form-urlencoded"</xref> of
<xref target="HTMLURL"/> only 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 entir e query string using the <tt>@query</tt> component identifier defined in <xref t arget="content-request-query"/>.</t> 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 entir e query string using the <tt>@query</tt> component identifier defined in <xref t arget="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 s uch as using the plus character to represent spaces. For the query parameters in this message:</t> <t>The encoding process allows query parameters that include newlines or other problematic characters in their values, or with alternative encodings s uch as using the plus (+) character to represent spaces. For the query parameter s in this message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
GET /parameters?var=this%20is%20a%20big%0Amultiline%20value&\ GET /parameters?var=this%20is%20a%20big%0Amultiline%20value&\
bar=with+plus+whitespace&fa%C3%A7ade%22%3A%20=something HTTP/1.1 bar=with+plus+whitespace&fa%C3%A7ade%22%3A%20=something HTTP/1.1
Host: www.example.com Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
]]></sourcecode> ]]></sourcecode>
<t>The resulting values are encoded as follows:</t> <t>The resulting values are encoded as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
skipping to change at line 722 skipping to change at line 726
"@query-param";name="bar": with%20plus%20whitespace "@query-param";name="bar": with%20plus%20whitespace
"@query-param";name="fa%C3%A7ade%22%3A%20": something "@query-param";name="fa%C3%A7ade%22%3A%20": something
]]></artwork> ]]></artwork>
<t>If the encoding were not applied, the resultant values would be:</t > <t>If the encoding were not applied, the resultant values would be:</t >
<artwork><![CDATA[ <artwork><![CDATA[
"@query-param";name="var": this is a big "@query-param";name="var": this is a big
multiline value multiline value
"@query-param";name="bar": with plus whitespace "@query-param";name="bar": with plus whitespace
"@query-param";name="façade\": ": something "@query-param";name="façade\": ": something
]]></artwork> ]]></artwork>
<t>This base string contains characters that violate the constraints o n component names and values, and is therefore invalid.</t> <t>This base string contains characters that violate the constraints o n component names and values and is therefore invalid.</t>
</section> </section>
<section anchor="content-status-code"> <section anchor="content-status-code">
<name>Status Code</name> <name>Status Code</name>
<t>The <tt>@status</tt> derived component refers to the three-digit nu meric HTTP status code of a response message as defined in <xref section="15" se ctionFormat="comma" target="HTTP"/>. The component value is the serialized three -digit integer of the HTTP status code, with no descriptive text.</t> <t>The <tt>@status</tt> derived component refers to the three-digit nu meric HTTP status code of a response message as defined in <xref section="15" se ctionFormat="comma" target="RFC9110"/>. The component value is the serialized th ree-digit integer of the HTTP status code, with no descriptive text.</t>
<t>For example, the following response message:</t> <t>For example, the following response message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT Date: Fri, 26 Mar 2010 00:05:00 GMT
]]></sourcecode> ]]></sourcecode>
<t>Would result in the following <tt>@status</tt> component value:</t> <t>would result in the following <tt>@status</tt> component value:</t>
<artwork><![CDATA[ <artwork><![CDATA[
200 200
]]></artwork> ]]></artwork>
<t>And the following signature base line:</t> <t>and the following signature base line:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@status": 200 "@status": 200
]]></artwork> ]]></artwork>
<t>The <tt>@status</tt> component identifier <bcp14>MUST NOT</bcp14> b e used in a request message.</t> <t>The <tt>@status</tt> component identifier <bcp14>MUST NOT</bcp14> b e used in a request message.</t>
</section> </section>
</section> </section>
<section anchor="signature-params"> <section anchor="signature-params">
<name>Signature Parameters</name> <name>Signature Parameters</name>
<t>HTTP Message Signatures have metadata properties that provide informa tion regarding the signature's generation and verification, consisting of the or dered set of covered components and the ordered set of parameters including a ti mestamp of signature creation, identifiers for verification key material, and ot her utilities. This metadata is represented by a special message component in th e signature base for signature parameters, and it is treated slightly differentl y from other message components. Specifically, the signature parameters message component is <bcp14>REQUIRED</bcp14> as the last line of the <xref target="creat e-sig-input">signature base</xref>, and the component identifier <bcp14>MUST NOT </bcp14> be enumerated within the set of covered components for any signature, i ncluding itself.</t> <t>HTTP message signatures have metadata properties that provide informa tion regarding the signature's generation and verification, consisting of the or dered set of covered components and the ordered set of parameters, where the par ameters include a timestamp of signature creation, identifiers for verification key material, and other utilities. This metadata is represented by a special mes sage component in the signature base for signature parameters; this special mess age component is treated slightly differently from other message components. Spe cifically, 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 se t 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 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 ordere d set with all associated parameters. These parameters include any of the follow ing:</t> <t>The signature parameters component value is the serialization of the signature parameters for this signature, including the covered components ordere d set with all associated parameters. These parameters include any of the follow ing:</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>
<tt>created</tt>: Creation time as an Integer UNIX timestamp value. <tt>created</tt>:
Sub-second precision is not supported. Inclusion of this parameter is <bcp14>REC </dt><dd>Creation time as a UNIX timestamp value of type Integer. Sub-s
OMMENDED</bcp14>.</li> econd precision is not supported. The inclusion of this parameter is <bcp14>RECO
<li> MMENDED</bcp14>.</dd>
<tt>expires</tt>: Expiration time as an Integer UNIX timestamp value <dt>
. Sub-second precision is not supported.</li> <tt>expires</tt>:
<li> </dt><dd>Expiration time as a UNIX timestamp value of type Integer. Sub
<tt>nonce</tt>: A random unique value generated for this signature a -second precision is not supported.</dd>
s a String value.</li> <dt>
<li> <tt>nonce</tt>:
<tt>alg</tt>: The HTTP message signature algorithm from the HTTP Sig </dt><dd>A random unique value generated for this signature as a String
nature Algorithms registry, as a String value.</li> value.</dd>
<li> <dt>
<tt>keyid</tt>: The identifier for the key material as a String valu <tt>alg</tt>:
e.</li> </dt><dd>The HTTP message signature algorithm from the "HTTP Signature
<li> Algorithms" registry, as a String value.</dd>
<tt>tag</tt>: An application-specific tag for the signature as a Str <dt>
ing value. This value is used by applications to help identify signatures releva <tt>keyid</tt>:
nt for specific applications or protocols.</li> </dt><dd>The identifier for the key material as a String value.</dd>
</ul> <dt>
<t>Additional parameters can be defined in the <xref target="param-regis <tt>tag</tt>:
try">HTTP Signature Metadata Parameters Registry</xref>. Note that there is no g </dt><dd>An application-specific tag for the signature as a String valu
eneral ordering to the parameters, but once an ordering is chosen for a given se e. This value is used by applications to help identify signatures relevant for s
t of parameters, it cannot be changed without altering the signature parameters pecific applications or protocols.</dd>
value.</t> </dl>
<t>The signature parameters component value is serialized as a parameter <t>Additional parameters can be defined in the <xref target="param-regis
ized Inner List using the rules in <xref section="4" sectionFormat="of" target=" try">"HTTP Signature Metadata Parameters" registry</xref>. Note that the paramet
STRUCTURED-FIELDS"/> as follows:</t> ers 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 v
alue.</t>
<t>The signature parameters component value is serialized as a parameter
ized Inner List using the rules provided in <xref section="4" sectionFormat="of"
target="RFC8941"/> as follows:</t>
<ol spacing="normal" type="1"><li>Let the output be an empty string.</li > <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 co <li>Determine an order for the component identifiers of the covered co
mponents, not including the <tt>@signature-params</tt> component identifier itse mponents, not including the <tt>@signature-params</tt> component identifier itse
lf. Once this order is chosen, it cannot be changed. This order <bcp14>MUST</bcp lf. Once this order is chosen, it cannot be changed. This order <bcp14>MUST</bcp
14> be the same order as used in creating the signature base (<xref target="crea 14> be the same order as that used in creating the signature base
te-sig-input"/>).</li> (<xref target="create-sig-input"/>).</li>
<li>Serialize the component identifiers of the covered components, inc <li>Serialize the component identifiers of the covered components, inc
luding all parameters, as an ordered Inner List of String values according to <x luding all parameters, as an ordered Inner List of String values according to <x
ref section="4.1.1.1" sectionFormat="of" target="STRUCTURED-FIELDS"/> and append ref section="4.1.1.1" sectionFormat="of" target="RFC8941"/>; then, append this t
this to the output. Note that the component identifiers can include their own p o the output. Note that the component identifiers can include their own paramete
arameters, and these parameters are ordered sets. Once an order is chosen for a rs, and these parameters are ordered sets. Once an order is chosen for a compone
component's parameters, the order cannot be changed.</li> nt's parameters, the order cannot be changed.</li>
<li>Determine an order for any signature parameters. Once this order i s chosen, it cannot be changed.</li> <li>Determine an order for any signature parameters. Once this order i s chosen, it cannot be changed.</li>
<li>Append the parameters to the Inner List in order according to <xre f section="4.1.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>, <li>Append the parameters to the Inner List in order according to <xre f section="4.1.1.2" sectionFormat="of" target="RFC8941"/>,
skipping parameters that are not available or not used for this message signatu re.</li> skipping parameters that are not available or not used for this message signatu re.</li>
<li>The output contains the signature parameters component value.</li> <li>The output contains the signature parameters component value.</li>
</ol> </ol>
<t>Note that the Inner List serialization from <xref section="4.1.1.1" s ectionFormat="of" target="STRUCTURED-FIELDS"/> is used for the covered component value instead of the List serialization from <xref section="4.1.1" sectionForma t="of" target="STRUCTURED-FIELDS"/> <t>Note that the Inner List serialization from <xref section="4.1.1.1" s ectionFormat="of" target="RFC8941"/> is used for the covered component value ins tead of the List serialization from <xref section="4.1.1" sectionFormat="of" tar get="RFC8941"/>
in order to facilitate parallelism with this value's inclusion in the Signature- Input field, in order to facilitate parallelism with this value's inclusion in the Signature- Input field,
as discussed in <xref target="signature-input-header"/>.</t> 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> <t>This example shows the serialized component value for the parameters of an example message signature:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
("@target-uri" "@authority" "date" "cache-control")\ ("@target-uri" "@authority" "date" "cache-control")\
;keyid="test-key-rsa-pss";alg="rsa-pss-sha512";\ ;keyid="test-key-rsa-pss";alg="rsa-pss-sha512";\
created=1618884475;expires=1618884775 created=1618884475;expires=1618884775
]]></artwork> ]]></artwork>
<t>Note that an HTTP message could contain <xref target="signature-multi ple">multiple signatures</xref>, but only the signature parameters used for a si ngle signature are included in a given signature parameters entry.</t> <t>Note that an HTTP message could contain <xref target="signature-multi ple">multiple signatures</xref>, but only the signature parameters used for a si ngle signature are included in a given signature parameters entry.</t>
</section> </section>
<section anchor="content-request-response"> <section anchor="content-request-response">
<name>Signing Request Components in a Response Message</name> <name>Signing Request Components in a Response Message</name>
<t>When a request message results in a signed response message, the sign er can include portions of the request message in the signature base by adding t he <tt>req</tt> parameter to the component identifier.</t> <t>When a request message results in a signed response message, the sign er can include portions of the request message in the signature base by adding t he <tt>req</tt> parameter to the component identifier.</t>
<dl> <dl>
<dt><tt>req</tt></dt> <dt><tt>req</tt></dt>
<dd> <dd>
<t>A boolean flag indicating that the component value is derived fro m the request that triggered this response message and not from the response mes sage directly.</t> <t>A Boolean flag indicating that the component value is derived fro m the request that triggered this response message and not from the response mes sage directly.</t>
</dd> </dd>
</dl> </dl>
<t>This parameter can be applied to both HTTP fields and derived compone nts 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 res ponse message to which the signature is applied.</t> <t>This parameter can be applied to both HTTP fields and derived compone nts 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 res ponse message to which the signature is applied.</t>
<t>Note that the same component name <bcp14>MAY</bcp14> be included with <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 t and without the <tt>req</tt> parameter in a single signature base, indicating t
he same named component from both the request and response message, respectively he same named component from both the request message and the response message.<
.</t> /t>
<t>The <tt>req</tt> parameter <bcp14>MAY</bcp14> be combined with other <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> parameters as appropriate for the component identifier, such as the <tt>key</tt>
parameter for a dictionary field.</t> parameter for a Dictionary field.</t>
<t>For example, when serving a response for this request:</t> <t>For example, when serving a response for this request:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json Content-Type: application/json
skipping to change at line 824 skipping to change at line 835
HTTP/1.1 503 Service Unavailable HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 62 Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\ Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
{"busy": true, "message": "Your call is very important to us"} {"busy": true, "message": "Your call is very important to us"}
]]></sourcecode> ]]></sourcecode>
<t>The server signs the response with its own key, including the <tt>@st atus</tt> code and several header fields in the covered components. While this c overs a reasonable amount of the response for this application, the server addit ionally includes several components derived from the original request message th at triggered this response. In this example, the server includes the method, aut hority, path, and content digest from the request in the covered components of t he response. The Content-Digest for both the request and the response are includ ed 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 as discu ssed in <xref target="application"/>.</t> <t>The server signs the response with its own key, including the <tt>@st atus</tt> code and several header fields in the covered components. While this c overs a reasonable amount of the response for this application, the server addit ionally includes several components derived from the original request message th at triggered this response. In this example, the server includes the method, aut hority, path, and content digest from the request in the covered components of t he response. The Content-Digest for both the request and the response is include d under the response signature. For the application in this example, the query i s deemed not to be relevant to the response and is therefore not covered. Other applications would make different decisions based on application needs, as discu ssed in <xref target="application"/>.</t>
<t>The signature base for this example is:</t> <t>The signature base for this example is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@status": 503 "@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\ "content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json "content-type": application/json
"@authority";req: example.com "@authority";req: example.com
"@method";req: POST "@method";req: POST
skipping to change at line 860 skipping to change at line 871
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\ Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \ Signature-Input: reqres=("@status" "content-digest" "content-type" \
"@authority";req "@method";req "@path";req "content-digest";req)\ "@authority";req "@method";req "@path";req "content-digest";req)\
;created=1618884479;keyid="test-key-ecc-p256" ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU\ Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU\
4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==: 4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==:
{"busy": true, "message": "Your call is very important to us"} {"busy": true, "message": "Your call is very important to us"}
]]></sourcecode> ]]></sourcecode>
<t>Note that the ECDSA algorithm in use here is non-deterministic, meani <t>Note that the ECDSA signature algorithm in use here is non-determinis
ng a different signature value will be created every time the algorithm is run. tic, meaning that a different signature value will be created every time the alg
The signature value provided here can be validated against the given keys, but n orithm is run. The signature value provided here can be validated against the gi
ewly-generated signature values are not expected to match the example. See <xref ven keys, but newly generated signature values are not expected to match the exa
target="security-nondeterministic"/>.</t> mple. See <xref target="security-nondeterministic"/>.</t>
<t>Since the component values from the request are not repeated in the r <t>Since the component values from the request are not repeated in the r
esponse message, the requester <bcp14>MUST</bcp14> keep the original message com esponse message, the requester <bcp14>MUST</bcp14> keep the original message com
ponent values around long enough to validate the signature of the response that ponent values around long enough to validate the signature of the response that
uses this component identifier parameter. In most cases, this means the requeste uses this component identifier parameter. In most cases, this means the requeste
r needs to keep the original request message around, since the signer could choo r needs to keep the original request message around, since the signer could choo
se to include any portions of the request in its response, according to the need se to include any portions of the request in its response, according to the need
s of the application. Since it is possible for an intermediary to alter a reques s of the application. Since it is possible for an intermediary to alter a reques
t message before it is processed by the server, applications need to take care n t message before it is processed by the server, applications need to take care n
ot to sign such altered values as the client would not be able to validate the r ot to sign such altered values, as the client would not be able to validate the
esulting signature.</t> resulting signature.</t>
<t>It is additionally possible for a server to create a signed response <t>It is also possible for a server to create a signed response in respo
in response to a signed request. For example, this signed request:</t> nse to a signed request. For this example of a signed request:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
skipping to change at line 885 skipping to change at line 896
;created=1618884475;keyid="test-key-rsa-pss" ;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK\ Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK\
t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr\ t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr\
d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4\ d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4\
2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw\ 2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw\
5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr\ 5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr\
0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==: 0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==:
{"hello": "world"} {"hello": "world"}
]]></artwork> ]]></artwork>
<t>The server could choose to sign portions of this response, including several portions of the request resulting in this signature base:</t> <t>The server could choose to sign portions of this response, including several portions of the request, resulting in this signature base:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@status": 503 "@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\ "content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json "content-type": application/json
"@authority";req: example.com "@authority";req: example.com
"@method";req: POST "@method";req: POST
"@path";req: /foo "@path";req: /foo
"@query";req: ?param=Value&Pet=dog "@query";req: ?param=Value&Pet=dog
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\ "content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: 2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type";req: application/json "content-type";req: application/json
"content-length";req: 18 "content-length";req: 18
"@signature-params": ("@status" "content-digest" "content-type" \ "@signature-params": ("@status" "content-digest" "content-type" \
"@authority";req "@method";req "@path";req "@query";req \ "@authority";req "@method";req "@path";req "@query";req \
"content-digest";req "content-type";req "content-length";req)\ "content-digest";req "content-type";req "content-length";req)\
;created=1618884479;keyid="test-key-ecc-p256" ;created=1618884479;keyid="test-key-ecc-p256"
]]></artwork> ]]></artwork>
<t>And the following signed response:</t> <t>and the following signed response:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 503 Service Unavailable HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 62 Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\ Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \ Signature-Input: reqres=("@status" "content-digest" "content-type" \
"@authority";req "@method";req "@path";req "@query";req \ "@authority";req "@method";req "@path";req "@query";req \
"content-digest";req "content-type";req "content-length";req)\ "content-digest";req "content-type";req "content-length";req)\
;created=1618884479;keyid="test-key-ecc-p256" ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym\ Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym\
dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==: dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==:
{"busy": true, "message": "Your call is very important to us"} {"busy": true, "message": "Your call is very important to us"}
]]></sourcecode> ]]></sourcecode>
<t>Note that the ECDSA algorithm in use here is non-deterministic, meani <t>Note that the ECDSA signature algorithm in use here is non-determinis
ng a different signature value will be created every time the algorithm is run. tic, meaning that a different signature value will be created every time the alg
The signature value provided here can be validated against the given keys, but n orithm is run. The signature value provided here can be validated against the gi
ewly-generated signature values are not expected to match the example. See <xref ven keys, but newly generated signature values are not expected to match the exa
target="security-nondeterministic"/>.</t> mple. See <xref target="security-nondeterministic"/>.</t>
<t>Applications signing a response to a signed request <bcp14>SHOULD</bc <t>Applications signing a response to a signed request <bcp14>SHOULD</bc
p14> sign all of the components of the request signature value to provide suffic p14> sign all of the components of the request signature value to provide suffic
ient coverage and protection against a class of collision attacks, as discussed ient coverage and protection against a class of collision attacks, as discussed
in <xref target="security-sign-signature"/>. The server in this example has incl in <xref target="security-sign-signature"/>. The server in this example has incl
uded all components listed in the Signature-Input of the client's signature on t uded all components listed in the Signature-Input field of the client's signatur
he request in the response signature, in addition to components of the response. e on the request in the response signature, in addition to components of the res
</t> ponse.</t>
<t>While it is syntactically possible to include the Signature and Signa <t>While it is syntactically possible to include the Signature and Signa
ture-Input fields of the request message in the signature components of a respon ture-Input fields of the request message in the signature components of a respon
se a message using this mechanism, this practice is <bcp14>NOT RECOMMENDED</bcp1 se to a message using this mechanism, this practice is <bcp14>NOT RECOMMENDED</b
4>. This is because signatures of signatures do not provide transitive coverage cp14>. This is because signatures of signatures do not provide transitive covera
of covered components as one might expect and the practice is susceptible to sev ge of covered components as one might expect, and the practice is susceptible to
eral attacks as discussed in <xref target="security-sign-signature"/>. An applic several attacks as discussed in <xref target="security-sign-signature"/>. An ap
ation that needs to signal successful processing or receipt of a signature would plication that needs to signal successful processing or receipt of a signature w
need to carefully specify alternative mechanisms for sending such a signal secu ould need to carefully specify alternative mechanisms for sending such a signal
rely.</t> securely.</t>
<t>The response signature can only ever cover what is included in the re quest message when using this flag. Consequently, if an application needs to inc lude 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-Di gest field. See the discussion in <xref target="security-message-content"/> for more information.</t> <t>The response signature can only ever cover what is included in the re quest message when using this flag. Consequently, if an application needs to inc lude 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-Di gest 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 co mponent in a signature that targets a request message.</t> <t>The <tt>req</tt> parameter <bcp14>MUST NOT</bcp14> be used for any co mponent in a signature that targets a request message.</t>
</section> </section>
<section anchor="create-sig-input"> <section anchor="create-sig-input">
<name>Creating the Signature Base</name> <name>Creating the Signature Base</name>
<t>The signature base is a <xref target="ASCII"/> string containing the <t>The signature base is an ASCII string <xref target="RFC0020"/> contai
canonicalized HTTP message components covered by the signature. The input to the ning the canonicalized HTTP message components covered by the signature. The inp
signature base creation algorithm is the ordered set of covered component ident ut to the signature base creation algorithm is the ordered set of covered compon
ifiers and their associated values, along with any additional signature paramete ent identifiers and their associated values, along with any additional signature
rs discussed in <xref target="signature-params"/>.</t> parameters discussed in <xref target="signature-params"/>.</t>
<t>Component identifiers are serialized using the strict serialization r <t>Component identifiers are serialized using the strict serialization r
ules defined by <xref section="4" sectionFormat="comma" target="STRUCTURED-FIELD ules defined by <xref section="4" sectionFormat="comma" target="RFC8941"/>.
S"/>. The component identifier has a component name, which is a String Item value seri
The component identifier has a component name, which is a String Item value seri alized using the <tt>sf-string</tt> ABNF rule. The component identifier <bcp14>M
alized using the <tt>sf-string</tt> ABNF rule. The component identifier <bcp14>M AY</bcp14> also include defined parameters that are serialized using the <tt>par
AY</bcp14> also include defined parameters which are serialized using the <tt>pa ameters</tt> ABNF rule. The signature parameters line defined in <xref target="s
rameters</tt> ABNF rule. The signature parameters line defined in <xref target=" ignature-params"/> follows this same pattern, but the component identifier is a
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 alw
String Item with a fixed value and no parameters, and the component value is al ays an Inner List with optional parameters.</t>
ways an Inner List with optional parameters.</t>
<t>Note that this means the serialization of the component name itself i s encased in double quotes, with parameters following as a semicolon-separated l ist, such as <tt>"cache-control"</tt>, <tt>"@authority"</tt>, <tt>"@signature-pa rams"</tt>, or <tt>"example-dictionary";key="foo"</tt>.</t> <t>Note that this means the serialization of the component name itself i s encased in double quotes, with parameters following as a semicolon-separated l ist, such as <tt>"cache-control"</tt>, <tt>"@authority"</tt>, <tt>"@signature-pa rams"</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> <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[ <sourcecode type="abnf"><![CDATA[
signature-base = *( signature-base-line LF ) signature-params-line signature-base = *( signature-base-line LF ) signature-params-line
signature-base-line = component-identifier ":" SP signature-base-line = component-identifier ":" SP
( derived-component-value / *field-content ) ( derived-component-value / *field-content )
; no obs-fold nor obs-text ; no obs-fold nor obs-text
component-identifier = component-name parameters component-identifier = component-name parameters
component-name = sf-string component-name = sf-string
derived-component-value = *( VCHAR / SP ) derived-component-value = *( VCHAR / SP )
signature-params-line = DQUOTE "@signature-params" DQUOTE signature-params-line = DQUOTE "@signature-params" DQUOTE
":" SP inner-list ":" SP inner-list
]]></sourcecode> ]]></sourcecode>
<t>To create the signature base, the signer or verifier concatenates tog ether entries for each component identifier in the signature's covered component s (including their parameters) using the following algorithm. All errors produce d as described immediately <bcp14>MUST</bcp14> fail the algorithm with no signat ure output base output.</t> <t>To create the signature base, the signer or verifier concatenates ent ries for each component identifier in the signature's covered components (includ ing their parameters) using the following algorithm. All errors produced as desc ribed <bcp14>MUST</bcp14> fail the algorithm immediately, without outputting a s ignature base.</t>
<ol spacing="normal" type="1"><li>Let the output be an empty string.</li > <ol spacing="normal" type="1"><li>Let the output be an empty string.</li >
<li> <li>
<t>For each message component item in the covered components set (in order): </t> <t>For each message component item in the covered components set (in order): </t>
<ol spacing="normal" type="1"><li>If the component identifier (inclu ding its parameters) has already been added to the signature base, produce an er ror.</li> <ol spacing="normal" type="%p%d."><li>If the component identifier (i ncluding its parameters) has already been added to the signature base, produce a n error.</li>
<li>Append the component identifier for the covered component seri alized according to the <tt>component-identifier</tt> ABNF rule. Note that this serialization places the component name in double quotes and appends any paramet ers outside of the quotes.</li> <li>Append the component identifier for the covered component seri alized according to the <tt>component-identifier</tt> ABNF rule. Note that this serialization places the component name in double quotes and appends any paramet ers outside of the quotes.</li>
<li>Append a single colon <tt>:</tt></li> <li>Append a single colon (<tt>:</tt>).</li>
<li>Append a single space " "</li> <li>Append a single space (" ").</li>
<li> <li>
<t>Determine the component value for the component identifier. </t> <t>Determine the component value for the component identifier. </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the component identifier has a parameter that is not un derstood, produce an error.</li> <li>If the component identifier has a parameter that is not un derstood, produce an error.</li>
<li>If the component identifier has parameters that are mutual ly incompatible with one another, such as <tt>bs</tt> and <tt>sf</tt>, produce a n error.</li> <li>If the component identifier has parameters that are mutual ly incompatible with one another, such as <tt>bs</tt> and <tt>sf</tt>, produce a n error.</li>
<li>If the component identifier contains the <tt>req</tt> para meter and the target message is a request, produce an error.</li> <li>If the component identifier contains the <tt>req</tt> para meter and the target message is a request, produce an error.</li>
<li>If the component identifier contains the <tt>req</tt> para meter 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 co ntext for the component value is the target message.</li> <li>If the component identifier contains the <tt>req</tt> para meter 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 co ntext for the component value is the target message.</li>
<li>If the component name starts with an "at" character (<tt>@ <li>If the component name starts with an "at" (<tt>@</tt>) cha
</tt>), derive the component's value from the message according to the specific racter, derive the component's value from the message according to the specific
rules defined for the derived component, as in <xref target="derived-components" rules defined for the derived component, as provided in <xref target="derived-co
/>, including processing of any known valid parameters. If the derived component mponents"/>, including processing of any known valid parameters. If the derived
name is unknown or the value cannot be derived, produce an error.</li> 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" characte <li>If the component name does not start with an "at" (<tt>@</
r (<tt>@</tt>), canonicalize the HTTP field value as described in <xref target=" tt>) character, canonicalize the HTTP field value as described in <xref target="
http-fields"/>, including processing of any known valid parameters. If the field http-fields"/>, including processing of any known valid parameters. If the field
cannot be found in the message, or the value cannot be obtained in the context, cannot be found in the message or the value cannot be obtained in the context,
produce an error.</li> produce an error.</li>
</ul> </ul>
</li> </li>
<li>Append the covered component's canonicalized component value.< /li> <li>Append the covered component's canonicalized component value.< /li>
<li>Append a single newline <tt>\n</tt></li> <li>Append a single newline (<tt>\n</tt>).</li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Append the signature parameters component (<xref target="signatur e-params"/>) according to the <tt>signature-params-line</tt> rule as follows: < /t> <t>Append the signature parameters component (<xref target="signatur e-params"/>) according to the <tt>signature-params-line</tt> rule as follows: < /t>
<ol spacing="normal" type="1"><li>Append the component identifier fo <ol spacing="normal" type="%p%d."><li>Append the component identifie
r the signature parameters serialized according to the <tt>component-identifier< r for the signature parameters serialized according to the <tt>component-identif
/tt> rule, i.e. the exact value <tt>"@signature-params"</tt> (including double q ier</tt> rule, i.e., the exact value <tt>"@signature-params"</tt> (including dou
uotes)</li> ble quotes).</li>
<li>Append a single colon <tt>:</tt></li> <li>Append a single colon (<tt>:</tt>).</li>
<li>Append a single space " "</li> <li>Append a single space (" ").</li>
<li>Append the signature parameters' canonicalized component value <li>Append the signature parameters' canonicalized component value
as defined in <xref target="signature-params"/>, i.e. an Inner List structured s as defined in <xref target="signature-params"/>, i.e., Inner List Structured F
field value with parameters</li> ield values with parameters.</li>
</ol> </ol>
</li> </li>
<li>Produce an error if the output string contains any non-ASCII (<xre f target="ASCII"/>) characters.</li> <li>Produce an error if the output string contains any non-ASCII chara cters <xref target="RFC0020"/>.</li>
<li>Return the output string.</li> <li>Return the output string.</li>
</ol> </ol>
<t>If covered components reference a component identifier that cannot be resolved to a component value in the message, the implementation <bcp14>MUST</b cp14> produce an error and not create a signature base. Such situations include, but are not limited to:</t> <t>If covered components reference a component identifier that cannot be resolved to a component value in the message, the implementation <bcp14>MUST</b cp14> produce an error and not create a signature base. Such situations include, but are not limited to, the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The signer or verifier does not understand the derived component n ame.</li> <li>The signer or verifier does not understand the derived component n ame.</li>
<li>The component name identifies a field that is not present in the m essage or whose value is malformed.</li> <li>The component name identifies a field that is not present in the m essage or whose value is malformed.</li>
<li>The component identifier includes a parameter that is unknown or d oes not apply to the component identifier to which it is attached.</li> <li>The component identifier includes a parameter that is unknown or d oes not apply to the component identifier to which it is attached.</li>
<li>The component identifier indicates that a structured field seriali <li>The component identifier indicates that a Structured Field seriali
zation is used (via the <tt>sf</tt> parameter), but the field in question is kno zation is used (via the <tt>sf</tt> parameter), but the field in question is kno
wn to not be a structured field or the type of structured field is not known to wn to not be a Structured Field or the type of Structured Field is not known to
the implementation.</li> the implementation.</li>
<li>The component identifier is a dictionary member identifier that re <li>The component identifier is a Dictionary member identifier that re
ferences a field that is not present in the message, is not a Dictionary Structu ferences a field that is not present in the message, that is not a Dictionary St
red Field, or whose value is malformed.</li> ructured Field, or whose value is malformed.</li>
<li>The component identifier is a dictionary member identifier or a na <li>The component identifier is a Dictionary member identifier or a na
med query parameter identifier that references a member that is not present in t med query parameter identifier that references a member that is not present in t
he component value, or whose value is malformed. E.g., the identifier is <tt>"ex he component value or whose value is malformed. For example, the identifier is <
ample-dict";key="c"</tt> and the value of the Example-Dict header field is <tt>a tt>"example-dict";key="c"</tt>, and the value of the Example-Dict header field i
=1, b=2</tt>, which does not have the <tt>c</tt> value.</li> s <tt>a=1, b=2</tt>, which does not have the <tt>c</tt> value.</li>
</ul> </ul>
<t>In the following non-normative example, the HTTP message being signed is the following request:</t> <t>In the following non-normative example, the HTTP message being signed is the following request:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18 Content-Length: 18
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>The covered components consist of the <tt>@method</tt>, <tt>@authorit y</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>16188844 73</tt> and a key identifier of <tt>test-key-rsa-pss</tt>. Note that no explicit <tt>alg</tt> parameter is given here since the verifier is known by the applica tion to use the RSA PSS algorithm based on the identified key. The signature bas e for this message with these parameters is:</t> <t>The covered components consist of the <tt>@method</tt>, <tt>@authorit y</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>16188844 73</tt> and a key identifier of <tt>test-key-rsa-pss</tt>. Note that no explicit <tt>alg</tt> parameter is given here, since the verifier is known by the applic ation to use the RSA-PSS algorithm based on the identified key. The signature ba se for this message with these parameters is:</t>
<figure anchor="example-sig-input"> <figure anchor="example-sig-input">
<name>Non-normative example Signature Base</name> <name>Non-normative Example Signature Base</name>
<sourcecode type="http-message" name="example-sig-input"><![CDATA[ <sourcecode type="http-message" name="example-sig-input"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@method": POST "@method": POST
"@authority": example.com "@authority": example.com
"@path": /foo "@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\ "content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-length": 18 "content-length": 18
"content-type": application/json "content-type": application/json
"@signature-params": ("@method" "@authority" "@path" \ "@signature-params": ("@method" "@authority" "@path" \
"content-digest" "content-length" "content-type")\ "content-digest" "content-length" "content-type")\
;created=1618884473;keyid="test-key-rsa-pss" ;created=1618884473;keyid="test-key-rsa-pss"
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Note that the example signature base here, or anywhere else within th is specification, does not include the final newline that ends the displayed exa mple.</t> <t>Note that the example signature base above does not include the final newline that ends the displayed example, nor do other example signature bases d isplayed elsewhere in this specification.</t>
</section> </section>
</section> </section>
<section anchor="message-signatures"> <section anchor="message-signatures">
<name>HTTP Message Signatures</name> <name>HTTP Message Signatures</name>
<t>An HTTP 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 s ignature itself. When successfully verified against an HTTP message, an HTTP Mes sage Signature provides cryptographic proof that the message is semantically equ ivalent to the message for which the signature was generated, with respect to th e subset of message components that was signed.</t> <t>An HTTP 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 s ignature itself. When successfully verified against an HTTP message, an HTTP mes sage signature provides cryptographic proof that the message is semantically equ ivalent to the message for which the signature was generated, with respect to th e subset of message components that was signed.</t>
<section anchor="sign"> <section anchor="sign">
<name>Creating a Signature</name> <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 parame ters that can be communicated to the verifier by adding them to the message.</t> <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 parame ters 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 t he following algorithm:</t> <t>In order to create a signature, a signer <bcp14>MUST</bcp14> apply th e following algorithm:</t>
<ol spacing="normal" type="1"><li>The signer chooses an HTTP signature a lgorithm and key material for signing from the set of potential signing algorith ms. <ol spacing="normal" type="1"><li>The signer chooses an HTTP signature a lgorithm and key material for signing from the set of potential signing algorith ms.
The set of potential algorithms is determined by the application and is out of scope for this document. 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 The signer <bcp14>MUST</bcp14> choose key material that is appropriate
for the signature's algorithm, and that conforms to any requirements defined by the algorithm, such as key size or format. The for the signature's 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> 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>The signer sets the signature's creation time to the current time. </li>
<li>If applicable, the signer sets the signature's expiration time pro perty 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 r equirements of this parameter, are application-specific.</li> <li>If applicable, the signer sets the signature's expiration time pro perty 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 r equirements of this parameter, are application specific.</li>
<li> <li>
<t>The signer creates an ordered set of component identifiers repres <t>The signer creates an ordered set of component identifiers repres
enting the message components to be covered by the signature, and attaches signa enting the message components to be covered by the signature and attaches signat
ture metadata parameters to this set. The serialized value of this is later used ure metadata parameters to this set. The serialized value of this set is later u
as the value of the Signature-Input field as described in <xref target="signatu sed as the value of the Signature-Input field as described in <xref target="sign
re-input-header"/>. ature-input-header"/>.</t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Once an order of covered components is chosen, the order <bcp1 4>MUST NOT</bcp14> change for the life of the signature.</li> <li>Once an order of covered components is chosen, the order <bcp1 4>MUST NOT</bcp14> change for the life of the signature.</li>
<li>Each covered component identifier <bcp14>MUST</bcp14> be eithe <li>Each covered component identifier <bcp14>MUST</bcp14> be eithe
r an HTTP field in the signature context <xref target="http-fields"/> or a deriv r
ed component listed in <xref target="derived-components"/> or the HTTP Signature (1)&nbsp;an HTTP field (<xref target="http-fields"/>) in the signature context o
Derived Component Names registry.</li> r
(2)&nbsp;a derived component listed in <xref target="derived-components"/> or in
the "HTTP Signature Derived Component 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.</l i> <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.</l i>
<li>Signers <bcp14>SHOULD</bcp14> include the <tt>created</tt> sig nature metadata parameter to indicate when the signature was created.</li> <li>Signers <bcp14>SHOULD</bcp14> include the <tt>created</tt> sig nature metadata parameter to indicate when the signature was created.</li>
<li>The <tt>@signature-params</tt> derived component identifier <b cp14>MUST NOT</bcp14> be listed in the list of covered component identifiers. Th e 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 cann ot be substituted.</li> <li>The <tt>@signature-params</tt> derived component identifier <b cp14>MUST NOT</bcp14> be present in the list of covered component identifiers. T he derived component is required to always be the last line in the signature bas e, ensuring that a signature always covers its own metadata and the metadata can not be substituted.</li>
<li>Further guidance on what to include in this set and in what or der is out of scope for this document.</li> <li>Further guidance on what to include in this set and in what or der is out of scope for this document.</li>
</ul> </ul>
</li> </li>
<li>The signer creates the signature base using these parameters and t he signature base creation algorithm. (<xref target="create-sig-input"/>)</li> <li>The signer creates the signature base using these parameters and t he signature base creation algorithm (<xref 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 chos en by the signer. The <tt>HTTP_SIGN</tt> primitive and several concrete applicat ions of signing algorithms are defined in <xref target="signature-methods"/>.</l i> <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 chos en by the signer. The <tt>HTTP_SIGN</tt> primitive and several concrete applicat ions of signing algorithms are defined in <xref target="signature-methods"/>.</l i>
<li>The byte array output of the signature function is the HTTP messag e signature output value to be included in the Signature field as defined in <xr ef target="signature-header"/>.</li> <li>The byte array output of the signature function is the HTTP messag e signature output value to be included in the Signature field as defined in <xr ef target="signature-header"/>.</li>
</ol> </ol>
<t>For example, given the HTTP message and signature parameters in the e xample in <xref target="create-sig-input"/>, the example signature base is signe d with the <tt>test-key-rsa-pss</tt> key in <xref target="example-key-rsa-pss-te st"/> and the RSA PSS algorithm described in <xref target="method-rsa-pss-sha512 "/>, giving the following message signature output value, encoded in Base64:</t> <t>For example, given the HTTP message and signature parameters in the e xample in <xref target="create-sig-input"/>, the example signature base is signe d with the <tt>test-key-rsa-pss</tt> key (see <xref target="example-key-rsa-pss- test"/>) and the RSASSA-PSS algorithm described in <xref target="method-rsa-pss- sha512"/>, giving the following message signature output value, encoded in Base6 4:</t>
<figure anchor="example-sig-value"> <figure anchor="example-sig-value">
<name>Non-normative example signature value</name> <name>Non-normative Example Signature Value</name>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrlFrCGUDih47vAxi4L2\ HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrlFrCGUDih47vAxi4L2\
YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxHLMCy8uqK488o+9jrptQ\ YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxHLMCy8uqK488o+9jrptQ\
+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSfSvzPuBCh+ARHBmWuNo1Uz\ +xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSfSvzPuBCh+ARHBmWuNo1Uz\
VVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y9TP5FsZYzHvDqbInkTNigBc\ VVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y9TP5FsZYzHvDqbInkTNigBc\
E9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7aXq6Am6sfOrpIC49yXjj3ae6H\ E9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7aXq6Am6sfOrpIC49yXjj3ae6H\
RalVc/g== RalVc/g==
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Note that the RSA PSS algorithm in use here is non-deterministic, mea ning a different signature value will be created every time the algorithm is run . The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example. See <xr ef target="security-nondeterministic"/>.</t> <t>Note that the RSA-PSS algorithm in use here is non-deterministic, mea ning that a different signature value will be created every time the algorithm i s run. The signature value provided here can be validated against the given keys , but newly generated signature values are not expected to match the example. Se e <xref target="security-nondeterministic"/>.</t>
</section> </section>
<section anchor="verify"> <section anchor="verify">
<name>Verifying a Signature</name> <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>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 the following algorithm:</t> <t>In order to verify a signature, a verifier <bcp14>MUST</bcp14> apply the following algorithm:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Parse the Signature and Signature-Input fields as described in <x <t>Parse the Signature and Signature-Input fields as described in
ref target="signature-input-header"/> and <xref target="signature-header"/>, and Sections&nbsp;<xref target="signature-input-header" format="counter"/> and <xref
extract the signatures to be verified. target="signature-header" format="counter"/>, and extract the signatures to be
verified and their labels.
</t> </t>
<ol spacing="normal" type="1"><li>If there is more than one signatur e value present, determine which signature should be processed <ol spacing="normal" type="%p%d."><li>If there is more than one sign ature value present, determine which signature should be processed
for this message based on the policy and configuration of the verifier. If an a pplicable signature is not found, produce an error.</li> for this message based on the policy and configuration of the verifier. If an a pplicable signature is not found, produce an error.</li>
<li>If the chosen Signature value does not have a corresponding Si gnature-Input value, <li>If the chosen Signature field value does not have a correspond ing Signature-Input field value (i.e., one with the same label),
produce an error.</li> produce an error.</li>
</ol> </ol>
</li> </li>
<li>Parse the values of the chosen Signature-Input field as a paramete rized Inner List to get the ordered list of covered components and the signature parameters for the signature to be verified.</li> <li>Parse the values of the chosen Signature-Input field as a paramete rized 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 by te array value of the signature <li>Parse the value of the corresponding Signature field to get the by te array value of the signature
to be verified.</li> to be verified.</li>
<li>Examine the signature parameters to confirm that the signature mee ts the requirements described <li>Examine the signature parameters to confirm that the signature mee ts the requirements described
in this document, as well as any additional requirements defined by the applica tion such as which in this document, as well as any additional requirements defined by the applica tion such as which
message components are required to be covered by the signature. (<xref target=" verify-requirements"/>)</li> message components are required to be covered by the signature (<xref target="v erify-requirements"/>).</li>
<li>Determine the verification key material for this signature. If the key material is known through external <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 verifi means such as static configuration or external protocol negotiation, the verifi
er will use that. If the key is er will use the applicable technique to obtain the key material from this extern
identified in the signature parameters, the verifier will dereference this to a al knowledge. If the key is
ppropriate key material to use identified in the signature parameters, the verifier will dereference the key i
dentifier to appropriate key material to use
with the signature. The verifier has to determine the trustworthiness of the ke y material for the context with the signature. The verifier has to determine the trustworthiness of the ke y material for the context
in which the signature is presented. If a key is identified that the verifier d in which the signature is presented. If a key is identified that the verifier d
oes not know, does oes not know or trust for this request or that does not match something preconfi
not trust for this request, or does not match something preconfigured, the veri gured, the verification <bcp14>MUST</bcp14> fail.</li>
fication <bcp14>MUST</bcp14> fail.</li>
<li> <li>
<t>Determine the algorithm to apply for verification: <t>Determine the algorithm to apply for verification:
</t> </t>
<ol spacing="normal" type="1"><li>Start with the set of allowable al gorithms known to the application. If any of the following steps selects an algo rithm that is not in this set, the signature validation fails.</li> <ol spacing="normal" type="%p%d."><li>Start with the set of allowabl e algorithms known to the application. If any of the following steps select an a lgorithm that is not in this set, the signature validation fails.</li>
<li>If the algorithm is known through external means such as stati c configuration or external protocol <li>If the algorithm is known through external means such as stati c configuration or external protocol
negotiation, the verifier will use this algorithm.</li> negotiation, the verifier will use that algorithm.</li>
<li>If the algorithm can be determined from the keying material, s uch as through an algorithm field <li>If the algorithm can be determined from the keying material, s uch as through an algorithm field
on the key value itself, the verifier will use this algorithm.</li> on the key value itself, the verifier will use that algorithm.</li>
<li>If the algorithm is explicitly stated in the signature paramet ers using a value from the <li>If the algorithm is explicitly stated in the signature paramet ers using a value from the
HTTP Signature Algorithms registry, the verifier will use the referenced algori "HTTP Signature Algorithms" registry, the verifier will use the referenced algo
thm.</li> rithm.</li>
<li>If the algorithm is specified in more than one location, such <li>If the algorithm is specified in more than one location (e.g.,
as through static configuration a combination of static configuration, the algorithm signature parameter, and th
and the algorithm signature parameter, or the algorithm signature parameter and e
from key material itself), the resolved algorithms <bcp14>MUST</bcp14> be the same. I
the key material itself, the resolved algorithms <bcp14>MUST</bcp14> be the sam f the algorithms are
e. If the algorithms are
not the same, the verifier <bcp14>MUST</bcp14> fail the verification.</li> not the same, the verifier <bcp14>MUST</bcp14> fail the verification.</li>
</ol> </ol>
</li> </li>
<li>Use the received HTTP message and the parsed signature parameters to re-create the signature base, using <li>Use the received HTTP message and the parsed signature parameters to recreate the signature base, using
the algorithm defined in <xref target="create-sig-input"/>. The value of the <t t>@signature-params</tt> input is the algorithm defined in <xref target="create-sig-input"/>. The value of the <t t>@signature-params</tt> input is
the value of the Signature-Input field for this signature serialized according to the rules described 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 signa ture's label from the Signature-Input field.</li> in <xref target="signature-params"/>. Note that this does not include the signa ture's label from the Signature-Input field.</li>
<li>If the key material is appropriate for the algorithm, apply the ap propriate <tt>HTTP_VERIFY</tt> cryptographic verification algorithm to the signa ture, <li>If the key material is appropriate for the algorithm, apply the ap propriate <tt>HTTP_VERIFY</tt> cryptographic verification algorithm to the signa ture,
recalculated signature base, key material, signature value. The <tt>HTTP_VERIFY </tt> primitive and several concrete algorithms are defined in recalculated signature base, key material, and signature value. The <tt>HTTP_VE RIFY</tt> primitive and several concrete algorithms are defined in
<xref target="signature-methods"/>.</li> <xref target="signature-methods"/>.</li>
<li>The results of the verification algorithm function are the final r esults of the cryptographic verification function.</li> <li>The results of the verification algorithm function are the final r esults of the cryptographic verification function.</li>
</ol> </ol>
<t>If any of the above steps fail or produce an error, the signature val idation fails.</t> <t>If any of the above steps fail or produce an error, the signature val idation fails.</t>
<t>For example, verifying the signature with the key <tt>sig1</tt> of th e following message with the <tt>test-key-rsa-pss</tt> key in <xref target="exam ple-key-rsa-pss-test"/> and the RSA PSS algorithm described in <xref target="met hod-rsa-pss-sha512"/>:</t> <t>For example, verifying the signature with the label <tt>sig1</tt> of the following message with the <tt>test-key-rsa-pss</tt> key (see <xref target=" example-key-rsa-pss-test"/>) and the RSASSA-PSS algorithm described in <xref tar get="method-rsa-pss-sha512"/>:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18 Content-Length: 18
skipping to change at line 1147 skipping to change at line 1159
;created=1618884473;keyid="test-key-rsa-pss" ;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig1=:HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrl\ Signature: sig1=:HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrl\
FrCGUDih47vAxi4L2YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxH\ FrCGUDih47vAxi4L2YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxH\
LMCy8uqK488o+9jrptQ+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSf\ LMCy8uqK488o+9jrptQ+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSf\
SvzPuBCh+ARHBmWuNo1UzVVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y\ SvzPuBCh+ARHBmWuNo1UzVVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y\
9TP5FsZYzHvDqbInkTNigBcE9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7\ 9TP5FsZYzHvDqbInkTNigBcE9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7\
aXq6Am6sfOrpIC49yXjj3ae6HRalVc/g==: aXq6Am6sfOrpIC49yXjj3ae6HRalVc/g==:
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>With the additional requirements that at least the method, authority, path, content-digest, content-length, and content-type be signed, and that the signature creation timestamp is recent enough at the time of verification, the v erification passes.</t> <t>With the additional requirements that at least the method, authority, path, content-digest, content-length, and content-type entries be signed, and t hat the signature creation timestamp be recent enough at the time of verificatio n, the verification passes.</t>
<section anchor="verify-requirements"> <section anchor="verify-requirements">
<name>Enforcing Application Requirements</name> <name>Enforcing Application Requirements</name>
<t>The verification requirements specified in this document are intend ed as a baseline set of restrictions that are generally applicable to all use ca ses. Applications using HTTP Message Signatures <bcp14>MAY</bcp14> impose requir ements above and beyond those specified by this document, as appropriate for the ir use case.</t> <t>The verification requirements specified in this document are intend ed as a baseline set of restrictions that are generally applicable to all use ca ses. Applications using HTTP message signatures <bcp14>MAY</bcp14> impose requir ements above and beyond those specified by this document, as appropriate for the ir use case.</t>
<t>Some non-normative examples of additional requirements an applicati on might define are:</t> <t>Some non-normative examples of additional requirements an applicati on might define are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Requiring a specific set of header fields to be signed (e.g., Au <li>Requiring a specific set of header fields to be signed (e.g., Au
thorization, Digest).</li> thorization, Content-Digest).</li>
<li>Enforcing a maximum signature age from the time of the <tt>creat <li>Enforcing a maximum signature age from the time of the <tt>creat
ed</tt> time stamp.</li> ed</tt> timestamp.</li>
<li>Rejection of signatures past the expiration time in the <tt>expi <li>Rejecting signatures past the expiration time in the <tt>expires
res</tt> time stamp. Note that the expiration time is a hint from the signer and </tt> timestamp. Note that the expiration time is a hint from the signer and tha
that a verifier can always reject a signature ahead of its expiration time.</li t a verifier can always reject a signature ahead of its expiration time.</li>
> <li>Prohibiting certain signature metadata parameters, such as runti
<li>Prohibition of certain signature metadata parameters, such as ru me algorithm signaling with the <tt>alg</tt> parameter when the algorithm is det
ntime algorithm signaling with the <tt>alg</tt> parameter when the algorithm is ermined from the key information.</li>
determined from the key information.</li>
<li>Ensuring successful dereferencing of the <tt>keyid</tt> paramete r to valid and appropriate key material.</li> <li>Ensuring successful dereferencing of the <tt>keyid</tt> paramete r to valid and appropriate key material.</li>
<li>Prohibiting the use of certain algorithms, or mandating the use of a specific algorithm.</li> <li>Prohibiting the use of certain algorithms or mandating the use o f a specific algorithm.</li>
<li>Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 bits).</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>Enforcing uniqueness of the <tt>nonce</tt> parameter.</li>
<li>Requiring an application-specific value for the <tt>tag</tt> par ameter.</li> <li>Requiring an application-specific value for the <tt>tag</tt> par ameter.</li>
</ul> </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 <bcp1 4>MUST</bcp14> fail if the signature does not conform to the application's requi rements.</t> <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 <bcp1 4>MUST</bcp14> fail if the signature does not conform to the application's requi rements.</t>
<t>Applications <bcp14>MUST</bcp14> enforce the requirements defined i n this document. Regardless of use case, applications <bcp14>MUST NOT</bcp14> ac cept signatures that do not conform to these requirements.</t> <t>Applications <bcp14>MUST</bcp14> enforce the requirements defined i n this document. Regardless of use case, applications <bcp14>MUST NOT</bcp14> ac cept signatures that do not conform to these requirements.</t>
</section> </section>
</section> </section>
<section anchor="signature-methods"> <section anchor="signature-methods">
<name>Signature Algorithms</name> <name>Signature Algorithms</name>
<t>An HTTP Message signature <bcp14>MUST</bcp14> use a cryptographic dig ital signature or MAC method that is <t>An HTTP message signature <bcp14>MUST</bcp14> use a cryptographic dig ital signature or MAC method that is
appropriate for the key material, environment, and needs of the signer and verif ier. This specification does not strictly limit the available signature algorith ms, and any signature algorithm that meets these basic requirements <bcp14>MAY</ bcp14> be used by an application of HTTP message signatures.</t> appropriate for the key material, environment, and needs of the signer and verif ier. This specification does not strictly limit the available signature algorith ms, and any signature algorithm that meets these basic requirements <bcp14>MAY</ bcp14> be used by an application of HTTP message signatures.</t>
<t>Each signing method <tt>HTTP_SIGN</tt> takes as its input the signatu <t>For each signing method, <tt>HTTP_SIGN</tt> takes as its input the si
re base defined in <xref target="create-sig-input"/> as a byte array (<tt>M</tt> gnature base defined in <xref target="create-sig-input"/> as a byte array (<tt>M
), the signing key material </tt>) and the signing key material
(<tt>Ks</tt>), and outputs the signature output as a byte array (<tt>S</tt>):</t (<tt>Ks</tt>), and outputs the resultant signature as a byte array (<tt>S</tt>):
> </t>
<artwork><![CDATA[ <artwork><![CDATA[
HTTP_SIGN (M, Ks) -> S HTTP_SIGN (M, Ks) -> S
]]></artwork> ]]></artwork>
<t>Each verification method <tt>HTTP_VERIFY</tt> takes as its input the <t>For each verification method, <tt>HTTP_VERIFY</tt> takes as its input
re-generated signature base defined in <xref target="create-sig-input"/> as a by the regenerated signature base defined in <xref target="create-sig-input"/> as
te array (<tt>M</tt>), the verification key a byte array (<tt>M</tt>), the verification key
material (<tt>Kv</tt>), and the presented signature to be verified as a byte arr material (<tt>Kv</tt>), and the presented signature to be verified as a byte arr
ay (<tt>S</tt>) and outputs the verification result (<tt>V</tt>) as a boolean:</ ay (<tt>S</tt>), and outputs the verification result (<tt>V</tt>) as a Boolean:<
t> /t>
<artwork><![CDATA[ <artwork><![CDATA[
HTTP_VERIFY (M, Kv, S) -> V HTTP_VERIFY (M, Kv, S) -> V
]]></artwork> ]]></artwork>
<t>The following sections contain several common signature algorithms an <t>The following sections contain several common signature algorithms an
d demonstrate how these cryptographic primitives map to the <tt>HTTP_SIGN</tt> a d demonstrate how these cryptographic primitives map to the <tt>HTTP_SIGN</tt> a
nd <tt>HTTP_VERIFY</tt> definitions here. Which method to use can be communicate nd <tt>HTTP_VERIFY</tt> definitions above. Which method to use can be communicat
d through the explicit algorithm signature parameter <tt>alg</tt> ed through the explicit algorithm (<tt>alg</tt>) signature parameter (<xref targ
defined in <xref target="signature-params"/>, by reference to the key material, et="signature-params"/>), by reference to the key material, or through mutual ag
or through mutual agreement between the signer and verifier. Signature algorithm reement between the signer and verifier. Signature algorithms selected using the
s selected using the <tt>alg</tt> parameter <bcp14>MUST</bcp14> use values from <tt>alg</tt> parameter <bcp14>MUST</bcp14> use values from the <xref target="hs
the <xref target="hsa-registry">HTTP Signature Algorithms registry</xref>.</t> a-registry">"HTTP Signature Algorithms" registry</xref>.</t>
<section anchor="method-rsa-pss-sha512"> <section anchor="method-rsa-pss-sha512">
<name>RSASSA-PSS using SHA-512</name> <name>RSASSA-PSS Using SHA-512</name>
<t>To sign using this algorithm, the signer applies the <tt>RSASSA-PSS <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 -SIGN (K, M)</tt> function defined in <xref target="RFC8017"/> with the signer's
private signing key (<tt>K</tt>) and private signing key (<tt>K</tt>) and the signature base (<tt>M</tt>)
the signature base (<tt>M</tt>) (<xref target="create-sig-input"/>). (<xref target="create-sig-input"/>).
The mask generation function is <tt>MGF1</tt> as specified in <xref target="RFC8 017"/> with a hash function of SHA-512 <xref target="RFC6234"/>. The mask generation function is <tt>MGF1</tt> as specified in <xref target="RFC8 017"/> with a hash function of SHA-512 <xref target="RFC6234"/>.
The salt length (<tt>sLen</tt>) is 64 bytes. 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 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 digest content to which the digital signature is applied.
The resulting signed content byte array (<tt>S</tt>) is the HTTP message signatu re output used in <xref target="sign"/>.</t> The resulting signed content byte array (<tt>S</tt>) is the HTTP message signatu re 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 publ ic key portion of the verification key material (<tt>(n, e)</tt>) and the signat ure base (<tt>M</tt>) re-created as described in <xref target="verify"/>. <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 publ ic key portion of the verification key material (<tt>n, e</tt>) and the signatur e base (<tt>M</tt>) recreated as described in <xref target="verify"/>.
The mask generation function is <tt>MGF1</tt> as specified in <xref target="RFC8 017"/> with a hash function of SHA-512 <xref target="RFC6234"/>. The mask generation function is <tt>MGF1</tt> as specified in <xref target="RFC8 017"/> with a hash function of SHA-512 <xref target="RFC6234"/>.
The salt length (<tt>sLen</tt>) is 64 bytes. 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 funct ion is applied. 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 funct ion is applied.
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as described in <xref target="verify"/>. 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 the signature presented is The results of the verification function indicate whether the signature presente
valid.</t> d is valid.</t>
<t>Note that the output of RSA PSS algorithms are non-deterministic, a <t>Note that the output of the RSASSA-PSS algorithm is non-determinist
nd therefore it is not correct to re-calculate a new signature on the signature ic; therefore, it is not correct to recalculate a new signature on the signature
base and compare the results to an existing signature. Instead, the verification base and compare the results to an existing signature. Instead, the verificatio
algorithm defined here needs to be used. See <xref target="security-nondetermin n algorithm defined here needs to be used. See <xref target="security-nondetermi
istic"/>.</t> nistic"/>.</t>
<t>Use of this algorithm can be indicated at runtime using the <tt>rsa <t>The use of this algorithm can be indicated at runtime using the <tt
-pss-sha512</tt> value for the <tt>alg</tt> signature parameter.</t> >rsa-pss-sha512</tt> value for the <tt>alg</tt> signature parameter.</t>
</section> </section>
<section anchor="method-rsa-v1_5-sha256"> <section anchor="method-rsa-v1_5-sha256">
<name>RSASSA-PKCS1-v1_5 using SHA-256</name> <name>RSASSA-PKCS1-v1_5 Using SHA-256</name>
<t>To sign using this algorithm, the signer applies the <tt>RSASSA-PKC <t>To sign using this algorithm, the signer applies the <tt>RSASSA-PKC
S1-V1_5-SIGN (K, M)</tt> function defined in <xref target="RFC8017"/> with the s S1-V1_5-SIGN (K, M)</tt> function defined in <xref target="RFC8017"/> with the s
igner's private signing key (<tt>K</tt>) and igner's private signing key (<tt>K</tt>) and the
the signature base (<tt>M</tt>) (<xref target="create-sig-input"/>). signature base (<tt>M</tt>) (<xref target="create-sig-input"/>).
The hash SHA-256 <xref target="RFC6234"/> is applied to the signature base to cr eate The hash SHA-256 <xref target="RFC6234"/> is applied to the signature base to cr eate
the digest content to which the digital signature is applied. the digest content to which the digital signature is applied.
The resulting signed content byte array (<tt>S</tt>) is the HTTP message signatu re output used in <xref target="sign"/>.</t> The resulting signed content byte array (<tt>S</tt>) is the HTTP message signatu re 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 t he public key portion of the verification key material (<tt>(n, e)</tt>) and the signature base (<tt>M</tt>) re-created as described in <xref target="verify"/>. <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 t he public key portion of the verification key material (<tt>n, e</tt>) and the s ignature base (<tt>M</tt>) recreated as described in <xref target="verify"/>.
The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature b ase to create the digest content to which the verification function is applied. The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature b ase 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 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 the signature presented is The results of the verification function indicate whether the signature presente
valid.</t> d is valid.</t>
<t>Use of this algorithm can be indicated at runtime using the <tt>rsa <t>The use of this algorithm can be indicated at runtime using the <tt
-v1_5-sha256</tt> value for the <tt>alg</tt> signature parameter.</t> >rsa-v1_5-sha256</tt> value for the <tt>alg</tt> signature parameter.</t>
</section> </section>
<section anchor="method-hmac-sha256"> <section anchor="method-hmac-sha256">
<name>HMAC using SHA-256</name> <name>HMAC Using SHA-256</name>
<t>To sign and verify using this algorithm, the signer applies the <tt <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< >HMAC</tt> function <xref target="RFC2104"/> with the shared signing key (<tt>K<
/tt>) and /tt>) and the
the signature base (<tt>text</tt>) (<xref target="create-sig-input"/>). signature base (<tt>text</tt>) (<xref target="create-sig-input"/>).
The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature b ase to create the digest content to which the HMAC is applied, giving the signat ure result.</t> The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature b ase to create the digest content to which the HMAC is applied, giving the signat ure result.</t>
<t>For signing, the resulting value is the HTTP message signature outp ut used in <xref target="sign"/>.</t> <t>For signing, the resulting value is the HTTP message signature outp ut 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"/>. <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 me ssage signature, and the results of the comparison determine the validity of the signature presented.</t> The output of the HMAC function is compared bytewise to the value of the HTTP me ssage signature, and the results of the comparison determine the validity of the signature presented.</t>
<t>Use of this algorithm can be indicated at runtime using the <tt>hma c-sha256</tt> value for the <tt>alg</tt> signature parameter.</t> <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>
<section anchor="method-ecdsa-p256-sha256"> <section anchor="method-ecdsa-p256-sha256">
<name>ECDSA using curve P-256 DSS and SHA-256</name> <name>ECDSA Using Curve P-256 DSS and SHA-256</name>
<t>To sign using this algorithm, the signer applies the <tt>ECDSA</tt> <t>To sign using this algorithm, the signer applies the <tt>ECDSA</tt>
algorithm defined in <xref target="FIPS186-4"/> using curve P-256 with the sign signature algorithm defined in <xref target="FIPS186-5"/> using curve P-256 wit
er's private signing key and h the signer's private signing key and
the signature base (<xref target="create-sig-input"/>). the signature base (<xref target="create-sig-input"/>).
The hash SHA-256 <xref target="RFC6234"/> is applied to the signature base to cr eate The hash SHA-256 <xref target="RFC6234"/> is applied to the signature base to cr eate
the digest content to which the digital signature is applied, (<tt>M</tt>). the digest content to which the digital signature is applied (<tt>M</tt>).
The signature algorithm returns two integer values, <tt>r</tt> and <tt>s</tt>. T The signature algorithm returns two integer values: <tt>r</tt> and <tt>s</tt>. T
hese are both encoded as big-endian unsigned integers, zero-padded to 32-octets hese are both encoded as big-endian unsigned integers, zero-padded to 32 octets
each. These encoded values are concatenated into a single 64-octet array consist each. These encoded values are concatenated into a single 64-octet array consist
ing of the encoded value of <tt>r</tt> followed by the encoded value of <tt>s</t ing of the encoded value of <tt>r</tt> followed by the encoded value of <tt>s</t
t>. The resulting concatenation of <tt>(r, s)</tt> is byte array of the HTTP mes t>. The resulting concatenation of <tt>(r, s)</tt> is a byte array of the HTTP m
sage signature output used in <xref target="sign"/>.</t> essage signature output used in <xref target="sign"/>.</t>
<t>To verify using this algorithm, the verifier applies the <tt>ECDSA< <t>To verify using this algorithm, the verifier applies the <tt>ECDSA<
/tt> algorithm defined in <xref target="FIPS186-4"/> using the public key porti /tt> signature algorithm defined in <xref target="FIPS186-5"/> using the public
on of the verification key material and the signature base re-created as describ key portion of the verification key material and the signature base recreated a
ed in <xref target="verify"/>. s described in <xref target="verify"/>.
The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature b The hash function SHA-256 <xref target="RFC6234"/> is applied to the signature b
ase to create the digest content to which the signature verification function is ase to create the digest content to which the signature verification function is
applied, (<tt>M</tt>). applied (<tt>M</tt>).
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as 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 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 of the encoded values of <tt>r</tt> and <tt>s</tt> concatenated in order. These
are both encoded in big-endian unsigned integers, zero-padded to 32-octets each. are both encoded as big-endian unsigned integers, zero-padded to 32 octets each.
The resulting signature value <tt>(r, s)</tt> is used as input to the signature The resulting signature value <tt>(r, s)</tt> is used as input to the signature
verification function. verification function.
The results of the verification function indicate if the signature presented is The results of the verification function indicate whether the signature presente
valid.</t> d is valid.</t>
<t>Note that the output of ECDSA algorithms are non-deterministic, and <t>Note that the output of ECDSA signature algorithms is non-determini
therefore it is not correct to re-calculate a new signature on the signature ba stic; therefore, it is not correct to recalculate a new signature on the signatu
se and compare the results to an existing signature. Instead, the verification a re base and compare the results to an existing signature. Instead, the verificat
lgorithm defined here needs to be used. See <xref target="security-nondeterminis ion algorithm defined here needs to be used. See <xref target="security-nondeter
tic"/>.</t> ministic"/>.</t>
<t>Use of this algorithm can be indicated at runtime using the <tt>ecd <t>The use of this algorithm can be indicated at runtime using the <tt
sa-p256-sha256</tt> value for the <tt>alg</tt> signature parameter.</t> >ecdsa-p256-sha256</tt> value for the <tt>alg</tt> signature parameter.</t>
</section> </section>
<section anchor="method-ecdsa-p384-sha384"> <section anchor="method-ecdsa-p384-sha384">
<name>ECDSA using curve P-384 DSS and SHA-384</name> <name>ECDSA Using Curve P-384 DSS and SHA-384</name>
<t>To sign using this algorithm, the signer applies the <tt>ECDSA</tt> <t>To sign using this algorithm, the signer applies the <tt>ECDSA</tt>
algorithm defined in <xref target="FIPS186-4"/> using curve P-384 with the sign signature algorithm defined in <xref target="FIPS186-5"/> using curve P-384 wit
er's private signing key and h the signer's private signing key and the
the signature base (<xref target="create-sig-input"/>). signature base (<xref target="create-sig-input"/>).
The hash SHA-384 <xref target="RFC6234"/> is applied to the signature base to cr eate The hash SHA-384 <xref target="RFC6234"/> is applied to the signature base to cr eate
the digest content to which the digital signature is applied, (<tt>M</tt>). the digest content to which the digital signature is applied (<tt>M</tt>).
The signature algorithm returns two integer values, <tt>r</tt> and <tt>s</tt>. T The signature algorithm returns two integer values: <tt>r</tt> and <tt>s</tt>. T
hese are both encoded as big-endian unsigned integers, zero-padded to 48-octets hese are both encoded as big-endian unsigned integers, zero-padded to 48 octets
each. These encoded values are concatenated into a single 96-octet array consist each. These encoded values are concatenated into a single 96-octet array consist
ing of the encoded value of <tt>r</tt> followed by the encoded value of <tt>s</t ing of the encoded value of <tt>r</tt> followed by the encoded value of <tt>s</t
t>. The resulting concatenation of <tt>(r, s)</tt> is byte array of the HTTP mes t>. The resulting concatenation of <tt>(r, s)</tt> is a byte array of the HTTP m
sage signature output used in <xref target="sign"/>.</t> essage signature output used in <xref target="sign"/>.</t>
<t>To verify using this algorithm, the verifier applies the <tt>ECDSA< <t>To verify using this algorithm, the verifier applies the <tt>ECDSA<
/tt> algorithm defined in <xref target="FIPS186-4"/> using the public key porti /tt> signature algorithm defined in <xref target="FIPS186-5"/> using the public
on of the verification key material and the signature base re-created as describ key portion of the verification key material and the signature base recreated a
ed in <xref target="verify"/>. s described in <xref target="verify"/>.
The hash function SHA-384 <xref target="RFC6234"/> is applied to the signature b The hash function SHA-384 <xref target="RFC6234"/> is applied to the signature b
ase to create the digest content to which the signature verification function is ase to create the digest content to which the signature verification function is
applied, (<tt>M</tt>). applied (<tt>M</tt>).
The verifier extracts the HTTP message signature to be verified (<tt>S</tt>) as 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 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 of the encoded values of <tt>r</tt> and <tt>s</tt> concatenated in order. These
are both encoded in big-endian unsigned integers, zero-padded to 48-octets each. are both encoded as big-endian unsigned integers, zero-padded to 48 octets each.
The resulting signature value <tt>(r, s)</tt> is used as input to the signature The resulting signature value <tt>(r, s)</tt> is used as input to the signature
verification function. verification function.
The results of the verification function indicate if the signature presented is The results of the verification function indicate whether the signature presente
valid.</t> d is valid.</t>
<t>Note that the output of ECDSA algorithms are non-deterministic, and <t>Note that the output of ECDSA signature algorithms is non-determini
therefore it is not correct to re-calculate a new signature on the signature ba stic; therefore, it is not correct to recalculate a new signature on the signatu
se and compare the results to an existing signature. Instead, the verification a re base and compare the results to an existing signature. Instead, the verificat
lgorithm defined here needs to be used. See <xref target="security-nondeterminis ion algorithm defined here needs to be used. See <xref target="security-nondeter
tic"/>.</t> ministic"/>.</t>
<t>Use of this algorithm can be indicated at runtime using the <tt>ecd <t>The use of this algorithm can be indicated at runtime using the <tt
sa-p384-sha384</tt> value for the <tt>alg</tt> signature parameter.</t> >ecdsa-p384-sha384</tt> value for the <tt>alg</tt> signature parameter.</t>
</section> </section>
<section anchor="method-ed25519"> <section anchor="method-ed25519">
<name>EdDSA using curve edwards25519</name> <name>EdDSA Using Curve edwards25519</name>
<t>To sign using this algorithm, the signer applies the <tt>Ed25519</t t> algorithm defined in <xref section="5.1.6" sectionFormat="of" target="RFC8032 "/> with the signer's private signing key and <t>To sign using this algorithm, the signer applies the <tt>Ed25519</t t> 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 (<xref target="create-sig-input"/>).
The signature base is taken as the input message (<tt>M</tt>) with no pre-hash f unction. The signature base is taken as the input message (<tt>M</tt>) with no prehash fu nction.
The signature is a 64-octet concatenation of <tt>R</tt> and <tt>S</tt> as specif ied 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> The signature is a 64-octet concatenation of <tt>R</tt> and <tt>S</tt> as specif ied 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< <t>To verify using this algorithm, the signer applies the <tt>Ed25519<
/tt> algorithm defined in <xref section="5.1.7" sectionFormat="of" target="RFC80 /tt> algorithm defined in <xref section="5.1.7" sectionFormat="of" target="RFC80
32"/> using the public key portion of the verification key material (<tt>A</tt>) 32"/> using the public key portion of the verification key material (<tt>A</tt>)
and the signature base re-created as described in <xref target="verify"/>. and the signature base recreated as described in <xref target="verify"/>.
The signature base is taken as the input message (<tt>M</tt>) with no pre-hash f The signature base is taken as the input message (<tt>M</tt>) with no prehash fu
unction. nction.
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" ta rget="RFC8032"/>. 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" ta rget="RFC8032"/>.
The results of the verification function indicate if the signature presented is The results of the verification function indicate whether the signature presente
valid.</t> d is valid.</t>
<t>Use of this algorithm can be indicated at runtime using the <tt>ed2 <t>The use of this algorithm can be indicated at runtime using the <tt
5519</tt> value for the <tt>alg</tt> signature parameter.</t> >ed25519</tt> value for the <tt>alg</tt> signature parameter.</t>
</section> </section>
<section anchor="method-jose"> <section anchor="method-jose">
<name>JSON Web Signature (JWS) algorithms</name> <name>JSON Web Signature (JWS) Algorithms</name>
<t>If the signing algorithm is a JOSE signing algorithm from the JSON <t>If the signing algorithm is a JSON Object Signing and Encryption (J
Web Signature and Encryption Algorithms Registry established by <xref target="RF OSE) signing algorithm from the "JSON Web Signature and Encryption Algorithms" r
C7518"/>, the egistry established by <xref target="RFC7518"/>, the
JWS algorithm definition determines the signature and hashing algorithms to appl y for both signing and verification.</t> JWS algorithm definition determines the signature and hashing algorithms to appl y for both signing and verification.</t>
<t>For both signing and verification, the HTTP messages signature base <t>For both signing and verification, the HTTP message's signature bas
(<xref target="create-sig-input"/>) is used as the entire "JWS Signing Input". e (<xref target="create-sig-input"/>) is used as the entire "JWS Signing Input".
The JOSE Header defined in <xref target="RFC7517"/> is not used, and the signatu The JOSE Header <xref target="RFC7515"/> <xref target="RFC7517"/> is not used, a
re base is not first encoded in Base64 before applying the algorithm. nd the signature base is not first encoded in Base64 before applying the algorit
The output of the JWS signature is taken as a byte array prior to the Base64url hm.
encoding used in JOSE.</t> The output of the JWS Signature is taken as a byte array prior to the Base64url
<t>The JWS algorithm <bcp14>MUST NOT</bcp14> be <tt>none</tt> and <bcp encoding used in JOSE.</t>
14>MUST NOT</bcp14> be any algorithm with a JOSE Implementation Requirement of < <t>The JWS algorithm <bcp14>MUST NOT</bcp14> be "<tt>none</tt>" and <b
tt>Prohibited</tt>.</t> cp14>MUST NOT</bcp14> be any algorithm with a JOSE Implementation Requirement of
<t>JWA algorithm values from the JSON Web Signature and Encryption Alg "<tt>Prohibited</tt>".</t>
orithms Registry are not included as signature parameters. Typically, the JWS al <t>JSON Web Algorithm (JWA) values from the "JSON Web Signature and En
gorithm can be signaled using JSON Web Keys or other mechanisms common to JOSE i cryption Algorithms" registry are not included as signature parameters. Typicall
mplementations. In fact, JWA algorithm values are not registered in the <xref ta y, the JWS algorithm can be signaled using JSON Web Keys (JWKs) or other mechani
rget="hsa-registry">HTTP Signature Algorithms registry</xref>, and so the explic sms common to JOSE implementations. In fact, JWA values are not registered in th
it <tt>alg</tt> signature parameter is not used at all when using JOSE signing a e <xref target="hsa-registry">"HTTP Signature Algorithms" registry</xref>, and s
lgorithms.</t> o the explicit <tt>alg</tt> signature parameter is not used at all when using JO
SE signing algorithms.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="attach-signature"> <section anchor="attach-signature">
<name>Including a Message Signature in a Message</name> <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>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 paramet ers that describe how the signature was generated, while the Signature field con tains the signature value. Each field <bcp14>MAY</bcp14> contain multiple labele d values.</t> <t>The Signature-Input field identifies the covered components and paramet ers that describe how the signature was generated, while the Signature field con tains the signature value. Each field <bcp14>MAY</bcp14> contain multiple labele d values.</t>
<t>An HTTP message signature is identified by a label within an HTTP messa <t>An HTTP message signature is identified by a label within an HTTP messa
ge. This label <bcp14>MUST</bcp14> be unique within a given HTTP message and <bc ge. This label <bcp14>MUST</bcp14> be unique within a given HTTP message and <bc
p14>MUST</bcp14> be used in both the Signature-Input and Signature fields. The l p14>MUST</bcp14> be used in both the Signature-Input field and the Signature fie
abel is chosen by the signer, except where a specific label is dictated by proto ld. The label is chosen by the signer, except where a specific label is dictated
col negotiations such as described in <xref target="request-signature"/>.</t> by protocol negotiations such as those described in <xref target="request-signa
<t>An HTTP message signature <bcp14>MUST</bcp14> use both Signature-Input ture"/>.</t>
and Signature fields and each field <bcp14>MUST</bcp14> contain the same labels. <t>An HTTP message signature <bcp14>MUST</bcp14> use both the Signature-In
The presence of a label in one field but not in the other is an error.</t> put field and the Signature field, and each field <bcp14>MUST</bcp14> contain th
e same labels. The presence of a label in one field but not the other is an erro
r.</t>
<section anchor="signature-input-header"> <section anchor="signature-input-header">
<name>The Signature-Input HTTP Field</name> <name>The Signature-Input HTTP Field</name>
<t>The Signature-Input field is a Dictionary structured field (defined i n <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) containin g the metadata for one or more message signatures generated from components with in the HTTP message. Each member describes a single message signature. The membe r's key is the label that uniquely identifies the message signature within the H TTP message. The member's value is the serialization of the covered components I nner List plus all signature metadata parameters identified by the label.</t> <t>The Signature-Input field is a Dictionary Structured Field (defined i n <xref section="3.2" sectionFormat="of" target="RFC8941"/>) containing the meta data for one or more message signatures generated from components within the HTT P message. Each member describes a single message signature. The member's key is the label that uniquely identifies the message signature within the HTTP messag e. The member's value is the covered components ordered set serialized as an Inn er List, including all signature metadata parameters identified by the label:</t >
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig1=("@method" "@target-uri" "@authority" \ Signature-Input: sig1=("@method" "@target-uri" "@authority" \
"content-digest" "cache-control");\ "content-digest" "cache-control");\
created=1618884475;keyid="test-key-rsa-pss" created=1618884475;keyid="test-key-rsa-pss"
]]></sourcecode> ]]></sourcecode>
<t>To facilitate signature validation, the Signature-Input field value < bcp14>MUST</bcp14> contain the same serialized value used <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 < in generating the signature base's <tt>@signature-params</tt> value defined in <
xref target="signature-params"/>. Note that in a structured field value, list or xref target="signature-params"/>. Note that in a Structured Field value, list or
der and parameter order have to be preserved.</t> der and parameter order have to be preserved.</t>
<t>The signer <bcp14>MAY</bcp14> include the Signature-Input field as a <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 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 <x the signer. However, since intermediaries are allowed to drop trailers as per <x
ref target="HTTP"/>, it is <bcp14>RECOMMENDED</bcp14> that the Signature-Input f ref target="RFC9110"/>, it is <bcp14>RECOMMENDED</bcp14> that the Signature-Inpu
ield be included only as a header to avoid signatures being inadvertently stripp t field be included only as a header field to avoid signatures being inadvertent
ed from a message.</t> ly stripped from a message.</t>
<t>Multiple Signature-Input fields <bcp14>MAY</bcp14> be included in a s ingle HTTP message. The signature labels <bcp14>MUST</bcp14> be unique across al l field values.</t> <t>Multiple Signature-Input fields <bcp14>MAY</bcp14> be included in a s ingle HTTP message. The signature labels <bcp14>MUST</bcp14> be unique across al l field values.</t>
</section> </section>
<section anchor="signature-header"> <section anchor="signature-header">
<name>The Signature HTTP Field</name> <name>The Signature HTTP Field</name>
<t>The Signature field is a Dictionary structured field defined in <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> containing one or more message signatures generated from the signature context of the target mess age. The member's key is the label that uniquely identifies the message signatur e 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> <t>The Signature field is a Dictionary Structured Field (defined in <xre f section="3.2" sectionFormat="of" target="RFC8941"/>) containing one or more me ssage 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 signatur e value for the message signature identified by the label:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Signature: sig1=:P0wLUszWQjoi54udOtydf9IWTfNhy+r53jGFj9XZuP4uKwxyJo\ Signature: sig1=:P0wLUszWQjoi54udOtydf9IWTfNhy+r53jGFj9XZuP4uKwxyJo\
1RSHi+oEF1FuX6O29d+lbxwwBao1BAgadijW+7O/PyezlTnqAOVPWx9GlyntiCiHz\ 1RSHi+oEF1FuX6O29d+lbxwwBao1BAgadijW+7O/PyezlTnqAOVPWx9GlyntiCiHz\
C87qmSQjvu1CFyFuWSjdGa3qLYYlNm7pVaJFalQiKWnUaqfT4LyttaXyoyZW84jS8\ C87qmSQjvu1CFyFuWSjdGa3qLYYlNm7pVaJFalQiKWnUaqfT4LyttaXyoyZW84jS8\
gyarxAiWI97mPXU+OVM64+HVBHmnEsS+lTeIsEQo36T3NFf2CujWARPQg53r58Rmp\ gyarxAiWI97mPXU+OVM64+HVBHmnEsS+lTeIsEQo36T3NFf2CujWARPQg53r58Rmp\
Z+J9eKR2CD6IJQvacn5A4Ix5BUAVGqlyp8JYm+S/CWJi31PNUjRRCusCVRj05NrxA\ Z+J9eKR2CD6IJQvacn5A4Ix5BUAVGqlyp8JYm+S/CWJi31PNUjRRCusCVRj05NrxA\
BNFv3r5S9IXf2fYJK+eyW4AiGVMvMcOg==: BNFv3r5S9IXf2fYJK+eyW4AiGVMvMcOg==:
]]></sourcecode> ]]></sourcecode>
<t>The signer <bcp14>MAY</bcp14> include the Signature field as a traile r to facilitate signing a message after its content has been processed by the si gner. However, since intermediaries are allowed to drop trailers as per <xref ta rget="HTTP"/>, it is <bcp14>RECOMMENDED</bcp14> that the Signature field be incl uded only as a header to avoid signatures being inadvertently stripped from a me ssage.</t> <t>The signer <bcp14>MAY</bcp14> include the Signature field as a traile r to facilitate signing a message after its content has been processed by the si gner. However, since intermediaries are allowed to drop trailers as per <xref ta rget="RFC9110"/>, it is <bcp14>RECOMMENDED</bcp14> that the Signature field be i ncluded 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 fiel d values.</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 fiel d values.</t>
</section> </section>
<section anchor="signature-multiple"> <section anchor="signature-multiple">
<name>Multiple Signatures</name> <name>Multiple Signatures</name>
<t>Multiple distinct signatures <bcp14>MAY</bcp14> be included in a sing <t>Multiple distinct signatures <bcp14>MAY</bcp14> be included in a sing
le message. Each distinct signature <bcp14>MUST</bcp14> have a unique label. The le message. Each distinct signature <bcp14>MUST</bcp14> have a unique label. The
se multiple signatures could be added all by the same signer or could come from se multiple signatures could all be added by the same signer, or they could come
several different signers. For example, a signer may include multiple signatures from several different signers. For example, a signer may include multiple sign
signing the same message components with different keys or algorithms to suppor atures signing the same message components with different keys or algorithms to
t verifiers with different capabilities, or a reverse proxy may include informat support verifiers with different capabilities, or a reverse proxy may include in
ion about the client in fields when forwarding the request to a service host, in formation about the client in fields when forwarding the request to a service ho
cluding a signature over the client's original signature values.</t> st, including a signature over the client's original signature values.</t>
<t>The following non-normative example starts with a signed request from <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 signa the client. A reverse proxy takes this request and validates the client's signa
ture.</t> ture:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \ Signature-Input: sig1=("@method" "@authority" "@path" \
"content-digest" "content-type" "content-length")\ "content-digest" "content-type" "content-length")\
;created=1618884475;keyid="test-key-ecc-p256" ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\ Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
+kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==: +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>The proxy then alters the message before forwarding it on to the orig in server, changing the target host and adding the Forwarded header field define d in <xref target="RFC7239"/>.</t> <t>The proxy then alters the message before forwarding it on to the orig in server, changing the target host and adding the Forwarded header field define d in <xref target="RFC7239"/>:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \ Signature-Input: sig1=("@method" "@authority" "@path" \
"content-digest" "content-type" "content-length")\ "content-digest" "content-type" "content-length")\
;created=1618884475;keyid="test-key-ecc-p256" ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\ Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
+kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==: +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>The proxy is in a position to validate the incoming client's signatur e and make its own statement to the origin server about the nature of the reques t that it is forwarding by adding its own signature over the new message before passing it along to the origin server. <t>The proxy is in a position to validate the incoming client's signatur e and make its own statement to the origin server about the nature of the reques t 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 rele vant to the origin server's processing. In many cases, the proxy will want to co ver all the same components that were covered by the client's signature, which i s the case in this example. Note that in this example, the proxy is signing over the new authority value, which it has changed. The proxy also adds the Forwarde d header to its own signature value. The proxy also includes all the elements from the original message that are rele vant to the origin server's processing. In many cases, the proxy will want to co ver all the same components that were covered by the client's signature, which i s the case in the following example. Note that in this example, the proxy is sig ning 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 w ill not vouch for this signed message past this short time window. This results in a signature base of:</t> 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 w ill not vouch for this signed message past this short time window. This results in a signature base of:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@method": POST "@method": POST
"@authority": origin.host.internal.example "@authority": origin.host.internal.example
"@path": /foo "@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\ "content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type": application/json "content-type": application/json
"content-length": 18 "content-length": 18
"forwarded": for=192.0.2.123;host=example.com;proto=https "forwarded": for=192.0.2.123;host=example.com;proto=https
"@signature-params": ("@method" "@authority" "@path" \ "@signature-params": ("@method" "@authority" "@path" \
"content-digest" "content-type" "content-length" "forwarded")\ "content-digest" "content-type" "content-length" "forwarded")\
;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\ ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
;expires=1618884540 ;expires=1618884540
]]></artwork> ]]></artwork>
<t>And a signature output value of:</t> <t>and a signature output value of:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy\ S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy\
+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s\ +CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s\
x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn\ x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn\
Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0\ Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0\
B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w\ B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w\
5o0LV/g== 5o0LV/g==
]]></artwork> ]]></artwork>
<t>These values are added to the HTTP request message by the proxy. The original signature is included under the identifier <tt>sig1</tt>, and the rever se proxy's signature is included under the label <tt>proxy_sig</tt>. The proxy u ses 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 signature algorith m.</t> <t>These values are added to the HTTP request message by the proxy. The original signature is included under the label <tt>sig1</tt>, and the reverse pr oxy's signature is included under the label <tt>proxy_sig</tt>. The proxy uses t he key <tt>test-key-rsa</tt> to create its signature using the <tt>rsa-v1_5-sha2 56</tt> signature algorithm, while the client's original signature was made usin g the key <tt>test-key-rsa-pss</tt> and an RSA-PSS signature algorithm:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\ Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
skipping to change at line 1415 skipping to change at line 1426
+kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:, \ +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:, \
proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+\ proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+\
JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G\ JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G\
wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7\ wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7\
LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf\ LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf\
lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL\ lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL\
Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==: Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==:
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>While the proxy could additionally include the client's Signature val ue and Signature-Input fields from the original message in the new signature's c overed components, this practice is <bcp14>NOT RECOMMENDED</bcp14> due to known weaknesses in signing signature values as discussed in <xref target="security-si gn-signature"/>. The proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signatur e 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 t o account for the change in authority, though this practice requires additional configuration and extra care as discussed in <xref target="security-context-mult iple-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 pro xy 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> <t>While the proxy could additionally include the client's Signature fie ld value and Signature-Input fields from the original message in the new signatu re's covered components, this practice is <bcp14>NOT RECOMMENDED</bcp14> due to known weaknesses in signing signature values as discussed in <xref target="secur ity-sign-signature"/>. The proxy is in a position to validate the client's signa ture; the changes the proxy makes to the message will invalidate the existing si gnature when the message is seen by the origin server. In this example, it is po ssible for the origin server to have additional information in its signature con text to account for the change in authority, though this practice requires addit ional configuration and extra care as discussed in <xref target="security-contex t-multiple-signatures"/>. In other applications, the origin server will not be a ble to verify the original signature itself but will still want to verify that t he proxy has done the appropriate validation of the client's signature. An appli cation that needs to signal successful processing or receipt of a signature woul d need to carefully specify alternative mechanisms for sending such a signal sec urely.</t>
</section> </section>
</section> </section>
<section anchor="request-signature"> <section anchor="request-signature">
<name>Requesting Signatures</name> <name>Requesting Signatures</name>
<t>While a signer is free to attach a signature to a request or response w ithout 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>While a signer is free to attach a signature to a request or response w ithout 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 t he identified parameters, and the target message is the response to this request . All responses from resources that support such signature negotiation <bcp14>SH OULD</bcp14> either be uncacheable or contain a Vary header field that lists Acc ept-Signature, in order to prevent a cache from returning a response with a sign ature intended for a different request.</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 t he identified parameters, and the target message is the response to this request . All responses from resources that support such signature negotiation <bcp14>SH OULD</bcp14> either be uncacheable or contain a Vary header field that lists Acc ept-Signature, in order to prevent a cache from returning a response with a sign ature intended for a different request.</t>
<t>When the Accept-Signature field is used in an HTTP response message, th e 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>When the Accept-Signature field is used in an HTTP response message, th e 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> inc <t>The target message of an Accept-Signature field <bcp14>MUST</bcp14> inc
lude all labeled signatures indicated in the Accept-Header signature, each cover lude all labeled signatures indicated in the Accept-Signature field, each coveri
ing the same identified components of the Accept-Signature field.</t> ng the same identified components of the Accept-Signature field.</t>
<t>The sender of an Accept-Signature field <bcp14>MUST</bcp14> include onl <t>The sender of an Accept-Signature field <bcp14>MUST</bcp14> include onl
y identifiers that are appropriate for the type of the target message. For examp y identifiers that are appropriate for the type of the target message. For examp
le, if the target message is a request, the covered components can not include t le, if the target message is a request, the covered components cannot include th
he <tt>@status</tt> component identifier.</t> e <tt>@status</tt> component identifier.</t>
<section anchor="accept-signature-header"> <section anchor="accept-signature-header">
<name>The Accept-Signature Field</name> <name>The Accept-Signature Field</name>
<t>The Accept-Signature field is a Dictionary structured field (defined <t>The Accept-Signature field is a Dictionary Structured Field (defined
in <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) containi in <xref section="3.2" sectionFormat="of" target="RFC8941"/>) containing the met
ng the metadata for one or more requested message signatures to be generated fro adata for one or more requested message signatures to be generated from message
m message components of the target HTTP message. Each member describes a single components of the target HTTP message. Each member describes a single message si
message signature. The member's key is the label that uniquely identifies the re gnature. The member's key is the label that uniquely identifies the requested me
quested message signature within the context of the target HTTP message.</t> ssage signature within the context of the target HTTP message.</t>
<t>The member's value is the serialization of the desired covered compon <t>The member's value is the serialization of the desired covered compon
ents of the target message, including any allowed component metadata parameters, ents of the target message, including any allowed component metadata parameters,
using the serialization process defined in <xref target="signature-params"/>.</ using the serialization process defined in <xref target="signature-params"/>:</
t> t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Accept-Signature: sig1=("@method" "@target-uri" "@authority" \ Accept-Signature: sig1=("@method" "@target-uri" "@authority" \
"content-digest" "cache-control");\ "content-digest" "cache-control");\
keyid="test-key-rsa-pss";created;tag="app-123" keyid="test-key-rsa-pss";created;tag="app-123"
]]></sourcecode> ]]></sourcecode>
<t>The list of component identifiers indicates the exact set of componen t identifiers to be included in the requested signature, including all applicabl e component parameters.</t> <t>The list of component identifiers indicates the exact set of componen t identifiers to be included in the requested signature, including all applicabl e component parameters.</t>
<t>The signature request <bcp14>MAY</bcp14> include signature metadata p arameters that indicate desired behavior for the signer. The following behavior is defined by this specification:</t> <t>The signature request <bcp14>MAY</bcp14> include signature metadata p arameters that indicate desired behavior for the signer. The following behavior is defined by this specification:</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>
<tt>created</tt>: The signer is requested to generate and include a <tt>created</tt>:</dt><dd>The signer is requested to generate and in
creation time. This parameter has no associated value when sent as a signature r clude a creation time. This parameter has no associated value when sent as a sig
equest.</li> nature request.</dd>
<li> <dt>
<tt>expires</tt>: The signer is requested to generate and include an <tt>expires</tt>:</dt><dd>The signer is requested to generate and in
expiration time. This parameter has no associated value when sent as a signatur clude an expiration time. This parameter has no associated value when sent as a
e request.</li> signature request.</dd>
<li> <dt>
<tt>nonce</tt>: The signer is requested to include the value of this <tt>nonce</tt>:</dt><dd>The signer is requested to include the value
parameter as the signature <tt>nonce</tt> in the target signature.</li> of this parameter as the signature <tt>nonce</tt> in the target signature.</dd>
<li> <dt>
<tt>alg</tt>: The signer is requested to use the indicated signature <tt>alg</tt>:</dt><dd>The signer is requested to use the indicated s
algorithm from the HTTP Signature Algorithms Registry to create the target sign ignature algorithm from the "HTTP Signature Algorithms" registry to create the t
ature.</li> arget signature.</dd>
<li> <dt>
<tt>keyid</tt>: The signer is requested to use the indicated key mat <tt>keyid</tt>:</dt><dd>The signer is requested to use the indicated
erial to create the target signature.</li> key material to create the target signature.</dd>
<li> <dt>
<tt>tag</tt>: The signer is requested to include the value of this p <tt>tag</tt>:</dt><dd>The signer is requested to include the value o
arameter as the signature <tt>tag</tt> in the target signature.</li> f this parameter as the signature <tt>tag</tt> in the target signature.</dd>
</ul> </dl>
</section> </section>
<section anchor="processing-an-accept-signature"> <section anchor="processing-an-accept-signature">
<name>Processing an Accept-Signature</name> <name>Processing an Accept-Signature</name>
<t>The receiver of an Accept-Signature field fulfills that header as fol lows:</t> <t>The receiver of an Accept-Signature field fulfills that header as fol lows:</t>
<ol spacing="normal" type="1"><li>Parse the field value as a Dictionary< /li> <ol spacing="normal" type="1"><li>Parse the field value as a Dictionary. </li>
<li> <li>
<t>For each member of the dictionary: <t>For each member of the Dictionary:
</t> </t>
<ol spacing="normal" type="1"><li>The key is taken as the label of t he output signature as specified in <xref target="signature-input-header"/>.</li > <ol spacing="normal" 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 com ponent identifiers.</li> <li>Parse the value of the member to obtain the set of covered com ponent identifiers.</li>
<li>Determine that the covered components are applicable to the ta rget message. If not, the process fails and returns an error.</li> <li>Determine that the covered components are applicable to the ta rget message. If not, the process fails and returns an error.</li>
<li>Process the requested parameters, such as the signing algorith m and key material. If any requested parameters cannot be fulfilled, or if the r equested parameters conflict with those deemed appropriate to the target message , the process fails and returns an error.</li> <li>Process the requested parameters, such as the signing algorith m and key material. If any requested parameters cannot be fulfilled or if the re quested 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 co mpleting the signature.</li> <li>Select and generate any additional parameters necessary for co mpleting the signature.</li>
<li>Create the HTTP message signature over the target message.</li > <li>Create the HTTP message signature over the target message.</li >
<li>Create the Signature-Input and Signature values and associate them with the label.</li> <li>Create the Signature-Input and Signature field values, and ass ociate them with the label.</li>
</ol> </ol>
</li> </li>
<li>Optionally create any additional Signature-Input and Signature val <li>Optionally create any additional Signature-Input and Signature fie
ues, with unique labels not found in the Accept-Signature field.</li> ld values, with unique labels not found in the Accept-Signature field.</li>
<li>Combine all labeled Signature-Input and Signature values and attac <li>Combine all labeled Signature-Input and Signature field values, an
h both fields to the target message.</li> d attach both fields to the target message.</li>
</ol> </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, <bcp14>MUST</bcp14> process all requested parameters, and <bcp14>MAY </bcp14> have additional parameters.</t> <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 components, <bcp14>MUST</bcp14> process all requested parameters, and <bcp14>MA Y</bcp14> have additional parameters.</t>
<t>The receiver of an Accept-Signature field <bcp14>MAY</bcp14> ignore a ny signature request that does not fit application parameters.</t> <t>The receiver of an Accept-Signature field <bcp14>MAY</bcp14> ignore a ny signature request that does not fit application parameters.</t>
<t>The target message <bcp14>MAY</bcp14> include additional signatures n ot specified by the Accept-Signature field. For example, to cover additional mes sage components, the signer can create a second signature that includes the addi tional components as well as the signature output of the requested signature.</t > <t>The target message <bcp14>MAY</bcp14> include additional signatures n ot specified by the Accept-Signature field. For example, to cover additional mes sage components, the signer can create a second signature that includes the addi tional components as well as the signature output of the requested signature.</t >
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is asked to update one registry and create four new registries, ac cording to the following sections.</t> <t>IANA has updated one registry and created four new registries, accordin g to the following sections.</t>
<section anchor="http-field-name-registration"> <section anchor="http-field-name-registration">
<name>HTTP Field Name Registration</name> <name>HTTP Field Name Registration</name>
<t>IANA is asked to update the <t>IANA has updated the entries in the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry, "Hypertext Transfer Protocol (HTTP) Field Name Registry" as follows:
registering the following entries according to the table below:</t> </t>
<table> <table>
<name>Updates to the Hypertext Transfer Protocol (HTTP) Field Name Regi stry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Field Name</th> <th align="left">Field Name</th>
<th align="left">Status</th> <th align="left">Status</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Signature-Input</td> <td align="left">Signature-Input</td>
<td align="left">permanent</td> <td align="left">permanent</td>
<td align="left"> <td align="left">
<xref target="signature-input-header"/> of RFC nnnn</td> <xref target="signature-input-header"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left">Signature</td> <td align="left">Signature</td>
<td align="left">permanent</td> <td align="left">permanent</td>
<td align="left"> <td align="left">
<xref target="signature-header"/> of RFC nnnn</td> <xref target="signature-header"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left">Accept-Signature</td> <td align="left">Accept-Signature</td>
<td align="left">permanent</td> <td align="left">permanent</td>
<td align="left"> <td align="left">
<xref target="accept-signature-header"/> of RFC nnnn</td> <xref target="accept-signature-header"/> of RFC 9421</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="hsa-registry"> <section anchor="hsa-registry">
<name>HTTP Signature Algorithms Registry</name> <name>HTTP Signature Algorithms Registry</name>
<t>This document defines HTTP Signature Algorithms, for which IANA is as <t>This document defines HTTP signature algorithms, for which IANA has c
ked to create and maintain a new registry titled "HTTP Signature Algorithms". In reated and now maintains a new registry titled "HTTP Signature Algorithms". Init
itial values for this registry are given in <xref target="iana-hsa-contents"/>. ial values for this registry are given in <xref target="iana-hsa-contents"/>. Fu
Future assignments and modifications to existing assignment are to be made throu ture assignments and modifications to existing assignments are to be made throug
gh the Specification Required registration policy <xref target="RFC8126"/>.</t> h the Specification Required registration policy <xref target="RFC8126"/>.</t>
<t>The algorithms listed in this registry identify some possible cryptog <t>The algorithms listed in this registry identify some possible cryptog
raphic algorithms for applications to use with this specification, but the entri raphic algorithms for applications to use with this specification, but the entri
es neither represent an exhaustive list of possible algorithms nor indicate fitn es neither represent an exhaustive list of possible algorithms nor indicate fitn
ess for purpose with any particular application of this specification. An applic ess for purpose with any particular application of this specification. An applic
ation is free to implement any algorithm that suits its needs, provided the sign ation is free to implement any algorithm that suits its needs, provided the sign
er and verifier can agree to the parameters of that algorithm in a secure and de er and verifier can agree to the parameters of that algorithm in a secure and de
terministic fashion. When an application has a need to signal the use of a parti terministic fashion. When an application needs to signal the use of a particular
cular algorithm at runtime using the <tt>alg</tt> signature parameter, this regi algorithm at runtime using the <tt>alg</tt> signature parameter, this registry
stry provides a mapping between the value of that parameter to a particular algo provides a mapping between the value of that parameter and a particular algorith
rithm. However, use of the <tt>alg</tt> parameter needs to be treated with cauti m. However, the use of the <tt>alg</tt> parameter needs to be treated with cauti
on to avoid various forms of algorithm confusion and substitution attacks, such on to avoid various forms of algorithm confusion and substitution attacks, as di
as discussed in <xref target="security-keydowngrade"/> and others.</t> scussed in <xref target="security"/>.</t>
<t>The Status value should reflect standardization status and the broad <t>The Status value should reflect standardization status and the broad
opinion of relevant interest groups such as the IETF or security-related SDOs. W opinion of relevant interest groups such as the IETF or security-related Standar
hen an algorithm is first registered, the Designated Expert (DE) should set the ds Development Organizations (SDOs). When an algorithm is first registered, the
Status field to "Active" if there is consensus for the algorithm to be generally designated expert (DE) should set the Status field to "Active" if there is conse
recommended as secure or "Provisional" if the algorithm has not reached that co nsus for the algorithm to be generally recommended as secure or "Provisional" if
nsensus, such as for an experimental algorithm. A status of "Provisional" does n the algorithm has not reached that consensus, e.g., for an experimental algorit
ot mean that the algorithm is known to be insecure, but instead indicates that t hm. A status of "Provisional" does not mean that the algorithm is known to be in
he algorithm has not reached consensus regarding its properties. If at a future secure but instead indicates that the algorithm has not reached consensus regard
time the algorithm as registered is found to have flaws, the registry entry can ing its properties. If at a future time the algorithm as registered is found to
be updated and the algorithm can be marked as "Deprecated" to indicate that the have flaws, the registry entry can be updated and the algorithm can be marked as
algorithm has been found to have problems. This status does not preclude an appl "Deprecated" to indicate that the algorithm has been found to have problems. Th
ication from using a particular algorithm, but serves to provide warning of poss is status does not preclude an application from using a particular algorithm; ra
ible known issues with an algorithm that need to be considered by the applicatio ther, it serves to provide a warning regarding possible known issues with an alg
n. The DE can further ensure that the registration includes an explanation and r orithm that need to be considered by the application. The DE can further ensure
eference for the Status value, which is particularly important for deprecated al that the registration includes an explanation and reference for the Status value
gorithms.</t> ; this is particularly important for deprecated algorithms.</t>
<t>The DE is expected to ensure that the algorithms referenced by a regi <t>The DE is expected to do the following:</t>
stered algorithm identifier are fully defined with all parameters (such as salt, <ul><li>Ensure that the algorithms referenced by a registered algorithm
hash, required key length, etc) fixed by the defining text. The DE is expected identifier are fully defined with all parameters (e.g., salt, hash, required key
to ensure that the algorithm definition fully specifies the <tt>HTTP_SIGN</tt> a length) fixed by the defining text.</li>
nd <tt>HTTP_VERIFY</tt> primitive functions, including how all defined inputs an <li>Ensure that the algorithm definition fully specifies the <tt>HTTP_SI
d outputs map to the underlying cryptographic algorithm. The DE is expected to r GN</tt> and <tt>HTTP_VERIFY</tt> primitive functions, including how all defined
eject any registrations that are aliases of existing registrations. The DE is ex inputs and outputs map to the underlying cryptographic algorithm.</li>
pected to ensure all registrations follow the template presented in <xref target <li>Reject any registrations that are aliases of existing registrations.
="iana-hsa-template"/>, including that the length of the name is not excessive w </li>
hile still being unique and recognizable.</t> <li>Ensure that all registrations follow the template presented in <xref
<t>This specification creates algorithm identifiers by including major p target="iana-hsa-template"/>; this includes ensuring that the length of the nam
arameters in the identifier string in order to make the algorithm name unique an e is not excessive while still being unique and recognizable.</li>
d recognizable by developers. However, algorithm identifiers in this registry ar </ul>
e to be interpreted as whole string values and not as a combination of parts. Th <t>This specification creates algorithm identifiers by including major p
at is to say, it is expected that implementors understand <tt>rsa-pss-sha512</tt arameters in the identifier String in order to make the algorithm name unique an
> as referring to one specific algorithm with its hash, mask, and salt values se d recognizable by developers. However, algorithm identifiers in this registry ar
t as defined in the defining text that establishes this identifier. Implementors e to be interpreted as whole String values and not as a combination of parts. Th
do not parse out the <tt>rsa</tt>, <tt>pss</tt>, and <tt>sha512</tt> portions o at is to say, it is expected that implementors understand <tt>rsa-pss-sha512</tt
f the identifier to determine parameters of the signing algorithm from the strin > as referring to one specific algorithm with its hash, mask, and salt values se
g, and the registry of one combination of parameters does not imply the registra t as defined in the defining text that establishes the identifier in question. I
tion of other combinations.</t> mplementors 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 fro
m the String, and the registration of one combination of parameters does not imp
ly the registration of other combinations.</t>
<section anchor="iana-hsa-template"> <section anchor="iana-hsa-template">
<name>Registration Template</name> <name>Registration Template</name>
<dl newline="true"> <dl newline="true">
<dt>Algorithm Name:</dt> <dt>Algorithm Name:</dt>
<dd> <dd>
<t>An identifier for the HTTP Signature Algorithm. The name <bcp14 >MUST</bcp14> be an ASCII string that conforms to the <tt>sf-string</tt> ABNF ru le in <xref section="3.3.3" sectionFormat="of" target="STRUCTURED-FIELDS"/> and <bcp14>SHOULD NOT</bcp14> exceed 20 characters in length. The identifier <bcp14> MUST</bcp14> be unique within the context of the registry.</t> <t>An identifier for the HTTP signature algorithm. The name <bcp14 >MUST</bcp14> be an ASCII string that conforms to the <tt>sf-string</tt> ABNF ru le in <xref section="3.3.3" sectionFormat="of" target="RFC8941"/> and <bcp14>SHO ULD NOT</bcp14> exceed 20 characters in length. The identifier <bcp14>MUST</bcp1 4> be unique within the context of the registry.</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>A brief description of the algorithm used to sign the signature base.</t> <t>A brief description of the algorithm used to sign the signature base.</t>
</dd> </dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd><t>The status of the algorithm. <bcp14>MUST</bcp14> start with
one of the following values and <bcp14>MAY</bcp14> contain additional explanato
ry text. The options are:</t>
<dl newline="false" spacing="normal">
<dt>"Active":</dt><dd>For algorithms without known problems. The signature al
gorithm is fully specified, and its security properties are understood.</dd>
<dt>"Provisional":</dt><dd>For unproven algorithms. The signature algorithm i
s fully specified, but its security properties are not known or proven.</dd>
<dt>"Deprecated":</dt><dd>For algorithms with known security issues. The sign
ature algorithm is no longer recommended for general use and might be insecure o
r unsafe in some known circumstances.</dd>
</dl>
</dd>
<dt>Reference:</dt>
<dd> <dd>
<t>The status of the algorithm. <bcp14>MUST</bcp14> start with one <t>Reference to the document or documents that specify the
of the following values and <bcp14>MAY</bcp14> contain additional explanatory t
ext. The options are:
- "Active": for algorithms without known problems. The signature algorithm is
fully specified and its security properties are understood.
- "Provisional": for unproven algorithms. The signature algorithm is fully spe
cified but its security properties are not known or proven.
- "Deprecated": for algorithms with know security issues. The signature algori
thm is no longer recommended for general use and might be insecure or unsafe in
some known circumstances.</t>
</dd>
<dt>Specification document(s):</dt>
<dd>
<t>Reference to the document(s) that specify the
algorithm, preferably including a URI that can be used algorithm, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required.</t> relevant sections may also be included but is not required.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-hsa-contents"> <section anchor="iana-hsa-contents">
<name>Initial Contents</name> <name>Initial Contents</name>
<t>The table below contains the initial contents of the "HTTP Signatur e Algorithms" registry.</t>
<table> <table>
<name>Initial contents of the HTTP Signature Algorithms Registry.</n ame> <name>Initial Contents of the HTTP Signature Algorithms Registry</na me>
<thead> <thead>
<tr> <tr>
<th align="left">Algorithm Name</th> <th align="left">Algorithm Name</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Status</th> <th align="left">Status</th>
<th align="left">Specification document(s)</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>rsa-pss-sha512</tt></td> <tt>rsa-pss-sha512</tt></td>
<td align="left">RSASSA-PSS using SHA-512</td> <td align="left">RSASSA-PSS using SHA-512</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left"> <td align="left">
<xref target="method-rsa-pss-sha512"/> of RFC nnnn</td> <xref target="method-rsa-pss-sha512"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>rsa-v1_5-sha256</tt></td> <tt>rsa-v1_5-sha256</tt></td>
<td align="left">RSASSA-PKCS1-v1_5 using SHA-256</td> <td align="left">RSASSA-PKCS1-v1_5 using SHA-256</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left"> <td align="left">
<xref target="method-rsa-v1_5-sha256"/> of RFC nnnn</td> <xref target="method-rsa-v1_5-sha256"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>hmac-sha256</tt></td> <tt>hmac-sha256</tt></td>
<td align="left">HMAC using SHA-256</td> <td align="left">HMAC using SHA-256</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left"> <td align="left">
<xref target="method-hmac-sha256"/> of RFC nnnn</td> <xref target="method-hmac-sha256"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>ecdsa-p256-sha256</tt></td> <tt>ecdsa-p256-sha256</tt></td>
<td align="left">ECDSA using curve P-256 DSS and SHA-256</td> <td align="left">ECDSA using curve P-256 DSS and SHA-256</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left"> <td align="left">
<xref target="method-ecdsa-p256-sha256"/> of RFC nnnn</td> <xref target="method-ecdsa-p256-sha256"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>ecdsa-p384-sha384</tt></td> <tt>ecdsa-p384-sha384</tt></td>
<td align="left">ECDSA using curve P-384 DSS and SHA-384</td> <td align="left">ECDSA using curve P-384 DSS and SHA-384</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left"> <td align="left">
<xref target="method-ecdsa-p384-sha384"/> of RFC nnnn</td> <xref target="method-ecdsa-p384-sha384"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>ed25519</tt></td> <tt>ed25519</tt></td>
<td align="left">Edwards Curve DSA using curve edwards25519</td> <td align="left">EdDSA using curve edwards25519</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left"> <td align="left">
<xref target="method-ed25519"/> of RFC nnnn</td> <xref target="method-ed25519"/> of RFC 9421</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="param-registry"> <section anchor="param-registry">
<name>HTTP Signature Metadata Parameters Registry</name> <name>HTTP Signature Metadata Parameters Registry</name>
<t>This document defines the signature parameters structure in <xref tar <t>This document defines the signature parameters structure (<xref targe
get="signature-params"/>, which may have parameters containing metadata about a t="signature-params"/>), which may have parameters containing metadata about a m
message signature. IANA is asked to create and maintain a new registry titled "H essage signature. IANA has created and now maintains a new registry titled "HTTP
TTP Signature Metadata Parameters" to record and maintain the set of parameters Signature Metadata Parameters" to record and maintain the set of parameters def
defined for use with member values in the signature parameters structure. Initia ined for use with member values in the signature parameters structure. Initial v
l values for this registry are given in <xref target="iana-param-contents"/>. Fu alues for this registry are given in <xref target="iana-param-contents"/>. Futur
ture assignments and modifications to existing assignments are to be made throug e assignments and modifications to existing assignments are to be made through t
h the Expert Review registration policy <xref target="RFC8126"/>.</t> he Expert Review registration policy <xref target="RFC8126"/>.</t>
<t>The DE is expected to ensure that the name follows the template prese <t>The DE is expected to do the following:</t>
nted in <xref target="iana-param-template"/>, including that the length of the n <ul><li>Ensure that the name follows the template presented in <xref tar
ame is not excessive while still being unique and recognizable for its defined f get="iana-param-template"/>; this includes ensuring that the length of the name
unction. The DE is expected to ensure that the defined functionality is clear an is not excessive while still being unique and recognizable for its defined funct
d does not conflict with other registered parameters. The DE is expected to ensu ion.</li>
re that the definition of the metadata parameter includes its behavior when used <li>Ensure that the defined functionality is clear and does not conflict
as part of the normal signature process as well as when used in an Accept-Signa with other registered parameters.</li>
ture field.</t> <li>Ensure that the definition of the metadata parameter includes its be
havior when used as part of the normal signature process as well as when used in
an Accept-Signature field.</li>
</ul>
<section anchor="iana-param-template"> <section anchor="iana-param-template">
<name>Registration Template</name> <name>Registration Template</name>
<dl newline="true"> <dl newline="true">
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>An identifier for the HTTP signature metadata parameter. The na me <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-FIE LDS"/> and <bcp14>SHOULD NOT</bcp14> exceed 20 characters in length. The identif ier <bcp14>MUST</bcp14> be unique within the context of the registry.</t> <t>An identifier for the HTTP signature metadata parameter. The na me <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="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> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>A brief description of the metadata parameter and what it repre sents.</t> <t>A brief description of the metadata parameter and what it repre sents.</t>
</dd> </dd>
<dt>Specification document(s):</dt> <dt>Reference:</dt>
<dd> <dd>
<t>Reference to the document(s) that specify the <t>Reference to the document or documents that specify the
parameter, preferably including a URI that can be used parameter, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required.</t> relevant sections may also be included but is not required.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-param-contents"> <section anchor="iana-param-contents">
<name>Initial Contents</name> <name>Initial Contents</name>
<t>The table below contains the initial contents of the HTTP Signature Metadata Parameters Registry. Each row in the table represents a distinct entry in the registry.</t> <t>The table below contains the initial contents of the "HTTP Signatur e Metadata Parameters" registry. Each row in the table represents a distinct ent ry in the registry.</t>
<table> <table>
<name>Initial contents of the HTTP Signature Metadata Parameters Reg istry.</name> <name>Initial Contents of the HTTP Signature Metadata Parameters Reg istry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Specification document(s)</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>alg</tt></td> <tt>alg</tt></td>
<td align="left">Explicitly declared signature algorithm</td> <td align="left">Explicitly declared signature algorithm</td>
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>created</tt></td> <tt>created</tt></td>
<td align="left">Timestamp of signature creation</td> <td align="left">Timestamp of signature creation</td>
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>expires</tt></td> <tt>expires</tt></td>
<td align="left">Timestamp of proposed signature expiration</td> <td align="left">Timestamp of proposed signature expiration</td>
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>keyid</tt></td> <tt>keyid</tt></td>
<td align="left">Key identifier for the signing and verification keys used to create this signature</td> <td align="left">Key identifier for the signing and verification keys used to create this signature</td>
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>nonce</tt></td> <tt>nonce</tt></td>
<td align="left">A single-use nonce value</td> <td align="left">A single-use nonce value</td>
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>tag</tt></td> <tt>tag</tt></td>
<td align="left">An application-specific tag for a signature</td > <td align="left">An application-specific tag for a signature</td >
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="content-registry"> <section anchor="content-registry">
<name>HTTP Signature Derived Component Names Registry</name> <name>HTTP Signature Derived Component Names Registry</name>
<t>This document defines a method for canonicalizing HTTP message compon <t>This document defines a method for canonicalizing HTTP message compon
ents, including components that can be derived from the context of the target me ents, including components that can be derived from the context of the target me
ssage outside of the HTTP fields. These derived components are identified by a u ssage outside of the HTTP fields. These derived components are identified by a u
nique string, known as the component name. Component names for derived component nique String, known as the component name. Component names for derived component
s always start with the "@" (at) symbol to distinguish them from HTTP field name s always start with the "at" (@) symbol to distinguish them from HTTP field name
s. IANA is asked to create and maintain a new registry typed "HTTP Signature Der s. IANA has created and now maintains a new registry titled "HTTP Signature Deri
ived Component Names" to record and maintain the set of non-field component name ved Component Names" to record and maintain the set of non-field component names
s and the methods to produce their associated component values. Initial values f and the methods used to produce their associated component values. Initial valu
or this registry are given in <xref target="iana-content-contents"/>. Future ass es for this registry are given in <xref target="iana-content-contents"/>. Future
ignments and modifications to existing assignments are to be made through the Ex assignments and modifications to existing assignments are to be made through th
pert Review registration policy <xref target="RFC8126"/>.</t> e Expert Review registration policy <xref target="RFC8126"/>.</t>
<t>The DE is expected to ensure that the name follows the template prese <t>The DE is expected to do the following:</t>
nted in <xref target="iana-content-template"/>, including that the length of the <ul><li>Ensure that the name follows the template presented in <xref tar
name is not excessive while still being unique and recognizable for its defined get="iana-content-template"/>; this includes ensuring that the length of the nam
function. The DE is expected to ensure that the component value represented by e is not excessive while still being unique and recognizable for its defined fun
the registration request can be deterministically derived from the target HTTP m ction.</li>
essage. The DE is expected to ensure that any parameters defined for the registr <li>Ensure that the component value represented by the registration requ
ation request are clearly documented, along with their effects on the component est can be deterministically derived from the target HTTP message.</li>
value. The DE should also ensure that the registration request is not sufficient <li>Ensure that any parameters defined for the registration request are
ly distinct from existing derived component definitions to warrant its registrat clearly documented, along with their effects on the component value.</li>
ion. When setting a registered item's status to "Deprecated", the DE should ensu </ul>
re that a reason for the deprecation is documented, along with instructions for <t>The DE should ensure that a registration is sufficiently distinct from existi
moving away from the deprecated functionality.</t> ng derived component definitions to warrant its 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 mo
ving away from the deprecated functionality.</t>
<section anchor="iana-content-template"> <section anchor="iana-content-template">
<name>Registration Template</name> <name>Registration Template</name>
<dl newline="true"> <dl newline="true">
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>A name for the HTTP derived component. The name <bcp14>MUST</bc p14> begin with the <tt>"@"</tt> character followed by an ASCII string consistin g only of lower-case characters (<tt>"a"</tt> - <tt>"z"</tt>), digits (<tt>"0"</ tt> - <tt>"9"</tt>), and hyphens (<tt>"-"</tt>), and <bcp14>SHOULD NOT</bcp14> e xceed 20 characters in length. The name <bcp14>MUST</bcp14> be unique within the context of the registry.</t> <t>A name for the HTTP derived component. The name <bcp14>MUST</bc p14> begin with the "at" (<tt>@</tt>) character followed by an ASCII string cons isting only of lowercase characters (<tt>"a"</tt>-<tt>"z"</tt>), digits (<tt>"0" </tt>-<tt>"9"</tt>), and hyphens (<tt>"-"</tt>), and <bcp14>SHOULD NOT</bcp14> e xceed 20 characters in length. The name <bcp14>MUST</bcp14> be unique within the context of the registry.</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>A description of the derived component.</t> <t>A description of the derived component.</t>
</dd> </dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>
<t>A brief text description of the status of the algorithm. The de scription <bcp14>MUST</bcp14> begin with one of "Active" or "Deprecated", and <b cp14>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> <t>A brief text description of the status of the algorithm. The de scription <bcp14>MUST</bcp14> begin with one of "Active" or "Deprecated" and <bc p14>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> </dd>
<dt>Target:</dt> <dt>Target:</dt>
<dd> <dd>
<t>The valid message targets for the derived parameter. <bcp14>MUS T</bcp14> be one of the values "Request", "Response", or "Request, Response". Th e semantics of these are defined in <xref target="derived-components"/>.</t> <t>The valid message targets for the derived parameter. <bcp14>MUS T</bcp14> be one of the values "Request", "Response", or "Request, Response". Th e semantics of these entries are defined in <xref target="derived-components"/>. </t>
</dd> </dd>
<dt>Specification document(s):</dt> <dt>Reference:</dt>
<dd> <dd>
<t>Reference to the document(s) that specify the <t>Reference to the document or documents that specify the
derived component, preferably including a URI that can be used derived component, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required.</t> relevant sections may also be included but is not required.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-content-contents"> <section anchor="iana-content-contents">
<name>Initial Contents</name> <name>Initial Contents</name>
<t>The table below contains the initial contents of the HTTP Signature Derived Component Names Registry.</t> <t>The table below contains the initial contents of the "HTTP Signatur e Derived Component Names" registry.</t>
<table> <table>
<name>Initial contents of the HTTP Signature Derived Component Names Registry.</name> <name>Initial Contents of the HTTP Signature Derived Component Names Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Status</th> <th align="left">Status</th>
<th align="left">Target</th> <th align="left">Target</th>
<th align="left">Specification document(s)</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@signature-params</tt></td> <tt>@signature-params</tt></td>
<td align="left">Reserved for signature parameters line in signa ture base</td> <td align="left">Reserved for signature parameters line in signa ture base</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request, Response</td> <td align="left">Request, Response</td>
<td align="left"> <td align="left">
<xref target="signature-params"/> of RFC nnnn</td> <xref target="signature-params"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@method</tt></td> <tt>@method</tt></td>
<td align="left">The HTTP request method</td> <td align="left">The HTTP request method</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-method"/> of RFC nnnn</td> <xref target="content-request-method"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@authority</tt></td> <tt>@authority</tt></td>
<td align="left">The HTTP authority, or target host</td> <td align="left">The HTTP authority, or target host</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-authority"/> of RFC nnnn</td> <xref target="content-request-authority"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@scheme</tt></td> <tt>@scheme</tt></td>
<td align="left">The URI scheme of the request URI</td> <td align="left">The URI scheme of the request URI</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-scheme"/> of RFC nnnn</td> <xref target="content-request-scheme"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@target-uri</tt></td> <tt>@target-uri</tt></td>
<td align="left">The full target URI of the request</td> <td align="left">The full target URI of the request</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-target-uri"/> of RFC nnnn</td> <xref target="content-target-uri"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@request-target</tt></td> <tt>@request-target</tt></td>
<td align="left">The request target of the request</td> <td align="left">The request target of the request</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-target"/> of RFC nnnn</td> <xref target="content-request-target"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@path</tt></td> <tt>@path</tt></td>
<td align="left">The full path of the request URI</td> <td align="left">The full path of the request URI</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-path"/> of RFC nnnn</td> <xref target="content-request-path"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@query</tt></td> <tt>@query</tt></td>
<td align="left">The full query of the request URI</td> <td align="left">The full query of the request URI</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-query"/> of RFC nnnn</td> <xref target="content-request-query"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@query-param</tt></td> <tt>@query-param</tt></td>
<td align="left">A single named query parameter</td> <td align="left">A single named query parameter</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Request</td> <td align="left">Request</td>
<td align="left"> <td align="left">
<xref target="content-request-query-param"/> of RFC nnnn</td> <xref target="content-request-query-param"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>@status</tt></td> <tt>@status</tt></td>
<td align="left">The status code of the response</td> <td align="left">The status code of the response</td>
<td align="left">Active</td> <td align="left">Active</td>
<td align="left">Response</td> <td align="left">Response</td>
<td align="left"> <td align="left">
<xref target="content-status-code"/> of RFC nnnn</td> <xref target="content-status-code"/> of RFC 9421</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="component-param-registry"> <section anchor="component-param-registry">
<name>HTTP Signature Component Parameters Registry</name> <name>HTTP Signature Component Parameters Registry</name>
<t>This document defines several kinds of component identifiers, some of <t>This document defines several kinds of component identifiers, some of
which can be parameterized in specific circumstances to provide unique modified which can be parameterized in specific circumstances to provide unique modified
behavior. IANA is asked to create and maintain a new registry typed "HTTP Signa behavior. IANA has created and now maintains a new registry titled "HTTP Signat
ture Component Parameters" to record and maintain the set of parameters names, t ure Component Parameters" to record and maintain the set of parameter names, the
he component identifiers they are associated with, and the modifications these p component identifiers they are associated with, and the modifications these par
arameters make to the component value. Definitions of parameters <bcp14>MUST</bc ameters make to the component value. Definitions of parameters <bcp14>MUST</bcp1
p14> define the targets to which they apply (such as specific field types, deriv 4> define the targets to which they apply (such as specific field types, derived
ed components, or contexts). Initial values for this registry are given in <xref components, or contexts). Initial values for this registry are given in <xref t
target="iana-component-param-contents"/>. Future assignments and modifications arget="iana-component-param-contents"/>. Future assignments and modifications to
to existing assignments are to be made through the Expert Review registration po existing assignments are to be made through the Expert Review registration poli
licy <xref target="RFC8126"/>.</t> cy <xref target="RFC8126"/>.</t>
<t>The DE is expected to ensure that the name follows the template prese <t>The DE is expected to do the following:</t>
nted in <xref target="iana-component-param-template"/>, including that the lengt <ul><li>Ensure that the name follows the template presented in <xref tar
h of the name is not excessive while still being unique and recognizable for its get="iana-component-param-template"/>; this includes ensuring that the length of
defined function. The DE is expected to ensure that the definition of the field the name is not excessive while still being unique and recognizable for its def
sufficiently defines any interactions incompatibilities with other existing par ined function.</li>
ameters known at the time of the registration request. If the parameter changes <li>Ensure that the definition of the field sufficiently defines any int
the component value, the DE is expected to ensure that the component value defin eractions or incompatibilities with other existing parameters known at the time
ed by the component identifier with the parameter applied can be deterministical of the registration request.</li>
ly derived from the target HTTP message.</t> <li>Ensure that the component value defined by the component identifier
with the parameter applied can be deterministically derived from the target HTTP
message in cases where the parameter changes the component value.</li>
</ul>
<section anchor="iana-component-param-template"> <section anchor="iana-component-param-template">
<name>Registration Template</name> <name>Registration Template</name>
<dl newline="true"> <dl newline="true">
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>A name for the parameter. The name <bcp14>MUST</bcp14> be an AS CII string that conforms to the <tt>key</tt> ABNF rule defined in <xref section= "3.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/> and <bcp14>SHOULD NOT</b cp14> exceed 20 characters in length. The name <bcp14>MUST</bcp14> be unique wit hin the context of the registry.</t> <t>A name for the parameter. The name <bcp14>MUST</bcp14> be an AS CII string that conforms to the <tt>key</tt> ABNF rule defined in <xref section= "3.1.2" sectionFormat="of" target="RFC8941"/> and <bcp14>SHOULD NOT</bcp14> exce ed 20 characters in length. The name <bcp14>MUST</bcp14> be unique within the co ntext of the registry.</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>A description of the parameter's function.</t> <t>A description of the parameter's function.</t>
</dd> </dd>
<dt>Specification document(s):</dt> <dt>Reference:</dt>
<dd> <dd>
<t>Reference to the document(s) that specify the <t>Reference to the document or documents that specify the
derived component, preferably including a URI that can be used derived component, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required.</t> relevant sections may also be included but is not required.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-component-param-contents"> <section anchor="iana-component-param-contents">
<name>Initial Contents</name> <name>Initial Contents</name>
<t>The table below contains the initial contents of the HTTP Signature
Derived Component Names Registry.</t> <t>The table below contains the initial contents of the "HTTP Signatur
e Component Parameters" registry.</t>
<table> <table>
<name>Initial contents of the HTTP Signature Component Parameters Re gistry.</name> <name>Initial Contents of the HTTP Signature Component Parameters Re gistry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Specification document(s)</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>sf</tt></td> <tt>sf</tt></td>
<td align="left">Strict structured field serialization</td> <td align="left">Strict Structured Field serialization</td>
<td align="left"> <td align="left">
<xref target="http-field-structured"/> of RFC nnnn</td> <xref target="http-field-structured"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>key</tt></td> <tt>key</tt></td>
<td align="left">Single key value of dictionary structured field s</td> <td align="left">Single key value of Dictionary Structured Field s</td>
<td align="left"> <td align="left">
<xref target="http-field-dictionary"/> of RFC nnnn</td> <xref target="http-field-dictionary"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>bs</tt></td> <tt>bs</tt></td>
<td align="left">Byte Sequence wrapping indicator</td> <td align="left">Byte Sequence wrapping indicator</td>
<td align="left"> <td align="left">
<xref target="http-field-byte-sequence"/> of RFC nnnn</td> <xref target="http-field-byte-sequence"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>tr</tt></td> <tt>tr</tt></td>
<td align="left">Trailer</td> <td align="left">Trailer</td>
<td align="left"> <td align="left">
<xref target="http-trailer"/> of RFC nnnn</td> <xref target="http-trailer"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>req</tt></td> <tt>req</tt></td>
<td align="left">Related request indicator</td> <td align="left">Related request indicator</td>
<td align="left"> <td align="left">
<xref target="content-request-scheme"/> of RFC nnnn</td> <xref target="content-request-response"/> of RFC 9421</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>name</tt></td> <tt>name</tt></td>
<td align="left">Single named query parameter</td> <td align="left">Single named query parameter</td>
<td align="left"> <td align="left">
<xref target="content-request-query-param"/> of RFC nnnn</td> <xref target="content-request-query-param"/> of RFC 9421</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>In order for an HTTP message to be considered <em>covered</em> by a sig nature, all of the following conditions have to be true:</t> <t>In order for an HTTP message to be considered <em>covered</em> by a sig nature, all of the following conditions have to be true:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a signature is expected or allowed on the message by the verifier</l <li>A signature is expected or allowed on the message by the verifier.</
i> li>
<li>the signature exists on the message</li> <li>The signature exists on the message.</li>
<li>the signature is verified against the identified key material and al <li>The signature is verified against the identified key material and al
gorithm</li> gorithm.</li>
<li>the key material and algorithm are appropriate for the context of th <li>The key material and algorithm are appropriate for the context of th
e message</li> e message.</li>
<li>the signature is within expected time boundaries</li> <li>The signature is within expected time boundaries.</li>
<li>the signature covers the expected content, including any critical co <li>The signature covers the expected content, including any critical co
mponents</li> mponents.</li>
<li>the list of covered components is applicable to the context of the m <li>The list of covered components is applicable to the context of the m
essage</li> essage.</li>
</ul> </ul>
<t>In addition to the application requirement definitions listed in <xref target="application"/>, the following security considerations provide discussion and context to the requirements of creating and verifying signatures on HTTP me ssages.</t> <t>In addition to the application requirement definitions listed in <xref target="application"/>, the following security considerations provide discussion and context regarding the requirements of creating and verifying signatures on HTTP messages.</t>
<section anchor="general-considerations"> <section anchor="general-considerations">
<name>General Considerations</name> <name>General Considerations</name>
<section anchor="security-ignore"> <section anchor="security-ignore">
<name>Skipping Signature Verification</name> <name>Skipping Signature Verification</name>
<t>HTTP Message Signatures only provide security if the signature is v <t>HTTP message signatures only provide security if the signature is v
erified by the verifier. Since the message to which the signature is attached re erified by the verifier. Since the message to which the signature is attached re
mains a valid HTTP message without the signature fields, it is possible for a ve mains a valid HTTP message without the Signature or Signature-Input fields, it i
rifier to ignore the output of the verification function and still process the m s possible for a verifier to ignore the output of the verification function and
essage. Common reasons for this could be relaxed requirements in a development e still process the message. Common reasons for this could be relaxed requirements
nvironment or a temporary suspension of enforcing verification during debugging in a development environment or a temporary suspension of enforcing verificatio
an overall system. Such temporary suspensions are difficult to detect under posi n while debugging an overall system. Such temporary suspensions are difficult to
tive-example testing since a good signature will always trigger a valid response detect under positive-example testing, since a good signature will always trigg
whether or not it has been checked.</t> er a valid response whether or not it has been checked.</t>
<t>To detect this, verifiers should be tested using both valid and inv <t>To detect this, verifiers should be tested using both valid and inv
alid signatures, ensuring that the invalid signature fails as expected.</t> alid signatures, ensuring that an invalid signature fails as expected.</t>
</section> </section>
<section anchor="security-tls"> <section anchor="security-tls">
<name>Use of TLS</name> <name>Use of TLS</name>
<t>The use of HTTP Message Signatures does not negate the need for TLS <t>The use of HTTP message signatures does not negate the need for TLS
or its equivalent to protect information in transit. Message signatures provide or its equivalent to protect information in transit. Message signatures provide
message integrity over the covered message components but do not provide any co message integrity over the covered message components but do not provide any co
nfidentiality for the communication between parties.</t> nfidentiality for communication between parties.</t>
<t>TLS provides such confidentiality between the TLS endpoints. As par <t>TLS provides such confidentiality between the TLS endpoints. As par
t of this, TLS also protects the signature data itself from being captured by an t of this, TLS also protects the signature data itself from being captured by an
attacker, which is an important step in preventing <xref target="security-repla attacker. This is an important step in preventing <xref target="security-repla
y">signature replay</xref>.</t> y">signature replay</xref>.</t>
<t>When TLS is used, it needs to be deployed according to the recommen <t>When TLS is used, it needs to be deployed according to the recommen
dations in <xref target="BCP195"/>.</t> dations provided in <xref target="BCP195"/>.</t>
</section> </section>
</section> </section>
<section anchor="message-processing-and-selection"> <section anchor="message-processing-and-selection">
<name>Message Processing and Selection</name> <name>Message Processing and Selection</name>
<section anchor="security-coverage"> <section anchor="security-coverage">
<name>Insufficient Coverage</name> <name>Insufficient Coverage</name>
<t>Any portions of the message not covered by the signature are suscep tible to modification by an attacker without affecting the signature. An attacke r 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 b e covered by the signature. Such an altered message would still pass signature v erification, but when the verifier processes the message as a whole, the unsigne d content injected by the attacker would subvert the trust conveyed by the valid signature and change the outcome of processing the message.</t> <t>Any portions of the message not covered by the signature are suscep tible to modification by an attacker without affecting the signature. An attacke r 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 b e covered by the signature. Such an altered message would still pass signature v erification, but when the verifier processes the message as a whole, the unsigne d 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 appli cation and deployment. The verifier should only trust message components that ha ve been signed. Verifiers could also strip out any sensitive unsigned portions o f the message before processing of the message continues.</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 appli cation and deployment. The verifier should only trust message components that ha ve been signed. Verifiers could also strip out any sensitive unsigned portions o f the message before processing of the message continues.</t>
</section> </section>
<section anchor="security-replay"> <section anchor="security-replay">
<name>Signature Replay</name> <name>Signature Replay</name>
<t>Since HTTP Message Signatures allows sub-portions of the HTTP messa ge to be signed, it is possible for two different HTTP messages to validate agai nst 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 replaye d at will by an attacker, attached to any HTTP message. Even with sufficient com ponent 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>Since HTTP message signatures allow sub-portions of the HTTP messag e to be signed, it is possible for two different HTTP messages to validate again st the same signature. The most extreme form of this would be a signature over n o 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 comp onent 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 othe r messages. In addition, the signature can use the <tt>nonce</tt> signature para meter to provide a per-message unique value to allow the verifier to detect repl ay 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 capt ured signature value.</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 othe r messages. In addition, the signature can use the <tt>nonce</tt> signature para meter to provide a per-message unique value to allow the verifier to detect repl ay 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 capt ured signature value.</t>
<t>If a verifier wants to trigger a new signature from a signer, it ca n send the <tt>Accept-Signature</tt> header field with a new <tt>nonce</tt> para meter. An attacker that is simply replaying a signature would not be able to gen erate a new signature with the chosen nonce value.</t> <t>If a verifier wants to trigger a new signature from a signer, it ca n send the 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 n ew signature with the chosen nonce value.</t>
</section> </section>
<section anchor="security-components"> <section anchor="security-components">
<name>Choosing Message Components</name> <name>Choosing Message Components</name>
<t>Applications of HTTP Message Signatures need to decide which messag <t>Applications of HTTP message signatures need to decide which messag
e components will be covered by the signature. Depending on the application, som e components will be covered by the signature. Depending on the application, som
e components could be expected to be changed by intermediaries prior to the sign e components could be expected to be changed by intermediaries prior to the sign
ature's verification. If these components are covered, such changes would, by de ature's verification. If these components are covered, such changes would, by de
sign, break the signature.</t> sign, break the signature.</t>
<t>However, the HTTP Message Signature standard allows for flexibility <t>However, this document allows for flexibility in determining which
in determining which components are signed precisely so that a given applicatio components are signed precisely so that a given application can choose the appro
n can choose the appropriate portions of the message that need to be signed, avo priate portions of the message that need to be signed, avoiding problematic comp
iding problematic components. For example, a web application framework that reli onents. For example, a web application framework that relies on rewriting query
es on rewriting query parameters might avoid use of the <tt>@query</tt> derived parameters might avoid using the <tt>@query</tt> derived component in favor of s
component in favor of sub-indexing the query value using <tt>@query-param</tt> d ub-indexing the query value using <tt>@query-param</tt> derived components inste
erived components instead.</t> ad.</t>
<t>Some components are expected to be changed by intermediaries and ou <t>Some components are expected to be changed by intermediaries and ou
ght not to be signed under most circumstance. The <tt>Via</tt> and <tt>Forwarded ght not to be signed under most circumstances. The Via and Forwarded header fiel
</tt> header fields, for example, are expected to be manipulated by proxies and ds, for example, are expected to be manipulated by proxies and other middleboxes
other middle-boxes, including replacing or entirely dropping existing values. Th , including replacing or entirely dropping existing values. These fields should
ese fields should not be covered by the signature except in very limited and tig not be covered by the signature, except in very limited and tightly coupled scen
htly-coupled scenarios.</t> arios.</t>
<t>Additional considerations for choosing signature aspects are discus sed in <xref target="application"/>.</t> <t>Additional considerations for choosing signature aspects are discus sed in <xref target="application"/>.</t>
</section> </section>
<section anchor="security-not-fields"> <section anchor="security-not-fields">
<name>Choosing Signature Parameters and Derived Components over HTTP F ields</name> <name>Choosing Signature Parameters and Derived Components over HTTP F ields</name>
<t>Some HTTP fields have values and interpretations that are similar t o HTTP signature parameters or derived components. In most cases, it is more des irable to sign the non-field alternative. In particular, the following fields sh ould usually not be included in the signature unless the application specificall y requires it:</t> <t>Some HTTP fields have values and interpretations that are similar t o HTTP signature parameters or derived components. In most cases, it is more des irable to sign the non-field alternative. In particular, the following fields sh ould usually not be included in the signature unless the application specificall y requires it:</t>
<dl> <dl>
<dt>"date"</dt> <dt>"date"</dt>
<dd> <dd>
<t>The "date" field value represents the timestamp of the HTTP mes sage. However, the creation time of the signature itself is encoded in the <tt>c reated</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> si gnature parameter for such calculations. An application could also put limits on how much skew there is between the "date" field and the <tt>created</tt> signat ure parameter, in order to limit the application of a generated signature to dif ferent HTTP messages. See also <xref target="security-replay"/> and <xref target ="security-coverage"/>.</t> <t>The Date header field value represents the timestamp of the HTT P message. However, the creation time of the signature itself is encoded in the <tt>created</tt> signature parameter. These two values can be different, dependi ng on how the signature and the HTTP message are created and serialized. Applica tions processing signatures for valid time windows should use the <tt>created</t t> signature parameter for such calculations. An application could also put limi ts on how much skew there is between the Date field and the <tt>created</tt> sig nature parameter, in order to limit the application of a generated signature to different HTTP messages. See also Sections&nbsp;<xref target="security-replay" f ormat="counter"/> and <xref target="security-coverage" format="counter"/>.</t>
</dd> </dd>
<dt>"host"</dt> <dt>"host"</dt>
<dd> <dd>
<t>The "host" header field is specific to HTTP/1.1, and its functi onality is subsumed by the "@authority" derived component, defined in <xref targ et="content-request-authority"/>. In order to preserve the value across differen t HTTP versions, applications should always use the "@authority" derived compone nt. See also <xref target="security-versions"/>.</t> <t>The Host header field is specific to HTTP/1.1, and its function ality is subsumed by the <tt>@authority</tt> derived component, defined in <xref target="content-request-authority"/>. In order to preserve the value across dif ferent HTTP versions, applications should always use the <tt>@authority</tt> der ived component. See also <xref target="security-versions"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="security-labels"> <section anchor="security-labels">
<name>Signature Labels</name> <name>Signature Labels</name>
<t>HTTP Message Signature values are identified in the Signature and S <t>HTTP message signature values are identified in the Signature and S
ignature-Input field values by unique labels. These labels are chosen only when ignature-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 the s attaching the signature values to the message and are not accounted for during t
igning process. An intermediary is allowed to re-label an existing signature whe he signing process. An intermediary is allowed to relabel an existing signature
n processing the message.</t> when processing the message.</t>
<t>Therefore, applications should not rely on specific labels being pr <t>Therefore, applications should not rely on specific labels being pr
esent, and applications should not put semantic meaning on the labels themselves esent, and applications should not put semantic meaning on the labels themselves
. Instead, additional signature parameters can be used to convey whatever additi . Instead, additional signature parameters can be used to convey whatever additi
onal meaning is required to be attached to and covered by the signature. In part onal meaning is required to be attached to, and covered by, the signature. In pa
icular, the <tt>tag</tt> parameter can be used to define an application-specific rticular, the <tt>tag</tt> parameter can be used to define an application-specif
value as described in <xref target="security-signature-tag"/>.</t> ic value as described in <xref target="security-signature-tag"/>.</t>
</section> </section>
<section anchor="security-multiple"> <section anchor="security-multiple">
<name>Multiple Signature Confusion</name> <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 ow n signature to a captured message without modifying existing signatures. This ne w signature could be completely valid based on the attacker's key, or it could b e an invalid signature for any number of reasons. Each of these situations need to be accounted for.</t> <t>Since <xref target="signature-multiple">multiple signatures can be applied to one message</xref>, it is possible for an attacker to attach their ow n signature to a captured message without modifying existing signatures. This ne w signature could be completely valid based on the attacker's key, or it could b e an invalid signature for any number of reasons. Each of these situations needs to be accounted for.</t>
<t>A verifier processing a set of valid signatures needs to account fo r all of the signers, identified by the signing keys. Only signatures from expec ted signers should be accepted, regardless of the cryptographic validity of the signature itself.</t> <t>A verifier processing a set of valid signatures needs to account fo r all of the signers, identified by the signing keys. Only signatures from expec ted 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 t o determine what to do when one or more of the signatures are not valid. If a me ssage is accepted when at least one signature is valid, then a verifier could dr op all invalid signatures from the request before processing the message further . Alternatively, if the verifier rejects a message for a single invalid signatur e, an attacker could use this to deny service to otherwise valid messages by inj ecting invalid signatures alongside the valid ones.</t> <t>A verifier processing a set of signatures on a message also needs t o determine what to do when one or more of the signatures are not valid. If a me ssage is accepted when at least one signature is valid, then a verifier could dr op all invalid signatures from the request before processing the message further . Alternatively, if the verifier rejects a message for a single invalid signatur e, an attacker could use this to deny service to otherwise valid messages by inj ecting invalid signatures alongside the valid signatures.</t>
</section> </section>
<section anchor="security-signature-tag"> <section anchor="security-signature-tag">
<name>Collision of Application-Specific Signature Tag</name> <name>Collision of Application-Specific Signature Tag</name>
<t>Multiple applications and protocols could apply HTTP signatures on <t>Multiple applications and protocols could apply HTTP signatures on
the same message simultaneously. In fact, this is a desired feature in many circ the same message simultaneously. In fact, this is a desired feature in many circ
umstances as described in <xref target="signature-multiple"/>. A naive verifier umstances; see <xref target="signature-multiple"/>. A naive verifier could becom
could become confused in processing multiple signatures, either accepting or rej e confused while processing multiple signatures, either accepting or rejecting a
ecting a message based on an unrelated or irrelevant signature. In order to help message based on an unrelated or irrelevant signature. In order to help an appl
an application select which signatures apply to its own processing, the applica ication select which signatures apply to its own processing, the application can
tion can declare a specific value for the <tt>tag</tt> signature parameter as de declare a specific value for the <tt>tag</tt> signature parameter as defined in
fined in <xref target="signature-params"/>. For example, a signature targeting a <xref target="signature-params"/>. For example, a signature targeting an applic
n application gateway could require <tt>tag="app-gateway"</tt> as part of the si ation gateway could require <tt>tag="app-gateway"</tt> as part of the signature
gnature parameters for that application.</t> parameters for that application.</t>
<t>The use of the <tt>tag</tt> parameter does not prevent an attacker <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 va from also using the same value as a target application, since the parameter's va
lue is public and otherwise unrestricted. As a consequence, a verifier should on lue is public and otherwise unrestricted. As a consequence, a verifier should on
ly use value of the <tt>tag</tt> parameter to limit which signatures to check. E ly use a value of the <tt>tag</tt> parameter to limit which signatures to check.
ach signature still needs to be examined by the verifier to ensure that sufficie Each signature still needs to be examined by the verifier to ensure that suffic
nt coverage is provided, as discussed in <xref target="security-coverage"/>.</t> ient coverage is provided, as discussed in <xref target="security-coverage"/>.</
t>
</section> </section>
<section anchor="security-message-content"> <section anchor="security-message-content">
<name>Message Content</name> <name>Message Content</name>
<t>On its own, this specification does not provide coverage for the co ntent of an HTTP message under the signature, either in request or response. How ever, <xref target="DIGEST"/> defines a set of fields that allow a cryptographic digest of the content to be represented in a field. Once this field is created, it can be included just like any other field as defined in <xref target="http-f ields"/>.</t> <t>On its own, this specification does not provide coverage for the co ntent of an HTTP message under the signature, in either a request or a response. However, <xref target="RFC9530"/> defines a set of fields that allow a cryptogr aphic digest of the content to be represented in a field. Once this field is cre ated, it can be included just like any other field as defined in <xref target="h ttp-fields"/>.</t>
<t>For example, in the following response message:</t> <t>For example, in the following response message:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>The digest of the content can be added to the Content-Digest field as follows:</t> <t>The digest of the content can be added to the Content-Digest field as follows:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
skipping to change at line 2029 skipping to change at line 2068
]]></sourcecode> ]]></sourcecode>
<t>This field can be included in a signature base just like any other field along with the basic signature parameters:</t> <t>This field can be included in a signature base just like any other field along with the basic signature parameters:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@status": 200 "@status": 200
"content-digest": \ "content-digest": \
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
"@signature-input": ("@status" "content-digest") "@signature-input": ("@status" "content-digest")
]]></artwork> ]]></artwork>
<t>From here, the signing process proceeds as usual.</t> <t>From here, the signing process proceeds as usual.</t>
<t>Upon verification, it is important that the verifier validate not o nly 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 Conten t-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 suffic ient protection against such a substitution attack.</t> <t>Upon verification, it is important that the verifier validate not o nly 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 Conten t-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 suffic ient protection against such a substitution attack.</t>
<t>As discussed in <xref target="DIGEST"/>, the value of the Content-D
igest field is dependent on the content encoding of the message. If an intermedi <t>As discussed in <xref target="RFC9530"/>, the value of the Content-
ary changes the content encoding, the resulting Content-Digest value would chang Digest field is dependent on the content encoding of the message. If an intermed
e, which would in turn invalidate the signature. Any intermediary performing suc iary changes the content encoding, the resulting Content-Digest value would chan
h an action would need to apply a new signature with the updated Content-Digest ge. This would in turn invalidate the signature. Any intermediary performing suc
field value, similar to the reverse proxy use case discussed in <xref target="si h an action would need to apply a new signature with the updated Content-Digest
gnature-multiple"/>.</t> field value, similar to the reverse proxy use case discussed in <xref target="si
<t>Applications that make use of the <xref target="content-request-res gnature-multiple"/>.</t>
ponse">request-response parameter</xref> also need to be aware of the limitation <t>Applications that make use of the <xref target="content-request-res
s in this functionality. Specifically, if a client does not include something li ponse"><tt>req</tt> parameter</xref> also need to be aware of the limitations of
ke a Content-Digest header field in the request, the server is unable to include this functionality. Specifically, if a client does not include something like a
a signature that covers the request's content.</t> Content-Digest header field in the request, the server is unable to include a s
ignature that covers the request's content.</t>
</section> </section>
</section> </section>
<section anchor="cryptographic-considerations"> <section anchor="cryptographic-considerations">
<name>Cryptographic Considerations</name> <name>Cryptographic Considerations</name>
<section anchor="security-collision"> <section anchor="security-collision">
<name>Cryptography and Signature Collision</name> <name>Cryptography and Signature Collision</name>
<t>The HTTP Message Signatures specification does not define any of it <t>This document does not define any of its own cryptographic primitiv
s own cryptographic primitives, and instead relies on other specifications to de es and instead relies on other specifications to define such elements. If the si
fine such elements. If the signature algorithm or key used to process the signat gnature algorithm or key used to process the signature base is vulnerable to any
ure base is vulnerable to any attacks, the resulting signature will also be susc attacks, the resulting signature will also be susceptible to these same attacks
eptible to these same attacks.</t> .</t>
<t>A common attack against signature systems is to force a signature c <t>A common attack against signature systems is to force a signature c
ollision, where the same signature value successfully verifies against multiple ollision, where the same signature value successfully verifies against multiple
different inputs. Since this specification relies on reconstruction of the signa different inputs. Since this specification relies on reconstruction of the signa
ture base from an HTTP message, and the list of components signed is fixed in th ture base from an HTTP message and the list of components signed is fixed in the
e signature, it is difficult but not impossible for an attacker to effect such a 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 covere collision. An attacker would need to manipulate the HTTP message and its covered
d message components in order to make the collision effective.</t> message components in order to make the collision effective.</t>
<t>To counter this, only vetted keys and signature algorithms should b <t>To counter this, only vetted keys and signature algorithms should b
e used to sign HTTP messages. The HTTP Message Signatures Algorithm Registry is e used to sign HTTP messages. The "HTTP Signature Algorithms" registry is one so
one source of trusted signature algorithms for applications to apply to their me urce of trusted signature algorithms for applications to apply to their messages
ssages.</t> .</t>
<t>While it is possible for an attacker to substitute the signature pa <t>While it is possible for an attacker to substitute the signature pa
rameters value or the signature value separately, the <xref target="create-sig-i rameters value or the signature value separately, the <xref target="create-sig-i
nput">signature base generation algorithm</xref> always covers the signature par nput">signature base generation algorithm</xref> always covers the signature par
ameters as the final value in the signature base using a deterministic serializa ameters as the final value in the signature base using a deterministic serializa
tion method. This step strongly binds the signature base with the signature valu tion method. This step strongly binds the signature base with the signature valu
e in a way that makes it much more difficult for an attacker to perform a partia e in a way that makes it much more difficult for an attacker to perform a partia
l substitution on the signature bases.</t> l substitution on the signature base.</t>
</section> </section>
<section anchor="security-keys"> <section anchor="security-keys">
<name>Key Theft</name> <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 s ign 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 protec t any signing key material from exfiltration, capture, and use by an attacker.</ t> <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 s ign 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 protec t 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 amou nt of time stolen keys are useful. Signers can also use key escrow and storage s ystems to limit the attack surface against keys. Furthermore, the use of asymmet ric signing algorithms exposes key material less than the use of <xref target="s ecurity-symmetric">symmetric signing algorithms</xref>.</t> <t>To combat this, signers can rotate keys over time to limit the amou nt of time that stolen keys are useful. Signers can also use key escrow and stor age systems to limit the attack surface against keys. Furthermore, the use of as ymmetric signing algorithms exposes key material less than the use of <xref targ et="security-symmetric">symmetric signing algorithms</xref>.</t>
</section> </section>
<section anchor="security-symmetric"> <section anchor="security-symmetric">
<name>Symmetric Cryptography</name> <name>Symmetric Cryptography</name>
<t>The HTTP Message Signatures specification allows for both asymmetri c and symmetric cryptography to be applied to HTTP messages. By its nature, symm etric cryptographic methods require the same key material to be known by both th e signer and verifier. This effectively means that a verifier is capable of gene rating a valid signature, since they have access to the same key material. An at tacker that is able to compromise a verifier would be able to then impersonate a signer.</t> <t>This document allows both asymmetric and symmetric cryptography to be applied to HTTP messages. By their nature, symmetric cryptographic methods re quire the same key material to be known by both the signer and verifier. This ef fectively means that a verifier is capable of generating a valid signature, sinc e they have access to the same key material. An attacker that is able to comprom ise a verifier would be able to then impersonate a signer.</t>
<t>Where possible, asymmetric methods or secure key agreement mechanis ms 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 c ode, minimizing the vulnerable attack surface. Another technique is the use of k ey derivation functions that allow the signer and verifier to agree on unique ke ys for each message without having to share the key values directly.</t> <t>Where possible, asymmetric methods or secure key agreement mechanis ms 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 c ode, minimizing the vulnerable attack surface. Another technique is the use of k ey derivation functions that allow the signer and verifier to agree on unique ke ys 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 dow ngrade attacks</xref>.</t> <t>Additionally, if symmetric algorithms are allowed within a system, special care must be taken to avoid <xref target="security-keydowngrade">key dow ngrade attacks</xref>.</t>
</section> </section>
<section anchor="security-keymixup"> <section anchor="security-keymixup">
<name>Key Specification Mix-Up</name> <name>Key Specification Mixup</name>
<t>The existence of a valid signature on an HTTP message is not suffic <t>The existence of a valid signature on an HTTP message is not suffic
ient to prove that the message has been signed by the appropriate party. It is u ient to prove that the message has been signed by the appropriate party. It is u
p to the verifier to ensure that a given key and algorithm are appropriate for t p to the verifier to ensure that a given key and algorithm are appropriate for t
he message in question. If the verifier does not perform such a step, an attacke he message in question. If the verifier does not perform such a step, an attacke
r could substitute their own signature using their own key on a message and forc r could substitute their own signature using their own key on a message and forc
e a verifier to accept and process it. To combat this, the verifier needs to ens e a verifier to accept and process it. To combat this, the verifier needs to ens
ure that not only does the signature validate for a message, but that the key an ure not only that the signature can be validated for a message but that the key
d algorithm used are appropriate.</t> and algorithm used are appropriate.</t>
</section> </section>
<section anchor="security-nondeterministic"> <section anchor="security-nondeterministic">
<name>Non-deterministic Signature Primitives</name> <name>Non-deterministic Signature Primitives</name>
<t>Some cryptographic primitives such as RSA PSS and ECDSA have non-de terministic 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 ch eck for the same value being created by re-signing the signature base. Such an i mplementation 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 verificatio n function for the algorithm in question and not do a simple comparison.</t> <t>Some cryptographic primitives, such as RSA-PSS and ECDSA, have non- deterministic outputs, which include some amount of entropy within the algorithm . For such algorithms, multiple signatures generated in succession will not matc h. 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 b ut fail to verify valid signatures made using non-deterministic algorithms. It i s therefore important that a verifier always use the correctly defined verificat ion function for the algorithm in question and not do a simple comparison.</t>
</section> </section>
<section anchor="security-keydowngrade"> <section anchor="security-keydowngrade">
<name>Key and Algorithm Specification Downgrades</name> <name>Key and Algorithm Specification Downgrades</name>
<t>Applications of this specification need to protect against key spec <t>Applications of this specification need to protect against key spec
ification downgrade attacks. For example, the same RSA key can be used for both ification 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 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 key using the weaker RSA 1 with RSA-PSS, it needs to reject signatures for any key that uses the weaker RS
.5 specification.</t> A 1.5 specification.</t>
<t>Another example of a downgrade attack occurs when an asymmetric alg <t>Another example of a downgrade attack would be when an asymmetric a
orithm is expected, such as RSA-PSS, but an attacker substitutes a signature usi lgorithm is expected, such as RSA-PSS, but an attacker substitutes a signature u
ng symmetric algorithm, such as HMAC. A naive verifier implementation could use sing a symmetric algorithm, such as HMAC. A naive verifier implementation could
the value of the public RSA key as the input to the HMAC verification function. use the value of the public RSA key as the input to the HMAC verification functi
Since the public key is known to the attacker, this would allow the attacker to on. Since the public key is known to the attacker, this would allow the attacker
create a valid HMAC signature against this known key. To prevent this, the verif to create a valid HMAC signature against this known key. To prevent this, the v
ier needs to ensure that both the key material and the algorithm are appropriate erifier needs to ensure that both the key material and the algorithm are appropr
for the usage in question. Additionally, while this specification does allow ru iate for the usage in question. Additionally, while this specification does allo
ntime specification of the algorithm using the <tt>alg</tt> signature parameter, w runtime specification of the algorithm using the <tt>alg</tt> signature parame
applications are encouraged to use other mechanisms such as static configuratio ter, applications are encouraged to use other mechanisms such as static configur
n or higher protocol-level algorithm specification instead, preventing an attack ation or a higher-protocol-level algorithm specification instead, preventing an
er from substituting the algorithm specified.</t> attacker from substituting the algorithm specified.</t>
</section> </section>
<section anchor="security-sign-signature"> <section anchor="security-sign-signature">
<name>Signing Signature Values</name> <name>Signing Signature Values</name>
<t>When applying the <xref target="content-request-response">request-r <t>When applying the <xref target="content-request-response"><tt>req</
esponse parameter</xref> or <xref target="signature-multiple">multiple signature tt>
s</xref> to a message, it is possible to sign the value of an existing Signature parameter</xref> or <xref target="signature-multiple">multiple signatures</xref>
field, thereby covering the bytes of the existing signature output in the new s to a message, it is possible to sign the value of an existing Signature field,
ignature's value. While it would seem that this practice would transitively cove thereby covering the bytes of the existing signature output in the new signature
r the components under the original signature in a verifiable fashion, the attac 's value. While it would seem that this practice would transitively cover the co
ks described in <xref target="JACKSON2019"/> can be used to impersonate a signat mponents under the original signature in a verifiable fashion, the attacks descr
ure output value on an unrelated message.</t> ibed in <xref target="JACKSON2019"/> can be used to impersonate a signature outp
ut 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 p roof that Bob is responding to Alice's incoming message. Mallory wants to interc ept this traffic and replace Alice's message with her own, without Alice being a ware that the interception has taken place.</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 p roof that Bob is responding to Alice's incoming message. Mallory wants to interc ept this traffic and replace Alice's message with her own, without Alice being a ware that the interception has taken place.</t>
<ol spacing="normal" type="1"><li>Alice creates a message, <tt>Req_A</ tt> and applies a signature <tt>Sig_A</tt> using her private key <tt>Key_A_Sign< /tt>.</li> <ol spacing="normal" type="1"><li>Alice creates a message <tt>Req_A</t t> 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>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 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 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 c an 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 crafts a signing key <tt>Key_M_Sign</tt> such that she c an 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>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, <li>Bob validates <tt>Sig_M</tt> against Mallory's verification key
<tt>Key_M_Verify</tt>. At no time does Bob think that he's responding to Alice. <tt>Key_M_Verify</tt>. At no time does Bob think that he's responding to Alice.<
</li> /li>
<li>Bob responds with response message <tt>Res_B</tt> to <tt>Req_M</ <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, <tt>Ke tt> and creates signature <tt>Sig_B</tt> over this message using his key <tt>Key
y_B_Sign</tt>. Bob includes the value of <tt>Sig_M</tt> under <tt>Sig_B</tt>'s c _B_Sign</tt>. Bob includes the value of <tt>Sig_M</tt> under <tt>Sig_B</tt>'s co
overed components, but nothing elese from the request message.</li> vered components but does not include anything else from the request message.</l
i>
<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>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</ <li>Alice reads <tt>Res_B</tt> from Mallory and verifies <tt>Sig_B</
tt> using Bob's verification key, <tt>Key_B_Verify</tt>. Alice includes the byte tt> using Bob's verification key <tt>Key_B_Verify</tt>. Alice includes the bytes
s of her original signature <tt>Sig_A</tt> in the signature base, and the signat of her original signature <tt>Sig_A</tt> in the signature base, and the signatu
ure verifies.</li> re verifies.</li>
<li>Alice is led to believe that Bob has responded to her message, a <li>Alice is led to believe that Bob has responded to her message an
nd believes she has cryptographic proof of this happening, but in fact Bob respo d believes she has cryptographic proof of this happening, but in fact Bob respon
nded to Mallory's malicious request and Alice is none the wiser.</li> ded to Mallory's malicious request and Alice is none the wiser.</li>
</ol> </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 mes sage from Mallory's. Applications using this feature, particularly for non-repud iation purposes, can stipulate that any components required in the original sign ature also be covered separately in the second signature. For signed messages, r equiring coverage of the corresponding Signature-Input field of the first signat ure ensures that unique items such as nonces and timestamps are also covered suf ficiently by the second signature.</t> <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 mes sage from Mallory's. Applications using this feature, particularly for non-repud iation purposes, can stipulate that any components required in the original sign ature also be covered separately in the second signature. For signed messages, r equiring coverage of the corresponding Signature-Input field of the first signat ure ensures that unique items such as nonces and timestamps are also covered suf ficiently by the second signature.</t>
</section> </section>
</section> </section>
<section anchor="matching-covered-components-to-message"> <section anchor="matching-covered-components-to-message">
<name>Matching Covered Components to Message</name> <name>Matching Signature Parameters to the Target Message</name>
<section anchor="security-modify"> <section anchor="security-modify">
<name>Modification of Required Message Parameters</name> <name>Modification of Required Message Parameters</name>
<t>An attacker could effectively deny a service by modifying an otherw <t>An attacker could effectively deny a service by modifying an otherw
ise benign signature parameter or signed message component. While rejecting a mo ise benign signature parameter or signed message component. While rejecting a mo
dified message is the desired behavior, consistently failing signatures could le dified message is the desired behavior, consistently failing signatures could le
ad to the verifier turning off signature checking in order to make systems work ad to (1)&nbsp;the verifier turning off signature checking in order to make syst
again (see <xref target="security-ignore"/>), or to the application minimizing t ems work again (see <xref target="security-ignore"/>) or (2)&nbsp;the applicatio
he signed component requirements.</t> n minimizing the requirements related to the signed component.</t>
<t>If such failures are common within an application, the signer and v <t>If such failures are common within an application, the signer and v
erifier should compare their generated signature bases with each other to determ erifier should compare their generated signature bases with each other to determ
ine which part of the message is being modified. If an expected modification is ine 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 t found, the signer and verifier can agree on an alternative set of requirements t
hat will pass. However, the signer and verifier should not remove the requiremen hat will pass. However, the signer and verifier should not remove the requiremen
t to sign the modified component when it is suspected an attacker is modifying t t to sign the modified component when it is suspected that an attacker is modify
he component.</t> ing the component.</t>
</section> </section>
<section anchor="security-mismatch"> <section anchor="security-mismatch">
<name>Mismatch of Signature Parameters from Message</name> <name>Matching Values of Covered Components to Values in the Target Me ssage</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 com ponent 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 le ad to downstream verifiers accepting a message that does not match the presented signature.</t> <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 com ponent 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 le ad 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 ne eds to be trusted by both the signer and verifier within a system.</t> <t>To counter this, the component that generates the signature base ne eds to be trusted by both the signer and verifier within a system.</t>
</section> </section>
<section anchor="security-message-component-context"> <section anchor="security-message-component-context">
<name>Message Component Source and Context</name> <name>Message Component Source and Context</name>
<t>The signature context for deriving message component values include <t>The signature context for deriving message component values include
s the target HTTP Message itself, any associated messages (such as the request t s the target HTTP message itself, any associated messages (such as the request t
hat triggered a response), and additional information that the signer or verifie hat triggered a response), and additional information that the signer or verifie
r has access to. Both signers and verifiers need to carefully consider the sourc r has access to. Both signers and verifiers need to carefully consider the sourc
e of all information when creating component values for the signature base and t e of all information when creating component values for the signature base and t
ake care not to take information from untrusted sources. Otherwise, an attacker ake care not to take information from untrusted sources. Otherwise, an attacker
could leverage such a loosely-defined message context to inject their own values could leverage such a loosely defined message context to inject their own values
into the signature base string, overriding or corrupting the intended values.</ into the signature base string, overriding or corrupting the intended values.</
t> t>
<t>For example, in most situations, the target URI of the message is d <t>For example, in most situations, the target URI of the message is a
efined in <xref section="7.1" sectionFormat="comma" target="HTTP"/>. However, le s defined in <xref section="7.1" sectionFormat="comma" target="RFC9110"/>. Howev
t's say that there is an application that requires signing of the <tt>@authority er, let's say that there is an application that requires signing of the <tt>@aut
</tt> of the incoming request, but the application doing the processing is behin hority</tt> of the incoming request, but the application doing the processing is
d a reverse proxy. Such an application would expect a change in the <tt>@authori behind a reverse proxy. Such an application would expect a change in the <tt>@a
ty</tt> value, and it could be configured to know the external target URI as see uthority</tt> value, and it could be configured to know the external target URI
n by the client on the other side of the proxy. This application would use this as seen by the client on the other side of the proxy. This application would use
configured value as its target URI for the purposes of deriving message componen this configured value as its target URI for the purposes of deriving message co
t values such as <tt>@authority</tt> instead of using the target URI of the inco mponent values such as <tt>@authority</tt> instead of using the target URI of th
ming message.</t> e incoming message.</t>
<t>This approach is not without problems, as a misconfigured system co uld accept signed requests intended for different components in the system. For this scenario, an intermediary could instead add its own signature to be verifie d by the application directly, as demonstrated in <xref target="signature-multip le"/>. This alternative approach requires a more active intermediary but relies less on the target application knowing external configuration values.</t> <t>This approach is not without problems, as a misconfigured system co uld accept signed requests intended for different components in the system. For this scenario, an intermediary could instead add its own signature to be verifie d by the application directly, as demonstrated in <xref target="signature-multip le"/>. This alternative approach requires a more active intermediary but relies less on the target application knowing external configuration values.</t>
<t>For another example, <xref target="content-request-response"/> defi nes a method for signing response messages but including portions of the request message that triggered the response. In this case, the context for component va lue calculation is the combination of the response and request message, not just the single message to which the signature is applied. For this feature, the <tt >req</tt> flag allows both signer to explicitly signal which part of the context is being sourced for a component identifier's value. Implementations need to en sure that only the intended message is being referred to for each component, oth erwise an attacker could attempt to subvert a signature by manipulating one side or the other.</t> <t>As another example, <xref target="content-request-response"/> defin es a method for signing response messages and also including portions of the req uest message that triggered the response. In this case, the context for componen t value calculation is the combination of the response and request messages, not just the single message to which the signature is applied. For this feature, th e <tt>req</tt> flag allows both signers to explicitly signal which part of the c ontext is being sourced for a component identifier's value. Implementations need to ensure that only the intended message is being referred to for each componen t; otherwise, an attacker could attempt to subvert a signature by manipulating o ne side or the other.</t>
</section> </section>
<section anchor="security-context-multiple-signatures"> <section anchor="security-context-multiple-signatures">
<name>Multiple Message Component Contexts</name> <name>Multiple Message Component Contexts</name>
<t>It is possible that the context for deriving message component valu <t>It is possible that the context for deriving message component valu
es could be distinct for each signature present within a single message. This is es could be distinct for each signature present within a single message. This is
particularly the case when proxies mutate messages and include signatures over particularly the case when proxies mutate messages and include signatures over
the mutated values, in addition to any existing signatures. For example, a rever the mutated values, in addition to any existing signatures. For example, a rever
se proxy can replace a public hostname in a request to a service with the hostna se proxy can replace a public hostname in a request to a service with the hostna
me for the individual service host that it is forwarding the request on to. If b me for the individual service host to which it is forwarding the request. If bot
oth the client and the reverse proxy add signatures covering <tt>@authority</tt> h the client and the reverse proxy add signatures covering <tt>@authority</tt>,
, the service host will see two signatures on the request, each signing differen the service host will see two signatures on the request, each signing different
t values for the <tt>@authority</tt> message component, reflecting the change to values for the <tt>@authority</tt> message component, reflecting the change to t
that component as the message made its way from the client to the service host. hat component as the message made its way from the client to the service host.</
</t> t>
<t>In such a case, it's common for the internal service to verify only <t>In such a case, it's common for the internal service to verify only
one of the signatures or to use externally-configured information, as discussed one of the signatures or to use externally configured information, as discussed
in <xref target="security-message-component-context"/>. However, a verifier pro in <xref target="security-message-component-context"/>. However, a verifier pro
cessing both signatures has to use a different message component context for eac cessing both signatures has to use a different message component context for eac
h signature, since the component value for the <tt>@authority</tt> component wil h signature, since the component value for the <tt>@authority</tt> component wil
l be different for each signature. Verifiers like this need to be aware of both l 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 the target service' the reverse proxy's context for incoming messages and the target service's conte
s context for the message coming from the reverse proxy. The verifier needs to t xt for the message coming from the reverse proxy. The verifier needs to take par
ake particular care to apply the correct context to the correct signature, other ticular care to apply the correct context to the correct signature; otherwise, a
wise an attacker could use knowledge of this complex setup to confuse the inputs n attacker could use knowledge of this complex setup to confuse the inputs to th
to the verifier.</t> e verifier.</t>
<t>Such verifiers also need to ensure that any differences in message <t>Such verifiers also need to ensure that any differences in message
component contexts between signatures are expected and permitted. For example, i component contexts between signatures are expected and permitted. For example, i
n the above scenario, the reverse proxy could include the original hostname in a n the above scenario, the reverse proxy could include the original hostname in a
<tt>Forwarded</tt> header field, and sign <tt>@authority</tt>, <tt>forwarded</t Forwarded header field and could sign <tt>@authority</tt>, forwarded, and the c
t>, and the client's entry in the <tt>signature</tt> field. The verifier can use lient's entry in the Signature field. The verifier can use the hostname from the
the hostname from the <tt>Forwarded</tt> header field to confirm that the hostn Forwarded header field to confirm that the hostname was transformed as expected
ame was transformed as expected.</t> .</t>
</section> </section>
</section> </section>
<section anchor="http-processing"> <section anchor="http-processing">
<name>HTTP Processing</name> <name>HTTP Processing</name>
<section anchor="security-lazy-header-parser"> <section anchor="security-lazy-header-parser">
<name>Confusing HTTP Field Names for Derived Component Names</name> <name>Processing Invalid HTTP Field Names as Derived Component Names</
<t>The definition of HTTP field names does not allow for the use of th name>
e <tt>@</tt> character anywhere in the name. As such, since all derived componen <t>The definition of HTTP field names does not allow for the use of th
t names start with the <tt>@</tt> character, these namespaces should be complete e
ly separate. However, some HTTP implementations are not sufficiently strict abou <tt>@</tt> character anywhere in the name. As such, since all derived component
t the characters accepted in HTTP field names. In such implementations, a sender names start with the <tt>@</tt> character, these namespaces should be completely
(or attacker) could inject a header field starting with an <tt>@</tt> character separate. However, some HTTP implementations are not sufficiently strict about
and have it passed through to the application code. These invalid header fields the characters accepted in HTTP field names. In such implementations, a sender (
could be used to override a portion of the derived message content and substitu or attacker) could inject a header field starting with an <tt>@</tt> character a
te an arbitrary value, providing a potential place for an attacker to mount a <x nd have it passed through to the application code. These invalid header fields c
ref target="security-collision">signature collision</xref> attack or other funct ould be used to override a portion of the derived message content and substitute
ional substitution attack (such as using the signature from a GET request on a c an arbitrary value, providing a potential place for an attacker to mount a <xre
rafted POST request).</t> f target="security-collision">signature collision</xref> attack or other functio
<t>To combat this, when selecting values for a message component, if t nal substitution attack (such as using the signature from a GET request on a cra
he component name starts with the <tt>@</tt> character, it needs to be processed fted POST request).</t>
as a derived component and never taken as a fields. Only if the component name <t>To combat this, when selecting values for a message component, if t
does not start with the <tt>@</tt> character can it be taken from the fields of he component name starts with the <tt>@</tt> character, it needs to be processed
the message. The algorithm discussed in <xref target="create-sig-input"/> provid as a derived component and never processed as an HTTP field. Only if the compon
es a safe order of operations.</t> ent name does not start with the <tt>@</tt> character can it be taken from the f
ields of the message. The algorithm discussed in <xref target="create-sig-input"
/> provides a safe order of operations.</t>
</section> </section>
<section anchor="security-field-values"> <section anchor="security-field-values">
<name>Semantically Equivalent Field Values</name> <name>Semantically Equivalent Field Values</name>
<t>The <xref target="create-sig-input">signature base generation algor <t>The <xref target="create-sig-input">signature base generation algor
ithm</xref> uses the value of an HTTP field as its component value. In the commo ithm</xref> uses the value of an HTTP field as its component value. In the commo
n case, this amounts to taking the actual bytes of the field value as the compon n case, this amounts to taking the actual bytes of the field value as the compon
ent value for both the signer and verifier. However, some field values allow for ent value for both the signer and verifier. However, some field values allow for
transformation of the values in semantically equivalent ways that alter the byt transformation of the values in semantically equivalent ways that alter the byt
es used in the value itself. For example, a field definition can declare some or es used in the value itself. For example, a field definition can declare some or
all of its value to be case-insensitive, or to have special handling of interna all of its values to be case insensitive or to have special handling of interna
l whitespace characters. Other fields have expected transformations from interme l whitespace characters. Other fields have expected transformations from interme
diaries, such as the removal of comments in the <tt>Via</tt> header field. In su diaries, such as the removal of comments in the Via header field. In such cases,
ch cases, a verifier could be tripped up by using the equivalent transformed fie a verifier could be tripped up by using the equivalent transformed field value,
ld value, which would differ from the byte value used by the signer. The verifie which would differ from the byte value used by the signer. The verifier would h
r would have a difficult time finding this class of errors since the value of th ave a difficult time finding this class of errors, since the value of the field
e field is still acceptable for the application, but the actual bytes required b is still acceptable for the application but the actual bytes required by the sig
y the signature base would not match.</t> nature base would not match.</t>
<t>When processing such fields, the signer and verifier have to agree <t>When processing such fields, the signer and verifier have to agree
how to handle such transformations, if at all. One option is to not sign problem on how to handle such transformations, if at all. One option is to not sign prob
atic fields, but care must be taken to ensure that there is still <xref target=" lematic fields, but care must be taken to ensure that there is still <xref targe
security-coverage">sufficient signature coverage</xref> for the application. Ano t="security-coverage">sufficient signature coverage</xref> for the application.
ther option is to define an application-specific canonicalization value for the Another option is to define an application-specific canonicalization value for t
field before it is added to the HTTP message, such as to always remove internal he field before it is added to the HTTP message, such as to always remove intern
comments before signing, or to always transform values to lowercase. Since these al comments before signing or to always transform values to lowercase. Since the
transformations are applied prior to the field being used as input to the signa se transformations are applied prior to the field being used as input to the sig
ture base generation algorithm, the signature base will still simply contain the nature base generation algorithm, the signature base will still simply contain t
byte value of the field as it appears within the message. If the transformation he byte value of the field as it appears within the message. If the transformati
s were to be applied after the value is extracted from the message but before it ons were to be applied after the value is extracted from the message but before
is added to the signature base, different attack surfaces such as value substit it is added to the signature base, different attack surfaces such as value subst
ution attacks could be launched against the application. All application-specifi itution attacks could be launched against the application. All application-speci
c additional rules are outside the scope of this specification, and by their ver fic additional rules are outside the scope of this specification, and by their v
y nature these transformations would harm interoperability of the implementation ery nature these transformations would harm interoperability of the implementati
outside of this specific application. It is recommended that applications avoid on outside of this specific application. It is recommended that applications avo
the use of such additional rules wherever possible.</t> id the use of such additional rules wherever possible.</t>
</section> </section>
<section anchor="security-structured"> <section anchor="security-structured">
<name>Parsing Structured Field Values</name> <name>Parsing Structured Field Values</name>
<t>Several parts of this specification rely on the parsing of structur ed field values <xref target="STRUCTURED-FIELDS"/>. In particular, <xref target= "http-field-structured">normalization of HTTP structured field values</xref>, <x ref target="http-field-dictionary">referencing members of a dictionary structure d field</xref>, and processing the <tt>@signature-input</tt> value when <xref ta rget="verify">verifying a signature</xref>. While structured field values are de signed to be relatively simple to parse, a naive or broken implementation of suc h a parser could lead to subtle attack surfaces being exposed in the implementat ion.</t> <t>Several parts of this specification rely on the parsing of Structur ed Field values <xref target="RFC8941"/> -- in particular, <xref target="http-fi eld-structured">strict serialization of HTTP Structured Field values</xref>, <xr ef target="http-field-dictionary">referencing members of a Dictionary Structured Field</xref>, and processing the <tt>@signature-input</tt> value when <xref tar get="verify">verifying a signature</xref>. While Structured Field values are des igned 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 implementati on.</t>
<t>For example, if a buggy parser of the <tt>@signature-input</tt> val ue does not enforce proper closing of quotes around string values within the lis t of component identifiers, an attacker could take advantage of this and inject additional content into the signature base through manipulating the Signature-In put field value on a message.</t> <t>For example, if a buggy parser of the <tt>@signature-input</tt> val ue does not enforce proper closing of quotes around string values within the lis t of component identifiers, an attacker could take advantage of this and inject additional content into the signature base through manipulating the Signature-In put field value on a message.</t>
<t>To counteract this, implementations should use fully compliant and trusted parsers for all structured field processing, both on the signer and veri fier side.</t> <t>To counteract this, implementations should use fully compliant and trusted parsers for all Structured Field processing, on both the signer side and the verifier side.</t>
</section> </section>
<section anchor="security-versions"> <section anchor="security-versions">
<name>HTTP Versions and Component Ambiguity</name> <name>HTTP Versions and Component Ambiguity</name>
<t>Some message components are expressed in different ways across HTTP <t>Some message components are expressed in different ways across HTTP
versions. For example, the authority of the request target is sent using the <t versions. For example, the authority of the request target is sent using the Ho
t>Host</tt> header field in HTTP/1.1 but with the <tt>:authority</tt> pseudo-hea st header field in HTTP/1.1 but with the <tt>:authority</tt> pseudo-header in HT
der in HTTP/2. If a signer sends an HTTP/1.1 message and signs the <tt>Host</tt> TP/2. If a signer sends an HTTP/1.1 message and signs the Host header field but
field, but the message is translated to HTTP/2 before it reaches the verifier, the message is translated to HTTP/2 before it reaches the verifier, the signatur
the signature will not validate as the <tt>Host</tt> header field could be dropp e will not validate, as the Host header field could be dropped.</t>
ed.</t> <t>It is for this reason that HTTP message signatures define a set of
<t>It is for this reason that HTTP Message Signatures defines a set of derived components that define a single way to get the value in question, such a
derived components that define a single way to get value in question, such as t s the <tt>@authority</tt> derived component (<xref target="content-request-autho
he <tt>@authority</tt> derived component (<xref target="content-request-authorit rity"/>) in lieu of the Host header field. Applications should therefore prefer
y"/>) in lieu of the <tt>Host</tt> header field. Applications should therefore p derived components for such options where possible.</t>
refer derived components for such options where possible.</t>
</section> </section>
<section anchor="security-canonicalization"> <section anchor="security-canonicalization">
<name>Canonicalization Attacks</name> <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 susce ptible to broken implementations that could lead to unexpected and insecure beha vior. Naive implementations of this specification might implement HTTP field pro cessing by taking the single value of a field and using it as the direct compone nt value without processing it appropriately.</t> <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 susce ptible to broken implementations that could lead to unexpected and insecure beha vior. Naive implementations of this specification might implement HTTP field pro cessing by taking the single value of a field and using it as the direct compone nt 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 collisio n</xref> attack. Alternatively, if header fields that appear multiple times are not joined into a single string value, as is required by this specification, sim ilar attacks can be mounted as a signed component value would show up in the sig nature base more than once and could be substituted or otherwise attacked in thi s way.</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 collisio n</xref> attack. Alternatively, if header fields that appear multiple times are not joined into a single string value, as required by this specification, simila r attacks can be mounted, as a signed component value would show up in the signa ture 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> <t>To counter this, the entire field value processing algorithm needs to be implemented by all implementations of signers and verifiers.</t>
</section> </section>
<section anchor="security-non-list"> <section anchor="security-non-list">
<name>Non-List Field Values</name> <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 i n the HTTP signature base, as described in <xref target="create-sig-input"/>. No t 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, t he message component value is never meant to be read back out of the signature b ase string or used in the application. 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 si gned message should also be rejected.</t> <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 i n the HTTP signature base, as described in <xref target="create-sig-input"/>. No t 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, t he message component value is never meant to be read back out of the signature b ase string or used in the application. 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 s igned message should also be rejected.</t>
<t>If an HTTP field allows for unquoted commas within its values, comb ining multiple field values can lead to a situation where two semantically diffe rent messages produce the same line in a signature base. For example, take the f ollowing hypothetical header field with an internal comma in its syntax, here us ed to define two separate lists of values:</t> <t>If an HTTP field allows for unquoted commas within its values, comb ining multiple field values can lead to a situation where two semantically diffe rent messages produce the same line in a signature base. For example, take the f ollowing hypothetical header field with an internal comma in its syntax, here us ed to define two separate lists of values:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots Example-Header: value, with, lots
Example-Header: of, commas Example-Header: of, commas
]]></sourcecode> ]]></sourcecode>
<t>For this header field, sending all of these values as a single fiel d value results in a single list of values:</t> <t>For this header field, sending all of these values as a single fiel d value results in a single list of values:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Header: value, with, lots, of, commas Example-Header: value, with, lots, of, commas
]]></sourcecode> ]]></sourcecode>
<t>Both of these messages would create the following line in the signa ture base:</t> <t>Both of these messages would create the following line in the signa ture base:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"example-header": value, with, lots, of, commas "example-header": value, with, lots, of, commas
]]></artwork> ]]></artwork>
<t>Since two semantically distinct inputs can create the same output i n the signature base, special care has to be taken when handling such values.</t > <t>Since two semantically distinct inputs can create the same output i n the signature base, special care has to be taken when handling such values.</t >
<t>Specifically, the Set-Cookie field <xref target="COOKIE"/> defines an internal syntax that does not conform to the List syntax in <xref target="STR UCTURED-FIELDS"/>. In particular some portions allow unquoted commas, and the fi eld 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" sectionF ormat="comma" target="HTTP"/>. Therefore, all the cookies need to be processed f rom their separate header values, without being combined, while the signature ba se needs to be processed from the special combined value generated solely for th is purpose. If the cookie value is invalid, the signed message ought to be rejec ted as this is a possible padding attack as described in <xref target="security- multiple-fields"/>.</t> <t>Specifically, the Set-Cookie field <xref target="RFC6265"/> defines an internal syntax that does not conform to the List syntax provided in <xref t arget="RFC8941"/>. In particular, some portions allow unquoted commas, and the f ield is typically sent as multiple separate field lines with distinct values whe n 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 b e able to parse and use the results, as discussed in <xref section="5.3" section Format="comma" target="RFC9110"/>. Therefore, all the cookies need to be process ed from their separate 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 re jected, as this is a possible padding attack as described in <xref target="secur ity-multiple-fields"/>.</t>
<t>To deal with this, an application can choose to limit signing of pr oblematic fields like Set-Cookie, such as including the field in a signature onl y when a single field value is present and the results would be unambiguous. Sim ilar 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-se quence"/>.</t> <t>To deal with this, an application can choose to limit signing of pr oblematic fields like Set-Cookie, such as including the field in a signature onl y when a single field value is present and the results would be unambiguous. Sim ilar 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-se quence"/>.</t>
</section> </section>
<section anchor="security-multiple-fields"> <section anchor="security-multiple-fields">
<name>Padding Attacks with Multiple Field Values</name> <name>Padding Attacks with Multiple Field Values</name>
<t>Since HTTP field values need to be combined in a single string valu <t>Since HTTP field values need to be combined into a single string va
e to be included in the HTTP signature base, as described in <xref target="creat lue to be included in the HTTP signature base (see <xref target="create-sig-inpu
e-sig-input"/>, it is possible for an attacker to inject an additional value for t"/>), it is possible for an attacker to inject an additional value for a given
a given field and add this to the signature base of the verifier.</t> field and add this to the signature base of the verifier.</t>
<t>In most circumstances, this causes the signature validation to fail <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 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 th the signer to create the signature. However, it is theoretically possible for th
e attacker to inject both a garbage value to a field and a desired value to anot e attacker to inject both a garbage value into a field and a desired value into
her field in order to force a particular input. This is a variation of the colli another field in order to force a particular input. This is a variation of the c
sion attack described in <xref target="security-collision"/>, where the attacker ollision attack described in <xref target="security-collision"/>, where the atta
accomplishes their change in the message by adding to existing field values.</t cker 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 th e fields covered in the signature in addition to ensuring that the signature its elf validates. With such protections, the attacker's padding attack would be rej ected by the field value processor, even in the case where the attacker could fo rce a signature collision.</t> <t>To counter this, an application needs to validate the content of th e fields covered in the signature in addition to ensuring that the signature its elf validates. With such protections, the attacker's padding attack would be rej ected by the field value processor, even in the case where the attacker could fo rce a signature collision.</t>
</section> </section>
<section anchor="security-query-elements"> <section anchor="security-query-elements">
<name>Ambiguous Handling of Query Elements</name> <name>Ambiguous Handling of Query Elements</name>
<t>The HTML form parameters format defined in the "application/x-www-f <t>The HTML form parameters format defined in Section&nbsp;<xref targe
orm-urlencoded" section of <xref target="HTMLURL"/>, is widely deployed and supp t="HTMLURL" section="5" relative="https://url.spec.whatwg.org/#application/x-www
orted by many application frameworks. For convenience, some of these frameworks -form-urlencoded"
in particular combine query parameters that are found in the HTTP query and thos sectionFormat="bare">"application/x-www-form-urlencoded"</xref> of
e found in the message content, particularly for POST message with a Content-Typ <xref target="HTMLURL"/> is widely deployed and supported by many application fr
e value of "application/x-www-form-urlencoded". The <tt>@query-param</tt> derive ameworks. For convenience, some of these frameworks in particular combine query
d component identifier defined in <xref target="content-request-query-param"/> d parameters that are found in the HTTP query and those found in the message conte
raws its values only from the query section of the target URI of the request. As nt, particularly for POST messages with a Content-Type value of "application/x-w
such, it would be possible for an attacker to shadow or replace query parameter ww-form-urlencoded". The <tt>@query-param</tt> derived component identifier defi
s in a request by overriding the signed query parameter with an unsigned form pa ned in <xref target="content-request-query-param"/> draws its values only from t
rameter, or vice versa.</t> he 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 overridin
g 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> <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>
</section> </section>
<section anchor="privacy"> <section anchor="privacy">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<section anchor="privacy-identify-keys"> <section anchor="privacy-identify-keys">
<name>Identification through Keys</name> <name>Identification through Keys</name>
<t>If a signer uses the same key with multiple verifiers, or uses the sa <t>If a signer uses the same key with multiple verifiers or uses the sam
me key over time with a single verifier, the ongoing use of that key can be used e 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. to track the signer throughout the set of verifiers that messages are sent to. S
Since cryptographic keys are meant to be functionally unique, the use of the sam ince cryptographic keys are meant to be functionally unique, the use of the same
e key over time is a strong indicator that it is the same party signing multiple key over time is a strong indicator that it is the same party signing multiple
messages.</t> messages.</t>
<t>In many applications, this is a desirable trait, and it allows HTTP M <t>In many applications, this is a desirable trait, and it allows HTTP m
essage Signatures to be used as part of authenticating the signer to the verifie essage signatures to be used as part of authenticating the signer to the verifie
r. However, it could be unintentional tracking that a signer might not be aware r. However, it could also result in unintentional tracking that a signer might n
of. To counter this kind of tracking, a signer can use a different key for each ot be aware of. To counter this kind of tracking, a signer can use a different k
verifier that it is in communication with. Sometimes, a signer could also rotate ey for each verifier that it is in communication with. Sometimes, a signer could
their key when sending messages to a given verifier. These approaches do not ne also rotate their key when sending messages to a given verifier. These approach
gate the need for other anti-tracking techniques to be applied as necessary.</t> es do not negate the need for other anti-tracking techniques to be applied as ne
cessary.</t>
</section> </section>
<section anchor="privacy-confidentiality"> <section anchor="privacy-confidentiality">
<name>Signatures do not provide confidentiality</name> <name>Signatures do not provide confidentiality</name>
<t>HTTP Message Signatures do not provide confidentiality of any of the <t>HTTP message signatures do not provide confidentiality for any of the
information protected by the signature. The content of the HTTP message, includi information protected by the signature. The content of the HTTP message, includ
ng the value of all fields and the value of the signature itself, is presented i ing the value of all fields and the value of the signature itself, is presented
n plaintext to any party with access to the message.</t> in plaintext to any party with access to the message.</t>
<t>To provide confidentiality at the transport level, TLS or its equival <t>To provide confidentiality at the transport level, TLS or its equival
ent can be used as discussed in <xref target="security-tls"/>.</t> ent can be used, as discussed in <xref target="security-tls"/>.</t>
</section> </section>
<section anchor="privacy-oracle"> <section anchor="privacy-oracle">
<name>Oracles</name> <name>Oracles</name>
<t>It is important to balance the need for providing useful feedback to developers on error conditions without providing additional information to an at tacker. For example, a naive but helpful server implementation might try to indi cate the required key identifier needed for requesting a resource. If someone kn ows who controls that key, a correlation can be made between the resource's exis tence and the party identified by the key. Access to such information could be u sed by an attacker as a means to target the legitimate owner of the resource for further attacks.</t> <t>It is important to balance the need for providing useful feedback to developers regarding error conditions without providing additional information t o an attacker. For example, a naive but helpful server implementation might try to indicate the required key identifier needed for requesting a resource. If som eone 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 cou ld be used by an attacker as a means to target the legitimate owner of the resou rce for further attacks.</t>
</section> </section>
<section anchor="privacy-required"> <section anchor="privacy-required">
<name>Required Content</name> <name>Required Content</name>
<t>A core design tenet of this specification is that all message compone nts covered by the signature need to be available to the verifier in order to re create the signature base and verify the signature. As a consequence, if an appl ication of this specification requires that a particular field be signed, the ve rifier will need access to the value of that field.</t> <t>A core design tenet of this specification is that all message compone nts covered by the signature need to be available to the verifier in order to re create the signature base and verify the signature. As a consequence, if an appl ication of this specification requires that a particular field be signed, the ve rifier will need access to the value of that field.</t>
<t>For example, in some complex systems with intermediary processors thi s could cause the surprising behavior of an intermediary not being able to remov e privacy-sensitive information from a message before forwarding it on for proce ssing, for fear of breaking the signature. A possible mitigation for this specif ic situation would be for the intermediary to verify the signature itself, and t hen modify the message to remove the privacy-sensitive information. The intermed iary can add its own signature at this point to signal to the next destination t hat the incoming signature was validated, as is shown in the example in <xref ta rget="signature-multiple"/>.</t> <t>For example, in some complex systems with intermediary processors, th is could cause surprising behavior where, for fear of breaking the signature, an intermediary cannot remove privacy-sensitive information from a message before forwarding it on for processing. One way to mitigate this specific situation wou ld be for the intermediary to verify the signature itself and then modify the me ssage 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 shown in the example in <xref target="signature-mult iple"/>.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="POSIX" to="POSIX.1"/> <displayreference target="POSIX" to="POSIX.1"/>
<displayreference target="HTTP1" to="HTTP/1.1"/> <displayreference 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-MESSA
GES"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="ASCII">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"
<title>ASCII format for network interchange</title> />
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"
<date month="October" year="1969"/> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"
<seriesInfo name="STD" value="80"/> />
<seriesInfo name="RFC" value="20"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"
<seriesInfo name="DOI" value="10.17487/RFC0020"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"
<reference anchor="RFC2104"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"
<title>HMAC: Keyed-Hashing for Message Authentication</title> />
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"
<author fullname="M. Bellare" initials="M." surname="Bellare"/> />
<author fullname="R. Canetti" initials="R." surname="Canetti"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8941.xml"
<date month="February" year="1997"/> />
<abstract>
<t>This document describes HMAC, a mechanism for message authentic <reference anchor="FIPS186-5" target="https://doi.org/10.6028/NIST.FIPS.
ation using cryptographic hash functions. HMAC can be used with any iterative cr 186-5">
yptographic 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 underl
ying hash function. This memo provides information for the Internet community. T
his 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 3
rd"/>
<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) dat
a structure that represents a cryptographic key. This specification also defines
a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algo
rithms and identifiers for use with this specification are described in the sepa
rate 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 ident
ifiers 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 th
ese 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 o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA 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 r
ecommended parameters for the edwards25519 and edwards448 curves. An example imp
lementation 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 algo
rithms that are intended to make it easier and safer to define and handle HTTP h
eader and trailer fields, known as "Structured Fields", "Structured Headers", or
"Structured Trailers". It is intended for use by specifications of new HTTP fie
lds that wish to use a common syntax that is more restrictive than traditional H
TTP 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">
<front> <front>
<title>Digital Signature Standard (DSS)</title> <title>Digital Signature Standard (DSS)</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date year="2013"/> <date month="February" year="2023"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
</reference> </reference>
<reference anchor="POSIX" target="https://pubs.opengroup.org/onlinepubs/ 9699919799/"> <reference anchor="POSIX" target="https://pubs.opengroup.org/onlinepubs/ 9699919799/">
<front> <front>
<title>The Open Group Base Specifications Issue 7, 2018 edition</tit le> <title>The Open Group Base Specifications Issue 7, 2018 edition</tit le>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="HTTP">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
<title>HTTP Semantics</title> />
<author fullname="R. Fielding" initials="R." role="editor" surname=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"
Fielding"/> />
<author fullname="M. Nottingham" initials="M." role="editor" surname <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
="Nottingham"/> />
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/> <reference anchor="HTMLURL" target="https://url.spec.whatwg.org/">
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, 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, 7
232, 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n 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 ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; 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>
<reference anchor="HTMLURL" target="https://url.spec.whatwg.org/#applica
tion/x-www-form-urlencoded">
<front> <front>
<title>URL (Living Standard)</title> <title>URL (Living Standard)</title>
<author> <author>
<organization/> <organization>WHATWG</organization>
</author> </author>
<date year="2021"/> <date month="January" year="2024"/>
</front>
</reference>
<reference anchor="ABNF">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<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 Au
gmented BNF (ABNF), has been popular among many Internet specifications. The cur
rent specification documents ABNF. It balances compactness and simplicity with r
easonable representational power. The differences between standard BNF and ABNF
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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> </front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
34.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7239">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72
<title>Forwarded HTTP Extension</title> 39.xml"/>
<author fullname="A. Petersson" initials="A." surname="Petersson"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
<author fullname="M. Nilsson" initials="M." surname="Nilsson"/> 15.xml"/>
<date month="June" year="2014"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.78
<abstract> 07.xml"/>
<t>This document defines an HTTP extension header field that allow <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
s proxy components to disclose information lost in the proxying process, for exa 57.xml"/>
mple, the originating IP address of a request or IP address of the proxy on the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
user-agent-facing interface. In a path of proxying components, this makes it pos 92.xml"/>
sible to arrange it so that each subsequent component will have access to, for e
xample, all IP addresses used in the chain of proxied HTTP requests.</t> <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/
<t>This document also specifies guidelines for a proxy administrat bcp195">
or to anonymize the origin of a request.</t>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
</front> 96.xml"/>
<seriesInfo name="RFC" value="7239"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<seriesInfo name="DOI" value="10.17487/RFC7239"/> 25.xml"/>
</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 digita
l signatures or Message Authentication Codes (MACs) using JSON-based data struct
ures. Cryptographic algorithms and identifiers for use with this specification a
re described in the separate JSON Web Algorithms (JWA) specification and an IANA
registry defined by that specification. Related encryption capabilities are des
cribed 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 mach
ine- readable details of errors in a HTTP response to avoid the need to define n
ew 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</t
itle>
<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" strateg
y, is based on the historical use of a single backslash ('\') character to indic
ate where line-folding has occurred, with the continuation occurring with the fi
rst character that is not a space character (' ') on the next line. The second s
trategy, called the "double backslash" strategy, extends the first strategy by a
dding a second backslash character to identify where the continuation begins and
is thereby able to handle cases not supported by the first strategy. Both strat
egies use a self-describing header enabling automated reconstitution of the orig
inal content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8792"/>
<seriesInfo name="DOI" value="10.17487/RFC8792"/>
</reference>
<referencegroup anchor="BCP195">
<reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rf
c8996">
<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 (T
LS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents hav
e been moved to Historic status. These versions lack support for current and rec
ommended cryptographic algorithms and mechanisms, and various government and ind
ustry profiles of applications using TLS now mandate avoiding these old TLS vers
ions. 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 miscon
figuration, 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/rf
c9325">
<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-And
re"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer S
ecurity (DTLS) are used to protect data exchanged over a wide range of applicati
on protocols and can also form the basis for secure transport protocols. Over th
e years, the industry has witnessed several serious attacks on TLS and DTLS, inc
luding attacks on the most commonly used cipher suites and their modes of operat
ion. This document provides the latest recommendations for ensuring the security
of deployed services that use TLS and DTLS. These recommendations are applicabl
e 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 tran
sition is largely complete, and TLS 1.3 is widely available. This document updat
es the guidance given the new environment and obsoletes RFC 7525. In addition, t
his 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>
</referencegroup> </referencegroup>
<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 informa
tion 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">
<front>
<title>Digest Fields</title>
<author fullname="Roberto Polli" initials="R." surname="Polli">
<organization>Team Digitale, Italian Government</organization>
</author>
<author fullname="Lucas Pardue" initials="L." surname="Pardue">
<organization>Cloudflare</organization>
</author>
<date day="10" month="July" year="2023"/>
<abstract>
<t> This document defines HTTP fields that support integrity dig
ests.
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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
fields. 40.xml"/>
</t> <!-- draft-ietf-httpbis-digest-headers (RFC 9530; AUTH48-DONE) -->
</abstract> <reference anchor="RFC9530" target="https://www.rfc-editor.org/info/rfc9530">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-digest-hea <title>Digest Fields</title>
ders-13"/> <author initials="R." surname="Polli" fullname="Roberto Polli">
</reference> <organization>Team Digitale, Italian Government</organization>
<reference anchor="COOKIE"> </author>
<front> <author initials="L." surname="Pardue" fullname="Lucas Pardue">
<title>HTTP State Management Mechanism</title> <organization>Cloudflare</organization>
<author fullname="A. Barth" initials="A." surname="Barth"/> </author>
<date month="April" year="2011"/> <date month="February" year="2024" />
<abstract> </front>
<t>This document defines the HTTP Cookie and Set-Cookie header fie <seriesInfo name="RFC" value="9530"/>
lds. These header fields can be used by HTTP servers to store state (called cook <seriesInfo name="DOI" value="10.17487/RFC9530"/>
ies) at HTTP user agents, letting the servers maintain a stateful session over t </reference>
he mostly stateless HTTP protocol. Although cookies have many historical infelic
ities that degrade their security and privacy, the Cookie and Set-Cookie header
fields are widely used on the Internet. This document obsoletes RFC 2965. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/>
</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 to authenticate the sender of a
particular message. It can also be desirable to ensure that the
message was not tampered with during transit. This document
describes a way for servers and clients to simultaneously add
authentication and message integrity to HTTP messages by using a
digital signature.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"
</abstract> />
</front>
<seriesInfo name="Internet-Draft" value="draft-cavage-http-signatures- <!-- draft-cavage-http-signatures Replaced by
12"/> draft-ietf-httpbis-message-signatures.
</reference> (This doc. makes specific reference to draft-cavage-http-signatures,
<reference anchor="I-D.ietf-oauth-signed-http-request"> so need to also list the older version.) -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.cavage-
<title>A Method for Signing HTTP Requests for OAuth</title> http-signatures.xml"/>
<author fullname="Justin Richer" initials="J." surname="Richer">
<!-- draft-ietf-oauth-signed-http-request (Expired)
Have to do long way; one author is also editor. -->
<reference anchor="SIGNING-HTTP-REQS-OAUTH">
<front>
<title>A Method for Signing HTTP Requests for OAuth</title>
<author initials="J." surname="Richer" fullname="Justin Richer" role="edit
or">
</author> </author>
<author fullname="John Bradley" initials="J." surname="Bradley"> <author initials="J." surname="Bradley" fullname="John Bradley">
<organization>Ping Identity</organization> <organization>Ping Identity</organization>
</author> </author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
ig"> <organization>ARM Limited</organization>
<organization>ARM Limited</organization> </author>
</author> <date month="August" day="8" year="2016" />
<date day="8" month="August" year="2016"/> </front>
<abstract> <seriesInfo name="Internet-Draft" value="draft-ietf-oauth-signed-http-request
<t> This document a method for offering data origin authenticati -03" />
on and </reference>
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>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-signed-http-
request-03"/>
</reference>
<reference anchor="AWS-SIGv4" target="https://docs.aws.amazon.com/Amazon S3/latest/API/sig-v4-authenticating-requests.html"> <reference anchor="AWS-SIGv4" target="https://docs.aws.amazon.com/Amazon S3/latest/API/sig-v4-authenticating-requests.html">
<front> <front>
<title>Authenticating Requests (AWS Signature Version 4)</title> <title>Authenticating Requests (AWS Signature Version 4)</title>
<author> <author>
<organization/> <organization>Amazon Simple Storage Service</organization>
</author> </author>
<date>n.d.</date> <date month="March" year="2006"/>
</front> </front>
</reference> </reference>
<reference anchor="JACKSON2019" target="https://dennis-jackson.uk/assets
/pdfs/signatures.pdf"> <reference anchor="JACKSON2019" target="https://dl.acm.org/doi/10.1145/3
319535.3339813">
<front> <front>
<title>Seems Legit: Automated Analysis of Subtle Attacks on Protocol s that Use Signatures</title> <title>Seems Legit: Automated Analysis of Subtle Attacks on Protocol s that Use Signatures</title>
<author initials="D." surname="Jackson" fullname="Dennis Jackson"> <author initials="D." surname="Jackson" fullname="Dennis Jackson">
<organization>University of Oxford</organization> <organization>University of Oxford</organization>
</author> </author>
<author initials="C." surname="Cremers" fullname="Cas Cremers"> <author initials="C." surname="Cremers" fullname="Cas Cremers">
<organization>CISPA Helmholtz Center for Information Security</org anization> <organization>CISPA Helmholtz Center for Information Security</org anization>
</author> </author>
<author initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-G ordon"> <author initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-G ordon">
<organization>Independent Scholar</organization> <organization>Independent Scholar</organization>
</author> </author>
<author initials="R." surname="Sasse" fullname="Ralf Sasse"> <author initials="R." surname="Sasse" fullname="Ralf Sasse">
<organization>Department of Computer Science, ETH Zurich</organiza tion> <organization>Department of Computer Science, ETH Zurich</organiza tion>
</author> </author>
<date year="2019" month="November"/> <date year="2019" month="November"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3319535.3339813"/>
<refcontent>CCS '19: Proceedings of the 2019 ACM SIGSAC Conference on Co
mputer and Communications Security, pp. 2165-2180</refcontent>
</reference> </reference>
<reference anchor="TLS">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl />
e> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/> />
<date month="August" year="2018"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7468.xml"
<abstract> />
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</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 con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations 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 des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear 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 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
</references> </references>
<?line 2284?>
<section anchor="detection"> <section anchor="detection">
<name>Detecting HTTP Message Signatures</name> <name>Detecting HTTP Message Signatures</name>
<t>There have been many attempts to create signed HTTP messages in the pas <t>There have been many attempts to create signed HTTP messages in the pas
t, including other non-standardized definitions of the Signature field, which is t, including other non-standardized definitions of the Signature field that is u
used within this specification. It is recommended that developers wishing to su sed within this specification. It is recommended that developers wishing to supp
pport both this specification and other historical drafts do so carefully and de ort this specification, other published documents, or other historical drafts do
liberately, as incompatibilities between this specification and various versions so carefully and deliberately, as incompatibilities between this specification
of other drafts could lead to unexpected problems.</t> and other documents or various versions of other drafts could lead to unexpected
<t>It is recommended that implementers first detect and validate the Signa problems.</t>
ture-Input field defined in this specification to detect that this standard is i <t>It is recommended that implementors first detect and validate the Signa
n use and not an alternative. If the Signature-Input field is present, all Signa ture-Input field defined in this specification to detect that the mechanism desc
ture fields can be parsed and interpreted in the context of this specification.< ribed in this document is in use and not an alternative. If the Signature-Input
/t> field is present, all Signature fields can be parsed and interpreted in the cont
ext of this specification.</t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t>The following non-normative examples are provided as a means of testing <t>The following non-normative examples are provided as a means of testing
implementations of HTTP Message Signatures. The signed messages given can be us implementations of HTTP message signatures. The signed messages given can be us
ed to create the signature base with the stated parameters, creating signatures ed to create the signature base with the stated parameters, creating signatures
using the stated algorithms and keys.</t> using the stated algorithms and keys.</t>
<t>The private keys given can be used to generate signatures, though since <t>The private keys given can be used to generate signatures, though since
several of the demonstrated algorithms are nondeterministic, the results of a s several of the demonstrated algorithms are non-deterministic, the results of a
ignature are expected to be different from the exact bytes of the examples. The 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> public keys given can be used to validate all signed examples.</t>
<section anchor="example-keys"> <section anchor="example-keys">
<name>Example Keys</name> <name>Example Keys</name>
<t>This section provides cryptographic keys that are referenced in examp le signatures throughout this document. These keys <bcp14>MUST NOT</bcp14> be us ed for any purpose other than testing.</t> <t>This section provides cryptographic keys that are referenced in examp le signatures throughout this document. These keys <bcp14>MUST NOT</bcp14> be us ed for any purpose other than testing.</t>
<t>The key identifiers for each key are used throughout the examples in <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 verifie this specification. It is assumed for these examples that the signer and verifie
r can unambiguously dereference all key identifiers used here, and that the keys r can unambiguously dereference all key identifiers used here and that the keys
and algorithms used are appropriate for the context in which the signature is p and algorithms used are appropriate for the context in which the signature is pr
resented.</t> esented.</t>
<t>The components for each private key in PEM format can be displayed by <t>The components for each private key, in PEM format <xref target="RFC7
executing the following OpenSSL command:</t> 468"/>, can be displayed by executing the following OpenSSL command:</t>
<artwork><![CDATA[ <artwork><![CDATA[
openssl pkey -text openssl pkey -text
]]></artwork> ]]></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, and may require additional processing. All keys are also made available in JWK format.</t> <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 and may require additional processing. All keys are also made available in JWK f ormat.</t>
<section anchor="example-key-rsa-test"> <section anchor="example-key-rsa-test">
<name>Example Key RSA test</name> <name>Example RSA Key</name>
<t>The following key is a 2048-bit RSA public and private key pair, re ferred to in this document <t>The following key is a 2048-bit RSA public and private key pair, re ferred to in this document
as <tt>test-key-rsa</tt>. This key is encoded in PEM Format, with no encryption. </t> as <tt>test-key-rsa</tt>. This key is encoded in PEM format, with no encryption. </t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN RSA PUBLIC KEY----- -----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw
WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq
MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg
kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P
uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ
PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB
-----END RSA PUBLIC KEY----- -----END RSA PUBLIC KEY-----
skipping to change at line 2734 skipping to change at line 2466
9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn 9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn
f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo
81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa 81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa
/2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG /2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG
IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m
qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P
WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ
EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0= EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0=
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
]]></artwork> ]]></artwork>
<t>The same public and private keypair in JWK format:</t> <t>The same public and private key pair in JWK format:</t>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
{ {
"kty": "RSA", "kty": "RSA",
"kid": "test-key-rsa", "kid": "test-key-rsa",
"p": "sqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOMcCNq8Sy\ "p": "sqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOMcCNq8Sy\
YbTqgnWlB9ZfcAm_cFpA8tYci9m5vYK8HNxQr-8FS3Qo8N9RJ8d0U5CswDzMYfRgh\ YbTqgnWlB9ZfcAm_cFpA8tYci9m5vYK8HNxQr-8FS3Qo8N9RJ8d0U5CswDzMYfRgh\
AfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1mw", AfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1mw",
"q": "vSlgXQbvHzWmuUBFRHAejRh_naQTDV3GnH4lcRHuFBFZCSLn82xQS2_7xFO\ "q": "vSlgXQbvHzWmuUBFRHAejRh_naQTDV3GnH4lcRHuFBFZCSLn82xQS2_7xFO\
skipping to change at line 2773 skipping to change at line 2505
"n": "hAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrwWEBnez6\ "n": "hAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrwWEBnez6\
d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFqMGmXCQvE\ d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFqMGmXCQvE\
G7YemcxDTRPxAleIAgYYRjTSd_QBwVW9OwNFhekro3RtlinV0a75jfZgkne_YiktS\ G7YemcxDTRPxAleIAgYYRjTSd_QBwVW9OwNFhekro3RtlinV0a75jfZgkne_YiktS\
vLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0PuKxI4T-HIa\ vLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0PuKxI4T-HIa\
Fpv8-rdV6eUgOrB2xeI1dSFFn_nnv5OoZJEIB-VmuKn3DCUcCZSFlQPSXSfBDiUGh\ Fpv8-rdV6eUgOrB2xeI1dSFFn_nnv5OoZJEIB-VmuKn3DCUcCZSFlQPSXSfBDiUGh\
wOw76WuSSsf1D4b_vLoJ10w" wOw76WuSSsf1D4b_vLoJ10w"
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="example-key-rsa-pss-test"> <section anchor="example-key-rsa-pss-test">
<name>Example RSA PSS Key</name> <name>Example RSA-PSS Key</name>
<t>The following key is a 2048-bit RSA public and private key pair, re ferred to in this document <t>The following key is a 2048-bit RSA public and private key pair, re ferred to in this document
as <tt>test-key-rsa-pss</tt>. This key is PCKS#8 encoded in PEM format, with no encryption.</t> as <tt>test-key-rsa-pss</tt>. This key is PKCS #8 encoded in PEM format, with no encryption.</t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4tmm3r20Wd/PbqvP1s2 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4tmm3r20Wd/PbqvP1s2
+QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct+Lh1GH45x28Rw3Ry53mm+ +QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct+Lh1GH45x28Rw3Ry53mm+
oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7OyrFAHq oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7OyrFAHq
gDsznjPFmTOtCEcN2Z1FpWgchwuYLPL+Wokqltd11nqqzi+bJ9cvSKADYdUAAN5W gDsznjPFmTOtCEcN2Z1FpWgchwuYLPL+Wokqltd11nqqzi+bJ9cvSKADYdUAAN5W
Utzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw9lq4 Utzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw9lq4
aOT9v6d+nb4bnNkQVklLQ3fVAvJm+xdDOp9LCNCN48V2pnDOkFV6+U9nV5oyc6XI aOT9v6d+nb4bnNkQVklLQ3fVAvJm+xdDOp9LCNCN48V2pnDOkFV6+U9nV5oyc6XI
2wIDAQAB 2wIDAQAB
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
skipping to change at line 2816 skipping to change at line 2548
OGIHDRp6HjMUcxHpHw7U+S1TETxePwKLnLKj6hw8jnX2/nZRgWHzgVcY+sPsReRx OGIHDRp6HjMUcxHpHw7U+S1TETxePwKLnLKj6hw8jnX2/nZRgWHzgVcY+sPsReRx
NJVf+Cfh6yOtznfX00p+JWOXdSY8glSSHJwRAMog+hFGW1AYdt7w80XBAoGBAImR NJVf+Cfh6yOtznfX00p+JWOXdSY8glSSHJwRAMog+hFGW1AYdt7w80XBAoGBAImR
NUugqapgaEA8TrFxkJmngXYaAqpA0iYRA7kv3S4QavPBUGtFJHBNULzitydkNtVZ NUugqapgaEA8TrFxkJmngXYaAqpA0iYRA7kv3S4QavPBUGtFJHBNULzitydkNtVZ
3w6hgce0h9YThTo/nKc+OZDZbgfN9s7cQ75x0PQCAO4fx2P91Q+mDzDUVTeG30mE 3w6hgce0h9YThTo/nKc+OZDZbgfN9s7cQ75x0PQCAO4fx2P91Q+mDzDUVTeG30mE
t2m3S0dGe47JiJxifV9P3wNBNrZGSIF3mrORBVNDAoGBAI0QKn2Iv7Sgo4T/XjND t2m3S0dGe47JiJxifV9P3wNBNrZGSIF3mrORBVNDAoGBAI0QKn2Iv7Sgo4T/XjND
dl2kZTXqGAk8dOhpUiw/HdM3OGWbhHj2NdCzBliOmPyQtAr770GITWvbAI+IRYyF dl2kZTXqGAk8dOhpUiw/HdM3OGWbhHj2NdCzBliOmPyQtAr770GITWvbAI+IRYyF
S7Fnk6ZVVVHsxjtaHy1uJGFlaZzKR4AGNaUTOJMs6NadzCmGPAxNQQOCqoUjn4XR S7Fnk6ZVVVHsxjtaHy1uJGFlaZzKR4AGNaUTOJMs6NadzCmGPAxNQQOCqoUjn4XR
rOjr9w349JooGXhOxbu8nOxX rOjr9w349JooGXhOxbu8nOxX
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
]]></artwork> ]]></artwork>
<t>The same public and private keypair in JWK format:</t> <t>The same public and private key pair in JWK format:</t>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
{ {
"kty": "RSA", "kty": "RSA",
"kid": "test-key-rsa-pss", "kid": "test-key-rsa-pss",
"p": "5V-6ISI5yEaCFXm-fk1EM2xwAWekePVCAyvr9QbTlFOCZwt9WwjUjhtKRus\ "p": "5V-6ISI5yEaCFXm-fk1EM2xwAWekePVCAyvr9QbTlFOCZwt9WwjUjhtKRus\
i5Uq-IYZ_tq2WRE4As4b_FHEMtp2AER43IcvmXPqKFBoUktVDS7dThIHrsnRi1U7d\ i5Uq-IYZ_tq2WRE4As4b_FHEMtp2AER43IcvmXPqKFBoUktVDS7dThIHrsnRi1U7d\
HqVdwiMEMe5jxKNgnsKLpnq-4NyhoS6OeWu1SFozG9J9xQk", HqVdwiMEMe5jxKNgnsKLpnq-4NyhoS6OeWu1SFozG9J9xQk",
"q": "w-wIde17W5Y0Cphp3ZZ0uM8OUq1AkrV2IKauqYHaDxAT32EM4ci2MMER2nI\ "q": "w-wIde17W5Y0Cphp3ZZ0uM8OUq1AkrV2IKauqYHaDxAT32EM4ci2MMER2nI\
skipping to change at line 2857 skipping to change at line 2589
dTrifbIFPNU8PPMO7OyrFAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL-Wokqltd11\ dTrifbIFPNU8PPMO7OyrFAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL-Wokqltd11\
nqqzi-bJ9cvSKADYdUAAN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSy\ nqqzi-bJ9cvSKADYdUAAN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSy\
ZYoA485mqcO0GVAdVw9lq4aOT9v6d-nb4bnNkQVklLQ3fVAvJm-xdDOp9LCNCN48V\ ZYoA485mqcO0GVAdVw9lq4aOT9v6d-nb4bnNkQVklLQ3fVAvJm-xdDOp9LCNCN48V\
2pnDOkFV6-U9nV5oyc6XI2w" 2pnDOkFV6-U9nV5oyc6XI2w"
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="example-key-ecc-p256"> <section anchor="example-key-ecc-p256">
<name>Example ECC P-256 Test Key</name> <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 <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. This key is encoded in PEM format, wi th no encryption.</t> to in this document as <tt>test-key-ecc-p256</tt>. This key is encoded in PEM fo rmat, with no encryption.</t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lf MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lf
w0EkjqF7xB4FivAxzic30tMM4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ== w0EkjqF7xB4FivAxzic30tMM4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ==
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKbhfNZfpDsW43+0+JjUr9K+bTeuxopu653+hBaXGA7oAoGCCqGSM49 MHcCAQEEIFKbhfNZfpDsW43+0+JjUr9K+bTeuxopu653+hBaXGA7oAoGCCqGSM49
AwEHoUQDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lfw0EkjqF7xB4FivAxzic30tMM AwEHoUQDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lfw0EkjqF7xB4FivAxzic30tMM
4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ== 4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></artwork> ]]></artwork>
<t>The same public and private keypair in JWK format:</t> <t>The same public and private key pair in JWK format:</t>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"kid": "test-key-ecc-p256", "kid": "test-key-ecc-p256",
"d": "UpuF81l-kOxbjf7T4mNSv0r5tN67Gim7rnf6EFpcYDs", "d": "UpuF81l-kOxbjf7T4mNSv0r5tN67Gim7rnf6EFpcYDs",
"x": "qIVYZVLCrPZHGHjP17CTW0_-D9Lfw0EkjqF7xB4FivA", "x": "qIVYZVLCrPZHGHjP17CTW0_-D9Lfw0EkjqF7xB4FivA",
"y": "Mc4nN9LTDOBhfoUeg8Ye9WedFRhnZXZJA12Qp0zZ6F0" "y": "Mc4nN9LTDOBhfoUeg8Ye9WedFRhnZXZJA12Qp0zZ6F0"
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="example-key-ed25519"> <section anchor="example-key-ed25519">
<name>Example Ed25519 Test Key</name> <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 encoded in PEM format, with no encryption.</t> <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 PKCS #8 encoded in PEM format, with no encryption.</t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs= MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIJ+DYvh6SEqVTm50DFtMDoQikTmiCqirVv9mWG9qfSnF MC4CAQAwBQYDK2VwBCIEIJ+DYvh6SEqVTm50DFtMDoQikTmiCqirVv9mWG9qfSnF
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
]]></artwork> ]]></artwork>
<t>The same public and private keypair in JWK format:</t> <t>The same public and private key pair in JWK format:</t>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"kty": "OKP", "kty": "OKP",
"crv": "Ed25519", "crv": "Ed25519",
"kid": "test-key-ed25519", "kid": "test-key-ed25519",
"d": "n4Ni-HpISpVObnQMW0wOhCKROaIKqKtW_2ZYb2p9KcU", "d": "n4Ni-HpISpVObnQMW0wOhCKROaIKqKtW_2ZYb2p9KcU",
"x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs" "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs"
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="example-shared-secret"> <section anchor="example-shared-secret">
<name>Example Shared Secret</name> <name>Example Shared Secret</name>
<t>The following shared secret is 64 randomly-generated bytes encoded <t>The following shared secret is 64 randomly generated bytes encoded
in Base64, in Base64,
referred to in this document as <tt>test-shared-secret</tt>.</t> referred to in this document as <tt>test-shared-secret</tt>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
uzvJfB4u3N0Jy4T7NZ75MDVcr8zSTInedJtkgcu46YW4XByzNJjxBdtjUkdJPBt\ uzvJfB4u3N0Jy4T7NZ75MDVcr8zSTInedJtkgcu46YW4XByzNJjxBdtjUkdJPBt\
bmHhIDi6pcl8jsasjlTMtDQ== bmHhIDi6pcl8jsasjlTMtDQ==
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="test-cases"> <section anchor="test-cases">
<name>Test Cases</name> <name>Test Cases</name>
skipping to change at line 2941 skipping to change at line 2673
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>For responses, this <tt>test-response</tt> message is used:</t> <t>For responses, this <tt>test-response</tt> message is used:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 20 Apr 2021 02:07:56 GMT Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json Content-Type: application/json
Content-Digest: sha-512=:JlEy2bfUz7WrWIjc1qV6KVLpdr/7L5/L4h7Sxvh6sN\ Content-Digest: sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ41Q\
HpDQWDCL+GauFQWcZBvVDhiyOnAQsxzZFYwi0wDH+1pw==: JgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
Content-Length: 23 Content-Length: 23
{"message": "good dog"} {"message": "good dog"}
]]></sourcecode> ]]></sourcecode>
<section anchor="minimal-signature-using-rsa-pss-sha512"> <section anchor="minimal-signature-using-rsa-pss-sha512">
<name>Minimal Signature Using rsa-pss-sha512</name> <name>Minimal Signature Using rsa-pss-sha512</name>
<t>This example presents a minimal signature using the <tt>rsa-pss-sha 512</tt> algorithm over <tt>test-request</tt>, covering none <t>This example presents a minimal signature using the <tt>rsa-pss-sha 512</tt> algorithm over <tt>test-request</tt>, covering none
of the components of the HTTP message, but providing a timestamped signature pro of of possession of the key with a signer-provided nonce.</t> of the components of the HTTP message but providing a timestamped signature proo f of possession of the key with a signer-provided nonce.</t>
<t>The corresponding signature base is:</t> <t>The corresponding signature base is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@signature-params": ();created=1618884473;keyid="test-key-rsa-pss"\ "@signature-params": ();created=1618884473;keyid="test-key-rsa-pss"\
;nonce="b3k2pp5k7z-50gnwp.yemd" ;nonce="b3k2pp5k7z-50gnwp.yemd"
]]></artwork> ]]></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 > <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[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b21=();created=1618884473\ Signature-Input: sig-b21=();created=1618884473\
;keyid="test-key-rsa-pss";nonce="b3k2pp5k7z-50gnwp.yemd" ;keyid="test-key-rsa-pss";nonce="b3k2pp5k7z-50gnwp.yemd"
Signature: sig-b21=:d2pmTvmbncD3xQm8E9ZV2828BjQWGgiwAaw5bAkgibUopem\ Signature: sig-b21=:d2pmTvmbncD3xQm8E9ZV2828BjQWGgiwAaw5bAkgibUopem\
LJcWDy/lkbbHAve4cRAtx31Iq786U7it++wgGxbtRxf8Udx7zFZsckzXaJMkA7ChG\ LJcWDy/lkbbHAve4cRAtx31Iq786U7it++wgGxbtRxf8Udx7zFZsckzXaJMkA7ChG\
52eSkFxykJeNqsrWH5S+oxNFlD4dzVuwe8DhTSja8xxbR/Z2cOGdCbzR72rgFWhzx\ 52eSkFxykJeNqsrWH5S+oxNFlD4dzVuwe8DhTSja8xxbR/Z2cOGdCbzR72rgFWhzx\
2VjBqJzsPLMIQKhO4DGezXehhWwE56YCE+O6c0mKZsfxVrogUvA4HELjVKWmAvtl6\ 2VjBqJzsPLMIQKhO4DGezXehhWwE56YCE+O6c0mKZsfxVrogUvA4HELjVKWmAvtl6\
UnCh8jYzuVG5WSb/QEVPnP5TmcAnLH1g+s++v6d4s8m0gCw1fV5/SITLq9mhho8K3\ UnCh8jYzuVG5WSb/QEVPnP5TmcAnLH1g+s++v6d4s8m0gCw1fV5/SITLq9mhho8K3\
+7EPYTU8IU1bLhdxO5Nyt8C8ssinQ98Xw9Q==: +7EPYTU8IU1bLhdxO5Nyt8C8ssinQ98Xw9Q==:
]]></sourcecode> ]]></sourcecode>
<t>Note that since the covered components list is empty, this signatur <t>Note that since the covered components list is empty, this signatur
e could be applied by an attacker to an unrelated HTTP message. In this example, e 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 bei the <tt>nonce</tt> parameter is included to prevent the same signature from bei
ng replayed more than once, but if an attacker intercepts the signature and prev ng replayed more than once, but if an attacker intercepts the signature and prev
ents its delivery to the verifier, the attacker could apply this signature to an ents its delivery to the verifier, the attacker could apply this signature to an
other message. Therefore, use of an empty covered components set is discouraged. other message. Therefore, the use of an empty covered components set is discoura
See <xref target="security-coverage"/> for more discussion.</t> ged. See <xref target="security-coverage"/> for more discussion.</t>
<t>Note that the RSA PSS algorithm in use here is non-deterministic, m <t>Note that the RSA-PSS algorithm in use here is non-deterministic, m
eaning a different signature value will be created every time the algorithm is r eaning that a different signature value will be created every time the algorithm
un. The signature value provided here can be validated against the given keys, b is run. The signature value provided here can be validated against the given ke
ut newly-generated signature values are not expected to match the example. See < ys, but newly generated signature values are not expected to match the example.
xref target="security-nondeterministic"/>.</t> See <xref target="security-nondeterministic"/>.</t>
</section> </section>
<section anchor="selective-covered-components-using-rsa-pss-sha512"> <section anchor="selective-covered-components-using-rsa-pss-sha512">
<name>Selective Covered Components using rsa-pss-sha512</name> <name>Selective Covered Components Using rsa-pss-sha512</name>
<t>This example covers additional components (the authority, the Conte nt-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>t ag</tt> parameter with the application-specific value of <tt>header-example</tt> .</t> <t>This example covers additional components (the authority, the Conte nt-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>t ag</tt> parameter with the application-specific value of <tt>header-example</tt> .</t>
<t>The corresponding signature base is:</t> <t>The corresponding signature base is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@authority": example.com "@authority": example.com
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\ "content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@query-param";name="Pet": dog "@query-param";name="Pet": dog
"@signature-params": ("@authority" "content-digest" \ "@signature-params": ("@authority" "content-digest" \
skipping to change at line 3004 skipping to change at line 2736
Signature-Input: sig-b22=("@authority" "content-digest" \ Signature-Input: sig-b22=("@authority" "content-digest" \
"@query-param";name="Pet");created=1618884473\ "@query-param";name="Pet");created=1618884473\
;keyid="test-key-rsa-pss";tag="header-example" ;keyid="test-key-rsa-pss";tag="header-example"
Signature: sig-b22=:LjbtqUbfmvjj5C5kr1Ugj4PmLYvx9wVjZvD9GsTT4F7GrcQ\ Signature: sig-b22=:LjbtqUbfmvjj5C5kr1Ugj4PmLYvx9wVjZvD9GsTT4F7GrcQ\
EdJzgI9qHxICagShLRiLMlAJjtq6N4CDfKtjvuJyE5qH7KT8UCMkSowOB4+ECxCmT\ EdJzgI9qHxICagShLRiLMlAJjtq6N4CDfKtjvuJyE5qH7KT8UCMkSowOB4+ECxCmT\
8rtAmj/0PIXxi0A0nxKyB09RNrCQibbUjsLS/2YyFYXEu4TRJQzRw1rLEuEfY17SA\ 8rtAmj/0PIXxi0A0nxKyB09RNrCQibbUjsLS/2YyFYXEu4TRJQzRw1rLEuEfY17SA\
RYhpTlaqwZVtR8NV7+4UKkjqpcAoFqWFQh62s7Cl+H2fjBSpqfZUJcsIk4N6wiKYd\ RYhpTlaqwZVtR8NV7+4UKkjqpcAoFqWFQh62s7Cl+H2fjBSpqfZUJcsIk4N6wiKYd\
4je2U/lankenQ99PZfB4jY3I5rSV2DSBVkSFsURIjYErOs0tFTQosMTAoxk//0RoK\ 4je2U/lankenQ99PZfB4jY3I5rSV2DSBVkSFsURIjYErOs0tFTQosMTAoxk//0RoK\
UqiYY8Bh0aaUEb0rQl3/XaVe4bXTugEjHSw==: UqiYY8Bh0aaUEb0rQl3/XaVe4bXTugEjHSw==:
]]></sourcecode> ]]></sourcecode>
<t>Note that the RSA PSS algorithm in use here is non-deterministic, m eaning a different signature value will be created every time the algorithm is r un. The signature value provided here can be validated against the given keys, b ut newly-generated signature values are not expected to match the example. See < xref target="security-nondeterministic"/>.</t> <t>Note that the RSA-PSS algorithm in use here is non-deterministic, m eaning 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 ke ys, but newly generated signature values are not expected to match the example. See <xref target="security-nondeterministic"/>.</t>
</section> </section>
<section anchor="full-coverage-using-rsa-pss-sha512"> <section anchor="full-coverage-using-rsa-pss-sha512">
<name>Full Coverage using rsa-pss-sha512</name> <name>Full Coverage Using rsa-pss-sha512</name>
<t>This example covers all applicable message components in <tt>test-r <t>This example covers all applicable message components in <tt>test-r
equest</tt> (including the content type and length) plus many derived components equest</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> , again using the <tt>rsa-pss-sha512</tt> algorithm. Note that the Host header f
header field is not covered because the <tt>@authority</tt> derived component i ield is not covered because the <tt>@authority</tt> derived component is include
s included instead.</t> d instead.</t>
<t>The corresponding signature base is:</t> <t>The corresponding signature base is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"date": Tue, 20 Apr 2021 02:07:55 GMT "date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST "@method": POST
"@path": /foo "@path": /foo
"@query": ?param=Value&Pet=dog "@query": ?param=Value&Pet=dog
"@authority": example.com "@authority": example.com
"content-type": application/json "content-type": application/json
skipping to change at line 3040 skipping to change at line 2772
Signature-Input: sig-b23=("date" "@method" "@path" "@query" \ Signature-Input: sig-b23=("date" "@method" "@path" "@query" \
"@authority" "content-type" "content-digest" "content-length")\ "@authority" "content-type" "content-digest" "content-length")\
;created=1618884473;keyid="test-key-rsa-pss" ;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig-b23=:bbN8oArOxYoyylQQUU6QYwrTuaxLwjAC9fbY2F6SVWvh0yB\ Signature: sig-b23=:bbN8oArOxYoyylQQUU6QYwrTuaxLwjAC9fbY2F6SVWvh0yB\
iMIRGOnMYwZ/5MR6fb0Kh1rIRASVxFkeGt683+qRpRRU5p2voTp768ZrCUb38K0fU\ iMIRGOnMYwZ/5MR6fb0Kh1rIRASVxFkeGt683+qRpRRU5p2voTp768ZrCUb38K0fU\
xN0O0iC59DzYx8DFll5GmydPxSmme9v6ULbMFkl+V5B1TP/yPViV7KsLNmvKiLJH1\ xN0O0iC59DzYx8DFll5GmydPxSmme9v6ULbMFkl+V5B1TP/yPViV7KsLNmvKiLJH1\
pFkh/aYA2HXXZzNBXmIkoQoLd7YfW91kE9o/CCoC1xMy7JA1ipwvKvfrs65ldmlu9\ pFkh/aYA2HXXZzNBXmIkoQoLd7YfW91kE9o/CCoC1xMy7JA1ipwvKvfrs65ldmlu9\
bpG6A9BmzhuzF8Eim5f8ui9eH8LZH896+QIF61ka39VBrohr9iyMUJpvRX2Zbhl5Z\ bpG6A9BmzhuzF8Eim5f8ui9eH8LZH896+QIF61ka39VBrohr9iyMUJpvRX2Zbhl5Z\
JzSRxpJyoEZAFL2FUo5fTIztsDZKEgM4cUA==: JzSRxpJyoEZAFL2FUo5fTIztsDZKEgM4cUA==:
]]></sourcecode> ]]></sourcecode>
<t>Note in this example that the value of the <tt>Date</tt> header and <t>Note in this example that the value of the Date header field and th
the value of the <tt>created</tt> signature parameter need not be the same. Thi e value of the <tt>created</tt> signature parameter need not be the same. This i
s is due to the fact that the <tt>Date</tt> header is added when creating the HT s due to the fact that the Date header field is added when creating the HTTP mes
TP Message and the <tt>created</tt> parameter is populated when creating the sig sage and the <tt>created</tt> parameter is populated when creating the signature
nature over that message, and these two times could vary. If the <tt>Date</tt> h over that message, and these two times could vary. If the Date header field is
eader is covered by the signature, it is up to the verifier to determine whether covered by the signature, it is up to the verifier to determine whether its valu
its value has to match that of the <tt>created</tt> parameter or not. See <xref e has to match that of the <tt>created</tt> parameter or not. See <xref target="
target="security-not-fields"/> for more discussion.</t> security-not-fields"/> for more discussion.</t>
<t>Note that the RSA PSS algorithm in use here is non-deterministic, m <t>Note that the RSA-PSS algorithm in use here is non-deterministic, m
eaning a different signature value will be created every time the algorithm is r eaning that a different signature value will be created every time the algorithm
un. The signature value provided here can be validated against the given keys, b is run. The signature value provided here can be validated against the given ke
ut newly-generated signature values are not expected to match the example. See < ys, but newly generated signature values are not expected to match the example.
xref target="security-nondeterministic"/>.</t> See <xref target="security-nondeterministic"/>.</t>
</section> </section>
<section anchor="signing-a-response-using-ecdsa-p256-sha256"> <section anchor="signing-a-response-using-ecdsa-p256-sha256">
<name>Signing a Response using ecdsa-p256-sha256</name> <name>Signing a Response Using ecdsa-p256-sha256</name>
<t>This example covers portions of the <tt>test-response</tt> response <t>This example covers portions of the <tt>test-response</tt> message
message using the <tt>ecdsa-p256-sha256</tt> algorithm using the <tt>ecdsa-p256-sha256</tt> algorithm
and the key <tt>test-key-ecc-p256</tt>.</t> and the key <tt>test-key-ecc-p256</tt>.</t>
<t>The corresponding signature base is:</t> <t>The corresponding signature base is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@status": 200 "@status": 200
"content-type": application/json "content-type": application/json
"content-digest": sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ4\ "content-digest": sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ4\
1QJgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==: 1QJgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
"content-length": 23 "content-length": 23
skipping to change at line 3069 skipping to change at line 2801
<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> <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[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b24=("@status" "content-type" \ Signature-Input: sig-b24=("@status" "content-type" \
"content-digest" "content-length");created=1618884473\ "content-digest" "content-length");created=1618884473\
;keyid="test-key-ecc-p256" ;keyid="test-key-ecc-p256"
Signature: sig-b24=:wNmSUAhwb5LxtOtOpNa6W5xj067m5hFrj0XQ4fvpaCLx0NK\ Signature: sig-b24=:wNmSUAhwb5LxtOtOpNa6W5xj067m5hFrj0XQ4fvpaCLx0NK\
ocgPquLgyahnzDnDAUy5eCdlYUEkLIj+32oiasw==: ocgPquLgyahnzDnDAUy5eCdlYUEkLIj+32oiasw==:
]]></sourcecode> ]]></sourcecode>
<t>Note that the ECDSA algorithm in use here is non-deterministic, mea ning a different signature value will be created every time the algorithm is run . The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example. See <xr ef target="security-nondeterministic"/>.</t> <t>Note that the ECDSA signature algorithm in use here is non-determin istic, meaning that a different signature value will be created every time the a lgorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the e xample. See <xref target="security-nondeterministic"/>.</t>
</section> </section>
<section anchor="signing-a-request-using-hmac-sha256"> <section anchor="signing-a-request-using-hmac-sha256">
<name>Signing a Request using hmac-sha256</name> <name>Signing a Request Using hmac-sha256</name>
<t>This example covers portions of the <tt>test-request</tt> using the <t>This example covers portions of the <tt>test-request</tt> message u
<tt>hmac-sha256</tt> algorithm and the sing the <tt>hmac-sha256</tt> algorithm and the
secret <tt>test-shared-secret</tt>.</t> secret <tt>test-shared-secret</tt>.</t>
<t>The corresponding signature base is:</t> <t>The corresponding signature base is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"date": Tue, 20 Apr 2021 02:07:55 GMT "date": Tue, 20 Apr 2021 02:07:55 GMT
"@authority": example.com "@authority": example.com
"content-type": application/json "content-type": application/json
"@signature-params": ("date" "@authority" "content-type")\ "@signature-params": ("date" "@authority" "content-type")\
;created=1618884473;keyid="test-shared-secret" ;created=1618884473;keyid="test-shared-secret"
]]></artwork> ]]></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> <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[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b25=("date" "@authority" "content-type")\ Signature-Input: sig-b25=("date" "@authority" "content-type")\
;created=1618884473;keyid="test-shared-secret" ;created=1618884473;keyid="test-shared-secret"
Signature: sig-b25=:pxcQw6G3AjtMBQjwo8XzkZf/bws5LelbaMk5rGIGtE8=: Signature: sig-b25=:pxcQw6G3AjtMBQjwo8XzkZf/bws5LelbaMk5rGIGtE8=:
]]></sourcecode> ]]></sourcecode>
<t>Before using symmetric signatures in practice, see the discussion o f the security tradeoffs in <xref target="security-symmetric"/>.</t> <t>Before using symmetric signatures in practice, see the discussion r egarding security trade-offs in <xref target="security-symmetric"/>.</t>
</section> </section>
<section anchor="signing-a-request-using-ed25519"> <section anchor="signing-a-request-using-ed25519">
<name>Signing a Request using ed25519</name> <name>Signing a Request Using ed25519</name>
<t>This example covers portions of the <tt>test-request</tt> using the <t>This example covers portions of the <tt>test-request</tt> message u
<tt>ed25519</tt> algorithm sing the <tt>Ed25519</tt> algorithm
and the key <tt>test-key-ed25519</tt>.</t> and the key <tt>test-key-ed25519</tt>.</t>
<t>The corresponding signature base is:</t> <t>The corresponding signature base is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"date": Tue, 20 Apr 2021 02:07:55 GMT "date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST "@method": POST
"@path": /foo "@path": /foo
"@authority": example.com "@authority": example.com
"content-type": application/json "content-type": application/json
skipping to change at line 3127 skipping to change at line 2859
Signature-Input: sig-b26=("date" "@method" "@path" "@authority" \ Signature-Input: sig-b26=("date" "@method" "@path" "@authority" \
"content-type" "content-length");created=1618884473\ "content-type" "content-length");created=1618884473\
;keyid="test-key-ed25519" ;keyid="test-key-ed25519"
Signature: sig-b26=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1\ Signature: sig-b26=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1\
u02Gb04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==: u02Gb04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==:
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="tls-terminating-proxies"> <section anchor="tls-terminating-proxies">
<name>TLS-Terminating Proxies</name> <name>TLS-Terminating Proxies</name>
<t>In this example, there is a TLS-terminating reverse proxy sitting in <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 mut front of the resource. The client does not sign the request but instead uses mut
ual TLS to make its call. The terminating proxy validates the TLS stream and inj ual TLS to make its call. The terminating proxy validates the TLS stream and inj
ects a <tt>Client-Cert</tt> header according to <xref target="CLIENT-CERT"/>, an ects a Client-Cert header field according to <xref target="RFC9440"/>, and then
d then applies a signature to this field. By signing this header field, a revers applies a signature to this field. By signing this header field, a reverse proxy
e proxy can not only attest to its own validation of the initial request's TLS p not only can attest to its own validation of the initial request's TLS paramete
arameters but also authenticate itself to the backend system independently of th rs but can also authenticate itself to the backend system independently of the c
e client's actions.</t> lient's actions.</t>
<t>The client makes the following request to the TLS terminating proxy u <t>The client makes the following request to the TLS-terminating proxy u
sing mutual TLS:</t> sing mutual TLS:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>The proxy processes the TLS connection and extracts the client's TLS certificate to a <tt>Client-Cert</tt> header field and passes it along to the in ternal service hosted at <tt>service.internal.example</tt>. This results in the following unsigned request:</t> <t>The proxy processes the TLS connection and extracts the client's TLS certificate to a Client-Cert header field and passes it along to the internal se rvice hosted at <tt>service.internal.example</tt>. This results in the following unsigned request:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\ Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\ BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\ AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\ wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\ C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\ R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\ 8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\ 4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=: bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
{"hello": "world"} {"hello": "world"}
]]></sourcecode> ]]></sourcecode>
<t>Without a signature, the internal service would need to trust that th e incoming connection has the right information. By signing the <tt>Client-Cert< /tt> header 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> <t>Without a signature, the internal service would need to trust that th e incoming connection has the right information. By signing the Client-Cert head er 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 an d presented it to the correct service. The proxy's signature base consists of th e following:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
"@path": /foo "@path": /foo
"@query": ?param=Value&Pet=dog "@query": ?param=Value&Pet=dog
"@method": POST "@method": POST
"@authority": service.internal.example "@authority": service.internal.example
"client-cert": :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQ\ "client-cert": :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQ\
KDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBD\ KDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBD\
QTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDM\ QTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDM\
skipping to change at line 3186 skipping to change at line 2918
"@signature-params": ("@path" "@query" "@method" "@authority" \ "@signature-params": ("@path" "@query" "@method" "@authority" \
"client-cert");created=1618884473;keyid="test-key-ecc-p256" "client-cert");created=1618884473;keyid="test-key-ecc-p256"
]]></artwork> ]]></artwork>
<t>This results in the following signature:</t> <t>This results in the following signature:</t>
<artwork><![CDATA[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\ xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\
zhD9ah4JHRwMLOgmizw== zhD9ah4JHRwMLOgmizw==
]]></artwork> ]]></artwork>
<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> <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[ <artwork><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /foo?param=Value&Pet=dog HTTP/1.1 POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json Content-Type: application/json
Content-Length: 18 Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\ Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\ BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
skipping to change at line 3215 skipping to change at line 2947
"client-cert");created=1618884473;keyid="test-key-ecc-p256" "client-cert");created=1618884473;keyid="test-key-ecc-p256"
Signature: ttrp=:xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6\ Signature: ttrp=:xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6\
Mce9315T6xoklyy0yzhD9ah4JHRwMLOgmizw==: Mce9315T6xoklyy0yzhD9ah4JHRwMLOgmizw==:
{"hello": "world"} {"hello": "world"}
]]></artwork> ]]></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> <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>
<section anchor="example-transform"> <section anchor="example-transform">
<name>HTTP Message Transformations</name> <name>HTTP Message Transformations</name>
<t>The HTTP protocol allows intermediaries and applications to transform <t>HTTP allows intermediaries and applications to transform an HTTP mess
an HTTP message without affecting the semantics of the message itself. HTTP mes age without affecting the semantics of the message itself. HTTP message signatur
sage signatures are designed to be robust against many of these transformations es are designed to be robust against many of these transformations in different
in different circumstances.</t> circumstances.</t>
<t>For example, the following HTTP request message has been signed using <t>For example, the following HTTP request message has been signed using
the <tt>ed25519</tt> algorithm the <tt>Ed25519</tt> algorithm
and the key <tt>test-key-ed25519</tt>.</t> and the key <tt>test-key-ed25519</tt>:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
GET /demo?name1=Value1&Name2=value2 HTTP/1.1 GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json Accept: application/json
Accept: */* Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \ Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519" "accept");created=1618884473;keyid="test-key-ed25519"
skipping to change at line 3240 skipping to change at line 2972
]]></sourcecode> ]]></sourcecode>
<t>The signature base string for this message is:</t> <t>The signature base string for this message is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
"@method": GET "@method": GET
"@path": /demo "@path": /demo
"@authority": example.org "@authority": example.org
"accept": application/json, */* "accept": application/json, */*
"@signature-params": ("@method" "@path" "@authority" "accept")\ "@signature-params": ("@method" "@path" "@authority" "accept")\
;created=1618884473;keyid="test-key-ed25519" ;created=1618884473;keyid="test-key-ed25519"
]]></artwork> ]]></artwork>
<t>The following message has been altered by adding the Accept-Language header as well as adding a query parameter. However, since neither the Accept-La nguage header nor the query are covered by the signature, the same signature is still valid:</t> <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 Acc ept-Language header field nor the query is covered by the signature, the same si gnature is still valid:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
GET /demo?name1=Value1&Name2=value2&param=added HTTP/1.1 GET /demo?name1=Value1&Name2=value2&param=added HTTP/1.1
Host: example.org Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json Accept: application/json
Accept: */* Accept: */*
Accept-Language: en-US,en;q=0.5 Accept-Language: en-US,en;q=0.5
Signature-Input: transform=("@method" "@path" "@authority" \ Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519" "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\ Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode> ]]></sourcecode>
<t>The following message has been altered by removing the Date header, a dding a Referer header, and collapsing the Accept header into a single line. The Date and Referrer headers are not covered by the signature, and the collapsing of the Accept header is an allowed transformation that is already accounted for by the canonicalization algorithm for HTTP field values. The same signature is s till valid:</t> <t>The following message has been altered by removing the Date header fi eld, adding a Referer header field, and collapsing the Accept header field into a single line. The Date and Referer header fields are not covered by the signatu re, and the collapsing of the Accept header field is an allowed transformation t hat is already accounted for by the canonicalization algorithm for HTTP field va lues. The same signature is still valid:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
GET /demo?name1=Value1&Name2=value2 HTTP/1.1 GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org Host: example.org
Referer: https://developer.example.org/demo Referer: https://developer.example.org/demo
Accept: application/json, */* Accept: application/json, */*
Signature-Input: transform=("@method" "@path" "@authority" \ Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519" "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\ Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode> ]]></sourcecode>
<t>The following message has been altered by re-ordering the field value s of the original message, but not re-ordering the individual Accept headers. Th e same signature is still valid:</t> <t>The following message has been altered by reordering the field values of the original message but not reordering the individual Accept header fields. The same signature is still valid:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
GET /demo?name1=Value1&Name2=value2 HTTP/1.1 GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Accept: application/json Accept: application/json
Accept: */* Accept: */*
Date: Fri, 15 Jul 2022 14:24:55 GMT Date: Fri, 15 Jul 2022 14:24:55 GMT
Host: example.org Host: example.org
Signature-Input: transform=("@method" "@path" "@authority" \ Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519" "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\ Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode> ]]></sourcecode>
<t>The following message has been altered by changing the method to POST and the authority to "example.com" (inside the Host header). Since both the met hod and authority are covered by the signature, the same signature is NOT still valid:</t> <t>The following message has been altered by changing the method to POST and the authority to "example.com" (inside the Host header field). Since both t he method and authority are covered by the signature, the same signature is NOT still valid:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /demo?name1=Value1&Name2=value2 HTTP/1.1 POST /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.com Host: example.com
Date: Fri, 15 Jul 2022 14:24:55 GMT Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json Accept: application/json
Accept: */* Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \ Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519" "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\ Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode> ]]></sourcecode>
<t>The following message has been altered by changing the order of the t wo instances of the Accept header. Since the order of fields with the same name is semantically significant in HTTP, this changes the value used in the signatur e base, and the same signature is NOT still valid:</t> <t>The following message has been altered by changing the order of the t wo instances of the Accept header field. Since the order of fields with the same name is semantically significant in HTTP, this changes the value used in the si gnature base, and the same signature is NOT still valid:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
GET /demo?name1=Value1&Name2=value2 HTTP/1.1 GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: */* Accept: */*
Accept: application/json Accept: application/json
Signature-Input: transform=("@method" "@path" "@authority" \ Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519" "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\ Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>This specification was initially based on the <xref target="I-D.cavage- <t>This specification was initially based on <xref target="I-D.cavage-http
http-signatures"/> internet draft. The editors would like to thank the authors o -signatures"/>. The editors would like to thank the authors of <xref target="I-D
f that draft, Mark Cavage and Manu Sporny, for their work on that draft and thei .cavage-http-signatures"/> -- <contact fullname="Mark Cavage"/> and <contact ful
r continuing contributions. The specification also includes contributions from t lname="Manu Sporny"/> -- for their work on that Internet-Draft and their continu
he <xref target="I-D.ietf-oauth-signed-http-request"/> internet draft and other ing contributions. This specification also includes contributions from <xref tar
similar efforts.</t> get="SIGNING-HTTP-REQS-OAUTH"/> and other similar efforts.</t>
<t>The editors would also like to thank the following individuals for feed <t>The editors would also like to thank the following individuals (listed
back, insight, and implementation of this draft and its predecessors (in alphabe in alphabetical order) for feedback, insight, and implementation of this documen
tical order): t and its predecessors:
Mark Adamcin, <contact fullname="Mark Adamcin"/>,
Mark Allen, <contact fullname="Mark Allen"/>,
Paul Annesley, <contact fullname="Paul Annesley"/>,
<contact fullname="Karl Böhlmark"/>, <contact fullname="Karl Böhlmark"/>,
<contact fullname="Stéphane Bortzmeyer"/>, <contact fullname="Stéphane Bortzmeyer"/>,
Sarven Capadisli, <contact fullname="Sarven Capadisli"/>,
Liam Dennehy, <contact fullname="Liam Dennehy"/>,
Stephen Farrell, <contact fullname="Stephen Farrell"/>,
Phillip Hallam-Baker, <contact fullname="Phillip Hallam-Baker"/>,
Tyler Ham, <contact fullname="Tyler Ham"/>,
Eric Holmes, <contact fullname="Eric Holmes"/>,
Andrey Kislyuk, <contact fullname="Andrey Kislyuk"/>,
Adam Knight, <contact fullname="Adam Knight"/>,
Dave Lehn, <contact fullname="Dave Lehn"/>,
Dave Longley, <contact fullname="Ilari Liusvaara"/>,
Ilari Liusvaara, <contact fullname="Dave Longley"/>,
James H. Manger, <contact fullname="James H. Manger"/>,
Kathleen Moriarty, <contact fullname="Kathleen Moriarty"/>,
Mark Nottingham, <contact fullname="Yoav Nir"/>,
Yoav Nir, <contact fullname="Mark Nottingham"/>,
Adrian Palmer, <contact fullname="Adrian Palmer"/>,
Lucas Pardue, <contact fullname="Lucas Pardue"/>,
Roberto Polli, <contact fullname="Roberto Polli"/>,
Julian Reschke, <contact fullname="Julian Reschke"/>,
Michael Richardson, <contact fullname="Michael Richardson"/>,
Wojciech Rygielski, <contact fullname="Wojciech Rygielski"/>,
Rich Salz, <contact fullname="Rich Salz"/>,
Adam Scarr, <contact fullname="Adam Scarr"/>,
Cory J. Slep, <contact fullname="Cory J. Slep"/>,
Dirk Stein, <contact fullname="Dirk Stein"/>,
Henry Story, <contact fullname="Henry Story"/>,
Lukasz Szewc, <contact fullname="Lukasz Szewc"/>,
Chris Webber, and <contact fullname="Chris Webber"/>, and
Jeffrey Yasskin.</t> <contact fullname="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 w
hy 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 S
ignature 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.</l
i>
<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 guidelin
es.</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 "s
ignature 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 relate
d-response for specialty components.</li>
</ul>
</li>
<li>
<t>-06
</t>
<ul spacing="normal">
<li>Updated language for message components, including identifie
rs and values.</li>
<li>Clarified that Signature-Input and Signature are fields whic
h can be used as headers or trailers.</li>
<li>Add "Accept-Signature" field and semantics for signature neg
otiation.</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 fulfil
l.</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" obje
ct 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>Sig
nature-Input</tt> and <tt>Signature</tt> Dictionary Structured Header Fields.</l
i>
<li>Defined content identifiers for individual Dictionary member
s, 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 us
e 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</bcp1
4>).</li>
<li>Added real example values for Creation Time and Expiration T
ime.</li>
<li>Minor editorial corrections and readability improvements.</l
i>
</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 s
tyle guides.</li>
<li>Removed Signature auth-scheme definition and related content
.</li>
<li>Removed conflicting normative requirements for use of algori
thm parameter. Now <bcp14>MUST NOT</bcp14> be relied upon.</li>
<li>Removed Extensions appendix.</li>
<li>Rewrote abstract and introduction to explain context and nee
d, 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 HTT
P terms.</li>
<li>Added examples for canonicalization and signature generation
steps.</li>
<li>Rewrote Signature header definition, retaining normative req
uirements.</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 and informative references.</li>
<li>Added Topics for Working Group Discussion section, to be rem
oved prior to publication as an RFC.</li>
</ul>
</li>
</ul>
</li>
</ul>
</section> </section>
</back> </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> </rfc>
 End of changes. 407 change blocks. 
3890 lines changed or deleted 1815 lines changed or added

This html diff was produced by rfcdiff 1.48.