<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2.6.0) -->
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-acme-authority-token-tnauthlist-13" number="9448" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="ACME TNAuthList Auth Authority Token">TNAuthList profile Profile of ACME Automated Certificate Management Environment (ACME) Authority Token</title>
    <seriesInfo name="RFC" value="9448"/>
    <author initials="C." surname="Wendt" fullname="Chris Wendt">
      <organization>Somos Inc.</organization>
      <address>
        <postal>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>chris-ietf@chriswendt.net</email>
      </address>
    </author>
    <author initials="D." surname="Hancock" fullname="David Hancock">
      <organization>Comcast</organization>
      <organization>Somos Inc.</organization>
      <address>
        <postal>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>davidhancock.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Barnes" fullname="Mary Barnes">
      <organization>Neustar Inc.</organization>
      <address>
        <postal>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>mary.ietf.barnes@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization>Neustar Inc.</organization>
      <address>
        <postal>
	  <extaddr>Suite 570</extaddr>
          <street>1800 Sutter St Suite 570</street>
          <city>Concord, CA  94520</city>
          <country>US</country> St</street>
          <city>Concord</city>
          <region>CA</region>
	  <code>94520</code>
          <country>United States of America</country>
        </postal>
        <email>jon.peterson@neustar.biz</email>
      </address>
    </author>
    <date year="2023"/> year="2023" month="September"/>
    <area>sec</area>
    <workgroup>acme</workgroup>
    <keyword>STIR</keyword>
    <abstract>
      <t>This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers Voice over IP (VoIP) telephone providers to support Secure Telephony Telephone Identity (STI) using the TNAuthList defined by STI certificates.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC8555"/> is describes a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources like domain names, and it automates the process of generating and issuing certificates. <xref target="I-D.ietf-acme-authority-token"/> target="RFC9447"/> extends ACME to provide a general method of extending the authority and authorization of entities to control a resource via a third party Token Authority beyond the Certification Authority certification authority (CA).</t>
      <t>This document is a profile document using the Authority Token mechanism defined in <xref target="I-D.ietf-acme-authority-token"/>. target="RFC9447"/>. It is a profile that  specifically addresses the STIR Secure Telephone Identity Revisited (STIR) problem statement described in <xref target="RFC7340"/> target="RFC7340"/>, which identifies the need for Internet credentials that can attest authority for the originator of VoIP calls in order to detect impersonation, which is currently an enabler for common attacks associated with illegal robocalling, voicemail hacking, and swatting.  These credentials are used to sign PASSporTs Personal Assertion Tokens (PASSporTs) <xref target="RFC8225"/>, which can be carried in using protocols such as SIP <xref target="RFC8224"/>.  Currently, the only defined credentials for this purpose are the certificates specified in <xref target="RFC8226"/> using the TNAuthList.  This document defines the use of the TNAuthList Authority Token in the ACME challenge to proof prove the authoritative use of the contents of the TNAuthList, including a Service Provider Token Code (SPC), a Telephone Number, telephone number, or a set of telephone numbers or telephone number blocks.</t>
      <t>This document also describes the ability for a telephone authority to authorize the creation of CA types of certificates for delegation delegation, as defined in <xref target="RFC9060"/>.</t>
    </section>
    <section anchor="terminology"><name>Terminology</name>

<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", anchor="terminology">
      <name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="acme-new-order-identifiers-for-tnauthlist"><name>ACME new-order identifiers anchor="acme-new-order-identifiers-for-tnauthlist">
      <name>ACME New-Order Identifiers for TNAuthList</name>

<t>In <xref target="RFC8555"/>, Section 7
      <t><xref target="RFC8555" section="7" sectionFormat="of" /> defines the procedure that an ACME client uses to order a new certificate from a CA. The new-order request contains an identifier field that specifies the identifier objects the order corresponds to.  This draft document defines a new type of identifier object called TNAuthList. A TNAuthList identifier contains the identity information to be populated in the TN Authorization List TNAuthList of the new certificate. For the TNAuthList identifier, the new-order request includes a type set to the string "TNAuthList". The value of the TNAuthList identifier MUST <bcp14>MUST</bcp14> be set to the details of the TNAuthList requested.</t>
      <t>The format of the string that represents the TNAuthList MUST <bcp14>MUST</bcp14> be
   constructed using base64url encoding, as per <xref target="RFC8555"/> base64url encoding described in Section 5 of
   <xref target="RFC4648"/> according to the profile specified in JSON Web Signature target="RFC4648" section="5" sectionFormat="of" /> and as defined in Section 2 of <xref target="RFC7515"/>. target="RFC7515" section="2" sectionFormat="of">JSON Web Signature</xref>.
      The base64url encoding MUST NOT <bcp14>MUST NOT</bcp14> include any padding characters characters, and the TNAuthList ASN.1 object MUST <bcp14>MUST</bcp14> be encoded using DER encoding rules.</t>
      <t>An example of an ACME order object “identifiers” "identifiers" field containing a TNAuthList certificate would look is as follows,</t>

<figure><artwork><![CDATA[ follows:</t>
      <sourcecode type=""><![CDATA[
 "identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}]
]]></artwork></figure>
]]></sourcecode>
      <t>where the "value" object string represents the arbitrary length base64url encoded of the base64url-encoded string.</t>
      <t>A full new-order request would look as follows,</t>

<figure><artwork><![CDATA[ follows:</t>
      <sourcecode type=""><![CDATA[
POST /acme/new-order HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/evOfKhNU60wg",
    "nonce": "5XJ1L3lEkMG7tR6pA00clA",
    "url": "https://example.com/acme/new-order"
  }),
  "payload": base64url({
    "identifiers": [{"type":"TNAuthList","value":"F83n...n27DN3"}],
    "notBefore": "2021-01-01T00:00:00Z",
    "notAfter": "2021-01-08T00:00:00Z"
  }),
  "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
]]></artwork></figure>
]]></sourcecode>
      <t>On receiving a valid new-order request, the ACME server creates an authorization object, <xref target="RFC8555"/> Section 7.1.4, object (<xref target="RFC8555" section="7.1.4" sectionFormat="comma" />), containing the challenge that the ACME client must satisfy to demonstrate authority for the identifiers specified by the new order (in this case, the TNAuthList identifier). The CA adds the authorization object URL to the "authorizations" field of the order object, object and returns the order object to the ACME client in the body of a 201 (Created) response.</t>

<figure><artwork><![CDATA[
      <sourcecode type=""><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/json
Replay-Nonce: MYAuvOpaoIiywTezizk5vw
Location: https://example.com/acme/order/1234

{
  "status": "pending",
  "expires": "2022-01-08T00:00:00Z",

  "notBefore": "2022-01-01T00:00:00Z",
  "notAfter": "2022-01-08T00:00:00Z",
  "identifiers":[{"type":"TNAuthList",
                 "value":"F83n2a...avn27DN3"}],

  "authorizations": [
   "https://example.com/acme/authz/1234"
  ],
  "finalize": "https://example.com/acme/order/1234/finalize"
}
]]></artwork></figure>
]]></sourcecode>
    </section>
    <section anchor="tnauthlist-identifier-authorization"><name>TNAuthList anchor="tnauthlist-identifier-authorization">
      <name>TNAuthList Identifier Authorization</name>
      <t>On receiving the new-order response, the ACME client queries the referenced authorization object to obtain the challenges for the identifier contained in the new-order request request, as shown in the following example request and response.</t>

<figure><artwork><![CDATA[
      <sourcecode type=""><![CDATA[
POST /acme/authz/1234 HTTP/1.1
    Host: example.com
    Content-Type: application/jose+json

    {
      "protected": base64url({
        "alg": "ES256",
        "kid": " https://example.com/acme/acct/evOfKhNU60wg",
        "nonce": "uQpSjlRb4vQVCjVYAyyUWg",
        "url": "https://example.com/acme/authz/1234"
      }),
      "payload": "",
      "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
    }
]]></artwork></figure>

<figure><artwork><![CDATA[
]]></sourcecode>
      <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/some-directory>;rel="index"

{
  "status": "pending",
  "expires": "2022-01-08T00:00:00Z",

  "identifier": {
    "type":"TNAuthList",
    "value":"F83n2a...avn27DN3"
  },

  "challenges": [
    {
      "type": "tkauth-01",
      "tkauth-type": "atc",
      "token-authority": "https://authority.example.org",
      "url": "https://example.com/acme/chall/prV_B7yEyA4",
      "token": "IlirfxKKXAsHtmzK29Pj8A"
    }
  ]
}
]]></artwork></figure>
]]></sourcecode>
      <t>When processing a certificate order containing an identifier of type "TNAuthList", a CA uses the Authority Token challenge type of "tkauth-01" with a "tkauth-type" of "atc" in <xref target="I-D.ietf-acme-authority-token"/> target="RFC9447"/> to verify that the requesting ACME client has authenticated and authorized control over the requested resources represented by the "TNAuthList" value.</t>
      <t>The challenge "token-authority" parameter is only used in cases where the VoIP telephone network requires the CA to identify the Token Authority. This is currently not the case for the SHAKEN Signature-based Handling of Asserted information using toKENs (SHAKEN) <xref target="ATIS-1000080"/> certificate framework governance, governance but may be used by other frameworks. If a "token-authority" parameter is present, then the ACME client MAY <bcp14>MAY</bcp14> use the "token-authority" value to identify the URL representing the Token Authority that will provide the TNAuthList Authority Token response to the challenge. If the "token-authority" parameter is not present, then the ACME client MUST <bcp14>MUST</bcp14> identify the Token Authority based on locally configured information or local policies.</t>
      <t>The ACME client responds to the challenge by posting the TNAuthList Authority Token to the challenge URL identified in the returned ACME authorization object, an example of which follows.</t>

<figure><artwork><![CDATA[ follows:</t>
      <sourcecode type=""><![CDATA[
POST /acme/chall/prV_B7yEyA4 HTTP/1.1
Host: boulder.example.com
Content-Type: application/jose+json

{
  "protected": base64url({
  "alg": "ES256",
  "kid": "https://example.com/acme/acct/evOfKhNU60wg",
  "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
  "url": "https://boulder.example.com/acme/authz/asdf/0"
  }),
  "payload": base64url({
  "tkauth": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"
  }),
  "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
]]></artwork></figure>
]]></sourcecode>
      <t>The "tkauth" field is defined as a new field in the challenge object specific to the tkauth-01 challenge type that should contain the TNAuthList Authority Token defined in the next section.</t>
    </section>
    <section anchor="tnauthlist-authority-token"><name>TNAuthList anchor="tnauthlist-authority-token">
      <name>TNAuthList Authority Token</name>
      <t>The Telephone Number Authority List TNAuthList Authority Token (TNAuthList Authority Token) is a profile instance of the ACME Authority Token defined in <xref target="I-D.ietf-acme-authority-token"/>.</t> target="RFC9447"/>.</t>
<t>The TNAuthList Authority Token Protected protected header MUST <bcp14>MUST</bcp14> comply with the Authority Token Protected header as defined in <xref target="I-D.ietf-acme-authority-token"/>.</t> "Request Authentication" (<xref target="RFC8555" section="6.2" sectionFormat="of"/>).</t>
      <t>The TNAuthList Authority Token Payload MUST <bcp14>MUST</bcp14> include the mandatory claims "exp", "jti", and "atc", "atc" and MAY <bcp14>MAY</bcp14> include the optional claims defined for the Authority Token detailed in the next subsections.</t>
      <section anchor="iss-claim"><name>"iss" claim</name> anchor="iss-claim">
        <name>"iss" Claim</name>
        <t>The "iss" claim is an optional claim defined in <xref target="RFC7519"/> Section 4.1.1. target="RFC7519" section="4.1.1" sectionFormat="comma" />.  It can be used as a URL identifying the Token Authority that issued the TNAuthList Authority Token beyond the "x5u" or other Header header claims that identify the location of the certificate or certificate chain of the Token Authority used to validate the TNAuthList Authority Token.</t>
      </section>
      <section anchor="exp-claim"><name>"exp" claim</name> anchor="exp-claim">
        <name>"exp" Claim</name>
        <t>The "exp" claim, defined in <xref target="RFC7519"/> Section 4.1.4, MUST target="RFC7519" section="4.1.4" sectionFormat="comma" />, <bcp14>MUST</bcp14> be included and contains the DateTime value of the ending date and time that the TNAuthList Authority Token expires.</t>
      </section>
      <section anchor="jti-claim"><name>"jti" claim</name> anchor="jti-claim">
        <name>"jti" Claim</name>
        <t>The "jti" claim, defined in <xref target="RFC7519"/> Section 4.1.7, MUST target="RFC7519" section="4.1.7" sectionFormat="comma" />, <bcp14>MUST</bcp14> be included and contains a unique identifier for this TNAuthList Authority Token transaction.</t>
      </section>
      <section anchor="atc-claim"><name>"atc" claim</name> anchor="atc-claim">
        <name>"atc" Claim</name>
        <t>The "atc" claim MUST <bcp14>MUST</bcp14> be included and is defined in <xref target="I-D.ietf-acme-authority-token"/>. target="RFC9447"/>.  It contains a JSON object with the following elements:</t>

<t><list style="symbols">
  <t>a
        <ul spacing="normal">
          <li>a "tktype" key with a string value equal to "TNAuthList" to represent a TNAuthList profile of the authority token Authority Token <xref target="I-D.ietf-acme-authority-token"/> target="RFC9447"/> defined by this document. "tktype" is a required key and MUST <bcp14>MUST</bcp14> be included.</t>
  <t>a included.</li>
          <li>a "tkvalue" key with a string value equal to the base64url encoding of the TN Authorization List TNAuthList certificate extension ASN.1 object using DER encoding rules. "tkvalue" is a required key and MUST <bcp14>MUST</bcp14> be included.</t>
  <t>a included.</li>
          <li>a "ca" key with a boolean value set to either true when the requested certificate is allowed to be a CA cert for delegation uses or false when the requested certificate is not intended to be a CA cert, only an end-entity certificate. "ca" is an optional key, key; if not included included, the "ca" value is considered false by default.</t>
  <t>a default.</li>
          <li>a "fingerprint" key is constructed as defined in <xref target="RFC8555"/> Section 8.1 target="RFC8555" section="8.1" sectionFormat="comma" />, corresponding to the computation of the "Thumbprint" step using the ACME account key credentials. "fingerprint" is a required key and MUST <bcp14>MUST</bcp14> be included.</t>
</list></t> included.</li>
        </ul>
        <t>An example of the TNAuthList Authority Token is as follows:</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{
  "protected": base64url({
    "typ":"JWT",
    "alg":"ES256",
    "x5u":"https://authority.example.org/cert"
  }),
  "payload": base64url({
    "iss":"https://authority.example.org",
    "exp":1640995200,
    "jti":"id6098364921",
    "atc":{"tktype":"TNAuthList",
      "tkvalue":"F83n2a...avn27DN3",
      "ca":false,
      "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:
       D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}
  }),
  "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
]]></artwork></figure>
]]></sourcecode>
      </section>
      <section anchor="acquiring-the-token-from-the-token-authority"><name>Acquiring anchor="acquiring-the-token-from-the-token-authority">
        <name>Acquiring the token Token from the Token Authority</name>
        <t>Following <xref target="I-D.ietf-acme-authority-token"/> Section 5, target="RFC9447" section="5" sectionFormat="comma" />, the authority token Authority Token should be acquired using a RESTful HTTP POST transaction as follows:</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
  POST /at/account/:id/token HTTP/1.1
  Host: authority.example.org
  Content-Type: application/json
]]></artwork></figure>
  ]]></sourcecode>
        <t>The request will pass the account id identifier as a string in the request parameter "id".  This string will be managed as an identifier specific to the Token Authority's relationship with a communications service provider Communications Service Provider (CSP). There is assumed to also be a corresponding authentication procedure that can be verified for the success of this transaction. For transaction, for example, an HTTP authorization header containing a valid authorization credentials credentials, as defined in <xref target="RFC7231"/> Section 14.8.</t> target="RFC9110" section="11.6.2" sectionFormat="comma" />.</t>
        <t>The body of the POST request MUST <bcp14>MUST</bcp14> contain a JSON object with key value pairs corresponding to values that are requested as the content of the claims in the issued token. As an example, the body SHOULD <bcp14>SHOULD</bcp14> contain a JSON object as follows:</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
 {
   "tktype":"TNAuthList",
   "tkvalue":"F83n2a...avn27DN3",
   "ca":false,
   "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3
     :BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"
 }
]]></artwork></figure>

<t>The
]]></sourcecode>
        <t>If successful, the response to the POST request if successful returns a 200 OK (OK) with a JSON body that contains, at a minimum, the TNAuthList Authority Token as a JSON object with a key of "token" and the base64url encoded base64url-encoded string representing the atc token. JSON is easily extensible, so users of this specification may want to pass other pieces of information relevant to a specific application.</t>
        <t>An example of a successful response would be as follows:</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json

{"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"}
]]></artwork></figure>
]]></sourcecode>
        <t>If the request is not successful, the response should indicate the error condition.  Specifically, for the case that the authorization credentials are invalid or if the Account ID account identifier provided does not exist, the response code MUST <bcp14>MUST</bcp14> be 403 - Forbidden. (Forbidden). Other 4xx and 5xx responses MUST <bcp14>MUST</bcp14> follow standard <xref target="RFC7231"/> HTTP error condition conventions.</t> conventions <xref target="RFC9110"/>.</t>
      </section>
      <section anchor="token-authority-responsibilities"><name>Token anchor="token-authority-responsibilities">
        <name>Token Authority Responsibilities</name>
        <t>When creating the TNAuthList Authority Token, the Token Authority MUST <bcp14>MUST</bcp14> validate that the information contained in the ASN.1 TNAuthList accurately represents the service provider code (SPC) or telephone number (TN) resources the requesting party is authorized to represent based on their pre-established pre-established, verified, and verified secure relationship between the Token Authority and the requesting party. Note that the fingerprint in the token request is not meant to be verified by the Token Authority, Authority but rather is meant to be signed as part of the token so that the party that requests the token can, as part of the challenge response, allow the ACME server to validate that the token requested and used came from the same party that controls the ACME client.</t>
      </section>
      <section anchor="scope-of-the-tnauthlist"><name>Scope anchor="scope-of-the-tnauthlist">
        <name>Scope of the TNAuthList</name>
        <t>Because this specification specifically involves the TNAuthList defined in <xref target="RFC8226"/> target="RFC8226"/>, which involves SPC, TNBlock, telephone number ranges, and individual TNs, telephone numbers, the client may also request an Authority Token with some subset of its own authority as the TNAuthList provided in the "tkvalue" element in the "atc" JSON object. Generally, the scope of authority representing a communications service provider CSP is represented by a particular SPC (e.g. (e.g., in North America, an operating company number (OCN) or service provider identifier (SPID)). That Based on number allocations, that provider is also generally associated, based on number allocations, associated
	with a particular set of different TN Blocks telephone number ranges and/or TNs. telephone numbers.  The TNAuthList can be constructed to define a limited scope of the TNBlocks TelephoneNumberRanges or TNs TelephoneNumbers (<xref target="RFC8226" sectionFormat="comma" section="9"/>) either associated with an SPC or with the scope of TN Blocks telephone number ranges or TNs telephone numbers the client has authority over.</t>
        <t>As recommended in the Security Considerations section in <xref target="I-D.ietf-acme-authority-token"/> security considerations, target="RFC9447"/>, an Authority Token can either have a scope that attests all of the resources which that a client is eligible to receive certificates for, for or potentially a more limited scope that is intended to capture only those resources for which a client will receive a certificate from a particular certification authority.  Any certification authority that sees an Authority Token can learn information about the resources a client can claim.  In cases where this incurs a privacy risk, Authority Token scopes should be limited to only the resources that will be attested by the requested ACME certificate.</t>
      </section>
    </section>
    <section anchor="validating-the-tnauthlist-authority-token"><name>Validating anchor="validating-the-tnauthlist-authority-token">
      <name>Validating the TNAuthList Authority Token</name>
      <t>Upon receiving a response to the challenge, the ACME server MUST <bcp14>MUST</bcp14> perform the following steps to determine the validity of the response.</t>

<t><list style="symbols">
  <t>Verify
      <ol spacing="normal" type="1">
        <li>Verify that the value of the "atc" claim is a well-formed JSON object containing the mandatory key values.</t>
  <t>If values.</li>
        <li>If there is an "x5u" parameter parameter, verify the "x5u" parameter is a an HTTPS URL with a reference to a certificate representing the trusted issuer of authority tokens Authority Tokens for the eco-system.</t>
  <t>If ecosystem.</li>
        <li>If there is an "x5c" parameter parameter, verify the certificate array contains a certificate representing the trusted issuer of authority tokens Authority Tokens for the eco-system.</t>
  <t>Verify ecosystem.</li>
        <li>Verify the TNAuthList Authority Token signature using the public key of the certificate referenced by the token's "x5u" or "x5c" parameter.</t>
  <t>Verify parameter.</li>
        <li>Verify that "atc" claim contains a "tktype" identifier with the value "TNAuthList".</t>
  <t>Verify "TNAuthList".</li>
        <li>Verify that the "atc" claim "tkvalue" identifier contains the equivalent base64url encoded base64url-encoded TNAuthList certificate extension string value as the Identifier identifier specified in the original challenge.</t>
  <t>Verify challenge.</li>
        <li>Verify that the remaining claims are valid (e.g., verify that token has not expired)</t>
  <t>Verify expired).</li>
        <li>Verify that the "atc" claim "fingerprint" is valid and matches the account key of the client making the request</t>
  <t>Verify request.</li>
        <li>Verify that the "atc" claim "ca" identifier boolean corresponds to the CA boolean in the Basic Constraints extension in the CSR Certificate Signing Request (CSR) for either CA certificate or end-entity certificate</t>
</list></t> certificate.</li>
      </ol>
      <t>If all steps in the token validation process pass, then the ACME server MUST <bcp14>MUST</bcp14> set the challenge object "status" to "valid". If any step of the validation process fails, the "status" in the challenge object MUST <bcp14>MUST</bcp14> be set to "invalid".</t>
    </section>
    <section anchor="using-acme-issued-certificates-with-json-web-signature"><name>Using ACME-issued anchor="using-acme-issued-certificates-with-json-web-signature">
      <name>Using ACME-Issued Certificates with JSON Web Signature</name>
      <t>JSON Web Signature (JWS, (JWS) <xref target="RFC7515"/>) target="RFC7515"/> objects can include an "x5u" header parameter to refer to a certificate that is used to validate the JWS signature.  For example, the STIR PASSporT framework <xref target="RFC8225"/> uses "x5u" to indicate the STIR certificate used to validate the PASSporT JWS object.  The URLs used in "x5u" are expected to provide the required certificate in response to a GET request, not a POST-as-GET POST-as-GET, as required for the "certificate" URL in the ACME order object.  Thus  Thus, the current mechanism generally requires the ACME client to download the certificate and host it on a public URL to make it accessible to relying parties.  This section defines an optional mechanism for the Certificate Authority certification authority (CA) to host the certificate directly and provide a URL that the ACME client owner can directly reference in the "x5u" of their signed PASSporTs.</t>
      <t>As described in Section 7.4 of <xref target="RFC8555"/> target="RFC8555" section="7.4" sectionFormat="of"/>, when the certificate is ready for making a finalize "finalize" request, the server will return a 200 (OK) with the updated order object.  In this response, an ACME Server server can add a newly defined field called "x5u" that can pass this URL to the ACME client for usage in generated PASSporTs as a publically publicly available URL for PASSporT validation.</t>
      <dl>
        <dt>x5u (optional, string):</dt>
        <dd>
    <t>A
          <t>a URL that can be used to reference the certificate in the "x5u" parameter of a JWS object <xref target="RFC7515"/></t>
        </dd>
      </dl>
      <t>The publishing of the certificates at the new "x5u" URL should follow the GET request requirement as mentioned above and should be consistent with the timely publication according to the durations of the certificate lifecycle.</t> life cycle.</t>
      <t>The following is an example of the use of "x5u" in the response when the certificate status is "valid".</t>

<figure><artwork><![CDATA[
      <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo

{
  "status": "valid",
  "expires": "2016-01-20T14:09:07.99Z",

  "notBefore": "2016-01-01T00:00:00Z",
  "notAfter": "2016-01-08T00:00:00Z",

  "identifiers": [
    "type":"TNAuthList",
    "value":"F83n2a...avn27DN3"
  ],

  "authorizations": ["https://sti-ca.com/acme/authz/1234"],

  "finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",

  "certificate": "https://example.com/acme/cert/mAt3xBGaobw",

  "x5u": "https://example.com/cert-repo/giJI53km23.pem"
}
]]></artwork></figure>
]]></sourcecode>
    </section>
    <section anchor="usage-considerations"><name>Usage anchor="usage-considerations">
      <name>Usage Considerations</name>
      <section anchor="large-number-of-non-contiguous-tnauthlist-values"><name>Large number anchor="large-number-of-non-contiguous-tnauthlist-values">
        <name>Large Number of Non-contiguous Noncontiguous TNAuthList values</name> Values</name>
        <t>There are many scenarios and reasons to have various combinations of SPCs, TNs, and TN Ranges. ranges.  <xref target="RFC8226"/> has provided a somewhat unbounded set of combinations.  It's possible that a complex non-contiguous noncontiguous set of telephone numbers are being managed by a CSP.  Best practice may be simply to split a set of non-contiguous noncontiguous numbers under management into multiple STI certificates to represent the various contiguous parts of the greater non-contiguous noncontiguous set of TNs, particularly if the length of the set of values in an identifier object grows to be too large.</t>
      </section>
    </section>

    <section anchor="security_considerations"><name>Security anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Per this document, IANA has added a new identifier object type to the "ACME Identifier Types" registry defined in <xref target="RFC8555" section="9.7.7" sectionFormat="of" />.</t>
      <table>
	<thead>
	  <tr>
	    <th>Label</th>
	    <th>Reference</th>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>TNAuthList</td>
	    <td>RFC 9448</td>
	  </tr>
	</tbody>
      </table>
    </section>
    <section anchor="security_considerations">
      <name>Security Considerations</name>
      <t>The token represented by this document has the credentials to represent the scope of a telephone number, a block of telephone numbers, or an entire set of telephone numbers represented by an SPC. The creation, transport, and any storage of this token MUST <bcp14>MUST</bcp14> follow the strictest of security best practices beyond the recommendations of the use of encrypted transport protocols in this document to protect it from getting in the hands of bad actors with illegitimate intent to impersonate telephone numbers.</t>
      <t>This document inherits the security properties of <xref target="I-D.ietf-acme-authority-token"/>. target="RFC9447"/>. Implementations should follow the best practices identified in <xref target="RFC8725"/>.</t>
      <t>This document only specifies SHA256 for the fingerprint hash. However, the syntax of the fingerprint object would permit other algorithms if, due to concerns about algorithmic agility, a more robust algorithm were required at a future time.  Future specifications can define new algorithms for the fingerprint object as needed.</t>
    </section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>This document requests the addition of a new identifier object type to the "ACME Identifier Types" registry defined in Section 9.7.7 of <xref target="RFC8555"/>.</t>

<figure><artwork><![CDATA[
                         +------------+-----------+
                         |   Label    | Reference |
                         +------------+-----------+
                         | TNAuthList |  RFCThis  |
                         +------------+-----------+
]]></artwork></figure>

</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>We would like to thank Richard Barnes and Russ Housley for valuable contributions to this document.</t>

</section>

  </middle>
  <back>

    <references title='Normative References'>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<reference anchor='I-D.ietf-acme-authority-token'> anchor='RFC9447' target='https://www.rfc-editor.org/info/rfc9447'>
<front>
      <title>ACME
<title>Automated Certificate Management Environment (ACME) Challenges Using an Authority Token</title>
<author initials='J' surname='Peterson' fullname='Jon Peterson' initials='J.' surname='Peterson'>
         <organization>Neustar, Inc.</organization> Peterson'>
<organization />
</author>
<author initials='M' surname='Barnes' fullname='Mary Barnes' initials='M.' surname='Barnes'>
         <organization>Neustar, Inc.</organization> Barnes'>
<organization />
</author>
<author initials='D' surname='Hancock' fullname='David Hancock' initials='D.' surname='Hancock'>
         <organization>Comcast</organization> Hancock'>
<organization />
</author>
<author initials='C' surname='Wendt' fullname='Chris Wendt' initials='C.' surname='Wendt'>
         <organization>Somos</organization> Wendt'>
<organization />
</author>
<date day='24' month='October' year='2022'/>
      <abstract>
	 <t>   Some proposed extensions to the Automated Certificate Management
   Environment (ACME) rely on proving eligibility for certificates
   through consulting an external authority that issues a token
   according to a particular policy.  This document specifies a generic
   Authority Token challenge for ACME which supports subtype claims for
   different identifiers or namespaces that can be defined separately
   for specific applications.

	 </t>
      </abstract> year='2023' month='August'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-acme-authority-token-09'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-acme-authority-token-09.txt' type='TXT'/>
</reference>

<reference anchor='RFC4648' target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/></author>
<date month='October' year='2006'/>
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/> name="RFC" value="9447"/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>

<reference anchor='RFC7231' target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author fullname='R. Fielding' initials='R.' role='editor' surname='Fielding'><organization/></author>
<author fullname='J. Reschke' initials='J.' role='editor' surname='Reschke'><organization/></author>
<date month='June' year='2014'/>
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>

<reference anchor='RFC7515' target='https://www.rfc-editor.org/info/rfc7515'>
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7515'/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/>
</reference>

<reference anchor='RFC7519' target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/></author>
<date month='May' year='2015'/>
<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='RFC8226' target='https://www.rfc-editor.org/info/rfc8226'>
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='S. Turner' initials='S.' surname='Turner'><organization/></author>
<date month='February' year='2018'/>
<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='RFC8555' target='https://www.rfc-editor.org/info/rfc8555'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author fullname='R. Barnes' initials='R.' surname='Barnes'><organization/></author>
<author fullname='J. Hoffman-Andrews' initials='J.' surname='Hoffman-Andrews'><organization/></author>
<author fullname='D. McCarney' initials='D.' surname='McCarney'><organization/></author>
<author fullname='J. Kasten' initials='J.' surname='Kasten'><organization/></author>
<date month='March' year='2019'/>
<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names.  Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.  As of this writing, this verification is done through a collection of ad hoc mechanisms.  This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>
</front>
<seriesInfo name='RFC' value='8555'/>
<seriesInfo name='DOI' value='10.17487/RFC8555'/>
</reference>

<reference anchor='RFC8725' target='https://www.rfc-editor.org/info/rfc8725'>
<front>
<title>JSON Web Token Best Current Practices</title>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></author>
<author fullname='D. Hardt' initials='D.' surname='Hardt'><organization/></author>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<date month='February' year='2020'/>
<abstract><t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas.  This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t></abstract>
</front>
<seriesInfo name='BCP' value='225'/>
<seriesInfo name='RFC' value='8725'/>
<seriesInfo name='DOI' value='10.17487/RFC8725'/>
</reference>

<reference anchor='RFC9060' target='https://www.rfc-editor.org/info/rfc9060'>
<front>
<title>Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<date month='September' year='2021'/>
<abstract><t>The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.</t></abstract>
</front>
<seriesInfo name='RFC' value='9060'/>
<seriesInfo name='DOI' value='10.17487/RFC9060'/>
</reference>

<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 fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

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

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9060.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title='Informative References'>
      <references>
        <name>Informative References</name>
        <reference anchor="ATIS-1000080" > target="https://access.atis.org/apps/group_public/download.php/69428/ATIS-1000080.v005.pdf">
          <front>
            <title>Signature-based Handling of Asserted information using toKENs (SHAKEN) (SHAKEN): Governance Model and Certificate Management &lt;https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000080.pdf&gt;</title>
    <author >
      <organization>ATIS/SIP Forum NNI Task Group</organization> Management</title>
            <author>
              <organization>ATIS</organization>
            </author>
            <date year="2017" month="July"/> year="2022" month="December"/>
          </front>
	  <refcontent>ATIS-1000080.v005</refcontent>
        </reference>

<reference anchor='RFC7340' target='https://www.rfc-editor.org/info/rfc7340'>
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organization/></author>
<date month='September' year='2014'/>
<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
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>We would like 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 thank <contact fullname="Richard Barnes"/> and <contact fullname="Russ Housley"/> for attaching a secure identity valuable contributions 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='RFC8224' target='https://www.rfc-editor.org/info/rfc8224'>
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/></author>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
<date month='February' year='2018'/>
<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 fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<date month='February' year='2018'/>
<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>

    </references> document.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAMF8jmMAA7U823bbyJHv/IpezkOshKRISrIk7G5OKEq2ZVsXi7Q9Mzk5
c5pAk2wLBBg0IJp2nJMP2f25fMlWVXcDjQslTzKrM4lBoC/V1XWv6u52u61U
pqHw2PR6lKXLt1KlbJ3EcxkKFs/ZaHx1wfBDnMh0y6bxvYhafDZLxIOnPzr9
8ME0CWI/4isYNkj4PO1Kkc673F+JLrdjdVNs2E0jfBNC9+5g2PJ5KhZxsvWY
SoNWS64Tj6VJptJhv3/aH7Z4Ijh8E37rXmw3cRJ4DEctfk2ml3etlkp5FPzC
wzgCCLZCtdbSY39OY7/DVJykiZgreNqu8OEvrZaGyWuxbovBn4yUx8Y99lFE
QUpv9FLGy0Qq522cLGDCeBUrdhn5PXonVlyGHvOxKa36T/S4wU69SOiOfpxF
KS7y/aQ053mPveKRH/v3zqzn/EEGpfc07zhe+Vyl7qQBtlzqhj2ae4Efen68
enTaqx4740kEaCpmveLJ1n1Lc14L2Ame1Fa7gsY0YW9GPZ6cl6Z93WO3IhWJ
iqNWPu/rOCq9bZzXTPspjnpr0/ZPkW7Tm8kv2ETBJovUY4OTfp9NshRasUkK
TzIV7Oi4j218oEJEJCAsCTpsPGLs9PBoqL85MLeiOFnxVD4IIBF22T3v7SRn
bHD3Ynz4/PDEPB4PDwb28WhwVDyemseT4fC5fTw6sg1Ojof28bT/vO+1ZDR3
oRhNLyfdQR/+TvoeYdmw8UQuIp5miejOuBJEOEEoowUxs1IiSeFlPhhgO1P4
NY3fXFwr9mzyagQPe+xl/CCSCGhJsKs4ECGDYdgYesu5RCYFAon4QqxElLL/
WqbpWnn7+9z3hVI9GFf1YOP2+Xqt9hdJnK1/WWezUPr7QbyJwpgHvfVyvX8w
HB4c77sr6a2D+R9pNTlLMkN9PJJfCGCP1r4/ubxlL+IkW7Hr60s25eqevcSZ
qEcAEHps2B8cd/vHBuMHh/0C44fFI6C51e12GZ8BzXA/bbWmS2BzEGAZrS4Q
cwk0zbgrFtOlQGkXAw7FTrxcRA8yiSN6foaycq8qSRlsA43F87EQz4aovsBP
HwQebRNM6hfTKOr5IQYkTEUo1kuQdOw2iUEAADvAbjKVrdcg6thE+EAMeast
uwwAHoTgGcjKPbv9AIMjyPWaAzbbokAtTdxraXStZBCEotX6AbgyTeIg8xHM
VuvrV0PI374xiVhbCR9kklQrAtksFOd0RgUJkmMN1orQwKhAgCLtscuUiYjP
QtyDYCVhKNgn5ANGC5GC1gubg2/mc+HTNz9GsEKGdMwSoeIsAeJkobwXsLcg
QCKSOKAHDMYJ/4rmhrGQkBHnCxGJRMOL7aRSWQV21WNfvz4qFAAT4nMKGkBp
jWmgha0C9OgJQkAT9AlwSt3W7ko+VokycppwUWCXzPP1sgfJ4We6lEnA1jzJ
6a6gw5nYxjAwTlWQMQ5eNHk2Hu31qmwhXY7I3xbUVKX0ggwsccEOPIk42v3S
VOmSpyDe18InUMMQEBMEsGBlNg8tAGwNBLMCNQA7RJARXaIQgN3YLKW/ZJIY
YS5Nv0gATEiilvKQ96gJD5We1ucR46BKgEOKbbEsDL8WEkQv/IR9IdZE8BSu
E/QLUCFsUQDqyocVrdaktQjTHQuPYsCqCcyIa4oM0Sc0AajSVUyTc/8e0KFU
7EuSFxsJNpcMQ7EAIoJVxzgpbEKHPcTSJ03JltCJXiEJqQ2MAr96jE2XQonS
MsG+gj2EYVGCgCZht6PJBOTIVGkEorz89s1CjPiYwQA8SaTeUL3/gH2wtWIY
T2XQjCuG0toOcIjbysZ2qR2NvQgWbSnDhUijF3CzzpJ1DOAiiNijJA0NPViq
MmoVtrpJvNHKm0Q8NoPVWwFfsWxdapZaSBE7A10D+qOFMIxtelsK0aLKGRbZ
FGZV9Wk6MK4fZsT7HCR38gA7mIt1M/Wzye14D7bSEfzX2Womkg5D+QrGcUoj
518j+qrwa/Ulm4VgK6oacwPikVaVn8iZwQufydCSO3cGKhgBVp8rLr1QR3eB
cZVu10I16jGwL4B8qSnQSkk+GPsHSAZVzVQkoADiMF5sEWTBjN2vWPvq/WTa
7uh/2fUNPd9dvHt/eXdxjs9g2Lx9mz/YFpNXN+/fnhdPRc/xzdXVxfW57gxv
WeXV1eintmao9s3t9PLmevS2rcmihMiEqAKYRKJUWSeCdLzKkUvLPBvfssEh
rPY/YLnDweAUCFf/OBkcH5LAEpGejPhE/wQUg5xYrwVYxjAIECFw4hoILkSl
BjyxBGOLLUUiCHdEq5HYdLUwyqVfovegoMJW69LyEKnxDtoQtDnHJU4hLRlk
iZHJIAs0O4RSawKtlPRsHGcuafx5Eq/g9XjUQzHkAJaIv2YoYZFNQEsrHLgA
lsH/hYGe0TK9BsdpE88+AcTKiGUcFCx8UBHrGHVwGucCAH1Tx8BDGJFKkUhr
w5E0h/1y5cjIlRFOjxz2AjBgENfq1kSxjtdZyLVFbmSBFTVGxdPIRlBUUNhD
+7cqqAogOrZPBa9axNB6aa0oLwAabAyGFYqedjFeW+/OAw+zJrHoLJn4blYa
DpQdaJ8GOWdhEUFPs7HGi21owKA9TgTwjCJxWRnDTgi4hg5gfgIWtbRHx+f5
YZaEoEL9ONCaDxQIQOlap/VmZa60VH+EcFFHdOugI7g5gFLtNVlOINukpIVe
T26u2UcxKzwyd9BhPih6hagREQ8NIFl5ZvcN2GELplxAH0H1oMuCPMyNEecq
rcl1b2Cpl8ahUXM8nV/cFfMkWUjG/QgMj898tdZ+jmVqTUJmqH/+438c6fHP
f/yvYUpD9Vp7OXC4bL+JM2gZxvE9bsk8DsN4ozqt1t+dvxZrO+O3Pfbnr20k
1bbnUmanTVQJL1+cHERD3uv1+EM0PD6/Pmh/+0t5wNYGxSDhx/SyazG0ViEz
nswkOBnJlqFiBwOrsjGAQt0REcbmGYjeOqN911Jvb2Bb9tH43S9GeDWd3u4P
eoPWq1ilnt0PiqeMtfHQnQI+PJT+obHX9z+BcfSHT4p8MHBu22iECeQKQGAO
/rOv5B+3ebiA1+2LyfDoebuj391LbNq2zrwzq4YPyD7dFw838zfL6/fP+5uF
7RjFkS+w69GPrwdvD8KL+6uXx+nd8/Wo3/fDkW0G0z86fr7+NrT/ttehRfAt
hgualvCrSQQIJCePHPL0TIDwIeiH/eGg28f/pv2+R//9XCwxHc2Bz0rtTpx2
BcjKsju2ffX85x/Tl5+mP2/fR7fiDcKwuRgdTu/Ds2B5IA6PDhft1rcKsd5E
QEO+kA+ak2ANMqjTV6ewQBVYiqh10N4SpDArfiLReqck/XKd3hv0Djsu75Lp
Vti0KIULW1cr91UG9K0wzjPfardmRVIYObzuGbmmRiEiZ9tcqel1PbPWkw9b
3dmtava0rASLEqSgcm3t0nLZ+7u3VkC3Sw1U2wgso29c4aatLDDTsiRSta92
PBcXRnPP4mBLEhPDTuAy014Ee0ybHQptsNIuWx6n5qb1Y9yNjH0n1iHfdq+R
3zx29dMoe7hZ8/hSbjdT8UV+uT962LTexr6Jk+3kNFrS/mB4cGhkBbrJGbJR
e61DD0T3bfF5LQF+Q/TDGtGDMGtgomEjE1VZqGm0Klc3M7WJCTp/j2oCDWSF
AEBg4DCPCDto/4VQhKxN8qINZiKw4hfxqBQrcLuft69x+A8uZV8WRlTJ9qsI
gqo1p8mqU6NHEA6JtYkTMQe9B9RSixzl5BzPkO/LTK8aWNdKiMJWrWu83Okw
LbTOQ+CtSZG3JCZr5gxHJRa7UOhE3PC6XsS336UbseFXQ0KP6shdetLVlbtZ
bJeyLCvM7N168im8mx0+vPsw/vThp9F2+/5jqelTSrNMp/in1ZBeXq492/mY
Zf0UZZPzy8ns48uT1dXi4vgVsM677Yf3b5+fbL/MD37mm7XS41YpeJcs67Ob
N0+JsbcyuveKrEFtTSpeiW4AksdP42T7x/9MRPjfbRkF4nP7t5BXBU1DQ2NM
oJhpkDKPCBZU+Hq8gm2sWCkITIsv+PceNwoAKvbBvLIteOo73yg1mmtSlwLy
lz2LtzgpKOZJeiFg99fJh1/OjrcX29FhZVLsfBnKZP75zZsfR+pVuvryZnh6
++lkZOkApGFNnn1cishGzbXR4tr81gUvvIOSR49aGB3REvopNGCCCA3RZMc+
Mf66g2IdE+VlFFMbRPJ3xZ1RMoJJJdG8sQaQkV24AFfeLkHqYX9cj9+YwnEz
Ec5AInDyErkDUlhGLj60B2685WLxNULBID9fYU4Uw8kULKJwLqwZrSrFCkeI
ItROQFCkmzi5J+CQiXRGYISIMHuloarkD3o6klKKXYOm1/oEZsw1iU4sAubd
fB8guhwTAtgJikWefuywWQYGJ8dMhV4LoCeGEZOiueqxyzlt+KPoMBgmlRnV
9ObV6CeK0hLqawPpCEgVGWhi5juXB5orGRYioI0EH9FmfZ4ILlvFaK3NfL9p
mc3wlRaKG/DEYjEa8Ni+Mp09BlMhjHWWBch4LhegN8rpY9heasHWMUh5KZQh
Unc2J/RW8S5gL9exSusx+hpSal0R97kUyY0SbbnDb5q/2Q3ipRCHTmUY97xk
i7iWSE1uVp30GXr7Iun91s563QT5Fx31wup494s6uPoY/3XaP5omwf3V8Gp6
7m90o4r+aFiVa3dwFcz3+9/hrxtRjEOfv9zeiU+rMZimxw+H16BTH2bD01fL
T5/e3k4Wi4282OVMn/qzxdHrm8HL+dFPbz99+gJdJ+v793M/uOXyNPvw00/v
yqa2pkQ7t3H6ZJFh4Dboa75UzOA8RmSSjZYGc01TVUM6Kr2kuI9Rd0+RtZPs
0Db15xTLm5BIehU/oVqFRYurJoGcVo3zPds94F450SojrKLyi3KHhkqwX5fL
NRDvRsat5QK2FDywQWWguTUmPVCpN9kCtV7VHNK/D5emaiM1TRwWQVmBqseM
L0jHkMuVIhMUs0OfUmmzQ2TY0SNqGLd3vMZtBtFpOlugrcqsIxvj6VViyWaG
XlB4/fAD2LdKtfWQhv6LF7TDUWXiWsINi5OcCNFhD6Rcj2Em3iR8SQ0T8zhC
ePuo/sPCCVGPUFdW6BQjtD8fZW3ULlrXv9JbazClh3TVV2iiHnmStWR/ln4C
08q8XRVYm/ymoBu2fhxig3Lc9RLKixed70HvYSdPZxgC0VZkKY90DuBM5aqS
jTGlIgQr5QCwRW6zPoJr4yyZFSDBllZQvPiuFRw/tQLOskiC3VvK5dnc/mN6
P+GR4rlA/MEY8S6oxYtmGOSvlAea1AvAKZNjdEEuhZzYRkgVJsprtX6vvQ7t
cNyLrfVETJZBbxwY2MB6QGMlAx9+55ZkOX1SKTtzE+6IoKd9Gaeaq5Sd7hWw
kuQ3pn9AkJPAqmCzZxdocihPrjBtzmnlCcGmZKfLqlQKpagayc1l7UxfObD9
qhX5vLSYWRyHAkSdXo3JaApJgihN4NXG2tSFK+eCjXMjdWhRMhPamcUW1XIH
cnDh1ZyH6nuGRcseKwmioD52R/t7VDkUdE3OuZQvpnVWVAAsu8Pk3IxsuIYE
MDbWGEDvDvQLFqGgeiJYZ1Suw7MwNTgEGltghQOAp5FpetncbENlRyUVcQI7
XCTqnfwqWgBZWpLv7ekS7B0zG2Bq7ZaekenvUwkvQeLUE/UqgH4vmVTyok+V
Bykn5eeVfIqnc3PAkW2v/frj1AahyAMo5+pQOXqPx4T2ceu/M5UGBsITo9mJ
UbF5g+eH/dPTo2G/b96isvDaMnjePz05eH54OhzksINs9r5aOdMYyM95tinM
ljcCavSI8vI37j56WNYD+GFHz72DC2/8whtdeCcH3njkHZ57gyPvrO8NT70X
L7zBmXc8sHXF7PzAOxt5Z6fe4NQ7GXgvTryjvnd65p2/8A5H3vmhd3DqHQ+9
i6F3Bl/72PLgxLs4aH/77XwU0GkjHwnQ0q+W61Qg02CitFovctXztOzPixg6
jcrDOCsoRnzDA5mJ4N1dTKbzLCQ/l5En7KjineTNmHGa033DgfueDPb1bE4M
XzvNjaTWejSSjz5z1cPLM+4UZOHKJAWNBJDGVjUqSpZErBM4Afpt28og05YG
nNnyZD1OKXZZdQ0re/U7DOyFOue0lGurX7CaE6whvSRF6Vss9FvbQr9n48mt
znImWpmA8bzSAp8q80jqlyWlE4HE7anUZhm7nSKa0vEwVObbQmeyDFxji6qL
zLZQzIQIoRxRMQ5XqfBDp6vL7UolpnU9gGckHFodHPZOjFNms6oILBGW3Tbj
GWofu8FEQ0muldeay0TV9Qp9NJ4EVukVKpcrt0wzdyi052Gox7oz5AOwkXJi
Sp0iHWxqCpvB3MlBJJR3S8ynxWVFVv5bgvL8QIvKf1FMtlg9HlMNb5b2FSwR
Q5Qoe2wenpvMkmUgwiOhWJO3sdWBTNF2xjMCq2xVKyGoamneaNxzoh3KKFBC
JK+s2lUDVI8Ag9KzpEHDA2cJriQYZ8agnSGZACOD+ZcU3JcXtRMXYMh7wyOy
PUmmaUd4LYWvy2jdKCxIGfFgGvNCKjmSs2zClHBstmOTq4IdlPkr03ytr0VK
6TuCfmVCMYHunCy06VuA3TGfDexGj0lgb9967SJJqHIe3mmBxibOqYFOLgQp
TZF7zI8ILqrg0+INukoTFjNa5vLcyu8AHCyh4RWfpS3UyUFF0skNzMP+Aeui
pJ3JIEB6uaFNPvz8mcjuCP61HZXupHeG0QlHngQlAUoSurJsfHrAJeQBomrI
405PIKnAWwpl0nm6evvJwHynMYxCoDoxFINcl2Rr9QTaxXNmAgWeYUkR8E2l
Pq+mMQmpVBnfWOb+bHq95yTbKtk8fTBGKjdpV3LH81wIdJQJpla60JXPQqmW
JsaQq1alz1uV1P5MpBthXLsqpqx0qcLTY9exizpHiFuEpSZbVGKRlTBiwNX3
s8Ycj06tAYaXOm3kdkWjVutChMYqQWM0xgVYGnemVJcAUU5LsDs61TGKmHlR
w0LecuG7mXq2ahiutF6Dd4rX+WDBFfaywl8OXCb/qqpJMM0NEz9eN7h0rdaZ
8LnOB9ZEc+n0EYiEOHwQtfrkmrOrD6SYsz62E5BsB3qd4TkMHSVGGQZEjRGU
6bXqGONDl92BSiADsCijqSk10mFYQaEjw4R2iYdNNpF7lqwGbi68DHEVkRQT
38o/ULjNUZs99lKfYbNneZRFaTFfSUU+bQDLWkKc045KPwt5gkhjz0Rv0UOY
ruMEVjxaAa37vKNjG/bIHgYOsF7aioGb8TUJiPqEhUkPUuTyfI/Mb56WQCLU
L+xanUNYnUJCmJmQoM3qOtascBZg9iWQc6rPSjEURiRAddz7dBxD9Uo11Oao
lRNQobpLpDEYO5Qrie9UmZrNmHo8G8GqHh6DkRGh0CgPbubDFHCZMRxqtIUP
eocxYd9jYGTg1uH+6hjVdxVbkMykaJWJMlnMNdA3IsIsZMkfcO0aWG3I0+E8
ir5ZJBRSX3Mez+s2ASGhXKAtpqU9FtqJ2uEkOlW1jlNtBeC2s1UMAr6McZPj
KMXmfL6mqn+KysEilAsMGh8VgMjZtGDwpsMyDgX5pbOahR/N2Cja7vpqEpRC
1wg3YTYUPIlKaprP4iytYDIHGbuQY4Qx82qJCaEDNlYnFeUD90EOSAVirjoz
4VA5wQiLXKxP1NgTJfVtCyrQWKUtL3RcoR60qHfin5hP/aAVytN2Tav1fh2X
C7F31mXUS7HJ/gExhHispAswWKnsWVA8zqaVG2k6YqScbm115O/Zh0opUikD
5OY/KJy5EWHYxZkBCa57U6nxLpKXubOsMJarTW8TeYhMIq4Ik+RlUaL2iWZH
I3RCiUEj9/IiVO2cuHRd85zorg+hz1nr0rBKxKooTQUh01VbaL1qBtrfAbQ7
P08SvnVTPf8/wH0oZn/EHc3jiE4oW1+bYD3SKvhOea+hfgLjd6rInlYQ0asQ
k0s7DhqKvFChF3PloImvdEisgUTdkZ2szI4zchiAhybW2C672TuOEhXJoVLy
yZg2l7UgXWHbmKPaoVNZ1bCCBA9PE7eY2A86gNr9I+OjU64QpD1EnagdP0yu
BntPIaaaizDBMzADQfz6S1GOZLpkYC3Ce0sqRvA9NSOlgArc2FRX+YAkdRuP
8q8Gb2dcATGO9VEPic5YsQemyXhyR0xgVLRJTTmZ+ObcFDn8qLW1dCw5OMYH
yMOaSlE8pFrZ5kpeStktG0p5bOUwpV9p4LauHQSlSVkkg96GOed4llFL+nyU
XRVDlcOQbRM2wPAyKqH3yhaRdk0gcexaHcRp9eODrVbDkcJnrz9OOu5Bwr38
9KtPG2cPDRqRYCK2hWQk02euH8ryz9o0jSURMG0hsGBZpWAxNqBrGOztAU5l
p3ONgM5+ariwstIN3lB3F5pGKPLxERzrjdDpINA/Ki991VMg+wJfCms8u9WY
eQawlG8tl2Jy9vIiD1R2iM05BS+7XHXxE1fFOFYRtJ0B27pcxqFZ92wRAZ4Z
C1vX0jqXZhRuR6lA162yRJPCXK9TV3QgUcAChf2kC1a4VSzmjBSIEYGf9AU+
hUkcbm08Ags7bW7EhOnzc9NONrl82QsJBAeKQuPhlSI4BcFUBVaX/oc6NlLc
lEKwNp1Gg0WjPgE48p6FzWG9Vq0Q5yaEY8Ib+e0WPXJcGo//HvcO87O6JmGd
5+kr2fkEmEsfezNymTN7Bqh8as/IKmPxY4zbhLif3bzZKzRttg7ITauQyaU5
J+fET8wx3Yk5CIgnAINAFzc692qYY7r6HLvhO5seMmkzGNY5N+diGZeVKb4g
lJprcVwU6nC6pivtKD2AxMQrTGhE7J6zayFeAfEAB3tmKahjlPme1/LYqNhz
t/LMiixtU1a3wd3vQszRybxCSrgSU2clCHC1dMpTSp6gITssFtVDI2TGYTEh
WfzuSAjLqPoeCIyuURAW41YzvKqI7mLJPR7yfFWq/UCz/VjKBXg0KNXeWPXo
eZAZZ7nJPgzlXPhbPxT5MXvrhEg3Y2W7mjtK9PryNKnNDjTRvNaDOJpVpuWT
Qb86Z1A+4Th+OT8ZvP54pv568m57ubgdy9N3pz8+eX5ox9Gh7z4YOb0JY//i
JJkv4tp5I73M+mmjwXM8bTTsTweHXv/U6x/3Tk93HJDUTZ86IGlaPXZ8qThv
tPOY5OMHmHaejcxrQVQquz5vPG5mOv+KQ5EOXouzkeYMlaMlHz2+BO32V6P0
4PPZSx7PNqY7lcM0d8MeXXDl4v2FfH15dHC/Gh701mJVPZRJWSeyzVDEjUuB
KAoUv+XJIk8oAJsAjXbRh5GLLM5KJYzalSaWS/R9RSuyL30R8UTGypx+5ArZ
FpUgxrEe8FOGierVTEYFT09ux6qjI8HYbXrN7jieNQM94IaV0fHIQ7icAsAb
lJtZNAPXgZKVOubojk+VjuAtrmOr9CmIpiuuxWcwcUpL3HmzEC5xJlCu2EIJ
itiOJ7cwwxlVWeA1FRhxNQd5lKSabrxlCiRAWlxbVJnSzoBLSNxb4sD7ALMl
C1OJAqx6SV05faMNeovefGw0a3KxuaAT2MmOJRP6i+gbRv3n9moIe2mJbmnK
CmTUcIHMIok3yuRX0jhmIVIURaUmNgBapjv29QcbGv2lHBo1SstmRCpnx9wb
iJa2nMG9zKyKnSJiX9tdPIlHt0Q1br2+cyqia+gSsZtCqtF8Cjnrc/z2lqiO
rj7BSwvNnXzkk8UJ8mNeoEILdhOhBD6YDD5dywbt8mDyzCU85daW5wHqsuo0
+g/MimS7JifBAuTcaFa74kl7Evpat1RHaheCblizOhQs4oAmmYFlzlEzKefa
NglqXhsuqRmuuB1O1FFZv4gvAjEj88SoWTyAtBZktmvj9el79pDlcUCbk6nZ
NhV8ls9eaVl0jG5dDUIK4RaXNZkCFOsguIlNINZlj72KN+LBXmCktgDSZ7tF
bmNbtEFwrjGUmpoaCR4ucHVLrNeZd8BGEuZ6RJARGN+ikHbeCOskFnS5WccG
95N4hjdc5E3YRiSOk0hCcp6RA45GGvq/+lcpT6hdcJOjQcvRgatp9UVhEN5F
SFWnP7DL0fWopo7K+C0lXvFmIFsoqw831QWRPqxkrsYgG9+JlqFlptow6AIv
2ty6eUzrEp32jnvHFaeoVykD3PH3h67z5/74w+4+f4P/veUzEeofd7nt/7ff
eh5Hif+N7oclRP+L85RqPNnIv4/iDTheWoFhlUV+GxLeSUrbwaN7difxVqfA
XL5MkvAuA9/sFeijUGj3ErUMeVaU25azTJMbjeEW+OurWmfcv2/9Hy4x4Lbq
WwAA

-->
</rfc>