<?xml version='1.0' encoding='utf-8'?>
<!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.25 (Ruby 3.1.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-fossati-cose-profiles-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="COSE Profiles">COSE Profiles</title>
    <seriesInfo name="Internet-Draft" value="draft-fossati-cose-profiles-00"/>
    <author fullname="Thomas Fossati">
      <organization>Arm Limited</organization>
      <address>
        <email>thomas.fossati@arm.com</email>
      </address>
    </author>
    <author fullname="Henk Birkholz">
      <organization>Fraunhofer SIT</organization>
      <address>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <date year="2023" month="March" day="13"/>
    <area>Security</area>
    <workgroup>CBOR Object Signing and Encryption</workgroup>
    <keyword>COSE</keyword>
    <keyword>profiling</keyword>
    <abstract>
      <t>COSE (STD96) is not an end-to-end system with guaranteed interoperability.
It is designed to serve a range of use cases and therefore it has a lot of options.
In general, two COSE implementations that want to interoperate require an agreement on which subset of COSE features they will use.
This document provides a set of rules for specifying such agreements as "COSE profiles" and registers a new COSE header parameter for in-band signalling of profile information.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://thomas-fossati.github.io/draft-fossati-cose-profile/draft-fossati-cose-profiles.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-fossati-cose-profiles/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        CBOR Object Signing and Encryption Working Group mailing list (<eref target="mailto:cose@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cose/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cose/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/thomas-fossati/draft-fossati-cose-profile"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>COSE <xref target="STD96"/> is not an end-to-end system with guaranteed interoperability.
 It is designed to serve a range of use cases and therefore it has a lot of options.
 In general, two COSE implementations that want to interoperate require an agreement on which subset of COSE features they will use.</t>
      <t>This document provides a set of rules for specifying such agreements as "COSE profiles" and registers a new COSE header parameter for in-band signalling of profile information.</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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="profiling-rules">
      <name>Profiling Rules</name>
      <t>A COSE profile:</t>
      <ul spacing="normal">
        <li>
          <bcp14>MUST</bcp14> be specified in a document</li>
        <li>
          <t><bcp14>MUST NOT</bcp14> change the syntax or semantics of any already defined
header attribute
          </t>
          <ul spacing="normal">
            <li>but does allow restricting their values</li>
          </ul>
        </li>
        <li>
          <t><bcp14>MAY</bcp14> define new header attributes
          </t>
          <ul spacing="normal">
            <li>if so, it <bcp14>MUST</bcp14> provide their definition in the same document</li>
          </ul>
        </li>
        <li>
          <bcp14>MUST</bcp14> use CDDL <xref target="RFC8610"/> to fully specify the syntax rules for the profile</li>
        <li>
          <t><bcp14>MUST</bcp14> use the <tt>cose-profile</tt> header attribute (see <xref target="hdr-param"/>) in the protected header
          </t>
          <ul spacing="normal">
            <li>
              <t>The value of <tt>cose-profile</tt> <bcp14>MUST</bcp14> be globally unique.  Possible choices include:
              </t>
              <ul spacing="normal">
                <li>IANA registry (<xref target="sec-profile-registry"/>)</li>
                <li>using an OID <xref target="RFC9090"/>, URI <xref target="STD66"/> or CRI <xref target="I-D.ietf-core-href"/></li>
                <li>using a UUID <xref target="RFC4122"/></li>
              </ul>
            </li>
            <li>The chosen value <bcp14>SHOULD</bcp14> be appropriate for the intended usage scope (e.g., a short value when used in constrained node environments)</li>
          </ul>
        </li>
        <li>
          <bcp14>MAY</bcp14> define its own CBOR tag that can be used together with, or in lieu of, the underlying COSE CBOR tag (Table 1, <xref section="2" sectionFormat="of" target="STD96"/>)</li>
        <li>
          <bcp14>SHOULD</bcp14> define its complementary media-type and content-format</li>
      </ul>
    </section>
    <section anchor="hdr-param">
      <name>COSE profile header parameter</name>
      <sourcecode type="cddl"><![CDATA[
COSE-profile = registered-profile / oid-profile / uri-profile
             / cri-profile / uuid-profile
registered-profile = int
oid-profile = oid ; tagged
uri-profile = ~uri ; unwrapped -- any tstr is a uri
cri-profile = cri
uuid-profile = uuid ; naked bstr is a UUID

uuid = bstr .size 16

; imported from RFC 9090
oid = #6.111(bstr)
; import from CRI spec when ready
cri = [*any]
]]></sourcecode>
    </section>
    <section anchor="profile-registration-template">
      <name>Profile Registration Template</name>
      <t><cref anchor="note">Note:</cref> This is just an initial sketch.</t>
      <t><cref anchor="issue">Tracked at:</cref> https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/10</t>
      <ul spacing="normal">
        <li>What is the profile identifier?</li>
        <li>Requires certain header keys?</li>
        <li>Constrains any header keys?</li>
        <li>Constrains any header values?</li>
        <li>Defines new header keys?</li>
        <li>Defines its own CBOR Tag?</li>
        <li>Defines its own Media Type?</li>
        <li>What payload(s) allows?</li>
      </ul>
    </section>
    <section anchor="coswid-cose-profile-definition">
      <name>CoSWID COSE Profile Definition</name>
      <t><cref anchor="note_1">Note:</cref> This is just an initial sketch.</t>
      <t><cref anchor="issue_1">Tracked at:</cref> https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/10</t>
      <t>This section defines the COSE profile for CoSWID <xref target="I-D.ietf-sacm-coswid"/>.</t>
      <t>This definition is semantically and syntactically equivalent with what is
described in <xref section="7" sectionFormat="of" target="I-D.ietf-sacm-coswid"/>, with the exception of the explicit
CoSWID COSE profile indicator that is added to the protected header.</t>
      <section anchor="cddl-definition">
        <name>CDDL Definition</name>
        <sourcecode type="cddl"><![CDATA[
protected-signed-coswid-header = {
  &(alg: 1) => int
  &(content-type: 3) => "application/swid+cbor"
  &(cose-profile-CPA: 13) => &(CoSWID-COSE-profile-CPA: 0)
  * cose-label => cose-values
}

cose-label = int / text
cose-values = any
]]></sourcecode>
      </section>
      <section anchor="checklist">
        <name>Checklist</name>
        <ul spacing="normal">
          <li>Mandatory header keys? YES</li>
          <li>Constrains header keys? NO</li>
          <li>Constrains header values? YES (alg is only int)</li>
          <li>New header keys? NO</li>
          <li>Defines its own CBOR Tag? YES</li>
          <li>Defines its own Media Type? YES</li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="new-cose-profile-header-parameter">
        <name>New COSE Profile Header Parameter</name>
        <t>This document requests IANA to allocate a new header parameter
<tt>cose-profile-CPA</tt> (suggested value 13) in the "COSE Header Parameters"
<xref target="IANA.cose"/> registry.</t>
      </section>
      <section anchor="sec-profile-registry">
        <name>COSE Profile Sub-registry</name>
        <t>This specification requests IANA to create a new sub-registry for COSE
<xref target="IANA.cose"/>, with the policy "specification required" (<xref section="4.6" sectionFormat="of" target="RFC8126"/>).</t>
        <t>Each entry in the registry must include:</t>
        <dl newline="true">
          <dt>Key value:</dt>
          <dd>
            <t>integer value for the profile</t>
          </dd>
          <dt>Brief description:</dt>
          <dd>
            <t>a brief description</t>
          </dd>
          <dt>Change Controller:</dt>
          <dd>
            <t>(see <xref section="2.3" sectionFormat="of" target="RFC8126"/>)</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>a reference document</t>
          </dd>
        </dl>
        <t>The expert is requested to assign the shortest key values (1+0 and
1+1 encoding) to registrations that are likely to enjoy wide use and
can benefit from short encodings.</t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="STD66">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
            </author>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="STD96">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need to be able to define basic security services for this data format.  This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.  </t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="I-D.ietf-core-href">
          <front>
            <title>Constrained Resource Identifiers</title>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <date day="6" month="March" year="2023"/>
            <abstract>
              <t>   The Constrained Resource Identifier (CRI) is a complement to the
   Uniform Resource Identifier (URI) that serializes the URI components
   in Concise Binary Object Representation (CBOR) instead of a sequence
   of characters.  This simplifies parsing, comparison and reference
   resolution in environments with severe limitations on processing
   power, code size, and memory size.


   // The present revision -12 of this draft adds a registry that is
   // intended to provide full coverage for representing a URI scheme
   // (and certain text strings used in their place) as negative
   // integers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-href-12"/>
        </reference>
        <reference anchor="I-D.ietf-sacm-coswid">
          <front>
            <title>Concise Software Identification Tags</title>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Jessica Fitzgerald-McKay" initials="J." surname="Fitzgerald-McKay">
              <organization>National Security Agency</organization>
            </author>
            <author fullname="Charles Schmidt" initials="C." surname="Schmidt">
              <organization>The MITRE Corporation</organization>
            </author>
            <author fullname="David Waltermire" initials="D." surname="Waltermire">
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date day="24" month="February" year="2023"/>
            <abstract>
              <t>   ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
   extensible XML-based structure to identify and describe individual
   software components, patches, and installation bundles.  SWID tag
   representations can be too large for devices with network and storage
   constraints.  This document defines a concise representation of SWID
   tags: Concise SWID (CoSWID) tags.  CoSWID supports a similar set of
   semantics and features as SWID tags, as well as new semantics that
   allow CoSWIDs to describe additional types of information, all in a
   more memory efficient format.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-coswid-24"/>
        </reference>
        <reference anchor="RFC4122">
          <front>
            <title>A Universally Unique IDentifier (UUID) URN Namespace</title>
            <author fullname="P. Leach" initials="P." surname="Leach">
              <organization/>
            </author>
            <author fullname="M. Mealling" initials="M." surname="Mealling">
              <organization/>
            </author>
            <author fullname="R. Salz" initials="R." surname="Salz">
              <organization/>
            </author>
            <date month="July" year="2005"/>
            <abstract>
              <t>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier).  A UUID is 128 bits long, and can guarantee uniqueness across space and time.  UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</t>
              <t>This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group).  Information from earlier versions of the DCE specification have been incorporated into this document.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4122"/>
          <seriesInfo name="DOI" value="10.17487/RFC4122"/>
        </reference>
        <reference anchor="RFC9090">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags for Object Identifiers</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="July" year="2021"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.</t>
              <t>This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9090"/>
          <seriesInfo name="DOI" value="10.17487/RFC9090"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <author fullname="T. Narten" initials="T." surname="Narten">
              <organization/>
            </author>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="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">
          <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"/>
        </reference>
        <reference anchor="IANA.cose" target="https://www.iana.org/assignments/cose">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="GlueCOSE" target="https://github.com/gluecose/test-vectors">
          <front>
            <title>Test Vectors</title>
            <author>
              <organization>The GlueCOSE Community</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="gluecose-test-cases">
      <name>GlueCOSE Test Cases</name>
      <t>The community effort <xref target="GlueCOSE"/> provides test vectors for the COSE specification.</t>
      <t>The CDDL definition for the test vector format used for COSE profiles will be provided in a future version of this document.</t>
      <t><cref anchor="issue_2">Tracked at:</cref> https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/4</t>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Laurence Lundblade who - unknowingly :-) - provided the introduction.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9VZ/3IbtxH+H0+xpWcykqOjRNtVbKZKIktyrKksqZLcjCeT
jsE7kER0PDAATgyjkZ+lz9In67cA7niUlEw7badtJjPiAbuLxf74dhfOskwI
r32phtQ7OLs8onNrxrpUrifkaGTVzcP1XHo1MXY5JOcLIQqTV3IG/sLKsc/G
xjnpdZYbp7J5Ysp2doSrRzPtnDaVX85Bfnx09UZU9Wyk7FAUkDkUuamcqlzt
huRtrQQOfy6kVRJKXKq8ttove2Jh7PXEmnrOqr0+u6Cz0Y8q93SpJ5WuJiSr
go6q3C7nHof1xLVagqUYCsqIr8J/o2KgFjeqqnE00T8jkijeofcddGGCb5mZ
12dSl1jn23+jlR/3jZ3wurT5FOtT7+duuL3NZLykb1S/Idvmhe2RNQuntlnA
NjNOtJ/WI7D6qZlJ19h3+9etzVwl7Ol858B17n6U2tfmN+T8xpbrT/2s7Akh
awi2bFocSjSuyzIGw1U4j95E5rCJK8pK/yLZhEPatzM60TPtVRF2VbRc1LOf
Dv1G2lk/N7OH8t+q6ppea3s9NeUvj4h/Y2VdTc1YWbo8vuqeMAVnf5Q4v3Ha
98ctbb9QQlTGziDlJkTFxZuDl7uDnSHlRVHi+/LqcHd3GORlQ0JEhp97QyZ8
/urlbiR5tSJhs3VoXu38/hk+j7PD4HdY1apsatUYlEFYu+NkPmOjL3QRpOBv
1OfF4NkzHF033692XkE/03y+HDzbHZKWleR0EkJX4+6Fvi1rxVkQFUypf4Vg
oT8j4o11Yb31KyXTskdVy0wHZjarK6RjoAjZS2NZpqt6aScK0dcEX4o2OHJ7
Agkhtjk+s5t0pFAVNFnyeZdHJ28Qt7iIn2qgjciyjOTIeStzL0Q4fSOYeJO0
o8p4ZCepqsi8yfCH3NJ5NaMFzqRJLa2svFIFafyxZq6sHCHx/bIvjj0LKJRD
koPAG3LK3iiSBJ6JIjOm2inKpVMuIICfKjgKDiPtaYrollTieNCZgAsOMiua
qAqHlFvkFybgDenZvFQzXDHEpoMc6WkBvfjMlV5ekVU/1RrycSM5sSowkalo
MdX5lICgToXzgtixkr62iuWpJe5blqxvX1xN+VomrwM3MvZGF3wDSsy2RgIT
7kFurnI9XjKAuRoHtGeC2iXcbzK+F0xg1UTDvJbFVWoRFZkqWSDP5rD1TGEz
yNZVNmIOtq4sGWr57CSN2qA0VT+6eKaRYMi+J3RceWuKOufN5PDb2wA/d3f/
osvpP+Fz+l9w+v+h158ARaobzny2D3MdqrEGqOiAW4w313xH1G6o9e795VVv
K/6l07Pw++LoT++PL44O+ffl2/2Tk/aHSBSXb8/enxyufq04D87evTs6PYzM
WKW1JdF7t/8BO6xV7+z86vjsdP+khwuQX7MzmhP250hFl84tLFHAjAK2B56P
QhTS64Pzv/118AJh/Dvg2rPB4BUiOX68HHzxAh8LVKV4mqnKZfpkFws5nyvJ
hiXYE4E51x44u8WuclOzqIgDFNZ8+j1b5och/WGUzwcvvkoLfOG1xcZma4vB
Zg9XHjBHIz6y9MgxrTXX1u9Zel3f/Q9r343dO4scNedN70YXHNNC7FM3Zoew
BYWrwysx1nV0g2z91lCwNvk0ZD6MDRxBuv5MnCNoFhCYuePwldUSxkcbWiwB
HQjR0LKk+Jfew8+158r3lPADh3DelaVZIHFQtzSQDMriAG3pRqIAOj5//0MS
FlLqvjQXxOkxObPF0BPUTVmdRBVttsS4hP7IxAd3ZDw7ODw8CSAKjEW0IWK5
k1o2UNC9/AoneDHZtCuLlz92m8GPD5SnDacUzpsWNgv4cHe32egIJo+qD49E
rnBPzvVgGTb3PeGNKyelGUlWGn3HT7XqE52jSdQj4Eo+NTqH1rrKy7pQsW15
Ssf7p/sJu+ySNm5vncobuVmzDtUSee1iq09nx4dsLHRUd3db9P7imL/Q6sFy
MMtB/M75e52T3r+PnNybhc14M6iHsSZdMOULLoTMRg2wmmtAY29GkaqAcWon
EZQuR5GgDdWf9LcYytGT+SSHIYL9ESKbOz00SByZKI+IEFXdaGuqgOqb69Gm
gfOMG2HO8XISK1OOe0OnINAbdG+AlVBQtyjAOpVa1fBOQCW4AJ4rQwmJ7WAj
a+NKskMGWzADJrYQnM/Yqal+sy7JAh110Bg2xRKOmqlCy4wHrACIuBtswnMI
lw4RIKCb7w8L0e2TVeAJ8enTp9i8M1Pjftpri5oq2sVt7qI7X/B585U64fTf
NjfrXcJ6xSceEbzHjhVd4Xt8FH3JRpsATjonYesTPrFXVwvL8F8Qt8AAIQ8n
c/8iw+CRr/Hw9NBVA0v8CTGVvIaIUcvLUSoCLWjCct/pX+C0XSG+5L4FQQaG
sTUznieI5wvWHdRPdvuDwWCDmTZb2kjJacFwEgMzgCVrCKbvn0L3H9gPK/RW
dBHzLzQDmD8QAMgDIb7/C9o79QOFdgb//1i70O0FpJMluWvl82mfCbVzNSgf
GTLC/ATRLltM0hS7WsLEpUHCzG57sMPV4jvOAO26iEfAWRQAlA77NSguYo+G
UFXWI8+aoEOD4nj/oElAFxz1D+3GUsD7oe+B8E4haFibrbWsvZKTx/beceLQ
FRLn6+ZSc7ksjSw23GasSJAZ+q7L74BU3XedTu/1X3FCOMolxCjSxdgfa6nO
MJmUjyPBgoG27X47BdG1JTzUjNCTcoHLmxV2KDzATVyYGxYxBtYbtxWIfdGA
2CJWhcDD+qmfcxUmASaIC/NS59qLrpVXHXCB831A+xhzsijiIPJYceQu+Ums
3l3/tJDW0mdxoEkKZimI9ugWuPXZhiwxvw82ae+rgEO81KBqfMd6HvZ6AJuS
1cMh2yzn83xkbC/Rr2pydnC+D3mR6bONeM+sC6+RYmczlMDAWsqRKpk+fKUu
COjc3WTlAKZe/exFhwwbyJqEH7DGVOXXJbAj9HlwLJtzPeXow9Hletqt7Z6e
PbqZ8pGZiU3G3gndONTiunV6LzujnF9N0KTEbyRpoEA6Nk+bQSfgTgRFHoHO
Ds/a3TAac0dznwo2OW2Gsiab30Y9z5uaeH8+5JkTvamLEhF9jA78sJsmvPs1
VXy8HwAf0eTVqF2OozW2JBwRqcuLU+R9LVxPYOrhI/tpnG+6sBTo3Stc1qO2
SUNJf7R3a3Ajdvkxch/eLUc1am/mumIDnvCT8LpanfSeG2TEknoPj0A5KHrc
VTYQ8aK/CwwQWfP0hm4H1zqSGLFhcrtsbNOePmNYbXtWcTu8cXOZqzvxR4y9
waRDMQwt4aQJzweNuXhttRpTRK2AQ8wjaXR/WYiDOOggfLw1ZcnP7sOmU297
tf7zAHSdOwhxocboZqpcRdG2+VyNGmFYB/ChOHLWJA9EXJOOsSmOGNy/8lPj
dXNBRxuDz3cYnsXg8wHslJsCXeUmM9pOh5DeT3jcLvW1QlKCQFU/Gn4DKULf
GoTENrZCzqW2JLbMjVyXHptGMr/mfGrfM8MD6AG/+sS75M37JqnxmCXc3ja0
iNr2dSVcJj1itq4JAtfipR+FBhzvFKmGoSOFYpcb+/AmOtvXmPjeM1KNAmmq
Hdf8JAQJ1rV1qJPs/7Y6/YJNtp9fV2ZRqmIShgtEbfw3HFXs9cILcA9ZeSLr
GCEnmBRGJVAA9dVQhpaWueEJeHCYbcZ/iYlXSeNP+/TXUXtIVxYe45cVP2y6
kyGdGv5Ho78DBTzh1cMaAAA=

-->

</rfc>
