Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7F83A0E46 for ; Mon, 27 Apr 2020 09:00:46 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, 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=blackberry.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 b-VcAQpitERo for ; Mon, 27 Apr 2020 09:00:42 -0700 (PDT) Received: from smtp-pg11.blackberry.com (smtp-pg11.blackberry.com [68.171.242.227]) (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 E871D3A0DCC for ; Mon, 27 Apr 2020 09:00:37 -0700 (PDT) Received: from pps.filterd (mhs401ykf.rim.net [127.0.0.1]) by mhs401ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 03RG0TvZ171389; Mon, 27 Apr 2020 12:00:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=IBWQW4UFAJ4D4UCTxxYFBpJRHB4/d3x05qxwQcn7Ge8=; b=LLBTvLgQcRyImlnkSXC0I+eIUzLGy9ngVvhR7Qcl/3Vm5Q6yR4uGXnRjxPtENXl8URFz STby4b5aOUP4xaq7OLpz93ffrM8sbbgnAQkG2Yx8PHrkyvya2PqEzej8rnqax+GyFRYn dWf/KGi7rCNr5Hrhz5lPtrk1y/1qqW1dU1FDjH+iWDCJpuz/SSRIfP4L7wHme/y0ObUq cugrNovcCJmpxqpU3nqku9tm97sLEs+KW+j9N7t3s6s+bQiUFjP34Gt+zhNnsG7qT1t4 3xNA7X0r8Qcs3MBy/XNvvNxBQoTw+Rr4mcP7obye9v85OxICqEBy6363YajT7Nw75q4l 3g== Received: from xch214ykf.rim.net (xch214ykf.rim.net [10.2.27.114]) by mhs401ykf.rim.net with ESMTP id 30mgf5v4cp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 27 Apr 2020 12:00:29 -0400 Received: from XCH210YKF.rim.net (10.2.27.110) by XCH214YKF.rim.net (10.2.27.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Apr 2020 12:00:29 -0400 Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Mon, 27 Apr 2020 12:00:29 -0400 From: Dan Brown To: Neil Madden , Paul Grubbs CC: CFRG Thread-Topic: [Cfrg] Multi-recipient public key authenticated encryption Thread-Index: AQHWHJ3sAo0Oxh6TOE2cxrrC/lIO9KiNVcmAgAAMF4D//734oA== Date: Mon, 27 Apr 2020 16:00:28 +0000 Message-ID: References: <6532256B-18E2-47E3-91EF-D18FBF339742@gmail.com> In-Reply-To: <6532256B-18E2-47E3-91EF-D18FBF339742@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [100.64.97.99] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01ED_01D61C8B.70CE04B0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_12:2020-04-27, 2020-04-27 signatures=0 Archived-At: Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:00:53 -0000 ------=_NextPart_000_01ED_01D61C8B.70CE04B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01EE_01D61C8B.70CE04B0" ------=_NextPart_001_01EE_01D61C8B.70CE04B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Neil, I recall that =E2=80=9Cunified model=E2=80=9D is well-known to lack some se= curity property. Maybe, key-compromise impersonation (KCI)? If Eve has Bob=E2=80=99s private key, can Eve impersonate Alice? E.g. replace ECDH(alice_private, bob_public) by ECDH(bob_private, alice_pub= lic)? Dan =20 From: Cfrg On Behalf Of Neil Madden Sent: Monday, April 27, 2020 11:54 AM To: Paul Grubbs Cc: CFRG Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption =20 The details of the original proposed scheme are in the linked draft or are = in NIST SP 800-56A. To summarise, if Alice wants to encrypt a message and s= end it to both Bob and Charlie she carries out the following steps (with so= me minor details of syntax elided): =20 1. Generate a random CEK and use it to encrypt the message content using so= me symmetric AEAD scheme producing authenticated ciphertext, C. 2. kek_bob =3D KDF(ECDH(ephemeral_private, bob_public) || ECDH(alice_privat= e, bob_public) || context_bob) 3. kek_charlie =3D KDF(ECDH(ephemeral_private, charlie_public) || ECDH(alic= e_private, charlie_public) || context_charlie) 4. bob_box =3D AES-KW(kek_bob, CEK) 5. charlie_box =3D AES-KW(kek_charlie, CEK) 6. Send bob_box || charlie_box || ephemeral_public || C =20 Here the context arguments are typically the public keys involved and any a= dditional identifiers for the parties involved. The new proposal is to also= mix in SHA-512(C) into this KDF calculation as additional context. =20 The threat model here is that Alice sends a message to Bob and Charlie stat= ing that Bob is in charge while she is on holiday. Charlie uses the shared = CEK to create a new message saying =E2=80=9COops, I meant that Charlie is i= n charge.=E2=80=9D and sends that to Bob with the original encrypted keys (= i.e., Charlie just replaces C). This new message from Charlie validates as = if it came from Alice. I=E2=80=99d like to stop this kind of attack. =20 My assertion is that if you mix SHA-512(C) into the KDF calculation then Ch= arlie needs to find a 2nd preimage of SHA-512 to pull off this attack. (I= =E2=80=99m using SHA-512 as an example, actually JOSE already uses SHA-256 = in its KDF so I=E2=80=99ll probably use that). =20 =E2=80=94 Neil On 27 Apr 2020, at 16:10, Paul Grubbs > wrote: =20 This sounds like a really interesting question, but I'm having trouble unde= rstanding your proposed scheme - can you give a bit more detail?=20 =20 I also don't quite understand the threat model. Are you trying to prevent a= malicious receiver from "forging" a new payload that looks like it came fr= om the sender? =20 On Mon, Apr 27, 2020 at 10:12 AM Neil Madden > wrote: Hi all, =20 I am working on an enhancement to the JOSE standards and would like feedbac= k from members of CFRG about solutions to a particular issue if any of you = have time. =20 In JOSE currently if you wish to create a message that has both confidentia= lity and sender authentication using public key cryptography then the only = option is to both sign and then encrypt the message. This is expensive beca= use it involves multiple passes over the message and results in a very bulk= y nested message structure with two layers of base64-encoding. =20 Given that many uses of this sign-then-encrypt pattern do not require the s= trong security properties of signatures, I have proposed [1] a public key a= uthenticated encryption mode based on NIST=E2=80=99s one-pass unified model= from SP 800-56A. This avoids the nested structure and means that you don= =E2=80=99t need multiple cryptographic primitives. The proposed algorithm u= ses two ECDH key agreements: one between the sender=E2=80=99s ephemeral pri= vate key and the recipient=E2=80=99s long-term public key; and a second bet= ween the two parties=E2=80=99 long term keys. The two shared secrets are co= ncatenated and passed through a KDF along with some context arguments. For = a single recipient this achieves sender authentication (subject to replay),= and the single recipient case is what I am primarily concerned about. =20 (If you squint this is also roughly similar to the Noise framework =E2=80= =9CK=E2=80=9D one-way pattern, but my hands are waving quite a lot here). =20 To support multiple recipients I copied the existing pattern used in JOSE= =E2=80=99s ECDH-ES+A256KW algorithm family in which the message is encrypte= d using a random Content Encryption Key (CEK) and then the CEK is encrypted= for each recipient using AES-KeyWrap with the ECDH-derived key. As I then = mention in the security considerations this leads to any recipient being ab= le to produce a forgery using that CEK and claim it came from the original = sender: =20 When Key Agreement with Key Wrapping is used, with the same Content Encryption Key (CEK) reused for multiple recipients, any of those recipients can produce a new message that appears to come from the original sender. The new message will be indistinguishable from a genuine message from the original sender to any of the other participants. To avoid this attack, the content SHOULD be encrypted separately to each recipient with a unique CEK or a nested signature over the content SHOULD be used. =20 Because I am primarily interested in single-recipient use cases, this seeme= d like an acceptable trade-off. However, I have since been contacted by peo= ple who would like to use this draft for multi-recipient messages and would= not like to fall back on a nested signature structure. =20 An initial proposal was to solve this by simply including the MAC tag from = the content encryption in either the per-recipient payload (encrypted using= AES-KeyWrap) or as an additional context field to the KDF. But the MAC is = computed using the CEK that is known to all recipients, so for this to be s= ecure would require second preimage resistance of the MAC with a known key,= which cannot be guaranteed for JOSE because it supports content encryption= using AES-GCM for which second preimages can be trivially computed if you = know the key. =20 Assuming that a per-recipient MAC is too much overhead, an alternative woul= d be to include a collision-resistant hash of entire ciphertext (and IV and= associated data) in the KDF. This is unfortunate as it requires another pa= ss over the entire message when we=E2=80=99ve already encrypted and MACed, = but it appears to be a solution and at least is no more inefficient than th= e original signed-then-encrypted approach which also needs to hash the enti= re message. =20 So two questions: =20 1. Is including a hash (e.g., SHA-512) of the ciphertext (assuming symmetri= c AE) in the per-recipient KDF calculation sufficient to prevent forgeries = in the multi-recipient setting? =20 2. Are there more efficient alternatives that don=E2=80=99t assume 2nd prei= mage resistance of the underlying symmetric MAC? =20 [1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 =20 =20 Kind regards, =20 Neil Madden _______________________________________________ Cfrg mailing list Cfrg@irtf.org =20 https://www.irtf.org/mailman/listinfo/cfrg =20 =20 ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. ------=_NextPart_001_01EE_01D61C8B.70CE04B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Neil,

I recall that =E2=80=9Cunified model=E2=80=9D i= s well-known to lack some security property. Maybe, key-compromise imperson= ation (KCI)?

If Eve has Bob=E2=80=99s pr= ivate key, can Eve impersonate Alice?

E.= g. replace ECDH(alice_private, bob_public) by ECDH(bob_private, alice_publi= c)?

Dan

 

From: Cfrg <cfrg-bounces@irtf.org>= On Behalf Of Neil Madden
Sent: Monday, April 27, 2020 11:= 54 AM
To: Paul Grubbs <pag225@cornell.edu>
Cc: CF= RG <cfrg@irtf.org>
Subject: Re: [Cfrg] Multi-recipient publ= ic key authenticated encryption

 

The details of the origi= nal proposed scheme are in the linked draft or are in NIST SP 800-56A. To s= ummarise, if Alice wants to encrypt a message and send it to both Bob and C= harlie she carries out the following steps (with some minor details of synt= ax elided):

 =

1. Generate a random CEK and use it to = encrypt the message content using some symmetric AEAD scheme producing auth= enticated ciphertext, C.

2. k= ek_bob =3D KDF(ECDH(ephemeral_private, bob_public) || ECDH(alice_private, b= ob_public) || context_bob)

3.= kek_charlie =3D KDF(ECDH(ephemeral_private, charlie_public) || ECDH(alice_= private, charlie_public) || context_charlie)

4. bob_box =3D AES-KW(kek_bob, CEK)

5. charlie_box =3D AES-KW(kek_charlie, CEK)

6. Send bob_box || charlie_box || eph= emeral_public || C

 = ;

Here the context arguments are t= ypically the public keys involved and any additional identifiers for the pa= rties involved. The new proposal is to also mix in SHA-512(C) into this KDF= calculation as additional context.

 

The threat mode= l here is that Alice sends a message to Bob and Charlie stating that Bob is= in charge while she is on holiday. Charlie uses the shared CEK to create a= new message saying =E2=80=9COops, I meant that Charlie is in charge.=E2=80= =9D and sends that to Bob with the original encrypted keys (i.e., Charlie j= ust replaces C). This new message from Charlie validates as if it came from= Alice. I=E2=80=99d like to stop this kind of attack.

<= div>

 

My assertion is that if you mix SHA-512(C) into the KDF calculation then= Charlie needs to find a 2nd preimage of SHA-512 to pull off this attack. (= I=E2=80=99m using SHA-512 as an example, actually JOSE already uses SHA-256= in its KDF so I=E2=80=99ll probably use that).

 

=E2= =80=94 Neil



=

On 27 Apr 2020, at 16:10, Paul Grubbs <pag225@cornell.edu> wrote:

 

This sou= nds like a really interesting question, but I'm having trouble understandin= g your proposed scheme - can you give a bit more detail? 

 

I also don't quite understand the threat model. Are you trying to pre= vent a malicious receiver from "forging" a new payload that looks= like it came from the sender?

 

On Mon, Apr 27, 2020= at 10:12 AM Neil Madden <nei= l.e.madden@gmail.com> wrote:

Hi all,

 

I am working on an enhancement to the JOSE standards and would= like feedback from members of CFRG about solutions to a particular issue i= f any of you have time.

=  

In JOSE currently if you wi= sh to create a message that has both confidentiality and sender authenticat= ion using public key cryptography then the only option is to both sign and = then encrypt the message. This is expensive because it involves multiple pa= sses over the message and results in a very bulky nested message structure = with two layers of base64-encoding.

 

Given that many= uses of this sign-then-encrypt pattern do not require the strong security = properties of signatures, I have proposed [1] a public key authenticated en= cryption mode based on NIST=E2=80=99s one-pass unified model from SP 800-56= A. This avoids the nested structure and means that you don=E2=80=99t need m= ultiple cryptographic primitives. The proposed algorithm uses two ECDH key = agreements: one between the sender=E2=80=99s ephemeral private key and the = recipient=E2=80=99s long-term public key; and a second between the two part= ies=E2=80=99 long term keys. The two shared secrets are concatenated and pa= ssed through a KDF along with some context arguments. For a single recipien= t this achieves sender authentication (subject to replay), and the single r= ecipient case is what I am primarily concerned about.

<= div>

 

(If you squint this is also roughly similar to the Noise framework =E2= =80=9CK=E2=80=9D one-way pattern, but my hands are waving quite a lot here)= .

 

=

To support multiple recipients I copied the exist= ing pattern used in JOSE=E2=80=99s ECDH-ES+A256KW algorithm family in which= the message is encrypted using a random Content Encryption Key (CEK) and t= hen the CEK is encrypted for each recipient using AES-KeyWrap with the ECDH= -derived key. As I then mention in the security considerations this leads t= o any recipient being able to produce a forgery using that CEK and claim it= came from the original sender:

 

=C2=A0=
=C2=A0 When Key Agreement with Key Wrapping is used, with the same Content<=
o:p>
=C2=A0=C2=A0 Encryption Key (CEK) reused for multiple =
recipients, any of those
=C2=A0=C2=A0 recipients can p=
roduce a new message that appears to come from the
=C2=
=A0=C2=A0 original sender.=C2=A0 The new message will be indistinguishable =
from a
=C2=A0=C2=A0 genuine message from the original =
sender to any of the other
=C2=A0=C2=A0 participants.=
=C2=A0 To avoid this attack, the content SHOULD be encrypted
=C2=A0=C2=A0 separately to each recipient with a unique CEK or a nes=
ted signature
=C2=A0=C2=A0 over the content SHOULD be =
used.

 

=

Because I am primarily interested in single= -recipient use cases, this seemed like an acceptable trade-off. However, I = have since been contacted by people who would like to use this draft for mu= lti-recipient messages and would not like to fall back on a nested signatur= e structure.

 

An initial proposal was to solve this = by simply including the MAC tag from the content encryption in either the p= er-recipient payload (encrypted using AES-KeyWrap) or as an additional cont= ext field to the KDF. But the MAC is computed using the CEK that is known t= o all recipients, so for this to be secure would require second preimage re= sistance of the MAC with a known key, which cannot be guaranteed for JOSE b= ecause it supports content encryption using AES-GCM for which second preima= ges can be trivially computed if you know the key.

 

= Assuming that a per-recipient MAC is too much overhead, an alternative woul= d be to include a collision-resistant hash of entire ciphertext (and IV and= associated data) in the KDF. This is unfortunate as it requires another pa= ss over the entire message when we=E2=80=99ve already encrypted and MACed, = but it appears to be a solution and at least is no more inefficient than th= e original signed-then-encrypted approach which also needs to hash the enti= re message.

 =

So two questions:

<= div>

 

1. Is including a hash (e.g., SHA-512) of the ciphertext (assuming symme= tric AE) in the per-recipient KDF calculation sufficient to prevent forgeri= es in the multi-recipient setting?

 

2. Are there mor= e efficient alternatives that don=E2=80=99t assume 2nd preimage resistance = of the underlying symmetric MAC?

 

[1]: https= ://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03

 

Kind regards,

&nbs= p;

Neil Madden

_______________________________________________=
Cfrg mailing list
Cfrg@irtf.org
= https://www.irtf.org/mailman/listinfo/cfrg

<= /div>

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful.
------=_NextPart_001_01EE_01D61C8B.70CE04B0-- ------=_NextPart_000_01ED_01D61C8B.70CE04B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCFp4w ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwgghfMIIGR6ADAgECAhN8AAAtTl4y8yLDoDw8AAAAAC1OMA0GCSqGSIb3DQEBDQUAMFoxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xLjAsBgNVBAMTJUJsYWNrQmVy cnkgQ29ycG9yYXRlIFJTQSBJc3N1aW5nIENBIDMwHhcNMjAwNDAzMTg1MjE1WhcNMjEwNDAzMTg1 MjE1WjCBqTETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTENMAsGA1UE CxMEQU1FUjELMAkGA1UECxMCQ0ExFDASBgNVBAsTC01pc3Npc3NhdWdhMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMScwJQYJKoZIhvcNAQkBFhhkYW5pYnJvd25AYmxhY2tiZXJy eS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDS9EruyZQmNb+gtO9Ki7JH5kFJ ng5Y2bztcEqCB0THjGcu0fRrAym0W+OPW1PfmH1Q0tmYGhKDkxOHyxe9/cnLgLEsVFKtoTN7EpJO Z1EBE4G/Jn/UeRtv2iFp/e7tOpI9LBbkbVOfHAwCVkx4ZA3mzv1P1FsKSomINNFs2E/Gg5n+Ml8G rO067W94t7IUL/MLyU/R8ooldqpjw4JJGcgEHlqFCMee1cufQqgv1o62LzCYAruHyBx5Xkkv0XvB eYMiCVS+lKlWC4E/V8mRiQxcs/k/ntG/1Gr4Te5Uhc+gomFWQ4p34FnrLVNtYpn0kgVyUX8/bfWw x2Eul3SJVoeZAgMBAAGjggPMMIIDyDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiHv5dLhrmB JIbBgTKD2/IlgtzYAYEA+ox9gcuuUQIBZAIBEzATBgNVHSUEDDAKBggrBgEFBQcDBDALBgNVHQ8E BAMCBsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTFAMwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvQ1BTL0NQU3RhdGVtZW50Lmh0bTAbBgkrBgEEAYI3FQoE DjAMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBTvAdV+R+3Qcn5rED5jj5u3fWNsUjAfBgNVHSMEGDAW gBRs0YtrknGE8G2HSz6tNwEU9cWjKzCCAUAGA1UdHwSCATcwggEzMIIBL6CCASugggEnhoHbbGRh cDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUlNBJTIwSXNzdWluZyUyMENBJTIwMyxD Tj1NQ0FVMDAxQ05DLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vY3Js My5yaW0ubmV0L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBSU0ElMjBJc3N1aW5nJTIwQ0ElMjAz LmNybDCCARQGCCsGAQUFBwEBBIIBBjCCAQIwgdAGCCsGAQUFBzAChoHDbGRhcDovLy9DTj1CbGFj a0JlcnJ5JTIwQ29ycG9yYXRlJTIwUlNBJTIwSXNzdWluZyUyMENBJTIwMyxDTj1BSUEsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC11c2VyLmR5bi5yaW0ubmV0L29jc3Aw TQYDVR0RBEYwRKAoBgorBgEEAYI3FAIDoBoMGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbYEYZGFu aWJyb3duQGJsYWNrYmVycnkuY29tMA0GCSqGSIb3DQEBDQUAA4ICAQC3YoZ/NDdWJ7HwVsqFtXSd qqk5N36J2tCSbaWMImQOAQWM3FjZ74HlqK6A5+n1L97o3H0NucFh+J1koyecQLdvoYRqBUtcnPtH g2Yl4zVG+8sgi+FLFhLdRE1TFRjQgoUCR930Um97w9MKjkYEEs+4WQqNVno90BE3h0vDB+3BEJ6b xrFenxhIEWxWCyUs17PGlF+Z6M2Cjn+sUeZ9fhTet6htOGM9Qwdv3Jqn+11WPzZ0mx7Y66yvCTDU sGj5gFyel5VZf8HILSzS+xLeQLrbIcSP2GjkziMSEclWGCduRdNQ6lvwPyHhNZOlRZ1OQo5BmAzH QRTbDgbV+1KEF59q/K/4tF4p8mxSX4vfXF6nYrW+ZZiBde6p7gzirIQ3w9AEqKsV44gXa0nKXmPq CbUGFDqnZfnpoh8Qzmvq6AkeNzxChzvUqetdDz0VSXUl1Un6HH1nddqh4cfBYOsrHnDRH/7cdHt9 m2EztqwBgJHIa6LviPGrIUiVZZk6XPHl0EgQsnDWqYQrL/PeBRzV2YUNKh7MDH+ZSN9OzTwxMShH dwI0SXRxBRrR5gLMbcr749K4LOSqgkXWCgItReNEGE45kJJuLKShsEjszfLfLItKAJdV+U5v+EtO W/fe2CvLLZKTdYWsHpl0NFfUyEs11VR3ygRHFwlffNtiP9QSLy9yDTCCCGowggZSoAMCAQICBEMV YiMwDQYJKoZIhvcNAQENBQAwfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGlt aXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxhY2tC ZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwHhcNMTkwMjA1MjEyMzUxWhcNMjQwMjA1MjEy MzUxWjBaMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMS4wLAYDVQQD EyVCbGFja0JlcnJ5IENvcnBvcmF0ZSBSU0EgSXNzdWluZyBDQSAzMIICIjANBgkqhkiG9w0BAQEF AAOCAg8AMIICCgKCAgEA3ISRAnwqdZJeJfgSe6vpen977nOzY8JIsBRxrvm8Uai16mVl1Yy9spNS z9zTnCK4iwJsot0fOJMBiaMT4deYlKhTtPygAqso6llqyM0dKvd6Ez8K/ceV8fdR6zypzU9x8h7v fFkvaYJSPRkyyvdU8YGJ9iBLhBVGB3EI81y6IyqLhYhzZN9FbNAutU5y69QuvGS5n1RrtM03jgWu qqNceDW4JtsKl2bN9AC8YU5EUO2u3r4dRd2C1UWAgw9F22LFkages0iKJ772W/m7BDVjmetQWdT/ hi+wlfiBZjLJN1i8MM0uuIH0Fnv4tiiJTUtwpkdjH9iw3JIg/057tFOIypS3vVHQA5GJ75tS3LQj LYOym8KxOp/sLLKSLTnG1zxq8zyEvXd9vCpmjQd8P7cT3aKV0yZSoruoa75KmJZLqd9UR+12TKh1 z/h0uhedOivw8xpoYc+usf28k7BkWJ1lQc9uPhcibFC9duIu4+M14ftKFvRVyQsoLMfmyCi9Jmdo JC1BAq9TGkTCqGUyn/1mEeFLP9XtdlOhJX+ItTP6VLbgBOx1nTqQFvuVCYC7QUBOxbaDHTCJbKac Qz1YdhUgxDbqwJEODvIQ8zejYtGfBM9Hwil8AuYD/05MgcqPNi7CfasHiDHEk/iMAAHVrbsZG798 KBoL1Ih8nYi/da4mV7kCAwEAAaOCAxQwggMQMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRs0YtrknGE8G2HSz6tNwEU9cWjKzAfBgNVHSMEGDAWgBT4aYn4Y57v aF6BMGJwUqMO3bKWCDBgBggrBgEFBQcBAQRUMFIwUAYIKwYBBQUHMAKGRGh0dHA6Ly9jcnQucmlt Lm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3J0MIIB NwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0JlcnJ5 JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3JshoHVbGRhcDovLy9DTj1CbGFj a0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEsQ049Um9vdENBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIHfBgNVHSAEgdcwgdQwMwYKKwYBBAGbShMUATAl MCMGCCsGAQUFBwIBFhdodHRwczovL2NwLnJpbS5uZXQvY3BzLzAzBgorBgEEAZtKExQCMCUwIwYI KwYBBQUHAgEWF2h0dHBzOi8vY3AucmltLm5ldC9jcHMvMDMGCisGAQQBm0oTFAMwJTAjBggrBgEF BQcCARYXaHR0cHM6Ly9jcC5yaW0ubmV0L2Nwcy8wMwYKKwYBBAGbShMUBDAlMCMGCCsGAQUFBwIB FhdodHRwczovL2NwLnJpbS5uZXQvY3BzLzAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIE DB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQ0FAAOCAgEAG+Ro3/lYZMVkEiFocDjNPdMFpcohlYQN W023fMW3OuJoJ0ngkLCdcQoNGzZ3S60nzibXFkuFEF3HNAwqFcFTDapeGk9nPehF9o4MfLhJhn/L 3QZiCpgCGbTdPZazxjOwWjA1r/lwVT1wjrhZ4Hmj+GiUpVytrKeEs2zMzx2hQ1M0iXUSGz4KPzgZ 3ez9qq1xcqqskAhD+YNLovCH18KmXLfX8fkcELx8AxDCazjwgmrjWWs9LK/2Y6os16v9cOYIXIsj dhdq7HbdRtSX8GTghxEmInheWNzTd2z9lhRaE82aYkoCI8ivfQysjKDlcD+5LZiGoF7vT/8W53E4 w5OoykXNcuvHh2ByiWrqtnMNf//Awu9gg+fdDl4yV8MNbGrBDPjsxTpaKBtWmQHJVQ4lMwnA/MDZ 1mDbT5ZmnCb9hCxlVZkCeV5GzKGU7Tu47D8WfKfkGErNwMQuWbJ0a3pVBDrl34IF6B3V+pqnB8uY lLAQIXvXYtoVW+aHe5FnwmqomfgjTIiU/2fg9uBYwAaZSQN6YFDeKEcmGTP9r72Apa3cc/ui+mUR GBVFLJpGhADjSdOhzQVjmObsDU+DleTqIMkVkBF/izXYWLbSFfDjylR/MXdlau2acP9RZBitMyR3 kLAQNRmIYPzDeE6EKrUxpDBRDnAX53UY0cr64/qYIYkxggJJMIICRQIBATBxMFoxEzARBgoJkiaJ k/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xLjAsBgNVBAMTJUJsYWNrQmVycnkgQ29y cG9yYXRlIFJTQSBJc3N1aW5nIENBIDMCE3wAAC1OXjLzIsOgPDwAAAAALU4wDQYJYIZIAWUDBAIB BQCggaowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNDI3MTYw MDI3WjAvBgkqhkiG9w0BCQQxIgQgDWYA3v3EmZTgywJVJbtcZYxE18JkiewvenwbVtLSG4QwPwYJ KoZIhvcNAQkPMTIwMDALBglghkgBZQMEAgEwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjAHBgUr DgMCGjANBgkqhkiG9w0BAQEFAASCAQDHs+oFuaIvAsF+Y+f6fW2Gqrmh5qgBTnGItsbo6Vo5R9pv IZBM/iz9xT6/ozqqN+TPANZOSA4JyUKJNKpmhIoQO/kIsyCHeGAsc5LRjx1FyJpxJiZNn4GZO47r zDN8O66jI8OwwqUlXadGw8ESdO10pbtqSMpVBAzSpuiBaxv5AzCQMJSau5vkH0Rd0B6hO2I4hCqa rT+I2xa0Nl56qVmL7nha9eaKqOv5KL4HOOe1t8gy1QdU0I5z0GmmwS5/zWzFOOA3uOc85zTMoG0Q 9dH3ObA9wcT7xXATdexmNkRzGlS2crBXejIa9X/8Tq401TBtIonwxxQ6TAQcHHtLPDYZAAAAAAAA ------=_NextPart_000_01ED_01D61C8B.70CE04B0--