Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E39129ABD for ; Thu, 29 Jun 2017 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6xb8aQrULKh for ; Thu, 29 Jun 2017 12:02:24 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA614126D05 for ; Thu, 29 Jun 2017 12:02:12 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id i2so82246379qta.3 for ; Thu, 29 Jun 2017 12:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0L0jPyG9Cq+Gbgei0NGfi14pne3Rlwmol7RqTF+iM2U=; b=IuhpPX1iw5ajhtat5MQHaarwe1724xVwY2J574/MZz43Rs+m3EEoXQ8KZPz/Jv9XCV gjgkDnO1Lh/MWsN2wYAMs/TNRe51cVprmk8lXc6DizdCdTKL/ETslfC3X729DnJ3sO3Y RD9+cXo7YFvgiujMwKpDNwtmHIkDm79uiptS9cJgwTM1MihY2Szsec9CAeGqIPtu3sFJ zTbK8tUt022Ox8N2xiqqaCDLFlmsyi+QyS8MdbKJs2MmUYxtoIuKFSvVWMu+ZWQw3A3q tEWYcq7sgWLBVdTWsIaCg7EHHkyFgbWQ5a1SuN1IlYxQFxQfNM7C1PHfS9NE4UBmhDe2 ueiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0L0jPyG9Cq+Gbgei0NGfi14pne3Rlwmol7RqTF+iM2U=; b=Lk89fBc3B5ach6GYoB1UvYeBDWZHZHZBwfjot0+CuTo1tHv3t3NmH2hzP4Yy8QRPLG L6e+qQqNiHfKD34fIIS0yw59LCuIwUAZVBn8gpIG1nqazNoEdRyOwmy6S2CkL3ztOiLF FK03jf2pVa6mJ/REGkEzFwU3wYghYTwAM8vvgRaTNIWgAmqcUMCOapMmzmMplvp7SJws fX0aVb5Q1IXw/3vsAxInjSQFQvaCevTa5tmWyW36E32PDb34WRgdEhWFgIZs/8ZzEo5s H6cz83VmOwtiAL5j8ZWXU6qQV2wbPpE2dgZxiZYgIg8lp86Ec4fABqJYKUJqeU65rtlw Y/JA== X-Gm-Message-State: AKS2vOzFE2dQgSrz0dcM/CQ9bXdGismwixxH8dXxh/qGRTNYFFgF7rwX JE+4CL2uVjjNmOzY X-Received: by 10.200.9.55 with SMTP id t52mr21947108qth.107.1498762930343; Thu, 29 Jun 2017 12:02:10 -0700 (PDT) Received: from johns-mbp.lan ([191.115.107.144]) by smtp.gmail.com with ESMTPSA id l207sm4318914qke.36.2017.06.29.12.02.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 12:02:09 -0700 (PDT) From: John Bradley Message-Id: <97A1224B-5B6C-41EC-9FE0-CA0DE53746E1@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 15:02:05 -0400 In-Reply-To: Cc: Leif Johansson , Benjamin Kaduk , IETF Tokbind WG , tokbind-chairs@ietf.org To: Nick Harper References: <149868793805.5443.4284920405751222901@ietfa.amsl.com> <20170629024818.GI68391@kduck.kaduk.org> <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144dfa027f58005531df0fc" Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:02:26 -0000 --001a1144dfa027f58005531df0fc Content-Type: multipart/alternative; boundary="Apple-Mail=_079E6D8C-19FC-4992-B425-7E25BF8A101A" --Apple-Mail=_079E6D8C-19FC-4992-B425-7E25BF8A101A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline > On Jun 29, 2017, at 2:33 PM, Nick Harper wrote: >=20 > On Thu, Jun 29, 2017 at 2:05 AM, Leif Johansson > wrote: >> On 2017-06-29 04:48, Benjamin Kaduk wrote: >>> On Wed, Jun 28, 2017 at 03:25:13PM -0700, Nick Harper wrote: >>>> Here's a summary of the changes since the last draft: >>>>=20 >>>> - If TB is accepted in 0-RTT data, keep using the early exporter = for >>>> the whole connection. There was some discussion on this in Chicago, >>>> with more on the mailing list. Chairs, can you confirm whether we >>>> reached consensus on the mailing list or whether we should take a = hum >>>> in Prague? >>>=20 >>> I am a WG chair, but not a tokbind chair, but that question does not >>> seem to make sense. Consensus must be reached (or confirmed) on the >>> mailing list, so deciding there wasn't enough feedback on the list = and >>> going to an in-room hum seems backwards, procedurally. >>=20 >> Judging consensus is sometimes tricky. I think what Nick meant was = that >> we may want to do a hum in Prague /in addition to/ seeking = confirmation >> on the list. >=20 > It is unclear to me whether consensus was reached (hence deferring to > the chairs on that judgement). If we don't have consensus, I'm fine > continuing the discussion on list and in Prague. Let me check that I > understand the process properly: first, discuss (on list and possibly > in person), then if the discussion sounds like it's reached a > consensus, optionally hum in person, and then confirm consensus on the > list. Does that sound about right? Yes >>=20 >>>=20 >>>> - 0-RTT TB cannot be used with externally provisioned PSKs or with = a >>>> PSK-only key exchange mode >>>>=20 >>>> - A new TLS extension is used for negotiating and indicating use of = 0-RTT TB >>>>=20 >>>> - The replay indication TLS extension has been removed >>>=20 >>> Some discussion on the httpbis list brought up that this document = should >>> mandate that 0-RTT token binding is only used in conjunction with >>> a TLS stack that provides strong anti-replay protections (i.e., zero >>> additional replays possible and one retransmission via DKG attack). = In other >>> words, the time-based scheme of (draft-02) section 6.4 should be = removed, >>> and perhaps 6.3.1 reworded somewhat. >=20 > I read over the "New Version Notification for > draft-thomson-http-replay-00.txt" thread on the httpbis list. My > understanding of the issue raised on that list is simply that there > are attacks on 0-RTT Token Binding if there isn't a strict global > anti-replay mechanism. There are still attacks possible on 0-RTT Token > Binding even if there is a strict global anti-replay mechanism. I need > to consider what additional attacks are possible without such a > mechanism, and if any of those attacks require less privileges than > the attacks possible with the mechanism. >>>=20 >>> (It also brought up multiple peoples' sentiments that 0-RTT token = binding >>> is a bad idea in general, but this may not be procedurally the right = time >>> to have that discussion.) >>>=20 >>> -Ben >>>=20 >>=20 > I'm aware that multiple people think that 0-RTT token binding is a bad > idea in general. So far, the impression I've gotten of this sentiment > is "0-RTT Token Binding is not something I have any interest in > implementing". If the sentiment is closer to "0-RTT Token Binding is > such a horrible thing that no one should be implementing it", then > maybe we should discuss that sooner. A good point, if the attacks are still possible then supporting 0-RTT = is problematic. =20 On the other hand 0-RTT is a big speed boost for resumed connections. = It is hard to imagine that servers are going to disable it to use token = binding over the long term. I don=E2=80=99t believe the WG has any real consensus on this yet. The = draft spec is helpfull for us to discuss the issues. =20 I encourage more discussion on the list on the topic of the draft and if = this is the correct way to deal with 0-rtt if there are counter = opinions. Regards John B. --Apple-Mail=_079E6D8C-19FC-4992-B425-7E25BF8A101A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline

On Jun 29, 2017, at 2:33 PM, = Nick Harper <nharper@google.com> wrote:

On Thu, Jun 29, 2017 at 2:05 AM, = Leif Johansson <leifj@sunet.se> wrote:
On 2017-06-29 04:48, = Benjamin Kaduk wrote:
On Wed, Jun 28, 2017 at 03:25:13PM -0700, Nick Harper = wrote:
Here's a = summary of the changes since the last draft:

- If TB is accepted in 0-RTT data, keep using the early = exporter for
the whole connection. There was some = discussion on this in Chicago,
with more on the mailing = list. Chairs, can you confirm whether we
reached consensus = on the mailing list or whether we should take a hum
in = Prague?

I am a WG chair, but = not a tokbind chair, but that question does not
seem to = make sense.  Consensus must be reached (or confirmed) on the
mailing list, so deciding there wasn't enough feedback on the = list and
going to an in-room hum seems backwards, = procedurally.

Judging = consensus is sometimes tricky. I think what Nick meant was that
we may want to do a hum in Prague /in addition to/ seeking = confirmation
on the list.

It is unclear to me whether consensus was = reached (hence deferring to
the chairs on that judgement). = If we don't have consensus, I'm fine
continuing the discussion on = list and in Prague. Let me check that I
understand the process properly: = first, discuss (on list and possibly
in person), then if the = discussion sounds like it's reached a
consensus, optionally hum in = person, and then confirm consensus on the
list. Does that sound about = right?

Yes


- 0-RTT TB cannot be used with externally provisioned PSKs or = with a
PSK-only key exchange mode

- A new TLS extension is used for negotiating and indicating = use of 0-RTT TB

- The replay indication TLS = extension has been removed

Some = discussion on the httpbis list brought up that this document should
mandate that 0-RTT token binding is only used in conjunction = with
a TLS stack that provides strong anti-replay = protections (i.e., zero
additional replays possible and = one retransmission via DKG attack).  In other
words, = the time-based scheme of (draft-02) section 6.4 should be removed,
and perhaps 6.3.1 reworded somewhat.

I read over the "New Version = Notification for
draft-thomson-http-replay-00.txt" thread = on the httpbis list. My
understanding of the issue = raised on that list is simply that there
are attacks on 0-RTT Token = Binding if there isn't a strict global
anti-replay mechanism. There are = still attacks possible on 0-RTT Token
Binding even if there is a = strict global anti-replay mechanism. I need
to consider what additional attacks are possible = without such a
mechanism, and if any of those attacks = require less privileges than
the attacks possible with the = mechanism.

(It also = brought up multiple peoples' sentiments that 0-RTT token binding
is a bad idea in general, but this may not be procedurally = the right time
to have that discussion.)

-Ben


I'm aware that multiple people think that = 0-RTT token binding is a bad
idea in general. So far, the = impression I've gotten of this sentiment
is "0-RTT Token Binding is not = something I have any interest in
implementing". If the sentiment = is closer to "0-RTT Token Binding is
such a horrible thing that no = one should be implementing it", then
maybe we should discuss that = sooner.

A good point, =  if the attacks are still possible then supporting 0-RTT is = problematic.  
On the other hand 0-RTT is a big speed = boost for resumed connections.  It is hard to imagine that servers = are going to disable it to use token binding over the long = term.

I don=E2=80=99t believe the WG = has any real consensus on this yet.   The draft spec is helpfull = for us to discuss the issues.   

I encourage more discussion on the list on the = topic of the draft and if this is the correct way to deal with 0-rtt if = there are counter opinions.

Regards
John B.

= --Apple-Mail=_079E6D8C-19FC-4992-B425-7E25BF8A101A-- --001a1144dfa027f58005531df0fc Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICzHx1bJzmjK09vF6OqheCw5SSCr UWHuQo9/XrKFJXbVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYyOTE5MDIxMVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQDEy71BuSEvr/gFl/MKN8zHv73e+q5szgRdF6k53uLKL6oY LBnWOLbHy11sIml8GbANTCQh8SFCfke0/I9ZKB/j1d2/M4ZFGYVbW98Ag+dX/fQdar6J9LgHVp7w ppUy6Q1prF9sI2Yz1FHsbY5z/bzPd9CF52hR0qTY20U+6cDT8OJBdq5nL8sQkHsG0sMaMsrqxWyI ZeEwTEv6qrCxvPg31rzW8JDdXkMDo7dbNWUBSQkFABcXBdJE54miSCYLyxGPnSBlLQRWSIQ2Z4C4 epIWAfNe3oDNKpLJ0HwlEK2fjg1tIZjORId2dCejYaoGt4tQbu+dp9IZMtdXEzPDo6Ul --001a1144dfa027f58005531df0fc--