<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>

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

<rfc ipr="trust200902" docName="draft-birkholz-core-coid-02" category="info">

  <front>
    <title abbrev="CoID">Concise Identities</title>

    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="M." surname="Pritikin" fullname="Max Pritikin">
      <organization>Cisco</organization>
      <address>
        <email>pritikin@cisco.com</email>
      </address>
    </author>
    <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street></street>
          <city>Oak Park</city>
          <region>MI</region>
          <code>48237</code>
        </postal>
        <email>rgm@labs.htt-consult.com</email>
      </address>
    </author>

    <date year="2019" month="July" day="06"/>

    <area>Applications</area>
    <workgroup>CoRE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>There is an increased demand of trustworthy claim sets — a set of system entity characteristics tied to an entity via signatures — in order to provide information. Claim sets represented via CBOR Web Tokens (CWT) can compose a variety of evidence suitable for constrained-node networks and to support secure device automation. This document focuses on sets of identifiers and attributes that are tied to a system entity and are typically used to compose identities appropriate for Constrained RESTful Environment (CoRE) authentication needs.</t>



    </abstract>


  </front>

  <middle>


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

<t>X.509 certificates <xref target="RFC5280"/> and Secure Device Identifier <xref target="IEEE-802.1AR"/> are ASN.1 encoded Identity Documents and intended to be tied to a system entity uniquely identified via these Identity Documents. An Identity Document - in general, a public-key certificate - can be conveyed to other system entities in order to prove or authenticate the identity of the owner of the Identity Document. Trust in the proof can be established by mutual trust of the provider and assessor of the identity in a third party verification (TVP) provided, for example, by a certificate authority (CA) or its subsidiaries (sub CA).</t>

<t>The evidence a certificate comprises is typically composed of a set of claims that is signed using secret keys issued by a (sub) CA. The core set of claims included in a certificate – its attributes – are well defined in the X.509v3 specifications and IEEE 802.1AR.</t>

<t>This document summarizes the core set of attributes and provides a corresponding list of claims using concise integer labels to be used in claim sets for CBOR Web Tokens (CWT) <xref target="RFC8392"/>. A resulting Concise Identity (CoID) is able to represent a signed set of claims that composes an Identity as defined in <xref target="RFC4949"/>.</t>

<t>The objective of using CWT as a basis for the signed claim sets defined in this document is to gain more flexibility and at the same time more rigorously defined semantics for the signed claim sets.  In addition, the benefits of using CBOR, COSE, and the corresponding CWT structure accrue, including more compact encoding and a simpler implementation in contrast to classical ASN.1 (DER/BER/PEM) structures and the X.509 complexity and uncertainty that has accreted since X.509 was released 29 years ago.  One area where both the compactness and the definiteness are highly desirable is in Constrained-Node Networks <xref target="RFC7228"/>, which may also make use of the Constrained Application Protocol (CoAP, <xref target="RFC7252"/>); however, the area of application of Concise Identities is not limited to constrained-node networks.</t>

<t>The present version of this document is a strawman that attempts to indicate the direction the work is intended to take.  Not all inspirations this version takes from X.509 maybe need to be taken.</t>

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

<t>This document uses terminology from <xref target="RFC8392"/> and therefore also <xref target="RFC7519"/>, as well as from <xref target="RFC8152"/>.  Specifically, we note:</t>

<t><list style="hanging">
  <t hangText='Assertion:'>
  A statement made by an entity without accompanying evidence of its validity <xref target="X.1252"/>.</t>
  <t hangText='Claim:'>
  A piece of information asserted about a subject.  A claim is
represented as a name/value pair consisting of a Claim Name and a
Claim Value.</t>
</list></t>

<t>Claims are grouped into claims sets (represented here by a CWT), which
need to be interpreted as a whole.  Note that this usage is a bit
different from idiomatic English usage, where a claim would stand on
its own.</t>

<t>(Note that the current version of this draft is not very explicit about the relationship of identities and identifiers.  To be done in next version.)</t>

</section>
<section anchor="requirements-language" title="Requirements Language">

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

</section>
</section>
<section anchor="claims-in-a-concise-identity" title="Claims in a Concise Identity">

<t>A Concise Identity (CoID) is a CBOR Web Token <xref target="RFC8392"/> with certain claims present. It can be signed in a number of ways, including a COSE_Sign1 data object <xref target="RFC8152"/>.</t>

<section anchor="iss-cwt-issuer" title="iss: CWT issuer">

<t>Optional: identifies the principal that is the claimant for the claims in the CoID
(<xref target="RFC8392"/> Section 3.1.1, cf. Section 4.1.1 in <xref target="RFC7519"/>).</t>

<t><list style="symbols">
  <t>Note that this is a StringOrURI (if it contains a “:” it needs to be a URI)</t>
  <t>For the “string” case (no “:”), there is no way to extract meaningful components from the string</t>
  <t>Make it a URI if it needs to be structured (not for routine retrieval, unless specified so by an application)</t>
  <t>If this URI looks like an HTTP or HTTPS URI then something retrievable by humans should exist there.</t>
  <t>Alternatively, some arithmetic can be applied to the URI (extract origin, add /.well-known/…) to find relevant information.</t>
</list></t>

</section>
<section anchor="sub-cwt-subject" title="sub: CWT subject">

<t>Optional: identifies the principal that is the subject for the claims in the CoID
(<xref target="RFC8392"/> Section 3.1.2, cf. Section 4.1.2 in <xref target="RFC7519"/>).</t>

</section>
<section anchor="aud-cwt-audience" title="aud: CWT audience">

<t>Optional: identifies the recipients that the CoID is intended for
(<xref target="RFC8392"/> Section 3.1.4, cf. Section 4.1.4 in <xref target="RFC7519"/>).</t>

</section>
<section anchor="exp-cwt-expiration-time" title="exp: CWT expiration time">

<t>Optional: the time on or after which the CoID must no longer be accepted for processing
(<xref target="RFC8392"/> Section 3.1.4, cf. Section 4.1.4 in <xref target="RFC7519"/>).</t>

</section>
<section anchor="nbf-cwt-start-of-validity" title="nbf: CWT start of validity">

<t>Optional: the time before which the CoID must not be accepted for processing
(<xref target="RFC8392"/> Section 3.1.5, cf. Section 4.1.5 in <xref target="RFC7519"/>).</t>

</section>
<section anchor="iat-cwt-time-of-issue" title="iat: CWT time of issue">

<t>Optional: the creation time of the CoID
(<xref target="RFC8392"/> Section 3.1.6, cf. Section 4.1.6 in <xref target="RFC7519"/>).</t>

</section>
<section anchor="cti-cwt-id" title="cti: CWT ID">

<t>The “cti” (CWT ID) claim provides a unique identifier for the CoID
(<xref target="RFC8392"/> Section 3.1.7, cf. “jti” in Section 4.1.7 in <xref target="RFC7519"/>).</t>

<t>CWT IDs are intended to be unique within an application, so they need to be either coordinated between issuers or based on sufficient randomness (e.g., 112 bits or more).</t>

</section>
<section anchor="cnf-cwt-proof-of-possession-key-claim" title="cnf: CWT proof-of-possession key claim">

<t>The “cnf” claim identifies the key that can be used by the subject for proof-of-possession and provides parameters to identify the CWT Confirmation Method
(<xref target="I-D.ietf-ace-cwt-proof-of-possession"/> Section 3.1).</t>

</section>
</section>
<section anchor="the-essential-qualities-of-the-subject-claim" title="The Essential Qualities of the Subject Claim">

<t>As highlighted above, the base definition of the representation of the “sub claim” is already covered by <xref target="RFC8392"/> and <xref target="RFC7519"/>.</t>

<t>If claim sets need to be made about multiple subjects, the favored approach in CoID is to create multiple CoIDs, one each per subject.</t>

<!-- Or can use a structured string -->

<t>In certain cases, the subject of a CoID needs to be an X.500 Distinguished Name in its full glory.
These are sequences of relative names, where each relative name has a relative name type and a (text string) value.</t>

<figure><artwork type="CDDL"><![CDATA[
dn-subject = [*(relativenametype, relativenamevalue)]
]]></artwork></figure>

<t>(RFC 5280 does not appear to specify how many DN components must be
in a DN, so this uses a zero or more quantity.)</t>

<t>Any RelativeDistinguishedName values that are SETs of more
than one AttributeTypeAndValue are translated into a sequence of pairs
of the nametype used and each of the namevalues, lexicographically sorted.</t>

<t>To be able to map these to CBOR, we define labels for the relative name
types listed in Section 4.1.2.4 of <xref target="RFC5280"/>:</t>

<t>(Note that unusual relative name types could be represented as OIDs;
this would probably best be done by reviving the currently dormant <xref target="I-D.bormann-cbor-tags-oid"/>.)</t>

<figure><artwork type="CDDL"><![CDATA[
relativenametype = &(
  country: 1
  organization: 2
  organizational-unit: 3
  distinguished-name-qualifier: 4
  state-or-province-name: 5
  common-name: 6
  serial-number: 7
  locality: 8
  title: 9
  surname: 10
  given-name: 11
  initials: 12
  pseudonym: 13
  generation-qualifier: 14
)
]]></artwork></figure>

<t>The relative name values for these types are always expressed as CBOR text strings,
i.e., in UTF-8:</t>

<figure><artwork type="CDDL"><![CDATA[
relativenamevalue = text
]]></artwork></figure>

</section>
<section anchor="signature-envelope" title="Signature Envelope">

<t>The signature envelope [TBD: need not actually be envelope, may be detached, too] carries additional information, e.g., the signature, as well as the identification of the signature algorithm employed (COSE: alg).  Additional information may pertain to the signature (as opposed to the claims being signed), e.g., a key id (COSE: kid) may be given in the header of the signature.</t>

</section>
<section anchor="processing-rules" title="Processing Rules">

<t>(TBD: This should contain some discussion of the processing rules that apply for CoIDs.  Some of this will just be pointers to <xref target="I-D.ietf-oauth-jwt-bcp"/>.)</t>

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

<t>This document makes no requests of IANA</t>

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

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC5280" target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>



<reference  anchor="RFC5755" target='https://www.rfc-editor.org/info/rfc5755'>
<front>
<title>An Internet Attribute Certificate Profile for Authorization</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></author>
<date year='2010' month='January' />
<abstract><t>This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols.  Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements.  The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements.  The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications.  This document obsoletes RFC 3281.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5755'/>
<seriesInfo name='DOI' value='10.17487/RFC5755'/>
</reference>



<reference  anchor="RFC7519" target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>



<reference  anchor="RFC8152" target='https://www.rfc-editor.org/info/rfc8152'>
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></author>
<date year='2017' month='July' />
<abstract><t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined 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></abstract>
</front>
<seriesInfo name='RFC' value='8152'/>
<seriesInfo name='DOI' value='10.17487/RFC8152'/>
</reference>



<reference  anchor="RFC8392" target='https://www.rfc-editor.org/info/rfc8392'>
<front>
<title>CBOR Web Token (CWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='E.' surname='Wahlstroem' fullname='E. Wahlstroem'><organization /></author>
<author initials='S.' surname='Erdtman' fullname='S. Erdtman'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2018' month='May' />
<abstract><t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties.  The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection.  A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value.  CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t></abstract>
</front>
<seriesInfo name='RFC' value='8392'/>
<seriesInfo name='DOI' value='10.17487/RFC8392'/>
</reference>



<reference anchor="I-D.ietf-ace-cwt-proof-of-possession">
<front>
<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
    <organization />
</author>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<date month='February' day='21' year='2019' />

<abstract><t>This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key.  Being able to prove possession of a key is also sometimes described as being the holder-of-key.  This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-ace-cwt-proof-of-possession-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-ace-cwt-proof-of-possession-06.txt' />
</reference>



<reference anchor="I-D.ietf-oauth-jwt-bcp">
<front>
<title>JSON Web Token Best Current Practices</title>

<author initials='Y' surname='Sheffer' fullname='Yaron Sheffer'>
    <organization />
</author>

<author initials='D' surname='Hardt' fullname='Dick Hardt'>
    <organization />
</author>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<date month='June' day='7' year='2019' />

<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.  The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-oauth-jwt-bcp-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-06.txt' />
</reference>



<reference anchor="I-D.ietf-rats-eat">
<front>
<title>The Entity Attestation Token (EAT)</title>

<author initials='G' surname='Mandyam' fullname='Giridhar Mandyam'>
    <organization />
</author>

<author initials='L' surname='Lundblade' fullname='Laurence Lundblade'>
    <organization />
</author>

<author initials='M' surname='Ballesteros' fullname='Miguel Ballesteros'>
    <organization />
</author>

<author initials='J' surname='O&apos;Donoghue' fullname='Jeremy O&apos;Donoghue'>
    <organization />
</author>

<date month='July' day='4' year='2019' />

<abstract><t>An Entity Attestation Token (EAT) provides a signed (attested) set of claims that describe state and characteristics of an entity, typically a device like a phone or an IoT device.  These claims are used by a relying party to determine how much it wishes to trust the entity.  An EAT is either a CWT or JWT with some attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT.  Contributing  TBD</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-eat-01.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-eat-01.pdf' />
</reference>



<reference anchor="I-D.tschofenig-rats-psa-token">
<front>
<title>Arm's Platform Security Architecture (PSA) Attestation Token</title>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='S' surname='Frost' fullname='Simon Frost'>
    <organization />
</author>

<author initials='M' surname='Brossard' fullname='Mathias Brossard'>
    <organization />
</author>

<author initials='A' surname='Shaw' fullname='Adrian Shaw'>
    <organization />
</author>

<date month='April' day='8' year='2019' />

<abstract><t>The insecurity of IoT systems is a widely known and discussed problem.  The Arm Platform Security Architecture (PSA) is being developed to address this challenge by making it easier to build secure systems.  This document specifies token format and claims used in the attestation API of the Arm Platform Security Architecture (PSA).  At its core, the Entity Attestation Token (EAT) format is used and populated with a set of claims.  This specification describes what claims are used by the PSA and what has been implemented within Arm Trusted Firmware-M.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-tschofenig-rats-psa-token-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-tschofenig-rats-psa-token-01.txt' />
</reference>


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



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




    </references>

    <references title='Informative References'>





<reference  anchor="RFC5652" target='https://www.rfc-editor.org/info/rfc5652'>
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<date year='2009' month='September' />
<abstract><t>This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='70'/>
<seriesInfo name='RFC' value='5652'/>
<seriesInfo name='DOI' value='10.17487/RFC5652'/>
</reference>



<reference  anchor="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference  anchor="RFC7228" target='https://www.rfc-editor.org/info/rfc7228'>
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'><organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></author>
<date year='2014' month='May' />
<abstract><t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7228'/>
<seriesInfo name='DOI' value='10.17487/RFC7228'/>
</reference>



<reference  anchor="RFC4949" target='https://www.rfc-editor.org/info/rfc4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials='R.' surname='Shirey' fullname='R. Shirey'><organization /></author>
<date year='2007' month='August' />
<abstract><t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='FYI' value='36'/>
<seriesInfo name='RFC' value='4949'/>
<seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>

<reference anchor="IEEE-802.1AR" >
  <front>
    <title>ISO/IEC/IEEE International Standard for Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Part 1AR: Secure device identity</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
  <seriesInfo name="IEEE" value="standard"/>
  <seriesInfo name="DOI" value="10.1109/ieeestd.2014.6739984"/>
</reference>



<reference anchor="I-D.bormann-cbor-tags-oid">
<front>
<title>Concise Binary Object Representation (CBOR) Tags and Techniques for Object Identifiers, UUIDs, Enumerations, Binary Entities, Regular Expressions, and Sets</title>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='S' surname='Leonard' fullname='Sean Leonard'>
    <organization />
</author>

<date month='March' day='13' year='2017' />

<abstract><t>The Concise Binary Object Representation (CBOR, RFC 7049) 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.  Useful tags and techniques have emerged since the publication of RFC 7049; the present document makes use of CBOR's built-in major types to define and refine several useful constructs, without changing the wire protocol.  This document adds object identifiers (OIDs) to CBOR with CBOR tags &lt;&lt;O>> and &lt;&lt;R>> [values TBD].  It is intended as the reference document for the IANA registration of the CBOR tags so defined.  Useful techniques for enumerations and sets are presented (without new tags).  As the documentation for binary UUIDs (tag 37), MIME entities (tag 36) and regular expressions (tag 35) RFC 7049 left much out, this document provides more comprehensive specifications.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bormann-cbor-tags-oid-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bormann-cbor-tags-oid-06.txt' />
</reference>




    </references>


<section anchor="common-terminology-on-identity-documents" title="Common Terminology on Identity Documents">

<t>To illustrate the purpose and intent of Identity Documents, typically, terms, such as certificates, certificate chains/paths and trust anchors, are used. To provide more context and for the convenience of the reader, three sources of definitions are highlighted in this section.</t>

<section anchor="terms-specified-in-ieee-8021ar" title="Terms Specified in IEEE 802.1AR">

<t><list style="numbers">
  <t>a certificate is “a digitally signed object that binds information identifying an entity that possesses a secret private key to the corresponding public key.”</t>
  <t>a certificate chain is “an ordered list of intermediate certificates that links an end entity certificate ([…] a DevID certificate) to a trust anchor.”</t>
  <t>a trust anchor is “a Certificate Authority that is trusted and for which the trusting party holds information, usually in the form of a self-signed certificate issued by the trust anchor”.</t>
</list></t>

</section>
<section anchor="terms-specified-in-rfc-4949" title="Terms Specified in RFC 4949">

<t><list style="numbers">
  <t>a public-key certificate is “a digital certificate that binds a system entity’s identifier to a public key value, and possibly to additional, secondary data items; i.e., a digitally signed data structure that attests to the ownership of a public key”.</t>
  <t>a certification path is “a linked sequence of one or more public-key certificates […] that enables a certificate user to verify the signature on the last certificate in the path, and thus enables the user to obtain (from that last certificate) a certified public key, or certified attributes, of the system entity that is the subject of that last certificate”.</t>
  <t>a trust anchor is “a CA that is the subject of a trust anchor certificate or otherwise establishes a trust anchor key”. Correspondingly, a trust anchor has a trust anchor certificate that “is a public-key certificate that is used to provide the first public key in a certification path”.</t>
</list></t>

</section>
<section anchor="terms-specified-in-isoiec-9594-82017" title="Terms specified in ISO/IEC 9594-8:2017">

<t><list style="numbers">
  <t>a public-key certificate is “the public key of an entity, together with some other information, rendered unforgeable by digital signature with the private key of the certification authority (CA) that issued it”.</t>
  <t>a certification path is “an ordered list of one or more public-key certificates, starting with a public-key certificate signed by the trust anchor, and ending with the end-entity public-key certificate to be validated. All intermediate public-key certificates, if any, are certification authority (CA) certificates in which the subject of the preceding public-key certificate is the issuer of the following public-key certificate”.</t>
  <t>a trust anchor is “an entity that is trusted by a relying party and used for validating public-key certificates”.</t>
</list></t>

</section>
</section>
<section anchor="concise-identities-and-trust-relationships" title="Concise Identities and Trust Relationships">

<t>Following the terminology highlighted above, Concise Identities are signed CBOR Web Tokens that compose public-key Identity Documents based on asymmetric key pairs, potentially including additional assertions: claims that are secondary data items.</t>

<t>In the context of certification paths, the “last certificate” in the certification path is the Identity Document that resides on the system component, which presents its Identity Document to relying partyies in order to be authenticated. The “first certificate” in the certification path resides on the trust anchor.</t>

<t>In order to be able to rely on the trust put into the Identity Document presented to relying parties, these have to put trust into two assumptions first:</t>

<t><list style="symbols">
  <t>the corresponding trust anchor (certificate) is trusted. In consequence, the consumer of the Identity Document requires a basis for decision whether to rely on the trust put in the trust anchor certificate, or not (e.g. via policies or a known certification paths).</t>
  <t>the secret key included in the system component that is presenting its Identity Document is protected. In consequence, the secret key has to be stored in a shielded location. Type and quality of the protection or shielding or even its location are assertions that can be included as secondary data items in the Identity Document.</t>
</list></t>

<t>In summary, a path of trust relationships between a system component’s Identity Document and a trusted authority’s Identity Document is required to enable transitive trust in the system component that presents the Identity Document.</t>

</section>
<section anchor="concise-identity-coid-cddl-data-definition-based-on-rfc-5280" title="Concise Identity (CoID) CDDL Data Definition based on RFC 5280">

<t>COSE MUST be used to sign this CoID template flavor.</t>

<t>“signatureAlgorithm” and “signature” are not part of the CoID map but of the COSE envelope.</t>

<figure><artwork type="CDDL"><![CDATA[
CoID = { version: uint .range 1..3 ; (8)
         issuer: text, ; iss(1)
         subject: text / bytes, ; sub(2)
         notAfter: uint, ; exp(4)
         notBefore: uint ; nbf(5)
         serialNumber: uint,; (7)
         subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value,
                                 subjectPublicKey: bytes,
                               ], ;(9)
         ? extensions: [ + [ extension-id: uint / registeredID,
                             extension-value: any,
                             ? criticality: bool,
                           ]
                       ], ;(0)
       }

COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2
registeredID = [ + uint ] ; OID

extensions = 0
issuer = 1
subject = 2
notAfter = 4
notBefore = 5
serialNumber = 7
version = 8
subjectPublicKeyInfo = 9
]]></artwork></figure>

</section>
<section anchor="concise-secure-device-identifier-codeid-based-on-ieee-8021ar-2018" title="Concise Secure Device Identifier (CoDeID) based on IEEE 802.1AR-2018">

<t>This section illustrates the context and background of Secure Device Identifiers.</t>

<section anchor="the-intended-use-of-devids" title="The Intended Use of DevIDs">

<t>IEEE 802.1AR Secure Device Identifier are a specific subset of X.509 Identity Documents that are intended to “authenticate a device’s identity”, where the corresponding Identity Document is “cryptographically bound to that device”. In this context, “cryptographically bound” means that the Identity Document is “constructed using cryptographic operations to combine a secret with other arbitrary data objects such that it may be proven that the result could only be created by an entity having knowledge of the secret.”</t>

<t>While the intent of using X.509 Identity Documents as Device Identifiers starts to blur the line between authentication and authorization, the specification of IEEE 802.1AR Identity Documents provides a meaningful subset of assertions that can be used to identify one or more system components. The following CDDL data definition maps the semantics of an RFC 5280 Public Key Infrastructure Certificate Profile, which provides the basis for the Secure Device Identifier semantics. Both are mapped to a CWT representation.</t>

</section>
<section anchor="devid-flavors" title="DevID Flavors">

<t>In order to provide consistent semantics for the claims as defined below, understanding the distinction of IDevIDs (mandatory representation capabilities) and LDevIDs (recommended representation capabilities) is of the essence.</t>

<t>Both flavors of Secure Device Identifiers share most of their assertion semantics (claim sets).</t>

<t>IDevIDs are the <spanx style="emph">initially</spanx> Secure Device Identifiers that “are normally created during manufacturing or initial provisioning” and are “installed on the device by the manufacturer”. IDevIDs are intended to be globally unique and to be stored in a way that protects it from modification (typically, a shielded location). It is important to note that a potential segregation of a manufacturer into separate supply chain/tree entities is not covered by the 802.1AR specification.</t>

<t>LDevIDs are the <spanx style="emph">local significant</spanx> Secure Device Identifiers that are intended to be “unique in the local administrative domain in which the device is used”. In essence, LDevIDs “can be created at any time [after IDevID provisioning], in accordance with local policies”. An “LDevID is bound to the device in a way that makes it infeasible for it to be forged or transferred to a device with a different
IDevID without knowledge of the private key used to effect the cryptographic binding”.</t>

</section>
<section anchor="privacy" title="Privacy">

<t>The exposition iof IDevID Identity Documents enables global unique identification of a system component. To mitigate the obvious privacy LDevIDs may also be used as the sole identifier (by disabling the IDevID) to assure the privacy of the user of a DevID and the equipment in which it is installed.</t>

</section>
<section anchor="concise-devid-cddl-data-definition-sans-cose-header" title="Concise DevID CDDL data definition (sans COSE header)">

<t>COSE MUST be used to sign this DevID flavor, if represented via CoID.</t>

<t>“signature” and “signatureValue” are not part of the CoID map but of the COSE envelope.</t>

<t>“AlgorithmIdentifier” and corresponding “algorithm” and “parameters” should
be part of the COSE envelope.</t>

<figure><artwork type="CDDL"><![CDATA[
CoDeID = { version: 3, ;(8)
           serialNumber: uint,(7)
           issuer: text, ; iss(1)
           notAfter: uint, ; exp(4)
           notBefore: uint ; nbf(5)
           subject: text / URI, ; sub(2)
           subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value,
                                   subjectPublicKey: bytes,
                                 ], ;(9)
           signatureAlgorithm: COSE-Algorithm-Value ; 802.1ar-2018 states
                                                    ; this must be identical
                                                    ; to cose sig-alg (rm?)
           authorityKeyidentifier: bytes, ; all, non-critical,
           ? subjectKeyIdentifier; bytes, ; only intermediates, non-critical
           ? keyUsage : [ bitmask: bytes .size 1, 
                          ? criticality: bool,
                        ]
           ? subjectAltName: text / iPAddress / registeredID,
           ? HardwareModuleName: [ hwType: registeredID,
                                   hwSerialNum: bytes,
                                 ],
           ? extensions: [ + [ extension-id: uint,
                               extension-value: any,
                               ? criticality: bool,
                             ],
         }
                  
COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2
iPAddress = bytes .size 4 / bytes .size 16
registeredID = [ + uint ] ; OID

extensions = 0
issuer = 1
subject = 2
notAfter = 4
notBefore = 5
serialNumber = 7
version = 8
subjectPublicKeyInfo = 9
signatureAlgorithm = 10
authorityKeyidentifier = 11
subjectKeyIdentifier = 12
keyUsage = 13 ; could move to COSE header?
subjectAltName = 14
HardwareModuleName = 15
]]></artwork></figure>

</section>
</section>
<section anchor="concise-attribute-documents" title="Concise Attribute Documents">

<t>Additional well-defined sets of characteristics can be bound to Identity Documents <xref target="RFC5280"/> or Secure Device Identifiers <xref target="IEEE-802.1AR"/>.
CDDL specifications to define these can be found in the corresponding appendices above and the Profile for X.509 Internet Attribute Certificates is defined in <xref target="RFC5755"/>.</t>

<t>Essentially, various existing CWT specializations, such as the Entity Attestation Tokens <xref target="I-D.ietf-rats-eat"/> and the Platform Security Architecture Tokens <xref target="I-D.tschofenig-rats-psa-token"/> already compose a type of Attribute Certificates today.
In order to bridge the gap between these already existing Concise Attribute Documents and binding them to traditional X.509 Identity Documents (pub-key certificates), a sub claim referencing the corresponding Identity Document has to be included in the signed CBOR Web Token (flavor).
The mechanics of how to handle the corresponding key material is also defined in <xref target="RFC5755"/> (and this document will elaborate on these in future versions).</t>

<t>With respect to Concise Identity Documents the dn-subject claim should be used. If a Concise Attribute Certificate has to refer to a traditional ASN.1 encoded X.509 Identity document the subject claim should be used.
This procedure provides a migration path from ASN.1 encoded Identity documents <xref target="RFC5280"/> to CBOR encoded Concise Identity documents that allows to bind Concise Attribute Documents, such as EAT or PSA Tokens to both kinds of certificates.
In an ideal scenario CBOR encoding in the form of <xref target="RFC8392"/> is used both for Concise Identity Documents and Concise Attribute Documents. The alternate uses of subject claims or dn-subject claims addresses the fact that the vast majority of constrained node devices still use an ASN.1 encoding and simplified interoperability between CBOR encoded and ASN.1 encoded documents is still of essence today.</t>

</section>
<section anchor="attic" title="Attic">

<t>Notes and previous content that will be pruned in next versions.</t>

<section anchor="checklist" title="Examples of claims taken from IEEE 802.1AR identifiers">

<t>This appendix briefly discusses common fields in a X.509 certificate or an IEEE 802.1AR Secure Device Identifier and relates them to claims in a CoID.</t>

<t>The original purpose of X.509 was only to sign the association between a name and a public key.
In principle, if something else needs to be signed as well, CMS <xref target="RFC5652"/> is required.
This principle has not been strictly upheld over time; this is demonstrated by the growth of various extensions to X.509 certificates that might or might not be interpreted to carry various additional claims.</t>

<!-- # Alignment with PKIX uses -->

<t>This document details only the claim sets for CBOR Web Tokens that are necessary for authentication. The plausible integration or replacement of ASN.1 formats in enrollment protocols, (D)TLS handshakes and similar are not in scope of this document.</t>

<t>Subsections in this appendix are marked by the ASN.1 Object Identifier
(OID) typically used for the X.509 item.  [TODO: Make this true; there are still some section numbers.]</t>

<section anchor="version" title="7.2.1 version">

<t>The version field is typically not employed usefully in an X.509 certificate, except possibly in legacy applications that accept original (pre-v3) X.509 certificates.</t>

<t>Generally, the point of versioning is to deliberately inhibit interoperability (due to semantic meaning changes).
CoIDs do not employ versioning.  Where future work requires semantic changes, these will be expressed by making alternate kinds of claims.</t>

</section>
<section anchor="serialnumber" title="7.2.2 serialNumber">

<t>Covered by cti claim.</t>

</section>
<section anchor="signature" title="7.2.3 signature">

<t>The signature, as well as the identification of the signature algorithm, are provided by the COSE container (e.g., COSE_Sign1) used to sign the CoID’s CWT.</t>

</section>
<section anchor="issuer-name" title="7.2.4 issuer Name">

<t>Covered by iss claim.</t>

</section>
<section anchor="authoritykeyidentifier" title="7.2.5 authoritykeyidentifier">

<t>Covered by COSE kid in signature, if needed.</t>

</section>
<section anchor="notbefore" title="7.2.7.1 notBefore">

<t>Covered by nbf claim.</t>

</section>
<section anchor="notafter" title="7.2.7.2 notAfter">

<t>Covered by exp claim.</t>

<t>For Secured Device identifiers, this claim is typically left out.</t>

<t><list style="symbols">
  <t>get a new one whenver you think you need it (“normal path”)</t>
  <t>nonced ocsp? might benefit from a more lightweight freshness verification of existing signed assertion - exploration required!</t>
  <t>(first party only verfiable freshness may be cheaper than third-party verifiable?)</t>
</list></t>

</section>
<section anchor="subjectpublickeyinfo" title="7.2.10 subjectPublicKeyInfo">

<t>Covered by cnf claim.</t>

</section>
<section anchor="signaturealgorithm" title="7.2.11 signatureAlgorithm">

<t>In COSE_Sign1 envelope.</t>

</section>
<section anchor="signaturevalue" title="7.2.12 signatureValue">

<t>In COSE_Sign1 envelope.</t>

</section>
</section>
<section anchor="examples-of-claims-taken-from-x509-certificates" title="Examples of claims taken from X.509 certificates">

<t>Most claims in X.509 certificates take the form of certificate extensions.  This section reviews a few common (and maybe not so common) certificate extensions and assesses their usefulness in signed claim sets.</t>

<section anchor="authority-key-identifier" title="2.5.29.35 - Authority Key Identifier">

<t>Used in certificate chaining.  Can be mapped to COSE <spanx style="verb">kid</spanx> of the issuer.</t>

</section>
<section anchor="subject-key-identifier" title="2.5.29.14 - Subject Key Identifier">

<t>Used in certificate chaining.  Can be mapped to COSE <spanx style="verb">kid</spanx> in the “cnf” (see Section 3.4 of <xref target="I-D.ietf-ace-cwt-proof-of-possession"/>).</t>

</section>
<section anchor="key-usage" title="2.5.29.15 - Key Usage">

<t>Usage information for a key claim that is included in the signed claims.  Can be mapped to COSE <spanx style="verb">key_ops</spanx> [TBD: Explain details].</t>

</section>
<section anchor="extended-key-usage" title="2.5.29.37 - Extended key usage">

<t>Can include additional usage information such as 1.3.6.1.5.5.7.3.1 for TLS server certificates or 1.3.6.1.5.5.7.3.2 for TLS client certificates.</t>

</section>
<section anchor="authority-information-access" title="1.3.6.1.5.5.7.1.1 - Authority Information Access">

<t>More information about the signer.  May include a pointer to signers higher up in the certificate chain (1.3.6.1.5.5.7.48.2), typically in the form of a URI to their certificate.</t>

</section>
<section anchor="certificate-template-name-domain-controller-microsoft" title="1.3.6.1.4.1.311.20.2 – Certificate Template Name Domain Controller (Microsoft)">

<t>This is an example for many ill-defined extensions that are on some arcs of the OID space somewhere.</t>

<t>E.g., the UCS-2 string (ASN.1 BMPString) <spanx style="verb">IPSECIntermediateOffline</spanx></t>

</section>
</section>
</section>
<section anchor="graveyard" title="Graveyard">

<t>Items and Content that was already discarded.</t>

<section anchor="subjectaltname" title="7.2.9 subjectAltName">

<t>(See “sub”).</t>

</section>
<section anchor="extensions" title="7.2.13 extensions">

<t>Extensions are handled by adding CWT claims to the CWT.</t>

</section>
<section anchor="crl-distribution-points" title="2.5.29.31 - CRL Distribution Points">

<t>Usually URIs of places where a CRL germane to the certificate can be obtained.  Other forms of validating claim sets may be more appropriate than CRLs for the applications envisaged here.</t>

<t>(Might be replaced by a more general freshness verification approach later. For example one could define a generic “is this valid” request to an authority.)</t>

</section>
<section anchor="subject-alternative-name" title="2.5.29.17 - Subject Alternative Name">

<t>Additional names for the Subject.</t>

<t>These may be an “OtherName”, i.e. a mistery blob “defined by” an ASN.1 OID such as 1.3.6.1.4.1.9.21.2.3, or one out of a few formats such as URIs (which may, then, turn out not to be really URIs).  Naming subjects obviously is a major issue that needs attention.</t>

</section>
<section anchor="basic-constraints" title="2.5.29.19 - Basic Constraints">

<t>Can identify the key claim as that for a CA, and can limit the length of a certificate path.  Empty in all the examples analyzed.</t>

<t>Any application space can define new fields / claims as appropriate and use them. There is no need for the underlying structure to define an additional extension method for this. Instead, they can use the registry as defined in Section 9.1 of <xref target="RFC8392"/>.&gt;</t>

</section>
</section>
<section numbered="no" anchor="acknowledgements" title="Acknowledgements">

<!--  LocalWords:  accreted strawman
 -->

</section>


  </back>

<!-- ##markdown-source:
H4sIAJbSH10AA8193XYjR5LefT1FDnSOBewCaIJk/xCyVsMmqRHPdDe5TfZq
bLmPVEAlgBILVZjKKrKhPj1n3mF94ztf+EnsN5kncXwRmVlZ+GFLsn2OtasZ
oiorMzIy/iMyZjAYRNMiSfP5WNXVbPAiiqq0yvRYnRX5NDVaXSY6p0epNlE8
mZT6Hq8uz6OkmObxkgYmZTyrBpO0vFsU2S+DaVFq+o80GRwcRtO40vOiXI9V
ms+KKEpX5VhVZW2qw4ODExoQlzoeq9PVKktpbFrkJnooyrt5WdQrLPT2Qn1P
vwk+9Sc8i+70mgYkY3WZV7rMdTU4x/pRZKo4T36MsyInmNYE7Sodqx+qYtpX
piirUs8M/bVeyh/TYrmkfZn3URTX1aIox5EaEJBmrL4bqpd2M5FSSjb5nc7v
Wo+LkjD2bRnX+aKY6VLdXN7isUPR9hu9jNNsrBY00dAh648mrYYzP3SYaIw0
BKyuxurtQhNAVRkbOobnT/GKjoqA+fLZ8eHJ0y/5QVoRcs/jckn7TyoZU+cV
UP4nXS7jfE0bw2Pe2xntrcDTvNnaWVyaSufhC97cuzy91yVB+L/+R6Velprw
pW7/82UI4XVhqlk8Xaijo4Pj44MGIBneQHw+OHxx9PRkN3hKrRZ8av98fDI4
PhwNDkcvBs+OTg5HAd6m8aT4Y/VLOiTYwh29HqrrksiTSKTZ0uv4Q+sp7+cs
NdMimHFlB/xxihdDoohw3rdD9bowd8VDWgVk8LaY6LJqv+HJv6vjB52GuPky
OJ+r+E5dx+UdnpR6TmROMF4GB3r84vDo+ZcBcOV8+ccsnpjhoqqIm3JTZxWD
GEU5zqmisxlHXyj19tuzZ0fHz4l88efTwxcHY/Xh6cGJ/f386VP5PYirqkwn
dUXMSVuQ18+fjk7G6ucH+/PF6OkhYbow2v6mM6Df/PpycD5MNUmIeEozPFSD
VVkUswH9/6og+jSGN8UvilU4vgB/DWiNwWS64sXwRziijCsz0DHhjP7DvqjM
FCyRp3N5vTLxoCruNK3h/6ShfxmODglmIE5ZudW5vH03uLVvVPfg+Mnhweig
1yHhQyLIo07Q84w3vDQWHYey/3jlfh++oN/ME/Tz+OSYsGX0dDDPaM9xCdq9
vLi4GLw4OByOTt8SnV9dDkcHw9Ho4OTHVGttqmRIyx8Pnz0/Ojl5cRxFLEzX
AjH+ubl49S0B/QPNP/gL/fOeAB0MBiRIwPlTEmy3C11qlRoV50SaUxKYRicq
IULJE1XMRJySTKwWazXN4nRJIFZG/ePv/1XF+BNjzJpYfKlkcTVdxJhal6mp
0qkhzNGEVYEF7Ij7lD5N53lc1aWWudKcKD0heUYD6ezv00Qrj9EiH6qzZu1S
r+gzmovmxVRnL6/equ/1RN3i3Izqnn1/2yOWziGHiX40QXofl0QNa0CrMXk+
1crUaRVPMq1oGQUuIJSkuU4GObGNIuEPXQHEMPimXq0IDTghgpowdJ/SHER+
hQPxdkFoJMVVQ/bTpNOaKFcVuUBNK6es7GYpyT2e1TMNIWkRV4rUVYOtDazy
eLxfr0iXZdla1UZGuk2mXpWqeEU4JAlE+pE3d9ZsTr29uLmd1Zm6yO/TssgZ
1i5UYQ+bWWAO0ZWEAZ2YoRDMMk2STEckE0gzlkVSTzEkiv4yJO5X4HnaF/Sx
UR8/WlHx6RNDfSMIOxeEXXoc0MCQvDGahp3evBmOaNMQXYkzD9bq3KJVEJfS
2eeJbH+yH2d1nv611oQqj3ghGNplY3oEcw/Vab79mDW3mutcl3HWp0VW9YTs
iQHZCuHGaRhIjsAhUrrXawGpoLXKFlg4n01q1/QzxL4GiO5AmWjxu3ggENyP
LTCJ/sCqmBvvWYA6iEhSEKGnZkFATdZqWVd1nAlru/ks05VCaCxzC7+Yh4Qm
B/rSMlGruAQrE5vPHMF0b//tuudmSvpMevpDvFxluo914xa+xDLCrN2z0x4w
kNLxmnpi0iQFuxIn0y9FL4cspxrObU8EBiBhA7yagD8sX7AU86KKRZhlNxoN
KUQjagMTkDi7pFF0rpjJ1IKsmKHoERjgcKxGVNqejeRmVoMcGT0haP/4+7/z
rgJOxyMQ+oPOMpIiM2ZKe2jMTfdHyqz01KNVSB6soiyrMDpCWWPq5ZIw9gsL
kjaIwcqYxh6OAZxFSWJ0VeSwzxVRR7glwcjUWungtznRBtkMOjOW61j+EOCB
VmBZs1Maf/wItf7pE7EYyW/YG5h/wwsAJZDx32N1BMFMC3lhr2J3WjuO0p41
azE/WWxC/LJYgpIlIIScisnPegp9jdlkwwQrPovVJDap7AcItQsHO20dXHgU
KaNnTrJWLXEMs0x/SCdp5mV4JTOSwUdyi/6DR5Up+TFFbYhs3cwGKpgV6F4o
hmQgEMUlSQo66fOgCcmpWSr6xu6JDqSvzq5uLvqiy4RCgrPHrkk/kEyHoI6n
07ImhhWqxnsGESgmtS6iGU95NwQU2Jt4F/8FDIgoAF0UObyLinVURiIFfGnl
e/f84u2Tl/Tv9cXrXrO28QBavVJg1g8Od3UO3iLU0m8+9gXOagquBcJSiAb5
8CGGmZCJMXN4Qh5bDJ07LwhlV7kGA8bqgU2fCYloixPeYE6Sz4PBh5GSsuGH
NHqRzhd8SCYtmURTluaBgh28gfXwxlkPTHYw9T596tOKKbkzy5i2k5mC/rhj
NnJiNlTTgdNKzkZBnmaRgT1Or/vMTGRGfvrU+0otigdNQlgOn7cFpg8+pp/b
zjbAzouKuH6ZVs6M2GMAWW5xbMhem8y7RfkxjjJ+IMK1Bk1Fam9VMUukRGte
tSVpqdmC4F9YRhDZqPWKcEOH9YaAJGkOr2lFGBd5yOs6ODCQeKQslvbsCb0T
zcaLMw9oRE67+OILdUteYZoXWTFfb8pQNtaq5r1M6eSWowjy78EMfHz07me8
60NksDiPTfMViSOIO3XjZDnpJKIADbyThxCdko4tsR/6e0xSkVR0xQxEGyDs
Q/N4g5mcwUVRV6B1EGm+Bv95bQjLknB8H2ekOGn0x4/inrCgY7vZLrFKtR3e
WNas60vQALnANUvZmuUigX5qZU0KDya0ullEwmd9QovWRBtxKhY0TH4CjTWu
WOxvIOhYVNAc8ujf8I0DTdiKIzIsTkVY4DnL2W64rPArVDJ0imWnKDhpEFC5
EnHAMD4sisySkRaSZNqpTTwXp0dN0ipK0tmMpobRjtMjLLJNPyUbeQ6rScb3
rcCILVYeijpLFAeGyMiPWOY+gM664WokV+qy3Mk4iCw5RqSXa7KVwLZpZY8C
H5MQE6JfpKvGhRAjH4Zw41HQLm8ZCUmRAxPEAR/8osMek/9b/dc65eAJAfsq
zuc17UvYG9YsQl9GdV6/u7nt9OW/1Zsr/vvtxb++u3x7cY6/b747ffXK/xHZ
ETffXb17dd781Xx5dvX69cWbc/mYnqrWo6jz+vQ/dUQ1da6uby+v3py+6mwr
VnZ+dpxyRLJ4SiaOKOOXZ9f/87+PjokH/kBy93A0InVvf7wYPT+mH3SIuaxW
5CTJ5Seheh2R1CQ1wUYc8fI0XpF7mBnmbkNiNmf6o/OFF3TmLD8Q44YVQ7z9
qGWzYSI1MgZsrqyKc1xgqX+oLitnzVs7gNfO6+VEnIKHeG1CpR2zyv/xhgaP
VBJXsbV3AuHENEGW7pgtADZ5yyi6WoHg4mzcUJexLgLNnq7gOVjzmckbcMbs
8JbNA+NMWo7mdv0Wb6zYPxqOhqO+ms6G/tExHomlJnIVZv8/bbIuI/CGbNp8
flW+e3upuinEH1sbhDa87Yw7eMLuqyWZWNHQHs32rQWyY3iKDuGUTqmbF/iq
1xcRL0wJjOJzYiPEM9RSxzl9At+Zzc2cuYglBltnPCEt8RpaHUyMNZVAF8Li
rZ0E6wreSPyR4AS70yz6Hn5mnWcwOqwrAPumsEoh0O7Y0qWVJ1gtKwqyObL0
DjJXfXd7ew2/Cv99w+/hYdJES01fEI245WDI0NyLmg6SiR2SjewuUwlChrTM
aYaIOMe3oMgwCfEkUSxNRqLS0ibDZjU4IYUPyCGQnL15Ct5LEvVkCIU5uMuJ
r54Mh8MeviBbK2Gz7R70FIZ/mFJJMQmlWg31m0nVfvfbKfVwm1IPNymVAIzr
RACkP1Ko5kcgJPsnJX0MEvKaAhC07CACdA9Ex9sQHe+AiDSKQER/WPOJvY4Q
MKzMngh0E/n/Mzpna6l6oJaIFBBLZEUOP3DCXoJeVQIjvMopgrRE//9H4OaT
mT3hKi7ZyXNGzU6AJ2KM7Ya1+u1QPt2G8ukOKFMEkwGlYG0mknMTQoRSPb4b
C38vjT3bXvzZjsXprSxOE7Hi7tCTDnvZCgpGbJPAzZcgWGApePJ/BJjnAkzn
Z8xNQIRQPd+ESpYWQ24jMmcXh2KDumrJLsgQVryhra5TDphNCzJFUpI2iMGQ
H6JJbIl+MqDRCft1iKzWMzKtwUaqJJVeLNlR6+rhfNhXo9EhzDv+Ai6sw2Bu
iWxHjoHNIEahQ24+6zgruM3AGCmxB5F8HA6ZrLcEza5VWpGYVVySjVxha3CT
ZBWZB1CSJTFLnbH+mgR3kbhDQzKkfXC8RQ5TXRiYDSlJwH+tiYfYYrREeGOh
O5N9nhrxaulf6wbcaxtLgG60LrC3XHXjCcTh0w5idYypDivpjOg/QRSOTFDB
TMuXcgREAF/OwshKQAzsCIktvETEaJV51BqBcBbfF5idA95IFbIvLlIUngR4
UDcf4xV9CQNZY/QKsVnr7kTRf/zDYKCuSj7QmrMGgaoW9a4Gg38hgPPGSiMU
WVjcoYvzAyBaFkjO7umBOhcfqZZoLLtHNA/IlCyLTM2zolwPQXyG/XlCCnEQ
6RI+PnEH7jU7X8Z5JLyX1iuJjGw8q9Yr64qpbgXnQPbUU/fWIfvb3/6mzs7P
X0VJPnC7+Vr98E9dNw+mwSx9FT7hz3vv8Tk5P2RpK0T/yXLX4ttYuxo5FDZm
1ghaKGRn1fmb0JZiyT3REVu252+sgGB/jUXZL7osHDOrv9YxW9ZwbU5pqrcW
ohZ+Gb0MX5Biubm4ZWRimoie5kwQpy5QeksbPM0T9lLF6yDRYjKWReyfxv5M
MAt8XxNZJnAIEmkAXPPZBG8FmL5CWGtazMt4tbDxatQR6ATRFiEYGwBdxiub
sKAfEst7sFypXUDWSfTWeUcAxHBgV7yFlvlC+pegCnI145bjWue1QY5gm4IM
cuwZxPJmSOCKmOuriA9MfGPiyQltY01j+WDFNSVJUOr79B7sFPjHiKpxjQA8
lG+QpZ1IycBgSn8MqnhuBkWakMToBZS6SZlEr/+hGwV1AMjyF+WcTPdfWFyN
1eHGkzgbkJoilX5EL5KQegaYdfBXyE8ozrE6jpTEaQYEEQtwIoKBJO+f8qrL
ZZHbB88wWJckggfipY3Vc3qUFVPIYwLtReTTykiom7qUD0codZhjU3amETbB
Qpj8UfqJHayMrgmd6yX9BuCSn8J+QoBHx1FP+PJ2kzwcW1jaMe50Yw5vwZuE
0Ujna+R02WkNxIbpR+lQD+Fyqne33w5ejPcci4SIvuZvBZYv1I3L/iINqbNi
ZaMQPiustH2u/ssPty/Px6IWWJpMkbxiovKD+hxTBYHpivgNuaeqKN6TdC45
j+RC5HEWehV9JXZCFS7cCuY1ua9ZEE5tjSdczQt2g5RerrICeb8uPO8x3vQQ
Rdu5OEO8slrEekvNpF1avFhJ+sq+tM7KRHOqikMAPbeDmK2R1K98lyY9hxIm
JOfjLEgnNzlEvx5bDdfePFZva/I9SR4w5jlMan1C62WL90e8Mq2NCbDSWNiq
xBRW5pLNt7Z5aBIRiIkWziSGrEgJ2T+L6FergqM7rDXFREA9hzD9F+ry9A2H
VgwylbagayOMu+RwcI7EEcloI4kQfMdkh1Q0ojGbcyDFPYmndxzaYSYOQ8Ww
NLezxSyoCfYaMW8b117VpRQcuCQ1mwPb3/abPGWfg86oHqtJU9C5h8n0fjvR
uUCE48kqrhY2RcEZ3DifLooSgapSFM8QkUBXRWGTNzmzLj7y3i/S1Hnq9Jjo
D5AHOKLURB5FXVq7ozECgzSINRhdpM6IemkC7cbFvmVQmMGMotFwI1VKM3Ri
oqk5om5QhxLlskErJqRJmiemxUTOWpZ8lAuX82BrbrPhYDO7qzK9x1Jsuhc7
EmGS2cf7YSeKDjdBZPwLoDaBTwC6xCnT7VInXHTRKohgcLI051oSgjHxlTLB
3N0fhsPhe9g9+p5Mx+BVT0obwrMGdEfDjYcWg2fBpKc+xe7DIPjAmiYghMZ3
5jeMBE7sL4qsjeu+YosgWztZgjcut57NBi472TpSl0T3C1hYO3upBOYjsrSW
QvbUWrSIpfUmIJSNcpAvTegEM06b8xZtKHFhUE4KswVjvPDug4qITuJyLeHU
lKY2XylRgjsolwc1aVWfEDOSD/MVHS60H4ID/GyQH8gdnG/3DnriLHFjicK4
ctbxbrwZJVTGsJBynmRSCRDgj+QHI4cLO9Ybasnm6zJkdVvHYWtOCDyXY66N
XwCv3LTFhPVH14ZNwRgbk/UagGh/DUr62Fvzoqlr6Ht11ir+2RX444E71gS6
9/LT6b6pNoaHCEHpDAIZD8gBNNU3ZvMbPmrSOIEQgkbYGCXO3N7FGLwOB8b3
sIvbgCsZc7qB2ZjclyrkhI0iFkd3LZY1LcF+c/Xk8uJMnTw9OSYz8PBg9Pzz
3Cva0i8KdDr5DeNtrjkOxBkRNjakkKolj0pEmiCCazydaxfGdmKhoVuexsaF
vQawVNPe6UZRkkUci7G0+ixXbmuFX8GTfYl2QvQynHvRZuXKDnEqTKdFifnN
0u+BZYZ9dMGeJsdY4d4O1Smn2gNFthfmFAe2FpvjURS2xA9RS6NxWlzJBQZT
HajhXWTDBjnHAd1XsyLLiof9Xz3C2vmWqLDKkVPM5MKsG3XI5SfGBpItwvYv
aphZdtVdYB6p03sbZHbJlvzW74MPNzA+dwTndk1cegLZrMAKK6RCgHcUV/rA
amzWyyWyQ8KeHOTok2asJKjIVoDPNDYOTuyKGshNDeuzJJC1rT6HHEyz1ihb
qCjs2uIuG2HrbMltp3l2M+TOOkkBiOQtB1+tRrOqw8eiXKmOjW8Yjs/tmKpo
k8lmbedEt6o6E6kg7IjI/ZX72IC0ZQYy9lqr+aq5bN3+YlVXEr3ajZQmkLOx
p9SGNw1iivc8OaaqbK0pJnwocO71ciX+Ae9ujNTttoHdYsJuS+s3/DdEVRuq
Saxt03cEQms8UgDLHl/KRWRB+V5Ciopd1IeFqJRHsLOF4PCM2P5AAIKzC1xH
vCpQrqE5wUAuOHKZu4hX8thMZr7CtFUzuosCvVCyJwPs7SZCHkOMOd2LumBZ
mBIuDc2Rc9b2JIN0BmAQnLLF7C5YzNGkpgjZLpVKslA+5JKfUmkONBCMbhaJ
JXmR0EqX+P3HZqdkcHjZrnNmopeKVzaVmEvcTYVWwYzxuaN4C79f7kKlBMe9
j+QU2c6xqXEExzwjxq7EilMOslVhOfbu4/XiZd9Ot3SILyRBmE2dA13nTYLG
i28XhI8iBIQUV/K4HBXi8KQoxGnnPAWK9DK+K5Ahn0LrdrztdOrCWx2p0PEv
Ony6YIiVzdU2Gdh4pcg0988AggvVSZrBhgl59NfqoytTGquaRIoaEhLnWo2G
wyP1leq+6Pn7LFb5jzmY2KeX9Ls7Ct5bm0IGqCekytla+QovuofBQAL8FJlu
WRIj9IdV97g94iUnmC1UXyE93X0aLsbR3Tc2uMvzELjPt8G5ZqX7Z72+JEt1
rH5ogoZjxs7AY3nAaYd+M8O+fzZnHtutfu7L97TV7kkA4jcocCEzQZT2D+qf
6V//ZJAmdvdP+GoZETHR++X5Z5Zpvme3esym4uOffKOmuDHnYuOTosge/eL9
vpe8wQO/wU/CApsYJqoTUjPpL1odDIeHtMO8/SQKd4xEGOGGP3pPtHCF/HuD
OXp9EFnL9Gs1ipr02WHkSI1+HEeequjX0yikIHrwPHJFgl+rF9Eu4qEXJ8xA
oWzYe8OGZMW5hrTwgiEMwg3IU3th46c2eBfEM03LLAPvI0CKQk25GLZvUWP9
REg0VwzwTmqcObRFtm4IxH7gWXn4qxB8MUQK/6XMd4f16k3NsAqh07pXE9uL
W//4+38z/lpLxyVStw2WnXK/My3Xq6qVvJswWti8IhhkjQ5rYxazFo39vZ92
uLwsqAXaszAXaddQ9e6KRjifIgHri6T5ZtgEWUIfAGXXUDzpuJykdM5O50qY
1UgQWkyPymUQ+IZS3oAm9zdsGpCLKCe23MX6Tt6xIosRMMIyynQy93FmAQdR
zO8XaWZvO/lwuWxs7ymTwbBNdOJDi22T1RLgzrB3bwG077axphf9/kvc3J5o
Xbzh0H1IqjuACQptgvrAhlb3WD9OEftqjzBOsGkrGHEbGk+XdT8fW1CcQUrX
Rqj8xREJqviEvAgS9We4fvkMVzNcbDKMGV+XxSzNdOMB2Q3agpDgVsxezvUQ
4D44IholajlWK3dLD2Ut7SISkRkS+v6WjRDT9m1cxMoWmfOlp60LMtbjDO79
TMjmeEAtJU3DldrOwZY879Qfs4gm1cW115gs4/Vmlcs0XsV8jYfs/R6Tzyv3
Tanlvj8EzqNfpb4EB4kJMs9p24wgsbvMo2KVbG3GY+Hv7KVlQ14BNrpNMQ08
D7e12Mq3H20iOVv/+MhiElMUC69cyn06y+FJzZUwtFw9QzK2tOa/nVeOCkqM
62vdvdUOmg3QPKKG+AhkVRvOaqbTJQRnAPVGTdk8KyZyAVaKy+z93A2Xhot3
xcZmhwUuvBTrLoskuLIY5OF2+EE9rrtGSeYSl39j8flzXyYRNyERQvicDAYv
OeLWlsRVNhrFXgjl1ZwT5YTSE1zpD+6GStFMUDcF9DgR1BJQdLqvNk+XywvY
wOdhefXZU96B4o4rGrTxfp4zTpZ0xGwcwL1JiiVnw8KInj1SG2kW/WdJve/5
peOuyVp6Agj5Wsokf5DqUzn9FiW950IDXIApkxgJD9ZlApnzwzt8gbcjCwGK
QCs3wLWoQ9LFKVcb6xhpH7kxnVYWFRxZTkDf7NrNdFk6MWYntEFbf4nEcpy/
tLOl/cIgtFMEmj6e2vsiLY2OVBYYSSTkNT6dru112A+rwojwT70M26WkXCJG
OGezInQakOym6uFM8pLWmLsMdzG5T4vayCama3+q/lKb0262fMIUWav4tMsB
eoOEiBXFArdkOcmAtoTs5rc44/wRgyi7dBf04IGvxDxyhJgKwzpxI4hzprJ8
vVOBdg0MMHZWpUyi91nvWWYT6c0h8a3WBOTgttzpTS+anZHf70p3vFvTsLUs
0TZjO/GGG98UnXZsbUcESy9c/hGvHU5F228/gtcVOuo7veOWb/x5Z/7XeOm/
xk/fDgu8e3u5Kyjw/9Jh//0u+w6nXantAM1uyGiXrDvikt09KV8zvwbcrX++
EqK3VZqWqUn+/t7JCm4Gg50MCL1kRy2/aW3Rx98IV40EGTcxHeLvPh1/PnCh
gxYqv3EIxzH6z79qPmfXJcx2mfZs7clIWr/ja4MgB/KdlrG5s7DYmMGorx5B
xW8KcLzfuZHTrHrDBYGWitPr0yRBhd5j0Zlv1HdxmTyQhHldJHWmZYYf1OIB
Id7xbwnryD+LhxvH2b+Fgtsw/ZqY02en/R1hpt8eaGrD/mnH0N8fYGoO8OsW
JR27yKWjrGf/38aituUQ1jyIdjMv3nmAWnyJN4eRZzL6hdivxBiWhSSeAt38
TdTmCXxwHG1TOp4/3QqY+VrvsJovqNPku2lNIwYpItzsa2TNWG9j7jC8Pn4c
oDvWp0+wH/eb4ZuNcIYRGygbXUBoCVv1Lek4u/6M13f5w5bWh8uNW/cITyBx
7K0m6+OzpWvjLLbfXYCas1bifqOXxmBH1y++zOHvncCjQtclGIt8ldB3msC2
iPsk7hIUPgKyC0HhKddJiWFqs9i0JvkLzU18dZ3FFdeg+arO03K6SOHsAc/N
Z76lFz7211JcZyiuGqfj3bPxqkji9bCdZy1TWPOAYQ7zzEaY5FTcAs2W99Oc
RFVTH5VYsqtSxp4O98bAuqt6slV00OvL7X17m6bU7I9MfZ39ZwKbTWpwKze5
q65AdcXu7fFlFbXUxB+5jTrhfgdNRQ+SbFdUFZAv44oFjlwWMsWvoS/VlcMP
C365fFhnRODsWRfuIGiaWc2UYOUYR0O+TyWlvmJvq9hOr4XRZPIZm4swNqqy
cJcfpND2chZcAN9JQg6vfByulLM54na/q40DT5qahaZcZicgEsXn+usEew7j
kum8DOoJOAayp8tWskNy2VsnfvAWxpKN+DuilEJJuM77CPk3nH9xegsJeX1z
6mtWCmnMcseVnK2iEG2YHWOu/kWsY0r+LcmZAExOlrerVP3lM1cGx9Pb5mj7
SCB+fAMSl43txWgt15TQDy88Ka4O2KQjvpJQSnkyQxm7Gmf8ukeZyzL+Waqo
sPmgMQz3ZpHQA6LeoH6+rJaHh+r683B3HleoR2ByfsB2I3Jyq3W6+KhNHM3x
pm49NNGTqI4Tj6RbCT/pNIpwhci1mtISKuDkh0t5M7tyUqG2zB72qbDJowtp
GmbCNk9o4iLE24rJhz31Pn4xXejpHWrvPtm8llWBHyC09Sxbu0sLfI2J6/xn
CPnZTg5b3ey4sqOdNXskYSW3113ubKmaXia2TwQHA0AzchUeoSt7YcCntdC5
iB2TJtDANRQF6UzJ8fuShty3VgkL18Eb9vo7ovjpLLjvrzOj270IRLLbKy99
dfb6hjllaYRTXIWDly92XhZqcscaDQVQJ4YLXPVqoZETuoekS5faeoxsPCyF
hqsmpjkviwcp3WjsBG/DEnw7egtKzA7FcJwt4T/sVe+wKwgQH5fl2k8clKjJ
ibjrnkS3GeHAahKC5vrPl38RRuarnu3LJbhelGbugFzGYX/vMx9fzTXuxSDb
Nmt3+pNaG8S7sriW8CM3W7MSG60hNL2aSmcgmCnMnFIFy3Sl87LIMlvEJX2i
SLJ2z3u3r25YA5sFxzitOEizuPThJtzkmRar5i5O0pSe3CCHNRXT013x8Nwk
GZ3yrjlMgetKZFzDFFH3imN77a6VLmEjJ4x6n6HCRa+r86ux9M/g5aqyZhLi
rjtIjLH04XJgl6+Wm3Vm+B5y4wv1fEg86oSJsJrzYpjP2x0CgQJ/aYsAwwVc
qX/Ot4mvT9SJZgLN9QAamOk5gpTBrXZ36Nx4oOHzLlHm4P6ot4OoCdd/kuaS
fBloYS9BMV8I7KzOrAOQpROkeLmrZb5IJxy63pDs3aRmf8nlhFxqEi5MPtcw
hPgmFh13gINgNTqN7xnr1oLiBl2+vM5Pa6dz9YFOtDfXBtFrMub22o2SbDS6
Y0R3cIetkGFEMPoUCB22jA+GHzUxsI3Lg7//Dp/UM7sOlo622e+0V98QwpZL
d017nd5maFiCt18a+DsBxMeudhmeaWt/9Hxrf0+bANhd6EO3PmTQ7lJWpMH+
SepDzNvot8z3nDjDe/ytSfLJbGt1+tdHX1uD6XT94G+9W5s4fRjo476tfbA9
xALGy/SM6LuuuDBSzTUSabl+4Cw4GjJBf6yLGt/nd/wXX/8kWu92JB8pVxLQ
/gYhuykyNFOz+saqBNsEUcyFWLLqXEL9oPn9jOhzwa0iWv1LYdc4t81rRpdg
HXB7rsIKZqcY/wAIuvYOBVeKs26gaWep9Bb2S9lqCjJRYvQd4Ivn3Ep1ELZS
xUff9KJAnB3sDEq32SPfPsDRaEeMmJPqQV+oIL7vvztU7ezEo998xlTblnZR
9BoZ7MYu2qXlRQM0xntokTU2AjqehbVLsDf1A1yeGdGSNe/YY7QtAUnUmcK+
6O2ZNOh/K2ZcWlrVwIdo2Uy32nAK8ohjh4cnw6OnRCrNxbs/+0J74d13rmvq
5r1CEbtnEtRpqiWYwX8iDv/JN+NlGdJedHRMi7q+Hv8Xl7ROlLRB6Rqtg2Yj
x41bJY1IehswARGAhSN6AIOb7gW3N2dSN+1arviS5z3xB6sw9kOs1z8WK/OT
uzJ+QfyKFLW12t5vnNNzAu/ig817Sy6W4TyTTuiAILQb6y3wnfc6Gh4Nn6FX
EP3fc/qbzTMF84tkB0RZi7jp1eYHh/6Daca9bDbMA0Dd/gad0kIquwzAOp3C
1gSflW14m66CjNCSMPk6Xjd7dZevnSKDS4XLJ/SkXm3fUHD3Ybtt0I5fDA97
wf3m7eui3IissLwVzLexU7SpOBqNhocHhCAy1cOYyq2rWOYY77mUIpyh4SzZ
wlDRr9NpWZhiVvWsDS8d7m03asY3NyBJg0Bv6H04w73IXaezqS/eIYtWmVWM
DvL06sF2BbzwvQTend0MDl3DmK4Yxi9fX9/Ybis/XV7fXJxdBnmnq9kMtWo/
wY3+Uxnf63VcJiR2uQ7exiACDzpuuuvAm6WxLssN+X2ykS2Kou6NlvY8nV4z
bHQU7JegDwQg7ndz5E6q+RLfI9jJd6mncLaNZyiQ5NnbV9zhhkMlILpr0JQB
98vlYTp8RiQ7Nca31MR3c/6f7ND+anZIacLxcnsUcTd1xVWMICrj+4TJlazA
J7Mql/V/2BOfdS8t2ZSOtSx40nApuD1xHR+JnMSscN6YvSPGE9vO8PuMCt+a
CPRKPPdt0xSd7R1JcdjIfiyzkW3dSV2fW+ys49oZ2P8hBW8Z2saeTuQ+D9RA
0LDPGpxBhoP7BzWVfL4H0i1b8hZvtFCH8YzPO32+6swBRSSiaERWTFTHl9qt
O00QillkQzyCn0+Gh+g9c8SXabjmsbZXaaGynVfrvmRa6fqmycxdKNSsy5w/
hEKXOAZxgyMutNwgeNmGs72iXNEKhBFHRBFaEz0qLCUhEVzOzptqRIfTE8Lp
y9jQmfj+zCDoszhvN+tq9FhsBYjot7NTuZ4JGuZ+y1JTpfO5BD/a969h19IO
LpYr224/y6TQxdlZMR3f+hfmeLQ9Cls9i1DCOpacYFPb+NaToDoyZAV7sZED
VhyJ8O0v2eR2FMIVlHIrLLjS7jNScR6qSi9Y1JL7ldlZUoOCMKKdOJGOq77T
llQVI8FZbrZtd/YGHUQYxh3+C8ccp764SpJ4H8c2IqCTr8lT6HyyYR71CoVi
36O/7VgFLcNtt+qIgz3/G2JbuyKuagAA

-->

</rfc>

