<?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-01" category="std">

  <front>
    <title abbrev="RPH Values for Emergency Services">Assertion Values for a Resource 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="March" day="09"/>

    <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 defined in RFC 8443, in support 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, which is used for communications resource prioritization.</t>

<t>Compromise of the SIP ‘Resource-Priority’ header field <xref target="RFC4412"/> 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 can use a PASSPorT claim to cryptographically sign the SIP ‘Resource-Priority’ header field and convey assertion of the authorization for the SIP ‘Resource-Priority’ header field.  A signed SIP ‘Resource-Priority’ header field will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing the SIP ‘Resource-Priority’ header field and 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.
How these new assertion values for real-time communications supported using the SIP ‘Resource-Priority’ header field is outside the scope of this document.  In addition, the PASSPorT extension defined in this document is intended for use in environments where there are means to verify that the signer of the SIP ‘Resource-Priority’ header field 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" title="New Assertion Values">

<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":{["tn":“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>

<t>The use of the compact form of PASSporT is not specified in this document.</t>

</section>
</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>
<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="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="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:
H4sIAAivZl4AA71Y7XLbuBX9z6fAKDNduyupkmxvYv5are2tPRPbqqV0p5PJ
dCASktCQBAuAdlRvOnmMdqZ9uTxJzwVAipadVk5nVz9skALux7nnfkC9Xi+y
0mYiZmNjhLZSFeyPPKuEYQulGWc3wqhKJ4JNtFRa2jU7FzwVmp1kXOZMFmxa
laXSlqkFO8uFXooiWbOp0LcygZQrYe+Ufm8iPp9rcRuzm8l5W8PjI1GqkoLn
MCnVfGF7UthFz1ipe7pc9US9v2fC/t5gGKXcYv9oMBr0Bge9wXGU4MVS6XXM
jE2jKJKljpnVlbGjweB4MIq4FhxO38wiMm+pVVXGbDq7uIneizVepTG7KKzQ
hbC9U7IjiozlRfpnnqkCutYwtJQxe2tV0mUGAGixMFitc1q8iyJe2ZXScdSL
GGAyMbvss1OVZWs8e/8uOQAvmpdKL2HR7DczrEXOZRazPD0YHhx9z63tJyrf
iDrps59EkdpG1MlKS9O8c5JOVJ5wYzfCEtrj4PzeLe9odx8OYouB+cI2h9hM
JKtCZWq5ZieCcMCeBNGP2WQlMxAgK1eSd9lkzNjweDg4oO9VVViC/M10HEWF
0jm38lbE+Ormx5OD0XfDsDw8HI7C8tVodLhZHm2W34Xly6Phcf328PAgjmSx
2JI8GjZbXh4cDprly0bcsBH3avgS+qJer8f4HE7zBIGdrYAdWFflcJXxNDWs
EHeMNxlxu1NG7H3+9C9Q9POnf++zxGVHKhayECllCXQzcqBLD2anlHH6Gr6z
hGcZIiuXsuDOKrDRvZzz5H3f+5TLNM1EFL0g8mqVVgntjKKJ0EYVPGtl+Uy9
FwXbm4ynU9gy22dnH6woDH1Feh97OXZ8ln/zyu/vQ0Q+fmSCTqbw066wfwdV
phSJXMjEi2qh5KWCCJBqFYNz6s5JlUWSVc44YJbodWnVUnNwkABYMyOXJKGJ
mKFt/IHB5BRJCrEsVVllKBJOLb2fCuPkXxTSSn9kohWyW2Vsb3ox2Wff1Jj0
aky+YSsf+oUUWdpld7BnxUCmykAwaUTW5lURPDVM16iWXkIwDtFD4pVa5dII
Mt0ZdDH5nyo9YJRPAAz5hzcZvibsIKrywgrPp0a5YXuyL/pdllZaFkucK5bC
OI9NIgoOTWYfPM1LZAdtIGt4WWZ1wOrKW/MYviI2YeMuZsPfdqRdmI2nkXE4
zdcBS17UYQQDlY9UkwPQaGSKkAotF+vG0gdhJx6wkgptgnhvBaQhxU5YJzCG
IOWMmDwBk0OaA+2nKbm7bJfLqrgV61bZCUR4msc74czYuM6Nncy4k6gxPus4
+JIIeUuwoiwS/nsuC9PmjQQFMpXUWZTKxUJoKqE141KFzlOY383RGVLwSph9
AsvHq85GmbrYLtrZW7v8HFI5DKloJLZmStMr8Hwn7YogXoAxBTLQrrh9tGnF
UfqVZXOBgmVKpRZwzadxyE7i7q/RL1r19RdrGee+uILSXzQfU1LWszIX25Xs
a1OfqqOqrMtbOmMSVYaS1wIVxL0oCFlJ2rq+sdRJ19SJNl4PjpMSWYSmRG5Q
2mKTKG6lVgVtMSgwICtJxl9MgywXHH616RkI4hJIP6ssy4bC1k0qIA168kzo
XPqpikgkGEZNRrOmYZ3LN9NZp+v/s6trt745+8Obi5uzU1pPz8evXzeLesf0
/PrN69PNanPy5Pry8uzq1B/GW7b16nL8J/wjPnSuJ7OL66vx685jHAkXIDIX
Dk5damFdmwXyJtFy7rH/4WTChoeesjSMoaR7+mLYwhpAF16VKrJ1eASUa2oq
AjUZIoioCS8BV4YhGgrMSt0hHxGcPkF3BYJu31BCIj41TGwlpGlRGtMfw+e3
jCH9zqaUHcjA+Kms2k6fBwfrNPpvh8Nk9uIF84qi6Cc4HzKm4991yFsiVge1
oLOdhZ76Hb/RF4nAw3qaYo4xWiA2hkJG35FuUkF9b82KKp8L7fks/XQjTLOP
4rupGHVrRwISQTuIs60VO0VCUsYQI3g98DNXJ5ZuMgixQC/ABIj5mqzYE/0l
po3O8XDYcdl4hcKxYmMoRdTodGc4HHXY76eXTUaHo26OAj3OKk1lwnHI6feq
XUOh85Uu4mB6bJTpeIo2xWH2w2l3A1Fdrh57TbS2da0MOBNGfZ+uC0WdkY5T
fqOcfOB5mbnqhaemmge4yFMqFp8//eNRufj86Z/bjReI8AeU3FABlP17+wMe
3jsuel7E9x1bdGKcHY6GR/jg36jzseu3uAjG92/rPdtQvas3ghadeIiOMxq8
Ojg8Cm+JlPF9Y1cnfou1MOjw3Q84i00ft4zzdK/pv035+v0vQftNQOsBxIpM
lCtc2EMS9L/A6rlvRtvbH3MmVINsK8WCcY8YFTLMZR6mWuHGbbwCLUNt+BV5
1apY/xe3Dr7IrTb/dudVQ4kduDVeWOHn3+Cmm2gIF7Ohhpr/RSTo8Ct+K/wo
h7kPFQW3YZE6akntujq3FRocQEfQhHZzrPvZgub3MuhZVjLlNDBuXU83Y8+i
QoxphqSA1VNKKKCJFinRB22tvnWdEPCuX4l9X+Dc/UHguRk3vGF5Zax3onUH
ug120e8+Bje05r7oE8lh4butH21o3qK2S6zeiCHv3NZgZ+srlxBuYAKEbfvB
GZVIh5KjlTO2LvisofxmMpz7GX/70rtu2R4u37UpFwume6FX0+yBCdAP4Cnq
f7kR6aaRXKDLUA9g9Jucj0XJ7ar71BaHZR1mZATNBx6xFpGaO5vPtNpLsIWG
kQaikLbV5q5O9wO6d7RZ4Kgo/X0iwPTEqOqmm4vx1ZidgKOYirUfsF0ZbcR8
+Q4BF/bZbF1+YRzS4q/A0prNNOt0AVeGCvn03A860kbk4rP0U1m5wRhgaCR4
2H9bl5lHJe+RencHndexD8boILiZ3r52eHvW7NbURnf4296Dz4PHb92Onxng
cGgw/3gj3I0YwLGfd5bh/WIsyHjr+AIA3z1LRu3D18jYtHJgklQu4Nv0pCia
+svkwZeY/kxSGfPwN71DuslCnIv1cNT1Ce5/Vppnop716WdMh/1/AJA0W3+c
GAAA

-->

</rfc>

