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.17 (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-09" 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 abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sieg</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="09"/>

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

    <abstract>


<?line 62?>

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

<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" type="1">
  <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" type="1">
      <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" type="1">
      <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" type="1">
  <t>Prepare a Recipient_structure</t>
  <t>Pass in the following parameters to HPKE Open API
  <list style="numbers" type="1">
      <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 804?>

<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:
H4sIAAAAAAAAA9V963LcyJHufzxFRSvikLS7W7hfuDsOUyQ10koackV6vY6x
glEACiRMNNAG0KQ4kvws51nOk21mXYACGk1RY53YMWOG6gbqlllZmV9mZRUX
i4XR5m3BDsmfGkaqjLx6iOs8JeebuMiTxRv2QE7LpH5Yt3lVkv1X529OD8h9
3t6Q4xdn78lZ/DeWtOQivy7z8prQMh0UPz67OD0waBzX7O6Q4DeCLRhplZR0
BZ2mNc3aRc7abJFUDVvcrG/ZwoyMhLbsuqofDknTpoaRr+tDsq6Z5wThZb1p
Wts0I9M2aM3oIblgyabO2wfjvqpvr+tqsxZ9GbfsAR6lh+R12bK6ZO3iBPsz
jKaFkV7RoiphDA+sMdb5Ifm5rZI5aaq6rVnWwKeHFX74YBh0095U9aGxMAjJ
y+aQvFqSyya5qTJW5tfwUBDzipYla4Zv2IrmxSG54a+Wbffqj9erj0sYERRR
7Hm1ePH+Ar5X9TUt818oshCmpczvWN0AeTg7R+t1kbOUXCQ5KxPo7EVVlov3
NywvFxc5wx6TalO2yLkfWb2i5UM/6rMluWgZK1g34rM6Z/2zukI5YGneVvXW
OC5rWjarTct6oiqo/cdWPV/mZQozA88afRQw/hYH3MKMNv1YTpbk6G/Q0Srv
BnNC82Zzy7TnwxHEeZy3tOj7T+nfcvgPWAlfl0m10vv9D7qmZd/f2yV5uynT
uKBpT/5buqmRjYNXw06VbJHLGwbySN6+Pe4HUFwXf2xkgZa/H49iSL1RVjAl
LUzoIRR6//LYtqxIfgytwJUfIys01UfTs/uPDn68uDyJeEkjL7NRe2HkBKpp
3+GNvF6cLPMa11dWXy/SElcYPsd1uHh99NMRfoEfJeNE/gAbYN3Ae/FEKomB
diDT2gErkffsOgdheJC1aX3NWlgGbbtuDp8/v7+/X+a0pEvo5TltGlAfK1a2
zXMcHf+1/HjTrgpROwXmgawmbRWzmtim7SD1i8UClg70QRNY0Zc3eUOaNUvy
LE/43JGUZTmuxxsx5rXQaKATCNsaMzCSbEABcs1mPFm1LTkbYWFmsEQJJXe0
BrJaeGBMdwdLmNYgxjWtHxZN/gvIxrqgOainj23DR0FJDUSsYXm3csgE2lga
Bu8JNZwsVz6AmK3ivKRdyyWhoLRWDBYhr4U903WzKUSRFUtAD+XNiuy/OX13
MEf9CFyq8zvxPtuUiSDuzcnLgzknGcUChoI8hbFqlCCnDJqCsoBvtMBJomT/
6PTo5KBrCNZ4X533AAPndOSlsAY5qN66ustTaDx+4M8WJZdoohZWP+wGhBJL
gdZGcqHl4fAMyf6G2zHoZinlAszNBuWrEwmsumm6VgRruVGDAUAtlK1Vnqag
Fo1nBM1HXaUbThNMxBPk6dMnuY6/fAEaYVJB8bMVg95oSxTJjTbBTxeSa2AO
TDQxOjnZa4aS8itoJvtixKBuvnyZE/XF+fLlYIksOK7KO+RzVTZcLC7BtuRl
VVTXD9gf4ySgrW3I7N2fLi5nc/Ev+emMf35/+p9/ev3+9AQ/X7w6evu2+6BK
XLw6+9NbeG/IT33N47N3705/OhGV4SkZPXp39JeZENbZ2fnl67Ofjt7OUMBa
YIPRsQGgAmkrEjOCjKwBTKBAU2AUa5I6j+EL1HlxfP5/yrhZ/5vlCiaghoY5
5J9RRX/5YtyDxIn+qrIAqvlXYOkDoes1ozW2Q4uCwNJDewVIAnppbqr7ktyw
mi0nlRXMjJiirCqK6p5rHI4LctpzHca9ag5BPHE+WqBqoUkNzsD+8ekbXLi8
pJx5TtfxuwtJD5iFL1+W0MRTVDnKUd+IJtTYwPr2PRbAQWtyLMWrE8654PGu
RhqtEa6I2K9pRY5e03XvRroO1AmbqnXSq7+XI/U3UeNooA1Ph9qQHDVNleT8
1UmvDacb6hXnsE1ZcboeLES+bFGNcoBrPHtGzgAe3uXsflKsms16DYAWGHxf
kVWFOkfqRqWC5xwLgRwbYFR/J3ABOclrtH0agVh3jrJeS9UBXYHMprimpBCK
SVSKChAyDgfrwUooxVqJmajE2QVKEcS80GZ5CeSCcl8U9IHVsOo6PYktp6wF
0NUs0fb3Ix3J7VOGScFu8tVDplaPWGjQH3zB2s0mbtjfN1Acxv9kiju+rzZF
m691IhukEqajoxKomSbUeF2SuAJOJRS1AyUluxfa+oYBVq3JmtYwd7DW51Ck
KGBse+x2b25oRCeouB94u4pqubaABnCuarBqAIL1taWsgzEQpSWZAZ9nQAeo
zgbp4AUbWD+0EDZKt0EvdUDFZwJL4/C2Bk/QUBgxKgDesBrDpgS2tCCH0PZW
HZwlbmCQKpgAQ5IkVQBUgXGgJOTJDU5jtWnXm3Zg/EAvCDWetwa30QgmcZE9
e7ZrFbzDuf30rJdRw/gzEti1Ob1w+PsOrcPDhNZ1zrnd5PK1gRN71WO/fmpg
bGwF9ikdVuDlZUemwofazKd8KMXDtLB2Yg48RxEFewM9w7rBl8gOBnQxtGVJ
sUl7wRj0iniMm4iWArxJl+Q1IBeYpIeioiliO+4c4kKABhqGs9eiqkGFB1zH
ulJuZ6oNJaUzwI6kzAseZjAqgcWhPBCQ9KMpqqRDv1zEOxLA1QXtCd4bf+0Z
UEBDOBJpC9Pfga5uDJKCZimwDQhlKsUUPgtG0uJak0Y5nLG8SvkDRy3l6n0A
wjqAOuyAE9gvlv2xTB8MuoV5Hi0VQ3QN7CvAodtc34yB395tnu4Nxz6cVERN
eQMubE2vBSwHvhFk3Jxjqg5aNj0Su/hKL8Y+MLziEtU9aw64Kv24Bq2Ro6CC
ZIMdzIS2asBlBm0y5QwZXMRjWY7zjovetnxK5dBoQ+KyN8AWZEV5kyiRMKCG
FShrfJLXwFaAJYhKNHQiZ40vuLHLKbAkwjVydP5arjLgGX7hGA9ezChNZxpv
ANrkJWinJfkzDm48G3JFy3ELhVBWBMFF77Kxj+Au4fRLL4oILwq4ikPQvVQ+
HFUPVHer6BkNi3SOmRQy3gjSgcsWIClXUNAjbSRobci+0irACPCbyQ28ixkM
vGYLTkVWVyt9IR4Amv3HP/5hALlXvcb7gfzMPX+uC0BXHXLbw/kBDgK+6Vfa
ISjHdftwVdVXvS26WtG1KAjVWQ1kXgFxUBZVvPHBMHbUgZ6xBFkmMcirWEn8
+XP5HL0xYvIhc57148hyVnR6aUjOQAr7GrQFPz3eYGCIs2VbfPsmwGvkBoeY
c9TnldTIwmaR9mGNbsWnTwm4rCKGqsMo9D2aieaPT07e9n0sxUwMilxd0mvU
AT+QZ/7S8vcHLw8M49/IWzGqYbVuAl9xDjZiKnrlLCcCuAoafg7zgR1/OiTP
JsYvIk8/zPhghQzB1DxicNFGz76I6RmOChxFRKCtoAkBSik+A+lHuIToCpFa
rrw17md0A1nI9wKIK4wwwp8SIPTwbgwQJvDqABmItQWQbWRye21ldDM2J/mS
LXk4ZCd4WAMHe3zNISVXAFy1gbUb+Zx80A13lvPyriruWHpI0OGU80z2k6oG
yLCuwKRBeakadD73nR8MJV/hz/0OhBwYEpsol0DibomkNYEBFY1Tpyy0xG0Z
6MFWe4g60hC44jHcMpB5RZo1QZoei5uiqjdlAM1ZKmVTIDGofs1KhogHPZ0b
YClioKQGADHlRvRkC7EXUiA4p7GJeyWlAvD4rSeGDDWSxMw6Su7l0BgCGKW3
JzD3Vn2OS7qqS77QpurBatOr3WLMrOsQqH/U3BtaSKE3871B2aDv2HsXKqjS
Lbwhfh4zXIkiD8ehd0qLhseG5Dzx4GbnusGo2xxNt5gpQCysFEinc2G1QKge
yFvj/KPzZBw1nERU+3F1x+aCqO0QEOUzPJINNdzeCggV9Iy87+SzVyoqANhh
EWyiK3ilCf/rFv23O4bLpWlh2pAmvlLenLy8OpbWV0UbFlxwej9WWPt11TR5
DDhDoDuOPUC2qhpYuOpjNuB/Sc9FA5AHfAhcwFRkYGdnCJLaoaMsRU4FljWo
OJLFhveD3gPYXNwIhFnIuBRu2eoutiQjoWCfiR5VKYBS4TwMVe4cNMAd657L
2Vj2VkjnqIqMdlRLDL6QoozmcGLC0Kz+v/+rIyMARl05iYxKeHzFpeQKpuEQ
fYTnLTQh3nbjvep4dCV4NIWjehjV1wMc1cEoDoMWZDbsc6YCep0YkNcnyi/g
8iGEGNko/PMJK4ceqJRoDIUK2C0mcdg0X8KtjEAPRAkX8VKshTtabJh4C3ZW
9jjpwiEp4FbeK1HmQ10a+yK2JhYLX7pQDVySGsSfoWyqBoFS3eJos86Hz/XM
ClTFNXcHQRxpctvIgBVFa91U5SIvF9DCQuxAEAxkXm9FhwUPez5wCIleB7oF
Gnsqjg84l7jfgOs5L7iBGy4hOUHjHuQKOuCmcrZbfma7YK5sgAwxbj/T6OAv
FKZNcS5WeZk3rVxsHS6YHVfAoxO9AK7dihvr9+zvG0CC3CudzdVyFStLBQHc
pb20kEx0Z8PIjWCl881UjugGxHFPqKMHt9o0Ba+8EukhFkp/3+fNDU5TpYiH
GUeEUiJQa8U20C+sBgPFymsgCvfKy2spoagVkSZwy3pODZwXBXvvb6pCriOm
tIzUbgBSNax3kePWdt7NO+2iEnkHqCQg4Zt3uoyIXf0ctGXKW+/0LiUrRstG
Cy1ijkEnPOgENV1IYSD90mL1yr23XcfKm+ytV7cnUCUsRd2H5MNYqdQHIyEa
mA3oizvSeimWC6WiOa6aHh9ZGxnnyLvNNjGYsYOs+8UXjBb7B+geC50/Q1A/
KowFr7Cg4nIfC+cD1SJCgtJ+VW5rx97rBhfaWpLzGuNrqEQmLIdhL8lZ3EMx
mLbLSnSPgQ8ZSul0XyNxhuFAu7RplErrdYOGfCVhnANIP7cXOKDBntBwqmbr
N+9nvCAM7BTtjlwN4i3nHX8NAxjohymryKvg1PAaroDB2C2+0Gka2Z7Zup0Z
UJyX17bdaowNQculilcMJlknkU80w6j4VmRyxm5nCglPzqGinreRtFNN9P7P
TIYXplviEpMyqQoRlMEXfTP5e4jPk+XgDNDxNpN6bgjeI9cUCy6EElJTNhKV
RomK87iouN8sKp4YnGAzEVh3h5ECduEk4YL4s1STQxkZkK60l6JovLh6QTSk
6kZtULKENQ2tH5CVWV4UyO6BTcJhiDB/27AiA2V2JyJ6rEMSXIkPK3GYvoVB
+dOL89A0F55/dHDA5V75SQqhLI1eO6KiEBtRaDtkvFRloigk1OI2OBpCiZxb
DKVsQHKFL1yIPUCs1axwj1z6gDkGiTrDim+5SMAzbow6iwqNFredWeRma2m8
2HqmOo2H4TblPAmVqxtXtE6X27OuRVq0iFAXpEL/gAvCmlFlTxhNbgzNCG/F
1AYhtWgYUjswiPG8C7U8H9STMTUtorYznkZ0v+mQ/H6sLz4YXS+W6qUnWvTT
842o1sdBUexI9/sPR+9kfIL/iCYw1GdoUdUfyCco9yOKRp5caaT9DqYqZgX5
4Q8CusPDL9tBwq+EBidCc1NxwUfCgkQCCc0TmXbH+12FvEcyqC6Nbgdq6ZDR
HhR3R0RKilCoGMKSG5YiesWXtgE4OFFpDVNpT1Lk21qFtHbGMrvoyCiWyVn1
Xm3sip4+PQPttagHD3XuvWEaNmcfOXa9FuGahzVreFQl7jVK1xBuu6rNFAOY
3cd5Grn/IUI7tO9mAO7mIwuU3DDUe6i9ViA/YM1+J0zObfugzKZyC+UQ1K5v
91xLKOsJ6HLVYMBLaFRuMOntAndnZ2/OZyg0s9NjezaXhru+29E1pvsO+6Yk
2YBXubM77lB33XUUTI9eph2wVEO1ogWxjGT3OqFYFcwJn5aRg6yRilkXT2eA
oEiOaarhnkHYME4XjC9P9YTGRtXn45/LbnmWF6+NE64rZa4Mm03esgWUXEAZ
FG5t2tjDVbVuHuOlXHUiVWXGEyMBGwNzZp1i0XYBJS/VLPDoSV9Oz4U4FYut
GcC3LcEeU7S9/AarFpPyeppVvi0VLtQR0fghPE+eF8/RYBecm8NXUGQ86MmX
UrVagzChZuvKGM0GJg1wxw1tbrptQ6gqUnrFSu1SNQt2x4olKiBOkTaIuXC+
VogS0u1YQ3JT5YB+eG4br4raGlO0QHiO1GDw+8nLwXce7egfCNcLKqHAQFmV
F4jF1BrgfIb+gK0jeM+znWuZuAwz0KVIA8OJSGkBtyylcY67pqM4lEZrI6yX
6Cne5AUwNEmqGuG5IZ3GnnSRGYq7LGjgeJ///l+Y8V+Vf1j8O/IB/gGS8PfJ
S/iNxPyh34KcccNGZI4BjFG69utqLbMGOjXddypZgfQblzQGS2H15olnm/Gp
mL0AwIc5P5lE+DPcsLqK+dNB4mRv56zluKm5IawaX1esxO4aPUwuWXJTFdJb
otLv1kyFWEowovOLN9sDWje3MNU7B2TvGJBuRpvO7sCSW8h9ANUp5uht94rV
H+vW+ZZux7nbXb9X50DcZN9fI9v9hv55nhklwF2R9r09HC7/lBSwOrBdXcHU
mvIB1QAqCgREpi+q9TNwso2Wy1yzWa1A9fwig5s1EyinucnXIMHtPZOgarC2
RGesVo6yluSr4BN6FhvhjSgR5hutyvZJ6R+3xIxODZAdakAs0t8vvvlnosrv
jc+a9n/iz2fxj17lM7YjfNgLPh1vOXb+Wju4uD5zhfpZqNHPv54u/Teni/MM
Ob84tz1/cfHqCP85suzwx+N3k+MxP1omjAT+kb85XVo7TuhiO/jP0QW0Nt0Q
tiNasOXvcTuebWE7nmV/rR3RgjPdzn/bnmdFX6UM2rEfpWvYzvENhf9s87wq
HizH9Ha242y147rh0+iyrUfp0trZOZrtdvh4vpf8cNt2JJQC1zddAt18rA+U
qb2hiNVQYXRp89LnB13UotVtqpWIqJcixIE5CCogCrorZVWWdVpHt/OoNUTI
XgVn9e5xeHxLV8As3JpY0QI3e2uOjtZVjonNfcK3MdBm0k0aqCJpD2mBo3jo
nSulk5ZcFUswCCAOw/yAq9rF3ze0bDeARdCyVtc1XYM61Hdjey7xE5AUIMkv
LMWUiVV+fdPiSGLwxrM8yYEG7raJcQ1V8OC0lBZ274ksHubDKpsWmPlL70Gv
1jRpRSoTPpSAUHMG58Y443/qJBuGYNRWhkZRN0LwwEXEn/J2WHmX15U4a7bk
IgZQY5OnrIDXYotBm9tmE6/ypuHOiJwTbhuOK32Pu0OMcy3zTZyW+rhmIgcc
TSaCn56dI0fH2OfZyKCN50ScoQLDiw68yFCAUnm7aSfdJH0yjN5DRsXOnW8Z
C9vPM7VXzw6kL4aeIz8Nw2eMaGmVRpcc3TkFjWoJQ3LA71X+EYvLBXNdVDGI
DNYQAxNrgM9II4IMyu1pRn6P5sY0fYBhMfYgyKbM/77BjEa1SShhg/Ji0aD1
e8pa/EAmgIiNmR4Dr+h6zQVSYJEuSW6bx4bmuG2Na953xEci/PtGOMGPAobR
01144HPfAf/amftmYO0/E/B74Td4vqLYY53+Xu90ZKz/+jveGrjz8Pt8AY8m
bfGoGDyaNLWjYvBohwWEgp/J2Ztz+C2eTBkm2ZosBk/IuLXjjoZHSTjuaHiU
hOOOhi0SnsjeLmq5HaDo4pdqei954ImH6zc802D3QsFI5jOiIgvq7I8E/9pu
Learg/QyFYLg+kTIOqJkvhOxwm2Ha7GQGmOY5Dkfxkq7rYR3R8c8fXuYwCEX
B7dpBhVn1eU5Ukx86MYlbXEfFsFo1DDYMQqIGaeYrKjCmnoyiRq9HjPVVrmW
XGl06V5aYJLHD2XoFtQKT9mShl8mQwmicux4pUYnIhVdIiM/SX+dd/sP/REb
mbYnTxSgU6fvOxzCDHbqF4N3/HD/0dGJPBp3SI4GaU0DV7i5PYX3JWFrDCDU
qHBFkpx+kG5N81oPAYyPEwjV/MTjLl0ASsqbmg7agCenhIuqYdzzo7g8UWC1
AuWd8FTI0tjiiki1HB8GU5uNK0A2hGWISfDpPX0Yhrj1Iz07SAAXUQus8fxi
WRvzjNE7fYv2H3AjvW2U1RMnHHrElJcN7rakBgommL2WDcJByxFPtg90cpHh
OVmPekdDuZrp2RBy42E52xKjmRZGXK9nSnpu9rwgiWwzCHzftVyfhYEf+GYS
ebaZmp5LaeQkDs1i02WO6Qeml8a+GZmOGXpmELups6cE7WbPtdPUsj3GssQ1
o8SJvcDxfRbYFnVN03Wy2KNeyBzXTz0rsRwH6KFBYDuB5Zu2Fe4JW2j5+yI5
/DlPmPrhK77i/hEXLqDR8Q7Ic17zZo9apmWFtrMn0tM+ddcWPOd5ps+77y6O
3DEdS5YUZditVmTBy5iul2a2awd2RjMXTEHkOSZwI2amlcFjM4yRVVFXTfyk
WchsP/QsJzNpFPksNaOYBqFrhpFLgSeR6yexHY6q2U4GfE48eOuYkZOGoeXR
ANhoO04ceAkNWRJbQTCq5rmp7VpR4DBJzpe5ZKW2qLojXopZjkepk0Zh4ER2
GMWhE3gWTCTgBhemPY6CgLlxBH5TZidhklFxDwb+xJaXBX5owZwHPpAaZmbk
Q9cfDjq7Nl5NA6PWpd5LQ9UpdW6+npZCrykdlbyu1ti9Uj27NI9KYyLU0HQN
noXVdkhFAGzXtiEGjpbGT1WrkuhEqpVE0uLAEHqU0KbQYDL/WJ0hm2OqtTyJ
BXXvcV8fzA/YvabXavJEgc6zKR03ncQ+JkBeNfCI0uNX7UiJeZr2M5T2Izu0
H3mK+rs8Ozk7RNaDT7FpZTIwNjiVcwKKR5sGrjePTi8WoBYWT9eSeDagFecK
u91yXO1JYvlh4jLLDRPPpqFjWiYNPNuDxehRN0iSOPRDO2UsTlgWZgnzUtCb
lm8x0AyZ51A7TUCnonoEhXM4My2RU/IkDS8KPq7BRZnvpsVVc1yTRwEFjeNk
EZDiJiloGqAfNJXrR57JstRlMeBvZvkJqLA0AO64jCWhY/uRnUWZ31Nt76B6
FNV6dQT/2eb52du/YBzp2xkQs8QOPGqBpkod307N0IrSxITxpmFEAydmfgzk
xL5P48D2KTNji2bMScAsuVbCRgyIQ5bCizTz/MR2TOb4GfV924SZBxsArYee
D5rWZtQDWfAA8WdZEKd+REEWUj+Tpizyr8yRMdNElOxbQ4NlWhPmKr/TTJHH
B4dWw0tTZoWJn0VgVsC0MM8bq/z+yGyfCCKaKjdFIUr93DX988CU/Hrbq362
bLD6+TSyWds2Wf1M2ea+zsBGqx9lq9MoiIPIDf2M2SyIozCLrTh1na0K4idx
M8qYY/lZ5oSpHcLqoFYCsz+2y93QTBqakR2FNLKYDwjAShIzsWPq7qgARt6H
pQZQwfesOPCjhGZplGbBrh6YF1IaZF4QWHaEY89MgBlmTP0RN77MRzOnTbdM
UUb1PzwiNJ4r23U9MwNVwSIHzL/jgRoJUiuAIdAg8pKMpcwejTQxHZaw1KIp
iH8SByxI7Iz5rhMF2hA/zJ8sYo8rBU3aXHuntNF/Wtrsb5U24EAWp6BtY5MF
jgeqN/PjhDputmNqYwa8tkPbtr2IJoAHs8RJPNPMrF3SRkFlswhgojNeTd9l
9s0gil0XZhMwXJJSn3pZGLghxdUQoCgA3ExHY3NNxwMTYENVz/Us33dC0LUp
fIu2Z//DbkioY40pbDgJDS8rcVpZ36rU0p8kzOMRY3XZwFdADl5pgIHZ/vIR
Pgi83csi9zXe3FMPr4so+sjzoF1sBXcCLx/tXZTCpjBfvpX58t2GQ38Xh/E4
NpM+U7hvqPX1XMvNey4Xhu3vwefhWvgrX39/JdbhIoB/To9PLo4IRsL+qhX7
AtWUPdFz+YaNySUFS2hPsP6PcrR43d1eV7CzTIotz6X8HR1Z0XK5fBGax3uq
jIiSI3x9zsucOi9CKGN7L0Js8YOxQ574ufKnylEHqt8dHe8E1PDunwbTK5rw
yXpKCAD7E3AJP8GMPIf/Ec8Krj2CZv/1kCbA5jRyAzv2QjPwHR+1KGAzanuB
Z6K1i6wkjkGpWrFnxwDHrZSGkR+ECK4dM/iXR5pBSN0oDWgWIIWu60Yhi6Co
41uUmuBvWKFLs8QNY8AbIfVDsNDgfaR2kgbM65FmsIU0dekh+6PYiKnQ4qet
RfkD2ZuSr72uvuf6oR8Fjm2K3wF+BwGA6ct8Bt88/G2zbim39LqvDO5E5pue
B4ghjT0ndk3TSgGehWFsU9ePbdNkgMCYxdIgABcjTTMMHTkJxehKuPebw63A
LwDu3xe+OjSxLd+xmesxC8BF4DiZadp0F7i0QVjczMGl5IDvljggjR4NknhX
BRZ5nhtz7BY4lCVRZLmRE4T+jgopiDLMRRR4gFZCz/aZz2zwd7dggfpJXCum
XuBEmR0DGa4VhCjQLHb/WQCDYo2R6/G0eQljduza4J8HWQbr0fLdLKBharEg
SpIMJMgZj5aB0NkZABnbt33QNxTUD3j74PuBrkLwCwt3HGNzHXD8fMYC0wTW
OX6Y2VFq/fYRL8qp/ZicfjPwNe0ky2iS+GbKMgfUdGqC1+T4/i4ca9tgPVIW
puApWakTOVEKiswM0l1ekxuxODbjmALP/3/JjZN5cQhWyg6s1LMdN43Bq/fc
NAH7ZqWm7UQsGiN51wujDCygx0LPd2ITCsZJ7ATgKlFYJ5YFLt5WSDd2E6gG
Os/FkK4NQgor9duxMkCJAb5BuqawzTfk7WshVD0XWe0T8WP88hrI03dTe3F9
anLMAMnIcCUW1q6PVIPbjUYE1dJq4G41yOzpcSe01iGxlU3Z0rz2SNv+ekvg
4BfVCG7DQj98j1h1tYCBWKrAR/WQD8D3WEoBHQB+CTAcwEIbrDmqEfCkTAuW
LKUUHGxmxbEXg1NnmWHKwGVOACF5VtoNXsnpwsFmLebZYA89aALMQhZkEXNN
sIxR5oCedcD5jGnom4AimJmA3qcBixhLUtMM3dSKkj3teMxAolAWLCVOE9Iy
FqydnJQSJyddCs6/7KzLwwB41mlP5PlfYZ7/3gdZGNTfz+GHXykjMU282LIS
CrAnirIoAfhreknmxhGzMayIugf0S+B6th2ChaC2FcH0pj41I5ZlO2TENi0n
BONsQ+3YTz0f8LKZUQDloItMlzrUB1QKhjzBaI4f+1nsI9KK4yyxAM52zarg
iFDy/zTgnz8me/b3l71dCucrjsCUFJ69Odek0BpJoTWSQusRKfwVht7BLyMR
E83oMuZOy1gSB4kZwczHANGTAGCQGTJmenEUx6kDXorngc/CYPri1AUQCL9Z
FDlWDPbbTWz78VlzvnnWHqdfJKt0V+njcf88lVfjNGCxGpYsMMfty+QdtvAA
DxzgdcvCJ1dp3N2xk2TYIA+q9Pdv85uf8YKNDC+QkDc24N4dz0nhiX3jPtV1
mn1iQxd04ndL8f0/xlMDt1MXty4vxgGL9kTCCr3VLxHhffBNrmZJXuGfI5iL
/BjMW+Fmum8Zr4jgd8ZhNkt/nTs/z80FTNyoiDmpePy2v3QH+kqqtYx7aDfw
KEJrVuANR2jqofNNnfCiNQy8WpW4VSnOKdI7mhecd1Upsx3v8oTp6a2Y+Wl0
6Sa4LTq+j4kHXsTluqKD4qG7KisdHY8zWNlsan79obzmpUvXbLq7evCvHsg7
PUWDpNys8E8FyFbF/dl1f8yyuy21JCi94nBAWjFxDnsy8kj5bV9bF8guidyT
NvBotJjf7oqJhhT5LesDjXMt5jjvYk9zIpO88IupkqdUehJN09FQ5N8c4MIr
r3QUFztzFk0NHq99y4abx6rLrWsmZXB0am9JnXE1Blciyywvnj11zVejdqfM
XU6/Tr4xoL+bBn64XUrr9miA8SohCznAxUXIitGJyhQRnG08MVf+AZWpccuL
2PJmjkJldJnWPF6C83zPrxeRl+3I+wO0a8bW/K8FsF2DMHBtYtayzKS93lCQ
25aJ7NsS8LrWLk+eJSrxeKQ4+amU8YX/Nc5NA9LH60gZwquj5bEXmcq8x4W1
OzvX7Am9WhGjfyuOZJPz7paHPZWEDtqiz+rVWun/8IexIOQn8XdxvpLuRP4L
B3ZILl+cWEPshi9P+kt6D9U5F5H5OsyOVIv5nbhwmbZ9/PXkFSzVfY7f5uTV
m5OXcgwH4g5ovqD7pzx1WtkYfT8XZwUT78gxXYu8B+ACIEVAEx/4Y35RE7+b
vwZNg3dqvT69+BFfvcfjWyhwh4T8/DMQeihEDLTXhw+igEi6SJHyv2BG5xT7
Js7ADPnn6PwLvjf/oN+ef/Blgn+YQ8uz2HUG4nT/Nhg4cfhnyEAdqznR92Yg
dN8zEAYxwUB4+htm4OSppyEHAx3tWt+Xg6L7J67h+W9zET9+4GvIy3DoOfwW
eLl1Jux/n6ETJ9+GbIx0NjrfmY3Q+7/4mn7kxN/IOps6I93fACP/l6VR4Z8t
nKQxmt3iZ35KhzPxvzUeLgQPOYf58Qt5tWb3TKGpQ/LT86MtdnPGjjP6R6QA
JVvuLZAj/n5aTJNb+eedhF9Z4dD/DACXn/Ti7gvMVXm7dagize/ydANoWl15
kfMrizvvtFEXHcib4PEMCv8jFoPddflXObojj5yZvadoaLeykaKSl5sV4l57
/BN8/JpK9HbxDxZsuD/Ot9jf5+Aa1ylIXF3iXx0krwta5+RtvmnuKEySYbzM
pa96PyS2kvS+h9bIq2rTFEycAH0B/EwppicDVu+JNgZEK2zN/6wl+oxJtRB/
WI8H3PMSxJEW5E5c7yCg/VFyW1b3BUuvxfWVW/xXQ/qP6ga6p23bNBU4U+/w
5Xld1VVyi9+AYlYoyrGEgcP+sWI43gtWUB6+6GcLD8mCU5CB24FisDT+B8zL
F1oMdAAA

-->

</rfc>