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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7924 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml">
<!ENTITY I-D.mglt-lurk-lurk SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-lurk-lurk.xml">
<!ENTITY I-D.mglt-lurk-tls12 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-lurk-tls12.xml">
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-mglt-lurk-tls13-05" category="std">

  <front>
    <title abbrev="LURK/TLS 1.3">LURK Extension version 1 for (D)TLS 1.3 Authentication</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>

    <date year="2021" month="July" day="26"/>

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

    <abstract>


<t>This document describes the LURK Extension ‘tls13’ which enables
interactions between a LURK client and a LURK server in a context of
authentication with (D)TLS 1.3.</t>



    </abstract>


  </front>

  <middle>


<section anchor="todo" title="TODO">

<t><list style="numbers">
  <t>check the terminology is used. PSK agreed….</t>
  <t>move the handshake description to the s_exchange description description</t>
  <t>state diagram for the server.</t>
</list></t>

</section>
<section anchor="sec-intro" title="Introduction">

<t>This document defines a LURK extension for TLS 1.3 <xref target="RFC8446"/>.</t>

<t>This document assumes the reader is familiar with TLS 1.3 the LURK architecture <xref target="I-D.mglt-lurk-lurk"/>.</t>

<t>Interactions with the Cryptographic Service (CS) can be performed by the TLS client as well as by the TLS server.</t>

<t>LURK defines an interface to a CS that stores the security credentials which include the PSK involved in a PSK or PSK-ECDHE authentication or the key used for signing  in an ECDHE authentication. 
In the case of session resumption the PSK is derived from the resumption_master_secret during the key schedule <xref target="RFC8446"/> section 7.1, this secret MAY require similar protection or MAY be delegated as in the LURK extension of TLS 1.2 <xref target="I-D.mglt-lurk-tls12"/>.</t>

<t>The current document extends the scope of the LURK extension for TLS 1.2 in that it defines the CS on the TLS server as well as on the TLS client and the CS can operate in non delegating scenarios.</t>

<t>This document defines the role to specify whether the CS runs on a TLS client or a TLS service. The CS MUST be associated a single role.</t>

<t>From a LURK client perspective, the purpose of the LURK exchange is to request secrets, a signing operations, or ticket (NewSessionTicket) as summed up in Table <xref target="table:x_purpose"/>.</t>

<figure title="Operation associated to LURK exchange" anchor="table:x_purpose"><artwork><![CDATA[
+--------+-----------------------+------------------------+
|  Role  | LURK exchange         | secret | sign | ticket |
+--------+-----------------------+--------+------+--------+
| server | s_init_early_secret   | yes    |  -   |  -     |
| server | s_init_cert_verify    | yes    | yes  |  -     |
| server | s_hand_and_app_secret | yes    |  -   |  -     | 
| server | s_new_ticket          | yes    |  -   |  yes   |
| client | c_init_post_hand_auth |  -     | yes  |  -     |
| client | c_post_hand_auth      |  -     | yes  |  -     |
| client | c_init_cert_verify    | yes    | yes  |  -     |
| client | c_init_early_secret   | yes    |  -   |  -     | 
| client | c_init_hand_secret    | yes    |  -   |  -     |
| client | c_hand_and_app_secret | yes    |  -   |  -     |
| client | c_register_tickets    | yes    |  -   |  yes   |
+--------+-----------------------+--------+------+--------+
]]></artwork></figure>

<t>The number of operations are limited, but the generation of secrets, tickets as well as signing heavily rely on the knowledge of the TLS handshake messages and in turn impacts these TLS handshake messages. 
As a result, these operations are highly inter-dependent.
This is one reason multiple sequential exchanges are needed between the LURK client and the CS as opposed to independent requests for secrets, signing or tickets. 
This especially requires the necessity to create a session between the LURK client and the CS. 
In addition, the LURK client and the CS need to synchronize the TLS handshake. 
First it is a necessary component for the CS to generate the secrets, signature and tickets. 
Second, elements are respectively generated by the LURK client and by the CS.</t>

<t>While all these messages do share a lot of structures, they also require different structure that make them unique.</t>

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

<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 document uses the terms defined <xref target="RFC8446"/> and <xref target="I-D.mglt-lurk-tls12"/>.</t>

<t><list style="hanging">
  <t hangText="ECHDE">
  designates the ECDHE authentication defined in <xref target="RFC8446"/>. 
(EC)DHE</t>
  <t>designates the shared secret agreed by the key_share extension (section 4.2.8 of <xref target="RFC8446"/>) during a TLS handshake.</t>
  <t hangText="PSK Proposed">
  A TLS handshake between a TLS client and a TLS server is said to be “PSK proposed” when the latest ClientHello contains a psk_key_exchange_modes (section 4.2.9 of <xref target="RFC8446"/>) and a pre_shared_key (section 4.2.11 of <xref target="RFC8446"/>) extension.
A TLS client is said to “propose PSK” when its TLS handshake is PSK proposed.</t>
  <t hangText="PSK Agreed">
  A TLS handshake between a TLS client and a TLS server is said to be “PSK agreed” when the TLS handshake is PSK proposed and the ServerHello contains a psk_key_exchange_modes and a pre_shared_key extension.
A TLS client and a TLS server are said to have “agreed on PSK” when its TLS handshake is PSK agreed.</t>
  <t hangText="ECDHE Agreed">
  A TLS handshake between a TLS client and a TLS server is said to be “ECDHE agreed” when the ServerHello contains neither a psk_key_exchange_modes or a pre_shared_key extension. 
As currently TLS proposes only ECDHE and PSK based authentication, when PSK agreed is false, ECDHE agreed is true. 
A TLS client and a TLS server are said to have “agreed on ECDHE” when its TLS handshake is PSK agreed.</t>
  <t hangText="Key Share Proposed">
  A TLS handshake between a TLS client and a TLS server is said to be “key shared proposed” or “(EC)DHE proposed” when the latest ClientHello contains a key_share extension (section 4.2.8 of <xref target="RFC8446"/>).
A TLS client is said to “propose PSK” when its TLS handshake is PSK proposed.</t>
  <t hangText="Key Share Agreed">
  A TLS handshake between a TLS client and a TLS server is said to be “key shared agreed” or “(EC)DHE agreed” when the TLS handshake is key shared proposed and the ServerHello contains neither a key_share extension. 
A TLS client and a TLS server are said to have “agreed on (EC)DHE” when its TLS handshake is key share agreed.</t>
  <t hangText="Early Data Enabled">
  A TLS client is said to “support early data” or “enable early data” when its latest ClientHello contains a early_data extension (section 4.2.10 of <xref target="RFC8446"/>.</t>
  <t hangText="Post Handshake Enabled:">
  A TLS client is said to “support early data” or “enable early data” when its latest ClientHello contains a post_handshake_auth extension.</t>
</list></t>

</section>
<section anchor="sec-lurk-tls-header" title="LURK Header">

<t>LURK / TLS 1.3 is a LURK Extension that introduces a new designation “tls13”. 
This document assumes that Extension is defined with designation set to “tls13” and version set to 1. 
The LURK Extension extends the LURKHeader structure defined in <xref target="I-D.mglt-lurk-lurk"/> as follows:</t>

<figure><artwork><![CDATA[
enum {
    tls13 (2), (255)
} Designation;

enum {
   capabilities(0), 
   ping(1), 
   s_init_cert_verify(2),   
   s_new_ticket(3),         
   s_init_early_secret(4),  
   s_hand_and_app_secret(5),
   c_binder_key(6),         
   c_init_early_secret(7),  
   c_init_hand_secret(8),   
   c_hand_secret(9),        
   c_app_secret(10),         
   c_cert_verify(11),        
   c_register_tickets(12),    
   c_post_hand(13), (255)          
}TLS13Type;


enum {
    // generic values reserved or aligned with the
    // LURK Protocol
    request (0), success (1), undefined_error (2),
    invalid_payload_format (3),

    invalid_psk
    invalid_freshness

    invalid_request
    invalid_key_id_type 
    invalid_key_id 
    invalid_signature_scheme
    invalid_certificate_type
    invalid_certificate
    invalid_certificate_verify
    invalid_secret_request
    invalid_handshake
    invalid_extension
    invalid_ephemeral
    invalid_identity
    too_many_identities
    
}TLS13Status

struct {
     Designation designation = "tls13";
     int8 version = 1;
} Extension;

struct {
    Extension extension;
    select( Extension ){
        case ("tls13", 1):
            TLS13Type;
    } type;
    select( Extension ){
        case ("tls13", 1):
            TLS13Status;
    } status;
    uint64 id;
    unint32 length;
} LURKHeader;
]]></artwork></figure>

</section>
<section anchor="sec:structures" title="Structures">

<t>This section describes structures that are widely re-used across the multiple LURK exchanges.</t>

<section anchor="sec:secret_request" title="secret_request">

<t>secret_request is a 16 bit structure described in Table <xref target="table:secret_request_struct"/> that indicates the requested key or secrets by the LURK client. 
The secret_request structure is present in the request of any exchange except for a c_post_hand exchange. 
The same structure is used across all LURK exchanges, but each LURK exchange only permit a subset of values described in Table <xref target="table:secret_request_value"/>.</t>

<t>A LURK client MUST NOT set secret_request to key or secrets that are not permitted. 
The CS MUST check the secret_request has only permitted values and has all mandatory keys or secrets set. 
If these two criteria are not met the CS MUST NOT perform the LURK exchange and SHOULD return a invalid_secret_request error. 
If the CS is not able to compute an optional key or secret, the CS MUST proceed the LURK exchange and ignore the optional key or secret.</t>

<figure title="secret_request structure" anchor="table:secret_request_struct"><artwork><![CDATA[
+------+-------------------------------------------+
| Bit  |      key or secret     (designation)      |
+------+-------------------------------------------+
| 0    | binder_key (b)                            |
| 1    | client_early_traffic_secret (e_c)         |
| 2    | early_exporter_master_secret (e_x)        |
| 3    | client_handshake_traffic_secret (h_c)     |
| 4    | server_handshake_traffic_secret (h_s)     |
| 5    | client_application_traffic_secret_0 (a_c) |
| 6    | server_application_traffic_secret_0 (a_s) |
| 7    | exporter_master_secret (x)                |
| 8    | resumption_master_secret (r)              |
| 9-15 | reserved and set to zero                  |
+------+-------------------------------------------+
]]></artwork></figure>

<figure title="secret_request permitted values per LURK
exchange" anchor="table:secret_request_value"><artwork><![CDATA[
+-----------------------+-----------------------------+  
| LURK exchange         | Permitted secrets           |
+-----------------------+-----------------------------+
| s_init_cert_verify    | h_c*, h_s*, a_c*, a_s*, x*  |
| s_new_ticket          | r*                          |
| s_init_early_secret   | b,e_c*, e_x*                |
| s_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x*    | 
| c_init_post_hand_auth | -                            |
| c_post_hand_auth      | -                            |
| c_init_cert_verify    | a_c*, a_s*, x*              |
| c_init_client_hello   | b*, e_c*, e_x*              | 
| c_client_hello        | b*, e_c*, e_x*              | 
| c_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x*, r*| 
| c_register_tickets    | -                            |
+-----------------------+-----------------------------+
* indicates the secret MAY be requested
- indicates no secrets van be requested
]]></artwork></figure>

</section>
<section anchor="sec:handshake" title="handshake">

<t>The derivation of the secrets, signing operation and tickets requires the TLS handshake. 
The TLS handshake is described in <xref target="RFC8446"/> section 4 and maintained by the TLS server and the TLS client to derive the same secrets. 
As the CS is in charge is deriving the secrets as well to perform some signature verification, the CS must be be aware of the TLS handshake.
The TLS handshake is not necessarily being provided by the LURK client to the CS, but instead is derived some structures provided by the LURK client as well as other structures generated or modified by the CS.</t>

<t>When an unexpected handshake context is received, the CS SHOULD return an invalid_handshake error.</t>

<t>The value of the TLS hanshake is defined in <xref target="RFC8446"/> section 4 and remainded in
Table <xref target="table:handshake"/> reminds the TLS handshake values after each LURK exchange and describes operations performed by the CS in order to build it.</t>

<t>On the TLS server:</t>

<t><list style="symbols">
  <t>(a) ServerHello.random value provided by the LURK client requires specific treatment as described in <xref target="sec:freshness"/> before being inserted in the TLS handshake variable.</t>
  <t>(b) When the shared secret ( and so the private ECDHE ) is generated by the CS, the KeyShareServerHello structure cannot be provided to the CS by the LURK client in a ServerHello and is instead completed by the CS as described in <xref target="sec:ephemeral"/>.</t>
  <t>(c) The TLS Certificate structure MUST not be provided by the LURK client as part of the handshake structure. 
Instead, the CS generates the Certificate message from the certificate structure described in <xref target="sec:cert"/>. The handshake MUST NOT contain a TLS Certificate message and CS SHOULD raise an invalid_handshake_error if such message is found in the TLS handshake. 
When a client Certificate is provided, the CS SHOULD raise an invalid_handshake error in the absence of a CertificateRequest message.</t>
  <t>(d) The Certificate and Finished messages are not provided in a handshake structure by the LURK client but are instead generated by the CS as described in <xref target="sec:sig"/>.</t>
  <t>(e) Some authentication PSK_ECHDE or ECDHE requires the agreement of a shared ECDHE secret. 
This is indicated by the presence of key_share extension in both ClientHello and ServerHello.
When these extensions are not found, the CS SHOULD raise an error. Note that in the case of PSK / PSK-ECDHE, the presence or absence of key_share extension MAY be used to distinguish between the two authentication methods.</t>
  <t>(f) ECDHE authentication does not involve the agreement of a PSK. 
This is indicated by the presence of a key_share extension in both ClientHello and ServerHello. 
When these extensions are found, the CS SHOULD raise an error.</t>
  <t>(g) PSK and PSK_ECDHE requires the agreement of a PSK, so a psk is expected in the ClientHello as well as - when present in the ServerHello. 
When this extension are not found, the CS SHOULD raise an error.</t>
</list></t>

<figure title="handshake values per LURK exchange" anchor="table:handshake"><artwork><![CDATA[
+-----------------------+------------------------------------+---------------+ 
| LURK exchange         |        TLS handshake               | CS operations |
+-----------------------+------------------------------------+---------------+
| s_init_cert_verify    | ClientHello ... later of           | a,b,c,d,e,f   |
|                       | server EncryptedExtensions /       |               |
|                       | CertificateRequest                 |               |
| s_new_ticket          | earlier of client Certificate /    | c             |
|                       | client CertificateVerify /         |               |
|                       | Finished ... Finished              |               |
| s_init_early_secret   | ClientHello                        | a, g          |
| s_hand_and_app_secret | ServerHello ... later of           | b, g          |
|                       | server EncryptedExtensions /       |               |
|                       | CertificateRequest                 |               |
| c_init_post_hand_auth | ClientHello ... ServerHello        | e             |
|                       | CertificateRequest                 |               |
| c_post_hand_auth      | CertificateRequest                 |               |
| c_init_cert_verify    | ClientHello...server Finished      | e,f           |
| c_init_client_hello   | (Partial) ClientHello  or          |               |
|                       | ClientHello, HelloRetryRequest,    |               |
|                       | (Partial) ClientHello              |               |
| c_client_hello        | HelloRetryRequest, (Partial) ClientHello           |
| c_hand_and_app_secret | ServerHello, {EncryptedExtensions} |               |
|                       | ... later of { server Finished } / |               |
|                       | EndOfEarlyData                     |               |
| c_register_tickets    | -                                  |               |
+-----------------------+------------------------------------+---------------+
]]></artwork></figure>

<figure><artwork><![CDATA[
Handshake handshake<0..2^32> //RFC8446 section 4 (clear) clientHello...client finished CertificateRequest
]]></artwork></figure>

</section>
<section anchor="sec:session_id" title="session_id">

<t>The session_id is a 32 bit identifier that identifies a LURK session between a LURK client and a CS. 
Unless the exchange is sessionless, the session_id is negotiated at the initiation of the LURK session where the LURK client (resp. the CS) indicates the value to be used for inbound session_id in the following LURK exchanges.     <vspace />
For other LURK exchanges, the session_id is set by the sender to the inbound value provided by the receiving party. 
When the CS receives an unexpected session_id the CS SHOULD return an invalid_session_id error.</t>

<t>Table <xref target="table:session_id"/> indicates the presence of the session_id.</t>

<figure title="session_id in LURK exchanges" anchor="table:session_id"><artwork><![CDATA[
+-----------------------+------------+
| LURK exchange         | session_id |
+-----------------------+------------+
| s_init_cert_verify    |      *     |
| s_new_ticket          |      y     |
| s_init_early_secret   |      y     |
| s_hand_and_app_secret |      y     |
| c_init_post_hand_auth |      *     |
| c_post_hand_auth      |      y     |
| c_init_cert_verify    |      *     |
| c_init_client_hello   |      y     |
| c_client_hello        |      y     |
| c_hand_and_app_secret |      y     |
| c_register_tickets    |      y     |
+-----------------------+------------+

y indicates the session_id is present
- indicates session_id may be absent
* indicates session_id may be present (depending on the tag.last_message)
]]></artwork></figure>

<t>The session_id structure is defined below:
~~~
uint32 session_id
~~~</t>

</section>
<section anchor="sec:freshness" title="freshness">

<t>The freshness function implements perfect forward secrecy (PFS) and prevents replay attack. 
On the TLS server, the CS generates the ServerHello.random of the TLS handshake that is used latter to derive the secrets. 
The ServerHello.random value is generated by the CS using the freshness function and the ServerHello.random  provided by the LURK client in the handshake structure. 
The CS operates similarly on the TLS client and generates the ClientHello.random of the TLS handshake using the freshness function as well as the ClientHello.random value provided by the LURK client in the handshake structure.</t>

<t>If the CS does not support the freshness, the CS SHOULD return an invalid_freshness error. 
In this document the freshness function is implemented by applying sha256.</t>

<t>Table {table:freshness} details the exchanges that contains the freshness structure.</t>

<figure title="freshness in LURK exchange" anchor="table:freshness"><artwork><![CDATA[
+-----------------------+-----------+
| LURK exchange         | freshness |
+-----------------------+-----------+
| s_init_cert_verify    |     y     |
| s_new_ticket          |     -     |
| s_init_early_secret   |     -     |
| s_hand_and_app_secret |     y     |
| c_init_post_hand_auth |     y     |
| c_post_hand_auth      |     -     |
| c_init_cert_verify    |     y     |
| c_init_client_hello   |     y     |
| c_client_hello        |     -     |
| c_hand_and_app_secret |     -     |
| c_register_tickets    |     -     |
+-----------------------+-----------+

y indicates freshness is present
- indicates freshness is absent
]]></artwork></figure>

<t>The extension data is defined as follows:</t>

<figure><artwork><![CDATA[
enum { sha256(0) ... (255) } Freshness;
]]></artwork></figure>

<t>When the CS is running on the TLS server, the  ServerHello.random is generated as follows:</t>

<figure><artwork><![CDATA[
server_random = ServerHello.random
ServerHello.random = freshness( server_random + "tls13 pfs srv" );
]]></artwork></figure>

<t>When the CS is running on the TLS client, the ClientHello.random is generated as follows:</t>

<figure><artwork><![CDATA[
client_random = ClientHello.random
ClientHello.random = freshness( client_random + "tls13 pfs clt" );
]]></artwork></figure>

<t>The server_random (resp client_random) MUST be deleted once it has been received by the CS.<vspace />
In some cases, especially when the TLS client enables post handshake authentication and interacts with the CS via a (c_init_post_hand_auth) exchange, there might be some delay between the ClientHello is sent to the server and the Handshake context is shared with the CS.
The client_random MUST be kept until the post-handshake authentication is performed as the full handshake is provided during this exchange.</t>

</section>
<section anchor="sec:ephemeral" title="ephemeral">

<t>The Ephemeral structure carries the necessary information to generate the (EC)DHE shared secret used to derive the secrets. 
This document defines the following ephemeral methods to generate the (EC)DHE shared secret:</t>

<t><list style="symbols">
  <t>secret_provided: Where (EC)DHE keys and shared secret are generated by the TLS server and provided to the CS</t>
  <t>secret_generated: Where the (EC)DH keys and shared secret are generated by the CS.</t>
  <t>no_secret: where no (EC)DHE is involved, and PSK authentication is performed.</t>
</list></t>

<section anchor="sharedsecretprovided" title="shared_secret_provided:">

<t>When ECDHE shared secret are generated by the TLS server, the LURK client provides the shared secret value to the CS.
The shared secret is transmitted via the SharedSecret structure, which is similar to the key_exchange parameter of the KeyShareEntry described in <xref target="RFC8446"/> section 4.2.8.<vspace />
The CS MUST NOT return any data.</t>

<figure><artwork><![CDATA[
struct {
   NamedGroup group;  
   opaque shared_secret[coordinate_length];
} SharedSecret;
]]></artwork></figure>

<t>Where coordinate_length depends on the chosen group. 
For secp256r1, secp384r1, secp521r1, x25519, x448, the coordinate_length is respectively 32 bytes, 48 bytes, 66 bytes, 32 bytes and 56 bytes. 
Upon receiving the shared_secret, the CS MUST check group is proposed in the KeyShareClientHello and agreed in the KeyShareServerHello.</t>

</section>
<section anchor="secretgenerated" title="secret_generated:">

<t>When the ECDHE public/private keys are generated by the CS, the LURK client requests the CS the associated public value. 
Note that in such cases the CS would receive an incomplete Handshake Context from the LURK client with the public part of the ECDHE missing. 
Typically the ServerHello message would present a KeyShareServerHello that consists of a KeyShareEntry with an empty key_exchange field, but the field group is present.</t>

<t>The CS MUST check the group field in the KeyShareServerHello, and get the public value of the TLS client from the KeyShareClientHello. 
The CS performs the same checks as described  in <xref target="RFC8446"/> section 4.2.8. 
The CS generates the private and public (EC)DH keys, computes the shared key and return the KeyShareEntry server_share structure defined in <xref target="RFC8446"/> section section 4.2.8 to the LURK client.</t>

</section>
<section anchor="nosecret" title="no_secret">

<t>With PSK authentication, (EC)DHE keys and shared secrets are not needed. 
The CS SHOULD check the PSK authentication has been agreed, that is pre_shared_key and psk_key_exchamge_modes extensions are noth present in the ClientHello and in the ServerHello</t>

<t>When the ephemeral method or the group is not supported, the CS SHOULD return an invalid_ephemeral error.</t>

<figure title="Ephemeral field in LURK exchange" anchor="table:ephemeral"><artwork><![CDATA[
+-----------------------+-----------+---------------------------+  
|                       |           |  ephemeral_method= secret |
| LURK exchange         | ephemeral | no | provided | generated |
+-----------------------+-----------+----+----------+-----------+
| s_init_cert_verify    |     y+    | -  |    y     |     y     |
| s_new_ticket          |     -     | -  |    -     |     -     |
| s_init_early_secret   |     -     | -  |    -     |     -     |
| s_hand_and_app_secret |     y     | y  |    y     |     y     |
| c_init_post_hand      |     y     | -  |    y     |     -     |
| c_post_hand           |     y     | -  |    y     |     y     |
| c_init_cert_verify    |     y     | -  |    y     |     y     |
| c_init_client_hello   |     y     | y  |    -     |     y     |
| c_client_hello        |     y     | y  |    -     |     y     |
| c_hand_and_app_secret |     y     | y  |    y     |     -     | 
| c_register_tickets    |     -     | -  |    -     |     -     |
+-----------------------+-----------+----+----------+-----------+

y indicates presence of ephemeral or possible value for ephemeral_method
- indicates absent or ephemeral or incompatible value for ephemeral_method
]]></artwork></figure>

<t>The extension data is defined as follows:</t>

<figure><artwork><![CDATA[
enum { no_secret (0), secret_provided(1), secret_generated(2) (255)} EphemeralMethod;

EphemeralRequest {
    EphemeralMethod method;
    select(method) {
        case secret_provided: 
            SharedSecret shared_secret<0..2^16>; 
    }
}

EphemeralResponse {
    select(method) {
        case secret_generated: 
            KeyShareEntry server_share
  }
}
]]></artwork></figure>

</section>
</section>
<section anchor="sec:psk_id" title="selected_identity">

<t>The selected_identity indicates the identity of the PSK used in the key schedule.
The selected_identity is expressed as a (0-based) index into the identities in the client’s list. The client’s list is provided in the pre_shared_key extension as expressed in <xref target="RFC8446"/> section 4.2.11.</t>

<t>The LURK client MUST provide the selected_identity only when PSK or PSK-authentication is envisioned and when the PSK has not been provided earlier. 
These exchanges are s_init_early_secret on the TLS server and c_init_early_secret and c_init_hand_secret on the TLS client side.</t>

<figure title="psk_id in LURK exchange" anchor="table:psk"><artwork><![CDATA[
+-----------------------+-----+
| LURK exchange         | req |
+-----------------------+-----+
| s_init_cert_verify    |  -  |
| s_new_ticket          |  -  |
| s_init_early_secret   |  y  |
| s_hand_and_app_secret |  -  |
| c_init_post_hand_auth |  -  |
| c_post_hand_auth      |  -  |
| c_init_cert_verify    |  -  |
| c_init_client_hello   |  -  |
| c_client_hello        |  -  |
| c_hand_and_app_secret |  -  |
| c_register_tickets    |  -  |
+-----------------------+-----+

y indicates the selected_identity is present
- indicates the selected_identity is absent
]]></artwork></figure>

<t>The extension data is defined as follows:</t>

<figure><artwork><![CDATA[
uint16 selected_identity; //RFC8446 section 4.2.11
]]></artwork></figure>

<t>The CS retrieve the PSK identity from the ClientHello and SHOULD send an invalid_psk error if an error occurs. 
If the PSK is not provided, a default PSK is generated as described in <xref target="RFC8446"/> section 7.1. If the default PSK is not allowed then an invalid_psk is returned.</t>

</section>
<section anchor="sec:cert" title="certificate">

<t>The certificate structure indicates the presence and associated value of the Certificate message in the TLS handshake.</t>

<t>Upon receiving a certificate field, the CS MUST:
1. ensure coherent with the handshake messages - typically authentication method is ECDHE and not PSK or PSK-ECDHE.
2. ensure the provided value corresponds to an acceptable provisioned value. 
3. generate the appropriated corresponding message.</t>

<t>If the CS is not able to understand the lurk_tls13_certificate field, it SHOULD return an invalid_certificate error.</t>

<t>Table <xref target="table:cert"/> indicates the presence of that field in the LURK exchanges.</t>

<figure title="certificate per LURK exchange" anchor="table:cert"><artwork><![CDATA[
+-----------------------+-------------+--------------------+  
| LURK exchange         | certificate | certificate type   |
+-----------------------+-------------+--------------------+
| s_init_cert_verify    |      y      | server certificate |
| s_new_ticket          |      *      | client certificate |
| s_init_early_secret   |      -      |                    |  
| s_hand_and_app_secret |      -      |                    |
| c_init_post_hand_auth |      y      | client_certificate |
| c_post_hand_auth      |      y      | client_certificate |
| c_init_cert_verify    |      y      | client certificate |
| c_init_client_hello   |      -      |                    |
| c_client_hello        |      -      |                    |
| c_hand_and_app_secret |      y      | client_certificate |
| c_register_tickets    |      -      |                    |
+-----------------------+-------------+--------------------+ 

* indicates certificate type MAY be set to emtpy. 
y indicates certificate type MUST NOT be set to empty
- indicates the certificate structure is absent
]]></artwork></figure>

<t>There are different ways the LURK client can provide the certificate message:</t>

<figure><artwork><![CDATA[
enum { empty(0), finger_print(1), uncompressed(2), (255)
}; LURKTLS13CertificateType 

struct {
    LURKTLS13CertificateType certificate_type;
    select (certificate_type) {
        case empty:
          // no payload
        case finger_print
            uint32 hash_cert;
        case uncompressed:
            Certificate certificate; // RFC8446 section 4.4.2
    };
} LURKTLS13Certificate;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="empty">
  indicates there is no certificates provided by this field.</t>
  <t hangText="fingerprint">
  a 4 bytes finger print length that represents the fingerprinting of the TLS Certificate message. 
Fingerprinting is described in <xref target="RFC7924"/> and takes as input the full handshake message - that is a message of message type certificate with that contain the Certificate as its message_data. 
In this document only the 4 most left bytes of the output are considered. 
uncompressed</t>
  <t>indicates the Certificate message as defined in <xref target="RFC8446"/> is provided.</t>
</list></t>

</section>
<section anchor="sec:tag" title="tag">

<t>This field provides extra information. 
Currently, the tag structure defines tag.last_message and tag.cert_request.</t>

<t>The LURK client or the CS sets the tag.last_message to terminate the LURK session. 
The tag.cert_request is only used by the CS in a c_hand_and_app_secret exchange. 
The tag.cert_request by the CS when a  CertificateRequest has been found in the handshake and that the CS includes in its response the necessary information to the TLS client to build a CertificateVerify message (see <xref target="sec:c_hand_and_app_secret"/> ).</t>

<t>In this document, we use setting, setting to True to indicate the bit is set to 1. Respectively, we say unsetting, setting to False to indicate the bit is set to 0.</t>

<t>Table <xref target="table:tag_values"/> indicates the different values carried by the tag as well as the exchange these tags are considered. 
The bits values MUST be ignored outside their exchange context and bits 
Bits that are not specified within a given exchange MUST be set to zero by the sender and MUST be ignored by the receiver.</t>

<figure title="tag description" anchor="table:tag_values"><artwork><![CDATA[
+------+----------------+
| Bit  | description    |
+------+----------------+
| 0    | last_exchange  |
| 1    | cert_request   |
| 2-7  | RESERVED       |
+------+----------------+
]]></artwork></figure>

<figure title="tag per LURK exchange" anchor="table:tag"><artwork><![CDATA[
+-----------------------+--------------+--------------+  
| LURK exchange         | last_message | cert_request |
+-----------------------+--------------+--------------+
| s_init_cert_verify    |       y      |       -      | 
| s_new_ticket          |       y      |       -      |
| s_init_early_secret   |       -      |       -      |
| s_hand_and_app_secret |       y      |       -      |
| c_init_post_hand_auth |       y      |       -      |
| c_post_hand_auth      |       y      |       -      |
| c_init_cert_verify    |       y      |       -      |
| c_init_client_hello   |       -      |       -      |
| c_client_hello        |       -      |       _      |
| c_hand_and_app_secret |       y      | y (response) |
| c_register_tickets    |       y      |       -      |
+-----------------------+--------------+--------------+

y indicates tag is present
- indicates tag is absent
]]></artwork></figure>

</section>
<section anchor="sec:secret" title="secret">

<t>The Secret structure is used by the CS to send the various secrets derived by the key schedule described in <xref target="RFC8446"/> section 7.</t>

<figure><artwork><![CDATA[
enum {
    binder_key (0),
    client_early_traffic_secret(1),
    early_exporter_master_secret(2),
    client_handshake_traffic_secret(3),
    server_handshake_traffic_secret(4),
    client_application_traffic_secret_0(5),
    server_application_traffic_secret_0(6),
    exporter_master_secret(7), 
    esumption_master_secret(8),
    (255)
} SecretType;

struct {
    SecretType secret_type;
    opaque secret_data<0..2^8-1>;
} Secret;
]]></artwork></figure>

<t>secret_type:
The type of the secret or key</t>

<t>secret_data:
The value of the secret.</t>

</section>
<section anchor="sec:sig" title="signature">

<t>The signature requires the signature scheme, a private key and the appropriated context. 
The signature scheme is provided using the SignatureScheme structure defined in <xref target="RFC8446"/> section 4.2.3, the private key is derived from the lurk_tls13_certificate <xref target="sec:cert"/> and the context is derived from the handshake <xref target="sec:handshake"/> and lurk_tls13_certificate <xref target="sec:cert"/>.</t>

<t>Signing operations are described in <xref target="RFC8446"/> section 4.4.3. 
The context string is derived from the role and the type of the LURK exchange as described
below. 
The Handshake Context is taken from the key schedule context.</t>

<figure><artwork><![CDATA[
+--------------------+-------------------------------------+
| type               | context                             |
+--------------------+-------------------------------------+
| s_init_cert_verify | "TLS 1.3, server CertificateVerify" |
| c_cert_verify      | "TLS 1.3, client CertificateVerify" |
+--------------------+-------------------------------------+
]]></artwork></figure>

<figure><artwork><![CDATA[
struct {
    opaque signature<0..2^16-1>; //RFC8446 section 4.4.3.
} Signature; 
]]></artwork></figure>

</section>
</section>
<section anchor="lurk-exchange-on-the-tls-server" title="LURK exchange on the TLS server">

<t>This section describes the LURK exchanges that are performed on the TLS server. 
Unless specified used structures are described in <xref target="sec:structures"/></t>

<section anchor="sec:s_init_cert_verify" title="s_init_cert_verify">

<t>s_init_cert_verify initiates a LURK session when the server is authenticated with ECDHE. 
The ClientHello received by the TLS server, and the ServerHello and optionally the HelloRetryRequest MUST carry a key_share extension.</t>

<t>If the LURK client is configured to not proceed to further exchange, it sets the last_exchange bit of the tag. When this bit is set, the session_id is ignored.
The CS sets the last_exchange bit if the last_exchange bit has been set by the LURK client or when it has been configured to not accept further LURK exchanges, such as s_new_ticket.</t>

<figure><artwork><![CDATA[
struct{
    uint8 tag;
    select (tag.last_exchange){
      case False:
        uint32 session_id;
    }
    FreshnessFunct freshness; 
    Ephemeral ephemeral;
    Handshake handshake<0..2^32>; //RFC8446 section 4
    LURKTLS13Certificate certificate; 
    uint16 secret_request;
    SignatureScheme sig_algo; //RFC8446 section 4.2.3.
}SInitCertVerifyRequest

struct{
    uint8 tag;
    select (tag.last_exchange){
      case False:
        uint32 session_id;
    }
    Ephemeral ephemeral;
    Secret secret_list<0..2^16-1>;
    Signature signature;
}SInitCertVerifyResponse
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="sig_algo">
  SignatureScheme is defined in <xref target="RFC8446"/> section 4.2.3.</t>
</list></t>

</section>
<section anchor="snewtickets" title="s_new_tickets">

<t>new_session ticket handles session resumption.
It enables to retrieve NewSessionTickets that will be forwarded to the TLS client by the TLS server to be used later when session resumption is used. 
It also provides the ability to delegate the session resumption authentication from the CS to the TLS server. 
In fact, if the LURK client requests and receives the resumption_master_secret it is able to emit on its own NewSessionTicket. 
As a result s_new_ticket LURK exchanges are only initiated if the TLS server expects to perform session resumption and the CS responds only if if session_resumption is enabled.</t>

<t>The CS MAY responds with a resumption_master_secret based on its policies.</t>

<t>The LURK client MAY perform multiple s_new_ticket exchanges. 
The LURK client and CS are expected to advertise by setting the last_exchange bit in the tag field.</t>

<figure><artwork><![CDATA[
struct {
    uint8 tag
    uint32 session_id
    Handshake handshake<0..2^32> //RFC8446 section 4.
    LURKTLS13Certificate certificate; 
    uint8 ticket_nbr;
    uint16 secret_request;
} SNewTicketRequest;


struct {
    uint8 tag
    uint32 session_id
    Secret secret_list<0..2^16-1>;
    NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1.
} SNewTicketResponse;
]]></artwork></figure>

<t>ticket_nbr:
designates the requested number of NewSessionTicket. 
In the case of delegation this number MAY be set to zero. 
The CS MAY responds with less tickets when the value is too high.</t>

</section>
<section anchor="sec:s_init_early_secret" title="s_init_early_secret">

<t>s_init_early_secret initiates a LURK session when the server is authenticated by the PSK or PSK-ECDHE methods. 
This means the ClientHello received by the TLS server and ServerHello responded by the TLS server MUST carry the pre_shared_key and psk_key_exchange_modes extensions.</t>

<t>selected_identity indicates the selected PSK</t>

<figure><artwork><![CDATA[
struct{
    uint32 session_id
    FreshnessFunct freshness 
    uint16 selected_identity
    Handshake handshake<0..2^32> //RFC8446 section 4
    uint16 secret_request;
}SInitEarlySecretRequest

struct{
    uint32 session_id
    Secret secret_list<0..2^16-1>;
}SInitEarlySecretResponse
]]></artwork></figure>

<t>The binder_key MUST be requested, since it is used to validate the PSK. 
The TLS client MAY indicate support for early application data via the early_data extension. Depending on the TLS server policies, it MAY accept early data and request the client_early_traffic_secret. 
The TLS server MAY have specific policies and request early_exporter_master_secret.</t>

<t>The CS MUST check pre_shared_key and psk_key_exchange_modes extensions are present in the ClientHello message. 
If these extensions are not present, a invalid_handshake error SHOULD be returned. 
The CS MUST ignore the client_early_traffic_secret if early_data extension is
not found in the ClientHello. 
The Cryptographic Service MAY ignore the request for client_early_traffic_secret or early_exporter_master_secret depending on configuration parameters.</t>

</section>
<section anchor="sec:s_hand_and_app_secret" title="s_hand_and_app_secret">

<t>The s_hand_and_app_secret is necessary to complete the ServerHello and always
follows an s_init_early_secret LURK exchange. Such sequence is guaranteed by the session_id. 
In case of unknown session_id or an invalid_request error SHOULD be returned.</t>

<t>The LURK client MUST ensure that PSK or PSK-ECDHE authentication has been
selected via the presence of the pre_shared_key extension in the
ServerHello. 
In addition, the selected identity MUST be the one provided in the pre_shared_key extension of the previous s_init_early_secret exchange. 
The CS MUST also check the selected cipher in the ServerHello match the one associated to the PSK. 
The CS generates the Finished message as described in <xref target="RFC8446"/> section 4.4.4. Which involves the h_s secret.
The LURK client MAY request the exporter_master_secret depending on its policies. 
The CS MAY ignore the request based on its policies.</t>

<t>If the LURK client is configured to not proceed to further exchange, it sets the last_exchange bit of the tag.
The CS sets the last_exchange bit if the last_exchange bit has been set by the LURK client or when it has been configured to not accept further LURK exchange.</t>

<figure><artwork><![CDATA[
struct{
    uint8 tag
    uint32 session_id
    Ephemeral ephemeral
    Handshake handshake<0..2^32> //RFC8446 section 4
    uint16 secret_request;
} SHandAndAppSecretRequest

struct{
    uint8 tag
    uint32 session_id
    Ephemeral ephemeral
    Secret secret_list<0..2^16-1>;
} SHandAndAppSecretResponse
]]></artwork></figure>

</section>
</section>
<section anchor="lurk-exchange-on-the-tls-client" title="LURK exchange on the TLS client">

<t>The CS described in this document considers the case where PSK and (EC)DHE private part MAY be protected by the CS. 
This document does not consider the case where a TLS client may propose a combination of protected and unprotected PSKs.
Either all proposed PSK are unprotected by the CS or all PSK are protected by the CS. 
Similarly, this document does not consider the case where a TLS client may propose a combination of protected and unprotected (EC)DHE. 
Either all (EC)DHE are generated by the CS or all (EC)DHE are generated by the TLS client.</t>

<t>Figure <xref target="fig:state:tls_client:clt"/> summarizes the different possible LURK session as well as the different messages that are involved in the session.</t>

<figure title="LURK client State Diagram" anchor="fig:state:tls_client:clt"><artwork><![CDATA[
                    ^           |        no
                    |   (EC)DHE in CS or ------------+
      ClientHello   |   PSK in CS Proposed           |
      Derivation    |       yes |                    |
                    |   c_init_client_hello          |
                    |           |           no       |
                    |   Hello Retry Request --+      |
                    |       yes |             |      |
      ClientHello   |    c_client_hello       |      |
      sent       -->v           |<------------+      |
      ServerHello-->^           |                    |      no
      received      |           |              ECDHE Agreed --+
                    |           |                yes |        |
        ServerHello | c_hand_and_app_secret c_init_cert_verify|
        Treatment   |           |                    |        |
      clientFinished|           +-------+------------+        |     no
      sent       -->v                   |         Post Auth Enabled --+
                    ^                   |                  +          |
                    |                   |         CertificateRequest  |
                    |                   |                 |           |
                    |                   |        c_init_post_hand_auth|
                    |                   |                     |       |
                    |+----------------->|<--------------------+       |
      Posthandshake ||        +---------+-------+                     |
      Treatment     ||        |                 |                     |
                    ||Post Auth Enabled   (EC)DHE in CS or            |
                    ||         +          Agreed PSK in CS            |
                    ||CertificateRequest        +                     |
                    ||        |          NewSessionTicket             |
                    ||        |                 |                     |
                    ||c_post_hand_auth c_register_tickets             |
                    ||        |                 |                     |
                    ||        +-------+---------+                     |
                    ||                |                               |
                    v+----------------+                         +-----+
                                      |                         |
                                 LURK session         LURK session
                                 closed               not initiated
]]></artwork></figure>

<t>The TLS client needs to interact with the CS when either the TLS client proposes PKSs and the CS hosts the PSKs or when the TLS client requests the CS to generate the (EC)DHE private key.
The TLS client requests with a c_init_client_hello exchange the CS the binder_keys, the (EC)DHE public part as well as early secrets and is thus able to start the TLS handshake, that is sending a ClientHello with potential early data. 
In case a HeloRetryRequest is received, the TLS client pursue with a c_client_hello exchange to complete the second ClientHello. 
Upon receiving a ServerHello as well as other messages by the TLS server, the TLS client requests via a c_hand_and_App_secret exchange the necessary information (signature, secrets) to complete the TLS handshake.</t>

<t>When the TLS client does not propose PSKs that are protected by the CS nor does request the CS to generate the private part of the (EC)DHE shared secret, the TLS client does not need to interact wit the CS to send its ClientHello.
However, the TLS client may interact with the CS to authenticate itself to the TLS server via the generation of a signature contained in a CertificateVerify message. 
Such authentication can be performed during the TLS handshake when ECDHE is agreed and when the TLS client enables post handshake authentication, in which case the signature is requested via a c_init_cert_verify exchange.</t>

<t>Once the TLS handshake is completed, and the TLS client has enabled post handshake authentication, the TLS server may request by sending a CertificateRequest the TLS client to authenticate itself with a signature. 
If the TLS client has already started a LURK session associated to the TLS handshake the signature is requested via a c_post_hand_auth exchange.
Otherwise, the signature is requested via a c_init_post_hand_auth exchange. 
Multiple post hand shake authentication may be performed in both cases and additional signature generation are requested via c_post_hand_auth exchange.</t>

<t>Similarly, once the TLS handshake is completed, the TLS client may receive NewSessionTickets from the TLS server to perform session resumption. 
If the TLS client has its (EC)DHE or the PSK in use protected by the CS - the NewSessionTicket is registered via a c_register_ticket. 
Multiple NewSessionTickets may be registered.
When no protected PSK have been agreed and (EC)DHE are not generated by the CS, the TLS client may generate the PSK session resumption. 
As a result, it cannot be registered in the CS as to prevent providing a false sense of security.</t>

<section anchor="sec:c_init_post_hand_auth" title="c_init_post_hand_auth">

<t>The c_init_post_hand_auth occurs when the TLS client performs post handshake authentication while no previous interactions occurred between the TLS client and the CS.
More specifically, the (EC)DHE shared secrets have been generated by the TLS client, and the proposed keys, if proposed previously by the TLS client, are not protected by the CS.</t>

<t>The CS completes and returns the signature as described in <xref target="sec:sig"/>.</t>

<t>Since session resumption secrets are not protected by the CS, the registration of NewSessioinTickets is not expected, and the only exchanges that MAY follow are additional post handshake authentications described in <xref target="sec:c_post_hand_auth"/>.</t>

<figure><artwork><![CDATA[
struct{
  uint8 tag;
  select (tag.last_exchange){
    case False:
      uint32 session_id;
  }
  FreshnessFunct freshness; 
  Ephemeral = ephemeral     ## ephemeral_method = secret_provided
  Handshake handshake<0..2^32> //RFC8446 section 4 
  LURKTLS13Certificate cert;
  SignatureScheme sig_algo;
}CInitPostHandAuthRequest


struct{
  unit8 tag
  select (tag.last_exchange){
    case False:
      uint32 session_id;
  }
  Signature signature 
}CInitPostHandAuth
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="tag">
  is defined in <xref target="sec:tag"/>. 
The TLS client sets tag.last_message if further post handshake authentications are expected.
Similarly the CS sets the tag.last_message if further post handshake authentications are permitted. 
Note that it is out of scope of this specification to specify the reasons, but it is RECOMMENEDED the CS sets life time to LURK session as well as limits the maximum number of post handshake authentications.</t>
  <t hangText="ephemeral">
  is defined in <xref target="sec:ephemeral"/> and ephemeral_method MUST be set to ‘secret_provided’ when the TLS handshake agreed an ECDHE or a PSK-ECDHE authentication. 
The ephemeral_method MUST be set to ‘no_secret’ when PSK the TLS handshake agreed on PSK authentication.</t>
  <t hangText="handshake">
  is defined in <xref target="sec:handshake"/> and post handshake authentication MUST be enabled by the TLS client.</t>
  <t hangText="cert">
  is defined in <xref target="sec:cert"/> and is used by the TLS client to indicate the expected certificate to be used to compute the signature as well as the certificate that is expected to be send further to the TLS server.</t>
  <t hangText="sig_algo">
  is defined in <xref target="sec:sig"/> and indicates the selected algorithm.</t>
  <t hangText="signature">
  is defined in <xref target="sec:sig"/>.</t>
</list></t>

</section>
<section anchor="sec:c_post_hand_auth" title="c_post_hand_auth">

<t>The c_post_hand_auth exchange enables a TLS client to perform post handshake authentication.</t>

<t>This exchange is followed by a c_register_ticket or a c_post_hand_and_app exchange.</t>

<figure><artwork><![CDATA[
struct{
  Tag tag 
  uint32 session_id
  Ephemeral = ephemeral     ## ephemeral_method = secret_provided
  Handshake handshake<0..2^32> // CertificateRequest
  LURKTLS13Certificate cert;
  SignatureScheme sig_algo;
}CPostHandAuthRequest


struct{
  Tag tag
  uint32 session_id
  Signature signature 
}CPostHandAuth
]]></artwork></figure>

<t>tag, sig_algo, cert, signature are described in <xref target="sec:c_init_post_hand_auth"/></t>

<t><list style="hanging">
  <t hangText="handshake">
  is defined in <xref target="sec:handshake"/> and is only composed of a CertificateRequest. 
However, post handshake authentication MUST be enabled by the TLS client.</t>
</list></t>

</section>
<section anchor="cinitcertverify" title="c_init_cert_verify">

<t>The c_init_cert_verify exchange occurs when the TLS client is being requested to authenticate during the TLS handshake.
According to <xref target="RFC8446"/> client authentication during the TLS handshake is not valid with a PSK or PSK based authentication. 
As a result, ECHDE needs to be agreed. 
In addition, as c_init_cert_verify initiates a LURK session, the ECDHE shared secrets have been generated by the TLS client as opposed to the CS.</t>

<t>The CS completes and returns the signature as described in <xref target="sec:sig"/>. 
When further LURK exchanges are expected, the CS generates also the Finished message in order to be able to complete the latter requests for post authentication.</t>

<t>This exchange is followed by a c_post_hand_auth exchange.</t>

<figure><artwork><![CDATA[
struct{
    uint8 tag;
    select (tag.last_exchange){
      case False:
        uint32 session_id;
    }
    FreshnessFunct freshness; 
    Ephemeral ephemeral;
    Handshake handshake<0..2^32>; //RFC8446 section 4
    LURKTLS13Certificate certificate; 
    SignatureScheme sig_algo; //RFC8446 section 4.2.3.
}CInitCertVerifyRequest

struct{
    uint8 tag;
    select (tag.last_exchange){
      case False:
        uint32 session_id;
    }
    Ephemeral ephemeral;
    Signature signature;
}CInitCertVerifyResponse
]]></artwork></figure>

<t>freshness, session_id are respectively defined in <xref target="sec:freshness"/> and <xref target="sec:session_id"/>.</t>

<t><list style="hanging">
  <t hangText="tag">
  is defined in <xref target="sec:tag"/>. The TLS client that does not expect an additional post handshake authentication MUST set it tag.last_message. 
A consequence is that a TLS client that does not enable post authentication MUST set the tag.last_message.<vspace />
The CS MUST set the tag.last_message when the TLS client does not enabled post handshake authentication or when no further post handshake authentication is expected.</t>
  <t hangText="ephemeral">
  is defined in <xref target="sec:ephemeral"/>. The TLS client MUST set the ephemeral_method to ‘secret_provided’.</t>
  <t hangText="handshake">
  is defined in <xref target="sec:handshake"/> and must be set to ECDHE agreed. Note that PSK may be proposed if these PSKs are not provisioned in the CS. The handshake messages are also in clear.</t>
</list></t>

</section>
<section anchor="sec:c_init_client_hello" title="c_init_client_hello">

<t>The c_init_ephemeral_binder exchange occurs when the  TLS client needs to generate the ClientHello as well as the early secrets.<vspace />
In fact the generation of the ClientHello may require the CS to generates the (EC)DHE  private key and returns the public part as well as the binder_key to generate the binders. 
On the other hand, the generation of the early secrets requires the ClientHello to be completed. 
As a result, the CS will be expected to complete the ClientHello from a potential partial ClientHello. 
More specifically, when binders are needed, the partial Client Hello does not contains the OfferedPsks structure, that is the PreSharedKeyExtension.<vspace />
The latter structure is simply stripped from the ClientHello, without any further changes, such as changing the lengths for example.<vspace />
It is entirely built by the CS and append as the last extension as described in section 4.2.11 of <xref target="RFC8446"/>. 
Note that extension_type as well as the 16 bit length of the OfferedPsks remain present.
The PreSharedKeyExtension structure of the ClientHello is built from a list of CPskIDs where each CPskID designates a PSK with an identifier managed by the CS of the TLS client. 
The PSK can be associated to a NewSessionTicket in which case the CPskID will be used to designate the NewSessionTicket and its associate identity structure.<vspace />
The reason for having CPskID as opposed to the identity structure is that nothing prevent identities of two different NewSessionTickets to be collide. 
CPskID are managed by the CS of the TLS client to prevent such collisions and are provided during the registration of the NewSessionTickets c_register_tickets (see <xref target="sec:c_register_tickets"/>). 
When the PSK is provisioned, the TLS client needs to be configured with it. 
When the CS is not able to generate the PreSharedKeyExtension an invalid_identity error SHOULD be raised.</t>

<t>Note that when PSK is not proposed or when PSK are not registered in the CS, the ClientHello is fully provided -  without the PreSharedKeyExtension or with a completed PreSharedKeyExtension extension. 
The CS is expected to be able to distinguish between the two by for example, comparing the length of the handshake provided in c_init_client_hello and the length indicated in the ClientHello.</t>

<t>Note that (EC)DHE may be generated when ECDHE or PSK-ECDHE authentication is proposed by the TLS client, while early secrets and binder_key can only be requested when PSK is proposed. 
When the TLS client requests the generation of a (EC)DHE private key, the KeyShareClietHello MAY contain a list of KeyShareEntry (defined in section 4.2.8 <xref target="RFC8446"/> ).
When provided, these structures contains the group but are being stripped the key_exchange_value, while all other fields - including the lengths - are left unchanged.<vspace />
When an error is found regarding the KeyShareClientHello, the CS SHOULD raise an invalid_ephemeral error.
Note that according to <xref target="sec:ephemeral"/> when the ephemeral_method is set to ‘no_secret’, the resulting list is empty.</t>

<t>This exchange is followed by a c_client_hello or a c_hand_and_app_secret.</t>

<figure><artwork><![CDATA[
struct{
  uint32 c_psk_id 
}CPskID

struct{
  uint32 session_id
  Freshness freshness 
  Ephemeral ephemeral ephemeral_method=secret_generate or no_secret
  Handshake handshake<0..2^32> //RFC8446 section 4
  CPskID c_psk_id_list<0..2^8-1>
  uint16 secret_request;
}CInitClientHello

struct{
  uint32 session_id
  Ephemeral ephemeral_list<0..2^16-1>
  Secret secret_list<0..2^16-1>;
}CInitClientHello
]]></artwork></figure>

<t>session_id, freshness and ephemeral, secret_request and secret_list are respectively defined in <xref target="sec:session_id"/>, <xref target="sec:freshness"/>, <xref target="sec:ephemeral"/>, <xref target="sec:secret_request"/> and <xref target="sec:secret"/>.</t>

<t><list style="hanging">
  <t hangText="ephemeral">
  is defined in <xref target="sec:ephemeral"/>. With a single ClientHello or partial ClientHello, ephemeral_method is set to secret_generate when ECDHE and PSK-ECDHE authentication are being proposed or no_secret when only PSK is proposed or when the ECDHE is generated by the TLS client.<vspace />
Note that even though the CLientHello requests multiple KeyShareENtries, a single ephemeral method is provided.</t>
  <t hangText="handshake">
  is defined in <xref target="sec:handshake"/>. When a partial ClientHello is provided, PSK or PSK-ECDHE MUST be enabled. 
When a ClientHello is provided, PSK or PSK-ECDHE may be proposed but with unprotected keys. 
ClientHello, HelloRetryRequest, ClientHello or ClientHello, HelloRetryRequest, partial ClientHello MAY be provided. 
However, there are cases this is not possible, typically when the HellRequestRetry does not contain a key_share extension, the (EC)DHE shared secret is generated with the (EC)DHE generated associated to the first ClientHello. 
When the (EC)DHE private key has been generated by the CS, the TLS client MUST use a c_early_secret LURK exchange as defined in <xref target="sec:c_client_hello"/> in order to ensure the CS is aware of the (EC)DHE shared secret to generate the further secrets.</t>
  <t hangText="c_psk_id">
  designate an 32 bit identifier for a PSK. 
This identifier is provided and managed by the CS of the TLS client to avoid collision of different PSK provided by different TLS servers.</t>
  <t hangText="c_psk_id_list">
  designates the list of CPskIDs. 
The list is used by the CS to build the OfferedPsks structure - including the PSKIdentity structure. 
The list of identities in the OfferedPsks MUST be the same as the one of the c_psk_id_list.</t>
  <t hangText="ephemeral_list">
  When contains the different values of (EC)DHE public parts - i.e. the KeyShareEntries when the ephemeral_method is set to secret_generated. 
When the ephemeral_method is set to no_secret, the list is an empty list by construction of the ephemeral structure (see <xref target="sec:ephemeral"/>).</t>
</list></t>

</section>
<section anchor="sec:c_client_hello" title="c_client_hello">

<t>The c_client_hello exchange occurs after a TLS server responds to a ClientHello generated using a c_init_client_hello defined in <xref target="sec:c_init_client_hello"/> is being responded a HelloRetryRequest by the TLS server.
While in some cases, re-initiating a LURK exchange with a _init_client_hello MAY be considered, this document RECOMMENDS to proceed as follows when a HelloRetryRequest is received:</t>

<t><list style="symbols">
  <t>If the first ClientHello has been generated via a c_init_client_hello, use c_client_hello to generate the second ClientHello</t>
  <t>If the first ClientHello has not been generated via a c_init_client_hello, consider generating the second ClientHello via c_init_client_hello.</t>
</list></t>

<t>This exchange is followed by a c_hand_and_app_secret.</t>

<figure><artwork><![CDATA[
struct{
  uint32 session_id
  Freshness freshness 
  Ephemeral ephemeral ephemeral_method=secret_generate or no_secret
  Handshake handshake<0..2^32> //RFC8446 section 4
  uint16 secret_request;
}CClientHello

struct{
  uint32 session_id
  Ephemeral ephemeral
  Secret secret_list<0..2^16-1>;
}CClientHello
]]></artwork></figure>

<t>session_id, ephemeral, secret_request and secret_list are respectively defined in <xref target="sec:session_id"/>, <xref target="sec:ephemeral"/>, <xref target="sec:secret_request"/> and <xref target="sec:secret"/>.</t>

<t><list style="hanging">
  <t hangText="handshake">
  is defined in <xref target="sec:handshake"/>. 
The handshake MUST contain a HelloRetryRequest and a ClientHello or partial ClientHello. 
The same restrictions as defined in <xref target="sec:c_init_client_hello"/> apply to the ClientHello</t>
</list></t>

</section>
<section anchor="sec:c_hand_and_app_secret" title="c_hand_and_app_secret">

<t>The c_hand_and_app_secret exchange occurs after a ServerHello is received and the TLS client request handshake secrets to decrypt (resp. encrypt) handshake messages sent by (resp. to) the server.<vspace />
Similarly the TLS client requests application secrets used to protect the TLS session as well as other secrets such as exporter secrets.</t>

<t>Upon receiption of the handshake the CS derives the handshake secrets and the server_handshake_traffic_secret as described in <xref target="RFC8446"/> section 7.3 to decrypt the encrypted messages.
The presence of a CertificateRequest indicates the TLS server expects the TLS client to authenticate via a CertificateVerify message. 
If the CS protects a private key associated to the TLS client, the CS MUST provides the necessary information to the TLS client client. 
Otherwise, the CertificateRequest is ignored by the CS.</t>

<t>When the CS generates the signature, the presence of the certificate, the signature and sig_algo is indicated by setting tag.cert_request. 
Unlike on the TLS server, where the TLS server indicates the certificate to chose  as well as the signature scheme to select, on the TLS client, such decision is left to the CS. 
The choice of the signature algorithm and certificate is performed by the CS as described in <xref target="RFC8446"/> section 4.4.2.3.  <vspace />
When resumption_master_secret is requested by the TLS client, or when further exchanges between teh TLS client and the CS are expected, the CS generates the CertificateVerify and Finished message to synchronize the TLS handshake context. 
The Certificate, respectively CertificateVerify and Finished message are generated as described in <xref target="RFC8446"/> section 4.4.2, section 4.4.3, and section 4.4.4.</t>

<t>This exchange is followed by a c_post_hand_auth, c_register_ticket exchange.</t>

<figure><artwork><![CDATA[
struct{
  uint8 tag;
  uint32 session_id;
  Ephemeral ephemeral; 
  Handshake handshake<0..2^32>; //RFC8446 section 4
  uint16 secret_request;
}CHandAndAppSecretRequest

struct{
  uint8 tag;
  uint32 session_id;
  Secret secret_list<0..2^16-1>;
  select( tag.cert_request){
    case true: 
      LURKTLS13Certificate certificate;
      SignatureScheme sig_algo;  
      Signature signature;
  } 
}CHandAndAppSecretRequest

]]></artwork></figure>

<t>session_id, secret_request certificate signature, and secret_list are respectively described in <xref target="sec:session_id"/>, <xref target="sec:secret_request"/>, <xref target="sec:cert"/>, <xref target="sec:sig"/> and <xref target="sec:secret"/></t>

<t><list style="hanging">
  <t hangText="tag">
  is defined in <xref target="sec:tag"/> and indicates whether the further exchanges are expected or not. 
If the TLS client or the TLS server do not expect to perform session resumption or have not enabled post handshake authentication the tag.last_message SHOULD be set.</t>
  <t hangText="ephemeral">
  is defined in <xref target="sec:ephemeral"/>. Since ClientHello as already been sent, the purpose of the ephemeral is to provid ethe (EC)DHE shared secret to perform the key schedule and ephemeral_method MUST NOT be set to secret_generated.</t>
  <t hangText="handshake">
  is defined in <xref target="sec:handshake"/> and includes the ServerHello up to the server Finished. These messages are passed to the CS encrypted.</t>
  <t hangText="sig_algo">
  is defined in <xref target="sec:sig"/> and defines the algorithm chosen by the CS.</t>
</list></t>

</section>
<section anchor="sec:c_register_tickets" title="c_register_tickets">

<t>The c_register_ticket is only used when the TLS client intend to
perform session resumption. 
The LURK client MAY
provide one or multiple NewSessionTickets. These tickets will be
helpful for the session resumption to bind the PSK value to some
identities. 
As teh NewSessionTicket’s identities may collide when being provided by multiple TLS servers, the CS provides identities it manages to prevent such collisions (CPskID). 
One such CPskID is assigned to each ticket and is later used to designate that ticket (see <xref target="sec:c_init_client_hello"/>). 
When too many tickets are provided, the CS SHOULD raise a too_many_identities error.</t>

<figure><artwork><![CDATA[
struct {
  uint8 tag
  uint32 session_id
  NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1.
} RegisterTicketsRequest;

struct {
  uint8 tag
  uint32 session_id
  CPskID c_spk_id_list<0..2^8-1>
} RegisterTicketsResponse;

]]></artwork></figure>

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

<t>Security credentials as per say are the private key used to sign the
CertificateVerify when ECDHE authentication is performed as well as the
PSK when PSK or PSK-ECDHE authentication is used.</t>

<t>The protection of these credentials means that someone gaining access to
the CS MUST NOT be able to use that access from
anything else than the authentication of an TLS being established. In
other way, it MUST NOT leverage this for:
* any operations outside the scope of TLS session establishment.
* any operations on past established TLS sessions
* any operations on future TLS sessions
* any operations on establishing TLS sessions by another LURK client.</t>

<t>The CS outputs are limited to secrets as well as
NewSessionTickets. The design of TLS 1.3 make these output of limited
use outside the scope of TLS 1.3. Signature are signing data specific to
TLS 1.3 that makes the signature facility of limited interest outside
the scope of TLS 1.3. NewSessionTicket are only useful in a context of
TLS 1.3 authentication.</t>

<t>ECDHE and PSK-ECDHE provides perfect forward secrecy which prevents past
session to be decrypted as long as the secret keys that generated teh
ECDHE share secret are deleted after every TLS handshake. PSK
authentication does not provide perfect forward secrecy and
authentication relies on the PSK remaining sercet. The Cryptographic
Service does not reveal the PSK and instead limits its disclosure to
secrets that are generated from the PSK and hard to be reversed.</t>

<t>Future session may be impacted if an attacker is able to authenticate a
future session based on what it learns from a current session. ECDHE
authentication relies on cryptographic signature and an ongoing TLS
handshake. The robustness of the signature depends on the signature
scheme and the unpredictability of the TLS Handshake. PSK authentication
relies on not revealing the PSK. The CS does not
reveal the PSK. TLS 1.3 has been designed so secrets generated do not
disclose the PSK as a result, secrets provided by the Cryptographic do
not reveal the PSK. NewSessionTicket reveals the identity (ticket) of a PSK.
NewSessionTickets.ticket are expected to be public data. It value is
bound to the knowledge of the PSK. The Cryptographic does not output any
material that could help generate a PSK - the PSK itself or the
resumption_master_secret. In addition, the Cryptographic only generates
NewSessionTickets for the LURK client that initiates the key schedule
with CS with a specific way to generate ctx_id. This
prevents the leak of NewSessionTickets to an attacker gaining access to
a given CS.</t>

<t>If an the attacker get the NewSessionTicket, as well as access to the
CS of the TLS client it will be possible to proceed
to the establishment of a TLS session based on the PSK. In this case,
the CS cannot make the distinction between the
legitimate TLS client and teh attacker.  This corresponds to the case
where the TLS client is corrupted.</t>

<t>Note that when access to the CS on the TLS server
side, a similar attack may be performed. However the limitation to a
single re-use of the NewSessionTicket prevents the TLS server to proceed
to the authentication.</t>

<t>Attacks related to other TLS sessions are hard by design of TLS 1.3
that ensure a close binding between the TLS Handshake and the generated
secrets. In addition communications between the LURK client and the
CS cannot be derived from an observed TLS handshake
(freshness function). This makes attacks on other TLS sessions unlikely.</t>

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

</section>
<section anchor="acknowledgments" title="Acknowledgments">

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC8446;
&RFC2119;
&RFC8174;
&RFC7924;


    </references>

    <references title='Informative References'>

&I-D.mglt-lurk-lurk;
&I-D.mglt-lurk-tls12;


    </references>


<section anchor="annex" title="Annex">

<section anchor="sec:ex:srv:ecdhe" title="TLS server ECDHE  (no session resumption)">

<t>This section illustrates the most common exchange of a TLS client authenticates a TLS server with it certificate (ECDHE) without session resumption.</t>

<t>The TLS handshake is depicted below from {!RFC8446}}. 
For clarity as ECDHE authentication is performed, PSK related extensions ( psk_key_exchange_modes, pre_shared_key ) have been omitted.
In addition, as the TLS client is not authenticated,  CertificateRequest sent by the TLS server as well as Certificate and CertificateVerify sent by the TLS client have been removed.</t>

<figure><artwork><![CDATA[
TLS client                                   TLS Server

  Key  ^ ClientHello
  Exch | + key_share
       v + signature_algorithms ---------> 
                                           ServerHello  ^ Key
                                           + key_share  v Exch
                                 {EncryptedExtensions}    Server Params
                                         {Certificate}  ^
                                   {CertificateVerify}  | Auth
                                            {Finished}  v
                        <--------  [Application Data*]
    {Finished}              -------->
    [Application Data]      <------->  [Application Data]
]]></artwork></figure>

<t>The TLS server interacts with the CS with a s_init_cert_verify exchange in order to respond to the ClientHello.</t>

<t>Since there is no session resumption, the request indicates with the tag set to last_exchange that no subsequent messages are expected. 
As a result, no session_id is provided. 
The freshness function is set to sha256, the handshake is constituted with the appropriated messages with a modified server_random to provide PFS. The Certificate message is also omitted from the handshake and is instead provided in the certificate structure using a finger_print. 
The requested secrets are handshake and application secrets, that is h_s, h_c, a_s, and a_c. The signature scheme is ed25519.<vspace />
With authentication based on certificates, there are two ways to generate the shared secrets that is used as an input to the derive the secrets.
The ECDHE private key and shared secret may be generated by the CS as described in {sec:ex:srv:cs_generated}. 
On the other hand the ECDHE private key and shared secret may be generated by the TLS server as described in {tls_server_generated}</t>

<section anchor="sec:ex:srv:cs_generated" title="ecdhe generated on the CS">

<t>When the (EC)DHE private key and shared secrets are generated by the CS, the LURK client set the ephemeral_method to secret_generated.
The (EC)DHE group x25519 is specified in the handshake in the key_share extension. 
In return the CS provides the LURK client the public key so the TLS server can send the ServerHello to the TLS client.</t>

<t>In this scenario, the CS is the only entity that knows the private ECDHE key and the shared secret, and only the CS is able to compute the secrets.
The CS indicates the exchange is final by setting the tag to last_message, returns the x25519 public key that will be included in the ServerHello key_share extension, the signature sig that will be returned in the CertificateVerify message as well as the secrets that will be used to derive the appropriated keys.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  SInitCertVerifyRequest
    tag=last_exchange        -------->
    freshness = sha256
    ephemeral
      ephemeral_method = secret_generated
    handshake = handshake (x25519)
    certificate = finger_print
    secret_request = h_s, h_c, a_s, and a_c
    sig_algo = ed25519
                                   SInitCertVerifyResponse
                                     tag=last_exchange
                                     ephemeral
                                       key
                                         group = x25519, 
                                         key_exchange = public_key
                                     secret_list
                                     signature = sig
                             <--------- 
]]></artwork></figure>

</section>
<section anchor="sec:ex:srv:tls_server_generated" title="ecdhe generated by the TLS server">

<t>When the (EC)DHE private keys and the shared secrets are generated by the TLS server, the LURK client provides the shared secret to the CS as only the shared secret is necessary to generated the signature. 
This is indicated by the ephemeral_method set to secret_provided.
No (EC)DHE values are returned by the CS as these have already been generated by the TLS server. 
However, the TLS server has all the necessary material to generate the secrets and the only information that the CS owns and that is not known to et TLS server is the private key (associated to the certificate) used to generate the signature. 
This means that is session resumption were allowed, since it is based on PSK authentication derived from the resumption secret, these sessions could be authenticated by the TLS server without any implication from the CS.</t>

<t>In this scenario, the CS is the only entity that knows the private ECDHE key. 
Only the CS is able to generate the signature. 
Both the CS and the TLS server are able to compute all secrets. 
The CS indicates the exchange is final by setting the tag to last_message, returns the signature sig that will be returned in the CertificateVerify message as well as - when requested - the secrets that will be used to derive the appropriated keys.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  SInitCertVerifyRequest
    tag.last_exchange=True   -------->
    freshness = sha256
    ephemeral
      ephemeral_method = secret_provided
      key
        group = x25519
        shared_secret = shared_secret
    handshake = handshake
    certificate = finger_print
    secret_request = h_s, h_c, a_s, and a_c
    sig_algo = ed25519
                                   SInitCertVerifyResponse
                                     tag.last_exchange=True
                                     secret_list
                                     signature = sig
                                   <--------- 
]]></artwork></figure>

</section>
</section>
<section anchor="sec:ex:srv:ecdhe_s" title="TLS server ECDHE ( with session resumption )">

<t>When the TLS client is enabling session resumption, the TLS server is expected to generate some tickets that will be later used for later sessions. 
The generation of the tickets is based on the resumption_master_secret. 
To ensure protection of the authentication credential used for the session resumption, the CS necessarily must have generated the (EC)DHE keys and must not have provided the resumption_master_secret. 
In either other cases, the TLS client is able to compute the resumption_master_secret and so session resumption is out of control of the CS.
As a result, the CS sort of achieves a delegation to the TLS server.</t>

<t>In the remaining of this section, we consider the session resumption is performed by the CS.</t>

<t>ECDHE authentication is performed with the CS generating the private part of the (EC)DHE as described in {sec:ex:srv:cs_generated}. 
However, additional s_new_ticket exchanges are needed so the TLS server provides sufficient material to generate the tickets by the CS and retrieves the generated tickets by the CS. 
As result, the main difference with the scenario described in {sec:ex:srv:cs_generated} is that tag carries a session_id to identify the session between the TLS server and the CS.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  SInitCertVerifyRequest
    tag.last_exchange=False
    session_id = session_id_tls_server    -------->
    freshness = sha256
    ephemeral
      ephemeral_method = secret_generated
    handshake = handshake (x25519)
    certificate = finger_print
    secret_request = h_s, h_c, a_s, a_c
    sig_algo = ed25519
                                   SInitCertVerifyResponse
                                     tag.last_exchange=False
                                     session_id = session_id_cs
                                     ephemeral
                                       key
                                         group = x25519, 
                                         key_exchange = public_key
                                     secret_list 
                                     signature = sig
                             <--------- 
]]></artwork></figure>

<t>To enable session resumption, the TLS server needs to send NewSessionTickets to the TLS client. 
This exchange is taken from <xref target="RFC8446"/> and represented below:
~~~
TLS client                                   TLS Server
                          &lt;——–      [NewSessionTicket]
~~~</t>

<t>The TLS server requests NewSessionTicket to the CS by sending a SNewTicketRequest. 
The tag.last_exchange set to False indicates to the CS the TLS server is willing to request NewSessionTickets multiple times. 
The session_id is set to the value provided previously by the CS. 
This session_id will be used to associate the SNewTicketRequest to the specific context of teh TLS handshake.
handshake is the remaining handshake necessary to generate the secrets. In some cases, when the TLS client is authenticated, the TLS handshake contains a Certificate message that is carried in the certificate structure as opposed as to the handshake structure.
In our current case, the TLS client is not authenticated, so the certificate_type is set to ‘empty’. 
ticket_nbr is an indication of the number of requested NewSessionTicket, and secret_list indicates the requested secrets.
In our case the resumption_master_secret (r) will remain in the CS and will be anyway ignored by the CS, so the secret_request has its r bit unset.</t>

<t>As depicted below, the CS provides a list of tickets that could be later used in order to authenticate the TLS server using PSK or PSK-ECDHE authentication as describe din {sec:ex:srv:server-psk}.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  SNewTicketRequest
    tag.last_exchange=False
    session_id = session_id_cs
    handshake = client Finished
    certificate
      certificate_type = empty
    ticket_nbr
    secret_request  -------->
                                   SNewTicketResponse
                                     tag.last_exchange=False
                                     session_id = session_id_tls_server
                                     secret_list
                        <---------   ticket_list
]]></artwork></figure>

</section>
<section anchor="sec:ex:srv:server-psk" title="TLS server  PSK / PSK-ECDHE">

<t>PSK/PSK-ECDHE authentication is the method used for session resumption but can also be used outside the scope of session resumption.
In both cases, the PSK is hosted by the CS.</t>

<t>The PSK authentication can be illustrated by the exchange below:</t>

<figure><artwork><![CDATA[
TLS client                                   TLS Server
  ClientHello
  + key_share
  + psk_key_exchange_mode
  + pre_shared_key          -------->
                                                  ServerHello
                                             + pre_shared_key
                                                 + key_share
                                        {EncryptedExtensions}
                                                   {Finished}
                            <--------     [Application Data*]
]]></artwork></figure>

<t>The TLS client may propose to the TLS server multiple PSKs.</t>

<t>Each of these PSKs is associated a PskBindersEntry defined in <xref target="RFC8446"/> section 4.2.11.2. 
PskBindersEntry is computed similarly to the Finished message using the binder_key and the partial ClientHello. 
The TLS server is expected to pick a single PSK and validate the binder.
In case the binder does not validate the TLS Handshake is aborted. 
As a result, only one binder_key is expected to be requested by the TLS server as opposed to the TLS client. 
In this example we assume the psk_key_exchange_mode indicated by the TLS client supports PSK-ECDHE as well as PSK authentication. 
The presence of a pre_shared_key and a key_share extension in the ServerHello indicates that PSK-ECDHE has been selected.</t>

<t>While the TLS handshake is performed in one round trip, the TLS server and the CS have 2 LURK exchanges.
These exchanges are consecutive and performed in the scope of a LURK session. 
A first exchange (s_init_early_secret) validates the ClientHello receives by the TLS server and existence of the selected PSK (by the TLS server) is actually hosted by the CS.
Once the s_init_early_secret exchange succeeds, the TLS server starts building the ServerHello and requests the necessary parameters derived by the CS to complete the ServerHello with a second exchange (s_init_hand_and_apps).</t>

<t>The TLS server is expected to select a PSK, check the associated binder and proceed further. 
If the binder fails, it is not expected to proceed to another PSK, as a result, the TLS server is expected to initiates a single LURK session.</t>

<t>The SInitEarlySecretRequest structure provides the session_id that will be used later by the TLS server to identify the session with future inbound responses from the CS (session_id_server). 
The freshness function (sha256) is used to implement PFS together with the ClientHello.random. 
selected_identity indicates the PSK chosen by the TLS server among those proposed by the TLS client in its ClientHello.
The secrets requested by the TLS server are indicated in secret_request.
This example shows only the binder_key, but other early secrets may be requests as well.</t>

<t>The CS responds with a SInitEarlySecretResponse that contains the session_id_cs used later to identify the incoming packets associated to the LURK session and the binder_key.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  SInitEarlySecretRequest ---------->
    session_id = session_id_tls_server
    freshness = sha256
    selected_identity = 0
    handshake = ClientHello
    secret_request = b
                                   SInitEarlySecretResponse
                                     session_id = session_id_cs
                          <--------- secret_list = binder_key
]]></artwork></figure>

<t>To complete to the ServerHello exchange, the TLS server needs the handshake and application secrets. 
These secrets are requested via an s_hand_and_app_secret LURK exchange.</t>

<t>The SHandAndAppSecretRequest structure carries a tag with its last_exchange set to False to indicate the willingness of the TLS server to keep the session open and proceed to further LURK exchanges. 
In our case, this could mean the TLS server expects to request additional tickets. 
The session_id is set to session_id_cs, the value provided by the CS. 
ephemeral is in our case set the ephemeral_method to secret_generated as described in  <xref target="sec:ex:srv:ecdhe"/>.
The method (x25519) to generate the (EC)DHE is indicated in the handshake. 
The necessary handshake to derive the handshake and application secrets, as well the requested secrets are indicated in the secret_request structure.</t>

<t>The CS sets its tag.last_exchange to True to indicate the session will be closed after this exchange. 
This also means that no ticket will be provided by the CS. 
The CS returns the (EC)DHE public key as well as requested secrets in a SHandAndAppResponse structure similarly to what is being described in {sec:ex:srv:ecdhe}.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  SHandshakeAndAppRequest
    tag.last_exchange = False
    session_id = session_id_cs
    ephemeral
      ephemeral_method = secret_generated
    handshake = ServerHello(x25519) ... EncryptedExtensions
    secret_request = h_c, h_s, a_c, a_s -------> 
                                   SHandAndAppResponse
                                     tag.last_exchange = True
                                     session_id = session_id_tls_server
                                     ephemeral
                                       key
                                         group = x25519, 
                                         key_exchange = public_key
                          <--------- secret_list 
]]></artwork></figure>

</section>
<section anchor="sec:ex:clt:unauth:ecdhe" title="TLS client unauthenticated ECDHE">

<t>This section details the case where a TLS client establishes a TLS session authenticating the TLS server using ECDHE. 
The TLS client interacts with the CS in order to generate the (EC)DHE private part. 
While this section does not illustrates session resumption, the TLS client is configured to proceed to session resumption which will be described with further details in <xref target="sec:ex:clt:unauth:psk"/>.</t>

<t>The TLS handshake described in <xref target="RFC8446"/> is depicted below. 
In this example, the TLS client proposes a key_share extension to agree on a (EC)DHE shared secret, but does not propose any PSK.</t>

<figure><artwork><![CDATA[
TLS client                                   TLS Server

  Key  ^ ClientHello
  Exch | + key_share
       v + signature_algorithms ---------> 
                                           ServerHello  ^ Key
                                           + key_share  v Exch
                                 {EncryptedExtensions}    Server Params
                                         {Certificate}  ^
                                   {CertificateVerify}  | Auth
                                            {Finished}  v
                        <--------  [Application Data*]
    {Finished}              -------->
    [Application Data]      <------->  [Application Data]
]]></artwork></figure>

<t>If the TLS client generates the (EC)DHE private key, no interaction with the CS is needed as it will have the default PSK value as well as the (EC)DHE shared secrets necessary to proceed to the key schedule described in section 7.1 of <xref target="RFC8446"/>.</t>

<t>In this example, the TLS client requests the CS via a c_init_client_hello to generate the (EC)DHE private key and provide back the public part that will be placed into the key_share extension before being sent to the TLS server.</t>

<t>Like in any init methods, the TLS client indicates with session_id_tls_client the idnetifier of the session that is being assigned by the TLS client for future inbound LURK message responses sent by the CS. 
Similarly, the CS advertises its session_id_cs. 
freshness is set to sha256, and the ClientHello.random is generated as described in <xref target="sec:freshness"/>. 
handshake contains the ClientHello message to which the key_exchange of the KeyShareentries has been stripped off without changing the other fields. 
As PSK are not involved, no early secrets are involved and c_psk_list and secret_request are empty.</t>

<t>The CS provides the KeyShareEntries. 
The TLS client is able to build the ClientHello to the TLS server with ClientHello.random and by placing the KeyShareEntries.</t>

<figure><artwork><![CDATA[
TLS client                      
LURK client                              Cryptographic Service
  CInitClientHello
    session_id = session_id_tls_client
    freshness = sha256
    ephemeral
      ephemeral_method = secret_generated
    handshake = ClientHello(x25519, x488, ... )
    c_psk_id_list = []
    secret_request = []    ------>    
                                   CInitClientHello
                                     session_id=session_id_cs
                                     ephemeral_list
                                       key
                                         group = x25519, 
                                         key_exchange = public_key
                                       ephemeral_method = secret_generated
                                       key
                                         group = x488, 
                                         key_exchange = public_key
                                     secret_list=[]
]]></artwork></figure>

<t>Upon receiving the response from the TLS server, responds with a ServerHello followed by additional encrypted messages.</t>

<t>The TLS client needs the handshake secrets to decrypt these encrypted messages and send back the client Finished message.
In addition, the TLS client requests the application secrets to encrypt and decrypt the TLS session.
The secrets are requested via a c_hand_and_app_secret.</t>

<t>We assume the TLS client supports session resumption so, the tag.last_message is unset.<vspace />
The session_id takes the value advertises by each party during the previous c_init_client_hello exchange. 
Since the CS already has the (EC)DHE private keys, it will be able to derive the (EC)DHE shared secret and no information needs to be provided by the TLS client. 
As a result, ephemeral_method is set to no_secret. 
The handshake is composed of the messages sent by the TLS server.
As the TLS client does not have yet the messages are not decrypted, and are provided encrypted. 
The requested secrets are the handshake and application secrets.</t>

<t>The CS generates the handshake secrets and the associated key to decrypt the encrypted messages. 
As no CertificateRequest has been found, the CS does not compute the signature that would authenticate the TLS client. 
In this section, we assume the CS is ready to accept further exchanges, and in our case the c_register_tickets exchange to enable session resumption. 
Since session resumption is enabled, the CS computes the Finished message to generate the resumption_master_secret.</t>

<t>The CS returns the response by unsetting the tag.last_message and cert_request. 
The ephemeral is an empty list and secret_request returns the requested secrets.</t>

<figure><artwork><![CDATA[
TLS client                      
LURK client                              Cryptographic Service
  CHandAndAppSecretRequest
    tag.last_message=False
    session_id=session_id_cs
    ephemeral
      ephemeral_method = no_secret
    handshake = ServerHello, {EncryptedExtensions}...,{Finished}. 
    secret_request = h_c, h_s, a_c, a_s -------> 
                                   CHandAndAppSecretResponse       
                                     tag
                                       last_message=False
                                        cert_request=False
                                     session_id=session_id_tls_clt
                                     ephemeral_list = []
                                     secret_request = h_s, h_c, a_s, and a_c
]]></artwork></figure>

<t>Upon reception of the response, the TLS client generates the necessary keys to decrypt and encrypt the handshake message and terminates the TLS handshake. 
The TLS client is also able to decrypt and encrypt application traffic.</t>

<t>In this section, we assume that after some time, the TLS client receives a NewSessionTicket from the TLS server. 
The TLS client will then transmit the NewSessionTicket to the CS so that it can generate the associated PSK that will be used for the authentication.</t>

<t>As multiple NewSessionTickets may be sent, in this example, both TLS client and CS enable further additional registrations by unsetting tag.last_message.<vspace />
For each registered NewSessionTicket, the CS returns c_spk_id that will use for further references. 
The c_spk_ids are managed by the CS which can ensure the uniqueness of these references as opposed to using the ticket field that is assigned by the TLS server.</t>

<t><xref target="sec:ex:clt:unauth:psk"/> illustrates how session resumption is performed using PSK / PSK-ECDHE authentication.</t>

<figure><artwork><![CDATA[
TLS client                      
LURK client                              Cryptographic Service
  RegisterTicketsRequest
    tag.last_message=False
    session_id=session_id_cs
    ticket_list = [NewSessionTicket]  
                ---------------->
                                   RegisterTicketsResponse
                                     last_message=False
                                     session_id=session_id_tls_clt
                           <-------- c_spk_id_list = [nst_id]
]]></artwork></figure>

</section>
<section anchor="sec:ex:clt:unauth:psk" title="TLS client unauthenticated PSK / PSK-ECDHE">

<t>This section describes the intercation between a TLS client and a CS for a PSK-ECDHE TLS handshake. 
<xref target="sec:ex:clt:unauth:ecdhe"/> shows how the PSK may be provisioned during a ECDHE TLS handshake. 
The scenario described in this section presents a number of similarities to the one described in <xref target="sec:ex:clt:unauth:ecdhe"/>. 
As such, we expect the reader to be familiar with <xref target="sec:ex:clt:unauth:ecdhe"/> and will highlight the differences with <xref target="sec:ex:clt:unauth:ecdhe"/> to avoid to repeat the description.</t>

<t>In this section, the PSK is protected by the CS, but the (EC)DHE private keys are generated by the TLS client and as such are considered as unprotected. 
As the (EC)DHE secret are generated by the TLS client, the ephemeral_method is set to no_secret, and the key_share extension is fully provided in the ClientHello.
However, the ClientHello do not carry the PreSharedKeyExtension. 
Instead, this extension is built from the NewSessionTicket identifier nst_id provided in our case from a previous c_register_ticktes exchange (see <xref target="sec:ex:clt:unauth:ecdhe"/> }. 
The TLS client requests the binder_key associated to nst_id in order to be able to complete the binders.</t>

<t>Upon receiving the message, the CS, computes the binder_keys, complete the ClientHello in order to synchronize its TLS handshake with the TLS client (and the TLS server). 
As the CS does not generate any (EC)DHE, the ephemeral_list is empty.</t>

<figure><artwork><![CDATA[
TLS client                      
LURK client                              Cryptographic Service
  CInitClientHello
    session_id = session_id_tls_client
    freshness = sha256
    ephemeral
      ephemeral_method = no_secret
    handshake = ClientHello without PreSharedKeyExtension
    c_psk_id_list = [nst_id]
    secret_request = [b]    ------>    
                                   CInitClientHello
                                     session_id=session_id_cs
                                     ephemeral_list = []
                                     secret_list=[binder_key]
]]></artwork></figure>

<t>When the TLS client receives the responses from the TLS server, the handshake and application secrets are requested with a c_hand_and_app similarly to <xref target="sec:ex:clt:unauth:ecdhe"/>. 
The only difference here is that (EC)DHE have been generated by the TLS client and the shared secret needs to be provided to the CS as described below:</t>

<figure><artwork><![CDATA[
TLS client                      
LURK client                              Cryptographic Service
  CHandAndAppSecretRequest
    tag.last_message=False
    session_id=session_id_cs
    ephemeral
      ephemeral_method = secret_provided
      shared_secret
    handshake = ServerHello, {EncryptedExtensions}...,{Finished}. 
    secret_request = h_c, h_s, a_c, a_s -------> 
                                   CHandAndAppSecretResponse       
                                     tag
                                       last_message=False
                                        cert_request=False
                                     session_id=session_id_tls_clt
                                     ephemeral_list = []
                                     secret_request = h_s, h_c, a_s, and a_c
]]></artwork></figure>

<t>Upon receiving the response, the TLS client proceeds similarly to the TLS client described in <xref target="sec:ex:clt:unauth:ecdhe"/>.</t>

</section>
<section anchor="sec:ex:clt:auth:ecdhe" title="TLS client authenticated ECDHE">

<t>This section provides scenarios when the TLS client is authenticated during the TLS handshake. 
Post handshake authentication is detailed in <xref target="sec:ex:clt:auth:post"/></t>

<section anchor="ecdhe-or-proposed-psk-protected-by-the-cs" title="(EC)DHE or Proposed PSK protected by the CS">

<t>When the (EC)DHE part have been generated by the CS, or the proposed PSK are protected by the CS, the TLS client sends a ClientHello after a c_client_hello exchange with the CS (see <xref target="sec:ex:clt:unauth:psk"/> or <xref target="sec:ex:clt:unauth:ecdhe"/>). 
The request for TLS client authentication is indicated by a encrypted CertificateRequest sent by the TLS server as indicated below:</t>

<figure><artwork><![CDATA[
TLS client                                   TLS Server

  Key  ^ ClientHello
  Exch | + key_share
       v + signature_algorithms ---------> 
                                           ServerHello  ^ Key
                                           + key_share  v Exch
                                 {EncryptedExtensions}  ^ Server Params
                                 {CertificateRequest}   v
                                         {Certificate}  ^
                                   {CertificateVerify}  | Auth
                                            {Finished}  v
                        <--------  [Application Data*]
       ^ {Certificate}
  Auth | {CertificateVErify}
       v {Finished}              -------->
         [Application Data]      <------->  [Application Data]
]]></artwork></figure>

<t>The TLS client is unaware of the presence of the CertifcateRequest until it has decrypted the message with a key derived from the handshake secrets. 
As a result, the TLS client initiates a c_hand_an_app_secret exchange as described in <xref target="sec:ex:clt:unauth:psk"/> or <xref target="sec:ex:clt:unauth:ecdhe"/>.</t>

<t>The CS proceeds as described in <xref target="sec:ex:clt:unauth:psk"/> or <xref target="sec:ex:clt:unauth:ecdhe"/>. 
However, after the messages have been decrypted, the CS proceeds to the generation of the signature and returns the necessary information to build the CertificateVerify. 
The CS indicates their presence by setting tag.cert_request and returns the certificate, the sig_algo and sig as described below:</t>

<figure><artwork><![CDATA[
TLS client                      
LURK client                              Cryptographic Service
  CHandAndAppSecretRequest
    tag.last_message=False
    session_id=session_id_cs
    ephemeral
      ephemeral_method = secret_provided
      shared_secret
    handshake = ServerHello, {EncryptedExtensions}...,{Finished}. 
    secret_request = h_c, h_s, a_c, a_s -------> 
                                   CHandAndAppSecretResponse       
                                     tag
                                       last_message=False
                                       cert_request=True
                                     session_id=session_id_tls_clt
                                     ephemeral_list = []
                                     secret_request = h_s, h_c, a_s, and a_c
                                     certificate
                                       certificate_type = finger_print
                                     sig_algo = ed25519
                                     sig
]]></artwork></figure>

<t>Note that in the example above, (EC)DHE have not been generated by the CS, but the c_client_hello was motivated to propose a protected PSK. 
As the PSK has not been agreed for authentication by the TLS server, the TLS session does not provide PFS and the protection is similar as the one described in {sec:ex:clt:auth:ecdhe-certverify}, where the TLS client would have proposed directly ECDHE with (EC)DHE generated by the TLS client.</t>

</section>
<section anchor="sec:ex:clt:auth:ecdhe-certverify" title="(EC)DHE provided by the TLS client">

<t>This section considers a TLS client that proposes to authenticate the TLS server using ECDHE with (EC)DHE private parts being generated by the TLS client.</t>

<t>The TLS client does not need to interact with CS to build its ClientHello. 
Similarly, as the (EC)DHE private part have been generated by the TLS client, the TLS client is able to perform the key schedule and derive the necessary keys to decrypt the encrypted response from the TLS server. 
Upon receiving a CertificateRequest, the TLS client requests the CS to generate the signature needed to send the CertificateVerify.<vspace />
The exchange is very similar as the one s_init_cert_verify (see <xref target="sec:ex:srv:tls_server_generated"/>). 
As the (EC)DHE shared secret is generated by the TLS client, the ephemeral_method is necessarily set to secret_provided. 
The handshake is set to the ClientHello … server Finished, and the certificate carries the reference to the TLS client certificate, so the CS picks the appropriated private key. 
sig_algo designates the signature algorithm.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  CInitCertVerifyRequest
    tag.last_exchange=True   -------->
    freshness = sha256
    ephemeral
      ephemeral_method = secret_provided
      key
        group = x25519
        shared_secret = shared_secret
    handshake = hanshake
    certificate
      certificate_type = finger_print
    sig_algo = ed25519
                                   CInitCertVerifyResponse
                                     tag.last_exchange=True
                                     signature = sig
                                   <--------- 
]]></artwork></figure>

</section>
</section>
<section anchor="sec:ex:clt:auth:post" title="TLS client authenticated - post handshake authentication">

<t>Post handshake authentication may be requested at any time after the TLS handshake is completed as long as the TLS client has indicated its support with a post_handshake_authentication extension.</t>

<t>If the establishment of the TLS session did not required any interactions with the CS, post handshake authentication is performed with a c_init_post_hand_auth exchange as described in <xref target="sec:ex:clt:auth:init_post"/>. 
When the TLS handshake already required some interactions with the CS the post handshake authentication is performed using a c_post_hand_auth described in {sec:ex:clt:auth:post_continued}.</t>

<t>In some cases, both c_init_post_hand_auth and c_post_hand_auth can be used. 
When this is possible, c_post_hand_auth is preferred as the handshake context is already being provisioned in the CS.
On the other hand, when the shared secret is only known to the CS, c_init_post_hand_auth cannot be used instead.</t>

<section anchor="sec:ex:clt:auth:init_post" title="Initial Post Handshake Authentication">

<t>This situation describes the case where the TLS client has performed the TLS handshake without interacting with the CS. 
As a result, if involved PSK, (EC)DHE shared secrets are unprotected and hosted by the TLS client. 
Upon receiving a CertificateRequest, the TLS client sends session_id and freshness to initiate the LURK session. 
tag.last_message is set in order to accept future post handshake authentication request. 
ephemeral_method is set to secret_provide as the CS is unable to generate the (EC)DHE shared secret. 
handshake is set to the full handshake including the just received CertificateRequest message. 
The certificate represents the TLS client certificate to determine the private key involved in computing the signature. 
sig_algo specifies the signature algorithm.</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  CInitPostHandAuthRequest
    tag.last_message = False
    session_id = session_id_tls_client
    freshness = sha256
    ephemeral
      ephemeral_method = secret_provided
    handshake = ClientHello ... client Finished CertificateRequest
    certificate
      certificate_type = finger_print
     sig_algo   ---------------->
                                   CInitPostHandAuthResponse
                                     tag.last_message = False
                                     session_id = session_id_cs
                   <--------------   signature = sig 
        
]]></artwork></figure>

</section>
<section anchor="sec:ex:clt:auth:post_continued" title="Post Handshake Authentication">

<t>In this scenario, the post authentication is performed while a LURK session has already been set. 
Upon receiving the CertificateRequest, the TLS client proceeds similarly to the initial post handshake authentication as described in <xref target="sec:ex:clt:auth:init_post"/> except that the LURK session does not need to be initiated, the shared secret is already known to the CS and the handshake is only constituted of the remaining CertificateRequest message.<vspace />
As a result, the exchange is illustrated below:</t>

<figure><artwork><![CDATA[
TLS server                      
LURK client                              Cryptographic Service
  CInitPostHandAuthRequest
    tag.last_message = False
    session_id = session_id_tls_client
    handshake = CertificateRequest
    certificate
      certificate_type = finger_print
     sig_algo   ---------------->
                                   CInitPostHandAuthResponse
                                     tag.last_message = False
                                     session_id = session_id_cs
                   <--------------   signature = sig 
        
]]></artwork></figure>

</section>
</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIABTj/mAAA+2963bc1rUu+L+eAm3/CGkXaVOWL5G30q1Iclsjvh1TOXv0
yEg4wCqQRKsKqAOgRHFb3M/Sz9JP1vO61lwXoIqU4u2dNkdikVXAuq95/eac
R0dHs6EeVtWj4ru//vyX4vmboWr6um2K11VH/54UF21XHDw7fPndaXFy/Fnx
ZDtcVc1QL8oBvp+V5+dd9Zpf/0SemS3bRVOuodFlV14MR+vL1XC02navjoZV
f/LZ0aefz2b1pntUDN22Hx58+ukfP30wK7uqfFScVottVw83s+tLbnP26vpR
8aIZqq6phqNn2N4Mun5U9MNyNptt6kezouguFtWyH25wHjdVD58M7cL8WjdL
GLJ+0Lfd0FUXvfv7Zh38OXT1wj28aNdreNd9WzerunHdwETX5WZTN5f6yayE
9Wk7HBX+HMm/+CK08ey4+L6+LLerwX3OC/WsbOpqlXzZdtDwcxhP38Na66cw
wqqCEX714MvPi5dd2fTF07Ipl2Xxc7sdKvfcAhYSlrSsm6H4rtx2MI958T+e
+u/bJXT98LT49M9fmA+3zdDBe9yk+7xal/UKdpQGerzmgf4flYztGNYJtuPo
6Kgoz2F85WKYzV5e1T0u0RZXsFhW/aKrz6u+gAMUH7c/0Mn4Q3F9VS+uiqop
z1ewnDXuOzQFT/TFeTVcV1VTlPzuYlVjq2Wz1E/6qoNTCwsNHyxaePXNULQX
tCH+wBbX9XBlzvMxD3pdL5erajb7sHj547MfZ7OT42JxVS1e0VhhEOu6aVft
5U0BM9r21fK4+On0L0V5CRuxPIaf2YPjYt2+ruj5KxhUf1W+qmTOG+p4aOnL
/qx6s4AnLsNv7e+zz45hj8sBnqihi3JNd5Bepike4zjhTnTtckuLU/zyYV8t
jmr86DZd9ws4sb2uUuXWHBvVW/3LL//bz988/erhwy9ub4+LuImy7+EX3ji4
pktc5b64KNf1qi47XlJtyW1u2S2u6qFaDHDwoP3//cXRs2NPCfA/3NULu8nU
FDbxtLvZDC1MfgMnAshC97peVMXB09PDYlE2cBiKTdXBDNbVsji/oVdwBHoq
oKVqtcJ/zZeyetAnDdAtTFPQQbsooQfYpbJ4egrvlANsQtvJtHshTMWiq5CY
1OWql9NaN4vVdslbj6eibl63q9cwLjqJ+AksNPxz9Pzps2+fF9F5lJ19Vd3Q
waJd6evLBmhKQS00Re49mMWLht5clH0F5xxG2NO2woi3azlyOiLYS7ipOKaL
rl3LPupjZ+uyh+mfwRS7Cs4LzBP61kH1cA+W21UVHBFcDurhy+OTOTwKHcjb
3z/5v6Dp/7WtYdP7Gg4InI9N1w7yPEwOnzjHw7+qLuGML3GT6safG39AYVJ8
qh6k5wfpxQM4QHhUYQ22XUdnXU8sNbKUrVu0G1qhTBf+DjzgQcCu1/7O0Ek8
LWQp/RmyB8x8aWiSvIlnFXrv8DJD+w3ddJo4rnG/AErX1W1/XCR3zg6ha1d0
MvtNtagvbuDcVfBxp51024aGUdpBwMRKN2K4O8fFS376+7+evsQNgEsNnJF3
ALaquVxxRzSWb/CYhJQWZoH9D3CM5tTzZttt2j5eWaFtMBUYMJ6Eqh/kcPRz
6onPNq8KXvo53YF68QqOz8EP1fUpH+SX9MkhLjGcVLzn2w2u4UvkDXAgBvz3
0ZszGQYTk//8z/+cfXwkP+6X6Gfs86OPZ28L4KHQfPE2mo/+vNWD/pZmAv/I
yN/eod+P479nb/VgwS9ndVMPZ1XZrW70TmK/IF/wAIoj/w/8knl3UXXDGXyC
ZyV8l34Zexf51hn9f7M5c9Mc67cIX26q6zNZCrNYycv8AXYsxwp+4UHDJg4y
BKB0tqN00Obd6LWiCAc5+e6dFyt+d+9NKjIv06Ddu9M7bN692y6F73bVZU20
nneqH+lXN+ldTjTexF8eFR9G17QgdePxBz/q9bd0CChGcOs+KECaYQrfbNfn
cNKA1njCASJGVayAycC78+J8OxAduqwabZq4olAenbGh3EqKrqrydb26AWoF
/xFy/qppr1fV8tKRNySlXrADaagvL0l4ID4PQg5IEesNyDFEsvuxF4BIPUFZ
DNnvapjLs9GcrurLKxgKSSVHy2pTkf5yzByiRlpPchjI3cUaWqk3KxRQgNSS
XOKWjxtrQERFIUnEZ0eqU2aFzGyDm0Q7gUqT9Kx0vGfpRJfUkXIl3zg7GmNF
nKpc0aKSMMCMrKkWSNxBjIIOoBVki6WTXHYPkaWecrmscbHmU5PBaRPPvGkW
V13b1P9RpfsI7X1Tdz3x/Bq3hQdYdjeo+G1gnaFRFb5RKmz1eFUqFfqlKEnS
pSG41QB9tm3gcALPJzWSdqSrlJHC+mh7ToyN5yMf0+Rn/35Vw17DwsrBcedw
CTO9wsbLYtUOdPJBuybhu6d1uoG3+tbJZsv64qIimck9x9LPGk8rPL8utk0N
u07iAKhFXgfiC4my4XXbgYz1AUoUH8z53+KHH+n3n5//j7+++Pn5M/z99Nsn
333nfpnJE6ff/vjX75753/ybT3/8/vvnPzzjl+HTIvho9gFIkPANrs0HP/70
8sWPPzz57gOW3gKlpSOZ6bzie7SBjSJhc6aKKF3cPz/96f/9f04einT74OTk
jyDdiqh78uVD+AOErYZ7a5vVjfyJCzoDAgwMgIR02JBFuakHWOM5kZar9roB
wtJVx7NYsgMxv3d6ZS+C3jKUr7G7CZn3+dNvnz2fPUKtkQ6eNJhVMLR9GGak
5R08f3oIL6Tt0ElaqqTDWq6eQ9j3Mz5pXoo+UHXg4fGD46/w8NmeDlWlKJPL
N0Pt5KeuJaID43gSUU2v80fidWmFcdQ+ynopu/0BtrmRNj+g/aKBr3B6Q/GU
GvkWWEBLVoKyRqJbbPpXZzg1pZ1n6xYWJZzZH9OZ8VjgbPGaLLGN8KWTk/Qt
t3LHsyd2ZmYiH8gMUH+TSdRAPsLlgeftZHVBn/CGvc/15DNgVnNyII4On1KD
+y52djHH1ioZNR5JHfZV+RoGLgcXNmKPRRRbToGXC28RL+L7WkO5mfEqZten
qWrS7kbXiVS70WUiAUMUYqBXOCbZl54pmIwFRozzPi9pwwKaMecR+mVhc8+q
B83PzoS0vA55xDvsDTW4/+78BSZ7SvTnfdMNsnYw5fPkA9b6A6GTdycq96CV
758i+AV7v0faLJeea7tYuylGZr2nCYe/GJmFfaczKIOeWlY3WkspUP0rnpVD
WTwnk7Vf3Mz+9VsQrruhIKWxWMJbvGJs7Q4+dsOYPl+sfuIrYwfs5NP4hIE8
h2wCtObiWzc/Gf2jX3f4TnWnQbD+bvYTx4miJwnE37LZmQ3dKg0dXdGnt2LQ
/cQZoWtn7vYuBrbtidW8YmH/2kk++MQH5IT4QJWYjPkbWvAN1l52I7O1baoH
uQkXjVukw6geNfnqhLpJHCHWcIlfyby9kB6Ic1mjOsqfFy2s9XX/iC1iFWjP
xS/kyqEBFQcPDufwn88/P5zdFs/8uL+emWdBoC3P6xWoWlV/8Cm8gB+ir+vg
RP5IzU3UcCFfepPQwWf0Mf+YN6395OAhPsNfZmwcB58fzmlUZ+eomXbI9Q6+
iJrNmGUOvtRmU7PLwVdutIvg8z/6dvlLM46TT5NO7QKcnMTvxkaXgxNeJPna
3YKDk890V7wJbXYLZ/rks5c3mwo2x+7kJ5+w7lgvitflCtRz1CuR1C1JQFjB
nurJhMOkr9BxA845tIt2RR+qjZa2uN8uUAEuaIu3jRy2s6rr0Av8gLcAPRzQ
/vJsU96s2nJ5hn4YuBq4y7Pwgf5V8PcFDPGqgQ7Cx2QIwWdI4uGfASZeZL4I
P3Pq9xm6K9ZV8CXuTn2Bok1FzY19OfoS72zYIZ2F7MAdQQs+dXQt/HSDo+3K
VfBpTQ6mgXsc2vZsXTY3+mlNbmZ3ME4HmDcsJxMIORr2Sgdk6bFSpK/5OSCH
XznC9Lg4+RrIgaNFX0etRkSKH8Ev+moFLOfAPHD4i/cno3vqQLqdFyeHj9xX
+GNON/55Wwzu93dultdGG+7NX1uY+BcPi3opfzbw92cPilXVXA5XuAie9H5N
FJQ50akzqTAjeuRtLLfqwFHu693d/iHmIChDXMNuknHsiJx+5aJreyb6zqAX
WELRljT78MMiPHc6iuBD4IbRU8QNT74ozushYCTGDBI6VcL3z/gdYCzCQpd0
LdQdTM9AKyggeetgxpolDC8anB8QDHODJAzljsY2jiIM3ADvjIFfqg0b5kpL
Qd0T2lW5rsIO7Gqj0SZcZDYiV+XiKvL+kN60QRPYgPbK7TkycRiVEN79l5Je
IBPOk8DQp6Yzkg6iFQJhIVpbd4yadpBhDSSRWhefxy9E7V2VvZ0Q7p3MA5cQ
v8WVAZoDwlzb3WDnve0dhoh22AsxQQ7XaMqtgcHVpRvUuhrUZuqmJg77jLMQ
+xUjIPSApvRyhNIWxIlc99g+7Cr2SKuOVuV2vdmiWRkdr3gTy1W4fPNgYKB5
LMhSnB0UEM62Y1NvvrHI5zjqWcz5TmZviz/DeUKHC/4E7dInB4Z0i0jw9r49
fUpvF152Kg7OD4uJH/QcnfBLfEZFqhq68gL4onqeDqqzxWHw0gN+iZ+u3qDO
AD2GGAN4682hfemzoCevE8S9XWlv+NJDfon1u8mXev/S50FPINetxOgRvXb2
aXFQYm/40hdBT7te6vmlL2UhRpbgTbL8+NJX/NIoOuOgO0xf+uPRyef8Est/
eHRFzfiPqmtzm3uvYxT69LJcQv17Y1SeXHqBlz7uZXoMBXpSx1zzPzmCprQq
M+W79jgbd6vDafxoDv/t4b8l/V7S728+Et/6iFe8+2j63o1BAM7nFfUCtydp
gd/LO4dhnDTMdJTqmh5xwR+Nj1N8yyP+9z1ezC9pOsD8e0IoyKRAS0PLkl8c
mWL0jny1x4t3W9Q5bK+8mHe371ib+x7TjyLJzACyzo2cNjsyzzWtuymvGVXn
n5u87CQwjNz1RKyADxjLG/r1QZz1FjaWZN3ft+xkJNSa8+UnHtcAR2Q9r6HX
OfY6vcxZIwMZLot1e0g9rBFOW5IJJoEWOvOlMaEBDWbsHQ+fJFKeA1vqvRQD
/cLydJeVw+spDk/3SLEL0KYKU32LDTrvM10lZ8WXttdb2JXzikBf1yih5SAN
x/llQdFKneKIkTivcFAgNb2ul3mfteBcn56yNF03cJrKpcUg8pi9VjTVmgXa
kfHXvOdd5yA3rdslzLxK/OUVQSi3DbBh2MdqaaanIOEaz8uiwrG5NYvE0SZV
70UU5YPK9yFcV3O0sh7Y6GB1iLBulvTcLFQi/LW4xcdqNRCGu6VC/AVQnJwS
g514rdRAThIkLZ5HxGqi5RGt/dt6BaMaCArwY4yFfDQD0nNQHlqb/XEHnbVr
WZap/XUXlbGN9aIYEBYidtf4ViKNcDYkWIzz6gLlcz6UcNKAm/CjudUB/eQc
4Y04XJB9/10dE6G3+4ClJz7EGyI/6lg/xM1M8Bp40PHfv1Q35Gaxrguvey7K
Bq/SuVkNd1Fy60LYYdsUqSO9u06o5qyqYBgj6+VsTOTzh7mDTKtX/am3cpmx
kmIUjzZ/NzdlN+ix92vtmiK8Dg3YXSxdP6F8ZgCCZfEQ5UV2dJkp4oM4u5fB
KJziKS4HcQflusTFNZe+rPsqe+fFEFpfoKH0yr2O3tF22+RPHqwBUyFdNjuA
2lO/hPSMjqKQUXBn5XlfNQsiPqVt+2dhxzJI3vsl770dAs79GxCq+itYUo9r
U+uC7j+tX2aLcwcD6T42oIc1c2dGDitwMnJR4VgrICnIKSI8y0+nfzkj/AtS
fb6YAbcn9xzRD1oRud38oFPaFUmnopAbGVugeDlz7lsY6TkwosClReYLQ/xm
Slp686ZfUjoqo7stBo4f2qFSe1sA80f37ic+nGAejbqz5yE3AZEHt4LyW4KA
CsRzC9sf4O/QqhMt/LoartplT4452J6LwxG8UVux2CBxELlNgeHvuwl5L/o+
21BM7MNee4CzvDxk/AGjJc52nzd4ao7sg9AbODsneMhGBkP20s0Re00jC2h2
PtSorsSdTtW7qN4jD308pZDLT8iJYx0LAyy8MHJfBWhseBPqu92J4+Nj8lYT
xNiOrpyfzxfz5byaX4gKOqK4qQ7wvFlg7FK1fO6P3Cfxijhtb7y5DClPH0qb
G7M5oDGh5ull+NAn/NBi79GlbfxPXtlPzEP7T9YxINwH98cek80bSuzOjvZZ
zovLuLm8qm/lsNGDcp40N9bxb+OgjNl84lthJ++aq5Lm3vvo8oald5vsFAmA
ucrGhOcPJju/GGkutkId/ATycF2uDsMTCFx5cnSja+cbmRf0z8/V0N3IxOd3
bW5kdLvXLm85ywxoVw9vJ+xp5pzNi18yl+P2TpMN7ukvRby1t3DV7tLc82b5
4wXhvQjulX8ot3b3sAGONfeeGWNo4PP8Wax6iWFBzXhReA6OzSPJ3Fv/9unx
8YN/fPbgT8Unn4jJwxg8DhYrINqHwkb0/glTudBNSi/7TLzgFDCCMBD1gOsH
Yjg0T5D3+7MH5P1mDMVFTbGTpfnb4cXiWJRctDmZlv7arCpx2dugR3kfv5uL
7c6OpKku20GCLtlDioSkDkycwTiuMYYgUbAOMITkWIS9w8jwK7bZ1on5F6Qs
npOGaofDIiZDxdCAEiMO+Gf2DbzOtrfYW57OD71OIsT3GDvUqZVD+89bhNj8
RpZFICA3RnSn+FY2zvWRIc/0vMtoZx51knDsp3cn6DZaT6uNhDMmg9jeEvXH
E4KyGeCe93xKsKWfjxwRGhMJ6efGPJYXppLH8vQ7emw0qjMc22gAZ7a1XTMd
48tJa3mOljy250zzND54bM89nd0kXhx7vUQ7DHw45ol1eUNG/nN66KPJh1TR
POAoP3KliOpfXh6vStgUMQYdJq4gf+/UAWSJSkgliElEJDmA5Kh1/LwCMvSI
+toyHMu/wRgsoPzO+CuE3xuDuRP//cW2YWZTo6GUg+/Q0A20AwniddmJyXdx
A2LLN6ccywOr8poe7arNChaqHIZy8QrIRWL2HjFoZozg2QBSZj8CSAI5ZWBS
aV1Fzkv0Mt8uk9K8SRraVedRZkkyKHttdNLgKxwjb+gV7JFkO+g1+4MPqY3A
+ZEh2AgCU+s2PS9vThlpc7dDYmqOmK3E4Y6cnUuB8cGgdjuS/PgdpikOYRyZ
JprM9FDzJBCRckMZJa7KB59/wekkmL/xnfX3BI7YUNarUHIRSJnD5ocdhyuw
L7+bYne+7f0o4y5mZ7nTOK8zSQ8mWJ19apz+78fo7FPjfO4obmvHHKe43H5M
zvY4Pkf71DiL06f228eAwfljMMLbggeErYXMyD8hvMi80mTUlZdX1oxMoTOG
B41ETsi1Ovj0kNRKhujfFt9oVw4jbKVW9Cpvm8Yw1ph55OhvQM7NcOTiCQJN
Hn6caWGWafSxX8iDImziY0GEF5sLuOjd6w+KQ5nN7rnw+ZqP0dqxqfBM5HC6
EaYNzDJtBjMJmwhmslgNfiYifthpkwIVNnDoMuNghh5CFaDQXzNg9hyVQUUJ
WIwBkW1CNKCHBui+yX0QxL4Jf5HcZhT8ZLhM5EQhb68kxrJZsU6L14iyBf05
R3UO3VmnTQH5al1fXpEfl0YIEyPhz7t5rJmG1DcP4IggLV7FN7AJca6Z8TGM
JNwZXddXCNrewiRXrFfB2I9GV6C2uARh6BdbYO4BPMVxcpe1ipwjDgWOMqNz
gIvM6B3ifDKeu++tu77r6iBpBeaEqBuOdJF0bkEqCI17DNEEzs2Wl+vGEj55
ndwPXtxv+3VMoAzBZekaPULIQ+dfIFw3gR3CcP+uSiXKCOOUYhh8d+5d7c8P
8k5dkpXlI5CwhCk9EltI07oZkO+Qk63NXUDzxDniA/Gh9H4Wr4/QPHEV32VR
0kwk0mgun4Kzz9gbEz5CcdVl0yuODu48yev00Ck/4w7rXPPQOZlbG7ex42hZ
KeEMsUHUAlaeY77H2BmfQSlhvDLSOxH0HbzCibYc/qleRhs79AP0vPw/u3a7
KS7xv19z8Fu7Kf/Xtgq342+Ltu1AHcXAK47H+TsG5NipewaFNzV+vGCF1iVm
W1y1QNa432O2ZkFPG+Dn3cmcfv3sq4f66+cPTvDXN8DhT/4I/z58+BXvbdoN
ocZMIhc0Md4MyAEefqW/ffGF/qbf0jH9XD5GM+KmbYz5y5+Ws1y0Asd00FSE
+nHYtCgtuqOxV1yj9cOnAt9yMZOrEV9iIwjwxdhsz1f14hOFRvGVzl/g9Fq4
REIyK3Kg+wRQ3DbfEFicAARBiBvisfrydbtdLZUps2qlsCjDrp4Ku3KwIjse
x7mkZ4tn4umu6x5VTiTXNxsgKsjXI93Z4YB4QGpZKbOQMFW0+hqXgSAD4UWk
IaHLfr0ZbsIrfFFXK5Ppiv60p4H6lVyCuUAgfpRfGz8Mc1HPB7swCcBRbfW6
qpmz540CQoGFGiIGlgbVhyigHZRHGwsNB3oOiS3xWA2zmWs8UECIMfyFIZdE
uVJiKMIio05GYq/TcYaZHYQG2wA4vmKOo8HVwr1OmdZ8B4/2WCJO7uXXRqwN
fsszHNGJs0wW5s4WFaUUoRW1GUjWLgNJimq6ipErMQ1KAS1WX4rFHE2L6g63
MbTsg9L17d0Z+TLlTePwk/zP2/B3N4IzntFjlzhywi7ih/0W5Zy3XtB6a+jr
nrp29MGd7Ckf8+9H8sGNmeGdbC2uhaP0u/3sMDtb2GmjwX8nZhFrUkX6VHYd
rHUkennPFvZzb9ythQmbkFuHo5EWxu1F+7Zwv72wOTJ3G5omD8S7X4zAQGVd
f/5uAm2CDe9rtK8yX0QPa3zhA0MW264K+1hBXllkT0CWdzQV2rx8E2Lz8hqs
4+0ZR/39TF+OW0mCiFBnojwRscx48OCQbWS3Xrf+niby9WzmPlH4jiQXCB8U
NhAkAuCPDosoCUCi5QaJAEKVyUrWDFA4+eJPX/Mbt7PbYHQ9SObQ/C/7D8Fo
vsEYxmWLGXer3i3upfIZIMRigVzYQBvih0KPoftYhDWUALZGSbBJvY/HWiTY
Khz+nk9GCZt/RJnCCGxQvUHjVGu7Q2OJIpWJjPyhL1ZwkRmUH3wU2G3knbFs
Zti5H8loAA3l2XOCbxJYL72J+SWerEvraHO1p1aEqnld45AkvtbZ9vAlFKk4
YIIgvDI3gVyydNZbbwuJlRnel0k0Dl3lkg2bz20e4dTV1sNQjveRfqb8NaC2
7SSukzLF0Q6JwX0/Ig/c7OD2Rzt8Me778XTRk3z4aAeXPdrBQ492cEj3/Qj7
O9rN3LLggczFzvlZRh/O+lwQ2C6chynTe3G1oNP/5It0GF/nAGR04ZluvlSQ
0NDV1WtThkGn4VTUJFiAtQcEKlndAafn4nwUO1+0i8W2633mCamrYGNkML09
TA8Lo+jXgQNkd4jpl8dAxaSDqCXKcYHrxckqmnjEZI5CNYjNnMhObPwUMxIK
lJKSCdngqhHkExmRvJkmMAbk4qmycVCz2NhVBoMQ44Yxdz3CMixwfMgg315x
umJnsckk4z7C7EFio8kGr+Aq+fSXuKRxeQ6q5CJ98hIIMec5L9quI8mADfGw
B+UCc9GQr52eFRahJqzPjkNrPVz7rt10vI6+NVwOH6g1nt0EU3J1/aBOGUz4
dkZer7PMUtbDuIJsHx+BxHFU3SQYrhxCa1Kas2j/eJPsU9P5Huwkwr8obdj+
mNl837sQdjc6DuHVwXB24e4+cpNgPp2+PIHGOwqaCn/e0pJNovQmX9+F3XOz
FlYXD3wPRN/Uy/us98iSTaL/ds95AhO4++WdSMGpOU/gB6d7fqebNQsQgsnt
kUBBySNTrYcN4nJvJl9Rl5B9bzPcJLLGCPMZkTfwaRU47Jt5QPpLcguVQY77
6/LGlB3T41M2gWawSBmZwi5EF6bJkBoMMswl7BcQ8maQXImoybOeYrNrfk1d
Ujo6wyhfUlbDML3e6HNx/kKrFBcH8beJckqDttnxPvkEbYuSuzF81k4rUGEF
kQl6zhWd36/D9+zsw0R8VjowQ0WhrkilOpDrWBfXHHzxgojrj0/Vo/BUdZKw
wvYTJ5fASG1kWKQr8mx5so9AGnkoLjr+vKAvJCcg87quEuFZvPT+fULGeOdI
RiaiUhPB8/mkI1/+8cFDKQAwgHDTc3msjbp8QgSEyltHzoZfus9gOPrrEB0j
FaI85C+R5LBXmKa0cCaO3QShSLozvvuwWCOgZVVdDLKKshztdthIODh5vUB+
IQnVHpl4J/Mx+uOJNIxB4ZhF36G8FJEXftOSeCyqOM886CZdaTEdMKqnmjed
BVFsJnb/9AlAWjbr8pjYlrg4s9YIX0mkr+QQJY2hXYWKbajIaONBxNMTd8ZF
YVZSQi7I4lGOMKcoVWLSom/kmrMX5ELvnCspSH9gMD0kp5aDHw+VyiNTUT2w
A52sbJM4m8ii4TKSlJnwU13Fg76qNDtEbv5wag65+mB4oufFNUXN4AbhLZ3r
L9jty46BG3pYaWTnXDvGp3X+2aACqLm+hI1pcg1+gzn1d7T4aSqZw2ZxBqY+
kc89z5OoLUYyuUOBJzqCSTvBeuB8juVln17XlzyuXptVTBdnSFziNe+Fkdad
b1KxYngQ6PXZn+s4gaVkfhEcGR3ZS1i8xreindmcdmGUEbYfDymILaKqmVOZ
Gk06RluL04pZ2XcksSJdYa+i2OyJ9lbxNw+OvsRvfn5++vzn//n8WSzOZfoJ
BSK//yoW4baaYbPB/w6x/vGfk2pXQK6iCe4dpRj/uUvZ8mJ0JBjvUrTGXtyl
Y8Wid/DehLg/0d+kXjX53oRKtbu/uy3oLkVqYl0mdaj4vTP73l7recOwXWQY
h7s1p9H53feAhubV8nLUmMpfZVUZ/M5c2ZGQWofDChI8qw8vxv+5MCLPsrHu
WSU2Ikx81W61QKvPwubrOfkar/tYKJOSAjan7KeSIX4iZSyqS/TMVIZYl2p+
R0ZYSjmPz+1IAovFBWx7UylctdLAPulesQIBTyY/jS+lUkIxks8VKxDQ91qM
gTdX0v0H+qH/Rv2NXhlUICV/jsI6eze/Ojr509euVVGezNuPWPa72VRhfkUU
VGE/3bPY4qM00Z2kU+ID63IQypmtL9Vh6b4J8ub4jzln/5yKGjlQoQOeRxZT
kic0v3fUROBZ9JFip/rYKT81AugacSx+pimW/NBy9ZRHTLE2QZmbkkHQJ+2Y
lJi/hCkx+f09+kGB8TQps8smkd1ZLkEJ/0zWV8cJC+YU1riMNFbL1XnZgxTl
HjS67owiPaWLFKeJ2Gf4u/F9BCTKnYDJWLT98hqj0CGWYvvz1k186meEkezf
c0bceVt8ICVs5mpUTlScD5TVhly9CF4eS8/zwbsOmyhIDO929EcvmmIrkPxk
3Xd4xpAu6QtfFxKq82GSeT/yiI+WWUj9D17N8JEkSXs+lYPXQ4ibmkSjmZvT
h9UfbpkGpjsqxDD5Aqs0pE9LMog0HYVDG/haXMbBpSE47MESMKhxdsZxSzZw
IRMLzMUuJd+92HeSZC+CLQbt8ma0IJf6sYL42h5v10V9ue04fkQ8qAup13qx
7dCWZyKZsGqFWktCNQsVZSE3aL8ofH40r0LnslSIhnisvuOJ5uuLkS+c6cOk
vIhMPVIGyz+aTpy9h27ScYINwrxjOVGj4FBeDnsHf3ElTb7CZQjNw868pK26
GipkuCUDhLfYJoH3UjyF/uvCHb/BQGQfiCf4KQ9Cc/i0r3cmh8lSh1FzeGhB
dtMm1IBNQc39Jmy/vjwrV5ftGKAAKdLpC7iB2COTS5d15tdd6dGlVNGfZ4tg
Kktpw1l7avx1Zl6sRolAKAsze5Ss2T7Zi3npmP75Y9rDGcW/lIKJdo5HYOUT
UphCB8ezFz46cmg9oOOH6vqUn34pLRNdv65XKzT3SDIHH4xmTIVp9JpJi8PZ
oeiSpqNRpQqN3gOXTg5Curgy2g3H9q2qS7XdZVqKkAgejnJqR+y40Qt4pFwA
3apT4unCZzh6QdLisJVrpGCEVLYW/ECFFWxaNr5iheJ4bcPy5KFhJWKulEi8
WXmmtdQRm+XmZD19kLE8s0K+bLdDV3DTF5RrVy5JuDt8VAjsImQcPZbufQ6j
GV8XrnsqS7FpQcOrGbGQIAihVR27r7ZuF8YCHuK3S84szJxREhchcGT5GklZ
T+lznUE4z4FcVhbnuioyIXaeLM2y9OVeebqO70qKv5J7ftacd19PEWiQ/eDs
8aH7WT+c3X1Ge1DE+IzrEOOHswvwxfHJcTRYJp2iTPvpPppFVbR9aaxmuz7n
uMvMfXsR5vcVakIkEyUZeTf0xqMF3JR7Ss49pyYTaulkR5cwZmjb4qq+vDq2
UmtgBQ3EVvvNLZ693Bv3F12FSMdILJ9vmCX+dVU2SV6XCdE2zgesS5R91giz
QwpHTiKhmkwk1DFaS6ah2fo9zXVEhkuP+JjcFQlAUdf3uu+TN5ZkCEqByJdu
VDi68y3NNG3lE/Y9OSOj+nnc/cJiIJKqQU2hcEcI56ZsWRNOB9IB3hvneNMs
PhR/QWmLjN2P0asahp0ru3tcPIvzaJnjpfyFlBnsVuR+XzRXOLpUfHOQ+awF
1cxEjy80STWNXRUF7TFod8riepwLGr3PPWCFezwY0OMhXAm5TJJ0aWBuKsHF
+e8F20gnwQFf7RxM9bapEmYgYWQLKdf9zCXWzkxEO8M0pe1lV26uYNmR3tQL
Bk+Z7nUD8HBNDUXP3ljdtCBXm2qTfEJdeH+v8N+8l0ope84nLvba7HuUvFId
9FJnjyKtc8aDcoWIq5kAvBF3mmMZgUB5XJyistvjStFl7ovLLcypGSpPsW3q
RWScyjS3zasGxVmj5mMmfA93DcoH5k9OPnTEQYHLFCs8Fljr+ICjGHEKydFw
Fz5mQQ4fmmi5XNa+po9r3/EZpYmEuGmq/eNr/IBes5cos08RVESvFylFtsqk
DGpRb9CWkQb8FutyWFy5MRpAuehBnkonYd5xhYr98PRoaHyIdiHKj8GpQri9
qzP1iB1nJX5Live5jJEWYSSzDBkY1T1+XXvZb9v8JQXgR+1cE+JGxn7y/sUh
oCLQyBP432azQyC673h3iU25IVjBacqazvvkmH5wl0KMn+KAeq+ncCYeLYyh
yQrURUZJNERhgZM6MFmwaX2izEeaSVF7ijsqrdSG+Usl8QmC29r1ed24/Mm+
OxzYtvF/w2BBRH9e00HDArcueQpNo6uCp70rveWn9aH8fE411+U8WrtfZWqy
/jAOMz3dlJHULDqvycf80AjN+A1dXqC0cIsfYTnt6tGw6gXz8WixQhdnv12v
y67+jwSO5iKmA+UwgqL5x11Mj/PhaKYnZSweEUmHPfHPwc8/zO8OQd+02Wfx
e5dXqpEVCn1f/GCY2R5fowgteuUnPVOmXXntmS9laEZzAzMcwfaPDTIPztn5
Wu73Rt8cf43nSY6fQj0/hA/b3Vs6t7fha+lK5hFE0WukWPDP0dGfXtv2/y3Y
sPA1I4jAa9mjkRmrOy3O0JC8Er3OouETTrnkj0229Xz3wcL5NbaS1BhmKkV8
+fdfusJ6O/oPPtT3eV9UDLPvqOv448zia0NuGcc3Lx3OT4gof4J4t+ds6x1d
zn9kPstM62Pz7c5tST/L1R65Tzu5T+7RThZN+C7jsZ+OtJPCBP4UXrp4/7Ud
3EuvwL91nfsGP47ejHqWduwhLkw706ubthN9+jY9axl2sEc77lczDaEFnk3s
0c54nZvp9Rkbj1mNxB5+z3ZGP5lqJ4Gy5jGcv9p49LeUiN1vnadHsaud1yn0
e7QFjfrf0dHO8eRHEvwEIlvuw91NLFaRXIQ/XCVQvIcOKTsmXSpw1qqZp/hc
8awuL7ty7dPcGJkaM6T1HGLB6XSDbLqko1YsNUe+YxHE++Knv5z21kV51WoC
Q9QpnKYbvZ5kOhxJ22pwhcfx2F0b4szMiX42ekMzKnpjueShd52ZLIdG9GYz
tMstx5Vmh6ut9xvDfkiG+yCm3+eO68UUUgZSHY17A3pKg1WhjLnbmO9KlDFD
aFFSkNluy7brt5VfkZHFiAyUMLcWPbGB+TZJRxCYMePC004jGcn+mts3TtZs
RLUnaQAWvZyPfTpwEA5NstQfJlOLi836pHpmRE4PVfWSjq7Hx2UU3wYONr1m
TWGZgxxo/WJdyuYkTpbJDaoRW5a9oqY7grKjqcxu3+zb9rrKLT4q0dm7PgQV
TdFd1FerixSD4ay2Mk3Rv0sDN5aoyUrK4o6GoaFpgCBcoaEYI4/PLSrRZa+O
y11c+4TE6DdlQSJIP3TX1OJzHDInDKbrR7fDTazujdtaT28CU7QJtn9Es3Y6
cDJbSolqDzI0g0WroEA4dg042h7cYBOlaChPKjNFnY4cASEmbhl8lpdowOUK
xM/lDZND3InYmhFbtOOiLzvXOpKO3ErPfkQidF331XzvLRtrq5h9rzgWt/JF
Ngm71gpyB1Xr7nIeXnL1iGcC06e7MZmbU3ZVNL7xSRJu3VnS2n1OVubya0Lg
FDfmoFchIGwcmTR6EJAaKZGToF4R7zF2NEdOj+iXRPam3WP512xfJBLbHUtn
JZvkm5EC1E1bBOZP9hCbzK+B8VYdr6NpnKNVDngAtp5dPQMmI8cEUD4pLG9m
rb5VKgqO+8FFmMSJxXf7giJl4a6zww84CpBMqhQnuY6yR17THuW+1DxI2Rc5
21OWyrpcxtMVHIDErireA3GtKVMiPzd1QFGqphpDVCFJzMuz79F/pJ59RGTP
x5lsb3Z5wp7rSbIzg7O0WF/4T3TkILPlGvAV4jMWcfUr6FVVIAK6W+P4n8lS
8EgSkBBkYINxMuTMSObid8Oz5lm5u0O1u0SSZ0kxen59CIcYhRSgb4N929S3
IYGTZyI7zZga8pxDr1eAON6FN07RxlmsMSKNJxHd3in12CQtxR9bU0MylBaa
3tjl4ZzdoyrobAJriGMeRXTPbp8iggiNOOQRg3X0BUPNOsIz6ot7j8uYgVwX
mREJYLC8LDDfRQSs1lQVtylMid2zcZoIuKjqNt1x6Cz29NgzWKW545ko7tbF
BpNWYLmKMHE/56bYkmrQL1oNEKt7T9E0zwN/oFH7ZQ8tc7J7buTn509//P77
5z88f/b8WTD4VX2BVWvXpPaNuZdWMG+Z6Lp8U6+3awPLnJ7e8WzmL8DI3vmi
Mhyml1yQKIfBH6Lr8oeQ15ixKKsWNQD9dqMQFDk8Ozt3SX3/4BOfjnbdNpks
8rAm/sGRNYlDF6cZpo5RlYKMD3I2o1RQI92ZIMsoIjrUAIJcGw6UHSSz8kEC
om1vh1h6jzyXwetiE7GA73NOVeEuVA757wIxxmZILFGy6WdxpfgyiEVXa2mN
xzrVmtRISmRyFZxGZKYRCd6poGW05ipiTx4BFhtMASccNvNZ3suMaMz3IRgQ
e8QCrSJkpy8xCB/JcB6P8U9nfLm61u/A+XZxPZnuyGxHmFeWcc1dv3Ma2dze
h3yMZF70vjXUY0/ioRmO8DaSdEommXQlYbudZeg9EByjWxgLSKA65CwjUwoE
hidWqNV4tTi2S4zZg45nTxYLKkRE6YMCzJsqDuEkRy1LIvASPFINIB7gKBC1
5H4G+tzzp98+e+4N7OfKMWLIIpDIzFKNBQywyJ4pwrWnakMW2w2fEVNk6/0p
JKRc5yM2A1krUyGYIJNDDs4IvcC+ugA1tbsHll4pE+ysyxetCGbxNu1DR0cN
Tb9Hlhb3Dh99+hsPH83GhiaDthBCU9DYgKvZqGeKnyXk2xccZvItV8g1wZLH
bmUo0oVItHJ+A75plIV5TxWciX7PcZGxwoP0jYB6BoPOLpKJITSc+jm9hr6r
nHIVF9Ibey7LQaLed0nW6qFs2v30OSu74i7dRflJdiyYXSI95TQh7PLOusV6
2w9GwxHlSNiRV0eRtalR2xXP0zAU8okZY5JL5u0MlDw7PzjnEyQzEBJ3eHSx
qsrOydWpxzawSdpvQoukXyt2547LFll3d2CfDTLfR9n/rO9Xytli/HHGAxa3
pI6YuvPe5zbC7auRMkntYznviFt6CFzZyaT4K8TN/8jrwH5a3J35yOhDR3eQ
jshOjHmw8zLEco/MVQPQrZoX8GvbJLkeSuMLx8niv6FLOmPqpW2WufLppJpv
kpUoaEXQmhZ07Ou5/0jQ2uVP/ave1g5VZZXM+MDsSOL6S3Xz3Ee2MaUS6SNI
O9ZjHfobyg+02di0QGZWc5Iu0QKEFUKVACUpLugDFwVNSXdZwqnelLimdDRZ
rYYF7JDpYBZQm6iU3FGbDZVz8AENYTGZQK6z7PvkBA+JlagDO5ZrhPJmxaf0
5AsKipBcwXLY7IJ31Rqz7GqJRlrQ7Gqb9c3cOFQdaNJynKicDjz3FDp58awX
THlVwpLyR4WJSWb5XstLcujQRU0O1QaIWAAOj51eYljCBsR5Hfo6y4xnK3Ez
y5D03vjayDLEvIesFOe/69BHPbm10jPKVkM6NqAr4GmSPlOdIG3EsXssZ4jv
qh/KlDjChbluDU49k5xCiMdqhZV3ipmOAKtx715o6//iiqfYkMRGNktFa0RF
r1MXR24p+xzYLkiUG397e3uoCo9zcfaWNSauQasNmngfOnX1YBtLi1uELsXs
7TAhfW4Dk5i+subEHeb6OitnHcBglk420vgO/DLnmkyq3JNOtcX0SG47jgpH
6sZngB0Kdkn5y8iTNpPSS7dgkVFR124JI4azsAWtMnAp4mmF42YIKZdELbuQ
1uqZ8bKNDSHMiTHqINNyyGKRHAmVNXuhIoHIYV6VN2CXqTBLW/g445dkx2sK
aTOSBJIwMibZKPLgjGgH9sCOgftimFAG2cenx5bIlUOEnkRNwe7JeVgw7sAI
v5ZjfRXafw7F7e+rEbFUa/KYBfIAl1Y9l9zsbJFyjBwfCKK8KXeELi4GDrGw
RRlJsPAOZ/aO+fcRtU1J4UGzp5Yo9f6/SwEjKbPUS5A1XLyyc41kKgonhV/x
qk/VfTXHrgwtZ7HTxknTiY7iU3Ebv4k6llEixDa1sB1VJtjLkB1cJrFiZ0I6
EoOMqP6LM6m9hcZa5DCz9JnA0OuMLGEGiYyxIK1d24cFDnG4vorxveIqhSvq
LExwI+YsnY2HXbK1wh+JXdPOzC+OpJztjrRMepVMqtrR3Cxq4P6bRzPgYs6+
mz1MKdZoMk/NK/P0MM/dm7bryBLDWfAD/X4f9f7fFSvXXK5ChojWyFSpmU9d
qPhcGQ6AQx1lAZ5iWUbuS5VSO0ThI3oeoLUdrnJH4KPRAl7Tq+32UlCl39lM
NMITXJIoR8Z/wExm/dwvW1Lu2lawKO7kHJGsh2Vu7W2z8zR9QeQAUV5X3qGJ
2JaC7ITEGxufisgiFITtoUjySc7js7Tr8dx8fdCxLqVFCYuXirGLBEFQaVBi
U+emfpw7JdiydMphkLF6nU9/OYHRCo+cgyjrs7ZmYIwnvag7oBmhaOUElIzg
4YPv98H10YHYcvDxRKqOpBQLKw+BKes28GiYgnosxZbXpddw84sUKwRqOfCm
KsQDCP+Ae+LVSJAHgAtQ+gKv5F4ocELDz813Nm00GRP309PK12299AoaZe9y
iiFeFVt7yH/jff6U8yFggXYeYsIIVXzRBVTcSPO+c2mUUYNPIqrBOF9k9Gnf
C/Sd1vi1bdvcI325rtQogjk+ZN2COZJ/KmTGMG06xYGAmpQygcYygSwkfR7D
kK3MiJIzDncfqS5iQoHMP/Ga4zZzv0815bohGZA/OL8hhwKtq7VDOvrvN8Yo
4obhHtJqkSU5a0TO2o/zMTFiNi4v0IxXWgx0UNIyIKieanA69XwMUoYYpMbt
W+v41kxsZSaxcBJfg4oNqh2o/7RrIeBzaOVIfMg8spBGiZKdGa0wCV/eJk7a
oECzZ6dsjeFcK75grVZESoduApceYXk9AY8nVDtHlsNoCzPgOZHkaFdj6pgG
OO3q3tWr3msILn+FartCPtJ+BeOftHG8h050B/3nN6zbjKou76a27KOmTKoo
/2yl5P4ayJ3k3Vnog+N0dU4USy8lmU330FS0qASyMJg8MBDB6ufFnRyFw5SB
Nw51YnpUINF4RrZ8lTKl6Ln3xgi7jWI0BCkXhKX771dTLWZkl19gbjsuuoNF
kenPw5z7k7I6nN/oo0N7KMSBkY1FhDrOWdJstkUdhHoIRJUwbCGB97ZWNnRO
Jc3c5YVGW4R6Y1lyGKVFGZE6l105XR9dzB11Z/Yt+/2ZXXCSEHi1PUKoZ6eR
zSSXjXgLkaG5VMypHGuhZ8wDpiIafXFq2Zc+rtySDYNT++xgUA9BSu196/85
j1QUEpdbjD6uBsfBKdYJEfqrTcTtcJUm7jMwoTgOj2ioAnixY2cQtymekyqR
WH2ifpUpdDEXb160jeOFdNH9fIWxvbF3MimTQ0Ivwo7maUYw8cjCWawlCybb
bz2UTmrDXLW1XxezDApBpgWx40MtywUSGq/tvon8EGKFKCbevfGE5zYeMuMf
UAtQnDiv936T6iofirUL3hedQrk5+H6C98MtuGkWV13b1P+RC3MMKx09tecu
4Mx79hfm99p/zefBn5/NVVSw6RXvjDacZ3DcJu3fZPhTFvmWQ7wVO4S3MYDg
qPS2R7q/3SPdIcEpHvAgoRQ2LAn6w9LUPg/HJJxR81+N4hmL+AkLDyyK22Jq
8omUGYmWQalvT1z3kDhTAG5G5owFTP2cg0HmRRw4EcqeDEGcQiBG0RZAOQbN
FZISkCDLP+kRQzaCuO1iqr5sLaBxuloCgxuqOwAAyREcAwu9w7ynCOO7uQE4
KDPClWl4vCQGVW6/2XaUcyIxftQS7otCQFFNmgJ1PcQx6euBjQdbhYXoUyvP
3fQOOQhSvxiHYeXs7UYZpGyoEmBCDPYRUnBT9gE63Ut7bNU0BVmmw4BcReor
y3hJCmhCiYe0jwT8oapHgvtQvSOm0kGd6WxwA3At5JftbDKqHluPUu7ORBhk
u2Hn3SgJjEXX1BU4YEDRDLSwzcV2RaZe3ork7qCBtBZ+jhZaLomAx6NdVzNv
52TIHwoCce9/6K05FP0fAvURoJ56pZzh183D2H2d7OAEYGtiHcQAHQTDx2Cg
AzYIHxL8seKvxalaE1gKaC2fMYKDDQZM1UvpmxwAq9TyGCEwKKPsemRQi1DQ
5sbth8UojXjs8aUzfOnMTJxd9mltE5tCN2creR8FPn6Wgy5HzJckucM4nE+7
3+R82plOtJQIc9EPUTqgtAZYDJHMbRyAOpu5L4CILRlBSnYJLCCL5cXLLkzG
gyRStxc3F7+cpaKi9bemIBsnrIf6xIxghAqW2YHUkRpKoruSuuiVbjRrmvlo
hQ84g3gdkQ5cljWVscRE0VjSpJ1Z9VEovGKgtr2HerAtsF3P4Iwxmq9a8ddM
smKI/AUa7vGG8gWGvYdWhYK/aGZsXrgub7iCg3a+Qt8iifNXJPR2j2YfEczV
lN00ldF9ALS1Yri+1gQNTRvA5P6IY/Vjsu/32TcutiTI7XzONYqztk+T5N7w
vA2l9oFUMK/NVm47BVfLaVMDiTszszwBF7Kjq3Fy/BlQkVdahZ5bxy+l7dmW
P82v5QnqhqdBMGIvFVCpqoOriwEnSHujo4JdxlryRbng4l6+d07egfKsDGGW
H0KKXtUqWTB85E1ko9Tyou2FG0waCZuDQTh2gXcTJUUpfsarvrgRxK3wjJ7O
jQrnAhgUIxPf6lWLd0uDiEnWQmc9L41XF4EPzkxAnj7KIZ8MYWTjI16Hmzgj
GQx/FkclmnRkxPPH5gOtxO921YqQuB6SyuBqwq9V3QKFWTqitjDHTAtzuJ5x
iUAE1TZYugPiXC41VQD+f1n3mLmQnNftzBlHNW+aXyKHfNfGrnAavOTYVSd0
8Bu+l7ongp+o15tyIRXUMJppGEo4PZ2t3BYY6crZRdiOqyhwLUkXMAal6RUn
TrlmKJWE5Mym3Rxf2UVQ1CS0cRF28rIVejEzG42r3rXn234gB0xiGuKCCW7r
fHy6mKXU0ILYkQo0rkGL7Bnv+7fBuYquzczPwG+xcXTLwTh1p2AWnoJjR4mc
f46JFKoinrT5XWe1bSanxOdCKm24iL5mhcIhPqDQ1Cw9lhmCwg/wlXUQ6AOW
eA7ZKowvZoju4ClSBCIWbzonZnwxuEJhs3OCZYqegiVWQNe8dIqcX9FoJnLF
hIYD05mtUeCsaWIlAme2K7ghIK57JyZHJxy5JZTUbCzKz8asfcico+Io4WCI
9joLXboqTlmw2gjHxLj45FjnnJFvmSKAGAunzAXkg8AxuxjeUKkaNI/NHFHG
5uB6vsrVg2MXvKEAqQBUFpc1wtBYr3tBBIMkGveKBNvFbc+tHOfaY8kwh3Cp
fY1Nl7zf+8NncioC6YXPnxVuHGFyB+aF1JdAS9ZcxTnJC6YCgMDZWVY0cPbZ
CiToocbTlFhoQVfTJQAtmiySi7az0AYymEOvs9CwbgutdN12M2SDB4IFI/kn
qUyNcgGD/MjZJcNJkugdFwJKE9wIMBvn6ihnghDsqqOtN5kkVCA4TFE2u3B/
MrHhT2hcaCZfqZOG5bxA/kM6QUzs/CYV1WYMh2RYV8nZfUmzxrMapzTzVlil
8I6CKksN7jEGKKy3jcsuZNuLa2vK6fV55YIK9cirzmlplqFUMjvwQIGLLR+0
Q76oIhKWskioHKSLsyWnzYqQ3h8WL5788CRR2T4siicLpZl4OeCzo6MjuBGL
V/jtk6ap3pBhxuwfS1nFQdNmrBeHYq+p3jzqu9ePqsXyqrqN6qHDhd1SHJDQ
rTUaBnE9KaBEHcZ6S9OcES53iwxIAncCM+4BjfLQBbtkLTwui1WQcgJEgJoz
tFWYPY02KQy5+4ZKpJWk7AKd2qmczkUE5KNsKskdjJSqm8fFsA5NXolWUlgl
CSxSYkGRS7aQ5TxbIUBd49FFNaTY2u3xSKdqetyGS0SpwwYJuH3NZAstCeaZ
3T/4MJsyZ7MCAXRYTsHiSIriOSxg8bb42ONcNRHBa/jQyXFnzgTZ+8opf1Lv
wl4/1qYKw4DR3OVtM0AcGg579+u/PFfjqwu96m/9WIqfsLBev/8wfjH7B+38
Y583f0n2/BZTtlPynb07xnbU7Ayvvx590xVsKIq/PTGwi2cg/33091nckP1x
u0pPJW//PezgT7lHfE3PwKvNuTH7MDu7yFcTeXYsylh4fQZ/49NIDsT66fpm
6JZG9cRQCjcoTFghDoWwJpoEjhb99pzTRwyhyd/kUwhiyf0wMJYnDAPANUrZ
lEWuXpUPPv9iHkFUuGIcyE/DNsCXlxuE6XcMzHCDkzUG0ohY6KUCWjpoDjVa
V/a8+OkbSX9g6ZVLXyO5bYR+enX4KuD9BItgJTuuUBj4CR0oVlGnF/APjApG
72KRvZPfmZy6uL8MqMhHvF+dwR9XZwug7/gbPX+24DkmkAn0by8ffP75yR8p
fo0WLWRKTtI1M+lt3AGGYmJZzBS7GWY50vGR/bbsObwNFSk51yzhGJuNQIPU
RBTmWQg9aUnM5QQOw4gai947zm5zCRfoz3cZQMgaw4FgGQg5ln4UKDl9WJAM
ZFprHawnEJWC8c+mIyaSMfdjNdTmiUQ6leckcUDSprmgD4rGfEMnrPDJMf39
MPe7UY00jjnhxFucWSPxMKVKrlP8SblN0uBjlCzlLBwiZ2cCySJFVNS6flE1
IL35UM1aowEwjy6bK+iEo2jcB04LPj+6B8nN4CtK7fimbaKs7ZC5FfhYAJkK
YCo1Zgyy+Cyh8Urfhb7Ng3Qlsktm8VhNFGVZnMRu5+zSjQYK9RZ7EbanNWpd
YPUYNi/BfVmCkmZdcFQkYAwSrOUFSTkN2Z+ZPVCTP9kyyYiHyWfMwldgHx6H
TDYrhHgO+VgYIn0cVtIsJhI3emUUn/P37LH5/YD3/JAxOIZVPQ5Yk2T0CgAw
j0cYDT+rgMHHyl72kfeSRZOMXXu8mlnW/V6L13Pnz6u7yO5M/h7L1ZrfQWew
Ch40wJfybO/ODQZpzxfcRX2Mv0+/5EujFeLizfCslAMGvGuE+03xsD5PQEcY
WVzIxt7pgHskoBwvOTiqnAQ6BkXDjUvJ0jwXkhehZrOsNMTzOHF59kPrlkLi
xRhTJsQzEHQG8jGS/hxglibWJooltdvFlUHYaO+n603eaahOACGntQsgz4TC
ECvjdaNPls7swMXOEdoxBEpUyE6RMR2kWGxDvQ4dNwgHGO+LccyT8pHAaq5J
xmXIJyaFpeR5nOlUpeLUWxOa6ljxinL7uxwWandjz8F5FVpeMlfI5pzCJFXa
p89Qdfq+pRaSi7PCyejq/rn1yq4Nz1BJuKsSAQcPmo9m+CdJOO9bGjliG7pX
2Y7eXUD5LcgnYcbOxy+7LQop71k+MYml8ceytpBtuo/FuClE+HH497iU868h
3GT25LcgCvBPRiBIzf8HbJTJ0NmcB+Csv83XfKulwBYDI/KmrpB7WLewo1kU
cqvQvuCmGhQhelH5TyXVQpzSHIzalGUOIfGPXbyzly6DQAIhS0qrOTyZHxiT
mvwCYKE7Ydn16obTiJJcEIoqKlk44YoeRF5MDztj1o6JvHDFJtl0IpHM6cbl
1NrRiBeyWOTMmab0BkKOunblkgqeHmdzWvYtF/ErF1d19ZqcQYjwuUxisXzR
ghe6fQrCcfU9eKPmwAV8+HB+L0ZigwwMagKdaC3GUXTyVG3Cu9i7nORnq52d
NdV1HL1iM3RmTCpOnO63GCQoxbRG5ES9KGGCS9jwjrdmCLSI5Gm2NNv9pRSU
mlVhUfmFU+lnzwVxiRJRjliUHWVaKK0dG6tscHqNm2DHY8+wyjmm2NVvka9T
8m1hf26Oj80fZ15Jw6f+uxsofkv826/9zp+xzVns6b371zdx7Nnpu9k4iFsT
A9tD6nD5QsnSnIVDJbbmJNpwgBsgql0Qycj0UpLuKujg0Tu5yPdYB/7zb/Fc
8o5PF/+eBjE4+0pQ5PQUHuQnfMGTl1dVenPUUEIXyGqIrt1UAETJTjIkKnXI
1JvUgBYsuaVyXujE7P34GUvoBKS0pqBEFHvDwhkVJAmVQZ/8lyzq8Rq44CtF
4nmEtYvmNUVUAl9pKLz4r7KGq8C/gJglm5BmpNhLBBLRB8JQX8p6VGZ9q2p3
YU67w2FqEh2Xbq9N+gKX4QnltnbbOWgwwfEyo8/AXPrEkMRJsU2iTEqBhJn8
JRSnOe8kOZIcRCPB+zJs3j6QwS5GAaOhySNxBvv5afbpUfH5oDvk8yZJuk05
0safxLK5QXhnkk7ALUfEVbVKbEeJyLZNT6lsnsQQqDQSzKeBDZQuZ/kyWpcF
PwT48Ohmsxd9V7SOEYhBSgzlP27oaNO/uv0VbS/xNb+3eCYSgBWdZGCKc4nl
Jq29Ep/xx5zdi0fiznZOrIqkwB0/dq7/5QKTl2bfn+XEiAmFDdBjrhjZQeis
fmKOamD2MIdxhsFon0wFoJHiwwK1MwhkFFBMXIkOb0KxKOPJhhtl0I5Ia3xZ
bL7Sknj0qu2HWKV9KV/nq8J7BKf3gShLFwHmHSWYENwXovo+zqMm+ZsQN+l+
7nTQox/jHL/b2/Fw7t53Bs648ycLFrzHtA3AbvLtUKjMofUCodLU55aUrKnN
xstvWO+GTCwYIOwiMqkKTm3qLWD2rJ/6V3/mEiTPKSd5EJOezR2CFTXgP8Us
frXu1aq1VKS8z5mV5C1h1oVfmfztai8YT+I1btcE5vvKJ+LVaC3KHq6ck3ui
W+2kB6nB42JbghdCkDuZ7zDtVAL2I28ShrWauaQp/bPZazw2KqpjEWhG6s6S
VP9oeYNt3K4lODh3s1OPqy09vN1gAq3eCg3eq5OpCltkklRFZIPTsWWAMDm8
jJXyuHyTDMMFaGntU4ps4DyRqYQd2AtRamowUo1im7p6kyilJuMPmXcfRGX+
CFnUV5HVjyqHLbaYv4TL3doeAxYSFjyksmOco9ER+gPBvNokvIfu0KUViyTJ
W587Mpgg4w3GnZs8Vq5iLO7hQfLSIR1iUBQoFXLCw2Y/CpS2yAzTT6LfLjAS
pU/Wtx8obyulqtXrbXed9XZTYsHrYhtEY1cD1kJS93GQ/jYowGTbVCwx56tM
Ftom2OsPQVLfQUakbB9Frc2LxVUFVIXcEZ5qCsmgoyA5RCVljE8KI89clPWq
n4vL3NahtwlIKTKM/QbUaRnb78dHa2ttCuWLTiBNl0x3z3EvgyQ/Rr0M8SDG
4Jt4cFlNSY/jmGmY9keiWuvmXOpBsCjcW7c9JqZwkqoc13Gw9AFbXA8doBb7
xyNC4Wo/fYOH5pJz+ng/gmEnjIOG9vXG+LozoQZKpZGCxCv2Dq5bOubIkMdr
lyCdQJXR9i/GFV+wbJQzdJaU102kjhyr1YwZQ3+FMAaH2vH8iAuu8ykLa6gI
ctcnbGRGoGcHNsbF2sldS48Tb6cqtCbXc6Cr2QMUH5e6gRtOKVZKSTaSAFzC
CvBCyv0Mf10XQ+Y2OUVIBOY9tbARN0J6Lh8XnybabijyZ1wA53ub9jMb+k80
zxu10Vp/HpsNFQ3ypSX+bUL/leKPWaCv9ogdYDLTGwhXZ8U1Sp0JD2eztQYS
hCO4I2nVDMX1/jX0tkk4Xl9MmHqHqMS9GHVtTH5Ij19V1SagxSCmNAHfGtqR
gscsc6qdTRJps6kKQWNxZy4HqbcvG4/qoNlBxi3KwbGZ5wzMVtMOMo3Vxh54
F5x+4ijWdGg2CvOWCbW0os64xHKsvucA6BgD/GX+XuYxqWkDWNQesS4qrWdt
pCnPyNgxjcVY6XxfSXaM1OcAAyQQVHwGPZdnEYEChjVryGD9OeoMIEOMAR42
rSamckHpuS13rMiD2aKaAZyh1ikx6apQihZzMx3b8pcy0FuvxT7PmYNGXeh8
UH5NaL1TSXUeE0ZUoKh7m1Hfh+fakGZ3W46Pj4uMfWXMZ72Ys+O6FMe1Mtb9
Ik4zG3xPiysM5i4gs/djcv1X8lWP8Hjh62oalquwbULob2QfXqyGR/yIXLgi
CpBfVgMqW+zBQl7AySCCeHifaauP0llYc4coromfhUZk7FAmM2Ia4mpdOFlW
YSFMlHGPLRx2RmqTsrH/U653m/DCVegMFc0cxptSSynx9WROFDeWDnR1fdLQ
YEvQZH+bTw4wno84SRuQGrqSuYmS1Y9YmlCVxtrgiD0s80lHWRGyiarInIp4
ci4i9Huk/e+R9v8dIu3T9MP5Cu1BudKmdfTKGWeUYvWKbyQPN1MEMpPiA8vq
otyuBpNcNQpKzF62KEzIECJ8Jcj3my3g/eVxWr17tpNIBCZGmNlo+ZudxFnt
2horjzle2ORuKtsHNrLNqlzQHPwcEyp1Xl20vjSrFGsIWQ7Soe9qDgqmUJcG
s8eSFJbBFYf5DCLpw4QF18umktJozl4sOQQDWddlmU1NWehmjax5JNCqX8eb
9mxyExLhXa0Qh40ol6/x1vYVqx2BRAoveMtImhrBmfITm15YhS/NiN+HZTah
nwxiJ7bDm/T+zC91b23uHfxMC5VVUqjM+zO0BG97ceGimOhdFThs5V32MNni
1XXzul29RphO08ZVkGkz+GuuzkBl2Tj/uofXOM0cD6MvZ5tGk0fF1jIijwey
+7J0drlS5ySnVks3C8cHhwSvTVwf2HW/J09+d80qqQaLD09J9tzZPxsNbEZ0
oJL7m4dffTUnzUqgwbYSH7zzt7/n1au//d0zoT/Rqk0vFa9Xbl12/vi1evwu
oN07BO78prWh4GffY7DfWO4xZTo+/xVQ5cd/E/nF12t6rTdfmYd3C9kY5sQN
YSTdoC6Jtzxmqi0VCaoiZyh2EYxB9aY+V79JSCzSMZUOIgyaq7EUZh+bklpy
VbMwLph7lxoBvqqUUWVDz1LGkD1Sjg+97AGqIAcXyKiPvcTWJnUo0DFH6Mgi
sfsOLjmziJJeDoD9o7z2KFndFMtt50N+GGCcleOMkdGlgyIBQ4LAr8pRmZjd
sw4NKmzNWGPzpStwB0iY9uHdDvKesWEGaI4AO7JPJdKkNp5gbbjyNQseSc22
SKCkugfhtjolmKT8G7GdB+mt8FuXWVqiQE0VAFvgYiJ5075OGJVGQkVmvEib
8RFStpadpdZo7WHbMvn8nKB2gUKtE1FNUWiTiMbFUbDsT36RLFA3QfDY4Dlz
2Vj/4sOKRozFooJZJJVo5pLPOkRAZwqAWMP9aNCGuy35wD2pQeOWQlaANyVX
+CpQpSaiJXPGfEf64eQS2bBB7SFhKaX+mKm19vIqKj8TVuvNCMFh3zHI3Brz
/8ki51gBJnwpnnoWEZ0RrvYQOm0p1FEL/jxv2gGpc+7NG8fFP8eQn1kZOSKy
9nu0UUhVj71+RlZ6nx97HO8H1H6caBZ7yryhnOwl/z363i/iPxTWgtqaemkT
WSYk4N4GxEUIPJkmDFvjSXZSglRSQHfr2ldOj8oQ5JRT9DF6Vp72ZdmPFPYM
sobkiDSWBiC3pgTOr3OGJ0HrlWnYV0akTcdOYshA4UagH/frOp/x28R6UZAK
lwZAnHlAgg17REtCiuXSIPq0SMWTfqJOk0KGuBJYHVvjCDEfZfGmWli0I8rT
jJTO3EuLl4QMIKKAKExiJmGSEZXrZeOKhpDHaPEeswqYh5vNWTyirpIAarV4
6DssxHDtJgtLZEsQLrtkMcDPt02NaUI9KKOvTMsR0NejoMUHTtYfZ43L2eG8
fXDUERM4jK7a6xH+7nGsPo7ok9Ewon09I+/OEvMlm96JIZq4FKSQSQhnhpsc
RT97BUGMFILajyDfl//cm4l4L0ZQ2gpXqIGh1Mu/B7lMRhy1oyE90bGcJQ5b
NstKyQv0SmjGVckmUMZUpMRbh1e2NP3F7CB3LQTMI/BIvBLYJ45ck/ijQoNL
BxMSpbMs8u2TLptNrBB4byU6GXmBD4QUfAmXRRMijpj1jIk6OwFWYLAmHPEm
LStJrLgUb/M5FjqCbupSrK5TC+IiIa/qy6sV/J9b88kk+t1toL7yuuXsEF21
qSTJGc/JpY1PeKvuAOdGHhjTbMIv0U07prOPJ7yzp0XrhXc+Twl7BLAQjfQo
BQGtnu+LIE30MM/jzDLKu/dVZGMjENOMYPw4b3IAFg4y1FlDu9QXRTAhj/Cn
riLj+fIv1c3zIH8spWeeK682/aMJ38gnibAhOF30GjFZCMbqNFEpSWTsNIFW
irzIoPNdDcL8mbpNZaPAPmaDhgKgsIzQwi+MWSeIIuA2otrxzhbp8qfpeQzU
X99/Pw9btbtjR2GrQqOzK0RJOEesmfBBmjnu0B9Xa5vwxXaaGz3H8QHl4Ore
e37+lV0q49qt3R71wmXvTN6ronyRZxH7Vs7/ezpX7q40siHfXwIRFHLZypxO
ZBXGPm/h38tOGNm0xRkQGrVDIOc0Q315JekgTQYlLSZAgrgyBl+WYxfnIRth
YC7O2oaDTKteBOBg4F/R6/lfZILKp0Gczmn4u3Hqd+PUuHEq9STmAIQUu5iG
KFvHyL7ieKwb7YSwmrcjdcinkBPdot8r74x1kcWayk+TxeMJfomozsw0WWmD
129vC05urUQQE41ooBtK7xnRPZfDGnFSE/QT5SuxRW1s66VPDRk+HDsoqf5k
GdatJ2MdcoasqzDAvo3Ko2xPgaFNnILD0PdFCmr+TMiyB5HZpfFT3anMlGnl
PWSP+B246oGr/7grcPWXdOMQ9TmOH51s4b8t5LXApQtmAh/jcGBUwWCf02D9
QdoPK0s/76E0laekcI+vqZDzhUIMehtMz0O2t3EL93iFtvYrktj03hp9UeVR
1EyTPOiJJzsGA8TE3oR3OwHXBh86YpaHOd6dloWQQOaU77Ftn29VAsQM3MCz
BwM4GKKxCK9Osw+HtYytd9d7n4Jc/AF0Mb5IIxnY686fEZt6HWRkK2QlQzDZ
plxVGM7ASZ7p+jKnAPwu/v8u/ruf+4v/gfR/n3i2367wv1djae63u7yiyeGS
XLu7J3GvJLv0HrMrX6dYLMKa46E8b18DHQnMElwkd0y0VlN6JApfA9VZtwOZ
1TVQjIOhjNDNQVFPfDIMZH2uO4q2YkdyXDYvX4TGBt3ZICwtRehzQPmM8LXT
1jTYJPWZZHWsI9xJrix5Oy+y1aEZu6XJ3lnzWNagTA6gGbICRxzd1XMbN/0Q
asjqSuMgwDGl0A440g/Vg9GHbjE6IC4qbq98kZlZ2WBEDQLZMdNImnJ72VSa
mobDjAotqu44bpwKJYgMGQFq7lIgY8dMPlhBPN7qjPHBR4yndZDPccDKEOAK
p/DKMK3ILlFm9LudsUujVWY0WEtTLI/IMYKNM0mVYWw3ufuUqcYaqsWjRatu
DzNetLhe1L18abaEw0h9qAw01mQptgYBDJaQi6ACgvfN2ay7mpqDDUlqE07N
RIFY1ztjLmaicyhuX9/G+C8x7ZCyBy7B7sBNRo5VjfrXS8z69P8XRXGyNXGk
uX1Y//04e7K2v1r5m/dQzWbSzHlUbCYNjRlmR6bF2Q4DZZiYCj33XPYLoXdG
gUwyAqo7llz9q5biGeOrexUY0Cj4kGMcVH/HEZ65Zs+iodnKrBqI65ILUAay
ICGPiDv1kjgkTqgmJAIFdrpo3CCBwHzHoqaVUlyEqxs6jXpPGwFti3udlPXA
m2cGIjEVbhqEhxybB8ty+09FC0Mv4mlMi3v0MEZv1s2W9b5ZlMSd8/hmV0hC
JsMPJWsv4iT9WnAtQ3iyr88R6pi8RWAWZBmCNAmtPpq9niCqWp6Qkp4Z+JFL
U36clmM2uegTBks+TFdB0KEWsjOGybEIr/nGCRziBNgXZHdaFXQ/fQLUJ+G+
pdfanx8VXuthW2bQXiZBR+Zi+tOQnj712bvz1lza4xYb1OoLHxlLyRVHwtTR
CmhQQXQkwvSYgfR7H8mOfRQG+oB9eH5psjnSm1Eex1x4Fco5Qap4jRrhlI6T
l87HTkxgmEKerOeZY1W2TbYKYnZ9gxjrUEBD8FNQAxtrLKtD6//e9g5AkPWO
OFQw43WNDOfKgySk3z5Fkj3DyyWVrgn8dwenbgT8o+OypR6dNKCVvX8rchxe
XjJTwcZPmfT2yhD1voOdAzFvDJ+DAnscSpkegneQ5Lwod0+8b2ah7yXW5bZi
58/d8i7+Wzi9IhEMvdHSlzSeZgAjgp3hw2OFWIk2TUo0lA4pzKcs9XhNWV+K
Ls25//cgx+NAgFq43zQBvZM0hUJYtRFrTUzdU9vJeeV4gfhAEm6v6xAxfKfP
BvSWRAM0IA3AjwcfM+rL40zR1oyPytoTgroG4rn4V6FzAWX6nfLozz+Z8sxm
/x/Mdx4DwIwBAA==

-->

</rfc>

