<?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.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-stir-rph-emergency-services-02" category="std">

  <front>
    <title abbrev="RPH Values for Emergency Services">Assertion Values for a Resource Priority Header Claim and a SIP Priority Header Claim in Support of Emergency Services Networks</title>

    <author initials="M." surname="Dolly" fullname="Martin Dolly">
      <organization>AT&amp;T</organization>
      <address>
        <email>md3135@att.com</email>
      </address>
    </author>
    <author initials="C." surname="Wendt" fullname="Chris Wendt">
      <organization>Comcast</organization>
      <address>
        <postal>
          <street>Comcast Technology Center</street>
          <city>Philadelphia, PA  19103</city>
          <country>USA</country>
        </postal>
        <email>chris-ietf@chriswendt.net</email>
      </address>
    </author>

    <date year="2020" month="July" day="13"/>

    <area>ART</area>
    <workgroup>STIR</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document adds new assertion values for a Resource Priority Header (“rph”) claim and a new SIP Priority Header claim (“sph”) for protection of the “psap-callback” value as part of the “rph” PASSporT extension, in support of the security of Emergency Services Networks for emergency call origination and callback.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization <xref target="RFC8443"/> extended the Personal Assertion Token (PASSporT) specification defined in <xref target="RFC8225"/> to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) “Resource-Priority” header field <xref target="RFC4412"/>, which is used for communications resource prioritization and the SIP “Priority” header field, used for categorizing the priority use of the call.</t>

<t>Compromise of the SIP “Resource-Priority” header field could lead to misuse of network resources (i.e., during congestion scenarios), impacting the application services supported using the SIP “Resource-Priority” header field.</t>

<t><xref target="RFC8225"/> allows extensions by which an authority on the originating side verifying the authorization of a particular communication for the SIP “Resource-Priority” header field or the SIP “Priority” header field can use PASSPorT claims to cryptographically sign the information associated with either the SIP “Resource-Priority” or “Priority” header fields and convey assertion of those values by the signing party authorization.  A signed SIP “Resource-Priority” or “Priority” header fields will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions to act on the information with confidence that the information has not been spoofed or compromised.</t>

<t>This document adds new assertion values for a Resource Priority Header (“rph”) claim defined in <xref target="RFC8443"/>, in support of Emergency Services Networks for emergency call origination and callback. This document also defines a new claim, “sph”, including protection of the SIP Priority header for the indication of an emergency service call-back assigned the value “psap-callback” as defined in <xref target="RFC7090"/>.
The use of these new assertion values for real-time communications supported using the SIP ‘Resource-Priority’ and ‘Priority’ header fields for emergency services is introduced in <xref target="I-D.rosen-stir-emergency-calls"/> but otherwise out-of-scope of this document.  In addition, the PASSPorT claims and values defined in this document are intended for use in environments where there are means to verify that the signer of the SIP ‘Resource-Priority’ and ‘Priority’ header fields is authoritative.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

</section>
<section anchor="new-assertion-values-for-rph-claim" title="New Assertion Values for “rph” claim">

<t>This specification defines new assertions values for:</t>

<figure><artwork><![CDATA[
*  “ESorig”: Emergency Services call origination
*  “EScallback”: Emergency Services callback.
]]></artwork></figure>

<section anchor="esorig" title="ESorig">

<t>When using “ESorig” as the “rph” assertion value, the “orig” claim of the PASSporT MUST represent the calling party number that initiates the call to emergency services.  The “dest” claim MUST either be a country or region specific dial string (e.g., “911” for North America or “112” GSM defined string used in Europe and other countries) or “urn:service:sos” as defined in TBD, representing the emergency services destination of the call.</t>

<t>The following is an example of an “rph” claim for SIP ‘Resource-Priority’ header field with a “ESorig” assertion:</t>

<figure><artwork><![CDATA[
  {
    "orig":{"tn":“12155551212"},
    "dest":{["uri":“urn:service:sos"]},
    "iat":1443208345,
    "rph":{“ESorig":[“esnet,x"]}
  }
]]></artwork></figure>

</section>
<section anchor="escallback" title="EScallback">

<t>When using “EScallback” as the “rph” assertion value, the “orig” claim of the PASSporT MUST represent the emergency network telephone number. The “dest” claim MUST be the telephone number representing the original calling party of the emergency service call that is being called back.</t>

<t>The following is an example of an “rph” claim for SIP ‘Resource-Priority’ header field with a “EScallback” assertion:</t>

<figure><artwork><![CDATA[
  {
    "orig":{"tn":“12155551213"},
    "dest":{["tn":“12155551212"]},
    "iat":1443208345,
    "rph":{“EScallback":[“esnet,x"]}
  }
]]></artwork></figure>

<t>After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in <xref target="RFC8225"/> using the full form of PASSPorT.  The credentials (i.e., Certificate) used to create the signature must have authority over the namespace of the “rph” claim, and there is only one authority per claim.  The authority MUST use its credentials associated with the specific service supported by the resource priority namespace in the claim. If r-values are added or dropped by the intermediaries along the path, the intermediaries must generate a new “rph” header and sign the claim with their own authority.</t>

</section>
</section>
<section anchor="the-sip-priority-header-sph-claim" title="The SIP Priority header “sph” claim">

<t>As discussed in <xref target="I-D.rosen-stir-emergency-calls"/>, and as defined in <xref target="RFC7090"/> the SIP Priority header may be set to the value “psap-callback” for emergency services callback calls.  Because some SIP networks may act on this value and provide priority or other special routing based on this value, it is important to protect and validate the authoritative use associated with it.</t>

<t>Therefore, we define a new claim key as part of the “rph” PASSporT, “sph”, which MUST be used only for authorized emergency callbacks and correspond to a SIP Priority header with the value “psap-callback”.</t>

<t>The value of the “sph” claim key should only be “psap-callback” to match the SIP Priority header field value for authorized emergency services callbacks.</t>

<t>The following is an example of an “sph” claim for SIP ‘Priority’ header field with the value “psap-callback”:</t>

<figure><artwork><![CDATA[
  {
    "orig":{"tn":“12155551213"},
    "dest":{["tn":“12155551212"]},
    "iat":1443208345,
    "rph":{“EScallback":[“esnet,x"]},
    "sph":"psap-callback"
  }
]]></artwork></figure>

</section>
<section anchor="order-of-claim-keys" title="Order of Claim Keys">

<t>The order of the claim keys MUST follow the rules of <xref target="RFC8225"/> Section 9; the claim keys MUST appear in lexicographic order. Therefore, the claim keys discussed in this document appear in the PASSporT Payload in the following order,</t>

<t><list style="symbols">
  <t>dest</t>
  <t>iat</t>
  <t>orig</t>
  <t>rph</t>
  <t>sph</t>
</list></t>

</section>
<section anchor="compact-form-of-passport" title="Compact Form of PASSporT">

<t>The use of the compact form of PASSporT is not specified in this document or recommended for ‘rph’ PASSporTs.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="passport-resource-priority-header-rph-types" title="PASSporT Resource Priority Header (rph) Types">

<t>This specification requests that the IANA add two new assertion values to the “PASSporT Resource Priority Header (rph) Types” Registry as defined in <xref target="RFC8443"/>.</t>

<t>The following assertion values will be added to the registry:</t>

<figure><artwork><![CDATA[
* “ESorig”: Emergency Services call origination
* “EScallback”: Emergency Services callback
]]></artwork></figure>

<figure><artwork><![CDATA[
    +--------------+------------+
    | rph Type     | Reference  |
    +--------------+------------+
    | ESorig       | [this RFC] |
    +--------------+------------+
    | EScallback   | [this RFC] |
    +--------------+------------+
]]></artwork></figure>

</section>
<section anchor="json-web-token-claims" title="JSON Web Token claims">

<t>This specification requests that the IANA add two new claims to the JSON Web Token Claims registry as defined in <xref target="RFC7519"/>.</t>

<t>Claim Name: “sph”</t>

<t>Claim Description: SIP Priority header field</t>

<t>Change Controller: IESG</t>

<t>Specification Document(s): [RFCThis]</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The security considerations discussed in <xref target="RFC8224"/>, Section 12, are applicable here.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor="I-D.rosen-stir-emergency-calls">
<front>
<title>Non-Interactive Emergency Calls</title>

<author initials='B' surname='Rosen' fullname='Brian Rosen'>
    <organization />
</author>

<date month='March' day='9' year='2020' />

<abstract><t>Emergency calls from citizens to authorities, and call back of such emergency calls by authorities to citizens need assurances that headers intended to get appropriate priority from the networks they traverse, and in some cases, appropriate routing.  Protection of the SIP Resource Priority Header and the SIP Priority header is needed for such calls.  This document describes the environment for placing emergency calls and call backs which motivate the need and use of the mechanisms described in other documents</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-rosen-stir-emergency-calls-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-rosen-stir-emergency-calls-00.txt' />
</reference>



<reference  anchor="RFC3261" target='https://www.rfc-editor.org/info/rfc3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'><organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'><organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'><organization /></author>
<date year='2002' month='June' />
<abstract><t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3261'/>
<seriesInfo name='DOI' value='10.17487/RFC3261'/>
</reference>



<reference  anchor="RFC4412" target='https://www.rfc-editor.org/info/rfc4412'>
<front>
<title>Communications Resource Priority for the Session Initiation Protocol (SIP)</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='J.' surname='Polk' fullname='J. Polk'><organization /></author>
<date year='2006' month='February' />
<abstract><t>This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, &quot;Resource-Priority&quot; and &quot;Accept-Resource-Priority&quot;.  The &quot;Resource-Priority&quot; header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies.  It does not directly influence the forwarding behavior of IP routers.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4412'/>
<seriesInfo name='DOI' value='10.17487/RFC4412'/>
</reference>



<reference  anchor="RFC7090" target='https://www.rfc-editor.org/info/rfc7090'>
<front>
<title>Public Safety Answering Point (PSAP) Callback</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='C.' surname='Holmberg' fullname='C. Holmberg'><organization /></author>
<author initials='M.' surname='Patel' fullname='M. Patel'><organization /></author>
<date year='2014' month='April' />
<abstract><t>After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication.  For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call.  This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.</t><t>The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays.  Unfortunately, the specified mechanism only supports limited scenarios.  This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable.  We describe a solution based on a new header field value for the SIP Priority header field, called &quot;psap-callback&quot;, to mark PSAP callbacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7090'/>
<seriesInfo name='DOI' value='10.17487/RFC7090'/>
</reference>



<reference  anchor="RFC8224" target='https://www.rfc-editor.org/info/rfc8224'>
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></author>
<date year='2018' month='February' />
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name='RFC' value='8224'/>
<seriesInfo name='DOI' value='10.17487/RFC8224'/>
</reference>



<reference  anchor="RFC8225" target='https://www.rfc-editor.org/info/rfc8225'>
<front>
<title>PASSporT: Personal Assertion Token</title>
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<date year='2018' month='February' />
<abstract><t>This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications.  The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination.  The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel.  PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.</t></abstract>
</front>
<seriesInfo name='RFC' value='8225'/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/>
</reference>



<reference  anchor="RFC8226" target='https://www.rfc-editor.org/info/rfc8226'>
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></author>
<date year='2018' month='February' />
<abstract><t>In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers.  This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.</t></abstract>
</front>
<seriesInfo name='RFC' value='8226'/>
<seriesInfo name='DOI' value='10.17487/RFC8226'/>
</reference>



<reference  anchor="RFC7519" target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<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>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>



<reference  anchor="RFC8443" target='https://www.rfc-editor.org/info/rfc8443'>
<front>
<title>Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization</title>
<author initials='R.' surname='Singh' fullname='R. Singh'><organization /></author>
<author initials='M.' surname='Dolly' fullname='M. Dolly'><organization /></author>
<author initials='S.' surname='Das' fullname='S. Das'><organization /></author>
<author initials='A.' surname='Nguyen' fullname='A. Nguyen'><organization /></author>
<date year='2018' month='August' />
<abstract><t>This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.</t></abstract>
</front>
<seriesInfo name='RFC' value='8443'/>
<seriesInfo name='DOI' value='10.17487/RFC8443'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<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>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC7340" target='https://www.rfc-editor.org/info/rfc7340'>
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='September' />
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</t></abstract>
</front>
<seriesInfo name='RFC' value='7340'/>
<seriesInfo name='DOI' value='10.17487/RFC7340'/>
</reference>



<reference  anchor="RFC7375" target='https://www.rfc-editor.org/info/rfc7375'>
<front>
<title>Secure Telephone Identity Threat Model</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<date year='2014' month='October' />
<abstract><t>As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.</t></abstract>
</front>
<seriesInfo name='RFC' value='7375'/>
<seriesInfo name='DOI' value='10.17487/RFC7375'/>
</reference>



<reference  anchor="RFC8126" target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations 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 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIANoJCl8AA81ZbXPbuBH+zl+BUWYaOyepluxcEvbL6WzfxW38UktpppPJ
dCASktBQBAuAdnQ5d/Iz2pn2z+WXdHcBkBQluU567VQfJIrEy2L32Wdf2Ov1
IittJmI2MkZoK1XO/sCzUhg2U5pxdi2MKnUi2JWWSku7Yi8FT4VmxxmXS8bz
FAaNz652PJc5G5dFobRlasZOl0LPRZ6s2FjoG5nALhfC3ir93kR8OtXiJmbX
Vy+bEmxOiVKV5HwJIqeaz2xPCjvrGSt1TxeLngjje8aP7x0Mo5RbGD88GB70
Dp71BodRAjfmSq9iZmwaRZEsdMysLo0dHhy8gBlcCw5KuZ5EKN5cq7KI2Xhy
dh29Fyu4lcbsLLdC58L2TlCOKDIWtPEnnqkc9lqBoIWM2Vurki4zoAAtZgau
Vku8eBdFvLQLpeOoFzFQk4nZeZ+dqCxbwX93vnMOBsmrm0rPQaLJryZwLZZc
ZjFbpoeDw6ffcWv7iVrWSx332RuRp7Za6nihpanu0UrHaplwY+vFEhxD6vyO
Lm9xdB8OCEMMiC9sNYlNRLLIVabmK3YsUA8wJgHrx+xqITMAQFYsJO+yqxFj
gxeDg0N8rsrcospfj0dRlCu95FbeiBgenfVO+loZkTtD1kZMeJYZHHH9w/Hh
8NuBvzw6Ggz95TMwl798Phwe1ZdP68tvw9ingxfh7tHRYRzJfNYUA+4PB9WQ
Z4dHB9Xls2q5QbXc88Ez2C/q9XqMT0FDPAEUTBagaIBouQS9MJ6mhuXilvHK
vW4e5F57nz/9A/D8+dM/91nScDVca5u7uTF7HVMsOvu0eKGVFQltCa5nF4J1
CsMLUumUJ+87ThKQjBXc+ScNgl07YLfxGLx2wsQHK3IDi3TRl03tyzjWiKQk
Ie73bRKnsilDAQCCci5zTuLhyYJUfafPpUzTTETRI/QyrdKSDhJFV0IblfOs
QVcT9V7kbC9IvM9Og8i076aGR+R48ie3+cePHg13d+6wqUjpcA/ZyhQikTOZ
uKVSMZM5zJZhVQAhrGoVg8OpW1pV5klWGm+URK8Kq+aag7OgAlbMyDmuUKHF
4DC+JjAeClfyOCpUUWbAZrQt3h8LQ+uf5dJKN+UKoKASlbE9gM4+6wSd9IJO
OmzhYDSTIkud9Ohjd3dddguyLRiAujSwCe4OVLMsc39qw3TQcOFWC4KiWUkg
gGtn+07dxqKOkeVPMp/TtCLYC4YEwKGSACHAQoDupawf0B7/7lhAQPCdwS20
CUz3K+cOp9VBDNuTfdHvshTQDdIkKp8LQ2cyicg5rG72wR+WBXh8EJcXRRaA
EEJP8Bc4ItjcD3yIqHDGJoIIPqb2RcOmK28Xngd4oBs6BFS+BTsamQJUhJaz
VSXpGpwQX0QAMgEctYxbge1B+m2O3WUCkBe1ji50hfxCvGXQHtudwTuNp2lE
lTEqkQT4W2kXTMCXuF9IkGuHPMZxj8pvxKpB0QQqCEfBx0DbRHcgDyoRtbVa
V2OfsVFw3q8R41YCJzqW4IDDRMgb3AlCCNp1j1gjre5IkClTSfD6VM5mQmO4
CUhOFYT03Px6CiE3BbwKs48qdjgI7CFTT90NtkGuSmwAUlPvpGzQ1AwAlYOz
2wW3G4MWEExyZdlUAE+aQqmZIFgklcMitP9rIXKDgInW25Hrl4pUrHWOzCgv
gfGBmqTqMgrKXVYbcTM0r4X0AA3vTzJPgzuisfKGgJ5oSKYeCoVKdCisQsRG
2AcbtRWFSdTdXR8sIxp0Cxc77QLpcdazcina0WAX5T3e8IjHpM7H9d91l1g3
RUWpoHLpU4JwgPuzR+DPaQmGR5q4pZBR2p6CkiFRhT9pw4zgyGc5YlJaSnoo
E2iRFYrtVdFQpF1Hg0bD+XQCj4JqhVEiv5Fa5TgGvB5EQk/Cb5ywFNz5YOWo
3sfIproJli9WJwgXAgXlu+CHkF1NhF5Kl8hHZH2obhiWN4Z1zl+PJwBb+mUX
l3R9ffr712fXpyd4PX45evWquggjxi8vX786qa/qmceX5+enFyduMtxlrVvn
oz/CDx6ic3k1Obu8GL3qbFcsaGjq1KsLLSwlTGAKk2g5dcb4/viKDY4cuDGl
BxA4RoCUHa5B8bnbSuXZyv8F1a4wjAuIgrAE+n7CC1BXBnUbbGAW6hYoDozV
R9VdgGtsLZpdBk1Y8Vy3LU1scZ5pOBfUFAw+TxgDhjsdIwEBycXbiKvNUGsT
g8vfN9nn3I8eMbdRFL0BZXjf7bh7RBl1bdDiA+cjHTfQ8bDHaVVEEIK0AFsZ
NGHI5OpYmpfLKQVxwLt0easw1Ti09yYTgKciYDtgdxs2po18RgAI4aHmZMRY
c8rNvC0gakJuD1UbSrEn+nPI9zovBoMO2fACKGzBRrApWI0i92Aw7LAfx+eV
y/uplMACXE5LjXxCmKL93dYUenF+qfPYix4bZdo0PPn+pFurKBDnFv7D44Zw
tJ4VozZmCnMInI7+DnTzgS+LTPjAUQVMry48KZLJ509/26CTz5/+vp66UQLA
1yBZQwEg+9fmB3D4kbDocBF/7Ni8E8PcwXDwFD7wM+zcdd0QsmD88S3oSNKg
tq7ehZGAi048gKg+PHh+ePTU30VUxh8rwTrxW7gWBpKh7geYC4PuWtI5vAf8
tzG/Fip/YdzXFg25mhWZKBYqF94L+jtgPaVIsTF8EzSeDrKWj3nhticP3vUg
1RVU8cAtwKUnh/8hsBqU9R+B63ATXFsA+HBcVZB4ALZGM+sLEn9Myhpd6lBB
Q03/DBmggYz5Rrh0GXJroJQygXBG0JKawj63JaYShoHRhKaUn1pnWCAVfp95
KVOOSXmr81BnYLMSbIx5Ohos5DOeQRMtUoQPxLlQ+B6j4ilgiX3HcFSgCfhf
5SNOsGVprDtEowy98XJh79FAkSzWm0s+Lfb9AXc6isOI6nqZIrS1vJz1E/IH
SqhAg03x28UhyRoIP+C9zlB9XdduYKwagvumipfjbMZ0zwdqTEQgT3QFTgrk
X9QrUmqyFBBiMAAw7An7pga3i+62IaTHYGJfPjhtNUBUFcTOy8IRASmYmVT6
ofRksqOqoGIkZCcjiCfSJKUxD82lndl2lhA7i5klXyGDGWERSruLkx1ZfxhA
Fxj6vxcJRwQYtXQb5qGEw52qGlaa0OUEqaHsusF2SGVm2MvFasIIMKaG2gBd
ZspRIWsrQP1GBCmXCB6e0zl8IRcqApkGB1lLtQmqbWhK65hVCzgyrH4rvEqb
tSOl4/c2aKvq0rWDQqQonfzgU1RE+1YF3FsvblGloQeiwQ0KlZOr8602rFxq
q+l8oHDPgqw12OgokEJjC44Em24aH7ty3CaL3SUxBQy3xc6DbYDGPDSGmR0x
7P7QVWsEllg7ESbe/7+xy49EE8UtS2xNmdilTl0R6t7t/U6sjFOsCg9qbgJr
G4dGp3VHtGUmqKPdDFJj3wl58Zut0+uCLBMfZBIahG5PypWCB7VmrxFbq4as
1lxL1674KlO8aqTXcKG9ulH0hLJv+AGdwzfVS08YqBq+QY2oI2xNI/v80Ii1
uHjU6q1QSwwHzloDEZvYQvNha5v4VMxg26XuLjwGIR5XaxiKAGejixHIk2ML
WLvuDCW+1U67O2uw2j6brAphtlawWvwFIqA1dYOC9oJoyICEtzeNPOsDAr9o
f/THa6jcDFZxW8KOa/FtOPjG9tRgnYaI7YXRfuGq4P7aevuLyu2KEWjyN721
z9rfb2jEz4gw0gZzf68FtXtBceznB6/hzsWYX+MtQQoU+O6L1qji8Fes0Sy+
fju+vGBvxNS/UnPZ8ddirX6HgI9bSx+7h/oeDOFrYcKQ47ULemNOvBhunVBv
qaBiZHdggtELns8FOp3VgEWhY3Z2Ov4xisZrZzrxnrxn9mP2FiTAc79Dnx2H
N6ptv500X7cmaw/bKZx/E465WuDWwbDr8lX3kmqaidDHwpetBMp/Aeg7Ey4L
IgAA

-->

</rfc>

