From nobody Fri Aug 10 22:47:22 2018 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9134E130FB2 for ; Fri, 10 Aug 2018 22:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=gmail.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 xxPkFxj7cIJ4 for ; Fri, 10 Aug 2018 22:47:17 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 957FF127332 for ; Fri, 10 Aug 2018 22:47:17 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w24-v6so3800446wmc.1 for ; Fri, 10 Aug 2018 22:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=rBZJYBF/JtFBuHG4e8JFj7vOwHYYJ6JgW+/XdrVU3WU=; b=VaJsyGJ/BoEKdkbtKImBqtLBhR79nqOZajD6z9LKw7LOYwmxxn1VqCbCWK2AiOgGkf NBgTilS4KI6Js7Plwr/6/mkZnJHrxIjumrIOP1dUVyAQDTPL0EmElVD7+IuMUxZJsG9Y MSqjCcgQ1Dkd9XmRkuvg9HnlBK9TL4qwAqHe0Cte8IErDtQa3nLPgrL0ujlF/DIT0XOx 3LTFjJ8UP56wHCfwRazswV8qtTIJrfRgtigg1WW7lo0QhhMQ/4baHOW4KUl9Xp6um3Bu jTwmPxIOLVbvw83ML70N3IYdLlCb+hbDMkTt3eXGWtLeVHUgCI4BMSl4IqBeHsZX241i Sb9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=rBZJYBF/JtFBuHG4e8JFj7vOwHYYJ6JgW+/XdrVU3WU=; b=Z/Ix+4r9QSpCaVgHv0UU6K6Fz9Sd/8Ltk5WK4Wh6cEXAvHUM7MgyWsP0OiIbmacK/O u9qvVqI6LI44VZ+l/UUewH82bgRz65YhB1reG1RwVDU9ugneou+d4s+WgdegWFTFpXLf MGwWi0/6NXz9VZ9fKamXwsxh+5buQyUiiMWGR3pKJRK/hlKB9BGMKIiWA1d8Pi2qtFSQ 6nHM0wy+nnYc53EikJxSka453PAMXlKVwxckS0+iU0/8vuFsoQwa2XhK2HUgJ8gkSICi 2+e3N95PgyI2d51C4g/x98h4iZarNkXP51oJISrSJi7gJXCieYmPl89LwBQ/g2lD2XZS cAgw== X-Gm-Message-State: AOUpUlHNDXTX8Y4yoosMsHWx20yH19dq3ZrkszvHLnmvqiGEErOJBXXB lR1FOKUFmh3odUsBN3F0xrs= X-Google-Smtp-Source: AA+uWPxWPmM2KWBh0f8Y2TVqx076N3m7oHerLB30gr1nE2lAZQCrLxuZ2Mf6twKpzmLTzIsBpfAS4Q== X-Received: by 2002:a1c:1dcd:: with SMTP id d196-v6mr3290261wmd.114.1533966436180; Fri, 10 Aug 2018 22:47:16 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id e141-v6sm5561343wmd.32.2018.08.10.22.47.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Aug 2018 22:47:15 -0700 (PDT) To: dispatch@ietf.org From: Anders Rundgren Cc: Samuel Erdtman , Eric Rescorla , Ben Campbell Message-ID: <4fea5830-dd5a-1709-f0d6-c8af28a78f94@gmail.com> Date: Sat, 11 Aug 2018 07:47:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [dispatch] JSON Canonicalization Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 05:47:21 -0000 Hi Dispatchers, I'm currently trying to develop a JSON Canonicalization Standard as an individual effort: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 I have been asked by the individual submission editor to get feedback from the SEC and ART directors but they in turn have directed me to the DISPATCH forum, and here I am :-) There are efforts creating an alternative to JOSE JWS since there are JSON-based protocols not benefiting from being cast into a form converting signed JSON messages into something completely alien to their unsigned counterpart.  However, after a number of iterations and vendor feedback, I have come to the conclusion that the "Missing Link" is not necessary a new signature format but a way to canonicalize [*] JSON data. The scheme is currently implemented in Java, C#/.NET, Python3 and EcmaScript V6 (https://www.npmjs.com/package/canonicalize). Related: https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme If you want to test the jws-jcs signature scheme, an on-line demo is currently available at: https://mobilepki.org/jws-jcs/home What do you think? Sincerely, Anders Rundgren *] The goal is rather creating a "hashable" JSON representation but since the described scheme does not change data, these terms are effectively interchangeable. From nobody Mon Aug 20 12:27:47 2018 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C3129619 for ; Mon, 20 Aug 2018 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8yQkmLqKGGlv for ; Mon, 20 Aug 2018 12:27:43 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 92DFA128CF3 for ; Mon, 20 Aug 2018 12:27:43 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id d9-v6so955312itf.2 for ; Mon, 20 Aug 2018 12:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=01w1168HPSSyACTov6YNAneiiDZzq1MOohVYau3d2x4=; b=U4s5PhiY+Eewi3qh92fL14XCjipnBh7P9KOD0uwlVFDNIUAjELJXGunUP1Mhy6MHVi VfNOmpySuUUlKXbow+FIFGVcA8OtvWXsV8o4B25u0ALQUH4m00QBVlwjpqrH8Et4JAQF fTcES0tO5AiKgb8cTktP8X8NmIXnzlxjXXhPIXhNy4SC4hI+p/5nu1FrG0qKgJDpn3GA 0ZJzcVlCPqu6PSu8ywyUnhdJ15CwRrmfTFMH53RmF5DOHeMJHMGXmJYqxto7lqmaWrNk 3lnQ0DcjvhdsIt4rs4Fj4rLLAt7hLqFTbw10HjxQZgB1zauZNLdHjhG3Z31b6IDwCYYO VjDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=01w1168HPSSyACTov6YNAneiiDZzq1MOohVYau3d2x4=; b=H90Mqew/QjbP8/KSUHU1lr/vVsyTulxb8s9pbcdz75L9LbfY4rvO7DoAaev3iLjPu1 nw63OgGbOss7nSoSOrkkW1sD81oVWhjL+rpfqr1AvP1oeIgmIGZnagJ42dO+OJELSFzf 9GsXUT895qq71mYsVUXnmagswDxLv3Ny9P4C+uYjw94YKRWMYA5h3W0Ws2IpStR/jeMT xpeqYB4phJqF7R1a9GvmMU9zLLL5H4/nEMnrJizzuXvC0AvmpSJxf0QSjQj8GVDlDQbk Hf31O+wj4NC/XV1OOG6/1qCA0+qxrn9W/CN0KGJgd4EFQZvXyqr/Yqry75/H/AiZt1rE D2AA== X-Gm-Message-State: AOUpUlEfzOmPfgPO8ifypMnkhD7zMvm581wap8NJgb9YIJxjbVhj9RS9 MLw6NVuGd+MTbLXiGKnRhJ1D/BKQrTZoMy+jKewCQ38mfI8= X-Google-Smtp-Source: AA+uWPx4euEhNoBZx5wzrmV/iX+hbMmb0M5XQ/v2F0QbMGpvWckd7UDK2VhcOr2yJh2ojLjeYlHJDgWEZZwDN1emzx8= X-Received: by 2002:a24:6c04:: with SMTP id w4-v6mr14329705itb.4.1534793261891; Mon, 20 Aug 2018 12:27:41 -0700 (PDT) MIME-Version: 1.0 From: Ben Schwartz Date: Mon, 20 Aug 2018 15:27:30 -0400 Message-ID: To: Dispatch WG Cc: Katharine Daly , Lucas Pardue Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003a00840573e2e79f" Archived-At: Subject: [dispatch] HTTP, QUIC, proxies, and HELIUM X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 19:27:46 -0000 --0000000000003a00840573e2e79f Content-Type: multipart/alternative; boundary="0000000000002eb3ad0573e2e7da" --0000000000002eb3ad0573e2e7da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At the DISPATCH session in Montreal, the chairs suggested reaching out to this list with a taxonomy of the problems that HELIUM is trying to solve. Here=E2=80=99s a quick attempt at that. (For more information, see Lucas Pa= rdue=E2=80=99s =E2=80=9CHiNT=E2=80=9D draft and slides.) The starting point is the observation that HTTP/QUIC can forward HTTPS (with HTTP CONNECT), but cannot forward HTTP/QUIC (because CONNECT is TCP-only). The baseline requirement, then, is to enable an HTTP/QUIC server to forward a QUIC connection. Although this is the starting use case, it is not the only property that one might desire. Some additional goals that we=E2=80=99ve considered incl= ude - extending the supported contents to include WebRTC, DNS, or even arbitrary IP - extending the supported substrates to include HTTP/2 or even HTTP/1.1 - extending the performance goals (beyond merely =E2=80=9Cfunctional=E2=80= =9D) to include minimizing setup latency, or even enhancing congestion control performan= ce on difficult paths (e.g. high loss, high latency, or variable latency) HELIUM attempts to cover all of these extended goals, at least to some extent, which results in an unconventional, extremely flexible design. Some participants asked for sketches of solutions with reduced scope that enable a more familiar approach. Here are a few: - If we require that the proxied contents are end-to-end congestion controlled (e.g. only QUIC is allowed), then the substrate could safely disable congestion control (and reliability and flow control) for those packets. This would require some modifications to HTTP/QUIC (creating a DTLS-like mode) but would make congestion control stability much easier = to achieve. - If we require that contents are plain UDP only (no IP options like DSCP or TTL) and exclude support for server-like behavior, then we can use a protocol that maps 1:1 with TURN, for familiar semantics. - If we require that the server has full =E2=80=9Craw IP sockets=E2=80=9D = access, then we can remove all mention of UDP and simply define a VPN-type IP tunnel. In my view, a protocol that solves one of these restricted problems would still be a worthwhile advance. Finally, I=E2=80=99ll note that the level of performance achievable with HE= LIUM=E2=80=99s current design is not entirely clear, due to the worrying presence of layered congestion control. A more ambitious approach to performance enhancement might allow the proxy to peek into the content=E2=80=99s conges= tion control information. This could enable optimizations like retransmission from the middle (in both directions) in the event of packet loss. My question to DISPATCH participants is: what would it take for a solution to be useful to you? --Ben --0000000000002eb3ad0573e2e7da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

At the DISPATCH session = in Montreal, the chairs suggested reaching out to this list with a taxonomy= of the problems that HELIUM is trying to solve.=C2=A0 Here=E2=80=99s a qui= ck attempt at that. (For more information, see Lucas Pardue=E2=80=99s =E2= =80=9CHiNT=E2=80=9D draft and slides.)


The starting point is the observation that HTTP/QUIC can forw= ard HTTPS (with HTTP CONNECT), but cannot forward HTTP/QUIC (because CONNEC= T is TCP-only).=C2=A0 The baseline requirement, then, is to enable an HTTP/= QUIC server to forward a QUIC connection.


Although this is the starting use case, it is not the only p= roperty that one might desire.=C2=A0 Some additional goals that we=E2=80=99= ve considered include

  • extending th= e supported contents to include WebRTC, DNS, or even arbitrary IP

  • extending = the supported substrates to include HTTP/2 or even HTTP/1.1

    • =

  • extending the pe= rformance goals (beyond merely =E2=80=9Cfunctional=E2=80=9D) to include min= imizing setup latency, or even enhancing congestion control performance on = difficult paths (e.g. high loss, high latency, or variable latency)<= /p>


HELIUM attempts to cover= all of these extended goals, at least to some extent, which results in an = unconventional, extremely flexible design.


Some participants asked for sketches of solutions with redu= ced scope that enable a more familiar approach.=C2=A0 Here are a few:

  • If we require that the proxied conten= ts are end-to-end congestion controlled (e.g. only QUIC is allowed), then t= he substrate could safely disable congestion control (and reliability and f= low control) for those packets.=C2=A0 This would require some modifications= to HTTP/QUIC (creating a DTLS-like mode) but would make congestion control= stability much easier to achieve.

  • If we require that contents are plain UDP= only (no IP options like DSCP or TTL) and exclude support for server-like = behavior, then we can use a protocol that maps 1:1 with TURN, for familiar = semantics.

  • If we require that the server has full =E2=80=9Craw IP sockets=E2= =80=9D access, then we can remove all mention of UDP and simply define a VP= N-type IP tunnel.


In my view, a protocol that solves one of these restricted problems would = still be a worthwhile advance.


Finally, I=E2=80=99ll note that the level of performance achievable wit= h HELIUM=E2=80=99s current design is not entirely clear, due to the worryin= g presence of layered congestion control.=C2=A0 A more ambitious approach t= o performance enhancement might allow the proxy to peek into the content=E2= =80=99s congestion control information. This could enable optimizations li= ke retransmission from the middle (in both directions) in the event of pack= et loss.


My question to DIS= PATCH participants is: what would it take for a solution to be useful to yo= u?


--Ben


--0000000000002eb3ad0573e2e7da-- --0000000000003a00840573e2e79f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCArNKymUFSuGsOEXxLSnj8g sDHkkIhfjJ9eVnbrLVJAgDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA4MjAxOTI3NDJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAMpjF93DVP4A+bDG8H9Dbs+IZ3fiS7U3O+bd9gREW WycSu3D8k4tznJjpMbNgGRuGlNC+SO3uT41KrW6iGL4i/h9HWzLcrm+xxoDmzHku4OXoZQ5TUcRM 2rhNf3dbf1yFl7SEUmW+R/kse9QX7Mw29blRqoVl1j/wA7wRAd0ZNKY+sbIxtLss/46MyiWEQPN4 61xJIu1dem2k7AUMCNlw0ZftABonqNMCxVc/FrtEIB/57UjTZMYgu6n8pvPlErJQmnkqwNDTzlDj 0jhO2hl+bk/2Kemjw8VRjq86lUKXKifyyhwK8m5zs6iC0HXjLiThN+Y9HqeUyrWM4F6RRSCjLg== --0000000000003a00840573e2e79f--