<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-hardt-gnap-jose-02" category="std" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>JOSE Authentication</title>
    <seriesInfo name="Internet-Draft" value="draft-hardt-gnap-jose-02"/>
    <author initials="D." surname="Hardt" fullname="Dick Hardt" role="editor">
      <organization>SignIn.Org</organization>
      <address>
        <postal>
          <country>United States</country>
        </postal>
        <email>dick.hardt@gmail.com</email>
      </address>
    </author>
    <date year="2020" month="August" day="15"/>
    <area>Security</area>
    <abstract>
      <t>TBD</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>TBD</t>
      <t><strong>Terminology</strong></t>
      <t>This document uses the following terms defined in <xref target="GNAP" format="default"/>:</t>
      <ul spacing="normal">
        <li>Grant Client (GC)</li>
        <li>Client Handle</li>
        <li>Registered Client</li>
        <li>Dynamic Client</li>
        <li>Grant</li>
        <li>Grant Server (GS)</li>
        <li>GS URI</li>
        <li>NumericDate</li>
        <li>Resource Server (RS)</li>
      </ul>
      <t><strong>Notational Conventions</strong></t>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
      <t>Certain security-related terms are to be understood in the sense
defined in <xref target="RFC4949" format="default"/>.  These terms include, but are not limited to,
"attack", "authentication", "authorization", "certificate",
"confidentiality", "credential", "encryption", "identity", "sign",
"signature", "trust", "validate", and "verify".</t>
      <t>Unless otherwise noted, all the protocol parameter names and values
are case sensitive.</t>
    </section>
    <section anchor="JOSEauthN" numbered="true" toc="default">
      <name>JOSE Authentication</name>
      <t>How the GC authenticates to the GS and RS are independent of each other. One mechanism can be used to authenticate to the GS, and a different mechanism to authenticate to the RS.</t>
      <t>Other documents that specify other GC authentication mechanisms will replace this section.</t>
      <t>In the JOSE Authentication Mechanism, the GC authenticates by using its private key to sign a JSON document with JWS per <xref target="RFC7515" format="default"/> which results in a token using JOSE compact serialization.</t>
      <t>[Editor: are there advantages to using JSON serialization in the body?]</t>
      <t>Different instances of a Registered GC MAY have different private keys, but each instance has a certificate to bind its private key to to a public key the GS has for the Client ID. An instance of a GC will use the same private key for all signing operations.</t>
      <t>The GC and the GS MUST both use HTTP/2 (<xref target="RFC7540" format="default"/>) or later, and TLS 1.3 (<xref target="RFC8446" format="default"/>) or later, when communicating with each other.</t>
      <t>[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]</t>
      <t>The token may be included in an HTTP header, or as the HTTP message body.</t>
      <t>The following sections specify how the GC uses JOSE to authenticate to the GS and RS.</t>
      <section anchor="grant-server-access" numbered="true" toc="default">
        <name>Grant Server Access</name>
        <t>The GC authenticates to the GS by passing either a signed header parameter, or a signed message body.
The following table shows the method, uri and token location for each GC request to the GS:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">request</th>
              <th align="left">http method</th>
              <th align="left">uri</th>
              <th align="left">token in</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Create Grant</td>
              <td align="left">POST</td>
              <td align="left">GS URI</td>
              <td align="left">body</td>
            </tr>
            <tr>
              <td align="left">Verify Grant</td>
              <td align="left">PATCH</td>
              <td align="left">Grant URI</td>
              <td align="left">body</td>
            </tr>
            <tr>
              <td align="left">Read Grant</td>
              <td align="left">GET</td>
              <td align="left">Grant URI</td>
              <td align="left">header</td>
            </tr>
            <tr>
              <td align="left">Update Grant</td>
              <td align="left">PUT</td>
              <td align="left">Grant URI</td>
              <td align="left">body</td>
            </tr>
            <tr>
              <td align="left">Delete Grant</td>
              <td align="left">DELETE</td>
              <td align="left">Grant URI</td>
              <td align="left">header</td>
            </tr>
            <tr>
              <td align="left">Read AuthZ</td>
              <td align="left">GET</td>
              <td align="left">AZ URI</td>
              <td align="left">header</td>
            </tr>
            <tr>
              <td align="left">Update AuthZ</td>
              <td align="left">PUT</td>
              <td align="left">AZ URI</td>
              <td align="left">body</td>
            </tr>
            <tr>
              <td align="left">Delete AuthZ</td>
              <td align="left">DELETE</td>
              <td align="left">AZ URI</td>
              <td align="left">header</td>
            </tr>
            <tr>
              <td align="left">GS Options</td>
              <td align="left">OPTIONS</td>
              <td align="left">GS URI</td>
              <td align="left">header</td>
            </tr>
            <tr>
              <td align="left">Grant Options</td>
              <td align="left">OPTIONS</td>
              <td align="left">Grant URI</td>
              <td align="left">header</td>
            </tr>
            <tr>
              <td align="left">AuthZ Options</td>
              <td align="left">OPTIONS</td>
              <td align="left">AZ URI</td>
              <td align="left">header</td>
            </tr>
          </tbody>
        </table>
        <section anchor="authorization-header" numbered="true" toc="default">
          <name>Authorization Header</name>
          <t>For requests with the token in the header, the JWS payload MUST contain the following attributes:</t>
          <t><strong>iat</strong> - the time the token was created as a NumericDate.</t>
          <t><strong>jti</strong> - a unique identifier for the token per <xref target="RFC7519" format="default"/> section 4.1.7.</t>
          <t><strong>uri</strong> - the value of the URI being called (GS URI, Grant URI, or AZ URI).</t>
          <t><strong>method</strong> - the HTTP method being used in the call ("GET", "DELETE", "OPTIONS")</t>
          <t>The HTTP authorization header is set to the "jose" parameter followed by one or more white space characters, followed by the resulting token.</t>
          <t>A non-normative example of a JWS payload and the HTTP request follows:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "iat"       : 15790460234,
    "jti"       : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
    "uri"       : "https://as.example/endpoint/grant/example6",
    "method"    : "GET"
}

GET /endpoint/example.grant HTTP/2
Host: as.example
Authorization: jose eyJhbGciOiJIUzI1NiIsIn ...
]]></artwork>
          <t>[Editor: make a real example token]</t>
          <t><strong>GS Verification</strong></t>
          <t>The GS MUST verify the token by:</t>
          <ul spacing="normal">
            <li>TBD</li>
          </ul>
        </section>
        <section anchor="signed-body" numbered="true" toc="default">
          <name>Signed Body</name>
          <t>For requests with the token in the body, the GC uses the Request JSON as the payload in a JWS. The resulting token is sent with the content-type set to "application/jose".</t>
          <t>A non-normative example (line breaks added to the body for readability):</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
POST /endpoint HTTP/2
Host: as.example
Content-Type: application/jose
Content-Length: 155

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyzdWIiOiIxMjM0NTY3ODkwIiwibmF
tZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMe
Jf36POk6yJV_adQssw5c
]]></artwork>
          <t>[Editor: make a real example token]</t>
          <t><strong>GS Verification</strong></t>
          <t>The GS MUST verify the token by:</t>
          <ul spacing="normal">
            <li>TBD</li>
          </ul>
        </section>
        <section anchor="public-key-resolution" numbered="true" toc="default">
          <name>Public Key Resolution</name>
          <ul spacing="normal">
            <li>
              <strong>Registered Clients</strong> MAY use any of the JWS header values to direct the GS to resolve the public key matching the private key linked to the Client ID. The GS MAY restrict which JWS headers a GC can use.</li>
          </ul>
          <t>[Editor: would examples help here so that implementors understand the full range of options, and how an instance can have its own asymetric key pair]</t>
          <t>A non-normative example of a JOSE header for a Registered Client with a key identifier of "12":</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "alg"   : "ES256",
    "typ"   : "JOSE",
    "kid"   : "12"
}
]]></artwork>
          <ul spacing="normal">
            <li>
              <strong>Dynamic Clients</strong> MUST include their public key in the "jwk" JWS header in a GNAP Create Grant request, unless they have a Client Handle and include it in the GNAP Request JSON "client" object.</li>
          </ul>
          <t>A non-normative example of a JOSE header for a Dynamic Client:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "alg"   : "ES256",
    "typ"   : "JOSE",
    "jwk"   : {
        "kty"   : "EC",
        "crv"   : "P-256",
        "x"     : "Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",
        "y"     : "GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"
    }
}
]]></artwork>
        </section>
      </section>
      <section anchor="resource-server-access" numbered="true" toc="default">
        <name>Resource Server Access</name>
        <t>In the "jose" mechanism <xref target="joseMech" format="default"/>, all GC requests to the RS include a proof-of-possession token in the HTTP authorization header. In the "jose+body" mechanism <xref target="jose_bodyMech" format="default"/>, the GC signs the JSON document in the request if the POST or PUT methods are used, otherwise it is the same as the "jose" mechanism.</t>
        <section anchor="JWSHeader" numbered="true" toc="default">
          <name>JOSE header</name>
          <t>The GS provides the GC one or more JWS header parameters and values for a a certificate, or a reference to a certificate or certificate chain, that the RS can use to resolve the public key matching the private key being used by the GC.</t>
          <t>A non-normative examples JOSE header:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "alg"   : "ES256",
    "typ"   : "JOSE",
    "x5u"   : "https://as.example/cert/example2"
}
]]></artwork>
          <t>[Editor: this enables Dynamic Clients to make proof-of-possession API calls the same as Registered Clients.]</t>
        </section>
        <section anchor="joseMech" numbered="true" toc="default">
          <name>"jose" Mechanism</name>
          <t>The JWS payload MUST contain the following attributes:</t>
          <t><strong>iat</strong> - the time the token was created as a NumericDate.</t>
          <t><strong>jti</strong> - a unique identifier for the token per <xref target="RFC7519" format="default"/> section 4.1.7.</t>
          <t><strong>uri</strong> - the value of the RS URI being called.</t>
          <t><strong>method</strong> - the HTTP method being used in the call</t>
          <t><strong>token</strong> - the access token provided by the GS to the GC</t>
          <t>The HTTP authorization header is set to the "jose" parameter followed by one or more white space characters, followed by the resulting token.</t>
          <t>A non-normative example of a JWS payload and the HTTP request follows:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "iat"       : 15790460234,
    "jti"       : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
    "uri"       : "https://calendar.example/calendar",
    "method"    : "GET",
    "token"     : "eyJJ2D6.example.access.token.mZf9pTSpA"
}

GET /calendar HTTP/2
Host: calendar.example
Authorization: jose eyJhbG.example.jose.token.adks
]]></artwork>
          <t>[Editor: make a real example token]</t>
          <t><strong>RS Verification</strong></t>
          <t>The RS MUST verify the token by:</t>
          <ul spacing="normal">
            <li>verify access token is bound to the public key - include key fingerprint in access token?</li>
            <li>TBD</li>
          </ul>
        </section>
        <section anchor="jose_bodyMech" numbered="true" toc="default">
          <name>"jose+body" Mechanism</name>
          <t>The "jose+body" mechanism can only be used if the content being sent to the RS is a JSON document.</t>
          <t>Any requests not sending a message body will use the "jose" mechanism <xref target="joseMech" format="default"/>.</t>
          <t>Requests sending a message body MUST have the following JWS payload:</t>
          <t><strong>iat</strong> - the time the token was created as a NumericDate.</t>
          <t><strong>jti</strong> - a unique identifier for the token per <xref target="RFC7519" format="default"/> section 4.1.7.</t>
          <t><strong>uri</strong> - the value of the RS URI being called.</t>
          <t><strong>method</strong> - the HTTP method being used in the call</t>
          <t><strong>token</strong> - the access token provided by the GS to the GC</t>
          <t><strong>body</strong> - the message body being sent to the RS</t>
          <t>A non-normative example of a JWS payload and the HTTP request follows:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "iat"   : 15790460234,
    "jti"   : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
    "uri"   : "https://calendar.example/calendar",
    "method": "POST",
    "token" : "eyJJ2D6.example.access.token.mZf9pTSpA",
    "payload" : {
        "event" : {
            "title"             : "meeting with joe",
            "start_date_utc"    : "2020-02-21 11:00:00",
            "end_date_utc"      : "2020-02-21 11:00:00"
        }  
    }
}

POST /calendar HTTP/2
Host: calendar.example
Content-Type: application/jose
Content-Length: 155

eyJhbGciOi.example.jose+body.adasdQssw5c
]]></artwork>
          <t>[Editor: make a real example token]</t>
          <t><strong>RS Verification</strong></t>
          <t>The RS MUST verify the token by:</t>
          <ul spacing="normal">
            <li>TBD</li>
          </ul>
        </section>
        <section anchor="public-key-resolution-1" numbered="true" toc="default">
          <name>Public Key Resolution</name>
          <t>The RS has a public key for the GS that it uses to verify the certificate or certificate chain the GC includes in the JWS header.</t>
        </section>
      </section>
      <section anchor="request-encryption" numbered="true" toc="default">
        <name>Request Encryption</name>
        <t>[Editor: to be fleshed out]</t>
        <t>The GC encrypts a request when ??? using the GS public key returned as the ??? attribute in GS Options.</t>
      </section>
      <section anchor="response-signing" numbered="true" toc="default">
        <name>Response Signing</name>
        <t>[Editor: to be fleshed out]</t>
        <t>The GC verifies a signed response ??? using the GS public key returned as the ??? attribute in GS Options.</t>
      </section>
      <section anchor="response-encryption" numbered="true" toc="default">
        <name>Response Encryption</name>
        <t>[Editor: to be fleshed out]</t>
        <t>The GC decrypts a response when ??? using the private key matching the public key included in the request as the ??? attribute in <xref target="GNAP" format="default"/> Grant Request JSON.</t>
      </section>
    </section>
    <section anchor="acknowledgments" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="BCP" value="14"/>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization/>
          </author>
          <date year="1997" month="March"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4949" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <seriesInfo name="DOI" value="10.17487/RFC4949"/>
          <seriesInfo name="RFC" value="4949"/>
          <seriesInfo name="FYI" value="36"/>
          <author initials="R." surname="Shirey" fullname="R. Shirey">
            <organization/>
          </author>
          <date year="2007" month="August"/>
          <abstract>
            <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
        <front>
          <title>JSON Web Signature (JWS)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
          <seriesInfo name="RFC" value="7515"/>
          <author initials="M." surname="Jones" fullname="M. Jones">
            <organization/>
          </author>
          <author initials="J." surname="Bradley" fullname="J. Bradley">
            <organization/>
          </author>
          <author initials="N." surname="Sakimura" fullname="N. Sakimura">
            <organization/>
          </author>
          <date year="2015" month="May"/>
          <abstract>
            <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
        <front>
          <title>JSON Web Token (JWT)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
          <seriesInfo name="RFC" value="7519"/>
          <author initials="M." surname="Jones" fullname="M. Jones">
            <organization/>
          </author>
          <author initials="J." surname="Bradley" fullname="J. Bradley">
            <organization/>
          </author>
          <author initials="N." surname="Sakimura" fullname="N. Sakimura">
            <organization/>
          </author>
          <date year="2015" month="May"/>
          <abstract>
            <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7540" target="https://www.rfc-editor.org/info/rfc7540" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml">
        <front>
          <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7540"/>
          <seriesInfo name="RFC" value="7540"/>
          <author initials="M." surname="Belshe" fullname="M. Belshe">
            <organization/>
          </author>
          <author initials="R." surname="Peon" fullname="R. Peon">
            <organization/>
          </author>
          <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
            <organization/>
          </author>
          <date year="2015" month="May"/>
          <abstract>
            <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t>
            <t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
          <seriesInfo name="RFC" value="8446"/>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <date year="2018" month="August"/>
          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="GNAP" target="https://tools.ietf.org/html/draft-hardt-xauth-protocol">
        <front>
          <title>The Grant Negotiation and Authorization Protocol</title>
          <author initials="D." surname="Hardt">
            <organization/>
          </author>
          <date year="2020" month="June"/>
        </front>
      </reference>
    </references>
    <section anchor="document-history" numbered="true" toc="default">
      <name>Document History</name>
      <section anchor="draft-hardt-gnap-jose-00" numbered="true" toc="default">
        <name>draft-hardt-gnap-jose-00</name>
        <ul spacing="normal">
          <li>Initial version</li>
        </ul>
      </section>
      <section anchor="draft-hardt-gnap-jose-01" numbered="true" toc="default">
        <name>draft-hardt-gnap-jose-01</name>
        <ul spacing="normal">
          <li>renamed HTTP verb to method</li>
        </ul>
      </section>
      <section anchor="draft-hardt-gnap-jose-02" numbered="true" toc="default">
        <name>draft-hardt-gnap-jose-02</name>
        <ul spacing="normal">
          <li>renamed Client to Grant Client (GC)</li>
        </ul>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIADhjOF8AA+1aX3MaORJ/51Oo8EviGAwYO2teciw4No5tHMDJbu5SKTEj
QGEYzY4GY5L4u193SzOjwTjOpnbv4WpTqfIgqVut/vPrbs1UKpWSr7yQL0SL
+TGfJJUZj/2kMg15VPmstKjUGqVEJgHMn/eHJ6y9TGYiTKTHE6nCks8TmGnU
GrVK7ZdK/bAE42Kq4nWL6cQvyShusSRe6qRRqx0DKx4L3mJD4S1jmaxLngq1
CPVS0ypRKnFgr+JWicE/GcJwt8rOUCIaUfGUh/ILbQ1c5DTshdV+PKXJWKGQ
wpeJimnAnKorvbnDQiy4DOCsMFqlo/5riiNVTy1o3lPLMEHxb0KZCJ8NEziQ
LpVCFS9g31vRKsG6wetOo14/bpnH5nEzfXx5WD/MH/PRZs0+/tJsHgEL+HF6
1b42B7X6Hc0EO415mLArUGEi6ZiMhz4pXcX24Ow6VonyVGBoeTwVSYvNkiTS
rf39RKlAV6VIJlXQ1v4sWQT7rmHvUMOVyGVhbHi+DAU72iNb0rBrCsYq9u+m
WUoynDiqKVUqFcbHOom5l7BSafRr14wtpO8HYOAd1gP9Kn/pkf+YBaXd3ZGI
FzJUgZqud3dheCY1A89cLsDZ2FILzcDv2EQFgVrJcMoSWA8rxESGYCUZsq9f
UaH39yDEC6vGTiCR+tlp5zmM2V9noFAQ5AUbiKnUwAbIzRSMddfgNNLLB4hR
xnAo4lsRA8MhMjwdsptBDx6uQMpYel3QI/HVahl7Ils9gNVwwiuVkP14wDoq
vMUgAu83hxVsLtZspWJfs/LlzXBU3jN/2VWfngcnb296g5MuPg/P2hcX2YNZ
UYIf/ZsLO49POWWnf3l5ctU1xJft3+EPOlW5fz3q9a/aF2VUXwIKL+lIeHJi
Y5tBrLJEsbGAedBTFAsMCI5a114sx6nebTDc31dLpY6IEw6j2kZ4JRYBRzJj
r5zlMvRFrMFbfbO7YAgEolSwqI0t4MwwOrSwbGToBUtf7LHxMiGeoUpYIBcU
sYkCbfAk4d4cD8wLgJWOZNGEAx4IbY4tUJMAShPpIw0P4Ai0ArzEDOAvEXrx
OkqpzVKzTgMkIQv8y5NlLHCQ8A8fboGfT5sYA4B3yMm6DGq7CQOhNVMgaryS
mg4kfFgWBKSbNF5ZxGNANdACoZsmPsB2CRCFevC4NoqUGI9VCEAIuC24zb7u
4Chq4uq+VDpTK9rmtMMcdWHMKTM+pI0GQ1K2BNNFIsRjMzVhgnszI3mV9QFD
FsKbAUrrBUgTkqk1WaXAOudsdMEBkScTCEbgmTN4hGgwBJX1cccMIhAeeMKM
A6+NOBvHwWNnrDVbSdBtLKKAQ6ii96PP4iLg3TMeuU1xlymHve0aG6/hvAhQ
EmSKYnmLcmNwg+zoFXDS82H/Kse2lUxm7Pz9kEUgMbk85pD7e7aaSVBsLPQy
SNDlgTJRcxFa/iQcZK0IgVaDJ4FzGZdGs//n3yeUCFsm5EAbgnH/FkCMT41d
LReUpUCdhuNY+etXH0ulbmYXAP6Ehx6Qg9W5i5+gBcAVNuO3wrGjc3ptQpVc
JWUDy8F/mRN8BA3gXdt0h67AouU4AHSmIeOWyAPyD/20AN+D3NQO821IWJCQ
DL7UwoANRE9hC2SC0YY2QsUoMAfpQ6M6R9bUIJvdmMB5DH5GLM9Go+v9Bntm
7des3d8/h2qFIfbFxsNHF0NWrx7YNVgGFNeswInQnotlSL4GMpBrOOHlmhWQ
k/HpFNxDQ6SjehawC57GyuLsiWbEExj3WfC1wXTCUEJaiFOkYjPBfZQFdWES
Lg0D0GhwG3KJqmGVJ2IbNTqLvVkOJpS3yVEfDX8LLMB2Z6eYZdseuJrOVP8I
LkG8RVyTLwtJUc/JhnAwc5ocMs250tnioYpnSvg4AB+BkxgtAPlMARxDSjM+
QIoMlMUE9B0yE8gZiz8AjJNcQqhHvmWjzr9vVLJZ1vALeTuTZguwDf4rfWth
DbXx71thbGOJ+Qlbd6DiTtLCMuV+3QfvzX6ZQib7iRoBwneUnTYJ26POWU5I
c5bWEOKWA1B8gY7WnozcX0VKayqgvYn8LeLefIfWitsVgXhA2D25OBmdPLkp
CYxA/+FRgdsfCjp6ILBLvSnwBm2qJitxkbIo8aO7gsn6kYm7fB9T0A23W9Wh
JTUUyB/QPqYpI+x3abfLTKUIhHixlTmjyVLpNUSQjRFtYC/J8MrmoxSbKDFj
uuTrQIHZCIihZKOys9gjQBEIZeoSAKOFBTg0VLu7rGJYy4Vw9lgB3HkUKFTg
crekryLt50QSLYfCVYKczFR9EwlHS/OPYeWmcahcU3xkzWq9+pJ4QaRnclDt
hikKf6DaxgIl9yAVgSjPjA33cnsQhhkNPydmBj8yfhavCVMMK6q+rGqQLXtW
Bs/GctS4Gj5ZA5afG3AnJoUqObUiVUkZuJXxgqDs1KRG9bAfoLKCUhBkXSio
PKCUAUfXEZZaUD5hbwjF/15hPTI0xQ4hMOoSM28bSuGwknXfTNzxRRTYrO76
QZqbSfgUb80Gmnp2xr5mPWwZfKFsn1usfvjyuNY8qjUOmnv5EjB5vqQ8OfJf
NhqHzUpz0jioNOsvJ5Xx4aGo1JvcP2gcjOu+Vy871GBkhzrtzrmu2gPsQwEd
KWis9qdo2307fOTyMHYsWx5oNZq7N6dBfMq5WPoqcbM1AC07UzqBKjDbmAYL
UdhiaEcm1uez8akn+/K8d/OlV7+SPQ2FcLVaqDsWfA6VJCgY2tjUFmSsj+iN
4K+UNmy1nDa3ab1kGh4nWMZratfpEgDRYWhy868I6T8CCgile4Vqg/oDa30q
bm0hk7oJ1dHgN1W6btlwOOPfaVFOEQPAAgOVZB2J1PXLPIoCe8J9CoHq4376
LIB2lo1BX3PAFd83rVAqO2EHzPl8LLHXfG49lfJzZtwnzdmxUo5ASpjcEK+w
5EKE02SGPn9ottpu9sGh1+kd9ebRb+8658dVsf7iv+/Bmt7d5efL2tXo94N+
d77qyZUcL16bi6gPQyK45afN6eD0OMBJ/v51rfdZ3V2NThpAeHjZ7a0nb6vD
SfDmbjU4H16KN29eN96OmpNVdGkEPZ8cHF3350fr83efuP9W69Wh979zwGvT
YbyBjgDvcYKluaV6wXZ3H9wXaUBdbHuwAeDhOkVxBCULl6YzR4P7MoY8kBat
MBAj91uTg5y2BrzHm5E/zor9CbjRPPcdp9VJjweCAE9IeLCNaR1zQbTpgLAf
B2GL/eFKLQM/1aQGgiBi1C5qZXpqiRPYqirgY69tUrCdLLGJ5uGUAFmZssD0
O9gGcKcNw82pQcTmTq0gDPUaAC62B4+4jD8+BffYSVjVUr/28A7PRC4nlk6K
BvJyvVF+mAd4MC0beD0ZNg4L6Ashb6dwX3dmLn07AzxTSEYXKV4fkn+g19lW
CzUmY9faFsXKn1fzsus3BFJ4nVms3i0YQh9irouAdm10you3m2SAdFeZpPsQ
xwI4lj0iKzM1/gz++R0ce8QAxRP/RfoldeBMzsjoPVmnzDrOeprz4ls7d10p
bkTTd+U0Fb+ZBofd8+H0Yv2ucnrQUHpxMXv95u78+OVrdfm+5n94d/JH97TS
WanmJpN1xuRUXzQX/cvmXUMcyf7VL7+e3Q66b4/a09/a1+GqtqgNJ34wOHn3
UjbLGY/71FUAZzYviW2zm9482coqvwn7+hVH8PLp/t5cC+a9ps7vxTKjc7wy
VJMK/I+U1nhLAFVcIXc+WuVVmSvFC8xTD0X5hMOpPDYBY2dtsm3xistumBZl
0uAk5ThwIuyVTKVj7oexYN1zrkLRf3V+aWPz+aaGENQQwF0X/boDMWVajPss
D4BebgEZdCq0W6c6IZgVte4dq3X6wqWVvVWIBd16ecLcVLm3WjDv/gSBZbhn
sNVazQLzz+QFp8i3RfRp5/Ew1q5+/qJovTtc2pktVS4ePK1Nc6x077Hw5lWE
eOGiN9BEm1utudjqy+3rHvUzRdd4mKSrH41jWIe5zP14Jwsp4xz/p13lYPig
sfy5zhGJSJqMhhNqpSKawMr9cJhdgnX+6Sv/3r4SzAPNAo/zuLMD328n3fhG
xWT5DZqC80b3KGVXNYauGu0tPkyOo9Ewaj9sR9NtH3YsmxI+0YZmO+OY3Zf7
c/3jncBgeycweKITsOMFzwbvHKtlmFXfDi5XKlnKpbcI4GP4plSarOdyeeW2
GW5m3USkPLMaibdnYUwZKgzW2Qs2m1Vtw2pDmJpZpzrQm6+fKBSgd8lKCXyT
ClQ+IV3hkrz4AuW7FQpyHaQcH+FGVqDitQivTuz9g68/jq+7u6jVjLKg6m2+
8Hcj4BPo9/PI95Ooh41Bf7gN8n4c7hxaq5vywyZF3FJDtTludsQPfcqFsRZK
KPLXfZ+V2Gg7iBKa6Dj5hG8aPi0TL8Vw891Vo9Kos3q9VavB/23EoJMi6aPE
Bdp7xh72LvjH3E79Saz/a+6oCnmBQBHSAtd/+p7oJ7PDU/dElod5s+2kiRRs
MGbpTiX9pkm5Wz3VNKQti804OgWPvG0xX3zsZE3+SfalSvHdMWaNCVTcM4AT
tUw+Zm+47actmjRneNCL6VevXtkvBuwxnMPFIlnGocFgnMW1WZGMMuYvq6pp
8xvhh3903Ys8f1A4UpXEr17Sl7hxyunvke9Pq88Xjvosky36cxu4Ymfn3g3l
7+fd7vmxQ6Tfv9m7Iveap0qfAbW9eahWkJ2m9MGM/fRuh/XaV20MPQ3JxX7y
kM2lH2pun8c3zGPuzXFlN232z6D/UvGaFPnIF6W1UoX1QomfU6FNNen38eV1
WA6tNfQCvslBQDOm3pCg/XukDYfU3pAB3cOvA/8L1X8bTggrAAA=

-->

</rfc>
