From keyprov-bounces@ietf.org Tue Oct 02 04:07:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccmP-0004yS-D8; Tue, 02 Oct 2007 04:06:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibwgv-0007Ut-TN for keyprov@ietf.org; Sun, 30 Sep 2007 07:10:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ibwgn-0000EJ-CI for keyprov@ietf.org; Sun, 30 Sep 2007 07:10:21 -0400 Received: (qmail invoked by alias); 30 Sep 2007 11:10:20 -0000 Received: from p508F85C2.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.133.194] by mail.gmx.net (mp011) with SMTP; 30 Sep 2007 13:10:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19daDdrqx9dAByoEbNxgmD10tybWlCF0PYXkrnEJ1 VLEzQgsMUegiNY Message-ID: <46FF8417.6090203@gmx.de> Date: Sun, 30 Sep 2007 13:10:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Hannes Tschofenig References: <46E93396.2090003@gmx.net> <46FF783D.7090904@gmx.net> In-Reply-To: <46FF783D.7090904@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Tue, 02 Oct 2007 04:06:56 -0400 Cc: Chris Newman , keyprov@ietf.org, apps-REVIEW@ietf.org Subject: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi, thanks for the overview. If that document indeed argues against new methods, for new URI schemes and for usage of WSDL it seems it needs to be either fixed or marked historic. Maybe it's something for HTTPbis to look at? Best regards, Julian _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Oct 02 04:25:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icd4F-0002Vs-Nn; Tue, 02 Oct 2007 04:25:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icd4E-0001s4-94 for keyprov@ietf.org; Tue, 02 Oct 2007 04:25:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Icd43-000428-J6 for keyprov@ietf.org; Tue, 02 Oct 2007 04:25:11 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:25:10 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp014) with SMTP; 02 Oct 2007 10:25:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+H3dFN/VeHhYfcP5A60akkJ3RhbD1ivM2GQfdBhN nyKPDCmER5qvlY Message-ID: <47020065.50104@gmx.net> Date: Tue, 02 Oct 2007 10:25:09 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julian Reschke References: <46E93396.2090003@gmx.net> <46FF783D.7090904@gmx.net> <46FF8417.6090203@gmx.de> In-Reply-To: <46FF8417.6090203@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Chris Newman , keyprov@ietf.org, apps-REVIEW@ietf.org Subject: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi Julian, I believe the first thing is to get some feedback from this group whether they think some of my observations are indeed correct. If the suggestions in RFC 3205 (BCP 56) are still correct then I suspect we need to modify a few protocols. (I also realize that BCP 56 is not providing strict rules but at least I got confused by the guidelines it provides.) Ciao Hannes Julian Reschke wrote: > Hi, > > thanks for the overview. > > If that document indeed argues against new methods, for new URI > schemes and for usage of WSDL it seems it needs to be either fixed or > marked historic. > > Maybe it's something for HTTPbis to look at? > > Best regards, Julian _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Oct 04 12:51:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTuz-000055-KR; Thu, 04 Oct 2007 12:51:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IctK2-0003o0-7R; Tue, 02 Oct 2007 21:46:46 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IctJp-00071U-20; Tue, 02 Oct 2007 21:46:33 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l931kWMm007816; Wed, 3 Oct 2007 01:46:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPB00001BJNCD00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM); Tue, 02 Oct 2007 19:46:32 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPB00ARUBLHFU00@mail-amer.sun.com>; Tue, 02 Oct 2007 19:46:31 -0600 (MDT) Date: Tue, 02 Oct 2007 18:46:31 -0700 From: Chris Newman In-reply-to: <46FF783D.7090904@gmx.net> To: Hannes Tschofenig , apps-REVIEW@ietf.org Message-id: <69CC0AC5EB46F7B9D4CE3495@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <46E93396.2090003@gmx.net> <46FF783D.7090904@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-Mailman-Approved-At: Thu, 04 Oct 2007 12:51:20 -0400 Cc: keyprov@ietf.org Subject: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hannes Tschofenig wrote on 9/30/07 12:19 +0200: > thank you Chris for the pointer to RFC 3205 (BCP 56). I now read it and it is > indeed a very interesting document. Too bad that I didn't came across it > earlier. > Reading through that document I got the impression that the suggestions that > can be found in there are not exercised by today's protocol designs. I largely support BCP 56 and as an IESG member I consider it my duty and within my authority to enforce that BCP using my best judgment. However, some of the advice it gives could be updated to make it better and it could use advice in additional areas -- I would support an effort to revise it, although the present HTTP WG proposal may not be the right place to do that work. I'm uncomfortable when my best technical judgment disagrees with common practice and am unlikely to use my IESG authority to permanently block forward progress on a document in that case. However, when I'm aware of a BCP rule and agree with it, I consider it my duty at a minimum to verify the community considered the rule and had explicit community rough consensus to violate it. > (c) New port number for DSKPP since the usage is so different from ordinary > HTTP webbrowsing > (This is quite controversal when it comes to firewall traversal and might > require more discussions. See > http://www1.ietf.org/mail-archive/web/apps-review/current/msg00090.html) > > None of the protocols I have been working on defines a new port. Can you give > a reference to a recently developed protocol that carries XML on top of HTTP > that uses a new port number? I'll give two examples of HTTP-based protocols with separate ports where that was clearly the right technical choice in my opinion: IPP: RFC 2910 SIP: RFC 3261 I'll also mention that the Mail Submission protocol runs on port 587 primarily, but can also run on port 25. That's a practical way to (1) remain backwards compatible with deployed usage or limitations. (2) provide a separate port when it's helpful to avoid middle-box restrictions on an overused/abused port like port 25. It's my technical opinion there should be a separate port registered for HTTP access to information used to validate security credentials (CRLs, OCSP, etc) with port 80 as a fallback for situations where the separate port can't be used and for legacy use. It's plausible to build an Internet service where port 80 was intercepted by default for the authentication screen, but this other port was (partially) open so a client can get security information necessary to verify the interception HTTP server's credentials. I think that would be a better architecture than running everything over port 80 and forcing the port 80 application-level middle-boxes to become ever more sophisticated and failure prone. I have voted DISCUSS for discussion on this topic with document authors, but I have not yet blocked forward progress on any documents on this basis. > (d) New URI scheme > (Currently we use the HTTP/HTTPS schemes but that does not seem to be inline > with the recommendations in BCP 56.) > > Neither HELD, SCVP, LoST nor DSKPP define a new URI scheme. In LoST we had a > URL registration in the document once, see Section 16.5 of > draft-ietf-ecrit-lost-03, but removed it later (co-author of that document is > Ted Hardie, the former Applications Area Director). For things that only run on port 80, I generally wouldn't expect a separate URL scheme. > (e) WSDL Usage: Lisa and Chris do not see WSDL as something being useful. In > fact, I haven't found a person who argued in favor of WSDL. Hence, I believe > we should avoid it. To be precise: I have not yet seen any evidence that WSDL is useful. However, I have not educated myself on the protocol sufficiently to have formed an opinion on whether or not it is useful. > (f) Error Codes: RFC 3205 points to the problems of defining error codes when > applications are layered on top of HTTP. The suggestion is to essentially > only use 200 (for complete success) and 500 (for complete failure) at the > HTTP layer and to use "application" specific error codes inside the layer > application itself. We are essentially doing this. The only other error > message that is being mentioned is 403 and since it is independent of the > DSKPP protocol interaction it should be fine as well. > > (g) HTTP client, proxy and server code: We added text regarding the expected > behavior of clients, proxies and server in Section 5 of > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt. I guess > we are doing fine there. > > I am OK with (a), (b), (e), (f) and (g). I am not sure about (c) and (d). > Help needed. > > Ciao > Hannes > > PS: Regarding Mime-Types: > > In KEYPROV with the DSKPP document we should use application/dskpp+xml > instead of application/vnd.ietf.keyprov.dskpp+xml > > The IANA registry for the MIME type should look similar to the one in Section > 17.2 of draft-ietf-ecrit-lost-06. > > We also need to add a registry for the schema and the namespace (see Section > 11.1 of draft-ietf-geopriv-http-location-delivery-02.txt for the URN > sub-namespace registration, and Section 11.2 of for the XML schema > registration). > > > > Chris Newman wrote: >> I expect HTTP bindings to address the concerns raised in BCP 56. >> Unless the primary client for your protocol is a web browser, I would >> strongly encourage registering a separate port. In the SMTP world, >> the primary source of interoperability problems is application-level >> gateways/firewalls. At this point it's inevitable we'll end up with >> intrusive firewalls on port 80 that will break anything beyond stock >> browser-based HTTP. I encourage new HTTP-based protocols to register >> a separate port so they have the opportunity to avoid such damage and >> interoperability problems. It also simplifies responsible firewall >> operation by enabling port-based service restrictions that are more >> scalable and less intrusive. >> >> I have yet to see any evidence that WSDL is useful in practice but >> that may be due to my lack of experience with web services. >> >> I find Relax NG and/or XML schema useful for XML-based >> protocols/formats whether or not they are built on top of HTTP. My >> understanding is that Relax NG is better for extensible entity-based >> XML formats, whereas XML Schema is better for XML formats with strong >> value typing. >> >> I haven't reviewed the DSKPP draft yet. >> >> - Chris >> >> Hannes Tschofenig wrote on 9/13/07 14:56 +0200: >> >>> Hi all, >>> >>> I would like to solicit feedback regarding the HTTP binding described in >>> DSKPP: >>> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt >>> >>> I went through a couple of documents that describe an HTTP binding and >>> noticed all of them are slightly different. If you, for example, take >>> a look >>> at another recent work, namely HELD, from the GEOPRIV working group >>> then you >>> will notice that the author incorporated a WSDL binding. The draft is >>> here: >>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delive >>> ry >>> >>> -01.txt >>> >>> Do people on this list have an opinion about the content they would >>> like to >>> see in these type of documents? >>> What is the opinion regarding the usage of WSDL? >>> >>> Ciao >>> Hannes >> >> >> >> _______________________________________________ >> APPS-REVIEW mailing list >> APPS-REVIEW@ietf.org >> https://www1.ietf.org/mailman/listinfo/apps-review > > > > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www1.ietf.org/mailman/listinfo/apps-review > _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Oct 04 15:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWAp-0007Tw-Ko; Thu, 04 Oct 2007 15:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWAj-00073m-J8; Thu, 04 Oct 2007 15:15:45 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWAZ-0004RD-5z; Thu, 04 Oct 2007 15:15:41 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l94JC1iJ023691; Thu, 4 Oct 2007 12:12:01 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 12:14:59 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Thu, 4 Oct 2007 12:11:40 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053526@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <69CC0AC5EB46F7B9D4CE3495@[10.1.110.5]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgGp13nekPs9RdISR6c88HIxUW1FgAAXm9A From: "Hallam-Baker, Phillip" To: "Chris Newman" , "Hannes Tschofenig" , X-OriginalArrivalTime: 04 Oct 2007 19:14:59.0335 (UTC) FILETIME=[DB525970:01C806BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a very troubling statement in my view. Web Services is a standards based architecture with broad industry-wide = support. Keith's RFC was written in 2002 before the Web Services = architecture was developed. There is clearly a conflict between the = views being advance here and established practice for the design and = implementation of Web Services based specifications. It is not helpful here if the IETF is going to insist on a separate = definition of Web Services specifications that is not in sync with where = the Web Services world is. Either the BCP56 view is right in which case we need the proponents of = this view to be talking to the wider Web Services world (OASIS, W3C) and = arriving at a consensus position or the BCP56 view is obsolete and needs = to be updated. In either case this is an issue that the IAB needs to address. BCP56 is = their work product, I believe. They need to be maintaining it. In particular the idea that WSDL is somehow dispensible as a component = in the Web Services architecture is not a widely held position within = the Web Services world.=20 The port number issue is somewhat more complex. The number of Web = Services is rapidly expanding and the idea of one port per Web Service = is simply not sustainable. We only have 65536 ports and we are going to = have far more Web Services in use.=20 We already have a technology that meets this need - the SRV record. = Unlike some recent DNS records there is absoluely no problem with = support for SRV record deployment. Practically all the DNS servers in = service, including Windows support SRV.=20 Rather than registering a port for the KEYPROV protocol we should = instead define an SRV prefix. Wildcarding issues are not relevant in = this particular case. The firewall issues are pretty complex, far more complex than BCP56 = allows. In particular the design of SOAP and WS-* is largely motivated = by precisely the observation that port filtering is no longer a very = effective firewall strategy. That's why the original SOAP architecture = envisioned XML firewalls, UDDI and the like to route SOAP messages. I don't think that either port filtering or SOAP firewalls is a viable = near term strategy. Implementing a SOAP firewall is just too big an = increase in complexity over traditional port filtering for it to be seen = as a successor. SRV filtering on the other hand offers essentially the = same degree of complexity. > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM]=20 > Sent: Tuesday, October 02, 2007 9:47 PM > To: Hannes Tschofenig; apps-REVIEW@ietf.org > Cc: keyprov@ietf.org > Subject: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP >=20 > Hannes Tschofenig wrote on 9/30/07 12:19 +0200: > > thank you Chris for the pointer to RFC 3205 (BCP 56). I now read it=20 > > and it is indeed a very interesting document. Too bad that I didn't=20 > > came across it earlier. > > Reading through that document I got the impression that the=20 > > suggestions that can be found in there are not exercised by=20 > today's protocol designs. >=20 > I largely support BCP 56 and as an IESG member I consider it=20 > my duty and within my authority to enforce that BCP using my=20 > best judgment. However, some of the advice it gives could be=20 > updated to make it better and it could use advice in=20 > additional areas -- I would support an effort to revise it,=20 > although the present HTTP WG proposal may not be the right=20 > place to do that work. I'm uncomfortable when my best=20 > technical judgment disagrees with common practice and am=20 > unlikely to use my IESG authority to permanently block=20 > forward progress on a document in that case. However, when=20 > I'm aware of a BCP rule and agree with it, I consider it my=20 > duty at a minimum to verify the community considered the rule=20 > and had explicit community rough consensus to violate it. >=20 > > (c) New port number for DSKPP since the usage is so different from=20 > > ordinary HTTP webbrowsing (This is quite controversal when=20 > it comes to=20 > > firewall traversal and might require more discussions. See > >=20 > http://www1.ietf.org/mail-archive/web/apps-review/current/msg00090.htm > > l) > > > > None of the protocols I have been working on defines a new=20 > port. Can=20 > > you give a reference to a recently developed protocol that=20 > carries XML=20 > > on top of HTTP that uses a new port number? >=20 > I'll give two examples of HTTP-based protocols with separate=20 > ports where that was clearly the right technical choice in my opinion: > IPP: RFC 2910 > SIP: RFC 3261 >=20 > I'll also mention that the Mail Submission protocol runs on=20 > port 587 primarily, but can also run on port 25. That's a=20 > practical way to (1) remain backwards compatible with=20 > deployed usage or limitations. (2) provide a separate port=20 > when it's helpful to avoid middle-box restrictions on an=20 > overused/abused port like port 25. >=20 > It's my technical opinion there should be a separate port=20 > registered for HTTP access to information used to validate=20 > security credentials (CRLs, OCSP, etc) with port 80 as a=20 > fallback for situations where the separate port can't be used=20 > and for legacy use. It's plausible to build an Internet=20 > service where port 80 was intercepted by default for the=20 > authentication screen, but this other port was (partially)=20 > open so a client can get security information necessary to=20 > verify the interception HTTP server's credentials. I think=20 > that would be a better architecture than running everything=20 > over port 80 and forcing the port 80 application-level=20 > middle-boxes to become ever more sophisticated and failure prone. >=20 > I have voted DISCUSS for discussion on this topic with=20 > document authors, but I have not yet blocked forward progress=20 > on any documents on this basis. >=20 > > (d) New URI scheme > > (Currently we use the HTTP/HTTPS schemes but that does not=20 > seem to be=20 > > inline with the recommendations in BCP 56.) > > > > Neither HELD, SCVP, LoST nor DSKPP define a new URI scheme.=20 > In LoST we=20 > > had a URL registration in the document once, see Section 16.5 of=20 > > draft-ietf-ecrit-lost-03, but removed it later (co-author of that=20 > > document is Ted Hardie, the former Applications Area Director). >=20 > For things that only run on port 80, I generally wouldn't=20 > expect a separate URL scheme. >=20 > > (e) WSDL Usage: Lisa and Chris do not see WSDL as something being=20 > > useful. In fact, I haven't found a person who argued in=20 > favor of WSDL.=20 > > Hence, I believe we should avoid it. >=20 > To be precise: I have not yet seen any evidence that WSDL is=20 > useful. However, I have not educated myself on the protocol=20 > sufficiently to have formed an opinion on whether or not it is useful. >=20 > > (f) Error Codes: RFC 3205 points to the problems of defining error=20 > > codes when applications are layered on top of HTTP. The=20 > suggestion is=20 > > to essentially only use 200 (for complete success) and 500 (for=20 > > complete failure) at the HTTP layer and to use=20 > "application" specific=20 > > error codes inside the layer application itself. We are essentially=20 > > doing this. The only other error message that is being mentioned is=20 > > 403 and since it is independent of the DSKPP protocol=20 > interaction it should be fine as well. > > > > (g) HTTP client, proxy and server code: We added text regarding the=20 > > expected behavior of clients, proxies and server in Section 5 of=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-0 0.txt. I=20 > > guess we are doing fine there. > > > > I am OK with (a), (b), (e), (f) and (g). I am not sure=20 > about (c) and (d). > > Help needed. > > > > Ciao > > Hannes > > > > PS: Regarding Mime-Types: > > > > In KEYPROV with the DSKPP document we should use=20 > application/dskpp+xml=20 > > instead of application/vnd.ietf.keyprov.dskpp+xml > > > > The IANA registry for the MIME type should look similar to=20 > the one in=20 > > Section > > 17.2 of draft-ietf-ecrit-lost-06. > > > > We also need to add a registry for the schema and the=20 > namespace (see=20 > > Section > > 11.1 of draft-ietf-geopriv-http-location-delivery-02.txt=20 > for the URN=20 > > sub-namespace registration, and Section 11.2 of for the XML schema=20 > > registration). > > > > > > > > Chris Newman wrote: > >> I expect HTTP bindings to address the concerns raised in BCP 56. > >> Unless the primary client for your protocol is a web=20 > browser, I would=20 > >> strongly encourage registering a separate port. In the=20 > SMTP world,=20 > >> the primary source of interoperability problems is=20 > application-level=20 > >> gateways/firewalls. At this point it's inevitable we'll=20 > end up with=20 > >> intrusive firewalls on port 80 that will break anything=20 > beyond stock=20 > >> browser-based HTTP. I encourage new HTTP-based protocols=20 > to register=20 > >> a separate port so they have the opportunity to avoid such=20 > damage and=20 > >> interoperability problems. It also simplifies responsible=20 > firewall=20 > >> operation by enabling port-based service restrictions that=20 > are more=20 > >> scalable and less intrusive. > >> > >> I have yet to see any evidence that WSDL is useful in practice but=20 > >> that may be due to my lack of experience with web services. > >> > >> I find Relax NG and/or XML schema useful for XML-based=20 > >> protocols/formats whether or not they are built on top of=20 > HTTP. My=20 > >> understanding is that Relax NG is better for extensible=20 > entity-based=20 > >> XML formats, whereas XML Schema is better for XML formats=20 > with strong=20 > >> value typing. > >> > >> I haven't reviewed the DSKPP draft yet. > >> > >> - Chris > >> > >> Hannes Tschofenig wrote on 9/13/07 14:56 +0200: > >> > >>> Hi all, > >>> > >>> I would like to solicit feedback regarding the HTTP binding=20 > >>> described in > >>> DSKPP: > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt > >>> > >>> I went through a couple of documents that describe an=20 > HTTP binding=20 > >>> and noticed all of them are slightly different. If you,=20 > for example,=20 > >>> take a look at another recent work, namely HELD, from the GEOPRIV=20 > >>> working group then you will notice that the author incorporated a=20 > >>> WSDL binding. The draft is > >>> here: > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location > >>> -delive > >>> ry > >>> > >>> -01.txt > >>> > >>> Do people on this list have an opinion about the content=20 > they would=20 > >>> like to see in these type of documents? > >>> What is the opinion regarding the usage of WSDL? > >>> > >>> Ciao > >>> Hannes > >> > >> > >> > >> _______________________________________________ > >> APPS-REVIEW mailing list > >> APPS-REVIEW@ietf.org > >> https://www1.ietf.org/mailman/listinfo/apps-review > > > > > > > > _______________________________________________ > > APPS-REVIEW mailing list > > APPS-REVIEW@ietf.org > > https://www1.ietf.org/mailman/listinfo/apps-review > > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Oct 09 10:44:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGIx-0002md-LZ; Tue, 09 Oct 2007 10:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGIv-0002SC-CN; Tue, 09 Oct 2007 10:43:25 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGIi-0001x5-9j; Tue, 09 Oct 2007 10:43:18 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l99EdcJm018899; Tue, 9 Oct 2007 07:39:38 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 07:42:20 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Tue, 9 Oct 2007 07:38:51 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155705370D@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <9779E47D06A3D56F44788D7F@446E7922C82D299DB29D899F> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgKNhJIKk3gUfBfSca4tXjYFQQvvwARMOZQ From: "Hallam-Baker, Phillip" To: , "Hannes Tschofenig" , X-OriginalArrivalTime: 09 Oct 2007 14:42:20.0576 (UTC) FILETIME=[98CE9200:01C80A82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org > From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM]=20 > > It is not helpful here if the IETF is going to insist on a separate=20 > > definition of Web Services specifications that is not in sync with=20 > > where the Web Services world is. >=20 > When protocols are built using OASIS or W3C protocols such as=20 > services layered on SOAP over HTTP, then we're entering an=20 > area where the IETF lacks expertise.=20 > One of the litmus tests for such work is that it has rough=20 > consensus both within the IETF and with the other standards=20 > organizations. Hence my proposal that the resolution here be that the IAB and apps area = talk to the W3C TAG and OASIS TAB. What the resolution is matters a = whole heap less than that we either agree on a common resolution or note = that there are differences. > However, I will observe that the IETF WebDAV family of=20 > protocols has gone in a quite different direction from the=20 > SOAP over HTTP web services protocols. So our use of port 80=20 > is already not in sync with the rest of the web services world. WebDav started a long time ago, well before anyone was talking about = SOAP or Web Services as a stack. In the meantime the IETF has made a number of unfortunate choices, not = least the attempt to prempt the W3C/OASIS work by racing BEEP to DRAFT = standard despite the fact that it has virtually no platform support. > > In either case this is an issue that the IAB needs to=20 > address. BCP56=20 > > is their work product, I believe. They need to be maintaining it. >=20 > I'm not sure the IAB has the correct composition of=20 > individuals to address these concerns, particularly in the=20 > area of web services and web protocols. It might be better=20 > if a revision to BCP 56 was driven by individuals with the=20 > appropriate expertise working with the IAB as necessary. If the IAB lacks the necessary individuals then ask NOMCON to fix this. = The requirement here is for a group of people who are capable of talking = to and evaluating input from people who are experts in Web Services, not = to be experts themselves.=20 > > In particular the idea that WSDL is somehow dispensible as=20 > a component=20 > > in the Web Services architecture is not a widely held=20 > position within=20 > > the Web Services world. >=20 > As an area director, I will not require WSDL until there is=20 > community consensus within the IETF that it should be=20 > required. We already have far too many bars to jump over to=20 > get standards approved and I'm not inclined to add new ones=20 > absent evidence of substantial value. The message was=20 > forwarded somewhat out of context -- I was asked if I would=20 > require a WSDL profile and I answered that question. If I=20 > were asked the question "should a W3C/OASIS standards based=20 > web service have a WSDL profile?", my answer would be "ask=20 > the W3C/OASIS communities". I was pushing back against the impression you created. The advice I would give to anyone writing a Web Service is that they = should use WSDL because it will help them write the specification and = help developers implement it.=20 WSDL is not like writing a MIB, thinking about it as a profile is = unhelpful. WSDL is a formal description of your protocol. It's a tool = that you should think about in the same way that you would think about = EBNF or such. You would not talk about an EBNF profile of RFC822 and its = not helpful to talk about a WSDL profile of a Web Service. > > We already have a technology that meets this need - the SRV record.=20 > > Unlike some recent DNS records there is absoluely no problem with=20 > > support for SRV record deployment. Practically all the DNS=20 > servers in=20 > > service, including Windows support SRV. > > > > Rather than registering a port for the KEYPROV protocol we should=20 > > instead define an SRV prefix. Wildcarding issues are not=20 > relevant in=20 > > this particular case. >=20 > I find this proposal very interesting. To me, the underlying=20 > value of separate ports is the benefit of architectural=20 > separation of components (security, software design,=20 > multi-vendor interoperability, etc). If the community=20 > chooses an alternative mechanism to provide that value, I=20 > suspect that would address the underlying motivation of the=20 > discussion in BCP 56 about separate ports. The problem with BCP 56 is that it is written to the assumption that the = Internet will look pretty much the same in twenty years time as it does = today. I think we have to at least have a contingency plan to deal with = an Internet with a million protocols in active use. The killer apps of the Internet today are almost exclusively = human-machine protocols. We have almost no layer 7 protocols that are = machine-machine.=20 Humans have a limited number of needs and will tolerate a limited number = of interaction modes. Over time the number of active killer = human-machine protocols is unlikely to grow beyond 5 or so. The need to = educate the human keeps complexity under control.=20 That constraint goes away when machine-machine protocols are concerned. = There are a dozen or more protocols in use just for card payment = services. There is some consolidation but nothing like the consolidation = we see in the human interaction space. It simply does not matter as much = if EBay does or does not use the same payment protocol as Zix = corporation. If a standards based service is introduced it will be in = addition to the proprietary offerings and displacement will be slow. I do see standardization pressures on Web Services themselves, as = distinct from the platform. But unlike the human-machine space where = standardization is motivated by the need for interoperation I see = standards in the Web Services application world being driven by the need = to reduce complexity in order to enable new development. The demand to = standardize card acquisiton protocols is going to come from some new = requirement (e.g. need to support EMV) that hits all the established = operators, not standards for the sake of it. When VeriSign took over = Cybercash we kept the old cybercash protocols alongside Payflow. So fast forward a few decades and I think that the number of Web = Services in use will have grown exponentially. That is a bad match for = an architecture that requires a fixed resource be consumed per protocol. The constraints I see here are 1) Need to support a very large number of Web Services (millions) 2) Need to provide a protocol description that can be easily read by a = firewall Port numbers meet the second need but not the first. SOAP firewalls meet = the first but not the second. SOAP is expressly designed to expose the = necessary information to a SOAP aware firewall but it is vastly more = complex than port filtering. SOAP aware firewalls will certainly have a place but I see them as = something you would use to perform a second pass after you have made a = basic go/nogo decision. Pushing this to the naming layer makes sense to me.=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Oct 09 12:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfI8X-0001Up-Nm; Tue, 09 Oct 2007 12:40:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfI8W-0001U4-89; Tue, 09 Oct 2007 12:40:48 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfI8M-0007Rd-LV; Tue, 09 Oct 2007 12:40:39 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l99Gbnam023444; Tue, 9 Oct 2007 09:37:49 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 09:40:31 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Tue, 9 Oct 2007 09:37:08 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053728@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <470BA265.4000709@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgKi55+PKWSazh0TrWMvBA+MAjBJAABRSoQ From: "Hallam-Baker, Phillip" To: "Julian Reschke" X-OriginalArrivalTime: 09 Oct 2007 16:40:31.0207 (UTC) FILETIME=[1B26FF70:01C80A93] X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: keyprov@ietf.org, Chris.Newman@Sun.COM, apps-REVIEW@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I don't see what you mean by 'originally intended'. Back in 1992 I was looking at the use of HTTP to control a physics = experiment. The idea that the Web was simply a publication tool had not = yet taken hold. At the time we had less than 100 Web users. So I think = it counts as original intent. >From a security point of view I am much more interested in improving the = security of the Internet, rather than an Internet architecture that is = likely to be ignored as impractical. If we tell people not to use port 80 they will simply ignore us and use = port 80 anyway. When Java first appeared on the Web I tried to persuade = Gosling that Java content should be tagged application/java and not try = to bypass content firewalls by tagging itself application/data. He = ignored me even though it would have cost nothing to make the change at = that point. If on the other hand we give people a mechanism that they can use and = which provides them with real benefits over raw port 80 we can persuade = them down that route. A platform designer is not going to prevent Web = Services being deployed on port 80 no matter what the IAB says. But a = platform designer could possibly be persuaded to implement a Web Service = connect call that employed the SRV mechanism by default, thus taking = advantage of the load sharing capabilities it offers. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Tuesday, October 09, 2007 11:47 AM > To: Hallam-Baker, Phillip > Cc: Chris.Newman@Sun.COM; Hannes Tschofenig;=20 > apps-REVIEW@ietf.org; keyprov@ietf.org > Subject: Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP=20 > Binding for DSKPP >=20 > Hallam-Baker, Phillip wrote: > > ... > >> However, I will observe that the IETF WebDAV family of=20 > protocols has=20 > >> gone in a quite different direction from the SOAP over HTTP web=20 > >> services protocols. So our use of port 80 is already not in sync=20 > >> with the rest of the web services world. > >=20 > > WebDav started a long time ago, well before anyone was=20 > talking about SOAP or Web Services as a stack. > > ... >=20 > I guess part of the problem is to distinguish between protocols that > *use* HTTP the way it was designed to be used (auch as WebDAV or > AtomPub) from protocols that just use HTTP as a transport=20 > layer (SOAP & friends). >=20 > Both WebDAV and AtomPub both use HTTP to edit/author HTTP resources.=20 > IMHO there's no point in running these operations on a=20 > different port from the one the resulting resources can be=20 > retrieved from. >=20 > Best regards, Julian >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Oct 09 12:42:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIAH-0002tQ-MD; Tue, 09 Oct 2007 12:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHIg-0001Bh-0J for keyprov@ietf.org; Tue, 09 Oct 2007 11:47:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfHIZ-0003Gu-7M for keyprov@ietf.org; Tue, 09 Oct 2007 11:47:13 -0400 Received: (qmail invoked by alias); 09 Oct 2007 15:46:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp026) with SMTP; 09 Oct 2007 17:46:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Fp8k20dRFux/elDj4DXV633STqSXLLgqV+4RM5t CcrvmKx+zPqydc Message-ID: <470BA265.4000709@gmx.de> Date: Tue, 09 Oct 2007 17:46:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Subject: Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <2788466ED3E31C418E9ACC5C3166155705370D@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C3166155705370D@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Tue, 09 Oct 2007 12:42:36 -0400 Cc: keyprov@ietf.org, Chris.Newman@Sun.COM, apps-REVIEW@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hallam-Baker, Phillip wrote: > ... >> However, I will observe that the IETF WebDAV family of >> protocols has gone in a quite different direction from the >> SOAP over HTTP web services protocols. So our use of port 80 >> is already not in sync with the rest of the web services world. > > WebDav started a long time ago, well before anyone was talking about SOAP or Web Services as a stack. > ... I guess part of the problem is to distinguish between protocols that *use* HTTP the way it was designed to be used (auch as WebDAV or AtomPub) from protocols that just use HTTP as a transport layer (SOAP & friends). Both WebDAV and AtomPub both use HTTP to edit/author HTTP resources. IMHO there's no point in running these operations on a different port from the one the resulting resources can be retrieved from. Best regards, Julian _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Oct 12 13:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNwB-0007H8-8W; Fri, 12 Oct 2007 13:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNwA-00078V-9k for keyprov@ietf.org; Fri, 12 Oct 2007 13:04:34 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgNvx-0005Qn-Lw for keyprov@ietf.org; Fri, 12 Oct 2007 13:04:28 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9CH0MnP017490; Fri, 12 Oct 2007 10:00:23 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 18:03:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs Date: Fri, 12 Oct 2007 10:03:39 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C95039C0@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4758240@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs Thread-Index: Acf+m8RqXOiDW1JSSF25lXP644vEHAOVaDyw From: "Pei, Mingliang" To: "Philip Hoyer" , X-OriginalArrivalTime: 12 Oct 2007 17:03:40.0306 (UTC) FILETIME=[D65BEF20:01C80CF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b21264b25b2584da3ddf2bd579ca48f Cc: magnus@RSA.COM, "Doherty, Andrea" X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0012265803==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0012265803== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80CF1.D63F4912" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80CF1.D63F4912 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Suggest Item 4) to cover: =20 1. [issue6] Refer to EncryptionAlgorithm from ClientHello for the SupportedEncryptionAlgorithms? 2. Use URI instead of enumeration for algorithm types. 3. Consistent name convention with regard to "Hash", "Digest", "Mac", "MAC", and "HMAC" in various element names. =20 Notice that Issue6 in issue tracker has been closed by refering it as an open work item to do during alignment. =20 - Ming ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Monday, September 24, 2007 4:12 AM To: keyprov@ietf.org Cc: Doherty, Andrea; Salah; magnus@RSA.COM; Pei, Mingliang; Shuh Subject: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs Alignment points =20 1) KeyType DSKPP The type of symmetric cryptographic methods for which the key will be used (e.g., OATH HOTP or RSA SecurID authentication, AES encryption, etc.) =20 PSKC The KeyType represents the key entity in the KeyContainer. =20 2) Key Container DSKPP Key Container =20 An object that encapsulates a symmetric key and its configuration data (DSKPP Key Container is effectively the PSKC KeyType) =20 PSKC The KeyContainerType represents the key container entity. A Container MAY contain more than one Device entity; each Device entity MAY contain more than one Key entity. =20 3) VersionType DSKPP: =20 PSKC =20 4) AlgorithmsType =20 5) KeyID DSKPP base64binary PSKC string =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C80CF1.D63F4912 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Suggest Item 4) to cover:
 
1. [issue6] Refer to = EncryptionAlgorithm from=20 ClientHello for the = SupportedEncryptionAlgorithms?
2. Use URI instead of enumeration for algorithm = types.
3. Consistent name convention with regard to = "Hash",=20 "Digest", "Mac", "MAC", and "HMAC" in various element = names.
 
Notice that Issue6 in issue tracker has been = closed by=20 refering it as an open work item to do during = alignment.
 
- Ming

From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Monday, = September 24,=20 2007 4:12 AM
To: keyprov@ietf.org
Cc: Doherty, = Andrea;=20 Salah; magnus@RSA.COM; Pei, Mingliang; Shuh
Subject: [KEYPROV] = [DSKPP]=20 [PSKC] DSKPP and PSKC alignement points to be discussed to align the two = specs

Alignment=20 points

 

1)=20 KeyType

DSKPP

The type of symmetric = cryptographic=20 methods for which the key will be used (e.g., OATH HOTP or RSA SecurID=20 authentication, AES encryption, etc.)

 

PSKC

The KeyType represents the = key=20 entity in the KeyContainer.

 

2) Key=20 Container

DSKPP

Key=20 Container      =20  

An object that = encapsulates a=20 symmetric key and its configuration data

(DSKPP Key Container is = effectively=20 the PSKC KeyType)

 

PSKC

The KeyContainerType = represents the=20 key container entity.  A Container MAY contain more than one Device = entity;=20 each Device entity MAY contain more than one Key=20 entity.

 

3)=20 VersionType

DSKPP:

<xs:simpleType=20 name=3D"VersionType">

    =20 <xs:restriction base=3D"xs:string">

      =20 <xs:pattern = value=3D"\d{1,2}\.\d{1,3}"/>

    =20 </xs:restriction>

  =20 </xs:simpleType>

 

PSKC

<simpleType = name=3D"VersionType"=20 final=3D"restriction">

           =              = <restriction base=3D"string">

           =             &= nbsp;           =20 <pattern value=3D"\d{1,9}\.\d{0,9}"/>

           =              = </restriction>

</simpleType>

 

4)=20 AlgorithmsType

 

5)=20 KeyID

DSKPP=20 base64binary

PSKC=20 string

 

 

________________________________

 

Philip Hoyer=20

 

Senior Architect - = Office of=20 CTO

 

ActivIdentity=20 (UK)=

109 Borough High=20 Street

London SE1=20 1NL

 

Telephone: +44 (0) = 20 7744=20 6248

Direct: +44 (0) 20 = 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C80CF1.D63F4912-- --===============0012265803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0012265803==-- From keyprov-bounces@ietf.org Tue Oct 16 12:22:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpBQ-0002uO-4R; Tue, 16 Oct 2007 12:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpBO-0002q5-FQ for keyprov@ietf.org; Tue, 16 Oct 2007 12:22:14 -0400 Received: from frhub1.activcard.fr ([91.151.120.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhpBB-0002B4-J7 for keyprov@ietf.org; Tue, 16 Oct 2007 12:22:08 -0400 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 3E06025ED3D; Tue, 16 Oct 2007 18:21:39 +0200 (CEST) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 33ML6JFY; Tue, 16 Oct 2007 18:27:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Oct 2007 18:22:54 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Keyprov PSKC meeting minutes 15/10.07 Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDg== From: "Philip Hoyer" To: , "Hallam-Baker, Phillip" , "Pei, Mingliang" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: baa5f0d7df7d67a6bff4df65bb02daf5 Cc: keyprov@ietf.org Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1922929917==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1922929917== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81010.DDF26FE4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81010.DDF26FE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C81010.DDF26FE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attendees:

Philip Hoyer, Ming Pei, Shuh Chang, Salah = Macchani, Phillip Hallam-Baker, Hannes Tschofenig

 

 

 

1)       = Initially decided to tackle the issue of algorithms that are represented as = enumerations in PSKC and if we should go to a URI based approach that allows for = easier extension. There are 3 type of algorithm definitions in = PSKC

a.       = EncryptionAlgorithm of the key material in the container

b.       = DigestAlgorithm to create a digest of the uncencrypted keys

c.       = OTP Algorithm, identifier of the algorithm that the key is being used = with

2)       = Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to = URI

3)       = Ming Pei to change schema and add minimum list of URIs

a.       = Issue, what about PBE related algorithms, no URIs found by = Ming

b.       = Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for = which he has not found URIs. Philip Hallam Baker will then try to find URIs or = get back to authors with way to proceed

4)       = Discussion about digest of the key for RSA encrypted keys – Ming, Shuh to = check if it is a bad idea – Philip to ask to the = list

a.       = The problem here is that the Digest used for symmetric algorithms is a keyed = digest eg HMAC-SHA1 which is still not broken. If for transmission of keys = wrapped by a public Key of the receiving party we use a simple digest iof the = unencrypted key material, it might open the container for brute force attacks. Since = a keyvalue to hash value mapping might be much quicker to find than brute = forcing HMAC-SHA1

5)       = URIs for KeyAlgorithm?

a.       = Fundamentally the people agreed that it is a better idea but even more than encryption = and digest algorithms, OTP algotihms do not have a defined = URI

b.       = Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for = which he has not found URIs Philip Hallam Baker will then try to find URIs or get = back to authors with way to proceed

6)       = Philip Hoyer proposed to introduce a keyType at container level with attributes = such as algorithm and logo and usage type that the key can reference (this = would avoid repeating all the data for similar keys within the container) = – Everyone agreed that this was a good idea but  deemed a priority 2 = item

7)       = Hannes to investigate what best practice is regarding URN versioning, current = proposal is to add numeric version so all ietf:keyprov URN should add = ‘:1’

8)       = Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed = to complicate the schema too much so it was deferred for now =

9)       = Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the = list.

10)   = Discussion if we need to have a face to face meeting to align spec. Hannes asked if = a set of conference calls with a precise short agenda. Would be good. Should = we have a weekly conference call? Agreed to have a weekly call on Monday 3pm = Central 4pm EDT 9 pm for 30 minutes

11)   = IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved = it to the PBEParams element)

12)   = Discussed initial PIN transmission, Philip invited for participants to review and = agree. If no disagreements Philip Hoyer will include in October revision of the = spec

 

 

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C81010.DDF26FE4-- --===============1922929917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1922929917==-- From keyprov-bounces@ietf.org Wed Oct 17 03:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii3BE-0005ts-55; Wed, 17 Oct 2007 03:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii3BC-0005nH-1r for keyprov@ietf.org; Wed, 17 Oct 2007 03:18:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ii3Az-0000xg-NH for keyprov@ietf.org; Wed, 17 Oct 2007 03:18:52 -0400 Received: (qmail invoked by alias); 17 Oct 2007 07:18:24 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp053) with SMTP; 17 Oct 2007 09:18:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xAkpZH7gxVgxrec+aCHl5M0OyZCwN06g5Hr8YDi HYzJ4tswLSZRmo Message-ID: <4715B741.2080604@gmx.net> Date: Wed, 17 Oct 2007 10:18:25 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Hoyer References: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: keyprov@ietf.org Subject: [KEYPROV] Re: IETF Keyprov PSKC meeting minutes 15/10.07 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org For the group: I collect the phone numbers of the draft authors. I really give them a call from time-to-time to remind them about the work we have todo and also to investigate what the open issues are. In this case I thought it might be valuable for the group to learn more about the topics we discussed. Hence, I asked Philip to distribute his notes. Ciao Hannes Philip Hoyer wrote: > Attendees: > > Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip > Hallam-Baker, Hannes Tschofenig > > > > > > > > 1) Initially decided to tackle the issue of algorithms that are > represented as enumerations in PSKC and if we should go to a URI based > approach that allows for easier extension. There are 3 type of algorithm > definitions in PSKC > > a. EncryptionAlgorithm of the key material in the container > > b. DigestAlgorithm to create a digest of the uncencrypted keys > > c. OTP Algorithm, identifier of the algorithm that the key is > being used with > > 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to > change to URI > > 3) Ming Pei to change schema and add minimum list of URIs > > a. Issue, what about PBE related algorithms, no URIs found by Ming > > b. Ming Pei to send Phillip Hallam Baker and to mailing list the > list of algorithms for which he has not found URIs. Philip Hallam Baker > will then try to find URIs or get back to authors with way to proceed > > 4) Discussion about digest of the key for RSA encrypted keys - > Ming, Shuh to check if it is a bad idea - Philip to ask to the list > > a. The problem here is that the Digest used for symmetric > algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If > for transmission of keys wrapped by a public Key of the receiving party > we use a simple digest iof the unencrypted key material, it might open > the container for brute force attacks. Since a keyvalue to hash value > mapping might be much quicker to find than brute forcing HMAC-SHA1 > > 5) URIs for KeyAlgorithm? > > a. Fundamentally the people agreed that it is a better idea but > even more than encryption and digest algorithms, OTP algotihms do not > have a defined URI > > b. Ming Pei to send Phillip Hallam Baker and to mailing list the > list of algorithms for which he has not found URIs Philip Hallam Baker > will then try to find URIs or get back to authors with way to proceed > > 6) Philip Hoyer proposed to introduce a keyType at container level > with attributes such as algorithm and logo and usage type that the key > can reference (this would avoid repeating all the data for similar keys > within the container) - Everyone agreed that this was a good idea but > deemed a priority 2 item > > 7) Hannes to investigate what best practice is regarding URN > versioning, current proposal is to add numeric version so all > ietf:keyprov URN should add ':1' > > 8) Should we reorganise PBE to support PKCS5 XML schema, currently > this was deemed to complicate the schema too much so it was deferred for > now > > 9) Discussion around attributes and elements, should the ASN.1 > document contain the description of the attributes. Decision for > ASN.1document to incorporate attribute definition of PSKC spec. Hannes > to send email to the list. > > 10) Discussion if we need to have a face to face meeting to align > spec. Hannes asked if a set of conference calls with a precise short > agenda. Would be good. Should we have a weekly conference call? Agreed > to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes > > 11) IV should be moved back to EncryptionMethod since it is used for > symmetric algorithms and not only for PBE (Ming in his latest revision > had moved it to the PBEParams element) > > 12) Discussed initial PIN transmission, Philip invited for > participants to review and agree. If no disagreements Philip Hoyer will > include in October revision of the spec > > > > > > > > > > ________________________________ > > > > Philip Hoyer > > > > Senior Architect - Office of CTO > > > > ActivIdentity (UK) > > 109 Borough High Street > > London SE1 1NL > > > > Telephone: +44 (0) 20 7744 6248 > > Direct: +44 (0) 20 7744 6455 > > Fax: +44 (0) 20 7744 6249 > > > > Private and confidential: This message and any attachments may contain > > privileged / confidential information. If you are not an intended > recipient, > > you must not copy, distribute, discuss or take any action in reliance on > it. > > If you have received this communication in error, please notify the > sender > > and delete this message immediately. > > > > > _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Wed Oct 17 20:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJ2o-0004bK-VE; Wed, 17 Oct 2007 20:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJ2o-0004Qz-3Y for keyprov@ietf.org; Wed, 17 Oct 2007 20:15:22 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiJ2Z-0001t6-1k for keyprov@ietf.org; Wed, 17 Oct 2007 20:15:14 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I0EFnC024432; Wed, 17 Oct 2007 20:14:15 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I0EA2P019712; Wed, 17 Oct 2007 20:14:11 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l9I0E9uS001042; Wed, 17 Oct 2007 20:14:09 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Oct 2007 20:13:52 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B015@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBCSDog References: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> From: "Doherty, Andrea" To: "Philip Hoyer" , , "Hallam-Baker, Phillip" , "Pei, Mingliang" , , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='HTML_70_90 0.1, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 71427903e4ce43cf4879c36ef9c04bc1 Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1878714718==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1878714718== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8111B.CDA6B26A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8111B.CDA6B26A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Philip, =20 Thank you for forwarding these minutes to the mailing list. =20 It is good to see progress towards use of standard XML (esp. URIs for algorithms). Toward this end, and also for alignment with DSKPP, a couple of things are needed: 1. Switch to use of ordinary XMLEnc, XMLDSig 2. Switch to use PKCS #5 XML as it makes no sense to have this in DSKPP and not in PSKC. The schema is not complex. What is being referred to as "difficult" (see #8 below)? =20 Regarding use of URIs for OTP algorithms --- why is this necessary? I know we spoke of doing this before, but stepping back a bit, isn't it really up to vendors to specify their own URIs? If vendor-specific URIs are included in the doc that should be fine since the purpose of using URIs is to allow for extensibility. =20 Andrea =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 12:23 PM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C8111B.CDA6B26A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Philip,
 
Thank you for forwarding these minutes to the = mailing=20 list.
 
It is good to see progress towards use of = standard XML=20 (esp. URIs for algorithms).  Toward this end, and also for = alignment with=20 DSKPP, a couple of things are needed:
1. Switch to use of ordinary XMLEnc,=20 XMLDSig
2. Switch to use PKCS #5 XML as it makes no = sense to have=20 this in DSKPP and not in PSKC.  The schema is not complex.  = What is=20 being referred to as "difficult" (see #8 below)?
 
Regarding use of URIs for OTP algorithms --- = why is this=20 necessary?  I know we spoke of doing this before, but stepping back = a bit,=20 isn't it really up to vendors to specify their own URIs?  If=20 vendor-specific URIs are included in the doc that should be fine since = the=20 purpose of using URIs is to allow for extensibility.
 
Andrea
 
From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, = October 16,=20 2007 12:23 PM
To: Hannes.Tschofenig@gmx.net; Hallam-Baker, = Phillip;=20 Pei, Mingliang; shuh.chang@gemalto.com; = smachani@diversinet.com
Cc:=20 keyprov@ietf.org
Subject: [KEYPROV] IETF Keyprov PSKC meeting = minutes=20 15/10.07

Attendees:=20

Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, = Phillip=20 Hallam-Baker, Hannes Tschofenig

 

 

 

1)      =20 Initially = decided to=20 tackle the issue of algorithms that are represented as enumerations in = PSKC and=20 if we should go to a URI based approach that allows for easier = extension. There=20 are 3 type of algorithm definitions in PSKC

a.      =20 EncryptionAlgorithm of=20 the key material in the container

b.      =20 DigestAlgorithm to create=20 a digest of the uncencrypted keys

c.      =20 OTP = Algorithm, identifier=20 of the algorithm that the key is being used = with

2)      =20 Agreed to = change=20 EncryptionAlgorithm and DigestAlgorithm to change to=20 URI

3)      =20 Ming=20 Pei to change=20 schema and add minimum list of URIs

a.      =20 Issue, what = about PBE=20 related algorithms, no URIs found by Ming

b.      =20 Ming=20 Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he has=20 not found URIs. Philip Hallam Baker will then try to find URIs or get = back to=20 authors with way to proceed

4)      =20 Discussion = about digest=20 of the key for RSA encrypted keys – Ming, Shuh to check if it is a = bad idea –=20 Philip to ask to the list

a.      =20 The problem = here is that=20 the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 = which is=20 still not broken. If for transmission of keys wrapped by a public Key of = the=20 receiving party we use a simple digest iof the unencrypted key material, = it=20 might open the container for brute force attacks. Since a keyvalue to = hash value=20 mapping might be much quicker to find than brute forcing=20 HMAC-SHA1

5)      =20 URIs for = KeyAlgorithm?=20

a.      =20 Fundamentally = the people=20 agreed that it is a better idea but even more than encryption and digest = algorithms, OTP algotihms do not have a defined = URI

b.      =20 Ming=20 Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he has=20 not found URIs Philip Hallam Baker will then try to find URIs or get = back to=20 authors with way to proceed

6)      =20 Philip Hoyer = proposed to=20 introduce a keyType at container level with attributes such as algorithm = and=20 logo and usage type that the key can reference (this would avoid = repeating all=20 the data for similar keys within the container) – Everyone agreed = that this was=20 a good idea but  deemed a priority 2 = item

7)      =20 Hannes to = investigate=20 what best practice is regarding URN versioning, current proposal is to = add=20 numeric version so all ietf:keyprov URN should add=20 ‘:1’

8)      =20 Should we = reorganise PBE=20 to support PKCS5 XML schema, currently this was deemed to complicate the = schema=20 too much so it was deferred for now

9)      =20 Discussion = around=20 attributes and elements, should the ASN.1 document contain the = description of=20 the attributes. Decision for ASN.1document to incorporate attribute = definition=20 of PSKC spec. Hannes to send email to the = list.

10)  =20 Discussion if = we need to=20 have a face to face meeting to align spec. Hannes asked if a set of = conference=20 calls with a precise short agenda. Would be good. Should we have a = weekly=20 conference call? Agreed to have a weekly call on Monday 3pm Central 4pm = EDT 9 pm=20 for 30 minutes

11)  =20 IV should be = moved back=20 to EncryptionMethod since it is used for symmetric algorithms and not = only for=20 PBE (Ming in his latest revision had moved it to the PBEParams=20 element)

12)  =20 Discussed = initial PIN=20 transmission, Philip invited for participants to review and agree. If no = disagreements Philip Hoyer will include in October revision of the=20 spec

 

 

 

 

________________________________

 

Philip=20 Hoyer=20

 

Senior Architect - = Office of=20 CTO

 

ActivIdentity=20 (UK)=

109 Borough High=20 Street

London SE1=20 1NL

 

Telephone: +44 (0) = 20 7744=20 6248

Direct: +44 (0) 20 = 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C8111B.CDA6B26A-- --===============1878714718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1878714718==-- From keyprov-bounces@ietf.org Wed Oct 17 20:18:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJ5T-0006US-1y; Wed, 17 Oct 2007 20:18:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJ5R-0006UA-7P for keyprov@ietf.org; Wed, 17 Oct 2007 20:18:05 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiJ5Q-0001nL-7T for keyprov@ietf.org; Wed, 17 Oct 2007 20:18:05 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I0HqdC026628; Wed, 17 Oct 2007 20:17:52 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I0HnKO020865; Wed, 17 Oct 2007 20:17:50 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l9I0HnuS001170; Wed, 17 Oct 2007 20:17:49 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Oct 2007 20:17:32 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B016@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <3E5A2F1AD44F5E49A74F79AB47C0C0C95039C0@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs Thread-Index: Acf+m8RqXOiDW1JSSF25lXP644vEHAOVaDywAQqzoxA= References: <5BFE9E473DBFC24CA87F18F29B3F0AC4758240@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C95039C0@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Doherty, Andrea" To: "Pei, Mingliang" , "Philip Hoyer" , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='HTML_70_90 0.1, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Cc: magnus@rsa.com X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249209449==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1249209449== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8111C.5088CA00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8111C.5088CA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Philip, Is this what you referring to by "AlgorithmsType" in item #4 below? Andrea ________________________________ From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Friday, October 12, 2007 1:04 PM To: Philip Hoyer; keyprov@ietf.org Cc: Doherty, Andrea; Salah; magnus@RSA.COM; Shuh Subject: RE: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs Suggest Item 4) to cover: =20 1. [issue6] Refer to EncryptionAlgorithm from ClientHello for the SupportedEncryptionAlgorithms? 2. Use URI instead of enumeration for algorithm types. 3. Consistent name convention with regard to "Hash", "Digest", "Mac", "MAC", and "HMAC" in various element names. =20 Notice that Issue6 in issue tracker has been closed by refering it as an open work item to do during alignment. =20 - Ming ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Monday, September 24, 2007 4:12 AM To: keyprov@ietf.org Cc: Doherty, Andrea; Salah; magnus@RSA.COM; Pei, Mingliang; Shuh Subject: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC alignement points to be discussed to align the two specs Alignment points =20 1) KeyType DSKPP The type of symmetric cryptographic methods for which the key will be used (e.g., OATH HOTP or RSA SecurID authentication, AES encryption, etc.) =20 PSKC The KeyType represents the key entity in the KeyContainer. =20 2) Key Container DSKPP Key Container =20 An object that encapsulates a symmetric key and its configuration data (DSKPP Key Container is effectively the PSKC KeyType) =20 PSKC The KeyContainerType represents the key container entity. A Container MAY contain more than one Device entity; each Device entity MAY contain more than one Key entity. =20 3) VersionType DSKPP: =20 PSKC =20 4) AlgorithmsType =20 5) KeyID DSKPP base64binary PSKC string =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C8111C.5088CA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Philip,
Is this what you referring to by = "AlgorithmsType" in item=20 #4 below?
Andrea

From: Pei, Mingliang = [mailto:mpei@verisign.com]=20
Sent: Friday, October 12, 2007 1:04 PM
To: Philip = Hoyer;=20 keyprov@ietf.org
Cc: Doherty, Andrea; Salah; magnus@RSA.COM;=20 Shuh
Subject: RE: [KEYPROV] [DSKPP] [PSKC] DSKPP and PSKC = alignement=20 points to be discussed to align the two specs

Suggest Item 4) to cover:
 
1. [issue6] Refer to = EncryptionAlgorithm from=20 ClientHello for the = SupportedEncryptionAlgorithms?
2. Use URI instead of enumeration for algorithm = types.
3. Consistent name convention with regard to = "Hash",=20 "Digest", "Mac", "MAC", and "HMAC" in various element = names.
 
Notice that Issue6 in issue tracker has been = closed by=20 refering it as an open work item to do during = alignment.
 
- Ming

From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Monday, = September 24,=20 2007 4:12 AM
To: keyprov@ietf.org
Cc: Doherty, = Andrea;=20 Salah; magnus@RSA.COM; Pei, Mingliang; Shuh
Subject: [KEYPROV] = [DSKPP]=20 [PSKC] DSKPP and PSKC alignement points to be discussed to align the two = specs

Alignment=20 points

 

1)=20 KeyType

DSKPP

The type of symmetric = cryptographic=20 methods for which the key will be used (e.g., OATH HOTP or RSA SecurID=20 authentication, AES encryption, etc.)

 

PSKC

The KeyType represents the = key=20 entity in the KeyContainer.

 

2) Key=20 Container

DSKPP

Key=20 Container      =20  

An object that = encapsulates a=20 symmetric key and its configuration data

(DSKPP Key Container is = effectively=20 the PSKC KeyType)

 

PSKC

The KeyContainerType = represents the=20 key container entity.  A Container MAY contain more than one Device = entity;=20 each Device entity MAY contain more than one Key=20 entity.

 

3)=20 VersionType

DSKPP:

<xs:simpleType=20 name=3D"VersionType">

    =20 <xs:restriction base=3D"xs:string">

      =20 <xs:pattern = value=3D"\d{1,2}\.\d{1,3}"/>

    =20 </xs:restriction>

  =20 </xs:simpleType>

 

PSKC

<simpleType = name=3D"VersionType"=20 final=3D"restriction">

           =              = <restriction base=3D"string">

           =             &= nbsp;           =20 <pattern value=3D"\d{1,9}\.\d{0,9}"/>

           =              = </restriction>

</simpleType>

 

4)=20 AlgorithmsType

 

5)=20 KeyID

DSKPP=20 base64binary

PSKC=20 string

 

 

________________________________

 

Philip Hoyer=20

 

Senior Architect - = Office of=20 CTO

 

ActivIdentity=20 (UK)=

109 Borough High=20 Street

London SE1=20 1NL

 

Telephone: +44 (0) = 20 7744=20 6248

Direct: +44 (0) 20 = 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C8111C.5088CA00-- --===============1249209449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1249209449==-- From keyprov-bounces@ietf.org Wed Oct 17 20:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJFR-0003aX-9l; Wed, 17 Oct 2007 20:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJFP-0003Sf-JW for keyprov@ietf.org; Wed, 17 Oct 2007 20:28:23 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiJFK-0002G9-9w for keyprov@ietf.org; Wed, 17 Oct 2007 20:28:19 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I0RtGK018418; Wed, 17 Oct 2007 20:27:55 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I0RodW007140; Wed, 17 Oct 2007 20:27:51 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l9I0RouS001627; Wed, 17 Oct 2007 20:27:50 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8111D.B6AF04DF" Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Oct 2007 20:27:32 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B017@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <5BFE9E473DBFC24CA87F18F29B3F0AC4758281@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAA= References: <1190365090.79.0.72059660846.issue28@http://www.tschofenig.priv.at> <5BFE9E473DBFC24CA87F18F29B3F0AC4758281@sur-corp-ex-02.corp.ad.activcard.com> From: "Doherty, Andrea" To: "Philip Hoyer" , "KEYPROV Roundup Issue Tracker" , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Cc: "M'Raihi, David" , "Bajaj, Siddharth" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8111D.B6AF04DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Philip, This looks ok except that a more complex PIN policy is needed (refer to this comment I made to the previous version of the PSKC draft, Section 5.1.7: "Recommend that you allow for a more complex PIN policy, esp., (a) how the PIN is to be used in the OTP calculation (e.g., concatenated vs. XOR's with the token code) and (b) PIN length. " This doesn't seem to have been addressed yet based on feedback to my review (see attached) and example below. What is the status of this? =20 Andrea -----Original Message----- From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Friday, September 28, 2007 11:48 AM To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Gentlemen, Since PSKC will be used also to bulk provision from manufacturing to a validation server and some of these devices do have a PIN pad there is the concept of an initial PIN. Since we have not yet defined how this initial PIN is transmitted in the PSKC spec I would like to put forward a proposal for inclusion in the spec for specifying the transmission of PINs. The PIN is effectively another shared secret hence I propose to treat it as a key in itself. This has the advantage that we can leverage the Usage part of the schema that can define things like length and format (alphanumeric etc). we also can set an expiry etc. It also leverages the fact that the PIN itself will be encrypted in transport in the same manner as other key material. I hence propose to extend the KeyAlgorithmType with a new type called 'userPIN' (inline with the name used in the access rules element already present) As an example a KeyContainer with a non encrypted HOTP key and a 4 digit numeric PIN (please note that the value and valuedigest are just copy and paste) ( I put the new section with NEW-> and <-NEW lines before and after): Token Manufacturer 98765432187 01/01/2008 Credential Issuer NEW-> <-NEW MyFirstToken WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D NEW-> Credential Issuer MyFirstTokenInitialPIN WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D <-NEW Comments are welcome, Philip -----Original Message----- From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, September 21, 2007 9:58 AM To: keyprov@ietf.org Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client viaPSKC? New submission from Mingliang Pei : PSKC provies support about carrying PIN usage policy. When PIN is used, how do=20 you actually transfer the initial PIN using PSKC? Should PIN be treated as=20 another credential, for example? ---------- assignedto: mpei messages: 71 nosy: keyprov, mpei priority: critical status: chatting title: How to transfer initial PIN to a client via PSKC? _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C8111D.B6AF04DF Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: from rsaeu-ex-uk2.eu.rsa.net ([10.148.48.60]) by rsana-ex-hq1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Aug 2007 19:37:48 -0400 Received: from rsasecurity.com ([10.148.48.70]) by rsaeu-ex-uk2.eu.rsa.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 00:37:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from echoes.eu.rsa.net (echoes.eu.rsa.net [192.168.5.70]) by rsasecurity.com (8.13.5/8.12.9) with ESMTP id l7SNSZr0015184 for ; Tue, 28 Aug 2007 23:28:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail-sin.bigfish.com (mail-sin.bigfish.com [207.46.51.74]) by echoes.eu.rsa.net (MOS 3.8.3-GA) with SMTP id BSJ51822; Tue, 28 Aug 2007 22:56:20 GMT Received: from mail-sin.bigfish.com ([207.46.51.74]) by mail-sin.bigfish.com via smtpd (for mailhost.rsasecurity.com [192.168.5.70]) with SMTP; Wed, 29 Aug 2007 00:31:47 +0100 Received: from mail88-sin (localhost.localdomain [127.0.0.1]) by mail88-sin-R.bigfish.com (Postfix) with ESMTP id D1341BE80A7 for ; Tue, 28 Aug 2007 23:37:42 +0000 (UTC) Received: by mail88-sin (MessageSwitch) id 1188344259874628_1270; Tue, 28 Aug 2007 23:37:39 +0000 (UCT) Received: from supertimor.gemplus.com (supertimor.gemalto.com [194.88.222.178]) by mail88-sin.bigfish.com (Postfix) with ESMTP id 9F0581BF0086 for ; Tue, 28 Aug 2007 23:37:38 +0000 (UTC) Received: from GMSEXC02.CORP.DS.GEMPLUS.COM (unknown [10.2.158.62]) by supertimor.gemplus.com (Postfix) with ESMTP id 120B91FB021; Tue, 28 Aug 2007 23:37:36 +0000 (GMT) Received: from GMSEXC07.CORP.DS.GEMPLUS.COM ([10.2.158.55]) by GMSEXC02.CORP.DS.GEMPLUS.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 01:37:36 +0200 Content-class: urn:content-classes:message Subject: RE: [KEYPROV] Review comments - PSKC Date: Tue, 28 Aug 2007 19:33:06 -0400 Message-ID: <093F8C873752A84D98A28841099DF380178D7B@GMSEXC07.CORP.DS.GEMPLUS.COM> In-reply-to: <017630AA6DF2DF4EBC1DD4454F8EE2970C2C849E@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Review comments - PSKC Thread-Index: AcfCF8H5roqi9T3eT+Sz0sEoRNv5sAAJE+nAB3G4/3ACbsNlcA== From: "CHANG Shuh" To: "Doherty, Andrea" , "Pei, Mingliang" , , "Philip Hoyer" , , "CHANG Shuh" Hi Andrea, Thanks for the great comments on the PSKC draft. The PSKC WG had an extensive discussion today and is providing the responses shown below under each issue. Regards, Shuh =20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 > Sent: Thursday, August 16, 2007 8:50 AM > To: Pei, Mingliang; keyprov@ietf.org; Philip Hoyer > Subject: [KEYPROV] Review comments - PSKC >=20 > I reviewed draft-hoyer-keyprov-portable-symmetric-key-container-02.txt > and have the following comments: >=20 > General: > =3D=3D=3D=3D=3D=3D=3D=3D > 1. Align terminology with DSKPP, esp. use of "token",=20 > "credentials", "seed records", "shared secret", "secret key",=20 > "attributes" throughout the document. We acknowledge this issue, and will address it in the next revision. >=20 > 2. Add section for IANA Considerations We will add this IANA section in this revision. (Ming's work item) >=20 > 3. Several typos found; recommend running document through=20 > spell checker. Yes, we'll do that. (Ming's work item) >=20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Is last paragraph appropriate for IETF document? We'll remove this paragraph and add it in the Acknowledgement section. (Ming's work item) This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. >=20 > Section 1 (Introduction): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > 1. It would be best if this document would be more generic to=20 > application context. Currently, it is still more "OTP"=20 > focused than useful for all constituents interested in this=20 > specification. Need further discussion, and we'll address this issue in the next revision. >=20 > 2. First sentence should read "...systems based ^^upon^^ one time..." Yes, we'll correct that. (Ming will correct it today.) >=20 > 3. Last sentence has spelling error "wherears" Yes, we'll correct that. (Ming will correct it today.) >=20 > Section 3.1.1 (Credential migration by end-user): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Last paragraph - this is example where alignment with DSKPP=20 > Key Initialization Profiles will be required (refer to Issue=20 > #9 in issue tracker). Need further discussion, and we'll address this issue in the next revision. >=20 > Section 3.2.1 (Online provisioning...): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Perhaps clarify last sentence of first paragraph ("user can=20 > download more than one..."). Doesn't this capability depend=20 > on whether an application has concept of a session, and how=20 > the session is defined? > Note that this capability is more of a provisioning server=20 > feature, and is not applicable to DSKPP. We'll clarify and rephrase the sentence to "a payload can contain multiple credentials". We'll address this issue in this revision. >=20 > Section 3.2.2 (Server to server...): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > First sentente, "...information from ^^a^^ manufacturer". Yes, we'll correct that. (Ming will correct it today.) >=20 > Section 5.1.4 (KeyID): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > Perhaps add explanation here that namespace is not encoded=20 > into the KeyID, but maintained as a separate attribute, e.g.,=20 > "Issuer". Agree and will do it in the next revision.. (Ming's action item) >=20 > Section 5.1.7 (AccessRules): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Recommend that you allow for a more complex PIN policy, esp.,=20 > (a) how the PIN is to be used in the OTP calculation (e.g.,=20 > concatenated vs. > XOR's with the token code) and (b) PIN length. Yes, agree. Ming will open an issue in issuer tracker. Add (c) how to transfer initial PIN value. Shuh to chat with people for some best practice. The issue "When PIN is used, how do you actually transfer the initial PIN using PSKC?" needs to be further discussed. Different vendors might have different approaches. We'd also like to solicit from the KeyProv list members for inputs on this issue. >=20 > Section 5.1.8 (EncryptionMethod): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > 1. Align this section with DSKPP Key Initialization Methods=20 > (see Issue Tracker #9). We'll defer this to next revision. >=20 > 2. Last paragraph - "KeyContainer" is referred to here, but=20 > not previously defined. We'll rephrase this sentence by changing word "KeyContainer" to "payload". >=20 > Section 6 (diagram): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. Typo in diagram -- arrow between Key n and Key p should be=20 > shown to the right. Yes and will correct. (Shuh's action item) >=20 > 2. Align model represented by the diagram with Object Model in DSKPP. This issue has been discussed in a previous PSKC conf call. The diagram is a more clear representation of the container. On the other hand, a more detailed object model will be genereated after the final XML schema is finalized. (Shuh's work item) >=20 > 3. Provide note that while PSKC supports bulk provisioning of=20 > keys, DSKPP does not. This is a provisioning protocol, not a format. Therefore, it's better to specify it in DSKPP. >=20 > Section 6.1.1 (KeyType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. SECRET has typo "key key".=20 Agree and will correct. (Ming will correct it today.) >=20 > 2. Last paragraph on 'Value Digest' - Perhaps refer to=20 > Section 5.1.8 for clarity. Agree and will rephrase in this revision. >=20 > Section 6.1.2 (UsageType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > - replace reference to [OCRA] with URI. We'll do that in the next revision. Deferred when URI is used. >=20 > Section 6.1.4 (DeviceIdType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 1. Would be better if description were more generic; add=20 > storage device as an example. We'll rephrase it in the next revision. >=20 > 2. I recommend base64Binary as data type for SerialNo. Will track as an issue to discuss. (Ming) >=20 > Section 6.1.5 (UserType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > To be consistent with the DSKPP Object Model, "UserIdType"=20 > would be more consistent that "UserType". Alternatively,=20 > "ClientIDType" would be more consistent than "UserType" since=20 > a user may be a software application. We'll refer this to further study. >=20 > Section 6.1.9 (AlgorithmIdentifierType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. Replace [OCRA] throughout this section with appropriate URI. We'll do that in the next revision. >=20 > 2. "The AlgorithmIdentifierType is define^^d^^ as follows" Agree and will correct. (Ming) >=20 > Section 6.5 (KeyAlgorithmType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > This type overlaps with "KeyType" in DSKPP; align. PSKC already has a KeyType. KeyAlgorithm is another attribute layer on top of KeyType. The KeyAlgorithmType in PSKC is different from KeyType in DSKPP. KeyAlgorithmType is the algorithm where the key will be applied. Therefore, we'll need to do more study on this issue to better clarify. >=20 > Section 8.1 (Payload Confidentiality): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I recommend that you identify and define each of the profiles=20 > that are described at a high-level here. We'll defer it to the next revision. >=20 > Section 8.2 (Payload Integrity): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > "provides a mean^^s^^ to" Agree and will correct. (Ming to change today) >=20 > Section 11 (Normative References): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. Many of the references in the list are not normative but=20 > "informative" (e.g., all of the I-D's). I think the section=20 > should either be divided in two, or simply called "References". We need to further discuss this issue. >=20 > 2. Is [OATHRefArch] used in the document? Will remove it. >=20 > 3. Update [DSKPP] reference to draft-ietf-keyprov-dskpp-00.txt. Agree. (Ming to change in this revision) >=20 >=20 > -- Andrea >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 ------_=_NextPart_001_01C8111D.B6AF04DF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C8111D.B6AF04DF-- From keyprov-bounces@ietf.org Wed Oct 17 21:24:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiK7J-0004P7-Lp; Wed, 17 Oct 2007 21:24:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiK7H-0004H0-Mh for keyprov@ietf.org; Wed, 17 Oct 2007 21:24:03 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiK7B-0003aH-He for keyprov@ietf.org; Wed, 17 Oct 2007 21:23:58 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I1Nc1o029299 for ; Wed, 17 Oct 2007 21:23:38 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9I1NaTH008221 for ; Wed, 17 Oct 2007 21:23:36 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l9I1NauS004719 for ; Wed, 17 Oct 2007 21:23:36 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [KEYPROV] DSKPP X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Oct 2007 21:23:19 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B024@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] DSKPP Thread-Index: AcfPE0KYAEOz/gseRdid3evFyDI8eQAhW0pABblFyxAKqW/GgA== From: "Doherty, Andrea" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=9%, Reasons='SUBJ_ALL_CAPS! .5, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.2 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Here are some off-mailing list comments that I received on the current version of the DSKPP I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TECHNICAL COMMENTS In 4.6 and subsequent cases (e.g., 4.8.1.1, 4.8.1.2), I think a little more specification is needed for interoperability. At 4.6, when constructing the s input to DSKPP-PRF, just how are k and R_S converted to strings? What radix, and are there spaces or other delimiters between them? An example and a few more rules would be helpful at this point.=20 Per 7.2.4, would a means in the 4-pass protocol for the server to perform key confirmation of the client be feasible or useful? Could, e.g., carry a MAC?=20 At A.4, is it feasible and acceptable for the server to retain the K_DERIVED form rather than the input passphrase? If so, suggest restating the first paragraph to correspond.=20 SPECIFIC POINTS Sec. 1.2, 1st para: the examples in the first sentence should be clearly stated as examples. As written, the list could be misconstrued as prescriptive. Sec. 3.3: Suggest emphasizing that the validity period construct is something within an endpoint, NOT an aspect of the protocol per se.=20 Sec. 3.6, 1st para: don't think that we should be presuming to state requirements for classified government modules; suggest dropping that reference.=20 Sec. 3.8: How can the cryptographic module provide assurance for SMS? Isn't this really a judgment to be made by deployers?=20 Sec. 4.1, figure legend: Do devices necessarily need to be hardware-based? Can't modules be hosted within a software framework? Sec. 4.1, figure legend: Can a cryptographic module also reside outside the application, somewhere else within its processing environment?=20 Sec. 4.3.1.3, shortly after Fig. 7, under the heading "AuthenticationData =3D Hash (AC)", the text describes a case where the authentication data may be plaintext. Given the heading, this structure is confusing.=20 At 4.8.1.1 (and similarly in 4.8.1.2), is the choice of alternatives necessary? If so, should the choice of key be tagged somehow so that the recipient doesn't need to guess?=20 At 4.9.8, is the intent to constrain a nonce to at least 16 octets of base64 representation (which I think this does), or to 16 octets of underlying binary value before base64 encoding?=20 4.10.3, : "... identifier MUST only be present if such shared secrets exist..." Which shared secrets?=20 7.2.2, 3rd para: "Clients will protect" -> "Clients MAY protect"?=20 7.6.4, "When an Authentication Code..." bullet reads oddly, seeming to suggest that use of SSL or TLS adds the ability to perform a guessing attack that would be infeasible if SSL/TLS weren't present.=20 App C, Req-8, requirement seems vague. Is the intent for the 2nd sentence to require symmetric method support or, as it reads, just anything that's not PKI? App C, Req-9, "SHOULD NOT only rely on" -> "SHOULD NOT require". App C, Req-10, citation to Global Platform (who?) seems out of place without a reference. If this is really an i.e. (therefore defining, not an example), it shouldn't be a SHOULD without a specification or more detail. (And, if it's going to be, there's room for IETF argument as to why...)=20 App C, Req-16: Isn't this an implementation limit, not something within the protocol?=20 EDITORIAL Sec. 1.2, 2nd paragraph, 1st sentence: seems strange to describe a server as a "mechanism". "... makes use of a symmetric key provisioning server", maybe?=20 Sec. 3.2, text: A trademark reference may be needed to accompany "RSA SecurID", but that's a question for Legal.=20 p. 17, last 2 paragraphs: believe that these upper case MAYs should be down-cased, as they don't (per RFC-2119) refer to implementation requirements.=20 Sec. 4.3.1.2, 1st sentence, suggest added clause at end: "corresponding to a particular cryptographic module". =20 4.3.1.3, there's an apparently garbled phrase "K_AUTH MAY be derived AES key from..." 4.9.5, 1st full para, last line, "MUST not" -> "MUST NOT".=20 4.9.5, error descriptions: in NoSupportedEncryptionAlgorithms through NoSupportedKeyContainer descriptions, the last sentences seem redundant. If they're not actually adding value relative to their preceding texts, suggest deleting them.=20 4.10.3, , 2nd sentence: suggest "exists or was" -> "exists or if the identifier was"=20 7.2.2, 1st sentence, suggest "or the DSKPP client" -> "or will cause the DSKPP client".=20 7.6.4, 3rd bullet, "length the of" -> "length of the".=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Oct 18 01:17:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiNkl-0008OT-Pr; Thu, 18 Oct 2007 01:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiNkj-0008DU-E9 for keyprov@ietf.org; Thu, 18 Oct 2007 01:17:01 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiNkZ-0001Qg-Ck for keyprov@ietf.org; Thu, 18 Oct 2007 01:16:58 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9I5BSbF015653; Wed, 17 Oct 2007 22:11:28 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 06:14:52 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C81145.CFD6B7A6" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Oct 2007 22:14:50 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503D02@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBM6pTg From: "Pei, Mingliang" To: "Philip Hoyer" , , "Hallam-Baker, Phillip" , , , "Doherty, Andrea" , X-OriginalArrivalTime: 18 Oct 2007 05:14:52.0146 (UTC) FILETIME=[D0143520:01C81145] X-Spam-Score: 0.0 (/) X-Scan-Signature: 320d33915a60f51e3fbb2018f22d9f93 Cc: Subject: [KEYPROV] Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C81145.CFD6B7A6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C81145.CFD6B7A6" ------_=_NextPart_002_01C81145.CFD6B7A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 In our effort to use URIs instead of enumerations in PSKC for EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we found that some algorithms don't have a defined / registered URIs yet, mostly, for the PBE methods and Key Algorithms. Attached please find current laundry list of the algorithms for their respective URIs, and those that need some URIs to be defined. We found most URIs defined by XML signature and encryption specification (xmldsig, additional xmldsig URIs, and xmlenc ). =20 Please let us know if you find some places that have defined URIs for the listed missing ones, or any suggestions where we should define the new ones, for example, OTP algorithms by HOTP, variours vendors (VASCO, SecurID (if need one other than current RSA URL)). =20 Please see the attached doc for questions. Here are quoted questions: =20 =20 a) Where can we find URIs defined for PBE algorithms? =20 PBEs are defined in PKCS#5. The XML version defined the following URI. One PBE algorithm would need two URIs to define, for example, PBE-AES128-CBC would be identified with the following two: =20 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc =20 and possibly a third one that identifies key derivative function. =20 b) Shall we define one URI for each PBE method with encryption such as PBE-AES128-CBC? =20 Thank you, =20 - Ming =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 9:23 AM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: IETF Keyprov PSKC meeting minutes 15/10.07 =09 =09 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_002_01C81145.CFD6B7A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
In our effort to use URIs instead of = enumerations in=20 PSKC for EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we = found=20 that some algorithms don't have a defined / registered URIs yet, mostly, = for the=20 PBE methods and Key Algorithms. Attached please find current laundry = list of the=20 algorithms for their respective URIs, and those that need some URIs to = be=20 defined. We found most URIs defined by XML signature and encryption=20 specification (xmldsig, additional xmldsig URIs, and xmlenc=20 ).
 
Please let us know if you find some places = that have=20 defined URIs for the listed missing ones, or any suggestions where we = should=20 define the new ones, for example, OTP algorithms by HOTP, = variours vendors=20 (VASCO, SecurID (if need one other than current RSA = URL)).
 
Please see the attached doc for questions. = Here are=20 quoted questions:
 
 

a) Where can=20 we find URIs defined for PBE algorithms?

 

PBEs are=20 defined in PKCS#5. The XML version defined the following URI. One PBE = algorithm=20 would need two URIs to define, for example, PBE-AES128-CBC would be = identified=20 with the following two:

 

htt= p://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2

http://www.w3.org= /2001/04/xmlenc#kw-aes128-cbc

 

and possibly=20 a third one that identifies key derivative function.

 

b) Shall we=20 define one URI for each PBE method with encryption such as=20 PBE-AES128-CBC?

 

Thank you,
 
- Ming
 

From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, = October 16,=20 2007 9:23 AM
To: Hannes.Tschofenig@gmx.net; Hallam-Baker, = Phillip;=20 Pei, Mingliang; shuh.chang@gemalto.com; = smachani@diversinet.com
Cc:=20 keyprov@ietf.org
Subject: IETF Keyprov PSKC meeting minutes=20 15/10.07

Attendees:=20

Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, = Phillip=20 Hallam-Baker, Hannes Tschofenig

 

 

 

1)      =20 Initially = decided to=20 tackle the issue of algorithms that are represented as enumerations in = PSKC=20 and if we should go to a URI based approach that allows for easier = extension.=20 There are 3 type of algorithm definitions in = PSKC

a.      =20 EncryptionAlgorithm of=20 the key material in the container

b.      =20 DigestAlgorithm to=20 create a digest of the uncencrypted keys

c.      =20 OTP = Algorithm,=20 identifier of the algorithm that the key is being used=20 with

2)      =20 Agreed to = change=20 EncryptionAlgorithm and DigestAlgorithm to change to=20 URI

3)      =20 Ming Pei to change=20 schema and add minimum list of URIs

a.      =20 Issue, what = about PBE=20 related algorithms, no URIs found by Ming

b.      =20 Ming Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he=20 has not found URIs. Philip Hallam Baker will then try to find URIs or = get back=20 to authors with way to proceed

4)      =20 Discussion = about digest=20 of the key for RSA encrypted keys – Ming, Shuh to check if it is = a bad idea –=20 Philip to ask to the list

a.      =20 The problem = here is=20 that the Digest used for symmetric algorithms is a keyed digest eg = HMAC-SHA1=20 which is still not broken. If for transmission of keys wrapped by a = public Key=20 of the receiving party we use a simple digest iof the unencrypted key=20 material, it might open the container for brute force attacks. Since a = keyvalue to hash value mapping might be much quicker to find than = brute=20 forcing HMAC-SHA1

5)      =20 URIs for = KeyAlgorithm?=20

a.      =20 Fundamentally the=20 people agreed that it is a better idea but even more than encryption = and=20 digest algorithms, OTP algotihms do not have a defined=20 URI

b.      =20 Ming Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he=20 has not found URIs Philip Hallam Baker will then try to find URIs or = get back=20 to authors with way to proceed

6)      =20 Philip = Hoyer proposed=20 to introduce a keyType at container level with attributes such as = algorithm=20 and logo and usage type that the key can reference (this would avoid = repeating=20 all the data for similar keys within the container) – Everyone = agreed that=20 this was a good idea but  deemed a priority 2=20 item

7)      =20 Hannes to = investigate=20 what best practice is regarding URN versioning, current proposal is to = add=20 numeric version so all ietf:keyprov URN should add=20 ‘:1’

8)      =20 Should we = reorganise=20 PBE to support PKCS5 XML schema, currently this was deemed to = complicate the=20 schema too much so it was deferred for now =

9)      =20 Discussion = around=20 attributes and elements, should the ASN.1 document contain the = description of=20 the attributes. Decision for ASN.1document to incorporate attribute = definition=20 of PSKC spec. Hannes to send email to the = list.

10)  =20 Discussion = if we need=20 to have a face to face meeting to align spec. Hannes asked if a set of = conference calls with a precise short agenda. Would be good. Should we = have a=20 weekly conference call? Agreed to have a weekly call on Monday 3pm = Central 4pm=20 EDT 9 pm for 30 minutes

11)  =20 IV should = be moved back=20 to EncryptionMethod since it is used for symmetric algorithms and not = only for=20 PBE (Ming in his latest revision had moved it to the PBEParams=20 element)

12)  =20 Discussed = initial PIN=20 transmission, Philip invited for participants to review and agree. If = no=20 disagreements Philip Hoyer will include in October revision of the=20 spec

 

 

 

 

________________________________

 

Philip=20 Hoyer=20

 

Senior Architect = - Office=20 of CTO

 

ActivIdentity=20 (UK)=

109 Borough High = Street

London SE1=20 1NL

 

Telephone: +44 = (0) 20 7744=20 6248

Direct: +44 (0) = 20 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended=20 recipient,

you must not = copy,=20 distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_002_01C81145.CFD6B7A6-- ------_=_NextPart_001_01C81145.CFD6B7A6 Content-Type: application/msword; name="URIs for Algorithms in PSKC.doc" Content-Transfer-Encoding: base64 Content-Description: URIs for Algorithms in PSKC.doc Content-Disposition: attachment; filename="URIs for Algorithms in PSKC.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAeQAAAAAAAAAA EAAAdwAAAAEAAAD+////AAAAAHoAAACAAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAA2AJBAAA+BK/AAAAAAAAEAAAAAAABgAA4RYAAA4AYmpiao/qj+oAAAAAAAAAAAAAAAAAAAAA AAAJBBYALnYAAO2AAADtgAAA4Q4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAEgEAAAAAAAASAQAAEgE AAAAAAAASAQAAAAAAABIBAAAAAAAAEgEAAAAAAAASAQAABQAAAAAAAAAAAAAAFwEAAAAAAAAZCUA AAAAAABkJQAAAAAAAGQlAAAAAAAAZCUAAFQAAAC4JQAAJAEAAFwEAAAAAAAA7y4AAPYAAADoJgAA tAEAAJwoAAAAAAAAnCgAAAAAAACcKAAAAAAAAJwoAAAAAAAAnCgAAAAAAACcKAAAAAAAAJwoAAAA AAAAbi4AAAIAAABwLgAAAAAAAHAuAAAAAAAAcC4AAAAAAABwLgAAAAAAAHAuAAAAAAAAcC4AACQA AADlLwAAaAIAAE0yAABwAAAAlC4AABUAAAAAAAAAAAAAAAAAAAAAAAAASAQAAAAAAACcKAAAAAAA AAAAAAAAAAAAAAAAAAAAAACcKAAAAAAAAJwoAAAAAAAAnCgAAAAAAACcKAAAAAAAAJQuAAAAAAAA AAAAAAAAAABIBAAAAAAAAEgEAAAAAAAAnCgAAAAAAAAAAAAAAAAAAJwoAAAAAAAAqS4AABYAAACG KgAAAAAAAIYqAAAAAAAAhioAAAAAAACcKAAAagAAAEgEAAAAAAAAnCgAAAAAAABIBAAAAAAAAJwo AAAAAAAAbi4AAAAAAAAAAAAAAAAAAIYqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnCgAAAAAAABuLgAAAAAAAAAAAAAAAAAAhioAAAAAAAAAAAAA AAAAAIYqAAAAAAAASAQAAAAAAABIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhioAAAAAAACcKAAAAAAAANwmAAAMAAAAoGd9qkUR yAEAAAAAAAAAAGQlAAAAAAAABikAACIAAACGKgAAAAAAAAAAAAAAAAAA+ioAAHQDAAC/LgAAMAAA AO8uAAAAAAAAhioAAAAAAAC9MgAAAAAAACgpAABIAQAAvTIAAAAAAACGKgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAL0yAAAAAAAAAAAAAAAAAABIBAAAAAAAAIYqAAB0AAAAnCgAAAAAAACcKAAAAAAAAIYq AAAAAAAAnCgAAAAAAACcKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnCgA AAAAAACcKAAAAAAAAJwoAAAAAAAAlC4AAAAAAACULgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcCoAABYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwoAAAA AAAAnCgAAAAAAACcKAAAAAAAAO8uAAAAAAAAnCgAAAAAAACcKAAAAAAAAJwoAAAAAAAAnCgAAAAA AAAAAAAAAAAAAFwEAAAAAAAAXAQAAAAAAABcBAAAZBEAAMAVAACkDwAAXAQAAAAAAABcBAAAAAAA AFwEAAAAAAAAwBUAAAAAAABcBAAAAAAAAFwEAAAAAAAAXAQAAAAAAABIBAAAAAAAAEgEAAAAAAAA SAQAAAAAAABIBAAAAAAAAEgEAAAAAAAASAQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1VUklz IGZvciBBbGdvcml0aG1zIGluIFBTS0MNMTAvMTYvMjAwNw1NaW5nbGlhbmcgUGVpDQ0xLiBFbmNy eXB0aW9uIEFsZ29yaXRobXMNDWEpIFdoZXJlIGNhbiB3ZSBmaW5kIFVSSXMgZGVmaW5lZCBmb3Ig UEJFIGFsZ29yaXRobXM/DQ1QQkVzIGFyZSBkZWZpbmVkIGluIFBLQ1MjNS4gVGhlIFhNTCB2ZXJz aW9uIGRlZmluZWQgdGhlIGZvbGxvd2luZyBVUkkuIE9uZSBQQkUgYWxnb3JpdGhtIHdvdWxkIG5l ZWQgdHdvIFVSSXMgdG8gZGVmaW5lLCBmb3IgZXhhbXBsZSwgUEJFLUFFUzEyOC1DQkMgd291bGQg YmUgaWRlbnRpZmllZCB3aXRoIHRoZSBmb2xsb3dpbmcgdHdvOg0NEyBIWVBFUkxJTksgImh0dHA6 Ly93d3cucnNhc2VjdXJpdHkuY29tL3JzYWxhYnMvcGtjcy9zY2hlbWFzL3BrY3MtNSNwYmVzMiIg ARRodHRwOi8vd3d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL3BrY3Mvc2NoZW1hcy9wa2NzLTUj cGJlczIVDRMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNrdy1h ZXMxMjgtY2JjIiABFGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczEyOC1j YmMVDQ1hbmQgcG9zc2libHkgYSB0aGlyZCBvbmUgdGhhdCBpZGVudGlmaWVzIGtleSBkZXJpdmF0 aXZlIGZ1bmN0aW9uLg0NYikgU2hhbGwgd2UgZGVmaW5lIG9uZSBVUkkgZm9yIGVhY2ggUEJFIG1l dGhvZCB3aXRoIGVuY3J5cHRpb24gc3VjaCBhcyBQQkUtQUVTMTI4LUNCQz8NDVRoZSBvdGhlciBu b24tUEJFIGFsZ29yaXRobXMgaGF2ZSBzb21lIFVSSXMgbW9zdGx5IGRlZmluZWQgaW4geG1sZW5j IHNwZWNpZmljYXRpb246DQ0TIEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvVFIveG1sZW5j LWNvcmUvI3NlYy1BbGdvcml0aG1zIiABFGh0dHA6Ly93d3cudzMub3JnL1RSL3htbGVuYy1jb3Jl LyNzZWMtQWxnb3JpdGhtcxUNDUFsZ29yaXRobSBOYW1lB1VSSQcHUEJFLTNERVMxMTItQ0JDBz8H B1BCRS0zREVTMTY4LUNCQwc/BwdQQkUtQUVTMTI4LUNCQwc/BwdQQkUtQUVTMjU2LUNCQwc/BwdQ QkUtQUVTMTkyLUNCQwc/BwczREVTMTEyLUNCQwc/BwczREVTMTY4LUNCQwcTIEhZUEVSTElOSyAi aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMiIFxsICJ0cmlwbGVkZXMtY2JjIiAUaHR0 cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjdHJpcGxlZGVzLWNiYxUHB0FFUzEyOC1DQkMH EyBIWVBFUkxJTksgImh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIiBcbCAiYWVzMTI4 LWNiYyIgFGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2FlczEyOC1jYmMVBwdBRVMx OTItQ0JDBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyIgXGwg ImFlczE5Mi1jYmMiIBRodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMxOTItY2Jj FQcHQUVTMjU2LUNCQwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxl bmMjYWVzMjU2LWNiYyIgARRodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMyNTYt Y2JjFQcHUlNBLTFfNQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxl bmMiIFxsICJyc2EtMV81IiAUaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjcnNhLTFf NRUHB1JTQS1PQUVQLU1HRjFQBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0 L3htbGVuYyIgXGwgInJzYS1vYWVwLW1nZjFwIiAUaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94 bWxlbmMjcnNhLW9hZXAtbWdmMXAVBwdLV18zREVTX0NCQwcTIEhZUEVSTElOSyAiaHR0cDovL3d3 dy53My5vcmcvMjAwMS8wNC94bWxlbmMiIFxsICJrdy10cmlwbGVkZXMiIBRodHRwOi8vd3d3Lncz Lm9yZy8yMDAxLzA0L3htbGVuYyNrdy10cmlwbGVkZXMVBwdLV19BRVNfMTI4BxMgSFlQRVJMSU5L ICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyIgXGwgImt3LWFlczEyOCIgFGh0dHA6 Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczEyOBUHB0tXX0FFU18xOTIHEyBIWVBF UkxJTksgImh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczI1NiIgARRodHRw Oi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNrdy1hZXMyNTYVIAcHS1dfQUVTXzI1NgcTIEhZ UEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMja3ctYWVzNTEyIiABFGh0 dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczUxMhUHBw1EaWdlc3QgQWxnb3Jp dGhtcw0NU0hBMQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2ln IiBcbCAic2hhMSIgFGh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExFQcHU0hB MjU2BxMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyIgXGwgInNo YTI1NiIgFGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NhUHB1NIQTUxMgcT IEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjc2hhNTEyIiABFGh0 dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTUxMhUgBwcNTWFjIEFsZ29yaXRobXMN DUhNQUMtU0hBMQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2ln IiBcbCAiaG1hYy1zaGExIiAUaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2htYWMt c2hhMRUHB0hNQUMtU0hBMjU2BxMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0 L3htbGRzaWctbW9yZSNobWFjLXNoYTI1NiIgARRodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3ht bGRzaWctbW9yZSNobWFjLXNoYTI1NhUgBwdITUFDLVNIQTUxMgcTIEhZUEVSTElOSyAiaHR0cDov L3d3dy53My5vcmcvMjAwMS8wNC94bWxkc2lnLW1vcmUjaG1hYy1zaGE1MTIiIAEUaHR0cDovL3d3 dy53My5vcmcvMjAwMS8wNC94bWxkc2lnLW1vcmUjaG1hYy1zaGE1MTIVIAcHDUtleSBBbGdvcml0 aG1zDQ1jKSBXaGVyZSBzaGFsbCB3ZSBkZWZpbmUgVVJJcyBmb3Iga2V5IHVzYWdlIGFsZ29yaXRo bXM/DQ0gM0RFUzExMgc/BwcgM0RFUzE2OAcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcv MjAwMS8wNC94bWxlbmMiIFxsICJ0cmlwbGVkZXMtY2JjIiAUaHR0cDovL3d3dy53My5vcmcvMjAw MS8wNC94bWxlbmMjdHJpcGxlZGVzLWNiYxUHByBBQ1RJBz8HByBBRVMxMjgHEyBIWVBFUkxJTksg Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIiBcbCAiYWVzMTI4LWNiYyIgFGh0dHA6 Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2FlczEyOC1jYmMVBwcgQUVTMTkyBxMgSFlQRVJM SU5LICJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyIgXGwgImFlczE5Mi1jYmMiIBRo dHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMxOTItY2JjFQcHIEFFUzI1NgcTIEhZ UEVSTElOSyAiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjYWVzMjU2LWNiYyIgARRo dHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMyNTYtY2JjFQcHIEFOU0lYOS45Bz8H ByBERVMHPwcHIEhPVFAHPwcHIE1LRVlMQUJFTAc/BwcgUlNBU0VDVVJFSUQHEyBIWVBFUkxJTksg Imh0dHA6Ly93d3cucnNhLmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzA5L290cHMtd3N0 I1NlY3VySUQtQUVTIiABFGh0dHA6Ly93d3cucnNhLmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8y MDA1LzA5L290cHMtd3N0I1NlY3VySUQtQUVTFSAHByBWQVNDTwc/BwcNAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAQgAABwIAAAd CAAANQgAADYIAAA3CAAAOggAAFAIAABRCAAAVAgAAIgIAABHCQAASQkAAEoJAABWCQAAkgkAAJQJ AACVCQAAlgkAANIJAADTCQAA1AkAANUJAADhCQAADwoAABEKAAASCgAAEwoAAEEKAABCCgAAhwoA AIoKAACiCgAA3AoAAN0KAADeCgAA3woAADILAAA0CwAANQsAAEELAABxCwAA/PTv6uL82tL8zsrG wrrCs8Koup+6wpfGkMaFl3yXxs7GzsaQs8bKdMptAAAAAAwVaFI+4gAWaFI+4gAADwNqAAAAABZo Uj7iAFUIARAVaI4W0wAWaEZ72gAwShAAABUCCIEDam0BAAAGCAEWaEZ72gBVCAEMFWhGe9oAFmhG e9oAAA8DagAAAAAWaEZ72gBVCAEQFWiOFtMAFmjlKycAMEoQAAAVAgiBA2oAAAAABggBFmjlKycA VQgBDBVo5SsnABZo5SsnAAAPA2oAAAAAFmjlKycAVQgBBhZo5SsnAAAGFmhGe9oAAAYWaFI+4gAA BhZoGmqYAAAPFWhSPuIAFmjdGw0ANQiBDxVoUj7iABZoUj7iADUIgQ8VaLo9PQAWaLo9PQA1CIEJ Fmi6PT0ANQiBCRZo3RsNADUIgQ8VaLo9PQAWaN0bDQA1CIEGFmjdGw0AKgAGAAABCAAAHQgAACgI AAA2CAAANwgAAFAIAABRCAAAhwgAAIgIAABICQAASQkAANQJAABDCgAARAoAAIYKAACHCgAA3goA AN8KAAAzCwAANAsAAKcLAACoCwAAtwsAALsLAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAABAAAZ2TdGw0AAAEAAAAYAAYAAOEWAAD+AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQFxCwAAcwsAAHQLAAB1CwAA pQsAAKYLAACnCwAAqAsAALsLAAC8CwAAzAsAAM0LAADPCwAA3wsAAOALAADiCwAA8QsAAPILAAD0 CwAAAwwAAAQMAAAGDAAAFQwAABYMAAAYDAAAIgwAACQMAAAlDAAAJwwAAC4MAAAvDAAAMwwAADQM AAB1DAAAdgwAAKQMAAClDAAApgwAAKcMAAD88eng6fzZ0c3Gws3Gws3Gws3Gws3Gws3Gt6+kt5y3 iHmIbIhhpBQVaLs4CQAWaN0bDQBtSAwEc0gMBAAYFWi7OAkAFmhSPuIAMEoQAG1IDARzSAwEAB0V aLs4CQAWaFI+4gBCKgFtSAwEcGgAAAAAc0gMBCYDagAAAAAVaLs4CQAWaFI+4gBCKgFVCAFtSAkA cGgAAAAAc0gJAAAOFmjdGw0AbUgMBHNIDAQAFBVoUj7iABZo3RsNAG1IDARzSAwEAA4WaFI+4gBt SAwEc0gMBAAUFWh6J7IAFmjdGw0AbUgMBHNIDAQABhZoF256AAAMFWhSPuIAFmjdGw0AAAYWaN0b DQAADxVo3RsNABZo3RsNADUIgQwVaFI+4gAWaFI+4gAAEBVojhbTABZoUj7iADBKEAAADwNqAAAA ABZoUj7iAFUIARUCCIEDaqICAAAGCAEWaFI+4gBVCAEGFmhSPuIAJrsLAAC8CwAAzAsAAM4LAACE AAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAA AAkAABYkAUlmAQAAAGdk3RsNAAB6AABrZN8DAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAE AQAABAEAAAQBAAAEAQAACNYwAAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAA AAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8A AAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADzgsAAM8LAADfCwAA4QsAAIQA AAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAA CQAAFiQBSWYBAAAAZ2TdGw0AAHoAAGtkPgQAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQB AAAEAQAABAEAAAQBAAAI1jAAApT/JAksIgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAA AAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAA AP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAPhCwAA4gsAAPELAADzCwAAhAAA AAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJ AAAWJAFJZgEAAABnZN0bDQAAegAAa2SdBAAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWMAAClP8kCSwiAAaQCQAAAAAAAAAAAAAAAAAAAAAABggZAAAAAAAAAAAA AAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA /x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA/MLAAD0CwAAAwwAAAUMAACEAAAA AAAAAAAAAAAAewAAAAAAAAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkA ABYkAUlmAQAAAGdk3RsNAAB6AABrZPwEAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAA BAEAAAQBAAAEAQAACNYwAAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAA AAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/ HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADBQwAAAYMAAAVDAAAFwwAAIQAAAAA AAAAAAAAAAB7AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAA FiQBSWYBAAAAZ2TdGw0AAHoAAGtkWwUAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAE AQAABAEAAAQBAAAI1jAAApT/JAksIgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAA AAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d 1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAMXDAAAGAwAACQMAAAmDAAAhAAAAAAA AAAAAAAAAHsAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAW JAFJZgEAAABnZN0bDQAAegAAa2S6BQAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQB AAAEAQAABAEAAAjWMAAClP8kCSwiAAaQCQAAAAAAAAAAAAAAAAAAAAAABggZAAAAAAAAAAAAAAAA AAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W CAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAAyYMAAAnDAAAMwwAAKYMAACEAAAAAAAA AAAAAAAAewAAAAAAAAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAABYk AUlmAQAAAGdk3RsNAAB6AABrZBkGAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNYwAAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAA AAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYI AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADpgwAAKcMAACyDAAAHw0AAIQAAAAAAAAA AAAAAAB7AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAFiQB SWYBAAAAZ2TdGw0AAHoAAGtkeAYAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAA BAEAAAQBAAAI1jAAApT/JAksIgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAAAAAA AAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggA AAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAOnDAAArQwAAK4MAACyDAAAswwAAPEMAADy DAAAHQ0AAB4NAAAfDQAAIA0AACsNAAAsDQAAag0AAGsNAACWDQAAlw0AAJgNAACZDQAApA0AAKUN AADeDQAA3w0AAOANAAALDgAADA4AAA0OAAAODgAAEQ4AABIOAAAWDgAAFw4AAFIOAABTDgAAew4A AHwOAAB9DgAA9e312crZvdmyp5jZytm92bKnjXnKYnm9ebKn9e312crZvdmyAAAAAAAAAAAAAAAA LAIIgQNqlQcAAAYIARVouzgJABZoUj7iAEIqAVUIAW1IDARwaAAAAABzSAwEACYDagAAAAAVaLs4 CQAWaFI+4gBCKgFVCAFtSAwEcGgAAAAAc0gMBAAUFWijbW4AFmjdGw0AbUgMBHNIDAQAHRVoo21u ABZo3RsNAEIqEG1IDARwaMDAwABzSAwEFBVoUj7iABZo3RsNAG1IDARzSAwEABQVaLs4CQAWaN0b DQBtSAwEc0gMBAAYFWi7OAkAFmhSPuIAMEoQAG1IDARzSAwEAB0VaLs4CQAWaFI+4gBCKgFtSAwE cGgAAAAAc0gMBCYDagAAAAAVaLs4CQAWaFI+4gBCKgFVCAFtSAkAcGgAAAAAc0gJAAAOFmjdGw0A bUgMBHNIDAQAFBVoeieyABZo3RsNAG1IDARzSAwEJB8NAAAgDQAAKw0AAJgNAACEAAAAAAAAAAAA AAAAewAAAAAAAAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAABYkAUlm AQAAAGdk3RsNAAB6AABrZNcGAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQB AAAEAQAACNYwAAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAA CnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA FPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA /wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADmA0AAJkNAACkDQAADQ4AAIQAAAAAAAAAAAAA AAB7AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAFiQBSWYB AAAAZ2TdGw0AAHoAAGtkNgcAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1jAAApT/JAksIgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAAAAAAAAAK dAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/ AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAMNDgAADg4AABYOAAB9DgAAhAAAAAAAAAAAAAAA AHsAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAWJAFJZgEA AABnZN0bDQAAegAAa2S+CAAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAA BAEAAAjWMAAClP8kCSwiAAaQCQAAAAAAAAAAAAAAAAAAAAAABggZAAAAAAAAAAAAAAAAAAAAAAp0 AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2 AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8A AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA30OAAB+DgAAjQ4AAAIPAACEAAAAAAAAAAAAAAAA ewAAAAAAAAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAABYkAUlmAQAA AGdk3RsNAAB6AABrZB0JAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAE AQAACNYwAAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAACnQA AOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYB AAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAA AP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADfQ4AAH4OAACBDgAAgg4AAIYOAACHDgAAjQ4AAI4O AADQDgAA0Q4AAAAPAAABDwAAAg8AAAMPAAAODwAADw8AABAPAABQDwAAUQ8AAH4PAAB/DwAAgA8A AIEPAACLDwAAjA8AAI0PAADKDwAAyw8AAPUPAAD2DwAA9w8AAPgPAAD/DwAA9e7q7uru1sfWutaz 6qugjH2McIx9ZaugjH2McIx9ZVYAAAAAAAAAAB0VaKNtbgAWaA492wBCKhBtSAwEcGjAwMAAc0gM BBQVaA492wAWaA492wBtSAwEc0gMBAAYFWi7OAkAFmgOPdsAMEoQAG1IDARzSAwEAB0VaLs4CQAW aA492wBCKgFtSAwEcGgAAAAAc0gMBCYDagAAAAAVaLs4CQAWaA492wBCKgFVCAFtSAkAcGgAAAAA c0gJAAAUFWh6J7IAFmgOPdsAbUgMBHNIDAQADhZoDj3bAG1IDARzSAwEAAwVaLs4CQAWaN0bDQAA GBVouzgJABZoUj7iADBKEABtSAkAc0gJAAAdFWi7OAkAFmhSPuIAQioBbUgJAHBoAAAAAHNICQAm A2oAAAAAFWi7OAkAFmhSPuIAQioBVQgBbUgJAHBoAAAAAHNICQAABhZo3RsNAAAMFWh6J7IAFmjd Gw0AABQVaPY9JQAWaN0bDQBtSAwEc0gMBCACDwAAAw8AAA8PAACADwAAhAAAAAAAAAAAAAAAAHsA AAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAWJAFJZgEAAABn ZN0bDQAAegAAa2R8CQAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEA AAjWMAAClP8kCSwiAAaQCQAAAAAAAAAAAAAAAAAAAAAABggZAAAAAAAAAAAAAAAAAAAAAAp0AADg ARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAA FTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/ NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA4APAACBDwAAjA8AAPcPAACEAAAAAAAAAAAAAAAAewAA AAAAAAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAABYkAUlmAQAAAGdk 3RsNAAB6AABrZNsJAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAA CNYwAAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAACnQAAOAB E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAV NgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP80 1gYAAQUDAAA01gYAAQoDbABh9gMAAAAD9w8AAPgPAAADEAAAaxAAAIQAAAAAAAAAAAAAAAB7AAAA AAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAFiQBSWYBAAAAZ2Td Gw0AAHoAAGtkOgoAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI 1jAAApT/JAksIgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET 1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2 ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTW BgABBQMAADTWBgABCgNsAGH2AwAAAAP/DwAAAhAAAAMQAAAEEAAAPBAAAD0QAAA+EAAAaBAAAGkQ AABrEAAAbBAAAHMQAAB2EAAAdxAAAHgQAACwEAAAsRAAALIQAADcEAAA3RAAAPDhzb6nzZrNvo+E eYRlVj9lMmUAGBVouzgJABZoDj3bADBKEABtSAwEc0gMBAAsAgiBA2odDAAABggBFWi7OAkAFmgO PdsAQioBVQgBbUgMBHBoAAAAAHNIDAQAHRVouzgJABZoDj3bAEIqAW1IDARwaAAAAABzSAwEJgNq AAAAABVouzgJABZoDj3bAEIqAVUIAW1IDARwaAAAAABzSAwEABQVaKNtbgAWaKNtbgBtSAwEc0gM BAAUFWijbW4AFmgOPdsAbUgMBHNIDAQAFBVoDj3bABZoDj3bAG1IDARzSAwEABgVaLs4CQAWaH8O NwAwShAAbUgMBHNIDAQALAIIgQNqmQoAAAYIARVouzgJABZofw43AEIqAVUIAW1IDARwaAAAAABz SAwEAB0VaLs4CQAWaH8ONwBCKgFtSAwEcGgAAAAAc0gMBCYDagAAAAAVaLs4CQAWaH8ONwBCKgFV CAFtSAwEcGgAAAAAc0gMBAAdFWijbW4AFmgOPdsAQioQbUgMBHBowMDAAHNIDAQdFWijbW4AFmij bW4AQioQbUgMBHBowMDAAHNIDAQAE2sQAABsEAAAdxAAAN4QAACEAAAAAAAAAAAAAAAAewAAAAAA AAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAABYkAUlmAQAAAGdk3RsN AAB6AABrZL4LAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYw AAKU/yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9Yw AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX 9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYA AQUDAAA01gYAAQoDbABh9gMAAAAD3RAAAN4QAADfEAAA4BAAAOYQAADnEAAA8hAAAPMQAAD3EAAA +BAAAPkQAAAyEQAAMxEAAFkRAABaEQAAXBEAAGIRAABjEQAAZBEAAJ4RAACfEQAAxhEAAMcRAADJ EQAAzxEAANARAADREQAA3REAAAESAAAGEgAA8OXa0srSxsK+p5Wnhae+wr6nlaeFp756b6eVWpUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKRVoo21uABZoo21uAEIqAU9KAgBRSgIAXkoC AG1ICQBwaAAAAABzSAkAFRVoo21uABZoSjKnAEIqEHBowMDAABUVaKNtbgAWaKNtbgBCKhBwaMDA wAAeFmijbW4AMEoQAE9KAgBRSgIAXkoCAG1ICQBzSAkAACMWaKNtbgBCKgFPSgIAUUoCAF5KAgBt SAkAcGgAAAAAc0gJACwDagAAAAAWaKNtbgBCKgFPSgIAUUoCAFUIAV5KAgBtSAkAcGgAAAAAc0gJ AAAGFmhKMqcAAAYWaKNtbgAABhZo3RsNAAAPFWhJX5UAFmhKMqcANQiBDxVoSV+VABZo3RsNADUI gRQVaA492wAWaN0bDQBtSAwEc0gMBAAUFWgOPdsAFmgOPdsAbUgMBHNIDAQAHRVouzgJABZoDj3b AEIqAW1IDARwaAAAAABzSAwEAB3eEAAA3xAAAOAQAADyEAAA8xAAAPgQAABbEQAAhAAAAAAAAAAA AAAAAIIAAAAAAAAAAAAAAACCAAAAAAAAAAAAAAAAggAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAB8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAABAAAA egAAa2RCDQAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAC lP8kCSwiAAaQCQAAAAAAAAAAAAAAAAAAAAAABggZAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YD AAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEF AwAANNYGAAEKA2wAYfYDAAAABlsRAABcEQAAYxEAAMgRAACEAAAAAAAAAAAAAAAAfgAAAAAAAAAA AAAAAH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAB6 AABrZKENAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU /yQJLCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMA ABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUD AAA01gYAAQoDbABh9gMAAAADyBEAAMkRAADQEQAAMhIAAIQAAAAAAAAAAAAAAAB+AAAAAAAAAAAA AAAAfgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAHoA AGtkAA4AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/ JAksIgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAA GPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMA ADTWBgABCgNsAGH2AwAAAAMGEgAABxIAAAgSAAAvEgAAMBIAADESAAAyEgAANBIAADcSAAA4EgAA QxIAAEQSAABOEgAATxIAAI0SAACOEgAAuRIAALoSAAC7EgAAvBIAAMQSAADHEgAAyBIAAOPMucyn nJiQiJCEfWlaaU1pRkJ9Qn0AAAAAAAAAAAAAAAAAAAAAAAAGFmhJX5UAAAwVaFBRhQAWaElflQAA GBVoUFGFABZoSV+VADBKEABtSAkAc0gJAAAdFWhQUYUAFmhJX5UAQioBbUgJAHBoAAAAAHNICQAm A2oAAAAAFWhQUYUAFmhJX5UAQioBVQgBbUgJAHBoAAAAAHNICQAADBVoSV+VABZoSV+VAAAGFmjd Gw0AAA8VaElflQAWaEoypwA1CIEPFWhJX5UAFmjdGw0ANQiBBhZoSjKnAAAUFWijbW4AFmhKMqcA bUgJAHNICQAAIxZoo21uAEIqAU9KAgBRSgIAXkoCAG1ICQBwaAAAAABzSAkAJBVojhbTABZoo21u ADBKEABPSgIAUUoCAF5KAgBtSAkAc0gJAAAsA2oAAAAAFmijbW4AQioBT0oCAFFKAgBVCAFeSgIA bUgJAHBoAAAAAHNICQAAOAIIgQNqXw4AAAYIARVojhbTABZoo21uAEIqAU9KAgBRSgIAVQgBXkoC AG1ICQBwaAAAAABzSAkAFjISAAAzEgAANBIAAEMSAABEEgAAThIAALsSAACEAAAAAAAAAAAAAAAA ggAAAAAAAAAAAAAAAIIAAAAAAAAAAAAAAACCAAAAAAAAAAAAAAAAfAAAAAAAAAAAAAAAAHwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAAEAAAB6AABr ZHgPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/yQJ LCIABpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2 AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA0 1gYAAQoDbABh9gMAAAAGuxIAALwSAADIEgAAQBMAAIQAAAAAAAAAAAAAAAB+AAAAAAAAAAAAAAAA fgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAHoAAGtk 1w8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/JAks IgAGkAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGPYD AAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTW BgABCgNsAGH2AwAAAAPIEgAAyRIAAAkTAAAKEwAACxMAAD0TAAA+EwAAQRMAAEkTAABMEwAATRMA AE4TAABaEwAAbBMAAI4TAACPEwAAkBMAAMITAADDEwAAxhMAAMcTAADKEwAAyxMAANYTAADXEwAA 2hMAAA8UAAAQFAAAERQAABkUAAAcFAAAJRQAACYUAABnFAAAaBQAAJYUAACXFAAAmRQAAPfz6Pff 9/PY89j389jzzfff9/PJwbnBtbHJraabrZuHeIdrh2AAAAAUFWi7OAkAFmi7OAkAbUgMBHNIDAQA GBVouzgJABZouzgJADBKEABtSAwEc0gMBAAdFWi7OAkAFmi7OAkAQioBbUgMBHBoAAAAAHNIDAQm A2oAAAAAFWi7OAkAFmi7OAkAQioBVQgBbUgJAHBoAAAAAHNICQAAFBVok1GrABZouzgJAG1IDARz SAwEAAwVaClxWwAWaLs4CQAABhZouzgJAAAGFmgpcVsAAAYWaN0bDQAADxVoSjKnABZoSjKnADUI gQ8VaEoypwAWaN0bDQA1CIEGFmhKMqcAABUCCIEDatoRAAAGCAEWaElflQBVCAEMFWhJX5UAFmhJ X5UAABAVaI4W0wAWaElflQAwShAAABUCCIEDajYQAAAGCAEWaElflQBVCAEGFmhJX5UAAA8DagAA AAAWaElflQBVCAEAJUATAABBEwAATRMAAMUTAACEAAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAAAH4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAB6AABrZHsR AAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/yQJLCIA BpAJAAAAAAAAAAAAAAAAAAAAAAAGCBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAA GtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYA AQoDbABh9gMAAAADxRMAAMYTAADHEwAA1hMAANcTAAAPFAAAEBQAABkUAAAbFAAAhAAAAAAAAAAA AAAAAIIAAAAAAAAAAAAAAACCAAAAAAAAAAAAAAAAggAAAAAAAAAAAAAAAIIAAAAAAAAAAAAAAAB9 AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAYAABYkAUlmAQAAAAkAABYkAUlmAQAAAGdkuzgJAAAEAABnZLs4CQAAAQAAAHoAAGtkHxMA ABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/JAksIgAG kAkAAAAAAAAAAAAAAAAAAAAAAAYIGQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa 1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgAB CgNsAGH2AwAAAAgbFAAAHBQAACUUAACYFAAAhAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB1AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAWJAFJZgEAAABnZLs4CQAAegAAa2R+EwAA FiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP9wCCwiAAbc CAAAAAAAAAAAAAAAAAAAAAAABrwZAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrW CAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEK A2wAYfYDAAAAA5gUAACZFAAAnxQAAKEUAACEAAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHsAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkuzgJAAB6AABrZN0TAAAW JAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/3AILCIABtwI AAAAAAAAAAAAAAAAAAAAAAAGvBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYI AAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoD bABh9gMAAAADmRQAAJ8UAACgFAAAohQAAKoUAACrFAAA6RQAAOoUAAAVFQAAFhUAABgVAAAgFQAA IRUAAF8VAABgFQAAixUAAIwVAACOFQAAlhUAAJcVAADQFQAA0RUAANIVAAD9FQAA/hUAAAAWAAAK FgAADRYAABIWAAAVFgAAGxYAAB4WAAApFgAALBYAAC0WAAA5FgAAOhYAAPXt4vXOv86yzuL1zr/O ss7i9Z6/h56ynuL1g/WD9YP1g/V8agAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjA2oAAAAA FmitLhYAQ0oUAE9KAwBRSgMAVQgBXkoDAGFKFAAMFWiTUasAFmi7OAkAAAYWaLs4CQAALAIIgQNq WRUAAAYIARVouzgJABZouzgJAEIqAVUIAW1IDARwaAAAAABzSAwEACYDagAAAAAVaLs4CQAWaLs4 CQBCKgFVCAFtSAwEcGgAAAAAc0gMBAAYFWi7OAkAFmi7OAkAMEoQAG1IDARzSAwEAB0VaLs4CQAW aLs4CQBCKgFtSAwEcGgAAAAAc0gMBCYDagAAAAAVaLs4CQAWaLs4CQBCKgFVCAFtSAkAcGgAAAAA c0gJAAAUFWi7OAkAFmi7OAkAbUgMBHNIDAQADhZouzgJAG1IDARzSAwEABQVaJNRqwAWaLs4CQBt SAwEc0gMBCShFAAAohQAAKoUAAAXFQAAhAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB7AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZLs4CQAAegAAa2Q8FAAAFiQB FyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP9wCCwiAAbcCAAA AAAAAAAAAAAAAAAAAAAABrwZAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWCAAA AP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wA YfYDAAAAAxcVAAAYFQAAIBUAAI0VAACEAAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHsAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkuzgJAAB6AABrZJsUAAAWJAEX JAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/3AILCIABtwIAAAA AAAAAAAAAAAAAAAAAAAGvBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA /wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh 9gMAAAADjRUAAI4VAACWFQAA/xUAAIQAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAewAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2S7OAkAAHoAAGtk+hQAABYkARck AUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/cAgsIgAG3AgAAAAA AAAAAAAAAAAAAAAAAAa8GQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/ AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2 AwAAAAP/FQAAABYAAAoWAAAMFgAAhAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB1AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAWJAFJZgEAAABnZLs4CQAAegAAa2SCFgAAFiQBFyQB SWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP9wCCwiAAbcCAAAAAAA AAAAAAAAAAAAAAAABrwZAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8A AAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYD AAAAAwwWAAANFgAAEhYAABQWAACEAAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAABYkAUlmAQAAAGdkuzgJAAB6AABrZOEWAAAWJAEXJAFJ ZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/3AILCIABtwIAAAAAAAA AAAAAAAAAAAAAAAGvBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAA AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMA AAADFBYAABUWAAAbFgAAHRYAAIQAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABgAAFiQBSWYBAAAACQAAFiQBSWYBAAAAZ2S7OAkAAHoAAGtkQBcAABYkARckAUlm AQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/cAgsIgAG3AgAAAAAAAAA AAAAAAAAAAAAAAa8GQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA /xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAA AAMdFgAAHhYAACkWAAArFgAAhAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAWJAFJZgEAAABnZLs4CQAAegAAa2SfFwAAFiQBFyQBSWYB AAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP9wCCwiAAbcCAAAAAAAAAAA AAAAAAAAAAAABrwZAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/ G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAA AysWAAAsFgAAORYAANUWAACEAAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAG0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AABYkATck ADgkAEgkAElmAQAAAGdkuzgJAAkAABYkAUlmAQAAAGdkuzgJAAB6AABrZP4XAAAWJAEXJAFJZgEA AAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/3AILCIABtwIAAAAAAAAAAAA AAAAAAAAAAAGvBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b 1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAAD OhYAAIwWAACNFgAAjhYAANIWAADTFgAA1BYAANUWAADWFgAA3RYAAOAWAADhFgAA8trItcjypKCZ oJUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAYWaN0bDQAADBVok1GrABZouzgJAAAGFmi7OAkAACAVaLs4CQAWaK0uFgBD ShQAT0oDAFFKAwBeSgMAYUoUAAAkFWiOFtMAFmitLhYAMEoQAENKFABPSgMAUUoDAF5KAwBhShQA ACMDagAAAAAWaK0uFgBDShQAT0oDAFFKAwBVCAFeSgMAYUoUAC8CCIEDal0YAAAGCAEVaI4W0wAW aK0uFgBDShQAT0oDAFFKAwBVCAFeSgMAYUoUABoWaK0uFgBDShQAT0oDAFFKAwBeSgMAYUoUAAvV FgAA1hYAAN0WAADfFgAAhAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAGAAAWJAFJZgEAAAAJAAAWJAFJZgEAAABnZLs4CQAAegAAa2TqGQAAFiQBFyQBSWYBAAAA ApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP9wCCwiAAbcCAAAAAAAAAAAAAAA AAAAAAAABrwZAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YI AAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA98W AADgFgAA4RYAAIQAAAAAAAAAAAAAAACCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAB6AABrZEkaAAAWJAEXJAFJZgEAAAAC lmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/3AILCIABtwIAAAAAAAAAAAAAAAA AAAAAAAGvBkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggA AAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAACLAAx kGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtAQAA RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAB8AAAA9AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AHIAcwBhAHMAZQBjAHUAcgBpAHQAeQAuAGMAbwBtAC8AcgBzAGEAbABhAGIAcwAvAHAAawBjAHMA LwBzAGMAaABlAG0AYQBzAC8AcABrAGMAcwAtADUAIwBwAGIAZQBzADIAAADgyep5+brOEYyCAKoA S6kLbgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgByAHMAYQBzAGUAYwB1AHIAaQB0AHkALgBjAG8A bQAvAHIAcwBhAGwAYQBiAHMALwBwAGsAYwBzAC8AcwBjAGgAZQBtAGEAcwAvAHAAawBjAHMALQA1 AAAABgAAAHAAYgBlAHMAMgAAADUBAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAHwAAAC8A AABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABt AGwAZQBuAGMAIwBrAHcALQBhAGUAcwAxADIAOAAtAGMAYgBjAAAA4Mnqefm6zhGMggCqAEupC0IA AABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABt AGwAZQBuAGMAAAAOAAAAawB3AC0AYQBlAHMAMQAyADgALQBjAGIAYwAAAD0BAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ 6nn5us4RjIIAqgBLqQsCAAAAHwAAADEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwBy AGcALwBUAFIALwB4AG0AbABlAG4AYwAtAGMAbwByAGUALwAjAHMAZQBjAC0AQQBsAGcAbwByAGkA dABoAG0AcwAAAODJ6nn5us4RjIIAqgBLqQtEAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAu AG8AcgBnAC8AVABSAC8AeABtAGwAZQBuAGMALQBjAG8AcgBlAC8AAAAPAAAAcwBlAGMALQBBAGwA ZwBvAHIAaQB0AGgAbQBzAAAAXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDkAk11gUBAgMI GSN2AAGQCSN2AQIIGTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA5AJNdYFAQIDCBld ABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJI3YBAggZOlYPAAKW bAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUBAgMIGV0AFiQBFyQBSWYBAAAAAZYAACF2 AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADgART2AQAAFTYBGPYD AAA11gUAAQOQCTXWBQECAwgZXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDkAk11gUBAgMI GSN2AAGQCSN2AQIIGTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA5AJNdYFAQIDCBld ABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJI3YBAggZOlYPAAKW bAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUBAgMIGV0AFiQBFyQBSWYBAAAAAZYAACF2 AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADgART2AQAAFTYBGPYD AAA11gUAAQOQCTXWBQECAwgZXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDkAk11gUBAgMI GSN2AAGQCSN2AQIIGTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA5AJNdYFAQIDCBld ABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJI3YBAggZOlYPAAKW bAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUBAgMIGV0AFiQBFyQBSWYBAAAAAZYAACF2 AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADgART2AQAAFTYBGPYD AAA11gUAAQOQCTXWBQECAwgZXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDkAk11gUBAgMI GSN2AAGQCSN2AQIIGTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA5AJNdYFAQIDCBkp AQAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAB8AAAAsAAAAaAB0AHQAcAA6AC8ALwB3AHcA dwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjACMAYQBlAHMAMgA1 ADYALQBjAGIAYwAAAODJ6nn5us4RjIIAqgBLqQtCAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcA MwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAACwAAAGEAZQBzADIANQA2 AC0AYwBiAGMAAABdABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJ I3YBAggZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUBAgMIGV0AFiQBFyQB SWYBAAAAAZYAACF2AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADg ART2AQAAFTYBGPYDAAA11gUAAQOQCTXWBQECAwgZXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYF AAEDkAk11gUBAgMIGSN2AAGQCSN2AQIIGTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQAB A5AJNdYFAQIDCBldABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJ I3YBAggZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUBAgMIGV0AFiQBFyQB SWYBAAAAAZYAACF2AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADg ART2AQAAFTYBGPYDAAA11gUAAQOQCTXWBQECAwgZJQEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEup CwIAAAAfAAAAKwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAwADEA LwAwADQALwB4AG0AbABlAG4AYwAjAGsAdwAtAGEAZQBzADIANQA2AAAA4Mnqefm6zhGMggCqAEup C0IAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8A eABtAGwAZQBuAGMAAAAKAAAAawB3AC0AYQBlAHMAMgA1ADYAAABdABYkARckAUlmAQAAAAGWAAAh dgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJI3YBAggZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2 AwAANdYFAAEDkAk11gUBAgMIGSUBAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAHwAAACsA AABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABt AGwAZQBuAGMAIwBrAHcALQBhAGUAcwA1ADEAMgAAAODJ6nn5us4RjIIAqgBLqQtCAAAAaAB0AHQA cAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBj AAAACgAAAGsAdwAtAGEAZQBzADUAMQAyAAAAXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAED kAk11gUBAgMIGSN2AAGQCSN2AQIIGTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA5AJ NdYFAQIDCBldABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXWBQECAwgZI3YAAZAJI3YB AggZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUBAgMIGV0AFiQBFyQBSWYB AAAAAZYAACF2AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADgART2 AQAAFTYBGPYDAAA11gUAAQOQCTXWBQECAwgZGQEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAAfAAAAKAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAwADEALwAw ADQALwB4AG0AbABlAG4AYwAjAHMAaABhADUAMQAyAAAA4Mnqefm6zhGMggCqAEupC0IAAABoAHQA dABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBu AGMAAAAHAAAAcwBoAGEANQAxADIAAABdABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQOQCTXW BQECAwgZI3YAAZAJI3YBAggZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDkAk11gUB AgMIGV0AFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6 Vg8AApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQOQCTXWBQECAwgZRQEAAEQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnq efm6zhGMggCqAEupCwIAAAAfAAAAMwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIA ZwAvADIAMAAwADEALwAwADQALwB4AG0AbABkAHMAaQBnAC0AbQBvAHIAZQAjAGgAbQBhAGMALQBz AGgAYQAyADUANgAAAODJ6nn5us4RjIIAqgBLqQtOAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcA MwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGQAcwBpAGcALQBtAG8AcgBlAAAADAAA AGgAbQBhAGMALQBzAGgAYQAyADUANgAAAF0AFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA5AJ NdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQOQCTXW BQECAwgZRQEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAfAAAAMwAAAGgAdAB0AHAAOgAv AC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAwADEALwAwADQALwB4AG0AbABkAHMAaQBnAC0A bQBvAHIAZQAjAGgAbQBhAGMALQBzAGgAYQA1ADEAMgAAAODJ6nn5us4RjIIAqgBLqQtOAAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGQA cwBpAGcALQBtAG8AcgBlAAAADAAAAGgAbQBhAGMALQBzAGgAYQA1ADEAMgAAAF0AFiQBFyQBSWYB AAAAAZYAACF2AAJoATXWBQABA5AJNdYFAQIDCBkjdgABkAkjdgECCBk6Vg8AApZsAAp0AADgART2 AQAAFTYBGPYDAAA11gUAAQOQCTXWBQECAwgZXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAED 3Ag11gUBAgO8GSN2AAHcCCN2AQK8GTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA9wI NdYFAQIDvBldABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQPcCDXWBQECA7wZI3YAAdwII3YB ArwZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAED3Ag11gUBAgO8GV0AFiQBFyQBSWYB AAAAAZYAACF2AAJoATXWBQABA9wINdYFAQIDvBkjdgAB3AgjdgECvBk6Vg8AApZsAAp0AADgART2 AQAAFTYBGPYDAAA11gUAAQPcCDXWBQECA7wZXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAED 3Ag11gUBAgO8GSN2AAHcCCN2AQK8GTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA9wI NdYFAQIDvBldABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQPcCDXWBQECA7wZI3YAAdwII3YB ArwZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAED3Ag11gUBAgO8GSkBAABEAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANDJ6nn5us4RjIIAqgBLqQsCAAAAHwAAACwAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4A bwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAIwBhAGUAcwAyADUANgAtAGMAYgBj AAAA4Mnqefm6zhGMggCqAEupC0IAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcA LwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAALAAAAYQBlAHMAMgA1ADYALQBjAGIAYwAA AF0AFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA9wINdYFAQIDvBkjdgAB3AgjdgECvBk6Vg8A ApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQPcCDXWBQECA7wZXQAWJAEXJAFJZgEAAAABlgAA IXYAAmgBNdYFAAED3Ag11gUBAgO8GSN2AAHcCCN2AQK8GTpWDwAClmwACnQAAOABFPYBAAAVNgEY 9gMAADXWBQABA9wINdYFAQIDvBldABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQPcCDXWBQEC A7wZI3YAAdwII3YBArwZOlYPAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAED3Ag11gUBAgO8 GV0AFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA9wINdYFAQIDvBkjdgAB3AgjdgECvBk6Vg8A ApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQPcCDXWBQECA7wZXQAWJAEXJAFJZgEAAAABlgAA IXYAAmgBNdYFAAED3Ag11gUBAgO8GSN2AAHcCCN2AQK8GTpWDwAClmwACnQAAOABFPYBAAAVNgEY 9gMAADXWBQABA9wINdYFAQIDvBmNAQAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAB8AAABF AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHIAcwBhAC4AYwBvAG0ALwByAHMAYQBsAGEAYgBzAC8A bwB0AHAAcwAvAHMAYwBoAGUAbQBhAHMALwAyADAAMAA1AC8AMAA5AC8AbwB0AHAAcwAtAHcAcwB0 ACMAUwBlAGMAdQByAEkARAAtAEEARQBTAAAA4Mnqefm6zhGMggCqAEupC3IAAABoAHQAdABwADoA LwAvAHcAdwB3AC4AcgBzAGEALgBjAG8AbQAvAHIAcwBhAGwAYQBiAHMALwBvAHQAcABzAC8AcwBj AGgAZQBtAGEAcwAvADIAMAAwADUALwAwADkALwBvAHQAcABzAC0AdwBzAHQAAAAMAAAAUwBlAGMA dQByAEkARAAtAEEARQBTAAAAXQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAED3Ag11gUBAgO8 GSN2AAHcCCN2AQK8GTpWDwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA9wINdYFAQIDvBld ABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQPcCDXWBQECA7wZI3YAAdwII3YBArwZOlYPAAKW bAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAED3Ag11gUBAgO8GQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgIRABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAQPH/AgBAAAwAAAAAAAAAAAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgA bUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAARABBQPL/oQBEAAwBAAAAAAAAAAAWAEQAZQBm AGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaUDz/7MAUgAMAQAA AAAAAAAADABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUD AABh9gMAAAIACwAAACgAa0D0/8EAKAAAAQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAA AABqAJpAswDzAGoADAQAAN0bDQAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAAA2AFVA ogABATYADAQAAFI+4gAAAAkASAB5AHAAZQByAGwAaQBuAGsAAAAMAD4qAUIqAnBoAAD/AAAAAADh DgAAFQAAdgAAFgD/////AAAAAAEAAAAdAAAAKAAAADYAAAA3AAAAUAAAAFEAAACHAAAAiAAAAEgB AABJAQAA1AEAAEMCAABEAgAAhgIAAIcCAADeAgAA3wIAADMDAAA0AwAApwMAAKgDAAC3AwAAuwMA ALwDAADMAwAAzgMAAM8DAADfAwAA4QMAAOIDAADxAwAA8wMAAPQDAAADBAAABQQAAAYEAAAVBAAA FwQAABgEAAAkBAAAJgQAACcEAAAzBAAApgQAAKcEAACyBAAAHwUAACAFAAArBQAAmAUAAJkFAACk BQAADQYAAA4GAAAWBgAAfQYAAH4GAACNBgAAAgcAAAMHAAAPBwAAgAcAAIEHAACMBwAA9wcAAPgH AAADCAAAawgAAGwIAAB3CAAA3ggAAN8IAADgCAAA8ggAAPMIAAD4CAAAWwkAAFwJAABjCQAAyAkA AMkJAADQCQAAMgoAADMKAAA0CgAAQwoAAEQKAABOCgAAuwoAALwKAADICgAAQAsAAEELAABNCwAA xQsAAMYLAADHCwAA1gsAANcLAAAPDAAAEAwAABkMAAAbDAAAHAwAACUMAACYDAAAmQwAAJ8MAACh DAAAogwAAKoMAAAXDQAAGA0AACANAACNDQAAjg0AAJYNAAD/DQAAAA4AAAoOAAAMDgAADQ4AABIO AAAUDgAAFQ4AABsOAAAdDgAAHg4AACkOAAArDgAALA4AADkOAADVDgAA1g4AAN0OAADfDgAA4A4A AOMOAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAA AAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAA AAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAA gAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAA AIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIAB AADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZ AAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAA AAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAA gAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQA AAAAIACpQAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAA MAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAAAAAADcAAABQAAAAUQAAAIcAAACIAAAASAEAAEkBAADUAQAA 3gIAAN8CAAAzAwAANAMAAKcDAACoAwAAtwMAALsDAAC8AwAAzAMAAN8DAADhAwAA4gMAAPEDAADz AwAA9AMAAAMEAAAFBAAABgQAABUEAAAXBAAAGAQAACQEAAAmBAAAJwQAADMEAACmBAAApwQAALIE AAAfBQAAIAUAACsFAACYBQAAmQUAAKQFAAANBgAADgYAABYGAAB9BgAAfgYAAI0GAAACBwAAAwcA AA8HAACABwAAgQcAAIwHAAD3BwAA+AcAAAMIAABrCAAAbAgAAHcIAADeCAAA3wgAAOAIAADyCAAA 8wgAAPgIAABbCQAAXAkAAGMJAADICQAAyQkAANAJAAAyCgAAMwoAADQKAABDCgAARAoAAE4KAAC7 CgAAvAoAAMgKAABACwAAQQsAAE0LAADFCwAAxgsAABAMAAAZDAAAGwwAABwMAAAlDAAAmAwAAJkM AACfDAAAoQwAAKIMAACqDAAAFw0AABgNAAAgDQAAjQ0AAI4NAACWDQAA/w0AAAAOAAAKDgAADA4A AA0OAAASDgAAFA4AABUOAAAbDgAAHQ4AAB4OAAApDgAAKw4AACwOAAA5DgAA1Q4AANYOAADdDgAA 3w4AAOAOAADjDgAA24oAMAAwAAAAAAAAAQAAAC8AAAABAAAAfOHBB9uKADAAMAAAAAAAAAEAAAAe AAAAAAAAAAAAAAfbigAwAjAAAAAAAAABAAAAMwAAAAMAAAAcQ08H24oAMAIwAAAAAAAAAQAAADIA AAAAAAAAAAAAB9mKADACMAAAAAAAAAIAAAAwAAAAAAAAAAAAgAHZigAwADAAAAAAAAABAAAAHQAA AAAAAAAAAIAB2YoAMAEwAAAAAAAAAgAAACwAAAAAAAAAAACAAdmKADABMAAAAAAAAAIAAAAsAAAA AAAAAAAAgAHbigAwATAAAAAAAAACAAAALAAAAAAAAAAAAIAH24oAMAEwAAAAAAAAAgAAACwAAAAA AAAAAACAB9uKADAAMAAAAAAAAAEAAAAdAAAAAAAAAAAAAAfZigAwADAAAAAAAAABAAAAHgAAAAAA AAAAAAAB24oAMAAwAAAAAAAAAQAAAB4AAAAAAAAAAAAAAduKADAAMAAAAAAAAAEAAAAeAAAAAAAA AAAAAAfbigAwADAAAAAAAAABAAAAHQABAAAAAAAAACAH24oAMAAwAAAAAAAAAgAAABsAAQAAAAAA AAAgB5ZBAADAMQAAwQEAAOgBAADpAQEAAAQAAAAAIAfbygAwADAAAAAAAAACAAAAAQAAAAEAAAC4 Lk4H28oAMAIwAAAAAAAAAgAAAAEAAAADAAAA8C5OB9vKADAAMAAAAAAAAAIAAAABAAEAAAAAAAAA TgeWQQAAwDEAAMEBAADoAQAA6QEAABoCAAABAKAH28oAMAQwAAAAAAAAAgAAAAEAAAAFAAAAKC9O B9vKADACMAAAAAAAAAIAAAABAAEAAAAAAAAATgfbygAwADAAAAAAAAABAAAAAAAAAAAAAABUB6AH 28oAMAYwAAAAAAAAAgAAAAEAAAAHAAAAYC9OB9vKADAEMAAAAAAAAAIAAAABAAEAAAAAAAAATgfb ygAwADAAAAAAAAABAAAAAAAAAAAAAABUB6AH28oAMAgwAAAAAAAAAgAAAAEAAAAJAAAAwGr2B9vK ADAGMAAAAAAAAAIAAAABAAEAAAAAAAAAIAfZygAwADAAAAAAAAABAAAAAAABAAAEAAAAAKAB28oA MAowAAAAAAAAAgAAAAEAAQAAAAAAAACgB9vKADAIMAAAAAAAAAIAAAABAAEAAAAAAAAAIAcAQAAA ATAAAAAAAAAAAAAAVAcBAAAEAAAAAKAB28oAMAwwAAAAAAAAAgAAAAEAAQAAAAAAAACgB9nKADAK MAAAAAAAAAIAAAABAAEAAAAAAAAAIAEBQAAAADAAAAAAAABUB6sHAAABAABEAAAAAKAB28oAMA4w AAAAAAAAAgAAAAEAAQAAAAAAAACgB9nKADAMMAAAAAAAAAIAAAABAAEAAAAAAAAAIAHZygAwADAA AAAAAAABAAAAAAABAAAEAAAAAKAB28oAMBAwAAAAAAAAAgAAAAEAAQAAAAAAAACgB9nKADAOMAAA AAAAAAIAAAABAAEAAAAAAAAAIAHZygAwADAAAAAAAAABAAAAAAABAAAEAAAAAKAB28oAMBIwAAAA AAAAAgAAAAEAAQAAAAAAAACgB9nKADAQMAAAAAAAAAIAAAABAAEAAAAAAAAAIAHZygAwADAAAAAA AAABAAAAAAABAAAEAAAAAKAB28oAMBQwAAAAAAAAAgAAAAEAAQAAAAAAAACgB9nKADASMAAAAAAA AAIAAAABAAEAAAAAAAAAIAHZygAwADAAAAAAAAABAAAAAAABAAAEAAAAAKAB28oAMBYwAAAAAAAA AgAAAAEAAQAAAAAAAAAgB9nKADAUMAAAAAAAAAIAAAABAAEAAAAAAAAAIAHZygAwADAAAAAAAAAB AAAAAAABAAAEAAAAAKAB2YoAMDMwAAAAAAAAAgAAAAIAAQAAAAAAAAAgAdmKADAzMAAAAAAAAAIA AAACAAEAAAAAAAAAIAGYAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB2YoAMDYwAAAAAAAAAgAA AAIAAQAAAAAAAAAgAdmKADA2MAAAAAAAAAIAAAACAAEAAAAAAAAAIAGYAAAAADAAAAAAAAAAgAAA AIABAAAEAAAAACAB24oAMDkwAAAAAAAAAgAAAAIAAQAAAAAAAAAgB9uKADA5MAAAAAAAAAIAAAAC AAEAAAAAAAAAIAeYAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB28oAMDwwAAAAAAAAAgAAAAIA AQAAAAAAAAAgB9uKADA8MAAAAAAAAAIAAAACAAEAAAAAAAAAIAeYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAACAF24oAMD8wAAAAAAAAAQAAAAcAAABAAAAAxLVOB9mKADA/MAAAAAAAAAEAAAAGAAAA AAAAAAAAAAHZigAwPzAAAAAAAAACAAAABAAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAQAA AAAAAAAgAdmKADA/MAAAAAAAAAIAAAACAAEAAAAAAAAAIAGYAAAAADAAAAAAAAAAgAAAAIABAAAE AAAAACAB2YoAMEUwAAAAAAAAAgAAAAIAAQAAAAAAAAAgAdmKADBFMAAAAAAAAAIAAAACAAEAAAAA AAAAIAGYAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB2YoAMEgwAAAAAAAAAgAAAAIAAQAAAAAA AAAgAduKADBIMAAAAAAAAAIAAAACAAEAAAAAAAAAIAeYAAAAADAAAAAAAAAAgAAAAIABAAAEAAAA ACAB2YoAMEswAAAAAAAAAgAAAAIAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAEIAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2YoAME4wAAAAAAAAAgAAAAIAAQAAAAAAAACg AdmKADBOMAAAAAAAAAIAAAACAAEAAAAAAAAAoAGYAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB 2YoAMFEwAAAAAAAAAgAAAAIAAQAAAAAAAACgAdmKADBRMAAAAAAAAAIAAAACAAEAAAAAAAAAoAGY AAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB2YoAMFQwAAAAAAAAAgAAAAIAAQAAAAAAAACgAduK ADBUMAAAAAAAAAIAAAACAAEAAAAAAAAAoAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAACAFCgAA AAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAB9vKADAAMAAAAAAAAAIAAAABAAAAAQAAAEgyTgfbigAw WTAAAAAAAAACAAAAIwABAAAAAAAAAKAH2coAMAEwAAAAAAAAAgAAAAEAAQAABAAAAAAgAdnKADAC MAAAAAAAAAIAAAABAAEAAAAAAAAAIAHZygAwATAAAAAAAAACAAAAAQABAAAAAAAAAKABYUCYAAIw AAAAAKAAAgAAAAAAAACMHlQAAAAgBdvKADAEMAAAAAAAAAIAAAABAAAABQAAALgyTgfbygAwCjAA AAAAAAACAAAAAQABAAAAAAAAACAHAkAAAAAwCAAAABMAAAAAZhIAAQAAAAAAAAAgBdvKADAGMAAA AAAAAAIAAAABAAAABwAAAPAyTgfbygAwDDAAAAAAAAACAAAAAQABAAAAAAAAACAHAkAAAAAwAAAA AAAAAAAAAAAAAQAABAAAAAAgAdvKADAIMAAAAAAAAAIAAAABAAAACQAAAEyaRgfbygAwDjAAAAAA AAACAAAAAQABAAAAAAAAACAHAEAAAAAwAAAAAAAAAAAAAAAAAQAABAAAAAAgAdnKADAKMAAAAAAA AAIAAAABAAEAAAAAAAAAIAHZygAwEDAAAAAAAAACAAAAAQABAAAAAAAAACABAEAAAAAwAAAAAAAA AAAAAAAAAQAABAAAAAAgAdvKADAMMAAAAAAAAAIAAAABAAAADQAAADyLRgfbygAwEDAAAAAAAAAC AAAAAQABAAAAAAAAAPYHAEAAAAAwAAAAAAAAAAAAAAAAAAAAAP//AAAgBdvKADAOMAAAAAAAAAIA AAABAAAADwAAABSbRgfbygAwEzAAAAAAAAACAAAAAQABAAAAAAAAAPYHAEAAAAAwAAAAAAAAAAAA AAAAAAAAAAAAAAAgBdvKADAQMAAAAAAAAAIAAAABAAAAEQAAAEybRgfbygAwFjAAAAAAAAACAAAA AQABAAAAAAAAAPYHAEAAAAIwAAAJAAAArE5OB9mKADAAMAAAAAAgBdvKADASMAAAAAAAAAIAAAAB AAAAEwAAAHwCRgfZygAwGTAAAAAAAAACAAAAAQABAAAAAAAAAKABAEAAAAIwAAAAAAAAAAABAAAA AQAABAAAAAAgAdnKADAUMAAAAAAAAAIAAAABAAEAAAAAAAAAIAHbygAwHDAAAAAAAAACAAAAAQAB AAAAAAAAAKAHAEAAAAAwAADfCwAA4AsAAPgpjA8BAAAAAAAgBdvKADAWMAAAAAAAAAIAAAABAAAA FwAAABicRgfbygAwHzAAAAAAAAACAAAAAQABAAAAAAAAAPYHAEAAAAAwAAAAAAAAAAAAAPsKAAAH CwAAAAQgBQoAAAAAMAAAAAAAAAAAAAAAACEwSAAAAAAAAAcABgAAcQsAAKcMAAB9DgAA/w8AAN0Q AAAGEgAAyBIAAJkUAAA6FgAA4RYAAAwAAAAPAAAAGAAAAB0AAAAhAAAAIwAAACcAAAAqAAAALwAA ADgAAAAABgAAuwsAAM4LAADhCwAA8wsAAAUMAAAXDAAAJgwAAKYMAAAfDQAAmA0AAA0OAAB9DgAA Ag8AAIAPAAD3DwAAaxAAAN4QAABbEQAAyBEAADISAAC7EgAAQBMAAMUTAAAbFAAAmBQAAKEUAAAX FQAAjRUAAP8VAAAMFgAAFBYAAB0WAAArFgAA1RYAAN8WAADhFgAADQAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGQAAABoAAAAbAAAAHAAAAB4AAAAfAAAAIAAAACIAAAAkAAAAJQAA ACYAAAAoAAAAKQAAACsAAAAsAAAALQAAAC4AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA NwAAADkAAAA6AAAAAAYAAOEWAAAOAAAASQEAAJUBAADSAQAA1AEAABICAABBAgAANAMAAHQDAACl AwAAMwQAAHUEAACkBAAAsgQAAPEEAAAdBQAAKwUAAGoFAACWBQAApAUAAN8FAAALBgAAFgYAAFIG AAB7BgAAjQYAANAGAAAABwAADwcAAFAHAAB+BwAAjAcAAMoHAAD1BwAAAwgAAD0IAABoCAAAdwgA ALEIAADcCAAA+AgAADIJAABZCQAAYwkAAJ4JAADGCQAA0AkAAAcKAAAvCgAATgoAAI0KAAC5CgAA yAoAAAoLAAA9CwAATQsAAI8LAADCCwAAJQwAAGcMAACWDAAAqgwAAOkMAAAVDQAAIA0AAF8NAACL DQAAlg0AANENAAD9DQAAOQ4AAI0OAADSDgAA4Q4AABNYFP8VgBNYFP8VgBNYFP8VgBNYFP8VjBNY FP8VjBNYFP8VjBNYFP8VhBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VhBNYFP8VhBNYFP8V jBNYFP8VjBNYFP8VgBNYFP8VjBNYFP8VgBNYFP8VgBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VhBNY FP8VgAAAAAABAAAABQAAADIAAAA1AAAAZgAAAGoAAACIAAAAjAAAAPAAAAD0AAAABgMAAAoDAAAd AwAAIwMAAPALAAD0CwAA4w4AAAcAHAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAA KAAAADYAAABEAgAARwIAAOMOAAAHAAQABwAzAAcAAAAAAAEAAAAcAAAAHQAAACgAAAA1AAAANgAA AFAAAACoAwAAtwMAALwDAAAzBAAApwQAALIEAAAgBQAAKwUAAJkFAACkBQAADgYAABYGAAB+BgAA jQYAAAMHAAAPBwAAgQcAAIwHAAD4BwAAAwgAAGwIAAB3CAAA4AgAAPgIAABcCQAAYwkAAMkJAADQ CQAANAoAAE4KAAC8CgAAyAoAAEELAABNCwAAEQwAACUMAACaDAAAqgwAABkNAAAgDQAAjw0AAJYN AAABDgAAOQ4AANcOAADgDgAA4w4AAAcABQAHAAUABAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAAAAAAAyAAAANQAAAOMOAAAHAAQABwAXAAAABAAAAAgAAADlAAAAAAAA ABYAAAC7OAkA3RsNAK0uFgD2PSUA5SsnAJ5pKQB/DjcAuj09ADRTRAApcVsAo21uAJJWcAAXbnoA J2N9AB9GggBQUYUASV+VABpqmABKMqcAJ0+7AEZ72gAOPdsAUj7iAAAAAACoAwAAtwMAALsDAAC8 AwAAzAMAAM4DAADPAwAA3wMAAOEDAADiAwAA8QMAAPMDAAD0AwAAAwQAAAUEAAAGBAAAFQQAABcE AAAYBAAAJAQAACYEAAAnBAAAMwQAAKYEAACnBAAAsgQAAB8FAAAgBQAAKwUAAJgFAACZBQAApAUA AA0GAAAOBgAAFgYAAH0GAAB+BgAAjQYAAAIHAAADBwAADwcAAIAHAACBBwAAjAcAAPcHAAD4BwAA AwgAAGsIAABsCAAAdwgAAN4IAADfCAAA8wgAAPgIAABbCQAAXAkAAGMJAADICQAAyQkAANAJAAAy CgAAMwoAAEQKAABOCgAAuwoAALwKAADICgAAQAsAAEELAABNCwAAxQsAAMYLAAAQDAAAGQwAABsM AAAcDAAAJQwAAJgMAACZDAAAnwwAAKEMAACiDAAAqgwAABcNAAAYDQAAIA0AAI0NAACODQAAlg0A AP8NAAAADgAACg4AAAwOAAANDgAAEg4AABQOAAAVDgAAGw4AAB0OAAAeDgAAKQ4AACsOAAAsDgAA OQ4AANUOAADWDgAA3Q4AAN8OAADgDgAA4w4AAAAAAAAIAAAAAgEAAAIBAACeAQAAAgEAAAIBAACe AQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIB AACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEA AAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAA AgEAAAIBAACWAQAACAAAAAIBAAACAQAAngEAAAIBAAACAQAAngEAAAIBAAACAQAAlgEAAAgAAAAC AQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJYBAAAIAAAAAgEAAAIBAACeAQAAAgEAAAIB AACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEA AAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAA AgEAAAIBAACWAQAA/0ADgAEANQAAADUAAAD4KYwPAQABADUAAAAAAAEANQAAAHAILCICEAAAAAAA AADhDgAAUAEAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAA AAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABAAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgA AAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIB BwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgIC AgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/NZABAAACBwMJAgIFAgQEh3oA IAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAIgAEADEIiBgA8NAC AABoAQAAAAA3i7pmjY26ZgAAAAAbAC0CAAA4AgAAqQwAAAEABwAAAAQAAxAbAAAAOAIAAKkMAAAB AAcAAAAbAAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0ALQAgYES NAAAEAAZAGQAAAAZAAAA2g4AANoOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACDKDUQDwEAAIAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABIWAAAAAAJ8P8PAQABPwAA5AQAAP///3////9/////f////3////9/ ////f////3/dGw0AAAAAADIAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAbAFUAUgBJAHMAIABm AG8AcgAgAEEAbABnAG8AcgBpAHQAaABtAHMAIABpAG4AIABQAFMASwBDAAAAAAAAAAQAbQBwAGUA aQAEAG0AcABlAGkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAIQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAAC8AAAABAAAAMgAAAAFAAAA2AAAAAYAAADk AAAABwAAAPAAAAAIAAAABAEAAAkAAAAUAQAAEgAAACABAAAKAAAAQAEAAAwAAABMAQAADQAAAFgB AAAOAAAAZAEAAA8AAABsAQAAEAAAAHQBAAATAAAAfAEAAAIAAADkBAAAHgAAABwAAABVUklzIGZv ciBBbGdvcml0aG1zIGluIFBTS0MAHgAAAAQAAAAAAAAAHgAAAAgAAABtcGVpAAAAAB4AAAAEAAAA AAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFsLmRvdAAAHgAAAAgAAABtcGVpAAAAAB4AAAAE AAAAMjcAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABO389NAAAAQAAAAACC mZn3EMgBQAAAAAAWPI1FEcgBAwAAAAEAAAADAAAAOAIAAAMAAACpDAAAAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3V nC4bEJOXCAArLPmuVAEAABABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACIAAAABgAAAJAAAAAR AAAAmAAAABcAAACgAAAACwAAAKgAAAAQAAAAsAAAABMAAAC4AAAAFgAAAMAAAAANAAAAyAAAAAwA AADwAAAAAgAAAOQEAAAeAAAAEAAAAFZlcmlTaWduIEluYwAAAAADAAAAGwAAAAMAAAAHAAAAAwAA ANoOAAADAAAACBkLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAcAAAA VVJJcyBmb3IgQWxnb3JpdGhtcyBpbiBQU0tDAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAA AAAAwA0AAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAAAEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5L UwACAAAA5AQAAEEAAAB4DQAAkAAAAAMAAAAvAGAAAwAAAEUAAAADAAAAAAAAAAMAAAAFAAAAHwAA ADkAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcgBzAGEALgBjAG8AbQAvAHIAcwBhAGwAYQBiAHMA LwBvAHQAcABzAC8AcwBjAGgAZQBtAGEAcwAvADIAMAAwADUALwAwADkALwBvAHQAcABzAC0AdwBz AHQAAAAAAB8AAAAMAAAAUwBlAGMAdQByAEkARAAtAEEARQBTAAAAAwAAAGAAOwADAAAAQgAAAAMA AAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAv ADIAMAAwADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAAAAsAAABhAGUAcwAyADUANgAtAGMA YgBjAAAAAAADAAAAbAA8AAMAAAA/AAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAA AAAfAAAACwAAAGEAZQBzADEAOQAyAC0AYwBiAGMAAAAAAAMAAABnADYAAwAAADwAAAADAAAAAAAA AAMAAAAFAAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAA MAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAALAAAAYQBlAHMAMQAyADgALQBjAGIAYwAA AAAAAwAAAA0AFwADAAAAOQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8A dwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAwADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAA AA4AAAB0AHIAaQBwAGwAZQBkAGUAcwAtAGMAYgBjAAAAAwAAABQAWwADAAAANgAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAJwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAw ADEALwAwADQALwB4AG0AbABkAHMAaQBnAC0AbQBvAHIAZQAAAAAAHwAAAAwAAABoAG0AYQBjAC0A cwBoAGEANQAxADIAAAADAAAAEwBfAAMAAAAzAAAAAwAAAAAAAAADAAAABQAAAB8AAAAnAAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGQA cwBpAGcALQBtAG8AcgBlAAAAAAAfAAAADAAAAGgAbQBhAGMALQBzAGgAYQAyADUANgAAAAMAAABU AEwAAwAAADAAAAADAAAAAAAAAAMAAAAFAAAAHwAAACIAAABoAHQAdABwADoALwAvAHcAdwB3AC4A dwAzAC4AbwByAGcALwAyADAAMAAwAC8AMAA5AC8AeABtAGwAZABzAGkAZwAAAB8AAAAKAAAAaABt AGEAYwAtAHMAaABhADEAAAADAAAAKwA1AAMAAAAtAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBs AGUAbgBjAAAAAAAfAAAABwAAAHMAaABhADUAMQAyAAAAAAADAAAALwA2AAMAAAAqAAAAAwAAAAAA AAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAw ADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAAAAAfAAAABwAAAHMAaABhADIANQA2AAAAAAADAAAA CgAJAAMAAAAnAAAAAwAAAAAAAAADAAAABQAAAB8AAAAiAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AHcAMwAuAG8AcgBnAC8AMgAwADAAMAAvADAAOQAvAHgAbQBsAGQAcwBpAGcAAAAfAAAABQAAAHMA aABhADEAAAAAAAMAAAAeAA4AAwAAACQAAAADAAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQAdABw ADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMA AAAAAB8AAAAKAAAAawB3AC0AYQBlAHMANQAxADIAAAADAAAAGQAKAAMAAAAhAAAAAwAAAAAAAAAD AAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAA MQAvADAANAAvAHgAbQBsAGUAbgBjAAAAAAAfAAAACgAAAGsAdwAtAGEAZQBzADIANQA2AAAAAwAA ABoADQADAAAAHgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgB3ADMALgBvAHIAZwAvADIAMAAwADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAAAAoAAABr AHcALQBhAGUAcwAxADIAOAAAAAMAAABMAEsAAwAAABsAAAADAAAAAAAAAAMAAAAFAAAAHwAAACEA AABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABt AGwAZQBuAGMAAAAAAB8AAAANAAAAawB3AC0AdAByAGkAcABsAGUAZABlAHMAAAAAAAMAAABqAG4A AwAAABgAAAADAAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAz AC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAAPAAAAcgBzAGEA LQBvAGEAZQBwAC0AbQBnAGYAMQBwAAAAAAADAAAAKgBbAAMAAAAVAAAAAwAAAAAAAAADAAAABQAA AB8AAAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAA NAAvAHgAbQBsAGUAbgBjAAAAAAAfAAAACAAAAHIAcwBhAC0AMQBfADUAAAADAAAAYAA7AAMAAAAS AAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8A cgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAAAAAfAAAACwAAAGEAZQBzADIANQA2 AC0AYwBiAGMAAAAAAAMAAABsADwAAwAAAA8AAAADAAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQA dABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBu AGMAAAAAAB8AAAALAAAAYQBlAHMAMQA5ADIALQBjAGIAYwAAAAAAAwAAAGcANgADAAAADAAAAAMA AAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAv ADIAMAAwADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAAAAsAAABhAGUAcwAxADIAOAAtAGMA YgBjAAAAAAADAAAADQAXAAMAAAAJAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAA AAAfAAAADgAAAHQAcgBpAHAAbABlAGQAZQBzAC0AYwBiAGMAAAADAAAANwA5AAMAAAAGAAAAAwAA AAAAAAADAAAABQAAAB8AAAAiAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8A VABSAC8AeABtAGwAZQBuAGMALQBjAG8AcgBlAC8AAAAfAAAADwAAAHMAZQBjAC0AQQBsAGcAbwBy AGkAdABoAG0AcwAAAAAAAwAAAEEAQgADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgA dAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAwADEALwAwADQALwB4AG0AbABl AG4AYwAAAAAAHwAAAA4AAABrAHcALQBhAGUAcwAxADIAOAAtAGMAYgBjAAAAAwAAAD8AfwADAAAA AAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAANwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgByAHMAYQBz AGUAYwB1AHIAaQB0AHkALgBjAG8AbQAvAHIAcwBhAGwAYQBiAHMALwBwAGsAYwBzAC8AcwBjAGgA ZQBtAGEAcwAvAHAAawBjAHMALQA1AAAAAAAfAAAABgAAAHAAYgBlAHMAMgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA ADsAAAD+////PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA SQAAAP7///9LAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABX AAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAA/v///2UA AABmAAAAZwAAAGgAAABpAAAAagAAAGsAAAD+////bQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAA AP7////9////dgAAAP7////+/////v////////////////////////////////////////9SAG8A bwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAADAAZuqRRHIAXgA AACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAPAAAAKgaAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABKAAAAvTIAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBl AG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudgAAAAAAAAUAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAA AAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABsAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8BAP7/AwoA AP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQA IABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAJAAgM5FEcgBeAAAAIAA AAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA8AAAAqBoAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEoAAAC9MgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC52AAAAAAAAAQAAAAIAAAAD AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEA AAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAA ACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAA LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAD+ ////PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAP7/ //9LAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAA AFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAA/v///2UAAABmAAAA ZwAAAGgAAABpAAAAagAAAGsAAAD+//////////////////////////////////////////////// ///////////////+/////v///3wAAAD9/////v////7///9+AAAAfwAAAIEAAABpAG4AZQAgAHQA aABlACAAdQBuAGQAZQBmAGkAbgBlAGQAIABVAFIASQBzACAAZgBvAHIAIAB0AGgAZQAgAGEAbABn AG8AcgBpAHQAaABtAGUAcwAgAGwAaQBzAHQAZQBkACAAaQBuACAAdABoAGUAIABjAHUAcgByAGUA bgB0ACAAUABTAEsAQwA/AAAAAAAfAAAAEgAAAG0AcABlAGkAQAB2AGUAcgBpAHMAaQBnAG4ALgBj AG8AbQAAAB8AAAAPAAAAUABlAGkALAAgAE0AaQBuAGcAbABpAGEAbgBnAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAUwB1AG0AbQBh AHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAAAQAAAA AAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB9AAAA5BAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAA AAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlQBAAAQ AQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsA AACoAAAAEAAAALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAA8AAAAAIAAADkBAAAHgAA ABAAAABWZXJpU2lnbiBJbmMAAAAAAwAAABsAAAADAAAABwAAAAMAAADaDgAAAwAAAAgZCwALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAHAAAAFVSSXMgZm9yIEFsZ29yaXRo bXMgaW4gUFNLQwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAJAPAAAIAAAAAAAAAEgA AAABAAAA4AAAAAIAAADoAAAAAwAAAGgOAAAEAAAAcA4AAAUAAAB8DgAABgAAADwPAAAHAAAAaA8A AAYAAAACAAAADAAAAF9QSURfSExJTktTAAMAAAAUAAAAX0FkSG9jUmV2aWV3Q3ljbGVJRAAEAAAA EAAAAF9OZXdSZXZpZXdDeWNsZQAFAAAADgAAAF9FbWFpbFN1YmplY3QABgAAAA0AAABfQXV0aG9y RW1haWwABwAAABgAAABfQXV0aG9yRW1haWxEaXNwbGF5TmFtZQAAAgAAAOQEAABBAAAAeA0AAJAA AAADAAAALwBgAAMAAABFAAAAAwAAAAAAAAADAAAABQAAAB8AAAA5AAAAaAB0AHQAcAA6AC8ALwB3 AHcAdwAuAHIAcwBhAC4AYwBvAG0ALwByAHMAYQBsAGEAYgBzAC8AbwB0AHAAcwAvAHMAYwBoAGUA bQBhAHMALwAyADAAMAA1AC8AMAA5AC8AbwB0AHAAcwAtAHcAcwB0AAAAAAAfAAAADAAAAFMAZQBj AHUAcgBJAEQALQBBAEUAUwAAAAMAAABgADsAAwAAAEIAAAADAAAAAAAAAAMAAAAFAAAAHwAAACEA AABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABt AGwAZQBuAGMAAAAAAB8AAAALAAAAYQBlAHMAMgA1ADYALQBjAGIAYwAAAAAAAwAAAGwAPAADAAAA PwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBv AHIAZwAvADIAMAAwADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAAAAsAAABhAGUAcwAxADkA MgAtAGMAYgBjAAAAAAADAAAAZwA2AAMAAAA8AAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUA bgBjAAAAAAAfAAAACwAAAGEAZQBzADEAMgA4AC0AYwBiAGMAAAAAAAMAAAANABcAAwAAADkAAAAD AAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcA LwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAAOAAAAdAByAGkAcABsAGUAZABl AHMALQBjAGIAYwAAAAMAAAAUAFsAAwAAADYAAAADAAAAAAAAAAMAAAAFAAAAHwAAACcAAABoAHQA dABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZABz AGkAZwAtAG0AbwByAGUAAAAAAB8AAAAMAAAAaABtAGEAYwAtAHMAaABhADUAMQAyAAAAAwAAABMA XwADAAAAMwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAJwAAAGgAdAB0AHAA/f///4IAAACDAAAAhAAA AIUAAAB7AAAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////86AC8ALwB3AHcAdwAuAHcA MwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGQAcwBpAGcALQBtAG8AcgBlAAAAAAAf AAAADAAAAGgAbQBhAGMALQBzAGgAYQAyADUANgAAAAMAAABUAEwAAwAAADAAAAADAAAAAAAAAAMA AAAFAAAAHwAAACIAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAw AC8AMAA5AC8AeABtAGwAZABzAGkAZwAAAB8AAAAKAAAAaABtAGEAYwAtAHMAaABhADEAAAADAAAA KwA1AAMAAAAtAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAAAAAfAAAABwAAAHMA aABhADUAMQAyAAAAAAADAAAALwA2AAMAAAAqAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUA bgBjAAAAAAAfAAAABwAAAHMAaABhADIANQA2AAAAAAADAAAACgAJAAMAAAAnAAAAAwAAAAAAAAAD AAAABQAAAB8AAAAiAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAA MAAvADAAOQAvAHgAbQBsAGQAcwBpAGcAAAAfAAAABQAAAHMAaABhADEAAAAAAAMAAAAeAA4AAwAA ACQAAAADAAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4A bwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAAKAAAAawB3AC0AYQBl AHMANQAxADIAAAADAAAAGQAKAAMAAAAhAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQA cAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBj AAAAAAAfAAAACgAAAGsAdwAtAGEAZQBzADIANQA2AAAAAwAAABoADQADAAAAHgAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAw ADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAAAAoAAABrAHcALQBhAGUAcwAxADIAOAAAAAMA AABMAEsAAwAAABsAAAADAAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3 AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAANAAAA awB3AC0AdAByAGkAcABsAGUAZABlAHMAAAAAAAMAAABqAG4AAwAAABgAAAADAAAAAAAAAAMAAAAF AAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwAyADAAMAAxAC8A MAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAAPAAAAcgBzAGEALQBvAGEAZQBwAC0AbQBnAGYAMQBw AAAAAAADAAAAKgBbAAMAAAAVAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6AC8A LwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAAAAAf AAAACAAAAHIAcwBhAC0AMQBfADUAAAADAAAAYAA7AAMAAAASAAAAAwAAAAAAAAADAAAABQAAAB8A AAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AMgAwADAAMQAvADAANAAv AHgAbQBsAGUAbgBjAAAAAAAfAAAACwAAAGEAZQBzADIANQA2AC0AYwBiAGMAAAAAAAMAAABsADwA AwAAAA8AAAADAAAAAAAAAAMAAAAFAAAAHwAAACEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAz AC4AbwByAGcALwAyADAAMAAxAC8AMAA0AC8AeABtAGwAZQBuAGMAAAAAAB8AAAALAAAAYQBlAHMA MQA5ADIALQBjAGIAYwAAAAAAAwAAAGcANgADAAAADAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3ADMALgBvAHIAZwAvADIAMAAwADEALwAwADQALwB4AG0A bABlAG4AYwAAAAAAHwAAAAsAAABhAGUAcwAxADIAOAAtAGMAYgBjAAAAAAADAAAADQAXAAMAAAAJ AAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8A cgBnAC8AMgAwADAAMQAvADAANAAvAHgAbQBsAGUAbgBjAAAAAAAfAAAADgAAAHQAcgBpAHAAbABl AGQAZQBzAC0AYwBiAGMAAAADAAAANwA5AAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAAiAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAHcAMwAuAG8AcgBnAC8AVABSAC8AeABtAGwAZQBuAGMALQBj AG8AcgBlAC8AAAAfAAAADwAAAHMAZQBjAC0AQQBsAGcAbwByAGkAdABoAG0AcwAAAAAAAwAAAEEA QgADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3 ADMALgBvAHIAZwAvADIAMAAwADEALwAwADQALwB4AG0AbABlAG4AYwAAAAAAHwAAAA4AAABrAHcA LQBhAGUAcwAxADIAOAAtAGMAYgBjAAAAAwAAAD8AfwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAf AAAANwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgByAHMAYQBzAGUAYwB1AHIAaQB0AHkALgBjAG8A bQAvAHIAcwBhAGwAYQBiAHMALwBwAGsAYwBzAC8AcwBjAGgAZQBtAGEAcwAvAHAAawBjAHMALQA1 AAAAAAAfAAAABgAAAHAAYgBlAHMAMgAAAAMAAABTXED5HwAAAAEAAAAAAAAAHwAAAFsAAABXAGgA ZQByAGUAIABhAG4AZAAgAGgAbwB3ACAAdABvACAAZABlAGYA ------_=_NextPart_001_01C81145.CFD6B7A6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C81145.CFD6B7A6-- From keyprov-bounces@ietf.org Thu Oct 18 01:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiNu1-0000rG-OS; Thu, 18 Oct 2007 01:26:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiNtz-0000eh-P8 for keyprov@ietf.org; Thu, 18 Oct 2007 01:26:35 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiNto-0001cu-M2 for keyprov@ietf.org; Thu, 18 Oct 2007 01:26:25 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9I5N8s4020996; Wed, 17 Oct 2007 22:23:08 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 06:26:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Oct 2007 22:26:02 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503D04@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBM6pTgAACR9qA= From: "Pei, Mingliang" To: "Pei, Mingliang" , "Philip Hoyer" , , "Hallam-Baker, Phillip" , , , "Doherty, Andrea" , X-OriginalArrivalTime: 18 Oct 2007 05:26:03.0816 (UTC) FILETIME=[606CEA80:01C81147] X-Spam-Score: 0.0 (/) X-Scan-Signature: b43eaa29978e81774503cbe9ddd3bf8a Cc: Subject: [KEYPROV] RE: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1211027020==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1211027020== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81147.60393FAC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81147.60393FAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Note that PBE URIs may use the PKCS URI and Key Wrapper URIs in xmlenc spec. PSKC schema introduces a type for PBE related algorithms as follows. The question is whether it is necessary to combine them. =20 =20 =20 Example: =20 y6TzckeLRQw=3D 1024 c2FtcGxlaXY=3D =20 which is currently proposed. =20 - Ming ________________________________ From: Pei, Mingliang=20 Sent: Wednesday, October 17, 2007 10:15 PM To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; shuh.chang@gemalto.com; smachani@diversinet.com; Doherty, Andrea; keyprov@ietf.org Subject: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? =09 =09 All, =20 In our effort to use URIs instead of enumerations in PSKC for EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we found that some algorithms don't have a defined / registered URIs yet, mostly, for the PBE methods and Key Algorithms. Attached please find current laundry list of the algorithms for their respective URIs, and those that need some URIs to be defined. We found most URIs defined by XML signature and encryption specification (xmldsig, additional xmldsig URIs, and xmlenc ). =20 Please let us know if you find some places that have defined URIs for the listed missing ones, or any suggestions where we should define the new ones, for example, OTP algorithms by HOTP, variours vendors (VASCO, SecurID (if need one other than current RSA URL)). =20 Please see the attached doc for questions. Here are quoted questions: =20 =09 =20 a) Where can we find URIs defined for PBE algorithms? =20 PBEs are defined in PKCS#5. The XML version defined the following URI. One PBE algorithm would need two URIs to define, for example, PBE-AES128-CBC would be identified with the following two: =20 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc =20 and possibly a third one that identifies key derivative function. =20 b) Shall we define one URI for each PBE method with encryption such as PBE-AES128-CBC? =20 Thank you, =20 - Ming =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 9:23 AM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: IETF Keyprov PSKC meeting minutes 15/10.07 =09 =09 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C81147.60393FAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Note that PBE URIs may use the PKCS URI = and Key=20 Wrapper URIs in xmlenc spec. PSKC schema introduces a type for PBE = related=20 algorithms as follows. The question is whether it is necessary to = combine=20 them.
 
  <complexType=20 name=3D"PBEEncryptionParamType">
   =20 <sequence>
      <element = name=3D"PBESalt"=20 type=3D"base64Binary"
        =       =20 minOccurs=3D"0"/>
      <element=20 name=3D"PBEIterationCount"=20 type=3D"int"
         &nb= sp;    =20 minOccurs=3D"0"/>
    = </sequence>
   =20 <attribute name=3D"encAlgorithm" type=3D"anyURI"/>
 =20 </complexType>
 
  <complexType=20 name=3D"EncryptionMethodType">
   =20 <sequence>
      <element=20 name=3D"EncKeyLabel" = minOccurs=3D"0"/>
     =20 <choice>
       =20 <sequence>
         = ;=20 <element=20 name=3D"KeyInfo"
         = ;         =20 type=3D"ds:KeyInfoType"=20 minOccurs=3D"0"/>
        &= nbsp;=20 <element=20 name=3D"OAEPParams"
        &n= bsp;         =20 type=3D"base64Binary"=20 minOccurs=3D"0"/>
       =20 </sequence>
       =20 <sequence>
         = ;=20 <element=20 name=3D"PBEEncryptionParam"
       =            =20 type=3D"pskc:PBEEncryptionParamType"=20 minOccurs=3D"0"/>
        &= nbsp;=20 <element name=3D"IV" type=3D"base64Binary"=20 minOccurs=3D"0"/>
       =20 </sequence>
        <any=20 namespace=3D"##other"=20 processContents=3D"strict"/>
     =20 </choice>
    = </sequence>
   =20 <attribute=20 name=3D"algorithm"
        &nb= sp;     =20 type=3D"anyURI" use=3D"required"/>
 =20 </complexType>
 
Example:
 
     =20 <EncryptionMethod
        = algorithm=3D"htt= p://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2"
 &= nbsp;     =20 xmlns=3D"urn:ietf:params:xml:ns:keyprov:container">
  &nb= sp;      =20 <PBEEncryptionParam
        = ;    =20 encAlgorithm=3D"http://www.w3.org= /2001/04/xmlenc#kw-aes128-cbc">
     &= nbsp;     =20 <PBESalt>y6TzckeLRQw=3D</PBESalt>
    =        =20 <PBEIterationCount>1024</PBEIterationCount>
  &n= bsp;      =20 </PBEEncryptionParam>
       =   =20 <IV>c2FtcGxlaXY=3D</IV>
     &nbs= p; =20 </EncryptionMethod>
 
which is currently = proposed.
 
- Ming

From: Pei, Mingliang =
Sent:=20 Wednesday, October 17, 2007 10:15 PM
To: Philip Hoyer;=20 Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; = shuh.chang@gemalto.com;=20 smachani@diversinet.com; Doherty, Andrea; = keyprov@ietf.org
Subject:=20 Where and how to define the undefined URIs for the algorithmes listed = in the=20 current PSKC?

All,
 
In our effort to use URIs instead of = enumerations in=20 PSKC for EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we = found=20 that some algorithms don't have a defined / registered URIs yet, = mostly, for=20 the PBE methods and Key Algorithms. Attached please find current = laundry list=20 of the algorithms for their respective URIs, and those that need some = URIs to=20 be defined. We found most URIs defined by XML signature and encryption = specification (xmldsig, additional xmldsig URIs, and xmlenc=20 ).
 
Please let us know if you find some places = that have=20 defined URIs for the listed missing ones, or any suggestions where we = should=20 define the new ones, for example, OTP algorithms by HOTP,=20 variours vendors (VASCO, SecurID (if need one other than current = RSA=20 URL)).
 
Please see the attached doc for questions. = Here are=20 quoted questions:
 
 =20

a) Where=20 can we find URIs defined for PBE algorithms?

 

PBEs are=20 defined in PKCS#5. The XML version defined the following URI. One PBE=20 algorithm would need two URIs to define, for example, PBE-AES128-CBC = would be=20 identified with the following two:

 

htt= p://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2

http://www.w3.org= /2001/04/xmlenc#kw-aes128-cbc

 

and=20 possibly a third one that identifies key derivative = function.

 

b) Shall we=20 define one URI for each PBE method with encryption such as=20 PBE-AES128-CBC?

 

Thank you,
 
- Ming
 

From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, = October=20 16, 2007 9:23 AM
To: Hannes.Tschofenig@gmx.net; = Hallam-Baker,=20 Phillip; Pei, Mingliang; shuh.chang@gemalto.com;=20 smachani@diversinet.com
Cc: = keyprov@ietf.org
Subject:=20 IETF Keyprov PSKC meeting minutes 15/10.07

Attendees:=20

Philip Hoyer, = Ming Pei, Shuh Chang, Salah Macchani, = Phillip=20 Hallam-Baker, Hannes Tschofenig

 

 

 

1)      =20 Initially = decided to=20 tackle the issue of algorithms that are represented as enumerations = in PSKC=20 and if we should go to a URI based approach that allows for easier=20 extension. There are 3 type of algorithm definitions in=20 PSKC

a.      =20 EncryptionAlgorithm=20 of the key material in the container

b.      =20 DigestAlgorithm to=20 create a digest of the uncencrypted = keys

c.      =20 OTP = Algorithm,=20 identifier of the algorithm that the key is being used=20 with

2)      =20 Agreed to = change=20 EncryptionAlgorithm and DigestAlgorithm to change to=20 URI

3)      =20 Ming Pei to=20 change schema and add minimum list of URIs =

a.      =20 Issue, = what about PBE=20 related algorithms, no URIs found by = Ming

b.      =20 Ming Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he=20 has not found URIs. Philip Hallam Baker will then try to find URIs = or get=20 back to authors with way to proceed

4)      =20 Discussion about=20 digest of the key for RSA encrypted keys – Ming, Shuh to check = if it is a=20 bad idea – Philip to ask to the = list

a.      =20 The = problem here is=20 that the Digest used for symmetric algorithms is a keyed digest eg = HMAC-SHA1=20 which is still not broken. If for transmission of keys wrapped by a = public=20 Key of the receiving party we use a simple digest iof the = unencrypted key=20 material, it might open the container for brute force attacks. Since = a=20 keyvalue to hash value mapping might be much quicker to find than = brute=20 forcing HMAC-SHA1

5)      =20 URIs for=20 KeyAlgorithm?

a.      =20 Fundamentally the=20 people agreed that it is a better idea but even more than encryption = and=20 digest algorithms, OTP algotihms do not have a defined=20 URI

b.      =20 Ming Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he=20 has not found URIs Philip Hallam Baker will then try to find URIs or = get=20 back to authors with way to proceed

6)      =20 Philip = Hoyer proposed=20 to introduce a keyType at container level with attributes such as = algorithm=20 and logo and usage type that the key can reference (this would avoid = repeating all the data for similar keys within the container) = – Everyone=20 agreed that this was a good idea but  deemed a priority 2=20 item

7)      =20 Hannes to = investigate=20 what best practice is regarding URN versioning, current proposal is = to add=20 numeric version so all ietf:keyprov URN should add=20 ‘:1’

8)      =20 Should we = reorganise=20 PBE to support PKCS5 XML schema, currently this was deemed to = complicate the=20 schema too much so it was deferred for now =

9)      =20 Discussion around=20 attributes and elements, should the ASN.1 document contain the = description=20 of the attributes. Decision for ASN.1document to incorporate = attribute=20 definition of PSKC spec. Hannes to send email to the=20 list.

10)  =20 Discussion if we need=20 to have a face to face meeting to align spec. Hannes asked if a set = of=20 conference calls with a precise short agenda. Would be good. Should = we have=20 a weekly conference call? Agreed to have a weekly call on Monday 3pm = Central=20 4pm EDT 9 pm for 30 minutes

11)  =20 IV should = be moved=20 back to EncryptionMethod since it is used for symmetric algorithms = and not=20 only for PBE (Ming in his latest revision had moved it to the = PBEParams=20 element)

12)  =20 Discussed = initial PIN=20 transmission, Philip invited for participants to review and agree. = If no=20 disagreements Philip Hoyer will include in October revision of the=20 spec

 

 

 

 

________________________________

 

Philip=20 Hoyer=20

 

Senior = Architect -=20 Office of CTO

 

ActivIdentity=20 (UK)=

109 Borough = High=20 Street

London SE1=20 1NL

 

Telephone: +44 = (0) 20=20 7744 6248

Direct: +44 = (0) 20 7744=20 6455

Fax: +44 (0) = 20 7744=20 6249

 

Private and=20 confidential: This message and any attachments may=20 contain

privileged /=20 confidential information. If you are not an intended=20 recipient,

you must not = copy,=20 distribute, discuss or take any action in reliance on=20 it.

If you have = received=20 this communication in error, please notify the=20 sender

and delete = this message=20 immediately.

 

= ------_=_NextPart_001_01C81147.60393FAC-- --===============1211027020== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1211027020==-- From keyprov-bounces@ietf.org Thu Oct 18 05:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiS9D-0007x6-Bb; Thu, 18 Oct 2007 05:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiS9A-0007X1-R3 for keyprov@ietf.org; Thu, 18 Oct 2007 05:58:32 -0400 Received: from frhub1.activcard.fr ([91.151.120.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiS8w-00011g-Qa for keyprov@ietf.org; Thu, 18 Oct 2007 05:58:26 -0400 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 72D9825ED46; Thu, 18 Oct 2007 11:57:56 +0200 (CEST) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 33ML63RP; Thu, 18 Oct 2007 12:03:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Oct 2007 11:59:39 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23FA@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503D02@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBM6pTgAAng85A= References: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23E1@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C9503D02@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Philip Hoyer" To: "Pei, Mingliang" , , "Hallam-Baker, Phillip" , , , "Doherty, Andrea" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 34f574168049ab737b16945320cc2031 Cc: Subject: [KEYPROV] RE: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0838074108==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0838074108== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8116D.98B83D5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8116D.98B83D5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ming, The MKEYLABEL is not really an algorithm but a way to denote a unique label of a pre shared master key.=20 Maybe we can do this by defining the masterkey-label in the credentialed and creating URIs for the masterkey derivation algorithms. =20 This is the case for example for EMV cards where in PSKC you would only transmit the data necessary for key derivation and refer to a master key label and a derivation algorithm. =20 It might be the case that we should make this more explicit (eg a choice between algorithm and derivation algorithm). I personally believe this is overkill. =20 I suggest we remove MKEYLABEL and add a description in the spec saying that for keys derived from masterkeys the credentialed contains the masterkey label and the algorithm is the derivation algorithm. =20 Obviously this means that we need to create some URIs for key-derivation algorithms we want to support. =20 Philip =20 =20 ________________________________ From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Thursday, October 18, 2007 6:15 AM To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; shuh.chang@gemalto.com; smachani@diversinet.com; Doherty, Andrea; keyprov@ietf.org Subject: Where and how to define the undefined URIs for the algorithmes listed in the current PSKC? =20 All, =20 In our effort to use URIs instead of enumerations in PSKC for EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we found that some algorithms don't have a defined / registered URIs yet, mostly, for the PBE methods and Key Algorithms. Attached please find current laundry list of the algorithms for their respective URIs, and those that need some URIs to be defined. We found most URIs defined by XML signature and encryption specification (xmldsig, additional xmldsig URIs, and xmlenc ). =20 Please let us know if you find some places that have defined URIs for the listed missing ones, or any suggestions where we should define the new ones, for example, OTP algorithms by HOTP, variours vendors (VASCO, SecurID (if need one other than current RSA URL)). =20 Please see the attached doc for questions. Here are quoted questions: =20 =20 a) Where can we find URIs defined for PBE algorithms? =20 PBEs are defined in PKCS#5. The XML version defined the following URI. One PBE algorithm would need two URIs to define, for example, PBE-AES128-CBC would be identified with the following two: =20 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc =20 and possibly a third one that identifies key derivative function. =20 b) Shall we define one URI for each PBE method with encryption such as PBE-AES128-CBC? =20 Thank you, =20 - Ming =20 =20 =09 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 9:23 AM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: IETF Keyprov PSKC meeting minutes 15/10.07 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C8116D.98B83D5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ming,

The MKEYLABEL is not really an = algorithm but a way to denote a unique label of a pre shared master key. =

Maybe we can do this by defining = the masterkey-label in the credentialed and creating URIs for the masterkey derivation algorithms.

 

This is the case for example for = EMV cards where in PSKC you would only transmit the data necessary for key = derivation and refer to a master key label and a derivation = algorithm.

 

It might be the case that we should = make this more explicit (eg a choice between algorithm and derivation = algorithm). I personally believe this is overkill.

 

I suggest we remove MKEYLABEL and = add a description in the spec saying that for keys derived from masterkeys the = credentialed contains the masterkey label and the algorithm is the derivation = algorithm.

 

Obviously this means that we need = to create some URIs for key-derivation algorithms we want to = support.

 

Philip

 

 

From: Pei, = Mingliang [mailto:mpei@verisign.com]
Sent: Thursday, October = 18, 2007 6:15 AM
To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, = Phillip; shuh.chang@gemalto.com; smachani@diversinet.com; Doherty, Andrea; keyprov@ietf.org
Subject: Where and how to = define the undefined URIs for the algorithmes listed in the current = PSKC?

 

All,

 

In our effort to use URIs instead = of enumerations in PSKC for EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we found that some algorithms don't have a defined / = registered URIs yet, mostly, for the PBE methods and Key Algorithms. Attached = please find current laundry list of the algorithms for their respective URIs, and = those that need some URIs to be defined. We found most URIs defined by XML = signature and encryption specification (xmldsig, additional xmldsig URIs, and = xmlenc ).

 

Please let us know if you find some = places that have defined URIs for the listed missing ones, or any suggestions = where we should define the new ones, for example, OTP algorithms by HOTP, variours vendors (VASCO, SecurID (if need one other than current = RSA URL)).

 

Please see the attached doc for = questions. Here are quoted questions:

 

  =

a) Where can we find URIs defined = for PBE algorithms?

 

=

PBEs are defined in PKCS#5. The = XML version defined the following URI. One PBE algorithm would need two URIs = to define, for example, PBE-AES128-CBC would be identified with the = following two:

 

=

htt= p://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2<= /span>

http://www.w3.org= /2001/04/xmlenc#kw-aes128-cbc

 

=

and possibly a third one that = identifies key derivative function.

 

=

b) Shall we define one URI for = each PBE method with encryption such as PBE-AES128-CBC?

 

=

Thank = you,

 

- Ming

 

 

From: Philip Hoyer = [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, October = 16, 2007 9:23 AM
To: = Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com
Cc: keyprov@ietf.org
Subject: IETF Keyprov = PSKC meeting minutes 15/10.07

Attendees:

Philip = Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes = Tschofenig

 

 

 

1)       Initially decided to tackle the issue of algorithms = that are represented as enumerations in PSKC and if we should go to a URI based = approach that allows for easier extension. There are 3 type of algorithm = definitions in PSKC

a.       EncryptionAlgorithm of the key material in the = container

b.       DigestAlgorithm to create a digest of the = uncencrypted keys

c.       OTP Algorithm, identifier of the algorithm that the = key is being used with

2)       Agreed to change EncryptionAlgorithm and = DigestAlgorithm to change to URI

3)       Ming Pei to change schema and add minimum list of URIs

a.       Issue, what about PBE related algorithms, no URIs = found by Ming

b.       Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for = which he has not found URIs. Philip Hallam Baker will then try to find URIs or = get back to authors with way to proceed

4)       Discussion about digest of the key for RSA encrypted = keys – Ming, Shuh to check if it is a bad idea – Philip to ask to = the list

a.       The problem here is that the Digest used for = symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If = for transmission of keys wrapped by a public Key of the receiving party we = use a simple digest iof the unencrypted key material, it might open the = container for brute force attacks. Since a keyvalue to hash value mapping might be = much quicker to find than brute forcing = HMAC-SHA1

5)       URIs for KeyAlgorithm?

a.       Fundamentally the people agreed that it is a better = idea but even more than encryption and digest algorithms, OTP algotihms do not = have a defined URI

b.       Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for = which he has not found URIs Philip Hallam Baker will then try to find URIs or get = back to authors with way to proceed

6)       Philip = Hoyer proposed to introduce a keyType at container level with attributes such = as algorithm and logo and usage type that the key can reference (this would = avoid repeating all the data for similar keys within the container) – = Everyone agreed that this was a good idea but  deemed a priority 2 = item

7)       Hannes to investigate what best practice is regarding = URN versioning, current proposal is to add numeric version so all = ietf:keyprov URN should add ‘:1’

8)       Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was = deferred for now

9)       Discussion around attributes and elements, should the = ASN.1 document contain the description of the attributes. Decision for = ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email = to the list.

10)   = Discussion if we need to have a face to face meeting to align spec. Hannes asked if = a set of conference calls with a precise short agenda. Would be good. Should = we have a weekly conference call? Agreed to have a weekly call on Monday 3pm = Central 4pm EDT 9 pm for 30 minutes

11)   = IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved = it to the PBEParams element)

12)   = Discussed initial PIN transmission, Philip invited for participants to review and = agree. If no disagreements Philip = Hoyer will include in October revision of the = spec

 

 

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C8116D.98B83D5A-- --===============0838074108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0838074108==-- From keyprov-bounces@ietf.org Thu Oct 18 06:14:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiSOj-0003fq-Np; Thu, 18 Oct 2007 06:14:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiSOi-0003eV-CC for keyprov@ietf.org; Thu, 18 Oct 2007 06:14:36 -0400 Received: from frhub1.activcard.fr ([91.151.120.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiSOf-0000jl-Cm for keyprov@ietf.org; Thu, 18 Oct 2007 06:14:34 -0400 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id AE8C525ED3C; Thu, 18 Oct 2007 12:14:31 +0200 (CEST) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 33ML63S8; Thu, 18 Oct 2007 12:19:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Date: Thu, 18 Oct 2007 12:16:14 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23FB@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B017@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAAAFH6XMA== References: <1190365090.79.0.72059660846.issue28@http://www.tschofenig.priv.at> <5BFE9E473DBFC24CA87F18F29B3F0AC4758281@sur-corp-ex-02.corp.ad.activcard.com> <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B017@rsana-ex-hq1.NA.RSA.NET> From: "Philip Hoyer" To: "Doherty, Andrea" , "KEYPROV Roundup Issue Tracker" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: "M'Raihi, David" , "Bajaj, Siddharth" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea, You are right I have not addressed the Pin policy issue. I would like to though.=20 Since you seem to have a good idea of the requirements would you be able to help? I suggest we create a new type called PINPolicy that contains the data required to be submitted. So currently PIN usage I can think of is: -KEY_ACCESS_CHECK (this check the pin on the device to allow access to a key for algorithms) -USED_IN_ALGO (used during calculation) When you talk though about length I already have that in the part of the PIN 'key' see below NEW-> Credential Issuer MyFirstTokenInitialPIN WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D <-NEW Also when we talk about server verified pins in otps are we not really talking about the otp algo or usage here? I was wondering hence if our usage element for the otp key should be augmented to contain and optional What do you think? Philip -----Original Message----- From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 Sent: Thursday, October 18, 2007 1:28 AM To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Philip, This looks ok except that a more complex PIN policy is needed (refer to this comment I made to the previous version of the PSKC draft, Section 5.1.7: "Recommend that you allow for a more complex PIN policy, esp., (a) how the PIN is to be used in the OTP calculation (e.g., concatenated vs. XOR's with the token code) and (b) PIN length. " This doesn't seem to have been addressed yet based on feedback to my review (see attached) and example below. What is the status of this? =20 Andrea -----Original Message----- From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Friday, September 28, 2007 11:48 AM To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Gentlemen, Since PSKC will be used also to bulk provision from manufacturing to a validation server and some of these devices do have a PIN pad there is the concept of an initial PIN. Since we have not yet defined how this initial PIN is transmitted in the PSKC spec I would like to put forward a proposal for inclusion in the spec for specifying the transmission of PINs. The PIN is effectively another shared secret hence I propose to treat it as a key in itself. This has the advantage that we can leverage the Usage part of the schema that can define things like length and format (alphanumeric etc). we also can set an expiry etc. It also leverages the fact that the PIN itself will be encrypted in transport in the same manner as other key material. I hence propose to extend the KeyAlgorithmType with a new type called 'userPIN' (inline with the name used in the access rules element already present) As an example a KeyContainer with a non encrypted HOTP key and a 4 digit numeric PIN (please note that the value and valuedigest are just copy and paste) ( I put the new section with NEW-> and <-NEW lines before and after): Token Manufacturer 98765432187 01/01/2008 Credential Issuer NEW-> <-NEW MyFirstToken WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D NEW-> Credential Issuer MyFirstTokenInitialPIN WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D <-NEW Comments are welcome, Philip -----Original Message----- From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, September 21, 2007 9:58 AM To: keyprov@ietf.org Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client viaPSKC? New submission from Mingliang Pei : PSKC provies support about carrying PIN usage policy. When PIN is used, how do=20 you actually transfer the initial PIN using PSKC? Should PIN be treated as=20 another credential, for example? ---------- assignedto: mpei messages: 71 nosy: keyprov, mpei priority: critical status: chatting title: How to transfer initial PIN to a client via PSKC? _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Oct 18 07:42:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiTll-00022C-Qx; Thu, 18 Oct 2007 07:42:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiTli-0001Zx-Ii for keyprov@ietf.org; Thu, 18 Oct 2007 07:42:26 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiTle-0005Cg-6i for keyprov@ietf.org; Thu, 18 Oct 2007 07:42:22 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9IBgL6U012842 for ; Thu, 18 Oct 2007 07:42:21 -0400 (EDT) Received: from rsasecurity.com (rsaeu-smtp-uk1.eu.rsa.net [10.148.48.70]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9IBgJQ1020738 for ; Thu, 18 Oct 2007 07:42:20 -0400 (EDT) Received: from rsaeu-ex-uk2.eu.rsa.net (e2k.rsa.net [10.148.48.60]) by rsasecurity.com (8.13.5/8.12.9) with ESMTP id l9IBWDGM008392 for ; Thu, 18 Oct 2007 11:32:13 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Oct 2007 12:42:04 +0100 Message-ID: <16B9CF34A1B2E445BE9398C6FF09DF90038BECA8@rsaeu-ex-uk2.eu.rsa.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Name-space issues in DSKPP and PSKC thread-index: AcgRe+ffASY/VvNaRc2tVRdr5x1bkg== From: "Rundgren, Anders" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [KEYPROV] Name-space issues in DSKPP and PSKC X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org If you compare=20 xmlns:dskpp=3D"urn:ietf:params:xml:schema:keyprov:protocol" xmlns:pskc=3D"urn:ietf:params:xml:ns:keyprov:container" with for example xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" it is not only the fact that you cannot dereference URNs that differ but that the two former namespaces seem to lack version information. Although you can use the version tag in the XML Schema to signify actual version, I'm (as a protocol implementer), a bit skeptical regarding mixing a potentially radically different v2 in the same name-space as v1. Personally I would not even try to put a v1.1 in the same name-space. It is in fact very convenient to just instantiate the appropriate XML object container based on the name-space and the top level element. The version tag does IMHO not add value, but it sure adds confusion. Other: It seems that the majority of XML-based standards use elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified" I think this is preferable regardless if you use prefixes or not. Regards Anders Rundgren _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Oct 19 16:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiySI-0001ZJ-OV; Fri, 19 Oct 2007 16:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiySH-0001Km-IO for keyprov@ietf.org; Fri, 19 Oct 2007 16:28:25 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiyS8-00013A-4T for keyprov@ietf.org; Fri, 19 Oct 2007 16:28:22 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9JKOZRT021638; Fri, 19 Oct 2007 13:24:35 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 21:27:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] Name-space issues in DSKPP and PSKC Date: Fri, 19 Oct 2007 13:27:31 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503E34@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <16B9CF34A1B2E445BE9398C6FF09DF90038BECA8@rsaeu-ex-uk2.eu.rsa.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Name-space issues in DSKPP and PSKC Thread-Index: AcgRe+ffASY/VvNaRc2tVRdr5x1bkgBChttQ From: "Pei, Mingliang" To: "Rundgren, Anders" , X-OriginalArrivalTime: 19 Oct 2007 20:27:32.0516 (UTC) FILETIME=[7A374E40:01C8128E] X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi Anders, Thank you for your comments and suggestions. Here are reasons that we choose the current approach. 1. IANA has had many spec that uses the URI style for schema. Instead of URL as schema for xmldsig, URI is good. One can find schema files via IANA pages. See the following page for schemas defined / registered with IANA: http://www.iana.org/assignments/xml-registry/schema.html 2. Some other later specs also use this style for schema URIs, for example, SAML. urn:oasis:names:tc:SAML:2.0:protocol defined in http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.x sd 3. To support versioning, we are changing to add :1.0 in the URI. With regard to elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified", most schema files do set them this way. By default, it is "unqualified" if not specified. Some still chooses to spell out even if both are set unqualified. For example, SAML v2.0 schema: elementFormDefault=3D"unqualified" = attributeFormDefault=3D"unqualified" blockDefault=3D"substitution" version=3D"2.0" The value controls whether the namespaces of the elements being used by the schema will be hidden or exposed in instance documents. I tried to verify some best practice about this usage. For example, here is one link found from google about this topic. http://www.xfront.com/HideVersusExpose.html Personally I felt that unqualified allows simpler instance doc without clutting of namespace. Also considering that the DSKPP schema is the top "application" level use, unqualified element is mostly fine. PKSC schema, on the other hand, is better to be "qualified" as it is a building block for other schema to import. We will review this further, and reply back soon. Thank you for the suggestion. - Ming -----Original Message----- From: Rundgren, Anders [mailto:arundgren@rsasecurity.com]=20 Sent: Thursday, October 18, 2007 4:42 AM To: keyprov@ietf.org Subject: [KEYPROV] Name-space issues in DSKPP and PSKC If you compare=20 xmlns:dskpp=3D"urn:ietf:params:xml:schema:keyprov:protocol" xmlns:pskc=3D"urn:ietf:params:xml:ns:keyprov:container" with for example xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" it is not only the fact that you cannot dereference URNs that differ but that the two former namespaces seem to lack version information. Although you can use the version tag in the XML Schema to signify actual version, I'm (as a protocol implementer), a bit skeptical regarding mixing a potentially radically different v2 in the same name-space as v1. Personally I would not even try to put a v1.1 in the same name-space. It is in fact very convenient to just instantiate the appropriate XML object container based on the name-space and the top level element. The version tag does IMHO not add value, but it sure adds confusion. Other: It seems that the majority of XML-based standards use elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified" I think this is preferable regardless if you use prefixes or not. Regards Anders Rundgren _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Oct 19 16:39:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiydC-0004Di-Ji; Fri, 19 Oct 2007 16:39:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiydB-00046O-Jq for keyprov@ietf.org; Fri, 19 Oct 2007 16:39:41 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiyd3-0001Y7-Kg for keyprov@ietf.org; Fri, 19 Oct 2007 16:39:35 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9JKZw9U022062; Fri, 19 Oct 2007 13:35:58 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 21:38:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Date: Fri, 19 Oct 2007 13:38:54 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503E36@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B015@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBCSDogAF1EkYA= From: "Pei, Mingliang" To: "Doherty, Andrea" , "Philip Hoyer" , , "Hallam-Baker, Phillip" , , X-OriginalArrivalTime: 19 Oct 2007 20:38:55.0865 (UTC) FILETIME=[11861690:01C81290] X-Spam-Score: -4.0 (----) X-Scan-Signature: b0ea7984e9e2d84601de65ae5960f32c Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0975776892==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0975776892== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81290.1150F8ED" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81290.1150F8ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I like to add another issue to track and resolve. =20 13) Consistent attribute name convention: upper case vs. lower case. =20 DSKPP uses upper case for all element names and attribute names. PSKC used lower case in majority attribute names, and some in upper cases. For example: =20 UsageType: =20 KeyType: =20 =20 DataType: =20 =20 For consistency, I suggest that we change them all to upper case. Comments? =20 - Ming ________________________________ From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 Sent: Wednesday, October 17, 2007 5:14 PM To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Philip, =20 Thank you for forwarding these minutes to the mailing list. =20 It is good to see progress towards use of standard XML (esp. URIs for algorithms). Toward this end, and also for alignment with DSKPP, a couple of things are needed: 1. Switch to use of ordinary XMLEnc, XMLDSig 2. Switch to use PKCS #5 XML as it makes no sense to have this in DSKPP and not in PSKC. The schema is not complex. What is being referred to as "difficult" (see #8 below)? =20 Regarding use of URIs for OTP algorithms --- why is this necessary? I know we spoke of doing this before, but stepping back a bit, isn't it really up to vendors to specify their own URIs? If vendor-specific URIs are included in the doc that should be fine since the purpose of using URIs is to allow for extensibility. =20 Andrea =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 12:23 PM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C81290.1150F8ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
I like to add another issue to track and=20 resolve.
 
13) Consistent attribute name convention: = upper case=20 vs. lower case.
 
DSKPP uses upper case for all element names = and=20 attribute names. PSKC used lower case in majority attribute names, and = some in=20 upper cases. For example:
 
UsageType:
 
    <attribute name=3D"otp" = type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute name=3D"cr"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute name=3D"sign" = type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute = name=3D"encrypt"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute = name=3D"unlock"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>
KeyType:
 
<attribute name=3D"KeyId" type=3D"string"=20 use=3D"required"/>
 
DataType:
 
    = <attribute=20 name=3D"Name"=20 type=3D"string"
         =      =20 use=3D"required"/>
 
For=20 consistency, I suggest that we change them all to upper case.=20 Comments?
 
-=20 Ming
From: Doherty, Andrea = [mailto:adoherty@rsa.com]=20
Sent: Wednesday, October 17, 2007 5:14 PM
To: = Philip Hoyer;=20 Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang;=20 shuh.chang@gemalto.com; smachani@diversinet.com
Cc:=20 keyprov@ietf.org
Subject: RE: [KEYPROV] IETF Keyprov PSKC = meeting=20 minutes 15/10.07

Philip,
 
Thank you for forwarding these minutes to the = mailing=20 list.
 
It is good to see progress towards use of = standard XML=20 (esp. URIs for algorithms).  Toward this end, and also for = alignment with=20 DSKPP, a couple of things are needed:
1. Switch to use of ordinary XMLEnc,=20 XMLDSig
2. Switch to use PKCS #5 XML as it makes no = sense to have=20 this in DSKPP and not in PSKC.  The schema is not complex.  = What is=20 being referred to as "difficult" (see #8 below)?
 
Regarding use of URIs for OTP algorithms --- = why is this=20 necessary?  I know we spoke of doing this before, but stepping back = a bit,=20 isn't it really up to vendors to specify their own URIs?  If=20 vendor-specific URIs are included in the doc that should be fine since = the=20 purpose of using URIs is to allow for extensibility.
 
Andrea
 
From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, = October 16,=20 2007 12:23 PM
To: Hannes.Tschofenig@gmx.net; Hallam-Baker, = Phillip;=20 Pei, Mingliang; shuh.chang@gemalto.com; = smachani@diversinet.com
Cc:=20 keyprov@ietf.org
Subject: [KEYPROV] IETF Keyprov PSKC meeting = minutes=20 15/10.07

Attendees:=20

Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, = Phillip=20 Hallam-Baker, Hannes Tschofenig

 

 

 

1)      =20 Initially = decided to=20 tackle the issue of algorithms that are represented as enumerations in = PSKC and=20 if we should go to a URI based approach that allows for easier = extension. There=20 are 3 type of algorithm definitions in PSKC

a.      =20 EncryptionAlgorithm of=20 the key material in the container

b.      =20 DigestAlgorithm to create=20 a digest of the uncencrypted keys

c.      =20 OTP = Algorithm, identifier=20 of the algorithm that the key is being used = with

2)      =20 Agreed to = change=20 EncryptionAlgorithm and DigestAlgorithm to change to=20 URI

3)      =20 Ming=20 Pei to change=20 schema and add minimum list of URIs

a.      =20 Issue, what = about PBE=20 related algorithms, no URIs found by Ming

b.      =20 Ming=20 Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he has=20 not found URIs. Philip Hallam Baker will then try to find URIs or get = back to=20 authors with way to proceed

4)      =20 Discussion = about digest=20 of the key for RSA encrypted keys – Ming, Shuh to check if it is a = bad idea –=20 Philip to ask to the list

a.      =20 The problem = here is that=20 the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 = which is=20 still not broken. If for transmission of keys wrapped by a public Key of = the=20 receiving party we use a simple digest iof the unencrypted key material, = it=20 might open the container for brute force attacks. Since a keyvalue to = hash value=20 mapping might be much quicker to find than brute forcing=20 HMAC-SHA1

5)      =20 URIs for = KeyAlgorithm?=20

a.      =20 Fundamentally = the people=20 agreed that it is a better idea but even more than encryption and digest = algorithms, OTP algotihms do not have a defined = URI

b.      =20 Ming=20 Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he has=20 not found URIs Philip Hallam Baker will then try to find URIs or get = back to=20 authors with way to proceed

6)      =20 Philip Hoyer = proposed to=20 introduce a keyType at container level with attributes such as algorithm = and=20 logo and usage type that the key can reference (this would avoid = repeating all=20 the data for similar keys within the container) – Everyone agreed = that this was=20 a good idea but  deemed a priority 2 = item

7)      =20 Hannes to = investigate=20 what best practice is regarding URN versioning, current proposal is to = add=20 numeric version so all ietf:keyprov URN should add=20 ‘:1’

8)      =20 Should we = reorganise PBE=20 to support PKCS5 XML schema, currently this was deemed to complicate the = schema=20 too much so it was deferred for now

9)      =20 Discussion = around=20 attributes and elements, should the ASN.1 document contain the = description of=20 the attributes. Decision for ASN.1document to incorporate attribute = definition=20 of PSKC spec. Hannes to send email to the = list.

10)  =20 Discussion if = we need to=20 have a face to face meeting to align spec. Hannes asked if a set of = conference=20 calls with a precise short agenda. Would be good. Should we have a = weekly=20 conference call? Agreed to have a weekly call on Monday 3pm Central 4pm = EDT 9 pm=20 for 30 minutes

11)  =20 IV should be = moved back=20 to EncryptionMethod since it is used for symmetric algorithms and not = only for=20 PBE (Ming in his latest revision had moved it to the PBEParams=20 element)

12)  =20 Discussed = initial PIN=20 transmission, Philip invited for participants to review and agree. If no = disagreements Philip Hoyer will include in October revision of the=20 spec

 

 

 

 

________________________________

 

Philip=20 Hoyer=20

 

Senior Architect - = Office of=20 CTO

 

ActivIdentity=20 (UK)=

109 Borough High=20 Street

London SE1=20 1NL

 

Telephone: +44 (0) = 20 7744=20 6248

Direct: +44 (0) 20 = 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C81290.1150F8ED-- --===============0975776892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0975776892==-- From keyprov-bounces@ietf.org Sun Oct 21 04:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjVxA-00025Q-D8; Sun, 21 Oct 2007 04:14:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjVx8-00022m-Hd for keyprov@ietf.org; Sun, 21 Oct 2007 04:14:30 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjVwy-00081s-Vf for keyprov@ietf.org; Sun, 21 Oct 2007 04:14:21 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9L8EKni021255 for ; Sun, 21 Oct 2007 04:14:20 -0400 (EDT) Received: from rsasecurity.com (rsaeu-smtp-uk1.eu.rsa.net [10.148.48.70]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9L8EIKj016757 for ; Sun, 21 Oct 2007 04:14:19 -0400 (EDT) Received: from rsaeu-ex-uk2.eu.rsa.net (e2k.rsa.net [10.148.48.60]) by rsasecurity.com (8.13.5/8.12.9) with ESMTP id l9L849cs020232 for ; Sun, 21 Oct 2007 08:04:09 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Oct 2007 09:13:57 +0100 Message-ID: <16B9CF34A1B2E445BE9398C6FF09DF90038BF62F@rsaeu-ex-uk2.eu.rsa.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XSD "import" question thread-index: AcgTulQvgiTHWHUBRf2qR3SpnSXtRA== From: "Rundgren, Anders" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [KEYPROV] XSD "import" question X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi, The following is by no means a showstopper but may anyway be worth a considerations. Having looked around quite a bit regarding the "true" way of writing XML Schemas I have come to the conclusion that the unity is fairly limited. One thing that really differs is the declaration of XSD "import" as shown below. XKMS2: DSKPP: XKMS' import declaration refers to a non-normative local file-name which does not appear to be entirely optimal for a strict definition. DSKPP's import declaration refers to a "live" URL which may be authoritative but even if it is, few real-world systems actually read schemas on-the-fly. In fact, this would probably be a bad thing from a security-point of view. Since the majority of XML processors[1,2] in use today support the concept of preloaded schemas (the ones that you intend to process, no more, no less), it seems that the leanest and cleanest import declaration is also the most suited for contemporary security protocols like DSKPP: For the presumably rare cases where you use dated XML processors or XSD design tools, you may indeed have to edit import declarations to fit local requirements. This typically involves ugly stuff like "C:\myxml\xmldsig-core-schema.xsd" but that is something XSD designers IMHO should not bother about. Regards Anders Rundgren 1]Xerces2: java -cp xercesSamples.jar xni.XMLGrammarBuilder -F -a xmldsig-core-schema.xsd myprotocol.xsd -i myrequest.xml 2]MSXML6: var cache =3D new ActiveXObject("Msxml2.XMLSchemaCache.6.0"); cache.add("http://www.w3.org/2000/09/xmldsig#", "xmldsig-core-schema.xsd"); cache.add("http://myprot.org/schema", "myprotocol.xsd"); var xmldoc =3D new ActiveXObject("Msxml2.DOMDocument.6.0"); xmldoc.schemas =3D cache; xmldoc.setProperty ("SelectionLanguage", "XPath"); xmldoc.setProperty ("SelectionNamespaces", "xmlns:ms=3D'urn:schemas-microsoft-com:xslt'"); xmldoc.async =3D false; xmldoc.load("myrequest.xml"); =09 if(xmldoc.parseError.errorCode !=3D 0) WScript.Echo("Houston, we have a problem: " + xmldoc.parseError.errorCode + " " + xmldoc.parseError.reason); else WScript.Echo("no problems!"); _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Oct 22 04:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijt6o-0000MU-Ml; Mon, 22 Oct 2007 04:58:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijt6m-0000D2-79 for keyprov@ietf.org; Mon, 22 Oct 2007 04:58:00 -0400 Received: from frhub1.activcard.fr ([91.151.120.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijt6d-0001QT-3o for keyprov@ietf.org; Mon, 22 Oct 2007 04:57:52 -0400 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 8097E25ED3C; Mon, 22 Oct 2007 10:57:48 +0200 (CEST) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 33ML6VH4; Mon, 22 Oct 2007 11:03:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Date: Mon, 22 Oct 2007 10:56:18 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA2406@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503E36@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBCSDogAF1EkYAAfpHmcA== References: <017630AA6DF2DF4EBC1DD4454F8EE2970CE9B015@rsana-ex-hq1.NA.RSA.NET> <3E5A2F1AD44F5E49A74F79AB47C0C0C9503E36@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Philip Hoyer" To: "Pei, Mingliang" , "Doherty, Andrea" , , "Hallam-Baker, Phillip" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e38911582fe5587191bda79f22c13c42 Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1149270889==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1149270889== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81489.DD1A568E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81489.DD1A568E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ming, When you say upper case I assume you mean the first letter upper case and not all capitalized, =20 I have no objections to make this consistent between the two specs hence make them all upper case. =20 Philip =20 ________________________________ From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Friday, October 19, 2007 9:39 PM To: Doherty, Andrea; Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 =20 =20 I like to add another issue to track and resolve. =20 13) Consistent attribute name convention: upper case vs. lower case. =20 DSKPP uses upper case for all element names and attribute names. PSKC used lower case in majority attribute names, and some in upper cases. For example: =20 UsageType: =20 KeyType: =20 =20 DataType: =20 =20 For consistency, I suggest that we change them all to upper case. Comments? =20 - Ming ________________________________ From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 Sent: Wednesday, October 17, 2007 5:14 PM To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Philip, =20 Thank you for forwarding these minutes to the mailing list. =20 It is good to see progress towards use of standard XML (esp. URIs for algorithms). Toward this end, and also for alignment with DSKPP, a couple of things are needed: 1. Switch to use of ordinary XMLEnc, XMLDSig 2. Switch to use PKCS #5 XML as it makes no sense to have this in DSKPP and not in PSKC. The schema is not complex. What is being referred to as "difficult" (see #8 below)? =20 Regarding use of URIs for OTP algorithms --- why is this necessary? I know we spoke of doing this before, but stepping back a bit, isn't it really up to vendors to specify their own URIs? If vendor-specific URIs are included in the doc that should be fine since the purpose of using URIs is to allow for extensibility. =20 Andrea =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 12:23 PM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C81489.DD1A568E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ming,

When you say upper case I assume = you mean the first letter upper case and not all = capitalized,

 

I have no objections to make this consistent between the two specs hence make them all upper = case.

 

Philip

 

From: Pei, = Mingliang [mailto:mpei@verisign.com]
Sent: Friday, October 19, = 2007 9:39 PM
To: Doherty, Andrea; = Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; = shuh.chang@gemalto.com; smachani@diversinet.com
Cc: keyprov@ietf.org
Subject: RE: [KEYPROV] = IETF Keyprov PSKC meeting minutes 15/10.07

 

 

I like to add another issue to = track and resolve.

 

13) Consistent attribute name = convention: upper case vs. lower case.

 

DSKPP uses upper case for all = element names and attribute names. PSKC used lower case in majority attribute = names, and some in upper cases. For example:

 

UsageType:<= /p>

 

    <attribute name=3D"otp" type=3D"boolean"
            &= nbsp;  default=3D"false"/>
    <attribute name=3D"cr" = type=3D"boolean"
            &= nbsp;  default=3D"false"/>
    <attribute name=3D"sign" = type=3D"boolean"
            &= nbsp;  default=3D"false"/>
    <attribute name=3D"encrypt" type=3D"boolean"
            &= nbsp;  default=3D"false"/>
    <attribute name=3D"unlock" type=3D"boolean"
            &= nbsp;  default=3D"false"/>

KeyType:

 

<attribute = name=3D"KeyId" type=3D"string" = use=3D"required"/>

 

DataType:

 

    <attribute name=3D"Name" type=3D"string"
            &= nbsp;  use=3D"required"/>

 

For consistency, I suggest that we = change them all to upper case. Comments?

 

- Ming

From: Doherty, Andrea [mailto:adoherty@rsa.com]
Sent: Wednesday, October = 17, 2007 5:14 PM
To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com
Cc: keyprov@ietf.org
Subject: RE: [KEYPROV] = IETF Keyprov PSKC meeting minutes 15/10.07

Philip,

=

 

Thank you for forwarding these = minutes to the mailing list.

 

It is good to see progress towards = use of standard XML (esp. URIs for algorithms).  Toward this end, and also = for alignment with DSKPP, a couple of things are = needed:

1. Switch to use of ordinary = XMLEnc, XMLDSig

2. Switch to use PKCS #5 XML as it = makes no sense to have this in DSKPP and not in PSKC.  The schema is not complex.  What is being referred to as "difficult" (see = #8 below)?

 

Regarding use of URIs for OTP = algorithms --- why is this necessary?  I know we spoke of doing this before, = but stepping back a bit, isn't it really up to vendors to specify their own URIs?  If vendor-specific URIs are included in the doc that should = be fine since the purpose of using URIs is to allow for = extensibility.

 

Andrea

 

From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, October = 16, 2007 12:23 PM
To: = Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com
Cc: keyprov@ietf.org
Subject: [KEYPROV] IETF = Keyprov PSKC meeting minutes 15/10.07

Attendees:

Philip Hoyer, Ming Pei, Shuh Chang, Salah = Macchani, Phillip Hallam-Baker, Hannes Tschofenig

 

 

 

1)       Initially decided to tackle the issue of algorithms = that are represented as enumerations in PSKC and if we should go to a URI based = approach that allows for easier extension. There are 3 type of algorithm = definitions in PSKC

a.       EncryptionAlgorithm of the key material in the = container

b.       DigestAlgorithm to create a digest of the = uncencrypted keys

c.       OTP Algorithm, identifier of the algorithm that the = key is being used with

2)       Agreed to change EncryptionAlgorithm and = DigestAlgorithm to change to URI

3)       Ming Pei to change schema and add minimum list of URIs

a.       Issue, what about PBE related algorithms, no URIs = found by Ming

b.       Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for = which he has not found URIs. Philip Hallam Baker will then try to find URIs or = get back to authors with way to proceed

4)       Discussion about digest of the key for RSA encrypted = keys – Ming, Shuh to check if it is a bad idea – Philip to ask to = the list

a.       The problem here is that the Digest used for = symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If = for transmission of keys wrapped by a public Key of the receiving party we = use a simple digest iof the unencrypted key material, it might open the = container for brute force attacks. Since a keyvalue to hash value mapping might be = much quicker to find than brute forcing = HMAC-SHA1

5)       URIs for KeyAlgorithm?

a.       Fundamentally the people agreed that it is a better = idea but even more than encryption and digest algorithms, OTP algotihms do not = have a defined URI

b.       Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for = which he has not found URIs Philip Hallam Baker will then try to find URIs or get = back to authors with way to proceed

6)       Philip Hoyer proposed to introduce a keyType at = container level with attributes such as algorithm and logo and usage type that the = key can reference (this would avoid repeating all the data for similar keys = within the container) – Everyone agreed that this was a good idea but  deemed a priority 2 item

7)       Hannes to investigate what best practice is regarding = URN versioning, current proposal is to add numeric version so all = ietf:keyprov URN should add ‘:1’

8)       Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was = deferred for now

9)       Discussion around attributes and elements, should the = ASN.1 document contain the description of the attributes. Decision for = ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email = to the list.

10)   = Discussion if we need to have a face to face meeting to align spec. Hannes asked if = a set of conference calls with a precise short agenda. Would be good. Should = we have a weekly conference call? Agreed to have a weekly call on Monday 3pm = Central 4pm EDT 9 pm for 30 minutes

11)   = IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved = it to the PBEParams element)

12)   = Discussed initial PIN transmission, Philip invited for participants to review and = agree. If no disagreements Philip Hoyer will include in October revision of the = spec

 

 

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C81489.DD1A568E-- --===============1149270889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1149270889==-- From keyprov-bounces@ietf.org Mon Oct 22 13:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1YS-00081o-Cu; Mon, 22 Oct 2007 13:59:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1YP-0007WR-MI for keyprov@ietf.org; Mon, 22 Oct 2007 13:59:05 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik1Xf-0006CK-Hx for keyprov@ietf.org; Mon, 22 Oct 2007 13:58:20 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9MHsjZx008792; Mon, 22 Oct 2007 10:54:45 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 18:57:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Date: Mon, 22 Oct 2007 10:57:09 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9503EE1@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA2406@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Thread-Index: AcgQEM363UxQ/ImwTTGneX03cbyhDgBCSDogAF1EkYAAfpHmcAASznZQ From: "Pei, Mingliang" To: "Philip Hoyer" , "Doherty, Andrea" , , "Hallam-Baker, Phillip" , , X-OriginalArrivalTime: 22 Oct 2007 17:57:45.0482 (UTC) FILETIME=[0CC3FEA0:01C814D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea98052f75c8682673c96267a0eea7de Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936031666==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1936031666== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C814D5.0CD61C5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C814D5.0CD61C5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Philip, =20 Right, we want to capitalize the first letter: version -> Version etc.. Some attribute word is better to be entirely changed upper case though, e.g., cr to CR instead of Cr and otp to OTP instead of Otp. =20 I will make changes in schema file, and send out for review. =20 - Ming ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Monday, October 22, 2007 1:56 AM To: Pei, Mingliang; Doherty, Andrea; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Ming, When you say upper case I assume you mean the first letter upper case and not all capitalized, =20 I have no objections to make this consistent between the two specs hence make them all upper case. =20 Philip =20 ________________________________ From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Friday, October 19, 2007 9:39 PM To: Doherty, Andrea; Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 =20 =20 I like to add another issue to track and resolve. =20 13) Consistent attribute name convention: upper case vs. lower case. =20 DSKPP uses upper case for all element names and attribute names. PSKC used lower case in majority attribute names, and some in upper cases. For example: =20 UsageType: =20 KeyType: =20 =20 DataType: =20 =20 For consistency, I suggest that we change them all to upper case. Comments? =20 - Ming ________________________________ From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 Sent: Wednesday, October 17, 2007 5:14 PM To: Philip Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Philip, =20 Thank you for forwarding these minutes to the mailing list. =20 It is good to see progress towards use of standard XML (esp. URIs for algorithms). Toward this end, and also for alignment with DSKPP, a couple of things are needed: 1. Switch to use of ordinary XMLEnc, XMLDSig 2. Switch to use PKCS #5 XML as it makes no sense to have this in DSKPP and not in PSKC. The schema is not complex. What is being referred to as "difficult" (see #8 below)? =20 Regarding use of URIs for OTP algorithms --- why is this necessary? I know we spoke of doing this before, but stepping back a bit, isn't it really up to vendors to specify their own URIs? If vendor-specific URIs are included in the doc that should be fine since the purpose of using URIs is to allow for extensibility. =20 Andrea =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, October 16, 2007 12:23 PM To: Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang; shuh.chang@gemalto.com; smachani@diversinet.com Cc: keyprov@ietf.org Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07 Attendees:=20 Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip Hallam-Baker, Hannes Tschofenig =20 =20 =20 1) Initially decided to tackle the issue of algorithms that are represented as enumerations in PSKC and if we should go to a URI based approach that allows for easier extension. There are 3 type of algorithm definitions in PSKC a. EncryptionAlgorithm of the key material in the container b. DigestAlgorithm to create a digest of the uncencrypted keys c. OTP Algorithm, identifier of the algorithm that the key is being used with 2) Agreed to change EncryptionAlgorithm and DigestAlgorithm to change to URI 3) Ming Pei to change schema and add minimum list of URIs=20 a. Issue, what about PBE related algorithms, no URIs found by Ming b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs. Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 4) Discussion about digest of the key for RSA encrypted keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the list a. The problem here is that the Digest used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If for transmission of keys wrapped by a public Key of the receiving party we use a simple digest iof the unencrypted key material, it might open the container for brute force attacks. Since a keyvalue to hash value mapping might be much quicker to find than brute forcing HMAC-SHA1 5) URIs for KeyAlgorithm?=20 a. Fundamentally the people agreed that it is a better idea but even more than encryption and digest algorithms, OTP algotihms do not have a defined URI b. Ming Pei to send Phillip Hallam Baker and to mailing list the list of algorithms for which he has not found URIs Philip Hallam Baker will then try to find URIs or get back to authors with way to proceed 6) Philip Hoyer proposed to introduce a keyType at container level with attributes such as algorithm and logo and usage type that the key can reference (this would avoid repeating all the data for similar keys within the container) - Everyone agreed that this was a good idea but deemed a priority 2 item 7) Hannes to investigate what best practice is regarding URN versioning, current proposal is to add numeric version so all ietf:keyprov URN should add ':1' 8) Should we reorganise PBE to support PKCS5 XML schema, currently this was deemed to complicate the schema too much so it was deferred for now=20 9) Discussion around attributes and elements, should the ASN.1 document contain the description of the attributes. Decision for ASN.1document to incorporate attribute definition of PSKC spec. Hannes to send email to the list. 10) Discussion if we need to have a face to face meeting to align spec. Hannes asked if a set of conference calls with a precise short agenda. Would be good. Should we have a weekly conference call? Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes 11) IV should be moved back to EncryptionMethod since it is used for symmetric algorithms and not only for PBE (Ming in his latest revision had moved it to the PBEParams element) 12) Discussed initial PIN transmission, Philip invited for participants to review and agree. If no disagreements Philip Hoyer will include in October revision of the spec =20 =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C814D5.0CD61C5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Philip,
 
Right, we want to capitalize the first letter: = version=20 -> Version etc.. Some attribute word is better to be entirely changed = upper=20 case though, e.g., cr to CR instead of Cr and otp to OTP instead of=20 Otp.
 
I will make changes in schema file, and send = out for=20 review.
 
- Ming

From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Monday, October = 22,=20 2007 1:56 AM
To: Pei, Mingliang; Doherty, Andrea;=20 Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; = shuh.chang@gemalto.com;=20 smachani@diversinet.com
Cc: = keyprov@ietf.org
Subject: RE:=20 [KEYPROV] IETF Keyprov PSKC meeting minutes = 15/10.07

Ming,

When you say = upper case=20 I assume you mean the first letter upper case and not all=20 capitalized,

 

I have no = objections to=20 make this consistent between the two specs hence make them all upper=20 case.

 

Philip

 

From: Pei,=20 Mingliang [mailto:mpei@verisign.com]
Sent: Friday, October 19, 2007 = 9:39=20 PM
To: Doherty, = Andrea; Philip=20 Hoyer; Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; = shuh.chang@gemalto.com;=20 smachani@diversinet.com
Cc:=20 keyprov@ietf.org
Subject: RE:=20 [KEYPROV] IETF Keyprov PSKC meeting minutes=20 15/10.07

 

 

I like to add = another=20 issue to track and resolve.

 

13) = Consistent=20 attribute name convention: upper case vs. lower=20 case.

 

DSKPP uses = upper case=20 for all element names and attribute names. PSKC used lower case in = majority=20 attribute names, and some in upper cases. For=20 example:

 

UsageType:

 

   =20 <attribute name=3D"otp"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute name=3D"cr"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute name=3D"sign" = type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute = name=3D"encrypt"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>
    <attribute = name=3D"unlock"=20 type=3D"boolean"
         = ;     =20 default=3D"false"/>

KeyType:

 

<attribute = name=3D"KeyId" type=3D"string" = use=3D"required"/>

 

DataType:

 

   =20 <attribute name=3D"Name"=20 type=3D"string"
         =      =20 use=3D"required"/>

 

For = consistency, I=20 suggest that we change them all to upper case.=20 Comments?

 

-=20 Ming

From: Doherty,=20 Andrea [mailto:adoherty@rsa.com]
Sent: Wednesday, October 17, 2007 = 5:14=20 PM
To: Philip Hoyer;=20 Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang;=20 shuh.chang@gemalto.com; smachani@diversinet.com
Cc: keyprov@ietf.org
Subject: RE: [KEYPROV] IETF = Keyprov PSKC=20 meeting minutes 15/10.07

Philip,

 

Thank you for = forwarding these minutes to the mailing = list.

 

It is good to = see=20 progress towards use of standard XML (esp. URIs for algorithms).  = Toward=20 this end, and also for alignment with DSKPP, a couple of things are = needed:

1. Switch to = use of=20 ordinary XMLEnc, XMLDSig

2. Switch to = use PKCS=20 #5 XML as it makes no sense to have this in DSKPP and not in PSKC.  = The=20 schema is not complex.  What is being referred to as "difficult" = (see #8=20 below)?

 

Regarding use = of URIs=20 for OTP algorithms --- why is this necessary?  I know we spoke of = doing=20 this before, but stepping back a bit, isn't it really up to vendors to = specify=20 their own URIs?  If vendor-specific URIs are included in the doc = that=20 should be fine since the purpose of using URIs is to allow for=20 extensibility.

 

Andrea

 

From: Philip=20 Hoyer [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, October 16, 2007 = 12:23=20 PM
To:=20 Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Pei, Mingliang;=20 shuh.chang@gemalto.com; smachani@diversinet.com
Cc: keyprov@ietf.org
Subject: [KEYPROV] IETF Keyprov = PSKC=20 meeting minutes 15/10.07

Attendees:=20

Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, = Phillip=20 Hallam-Baker, Hannes Tschofenig

 

 

 

1)      =20 Initially decided to = tackle the=20 issue of algorithms that are represented as enumerations in PSKC and if = we=20 should go to a URI based approach that allows for easier extension. = There are 3=20 type of algorithm definitions in PSKC

a.      =20 EncryptionAlgorithm of the = key=20 material in the container

b.      =20 DigestAlgorithm to create = a digest=20 of the uncencrypted keys

c.      =20 OTP Algorithm, identifier = of the=20 algorithm that the key is being used with

2)      =20 Agreed to change = EncryptionAlgorithm=20 and DigestAlgorithm to change to URI

3)      =20 Ming=20 Pei to change=20 schema and add minimum list of URIs

a.      =20 Issue, what about PBE = related=20 algorithms, no URIs found by Ming

b.      =20 Ming=20 Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he has=20 not found URIs. Philip Hallam Baker will then try to find URIs or get = back to=20 authors with way to proceed

4)      =20 Discussion about digest of = the key=20 for RSA encrypted keys – Ming, Shuh to check if it is a bad idea = – Philip to ask=20 to the list

a.      =20 The problem here is that = the Digest=20 used for symmetric algorithms is a keyed digest eg HMAC-SHA1 which is = still not=20 broken. If for transmission of keys wrapped by a public Key of the = receiving=20 party we use a simple digest iof the unencrypted key material, it might = open the=20 container for brute force attacks. Since a keyvalue to hash value = mapping might=20 be much quicker to find than brute forcing=20 HMAC-SHA1

5)      =20 URIs for KeyAlgorithm?=20

a.      =20 Fundamentally the people = agreed that=20 it is a better idea but even more than encryption and digest algorithms, = OTP=20 algotihms do not have a defined URI

b.      =20 Ming=20 Pei to send=20 Phillip Hallam Baker and to mailing list the list of algorithms for = which he has=20 not found URIs Philip Hallam Baker will then try to find URIs or get = back to=20 authors with way to proceed

6)      =20 Philip Hoyer proposed to = introduce a=20 keyType at container level with attributes such as algorithm and logo = and usage=20 type that the key can reference (this would avoid repeating all the data = for=20 similar keys within the container) – Everyone agreed that this was = a good idea=20 but  deemed a priority 2 item

7)      =20 Hannes to investigate what = best=20 practice is regarding URN versioning, current proposal is to add numeric = version=20 so all ietf:keyprov URN should add = ‘:1’

8)      =20 Should we reorganise PBE = to support=20 PKCS5 XML schema, currently this was deemed to complicate the schema too = much so=20 it was deferred for now

9)      =20 Discussion around = attributes and=20 elements, should the ASN.1 document contain the description of the = attributes.=20 Decision for ASN.1document to incorporate attribute definition of PSKC = spec.=20 Hannes to send email to the list.

10)   Discussion=20 if we need to have a face to face meeting to align spec. Hannes asked if = a set=20 of conference calls with a precise short agenda. Would be good. Should = we have a=20 weekly conference call? Agreed to have a weekly call on Monday 3pm = Central 4pm=20 EDT 9 pm for 30 minutes

11)   IV should be=20 moved back to EncryptionMethod since it is used for symmetric algorithms = and not=20 only for PBE (Ming in his latest revision had moved it to the PBEParams=20 element)

12)   Discussed=20 initial PIN transmission, Philip invited for participants to review and = agree.=20 If no disagreements Philip Hoyer will include in October revision of the = spec

 

 

 

 

________________________________

 

Philip=20 Hoyer=20

 

Senior Architect - = Office of=20 CTO

 

ActivIdentity = (UK)=

109 Borough High=20 Street

London SE1=20 1NL

 

Telephone: +44 (0) = 20 7744=20 6248

Direct: +44 (0) 20 = 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C814D5.0CD61C5F-- --===============1936031666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1936031666==-- From keyprov-bounces@ietf.org Sat Oct 27 16:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ils1T-0001U5-Ul; Sat, 27 Oct 2007 16:12:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ils1T-0000wr-9i for keyprov@ietf.org; Sat, 27 Oct 2007 16:12:43 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ils1G-0006Yi-GV for keyprov@ietf.org; Sat, 27 Oct 2007 16:12:30 -0400 Received: (qmail invoked by alias); 27 Oct 2007 20:12:28 -0000 Received: from p54987B57.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.123.87] by mail.gmx.net (mp016) with SMTP; 27 Oct 2007 22:12:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/0P9pe4h/HJsL/L0VZtFjayzb7dPuaxiZR6aHUo JxKidD1InrnKVx Message-ID: <47239BAD.7010502@gmx.net> Date: Sat, 27 Oct 2007 22:12:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [KEYPROV] Chat @ IETF#70 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi all, I am going to be in Vancouver for the next IETF meeting already on Friday. I wonder whether someone from the KEYPROV group arrives earlier as well and is available for a chat (e.g, about the progress of the work or on the technical aspects of the specifications). Please drop me a note if you arrive earlier and in case you are interested. Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Oct 29 13:21:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYII-0008RA-Ek; Mon, 29 Oct 2007 13:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYID-0008Pp-SC; Mon, 29 Oct 2007 13:20:49 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImYHR-0002qX-VU; Mon, 29 Oct 2007 13:20:49 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D95FE328FA; Mon, 29 Oct 2007 17:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ImYHR-0007y8-PT; Mon, 29 Oct 2007 13:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 29 Oct 2007 13:20:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: keyprov@ietf.org Subject: [KEYPROV] I-D Action:draft-ietf-keyprov-dskpp-01.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning of Symmetric Keys Working Group of the IETF. Title : Dynamic Symmetric Key Provisioning Protocol (DSKPP) Author(s) : A. Doherty, et al. Filename : draft-ietf-keyprov-dskpp-01.txt Pages : 106 Date : 2007-10-29 DSKPP is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private-key capabilities in the cryptographic modules, and with or without an established public-key infrastructure. Three variations of the protocol support multiple usage scenarios. The four-pass (i.e., two round-trip) variant enables key generation in near real-time. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. Two- and one-pass variants enable secure and efficient download and installation of symmetric keys to a cryptographic module in environments where near real-time communication may not be possible. This document builds on information contained in [RFC4758], adding specific enhancements in response to implementation experience and liaison requests. It is intended, therefore, that this document or a successor version thereto will become the basis for subsequent progression of a symmetric key provisioning protocol specification on the standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-keyprov-dskpp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-keyprov-dskpp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-29131930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-keyprov-dskpp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-keyprov-dskpp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-29131930.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --NextPart-- From keyprov-bounces@ietf.org Mon Oct 29 13:30:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYR7-0008H0-Gw; Mon, 29 Oct 2007 13:30:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYHU-0008AN-FC for keyprov@ietf.org; Mon, 29 Oct 2007 13:20:04 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImYHU-00029l-64 for keyprov@ietf.org; Mon, 29 Oct 2007 13:20:04 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 2271C2AC79; Mon, 29 Oct 2007 17:19:34 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1ImYGz-0007HT-Sl; Mon, 29 Oct 2007 13:19:33 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: adoherty@rsa.com From: IETF I-D Submission Tool Message-Id: Date: Mon, 29 Oct 2007 13:19:33 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Mon, 29 Oct 2007 13:30:00 -0400 Cc: mnystrom@rsa.com, keyprov@ietf.org Subject: [KEYPROV] New Version Notification for draft-ietf-keyprov-dskpp-01 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org A new version of I-D, draft-ietf-keyprov-dskpp-01.txt has been successfuly submitted by Andrea Doherty and posted to the IETF repository. Filename: draft-ietf-keyprov-dskpp Revision: 01 Title: Dynamic Symmetric Key Provisioning Protocol (DSKPP) Creation_date: 2007-10-29 WG ID: keyprov Number_of_pages: 106 Abstract: DSKPP is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private-key capabilities in the cryptographic modules, and with or without an established public-key infrastructure. Three variations of the protocol support multiple usage scenarios. The four-pass (i.e., two round-trip) variant enables key generation in near real-time. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. Two- and one-pass variants enable secure and efficient download and installation of symmetric keys to a cryptographic module in environments where near real-time communication may not be possible. This document builds on information contained in [RFC4758], adding specific enhancements in response to implementation experience and liaison requests. It is intended, therefore, that this document or a successor version thereto will become the basis for subsequent progression of a symmetric key provisioning protocol specification on the standards track. The IETF Secretariat. _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov