<?xml version="1.0" encoding="us-ascii"?>
  <?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 RFC5246 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC8422 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml">
<!ENTITY RFC8017 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
<!ENTITY RFC5480 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY RFC7627 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7627.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY RFC7250 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY I-D.mglt-lurk-tls-use-cases SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-lurk-tls-use-cases.xml">
<!ENTITY I-D.fieau-cdni-https-delegation SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.fieau-cdni-https-delegation.xml">
<!ENTITY I-D.ietf-acme-star SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-acme-star.xml">
<!ENTITY I-D.sheffer-acme-star-request SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.sheffer-acme-star-request.xml">
<!ENTITY I-D.ietf-acme-acme SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-acme-acme.xml">
<!ENTITY I-D.rescorla-tls-subcerts SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.rescorla-tls-subcerts.xml">
<!ENTITY I-D.mglt-lurk-lurk SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-lurk-lurk.xml">
<!ENTITY RFC8235 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8235.xml">
<!ENTITY I-D.erb-lurk-rsalg SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.erb-lurk-rsalg.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-tls12-05" category="std">

  <front>
    <title abbrev="LURK/TLS 1.2">LURK Extension version 1 for (D)TLS 1.2 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>
    <author initials="I." surname="Boureanu" fullname="Ioana Boureanu">
      <organization>University of Surrey</organization>
      <address>
        <postal>
          <street>Stag Hill Campus</street>
          <city>Guildford</city>
          <code>GU2 7XH</code>
          <country>UK</country>
        </postal>
        <email>i.boureanu@surrey.ac.uk</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 'tls12' which enables
interactions between a LURK Client and a LURK Server in a context of
authentication with (D)TLS 1.2.</t>



    </abstract>


  </front>

  <middle>


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

<t>This document describes the LURK Extension for TLS 1.2 so the LURK
Server can implement a Cryptographic Service in a TLS 1.2 <xref target="RFC5246"/>
and DTLS 1.2 <xref target="RFC6347"/> context.</t>

<t>More specifically, the LURK Server will be in charge of performing the
cryptographic operations associated to the private key of the TLS
Server, while other aspects of the termination of the TLS session is
handled by other services in the same administrative domain or in a
different administrative domain. Most Cryptographic Operations are
related to the TLS authentication and the current document limits the
Cryptographic Operations to the following authentication methods: RSA
and ECDHE_RSA defined in <xref target="RFC5246"/>, <xref target="RFC6347"/> as well as
ECDHE_ECDSA defined in <xref target="RFC8422"/>.</t>

<t>A more detailed description of some use cases foreseen in a TLS context
can be found in <xref target="I-D.mglt-lurk-tls-use-cases"/>.</t>

<t>HTTPS delegation has been the main concern of the Content Delivery
Networks Interconnection (cdni) Working Group and several mechanisms
have been designed to delegate the load from an upstream entity to a
downstream entity. Entities can be of different nature and may
designated differently according to the context. Typically designations
includes Content Owner, CDN Provider, Domain Name Owner for example.
<xref target="I-D.fieau-cdni-https-delegation"/> provides a details comparison of
the various mechanisms applies to the CDN Interconnection, and the
remaining of this section positions these mechanisms at a very high
level view.</t>

<t>STAR <xref target="I-D.ietf-acme-star"/>, <xref target="I-D.sheffer-acme-star-request"/>
describes a methods where the domain name owner or the content owner
orchestrates the refreshing process between a CA and the CDN
(terminating the TLS session). The CDN refreshes regularly and
automatically its certificates using <xref target="I-D.ietf-acme-acme"/>, which
allows the use of short term certificates.</t>

<t>Delegated credentials <xref target="I-D.rescorla-tls-subcerts"/> consists having a
certificate that enables the servers to generates some "delegated
credentials".</t>

<t>STAR and "delegated credentials" both require some changes performed by
the CA - new certificate type for the delegated credentials and new
interfaces for the delegated and delegating entity for STAR. In both
case the TLS Client authenticates the delegated entity. While STAR does
not require changes on the TLS Client, the "delegated credential"
solution does. In both cases, the delegation is controlled by limiting
in time (7 days), which is also the limit of use of a stolen key or a
rogue server. Such delegation provides a high scalability of the
architecture and prevents additional delays when a TLS session is
established.</t>

<t>The LURK Architecture <xref target="I-D.mglt-lurk-lurk"/> and the LURK Extension
'tls12' do not proceed to the delegation of the HTTPS delegation by
delegating the entire TLS termination. Instead, the TLS termination is
split into sub services, for example one associated to the networking
part and one associated to the cryptographic operation. While micro
services associated to the networking part are delegated, the micro
service associated to the cryptographic operation may not be delegated.
As a result, LURK Architecture is focused on the protection of the
Cryptographic Material and prevents leakage of the Cryptographic
Material for example by avoiding node exposed to the Internet to host
the Cryptographic Material. In addition, LURK provides means to
instantaneously suspend the delegation with a suspicious node. On the
other hand the LURK Extension 'tls12' introduces some latency, and is
not as scalable as STAR or delegated credential solutions.</t>

<t>The LURK Extension 'tls12' is seen as a complementary to the STAR and
"delegated credentials". The LURK Extension 'tls12' is a backend
solution that does not require any modifications from TLS Client or the
CA. It is also aimed at protecting the Cryptographic Material.</t>

<t>LURK may also be deployed within an administrative domain in order to to
provide a more controlled deployment of TLS Servers.</t>

</section>
<section anchor="terminology-and-acronyms" title="Terminology and Acronyms">

<t>This document re-uses the terminology defined in
<xref target="I-D.mglt-lurk-lurk"/>.</t>

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

<t>LURK / TLS 1.2 is a LURK Extension that introduces a new designation
"tls12". This document assumes that Extension is defined with
designation set to "tls12" 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 {
    tls12 (1), (255)
} Designation;

enum {
   capabilities (0), ping (1), rsa_master (2), 
   rsa_master_with_poh (3), rsa_extended_master (4), 
   rsa_extended_master_with_poh (5), ecdhe (6), (255)
}TLS12Type;


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

    // code points for rsa authentication
    invalid_key_id_type (4), invalid_key_id (5),
    invalid_tls_random (6), invalid_freshness_funct (7),
    invalid_encrypted_premaster (8), invalid_finished (9)

    //code points for ecdhe authentication
    invalid_ec_type (10), invalid_ec_curve (11), 
    invalid_poo_prf (12), invalid_poo (13), (255)
}TLS12Status

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

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

</section>
<section anchor="rsamaster-rsamasterwithpoh" title="rsa_master, rsa_master_with_poh">

<t>An exchange of type "rsa_master" or "rsa_master_with_poh" enables the
LURK Client to delegate the RSA Key Exchange and authentication as
defined in <xref target="RFC5246"/>. The LURK Server returns the master secret.</t>

<t>"rsa_master" provides the necessary parameters and details to generate
the master secret, as well as to hinder replaying of old handshake
messages by a corrupt LURK Client. I.e., some attestation of
message-freshness is acquired by the LURK Server.</t>

<t>In addition, the"rsa_master_with_poh" provides  a proof of handshake
(PoH).  The proof of handshake consists in providing the Finished
message of the TLS Client to the LURK Server, so that latter  can
perform more checks that in the "rsa_master" mode. Notably, herein, the
LURK Server also checks that the LURK request is performed in a context
of a TLS handshake.</t>

<t>While "rsa_master" and "rsa_master_with_poh" exchange have respectively
different requests, the response is the same. The motivation for having
different type is that the parameters provided to the LURK Server are
provided using different format. "rsa_master" provides them explicitly,
while "rsa_master_with_poh" provides them via handshake messages.</t>

<section anchor="sec-rsa-master-req" title="Request Payload">

<t>A rsa_master request payload has the following structure:</t>

<figure><artwork><![CDATA[
enum {
    sha256_32 (0), (255)
}KeyPairIdType;

struct {
    KeyPairIdType type;
    opaque data; // length defined by the type
} KeyPairID;

enum{
    sha256 (0), (255)
} FreshnessFunct

enum{
    sha256 (0), sha384(1), sha512(2), (255)
} PRFHash

struct {
    KeyPairID key_id;
    FreshnessFunct freshness_funct; 
    PRFHash prf_hash;
    Random client_random;        // see RFC5246 section 7.4.1.2
    Random server_random;    
    EncryptedPreMasterSecret  pre_master; 
                // see RFC5246 section 7.4.7.1 
                // Length depends on the key.
    }
} TLS12RSAMasterRequestPayload;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="key_id">
  The identifier of the public key. This document defines sha256_32
format which takes the 32 first bits of the hash of the binary ASN.1 DER
representation of the public key using sha256. The binary representation
of RSA keys is described in <xref target="RFC8017"/>. The binary representation of
ECC keys is the subjectPublicKeyInfo structure defined in <xref target="RFC5480"/>.</t>
  <t hangText="freshness_funct">
  the one-way hash function (OWHF) used by LURK to implement Perfect
Forward Secrecy.</t>
  <t hangText="prf_hash">
  the one way hash function used by the Pseudo Random Function (PRF) to
generate the master secret. PRF and hash function are defined in
{!RFC5246}} Section 5.</t>
  <t hangText="client_random">
  the random value associated to the TLS Client as defined in
<xref target="RFC5246"/> Section 7.4.1.2.</t>
</list></t>

<t>server_random: the random value associated to the TLS Server as defined
in <xref target="RFC5246"/> Section 7.4.1.2.</t>

<t>EncryptedPreMasterSecret : The encrypted master secret as defined in
<xref target="RFC5246"/> Section 7.4.7.1.</t>

<t>A rsa_master_with_poh request payload has the following structure:</t>

<figure><artwork><![CDATA[
struct {
    KeyPairID key_id;
    FreshnessFunct freshness_funct; 
    opaque handshake_messages<2...2^16-2> 
              // see RFC5246 section 7.4.9
    Finished finished
} TLS12RSAMasterWithPoHRequestPayload;
]]></artwork></figure>

<t>key_id, freshness_funct are defined above</t>

<t><list style="hanging">
  <t hangText="handshake_messages">
  provides the necessary handshake messages to compute the Finished
message of the TLS Client as defined in <xref target="RFC5246"/> section 7.4.9.</t>
  <t hangText="finished">
  the TLS Client Finished message as defined by <xref target="RFC5246"/> section
7.4.9.</t>
</list></t>

<section anchor="sec-pfs" title="Perfect Forward Secrecy">

<t>This document defines a mechanism which uses a function called
freshness_funct, to prevent an attacker to send a request to the LURK
Server in such a way that the said attacker can obtain back the
mastersecret for an old handshake. In other words, the use of this
function helps prevent a forward-secrecy attack on an old TLS session,
where the attack would make use that session's handshake-data observed
by the adversary.</t>

<t>This design achieves PFS  with freshness_funct being a
collision-resistant hash function (CHRF). By CRHF, we mean a one-way
hash function (OWHF) which also has collision resistance; the latter
means that it is computationally infeasible to find any two inputs x1
and x2 such that freshness_funct(x1) = freshness_funct(x2). By one-way
hash function (OWHF) we mean, as standard, a hash function
freshness_funct that satisfies preimage resistance and 2nd-preimage
resistance. That is, given a hash value y, it is computationally
infeasible to find an x such that freshness_funct(x) = y, and
respectively-- given a value x1 and its hash freshness_funct(x1), it is
computationally infeasible to find another x2 such that
freshness_funct(x2) = freshness_funct(x1).</t>

<t>For the concrete use of our freshness_funct funtions, let S be a fresh,
randomly picked value generated by the LURK Client. The value of
server_random in the TLS exchange is then equal to freshness_funct(S),
i.e., server_random=freshness_funct(S). Between the TLS Client and the
LURK Server only server-random is exchanged. The LURK Client sends S to
the Key Server, in the query. Note that the latter SHOULD happen over a
secure channel.</t>

<t>A man-in-the-middle attacker observing the (plaintext) TLS handshake
between a TLS Client and the LURK Client does not see S, but only
server_random. The preimage resistance guaranted by the freshness_funct
makes it such that this man-in-the-middle cannot retrieve S out of the
observed server-random. As such, this man-in-the-middle attacker cannot
query the S corresponding to an (old) observed handshake to the Key
Server. Moreover, the collision resistance guaranteed by the
freshness_funct makes it such that if the aforementioned
man-in-the-middle cannot find S' such that
freshness_funct(S)=freshness_funct(S').</t>

<t>As discussed in <xref target="sec-sec"/>, PFS may be achieved in other ways (i.e.,
not using a CRHF and the aforementioned exchanges but other
cryptographic primitives and other exchanges). These may offer better
computational efficiency. These may be standardized in future versions
of the LURK extension "tls12.</t>

<t>The server_random MUST follow the structure of <xref target="RFC5246"/> section
7.4.1.2, which carries the gmt_unix_time in the first four bytes. 
So, the ServerHello.random of the TLS exchange is derived from the
server_random of the LURK exchange as defined below:</t>

<figure><artwork><![CDATA[
gmt_unix_time = server_random[0..3];
ServerHello.random = freshness_funct( server_random + "tls12 pfs" ); 
ServerHello.random[0..3] = gmt_unix_time;
]]></artwork></figure>

<t>The operation MUST be performed by the LURK Server as well as the TLS
Server, upon receiving the master secret or the signature of the
ecdhe_params from the LURK Client.</t>

</section>
</section>
<section anchor="sec-lurk-tls-rsa-master-resp" title="Response Payload">

<t>The "rsa_master" response payload contains the master secret and has
the following structure:</t>

<figure><artwork><![CDATA[
struct {
    opaque master[0..47];
} TLS12RSAMasterResponsePayload;
]]></artwork></figure>

</section>
<section anchor="sec-rsa-master-clt" title="LURK Client Behavior">

<t>A LURK Client initiates an rsa_master or an rsa_master_with_poh exchange
in order to retrieve the master secret. The LURK exchange happens on the
TLS Server side (Edge Server). Upon receipt of the master_secret the
Edge Server generates the session keys and finish the TLS key exchange
protocol.</t>

<t>A LURK Client MAY use the rsa_master_with_poh to provide the LURK Server
evidences that the LURK exchange is performed in the context of a TLS
handshake. The Proof of TLS Hanshake (POH) helps the LURK Server to
audit the context associated to the query.</t>

<t>The LURK Client MUST ensure that the transmitted values for
server_random is S such as server_random = freshness_funct( S ).</t>

</section>
<section anchor="sec-rsa-master-srv" title="LURK Server Behavior">

<t>Upon receipt of a rsa_master or a rsa_master_with_poh request, the LURK
Server proceeds according to the following steps:</t>

<t><list style="numbers">
  <t>The LURK Server checks the RSA key pair is available (key_id). If the
format of the key pair identifier is not understood, an
"invalid_key_id_type" error is returned. If the designated key pair is
not available an "invalid_key_id" error is returned.</t>
  <t>The LURK Server checks the freshness_funct. If it does not support the
FreshnessFunct, an "invalid_freshness_funct" error is returned.</t>
  <t>The LURK Server collects the client_random, server_random and
pre_master parameters either provided explicitly (rsa_master) or within
the handshake (rsa_master_with_poh).</t>
  <t>The LURK Server MUST check the format of the server_random and more
specifically checks the gmt_unix_time associated to the random is
acceptable. Otherwise it SHOULD return an "invalid_tls_random" error.
The value of the time window is implementation dependent and SHOULD be a
configurable parameters. The LURK Server MAY also check the
client_random. This should be considered cautiously as such check may
prevent TLS Clients to set a TLS session. client_random is generated by
the TLS Client whose clock might not be synchronized with the one of the
LURK Server or that might have a TLS implementations that does not
generate random based on gmt_unix_time.</t>
  <t>The LURK Server computes the necessary ServerHello.random from the
server_random when applicable as described in <xref target="sec-pfs"/>. When option
is set to "finished" the ServerHello.random in the handshake is replaced
by its new value.</t>
  <t>The LURK Server checks the length of the encrypted premaster secret
and returns an "invalid_payload_format" error if the length differs from
the length of binary representation of the RSA modulus.</t>
  <t>The LURK Server decrypts the encrypted premaster secret as described
in <xref target="RFC5246"/> section 7.4.7.1. When a PKCS1.5 format error is
detected, or a mismatch between the TLS versions provided as input and
the one indicated in the encrypted premaster secret, the Key Server
returns a randomly generated master secret.</t>
  <t>The LURK Server generates the master secret as described in
<xref target="RFC5246"/> section 8.1 using the client_random, and the server_random
provided by the LURK Client.</t>
  <t>With a rsa_master_with_poh, the LURK Server checks the Finished
message is checked as defined in <xref target="RFC5246"/> section 7.4.9. In case of
mismatch returns an "invalid_finished" error.</t>
  <t>The LURK Server returns a master secret in a
TLS12RSAMasterResponsePayload.</t>
  <t>Error are expected to provide the LURK Client an indication of the
cause that resulted in the error. When an error occurs the LURK Server
MAY ignore the request, or provide more generic error codes such as
"undefined_error" or "invalid_format".</t>
</list></t>

</section>
</section>
<section anchor="rsaextendedmaster-rssextendedmasterwithpoh" title="rsa_extended_master, rss_extended_master_with_poh">

<t>A exchange of type "rsa_extended_master" enables the LURK Client to
delegate
the RSA Key Exchange and authentication. The LURK Server returns the
extended master secret as defined in <xref target="RFC7627"/>.</t>

<section anchor="request-payload" title="Request Payload">

<t>The "rsa_extended_master" request has the following structure:</t>

<figure><artwork><![CDATA[
enum { sha256 (0), (255) } FreshnessFunct

enum { null(0), sha256_128(1), sha256_256(2),
(255) }POOPRF 

struct {
    KeyPairID key_id
    FreshnessFunct freshness_funct        // see RFC5246 section 6.1
    opaque handshake_messages<2...2^16-2> // see RFC7627 section 4
}TLS12ExtendedMasterRSARequestPayload;
]]></artwork></figure>

<t>The "rsa_extended_master_with_poh" request has the following structure:</t>

<figure><artwork><![CDATA[
struct {
    KeyPairID key_id
    FreshnessFunct freshness_funct        // see RFC5246 section 6.1
    opaque handshake_messages<2...2^16-2> 
                                // see RFC5246 section 7.4.9
    Finished finished
    }
}TLS12ExtendedMasterRSAWithPoHRequestPayload;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="key_id, freshness_funct, option, handshake, finished">
  are defined in <xref target="sec-rsa-master-req"/>.</t>
  <t hangText="handshake_messages">
  With a the handshake message includes
are those necessary to generate a extended master secret as defined in
<xref target="RFC7627"/> section 4.</t>
</list></t>

</section>
<section anchor="response-payload" title="Response Payload">

<t>rsa_extended_master response payload has a similar structure as the
rsa_master response payload <xref target="sec-lurk-tls-rsa-master-resp"/>.</t>

</section>
<section anchor="lurk-client-behavior" title="LURK Client Behavior">

<t>The LURK Client proceeds as described in <xref target="sec-rsa-master-clt"/>. The
main difference is that the necessary element to generate the master
secret are included in the handshake and or not provided separately.</t>

</section>
<section anchor="lurk-server-behavior" title="LURK Server Behavior">

<t>The LURK Server proceeds as described in <xref target="sec-rsa-master-srv"/> except
that the generation of the extended master is processed as described in
<xref target="RFC7627"/>.</t>

</section>
</section>
<section anchor="sec-ecdhe" title="ecdhe&quot;">

<t>A exchange of type "ecdhe" enables the LURK Client to delegate the
ECDHE_RSA <xref target="RFC5246"/> or the ECDHE_ECDSA <xref target="RFC8422"/>
authentication.</t>

<section anchor="sec-ecdhe-req" title="Request Payload">

<t>The "ecdhe" request payload has the following structure:</t>

<figure><artwork><![CDATA[
enum { null(0), sha256_128(1), sha256_256(2),
(255) }POOPRF 

struct {
    POOPRF poo_prf;
    select( poo_prf ) {
        case ( "null" ):
        case ( "sha256_128" )
            ECPoint vG;  //RFC8422 section 5.4
            opaque R[16] r;
        case ( "sha256_256" ):
            ECPoint vG;  //RFC8422 section 5.4
            opaque R[32] r;
    }
} TLS12POOParams;

struct {
    KeyPairID key_id;
    FreshnessFunct freshness_funct;
    Random client_random;        // see RFC5246 section 7.4.1.2
    Random server_random;
    SignatureAndHashAlgorithm sig_and_hash  //RFC 5246 section 4.7
    ServerECDHParams ecdhe_params;  // RFC8422 section 5.4
    POOParams poo_params;
} TLS12ECDHERequestPayload;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="key_id, freshness_funct, client_random, server_random">
  is defined in  <xref target="sec-rsa-master-req"/>.</t>
  <t hangText="ecdhe_params">
  contains as defined in <xref target="RFC8422"/> section 5.4, the
elliptic curve domain parameters associated with the ECDH public key
(defined by the ECParameters structure) and the ephemeral ECDH public
key (defined by the ECPoint structure). The public key is also noted in
this document bG with b is a random secret generated by the LURK Client
and G the base point of the curve.</t>
  <t hangText="poo_params">
  defines the necessary parameters to provide a proof of ownership of
the ECDHE private key. This option is intended to prevent the LURK
Server to sign bytes that do not correspond to a ECDHE public key.</t>
  <t hangText="poo_prf">
  pseudo random function used to generate the necessary randoms to proof
ownership of the private key.  This document defines sha256_128 and
sha256_256 which apply the sha256 hash function and respectively return
the 128 or 256 first bits of the resulting hash.</t>
  <t hangText="vG">
  are the necessary points to generate the proof of ownership.</t>
  <t hangText="r">
  necessary value to create the proof of ownership.</t>
</list></t>

<t>The proof of ownership (PoO) consists in the LURK Client proving the knowledge
of the private random b, while not disclosing b. With G the base point, bG
represents the public value. The PoO is based on the non-interactive variant of
the three-pass Schnorr identification scheme (NIZR) also designated as the
Fiat-Shamir transformation described in <xref target="RFC8235"/>. More specifically, the
LURK Client randomly generates v and then derive c and r = v - b*c. The LURK
Client provides bG, vG, and r to the LURK Servers. The LURK Server first checks
bG is on the curve. Then it computes c similarly to the LURK Client as well S =
rG + (bG)c. This latest value S is compared to vG. The equality between S and
vG proves the ownership of b.</t>

<t>v is randomly generated by the LURK Client. v MUST remain non-predictable with a
length equivalent to the expected level of security, that is 128 bit length
(resp. 256 bit length) for a 128 (resp 256) bit security level. Given b, we
RECOMMEND v to be at least half the size of b.</t>

<t>c is computed by the LURK Client and the LURK Server as described in
<xref target="RFC8235"/>. UserID is defined by the concatenation of the client_random and
the server_random. OtherInfo is defined as the concatenation of key_id,
freshness_funct, sig_and_hash, ecdhe_params, "tls12 poo". Each concatenated
item is prefixed with a 4-byte integer that represents the byte length of the
item.</t>

<figure><artwork><![CDATA[
UserID = client_random || server_random
OtherInfo =  key_id || freshness_funct || sig_and_hash || 
             ecdhe_params || "tls12 poo"
c = poo_prf(G || vG || bG || UserID || OtherInfo)
]]></artwork></figure>

<t>The LURK Client provides bG in ecdhe_params and vG as well as r in poo_params.</t>

<t>With X25519 or X448, b and r MUST be clamped and vG MUST use the Curve25519
(resp. Curve448). bG MAY also use the Curve25519 or Curve448 representation, or
the LURK Server MAY derive bG values from the provided xlined value in
ecdhe_params.</t>

</section>
<section anchor="response-payload-1" title="Response Payload">

<t>The "ecdhe" response payload has the following structure:</t>

<figure><artwork><![CDATA[
struct {
    Signature signed_params;  // RFC8422 section 5.4  
} TLS12ECDHEResponsePayload;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="signed_params">
  signature applied to the hash of the
ecdhe_params
as well as client_random and server_random as described in<vspace />
<xref target="RFC8422"/> section 5.4.</t>
</list></t>

</section>
<section anchor="lurk-client-behavior-1" title="LURK Client Behavior">

<t>The LURK Client builds the base as described in <xref target="sec-rsa-master-req"/> and in
<xref target="sec-ecdhe-req"/>.</t>

<t>Upon receiving the response payload, the LURK Client MAY check the
signature. If the signature does not match an error SHOULD be
reported.</t>

</section>
<section anchor="lurk-server-behavior-1" title="LURK Server Behavior">

<t>Upon receiving an ecdhe request, the LURK Server proceeds as follows:</t>

<t><list style="numbers">
  <t>perform steps 1 - 6 as described in <xref target="sec-rsa-master-srv"/></t>
  <t>The LURK Server performs some format check of the ecdhe_params before
signing them. If the ecdhe_params does not follow the expected
structure. With the notations from <xref target="RFC8422"/>, if
curve_type is not set to "named_curve", the LURK Server SHOULD respond
with an "invalid_ec_type" error. If the curve or namedcurve is not
supported the LURK Server SHOULD be able to respond with an
"invalid_ec_curve" error.</t>
  <t>The LURK Server processes the poo_params. If the poo_prf is not
supported, the LURK Extension returns a "invalid_poo_prf" status. If
poo_prf is supported and different from "null", the LURK Server proceeds
to the proof of ownership as described in <xref target="sec-ecdhe-req"/>. If the
proof is not properly verified, the LURK Extension returns a
"invalid_poo" status.</t>
  <t>The LURK Server processes the base structure as described in
<xref target="sec-rsa-master-srv"/></t>
  <t>The LURK Server generates the signed_params.</t>
</list></t>

<t>Error are expected to provide the LURK Client an indication of the cause
that resulted in the error. When an error occurs the LURK Server MAY
ignore the request, or provide more generic error codes such as
"undefined_error" or "invalid_format".</t>

</section>
</section>
<section anchor="capabilities" title="capabilities">

<t>A exchange of type "capabilities" enables the LURK Client to be informed
of the supported operations performed by the LURK Server. The supported
parameters are provided on a per type basis.</t>

<section anchor="request-payload-1" title="Request Payload">

<t>A LURK "capabilities" request has no payload.</t>

</section>
<section anchor="response-payload-2" title="Response Payload">

<t>The "capabilities" response payload lists for each supported type, the
supported certificates, the supported signatures and hash associated.
The "capabilities" payload has the following structure:</t>

<figure><artwork><![CDATA[
struct{
    CertificateType certificate_type  // RFC8442 section 4.4.2
    select (certificate_type) {
         case RawPublicKey:
           /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
           opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
         case X509:
           opaque cert_data<1..2^24-1>;
     };
} TypedCertificate;

struct {
     KeyPairID key_id_type_list<0..255>; 
     TypedCertificate typed_certificate_list<0..255>  
     FreshnessFunctList freshness_funct_list<0..255>
     CipherSuites cipher_suite_list<0..255>
     PRFHash prf_hash_list<0..255>
} TLS12RSACapability; 



struct { 
     KeyPairID key_id_type_list<0..255>; 
     TypedCertificate typed_certificate_list<0..255>  
     FreshnessFunctList freshness_funct_list<0..255>
     CipherSuites cipher_suite_list<0..255>
     SignatureAndHashAlgorithm sig_and_hash_list<0..255>
     NameCurve ecdsa_curves_list<0..255>; 
     NameCurve ecdhe_curves_list<0..255>
     POOPRF poo_prf_list<0..255>
} TLS12ECDHECapability;  

struct {
    uint32 length;
    TLS12Type type
    Select( type ) {
           case rsa_master : TLS12RSACapability,
           case rsa_master_with_poh : TLS12RSACapability,
           case rsa_extended_master : TLS12RSACapability,
           case rsa_extended_master_with_poh : TLS12RSACapability,
           case ecdhe : TLS12ECDHECapability
    } capability ;
} TLS12Capability 


struct {
    TLS12Capability capability_list;
    opaque state<32>;  
} TLS12CapabilitiesResponsePayload;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText="typed_certificate">
  enables to contain authentication credentials of various type, such as
X09 certificate or raw public key. While different,  the structure is
similar of CertificateEntry defined in <xref target="RFC8446"/> section 4.4.2 as
well as the Certificate structure defined in <xref target="RFC7250"/>.</t>
  <t hangText="key_id_type_list">
  the supported key_id_type.</t>
  <t hangText="freshness_funct_list">
  designates the list of freshness_funct ( see <xref target="sec-rsa-master-req"/>).</t>
  <t hangText="certificate_list">
  designates the certificates associated to message type. The format is
similar but different from the CertificateEntry defined in <xref target="RFC8446"/>
in section 4.4.2 and <xref target="RFC7250"/> section 1. The CertificateBis format enables
the use of X509 as well as Raw Public key, while the Certificate
structure defined in <xref target="RFC5246"/> section 7.4.2 does not.</t>
  <t hangText="sig_and_hash_list">
  designates supported signature algorithms as well as PRF used for the
different operations. The format is defined in <xref target="RFC5246"/> section
7.4.1.4.1.</t>
  <t hangText="ecdsa_curves_list">
  the supported signatures</t>
  <t hangText="ecdhe_curves_list">
  the supported curves for ECHDE parameters.</t>
  <t hangText="poo_prf_list">
  the supported message type poo_prf ( see <xref target="sec-ecdhe-req"/>. to be used
with the proof of ownership.</t>
  <t hangText="type_list">
  the supported message type of the LURK extension.</t>
  <t hangText="state">
  characterizes the configuration associated to 'tls12' on the LURK
Server..</t>
</list></t>

</section>
<section anchor="lurk-client-behavior-2" title="LURK Client Behavior">

<t>The LURK Client performs a capability request in order to determine
the possible operations.</t>

<t>The LURK Client is expected to keep the state value to be able to
detect a change in the LURK Server configuration when an error
occurs.</t>

</section>
<section anchor="lurk-server-behavior-2" title="LURK Server Behavior&quot;">

<t>Upon receiving a capabilities request, the LURK Extension MUST return
the capabilities payload associated to a "success" status to the LURK
Server. These information are then forwarded by the LURK Server to the
LURK Client.</t>

</section>
</section>
<section anchor="ping" title="ping">

<t>A exchange of type "ping" enables the LURK Client to check the 
reachability in a context of the defined LURK Extension.</t>

<section anchor="request-payload-2" title="Request Payload">

<t>A "ping" request has no payload.</t>

</section>
<section anchor="response-payload-3" title="Response Payload">

<t>A "ping" response has no payload.</t>

</section>
<section anchor="lurk-client-behavior-3" title="LURK Client Behavior">

<t>The LURK Client sends a "ping" request to test the reachability of
the LURK Server. The reachability is performed for the tls12 LURK
Extension.</t>

</section>
<section anchor="lurk-server-behavior-3" title="LURK Server Behavior">

<t>Upon receiving a ping request, the LURK Extension MUST return the
ping response associated with a "success" status to the LURK Server.
These information are then forwarded by the LURK Server to the LURK
Client.</t>

</section>
</section>
<section anchor="sec-sec" title="Security Considerations">

<t>The security considerations defined in <xref target="I-D.mglt-lurk-lurk"/> applies
to the LURK Extension "tls12" defined in this document.</t>

<t>Anti-replay mechanisms rely in part on the security of channel between
the LURK Client and the LURK Server. As such the channel between the
LURK Client and the LURK Server MUST be ensuring confidentiality and
integrity. More specifically, the exchanges between the LURK Client and
the LURK Server MUST be an encrypted with authentication encryption, and
the two parties had previously mutually authenticated.</t>

<t>The LURK Extension "tls12" is expected to have response smaller that
the request or at least not significantly larger, which makes
"tls12" relatively robust to amplification attacks. This is especially
matters when LURK is using UDP. The use of an authenticated channel
reduces also the risk of amplification attacks even when UDP is being
used.</t>

<t>The LURK Client and the LURK Server use time in their way to generate
the server_random. Care MUST be taken so the LURK Client and LURK Server
remain synchronized.</t>

<section anchor="rsa" title="RSA">

<t>The rsa_master and rsa_extended_master returns the master_secret
instead of the premaster. The additional hashing operation
necessary to generate the master secret is expected to improve the
protection of the RSA private key against cryptographic analysis based
on the observation of a set of clear text and corresponding encrypted
text.</t>

<t>The standard TLS1.2 is robust against Bleichenbacher attack as it
provides no means to detect if the error comes from a TLS version
mismatch or from the premaster format. This properties remain with LURK,
and so LURK does not present vulnerabilities toward Bleichenbacher
attack, and cannot be used as a decryption oracle.</t>

</section>
<section anchor="ecdhe" title="ECDHE">

<t>A passive attacker observing the ecdhe exchange may collect a
sufficient amount of clear text and corresponding signature to perform a
cryptographic analysis or to reuse the signature for other purposes. As
a result, it remains important to encrypt the ecdhe exchange between the
LURK Client and the LURK Server. Note that this vulnerability is present
in TLS 1.2 as a TLS Client can accumulate these data as well. The
difference with LURK is by listening the LURK Server, the accumulation
is achieved for all TLS Clients.</t>

<t>As previously mentioned, the LURK Server may be used as signing
oracle for the specific string:</t>

<figure><artwork><![CDATA[
    SHA(ClientHello.random + ServerHello.random +
                         ServerKeyExchange.params);  
]]></artwork></figure>

<t>More specifically, the ECDHE_RSA and ECDHE_DSA mechanisms does not
associate the signature to a TLS1.2 context. As a result, an attacker
could  re-used the signature in another context.</t>

<t>The attack may operate by collecting a large collection of clear text
and their corresponding signature. When the attacker want to provide a
signature, it checks in its database, a match occurs between the two
contents to be signed. The probability of a collision increases with
number of available hashes. The attack is related the pre-image and
collision resistance properties of the hash function.</t>

<t>The attacker may also given a clear text to be signed, generate a
collision such that a collision occurs which provides is related to the
second pre-image and collision resistance property of the hash
function.</t>

<t>The surface of attack is limited by:</t>

<t><list style="symbols">
  <t>limiting the possibility of aggregating a collection of clear text
and their corresponding signatures. This could be achieved by using
multiple LURK Clients using an encrypted channel between the LURK Client
and the LURK Server.</t>
  <t>increasing the checks and ensure that signature is performed in a TLS
1.2 context. For that purpose it is RECOMMENDED the LURK Server checks
the consistency of its input parameters. This includes the proof of
ownership as well as the format of the randoms and ecdhe_params for
example.</t>
  <t>limiting the usage of a Cryptographic material to a single usage, in
our case serving  TLS 1.2.</t>
</list></t>

</section>
<section anchor="perfect-foward-secrecy" title="Perfect Foward Secrecy">

<t>This document uses sha256 as the freshness_funct, in order to achieve
PFS <xref target="sec-pfs"/> as described above.  By construction of the
server_random, of the output of freshness_funct we will keep only the
last 28 bytes.  The PFS property is in place as long as this truncated
version of  freshness_funct can be considered a CRHF and that the 28
bytes of randomness carried by the server_random are sufficient.
Otherwise, the mechanism described in this document will not be
considered as safe.</t>

<t>Details on the truncation will be added.  Alternatively, we could use a
hash function like SHA3 (or, more explicitly SHAKE) which considers
variable output length  as part of its design.  The SHAKE functions
allow arbitrary output lengths and  the PFS-input S  can be of arbitrary
length too.  However, for SHAKE128-d, if the truncated output is of
length d as low as 224 bits (28 bytes), then one only gets 224/2=112
bits security w.r.t.  collision-resistance, &gt; 112 bits w.r.t. preimage
resistance and 112 bits security w.r.t. second preimage resistance.</t>

<t>One reason why we have the hash-based solution to is to reduce
communication costs between the LURK Client and the LURK Server, whilst
still getting more than some security w.r.t. a MiM corrupting a LURK
Client and then attempting a PFS attack.</t>

<t>But, if we disregard the overhaed on communication costs, we  can
consider other mechanisms not based on CRHF for attaining PFS security.
See I and II below.</t>

<t>I. For example, as  freshness_funct, one can use an instance of a pseudo random
function (PRF), keyed on a key K  that the LURK Server already shares
with the LURK Client. I.e., server_random=freshness_funct(S;K).
In this case, the mechanisms to achieve PFS are as follows:
1. The LURK Client and the LURK Server  run a key-establishment protocol before every LURK session 
to establish such a new key K for every LURK session. Alternatively, the export this key of the key-establishment
run to secure the channel. The time-to-live of K is  one session only.
2. The LURK Server  generates the value  S on its side and send the server_random to the LURK Client.
3. The LURK Client uses this server_random with the TLS Client
4. The LURK Server checks the correctness of the use of the said server_random when the query for the master_secret is made, with 
the messages forwarded therein;</t>

<t>II. In fact, since the channel between the LURK Client and the LURK Server  MUST be encrypted by default, all for 2 steps in point I above can 
be combined into 1 step (without the need of a specially executed key-establishment): 
 a.  the LURK Server  sends the server_random to the LURK Client.
 b.  the LURK Client uses this server_random with the TLS Client
 c.  the LURK Server checks the correctness of the use of the said server_random when the query for the master_secret is made, with 
the messages forwarded therein;</t>

<t>Yet, option I and option II  are more expensive on the communication
than the version achieving PFS with a hash function. I.e., in I and II,
the LURK Server needs to be involved on the first part of the TLS
handshake to produce the S or server_random for the LURK Client.
However, note that the LURK Client no longer queries S, hence the risk
of a man-in-the-middle querying an old S is eliminated by design.</t>

<t>Option II above is akin to what "Content delivery over TLS: a
cryptographic analysis of keyless SSL," by K. Bhargavan, I. Boureanu, P.
A. Fouque, C. Onete and B. Richard at 2017 IEEE European Symposium on
Security and Privacy (EuroS&amp;P), Paris, 2017, pp. 1-16, suggested in
order to amend (forward-secrecy) attacks  on Keyless SSL.</t>

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

<t>The requested information is defined  in <xref target="I-D.mglt-lurk-lurk"/>.</t>

<t>LURK Extension Designation: tls12 
LURK Extension Reference: [RFD-TBD]
LURK Extension Description: RSA, ECDHE_RSA and ECDHE_ECDSA for (D)TLS
1.2.</t>

<figure><artwork><![CDATA[
LURK tls12 Extension Status 

Value    Description                 Reference
---------------------------------------------------
0 - 1    Reserved                    [RFC-TBD-LURK]
2        undefined_error             [RFC-TBD]
3        invalid_payload_format      [RFC-TBD]
4        invalid_key_id_type         [RFC-TBD]
5        invalid_key_id              [RFC-TBD]
6        invalid_tls_random          [RFC-TBD]
7        invalid_freshness_funct     [RFC-TBD]
8        invalid_encrypted_premaster [RFC-TBD]
9        invalid_finished            [RFC-TBD]
10       invalid_ec_type             [RFC-TBD]
11       invalid_ec_curve            [RFC-TBD]
12       invalid_poo_prf             [RFC-TBD]
13       invalid_poo                 [RFC-TBD]
14       invalid_cipher_or_prf_hash  [RFC-TBD]
15 - 255 UNASSIGNED                 

LURK tls12 Extension Type 

Value    Description                  Reference
----------------------------------------------
0        capabilities                 [RFC-TBD]
1        ping                         [RFC-TBD]
2        rsa_master                   [RFC-TBD]
2        rsa_master_with_poh          [RFC-TBD]
3        rsa_extended_master          [RFC-TBD]
3        rsa_extended_master_with_poh [RFC-TBD]
4        ecdhe                        [RFC-TBD]
16 - 255 UNASSIGNED                  
]]></artwork></figure>

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

<t>We would like to thank for their very useful feed backs: Yaron Sheffer, Yoav
Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric Rescorla, Mat Naslung,
Rich Salz, Ilari Liusvaara, Scott Fluhrer. Many ideas in this document are from
<xref target="I-D.erb-lurk-rsalg"/>.</t>

<t>We would also like to thank those that have supported LURK or raised
interesting discussions. This includes among others Robert Skog, Hans
Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin,
Richard Brunner, Stephane Dault, Dan Kahn Gillmor, Joe Hildebrand,
Kelsey Cairns.</t>

</section>
<section anchor="apendix" title="Apendix">
<t>## LURK Exchange for TLS RSA Master Secret</t>

<figure><artwork><![CDATA[
TLS Client          Edge Server         Key Server

ClientHello
   server_version  
   client_random         
   cipher_suite 
       TLS_RSA_*, ... 
--------> 
                    S = server_random                          
                    server_random = freshness_funct( S )

                    ServerHello
                        tls_version  
                        server_random        
                        Cipher_suite=TLS_RSA 
                    Certificate
                        RSA Public Key
                    ServerHelloDone
                    <-------- 

ClientKeyExchange
    EncryptedPremasterSecret 
[ChangeCipherSpec]
Finished              
-------->  


                    TLS12 Request Header
                    TLS12MasterRSARequestPayload
                        key_id
                        freshness_funct
                        prf_hash
                        client_random
                        S
                        EncryptedPremasterSecret    
                    -------->

                                 server_random = freshness_funct( S )

                                 master_secret = PRF(\
                                 pre_master_secret + \
                                 "master secret" +\
                                 client_random +\
                                 server_random)[0..47];
    
                                        TLS12 Response Header
                                        TLS12MasterResponsePayload
                                            master         
                                        <--------          

                    [ChangeCipherSpec]
                        Finished
                    <--------
Application Data      <------->     Application Data
]]></artwork></figure>

<section anchor="lurk-exchange-for-tls-rsa-master-secret-with-proof-of-handshake" title="LURK Exchange for TLS RSA Master Secret with Proof of Handshake">

<figure><artwork><![CDATA[
TLS Client          Edge Server         Key Server

ClientHello
   server_version  
   client_random         
   cipher_suite 
       TLS_RSA_*, ... 
--------> 
                    S = server_random                          
                    server_random = freshness_funct( S )

                    ServerHello
                        tls_version  
                        server_random        
                        Cipher_suite=TLS_RSA 
                    Certificate
                        RSA Public Key
                    ServerHelloDone
                    <-------- 

ClientKeyExchange
    EncryptedPremasterSecret 
[ChangeCipherSpec]
Finished              
-------->  


                    TLS12 Request Header
                    TLS12MasterRSAWithPoHRequestPayload
                        key_id
                        freshness_funct
                        handshake_messages
                        finished    
                    -------->

                                 server_random = freshness_funct( S )

                                 master_secret = PRF(\
                                 pre_master_secret + \
                                 "master secret" +\
                                 client_random +\
                                 server_random)[0..47];
    
                                        TLS12 Response Header
                                        TLS12MasterResponsePayload
                                            master         
                                        <--------          

                    [ChangeCipherSpec]
                        Finished
                    <--------
Application Data      <------->     Application Data
]]></artwork></figure>

</section>
<section anchor="lurk-exchange-for-tls-rsa-extended-master-secret" title="LURK Exchange for TLS RSA Extended Master Secret">

<figure><artwork><![CDATA[
TLS Client          Edge Server         Key Server

ClientHello 
   tls_version  
   cipher_suite 
       TLS_RSA_*, ... 
   Extension 0x0017 
--------> 
   
                    ServerHello
                        edge_server_version  
                        cipher_suite=TLS_RSA 
                        Extension 0x0017
                    Certificate
                        RSA Public Key
                    ServerHelloDone
                    <-------- 
ClientKeyExchange
    EncryptedPremasterSecret 
[ChangeCipherSpec]
Finished        
-------->  
                       
                    TLS12 Request Header
                    TLS12ExtendedMasterRSARequestPayload
                        key_id
                        freshness_funct
                        handshake_messages 
                        EncryptedPreMasterSecret  
                    -------->

                                 1. Computing Master Secret
                                 master_secret = master_prf(
                                 pre_master_secret +\
                                 "extended master secret" +\
                                 session_hash)[0..47]

                                        TLS12 Response Header
                                        TLS12MasterPayload
                                            master         
                                        <--------          

                    [ChangeCipherSpec]
                        Finished
                    <--------
Application Data      <------->     Application Data
]]></artwork></figure>

</section>
<section anchor="lurk-exchange-for-tls-rsa-extended-master-secret-with-proof-of-handshake" title="LURK Exchange for TLS RSA Extended Master Secret with proof of handshake">

<figure><artwork><![CDATA[
TLS Client          Edge Server         Key Server

ClientHello 
   tls_version  
   cipher_suite 
       TLS_RSA_*, ... 
   Extension 0x0017 
--------> 
   
                    ServerHello
                        edge_server_version  
                        cipher_suite=TLS_RSA 
                        Extension 0x0017
                    Certificate
                        RSA Public Key
                    ServerHelloDone
                    <-------- 
ClientKeyExchange
    EncryptedPremasterSecret 
[ChangeCipherSpec]
Finished        
-------->  
                       
                    TLS12 Request Header
                    TLS12ExtendedMasterWithPoHRequestPayload
                        key_id
                        freshness_funct
                        handshake_messages           
                        finished 
                    -------->

                                 1. Computing Master Secret
                                 master_secret = master_prf(
                                 pre_master_secret +\
                                 "extended master secret" +\
                                 session_hash)[0..47]

                                        TLS12 Response Header
                                        TLS12MasterPayload
                                            master         
                                        <--------          

                    [ChangeCipherSpec]
                        Finished
                    <--------
Application Data      <------->     Application Data
]]></artwork></figure>

</section>
<section anchor="lurk-exchange-for-tls-ecdhe-signature" title="LURK Exchange for TLS ECDHE Signature">

<figure><artwork><![CDATA[
TLS Client          Edge Server         Key Server

ClientHello
   tls_version  
   client_random         
   cipher_suite 
       TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ... 
       Extension Supported EC, Supported Point Format
--------> 
                    S = server_random                          
                    server_random = freshness_funct( S )
   
                    TLS12 Request Header
                    TLS12ECDHEInputPayload
                        key_id
                        client_random
                        S
                        ecdhe_params     
                    -------->
                                 server_random = freshness_funct( S )

                                 signature = ECDSA( client_random +\
                                 server_random + ecdhe_params )

                                        TLS12 Response Header
                                        TLS12DigitallySignedPayloads
                                            signature
                                        <--------          

                    ServerHello
                        tls_version  
                        server_random         
                        Cipher_suite=TLS_ECDHE_ECDSA 
                        Extension Supported EC, 
                        Supported Point Format
                    Certificate
                        ECDSA Public Key
                    ServerKeyExchange
                        ecdhe_params
                        signature
                    ServerHelloDone
                    <--------


ClientKeyExchange
[ChangeCipherSpec]
Finished              
-------->
                    [ChangeCipherSpec]
                    Finished
                    <--------
Application Data      <------->     Application Data
]]></artwork></figure>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC5246;
&RFC6347;
&RFC8422;
&RFC8017;
&RFC5480;
&RFC7627;
&RFC8446;
&RFC7250;


    </references>

    <references title='Informative References'>

&I-D.mglt-lurk-tls-use-cases;
&I-D.fieau-cdni-https-delegation;
&I-D.ietf-acme-star;
&I-D.sheffer-acme-star-request;
&I-D.ietf-acme-acme;
&I-D.rescorla-tls-subcerts;
&I-D.mglt-lurk-lurk;
&RFC8235;
&I-D.erb-lurk-rsalg;


    </references>



  </back>

<!-- ##markdown-source:
H4sIAKPi/mAAA+19aXcbSZLY9/wVafZ7HnIaQIsUdbQ06l2KpI5VS6IFyT3j
cZsvUSgStSpUwXWQ4sxqn/+I/5x/iePKq6oAkmrN7DxbeN2SgKq8IuOOyMjx
eKyarMnTR/rnD+9e6eNPTVrUWVnoi7Siv3f1WVnp7aOd9z9P9e5kTx+0zSIt
miwxDTxXZjar0gtu/oN9R83LpDBL6HVembNmvDzPm3HeVh/HTV7v7o3v3FNK
ZavqkW6qtm727tz58c6eMlVqHulpmrRV1lypy3PuVX28fKRfFk1aFWkzPsIO
FQz+SNfNXKmknGcFvNnWY1MnWaZW2SOldXWWpPO6ucKVXaU1/NKUSfDPrJjD
IuwPdVk1VXpWu+9Xy+hrU2WJezkpl0to655mRZ4VbhhY+dKsVjQn/EUZgFdZ
4ZzwM5a/sRn0cDTRr7Nz0+aN+53hdmSKLM17D8sKuj2G2dQ1wN7+CvNLU5jf
w70H9/T7yhS1PjSFmRv9rmyb1L2XAFgBwCYrGv2zaStYxUj/l0P/vJzD0PtT
fefp/eDHtmgqaMddut/Tpcly2GCa6GTJE/3nVOY2ASgNL/nlRD8tYWxTtJ01
vyxhhP5DWvOHIiOMbK50eaanbVWlV731Txtzrl9keQ5zXa7aurNw/bzN8jmg
87yz4ucf9vSDP77oL/nDq+5ys8lM5vfPNU1iYpJJ+xHQeTweazODqZikUer9
IqsRF1pEFT1P66TKZmmtgXa6lPY7oonf6ctFlix0WphZDniTIcJDV/BGrWdp
c5mmhTbc9jDPsFdTzO0v07QC8ACA4YekhKafGoAT4Z6nVX2ZNYuAlCc86WU2
n+cprOA7pLKqnLc0qv7rd3WajDP86fOtFoQMw3KCunRvKJlkYgqdLVd5Sj0Z
fVhdrZryvDIrAACtJEtSXort5a9//U/vnh3e29u///mzwmUfxU/u391/8Pmz
XTms63VZpbpepUl2BovP86uRn6hM4xLxZEYDJQtTnaeIWKu0gtkvgXrxfZVE
UyvhqeENMYDjSWaadA7MhLpeVdkFfNcfU8JQ/AnmKGse4ebmMAL8XEFjmFhT
29dgn2FA3iHfUtdpTdDMarWAJecw1OxKeqgZSDVOHt+vgX60mUM3GSJgA7QC
ewUYCz0yVqh5dnaWVgTxofeAD5V109mLt8GCq1RVaR6uGCfZQTDcGnyUIGkg
mlh8ybNl1hCyqLVDSLdnZZ6Xl7gDnc6XKTDSOXCQd9MDQoLjw6MXx6fwDdDx
DFjwHFcaosooRg9T68sUNt3UipvCn0ONH+7v7X3+DFh0oJeIR/O0AdqHNxjr
V3an6hKg3tawXAObhWif1kilDnUFHxVi/AxX1hYyzD+9HB9NIqk4ho7G1BEN
/eL9+5MpDJin57z6hUE2kPJ+085C7wnIRIszhzgYgPoozZFVXqk3wDTK6mPN
shPeLlIm7O1kXmQ7+hd4iGB+XpXtirauTqGhyQHSQBGAIktEPUARGhcWn50X
vP0yr5QGzksz12dVuYQ+dLtCZmyWGjcOmDW8DLhXXhbRzxN9jH9nADWBDSzC
YygQA/BYmtLSXCkemVDPvZNfaZMkwMqJVBlzLPnr91crpnptmyKCAUtN8hZ+
caB6e1kgbR4evdEnVXmRzfHbEdPNGyQpeoH4WfrJIMuaKNm7syw17RgBOV40
zaoe+60CTFtxb0A2gjw1ag0rU2U1oY7C6V7A17KtA2hrUBxyBIosCCfW2byR
pTGgRpwnLp8QALhzLfu7KkFOMkktACOjAZDhInboRXa+UDlseK4vsvQSUG76
/uCdRc0sbc7GJlmm47oxFVMSPagXKe6Afzau0v/ZpnUDjNkLBWOJFfgebBct
RvgRinpdElwBrG7bYDfoR1VWCUwamZMIF1DEgK4WuFAAKzC9UBweHjieA8BS
246XMgMPGekO4IXAVLqEAar0vM1NhdhUzFFcwiQbwR1kWEBgDYkQnE1bY7c9
COEfCCGS38og9+KZI2tANgHqX0NcPuoOIH4kZDTXSZWiPpoZwBQZAGYI+J0b
Yg51O8O2NQu5Grh3DRzhgrikCnqFcWGLRYdg0UACiFDqPC1Shitxri1LxXMV
DL9lMQHh6l8JZ7ilZyCGNG58hmIWO0MMO4eeRYCSsCIshx0a6yK91NEsr1Yp
kRUhxiAUcHhoxnrQmUmYwXYa4EuW8AAUwnPwPVzCBIiHpqqQrzp8sNqTly4C
Kt+v5VK/kNQmcMxLUMqKsnHLtisui07PrGoMgm5L1WXeEpFif26CLEFG4SxY
9BNxVCARWfqTGIWVKpT7GYB9+wEo4Ff1jmAftgDgMfeglxEBBQ8N6MllDmRD
KgqoIaoqz1uLIRNQqqGDYPSAiSGz0DWQhZlluejgyIMMEGvWANux7HoFtiDa
RqBkzIkHgTSBLmGKyAmsXAxUGyB1wNUMiHE+0ahlipJ2EPbck5f4Bwp0If1Y
/1RWoZ6XGjeMuIZXW4IViuTsydoZyhyHVfgKbl/Fmxyoa7h/dZOa+cihQKjM
wfJq4OcNiHwYG0jY6W2jUKYABqUDCmXB4ht3GwQHa/vDb67RUi36LrOkKpVT
GTeNpHmkKqAFXlrUx82ngOKb9mAW9DhRB4hTwN/AYBwNbHeGpJ4A1s4tccEW
NiLcBPNiLfI19FsBfcU4mKfmo2G9njhR2ES5JuFOAImZizIjpaIA0xAegDD1
y7ReCPy+AH1Z9fp1UyHatlQgq3QUtUwNKbxAx4D/BfyXgiYAMqduwTYQrA4Q
kgw3Q0+zhJQGnN1EvyXwKDYKFsPk4OzLTIw7y/9RmS+SK9YoMmZuoGQymee4
y8z5AD5DvExbVlYj4XrKHRgYVRMk/pqsU2v6merKwtUKHLVG4LDoXt+90TOT
fATAef5KghCZrA6ZtimuQKefsxwiFYkU10AssIxRhwewgY3jpyZDkWYah4nC
F9bsvVI0V8R+ak7ov8rLK+gE9xIthGKNwUY2G2iiBJtSCc6gSoW2SCAPuEcy
rwDDcQlsbKJm8Z1+T4yozMtz0m30ARBwcQUafceSr1K0POrAEuU23ipSa9gv
bft3vCsvgAnClNll4EyaBf36WaDxgzPnacc6u0n7FaCoIaUh0N/VFu034UK4
AGBG8I+aO/D94SuyBIS4CnoCbCQKlg4JPNbdKY92hzBOpfivufd5yKphB1vm
XJEpuUZm1Yot3PqRUv/+7/+u0qJd6r+Sn4nmo7d3QZxv7927t6M+gzXnpv1Y
Be8mZsWyGM2F7TvQAl2O3LaqzenSgGCqoBv4ju/7304RHKercqG378rLvK50
7lrtB606D4Pm9+CtNJkDMLbv+ynDJu/ugQWWwnzDxf3wAyugQCcXJm9J+SbV
Y07KSM7GJXE6hK9tQ1sA1llTJmVOP4rBwauu24RMAlo4mNe8AadpVZW8esWO
Rxgym5+uzBVaq6eoogK2IACUHQhdgWA6ZSg5UCbA2jseiKgrUKJO4S/SZAle
8QOCTtQANve0AlQDdkPgsr+TKVLAGk7P2iKBST3oNAQmjVwGVrVCm4936GHY
A3IRUKD09o87djnd1fA+bVhPmshadu8EXcOvSQt7BD/vCk54YJYlzOgMHu0F
LeBX+OVuBx+mDZj0wHuYVAQjQuQOKV0/saT5WInfuHnoKPSJ3n0MvwFtOMJ8
3OnYc4HUv0KOYpAuSbMdvLDzV+/1RSNhW0Ye6d2dR+4RfgK8xq+fyYj5St0y
eGzHdfCthbXf39fZXL6Cwd/c3QPVpjhvFo8BCJ4PPSZ2oogpe3IfDZG+UgcI
GzZhSD/Crd/yb24hTW4NtNwKjUsVeqO7biH0y70CS+PYDkPu6o6/sFZrXHcB
/xV/bZUCi2WfhhYqAGEDv4K4i2butCzWbZE9oKoBqq1Zpg3awmw2sl8msItV
r+tR4DMknQ/DRjiVFZg04nop8zmpXvXCfEzVEkdDsxBVSeApVdWumtBrD2rF
JJ2MWAUzTYMGkCi2tvHYsQSSlAmpLmT/dXzYsPJIyYTHw3vmQAJzgn/jrM+C
SW+flC92JppA3n/sPQ6ZNQqt+vNMOI+deei/9mjRmfWIgwLAf3Ncf4UkUihx
HIiWs0iTj7XVCdieDrd4SdrvmxJtR1Bg0ceU8fpViDKke4V9uZlYGZKFHosw
eqLIYMZ1ODgAgJRikyqaDDlKhknFoj55UWFT0e8Pql5+FbjjZSpi/eNLAG4y
gqxnn2lhWTYYYbABFvb+BP0QCWfBQgOEl/2fD+wGefbdc3Zx+U5ZUE70WgJb
oomUg1HSwEaoyy50hnCQWl1kJsAwSzWoUn73nX4nu3PC4lrUSuh1zL2iz/Ez
uucDTcfuqIh48pfH4QSnpvUVL5jF3r37p8BYSakQyQXc68Rk1cu5aDORjIke
BrKgXBmYiJ6bxjxGtYI5tdMMhYjxfWDetpMj0e3C2URT0c8sS3iGSsK6t+Hf
dx/uky4E/7y3u0f6n+3j5N2zF6ZerFnIkWbNhZcRj6c7Sspj1gSkQ9jas1OA
94KbvmMlJyH6F5XnsRV3ABGwBbXweeeyfjDZn4BlELZnt1TYnmW71YZOqvQ1
bf2UWLVGu1+QQaYXfjaM+2CyO/j+z3bnVqT0iysCgDRhOQ0QJeENgo4nImgr
WCvimIGqHhENZ2TRnmXo/GZOuWpnQD3Uq+6GWBFjao+bSrRW9vQ1QDeM4YC1
Z1kFqD/LfFARt8P+e5YVKAAPpm9gpUfH7xTIL9S9iyZyg/mpCBvgkZn7SB9x
S2SSKOahSc0GFwcAwljand0HVpoP9oFy7/jw0PVBTK+d/Sts0AlNCPDzZXFW
rrOySGXYf3iHomYdNAWoY3dlkY4vwRQnmNADioK9/eXFsx1NbiagSmKJwB59
ZPoEBAPMQj0rq0tTzTXhWQK7ryy++/51v3/bMb5xUqftvLSY/cxNAQhoB418
q4EMKDdIZCRi4t5NBAcVaE44T3rlHnLTiAq1TFi+kRk24MwLneR17AgYGEZI
d0L0qSKqvfFoVhS50VRHHRwaTa1lBUxszm6KIXrTNQFbQAAeDJrOt5c2X4vn
inxxsvPUys4/7E0mk73/sXt/vPdTl59t4H4/8tDWhLS2ZI+5/QJLBzVxA48b
dWccIamZlaADAUD7MwesXKOz9zUExBp0IbZCLDfQQKP9jrEqAgTyD9vbo24n
DkB2nKBXIPKhXpXt9TtQaYSZ6A4zEdVmdVYPpNgw/zc+fiusn/x1xvMCDFfC
nDvQHyGoxBdO3samQR8p+RXrlFKHLBY3/SQdgFSN8SBDnM3plLXJ5r4njN2X
swa9luh/Jf2bKUVIDRVVfCc0kcgxzh7ry7Kai94rMSqMYyu3sEWar2q/BuwO
gTeuBXg8EU2JJzRIEFxCZdSGnuW9y7LNkRl85OFoUfL272o/wTHqbrAudk4p
YeFmjg4IQMqJ3ShyWIB5tshgfrU+eTbV7L7qksEslTgtMIcMRwP9FQ0qA4vq
yKTDFyARJvrplT589+LZCGxPihXA2kWIqUEhxnhB5g5yIjeQtgMl6WOOCZLF
pST+QOZVw2FGJCnDETuMfRdnqakzDAMAcgAizsl13lyCgCzgzVp/2qUcnE97
jCfUV2fh2592d/ST/q97vMLNK+KFkwGOC5jDvo8wEhm+3EV52VJYRn2GflHA
nGyJxOrBQKJ0r5iP7TPln6GWghABlDwHK62ww7HkAjtzEFZqEFb60ya4IFg4
8KJCq3A8dgPzmJ92OThD0f66h1kIYJmVutEOMtmFe9YFIe7O0J7t7gDeP/MZ
G0jejmrLtuohPfxJAZYRWECNnmIIxPBLI8UaAUxylQEfmctirRIUezqs1+Q9
Zczge6AwRlqG9RAg8TuLmzXJQgOHMzlBoLOi6c5IZeyJCTt70n8PkFXyTbqC
RTJxQmu6LDCKR/8e2+nVblrzwK0lndRkXExRC8Tu0WNm3SSyLuDRwHXQ25F6
Riyuk+mLtx9+PgLkWIGRoktSogA6SSsJCkWacx6bKcZZMYaWY0739EycGZ31
6GyvckwPTj81O7H3Q/mkmz4IohW5oBuqHNORnrUNgSXetYl4m/oUet4aeCXA
g65WvyTTB9DeUxjlP/UXCQKKo39NhUwawFy2jQ0hWw4fb9dEH9TU8Whdp6H4
g94V7Q+HMcnhRx4cm5cGnGAbJNOOkyeBTiNiF7ZcpC4mYVZpSZvPdNbn4w48
Dj49LjgAn4y1IoM5iqhdQJ+oM60DGLGL6e82sInpTp9Sfoc8AqA3z+qkrWur
b6GCA/9jihTKSAyKIjNguUnviDaAWSLbRJMUi2Yj1JAkdIgWr8ARVs1Yhv10
knZXFeXMoISmDAoayjXjpDDMkTOY1HIGzwDPUURG/FSnZ2dZkmG4PGwAy7Cy
KfsLL+WsJRNVghW1EnWU6MMFIyS8MZGweczNXn+Yvhc7glUuZ/dCX2v1TLCJ
bA5QYqoqE1X6fNmctkX26ZSyhYShsLfgDLn27Kohr9u0ZIxjPHyRwugTmU+g
UIfcdZ5WGW4fxc8RC+NVxOu2EYBAZ05hfY8020bxLJ/EAPnzncnk7q+P1cDU
+nKqA8vvBdIaFOwtvQMmVL8X7h/6imYhlg1uj89moa2BTQ+T3Pr+1CBisIiT
wNsVkXKSZo7fxqapyFeOhMmWI2wpendKDt3aQTySjxT2Qc+puI9j16mLyEc+
1Hr1mVcYeXedB9ratugRB5kwEHmxfgl1C9NX7FfuB2G//+DXxwOuNJ5EbGfi
CkNJ8zRFL3hZ9R3ESd6Qgzh8Gyy4JqNkP2DKgeeYbZQhK98irgpzMpwwGfDV
vO+hPEtm6z1UgbOjxqyO7eP5uaU64EUfHIKsrJiSIU4F4thJ0CbI6STEkcQ6
cqbh5rBB6wgYfXtuUSsJqk+6gHp98CcxkNJBsJBdyVkpHeRXKf5aJGk33hJy
jijgIuqkHFhh5UIFtiJC9MSGpHAJL8ByIem5ffL2xY6YiF0aBGXKtPOsibrv
u55EswqSlywEkNBh29oqULkaPFgFsqSxGitF1ru6KOpybDnXHWY0wK2mekdC
HuHs16N1XV0AWnexxHSxeZPLyh+Esaa+5EfW/YT6kKTTFSas7Pbjsi6+llpf
MHCOrKLQ5YXJOJdsm11EsNqXzNHEly047ht5B3nGSiTmdIC4Kks0/wq1NZB/
saU53SOrJUiMejaPo4OzA8HMONfNzQ7Iv9PvUJdK7W1cfWd3aQpZqA63qxVl
gsPyY1ffKJpBp5/hqewPTAXTwhI+ZRNHXzo2DtmdPloSBgrTjPQjFw/0wT29
7ZFqB7GM89gUBxusSrs9gHmoFd7rT5dojMAnuBYiRG++FBdW4YmuEPSxAtEn
dEecCnA8XWHYGLMnca2XGQZbG2tJMYij/fCJO7IVExUao8wbcFyglDkobbBR
Lohgc1swhGTtJRkJdWDQMouz7LytCA39PgxAC3iyD2cTDkVbLNGjekE+rpkE
7YF0MJPSYEok5Zcatm2kFzxcY71r3qir2UPYxMnakxilcJWhwa46tvHlosSD
UXmJw2Tni8amAddXRbKoyoIUZpfthSEU0XUia7pi9ss9UBSdJxUDWKSNpTQf
TpG5zozkEkd4gpz3/hAZkXe564oeUD/XqL6c6I4neRKbR9sJjFmX72dM0Ua7
nY6UKcqT5cxE64jeWqeVi+j0lEfsAYz3hF2W6DLCBErCUlzpg428S6LUgs0+
cuIzzlj/IJ+fzcQJiSTOrHM86yzsndMKWIFV8ajrQoNOrCzLeZu3lCDwsL+S
eUoTrq+ZfbQVvRBT3Q3+/MInFk5eHU53J/csh7LcWM1TzATGDHmSucushsdA
W7OOt8jagp6rmpq9qMSILfoD86CzKE4tWr+OkfUbWLXL7Yh2rjVPnJ1kKa1+
7AMwViPXA60XMbNAezjZFYN9QPpY4z2iE590MuDuA03jDmwAp70PyJT+cd4A
mXsxIXTa4mMG/c2CQRiloNQ9zMuyWzuE+Z5UWTgAhu4OqEl+i2Lo0uHcjcYP
9QiqxzEhHsbUQCoT5g1q4s4zZzEqODUBksAGPvj4RYBtPHnG+UKwvEyStuqp
1wqFEWhVpYRXnGZZOs2B07hsvi93himptdWN1VYnWZczDh1QmY1MbC5jJwkZ
kxrrtZnJaM8MJzd2WkTJjBH0wICwyYzKsqBrkhk3ZiwqO/KmWLSg44P7ew8o
m6GfCRWY672l2GDeplC0DjOf+nlGejjPCF4t2jy3GUaYjbK799BmGeFX+J9y
raWXk7dvMWvhmkSjG8S8r4lf35/s3iIm7jtBCLtO9iVF+VgAKjQ4PRgMda+D
f5DodouN+IeCTy8H6hY5VOuyCCRRahjAX5BSMBJdaeQXM9JB1N5004MGEgfp
4MpgFoLIm1ixckJETo9jmRp4BdVbrx0GWcTQwU2IXYXE7pGREluGPHlKDZ3U
6DnrFnTIqs6WYNqGJ1MYF1WUMNlpysBa6ypEjrTOAdf3oHinwqD223HVEe9U
dPzJ5p4mcTKrB3Uq6VkhyL3SoiysK7dj876yTJGAyp4OZS2kTtH+atL8aoNL
Jlhoz3ty3ULRefMZBRMYoMotTNYQqLtd7Mlqe/Dd6i89ZcyLDD7osSWuI/ry
eVgeyovrJWCUzq98sY1IaRKPdVhPIyyioboyUpjM+ixfmpYk+BKzlXl+aX7v
VxFd8quceIkPfdhjMDu6e+ZDb+HYWzo48WEf+LnA44jxHh+e4KkdffH8MXJc
gaRjEPcm+9Hrwtrf/Xn3/q+6erxuIPg/msdvGenunhvJ5cAigCg6sS5N+laZ
bn+7NGJ6MrXhlYNijvnLB/l5WQHrX2Lg5RRepOROgYmOBgDLkLugXhHredk6
jNAQOPU6eDpQMeYI1ASOREeDAhHstrUycZOzD8RaFimZG4RiuAho5wI/Q1oq
03e4Oj5/keY5VshJNJ8bk0Ot4eEb751z7h9cdpB/rLY76fKAqr4DR+c7zrBM
VwsQCli6JugJ4aUHeiKk951IIoJPfrZnfkE6MI9tory82XOe94yPsVYWzUjs
bMphId/Jc/oVHVJ8Os8yfYIWphY7nIANsCmAsQAMYBnYf8HBHiqkUi+yla00
Q1gVVqgSbyHrUuSwLETmBDmD3TgBegUx441ixtbjRjLUZz1QyoMdz6e2O0Yi
C6zOMOeTk6KtMy3Km+4Kd796ft0uHRYYrpbejda5Oake+C/5YDyXtKl0q1XO
GyhGUif7mrxgPnFLTD0CNvYJUhEb9dPy2epGaYUdwn5fPBettbPHfHKzC4b+
FiPZVtCFb8p+aUyTrdIN7Vi6DuDM9kn5dic689VVDQjlxNPzsSgv83R+nqoO
9K3r1ZY+QzzBxJC8JC/RTLw7XXoYAX358wmM+oJI4sqkiGD5FrHW+XUJeCUm
s0jRvAsur2SIwGhbmkWVpuMVcB89TRYFYKwLNomPpE6QiejtNy//27sdZgFB
9EgU6GfAucbThVlmFQcE2VMhJ1hD7e+fkEnu3b2HrHW4HF10fLLnuKv1heVv
hWRb6IQxTz+BZ2M9+33inQ4q3Bx0tMyej0C0j6RF/+DXQJCB8ZU9aQr4XOZO
vTB7wgYFBkucjzyxpkZ+FQ3hU68pF2Kqn6jquf5eb8+e7yTCfbD+BAzH+Dq1
mZWmYvK/eM7zowQ+LDlj3apTotiL57RSYY4RD5ghWZE/vO8LHcosvOBQFNfT
IjQC7JtnCUWJpPSGElc1lpGACQcHG50vjmtpYb0nKWA6Yh4JE0GWAFxA/N1q
G1nHhDiE/3WHk6XpXXoBn+/QC7ZDHmKin1OOKFJWqt4dH759/fr4zREso6FC
E3iuMjXkf8glmJb9JbWASXwG6yA44oy+8FxGZHSEyP0B9A3Q77IoIb7hwDs6
tOPShnEUyTrAO6mBFJmjUz9Br6Lw93oVtaif/x5qc6NIQxu5vKCy3JroY4Mh
MdcvxgaadMmGFwz+yaoqRu+PUfqRuDxPK+tJjbgVvRDFU6g3MuxRkxNwPelA
4t/+raO3eRg80bJGfKnrAcJ2odYK32NHTpQ7BE+DlQM2PLH2y/ZzfHhBf87o
T5ko/MtNZQdXoAcSJgKug9wvGpPKazwP86LoeIHXdNAqVCQN/ghG2O6PKD7/
uL//EGSBcC+beJXkZrmSul/QJf1sM1UOkUVRe0tg9Av0AyoeTMtFUPsNcED7
cicGhU5t1aUH7Eo4MnRsc0FsWpbzKHzKCW+ZwQHZhFBxJ127Xp7Y5h3w7mw2
eiPjyxk6mks3XmefUFWF0A4ZSsKKugLNwyercfVCF3QPjiDGlkWACT1u0I38
d5wqWq2zPia3cE7NsA5w7TWPa103ZCFxKj5yv9hPgX6XD/3Mvu7mjXqsFtHI
h/MdHF3uioesyyHhMJSLz7hUAlSZyqqhImqiaK/1YHXmaoRc+wlCQy4uX7tm
d2IzuTg7SO+CSnL/hm6wwVwa6U7KU0m4lQFkXWMhX5mlZ5QTAlASmC8d6KIX
HfSCrFortpUjIFFIWZW0eQVE1CHKjXR2pkgbOrUH7jnVneP2WN1yziVTtvqA
dDkmZCsplilBKFFqsLhI4svANiR/JfbO33hcJTlFaV9mB1kmcgbEmmgyrNrq
FnkJIph3B3ZHfJCikwfcW6ZpHWHdqQVw8AVSfDh0q1NPZkvqn2C/KujTL5XK
d/gSBbhF7Glbj7rKVWnu2TvDCBuSt81Z48ay4/AF8BWUSxgGE9auWaYKl+mW
OJjHFQOaGFTkx++oYsPkNZBw1UkVDdk4TOS3R5c1RZfVb40uI1tUf7/oclhI
a9hRHr6x0V9OxcQ5tdVawx5pg+Lhm9LHedtcMxU6zqpAt0AnBHbEcwQkyeqJ
GgwZO9eLJPl21hNGK4vSCqvAY7NeS+l21FFWcvIfUPEp1K8DVgVTZgPY/xZW
xh11QOfkYO0Pwnsv4mRoMrdVmFhfOvSToKoewaSY2zu9aX8vcAnvi8eZIwJ6
u9ssjAywY/6duXTFDSKn/A+/18+Qn6Hj+cHevTtctOF0sCDC738IW4p7Ht4f
fv0Puxjp3dsf7/70uDObP9678+Ojgb5wHad4GLbf9jN5rGFt8wBmXd9/z/lP
0DhFvPjDHejx3r2fbKWObleEIyBIA0iGzaQWSCeO8HNW92IJUTNudJitwJyZ
thk5MOgLQCzrDMHvdiucxK/4UwuHFvuuHmP81sFB/78CiJvFTAYaYh11sq1Q
J6sNaxr14NqjV0F9G3hVdiUKxw3uCRkw4a50Q3ptXEiNYG8rvHF5Hlq2BPmI
+iM6FtoJAuqPBrBhtKGBT82/ectu/P+LW952cDYRHg0CV8rWOQ58pV08y7+k
VWcDus99c9rQqJoSqkvpH+7u/fTYm6iHAcMftlR7pAPWqhPfpQ1vdWvShUXI
QYrbKv0stKx+8cc7P0YFzbFepLmMqvlwpTCnp440SzWnyWF1aEnTgGECkj/G
u2eGAm5RliKJHZxKeNgsZBwb6uWgZOGIX5cdSeELL3uDF/r1dWwT5yaXZGJk
P7CmXmVLitkOG9d0DqbL5fpdR/X44zx/m6dDUyUtSizIANB4SLRjOXTAthH4
mDLcgX8xj2DqHksGaNDzUyprzSnEcscPji1H6FEGhy4y0BD0icMmG0TpTFZt
qonUT2rdc5bwhEr1dBm3juE9oIBpY9l+HU4WmTGF7aRCf1CVzqu9nT25bsZy
qhX/p8B0LDp6eBroiDaOvel1fkbzPT58cXQcnr1wMcrhpiGeOZs3RO3IdGSz
AIGjXLR7MBq3ngSjAQfPE0+QtTJ/w6uMTIJlqP+SOn85HzGRipshzdgS2qUP
8tmj6LfL9rKeGxNKAVdkMTg9iUnzWGSa02pXZc0lKkI06XdPFRS8UfoxTVfC
TJHRuYCn93VIbj5OR44dFj0zM4bLZWiZKrZMJ1qtdaNt9f1ocU3mvjfNewUk
3uRCxlFDa7rEO2X0lpQ6ts6Dgao99mw6W6HGFQqjEKIUzxk+tMx9hQFJ2n8q
Kj1sFeOTjdawP9qlKjQALVZ07iijNywviOG0JgX6wA6+znQdNlmDZvJoqN0g
vltNqIeYXLzDdCeE0KS/yX0RrF1i0T17PwZQ6CGwd55w0Ib2OoCPm9jNvb1c
J/yG2MluL24gQOum72xGTFeo9rchZhjhlrLz9ppIvMyJDrqJc4WzCLHehC2u
IO8l8Xs3KdXOtzGpcD3HnRoOW2FHUaIQHqsGNXLMxYLDS5iqlOrz8GUbwnrd
NIEipHCLjXirLnENhGhd1RJm+XEHvVyDoRivDbHRqWfcceKPognjxDBUS3HP
iq7GWXPDXlCQIzgG1Rm8H1CTwZEBu1NPjF6xci5PM7kIizM7LksCJTLPheH7
P+S447JtWjorGl72M58M3lZh97MjbFzpXsL+eom11jjwqwLvJB0Bs4F3Cghg
VAIhQ1eV5Xi/YGULdFB9FnudgaZb9SSLqJy1zD7wOhKfmcIVZ2rJm8AJEuCp
+tSSCgHJ9Tq0pMzeVPXh6ITZi70AqIjhYPEE+LPcuWCvDqqymmIug9PQmB7G
48EIlIeDBc4UKjlD0nsI2ygG60uSZBWXmevU4u5kBRwiy7CogvVPi/B6yXC4
8LCS5HWE506tYMeLBGm6gRVPAefBTPtu+XEpyUB3uKSAdy4BSg7rMeyDi5BQ
0aai4VbZUcMHCPwQ7pBYjJPZknJfbFAivhqHziqFt1Gac0zibDp39BiY0VVt
k6iUsCGuUuS8+oYCW8iSALMB66mMQjHvlDlyJKvk9s33C18Yh4x1vvND0NvO
52meAjWkxQxkHwKei/Th2chGuXyConSX5WhR6uRQqXX7L23s3YSnLf2ZvbIK
Q/P2IKUtbE0UxbEcUdsIW4j3IBaNKGsT0IxQykUSJUVAX7Q5bppT3pqSqjvG
S1O8NE7FkgpLYhTwnThyfJWADto7XjOI6EluFlRcMGsNkw3W1Oxi34xT0bAy
kdQCwGJgrZQugi9LvNf22u301h4GgCTEa9Qa9CmlKIrNqvCtUXXhckurtsJr
lGqUUsrf/JQ1Am46MA/GjmHNUfBpaG23kGhxxTSYabhXV5Lcg5uIVr29mYa2
IzjGjhUuDRgDyzYXyqy5trc1f/nkSnBoxWEOMcYrcoakNkAdl8HHH1zncgDc
lcWibDAwr4Nz+VxdKxRvtg5WP/Ap5aksjkmQXDF6Oa3Sym+64bo4l5AIOT5f
HGzzsNGx8++HzqJ/v/7kGL/9Kr2yBycnHHDcQUceOenW6BH+uIlxN73i4ZJA
jXLH/Z1K2kFAMpuE/bi7QaO7x4KyqCqhyglyH9K80xVd2MTI7C8ZJvbOXIvK
h62Yfc8c+bHCTcLf/cSM1ROgEtTNqnVkKGHTZhEwgEshFZf97dNHiK7kNDRe
J9XUhLDI5kd0+piYIodeQx0N1CglV3HWYk1zjNhW6itnwe1/JihOl2E1SLoC
l25aKtrljAuc+worKPpScQEJyKhggVwozKx5zKUAUa8brHwXsOmwyrnNyra6
hwOSu37LFtUM2F64wFFwdi8Y2VfPCxcrkGNNzompcDFsSoPkLvkyOr+s4YJ+
sqyrcFGuBq6Vpi3dgUlAdeCjCx7JbALCVb93t0Nq71rx+3V+XtkLDc1vQEar
hCa2zohjWDMpG6+WmOGOt+kFDNqqpJGCP2Cm9M5L9AxJWKfgmys2wLiOb4cl
mwLi7V3ygUWmIq7wzFYaEVElpV5ddu3xUd9/xGnS4mKric0nBOussfUd4oou
dM5CriAO/YAqSkYJ/flxURx79IFWGlWEA0PfXVDcRYTWlsXu3rS+tDcgEp9E
cObyNpYeVVgekEI/VtWwQlJSF31F67CgteqWsaZi1XKIwq6qm6gbOggFnxSW
igwqpcSJL1RMfKKxijDCnrzgQZmDyG4YWfCVbbNqBwMTlynfBk+ORargir3k
aMth5jbXSOSDBzArR68Z34iDNVdwenmJCF6zsgFTonTiubL3VsG4vYHl8uug
Vk9U7lKOiO49VHzmBrrgNdHdQFzn0XlNOomTKFWd6jdRrtaR3OfpSopHuU/x
SSeCCSurKpwi7Kc5o6IyR3KJklgPsmjyp2LbGZk/KEH0QY43Z4qhS3WtmYOg
2mg6JaDz7GOKCshdvV2CmkTJPkEhKnjy6tjWvLbzqhWd9yBfMu+zpGDjdNnR
woTJAQ7ZTurKDVzz5c0Au1nWVGiVRV0x4dFCAQ3GTOFTHdxg7hra4wJNWcJI
L8rLlBQ+upgYh9zdeziej6wl43DFjodq9ZntY864dYl/7e3t83GibYuXOyN2
olEBpYLOOjT03g97T3Z39xS97ZxLl5NqAtxO9yuRJ4AYP2lowf3LiwNFsgkI
7r1uz17qdcv6AmN6W5CnsyZ3+xXiADlXrMwb83Eef4MnZf+TcYHuCazIumwL
F6YtMbtog5Opr29jDK1uVN0gbgKciEUuOc/MFJx12l2Q0a+z1/YeLxae4Wkb
d0AHvTBL+wZyCRbTsOqnbUM7fYnB4BqFcMVzwzq/C8O5XANrIyKhq7Esjos1
FajARJz2EBQxDjIbmkZuhseJ2BVN1DRN9Uua8suXXIAVLxBj4Sfig+qtDxRd
KKg0MFMrKnyCCyRVonN8vng/XW4yQg+ETVdDZ8QrrePKkO6qLsCM+RVKChjc
x8qikzovb1Kv+/GrnQlei0a8LDE9jlcHUoZ3itMqXWZzWLxngwtLA9Xyosbu
EuulnIWgupqSoIzuskrul7H1OdGl7BrZixawXBeDiHLmeq0mXSbK/lapKQiL
pXu9XUHFeFYKZ0t13ZJWEittfXBaLTrjxk05ztHPAJ2Q+Ur7bueM3GUylLbd
SSzlcByW2mbjg+qccmb/UBmogWNjkyj9WLZALqnNulU1HaZ4Q3mwOKIvD0Wa
bdKQDBVwudsn5IaLgYJu+IwrfVvjOS7MSqXC54BsNCG+StDeWeIjHA1fVYdJ
Yi9fUo0pUOvpqBKS0xrf/fWo6J33VreeURKDYSs351uu9yRRnw7f4Nnjl3Ir
C5K2Ij1kOZNYBt6BS6/rbVwQlk3HUQssO86OQeuBBhQEnJJckRjpdh5ppc1E
9ydcu3t0r0cGPCvaA8Nt0EEnA1P4x0OIP6WuvI2wafvlpSYmZRUhDFggldrq
uYHoUCTJiAxF7WROZ4WBhOw6djPz1axw0mHUi9AUdADEJjlflPmFP3nLx0at
kiXA9xV2xE+BMpweTtFnGAPUQjDad6c2FdHNByEWFCVp3TA/3Al0DEzxNkhL
SxjG4Isc+5XuaevEJMWrY+gAaoqWU2EcAZGqCIqL2wemF/TTfcyIn17itLYO
2W+CFVMy4tt0EwNA4dEGxymdXMwR6abTn0f/53/9bxzz1UQ/BRF4bi7w8hNg
EU/BDktN0Y70yUQdoLBuYeojfYi3v+MdHLhjTyf6XYapH3RH+d6d3Qf65fHx
sT5u0VaBFU6vlmDWZu0S9ky50Ck2PcFIAdit2/ju9D+fgMg+AU0a1A/sZqRX
q4neHe/ex9y3c8BdqYng7bUlsvXtztU8Oy5YhEjyyq+T0wpeHrw56ARuJRDD
4TQaw4eKg2yhDfFae+u6D+kF9ws/kgh695V3qThuH+k/v3t2NH7/9OjXgW7A
RFpxN++mB6NB7yQXv0FM3j7aEQfDhK9jpv54fN8r3/nLqa/0x39lwanD8XoO
VTdfajK+/Yfa3dFjYO/UndxKMfABeBwiPMY4/V+p3Z591r1pe6gdN7lrf15z
B/dAk/1uk/Cu7eFR7g03GV4QN7nfbRJc0L2myYNuk6FybHGTh90mQ7d5x01+
7I1iy6qtXcvune4oSQytgSa7/SZ8tGx9k71OE5v9tqHJ3X4T3f10mux3mkhm
elmd2iz8XpN7gM979+7pD28OptOXz98cH/UG8XQ2SI2U9n1LWvxNxCh0KJ8o
A+wa+NifKS9n3Sdu4+g2CHR/QRufNL6mzd2wTTeC/gVt/IBrOASHB28Eg937
1yOJ5tvTDxJb1gS12NrWLPsllSvkyEFFqqopPlrlJas0iX5QHc9aULjpgh4U
gY/0n0yFDH+RYpRwpP9Umgv1JoN/TRusXFToZwY00DwHwYIH2p62nC3yflEC
GEDi13ilmTwEjg36am5G+jVwzzemztvifKRQ/Oupyf8CSkMO8lv/nLX1hTEV
vDhNyqbRz/J2UdEdQ3iTGwheU/ddfqhmUnlmkbFpNWMRC5uTn5OMdVCg0EoM
Ci6LSKoauXZ8EisRHWXJZ3XKiUTAOxu+bZquC7I5wqGX3CzRp0puj1q/K2cp
qJjTj+X5iK6BUNOVMR9HuOwL06By/DP80ZQj/S/lokD4NHWNmUIHOdgomX7f
Lk0FehtDi+L0YBUXqd0IA9buEZtMR6AzvTLQyfMsz5fohfyXMtUvsnyezlBG
jNSrNK/B3j40WYXz5qS0A6zznn1y2XiuXCziCFokqDJw/Ustd5UqexjC6rTu
E17zYT9BzWdCSfwjCNPaQKxo19YGcBUh4uP2Dunt0+AIUFREAmaHys7p70d6
MpET5paPbagbOu1e5bPuRb2+j5tcoaHWz8AHqzdWN0XR3wPWDeZz3ezxcxhA
9YlAcn2LMLt/U6/YiZwPwPvD1r0WAOCoLNZ3+Qe7nbqLV0Hs3rUOL95dhhfv
0ht/PqS35XTZKk1+jYvDRp8OLgXDr50rnf5xacEvUjCyq80vrynpuxHAQQ3e
dZ/uvXSb3nVXRm96KSLPjW9ONz5duz96A1jdJmyGfvT5bdQZfWLnyRM8U7L9
32/W1F9lYpt/r2/YdCvKs9vS39+wXcxIb9oqAteOu/zKPr5ZJ/KxVCCJqdeQ
wdoeBivO36ob/HQ0vFu196wnbr+2kzX8Zd3nWViLeuME6I0DvriDFP4jTPSK
3vlJD72jbiPwyQXnrrR64bxk3xSBcAq9zzdFYPjzTRH4EkVgsPT831MfGKg/
v7HrAGbfJHj4+SbBv0nwryHBr5Hh9vKKv6X17gA2KIVuJZRxAs63eefTHYwI
rZHWv1lmYvXf03WKxuAnuZUkHFrMP7jY/BtLzEFZuebzFaXnNTfk/MeKz2vw
JwD768gi/qrSdHeiD6m2Lvo1I07xZSJUvmN51i8WpDeVo8OX1txcoEqeEHk5
rGS8Bejk81WF4jdh+KXC8EtkIRm2rraFo9BvIvKbiMTP/4ci8h/Qygwe3szg
/CYf+fNNPvrPN/m4Vj7y1TeuWuLfxKk7LPu+3KMb5K+hhPQ/DYhMmrrPYXPx
/ePDUfCN71h6Rhlea2Rq7/N3cxJf18kXcH2E1ks8D/SVePzXCgRGpwTxc0Nu
fu3nK7oN/TnNJ5pwcPtr+Ob09/Hid/7DWO1Rdp41mCg/pcPGgiGb3b1DHwen
vy27/TtFSm4ZKglTbG+oBce8aTMRrWdcg7O7oQLN072xCj2kCw99ors0Nr14
PcbcWnf3uLNBif8NcZ+voQX8XTSA/wsuOzuBOb8AAA==

-->

</rfc>

