<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 09/06/23 -->

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-caa-issuemail-07" number="9495" submissionType="IETF" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.5 -->
  <front>
    <title abbrev="CAA for Email Addresses">Certification Authority Authorization (CAA) Processing for Email Addresses</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-caa-issuemail-07"/> name="RFC" value="9495"/>
    <author fullname="Corey Bonnell">
      <organization>DigiCert, Inc.</organization>
      <address>
        <email>corey.bonnell@digicert.com</email>
      </address>
    </author>
    <date year="2023" month="August" day="10"/>
    <area>Security</area> month="October"/>
    <area>sec</area>
    <workgroup>lamps</workgroup>
    <keyword>caa</keyword>
    <keyword>certification authority authorization</keyword>
    <keyword>email address</keyword>
    <abstract>
      <?line 42?>

<t>The Certification Authority Authorization (CAA) DNS resource record (RR)
provides a mechanism for domains to express the allowed set of
Certification Authorities (CAs) that are authorized to issue
certificates for the domain. RFC 8659 contains the core CAA
specification, where Property Tags that restrict the issuance of
certificates which that certify domain names are defined. This specification
defines a Property Tag that grants authorization to CAs Certification Authorities to issue
certificates which that contain the <tt>id-kp-emailProtection</tt> key purpose in
the <tt>extendedKeyUsage</tt> extension and at least one or more <tt>rfc822Name</tt> value or
<tt>otherName</tt> value of type <tt>id-on-SmtpUTF8Mailbox</tt> that include includes the domain name
in the <tt>subjectAltName</tt> extension.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://CBonnell.github.io/caa-issuemail/draft-ietf-lamps-caa-issuemail.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (<eref target="mailto:spasm@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/spasm/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/CBonnell/caa-issuemail"/>.</t>
    </note>
  </front>
  <middle>
    <?line 56?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The Certification Authority Authorization (CAA) DNS resource record (RR)
provides a mechanism for domains to express the allowed set of
Certification Authorities (CAs) that are authorized to issue
certificates for the domain. <xref target="RFC8659"/> contains the core CAA
specification, where Property Tags that restrict the issuance of
certificates which that certify domain names are defined. <xref target="RFC8659"/> does not
define a mechanism to restrict the issuance of certificates which that
certify email addresses. For the purposes of this document, a
certificate "certifies" an email address if the certificate contains the
<tt>id-kp-emailProtection</tt> key purpose in
the <tt>extendedKeyUsage</tt> extension and the email address is included as a at least one <tt>rfc822Name</tt> value or
<tt>otherName</tt> value of type <tt>id-on-SmtpUTF8Mailbox</tt> that includes the domain name
in the <tt>subjectAltName</tt> extension.</t>
      <t>This document defines a CAA Property Tag which that restricts the allowed set
of issuers of certificates which that certify email addresses. Its
syntax and processing are similar to the "issue" Property Tag as defined
in section 4.2 of <xref target="RFC8659"/>.</t> target="RFC8659" sectionFormat="of" section="4.2"/>.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</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 "<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>
      <?line -18?>
</section>
    <section anchor="syntax">
      <name>Syntax of the "issuemail" Property Tag</name>
      <t>This document defines the "issuemail" Property Tag. The &nbsp;The presence of
one or more "issuemail" Properties in the Relevant Resource Record
Set (<xref target="RFC8659"/>) (RRSet) <xref target="RFC8659"/> indicates that the domain is requesting that
Certification Authorities restrict the issuance of certificates that
certify email addresses.</t>
      <t>The CAA "issuemail" Property Value has the following sub-syntax
(specified in ABNF as per <xref target="RFC5234"/>):</t>
      <artwork><![CDATA[

<sourcecode name="" type="abnf"><![CDATA[
  issuemail-value = *WSP [issuer-domain-name *WSP]
    [";" *WSP [parameters *WSP]]

  issuer-domain-name = label *("." label)
  label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

  parameters = (parameter *WSP ";" *WSP parameters) / parameter
  parameter = tag *WSP "=" *WSP value
  tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
  value = *(%x21-3A / %x3C-7E)
]]></artwork>
]]></sourcecode>
      <t>The production rules for "WSP", "ALPHA", and "DIGIT" are defined in
Appendix B.1 of
<xref target="RFC5234"/>. target="RFC5234" sectionFormat="of" section="B.1"/>. Readers who are familiar with the sub-syntax
of the "issue" and "issuewild" Property Tags will recognize that this
sub-syntax is identical.</t>
      <t>The meanings of each production rule within "issuemail-value" are as
follows:</t>
      <ul spacing="normal">
        <li>"issuer-domain-name": A
      <dl spacing="normal" newline="true">
        <dt>"issuer-domain-name":</dt><dd>A domain name of the CA Certification Authority comprised of one or
more labels</li>
        <li>"label": A labels</dd>
        <dt>"label":</dt><dd>A single domain label which that consists solely of ASCII letters,
digits, and the hyphen (known as an "LDH label")</li>
        <li>"parameters": A label")</dd>
        <dt>"parameters":</dt><dd>A semicolon-separated list of parameters</li>
        <li>"parameter": A parameters</dd>
        <dt>"parameter":</dt><dd>A tag and a value, separated by an equals sign ("=")</li>
        <li>"tag": A ("=")</dd>
        <dt>"tag":</dt><dd>A keyword which that identifies the type of parameter</li>
        <li>"value": The parameter</dd>
        <dt>"value":</dt><dd>The string value for a parameter</li>
      </ul> parameter</dd>
      </dl>
    </section>
    <section anchor="processing-of-the-issuemail-property-tag">
      <name>Processing of the "issuemail" Property Tag</name>
      <t>Prior to issuing a certificate that certifies an email address, the
Certification Authority <bcp14>MUST</bcp14> check for publication of a Relevant
Resource Record Set (RRSet).
RRSet. The discovery of such a Relevant RRSet <bcp14>MUST</bcp14>
be performed using the algorithm specified in section 3 of <xref target="RFC8659"/>. target="RFC8659" sectionFormat="of" section="3"/>.
The input domain to the discovery algorithm <bcp14>SHALL</bcp14> be the domain "part"
(<xref target="RFC5322"/>)
<xref target="RFC5322"/> of the email address that is being certified. If the domain
"part" of the email address being certified is an Internationalized
Domain Name (<xref target="RFC5890"/>) <xref target="RFC5890"/> that contains one or more U-Labels, then all
U-Labels <bcp14>MUST</bcp14> be converted to their A-Label representation (<xref target="RFC5891"/>) <xref target="RFC5891"/>
for the purpose of discovering the Relevant RRSet for that email
address.</t>
      <t>If the Relevant RRSet is empty, empty or the Relevant RRSet if it does not contain
any "issuemail" Properties, then the domain has not requested any
restrictions on the issuance of certificates for email addresses. The
presence of other Property Tags, such as "issue" or "issuewild", does
not restrict the issuance of certificates which that certify email addresses.</t>
      <t>For each "issuemail" Property in the Relevant RRSet, the
Certification Authority <bcp14>SHALL</bcp14> compare its issuer-domain-name with the
issuer-domain-name as expressed in the Property Value. If there is not
any "issuemail" record whose issuer-domain-name (as expressed in the
Property Value) matches the Certification Authority's
issuer-domain-name, then the Certification Authority <bcp14>MUST NOT</bcp14> issue
the certificate. If the Relevant RRSet contains any "issuemail"
Property whose issuemail-value does not conform to the ABNF syntax as
defined in <xref target="syntax"/> of this document, then those records <bcp14>SHALL</bcp14> be
treated as if the issuer-domain-name in the issuemail-value is the empty
string.</t>
      <t>If the certificate certifies more than one email address, then the
Certification Authority <bcp14>MUST</bcp14> perform the above procedure for each
email address being certified.</t>
      <t>The assignment of issuer-domain-names to Certification Authorities is
beyond the scope of this document.</t>
      <t>Parameters may be defined by a Certification Authority as a means
for domains to further restrict the issuance of certificates. For
example, a Certification Authority may define a parameter which that contains
an account identifier.  If the domain elects to add this parameter in an
issuemail
"issuemail" Property, the Certification Authority will verify that the
account that is requesting the certificate matches the account specified
in the Property and will refuse to issue the certificate if they do not
match.</t>
      <t>The processing of parameters in the issuemail-value are is specific to each
Certification Authority and are is beyond the scope of this document. In
particular, this document does not define any parameters and does not
specify any processing rules for when parameters must be acknowledged by
a Certification Authority. However, parameters that do not conform to
the ABNF syntax as defined in <xref target="syntax"/> will result in the
issuemail-value being not conformant with the ABNF syntax. As stated
above, a Property whose issuemail-value is malformed <bcp14>SHALL</bcp14> be treated as
if the issuer-domain-name in the issuemail-value is the empty string.</t>
    </section>
    <section anchor="examples-of-the-issuemail-property-tag">
      <name>Examples of the "issuemail" Property Tag</name>
      <t>Several illustrative examples of Relevant RRSets and their expected
processing semantics follow. All examples assume that the
issuer-domain-name for the Certification Authority is
"authority.example".</t>
      <section anchor="no-issuemail-property">
        <name>No issuemail "issuemail" Property</name>
        <t>The following RRSet does not contain any "issuemail" Properties,
so there are no restrictions on the issuance of certificates which that
certify email addresses for that domain:</t>
        <artwork><![CDATA[
mail.client.example         CAA 0 issue "authority.example"
mail.client.example         CAA 0 issue "other-authority.example"
]]></artwork>
      </section>
      <section anchor="single-issuemail-property">
        <name>Single issuemail "issuemail" Property</name>
        <t>The following RRSet contains a single "issuemail" Property where the
issuer-domain-name is the empty string, so the issuance of certificates
certifying email addresses for the domain is prohibited:</t>
        <artwork><![CDATA[
mail.client.example         CAA 0 issuemail ";"
]]></artwork>
      </section>
      <section anchor="single-issuemail-property-with-parameters">
        <name>Single issuemail "issuemail" Property with Parameters</name>
        <t>The following RRSet contains a single "issuemail" Property where the
issuer-domain-name is "authority.example" and contains a single
"account" parameter of "123456". In this case, the Certification
Authority <bcp14>MAY</bcp14> issue the certificate, or it <bcp14>MAY</bcp14> refuse to issue the
certificate
certificate, depending on its practices for processing the "account"
parameter:</t>
        <artwork><![CDATA[
mail.client.example
        CAA 0 issuemail "authority.example; account=123456"
]]></artwork>
      </section>
      <section anchor="multiple-issuemail-properties">
        <name>Multiple issuemail "issuemail" Properties</name>
        <t>The following RRSet contains multiple "issuemail" Properties,
where one of which Property matches the issuer-domain-name of the example Certification
Authority ("authority.example") and one Property which does not match.
Although this example is contrived, this example it demonstrates that since
there is at least one record whose issuer-domain-name matches the
Certification Authority's issuer-domain-name, issuance is permitted.</t>
        <artwork><![CDATA[
mail.client.example         CAA 0 issuemail ";"
mail.client.example         CAA 0 issuemail "authority.example"
]]></artwork>
      </section>
      <section anchor="malformed-issuemail-property">
        <name>Malformed issuemail "issuemail" Property</name>
        <t>The following RRSet contains a single "issuemail" Property whose
sub-syntax does not conform to the ABNF as specified in <xref target="syntax"/>.
Given that "issuemail" Properties with malformed syntax are treated the
same as "issuemail" Properties whose issuer-domain-name is the empty
string, issuance is prohibited.</t>
        <artwork><![CDATA[
malformed.client.example     CAA 0 issuemail "%%%%%"
]]></artwork>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations that are expressed in <xref target="RFC8659"/> are relevant
to this specification.</t>
      <t>The processing of "issuemail" Properties as specified in this document
is a supplement to the Certification Authority's validation process.
The Certification Authority <bcp14>MUST NOT</bcp14> treat solely the presence of an
"issuemail" Property with its issuer-domain-name specified within the
relevant
Relevant CAA RRSet as sufficient validation of the email address. The
Certification Authority <bcp14>MUST</bcp14> validate the email address according to the
relevant policy documents and practice statements.</t>
      <t>CAA Properties may have the "critical" flag asserted, which specifies
that the a given Property is critical and must be processed by conforming
Certification Authorities. If a Certification Authority does not
understand the Property, then it <bcp14>MUST NOT</bcp14> issue the certificate in
question.</t>
      <t>If a single CAA RRSet is processed by multiple Certification Authorities
for the issuance of multiple certificate types, then a Certification
Authority's lack of support for a critical CAA Property in the RRSet
will prevent the Certification Authority from issuing any certificates
for that domain.</t>
      <t>For example, assume that an RRSet contains the following Properties:</t>
      <artwork><![CDATA[
client.example         CAA 128 issue "other-authority.example"
client.example         CAA 0 issuemail "authority.example"
]]></artwork>
      <t>In this case, if the Certification Authority whose issuer-domain-name
matches "authority.example" does not recognize the "issue" Property Tag,
then that Certification Authority will not be able to issue S/MIME S&wj;/MIME
certificates that certify email addresses for "client.example".</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>The author requests the registration of
      <t>IANA has registered the following entry in the "Certification Authority Restriction Properties" in subregistry of the registry group "Public Key
Infrastructure using X.509 (PKIX) Parameters":</t> Parameters" registry group:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Tag</th>
            <th align="left">Meaning</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">issuemail</td>
            <td align="left">Authorization Entry by Email Address</td>
            <td align="left">[This document]</td> align="left">RFC 9495</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC5322">
          <front>
            <title>Internet Message Format</title>
            <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/>
            <date month="October" year="2008"/>
            <abstract>
              <t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5322"/>
          <seriesInfo name="DOI" value="10.17487/RFC5322"/>
        </reference>
        <reference anchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC5891">
          <front>
            <title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5891"/>
          <seriesInfo name="DOI" value="10.17487/RFC5891"/>
        </reference>
        <reference anchor="RFC8659">
          <front>
            <title>DNS Certification Authority Authorization (CAA) Resource Record</title>
            <author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Baker"/>
            <author fullname="R. Stradling" initials="R." surname="Stradling"/>
            <author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman-Andrews"/>
            <date month="November" year="2019"/>
            <abstract>
              <t>The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs.</t>
              <t>This document obsoletes RFC 6844.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8659"/>
          <seriesInfo name="DOI" value="10.17487/RFC8659"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to 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">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in 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>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5891.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8659.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>
        <name>Informative References</name>
        <reference anchor="RFC5890">
          <front>
            <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5890"/>
          <seriesInfo name="DOI" value="10.17487/RFC5890"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>

      </references>
    </references>
    <?line 316?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The author would like to thank the participants on the LAMPS Working
Group mailing list for their insightful feedback and comments. In
particular, the author extends sincere appreciation to Alexey Melnikov,
Christer Holmberg, Éric Vyncke, John Levine, Lars Eggert,
Michael Richardson, Murray Kucherawy, Paul Wouters,
Phillip Hallam-Baker, Roman Danyliw, Russ Housley, Sean Turner,
Seo Suchan, Tim Chown, and Tim Wicinski <contact fullname="Alexey Melnikov"/>,
<contact fullname="Christer Holmberg"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="John Levine"/>, <contact fullname="Lars Eggert"/>,
<contact fullname="Michael Richardson"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Paul Wouters"/>,
<contact fullname="Phillip Hallam-Baker"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Russ Housley"/>, <contact fullname="Sean Turner"/>,
<contact fullname="Seo Suchan"/>, <contact fullname="Tim Chown"/>, and <contact fullname="Tim Wicinski"/> for their official reviews and
suggestions
suggestions, which greatly improved the quality of this document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va73IbtxH/jqdAz5OJmCGpSLYTW4mT0pIcq5ZsVZTjZDye
MXgHkqjuXw53ktjE+d636LO0L9bdBXCHI+9opWlnOlN9sI93AHaxf3+7wGg0
YqUqY3nAg0NZlGquQlGqLOWTqlxmhSpX7umv5v3O4WQy4OdFFkqtVbrg86zg
x4lQMZ9EUQEvpQ6YmM0KeY2LTibdI4CMXGTF6oDrMmIsysJUJMBGVIh5OVKy
nI9ikeR6FAoxUlpXElcYff4l09UsgRfATLnKYcbJ8eUzzu9xEesMKKo0krmE
f9IyGPLgZPIU/gMOgpOLy2cBS6tkJosDFgH9AxZmqZaprvQBL4tKMmD5PhOF
FAd8KsMK98/u8ZusuFoUWZUf8Dff8TfwCzf+Hb5hV3IFn6MDxkccWKX/WoIU
tSCFL0gcSFviwgiFXcu0ApY4t6SCU5WoUkYoNYVTRMzPZLgUqdKJJqmevzj5
gYs04tOzk7NjvkMSGwSwhhFN0OIV3yNFeK9zoZM/opTHWbHAD6IIl/BhWZa5
PtjdxXH4Sl3LsRu2iy92Z0V2o+UurbCLMxeqXFYz1PXTLE1lHO+2VIZDYhC2
Lr3l3dCxmTxWWXvS7nYzGC/LBBZmRqIoeyDC+byKY2NFh1khV9wSoW/APwjO
yP6AH6mFQnsf8pM0HNMAaUQT4szxzMz8YwTjUJ3jMEsYS7MigQWuSUsXzw4f
3t/fd4/79x+4x0eP9+zjoy8ePj5gTKXz9ZmPHn8OH9hoNOJipstChCVjl0vJ
f4sXHr2ccjCdrCpCCQ/AesR3Li4GLC+yaxVJzQVPnMWQwUQZ7DLVvMy4vM3R
7HgJREUcZzdgaVqWPJuzbh4UrAd09QCmiBIMRtYWDVNhRVIPa6xfGiNFAobu
GLfOUSgg5rQ0nMBXlDmHHTGdy7AmPOQ3SwkfINbksOaKX4qFNrSB8bJQYUmz
kaxIQQLAeYv4zVKFS+uNK8sCR/vQxHwk5yqV0ZhfLpXmLdLMfEP5+dQN8UUh
0lK3vRm3D6LpkYJlxGyZeH6votFVPiKbAwqlDHGV9xyiCc+rIs807CtlNFTe
lhjOohdy9VqLhXzP6Y2m4AK+n6US41uCQnxfzMNH+/svYZPv4SV7n8EShf05
p6hAtLN0NE3K/PXls0dnwMIsu31vNqfSMK4i6SmNJMYc3xB8/wLMTuLSLFqz
MjbGnKgoiiWDoHmSlkUWVbSx/wfTfmv9/d3/lG03XEUZfEuz0tp2S36wwz6y
fJMsc2Rb+UvqMX9mZWJNWJPNoXdBeq8SyMhDLvx98MD+AEQAttxekKu5kaA3
3hctu5sT8Y85EUMnwkFr1LVzhogLNLc13+Jt32Jbfesu7nPpC4o3EQghVCsK
Gd07hW2YOQOhk70Wult/vFd/J6VmegUivqXIkjcoD41KAx4BUIDWgiQDIhK0
eQNJWdvDkKGNSviD8T6yUhvjGAPEYZYC5MHvmqgd4TwCOtrEC9QjYivNg7PX
00tEc/g/f/mKni+O//z65OL4CJ+nzyenp/UDsyOmz1+9Pj1qnpqZh6/Ozo5f
HpnJ8Ja3XrHgbPIjfEGuglfnlyevXk5OA6NEX0coFBDGDM2slAUEnZKMBVxM
h4WawQ+Y8/Tw/B9/33vAf/75D7D//b29xx8+2B+P9r58AD8gFqRDG8vjlf0J
Il4xkecSJA6rgIIBX+aqBJg7RDHrZXaTcowiIM3P3qJk3h3wr2dhvvfgG/sC
N9x66WTWekky23yzMdkIseNVB5lamq33a5Ju8zv5sfXbyd17+fW3MUau0d6j
b79haEJTY6vZ3DNIwpxto/z5njHqD31Otm024gOIaOAi0gZiP+F2zMJkYv39
QsbyGtACPNhUdkGpjE0hG+3U7jCA8ZH1UMoBXvYFdgv5UwXOjm6IX7fksLsF
cVqkLwbYVA0xp1Mg34u4knwpjMzmGYYdZAwC28gIme3YTGesf/L05TM0V5hO
/o9A+d0AsO+vv/4KWLip7K5p5Sf8szfTc/7WBLCREcIIExt9eEdQ/W3wVWDH
5aKAbyXGOvr+jrlF25OfQA0ykzH/bCcYB+Z5QIUJvnzCdyan588nfJcfnXx3
cjmAYThyFAzWvwxwfY8oTK1/GZZq3ppRA5he//Lnw/QS7NPMe2LnkSCwhIMv
v4kzzmsZ7nxyu783uo9fP7m9fzj68nhAAmfGlh0u40UVWygTAGkMhrSoi320
cuAjCkSlkxzra3XLn473XFgntQK+lyJCsdwsM5o1F5AyFESwG6jzyGQ8Q2m5
bWAo0vONiqNgDRvBu5iA4AKqOOncRGnWLEgpG+t+sPPYGnIiAeGkC8qEUkDu
W9s8MQZmGqwZotk0hHJj4hoM9jM7qGVYwQGf+PDLxaLDCWCVJC+UBpnBOxMz
sADHqEFmp3FFeqJFMM3Gtdsbw6wLB600JHqdxRLyAyw3mR6enPBYlmheQ1gW
C9VSG7Uh/eUqhyzCd65SzBKIX2CPp0fPzcLBAGk3BmoYkIkKsxjgi5b4CXNZ
DHSRXjO0NZHmoZ0iWWHMb8ib6bMVobqfKkhasMEFMARmTsRhFs22/RO7VaM+
xIO0C8JUPnmcafRzQGEZwx1EH2P3aMbCGwsJwutTfSRJMHZeqKxwYJ8wTwt6
ksXVcHUDrVLC7gnNK07JOFzK8Iq4zKtZ7AYBX6JOFGwtUXBKFBcX8N/AJKJI
6TC7lgWZga5AZsJLMziQiDEAJbA37DuAHiptkgfixAVytEx4K0o7oHZ/DaYh
RZXmVens0mK/hotmQQMaZq3aEU2lDBilOuyWQKqzemiDbVN7apiNjDopQ/1y
MveWY2a57iXWpuJqoKMTBGapMO0zrObYkeEM8bdJwdiLeWcrv7q+8HP869Ep
+SupmJAYc6+MYmdUmIA4SlMtwjBV8IkZA0HLgIfS1reW5t67AZu36yXcmJOs
U9iabs0M4JQ2z+zmIdhZQa0NByHIJC9X1AHt+O6KQrdxqIVWPZjG7t5TLqIA
nGvxCULfdMUcBiFcn6XboQhuZ6MKAaNjHt7iVGe108HQmr6uswemsCZ5DGln
zHB358K2tzBiDCtbyh+d8WMD7qFwt0cE4y2YIzDRQOzuQi0ua7KOb7B32+cw
LowMtGGa8x5c35T+69q1jRXI1lp20d/pIMLaRAY8ESVENhOwe3b7qe7YgWdQ
W8MmFg2m/7LWDaijw5pR1068tt2Gc2/DHvb0nQEDpwt2BGFdWaxZg4SgirOF
xYeOTofdHVIyctZ1iGRlIYWpFV2Xo0P6qnEen02lbfQDv2YmATb+32qW1MmK
whiEjZTi2mbeSj+evGwyMUlkBhHKdAeiqjCJF52DbY3IFpEJjUCAyq+6UeFv
mzp4/SUOIL6ZXGUW5kCszOWG7IHSeQPRE7HCCO3Uhpik1+CE6SuKVLO1nuK8
KigM3SmcUCeMyVuR5DHYeT895K3uxzVlQathrMFtuQjDrAKR1QCpGPN2cuTg
BNQNylABRiDNithBSFltSnWkGG71PwLdmIwgJrrClDlWXM5uladtC/RDg5tW
4w62HrQQRFqYP6+0rPuuG8sal8G2J0U1ojKuaxsP8HmFWo8zUV/LdmapdYxm
3GsdiHJhwscNEHAHQ6yiwioWxXCtb1QHGqd6iFMeq0im7tYa5lZmTLO5pnDD
bpE/O6kAss9Q3oj9YxktyOhZrxGO+fPsRoKWh/4ypF0jYC8ess14yLvjoVWk
ruLSJY512Zv44BHAEF4Xih6VMZ9A+VBixGQUe4b+wUx3MFfo+LHFvw00reMu
+11xl9dx9x4/Nm6uP15hTFHKIuYgmgrP/PBAkEtvejuRaVfNAZiELAzeDfv3
bAAKNoHFrrZ9GBATyLxeDwItmFvjtx07dfizz+Ah2Ab1+fXYrhzgru/xlxnf
DCfGCZu2UDfKXE/MPspkOrOYBT0tbQ4m7oQnt55PNODZyMA2oehAOYwV+q3d
Ind/2Af73EahDkncfS5h2FHHCtSVAXFOTfl/V5E2GMc1DjrNzpwy9Wi/w6AB
V2dbJexki5x0i9fvXIKxLtUMLzH8NlnTwsFXd5COiRdNtv+vSqvDAshFN5YH
rzHZLvBSMEgy2Nu//+DhFwHmB5MTQqFlRw5mHvqa/NidBqmmUyUN6MiYrXM2
cyWGsmJKxUaONw5UaLXmBRWKYI57VnPfrz/Wq78NaX3lQMATK4dav2eQJlTe
pWGICR/RaeLm9kUUquXnFlT5kKRDy661YG2zTyk7HaYwqE/jPYNCknX4s0Bl
EsPUarE0FuBIoTHAlgrICdGw/SmSCQQ/TBjugABUFVI9ZGo7eBNLga26VH60
qPMk0Id0Pu2qRodNUFDUz09UWRKs/3c8+zeN3xI3z+ok/x8PnSA/v7u8tTwU
ut1Qa5DQmH0HKk2N3nqOiyiINXDFYauiASyoLG3L/r5F+hTeUTCu6bIO07Uy
LStdGtrQzif45zRS35vD810N5UohvCNd7T6GrY+8vnbR6jY0lxfwU+F6pCT3
9Ss7nfi/R1Lrymqhc6bIMqoc9kto3aq531UAHqrIvLbkx1vvu9RdDVKu6+qX
7VNGLNe67RJtpadf1OzKHmug2Ti5keKMC6AAqjmwhsr1+e/qrJqG3NbN2BVk
R1sWI35BmcfIsWEnz2IVrmq5a3vlwOQlA/fpPWjWuwJB7Qyompfi2pALQuwM
hAJkNI/pBoKmRuzQRl8nE83qo9Wmbwcx184m6q52smo03QLr7rCF/pNXakX1
l/l1NVeleDxWulOaVhWeUjJvdbw2K9+UmWKbDJ5o2hjWKNc4dMN/nR97ua/7
0D7qq6e1DkFWed0JFn3ZEVwihurTHFDkeVaU9mimlnXrSotrniLzjMpGcINr
8rwtTjQvsqQ5qYF6ooVS15C+a+DWDRmvNBLpel5on2w3dmcx0Jaktbf/6KOA
//fmvDZytFVsbwOnJycwBwK6IG2d6Pzj1u77PkNmu4cgyK1NJFwOmxKz2EOp
0128tty+2OYds3UXcEFbgFiN4m3DyctJZ8Yx+3NNKqPcQi6Uqb+bkNcoPOgD
fRdNJepZReAM2K66Mve3eXBOh3z8hVyBzuYFwLOiCkvsl5rjuB/GDz9/zHfw
DvfAq2ACMLNf6NqK+fuFn5kzbL717xdgbw5wEL3XvoFlRu6Pe89b/jaH0TKN
Wf6ydlvzOMUdQ5RpXfCHYW9bN23ewTLmgugMIgMqbFK3pyjIs58PzM18GT0J
5iLWMvjQUuBNVsV4Hn0lTSIR6ZVJmdRlUzndybXtgdPJ2fnU3dNndPedLr6j
EOlE28Y7hX1RrRbLcl7FfC5lhNzZki4xyWezk1ezZO4UagPGsWGRQ+AKVX0h
eBLLWwkZUsapusquh+xwWQB1KAWfZzHuFWDYP/8GFsW/X6XhFXjzn7Jlyk/l
tUrhx6koND9eLPCaOjuDVCZkzC/w/yLSeIX0rCoKyIQvKvDkQtxAFjkXsI83
WWVuBZwvwfNUzp+LOBbJ6Km4wh7fBUSBlB9ByIzVDfysQF3Ps0rHEhaYgqnx
y6pIYSSbyoxPK7wjOuSXKuGHeOPMXDHAn29A7Km+Up40M8IUAht/10reUEoH
CA170AbnmZS8QNwDkEcleJvXoFuOlwTQyzab+f8CXGCpXqUyAAA=

-->
</rfc>