Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3746454785_844607559" --B_3746454785_844607559 Content-type: multipart/alternative; boundary="B_3746454785_3564546781" --B_3746454785_3564546781 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable My read: =20 Option 0: no-go in 99% of the cases; Option 1: should be acceptable in 95+% of the cases; Option 2: absolutely no-go; Option 4: an =E2=80=9Caccessorized=E2=80=9D version of (1), probably the be= st, as each protocol can decide what =E2=80=9Caccessories=E2=80=9D it wants= for the =E2=80=9Cenvelope=E2=80=9D. =20 TNX -- V/R, Uri =20 There are two ways to design a system. One is to make it so simple there ar= e obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. = - C. A. R. Hoare =20 =20 From: CFRG on behalf of Mike Ounsworth Date: Monday, September 19, 2022 at 17:18 To: Mike Ounsworth , pqc-forum Cc: "pqc@ietf.org" , CFRG Subject: Re: [CFRG] Design rationale for keyed message digests in SPHINCS+,= Dilithium, FALCON? =20 Thank you all for the wholesome discussion all! =20 Here is my attempt to summarize: we have a few fundamental options: =20 =20 Option 0: Do not pre-hash; send the whole message to the cryptographic prim= itive. =20 Discussion: There will be at least some applications where this is not prac= tical; for example imagine signing a 25 mb email with a smartcard. Streamin= g the entire 25 mb to the smartcard sounds like you=E2=80=99d be sitting th= ere waiting for a human-irritating amount of time. Validation of firmware i= mages during secure boot is another case that comes to mind where you want = to digest in-place and not stream the firmware image over an internal BUS. =20 =20 =20 Option 1: Simple pre-hash m=E2=80=99 =3D SHA256(m); sign(m) =20 Discussion: Don=E2=80=99t, for various reasons, none of which are catastrop= hic to the algorithm security, but there are better ways. =20 =20 =20 Option 2: Externalize the keyed digest step of SPHINCS+, Dilithium, FALCON = to the client. =20 Discussion: REALLY DON=E2=80=99T! This can be private-key-recovery-level ca= tastrophic for FALCON. For Dilithium and non-randomized SPHINCS+ this might= be cryptographically sound, but regardless, moving part of the algorithm o= utside the crypto module boundary is unlikely to ever pass a FIPS validatio= n. =20 =20 Option 3: Application-level envelopes =20 Discussion: if your application has a need to only send a small amount of d= ata to the crypto module, then your application needs to define a compressi= ng envelope format, and sign that. How fancy the envelope format needs to b= e is dictated by the security needs of the protocol =E2=80=93 ie collision = resistance, entropy, contains a nonce, algorithm code footprint, performanc= e, etc. Downside is that we=E2=80=99re not solving this problem centrally, = but delegating the problem of doing this securely to each protocol design t= eam. =20 This seems to be the winning option. =20 =20 =20 Have I understood and summarized correctly? =20 =20 --- Mike Ounsworth Software Security Architect, Entrust =20 From: 'Mike Ounsworth' via pqc-forum =20 Sent: September 18, 2022 2:42 PM To: pqc-forum Cc: pqc@ietf.org; cfrg@irtf.org Subject: [EXTERNAL] [pqc-forum] Design rationale for keyed message digests = in SPHINCS+, Dilithium, FALCON? =20 WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. Hi NIST PQC Forum! =20 This is bubble-over from an IETF thread I started last week. =20 Context: hash-then-sign schemes are good. For example, they allow you to pr= e-hash your potentially very large message and then send just the hash valu= e to your cryptographic module to sign or verify. We like this pattern, it= =E2=80=99s good for bandwidth and latency of cryptographic modules. We noti= ce that SPHINCS+, CRYSTALS-Dilithium, and FALCON all start with a keyed mes= sage digest =E2=80=93 in the case of randomized SPHINCS+ and FALCON, that m= essage digest is keyed with a random number; in the case of non-randomized = SPHINCS+ and Dilithium, that message digest is keyed with values derived fr= om the public key (for completeness: randomized SPHINCS+ seems to be the on= ly to do both). =20 A quick skim through the submission documents for the three schemes shows t= hat the message randomization is intended as a protection against different= ial and fault attacks since the traces would not be repeatable between subs= equent signatures even of the same message. Unless I missed something, I do= n=E2=80=99t see any other justification given for the use of keyed message = digests (randomized or deterministic). =20 But it seems to me that, especially the randomized version, keyed message d= igests also protect against yet-to-be-discovered collision attacks in the u= nderlying hash function because an attacker cannot pre-compute against an `= r` chosen at signing time (ie the signature scheme=E2=80=99s security may n= ot need to rely on the hash function being collision resistant). =20 Question: So what is the safe way to externally pre-hash messages for these schemes i= n order to achieve a hash-then-sign scheme? Is it ok to take m=E2=80=99 = =3D SHA256(m) and then sign m=E2=80=99 ? If we care about the built-in coll= ision-resistance, then the answer is probably =E2=80=9CNo=E2=80=9D. Is it s= afe to externalize the keyed message digest step of SPHINCS+, Dilithium, FA= LCON? In the non-randomized versions where the keyed message digest only re= lies on values in the public key, I would think the answer is =E2=80=9CYes= =E2=80=9D. For randomized versions, that would mean having access to a cryp= tographic RNG value outside the cryptographic module boundary, which, at le= ast for FIPS validation, is probably a =E2=80=9CNo=E2=80=9D. =20 =20 =20 I=E2=80=99m eager to hear more on the design rationale for starting with a = randomized or deterministic keyed message digest, and recommendations for t= he safe way to external pre-hashes with these schemes. =20 --- Mike Ounsworth Software Security Architect, Entrust =20 Any email and files/attachments transmitted with it are confidential and ar= e intended solely for the use of the individual or entity to whom they are = addressed. If this message has been sent to you in error, you must not copy= , distribute or disclose of the information it contains. Please notify Entr= ust immediately and delete the message from your system.=20 --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/CH0PR11MB57394C98AA026DB0649C3FBC9F4A9%40CH0PR11M= B5739.namprd11.prod.outlook.com. --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/7AD08768-88B0-4A50-AD78-048DBFF025FD%40ll.mit.edu= . --B_3746454785_3564546781 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

My read:=

 = ;

  • Option 0: no-go in 99% of the cases;
  • Option 1: should be acceptable i= n 95+% of the cases;
  • Option 2: absolutely no-go;
  • Option 4: an =E2=80=9Caccessorized=E2=80=9D version of (1)= , probably the best, as each protocol can decide what =E2=80=9Caccessories= =E2=80=9D it wants for the =E2=80=9Cenvelope=E2=80=9D.

 

TNX

--

= V/R,

= Uri

 

There are two ways to design a system. One is to make it so simple there= are obviously no deficiencies.

The other is to make it so complex there are no obvious deficien= cies.

  &nb= sp;            =              &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   -  C. A. R. Hoare

 

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: CFRG <cfrg-bounces@irtf.org> on behalf of Mike Ounswo= rth <Mike.Ounsworth=3D40entrust.com@dmarc.ietf.org>
Date: M= onday, September 19, 2022 at 17:18
To: Mike Ounsworth <Mike.Ou= nsworth@entrust.com>, pqc-forum <pqc-forum@list.nist.gov>
Cc= : "pqc@ietf.org" <pqc@ietf.org>, CFRG <cfrg@irtf.org= >
Subject: Re: [CFRG] Design rationale for keyed message diges= ts in SPHINCS+, Dilithium, FALCON?

 

Thank= you all for the wholesome discussion all!

&nb= sp;

Here is my attempt to summarize: we have a few funda= mental options:

 

 

Option 0: Do not pre-hash; send the whole messag= e to the cryptographic primitive.

 =

Discussion: There will be at least some applications where th= is is not practical; for example imagine signing a 25 mb email with a smart= card. Streaming the entire 25 mb to the smartcard sounds like you=E2=80=99d= be sitting there waiting for a human-irritating amount of time. Validation= of firmware images during secure boot is another case that comes to mind w= here you want to digest in-place and not stream the firmware image over an = internal BUS.

 

=  

 

Option 1: Simple p= re-hash m=E2=80=99 =3D SHA256(m); sign(m)

&nbs= p;

Discussion: Don=E2=80=99t, for various reasons, none = of which are catastrophic to the algorithm security, but there are better w= ays.

<= span style=3D'color:#7030A0'> 

 

 

Option 2: Externalize the ke= yed digest step of SPHINCS+, Dilithium, FALCON to the client.

 

Discussion: REALLY DON=E2=80=99T!= This can be private-key-recovery-level catastrophic for FALCON. For Dilith= ium and non-randomized SPHINCS+ this might be cryptographically sound, but = regardless, moving part of the algorithm outside the crypto module boundary= is unlikely to ever pass a FIPS validation.

=  

 

Option 3: Applicat= ion-level envelopes

 

= Discussion: if your application has a need to only send a small amount of d= ata to the crypto module, then your application needs to define a compressi= ng envelope format, and sign that. How fancy the envelope format needs to b= e is dictated by the security needs of the protocol =E2=80=93 ie collision = resistance, entropy, contains a nonce, algorithm code footprint, performanc= e, etc. Downside is that we=E2=80=99re not solving this problem centrally, = but delegating the problem of doing this securely to each protocol design t= eam.

<= span style=3D'color:#7030A0'> 

This seems to b= e the winning option.

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

 

Have I unde= rstood and summarized correctly?

 <= /span>

 

---
Mike Ounsworth
Software Security Architect, En= trust

<= span style=3D'color:#7030A0'> 

From: 'Mike Ounsworth' v= ia pqc-forum <pqc-forum@list.nist.gov>
Sent: September 18,= 2022 2:42 PM
To: pqc-forum <pqc-forum@list.nist.gov>
Cc: pqc@ietf.org; cfrg@irtf.org
Subject: [EXTERNAL] [pqc-for= um] Design rationale for keyed message digests in SPHINCS+, Dilithium, FALC= ON?

 

WAR= NING: This email originated outside of Entrust.
DO NOT CLICK links or at= tachments unless you trust the sender and know the content is safe.

Hi NIST PQC Forum!

 

This is bubble-over from an IETF threa= d I started last week.

 

Context: hash-then-sign schemes are good. For example, they allow you t= o pre-hash your potentially very large message and then send just the hash = value to your cryptographic module to sign or verify. We like this pattern,= it=E2=80=99s good for bandwidth and latency of cryptographic modules. We n= otice that SPHINCS+, CRYSTALS-Dilithium, and FALCON all start with a keyed = message digest =E2=80=93 in the case of randomized SPHINCS+ and FALCON, tha= t message digest is keyed with a random number; in the case of non-randomiz= ed SPHINCS+ and Dilithium, that message digest is keyed with values derived= from the public key (for completeness: randomized SPHINCS+ seems to be the= only to do both).

 

= A quick skim through the submission documents for the three schemes shows t= hat the message randomization is intended as a protection against different= ial and fault attacks since the traces would not be repeatable between subs= equent signatures even of the same message. Unless I missed something, I do= n=E2=80=99t see any other justification given for the use of keyed message = digests (randomized or deterministic).

 

But it seems to me that, especially the randomized ve= rsion, keyed message digests also protect against yet-to-be-discovered coll= ision attacks in the underlying hash function because an attacker cannot pr= e-compute against an `r` chosen at signing time (ie the signature scheme=E2= =80=99s security may not need to rely on the hash function being collision = resistant).

<= o:p> 

Questio= n:

So what is= the safe way to externally pre-hash messages for these schemes in order to= achieve a hash-then-sign scheme? Is it  ok to take m=E2=80=99 =3D SHA= 256(m) and then sign m=E2=80=99 ? If we care about the built-in collision-r= esistance, then the answer is probably =E2=80=9CNo=E2=80=9D. Is it safe to = externalize the keyed message digest step of SPHINCS+, Dilithium, FALCON? I= n the non-randomized versions where the keyed message digest only relies on= values in the public key, I would think the answer is =E2=80=9CYes=E2=80= =9D. For randomized versions, that would mean having access to a cryptograp= hic RNG value outside the cryptographic module boundary, which, at least fo= r FIPS validation, is probably a =E2=80=9CNo=E2=80=9D.

 

 

 

I=E2=80=99m eager to hear more on the design ration= ale for starting with a randomized or deterministic keyed message digest, a= nd recommendations for the safe way to external pre-hashes with these schem= es.

&nbs= p;

---
Mike Oun= sworth
Software Security Architect, Entrust

 

Any email and files/attachments transmitted = with it are confidential and are intended solely for the use of the individ= ual or entity to whom they are addressed. If this message has been sent to = you in error, you must not copy, distribute or disclose of the information = it contains. Please notify Entrust immediately and delete the messag= e from your system.

--
You received this message because you are subscribed to = the Google Groups "pqc-forum" group.
To unsubscribe from this = group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum= /CH0PR11MB57394C98AA026DB0649C3FBC9F4A9%40CH0PR11MB5739.namprd11.prod.outlo= ok.com.

--
You received this message because you are subscribed to the Google Groups &= quot;pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+un= subscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.c= om/a/list.nist.gov/d/msgid/pqc-forum/7AD08768-88B0-4A50-AD78-048DBFF025FD%4= 0ll.mit.edu.
--B_3746454785_3564546781-- --B_3746454785_844607559 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G 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 A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCB4fdMwhEoK+1d5cszOzmtdpIBTU3VNzXwqJ97S PJwQxTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjA5MTky MTUzMDVaMA0GCSqGSIb3DQEBAQUABIIBAFszS1YKONBRGSxSrT7SwFIuSASOs3AkceB5rE/G lY3N+ub/qTcz6kFXAxgo4gaH5HPrtJmrx6+lmqqOE/yaAldVOZdSC5H1DqocxHcCDxPxHeq+ KqogIQXeYn8FPq2vfZL8kvnx0CJHkOJG61W3uDEDJdotMm40Iz2gvVSHQ2NSB8NFGD/q0dzj jbIALKWL801J6f7Le/0Qx2SUxyMAMD+0yMxKXp2hLo/Iy6PEYsCAtoI4Q2X7P4Cs/t2d7fKf kaUBqdBR3W6A3jfPE/M5ER5ROwv79nw1v6ehnoJsa46aQYtmyke6TqpTu48xUTa3JGldmZMH but3rRYx4XhhWBU= --B_3746454785_844607559--