From nobody Thu Jul 22 12:00:06 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12A03A0DFE for ; Thu, 22 Jul 2021 12:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 d-TBeBb3NCWq for ; Thu, 22 Jul 2021 11:59:59 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641AE3A0DEE for ; Thu, 22 Jul 2021 11:59:59 -0700 (PDT) Received: from LLE2K16-HYBRD02.mitll.ad.local (LLE2K16-HYBRD02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 16MIxrYV013040; Thu, 22 Jul 2021 14:59:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=FTVqyK+tbyzZCPlhKddV0x6OkGLEAX5ik2xfJw6Qh/Hr3s6cpYjgi+cji4nNJTPKtqmo0PqgMK2QrTMnIBmtYbNa62TJ+1b9BY3v+3LKbCVGTLLgZkuXMYYuMUj49urHyd42K9jgnSbHqwuHbjjjWyii4t/cx8bc4tI8Si1T03s238tna7bo3CmjpLkm9e1YIWI0KWxnjm5Q0hphN6QHIzmv3md3fQ4RgDW638GYx3s01+j6CoZ0e0ME53yYn2XVFiHYjCKw4mbnxwBz6y5ueOMTZChXGOH2m+zsTG4LtYppnvJ/QxlliMaQTkIekizI+peYNEL3IEsYQvHqThnHhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GzT4HYV7ZRiyGVea4RqPZiybYf9Kp9/PX8QE5Lr56tI=; b=S6Y/RiGLJMoc33T7iutyIuPEbpXHrOeGgxRZZ8VWq56443FSIQa6pLjPBoNgwt6hCb9zhZvMxWk2mpenLfwaG2KwIRWCwFqd9UFWf4vsm+VYKxiirUqhf/Oy+XEO9OYcjg82pHLZsD/7LAWn1pL+kgs6e+0R8XSrqehL2dg/BgreAADnV++k9vhNNDvFwm68EZQFsBAlM/UKxKuJi5lIqwlgWX720Q67QZvkREhVwwrOH6Ehki2z9K4nhQLuN6GF1Jgkp16ksWUIwXFdJK9wxGFIcnyKS87WnEZS1Z7y1+9P0vLdt+A0ugDyqXK1NuLghu+Hk88JZ62KwN3gcOBj+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: "Kampanakis, Panos" CC: "tls@ietf.org" , Douglas Stebila , "Eric Rescorla" Thread-Topic: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt Thread-Index: Add+tHdLT0JcZqpyTOWwQ+3dwbToQgAQ2naAAAm4oZD//9bkAA== Date: Thu, 22 Jul 2021 18:59:47 +0000 Message-ID: References: <8674700eb241430cb5d09d46ba331e1b@EX13D01ANC003.ant.amazon.com> <40F72451-DA9B-4E71-9A7F-5BE9A6EFDD67@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=ll.mit.edu; x-originating-ip: [129.55.200.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f28c267d-3da8-4701-cb3f-08d94d42e076 x-ms-traffictypediagnostic: SN5P110MB0544: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iT+AsLwWvW8R8klocn2clb6SyeRLLx796WrS+p37Nb75ffnX7mlFHbN0qSs0mkoaMBvvOrm/oSCZjzQwYxpz9cvvOY1TWOnHD5k/ic+yWTgRqErPA+FRTbGCq4H5HCc796WJcYgymYDTALxK6lKnhae1jrbHhjYEZIC2c0aXM6Xs16cWHGeyHsneeUtefAA+2DQV0iQD8pIpxxlclAh2ET46ei/ATJBKa94Cw26VsWs3QtbYVc+j4AUBWt8NDld+2qfNxUA9i0aQ5vsdBKz3LA31tqHI5G6T3cfIn/IT+i2mykEHxfIMTyPi+xjDZLVOHih1LasRJAJguX/4shyxXHNF4oPoAqyO2MBItd8+IyjZaZcTmZv9FmxH2xzUOegjxOfMg0SIkd3z+Frw8yNVFjDTAX2uWQUzcCDbktJGvytiE1tlWp3LJ3TefJFimpdZwJspdnCxaqPQFPkx/I5wKcR9i2zG1rY1HnUHXu7BuqGrXSlqSnQEFz6iTd/xPcIsSE/TnB4qKyxHiK3zQ3pJfNjBgepxzFlNU25wNosmXagGdv860g3uAlPc0oAzuyErfgIH1dq9wiAglA2ko9jdPWAAwW06qQDUWuQAWPFBLqAvZyN0gqADN7yaN/7Uq0zv7ZwTYSr7JzOIaziFDdqZTZ1lBpzpsc+J/JXKdGK1U3A= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(5660300002)(26005)(66616009)(966005)(66476007)(66556008)(33656002)(122000001)(86362001)(54906003)(8936002)(75432002)(6486002)(316002)(71200400001)(8676002)(6512007)(508600001)(2616005)(38100700002)(76116006)(6916009)(186003)(66946007)(6506007)(4326008)(99936003)(53546011)(64756008)(83380400001)(66446008)(45980500001)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 6aWDiwWtqA3EWyR4gdbF8E1MM829nAwC5c1sCTkpTZaTdcPmRKntX2FSJoQKqV6kCfXZcKXfHUb5fCrXzppF7wax/cT9THJfDBW87G197/HM1njCJocSMNhdy5JIj9pIvuCC1N5Wn95scepIE0wMgp+/yNC+mE9wM8ttZNYPtQ+fB9e7Lk+vb0cWd2pWT8KrZZnyRV2mwj2bll0BL6LTsy5rS2QupfyUlDdfN93Cry5ZTlHhw+dueCfDeo+968L2jwcKMC2o3xwnoWKbMW8WFFqrb/bXXDjhTBzPX4aoldC/JDoohuACF6N+9OvY4B4VHAckfcoZskqO5tZujKidbPcW1vLRkJls5aDQZ1bT9Dc4FjCw9corml4mcdZ6pQ9WXovTlrzy0Vc8hRx56xw23b8k+1Wqf7fda14+qBujQjSIl7DqQMnZfNAwojl20n6xi+0MbafyXY0iLExFFDRhEkxZ8BV35w2AgwETa8Vk2LDIT0QWUphn6kytCvl8SvaAxKEYtF9ysPwKH0PYgZHKYvIP+qjecqKeQRa6pGsZTRScx6eCQUY9BRecajZGoxUWstG9z7lBRPgjHu7rRYTieHHjznXRZXpVCBmEPL+X27sEMv0XfK+c2gcTeurhFkvw6E//pbiwZaEApzhj7eyWP+/k11znsLf9+JYfs43Zd8Sqde/Xf3VcpS2nKCqqKDTaMdPntRzrkrmKRrwZinObZg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3709810787_1096455040" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f28c267d-3da8-4701-cb3f-08d94d42e076 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2021 18:59:47.7698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0544 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-22_12:2021-07-22, 2021-07-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2107220124 Archived-At: Subject: Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 19:00:04 -0000 --B_3709810787_1096455040 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit > >> - can cache or fetch the peer public keys in order to do KEMTLS > > I did not say that. As far as I can tell now, there's no way to fetch (outside/OOB of this protocol) peer's pub keys or certs. > > draft-ietf-tls-esni does it with DNS HTTPS RRs, but indeed it would require new efforts to make it happen with additional operational challenges. Most likely it won't work in my environment, but need to check. > If caching the peer public key is an option for your use case, then cache management could be an operational challenge for clients that talk to many peers. Exactly! Open question for now. > If caching peer public keys is not an option either, then you will have to pay the price of an extra round-trip to get the peer KEM public key. Yes, and this is what we've been planning for. In general, one extra round-trip is not a "pain point" for my use case, as long as one round-trip fits into the link constraints. Now that you mentioned the possibility of caching keys, and paying that extra round-trip price only once - we'll evaluate the implementation costs of doing that. Thanks! -----Original Message----- From: Blumenthal, Uri - 0553 - MITLL Sent: Thursday, July 22, 2021 8:49 AM To: Kampanakis, Panos Cc: tls@ietf.org; Douglas Stebila ; Eric Rescorla Subject: RE: [EXTERNAL] [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt On Jul 22, 2021, at 00:46, Kampanakis, Panos wrote: > > Hi Uri, > > Thank you for the clarifications. > > So you have a usecase that > - want to use PQ algorithms > - is significantly affected by an extra 1-2 or 4-5KB on the link > - does not send a cert chain, only leaf certs Yes. > - can cache or fetch the peer public keys in order to do KEMTLS I did not say that. As far as I can tell now, there's no way to fetch (outside/OOB of this protocol) peer's pub keys or certs. Caching received and validated keys to ease the reconnects is an interesting idea. I'll need to figure whether the comm savings outweigh the extra complexity and branching of the protocol. > Although I don't consider it the general usecase, maybe KEMTLS is the way to go there. I'm 99.9% sure it is. > Other good options imo for it would be draft-ietf-tls-ctls and rfc7924 to save even more on data put on the link. Thank you! Seems applicable - let me check. Thanks > -----Original Message----- > From: Blumenthal, Uri - 0553 - MITLL > Sent: Tuesday, July 13, 2021 1:17 AM > To: Kampanakis, Panos > Cc: ; Douglas Stebila ; Eric Rescorla > Subject: RE: [EXTERNAL] [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt > >> If we are talking NIST Level 5 (and I am assuming you are >> discussing mTLS), > > Yes. ;-) > >> ...have you calculated the total CertVerify+cert chain sizes >> there assuming 2 ICAs let's say? > > More or less. ;-) > > My use case has all the ICAs pre-loaded - the transmitted chain contains only one entity cert. I'm sacrificing flexibility for performance under constraints. Size is the real enemy here. > > >> And would constrained devices or mediums that sweat about 5KB >> really be able to support PQ KEMs and Sigs at NIST Level 5? > > My tests showed that they *do* support PQ KEMs (NTRU and Kyber - haven't tried McEliece ;) and Sigs (Falcon and Dilithium - haven't tried Rainbow ;) at Level 5. Caveat - they do only Sig *verification* (which suits me fine). > > (I posted benchmarks from Intel Core i9, but they work acceptably well on the "smaller" chips.) > > Also, sorry if I did not make it clear - it's not the *devices* themselves that sweat 5KB, it's their austere links. > > > > -----Original Message----- > From: TLS On Behalf Of Blumenthal, Uri - 0553 - MITLL > Sent: Monday, July 12, 2021 11:39 PM > To: Douglas Stebila ; Eric Rescorla > Cc: > Subject: RE: [EXTERNAL] [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Let me emphasize the reasons Douglas brought up. Note that I need to use NIST Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other algorithms show even worse ratio between KEM and signature!). > > Communications costs: > - Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes of Dilithium => 1024 extra bytes to carry over channel each way; > - Signature: extra 4595 bytes each way, because in addition to exchanging certs (aka "signed public keys", which is inevitable) you need to sign the exchange and communicate that signature across; > - Total: 5619 extra bytes each way. For peer-to-peer broadband connections, you can say "so what?". But my links are *very* austere. > > Computation costs (ballpark, on a powerful CPU): > - KEM: keygen 15us, encap 18us, decap 14us (say, double encap and decap for PFS-providing exchange); > - Signature: sign 113us, verify 55us; > - Comparison: 134us for signature-less KEM vs. 215us for TLS-like exchange => almost twice as long; > - Difference may be negligible for Intel Xeon, but for my much weaker hardware it matters. > > So, for constrained environments with austere comm links, signature-less "authkem" is God-sent. > Big servers that need to support many clients (so they care how much CPU cycles and comm bytes they spend on every connection) would appreciate these savings too. > > @ekr,I hope this provides convincing explanation why "authkem" is needed. > > P.S. I know that Falcon has much more favorable sizes - but (a) it takes three times as long to sign, and (b) it uses FP calculations, which isn't great to implement in my environment. > -- > Regards, > Uri > > There are two ways to design a system. One is to make is so simple there are obviously no deficiencies. > The other is to make it so complex there are no obvious deficiencies. > - C. A. R. Hoare > > > On 7/12/21, 20:59, "TLS on behalf of Douglas Stebila" wrote: > > Hi Eric, > > The main motivation is that, in some cases, post-quantum signatures are larger in terms of communication size compared to a post-quantum KEM, under the same cryptographic assumption. > > For example, the KEM Kyber (based on module LWE) at the 128-bit security level has 800-byte public keys and 768-byte ciphertexts. The matching signature scheme Dilithium (also based on module LWE) has 1312-byte public keys and 2420-byte signatures. Doing KEM-based server authentication rather than signature-based server authentication would thus save 2164 bytes per handshake. > > We would still need digital signatures for a PKI (i.e., the root and intermediate CAs would sign certificates using PQ digital signature schemes), but the public key of the endpoint server can be a KEM public key, not a digital signature public key. > > Douglas > > >> On Jul 12, 2021, at 20:30, Eric Rescorla wrote: >> >> Hi folks, >> >> I have just given draft-celi-wiggers-tls-authkem-00.txt a quick >> read. I'm struggling a bit with the rationale, which I take to be >> these paragraphs: >> >> In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke]. >> We believe KEMs are especially worth discussing in the context of the >> TLS protocol because NIST is in the process of standardizing post- >> quantum KEM algorithms to replace "classic" key exchange (based on >> elliptic curve or finite-field Diffie-Hellman [NISTPQC]). >> >> This proposal draws inspiration from [I-D.ietf-tls-semistatic-dh], >> which is in turn based on the OPTLS proposal for TLS 1.3 [KW16]. >> However, these proposals require a non-interactive key exchange: they >> combine the client's public key with the server's long-term key. >> This imposes a requirement that the ephemeral and static keys use the >> same algorithm, which this proposal does not require. Additionally, >> there are no post-quantum proposals for a non-interactive key >> exchange currently considered for standardization, while several KEMs >> are on the way. >> >> I see why this motivates using a KEM for key establishment, but I'm >> not sure it motivates this design, which seems like a fairly radical >> change to TLS. As I understand the situation, in the post-quantum >> world we're going to have: >> >> - non-interactive KEMs (as you indicate above) >> - some sort of signature system (otherwise we won't have certificates). >> >> This certainly argues that we need a KEM for key establishment, but >> not for authentication. Instead, why can't we use signatures for >> authentication, as TLS does today? I.e., the certificates would have a >> (potentially post-quantum) signing key in them and you then use the >> KEM for key establishment and the signing key for authentication. >> That would give us a design much closer to the present TLS 1.3 >> (effectively just defining a new group for the KEM). >> >> What am I missing? >> >> -Ekr >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --B_3709810787_1096455040 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCB5GXynOJG+z+k5WgrmTYc1vFvigHji6591sJFW Gei4aDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA3MjIx ODU5NDdaMA0GCSqGSIb3DQEBAQUABIIBAEdf+hEq28BzV0kM7NOntafj6tc6P8u8Z0fU5bUB wiOGRKp0S4XALj1/rvkd4NefuDGiRfTOQZU3TaJGERh/AKT8JqlYz9MgQ7LLJ79r2pO+xxKa C5KgZnpcXM+YZ1i/kFet4ldL0Vreou7A90gSInG2NUOIibYP4Uo/tcTTbkPYtbxv+1SJCNIe 5lINs0frGwagWJ89nWue34XtY3nLnR3+xiBn60Q9iEJd3U0L+hv+IIQzRakOdTCLEALrHIH+ 2mL+vcOglaut2D68iN6tOWwRpoDWeE3Etek/9IYDe144B196OoPWJ2VYECRZOfh7/apoL08K nSnwWhmQUPxbbuc= --B_3709810787_1096455040--