draft-ietf-cose-hpke.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.0.2) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="pre5378Trust200902" docName="draft-ietf-cose-hpke-08" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="COSE HPKE">Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)</title>

    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization></organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>
    <author initials="O." surname="Steele" fullname="Orie Steele" role="editor">
      <organization>Transmute</organization>
      <address>
        <postal>
          <country>United States</country>
        </postal>
        <email>orie@transmute.industries</email>
      </address>
    </author>
    <author initials="D." surname="Ajitomi" fullname="Daisuke Ajitomi">
      <organization>bibital</organization>
      <address>
        <postal>
          <country>Japan</country>
        </postal>
        <email>dajiaji@gmail.com</email>
      </address>
    </author>
    <author initials="L." surname="Lundblade" fullname="Laurence Lundblade">
      <organization>Security Theory LLC</organization>
      <address>
        <postal>
          <country>United States</country>
        </postal>
        <email>lgl@securitytheory.com</email>
      </address>
    </author>

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

    <area>Security</area>
    <workgroup>COSE</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 60?>

<t>This specification defines hybrid public-key encryption (HPKE) for use with 
CBOR Object Signing and Encryption (COSE). HPKE offers a variant of
public-key encryption of arbitrary-sized plaintexts for a recipient public key.</t>

<t>HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM),
key derivation function (KDF), and authenticated encryption with
additional data (AEAD) function. Authentication for HPKE in COSE is
provided by COSE-native security mechanisms or by one of the authenticated
variants of HPKE.</t>

<t>This document defines the use of the HPKE with COSE.</t>



    </abstract>



  </front>

  <middle>


<?line 74?>

<section anchor="introduction"><name>Introduction</name>

<t>Hybrid public-key encryption (HPKE) <xref target="RFC9180"/> is a scheme that 
provides public key encryption of arbitrary-sized plaintexts given a 
recipient's public key.</t>

<t>This document defines the use of the HPKE with COSE (<xref target="RFC9052"/>, <xref target="RFC9053"/>).</t>

</section>
<section anchor="conventions-and-terminology"><name>Conventions and Terminology</name>

<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>

<t>This specification uses the following abbreviations and terms:</t>

<t><list style="symbols">
  <t>Content-encryption key (CEK), a term defined in CMS <xref target="RFC2630"/>.</t>
  <t>Hybrid Public Key Encryption (HPKE) is defined in <xref target="RFC9180"/>.</t>
  <t>pkR is the public key of the recipient, as defined in <xref target="RFC9180"/>.</t>
  <t>skR is the private key of the recipient, as defined in <xref target="RFC9180"/>.</t>
  <t>Key Encapsulation Mechanism (KEM), see <xref target="RFC9180"/>.</t>
  <t>Key Derivation Function (KDF), see <xref target="RFC9180"/>.</t>
  <t>Authenticated Encryption with Associated Data (AEAD), see <xref target="RFC9180"/>.</t>
  <t>Additional Authenticated Data (AAD), see <xref target="RFC9180"/>.</t>
</list></t>

</section>
<section anchor="hpke-for-cose"><name>HPKE for COSE</name>

<section anchor="overview"><name>Overview</name>

<t>This specification supports two modes of HPKE in COSE, namely</t>

<t><list style="symbols">
  <t>HPKE Direct Encryption mode, where HPKE is used to encrypt the plaintext. This mode can only be used with a single recipient. <xref target="one-layer"/> provides the details.</t>
  <t>HPKE Key Encryption mode, where HPKE is used to encrypt a content encryption key (CEK) and the CEK is subsequently used to encrypt the plaintext. This mode supports multiple recipients. <xref target="two-layer"/> 
  provides the details.</t>
</list></t>

<t>In both cases a new COSE header parameter, called 'ek',
is used to convey the content of the enc structure defined in the HPKE
specification. "Enc" represents the serialized public key.</t>

<t>For use with HPKE the 'ek' header parameter MUST
be present in the unprotected header parameter and MUST contain
the encapsulated key, which is output of the HPKE KEM, and it
is a bstr.</t>

<section anchor="one-layer"><name>HPKE Direct Encryption Mode</name>

<t>With the HPKE Direct Encryption mode the information carried inside the 
COSE_recipient structure is embedded inside the COSE_Encrypt0.</t>

<t>HPKE is used to directly encrypt the plaintext and the resulting ciphertext
is either included in the COSE_Encrypt0 or is detached. If a payload is
transported separately then it is called "detached content". A nil CBOR
object is placed in the location of the ciphertext. See Section 5
of <xref target="RFC9052"/> for a description of detached payloads.</t>

<t>The sender MUST set the alg parameter in the protected header, which
indicates the use of HPKE.</t>

<t>The sender MUST place the 'ek' (encapsulated key) parameter into the unprotected
header. Although the use of the 'kid' parameter in COSE_Encrypt0 is
discouraged by RFC 9052, this documents RECOMMENDS the use of the 'kid' parameter
(or other parameters) to explicitly identify the static recipient public key
used by the sender. If the COSE_Encrypt0 contains the 'kid' then the recipient may
use it to select the appropriate private key.</t>

<t>The HPKE specification describes an API and this API uses an "aad" parameter
as input. When COSE_Encrypt0 is used then there is no AEAD function executed
by COSE natively and HPKE offers this functionality.</t>

<t>The "aad" parameter provided to the HPKE API is constructed
as follows (and the design has been re-used from <xref target="RFC9052"/>):</t>

<figure><artwork><![CDATA[
Enc_structure = [
    context : "Encrypt0",
    protected : empty_or_serialized_map,
    external_aad : bstr
]

empty_or_serialized_map = bstr .cbor header_map / bstr .size 0
]]></artwork></figure>

<t>The protected field in the Enc_structure contains the protected attributes
from the COSE_Encrypt0 structure at layer 0, encoded in a bstr type.</t>

<t><xref target="cddl-hpke-one-layer"/> shows the COSE_Encrypt0 CDDL structure.</t>

<figure title="CDDL used for the HPKE Direct Encryption Mode" anchor="cddl-hpke-one-layer"><artwork><![CDATA[
COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

; Layer 0
COSE_Encrypt0 = [
    Headers,
    ciphertext : bstr / nil,
]
]]></artwork></figure>

<t>The COSE_Encrypt0 MAY be tagged or untagged.</t>

<t>An example is shown in <xref target="one-layer-example"/>.</t>

</section>
<section anchor="two-layer"><name>HPKE Key Encryption Mode</name>

<t>With the HPKE Key Encryption mode information is conveyed in the COSE_recipient 
structure, i.e. one COSE_recipient structure per recipient.</t>

<t>In this approach the following layers are involved:</t>

<t><list style="symbols">
  <t>Layer 0 (corresponding to the COSE_Encrypt structure) contains the content (plaintext)
encrypted with the CEK. This ciphertext may be detached, and if not detached, then
it is included in the COSE_Encrypt structure.</t>
  <t>Layer 1 (corresponding to a recipient structure) contains parameters needed for 
HPKE to generate a shared secret used to encrypt the CEK. This layer conveys the 
encrypted CEK in the encCEK structure. The protected header MUST contain the HPKE 
alg parameter and the unprotected header MUST contain the 'ek' parameter.
The unprotected header MAY contain the kid parameter to identify the static recipient
public key the sender has been using with HPKE.</t>
</list></t>

<t>This two-layer structure is used to encrypt content that can also be shared with
multiple parties at the expense of a single additional encryption operation.
As stated above, the specification uses a CEK to encrypt the content at layer 0.</t>

<section anchor="recipient-encryption"><name>Recipient Encryption</name>

<t>This describes the Recipient_structure.
It serves instead of COSE_KDF_Context for COSE-HPKE recipients (and possibly other COSE algorithms defined outside this document).
It MUST be used for COSE-HPKE recipients as it provides the protection for recipient protected headers.
It is patterned after the Enc_structure in <xref target="RFC9052"/>, but is specifically for a COSE_recipient, never a COSE_Encrypt.
The COSE_KDF_Context MUST NOT be used in COSE-HPKE.</t>

<figure><artwork><![CDATA[
Recipient_structure = [ 
    context: "Recipient",
    next_layer_alg: int/tstr,
    recipient_protected_header: empty_or_serialize_map,
    recipient_aad: bstr
]
]]></artwork></figure>

<t><list style="symbols">
  <t>"next_layer_alg" is the algorithm ID of the COSE layer for which the COSE_recipient is encrypting a key.
It is the algorithm that the key MUST be used with.
This value MUST match the alg parameter in the next lower COSE layer.
(This serves the same purpose as the alg ID in the COSE_KDF_Context.
It also mitigates attacks where a person-in-the-middle changes the following layer algorithm from an AEAD algorithm to one that is not foiling the protection of the following layer headers).</t>
  <t>"recipient_protected_header" contains the protected headers from the COSE_recipient CBOR-encoded deterministically with the "Core Deterministic Encoding Requirements", specified in Section 4.2.1 of RFC 8949 <xref target="STD94"/>.</t>
  <t>"recipient_aad" contains any additional context the application wishes to protect.
If none, it is a zero-length string.
This is distinct from the external_aad for the whole COSE encrypt.
It is per-recipient.
Since it is not a header, it may be secret data that is not transmitted.
It provides a means to convey many of the fields in COSE_KDF_Context.</t>
</list></t>

</section>
<section anchor="cose-hpke-recipient-construction"><name>COSE-HPKE Recipient Construction</name>

<t>This is the procedure for creating a COSE_recipient for COSE-HPKE.</t>

<t>When a COSE_recipeint is constructed for a COSE-HPKE recipient, this is given as the "aad" parameter to the HPKE Seal() API.
The "info" parameter to HPKE_Seal is not used with COSE_HPKE.</t>

<t>The creation of the COSE_recipient is as follows:</t>

<t><list style="numbers">
  <t>Prepare a Recipient_structure</t>
  <t>Obtain the key To used use by the next lowest layer</t>
  <t>Pass in the following parameters to HPKE Seal API
  <list style="numbers">
      <t>Public key of recipient for "pKR"</t>
      <t>Empty string for "info"</t>
      <t>CBOR-encoded Recipient_structure for "aad"</t>
      <t>The key for next lowest COSE layer for "pt"</t>
    </list></t>
  <t>The following are returned from the HPKE Seal API
  <list style="numbers">
      <t>The "enc" is placed in the "ek" header of the COSE_recipient</t>
      <t>The "ct" is placed in the "ciphertext" field of the COSE_recipient</t>
    </list></t>
</list></t>

<t>The decoding and decryption of a COSE_recipient is as follows:</t>

<t><list style="numbers">
  <t>Prepare a Recipient_structure</t>
  <t>Pass in the following parameters to HPKE Open API
  <list style="numbers">
      <t>The "ek" header  for "enc"</t>
      <t>Secret key for recipient for "sKR"</t>
      <t>Empty string for "info"</t>
      <t>CBOR-encoded Recipient_structure for "aad"</t>
      <t>The cipher text from the COSE_recipient as "ct"</t>
    </list></t>
  <t>What is returned from HPKE Open API is the key for the next lowest COSE layer</t>
</list></t>

<t>It is not necessary to fill in recipient_aad as HPKE itself covers the attacks that recipient_aad (and COSE_KDF_Context (and SP800-56A)) are used to mitigate.
COSE-HPKE use cases may use it for any purpose they wish, but it should generally be for small identifiers, context or secrets, not to protect bulk external data.
Bulk external data should be protected at layer 0 with external_aad.</t>

<t>The COSE_recipient structure, shown in <xref target="cddl-hpke"/>, is repeated for each
recipient.</t>

<figure title="CDDL used for the HPKE Key Encryption Mode" anchor="cddl-hpke"><artwork><![CDATA[
COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)
 
/ Layer 0 /
COSE_Encrypt = [
  Headers,
  ciphertext : bstr / nil,
  recipients : + COSE_recipient
]

/ Layer 1 /
COSE_recipient = [
  protected   : bstr .cbor header_map,
  unprotected : header_map,
  encCEK      : bstr,
]

header_map = {
  Generic_Headers,
  * label => values,
}
]]></artwork></figure>

<t>The COSE_Encrypt MAY be tagged or untagged.</t>

<t>When encrypting the content at layer 0 then the instructions in
Section 5.3 of <xref target="RFC9052"/> MUST to be followed, which includes the
calculation of the authenticated data strcture.</t>

<t>An example is shown in <xref target="two-layer-example"/>.</t>

</section>
</section>
</section>
<section anchor="key-representation"><name>Key Representation</name>

<t>The COSE_Key with the existing key types can be used to represent KEM private
or public keys. When using a COSE_Key for COSE-HPKE, the following checks are made:</t>

<t><list style="symbols">
  <t>The "kty" field MUST be present, and it MUST be one of the key types for HPKE KEM.</t>
  <t>If the "kty" field is "OKP" or "EC2", the "crv" field MUST be present
and it MUST be a curve for HPKE KEM.</t>
  <t>If the "alg" field is present, it MUST be one of the supported COSE-HPKE "alg" values
and the key type of its KEM MUST match the "kty" field.
If the "kty" field is "OKP" or "EC2", the curve of the KEM MUST match the "crv" field.
The valid combinations of the "alg", "kty" and "crv" are shown in <xref target="ciphersuite-kty-crv"/>.</t>
  <t>If the "key_ops" field is present, it MUST include only "derive bits" for the private key
and MUST be empty for the public key.</t>
</list></t>

<t>Examples of the COSE_Key for COSE-HPKE are shown in <xref target="key-representation-example"/>.</t>

</section>
</section>
<section anchor="ciphersuite-registration"><name>Ciphersuite Registration</name>

<t>A ciphersuite is a group of algorithms, often sharing component algorithms
such as hash functions, targeting a security level.
An HPKE ciphersuite, is composed of the following choices:</t>

<t><list style="symbols">
  <t>HPKE Mode</t>
  <t>KEM Algorithm</t>
  <t>KDF Algorithm</t>
  <t>AEAD Algorithm</t>
</list></t>

<t>The "KEM", "KDF", and "AEAD" values are chosen from the HPKE IANA
registry <xref target="HPKE-IANA"/>.</t>

<t>For readability the algorithm ciphersuites labels are built according
to the following scheme:</t>

<figure><artwork><![CDATA[
HPKE-<Version>-<Mode>-<KEM>-<KDF>-<AEAD>
]]></artwork></figure>

<t>The "Mode" indicator may be populated with the following values from
Table 1 of <xref target="RFC9180"/>:</t>

<t><list style="symbols">
  <t>"Base" refers to "mode_base" described in Section 5.1.1 of <xref target="RFC9180"/>,
which only enables encryption to the holder of a given KEM private key.</t>
  <t>"PSK" refers to "mode_psk", described in Section 5.1.2 of <xref target="RFC9180"/>,
which authenticates using a pre-shared key.</t>
  <t>"Auth" refers to "mode_auth", described in Section 5.1.3 of <xref target="RFC9180"/>,
which authenticates using an asymmetric key.</t>
  <t>"Auth_Psk" refers to "mode_auth_psk", described in Section 5.1.4 of <xref target="RFC9180"/>,
which authenticates using both a PSK and an asymmetric key.</t>
</list></t>

<t>For a list of ciphersuite registrations, please see <xref target="IANA"/>. The following
table summarizes the relationship between the ciphersuites registered in this
document, which all use the "Base" mode and the values registered in the
HPKE IANA registry <xref target="HPKE-IANA"/>.</t>

<figure><artwork><![CDATA[
+--------------------------------------------------+------------------+
| COSE-HPKE                                        |      HPKE        |
| Cipher Suite Label                               | KEM | KDF | AEAD |
+--------------------------------------------------+-----+-----+------+
| HPKE-Base-P256-SHA256-A128GCM                    |0x10 | 0x1 | 0x1  |
| HPKE-Base-P384-SHA384-AS256GCM                   |0x11 | 0x2 | 0x2  |
| HPKE-Base-P521-SHA512-AS256GCM                   |0x12 | 0x3 | 0x2  |
| HPKE-Base-X25519-SHA256-A128GCM                  |0x20 | 0x1 | 0x1  |
| HPKE-Base-X25519-SHA256-ChaCha20Poly1305         |0x20 | 0x1 | 0x3  |
| HPKE-Base-X448-SHA512-AS256GCM                   |0x21 | 0x3 | 0x2  |
| HPKE-Base-X448-SHA512-ChaCha20Poly1305           |0x21 | 0x3 | 0x3  |
+--------------------------------------------------+-----+-----+------+
]]></artwork></figure>

<t>As the list indicates, the ciphersuite labels have been abbreviated at least
to some extend to maintain the tradeoff between readability and length.</t>

<t>The ciphersuite list above is a minimal starting point. Additional
ciphersuites can be registered into the already existing registry.
For example, once post-quantum cryptographic algorithms have been standardized
it might be beneficial to register ciphersuites for use with COSE-HPKE.
Additionally, ciphersuites utilizing the compact encoding of the public keys,
as defined in <xref target="I-D.irtf-cfrg-dnhpke"/>, may be standardized for use in
constrained environments.</t>

<t>As a guideline for ciphersuite submissions to the IANA CoSE algorithm
registry, the designated experts must only register combinations of 
(KEM, KDF, AEAD) triple that consitute valid combinations for use with
HPKE, the KDF used should (if possible) match one internally used by the
KEM, and components should not be mixed between global and national standards.</t>

<section anchor="cosekeys-for-cose-hpke-ciphersuites"><name>COSE_Keys for COSE-HPKE Ciphersuites</name>

<t>The COSE-HPKE ciphersuite uniquely determines the type of KEM for which a COSE_Key is used.
The following mapping table shows the valid combinations
of the COSE-HPKE ciphersuite, COSE_Key type and its curve.</t>

<figure title="COSE_Key Types and Curves for COSE-HPKE Ciphersuites" anchor="ciphersuite-kty-crv"><artwork><![CDATA[
+---------------------+--------------+
| COSE-HPKE           | COSE_Key     |
| Ciphersuite Label   | kty | crv    |
+---------------------+-----+--------+
| HPKE-Base-P256-\*   | EC2 | P-256  |
| HPKE-Base-P384-\*   | EC2 | P-384  |
| HPKE-Base-P521-\*   | EC2 | P-521  |
| HPKE-Base-X25519-\* | OKP | X25519 |
| HPKE-Base-X448-\*   | OKP | X448   |
| HPKE-Base-CP256-\*  | EC2 | P-256  |
| HPKE-Base-CP384-\*  | EC2 | P-384  |
| HPKE-Base-CP521-\*  | EC2 | P-521  |
+---------------------+-----+--------+
]]></artwork></figure>

</section>
</section>
<section anchor="examples"><name>Examples</name>

<t>This section provides a set of examples that shows all COSE message types
(COSE_Encrypt0, COSE_Encrypt and COSE_MAC) to which the COSE-HPKE can be
applied, and also provides some examples of key representation for HPKE KEM.</t>

<t>Each example of the COSE message includes the following information
that can be used to check the interoperability of COSE-HPKE implementations:</t>

<t><list style="symbols">
  <t>plaintext: Original data of the encrypted payload.</t>
  <t>external_aad: Externally supplied AAD.</t>
  <t>skR: A recipient private key.</t>
  <t>skE: An ephemeral sender private key paired with the encapsulated key.</t>
</list></t>

<section anchor="one-layer-example"><name>HPKE Direct Encryption Mode</name>

<t>This example assumes that a sender wants to communicate an
encrypted payload to a single recipient in the most efficient way.</t>

<t>An example of the HPKE Direct Encryption Mode is
shown in <xref target="hpke-example-one"/>. Line breaks and comments have been inserted
for better readability.</t>

<t>This example uses the following:</t>

<t><list style="symbols">
  <t>alg: HPKE-Base-P256-SHA256-A128GCM</t>
  <t>plaintext: "This is the content."</t>
  <t>external_aad: "COSE-HPKE app"</t>
  <t>skR: h'57c92077664146e876760c9520d054aa93c3afb04e306705db6090308507b4d3'</t>
  <t>skE: h'42dd125eefc409c3b57366e721a40043fb5a58e346d51c133128a77237160218'</t>
</list></t>

<figure title="COSE_Encrypt0 Example for HPKE" anchor="hpke-example-one"><artwork><![CDATA[
16([
    / alg = HPKE-Base-P256-SHA256-A128GCM (Assumed: 35) /
    h'a1011823',
    {
        / kid /
        4: h'3031',
        / ek /
        -4: h'045df24272faf43849530db6be01f42708b3c3a9
              df8e268513f0a996ed09ba7840894a3fb946cb28
              23f609c59463093d8815a7400233b75ca8ecb177
              54d241973e',
    },
    / encrypted plaintext /
    h'35aa3d98739289b83751125abe44e3b977e4b9abbf2c8cfaade
      b15f7681eef76df88f096',
])
]]></artwork></figure>

</section>
<section anchor="two-layer-example"><name>HPKE Key Encryption Mode</name>

<t>In this example we assume that a sender wants to transmit a
payload to two recipients using the HPKE Key Encryption mode.
Note that it is possible to send two single-layer payloads, 
although it will be less efficient.</t>

<section anchor="coseencrypt"><name>COSE_Encrypt</name>

<t>An example of the COSE_Encrypt structure using the HPKE scheme is
shown in <xref target="hpke-example-cose-encrypt"/>. Line breaks and comments have been
inserted for better readability.</t>

<t>This example uses the following:</t>

<t>TODO: recompute this for Recipient_structure</t>

<t><list style="symbols">
  <t>Encryption alg: AES-128-GCM</t>
  <t>plaintext: "This is the content."</t>
  <t>detatched ciphertext: h'cc168c4e148c52a83010a75250935a47ccb8682deebcef8fce5d60c161e849f53a2dc664'</t>
  <t>kid:"01"
  <list style="symbols">
      <t>alg: HPKE-Base-P256-SHA256-A128GCM</t>
      <t>external_aad: "COSE-HPKE app"</t>
      <t>skR: h'57c92077664146e876760c9520d054aa93c3afb04e306705db6090308507b4d3'</t>
      <t>skE: h'97ad883f949f4cdcb1301b9446950efd4eb519e16c4a3d78304eec832692f9f6'</t>
    </list></t>
  <t>kid:"02"
  <list style="symbols">
      <t>alg: HPKE-Base-X25519-SHA256-CHACHA20POLY1305</t>
      <t>external_aad: "COSE-HPKE app"</t>
      <t>skR: h'bec275a17e4d362d0819dc0695d89a73be6bf94b66ab726ae0b1afe3c43f41ce'</t>
      <t>skE: h'b8ed3f4df56c230e36fa6620a47f24d08856d242ea547c5521ff7bd69af8fd6f'</t>
    </list></t>
</list></t>

<figure title="COSE_Encrypt Example for HPKE" anchor="hpke-example-cose-encrypt"><artwork><![CDATA[
96_0([
    / alg = AES-128-GCM (1) /
    h'a10101',
    {
        / iv /
        5: h'b3fb95dde18c6f90a9f0ae55',
    },
    / detached ciphertext /
    null,
    [
        [
            / alg = HPKE-Base-P256-SHA256-A128GCM (Assumed: 35) /
            h'a1011823',
            {
                / kid /
                4: h'3031',
                / ek /
                -4: h'04d97b79486fe2e7b98fb1bd43
                      c4faee316ff38d28609a1cf568
                      40a809298a91e601f1cc0c2ba4
                      6cb67b41f4651b769cafd9df78
                      e58aa7f5771291bd4f0f420ba6',
            },
            / ciphertext containing encrypted CEK /
            h'24450f54ae93375351467d17aa7a795cfede2
              c03eced1ad21fcb7e7c2fe64397',
        ],
        [
            / alg = HPKE-Base-X25519-SHA256-CHACHA20POLY1305 (Assumed: 42) /
            h'a101182a',
            {
                / kid /
                4: h'3032',
                / ek /
                -4: h'd1afbdc95b0e735676f6bca34f
                      be50f2822259ac09bfc3c500f1
                      4a05de9b2833',
            },
            / ciphertext containing encrypted CEK /
            h'079b443ec6dfcda6a5f8748aff3875146a8ed
              40359e1279b545166385d8d9b59',
        ],
    ],
])
]]></artwork></figure>

<t>To offer authentication of the sender the payload in <xref target="hpke-example-cose-encrypt"/>
is signed with a COSE_Sign1 wrapper, which is outlined in <xref target="hpke-example-sign"/>.
The payload in <xref target="hpke-example-sign"/> is meant to contain the content of
<xref target="hpke-example-cose-encrypt"/>.</t>

<figure title="COSE_Encrypt Example for HPKE" anchor="hpke-example-sign"><artwork><![CDATA[
18(
  [
    / protected / h'a10126' / {
            \ alg \ 1:-7 \ ECDSA 256 \
          } / ,
    / unprotected / {
          / kid / 4:'sender@example.com'
        },
    / payload /     h'AA19...B80C',
    / signature /   h'E3B8...25B8'
  ]
)
]]></artwork></figure>

</section>
<section anchor="cosemac"><name>COSE_MAC</name>

<t>An example of the COSE_MAC structure using the HPKE scheme is
shown in <xref target="hpke-example-cose-mac"/>.</t>

<t>This example uses the following:</t>

<t><list style="symbols">
  <t>MAC alg: HMAC 256/256</t>
  <t>payload: "This is the content."</t>
  <t>kid:"01"
  <list style="symbols">
      <t>alg: HPKE-Base-P256-SHA256-A128GCM</t>
      <t>external_aad: "COSE-HPKE app"</t>
      <t>skR: h'57c92077664146e876760c9520d054aa93c3afb04e306705db6090308507b4d3'</t>
      <t>skE: h'e5dd9472b5807636c95be0ba2575020ba91cbb3561b52be141da89678c664307'</t>
    </list></t>
  <t>kid:"02"
  <list style="symbols">
      <t>alg: HPKE-Base-X25519-SHA256-CHACHA20POLY1305</t>
      <t>external_aad: "COSE-HPKE app"</t>
      <t>skR: h'bec275a17e4d362d0819dc0695d89a73be6bf94b66ab726ae0b1afe3c43f41ce'</t>
      <t>skE: h'78a49d7af71b5244498e943f361aa0250184afc48b8098a68ae97ccd2cd7e56f'</t>
    </list></t>
</list></t>

<figure title="COSE_MAC Example for HPKE" anchor="hpke-example-cose-mac"><artwork><![CDATA[
97_0([
    / alg = HMAC 256/256 (5) /
    h'a10105',
    {},
    / payload = 'This is the content.' /
    h'546869732069732074686520636f6e74656e742e',
    / tag /
    h'5cdcf6055fcbdb53b4001d8fb88b2a46b200ed28e1ed77e16ddf43fb3cac3a98',
    [
        [
            / alg = HPKE-Base-P256-SHA256-A128GCM (Assumed: 35) /
            h'a1011823',
            {
                / kid = '01' /
                4: h'3031',
                / ek /
                -4: h'043ac21632e45e1fbd733f002a
                      621aa4f3d94737adc395d5a7cb
                      6e9554bd1ad273aec991493786
                      d72616d9759bf8526e6e20c1ed
                      c41ba5739f2b2e441781aa0eb4',
            },
            / ciphertext containing encrypted MAC key /
            h'5cee2b4235a7ff695164f7a8d1e79ccf3ca3d
              e8b22f3592626020a95b2a8d3fb4d7aa7fe37
              432426ee70073a368f29d1',
        ],
        [
            / alg = HPKE-Base-X25519-SHA256-CHACHA20POLY1305 (Assumed: 42) /
            h'a101182a',
            {
                / kid = '02' /
                4: h'3032',
                / ek /
                -4: h'02cffacc60def3bb3d0a1c3661
                      227c9de8dc2b1d3939dd2c07d4
                      49ebb0bba324',
            },
            / ciphertext containing encrypted MAC key /
            h'3f5b8b60271d5234dbea554dc1461d0239e9f
              4589f6415e8563b061dbcb37795a616111b78
              2b4c589b534309327ffadc',
        ],
    ],
])
]]></artwork></figure>

</section>
</section>
<section anchor="key-representation-example"><name>Key Representation</name>

<t>Examples of private and public KEM key representation are shown below.</t>

<section anchor="kem-public-key-for-hpke-base-p256-sha256-a128gcm"><name>KEM Public Key for HPKE-Base-P256-SHA256-A128GCM</name>

<figure title="Key Representation Example for HPKE-Base-P256-SHA256-A128GCM" anchor="hpke-example-key-1"><artwork><![CDATA[
{
    / kty = 'EC2' /
    1: 2,
    / kid = '01' /
    2: h'3031',
    / alg = HPKE-Base-P256-SHA256-A128GCM (Assumed: 35) /
    3: 35,
    / crv = 'P-256' /
    -1: 1,
    / x /
    -2: h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d',
    / y /
    -3: h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c'
}
]]></artwork></figure>

</section>
<section anchor="kem-private-key-for-hpke-base-p256-sha256-a128gcm"><name>KEM Private Key for HPKE-Base-P256-SHA256-A128GCM</name>

<figure title="Key Representation Example for HPKE-Base-P256-SHA256-A128GCM" anchor="hpke-example-key-2"><artwork><![CDATA[
{
    / kty = 'EC2' /
    1: 2,
    / kid = '01' /
    2: h'3031',
    / alg = HPKE-Base-P256-SHA256-A128GCM (Assumed: 35) /
    3: 35,
    / key_ops = ['derive_bits'] /
    4: [8],
    / crv = 'P-256' /
    -1: 1,
    / x /
    -2: h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a09eff',
    / y /
    -3: h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbfc117e',
    / d /
    -4: h'57c92077664146e876760c9520d054aa93c3afb04e306705db6090308507b4d3',
}
]]></artwork></figure>

</section>
<section anchor="kem-public-key-for-hpke-base-x25519-sha256-chacha20poly1305"><name>KEM Public Key for HPKE-Base-X25519-SHA256-CHACHA20POLY1305</name>

<figure title="Key Representation Example for HPKE-Base-X25519-SHA256-CHACHA20POLY1305" anchor="hpke-example-key-3"><artwork><![CDATA[
{
    / kty = 'OKP' /
    1: 1,
    / kid = '11' /
    2: h'3131',
    / alg = HPKE-Base-X25519-SHA256-CHACHA20POLY1305 (Assumed: 42) /
    3: 42,
    / crv = 'X25519' /
    -1: 4,
    / x /
    -2: h'cb7c09ab7b973c77a808ee05b9bbd373b55c06eaa9bd4ad2bd4e9931b1c34c22',
}
]]></artwork></figure>

</section>
</section>
</section>
<section anchor="sec-cons"><name>Security Considerations</name>

<t>This specification is based on HPKE and the security considerations of
<xref target="RFC9180"/> are therefore applicable also to this specification.</t>

<t>HPKE assumes the sender is in possession of the public key of the recipient and
HPKE COSE makes the same assumptions. Hence, some form of public key distribution
mechanism is assumed to exist but outside the scope of this document.</t>

<t>HPKE relies on a source of randomness to be available on the device. Additionally, 
with the two layer structure the CEK is randomly generated and it MUST be
ensured that the guidelines in <xref target="RFC8937"/> for random number generations are followed.</t>

<t>HPKE in Base mode does not offer authentication as part of the HPKE KEM. In this
case COSE constructs like COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0 can be
used to add authentication. HPKE also offers modes that offer authentication.</t>

<t>If COSE_Encrypt or COSE_Encrypt0 is used with a detached ciphertext then the
subsequently applied integrity protection via COSE_Sign, COSE_Sign1, COSE_MAC, 
or COSE_MAC0 does not cover this detached ciphertext. Implementers MUST ensure
that the detached ciphertext also experiences integrity protection. This is, for
example, the case when an AEAD cipher is used to produce the detached ciphertext
but may not be guaranteed by non-AEAD ciphers.</t>

</section>
<section anchor="IANA"><name>IANA Considerations</name>

<t>This document requests IANA to add new values to the 'COSE Algorithms' and to 
the 'COSE Header Parameters' registries.</t>

<section anchor="cose-algorithms-registry"><name>COSE Algorithms Registry</name>

<t><list style="symbols">
  <t>Name: HPKE-Base-P256-SHA256-A128GCM</t>
  <t>Value: TBD1 (Assumed: 35)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(P-256, HKDF-SHA256) KEM, the HKDF-SHA256 KDF and the AES-128-GCM AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
  <t>Name: HPKE-Base-P384-SHA384-AS256GCM</t>
  <t>Value: TBD3 (Assumed: 37)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(P-384, HKDF-SHA384) KEM, the HKDF-SHA384 KDF, and the AES-256-GCM AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
  <t>Name: HPKE-Base-P521-SHA512-AS256GCM</t>
  <t>Value: TBD5 (Assumed: 39)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(P-521, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and the AES-256-GCM AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
  <t>Name: HPKE-Base-X25519-SHA256-A128GCM</t>
  <t>Value: TBD7 (Assumed: 41)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and the AES-128-GCM AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
  <t>Name: HPKE-Base-X25519-SHA256-ChaCha20Poly1305</t>
  <t>Value: TBD8 (Assumed: 42)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
  <t>Name: HPKE-Base-X448-SHA512-AS256GCM</t>
  <t>Value: TBD9 (Assumed: 43)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(X448, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and the AES-256-GCM AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
  <t>Name: HPKE-Base-X448-SHA512-ChaCha20Poly1305</t>
  <t>Value: TBD10 (Assumed: 44)</t>
  <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the DHKEM(X448, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and the ChaCha20Poly1305 AEAD.</t>
  <t>Capabilities: [kty]</t>
  <t>Change Controller: IESG</t>
  <t>Reference:  [[TBD: This RFC]]</t>
  <t>Recommended: Yes</t>
</list></t>

</section>
<section anchor="cose-header-parameters"><name>COSE Header Parameters</name>

<t><list style="symbols">
  <t>Name: ek</t>
  <t>Label: TBDX (Assumed: -4)</t>
  <t>Value type: bstr</t>
  <t>Value Registry: N/A</t>
  <t>Description: HPKE encapsulated key</t>
  <t>Reference: [[This specification]]</t>
</list></t>

</section>
</section>


  </middle>

  <back>


    <references title='Normative References' anchor="sec-normative-references">



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

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

<reference anchor="RFC9180">
  <front>
    <title>Hybrid Public Key Encryption</title>
    <author fullname="R. Barnes" initials="R." surname="Barnes"/>
    <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
    <author fullname="B. Lipp" initials="B." surname="Lipp"/>
    <author fullname="C. Wood" initials="C." surname="Wood"/>
    <date month="February" year="2022"/>
    <abstract>
      <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
      <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9180"/>
  <seriesInfo name="DOI" value="10.17487/RFC9180"/>
</reference>

<reference anchor="RFC9052">
  <front>
    <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
    <author fullname="J. Schaad" initials="J." surname="Schaad"/>
    <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="RFC9053">
  <front>
    <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
    <author fullname="J. Schaad" initials="J." surname="Schaad"/>
    <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 a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t>
      <t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9053"/>
  <seriesInfo name="DOI" value="10.17487/RFC9053"/>
</reference>

<referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94">
  <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949">
    <front>
      <title>Concise Binary Object Representation (CBOR)</title>
      <author fullname="C. Bormann" initials="C." surname="Bormann"/>
      <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
      <date month="December" year="2020"/>
      <abstract>
        <t>The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
        <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
      </abstract>
    </front>
    <seriesInfo name="STD" value="94"/>
    <seriesInfo name="RFC" value="8949"/>
    <seriesInfo name="DOI" value="10.17487/RFC8949"/>
  </reference>
</referencegroup>




    </references>

    <references title='Informative References' anchor="sec-informative-references">



<reference anchor="RFC8937">
  <front>
    <title>Randomness Improvements for Security Protocols</title>
    <author fullname="C. Cremers" initials="C." surname="Cremers"/>
    <author fullname="L. Garratt" initials="L." surname="Garratt"/>
    <author fullname="S. Smyshlyaev" initials="S." surname="Smyshlyaev"/>
    <author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
    <author fullname="C. Wood" initials="C." surname="Wood"/>
    <date month="October" year="2020"/>
    <abstract>
      <t>Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.</t>
      <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8937"/>
  <seriesInfo name="DOI" value="10.17487/RFC8937"/>
</reference>

<reference anchor="RFC2630">
  <front>
    <title>Cryptographic Message Syntax</title>
    <author fullname="R. Housley" initials="R." surname="Housley"/>
    <date month="June" year="1999"/>
    <abstract>
      <t>This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2630"/>
  <seriesInfo name="DOI" value="10.17487/RFC2630"/>
</reference>


<reference anchor="I-D.irtf-cfrg-dnhpke">
   <front>
      <title>Deterministic Nonce-less Hybrid Public Key Encryption</title>
      <author fullname="Dan Harkins" initials="D." surname="Harkins">
         <organization>Hewlett-Packard Enterprise</organization>
      </author>
      <date day="5" month="February" year="2024"/>
      <abstract>
	 <t>   This document describes enhancements to the Hybrid Public Key
   Encryption standard published by CFRG.  These include use of &quot;compact
   representation&quot; of relevant public keys, support for key-wrapping,
   and two ways to address the use of HPKE on lossy networks: a
   determinstic, nonce-less AEAD scheme, and use of a rolling sequence
   number with existing AEAD schemes.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-dnhpke-04"/>
   
</reference>


<reference anchor="HPKE-IANA" target="https://www.iana.org/assignments/hpke/hpke.xhtml">
  <front>
    <title>Hybrid Public Key Encryption (HPKE) IANA Registry</title>
    <author >
      <organization>IANA</organization>
    </author>
    <date year="2023" month="October"/>
  </front>
</reference>


    </references>


<?line 802?>

<section anchor="contributors"><name>Contributors</name>

<t>We would like thank the following individuals for their contributions
to the design of embedding the HPKE output into the COSE structure 
following a long and lively mailing list discussion:</t>

<t><list style="symbols">
  <t>Richard Barnes</t>
  <t>Ilari Liusvaara</t>
</list></t>

<t>Finally, we would like to thank Russ Housley and Brendan Moran for their
contributions to the draft as co-authors of initial versions.</t>

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

<t>We would like to thank John Mattsson, Mike Prorock, Michael Richardson,
and Goeran Selander for their review feedback.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA9Vde3PcyHH/H59ialUVkvbuCu8Hk3OZIqmTIunIiLw4rrOK
NQAGJEwssAawpHg6+bPks+STpXsewACLpaizUjmz7qhdYF7d09P9656e4WKx
MNq8Ldgh+bFhpMrIq4e4zlNyvomLPFm8YQ/ktEzqh3WbVyXZf3X+5vSA3Oft
DTl+cfaenMV/ZUlLLvLrMi+vCS3TQfHjs4vTA4PGcc3uDgl+I9iCkVZJSVfQ
aVrTrF3krM0WSdWwxc36li3M0Ehoy66r+uGQNG1qGPm6PiTrmnlOEF7Wm6a1
TTMybYPWjB6SC5Zs6rx9MO6r+va6rjZr0Zdxyx7gUXpIXpctq0vWLk6wP8No
WhjpFS2qEsbwwBpjnR+Sn9oqmZOmqtuaZQ18eljhhw+GQTftTVUfGguDkLxs
DsmrJblskpsqY2V+DQ8FMa9oWbJm+IataF4ckhv+atl2r/54vfq4hBFBkaTa
lC2S+j2rV7R86Ls5W5KLlrGCdV2c1Tnrn9UVThxL87aq4WtVX9My/5ki7w/J
ZU3LZrVpWT+KCmr/sVXPl3mZAivhWaOP4scyb1kKncAUNP1YTpbk6K/Q0Srv
BnNC82Zzy7TnwxHEeZy3tOj7T+lfc/gPaIevy6Ra6f3+O13Tsu/v7ZK83ZRp
XNC0J/8t3dSsTNjg1bBTJQzk8oaBAJG3b4/7ARTXxR8bWaDl78ejGFJvlBVM
SZvfsUMo9P7lsW1ZkfwYWoErP0ZWaKqPpmf3Hx38eHF5EvGSRl5mo/bCyAlU
077DG3m9OFnmNS6IrL5epCUuCXyOC2fx+uiHI/wCP0ooifwBNoCgw3vxRK7q
wXIm08sZK5H37DoHYXiQtWl9zVqQ27ZdN4fPn9/f3y9zWtIl9PKcNg2s9xUr
2+Y5jo7/Wn68aVeFqJ0C80BWk7aKWU1s03aQ+sViQWgMfdAEluDlTd6QZs2S
PMsTPnckZVmOC+hGjHktVBAsYsK2xgyMJBvQWFwVGU/WRUvORtBzGasbQskd
rYGsFh4Y092BRqQ1iHFN64dFk/8MsrEuaA765GPb8FFQUgMR6xzYIYdMoI2l
YfCeUCXJcuUDiNkqzkvatVwSClpmxWAR8lrYM103m0IUWbEEFEferMj+m9N3
B3NUaMClOr8T77NNmQji3py8PJhzklEsYCjIUxirRglyyqApKAv4RgucJEr2
j06PTg66hmCN99V5DzBwTkdeCvWdg66sq7s8hcbjB/5sUXKJJmph9cNuQCix
FKhZJBdaHg7PkOxvuOGBbpZSLsA+bFC+OpHAqpuma0WwllshGADUQtla5WkK
atF4RlDf11W64TTBRDxBnj59kuv482egESYVNDVbMeiNtkSR3GgT/HQhuQbm
wEQTo5OTvWYoKb+CZrIvRgzq5vPnOVFfnM+fD5bIguOqvEM+V2XDxeISbEte
VkV1/YD9MU4CGseGzN79eHE5m4t/yQ9n/PP70//48fX70xP8fPHq6O3b7oMq
cfHq7Me38N6Qn/qax2fv3p3+cCIqw1MyevTu6M8zIayzs/PL12c/HL2doYC1
wAajYwPYdtJWJGYEGVmD9UeBpsAo1iR1HsMXqPPi+PxfyrhZ/6vlCiaghoY5
5J9RRX/+bNyDxIn+qrIAqvlXYOkDoes1ozW2Q4uCwNJDewWmH3ppbqr7ktyw
mi0nlRXMjJiirCqK6p5rHI5zctpzHca9ag5BPHE+WqBqoUkNzsD+8ekbXLi8
pJx5TtfxuwtJD5iFz5+X0MRTVDnKUd+IJtTYwPr2PRbAQWtyLMWrE8654PGu
RhqtEa6I2K9pRY5e03XvRroO1AmbqnXSq7+XI/U3UeNooA1Ph9qQHDVNleT8
1UmvDacb6hXnsE1ZcboeLES+bFGNckRqPHtGzu5YfZez+0mxajbrNSBQYPB9
RVYV6hypG5UKnnMsBHJsgFH9ncAF5CSv0fZpBGLdOcp6LVUHdAUym+KakkIo
JlEpKoC0OBysByuhFGslZqISZxcoRRDzQpvlJZALyn1R0AdWw6rr9CS2nLIW
QFezRNvfj3Qkt08ZJgW7yVcPmVo9YqFBf/AFazebuGF/20BxGP+TKe74vtoU
bb7WiWyQSpiOjkqgZppQ43VJ4go4lVDUDpSU7F5o6xsGWLUma1rD3MFan0OR
ooCx7bHbvbmhEZ2g4n7g7Sqq5doCGsAbqsGqAQjW15ayDsZAlJZkBnyeAR2g
OhukgxdsYP3QQtgo3Qa91AEVnwksjcPbGjxBQ2HEqAB4w2oMmxLY0oIcQttb
dXCWuIFBqmACDEmSVAFQBcaBkpAnNziN1aZdb9qB8QO9INR43hrcRiOYxEX2
7NmuVfAO5/bTs15GDeNPSGDX5vTC4e87tA4PE1qDn4TcbnL52sCJveqxXz81
MDa2AvuUDivw8rIjU+FDbeZTPpTiYVpYOzEHnqOIgr2BnmHd4EtkBwO6GNqy
pNikvWAMekU8xk1ESwHepEvyGpALTNJDUdEUsR13DnEhQAMNw9lrUdWgwgOu
Y10ptzPVhpLSGWBHUuYFjwsYlcDiUB4ISPrRFFXSoV8u4h0J4OqC9gTvjb/2
DCigIRyJtIXp70BXNwZJQbMU2AaEMpViCp8FI2lxrUmjHM5YXqX8gaOWcvU+
AGEdQB12wAnsF8v+WKYPBt3CPI+WiiG6BvYV4NBtrm/GwG/vNk/3hmMfTiqi
prwBF7am1wKWA98IMm7OMVUHLZseiV18oRdjHxhecYnqnjUHXJV+XIPWyFFQ
QbLBDmZCWzXgMoM2mXKGDC7isSzHecdFb1s+pXJotCFx2RtgC7KivEmUSBhQ
wwqUNT7Ja2ArwBJEJRo6kbPGF9zY5RRYEuEaOTp/LVcZ8Ay/cIwHL2aUpjON
NwBt8hK005L8CQc3ng25ouW4hUIoK4LgonfZ2Edwl3D6pRdFhBcFXMUh6F4q
H46qB6q7VfSMhkU6x0wKGW8E6cBlC5CUKyjokTYStDZkX2kVYAT4zeQG3sUM
Bl6zBaciq6uVvhAPAM3+/e9/N4Dcq17jfUd+4p4/1wWgqw657eH8AAcB3/Qr
7RCU47p9uKrqq94WXa3oWhSE6qwGMq+AOCiLKt74YBg76kDPWIIskxjkVawk
/vy5fI7eGDH5kDnP+nFkOSs6vTQkZyCFfQ3agp8ebzAwxNmyLb59E+A1coND
zDnq80pqZGGzSPuwRrfi06cEXFYR9NRhFPoezUTzxycnb/s+lmImBkWuLuk1
6oDvyDN/afn7g5cHhvGv5K0Y1bBaN4GvOAcbMRW9cpYTAVwFDT+H+cCOPx2S
ZxPjF5Gn72Z8sEKGYGoeMbhoo2efxfQMRwWOIiLQVtCEAKUUn4H0I1xCdIVI
LVfeGvczuoEs5HsBxBVGGOFPCRB6eDcGCBN4dYAMxNoCyDYyub22MroZm5N8
yZY8HLITPKyBgz2+5pCSKwCu2sDajXxOPuiGO8t5eVcVdyw9JOhwynkm+0lV
A2RYV2DSoLxUDTqf+84PhpKv8Od+B0IODIlNlEsgcbdE0prAgIrGqVMWWuK2
DPRgqz1EHWkIXPEYbhnIvCLNmiBNj8VNUdWbMoDmLJWyKZAYVL9mJUPEg57O
DbAUMVBSA4CYciN6soXYCykQnNPYxL2SUgF4/NYTQ4YaSWJmHSX3cmgMAYzS
2xOYe6s+xyVd1SVfaFP1YLXp1W4xZtZ1CNQ/au4NLaTQm/neoGzQd+y9CxVU
6RbeED+PGa5EkYfj0DulRcNjQ3KeeHCzc91g1G2OplvMFCAWVgqk07mwWiBU
D+Stcf7ReTKOGk4iqv24umNzQdR2CIjyGR7JhhpubwWECnpG3nfy2SsVFQDs
sAg20RW80oT/dYv+2x3D5dK0MG1IE18pb05eXh1L66uiDQsuOL0fK6z9umqa
PAacIdAdxx4gW1UNLFz1MRvwv6TnogHIAz4ELmAqMrCzMwRJ7dBRliKnAssa
VBzJYsP7Qe8BbC7u3MEsZFwKt2x1F1uSkVCwz0SPqhRAqXAehip3DhrgjnXP
5Wwseyukc1RFRjuqJQZfSFFGczgxYWhW/+e/dWQEwKgrJ5FRCY+vuJRcwTQc
oo/wvIUmxNtuvFcdj64Ej6ZwVA+j+nqAozoYxWHQgsyGfc5UQK8TA/L6RPkF
XD6EECMbhX8+YeXQA5USjaFQAbvFJA6b5ku4lRHogSjhIl6KtXBHiw0Tb8HO
yh4nXTgkBdzKeyXKfKhLY1/E1sRi4UsXqoFLUoP4M5RN1SBQqlscbdb58Lme
WYGquObuIIgjTW4bGbCiaK2bqlzk5QJaWIgdCIKBzOut6LDgYc8HDiHR60C3
QGNPxfEB5xL3G3A95wU3cMMlJCdo3INcQQfcVM52y89sF8yVDZAhxu1nGh38
hcK0Kc7FKi/zppWLrcMFs+MKeHSiF8C1W3Fj/Z79bQNIkHuls7larmJlqSCA
u7SXFpKJ7mwYuRGsdL6ZyhHdgDjuCXX04FabpuCVVyI9xELp7/u8ucFpqhTx
MOOIUEoEaq3YBvqZ1WCgWHkNROFeeXktJRS1ItIEblnPqYHzomDv/U1VyHXE
lJaR2g1Aqob1LnLc2s67eaddVCLvAJUEJHzzTpcRsaufg7ZMeeud3qVkxWjZ
aKFFzDHohAedoKYLKQykX1qsXrn3tutYeZO99er2BKqEpaj7kHwYK5X6YCRE
A7MBfXFHWi/FcqFUNMdV0+MjayPjHHm32SYGM3aQdb/4gtFi/wDdY6HzZwjq
R4Wx4BUWVFzuY+F8oFpESFDar8pt7dh73eBCW0tyXmN8DZXIhOUw7CU5i3so
BtN2WYnuMfAhQymd7mskzjAcaJc2jVJpvW7QkK8kjHMA6ef2Agc02BMaTtVs
/eb9jBeEgZ2i3ZGrQbzlvOOvYQAD/TBlFXkVnBpewxUwGLvFFzpNI9szW7cz
A4rz8tq2W42xIWi5VPGKwSTrJPKJZhgV34pMztjtTCHhyTlU1PM2knaqid7/
mcnwwnRLXGJSJlUhgjL4om8mfwvxebIcnAE63mZSzw3Be+SaYsGFUEJqykai
0ihRcR4XFferRcUTgxNsJgLr7jBSwC6cJFwQf5JqcigjA9KV9lIUjRdXL4iG
VN2oDUqWsKah9QOyMsuLAtk9sEk4DBHmbxtWZKDM7kREj3VIgivxYSUO07cw
KH96cR6a5sLzjw4OuNwrP0khlKXRa0dUFGIjCm2HjJeqTBSFhFrcBkdDKJFz
i6GUDUiu8IULsQeItZoV7pFLHzDHIFFnWPEtFwl4xo1RZ1Gh0eK2M4vcbC2N
F1vPVKfxMNymnCehcnXjitbpcnvWtUiLFhHqglToH3BBWDOq7AmjyY2hGeGt
mNogpBYNQ2oHBjGed6GW54N6MqamRdR2xtOI7jcdkt+P9cUHo+vFUr30RIt+
er4R1fo4KIod6X7/4eidjE/wH9EEhvoMLar6HfkE5b5H0ciTK42038FUxawg
3/1BQHd4+Hk7SPiF0OBEaG4qLvhIWJBIIKF5ItPueL+rkPdIBtWl0e1ALR0y
2oPi7ohISREKFUNYcsNSRK/40jYABycqrWEq7UmKfFurkNbOWGYXHRnFMjmr
3quNXdHTp2egvRb14KHOvTdMw+bsI8eu1yJc87BmDY+qxL1G6RrCbVe1mWIA
s/s4TyP3P0Roh/bdDMDdfGSBkhuGeg+11wrkB6zZ74TJuW0flNlUbqEcgtr1
7Z5rCWU9AV2uGgx4CY3KDSa9XeDu7OzN+QyFZnZ6bM/m0nDXdzu6Btke9U1J
sgGvcmd33KHuuusomB69TDtgqYZqRQtiGcnudUKxKpgTPi0jB1kjFbMuns4A
QZEc01TDPYOwYZwuGF+e6gmNjarPxz+X3fIsL14bJ1xXylwZNpu8ZQsouYAy
KNzatLGHq2rdPMZLuepEqsqMJ0YCNgbmzDrFou0CSl6qWeDRk76cngtxKhZb
M4BvW4I9pmh7+Q1WLSbl9TSrfFsqXKgjovFDeJ48kZ2jwS44N4evoMh40JMv
pWq1BmFCzdaVMZoNTBrgjhva3HTbhlBVpPSKldqlahbsjhVLVECcIm0Qc+F8
rRAlpNuxhuSmygH98Nw2XhW1NaZogfAcqcHg95OXg+882tE/EK4XVEKBgbIq
LxCLqTXA+Qz9AVtH8J5nO9cycRlmoEuRBoYTkdICbllK4xx3TUdxKI3WRlgv
0VO8yQtgaJJUNcJzQzqNPekiMxR3WdDA8T7/7T+hJWDzHxb/hnyAf4Ak/H3y
En4jMX/otyBn3LARmWMAY5Su/bpay6yBTk33nUpWIP3GJY3BUli9eeLZZnwq
Zi8A8GHOTyYR/gw3rK5i/nSQONnbOWs5bmpuCKvG1xUrsbtGD5NLltxUhfSW
qPS7NVMhlhKM6PzizfaA1s0tTPXOAdk7BqSb0aazO7DkFnIfQHWKOXrbvWL1
x7p1vqbbce521+/VORA32feXyHa/on+eZ0YJcFekfW8Ph8s/JQWsDmxXVzC1
pnxANYCKAgGR6Ytq/QycbKPlMtdsVitQPT/L4GbNBMppbvI1SHB7zySoGqwt
0RmrlaOsJfkq+ISexUZ4I0qE+Uarsn1S+sctMaNTA2SHGhCL9PeLr/6ZqPJ7
4xdN+z/x5xfxj17lF2xH+LAXfDrecuz8pXZwcf3CFeovQo3+8uvp0n9zujjP
kPOLc9vzFxevjvCfI8sOvz9+Nzke86NlwkjgH/mb06W144QutoP/HF1Aa9MN
YTuiBVv+Hrfj2Ra241n2l9oRLTjT7fyX7XlW9EXKoB37UbqG7RzfUPjPNs+r
4sFyTG9nO85WO64bPo0u23qULq2dnaPZboeP51vJD7dtR0IpcH3TJdDNx/pA
mdobilgNFUaXNi99ftBFLVrdplqJiHopQhyYg6ACoqC7UlZlWad1dDuPWkOE
7FVwVu8eh8e3dAXMwq2JFS1ws7fm6Ghd5ZjY3Cd8GwNtJt2kgSqS9pAWOIqH
3rlSOmnJVbEEgwDiMMwPuKpd/G1Dy3YDWAQta3Vd0zWoQ303tucSP7JIAZL8
zFJMmVjl1zctjiQGbzzLkxxo4G6bGNdQBQ9OS2lh957I4mE+rLJpgZk/9x70
ak2TVqQy4UMJCDVncG6MM/6nTrJhCEZtZWgUdSMED1xE/Clvh5V3eV2Js2ZL
LmIANTZ5ygp4LbYYtLltNvEqbxrujMg54bbhuNL3uDvEONcy38RpqY9rJnLA
0WQi+OnZOXJ0jH2ejQzaeE7EGSowvOjAiwwFKJW3m3bSTdInw+g9ZFTs3PmW
sbD9PFN79exA+mLoOfLTMHzGiJZWaXTJ0Z1T0KiWMCQH/F7lH7G4XDDXRRWD
yGANMTCxBviMNCLIoNyeZuT3aG5M0wcYFmMPgmzK/G8bzGhUm4QSNigvFg1a
v6esxQ9kAojYmOkx8Iqu11wgBRbpkuS2eWxojtvWuOZ9R3wkwr9vhBP8KGAY
Pd2FB37pO+BfO3PfDKz9LwT8XvgNnq8o9linv9c7HRnrv/yOtwbuPPw+X8Cj
SVs8KgaPJk3tqBg82mEBoeAv5OzNOfwWT6YMk2xNFoMnZNzacUfDoyQcdzQ8
SsJxR8MWCU9kbxe13A5QdPFLNb2XPPDEw/Ubnmmwe6FgJPMZUZEFdfZHgn9t
txbz1UF6mQpBcH0iZB1RMt+JWOG2w7VYSI0xTPKcD2Ol3VbCu6Njnr49TOCQ
i4PbNIPvjatcPZ740I1L2uI+LILRqGGwYxQQM04xWVGFNfVkEjV6PWaqrXIt
udLo0r20wCSPH8rQLagVnrIlDb9MhhJE5djxSo1ORCq6REZ+kv467/Yf+iM2
Mm1PnihAp07fdziEGezULwbvkGHk6OhEHo07JEeDtKaBK9zcnsL7krA1BhBq
VLgiSU4/SLemea2HAMbHCYRqfuJxly4AJeVNTQdtwJNTwkXVMO75UVyeKLBa
gfJOeCpkaWxxRaRajg+Dqc3GFSAbwjLEJPj0nj4MQ9z6kZ4dJICLqAXWeH6x
rI15xuidvkX7D7iR3jbK6okTDj1iyssGd1tSAwUTzF7LBuGg5Ygn2wc6ucjw
nKxHvaOhXM30bAi58bCcbYnRTAsjrtczJT03e16QRLYZBL7vWq7PwsAPfDOJ
PNtMTc+lNHISh2ax6TLH9APTS2PfjEzHDD0ziN3U2VOCdrPn2mlq2R5jWeKa
UeLEXuD4Pgtsi7qm6TpZ7FEvZI7rp56VWI4D9NAgsJ3A8k3bCveELbT8fZEc
/pwnTH33BV9x/4gLF9DoeAfkOa95s0ct07JC29kT6WmfumsLnvM80+fddxdH
7piOJUuKMuxWK7LgZUzXSzPbtQM7o5kLpiDyHBO4ETPTyuCxGcbIqqirJn7S
LGS2H3qWk5k0inyWmlFMg9A1w8ilwJPI9ZPYDkfVbCcDPicevHXMyEnD0PJo
AGy0HScOvISGLImtIBhV89zUdq0ocJgk5/NcslJbVN0RL8Usx6PUSaMwcCI7
jOLQCTwLJhJwgwvTHkdBwNw4Ar8ps5Mwyai4BwN/YsvLAj+0YM4DH0gNMzPy
oesPB51dG6+mgVHrUu+loeqUOjdfT0uh15SOSl5Xa+xeqZ5dmkelMRFqaLoG
z8JqO6QiALZr2xADR0vjh6pVSXQi1UoiaXFgCD1KaFNoMJl/rM6QzTHVWp7E
grr3uK8P5gfsXtNrNXmiQOfZlI6bTmIfEyCvGnhE6fG7caTEPE37GUr7kR3a
jzxF/V2enZwdIuvBp9i0MhkYG5zKOQHFo00D15tHpxcLUAuLp2tJPBvQinOF
3W45rvYksfwwcZnlholn09AxLZMGnu3BYvSoGyRJHPqhnTIWJywLs4R5KehN
y7cYaIbMc6idJqBTUT2CwjmcmZbIKXmShhcFH9fgosw30+KqOa7Jo4CCxnGy
CEhxkxQ0DdAPmsr1I89kWeqyGPA3s/wEVFgaAHdcxpLQsf3IzqLM76m2d1A9
imq9OoL/bPP87O2fMY709QyIWWIHHrVAU6WOb6dmaEVpYsJ40zCigRMzPwZy
Yt+ncWD7lJmxRTPmJGCWXCthIwbEIUvhRZp5fmI7JnP8jPq+bcLMgw2A1kPP
B01rM+qBLHiA+LMsiFM/oiALqZ9JUxb5V+bImGkiSvatocEyrQlzld9ppsjj
g0Or4aUps8LEzyIwK2BamOeNVX5/ZLZPBBFNlZuiEKV+6pr+aWBKfr3tVT9b
Nlj9fBrZrG2brH6mbHNfZ2Cj1Y+y1WkUxEHkhn7GbBbEUZjFVpy6zlYF8ZO4
GWXMsfwsc8LUDmF1UCuB2R/b5W5oJg3NyI5CGlnMBwRgJYmZ2DF1d1QAI+/D
UgOo4HtWHPhRQrM0SrNgVw/MCykNMi8ILDvCsWcmwAwzpv6IG5/no5nTplum
KKP6Hx4RGs+V7bqemYGqYJED5t/xQI0EqRXAEGgQeUnGUmaPRpqYDktYatEU
xD+JAxYkdsZ814kCbYgf5k8WsceVgiZtrr1T2ug/LG3210obcCCLU9C2sckC
xwPVm/lxQh032zG1MQNe26Ft215EE8CDWeIknmlm1i5po6CyWQQw0Rmvpm8y
+2YQxa4LswkYLkmpT70sDNyQ4moIUBQAbqajsbmm44EJsKGq53qW7zsh6NoU
vkXbs/9hNyTUscYUNpyEhpeVOK2sb1Vq6U8S5vGIsbps4AsgB680wMBsf/kI
HwTe7mWR+xpv7qmH10UUfeR50C62gjuBl4/2LkphU5gv38p8+W7Dob+Lw3gc
m0mfKdw31Pp6ruXmPZcLw/b34PNwLfyFr7+/EOtwEcA/p8cnF0cEI2F/0Yp9
hmrKnui5fMPG5JKCJbQnWP9HOVq87m6vK9hZJsWW51L+jo6saLlcvgjN4z1V
RkTJEb4+52VOnRchlLG9FyG2+MHYIU/8XPlT5agD1e+OjncCanj3D4PpFU34
ZD0lBID9CbiEn2BGnsP/iGcF1x5Bs/98SBNgcxq5gR17oRn4jo9aFLAZtb3A
M9HaRVYSx6BUrdizY4DjVkrDyA9CBNeOGfzTI80gpG6UBjQLkELXdaOQRVDU
8S1KTfA3rNClWeKGMeCNkPohWGjwPlI7SQPm9Ugz2EKauvSQ/VFsxFRo8dPW
ovyO7E3J115X33P90I8CxzbF7wC/gwDA9GU+g28e/rZZt5Rbet1XBnci803P
A8SQxp4Tu6ZppQDPwjC2qevHtmkyQGDMYmkQgIuRphmGjpyEYnQl3PvN4Vbg
FwD3bwtfHZrYlu/YzPWYBeAicJzMNG26C1zaICxu5uBScsB3SxyQRo8GSbyr
Aos8z405dgscypIostzICUJ/R4UURBnmIgo8QCuhZ/vMZzb4u1uwQP0krhVT
L3CizI6BDNcKQhRoFrv/KIBBscbI9XjavIQxO3Zt8M+DLIP1aPluFtAwtVgQ
JUkGEuSMR8tA6OwMgIzt2z7oGwrqB7x98P1AVyH4hYU7jrG5Djh+PmOBaQLr
HD/M7Ci1fvuIF+XUfkxOvxr4mnaSZTRJfDNlmQNqOjXBa3J8fxeOtW2wHikL
U/CUrNSJnCgFRWYG6S6vyY1YHJtxTIHn/1dy42ReHIKVsgMr9WzHTWPw6j03
TcC+WalpOxGLxkje9cIoAwvosdDzndiEgnESOwG4ShTWiWWBi7cV0o3dBKqB
znMxpGuDkMJK/XqsDFBigG+Qrils8xV5+1oIVc9FVvtE/Bi/vAby9N3UXlyf
mhwzQDIyXImFtesj1eB2oxFBtbQauFsNMnt63AmtdUhsZVO2NK890ra/3hI4
+EU1gtuw0A/fI1ZdLWAglirwUT3kA/A9llJAB4BfAgwHsNAGa45qBDwp04Il
SykFB5tZcezF4NRZZpgycJkTQEielXaDV3K6cLBZi3k22EMPmgCzkAVZxFwT
LGOUOaBnHXA+Yxr6JqAIZiag92nAIsaS1DRDN7WiZE87HjOQKJQFS4nThLSM
BWsnJ6XEyUmXgvNPO+vyMACeddoTef5XmOe/90EWBvX3U/jhV8pITBMvtqyE
AuyJoixKAP6aXpK5ccRsDCui7gH9EriebYdgIahtRTC9qU/NiGXZDhmxTcsJ
wTjbUDv2U88HvGxmFEA56CLTpQ71AZWCIU8wmuPHfhb7iLTiOEssgLNdsyo4
IpT8Pwz454/Jnv3tZW+XwvmCIzAlhWdvzjUptEZSaI2k0HpECn+FoXfwy0jE
RDO6jLnTMpbEQWJGMPMxQPQkABhkhoyZXhzFceqAl+J54LMwmL44dQEEwm8W
RY4Vg/12E9t+fNacr561x+kXySrdVfp43D9P5dU4DVishiULzHH7PHmHLTzA
Awd43bLwyVUad3fsJBk2yIMq/f3b/OZnvGAjwwsk5I0NuHfHc1J4Yt+4T3Wd
Zp/Y0AWd+N1SfP+P8dTA7dTFrcuLccCiPZGwQm/1S0R4H3yTq1mSV/jnCOYi
PwbzVriZ7lvGKyL4nXGYzdJf587Pc3MBEzcqYk4qHr/tL92BvpJqLeMe2g08
itCaFXjDEZp66HxTJ7xoDQOvViVuVYpzivSO5gXnXVXKbMe7PGF6eitmfhpd
uglui47vY+KBF3G5ruigeOiuykpHx+MMVjabml9/KK956dI1m+6uHvyrB/JO
T9EgKTcr/FMBslVxf3bdH7PsbkstCUqvOByQVkycw56MPFJ+29fWBbJLIvek
DTwaLea3u2KiIUV+y/pA41yLOc672NOcyCQv/GKq5CmVnkTTdDQU+TcHuPDK
Kx3Fxc6cRVODx2vfsuHmsepy65pJGRyd2ltSZ1yNwZXIMsuLZ09d89Wo3Slz
l9Mvk28M6O+mgR9ul9K6PRpgvErIQg5wcRGyYnSiMkUEZxtPzM1xqTWT45YX
seXNHIXK6DKtebwE5/meXy8iL9uR9wdo14yt+V8LYLsGYeDaxKxlmUl7vaEg
ty0T2bcl4HWtXZ48S1Ti8Uhx8lMp4wv/a5ybBqSP15EyhFdHy2MvMpV5jwtr
d3au2RN6tSJG/1YcySbn3S0PeyoJHbRFn9WrtdL/4Q9jQcgP4g/ZfCHdifwn
DuyQXL44sYbYDV+e9Jf0HqpzLiLzdZgdqRbzO3HhMm37+OvJK1iq+xy/zcmr
Nycv5RgOxB3QfEH3T3nqtLIx+n4uzgom3pFjuhZ5D8AFQIqAJj7wx/yiJn43
fw2aBu/Uen168T2+eo/Ht1DgDgn56Scg9FCIGGivDx9EAZF0kSLlf8aMzin2
TZyBGfLP0fkXfGv+Qb89/+DLBP8wh5ZnsesMxOn+bTBw4vDPkIE6VnOib81A
6L5nIAxigoHw9DfMwMlTT0MOBjratb4tB0X3T1zD89/mIn78wNeQl+HQc/gt
8HLrTNj/P0MnTr4N2RjpbHS+MRuh93/yNf3Iib+RdTZ1Rrq/AUb+P0ujwj9b
OEljNLvFz/yUDmfif2k8XAgecg7z4xfyas3umUJTh+SH50db7OaMHWf0j0gB
SrbcWyBH/P20mCa38s87Cb+ywqH/CQAuP+nF3ReYq/J261BFmt/l6QbQtLry
IudXFnfeaaMuOpA3weMZFP5HLAa76/KvcnRHHjkze0/R0G5lI0UlLzcrxL32
+Cf4+DWV6O3iHyzYcH+cb7G/z8E1rlOQuLrEvzpIXhe0zsnbfNPcUZgkw3iZ
S1/1fkhsJel9D62RV9WmKZg4AfoC+JlSTE8GrN4TbQyIVtia/x1K9BmTaiH+
sB4PuOcliCMtyJ243kFA+6PktqzuC5Zei+srt/ivhvTv1Q10T9u2aSpwpt7h
y/O6qqvkFr8BxaxQlGMJA4f9fcVwvBesoDx80c8WHpIFpyADtwPFYGn8L56x
+bC9cwAA

-->

</rfc>