From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38769 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P6Sfv-0005tU-Km for qemu-devel@nongnu.org; Thu, 14 Oct 2010 14:37:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P6Sft-0007AP-W1 for qemu-devel@nongnu.org; Thu, 14 Oct 2010 14:37:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P6Sft-0007AE-JA for qemu-devel@nongnu.org; Thu, 14 Oct 2010 14:37:09 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o9EIb8Cx012604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 14 Oct 2010 14:37:08 -0400 Message-ID: <4CB74DD3.7090100@REDHAT.COM> Date: Thu, 14 Oct 2010 11:37:07 -0700 From: Robert Relyea MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070001030502060300080607" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Alon Levy This is a cryptographically signed message in MIME format. --------------ms070001030502060300080607 Content-Type: multipart/alternative; boundary="------------020104080505070807010907" This is a multi-part message in MIME format. --------------020104080505070807010907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > > And how does the smart card state get migrated during migration? How > > do you keep it synced with QEMU? > > > > I don't understand the use-case behind this. Is this so that a local > > physical smart card can be passed through to a guest from a Spice > > client and when migration happens, the QEMU instance connects back to= > > the Spice client? So the device is never actually migrated? > =20 A lot of this discussion has confused me until I realized we are talking 2 different models. My current understanding is that qemu assumes that all devices are local to the qemu instance (that is on the host). When you migrate you want to connect to the new hardware on the new host, not feed back to some general client. The only exception seems to be mouse and keyboard, where qemu depends on some external protocol (vncclient or xdesktop or the x protocol itself) to transport the mouse and keyboard events. Our model has been that the smart card is local to the user/client -- like the mouse and keyboard. When you migrate qemu you do not migrate the smart card itself, since it's still physically on your client machine (like the mouse and keyboard), and needs to be managed by the local drivers on that client machine (which knows how to talk to the specific smart card installed there). So the daemon stays right where it's at and connects to the new qemu instance as it comes up. This is where I think I was confused about your migration question. I think you are assuming that the smart card itself connects to new hardware on the new host, meaning the daemon itself needs to move. If that is the semantic you are trying to present, then you are quite right, it's ludicrous to have the external daemon as part of the emulation. It now appears to me that qemu punts on this case, except for the keyboard and mouse -- well maybe not punts, but simply doesn't support any device that isn't on the host machine. If you look at the way qemu handles the sound device, for instance. Normally you want the sound to come out the speakers of the controlling console, not a random server that's hosting the guest. However, straight qemu doesn't handle things that way. The sound (if it comes out at all) comes out the server that qemu is installed on. When you migrate qemu, the sound now comes out the new server. This probably isn't a problem since most of the time someone is using the speaker, he's got the case where host =3D=3D client. In that case it makes perfect sense to put the emulator inside qemu. In the case where we are running a hosted server service, it's highly unlikely anyone is going to be using sound (or an attached webcam, etc.). In fact migration for these devices are really a noop. Smart cards are really like these devices. In fact more than a few keyboards have built in smart card readers. The smart card model is I want the smart card at the same location as my keyboard and mouse. I use that set of smart cards to authenticate. The use case on machines running with a server is that some customers have a requirement that you need the smart card to log in and administer those machines. Those smart cards are ones the operator carries with him, not ones that would sit on some server farm. For their requirements, one needs a way to get back to the local client. As I said before, I don't think this requirement is unique. The only way to handle it is to run code on the client machine. The devices that run on that client are ones you don't migrate with qemu, but stay with the client itself and reconnect to the new instance. I agree that having a daemon for each devices will eventually become unweildy. It looks like spice is the answer for this scenario. If you have devices other than the mouse/keyboard/display that are located on the client =3D=3D host, th= en you should assume the need for spice and not use straight qemu? In that world it makes sense to have a single protocol (passthru). It's ok to integrate the smart card emul directly into qemu because it's really only used either in the case where client !=3D host, or in the cas= e where your server hardware has some smart card installed that is uses for authentication. (NOTE: in this case, migrate means that the server will loose authentication and have to authenticate with the new smart card on the new host... I don't know how useful this really is, but I think it's important to point out that migrate with smart cards means something different than most devices. It means you have become a new entity, not a continuation of the old... it's the equivalent of pulling a smart card on a server and inserting a new one). So if my understanding is correct, as long as you are willing to deal with the card plug/unplug scenario on migration, it makes sense for qemu to have passthru plus a local emulated smart card which goes directly to local hardward. If you need to have the 'console' experience, then you turn on spice and emulate the card in the spice client. bob --------------020104080505070807010907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable = 
Anthony Liguori wrote:


> And how doe=
s the smart card state get migrated during migration? How
> do you keep it synced with Q=
EMU?
>
> I don't understand the use-c=
ase behind this. Is this so that a local
> physical smart card can be p=
assed through to a guest from a Spice
> client and when migration ha=
ppens, the QEMU instance connects back to
> the Spice client? So the dev=
ice is never actually migrated?
  
A lot of this discussion has confused me until I realized =
we are talking
2 different models.

My current understanding is that qemu assumes that all devices are local
to the qemu instance (that is on the host). When you migrate you want to
connect to the new hardware on the new host, not feed back to some
general client. The only exception seems to be mouse and keyboard, where
qemu depends on some external protocol (vncclient or xdesktop or the x
protocol itself) to transport the mouse and keyboard events.

Our model has been that the smart card is local to the user/client --
like the mouse and keyboard. When you migrate qemu you do not migrate
the smart card itself, since it's still physically on your client
machine (like the mouse and keyboard), and needs to be managed by the
local drivers on that client machine (which knows how to talk to the
specific smart card installed there). So the daemon stays right where
it's at and connects to the new qemu instance as it comes up. This is
where I think I was confused about your migration question. I think you
are assuming that the smart card itself connects to new hardware on the
new host, meaning the daemon itself needs to move. If that is the
semantic you are trying to present, then you are quite right, it's
ludicrous to have the external daemon as part of the emulation.

It now appears to me that qemu punts on this case, except for the
keyboard and mouse -- well maybe not punts, but simply doesn't support
any device that isn't on the host machine. If you look at the way qemu
handles the sound device, for instance. Normally you want the sound to
come out the speakers of the controlling console, not a random server
that's hosting the guest. However, straight qemu doesn't handle things
that way. The sound (if it comes out at all) comes out the server that
qemu is installed on. When you migrate qemu, the sound now comes out the
new server.

This probably isn't a problem since most of the time someone is using
the speaker, he's got the case where host =3D=3D client. In that case it
makes perfect sense to put the emulator inside qemu. In the case where
we are running a hosted server service, it's highly unlikely anyone is
going to be using sound (or an attached webcam, etc.). In fact migration
for these devices are really a noop.

Smart cards are really like these devices. In fact more than a few
keyboards have built in smart card readers. The smart card model is I
want the smart card at the same location as my keyboard and mouse. I use
that set of smart cards to authenticate. The use case on machines
running with a server is that some customers have a requirement that you
need the smart card to log in and administer those machines. Those smart
cards are ones the operator carries with him, not ones that would sit on
some server farm. For their requirements, one needs a way to get back to
the local client.

As I said before, I don't think this requirement is unique. The only way
to handle it is to run code on the client machine. The devices that run
on that client are ones you don't migrate with qemu, but stay with the
client itself and reconnect to the new instance. I agree that having a
daemon for each devices will eventually become unweildy. It looks like
spice is the answer for this scenario. If you have devices other than
the mouse/keyboard/display that are located on the client =3D=3D host, th=
en
you should assume the need for spice and not use straight qemu?

In that world it makes sense to have a single protocol (passthru). It's
ok to integrate the smart card emul directly into qemu because it's
really only used either in the case where client !=3D host, or in the cas=
e
where your server hardware has some smart card installed that is uses
for authentication. (NOTE: in this case, migrate means that the server
will loose authentication and have to authenticate with the new smart
card on the new host... I don't know how useful this really is, but I
think it's important to point out that migrate with smart cards means
something different than most devices. It means you have become a new
entity, not a continuation of the old... it's the equivalent of pulling
a smart card on a server and inserting a new one).

So if my understanding is correct, as long as you are willing to deal
with the card plug/unplug scenario on migration, it makes sense for qemu
to have passthru plus a local emulated smart card which goes directly to
local hardward. If you need to have the 'console' experience, then you
turn on spice and emulate the card in the spice client.

bob
--------------020104080505070807010907-- --------------ms070001030502060300080607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITcDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGmDCCBYCgAwIBAgIDAaw8MA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTAwOTMwMTg0NjA4 WhcNMTExMDAyMTUyMjEwWjCBkDEgMB4GA1UEDRMXMjY3NDEzLUlnZG1pYU9TQ25FTm5GdGsx HjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRDb20gRnJl ZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVkaGF0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/vMdJyaf8cVx+DOHsFocCxBTlQ XlBFrvoMW3a/keL27AOWJCkLcSPRMzIBvmQe4DDISs1I+pe4CXn/ZKTTP8DBDkWr/vQEeXKW nT47SnY6a5Kb/IHaw3vJJDjPkXUSkTMeKrp+4rSorGEf6jUrreyrHC6phjIGqKWMLcSxfkQy i3IPtfhbXC3IHsa3om/2rGNkA3Ocal4OZDS5gxVgNrxATYxvncdheLN0fHerquWIRyY4z+2A BtzSJ0t4Ixj7bvyxFToywUGHpHgiK/0Mrz2J55auJ9Rh/EqXHqJxnqB71yijjzkUzdYvE+Ke ZxxUJwkWTaMNI2YwzWq3gUJQyoUCAwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUFYpMA40TM+1C BCDr1I3jdoQkNHQwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYw FIEScnJlbHllYUByZWRoYXQuY29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwEC AjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmls aXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5z dGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5j b20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQw IwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQAHFhOPN0nFgE+8h1PaW2cm0WGqkiOyrGerZx0WaGknFqrWzbwNiNbEEIAWS153n94P3T9S RsZrGTT7zf0yR2E2132twrbqYAMcIY8OgDuufm5aCHVZDNGUYqFdSFPqlSW6t5jkqsA3JYs5 5bGyBb9pcS8/gyyO6gOOkH2WbAaS85D0K7LxqwsHZa9B/X+OxJX+3SxK/J14mlLSOYO7veZ7 e5ynM5NEeVzA53E8WDLcZuEjFTf72/v7LmmDry1hbCF+LvEOKFAyco1BaK753wVkKrVRPLdR Nv3G6uepR6SPpb3M9QGRLNY6WQC0HxRQw32h6irknRRauASYZggT3mtzMIIGmDCCBYCgAwIB AgIDAaw8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0EwHhcNMTAwOTMwMTg0NjA4WhcNMTExMDAyMTUyMjEwWjCBkDEgMB4GA1UEDRMXMjY3NDEz LUlnZG1pYU9TQ25FTm5GdGsxHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcG A1UEAxMgU3RhcnRDb20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEW EnJyZWx5ZWFAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/v MdJyaf8cVx+DOHsFocCxBTlQXlBFrvoMW3a/keL27AOWJCkLcSPRMzIBvmQe4DDISs1I+pe4 CXn/ZKTTP8DBDkWr/vQEeXKWnT47SnY6a5Kb/IHaw3vJJDjPkXUSkTMeKrp+4rSorGEf6jUr reyrHC6phjIGqKWMLcSxfkQyi3IPtfhbXC3IHsa3om/2rGNkA3Ocal4OZDS5gxVgNrxATYxv ncdheLN0fHerquWIRyY4z+2ABtzSJ0t4Ixj7bvyxFToywUGHpHgiK/0Mrz2J55auJ9Rh/EqX HqJxnqB71yijjzkUzdYvE+KeZxxUJwkWTaMNI2YwzWq3gUJQyoUCAwEAAaOCAvswggL3MAkG A1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUFYpMA40TM+1CBCDr1I3jdoQkNHQwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ ljVO8tS4UYIwHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQuY29tMIIBQgYDVR0gBIIBOTCC ATUwggExBgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMq IG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxh YmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAr oCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDAroCmgJ4YlaHR0 cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5 BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50 L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xh c3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQAHFhOPN0nFgE+8h1PaW2cm0WGqkiOyrGerZx0WaGknFqrW zbwNiNbEEIAWS153n94P3T9SRsZrGTT7zf0yR2E2132twrbqYAMcIY8OgDuufm5aCHVZDNGU YqFdSFPqlSW6t5jkqsA3JYs55bGyBb9pcS8/gyyO6gOOkH2WbAaS85D0K7LxqwsHZa9B/X+O xJX+3SxK/J14mlLSOYO7veZ7e5ynM5NEeVzA53E8WDLcZuEjFTf72/v7LmmDry1hbCF+LvEO KFAyco1BaK753wVkKrVRPLdRNv3G6uepR6SPpb3M9QGRLNY6WQC0HxRQw32h6irknRRauASY ZggT3mtzMYID0DCCA8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIDAaw8MAkGBSsOAwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMTAxNDE4MzcwN1owIwYJKoZIhvcNAQkEMRYEFD6JpeD6hOlHkf3FqYDI 3/80TJ+BMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJ KwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwGs PDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQIDAaw8MA0GCSqGSIb3DQEBAQUABIIBAJv8WWd/Spf25eCDQNGYLh+uekry2jFh4DOU 3pYdGSLqcE2QuFuVtJNAUOiHM+jEa3GkVYSY0LE5p5zwL8uvTzKbTRBjXylRipG7rao/3nFI etlwzsFVy0oBtKY49SIanbZ1EEvBRp2WuLlr9JCkBjIZkKCJNKl/+qOjym0TBKZa5YOPlluk 6AwdyOqeLBdYn8H7Yz/bsHoEvvBaqGJr2aRQqLN+l/WTb0xRVC2AGU8pyDoO3CuGVSWogPW1 wFvxuiNbOXPHAalk7lPQ+kasoOfuSOXKLbpIpXdoSW/dNjoTy+zPJvgzQq/gLmK5IAXZLYhk qqTmn8yvYPY9F+HqQC0AAAAAAAA= --------------ms070001030502060300080607--