From owner-saag  Tue Jan  9 11:45:49 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21966
	Tue, 9 Jan 2001 11:43:21 -0500 (EST)
X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI]
From: Steve Bellovin <smb@research.att.com>
To: saag@lists.tislabs.com
Subject: Update on NIST crypto standards (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 09 Jan 2001 11:45:42 -0500
Message-Id: <20010109164542.9822D35DC2@smb.research.att.com>
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

Forwarded with permission.  There is also going to be an announcement 
within the next month on NIST's plans for new modes of operations; watch
http://csrc.nist.gov/encryption/tkmodes.html for details.


------- Forwarded Message


Date: Mon, 08 Jan 2001 13:20:18 -0500
To: jfoti@nist.gov
From: Jim Foti <jfoti@nist.gov>
Subject: Update on NIST crypto standards
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-UIDL: 70f288237482be01d5331b60aec89937

Hello-

Here is a brief update on NIST's crypto standards efforts:

1.  On January 5, 2001, we announced a Draft FIPS for HMAC (Keyed-Hash 
Message Authentication Code) that is a generalization of HMAC as specified 
in Internet RFC 2104 and ANSI X9.71.  A 90-day public comment period ends 
April 5, 2001.  Details are available at <http://www.nist.gov/hmac>.

2.  On January 2, 2001, we posted a white paper that discusses our plans 
for developing standards and recommendations for public key-based key 
management.  This will be a two-part process, involving the development of 
1) a scheme definition document, and 2) a key management guideline.  This 
paper is available at <http://www.nist.gov/kms>.

3.  The Draft FIPS for the AES is anticipated for release for public review 
in the very near future.  Final approvals for the release of this document 
are pending.  When an announcement is made, information on the draft and 
for providing public comments will be available at <http://www.nist.gov/aes>.

Best regards and Happy New Year,

Jim

[This note is being sent to those people who have attended any of NIST's 
AES conferences, the Key Management Standard (KMS) workshop in February 
2000, the Modes of Operation workshop in October 2000, or who have 
expressed other interest in our efforts.  If you would not like to receive 
similar notices in the future (which should be infrequent), please let me 
know, and we will remove you from our email distribution list.]

*******************************************************************
Jim Foti

Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD  20899-8930
USA

TEL: (301) 975-5237
FAX: (301) 948-1233
jfoti@nist.gov
*******************************************************************



------- End of Forwarded Message



		--Steve Bellovin



From owner-saag  Tue Jan 30 09:55:43 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00337
	Tue, 30 Jan 2001 09:54:48 -0500 (EST)
Message-ID: <73FC40B85BD7044FA81AA836548A880308D3DC@matrix.ntdomain.com>
From: Kathleen Hastings <KHastings@tmcnet.com>
Subject: Speaking Opp at Internet Telephony Conference & Expo
Date: Mon, 29 Jan 2001 16:40:09 -0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

Good Afternoon.

Please allow me to introduce myself as the Conference Manger for Internet
Telephony Conference & Expo, February 7-9, Hotel Inter-Continental, Miami.
I have had a last-minute speaker cancellation in our conference program and
was wondering if you would be interested in presenting at the following
session:

Wednesday, February 7th, 3:45-4:45pm
Lockdown: Addressing Security Issues for IP Telephony (PC3-6)
Network managers and users alike consider traditional telephone calls highly
secure. As calls move from circuit-switched networks to packet-switched
networks, we must make sure to take precautions. Threats include
eavesdropping on confidential calls, hijacking of system resources and more.
Precautions must apply whether calls travel over the Internet or an
Intranet. This session looks at authentication, which applies to packet
headers, as well as encryption, which applies to packet payloads. Topics
discussed will include security mechanisms such as IPSec, DES/Triple DES,
PGP, and others.

Speakers are required to provide a PowerPoint presentation as well as
handouts for the audience.  In addition, please note that this session is
intended to be strictly non-commercial.

If you are interested in participating, please forward a proposed speaker
bio to me ASAP and we will "officially" confirm.  Further details on the
show can be found on our Web site at http://www.tmcnet.com.  Of course, feel
free to contact me as well.

I look forward to hearing from you.

Regards.

Kathleen Hastings
Conference Manager


NEW! 
-------------------------------------------------------------
Subscribe Free to Communications ASP Magazine:
<http://www.communicationsasp.com/>
-------------------------------------------------------------
See you at:
INTERNET TELEPHONY Conference & EXPO, Feb 7-9, Miami, FL 
<http://www.tmcnet.com/itexpo/>
Communications SOLUTIONS EXPO, May 23-25, 2001, Washington. D.C.
<http://www.tmcnet.com/comsolexpo/> 
Subscribe FREE to TMC's industry-leading publications and eNewsletters:
<http://www.tmcnet.com/scripts/magsub/fmag.asp>

Kathleen Hastings, Conference Manager
TMC
One Technology Plaza 
Norwalk, CT 06854 
203-852-6800 x271   khastings@tmcnet.com
TMC: "We've Got Communications Covered"
http://www.tmcnet.com

From owner-saag  Mon Feb 12 10:22:09 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18262
	Mon, 12 Feb 2001 10:21:42 -0500 (EST)
Content-return: allowed
Date: Mon, 12 Feb 2001 08:02:28 -0500
From: "Chalmers, Matthew (FUSA)" <MatthewChalmers@FirstUSA.com>
Subject: ietf security area list
To: "'saag@lists.tislabs.com'" <saag@lists.tislabs.com>
Cc: "'majordomo-owner@ietf.org'" <majordomo-owner@ietf.org>
Message-id: <D1BDE7E657E9D311AD3D00A0C9B42699020C3A62@swilnts801.wil.fusa.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

I'd like to know if there's a general discussion or announcement list I can
join for the IETF Security Area WG. I can only find info online about the
sub-groups like OpenPGP, etc. I tried writing to Jeffrey Schiller and
haven't gotten a response yet, and also tried sending the 'lists' command to
<majordomo@imc.org> and <majordomo@ietf.org> and an email to
<majordomo-owner@imc.org>. I'd really like to be able to contribute to
general security discussion; please point me in the right direction. Thanks.


Matthew Chalmers
CCO, Information Security
FIRST USA BANK, NA



From owner-saag  Mon Feb 12 17:09:34 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19560
	Mon, 12 Feb 2001 17:09:09 -0500 (EST)
Message-Id: <200102122212.OAA02185@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Re: ietf security area list 
To: "Chalmers, Matthew (FUSA)" <MatthewChalmers@firstusa.com>
cc: saag@lists.tislabs.com
In-reply-to: "Chalmers, Matthew (FUSA)" <MatthewChalmers@FirstUSA.com> 's 
 message of
	Mon, 12 Feb 2001 08:02:28 -0500
Reply-to: Jeff.Hodges@KingsMountain.com
From: Jeff.Hodges@KingsMountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Feb 2001 14:12:11 -0800
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

MatthewChalmers@FirstUSA.com said:
> I'd like to know if there's a general discussion or announcement list
> I can join for the IETF Security Area WG ... I'd really like to be able to 
> contribute to general security discussion; please point me in the right
> direction.

You've found the correct list -- saag@lists.tislabs.com. Many of us, 
especially apps-oriented folks, would like to see more overall discussion of 
security mechanisms and their applications here.

I myself only by chance stumbled across this list a while back (via the 
Security Area web page). AFAIK, it's existence & purpose have never been 
advertised elsewhere.

JeffH



From owner-saag  Mon Feb 26 07:52:07 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14578
	Mon, 26 Feb 2001 07:50:45 -0500 (EST)
Date: Sun, 25 Feb 2001 21:51:50 +0200
From: Keith Burdis <keith@rucus.ru.ac.za>
To: ietf-sasl@imc.org, saag@lists.tislabs.com
Subject: HTTP over SASL
Message-ID: <20010225215150.A51335@rucus.ru.ac.za>
Mail-Followup-To: Keith Burdis <keith@rucus.ru.ac.za>, ietf-sasl@imc.org,
	saag@lists.tislabs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

Hi there

Magnus Nystrom and Robert Zuccherato have submitted a proposal for using 
SASL with HTTP (draft-nystrom-http-sasl-00).

I have an alternative proposal based on RFC 2817 "Upgrading to TLS Within
HTTP/1.1".

RFC 2817 describes a means of using TLS with HTTP by upgrading to TLS from
within HTTP.  The advantage of this is that a separate port is not required
for a secure connection.  Once the upgrade is initiated the TLS protocol
starts.  If TLS authentication is successful, a secure connection is
established and subsequent HTTP messages are tunnelled through this
connection.
	        
The same procedure can be used with SASL.  An HTTP client and server
negotiate an upgrade to an SASL mechanism.  Once the upgrade is initiated,
the SASL mechanism protocol starts.  If the authentication procedure using
this mechanism is successful, subsequent HTTP messages are tunnelled through
this SASL connection.  If a security layer was negotiated as part of the
SASL mechanism exchange then it is used to protect any messages passing
through the connection, otherwise the messages are passed through unchanged.

The benefit of tunnelling HTTP through an SASL connection, rather than
making the SASL exchange part of HTTP, is that the TCP connection is
protected.  This means that the entire HTTP message is protected when
transmitted along this connection rather than just the HTTP body. Also, as
with TLS, once the upgrade has taken place, the HTTP protocol exchanges
continue unaware that they are being protected.

A copy of the full proposal is available at:

   http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.html
   http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.txt

Any comments are welcome.

Thanks.

   - Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras					JAPH 	QEFH
---


From owner-saag  Mon Mar 26 03:05:53 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29558
	Mon, 26 Mar 2001 03:05:36 -0500 (EST)
Message-Id: <200103260728.XAA17067@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: fyi: PGP attack specs [english]
To: ietf-openpgp@imc.org
Reply-to: ietf-openpgp@imc.org
From: Jeff.Hodges@KingsMountain.com
Mime-Version: 1.0
Date: Sun, 25 Mar 2001 23:28:41 -0800
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Type: text/plain; charset=us-ascii
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

------- Forwarded Message

Date: Sun, 25 Mar 2001 18:13:27 +0100
To: ukcrypto@chiark.greenend.org.uk
From: Donald ramsbottom <donald@ramsbottom.co.uk>
Subject: PGP attack specs

Via Cryptome, below is the URL for the tech specs on the PGP attack



http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf



Donald Ramsbottom BA LLb (Hons) PGdip
Ramsbottom & Co Solicitors
Internet and Global Encryption Law Specialists & General UK  Law Matters
5 Seagrove Avenue Hayling Island Hampshire UK
Tel (44) 023 9246 5931 Fax (44) 023 9246 8349
Regulated by the Law Society in the conduct of Investment business
Service by Fax or Email NOT accepted



------- End of Forwarded Message




From owner-saag  Wed Apr  4 09:28:37 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03887
	Wed, 4 Apr 2001 09:28:12 -0400 (EDT)
Message-ID: <0001EAFF884AD411ADF800508B4485CF01A9F548@AMG2>
From: Kirstie Hitchcock <Kirstie.Hitchcock@alexmann.com>
To: "'saag@lists.tislabs.com'" <saag@lists.tislabs.com>
Subject: re: security specialists
Date: Wed, 4 Apr 2001 12:04:43 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0BCF7.0D69B7B0"
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0BCF7.0D69B7B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello
I am just writing to see if you can be of any help to me. I am currently
recruiting for one of the big 5 consultancies in London and they currently
have a position available for a security manager - the focus of work
initially being on a huge new internet project which will take my client to
the leading edge of internet security. As I'm sure you are aware candidates
like this are like golddust at the moment and I would appreciate any help
you can give me - either a name of someone that you know may be interested
or perhaps if you advertise vacancies to your members - I could place an
advert.
Thank you very much for your time and I hope to hear from you soon
thanks and regards

Kirstie Hitchcock
Account Manager
Alexander Mann Solutions
ddi:0207 984 4262
mobile: 07957 571 119
kirstie.hitchcock@alexmann.com


------_=_NextPart_001_01C0BCF7.0D69B7B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>re: security specialists</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I am just writing to see if you can =
be of any help to me. I am currently recruiting for one of the big 5 =
consultancies in London and they currently have a position available =
for a security manager - the focus of work initially being on a huge =
new internet project which will take my client to the leading edge of =
internet security. As I'm sure you are aware candidates like this are =
like golddust at the moment and I would appreciate any help you can =
give me - either a name of someone that you know may be interested or =
perhaps if you advertise vacancies to your members - I could place an =
advert.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you very much for your time and =
I hope to hear from you soon</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">thanks and regards</FONT>
</P>

<P><I><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Kirstie =
Hitchcock</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Account Manager</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Alexander Mann =
Solutions</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Comic Sans MS">ddi:0207 984 =
4262</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Comic Sans MS">mobile: 07957 571 =
119</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Comic Sans =
MS">kirstie.hitchcock@alexmann.com</FONT></I>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0BCF7.0D69B7B0--

From owner-saag  Fri Apr 13 02:32:32 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA04823
	Fri, 13 Apr 2001 02:32:09 -0400 (EDT)
Message-Id: <200104130636.XAA00165@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: available: Security Design for Application Protocols
To: discuss@apps.ietf.org
cc: saag@lists.tislabs.com,
        Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        ned.freed@innosoft.com
From: Jeff.Hodges@KingsMountain.com
Reply-to: discuss@apps.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 12 Apr 2001 23:36:36 -0700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id CAA04820
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

My extemporaneous talk on "Security Design for Application Protocols" at the 
Apps Area session at the 50th IETF (Minneapolis) is now available here in 
.html & .pdf formats (URLs folded; the .pdf is the easier to deal with and use 
imho)..

http://www.stanford.edu/~hodges/talks
 /Hodges-SecurityDesignForAppProtocols-2001-04-10.pdf

 /Hodges-SecurityDesignForAppProtocols-2001-04-10.html

I'm working on getting the .ppt source file up there on my website and hope to 
have there in the next few days.

thanks,

JeffH



From owner-saag  Wed Apr 18 11:50:04 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27103
	Wed, 18 Apr 2001 11:49:12 -0400 (EDT)
Message-ID: <6F303E756050D3119C4C0008C7917D0004C0C1E5@zbl6c000.corpeast.baynetworks.com>
From: "Jing Xiang" <jxiang@nortelnetworks.com>
To: saag@lists.tislabs.com
Subject: draft-ietf-saag-aes-ciph-00.txt
Date: Tue, 17 Apr 2001 13:47:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C77F.A6352A50"
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0C77F.A6352A50
Content-Type: text/plain;
	charset="iso-8859-1"

Since the above document expires Jan 2000 & with the selection of Rijndael
as AES, are there any new updates?
Thanks!

------_=_NextPart_001_01C0C77F.A6352A50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>draft-ietf-saag-aes-ciph-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Since the above document expires Jan =
2000 &amp; with the selection of Rijndael as AES, are there any new =
updates?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks!</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C77F.A6352A50--

From owner-saag  Wed Apr 25 11:05:21 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00346
	Wed, 25 Apr 2001 11:04:57 -0400 (EDT)
From: "Tim Moors" <moors@ieee.org>
To: <saag@lists.tislabs.com>
Subject: Record of "How to Secure a Protocol" from IETF 49
Date: Wed, 25 Apr 2001 09:03:27 -0400
Message-ID: <NDBBKKDDOKHDNCFOLOIFMEGADBAA.moors@ieee.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

Is there any record of the "How to Secure a Protocol" tutorial from IETF 49
(e.g. video recording or slides)?  I couldn't find anything in the
Proceedings (http://www.ietf.org/proceedings/00dec/index.html), video
archives (http://videolab.uoregon.edu/events/ietf/ietf49.html), Security
Area Web Page (http://web.mit.edu/network/ietf/sa/), or standard web
searches.

Thanks in advance for your help.


Tim Moors
___________________________________
Web: http://uluru.poly.edu/~tmoors/



From owner-saag  Tue May  1 02:13:50 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01988
	Tue, 1 May 2001 02:13:25 -0400 (EDT)
Message-Id: <200105010618.XAA08030@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: fyi: NTT/Mitsubishi release Camilla, ESIGN, EPOC
To: Security Area Advisory Group <saag@lists.tislabs.com>
Reply-to: Security Area Advisory Group <saag@lists.tislabs.com>
From: Jeff.Hodges@KingsMountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 30 Apr 2001 23:18:20 -0700
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

------- Forwarded Message

Date: Mon, 30 Apr 2001 22:35:48 -0400
From: Rich Salz <rsalz@zolera.com>
To: cryptography@wasabisystems.com
Subject: NTT/Mitsubishi release Camilla, ESIGN, EPOC

NTT and Mitsubishi will be granting royalty free licenses for strict
implementations of Camilla (128bit block cipher), EPOC (public-key
encryption provably secure given its assumptions), PSEC (same but for
elliptic curve), and ESIGN (a digital signature algorithm).

More details at http://info.isl.ntt.co.jp/camellia, .../epoc, .../psec,
.../esic
Press release at http://www.ntt.co.jp/news/news00e/0003/000310.html

	/r$



- ---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to 
majordomo@wasabisystems.com

------- End of Forwarded Message




From owner-saag  Tue May  1 21:54:20 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04002
	Tue, 1 May 2001 21:53:52 -0400 (EDT)
Message-Id: <5.1.0.14.0.20010501185515.00ae1050@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 01 May 2001 18:55:42 -0700
To: saag@lists.tislabs.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: User/Admin selection of authentication mechanisms by
  "strength" level
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

Your comments on the following I-D are solicited.

Title		: Authentication Mechanisms Levels
Filename	: draft-zeilenga-auth-lvl-01.txt
	
  Numerous authentication mechanisms are in use today on the Internet.
  It is desirable to give administrators the choice of which mechanisms
  to support in their deployments and to give users the choice which
  mechanisms to use.  This document offers terminology designed to be
  easily understandable by users and administrators of Internet
  services, while being meaningful to designers and developers of these
  services and associated Internet protocols.

Thanks, Kurt 


From owner-saag  Thu May  3 13:58:28 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09633
	Thu, 3 May 2001 13:58:02 -0400 (EDT)
Date: Thu, 3 May 2001 14:02:57 -0400 (EDT)
Message-Id: <200105031802.OAA15894@sweet-transvestite.mit.edu>
From: Sam Hartman <hartmans@mit.edu>
To: Kurt@OpenLDAP.org
CC: saag@lists.tislabs.com
Subject: draft-zeilenga-auth-lvl-01.txt  coments
Sender: owner-saag@lists.tislabs.com
Precedence: bulk



Hi.  I just read this draft as you requested.

Initial issues:

In section 2:

 Use of anonymous mechanisms
   SHOULD only be used for read-only access to non-sensitive information.


Just because this is a reasonable policy for LDAP does not mean it is
reasonable for the Internet.  For forms of communication where speech
might be involved, supporting anonymous speech is important.  Yes, you
have the administrative controls and there are many situations where
you don't allow anonymous auth, but there are enough where it is
appropriate that  should is too strong.


In section 3:

   When disabling access, mechanisms at or below the indicated level
   SHOULD be viewed as sufficient to deny access.


I do not understand what this text means a at all.


In section 4.5 you classify challenge response as weak.  If there is
not security justification for this, I believe these should be
classified as limited.

General comments:

I don't think this classification scheme is really appropriate for
authentication.  It is really the entire security mechanism that needs
to be classified.  If I use SRP or Kerberos to authenticate a channel,
but do not encrypt or integrity protect the channel, then I do not
have strong authentication of the data that comes over that channel.
Thus, the classification of the authenticity of data on the channel is
dependent on the classification of the security mechanism, not just
the authentication.  The SASL GSSAPI Kerberos mechanism used as a
full security mechanism normally provides strong authe; the sendauth
security mechanism in the old krb5 kpop provides limited or weak
authentication depending on configuration.  Your draft tries to work
around this at several points when it distinguishes passwords over TLS
from passwords unencrypted and discusses SASL external.

While I agree that it is reasonable for SASL to focus on the
authentication aspects of the mechanisms, I don't think you can
succeed by taking the same simplification.  It would be nice, but it
breaks down at too many points.


It also seems that your model fails to take into account convenience
issues.  I really want my UI to prefer mechanisms that minimize
storing long-term secrets and don't require me to interact like GSSAPI
krb5 to mechanisms that are at the same level but require me to do
things like type passwords every authentication.

I'm still not sure about whether the problem you are trying to solve
exists or should be solved in an IETF context.  I need to think more
about that.


From owner-saag  Thu May  3 15:53:56 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09938
	Thu, 3 May 2001 15:53:53 -0400 (EDT)
Message-Id: <5.1.0.14.0.20010503120611.00aca450@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 03 May 2001 12:55:39 -0700
To: Sam Hartman <hartmans@mit.edu>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: draft-zeilenga-auth-lvl-01.txt  coments
Cc: saag@lists.tislabs.com
In-Reply-To: <200105031802.OAA15894@sweet-transvestite.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-saag@lists.tislabs.com
Precedence: bulk


At 11:02 AM 5/3/01, Sam Hartman wrote:
>In section 2:
>
> Use of anonymous mechanisms
>   SHOULD only be used for read-only access to non-sensitive information.

I agree that this sentence should be reworded.  There are
obviously are appropriate uses of anonymous which involve
non-read operations (such as posting speech anonymous).

I'll likely reword this, e.g. "Anonymous mechanisms may be used when
and where appropriate", and provide a suitable reference discussing
the applicability of anonymous mechanisms.

>In section 3:
>
>   When disabling access, mechanisms at or below the indicated level
>   SHOULD be viewed as sufficient to deny access.

>I do not understand what this text means a at all.

If one says "if LIMITED deny access" then access is denied if
the mechanism has a level at or below LIMITED.

>In section 4.5 you classify challenge response as weak.

The example classification only has "simple" challenge
response mechanisms as weak.

>If there is
>not security justification for this, I believe these should be
>classified as limited.

I'll provide a reference to RFC 2831 which provides
additional information regarding the security reasons
for selecting DIGEST over simpler mechanisms.

I'll also add some clarification to section 4 stating that
it does not provide a definitive classification.  

>General comments:

I'll chew on these.  Thanks!

Kurt


From owner-saag  Fri May 11 07:32:32 2001
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01786
	Fri, 11 May 2001 07:32:05 -0400 (EDT)
From: tim <tfs@mystic.uprising.net>
Message-Id: <200105110627.CAA41178@mystic.uprising.net>
Subject: Re: draft-zeilenga-auth-lvl-01.txt  coments
In-Reply-To: <200105031802.OAA15894@sweet-transvestite.mit.edu> from Sam Hartman at "May 3, 2001  2: 2:57 pm"
To: hartmans@mit.edu (Sam Hartman)
Date: Fri, 11 May 2001 02:27:23 -0400 (EDT)
Cc: Kurt@OpenLDAP.org, saag@lists.tislabs.com
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-saag@lists.tislabs.com
Precedence: bulk

Sam Hartman said:
 > 
 > General comments:
 > 
 > I don't think this classification scheme is really appropriate for
 > authentication.  It is really the entire security mechanism that needs
 > to be classified.  If I use SRP or Kerberos to authenticate a channel,
 > but do not encrypt or integrity protect the channel, then I do not
 > have strong authentication of the data that comes over that channel.
 > Thus, the classification of the authenticity of data on the channel is
 > dependent on the classification of the security mechanism, not just
 > the authentication.  The SASL GSSAPI Kerberos mechanism used as a
 > full security mechanism normally provides strong authe; the sendauth
 > security mechanism in the old krb5 kpop provides limited or weak
 > authentication depending on configuration.  Your draft tries to work
 > around this at several points when it distinguishes passwords over TLS
 > from passwords unencrypted and discusses SASL external.

This might seem off topic, but I am wondering if you or anyone else
reading has done any time & channel mapping to deal with some of the
loadbearing issues associated with support on these. I'm having to look
at this some currently and I've been wondering about that question for
these mechanisims. The vendor side of things I've got covered, but
this is an aspect of the configuration stuff I'm working on that I have
to consider. 

 > While I agree that it is reasonable for SASL to focus on the
 > authentication aspects of the mechanisms, I don't think you can
 > succeed by taking the same simplification.  It would be nice, but it
 > breaks down at too many points.

I agree with this.

 > 
 > It also seems that your model fails to take into account convenience
 > issues.  I really want my UI to prefer mechanisms that minimize
 > storing long-term secrets and don't require me to interact like GSSAPI
 > krb5 to mechanisms that are at the same level but require me to do
 > things like type passwords every authentication.

The fun of planning crypto infrastructure there. Typing passwords everytime
does make for unpleasantness when it comes to dealing with the passwords,
much less managing what ends up being programed around them in uncontroled
environments.

 > I'm still not sure about whether the problem you are trying to solve
 > exists or should be solved in an IETF context.  I need to think more
 > about that.

I have no idea if the one I'm asking about is or isn't. I'll freely admit
I'm asking because it's something I'm dealing with and I want to save 
some time & not reinvent a wheel if possible. Apologies if it's considered
inappropriate by anyone. Also, please forgive the late followup, but I
have been unavalible to the list traffic for awhile until now. 


Tim Scanlon








From jis@MIT.EDU  Mon Jun 18 15:10:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA22809;
	Mon, 18 Jun 2001 15:10:38 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA04795;
	Mon, 18 Jun 2001 15:10:37 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA22420;
	Mon, 18 Jun 2001 15:00:33 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id OAA00580;
	Mon, 18 Jun 2001 14:59:46 -0400
Date: Mon, 18 Jun 2001 14:59:46 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Security Area Advisory Group <saag@mit.edu>
Message-ID: <20010618145945.B512@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [saag] New SAAG Mailing List Home
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I am about to move the SAAG mailing list from saag@lists.tislabs.com to
its new home at saag@mit.edu.

The new list is being managed via "mailman" software (similar to
majordomo, but with an optional web interface). You will receive an
automated greeting message when you are added, it will contain the
information you need to manage your subscription.

In spite of what the greeting message says, you will *not* receive
monthly spam with your list password. If you need to know your list
password, you can have it mailed to you from the website (info in
the welcome message).

For most people you need not do anything except to remember to send
posts to saag@mit.edu instead of saag@list.tislabs.com (though they
should forward).

			-Jeff


From jis@MIT.EDU  Tue Jun 19 22:14:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA03889
	for <saag@jis.mit.edu>; Tue, 19 Jun 2001 22:14:50 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA19061
	for <saag@mit.edu>; Tue, 19 Jun 2001 22:14:50 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA03885
	for <saag@mit.edu>; Tue, 19 Jun 2001 22:14:49 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id WAA02334
	for saag@mit.edu; Tue, 19 Jun 2001 22:14:40 -0400
Date: Tue, 19 Jun 2001 22:14:40 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Security Area Advisory Group <saag@mit.edu>
Message-ID: <20010619221440.N686@mit.edu>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="ZoaI/ZTpAVc4A5k6"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [saag] Encryption and Security Requirements in the IETF
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--ZoaI/ZTpAVc4A5k6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Attached is an as yet unsubmitted Internet Draft. It is a first pass
at codifying the Danver's Doctrine and the general notion that we need
to do "good" security in IETF protocols. The plan is for this document
to be issued as a BCP. Comments are welcome and debate can happen here.

			-Jeff

--ZoaI/ZTpAVc4A5k6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="id.txt"

Network Working Group                                Jeffrey I. Schiller
*DRAFT*                            Massachusetts Institute of Technology
                                                              June, 2001

    Encryption and Security Requirements for IETF Standard Protocols
                     <draft-schiller-whyenc-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   It is the consensus of the IETF that IETF standard protocols MUST
   make use of appropriate strong security mechanisms. This document
   establishes this doctrine as a BCP [or will after it is published as
   a BCP]. It also describes the history and rationale for this
   statement.

1.  Introduction

   The purpose of this document is to document the IETF consensus on
   security requirements for protocols as well as to provide the
   background and motivation for them.

   The Internet is a global network of independently managed networks
   and hosts. As such there is no central authority responsible for the
   operation of the network. There is no central authority responsible
   for the provision of security across the network either.

   Security needs to be provided end-to-end or host to host. The IETF's
   security role is to ensure that IETF standard protocols have the
   necessary features to provide appropriate security for the
   application as it may be used across the Internet.



Schiller                         *DRAFT*                        [Page 1]

                    Encryption Security Requirements           June 2001


2.  Terminology

   Although we are not defining a protocol standard in this document we
   will use the terms MUST, MAY, SHOULD and friends in the ways defined
   by [RFC2119].

3.  Security Services

   More formal definitions of network security services may be found
   elsewhere. Here is a quick synopsis:

   * Authentication: Knowing that a datagram came from where it purports
     to originate. At the application layer, knowing that the entity
     performing an operations, be it a process, computer system or a
     person, is whom it claims to be.

   * Integrity: Knowing that information that has been transported
     across the network has not been tampered with.

   * Confidentiality: Knowing that sensitive information has not been
     disclosed to unauthorized parties.

4.  Some Properties of the Internet

   As mentioned earlier, the Internet provides no inherent security.
   Enclaves of networking exist where users believe that security is
   provided by the environment itself. An example would be a company
   network not connected to the global Internet.

   One might imagine that protocols designed to operate in such an
   enclave would not require any security services, as the security is
   provided by the environment.

   History has shown that applications that operate using the TCP/IP
   Protocol Suite wind up being used over the Internet. This is true
   even when the original application was not envisioned to be used in a
   "wide area" Internet environment. If an application isn't designed to
   provide security, users of the application discover that they are
   vulnerable to attack.

5.  IPSec and TLS

   The IETF has two generic security standards, IP Security Protocol
   (IPSec) and the Transport Layer Security (TLS) protocol. These
   protocols provide security services at the IP and TCP layer
   respectively. However these protocols provide selected services to an
   entire association or connection. All data is protected. This usually
   means that performance when run over these protocols will likely be
   less then if only appropriate portions of an application's data were
   protected. To do this requires designing appropriate security
   mechanisms into the application protocol.

   We therefore encourage IETF protocol designers to take a critical
   look at the protocol they are designing with an eye toward the



Schiller                         *DRAFT*                        [Page 2]

                    Encryption Security Requirements           June 2001


   application of appropriate security.

6.  The Danver's Doctrine

   At the 32cd IETF held in Danvers, Massachusetts during April of 1995
   the IESG asked the plenary for a consensus on the strength of
   security that should be provided by IETF standards. Although the
   immediate issue before the IETF was whether or not to support
   "export" grade security (which is to say weak security) in standards
   the question raised the generic issue of security in general.

   The overwhelming consensus was that the IETF should standardize on
   the use of the best security available, regardless of national
   policies. This consensus is often referred to as the "Danver's
   Doctrine."

   Over time we have extended the interpretation of the Danver's
   Doctrine to imply that all IETF protocols should operate securely.
   How can you argue against this?

   Since 1995 the Internet has increasingly come under attack from
   various malicious actors. In 2000 significant press coverage was
   devoted to Distributed Denial of Service attacks. However many of
   these attacks were launched by first compromising an Internet
   connected computer system. Usually many systems are compromised in
   order to launch a significant distributed attack.

   A conclusion we can draw from all of this is that if we fail to
   provide secure protocols, then the Internet will become less useful
   in providing an international communications infrastructure, which
   appears to be its destiny.

   One of the continuing arguments we hear against building security
   into protocols is the argument that a given protocol is intended only
   for use in "protected" environments where security will not be an
   issue.

   However it is very hard to predict how a protocol will be used in the
   future. What may be intended only for a restricted environment may
   well wind up being deployed in the global Internet. We cannot wait
   until that point to "fix" security problems. By the time we realize
   this deployment, it is too late.

   The solution is that we MUST implement strong security in all
   protocols to provide for the all too frequent day when the protocol
   coming into widespread use in the global Internet.

7.  MUST is for Implementors

   We often say that Security is a MUST implement. It is worth noting
   that there is a significant different between MUST implement and MUST
   use.





Schiller                         *DRAFT*                        [Page 3]

                    Encryption Security Requirements           June 2001


   As mentioned earlier, some protocols may be deployed in secure
   enclaves for which security isn't an issue and security protocol
   processing may add a significant performance degradation. Therefore
   it is completely reasonable for security features to be an option
   that the end user of the protocol may choose to disable. Note that we
   are using a fuzzy definition of "end user" here. We mean not only the
   ultimate end user, but any deployer of a technology, which may be an
   entire enterprise.

   However security must be a MUST IMPLEMENT so that end users will have
   the option of enabling it when the situation calls for it.

8.  Is Encryption a MUST?

   Not necessarily. However we need to be a bit more precise here.
   Exactly what security services are appropriate for a given protocol
   depends heavily on the application it is implementing. Many people
   assume that encryption means confidentiality. In other words the
   encryption of the content of protocol messages.

   However there are many applications where confidentiality is not a
   requirement, but authentication and integrity are.

   One example might be in a building control application where we are
   using IP technology to operate heat and vent controls. There is
   likely no requirement to protect the confidentiality of messages that
   instruct heat vents to open and close. However authentication and
   integrity are likely important if we are to protect the building from
   a malicious actor raising or lowering the temperature at will.

   Yet we often require cryptographic technology to implement
   authentication and integrity of protocol messages. So if the question
   is "MUST we implement confidentiality?" the answer will be "depends."
   However if the question is "MUST we make use of cryptographic
   technology?" the answer is "likely."

9.  Crypto Seems to have a Bad Name

   The mention of cryptographic technology in many IETF forums causes
   eyes to glaze over and resistance to increase.

   Many people seem to associate the word "cryptography" with concerns
   such as export control and performance. Some just plain do not
   understand it and therefore shy away from its use. However many of
   these concerns are unfounded.

   Today export control, at least from most of the developed world, is
   becoming less of a concern. And even where it is a concern, the
   concern is not over cryptography itself but in its use in providing
   confidentiality.

   There are performance issues when you make use of cryptographic
   technology. However we pride ourselves in the IETF as being
   engineers. It is an engineering exercise to figure out the



Schiller                         *DRAFT*                        [Page 4]

                    Encryption Security Requirements           June 2001


   appropriate way to make use of cryptographic technology so as to
   eliminate or at least minimize the impact of using cryptography
   within a given protocol.

   Finally as to understanding cryptography, you don't have to. In other
   words you do not need to become a cryptographer in order to
   effectively make use of cryptographic technology. Instead you make
   use of existing well understood ciphers and cipher suites to solve
   the engineering problem you face.

   One of the goals that we have in the Security Area of the IETF is to
   come up with guides so that protocol implementers can choose
   appropriate technology without having to understand the minutiae.

10.  Security Considerations

   This document is about the IETF's requirement that security be
   considered in the implementation of protocols. Therefore it is
   entirely about security!

11.  References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

12.  Author's Address


   Jeffrey I. Schiller
   MIT Room W92-190
   77 Massachusetts Avenue
   Cambridge, MA 02139-4307
   USA
   Phone: +1 (617) 253-8400
   Email: jis@mit.edu

Full Copyright statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.





Schiller                         *DRAFT*                        [Page 5]

                    Encryption Security Requirements           June 2001


   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on An
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















































Schiller                         *DRAFT*                        [Page 6]

                    Encryption Security Requirements           June 2001


                             Table of Contents


   Status of this Memo . . . . . . . . . . . . . . . . . . . . . . .   1
   Copyright Notice  . . . . . . . . . . . . . . . . . . . . . . . .   1
   Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   1
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3. Security Services  . . . . . . . . . . . . . . . . . . . . . .   2
   4. The Properties of the Internet . . . . . . . . . . . . . . . .   2
   5. IPSec and TLS  . . . . . . . . . . . . . . . . . . . . . . . .   2
   6. The Danver's Doctrine  . . . . . . . . . . . . . . . . . . . .   3
   7. MUST is for Implementors . . . . . . . . . . . . . . . . . . .   3
   8. Is Encryption a MUST?  . . . . . . . . . . . . . . . . . . . .   4
   9. Crypto Seems to have a Bad Name  . . . . . . . . . . . . . . .   4
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   5
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   12. Author's Address  . . . . . . . . . . . . . . . . . . . . . .   5
   Full Copyright statement  . . . . . . . . . . . . . . . . . . . .   5






































Schiller                         *DRAFT*                        [Page i]

--ZoaI/ZTpAVc4A5k6--

From HUITEMA@windows.microsoft.com  Wed Jun 20 11:19:48 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08562
	for <saag@jis.mit.edu>; Wed, 20 Jun 2001 11:19:48 -0400 (EDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA24471
	for <saag@mit.edu>; Wed, 20 Jun 2001 11:19:47 -0400 (EDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Jun 2001 08:16:47 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Wed, 20 Jun 2001 08:18:58 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Wed, 20 Jun 2001 08:18:43 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 20 Jun 2001 08:17:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [saag] Encryption and Security Requirements in the IETF
Date: Wed, 20 Jun 2001 08:17:09 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BE73@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [saag] Encryption and Security Requirements in the IETF
Thread-Index: AcD5MM4DK0nZJqPhSFG9fKTb/mMoTAAavW7w
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <saag@mit.edu>
X-OriginalArrivalTime: 20 Jun 2001 15:17:09.0914 (UTC) FILETIME=[1339BFA0:01C0F99C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id LAA08562
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jeff,

This is a fine document, yet I wonder whether it is complete. In
practice, we find three issues that tend to block the deployment of
strong security: key negotiation, proving an identity, and convincing
local administrators to let encrypted data through a firewall. Should
the draft discuss these issues?

-- Christian Huitema

> -----Original Message-----
> From: Jeffrey I. Schiller [mailto:jis@MIT.EDU]
> Sent: Tuesday, June 19, 2001 7:15 PM
> To: Security Area Advisory Group
> Subject: [saag] Encryption and Security Requirements in the IETF
> 
> Attached is an as yet unsubmitted Internet Draft. It is a first pass
> at codifying the Danver's Doctrine and the general notion that we need
> to do "good" security in IETF protocols. The plan is for this document
> to be issued as a BCP. Comments are welcome and debate can happen
here.
> 
> 			-Jeff

From MatthewChalmers@FirstUSA.com  Wed Jun 20 11:59:35 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08915
	for <saag@jis.mit.edu>; Wed, 20 Jun 2001 11:59:35 -0400 (EDT)
Received: from pm03sm.rst.cw.net (PM03SM.RST.CW.NET [204.71.247.138])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28891
	for <saag@mit.edu>; Wed, 20 Jun 2001 11:59:34 -0400 (EDT)
Received: from swilnts808.wil.fusa.com ([206.151.92.65])
 by PM03SM.RST.CW.NET (PMDF V6.0-24 #42203)
 with ESMTP id <0GF803R7YKF842@PM03SM.RST.CW.NET> for saag@mit.edu; Wed,
 20 Jun 2001 15:59:33 +0000 (GMT)
Received: by swilnts808.wil.fusa.com with Internet Mail Service (5.5.2650.21)
	id <NJP5Q2SL>; Wed, 20 Jun 2001 11:56:58 -0400
Content-return: allowed
Date: Wed, 20 Jun 2001 11:56:57 -0400
From: "Chalmers, Matthew (FUSA)" <MatthewChalmers@FirstUSA.com>
Subject: RE: [saag] Encryption and Security Requirements in the IETF
To: "'saag@mit.edu'" <saag@mit.edu>
Message-id: <B39104ADF3A0D311878200A0C9B41A1F04FED58D@swilnts814.wil.fusa.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I like the point made about not knowing how a protocol will be used in the
future. If someone is going to submit an RFC, obviously the protocol can be
used by anyone in any situation. If a protocol is intended only to be used
in a vacuum, it should not be publicly disclosed. However I don't know if
that should be mentioned because we don't want to discourage anyone from
publicizing ideas which could be beneficial to others.

I like the point made about security not necessarily implying
confidentiality or even encryption/crypto. Perhaps it could be made more
clear by defining the other security services. Only authentication,
confidentiality, and integrity are mentioned in the document; the 'quick
synopsis' section should probably also define authorization (e.g. rights
given an authenticated entity), nonrepudiation, and availability. You might
also consider referring to 'security services' more often, rather than
simply 'security'.

I'm not sure I like the paragraph describing DDoS attacks because it's not
entirely the fault of non-secure protocols (at least when you mention the
compromise of Internet-connected systems). Then the following paragraph
seems like a non sequitur, as if there should have been more evidence
preceding it. But with the added definition of availability, it might be
more clear.

At first I thought the document was too short, but then I decided it's
probably better that way because the intention, as it states, is only to
document the IETF concensus. Perhaps the flow could be made smoother in
places, perhaps by adding more meat, especially in the Danver's Doctrine
section. But we don't want to dwell on this document too much because it is
just to document the IETF concensus as a BCP.

Also, 'operations' with an 's' is probably a typo in the paragraph defining
authentication, unless you meant to parenthesize it. The 'whom' vice 'who'
later in the same sentence is debatable.

Sorry I didn't have more time to review it but it looks pretty good.

--
Matthew Chalmers
Information Security
FIRST USA BANK, NA


-----Original Message-----
From: Jeffrey I. Schiller [mailto:jis@mit.edu]
Sent: Tuesday, June 19, 2001 10:15 PM
To: Security Area Advisory Group
Subject: [saag] Encryption and Security Requirements in the IETF


Attached is an as yet unsubmitted Internet Draft. It is a first pass
at codifying the Danver's Doctrine and the general notion that we need
to do "good" security in IETF protocols. The plan is for this document
to be issued as a BCP. Comments are welcome and debate can happen here.

			-Jeff

From randy@psg.com  Wed Jun 20 12:51:09 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA09410
	for <saag@jis.mit.edu>; Wed, 20 Jun 2001 12:51:09 -0400 (EDT)
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14725
	for <saag@mit.edu>; Wed, 20 Jun 2001 12:51:08 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 15ClC6-000GtE-00; Wed, 20 Jun 2001 09:51:06 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Christian Huitema" <huitema@windows.microsoft.com>
Cc: <saag@mit.edu>
Subject: RE: [saag] Encryption and Security Requirements in the IETF
References: <F66A04C29AD9034A8205949AD0C9010418BE73@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Message-Id: <E15ClC6-000GtE-00@rip.psg.com>
Date: Wed, 20 Jun 2001 09:51:06 -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> This is a fine document, yet I wonder whether it is complete. In
> practice, we find three issues that tend to block the deployment of
> strong security: key negotiation, proving an identity, and convincing
> local administrators to let encrypted data through a firewall. Should
> the draft discuss these issues?

there seems to be a long, albeit useful, path from prescribing that
protocols must support encryption to recommendations on how to implement.

randy

From rshirey@bbn.com  Mon Jun 25 10:26:26 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA08656
	for <saag@jis.mit.edu>; Mon, 25 Jun 2001 10:26:26 -0400 (EDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA11397
	for <saag@mit.edu>; Mon, 25 Jun 2001 10:26:26 -0400 (EDT)
Received: from [192.233.50.128] ([192.233.50.128])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA16285
	for <saag@mit.edu>; Mon, 25 Jun 2001 10:25:43 -0400 (EDT)
X-Sender: rshirey@rospo1.bbn.com
Message-Id: <v03110700b75ced35b0eb@[192.233.50.167]>
In-Reply-To: <20010619221440.N686@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 25 Jun 2001 10:22:18 -0400
To: saag@mit.edu
From: "Robert W. Shirey" <rshirey@bbn.com>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 10:14 PM -0400 6/19/01, Jeffrey I. Schiller wrote:
>Attached is an as yet unsubmitted Internet Draft . . . Comments are
>welcome and debate can happen here.

Jeff,

These suggestions may be somewhat immodest, but I believe they are
constructive:


Suggest adding the following paragraphs to section "2. Terminology":
-------------------------------------------------------------------

[RFC2828] provides explanations and recommendations for use of information
system security terminology. Here are four essential recommendations:

 * To improve comprehensibility of writing that deals with Internet
security, authors of Internet Standards documents (ISDs) SHOULD use terms,
abbreviations, and definitions that are already established in RFC 2828,
avoiding use of private or newly made-up synonyms.

 * To avoid litigation, ISDs SHOULD NOT use terms that are proprietary or
otherwise favor a particular vendor, or that create a bias toward a
particular security technology or mechanism versus other, competing
techniques that already exist or might be developed in the future.

 * To avoid confusion, ISDs SHOULD use the same term or definition whenever
the same concept is mentioned.

 * To improve international understanding, ISDs SHOULD use *all*
terms--both security and non-security--in their plainest, dictionary sense.


Suggest replacing section "3. Security Services" as follows:
--------------------------------------------------------------------

[RFC2828] provides a comprehensive listing of internetwork security
services and their definitions. Here are three essential definitions:

 * Authentication service: A security service that verifies an identity
claimed by or for an entity, be it a process, computer system, or person.
At the internetwork layer, this includes verifying that a datagram came
from where it purports to originate. At the application layer, this
includes verifying that the entity performing an operation is who it claims
to be.

 * Data confidentiality service: A security service that protects data
against unauthorized disclosure to unauthorized individuals or processes.
(ISDs SHOULD NOT use "data confidentiality" as a synonym for "privacy",
which is a different concept. Privacy refers to the right of an entity,
normally a person, acting in its own behalf, to determine the degree to
which it will interact with its environment, including the degree to which
the entity is willing to share information about itself with others.)

 * Data integrity service: A security service that protects against
unauthorized changes to data, including both intentional change (including
destruction) and accidental change (including loss), by ensuring that
changes to data are detectable.


Suggested adding the following paragraph to section "11. References":
---------------------------------------------------------------------
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.


Regards, -Rob-

Robert W. Shirey, BBN Technologies (A Verizon Co.) Info. Security Dept.
Suite 1200,  1300 Seventeenth St. North,  Arlington, VA  22209-3801 USA
rshirey@bbn.com,  Phone 703-284-4641,  Reception 284-4600, Fax 284-2766





From rja@inet.org  Mon Jun 25 11:21:06 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA09025
	for <saag@jis.mit.edu>; Mon, 25 Jun 2001 11:21:06 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28305
	for <saag@mit.edu>; Mon, 25 Jun 2001 11:21:06 -0400 (EDT)
Received: from mosquito.inet.org (rja-laptop [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP id 164D88266E
	for <saag@mit.edu>; Mon, 25 Jun 2001 11:20:11 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010625111507.00a19de0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 25 Jun 2001 11:16:12 -0400
To: saag@mit.edu
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
In-Reply-To: <v03110700b75ced35b0eb@[192.233.50.167]>
References: <20010619221440.N686@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

>[RFC2828] provides explanations and recommendations for use of information
>system security terminology. Here are four essential recommendations:
>
> * To improve comprehensibility of writing that deals with Internet
>security, authors of Internet Standards documents (ISDs) SHOULD use terms,
>abbreviations, and definitions that are already established in RFC 2828,
>avoiding use of private or newly made-up synonyms.
>
> * To avoid litigation, ISDs SHOULD NOT use terms that are proprietary or
>otherwise favor a particular vendor, or that create a bias toward a
>particular security technology or mechanism versus other, competing
>techniques that already exist or might be developed in the future.
>
> * To avoid confusion, ISDs SHOULD use the same term or definition whenever
>the same concept is mentioned.
>
> * To improve international understanding, ISDs SHOULD use *all*
>terms--both security and non-security--in their plainest, dictionary sense.

        I support the above.  Lack of clarity and precision has
been particularly problematic in IETF security-related documents,
mine included.  Moving towards a common, precise, and clear lexicon
will really be helpful.

Ran
rja@inet.org


From smb@research.att.com  Mon Jun 25 11:55:15 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA09302
	for <saag@jis.mit.edu>; Mon, 25 Jun 2001 11:55:15 -0400 (EDT)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18102
	for <saag@mit.edu>; Mon, 25 Jun 2001 11:55:13 -0400 (EDT)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30])
	by mail-green.research.att.com (Postfix) with ESMTP id 5A1E01E5A1
	for <saag@mit.edu>; Mon, 25 Jun 2001 11:55:13 -0400 (EDT)
Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10])
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA09885
	for <saag@mit.edu>; Mon, 25 Jun 2001 11:54:55 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id D96157B5F
	for <saag@mit.edu>; Mon, 25 Jun 2001 11:55:10 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 25 Jun 2001 11:55:10 -0400
Message-Id: <20010625155510.D96157B5F@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <5.1.0.14.2.20010625111507.00a19de0@10.30.15.2>, RJ Atkinson writes:
>
>>[RFC2828] provides explanations and recommendations for use of information
>>system security terminology. Here are four essential recommendations:
>>
>> * To improve comprehensibility of writing that deals with Internet
>>security, authors of Internet Standards documents (ISDs) SHOULD use terms,
>>abbreviations, and definitions that are already established in RFC 2828,
>>avoiding use of private or newly made-up synonyms.
>>
>> * To avoid litigation, ISDs SHOULD NOT use terms that are proprietary or
>>otherwise favor a particular vendor, or that create a bias toward a
>>particular security technology or mechanism versus other, competing
>>techniques that already exist or might be developed in the future.
>>
>> * To avoid confusion, ISDs SHOULD use the same term or definition whenever
>>the same concept is mentioned.
>>
>> * To improve international understanding, ISDs SHOULD use *all*
>>terms--both security and non-security--in their plainest, dictionary sense.
>
>        I support the above.  Lack of clarity and precision has
>been particularly problematic in IETF security-related documents,
>mine included.  Moving towards a common, precise, and clear lexicon
>will really be helpful.

I guess we need to say that to ekr, too.

		--Steve Bellovin, http://www.research.att.com/~smb



From randy@psg.com  Mon Jun 25 13:08:34 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA09708
	for <saag@jis.mit.edu>; Mon, 25 Jun 2001 13:08:34 -0400 (EDT)
Received: from roam.psg.com (mpfg.attlabs.net [12.106.35.2])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA10858
	for <saag@mit.edu>; Mon, 25 Jun 2001 13:08:33 -0400 (EDT)
Received: from randy by roam.psg.com with local (Exim 3.22 #1)
	id 15EZpe-0000gQ-00; Mon, 25 Jun 2001 10:07:26 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Robert W. Shirey" <rshirey@bbn.com>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
References: <20010619221440.N686@mit.edu>
	<v03110700b75ced35b0eb@[192.233.50.167]>
Message-Id: <E15EZpe-0000gQ-00@roam.psg.com>
Date: Mon, 25 Jun 2001 10:07:26 -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: saag@mit.edu
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Suggest adding the following paragraphs to section "2. Terminology":
> -------------------------------------------------------------------
> 
> [RFC2828] provides explanations and recommendations for use of information
> system security terminology. Here are four essential recommendations:
> 
>  * To improve comprehensibility of writing that deals with Internet
> security, authors of Internet Standards documents (ISDs) SHOULD use terms,
> abbreviations, and definitions that are already established in RFC 2828,
> avoiding use of private or newly made-up synonyms.
> 
>  * To avoid litigation, ISDs SHOULD NOT use terms that are proprietary or
> otherwise favor a particular vendor, or that create a bias toward a
> particular security technology or mechanism versus other, competing
> techniques that already exist or might be developed in the future.
> 
>  * To avoid confusion, ISDs SHOULD use the same term or definition whenever
> the same concept is mentioned.
> 
>  * To improve international understanding, ISDs SHOULD use *all*
> terms--both security and non-security--in their plainest, dictionary sense.

while i have no disagreement with these per se, are they germane to the
subject, or will they merely act as flame attractors?

randy

From owner-saag@MIT.EDU  Tue Jun 26 07:02:43 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id HAA16670
	for <saag@jis.mit.edu>; Tue, 26 Jun 2001 07:02:43 -0400 (EDT)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA21966
	for <saag@mit.edu>; Tue, 26 Jun 2001 07:02:43 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id GAA14740
	Tue, 26 Jun 2001 06:56:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27137;
	Tue, 26 Jun 2001 07:01:47 -0400 (EDT)
Message-Id: <200106261101.HAA27137@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 26 Jun 2001 07:01:47 -0400
Subject: [saag] I-D ACTION:draft-mcgrew-saag-sst-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Stream Cipher Security Transform
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-sst-00.txt
	Pages		: 12
	Date		: 25-Jun-01
	
This document describes a cryptographic transform which uses a
stream cipher (which can generate keystream segments in arbitrary
order) and a universal hash function to provide both privacy and
authentication together, or either security service separately.
This transform is efficient, provably secure, appropriate for
network security, and is believed to be patent free.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-sst-00.txt

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-mcgrew-saag-sst-00.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-mcgrew-saag-sst-00.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:	<20010625095516.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-sst-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-sst-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010625095516.I-D@ietf.org>

--OtherAccess--

--NextPart--



From phoffman@imc.org  Wed Jun 27 14:29:59 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA25502
	for <saag@jis.mit.edu>; Wed, 27 Jun 2001 14:29:59 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA09315
	for <saag@mit.edu>; Wed, 27 Jun 2001 14:29:57 -0400 (EDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20])
	by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RITsm23238
	for <saag@mit.edu>; Wed, 27 Jun 2001 11:29:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05100331b75fd53523dc@[165.227.249.20]>
In-Reply-To: <20010619221440.N686@mit.edu>
References: <20010619221440.N686@mit.edu>
Date: Wed, 27 Jun 2001 11:29:49 -0700
To: saag@mit.edu
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jeff:

This document would be more useful if you would give some more 
parameters on what "strong" means. A good example would be to say 
whether or not a hash of a password (that's password, not pre-shared 
secret) is considered "strong" enough for authentication in 
application protocols.

We all agree that, if encryption is used, the key lengths should 
be >80 bits at a minimum. If the document wants to just cover 
encryption, it should actually give some bit lengths. If you want to 
talk about authentication, you need to have much more discussion 
about what is and is not acceptable for protocols.

Without giving guidance, this document can't be said to describe Best 
Current Practices.

--Paul Hoffman, Director
--Internet Mail Consortium

From phoffman@imc.org  Wed Jun 27 17:15:17 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA26435
	for <saag@jis.mit.edu>; Wed, 27 Jun 2001 17:15:17 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00729
	for <saag@mit.edu>; Wed, 27 Jun 2001 17:15:17 -0400 (EDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20])
	by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RLFCm28796
	for <saag@mit.edu>; Wed, 27 Jun 2001 14:15:12 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0510033bb75ffc084322@[165.227.249.20]>
Date: Wed, 27 Jun 2001 14:15:02 -0700
To: saag@mit.edu
From: Paul Hoffman / IMC <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [saag] OIDs used in security protocols
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

S/MIME and PKIX (and other security protocols) use OIDs to identify 
security parameters such as encryption algorithms and 
protocol-specific extensions. Both protocols already use OIDs from a 
wide variety of arcs, and both also have their own OID arcs that are 
being managed by Russ Housley. (The current arcs can be seen at 
<http://www.imc.org/ietf-smime/sm-oid.asn> and 
<http://www.imc.org/ietf-pkix/pkix-oid.asn>).

Maintaining these OID arcs has been found to be troublesome. Some 
developers don't know to look for the OIDs on the WG's home pages. 
Even if these were arcs maintained by IANA, some developers don't 
know to look for the OIDs at IANA, or where to look on the IANA site. 
Further, it is not clear that we can agree to the rules that we 
should give IANA for the arcs if they were to become official.

The basic problem is that we want OIDs early in the Internet Draft 
development so that people can test and implement. Assuming that the 
drafts progress, some developers will probably ship products with 
those OIDs in them. If we use unofficial OIDs for the drafts and then 
change to official OIDs when the drafts become RFCs, the 
early-shipped products won't recognize the new OIDs, and developers 
who only read the RFCs won't know to also accept the old OIDs and 
therefore will not interoperate with early products.

Given these problems, it is not clear what is the advantage of 
area-specific OID arcs maintained by IANA. Russ and I therefore 
propose:

- Russ freezes the PKIX and S/MIME OID arcs and submits them to IANA 
to be included in the parent arcs (which are kept at 
<http://www.iana.org/assignments/smi-numbers>, a location that few 
folks know about) with instructions that they should remain frozen.

- Future security protocol authors that need OIDs simply assign the 
OIDs themselves from private OID trees. For those of you who don't 
have your own OID tree (officially called "enterprise numbers"), you 
can get one by filling in the form at 
<http://www.iana.org/cgi-bin/enterprise.pl>; the list of existing 
enterprise numbers can be found at 
<http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers>. 
This has worked well so far; both PKIX and S/MIME have many algorithm 
identifiers from arcs that are not maintained by IANA, and NIST has 
already assigned OIDs for AES.

Following these two steps means that the only official mechanism for 
assigning OIDs is the RFCs themselves (or the Internet Drafts, for 
the very early adopters). Looking back on our experience with S/MIME 
and PKIX, this is probably the best way to get interoperability and 
still give us the flexibility we need as we are creating protocols. 
Developers need only look in the spec, not to IANA, for the 
identifiers.

Comments are welcome.

--Paul Hoffman, Director
--Internet Mail Consortium

From jis@MIT.EDU  Thu Jun 28 02:17:01 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA28783;
	Thu, 28 Jun 2001 02:17:01 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA02508;
	Thu, 28 Jun 2001 02:17:01 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA28779;
	Thu, 28 Jun 2001 02:17:01 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id CAA00626;
	Thu, 28 Jun 2001 02:17:02 -0400
Date: Thu, 28 Jun 2001 02:17:02 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Tim Moors <moors@ieee.org>
Cc: saag@mit.edu
Message-ID: <20010628021702.A619@mit.edu>
References: <NDBBKKDDOKHDNCFOLOIFMEGADBAA.moors@ieee.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <NDBBKKDDOKHDNCFOLOIFMEGADBAA.moors@ieee.org>; from moors@ieee.org on Wed, Apr 25, 2001 at 09:03:27AM -0400
Subject: [saag] Re: Record of "How to Secure a Protocol" from IETF 49
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

There is now a link off of the Security Area web page:

  http://web.mit.edu/network/ietf/sa

to the slides used during the Security Tutorial.

			-Jeff

On Wed, Apr 25, 2001 at 09:03:27AM -0400, Tim Moors wrote:
> Is there any record of the "How to Secure a Protocol" tutorial from IETF 49
> (e.g. video recording or slides)?  I couldn't find anything in the
> Proceedings (http://www.ietf.org/proceedings/00dec/index.html), video
> archives (http://videolab.uoregon.edu/events/ietf/ietf49.html), Security
> Area Web Page (http://web.mit.edu/network/ietf/sa/), or standard web
> searches.

From adam@zeroknowledge.com  Thu Jun 28 09:40:51 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00599
	for <saag@jis.mit.edu>; Thu, 28 Jun 2001 09:40:51 -0400 (EDT)
Received: from cc.zeroknowledge.com (cc.zeroknowledge.com [207.107.114.244])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA24070
	for <saag@mit.edu>; Thu, 28 Jun 2001 09:40:51 -0400 (EDT)
Received: from smartypants.zks.net (smartypants.zks.net [192.168.1.4])
	by cc.zeroknowledge.com (8.9.3/8.9.3) with ESMTP id JAA05115;
	Thu, 28 Jun 2001 09:40:50 -0400
Received: from computer (adam.dev.zks.net [10.16.3.144])
	by smartypants.zks.net (8.9.3/8.9.3) with SMTP id JAA32201;
	Thu, 28 Jun 2001 09:40:50 -0400
Received: (from adam@localhost)
	by adam.zks.net (8.9.3/8.9.3) id JAA06193;
	Thu, 28 Jun 2001 09:42:33 -0400
Date: Thu, 28 Jun 2001 09:42:33 -0400
From: Adam Shostack <adam@zeroknowledge.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010628094233.A6069@zeroknowledge.com>
References: <20010619221440.N686@mit.edu> <p05100331b75fd53523dc@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100331b75fd53523dc@[165.227.249.20]>; from phoffman@imc.org on Wed, Jun 27, 2001 at 11:29:49AM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Wed, Jun 27, 2001 at 11:29:49AM -0700, Paul Hoffman / IMC wrote:
> Jeff:
> 
> This document would be more useful if you would give some more 
> parameters on what "strong" means. A good example would be to say 
> whether or not a hash of a password (that's password, not pre-shared 
> secret) is considered "strong" enough for authentication in 
> application protocols.
[...]
> Without giving guidance, this document can't be said to describe Best 
> Current Practices.

Paul,

	Does encoding what strong means in every document make sense?
It seems to me that this (along with key exchange), should be covered
in a BCP, and various protocol documents should just refer to
BCP-ROT13 for key strengths.

Adam




-- 
It's Easy, Fun and Mandatory!!

From phoffman@imc.org  Thu Jun 28 14:06:54 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA02242
	for <saag@jis.mit.edu>; Thu, 28 Jun 2001 14:06:54 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA22952
	for <saag@mit.edu>; Thu, 28 Jun 2001 14:06:53 -0400 (EDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20])
	by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SI6nm16489;
	Thu, 28 Jun 2001 11:06:49 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0510030cb761212821d5@[165.227.249.20]>
In-Reply-To: <20010628094233.A6069@zeroknowledge.com>
References: <20010619221440.N686@mit.edu>
 <p05100331b75fd53523dc@[165.227.249.20]>
 <20010628094233.A6069@zeroknowledge.com>
Date: Thu, 28 Jun 2001 11:06:46 -0700
To: Adam Shostack <adam@zeroknowledge.com>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 9:42 AM -0400 6/28/01, Adam Shostack wrote:
>On Wed, Jun 27, 2001 at 11:29:49AM -0700, Paul Hoffman / IMC wrote:
>>  Jeff:
>>
>>  This document would be more useful if you would give some more
>>  parameters on what "strong" means. A good example would be to say
>>  whether or not a hash of a password (that's password, not pre-shared
>>  secret) is considered "strong" enough for authentication in
>>  application protocols.
>[...]
>>  Without giving guidance, this document can't be said to describe Best
>>  Current Practices.
>
>Paul,
>
>	Does encoding what strong means in every document make sense?

No, what makes sense is that every protocol just be strong. What is 
needed by protocol developers is an understanding of what "strong" 
means both for encryption (which is now pretty clear) and for 
authentication (which is far from clear, so far).

>It seems to me that this (along with key exchange), should be covered
>in a BCP, and various protocol documents should just refer to
>BCP-ROT13 for key strengths.

If key lengths were all we had to worry about, it would be fine, but 
it's not. Please take a look at my example again. There are many 
folks in the IETF who would say that that was strong enough (because 
it requires that the attacker mount a dictionary attack) and there 
are many who would say it is not strong enough (because it *only* 
requires that the attacker mount a dictionary attack).

Does IETF-defined strong authentication require hashes of passwords? 
A DH exchange? Use of a PKI? Hardware tokens?

--Paul Hoffman, Director
--Internet Mail Consortium

From jis@MIT.EDU  Thu Jun 28 19:58:00 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA04030;
	Thu, 28 Jun 2001 19:58:00 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA21161;
	Thu, 28 Jun 2001 19:58:00 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA04024;
	Thu, 28 Jun 2001 19:58:00 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id TAA01417;
	Thu, 28 Jun 2001 19:57:56 -0400
Date: Thu, 28 Jun 2001 19:57:56 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010628195756.C1147@mit.edu>
References: <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <v03110700b75ced35b0eb@[192.233.50.167]>; from rshirey@bbn.com on Mon, Jun 25, 2001 at 10:22:18AM -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

The latest version of the document is now in:

 http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt

I'll keep that copy up-to-date as I continue to edit. I am pretty close
to the version that I will submit to the I-D directory.

			-Jeff

From jis@MIT.EDU  Thu Jun 28 20:08:16 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA04142;
	Thu, 28 Jun 2001 20:08:16 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA26133;
	Thu, 28 Jun 2001 20:08:16 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA04138;
	Thu, 28 Jun 2001 20:08:15 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id UAA01463;
	Thu, 28 Jun 2001 20:08:12 -0400
Date: Thu, 28 Jun 2001 20:08:12 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010628200812.D1147@mit.edu>
References: <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]> <20010628195756.C1147@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010628195756.C1147@mit.edu>; from jis@MIT.EDU on Thu, Jun 28, 2001 at 07:57:56PM -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Btw. I haven't finished incorporating the various comments received on
the list (thanks by the way), so don't be offended (yet) if your remarks
are not yet reflected in the document.

			-Jeff

From Kurt@OpenLDAP.org  Thu Jun 28 20:10:10 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA04178;
	Thu, 28 Jun 2001 20:10:10 -0400 (EDT)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA22986;
	Thu, 28 Jun 2001 20:10:09 -0400 (EDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f5T06lA50676;
	Fri, 29 Jun 2001 00:06:47 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 28 Jun 2001 17:06:30 -0700
To: "Jeffrey I. Schiller" <jis@mit.edu>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
In-Reply-To: <20010628195756.C1147@mit.edu>
References: <v03110700b75ced35b0eb@[192.233.50.167]>
 <20010619221440.N686@mit.edu>
 <v03110700b75ced35b0eb@[192.233.50.167]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Is there a particular reason why SASL and GSSAPI are
not mentioned in this document?

Kurt


At 04:57 PM 6/28/2001, you wrote:
>The latest version of the document is now in:
>
> http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt
>
>I'll keep that copy up-to-date as I continue to edit. I am pretty close
>to the version that I will submit to the I-D directory.
>
>                        -Jeff
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://jis.mit.edu/mailman/listinfo/saag


From jis@MIT.EDU  Thu Jun 28 20:16:53 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA04259;
	Thu, 28 Jun 2001 20:16:53 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA27616;
	Thu, 28 Jun 2001 20:16:53 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA04255;
	Thu, 28 Jun 2001 20:16:52 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id UAA01494;
	Thu, 28 Jun 2001 20:16:49 -0400
Date: Thu, 28 Jun 2001 20:16:49 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010628201649.F1147@mit.edu>
References: <v03110700b75ced35b0eb@[192.233.50.167]> <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]> <20010628195756.C1147@mit.edu> <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1>; from Kurt@OpenLDAP.org on Thu, Jun 28, 2001 at 05:06:30PM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

No good reason. Care to contribute text :-)

			-Jeff

On Thu, Jun 28, 2001 at 05:06:30PM -0700, Kurt D. Zeilenga wrote:
> Is there a particular reason why SASL and GSSAPI are
> not mentioned in this document?
> 
> Kurt
> 
> 
> At 04:57 PM 6/28/2001, you wrote:
> >The latest version of the document is now in:
> >
> > http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt
> >
> >I'll keep that copy up-to-date as I continue to edit. I am pretty close
> >to the version that I will submit to the I-D directory.
> >
> >                        -Jeff
> >_______________________________________________
> >saag mailing list
> >saag@mit.edu
> >http://jis.mit.edu/mailman/listinfo/saag
> 

From Kurt@OpenLDAP.org  Thu Jun 28 20:28:19 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA04341;
	Thu, 28 Jun 2001 20:28:18 -0400 (EDT)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA25735;
	Thu, 28 Jun 2001 20:28:18 -0400 (EDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f5T0P0A50736;
	Fri, 29 Jun 2001 00:25:00 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010628171649.02a9afa0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 28 Jun 2001 17:24:43 -0700
To: "Jeffrey I. Schiller" <jis@mit.edu>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
In-Reply-To: <20010628201649.F1147@mit.edu>
References: <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1>
 <v03110700b75ced35b0eb@[192.233.50.167]>
 <20010619221440.N686@mit.edu>
 <v03110700b75ced35b0eb@[192.233.50.167]>
 <20010628195756.C1147@mit.edu>
 <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 05:16 PM 6/28/2001, you wrote:
>No good reason. Care to contribute text :-)

I can do that.  I'll send you some text to expand
section 5 to cover additional IETF generic security
standards.

Kurt


From HUITEMA@windows.microsoft.com  Thu Jun 28 21:23:23 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA04667
	for <saag@jis.mit.edu>; Thu, 28 Jun 2001 21:23:23 -0400 (EDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id VAA06891
	for <saag@mit.edu>; Thu, 28 Jun 2001 21:23:22 -0400 (EDT)
Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Jun 2001 17:32:59 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 28 Jun 2001 17:32:59 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 28 Jun 2001 17:32:48 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 28 Jun 2001 17:32:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [saag] Encryption and Security Requirements in the IETF
Date: Thu, 28 Jun 2001 17:32:16 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BE8E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [saag] Encryption and Security Requirements in the IETF
Thread-Index: AcEAMUU211bEp9IHQOGWggtqNXC/vgAAI7HQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Jeffrey I. Schiller" <jis@mit.edu>, <saag@mit.edu>
X-OriginalArrivalTime: 29 Jun 2001 00:32:17.0180 (UTC) FILETIME=[F33535C0:01C10032]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id VAA04667
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jeff,

Maybe a nit, but I am not entirely convinced by the argument in section
5, IPSec and TLS. You say that "performance when run over these
protocols will likely be less then if only appropriate portions of an
application's data were protected." Well, how likely is likely, exactly?
A large part of the performance hit is key negotiation, and that is
pretty much independent of whether you protect the whole thing or part
of it. Indeed, in theory, encrypting or signing large amount of data is
more costly than doing so on small amounts; but, on the other hand, you
are much more likely to benefit from hardware assist if you are using a
standard scheme such as IPSec or TLS; overall, the performance may well
be better if you use IPSec than if you use an application specific
scheme.

This is not to say that protocol designers should not take a hard look
at the standard schemes before deciding that they fit their needs. The
canonical example of the contrary is e-mail, in which hop-by-hop
encryption has only limited benefits. But I believe that something on
the line of "TLS or IPSec may not achieve the desired result" would be
more convincing than a mere remark on performance.

-- Christian Huitema

> -----Original Message-----
> From: Jeffrey I. Schiller [mailto:jis@MIT.EDU]
> Sent: Thursday, June 28, 2001 4:58 PM
> To: saag@mit.edu
> Subject: Re: [saag] Encryption and Security Requirements in the IETF
> 
> The latest version of the document is now in:
> 
>  http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt
> 
> I'll keep that copy up-to-date as I continue to edit. I am pretty
close
> to the version that I will submit to the I-D directory.
> 
> 			-Jeff
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

From stephen.farrell@baltimore.ie  Fri Jun 29 06:35:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA06731;
	Fri, 29 Jun 2001 06:35:38 -0400 (EDT)
Received: from hip.baltimore.ie ([193.41.17.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA05939;
	Fri, 29 Jun 2001 06:35:37 -0400 (EDT)
Received: from Baltimore-FW1 ([172.19.1.1])
	by hip.baltimore.ie (8.9.3/8.9.3) with SMTP id LAA31983;
	Fri, 29 Jun 2001 11:35:07 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.1) with SMTP id <T54705cbe550a991935167@emeairlsw1.baltimore.com>;
 Fri, 29 Jun 2001 11:32:59 +0100
Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA04816;
	Fri, 29 Jun 2001 11:44:33 +0100
Message-ID: <3B3C59D2.F98DC530@baltimore.ie>
Date: Fri, 29 Jun 2001 11:34:58 +0100
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jeffrey I. Schiller" <jis@mit.edu>
CC: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
References: <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]> <20010628195756.C1147@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jeff,

I think the fact that protocols that use crypto are actually
harder to debug/interop deserves a mention and is one of the
(defensible) reasons why people omit security or go with the 
"we'll run over TLS" approach.

I don't think that there's any way to completely avoid the problem
(which is basically that crypto makes all bits important), but it
might help to point at some of the things that have been done during
interop of crypto rfcs (e.g. the CMS samples monster I-D that 
contains broken as well as good examples, the IRC scheme that
Bob M ran for the PKIX CMP interop).

Stephen.

"Jeffrey I. Schiller" wrote:
> 
> The latest version of the document is now in:
> 
>  http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt
> 
> I'll keep that copy up-to-date as I continue to edit. I am pretty close
> to the version that I will submit to the I-D directory.
> 
>                         -Jeff
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

From mshore@cisco.com  Fri Jun 29 09:14:26 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA07379;
	Fri, 29 Jun 2001 09:14:26 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA28287;
	Fri, 29 Jun 2001 09:14:25 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5TDCFH25992;
	Fri, 29 Jun 2001 06:12:16 -0700 (PDT)
Received: from spandex (sjc-vpn-tmp220.cisco.com [10.21.64.220])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with SMTP id ALP10408;
	Fri, 29 Jun 2001 06:13:33 -0700 (PDT)
Message-ID: <02ac01c1009d$707d2640$d45904d1@cisco.com>
From: "Melinda Shore" <mshore@cisco.com>
To: "Jeffrey I. Schiller" <jis@mit.edu>, <saag@mit.edu>
References: <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]> <20010628195756.C1147@mit.edu>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Date: Fri, 29 Jun 2001 09:14:33 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> The latest version of the document is now in:
>  http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt

One additional consideration (or maybe not) is interaction with
firewalls and NATs, where deployment of the kind of device that
does payload inspection or payload rewrite is at odds with trying
to provide end-to-end privacy or end-to-end integrity protection.

Melinda



From adam@zeroknowledge.com  Fri Jun 29 11:15:35 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08078
	for <saag@jis.mit.edu>; Fri, 29 Jun 2001 11:15:35 -0400 (EDT)
Received: from cc.zeroknowledge.com (cc.zeroknowledge.com [207.107.114.244])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA02489
	for <saag@mit.edu>; Fri, 29 Jun 2001 11:15:35 -0400 (EDT)
Received: from smartypants.zks.net (smartypants.zks.net [192.168.1.4])
	by cc.zeroknowledge.com (8.9.3/8.9.3) with ESMTP id LAA28007;
	Fri, 29 Jun 2001 11:15:35 -0400
Received: from computer (adam.dev.zks.net [10.16.3.144])
	by smartypants.zks.net (8.9.3/8.9.3) with SMTP id LAA21454;
	Fri, 29 Jun 2001 11:15:34 -0400
Received: (from adam@localhost)
	by adam.zks.net (8.9.3/8.9.3) id LAA18459;
	Fri, 29 Jun 2001 11:17:17 -0400
Date: Fri, 29 Jun 2001 11:17:17 -0400
From: Adam Shostack <adam@zeroknowledge.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010629111717.A18432@zeroknowledge.com>
References: <20010619221440.N686@mit.edu> <p05100331b75fd53523dc@[165.227.249.20]> <20010628094233.A6069@zeroknowledge.com> <p0510030cb761212821d5@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p0510030cb761212821d5@[165.227.249.20]>; from phoffman@imc.org on Thu, Jun 28, 2001 at 11:06:46AM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Thu, Jun 28, 2001 at 11:06:46AM -0700, Paul Hoffman / IMC wrote:
> At 9:42 AM -0400 6/28/01, Adam Shostack wrote:
> >On Wed, Jun 27, 2001 at 11:29:49AM -0700, Paul Hoffman / IMC wrote:
> >>  Jeff:
> >>
> >>  This document would be more useful if you would give some more
> >>  parameters on what "strong" means. A good example would be to say
> >>  whether or not a hash of a password (that's password, not pre-shared
> >>  secret) is considered "strong" enough for authentication in
> >>  application protocols.
> >[...]
> >>  Without giving guidance, this document can't be said to describe Best
> >>  Current Practices.
> >
> >Paul,
> >
> >	Does encoding what strong means in every document make sense?
> 
> No, what makes sense is that every protocol just be strong. What is 
> needed by protocol developers is an understanding of what "strong" 
> means both for encryption (which is now pretty clear) and for 
> authentication (which is far from clear, so far).
> 
> >It seems to me that this (along with key exchange), should be covered
> >in a BCP, and various protocol documents should just refer to
> >BCP-ROT13 for key strengths.
> 
> If key lengths were all we had to worry about, it would be fine, but 
> it's not. Please take a look at my example again. There are many 
> folks in the IETF who would say that that was strong enough (because 
> it requires that the attacker mount a dictionary attack) and there 
> are many who would say it is not strong enough (because it *only* 
> requires that the attacker mount a dictionary attack).
> 
> Does IETF-defined strong authentication require hashes of passwords? 
> A DH exchange? Use of a PKI? Hardware tokens?

Paul,

	I agree that the points you raise are valid.  I wasn't meaning
to ignore them, I was responding to what I took as a suggestion that
the meaning of strong encryption and authentication be defined in the
SST draft.  Given the wide difference of opinions on what strong
authentication (or authorization) entails, having such decisions made
on a protocol-by-protocol basis would lead both to lots of duplication 
of effort and to different levels of security for different protocols.

        As to the technical question, what is strong enough
authentication is dependent on the use.  For things like
authenticating mail hops to manage spam, I think that the
authentication should be "proof-creating," such as a signature, and
that the key used to sign should be tied to some DNS name, so that I
have evidence that a bit of mail passed through a given server.  That
roughly requires a PKI.

	For 802.11, which is mentioned as one of the inputs, it may be
useful in a corporate setting to strongly authenticate the base
station at the ota level, while the roamer 'simply' needs to authorize
to use the service.  This could be done with hashed passwords,
persistent but unsigned DH keys, a PKI, Kerberos, etc.  For a
community networks (eg http://www.toaster.net/wireless/community.html)
then there is no need for authentication; the service is explicitly
open, and users ought to use other end-to-end security.

        Hardware tokens, I think, are orthogonal to the question.
Tokens add confidence that keys have not been stolen in a security
breach.



-- 
It's Easy, Fun and Mandatory!!

From jis@MIT.EDU  Fri Jun 29 12:03:35 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA08450;
	Fri, 29 Jun 2001 12:03:35 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA21580;
	Fri, 29 Jun 2001 12:03:35 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA08446;
	Fri, 29 Jun 2001 12:03:35 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id MAA00500;
	Fri, 29 Jun 2001 12:03:36 -0400
Date: Fri, 29 Jun 2001 12:03:36 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010629120336.E424@mit.edu>
References: <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1> <v03110700b75ced35b0eb@[192.233.50.167]> <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]> <20010628195756.C1147@mit.edu> <5.1.0.14.0.20010628170245.02ad8818@127.0.0.1> <20010628201649.F1147@mit.edu> <5.1.0.14.0.20010628171649.02a9afa0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010628171649.02a9afa0@127.0.0.1>; from Kurt@OpenLDAP.org on Thu, Jun 28, 2001 at 05:24:43PM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Thanks.

			-Jeff

On Thu, Jun 28, 2001 at 05:24:43PM -0700, Kurt D. Zeilenga wrote:
> At 05:16 PM 6/28/2001, you wrote:
> >No good reason. Care to contribute text :-)
> 
> I can do that.  I'll send you some text to expand
> section 5 to cover additional IETF generic security
> standards.
> 
> Kurt
> 

From jis@MIT.EDU  Sun Jul  1 13:07:09 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA19426;
	Sun, 1 Jul 2001 13:07:08 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA21756;
	Sun, 1 Jul 2001 13:07:08 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA19422;
	Sun, 1 Jul 2001 13:07:08 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id NAA00874;
	Sun, 1 Jul 2001 13:07:07 -0400
Date: Sun, 1 Jul 2001 13:07:07 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Melinda Shore <mshore@cisco.com>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010701130707.H603@mit.edu>
References: <20010619221440.N686@mit.edu> <v03110700b75ced35b0eb@[192.233.50.167]> <20010628195756.C1147@mit.edu> <02ac01c1009d$707d2640$d45904d1@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <02ac01c1009d$707d2640$d45904d1@cisco.com>; from mshore@cisco.com on Fri, Jun 29, 2001 at 09:14:33AM -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Fri, Jun 29, 2001 at 09:14:33AM -0400, Melinda Shore wrote:
> > The latest version of the document is now in:
> >  http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt
> 
> One additional consideration (or maybe not) is interaction with
> firewalls and NATs, where deployment of the kind of device that
> does payload inspection or payload rewrite is at odds with trying
> to provide end-to-end privacy or end-to-end integrity protection.

Although I agree with you, I'm not sure this is the document that
should make this point. The primary point of the document is to say to
protocol developers "You have to pay attention to security in the
design of your protocol." Now whether or not the protocol should be
NAT friendly is a different (though important) discussion.

			-Jeff

From jis@MIT.EDU  Sun Jul  1 13:21:09 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA19504;
	Sun, 1 Jul 2001 13:21:08 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA22832;
	Sun, 1 Jul 2001 13:21:08 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA19500;
	Sun, 1 Jul 2001 13:21:08 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id NAA00910;
	Sun, 1 Jul 2001 13:21:02 -0400
Date: Sun, 1 Jul 2001 13:21:02 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Christian Huitema <huitema@windows.microsoft.com>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010701132102.I603@mit.edu>
References: <F66A04C29AD9034A8205949AD0C9010418BE8E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BE8E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>; from huitema@windows.microsoft.com on Thu, Jun 28, 2001 at 05:32:16PM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I've just posted a revised version:

 http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt

This version removes the "IPSec and TLS" section and replaces it the
an "IETF Security Technology" section. I removed the reference to
performance considerations as they applied to whether to use IPSec/TLS
or roll your own.

I've added mention of GSSAPI and SASL and reworded the Abstract as
suggested by Paul Hoffman.

			-Jeff

From dhc2@dcrocker.net  Sun Jul  1 14:01:28 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA19699;
	Sun, 1 Jul 2001 14:01:28 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA27193;
	Sun, 1 Jul 2001 14:01:27 -0400 (EDT)
Received: from bbdesk.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112])
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA13951;
	Sun, 1 Jul 2001 11:01:26 -0700
Message-Id: <5.1.0.14.2.20010701105437.02308440@dcrocker.net>
X-Sender: dhc2@dcrocker.net
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 01 Jul 2001 11:00:20 -0700
To: "Jeffrey I. Schiller" <jis@mit.edu>
From: Dave Crocker <dhc2@dcrocker.net>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
In-Reply-To: <20010701132102.I603@mit.edu>
References: <F66A04C29AD9034A8205949AD0C9010418BE8E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
 <F66A04C29AD9034A8205949AD0C9010418BE8E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 10:21 AM 7/1/2001, Jeffrey I. Schiller wrote:
>I've just posted a revised version:
>
>  http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt

Jeff, I like the document quite a lot.

However... I'll suggest that section 9 misses a key point.  Yes, perhaps, 
many eyes glaze over because of algorithm fear, or somesuch. But I suspect 
that is not a core problem.

It appears that there is some deeper, broader, or whatever, barrier to the 
USE of encryption-based mechanisms.  Perhaps this is captured by the adage 
(myth?) that good security cannot be easy to use.

We simply MUST find a way to overcome the barrier to use that plagues 
literally all of the IETF's initiatives in security.  (In terms of 
Internet-wide scale, only SSL has gained acceptance and, of course, it had 
widescale use as TLS, before the IETF touched it.)

Until we do something about this barrier, I fear that excellent 
pronouncements about need will be wasted.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464


From jis@MIT.EDU  Wed Jul  4 22:45:13 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA01478;
	Wed, 4 Jul 2001 22:45:13 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA14077;
	Wed, 4 Jul 2001 22:45:13 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA01474;
	Wed, 4 Jul 2001 22:45:08 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id WAA00540;
	Wed, 4 Jul 2001 22:45:09 -0400
Date: Wed, 4 Jul 2001 22:45:09 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010704224509.C484@mit.edu>
References: <20010619221440.N686@mit.edu> <p05100331b75fd53523dc@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100331b75fd53523dc@[165.227.249.20]>; from phoffman@imc.org on Wed, Jun 27, 2001 at 11:29:49AM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I've been thinking this over. Basically I want to leave this issue for
another document. Exactly what is "strong" enough will vary over
time. This isn't the point of this document. The point of this
document is that you have to do something! We have plenty of people
who want to do nothing about security, they are the audience.

			-Jeff

On Wed, Jun 27, 2001 at 11:29:49AM -0700, Paul Hoffman / IMC wrote:
> Jeff:
> 
> This document would be more useful if you would give some more 
> parameters on what "strong" means. A good example would be to say 
> whether or not a hash of a password (that's password, not pre-shared 
> secret) is considered "strong" enough for authentication in 
> application protocols.
> 
> We all agree that, if encryption is used, the key lengths should 
> be >80 bits at a minimum. If the document wants to just cover 
> encryption, it should actually give some bit lengths. If you want to 
> talk about authentication, you need to have much more discussion 
> about what is and is not acceptable for protocols.
> 
> Without giving guidance, this document can't be said to describe Best 
> Current Practices.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

From Marc.Blanchet@viagenie.qc.ca  Wed Jul  4 22:58:44 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA01540;
	Wed, 4 Jul 2001 22:58:44 -0400 (EDT)
Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA06144;
	Wed, 4 Jul 2001 22:58:44 -0400 (EDT)
Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f653IC144535;
	Wed, 4 Jul 2001 23:18:12 -0400 (EDT)
X-Accept-Language: fr,en,es
Message-Id: <5.1.0.14.1.20010704225244.02b7fe00@mail.viagenie.qc.ca>
X-Sender: blanchet@mail.viagenie.qc.ca
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 04 Jul 2001 23:01:34 -0400
To: "Jeffrey I. Schiller" <jis@mit.edu>, Paul Hoffman / IMC <phoffman@imc.org>
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
In-Reply-To: <20010704224509.C484@mit.edu>
References: <p05100331b75fd53523dc@[165.227.249.20]>
 <20010619221440.N686@mit.edu>
 <p05100331b75fd53523dc@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At/À 22:45 2001-07-04 -0400, Jeffrey I. Schiller you wrote/vous écriviez:
>I've been thinking this over. Basically I want to leave this issue for
>another document.

understand the intent. good idea. but...

>Exactly what is "strong" enough will vary over
>time.

right, but the fundamental things like key size does not change every day.

When things change, the document could be recycled: i.e. another rev -> 
another RFC.

The advantage of Paul idea is that "everything is in one document" so 
target people will get "everything" they need to take care of in one 
document (well that is not completly true since the document is not the end 
of the story for security!, but you get the point). And it is easy to 
remember and reference for them. It could become a popular reference as 
RFC2026...

In some ways, it makes history clear: if an application protocol v1 is done 
based on the state of art at one point in time by refering to a version of 
the sec document (v3), it makes references complete, since the key size 
used in the app protocol v1 will be referred from the advice in the sec doc 
(v3). Later on, a new rev of the app protocol (v2) could reference a new 
rev (v4) of the sec document, which increases the key size.

my 2 cents.

Marc.

>This isn't the point of this document. The point of this
>document is that you have to do something! We have plenty of people
>who want to do nothing about security, they are the audience.
>
>                         -Jeff
>
>On Wed, Jun 27, 2001 at 11:29:49AM -0700, Paul Hoffman / IMC wrote:
> > Jeff:
> >
> > This document would be more useful if you would give some more
> > parameters on what "strong" means. A good example would be to say
> > whether or not a hash of a password (that's password, not pre-shared
> > secret) is considered "strong" enough for authentication in
> > application protocols.
> >
> > We all agree that, if encryption is used, the key lengths should
> > be >80 bits at a minimum. If the document wants to just cover
> > encryption, it should actually give some bit lengths. If you want to
> > talk about authentication, you need to have much more discussion
> > about what is and is not acceptable for protocols.
> >
> > Without giving guidance, this document can't be said to describe Best
> > Current Practices.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > http://jis.mit.edu/mailman/listinfo/saag
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://jis.mit.edu/mailman/listinfo/saag



From ksankar@gte.net  Thu Jul  5 02:57:07 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA02389
	for <saag@jis.mit.edu>; Thu, 5 Jul 2001 02:57:07 -0400 (EDT)
Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA25225
	for <saag@mit.edu>; Thu, 5 Jul 2001 02:57:06 -0400 (EDT)
Received: from ksankarw2k (sj-dial-1-78.cisco.com [171.68.179.79])
	by smtppop3pub.verizon.net  with SMTP
	; id BAA33996249
	Thu, 5 Jul 2001 01:56:28 -0500 (CDT)
From: "Krishna Sankar" <ksankar@gte.net>
To: "Paul Hoffman / IMC" <phoffman@imc.org>, <saag@mit.edu>
Subject: RE: [saag] Encryption and Security Requirements in the IETF
Date: Wed, 4 Jul 2001 23:58:32 -0700
Message-ID: <NABBJDOPDKGCDCNBNEDOGEFNEMAA.ksankar@gte.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <p05100331b75fd53523dc@[165.227.249.20]>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Paul,

	Remember, the notion of strength is relative and depends on the
application. It would be nice if we could have a scale (may be something
like rare, medium, well done :-)) or some other way of relatively
positioning the degree of difficulty and the probability of breaking the
code. Other wise "strong" for one application might not be "strong" for
another system. And if they co-exist, they both will say "strong" which
means different degrees. I know that the document is more to cover the
general principles and IMHO, at least a mention of how to treat the
different degrees would be good.

cheers

  |-----Original Message-----
  |From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of Paul
  |Hoffman / IMC
  |Sent: Wednesday, June 27, 2001 11:30 AM
  |To: saag@mit.edu
  |Subject: Re: [saag] Encryption and Security Requirements in the IETF
  |
  |
  |Jeff:
  |
  |This document would be more useful if you would give some more
  |parameters on what "strong" means. A good example would be to say
  |whether or not a hash of a password (that's password, not pre-shared
  |secret) is considered "strong" enough for authentication in
  |application protocols.
  |
  |We all agree that, if encryption is used, the key lengths should
  |be >80 bits at a minimum. If the document wants to just cover
  |encryption, it should actually give some bit lengths. If you want to
  |talk about authentication, you need to have much more discussion
  |about what is and is not acceptable for protocols.
  |
  |Without giving guidance, this document can't be said to describe Best
  |Current Practices.
  |
  |--Paul Hoffman, Director
  |--Internet Mail Consortium
  |_______________________________________________
  |saag mailing list
  |saag@mit.edu
  |http://jis.mit.edu/mailman/listinfo/saag


From phoffman@imc.org  Fri Jul  6 12:11:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA11169
	for <saag@jis.mit.edu>; Fri, 6 Jul 2001 12:11:38 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA28255
	for <saag@mit.edu>; Fri, 6 Jul 2001 12:11:38 -0400 (EDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20])
	by above.proper.com (8.11.3/8.11.3) with ESMTP id f66GBYm09667
	for <saag@mit.edu>; Fri, 6 Jul 2001 09:11:35 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05100302b76b8f442647@[165.227.249.20]>
In-Reply-To: <20010704224509.C484@mit.edu>
References: <20010619221440.N686@mit.edu>
 <p05100331b75fd53523dc@[165.227.249.20]> <20010704224509.C484@mit.edu>
Date: Fri, 6 Jul 2001 09:10:56 -0700
To: saag@mit.edu
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 10:45 PM -0400 7/4/01, Jeffrey I. Schiller wrote:
>  Exactly what is "strong" enough will vary over
>time.

But it will never drop below a base level. Before 1993ish, the rule 
was 0 bits for encryption. Then the rule was 40 bits. After Danvers, 
it was 56 bits. After 1999ish, it was 112 bits. It is inconceivable 
that the IETF will ever return to one of the previous values. 
Everyone in the Security Area knows that; it should be written down 
somewhere.

>  This isn't the point of this document. The point of this
>document is that you have to do something!

But that's not true. There are zillions of major IETF protocols that 
don't do something. If you intend to change that, you have to be 
honest about what the old rules were, what the new rules are, and 
what the transition strategy will be.

>  We have plenty of people
>who want to do nothing about security, they are the audience.

If the document is supposed to be helpful instead of prescriptive, it 
needs to address the audience. It needs to describe how to tell when 
data is sensitive enough to need encryption. Without such a 
description, the easy reaction is "but important protocols like DNS, 
HTTP, SMTP, and POP are not encrypted; why should our protocol be?" 
Or, if by "security" you meant "encryption and/or authentication", 
you need to describe what acceptable authentication means in the same 
way we all know that acceptable encryption does *not* mean 0, 40, or 
56 bits.

If the document is supposed to be prescriptive about new protocols, 
make the document really short so that there is no possibility of 
misinterpretation. Two pages should be more than enough.

--Paul Hoffman, Director
--Internet Mail Consortium

From MatthewChalmers@FirstUSA.com  Fri Jul  6 13:42:32 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA11762
	for <saag@jis.mit.edu>; Fri, 6 Jul 2001 13:42:32 -0400 (EDT)
Received: from pm01sm.rst.cw.net (PM01SM.RST.CW.NET [204.71.247.136])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA05586
	for <saag@mit.edu>; Fri, 6 Jul 2001 13:42:32 -0400 (EDT)
Received: from swilnts808.wil.fusa.com (gw1.firstusa.com [206.151.92.65])
 by PM01SM.RST.CW.NET (PMDF V5.2-33 #42201)
 with ESMTP id <0GG200EPIBUVX9@PM01SM.RST.CW.NET> for saag@mit.edu; Fri,
 6 Jul 2001 17:42:32 +0000 (GMT)
Received: by swilnts808.wil.fusa.com with Internet Mail Service (5.5.2650.21)
	id <3M3F06AA>; Fri, 06 Jul 2001 13:39:48 -0400
Content-return: allowed
Date: Fri, 06 Jul 2001 13:39:44 -0400
From: "Chalmers, Matthew (FUSA)" <MatthewChalmers@FirstUSA.com>
Subject: RE: [saag] Encryption and Security Requirements in the IETF
To: "'saag@mit.edu'" <saag@mit.edu>
Message-id: <B39104ADF3A0D311878200A0C9B41A1F04FED6AF@swilnts814.wil.fusa.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

With all due respect to the Director...

>>Exactly what is "strong" enough will vary over time. [JS]
>
>But it will never drop below a base level. Before 1993ish, the rule 
>was 0 bits for encryption. Then the rule was 40 bits. After Danvers, 
>it was 56 bits. After 1999ish, it was 112 bits. It is inconceivable 
>that the IETF will ever return to one of the previous values. 
>Everyone in the Security Area knows that; it should be written down 
>somewhere. [PH]

For the document not to be outdated before next year, and not needing to be
updated every few months, there should be little or no mention of key
bit-length. It should be relevant to the cryptographic algorithm, key
schedule, protocol's connection lifetime and the perception of the day.
Today in 2001 no one uses 1024-bit SSL, but not many people would use a
1024-bit DH PGP key pair either, for the opposite reason. Even among
symmetric ciphers, some are strong with smaller keys and others aren't. This
perception is hard to quantify and retain longevity because of Moore's law.
Also, if you have a protocol that makes a secure connection only for a few
milliseconds, it may still be secure with a small key as long as the key is
different every time (of course many factors come into play like replay
attack, etc. but you get the point).

If the document is too vague some people won't know what to do at all and
may use security mechanisms which are entirely too weak or strong; if it is
too cut-n-dry some people will employ exactly what it tells them, if they
can figure out what to apply to their situation, and still end up with
something too weak or strong for the job and the day. The document is not
supposed to be a tutorial on cryptography, however without a little
education we could end up with a lot of loopholes.

Take one easy example. Say the document specifies that 128 bits is the bare
minimum key length for any cryptographic algorithm. We must specify
symmetric otherwise designers will end up with really weak public key
security. 128 bits rules out DES, but what about Triple DES? We need to
specify that too because some people won't get that three small keys is
okeigh. Wait, what if they use three identical keys? That's not as good as
three separate keys but it saves space. Or what if they decide to sacrifice
a little space and use two keys, but keys one and two are the same--and the
particular 3DES algorithm is encrypt, decrypt, encrypt for backward
compatibility...well, that's the same as plain DES.

I don't think this document should get that detailed.

>It needs to describe how to tell when 
>data is sensitive enough to need encryption. Without such a 
>description, the easy reaction is "but important protocols like DNS, 
>HTTP, SMTP, and POP are not encrypted; why should our protocol be?" [PH]

Not necessarily. The document is meant to get protocol engineers to add the
option of secure mode, not to get them to think of every possible kind of
data that it might be used for or to put a value on the only kind of data it
will be used for, or even necessarily to require encryption or other
security 100% of the time. One man's garbage is another's treasure and vice
versa--one person may not care about protecting certain data yet it may be
very valuable to another person. Also, you seem to be insistant that we're
only talking about encryption here. We're not. Not about just encryption
and/or authentication either. It's more than that. And the point about "such
and such protocol is not encrypted" is irrelevant because the document in
question is intended to make security required from now on, regardless of
what was done in the past.

--
Matthew Chalmers
Information Security
FIRST USA BANK, NA

From mcgrew@cisco.com  Fri Jul  6 16:30:36 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12684
	for <saag@jis.mit.edu>; Fri, 6 Jul 2001 16:30:36 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA03748
	for <saag@mit.edu>; Fri, 6 Jul 2001 16:30:36 -0400 (EDT)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f66KSPH05101
	for <saag@mit.edu>; Fri, 6 Jul 2001 13:28:25 -0700 (PDT)
Received: from cisco.com ([171.70.196.154])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AKW04837 (AUTH mcgrew);
	Fri, 6 Jul 2001 13:30:03 -0700 (PDT)
Message-ID: <3B4620FA.C2093007@cisco.com>
Date: Fri, 06 Jul 2001 16:35:06 -0400
From: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [saag] sst comments
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hello,

the following suggestions were made with respect to
draft-mcgrew-saag-sst-00.txt, which is a recently submitted draft on a transform
which provides authentication and confidentiality.  I'd value further input on
these suggestions:

  * make authentication (and "replay checking") mandatory.  This would make the
transform more foolproof.

  * allow authentication coverage to extend beyond the encryption coverage. 
This would make the transform more useful, but would also increase complexity.

  * redefine authentication so that it can use hash functions which are
epsilon-Delta Universal over groups other than binary ones, or even hash
functions that aren't based on universal hashing.  This would allow more extant
auth functions to be directly used.

A few other comments were made and will be reflected in the next version of the
draft:

  * "privacy" should be "confidentiality",

  * the suggestion to limit the number of authentication failures that will be
tolerated by a receiver (Section 8) may introduce a denial of service attack in
some cases.

  * SST is a trademark of the Intel corporation (Shiva Secure Tunnel).  A new
name (or at least a new acronym) is needed :-(

Thanks to Doug Smith, Adam Shostack, and Jesse Walker for their feedback.

thanks,

David
mcgrew@cisco.com

From owner-saag@MIT.EDU  Fri Jul  6 10:50:28 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA10664
	for <saag@jis.mit.edu>; Fri, 6 Jul 2001 10:50:28 -0400 (EDT)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04037
	for <saag@mit.edu>; Fri, 6 Jul 2001 10:50:28 -0400 (EDT)
Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id KAA14695
	Fri, 6 Jul 2001 10:43:59 -0400 (EDT)
From: Internet-Drafts@ietf.org
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Fri, 6 Jul 2001 15:54:43 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 14:30:12 2001
Envelope-to: david@REPLICANTS.FREESERVE.CO.UK
Delivery-date: Tue, 26 Jun 2001 14:30:12 +0100
Received: from [132.151.1.177] (helo=loki.ietf.org)	by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15Esus-0006g0-00; Tue, 26 Jun 2001 14:30:07 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19010	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18553	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:01:48 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27137;	Tue, 26 Jun 2001 07:01:47 -0400 (EDT)
Message-Id: <200106261101.HAA27137@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 26 Jun 2001 07:01:47 -0400
X-OriginalArrivalTime: 06 Jul 2001 14:54:43.0337 (UTC) FILETIME=[97366790:01C1062B]
Subject: [saag] I-D ACTION:draft-mcgrew-saag-sst-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Stream Cipher Security Transform
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-sst-00.txt
	Pages		: 12
	Date		: 25-Jun-01
	
This document describes a cryptographic transform which uses a
stream cipher (which can generate keystream segments in arbitrary
order) and a universal hash function to provide both privacy and
authentication together, or either security service separately.
This transform is efficient, provably secure, appropriate for
network security, and is believed to be patent free.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-sst-00.txt

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-mcgrew-saag-sst-00.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-mcgrew-saag-sst-00.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:	<20010625095516.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-sst-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-sst-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"


From kent@bbn.com  Fri Jul  6 18:49:39 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA13665
	for <saag@jis.mit.edu>; Fri, 6 Jul 2001 18:49:39 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA29576
	for <saag@mit.edu>; Fri, 6 Jul 2001 18:49:39 -0400 (EDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28332
	for <saag@mit.edu>; Fri, 6 Jul 2001 18:50:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010414b76bedd8df2a@[128.33.84.34]>
In-Reply-To: <20010619221440.N686@mit.edu>
References: <20010619221440.N686@mit.edu>
Date: Fri, 6 Jul 2001 18:47:34 -0400
To: saag@mit.edu
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jeff,

I have a number of comments re the document:

Section	Comment
5	the correct spelling is IPsec, not IPSec, as per the RFCs

5	TLS is not a transport layer protocol, despite the name. it operates
	above the transport layer, and thus is really a session layer protocol.
	can we state that here and avoid further, future confusion?

5	performance might be worse, due to the increased volume of data being
	protected, but because many other factors affect performance, this may
	be a misleading statement. also, the cost of developing security on
	a per-application basis, measures in man years of design and 
development
	time may argue against application layer security protocols in many
	instances. this section seems to encourage application developers to
	"roll their own" which hardly seems like a good idea, in the 
grand scheme
	of things

7	good clarification of MUST

8	you might mention here that IF one uses authentication 
mechanisms such as
	passwords, THEN confidentiality might be required just to protect the
	passwords. this further argues against the use of passwords.

10	one must understand how to make use of crypto, even though 
need not be a
	cryptographer, and even this is not a trivial task. that argues for the
	IETF creating a small number of generally applicable crypto-based
	protocols, so that application developers do not have to become smart
	about how to use crypto.


Steve

From kent@bbn.com  Fri Jul  6 18:55:09 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA13725
	for <saag@jis.mit.edu>; Fri, 6 Jul 2001 18:55:09 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA16470
	for <saag@mit.edu>; Fri, 6 Jul 2001 18:55:08 -0400 (EDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28681;
	Fri, 6 Jul 2001 18:56:17 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010415b76bf09182ed@[128.33.84.34]>
In-Reply-To: <p05100302b76b8f442647@[165.227.249.20]>
References: <20010619221440.N686@mit.edu>
 <p05100331b75fd53523dc@[165.227.249.20]> <20010704224509.C484@mit.edu>
 <p05100302b76b8f442647@[165.227.249.20]>
Date: Fri, 6 Jul 2001 18:56:43 -0400
To: Paul Hoffman / IMC <phoffman@imc.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 9:10 AM -0700 7/6/01, Paul Hoffman / IMC wrote:
>At 10:45 PM -0400 7/4/01, Jeffrey I. Schiller wrote:
>>  Exactly what is "strong" enough will vary over
>>time.
>
>But it will never drop below a base level. Before 1993ish, the rule 
>was 0 bits for encryption. Then the rule was 40 bits. After Danvers, 
>it was 56 bits. After 1999ish, it was 112 bits. It is inconceivable 
>that the IETF will ever return to one of the previous values. 
>Everyone in the Security Area knows that; it should be written down 
>somewhere.

The term "strong" in the protocol security context often has a 
specific meaning that is not immediately apparent, but which skirts 
the issue you raise. "Strong authentication" means crypto-based 
authentication, irrespective of the algorithm or key length employed. 
the reason is that crypto-based authentication protocols have the 
capability to be strong, e.g., by selection of appropriate algorithms 
and key lengths, whereas password-based protocols typically do not. 
I have to agree with Matthew that it is not necessary nor appropriate 
to nail down key lengths or algorithms in a document of this sort, 
or, maybe we can put some info in an appendix as a guideline, but 
certainly not in the main stream of the text.

>
>>  This isn't the point of this document. The point of this
>>document is that you have to do something!
>
>But that's not true. There are zillions of major IETF protocols that 
>don't do something. If you intend to change that, you have to be 
>honest about what the old rules were, what the new rules are, and 
>what the transition strategy will be.
>
>>  We have plenty of people
>>who want to do nothing about security, they are the audience.
>
>If the document is supposed to be helpful instead of prescriptive, 
>it needs to address the audience. It needs to describe how to tell 
>when data is sensitive enough to need encryption. Without such a 
>description, the easy reaction is "but important protocols like DNS, 
>HTTP, SMTP, and POP are not encrypted; why should our protocol be?" 
>Or, if by "security" you meant "encryption and/or authentication", 
>you need to describe what acceptable authentication means in the 
>same way we all know that acceptable encryption does *not* mean 0, 
>40, or 56 bits.

I don't think one can explain in much detail, or in much generality, 
when data is sensitive.  Beyond a few obvious examples, this is a 
context sensitive determination. However, I would like to see the 
document discuss a generic threat model that we believe should be 
adopted. I was disappointed to see a recent ID for mobile host 
security that proposes an authentication mechanism that it admits is 
NOT secure against man-in-the-middle attacks.  Ought we not explain 
general classes of attacks, and motivate the adoption of protocols 
that are resistant to MITM attacks?

Again, I don't think algorithms or key lengths are the central issue 
here.  We know how to design protocols that are largely algorithm 
independent. Setting algorithm and key length constraints is 
relatively easy compared to the rest of the engineering and standards 
development for secure protocols.

>
>If the document is supposed to be prescriptive about new protocols, 
>make the document really short so that there is no possibility of 
>misinterpretation. Two pages should be more than enough.

I fear that the document really needs to be longer, not shorter, to 
better motivate the principles being advocated.

Steve

From jlinn@rsasecurity.com  Mon Jul  9 11:06:36 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA26560
	for <saag@jis.mit.edu>; Mon, 9 Jul 2001 11:06:36 -0400 (EDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id LAA23858
	for <saag@mit.edu>; Mon, 9 Jul 2001 11:06:35 -0400 (EDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com
          via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 9 Jul 2001 15:05:08 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA26125;
	Mon, 9 Jul 2001 11:06:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19)
	id <LR8TPJNK>; Mon, 9 Jul 2001 11:06:27 -0400
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01F7CA17@exna07.securitydynamics.com>
From: "Linn, John" <jlinn@rsasecurity.com>
To: "'Stephen Kent'" <kent@bbn.com>, Paul Hoffman / IMC <phoffman@imc.org>
Cc: saag@mit.edu
Subject: RE: [saag] Encryption and Security Requirements in the IETF
Date: Mon, 9 Jul 2001 11:06:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Steve wrote, excerpting:

> At 9:10 AM -0700 7/6/01, Paul Hoffman / IMC wrote:
> >At 10:45 PM -0400 7/4/01, Jeffrey I. Schiller wrote:
> >>  Exactly what is "strong" enough will vary over
> >>time.
> >
> >But it will never drop below a base level. Before 1993ish, the rule
> >was 0 bits for encryption. Then the rule was 40 bits. After Danvers,
> >it was 56 bits. After 1999ish, it was 112 bits. It is inconceivable
> >that the IETF will ever return to one of the previous values.
> >Everyone in the Security Area knows that; it should be written down
> >somewhere.
>
> The term "strong" in the protocol security context often has a
> specific meaning that is not immediately apparent, but which skirts
> the issue you raise. "Strong authentication" means crypto-based
> authentication, irrespective of the algorithm or key length employed.
> the reason is that crypto-based authentication protocols have the
> capability to be strong, e.g., by selection of appropriate algorithms
> and key lengths, whereas password-based protocols typically do not.
> I have to agree with Matthew that it is not necessary nor appropriate
> to nail down key lengths or algorithms in a document of this sort,
> or, maybe we can put some info in an appendix as a guideline, but
> certainly not in the main stream of the text.
>

I think there may be some risk of confusion in equating strong and
crypto-based authentication, and in distinguishing them from password-based
authentication as a separate category. Note that the strength of any
authentication technique depends on several factors, including at least:

1) the entropy of its secrets
2) the quality of those secrets' storage,
3) the means through which the secrets are applied to perform an
authentication transaction
4) protection facilities (if any) within the protocols that carry the
authentication transactions

If one were to construct (mistakenly or otherwise) an AES-based
authentication protocol using keys limited to 8 bits of entropy, it would be
unfortunate to infer that such a scheme was stronger than, e.g., one-time
passwords, simply as a result of its being directly based on cryptography.
Further, consider techniques like EKE, SPEKE, or PDM, which apply passwords
as secrets yet integrate them with cryptographic methods to provide enhanced
protection; these are password-based, but have protection characteristics
very different from simple password methods.

Generally, I think it's clarifying to distinguish authentication of protocol
peers from authentication of associated individuals (if any), but am not
sure how this fits relative to the appropriate scope of the draft. The
secrets that authenticate a user vs. the secrets that authenticate a
protocol peer may not be the same; in different contexts, cryptographic
methods may be used for either or both. Increasingly, we can assume that
protocol entities have the ability to store and operate with cryptographic
keys, even though the protection quality of their key storage may be
limited. We can't generally expect people to remember or enter high-entropy
secrets, however; to execute a strong cryptographic protocol on behalf of a
person, we either need some sort of personal protected hardware or a means
(whether distributed protocol or local interface) to obtain and unlock
cryptographic-level credentials, usually based on the password-level secret
that a person can enter.

--jl

From kent@bbn.com  Mon Jul  9 11:30:31 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA26743
	for <saag@jis.mit.edu>; Mon, 9 Jul 2001 11:30:31 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA12442
	for <saag@mit.edu>; Mon, 9 Jul 2001 11:30:31 -0400 (EDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29749;
	Mon, 9 Jul 2001 11:31:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010407b76f7c36c301@[128.33.84.34]>
In-Reply-To: 
 <F504A8CEE925D411AF4A00508B8BE90A01F7CA17@exna07.securitydynamics.com>
References: 
 <F504A8CEE925D411AF4A00508B8BE90A01F7CA17@exna07.securitydynamics.com>
Date: Mon, 9 Jul 2001 11:28:40 -0400
To: "Linn, John" <jlinn@rsasecurity.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [saag] Encryption and Security Requirements in the IETF
Cc: saag@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 11:06 AM -0400 7/9/01, Linn, John wrote:
>Steve wrote, excerpting:
>
>>  At 9:10 AM -0700 7/6/01, Paul Hoffman / IMC wrote:
>>  >At 10:45 PM -0400 7/4/01, Jeffrey I. Schiller wrote:
>>  >>  Exactly what is "strong" enough will vary over
>>  >>time.
>>  >
>>  >But it will never drop below a base level. Before 1993ish, the rule
>>  >was 0 bits for encryption. Then the rule was 40 bits. After Danvers,
>>  >it was 56 bits. After 1999ish, it was 112 bits. It is inconceivable
>>  >that the IETF will ever return to one of the previous values.
>>  >Everyone in the Security Area knows that; it should be written down
>>  >somewhere.
>>
>>  The term "strong" in the protocol security context often has a
>>  specific meaning that is not immediately apparent, but which skirts
>>  the issue you raise. "Strong authentication" means crypto-based
>>  authentication, irrespective of the algorithm or key length employed.
>>  the reason is that crypto-based authentication protocols have the
>>  capability to be strong, e.g., by selection of appropriate algorithms
>>  and key lengths, whereas password-based protocols typically do not.
>>  I have to agree with Matthew that it is not necessary nor appropriate
>>  to nail down key lengths or algorithms in a document of this sort,
>>  or, maybe we can put some info in an appendix as a guideline, but
>>  certainly not in the main stream of the text.
>>
>
>I think there may be some risk of confusion in equating strong and
>crypto-based authentication, and in distinguishing them from password-based
>authentication as a separate category. Note that the strength of any
>authentication technique depends on several factors, including at least:
>
>1) the entropy of its secrets
>2) the quality of those secrets' storage,
>3) the means through which the secrets are applied to perform an
>authentication transaction
>4) protection facilities (if any) within the protocols that carry the
>authentication transactions
>
>If one were to construct (mistakenly or otherwise) an AES-based
>authentication protocol using keys limited to 8 bits of entropy, it would be
>unfortunate to infer that such a scheme was stronger than, e.g., one-time
>passwords, simply as a result of its being directly based on cryptography.
>Further, consider techniques like EKE, SPEKE, or PDM, which apply passwords
>as secrets yet integrate them with cryptographic methods to provide enhanced
>protection; these are password-based, but have protection characteristics
>very different from simple password methods.
>
>Generally, I think it's clarifying to distinguish authentication of protocol
>peers from authentication of associated individuals (if any), but am not
>sure how this fits relative to the appropriate scope of the draft. The
>secrets that authenticate a user vs. the secrets that authenticate a
>protocol peer may not be the same; in different contexts, cryptographic
>methods may be used for either or both. Increasingly, we can assume that
>protocol entities have the ability to store and operate with cryptographic
>keys, even though the protection quality of their key storage may be
>limited. We can't generally expect people to remember or enter high-entropy
>secrets, however; to execute a strong cryptographic protocol on behalf of a
>person, we either need some sort of personal protected hardware or a means
>(whether distributed protocol or local interface) to obtain and unlock
>cryptographic-level credentials, usually based on the password-level secret
>that a person can enter.

John,

I agree that the strength of an authentication mechanism depends on 
many factors, including ones not addressed in your brief analysis 
above. I was just noting that standards terminology has employed the 
phrase "strong authentication" in a specific way in the past.

I also agree that one can distinguish between protocol peer 
authentication and user authentication, as you note, but one needs to 
be careful in doing so.  We may differ here in what constitutes 
examples of each. I've often heard folks say that IPsec does not 
offer user authentication, and as an example they cite a private key 
stored on a laptop and activate by a password. The same folks have 
agreed that if the user held a crypto token with the users private 
key inside, then that would constitute user authentication. This 
distinction is nonsense and suggests that there is confusion about 
where we draw the line between protocol peer and user authentication.

Steve

From jis@MIT.EDU  Tue Jul 10 22:24:27 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA07397
	for <saag@jis.mit.edu>; Tue, 10 Jul 2001 22:24:27 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA04836
	for <saag@mit.edu>; Tue, 10 Jul 2001 22:24:20 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA07391;
	Tue, 10 Jul 2001 22:24:00 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id WAA01009;
	Tue, 10 Jul 2001 22:23:57 -0400
Date: Tue, 10 Jul 2001 22:23:57 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: saag@mit.edu
Cc: The Internet Engineering Steering Group <iesg@ietf.org>
Message-ID: <20010710222357.D855@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [saag] http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt submitted
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt contains the
version that I just submitted to the I-D directory. Wanted to get it
in there before the deadline...

			-Jeff

From jis@MIT.EDU  Tue Jul 10 22:29:45 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA07464;
	Tue, 10 Jul 2001 22:29:45 -0400 (EDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA24579;
	Tue, 10 Jul 2001 22:29:44 -0400 (EDT)
Received: from jis.tzo.com (localhost [127.0.0.1])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA07460;
	Tue, 10 Jul 2001 22:29:44 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.8.7/8.8.7) id WAA01027;
	Tue, 10 Jul 2001 22:29:41 -0400
Date: Tue, 10 Jul 2001 22:29:41 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Stephen Kent <kent@bbn.com>
Cc: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF
Message-ID: <20010710222941.F855@mit.edu>
References: <20010619221440.N686@mit.edu> <p05010414b76bedd8df2a@[128.33.84.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05010414b76bedd8df2a@[128.33.84.34]>; from kent@bbn.com on Fri, Jul 06, 2001 at 06:47:34PM -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Fri, Jul 06, 2001 at 06:47:34PM -0400, Stephen Kent wrote:
> Section	Comment
> 5	the correct spelling is IPsec, not IPSec, as per the RFCs
>
> 5	TLS is not a transport layer protocol, despite the name. it operates
> 	above the transport layer, and thus is really a session layer protocol.
> 	can we state that here and avoid further, future confusion?
> 
> 5	performance might be worse, due to the increased volume of data being
> 	protected, but because many other factors affect performance, this may
> 	be a misleading statement. also, the cost of developing security on
> 	a per-application basis, measures in man years of design and 
> development
> 	time may argue against application layer security protocols in many
> 	instances. this section seems to encourage application developers to
> 	"roll their own" which hardly seems like a good idea, in the 
> grand scheme
> 	of things

I completely rewrote section 5. I got IPsec spelled right this time.

> 7	good clarification of MUST

Thank you.

> 8	you might mention here that IF one uses authentication 
> mechanisms such as
> 	passwords, THEN confidentiality might be required just to protect the
> 	passwords. this further argues against the use of passwords.

This is more detail then I wanted to get into... but I can be convinced
otherwise.

> 10	one must understand how to make use of crypto, even though 
> need not be a
> 	cryptographer, and even this is not a trivial task. that argues for the
> 	IETF creating a small number of generally applicable crypto-based
> 	protocols, so that application developers do not have to become smart
> 	about how to use crypto.

Can you suggest a clear and concise way to get this across?

			-Jeff

From Estella931@aol.com  Tue Jul 10 14:39:56 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA04621
	for <saag@jis.mit.edu>; Tue, 10 Jul 2001 14:39:56 -0400 (EDT)
From: Estella931@aol.com
Received: from imo-r07.mx.aol.com (imo-r07.mx.aol.com [152.163.225.103])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19384
	for <saag@mit.edu>; Tue, 10 Jul 2001 14:39:56 -0400 (EDT)
Received: from Estella931@aol.com
	by imo-r07.mx.aol.com (mail_out_v30.22.) id 6.62.10fccdcf (4420)
	 for <saag@mit.edu>; Tue, 10 Jul 2001 14:39:52 -0400 (EDT)
Message-ID: <62.10fccdcf.287ca5f8@aol.com>
Date: Tue, 10 Jul 2001 14:39:52 EDT
To: saag@mit.edu
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_62.10fccdcf.287ca5f8_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10520
Subject: [saag] questions
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--part1_62.10fccdcf.287ca5f8_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

         Hello. I am researching cybercrime.  I would like to know if your 
members and the community of people who run the internet in general are aware 
of hte Council of Europe's convention on Cybercrime, to which Canada and the 
US will be parties.  I wanted to konw if you have any input opinion regarding 
this new piece of international legislation.  It has come under attack for 
violating privacy rights and lacking an understanding of the internet and its 
functions.  If you have any information at all regarding the opinion of your 
organization and the creators of the internet on this piece of legislation, 
could you please let me know?  Thank you.  -M. Shah

--part1_62.10fccdcf.287ca5f8_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=1>  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hello. I am researching cybercrime. &nbsp;I would like to know if your 
<BR>members and the community of people who run the internet in general are aware 
<BR>of hte Council of Europe's convention on Cybercrime, to which Canada and the 
<BR>US will be parties. &nbsp;I wanted to konw if you have any input opinion regarding 
<BR>this new piece of international legislation. &nbsp;It has come under attack for 
<BR>violating privacy rights and lacking an understanding of the internet and its 
<BR>functions. &nbsp;If you have any information at all regarding the opinion of your 
<BR>organization and the creators of the internet on this piece of legislation, 
<BR>could you please let me know? &nbsp;Thank you. &nbsp;-M. Shah</FONT></HTML>

--part1_62.10fccdcf.287ca5f8_boundary--

From mouse@Twig.Rodents.Montreal.QC.CA  Wed Jul 11 01:37:53 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id BAA08295
	for <saag@jis.mit.edu>; Wed, 11 Jul 2001 01:37:53 -0400 (EDT)
Received: from Twig.Rodents.Montreal.QC.CA (root@Twig.Rodents.Montreal.QC.CA [216.46.5.3])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA00910
	for <saag@mit.edu>; Wed, 11 Jul 2001 01:37:41 -0400 (EDT)
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA24519;
	Wed, 11 Jul 2001 01:34:22 -0400 (EDT)
Date: Wed, 11 Jul 2001 01:34:22 -0400 (EDT)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200107110534.BAA24519@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: Estella931@aol.com
Cc: saag@mit.edu
Subject: Re: [saag] questions
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Hello.  I am researching cybercrime.

...by which you mean?  I can plausibly see this as meaning anything
from "any crime in which a computer was even vaguely involved" to
"breaches of the rules by which the net runs, regardless of whether
they contravene any meatspace laws".  The feeling the term gives me is
"sensationalist media hype about the Big Bad Internet", which makes me
tend towards the first definition - but you're aware of the saag list,
which indicates at least *some* degree of clue and hence pushes me away
from that interpretation.  So I don't know.

> I would like to know if your members and the community of people who
> run the internet in general are aware of hte Council of Europe's
> convention on Cybercrime, to which Canada and the US will be parties.

I can't speak for anyone else, but I was not aware of it.

> I wanted to konw if you have any input opinion regarding this new
> piece of international legislation.

Yes: assuming of course that what you said above is true, it is being
done irresponsibly.  I am contact for two .ca domains, yet I have not
had any apparent attempt to alert me to new law attempting to affect
the net.  This is legislating in a vacuum.  See below.

Not that this is surprising.  See below again.

> It has come under attack for violating privacy rights and lacking an
> understanding of the internet and its functions.

Of *course* it lacks an understanding of the Internet and its
functions - I have yet to even *hear of* a legislator who actually has
anything approximating a clue about the net.  Any such legislation is
thus being created in a vacuum, and will function about as well as
you'd expect from traffic laws written by people who've never even
tried to drive, or insider-trading regulations by people who've never
traded stocks, or any of the endless other similar analogies I'm sure
you can come up with on your own.

This is not to say that people with clue never create laws.  The net
has been creating laws and enforcement mechanisms to enforce them ever
since it first started, back before it was the Internet, back when it
was still largely funded by the National Science Foundation in the USA.
(They aren't and weren't called laws and courts and police, probably in
part because they bear comparatively little resemblance to the
meatspace versions thereof, but that's really what they are.)  Like any
new territory less than forty years old, it's still largely in the
vigilante stage of shaking down just what sort of legal machinery it
needs and wants - but it's happening and if left alone, it will be
rough for a little while but will end up settling down, just like the
"Wild West" in the USA, or any of many similar territories elsewhere.

I think there are two big problems, though.  One is that few people
realize that this is what's happening and hence view the current
lawlessness as disregard for law rather than as the first stages in the
evolution of appropriate law; the other is that, unlike the analogies I
mentioned above, it overlaps to a very large degree with established
societies and established legal systems, and its existence is based on
infrastructures dependent on those societies and under the jurisdiction
of those legal systems.  This makes it subject to those legal systems
to some extent; to compound matters, there are many such legal
sysstems, differing to greater or lesser degrees, and they exert
varying degrees of influence over the parts of the net supported by
infrastructures in their jurisdicta.

It doesn't help that the net is to a certain degree anarchic in nature
and inherently reacts to attempts to impose meatspace law on it by
evolving ways to ignore that law - and in some cases taking a
civil-disobedience stance towards it; witness the CDA debacle in the
USA.  The net also moves immensely faster than any meatspace
legislature or court system, with the possible exception of a "whim of
the dictator" system; in the time it takes to enact a law, two
generations of design and implementation of the thing supposedly being
legislated about can come and go.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From adam@zeroknowledge.com  Wed Jul 11 11:14:20 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA10534
	for <saag@jis.mit.edu>; Wed, 11 Jul 2001 11:14:15 -0400 (EDT)
Received: from cc.zeroknowledge.com (cc.zeroknowledge.com [207.107.114.244])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20590
	for <saag@mit.edu>; Wed, 11 Jul 2001 11:14:15 -0400 (EDT)
Received: from smartypants.zks.net (smartypants.zks.net [192.168.1.4])
	by cc.zeroknowledge.com (8.9.3/8.9.3) with ESMTP id LAA24758;
	Wed, 11 Jul 2001 11:14:13 -0400
Received: from computer (adam.dev.zks.net [10.16.3.144])
	by smartypants.zks.net (8.9.3/8.9.3) with SMTP id LAA06827;
	Wed, 11 Jul 2001 11:14:13 -0400
Received: (from adam@localhost)
	by adam.zks.net (8.9.3/8.9.3) id LAA03581;
	Wed, 11 Jul 2001 11:15:54 -0400
Date: Wed, 11 Jul 2001 11:15:54 -0400
From: Adam Shostack <adam@zeroknowledge.com>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: Estella931@aol.com, saag@mit.edu
Subject: Re: [saag] questions
Message-ID: <20010711111554.A3548@zeroknowledge.com>
References: <200107110534.BAA24519@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200107110534.BAA24519@Twig.Rodents.Montreal.QC.CA>; from mouse@Rodents.Montreal.QC.CA on Wed, Jul 11, 2001 at 01:34:22AM -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Wed, Jul 11, 2001 at 01:34:22AM -0400, der Mouse wrote:
> I can't speak for anyone else, but I was not aware of it.
> 
> > I wanted to konw if you have any input opinion regarding this new
> > piece of international legislation.
> 
> Yes: assuming of course that what you said above is true, it is being
> done irresponsibly.  I am contact for two .ca domains, yet I have not
> had any apparent attempt to alert me to new law attempting to affect
> the net.  This is legislating in a vacuum.  See below.

The Council of Europe is proposing a "convention," which will then be
implemented in national laws.

A group of security experts wrote to the Council, expressing concern
over a number of provisions, see
http://www.cerias.purdue.edu/homes/spaf/coe/

Adam

-- 
It's Easy, Fun and Mandatory!!

From paf@cisco.com  Wed Jul 11 03:41:42 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA08736;
	Wed, 11 Jul 2001 03:41:42 -0400 (EDT)
Received: from cisco.com (nordic.cisco.com [64.103.48.45])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id DAA05916;
	Wed, 11 Jul 2001 03:41:41 -0400 (EDT)
Received: from dhcp-64-103-49-12.cisco.com (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA01042;
	Wed, 11 Jul 2001 09:41:09 +0200 (MET DST)
Date: Wed, 11 Jul 2001 09:35:03 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "Jeffrey I. Schiller" <jis@mit.edu>, saag@mit.edu
cc: The Internet Engineering Steering Group <iesg@ietf.org>
Message-ID: <2386307.994844103@localhost>
X-Mailer: Mulberry/2.1.0b2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [saag] Re: http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt submitted
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--On 01-07-10 22.23 -0400 "Jeffrey I. Schiller" <jis@mit.edu> wrote:

> http://jis.mit.edu/saag/draft-ietf-saag-whyenc-00.txt contains the
> version that I just submitted to the I-D directory. Wanted to get it
> in there before the deadline...

Good!

  paf
 

From owner-saag@MIT.EDU  Thu Jul 12 07:07:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id HAA16497
	for <saag@jis.mit.edu>; Thu, 12 Jul 2001 07:07:50 -0400 (EDT)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id HAA12116
	for <saag@mit.edu>; Thu, 12 Jul 2001 07:07:49 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id HAA29821
	Thu, 12 Jul 2001 07:01:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01836;
	Thu, 12 Jul 2001 07:06:58 -0400 (EDT)
Message-Id: <200107121106.HAA01836@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: saag@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 12 Jul 2001 07:06:57 -0400
Subject: [saag] I-D ACTION:draft-ietf-saag-whyenc-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Security Area Directorate Meeting Working Group of the IETF.

	Title		: Encryption and Security Requirements for IETF Standard
                          Protocols
	Author(s)	: J. Schiller
	Filename	: draft-ietf-saag-whyenc-00.txt
	Pages		: 8
	Date		: 11-Jul-01
	
It is the consensus of the IETF that IETF standard protocols MUST
make use of appropriate strong security mechanisms. This document
describes the history and rationale for this doctrine and establishes
this doctrine as a best current practice.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

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-saag-whyenc-00.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-saag-whyenc-00.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:	<20010711155851.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-saag-whyenc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-saag-whyenc-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010711155851.I-D@ietf.org>

--OtherAccess--

--NextPart--



From paulfordh@uk.ibm.com  Mon Jul 16 14:13:31 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11259
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 14:13:26 -0400 (EDT)
Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA24204
	for <saag@mit.edu>; Mon, 16 Jul 2001 14:13:25 -0400 (EDT)
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147])
	by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id SAA170854
	for <saag@mit.edu>; Mon, 16 Jul 2001 18:56:19 +0100
Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16])
	by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6GICm332058
	for <saag@mit.edu>; Mon, 16 Jul 2001 19:12:49 +0100
Importance: Normal
MIME-Version: 1.0
To: saag@mit.edu
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
From: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
Message-ID: <OF206DECB6.B20A3C7B-ON80256A8B.00633388@portsmouth.uk.ibm.com>
Date: Mon, 16 Jul 2001 19:11:39 +0100
X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/07/2001 19:11:49,
	Serialize complete at 16/07/2001 19:11:49
Content-Type: text/plain; charset="us-ascii"
Subject: [saag] FTP over TLS
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hello all, 

I am trying to work out how to move forward the internet draft which 
discusses how FTP and TLS should interoperate, onto Standards track.  (the 
draft is draft-murray-auth-ftp-ssl-07.txt)   This draft has been around 
for about 4 years and has not really changed much after revision 2 or 3.

After approaching the RFC editor and the Security Area directors, It has 
been suggested that I raise the question on this list. 

The draft is the FTP equivalent to RFC2817 (http over TLS); RFC2595 (imap, 
pop3 and acap over TLS) and RFC2487 (smtp over TLS).  There are several 
client and server implementations currently deployed.  (see http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html for info)  so I believe we should try to formalise the approach rather 
than leaving this in internet-draft state.

Does anyone have any suggestions for a next step ?


Thanks,
Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh@uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005


From jaltman@columbia.edu  Mon Jul 16 14:17:43 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11304
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 14:17:43 -0400 (EDT)
Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA07287
	for <saag@mit.edu>; Mon, 16 Jul 2001 14:17:42 -0400 (EDT)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA10893;
	Mon, 16 Jul 2001 14:17:34 -0400 (EDT)
Date: Mon, 16 Jul 2001 14:17:34 EDT
From: Jeffrey Altman <jaltman@columbia.edu>
Reply-To: jaltman@columbia.edu
To: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
Cc: saag@mit.edu
Subject: Re: [saag] FTP over TLS
In-Reply-To: Your message of Mon, 16 Jul 2001 19:11:39 +0100
Message-ID: <CMM.0.90.4.995307454.jaltman@watsun.cc.columbia.edu>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Paul:

I suggest you follow the same track that I did for the Telnet drafts.
Simply submit them to the Security Area director and request an IETF
Last Call for Standards Track.  As we have discussed in the past, the
old "SSL" method should be pulled out and placed in its own
Informational Draft.  The "TLS" method should be Standards Track.

- Jeff



> Hello all, 
> 
> I am trying to work out how to move forward the internet draft which 
> discusses how FTP and TLS should interoperate, onto Standards track.  (the 
> draft is draft-murray-auth-ftp-ssl-07.txt)   This draft has been around 
> for about 4 years and has not really changed much after revision 2 or 3.
> 
> After approaching the RFC editor and the Security Area directors, It has 
> been suggested that I raise the question on this list. 
> 
> The draft is the FTP equivalent to RFC2817 (http over TLS); RFC2595 (imap, 
> pop3 and acap over TLS) and RFC2487 (smtp over TLS).  There are several 
> client and server implementations currently deployed.  (see http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html for info)  so I believe we should try to formalise the approach rather 
> than leaving this in internet-draft state.
> 
> Does anyone have any suggestions for a next step ?
> 
> 
> Thanks,
> Paul
> 
> --
> Paul Ford-Hutchinson :  eCommerce application security : 
> paulfordh@uk.ibm.com
> MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
> 462005
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag
> 



 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 kermit-support@kermit-project.org          OpenSSL.  SSH soon to follow.

From rja@inet.org  Mon Jul 16 14:25:56 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11404
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 14:25:56 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA28573
	for <saag@mit.edu>; Mon, 16 Jul 2001 14:25:56 -0400 (EDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 2E23C8266E; Mon, 16 Jul 2001 14:25:09 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010716141859.009fee70@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 16 Jul 2001 14:20:43 -0400
To: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] FTP over TLS
Cc: saag@mit.edu
In-Reply-To: <OF206DECB6.B20A3C7B-ON80256A8B.00633388@portsmouth.uk.ibm.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 14:11 16/07/01, Paul V Ford-Hutchinson wrote:
>I am trying to work out how to move forward the internet draft which 
>discusses how FTP and TLS should interoperate, onto Standards track.  (the 
>draft is draft-murray-auth-ftp-ssl-07.txt)   This draft has been around 
>for about 4 years and has not really changed much after revision 2 or 3.

        I don't know that it needs/should be on the standards-track,
because deployment is not widespread and does not seem very likely
to become widespread (even if it were a standards-track RFC).

        Perhaps a better goal would be to publish your specification 
as an Informational RFC.  That way folks who want to implement/deploy
can do so against a stable, open specification.  This approach is
also MUCH MUCH simpler than trying to go standards-track.

Ran
rja@inet.org


From jaltman@columbia.edu  Mon Jul 16 14:28:52 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11462
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 14:28:52 -0400 (EDT)
Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10929
	for <saag@mit.edu>; Mon, 16 Jul 2001 14:28:51 -0400 (EDT)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA12662;
	Mon, 16 Jul 2001 14:28:42 -0400 (EDT)
Date: Mon, 16 Jul 2001 14:28:40 EDT
From: Jeffrey Altman <jaltman@columbia.edu>
Reply-To: jaltman@columbia.edu
To: RJ Atkinson <rja@inet.org>
Cc: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>, saag@mit.edu
Subject: Re: [saag] FTP over TLS
In-Reply-To: Your message of Mon, 16 Jul 2001 14:20:43 -0400
Message-ID: <CMM.0.90.4.995308120.jaltman@watsun.cc.columbia.edu>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> At 14:11 16/07/01, Paul V Ford-Hutchinson wrote:
> >I am trying to work out how to move forward the internet draft which 
> >discusses how FTP and TLS should interoperate, onto Standards track.  (the 
> >draft is draft-murray-auth-ftp-ssl-07.txt)   This draft has been around 
> >for about 4 years and has not really changed much after revision 2 or 3.
> 
>         I don't know that it needs/should be on the standards-track,
> because deployment is not widespread and does not seem very likely
> to become widespread (even if it were a standards-track RFC).
> 
>         Perhaps a better goal would be to publish your specification 
> as an Informational RFC.  That way folks who want to implement/deploy
> can do so against a stable, open specification.  This approach is
> also MUCH MUCH simpler than trying to go standards-track.

There are at least three separate interoperable implementations of 
this internet-draft. 



 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 kermit-support@kermit-project.org          OpenSSL.  SSH soon to follow.

From rja@inet.org  Mon Jul 16 14:38:14 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11544
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 14:38:14 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA13989
	for <saag@mit.edu>; Mon, 16 Jul 2001 14:38:14 -0400 (EDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id A4B768266E
	for <saag@mit.edu>; Mon, 16 Jul 2001 14:37:42 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010716143120.00a1c5e0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 16 Jul 2001 14:33:16 -0400
To: saag@mit.edu
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] FTP over TLS
In-Reply-To: <CMM.0.90.4.995308120.jaltman@watsun.cc.columbia.edu>
References: <Your message of Mon, 16 Jul 2001 14:20:43 -0400>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 14:28 16/07/01, Jeffrey Altman wrote:
>There are at least three separate interoperable implementations of 
>this internet-draft. 

...and negligible deployment relative to the global Internet.  

        Having multiple implementations of something is not by itself
sufficient grounds to suggest that it is worth the hassle/cost 
of pushing it onto the standards track.

        I stand by my suggestion to publish the spec as Informational.

Ran
rja@inet.org


From jaltman@columbia.edu  Mon Jul 16 15:03:18 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11716
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:03:18 -0400 (EDT)
Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22467
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:03:17 -0400 (EDT)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA17511;
	Mon, 16 Jul 2001 15:03:10 -0400 (EDT)
Date: Mon, 16 Jul 2001 15:02:56 EDT
From: Jeffrey Altman <jaltman@columbia.edu>
Reply-To: jaltman@columbia.edu
To: RJ Atkinson <rja@inet.org>
Cc: saag@mit.edu
Subject: Re: [saag] FTP over TLS
In-Reply-To: Your message of Mon, 16 Jul 2001 14:33:16 -0400
Message-ID: <CMM.0.90.4.995310176.jaltman@watsun.cc.columbia.edu>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> At 14:28 16/07/01, Jeffrey Altman wrote:
> >There are at least three separate interoperable implementations of 
> >this internet-draft. 
> 
> ...and negligible deployment relative to the global Internet.  
> 
>         Having multiple implementations of something is not by itself
> sufficient grounds to suggest that it is worth the hassle/cost 
> of pushing it onto the standards track.
> 

And whose fault is that?  Few if any of the security extensions to FTP
have been given wide deployment.  The same is true of those for
Telnet.  That's not to say that they do not belong on the standards
track.  The reasons that they have not been widely deployed are well
known:

U.S. owned Operating Systems manufacturers refused for years to deploy
security in the base services for fear of either falling under the
E.A.R. provisions; or giving the impression that the U.S. versions
were more secure than the non-U.S. versions.  Even today the operating
systems that do provide for TLS in the box do not deploy it on all
services.  The only widely deployed FTP daemons are those that ship
with the operating system.  Anything else is simply going to have a
small percentage of the installed base.

The reason for making the "SSL" security extension informational is
because it is not compliant with RFC 2228.  The revised "TLS" security
extension is complaint with RFC 2228 (a Proposed Standard) and
therefore should be Standards Track.  Perhaps if we actually brought
this document to RFC status there would be some pressure on companies
such as Microsoft to implement support for it in their FTP servers.




 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 kermit-support@kermit-project.org          OpenSSL.  SSH soon to follow.

From rodney@tillerman.to  Mon Jul 16 15:31:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11917
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:31:38 -0400 (EDT)
Received: from xena.pkiclue.com (IDENT:root@marge.intermag.com [216.218.196.15])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20299
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:31:37 -0400 (EDT)
Received: from opcenter2.tillerman.to (IDENT:root@xena.pkiclue.com [216.218.196.15])
	by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id LAA13062
	for <saag@mit.edu>; Mon, 16 Jul 2001 11:32:41 -0700
Message-Id: <5.0.0.25.2.20010716122033.034f9480@127.0.0.1>
X-Sender: rodney@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 16 Jul 2001 12:31:43 -0700
To: saag@mit.edu
From: Rodney Thayer <rodney@tillerman.to>
Subject: Re: [saag] FTP over TLS
In-Reply-To: <CMM.0.90.4.995310176.jaltman@watsun.cc.columbia.edu>
References: <Your message of Mon, 16 Jul 2001 14:33:16 -0400>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This reeks of old IETF geezers in wheelchairs,
muttering something like...

   "if IPsec were deployed back in the 50's, like we wanted,
    we would not have SSL and all these problems"

If you want consistency, ask why we have FTP over TLS, and,
in the same standards body, have Secure Copy over SSH.  Or,
why don't we run rcp over IPsec over IPv6?  Everyone has that,
don't they?

I agree with Jeffrey.  We have a chicken and egg problem,
and we should standardize this so the network community (e.g.
the users) can choose to pressure their implementors for support
of it.  I'd rather use FTP (which is universal) over TLS (which is,
effectively, universal, since both Microsoft and Linux support it),
with a standard.

At 03:02 PM 7/16/01 -0400, Jeffrey Altman wrote:
> > At 14:28 16/07/01, Jeffrey Altman wrote:
> > >There are at least three separate interoperable implementations of
> > >this internet-draft.
...

(and Ran Atkinson wrote...)
> > ...and negligible deployment relative to the global Internet.
...


From rja@inet.org  Mon Jul 16 15:34:30 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11955
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:34:30 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21580
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:34:29 -0400 (EDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id 0C4498266E
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:33:58 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010716152722.00a12490@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 16 Jul 2001 15:29:31 -0400
To: saag@mit.edu
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] FTP over TLS
In-Reply-To: <CMM.0.90.4.995310176.jaltman@watsun.cc.columbia.edu>
References: <Your message of Mon, 16 Jul 2001 14:33:16 -0400>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 15:02 16/07/01, Jeffrey Altman wrote:
>> At 14:28 16/07/01, Jeffrey Altman wrote:
>> >There are at least three separate interoperable implementations of 
>> >this internet-draft. 
>> 
>> ...and negligible deployment relative to the global Internet.  
>> 
>>         Having multiple implementations of something is not by itself
>> sufficient grounds to suggest that it is worth the hassle/cost 
>> of pushing it onto the standards track.
>> 
>
>And whose fault is that?  

        Fault is not the question here.    Bottom line is that the 
marketplace uses HTTP with SSLv3 instead of using FTP for protected 
file transfers.  This deployed approach works fine and is already 
standard.  This fact has nothing to do with your (complex geo-political)
analysis.

Ran


From rodney@tillerman.to  Mon Jul 16 15:39:22 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA12003
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:39:22 -0400 (EDT)
Received: from xena.pkiclue.com (IDENT:root@marge.intermag.com [216.218.196.15])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA23359
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:39:21 -0400 (EDT)
Received: from opcenter2.tillerman.to (IDENT:root@xena.pkiclue.com [216.218.196.15])
	by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id LAA13098
	for <saag@mit.edu>; Mon, 16 Jul 2001 11:40:26 -0700
Message-Id: <5.0.0.25.2.20010716123950.03a468a0@127.0.0.1>
X-Sender: rodney@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 16 Jul 2001 12:41:53 -0700
To: saag@mit.edu
From: Rodney Thayer <rodney@tillerman.to>
Subject: Re: [saag] FTP over TLS
In-Reply-To: <5.1.0.14.2.20010716152722.00a12490@10.30.15.2>
References: <CMM.0.90.4.995310176.jaltman@watsun.cc.columbia.edu>
 <Your message of Mon, 16 Jul 2001 14:33:16 -0400>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

the marketplace uses HTTP to spit files at users.  it has essentially
no capability to send files back.  I believe the bidirectional file
transfer problem was solved about 20 years ago, and it's called FTP,
so let's just secure it and get over it...

At 03:29 PM 7/16/01 -0400, RJ Atkinson wrote:
>  Bottom line is that the
>marketplace uses HTTP with SSLv3 instead of using FTP for protected
>file transfers.  This deployed approach works fine and is already
>standard.  This fact has nothing to do with your (complex geo-political)
>analysis.


From rja@inet.org  Mon Jul 16 15:40:52 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA12042
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:40:52 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA23857
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:40:52 -0400 (EDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id A370D8266E
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:40:19 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010716153303.01dd1ec0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 16 Jul 2001 15:35:52 -0400
To: saag@mit.edu
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] FTP over TLS
In-Reply-To: <5.0.0.25.2.20010716122033.034f9480@127.0.0.1>
References: <CMM.0.90.4.995310176.jaltman@watsun.cc.columbia.edu>
 <Your message of Mon, 16 Jul 2001 14:33:16 -0400>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 15:31 16/07/01, Rodney Thayer wrote:
>we should standardize this so the network community (e.g.
>the users) can choose to pressure their implementors for support
>of it.  

        I've been equally successful (and unsuccessful) over
the years in getting my vendors/implementors to support some
spec with standards-track RFCs and mundane RFCs.  The critical
thing for success is usually to have an open and complete 
specification, not whether a given document is on the standards-track.

        There is a widespread myth that stuff gets implemented
because its standards-track.  Empirical evidence doesn't really
support that myth.  Perhaps that is a pity, not sure.  It is
real though.

        Clearly some folks get different mileage than I do. :-)

Cheers,

Ran



From steve@stevecrocker.com  Mon Jul 16 15:55:47 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA12186
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:55:47 -0400 (EDT)
Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28644
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:55:46 -0400 (EDT)
Received: from [128.128.175.240] (HELO sdc2.stevecrocker.com)
  by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
  with ESMTP id 2563867; Mon, 16 Jul 2001 15:55:45 -0400
Message-Id: <5.0.2.1.2.20010716155238.023e47f0@mail.stevecrocker.com>
X-Sender: steve@stevecrocker.com@mail.stevecrocker.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 16 Jul 2001 15:54:51 -0400
To: Rodney Thayer <rodney@tillerman.to>
From: Steve Crocker <steve@stevecrocker.com>
Subject: Re: [saag] FTP over TLS
Cc: saag@mit.edu
In-Reply-To: <5.0.0.25.2.20010716122033.034f9480@127.0.0.1>
References: <CMM.0.90.4.995310176.jaltman@watsun.cc.columbia.edu>
 <Your message of Mon, 16 Jul 2001 14:33:16 -0400>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

As old geezer, I agree with the sentiment and will even take blame for not 
paying closer attention to security at the beginning -- late 60s, of 
course, not 50s.  Of course, public key crypto hadn't been invented yet, at 
least not publicly...

Steve



At 12:31 PM 7/16/2001 -0700, Rodney Thayer wrote:
>This reeks of old IETF geezers in wheelchairs,
>muttering something like...
>
>   "if IPsec were deployed back in the 50's, like we wanted,
>    we would not have SSL and all these problems"
>
>If you want consistency, ask why we have FTP over TLS, and,
>in the same standards body, have Secure Copy over SSH.  Or,
>why don't we run rcp over IPsec over IPv6?  Everyone has that,
>don't they?
>
>I agree with Jeffrey.  We have a chicken and egg problem,
>and we should standardize this so the network community (e.g.
>the users) can choose to pressure their implementors for support
>of it.  I'd rather use FTP (which is universal) over TLS (which is,
>effectively, universal, since both Microsoft and Linux support it),
>with a standard.
>
>At 03:02 PM 7/16/01 -0400, Jeffrey Altman wrote:
>> > At 14:28 16/07/01, Jeffrey Altman wrote:
>> > >There are at least three separate interoperable implementations of
>> > >this internet-draft.
>...
>
>(and Ran Atkinson wrote...)
>> > ...and negligible deployment relative to the global Internet.
>...
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://jis.mit.edu/mailman/listinfo/saag

----------------------------------
Steve Crocker Associates, LLC                 Bus: +1 301 654 4707
5110 Edgemoor Lane                            Fax: +1 202 478 0458
Bethesda, MD 20814                            steve@stevecrocker.com


From phoffman@imc.org  Mon Jul 16 16:34:09 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12487
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 16:34:09 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23402
	for <saag@mit.edu>; Mon, 16 Jul 2001 16:34:09 -0400 (EDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20])
	by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GKY3q26128;
	Mon, 16 Jul 2001 13:34:03 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0510035db778ff4f829c@[165.227.249.20]>
In-Reply-To: <5.1.0.14.2.20010716152722.00a12490@10.30.15.2>
References: <Your message of Mon, 16 Jul 2001 14:33:16 -0400>
 <5.1.0.14.2.20010716152722.00a12490@10.30.15.2>
Date: Mon, 16 Jul 2001 13:33:11 -0700
To: RJ Atkinson <rja@inet.org>, saag@mit.edu
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [saag] FTP over TLS
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 3:29 PM -0400 7/16/01, RJ Atkinson wrote:
>  Bottom line is that the
>marketplace uses HTTP with SSLv3 instead of using FTP for protected
>file transfers.

That doesn't seem true. SSL for file transfer is extremely rare. In 
day-to-day use, SSL is only for web page interaction.

This should be on standards track. It should also be at least 
mentioned on the ietf-apps-tls@imc.org mailing list, which discusses 
foo-over-TLS protocols.

--Paul Hoffman, Director
--Internet Mail Consortium

From moore@cs.utk.edu  Mon Jul 16 15:54:07 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA12159
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 15:54:07 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA09555
	for <saag@mit.edu>; Mon, 16 Jul 2001 15:54:06 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA11395;
        Mon, 16 Jul 2001 15:53:53 -0400 (EDT)
Message-Id: <200107161953.PAA11395@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: RJ Atkinson <rja@inet.org>
cc: saag@mit.edu
Subject: Re: [saag] FTP over TLS 
In-reply-to: Your message of "Mon, 16 Jul 2001 14:33:16 EDT."
             <5.1.0.14.2.20010716143120.00a1c5e0@10.30.15.2> 
Date: Mon, 16 Jul 2001 15:53:53 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> >There are at least three separate interoperable implementations of
> >this internet-draft.
> 
> ...and negligible deployment relative to the global Internet.
> 
>         Having multiple implementations of something is not by itself
> sufficient grounds to suggest that it is worth the hassle/cost
> of pushing it onto the standards track.

True.  But deployment isn't by itself a justification either.

Keith

From moore@cs.utk.edu  Mon Jul 16 17:03:05 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA12667
	for <saag@jis.mit.edu>; Mon, 16 Jul 2001 17:03:05 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17575
	for <saag@mit.edu>; Mon, 16 Jul 2001 17:03:04 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA12241;
        Mon, 16 Jul 2001 17:03:01 -0400 (EDT)
Message-Id: <200107162103.RAA12241@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Paul Hoffman / IMC <phoffman@imc.org>
cc: RJ Atkinson <rja@inet.org>, saag@mit.edu
Subject: Re: [saag] FTP over TLS 
In-reply-to: Your message of "Mon, 16 Jul 2001 13:33:11 PDT."
             <p0510035db778ff4f829c@[165.227.249.20]> 
Date: Mon, 16 Jul 2001 17:03:01 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

yeah, I really have to disagree with Ran's arguments about the utility of FTP.

and while SAAG and the security area would certainly have something to say about 
the security (or lack thereof) provided by a particular approach, determining the 
utility of FTP-over-TLS seems like more of an issue for applications groups.

the ftpext wg is mostly wound down, but the list might be a good place to start
asking who is interested.  at least at one time, several FTP implementors were there.

Keith

From owner-saag@MIT.EDU  Wed Jul 18 07:02:11 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id HAA22810
	for <saag@jis.mit.edu>; Wed, 18 Jul 2001 07:02:11 -0400 (EDT)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA15342
	for <saag@mit.edu>; Wed, 18 Jul 2001 07:02:11 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id GAA15024
	Wed, 18 Jul 2001 06:55:25 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26591;
	Wed, 18 Jul 2001 07:01:11 -0400 (EDT)
Message-Id: <200107181101.HAA26591@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 18 Jul 2001 07:01:10 -0400
Subject: [saag] I-D ACTION:draft-mcgrew-saag-tmmh-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Truncated Multi-Modular Hash Function (TMMH)
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-tmmh-00.txt
	Pages		: 6
	Date		: 17-Jul-01
	
TMMH is a `universal' hash function suitable for message
authentication in the Wegman-Carter paradigm, as in the Stream
Cipher Security Transform.  It is simple, quick, and especially
appropriate for Digital Signal Processors and other processors with
a fast multiply operation, though a straightforward implementation
requires storage equal in length to the largest message to be
hashed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-tmmh-00.txt

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-mcgrew-saag-tmmh-00.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-mcgrew-saag-tmmh-00.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:	<20010717133853.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-tmmh-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-tmmh-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010717133853.I-D@ietf.org>

--OtherAccess--

--NextPart--



From mouse@Twig.Rodents.Montreal.QC.CA  Wed Jul 18 10:39:07 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA24015
	for <saag@jis.mit.edu>; Wed, 18 Jul 2001 10:39:06 -0400 (EDT)
Received: from Twig.Rodents.Montreal.QC.CA (root@Twig.Rodents.Montreal.QC.CA [216.46.5.3])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA15423
	for <saag@mit.edu>; Wed, 18 Jul 2001 10:39:05 -0400 (EDT)
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA28024;
	Wed, 18 Jul 2001 10:38:46 -0400 (EDT)
Date: Wed, 18 Jul 2001 10:38:46 -0400 (EDT)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200107181438.KAA28024@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: mcgrew@cisco.com
Cc: saag@mit.edu
Subject: Re: [saag] I-D ACTION:draft-mcgrew-saag-tmmh-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> http://www.ietf.org/internet-drafts/draft-mcgrew-saag-tmmh-00.txt

Section 3 ("TMMH/16"), first paragraph, first sentence:
s/a multiple/multiples/

Same section, second paragraph, last sentence: shouldn't that be
"2 * KEY_WORDS", not "2 * MSG_WORDS"?  (Since KEY_LENGTH is a multiple
of two, it is the same thing - and might be simpler - to say that
KEY_WORDS is KEY_LENGTH/2.)

It also appears to me that the definition of TMMH/16 involves accessing
nonexistent elements of M[], if TAG_WORDS > 1.  This is because j can
then be greater than zero, which means M[j+MSG_WORDS] can be greater
than MSG_WORDS.  Mutatis mutandis, the same applies to TMMH/32.  (The
remark about cyclic use of the key material makes me suspect that the
"j+" is supposed to be absent from the M[] subscripts; as it stands,
K[] and M[] subscripts are always equal and there's nothing cyclic
about it.)

Also, something is, at the very least, unclear.  I'd like to think I
can follow directions, and indeed the values I compute match the test
vectors for TMMH/16 - at least for the first two; I can't compute the
third one because it involves a nonexistent M[] element.  But for
TMMH/32, my values disagree with the results given.

I do have to assume how KEY_WORDS is defined for TMMH/32, since this is
not stated.  Since extra key material is presented, I infer that it is
supposed to be KEY_LENGTH/4.

Here's what I get.  (All values are hex; I omit the 0x prefix.)

For the first test vector, we have

key		01 23 45 67 89 ab cd ef fe dc ba 98
message		ca fe ba be ba de de ed
KEY_LENGTH	c
TAG_LENGTH	4

Then I find, in order,

MAX_HASH_LENGTH	8
MESSAGE_LENGTH	8
KEY_WORDS	3
K[]		01234567 89abcdef fedcba98
MSG_WORDS	2
M[]		cafebabe badedeed
hash		( ( K[0] * MESSAGE_LENGTH   +64
		    K[1] * M[1]             +64
		    K[2] * M[2] ) mod 10000000f ) mod 100000000 =
		( ( 01234567 * 8         +64
		    89abcdef * cafebabe  +64
		    fedcba98 * badedeed ) mod 10000000f ) mod 100000000 =
		( ( 00000000091a2b38  +64
		    6d2a8d61ea447d62  +64
		    ba0a40eb9bf88eb8 ) mod 10000000f ) mod 100000000 =
		( 2734ce4d8f573752 mod 10000000f ) mod 100000000 =
		433f20ed
		-> 43 3f 20 ed

which bears no obvious relation to the stated value, a2 bb e1 b1.

If I take the draft strictly as stated and let KEY_WORDS be
KEY_LENGTH/2, using two octets for each K[] value (in the low 16 bits
of K[], with the high bits zero), then there is exactly twice as much
key material as needed, and I find that the hash becomes 6c f5 01 ff.
If I let the key material appear in the high 16 bits of K[] instead, I
get 01 f8 9d a5.

Have I made an arithmetic mistake?  Or is the mistake in the draft?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From paul.hoffman@vpnc.org  Fri Jul 20 11:11:24 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA10163
	for <saag@jis.mit.edu>; Fri, 20 Jul 2001 11:11:24 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA21702
	for <saag@mit.edu>; Fri, 20 Jul 2001 11:11:23 -0400 (EDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20])
	by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KFBKq03524
	for <saag@mit.edu>; Fri, 20 Jul 2001 08:11:20 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05100333b77df9579949@[165.227.249.20]>
Date: Fri, 20 Jul 2001 08:10:07 -0700
To: saag@mit.edu
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [saag] Determining Strengths For Public Keys
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Greetings again. Hilarie and I have made significant changes to our 
public key strengths document. We think it is now pretty complete, 
and we want to take it to IETF last call after London. However, 
having all the SAAG folks pore over it now might find places for 
improvement before IETF last call. Please read through it and send 
any comments you have to us or, preferably, to the SAAG mailing list. 
Thanks!

	Title		: Determining Strengths For Public Keys Used For
                           Exchanging Symmetric Keys
	Author(s)	: H. Orman, P. Hoffman
	Filename	: draft-orman-public-key-lengths-03.txt
	Pages		:
	Date		: 19-Jul-01


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-orman-public-key-lengths-03.txt

--Paul Hoffman, Director
--VPN Consortium

From mleech@nortelnetworks.com  Tue Jul 24 09:44:20 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA02565
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 09:44:20 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21697
	for <saag@mit.edu>; Tue, 24 Jul 2001 09:44:19 -0400 (EDT)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6ODhO918486
	for <saag@mit.edu>; Tue, 24 Jul 2001 09:43:24 -0400 (EDT)
Received: from rftzy232.ca.nortel.com by zcars04e.ca.nortel.com;
          Tue, 24 Jul 2001 09:43:15 -0400
Received: from NORTELNETWORKS.COM (wftzh00e.ca.nortel.com [47.130.116.9]) 
          by rftzy232.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id NKPL5SLG; Tue, 24 Jul 2001 09:43:09 -0400
Message-ID: <3B5D7B80.7A41D9E6@NORTELNETWORKS.COM>
Date: Tue, 24 Jul 2001 09:43:28 -0400
From: "Marcus Leech" <mleech@nortelnetworks.com>
X-Mailer: Mozilla 4.73C-CCK-MCD [en] (X11; U; HP-UX B.10.20 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <mleech@NORTELNETWORKS.COM>
Subject: [saag] Presentation on SHAMAN at SAAG session in London
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I have a request from someone in the wireless industry to do a brief presentation
  on a unified security architecture for various wireless technologies.  The
  project is called SHAMAN.

He's asked for 15 minutes, and I can't decide, so I'm putting it out to you
  fine folks to ask for your opinion.  Is this someone we want to spend our
  time on at the SAAG session?

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  +1 613 763 9145
Security Architecture and Planning       Fax:   (ESN) 393-9435  +1 613 763 9435
Nortel Networks                          mleech@nortelnetworks.com
-----------------Expressed opinions are my own, not my employer's------

From warlord@MIT.EDU  Tue Jul 24 10:19:34 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA02857
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 10:19:34 -0400 (EDT)
Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA03235
	for <saag@mit.edu>; Tue, 24 Jul 2001 10:19:34 -0400 (EDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3)
	id KAA30866; Tue, 24 Jul 2001 10:19:23 -0400
To: "Marcus Leech" <mleech@nortelnetworks.com>
Cc: saag@MIT.EDU
Subject: Re: [saag] Presentation on SHAMAN at SAAG session in London
References: <3B5D7B80.7A41D9E6@NORTELNETWORKS.COM>
From: Derek Atkins <warlord@MIT.EDU>
Date: 24 Jul 2001 10:19:23 -0400
In-Reply-To: "Marcus Leech"'s message of "Tue, 24 Jul 2001 09:43:28 -0400"
Message-ID: <sjmg0bm9zpw.fsf@rcn.ihtfp.org>
Lines: 41
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Is he willing to be bashed into the ground when he shows his lack of
knowledge about security or a solution that is completely
non-conformant to all existing standards?  ;)

[ Note: I'm hoping neither of these two cases is true, but having
worked with wireless people for the past year I'm not getting my hopes
up ]

Seriously, I think it's always useful to find out what others are
doing __IF__ they are in a position (e.g. the ITU) to make their work
into some kind of "standard."

-derek

"Marcus Leech" <mleech@nortelnetworks.com> writes:

> I have a request from someone in the wireless industry to do a brief presentation
>   on a unified security architecture for various wireless technologies.  The
>   project is called SHAMAN.
> 
> He's asked for 15 minutes, and I can't decide, so I'm putting it out to you
>   fine folks to ask for your opinion.  Is this someone we want to spend our
>   time on at the SAAG session?
> 
> -- 
> ----------------------------------------------------------------------
> Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
> Advisor                                  Phone: (ESN) 393-9145  +1 613 763 9145
> Security Architecture and Planning       Fax:   (ESN) 393-9435  +1 613 763 9435
> Nortel Networks                          mleech@nortelnetworks.com
> -----------------Expressed opinions are my own, not my employer's------
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From Kurt@OpenLDAP.org  Tue Jul 24 10:27:43 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA02913
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 10:27:42 -0400 (EDT)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA22693
	for <saag@mit.edu>; Tue, 24 Jul 2001 10:27:40 -0400 (EDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f6OEOGC74068;
	Tue, 24 Jul 2001 14:24:16 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010724071643.00afc7b8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Jul 2001 07:23:52 -0700
To: "Marcus Leech" <mleech@nortelnetworks.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [saag] Presentation on SHAMAN at SAAG session in London
Cc: saag@mit.edu
In-Reply-To: <3B5D7B80.7A41D9E6@NORTELNETWORKS.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 06:43 AM 7/24/2001, Marcus Leech wrote:
>I have a request from someone in the wireless industry to do a brief presentation
>  on a unified security architecture for various wireless technologies.  The
>  project is called SHAMAN.

Is there an I-D? or other public technical documents?

Has this someone read the "note well"?

Kurt


From moore@cs.utk.edu  Tue Jul 24 10:51:49 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA03107
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 10:51:49 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29942
	for <saag@mit.edu>; Tue, 24 Jul 2001 10:51:48 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA10309;
        Tue, 24 Jul 2001 10:50:40 -0400 (EDT)
Message-Id: <200107241450.KAA10309@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: "Marcus Leech" <mleech@nortelnetworks.com>
cc: saag@mit.edu
Subject: Re: [saag] Presentation on SHAMAN at SAAG session in London 
In-reply-to: Your message of "Tue, 24 Jul 2001 09:43:28 EDT."
             <3B5D7B80.7A41D9E6@NORTELNETWORKS.COM> 
Date: Tue, 24 Jul 2001 10:50:40 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I don't see how folks can evaluate whether to spend precious meeting time
on a proposal from knowing only the name of the project.

But in general, these things are rarely a good use of meeting time.
If it's really a good idea, he can write up an I-D explaining it. 
Or point people to a web page.  

Keith

From rodney@tillerman.to  Tue Jul 24 11:30:10 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA03412
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 11:30:10 -0400 (EDT)
Received: from xena.pkiclue.com (IDENT:root@marge.intermag.com [216.218.196.15])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27984
	for <saag@mit.edu>; Tue, 24 Jul 2001 11:30:09 -0400 (EDT)
Received: from opcenter2.tillerman.to (IDENT:root@xena.pkiclue.com [216.218.196.15])
	by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id HAA18145;
	Tue, 24 Jul 2001 07:31:20 -0700
Message-Id: <5.0.0.25.2.20010724083126.03de26c0@127.0.0.1>
X-Sender: rodney@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 24 Jul 2001 08:32:13 -0700
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "Marcus Leech" <mleech@nortelnetworks.com>
From: Rodney Thayer <rodney@tillerman.to>
Subject: Re: [saag] Presentation on SHAMAN at SAAG session in London
Cc: saag@mit.edu
In-Reply-To: <5.1.0.14.0.20010724071643.00afc7b8@127.0.0.1>
References: <3B5D7B80.7A41D9E6@NORTELNETWORKS.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

or, more coarsley put, given past experience, is there any
hard evidence anyone with the vaguest possible technical clue about
security was involved in creating this, otherwise go away and
write it up first.

At 07:23 AM 7/24/01 -0700, Kurt D. Zeilenga wrote:
>At 06:43 AM 7/24/2001, Marcus Leech wrote:
> >I have a request from someone in the wireless industry to do a brief 
> presentation
> >  on a unified security architecture for various wireless technologies.  The
> >  project is called SHAMAN.
>
>Is there an I-D? or other public technical documents?
>
>Has this someone read the "note well"?
>
>Kurt
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://jis.mit.edu/mailman/listinfo/saag


From timothy.wright@vodafone.com  Tue Jul 24 12:31:43 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA03863
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 12:31:43 -0400 (EDT)
From: timothy.wright@vodafone.com
Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA06011
	for <saag@mit.edu>; Tue, 24 Jul 2001 12:31:42 -0400 (EDT)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id RAA27974; Tue, 24 Jul 2001 17:31:12 +0100 (BST)
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0008701117@mimesweeper1.vfl.vodafone> for <saag@mit.edu>;
 Tue, 24 Jul 2001 17:28:21 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id <PR4HPQHK>; Tue, 24 Jul 2001 17:26:48 +0100
Message-Id: <DDC3D921FB67D211AAD100A0C9E58F5308A8B82D@HAMPSTEAD>
To: saag@mit.edu
Date: Tue, 24 Jul 2001 17:26:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [saag] Presentation on SHAMAN at SAAG
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I've just joined the list, and it was me who asked Marcus for time at SAAG.

Keith is right that you don't have enough info to make a decision, so here
is my original mail to Marcus and Jeff:

"Marcus, Jeff, I am writing to ask if I can give a presentation at the SAAG
plenary in London. I know this is late but the SAAG plenary did not appear
on the agenda until recently (unless I missed it earlier).  I gave a
presentation on WAP security at the SAAG last year in Pittsburgh.

Vodafone are leading a project called SHAMAN (www.ist-shaman.org - but not
too much on the site yet).  SHAMAN will be looking at developing a unified
security archi for distributed and configurable mobile terminals accessing
core networks through a variety of access networks (2 and 3G cellular,
Bluetooth, wireless LAN, fixed).   The work is impacted by and (will
hopefully) impact upon the IETF.  The project is composed of VF, Ericsson,
Nokia, Siemens, Deutches Telekom, G&D and Royal Holloway College (out of
Fred Piper's group), so contains some significant companies.  We aim to
generate solutions of real significance and put these into standards.  The
project is a follow on to USECA (Umts SECurity Architecture) which designed
the security mechanisms for 3GPP - we aim to be as successful in a wireless
internet world.  15 minutes would be fine."

So, 
Derek, we are totally committed to standards, including the IETF.
Kurt, there will be public deliverables on the web site soon.  They are
first deliverables though, so not much new information.  Some good reviews
of access technologies though.  But we have just started, so no i-d's yet.
This is just to tell you about the project and get these sort of
questions/misunderstandings out of the way before we do submit something,
and also to get whatever early feedback people are gracious enough to give.
Rodney, you might want to have a look at the 3GPP security archi (grab spec
33.102 off www.3gpp.org) to see whether we have any security knowledge.  If
you find a hole, please let us know.
Keith, there is your web page.

To the person who said they had never met someone from the wireless world
who knew much about security, I guess you better try mixing with a better
class of wireless person ...

Tim

From moore@cs.utk.edu  Tue Jul 24 13:37:05 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA04376
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 13:37:05 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25582
	for <saag@mit.edu>; Tue, 24 Jul 2001 13:37:04 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA11371;
        Tue, 24 Jul 2001 13:36:46 -0400 (EDT)
Message-Id: <200107241736.NAA11371@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: timothy.wright@vodafone.com
cc: saag@mit.edu
Subject: Re: [saag] Presentation on SHAMAN at SAAG 
In-reply-to: Your message of "Tue, 24 Jul 2001 17:26:45 BST."
             <DDC3D921FB67D211AAD100A0C9E58F5308A8B82D@HAMPSTEAD> 
Date: Tue, 24 Jul 2001 13:36:46 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I guess the question is - why should you get 15 minutes to speak when you
don't even have a written proposal yet?  

From timothy.wright@vodafone.com  Tue Jul 24 13:44:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA04447
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 13:44:50 -0400 (EDT)
From: timothy.wright@vodafone.com
Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA13559
	for <saag@mit.edu>; Tue, 24 Jul 2001 13:44:50 -0400 (EDT)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id SAA03735; Tue, 24 Jul 2001 18:44:19 +0100 (BST)
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0008702312@mimesweeper1.vfl.vodafone> for <saag@mit.edu>;
 Tue, 24 Jul 2001 18:41:48 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id <PR4HPRFX>; Tue, 24 Jul 2001 18:40:13 +0100
Message-Id: <DDC3D921FB67D211AAD100A0C9E58F5308A8B831@HAMPSTEAD>
To: saag@mit.edu
Subject: RE: [saag] Presentation on SHAMAN at SAAG 
Date: Tue, 24 Jul 2001 18:40:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Keith, what sort of proposal are you after?  If you go to
www.ist-shaman.org, then Public Documents, then Project Snapshot, you'll get
a project summary.

Tim

> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: 24 July 2001 18:37
> To: timothy.wright@vodafone.com
> Cc: saag@mit.edu
> Subject: Re: [saag] Presentation on SHAMAN at SAAG 
> 
> 
> I guess the question is - why should you get 15 minutes to 
> speak when you
> don't even have a written proposal yet?  
> 

From moore@cs.utk.edu  Tue Jul 24 15:20:03 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA05671
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 15:20:03 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA16506
	for <saag@mit.edu>; Tue, 24 Jul 2001 15:20:03 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA12143;
        Tue, 24 Jul 2001 15:20:01 -0400 (EDT)
Message-Id: <200107241920.PAA12143@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: timothy.wright@vodafone.com
cc: saag@mit.edu
Subject: Re: [saag] Presentation on SHAMAN at SAAG 
In-reply-to: Your message of "Tue, 24 Jul 2001 18:40:12 BST."
             <DDC3D921FB67D211AAD100A0C9E58F5308A8B831@HAMPSTEAD> 
Date: Tue, 24 Jul 2001 15:20:01 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Keith, what sort of proposal are you after?  If you go to
> www.ist-shaman.org, then Public Documents, then Project Snapshot, you'll get
> a project summary.

that has essentially zero technical content.  do you have technical
proposals to make to IETF, or not?

Keith

p.s. IMHO any security infrastructure should not be specific to mobile
terminals - as at least some mobile terminals will connect to the wired
internet from time to time.  So a mobile-only authentication proposal
is not very interesting.

From smb@research.att.com  Tue Jul 24 17:08:24 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA06559
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 17:08:24 -0400 (EDT)
Received: from berkshire.research.att.com (H-135-207-10-200.research.att.com [135.207.10.200])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA05379
	for <saag@mit.edu>; Tue, 24 Jul 2001 17:08:24 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 120A37B57; Tue, 24 Jul 2001 17:08:22 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: Keith Moore <moore@cs.utk.edu>
Cc: timothy.wright@vodafone.com, saag@mit.edu
Subject: Re: [saag] Presentation on SHAMAN at SAAG 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 24 Jul 2001 17:08:22 -0400
Message-Id: <20010724210823.120A37B57@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <200107241920.PAA12143@astro.cs.utk.edu>, Keith Moore writes:

>
>p.s. IMHO any security infrastructure should not be specific to mobile
>terminals - as at least some mobile terminals will connect to the wired
>internet from time to time.  So a mobile-only authentication proposal
>is not very interesting.

More to the point, there is very little in the threat models we deal 
with that is specific to wireless nodes.

		--Steve Bellovin, http://www.research.att.com/~smb



From hodges@breakaway.Stanford.EDU  Tue Jul 24 20:01:15 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA07531
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 20:01:15 -0400 (EDT)
Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA12612
	for <saag@mit.edu>; Tue, 24 Jul 2001 20:01:14 -0400 (EDT)
Received: from localhost (hodges@localhost)
	by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA12997
	for <saag@mit.edu>; Tue, 24 Jul 2001 17:01:13 -0700 (PDT)
Message-Id: <200107250001.RAA12997@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Re: [saag] Encryption and Security Requirements in the IETF 
To: saag@mit.edu
In-reply-to: "Jeffrey I. Schiller" <jis@mit.edu> 's message of 
	Tue, 10 Jul 2001 22:29:41 -0400
Reply-to: saag@MIT.EDU
From: Jeff.Hodges@kingsmountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 24 Jul 2001 17:01:13 -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I'm curious as to the relationship between..

  http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

..and..

  http://www.ietf.org/internet-drafts/draft-rescorla-sec-cons-03.txt

..if any. I haven't seen the latter mentioned yet in this thread. 

It seems to me that these two I-Ds intersect a fair amount. IMHO 
draft-rescorla-sec-cons-03 contains worthwhile material, as certainly does  
draft-ietf-saag-whyenc-00.

Is anyone thinking about merging these documents?  Or, if not, what delineates 
them?

thanks,

JeffH



From hodges@breakaway.Stanford.EDU  Tue Jul 24 20:13:11 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA07641
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 20:13:10 -0400 (EDT)
Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA26264
	for <saag@mit.edu>; Tue, 24 Jul 2001 20:13:10 -0400 (EDT)
Received: from localhost (hodges@localhost)
	by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA13059
	for <saag@mit.edu>; Tue, 24 Jul 2001 17:13:09 -0700 (PDT)
Message-Id: <200107250013.RAA13059@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Re: [saag] Encryption and Security Requirements in the IETF 
To: saag@mit.edu
In-reply-to: Stephen Kent <kent@bbn.com> 's message of 
	Fri, 06 Jul 2001 18:47:34 -0400
Reply-to: saag@MIT.EDU
From: Jeff.Hodges@kingsmountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 24 Jul 2001 17:13:09 -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

kent@bbn.com said:
> also, the cost of developing security on
> 	a per-application basis, measures in man years of design and
> development
> 	time may argue against application layer security protocols in many
> 	instances. this section seems to encourage application developers to
> 	"roll their own" which hardly seems like a good idea, in the  grand
> scheme
> 	of things

Indeed. I happened to be discussing this with Ned & Patrick & Paul the Sunday 
evening of the 50th IETF (Minneapolis) and got signed up to give an 
extemporaneous talk on "Security Design for Application Protocols" at the
Apps Area session the next morning. 

FWIW, the talk's available here (URLs are folded)..

http://www.stanford.edu/~hodges/talks
 /Hodges-SecurityDesignForAppProtocols-2001-04-10.pdf
 /Hodges-SecurityDesignForAppProtocols-2001-04-10.html
 /Hodges-SecurityDesignForAppProtocols-2001-04-10.ppt


The overall conclusion is: "if yer gonna invent yet-another-app-protocol, then 
you should strongly consider using a framework such as BEEP wherein much of 
one's app-protocol-security-considerations are addressed. If yer not going to 
use BEEP, then you should strongly consider designing-in use of SASL for 
authentication, and a 'StartTLS' command (a la RFC2830 and others) with which 
to establish TLS on the same port."


JeffH



From moore@cs.utk.edu  Tue Jul 24 22:59:38 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA08331
	for <saag@jis.mit.edu>; Tue, 24 Jul 2001 22:59:38 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA21974
	for <saag@mit.edu>; Tue, 24 Jul 2001 22:59:38 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA14902
        for <saag@mit.edu>; Tue, 24 Jul 2001 22:59:37 -0400 (EDT)
Message-Id: <200107250259.WAA14902@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: saag@mit.edu
Subject: Re: [saag] Encryption and Security Requirements in the IETF 
In-reply-to: Your message of "Tue, 24 Jul 2001 17:13:09 PDT."
             <200107250013.RAA13059@breakaway.Stanford.EDU> 
Date: Tue, 24 Jul 2001 22:59:37 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> The overall conclusion is: "if yer gonna invent yet-another-app-protocol, then
> you should strongly consider using a framework such as BEEP wherein much of
> one's app-protocol-security-considerations are addressed. If yer not going to
> use BEEP, then you should strongly consider designing-in use of SASL for
> authentication, and a 'StartTLS' command (a la RFC2830 and others) with which
> to establish TLS on the same port."

one problem is that different applications have different needs, and it's
hard to get apps folks to understand that, much less consider which
off-the-shelf solutions (if any) are suitable for the needs of a particular
app.

I never could get the IPP folks, for instance, to see that just because
you had SSL/TLS did not mean that you had a good way of authenticating 
arbitrary clients to arbitrary printers.

Keith

From timothy.wright@vodafone.com  Thu Jul 26 04:30:07 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA19667
	for <saag@jis.mit.edu>; Thu, 26 Jul 2001 04:29:57 -0400 (EDT)
From: timothy.wright@vodafone.com
Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id EAA24839
	for <saag@mit.edu>; Thu, 26 Jul 2001 04:29:46 -0400 (EDT)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id JAA20894; Thu, 26 Jul 2001 09:29:13 +0100 (BST)
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0008737886@mimesweeper1.vfl.vodafone>;
 Thu, 26 Jul 2001 09:29:07 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id <PR4HQ3YZ>; Thu, 26 Jul 2001 09:24:53 +0100
Message-Id: <DDC3D921FB67D211AAD100A0C9E58F5308A8B838@HAMPSTEAD>
To: smb@research.att.com, moore@cs.utk.edu
Cc: saag@mit.edu
Subject: RE: [saag] Presentation on SHAMAN at SAAG 
Date: Thu, 26 Jul 2001 09:24:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1252"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>


> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: 24 July 2001 22:08
> To: Keith Moore
> Cc: timothy.wright@vodafone.com; saag@mit.edu
> Subject: Re: [saag] Presentation on SHAMAN at SAAG 
> 
> 
> In message <200107241920.PAA12143@astro.cs.utk.edu>, Keith 
> Moore writes:
> 
> >
> >p.s. IMHO any security infrastructure should not be specific 
> to mobile
> >terminals - as at least some mobile terminals will connect 
> to the wired
> >internet from time to time.  So a mobile-only authentication proposal
> >is not very interesting.

I think a new "internet" protocol which could only be used by mobiles is
unlikely to have good acceptance at the IETF and we have no plans to propose
one.  However, GSM/3G mobiles have a smartcard which can have PK capability
and so enhanced client auth and key management capabilities.  I think it
makes sense to take advantage of this where we can.

> 
> More to the point, there is very little in the threat models we deal 
> with that is specific to wireless nodes.

Maybe the threats are the same but the likelihood is different and that will
change how you act on your threat model.  802.11 is clearly more open to
attack than a wired LAN.  A compromised router can perform an MITM attack
same as a false base station can, but I think that though not trivial at
all, a false base station attack is easier for many intruders than router
compromise.

Tim

> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 

From jlinn@rsasecurity.com  Fri Jul 27 15:53:10 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA01556
	for <saag@jis.mit.edu>; Fri, 27 Jul 2001 15:53:10 -0400 (EDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id PAA12011
	for <saag@mit.edu>; Fri, 27 Jul 2001 15:53:09 -0400 (EDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com
          via smtpd (for FORT-POINT-STATION.MIT.EDU [18.72.0.53]) with SMTP; 27 Jul 2001 19:51:21 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA01291
	for <saag@mit.edu>; Fri, 27 Jul 2001 15:53:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19)
	id <PY1GQW17>; Fri, 27 Jul 2001 15:52:58 -0400
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01F7CA8B@exna07.securitydynamics.com>
From: "Linn, John" <jlinn@rsasecurity.com>
To: saag@mit.edu
Subject: RE: [saag] Determining Strengths For Public Keys
Date: Fri, 27 Jul 2001 15:52:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I'd like to identify some concerns about this document. 

Section 1 appropriately recognizes the importance of sizing public keys
based on the effective symmetric key strength requirement, which will often
be less than the lengths of the symmetric keys used.  As a concrete example
to complement the procedure defined at the end of the section, it might be
useful to cite the 1996 "Minimal Key Lengths for Symmetric Ciphers to
Provide Adequate Commercial Security" report, recently included as an
appendix to draft-eastlake-randomness2-02.txt, which recommended a 90-bit
threshold for 20-year protection.  Later in the paper (Secs. 4-4.2, 4.4),
however, the discussion stresses keylengths corresponding to 112-bit
triple-DES keys and to 128-bit AES keys rather than to separate strength
requirements.  This emphasis could lead readers employing 3DES or AES to a
hasty conclusion that extremely large public key sizes were needed to
protect their key exchanges, incurring excessive performance costs.
Migration from triple-DES to AES need not imply any changes to associated
key exchanges, if, e.g., the underlying symmetric strength requirement
remains at 80 or 90 bits. 

Per Sec. 2.4, 2nd para, I'd suggest also citing another finding from
[SIL00]; the observation that NFS factoring of a 1024-bit number would
require approximately 7 million times the effort that was required to factor
RSA-512 in 1999 (cited in Sec. 2.1 as 8000 MY), even leaving the cited
memory space questions aside.  Phrased another way, available processor
cycles would have to double almost 23 times relative to the distributed
RSA-512 effort.  Pragmatically, availability and concentration of this level
of processing power on a particular factoring problem seems unlikely to be
imminent. 

Per Sec. 2.4, 4th para: A central premise of this paragraph seems to be that
memory costs should be dismissed for predictive purposes because future
demand for memory may derive from as-yet-unpredicted applications.
Certainly, future applications will influence memory requirements; they will
also drive demand for development and deployment of faster processors and
new processor features.  Any or all of these are likely to influence costs
and the pool of processing capabilities available for future factoring
efforts; it seems consistent that all be considered in the analysis.  

Sec. 4, 4th paragraph, sets out to evaluate a cost-based metric, but
explicitly omits the cost of 2^60 bytes of memory.  A "back-of-calculator"
estimate suggests that the significance of this omission dwarfs the
remainder of the analysis.  Today, 64Mbyte PC RAM modules sell for about
$200 US in units; for the sake of argument, let's guesstimate that large
quantities could be had for less than half of that price, $64/module or
$1/Mbyte.  64Mbytes is 2^26 bytes, so 2^34 such modules would be needed to
populate that system as described.  At $64/module, the cost of this memory
would be just over one quadrillion dollars, far out of reach for even the
trillionaire postulated in the discussion.  Given that large-scale factoring
is also extremely memory-intensive, it seems reasonable that memory costs
should not be omitted when the processing resources potentially available to
an attacker are estimated.  

Editorial:

Abstract, 2nd para, 2nd sentence: "as a function of the length of a
symmetric key" -> "as a function of a symmetric key strength requirement",
consistent with other discussion and the preceding sentence. 

Sec. 1, 4th para, last line: "no the case" -> "not the case". 

Sec. 2.4, 2nd para: citation to [SILIIEEE99] lacks a corresponding reference
in Section 6.  I believe it should be R. D. Silverman, "The Mythical MIPS
Year", IEEE Computer, August 1999. 

Sec. 2.4, 2nd para, 7th line: "that be brought" -> "that can be brought".

Sec. 4.1, last para, last line: "it not a" -> "it is not a".

--jl

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Friday, July 20, 2001 11:10 AM
> To: saag@mit.edu
> Subject: [saag] Determining Strengths For Public Keys
> 
> 
> Greetings again. Hilarie and I have made significant changes to our 
> public key strengths document. We think it is now pretty complete, 
> and we want to take it to IETF last call after London. However, 
> having all the SAAG folks pore over it now might find places for 
> improvement before IETF last call. Please read through it and send 
> any comments you have to us or, preferably, to the SAAG mailing list. 
> Thanks!
> 
> 	Title		: Determining Strengths For Public Keys Used For
>                            Exchanging Symmetric Keys
> 	Author(s)	: H. Orman, P. Hoffman
> 	Filename	: draft-orman-public-key-lengths-03.txt
> 	Pages		:
> 	Date		: 19-Jul-01
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-orman-public-key-len
gths-03.txt

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
saag mailing list
saag@mit.edu
http://jis.mit.edu/mailman/listinfo/saag

From jlinn@rsasecurity.com  Tue Jul 31 08:11:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA00896
	for <saag@jis.mit.edu>; Tue, 31 Jul 2001 08:11:50 -0400 (EDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id IAA22069
	for <saag@mit.edu>; Tue, 31 Jul 2001 08:11:45 -0400 (EDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com
          via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 31 Jul 2001 12:09:52 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA22107
	for <saag@mit.edu>; Tue, 31 Jul 2001 08:11:31 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19)
	id <PY1GSARB>; Tue, 31 Jul 2001 08:11:31 -0400
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01F7CA9F@exna07.securitydynamics.com>
From: "Linn, John" <jlinn@rsasecurity.com>
To: saag@mit.edu
Subject: RE: [saag] Determining Strengths For Public Keys
Date: Tue, 31 Jul 2001 08:11:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I wrote, too hastily:

> Sec. 4, 4th paragraph, sets out to evaluate a cost-based metric, but
> explicitly omits the cost of 2^60 bytes of memory.  A 
> "back-of-calculator"
> estimate suggests that the significance of this omission dwarfs the
> remainder of the analysis.  Today, 64Mbyte PC RAM modules 
> sell for about
> $200 US in units; for the sake of argument, let's guesstimate 
> that large
> quantities could be had for less than half of that price, 
> $64/module or
> $1/Mbyte.  64Mbytes is 2^26 bytes, so 2^34 such modules would 
> be needed to
> populate that system as described.  At $64/module, the cost 
> of this memory
> would be just over one quadrillion dollars, far out of reach 
> for even the
> trillionaire postulated in the discussion.  Given that 
> large-scale factoring
> is also extremely memory-intensive, it seems reasonable that 
> memory costs
> should not be omitted when the processing resources 
> potentially available to
> an attacker are estimated.  
> 

At $1/Mbyte (=2^20 bytes), 2^40 dollars would be needed to populate the 2^60
byte space.  2^40 expands to $1,099,511,627,776, which is just over a
trillion rather than a quadrillion.  My apologies for the error.  Even so,
this estimated memory cost would itself consume the trillionaire's budget,
leaving nothing left for processors.  

--jl

From HORMAN@volera.com  Wed Aug  1 13:30:26 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA12469
	for <saag@jis.mit.edu>; Wed, 1 Aug 2001 13:30:25 -0400 (EDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA00875
	for <saag@mit.edu>; Wed, 1 Aug 2001 13:30:25 -0400 (EDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com
	with Novell_GroupWise; Wed, 01 Aug 2001 11:29:44 -0600
Message-Id: <sb67e828.056@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 01 Aug 2001 11:29:41 -0600
From: "Hilarie Orman" <HORMAN@volera.com>
To: <jlinn@rsasecurity.com>
Cc: <saag@mit.edu>
Subject: RE: [saag] Determining Strengths For Public Keys
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id NAA12469
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

The 1996 report needs continual updates, of course, and
20-year protection is fairly skimpy.  Ross Anderson points
out that some data needs 200 year protection.  I agree that
it's a good citation for the initial 'stength' section.

Let's look at the motivation for writing this.  It is an 
informational document, not Best Practice.  That's because
key length issues seem to be a matter of continual interest 
in the security area.  I believe that people really do
want to understand the key equivalency issue and need
this information in order to decide on highest strength
they can tolerate.  Perhaps, after looking at the numbers,
they'll decide to use 95 bits.

As for the memory issue, it's not inconceivable to me
that some nation state is currently running a fab line
for 64-bit processors and high density memory specifically
for the purpose of solving factoring-related problems for
large moduli.  The costs for that are not commercial
costs and probably falls easily into the trillion dollar
budget.

The discussion about commandeering otherwise
unused resources is merely to note that cheaper
ways of getting resources will be available in
the future, perhaps faster than one would imagine
simply by looking at workstations.


Hilarie



From: "Linn, John" <jlinn@rsasecurity.com>
To: saag@mit.edu 
Subject: RE: [saag] Determining Strengths For Public Keys
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: saag-admin@mit.edu 
X-BeenThere: saag@mit.edu 
X-Mailman-Version: 2.0
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>
Date: Fri, 27 Jul 2001 15:52:49 -0400

I'd like to identify some concerns about this document.

Section 1 appropriately recognizes the importance of sizing public keys
based on the effective symmetric key strength requirement, which will often
be less than the lengths of the symmetric keys used.  As a concrete example
to complement the procedure defined at the end of the section, it might be
useful to cite the 1996 "Minimal Key Lengths for Symmetric Ciphers to
Provide Adequate Commercial Security" report, recently included as an
appendix to draft-eastlake-randomness2-02.txt, which recommended a 90-bit
threshold for 20-year protection.  Later in the paper (Secs. 4-4.2, 4.4),
however, the discussion stresses keylengths corresponding to 112-bit
triple-DES keys and to 128-bit AES keys rather than to separate strength
requirements.  This emphasis could lead readers employing 3DES or AES to a
hasty conclusion that extremely large public key sizes were needed to
protect their key exchanges, incurring excessive performance costs.
Migration from triple-DES to AES need not imply any changes to associated
key exchanges, if, e.g., the underlying symmetric strength requirement
remains at 80 or 90 bits.

Per Sec. 2.4, 2nd para, I'd suggest also citing another finding from
[SIL00]; the observation that NFS factoring of a 1024-bit number would
require approximately 7 million times the effort that was required to factor
RSA-512 in 1999 (cited in Sec. 2.1 as 8000 MY), even leaving the cited
memory space questions aside.  Phrased another way, available processor
cycles would have to double almost 23 times relative to the distributed
RSA-512 effort.  Pragmatically, availability and concentration of this level
of processing power on a particular factoring problem seems unlikely to be
imminent.

Per Sec. 2.4, 4th para: A central premise of this paragraph seems to be that
memory costs should be dismissed for predictive purposes because future
demand for memory may derive from as-yet-unpredicted applications.
Certainly, future applications will influence memory requirements; they will
also drive demand for development and deployment of faster processors and
new processor features.  Any or all of these are likely to influence costs
and the pool of processing capabilities available for future factoring
efforts; it seems consistent that all be considered in the analysis. 

Sec. 4, 4th paragraph, sets out to evaluate a cost-based metric, but
explicitly omits the cost of 2^60 bytes of memory.  A "back-of-calculator"
estimate suggests that the significance of this omission dwarfs the
remainder of the analysis.  Today, 64Mbyte PC RAM modules sell for about
$200 US in units; for the sake of argument, let's guesstimate that large
quantities could be had for less than half of that price, $64/module or
$1/Mbyte.  64Mbytes is 2^26 bytes, so 2^34 such modules would be needed to
populate that system as described.  At $64/module, the cost of this memory
would be just over one quadrillion dollars, far out of reach for even the
trillionaire postulated in the discussion.  Given that large-scale factoring
is also extremely memory-intensive, it seems reasonable that memory costs
should not be omitted when the processing resources potentially available to
an attacker are estimated. 

Editorial:

Abstract, 2nd para, 2nd sentence: "as a function of the length of a
symmetric key" -> "as a function of a symmetric key strength requirement",
consistent with other discussion and the preceding sentence.

Sec. 1, 4th para, last line: "no the case" -> "not the case".

Sec. 2.4, 2nd para: citation to [SILIIEEE99] lacks a corresponding reference
in Section 6.  I believe it should be R. D. Silverman, "The Mythical MIPS
Year", IEEE Computer, August 1999.

Sec. 2.4, 2nd para, 7th line: "that be brought" -> "that can be brought".

Sec. 4.1, last para, last line: "it not a" -> "it is not a".


From smb@research.att.com  Wed Aug  1 11:44:09 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA11365
	for <saag@jis.mit.edu>; Wed, 1 Aug 2001 11:44:09 -0400 (EDT)
Received: from berkshire.research.att.com (H-135-207-10-200.research.att.com [135.207.10.200])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18909
	for <saag@mit.edu>; Wed, 1 Aug 2001 11:44:09 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id 3302C7B59
	for <saag@mit.edu>; Wed,  1 Aug 2001 11:44:03 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 01 Aug 2001 11:44:03 -0400
Message-Id: <20010801154403.3302C7B59@berkshire.research.att.com>
Subject: [saag] Two NIST documents posted for comments (fwd)
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

------- Forwarded Message


X-Sender: dworkin@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 30 Jul 2001 09:57:09 -0400
To: dworkin@nist.gov
From: Morris Dworkin <dworkin@nist.gov>
Subject: Two NIST documents posted for comments 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-UIDL: 0ef060c25b0cacf202387b54fddf7923

NIST is proposing changes to FIPS 186-2, Digital Signature Standard (DSS) 
and requests comments on these changes. Specifically, NIST is proposing 
that the Implementation Schedule of FIPS 186-2 be modified to extend the 
transition period for the acquisition of equipment implementing FIPS 186-2 
from July 2001 to December 2002. This will enable agencies to continue to 
acquire commercial products based on PKCS #1. NIST also proposes that the 
Applications section of FIPS 186-2 be modified to clarify that 
implementations of PKCS #1 (version 1.5 or higher) may be used during the 
transition period. Comments may be sent to FIPS186@nist.gov. The notice 
appeared in the July 11, 2001, FEDERAL REGISTER, Volume 66, Number 133, 
page 36254. This announcement and a copy of the announcement is available 
at http://csrc.nist.gov.

Also, the draft "Recommendation for Block Cipher Modes of Operation" is 
available for public comment, from a link at 
http://csrc.nist.gov/publications/drafts.html .  The recommendation updates 
the modes in FIPS 81 for use with any FIPS-approved block cipher, and 
specifies the counter mode. Comments and questions may be addressed to 
EncryptionModes@nist.gov. The deadline for the submission of comments is 
August 31, 2001.

Finally, a reminder that NIST will hold the Second Modes of Operation 
Workshop on August 24, 2001 at the Holiday Inn, Santa Barbara.  Comments 
and analysis for the workshop are requested by August 3.  Information, 
including a link to on-line registration,  is available the modes home 
page:  http://nist.gov/modes.

Regards,

Morris Dworkin



------- End of Forwarded Message



		--Steve Bellovin, http://www.research.att.com/~smb



From smb@research.att.com  Wed Aug  1 17:33:58 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA14713
	for <saag@jis.mit.edu>; Wed, 1 Aug 2001 17:33:58 -0400 (EDT)
Received: from berkshire.research.att.com (H-135-207-10-200.research.att.com [135.207.10.200])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22759
	for <saag@mit.edu>; Wed, 1 Aug 2001 17:33:57 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id B97777B59
	for <saag@mit.edu>; Wed,  1 Aug 2001 17:33:45 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 01 Aug 2001 17:33:45 -0400
Message-Id: <20010801213345.B97777B59@berkshire.research.att.com>
Subject: [saag] new mode proposal (fwd)
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

------- Forwarded Message


X-Sender: dworkin@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 15:24:56 -0400
From: Morris Dworkin <dworkin@nist.gov>
Subject: new mode proposal
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-UIDL: 8ac52ed4a168ffa2e381d3d748ebde59

NIST has accepted a new proposal for a mode of operation, called Dual 
Counter Mode, by Mike Boyle and Chris Salter of the National Security 
Agency.  There is a link to the proposal from the list of proposed modes at 
the modes home page:  http://csrc.nist.gov/encryption/modes/proposedmodes/.

Regards,

Morris Dworkin



------- End of Forwarded Message



		--Steve Bellovin, http://www.research.att.com/~smb



From rlmorgan@washington.edu  Tue Aug  7 06:50:03 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA19315
	for <saag@jis.mit.edu>; Tue, 7 Aug 2001 06:50:02 -0400 (EDT)
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA20427
	for <saag@mit.edu>; Tue, 7 Aug 2001 06:50:02 -0400 (EDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged))
	by mxout1.cac.washington.edu (8.11.2+UW01.01/8.11.2+UW01.04) with ESMTP id f77Ao1125920
	for <saag@mit.edu>; Tue, 7 Aug 2001 03:50:01 -0700
Received: from host217-33-137-99.ietf.ignite.net (host217-33-137-99.ietf.ignite.net [217.33.137.99])
	(authenticated (0 bits))
	by smtp.washington.edu (8.12.0.Beta7+UW01.04/8.12.0.Beta7+UW01.04) with ESMTP id f77AnxXt011592
	for <saag@mit.edu>; Tue, 7 Aug 2001 03:50:01 -0700
Date: Tue, 7 Aug 2001 03:50:13 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender:  <rlmorgan@perx.cac.washington.edu>
Reply-To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: SAAG list <saag@mit.edu>
Message-ID: <Pine.LNX.4.33.0107250822410.3092-100000@perx.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [saag] SAML
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Let me offer to SAAG folks some info about a security-space standards
activity that I think is interesting, important, and relevant to IETF
security standards.  I note that though I participate in the
below-described activity I'm not a spokesperson, so these are my personal
points of view on this stuff.

OASIS "is a non-profit, international consortium that creates
interoperable industry specifications based on public standards such as
XML and SGML".  It's a membership organization, ie you have to be a member
to officially participate in its standards-making processes.  See
http://www.oasis-open.org/.

OASIS has technical committees that are more or less like IETF working
groups.  One technical committee is called (generically enough) "Security
Services".  This committee has been working since January 2001 on a
standard which will be called "Security Assertion Markup Language", aka
SAML.  Links:

  http://www.oasis-open.org/committees/security/
  http://www.oasis-open.org/committees/security/docs/
  http://lists.oasis-open.org/archives/security-services/

All the group's documents and list archives are openly available.

This effort came about primarily based on the observation of a number of
vendors of "web access management" products (providing web single sign-on,
access control, etc) that their customers wanted interoperability among
their products, and that this seemed to be possible.  The main initial
inputs were S2ML (http://www.s2ml.org/) and AuthXML
(http://www.authxml.org/).

Very briefly, the standard will specify (1) XML schema for a few different
flavors of "assertions", basically structured statements by particular
"authorities"; (2) a simple protocol for requesting assertions and
responding with them; (3) bindings of this protocol to underlying
transports such as HTTP, SOAP, BEEP, S/MIME, etc; (4) profiles for
inclusion of SAML assertions in other protocols such as SOAP; (5)
conformance and security considerations material.  The current set of
assertions is:  (1) authentication assertions ("Bob logged in at 3:27");
(2) attribute assertions ("Bob is a member of group Mumble"); (3)
authorization decision assertions ("Yes, Bob can access web page
http://foo").

My biased point of view is that though the group's goals are ambitious,
the level of clue is pretty good too, including a number of regular IETF
security-area contributors, and core W3C contributors.

I can speak about this briefly at the SAAG meeting on Thursday if there is
time and interest.

 - RL "Bob"



From a.falk@ieee.org  Tue Aug  7 12:52:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA21196
	for <saag@jis.mit.edu>; Tue, 7 Aug 2001 12:52:38 -0400 (EDT)
Received: from cluebox.homeip.net (109.11.252.64.snet.net [64.252.11.109])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA19160
	for <saag@mit.edu>; Tue, 7 Aug 2001 12:52:37 -0400 (EDT)
Received: from host217-33-136-171.ietf.ignite.net (localhost.localdomain [127.0.0.1])
	by cluebox.homeip.net (8.11.2/8.11.2) with ESMTP id f77Gvag01304;
	Tue, 7 Aug 2001 12:57:37 -0400
Date: Tue, 07 Aug 2001 12:51:52 -0400
From: Aaron Falk <a.falk@ieee.org>
To: karn@qualcomm.com
cc: pilc@grc.nasa.gov, saag@mit.edu, mankin@isi.edu
Message-ID: <98043093.997188712@host217-33-136-171.ietf.ignite.net>
X-Mailer: Mulberry/2.1.0b3 (Win32 Demo)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [saag] PILC IETF-51 discussion on LINK Security Considerations
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Phil-

(saag list cc'ed for heads up. Ref: draft-ietf-pilc-link-design-06.txt 
section on security considerations)

This is my take on the issues that were raised today regarding the Security 
Considerations section of LINK:

* end-to-end encryption is the best way to protect user data: clear 
consensus

* subnet designers should use security mechanisms to protect the network: 
clear consensus

* subnets may protect against traffic analysis: clear consensus

* subnets may use link encryption to protect against traffic analysis: 
mixed         consensus, evesdroppers may gain access to cleartext at 
access points,     pre-encryption

* it is not appropriate for PILC to recommend use of link encryption to 
protect user data: clear consensus, it's easy to get wrong, it can lead to 
a false sense of security

* wireline equivalent privacy is a poorly defined concept which PILC should 
not advocate: rough consensus

Now, my thoughts:

IP encryption does not provide complete privacy: IP addresses are still in 
the clear and it is possibly that an evesdropper could identify which web 
site a user is accessing, e.g., the sex.com example. So, perhaps we can get 
consensus if we add a statement that traffic analysis can violate user 
privacy. IANASE, but there doesn't seem to be a better way of hiding IP 
addresses over a wireless link than link encryption. So, while link 
encryption is not a complete solution to traffic analysis it does yield 
some capabilities that IP encryption cannot. However, we also need to do 
what we can to avoid the impression that link encryption can protect user 
data -- it only offers protection of IP addresses. IP or higher layer 
security mechanisms should be used to protect user data.

I think we should discuss this further at the SAAG meeting (Thurs, 3:30) to 
get more Security Area input.

--aaron

From smb@research.att.com  Tue Aug  7 15:35:52 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA22300
	for <saag@jis.mit.edu>; Tue, 7 Aug 2001 15:35:52 -0400 (EDT)
Received: from berkshire.research.att.com (host217-33-137-230.ietf.ignite.net [217.33.137.230])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA02756
	for <saag@mit.edu>; Tue, 7 Aug 2001 15:35:51 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id 0D1E97B4B
	for <saag@mit.edu>; Tue,  7 Aug 2001 20:35:20 +0100 (BST)
X-Mailer: exmh version 2.1.1 10/15/1999
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Aug 2001 20:35:20 +0100
Message-Id: <20010807193520.0D1E97B4B@berkshire.research.att.com>
Subject: [saag] WEP insecurity
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

From the latest issue of RISKS:

Date: Tue, 07 Aug 2001 05:56:27 -0400
From: Avi Rubin <rubin@research.att.com>
Subject: WEP insecurity

   [Read it and WE(E)P, unless you already WEPt.  PGN]

We have a new paper:

Using the Fluhrer, Mantin, and Shamir Attack to Break WEP
by
Adam Stubblefield, John Ioannidis, and Aviel D. Rubin

We implemented an attack against WEP, the link-layer security protocol for
802.11 networks.  The attack was described in a recent paper by Fluhrer,
Mantin, and Shamir. With our implementation, and permission of the network
administrator, we were able to recover the 128-bit secret key used in a
production network, with a passive attack. The WEP standard uses RC4 IVs
improperly, and the attack exploits this design failure.  This paper
describes the attack, how we implemented it, and some optimizations to make
the attack more efficient. We conclude that 802.11 WEP is totally insecure,
and we provide some recommendations.

The paper is available at http://www.cs.rice.edu/~astubble/wep/

Avi Rubin, AT&T Labs - Research  http://avirubin.com/
White-Hat Security Arsenal:  http://white-hat.org/


		--Steve Bellovin, http://www.research.att.com/~smb



From hodges@breakaway.Stanford.EDU  Tue Aug  7 16:43:26 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22692
	for <saag@jis.mit.edu>; Tue, 7 Aug 2001 16:43:26 -0400 (EDT)
Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA22790
	for <saag@mit.edu>; Tue, 7 Aug 2001 16:43:25 -0400 (EDT)
Received: from localhost (hodges@localhost)
	by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA16464;
	Tue, 7 Aug 2001 13:43:25 -0700 (PDT)
Message-Id: <200108072043.NAA16464@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
To: Security Area Advisory Group <saag@mit.edu>
cc: Jeff.Hodges@kingsmountain.com
From: Jeff.Hodges@kingsmountain.com
Reply-to: Jeff.Hodges@kingsmountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Aug 2001 13:43:24 -0700
Subject: [saag] RC4 insecurity wrt SSL/TLS?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

A question for those who've read and grokked the first paper below...

given..

  Weaknesses in the Key Scheduling Algorithm of RC4
  http://www.eyetap.org/~rguerra/toronto2001/rc4_ksaproc.pdf

  Using the Fluhrer, Mantin, and Shamir Attack to Break WEP
  http://www.cs.rice.edu/~astubble/wep/


..and this from http://www.ietf.org/rfc/rfc2246.txt ...


  C. CipherSuite definitions
                  .
                  .
  TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
  TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
                  .
                  .
                  .
                        Key      Expanded   Effective   IV    Block
    Cipher       Type  Material Key Material  Key Bits  Size   Size
                  .
                  .
    RC4_128      Stream  16         16         128        0     N/A
                  .
                  .


Is it thus possible for conformant TLS implementations to use similar-to-WEP 
RC4 initializations such that their operational use of RC4 as the TLS stream 
cipher is similarly vulnerable?

An additional question is whether typical RC4 implementations-and-APIs give 
the programmer enough lattitude to step into the vulnerable-like-WEP mudpuddle?

thanks,

JeffH



From smb@research.att.com  Tue Aug  7 17:02:36 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA22855
	for <saag@jis.mit.edu>; Tue, 7 Aug 2001 17:02:36 -0400 (EDT)
Received: from berkshire.research.att.com (host217-33-137-230.ietf.ignite.net [217.33.137.230])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28246
	for <saag@mit.edu>; Tue, 7 Aug 2001 17:02:35 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 96E287B4B; Tue,  7 Aug 2001 22:02:04 +0100 (BST)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: Jeff.Hodges@kingsmountain.com
Cc: Security Area Advisory Group <saag@mit.edu>
Subject: Re: [saag] RC4 insecurity wrt SSL/TLS? 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Aug 2001 22:02:04 +0100
Message-Id: <20010807210204.96E287B4B@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <200108072043.NAA16464@breakaway.Stanford.EDU>, Jeff.Hodges@kingsmou
ntain.com writes:
>A question for those who've read and grokked the first paper below...
>
>given..
>
>  Weaknesses in the Key Scheduling Algorithm of RC4
>  http://www.eyetap.org/~rguerra/toronto2001/rc4_ksaproc.pdf
>
>  Using the Fluhrer, Mantin, and Shamir Attack to Break WEP
>  http://www.cs.rice.edu/~astubble/wep/
>
>
>..and this from http://www.ietf.org/rfc/rfc2246.txt ...
>
>
>  C. CipherSuite definitions
>                  .
>                  .
>  TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
>  TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
>                  .
>                  .
>                  .
>                        Key      Expanded   Effective   IV    Block
>    Cipher       Type  Material Key Material  Key Bits  Size   Size
>                  .
>                  .
>    RC4_128      Stream  16         16         128        0     N/A
>                  .
>                  .
>
>
>Is it thus possible for conformant TLS implementations to use similar-to-WEP 
>RC4 initializations such that their operational use of RC4 as the TLS stream 
>cipher is similarly vulnerable?
>
>An additional question is whether typical RC4 implementations-and-APIs give 
>the programmer enough lattitude to step into the vulnerable-like-WEP mudpuddle
>?

TLS is almost certainly not vulnerable.  

The attack here is a "related key attack".  For a number of reasons 
(most because the designers of WEP misused a stream cipher instead of 
using a block cipher) the actual RC4 key used in comprised of a 
preprovisioned "key" and an "IV", concatenated together.  Each packet 
(until the IV counter wraps around after 2^24 packets) has a different 
key, but 24 of those bits are changing, while 40 or 104 remain the 
same.  The keys are thus *slightly* different, which is the wedge that 
Fluhrer, Mantin, and Shamir used.  TLS uses a much more random key for 
each session; there are no easy-to-find relationships between the keys 
used for different sessions.

That said, if I were designing TLS/RC4 today, I'd specify that the 
first 256 bytes of of its output should be discarded, to avoid future 
cryptanalytic attacks on the not-as-random portions of its output.


		--Steve Bellovin, http://www.research.att.com/~smb



From ekr@rtfm.com  Tue Aug  7 17:40:58 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA23074
	for <saag@jis.mit.edu>; Tue, 7 Aug 2001 17:40:58 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA10992
	for <saag@mit.edu>; Tue, 7 Aug 2001 17:40:39 -0400 (EDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA71033; Tue, 7 Aug 2001 14:46:42 -0700 (PDT)
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: Jeff.Hodges@kingsmountain.com, Security Area Advisory Group <saag@mit.edu>
Subject: Re: [saag] RC4 insecurity wrt SSL/TLS?
References: <20010807210204.96E287B4B@berkshire.research.att.com>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 07 Aug 2001 14:46:41 -0700
In-Reply-To: "Steven M. Bellovin"'s message of "Tue, 07 Aug 2001 22:02:04 +0100"
Message-ID: <kj8zgvpmpq.fsf@romeo.rtfm.com>
Lines: 17
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

"Steven M. Bellovin" <smb@research.att.com> writes:
> TLS is almost certainly not vulnerable.  
It is not.

> The attack here is a "related key attack".  For a number of reasons 
> (most because the designers of WEP misused a stream cipher instead of 
> using a block cipher) the actual RC4 key used in comprised of a 
> preprovisioned "key" and an "IV", concatenated together.  Each packet 
> (until the IV counter wraps around after 2^24 packets) has a different 
> key, but 24 of those bits are changing, while 40 or 104 remain the 
> same.  The keys are thus *slightly* different, which is the wedge that 
> Fluhrer, Mantin, and Shamir used.  TLS uses a much more random key for 
> each session; there are no easy-to-find relationships between the keys 
> used for different sessions.
Correct.

-Ekr

From rgm-sec@htt-consult.com  Wed Aug  8 05:23:09 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA26393
	for <saag@jis.mit.edu>; Wed, 8 Aug 2001 05:23:05 -0400 (EDT)
Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id FAA25732
	for <saag@mit.edu>; Wed, 8 Aug 2001 05:23:01 -0400 (EDT)
Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 08 Aug 2001 05:21:59 -0400
Message-Id: <5.1.0.14.2.20010808101114.01dee0a0@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 Aug 2001 10:20:43 +0100
To: Aaron Falk <a.falk@ieee.org>, karn@qualcomm.com
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security
  Considerations
Cc: pilc@grc.nasa.gov, saag@mit.edu, mankin@isi.edu
In-Reply-To: <98043093.997188712@host217-33-136-171.ietf.ignite.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 12:51 PM 8/7/2001 -0400, Aaron Falk wrote:

>(saag list cc'ed for heads up. Ref: draft-ietf-pilc-link-design-06.txt 
>section on security considerations)
>
>* subnet designers should use security mechanisms to protect the network: 
>clear consensus
>
>* subnets may protect against traffic analysis: clear consensus
>
>* subnets may use link encryption to protect against traffic analysis: 
>mixed         consensus, evesdroppers may gain access to cleartext at 
>access points,     pre-encryption
>
>* it is not appropriate for PILC to recommend use of link encryption to 
>protect user data: clear consensus, it's easy to get wrong, it can lead to 
>a false sense of security
>
>Now, my thoughts:
>
>IP encryption does not provide complete privacy: IP addresses are still in 
>the clear and it is possibly that an evesdropper could identify which web 
>site a user is accessing, e.g., the sex.com example. So, perhaps we can 
>get consensus if we add a statement that traffic analysis can violate user 
>privacy. IANASE, but there doesn't seem to be a better way of hiding IP 
>addresses over a wireless link than link encryption. So, while link 
>encryption is not a complete solution to traffic analysis it does yield 
>some capabilities that IP encryption cannot. However, we also need to do 
>what we can to avoid the impression that link encryption can protect user 
>data -- it only offers protection of IP addresses. IP or higher layer 
>security mechanisms should be used to protect user data.

I have been looking at this vis-a-vis 802.11i.  ESP is very usable as a 
link layer protection mechanism.  It just needs an applicable KME for 
sub-IP (layer 2.5 if you will).

This of course is a 'different' ESP than 2406.  The nature of the SA is 
different, no IP address for the tuple, at least.  But the format and much 
of the code would be the same.

ESP overhead can be 'managed' by selection of the transform.  ESP 
contributes 10 bytes (14 if we increase the size of the 
Seq#).  3DES-HMAC-SHA1-96 contributes 20 bytes with an average 2 bytes 
padding.  But a dual-mode AES transform could be much less overhead 
(conversations with Phil Rogaway seems to indicate that AES128-OCB64 would 
be 8 bytes plus padding).

An effort in the security area to define a common security mechinism for 
link layers would be a benifit to the community.  When I attended the 
802.11i meeting in Portland, it was mentioned that it WOULD be nice if IETF 
did this generically, but since they don't WEP2 needs to come out of the 
11i group.



Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com


From tytso@thunk.org  Wed Aug  8 06:50:50 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA26789
	for <saag@jis.mit.edu>; Wed, 8 Aug 2001 06:50:46 -0400 (EDT)
Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA03815;
	Wed, 8 Aug 2001 06:50:46 -0400 (EDT)
Received: from host217-33-136-64.ietf.ignite.net ([217.33.136.64] helo=think.thunk.org)
	by thunk.org with asmtp (Exim 3.22 #1 (Debian))
	id 15UQv5-0005Hs-00; Wed, 08 Aug 2001 06:50:35 -0400
Received: from tytso by think.thunk.org with local (Exim 3.22 #1 (Debian))
	id 15UQuw-00020v-00; Wed, 08 Aug 2001 06:50:26 -0400
Date: Wed, 8 Aug 2001 06:50:26 -0400
From: Theodore Tso <tytso@MIT.EDU>
To: ipsec@lists.tislabs.com, saag@mit.edu
Message-ID: <20010808065026.B7491@thunk.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Subject: [saag] NIST Modes of Operation Papers On-Line
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

The papers for the upcoming NIST Modes of Operation workshop are now available.

Folks who are interested in new modes for AES may find this of interest.

						- Ted

-- 

--vkogqOf2sHV7VnPd
Content-Type: message/rfc822
Content-Disposition: inline

>From tytso  Tue Aug  7 16:14:01 2001
Return-Path: <owner-extdom.iscsi-security@sj-msg-core-3.cisco.com>
Received: from po14.mit.edu [18.7.21.72]
	by localhost with IMAP (fetchmail-5.8.14)
	for tytso@localhost (single-drop); Tue, 07 Aug 2001 16:14:01 -0400 (EDT)
Received: from fort-point-station.mit.edu by po14.mit.edu (8.9.2/4.7) id NAA14890; Tue, 7 Aug 2001 13:02:35 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25488
	for <tytso@mit.edu>; Tue, 7 Aug 2001 13:02:35 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f77GoiJ27798
	for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:51:07 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f77Gqec06958
	for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:52:41 -0700 (PDT)
Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38])
	by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f77GqEr12035
	for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:52:14 -0700 (PDT)
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 MMS-3 SMTP Relay (MMS v4.7)); Tue, 07 Aug 2001 09:48:52 -0700
X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
 [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id JAA06811 for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001
 09:48:58 -0700 (PDT)
Received: from ltjtardo (dhcpe2-sj1-067 [10.16.75.67]) by
 mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id JAA15684 for
 <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:48:58 -0700 (
 PDT)
From: "Joseph Tardo" <jtardo@broadcom.com>
To: iscsi-security@external.cisco.com
Subject: NIST Modes of Operation Papers On-Line
Date: Tue, 7 Aug 2001 09:48:57 -0700
Message-ID: <NDBBJJDNOJJEFGHAECHIOEJFDCAA.jtardo@broadcom.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <F66A04C29AD9034A8205949AD0C90104D57922@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-WSS-ID: 176EC47E36034-01-01
Content-Type: text/plain; 
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bernard:

Here is the URL.

--Joe

http://csrc.nist.gov/encryption/modes/proposedmodes/index.html



--vkogqOf2sHV7VnPd--

From sommerfeld@orchard.arlington.ma.us  Wed Aug  8 06:38:46 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA26728
	for <saag@jis.mit.edu>; Wed, 8 Aug 2001 06:38:37 -0400 (EDT)
Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [24.218.160.210])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA08445
	for <saag@mit.edu>; Wed, 8 Aug 2001 06:38:37 -0400 (EDT)
Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2])
	by stack.hamachi.org (Postfix) with ESMTP
	id B28A226D1; Wed,  8 Aug 2001 06:38:35 -0400 (EDT)
Received: from syn.hamachi.org (localhost [[UNIX: localhost]])
	by syn.hamachi.org (8.11.0/8.8.8) with ESMTP id f78AcP702425;
	Wed, 8 Aug 2001 06:38:25 -0400 (EDT)
Message-Id: <200108081038.f78AcP702425@syn.hamachi.org>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: Aaron Falk <a.falk@ieee.org>
Cc: karn@qualcomm.com, pilc@grc.nasa.gov, saag@mit.edu, mankin@ISI.EDU
In-Reply-To: Message from Aaron Falk <a.falk@ieee.org> 
   of "Tue, 07 Aug 2001 12:51:52 EDT." <98043093.997188712@host217-33-136-171.ietf.ignite.net> 
Reply-To: sommerfeld@orchard.arlington.ma.us
Date: Wed, 08 Aug 2001 06:38:25 -0400
Subject: [saag] Re: PILC IETF-51 discussion on LINK Security Considerations
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

We want to be very very careful about what we say about traffic analysis.

My sense is that it's harder to defeat traffic analysis than to
engineer systems to be robust in the face of denial-of-service
attacks.

Adversaries can choose to attack things other than just the abstract
bitstream at the link layer -- there are no doubt many opportunities
to distinguish between transmitters using physical layer techniques
like radio direction finding, waveform shapes, etc., etc.,

An adversary with taps on both sides of a router who can see frame
boundaries can likely correlate traffic going in and coming out.

Merely using something like ESP at the link layer isn't going to help
much against traffic analysis since you'll still be able to do TA
using the ESP SPI's.

Modern bridges and routers often run very complex software systems and
likely have some of the same vulnerability-to-remote-compromise issues
as host software.  Code Red's buffer-overrun attack reportedly also
crashed certain routers... what's the chance that the crash involved
an exploitable buffer overrun?

Security is hard.

					- Bill


From karn@ka9q.net  Wed Aug  8 11:44:51 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA28862
	for <saag@jis.mit.edu>; Wed, 8 Aug 2001 11:44:47 -0400 (EDT)
Received: from maggie.ka9q.net (host217-33-141-5.ietf.ignite.net [217.33.141.5])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA17955
	for <saag@mit.edu>; Wed, 8 Aug 2001 11:44:46 -0400 (EDT)
Received: (from karn@localhost)
	by maggie.ka9q.net (8.11.1/8.9.3/Debian 8.9.3-21) id f78FiZI00743;
	Wed, 8 Aug 2001 16:44:35 +0100
Date: Wed, 8 Aug 2001 16:44:35 +0100
Message-Id: <200108081544.f78FiZI00743@maggie.ka9q.net>
From: Phil Karn <karn@ka9q.net>
To: sommerfeld@orchard.arlington.ma.us
CC: a.falk@ieee.org, pilc@grc.nasa.gov, saag@mit.edu, mankin@isi.edu
In-reply-to: <200108081038.f78AcP702425@syn.hamachi.org> (message from Bill
	Sommerfeld on Wed, 08 Aug 2001 06:38:25 -0400)
Reply-to: karn@ka9q.net
References:  <200108081038.f78AcP702425@syn.hamachi.org>
Subject: [saag] Re: PILC IETF-51 discussion on LINK Security Considerations
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

>We want to be very very careful about what we say about traffic analysis.

I agree fully, and I will word the text I am writing very carefully.

Phil

From mcgrew@cisco.com  Wed Aug  8 15:55:35 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA00639
	for <saag@jis.mit.edu>; Wed, 8 Aug 2001 15:55:35 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA11181
	for <saag@mit.edu>; Wed, 8 Aug 2001 15:55:30 -0400 (EDT)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f78Jshg25108;
	Wed, 8 Aug 2001 12:54:43 -0700 (PDT)
Received: from cisco.com (ssh-rtp1.cisco.com [161.44.11.166])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id ARE07242 (AUTH mcgrew);
	Wed, 8 Aug 2001 12:54:40 -0700 (PDT)
Message-ID: <3B719A4D.5D77B479@cisco.com>
Date: Wed, 08 Aug 2001 16:00:13 -0400
From: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
CC: saag@mit.edu
Subject: Re: [saag] I-D ACTION:draft-mcgrew-saag-tmmh-00.txt
References: <200107181438.KAA28024@Twig.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

der Mouse,

thanks for your comments, you found a couple of glitches.  I'll be submitting a
corrected version to the ID editor soon.  I'd like to mention your contribution
in the Acknowledgments section.  Would you care to be identified solely as "der
Mouse <mouse@Rodents.Montreal.QC.CA>"?  

More inline:

der Mouse wrote:
> 
> > http://www.ietf.org/internet-drafts/draft-mcgrew-saag-tmmh-00.txt
> 
> Section 3 ("TMMH/16"), first paragraph, first sentence:
> s/a multiple/multiples/
> 
> Same section, second paragraph, last sentence: shouldn't that be
> "2 * KEY_WORDS", not "2 * MSG_WORDS"?  (Since KEY_LENGTH is a multiple
> of two, it is the same thing - and might be simpler - to say that
> KEY_WORDS is KEY_LENGTH/2.)

good point.

> 
> It also appears to me that the definition of TMMH/16 involves accessing
> nonexistent elements of M[], if TAG_WORDS > 1.  This is because j can
> then be greater than zero, which means M[j+MSG_WORDS] can be greater
> than MSG_WORDS.  Mutatis mutandis, the same applies to TMMH/32.  (The
> remark about cyclic use of the key material makes me suspect that the
> "j+" is supposed to be absent from the M[] subscripts; as it stands,
> K[] and M[] subscripts are always equal and there's nothing cyclic
> about it.)

Right.

> 
> Also, something is, at the very least, unclear.  I'd like to think I
> can follow directions, and indeed the values I compute match the test
> vectors for TMMH/16 - at least for the first two; I can't compute the
> third one because it involves a nonexistent M[] element.  But for
> TMMH/32, my values disagree with the results given.
> 
> I do have to assume how KEY_WORDS is defined for TMMH/32, since this is
> not stated.  Since extra key material is presented, I infer that it is
> supposed to be KEY_LENGTH/4.
> 
> Here's what I get.  (All values are hex; I omit the 0x prefix.)
> 
> For the first test vector, we have
> 
> key             01 23 45 67 89 ab cd ef fe dc ba 98
> message         ca fe ba be ba de de ed
> KEY_LENGTH      c
> TAG_LENGTH      4
> 
> Then I find, in order,
> 
> MAX_HASH_LENGTH 8
> MESSAGE_LENGTH  8
> KEY_WORDS       3
> K[]             01234567 89abcdef fedcba98
> MSG_WORDS       2
> M[]             cafebabe badedeed
> hash            ( ( K[0] * MESSAGE_LENGTH   +64
>                     K[1] * M[1]             +64
>                     K[2] * M[2] ) mod 10000000f ) mod 100000000 =
>                 ( ( 01234567 * 8         +64
>                     89abcdef * cafebabe  +64
>                     fedcba98 * badedeed ) mod 10000000f ) mod 100000000 =
>                 ( ( 00000000091a2b38  +64
>                     6d2a8d61ea447d62  +64
>                     ba0a40eb9bf88eb8 ) mod 10000000f ) mod 100000000 =
>                 ( 2734ce4d8f573752 mod 10000000f ) mod 100000000 =
>                 433f20ed
>                 -> 43 3f 20 ed
> 
> which bears no obvious relation to the stated value, a2 bb e1 b1.

You're value is correct - I'd used htons() rather than htonl() in my key setup
routine, so while I verified the actual hash computation using the pari-gp
interpreter, the test vector computation suffered from GIGO.

thanks,

David

> 
> If I take the draft strictly as stated and let KEY_WORDS be
> KEY_LENGTH/2, using two octets for each K[] value (in the low 16 bits
> of K[], with the high bits zero), then there is exactly twice as much
> key material as needed, and I find that the hash becomes 6c f5 01 ff.
> If I let the key material appear in the high 16 bits of K[] instead, I
> get 01 f8 9d a5.
> 
> Have I made an arithmetic mistake?  Or is the mistake in the draft?
> 
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@rodents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

From mouse@Twig.Rodents.Montreal.QC.CA  Wed Aug  8 23:00:18 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA02850
	for <saag@jis.mit.edu>; Wed, 8 Aug 2001 23:00:18 -0400 (EDT)
Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [216.46.5.3])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA07321
	for <saag@mit.edu>; Wed, 8 Aug 2001 23:00:03 -0400 (EDT)
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id WAA23863;
	Wed, 8 Aug 2001 22:58:53 -0400 (EDT)
Date: Wed, 8 Aug 2001 22:58:53 -0400 (EDT)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200108090258.WAA23863@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: "David A. McGrew" <mcgrew@cisco.com>
Cc: saag@mit.edu
Subject: Re: [saag] I-D ACTION:draft-mcgrew-saag-tmmh-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> thanks for your comments, you found a couple of glitches.

Glad I could help!

> I'll be submitting a corrected version to the ID editor soon.  I'd
> like to mention your contribution in the Acknowledgments section.
> Would you care to be identified solely as "der Mouse
> <mouse@Rodents.Montreal.QC.CA>"?

That'd be fine, yes.  (I try to divorce my mundane identity from my
electronic identity, and the electronic one is the one that has a
reputation attached.)

>> [32-bit example mismatch]
> You're value is correct - I'd used htons() rather than htonl() in my
> key setup routine, [...]

Oops! :-)

One other thing, I don't recall whether I mentioned it before...the
distribution is uneven.  For the 32-bit hash, for example, the values
from 0 to e should occur about twice as often as the values from f to
ffffffff.  Of course, this may not be seen as a problem, but it might
be nice if it were mentioned in the draft, so that people considering
using it could know that property, to help them decide whether it's a
good match to their applications.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From mcgrew@cisco.com  Thu Aug  9 14:41:08 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA07490
	for <saag@jis.mit.edu>; Thu, 9 Aug 2001 14:41:08 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA15736
	for <saag@mit.edu>; Thu, 9 Aug 2001 14:41:07 -0400 (EDT)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f79IenE09191;
	Thu, 9 Aug 2001 11:40:50 -0700 (PDT)
Received: from cisco.com (ssh-rtp1.cisco.com [161.44.11.166])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id ARH02217 (AUTH mcgrew);
	Thu, 9 Aug 2001 11:40:31 -0700 (PDT)
Message-ID: <3B72DA6C.7F51579E@cisco.com>
Date: Thu, 09 Aug 2001 14:46:04 -0400
From: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
CC: saag@mit.edu
Subject: Re: [saag] I-D ACTION:draft-mcgrew-saag-tmmh-00.txt
References: <200108090258.WAA23863@Twig.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

der Mouse wrote:
> 
> > thanks for your comments, you found a couple of glitches.
> 
> Glad I could help!
> 
> > I'll be submitting a corrected version to the ID editor soon.  I'd
> > like to mention your contribution in the Acknowledgments section.
> > Would you care to be identified solely as "der Mouse
> > <mouse@Rodents.Montreal.QC.CA>"?
> 
> That'd be fine, yes.  (I try to divorce my mundane identity from my
> electronic identity, and the electronic one is the one that has a
> reputation attached.)
> 
> >> [32-bit example mismatch]
> > You're value is correct - I'd used htons() rather than htonl() in my
> > key setup routine, [...]
> 
> Oops! :-)
> 
> One other thing, I don't recall whether I mentioned it before...the
> distribution is uneven.  For the 32-bit hash, for example, the values
> from 0 to e should occur about twice as often as the values from f to
> ffffffff.  Of course, this may not be seen as a problem, but it might
> be nice if it were mentioned in the draft, so that people considering
> using it could know that property, to help them decide whether it's a
> good match to their applications.

right.  This fact is implicit in the bound claimed in the security section, but
it would probably be best to add a paragraph describing wegman-carter
authentication, so that no one uses the hash output without encrypting it.

thanks,

David

> 
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@rodents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From mcgrew@cisco.com  Mon Aug 13 10:48:15 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA28993
	for <saag@jis.mit.edu>; Mon, 13 Aug 2001 10:48:15 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04877
	for <saag@mit.edu>; Mon, 13 Aug 2001 10:48:14 -0400 (EDT)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7DEjrD07073;
	Mon, 13 Aug 2001 07:45:53 -0700 (PDT)
Received: from cisco.com (ssh-rtp1.cisco.com [161.44.11.166])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id ARW01094 (AUTH mcgrew);
	Mon, 13 Aug 2001 07:47:41 -0700 (PDT)
Message-ID: <3B77E9DD.A7A77F7E@cisco.com>
Date: Mon, 13 Aug 2001 10:53:17 -0400
From: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff.Hodges@kingsmountain.com
CC: Security Area Advisory Group <saag@mit.edu>
Subject: Re: [saag] RC4 insecurity wrt SSL/TLS?
References: <200108072043.NAA16464@breakaway.Stanford.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jeff.Hodges@kingsmountain.com wrote:
<snip> </snip>
> An additional question is whether typical RC4 implementations-and-APIs give
> the programmer enough lattitude to step into the vulnerable-like-WEP mudpuddle?

technically, yes.  The weakness exploited in the Fluhrer, Mantin, and Shamir
paper is a weakness in the key setup of the algorithm.  

WEP uses a per-packet key, which derived from a master key by prepending the IV
of the packet.  A per-packet key is used because WEP packets use an unreliable
transport, so that continuous use of the same keystream is awkward if not
impossible.  This approach would have been fine if RC4 didn't have a major
related-key weakness, but it did.

There is a clear need for stream ciphers which are packet-oriented, that is,
which can generate a keystream segment for any packet in any order efficiently
and securely.  Some ciphers, such as SEAL, LEVIATHAN, and Counter Mode do this,
though there are ciphers (e.g. SNOW) that one might want to use, but which are
not designed to do this.

Discarding the initial bytes of keystream appears to be sufficient to defeat all
known attacks on the RC4 key setup weakness.  Scott Fluhrer says that 16 bytes
are sufficient; the paraniod might choose 256, which would double the cost of
key setup.

David
mcgrew@cisco.com

> 
> thanks,
> 
> JeffH
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

From ji@research.att.com  Mon Aug 13 11:06:14 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA29101
	for <saag@jis.mit.edu>; Mon, 13 Aug 2001 11:06:14 -0400 (EDT)
From: ji@research.att.com
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA10538
	for <saag@mit.edu>; Mon, 13 Aug 2001 11:06:14 -0400 (EDT)
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
	by mail-blue.research.att.com (Postfix) with ESMTP id DE3FF4CE20
	for <saag@mit.edu>; Mon, 13 Aug 2001 11:06:13 -0400 (EDT)
Received: from arran.research.att.com (arran.research.att.com [135.207.24.12])
	by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id LAA05911
	for <saag@mit.edu>; Mon, 13 Aug 2001 11:06:12 -0400 (EDT)
Received: (from ji@localhost)
	by arran.research.att.com (8.9.3+Sun/8.9.3) id LAA22547
	for saag@mit.edu; Mon, 13 Aug 2001 11:06:12 -0400 (EDT)
Date: Mon, 13 Aug 2001 11:06:12 -0400 (EDT)
Message-Id: <200108131506.LAA22547@arran.research.att.com>
To: saag@mit.edu
Subject: Re: [saag] RC4 insecurity wrt SSL/TLS?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

"David A. McGrew" <mcgrew@cisco.com> wrote:
> There is a clear need for stream ciphers which are packet-oriented, that is,

The clear need is for people to learn when to use block ciphers and
when to use stream ciphers.  802.11 is already transmitting so much
extra stuff in the header that the average of four octets per packet
that would be wasted by using a 64-bit block cipher are worth the
trouble of (mis)using a stream cipher.

/ji - KC2IER

--
 /\  ASCII ribbon  |  John "JI" Ioannidis * Secure Systems Research Department
 \/    campaign    |  AT&T Labs - Research * Florham Park, NJ 07932 * USA
 /\    against     |  "Intellectuals trying to out-intellectual
/  \  HTML email.  |   other intellectuals" (Fritz the Cat)



From pbaker@verisign.com  Wed Aug 15 14:12:11 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA13248
	for <saag@jis.mit.edu>; Wed, 15 Aug 2001 14:12:11 -0400 (EDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA00238
	for <saag@mit.edu>; Wed, 15 Aug 2001 14:12:06 -0400 (EDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102])
        by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA19173
        for <saag@mit.edu>; Wed, 15 Aug 2001 11:15:13 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2653.19)
	id <QS85WNNZ>; Wed, 15 Aug 2001 11:12:02 -0700
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696E4@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'saag@mit.edu'" <saag@mit.edu>
Date: Wed, 15 Aug 2001 11:11:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C125B5.BE2B94C0"
Subject: [saag] FYI: XML Key Agreement Specification
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C125B5.BE2B94C0
Content-Type: text/plain;
	charset="iso-8859-1"

All,

	Members of the group may be interested in the attached paper that
describes a key agreement algorithm that establishes a shared secret between
two parties if an only if the two parties hold the private keys identified
in their credentials and requires only a single request/response round trip.

	I am currently working on conversion to Plaintext/RFC format,
although the diagrams loose a considerable amount when converted.

	The anticipated application area is to secure Web Services, hence
the XML syntax. However the same algorithm could be implemented in another
syntax to support other applications (IPSEC, 802.11b security, TLS).

	The paper will be available from the www.xmltrustcenter.org site in
the near future. 

	Please send comments directly to me rather than the list.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


------_=_NextPart_000_01C125B5.BE2B94C0
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C125B5.BE2B94C0
Content-Type: application/octet-stream;
	name="X-KASS-31.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="X-KASS-31.pdf"

JVBERi0xLjINJeLjz9MNCjI5MiAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gMjk1IA0vSCBb
IDEwOTAgNzc0IF0gDS9MIDQyODY1NSANL0UgMTEyMjI2IA0vTiAyOCANL1QgNDIyNjk2IA0+PiAN
ZW5kb2JqDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTI5MiAyMiANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwODA5IDAwMDAwIG4NCjAw
MDAwMDA5NTAgMDAwMDAgbg0KMDAwMDAwMTg2NCAwMDAwMCBuDQowMDAwMDAyMDIyIDAwMDAwIG4N
CjAwMDAwMDIyMDAgMDAwMDAgbg0KMDAwMDAwMjQxNCAwMDAwMCBuDQowMDAwMDAzMDE3IDAwMDAw
IG4NCjAwMDAwMzg0NjQgMDAwMDAgbg0KMDAwMDAzODY0NSAwMDAwMCBuDQowMDAwMDQwNTQ1IDAw
MDAwIG4NCjAwMDAwNDA3NTEgMDAwMDAgbg0KMDAwMDA0MTIxNCAwMDAwMCBuDQowMDAwMDYyMjE0
IDAwMDAwIG4NCjAwMDAwODM5MjcgMDAwMDAgbg0KMDAwMDA4NDM5MyAwMDAwMCBuDQowMDAwMDg0
NjA2IDAwMDAwIG4NCjAwMDAwODUxMzUgMDAwMDAgbg0KMDAwMDA4NTM1OSAwMDAwMCBuDQowMDAw
MTExNDc3IDAwMDAwIG4NCjAwMDAwMDEwOTAgMDAwMDAgbg0KMDAwMDAwMTg0MiAwMDAwMCBuDQp0
cmFpbGVyDTw8DS9TaXplIDMxNA0vSW5mbyAyODcgMCBSIA0vRW5jcnlwdCAyOTQgMCBSIA0vUm9v
dCAyOTMgMCBSIA0vUHJldiA0MjI2ODUgDS9JRFs8N2ZiOWY3OGI5MTYwYjRiNjhlMGY0OTEwOTMw
YTk4MTQ+PDdmYjlmNzhiOTE2MGI0YjY4ZTBmNDkxMDkzMGE5ODE0Pl0NPj4Nc3RhcnR4cmVmDTAN
JSVFT0YNICAgIA0yOTMgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMjg5IDAgUiAN
L091dGxpbmVzIDI0MSAwIFIgDS9PcGVuQWN0aW9uIFsgMjk1IDAgUiAvWFlaIG51bGwgbnVsbCBu
dWxsIF0gDS9QYWdlTW9kZSAvVXNlTm9uZSANPj4gDWVuZG9iag0yOTQgMCBvYmoNPDwgDS9GaWx0
ZXIgL1N0YW5kYXJkIA0vViAxIA0vUiAyIA0vTyAoIFXHVscuGtcCYI6BlqytRHrTLRfP9YMjX23R
X+19q2cpDS9VICibEZGjQguiWDBNg4xg0Usv4ePtsnWxtq6OgKQB+X1/gCkNL1AgLTEyIA0+PiAN
ZW5kb2JqDTMxMiAwIG9iag08PCAvUyA3ODEgL08gOTA3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M
ZW5ndGggMzEzIDAgUiA+PiANc3RyZWFtDQpigOqu8+9r4AgW88qooDpVrsw4H/QEFQ2xBK1LKTcH
Y1+WkRwv4wIDcRYqjzqt8Zd6SgLFZrMnwQg5ohosdQTaqjtoQzWijP7jp7v/AxKsxksC1fpbG7ZF
YoVDxPxR01QHH/unuKTcgBKoyvxWLMozi093NAp2ujwaIh+BRY004ODQfCg1UmPrprSb5ghVyFbv
uNevpW2YM5h5MSOQzUMADVBC4gI45R0z2JGDlGnSg4tRIfllj3B4SEErdWswxR7h2qkkEhwI5n4S
tFCt8RAi1iDGLHu78G1sebyZ58sucqKyBiRaaTe6QpB2M27uSw1UhYxFIVgpmDGlFy6rz+4y8Oe7
cJ12Ch48YJpdl+LMU0kCRmkkKxUKC+W3JAlCNesBkv9Hjjliq2O3tdaMK9Eki6aJQxJkewCvN2pp
zF9bSj1NW/6h7M28uhtYJofcbDJiCaE0tt7jrABQ/Y1bCDdzVx05oKcxx3dtTYUe6ziPiFRM3lSr
S4LYJJuUxu1iHiVIFr2PgV6xtM6sg7YXvNYRG8QmV1NfU5uSEMCsTDwJvuqYaNrXObG7eiq7uNSv
TX/3Iypyh58TGH8bogQUNozzI1cVp2pWlbratDm36xYWF3XTpQHCR9Dzs3DhGuTURKPrPKgBzqWE
RUgwgPl2nlCWPoCii7AlePfUVWwzFd3Xv+4MpR0lIXUJWk09xm8Lfgk1s8zFitFtbKqfNCRLAzDM
QkjBhT8ibXlV0upykgYafcCkuXSbQLK9a2vf43YKJeSLLDlTxwzqHBJ/wcJaJRVTO7jdygeRdhUL
kFdp5V20x9x6w3UjQNMS6vMsxKbdFaBpPFaOhHxosyICJODfZJsMinVySryosTq0kQGKtdApyvrW
DWVuZHN0cmVhbQ1lbmRvYmoNMzEzIDAgb2JqDTY1OCANZW5kb2JqDTI5NSAwIG9iag08PCANL1R5
cGUgL1BhZ2UgDS9QYXJlbnQgMjg4IDAgUiANL1Jlc291cmNlcyAyOTYgMCBSIA0vQ29udGVudHMg
MzAxIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5
MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjk2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg
L1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIg
L1RUOCAzMDggMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3Bh
Y2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTI5NyAwIG9iag08PCANL1R5cGUgL0Zv
bnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0v
RmxhZ3MgNiANL0ZvbnRCQm94IFsgLTU2OCAtMzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL0ZC
REdPTytUaW1lc05ld1JvbWFuIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIg
Mjk5IDAgUiANPj4gDWVuZG9iag0yOTggMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAv
VHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNjkgDS9XaWR0aHMgWyAyNTAgMCA0
MDggMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAg
NTAwIA01MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggMCA1NjQgNTY0IDAgOTIxIDcyMiA2Njcg
NjY3IDcyMiA2MTEgDTU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYg
MCA2NjcgNTU2IDYxMSA3MjIgNzIyIA05NDQgNzIyIDcyMiAwIDMzMyAwIDMzMyAwIDAgMCA0NDQg
NTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCANMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAg
NTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIA00NDQgNDgwIDAgNDgwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCA0NDQgDTAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDc2MCBdIA0vQmFzZUZvbnQgL0ZCREdP
TytUaW1lc05ld1JvbWFuIA0vRm9udERlc2NyaXB0b3IgMjk3IDAgUiANPj4gDWVuZG9iag0yOTkg
MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNTM1NCAvTGVuZ3RoMSA1MzQz
NiA+PiANc3RyZWFtDQov9J8otZsS9V1b5fldyix/wAxV/gp9UmbZQKT66GC/FdYH4MsUhAA0+WH5
NnCHdhBSnqwOGbwqnhDlFFrdH0UvpxaC9eXkwMyG/ty0Wq35I2RQHG2PcVzurlmBgvyGVcbO0O07
D+k1JoPaFeG8/MCaRDoXqdbhI6dpTardjbj7NYYdrxh3ZZwhdwxkfviVx1Lr3GhIsVyxPtMlOAx8
GSAoHlM6r3bQ90JV6eB4xnFXjfKPziZ01ZRu7bYsXsvYjpjgmM0tPz/uvS5Yw4JDpGBLmDWTnuVd
2ZunByTwWvnyYfcKf20369k82hUXvXTOrNoU1Xg3+EKFfV3gGCZ7ETxSCxTJ2vJ0fw28qcXxu5fY
UdaDzNos1BtZv6euvylfkmTwbR2mGI7KzUZSyLWYekWpzEiz5FahLHnLwifKv3HlOH+hfmGPeVQu
hPGMnIsEU56yyct9HnXMXTTei9NbLLsHrzVqWghbnTvJ+fubFj3sRET8GgjmjTPKLqac842C09KZ
VvNFwgNKy8rfXrVjuODUq0FpBt3FxViNHrN8CqL2iLyT0rTbQyMQDPwOgQ4O00NmsoLZqcwGhUgZ
iXO0rA7vcq5KM6N+nCMYVgnw/GAgHwmmhPcwDcJ8Zx7P26nFEs+3vvu6c+USzQ/52bBm4aucxnlK
/bxhBTdaCtaGup0msKwmEYw62dr0ApTcsOo0yIjCxDOQ6CjG5vhrx6POlJNSDSJdl3g7NvR11lHR
pBfIVtlA5M7Vf7YUacyJK+8XiCrbP8M4zJlQyL0JYPgDkWd46vWVehqCwWClkvULdsH6oE3ZiOG6
QMbp0myu47EhChpIbCsoHNNd4uXQeg8Q/bW7ByPjYzbH6KCR6paboE/QqZNk53WBBbQNtg6PIhPI
Rsa6/c0nef3yhIthbwj4+3IAVdpao1fjEpORKeCtL34UArgTAvuIngSeWjsI4jy5IOYjMUHemFUp
p6Mx71L0j37Lpvd0VvtN6xK/lFl4c6dT7f6SidviDwZ7CDP33OOvO5HuTmI/6ENtY0Nl4tt8w3cB
GYjop3994ufme2nYR1EIfKxui50iwskvyyR8spPaD5GVkku/bOgNEsos0D4zD5rd3QA2DwivivHv
ZrJeioZiO7Fq0oYZc/UHA54rM0AL/WNEy5mVC8YLwyR0QWws2rqyoHzWgEV4dpnUuZvheBXUr07a
6lno4sO5BwMFObgI+4drK/mi36Wf71d2qarKRRJO/V2Qeikd2c5z6QxQ+vPVDMar7xAnGwXtomCw
ZVbuFk/KjncgM6iqkSr3fynWDOxSgYiGHggzHl4bYyZqIuZ/Vpf4difVGrPWRcZ/Q+dcpe4nlZ1S
V/P2yZjkw8e/5kA6PuHPoLGf7rQolpuIVQESO5RAw6IebQIUmpLtTWADHoYjDNcrkJ+IDLEtqzEc
Sh710LohA44ckAp4tEHgwsQgjH6CHeawfv/9nM73ul+zStlH3fb9+o5mgArbg8FevDREMoysToXO
zTLzVXyVP/35llgYIdlBK04v3JnpZiiHRAIuRQhtYgyh0O2U7WyRDZTsWauDtkFp6h3dNLCBgSgX
doU5Gp5nXJm6FcMF3nW748r+YyKUypA+IpADm776H9gMbEFgdODB0nlbjGYSNwSkF7ry3dggfviY
Lo5vBioBR6T9RNE9zgJ5jPnazJ5u/36fCqrfKGsgESQuUOXcvtjIRw7Wj9OHtw79DgwWtIIjD7/r
qRLwZuE9EKtcNdcKDIrUV2zlfhAac+8cUB6yZoIrVbzPzjKx6LB2fMpCst18t1kA69ZsO/ZHOyVC
rymigmu978W4vR17/MUMJiHKjcMB3095vpPaOYTEFjHgy2LEXyGELJznAdyIYUMCnX0p9s9/HdZr
L4Fy050B5q+4PwXThtKg2xoQaPtmFIcIEmQd/Rky8SU9K/0bxkcQXtPnGwflJRHt03ruLz64Dj1m
9j/KDM2EaNup+QK7jVkKg3npK8SIIewndAWjz06T9Ekx+moX2HJDdovf3z/WhRmBkOcgqZsBWFS4
k36BP1KKrEJFZAypVDD3IOVp9FB8/IkLSn2LN97AkjcBDe0UIUROrDjeqc5AeygosEnGK4uvXSOu
3D3zmkUOFv6bpR1cE0SiZ2jZWE8ZMcLs0FU9RbQb9Qwo60k1YfG15qd6U3IOCbDVu0qxNvFBhfa4
pMo0ILRgAfodB5+yE49yMJ6Y4I6QsoRSQVPSIaG9xD/xT9WDwdtpbaMYWZey4wM8R5Ia/99w29WK
t1xoZefIPpyjBM8d5mrToRsZmUCD4wP2RlMcpm5qf6rjkLj2HbauSAKVRFJIzyhGqfp6eYeUkDcu
zq9qYDLmKAuqfYruvlfoXuPG5H9QlPqwK7bxjEfoBfN9FsDMvqqT4sq28+Dn6SZjeLaxOcI1DmRV
CAgyuz4/aVOfPPveAfccCFTZSdLk2MQKk2wE7UdHV/14Fb373idpIDDVd40f5Iw5H5vl5LuGE3Ba
DQ/jXqlSGGND+AFZ3EW/5/O7L3H1ER1ACAbnO+TRC7Uxo+t7cr7IWFHYJhFrpy16Atrv3W8Zvdti
5f+Pm8pnlcBss2WxnB/4h9409y9vT41kGZVdpsS1b5k9/i1b3JvH256xUWj5ZgeP0C7I4utPT1pg
aXTX4mjgj1NcdhB7If5qGP0YN24tZx7yy0yIiajw9npl7FoDHVxJr41vC1quuiBrdUO+cSqxZUSV
HdUz0O/BFjisqjuskLkRXYFDwiXZh7Ug7P0WQMTkE3D9FkUQSK/7J9nGw5xzlPtXGuQA2xoXtCp+
EP4oaSjmBDU/RaIUNjr+O2MIi90NuLHjPwqTeJtlSxmDk2eI7H3g3Dd7BPglY4QHGbdtBY2fRydb
fJ77S7D0sh+7A5FaNhj9eNa/qBCiZtbpHXXktU5HETw5TRWdKZF97kBPgJEpp9jIjRwBPmPepYYW
VZYVO++Mef7rSVBmyL2pCaOBdYJZKDnNaMUYs6OMZPGJwUB22jCCmId8Snx5+C2EFC7xGz+5dWmj
4e+CEigY97LWrBkXcm5fIdkDUNXmFRF0okdOUun9F5CFdCYgzcuE92NjaYSotRtbPy+Le1K/D+fh
UGid5cArlAC52oFlWEn0p+PAfCYTIC1Cc5oxrF7kNfa2Q5Oscp3WPRzp/tiajZjtUrgB19DTPXxE
HQwsqvUOLrQHadJVRZItjSoOhtbZfnh9WojE6EYTVXemxQvDKX6g1TaHQxnyvIzjG1NrHKi+GEus
TIqv5CPUAINVQY5HOzIx7nejRYzbPi6Sja/loX+rQ0Ym7d7vuu2H5ieO6ZCmfvq7dzJ3/aBhcffH
kQORghCgKn1orcA85WbzrZPGYU1yNPgKke9ZqlFXGulFmdf6Py0BD+bS/rhX2Ubrl4WAXnP+5xK9
Mjh+B9+aJrU+kiFHAcuHjm0z42VRGAo1lFTo07I/Tc3IPBp2o2+A6NFWdNcxxfBymyXXTag5WsM9
/y/FPZA6j6R4WgVS+g/LxY+baiANGhJf5CFKJpngEYGUwuMBosSO5b1gYElS2pwhgE94mgyzOoM2
qMRyfPhUyRfD4LVFOAOOL4RwQL5AqBf54gPy+Mi6DNv50nPGEmkpCApybSFaTFECLOrRk7APvezG
Wc5wTf+gx8TB7rzXcVd6FkxRXeRyoaenRLqysbxWpv1WjcSbqIQPgjhCnooWD91uBYuxQBkqzHLa
7WTOxgE42+vgUJdazFCa7kpYffW1zHADP0uP77NPOyqS36zwLJ4OEYuUGj4sM+UtsgePv91pQ1lp
60iUktBGIcr32c7WYRLILfayp6ihK52Xw9qYm12VPHm+RiJzh3A+K78U1OHSfdItFRHnBH/PhD8F
kqqeS6hru3W5zMOyNiYgqmybL2fXaApm9ZlMINZ6CD3wBvrx1+YLhuURjlkVWZSwo23dfkmJgzBx
hjFuJrqwxvT+OhpP9Y+kXc3EfPZfUyZo1YahHQ4ATbtP8rk8LqE6RJ36p3EjR3+qQ6fssqmDfVhx
Ua+LTDMtWV07bYk/4Dh1Vo6NtCJ2VGSUwWp2aZLpGQblBUFUuBhUSOefgL9tV1pd8wnPAeTKtC2o
giiKRsU03ZR8xILpi9CBPEQIIvallvZ18vH5wrvof7ZnxULJ/srRP07V/r0kYJ15R6UPeQYZAATy
lJJAAeD1ArWA/t7qOhvPFJh0TuoZVQQwAGzP8CRu4FbOYIsIfVhKnnOb806DQT7cRkJeuEC4dGQ+
L8TDxjlnauqitGG37BNOj5OUUjEFqh2eJ6YjQGFG655NaM4RaVlzEnVbExWlw4Kw9LPA+1412xcI
mxbJK7KQfSxOFAs7IAJs21kfPeagJ4myUWE+GLm84i3UdJusJNQbvbYaHRTk0OB3w6zuMfhanZOE
hbgyL6oZro/qbvTmRclwRAk06m8HYpoq3Tmbqheaux3YzVzSBb1VAPZMKdWcXd3OWmF4FLPZ6XS7
mP3fTX9+2/AC+eC319Rs0hsnHLVcp7gHF5SfDpQrlhZRFcAR3h/4e6ve40kF1D+Q3IU5RsYSBf7x
LAnD/iYSWg3BhW/RSa771NQU8tPY4m67cfgI3o5/6JhKZ6UDAv6QhNPh/kKfA+rj4CilOguDc3Gm
k7yQuY0DgkfqnnF+NE8/1jX+ED3csnrc2qXfvuDyiFx0geP8yKLZQwRN5xJ79zN+fy1OpCTxtQeo
+vFQqYNrJFURBBl9I6DpuKzKNVXERBTWwDgyauilUPtL7CRe6p5ThoV3C8Pf3NTAlKZUynkFMVSD
wdZAqYt+a59iGCJMZov5CtHTuFSi7LmzTJznCxtim6X3nmlmRj5OGXFS4GNeszFNjZXbeBPtQxZz
LjTAgkaPj1Chx7G/2lM1q+sHUJTpMpibBFF/0RFTK5L0dN54OBdtlkeIKcKBjlCeVtsEYcNWGw+J
hPJz7Vfo0bRdNwjrhsGJBFuwg4nOBaYaghqF1Wo8FmkyAZ0xcI/kxOZQrs86z44jOXXg82ACEz+0
xdnyPeahrvAXzrY5fv6riN6ua/FYFPlX5XeGZ0OCqfPV4jDMSUe4JZgIeVLmWZsryFerFHBKW15U
q0Te/zsnzFm6ASzSAB5crjQLYE5fUGjSDE82IDT4wELUu1Madpx4x2ql+OKO4lWpQbai5Ia5yR+h
Lheodn+7JsnW1nMf62l2PWtc0pKKKH1DXukYJXfV7gPStR68T0YLbrPKl4JSzD6mHFLgV0f3AE4I
y7Txrmeo4EgOLYWa88sX8Ch7ix9PECZs5dgJs6OqbS4PWPKI4GvVS1YqlwlsvEl7jInIOdEuCmhw
nUuVy1itUbZulsfoJRI5l3byFQz0h/8nGDE7oZbKFupq9APHAYJYI2UVazviKPrRLKhSZdk2O7dR
fEKpqFlTS+uhl3lQovnr840kj8BzNP2TsSoIsvxCGMVPuVT9AUR1+WQFV3TzAdcVrSxOqMFhXdks
fyQxNjfdpiavrOdyYRA8psHYts9xPp8wqQH30New+xB8Lot1kdVp7ZG9D0zbcy92DbNtWEIT6NNp
hoaNXx34U5ZUwVx+3nvNKd7MQaAjiWEuubJiYxquD1w4ecDRl03MrTDIO1+p3BVrAjq+OROq6vm9
uta7FdwHkXb/QUbmIKLAn6lZW726CMUODdncfqzgOfWsK18ErAyEpb+HTieUUUaTdH3mNfJLw7/h
z+OGxvdCcoX5jIWThJfl3rvV5brEbH0PPJkEVdLTJzyH1DStvafq7Y8OgDixH/HfnBp1692pGr50
Q15nXG1UwegkagVBrHoA0xnbtJ8wdCTqAEC2O/i86sb7f/SlX8arPTt9LU1O0Gn8Yv201qvqw+4u
EhgzH63Hx42Py1oyRAPqE4ACPkuucHILeZLQ7mkWKHNswjbm9qLRuP0K2K4b6JUtuZ4zmcWS1m89
sDyreE5clFMzWBXwXDhEDYxDpucL5+dPvhfr53hcS7wm9MBQtZ83vlmyyk16YjmawZOm00dVu0bI
Prs/v+BzvIpPpY2e/LyJzoytyaiBHpGmdSleTeyfONiqc+kL6WDgHJ8w5yDtzPYDUl4wbMlqqA/+
ez6ur4QId1FKh3M+Y04iSoflWsywwRGeJIHrjqRjTX1fZpaZYq8bNR2BkGDRW9/2CzSLJmABnMPU
+RwvwZQrK4FkOb557hgA1MOU61OOGGhsqN6CcDcitQX7TsGreP4i73Fe05SMojmQqodTVDoK8GqU
TI4AZVrTcu2WucAr2HiBLx8bfbiUajlwv/ZUBGylz1HYqF5X77LX8AAX5EfR+aTNyM4VwhUHMCPi
f/73aB+ws1frKAhbsMpvZo2ScLouDmof8NleypGY/wnwR+G6fQA58mwBvUk8PqA2tJVBby9Ic6sP
ZFjkyC4wwt1s0Nl76OF2Vp1lCjj1hf4eMK1XaRHCQ0rOLpLl1mANGJFSpt4Fhfe+8fPNbGGhq3J7
oXOQ8XjqxJp7Kua3wIRWXyA7gSiSQJKMspP73TTwdpA42OxIj1G7ipZHR9lMKv0P2Q6TNlDkEryQ
xjaBTs+kt60wiIfKVH5MPzUHSh1ZPbc7nuuV4mIytkcRiRAhZCyo8eOsIzzLGmQIgY1MqHxL+WLd
Gdzz71pEvptEbniH1CdBXsbcFz1QSnBQ9uWV3Xe0CbvZsqJx19969EKuwhr9u/aKN7SQK4yOknYV
Zgl8+JisZe+7d0zSIvH9fB9PGYWN6NFY9Htz5wK8EP4s+Ig1z9npkpONI7nAfzpY9+0nKwoLyZtv
8d1cAJMyKhNIjmfoH/rRB1WmynnEkZtm73nnGLFHIWgzRj1aDGcSAON/iOHB/XrA6xmGUte6kf/b
kYo7uu1Sjp088/5IgXVHz2BR4u49ikad+IlUyT1HqmRmolQ2L0UQLiXSHsshhh54MuKfLTHggA8F
dA/stuI5dW3Qh0oxYayiwrkhZG+PqRZ7/JacZuIDYY1Xmu1CNswb5nToPqBOgOZqAoh8Q6QqG0xk
86jQzRCMI2qPqDom97yQE5eiTnZ0GanYbb7l6L/sJizFPuHmaF9nnf02VqCk0Zq8Gu4GaRwL/HfW
SvVmlm9q5eu3gFzK7a4IMCp71yvha925Jbs0GCd+emh9/ahfI48Wj1a+meR7ZsIFyWCCn/Pt4XoA
btDt8ZGDmUjZm4Z608vPK4L+7tn/toIW3nlrbCWOEBoQ4OdYTVEAcvKolEGluFZW1ccoOIJBFDcj
X8Gq2toR6ICrxmLUDPWO7VRB3hGtYl6DllKaDyxEAK8c7Wr5+ryULf7bDoaaDX7XDLa044wTfJXm
BX9wllMLvdRilI4iSUk1Yazd6EGCbks93pDQxIEAOMACJRZhx4M66643Ly6jebVRsueLhE9MTgdk
rH3a7eNImSdtIc55ewB1H6t6A1WjqE9+fKYu2/MplKFRXwF99ImF3x2yNWVgcq6x6rfpFuxAKW82
v4NO6ZUMEWpr1tx918YRgIccY5ZlARk3jfGBnsyT+1guIZ23shH5Z+Aq2w3QcCuXyty7QZmV1tg4
ADI+Kn0dx5BILDUCm/h40pmoutdW3n9jhfXO/bF/SslnYRh/1EZB11X3k1R476R3bJ92PaSMdsrU
raRRzuNTLbQXYMOqhK0hHSYT+PdswgfMMFSi3g/vvadgZkQQbqg8kgB7txvqFUVcGrDl4alo56Dj
/Omm/e+KRRTeg9kKpKpFqAT7TF8w+vB2VQ1ZDcAeXIzkmRiI0gwTX3kaCcs4h7a8K8+tdolUZNbX
8yAn9NhcTyHxPP6fg+j1qvAGL2YvoIujVTpz4P68HnlhIm/KWe5dKfgX0BCdJXImJzXZ7TNOes3p
rYENRXsc91RnVAwalvTAj8YwNKDCNq+BiNxpDcNCN4NiWkcQd3bSMdpVZM+GNrKP2SxrAbHsbZqM
srIWmYZd+kJqXmNy7094/VGAuHt7uXkmwBO+s1B/MwLXzvQydVzCWpvL0hJv2YJTQveoXi9lNL/g
orLjBDo7hx9N9u1k1EpyRXwmXZFJP7IIyU68yC3CqRPMNgUOi8WOkBpAR7wjX6QQTtZxmFtEJpww
wUVsmoWYRC2ZVzVHInHBI+DPdNZvUPQWLofUlwMRSM+4wL+vgJ5JyT0Ls+yt43H+rz2iYZgglDhy
qOKXY5I6oHcen+r5TEtmTDNoNyMoLYw2NeMOt6bBWxPQOMH57iQjo/+etjq0RG1tO+oeEGiA0xF5
8g2F3WG7NGfgye/ffg/8erKB6QVK2Go9iAaPsOeKIx+jBmk8GwRXLtrpoL7XrQ/uTbGMSjxBevmE
pThITtcv4b6JTbEHYufbdf8sba1/6eLM7yJ1V+mva+cpLYO7t/00FUq86woBrghX1x3RQ5/PXNLO
SKUOUBi9yjTKFtHW56dNMtH20fhjni0C10JsdBtT+2NKG6aVcU9NpdMG59q/fRgmk57b97GFr35g
OpFOMSVV0BUlFNCS5EnmFgWFzpS3K9KS1NTNffefqYcIx8EWVzkdDD3b95RR529pUcrY5y4/Twfc
o8fHkCm3ndAswBZjYKYNMXfnl0o1EQQC5NOh5cVY3ooLh77u+DN9W/IUOCgSnU+PCRuN9I6fFLIc
1jo+RBnno8x+UkhDtth7lU9RLceqNNN/k5iXkSV06wQ8/XRAAVZNXY2wmHxUgYkeMDPIEm8lH6Qp
CZns2fFuKFLa3ME5X2P4Xtyzc2MJ4Va38DdLlnhRhJUYgcnXzyj/73EDjTVVvdrB7H0vlL2f0qoH
ME0d3bXD2HOfPLkqnuBR199p8akyyYFtDlbEvdcTpTUG5pTw+Q+XLFtlRu8fjgAF/+mMZW3/7fyf
kL3WZ5QQxVnEk3JAmfOthVazLeT0psshRpvpUHjLL/iEHrnITFFm5r8BJaM0x+KVief2QttqPG6C
0pXIcAVq48xyvOuYbDxSFxyXoz4j8YeNLosxtKeiBxcuQ1tYyG6PMqzU2eut0ym4OSNyWbNohMS3
KxCZlYry2NGu9U1nJ06r9s0vNxbThd/EEt1gu2Hj3cHWxAvYQsLXn/XZSzBo9irzUgGmg3r2Em4d
L2vsHL/2FLIhHmwbsBZ49S+5ebJ+AuAI1cO1aHt+YNg+QkwTYbTwVXwU6FIzHjTUfSZIwG0dddvr
zVnXrPAI10miVk2noiZSObIgGb9H5WNd5BGITro4zqJysphGugA5CrWZXZ9ASGIXyPCQ1rVqkToN
auUa8Zp1g7Am0gOuoPFRc9UxH3x8nNgKexA+0D6jQDEB5JpZHBRG7BNoiRJqnWOBqHy4Aj0ZeScm
tIAIVj6o7s+gjPjaS1W4N+qZKXpOyz15QehoZYqwoO6+KonNb+EhLGsm2Ssz6/2g1P6AfG/QMmPn
UnZEmPV2DnJOipD5EbiIIqIiOrJRmjXmxNXKv2v/8PlQbd424vSmtU2aWCD7upFYfFe/cvA/W1+b
3V1F8J97Qa6H39XYNckV6p8LiP/gELR4c5jw8JWEbLPMMx3tGkjQk7rUtwTCCVXWi1A+gIjLY9aC
f3px+AwsIs+S2dgebCkyWw4muFgvwm97e06aQPIBkpI+q87njCAkFRNZxePG9NOZfAGwlhYBJTeC
c2ey+xk6uongMAG0TsUoy7HuWLFedkNvlqBASeQrFFZx88W5/rGEAAbYaYxo23iOHBz144W1nU8q
Q/pW1RN9miTzwFUSaBknd/E6zMWUPnf2UdOnXkSyNgXDiU5IxuPdfGQpSm3ff0NUoPXU4XGGbc1F
NRMqCMklkXivfmPgT5VkhoN+w7gzIydWK+l5hizFV8zOAP60Yn6XccD9v+9u/arDGBZz0RMXBm2H
l6kV9S7wK6wWImh/iBM8bXaN5Mf3iOBEVdoGsx53TABl1d5jxzqgfhd8nNiflV6gyXSGIbB+mCYB
JXaH/NUOM5mTIig1vZmQe8vMcEQPFmFpyZKl+8c5tJoWoAQlX2xiUbW0Wc6MI830aMdrTsDV7o6Y
kREEaZofDwFU0rcDhmVminTUP8nci4BX0UXpL+tFDeayiaYEKpoQVwJoCSk47RsYpiIWTgDt1E47
mCZOsr5ARWQLMCEZYSLbTvdYwxZqptDf6IS0YJ4IljBZdzAbTEg3Op1jQSYWB2NCP0WK1EpS86yd
1AA885BtZlT53DN6RhOgS+4dtsdLcaHSNgWg+XXGj2KwTtoqMMszsGB1bs4lIqjmmOeTK3cjK/os
CVaZVzzwN0WUFNaxHYBOYhByUgcFUnWDxDyYvt2nflPOVGMgSG53pAI42hxlVzzXqxzRXnkiPnjd
PTeecJc0qVG5Jo2yFQjMLSitHs1pkWDWaowOTQL2yolUHgDPXgLSg36RdjbRYkObtYHA8fSo1Tqm
k8k9A39Y4SUtftk2MTZPu+3w7eJOcttMOElVU9pJ3ir5eGGhRmaPVIh7zRAUJoiDT7Z2agFTiKMR
IsomdpgVlWF8gRWsvIW6jtj7l0wEsMMRMIvVtyy7zj6UnOAsWR2Xd6NCRqHoMoAa4GSOM/vecbjb
vGzrZf/2nNepoqH88jR2TkuGUQvVBd7W6RCAqRwgRHjnQjlH/6sCT2l++KDGif8673daVcitDKa4
lvBeE8w5yPnDVSecr1I8RLdD5+GX61/5BD8+hOcSOwA/u8tIYqpy6hkvvS/HmVp6nhx26GPJIwQ/
E3etD37mDzToyiScysRVQFf4GrbGlzdppLK+dALmkrQsy2lAgmHRzKU5N3RErm5tdPae4wjEJyyC
IU1gl01o1ifU2rrnRUz/LxY4hFM9qbyp9Rz16Ced+UGJR4NN5nXkrjHr/9qZ8Ej4TRoy5xJTl5Pn
pXCki2nUR2NN4Kc5mSyGQql+0vEY5rMlQN8qUWlOeApVAU24XFOSqNqhxhUxhYXCv0Ywdm9p31FC
GRaTYiR4DEI27eXDUQ6Uc5SjvN94UZMDx7qV8LbqF3PylgORy8kTDX0+K0wJLos9qUyEIAFmFbFe
Mdu2MX2xhTg4wLwLhqQpEgsGnss1mV9a2pdsJqVZj4m7wjPi7//3DXXNzFEwByc/0i6CHUfPWN9z
Bgv+DcNbFkxGigRDQlvoZQGJPBLvndKXoBuyusBVXNOmPnM8myWJuCrlcXoCwDtnnCpQtmczTIH7
eJriisHpJ3AwDk/oM+pJLJA1/lNBMmw9uYOTH0ISNl2GsquX02OokJnWugJZQRpgACoUmE/SAsN6
3PAq48+qEuov2wFsXaTuBQV1c9kyfFr3FgKUFx/LhpbYiKTXHL4vSzl99Azboc1zX54aLDwwKvJN
A1T2JzmjOYesDClK9pnD41yQbfmwSaq/C+I825diWCvcEGdterBuGPU6HsEfuhafsHVzNLl2edS2
agQ+KweRlZEJXFYQ7OAyrDMqmW+LB07yfGwHY3S4IQnJ6YGXb486lY4MrkeJD5PVYkvSBAOzI4O+
2Y8M/4grxx+PVoV0qnG5wnA24tUHjroBGWXNJcW5PVEJIhn4echzACVbD7JqDqqNslMI9qbTpYQS
ILfYxS2JoA62b9M2rdLDU47basQsGTjzgfLCR/wivMJqIV3NUJnaxDQrfBF+GHHMMsQNWn2AQOI3
D/+Lic5/oeMGbVCjI9BRk5Dj20l0AU0j/UIOqnn0IMagydFozTHtX8wye/UDdlzEBDFX9wbJupxe
CL/lGilpBghfkYCuXZG1KolLfFif7pvpOwE/Mo+1gaAx3+tYlW377dMWDn0JvE9rMt36K5oWPWL9
tX1l1Im5kynsZJMCZoRmx71t4acCSBgmlQAozBifGOPKQEB4QL1kJY+0JYDTEstf5Fov18hQkhDF
e1AcSskyk/uhSypVe+4iDSXtButBTxIOmG9GRM3UKaA0DIA00oHb6Q5r1jOi9jIzJIv7PUIXgmyq
LSsugWvpviJJrMEnoGkT8nb0vJiokIwt0fqZMrHBsutzdHU6YWOyc9ZGcD76He5WONLjpSAapFlR
V1HIxjzq/W5gpQbDmnIx3E5MrH/SZfIPk5A/Svmt1gZbgHrnu8WPcnezCHa5i0nUyip3ogpMLP/9
iNOg1SwqrCJn7BJyFKZHrtU77VHpZIFYXSSdZk8Gv9Y4Py9gmvJs/RfozoAqNrgs9ArN30cmwqIW
0Rpeb0QrX3fl+wUbwrcJTibFKanzwuJ5yv2pVwFzVUsehYaWw/EFuobcvpp0w5T0CZE/9B689Jc8
QG2vxjrlLzTpAllNgqQ1q9U2UOl7LmC2YpytixW+riaYv7yU4Dcip8nI2Fl7QF0z6umuTaORa1oF
yDV1zm4KkAAaWuGt2ynohQGV7HPLWHzOR7qTp34VRDQQzjKszzF3KyRkgFAqVDPvg7wNB5JsYsJX
T1DnSu18WCaMVXb7IERH/kjeT5wJ3K7nuoX9CgNgc9mq8cFQ5+Wz1htovax9C3Y6nE5buPGDSuu0
cGRyfYDtZ9yPzrZ2ovDFYL0uor7OE3rM84WKL7CgkvXIjwCa16NAUvEtzMl9ON5b6Y3EwY+Tgyds
/n2sDdJRwVA4ahkVFT4KPO95xyJgFySwDi0Mht1OE3LUBKYn9a+HpLYHxa9CXwGUwQWjI5ocH2ZG
gBfSFHBHTGANBeyk+GryIfvDPAoQBCXOYMfFtfAOVaZ9eIIHqJ6Hcwwh/mtprvAfgm5bKG/HGC3f
nzesVz3iCl8o2AIN9kuAAyusn6jtgLVy9PzUeIWLlQfMAxq7Kn5DF/UvTyzlm9HDEJNXBm15t9dO
g4QQFxZDacvHhh2UaNjEQr2b/KLWHMafOtnq6cOzBY0gR9UvQZ1GQo2QxHRto2yltboipBr/cRua
8wyzvOJu3oStZ69yxMlKt+ooDBXLwVVmyM2Jftqb/Rb0w3JChOi7wTnyNLiSpOeckSShtenqwraT
qOjifquHnpso1R/w+aqt3e/QZ+whUwSfTH/DFsGBtu7Bhbg3rwc3Aj+CawuPZj0qdxPYjLXTBSjD
Lgf7Xsh6BMDqshOU91tVFtrDuqZD6eLlzeJfuQbYaxzBnU6FgkQf3EetMYRZbQ3JiEJDrkRtSe3w
Nz+90UVisNJkderssA8a9zDvS9XVDIMV/cCNl5EaWvlmRWc8yx8ZNIuNniAAlsAMo/u2ziif/fK2
KsjkTB3K1VNkx3kFhbXj+db50XHp1Hdr9Bb3Vt1hDI8WS9SqyrnbVLm7GGRalmGbu0mOZuxRzAvw
Pqk5wAmiryo9o+gDiuwwqx4507eBwSBJXQWA0G5sLLeJejyUGYquJdCwOaMF1/N8vfgJMYpYJs48
vXUvHDhJ2PnxfGDvp0xR9M0kjAxMDAo7iPseIL4dLPcP8nmJtLliuDGqY/XA/OND8I/mfxKDG0Xj
fqhzaDlrc9xiQInLh0IxYFVXdOrBf7XMjTTiNvVDlweX0425KRFFy3B+9g1HiWs0dMwJMzVeNzeG
kz5xisa5tc4X0igssT6BiRcxSc4/zRXZQAuipoywaN1MSUxPPl5HEOF94VrM0UP4ZZ9G/YmSvsdS
1zXDsChu1VpjhhlBZjXPaHB9K67QwHNIE48y4+9BL3Ve5Q3PZtazhuZc58cZutTC2bktQfd2OBnu
enZRlqJFxjj47as96G8zcU7CIx+2P2sAqR1wAP3qAdLDFT7sBZJWzNY0AdLnZrdHIGIntSw3oB8w
T6alALjF29KHSdLKO8uXL9y4nSfn9XAjg5KVNBxAxgebGmbEeeMG+gHlocz6PHqpYpjvLHAOZRR0
7s7PvLHNTc9LtvSo/ReXjpkQHVe9BNetL2XoWei7ZllzcwOKdieRwHYmas1alMXALTUDdO+JSiYj
rAG6MddQN6tNOPW20/jwW7y41uYf4NFBgzApM3J4ALcbtg/nqy/6wKMfc88P+h96A6xYQu4TAQq3
t9aEi3TPqKABxvVjn9pTRvqHwLWnvHdUdXRxXgmMLmVRCw7k75jvUtw1NTmoa69/g44Z/Grs/8c0
eRKF5kiEnacItdHGEkRwWrGxScRgY6yUV0jJL5wY+vyogJUev7uC3pbkSuVOGNpRiqWFffBkMnA0
cUGywA/3oTZc7/yhxHskgrpqvpNG729WNTeVFNsdjUA7QRdYHSUvdXegqF6u8Y5ijBxs9sKJ3RgY
xRXcXfqWv2SWRr8nrf2eBp90pBUcLaxYIdNMo5LPT/8npr4jt1RbEiVuDJt1wiboyF1DrvfaY4Ee
U93mLJCRh2twbi3ZwlTEKjn+hzpDIWh9m5tYMF5vMdwz9hRvMkUkggB49o37fyKorsiC4uonIPJB
0BcuhOpUTq9KfQhKSSLwJRMTaX/BpAtYkSXy9hJ/VmDYdKdrYSwRrZ1Bq5oqWmwDUzYvG8BPFN8L
WmkFAWr8mu/Gez8xfwBslv2FUgfn5ocI5T0IzSYl7fEyj+jr4JMEhOpGVbX8er0GPPwOROakxbQC
KSdcND+x2pXcMd3DLzJ0cgpVkICnfirW5xBtsak194EVq07frAt6WWZXJ5boanbyC/nM1TAtX80r
vgvmT3Q0z26Z79T99GPWO5UsdD5rUw356m9SrTrFUz6wTo0UWE7MXODXiuFU88gV8fsVFeMq+74U
VOmQ2UwLcjaq8qwQ5Cuas0S98X2y7aPRWxUYpoZuapXxm7BRV/CgzgHN5ZJfESVnmKrRmAKRXDDN
cLgmOI2iE6jwrr63p7DuUYx8D7SUW/HboCEsa8j7Uk9yfMQSgNxuCV1T2feD5fW47ruwpDEpv6Iu
sKgP6ztjhr2OTBgYPBKyHYOUodZdcRaaoGrA8smQAcYTZSQZXrmDZrodLM31iG1YkvFRZ41XrKIY
hrIdSjR51omnguvje8z6izMOHSOL5qRPcla25xlds6bEk0z0+J65FMO8Zo5T6zN+qNya23KINkPR
WDL55O5Avu4ll1AwqEZ2nZFWW2TDRFKNOEJ31JAU36g7ilbWHcJcNgMlqpRGT29m0ZflUQzYGt4k
adPc3ld1Ycg8FXXqGNMNAPrRA8Wc0qFRWkigWtQCjXD2DXyPlPPGMvdYHOr2ZCUr9apouXvW3uXE
RQgiBE4B5s8eZfwCwxjbSZgdjo0RDgd/aaG+vEEFuxTMWyiA9tRFT3wYRyKQan5Xv7//7K1oqKEK
bdWxuQyRW28aYNrxdXP4ThRPt/M9Lp5A2FawHxGcspWJcYfSc9N+lx5s+dE17jW0+xFMJ1s8b+yn
sVqhflCbT/YG/oFISDvW+OmGlklka5V0Aei+O07PAbdrVFDlLyF7jqwUfU5E1LzC5Ym7ODxZ9y9M
YHA8txl7CT1aKOwvySpvgypOrzvovT1lD/rrnQszj+zBWmr6gGOZr1A0aAWAPI8lmGITRZZNEvL/
cok44s7yIxRq+CwJ7gpXJ9qZAFrjwq+Cu3ByxINLnCZFi1tOGnme0xD5H9zo0GkBJU8AiMNWZtzU
ClNxHxN1HO6wvv8VZiTojJieXtdIIawSLoRsTWGUOpEEqWrOZTSTVLhDx2+P9LLlH2peGBBrS5VR
duXZgpgR/mmULaErtgVAJDYf+FAbV5AEFDQhA3PAy8jFKcHOIgfcDWSLwxNfMLYvT5cJzUlrWFyP
7rZ9xmLt+YKmPEOFQzViI5UHrddnZHxWfZlGCiYm4hKh1ziYBd3lj2bsFziZUZ21h2GkPKa62uu+
NGJUhkJ72jw/jQ42Oz6YfXyW9HMdMYhBKBji45QDiyNa7Q7sSOvy+8B4eoUK+tvjlEKhWf4/i5ty
4AXXHRNs0/ZN2STWiu7PbR6ZNGhiiVs4agtkdFS3bMh+/49b1LL0D0cwt0kuEF2zGX04xKBGnNc2
5qRwRO7yy3/qGq373XlMJRB/X96WxYBWFsw0C4Ius05dCHvAdkZ0VrGJMQzhRHcxZjsndOA3ccXK
wNZEAlQZHR9JuwbCbBC5iXlVDcLdqdYuoesEUdZqD1MaK8J51uJCldirgjBFtBO0oZfYa5d/Pq3H
haymxxA69YC1xSBkvvKS2E5Xe/447lNq0wP0qJQtvGK6HKaOA7SKtBKvp+mZz56Iu/lYpWF31T+B
w+TcztARfv2x+95qj+kIcI+yIiRELJDB9AWaGwo79u7vXuqZZgjsgzXC4B84LUIBScDKdhRG+yVK
lu5bvk4a2GdtXf5rVb/UZGPGBkJ5GUA6VaxpdXb3oIUiwu7/fYUeqOmktwUTVdzD6t7pWTrwQD30
fIy2On5rY4kBsdr6KmurxAgmWvzeRADh5/yaee6/ko/cX8k8O6lwVfTJKT4FBnuKXWsLwS2Ufnbz
13OZ3Ox6bl4baGxUyg1I52nr4IZBV1snYWMjiEs60cZ43Jsi9slmzovFuhuCzkcNCotnIKsMtj18
I79aUsZIlJXISM2Rf3AlQcamkawhsWzqkKHLJK1QfpphmnvIKBwKGk4SM2pRnnIdiw/ibiU1H76v
4zTHWNRO3ELtjVMvu/3odY/9jB4V2mKZiGWxDPr0m2EVdoNfv8b0E02W2j5ObotTLqYqGckZLxcw
yXQRgx8JakNrz/hOky9c6h2DeGdxa52e21MUU7NvRoYeS7lKMbgn+2O+rANEjD/PGntRCTrMQ7V6
qLq7bMPe3WnLmKJA4z5+KL//jlH9yVJsqRPvqa6yEEr6rLPvhAKlQb4ISto+zZ9Q4HzssUpmq+qh
Bf5vujt4pRe73/BMZG8dtEZP73pgW1rUg50wRUpElGqyAwm/0OYcLx3mHxvafOzQdyyfUOZj2p5c
yevViQ5Z7/ZKURky7NIoNWzn5lERfT9SZECAMCMqoWmJQmXKPjw6wk/L6h+bkVyI6ABv4nquqxj0
Jwgh8M4Tm7INN7BjzOxNBS0iCJYhmxBj6GyxfjUe6g/B3v7hvBfMjptmoQJtLI7sn6n19C9Eli43
DuqMt3gShWv4oWUPhUUJWjCuvvz5wfKDgU692zLZOdoO+HROap7iLgd776lMo7HbANseAmU3cpMe
GC/z5KZi5F/g2GzcxV1EJPEJxMAexBcQ91VMlzRnYKah7bie780QFauE2gHW5k4nFBf8o8DvM80G
WThLXo8EcO3TAH4uqzr5xkGXVtHuBwCrlB7sZpLsdZlPL1x3ph7S8e3Hr5b0zSybvMoM1GzSycBq
jq8eU25TkBBl1e1fJbNoQN25fmgNKNoVMcetJ7S/5GoEBLALhk29lDZOoR7FaJ4eq1/R9hGRpujf
QBcEoFB0rRW0zNd5eetZxNf87i7g5IzMghv2aE9qLzI0PprsxCkDe/Evd0pvO1o6HldTWxzMTPiN
ZA/Ea3pC+k2b3cJJZryel1sgyvATPj5KOzo0xhD+ydo0pb8W+RU68O5Rw4hAN3W5Maf4eOxH/K5S
ugeZ1dNQzrAUGOEZjimhHdrxdyxWA2nbk/l9VcVc0biFbxkN1SFjfGaCigHeYQNHS8B0E5FAJS4z
2O/g0GC8MqY4g2RRfR2Iux4GCl4MrQHNntR2k7wYiiWBx8ZTelEHwvRfPcCukcl7mhzj0jUmYX0C
LxznfhqT+itSSydrnlIbQdchM57co7fBRjkpXU3n6ZaC5aNu1d04lg8ifP2M3dRqnGMa4aZ8iWcv
1OHx380Z2mzKBtAyVjpxK+jpIwSG7eH+Bi3ssN2X8mkSKOVBkK1J+zEOwbQZastLqhoyF6ffw/Np
YbtBm0/bHKWnU0e0xSlXx7N024u2/d27pad5YwinMePsoYopLq+3oxFxqcw+NZ7L0eXovFdLHUrh
9bEDIevhJTbvsFEW1YdIoBnF5oldeIL5gc//7fgBhPLkiP2FDofuFxKNJttGeMim/Q2xDcgyOxdu
t+xLqCAAZqZ6Y698hdOwXOyusVzAodcS7dNZt2/F6q0vtSo9jr4ZBfyFREv94ZEStvExMaTVfDPO
LMACmZ+Sm88llnKXaxAEeARIQDmY+a3PZNQtuusjWzs82IbJ/rKLz0SSW1KxOKe9oVOFK+XdFrEQ
ah9S4O6EJS3D+8cTMohAh8dz/iF96vTTNEzHQZM3BLcjSclXEfBO/7VLbm3XlxVnc6lLfBia0Bzv
H0eFv9Xt/iK6XJD12R2ViE2b40/Zp4Km6XziXDwKq5i+VM5zgFCXHfTlDCVsrIcfyO2y+YitlAUS
1MrBITHO46QaSL57ucQQAOUB9eZap7wDlJ5SMCYH5lVzH6uokMc6hTxezpPkdCIzLmgHmDwBI/H7
mjVgf7ieRqkeTLus0QD4FofZtE+zQmLEEzBV5L8L0NJd0xqq9xqoD4PUGRI3gLUeMoTX++/ntQlH
2BdmNlhRpavyUuMnVJ9eQLq5eGD6IZqXrVq1dRh6/8DXjWofKq9VpqgFT67ETWIR9RMCNixw+oG5
TycSpXFoJldg/E4LDVOH+3BoTIq6bXlGU7Q5QXLI69QygOCX65MgB7uEagzCl0ixsJf2vASjMoO8
Re04d7W6m0FGMrGTtRlDKOAxBOiR4eCQndnMys4r1KXcnw58MJNKCbq5jt1sajdw39SU7sQJDEYT
4pURxk43HMMbvuJqOSNm7a8BkJwhIGlN0S81K4pw+C3FrgUa4L1BNS802JhkyR4Fgsuy8yW61AhU
mZCq6BT0bRVoEVFyWnb/DPntZs+QzyNtV99GZDVMjDn3HXGXdgGu8ta1My+yiz6lX6Uj+iTuZil+
3X1EW1BPKzwxvdRTMOZmLMsdwcbeY9yy1Fv8MPEsXrxxsUPnD/yHRHNIArsXqPMGafA+1/mBM0cP
aK/Qi4KJvOrTUH2qXH/dBwqNFR2jYS+ql+Y6EKRspRbuAKZOwogje/7RbT/lfvJ0OGOm4/lyEdAw
3QA/jqSDysFQ43PpVI9hRDWCzGC8ZDG3AyoiSJs1PJ0CcqaIOlqNQdzMRz5/h1n0mirVY93x3dmy
eGVjYUh2owM8lhLcv/TVD7zLNaTIL578/z2+6KAKZVnELi8U/qQhevK86zE0tmbfUBmlua7+O8OE
tKkh22ueDgZXbwSTIUygEJdiRVoXrwnEAXGx9pcAdsRQ5BnIOkT7eEgFHg+jfEk6CFWQk5z2GygE
iX2X6ZLJZj/JrfFN7AtBs3tiySfmJlei7K75grRhA2dS3Vcjkzsy2Tqi7+nP690ZtHTseU/wqsit
LsyPqsXABShGtxl6jJjqeAz0hP3vEe/PEVdRLObyb5/sJXTQEzxwjRzkhoA9j2qt86y0Cjy7ms91
K3PQP8Q3yGC019LuIkpjTeaUCkOemeYgI2D7mkzu3C91LXMcCz/ph8UEQ/Rr/Y07XCp9c6D+6nzr
BhW2Ya8PjiJfuand0/Rp1aARGKNBrZOzqjE60cNSbTaI4iynMAz/8/dOkNa4J9zKw6ADs9RIRCpl
qpXjv5/jJRPFmjLUyqxuV1TMNuVw+iVQchWbXTGKid5mwkqQCyWwkNY9cWqvWB9OiLZvMU28XAhW
9iXjTrScskprD21DZ5Od+gKw/oc1Hkp+wpuDY0IX3okeh6jvvjRdrfhF/u0jYPxATdVo5zv0Qn+v
aqUU/V2wpLGOR0e3Noe3e91p28ZcRMTkX4tr0s/xh06u4K0OyatHKxy8Gx5UQxwhvz/5TEDmnv4K
cgDoeZ5xSIkDacMSbqrfsTGOo0ZXX+JHkUoXY56Y5+i+qii57OjbEggmzUETiMudHGlOif4Hh+Qo
7ZQeCkvU1jrYNo7gsAC5yG1N6hx24wrfSdl/q1h3rsC+L3IXftCMOLrK9BjxqG8Tvldgcc/4rkdq
N3rIc02dBIAI8XIl4qjpzp+ixF7YLJWaHgnQRe6No7wBqH8dd7MEqUwuWdUEK7hzevRx7hQk3JrM
Cs4YKqVYByNZcGdNHj4kNtUb+UhqZCBbYbpKsD7qlyf4FFavQeDzFfm/e62lh3bMKQVbhhgtgc/j
H6/tRqd3B/D7hYrqQ+1fee+EfcSYi6Um9QdlNTqJbt4WJaR+1DcxzLyyJkRPRcuQsbRRO5ySyjqe
e+ij5/iyPw8JGIYFCBXuX4pa3uFHP8RvRnvQcoyaU/WmkgCFX6HOSV+P0icWbaWDxIjDd9+zk+5F
vKH8XOE4vDQ/Btnq97Z8JQ3b23ks8GEcOjTQnk9bphZpGg41a5vrqglmMvjE/VmQE/04NcEivtVC
2JFoAcuwvuDzVUvmH0wMF7sjYWGxXEYyjMc6t7ogW/VfYQqZ2hZjU3Hgv/C6nUNVuKh0KGiHBie3
0Dal8Gqa/xuVbztfPtSyQPh6+EIcqqMbP0battah/sOot+Dc9BJKzmvnX6RPP8ZUqg6LkETJYW4X
xsXQ1QPprsqUlLyDhCYZxIjntCe8HvATXkwY1PKxkem57xLXk95404Oe6fUnnasQxVChH8QpikY/
zIje3bk5b9NL8+0vk00f0RYWMiQlh9m6tbDwvLt/KUj//X6k0npx3ZYtgnicDLpo4Ydo9IZeAIPa
FYd9kayffRXYX3ktM21XIB3BL04MWSUDZ9xMOv7TxHX7tUzkgRsT9Wfkk8+aokVG3gw3g88eN3KF
KizECvNEexGesT94fP7moo90RjXL1KuoCqAFVDsDm7fz0HV7kUyqnQjYxZmoysKmL0PV15SnI163
drbrcYC27cPiWmn9UjhkW/eyA8sCwL+FqpsfZ530a9Vjqey+TUy+gYXf/W8KsP7vDkVPmQghOYn7
Z7xAFFvWEBXVJRYW3z6aFcHNGhndPQU9EPrXYdVmYMYQO7dPbO6QMe4KnBFjTfUdHG5/FdjYrhsK
7J+S0WI/ouhorZ2qcKOBZXMaXL3QYMtEfWLeqxUiGWkxANhbbLoCp/ly01y2Ohfheip/jePdu8bI
jvxU1j3TQgxhlxLcpSC0g7yGelmtm9fw+aYjqO12UshEWqUC+609dyqQDHtAaQP2cxGkLk2dtOjw
tWjgHNpU2Mc3L7JyS+VbsjLAdeK9NHoqaK+VDfUoekWwcpF+EJw+R00mAi0ziGXZ5fSnOvsrH9q9
oum3h0lBCWkFiBwfW2iB0TL3Ve2ozJpGshg1ibz8EkEOhTpgOEVWZlC5qyrtNp/KDRkpshTOi1F/
G17OqRBQlCZp8PfrvqhIlbE27xaSO2R9hhb9Nn6D5XpBcrBh0w7DP2o2Ms4G9o1YxBb3FTjIcToG
KjcwIpDJHEd94SddsgnQ3pv4yNwueUD5mQf5RCG1Et5naWyLRuXioYzQG7G7e98zLRh78qvYB17i
5JPaBjotnQFXawu3ZXNJJSCvT+BuGVnLd41F6ypJY3swtZT7HqlxlCuqmhcwqgjv5Sti69x0TJ3I
nTtuYNXrnKf2G2nInPUUnfRvhTie+SMZOtriOcEW8GRVOMOK03xAiQKfNmNp62b4PUr4vuTB8O0W
chhsWo5s0zdb1FDgopNTzi9Or1el8f+KcZlemZMrjM+wDK6fPQ4D9n9vyR+cXWmGiWV1fSex84HC
RoTRCmg2KvBObO2yNIy8BXCmA0aOjtEYUm/zW8pza0MRE+VNo/gDPqQZUKrGdgKQ703FQxmDKu6O
pBJtOrSUi54r6wbZt/ip1mM28Ji7SBi4UgDdFXqJKqDajHYYZ7O5VRSOPOp4N9ss87St3Uscwb1G
wIWx75Tb7IsxPg28hGowyMXqQ+Nbfg5gUe0znQEpEhsDufacbQ6xB9U9mv2OhyEVjClulqTjr4p0
tOPkYMxYP8QbruOPvGwRdssLzFergS9FT5u4TZsGkv71H8awtp5b2iskPaRfu2GXtHrA3gExomgF
8EGiJikPxFwE5BlvYOPS09dDKKndM1bDlsFPFPZgWWCVMVSWvnKUOryAZPEOEAimbTLRv63Zq/eV
+uTLxjuhh95hw/87pF5ktZDRvmXxnV82NRCPBru3RuuX97kuuf8ORxoi3qJUpKOJqrKrKvodqdK9
SJWdROwyofeSCANZJnn6jwcaTj2sict8cAort4glqYnci0iL/Iko2cOekIB46QG9MO5U+ViF3LUN
+qwMDr1c8ofjkzIPCKOhvG7J6tbn2w6e6zWoPgkpgbiR0mCnHdr5f3MVSkZl149NJcBPXR94Dlzn
qPJcnYgvOljzvGu9eL+mWNdgKvvDSBHfm21CaOs77NQHoMvDy25la8QZb6SvPuge4wOUJof/avjt
p+5q42h2KKWZ+xNZzvoeeiP2cKLa2zPu3X8fljS9vRYnk+Dlc2+9nWXLtHRO6z7nwBWYyTDo2HuJ
AUtE0czBZa/U6XyfCa0QNItJr0RQo9Pl8niA67SO3nDJAxorxOGSS0H00dxwNgghtF3kuNepQRLr
u2QES8pj7oGj6naUG4Aer1+qqZn1vl325ABbR3H23SrTJqVdsEmUftjD7dw9wRtUmGrkxuCQV3lr
xEVZ5YF9mSX5N6Y42Gxx8abD782sKJX1MI8BA/n/Qgqf5NG1U2dRtp0jXNDnF9oegL8rREj+/QFM
IHRFpflSJi/+7PxKNDygpBj5623sQ20HBSgV5By9bcWc/al+V++kmbLzNnVP1DXL+ZSzajI6uOOg
UJHrcl57gyGiRl9CjnnjsGSzYXhwash7UaYscNihXJNXHWEXwcrte8A4+/epI7axPYmyuZRKdZyB
ToryVOMl12bTC7g0Z4lNqXubLy1VVY2FSGZQb41x0DIGCvJFn+5448h4peu2HKeZLkW1xqAtv5a3
ss9KKOlKNXVlqhJgNvBQObWoP9n5al+Yf+Sy6I3eD9r4pmIQ6jIJef7hfn5aspUUMXKB2qpv8AAl
iljV9za4jdFf8qk8Np7c+7xzVkjBne3DyUxIJU/F+lWqBgC4HUCRQpE/ZgxtY93YckDneacXf0+Q
oRGhhJ5mvLs6my3IeE0Xu3xbP2yc9v4yJb0SzCVtZvpfFiSQ+8w/wa+VRHiQdqMax0F124AoDheD
6KMzLedVG89Zu1N4vGkYRXd/RRY47uy2NHnPshjKYGweqOlj/42CspPJBkrKLVGq8wRJOTny6a6t
ozVLcnZQYlsjrsisyjbtjdc7muiJdRRHXAn/P8/thyWaE2JyNL4+JDtLuLz9twTdK+8lUfaQqbkD
IJ4uy7wrGSJ8th2iYSmU37LQiApkQRPBlCpC+evYwdZIYXSuWP3spuw++3FhQNKkbLjimr3xxiOU
RcsfcCdy4j1jdzCMpuOAtNyDdcULlpzNDhxuokQQ7OWVjTIsKBedFDiFOEvCtOsJ39NgI2Yyk4m9
cTpUH8+bYnm1VK3bbI6YXsavBfNGbydDWR+afD/oJ2KpcydZzHIhuB1ZtfnCmYVimif5GYF/wU5c
3cZOzovmD6S+TmsQVjO6ujygrh4kWqfyKeGsSP5DPiFMdR7yOVorpMDXtWue+tNbKqxGfxTVWjif
LXdc8a/vXbBx1R57NgQhFNQCvpzI7iUCUBkQ7RjKVypXY0CYMvNkvLXC3yEZYD8djl6yAIBTPTzM
QxFnjg3Hu5/iknQzNmUH6V6vfDPq0yAdAoA0tUQ9CwfLWiKoO5vlIexoAnVrLE1W3uqaVhxOznsJ
mN/NPENsCAcwSir1+xsFtignMwL094Q8JDKZhqMdtSPN5fw0nGMUfPbbuVe9P/RQYb2T54Kmdsr+
t6uNUVAeruahxOt7+GlLKQ37rFc0CMDqblFtxBbXmfgWRFQy41CR5Ha5nmIAeOO3Xt5bUHf0usuZ
0Dx3ySmQtVlup4Qj5Gd2/iIrs8Y1272nx//thjTSTyzTFOMDfrmp1Fis31WDXGJswJDnja82xp+R
Zrb4AwR3d7rtf+ztuSFqv7Uusi3bFQFBUzbq8hvGhfAmt/CqZ+e+JIy/nswDn9zjblIkb57NSd4s
1zVxI+WR8ZIPFIDePaH9BW2WfdhdoCOywwPwifqlYDmltb0miaKkwciYBUmFmMVuoACHEPRg25q9
suGm7wsNH9Faa580X2K51wcGC+5VHpnaRkMiS7+C1v4P+9RZ5/u0JQ2QXepLQaFBoUTokQ7jYSzm
EYdAocw0Ek4d865UjKfN5IVgEAMSxZKvgfzYGS2rE5FoUbF03HIlKNs1bkTpOxiwWPFzXgKE+rNN
EjecFs2SL+sLkqhpVx6tof0Zk70DDUsLYRYhOOUBmp7B6i+7c5JEfBC3Uw1CAJhbuDew8WEnyo+a
Z+xVJ2crIDLeTMnBxbpyjMSAajkzIXs4C7I+gxEvrVgDTdr/4NgSuIuuRttyVz0tiQrYqq7CKnF+
V4RJuzCEd0fpkYnPGT4TsvFUate1tQieya15Uhy7Ndggv0+a+9A9+dJRcuFAtknw0QzbZ42J9ENc
j8jP+rCvlM3L3lViAMrEvP2Sx+dGm1+hDuak8H3QekmEPVxiua1TmN6oHHRkZZpT94ZmUEPQvuOi
jYMTcK9AN/hczERLi4O7wJJ2suxfHjA+xZupp/KCr4flDwkl8xctMfDxTyOrWo2FsaoZmTnAim6t
Kux+ZPe9kMpiGB07ugiatiFYmpbhY9UkRj3WrO2FLzawdqEPVuUQ8HeIzJqfMcMNtipWec2m0pF5
7CkxFze4K0TdPmUYPZZAZHbvpnIHv4YWWezlOTdWSwUaB7jIwGdSziGMuMyee7ud8PhB/316lw6T
4g7srLN8TZgRH7wstX6iBnj37/gzCGAcQOfba8Wl5JSzW1vnfKQBIRcnjfehTwkNqV3NRUezRike
upCqwTOXe4IMVcPGZ/pkmF8kT87iEQwGmw/ANiewLNQS+iCQ75/hpZjqchrmVtsJUsYpyfNbn6Q4
GXYOsFY+zIJGjghUeGkE0wyjTI7/bnvY9ztuUkbA/zlfB/tDkj3d1Dn6elRni5Ur5zBiNU5NQzZo
DBhZzcmspfC5vPZiOP6w+FEdZuE+P9EMIN/bVwjixQmsux+7zpbJLp3rrco6V3GmaqKmmQb6FTU/
uJ2bwWNrXiXg4tycb0BqsPVYqYNWRST2esqC2G5CglIcAjsxtDxrKBFbNBmUJwsey1u+75y37WAD
axB6d9qkpyWlxfIfymIVai/3SZp4IxDg4V017XMOnO3/2+KMNIYyIuPq+4sa/OuC5qvbiHt8Jnns
YoTtXUAwZVPAe6otz2wfnkGPuKSDydgVLgiSYVvNS3tjPC5yUdL9L1tfmbXx/z+HHjAlI209l7mc
fKbsOfTW1/p+A3cSuGz3I/9GoaYudIh2aqM0+NuVOSLxuC9xz/NamUxA579RpNIsmh2Q7cj3A8eH
6Cv173Np8vr/xwrDmJeGHYxQyyVVMeTstLjc2a2X5PuaN2Q86d/Napd0+7qalgQiDaFHBWvvOvjd
FBL84ghRMAC8cQ/pjW2Hk/yLMEqKIuOTgLLDYH9T07OM8fRViYroM9suKnyXZtfcsQ6hLg4rxOpG
c64zIsF6SVE1F637UFDgs7B1wx8vjyd2KD221+aW0K6J2vlcmFjDCalWoOEd/C37HaNBogf7ONJc
EpE7725YvIW9gAjgowz4QFBclcdthxiEvBPL1tsndEtTzpRWHuK0DIxgojTcugILZKGwZ8ErcvxR
c+4lK4QBB+f3HQCHh8gB4EiC4eZ0VHmqZFBTqhhjSJAszr+wDIqy777mGdyR9yF0SBfoEzyqpvLk
hFZJsaxYwjHTxg4Q3q4i3J58IpfEEIU/rapwNqej7oDVFE96mUFH/wxGMXEhG46BCqQSqkC8ncJn
vKBw3jRH341RMx1YCPpalg53OmXGS86kLkekWlnH5Q7qElwTZmZxO4DbyHDe8UVRHKFENr8Q02f1
+yxaU2Y0D7CxOBmEvv6pn3+cvSUV6QH/+cc3PAYPHDChAXrOB8NG+5VMJTgpxAepXvISHqWVSpyC
ZFWMqwkLCCCwZ1NRh1M7CIh3C691fOh2rmADGnv4d4hC4D89e25gmxbJbdLjdKUrucOkQwSaKkvp
htfwB1GzqIOi45ugjrFXqxGFP+C85CP4m7T2JQXCIxyDnfPfgD5iET5GcxubfZl+CMjF79U7UWLs
XTFJJK6bRP4kUiz82rOaQ97tx+EkZ7c3yRJwRuUQt3KRtDVpdHIiUmNf70w2Xe+4WivoY3HCb9Hj
2C8qyXbiJCmFGl/KJET1MA39FGTmD8Cc0ZWS2wmAnQf2aGX+kfdIuwmv2hRSbolpa3IR9qmeJbRo
+MeWhST+KKEiGOAEUH7SlI2qcHIiabOZ2BfCiaOiLIaj0vdQofjnOwDN15WKghc5ZYKJJWEWEloo
SvWaXDPyV8/ls4ZjtCesvgWdQrrd1Erla+UtGNMxN4px8Kf6MHGd0wFxT+aSlJuJ+TqaMogvgN6W
qD2Fnr+gTsRTOBph95Mp6bq+HmGDgSPlCp4uqUyQGRgMeWUFKWFJz3ASi4KHnCdZo4HvfCYvICU1
qOGy1oRMjbONt0P4B3tz4qzv1NDCJZdcEyViyADNwuzx/gmSPBMvGaYypT36Ltn7OwQ8UGqBw4r8
BmYfugDUkhLvJOT+YpxJkCI4fshvtDfPrXZWah/bZ09ZKwk7/noYZHz6t9qH9jzNEKHcXrQZhWjr
Za65UuEPWVq2EOaefzfBCgx1BDGEnqxeIW+BDG1lJId7Hmejhzg1djoRbNTGPMoVd9tNQIPMf8hs
BYW09n4m0fpJiJtqbLahTU7d9i9fVOwfzkWG2sWByaln/iZUxRM6kE+ZInzJQQ6bRcdLEuRekgIG
82j+GiI+05crFPCUL3D8w7eTE/o+jaRZGILsdXQhJD50V659SwjYLAK/ELmG8AUrlJFXv+Jc8jT4
Cofxa+vssajZhK7rkI2orAn45sC9widaCnQXiA2NMLs97+9G8obkaVPGf1BTXTJTz1MKj7cKy/ZR
pp64Q796yFTILzHPZZWE5K65nnOusIoCJydmlHbSjVBwQzng9BqQyElylM5ZbunmI+g1FkdG6HHK
iva6VjQ094aXPHg4aIaeWJcMihlbgvrS/HoXfpBdx4dDtDUaIDKNjJFABk3kPsTK3sQT0wBWQiPe
zT9xrvTj56vR++XTX+/Vne6MBZ2qnEb8yfnFgNPJz3DKnL8PFv1Enp/4N5OodRwi53HJhDVHKQk7
fOzPO9f0D8oZ/CcCGR01zGY2jdnF4hrVuPTM0soFgKj2xRU6kbOR9vnAYZMnt6XqNi1mht0WmK/Q
4fDf6hb7DXpxK1tXb5lVusIGR5Wu2dsBP6RfsuboLiUxEY7Ijj/qeMDS1HJ68PX6bAalfIDf1I3l
Mi4GtLio+kWMfBJdsgi9qhNf+MJ2dbHf7YEP2MJtGDbB2hc+HAyQTiT4tmyXUsiY+O6d49Qdawfu
4C+PhMa+8F2ATbPRjT+QJidOPlPA8skVC+iTw93zlxjhmRdWq3P1bsOOG7SCaB6xr1pQHFsh+kxG
sh39ZHtv1PWq/TTE5ZLgR5Cn/IyyUg8Oia5zrRg3Ls1gyVkEy4XNtcxAnI+9yIJms4uYtPNJLq91
0M6QOsFY9VpfFNRNL81mLMxxu8zu++khgo/HybVEyZFCemNRjYdIIID2ExRhbPQygo8zxrWQQxUf
llghxUzFNXDgqBg1AWlZYJPgd595scPN9gsYAfWMP3Tv3HT6efRxnQOgXRMCBJQSOWgTMmQDfGis
uKx1Sm52JSaInVbO6g0D08DF/mTKveARgGSBWQqcJCon0cNWpXiiJAzNrytH3N6hMHlLPYs+KrXn
2pCzXd1HWdhNzxsJgn/u+P35zdqF4SNSOgY8uDLB1p0BBFFbollbC6vKhjewd8FNYp0zz3KghyvI
v7Wvp7o8OpWvHGCcgPz7Y7bjCQC1xXbJcwGLBgPraL1+o8/rKeOfGISm44dn5UgrcGhpTh5Agukl
+Xv5ahJvcmFNss2kkiKoKtEjOUAAPyab25OuqTlzrRb8lVVmOrv1fkZM2tmf7J2pKSgRDMR10BKx
PH+HcCW1zwZTeLLTBZNh2x4zAxiBhKpjF1Ue2IAz/1N3jccK341k3sA59UwonWyHxxm1r4FaTZ4N
TC+RZ+NYNqsoJ8I0NOvJSDhapfySzDPOXOfrut9eLxQr7BJi407oSW6WQHdSMUZYw+1fz0a3YcbW
1tVcfznBNcQOKzxRAkL8l+3u+u8GxedplaftEu6j2gScUcJ3rIS/8ioyCa5Eyp8wk8SMitFUgG+K
O5ac6JbW4ZhDw0prx1wAQm8nnk2uo6yyLvpZvJhdcpApxZ4OzFwUy+3yuRpjtWAEhE4R+WUysljY
Y81XIjni1T2h/m7cBGPRETyIW6v0YIkoHAOWQyH+gX53GutrMKRVBpe8qkUfod0chhAhLFY5rCbL
zpcdcCqGm4+bvJUROvZwOYH2GB2Zua/R5cwpwHgg8V/h35p6Ez5MOL1vu/zo5iNyHNIUMhDLYNNZ
D/6FXq6D3E71md+zd86xjg6Zl+DnjLF3AjJ3LSgZWHU7WeOXNQ5pI2ylVel6yXM0+2Jf8HjCpyzH
UAvItmstM9kIn3Iyv8Aav1Izl9hUakYoz33ssu9kRgLhYD8B40Zh0WeoKuOr9hwXrZjaqD5k3PnO
frTPjSZcwlYtPLFoo0O1L3afdydoAQXXiIjGNL3mXWIdoc74FgPjHxRlU20dGny+li1OpDTDcN7R
5X5IRlXDXChY/v/gaqDl7Jb3JNZLaXVCxWkEMZiUel7MX88JX0ebgrXeKMx8cwXaH4K2dJYGnci9
SIvX9zy3C+kKC43jbN/dGVNIS0Rgx12n+kP50P1ZebvJRsA+0pzY7aDU/wngXLka187tgLz1peFx
n2HzAmBoBOUixPPX1tXrsRGzCh0UBHiszoUgDrCyv7FZfRmvERpm9F8NVA0nQQ6U0yZlbVjtDpFr
UrwaBEEhDkoxp0iaRWLhm+l2YtOUnJF6TFoYgnXGJo2EQ5ZN/6YF1+j0+C5tSqdwr5jP8juLuaju
RZTTD+Ghb5QMqHF5e+PwMosWU/YCdrGbqsniRANtMMX0Yq54mU/xuV6zRZ9/prqp177t6ULdZrhz
o/rF/9Vj3I8qWGeszjpxkYt5/9me2WoXPVqIFplTKeuTuUjF6/NUwwevbNO4nO8wGvJwdxCvt9YL
qVQ5moCQwePTKjpPc7hMGfNr/smKMKMGpExQyNfx7c7kxyuLzJqJ8r5B4+MdIZFDa+WYq7rzeEat
ooEBru2QYyQ13nRYwdyQ5gjYFceMvPldvTiof/S3sA2ZhOH1o0+ijZ0VFMkqv8Dpv9uMCRlmvrtc
RN73kGQKDhERQ9Wose08xUXyTWcniPYXQF2j3/kidCjU//XRr4F5yUB/JsHoRXjtAeIukaYZ2MSD
WKaEeR7vMByBu7KqPSN7ShftwQlN4iDJ1IioOfNhHck7WJ5+1YyBWrMfIHMcZAMFqNJ4KWmtsyo+
/Mu7pF7HSaaUl5gbF0sWwrtDcz9m+THhxPV8ndAsOkUKdxYk53QsJSBlzjgvzEMaanTFIIUmGKAX
zv+4LnqYxMamzxGm1EwpKiWx5m0KFiql9MAIqUW2cwrGxM0A6HKq0ljktAMxR6DBAJ7N4lxDZU2v
mMD24M5Orh4SzpKHB/zJY1+gj0V+9ViLiZQ0eFdqUjIYgFL2QYP4zWRxwMdFHaaPdC/rEnZ+Zu3N
xZ9CKVZj/F4393UYhZIaMA5WKNtCbVLZGLGezOuW/DjhstsBPBCbTIQDRD3cars1zT4II086xPEA
/b6Znm43E55M1lYmIVpwjZbXNX900OBSewRgJHw2KwhWGCc9O6S4foG3J4R+laIliRbRtbYs9Hla
5n5MFeEInmlRef0YdjYRAX3pb8Xll/uPDA1SPdGa+5TkQB1O3es9lHyQvFp1xxechHRnFiYMc8Fq
kuaKe2Vl8cEhf2Y+FVNcDLVQuQRA0T26RM2+Bj+0kZa3b7uDHGGZIeWeqGZ2wL8w21Kl1t/QwKYx
7xBJcNv7uiwXecL8V3fpB4a6gB7U8FzmDr8n+f+hySseuGZjN+UdacBbULFz14+GfZWJg358ra0e
MTxRFHqO47GdaKNbWeLJiaHFL7gUPa++XhZg1N/I+5kwKia5Chx8SpULqdrneMunXUnYkGBJbyyS
510vG59tINajjetMYONUeUaM0l5EcqJZS7QnolOEr/Z3665fJgNcheHwuOGWFpAHu6RGySQe5kI1
pBFvSUy5gDKNop4Atnrdp5iPzsLteyN3m+LhwBwBtlXVywCXlcdvPNtrSUsHASzZ2HQ/oYP1dDyw
4a+tVvJMvP/lU8xUy27o+UZKqBBKUciEARhQTmwJkYLYOKVMGyEZWiFgSgAl5Cawe1LCYcFS5Bvf
zzFPDEnAhN8OKqTl4Ce+mwNd88M2xYJ7HDGvcN8jJwcs7Wn8HA0BZGMwiDjYu1zDNYT+Wi1QMJk4
S/2soYHQpr6rHsEVhw1zehNSZOUTJ0KX0WCPPQduLjYVhu4HSrRAayy/3zBxAKaTlALkEuVyc0Jn
H6Md2Btu86HKhiEZC8hA/Iw1+efF68wfNXxNtSjGr5A1BxbAbfKLtkEqhdpJp7JZKDdzW/cTFgHf
YL/RixtC9A95ds/NSb4W5MchOZOC3fq6rQegcMKSJhQyktrmHliJnGo/h5ymX0cqlcH3gAmeJn9j
+iW2das/6M6UVlfiLSHXkAfQlFLOda7lcjjVQDYiLp/GQuvxK/8kRZWZsjLc4mX7yQpNxgW1d1Ni
7atDIuEj/GzI4ywnXEzh40UgNJzyLbstxsh8WMAo7s1CdPJFIGbOUiAwng+az15neFyklhkI0dqK
18lQRksOFwo+mmR2yXyJ3vWMcuiRP1P4H4FWw/K6YoW+oLMEU1+tG95GXQwAw35E2Vxt4Gp8Yf2w
P/To76KmEz/PJ8lw7/b9faccJ0AxW6jiaCN7ru924a5AG+pc0dJS9RGFW4U86NHhygw3+PmzG9/Q
Sf/2oIt8Ck3YerZH7t07wgF2apEudJuE9jokB0Kac6EMh7+Nrftd250oYHJ9BhIOwKhxWXV/KF83
NTsLIYODtGZ97TT4H3bUjz+N4DkWILZNNZraciD+5blEKRnEVaKL+JXwfYn0nH+3Rhs125OXHXwE
axupWV4H2eAzFpP5jCVIQgjkY/NeRJ/E7D9AePk1thjf2EhUpzgfaj95klPTjIxLBE7AtucQ8q3W
RBGWcDbhOVnN2/QS2q3nx6VWVr5//hf3hKAWJOLuRHr7s/n1Id7T2Hd4jW0mtV0r+vggdsTnKKQE
ZFkA5WPB/JUpvx2fwCEVuj65+E1BMMqKcrHgA7WsJ8YxKAXaw7vBubin093JbcM2VcAjLiLbB/AH
cHOZgM4Pp5dhLgiAfNtDUqlqZvwdHVlOv+Kibp+RTH2rR0VgRvoMl3+1qU5hFdU94Ul58Hd1BKH+
vEcTcYeIagcwarWEVpqjbYWSb70je5cIoJzIjKHDHrwFH/rJ+z1AlyEbCoJtQnRBUJ3fJPOqkoYp
Hwbn+gVMObhgedoHfwgUjIuCusHG+v7INaIhJvG8e3N2LvD688F1nnMEbOcwiZk1lpnFCwP2HiLa
3/saFfYhSlYMTf9liX7Df7/f4JbYo7rvlSXk7Su5a2qYX5js9pF8+ozWwWWxOzuvptcO4p/+fIfc
J3FibVbXyKIln3Tcv0qkSNNuDamqT+1hgvxTtAsZCUUSkJ8ETd4KdMetk3vkilWE0u9qJiqe1oHD
/Pxzpg5gMgw97UjpCpm+0zbpXoEqFUIfbb24FB4oDcvt8bU7Cczyud+okuqN9OW7O7+zSQuUARDj
bzTfl+bYrMFGWrRgqQtsN3hDOZOFOmZU2iqtEtUMIHhOmqJbmI8usq0Gsd8OIbzeVh6W/L5bhBFT
719x7OsE4IbX5l5q5L3k5m5DghtmSVeTVQx9igyBHEdhpLo6E7jW6hV9O43+JOcDlTzCHIH/IPN6
W4+SVBuLN3+YWC8pi/zqWUxWZEmst0CkfKBheGm3dpPhSMEM0R/5LTiN8CNjzaqLs01oj3fFw8O5
Wd4Gser38nX4FTxcB/3F+wNt3DV045eXp6pRtHkFckAF89+cs4pEToe5GsX9vBNg5LZbU9MWNe23
dexwaVvNYTGG6dJfIjJ3kL/hqR3dTktuW81Q9UM3l14oLojoq9bvCZFfLACzHBi151gRTXht6llG
GMgxgtqm712ulYzovzfo2qT3y6I/Qbr4R6Z+KemQKEtFNstrxouILM5KUK+U6C1+q8iHFmU4hD+D
9BYGwrTcfmRUFNdQz6Pi46905FP7tQ+zcaaZ3/jh+qdsfvN66Mx6PaAXTvOYgqFfa1fZdERfza6O
y8hVWJ4QhcjsMGPPKN/6NW95D9JC3as+BB/KtELmkJpPoHkyBLg71iqHBYVSAjjmJutkMk1LpOuZ
1j3Zh8ourlMURV2Fsxl4o2lu+2/W/I9SIN3Ene3GESJev5red4GUFiGYyigTJzSoKH4Gy4Ui5Avq
DuhZZRRsnaT0gRFh9L7AhHZHOy+vQQys4ChFUww6t3Ed/Mx6P30FNYZhuBzpWKwrU2GK+LBZH7aq
EpFpv7zztoZyeOf64yvfvtglLEB6/7Cw0/RxcdKf/JA2SErfSRnssPOlyy1QKUEv03fPEZlOKWky
Ogyuppbb1AiTpL4eKYGRwW5iPfpQo/4gL76OakjVtHUSFZ3BUPz+QE6oTFgwHim5Ji/D54c91VZl
7Xis6oJmhqXvnbrOKJ9TQNEFPcZzBwQarhkHWs8EHV4swM1OAL3PtXuT/ftUTsuohwDVyo0RdC5E
C9yxa/Tr1f9yn3+t6Iqw/r6Rumcnr4iP8bIMF8EvMjQI/4OTSshaIqrnidQHK5yJXC77Mru6WUQu
ovDu4S0GWXfAGmaH5kkQYklhBq4oxz4BUJo9yyUq12B7LJn7x75R/iZEViif3EAAzp3W9ZYz8KUW
0KTeNtY+hNBkB6EupMOZPxOCJ1+PEoT3Rv/ZCXJ78JtFnGcaGZjezqx1BBYxtTqjloe12rb8/GiB
QaPV/q57lX7yLwEmtEDv2D/qXpnYNbB8sCbYZKNhO+JWyPZ4ueMw+vd8tj1Zf4+5+a98LMgK4ttA
YM/hxN8jovf58RYKA20iE/n2SMugb958GadUucAuW0j01EPXSdfauuDyDU3v4YFIup6CZGX7VtU+
BpMrymX6va4JRXAz+3SD8n3qCN78yJ2dmC8rXyzk7w2ypcDJkqCBEs7tJ68nkUNmkRQbf9FOOFjj
QCuDs85cbadTbpk0lykECzCoolvPAXODmGQwzTNSK9Pn+DUmcvoYXk/JJb+0iFkmNW/1kwASbUOI
8CkoREZYzJbRPmuHt7iDpt82GXo+x9P/5mXZdzE1VMPiG3G2sspVJ/Tzc5P6oL9Nd9OoSpI4JU/J
HENMIaUWcjV/+DNzoIeNXUtvzpvCioLK8rGx7XQ6kY5Q3D+u2PGPvNSNeWmp/IMdZUG7/vRXU9b0
Kr0e05zHAEkS7pGLp0hxJD/n47sBaPbRa/vQdchOv34I01Mj2lolJLSM9xxUscfFWGBnwBLhiEB5
3tQYKQNuXPCvB0qAYDYUf2SJUhbQBrZR5LRd5nrFUcHv6RQzvQ+h1/29W/DdIG8WXbu2RhMmCORX
VebBZLp1uM3xppJOUxY1+husG2v6RRrRgVxNy5jA0SI3XtxaYtEyk1OjB7yU6kDp+ubQO6FXpZYF
Dw1GFSclFGkyHhN2vhXKK1vVBZX7ZQhFUS6yn4Hy4RYMMQ2FIEaFm8L7G6OdkebIWKQfCf0S/Saz
AatlCsKnmvvC/m2nNeVgEFZ8Agw8f4C+s/UfxBE2ublBlzZdDvrRZAZXnc+39n/Jcry4n7THAKeN
rcLWdPUQWwi+zeSwIW0uruUYWg3e/dQn/3DmBAfqjp43s+I+Ms0SINlcl8T230H/nzqdNqbuIx9q
6tCMeinNvhwz0SzWlZ/1GbVF7nz8VKz187fzbHKO9OZYISWjWg+uJS/ON/KtqFr1EB+l89+XUpC7
RIWUXjCRe2Z53mqUI8DVHRCmKRcnbdZaVTz3rehfZgaJd+Zx7HFFh9FCdFpzAFZ2wvCcZvciDDFF
ExNWoD4fcArcgGr5XQsBwE/O9jaZc225/4Rj5L4c+V434Ptp8dwvoQI1t8ucotg+Ue8dG2t1ivjk
Gj8LRong3r0K9GsJ0KWlRQXvvPkYgQPkfr7PVVHyamH+0wP+dxKKiJ/vcQ/Lo16dgQRenZ4St+8Y
qbKlQ4XJJQ6pEs4XwuZV6sSFBw6hWSQbXdmmt/E0QpZs+50DuOQuHGP3q//kK1ipAESlMvcm9VRa
hkCqXuRF47RgD/Yl+pfP5u2qqXK/ufJK1zsgs7W5dBmJIj4G5SsC++f9VXglTH8R33LH29nFhMXJ
FZCjeOW97jcf9Jvad4CujX1sOBLFTcAl8fcKdvvA45x3Fcl228i5ViAoueDIg7+WA7kGbr1vYDD/
JGlqq9u5KTIqxrJV+JiCI6WUdor4ix/sSmB8d0OZ0XILxfeFvB7TgpLlSa5wd33AwHK6NDkdJJ5Z
hLYsh9USn1X4is/fI8zC9FJhPjgicqgHiVIYtpAMKp2/FzTxKfzf8yjAjlofnQh2uExJ552EzlId
kVN8jwbPjAYjzO4g18H9XA5IuRA9Xn66z8/9ltzKbh7eAQ71a29H5Yb6rdtYmcpXj3D+C8mykqfH
TXVmmJcez+UlFZHmDsEXdRto4YYlovg/HN76RZ5AXYn/AbTV14OCtNohrTpA+u8d6nPvt8R/lwgn
zEcTCrNLj3jaejMkIz/0dUdsDC5txVDR/B9ZSU6f35kZbQvPb5aGj57n6zKljiJAJS8aQOwMokwl
YONnGVjY5wZHkCz4lExscRsaxXb6V1a88z5tPehvICb5ZI5afG7v01CfUEbZbWYfvyVbm+nPaba4
8aae6w67/VS5x6QcCOOcXfb7X44pV9tesIpF8PpNYSBq9gkPBjV6O/JzF7kwaDu8jic9Bi640hw2
W+HDKaHIOO2kdQEJMCvtbtVow/Sj6+Yw6QH2NypokJlSveRP94eNy3UGrQB/5bzGh6j0pdqll2oK
v85sQFHg2z8098vZNXjj7u1Xa+Et3D73Dh2fmukARVaozMdSjjdZNzWtIAdXrQyGlWj1Iv+KVrJm
UeAPefeXqmpjyldezmDzCknnqIkd32hANHybefoAmRpnz0SNZb8sjEMiJQ5MmWEfuyKAv5vjJ6BW
hTqVGM1W7Tf3orEWDlz/LsnEUAfbl79En2nABb66yUC7OxqunlEy5YR5tXCDB3Y1oVJYvBKRVtXT
29HgVPgKGaQHeu/GUEx6780ZDn+IgqUO2DRApt9hlhtwUFxr5BVWp9dEg4RC7DdlZ9/qQKJUHBXT
zoz/4jUqBg7GU92uHskdr6AzF7A6N34BXsHlSYcI8Hcbv9y8sITDC1wzyrZNmHYPVPYSkiGVx75B
POO+hY5yClHqTvS5KPydL1D1SbUf9n22xUmFBVj9SqRyEko4cBJtusH07moEt2gni6GZjToz548B
9E3FAePFXDEucH1ztj5iavgTTFkxVm/GsmAKTrt6JjmFy/Y4A+1m/QGbQEFHe9NrHFSIeI/pDcod
9sKddYervpH7TjNGfY5LgozZA8hkSIes2Axcwpk6/l0uew3qH9Dg85eQNirJ0siFTvw2aOBQb664
DIUjwe9eZ8ewj1bQrMA2wZo6/i9N5rPd6EGOWiVdy0/2nyB/6A0v0221cxgHZTZb1WtSb1Q6+LKr
qGH+SmUhO4a8q4PVIyFcsxtaHMEyhciqXw3DXkKSAL78SA4nXHyaGTgzEwXaeGjE3wfxKkYM5lg4
04NZFYC6+LuWJaejWaU8OX4CamOzFYDclA/4HkudtbhF6e+j2qB/Q3hMBfYFTYRot8SqAlJUhlpU
MMRGYXJ4fS4QdTt+sPkByGBnps3AlfbgGfaLhCjCVowU18J5rLPoJ77dIPri2i7pGw21P/1afX0T
0Hfy+zOcYiw+P+U5LhsaNq/klpY7VkhmdOVzwW2Lf4w2bIslewUGMX2S5oDCMLOVf3E3ta83VqSm
OkJ1KaXNS0IzhvuM2Jg9b9T4XFmltAc2pIe66y9u9fQwlmFOPuVJGllunoS75eKU6idJZzP9Yf1v
5cDKeolaPc5l43W1lvyBeJFt+vuh8ZDiOfM3Y7FgI9Fgz3JKAW/6dCwfic/CaJJupA/5ZVAQYUig
0wnWxzQKbsSYJK3SqikkZorzUJtSMJTwPq+leuflNnaX8GNfVH4iy3p/XtZxY8u10OQMVrAx6Y1c
PwB639Zmod0rCA5HQ1Vu24qCo7GRXl2wZk+kBKJJbhHuC+aBC1HgBMHCXNhhTRm6ClKb2DonLmXN
RiZMVQtINvWjQSzbEpdEXHZNx++koT6PCmQMxg6Q2m2i1qczH9nvqQb06Xoj61q6Ir0n2ZMrK+TX
asELDgizuWYxL0jWWY/lgk6p/auQU6NVYeTImOuLSLl5ngwHDkxVJhsJforgKoLIb2RNHRLWoKzZ
MaOh5ymMvhhqGdZwI3/idwfXm0LfA6sCnbprq1boDTnLh0YkQHKJQG4XbpZhPlYX330fGRMM7MST
vpI2hq5512Ex94+dP47stecLtck2xcL+UnbvlZB4PfSWV1wZM4sircfnC2mA8SHKaKCodmmF7vuw
lRAVWZKKeOrqDUiCZtyKW7HiachBfgrle39HTttU47MM911DWylEXjIEsLFZLYN9e5BPKwtnMJ40
dinAFpuRnJJW/JgbYeGezRJpkwTcpbMF3PQe3rhxfikOwHZgq6s2SdNevQ82LVYIBe6Quc6UGTLW
fyriwdeyV305mg+v54IIXP3w1FT2waDVVm3hUrtzPZDKSo4dHp2wozvyTnH2cw1gXz5pOvS4V/0y
kfJxHc8vV/h8mRzcIoMrUR9g0nF7ZXLreyz1qW8S8qeNLnrBKXvmQ8Q3MVwPuDYGGKyobz76S0Wp
EK+oFwAgXOVnNR3Tn9ArL2UxEXmEihYlMAe2Xmu/bTQEzTqTvrEeFWOirAduZmj9AA+fPe+7jL2n
MMsrnntW0NsxFPRAAmM6JTiIJ72YDoZ2pLgIF27IDmV7UEOu2qI07H+P4BkIs6JpkShxw5L1/NFo
4aTyV8/JWU6yzt1tIIuSpTktTT7zMyMF319gMJVXbOZ6zYCkR6gvxVXlU8SBsWhLmPJ+b3FprKnJ
RPUfySikOQ91ohb2L2Z4KorlkrO/+c1fgJ2hiBpAJl/xTTtS8jdY4yBZn2DxXePLVgMA4ZgTqV5y
n1VGPZZ9pakQu7O52Gy57vZb/MCgE/4j+dao/wa4OhqyNWFQN/0ZTGQMtBNkcBT+uzY2c5IHG8q1
jQlr0bbUnyGzwGsCdICMUYJ659hOP5MHKGFpTCKVyJtkiUG08v4tTWGdfFwoZhLyL0Y44EbBCkoK
6JjsCQeO8DiPaNkiN80a7g6hBHhuLbTPIC3xGW6zNIyCrDpJsY1tS7kVkDXeH56zBb234RAQwSK6
Yq2vzw/DsLAcXtRn4HuSExQsFHCB285P/EFPJXHlylYleVPNQuLlQ9WQICedx7UUTvF7zphHsgAG
Knd5fdYrWVj7V3FfyKcYV3loblIRpfThBgcX6qz31Vdwr5L8MteJmwHMjlO5NAj/hz3e25HcAnRA
j5eXP9BJxdYZfQ9FYdIVoagwMgu53xjpn5neg9i3MMiTVMXmAVwdvPJPKiGBGSE8HDIXUwLXGRx/
yI24FBj1rkMxOgv9WzNV8JMWKmilNLekaij0cB+wvhKIcD9nEr4sfNTZzRoHaSgi5sLlrJvLYWlb
9X1+GHEH0/v1rivrmOsF56DdsoZwEMLyyZghkJodaf/RsDvTRnJLoE6DcNnRfxfsPFMC73XC7OZx
5wd7bUDzn54CEXRatEW0Ba8lZPIK6oXNemsXz2iVDIkF1864zfpnPsNv1P0P2j4vvgYUgS8wNKtG
JYDn7dj+PvfxdnIVmvuXL6GqTcfI9u7sx6Fdu7dX2i/R0WjmJzGUifmJllnp8HuK8iXgi7nQPX5i
HidTDyB3+NhHeYz6fnbFxcedzfsfnmgVM+a9Xq9ga+EpTnbmPELHvL9WmwiKlj36ZI8D8VEYoGFi
u8XMUaqcXsv7JNzQw8IgtRWTXSdeuMHWkxLSzPHHuN7MHbsftMdAzlb5beyDQs8WMwny77ubdhSJ
Fry5dNpWTT87eZzN2wCtvU3M3DHLn5yw54DFD/7cIBbplGC2bEWT90nOxfm7a6ZDq0tpElShwBC9
sydR3Uybhs2wCrXkN07Vni87teI5kPodtK1W7JoSTTZTzLcw++4k7ZdOpiBz+sNnZziUehaeM4X6
kSbwUznXBCAjWv7Kq+hK2RBWBj6LdFght+Jh3PtELcEKFzc9uaEXZwU5V3L/v999DCeDsv0LEJXr
NMfX6//uJRDKZAGdocynzsVUxbyiNowzpT5DWTxZjL4CTSXaaSvVvV61XT/SLIvPoLSEg5u8msRa
cyxZkX7VbrAzhU/Uy8auKytU5jNvUHVbnt+Gl/zX0n3zF4voaxXIgXSzJur7svKo16MmMRyc1L41
0Gx5InQZscEBFANr1Y8TX/jLDZRxPhw6/dkUsQuPaKFdYsI3ckCK6HeJ0fwFEJSUnhUsQ0JNoYMI
kcN2epNOaN5NxV1iH0Dq7kmBljoNZQ/QDbjFIGbFWCWixacfuT2/M0LGe/vkm7y1pNH8BExV423A
JCQ1Va6j9htc0XbeSMlSyjCLa9139bQTZPhyelPGUkb5y+zfocT5BUeE2GMcOnBywgJAlTCANMFm
xXwAFO7EMq+CuaWirtxl22CnQC1e0O0P/qhiTSxeEc61IO+H+So3dqmWGpT1LQnyw7TXEkzNT7/d
X597fY/jh2fvKg5JR8BaB+mgiyD/tU9vv/b4vMl6vA0Y49Z1D5edCJ4XW1bwKf/ymBiqclgqEVb9
d7ZZoOid9KDtWkf3qyZIM/tmXt6kO1RcrKfzP+ceaL40saVVDqELmQRHHw0n+OY9iTpXQn6A3Wh5
FZoM6JKFo+fXSPTTM7D9RF57/mnnrAEtmIBTAkj7w/ucEBflx7mwsRw3is3oBs88G7QbFt33Ee+k
CLG/q0lT3YDqxLixyajx7B//xFELHKJrjWf2eMVLnTaX4eCMEnmsdPUweYAkdZB5eOGPDOY/dxO4
vCoYprLE89sg9ExtPyqP4u2aIQo4HIgBG1liQJMI+ku8QqndACTGeqvnvk7+0bo6kTelPm+4ABO2
cRminvBpIcXbNEXd2dQpWO1oIjPT6NLVnMpKts6dse18O8bdZtGmkJxTujPjYauPd//DAQaYQ0jF
Pp1eW/neBz/pWHc+40vyvzHe+lKEJ+Flb9LY1hrV288lJnzyFk12SzsIth0NKbM/WLDH4r7hdO4J
1ssqiQseQOVOJ68VjkebubExek1GvSRygZTMb+snlcHyeBnz+V0bQMhM0/ymFFIPLSdfxLtBcDml
I9Mkwk28jSBszU7zTX5mNOjvmknONj4vXyJ0XEHRuqc8yjFAcGiu+71edB6Vq2PnxtCj3/nDzI5r
AJv6zW5+WfnfSS3MemTENgPy3BeCUTPep3J0oZtkoMkcnYLzXsCVrJEfiJGZAPaPKCCroAcubwoF
RtRANf4+fz+EUiayntPl6HPuItRQDt+PJijXfGtDfamCtSoXd4YkrsBLFZQ9/sZ1R6TkCjZFRPH0
SH6MqtWnYD79j0nVkL73RJV/2Bdn8syW0RNc7zZJPyINmtiXjQtsfb1lJf+RA3/XjfhBhVjYfryT
ueazr+7tWedGdcCrHTqZI9RE4vMKA81FLG25OyLPDh7jicFRsjRrBSfBc18PNwkc7EzNiKG5Kznh
x9otDjBoFFRBMeBv9uBh6HDZVifZBnGibelxXqONgvPxArnVNHHwOMbJdrvxCsKpIDDqeaXsW/cL
uFSMO1BJRMAxS6DaROqiPMf+MtDfaMxbnQRcJEsIV2mDtBNp3WOBaQIfDGRGeSBQ5OuYlNgzs4jp
3ANQXBXNaKlOYEYiVuokvgZQMsZ4TyuhObhynFq1Ztg0dno/jRdOW6HLonIF0BYqoqJu/gGE1kQX
TJxjzI7tD0d8EvEWqzLzx9jQlMXkNGF7jhM7hMUHIzSQsw0pi7/f1smQhlQjbZwuWySDgF64ZTeV
GO/Wjrbik5lyU1n08JvCBTUD5Su3OYBJ2S3vltrnZZjANwlfvPl7QvPE8dogfIh1dyLrAguauPYf
uj7fIfSMtQ5qU6iVgFlly4cEit4RYA3CVw35XGZpH6Kr5l+1FAX46ljgYD/nTXC0KvFXD1PtrEAb
7I7jOgCCIFZ/jP0LV6hvr3A8+IYWqW6TF3HKfo48We/t5rU670FLDaxpgKeha/K+hO7pxurPi1La
RKMYPfS1yDuWa/ZpWrcCupK+g3ayuFlKKBuhWazjiWEM6ofnr6evVexTTGBZsfh+Og/u1FHbK9j8
85Rs7Rc+yC3ZH1r0bj/Lh5oKEHpi3Epe0ogE57CWKk/WzdpdJhHg7XgDFvAx5QCmTnJcdLJCEgZh
iG6EnqhpydenSDAkECrP4oqJ2LR9MNbzy950GfiDl7KsOAeq98/3KwfIxwGEyI3VTLWkXZabnxmE
XYiUjwIQyimMypqAuygz92DejCG/lLSVS50+wPeS2G4gtK14Z8fKBnei4ApIcUSA1QvAD43YTHap
o5QIsMwIKcSAaX0Da3hTea3ErGIGASD6o3UN9KZufQ9Nj7A07KR3Tj9dgW4DMuJrxxz6UThIxjy1
bpfyi94uZpJIFt8Y68wNMbrWDVeEvKNEJwVwo2qtdY489SOOC1eBeAgbAQooOIIvIeoi+XUzbIVK
OstQ4supPgxbZ73LHBn0FI0rUNOqmjCy2SL8rfH18g9BHgUYENtHCeC0R1Bqug22CzeDQcGmGkdp
Y4+YynVj89nSMyci30z9zKYSJWxAZriQ6vEPmhHW5dV0UaVbBU/391HxBSSyofR6/QyyWd975W0Y
cHxduLg7qsIy4+BHXvU5jiYtKcAbqfOM/ya0Gth58Hbzzhe9ScU281rR00P6f1AdE8bLsbXJkh64
x9yQee9JP2C1jSJV6Z5HJ4XMhscxPXuCgpF+zRuKiPR83I2l5Ezinf0OTNBAITQ/hHuMnOf69DC0
j4W4NoQgI8spoROD9AIN/RiIAYBZk+Ljk1247tC6D+BuRheHcmRUEIRLF4pCnrYrMEtsPZj78cot
a41xoB2sSAm15jjwfx93sE5J8ROC1sRX+aKR51rWpUhKLZzB8o8BsdVdVKqxNi/zDCPieQuaX+mw
Q+WHshf1purXw++o54tOwd4Bg1S5QElDG1rIBLGVthqPRGLWdv1ky5ZFeWyL3XhtbynDmaHtQIHa
euhv+QfvryaDq963gV6ImcvqHyCM0MkOgXBtvE/0qWUNwEJmkFlLtmlolYLFGHO+pfM9Wk4wnNYc
oqUBlKHBXNhNKIo9aoHoF6Br8xNXW37yjj1/KzQeT4F7ltk6YdH4pjY+LLNAaABFsxhzN8lNADME
Nf/P0oweSf2m1/LtIUVTxtmaBZIL0hi9TxQwLjyYTDjVX4XzkXVf7xfBe+iXNRwn1tTThdgqF/25
x9zBdE4H/ESNLT/gBQWUP+Ujw2K4L4utMjMD2izIBdgdTK4he4m47khPCQ8n6QGvkPr67aCothl9
QrCB25t6hiz4nJNFCqxtvAR30PImgnH+P3aIUO2jtXVLPfT1zzCENqCXfk5RGZL7GHa96g1FFJJY
h+tWA9mOyoe20/GA3FFZOSjSXqlv7YworJ0odDq9J19kNAKM/S4dpAL9ytCNJLp8maNds+uIBgf1
wh3eRgQjXhrzONCfDtHSQwZ5kFjBRKTR1/QPA/YwXmLOGTuQ7aeOHn17ev9JIVauSiLNVQGVEzcg
LwtpKJr5q4grnJVAuxUEyUNNjesg1bGxJooc+Zp+H+gA9scwPhMmDAakvqz3zU8QEje8nDTKIJM8
0Qs7v1JudiFSbMPxO6mmG7fCx7xeB/Bb0k04rYYd9/fbaWNUsQ4WlHNOW8BNvyGuCt6D2XNT2dRL
mRwzsYzRF0uBv6NXMbSRLZdmlGS+8vW1jbe8RocpTHHt095vq1HCvAHNgXkzWQNKeFrvDrch/V68
e0EvD2ZnGM48+4YR1OZUNWVp1CASjMlzppAdCwSgE3Gtad8OMp7TfTMj1Kb9Kvd7AtGTbIB11DEy
edAKGnIbx6Wr3SWfclZN2MvirDbfpBYesPzDKnk/eAYxugreI568CWMludvHC2vMfHOPR9Ttjm/W
x/oEMcB/WR08NsuxkEjNbLbV6NpJhODA3IHwN0H/sP+gnZ87FrrJFfLnex4nIWi3IEcOSxtFEzv/
NDKHyeCnsLfle8AcsAuLEA3stB7F6I4ebZLNU76b9ZDGxIJ6/06N5AU/ilQ21Nfx+KfTVki/Sb3b
iX8n1sV8UzRGeScjzoIJ6KNCE7CqgXEJ74T5sqTmvqZbRt33ZoKJwIue+fFkP6J2kJ2q8tYoVsGE
V0x0CGcRYzRKtPAxDFpLO+jS0Qqs20v6QWix8IRooOzB7NWMUVtzebWunmKm1Qh9G2DgLN7dl51x
VTt0ldeUdh9phPq0HY322puBjW4JzbYO7+wJ+pAnVFEZJf940iqTmNhxbZlRkP7QCrzbh0NT2+Dv
ufkP0Ura97pl5eoP4wdSq0opmW+abmmEdpiOPYL0GofUhdVUn5yravYbirsHfz/dHHxh1nzW5pfh
FJD0FFstBePYpPzDecRCEj5monPFCmWE9uzoIZ6x+b7c1NRNbya5e8epyrEaamhlttPWmE2Np2Ps
iUiCat1YQDmV+pbF7Nu+Z5+ULWkdmgQgtmXvvyZwHPiqmWd3ByLzSkVt82lMVSYN9kctJcQND8rS
NgehgYVJB/ziLxC652vioZ6Fhn6i5OGcLoLQAr6SwtilxzLMeb7CxLarhzL3KSIaqcmDSRxycpQz
0vXQ3gPFzxiB+6PkPNfl7dppOfe0StXLJY6zBNnVgK1rEEbY1xdUGeYWxXp3niCxPpQx9boQHg6E
bj0+BffApQNU6UKmQirgzMtO22+vjlL+J+rKXRcMdCelV/QkPGn7RWMe5RrcKtHLe9tgaIUD/k4E
B6oKhTH5ZyYhnSoDktNak33ai7L5iRGpf/MXFWlHavkzWIDKiwQQxxycpxAZYdESX5/0kB7gNxc3
9VHZmA6f8anJp+Ed/Qe6FWY9t62oSIIGvwjfT76P83OwRFCi4oO31n87QXabsJWrq5DcY5MEsLOx
pU+RRAIM6MVBE3wW/Bz+Cdk290StBTBEy/vwzR0r4UufCdbFR+jgNxxOch5h4ZO/saBuK6T9W+kD
aX+csBUrUXHRdnZeKA08aqdZFYlOHaeEpROyCMmYTyojgEaW1ET75Ri/y8n5JkaAXjoDBebBe/xj
gS4Wzphr7Kr0VSnVmWwlmyzrtiqk+914HtsZ3Dl3zrEYgp5t7/Zs541Q/ghLFLAbprJSV2k3ODiA
WZ6Otni2ObT4F+RljZ3iiRAB2c1psRh/vg4Fef8xyE17DYkdYgi6ptGIbSrparhg3dC5KHF8fUtB
8VLeM7XAObSI3ZUCY7E7NiUoKzIcdunvXqxZE7+AU2pNS5NCQZf2Ib8TRmzFtHC/fmMeanjMsR3l
dHy0KrDzclg5MNBZxjM7EGQAYxjZQwcso0+ZrMYQIdzmdMYs/Iz+9zR0XM5LFlM/+upDgV39rtzX
qrszis/8vqByycg2iI/IuY90sEv1RxwVH0nBUwaUISAHCAAynCsUhiAkvEX23i0sjq+CGWSeiSPR
ejF1oGh4dbgr+K9WHId7rB4q458EdrnkaYe4qU7U4bwfXM6cb3LkXkWrRTaJWDIrB3/ilSI1mXLj
pDAlEBMiUjvlJiw+hYARp+SPFuRU7QEsHRgb+3mZREQ/sxpAYI+nWUHnEBOn/LVAUY3oh3XsARkN
WFEC0li8q+Lxuzds1VOcj55gUnc/Ty0GJ5wUf+jhSud1A+Hg0ruQYGhLhZY/jGeJG0YywgybXN7b
hY/e/uo0OihY8gcejCtZlyd9M5+0OCrJfQwBar6kHmsh49IgpmP/1jktUgwotrSfuSQ/jWSTimy8
7BXvrEeJ2Evv0I0yfwlKhbFkFFGKnDOeMUUXcDDxpDjNq6i3ZRTgwEXiNo6W3cIco5ER53H6ZYr3
0yXKiJueoqIeXlU7RksFM59QfhsYqlFFg6GSeV3y4qwe1IJqHXchW1Q8TR3O+mrXnHOUUI8tap/2
qtZaqdVdoIMYel+K59eumNqafXXAiC+GDfEKRg0MWcntwpphR1Ay6p6abLT18aBPGso99y03s3CV
txmPA2PacatKIytuEoHcCy3wsLTEw9XWAySJYYqWxbHLA/iKVOZhLdaMY7C4pCRMJLfxrHZzt02E
zoH2LvKRkaNcP8nbc2KB6DXkB70LKGHrTQdl+u0Hanyx/FD+7JjJjpJ+s/2IVCmahvTVWMkZt10O
XcFRE7NINv+nWnTw4WlPc3QjbFQBA5B9xZ2Y1snpYRM9IvcVLU5YZhcPzYNoaUMzZDkH+RIltQLG
lar2hG7nV5CNZfjCSVKd6rRNJHp+hrkDtTSpfLcqetIsbF88Kh7uih8yNtFyfxid4kRkWUVW92X8
dCVKJZm0wD3L8gwxFEleNOlAL6QKkEnVj+769wbSySVicLqga9AqldIvDFBOvJOw/viU2hsAWEU0
/9hYBSZV1tPmdhT233O0XkW2ZeQ1mr3keDs9WHnY3MIw1xcOXq8WJVnoAhHTKXaRwFK8E+XDBT8s
TYlpvQ8nwlrE1bjKwyFLhFaPAJs6n27T9kZ0vi28x9Q4BrfzRoCPhtFGqAoZKaOHeiJ8vm9pMJKS
6mM+U1pYY7nN8ONaahYAOK3BJ4EEvKhu0DOiSkeojGgHw493dPhSsmip5/zRKOAwhBOFOZHwD6me
Jnka3vBtkA0qArehWyPHiGPciJTRPJ5tDYywV8n/JQlr4Yv4S5cJcaxjMuO3CifPKMCe2oNceAOR
WCTanBmtqi6GaqJMdmYtMO9h45L+6XaKyIdE67AcSmHua1yd+hquAwUnDaa7w1sHmBqy86nwGG5d
qZ0ulpSFvfZ8FYL29xptrm9PsO2luLpbjst9+1QIZxcj8ql53gw9UNGHa82x/Pgn7pjavsRTeDS/
GTcH8VE7kk+4xPQ8k8nwTW461dKwOxaLvlLTk3e+VSN8r0Q9ZPioFetJfPk/N8pFEnMcz9urJXjL
tTeL8Az1Njs6XtUonQLWPTD5nGa4IR+TL9Xt8J9Lj0O2TG9C/7s6xFO2zXBpMaM0K1iTtj+xUL6s
nykuTICpImRnuUuFpR41r2bDqdpnVTQxyDqriY6uhFB2OevzOI429ypqoZ6jHvwbh+Nac+eAPmpv
YKT/7IHe3YuYK+RB+jIaN+xzeMFLQZcevl2lWJVY9yniWZy7Pqg0GNBH/eeIqFpCEuNWDoBvs8+N
RFcdjbwZHUsliQZ3UpjwqASZAj7w6d/zKXhOREqZI1SBW8YcO2sQRNRIuhecTjogBFAXWFOAdcyj
Fg6fd65Fx/bfqbe26lkS/hAA+Jv00CMF6J7gMgEIcccOrMpSXZq6DnU9HthpDZchZ8cHMtNGbu5c
DOJLEEa7AOeAxUfrvNNHczgM6rwmP3ZgDr1yz5jaC2Gb27RIqhkUTpz7ePtftLqf3M0Hcl07OJcd
akh+P2fDMfC2Zo6+NWa/HC3r5fIJHCEhcZeJ16ufmpx9eSM2fRPsTzQNaOqHA+iwtsLThLV1Cz7z
3SieIAFBXK4In4vDCuaRb1YgGgCsJGI5FNCmTD6iqPObO3U9fR6rve3GuiyArj0Y04vNgap8wvXF
RLdjzq+XX/iihB4Zv8EhYWJK2Gd9yelCOMdY0SDIBRRM6SNiYr6KB3KcX/lcCtqFjZ8x+P1RANra
Uj7XIt4WTLmU2aOzKXm3ETWdcNWqiquHqEJm+ec3zShOwOUEGaadZwbPbrAtLGYwjwzXrgWXnzLc
oLLvfPcVPDQIMb16bO6nioq2YvhvgzZVd2pd0O/oGmtK1epn/7uLSX0/TAP77XvaOViIA0rK5zSe
WWdzbga8fHwMB6wwNL/h/+TMMsNoX2Pu6FZ9o5IVSET7UYYJqzXsQ/OogLpy+fF3d7yfFYfDvCFR
3XA+kafG6iQ2hUmfl9tkPc/ppPsHpzyo41VJf9VK5+JELfa5Yai/tvazVxRjGDmre0UoVKFPjov2
pPIUnn9iiHQNge1M/7QcKL1y+H1pSmMpS2mlO1aZdzbvexg13tJk/eleFuS+oR86natvdERpLo2C
uXwxZ4saiMxiDvEHSfF7o7CzFgyubB/qOSEc1K956/5FNY7PUpvDaDbnpGa1Oa+PIjpkg1aM3bsL
A+q8ua0Z80wWHH/BNGThOoZ4Ag91AaXII+RZInU3KSsLZJJMe/xXuoLsJXkDWE8LWLiW5awpBhKx
yY4KFioyoi+Oauo3jH6ms6vmWa4i8kMULLrQ0SZG9v4mVo2tBUU0nyYLglL4tEv4usJf4HD6k4IK
Wjiy3XxKPMVarPPnCqc+LSEMZwtoc0IlNX37aR1CKeyjxUs0aklyvXmtbSaSdhkbhGaQlq7AQNao
wYHGpsh2Wh6KNj5eYtN/9y5oE9lLfdHH1EbKwPtcgdgFCY+VtISgxANQuke3BFNZfKxt8CBXu4dj
arPSnGTjFXTA7rmTzuv1mm1fDE3UhwlbgsOoiErOvzoU6VffqGB0sRXVa8H8JATPEoQDb33rUsOm
SABKT+4HAA2nBPL8UVusau1aMlZwUs8HRkGQrXGs6pZogOnohvWxLqD902zFqx99+kw5U3th2Gj5
kItPii6WeTKzX4e1TD5UOaAlAyOZQ7who/h3rbS8e5C2pVZxNlKw1C5JH10R0SCcDiR6cNOOQIcE
JXIou2aPGy/Gx4ihuByi7Jm/hmGzTk0wD3XLpSw7YVUcecuRZbW6LEsTw2K5LcEqFDMiL9dRKB1t
C68FCo+6NHxXZEZAIQMgQIbHF9GBGuBcCYBZotexYHcBRgxn/rrkf63q2qHcOVyDvUhRPiotONj4
sSGzFbcyCnAx/kFUIjB6ABaIoXwJ1ys0M5Q8hwUpXjSuGtPQzi7+SnP/ZIaXbUb7gAypmcLScSDx
NaswNlG+TDTzwPEyQkrBQ1a3F7H7AYyH9vQ55XU8au2DArLnK1KDgqOA9Gl8Vhw6t23JZ4RJCxm/
Uv6xO23PVpTTL7e9GPihhlx+qQCDezAp6mHLkF0So4rvGC6PWIVfxBDkkMs/pP0IB76VeGDilcDl
zfcehaUnzuCK5uQ1yGjqrkcP4dqF/i+ioYYn0/TNhXmLF7T4QRSL8Lv25DPtJY554Kf5odJNweA0
QHqtRJfN/rwtrI5fxXNLrl2s7yQ/w+L5vzgTEvSS7gS7qOcCv4cFBVfak2eBib676NgSJKmMe/V7
CA3nVQVSWRnLXfVO0lFBlcNrFGhN6qSCT56jTQ1lbmRzdHJlYW0NZW5kb2JqDTMwMCAwIG9iag1b
IA0vQ2FsUkdCIDw8IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIy
MjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMgMC4z
NTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag0z
MDEgMCBvYmoNPDwgL0xlbmd0aCAxODQ0ID4+IA1zdHJlYW0NChhVL1/WfVW+7KuwyjOnRR3uz3Hp
4cZASnZ0Q0Eim5814ENy8trR3tl/qfyN6e3o6KD0UUI74kaicJu1uUfYhP7Uy3KH4C3yNMWPXNsF
U4vve74me5UBzV8QG3UuvnHNFc9cf6LWCHh9JsWzZZZvIKih7ESDFxl0f0aDU/AO8WLnCzGh0LRf
iPuTCiEAYy99/KbAaVnuBxvKyUXq9gkEJb/yoNTGmp/eMv/GlYdVu7b7N9wplUHJL1caCEaFeDAT
7PqLxs6WpGM1ubr2EOOELyj+yk+JLLQ3BtuTx6/eZCTsFFiuU3kx3ntGATcKuZWBw9eDbQvDPM3z
bk7uT9bjaW4DYFi2XPE2rGion1AxCi4bU0iu1rjohw2zicIUhAemOF0d68pZ1fa/jt5Tu1UuxW15
sUThasmFGgc5SSvPUW+BAoadShsHHWumPYd6EDVgMqqAoOI4kUHb+cXf++oSwk4iab5CKNLpUN9d
PX9Wj/2QBpNqg3G8Iehr+ocBM4hrBxBMNnym1zfxrYIPrg7heEwEJJRoJq0HSfYhktCjOPL4ArLJ
8kjurqQy8yGrWF2dsVWVduepbbZ2Tsy5zHQJElM+8YcDvNBs0xCnDgX8Nle6+Lzu9fI9zPDGlSS/
3RMZ3ZtT9sQz+vQfc0f1XnqlejyipS8zCmAMBVM/F6K1CGyhzV1w6/CPahdlBmDOFKtvlHy9jTn7
ufeT9lETJw+KrNTZEd8DVrNtsp6oKDvmPhWoKyljQjjcphgDPmQjJfJgKMhGkIxNmp4CKJ8/MY8+
CiaQYeiVtzTjezrMSSRFRpUNfe6NF5mDT6LeQzg3bEsM9oQ4ldfT0m2jlyqiDNigOtyqHxJp7+8d
JqQxXa/18WoxNc068amQ00AhZH/BdyLUSLYeN99n4gDZvVrneYt8ZXOned4chbLQy8PX8PMmtBix
kkw8as9Ny115gCuCR27aydk1hyW4Q0j7S5xWnYuRmshpVyB26m4DZ++2Ijvdhhnhs2o8Uk04wp3D
SAKuAVTzsU0kz47kQgxQfQ/mxU9JahtUIDsxdkQ08uF6wNkg+7QWggJKTAQq5qsO77pnD9Z/nGEI
06/uQHD0Wva6uNBspFYkCbZatwlDTFl0qdA+Z4scjfWxmH+ybBV6DrNn0x7Cz4LEaheorEvK47zZ
43/XIYjtHAq9wfLH7igPpk9GLd2vIV/tWSQa1PM2r7p7GkqUs7Klosr1audTH7x3DYcLXlqyZ/3Z
ps/XzL0WE58u/w3v81KHy/UJ+g+BcMEbMqlGNgJgtUaE8PscmnpUluMsN4kPF0dP7vb8y2kxcrzM
UDwF0WIJ/z4Ec+4BvdRhNc3EWyGQOeoMMvX8bR3u5kU2deMNL1FI4kiCkkxZeDO3BLbrfGwWOrFr
S/LeT5tau1pF211XplawxtTyBj3g4zYfsmYURTgk9RuqJaxhUTqx49cjnwPy4anHpXkcHGy1Kwy+
WSInNiMMVNA0+1VOg29EaFnbyOsZrq+t1zStLRpjjwZ2Jz3dOzcdyDsy1UHQeOd4Bqw0xAmMN3c5
BDDGbvAryQg3FkhR7enVOaeBOnNMJkwi5i/HPJmabkeZFPGV9NCm7qUF458FJsjXtaVhj4UuQSrP
pQ2scFspcxX16ZO7inpJeKpP0V76dESBGzCMxhv0Y9+bRSjvoQ3GCRmYv+bNf5pUjqUPfzVtyWCd
Xj6vDFk0OIliUiFwgiQ0/3oY7U6xrXpufu5+HHnYiJhYlG8aqPpHE5/WziwUqEfXF8wpxuGp9+QS
ye/Di4AdgSttty0SIfkLRlHdrvI7PRRg+2Y5NFLUjBj5k/t6loBi9zU+UKApMPuSBWWM4ePQULV5
fe0ODwnIhpSTJj6ZBSsr3tjLAWZm1F8fiDHa+Zh4bEsX9zf4NAKPMiGzcomvkV59BAVF1dYxOEmT
MhV2F9q+QqUFbdG8EcmeM8vqlN+KtNRSF0NffjWLQZCBiVqkFP1peHXX732EAkSd2A/p1yjV09jC
Yw2g3VlaA46oCEjhy2ZFFmfipFxLnQKNuQhvu0Vjk69xK+n1ELRxnrqq1jLHmCYvLwOuaYv3MLlu
FxxL/sc4slDxYWYKbjY+v4UlsTznqPopNaGY78pD/xlnvNBGwCPsvIr/liaRWxMDiYoj3AINVq8R
ngguIepR2NA7RqXWmJ0GVklxXM9fci0w/ciBSBb/j5yJDnCm28i+nf2FGQEYUT/vMnXSDtXXvik0
UikCzTWL5s1eAlYRIhN4/Xcp5hKByY123cL9J50saAFWPqI8irHe5ChVw5MKrCdZ/j7Fhjgdu505
F2dsG/gMox9qiC54PtIZo9QfU2f4uvM/8xQ62aT6LSbMuwhg7bI9b0z0q4v0NQu64Bye/Ydw3JDo
godj3t+fAyiLhX/ZxwaqatpH4YGZXr1S239Ay2roTSWeyI+LRrrX515RAyNhQdkpLMHrahN4hAIn
DWVuZHN0cmVhbQ1lbmRvYmoNMzAyIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9B
c2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyA0IA0vRm9udEJC
b3ggWyAtNjY1IC0zMjUgMjAyOCAxMDM3IF0gDS9Gb250TmFtZSAvRkJESENOK0FyaWFsIA0vSXRh
bGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIgMzA0IDAgUiANPj4gDWVuZG9iag0zMDMg
MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIg
DS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAy
NzggMzMzIDI3OCAyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiANNTU2IDU1NiA1NTYgNTU2IDU1NiAy
NzggMCA1ODQgMCA1ODQgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIA0wIDAgMjc4IDAgNjY3
IDU1NiA4MzMgMCA3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDAgDTAgMjc4
IDAgMjc4IDAgMCAwIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgNTAwIDIy
MiANODMzIDU1NiA1NTYgNTU2IDAgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCBdIA0v
QmFzZUZvbnQgL0ZCREhDTitBcmlhbCANL0ZvbnREZXNjcmlwdG9yIDMwMiAwIFIgDT4+IA1lbmRv
YmoNMzA0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjA5MDcgL0xlbmd0
aDEgMzUwNTIgPj4gDXN0cmVhbQ0KnoqghM5EzI1wMFgVfMCIwWvrdk7+fsP1ePXLYBW+Q+Eohcft
2WmWITGgV2UjZg9JyS9rDXFhceZjH8g/mAoYAEDLKx4YLmz+y5zknTIKeAer/2sazcnjnI6bqyjt
P6VsFh0/LG0aebAAozzXU57mEWdH/nqqcPFgum/Hz1mOKposdSneSwwc48m4ojpnuSNsEYRtUEtX
yKpXXE8lJbOns4PRhuxwRbopoxxh+ry5lbp3DrAALob7a1uXX3+UcID37FMOyYdXKWeTWAzIINVE
QpGRfJRCUltR2yhL+7FVsQqpN8IMLA7uK5OO/5OkvTeJb9iKTlA0V8WFbULLNSSsuCO3ee8Tvs5h
xBupRNg1Oqx3A4qRiO2QX9rdH8Zu9vwGrX0nHuTFSrd1bBz8AU+00ebtwa6FEqPmsOZFCMwEDuXX
hONASoaVCf+VyaIhOLcMaO8mnntRpEDv0QhV1zVmYK5dbBn2sAPztB5TRMJgMS3xRqpKZTKnJIMC
qa47EiLuwO+XAzd61wf/7d2g9AcElsw+Hp6JdcXk27kLqafjJUYS3ClKF28zLm+hKw74ieLgO1f/
DrYsNUysT8Zu3qp4XqauhSEBrKJBXFnT0HEXvRcbg85PDt5w4+W7RTPWioVYc9ZcbeHXrd3dqTkW
Oq5mcpm17dBu6xLN9mlA+1+EjTellMXoLzIUS7JjzMAdC6OyP3yfZ6mVuwoqNNG9ap4sUB1k98DG
HFbE3WRCDwMIvJhM6iJXCR6mJ2CvDPQiRKC9WMWIE3SGDKsFp8/VatUH+XYcxcw37+Q8MWvjsfov
J+dIe5QLVGGxo4Cemf/nJYRLTASep+/NbzIWdR/RIHvjqGNSJERsEUdmnhSSiTvmOp7cNrdj94nX
reSOybAAYPT/QNmVTB1YjhDVaYM5h8kH+tcvSQfY/xzWS2XtjqXlLWH0l8Um3AgjPVhhMIi3tiEa
LhfMJpxGCYeHqEBSMUMAWbuj7pM8ngSzw6NZ+/rwPZaCbZ1rbK3eMBlzkRxG4u63rIwGt3tD2rP6
mW0kit1mheibGJk3yws0BLsaLBJni0zXJasMJ/WECeT6/IEz8ZTW2yVvmBcSohHu6iW1q1hALQmd
W+EA8m/Xz5zKx07/tajRIebkHup4S+0k/f/+G5ADlM1FndtvrOfmNVARZECuCLPOZ//TzewMB5sC
4U+fQN9AO+7XKKl9oFY0GnwqrZTZ6/048oUQyDh9jPEGE6V4VVWsfkONMDvF26dJfOUChktD2hHE
hUahKEMpvxiyyTgGzO66d/7AwMxYtWJ86Vc3dZ1Kalhr28NUdBrjmtEzDU6Lp2jCUYRVh2XQcVf7
JGykif/9dYZ3pmyTESda4kisZBju/MiJdT7efFp5yHrrT3KNVXAF5oz4XCZuYuAPclx2ozR8rytR
3fkeRDvCSj2ujpNx9znuWatR6jgJ69GL9hGLgKRxGHliIQmh0X7h0eY3uuqvMOqn/fM72BLoeIJ+
gCdr/t0bIpWor/qg5fphZq1g+aRj5nYxVG2oBfMbBmAJCBf9ag9VceeK5dlCy7+/QpC3JjG0L+N+
h61zIeL4JlZwtC1mrx08IPZSXPnczK+lcjR1iDdCiCdse3wleLB200pGE81J2r6nbBXdGBQvL4/e
gS8Y59KGxE6n8HAw0TYC1R7i6O6lu9TvMtJsq6Cr1gOKClus/yedjAEFL1w9obTgvuW77PhB1d3b
24TRpyfziqsD9E/c1KO310/pmyjcoJW9McASCGnCbYM3rStYJIECfz6UdgXbk6+PC1kRiuXmUw51
KgFtiuRq3hHVNoMOElf4GMJEdszYijl2yoTMtMslV/WLWuu1QYlYeUBDnwyCc+5GHSGO4Wijj2yL
ryyvrQVHPgo1abmhaWwzNoQ6w8o68Rxs/xyqRAHK0ICpM6Vahhoha52don6HkJbcc1gITZnTliXU
CFkfbT0evJ7kKByFuIwWkLPi/c6DpPMbe38euxSQ+d0yB65koqMGGLk+28CtZ29ucYoTBF0Ef6zV
2Orz7mkG2yJRmzev2qxUlAAJqmSkDHjlZf+X1lPxJ7gXfBcoJu3vaIRup3dsZe6BNUMgkenjo1++
paPKpLijNny7rEJk15K1Kse4ltbUnR5nZ9vhdXItBZTB9bHVEo3GVHZun/x3MnJjW3IUsZys/0iy
tcAKz/AEj6e+c2lZBknWzWUJL4qMTaLmEtdl/8jTQfBeQJjKNINfx8HKdmx/cwkNxE1bM8rrt7BX
iyplTex9hXStA4qunCoHSPXFIiEnK3aJNwY5FzZP+wr1lcdS7kBr2jf5QiQjvLOKOjUasUNPW++H
3p/vae2ucWZS7eoyHy7QBIRCj4FaiQ9xQn3nNcm8Fr2czRMAzmgm1PPBfQeRl48J6exSi99FrjhZ
TZAzH8VPWGghkuXr5FWLZK4J0iiKAQGfvpXGRKHF+bLl8UuX3DnG0UHz2+lqdaZTOzQK0b3tW2cp
ohpQxupWcLPRkX9IHqh7AeK+Gb4EgqCnRhbo7aWhPUSHkgg8tQQGq47XZAAdcyR49YV986Pponkb
JiAEaoFGgrza54O5ISjdOCQQ0/AEa7Dq5zGNmfXucHlGRwkEz9qdtv0FC3Y0dYGSWWny0MOXv4YI
Kp4+sJQ000QNVqLEvFbMmcAeaFPyaNaXcf7hGGESsg/UHJr/JQDKCIkpYWeeDSQh2OMs1lNF929p
3YhRra3I0of7IG/toZBz+wmGLI9ACLudCXVmnc+q63CmRVqv8HeZvN6ymY5LHRTrl1oEL0z2uFov
XtLPZmfER/+zRgml+4VD09fMVqfuysUijsrqw+YND5DPrPOP2ekdFskmEK3WKeq+Yoy2XKr7vhcO
3iq5l/GlYJ70Cmf4jE9MaUcErWoed7/Mo1eXoSrZzeP0XOZQvOSa8S5D5dM8KZY1GZWM4R9Ljdlp
MOXeDwu1XxHJgVF+7HIAyxtQnTAg/0/dTurMAyePVriHWj8u8pHJ/TCJv2jbUIYnqXmoGwnwD/oa
zh0YzUvFE49L6USyhppCLrxVYhR1ZDc6zmz3mYSEVIg5CJtgC7IhxGlRHUqY+lpJxkYIS93aEX6N
w/GFwsI04qriEwAfFKhjQoKXBUhWhy/b/iOBeGfDzfieaMdzFJ8zPg03Q6h4upZKCvrT6bReRhZK
ZW1g9GfytaKW9fWEf343tBfs+eDhkR5LR5Kni7w1SMcKfJk4IKKD205+9JPZpVs1oIHLmIr+X+hn
K3ZpZ9qRzveAlCZMxI13g2DhBdiQ1Mo4gse8b2wgpPvso/rBTVaGx4gz4qTuzfy+689WNIBOzXoA
Q1ASkc8Koc83CJRstv2hbgS5sMAQrg2AwmIVez3GI7uRa7biLSkzii9mAwKEZdEszZXcEl4oKWUu
jdobzG9gOVFvNbzhWIJYdN9RcXdmcQh9dprrqV5R5w4xoZQ/tSv1MJCdv5WxPrw4zRImlgGZyy/2
tghN3keuao+ewtyqgZReWCdysFgNIsw3uEdY1Y5WSfbIXEn9GrhDaXGd3+Ruh7Z7bkxeasxjAOyM
KNv6IWa21r9NT7VP8MeZ7nxDm3rci5SmHFddfiJCpLa7KWULnV583MXJckNiT4Zgr/rScxJ3t3bZ
L1FyKpKdkFos62v4dRcHAWAV/NHSUrwVKtviVZlb6MCSlvSj2tAC99HdvrAeQRAMXR49EBv8QJL3
ERUGEd3kAbSMYHOyYvybBIrSoNspvdk5TZtav8P2ZVheGqcvfwj38T1eBhI48pEA55V/uk/j8gat
16yW12hag46RElkIumy8G17Vo0E19FOz799fklCAH+vYk5TpmSEkrbKUJZIqpzoY2gPoPsDg9pYY
V8qZB2vY+aNl3jFpCJedw8NDrzPaVokZ0Dp8Q0GyjJyTPvErq7w3gY3DazuuoeMkLyOyhXUg2icI
EFaXjO/v/A9YMTj0PemaojLiDWrPigUacCXfeZ1I3025hBlmLIEV5SUhSPoo4geIsehGKByhvr5p
gl3H1EuVmsqnp97rxrjXo7AmeW1m36d9130t2ldi4DABbVI3ivsDkglc7mvCn1HzjDLE98jlyie0
bGpDuQJGSCWJy1J3lrFPr8fZHc3Gdk6NJ8RJFkqYd5ggMjCDNzhj3zqWEd09jUIsvgxNcccKIvgd
83pzJSz5wyMQ2gHm+03TjN+Q+9a4wfs4JX58AofbK8hgdP4iqR1Vg6reQWb4eIF2ScZjX/xEoCj4
karPtRLAZiTblrPdAqu4YBi1nemZs+MbFCLNkMBdmp3gC8eCmY7OFzvLifAQmyy4kdLuTQ/pllAo
6pyRUCGHH4UiIN9BdMLck781Dk0Q2+DN7zSu5mKLwmq9/ZEc/aTFlp4FmI8BdB986SPK/aivaDsu
VTlM94nTeiH9SdrNT63vdEagaj4Ke2a+ePt0Xn2fF5UNcySBsbGNy01vW8iGcxnAt5Tm4k1+1sph
jGzTwWSD/FKrIOHPOuq/hUHSjQ47tpkTyFbR7EndEH7p+EOdTEeoaezP8WNtUY+dXLBDgk7Ac7KA
AXKKT2rZTyaxgQ6Ej6NtLJuHjSHjF5DNv9VUL8BkDJQDpung00zmXf/oAxz45pF27b+PfGmuwqnj
2TMdgZKLJxoSsqoRtC5x5z6OcP1qbZpFclhPl9q7sMEOngHx+cYeKFO+G4F9o0iSVddhHJeT3uT2
D9dDn4uJD/YkJtFVrtG090zM3qjxNzuuhWnjDgPcAWL46aAfA0Xr0mFnmhP54jnSMsMC58iC6FRQ
XAM7uOf4+UM62NPnQxbuo1rkwe7NP7RyA6Rc696jK15J9UAYFtxlH1Csze7p6JYvIjqBBQO29+6w
/38HB2Lz6g1EP0On+/Wcny5EZAUXrdJaBL0lS+QyIjU+lYo6x3Uzjku2ng9+igcVk7Wn2Ms1P0G6
4nSRE6c8uC+sPYfMbNGxEezIGDLWk/vabi6IeKsYzInQWYwF0e2vuJhr0ElGp6Y2SnEzSzBfJAyp
8geXox8jiVdWk/oKJc1Mg2dSwRVOVr57UP5EphndiSdqtVRaxl4j07JjF8hIOubTJQCloZe6kBTY
7kFjetAmliD8oMHfQd6p2NARHYuvklUIdFsjL82OGuCZlE4Zbxv89bAQi0ycdlMJNtmfW33q6taA
Pt8j35HcXFzg48mSVQzzrYJSA1ZfTlEDhqh4AIBPsA4pv3o/JWsyPe5c+94dYoTei8s1hNA23Vvk
EvLuLwbwBF4GfTvphcxrtGKzaKfDFyrH69c/y4w0yJZ/K5ywK+cqvomwZp8NO0iaVo0yiX1W0E/4
BpyyFg2R/eaUm97RTVRCi287XUUrsotAjW+1VWfvEzpyPjvm5OG06OqUVVRFyH3GH7CC252oDApc
bvNmO08cSd4p0eVs7hH0mkJXZLxVAGUlhT6b7UpDL/JvgoOJe14LQ5cCsKmz/uhx0zd6xPRs35YL
r2o8oVpTzJT3xaU6gxWaq25DHStOLGSijsXgKJmjfr7pZgqNgdyCdwCaod2MwxWf9bVTQ3Zu00F7
HaDvQQWD1aSw5G/Pb26f6dbLnGtErpQ89s7yU2Wesgl8WdtuA/s0yZcYtqstAJx84ysC8+OG7qOU
Ujkl1WXInTTSuYYsPSlzAURl9ARutJD8m6YJOUK2UqTe/fl1DYwbfOD51JUcSwbBQ+CsJi7rwwuI
fZjWvZA2vJ6360kM8b2wLBbcjxQfnEdKNPhf/pZ/+6sMwqkacaLkEX3SPI9hQvEXLmHfCasJYFyV
/vucIbbORVL8INUHTZ9zTMDoG70neVVsKxxh/NZB+HymQG3lqUAumuPvy4TuNv8+VqKxFgpQTEUH
Q5qVsd84mTTKmcK8T4LJAWi03Fk5ND6hjTCaKn014LcsGSfQToAA0M77+abnhkQK/2hZoUxHYSGm
FXBSWfDL4Sxk5E5s7P2gLP2F0jX6ZPJyBcKYs/3a9UP9hm8UmlJloRC6vbq4ImbxKNMPGISuywyF
hhLGFFU9uQgkKT5VMAfG0jG6t3u//JmMHACdUqPRVgxYxKr3gqbCM5OWzATryNnw0vSfW2OpXeYd
MyqjWeNk/XKVQiUJRiEYgW/MOvtBx+hTNDLUi2W/sAOVRqff/5R1o27LcWrYbdIeuxuwAMCK/Voc
rB7jaUq4DCmEJZVtr8W/eZbbi7buXbPodyp6CGB87vIl94BnsEPTWTeBGwk29/l1gXd/1vwL/GW3
t6G6rgax9sjJlRb6PreVwW+LxuT7CO+VxCcpKTW8IUz2wsZDjhCy61cCJwBP0qDHHVt7ljCFtC4r
kzPIJh6L5rh68Xmt0i+cFgdy8gmPvR19ErD1klA4bnoN0StYdyFT+gNWktgT29mYPrX7MLutWNaN
UM5GxsH2iazUUt8cXSgP/qaS1BN4woWSVsU9kGCcWdYIG7hbAHpEMotiMlVTQws5H6rAjkWk+gup
0ADEwsNbCFBRMBC9F5hNPC3mRLgDMLyUHKUGtaOws1HkPAXsI4zEXyxkDyrymmgx4VXMpzpheOjS
HKhPTotVj427+www/XCriVf4/rby8F+6O8l+nc95QonluQX3uvP4M8tfARptK2xCUwmyid65ry7Q
zDvLFqyUNVKyq7VoRu/fpnU8RZbz9pkFZiAJxInIAPyUSz4ZG0aWRn/YHPZwwXAsXzMYivszcCkC
pF4YkYpXc90VflriAlcQzxoUkHdUtkYk6eTtm4ONSIPCWZ4NSwN5n94dGgpo6T2/uyIGObhLdYKS
AX7Bsk/zW1TFEKG8gZKKOKJ/ec1LaufXFpYgy6TSutuT8jb7Ii2lN+pSnD19HIB05RNfzV+fyv9M
BG22ohVkJJiCm4lu76Sngwywa3FlCOgofWw3nh/CLAzeaCxXhm23FHFF4VSzFvR6ABzZmQ3IDIsI
yyEPgsWdi1snDoOZRUMB6c+Xi9addC/2JB9yFZewTfptyZIo7ggRgf8ExLxPjVLH9dwd7iK4q8Cu
ZltidwUT2GAxwlMoWfQsFthlT/KohurjdfD0lkpIbqIxX2EzUzEqjt0CTiPnK9S/KccjuFNWZEmz
0uIgyCpcbPsya1d+v7iqQ00KXYIN5v+SyFwHX2U/BVjUMREloWCaHM7QLVo0mQFkbnTMzcvZB9P2
5jgg6m80BoccOPLgcjnT3Cya/4VIkBxCcZWPrDc+HNWU9ieiP6iIPLvLPVmMosEZNPwloBPVwwas
1x1r+1QA7LbexivCEOVoUYmNlRJLdY2vWffT7UhnthZA5MQPce8T5cPpzAa77HiREFUCRivg0lkj
JOYrIlWqynxTYI3GqqtRlwE+6G/+6aHWzPpe9H+8Pzqvcnr0+cQNMEZ7fNf2nIuapzNJHM4NCTjX
spXA03z+GpVBlyye5zlvEILS3JNahipF6f6+RsIGJjVqjE56oCQ3rpWQgVoWDyEzdOS9P1OSglDz
OA1dkaEofjyGwVG9rKmIRLbzKDs4HKuRpU1jq0lOeWoY2X57a7IZlJNT6wqKlpBERgAh39EmCRNS
WgkVOxL+TNTcBbGit/rmMWxgK871X/jMr8+bf4+c4fBmA1Y7yF6WfR4i+fG5gyBsbYl3rG9c6Tz8
HA6wflVX54bImpoRkF2vBAYLNbM4DX3OgajkoDumQBzbgrDCDn5R5lxN0XeiwEthQN804ckgS62v
hkUZRkraKgmIx1hBTPRD9dyK4ehsKmr/b1txr0Bj2KYy8gX8/LHaJ/HOiWi8WDlPcQNV+H8eL8IV
srZT6Tw0EPOIqUFM7M+y8AP13du5N/2cN2pX1HnyY0lBB9H7b154rj2AvC4rIDsmm7LTfUyW/xJ9
NORQ0n/YKa/iPQixHyLTptaXNVB12SoJrsEGgBZW3MmsYb0WrVw0lnNcQv3eq5R9xCRVab2juQRv
btYZQYoYHWkUqhLxH/fL/9/9LQblQtYBmTBRaBgUkUCsM0TTp+WK/YZeITHHF48D4SBp5sEiKzNN
pyEAIp/Jzo4nmoMv9FA+AVZL8GnhRBUUq79qdkn19IDqeUySqqZacqBv7sNpBlMJAoiN5VwduSVV
xG5TUB0x9IBg6RzMTUU02OY7IZPz2blb20bBdTm/W3t7SC49Fx2til9PvTjudc2QeYt78LgV25ux
ukg2wlE0cvTDxlynxUlm5ERYsd/uMse8/BBl+iL+eHtyqlEW5ZBT6oQEwk+hTAbALD316JrJ1pHE
zt8jURvUm5x5/3yN3sZgfKFfDYocX2ZC3KjRD+eOwDDUB8tSABRN5WS1X4cn1IvGHTVkYLVqZczK
7tDYMHGn8KteAb/lLvzYGnlYjSmUsNgtOB+UYJXLDgNOq8vUb6SXBRuf4O4YZ45Dwyomzwax8Vku
R7J3Mjy8hUimm54Q4o6ogar3mFiGwsan+FGhnI5zsNkYZmJaHcQdZ7MV5gqrlyMgLH9Xj5+0CC3j
7dBA1MURjiWv4rcLV6w7cS4upu/DWt7RevAMBrPgxIlbzy7XVoJZQPXhbzaHAY6ielg0R4I7KZd7
d6gn5Hpz9wquO/wtJp4m6JdfiaMUwhj8TGZoxu+eb9E6ZxeS6eKR2+EsNuhoepUnVoTukF12usGI
FF9A9SME6rhfdED1UjS/DXsBtbSEwrWO3JnaMxEol7QDHy8O+AFkZyJbOq0gczDGa1m7j7MB7X5A
oMN9f4Csb3s2oLkuBS0SMXkdnuKdS1Ao2P6QWVhF+19SvdIHAq8bh+QT/mFDtSi47on0B4WYwMDR
kNPp8Zdb1VkO8P61uZgmWdg4TG4PuuGQfwr706XWoV0mCZsEK4CJZnxKQYvrxHFxCrEtyG0aHlEQ
9/wAnH9vKPSjqjaRvV2ur5PFabS7n6YilSp9uzOpbnS4G3VmfuSLgkR/hVVO447MfWywh5ldop/i
BbK1L7rw+orSinA4NDAae6Lxsa0LZyX36ASTnkCEVTcyCy9JgOYeADofm9lLMk5arymh4NhECJfe
T3N7yMGSiAWNRy/LWJFJscowsRC8efgzLlqctAXJ0sEATL8y+bRfIVRA1n3MSPqm6JUAOaJZ8JJO
biZDrAFLXRCo0sL/JRRKkUtTet9+r59IvGz6HCQaS/+Ic2+MUwMb9jKX61uK9xWvj+WL5PNIZ6zO
oO751BtH7VUA0Mn+h5IGQ/hozYE+9M6G5EvM1jsw4hadRK28LQNhEqRm9Nw+oJPkDPRMVBZCJTWr
EZS9ybWHIbeBDK41qCfLT0zn0LnvDyf2kkr1ewNSetKZM09QzuR5akktqC+j8bWzD/2CFDzdNgPm
LHslzRcdKvCoAzXEithzkooiILbW43K3OqEQRvgGQyGBQis3VRzBm/t5kY/ksMlkmyyzkQyCFYU1
7VHcVLU/4hnXmTXAdQsbloh2ubNrsXXHtixiRNCjgKt5y/ZANkrtkgMC8eH2mG3Es9Nq9m+YRXbm
Bne57zuTa/ETGhYm61elMZIDj9I5kTxsY2k0+dT+a5GwASrpIvey+uPvYrwly4tBRNUk7B+1/PcK
R8qQOCVtv70Cyz2Vxq3lVkl+FtdQ+h53c6Ok/nfc+mGi3wwp2qdGmmWcwz+GzFoLMQNZlzIwd0I2
Kw1GFtvgHqMrpwkMV79ORlyp3I9xbD9IhiMawC2PUeYbarvBTeS2g7JjCkYr+kNLmozODN9FCOaX
cpOUeWD4ghTV30+sDQaBQh/JvgAMsHIXmbKlFz1jdQvjK0fK13q/LiGuny+t6V7VLaCE0JfOxi7L
7sdHw9ktwamVMzPeuUPFfJiQRz0rUZftPmwYfa8PqyIqWUs2oGPzVbf47mIGszAJmZxLE5pMQHaD
tREc5aDaOYB4ns6G703YTCAYNMqWRqw1vycn9F0p+xld8s94b3dpyiFIodR2enLZ8RxzMFuCokQy
E+N0vncE1EM1Ueye9YubeSADSo6CJfADpK1HfFP86r5rXwQyXU9uZbzQ8ZBZgcy7G2oFQjciF62O
VGZpY18B0d/yjMb2bNjg13T8bS0r3jtKOJUArpVBFTtdg1LEIq4RM6TucxXn6NSphdXR/H9R+UGo
tQJoTkH3pD02p5vcWX1D4Y1Szm63ZEpLj937Ec/9r/T1KIwzkaYZCDbYbSSx7SxGnV6jdpWybncb
fxQZjhB9ondHle2JP7D8Uv/GzE33w4kHL/srmJ6d89Yau9RQrYunOPVUdQroUQEPyrL/jcZ42CuD
5Tci21hi8tF0gYc/T37FlOnHr15E13b80MYrq3boFXrG+sXIHx0tSNtSnmyWv9Js9Brt6Dxj0WLL
/+Cn7Z8Bfx+0zv6EEGVpWw0rOZHqC4+liBnCT43eNPJrNgyHFYnpebC9SRkytcgwWKzkWR3gZWij
v5twqfqaR2cWfOyFiS1fHYrL265PzyyyPK4psk2JRyDCyR5JicEWLEcZei/o9QXZ+jh/9cg/f9pQ
4oEnXcW232nivB1bg0zOuWYDICnJH2ttmDYP2OuXs0NxHAFOK/TiQ9nXdKe+5SKAv6yqI12ifkA0
KDCxZ6kZ1+LVyJ8DntoJNLbr7u2QsN1SlJDVcjgfD9j+WDNhepTMct3zXP8/BqFecsz8+e2kASfJ
BNgDE+3t7KV8JCipbIUPKLy7a5AW0OImcxc9FedSbC3Oh1UThhplZyKXdaZkDxKGc/r/OmfWfWXm
FJWhrimegKpxyWG6hAuCprPV/AoetrMl8k8Tqe1X3YkCpMkXP2edxCTh3t5NCqGyQbL30ng4JLcM
hoqc9elcoMLzDqwuoqW9PpUIz2DQuaA6imiCHBUx23ZFOS4lRPIUZC/IZ4c8KBusAeknBN7Axj95
UNQleYqYwF/QTpSOsiAIQjTG3GM/nMNje8kyZT4ZeVix5k4//21PAxYS0tfq8g/34A1ePhVeVv/K
WnOQx5mcKngfUwiFSrTcuy18D1q3gUT2J+AaPxlsNg2mopxbm8Fclb/P6f6+9CCAm/hUxFH5SMI7
LklksobZGHu2SI8jQWdkn71FtY2PPhKeWLHP/Wsf6J+mGE4P5z9806cr5fDphrfZjLcBA7esYAIg
HDMHMDlPouPW49LyCDiUf0ta0c8AtBSA1h4cPhlMgZ6trF3RipE+BOX3PFamQLL1n2X+t+GTfDGK
6502T/4nu+ah46ja2EcpNVGKMrrsWan1BbZ56EtDI7Zl4lE3Ym5McvT6MshiZ3fD+NseE5sq4JgT
ARMs2AO0z9+zP7NwB39hjvFCrLsg54ppNEIPX3A9FPpuVVOSddt+lX6oHx61OGwvvQ5r3/J2fABt
Slmu7WoCY+LZNbvpzFBOykI5qoOCyM4ukXs+6wIZQ9gX4o8JEOfM9FmnZ10g+wdZiSaZpFKXVv9D
auTQKN+ywfj3cMaCrRrOS7MW/gFKX1ZQFhoxPs5aJVaHO8cqfCgXUFM7N3Mt40uQRwELO9+gW/t8
w7UP1XAoXQx31kPpNvd7ddzoeC8oh1JkZgKqs5cfVrxGilQL0Z3O6uz61EzaX0L/rY45NubSDQ48
G97DzBPzZmXalvode6a9I6EK5bABhKqaJkIN06YJGKbAmNTzHHcY6zMlnN7wSwKqLV3+6A9Uvqxm
V3a9N9Z/UwqBRzC8mRFTIJIIc0YostitgvXcWj7vTcW3Voy/EYwLFtzNr9bayepRXTe4xhNmk89H
PQkuza5ogk2SuxHeFdL+VLcyTJIu3YbcWidZBr/KIlu87+MZlqFp6uKU+aAk6YRPAFu9jrnJwlom
mQNrqBHt0MUR7inQHr3zGuC+kr5HkNf7PfOGF9aZ422/OXhLSwKYw17+E/sDgz22c5pyiFuaM2g3
xPP1WhVsQd7d+5RbOEIA5SzIHhbaq0i5m1MsZwjQLJVW65hdHmeCvfh8vym8RZaKZrDkuAG8WB+a
zoPVhe+nkaDXWdANHGaMEZXXxOuMNuStNBK4rEquj7pQGZvyIXfYqDEw+EDJ3KdkSKE9RCKH6YnI
JNrgY2wNmFm0ljNQnrNYk0HQENL+H/wzElni+7tMMrYHjpTJ9iL8phlrnJH3ISMDq/xGgIn3d4mV
UN8Dv15nAwYaR/kySokApC6bjXb1luvC+MzDF2RgcKPB5bT7MqR/Htx/Zk5qcE9GqjhbJQgkTtow
VI1wHqKxKLxvtU+I1igo4AVANgRQ/OfwBKkMiin5KI5OkrqO24qCe6zhDubRfjy0O9Zci3Akj7yz
DIW1WBXz2Pjxd8W3Pu/oNjYWrXGgEG7xE96ne38sfEv3203RkC749ynby+HGahk3iPKDV18ZTgo2
zqJxYbroOE9Gj8vZ1mfOVja0Bo2lki9aBQlM/RZgDeqoSw/f5hop0MM5RORl5WQw4EwLO2EUtXQW
K6/NZK4xKSPGHyzO+jjhDPbHSZ1QdgOZuP1OLWlnCVtxD/TyaqV5NpM5SZyBa4RIylft2cljLzEo
Yvvi2PmU/LJS1KSQ5rU9N0IyukLYR1ceAkpraM93AV/D1nBSgpvMhGWOxnM74FVQY5HJ3v3EEPg1
9oz0wURJl4eNbJDZVsU6A4z8w+93hHIoKRf2hYRI6YziOjrUsuGMMune7j5IwASv4ojbepyElIJX
sW2BPI5adMyzEPPUN7V4W3cLc6QFJN2bV3D5oVek5vgzCCcfLnUemmIY1gkeNJJEq00Ke8IYLw00
i+R4vEw4reKbyQaxdWSJJja9bZZSx4K3dSbSx36v9P3fB+JOYB3UrvLH0XtBvK+NwSoUHKHWO0TX
y3DpI/JhTix25DV0NByYrzYorSSH/8aF0wkyJ7D/c+3j73Zy5p7+xis5UBqd/ViSrbZ6JqWeZJWk
EsyuBDKPuaJwxlPzPLX35/P8hAlLdaX50l/OrE+sg6ePeeTnuGQBzOkYJRjctjMASSpawtVDzTJP
2zCHyuTa80HDdR9zvZsnaY8MEcwFtG3e3uEYwn/M1hneL3zrsws15Vme531xeuhpmMx78vDZsa5T
2s/3A18/rSKsblAF+71tO6hG4vgnmxZeq9STAjRL8vBMJBCLuL3Wbr6MReURUGYSM1PEpWjnO5A4
fs13Hkm5zCqO9Te8sCrx2r+3igA67k2SMKW+wHpUOFNK+bcLaR+zRETA3zJ87K162oYyOYYyLvwI
CJqJFMM+K24q08Zlp7zV96oQj9oOYbtnKbxHcUI7YW4QMvGbwPLFC6wRBYSR8bm+KV+pxcc+cso2
1Mh9rQ/DjHDEjPy/66JH8mqD6GGwr8CbZneIwSo2lKQ98TTrT+R3SoJji1XBCAEvhSymO6ZpOwR7
3sl7PPDrPEWEUvC85+TukGe6pYz30YrCm+kghtu2jMP2567k2EUcw9zXgbJjMrXAx/Lr4ejkAtzy
3bbBDJLca622/wZqrAzCMdpictGNT+iwWgAz68sWZVacdGOHoatGy9YCqAnem86IbYtJJFdl2gFg
Rk6smAG/ihdatnpnxuPzx1d8bsmOvUXT4CvY4avhhWIRg5Mw8GwlJAgo/rlmKnSxGeOYoSfCaDFb
BfsWsbUTlGmJtxsttCCrofyOhiYeGRqyb6uwK7nvaChLHpNSoi3w5i8v0RiVLC8dhyB/s+f3F6FH
6lI/tQXFWzdK0MM/aGP0v1I3ICaQJ7EY72Cpf7LMWJcrLQRemJCN7ml91RGK24sX7dSCybsyXTtg
UERiwYt7zzsnaBVB3SNdPv12TYPvU25a04Q9WX5qOT/XhdU0Hh1aH0+QaGbI35WPiFlNQp8PMPJ/
04oFAwXVoZvBRnfJLSBRpZjKh52FukOnBRHOyQiEnlQGoUrYvhYWs39Ind6Tk8DESMWonbKtsVbS
pXnd1OQxWn29Jm7HFkWrswUVJ6o5aVfQp+xVSjUk2cBoBn+37E38rNY6OYOMHtpY93Mlr4AH0Cjv
5TUVDoIsQni42jQsh2pUgwR6Gt5z2tAXzEmtEFM1bghnTzn+ekEmRmu1aPDvJrjZSJjG4le99ZEL
CEF3vIdJbDCkdn0M81vZp9n7CIAtZ8VQY0TsQVGEIP3317NzSSo+EunEAsmmRx7oc1t9y+1udljs
N1EMxrH5fsWQ7xNRtjYmmKUzb9rC6F3vVRepyCzJR60MgXfN8+Ra3bg2HKni13xnJstmZKqzz+VQ
Ds87LRuRrZ/GrGZ6Khhx3kVcSNJcsn7P9gCThNdVnz7CNuJvv5iwpNj64d762OR6QvK/c5g/hCba
h5qsgw2VRdYMcO3QZLV9ik2frRP9qc+9aRciztvTVtRfiqpCDeaLIvvEcMX67L1Nfqyr6wASQ10m
+1W+BfxDO9QzlEm67ZmjZO1/EDdR6ZEXaPg9BYKxa4jOt4DOlv9KRpvWETsBLjevOfbGuhvoKAZS
U1tK8WQbNxUiXMfx13I38dQp3Nx1wVOviG03UD4wAuLYTBHilo/rYXENK2bVp5YgnGDN0K07mYmO
bXSz4ZIMjp4NSYhURnlnpexuJdyLverY6MpkDGHE3U4a9sX07v8WoxqC8Hszjd2d2RlXwZSqk73L
LYcCaJMO470rSGqXQfc+pEuLO76+tJhmGBeiAoUs9riZUFPZ+IouASAS+BX49NR5OWg8dFjB96Vc
fQD/Dbrn6XruTqYEOcCr/wmcHKrdnhIPdmCA7eYYTZMikycgCoK16amImEoNqZNUz4I3FrUDpDwC
vGVCfHeqNMAcWXLCrpT5SX5/pUoWznOZg2QM5AcvgYE0JA+7ywvcWkJKfsT+58CHql2vZy/J/+VM
TXthyfF+Ewwu7lLr2krlaKQuLdJe1TCdtsIQEiJgyGD9wZ/dWF4qx+YrRkjpAl5xOGLCXH9hI4uv
DGOUxEDDxjEPa/i8fUDUkCsb/yaUftFTwKZ/vFEN78BNN0nWA6tliMsUzyuT/w91I5482DwH/jRz
j6Q092UaajFOvu9rhRPyvGXAARo0a1jmrSOKW/jyZ+HUyqTaG3TF6bVMzC3qKaOq9R5w6Q/MXm0H
NjOEasuFEzLd87WQkgBAvPxw1pE2/qaD0WAEZQrMDA3Zba4DSVE2z0oEL/QMQOrCzg3Yrq9SxnYY
kdutiX5D0f3CAAlzkIjNQ769/P1pfoQebHk/5J7MKXsYH2j6bZi+zpdUVkUWp2TwiaQZ9NlEiqI5
leA9syK97Oqt66TWeFPNSgdNJ8H9IVf7jRirbyiF+muUCZhJbSiTDccghAS1CcX3VK91asuBcahQ
aPaMQrlGTiIQDauEMwnANBYk9oWTN1KFxIXADWt8GHBN65pZVRqgLltPzgCz/fRgR3Cj7byy2FJS
+Bt+jFN919zlkLYkhLq/4AydpwnVfFiv0wGKvSFVQGCnpjp/xLlLAK1ngy/GKbMkIBfzgp8NlAUy
GXaRFIyP/3unSM3nQ0/EKCfXeDe1QBQap0qs9wA96eOv6X+tW3N+6Mwh61985HeE/O0+auFjo6+X
qq0x7UeDV2iC3dE2ETJFiGz79rBSQ/9o9gGQS/GdIxHcK0fisBvLsm78qsXaH3NZE6E8Ux79qmnS
0+UkleUhU1Ag4Ekm1Qvpb3B/HdIeCxcFhco5ubrrD1TMAFpifwQvkdi0vh8svL3s0Yipd8Wi+JYY
64bgwjKTvVL2ntuspo3gAUh2DvYgB2Rl7QAbrAdsocdFSkA8EsVFx/Lp2FW+o7IT7BwQWJZKNmyv
RjFBX03TuVwsKYs98fyMH0l2Ifv+9WiiEpp8h8JJF8QDUwVsScJb0eQlGuDxkBDiI13eQ1KmQ1WC
QsJNJmqRcY/i7cMjdkMcdxEm9GuX1sE3mIa8XaWcJfy8mmEd+x9VndW1waIVwPCIU7GKW0zFBbga
YVbndhqmlOxPnmiKbNpe46iHJXNp6QmmG8kC3YcHsM6wvCinqJsj+YV5PxRIxyjR02/DWxBpCJuG
EgWwVExI+O9dbmRtN4m7E/5vEBKThfD/GUXpcIw73Bio/ydqXe0mBN7XJpa4oJobC+Osq6KIaMs1
Hiw8qDaX7Cz0JXH21jpxtFVWbMG2zykOqYRNPByiRtx5Q1j9jF9Q9PdnjwmRW13mpKFa05TvQE1v
9kf/JH/wsrWXa4tc2X/PJ/tbxUlKPDIDpg3ZCba4l2kJL8Kk0QK71jbnH27Mz0YJXtoJvxyrxZQj
XZXP/maQGduABga8czF3TxYI8JWVMHKPxFBFG3tE3zSfnkgQmsykIb/VRZjIvYJW94Yz0vBtbZfj
KzBf82qcjARTyTr8njJL//ZqRZm+wBqyh6ztNPkodOCgBHHZC0LaSvCGw6xdFpn27U4pNa3BtWo3
ipvIScMp04cjFvMSu2rrTOmfz/7vpzWipumCCfO2d4YtekVbO4TKzC1kB0slCtJfXJPETtJ1chW1
j36DeXGbP/2/kF8pFzvG3XtEUXcHtRSWq5T8cvitpGfUNUWjDpmbmxaHyS3WJqtt/1ePXTGAeme0
lSfBAEZHi1sWgCWHef5lcC5Jjqw04USFNhPCg7i/LJH6mVZHW+X1og2tddN2Bqud1FCw7lWK/g0J
PcIayGR/4QcZ7Smh+XqvF/a/d02hZWhwdsVRqZTvhC3cRpR1G1M1amxyvPdpZhg4wQE2mHN8K5AR
I1oluLjna/MNwtCPs1+aTTpDZEci2HZ1dmqSME/jYKvKf2BFjiAEWEBnJ0VwRs9pU4BYwgMRNM5c
8tnK1x/0guLdT0cpblpxaqv3SxVU2iSW8UwFWlRu0EPsc4rg2qtNwp/R+DxhXbGMOY6SYntWm9Ry
Ihz/kCVXOGNIngYi+wlLFXRxON4rqyavAsCmdBvjAXfe356DOyD4TuPYVUKvCSgGtMzGQ7FQlhYL
1m74tXTGPAaZMO1KNuIqxN7znAxoThMAxtec0KLQ0xeYCLJKzq65Flk1W9JVNvSjakhUK1jyPWh3
D1Dd7z7z5DWlk/XNxGu469umpWMfF4gQrGKizlmS/nR4uvJlMSdA911eopkfOea04sfQKY0Mhl4f
dnHkBS+PGFDDwB+acqJ0Y1vhlMo/ZF/z+S5MmYs+RdCB20gse98LXPflZzHNfzJqOyk6Um2kn3mX
HMQUzg4O1Ug5m/YISeqcE+8E/2EHWvJqnGSvnV5Jl6fkOJ58BsRkuNhnwAspWh8zEtzB/vUmf01f
jXrJaB0B6kKPDc85d55i2w7sL9w9V8P4x8dtKxGPCBm1Cy2GgeIhEZ9IWCfIwC86rH4q7A7ockck
1LaRySFNp5ehyZWl9TdxbzS3EPbKclsN5HOtkbeqmDV1fz8QMRYotzccMN3TBvgK2jFGXnhmaJKZ
XfwItP2OlzpiTjGzBy/gIYL07mMfhhZeynLYXahKs1S6NEh6XOAMEHPYOPr2oHN41i6YmF3Iv7wo
hdz34yB9lYNjHEvuxAgoA7R15TtvG8BWw2fSPXyoL7ff4/eYdi4H1TSx3j6zjvGqdB3ekOwI0Zvw
ysBPrS9XaW+UeSR0LJ3sf4Jxu8tPsas78A1/YnNwueyoahmOjTk+ZFxQ5gR0+2CXHnUrX1Iduu7z
awCkeDFYuzyjshv0DC4I0wuYPEUwfhGnTER/EzaSxgcPMeEsk+2CdfPyqbiGOzkgiImgFGaWrvWO
kudoe4xtlc3bRvHqqHDkcb64Pr4QcQQBANUM9r5ylnkaAhK5oBkkH9W8m8vm2dOWbnNfb5fam7os
eAb5t2yiKe5E0+O91lnY/yVELFJ3XL1bL4I96d6D1X/ktY4tGWBVCD0DUtPVUuAi78ZFqFseXCiO
H6pq9mlNdhx06SKtCU4cnKqRqp70aDq3hea99z1UsBWmZp/1JaVTc9+DhJ1w5UZmcfhPgxZfX/+G
jmXBC1Yqh1wUqvyLXEVZ4LwHHScTWLguuKOtBC8/k9tvJHocFNphcGIgtBeFr4q7JYNQ93XllbSI
SJlCtUmaB7Rf2JHJt8kWgpwTTh2TLZbTK0oeO7lDDiGchQO5oBmh6zFOy7qs18AF1By88wwhcMRj
Ly+V4fvCW+Eqz2YbqAoUZjaIl2soKz/CNEbtS0YX0yk/FZ6GY4l+F0gXS3tlmx2Eqg7HtAl4gl08
Kst2DIx6Gw3jKvuyAwLp3aUr461K1aQK2lWSNW+4iRk+iW9g5R+JxdWxazLEWDnaWwCVy+Mode0s
cJEJJ09YM4ODLo4y2UwDvdLwWVDI7aDpBFWow86FV231qccZh+PCrKimDhb3Fuf+/YK2XHgw/NbN
4pG7lmNA6DtvJ4vyTHIOZKUCGIAyP0+5E9iqncPYFNWb6QRhUxyAWui5ho5bxHnyDn3PbmddVNMf
cZObtRQSqSWv+YDBjwl7VT5gFfT4Bv/8vqHKB3dJtHhFMCOXCh0zC3GJQ8+4rAIDXHQW61drQkXX
jVx3y1pK1VTw7+3kKsc3kbf6U5h6zzP/8sxiXI7FvMTFB2Cxk+9ykiOz3Zi/5zJDgLqd7ZWQGDF9
RLKk6F+w9LtmD4dS8jakU2+XSItxgMS+kpwceHKykFyfULgKSOpFVzZIvLOleDv8m4PsnKvhVrmE
4ZDwMQoNgD5rgBfkVEiPfa3de6e7VbVqOgii8ebcJNRc/Jwu+gApdX9RowWemfXGNwsINY7JSkKk
HsLUvUeCpOesajeqHOl0rIVagnpnPdKk1HMh6KOEwpKu70Lacmx3Iy9sqI8TkqOtb+Xoy/QId1ZW
57Herpi587e67YxZX1XjfjjQKoW95HjXYajSulbsOfgDVT4AeE2qBEuUV/jQhO8AMVRcfntCsfeZ
8vD3aSqmJE1yXcS90g1rxtS/MFGsQ56uP0a6iOxfwGZvssEe+3Cys2uC962sOViC/E8AhFnyErbd
KB/sA0aNesMqkSSuCstdDM2GX6bwgqJt63L9b4FvpaR4FH4DohkBHNAh5k7gPAIH4AvfIjA2u1DF
SXVJK6pcWkv17WnGV9HknVyIp/D2Yrn1zEU4nARHNHjhIj8VCzPLHH0sDNY2AfQvxLAqHFB7Uvqh
aZ49tQCJCEI0AN+BKdBCGUzf3NpjV5cSIO4UbcnKixMBhl8qdhYiFYZU2Y446ozxbpAXYab+LQFc
U/gndp5LNFr+rbykXlsv8i31d1KmHqWPh37ll5auSskgjwUn4OEEfMgNE1zA0bcp9huedYSRqQzg
rTy/hWk7oOj0DcAVDKfKqTym/D/Jz/NiedF7U8eeBG6mlvSdN0ObmU7cu2Deu9xTUIlNLbniV8pP
uUN6aq1SXUjuRUmymH8EwVVCVQQmv70of9mUx9tr5vR4n7svqUpzxUpJ5fOGrcuyXMJ6iNuxjCbR
k0E2fr6MLEHYGy3rQUOG3bdFZTYLFX5rhcT0wST6AdMAvptpNo/qRUtbe1YHIswOyGn1D+AOg6iP
5esG3s01I0oXQPQ0y40vR1lCU1BDxE9vJmvqXe/bfGo6hPh7uUpe1iCC8VsQYr9S7wzjMykOFJXM
PNCjK0m0Y4fyVGi1AR4uPWZXhvjNq+OFVuxXgdOpVmygmAedv8iGoykBanQafB/ank3BjTp+7m/2
MzfWUfZMJNPWpkUNnJwPJFEy+XBrRBSE7yYjftADg6WAWvZnVO3Zo6Bkct2QbDBSaFfa59+tfZPT
fXBW/dDZJzOoT5xF+fe9iqYS0D54XZlMiKjQyro39fKR3vb4joCj7rjU940+aIsjVEhdcQkaAj95
yba4/q8tDOaH8jItNKs4mGKYlDd+WU6d3V56IoYGCwhIESBaiLPAkU8tayEJceyNaY8726csg7q7
gDHHnslUM8/ivhqrFTTEj42IDsMAKCVX50lmepiM/nR0L7C5odFtklyUqSuLRC7RYqu3BmfvGXH2
LY+kHiI6TaIHe0yw1Yx0dRAn6RPUZod1DOTQT08TSO1AbVdwkYGs34BPMrwW5l+aAI4l2SBn3cYb
/JM/M9KCpmwnOcjOqZpYYZuPCRnoY/EO26zOu3gRDsRE3Cu98/WuiHSbNz2TueObi7qID9ku6e+H
lHXs2m/lgansSNYyntuSfMxb/hK+OUyfiR8wDx1eZGGxJ7WrYdEy+AgxCyuSikOOSgJ701XZpadr
TrcGjZLc7alGWLLpLGD4PsZgFlkFHe3KIydFoX/r0cz89z7wvejDENifMw6R2RHVBFXMsktjwjev
/CvO8XQ+3Qk5qGBpz8O6ZjR5aXnPzbhc1immmOodXPT6mgcMfJt+IYZL1DN0MSrzrIgxWqqpqpPH
qnjE92/a15y9+5sUKuNuEjOb027o0T2LsJAt2udzsbKTlJ19uvXfYkSesWnZK0RDdwBva5zpZypb
n/q/kabaN3VRElP2bbqs9dIJPqjDaVu21C/XoTjr+ySks6DBgrdjL2oKXavMS/nP0rUBAbcxqJsT
cm8DYliJliyZ14P6H3RR1vB0EXBc+h6AvEO1IF8lizeRyGuq7DhhgXmi05cQfxRU9fhLLWsDlTRw
1qt2AC+P8PloUcndbqGzw5kxMQiUeJV1UPOUjjphdjAbb4qLTNKlvJRMPNucBUfIQoHxfwFqZgfV
BEE+etncEsF8J/FQeWegB4MLXDhJPuQ5h2bOwKXp/UgZy5E5F0TD4hVBfan7JxdUrcFRLSfztTd6
ArzSoA49ACF/6GxCqbzDKiJVStaVD6aeJsNAXHdBziUfBHtCKqqfdT19+/cttzuhpO18DFTY+/Qt
wiAT/RA163377Hu+b+uTo8cxtxeEpaP8X0DD9Hzi1LNJrheYKhimHH3niZn9IGojP7PGnBivJemk
wtCkM7FY659FXuz13C9ySOS0X51xNVRWqpNw7xFKYJX5P6tkcFiv9nz8NNten5ov4+X4qD0zyEFv
XiF2R6X2fCCn3jlcORId/9Hh+Q6ZjV0dLjQJcKtqlx4F3uwUNCxZpREG0RLnD9avB10Ni260kS9H
FNWMTTJ2wrnPes/VP+x7Jg2ych4YXIX+Ouz4FLuG2/kskMYgcM7mb8717Csfg3UI/HznJ5HzTE/Y
UqFaG5ISqkkwz4TBB+WsjEL0JkQuXPuigZnIC/e4qjOhTzcTgRPijfsqqwVzlKyihEnoD257nhQs
wQyH0NQeiPLMchaXERxLXh8g8MWDDDZukQsPWnIt25WpRKDNhZFR+iHwIj3F8699CrXrXpVzcDqC
MPZ485RqpqWJbqlPbth9rlrdi7WmgywCFhCQ46FjeICMHZHgXJhetukwpLiap1Neb3zMgFCRMyIv
sG0SP7EufgsNzRKAUwtB9aL0FCfZ1HrGtHVQP3tzdSpe5fVHeJaS+tHPWes3pW4VvFpNxYsxp8k/
JE2cNM/mEVR2pjTtUpyHRxEuiwp4PStPhQhxuykAWhFpw8l0/hAymYklZ1RI97DGdC7ew/XbrfBW
UDow4ZI/NviDwiaV2+yD8XV8/HJepQBqvqEGLzi3u3wrBBYQJYjCGQxz6Vy+tkX0Hd4m6zCAgrZW
nLiQC6sQJM1on0+QLTpjrVOnS7enBNIdUJITv+GHr3INPTY1+l+IYqkQEww+vfxAarGN+RTzPwJh
CN+uLlVMGe48nmSPFtpqsRZzN3ngOwim+u5uQXDsCmJhnyxioFno1FDudNWuRKSXGkPdNLSlJ67/
N2Ijc58uZUn0ULkBMg6/3I1eFawvGWCYcrajGvZPUAxWNW6HB/pYn3ZqlU08NN79ExMkSAW/jMTB
2VE1+rmB/+tdi9cVfiOxe/5Xe33f+r3xKRKu7xM/IQJAV3i/IKB6F/bLIkP12pZEafd0t50x/2eV
VTIhHvdS7iUi5m0tlDevK4vbglziYc5mWj9DAHMHiHk0qoa1GGhK+NyLyI5qDSyxavYpP7a3S5KU
eJMlmd3fcY0BgZQGWlLZlhIsspBBaZdHWEOPjam6z2+AAbewr+aqcLbug4O/z/qtOR9XblR2tsLg
paoz/gzOZptOr9lYCvdltwoyJhEai75UMQZTgMwGLxOffPQIHuRbVk+hO4JQfOB17rU/cEcdtjRj
5/CnWHZhWSnCRK18s7sQ5HmqeL40bEIaCNaz3Z7aGf5E3n3tXv0EDNkSfIw9WqdH3ZtkJ2wOwZww
RkENxxCl4jENp7NvevLTh6kLKhfgTPCv7p2AdsO70u//5Wa1IY0TPK5l1MmLSUXfELULyru2jPlz
JDiBYHGY4rJA6u78tvWl0M2t99OuqSOF3xT4LiByw/+NeJ1mJmPlL4eCRJxPywmOt3DE+8K6eWaZ
h0YmpTmE8xQebbAFBLT7vgW1qbTqhm32Ez6Z2D5Nzz6B2OQ1I7Ag6wDKoLTqsk96NaHsUZsRpwHH
nQ7k1mnEBMFbproSEIPKDyKbvD2mtN3Xcq/F7QxDQQgXwDAVpdjddrVbS6NMGHIFwDpNazcB6eLx
k8La8GcFKd0FnOVhLkBbRMZujm9p8cmYXqQYxgvj7WPIEmbiaGtaylGIhn38Z2KBSaXZu9Pk4zJ7
G0MekSxms+RTZ+sjXIZx3GhvUX9OHBA1DS9kRSd8TfZo5oKmlx4jFC4kb0zESkWiiXACL2zvVPGi
Qo4EDv7XzbkaMk4/xqrYq3EEHorXgTWwbsEXQY/YUDP5eeJXnuOVhiXPXVuFqsLz2RsnVXRUiQC+
9gmoJa/lxRSy5mNPDHdoFtUwRvTjEeAGNZWmEK5SGMiKUq9nyeVhxsDG61h6pX8DdnAC3eWz5wiW
RtRV+pFdrlQ/BJtXhTqWlq1zhsVmMf8e6mYkKuNRdIdH/9KgBovrwm+nsEG69IuaQYXlXsmGrxX/
Z8BSsjrNVE08W2iTSfAFt3h9XLnHRzYCIFH07UVmEiKLPn5RsP0u86PQsHfWehEYL+oO27RuPXIx
sTRCEsDG5R0vq6Ra75PeUDewMfWOVyVBtxArXHTDEOPw7WwWrhaVaWRrY88Mz9jmor4/zWCqb3U5
KHXPHL1+56A2xxuSA3ZqgjTM8w3nwylZ/Rzu1tHT9aLx4/+T2O1FuNcJ/HA0URkWgeBq+2bgk8uY
8wdYBFSNtki/xyyI03862P730iClbgqwNsztK+xCJzvtT2vxwGBnmIqOVA3iVSZ6DGMZdVPciH6L
aGlGvwvCbfYygEypE1FYwnbAqzcEW+ZEBz8ADnT3059ikFWL+U0sDczXvGTZ+K4xBOAIOVSwdg0E
llUeYCd/WRDoaRTOlfAjm8isrqiIHUvitFsq8PFn9pJ8vi24SRkwlKYtNFAz9UEFDzJyN00xty75
jfC5PAwr9hKR77M1eqxunbWuIkhgV9m6sVPu2MlTIR1UEXccX+/Ttk0kd30lJYZYKLH+CLPHf4o4
dNFUVxeMhIkOf9QvTNsQ6MMMgD+bcJAn0h1W9uLk7LOU/NioQOKfTXwcrjCMyVS85fGXKZXi4IF5
c493eq2c8Tm461DXZ7oFbDnLQ3qVYdKW0SYf3+Ofxy6WgPVpCsChcspCZVTM3HFbyAnR5JzRRdmr
g8rEBvv47q29fg5lGxN4m2K3lWYPUfDi0NTg6nrd1bskeERgVFFWMPgbA93ekjZnnRZ/YkMZezAA
9EoVkrqcpoX0fqIKfEp26laFK6+5KtqWlnGjqrAIOqsliTDtrHu4CZ76GDRT78e3kxCi6EU4T85/
GsKlPWJm8IAF7qbW1Ck/u6F0aBBA1mAXRwquZN5ipb0O+i3Wm4q5Rm0Zl2FVXw/7F0NMgK6CgdjL
6s2XiqLQMArrglzVBMwFdQ+MBbRtPBDBn6Kgoo/Y3STYBja/zfUu/zoCUuSE2mk+JGSzUh5Xxrwo
ceKm4+VQqFUfCkx2bEEkQCwhzLEppSnDMkJIaQ1K9uJXBTc+0B4EuGoCDJsGZDKoFUdMwfX7vG7E
xa7/1p1aLt9nIp3w2RxfD/dvT4qwB3J4bAQDWgKAEk1DAv8+AtrEreiHRsph2kXYrbfs6xzkY+Je
bby7VFCvkca34CGISKIxfTDhIm9LiHJ/mBHr1dDa4ZP1pYomdPpGwiXJ6FFqCKJmp6h/jHp77XpQ
WrfXOKEmvRxgSM6pGVLNGOTfiLGeF59Ux9lKzZRpV9a4FbHs9za/CXa+/YjdY7LuB6dbbUz65c++
9G6LsbJwVxK/RHfRhUTa09lLTLgR0jifayfjGpm8Y3dzxMuhXuAchhLpxtb8LqfA1iYKc2Zr2vuG
f2c98i75rzP9cN7dJL2Q3BE26uh9nIfeX/Ik+d6sdgHvHAr0f1uvW1yi9xJZTe6YcNEf4oIdvxwV
uhFx52om8uJS7O5uZqYNLxjEuz57hDBb0T+bmu4k1/a7hG52RM5v6UMGje9cNIIeFszBdnbyr8jB
B21/PXvz+NcHCKmhdzEATozAyROpDc9PmsWwSk9elbwyRijNasNSNP+FCljk2j8Mcvmlug9JtjuV
2nRYg7Yg8RBfuec/aT456YuKhbiWghNLVIvYemnBxmmuWQJC/EVbPEQkzOBIwoteiWH17lb/WbhI
uwv96g0TwoErzCgR8ZYoebu0IGUhp9bf7eYm6zQnSibKURtoZXqCAnR0YiXMeY0ucmupsJ+p62D1
2PhHDXCUpQL0gj2s8Pvp2vXfF6sR4f+aYbF/Z1Q+5vlIO0ubUD0KU7jmf8pehWQThCtMSEZBdA7R
wPp4aIt7APoel9YaVTyNKb8m8mgeh417ZYqu+VBdfY2rWfVG8VOo9CLYIffQBh2U0H+X9YeyJCQB
u2L8BIQZHGAf12GRPTaGeqN+R3gNJuqkb61DPl8UGaxnwZDCRrYL3fcOAYHfQF4roNmdVmX8mFDY
gT+zwV+h6s0nDFO+iPzqtXJpfIr+m8HMX/hPmnU3W/PuviH0/4Ivo51hRa0UMOP8Cr3xGjEWpR+m
EbHVtbuRDZ+sTBFBu3haxihMNSUWV6KJ/a8Xe16rJKcEyNRe2DFA7gTz5tMEVfRjWF8gvbPS48pr
h3HSENPg5wcBYJQjGmmVN8dBA5PKMsRfiv02VEX4Rr7jqCFEd7jV6e9yYaGFQWusdC2b6a4c3VsU
ruLSuIJCuwQYt18IaruP037OTBEzniGCwpdKkGfX11oj7dYl+0mjJVtEmALmH6/Cu8LbO0HqtYfd
v0ZT6nN3w5AqTsnWzZEbcoVbrTWAfQAG33tDTRbeFM7k+Wjlzz2qv5VDqJRdqa0y6tcsV7dPSIBk
buZjHLks4ICjygvnJBNOLjJKmO4nJ1Zb+vL1FYp0j51g1j/2uscnXqDoSBjOw2XwlaWw4Q6+4CIp
m9FE/zkr2bHCW7OF19yWk0FvIi6og4ZeIabFKmji36XTLT4FCtXYgItQ3r4mKmFclQ9nlYcWCqQZ
35Hc7PbbBSY8Q4bUwlOlPW3mso5VShofYcvlkOzfDgTBNgjeBMjtARKbeQiME22sneeOU+ZZVyAg
oiilnK1jI2tHykwWaCxgZg9SnVG8oIZqMNrpb5SMF1JFkMlMscPcnddeTnugbBG2cAirAKVXs2HA
0S7CpYxjdbRziKqu9zrNQS3kjhMxTdt31A66x5YcrunC5YK6CVxsL/0WweZrTTHvRdfgrSWo90D9
WkGcv/rGKHg4N65jnf0FiseXrSD9bERI2wbvYoFI78Kev6vdepjFkOceW37uoQUOR0Iuh2T7QYsG
laUGkcwickYmB7gKY1Ir/Nst/v36i1vCSETQJ/Zc45rk+WkWb1HWBRG+6+C18Zezp+ve4v3e8CE/
xqjWK4z9ZOuP+wbxQR2jn83cIqbPaRHfaazK6IP7qQTOOdZ+9ekhiABS5gm6KC+Ei5DB0LGflHPw
fDIiGuOfNtsSmLbbtQggEgjGt1msg7YJZla4UmhFxMWNgIjwJV8Jcc06Q4Oueoq0yjl47KZbUbZA
Fr8DN31oJ81qiZ6fMFsReUvIK5kO1lOEjIXxboRVWK55cJ1yuxRHJNltwI2c79gQng1J9cKXKauy
fsgYIFtrBRQB8K4waYUkWAkRtaldCJ9CbuEPxZt3n96NTJ5CvnkcvH7hYRLV+ZHAcGBS2xLYL01z
1gD70CxLuSsuKh0Ii6pj4od87EbQBMR07OSaFh8etE5cUq8UFzy/Fn8s1E5UAF4/CmVzxvSgqRv8
nPNPuXjZKCAnrh+93NWxr+Ks0MU/6pToKX2EcRRZYKpLngLP43CxpqrghjTG1jHsmKc6MgrOD3Go
PXd89fdTlfLuEhJOVCF4xNx4RtLexLmJatXSsWz9wbwZAMnezeZcFm1BkOPOrONTmvvZWHC3lOpB
nsvCvgB62Tgg5mTUZ5Ir57MBlkUOS6GaalpE5zEtTx8I+YnnJohLI0JUNXTfkq/HgqSFlnE9F25x
T6pLZqhLL39uf6jLmO+PPGQ0rcAl8174LighT+4wJe4mW5YrBxx705GqSUk21HL1wIqJ57+MTnmw
3GiVnS46fdyDYq6GegsihmxjI4j81/fEnhHbOS0fWiqj6rYh8EdZNRGf3XrGWqtZra9EgE1RrVJp
sfj0n5sF38bloweotfGBMx/7c20ZOOtr14C/0jWk8lEsVSMcl/TX77GuEkL+4Vd7UNNrwse0zGYC
aMLbB7MHDYagyC65T+8DlzrJ7vpBD7tKcIV5ZOfcYsP3ZSUA8spiOVcc4yR6sv/4vI+gsThqObu2
qLzJ4LzKCFAYhS1HrxgVPdT+TRt0dZ1HAAuWSpyX+IbH4jXjKyN0jy9scpIF+w6Eduvc5A4axvnj
mQc75oHYojKfL364ERhs2iPibaxkKnjMDgfQ250RG6S5rvYHs9H8hU+o00o1pA0aDOtJ6CfPp0u7
CBlwLT70ee9G+Zjh/2J9XOigMrAvhRC+OvCnsTRUzVDM1Js2LzSGc4t3KSxoPzt3hAqSwFFAitEV
weN3skHut8aANs/4lEwO1coZdillQP2ryfjnC/JoW4ZalBWR+1QaEVsGY202G708HEyEBhfbCU0G
fmRFvWsr7ngaTJVyUixae6as0kchnpYR8iFJ735USwjxDmFmQMlYKc9vLR3UhTYp97Gchx4cRvoW
CRZ7w0a6miZYNf6mXYI6oXN08TDo4pbNU//89tDTb98+VKnuEnYXo7s3vVdRE4EsFioNRrsScu+S
tnYVgGKimWk7q/XDBuFwRkZoNbz79qrvJW/TdAbKLresylUpFnS9T1psvldsWiNmU6963BM23cyU
uTj2GTfZXk1QEvFLwch6hv6UzYX+QQFFzPLE3V22DYO4uNXeWhZdyffUj1IkKwPsSwkoYR+2VO/T
FiBSVH+vEeb3OQrWi6aC/dBmosHZIcpMeehktWFZTjjdTvhGqjnNqPu9mkroJnkzsUne8XBGFdY+
OqFuDliJHTjWQQe3o3Ojpo6JvXUmpJr41rq2jzgA5PbjFvPauLbWhU6eOZQZpJBwPJCEC7vivWYv
L2BrRcTnbAuEYTOkClq2FP3CqQ5FBC7TiRwMk+OtG/1IvXZ+nRmTfthrqG9eFRe6m/Ohjkky1oky
CJjHVWB+5mz7D9GP4PH36O0jep7IsOaoM7RgpkAElWtuPuKc3HHWGHtpBQ8jO0oByQ5Xe3fddn+r
b+5je+aJlly2ybwOYGxwPZN0JDE8wlTc59x3MmxEKusqmKEgTtivQbGMBmiHR7NwDHzfHrpqki7o
Jm4QljtT4zlxxfSAQzuC1NVbpfWF/tmDW+FjD3AAEsW77jar6gFKCvuszRLcdkLDmuDQoJ9Gig89
EbEayVe9Ca7qHJv4TilySlOuki/d+esRE/BIITQwUQvBiD6jqa/0V2qeTvm4qeTsYM9XQMy5IGD3
Wfx2cU0u04C5QoPpH/Bd8jGkadPA7fD+7t5dFMkM/t7zAUJapOUq/0vhfrPBxRMYBtPUAZqruRGL
J0/rd/MiTazc4tdOfRvNNqAVVn4lTJHvG+c+E6QSc9WZStvY4wZvxnYYOmVkounucSvFDzbabXtO
K0FS9UbkOhSxu9w51djnKM8K8srfwtL+56kjeJqPoXtJNmiXuBDLxq/drOmdU5sUcG4skpE6H82O
JBftOthMPtNmHrcP83zK8WBvqPT/RELbvEc1VFDe+JCPs7Z6vpPiQ7jXzt/Zq+0zEQdUxlMcRN7J
y9v/ZwW6oujTSvgALxpV3l7rr4y+NSwcnE8JoiB8X7JO20w3QAclLfkRTmbnYGDIYzkmLoax10Y/
Jb9daJiIKSWaDWVuZHN0cmVhbQ1lbmRvYmoNMzA1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlIC9MZW5ndGggMjE2MjAgL0xlbmd0aDEgMzY3MzIgPj4gDXN0cmVhbQ0Ki73b/I+xsySSrhiY
0LDOsovVWfdhwgCnpRQ2yBmQpSQq5UYKNfvdPuwcKh9BnvJQeRvlCTTwklEWB6sIq9RoGrb2bSCD
kFfCBPycUk5xO7LEh/yVCymuaZ3lWmzmQXcUXFU/QsoL6A2iPM3B3B05Nk4+VXgAYZMulexIu4Qd
3ZOeTsbAP9uQtUADqeVPTjEGUp2BVYi7iI87O/oO5DnEJYMl9N6Yds47ovotqXLUda9D5YYs0v6H
+slhJ602FDufVsXHqgbX6FGBxxlJOLifDpDlymaSkAbyB5jRL0emktmT89261QXw7+QEqKegzSBv
YOBdrJsKPX21rml24paWDSVQT9voHwf7WfnfS5V4zNinHPOkQ3lV3Y4zaDGWfG2/RIh818aC0GmW
NbJCa6yrxyXDnCOxomSkRWVQjXCvA4p4VOkq+xzwwhJxNpG/lnEsl8mcX/EOf8gh4NU8ZPCUagpk
G5l8PFpC5dp5ulDasWJmU886Csj0MloqXiISBdc01N0Yl72MBUV6kj9clc1sZShAgTRRcCjX0Vum
ecKH3sUXgHi3E0smwZmjS2QubSFY5Dajh9EJjBoj71/5VzgSBQmlaE+CZcKDWcklVReL9+WVNEj/
T7/Isi7A+g4U+s8efPVkmYFF/DRasgRtSQyT179GIAQF4tGXymlu5r+eCgIAiiDxXRoOIe2EmPm7
rActyEQsWidny9ZkH5gXqQc9S5gkgVQxUPK3DyM5s4iLlvmJTDoUajPqGFOrmV6tVvGbiEPs9vMo
mBpHQB5eZhqqoD7miSoBWRHuMXvElCgyluQKepj9NrNGlSbtUG7BlpVm2xb4+cCB2y18YPzmmCMm
Q/FNcir3N+PSf+ZgWVuubiGVApHbCSVOj0zh09JWhv5R2x6e7UZaF6tb5j0M8yGAulM6py4tEBlF
VqUryAfUmJOxVAyKOlxoD/4WqK+CTYRBsW2EwpDA5Ixe9LS6Z9nhOFoaHBCJ+DJ8HwF8dtr4pWvZ
sW+FriZl0fF7Ih2+dTiFN575/95x3Jl81hLLpzz3WLAxMhC1dQSTPUYex+FDa8A2mob8WLio5rKk
mI4URCsONQzgHuKwNrYZWV6ZBssnXmGCklDJF5DANQRG1y8UrRVeRmBtC/KaqS4En5+uJaMdYiR9
m01jBijzWsnPbhkd+eZ3xMFxuKoP+IL2gk1Lo/ddH30CZ7ER+Xk1N4s2wH1NLoYo3YoDEElMctW5
o8FiHGsrpdMLh9Cdn1rTSAslcJfQkdDcr5LOQmR7STLPsjtEnz9LhlUTtI2F/PisZhYXHTBrVx7G
uSZxMGgAvY4+PlqEv5bZZt4poPtexEWS8qaZApK4wWfaMnv1fAF+T4GgoHKcblH7XbU3FUPx4hAx
HDx/hly6tDYewqPQZNFyA6T300OeEiTbr2fGp/qoI3QbL9SwyeeZXzXqL0tU1MXBtUwrgaYhPIxW
Msio9vHuYEtsCJurUkS9HVTP6duMx74/E5yBN49Hve7OS4eq9Oky3FVh3E4kMa54p8V0FTuP9o1e
IgHTh12krLvaO9D+Z0vrUosbb/cz/9UiJHTbWaqkkegU+/KJK0Ab+/0HObqYjnHCctPGzmjPwzo1
6HSGtmt5dqkgzQGGGdHgQsdyjcRnnAux6Ad2S6iMjAA6JLwMccFOAqMZcwubcIYQ3TtaVmuH8Zav
CXcxmQZwRIv1LNq9ubEs3JAk8mRNoPFYCHo+ue1nqHMC71nT4tiOhWsjrL4NGVku3tOQWVd9squ5
9giRdT2+cWGljTL10vAWF+ac2HWMXST7a9I/tdU28uGdpC0iR2XD9rtpjpzU5JlzJjLLCQS41Y5F
L/Lpyh95o3+6n/ZBuPgAbn5y/jJCj2IIyf7cAuIaqZK08ebKwDGVrONEVGOjAxUMBy+yiZbpPdd8
fh6q2TT3p7udUAVyVBmIGrVBzRW7LfO9dEY5HLvzi+weodPFE4n2PiTpE9NtZOyNwxGysJxSns7I
jFcgB+oELHuVzE/KK/epzxBPbdu/zokb7eXPs589GRuLkRdtVEYltrZmpZDvobp8gTpfNzDec4EO
dR9YkW1i3/fMnBjNW1EaoZElwpXDz3+hmbbwV4SshPO/okD4vUL9xq7ty5+Vvdr7H79vTSir1zFt
nH2RGCep1iKC6QQfLQtekZwpWFhix5hFuj8jOTGbxg3W9g/iSIy0dKvYt85OYwUF9QL9b/AI8a3e
2fcwxyU0prpA07GyGgDDgtpeewnUF7KMtIACSZc6fNZBMQXlwiHB00clS/j9Bd3B9+O/CmqmeyyB
giJgcpeZQEvqkC1PN88YH3Td3T8N8M4jSSvrzhOBKnUhymLwIOBZNLVs0HiesViGwkWRqIgWHSYJ
ApA6O7KhJYQKxAVAHc6kBBKDytbRJihBicH73Tl8ioajD/bhnZdxiRbev5q34dREUNHhCP+cWFfB
BLorlUWbXu81ujotNm6dNVWhj2b7NW/swARXByphjQDHv2IPEAbvBwQHh2ylsHY6RWGvUQWnBRME
tV7SVKWv7+oRgUo9qXnHVemnhIGUbs5uAUWuAdc8tNtm/ZPcG/0sFl+MREgO2roqaggXag8NBqGc
ySd4SFad5ARvyO3CwNy29deS7ADuflThuYOwb2U7uVHlfu8odurKy73PcLPSedZDgDxuW/w+9LAB
TphgQzw4qdDTQSJz46lePebr0OJiFgqeKukrdOzCPFRcz2VsqExr2+eHlwo9ATRduqSoVqIxUpb2
cxRL1UjNMLBkqYCjCu6XBNcwgp6ZpxgOf+gMCuYMvcx615r7lUMSqEg9tVu9yntw7Yda1QLnC7EW
r20pcRoFvOy4eav3Nptv4cMOKktgzcKdL4CjJG7rGUKYATX4yR4e+do5DBrrXqX3NdMyYoRfyogN
iTsTOpjYrQJURUQMJs40ba59LBqvoBBBb6x9HT3k8Lf77/szmVsD0xj+1A4zQ08NUq7DsYISjOdk
P05xxHhz4GzP+xA/J9Eosq70Y8+yC4NxVq7l7Vcxz7I+zZhselrrJv13QHG+Gq5/4/uSZApPBXUN
RS0UGt98jtL9d8wEA1EIiz/E8gOqJa2gI3BzyKgvLUJqXJA+p4ifjSYr0W2jhXyBrN5TJUxtwKsR
Tiajw9u/tw0yIULFoz9JJHqpR2ooBpTbxzEw3UfnXfZ9p50ydQY/5HZ6YxfrFE4Or3AZ9zTavY98
2uFWd2lPQ4dlvTQ13Adv21iP070JUu2269ysJVOwd9hEdE4F3CtSd9lh96ce8W7tbGINDx86aF6d
nXa08M1bsb2ooXGu3ngAM42FMd2rdi32nGAMO0RZ5Jymr33udPIrM2WGHAq/7GgHMQu9wxUPfwqh
MQFcChAmaMk1ktbkv8FEKao7CiSjsH5DzptiImxuzcCPeWpNEW62JDIdII2cYwFc92ntLDZSU2bI
tauoLbbX4ycsqS0m7G7dQ4BBUw1dtQdhKznYPc4LIqxwCr4njOhp/qHjHZ4DTIO8ZTjWcHsLScYz
i+mB7K7lRjNQduI5b9ThccvxdroACAFKjVsVPC5oSwHTBJw8TdRjuPmjyUYJntcAArhQeSs9WtFW
D2kydGO4BtT9e8CCt+AqMdbMQU7fdTWgywOaFvy+Xj/e7BHGVwMQuJnlw1RIGU0PvL9OWqdLTVqa
n7Qp47D5K2C/6hME5cmAdYkpMJ+NruQlSuSOMcZF5MpAOedSSpCBhUzqbPJQnATlfDNXsxc04rp7
fGZYRs11doCrrj/6kKtQ2RYNkeznwFikCUehYPDaz4cwH0KhNch2SA7v9al8Q+MlE8FZo/oGAPjT
zj9u6uvUq/AQFlZQyDr3cxOCAgP2LW0UfqxM+ZHzsfVR0DWBha5U/qNn4XMKH+WEWRoQy/IREN3W
YF1CpkBxEMRCGP1bdXvDLNevMmJRWPH547Wu/RXM6zdr7EJejS6HYaDem15ufqxLHkf0XlIfiKtG
IlZQj7dmbqK0IKjx8mUzQmb1bpBO1doc4PpvB2R0MkPDJqZ++dKvjUF9labQbP4cEom/sVDTzMUA
HUP3sTjJ1x1MGXOspQYdSFOq2+OzFo+8wmuAAdO194dAB/5WDiQbdGSGrauV7AaReIx2aNnn4c80
TPJpyoT0ke+qJPNZuNOa2SjCj/jFIvdfqCY/wpD254JiAPpx8jKtY1YQn+1E6ChU8+ksqQOEwxJJ
8r4fd6gH2Bc3s+xgu/Yo355dMTnOjxw0ZjWleHLtyK1KdjPb8e2mlVUrbkc4V7oqPyZqfBkLyWhY
5fNRJn9NBb3Uo2OzbpJcuQdsC/JujmpFRl16mlxVNM2n1nihoIUqMNeiH0tdxPJN5Z7idr0nYZ0Z
gfA66QFzVa5Pl6dRbnw/xjRRwZpyBxtRmDxAJCejg0XBDgsH18tjEVWkOpStzbcTYEd0sWtTM8ue
MTqpGTKwewzciddZMNeycBWOtRU9JtGSmaHvcrmbeNzG77Eh/O1AfkkCFjNR5Xa0CDThQE9SIqEh
WJBTn9uXc43ZYQkWEKsLDmCrg6AO6gBYdyElUweQMMxRzeTQTHs9UEdKNwCITB/4hM5j39HIf/Lz
iDTIx/h+4CYA7LSpa80wUXrU2xjFnZhC6K9b+40Z7WoZ9mAX7vmJUQjry4RRbcEwmZV6u3N27rRG
kLpmSHHfBnrpYzWt3gE7LbyzjKpp8XuC+x39KZDp2HroLsleoTPsGGJICzjI5i+7UmwLDGrXoLtu
d8JMlVpNSAxRlTA2yhFbsrSaXS/0wk6ooqAmml1j04kMffiVG/MvDziNMloe4TrqYo2qwh2ETqWq
RPdWvlJKupc66jwStWVdqV3b7fpCssDlEQVs5kZ+SCuhR2kqDmYR1H4+ggTmPLHIc8o4avovP67S
yPzSSyvTtm+67g84VVyT4wQKtyKoTCssZs3E0v1vVHWIVTZwT7rFsO1Mn01fBtRd1vQPaIrhL/lU
a+EI0BFh+kSmZXSZ7EmRwTHUhbXrwqCGj0MLtmWwKrpLpeFmbNRLnouBP4zpbJOgSAO6gy95w2QY
ulxIdvERpa92E8Ny2bKl9jLVN9JrPwS96Bj4TNnTgN8mOsMsc0X9u0j338sTag+QZzRxa+r2UlG2
bZ3+VdIoG0IOGJqlbjhA045WEK1upa2DPDCo7xBuZamu+xOQIqIwTBRFfmCGIGXTFDbeT9sTtp/e
yPnuwT4LRVee45yuyf0H8v1rxvZ7hvzhtHYlQlMrAHpp+B2IEuV5CM7jpV76hnM9SA2RowHo7rI6
vekPuOhQ4bYFBA0VY4alAI2oO84bZek5v0LbHujmcbrsA7yFLTr83hrmLbk99cV5BVw09NfGIlyY
KIL/QDVEjFJhjqo/mK92nFeVXXhNxJ19mwNwTwnD0aLW1sjV+X41n0tTz36eSbPSRDTvMuofJBO6
HPsZLZyxUEyD2rcOfXkpLFHmlPt7Q07F/iA2g9XJhlcxjFbhlpNRSSvmKDHJdogyiAualemBW8DS
swDyG3ctNDlKmXFcRgUghLoprmHfQfL5Ev6ly/rMI6xRvx4ZC6PrQHLShUgEJmkXnXRzYt1O//qF
KDL9wzPNw8fYcYAbUL/2D/OZD1THP5CEJxH+CVgMw7xixltD/Q+Imx3HvLxXnI5kYiLEN+jheszk
en0b0pN21iEyZU0da22odXuB2v1W1sK2F3X563/Y7j/3hSDVRJX9LJ8oVCUYK8ypfzLvekxyCGHA
jBekxGdmHA7JjyWVOAbl2PYzkkEgB7v0qNCUfvzEjLXXTV/h0AMhVHZbFTTapW3up+xGfBtMzrHl
94kL5zWC7viP5x8Rw9R3FAWR0S74Gtb6aXal/FVb4YCBEM+QSfAKf0lG8FcXRKg/xLrzConSt3Yz
woDPwnHdhpxSN9Xq4OXo9ZYnUoXOar3geuzhl2RILQ9dvdcodgR0+Eg0uka8mUut5JEzo9Y4utjt
XxPtKPMyVZTaevJsnZJPDnNnMxLHyeMmDSxTGdkvDKQmUr//6JVft1O76nOIpWMbg+Abg3ypHQ/f
EGFe6lkAz0iLSDB6ebAevTTUtBoH5eOqkGkEuwjViDCxffcl5PN2zhlIJiZ3Cvl0X7ElWiJklyWp
FqEIg2mG1rLbAvN0Phga7ug+2jhnUyLUYTwN25KSRrtohrHGvNVB+l99buJ6bj8JXJs7FA9TCpsq
a2z8ZcraswA7WifEvmFmcw2rOGJsO/4L3eDZxFdqGB47IAo70E79EFHXSCvGpKyV8lbZhpeKzhkK
6zQXIeOOZnKP5URtocbBjg9maAqFBpll5OuAkBfcWyQLDHgfJ070Yp2W8q3F+lsZgb8h2bIWUE5Y
t97xXuACAoHzMlQgs6u2wQ5LyaG2HeR0SsEM4ruPUbGCg1so1TPoJzvX71vlq3hra97y0fAimEm0
ft8Jp6zRx2je3DzTWCZMX/+W0s6+rNmhtiXwsCOGRx7uGmYH5wj3oADo1BH0dXFj32MGA+MQ/v+4
N2wDRNXsC35oaHOHzCqksMFDP2Tp5a9Zkf8e2ghD+im8r/3nkg4BRpbEzO2hc8SPCmk14jqv+wK1
wgyjtS0UtTeqxRqd9HEFcUjmPjw7SYVLCTjE1hxnA9G5h2tffD8/Eur75/TpstLucOyKvkwp0wTL
jWdtNeTg9z2Y+EPuhS6oAwaHtpAPTSR7DFCj9emrej8X+Gwylp7U+OmndLk+S4meCcTZO/63Up1f
KNdM4LC/Y1WRFNGLjmAFGa2cNv/n7WrzlSMMOJCZW7SGdx01l3JKP9XqZ+oI6DwMf6UzwdxtA0w6
OTVkrble31KZmnGGsCznOVefDG6Kk3WHNJ31vVdvLVv6WJY6P+gVHWUH0ipKxm1taV8/+yyqwcu+
WFxGbGhPRn3kdweMuHtLe046xHsAILk70hV7Vmw3SBMJrqSGpCqhs+/y+Kf/GxQ/3RuDPN1QVexZ
e2NMpDYaYPlGSFODPfv8ae0zQJobTrNzigjYiwObwbBHg8y0lu4Cx8GHlFoAy15IrSPLG+lliPsK
mGTI3HhEcQBFd8U2v+hmjSHW2luBOlchIPz2236XivZZNHdmOCTNrPITLB7AineNMIHoXrEzMxUc
YIynpmMMnbx1fdg2wQrB2rAncd0ECbgeDlh7gZsS/FNFOpVgGGf2VKXs0KrsJk1QD0TiBAN5+zMk
WHlCK+N5V3n1eNakQdOwILsdYoi0TSQBfdg5sVy1RVa48ZRVVl/b8qbwJv6KEesHK7S7r13NsBf5
z4CoitSgan70vD+ij4tt5VnEMmLWWamt37nIxPgl02LZxmz1t5ZUJE2pIZ2Wo2yhfY5RuCE6WKxh
T2X69vA8FeRoephlZDtIoEqs28Ypd7WLzWEn+kyY6tqYu/Svwzjspv/wMD4QdHl/8QhaXuAodKlF
XHhY8GAIDhiPggZSgKfOdlI+liHyUJUwXROxjOBADBR6UDahJBbz2JK6Elha/B62TGvcUlJ69Yh4
wTAmJEH+LOpkDXgxnvtXAjHag8/V0fcNT7PZbiFaPjKKjzMms8YZjxTRdVW95EBLHVe8/at+iF/b
JI3Jcrkc7JOxsn4bgQ+kM44u0XiBY8KRdNHMMerrkhjtgj6oLUVZFO8TF4Gu3QeIUCCFak9K8HyB
CEVpKp48ko53iEr/t3jAO04QijFFgWofDCdDfX5+rxy8K60AZZm8RbVelRfR59SAUx3mSgnJod8V
oKym71aJ9sKR9OXFCAQas4rA6Psp/lpVQY1SA/YwQDLCdcCOv53FCyZ8jvPkLWD6GypUc7QOOp5u
vvVwHKAMzJtdkaHXOrKtuEFlaQsEH7CZSiTyHsvgX0VkUheVd7u/VA7RkeyjUc2NhmLMtsxwEcmZ
4+/69cqWoUQCYFJDXBjW46q48pO/N0DX1nUHVgU9zqwrCsY+vwe0QvtvKbqsM+vUel58rcTojehA
fgqJxCVK4XpoaQ44UlnkQYo7SYU1cHUa1GXffkUQzZYby0LM7ndWrP9saVmSkqavtQHV6bKq1hUv
VvKuiX8i6ccq3e/L84ALParPDZNHHj71WFQcSWcF9/GdBeiALWpgV+G0V1Mdkhg7ipNI2xhKfryq
9PeW6bTl37zP10c0vTGi74WggX5RR3I0OEMp8k7XthGEMKNNohZb5Icig+vwe5X3yNm3CQQC7cUd
ovTzOVVLz4V0XJatRJa4/GPEog5YprmwEE00e9HA0/dSUx33DlWrfxtg+fKxtCd4Z+FTzulUTFbN
efw9QpUJfbwz5oaZCBTv4MLwIDQew4dunBOUTl0xMTkkQU4UR0P8HZxzoMHDTqPA5axx+TMzx5Am
ouKi0BHU5Yzvt7pwzXILqroWap23ZheuNuC9NeJwFTXCGccl/Y0dUDgVU9Pi444yYLvHwNfwCecp
qoCkdR108NPE+rmQdkafPvvoab/tZUpjfs69nW5XzZ/WK7YDrwbCeKaqzp2/Ri/aC+le3tUei+7Z
knytJnfKU6tPYogjfhFixW3ZtXNdcK0LhTpZxG0mWEwILuPpst9hnITBviVNWhshCU1uxjlJX0vM
r0ASWKmPaIXoEpDvrT3S8l326dCHrKMYa0ZP7WyY1uR2Q6zKBFzBTHT7RCzxzbXHxcXSfm2tNn33
leczLm+bX6YxI84WOOSzpbMWS5CrhFKgYeSpWa9CtDkul34YldBxPvYCqnPho+O8sw9aRpiXksb9
M8PQWh0Us1/5kGmgCsY5+Ktont8kObHfZCMRzZ9ZB2GBjsEpdnqPE0/u+LXheHhQzpQ6RPi6/fvO
y9hDi72QhSKRpHshXnhR+xGaLvDMaauuKm2RoSsyfa2Ww5cCHN95jIez0GecQvW5pKv+Bo11WG7X
5TiFIZz+BCJ7PzXhOj8X4mUdbX8EL6fLLVxgVZOlWqyRqGKw58oW9konBOo6vn/X2z79y/F81M11
hHiaLR6K1oY2p1F79KjVf3VBhfsqQuwtu5bmc2MNRnecpNZX14arbeNoGN7W0LjMry1EiTE3W3yp
3jwq4/vjA92I34POatXhIWb/6l3sznoPlB6qanG3olC1+dTWRSmNCYgjhPsDJrY+2JnpCrXeVdAR
AgtqyXljPQxqWzLtM9BNcxeYCPJ/efhZfk/qHAJ7bcH4S9QCWZADwgAGIsucmr/+iP8ZOAVqHII0
xjZFvFXiGJpsKT5AkaG2ojaxXGDJGM5bcfpQx5e5Yf5rhkz71zzBBCG2jWhZV38txgPl7bx0HPlB
DJjDO9CXb6PV7pJ1SrE+dLZI92T+1OQdfSrRRCBQlE6rFpZyuV7VQrHC4M0SeO/ykVnd7AxTHxf1
XMxu+hAYXhsElFQ3slmCsmzskqvVwzIrIsMGciuUtmR1hTwrb+FpTA9StEHn8g3zhw7a4BCU2hez
rzsrqlFJomjnGUKZQ9dapklIeohhJI5g+ASVDIcLsaMEsxbtmEmT3oVwvDHM8c0oBNvDpQCSDhrV
gEPuArAxXdfi4+/Hr8qtQw5bVmn9aACarRChRVKl9XUaOdJtnyeYu248g1tZPYRF8kbUJQHZm5p7
oJXnUA0ZSpUq83xvaY5v58ZJfPBpc2C7At9Wu9wfsmcs0UloQp13tpFuCHndF+0Jzc/p8fP7LuuI
zjo57rE34qOjVzIqevhE3WnJc9e2XNy4ewXAzBLhUzdi0G+oXJEwtFRzhT55ZLBhS+5Sj29M1r2Y
1q09iia0ayKan+C2yZAP/mcitOstUF9EpCDBLw0kfEQmT9euoZWraoUHK3k9JWCMDmU3FIBVU5wJ
6+F4bBHEhtN70qokZmTqbUIZqfLnaPVckUfPCyxt31EWqJlaJD1eNYn4XFFVQg34iXMIazp5EM2F
hWGCvMOdXKFWRJMU5gdq6aMY9/4Kb8LGJ5D2/V+tcjugWkxnMXuPO6dhQzRQqleBAJss1a/6mSZx
HZhUhzz4QsQC4f0yX4BMbfQF8hxotXu5BqjndMp9BSaiNe5/J1h4O2Bs0T72VYHrVYuOPAqEwfdP
FXRreTvYJChJrrcflBA4nnMs1RqZKQ81ozkt1K+fvAtVVWZLgqiepv5eubqryMH9tOsu2SybFuAD
aj0lufMLvt0Ja9dAsZkvjgu9UbHK9h0BzfPWrbeFh/I9zrpoKgNP2U/Ggk8impwQ5XyAMt4cvEBv
K9MTWj1dCiWrIliS6ojslKhM4GmW7AP4U62s7ZlKMA+BT5yXQBdE6ZEgUlZAbnmq67l7ytUP3F15
wjS3dsHA9UY/6z/hT0akOJwE1KsyIwOT1TPpcPO0KMk2otLoOuhQ9GdTKTwUvN2qKDEv/wJVnIzq
C7pecUE8+KvzkVyIVjOTnaCgckWaM5nPJ6ZBVRnrj0HJLgK5t8YVrCn6fap4uaiJCiGKlMUfW3PC
a1PmFy52ilLoLZJK4WLXL736sUlclPr+0IjIX/1eYtYxonisSkO5FbWSWTdItDcUF/a2LgtIiMeZ
OXSOjoR22XzOUVdW6UXSrlJzkoEOIBeG4dgj4c+m3Honxv8ZUe6jgj/qRwcy0GBWUTzBZwk5r3gD
0O0fdEdSOvo0J0tL6UzwuEgrcBShfTf2VM79p2iKKXE11G6xQyyqrOagpsxLtSLW/cqKtPNsMKsB
2NeTyNRUBAwNLksbYo1DjNk8z/YrLlFESS6rs9YqdkjD8qr9VH9ThmY1UIlQm7UNnNxJkcT90+mx
L0Bz0g9wd1oPZheSyYdu9mbPcUeAaD6MBMbqjpYlK0iGuCWtnF38W1n/bJ64Dtbag/AerDMqVDF0
DEk9Leul7dTGMHKjf9qimchh3Uug6WFrmUXpHNp0u9PHLEUMM2w/4CQizRvCKSTQntDloAhOGsx2
RA4cI6pwxhfBO66Fl1HxneyLt5gR/sQUbjNqaM1ntMVFUONfRZU/ga+RZeB93nIMmtq+yL/LgEOC
n0XQt68jV27u0zebpAWjqMcxgl8aCMeKxbyKE9bD0oYN1o8/bEsmmjq96MzscK+mwWTeAR6xGprN
8Mez2e4P+BneCpZ74QinOlJmb+tuc29Nj1w4iNyCa7Jxy5CebMzk+lnBUawFyADzGE/K6GjLsBC5
0MSVEUk+xMuWmzXopt/7RUXpamZ9ITHNOokeCsdIbFe1ZV5hfnD+rmyr6BIia4CeVd7OmoJuyL7p
YeqvTiCx1F0UazRMf1WW30nFIGV96iqj937amRHznwiofe/aghKNbdMTrIz1XZhyR6mkSh2RzI3n
VA4qXfk73qsgGmfdI/2/53qIeykbAOZocH4y4DPqCsY0nZ9U+MXdUpOfg97/XPWse09NBmfnRjcJ
uzL3I4qzlybE2UkRtn4qZAMdl799Ed27U1GwQNIn+9WjQkNOx6x2+35bRZLBJYAxYpDViBb/fTQe
JvxG7Vj6zYMaUrRodwReGJCJzYLd/chdCrjn43K/RlN+YSWmvsyiJGNLLIOSVALgo0Ky1r86A7z1
KNLiH/muSWKOA77OIoyJj2MqZnX0c/xv/Q+z2MZNNDVvDKOFxQ3R3Xh5pcH8Oa8rHqq/GtpEB1W9
Tt1Avl14aEWt423DrJ7VyxJ5WDCDCXzQ4qUe+GZy8udwaTwAxjC3QyyAFwoS5wV0CMwemxwiJ0TD
DoJ4GEo44+IWA8iEpb1sU1rGaM4GmDycBW3Ux1Z6i+owYg4EfpbFEua7iSvEW+JdzB6Q7tJPESO1
y4mXKaFBPtSebk4v8eo6t/AQfCUym/x/GMpNn7nVK10OzSX4Gd8+64tKQxrhpffVqO5NJB9GwLgy
yFQmSFP+rTmzM6PHrzma1VbXFz+NRP7wxFySNh/jik/rulTZBXUkWXyLOx2qEk6HN/DjNVc6liE3
1Ycmw/LXYnjL/WlWQG58tcnik9i+hZ/fl8pHTL2m6kCKKt28e75ZB4NfhtGzcIK7/wpqbuYkhmRa
2v+QbxcN0RYqIbQv0fqB1ZiJgO100+cBTA3udDRxsWOzIOOh72G7wtFM9HaqKiV85G5dGRUAne6Q
mKSzRWBT0N+DX8iwIjZE17CZGeOSck1SCxWrJRxIxB/DVRPyxo5dh0ewa/Nx1WO9Pc06eMbNjWKI
Q8sIyOzpHVekdJ2Diky4KcEjWkc30VDL2D/Pd4mhsLVCD5JGGfnPuDE4qK/lbB26Z5ieiLPfI2Sg
amBmJFHo2Vf3bA3mAM2HaUbxWVQUIuRqGVcsCJMk5endha6QwLk/3lc3sQwWnNSK4DQfaU8xHCE5
1SMEg7nyF67Y6R1wcdPiRMrsFC5cwRIVyaXl76ZJJLWD0E4L8YYMxlmgy6kfVnYqjbNCrjZdYKZt
le+4wEZ11o4nf/z7G8VXS252W9GsaJzpGqdxsq8YaDpgyaQDqzc/pQVVEsCAHWZr3Mji2A3NsBL1
V+87xODKtFG3lFhV9AiJErro6y+a5RzWOHDKfgvbEdSFSG9ZWJ2F/5ubfOcyIIqurnLRtx875xe0
QDKTY5JnuSAksbS3eSEEUgyYgGH72hEnu/itLIOkl9NrKw86KipM9mKsSgpoQMCiBTlYxSVhoFq8
dmPNHdYSaCqtfLP/A+ofCBifkihlVhcCKJeL9M1M9Y05K+JhAKUr+bnKGtMnLSXxOPGZ7qVofCgq
16ZF0h4vpN/qdAvAo3Te0/oDXR3PcbcLTtWudC3kHzXZ8SaCgO2Cy0XYGwz304vd3DGnqkGH3xU4
hquvGTmvsdmqbvGk6djnLbxL7s59vptRJrv1+v5xZsajT2w5TeQ4jvz5LgRXhpi6Kq8Xq+wHB/mS
wzpUoPbq9o1+h0qc2GhYyDYpSpZyR8tJ81cGaVmASa2eSnlU/mae/uK9DKwRQg1nA7PQgWDS7Ubb
hZ60zX+E10Jejc0CpRHm0S5gbT2N4favPli8sHitX+sGyAg9CqLmbtZz7Pt4Z2wvJCqtZ42sEst2
CMhk/Y4BgRXVWLfrHVcz3yjrnLGt/REaUOJVM8QiylPL2K/bruY5SBCetb8TNG5DvKOncs+HcpGK
jeHOaKO1vZpWwlm2wI+ojjQyQ3Wzl9C8KqHn3zy56jLIv4dDmc13dylD3WEj1FNOBFiKHs7nhvMd
i1iWW9C1v4K64VtL+Sx/GqGJfr32E9GR842Yvh6wYkAf+bwAL7U32W73I9/uxCl6WI29sOglrOCx
pjGnKPXjF/FRZOGtY3ZnqBlrXUJU9FqNDxf6begpH5u6x3m3eux6uAqWHsvGqQoPL5+3GyL+Bl/g
rnRq2hAHVcZ+cF1cuui+aNXj0bVX+4MCpkfHtSsCqNkvlE+Cx62AKamKPihVBY7BA6qgnJPmAeuz
qMSfjDA9JWHLKhA6Lg348qgaD5PI3re/7sqf2adk0LamvWdXz4euTgp66VBT42zxAO2jTqpR+B7b
Lk29VCvZvefV3343yN+HSWybuGdXt7kUAWFfYg8VVmBR6lFUBOAgPoR8gx04Goc5wY0F9U3Q4ytu
F/FkzKBtemB/zpR3aDAPjjzQKzxZ3e0sXIxuZ+ChHqkZ3/z3jxTaJVkrjdDq46JIc2GcEk7s3XJM
Np1wE35SmZvBEPUHMPhebVyTpRgRiCMPd59nrwIRtZvAgdBFA5ZJvw1cEm8GpryJG33O+DZVIgzH
KHMnrZPCRE5RKTIe5AmC4N/RgXJdw4n6sPopJjbPiUSwQIz1KAYuTSKswGtsSBCflM1J/3r5Jdw7
7crItQqYqKO9STzWuBNSHQeUg6nUWnwY+ukA+zXs4paRdqKxV4v5W+JLNZqo+om19BwcH0BHt7lj
dQ2VS5kWk5IXJsciR2Ngg3U2OIf2KvSNeaQryN0N/AQnOvdDDdGzNa3gFvAn/mVGBi3gM3gCoBua
LDIDkN3cILIZB6FWkXoiCigcrc+30FjMXTEKm4zLpH+5TnnrEN7PWzOyx0aUQqC0lKzDPx6q55bR
74x3FqJUjPigzXN4c41W7Xa+2mNEYGgIhA5IIl7WL6bt/DqQ8jf6PVM8tClB6zuuKuyZT/+hysLP
02a7vtrVvSsHDyl0p6j57jACY3J0utf9mW64p1P22D1S5lWOTSn0lLtf+ABdKrF+fYYcSwIQn34a
o/BIq1ueKuo8sKtmehX1yczs7zTaEGpCmnE2tHrRgvVYQu0sxyFiNEwFpiod5CsB6vBChrfABBIh
COGh5IcN18aptuDFHd2WbOhee1X+O/yNuKKYueN+3LMNv1loIKKhlpDpfeyiwe+Ckt/TyRwCI3cx
/b33Q0nJ/DzJAfLCYwcc05Ve6cKiEDKu2dSj1brFNeJXHWGPJycXOOlGQ9X0PQuyGiWLyqTgumnV
mEJqsRUjlb+eiVIvLwVn2yIDUG6oAvsAsUEwE7qfn8woZgkDeqI4ga9vCQ07t65ChfufTtaTv1i8
jiXw32cKy/sbUrIN1hWSiAgJZjtP5w+5bRqL9I6TdAW1vZDYjP4rSU3aLsB1VV0gCZ+HduTxx1bg
6HlnLE4gZR85TDExTq1TOA1LyYmaW77kN0Ia3ICrDvR6WcQRa6xU8GNGexco7Eg8qrN4773+Xcmd
LXNkF6ORQErZ7ICWMf7odduBV+fQMNMA6QHYK6eSuP3L5jQeD9lN/2JOcHVq5Ayozk+Tv7DR4mtX
5fmfCOjk9vcOWtktSGb3GTOtkSHlJsqwIlQ8UvmIifbRSqD4etscZVpqH+6bjE/4SQUQSfWn46RH
5SoRKjiRBKJwuouP7BMuCWbM8jMHEmyvw1+pwl44YoDuHbOU7nWTKuJDtvn2G1Mc2gQ7xSq5/q3R
iSdXlt+fiHmSoyYQzDnBmpIM3b5Sw+rmtUnEMfJavEAApNaVvt7pXT3z/qk3Bcmp5QnTvgaqiMn4
hd5xZDu6Y45N0hg5HrgweMd4pbiPnjszmlCe/vb9DBkKQpktVO9+An/lqIUZQWDii1a+1EQzTPqu
CBWVqk/0KVdEktScyelkvCVimH+f0GhYq+CMOexroteqBaRnggviKY/Oow8brQXFRQAsUDd34dub
5fcPsEgn0RcGCVNxKshHo+gK8/IVF91PEIzfSB0Yjd2rcgB8BQbX1jxJxaRYKIOgVlK7hapTZBWE
BYpYkmls1ZwLPUbHTz4SIrRFHDi/XP90AvukyfcshtcynV6M3KcAUAqn/SRapIqJNZ6FUwOf5FDm
4ld2DH5nbXSWDTd1uyBBt81pfQ4eB6z97k2MTSouoxPlayZxOr8RdhbSCvf6uUYFptPZURvKUz4V
20+xu9boqaCbMyNo6yro3eJ8VkB+i1JNtyaWzYbQRZK/F2v4F2RsGaYUxt1VrKVYJXP84Ct0C1jc
7cYrNbE6YmuLGZbyhqEr6cFzMxpfrnEbAt7t6DetLU/yMfzjbvcLn7NIcPNhBqEyETHVMAE0GCl0
58jDztbfJr5C4o3IL6vxeM9kQMqshJzvvsTAPSaf4M4O38irvzliI8Mz9v9oslu5jlNsZ91Z26i7
boK25HwliNK+HmH4+BvstQBRIcVZsgDpa32vPseDryyhsu9+dgn9ie3oKkwXSZlWRln0oUmgAERD
W9po6sxW3u9nvxZMJkWRTNWwKeOutZuVJ3w1BrvjnXjApF4Qp1RTSc3p5o6TRdk4d0yY2Etv7ROG
uWVLMYEmCe5qQHWDeSlN7UB7d1/KNG7/yinuOZJvEerHXc+Y5LBiWPDJRbWk9hgEuc3s0Gb16Liy
KA9bfsJcxKIVzt5b9ZL1K0gjXawe4arl57sPT5ih8IgB3s5dKC+YnvkwbJrIPbhxkdX9FPXvSXnb
c0X1eGc24L/pgV5iVUdo+cceMUbLiUq/i/x5Dkvz3kr7v2ny//KlM3zzEi1b02gaR/9AdVvUIg00
EysR/g1AmgvXXz066IQiivZE5P/JoiL/PlsQc2HcyYZg+6deseUUvMkhRpwCWRBbR/5kxdfl2coE
nIrIoo/k/kL7AkuYzZfKRhyZ1Y2YwUhjVH0Wj/n7cLQJ3IrG5D2MWSb3A7ba8ZhsW406Fzg8RG1k
G7rCQDAZnJIQpiySLCpRqjJ5MFkweHi451RxtmRvkqD/Ai3/rY3AGSuDt4RA9BNBIa+5QBd/DB+m
2aCP8SsExgcs4mJJ1vUylVNW3DgLdfOSpRMMD1PyX7ELa34GWTQrmifL9Bc0STukoQtdbTBFS2xV
TQ1U/LIfkRk64wpXlB8I7PWhzbzNd6xA0u1jsR6fq2gF6lxi2cBZHKFiVJE2JLRuVSu453+mpVqh
QrDZn4UF011ipDf8pGzfL4BU/pdchT5jxkUvE1+pA2o6rS4naQxd97UrfrKhdTsAD/N1lwpm+ObD
qfqHiys9VvtkO992ojfRsVs2M/fPb42SbbQS8ny+P3X1kKoPGsmK7zvTfiVa6U34D/tyrNmNbnrf
oWnSs7mUUeymKguft0xDZT2eRmSGJEkGSygEnFc6xZt8TdSydz2Cgt/l71W5VtpqP90obqtHp12+
L/HNMie+dqPqG1/h3ixUVjbEeLXSXr31ELP/LyFM/s40wG1eOFvfPU/3mQzcNo3UiWnK8ieuatnB
6alFQ5W5Szr4Wi2Ojgep6PFwVWUTNRmjY/HPVAHKGX2xJqH8gTi/9XJwwM2qULm68/NnCdzAeN12
sia7Zge4e2UIwlPf5O7bd4dCukSLhXb5kJkxPL7UrSBxlap8/gOOr88Xkkmce1DyUi1BxZ0xMcYy
ovSo/0SkiJTkoaxshB9N8USDsWyZpe99rwRDTihqdep2+neBVfd3pMAlpyVCkoDzg6ta0Ia5mEWJ
9r4l8PmhgYwEW1epwSUo01aFgRImP8eEnQTsk2IepSmW++9xkpa+OyAWaZa0hBrVdDLAIvNisc+7
rONZn+u2JsFl8dgvnyIGStp1LsO0UAHmbG3zBaYxMR7uSswQiMC+cSTv/6LjPfmncylx8eJ39X1v
gEV28/sxbSC9qwGBRzCPcG46vMuHI9mCsotz7lSQybxjNc+fVhLXgYH1ejaNEVx54uqgl6FheDOR
H4YOZ3a3gKq0Z3J2t7je796z30m1DCW7BhAWQy8BLtyXtOMNrjMULiGwiO67eNAWw6N5OHDKRocU
DZjXrsQELoiiu6YTzTH3JKZXb5gZnIBS+58Pg9th9uq0BXLtm9Hunp4Iy9uA9mDmQmII6LzqJYl4
/zMu5asbajth7y0HU7ushZnvqKp3uFJ+0TCisT0bPjVtYHPjRslfqlnj/iAk3UOLz+iDDGmnw6AV
+/UXnMlbnRt6rJkt1I0FDGuL6sIUD75s7W2RZ8is7uDu1aoX841TkBRehft1FW0euNMiYXTS9DUs
Rbn+CUu8BjVF959+1odbwp15aEyIsrX04UEGNAFn+jUDxMhrrP+tsWerGINiw8DfhZAasHnK8sV3
sJG0Z2q8hJD5apbplZvjBMVd8hs+KY1gTG4exxpjBO9d6u/6PdQlDczywEziXky9Hvnuj9NImiz2
XgVV5uasunFSvqHqdiYyaViaJGs1IizO1s+bmwGceM4H3P0YrMzm7JHXsC1BUSZRMIyiocvkG3Yo
MATLzWwBDM44NxdC5pmBChW74d22vyaERKhjKJ+/ReyFpa5dZyS2TDXXoMdPgYRmE5PP96rN4HAa
jhfgLlMpCV9Jg+uZIoq8DIQgrn2RljOkUI/iiFEVP5y1Q+ZWn2PCggKRwcz69aLprjceplNGWXXa
i5oDHFvr7+AEV8qn/g/vJ9faM0d4bglodOG65KxjUiUTEUGQBaKU29vO4FPLezbmU2EvOaTj/m3o
hCZ8HaqIRrJUWaLvEjPunbPpF8SdKfptvi27cVrB+GTh76f7SXCQ487P0FtmbrN/426BK39tRk7t
Akdwcox9rcBD3x0r6dG/bSKp6wjBo/WH08IGEmKWYCe24gICtLx+45QQ/nOLdtNavU6GvqTEYWKe
1aqT9l9a5tmTldWBwS037JdAr4B/z73SRRb9Rm659zVzELy29huZYoSOe4HqH6IkN9aEFhhwi+CS
0ZtIOhjCmxfg/au6DUAmyvYfLy5wBQTG59CxdXVI3LkcZTGJjhiYvTYJe3N3m/Fm3cZL/NoJMScG
P0yLNxL/QfvZX2SxSh0GZZN5k9ejG6Bjgdy03Adz//Ia5cqvt3RSQ/BxNbBsMMiQN+XJGPBWTQUs
ZMK114qbe4/S5h43Brit4g28okDopXdwIvSMfpfvIMsX+UbRFojq1KF5Bx1JsbWgqzUHN5deXHZ4
KGgQqUzxxo6N6lXf8ltypqTNIoDjWJoOcNR0nzHlSxg9neIKjHiwnV6wjpbazIUw5DmgUw27sCa5
Pe0aOTCLft2KSKYuj0Hb9vweqoKUeVxprtgAzM9qiGJGrSQDULjRd0JPqbeYkhFVC7kQBtY0x79/
r3Gzj2+qPJY5lb3WDg3guTlRi7hVJEwDwejHua1x+HgDSs338DzQfMDLzCkfC/l+Oz7Uqj5sqkEz
hU7s0vCi8QEm2SxQgoqnRoA5yzTNpM3GbiFiS7cedMx44KZYBOkXxU1KsVzFyzCjG7PAd9xtjJhb
MWF5IZGAKQaVOkDgnkV6N25qur0QVqKkf+7Y04WZ0q2Kh/Cl+iKUzAk6RzLbFICHU+qGmSHf4GaK
V4Da6JI9md6PXLHs9TZyyd99IAg5kAJfXGz5Fa0T1ZB5qJVZFid34npmG+KxeOnJ+TyXzFm4Mazp
JfKK+n8gQT1UPVv/jFLQHghdLAp82btkwbpjaveH0h+rYixxFSawkBcmHIFKNd4yRicXxFPUjLks
lDauUF/Iyjj2beuaITxBrrPW2EwKfBGr1SH6NyQLKVSg4gySkJXGTUBLWiAGstTmMee2Hj7ZljCT
OrRzZ7gi6okCBbDJ7nLVLPjgcXJNNm/cRXWYem36cL6J8n4V7sGpYZoj7I9Z7rRE3lSetgdCSXax
e+U5IE2cRg+wRQB+FdTKfDFaBxWP5UelBcOtwjaqhXCHMN3YJFFlz3X9i5stZi3uprSOo7qE4/Zx
ZK45Dq8SkaBHeXHruzjuO+2SWRvcm69gaUrrXpgcaeE7s40+pWMA96f06kaihKPESSVvfUHZ80b1
7il59iqpEqGq7M8DuTmNrkphA8hznZ3h2ZJxtCJDT1xdMnxP/gC2Qc2ZRXHZVHoVOB0FyWaf/JM/
rBwYNmaoMovuRDdAY0oGCYnPw1/WDvP2MoFBzaEhdNg6t+aVreVpHY3DoG3tDhTyfxtfCxhigVqg
NhXjfdBdaMnIJvXN2BekudAYgU3eAf4BTovq4WtPfX+nyzSVDFjUx9uxaWnPZBaXObtQDM7vek0h
fbDQf+ujC0G7OJ5ZtmK9ZuBEj166d1SmvErFZeBAfXcQZlxfngEz1SG/16CVBRGadPKUAOUQm3kM
WNNzeHwX+UQSwYFfpvM+834YlXEtgfGIRdsV+rMDLrIdCfky7QCr3/vCmqIntRhb4JB2IZNP9uQN
Jdwe4ocsZjaJ/6fUIFYTR2O/S3sZ53mU1RmGnIxqqXplcuOd1NdooFrm5t6nQGbzMbpQksTYYmn+
4eahV2zpiWzi3uDrdEc873yrXOyPZjUTKq28nIRinYBi8FFuXmPNs1wLzeojN4KVCAnjbnusFr/d
k+qbzXVn6moowVJiJ5l+4Uoq0M5YYmToPJ2POa6+70EohW5cxrL3R2zUdvi5cfPIemPgZGKMKOzB
aDqI/ipAUSR6oKs7UsoEyyVjlNmFMGvJUBly1CJtT4zadul+2WC6i1XF05sulqICi2N8lkfkY3m4
AgggnKlcO3AZpCVSOjGPqI8rBXgx42I2a9de1VmkL0Dc+8wO+7+edVP9S4zKvMaBEbFf+39XsqDd
H9AJv7NiqJE7Qy9N9rch0e3jxqkMfDz+Fciq1LdnKdoyrLzI6/7gPK0HYkCIlp5UMVqjZGPOARzf
z6TVKzTKhvEsg4AmeE1D8pO1CcclcRXsfdTZy/X0bPfG0LK4qPQnuVrlhh90Gd9RxuE8NbRpeBzz
DJvEBeLDWCRp4S7B/KeNSrrlJIsiX7Ask8JzXoAQFCNpBWG7f3LKD/OsvfjEAc4zA2l52xXGYH9E
JlHISChtcafNcxIU1gbSaSXi2RYXD9W4hrKQjKKa497baa8ZXsDKUo4rFRSJjmSgIqRT4pX7PmBP
ULuXRTEgynTlKkaKk992IY3+SQg30sHizhEJBkDyFSIuMZBK27stdhBa+bNAdpP6IJjF6OE0bzpD
1wkJvgVXobUBYdCQ2oicya8tK1cgxsFzURIt2PN7ak6X5qP8t6DGJ5KsTDxXHhElBHMIvANPa+ku
Lytk42tDg5fkdtQcB7zTiXBNgGVX3sA3y/7kSE5qicbiVmgHlq5LSMFW7GkbKGVr4ko565dpvPmH
Y2yUscLMBXw0ClHVHhm8TC1z/h8gMu9hujlCNCddANRGXVf5fTbeE33N57N/4G5pXK4PT8OyNVgg
fVNQv4BzSIACjHgbGfoUAn4AigCarFMsYxTwTAuZLggMSuj55PPmyK3s8SAHQf5fdnZHlXFH6aeX
X+fvu8cpq/BbJJriG6yJYYsPt3YQ59Fn40yE6aJRL0c1Whd/CjHOSNdFLZW87+pstUXIWQEuVHzO
rXabTfarZgaw9OETPSXO5gw1xqNi4JFunoH87lLiXbVJEVO1k9JKAbWomtIXCW+sZzMxvm+tarhz
tRDJ89K9TzlECWYPAzCGoHyOpWIGPOURWgu2vTP4Zhow7IH4XrXVaas8jPK96NFPNQBVTarO9LQo
nytweB+s545HHjDUCRQWrlWgQhjzCJcaj2dVuIme9Yd2892v9RHnDEoAve5I0CkZuqQt/+f+rs+Q
V+B3qf/iSqxNOdXO2jKoC/8wV1/Q3PgthHI+XD//cju5tUYoKa5I58jaUoZTbmW+DJ/yljniV//7
BiZDSKRrRE1XQwXKUlt3Q7xO6/H/S21HoOAVbHQ/GVpf8FUNT+9koklV6VAwBgxGgVdoCZvjKlSu
4YNIDjonKnpKaSLIcawB/KWob0209P80Yy2ff40vIpR/Svt8vjiOH2PRUH2FMJVROigVPvmGKold
r3TO15/wi+01paZsO3x16/L/GHZ2cWaKZmWQ/6Aj8kuiH+g+OzfJXOu4/a0G4IFoLAou+M8HBJmX
IMcF+nDd8zkVzX7KWRrbTp0IJKxyNZQDjYSSW7+eumnf/QCQPEWmShsA0IfvbEzfiKgLjsmTIvMh
hVvDTlBwNEwWKaRpKSqDb22/GWNuGlN/6w4d4IOMbXg0yuWwgF4yT9syXY1MnxdlYhk03DK5aLDs
dn4dvePFM2hk6PAyMCU/ZFe4d4Zshdvfjq6TRTPZcuX8x8nGBPJue4En0GUQpGGi7TTnNKcvcO6V
HAjoMJ8stktmt44zYwuqT0G8bG34OU4jQFLo4pU0rSkhcsnCKmh0PO4wb39wIk1OAdp304M/Obov
S/3NbM4e+X1VLElpoXklF1fQ4IjTvmhQLwEl+GNEeP/eWfIeNMEaMqy8UoET3WtxS1AlmAjbqXLT
Z79jD2bFX351RoeXwh+AIb5/HMw46eCPxf+k671CguJa3XVde1t2hPaqokgPiYg1pen2n8ugvrVj
aPySKHdV70MduBogQ5MA6vO11OyhHj7PSKfp5iB2l88JQP3lKkjSbj2z7cgasFX0fC1XZj6zKoln
GgJjW6gTskCP8Tb90Iz1b/cor2XaMhYV0JH7zJ311wgTA7NJ4ffVOirqPCkP96+tLWP1b36/iGEW
ilPIUUo5D7NKZSnNU8AdubNryrOvdn4inV03q93CSoz40gp4Zm4ZIvgFj9UEnKMpbBbEtxXqLzJ6
BDFwrQFhJJ22eTVGwzBqh6EFSfD8tEFYD88DIc6NFFlAdM6LCLE70Uid+8KC09iHN5gi+PNLVdql
Hk0wlFgVokVh924lWFaYsr63lyv1ti0hbaWvUpGpGiDpbGfmCTs22ZE4q+K90O8qOC9He/WOEJod
JayqiZaG9P7E9mKQlyxPTJGFMKkfTSwmUQC/xG0CXtRgbkdGjKrAA4fAA4LqaxGPJN9c41kEFy0t
Fvk7zafSoOQ6VaCjQFOlNV/C66gd0lPUwPF4PULNfZRYOsZKnF/wu7yFqSNiyRNIEFHSFq/q2dOe
oRW2u2KVQ5gtPYUVDP0SHPr8fvmuc1DQy6lbIbf6/KJjBzLqqC70ko6fbF2ENc9zfOg9S7NpvJUS
qxMHsFcOfMmbb+erY+ZCOF/R565JS6m21hEdGTYFKydLTyi9fsj+q8h0dyEIP2s2P5BCZMkq2SAk
jnAgj6QCgMEbBzEu/y4KsCbzRtCDgeuWjB7CIcqSMDVx3M9LFCSSumwicNlfwN7IiCGmFsQaW6ha
bUyz30nMUNJGHULyGhbwIg8KE/e0MLAAzuc/9/r83Now5pNyIy6IYvtngwfbyNX2TNCC4669TaBF
fofzp3QcuWt78kRPkI/8kKDCIs1dB7u1q32DZD1c/RIu0u6z44wwJxtyQ/m0gePzd1H1ofR3Zy4f
seOkwLB9il5/LUERrfPERAt9c5XvI6RcZoYKY1cBaVPJ1yTRfv8MVvecnRfu+/b7qW0NgzWQLdb8
EF0giyGVS4QU9mlSLDfzN8wBPdIU+G3KNACSginnJLy7c0V5ZVr/L1mVe6Fj1Jxq1eNanXIcYgEL
4nmrSHZKBd6BQipR2LspoL+1b5qI9vCD4CjH4nQ6Pj+u4wW/86noILytGuYNGskqW7OaM7GOA4PE
hNTlhjtMGhYE7LAKg3oIzmfDRroDioAsltXsZsepcIhTH1mku5TIW8inAezIR08UyGWbD6Kcc6w+
uIOKYa1Cy8hIH+Eenk/y0jcRA0MeuQUUdn6zMfbfRXc7Cz6GFX97fvnMTjt5nTqTJenb6AhoN0cM
B98sqqIEWIYKyZowJOTkv7WFi9m4bF/kAnHkTDAzrh7fcwEng0b1htXtSDwQdoQJ2Qhx9bJ67Iey
B3du2qAM7RHjomtsxD+UfqHlL4tppJvDD7v92sXqRXIEBgYnSyOlcWKy9cPjZhZtjCVrIooKSpbG
MNOqeT+rKJJsrHw0rn9f6llEyPgJHYUq2RoUM7yxNj+IC9aI2gBDK3wvHFux4aEszR/aQ7Xw/wqb
6cixh7DflX5/bhi6ZHDR6LHaL9lnWcLu8ptK1VqzKfptoZSdwyT8TPfSor7d2MrF0sJK3baEquFF
SqLWCFR+AOmy6OZBhgxQXHJVpVLHdmq4RT0/FtKJ4EvVMCtOrOE8OQAiQ+cJp26LqcAhw1IlsCl+
abGYI6TotvC0aUNFBRYiwlay794wjdp8r1k3AFzk6IaMt9qktnmC/vmg027CuJ+SWyXg83WTiPG7
ujgic3Bd9dPV2vpxIihO814xXhNSwGB7JQ5bc8aWtPPrV4P9yzSboja+Kw1aFa49PXOfuTkxLTti
QM1lDpAbEKDa+TB2+tQcVw3n4BiAo/cZ7rW+f0JIZgXsZThxF6bH3178gJc2L/4YepPXRQWSYLMe
YaH2frrAfOUMQUQivzyofIZP9ou7dzsCBgtwhg/t4ZvIxs3QwLC5Vo/9S+HWXppG6bgMxKgy02hF
XzQEZ2fo/deIFFqGwTcZoQk3CpQuHxkPFHtDj2/lbUli86rLVvwPPBMs0voBeKLI8dnIWhuB+RL7
IrnWiSDYhoqnoQkBT0C1jgMUsUsA6lIZPsk4PameOOuSNGPp4TA0SOOc+GwbR6skJTjiQ0/ye16o
SYL5+6uaZ6P/InsDojBCTZL37MT2VEPBazMCU8xLpJD3PT/AmogeXQYqYfYmJBZw5L1hyw3im6sv
j0xeBrB7qkMsbVLZWWZ7QqARwheqYk7IISzYcxKyI+aQ66RoRxCSkGlaMcWR36mX84rnZ6S35+Sj
G0EdA6eDme/8EYH8DckbgIw9T/522IMd60X9/zHwe2SBEonZ9lDWqHAIP8L8i+k6WxDToH8MgVCy
kMhs8tMwtYyWXNRthIl03RJlBDCzJYxLbWNqeiWkjlRqOftePq1XUQk5hVqhirdQ4UZH56kjd+Zv
1BYQdmDsJ5jq+DrIBbU7ZuZDenSPxdURPFPHScPiupe/2VSFc79v15gDTe84kq5WNyIiUBSn0Lml
lArBrwLmGlGjUvFrCfC9lzPmieXuTyaVm2NIvDk5CQ8YDv/Y/n7ASHoL+qOv+uoBXkA3LULGcR1E
+Du2s1pdDFGJyIfhH5ppt9TAyFMj4h30DDLXgjwIlIPdFb7luSjZljsCWst2eGQfrYWojjYrU8km
/MeW5nDxCCzwAvxiOj415B38+pdayx4vqwD8myN7RsHBwVOZ7lN8aACbix3aSQgLPkrRSqlf14eR
CDGdIsvnvVbdxMTgdzEmlHUvLN/MCNJ4CzeDqE0fZ57gcStQ99HncN8G39xY/D8KxE3Mgu7JQg/Y
rAHRJZ2+7wjZJp3RbhzgOnhsai555t4edqhkMXz/EOaj/Ir7hJiPYMb58riZLDjjyX6KiL+1Yx+1
qpOE3FsuSYArp7JSJvBf9wCS/CHe6Mld0HjkD1e9zfzDCYS2k3YuIp8bqsy+WPHWMkJKqN9OQa9f
PGwg+VohwbwmoogAKKP6gnYk1jhkKeHrfRggkEH0wLph0MrV0q3SMf05Mm83/eWS3JW+8aivnxG0
gNSCNLWwaQiPZZ6Tq5qVvFyzHNPZDNOjUXdK8USTXdFtRPCxw0UW/SC/xQxZC+uG/yKIRjA/zBpB
QHmliZ3+y4wQpa2UZe/7Dihq6o4RMAjtZMki35qg8FQdr55kPL6NSFp/9QOdl0FTkfs+Gr98taqH
GrB9nyEB1mWROFAkIvG5pNtYzgd0qyIXRHxL9UZVVHSroH+AvOsg0zgwZZMrWEUHd/fwfZsrgejm
4Go9it4gUyQAfCbQAQlMITH4AKt95i0I+HSMoANbuwmLlkZXjBwhvPhZsiwgmSQ4838T5tEHBoVk
Whltp0tUT1s9piLH0GpmmFlIzOeJqk9mzBC1CsfSVSyzsG0MIrLxDcJHljPGJpjF+OP5JuC425Kp
n8yxfxUWZTPCKws8hqgRvShPYz7bj6jNMeThXc5B/3QxbSigAFRluov2OOvyr4ucuA6RQj/nrbvC
Ht016k0peJern91Yr98CBPActCgC5VCVM2gvCpzYXIBuKuF5QSOd7zajoXlGQuF2/L+TxuMyCeSk
unwgzAzNA+0qwCtgYaX2xI9PdQSUN76XrdaY4KMPTz/ltH2KHxGUx90hpW418GS6d2x6xaT+928E
0Lb0xapKtAZjGL7SHZWeU+jPsRlP+fexxV84CjE7Od+GNdY+tSgpEiu3odk1evaxRZ2MpZUva1sj
p1RGsk8kvy56LmDPsAFk3lY0hLAcbSNCWkv37h2DHcZCQY38sjO29XS/n5d5dQlwzJEO3Bf9YBv9
/TEMCrP5zW9pL/RFEJJkZ4Hzv2LBPe1Ank8kEpV4A9dgHIvnPRktlFTv4TAZbK+zln+MftdODyBC
IFOL5oDgb4zp2E4Y8XVWL4llkc65epJd/zJsVf0ZPq+h/DK/fJovW9t/FjZAeOBemtetZeGWavAK
UY++BdNGC9lDrSHDUviFxM9aj50z2Jj4LC2VIfjO96I+0FZJZh7f+LnFZuKqMhQfpIVZvynAyZ/6
tVeyicv2nVNqoRjVQ+DUpHMurN/BAlo0kokDaesL8hhS5Mx6FlHlek/xSqjdP3EZlhXpqFKz85y5
vSOlRFaoJgxytgGd/60Sbdpxv/CZlI1DdnDplveasK7r90H17g6XWZYlS/1xLENGLjfYLMCcXJdR
Kz/MxblyMj9a64G40ZKefcBjeuOf98F00YInpMHHeljRxL3dwVjWvHRe3TR2jR78nr6DxzM6kKuN
iW3gUxP030jciIqy/oVlFCeM/Fi1/REdFrQB3JQxT1TYUpqvtMR2TWiGHt52r/2G9uk91y55NTRS
iTd/RLkuxoHER1Cqs+XWAMRZce/FUybR3d4M3S+oP/Kac7/3ZdMI5EW2zYb5Of1gZHUp0cjE8CWP
E6iqrsDFQ2ngT37IlKK9aRR3i/K1RsaL2JhwMUs+OJhun2BTqfszSMbpJCn8vnOtNS/VfZxbKor7
4/RDhHtEK+09a9pY0DcVgdwTx9pwyRo4s0bKHkAkgbwHBuSMKwHwhOI8WeyxioXuQA+FM9q0o8wo
oyfGeR6T7vqjL633wTONzKc+AYnzsMvxSlkMJK9wPtdeOrg9NthAULwnG2g23fB12N8nQWPCdhvs
FnWFCrBd6AxCY9TFv17jCDZ4KtmqPsUig1PM4oPXyMgi+lCY6He09KD0GvuDLKCvbPttYS/aifjf
zN5A4qzxGwir5y7SJvQuhUwF8U+Y7cA9QheKTJk/5+7waUKO8+2wA40q0N7hjibd6ofV7pvt+S8j
asSffSG70C6vuD1CCbPo39c61XscvG4IEU62r6yxhAM3wUvtI2QTIN6xTkPbWmCj9dsXFN5IPXkP
QMvbPyNRq710jG76ZGzK0wsgjld2QimePrR3wAJVx9dWRK29HU0gyusEjQJR3G6QZz+BiW7IC6F4
uzP4HvMI+LxtSTr+YhcOsvfdz8fsTkZVXtW/iLlSTgZkC/QkJ78LtJ3R9GZEPWrok77z+g1U6/8e
gj6wRtI9cq+1pVZ4ESES/ln3ewyL44lhcL1dghmnkklkhRyQSfFuqpdafKLLHY4CWPG9WScBd+xq
6pxO5fcSz2JV/b6ti6GIgvHvVwRG60NCC6y0w5U5sYkPIFXtV418MLIQqRdsEOX+J0QB0gnGORxp
szgOauW6wSHSHsDWjwuQkECj472MW8mtUxN2WR6DINgqr/OHZ1pj5pm+BbLmFA3A2cVqZdOXqvSS
Jda1Fz2VFw3RWejBufV2dTm0hn/MgGeg6oYbcGDEFdt1KQcOHoH0mAMBidUKCQAJBnwgTqovQULf
Qmjj18CEVI9a2WYbs0dpiLHFR+kYnr/mbGu+0NFhV7gdJNvVw8pShJJ8rkNZfIXJwulKD13rpved
EeiRIzTb6J71LRjBpegXmjp3oKBkonf+Pb5zr3vmkO5CqtJwgdWzDJBucZcDgBBxDjcwDHPvkwZE
P0v00FjkI3/EQQYrtrNFUsvGGqP3VSaTLhEpt2dYo0AKa6LhpD9cE4v0flTyeGUJvKlYOw1Ypmr9
URyQqYbqUcxz9QPwJwk89Gs7NrtpZU0KDyTeeJe7eyQ8+J/+viGwOt9MNe4M3OdpImEDPwfFqtB2
zM5bbXHaSRY/VhofKK98/TQk5BUecxgDYRLf8Dd3wLgC0mH6q8f+60aDqIJoffmtZSh/HeTnq1Fe
spFoa4RG6Yz/UhgKaG0GQOvHMbGkVVloJC8ZyqCQLxw5aRY4hWszuJWYhOj9jGKfufUkLuoBAYif
ICH8VmuvZCYRO6EttiHotgatHBM3GrlhCcVv09rkPj0V0CH7nGOytpbq0IKsJUSkTnCHn/QeQXUg
s9KgNNoDMVbmd7pTgENhWzzX2t+q3ij4MkGunn+2eBPaiYKMSTCxQZvfF689uniC5LxFFUcetU0F
4vwzNI2FU1sUOi0NzJ75NszHR5UcqoGGPK8zuWEk2/ZGD5D7FFPYRbDQPKE+K96m+F8HMQJ1OEL9
h0kQvitm2I4URvyuLeG2mpcgtYAbNW/lg+PQFxPTm8N9EpX4jTTFeeTClYAqZUaKiRzpwMg6nejp
CiTIH6f+z5lJGh9aqYR2IEPEZVCoAc2GoLBDIXOusz14fy2OzHt7VZIMgCUFghlFW+RnWFBdnjfB
kepJipxUb+pMxMoJY7/b6U/MxAXZgdJkBYINXYS5YiCHAFYz0hUkT5MERMxYLKuhOA6eJfCqbn8v
3uKVQ/GkR9YBx0B7z9caNna0psefNgeQsd2dwx5PW14is8WumCDRUExB3kkE1dEqLxTsS9BM3E+8
vPa0rApJkGqteeeYMbo1zIB9sCRvI+hIrnxooPEG2ZZ5B94/KMiCX8schrT1lfBYAKIEDxWt7gtZ
XW3ODDkZpXRPIqNdlMGlDr4KmpFBjQg84SpxpkmfA3R6kevz6W0vU2eTAfwy5UN0uZxu0cKAnI0x
qS6l0xvKo7LFNm04traO+BXxiAniQZR8y4T3gQXciV2yNgvb0yMLQTYPga9FhjjWTHIw/sSyIx7G
/JEbRMj1HBM1lPBBM0eIz54/nGFDTdtJw6stoN4s8JNF1nMBhYeMjuRRdEM4t4qVLYlBMpKGZQtc
wwGUh1xxotjV9EEjBN7SkIxodOjnQpefy9TKlnjgs7TrE7uYC3NoTwOb+OjBV2T414FYdJpJg5De
uha99HFTbUNvNNBXKZ+mC8gVT/HXYvtXANROqCIxE8MHNq5S/Ruc0nf71e+iExYJyHJMZG1OkmHV
3HcGOM+cHUh7a4rYaiz9sZqU4GjCyxO6zIYnFHxXRXrQnpQfyWwqhuqMQAJdGGPHAbg/ghXMOv23
Ka88gTMEPgGjWDEc2sTc34zEYXlgohD03snKHt3MWj11FF+1za3IBmGQVGsYQLZVHVexHgK64LM8
D7fuinqnufIx91LUZiT6EgS0qf5pwNLC4e6gj7GbXIH64IBNTnyvgeB1ASM/cyid00FcuhvRKAcj
ZFkL5Y1XoFoEaDyWDJQB8cn3fTwOoO5zrKMZ5yHufHoy7aaM60LpKyUetKRHTqa9yLNoUadaaMzJ
DCxq/wuv3IaxvDRX/rxDaDk54yDCTb/mtuBwMpoPec1l3PltCgHFfD6GDPzGfady7BwRUmNeaswb
VdcndZB2P2ITNNCLgBxSLV9SUE/BWSN4oXSvT1rq/lSE9VQtbNhVvuR9VVY4ygymtyijBBadtrza
UDV0TXA0GmV1tCif2jG9ZfBRdM7lwp3FCcYzoat0t/yExq1U4wm7s7H5KYPdDF7e3MU32iKnF38i
3C6EtvMiqoUiD8UAcH42oEhenJdVzWSrYYWg5RuzabGkXTVzXF6OVWuc1w60RJhStdEcr/lqjgRf
UP8qjzINZW5kc3RyZWFtDWVuZG9iag0zMDYgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlw
ZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjIgDS9XaWR0aHMgWyAyNzgg
MCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1
NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgMzMzIDAgMCAwIDAgMCAwIDcyMiA3MjIgNzIyIDcyMiA2
NjcgNjExIDAgMCAyNzggDTAgNzIyIDYxMSA4MzMgNzIyIDc3OCA2NjcgMCA3MjIgNjY3IDYxMSA3
MjIgMCA5NDQgNjY3IDAgMCAzMzMgMCANMzMzIDAgMCAwIDU1NiA2MTEgNTU2IDYxMSA1NTYgMzMz
IDYxMSA2MTEgMjc4IDAgNTU2IDI3OCA4ODkgNjExIA02MTEgNjExIDAgMzg5IDU1NiAzMzMgNjEx
IDU1NiA3NzggNTU2IDU1NiA1MDAgXSANL0Jhc2VGb250IC9GQkRIR0wrQXJpYWwsQm9sZCANL0Zv
bnREZXNjcmlwdG9yIDMwNyAwIFIgDT4+IA1lbmRvYmoNMzA3IDAgb2JqDTw8IA0vVHlwZSAvRm9u
dERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9G
bGFncyA0IA0vRm9udEJCb3ggWyAtNjI4IC0zNzYgMjAzNCAxMDQ4IF0gDS9Gb250TmFtZSAvRkJE
SEdMK0FyaWFsLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMzIA0vRm9udEZpbGUyIDMw
NSAwIFIgDT4+IA1lbmRvYmoNMzA4IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1Ry
dWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTQ2IA0vV2lkdGhzIFsgMjUwIDAgMCAw
IDAgMCAwIDAgMzMzIDMzMyAwIDY3NSAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg
DTAgMCAwIDAgMCAzMzMgMCAwIDY3NSAwIDAgMCA2MTEgNjExIDY2NyA3MjIgNjExIDYxMSAwIDcy
MiAzMzMgMCANNjY3IDU1NiA4MzMgMCA3MjIgNjExIDAgNjExIDUwMCA1NTYgNzIyIDYxMSA4MzMg
NjExIDAgMCAzODkgMCAzODkgDTAgMCAwIDUwMCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAg
Mjc4IDI3OCA0NDQgMjc4IDcyMiA1MDAgNTAwIA01MDAgNTAwIDM4OSAzODkgMjc4IDUwMCA0NDQg
NjY3IDQ0NCA0NDQgMCA0MDAgMCA0MDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAzMzMgXSANL0Jhc2VGb250IC9GQkRIS0orVGltZXNOZXdSb21hbixJdGFsaWMgDS9G
b250RGVzY3JpcHRvciAzMDkgMCBSIA0+PiANZW5kb2JqDTMwOSAwIG9iag08PCANL1R5cGUgL0Zv
bnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0v
RmxhZ3MgNzAgDS9Gb250QkJveCBbIC00OTggLTMwNyAxMTIwIDEwMjMgXSANL0ZvbnROYW1lIC9G
QkRIS0orVGltZXNOZXdSb21hbixJdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViAwIA0v
Rm9udEZpbGUyIDMxMCAwIFIgDT4+IA1lbmRvYmoNMzEwIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlIC9MZW5ndGggMjYwMjUgL0xlbmd0aDEgNDAwMjggPj4gDXN0cmVhbQ0KCv7uBWFtf5GB
SfI5NSaHgKKml3CmXM9QKalbzYNbSkraKMoytY7n5IZAIyJfMS/HtG+9V6Nw4gtAzOnKsdXCTx5V
56cWc4MbWW8E4ltDcZyS+ZXrEboGtejrEByNiySFVxcUCC4mIdNe64H+vIpfkzcq2vkfISwGqcwA
jEryteHFC+TqK87uZxyReHUVefE5cO6b7byhxOeLVnpjk+90srA1lqdzukF+v0v1BPQ5ePuBxxnj
cdhzDQNlgJERVKpAy7zhV2jBJEZqPKwm0BcFP4Ug2sXX9nqSYx7YkRs+nVMwy9X0ILiXywU80MNN
iKXk1EovT+uRrQ8oRhLRuYbSE3sMbL93R9+AeoKltmG0H4zP0Yl9mxFWco8mgrHYoqQnoHNxqKm4
GIK6qAdJWdYLJqvy9MW3pFWLB/bxEbdSlXvfkQ/Cd7QkRmDQZHitPjF+YAYm8wXpG100dm/wtnqa
aFWMjrW1k94ObZ8oZu0lECTpL8qesg/tksizs9/MxjaXelQTmqhfLoDkYmM+2E5XxON0QN/oka7t
LznfLZJTKymmAeKd/HQM266JV8DVZHATsN+9zE2I05YPcfOz2vZKtVqS7NM1NMRabOvy876wpzkj
iE+hvgyXrCLk0+FYT2HDUEtG/YmSsbpsogtC/syN3sBw0i9ae9eh5fWA4EuBIXesS1COBDHOEDl8
fjht8RLmPzUy2vdUjpXkh0LexAm7OYHNEX5ZYMLX9b5EJo9b0OZ9zdpFqz8vXNO3bEV4gyQrX8QY
fUs14AfNsHOrQ7+z8JDJfc5BYaO+YyJHTYst5zXNKWEGvdMoFDp/wKPJ3sSyG38fGiRu90FBsGhZ
hm9D2I2rnRuS33HigwpAGOVhN2shBGDdtGcGIK3yWyre2nHB4u2qEVszj5955wwJ4vDkrln1qQUp
zxwA2m5/kZCiPnpsaOgozhmJJUxex2glcxVXQ9IhIduhg+/AYdRA6OnCQKQdNIUAYgbR/sBTYwsL
hKbpUtBQDpCut9OnkqF2Csg3PXXl5Qu7H6nJaZB1dBqzDnsYJKqmiSgCo42sEFDxPy8lmBZgIPmd
4nBPUsfSkhezC+esgAzbH0YZIAdH6wTasap+UYkuC/JKInUYAj42T8gz5qC6LvirMZud4BYAuorX
iUruZhpDn2Viguau87Xch+f30TMje16tnohwiLD6tbpm47pR3R3+BxVN0A/gIS5YKkrisS56Djmj
HNit20CZEyvR7JRwgUZTvb+VEgb1OouZOYywYe+a+rQCFpmh2GUa4XGSkZ8+zaQmNbiSWk79iqB6
j9kSw7zKmoy06xOjbpddE1yzbWXmaRDAJwaF+7Rlg2hx/m2Px4AT2zIY4oDMRUI7ULHQHV2gRBVm
nEf+LuNjhWMfwFwJS6YA8ySd/UDm5C52EDwue4nsJkVWx6GsyB27PgrJpxYDcwEstbW09SfLisHA
JHOPIBU5H8ILSEmSUqM8p4xMkI78fRtP/Cbf4gFAMeviaEOdc/3JyhAmXluJAOBi+boMO17FrqDb
AAVMdR8U+x3H60vXXWGUSAWYnq5023su4fQw+/PMU6dOG7A3Y5lkqHiskYLWns6FtDD1QVLXyfMT
glXRcqdpcmad6XUCb5UrGEiFSEd5drGOo7mQ+LWzUGsgqvAxOboauboA3/eDarhzaiVBSViEnsOI
lUA0D+8DVBBukXYPFOMUIP1PUDEsOQZWekukPMfxIesp8hcWnbzuo13hCyhHOPrtxd6s1u8Hbh8e
+Qa4X9HwSJpJcD4kctEQE2ws5ZwVMMrJk+AJ639gsZRpmndiuMUtxdbcd4EkzhRocrd3T2PHDeOH
iz85tdcZsmy3R24vQmtnnJewzaISbm1mk3HWKsipdpo6bSFXZM4QsMOyxcqlAKiO6hYVOSFyul0e
oDEY5D/p8Ai0GntrqiBzZRCgS9EbR1vRj6uoc8MNpdFbMNQU8FpspsbJxelr0bEByzv43u+U7DkB
Lsh8gLXlo7DjL+YPKXOQFvZqEmaEZpIn4M3/KtrP2iBHIBdoBbOIaFEXxdzmx2l6Qvk7CNfjmU/2
jqiWJRSDUtPM22mwti6MGUwiIIWSmYJLg6mye0P+3PmyUGYzOayAVItKiB60/1m2ukRX246udLdk
HsphVshX0h9IMhzO/XtKrEaPwlKGDx5SBnFl6SWSWV/So/WRMB5gxM4hW0/TUlhm3NXIumx22AO3
MRor+yTh4PGsMSPZ/zCcx7rXm8wLgFq71e5V5N3Cxo+JUkqOGTLqmAPQK+NySkG7wcC2F1aXe/bW
UA/ABE9HLrjLPuTa9iBifTM9UTts1nfMmeCJ7dF2PBnX7SeJ+Pqf/L/gLuBMtGTHInyOaNPwFLR2
QXf/VnNYjo//o/y9ACFjodBHCPP7RBQmtdxDJZ3dUtsur/xVkr2PtoK+DRFSmJzKxSoKxpzJnxf4
0tKMvNjAKrJOQxdBk3Rgb0zsNYOx2jUUMXlp2EVDEz7sOSaCn0XXMtkIu+ZT0gr3JH+jibl7dFaA
EM7kPDUmkXLx5YuTrVqNjUL9X7jJHRYDQQKymrTcFsiA1RyKbIZ2q9hRKHUXYxG+fFZmbX0lysxR
2fapFNMc/8ztZ86KqK8E9X77F2NIwnzZ0zQ37E8rg674RT7zgdBZR/OsNszvbFX7yVr4Bw0yL5Cw
+jdho5spAeoIl2w3Tla7AFX1kAWwpC2K8D4PK003EJR2gRzECrWxenZM+lUwDupvNuuaWpVseSqA
snWKU+KC/VeVGwShcH4XLN5K9lp2lmf6dfarfRjsC4pORL2/bFIcLIdV5RhF+FuiVCu9gdtJoQnu
46ZPVadz9q4IiN+rBRrHydK6m2N5XCiwo/T5VDFolu52KkLGOELAQZ3cewbqvS7ZJUP2jGY2D9wu
DXL40iSLjqH8IWspejDpTXg2OTVltf8IaAkeWXfBc3JBNBGriSVxELbANbXJbiV2b8arj5aF3O3f
/xFBFCiNhEm9p2qdS/RggYT7JpZ1oCpeYn1k2EZeW1mvcQpIZEBjrNq+r2dItrwGRKbLH7HY2yr3
7W42bD0vO24ACrnBlt4/1TpF6uTAL8zog78Hz3W8Snu9hlDn4NRoSZr2lxJWeApRKL5vkRoaYwQF
JKkVx1f/K6Ju1XTzm3/fe3Nf9KP42nrqHis9O2xaXolc2Z1zSAhGiuMllXxtLoVV868w3ANuf9vM
kNuRV+KdxEgOITh0SXzS4N8T4JPMWdhVGTYmqPE5O7uSE0PReTl4yEc3jfwJjOaQlDzXl/9fm2bj
CXcFDVbLE3FdWB9xNhAz4LMgOCtCcwIMkkwB4jZRscrSlFiVY3wlMJIhBb3xQ3zrQX5ORHbqeneU
3wjenyO+ALIsA9YTR/QgC4wpFgHNGBM7dc7sypqMWzO2RCN0GjnIZwzvsFKVP2bdcBXrbB8S//mp
KPod0wgCOuPFuTlPaDDrYjbqEsm0/ZG9tLZIuB1/hyOMXUzeyG/vtn+T75AHWE4+GJK2CYfS+3zo
sA9Tz+mAFbsb9fLBs4Rk85iqLkk5GEUr3ocp/OdUnpsWdikv0MpUacBmgjGvGAnLt6x7FlGIxUy7
LC12/TjTSU0uYSAZnO01BitPUNJDP59ZglKABbl7He31j4ue8KeaFeZPQnNaBAnoX/yuC88Mod9X
XG19RRK8e763oZ1i2SRgCNpgyl5DyMsmirh94vl4kth7TJYwX/dyBbslkdTmi8v7vhVW3o/bllck
Fqsswspy+JDMSWDhxmxmT0FLfhpkaU/bGRR7Zfgc/Gb9N56+ON3+RUUugkC++xD3EFrhS7MwlAl7
sJfXiL4OYT4+cqwaKhzllv4elxr0LC+ZMkutQFDTLnNL/vxfar7R1itwQVp+gN6n5zevbv1Rv1AI
ZLiMWFi6FjDUopIY4bSYQuFa+ztLQWdv7Olm7gGH9Vq1enYb1hyX1OEBtVRmjBhNqp2tQOD6fj9u
chibSbrqM8t2uLim6GdXfHnZeF0Ei3Y0FmyBzGC+qFrARzFGigEyu4G+JmkT9LLh1JoeozZvPO1a
FhgB22qEGXV1reYhW9t+NV0VFkeQphU0w88D3Ka4N9YNfAmy91a1yIpV914yyc0702+B2wq1ztb2
hvtZf5RsU6qd/lSRedQwoXWAKh+Jlxt65iwk8C6JMF2RqiwjcYEbeH1Dtl7YTJapWHICl9MOlHzW
xVX9362fFflJTi2tl0RlFDZ05S2stE6AoWJippsve679+lnP36Ik7mTq7NGSKqmLBnGZgqLyDP6B
z3N+zAgWNRXkJ7tg2nKSsk5N8yVqP89tPJ8XYI1LSisdSsAf72Nwg62VI7fHUPE3bLPmIFPPPDi9
2Z8RUovp9h7zOyzWtn3xGBbbHumTmp3rkc5qtNTCYJWly490kJmc51vUFdjtyeKSap10xozDNzVX
0F6IMZ5zQTbR3ar1txy9V4fhRFm4UaY86lNM8PhWWPI8Aycr9Ws1lGoD1ssxr4y5GrUIoHRDh+X/
2sZTyZA897rN8yYY7T6AO8cCW+e7mEAM50yckuMpHwlBdDSWYMhaMMiLjrHZP/S0rE1EwT8u1dbg
uCbsdNM7mLeo5YkcBh5zlK7OuPbaUxoTnsXWHoCIQ0vfuacfbGtpAy/TZLdU7/fI+961K0mYIJDq
6YnfscZJeiF92P8xxsklcbuI8viV22VjfDeAEtPpb7dCenRFBfc8q6otZ+L+uAiygNRsF9YDSUIh
kqjELuv4011uHkUd6TtZ/m4qQZLuzD78NNFPCd5fZNLgNyb6LcAvE0/DRiaw9jVFq1udJRMZac2b
YqA6N/jWC5Dc/YCWLeGmq3RD1dGOnwG51m56VMQTs+5KiJ+3xJ/HpCen+vty9IJOWCjhV2jnNATD
AZfCNLajdTcorQxSLyTrDbZLc8NLRZNfEFM1KMA4x8IHAJ71FkUOeCF4W3t1UMGSXvbx4yyAsZFV
lNYdUREDkjNBlNG7utixOHYsbeodeluE+pnM7SOOhXxp8WqsrljE05Gjwej9adjgIdtxFXYrzRXK
NmX/XWzg4ox/Fdv3G4Ic3fEu+zYWPfZjwujparLr97yzwimAudG7LMpOD2DYg+8BC4ut+vz1AeJd
U7L7RrQgOZCKoueA7pKoHBB89j8GjairNwmULeXw2SARiDW3791C31vJYTD4mcZdRZOcfPqkVuxL
mafy85C/WOHh5c4m7QKwIk8Eh3WogCQ+VKE/ncFfgbbI0yP3ebO7jVs5c5pOg/fjUvHMqi+9/4uW
prYUQNklknx102oZjuHRXrpTI7Py0tfzNdNnRFpO42mgeye6Fhj1S7rOFX4iDpnZv1MJmDMiAzky
OgsWpyCBu8ItDFMUHaZ2IbErD+dYh9xEbaEVTsqeX40tJ8jFiLiIqDtDtKdyrpn+Fa6nMYdMk8Tf
weX+ySLgrDvAml2LqHkEM6Tw+OXguLGOxonc6Dsed5KljCbZFFYHKYvxPMbAGmYTjRG9kD1FHtzR
d5WArhcW0bw+zHatotDp8PIgbAiHdUEo/8WBTKW6R1gzsZjTwsMugM2MHhTy+b7FM8L/WGFrltnf
/+ZNIeVjzh7y32xmZLAQXrRm9cVR4Vef4lPa55D3shayll12I4Helt1a7TqMSt2RAxvoEYXpzJ68
QsfwbxON9bd0wfN9ZbCYuuGfks/GSaaINCN2Zg5MyPsCQnf7qe7dgM+T4e/kk7lnDVN7Jl1vbcf5
T9uJX3Q2uGI2usuu6qNGsYOahpSv8i2GYjy4YE0pXFVvU1SWkDi8wMSVgeC7tC2+iJzePU8kFU4b
QEC/gm2Mo0riW9Ft1rXr8ASrsHI+l6gywedd4a3Pz6YQPVMvQTSEHDOrz0w4GG/LHzMvrjKFEwXW
1Ny7UuAUYZX3EGjVcvjqSRYSIFubbUZgKhQfVp1VyZfOZUeP4nn1tsYViywsyQSKobs+s6cZUSEa
Q+bqMJvp7YPwbf0LikaHjFwcJhlsxhZgm0aarFG+eRhV+NLUJzVytwXuo7Py2wPtS+g+ann7LTjK
ErcATCm1VO3S6GQqnwFA4E/akl0OMYfmSiodR1+GDmWWe41ot9A8RoePxDZ8MlDm95DtZRrZIWsV
a7qyJSiCbXQpi3YB2XrG7VlRb81FnJD89bvmRMvUlsCQpLxVmS9LpYPWb+rnOUx2pR9XH3/g4Kke
6dhNAhb/9EjR2igsPfxaObeD9pNYc4qT1Tdj9c+5OhmIVOpp5Gr5M9KyU83Gi/d8mw5dn/lfPCNl
0E4jyVLuQVK2t2OUGqUblTXGPqsKK1z6YMQPDjfpgKYFAmvk5Cdy35j0GLz+iFmGcgU58NsnvYF8
UYfnRJ5ftwmiVMD8SQ8eLTz98rsr3Hvfhj1EtdckQQAeKTy21f8EvEvN+8t1lCrBhBTIct2iLW4j
d2Pvp+y4f01p2lBsGyulzOZ4JcTwrZUgLwokFYzDGIuk4JcG2Yf3LDpuf8Go+MUTW4egdojLOwzk
ezox/rqTP+vUBdISsjGy1cxssiDlWJ8IfYSnjHIQ3B8YrA2bmrtmS1La6F5NpfaSIqW6YODfHWoW
l60dZcpwwkNwjaLCmpUQMjsdIIltv2b439fswP6CqKhWtCFyfeQVBK4FvVX4+PLOzGCDOmj1MOX7
5hNbgElKQebp/yv5fL8Zwf/kCjJW+2PD6F2po/sCwcYI7ew4txHa+whPB08xQTlLpOOw6n7PcsTv
/H2HsiyTh4X5nr1ruA3uUqUzKjf+wWa8Aj+GSeNP3HmRZ4gTGpihgOWOg2Z8oz+ZE1NJk7XZMDVq
93Xr2pQkSme5I+mLv4Q0JuvMTsZwXmvr2Cn4KIFjpPhKKMmi3W9m4GtuIoH8Oj69lugjDWzwtXGl
sFgvJTABbmtxczleIsqPxLM6BQ646unyrIpHEG21mZSoayyQ93yYdFnpmE3OYEMIu/O0cLPrFXIy
IyNplEPBvaaJ/qrgNomrLJPFrVElIJZXxemdyAXB0LIRI53iB7UNwsvZoWvQQ0qL46uA3uYjRY/R
iv3B/cqVc23QIsLC6YFADsA8m9WpmMsjwVrBgJ6qheiOTaMX8w2lWWfWPh+qSUBspuMO5W1dQuRK
u66ChrO1IFIWLXDb9A41pa8PUQn0RdEsh/d1YazHJYRLN+TKOtBLdlGphYezFjzPyqz1j7g+4TVJ
PNoJIZqfvtRxJLWlZcvwWDU/FQqIFKGa7OMfi+GYaevyznFwDQ2AqCDiK6qUhSw4KobiL6p+kbu6
AOl8/bl+xekuGNxsIpw6fOQl8qjtTqQBuV9+tHsfTZS0IFY7mTs1SzlTZoRnrOZQWl7MznGCaB9m
SpPjafbJDxtqMsJDjc9Gpy1IPGAnkM0BcbwDU3yRXOF5Ww8iXAOU2EA3Ch7bfTmyyt/SP1/f+kOf
WCSJQOChmfeZpRc6WPem0hfESisvqM4PNSMe2VhqrgZ6Cv/V3AzmjI0FROrCR9V4PbQoW1LdhHbx
v/CI+z3SnjemQXEjyhYz4DUVndAaGg7fFw3f5tJkvwnVswSprqPJYuh6Qb61PsWv1OWlcwI+DfaY
ZqFAfuM/s1+JuPnTHWp2sWAZaNktZiRTU102kA8uWrQpv5iU6iJPemi11KY5/HyDRxVReLnWv9Oh
hd3+LCQsZvc4zxblHXeCRQM5DoI4HrAiQ0/AwqdGsPYHUgf/1lrv+yeTvW4m5ZqHLv2pH0/zmca3
Mgw3wyuVt7TlZIDTPevIhYKAzYllv9zxD7iXEff4l6NYkbYPfhcjmCb1Scl5aHBO+L7BIxpkfaMi
k71gXd8Fqs76W6W868ZiZLQaup19ERGOf3UGtKw4xcpODYSOHsff3nDb14T7JmZgbThuF5N+WslY
wCw7f2mJeRsMyHBqNvXY6h2fQxcfNwILvGk5wD75HQxaIWIqjDV3bPB0C4BuSj6ZJDOJIQy6ruif
b9a20jARL6sYHP00VUngcdx0q7jRinXnIlCVBBgQsYmp4XAjUquTMUcNFBSLAjqBfiqBfXYvMaov
eGr05oKbUVh7yW516kgeGZqH0G2c9Pli+V1gc7zmW11JHyBSqxdXPGj7FnOzmKL/Bsn/kHmN+sz3
1QjChdYsb7o+zAenhnxLXuLChH4F4y1og8zm5S5KM/dWhnLrbBEKzEyKI47N1kBUFpNnOfvGDYRT
Tnj9yPhVO7y7g7CSbwZIqoDkZZtO7I1sAAlwI/FLURa+JqQqadUlNSXyhEXvp5BD6dAposSt+Dl4
m7AJ6+ayqh/n3d5wXQeUHjTfL6TN9C21CUYOhEFGgqfR8j7eVclXOq/Bv/XQloOiWT4piWO2I1YE
9/KsAGr20NDi39zaNtC4Uj4HnM9NRChlFSg0MkSdDoA+Eu9ObrLhP8asnqdMh6tApPbWC3C36Trs
myBN3y7I82bLa7vZdZtaRcpUey/iJmEKVNrI9PHJo1wnpsHbhJssFz3fo+UcpGvalftw3QsoGImy
frWvngYQRZKfaAFO5F5m4lLWox2xhyk3Q8u8xlws7KIjoPirXiTtqe8NYZFnzjKO93+VTWLs1pvw
9ZIpZWQJD6yCY9NjqIsORulmAsEnh9hd3fTzC/f8H8sgx0XR1xxz+FDvJyfG+Pfzddqjr05MRJzB
di+GQEQgl9Jgnz4ZarKB2UVdiAoVImopx8zdfXZIhPbL0Cn/+niuRPiPrDYi/hwv1K3r1HMhJEuJ
0WoiejXKnfgDH+UeCWRKzryeeUg86AUw2ftYNonBLRsnmDifWkW9fQMLpvVk122xKBqzSqGMnoJJ
OSrudaYE7DQVmSaE0tVwes2zFHJgj95+hSyEvG7490XR9YxTKcXCSofsq/LXrd28pjf9fMl1+zub
+YpfltHSe82dBnxnpvxK1bL5cq7NVo2NpH6jfr0tgWT8+lAY3DwRO1fHWGxqGZnMl7hxLFkymWuI
/XB/Buad5OHrDyDIKxmN6vJiuPzPq2RoRQ9bRLuDyaCNpVJ0rTT3LMAc/6oVuIrB4SCEhxWS8Vyt
aZyYVVhsMJrE5vdxsxGNlgZhEAucKMPOtWfJpkIhIG2xLaxYNyNNChzNZQ7ox+BTSlJM0zu+Dm0q
i3kdqota9tGiYPQmfsgn4aXqkC7EpS61tMWxV6d9BoIoGEQXM2u3+n7qVO7NEvGv64OqF7x2mPOV
UIMSUuK6vfF/qF4uL2YjbxBeewh81NkHjljn7EQhRLWvT8gXMOOWGUbuNRMRosbl/4HlKx8/2DSW
roXtaPmx/rnzc+aTOa5wm1joKmyT0nRdfKTNSsqr/6jZ9vgzkvhEZia6SzvuGcfXO6P/bwccJPxy
0U0sZYVc3mKtVIwaFw1uxqfeOtz5RNYJnul4nJ6pLXUnEOx+MXZZYVO8Mja4TkCcr5G2tTbBeibw
i64iIBGHNezfd7RiNRUCTCAxRvLqpzFLI5EqaBY1xRGjtn3dgNb2FZipZXoA+HFLRTASzFckMxrM
fpXxTTJ3mUxfgFxUGedmD0huLFQ1g18fp7aLR7LZAW7Lq0D3kq/Y85uC8Zfv2E6lPAcj0WJUVRbZ
LO/VyFppnUd+/8s7nlED43Y4YcXNpKgcC9jz0G7pst4BUzRmrBB7bRUSdi8Bf8S2KNEuM/FzML6O
E408e7Yp6lZgJyncvlLiGYjPyAE607XhRNTYkXtp/gZE/w6rqs23koCudgC8c7b5l3+HScQ5+aEm
R61kJ/mvGvrLYT3MVeXUmaD/sSSyzR0LGsAtWza2bae9DMqQ/WvJ+jUBmbLIVE/1sRQWgDDE2s74
Y4f2aBgGi+x66pUCQWrp9BOuaW1MfN92O1S2kUpUfqaOvozA+knWGdfyNL+OZ+VsZRD6GLIf4e1x
VdP5R1PMmKtAZIHKRy9ypMPzAP+4bAnpx1j2XzAKPpKVCHhcV3LEvCv4wS2Tr6+OoXELWYnTcLde
RQeVSdFkixhHhnLxOu+QTWircCudlf6Yq8oRUhanGEXYRL74A5QCWu5jBvR96X8oOTTmQpZ3+42Q
sbQ/Xd7ueOfBYbuXd8xrHtpZ1ujb1T7uz2gHkKculhYDLlxnWPzCkNBPPh8In/AcxUo2EadVxTYQ
FfDOIc1eYLn0u1mf3Ccga2xV6puaBtlZ8ceq4HhvRDN0bHyczGeMyUNwch3ARRiJqOho6CzWXf5f
CeUaTTV8Kz8GFTsuJFQI3g5D5UkNHAhZiQzEa7yA/en5M4GJCPfcP2Ms9/YdFX5KRVnsbva1gQt9
Vck4eHZy7ysOTECASICgF8WuUKjo+w90gROlL9nqqEGhoGbhTirLfj731EAt6nnfs+9V7blypXNM
Wsb3IdZQ9+GbHW38fm8qz6phkGsI20WkFBMb7/4KhrB/hHuP1JeDcIuILAin72qoAJRu/ZlbfFcO
XM5alAg6PagcTmS3DinxLlYV4Nl5f9Jx3SGuSd0sxx2k7iNt0bNdhaVoYfyOA0rANBAoealraUDe
66NCHDrdOOpCNzfqUqBCzs87jwazK7gWlYqn3ioulolIByzXzLpzmJCR7OQGtNMptIdw5W8GvWRb
C3BsAg1VHE2gv7q7YOXL3eRt84jCBp6SMMGGcAr13p2NCZBYn2UWm+Y40tr55ozHfl8zp+DefzdS
JjHP4iYDQM2EulEOXYJQPFAX73FanEpu1S9h7zdnV94dq8lrs3RIT0JLi3NHrM6DUW5GszT8XeQm
6XXkazKEa4VC9iGy2Zw/97XWZ5QHeDTMaq6B4oJPgMmSUaVX3iQ+HFoHAPE2zZbyUsc+dUym+Sbc
gF1ELsKH90eoMcHY+MdG/wAfXDg7JKHLtaiJiBkVRCzwkYURhIealpFvU2CoXer61FMu866lhDzd
LjAYSXYBPbK+J2gujxKgqmj/8LZek05p7veqlAiXx2g6taPQ87iyZO+xvHx5d86/3+xQtK1HcfTz
QZ1lKMkEMBof+/GezS5hArNh9GJfgiQb3wMrmjAdBvYMMmBMpCnUYITLTpKYUpV8pUaic1ZW/Vl7
uUPRM2QkQOBTsBc8ZnoTg46Rh04rzrpVCEhtLcDwnSMmS9biEKUFFco589Ncga/ux5Xt/wT7s5gl
JCPVZseGj4HecI2XeL3uIEoqoznlw91cMZ+5S+8yYnugpOP8pTE27iMG2Yl0eQoLoJUzFGGPa0+3
HQXin/aGrzPH8F2Or1jkeTwRrWbnzb7dZSU1MWRJNp3/CM3tvR2zt7dDZQGtXOnX1oXpPgfXxj0e
8uH6FhK7cGqWon6jGFVMWPv/nY8TSZ/qVxLhST7fbajAHyy53UYnWLexkntQAzLENwG8oWM2ZeXj
vHVRYbWmmGoS0xWVG20b4YJbjUEe+W20Hhk1FAtrjbQ2FYeYAJhjMeGmAlVwuSlnntFGuJPtksVf
tvYVpbT+z5b+JHjTK/jYnVDHd3Q7pIkdu1zeVFjOLthOVXt4Z/5xa/StDYI//Dg6ZfHaCmirvXuY
FZMxbPOYigRny+Mq+yjlFeHV2spDAO3LeYcToECzpvO9XGJRVVdfdH1sk0MkiJ2LjTgcPSZQDoYY
NVHZQq9oDtHaJUMUTS0eVp3SFaxZ46p7s25vjkabKdiWf0Wp+d4Zupm6C+GiscWaVc/L0mx62WMx
tIMEH/ArG+mHlijOtKr62L4Fv/YYUMjGRqqBc6IHmSO5k4caHNP/3zbEVBHRxpgaD67NADv4YmTE
AqHX3Ro5ZHL7D4IpZfCOFu5XbLBGG2bina16yoWhrv2Y2aspsGX3UWEYhxZjrzr39ShjUt1oEhGp
UICqoXDQXnRGImGLPT8URii99fYJWicQM2Z3UP9XPiMrvm2FqrdnJSptfDSWWhDHEF51/D7ClUHb
tvY4dDjPGHrHLwlDL6a2lWM5cByabOVtHwWd6oeRd9JmSjeimv/4yO2yzeAJCujxZj2/iD3DH2EB
hN2fASPBD5s+sKyPlwDJ/fb46cMAtZ8qvjbiTj8D1x2CoWBqfdZ+v6sasttb6HBNI2iJPnEmLzNV
+65ISH9k+Ditt1MW1uzCLMcVa53s29VE+xUh7KTTek/TztHAf/J2Ui0Fxf4cjcS7aJc4PGKaep0x
/wRrR5nJg9h3Ko9PzL1ITYlyIq8l0cmIy3X1Oesn/wU0X57u4YfdmhfmDJnmZMHMsMZc010IcUSo
q/RrYSuQFeILTkTtrpkCuCIoYeS5bkCuHbzZU4CLvlYYFq8yeq0GcCejXYps4vwwNZhL0NupG+sc
jDtPDY7dlGpJYMv0HXSxKZ+2x5zt1Mhit6c+4A8c+8cMb0CSWzO1/TIo61er7Z/m/7wXaINqJ/ce
LK5dVOcn7zbBk1ctxqx2aQXZRJoxy9EsoRJpKlnBllkYtz3xV7litnviHZqHFb/lzKWn+L0zQkTI
5imHUYy2CpToTs34UM1zz5TuW276jnJ5pFdrghUf/xa5wviPNE2dWMc2yTGv2MbD6uspD5w64/Z7
g/bCbUCPqHhq7vgX/LQiMX7HPygxVVUDK6slJIbqS95/XO9f6ZlT3btA38u24csNPzUqL/XeJjAq
x9tyQ6XSftNhLL79s+x7xctujcxTY/9Iz2e3jH2v15faM44ne62qoVTYPhYoDExGjyW8w+X6e2Va
2CDI+xCWvyBbFAnFly/Ckv1iWWatmWhQ32aHpwXTm3XW9Ca0gjanUaFFxGddmP0sHollk75aqIIA
haTql4xChFHrY/VXy8V0rhtm6k5xKluxErCx9GGzgvu7sxzd27pGllgzdolbISJF63KdPkjuAc1M
6ldteCtefHGIPjyQZYbHfGQ0Bi9L4WJZlkDNks2sFtOZrIEZFdDJUQ9xzzz5TwNjp6ZraBcxbggR
DOrRIL2mP/thEX8t8KWcdSGpZvrQ2IHXD7tdwgBErsbDeTgCZA+WC+1Vmq1rna5Wa7Wu70ZdrIQR
x9rf3bZKBd4YGke/OgRjk+830DkQdMq68vRMF85r4acD1qIsugDKI1nMOMCulM8PdKWtSpYUWZAh
p0k5Tpiskz50OD2PQOO+K5skLhKbSxqvXuQN0Nqxc8OUuVZ7sHaPRTwtfTiSD6cqyieh3VBy+kXe
sd/TZuuwOqea9PsRN6L0yCGrtf2GI0LtDbgdet87U3I894p+XbCnRGU/EcWOpiAG/C+DMFArz/1B
I3r9qow1ncg6cbkxA4JjoFRdpCmuCpRt2yo+PH+4cVjljUwySx/6ahGFw4bc7JNsHsivGUmXwn6u
y+ECNO5ymV5Qehr0wrAl5BjkORL+IO4Ne2GNcQSD3Pycp4PBemrD28qA/yUmYNQzvgeKSCIOSSxk
ajWqgS/tkE9gHw99vpcallfWJH/V6z9AwQb1/8S2JBOqhGusaNw0T4LOS4hxXNLi6vQyWK8pG+de
MHYmFdG7TCRChiZ9j+B375Lknx24Mxmp1W463k20F6wuewHVBd0IFai87LcfewMwaUioE1BnLg4t
0hYFhjrCDKnKogAiHysjO/o4T8Sxx5ZeSEmrbbAXkaOpmfL2M4rzmXBNs3PSDbAtksm7YfvLaujp
4zy4S7Q6yQkm/KEW7J0t96ZYuDT0AqJQfEvbo3MPpn6WxZYeMokgLRbR2VtsLN+OWnf7gx0l43+t
VTS6T6GZAB+/YqduYSVsP/60+sibtQ9k53uT4PswBoBf0S5NKcUtPdr03D/UMhCD+pRNvK4xZdUM
VYU/LPClfkui13iSDxZEJ6n5KIs3BsU6Rk/c15kzhHlNlLenafTMrjr6jfjqlxAVQKz2EQY62MKd
l6Q09iQnLEZD4pbNG6szmdn5oXLw6hp/hVxabs+oKCCu4GBM+U9inlIqEO5dK26dzzmLBpcV7tVW
bxsTjHDG3r0I/P/GFLgshz0cddARyXEzm2Kg+v2LWabKZvafFTPDJtMJ2BPsLwMUyioaP+sDWvY9
I9D1WJ+WQI2gJbCRlJ6BCrYU2aJIc94wnhNncrOf1BzSot5SJSvm5S1YiYf5VDIQNz5Y3/ZOluDB
hdz7wu6bGTtFJJW9LDcpvaZze8w4Pnw6CRLG6rr4YvXDs5g0ZBKxkVX9VCtNLSPnFW1o9YkgA3VK
ukEpqHNierWi288pvZJNfNBby2mXnyREY4USRz9CRZ+BlzIVoeWEALeVV6hjnn8ZrZCJlVL3c10l
dtg8IrTQumtrgTTFyfW5KVRx+lrHEWuZ0W1jRkHnjQ/WBc2d98tniJhMMxyoCaCthWqxIvr1SnSU
4leTEtvk9YeBtwZpkcYfcfS+hMzDqW+dnKHngEQQkULvchqFCs0Q53/98Y3K0JCl+YYfL9Yc9F9L
uuMTh40Rqj0W/tdIsVnKHe/rNCsfBTrYTIZcDODQ9AVHFD0dpahByaOkC0L3GDxZQWWhkD/wj9Ik
zBZL0mxceuC6Y0CBJ+IEvSARCLDZfyHEMZDCB1AUnyBaBKrKSyuL3qGy8a0f0n8LhempQc8aUef9
x4yQNDuGAAPe0fv5H0ZriOs5f3XHeLOL1v/G7txj3rFdpRJv8l7Oy/hdVl5zQjjmQ//ypwuLP/dB
8tzj2kHjJedfLshdujc0jalcjTYmxAS0bvL/NdLcqdVE31p96lDO10LyigszKtBx0Jxm3mpg5ZXD
mXDG/XgV0IFutnj1HVtD0/XUXvwJDP9qwHmM5Z1AoNp0X8MDrUdDMnnBPMq3TnxkwV195GOe+O9g
EsTMnFH6XPtmOtmgU/63M/GHoLwR9vsMpqJPc83b+lISwi/W5Fd6HPka16Ep06QVck6qqGwM5p9v
yo0trHwZ/28ZY/4LdtNdoTNMJsJ9HkBOqY2nr7T2XSk+B3hNwZ2kn4rUCMYxWnPBZSrNTCoegVI0
lhdftEw3QRwHbxVfX5Ani246T+zUGFnFnLpGRYSUCrqpPJegXICgDWX5ZLDrOCjBZs9xwJ1lCg05
65bJlkpJsg1aYZFG/kNVvFiaMxvV+oj5WIwYUXL3hiwR7UiOznK5wed939Mp13KhwayDScDEXtSO
PKw9XYvh2z7pzqAsGmjFSkmEBKBqQJ9U0YrmZGU92zuOOkYOUCy8WXJtuSx5y7m21TuTXtQiinFg
B5v+YH1BG7XHMhTlH9bn4f83pE71pYdPsL14s2IRQSU4jiWR3YIyffo1YyZbLCHWJ2UNPHWLbd3U
3vw5yCpjE4dOJs4VMObi067WIn//nEJU9GrEK7lX0zjn3PNlKOKtJ12OQ5mO/BzKoAJQ6DTdxpWc
ubkNCBVRwpudGn+Youz61ecZBVpoyL9wJ/dnl26g1V3MVR93Y4e4DDXpNGSH9ukB0+gG+Lq3ibuo
y5oYXoG6Ia1/H16oFMP70wFu6KM+ToTKL8/1qAOxghNpHAydM/CXr68KnOTIpveXB2WO62oQB1Y4
6u96tWKw+qA/tGRN1GjJoIMmmr0qTfbry3vAkqBtmdP03032V4Aj4S1R2ORWL5bm2sPiL//CxcH7
/0F4x8XixBCqn5otRHEyoq25ZSFFaL3cnrUx8Pi3mpxHIani3IAHjQO1+ahwGWskgggbiNybHDXI
FoAwhsnHR+9sKY/8hmnvMX2sjMUk4D8UlhSn359Hntj8sVRX1bI4lV9UEXk5kAC3T0GG5Gc++w+r
DWy15jf7umHng+HNHA7r/UE7EralFfPJKhOUoT97wh8k5R+ASN7BIEBc/C5jaxMh7vevzaNEy+2M
Q+OhFcdS1nuXxNFwrum8KFSLxp5nN+/7jDw0nwZ5/PvtKjbuOGNzlTAKlIqqp/luB6hBwAZfdHxZ
V7bFPq4fdDIpGTVkjtB/bFACatQhZdFxgaCIVjnWuAaOpjkN+CLWlRW+dUCE40Sn8IQDg8k3V1ZP
WcXygo9LjyAl6Ls94F/KRIJcM5Q3bWN1UfAT89dNE/ETZKFufaPfrTFLBay5GsMWSQ4F+0J0jGKs
p4lihBIc86IaIeIyJI9tYAUrCmi5KMaKZjQnms8iGmA31lgiw8E0tnzQPUvcKibF0uw432g6QKdL
tI2AzLhnD4C9y/9S4g9yQL/ne4110nJ+/hI6auREpim93+f6LiIEqZRVvk8bW+MRU+Et3tnzlUjO
Gd+uryyGMj1LJxAQDNMcTzh5ZtOQwFq6oR9PyhGnu8FjS/ODEeMEQeBfdIoAL6eD7Ygpl0Kd77Wx
Zyc+e8kdJs9uaxZEUfDHOgiL7yPSTNdEg+rAp1Hc8TLtDk/e1kFVkzbUqaom2QZfPYJmzbPfbAHE
wEriwxisCI3P/GI5mFUDibIpSONavjxka1028y4Vkf9bxY8xAhpgv4sZCaIjeX2e5yGJq+i/EIR/
SpyOCkR5gD0RHBeoprBioXV+1R2rQOqauQOtvCSyVSDuGM5Ch0w23n8uS87N8qvPP31L9rYtRf8U
gp7KhhieLF/WOLd/tobGEEny/HCderh8h4vJ475C2OSoifGoII1DNGfpgC+GLmWH6bMKgb5bePF6
9IAiWv4npI3l7QWNdx8Ny3L6JlyVWI3ng+OIdnee01swku+bjvvT7ilUnK8Js+qXRpAFueyVLdW4
zZC+xuc/f02mbTPQs+3RySmrjMV9ZKdh/9PL7r1DpiwOqgUVi84vZVKIBFa39DjXLsSVZm1jAg9g
NrGmihAKbmSCi2KI/7VUVxnkxv2PWlq5saB4QOnYhbOsCltgDbeXPl1elUh7weU6JIvhksX8eC5P
QvEy9zYqF6H6ADA0j1kPbfWhbNsM6h3TpvgpnSozZ7OVv620MQU4il5jozyPFAYbJUHbXJVxQGtX
9ASGDxi+DgQcHKbc6ByJJFRHjWxfVw3qoEHY50z6fmNai/KyEUh4GXZmn4EYnqnmipaSJrCevbpV
xJ8CLfiPp8HokVehSC4RSh3q7LSQKIuGBmHQJatwB6TyAaZN+OXC2fiXA2fvrHDrx88jB/zZV6No
VZfLwQrQ9883QZrjA4gzV1DesZLElvt1LH1YOtAKflDmWlcxTW8Hp/GVH6KAFUgYvcp6LNeajsCU
b8vP6oMuDcPTR1whu+x20wSzpocg+whnRMsoslENb9MdAg6v8rzrr9/rCPvBeqfk4LnNjc4n7w+x
kAlZ9inKD9jwfWLD9WxlPFWXCYdW1dCa/VE1nhsS3Pc2Dy7BbJGKifpc1j8bb9dlhq328gBjNtfl
JfM+LKB2Rny+J2DBPu/RPXUhdmlq4zLm0aew6qdZKUAcl6tkKxA6WI+GcD8f1ViY6Pn4F2WeweDE
frQ68oMoW07ZeT5Ewri774vjnQf9NMtbi+PkA7Xsq6jPUM88qqWLI/4/+1pSSIk3Tp3hcrY8jCm7
PzDQtiC9/dkua9MgRii9zp1+7UFrdx77kvHUHl1+D7Ep6+qf+U/kqN3B6Kfe9IfysD/tWb13KoXo
+5lGNwYMeMss+OY7wPbmthqW90DnLDBJmvb6Zh/GymxyGG6R3Os39dkxkjEXRIPjwx6KAQVUIeDG
m9tzntFJpZpB3mhTRLdx3IL1zPGMY0/1vHg4UdRn4uGG+kFpOcTPA5MKKI67BH3p7l+Tnhs4gifR
4qMRYLDZbxwLUf/fBTYrwYQqjaV97Jm8Jn+SLE2k6o2NiZEZnq/amkQTQv5/RGY+cXo+//rUen1M
UbXJ1uIZYXnxUNTo3FACd/R48g0LwRoDtpYsGWcDnPSiugxU3XPn1z2sj7RGYMrlJSqgf0CnfNoB
c0LyO05Td7gj274y3eYY9Apmqr21LEtqgXM1NbxyRmEibtPkjfe7Yo/QO95kc6BFcqgVKgrUhOGn
bd6s3b0L7RYILo0XftXbwKwRw1dMOVa6/d0BvH/iQX+XHJfZHIegDF24q6GYWhlYyFTUIsp0py6t
tztqtgtUOChhUlxmnpUmoYHtxrnbh8IwXxBu+cXUY562RuJKmrjUlgE+WlGIrw11muDcbo7m4bpu
BJKAYCXRZRPV0TkcQg9tyUsUAC8snaqBlwpkQl4MXkbXTvxZHzGhfyYP+3/YB87Mq/JKz7BZVRF8
P+udwRincKq3tcGlGF+7jlFkO9ddZYfGz0IyKRLj5tkuLmZuyMGgS01RhX2Wm3pbyjy0dNNQgx45
DWsJ0FozR/HRzrXIWV6Jzsieq6CsIoto259bQPcYVw+Fe3Pk6VQ3UluQjVqFmUN3EG3/5oMLhZ3L
iDPNOp1SIy6MTB7vwT9czDqfXYoe5woR92QxiOBwRMbNvDHkiTXgfcD462N+Yc0jGUV4L33Li3l1
aSMS3aljvoK+uBbR1XicPanq2NNrcl+1/I2C6QX/wun95/MKfUPhXfgNJwQQc+Mg+8OhRjcmGLa6
akYKXRSRSsbGkY6gVpVCU56L7Uae5/qzaxaWIO15Nq0s5OFOqlxIBCuSxHkqF4Gxstyl0Lq5Za05
yNf30FqfJ7XmuBonF9yRClB0uF6aweDm5jBsuZNV2BERtMlE8uwLY5+pGtCeyvkiO1y+fIw0Yy4S
+hIzogmr8RvdGiKK6MsB4iJY5VKSiZgQxZvZJkqBAzGDv6XmMW5lQbOVLlQ2Fg5+wWL1Ymwl1lGF
kVI/dO8hKBJ+dUP0QlAu+lvBoAvDydfBgTVGTiQebWEFvaraJXu+/PZUkpvV1RJw/UR7valkmTow
t66emVJWBZaUgAXtnGwr+7NP4GXR4pq4bVe4ezWBwz9MYr5pBxtk9arWkyFkO/sCVLhaUofv+yvv
F2bJH0MLi0P9TQHb5PxH3LMrMzocqDkwWSC+AIBB58EXNyL9y13jCHLXV1FM93kmdNyNCWmHZkst
TgW+YTzNT7jQ8sqeiJ9P8Ci4yOyYQeUc/k8JjtDRnK+Wmk4AI4sZWQb2xd8pLzNp9APkcSUKgfq+
NUDLNvh9aj4Wdj87TDDUjorEMHEo1KdIEfg8PY/RAkx4A656t3+o/p5tc+4x/UKrXporHC/4W7FI
MHOvVY7mwm6zexZR9geQgKPUh8OdYS9YpfCL4UcNunrutmIvJGisJ3bG+f4/Q1iQVzApI87wpAI7
my51U9AOQ+8yynQTXqiO0S9igpL/sQbGjwcCSbV4LpAkoDyODusjFwSeuLo1zeGowkCe7V3moEAk
bovhn/mElo9frTJzXIbKEf3b/DT8vlFLGD2aV3s1f83iHFobfWiBoBAbg22WgD1AqGTxD0pu+BvF
v25ZUWPGI5aMXR8dA7PnfW70d75ZUNPTdQrI6rAvEdvO+gkjHGzCHkaQLNoi0r1tGUZpdzAuD+CB
fcgPLcnb9EuezszTuAZD0iCzUVMu3eXBwSCMoSwgCis92ddUEfaU0+Ljhy0pk00yNIb8+YN0zQT5
5SidcwUbDxS19u9V3+4FolK8+fdyrFL9LzxQkw5j91t+FmmC9KQjvEoR8ieZ8hGGUkUZ8ha9Cu0c
L5xlXVGVMW3L3SHTd8NOHeSVPa9a9Y7Db/Kc2btAd1jiyW3IIJDkrWGIzzkUWOqzPQGs8VKy5M9I
V9tQwfUvXK8lcUJy98jLjvdZnsQGb0G8dyg2qmRGwyqoKKJfhJNodsu+g9ZCcBQqN7K3aQRVqqem
Lf0w8rLJhwMqs+u1zVG1VX7YBbcnDktOLitdtl4pi0VBHYwddYkGuSeR9ojSU2BYAZ1kZIfevr6g
AkfCt1whoaXycH5YX6UdvfznqIrxDPHQMuU69haFYZkJmu29KCUDbHWsO4B13Nn21W2WegIwZWFV
lOr4OBVu3aLQrQrtbwNTs+JFwzQ4r2uUr40stfoR2y1pu6Hc6fx8Nrl0zF2JUvejGFlAtnQgU6gl
s6YaWZHBpBMoDBdGlQKkCLGBfaCiqZLJRLsInKDVZgxuuhDo/K0rmA1EWj1St++nG8ZeV8eNTLFo
gm9QwFg3/pCY4mec66hiss/VeNig9Tl1mSXw0axz3shnnCSkK+Z/WacFseyY77LN7byTGHB53Bpn
lD6GYCmKbDf52HK3I36LMQMF/sRDHhAURlM7uaZ2hwnP/J7WPTswo70cfAvtgX3l05dFewnd1zaz
NgBBeSbhO0eOPVNR2DwQVVD5S4cKhqNjUnJV5qFuPc7/nV/Yc+/u7Bg/083T2cbwVX5HASRuSxu0
v9Vqd6xT82k0Mn8MKd9vBLEWE4cvgSPzWTHYe3SGjsDCbYmdnlpxZBKXeMs3e4qtqd3qS8DMSroV
9Xf3wGEgiEghKFf7EB8wYL49ub6omfqprWHvPFefxoVJuvQrr8yv6bT4nc4AwK1n3sRUqcIPXKYZ
ALvRJGk88w6b2EyQxgFVEFrYBocycrliMX5XXDGXL8IC/ovn39w4rGbXEacwYzJizNAX/pu9tllX
AvnnS2Iii1kqwAFLEEI7TGpNeQLIyWuzD+IhVVRheJRyVDpzDFBEJixktrzk9ojHjXBlV/o/K9xY
ADM40s9UV36DzKewUUjPx+CeRVSkrZ6p4VVo3WvVrnImA1jfONnZqz0VxFPJ7WIsGJDBPK4UHJxy
Jk0EZ+k55oeQGavovbllMjs5/JO+XoQe9SaTFiEehoOd92ymyeEwSutp5mGSE1AIuq1XtJ7lf7Ir
t1hGIPMc0kNkzMC7GthREExbEhXUs10zhZfbNTtKczw1i1nXwzGFNk6kGPHgwjfpo+8EgyrFdoho
khRgHxUKXiaBhU/4ejnK6DM+EJNPXPvRQlaR0ZBG+NXlTnJmo7Oi8Rb0W4WWB30ogHTE6wN5uREU
QzbC1rLwM9y8PdGZs2xmMQsvs4wZpppaXlPAJGLJ2aZi+1xJTPDjqKvOSaARLJoZUpgO5jhqxHrP
cqEX1N3O+wvCKQYFtCYR/chIyW61gAO6VpFOsAVAsEulnmYW02i2blVyUYg5uDPWGq/En2JVCXvD
X7ZRDULRcmPLlkPyMjRp6+A04jvzxQd1v4+SmGMth0DCGYyXjRUqEDUES99r4imcP64/5c4uYQyc
Z+01Ix+Ddt8/KAhsEHCRuiH8JopUGrJFPJqj5Ydi0L6VB3Otfxpu3ZUW4CQKEvogkONBvgpl9XGy
bMbln3CoCkG5jOaRs6WyAsNiEmUzEnMY5budFiZHyFbIKIPQnLHr9IY8C0bw53+lsNEBFy0518yq
NKLx9NhUynFUChMJgwOwJmKgIkaYWQgPsNAml4291jxeO7hoE5S/PaM0JY40XWI37bIWrye/qZ7K
6FkaKeWy+m9TGSRRjEXDOtY7KBLqyBtjf67rU1L7iU4KYLJPMhv1HxVVB5E2muhYgdSwL7MWBLvK
iVeDo7q1wD2kniAYjNJLfyS+JF6E5v/lSeLBd9Uw2OTiUiYckvXY6+iZSj65QyHIjiJZCxzQSgFc
4Cmn5OOT9Bd2TkZsa7MjtOSvo5r7CGbTfI7ZbS3DtGLomjj6YN8l91lgU+CToDJ/ZreGpVv2+t+x
7I7JMHgmUslhGpys4W/Kx5dSJbN64hv4q9UqTLXd4wRRXbHK3lB5FpN0L9vp+zmJH5DI72tFq16g
roocv3i6UNN0JUOcOXc1FRRVi3/zX119SX+r+PICuaepeBj3rkqkzE9IfypQTqlKb3YcbbCh50fN
+LLLavdZySmX92j5i9etIsM5DnjLYNDDHNyehBQOZ3qUJtys1pE60uXBmX0KaJ6W5M1txAoY1AL/
GpKjNzfdr/fiO0Q61ICzKdFkGA1MHLZy9jiIO66McIYkS4cKqfcViwXfch7xMnBF4IxyxIb9hxtJ
cnBgW473Jy2yyNDXHsV/SWkIZofrvG1BQPIKVAlovsWu6mRqHqnmnm54pZ4xpNxMf0V7etcsP4eQ
kULBOL1ykq4F6zELInAUjE37dg+5d6yfU/SYUT1m6CVsXmeeRrJvXYWsF23dVRsGtBs3xBzPpnXQ
UReUAps1Vid/bpkL3K6t/rftUvakq9tVuRnuzRAW5A6/9iPahP3OGSlLnPIjXq+RyEQJTb4XtfKY
+KflT0iH7R2BbNzVNiDQBUsbFdXCLdhQqSC7e+nrYHBxkAhRkjOTdvbWNxAYjdHhNyLfgajOo9fW
S2xw9iiqYIxrc4y2BkgEz72iJEosO6GImrH9bbJ1BVPo2vTZAefzdmF4bpPfljE92nDCUSV8zusi
+VcF+a8d2V7fIvWLWThQ4cB0BwIN6+fQ+2RA3tGCAjzi44qCgzUwrHvR5JZ7rM7pStZzWpXT0Vnf
c+wYc9CPrXt62NmiycNI/iKhwz+O9LsCLQofEDL1IntljZFaGzmJ8Vu+dny6x71yK3pxTrjUkC31
hmlRwI/tyQCjJtmO5k48wWk2AWTMnnuZmCRmXM1GLN1x6y0OGxr9P1GuSINy4f04oUp6jsK/0dAG
dMf1lOvvNMQnTL/4iMcoZTYUgzohFr96PQ7Pgu+2nV695qBsn4dhcmofrjAgrVsz6r9WrW1xhTpF
37p0JyLGKIvp5GGcGRADqmITcKy67Hmlzl14HfwJTS4NYe/bJsnHVI2NvAuTy6VrolnSekH6bI9/
uYemhpJKSilXasohfPClZJxT82zUR5HoUF6ulZNygOozzcq1ihqWHWHkBSYjOME0nezK3+8azZMl
gq+133ekBCfZ7gykyePjcOJrrZ2Je3Oip0CsWlNx9aXH3+jwcNi8lJk1fYGHWqbCRclZY8ZiUGuy
lcIMvRN7XsVp6qjpz7aNpPSLHae98ZQKQnRdq3yza+U1cyf8vc1kFZFE/b/zjTAYBe+WmLL4SbHO
2d6zHoKixAc0zhOnwXRhRVDMC4x0dJJEskrQNBBNei+wi5fZm4wZSAmzkeXhDd/JImK8SNRAcjMm
jBJNzK9qqdvM7BVkgDcJ86VV3g5yOqOT4Je22ix47jYR4eS55qQEma4enklWUYbZpWM+ZlygSrIv
aPGaQg4KLD0hli9mL+T4b6U4yWmyro74Pu82UixP+GgzN6uKpz+OyUWOS7tHxtuZeVSLsqKuZl+X
JrNehVHNWcdL3Fu4xyjvkKEa9ZdSCKUYIeAmN30boydg2HCE7bNUDxah0/YnKUFC3n0jKqoK3ZUG
LcTEgppH/ykcTcTDs6TBZG3C/pksqctslrdprYOYeUKuQluTbNxwXGsZvOq4htim3B0z6v6ArXvF
PpNgL25aNitH2RtFhn74JKYsmdnown6lDi5dsQnKIB2gfMXhx62qFnUpUUy1BxxvSYIXtYnWjfHX
CzU1FiUYeS58CnzyFvQmcntLY2wBrzZgUiqsRqr6fJMNELxHeuZW2nssnGNuFr5YwHRoLLGpOvAX
Oj9lz1CEljh2gd4HkYlCK6BuVkK6nSytwOrDJFrAGb4BvZ4yoXpLjEJuG1zTOEihXo4OoY0WPZGp
SsehYo412h0BQ6iiIr9rqNJ9xrts9jra7k57duoU6atrf7XMehEHQWFvcbAtI8zB6vtRetUoi5yo
E3rO46jz5MbxbC1GV3or4cV9cba1aet5JJSu3SVuwy4lJsYP7pB2PP7sOvT4Ue2LhXv82VVLSAV5
pEzPCRMQ2vvuUyTKzh390snvW6y5oJSR/p4bYiRelRnJ02ohvCcaqltfC77e3kbYa7MnAQagccqS
VYvWntjmKXFTvF4Krw4Xr5NfLcvQhytZIFJbfUtn69yzfJBJF43X+gNQ589+lg0q0H9sCE+eAFrV
4IEWEoB5G0Cj19K/qgn9dS0esZkoJPh3B9DZVLW8ZgU2g6xdtHki87jkDr5yddBxwqgNrZm0T87i
vSYhaNepSb6EkfG83/bvZub6nbb1KwKuWlnZO3Y+yhkDkSXgtsaRDV9VqnHLK0GxypBWXIYw4BxG
dw0DHjZQEv4Ydmb2+ziyzzKK5d+YxTlzaoNL7zLN2X/+Jwp/PzD7mGr33VVKIFWUSw+e2vqKwZz7
7641jowF+HvdZ5oI32Fui2xDN7Kp8KXRifX3Zh9wBYl9zeoEcF5AxPgojEfPkwVj62UI1/n9rCkB
3TUBfvebo/XkHTYeMFVyoeItF3et3l933YBJMM3P8Ta5v1hSEZxteRKrLzMNBYVgpUN+nzB+wltr
SNiNz0oGDXSCBAXlq/0YKCnl4vkKov0Y7vuExP/E7oRzxTMVLN1RfXwg/fIrHUhlA5ycecOwIzHQ
5SN5jAzAZBwaeI3ptgVYP/IROPclTnWH9M6pf9trTv+axb3OTnNd1423TxDzAAx17PyVYEtOCaxg
1ncxfV5Twz2x/qK0W0oeWBcDyXZIwA7sEjqwX4jepnTaaOfjNIUkWjNtIEk3vilisrhN7qKCeOqT
o0n/4vYM5ZPb0sPpRdvSNlvnoPdyf/+jPvO5pjqfol6R/Q1RrJhHW80UXQDeXZkvWYL4SXJrWUPA
deNjj23KkGuXSghUk1xRxuuieqRLIDwzsMjUREedj5Hpu5jcJdBh7msNXF01auir9iNvgJhNOZfJ
SiPrK8ZiCwMqjMr3Oz8UJ1X/gh2nlumkeR6rz8NXFlW9QVc9LLSgQ5ejbHtNQZgdt7WciQIA8g2L
DwIgv1fgNAP5OYKOgorj1iNtFNNfOCdew3j9ZuDOMbqieaHi3cI79HLPnHxqRGzMtKSZ/jJhAUOg
8AjSbH57QuxGwpkYkqGxto09xgZdnhfeonnRNDnVMN6680Sm6Ni07iEGT3Sfb50aptzQ+8DYEYz3
bwTZ4CV9V2pp6s0gcHEQAtCPHFEI4cqcVHQktvqL0jAb0A3+gW0GsVExWhHOr9AVG/YHPfRjmx96
mKWTWikdv7KENVfX91/zSuXD7/+TBvpAh54aN6NGTyPfE2X4G2Frv7UEU7Fd5bIX9oKL2dsFn4IR
/HY6W8bKzcJs+VGN8rn9ocqulz6YGPPVRdVABwdrY7SnjWOwXCYdDdJJvd27h5ZhwoZcHOs3E5mu
SxJdHoJ8sihskAMXsXN7ON1KxlRHhtQfjuakfm4JcK++qX1W3Sk94YIltb8oKw0pgDodmPcysJz3
/KexSVPIS4QqCvIXFUHw528Gi92U3KgukY8gdRaysxOaDRd5JereC76YOYYC2amIkQuxBFrGUY8D
KAb/dfo8tk+XKUR8h/I4P3dVEwG1LfAqS5uKGT51uGcKdp/wFiafM7Vlbu2/BgFDdjDp0pQI7BmS
M/FDtt4K6CDpfPxxDMVuDysfGrxx7Af6bN7T2B6/jA8fpc942jJ66hswQ4vETM0NZ0e4tNFkLNmT
HDsTKO8cbvIS0d+rFmuzqd81kD+yRdzGHkVh2sp5xf1fYZV6bd5/Unm4600FAWBzGLkza4RyQCOy
P4MghsyNIPfCiXHhYj+Qpvn7IYzeu5tbksTLqdyPD2/Uy+Xa8G4ueCQAF2HQElczwJjoJvq8W/5j
eASfDddDEqgBqkTLIFHG9mjeiUfsrFaz74+NdWbvdIdG2kO1YHdwgsXgIOZcmgC62HQas0r0W8B2
ent4Js9nMv4dPrKopfXK7dYRJfX4C9Rz7JGutasr5yhJr1iOQDrVh68PdXQZVHCwySxVanBuMm0D
XW2A+KEe6MGiE+1PJJnCgaqxP6yVSezDA2bgs0KGxOHz/AeFWcdiqlm3yWevlTG5UAIGgkeREWMz
DENgsCdUD9Z5wHy/jIBLk/pWn/cLZCOOiJmvZDcCNEg9DHfPdkROnnGMWcKoUFg+ztP1EPplJ7E8
UdoVMuFP7OLd9FwwUKAQ0gRFmrNUpHvfECOW+3s/kJ7yqagIf8pg0AxuEFIhoih1hpVsMecjY81X
lGHAhILVipSlfS5IuwX8Bxf0U0na3+KOMKQsMNwt3BwGnl0865bCrNqziUQNMpGjcSGcJ8wz5JOk
qSUjprP14ktZCSxRemA0u3ZlBw3hKq2h20xbnDgdeC8O8+polPF/v3Jk3vzaKkxxCf7gAE/Cui4C
1zOxEH3Q/+NgyQSsCW27tV9ETCvD66HlySkhXR/+s1W666JjYlIHudamTfwUGjaruqMy+LVPpL/z
cjRigtGqhktw6K7mlDHPlDXRkfBgsneeoucJpxheKNylKGqawgd9G9CR2yEjukConPUetVQ5htuP
M4YBpmo0vGrBM/I5eDqziB7w1YA/XR3FfO7GVasW2XNBciSUC5C1cOd6Wv++Hd9qRFVksVcfo1AK
+5qkhJI0NAn2EHiP5WqR3ELtx16L0New9VcxtHi8RA87PQtgnUyS3AVMZf5VCObBS+pKhjDtr7PB
hEm1M0oN+kTYs25gw/85yyTP559NKa6Ww1Zy8cB3bJGNTg8wie1hs1OCfuXjJM500T4l1v6R9+jc
IUpZp70O0LpjF2Xwh8r36ijz7qLDQBulfs5KtAGQP8Be1eHNFq3Prgn+mo9eLByEVGserslvsuFA
1QzdI5Dc2Tyr2iT748uf5cu9VLx3TX8mdpTEX6UD5MBOWOjDDFrurNjA/TuucthAW1rkj7z/bL68
LnrVXhXqnWGb7TJudxtdQ+XXy7mJYwpCmDPZFQ+8HTQUrHe0p0jib7JU9ekm7pd5wI/8hkhrQ6di
dJjBJ3+EaUNL0t2F4GICJClanJe1tRFvtC9f47yaaDU9YZwpwbxkSP6uv5qvhThEwRznqLin2Q3v
C0PL9nCBhIwZdScWqqOcIqlGjy4bUaL0f+/q9VWS7V7VZJzzR/I3tQfAlTzXzUfl9z1NGYUemU68
feSThNNi09uSqHEFRIcl+lIv1ihs5c6ywImW8d6zopIr9BU8JooxoiAKJforZ3MP80o1o/wL43/F
jyTU1QziaPWzeXTJ39LSGNjXTJeWvHOwRSUOTEg5C70JmeRfNt3g+iNdCduAVAH2gDfRVPYBjc9D
iZ0iAXg0pAZmZvj8UvwWiJ0+pDCc5+2MNWdU15DAxv6l+1B1QLnd3O1Xh611BmjfcxeVd7rfAbSo
92xAU05X7XO5DzPM0H8feDK+mq7j0zL1COYS8e6Xjoib6YyeNaLVFVv548nEpH1gmb2J2v4+En26
INJDuK9SB0VqhhrJprXk5KjWXh9ietCdkXR+6UTH5nLIxsqMr7AVqiWAHcrDLGO+fzmWJlXhHSNp
9y44APnCUbnok+YHvcdcugwkRZMeksZr9qBfPlquoA4xHUwG8RO37RgDWH8dmMu1l+hsNI2BFl1H
bd9Pt7zSNz/BnqhIQ4H5ibu0DSwTE4UKoa7at4pK10CLpMGGGTnGAWw1VB4fQSxEiOZqGVIBfNM7
DOjda6z8z97rGHUyErKLn4O8Xy+wd5AeyRu+qPeWswvjQ0sViDX9yTCT7d1MxRHd6cRCcFak/kSe
qMPatuxj30/HC/OrMYyooMMarapy+FASbHoSM6nte5OgnOH7t/6eg5fefcK2g/Al8KTqjzdF+ZTz
1WfM2gDJtduO1GmxB21PKa6XkM4BuraQmGjT39JrVR+38x/Q0mwcwB2Wcrf9DzocsvC98pf2Cct6
LgdttLgy1p/dpn55R8DimOFgJtLUiwnP9dtlICSgsCyXWT2AYC+mxMnrRKag9T/sOJ7aD/2iIPGZ
gxVTqZdaToQd5ilgeiY6+Pn7OzgoaUhV7BKao7kBuIOEya1nZhznLp2BRZ457c404b3T0LiAfLFv
DHcqAh9DpToBYrJyU4X0wh3ANxzkP6FFmORj9wRk4gWQcElGmASJhNnrqowW7VMVxSVi31LCdhtb
H3r0lydgcMVecEppbhJTj9eUa9O6jmhrZ8UAdvWIBdxkOl8bdoTIqXyQRWC5MHrlYeITGfCKu5kq
G6ZIRW0g3qSK5gEfMpEi1fSoUX6MYbZQ12Giq7FdpzoKLAGPWcN5fR1YDS5jwmQmFOyLGWhollUr
tfAg5roCjT8caFa3LyWrU1Uc0OK76RTcH+DlIeOrx5Ibd0kLis1FGDUybZR9x61423t+Dw4QRPQl
1kfJCB5yfsdLdFpmL+Z/7LvL9GWvhzk6E/VnV7bBEND8ot7NVd2wFBhNMX8rggbccwD0oMhcLbbm
CZRkOt52FsP5qB3MJAJsypso+qsdz05A7oMvn+vrmaEir6YudB+L03GIUEe3jd/i0aMjtKEIUla3
erFCBWPPymMVFzR09IXFNOPDPy7N7Ep06PKzL4m8BHLPhnxAhaYPSpPy1Z26Ld3PXwiUCHPBuq1F
lPcqmOSLyzPl7h3q6t3YRI3EBaTbmNwhJwsvYtUXeTjYx9RnRcCM02VkMRNU6D2jP18RBQLAcqmj
RCPaWZFiwWC5qEpKxPQzYPjeDjY6pGhdGg4YH5N+mAEZGpfiCt4/VyHW+J7lBnMjycMwOUUv8BB7
NwsiZRnsenJnXMlFxar2zM42Ygbz3aLkThCjLGB/S9gUu+GRBEwEe+++qHwn5aw50iRMaFaD5oHv
UR+I9jAAXW14YIn7ZvjeTPHBRXKww3aMaUdF9A5nls4SdU2NST542/qqZMsoeeQiLxEB+VYO6Cbs
LXX1nlkR5D86nZMrkqCzXL+yUfXncdafJQF01Ux9GA/PZIBQWcg+FZjY+IrcmjPqnK6X+I/a4NIj
u5iLZZt8KwE8D+JGLHHtNIgKhBMvXSYA5VVa9fCvUR39nQdXxdnfjSshmiqbz8Tk1h7bPCSSjvhE
lwCuLzAHKCaM5ywRzYotn0pL77I/8isaRnJejd69zgU8guR9ZsSWd17cxic+wcY8BgEvnaT4WH3G
P0wzTMDFX3V9WEokGMMkKVQFOLm23ihMDGSz4jV8/R1VeRkkDGvbhbAGugsvysa7yaSx6z1c4Rdl
AyuX6PBM2lmd9IG3Vtygpv3EgHnQoF72Hk7hcQYgSnz/VnjMU5B0P/GgemAagDAkl6v1Hx3i5u67
vqxCISCT7zYHp/xloEHoL3XhiCcobLmHt6sOC3fvSqlJb6E1GxD2tCQgSNBgCNiQBiKdDQJlv71/
9oGgZeftn8FbFy+5pZWY9AAfH5qymEImvE52zbejGBD8aeYuODZjA6hFz7Wfq83U0dGrkgQtBb/X
z5Myf6vCquKEs6HSxrmQi2r8e5x8CtcmJORkiiQtAVRXWgIuOzj4PzJxY0gV+Z3Hf5Jy/Fpp5FMw
L9X4q5Cz4t/EDdE/KCb55j3P+vNCxZZUA21SZP0RV5Cr1m4CczaGjPVITNjfbEUNjq2hMQa8LQcq
2hRNSHYpWcExroGPAvzNRfhI+SyMpciUljTqGZzFplJu4AWlD4kFzehVRGUuPMJG8WzfLU3NbReH
jBokNFZNbLOkghTPqAKhIP05VL96TgeepRxJCTcqBke3czPMUaIObKi81JNNb41c33o/y5dTfqSn
MSy7OCyz+F3QeCqW3bKqGNeqfNO8h19urrWWOeOxLNJjxCpWhI+ug+GO/uS3zfXwlLAtaXI9/Ql7
M+jNDe5sr9orJ2QHGg+tH5px7wMqtopRxxLM5kRtgHad34rlAXPl7+SyyiUFTHafV/wFCAkEyJ0V
TkgCjMyvdi70CWwJNbMtADAoJ43YhuS9CgwuKlaf8Hm8fUM1q9N+qL9mDREMlGW5GBlENRuTNmbV
YMuStd2b+gdnil4JCGabpKnUbtktRxbgVWFBzSxMSSF1oE7rT7q7XLafFhV2KfwnNYd26B7JuQrM
4iJ0G2KGWfxwnvLdQBf1a/rDL0MoEtn60g6UIfixUJigGTcR3e2t208sI1Vd8wbJ/Le70n0Q65Pp
03DIYT7SxBuJpM/DgcxqfBItOnOmhFybN/EKqFdeojIj3hQpWtcSpiopEJf5tyClsQfu6vBNJwTG
cjP9v0XaVyYTw/M+J7L52iD5K5gZnNuBiywqI2YYTztbvoOtmbxa+CjgPTleL7fLGTdlIFJ70m5n
B1aCvAPmj/ViRcA5Ajz64CG3YOSwzWZ05/YAEnckl4hXHk9ogxiFNrd5edDl/QKa8FkuWino7Bii
PIuAuRzaniABaQudI4nT5JmsVY/KYEHTvnfzE6EmueNHQdp70LptE2uNd8SicqAaQ44hj351UTjl
uPMzk45hLCmGHtAFLTDd5F6kgP1fsZNDCtliNzPLcCN3KuLAam98OHI3DUvqcKy2XYCujthKmxYP
AGEu7FY/O+cfJkk8CXOn27w1EVKlQIVgRF+xHOEKYFA0kPQpY1g2Wb8UD5Q1eWmdRjB8fJNcvQno
mVHtpkkoV4DUA4la6pzmkI142zCHENYfAJWxSawKHVMIjC0McvdqaZgLU9678lKfKYfAYyEhtOAq
b3iAFp8OsK7Nq9ZQyK+tE0TD6usNTwuynJugWhcDdSpc1hWCXJoP2kbXXg9qXT9K5c9u1FcPB8Fr
6ttcSLzoxBcEBT6kRKEHD/G3Z/gZGnyVMcFfW4UsPf44TkS2c85DKUH3veIsjKdkou3TR9s/qIVp
K5+e23BAt8BsxRlRrT29mal9sC+UcyxGAMaw8DGCtROpfRLyz3CLcmHqXMwBuobdaxR+NJ9yqJoL
x66P5/3GM/VOXj44ZoiR7TzOt3dyZZZ/MpAi7/ktFR+bqRmlbTmBr0U4yl3vreXPKY8jL5+dadLZ
clJ6AnzfrFYXgmbt8tJvtI/eMh82Mgq3CyGCxtsPox8Wk1F09iDhqpBxa3M3wKSlseW2Yu0Mxqj6
jkpALTkQLLoP5Y3U5AVj4fQ9UTYyCMuEV9SqA4u6UpkKWCemSeOVDi8RlAIGd1IAi7RD9blDPuX+
Kig4zmUhUVttXm/7KsIxVJlieICg/HPeFErFy5Ckx3ReVvCe3KXNt0y5ivTTUnCkSXQfr8nThTU7
sDC8WI0QEmL0wX3MT1hW4YxlcGiE2EYV9r5dcHknLKLScttXpTPN4di0BpWF4k3ov6QJwAa60h+e
TOC9oxg9NM8yULKZA3JkaeOvj9E38qOzJ9893H9Dz3GPwodsScqgbwK/DixrDPx1o5pfsO16UMEp
3lHaeqJtzBzbXotGXZLxgkicbR6GNcbtrUNAcunAqgjn1PGEc9mjBdLFW0YrYGa+mnPue66U6kYQ
NvVFCBDnBchUiZHL/DkA+x6tFEDASdQYIRyVi/dXW5utVIeQhaKp430T+ypYK/07Ksy+J/41/jxL
YoEYDbWpWlhZ8vD3Cky7tG74krWT5l/mGdDVpi1v3IySIgL6Fv3Qf8daaihf4n/LXyaQpmtiuQGI
nVFTQldlqQfzDxdVX/m0yZfuDJfC8QsiAbESZVIYetnr+AtMvdMSPvE1uV+N3bVyRxuULWuWBDhr
oq8Jmbep3jvyhjtRBQ+j6zdymbnAL8/J01qjrzqScZlQbCYWmrRWsWHmaWKo1rLXP4RS6P6ulg72
ZtfsqEIu46P+JfyYMByKIdqDUYLef1fgfCF3VxI/1J3EtX3Ae4FMCKXVbytdbKoDyvhJ0xX0yT19
sqLdmHot510l5r5lTCp+lXgBayQhPFjyvZphqUjd4U2Rp9Ein+PrxBOjNm+QEhNVxmm0jZWMZDQi
KZRnK/RAlYbG6auinfkXorwCEJ4u5vgDdgh4TJv07cIvmDNrPbW18H30xflBA0RhcTWIwgrBXuBs
jmi/asiK6sWY13dFoBr1jJZ3XazM117a3frGhdD5rCSwnbRP977kxK1u5vmEl0mFOOaucoR1MaA2
Ah5Po7MF7P+WRuSPcPtyG6hOrAqig+CsP83YImTBa+YPt8NqJFa389nCB9wRiEMcA2iLyUoB4jWX
CEbB4EcIpg6S6ZEG2vrkKQtKXb5j99bYYcB0la+BigenfcIoxIXz4BrjUHhsrrheYXlolV+g5RI0
Oa3aSulH8DURuMY1jG4J0sN9GuJQV8lGRUNNz3ecor2SHPBBNAreQQN8yQG1I7Lm2fwcEZknrhQ0
RuZ2H2SKPqXrC+wJEY2PEBh+5UAiTJ7QLE+YocAlVAVvXa4o6cNGZsFxSCrelduF3Iq9zP31Qiit
Tol4nCsmeKbNdSVCh7Tu3ebtWh+jqEFG0oy3pZlVkvdBY8CDZyXzi3W9sOZtn6qd+bGGDUkZe0Hi
WskQk9gGI5i5nMYkp8zJcbDyf+koP8ZOya+0Ozm5WSJnJ9b1kLTNx4ES3Dv88LTm1F0NLqRJn2qA
XNDBX7HRm3TJvEg3OfUfPnHdzA7cRHFPozRplesjc2duuKp2VSC6r88vA7yrbXXqsKgZQXI02eUq
dc4Sh78exakRWvHhMN6WKjn3rwIFy+Z7qpuY5T9eQfDeea6Zt03HPnOl7PWpBh6Q5Uge9gBwuG1f
ikdWnYi54H7KxKUds1asVBvXtotvuR3gIiqA4Bz9Q2i4BNvWa1HZov3d/DbpDLchTOiKeF7lvPov
iw0L49WcfB6PnYmLYP/tjnHjnqc9TUWlFFDF71O4XyR8sDczGiry1j5cx7itsLKtyrRtLrRfnJzb
dNd+9bweDEuwnhZaVAr4RYCsBKcirqAmjRqUTHAyc+uewpzYjfO+n2HuLvpdybxhEK0zJT2m6tlN
GXeuIoEueJGMKR0aT3G4qq/ay/JWFb5daLVmHJ39+QJS8l/J3r7drPpAy7ooQUHwEa3AP9pxDziZ
I6qZLFSxS13qfrmmOS1qDD1pXxHwNhzSKVC0IsQMK7I8bUDr4U131Y+xATiHpd+gUjlWlcKn9O73
WX4aK3+HitvuDCvcXAasGPg6HJ009gN3dtjljECDmk0wbGcK8qLB5MkGKZWegI6hEZyUhBgGlEfX
CEG+lH22EzepB7KvRFutjuk13WA6My77IJ2hKlcC22itbiBIuNb3HgImB8BSbjODvBoFtwigAmyi
2UZV2lPg0cjL81orKxyHvhIpxX7YhLt8FpVsdWbwHPoZQ47EHePyeehp1+pIrVHx8rwzDEiW4rix
tQHyXEbr/NIQ7XDC122G3/XIGFwsL0nUJvQ7mKZ4E1hlJNc1fBZP1YBQ3D1vOmQnoxbrJDhJwoeq
stjaq7ekCwJSjq8vcCZaowhXTMaY1SHx+bfI7SJ3d5mmUsY1vATYwwdGbeM/TWPkUsxjqYtolyiH
9cKmMas/ZEF+mWnSIFqBqF5zvacFAUEVb+djKgRhMOrjdD78J2ocvCI3KjVePJFbqoVQzwB3j2zU
zUOiDwy1poeTM/Rco+43QqAZvdBxrmwTTci4+z7rSAYN+BNXglXXqK9EsmYWVcQ6hB5T7SQ1yXqi
M1xxY4C16xd0UyDOgyHEzsiTXTeWsv4trKcCGd7djWf+MKtTpjlkclobziPw58+K2R+GoC9kzr69
jjj2wwLEx0vs94EP15neJklLGp+gVxLoc3NL5PgMHMHXCmZDc8NW90RK5PEqsy5ypbmcAjHW1jfx
vhDcIftuENgJDdI0C/37+kM1kwQLSkiTvUFm6sVbDGaFhRCDp8IG2fq9wn1V+65fl5qI6jbsNMt4
amJsXhY+QXJ8AliSxABUj8h4qXGNkFkjj/NGx+dCVzE+Ewz5GdBm7MSPp02uMRsbpW+UzQpUg80N
DfhPQZxzERlZkFbFc2RJ6fogFQSecHQnWwsElC2vAbuLkdmgjaXAzbVAT70mUR+wBiMrlIul2sjf
rpTdqCP/+hX/f8yYzoIDtNiQ3WbyJ7v/imsQyLN/+ctVo401mqo7SbiPHlbHP7WrcszbWQnj7Wra
fFqWQ8iwPXymNppmFVi6mMXx/5vadh8j66aMbMbnQUfNMy19P4D5yy1OnHb9Kel7G6gOFEYA2xg2
e/G0B8Fc5uSsRn8ZnAlf4QvIUjZ42vUZyipCTaLID17C2QiI/8DISWL7aide50hB77ntd4KauMcA
1qQlddmIcHbBvEhbUF9kXbEtdDQgI6aReooFdPlZBHK2uo+0IFBqN0GJjVXDByZYnsPaMEaCEU04
iKBxw3MQSR01ocQtH4WFXnlo607r34MH6HizXXd59/mUY6YMCBWSEa2HW7GTs8BToZDWbV75epBP
e7IiNgiwq5GgBspikbh2gg71gRYm4kmskTgnLltc43KJdVc7aIwXWJie/aZbXbHjVRaWmtEbRtIc
YcDgJcgY71z+6gS1LC5o9BAgfL5Nq9PuuY4pTsFon3c5Qar6FmlZfejQr8iiQ84F9uG1OZVc5cNd
uPg4RdaE6cHCodQht+QHPlZ2AoCsNsL2rpCGOzVurUoKVhAj8Sh62ZOU7kSRwnOrnloVARO8IM3X
s4Me9s7x9aIWLDpCAI3TXR6uz3SOJq1xrLrcT1wnWyriNV1ZvOGkRj0DL3aMKOLnqLnDAjIE6dn2
ITTH5L/SKitjBC9J/Cl6LSovjXAzpqDE/gIJEs0RTflFOdnNqvWdmoQHyI9WZQdViyCkk8ltCc9e
hxS+PdMWwC0GNzYX8AyGH/Ij913FXfeQmNnOp2i+cC1j6Ulyu8BmD2f06Q+UKnsDRpWmBiYZOZLM
A2lataf64Z+/EehMUuprX319oTdhkY+lG81Q9WPqtB3R+nHwbnC4d+4Hb/XEn02WmY1lxJoKiLow
l9D3iM3rVyY3AK0rZ9DT8DHoEQuP9aOY/a0bF0eH227sWePStYhcRp4OrBd4hTE7r9waKh4nmYPQ
wkzvOd9N13TRptjQIb71/odZeNBY91AtqAlXbG/7TJFvOjxBv2aM/DylNLNyRbiBPSMubbpmfu3u
zrwGVhrGf1TvX1rfzrtjWxlZgmskiBoPNutA6wAB0a/LFjW5o02LPSGvIHisGPNs/kNktyg2fwZa
44R01v7lnHHaScNtOdgy2lrjrxBJ6tn/grZijcGCB41m95ROlIHHhTdPjK2ulkw5oYSzoKgarRke
hmVAF61fjSD5HVVkP1ybBKH/2tXCUkuuZHFlapjHdU+V4MHpPPp4QdY2mOugCigC9hFiKycWPMq7
9uApXC1HIiih49LDDIZ8R7qMMr9QXZ4jBGxtoIjH5PjMbCltX7ItJO3sMUz9DNzxSKAYjtfki+vl
cv7o4cJiiDLjpYIWWESFYdsdlQ2FNvzVnN3fC07K6Gav0YtRUTxUtGW7tjYf8070hv0ZheUYsW6X
jQInANBT3bUsYQfHAEo9kluejzZWi/Ro+ZMxSe4KZXkjc/wfVC1fRKhTJKeKd/Vf3e5DOF7cvWXS
pOeuKl8OCAfJxiaUwdmuXvnxdfpu6s60DWVuZHN0cmVhbQ1lbmRvYmoNMzExIDAgb2JqDTw8IA0v
VHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIgL0lkZW50aXR5IA0+PiAN
ZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4OCAwIFIgDS9SZXNvdXJj
ZXMgNzQgMCBSIA0vQ29udGVudHMgNzUgMCBSIA0vQW5ub3RzIFsgMiAwIFIgMyAwIFIgNCAwIFIg
NSAwIFIgNiAwIFIgNyAwIFIgOCAwIFIgOSAwIFIgMTAgMCBSIDExIDAgUiAxMiAwIFIgDTEzIDAg
UiAxNCAwIFIgMTUgMCBSIDE2IDAgUiAxNyAwIFIgMTggMCBSIDE5IDAgUiAyMCAwIFIgMjEgMCBS
IDIyIDAgUiANMjMgMCBSIDI0IDAgUiAyNSAwIFIgMjYgMCBSIDI3IDAgUiAyOCAwIFIgMjkgMCBS
IDMwIDAgUiAzMSAwIFIgMzIgMCBSIA0zMyAwIFIgMzQgMCBSIDM1IDAgUiAzNiAwIFIgMzcgMCBS
IDM4IDAgUiAzOSAwIFIgNDAgMCBSIDQxIDAgUiA0MiAwIFIgDTQzIDAgUiA0NCAwIFIgNDUgMCBS
IDQ2IDAgUiA0NyAwIFIgNDggMCBSIDQ5IDAgUiA1MCAwIFIgNTEgMCBSIDUyIDAgUiANNTMgMCBS
IDU0IDAgUiA1NSAwIFIgNTYgMCBSIDU3IDAgUiA1OCAwIFIgNTkgMCBSIDYwIDAgUiA2MSAwIFIg
NjIgMCBSIA02MyAwIFIgNjQgMCBSIDY1IDAgUiA2NiAwIFIgNjcgMCBSIDY4IDAgUiA2OSAwIFIg
NzAgMCBSIDcxIDAgUiA3MiAwIFIgDTczIDAgUiBdIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd
IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2Jq
DTw8IA0vRGVzdCBbIDEgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsg
DS9SZWN0IFsgOTAgNTkxIDQ4MSA2MDUgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEg
XSANL0ggL0kgDT4+IA1lbmRvYmoNMyAwIG9iag08PCANL0Rlc3QgWyA3NiAwIFIgL0ZpdEIgXSAN
L1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA1NzggNDgxIDU5MiBdIA0v
QyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag00IDAgb2Jq
DTw8IA0vRGVzdCBbIDk5IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5r
IA0vUmVjdCBbIDkwIDU1OSA0ODEgNTczIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAx
IF0gDS9IIC9JIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9EZXN0IFsgOTkgMCBSIC9GaXRCIF0g
DS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNTQyIDQ4MSA1NTYgXSAN
L0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNiAwIG9i
ag08PCANL0Rlc3QgWyAxMDYgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xp
bmsgDS9SZWN0IFsgOTAgNTI4IDQ4MSA1NDIgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAw
IDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNyAwIG9iag08PCANL0Rlc3QgWyAxMDYgMCBSIC9GaXRC
IF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNTE1IDQ4MSA1Mjkg
XSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNOCAw
IG9iag08PCANL0Rlc3QgWyAxMDYgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUg
L0xpbmsgDS9SZWN0IFsgOTAgNDk2IDQ4MSA1MTAgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsg
MCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNOSAwIG9iag08PCANL0Rlc3QgWyAxMDYgMCBSIC9G
aXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNDgyIDQ4MSA0
OTYgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoN
MTAgMCBvYmoNPDwgDS9EZXN0IFsgMTE3IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0
eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDQ2OSA0ODEgNDgzIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRl
ciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTExIDAgb2JqDTw8IA0vRGVzdCBbIDEyMSAw
IFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA0NTUg
NDgxIDQ2OSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVu
ZG9iag0xMiAwIG9iag08PCANL0Rlc3QgWyAxMjggMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCAN
L1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNDQxIDQ4MSA0NTUgXSANL0MgWyAwIDAgMCBdIA0v
Qm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMTMgMCBvYmoNPDwgDS9EZXN0IFsg
MTQwIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkw
IDQyOCA0ODEgNDQyIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+
PiANZW5kb2JqDTE0IDAgb2JqDTw8IA0vRGVzdCBbIDE0MCAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fu
bm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA0MTMgNDgxIDQyNyBdIA0vQyBbIDAgMCAw
IF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xNSAwIG9iag08PCANL0Rl
c3QgWyAxNDMgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0
IFsgOTAgNDAwIDQ4MSA0MTQgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0gg
L0kgDT4+IA1lbmRvYmoNMTYgMCBvYmoNPDwgDS9EZXN0IFsgMTQ2IDAgUiAvRml0QiBdIA0vVHlw
ZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDM4NiA0ODEgNDAwIF0gDS9DIFsg
MCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTE3IDAgb2JqDTw8
IA0vRGVzdCBbIDE0OSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayAN
L1JlY3QgWyA5MCAzNzIgNDgxIDM4NiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBd
IA0vSCAvSSANPj4gDWVuZG9iag0xOCAwIG9iag08PCANL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0g
DS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMzU5IDQ4MSAzNzMgXSAN
L0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMTkgMCBv
YmoNPDwgDS9EZXN0IFsgMTUyIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9M
aW5rIA0vUmVjdCBbIDkwIDM0NCA0ODEgMzU4IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAg
MCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTIwIDAgb2JqDTw8IA0vRGVzdCBbIDE1MiAwIFIgL0Zp
dEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAzMzEgNDgxIDM0
NSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0y
MSAwIG9iag08PCANL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5
cGUgL0xpbmsgDS9SZWN0IFsgOTAgMzE3IDQ4MSAzMzEgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVy
IFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMjIgMCBvYmoNPDwgDS9EZXN0IFsgMTUyIDAg
UiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDMwMyA0
ODEgMzE3IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5k
b2JqDTIzIDAgb2JqDTw8IA0vRGVzdCBbIDE1MiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0v
U3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAyODYgNDgxIDMwMCBdIA0vQyBbIDAgMCAwIF0gDS9C
b3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0yNCAwIG9iag08PCANL0Rlc3QgWyAx
NTggMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAg
MjcyIDQ4MSAyODYgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+
IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9EZXN0IFsgMTU4IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5u
b3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDI1NyA0ODEgMjcxIF0gDS9DIFsgMCAwIDAg
XSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTI2IDAgb2JqDTw8IA0vRGVz
dCBbIDE2MyAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3Qg
WyA5MCAyNDMgNDgxIDI1NyBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAv
SSANPj4gDWVuZG9iag0yNyAwIG9iag08PCANL0Rlc3QgWyAxNjMgMCBSIC9GaXRCIF0gDS9UeXBl
IC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMjI5IDQ4MSAyNDMgXSANL0MgWyAw
IDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMjggMCBvYmoNPDwg
DS9EZXN0IFsgMTYzIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0v
UmVjdCBbIDkwIDIxNSA0ODEgMjI5IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0g
DS9IIC9JIA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vRGVzdCBbIDE2NiAwIFIgL0ZpdEIgXSAN
L1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAyMDAgNDgxIDIxNCBdIA0v
QyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0zMCAwIG9i
ag08PCANL0Rlc3QgWyAxNjYgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xp
bmsgDS9SZWN0IFsgOTAgMTg2IDQ4MSAyMDAgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAw
IDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMzEgMCBvYmoNPDwgDS9EZXN0IFsgMTY2IDAgUiAvRml0
QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDE3MiA0ODEgMTg2
IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTMy
IDAgb2JqDTw8IA0vRGVzdCBbIDE2NiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlw
ZSAvTGluayANL1JlY3QgWyA5MCAxNTggNDgxIDE3MiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIg
WyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0zMyAwIG9iag08PCANL0Rlc3QgWyAxNjYgMCBS
IC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMTQ0IDQ4
MSAxNTggXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRv
YmoNMzQgMCBvYmoNPDwgDS9EZXN0IFsgMTY2IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9T
dWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDEzMCA0ODEgMTQ0IF0gDS9DIFsgMCAwIDAgXSANL0Jv
cmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTM1IDAgb2JqDTw8IA0vRGVzdCBbIDE2
OSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAx
MTYgNDgxIDEzMCBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4g
DWVuZG9iag0zNiAwIG9iag08PCANL0Rlc3QgWyAxNjkgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5v
dCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMTAxIDQ4MSAxMTUgXSANL0MgWyAwIDAgMCBd
IA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMzcgMCBvYmoNPDwgDS9EZXN0
IFsgMTY5IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBb
IDkwIDg3IDQ4MSAxMDEgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kg
DT4+IA1lbmRvYmoNMzggMCBvYmoNPDwgDS9EZXN0IFsgMSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fu
bm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA4NiA1OTEgNDgxIDYwNSBdIA0vQyBbIDAgMCAw
IF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL0Rl
c3QgWyA3NiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3Qg
WyA4MCA1NzggNDgxIDU5MiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAv
SSANPj4gDWVuZG9iag00MCAwIG9iag08PCANL0Rlc3QgWyA5OSAwIFIgL0ZpdEIgXSANL1R5cGUg
L0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA4MSA1NTkgNDgxIDU3MyBdIA0vQyBbIDAg
MCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag00MSAwIG9iag08PCAN
L0Rlc3QgWyA5OSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1Jl
Y3QgWyA4MCA1NDIgNDgxIDU1NiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0v
SCAvSSANPj4gDWVuZG9iag00MiAwIG9iag08PCANL0Rlc3QgWyAxMDYgMCBSIC9GaXRCIF0gDS9U
eXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgODYgNTI4IDQ4MSA1NDIgXSANL0Mg
WyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNDMgMCBvYmoN
PDwgDS9EZXN0IFsgMTA2IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5r
IA0vUmVjdCBbIDg0IDUxNSA0ODEgNTI5IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAx
IF0gDS9IIC9JIA0+PiANZW5kb2JqDTQ0IDAgb2JqDTw8IA0vRGVzdCBbIDEwNiAwIFIgL0ZpdEIg
XSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA4MSA0OTYgNDgxIDUxMCBd
IA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag00NSAw
IG9iag08PCANL0Rlc3QgWyAxMDYgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUg
L0xpbmsgDS9SZWN0IFsgNzYgNDgyIDQ4MSA0OTYgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsg
MCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNDYgMCBvYmoNPDwgDS9EZXN0IFsgMTE3IDAgUiAv
Rml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDgwIDQ2OSA0ODEg
NDgzIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2Jq
DTQ3IDAgb2JqDTw8IA0vRGVzdCBbIDEyMSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3Vi
dHlwZSAvTGluayANL1JlY3QgWyA4MCA0NTUgNDgxIDQ2OSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3Jk
ZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag00OCAwIG9iag08PCANL0Rlc3QgWyAxMjgg
MCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNDQx
IDQ4MSA0NTUgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1l
bmRvYmoNNDkgMCBvYmoNPDwgDS9EZXN0IFsgMTQwIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3Qg
DS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDQyOCA0ODEgNDQyIF0gDS9DIFsgMCAwIDAgXSAN
L0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTUwIDAgb2JqDTw8IA0vRGVzdCBb
IDE0MCAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5
MCA0MTMgNDgxIDQyNyBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSAN
Pj4gDWVuZG9iag01MSAwIG9iag08PCANL0Rlc3QgWyAxNDMgMCBSIC9GaXRCIF0gDS9UeXBlIC9B
bm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNDAwIDQ4MSA0MTQgXSANL0MgWyAwIDAg
MCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNTIgMCBvYmoNPDwgDS9E
ZXN0IFsgMTQ2IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVj
dCBbIDkwIDM4NiA0ODEgNDAwIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9I
IC9JIA0+PiANZW5kb2JqDTUzIDAgb2JqDTw8IA0vRGVzdCBbIDE0OSAwIFIgL0ZpdEIgXSANL1R5
cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAzNzIgNDgxIDM4NiBdIA0vQyBb
IDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag01NCAwIG9iag08
PCANL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsg
DS9SZWN0IFsgOTAgMzU5IDQ4MSAzNzMgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEg
XSANL0ggL0kgDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwgDS9EZXN0IFsgMTUyIDAgUiAvRml0QiBd
IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDM0NCA0ODEgMzU4IF0g
DS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTU2IDAg
b2JqDTw8IA0vRGVzdCBbIDE1MiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAv
TGluayANL1JlY3QgWyA5MCAzMzEgNDgxIDM0NSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAw
IDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag01NyAwIG9iag08PCANL0Rlc3QgWyAxNTIgMCBSIC9G
aXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMzE3IDQ4MSAz
MzEgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoN
NTggMCBvYmoNPDwgDS9EZXN0IFsgMTUyIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0
eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDMwMyA0ODEgMzE3IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRl
ciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTU5IDAgb2JqDTw8IA0vRGVzdCBbIDE1MiAw
IFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAyODYg
NDgxIDMwMCBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVu
ZG9iag02MCAwIG9iag08PCANL0Rlc3QgWyAxNTggMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCAN
L1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMjcyIDQ4MSAyODYgXSANL0MgWyAwIDAgMCBdIA0v
Qm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNjEgMCBvYmoNPDwgDS9EZXN0IFsg
MTU4IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkw
IDI1NyA0ODEgMjcxIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+
PiANZW5kb2JqDTYyIDAgb2JqDTw8IA0vRGVzdCBbIDE2MyAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fu
bm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAyNDMgNDgxIDI1NyBdIA0vQyBbIDAgMCAw
IF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag02MyAwIG9iag08PCANL0Rl
c3QgWyAxNjMgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0
IFsgOTAgMjI5IDQ4MSAyNDMgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0gg
L0kgDT4+IA1lbmRvYmoNNjQgMCBvYmoNPDwgDS9EZXN0IFsgMTYzIDAgUiAvRml0QiBdIA0vVHlw
ZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDIxNSA0ODEgMjI5IF0gDS9DIFsg
MCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTY1IDAgb2JqDTw8
IA0vRGVzdCBbIDE2NiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayAN
L1JlY3QgWyA5MCAyMDAgNDgxIDIxNCBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBd
IA0vSCAvSSANPj4gDWVuZG9iag02NiAwIG9iag08PCANL0Rlc3QgWyAxNjYgMCBSIC9GaXRCIF0g
DS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMTg2IDQ4MSAyMDAgXSAN
L0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNjcgMCBv
YmoNPDwgDS9EZXN0IFsgMTY2IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9M
aW5rIA0vUmVjdCBbIDkwIDE3MiA0ODEgMTg2IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAg
MCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTY4IDAgb2JqDTw8IA0vRGVzdCBbIDE2NiAwIFIgL0Zp
dEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAxNTggNDgxIDE3
MiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag02
OSAwIG9iag08PCANL0Rlc3QgWyAxNjYgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5
cGUgL0xpbmsgDS9SZWN0IFsgOTAgMTQ0IDQ4MSAxNTggXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVy
IFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgDS9EZXN0IFsgMTY2IDAg
UiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDEzMCA0
ODEgMTQ0IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5k
b2JqDTcxIDAgb2JqDTw8IA0vRGVzdCBbIDE2OSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0v
U3VidHlwZSAvTGluayANL1JlY3QgWyA5MCAxMTYgNDgxIDEzMCBdIA0vQyBbIDAgMCAwIF0gDS9C
b3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag03MiAwIG9iag08PCANL0Rlc3QgWyAx
NjkgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAg
MTAxIDQ4MSAxMTUgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+
IA1lbmRvYmoNNzMgMCBvYmoNPDwgDS9EZXN0IFsgMTY5IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5u
b3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDg3IDQ4MSAxMDEgXSANL0MgWyAwIDAgMCBd
IA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNzQgMCBvYmoNPDwgDS9Qcm9j
U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgMjEwIDAgUiAvVFQyIDI5OCAwIFIgL1RU
NCAzMDMgMCBSIC9UVDYgMzA2IDAgUiAvVFQxMCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9H
UzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2Jq
DTc1IDAgb2JqDTw8IC9MZW5ndGggOTcwMyA+PiANc3RyZWFtDQoyP6d/5wgfMXJ3QTuW5ba3wsuD
JrrbYsewhKl3Uyl7VB1ArQQE/CG+RVO006vxDJ4ct2WaMkYyfWNUAHh30lXWsYcN9i58yjxdvkRh
KiReqM5I9AUinrXIaADna944uOiCdsHQ/MrymJd7BN+LNbJ4WHmvmqOumZTTxZfrajm+ClrNFjWn
/7OEXT3ExqMw95Nz6t9/qaboHUdiSeZxczwWqgtsNJlWbc0CJV5BNCR05tLErGx6Rs6UuJwPWEDk
3qtQTksjHpkJwhYOedjHJSnhJDoRJB3RYSfQBdkkYuBALJba4y6h1fbD7TO1UGUV0ZH8eCCM+OJX
wj5RNcj1RmVTsUoR6ERy2NJDP/lIQuE3De0zT6d3lxp1948EcSxcNLF7M5sjPpbZrecEPDfKGJLJ
41isevBGjG6aIvQadWRWTo9F9BezFMCetK6pSCft3OsQtNw1/EeOREl09Ux8yeXzdT1zzlcOeeFl
jzRTHHxPmhpZ1iemOpb+xSyF7UnV+mMaDv7tQo8pocEQdJyE7zAHiBZ5LOzvnxE5mzf1GgSLwnwF
rbufHQfRvCIH5EANZkz+49BAmn7jyHejUOH25kLoOFaU6UYQ7RttfIafosK2HrN45OLvltVXu00y
NN0fC7RsJlO746OC8+wQzXLJEBuaf/Iyg3a9srbs2qmxr8rraA+vMpmpSNd3ZxoqDl2xZn4cG2KU
Un4lW8XTpo5Kp2CW3gj++0CxPJbvP4NugkRzwUOoES1P2qAzXvS7OFGQNZMcfdcW3t4TLszS/tVR
VYqEQX7neALPfPVrIPebxdD+TQC+KeL43x9ZiYqpaSSajELDoWO+P6oqABVhuJqsnQ5BQOlMJoju
7SFPMfuqpnPkNCF6x7VSPtQ5kcNdZY6fsPX/raO97OB2DCBcEXpupDvxO0U/EI6xQrprb5dLdPUH
ooyMboT61Nx0sN/qf5G+YHJxyTP9IAKD9satmoVjKIpdDA2CIuPJCkgIv1Q/zmItlPrGrQMfwvU9
Q2iVa/wksrfrMKQMqdY66ORzQtEx+CuryHCtp9VvlRcmJ4knBjgdneQWnGyRf9JO7gZY9D1FqgCg
u3lnJdTAxYUAX5aKNDEGRxI6VLmNc6NZLELcsLSPm3v7ZS8CoLE1iVp0UwLtou3w86pMH3SdPPi7
XGDQo2QWdWQaIRyGAoPNFz+M6zkfNa297LzNY1bHHOF1MsAhr0S5jJ6fOREQA6HO1CwovZ74uEgn
5/aUDNjPkG0qtWTq1hr6JQpDf9qQMWYX8O7sy/0Sci3gB+sXhRfa/AQauI3b5q5SphH8p7IFOy/p
xgyEdzrTBdfOLJbfXFCMNrSi2Bc4KBvIRu0U9+fv25UGwQAjbK82hpJKyk/m7Ck5w/squ0/gmmWj
uqTWRx3U0Iije3fmtZc0s2uhzBbQfiB0drB99SjBdQfD/5/iXiwCKyjvO0AhUVB469q0zl1DoCjf
LAYWcq+kN3W1nvHTbYhcl9IDjAB/0znFX1B7hP05s/+ELSMFQJ/Pn1Er4uUnLfn75jiqm4z2YDlV
QAqi02QGHYWkUXNoNV0OFLUUHA6IvRHWIwkfzHSFnddXNvtddGi8n1to14SLUb3zQcmSUpX8O5Cm
eTRDOYFUEYibNVz4pfy62OELaDFWW4N0bcRzOeWp6Yn6Evgv84InRZlH45i7ineo9YZKCkNzR3iX
OHuOHIU/SpQjLksxa/CdIUtjCtd0Fb/VzNpEjrnAhxVkfYKYIKiAhOoKngrmgYJBZ9y8Af909y6O
h4zEaEpK6q9j42bWMT2QAgURaEaIqhSteLKcT+iWUBAq5cJhRFo5gv0hFetHkOrU27dESJuezQFC
vsrKbePhMW80yEOIg6r7NsgNvmprMmaAeFl9EZsRW3xakzlxarX+aXwX62NNAX/PfQb3wZAmin/T
JCVEOqINJt9qvp+LCyjXW7EjrOYpbLVffHZMU7X6Nd5g9U8wJ+NT98IbyGBBlOZpgOrJ/LITNNop
wXRRvHpkPaxKKulPr9I+DBBhKiXKzq9FmC1EBfEF4XGhMqQRuurQXZKGDOphVNNCGr0bcaMrhN2Z
YJOKf4bFTiGbl7YgxwdsuoqmkY0hJpyLDEz1Datoa9SCWzGVSQ57yxpNLP5K2B5diIhpbNWZAt4p
Pn+o275MWLil7iDNJeTGR+e0w+6DMbnNP3k2WthhNl99Vkqkb2vRgR4uNzkiTMkjXH3/MNkQRDIX
wPM//WoUs67RcRW/8Wgsd545/pNGC1peGsEtWAc6CnyEN26ZD7mEtgBCich4qqM8AyYyvNKX2bvK
bde557kj8EzK+dNotEInRQ8KW2bljjTX+6/cC9T8oiwo3r+d3x4Awy1F14QwyXzc9MDP0HMjT8ef
nO05wNWPCLurG0zIx7wmerF2DsrREVb/EsDSMvEZP2c3+Y3Is1RcCxsQvUAJWG67xpRci8CiycPC
EUPZ+sk5VtknKvdzccuvE7x3druZYQS99S6+u9xkNSwQoLkeUUt52fvdJQK7W2Vjaiv7qCkgg+Of
mKxtHw1FrH4bwyrZfLnSxnm2Zugq0hf1ilTb9OUctqNEUXubs2JuYNm/UI0FXDLilW8DqAh1sZlz
/D3qFdsBZbgQkrWk8y0c9vfswTNYlzo/zUQSwrDCpXd7BouODCjQjdPS8pk31X1tddaQ+Zkt/1eA
uaObNo0f2BhbRscrJe96tJnTRHOImBp0nLYlkL8CNYkVKH43uscbvmC5CpBkKlPGGfj0Xgfuicpf
LExhu7kHTJHKOpVOL86fRI9rdziHFLQMRqqc2mfwyjZon+KIyyqMUCr9T41uobhggp5HTPaYRpeV
2lBjYtmFbntC8CVk0Pm+v5erEyfKX/QzisuE73EBgQ7rHwU5ajIluNNyFbyVHvG7f0W2KyGqu4Pi
ItmXbJLOJuU1siVljOM96W2DRH3WAWp7jqxBJaPcAQ159TiuoEruqx/sSQvjKhaVtNnNND94W9S7
kpVwUwpnBMsh1Y1Um0HpXYPa042oA97ZxYM2ux6EKOi0vIzYw8iuwnThenXuS7T7ShDbswQehW1h
45QcDL8Bt86/eRtYf5v4hzfjB4/1Ao3FhYdzCSZ55Mk8UG4Jhu3Rs6t9TKVJIDcb/x8vCLzIbWvD
jmXCKeUVC2rN8vuan0RO+mYc3c5P1Pi68lp+x0SwDpekCK2R9XNdtu10iLoGXXDR77Is5EQJOgpS
TvgZ3RLLZNhYXotcxWpKlHmLrSrSVCtXSt4T6O6RKSwoSz0f5HOyEEG1WDD8tzq19aDnRTNiNx9L
ZDDtzsL8r/nLowYPqrjTaih4gTL5EVaiZhq1K7NPAh7003ycKHNCqolEwGYTr7TbcEcOXceHSV16
dVI9LEvZpfdsak5YNQ28Is95fL+Vujz7yFihNb0aQjbPeg4Q9qnh0eA44dlgwmc69LxHe2024l2u
12Yi7JD8LST5GkWjaLStXjgE+r1PILR3qHhSswF+8tm8tfoSiQzh3vNMm549H+nu+ue86kxyP9gh
hQRG5tWLrrYCSZZqg9vdQZcqBuEGPZc3P0d5GYejZRsSFkC4SceEzlwoLKCRGb4thznHakIlEicj
Mtn1eHNy2ks78/yd3UCEvWj8oWsD9KLDbdRb6CLTN13nqfIZvmr4Lnm/sCtTm5s7SQiwmJxS47YK
I8PjVmRB4gIN6mHCZhqCjGgp9hUoGhQ84mV4FZdeckPZgGw8JWbVdjB01dtY7sYUrqKgLPWwcvUx
RzhDq1c/tkpP2joHhYvjP09cxpS1UDV6FnMNWhw3XB5paIW/s+bIehllat45BjpjCMVKSLnwyT04
+gCRvMCevOkLnA0IlcD/85p6ie2pHX8r7Cg6b2+eFB/VmamZF1FTSamBASwBFL8Li+nbisnPme9F
8HUwihW+HL4lZpnOk4w1L08kYMM15Lj4mNL8xc3CFnwTIdS1aN/3SRyc+YeuD58YqAZ2mq5JQEZZ
YzTHIAcBk735YA0AQXMW0LDoOFitXR9ITJNd28Jg56iRFzXczVYkTfGJIHytDgzaJ48n9SPqMwPm
dFZLT5ehPPJm7zZ89d5EGCEAXThuQtzLOHObVhNQ6WECtssVsTG7ABGratYOZAwEMdg6aa4qRNT1
5vKJ8aYF6D6skb3d1X5VGnVcFPZSEVYLxFnF+Ie1eEPMgKI0m/9d9PStj9F3AF06TxLkj9o1Cqdh
sL8p0B2S3Zj7D6GBOorP4bWUAmRAqx7EgSpVgHCRRTruLKyVM+UEC/D6zZMXCVk+TGYc2AFjEEac
soimA0BF6k4K6WrykK7k5zqKSXWA84tJGBC3wXFpqWV5g0gndB7WKKCJMuSfkCqbiwPXvp24YE1G
+9MmvBwDQXefByae8qJDyJ5K7Utol/oRJYjfnN1gaHhexdQsDloOB/6N4vmTCfjsDjmmNfuTZXXG
7IM815q/fYdQmZ8V1pQtXtVIrrwL2bL+tJABPQZ31m0v5Mm/olQjpB6MrvsaRPj9R5fYFlVFQK60
hPCaO7Ot7crtPgtGk166LF75obsD+KWw6s868J0RRly/EDlAOagOP9/6pkf1r3AV9GjOA/9Hrw87
3jRWGByvyVMco7K3eACAWDNnSW4ArL2lzTdQ1uGqBdH8IPEq+lvLJJHhqEfM4X/B6h9s8DUFLVA2
9UEygLNo3G//kV81gSlBFRUZgBJ/0djn8/btE0y7vQjvHbNbWX05e6VQP17P+8WDkeVoKlcUvijn
uJuquW+pTHA3tzfd0O0wkGwKG+bckxB8bv30da92KwCdQIW8Dcxu9XkFaCPWs3Oie6rakcvkY+Ev
/0qTdTDuw12feuFMnPLr4U3VcD0kqb3TbYjmeQOQcFDc7PTy61eNGvvQwhBWDs7FoaAqh4kSvl2t
NLycgBTvA4/JF+0GDufQa7ug4CUcdF3yKSpimBIKgThjfGbggNquXxon1I9nYVYHbIYQhi8icu5P
znqH4Kz/7NWD8C8Q5rYfOebyYFDttbxZSk4mCZ0mXOnuNlZdanBS7jIJwMV1x7kqSrYrqyOjGYlk
lb9sPO9Fga6ljjmbXni6pSPiDKWg9Hh+RkMkcgPYdxKDoOVDqsM4zTg6GL4LoJ2MZ6/pp2Fvh1ji
UpIkDWIlIHFj9YTIRKCxasBXbBhK8lM5vIptI1SdQtSQNe0V8/oSsJKCQmvxNYg8N3f1q0RbExEP
AQjpT7qati/tmsmly/GK8XnS30dDgTEe8VxQjVEYfdz0iq6x+ZIsXjLsWUPeyH4+ZL5IGcxvHOpr
+/UaXx+dzo0sZMDB9qzRjzLuTAROn8kqQNchz3VOER0b69HVcL9Y2Fxypb/aGnOkrf0vYPFKoSh3
vfa8TPRJiP4dVomUsy1lJf47w1VMtzANqpDS0Jf2s+Qi6DhxAzgqgAt52oRGLhHMT/LlzduYiJWe
kCyUJX+FF+NtOCCbh19S/zUiyJiEXJ1C56dGNdGbFtWm8vPP8twePt52aVggeX8BDPRiLwHsokIf
7LdyQKYUL14vAijJziB7BLJaaMF/saZ698uUzO5P2neG8PVdtvkGq9hSVZ7CF0MqkdoFKXZawZ/k
P/cQGX/ihXt5QCZ8G8tnDZijZGqGvPA8Q1XxZVd9zCYF6bnIMOghsGhTYxlESMfn5BnAo6UIuT6Z
3JHUKV/RhrnS39O8tqxKqjR9SPzQ3ad1UP/QCUeVEnW8duDbdhcZ+IVXAVv1I7XCG+eHTHA2BBRW
jFYTZ34OCenzFGrt0hyBZCkAm9yQr6e9ogBzGkEzrMfvDzzAC1PP+yVin68k+0uFPkSpO4Uh8wlM
sOn9Pj/P2gYIZDW+q39BO2QT6N/W0Q9Z16Du7VcxSMZSRR9fApztAzXg9FjX2b7TGQv4hThqp7xf
A1+fOZ0VtDA1ifS/vN+DY6rnmk06Rd8AGKCouMFQad19jgQ2TTcyfooMomeu8sJAku/mo8otYOuT
wg12HV5UapIdDq75yHwbr5hSsIEhIgEayzM6LL1JG1o3UuIQjx8GTaYN6+AadUVfmVgg6wLX+GUE
7xsUf7juZndV2rZmr6M8eRTsGb/avl0ogUoNFei/MpoJOmUo1xXjEhSwOzGNSFqMCwfpvMMxsc5i
U7NEgmNX5aMXAf7CtwTEN6XdB2udVa3NDF/+dlSqSGRR7hdrcbqVuAtLp6oy1RwyzAtyXf4Z9uGf
rqIlEYL0bjfqVDUwvb+wv68X6XMPnFIzI8b7Ni9da6dUNnaRDD+RDGsbaJJ2Ihy/MhCVGvqCW4Bs
lGV36aMzAmGdWQ78jMk7QxbQGJBdk7AVEFiiMnNZCuPyQyqAunXKOEJsDI3ZDyIsmHBJusL1WkwN
Bb39tCK+GhQNTu4AHN8LwsdJL7CFJJzsm2MQC92vlwa4TSm3HBn3ej2qp7Cz0qQ9OCh3Qc92OPFu
YedrptnNVBUn0x6CY9/fwEXKIeRf7rCdoWuFEj0sbhQcMISzgEvBqrzO+RLo7N9hgXUX8rNf6Whi
IONq5av7ntbDqf1wEmJXOq+4tvzpHygeQuh/crLnuJSCE7FZ8MN5MiHiKWjkMtixUwPWhCoA7syH
MLvuBXI3xGaSQ8LG+prqjv1a8HbBfAWbvzThprzXESyxp66s71fbUvcmMTIi3FcQqs2bXL7Z5mq0
5eCPe4mp3nzUFPzhFYxxku+UVdjRMsOxxadXb7NCRzsZK7Rtx3hrqUQdPeI5l0e/ljvfSAgk4/jT
wfreClemwu48PPST3cQ+eEL9iWzSTZ+bs/u90dg6aI4wveZaAeMyV2psL59X0mgPyv5fmUDaa+8x
PXX+xtkZnZCJNbnkcQlgXIGxmGOStHadZto+mOE+ZA8i1FQ6c5bOTBamI2Vk2j8/cpAlt7OaJw1x
6U71n1g2wQvVpoSq1GmFzFhsai36kadbuG7ZgbnuuisDh56gbpCFZ3EbAIa+2DkCFFCrC1kBr644
YMVmqJKNbTvoD+tVDnUHoQ2nZ+R5AyCpxA7g0ngagqn3wkicdXZv5TnniYibHutKYpAbQ6FNlpy7
inHBNUk7R+GatxYwYexa8UU4DnI3eW+VfausvD7eFolkzXwQ9CaP3nPHF05KjUERq0HpmVmfHzSk
qmF7mAVwG0otyyd29noGHCAs2/uPjmpPXd10hlMbJUQoDqfmr/DKuyjHlcayJLaFj8WObN5C98s6
gFI6VAlJEd7YgjMmAlzFX6MMwmeJaK/FTc2/hkFPBo3MR35PMmxEL/VnIjM/7ucgPtP9d/4mOW3z
/Q0pW0sv0U4iCdepjjbSLmNHaKAHjjQyV7RwBUofzHLC25g6kFk7ctxkfYGKCDNwAga2xdgWHXa7
MwD/L5WnZsvnezSRD2wKSuMhPflQ09Uw5lM6hvpN/EBK0BFnAtSUndMcDcuzVFnZFzLvMhYUFNdS
+9GL/R8mk7xs7LhOyZ2VbCvBMprwfuXkblsiKN4G+hB9D9ilwcTX8wJ858lY1X+9XslQl7kIrg3g
Lb+uUqtXNdK0/hJZovTWV6DjFXX9/aLmY6mSVzudgnKi4UYFZrA4auoDxtGdRVZUTAFwwP9gLYRN
KZjXl//TrRvyzGryDfkfPx0GS3KThsP8BuVCzSjh9Z/de0IxzaMEzuzDKsV2aAZbE0lAHn8bM4nJ
bClOyzpcG735FlKrTMJJmDOrxvMIwR4HyS/kq9/Xsq41dDVQJ+0B0IzHL4yRM7rbXWBODAfnhxWx
cckpy/60v2roEdXudiX7wo/9WVAFcVMRXmDAxdhM8YsQdNPWj6hn5CYqBK998+honlcPzw0gXiDa
U+d1GmyvrUxJCAlEpF1BG8/cUTpYsrbabiRhlrGd6P3PUZb3FcKFyG45YWZA9biV3x/i0hBGtbDj
ouDpUcLFC9gZ2NVhrlB/M+nf1aa6rFUZ3gLWag80LyyNuJd8TgOhbesit3TGKZhRecVhdZdzOV8f
H++FKbihx0dOt9ZRUMWX//XXI3QerBjjo1XlCMc0uR2Mzo9bBqnb1PrRgzk/PMb3ZOvMC7Wy9b5A
OBMG5mufyDikdM0xif1J+xZVoX+6zJ51xRD3fABuY+uivpV2qc1L/2jut1jS2E1vawLqdEs+tir8
E71dWrqoIiiR1K7qdB3Az2jtEx+umi1Q9o1FZMQKDb5nrg5D4tslR6i/JZzmj8tFRbZ4WY2y7/ty
SnH8XnJFQdwNOko0DcUxW+SIYnPkuar71U0CrgxwtyE8UI8Qf5pZapennH1BZfqVAiEPH6zrcHrJ
8ZXhIXpjzjgxbHriVFWgJZUH0g1L1VAQ3s2CTmFDdnCOdNeJYqFh+UTPz0+zx/5c1aBOc62fkm4y
QKGq/7CNfDHBEwVTrcgZIw4zKVgG4RG3QgYolTI6L9BFtUfQ033VDX+EeegzLfBrKKiPNkhxs39M
qoB92/ZVe9340QKjPpU7J8J3+aqMAb6hmjXVUeQ7EOuqfsv7x6v5K9UGhmjLChL1pu+epAyDLNqb
eanES2rLJGj+39ikiHyOe1OXCC1xextsc/B8EgCKaLT/N/tU76yUQanKTPPMu6pwUTe6KzxNyk4c
WqK6qROLc990OywqAcuQU+ybvMHFitzw7IqII5WRzI7y2wK9lkOKGEfvfjvkCjEa29Wy2iS9sC0J
pEaEPQFHo/JK33wSJakEfwY8f3ZwvDSbyFmUBK8mfBIatv98J+FexB6T6VmU3CVyIpkK/in3PSjF
EDulchSm/68wcxU9zlwiYy4CCdZjuNUCJwzMUSAxWH6u4+WfLmSrbXoM6cyuIlqvkMu6ITsp+fB7
8y4LtuCgeJy/We7O3M365JCndox3RI2ELjyFkckAURTnKzrKEeU6WNtJVY+Tbovzkrp8WNRyua6z
h+cuqeA/heNhkV7sgkDnBsE3sVoMRnl4+bD+Vr8/MA/JdSwjMmfYIRev+wxXF2bzrfxF7/4IHCbF
e5KwIQs5Uw4sq/o2853++cZBVqEQQatCRG86npG0Uf2FePJYGziVmwDI6I1+OkOUIRCJvCF7D99v
WAzgDgoqi1jdznBX1LWP+2UxGa6B978NaC3eOCSobexaJi7Txd9T8g+JSkhwykGiQk2l5PDnhBqt
cNQJdc++2tlO8czXx+114sS/BfBKyLF8bEIIve3g8NmFk6cub6an+L6F8h0XeqT1q/sBqt58D9M9
ePAcDdMPZun53UeYCnoT1LoKyL1Ew26zuBVRKes3nxqZVFRp4dNeGeeGpBHeNCrC0yRJ5dg8cthF
w2alRV4+z9180TTpxebu//kTAemX7ci8FiICBXP/o1qL70hHlOvZLaBIox9E3QLcfctY6Rhicg5a
RRs/TrMk0C4yafIcuWruN2PjDq60qP1WAnJv3DXkyJD1gh3scXfzUBuMuQahdGcodSrpsR/x/tJi
9EhlPsKl0V0oggrDpWAQ1Xiv2NIdD3LVPQbCFMYSr6SipKP4RaO8Ni0Y+44Fo9LxWZqrshkPZegU
DUOcDgpIAuE6K1gbS1qaE+6t3XJOyEfFW4DYG5JvFGbZKSm7BUMo+q3/M/HJRxNmq4VDSI1sBPZB
0rc43TiRE1ohasHGkZsRPOgN9TsmPwDuj2YSp4Zw1PMrmd33sohivfN01n7nV7OQ+BWDSSwdxtEJ
iL3DCO/TIYrUEd+3q3+vaEz41nfsWQ3XeDZrlnyVpPu/Jy9FsTwTKSWaTjOQMQNX+bVdmBQzCbA2
gbQWjO07KTrSCj4qRa8yMBEtzchJtk/5ngSDAOCCHgIsQBFPdfaR9my1NEYY+6emiumq/ZJnyNqu
eG1RizUe6F4OvQCh41mKbZLDVYBSKxLh/5sauwvxVNY93Kjo8WByFzEdEl/2LDR/h6hJEiRw9kP4
hh8ae0TuSuLRXIbvfSHj/Zn1LEvgGJJKeF3mEZ7rQdTgH9bnodfxF6uUNUTQ+Ic9a2zDJWOJIYJn
8xzDZbCCE4UZMJI2Oyqq5AokJCZtdaxLK5LgvZTtEBmxTzYOwOJ7JYF50fJ3bOx2XObbtEbIr3Ea
E10oLopl5NV9hBZJR/0wxwGODXARhPCCuyANvKyl3vOhr42BOzyTCB1FZlumC/q19cQRbCbDyDHU
0/GXMn/r9wk+u//R768+i4bvOKnxnYzc27sdNca3aMxtqEkznjrDfSxDnwv4MN9FC5e2f20082by
LHyq+8f9HSqKW7u+OWMwfTCV9uuFNS62zTqeHZuN7RK2FZ1d67F2bqAc/aOOZeXjPyvu6pCmn+6W
u0eV0bwf6jVvxT4hom5F7lb6Js31MXOkPuNx4QPmjSLm7w9Kidb+03ChS4ILIL/eL+6hRarWTtHL
T9TEysOjjbrN0Obcetm1JVtKg0Ikk+/pKdVdM3p1oN2S7deFCe6wI5alb5d26GcNPsxekr9A8HhE
eghrW+2jJKaMbp1Fy0g8g3zxb/jVBES67geLyoW2ny98R8skrSDnbAmd69dh74kw6oA0m5q9dw0n
AU2NvjdNLwLGOkFeDJo5lk3gTrsboW8YXDr2kt8unnvcbKZOoNwbrw5t9i/9QaHdVShIOBUjaZvN
UMlX+gtzyUsPGRoNuB4BJm7JC7XMFPu7w82LFs0UBq6mCX6cx9RjnH0qVF/7fhiup/nJN2p1MTuA
xMIP7WH/N50rm6nmjUYotN/DcXm9m2IwcSy0sUN1JrRkTNee4Som2CHdDaoPrDuCh+OG3aXnNkyM
YyEb7fZ99Qn0l2qGHR7DUCgsHvV1wd+E49yn+tkvMZYtOVejhET6wrq573fWQcM8JA3SBGovWP76
10ojmCyjCkw5aiwe42ihTotKZqG96BxCjcxlCvzlLg14+6wEK11ttxy8FtdvG2PkOIKuCQO5OSbr
C6PuOnAQdwPKa8nbsGpyMgm6EQ3dHJUB5IwKZhBjPaKv/V+uqz396nv0GZdFNG0Scc38jNDJYP1r
mOsGHn6EN7dGD66/GrIjovyf497JsG62ToM5WrF6WHaPuHLRcT+74I6/3MRcP/kMp+o/8axRFfLU
4QfGzmgIktL+RBKvSyMXSnmvvCe8EZWWaxCUnQ3nX6S/OC0RQK1SyVBtK+yj2pYh7KMR+WbrZyDz
w20/oIWJ4NL92/wqf/phKP/Fzzfhn4NF0Q7pRnE1ltxSdYtAR+4ejm1lD4PmF/B+MltMarAUt5OJ
PaUbAHWQlnMAWlIiZxqmYYuUW0gB8XNx6MOEg05ivGpa+v7Vezb2+AfQsjPoBFL7y/XhJM+LCt68
uzs5kBYtXZu2HWLM888vviKr0Qq8K/zTfYSsGE70WpB0vNj9tD+g4YKeWWgH442ooKCmxMzHklWJ
6ocaWPeEJNVJDxgJDQbTBqdrKv1MKYEjIhiUalYh5porCrLxFl5w1ll+BJ3AHzqjhUfqNQEZC4SC
n74IcKqROozd2KW9kAPF4fzhbi+1/0xV2l89oF88Wb63I/0QX1UJxyoaijMCqWv9H5rr0tfzdaar
mLWiiDgAia242OKNO4Kbe1+P0xoHSeEDZgxk4JLXfjU5InkqkBiwZ3M/+Il9kEFiR/DHOKXCZiWi
Gr0e04zQT+FTjD1r6Co08t6QWGIcaipPomUhOMCV8Vv3a8QWv5D2Yqxytc1dW2O3C3/JIiDeLY5j
OqNtH4ZF8HhtV8MN+wVefBWbMJ9eha8cWYM4aMAm85cKz5BsTQ6VNZtge1JSdC6bQQ/3YnuIhjRa
hduKzAQ9bXABAs0gsLq3+lk8mVp/zndRtKBX1+QmYeTQAVAdkj3moxlnvMR3OJtjCU0jI5MkDWPt
dzCDPKfS677r4vdrjN70wip9nkwKWpEeW3SlbiNvvNLocHpVgKLi7AP/5IzSLdKWcOhuxvlZzbxF
dNPuaBWiBbi6dJPD/0K9FZ7LbacBXVY0AsagWWfGkMj6Bczgoo1dc5x/kXuZaYr03q0e9KlmYETX
OPBUNrz6HeiA+1jzeEupCYfptyyyqweK7FFj/zhpUpZWSjp6rNcwgGY282rP8ukC3xxw+6nKlAER
Zo98lyAe5J7OS2ZNkL+u1AFnH16bnZoJmsmUskQ5/W+6CxCZ8qrkM8ZwFZZXY3JT+vAc2p+6JH8H
qjBNVclGi6dDdPQVk9OHgehCYcvRzPOcXHuTwBsjX8u5X7BMUA5ihOccr4N/WiHGa3zfJ5PH5K/O
0qY0xTySuAOXb6oWzsVyNcBj0MpZ0W3nsRK6RUX8TgzBUmN41GEJaFKItRYYUVPgPS7zaCRI7nJ9
lKb12fYJYLuA+E7FEW/R4YVfURx1llsI2f9BvuBoUXJ4yi5a6FBlWLSm1D5iNGsGiJcOVpl4m92D
NKN2sLlGNjde2I/B8pdO8s552J3PSQQxEfyBU2i9MLhewn12YJ3pA0JGRuUHp+G4GBZt3ImgQ0Ek
PTc3nT0os9nVnp0womW+9pWvcd7kybI43g5KtxINkf8QAUgX/L2hdoLvDRTnvtNYCUg3sfTLV8r9
LdTpO5PN+pHWK0m3uxujMFwf2SLsomMxGvdY+akAqblUxUPSm/sltMVaHVAAjg1nN81cys56Yo/V
aCeZEJMmYP7SVjcVQaKx+XgAoZAW3mf3XkqHvMYYkhcYPnITAyaI31OTA87GO0IrjqdOx3xBT4+x
S3J2BUL3uaNJPOG1hhBKrD5NP36WUgxGsV6z1z03xxoz51qcZ2ZJKVRxsJUp+/Bu27PqI3cuGauN
2yZDW/BQHd50ntkDVJW5i40aLkIn56sSGRXKBPSgrgmw3sBYhseba9DkJ0fqakn2OOJ6Y47rJU5l
wzm1vRCQQw+Hz4YwkYDRZQGY1E5KDQAGm+KY2JfO4Y57aYF42/hkli/K7HWrgt+VgC0lkf+1ZB7h
3Kfii5X+lTTYW9qRt1xPBnUAdRd7+Oi3rADAvKdtqgG92Cs+/U+vDmVGkvA9of/6KxqgeNvs6rov
CgaNPt80VRYUSXeZGf4pqyj1+uUkeCZ8j4JGm6+WFey5Q7mF6S216L9zDK0LsO+Kp/rgDWVuZHN0
cmVhbQ1lbmRvYmoNNzYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4OCAwIFIgDS9S
ZXNvdXJjZXMgOTcgMCBSIA0vQ29udGVudHMgOTggMCBSIA0vQW5ub3RzIFsgNzcgMCBSIDc4IDAg
UiA3OSAwIFIgODAgMCBSIDgxIDAgUiA4MiAwIFIgODMgMCBSIDg0IDAgUiA4NSAwIFIgODYgMCBS
IA04NyAwIFIgODggMCBSIDg5IDAgUiA5MCAwIFIgOTEgMCBSIDkyIDAgUiA5MyAwIFIgOTQgMCBS
IDk1IDAgUiA5NiAwIFIgDV0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg
MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc3IDAgb2JqDTw8IA0vRGVzdCBb
IDE2OSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5
MCA3MDcgNDgxIDcyMSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSAN
Pj4gDWVuZG9iag03OCAwIG9iag08PCANL0Rlc3QgWyAxNzIgMCBSIC9GaXRCIF0gDS9UeXBlIC9B
bm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNjkzIDQ4MSA3MDcgXSANL0MgWyAwIDAg
MCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNNzkgMCBvYmoNPDwgDS9E
ZXN0IFsgMTcyIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVj
dCBbIDkwIDY4MCA0ODEgNjk0IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9I
IC9JIA0+PiANZW5kb2JqDTgwIDAgb2JqDTw8IA0vRGVzdCBbIDE3MiAwIFIgL0ZpdEIgXSANL1R5
cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA2NjUgNDgxIDY3OSBdIA0vQyBb
IDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag04MSAwIG9iag08
PCANL0Rlc3QgWyAxNzIgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsg
DS9SZWN0IFsgOTAgNjUxIDQ4MSA2NjUgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEg
XSANL0ggL0kgDT4+IA1lbmRvYmoNODIgMCBvYmoNPDwgDS9EZXN0IFsgMTcyIDAgUiAvRml0QiBd
IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDYzNyA0ODEgNjUxIF0g
DS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTgzIDAg
b2JqDTw8IA0vRGVzdCBbIDExMCAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAv
TGluayANL1JlY3QgWyA5MCA1NjkgNDgxIDU4MyBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAw
IDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag04NCAwIG9iag08PCANL0Rlc3QgWyAxMTMgMCBSIC9G
aXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNTU2IDQ4MSA1
NzAgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoN
ODUgMCBvYmoNPDwgDS9EZXN0IFsgMTI1IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0
eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDU0MiA0ODEgNTU2IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRl
ciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTg2IDAgb2JqDTw8IA0vRGVzdCBbIDEzMiAw
IFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA1Mjgg
NDgxIDU0MiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVu
ZG9iag04NyAwIG9iag08PCANL0Rlc3QgWyAxNjkgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCAN
L1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgNzA3IDQ4MSA3MjEgXSANL0MgWyAwIDAgMCBdIA0v
Qm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNODggMCBvYmoNPDwgDS9EZXN0IFsg
MTcyIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkw
IDY5MyA0ODEgNzA3IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+
PiANZW5kb2JqDTg5IDAgb2JqDTw8IA0vRGVzdCBbIDE3MiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fu
bm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA2ODAgNDgxIDY5NCBdIA0vQyBbIDAgMCAw
IF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag05MCAwIG9iag08PCANL0Rl
c3QgWyAxNzIgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0
IFsgOTAgNjY1IDQ4MSA2NzkgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0gg
L0kgDT4+IA1lbmRvYmoNOTEgMCBvYmoNPDwgDS9EZXN0IFsgMTcyIDAgUiAvRml0QiBdIA0vVHlw
ZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDkwIDY1MSA0ODEgNjY1IF0gDS9DIFsg
MCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTkyIDAgb2JqDTw8
IA0vRGVzdCBbIDE3MiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayAN
L1JlY3QgWyA5MCA2MzcgNDgxIDY1MSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBd
IA0vSCAvSSANPj4gDWVuZG9iag05MyAwIG9iag08PCANL0Rlc3QgWyAxMTAgMCBSIC9GaXRCIF0g
DS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgODggNTY5IDQ4MSA1ODMgXSAN
L0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNOTQgMCBv
YmoNPDwgDS9EZXN0IFsgMTEzIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9M
aW5rIA0vUmVjdCBbIDgwIDU1NiA0ODEgNTcwIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAg
MCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTk1IDAgb2JqDTw8IA0vRGVzdCBbIDEyNSAwIFIgL0Zp
dEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA5MCA1NDIgNDgxIDU1
NiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag05
NiAwIG9iag08PCANL0Rlc3QgWyAxMzIgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5
cGUgL0xpbmsgDS9SZWN0IFsgOTAgNTI4IDQ4MSA1NDIgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVy
IFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNOTcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgMjEwIDAgUiAvVFQyIDI5OCAwIFIgL1RUNCAzMDMgMCBS
IC9UVDYgMzA2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4gDS9Db2xvclNw
YWNlIDw8IC9DczUgMzAwIDAgUiA+PiANPj4gDWVuZG9iag05OCAwIG9iag08PCAvTGVuZ3RoIDMx
NjUgPj4gDXN0cmVhbQ0Kgv3Q7GDuQKZyBk/O7g11geQuk+UqeFRUUoAv3Md5tWj4Y8w28D6kJWsV
9WdrZxZCzCnkd+WM7dsmF34+rrYsmG2d1l1oQEoN/tKp3CslfMq+ls+jMl7dKoKd4Fh9Vv8JfmA1
TPg7KfMYrvKq91paoAibYJ0waGaIcPP916DFL2DOv38lQ+gcN7OHA7gU+zP4iuRnfZFht4A8GBvo
fgy1Un0W2NCPUT30kwICbZ1l6mfH2uM3lwJ2dlM5Vvpu8XqjuyC3Uvc47058jaklZKKckpjiA4BV
AYYN/ZRTtfA5OI3a16ah3BMufBQjR3PwH/W9aqBdQxjeUdcx+4BxWv5zLRNzygOM20KuguW5aRip
vRKENwU1B6wcR3+l1UViDLU66+EXkMR6nhW8K6X+67QL+BNHj6vD40P46CpepyLhRLVvWYsygpEv
HcytJGAY+5RROZ8MXN8ejOxnC7AiFnavIzZyA+jRB0rOJvDGyf70WAIgYNQETOyqrPQdY7Jl0crv
RV2BhwZyS8e9t/QV38VFQ6wwqYjtlkxgruj0agCvO1fQnvHqF8qbg3nkAs3U7rPZlGNbIRUC1y97
71zr441jqysLNLPsq2CQZwTRGu6xutjm5YT/MbnzM9DISJQdwpNjkNrJBiYPEEnwSXO7mMg/24HJ
O3vrXQGzjhxwEkrAg9PQzYj3xEIsMm6vaLKSxCYuw0icjPESa/3sL1/g6/Q95Fwv0aUXbFsPnKwv
9kZa0ZnkB8PCQ4vGEzXnVaXEPPQEodjeEz1cvQwIKrj3qFGsomni4lH+b64ryrybYv09bmNoxkdO
wo2JDq+tBE1bRUIijIgLer4Y+aBY4RAYjajwoaq4cYf5HfcGJbe25Zb1DHLw9H8dzATGQOJpX3Z6
Ykh0Dkr17AXHq0E5DMNz/EUnYa4tSpd4CBWFXYViIJ3i3dB3zA5/hS6vwUfQDOrVM8CeAx0W5AT3
fNrbge6QI+wp59rUY5vldKAEIcWDBckcCTFxBGLLZ96IwCVA+2uKJSHbWAY3G0Psya4ShqG4gRPe
2XUdkOYv1yy36VvipMM7nsjUm3Xcpv1SAip6Wha+ytVdtssEQzxDKamiRdFOzELVd+qvlF0tRbHy
MSGvcDXePhHINspCuE1Q6VMOuKjwVbe2nG5cLZbDGawFCNTm1IBBAUrUe6ZJYS5J8u/rbO1UcH+S
4lPx96Tlz7CPpJf3AN8AkhPSdy/J50i8Kg2z+w6YDZhoQeqYlKrAA28NlcyngJORknsDPltmd9v/
lRa1eL3sDfGmBH0jvmtFP3P0O+41YcfkgYGdYpzECJ0Bb8xszkkgX/V9Ws484s0sWCnB/JqzV+QC
9t1YFqo06quAJFP6Rb/YKfgnBfem4W4QXLVvMmEaobR9iQlOhZVeZrfnczYyQM3U8YKBHUw9WEY8
HNr+EwEJnc47AZV47TUSs4+cOlEyXcA69rWVBrniRKAZM+fpYJqCDq1Dwi8FgXMy3+jQw1FTRTdf
pI7kY+ONFFMVIpxahkrRqyRzceFedRLAnHK/00wdi2krE4BtCZHw95mikzrRzJBo5qXLfPHPbGXb
UnOPUZ/6Jfhc63yWt1IC4kDqq0tjKXSJrlyMe6Ih/mJqokSgqhebers22M93FNyScz84UBtrRWk8
dqnPwhB16fH6UmOe/ZsgJn10aX11/WQKao2siRTic94QOTyFA+DFjLxYbdfQX0UTA2UAJHO2rMhA
TW2GN965H77baqzDnHLgeWI/7c3stsX0v5WdhG/ufvSUzDfHgGi+hTS8vhvK12uplmTjSOTa4507
3AO6zEdq4y/TUm2isdMmZjLFrsnJSJkZkAgz+WmYJb8TYEj/1x0yU+0ZhPtdFh1g1pGp5JHJ4Zg6
uoR+pqXMFl5tDZ8QNWgnWzgmGgUBDCgrkHh2zafk1TgD4+2mGgv8MOTomrdj3JPv8QSSB3ESTevh
vjLhnVwO3LvNVL7vXt1gqYh8bbs+9iIiCPNksJV7ixUEhJIvSJI6fgMOY+m3vUsp1vAbL9l5UGXs
B3oJoCaTqFjnkxWEzx5bjiBQHLqZhVfikvqwbVI7QkgQREEnjFtavIRysn8PGV+oa20xbgUC4ioi
h6+cqHjDzjQ17hWz/+7UZSMM1rSd5NbS6iTlrrVcppmYRunVAK9hJtvUMXWG/mEA091sXBxmhxj8
KLy/ON1kxkGmPm7VtgvMfu7rvwQ3MtyzkCKD5GvKpEBrOKcX8sIb6VObtU7Ti8rb37g9ssowohqE
Y97Ihfcr2EJELL1za+IsL2RFtyU8xyonmSvanTRe5b+0YtNGv89wlhfPDgKc92SBrpMtB5CIEm/M
eZVZX5Q+zud8pXD1+NBBVOJWwFXLpRQAgQTHBvQdBhe6FEd2S2TD2BPX3qzBzNNdacnhYl9DGUSm
w7VA8a4dNk5byf+mob0c2e4jQIrIxbplazrTv5g6v8JTqL8woTdloBwyDaOSlrYx0CF+ML+Ayaw8
7NorL1nzKyBueKRKMjawIe6ZNGMt4uG023YgRfzeEva4geZDXAG1COGbH3lrrVNK08zeeq1ToSqO
kM5KhhlWiBK07LX13eAE14/jdILz36VqmHxfExAMjvW1GW3mcwUcVU5pFaKut4wqQcGOxSbD37Og
xxZD8gqKy34WMLwFUH6MRSkS1Yd06AirzOJJLVgVTxggRMeZjngb71P9zAB05JzzYMthT8yX0/Dq
BGRNKpfJNCbVNmW+sZ6iPJQtLCvEi4+RSpFMPE5igO/ZAfNIgeWS6D+VZNoe+3NeGzvA4mbPEW4L
Ih4yiWkAxDaxub/olpPI21j87JUSgSHNMcKHfBPdkAyRdWVW4mShkCIk53xPXky66JW8PNzHEC8S
saiJum68B4JvH3SSLRYp5jxn0RR5Hd0eI/K16mNuX4dyxJfCsBrbrwl+Nub8vc9q6WvnlbbJ50Cw
eQcVRAlbpjsKZSCl6ucx+IqOi1lJJPpoBluG+0IIawmGdPc6hFVJW17CZjfBVq9AqAiuZmwzqdgN
w0GwaU6svh7Fi/wlZVmx/pcCE2NiqkYdIAmSGWc+dUKZtu1LUyXmgfP2QkbbE83vRqxACM9cBW/J
GJDJZzk6s8M0Nugj2kQDQJnJIklFm6Y6eh8iklHVzNzbaChSk8GfgJdrg/Tu+9jhNGG1fuK5K+OX
6hta8Q1OwaFgQZgUFqXW6UutVF9zr9k2s97Ve3pA/iOKAknGx4wQhrgb/pzM7ahRihoctOS65HFU
40ZBKh8v2zly5MzKouRnUOsOrzO/oWIoM+zY9dI0AZ5GblFzEkyN2yKueVL1hpFxCOrlMp1fuqte
W3kfNKYIGOxUijV515KetCp2T9af74fHYuS/euh9CrXBIrfFhl5rkh2bGi1NloYTTaRRKrKUOvjI
0P2BDqiL5K7x6YbcfypebhdSR0SmjXPGS5+2ixd5Ec3iX0IC0rw9ypmboNfOYqmy/YIktClOwc1I
ZNik/NfyO6hfygjrLR2XF8xOJaDqTzjGCaGyq5w4+pUviJcAJL7iIkTHJFugqA7rqKXBwT9De8b1
uhz6rZ8mu7FZdsT00O2d7R2jrAnNt/Cwzru/E3cOh/i1yuP/y9Rv3ndHv6vGnKlWxsGcBuBtWwbn
OnO16xGbP8tZg7ERTNIuFCla0ox3Tmjb2NB7a+/5f8izYnkzHS6XlGHmxk1MAo7LVNg/7R7bEPtz
7PaT/Grmef3YofQsqW8ev5n2aKHIaVOK0StWX52csDY8c/hmxTtYsNoa16majKEaLefnw6f6zJ01
dPQfjDVYceqpG6eJC7G4tBv5F/ySXrXMRRMkcqIrq6XP061DkveNz2O8LS6wx+Qobub9BMlPIJ8M
nBBdZn/MLZrGyPhZgYrUMd3kfCFUh0aRQqikITUd0EJXCnxUw6w85ppH98PKx9nCTiXxPIyW2OZL
K7gUtBs11aGNpV1TKNkJBjIe1flcODpZqhfo83OL5RGkzlQ4cwXOtyMIpMTn8lNa04SEdr00TsSM
jjRBzm59Sjg1WiqZB6q+HrDx5DQDzLigw70ysnfDFdMEZAix0ISy+SvJiaUJ4N0gKsDugBCIh0uK
PfwB6ayO4WMeJc12NQ/inFUcsqNtXeDL969oeMCX8E3Bk/qqB9W7b+LkI47xi9amTwbaje+D78Oq
TDOmkXMkBc6Z+QhME0i+vXgobjgMnVGnh38Ggj6W7Q2yAt1s3WshwoOYYV29DWVuZHN0cmVhbQ1l
bmRvYmoNOTkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4OCAwIFIgDS9SZXNvdXJj
ZXMgMTA0IDAgUiANL0NvbnRlbnRzIDEwNSAwIFIgDS9Bbm5vdHMgWyAxMDAgMCBSIDEwMSAwIFIg
MTAyIDAgUiAxMDMgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg
MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEwMCAwIG9iag08PCANL0Rlc3Qg
WyAxOTUgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsg
MTI4IDUyNyAxNzQgNTQxIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9J
IA0+PiANZW5kb2JqDTEwMSAwIG9iag08PCANL0Rlc3QgWyAxOTUgMCBSIC9GaXRCIF0gDS9UeXBl
IC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMzAyIDUyNyAzNDQgNTQxIF0gDS9DIFsg
MCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTEwMiAwIG9iag08
PCANL0Rlc3QgWyAxOTUgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsg
DS9SZWN0IFsgMzQyIDUyNyAzODcgNTQxIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAx
IF0gDS9IIC9JIA0+PiANZW5kb2JqDTEwMyAwIG9iag08PCANL0Rlc3QgWyAxMTAgMCBSIC9GaXRC
IF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjQxIDM2OCA0MjMgMzgy
IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTEw
NCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjk4IDAg
UiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYgMCBSIC9UVDEwIDIxMSAwIFIgPj4gDS9FeHRHU3RhdGUg
PDwgL0dTMSAzMTEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1l
bmRvYmoNMTA1IDAgb2JqDTw8IC9MZW5ndGggNjQ0NCA+PiANc3RyZWFtDQpggaxjp4RTFtIDtFNS
aq4FtZ9Mf6YRmYN9s4F3ehKEyO7I8/BC0J5g9NO+sO2BmPvc6JT/HitX/lW5V3UW1IPb/LF6ILtN
L3cyL6IFeJ6K3Shw/B7m1MepqqGhgyifp0Kp/hFoTWazx1l2RTh2ExIkKNzLP3bobTM0qn5b0QvY
G9qA5RHhDgIaIP3V8SlmuFTTBXo1tlN53L1kbU4LC2GAFph0HOZuUEMJFQ3YGwJy64XZiG6LUl+k
UuP5ldwwOuxPr6Skm42Z+MSOICfNTDKDzsRlGSTD9eFa8yV/hRvhF+/GTODsmtkUezh7zXg5UkEp
Y4Cv8YRdAKyu/4WcWubsmBT1HhQEgJuyaqgJex1y/7WvktFt7HIwbf3tKvgpfJogA5Mmj1BZXWcP
N3qU+fkUsw5AVaW8+Y05KhGMe/anrN08RScLabRdE7/lwZFZHR0IENTXzb5TndweE2mm7XzwI9K1
7p3TdUUit8meh9hP5lIsf8PQJZbL7lrwAwaW4WYxdxvZQLCrSjSRldJq9fNf0WAQFHMKIYIFlfwr
ly/T9v3k0vbApaZ7IEcYaruz+gAoL+aUabBLP25NKTo8ZZJSKA1e3kCtJcvQ3obBkz+SJgBkrqDT
lajn5uTIik0yQlzHQhOcVzsFjuvMu4K3hfX7Z9beIEhv6HDFpFmpYCQd8qFBPyJ/q0O3406vusBZ
uG2CYhSS+aDW60a3yD7o3l1fZvG9zRGFYPaOD8g9hhXk92ASuNWchda+EUfZWyI/2wF7wEmCaDnF
nfLanF3czPacebNMomKcuB19yo+uOToIWr6EMBHCcRHq7TJ/t7LaONhYRMQClTFLoQFgCZ2amdjN
hmg7JenQ0FhR48gPIkAZS3kgzpopmrN/VpQC7YkeHPrSeSxS5MrQzqxllc8hiV4wr8acjYiIvYsO
Udd9M5Q1bVrokEz+g1mbMJpM6/zDv3BLc3hUxM8D83hfVWYRs+zSsrBG2z6l1TpbyHfAeoNL7uZN
bj7RmqHCFs2VL7KlbkVXY69wXUkU93IyJXXscu+mF9dgFkgVuDr/3FPxDD1lJNW7nOYl9NYRL9tX
1Scj4hNBQzAuttsf8aVCiyMW8gj5WxsH0BhqS18PfD0WFOBOSplD7+FaDq4BqT1hdJcdEKuDh/CA
rlnUlK4J0sVpndqQTN0AC6F/I8sqHQUR8w1vbUAy9qrjkXKCBBrDkYWfdzzN4dhZuq7IKnINExYH
o710iK1tjzmPvJCD3RlLxLnTZg2TfOfA1vv/LD2k7fGqohilBa6iksAufqoa58qri4rqQQrWH4AE
eKKOzEhdEBRNKcs3V29S7GuAx55ZcaTOif1k/8/4g5RAjGAhDWJVyi/6TtKC9WYzgG5ztHY0wXH6
pkZkhvcBzyXQI5Aw/42D01dooAaWYlBb1tSuZ8v6UyjqGCdD9pySR5dM6dNR7ZwLOCxTpsyaU7Yq
nxyD2Uv4imYKSKqZFYp6/8PPDiTV9ABB4N/06Bau/H3vRp+zcevmkzqLb7Ku6hOcxRYsOhN13Eq4
ttVNpUl9dqOBEi6Ur08VZbSPwfbeJQ3Vsr4SygJ+FbLjs8Ul5d7AGedpr9XYyI2OMvN+fiQA5ztv
43dhlhtjZYd+VcXfOyuBDwKRzFGbMzc4l6WT9tLwYnWrf9rOXP+fjyizHuOLwHUMbouC3/gMqAlL
9dTQ1ETAlujPhtD+oYabzxac+fmIH8VMfr3gSHB40dLIJDPwFOQXQSnKWbVHHW63Gu6H/GXaCTw1
Y6UD9nYORyOzBcj/fdiaDJ6VCsrK94nL1Z4+Q19pM3HcBcg5KtIhG7cFuTzELYnsRhNdwEfU4FNw
dtMrA0kONNQHkigVTl+9PHecjlu44fCE+LbQzzCMjIKeWSDRQs7ZdF+kddRhPKP8M7FqdOSDQJNi
RBLIQ1KKD6lRCK5uhp0s7Eu6QTOaEAD2h94lVOGVFA8QSILmh1L5vrXpKbXnPQonUHIRlYFp2DZQ
j9TeyfbEYrmp1xd6p7yZRB7x0PKCASeriW7g/a/tcYOrZBmDPQr1qKEIn4F25Y7S3NN8vAIpgI0R
uXyFJSq/W/zAJ94aK3cm4tTs5lhTfkYWXHQK8UbHFUiLMg0nrmldWDxRnTA8gnDZ0hJi4kYvjoAq
XvSZwGv/AXzwh4NkexeuCPYAGr3OZRUtQkHezIegarPlfULC5Me9F0FXuWvnV6Jl593qtRwSDUBf
yPKz8mOXyMfcW/PCya2NaJtRBLS6s7u4t0jVkm5gnFd9580EqZzf4EXw0m5hD7Dog+P6sHnTmQmu
aSMY2nqDfmTEfnYuakThSTH+hiAuPftI6Y7tOG8JDfcw/8GaR47wle+QHuRmt0crKiVSlilbu6Ou
DexQe/o/JgfpKu3NmRqLq0BkQB2hREzwCoOpV/atZN7v5cXl+YxSDV4VGc6kOpzTejwfJvNa0O49
lUQe1ZwWLDRb8XXFyGO+Ohf5ztb8UYpRCpAe/7unFnKu1IEXuVeUQtl5/eZhqUWZhcQNagGsIzAd
UuK0iluGOSTUhZZXDXerw1K3sSKDEf7eEanbVqDeMsRGTfBGJiTw1sVI5t2OF/Yoqed39Y0IecWm
c1t6qBUmblK6zWLd+k9SSFhTFefE97S+9B65UrahT1RFRWsIhF6T7BS+N2ZyHW0ty4XP4CYsjZRL
JG7Orm5Tm3HPILwN/nbmpsou8Snry4jqrCdCsI8o2V7dUn60ZkIP/eZVmQUbjJNnpvd3mrgR06mw
2xTx0/f+SAezWkSD3UdN8u+P3Eo8W6RKL2Et7Zbs8AkCHxWupoVB5toNMb7wmMi93gDQjSfBrcUE
vyREEM/guZ8JRRgpY1xe/rjWjxB5gmkjzhs+e3a/WUQJYRWdCRKHVlLU+BqHwJGaaaXf3on9n2Mi
0afSe7uVfvx/jbZ0R9mdPwzUDph7HixLw3uNfLi1h46gqakKM0rsrLfAHcf6RfghbnJXCo/OAlEE
VWs8gdnEdkfNI86SxQPltl5mpEiRq8NAXkhzf54DTykz3rt5X6GrWiW9MzOh6WUhE/0Dscgd+H5z
gU7DeqDoYs9JyjQetsN4gVEa7v9CPO2KMEvL9qZAO7A2cC1GqxxPo3G91LA2QySyMHICP2J7ujf/
3cW/I2wnofhKl5JbJl7Fl3An1qiG7f1OFO4FFDeQjC0bbbOdH/+nB9ySfhwb3Kh+mgOKbAXoyonk
8V+vDzdw13O73eJSYNxi735gGGDXWl9nVPE2Q5IdK6Ks7pO1APzxr/uBhJMg9sST48tWkkFtjP9b
B0F1hXtcwHgXiLnP+wuXoL3RplCbxpzWWH9ufbpuuZDPDTxSZ3wjG4vXKKZ4LrWXf2cudMUXpnDv
t8RbQa3SmfZvOniGC+2Qx8nqBSwdxCoCDnW/yDSQ/T02pcJEYV/PESjkEwK+ztetKvk/wh9jPF7a
DU9X/vYD0GentEZ5Prjm940+3/kWrajMovtHHTbWk5cTc2owFKBGvZTnHCgpRCIQbkaYGBE3SthT
kcEEm4yDmt4zF4EKZSuH5XvnSuoPTopvStalt7+7XFX4SJ4CqIXj/JU21uxaBAv4UAbSeEHAT3nW
gHomcwtueYz3W8gPRGGGmTaXbD0oqK9d2P+vFTRpZLac5bt4pxnFp7wQ6xmnozel+EJav5XkLHFZ
Tqcf0muY7n4lsfRnJMsYwaGiVVPAq5G2yAG/6ts1CFVydLkg4eiaaunTX7uhpyFWXQfAmFQLaQxb
IXOeDMUFOg3glotOf+LzWIxWGs9/zxr45cQzPuYpabchMCJ1fMGkpyA5FTVL3QwPeC3T5isIostH
oiPFYNOdHvNpbow4iab/mkoUIW9Pisustg9Nft6IUyRYrPPBgGF0liMqcenPFi8FWw7y+WcZWtMu
7D/TZ6bGrr2v9ghdK/hRw+l5ZfPbnxwpcOitH08eQojEnlX4NHqvDjh/9nM9VMybhUELf/mLvFgX
0pDFlzx8pq/3tKlewDRwh//WxRrOwRhZq6YKGvKQLow6jl7J5Dea4XuOvcZunjK4md0BKnwpisf6
jCGDeOaeyByHGj+yAwja/oHE7KJQZUhCL8zw/PYTKqeTQtobGsvAkVg3VL8J9Nd7bO6jQsDk6vtM
di5K7W1zcSJEhVfH9QPD5OKoYzzH3eYlmzOsNMAVVc2y9sIAclZN03yWHJ1TfCH6PYMdkk8xiwPp
+wjkGjYqRIZHNiVK4fqbMEparAV07xXa/vIv8VF2wcTFefO/QvyexJ0kR3JmTLQqyjzJlQXp6Rob
qoLb1U3gTfa+Ly1qPkj5IJcqIy8A/z5ckMKZS3275zb2AfeqDJ/TilYPaEXFq0sM+gp9R7kipoZU
63rm3NQ4UKZQVx+6Hk6cD477dnyuB3z6R4kJ0RQuwMYz4bJBnAPUzVW03ISJZ8WvAbqGcSd2QrMU
+hE+wSyJxvUV1Htl4bJ77jdcSSL6E5Ag87r7W2xHOTZNCfZWSLJSlx4l2l1Iy4SSL7whTgWs9u/R
sxeTsUJ9sRFKpz/MHd9PaZ52J4sQDoHUCUi3Mr+6gJ0cGCv9ig8RFR6PB+k6U68fhqlvG4bR0dfY
5x6z37+7o2xrA51KnAy7VcA34ACrhjw1P/WuorcJpk97re1ggc51ja5Q0t2ufMwRAeTSPUTLi0sk
cMMuDXL6ZdJ9QaAfDAJx0VYiU+VBf9BJIViIxhCaXr5D3LibXJL3AfVG5HqOznW3PZ/lIyyDUoKt
GrOUESUWRf8VMuLNF5/6A8sJ2BPuFjzK87OOlmtspiSEgTOB8tga+f0WYH2Rn2ZmtubL/DueypDq
Ho93a5M8sGSsQvgUzGUpgZ1uZZ2+VCwY9HJjwC+EQRINF/xdMDmEVBAwY5yW/0xuvE6YUodB8s1b
jqXK+NaDZRP41dX8sS//f3YNwXb0M5qdNXJvLf1z5YrryJCmu6twG5oEtFZiBjpihH8KEimvbQqQ
+eHNLbo9l5e49Pxw9RvIdyNbEg5RaJBVwLycsBxCIkK71YJaczzYkRU5uPTbFPdAu4EXAmA/gIoS
pSASRypml6zuGnn1yaQTRYl1IaF5qAQU8m2s5Joab25FxbofPgbGKkZLvduerqncJXGnDhTLvB0X
42kYhAsDXx9CiqxjgZKODb7xq5PRz3IL5flIuivvd1NBoOYovpJfrQM9sNZN63XklOLq5YYD1u/H
lGe18MC2k7fl06+D9hGR4SmKh1t3vN8HJnpOfTrVR8f0JTfKj2T96BSycSeZs62yUMjMAs+szZAD
L6IqiwarfOGm/U3fJQzdMaoNPmoS5ihYtnd7SL14WI2UD+z//qg0pw9X11uqErGuoxLgHEMjHcxT
b5CPW2qCrKnDivhFGanBC5iIb4Agy5rbs2V6M43Kf3rOKHsBQzD0DMdZatAtAt/nmj7/+Ce8djKJ
Hv97vY/J/UEMafi6tHPiNI64tRKKvZ/3RclxBkFphR80ztywN8NvsgmSUBBPcPbOrHUltVPG/sJX
6cofuhny1DXpfn8OBJiwXu9KwJQSspFoKJwfVhIw1SyKM2rJWAJnHN2qMBsX6jRMO0dwsNZCMZiG
TQrdUz2e2zLOJ0VBrvlFCCvP1W7ULlucrPEJsrUbRtV65TR7WPD/f+jt48KylkZxmnB/uRFQ9L2z
lZGb8fmaxXKYkxYzdqIPySyzrQqtn0DUAT7NRKJAga6GSE06MIDT0BipBBydTOxN/k0vVnFrNdAq
1uUt54EnTE6wdnXg5mpuWNnhFIrupEP07swvbIq0+b4ZfGJhjPG/roeZyklkalHtvanQeznz4VQ4
cuPL357h7rj6wtja2fkhacmEz91/qwMW5HfmjvxNqGjziHgyYUjQ1LV+se6U91vE2v5aUqFiiL8i
IPU6ie+vdsR4qlQKpA+bdRYbJorpMxvT2Fz9CLWDFchD7Fjn2Ec2iwxwgR7eL3U1WiohUR/tT3Ra
RjbxQsAhixFqxOGqZNOwI7x+tnaRrwzno9JK0Ax23OReLf9uowVsdIn7wP8RUdz2hs/YfjftLwfk
BmGHjVb3jz6v0exEgv1p+Vg0P8v3qeNLpvnYWWlJZTNjS+PllzqaWS7mkl9k+bXYMxUoIgk5/M02
3R8ixpUZ9r4KlikQS1fzyKE0WD2ZLeP/cWfORkeicpG3l28Wa4gUpbvQBBZrlYWBWJHbKgvTTdPE
jr2v6f5EwDCiOjwKTe+IFxQXQtqUGQvgHdvCwuSspAG5Kz6Bk5WipFCK7tpRz5joXKHm1DxapaNi
R2ZXGOIDYX7EAEgrHJLX6fs3jfdgivhJsYqFCCmSe53NPJoc0slJUwSaeGXiTLHN4sIMvsV3FfNZ
NIWf1o8C4ELRCL6f2ze4nEX+JNQEi9KKh3rk1/HmH5jU4PIs5s76mduhkXehwufH0zYzi9I8xjwW
asKOn+nCB/D0kNuS+rM7dbmYL0vlaVx40LF3Wl0ECeX5IiGaUsDWkKNa+qFUiPXRCJDKPSDyrlMS
J/R+OkGkjBjLMTGBo+lmd50brCKvNr3Ku9d7ehOFvUXzoqycmOiCCO++A98UQaitdkYFU+481TJF
OPUHeSVv82sC9Rw0UslTjrLq3UwA/TFGPqrQLsxu6lU1rYYRUjsiCUyMWYwcSG2EYpulH6R5DE6f
76g2JeTlzqpAX4bEtSSSqWh4XdgGKVryETllKjmCY1ZD4IdM0S4YQP/9VYZkkTbEc3QjUEhIiHx9
hgpjDoJ+ln46E3r3dZWbXwDRSnMYWMHRmkhPewIg78tXpw08ZnXfN6DkhsVUGCz9PRKXG463xxYG
m9u4mIgTSXEvtnDeefZN4bNRqHpiXWl/Ud9UCjMIx7lvvqhaLACfnAP8GncXTAWR9OhPx6SZxCM4
tU56GSAKrWMiuWGfeWtoEC5ifY5n9oRhXMs4l6e4Gp7l5wkM8bc1oVweSNXeXJjw1NncFIKFyVaS
KBwnXdmbf/zPGTeJXorCd3megFywUHf/6MXvtUS94MkhcWvV3Fi1UVZQoA69JPCFifFQp91PFvTP
f3NKQMi+JHekICJCYh0Jf5mAt1sisNupmysv+dkHTl2O5nUAQs4V2whJ5nhPw4cfWvruj0Q0RwF+
azv0kOHt/4OlaWCmeEYOTDQD4oYjlev+p/oGWYJ25teNJrmAXQCXxeLSYE1SpgOD2V+i8/nzM9UE
938+GPL78gKnT5iDjaxR2yeSllPRYUnFjkG0k9R9eH07xc28DcYDKoiQ2v66MrYMQyQrDP0sOj/x
LfiIH1yqWkvxgWEUUcq3evwLacdHpVLhhhWwqQN3sgKsRC9vlmBNm3zQ/Smz81zyHKkykgxyl0RR
Y0j3TBJ5AGp9lKyvJMwS6I7/MXC4kZlpwLh3LN+/Zg8WBg0vCOgrpZcWYxVkUgubGaVhuhJhQznj
09RyxvQa8O8mt1d54laZcVZ7xCX/Dxx+7MXkn4u0z+CKprUt3vF3ckFzYatUx9GEfPJgpi9WBmrt
e2+Nq2enWWGVjh07KPKzIa5/OZkwpVL023NRP40Ej+brIZzZmkSLSNzS+rE2MIpiVv9TgHtJREEq
dwIlAdPVyC4K7j7O9rDIlWuzYTSGV7NlekUpITQy/SFrcMMg6524CKJKLlOCVmUCD+B7pNO7lhar
K9xT6uBrC65LJf4uZlniNLjY/dw3D1S9DchOqdsuVDm8jmEPrjDVH7BJjNOXZpaiS/alhjPkrlRg
zohr+Eyt2XhcUpdnk/4+uzxgObqswyTeYY+guoj5yL8wnVXrqFQfx1P6XNDTfd1NU2Ah26ZG+mF9
nbf9eGGkPsWP1bSdJQyH1InQoGxq6TQU/M6lsUvXrxJypVHzQZYIhlXKE2j2qg15L6SBsNiOs5nK
oPhFNIBbxZnHUfvemp9upXyNPurKoFXdLgxI7PyD4WHj9PMZZiwDNhSD3ZhjqWL0rC9hVVGemEqZ
km349F7qUdF+w6kBQATSl05EDK0LlQzkKQ+aL00WRxoECqc4B6KaMA7MsEr9vOXJ7j3cD3rLjl7O
mq8Ogy9YPVr1BYqXTmbY4zj8id2Evj30OYsbsr81Lqfh01c18wNQ6peIyxQ563SbXMXLyglBTiuh
8xlOaDUrRsvUBK8cAUft1BNJgYfEcZ9EeZlnZlANWpbPdArLIphIOi+Evmia28nedffGPTv8j5M1
woJWZigzNsWBoaJLefONKdEyzlm2BPGrqU6+Ib4NF/UGszmM5EmJQBOWfp22qUcApfr414+6LUSa
dX9P4xRpExQMY1NCDixAdSF8IxLs4JhbjTZqs2cUsitqV+JzAM5DpOlr4yJwEgCNVwkL84jl8yZL
qRJLRQTXzZNzLS5817yL7oXEgAufQY4S150Yotkfq8SYpQisc2bvrcmCOlBH9RuZLIl59TRG+B4b
WGtZp2XkKup9nWJeVXbLSrwEuZnShku+Itvh8EgiCpfTxK3Hqz3A8p6iP5OL8gL4ZHoNSjz8Insc
v6+tkXTc1GND2XakAypFbxCIn7W02ixFC60bSMTIedgqNJJM6PtZTNRML7qWN8FoJX2seaPjIYTc
mAHD2D/kYrK+h7PDFhiHWTNyec312Nr0jD6Zcn4BnU3bDnJ0b1aSkaU25GVojrENZW5kc3RyZWFt
DWVuZG9iag0xMDYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4OCAwIFIgDS9SZXNv
dXJjZXMgMTA4IDAgUiANL0NvbnRlbnRzIDEwOSAwIFIgDS9Bbm5vdHMgWyAxMDcgMCBSIF0gDS9N
ZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0
ZSAwIA0+PiANZW5kb2JqDTEwNyAwIG9iag08PCANL0Rlc3QgWyAxMTAgMCBSIC9GaXRCIF0gDS9U
eXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgNDIyIDE2MCA0NjQgMTc0IF0gDS9D
IFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTEwOCAwIG9i
ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjk4IDAgUiAvVFQ0
IDMwMyAwIFIgL1RUNiAzMDYgMCBSIC9UVDEwIDIxMSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dT
MSAzMTEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoN
MTA5IDAgb2JqDTw8IC9MZW5ndGggNDUxMiA+PiANc3RyZWFtDQoiEy56sdYnogHRtOR2HAr52r53
HL2ngi8j39bzTXuWmr3WBbcaxTTWB3St2eivSUpNxMwRUz0qNWBJYnvOhNGKQEFhXqwpPQH1jr8J
imBWCs67FtK5BEV6P9Qy1mUdQr4jpzFh7qKignnK/GQUYX6eLI7qCm9A5JjqXrNGsQ80kDRW6jM/
NDSh8hEbH1Ottl4IEMW/GQI/W5kBkTgnuSdCSCKNOCoF8A/u0sUmxO2j6fg8GdYYJUlpr0DuHyP1
aJUOgrY33Sjmc3Lx+XviTCKjlKQ03m5oTRbeLOrSygrDor8IdH5H1I8sP9SPa/xhD/Jvgm/1eiOU
8w2ZgHvcgEubBL0h7+d7D2YZNwAZpA1B1CYiZlV7tS/oUYsj7mqbD3faVX7tMBQ2gyZaQ4udJYZO
3LptA/ZWyY/mxaHa5dOC34iP6WTb6NKSrVrd2gEwvt3E1BVHRnau4YOuFqNo5SN2zvV5cmDwkayx
u52LT+mCyabErMznXYJbo1f0dEKhQAFMOaAEIYgvp5ra31tLkzM2d+zlAWw/fR+/UWmatXfea/cW
fYQQ+jNPuczlw6Vr9ej5BqZ8+P9WrTz7t4bYSGW6UouSBfJWF4j3jBRyONiNui0Q6lvwZyLBiRaH
rp8jBxxCtTDy7bHlMiLO3Dm9zs9Ltk0MuK/1tMPQTa1ylA+Ewetf5qrwkC/LOsTMVZkRTt/Lug3m
tOm9l+d5n/OQIbVj4l+NwfuHwpvNepYIMJf8ejQMLrpFlZQ9G/2nJ56feP33y/VRMQRdbQfDalZ8
+NLS++wpfw/ecgpCJxyCfGR8/D08lAgRnF6vDCJ1OAAHYfbpXVoG+Wi2f2Jj6gSOlb10uW1XLlBW
zv/rBuXq7Z7e0lHIKyKZaZohoSFgc5Hg6bJzWt2n5IIuXJyBLPbjO9xZERWnQcZfXd87sQ5vn5LL
xQZbAgpjeG/WXzEsXYer8Y+MiUlCpFXeh3LTYBWE+mdxhL2E6JnApXhJcQxp58/MguryPVqQRnnj
H/sIMOth69zp79yGwSGX3jzBykUMKfi8Z9r7984Qqn2D7o0mSApW3qfG5aObkAueZgHuM+HNNdEZ
8NbAgviy5HLXiOOyrnZB83JNCsCOuGQotnFxxtRMgz7XRzMc+aX/5Ju42UhBF/Zl9Gchfy2S1yaX
1IzqyR4yn/EgEwdPYy2rF0TDL4qE0BUp/tt09K6prSadXyoFNG/AB71+CwuhNlIitXAR0ji9NSMz
0qf4CebwlXpvMANWZsK1XPrZS2Uqdz2sA1SoaMSnevPfaN9RLKRCwCy4Ps+jQN+Eg/QUR0sLYd0B
b9ML1ickkG16kpeRfYh0WLN7jpyBGNVU+RJhg106TO7sQSNi50EmfJsW/ZOzMswmnCcW4gMKOC3F
qyzZl68WDbggVoTUedy2wcXyfLtBQPC4/xq3UI0/ocU5DVned6ttp94xWzc1qFyZYrNDYPn2VXAX
/iQjHhsb4viFVtz2qQUfHEk3ZrzU+wu7/BMowu0mL6R9VLq9n5ahAvbUocMINQxE7AFtroSk6+PU
z752WThFdn86WytwJDpI2oAqkYmshJKYF/4E7sHkTMwLxT7KeIsRsqQNxCJ8JXBH6bd93Iwo2pZZ
Kb7Ktjg+Qvot1LD2vcufM62cMvTxXfuTZ9s7c+OaNYxUXGfvu0QCZnXw7hfUTPzYagA3fEhGyGYW
4VpCm7hhegteSGuK/u0eQxCASAWghHeaotFmf1iRLyARd4ivX08XWIIbYOqz72XhwVa79JGl6Neg
1IV5j1BHMzRnP9CifreVOiyoUNvGlRvW2ac0YrRS80aWrfne2rC+1G3gs44nyg/7kKcgx9uT//BW
8HTWw2dKBOLrEzo4T+ZMcRxPsfPMzt05pgekoFo6eTxoGDGlWr888psN8t7YpTM38N3Ho3wBhswX
5Ue/x5W2/regQS2yuMPwcPwAz+FzUqTirDAqMd6wjdYCPgVL/Uinempp3tsrxVE07dSlNWgRPQGw
7WcQH7OBj/b635G/B77/D3d/msoCAIHRdOvArtWo70Rvq6LG7bSW3qSe9todHu+KyKZ9JQBkG7Uy
5QXwO1ax1quTqQtS+nqBHCPX+uSi8JZBQLuSNo8nEj2RRJjhH8ime0UK7uwUXGxekg+WFPP6AFMM
/bLyb4wAA4Yw1aTkDy1j5j3rL4KTwPkiJ+V5rzKafh/JbAZfwc3/dcz7H4IubgpZR3GCTe1ifFwG
bBLywrUyfm83JH8ifyFP6Bdn057wlddE9so8oh10uKdROfi3O0T6tHksYP11miWR6pY8iaMq0tif
0uPtQlyqUYFV5jLZNAwky5/4VKsqaXzub8vpBWyq9BUsQoJ89/LIFA7LiZxpbMHDO5xhV4NGaEJD
Z8vJ6snB+NPG6Ci+Yu/xV2uJJtotOgSbV8/3T1rFLkYexZEHPvQ4KvT4CsYhgxo/ehJ28hLoe3qi
tl5r0cv9SBMyHh49ucK9YVt+sR56oxfc6cPvMkQ3HKby+KiE9MTp69JKhVYvjpp31bx+PyZV52JB
NAS7OBIavNjx8xgebErGDO+LX5YjCCj2hQlK8HeIdJwII1rh4vNinEATScPtb2kKLsTUG9cgpIi8
SKIc8oeH4yaTyjXxCKof8fZIY1mJ3Zw8vwbAf1zODZWmwnqIapPbj18MJdRNFo65UyAZ0hxf5c+b
s+z6K/AxazJ5nhwaERliVZulu0wnIjZjpksRurQK3sx6o3UdMCVH1fW3T0Slf+vuM7aadcg3pDKu
RdOuGaY3Hk2/wVVHD5E2iAvQypt9hT0/u6mHMkzi2dzEnIZ56bh5NF8EdxBRP9nUUD2OT1IWSlZc
EQrY6mJVQCYPskre6C/C0RGTRLHfHgXXvSdHVfD83OhjrEh199oOjB+60nlT67RdSYLHr70z1MaP
t0vCpRdbHqOqK2xpmarYQTreLJxUzYo8Pq1FBb36w4u6dG+sQYySP/bWTE5hPzPxvwNqhazNJuDo
kqB+tR90T+qjfpBb/RW4HrrKq9v15IQ8gq6sWyDyekXXM4t1YWxIsrJUy6YMbH7lR2fwFP304jXq
+f1OGksPGncUoqbkRAnCu8DW0jZDdRZRBUBZsWkRasJ96IP0VAFMlha3ohKSbwlE+7OL5zo6yjoF
bzOz1X4OnL/OWBGJLDji6cRTapvazoyBOdcl4ev8k88f2u82wSEVINNpUsIefLf9MBEKKvtNLZz3
icY0o432nQl2I17YRAmJ/aqnp9SpwCTjZgIgWyvSOvaFLoqPzrgj1udTmLeRPhppwkPVHZmCXMBh
z/syeUqg7Q1CuQ2KGTsG3ZPIw1eVtpi56VwDbuHGQwpJ1n392gekGxiwGO1ALSsEiyDzHkFr6TO3
xM5/Jjf12ikcP9HCSivA7qZEvpPJ9xoEhU/Dv2/R0iNspVsqfIQD5JoCLfS8lSixFxILmxaUIQmh
a73lSQWQ2KauCRV4RLEn9AllJy5zfe2QoCarHRFGTsMxxt9eAl9Vy76XiPCrWDhoUZKizL0fEn94
PtOpzJzBr/c1WTHHWJoynmNtotdmWgkK78a2squv0rxXLaxBi+wk1wBLovCbHQutbt4Upht3bZ9O
bZvh93aSXAl8/OHlQmqRsyrBefC9AT6l3JUOuub0uCXGPSMOKEexcMS3Ey2f4pebWrBYZNzMjdCy
oa9Hrhutl8lQ40JQyrRQBtbyyxVRISGbo4UEoiBd+XQrRBso+6TxpVxi2NQz5p6IfUQ5Mm7wlLGx
D1nEvi/sbFPBlIy07hFNP7lufz4f6cHDEsVDdQu1i3aCFmkbN1S4N4i2OzRg3ld9Z7kNeNuu7dVy
10MUuaMr5OcnbTxOgglNSfjT3HfBAQztotNdjg2lh3UdBdBQnQK37Ke2nffi8Cxo6h6JZUNEkY2l
iikU3otODjm9UezADGF7qzzOoacRJwdBsu6bvnAOHyeuMvdwwyDkXyn+5qHdbLODU7OmTjLVJ4Ta
ZDIyWisq6u8RY0BjZR2kqRAfx2t76/4mnI4hT8woL7nDOaVDsw62QXXKkKKGmxjfRnavHNGxBIUt
dPwvLl+pKSFmYEsKocZNJKaYSj/jmrxqTOeLmdeR+uUQtxcAmXzr5Lgc5TAwaZ8SVJskS7MNb4X4
FsAsVre5uaGgYG2UnAGzBQjOu5snVa0EZ8wQoEVsSPBEZuomF6ZAA/2vqVCaEKUwkyBfMgRVhL5r
sOoomDj7c3vx2hYUGGF0CpZMzXRdrmCpT2lPyalm+4SRQuXF/OHxq7eX6vGrlStc5Y2P7Fpmz11m
bNz8AcUiHTPx9lO+IXNpWTIe7FZpjppylCz3k+YSLHLuvYwlqu4RjmmdfG16vx5VpuYEOu9jNoK2
ZJ5SND0+VTeIpoPVe157fwA5mBxDxseY1hb/pVR5R1sPcLl7xRsLAdUS3LrSyKYIuIGHMq8eeYtM
JnVEsfu5waWW9omAz/uFrt9VpIG9BM2REgN/uSC9349wZIkvY+30pJKhnuuLoIGbw6NYre+8PebA
2MowAQJx3p5ERa9PBLFZKaoE2o+AqNWBwzOADjyBNPaOztVXsJORv58T2AmVORcQAqbF2BMRFown
bEpDJliKYMKgj13OknrUbBbNlmj+W4UFR4SQ02A32IcRRYGpfuQUXz2yRyoU+wv0IDfwnDok1hJl
vDrX/L6fDWiMt22C4ZHVUYBebxh1iYo/Z72NMGGF/y2yJqZbwDdYab450WIoA47xkIlxKDF6OdKJ
FzEENXUm7mFVsTFh5RCXrTef0Gu60igJREoq5Y9/EMLbDfKuHmWhZBwzFPjhVL2bA8w+fZrZ4ptt
8Fvw/Wyp0g6KGlWs5bzmfPOeT90hQGtfjeTkaduFZuDgv/ea2df9iyPYnRN1n+DEUqpUj4FARwut
4Fq9k6OOHZrPZPyDH1ys2xsnGYgChQBWzTbBSJcwX+8obIfI0YCf0rYlzlP0soz1Oi9GeS0xIHgH
h+OE1DMkMpjpU+KZhNkStjwsATZL9GrO1UB5OOT/E6OzUN5WdAc8IgL3s+xLCjZzyu4T4Hs1a/Zx
x4UXP0SO9DohkDR0YTmA4ezEnFDHARO0tWOIqrq9aEHR8xk10LUdOwCbJ1J/F8OsBDSqbl9JHnPi
esrW5h9JS2Pi29Th35fWI7YzMB4g0pw+9/V4UEwGdUP2/XQZ/OThIkOXI+Olts3hsNrhPGehCaEb
n/yYaKAg1IDtpYld5WFN/XN/Xw0+YnSUBykMN6wFLmlaX6NNzHXhbowst8YqZfWiFwJgaGo7hjsd
nUyd5p/CKj7XShnH5khruNNDH6wKFBxQhB+NQ1RVyfXC69tdoO9fVFIja8MZ6LLKk+Ow0Uk0ZDzd
bC6h0Fl1YcCDodBEVtMcWVKwuQPGEj+1ek8pOlSK/upNnfUHvIqL07zuwhzRAWb1zKyNzc5oXHLv
Aj2FCzdcAuOzR36CKp9hLt7TEY6k8lDGLMDWPdUGxQKbxVMumdQanlNSKcBhJq6VN3OXVKEKr1ky
6PGLwc8uItdu1Lop5rpozD9//5HY8nDrqiJbQ8TFC+KGtFQdO1cms+ZuUasKwo6dpEpka7t/TIQX
BzhkNQmBE+xkAPY6zDM78riWfu5QkQseBjpGeE8SwEPVEOhnPMfSDl9rpoNTk3PIlaHt1toqZIG6
WtJa1npaQ4J3gic/qV3MwPOVsf5AX8s9HFspW5nEhGXxLNFodF8S41uVQaYYC440wDzZZ6BqziRF
EAP6OwUmBXCSYbWgx6lVbhlnEOyieqtKRr7iQWh+9QATi1+fK0nhNB6PaoTGfdwGHDL61UG8/M4K
9uCjRLuP/lJfyN/PZVs/j3XccQOp/UB7rMev8s8ycFidPdyyWe0obea6Y1rvXgwnfeVL81yvVSCa
/+cAVof1IOJK+W7qwblkmaTbfBDcIo7jwgdyeK0Cbq61TnOeq8FLAs1jmAHBEn8K9dlYUl49QCF4
VFPQp+XKapnAIiIDK/MvZXB8LMffhl97V64Fxs4pYN3hEePVDoLMJ9AnDJdEMrINZW5kc3RyZWFt
DWVuZG9iag0xMTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4OCAwIFIgDS9SZXNv
dXJjZXMgMTExIDAgUiANL0NvbnRlbnRzIDExMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzky
IF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExMSAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMiAyMTAgMCBSIC9G
MyAyMTIgMCBSIC9GNSAyMTMgMCBSIC9GNyAyMTQgMCBSIC9GMTAgMjE1IDAgUiAvVFQyIDI5OCAw
IFIgDS9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIgL1RUOCAzMDggMCBSID4+IA0vRXh0R1N0YXRl
IDw8IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiAN
ZW5kb2JqDTExMiAwIG9iag08PCAvTGVuZ3RoIDEyMjYzID4+IA1zdHJlYW0NCuY2PNKUkZQ7Sr5/
Ni/VtCr2nydyaplhPZZcHfYFkysivpnvLgWLZ0E6cmAvBbK1IFtnnT/0GZlg+ojDxHE/YyGteNxV
ZcI/VPrPKUbdhDUUhKkFU1AsJjNBU+9M/iZLI6K17DnzRtRyCy1jI1kXk8QbmlL4Nu2+gVc25OAe
nLKcbekXOzZ26yeNlBfHZ/Uz2SKaiiWrZ+UE3MmP11hkduLqW2oh2pZglGCmesabQuq8Mhc0H4cZ
w5Das/NOCAaq1M1V/d4k7sOpX6rezPEOUcblZgb/X+6p48xqZu36q3XzpNtVkaveDkrKVbSoExbc
GUdpuzVseXGjkqLyOdDkcNcXJ4vqSlgX/MwzTe/zMjBs8hjtBxkdWlWVv3R0Ma/i/fmna+DjSVJJ
yr+p+8qg4LuYqJp398s48D09pZxsHnXuf9RoY8dtB3moYvORmaShd3IU4z0G0XifVXk3sXTM1Oyp
Qi52hLJbun+3otqkiDWoQLDZxpTMQQnRytoE7wzgv4DC0Q4zK/U/Xhnio0x9TUBGAz+hjJd0zaWV
onvTqjX1xIWx+s9Yb7DI3KK9zk1oM+3l5foIXB/99/r73HxibuRhz+xymdqGTsP27NCDswH7do22
1Z/fFJ8RE6cl9LpEJOp+CtEApKIDkuiDPhS4tAhuFtX4MMYyUEDjKxCGECu/i25OgM9W7V/ufgDG
/ZcE5wnKGXJus3epBv/mMdi26BRoxJb5cZNrgBDfAGqbr829OWEUdT1wyT9IkGKYB2JMSCOMG2EU
nNo0y8Fyw1DC+geyHul79YDoSmBKscC+NA9mcHlTD6OhmnEd2Ba0MsBbjJmfRDC9d2FTA2zQ+x+Q
5ThjxvE1ZtcVGbknw/0Sej/m5Ut/0vCWABWXumKzyYfRaoKvA1cQrfvyI1bmo36Ykp93dX9sY0gZ
dkZ6yWBa5aOaC9tfZ2JGZzEUmUL1BUJ47+B8GZ6bvMkDOENmSydGQQHRZPCCn5uiSsjOkzKEdE8I
rhmSq3JO1gbKqus3NzYNvtDEHAaZw5c8znh5o7xMX/nqHS+Y0G3p5Dyj2niMjrUW818DlsO/INtR
Pf68kg0QgmBzKEfZKdp6qFhPQQ+2cWpDyhOPFaUsnKJ1Jd33iBnrg9qSDiocJjWGQlgTRVi3mMoM
KP9PnmTlUqbDGFjv4XWTTQCikrm3nyFPweqIS5Xtt4IKap7VZILtbMqTo8y/w/K6w7NZWaagRset
ym7gKj18nqPMZHNzWc6vc+9rW3vi0Yvh5MfchZIIcnw4mMO/xv0v3rdHya79htPW2CwZ0vhYcC/U
SPApI8K5P1D80OAGEs3yCmMG5fxrmt6oOJzMyeHIl8voMmFPejV/RgfkEKZU5HKbv2QxIzQ6uX+c
W2AwIoeHprfHn8YoyK8zNzC5tPYDWQODoJSA2Dfq74jGQr8jBQr8I8wtu5y4Tq6WxuGiCtZv2yzI
s5KZqGZrx3ckWy5+GHR4/6nKuVgC0B8rSHkboMSaoKS6oWXniJZjhvJ7Znv/DdwHBdzG6KJYEsz1
VsmgMSPm56QutLhFL1fy1DBFC2T6Phut5dmO4S1UfVHMaSYfNCoSPdN0+a862Zib0iqpZs+z2mRR
jj8EfPIH+/zpaTPMXE07pNO+ew0whu5z4RjRk3Kt9yX6DYG2moj6QanZ787NtuqDo81sXN10Y+FE
G/mVLx3KeVDGWkyxUo9y9n0aqJyUaf7McwZVtqgC58At+XG4NsbWsMmK+1guETEIQfR22O+v3Nqh
zjvAYGcR4FllGNNPP0f9lJ49WUHPv2v158vGx6yxAkyrA1ZMgjwP/JPV89iPIzeS1qp/h3+Lzdmy
6mnnb78RYwZ36x8hJK+xyAP2MKZ1FYNYrEsVX3acb6d0CMKr/3o4MnK1+sYbinTXSPRtbKjLFvbi
7BpmigC19hWupq6IHY4DehJzVhDHYR1vGRWU3YNNc3+HeIc2Xc5aY2D/xtCZMR64vpUk93tzBZNS
m4CKz52LXCRnhB9KR1UWhkxgYHmtL3lI0Zr22y9cbahzdETUF2W26Kpmnr+76mwnldvGvVh2nBsr
qmAb5MJjewbhD9fjvwb7pC0h0jttROS/QxMWQQF95jqC8WXr3iA3udfHgvki9qSJhcyl6Dg9JtoM
YKGFiG+wmbG9nIGQdOxkIaX0YCjTDMtBQDgB7BwpNPJDRQgtExgVGp8LS421C9TPwkqNuetrpzNO
5i7ZoIuzKt4Z4/TIgcstRVZnLFY3de+tL9JIrrS5amP8pAb6fJgrb/wIrWAr/13X8MYMsSc+p2lX
HiQ5J/Q5ILeVCW7t+zQgFcBKqwSUzRhtX8Hd55xa/V9SCyAUDQRC5xWmSbycJJCrePwo3qqTjMNe
IOCPkrn7XH1RuBvQmz6Qqn7Qsa0bNqT1Vd+fGpRAy4oz4dIDqR5cSbTjAYfGtd3PGM/JiKzwlhOH
p68t5wXod2cvAyKkGTlG78hh1PZPn5oO+LgOceqpr8plyzSgPuhi0y+79wiXf4ULP1caQPM4L+0j
fm9z5ZKVAyplu0fJYdyqFwYzS1joq1piKFsUsAxLIO1yAhuSjOKXkPmA+DvV2kMDTpTd9MFU/5P0
rDZwall8TWwJXn/vyOhVrRXlFujnBqN8haSyU05xG5YuMCcX/GrVE9mjgGqT7ZEWu8UT9GwKF7pq
yId/ckDay8a44LvfC3u9WbCSj1ATyIyMuAQWBo5MDZMmG/Kav+i+z1ua0g3VEsK3QMwcJnehKubd
dpWDcFGbyyZ29t2/3ssDaQ2durYNHbnu6OiJXMWrW6Yae3YJAqPDCXdFcAVhllAV3kPotAMVjxe/
ewHco6zW4JcfUgDDPHQ66K0vA2KRJKjsEZl9M44stZvrsPAE8/C3QHXNLyih/CfHOKs3bs/LoZUo
cuDVLMttUsHgOJT+HREmM2m91jUiS/Xd4T6vPGuNgc23DGktQA/A8IcWNvvKy2F7HPuu3bmleW5F
kfXEU3OKdUmRydpou3Gehy6kVniGa86POx3DKcaEFG0Xn51QAv+sKPzeJU3g9AHweodj3dwdYsAx
b/8zkBQxqjnufAbzshpnZ3w/hoW00ulRw5+fvsSsxFVztF6YiAac2rW0QbclbQbcTyLgaqPdIBd2
LpGmrhCGHyVxoKIaLbjDxf2H/qorz7Oz9QAm1d/etjvxCjFeSdL+xJnJ8ktTVUA7ibdzQ2dcIuYT
1s4y5e8P09Gywb5d10WD7WC96KozOTcXIcr5zvj+baTmUD5qOblPAa3Fb3BwtXRKNOEuuS7MH25B
Cq9r+Fe0uCFp0ZiR/2cNBjkYi/uiICKZ2OzAf14DviOprh9LwRBC+4yjlhXRW5bm13KuChB3oubR
+3997NqQaDkVt1DY1RgOMgxjOpg15D7GJ1fvAi131UoII9NE8Jjx8CC+pXz6inWME2ZxTNTLNk0t
4ld9Y5E0RJw7ZXywI6FYlSCOUlmjFJEe3Ay2L0Zby5hExzB8+2YbbklA0a1cDDC5FT+c4jztkoey
T7fiRfqz89b6Fy6hKbP30zO9IG0WhR3C3i+ZYutD7XTBysb7Qsf1c2SwjNHj03LzBuhyceL6nHHn
p+jgWXxTMxM1TKt2mhsPrEUld548hAM4uBTyz4PNCpCKyUKlwA+D+3Wpyhjd44PzPQmUoXG/8FCh
M0jmCDbYHsKAtZWFUB1jE+85JpksWHF5SE7ITBc5wdf5ek5vdqTdCEM8dc6mflsjqaB+Nq+cRmi6
pHMprBQIXDWkHCoA8InCl09eBFQtF/500Yf3YFny2RHJPHEVtbPjXvii49hqlYxkk0pbFDrCjuVH
HdOH5MD9w3Ti0wk1TqNbUmPfdftKN+RK5Atompqv/60CBwHOXMUnlhAhi5LLjUmVmv6Pfsw7fWq1
7pjcUMni9BQGGWsOZhOxvVyeBNfQtDVG2ccnm6T9f7APLM8W0XnErUomEdVl+rpIE4yA5FJA9rtW
w9g+yJWtiNBMxB56mCF+ckpzSPma8jKvyLVEx1EVFhFB0syt7Jxg3RvEqm2bitCSvzjY3X4SyLJM
Vbg2jpz9nT23FEQQRGcl8RRZQ/E47jWh2Li/27CY0qlXFw0jOpbi3ikvAbAp/N6xfLKo4WK/XQjK
41ng/FygRYrEGLYuHpxAwcSb4z8M/gB1L8ss8dJloKORhmjoUmM2KcQOTY+fF3xZatSqSZZBS+yR
otyZWD1gcHZYEfSd+M15HBj7W3CtakUKqDNqM8LNSnWMqZhuy3dbtVZIMA58/dBefwNk12dyXTlW
PKEGfcTlR+Vlicm7kWEoVLG3kDLpLLoZnWDBF848mVsnnhy2yNTUpHBiRJLzbLB4YevGihiYZYKJ
PMabIPi0zovGrkAjjrhjJeaDDVbf4a0zKLj78n6a6AMIc673fROMPWHIyYc/valBEkIeDpMQrTT+
Q6syWzjBdI+yoNw1SV/se+tiJgMH90gY20e7MIzg89PbCavU/8obfCv8TA10OGo9yXLIje1emfsm
k23BPJz9t1U4MLGbu6pQ9VskfMqcCyDOLMhOALnFd/zCGzwAr5RHUZQQMrdxuAGQ1bWLPTXHLoZV
dfZAO0C1kto6Pzn12Wef/dcrS+qwZ9nBRArAkm1Wpx6GhHplb1hUHe/L6dtHE6seefj3rW2m/K90
gaNTiVpQrP1GRa7m4UMa0XoFQhMtLuz4Le57cYuxdxVuywP30lBbIVRW4L5p+oArsV7kSdbgNdfv
chXA1lt9+h6qug09Ra+IulG4lX/pUmgLVyAnsdtoxvohF3RaGYucztEy1K5iBZUoQhv4rWILG+ZB
V4JQUGYHLWZGMRpaMcYmEZjzhc0nHYHQHvceAYJx9Ig6xNYuXtDMb9EEfk4BfaDTbY75o150vMJg
XmmJdN1kADNnYv2edLvzY/ho3BmcIAadS47BQ710IXaourbV/W70DDDwo38QTGCrwQcDxobUR9n+
syAA6r4nvJIelkTB5Twd4AfQ1rIpUYwD+bEbzaBAdrb7Ot4Xw9eKUz2DoYA3rwrpZvJBXxEjfyAm
yxEZPsPKSzaho7vNS9j6SbcpgOljoxWeu/kv1ZAwIuI1cZyXTpB1MKsoc+Bf9WyrnqFsycirMcy0
v2X7ERO/nIY8j+gChS7EMvKKPaiMGoowVheRB9NB9B9+pm6udDof9wehPiYJ1zVfaKDDlDFlAMv4
bqjeT5gi02EjsRRjLeE19bKfGHPG9uZsKzH6arz4IIcnaZfXDg1g+22TmTNVkO72TU27422FAVfE
aM+XusvIYuTWVoHhN0V5hNR+UU4m7K+3F0PyAU0zIElgO0bHz/s5bVX2Ln8cXw+AfpLY1RUIGm6C
4ZFKCF+x4dcC3g43EqcsXuO5FwblCNpw1rRNWosTwK9Jluc5ufTuktaFiC+FCqyg5lv628ANMfVu
EeBRqGfbRnVyFl4v+7jNVS6A7Gp5LBnvdbJihiirWMZ3zY8KUuTNLR+nsBj2fjwCyEivzCgmKig8
Bm1hZB3FZhbEYAgjjOr9mgXU+2Z6S2jB42JiFiMWZLItG8L1s672HVKxH8moUf92+N3KLuGOmjkv
P5ugIpSwf8d8HC2cH9qejTTF0/QuWOuHXXRSR7516vXOtiAWw+vH7L0t+hEKQWZqkrD3D2VdHl4T
dI6JbuoFmi1j5IyxX1+69rwRYj4FwlyDrJ5qOt8fVxgx7iOwQFpllNKInz+MS687aXQDE1NW/2l2
UqVtU2a+m00Xgd1meKE88iBMM3fOYRfJt4A8JvWeTSaEyYdRAMWJR4QF1wDImqdfNIwp0eC9YOct
JoaJXmD2OZAgfW3mqAyusanlHm7PtuvgE4IawJ145H7fEwCiDy25dkMtKpjpEDbdEAHdWB/fTLN+
j1lGMlx0wfQc92+0iirH4r3arR4BV/7xvpXGbXSD5eUPFUvA4QN8GifVaDHEPRYSdF58pZ50mqgo
eChfRNalRhSG6j7PIoApJ2RrYZG3fUZ+ZNKtyJbGC7YlA1WCnLjSEJ2bp+KCn6tNnGo5kjV84fFQ
V5b2PoxJoi9k9e8KqxfzbvGWzVbRakuZrkohHf6QOwtzS7XA1bHEay+9szl2Lfvi8IZ8WstvIk0A
+kV6nrzUCoY5zxs3WDEa/312Rmx2xE/WJ8CPOLz2xXBQf2Ym4F0MQrfmTTxsqJgxKGT1bJje0OBp
0SF1weDKMQWhrnRfwIPA8cjc8n705wpj2R0bxOjClHheDfzv1zozEkTC9szInwAUTbPqEYZoL75G
NxNMlwdYNBerpw//iJ6trQx3qB3VirYgaFykbF+WFvpQG9PDDo0KijTtR4ISfttHhiPpDOP5pUSS
poSSQ3FwlJ3kCF/yazYCCfk0R2uZhpCwM5lg7mIwIZkSQtwnpNuNIg+GkcYKKGvryOoxPXBx64U0
vqSU0bWcgNvrZP3rfJCBpl+3XWZN2/MCTc4tlUH1Jpu36brEEhfi49QSX086uR+XTpyAZ15VlKhg
fUKLYOHc2usz2vJ2Hv6Jj6T6D/+75RMuuXGMUcWCr4V+2R1JIyr06rEWZx6RCW5nhl0CmMGAtr4n
uniTKOVrjkxHkhVxyjDba9gcpNrcvEBnXtjxkkGMqalIaWZBm4CKxtbB85fBI21iPMAVSQ/oSQ4k
xe+xj/BVxNPNUs04LKHvXOcT30uLfAL6n168AbQ6fO5XpjHBiJAYAjYpu2ypnC//z9YczryA2YuA
wuWX0SQgS+Jvemut0u9YRCxbwdqRGTAEj5s2xMJFti40gfQUD1roujeXyiUTLLpFfnydxs4cOkmw
3dJo53fbmkhepA/JfA+OF3KVe3NcA571DOk2XwJEF3i1CDF2Z3xzrvMogR21dR2hQPZ7bQO5Swx0
44RbdhLZY9oFu6yOXeHUQGF+bK4/KOF3jxBejENiiqkImBPEA21eMuWVbrvWosVduIDnb/wRez2f
PUeGXVBE3Ustf1yJKhdE/PtEuT9Q3TmUCdnevkdVqZIasGqj3JkhQ0lZnHE5uKqWL0dhuhQcCJC+
3hxbV2TqXWYrwyF/jVso9C0/Bs4MXA855jCyU2za8nrczyYpf/YRR9UONVSNrShKfHwJjXYx1kL4
B2MImPoq8gTamteDnNYt0nn/0tVi5Cq7TDWqSmjPigxjoNAhnN4Dv0ksW0aFIhhHYAVYViOVdt4/
g7bH/0WG0lhcWZBvuyf91PA+fxuqDbs53Jg9EnvBOO/z608cz8ZmfG9zhFbwie1aTdunCgZ1n+bo
6cMDm8FrXnmuEVXMMY9coQ+3KLUSGeshvmGOnO4kWK/+blKEJdHsQipkkRrWdQ4f4eggnLbIeb/D
tNsH+E+bKkJZcXaP0QUdvV8/3TAAETZGEyia2tAH4SXF8f6OFbbnwjyeeO4tbmHDXm8d5kS41J8F
GqboEz8u0i3J7Vwvl374MH/RQgDP+UqkBIKpdK8SoPVaCJ/2j3qdJjxdmKQNJObBGWJuJJHGA/4Q
EgXyzdQQZ8WF/uZQ4Wxo+hMQF8ThsnEtZvwz1dDMRslBkBhChEVNIr4VgUnGWAiiMFsUQOLh/wka
2/LS+pYfdIM5EcOxJlxiFfOR0f+QCtJmDTA5kFA7E66oSR74EtDXUpxP1t7MS6egBqTmcru5md0a
2691abZuUVSbkfxk1/gv7mGnik3nogqu0sn2j3l+ra8oabkpD9BBYMRwXwJKmCacOpaVf0UwlH6h
y6YbV98SixCwccvg6EK7WExa+xYVqyw2bGe5sSUi4L+W5yy7Wm+TYucnZCEaO1l0t78dAM1vR9e9
ewmwC4O9JJuaheJCQSktCF/DNPvQzxoIMtlPkKJ1l/hpWIX9Q5cuhm0f3wVdpLyK6+6nN0K93T6+
wj+qiEqoIi2JHEFg8LJmm78L3/bRK28neftcQwKwMtqdLnAioGNsvcrO3prMgE8fjkB/HH/ZgVzo
Qi78JZYpm3ncsWiCRGgYQQlAHohxyUw2hUSpE7l3Ja9ZM3N4SwhCvegeFPBzcL8V3SNmausvea8h
GA9x5ho4qhch45OJ6euGtC8v6smh0R9Tt4lKeIpPkrWWie9pmeillYCSP4qpYYsPEMOSxlgK54fW
2L2FmX+X0ZvSGHR5cMr5djK7jLd0tACsxQFHZc55IS67Ryy3P4yxdcD8gNeX9tRodMtTnMHMQLtw
0u2yQFlGS4yxsJbxBrdLyFdvKQjYg3kDbmqaP53BioPKO8wOYSJVC5ZyyStFJZGr6jO3pxsIXEkq
pceWQ6O62QB2HJ08FURqgJ2BB7QI4v/foz2iHcAeaq58wi+6XuHLCOpuQikAyCxRTgNC9LlSO5Pv
1LEC0w0rdjK3aqBY9Vhq8fDVnWHFb2XJn4uowOU8iA9q9ObQD0JNBReu6HaESwNuNtI8sIHhjL/f
yewkgVUQD5PyPe/u4fyRyjGtMO3G5b2//RRGvrq0hBJzICIJeLbX8HiwXF7KVAJeiU8rfqplXvtl
16LbZUxrxc5k04LEvLVpvx7V2jhYkj4pBcXazCsNPHf8+nXzdZK0CC7CbUhEodPjfEjN+2SzwGvu
ySrNAyT5FYL/7CdiNWFbjvKc++2NdkxK5q4Zn+u4meKRS8dlCXT/LFMC32cWRdopww4LRG+gcmdD
ogoKm6WQ8z7fvzQzATzU9GWWz3yWZXLEKzLVBs3OiBpnSSmGfAnRy90jhZV0AIvj+5zYEEAhoVV2
pXy2W1BvLBcIDRyIId0dNteuf8jcIh8zX0bKKm/go/bmE7QREg4nWYDwy2vdZTb1bxuWmylpCUTj
rwgRkc2TKiwNifnDEAZOH2bHl1G5aXh+yestqnHqSIcRid/+vh63LSOvW2Q/xH2AzRhf1mDPba56
oPnzqfa6S7AtT/5pZOvvOUF3bg0RWaeq1/vOd+hglz+72ceYziEveZSoEiLHKfqm6wC0hrNdyuSh
J5eOxx7ozR8WBtdGq/SxGnOstrmZcoh3nDIWXWSzyLIH+A9dGPYDRl6l0YzrbcardizmOlGIMZTc
XW11k29yDXn66gOa6VNe2DKIMXNpa+Fndrqlhun0TSd81slQt0BxmTPwlYeODkKh+6vy6ee1Z1um
+0LCoB/ltr/YxoyVTQUZxYNXcGfAqj9D7H5TaqY/BjBYOZEfOsuN3zIbVBX4SrhIAE7zaFol1tco
coV0ZMhC4fJqw5FSqDDiJg9r2M2vJ3m6nlWMTg96cNlDlQD8uQB0vV3KYXgf6zSQIMYKGux90cnR
W7hkZRJ7d4jmx5YcSZjUR6NHiRkIXGwGifz6Fe6jGUO8WtzWvXqkzS7oonPVX2a8YYfwY4h/ox5y
h/2lc18t7ngJ6mhaiP8ZAxMGb5HyUrKdAXSyfyE5HWPnnxejjExqMslvKyOXNm+O3f0SlTQnbxG6
amoOmLPEWz6UebM0UIWlLsLJrS298H2Nz1sWl0AFCvqkWNERP72Ba5k9nsEXNFhtQqbhHjsmmzBB
LvqZfr62Ikjeu9kHUc66PQtlFjS9Kod4LSKA5l6VZthuWze9thqOPuJezhmPjOkYwVfgS3LpLZ2G
1V/XH1N6/34bjckij7Ap6ibdOhaCqggknuP13jb6fs6lO14V7fvvMRuGV/mNo4owLtO+S8+L36BB
5QUPqEMiIunVuQxhuaMfW3BH0Cz0ffjZcraGYDEQ7MCLR/Mrdww+cj+zTZLvI9YnLI79ODPLa6oO
OiOqEwrrJVQqxuhEECcSiCUEsUwWFx44UJsCZYO9PBhDt/tkOCDINEMIQ8Z2YFTYq4nAlJjxiAtx
AYIcdkA/JOL/ufcurpZcEDDZ1K004EYava5jpjnabrC/7sVNQWYKe0L1ji1qnep3+lnVWh8A1whZ
Gw5TbR3IHgg4Mol6MwSOcIekZITEG6Jhol20xTMCy7jCxezCaKIZLXF/DrBUu5aPqw8gIgMQTHtt
vKb2XM6UDfsHWZjwSdcqTkaETUR+9zFtjQpbx61zXdw8bjd3IWryt2j4FEfhB9Zx5SKTB7DrwN+G
KoGo7frJ3/7jjZEOdWbR/aJK5xaO17Aj7nAukgUs/uQ5qk+TTynMqItJi5tNUK0cqyKfld1HxQju
Rce9kslQSmgELxuivD1XI95i/YWlKn6OwP3SEM5cW1y/1kyNq0xMY2wD65ovBGUG4zPgfDvUKm3A
jRggD5CqkC62cEhXnlzb8bFzYbZuQqt3C7i7JeY8A9cmuusEKij6OqNorn4qHu9oqRw96gXV4sEH
63LaKZVpiCCuNdqJexa9Anx8z2AKeOVs3lwBnAL1h8Bbnhfs4hpDb8qXdVbuCvF9jSN9WK0i0A6I
kgp3nMyD4y0bu+gN4gUN2lsrhEJGmGEChhjrZoKRqTqREq6TocH12hA7tVEYg6o3gantGj9zek2t
ipmsEltWyMNBJ/FMzqrQgq/mbcHA8UG6JYgLBN/vIqiou22kDeBABEzkpoCCpn0kGacQ05q0vkpl
VZ7augcVluyjH1vOuCKFvqDJqeT5XoiIDLKaCd8CxYU+JheXTh+sJaOcgFZ44JWOC1uKKgSQU3/c
7/59EYsyY2eaBx83fKtiazO3JaSss3pikFzWAnZDIX4SZZMi4j0m2yqaztAvqsk8nsYjB14vqn3L
Rmhteh0M5GfAoSAjJTd5WvMYMHVOGdyvfvMChVaYUKQOYQBwUZOz/I3FFOQpOay/SsGqgkqpUYtW
vGwuRbvKzAa0ZXu/GMcI5AC5VTyVTeGgGFt2kfgndMZ1mz5iN72Fno+4oKgNhXnw7zXN1wZ3shRl
25nfDWV1EnY7PAlHOXaF50FzR4tqIjG3FuCUrBU7K6/PCR8nCPC6xipiFREqLzdVyxPbMCxVVcMK
rdd5BOisVmofs3mXiD3XDbYvPhQSn2OcEsDPqu7t/2OYB4gJAK68oGlC92q9ibiK1HuzVtiq5BkS
1at86xvNeNWi1CLsyPOwo/2AGW6/oHUy4vJFPRWHRJatYjA7RvIuxnuwAs2uskDK/eg1viMagxSS
AdcZB35/tySFnA7/SdAJEKoTg+S1pfHkQ3y+7YazncJgvkxgp2RjDTDLWOfr2BYYxSb+dWO1Eylz
flCXZJWKATItwln3EL1eL/LwYeuAiUO5zJFkAso5BbXjv4Q3vKRxgrTxlcSknIdlu/WkVWtqz8rM
ibrBvB/0HciIkHZwdUzF5hcm8oRnK62x6zBzkDE8RdSEPU/6jY6nWFgXue+MWtp+HhmgadVvBYTn
kP+tvGnjTtd7x/bpbfoiov2y5fqxUqhxizCrEnTv6CqOnGBszjz6WF6hZHzYhInYcPDzib35u+SW
84Tuw5AWxG86yWUVplHCYE1m662YkuzhAgonQTRYe75XBB4v4+UwGcnnWG018kIoQQU6FVLSNDdh
PmlE7ZRz8ozUWPzcfyLfBlh23Pr9NZmkNPvtr7rn1vruwn/RHpmuCx3XvlfvPrPdZmrJvXWlE6vN
nSNdRxbJnuxaNmJr2RL4qk2Q9R1VXILbh2/tpUByr6S+sP08WE1gOSUksgLpFpkPMMrnhInHQvYA
PQn1/OJmeQBJos+epxfFMPLmb7TP/vZjqIirpRc9ZrHYZS0+xqw2Er7o2XTlcNQEY3cr7fkEBitJ
7yOlkU1PM9PDCHpvcubeNW0FN2+i5+ro+tuoSgNNywsl+kik9aSvFrDGH4bsVJBHAdfITQW7mgh9
gmZifZ5OO3+3Hx61rm3WopWaAOIU8B/pkARJ5M4bU7J1T9KoJ61ZW2NLt01RJntschvGDFyBwbTl
H8P/3QohaQVIBvpTbTOcYwyP7ynX5PLLVICQsvsF261N39159NtmjHZfpKLnbC3eX6OfeVfTSD7Y
J9HMPqIKilTHdQUDBmTFrQ+uaGZlZ8kdNommvyDUm+V2Ncnw+5VO8GsgznlsjE5xuhE2ya1J2fv7
6ZoyUQ5d/gvqiFhklWHpgYx3Va4jBoGNxJr5EIoX/Sb24pQRi/HGyuUb5b0z4pNRPpU1/8jeoEZy
1omN4Q8OkzYnZd5It+SwA6iE9erofSq2keCTSQPnBICWyq+IMr3JHcsGH3Cl8hU88rE50kpKieUK
O8Ir8oRbnYB16oNVPEis4k5mU/CawLyvDAB98URfg1LPgMYcqTWZ1bJRJ04qMvBelMzcBSt+Pa84
v6OHK+N5AvFr4S+R7JFKZqCSFxkhzShvU9P7H+cVbiOyaIEi7UBFZHrC11r2RG4s2j1XpXuscH6a
5Db5syHjJnNYai9XYnECX65anQczerswUtLljtBCUUUyTgvCDpW9NyIriYpifrOI6oxNUCJHymP4
JHiCk4szOjLXm+BqMREs/aTx2GFAggS0d6h799knwNWfj0D6jQjfb49A2hoa3YteRMESkGmflPbv
nP8dZRfQ41JxwicEdMLFShfOxeovmPaU3PlliJIISLJEVqKh8/34SG18Pp1RTi6gGSehAhzxVVoY
Rw3ZcVwUbn8bXpxngMdsZ1FfJMNFgPVLUr3x2Uv6OxV0a4O0+kmiQp5+ZTtHqtHxYSVNvGszdRV2
VLLFgYI1ak9aE+SoR+cghYdpLrHbxS5/KPyZPTS+57wYZtKngluW3a0Q6Ss+YOh+9bmB9rfSLjTQ
Ea522uFZuMBrRUGX0x5ZmOZ2hYgtGDR8Eu55vnk3UbdiL7hluVNqiFxZTxS5YNPVOyL+yjlHcI88
x1i0eg+4n0Q9s5ZHwLq5cUAP945SQMv9iGW51mGbYa0ll75gT9sSKO5BvU2MXmaFoTD5YlkSB/nv
b45kLd/feCozMB2bUf/+tAWzOMsrERXc7nSXFYyNb2bSvtum9DmMCUoS8WUPis+VJ8BFwyOl2uf5
6rktZzVCIfN5wkDTG+eFA8xOZd30HlM3nigSUFXZhf+alHQ8CK0DYnYFXD+KUIaXyPbLUM9QqTTR
evtTebHGa5ZqqcaEFWIxNFYuki3Xv/JHY+UIeK99341ACZ2DnYQ+9Mz4mLQZwud1nDysgUMhFW/h
fG/bZddfYGEgN6zC9/2PmOv9u/G2EiymKWkypzUnMb1zqqEmwIVVaVHMbphMHvtMcCqKKa7T6rPD
y8GNOiOnJ1M6TBAAIUuuWWhJ5sXOO3PI3krzKILXNPLun1hrPA54ouXm488wXtqTjeiz+/rib9lE
1vfeoHoqb/uPbGSOqXpG3XfyPRFB1M9ofWjVsqfmRCmaUqnVOtS4iI7vp+PZEcZ7sqTyO32yYCB5
J1K6a/5GO0Bghknt8cVZsXZkKxnOJ+OrcUx8uwmNPkmhUTfNbfdGY1U+XMM9NDrGUWeCB1S1/wcQ
kSjdl9ZMy8BrgEPsHTVFW9828Mb6YmaWM5X9Dr69kRh4c0mo0Fq3gKZ3ceqAHEc9uUljjnTGpTlb
nV/m64MmVk+HMshQgTJd/yO3S1VUK1NWlZhead4hLpWWe+p2TUALM6mmx7JvMt89dVpEiNptZfvx
HGJVPKc3Cw0zNMCMq7oF+d/wGHULKGj2vxBasR3Rwv08sEDEvTKeC72i5wm4TlMIWQZyzZpENcGz
ZTA9R5ne7p7KZPE0ou9FCaJpn93ZA4ufA9n1qeOk8o9evYQYCD9bXqL3rcy+YM3X5iaaOB2HeyU4
AMuRJBJ3bKdC9H+ZomnE7vgAcNZJ1/iNeFbqx5ON7eObCE+SGt2adjXEkhxdGYw3Z2RhSIb3MaBi
br2UXfAgR8oMBzz0FNIK+2LF4dfNPgbxQ8V9q+bKhKUTOG2/J6pd7EAXI9Jk5zuonWAns/Pqa34u
/vErtCfo4ZQkzDuI5AyAS5FzpOMbZUV0U60cE4iDtuq27I3HXPxopcMEHd7cblZEuYnNeyLo75vB
6lEbnkxyRA5jyfg9+fdnj42AKwwaUE2Gf9jZaf9A8stV2o7BH3USrJGH2bz+2ZtwVPguBIrkmXPo
otrk4dfMP8dN6yMUiUg6aQEJFhpe0wVd8MZEbrd5mtETNQzXAmBZyg/iawNcxahnnih1ESC6GX7p
QaJgzqqJIL9L0tVCp7f+Nk/zRxH9VkjURk5yZQUX8ZeRCYIqwO7EEAHrfMDdFWKfXX9XpwJ0E669
1hHg1OIBeOCizHGANDrqEykgV1x9UgbvLIbwbkJbXwyVY6NypSpSDjToDl3HZX7J0Uy0pf7Abf7R
2II1dpabJKLZMtFU0kBRNOFDljUTDduNzMOMASz8CKzLZMfMwrPzz2E1JqaJWVHDK2SrqI2/PaOW
7/yMY2z07lr/wNOVipeP0EMtXC8bztQbfc2aEG9M+s/MKCqYSfZ/TzNtftWrWFVFEvIcxsNAPiHr
MpbPw7+vyEnWnxFBqKqLTjRkG1WYG2lS0KNG6jhPC2MG0PRccE7QyB8aprBsmp+Y1RQzJdzvNzbW
A03tw1o+MOTWdeCnOSiC4bR7EED5WHcj6iJBWSZV/BODN2mns07zJa3Pe4lvb4LU+WrrCEewi0vN
MBY5KdKNN9lbJG/ygtnIBEMUEH50khdkJWfnSROexOpjmKUbn7VmmaOwLQYmJSXjWxJTKJXYcLcE
hg6WJ0FR4MgrUa9lNHiYbj1jV6985LJQCKzZNugg71NTtAnNyhkoeBmI3s7I99zl5NTIocYpaSJ+
QDXsz5PFH8CsxJFc/5ueo85OpGzHFJaPqcDrF1q622q8FvDRdfvyqxZfNokMSokvq4jyYuNRl9GN
28BxxRQoX7inVCdl2A1H0UKUv9HYkSI6qTgpilv9VprekRdwHju/e84O0dF+Mnre2wG6VMeKk14E
CBi5wMcXg5RufgK+8WxIJKQutMjPkOmSgxtA5BMrBJdnpu/uzjCrCCdYBMJtEDHKRQW2a8kb/s1Q
jCueoagf0frbjfx5mEpuOuyHqorRxEvO/x+omxtguvT/DHDIcRAP2Ws+2/xrCBe9qn6LCk++BOqM
KfvWSDAjWYOtsbaO2zhEGn6C5tvWXR3p00UGE3TFDYAFl92e8WldngFhLhFBXP9g7lRTDvOqSKiP
UVoP4vO+CCtjmEnE11kWGuZq2GqQ+J+2ds5e5MRreOKxCV51+zrPKGVcgrucJWFUhcx+qrNdQxsK
T8YlBGivZLCS2hTp6zzokBzAZFP0Rvoe+DRcsrVroRvM+l1YdIYf5ckgoozXPgozvZ4SvekLs4GP
xlwnruZBFVmlmhuOE6rinR+Q0T06H7ajXkD4XDLgJn9GbOkXJLANtGLpYuskb8aUElGc7Ra95kIo
O69YOb40XrdmiTN49b1m6GtW1gW3OBphcojUN+30t/ZVQ8HqvaEVOwf0xKSEwuhvPVG66eUncfzh
yvK/tZb+i1BYbIFieTGkwclZK12gTBBJmyU62Uu0t1CcfnVeRjP36rx3gdbRk4FWDC0eXp2nBe7+
DiCUyRxJTjQ84EjViiHbVCQlQfXQcc+NNuulsaSi7NWhN3CIs4xDDZ7xJi2TRzGdVBFCdbqhnuqm
os8iDMbARnnMZOAIPYr/gMmhcsyhZIsVcS5Ijt0BwWFtarhb/5txHfNgv5dJntGJgj1xp17Q5koW
sIHpc/SRS7Xc7uxR2wQSEv9vzuXHkZ97rXFOIUWGYrtilFZLHWBQkWW4Br3tF5XbLNggSDSJL9GY
+tXbyr/1muWqemMu7143fGENgIpq6QfwrGYx7Rle0sNy+nWEeWIHcq6gFaoxkIAWVI9QNeoRdtWy
eKdYHwFPZWSiCDlvFNDZI88LN5yFmKkc7WhNaEis1ThBC7mrOR0WV4qSel57Y830lj2ZzcMRZDpZ
GxQQjih0+yIr7DPCR1NM27kVzUH2svB6PPMXM9qxkgoTA/IwcGSB8zwu3b7xaMhqw5tZ7h6stPOb
8P35MDwY3/Ie3SaE55C6wneAinhfIdUm5SuozsiR+34JnEZC/DmML86s5trFhHGOqJFoRuwEHnvL
/hvK8Np8zCWtB8mkk8lzMJ4nrCJ2SFs8x6x+qzkZRudCK5K9N7xxNbUjm9AjAUHY+wd++Fefpyf6
HMiBgftMDn7Aps0JPWxdzI367x0hTrhhHL4nmZkisKBf2K5g+QDHgjWyTDnDTLFNSsi4ZisutFRM
EqDfQ1IvoyTpx0DHqnxgz9V7Fd+HfctzZTGrtZn+Cwwl73LyiknmcHox5ivAO3ZRV2N/WfXMqH1h
/Nq3z4k/GKkAPmju5/XlhfCErM6zYu16DAdSZrAOJwF23uYziFx9iu/4yFEX/LPpczyU6m1uW5C2
f4+XZHJuTyWHc6XtsLS2QzIXLRBQnPws/B0HkLZgN9A1cMSC6ZcsdjfExQH8VDKNo2QNJWRhvTLK
FALGSHD18ZXj2QpSDga2Yfj13hRjqRi33jycgk9LALMnRqnjDgD0lktFoxgMbzYLe6bRiOfDH1De
mWqnepxjxxdV3GzbdxLwupI8d806h1hFV7WIV3EW73AkUvak06BzZK/6mL3IQazpwH5HUgDeDWVu
ZHN0cmVhbQ1lbmRvYmoNMTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyODggMCBS
IA0vUmVzb3VyY2VzIDExNSAwIFIgDS9Db250ZW50cyAxMTYgMCBSIA0vQW5ub3RzIFsgMTE0IDAg
UiBdIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0g
DS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMTQgMCBvYmoNPDwgDS9EZXN0IFsgMTEzIDAgUiAvRml0
QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE5NSA2OTIgMjM4IDcw
NiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0x
MTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjcgMjE0IDAg
UiAvRjEyIDIxNiAwIFIgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIgL1RU
OCAzMDggMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2Ug
PDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTExNiAwIG9iag08PCAvTGVuZ3RoIDE5MDg3
ID4+IA1zdHJlYW0NCueTl6cIG5f1CkfVsIFgVkwEJKvEoOdkLWuUTjhzQ9jlujKwVjgXmX6MUWWE
eR6kgjBCGLa5GqvEwYYMx1ofVPI5DomTu4xasekKof1xLfOKxyCIrWtmFUVH4Q4eTMY72/qgTE4w
sbu9EwbvHh6b4p4fdCOI9vPfooMjzggARYIT0/SCie67cUCywNWya8RVczlAwy2CdWB9tGCSxrVp
WiA25piIFoPiYBAW8JvL5GsibBL9NXc0GtQ1VuRa4x1o19bnbnb9R1O2U/aCMoZD9iv5rdutcny6
V0+375NCRbfkJMJOk99V3umvsptWQyz+ReVEeCaBzP87w1L8vtSyf9FpN+rgFIxdIHKu+estjq6G
oMnbNrjeUSs5QPadTdGJN1l6ykZShmWcBSn4Z0M8mMoCZCAQ+WawBUGktx5IUxWEuu/kpgi3WwQF
J2MwdOwWxBss09Riay7d1g9kiGpq467DGc+IQKdEZjDmLWyhATXG25Ms8lxxCP5T+ihX8b93Os+M
wbwJ8l/4XQuaRZYVHzE9mz5Khy71B1IINKxzupaogISO1mT2PV7bZ8a02UkmYxsNghzB0p8T9E2E
WXBYuqSQjj/J+XHjgYWF7wgMYyZXJnJuwRxKYxVHceMJf4BX7G94e1xKC/R+lomTF1iCStmN3mLo
BAWAMxxD4DGapbr13HBC9N1GOLmEd90PV/dTlStD48zwA/v5rTzPf+RlAzTksLoemGtQLWGnqh+4
H3dNefRP6ppPz7rFVWd7D0N1wjbQzQMmGMMclF0VBSOOihnL1kBRpXg6UdlhPe9YhwJJO4Jvx8aQ
8rXsO0/PoyE8OEnlrsVAElJ/nADHCSxzRN74zFFHj6BwE5ggBKIQvx28aWfLt7m0bVS4RbUYQXyl
xED+0EX0zavLFPUg4j8WdJTcyedQKAYP9RYDHHNrnr1OPcMDX22R0Dw40ttNHr8Sulf9X8LlbJDT
c/T8kTyG2xZs5U7reINresckpxJGZStvZxyBLRnZLu1iYwACSzRKEAqaJNkXnoSK7GxwolF1fz94
mh+LBmNmdFh+CQ837H2B4Nu5Y+FUahAOqRysUeV8pd6/uWaSdTS3J0YL5H4EjGbVsNgKTM+u3L8A
G+SvjEZNwLd4HQCUEeJ5YbRbf4zEoH4ubPwU++kN2UzWBAlioDlawofzXhqv7kGfqzWjY659YOAM
oFBDF6EBhZcAkZqR7xiNCsSkLomEMMNzc+d9KfXW0W8RVOhP17DmTNiE4Q18mF1kOfLlmAJ3nNpg
koXY2/LNL6Z77OmtWJG2LdOWRnonQpy+h5ikFa18l0LRnkbfD6JbtY60gYFjQ/DnTRtTcj2pMTTv
o1SVjuqVFpmDZNjLRiwz5XUg7TVzKr2v8Dew5cI5FN69V82x9ErLFNR5SuXCnPY+hefvVfj5yRWC
FvJbvo3SDXlwa/U80huoTf6OKNkHwdv0pgJlxs4xIR9AIzez6DYUS8B54lAIhdzQP4RaFf+z0h0y
uF5Vaq/OOU2hRW5uSbBq8VqFXnAtXVsvkS5FA+Ftg2PQXaPiFVm1EiEX6t92GaY5LOXmvNiMa8aq
79lEajH9JW8xMwCoQR8vCc/s7bRN2HmNHrlqEvq37xMRTHrDNgqDjo6kn2444RfY0bwavnWXEm2j
5MaLCInulI6QwjyL4Km5zzx/Edu0uNDzK7lEHRiZ7DID2wmGxSDsHJq54QUVRcXCZ5Cqmz3NsLxu
+YciKrKkb7xWEcM1+gfYgf4L+pN1PC98Jp69CINZzOyGlndqayDFojryDaYf290iBaXWckRYDjWh
g/7YbwFcvCDfjhQkBPagxqa/l7yOs9eme9GTcN/cfvQ9XQ7VqSS4Kb1u2glCRPEPcS8ctrAiHomQ
7Lll4OhfJgyJsgMjFe83SO3wOvNY6w3AcY9jy4zsk/g+AD6tgg8gU0tICskIUkJnL9iMGQUZJ4ll
8hUIOAExfQIaJCk2hb4BufF2Y+ofYdkWDgb0UbTOQVJQ04QkbWYWMvlbH3B9xnEXH00S9WTBiDYw
3pW53PjSXRKoT6oesGs7NCS4lLa4K/Mp/cpXEouO/H5p8S6z3RwaQ48xyhlERvmi+4twsR/szUmP
Ebl45R0CdMAT2sxey9b8o3f97n5GxF/DtIXNJM+9gklE7GzkayngcZpAiZKAh7G8q5bC5YCc51E1
oCyu8Ix0GnUZ0E83ujadXI8LpjSF4Bsy/NMp7hqX1uJkSb9iAjdnStRU4THKZtjhXlV+/0Jiff2D
KvXVSMQY0L+0xP3pI0Ywlw/6Dy0uqzTolyuWlMwmzqJB0yWi7phOAzAal3MrE7Db/zPpzolc46hy
AyA+H5v78MUPkUCdpQv8SgUObCJDqaanCVdSd1iIpGd6tS3nlkIfSq9044rgb5ANtIhCmye1D3Uk
JClCCO0Z6JLoIjK9/XdTLfmLZeEqlIrolTVHBruDJgut9k4Fd7ISVtUqhbPJoyKC8IUIPeFpukap
eZgjjJRFOqGEOrJ2Yvwutb9uTw8NV6RUVN/Ncz+PciHL5FqYGfkgulyeDDN+8tbbkHY7JrgmDjOa
kKdBl9cNmhxkIjoRDXDb+MELxMULv8y/Lu7/msk9XLsJuxJTQ6UbIuLZ7G4RbLKsRSL6jFQ2nXkr
+UfWbiSC+h/UWPthTOt5UkN4xl3JEmZgNLIbIiImbnqXQKZol6uA5VUiOC3ZBd2c0W1iRa6FE+Fl
b8vuT0N9IO43nKXWEBGttOlrXDtQJOIJvdt4aiSzYcyhPaw8RupmyqowqkBXF3VkzMOi9c8Kahdo
zRg6Tsg/dzr0gGJ91au2vnyKtBlZX+SsUmD+JlSk+rQgmzUxDlx6USAUjnj0s5Y4f/7qORCBkj2w
zKIvUxRFhIwX9ixRRaikvllw9oLBuGZ3jLruLWku00T0QymUfa29lfF4IsObw5NSlyKZw5F706ZH
J2yzp0KXJPQ5Uy5S6dd89qCqqQRFqk00dn9Mg9LwRi7eMhAUYr7gt+7/uLlw9WdqJEKJQMZMX7/h
Ra9NT00foXwdEQpcYfqoHMXtrc7czfKbiE+KWV0/u6Oo/ddZJcSokymqyyr3RJ6eziZSLEBAoeFt
ogdp5jeW/RrBVkQxD0VdyHh2+yPHkvDBJj0WNvdQsQC5tKPS7YRQcSlzeVZ663lKoUVJUowjea99
zNRgBV4DuL3+TsaB2ABnb+Yl5+ArZH5CqqNFPK6R7sAq3Cc6Z5e3/nrheKkIljumbGhmowh4TA74
emyLZSCaodKF8u3ucXVM5Yal0RMWGFJ9lSwbvJ6yPW0Cqe4ZtOK3y1i7J7bh509j5mSk+/j1MuIN
oX8MglE/w4PA3WZsVFTfWW09tgS39iZqdicmb5GD4qNzjEYpAtvUtDqbGb0obS/XluV7hYlVeb2q
jY2YA3rvjHN1d8eSOo8eJe5K5Tz1d/8bt/rCoLXML5R6poR7NxsAA+fNReLzF4qHQ0Zkj+z1f67a
6srwYaHTI0k6eg8ftlT5hqLYSulgr7xCYQIJpTNUsIPNxfi2nmGX6RlHAJNygw7eNXyT7wAPdNxh
uzqp77OZgAQZlwwFI41Jvav80xK23vkEzn+YjdvhB4sf3xZFFyjFMhcMOMEmu2TD9SFW5GfO9/YH
vsPrjr3PA5UeuDQm2AdIa+z47hWsPMnfUfJcpzDq05CkE6k22TWYFT0LJZh2xXQhTjSEWOvtzc3R
jACNdHzIf9CkNFjTbrl5LGuIxDDcDU04PvZtHuiWC2iAazCV2WXJMlYS+DR7df7JeeVesJ/1j8pr
Ww5DZbOI3ljFHl5Smn42j9vuJt2D6nOacmO0yCNiOUJ+qGkDWbELfJnxuTLlE2BNjlkQ214WeUev
tvDkYH7kveBgxXzkeDeZq2lL4+zKSyAUnW27++UT3ewXIEKZBdzcG/lYBe/cgdIo6cAJYJCRZY+u
1RnzJzZ76UN2pGYPO2wYv1Z0+DJWY93ON+jiIhj3ujJG3U1jKxpcXKzAUDq0L4oEHyAKv5k2+8/F
rOGOfjx24LGPN8TcZuiW496pV6tKAfbd/6RDL+Aq7dHoAhPefySZ6BVESsBaxnDS8rvOdBZNEu0y
bFXMijvrPeZLD6aWj9XVbOYK+rwDZ8tUNmhIY4szrurL6F+ZTPCc+sEXHk+7lJwY/NFmQVnwbQcQ
O1vrrN/jExgWJEL8s972zP0KGWDOMwJzvBHK3bJgqPCt20pdE5VsXGRz7N94U16C6Mn2NJowH0jh
S3js/pRx+lXvfh9d6H1QsV9r20O4qL2NRzCk7PJIRoXgwAQFNfGaQVYGQ0/ZtMdn8C9JcbovJcrW
V55NhIvTd93r/yqa7X1+spXhHO7WJ52YXueSujtkDV/T4iNfPTCL+FI/BZhz3cZCYg9tsNzIWg/P
b5HoanLZrJUvHxjjLXivEYov/uxFozb8/1msxlw/SrLh85WSXjiYSylJamrucqoTGitJ7f0YPufR
QJfiaE3ojXrxH7hXqXXD+Lkbw4SoIrQXoH5Jo3chLqM9vpFCfMEO3NnMOqUDWk/KfRQMw6F+b5/S
RFyFNNhVwYV0C0CqeL3lAEzvGVzptHpLaWNtfWn+U76x/aW+HTpKafWE2EJH8nWqG2s8D/a1Vh1j
kxNz8cjBxWixkV/pTd1mG0OnOkbUKWPkhrZkWlj3gfbKCWuSo7dnNXp+8tqUpaxOKGeEq82wR7vJ
NFgYLK8AO+NPj4QQhfIgOLO/FldLwXRXiHjdEyOs8ue8qc7KImh8loJayD19/j9nnnJ5q4iWhEDD
AkusbjKqs7OREexki6Zq4DFilj17mK1YsjKrIPrad2E7DuzNX9zFabG2190aaMs6Ur9DUlSHdra6
AZvBCeMUHDVpc+QwVrb3rvUroL+eBV77bqq3u/Nv82w3K6w/e9vt2/C3IIokVW13aTExhmnh29Ck
EDe4Cxogb+RTwHNg8PcePF3BqNZ4d1ucjTHWWaXbX3dYOvZFSM31Qou91Qen3+X8rVlIDptdb/yD
yT6CB1BHZ38iEdLHBgrXLnJnRlRAJ9VxoMW3mekww9cH0L3bG3wgm02JnZxZrLlpIDjBP4wPDwi0
ge1G/pig7UlsiDrSY8LY5rVS+X0rvv7ulEIHXGzWKQCAtk2PGC5AyACf6EOJeV3YpFYpnQKzZGR7
jr6CSKXfeCNadSAsZUmW9UbI4Tbmox7IVLtepkMQTE7XARKNWHJ9F+xnoJiV+gKmNFFwRgY6QUVB
6CYNCAnOw328CdN1xVUHYY6iuN9GuJwaf5qUboeBbBv+2tZhTeeVqhkEruwRiEtLw2Xi08AvNqpR
6wHFZ5Hgv3ofAmHoNk++inTNJ6pQv44fMiAEJOMYO8ilANd2wn3jP2E3mHpwEsahT3TxGFEd5ZDr
JSTY0Tg1V17CvrlQU1d8sXRhGx4AT9P0ag176+fOp3iWZ8lQwdZZBAKNUu87cWNRSdNUg9i956Rh
S8EM4k9eu3sG+6WT8LNnPbNREKNrTG1EV1+PmHinkcA0/3hRVcnlJ2YonNcpX8rXuyzxY6gPahMK
kRkomKiLP9YEjhuIQ++URq1z8VXcaqPfMs/jAkkraBKxqnG6hkwB4U7A/4T8DyhSgeHIXMawgZly
UkxOEpQonoeQTKjC6l2JVTFor2WVaItXMsHc/Xab0P+c9RgTREFIR+TakR/+7Pdt7mWGvuU5SZXS
LOk/XcBpKlImfen+lqYTozbRS4ZZ6O68yt0Sn3GCIJbYauY2+GzipXx57Hurax0mc7usODR6aP9T
61htzC9KUyTM5aqGLN2LoAIqi6C8MIBjw29Zgf7ZIFFsxwjtJhOYOauko9kza5V5CaseR0NHnRAC
P2dhLJfYuRdbOuRa87gmVrFndTyq/ksQ8NsIIon4HIFu+IIBwyE+glGO5RBxGwBfr/l31lPh3UEY
TJXBLlH408kp+FdbG0WZIFaF4i1hCBzOpMNp7CqrHmsU99i5FTOt6mV3esUhQMvzxO4RGYOzcCId
XbrlBY60qruYNbJnFK+uxNepwy+s7xHzzrZJF0fGhimLRON+xqesydNdUo7v15Y7Am5/1MHfpDNv
p1wEEWpgmbssxesBkmb87FEADebB4kgSy9EVnz5oWVIss/s+YHC5nbacBMsnKIyQNrkruLPbPSXk
ixAkLyyWFdE5bV8PlaaTGJ/z7Hl7JESUs3JuNMjNTi5u5Jlvj83VIRvC2XSh89UrHaCfE3Yf8WjH
yGYYHSv6KEykg5TKr2JUDZIjS+qA+sPWzanzYm1haKVZresMsp7FRHRntj6lUqATUmt4YZH/31Oo
UUrrB/YI8EXsTR22s/QrL3zO5UxJdUe5DW+LhIhyzpGSpEwjcj7QQSviHSRKrQuuSCQGaoU65ODI
mx5XuVGEWaeXPbWzzcopOozu6cJipfE+BLWra8ZZx1Pxk4ONcNDmL6Vss+gC2fEwxqQSS9dKMymx
qIty1veSxiGXSB3q9J4NNX+lS8OdifQ+FC77rHIcVis5tFATcicgP4HpzWxeb2/4SsonFJCLWdkW
Z0iPDAGDKQYSRZ3GmQISrowmgEcSfWDK9a7CJm1DLFXMBhEKC/VbtmMM8L59DG8nvFsgC+UXJgWR
8VTWKPpxREokHwYhdT1JK8wC3iKoKvcbm6w/K/ybWklmRNZHl8fU+YSy8Y89c2fyCJ6kzs8a7gYz
e1A4aVAJcF7NVuLIWTmNKCzV2HWCrqp3CEAhVcRO3wJvBiGpmgY/pRa6S41SdRgIRHvxxXya2H7x
s6rQa7eCJFv0DtelazEuaJOLrwi24S7+lzdRcI+Spm/kGFJXPl0pSvsqL1UAZHnddhflPQhaCg+A
ltYm7fRolMyYdnnPODJJ+yvb4sHOBYQVdmdeEcZGltD/H/BD/o415Dq30W8ztlQms+5kDyNDC1dB
41ALNyPLQLmguUSJKpCSJcHEJ0VrkH3FDTbVSbAQNgO/fFHwGpgxYEMjHbrH9CzwGhiTsXSu69Gq
ilhkCAE2LYwnUwJrzOKpzW12eblCCKD9Lkj+H8rPoZB59SfO8+8N0xDXmLBiTVjfOloPkFCSKR9h
GqG6oybdRxdQVgs9WqLIRahUfLm1DQJ7dRolm/fT1Xia+4tsL8pSjCcDT8mQkSuh59/iNeblNcvq
XaHE7EO+ruFXc/7UjhJZPaZjD4wQnNgDhuQcLJnFfzMm2RW60xFpK22XJ+A6JTgCZferr0J5BqCb
IQpkAaKFE81pEhN1pSeD0+1W8OPtVRZdwYgH0dTYdA+m8c9mLTT14Jfto1H6Hm4ClXEBB1xoydAH
WDXjgPqpDjW6Dp/X/ljMIGs3tZvNDXOff1wPO+j3nMS6VEmEe1+bJLCPmpbLPygwn3n7QNlEOg+P
C98YjR2+1AeHnvI8x9sYFMecHquiDzyV9poYhqJl3UiobThAzXSJa/fVko2+qD2n2TLy35GYVq1t
C2H+4xNdRWuJqaJu2t+gfKLNwMlsLw6aWQre77KyThLBRYxcyPSaPv14YocXT5POSqcDog4C9v4z
lcvhmqSHG7zj2MU+d/fLkkneixUDsJn4jKwCpDQs/IHyr3Gj13gR5SLsoM95zi9SvuJ2RPvQXoo+
VWenXE3gnf4+KlCzgjYJ4+1ZBbN9tVm3aF23pDF0O4RWudxL2x0UFwA5AdDx7MXM+9UxUd0zPezu
2Lr8vTX8yO3101UaHmXOPinb6cNIfdCdRQRgrZCSBRgo9aJBnFHFMHRCy16kfWPDoJPcb2nW5Wdd
NmmJzsfum0vrBYRX/QnF0iPQDgOUL9iO8XQxIzOu5ryLyhlbVnCysGHNP+/y4GbIkkECrHbsbL+9
01ULKnczIFbOO9amql6I6eJ/Bfw1BkjyL57xZgSNx3T/pWOdHyCtnXzt6gFvzRhuMspSQ83bw9np
S2QlEi6fA1f+4e3D8hKEiCO1+usTghLW/8DN1aNu8VAwFYWu2sYd2OSa+QN5LkKCfislC0YyT/D0
SZPT7RnbOifRoUVz86zA3j21rny8lUT2cvFATMRdJNc+QUXudcasQDyIo1sqKwlQTGAf7+YyPLDQ
IN4xQU3R6UJBYNiLD2Y07vcOpBZ6a0R94bB12Ya9s1NPNF6SYHZEvrAW8mpKAZGoUzWcgfaZP6zZ
cUd9MqPEqsPwh8Tdb67ptQxwVHxrjx9z8/WX0OsEwYOdxSqev4v4J0U39qN7hV5d7U2tZXMVjf/4
K2LmDOSioMWp3Qi2KYqABFpHYHJQym8ig1YhRQvDVAj/qu4H8UhuBp0+Xs+p4SnzsImb8H0QoiBY
MY4c7N+fBrgyO0IGE3liXJSLlRdU5JmBlO8C2bFzbY5WnU9TQBMAFzOUdDK4iGSwOMbEdl1HPs+F
72akfTWRIsAZ7v+M7UQV8p6nWLsnJoSYa59NNm++SOF+RF2zl22qXd24ctrFTu30J2WGLvBl2IRn
VX14NvZcvpcmzNEC03p0WwObZoU/R9knOAGXR58cVgL5Tb1jI/odKIqdN5/eQE9omWo8hNuhgtfq
9HEigfQmi+iWvw3aZVAIPLyK/TB4aQhwKwC7QA6rpDxWchmYaCFAtw9w19hgXlEwivKXAvVa3iG+
SQIahH0KbbBKqqqwBKR1Mw36z8XmHSJe4b+w6ykhhI/fl+uSLirx5Ra3I+QuMwkG1nVbG7mYtNP5
sLKr+rAaeFzm2FW1tmIBtD26vls6dQs5VADxURU85GMW4S/QybLLwmwS64Dxn6/VXlulWB6nGMxA
Qr6/CFg9r7AZ+Ap5BcK+Icmaq4k4HioRKuvLHYnnXztXxKYrep0x/bK6Q2K9KYVU2322QCeNLCLq
rJ0pDdmmnWw+7IUfChQzPdkOboy3Dm43S/HCWNd2Ajq7uYALkojn9o5iu02Ir3ThRTQwFjDIi5PO
xICXnUUEX173YqDprlpdQjClg+lsyZ3fYDBPseApVEkdl+/Mn+stbc4JDDn8o3Brfkkp1U5h8vdp
o1GiapB3ajJSyYgxczAc7ePH0d4dlRoJc4v63tQ3RAcq5k72sXWzQ69lRWNEjyU4cTjWfRccmqNV
/MK7NS/aPRkW22FUbZx1IxISX66gbNnvBuOZ8uIOoz6NCPyg8cHYW4wGBuTd33omKhTpFW+4I2sD
MFAO0EUDbuwQ9Ak54i61PZyXgZ9adheGPOIN/ELzj5r8we3cbYIr8NWAL56ewvA8dQMLGL1VJp1i
7N6u/blWIwEtyKVvFmA/ZbqbWUK38hZjC+4shb/A9b8Gu/1gpZEerMIEs0xJvghly1OXdULxr6RP
Zb9iiBFoM8Qn1kEXNHp/DlZeQWosyvj93iHzPFXFhpALQZcGHNdgVRABRrEVWvOcsmlpiOTXRzxM
8kHZDYBdJ+KsoaS8F8bcBm7n+0bNzqnzouuQp8Vuxv6BHR1OJ93iKESGQEu5TNy0/wBwbLLu+B0L
XRammkexzbeTNFFPdY94r+kny0ZfUf1jXpcXBSnOS7VNn4Y/JOq3Y6pYJ5J1JQDGMQJ3RnY+gEUv
jIc/yQAVF39HcPOWvCkWtx6hcowNboxgf0+AwCSxS67WhdK7oU3L+v65ZGt+pZgNpq8SqO7fslBj
LW+xce/2cM+k+ELFTh5+G7EH3Q0XoROE2UdG2OGCWx5PsBc8M9ZsL0p68/y8+A0FoPmHS7ojhPhG
GUv6N1wqKo81VH3nq5IPXXGGUa1S3D9e7Fr12zd1FjQPxBSs/VvT5qJTndf7UMFf44sXV9tkMIQA
2KKTDJBK2HNvEtZzZvujMvecxaXvHhLRIB/6SoVMu9k/bxTS3Uq0gtGjrWh9Yq+Err/1TWASQwSG
4scGJ3teLTvD96omj2Tj5ziJbpmhDB9Z0n+/p54HJRJgdoHLl6PZhW/0G0UykctjwBoOyUWSeR+l
SwVr5klEbW03pRmrY2dRjGm5NONC/qo7PZ9bQ0wsh6IXPzMh4aeyuW6OUnz2fRZ4ya026WKEBvOR
0uSxMEq1/CQwRMa9wVyylRxe2HGXDymMmgjH8nu0gu5D2B/IwC72Uf8PdQypAQkPXyJPVLcPciG0
vsbT/y05IHkyDT4k5R+fFvHMQX3lxXJ/3ytRLbdCDYE05Hp86jR+UJY4+OC39X04pccW6TaqSvW/
NgGn9srX2AnZ6HNbSe+5N5kCN5zbAYTB7b4aAy37cmKYJQU0JROQSsyHuq0gQcr6etsK76ae9T+r
v6CEePTKZc9pYXgnNgKe60h1fZvmy3AMidAwPTm65g6Iel/91Nw7ho6RjXOjDJAtBMywnWVbD6m7
uwRwSMCLnNUDnYsb9ISk/Jdnex+qZ2ib0Ht6W45xTlp/qcoGpx+E+yNlQmAn4ziHqMXVywiGFh0A
fuvaSu7xa4fXTRrskfXJFfsa+IuU+VeirICbrWclAP2Jk4yPvCHmAr2yeSBV9V1KtEaChJhMDOlX
unUgSF0W+z01Afbr8UPAqFRzvWuL4bJ6MKtHyQydFr0I21aNVj4A+P/VTT/eAia8WcpAezGhXuX/
MqCAE/ry2Xjr67ENoA5qgPNGlS7jxTpw9gvITbYHN8WfJT0KrAVYyA8mPn3t5jZpkmrUvcMArhob
QV6eUJTyVUyZGM+h9kVs24iTztOc587lL7N/mSr1aI3XXo9jvo2LVK8v8okMGfROG7315IkADgJ7
5A4cYnUlwUlQnIyqixIqXrGug640qjG+Ce5jAFp11nsMq8+hoB1y3Md41sOAE00papaveJ0APYWZ
M18Zkt9bv7U9IvdizTI87nkhvFHqgTEYZVoCz8P0OsevizjRO2Wxwllqhl1Z1sNphZLuWpPFV2yz
sBa6mQgJXaAj4BzwLi6omXOKfcPwH3B9KTxTixLGDOKgjRY6CvyQ5/Y169dbHFa4gEraAQxqXcp6
n84RCruW3jxYQK1meDqqXqgM3daHNH7jVvrZQHkN/RI9Wac5sI+SIbOj60xeY0SmZtrRN6zXEHZh
Clni5YJQMb55C0uGdmMvAA9kv1BXBulpM1lp2Cf8EKnFqoXd3VMLmEcAsizt3oeLrvOre5NCHfUi
vT589YxBwIfuag7NsNjXswzYw9JhGxWGs0zR8WYZ26MRKNJVq5Y2QXd9V70PVVjbrJcFbryK5kXT
WUPbK91yl4JTfVlSpq+CvThj8WWHB6Syqldd7HM0mRorpbX57UZEwxVyF/P3njdBpBJ43UBrjTI6
UBolizwwYk8VOqvKqbLvcrz21PkZfSUsfsgWBIDXYT9kdx88UuUMZPyx2rZjnUWLvstQNDG14djn
SF5O6SmoxMrVGO/xPH3SFZdBb0Rt/Go5uo3HdEEIFX6vbIdLiwMOMn2bJAbT6KNipFrzFoq8t6Dg
cvGJ7XowF1Zz2ETxCg1CK+mDCnAlGxV6KbH8t+fTnr3utQtTaGDb09Af1S5/9cKZveaibB+IqOWf
M8uwXRyUCp32GEYHW6G66ZNPLEiyUk9j3w8X45qRk/7B3GE4xtsJDffQrFdpqOq4W380wqxcPPm9
6EgoE/MVqwyMlKO4RhRaelC51AjsXJiwPVPXIOawG62Jx+w3KaOC1cUbSHlS8iTc0UdGMHzDXeFn
8bwxFtISarsccfL3Xie7NSUGOSn2bhAWNBleXVxEs7XcW3J+CwtdZW2vN/vqtUPGt/o3jOyQoEsm
K3f2a14MXJx6ar9sujjCXnvds+NwLBpSK/kv1W6+FafE2CLAusPzVk7+pr3zTpT4TQnM2Wifi3KR
4wwc/1B/w6ewm2kbfP3Jmo+NuWXCbSz2bKdgT2Loahrbc2vYX1XGAZNgL+lmbq71MVP0YMCC0uzf
Kd8w1wHGpoBV/BARaq0IOcUbrSaZhTti24DR4kWxarc7Y/Wzt3iMsLHcIlALsQp/jNn5d142jnHx
hZzIjRxwuFvtxbXi+oIqzPYEWyWM/+EfDUQnyAc96QGRnkD8F1rERHZFxnCPoKU7T9D37IvatTfE
xqX4mTuOcz+/qEBkuIny1ABOOqot+qycZBWHmkvoc5E7zV2TZQ/38CoHojSiDzxSzEoLcNMVHufX
qjOy13I2Jh1aDlY2Egx5XZeIyot50D7e/LUDty8J20HQMx65lMn+m2auqrxOaD1E14Kc33LtisAw
HHCZEr8zxrTMaLiuKFEPc4dwdirqCf8lLNn45m6dHJRDXbtK5G3viExBJRSKq1dc8A6sI765AQbi
v6nLx79M5EwWPwCJhkl9HgM0STUlR96dO5KL+kYtzjISONQ3ph21qPAL8u/Jxr2pG0zCiAyfh4SJ
QbQwlrnog/JKxBlUJdvl+0EbssHKMeWDySSfe6f/Jyj9Dbjxq5BTcAxpM5AdHq9HCNW2PriiFZ4H
Tl2r11e5m6SAcJhkD4YsbrnEVTXWgL7eJSJGGq5lCChnz0Shxzs57TosEf0+XpeLEjKDaCattfyk
6zoin24evycHpbdQ0R2yAWjoadIH4sO6pCvVRGk/MlBpM34Ft7NOYr6aPNCA5a9LAw7DYFRQl3Im
DPLu5tsJoDK0WeWDWsbCkNs6ZdJBZefGq2QeCsiNoAkZnOOwNvaJhCComxkRbXmqewIUuUAYVGhb
Ongm1yq9iJNeoGkWVgZ6k/RUYceEDETonCjgzLmiD3kOwXWKzdQHohzaFRcQxxwW7tcBoE0VONwp
kREwmnvvUuvrIzKPNyT4X+TB7qf+4PfG62O4vyg4LOympAz+CLeSCibiEkvs+sv9igLiKkjni8Lg
WV6DHQQdOFV5iOuquhJVNNTPhJVW3kv19kq9JXH0q0WkPqMPkRfjh6qdFPlnBKiM59elL5Ife+98
lCJvHSbUmYsKDODdTPrHjCdb3mVVQ344Xv7mGBMEjYQZZqws+gYrMHtMm/sDsbiL2JdQRSSGJRJl
IdV9vAzNk2fhZnnFkgFXuF9t0VoAfd3N2RqXX7R4/J0jAyaIZ+fFQqGwcqyqByNUGWFNVrMEkiqh
LPUqvh5+UECT4pCd63qZ4sYzzJOIYJ4VDj/YGwyJx+fl5muU5tRxzVICeXW1V4pCi6ZBXB/Oen8X
VbfKntwmDU6bb8rmlF182Z3wHeSBduRu//flaBzAztEedpBcGCCl0pkGUo1wdpH6xQRmEsF6WZgH
imm20a/h74tsf12GDTSsvETi/69w4a5p8vqgi/nKNhyJtcJg+8PutaHfY0q9/inOfE/k9rnIbefg
BfTRW1yFu6hZMxi4f2OYafv16TI1uQGRjoVRJzKL3EVAaXiwEHkzmvs3g3uN0doaolUpnaccLLG0
o+odCkW/qDw6+A/gJxA2N7hvNMWyeofRKJ9C1crAE3tcwkyjFFYg4XysqtLDqiHTQly6R86rI69G
0fYr9e5GmzmQ6il+R4TJ+3+7bGcjQgBqf+yEHh9dqO7jBPZmZOYt1n8fCj9qFdMJb1lyzHkvym6e
zQKrZqkhWZ094eoPgszp97q1S3anEXJOo+UxmVhllSaqcrRlDtHYFubV/rQg78A8q+2s20NhA7ZL
NMK6W71Dd7TOWxx0whaZdPVzJ9jNWKqWdfhwE+Idc3O09eBFZRyQcYWOUSBp/Nry0cIg/xaUfavH
FxTjd1+jUhlcm+1jrSwN3bqG0rgQj0iLZNJAwyZEL77qMBM1Un3LObLbIXMDgYLfcjQRoqpo+L0S
hhp7G1myvcYJeEqgfEElASvh0XbtIbs7grdnJWbWhonVqIH9qDaztT3caz3Z7oWXgiINKXS6v+FQ
Dr2DJhc6rrMzKgC08cBgLklFxz+6u2fNqyxCZ6R563FuzEKu7s5x4vc3F8hQhWsAqJOk66l51wvb
ikWst5b9sPV1jgYnUDLajxBk03iR5VSXPMY4tzCNaqC2joalgVaN4swwUTwoYvEyG5JzIeINYOT5
70Rcx2hR+uXFetHywOL2H/GOngvv7o0nWw0KAXpjJw7ZXr70frfDysTOPdbzDYI2qIc5xmlPYoG4
U5V9yViTlb/82/W4qa5JNUIqrTcaF7cLwT9MGpX7poDx4ie5N1XT92yuw/RW6EzvyI5YWLCQvCQx
ssmbiASj/QhPt/WUjUarfmpEuGtSlhmMJpefhUVHBsa485BPVHLsuXzRP2FlO+EayJPGRZwaXr7M
L/AcHn2WcTQERfwrAaO20aeD5YhzN2Q+MzehsrDyrN5C+4Km14pjaFZFghL4hzdyYhyqkbkyhCst
nXcz/to0W/qgR7ITIp2u8NBOTgUCjNpf9HKE4qavKzZvzoGiPnuvQzwOdnKjegtFEXIov+wUGu8O
uSEXZyy7jtpla4emwKtOXYRUFXEJmwr6W3FedjaTQMmWwRV8wd2gHqymMpl5Q/2XnbRfBTjWgLqh
wYpIuIkMN8EF/p3XCnYQFXL0zNcOSWZUNXIHPQ+fzJfU0iXZlF/3blwFaBfUzrLWrlute0QMO2po
EDO505FBE0nkhd9HXnkOiMYE9MR6O/DD1NLFwk9bf8vCcTPdX4Yz5z8ufdviLNizx468qcbOGSdV
BcCCqphxrrnsj2pf7Hf5F5U16AH5DlwUUt2Iufs/Bmcid8yR/ySvcd4uec3TtqVW9EAMPtJ5VHYF
TMa8HoRV5gNa289web3vLEHRSuuEaYcLYWGLnYxylfHm4dgYUO0vh/1T3AWrRhBLRU2E8eIONjmH
Pd8HyCKWmVHEweUulXZxfCcPTYY9LahpiTn6ZQmdRQOd0V4OO8uvME/S4TnEUGZpniCGzd/Gia1R
Dwzi5iscOKNUXEeiMPre2K4uiyB4W9F0cBvgzdQg6LVcbChCibuinbrHsQd9vYn5PTCWOW4c2uwQ
iD32msj7S5LU4MlhhzI9npeZBEnJiPT1KL4A08bpCH2fmFRefWATdQXkFlYoZCA0uKlrWxzzYJu7
9YN+hKnxJvIIEhHEtLvbRGN0K0ENxcqEbmjdhfAD7TlnCyDOrx5ILzhke1IrXXtyu7IjAxnjzvbM
TTirMeoc7VZ6HHGdPyS+SFc2y+Mnl/VfnBxdXDipt8V7nHRMGEjMnPSgFUswmWQ5RavcxTtx6nQy
SH5qxyktMMo4jvUD8B2v9c1UrfyDiQkYtTVCwatU2P3GMY7N9obTeChxc+gWs16opqvNejGF6jqR
Tnx9vy6GjwXz05E/MEF/bH7mVwDnSFTi/qCHM47umFpwXRjpRtIBlIzHQgPrLJyfE/AFSSYyNZ+/
4FKyXX0dwVGO0a0rfCHNCRQm0JLwixk6u3epwvXmzMC/I3EwCOtgNhyB7Hun/3/2ehcvi7KspRiq
tph7c9c9bxDfdi1cE+PyMZsMzq/QsEfR0848KVFEdXWqULaQVMAFcMjO3sCgc02gMAlZcnTtZfvb
8+D6hnPHxI6l5px2w6aLZyCIclyYMiJKhS5aMjWYkppSflTpn1YWWL4Bjx8PTz/LZGDrBh2+EFCJ
vpJufvc86Z2EFIhurlkefJMZZl4lgu2wbk8YahCervijsbuAbZQAWd3SzeHc3uvp9jU7D1OdKJdC
KmEKzwEe+1kpf34L3OGY4xijzicIQ5e4450xVhrTxYAOi6cTlWhYmaNAKOoU0G1UJt9ovIs4ytPy
dzFSc7syaudeE+wyENGNnyCoFUlywmGlG7k3AHmGxGDvLqUfSAYD+T6C65VTQNMuaXKK/RSaLrDX
nQQt2Ow/bkdOx5CtoqEZU89xIXPFU4aAyrJm4WCKHDZH60IUbRLVxcFArRrsPbxjDzgwC+o94veH
t+IR0sK19ScwdGGICQ8IZO7PcqX7ZdEakTAnyM7fy/PLKb+NbCdyEbpMqyt94H50vq4VHlbDJvr0
BXVFpXgug7lowDbanX88QnLWLbZgp5VW8mW8P7M9YmzeKPxLmChQTI40n1lOAX55sa6uo5gKcVvR
5wHYdgieQhLXLtN7vvgu0a2DgiZwXGe9hDi3Anl3yEyz0G6BORx0PVfNaUT8Qo7Eb8Y/KswWd/JL
poFlTi/P4LL+5Wpz34jRCgCVrlZ7fYxU+MQT240aBdSuLXKGwcAkLymKf1L66k6PROZEJJonIms9
blsB4LppMHxcLhFeBjmatjt0fMsBlDzpv9faU7AUD+uyzYZNxbLs4FY4dbHlv9nVWOAE+ADhgy2h
WRbtutqLTTBPwDwiSG/GmL24TyCgCMCKyY2esENKOnqjPofYodtguqPj6RKyG81ewX4x4QBd6ZMj
DFLYSG24AkCfx8X8DwTa02HUYCmCBRfSSSBX8qQpIpuIufCwtOvN07YdVMblw/Rd4XX+yI5HXPXr
uNNFcR5gS9aK0dhEKfoE+h3L5oIKwYcQugW1IIFY94T8VnRcBpdCCcOfO2ELCZZfX7U5wH0Vkzsx
63SNMTB3eJYisVebdx+/sLFKzqL/+3KaxI1swZ+vMO7Md7trwxmH2PN+z6xOqcob/kvwUL70Pmg3
393/CFThk+GOcjTE+jreSiqKOmFvrgjXWL0GFY0VCPfldYKGtD/wJLrjcEIE70rkFNyQYYcgw8+F
3AS/hi+CtWBd/xJKYnKc0FrU/8kpPuud9lsPm3UmjUupVOF/zAOTUWcZzjR5nPPnUM5kgV9MHKQs
fAL2r1uxb7QQjn8amtq1ddyhRCcFuyNbCT5ePrztUsnbg4Ql6qRYYDQ0SDcCsk0dw54uE9UrnEYD
Pz/WYlC5ggMzDeZGHrwPISAB0rF9xE0R1WOji8SnBb5FURKAy/9t+cE6EDlZHRM5XTNMdkzZ8mlP
AOujvswNlIcfuDPxWVATZm8OhL4t+N2/H1l1ef9ChrJFQ0R2fXSjm5+rRYhx/RXU+mLo4ElyENpu
aiOETss81l21YVHokbDhgU3r+CjeE7+Jzrcm7ZtewBRqg+8oYfoq3Nts5J6fPicK1q3Mtg6ImrAe
lzFtZGv52zhezQRa5HXEtEN07kk7fA8yryTgR5dTkJVmhnt/aZvgZnB+gbt6vAmV3QlnOSUSwAWr
Xf3wpPujG2TxsNzwlpDYI4pMvipeqxykcC5IeoUhABYwiMDO+R9vVPOImT2tnc2wFkh1wNnGVHPE
Z/FWNVb6K5OucNDKnoqJoozINRrAUYtEIBfOBxspnu0vSuiC9mmgjlUUXkCNrCYJMwQ6FQbZevYX
cjnVVCzVwuIyiLxB45m/XdDcL4c7zY5YjaslowcvkBbC/2mspK/3oQy+AlxKlv0BEuCijJWz35tp
+usI92bju6kDK+LUCkdqfZy0llts3kH+Rq7Z0Crrvjc7TDlXKKJqhkFYuEML3ug3X3KN8/YujZox
FyYtNBAKs7bpNr5ejQbwh6iCsGSxDSV4p0k5SWs/4cxMpyd2X1lgzDsnhy4lpTmNBlFsjSW9WCQQ
d00oOO1vyyVCRwOfyQ5hwPvAFC8NmJXk1TnLtpkhJ674CEwiFQKvEyWpYLr60d9XSsIhyJQRFHfW
aJ71vVj4QZi+FNuzvBi4Si44D61s3RwemIiytbTnSFpMqsVwXyrP305GnTPCeeKc2rBHCuViisqX
t5q4Hmq+5/e0590Z2IAgTt311a6/anthdMstrAm0xR3XfYzQpC0TvEhWKlvP0I7udhySNC2zsx3f
V47FT+NkWAqQddUnKrb1LVCRfzN8K/SGFn/rPrmZtALiKaq0UaBu0iaxIvVkUNMYngy5Jm5sKqNv
u6JV3ro1bRh78tKF+rDl4dWR50SelVhkxqEXGtjZrTYi/Jh/kz5Qu1ocu6OY0ISMLqpEYrEZFuZ7
YPfrcO2QU2IJ1iszD223MGfMPrVYNb+uiEAEQajUGHFMpxqQJ8AHMPpynuirxfFiYbKlwqSfXdJP
PGEETFV59IiUIAqWWzKYCJuLYF2k+arV9VdpcHfQuvuZmCB8bGLiiWooc8qnO9/Ogs/A3/a0L/c7
HxQW4zgevl3CAxjGi1jI8okbw3ttWdYOrf1zRR+9uNH8Fb/X5HIFg3qn5sPuSi2x+Ei2F3kanjAW
4u/EP/0RpkfuW+Ci7U3XKs/t4vILoGZPdhG0r+JK/9SeO5RKcbnlIqwCh4BIVsMadfwrZ3wi3vUt
Pzz78V+7c9HRoXeGTiJ2zxWjnE5wAfa1Lc5g/fRsxhPoq3DDLHxGXPPLblAfHQS0BvnQ1fRM1We1
tIze0E87irI+rDndGtAZOAPhwEO+VreGvhE5gveKaC3pQ0GW5ElHUR/OKoNrAHok8SMTDsaN1XKP
ShBQDRWHsrzuteAZ5jpl1/NodDDLcSCdN3EtcMH31lbjpwvDO4gECQDx9N9oucl30mWSGokBqJiK
r/V5dg+SFQ+INuQLnn1pOFoEfQ8oL1h2A+BG/E3H8EZnL13pvEfT3j7SD8pQID61VNn4bS8NIeE3
WAgbTE+6fsTD+7jP4hkXCnpMVJsjNI3QrBL6tbVd5zza70nEt4Uywqc6MxYlLWj3NuSQZvqxR0UB
W5X0GHHQ739t5hw7VrK7/6A046c8u2EJg47UISkYiMfMD3qN9Yl/aEk6MnLcORKBOzLg4fcTID5c
lHvRYNvptsFSfYvPjquxzQUBTeG/Gmo6etMA47Tu3A746TDFvWpjqgYDu4Jt5TXVpIvpgmy7SKPL
B9XLKqzMTAcgJNsyLO7LaIkUyxsrtz0uWFEmEezbhgVnputNIpwo8jnrZS1TNVv08L9u+tKO35hb
Vy2hnWBnz+jkUVpYA4lVHiyCy/o72v9gWs/mVGD+H3iXbQV8Z+sqO72xm3ak/OO0WsJ/wszTjTwW
0prMgeJB8uk52q0vJIPNguUaAuWc4UPR/drJ7Oz0ftOMcgAus88N73ZUisXPHQzFESBhItQgNAMH
vfq1SEePv7ecLRfPOXX4xVNZ3JWnNwXEqKwYS5ueRZFk6Penmm4N5dTPRej3h41FNl74AVwGDQm2
t6WboXLbuBph0x9vFNIMkDv7gh0aW0gYs10NAkU8Q/vbsKwpASyiXI8aAVIK8tTbsRwpj9okxnjT
Lb0HOQQGV9JHrHl8CMqGE6/h/q0D3yPqAaQRAEg71oOaOkmcFoY0Yg8B+yAX0UW66Yr9uP1C/o1c
8IScJLUmUSpVEQS5XvBUyzgEt1hrJwB9APSzXqOKfIVWLwVaUgDZOmVm0Xh2tybuw5HvlvJ158UO
EA3XhrWHLQ/8H/VjA8Z7fK4bgWLsXiTXs1ZtRgHZd8nOjjyt3hGgHM2qItPG91uAtHZq+gxGk8sm
NFqvw6RkYX7n8P/nmBN0cl9Vg3R0VoIbYiPCs1FunsCDlsFoyj2Swi0HU+wzmUQPnx+Lym3dYM4H
JVdrIp+3flhQiWBysqAq3nmhQuZY9+WH0KR8tzVD0nt95xMvhEX86HBhsTzdshlr/unCr6omOSXL
9u3R25BdXe9a2gu/fBRehphVoRHaba19Ahv8S2ROLBb0nZPVnQEqOa6NoG8H/6hvDYlWBTF6M7GB
9LTf5M6HtaPflLWpLdUXW0Rd1cmufRy6hpr3uvf4QKBhnCsRqFKN7O0NYr65qURxVHRmxUwLGUXZ
yJPgFFoshY1R0LwFIey3gxKYGfmlCNAbVr90PGs2zTwpcUp5qsjl4AD+5sDGpvCzRpS1fwhIc5fQ
dVeMlOGCNDGeyxYQCUXT6Ze06LEBtFVQSmiPaeLalUd0UpaXMKp9vqIe2fJ+mckolC6Pd7ExjSzJ
d8ztOj21Jim0FC8nzG6c4az4aSGxZIN1b/eHkROcwD8Fb0Q7foBA8IVs2haLn7TUmnO8HkS71+eP
N+x4z6NAaEQuUqJj3XHdqLtE6fd0LJZLoVJ986tBvcIHEYG+itVNVdXueVcsscw3oMOWjejhhR+1
2Ay3IqsKe0N/Lc/dDbrr2EYGS0bDHEY2epJ1ZyfbA/Ug1n05sdWRXIA5OpPjqA5komfbklpcsuBF
bBAt1OXST713s/oI1YCdCPx4/3YbrUNoWDkq2nLm713Eej+IO6WLk0wCAAiy8FgEkz/0TvcWjc1G
NH5+E60JxBJRSBeH8tgYa4zPrshcLgv0Oid+TXzv6wiP4qmGYmLIpiSoaqdJx19suY7jC9TFkQwb
hgB29k+s64vSwUM+MgEFX35/oiCH81SmdL90qBi/Yv0taiSMxtuOMGBmiB2O61fNWHTrru3iDKI8
srclUUXqEO3+MXUIlAmJYcYWswruXFOKFCb4Bbxknh9ZtL0mrRGS7ZPkjZ4fol3bwHz7iqVtNtfG
BckxSU8/vifl8MoQM8OiLJ6pgJnDNuw0AabmRZ1sO853JsHHWaCH8UO3+1ZoQYh1qJdh5xAsiMr9
Gixh8oLry1kTFQHitUyw1LSQo3ow5Xlip+9gOEMs7IXJa01AnMKRCEF8aszEJ67tnDEEHxw8WsL2
G2K35XG2h1YudPGS7KCkps+xzcFDXxaTgSHTbdxypHEMCEwG2zC9+UU1kOBACDQc3AyRuPnXijFV
eEudfxJGi9rYk0TwhK8CPxMJ/a+CODpU9n4UXy7WZMtiUA4J0wLvXkW2fRzqVyvTvLynLL1aFRGf
J787eYWohtMXaz8JggH50X/FXR/XC5QbnbyJR0LQmrUXLqgllbSfVSNkZ2UXBuUph1ican+8YyO6
86s0wojdSwAUEANVqSry6VH6iBM7pOSdSug5c0jfeofLtCFgLBAq6OdSE3mKrVVc9ZcHkNWXKSDI
p5puCxNTjBw5Zyvep3mEAA3dR24aDR5UnjF6Q5QmIlJjr6gAHk2hihdbObcEGXf41ppYrRVHMJ1b
i6ZuyOs8eI9D7t8oCIm6Wm4JYzhXzU7py0rnXC6nPHWiMdCi9JAAtnLC4xnVX8M4tQtyfwnsjMQH
BrZCz5mzc1ZO50TnZ+CRULDqg0nCAwjPbj/X7cXcE+5nT16vV9oagpDRCtgIrprrqkuO4RD5iDgn
cv3UxrPNwTR3RF9nCKs9yKOFm2UULXByBthQABs+Op6O8xFjmU65f/4a6FEghiN/JVRWtWG2EZbK
2SY7DZA5qiv5vAn8rEzV0anl/hJ0enKPBw3zwDQ1xuO4Y9WSUj6cW6wG8n62KCPIrEMYwtGU+ThI
0v61qsaeZSPcEZwVMQrZZhmyhLpsnJseQsS8rBi6d4SNVfX7ncfQuc1/r9U+TO4sEBfCGfSmdjD5
VrB6jvRZSHZRDfZ3bkVxtLgTR77Z6KK0QAWWOOeTUbYyZIBdLRH8H8cKa6xf4yAp2vKCvIXWJUrz
7t5dEf8Pk4Mpy7ATfOiBcAh+UIU17B72hNZht2uIZ3vzMaSMvcV0az6cl797G/dHYOcvGtwKzguf
acftyUMpncm4xXZ8Osei0tKpwibexwvBnJS4iJurA+uRqP5C6lWsVjUTU6LrOYOCv8XihlWfvLGn
4nuaek84M0dq/Mz9jNV7G9Lfmmd9MxADBFCCL9J1nRn4WVCjHweX+tWRt9ABfIIFPc0U+QaupS+a
/iTLZr7ot5eYUOgUUz6Er0XFfcjSmwAir6XQdLOFWJ3JUTijx+59jgbApPZflSpSv+0iJygyWlpg
Ia3ntPVQ7Kco8xVtvRaWhqHXjNQpn+PjSFY8Hw5G0Y8iNnjCiHl0H0B6emGdrt9v8RCryIwtzGkQ
iC4GCa/+74Jt6aprg9oR2tq5a1qYYvP6w4jVMEEp6qIHkCBKtDzx1bI8nr1GIPewiTkI+DpGk4XE
BEO2XHzhzlcAX5Z2c7xgy376DQoJYaeOdDA4qQKEVKKkkXKqVDoWzPz9rd8yolwEkbxU6funeZwj
Um1/a+m1IvJ8vRqA/xRZ2m701IN7Om0x9+A6aAL4iSp4L7Y0vRW42Fc/mOwS0k7pELo343UCRpNc
pw42u+ozGxlSt8HxOzfAwK1XwUTJSV4S4aGw/AW4UiaPn622YUcBzutyIs+mAtMMAr/BlLexUlyQ
ppL/ckVGUlEb2n6rwzb6pV0zR5oT7DObBBJxV/Sjoha6VH75fMhjZj/HDdyGbicAntjt+yZvx7Sv
dDMk8hhzSQ6mHfp9Dy2KOwI9GgPwoj1f/hrIe0GCZ3n3Z92tbdJhhqr7NtiVe34crDilehkFWOId
+E4eteKki9tJmPkp5uUjYQx9Vl9gsiOUG1lm8vLHIHfTt1+3U+5cHzafSzzDokg+12QZhhdURcfJ
z1PZXpup5gb6eUxelA3aXBriLcSt2vsmlHtwg3+Elmyw0t7Ob5YeBflWe9B2DVrWf3Ih7vvXDx5A
crrkhor+skwv7nb3OxQ3aYDadLqbuSqqnGLnY30LNfXKF043VsjzMviGoTsbiH95eFZErUPGlFFK
A5OS5Li0lRYyCE4pNlR1fqUAWvhILD3PoxI/ZVUOyOEhXHwcuuZUfj4eBYQHN+Kr+19LCCg3bFXU
DI7d/+MNyGM1v+Ww4qOC00Tl1zs+Cl/am0/a4h2H5TfM+OrVblfdmjZvs75M6TwCp+CiEMcazhGS
wnHXy7X+ucB/vFqA98A7OA8rfImEIr6MPLXy79I3B/vCMmvLevBnlu0l9+/wQaCSBzGOeXXJepw6
Yy3FTBIJHw32Sguv5VLgk0QdVoq8Lkj35t9tedjdeXk+nDxzOh6xU/cbNFU7IsBKEEMD/vIEmf8g
TFYc1I3DHYF5ES11IDeDTN8sS+C6U10Ew9tOPLXvY1Aow7W8WmdcEJnva13vfgJTMFyXB00mIOus
LeMUHyBbwAz9RLisRAznkbZGCz9tUQzcQ+6NKq6EDvSZP8M2sK5lhTDPcmh05tw0FgsN87uN7Z/Z
hVoM2kH5uFnNpW0is2wwLSIbJ3G3flqEkmBSQdeUTlA9mbmeK/9vc/b2Lf3iiu0D7Y/e+WkvVhbR
2NBVsG//u0MCtT4MB8zJFl8L0Y5XeVk7jpUYFT9kmP3vs57tEximz2wuMAZKhvxf39Y3thocZINb
cr33ipmbofpbNKz6Ld8RiJ4sjph5Wm7J5L9TmrXJL9A5M+FPbg0iTpMl8LjVMNZevb8oDWmbLGvk
M6HWieEFNajJt+M2qC4JY1rYZea342zPXVjrnXARua7K/7IqQiqjOHEiw9xqJiMki5K+vBDH2J5z
xEIlga8lEi8t5D8ezZcokz6nhfqUrYvSRkLmw3YKWR9BB3uy4ngHekoA3/d1wGFCpVL8A/cvUuj/
0hze66L4/LAFZOSz4JpqKlC3URrLQvjqEeBT1jHnqTIy+rw9OjxezqfLP02alkPc6HGxa8EW2o/a
Y43Xu3dBCC0hGr+Lh994vSQWOX1ZMx2v2xKvlggpLfLg5jOo02FXZJUtCNNr3nPC56MrsUSv0d3X
jClgr7ELE2Wa39Igp2cjLckghQ5I1tPwFoRL9W+Tg4wxWccvuJQgADfP+/FRei45LaLGWVqPWpNw
m1jFJCB7f8/I7SOhdnqIFcZWBugLOIhSq53bPsos8sKmx6HETupzjiQJ6vW//7suygIUv4D/nMmG
iRyWvXhDmugApnvPAZbifxxGL0pVdL075dESYULSEGiSPjeX5Q2bq0x/HKJGKPDs7hSILAw5JVUZ
W+2aB4r0ZM7YnR0G1KHtkPrsTr2Bj7YjgYg+7jgFTOP6xYi2B6DpsudJUxGhKftVSuTkYEMwVRNz
xsyxbhsNkb8/Y3Qf3q12vahljZFn/KTJsUuPR0c++fS5CR+mhs+1GAu0Yy578EaBfMNdK679mjpg
B9vB5beKtXVVLrctodtT2ywww0XJz6nl5dwiAZAhbDc1b6BReQ4YowlpUyCpBj3q0wBxM9aPf/fj
+/iIdqor4xmWVKRjbDGu10fzokFMCfLDBd8PGv9guEjFBH3eXvWAHk0xqKVAx9RLxMcyQfc5p6fO
cyUJN6G7FRPpcsyox76TV24mK4J8vfqq5uQs95HL8smtGpKyuSaC/ci1sfeaN61gORS8c19TpjFq
tFxyqjXAbwPb6EgLQtW/UfM3lj6Wq94Js9QCsjUPRbmDOFdCz0irRya/8XnQTkSiZggnGvaYVvF1
q4tBBhcb6MeMN41GePzYOJVwkj0mNYD4pwWQq9nDgwyg/FoIHACDXJ0ceM++sm6s+7Ajd6ZvAgNm
CZlclg+yfxC1oHK0Jnoy4Ure/qyLgwAlNA7v6tn32YHzkF+vNFLRcipvDrBSKExAmiskUuyrpt6H
PGmE2Rc0QLHx6RY/uIpabOwbCBCR3kY6FvAsXoqjyUPBWUc2AohjPpLfY0+BQKFIEGMODzBHuyo3
QkoJROdwUHaVCvSGw/7Ai/2BBJxzVfAz7Dda4zFdgSXPazwTgXsdsj12LJXE110aYTs5wXhZvfOu
j/eJleok+AYcIrwsrOURyJlZjse3EeKDk1oxq+nxzvL7ymO45a2WGrSEHG4QlhqWiVMTAixWlXWW
mqj7mqmYFvkwImMxSYW8l57DRpWLkrBtaPr/yUq7K7DdARk48y8+6jEHycfFbI2Vy1wgArktwaQD
g1nZt4K7/H25gW+hUB9lskRw5Af8rLYS0ngx1Lgqd3B827e+HgfA+w3n00akx5vKSktF2HJuNxDP
K82+z1U7Eq6D4fPzACZKpdZWX3eqNcZUD4gSMcov5KRbALgXvnLB5aVB8Vz8TuwEMRvtC1St0/Qy
CFYCc0/rECePvEAYK6cn3vgCONUPaWsHrPaRwwk2Dhamru1A17KMnWH5Lj4yukEXAglm29pUJ2IQ
4V3/mCDnRzXq6kPDsFz5excLvXmIN3KtmLB33YyPi6nqmiF/ZE7DIqKt4D0xgYy1Mic6Rz6yOm9L
iftN7cpehg2ySnmwexCU777JIZgB5rIrttzcoQhyrkoYkdaHHAh8ZCN+klaCcKpinoImFK+rPSIq
FJQ1r7GjNpZw8ZWe4kQmOMuZ7ceikvatOeG9+2tBC0W0LNNg2H+cGCKqjzf3nIFpXXJeWf0lRl5F
8fMHkN20KKlo+jyBMBWNcxbxhZNMFKttaHkZY4Cr8HzxOA1v3fmNV1zYpFIvDeYClpgqGQMqbgBz
KIIP9sCfJsRdgBbG/lSFbAfDHeRKrkAXJP3fpZ8Hah7Qx7Qfe7v1Gi1TX5XjShpZOtLuT7en3zpK
+vM5ZCKMBckbsGEE8ZLKL29jiLM09UJHa1T2A8N0n0bn4gTAZyNisvCWRAJo/PIgpSqPzCq1oSLi
JLxZRZjYK+4+D5QAmuAgiCITmRVV51hBzedrd9uMSpG4gVPT23/bdRxidgYjt2OcTaWekJUI+qqz
05xOEAuT8chKmeiAh9/Un3v2iSeGLfVQDnLaP/00vkonih+cJsNd0RbzKqXJWLF0NFHT472qQ804
tgdXN2r1WkveJqA0o3Bm1ofnuBmrYNvAryEum2gjfZXfyQNP37wmb641gG45oqsPikWk88fYAOse
pTiEJkYoDeGCwjhjBf2se6BCeOHYaoZSMgA/jXg0OJpoUahRn4xdGIHQ0uimac0Xx0YkMRL2j3C9
EgEwlZDLQnOGNPUnpAEDVFZE4ot+3yyt5WuBynZOqDHk3U5u6oF3PyW72dncteuz8AXE2ragpOnP
Z7y4wrMig4luVVZGLhaWGJP8EAWRTAlxEcOqdtff95VqbTdYllfOfzKmlgkHpXV0FtSLj5OQeE6C
wZqciX8jMIlyTXZqADJ8xCmedo0YsmfOwwH/X3KNq27V0QZ29QwvbRu5gDmqlx+BdYESbI2Q4ip8
XSv6aEYNZW5kc3RyZWFtDWVuZG9iag0xMTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50
IDI4OCAwIFIgDS9SZXNvdXJjZXMgMTE5IDAgUiANL0NvbnRlbnRzIDEyMCAwIFIgDS9Bbm5vdHMg
WyAxMTggMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx
MiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExOCAwIG9iag08PCANL0Rlc3QgWyAxOTUg
MCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgOTAgMTcw
IDEzNSAxODQgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1l
bmRvYmoNMTE5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0Yx
MiAyMTYgMCBSIC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYgMCBSIC9UVDggMzA4
IDAgUiANL1RUMTAgMjExIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4gDS9D
b2xvclNwYWNlIDw8IC9DczUgMzAwIDAgUiA+PiANPj4gDWVuZG9iag0xMjAgMCBvYmoNPDwgL0xl
bmd0aCA2ODU3ID4+IA1zdHJlYW0NCkVoGibYyt4SqE/SrSTboHchkt7RHT1WL4s95wFIJIdhQzud
P/RtuM5px7HHPEKjCEX77e4jMeNFKzo4snceofOuJvUmcHJ/oEhIfr3+kU8dn6Cb22gWjb2ezEL0
fUoopIFUh6gzMmiks5a4k+f1KnA3gvPUDlIEaDGO5R46eMTNtmYKjThWcIYJValLD7sBj4l0Fyvy
YxMXdaOBX7hDFT24g5JBOul4oZ6pjxNOHKN1MSVoJ5uRjFVjPwL2KSIymmyYirHCNVKILp0bivoa
WuTpsNdr6M4/5a0RN3VvbFr1pKX3fjrg1ily1Fha+phjbT6EEParrwfWAF4n5n8xIhhU5FBt5hWk
bElVTPKEO6UtE3ZSnBC/r25yWz5nW4NT7BZexVq/IhV2VJa4gDffoxCRiTd5D55uZZ2DbrHY1sPO
cBsH5YBd5YXi929hAwmMiCsNRt3wbLP7TJ9TXUQoFLNplITNb2ytszSoHclDT4JcPRiiEpqVnGqv
0gXmBTQaOAMnJR0VTHMm9lvUsgWUbGnMXS7xmp82SBII2VepSI55hW0ZX0/NMdmx8szYLqgpddGc
9JTZORoX1e3m/Jh0bNetht6ZakMeMslaE30Q3fXtjEj9Ox1MQ7mgKd3XTQx1MRqBxASuOxkh/UoY
0vtm6Fr4TccrPM544Mg0JyRqRiRfuTy7FH1gEHsm88vXY5/2nyq03jie+OSsoB6CG1yfN9h7y2ZO
T0ns07YzSzVD5vkHkSFBlJat4fIkithwAdpVaTREu30yIVqKf9MiVQLqtwO1SOR/2EJ8AFdsCGrd
Oc/D8mmX5PmyV6JXZDQ/9k2csJAf4YYUmZPey7ScL94eGzim68o9aw6IFgq26aD044thc4CEfOka
7/bQF1cnwF7PKvmd1rglzw1eT+y1/gkkJb90HJxPFR6dj4EGGtkxrzQETDNVmzLZ0jD8yWPqg0Dt
soMZ2myXWDHmN7FnF0IcmW2ei7zdQLSPGDnAVMrOKIvRr5kkJIIW5LUED4zSmmE8siUgxEASMeZj
Vs0O6GHy7SuzxP+2T1eD4QjHTEKlwh7l8mneSoHo8wuPhUbtmvmwGvTDqeF7jPEUt2ze5U9zAu/u
Dx1tYBjuy4rhL2/EjuAj6wihzTsFiJBJgUnVCr+//KZjBj96v2JUeMP+30l+Y3r05V39JOxzHkgJ
XBR10X+5c6B+D3Vpofsk+EeSINQM+tTdLo7oZwqp19falxeFMLTMjiexAREvHnf8NQhei74DT4Pq
SNlni2S4n2fjBt9MZQ49bFSsGvjCyJkClLbsAurpbJi4kfcPAeWWDO1Or3plzX+baxvMCX5KV5aV
ZsIwUXYcCXHXdGorocuYz2nI6HV4ThhkHEGxMolYyUbtW7BnJoSR6KWIe6ObX30kfdwThfw119vQ
Bb0ngawZnhwvPd/m+FGsuMIxSX4+w58mIdErzYrV6V8TxZIDZ3Sh1fBj5dnVeM+u9rdduinkt0S0
pKpUksNRR09CLogXtmOUqdlM0hj1MBONjT7AMbnJpju9iXyYhKBm4Q0D4h2emtg6j7AtksSuxH+7
6/GnBK3LqfGkzJ0ZLnUiX81+OldIUNM4aRFMiQhDHZsue8+rJITP2I1aZp7zMLxRdaed80n5uupv
egHhqG92HVBEqV8kT+c1D06XpXNL3jt0wwQxKg8II0fxYIz5BwJkVs5i6Z+uIeI9mKbIRYWbE0Un
yGxddq3pJbidsnGfP5SmDx9bk8KOUliZT4cbBJ9jhMK0+byViuKeuUfiplsF7fpeWE8ibKdmThKg
Zwpcr5yqgVuEgonVLaOz8KWpwEQ8lwG9OlexJhPZg4kVSCM9Nl0XtJbeuhPmkPNi7UoOqy5JYuRo
tLqHeU0RmSVfrT9jPlW5nrZ9og5lVEG2bMklpjwbYIyeWSoTJjq7Esn+0wwMy1cvHGFdwMprfVyo
DkP5+YusEDkx7dgknmQdSJasbMJI0/np28UgrbzKcNIFS0P46SJ3ebBi64tZjx0sVqO3EcogEz1h
QA3/dcfCW/+K1gr1dOElnH9Ud1Xev8bg+VagpyysqmlxTchPJqUS5auotFBfNyRFpBsCqDFq9vo1
aIcXWkeuetlSMcelfX9jXclbyXs14qillthrDgAUcRR41RnSIQpKsM+EdRUk+7NIjLLZtoqJbDoR
415bLvB/I4YhKWLlxIMM+S0zSGQxYUorKHvj0Ce63RUL+0X0EHNtY3+1kUJ4dax7Vxy5eZxp7v/d
IFVvnpyYdcYyqMuikQEhc/J0IAiuOdG1KcZKT38bgXwXoBLhDhrJ/HGy/NteOxzpniKZHgQcPVfm
AfWLrW01L5avpT09mscL3x9pLERAUDdWkqUVy1eqkGwHZSnUxoKMSk7gtROn0vBjlGMPmXuW/NXy
vTExKn89zBlNWVAxYl1kUBQsFmJvDiNy2FQVdT5s4ACVEokNrf0dxm+UXYlw2ExwoyXMePIxUZdZ
XdqTIMcv8GwEdT2Fp6XHqvemppSOi+R2fFBgtqVM1zmtZiAaAsU7NyrT8cs4+Uggb0+yGuXmIGGy
bEiQNUyAf4mBhsHoXnl8SJu61ZY/6mQqJyd9axZOCTOf1e0U5ilXBN0lfU/pKemBOjUQ7Mnaz0rL
nh+ZOIYshqzwtkcBQKfmNWQOqSFJcpWAvz7ofuzLAkjhloZSfbGN3hq4OSHS+LAk4tJeq4VS7xYB
VfmAH0jEK0D5zkNm1qB9yfl6DhO/6bY23l886OfWAY3srJjOCsk7NQ25KuIf7UmPdIIqE09jS9bu
Sik1OowiiHHBNQLgA8Al9fs9Bb05Z0u/Oj0lkjgUzHY2ZAKp58BHaqAx3lj8Y4cj+9ORN6NpTh7n
iQ6FUUoUh2nHisC/t/jI74ECy+I3IbtmlnSvvfuIfhS2Z6/nwydAeEShVmB8l22lTzWcaSzTkUX+
UK2HcVcQ2Ry2Yzeqqpl57BE9vLBfVTvzSg6kSFfK7Tan7lHFQUHS5JQPTPjPYbqjyimf9TRCN8bl
RtcvXAx3/L/Wl8eNXSCdGrUL0XHG6PUmCpxHJO/2ol08iFsaHHBiZ+fOEuYY2YjEkY+8u1nj7yho
DmDZQB655Ps4lolaEmnRtOO6cGGBW5YWZePVtLbdabMRRkmMEBa6/zwD3G7OX6a9TFrFpNOtXAcf
5Z5lQcpqrDRRoBTsiC2RRO9VFVyeiHZRlrWy0LYPKaEyCvsTey7xY4U00lvW2xeUvM7wuNcb2SuW
rPqOC4/nArxZRvrWzXxfx5WYMEToMBN0W7h3TIoTdz61L9iOj86JV5yJ1k3f/DB49BskEBEQW2A1
5dho3b0N7BjuJ5Lcct2CSyhorFpG9JECVfD/Nsj6lqvAbkN3XITTHTVIS4RTHchdhY3CMVDaS3c6
gdPnfA2RvZHTXq4ZQhTiShexcTcMK2gjAaIMTqJe35Bz+Tt98jLeMbfp7qLUinHQ54TpO4NkwEQs
daU9j1uw5RSE5iwqIydDRHDAv+n//tyZovIVtR+6AzD7I7zceX69K7yi6iGlKfuwzQGU607vU6Lx
QxsbLETSxbNCwRHiz+dqNQtrJ1j7aA7Q2mn7v28DLjX3olvEdkvE2u/VAv/xF2RPmmOBDQ0K29fX
vkd4UiHW00ktIsZ9Vzq/jojXh70/WsSJ42E47Z2pspE4jXcowGUDs0TkRAIq0nNVxpoXOt6X/xxL
MHTG4qRSMQ/QFzaBulsdtyvj5f1OQE1SfpG669UpC78BTFYWBAIAOD2VBBohaxSnBNOAgGrghtEi
zSD9dYxRm1OI9jK08bgh9r16UamHUudQXS3q6eycovUiHVrFAHGBfpAuCKaNXgNw3sH4D2uAAUqS
Ug9nzu7/fjmk9ZQ4Vti7i0KXBRlIT8KdmHw3lV3cWUDiizFb39uflwV87Rn6zNFhPY0CZlj9+Haa
RzK2RFKYzwsHIGeWgtm3d51JJZSZv+yd9OLxqOH0ccou/ei9rOWKMJHw/VMeTtYAiwp4LJQhL0LH
xeYNh7HAWATSPoQ8JKd3jwd9wiPA2NE1jUJNsztorjzsLOzKlA0VjCSAgGOB4gqyc7LB0GX6XrJI
gYx5a2Ex/AsxscejftfBIS+FiTtS/gPslBWRBK2kiXUeveBD2Lt7akGAihaKlQDAUQ89Q40wJmL+
3w9/LRi69mdgPXO+VxVywx+wpmc7NGoq5br27l+2LBeL8qZ9NpwFYaWvFu7hFTIup1s9E8MqZqPj
iV7ZBGfagJXioE+IMhMtTaJ7CYVpiS6FNoDJSolu0RqfRJb/VFzNNEiMbHWucxtW4ndX863xzpth
7AJnLdjof2a89URr/w45iPJRnAiQPOzBYPekMus2qyB8z00fDWGDRqCvaVFQ/7z75q8UQg/gj3BI
1bevp/WAY/a/ndncISk9p5mQr6OJkrWKZbPQfTZt1KDix3XiQ9PpBxVG62tmifwORt+L+XK5ftWW
0z0frghF4A9zLdrsy36OJthkhlMbPTEsWs6Yxy2fgstzEa20ZqaNIsS+VX7qXwujFZI3w9eVcoSi
KqYKIn9N4o04JQU3sk0Hf8BvNVP+hTjECWKyp+B8HRN/GxL1dv6Y0TIdbJLKzOBZN/xyEgngVvYk
/zNhyvVwM3VZQv5r6wRlvM3ULwTkU6tfgcuHxtvuwnp4gtOUjgzsSF9STCFveGZsduGCm1myKkVG
NSF0agb5st+1QIiRbIMUfYKH+DADTKbkwsaiAQTitDJEhwLnmw2IrfTCUsTPEvgORde1+mdq+elU
zt4wvd1LzVfCBUKN9yKY5wP7q3C07E8w3xYzTip7GeSJBSfBIviA6OsrfK2aUIIQyL2lqfHcrfnC
Un2PGOrIvrSLPD/mF8VtxI6yBSLLSw7pj5vkZXctNaYdgZ4mtQrG1IjprufHKE+Y7mYI4SjxQ/vE
Pgl08Yfw5N9JDMqNc4spX5Tk61vArAeOrK30G5afoeBb3L04MZI9dm7B1ncl1YdXrGdKlHoQ+54s
G0UVNmsQjVDGwk+mzxp/J9KX1Q+SiHZwxRhERCi3YRxvoqNZdaQqC93il39wn+RCGLw2HQc1/mC4
5sKs431TZa7v5MFguIZRk+4XwoxMtM6xs+0Ime79UWNy+FWYN9ZZ6gTbXNkNoTfNucf+BO6u/NSz
DxpozL/qKZVzdsZytfdHxt724l+V6h9DIMvo8uCQ7x1aHM8NPakRAnxpFJsG7LzcEoJztCCTRoWC
1aFXV5rOZrFQgZGXaS48u3Sujx7FmZ6kSlSoaSz3D+cAFb+38ve2GSXrUn9NpRV53eU9x7uuK72m
/q2FkhGRgzFMwhpvZxCeujTcjjgBU4437W4GvCO7+B3/Lb+Czxm/2fY+ShFIOhZucchdGZBlvtUd
FO2mOdVmxPwxFl4+SxczjanzZrbp7406jrK9TQTgtImddawLU65qsMCmBbvNXALk6clKm6W2LMRN
7vn+fgq3RmyJB5VN+6XSB1ZF5Pu/XXVqDogX+AxWGCj1KA2Rpmerp1ZBmE8Uh4U+DuWziJYkp2+Z
NtNKD9wU899pWTCT1rSKwzsvdYVWmC92AgLX/1dw9xtSh2Vs0ka/miiZvVjo5njr/PiMyYBJ1xnX
ibt0K2nZR3T3gFSvGX9YKhAWM0ZglrR4Owtc/y9wKBYpdk/I+vluIUH2MoU4ii+19LWzkOdaGT7d
53wuN0t3nZzBZSpuAhPavCNds8J+66cKpzhjIRJhFqpJP6RkC6bcMMKz8xjO9e0RpHnaASF4r7CB
SSr+5ZHNMQwyQ51HDLVhCBGREYjVeuISpfqVUY21YWGh318IMb7AUkjg7EHMVqYV/i9GagKXe681
zC4qK6gPdSAmO8qIZ0EKijJMBCW/yhDbA7amWd0Njl1+kyEVpRTLDtP2769hblI3sIpAvAavSfpD
fmTQG+y9LNbSbXsc0/ip3DgKUyD5gCwo/BD3ZPygang/yM1UWFNRSywTSBNrmCOwtmOI0iAnp1A3
G0wIJIMuJ81G2X8uaKuP6nSmbAXN9EUTqbb0rtXWXxs8NT0I9UZLE5drLCuJ2yvSdNiYmjz/zccA
8WEloizq7nRdQ9xdK+wQvOnyE8iFNTj+t3L7+ZEBLP0GnoNMHSC/1rI1/zGZjCJi42ygsnoFlgLN
RGbaJwEpoDTZgW6qiK26x3F+WWvFAS2f/JFO7JRJc4pBskI1NBT6zP7JyRWaksF99J65BmWtleo0
MkjlJPRFAHdUnNS9SE+/0tkwbauSbPNpbd2wZ8RkscB1cKTo9rJlG2ATuDVKmRRD0QxF+bXgr+cx
P1dNpkpJqJMstklLyUfHRvTTpDJT9SeSWScJrOXYAx/9cw48/Vekh5TaCTknF0l83t7UIcxMQFbS
mmndOhzKaINtO94IYKt36nJgUBzcqWMkiqVm2Tjn4C+ld8JDZrJYCob/2tVYCuvpdONP8EoJ+J18
/J7+w4qrECYuUfCiMDMot6MwYh5myT7/fpqx/lBm/0R5VNaARPqDn0nE5cpvJ2MBZ3DS2x2EBbZt
Xr+KYAevjuNgEuhL/ZRorHjB7tIWL9GDDLJld8EoUazKUDGDhKaU0SyMlpSVlvHZMp02E7ig//Ub
aN1gACR8Wsg8w5b0NmRCFDZ1Fb2ywQm3Yr4u0V8J9LsIQ4fG4SdUfxkoAOc/EydAx2hZtOnIe+Gf
wIa0AX+Cg6G6I06zhCiB1bMiWkxmQb4gI58amwnwUWtb/vOjMXM0ZLP4su83QdaRXY5mhsU6Jx+d
9z+nekAsAxE5KpVzihH4QJDc5qSdODxMJHw73JhRTzhOqgc/HKDjXqkUkc7RVQ+3M9VMOCU2ujqd
7gkVxcQh49ZacDa7PnjbFo+9eQ1TTW/m79HyXR4xqEJ5Z9aB5DUcJmlGufBuHNUI52nlw1b8rYBM
eHT+nmie1eb7Ay36ZlEHs9/TfvraHumV6FUW5sYDiVZPItcqlxedKVe0yDiX6sNmSXKREgD/Hyzh
SAB2K61SvKtk+uxucmbDmpm5CXjuRVunXaEwcn+03gAnKn+tggSLmpk7gvVaRps0tk5Xd4mMIrFT
tmNdYgb3Kz/cZz8p2cy+MDnsx4k4QB6gWaxwpLVkSXvlcNg4wmBlquiir+z6AlovMRe55zREAE9c
RcEgu6EH3X3XPqnPsyFcS9idA48e0GQsLpcXix2/mf23CX4D5R3lmtSj5Jq8Zfvf3Sz7M906jUZU
C3ZmGx1aVXp45Oyqa8djP12P2kJolz3ztJV9zdJtkRPYesDBrzDP5vxs2+S1SSorGRoGTCpBqlUF
Vljlymb5IvK+LSWQLL8X58S0IP/JJrCf7DUIn2u7jQZVVNqwqrKEYzkgUvnE9yGNuyZiDJyFHOJn
1fARu6EboKDG/w3ZuC28Q+ZjEXVM8abg20QAZmXeg3FStdRtQAfO4RZbBEn6vZEkwk+U2E61RYHF
MrIfI+jC3ncaT5IU7+WKdfPFHZ2dr6UiQhh079QCkh8x9WWTeUrCxEz5ijhTtnMD0bBRl6LBZIbk
gWjGIWRAVpDH6El47q0hTa0PX/ejZ++S7ArJQJey6Xw6iC+DCDH1/jyMMv612vUdvYgXYT9GlCy3
v5kcNbm68rGOV9j/j2G5sIa1PHSnlZmO36H7ODtyuT73oOFaa3nHNGAjy5Dy/t9bSorCceMzkN3l
zP7g5PJOWBL6fQu9mvaGBC+SyJsDOaSJtukPLNEUCUf0+mtZ+4o2RQXjH3ycUlGWx3JVdx0Bz91o
iawhRbHDB1PRL9skoF7DpiJOrWF67ramjTzPwE7m0YlU5izlWNnVbsAfHvNxK7fQuWIpLSVXR4T5
J16rOmUmzCto413pWeFlq5bWTLCZ3+CJJT2TTqP8R779INiEf7j9Jdo0AzPsM8DbK7mLSrr1d6K1
vgtXFJ2Kw+qfbraZ7hadb3BkWemL/reI9arJfxFQGjQR4OZrhcbZiQlFZKBTYFRlER+mPum0YYdC
JBL/ZaIEAs3d7krU1KERPDrv4E7tu5S1UQMST7YAiVwmb4Pd83DphMOffTYmIypxIJWgfmx+DcSp
DlppwxJM3S4P6MqNY/SM8qRQNRmknpQOxij7bOKcPaPb7+qq6nQJw6J3mLHUl/DjeAeSFuw6pNod
f6w8VR7K3BjLh87B9jeqF/tCKXWNekuMRGJHPhMq4UQ4Og6rUSx5H//GN/98jw1hCXr81cw2dk3W
JqfsqK5BWLej0jRM4tlMoOw8Kuvh82+ZX2wAQh2IaE+B4XWQ9a7IjxHFvLiLfmg883YUD8ufwBiP
hYJoSAAt1WwwaEMHjv+hrDXZgTShU55Y9wJArL7sUyJVtsksfujnc13imfle9zbUl92JwZNoq2UH
TRtlt4Vi9jfXhuqcAUGDZuFwYD26JQnElk5IGcXhxCGDZfWAjHAvoOTsghLGBy2Ck9GD/okywgqB
pYnD0HqVWbWbiaeXM++ZDF9Nr9561D0xZRNFE8K514zCEKKDvXP0DTQTz+RfwIelYhIFD1De94dQ
TV27JO69o31gINiLo9V7Xp1nj69RyFBzB/Mrj6ssq0s0HzIfu9PTLCw4HSsT32kiMmwePcI+ntTs
4B3RW9qErw/7N/PECIjVS2+z26CKcYr0VzibFX9+da2ubr1Z7taJip3q80GGN7k9Hj7Wiimvzntl
F3mDi4C3CugNEkvRqZsh/9xTA8ta8v9Oc0wfaZsLyf44gGzFJQStwr4UHAUWGDZ3nnMk/fd69oCh
9HsXMIKqXuCriRg7qwD1/kCy7ty8lQ+9kXSfxu1rNi3B5stJ/7qTf7k5yH0/kajRR5B4hc7SQeu7
pasb+8EgW0jiW0BGSt8Zf1D4/jk8zcB5v8R868a2INie+MEPGn6MtAK2j6R/dAcV09cm3tFNNx+f
/CM5xNHH9q5ESQpfVeC3RVn/+aIU6YV1PebhWzJk5mFZcY5Ii0VKGq4fz00utZQZnrSxLGFGmgQy
gTk7wx11QxH6Xi0myVYgQxY/NMjI5csT6z3O3A7Ek97iXznUZzrq5uDnU5PuvJfyQj4k4UudRn+y
yJq3dZirp3edAjbPdx7f0DeWiVQAeIMV8gWzjvWrq9knGGUu+OC+VGIawOGlHVxuQEvVbSKZxTK+
9c8cWLGLYA1iz7GkTyHf6UckRxIQ6xvvgTfeVxogX0CwIoOmzcMyDWVuZHN0cmVhbQ1lbmRvYmoN
MTIxIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyODggMCBSIA0vUmVzb3VyY2VzIDEy
MyAwIFIgDS9Db250ZW50cyAxMjQgMCBSIA0vQW5ub3RzIFsgMTIyIDAgUiBdIA0vTWVkaWFCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g
DWVuZG9iag0xMjIgMCBvYmoNPDwgDS9EZXN0IFsgMTI1IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5u
b3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDMzNCAyNDEgMzc2IDI1NSBdIA0vQyBbIDAgMCAw
IF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xMjMgMCBvYmoNPDwgDS9Q
cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDI5OCAwIFIgL1RUNCAzMDMgMCBS
IC9UVDYgMzA2IDAgUiAvVFQ4IDMwOCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzMTEgMCBS
ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTI0IDAgb2Jq
DTw8IC9MZW5ndGggNTcxOSA+PiANc3RyZWFtDQrLLOm2mFkIwN2o1LbrF1ZjTEK7I9chh+25Z+x9
KakAqnSIuWfjIuEf4kvoUigu52I5x0sp35Ssgoan5t0W9UItDGD1+kFTgjuA5QuFug2Hi8/k+sdt
wSF6ueKoJP393fvEJYvZBUeioJy3WsLf0Xqpw9aikL2jfLtxwvCiebvFbWR88YKJB3j8Rr3d3BC6
/xCEvK6mYP2+k0nUwxXZ3yjc+8jL44Q731TtcbeDWt2i/jlpd0i2WgF2UkxWw87gaNMlwYQb8yC2
hMU407GoilR2B6Uz0Onh/QeawosmlQ+SMzO2zI4doWjOe81hvhBCrJGNy7kJ3o/eQUpBCBmnRaBC
h1be6d1RkGNWOXTpXq6evztw73ekxvBH6gDqWK5P6+cz50Ums+iDBOzFOsHgz+l0pAUNtKQC1uPH
4c+8XXZCi28oF2EJ/f1FjVjmZD8DYfalo8oTzECJVs8Xd3QPbUKcQimEVM1QjGdrcn6grx4HK7dg
JEMCcYrAaJkv6kHWDqfshoOTARGS+R7Kp7tqiIsg1c2XN2vEobjSXf610DmbV+7MlUfy34B0qIwH
vVcj2j64PnHW+8Uv2IqVzfnl4Sww2B+Axzgs7qxXF1jLGo9lW5yYkCyjGwEWXR4fJzEK4HmE5uP4
zvdNdRLyr0blwcCKHtgzmRf4Cy6u+RnSoqyH9ZrMYehEmQ4dTsLRIQDP/mHgWWQ2XmFjoCY1tGW/
AZu4DtY4RzqoN1Qol4n9+k9cPBuljU5W2HhMyGUjdxyckK7AGKxOSqPHzwKXco8QO6aWYjzImUT+
0J8mkLwNL2FFBjv0/JB4npPhIZzJ0VnvMY5OAFXUIAnrKeMZrkO73jPO2l/iZBeQ/K+eCKol7Y9b
3CB0+Cz3Jw5BLlYFiIfHWYilsdAdCAJpY3KYixETdfCj4NR3HNjB2GhuRKP+iAnaK33L31izDwOo
6utkEViNnSVq85X2IsYXjNDMBK0HrQqLsPbtR3sa6yEx2V4W7O1hL2Pvpdn2Ox4LlcOj0e6JmRur
q+WLZhKRSEL5QSkLrbqRFRgmQ6L/WcXQn5HBAjNY8oO0cZoHqBW9SrX/Q2QtBc1WaZvU5LyK3H86
k5x8x9dEhMkBzEtYItO9S48uF8Pin2FrLX84Var+w4advRpWdi7JJxJ+GJILgbLS6kgkohJLHBzu
vvaSNSg2QuYc3PWhBfdHOAY1Uy+C4mCU6ZvVEsTrxTJzFbzoH1ghFicJCXJkUplq79wWSEb1mcGI
Ro8+LwGRl2AjXaJeaORVX0EPH/nY/Ovd+kziSDZh5EMaVb9jkmXfUn2/7amR4y+cpvN1UZ5jcdn6
6ec+xCL0mthrJg6AS0rubfJQlttffPGaZGXML/30tF9axigZliaVB9Vu6jedVe6tTJfwxEJYksqa
oe6AAfHhB9QvcwQ6HIHaRjvbcrdVgn2sYncrEVIz6pCsiQPg7tCY2Xr+m8cjSJtI9gnMf7ffqmYv
6xiQhNQoz6hOPPZogqTmQYGuuPUix0hOBFViOCdg+ctbVPjkhmkMKIhj5MOjl7M3j/316aurxwua
PVAlypZ4PGfNT+kG5lGHEnhYsNl9WM573/8yBl680EsaoQeiT0FZe6Rzd5vyfxmWUv+edD0kSYb0
Qw2CSG6Tyjn3G8wYejUVGG4n8JjYWLoK+X+OxQCFBmhoryVYTYQAT0DCM0RTXLKxRWahy00zjAV+
PWrMkBRrNcq20RzveD7S52TMYMdFvd5RciLMIlA7lBdXg8aC7s0nijTAKSwniCrNFYqKcVmtl3cU
yUWNa8mc6cK0uVBQaBCgW7vTb2M8eT6IeWkFASaDB6jYrsPf+8YEQTda70Hi72hKfXqXvPzcghoj
N/j5nc44y9p+qHNCIQ3hiVpBs4+OeMeVtVtinLJm3K4IyZxtkSIWAK9tVWX/17FZUiLwV2yHw2jP
WBY0bPzDSz3IAz5grxAC0+TAJt/0EbGa1ngIYK0Kee0PHOIzawWePpqmry8BAosnyfirBnb7LDP6
WQbwN9dEni5Ph/p4ydBnbxuSARIZTriSc35KDtxo0AWvfyCGnBjc/yFKdX7Ppr5sLOYuxi+6rZV0
c8kYjEklfJkmlOwKhAzu7RR98U0f2TCbSSWPa/GIN3YWTonpt2qzc8TZJDPbpiDdLuaPQfGD+J4B
FHO6lsHyFNibbcszCMIiJ89wH4I5NXGat1W7TeXPrwI2Pw8ixIqub82ulNRn9CZyPN2EGOtjg98T
cHMAIPz6t+79ZRUrCrjM+CuZr7rtFuCNphvYkqTSaZ0Mt2EATIS7qXzjUi5Pu6YC3iY1XUqdWanh
rZeWCbg+qxpXtBtuAvjXQQbQUouT7ZerILfTAPSqcHYqTUiTAGyI88aH8P4qaiBjGqIgWI53Fpre
Io49cAxQGx6PMe6zT7VwUYWGPkTx/iPDlJ8384aH7V0bM0ofGf5MB+7jxoSDI93P9dy4gfPwm5yK
2q+AWAccvbageDz2LZTpMEmhBCrEWH2OwHRYCBFpd+z9nYY/8uxHgX6c/kpsGR+kgpCIkpFheOKG
9vSd0ZW4yzv1PiRl5jhVpQsDYBsRMeK9WXmyS3Thh/7Kja/oI1wtVy/SBFf7AzsW4fZBUe+yQJoa
DwTTlvZ8FPbwPuf2CNWLMbP89V6fnWPtx71HMi9dSoLI4jAZVHm5qm6js9mw/0AfhzoSdubbDcz4
AlvdiW+asr9IGBmXzEUt8fwMXDfJgObi9Qaek/mh/wMf1iH0ap0z3J4vzds+Ke8OlYMVA5wzvZbX
pvTsA2G1bHDMCBr0fktPoA8e7SfLHNDzL/5zlhAi0WaHmOdxJIkWO0pG+QcxTEh7m/UYedbp2NhO
6Sy8IbgnLmGhpEGq4DpwSKiKSw0z3H0Pi2uPm2NEY68CJhEczAXsPtsfT5DA25Tn1yoNleVq0e0z
gmre31FuYRf2oKqBCTnVLcHQJQzcQ1fTkPfI7BPXEuiR3IEZH3Ptz0Aenn5G3kIhIszALUkWuQgr
ExbOSs7u32g6BDcEO754d/ENCrto/aAliMQqaTe4NkA3CkXP+JkaTvpdWtQxBdxDtcEJTAleTf3i
omtayIQybuOaIKuuuAO3nohfGjtUbZM5ERdGbFw7onFSNxQS/e3d1uFxEWNBb7LBb+BvvXkCIa9E
jKYh9xxBB8po4IS/ZajUSIlN6N2ArTtwXC3Wd3Iie0BhseO67Ir8j1f1shbGRldBHqNG/XBcPkHx
ihzTfrJ+BK/zH2YdWBhPTbzWOWv8wXLxkK8jtv7sbYps4Rmg2fP0FO5YqbTkvU8p+vtXg6hqXiLm
dtQHOKOysd0j+o2az4az+hHWv3Web1mYWXod7ms/8cRPWhMkkSoObYSAOOIWtGkTh4PUVnhXkdjz
d/Yw1ae8wFPFfHzybG72T8D9j6O/sDF0mhAoMj3/ZZZBvy2q+cBND/2reCrGKZBEIo9R5xcK/0mH
ohCVIDH+O57UqunEUbWCP6lkyM47JLhvXHfbVJWp0hlgeLKAyLT3RPZ6P/FZkIfMcc9GDsra/qiD
KeuR14qCViickak78Dp3FkqcnbSXriOOqqoLkOStVLaHYC1BKu+toSgA+zAdba2Ji3nd3SPQTlOC
ALUfUkFTylyvAo+gkcTdxBH1TXpGPnhUYKFGZ6i/Q3H7MiOJfsiTbDymE8KKQrjFfr0qvRgsWN3l
GEA2t9kFTuFokQ6zcHK00Cmwex8RmLT/scpb7UNAY/GXmvEIOrhocBKKDOe3DY82Vu6JSfIRGjBZ
GdfSLBq7JyhLafb+oqXaqFtsNrfUh0HKkt+eiiAtiIEJIrQGef7ObiC/1BSxdXJjwf1VbFpIQ35e
9ZI3iH7CaIxryO5ggb6c+CEeoSZjPKpIeKex+iXM2XhV/hF9OWPZA5rANowEJ7k2zjYECA0CHeQh
uJZvr4EaIMMCuNr5EaX2VGclZvZxN08U/l77au1FlfTGVjSn/sOFefc6w79RqBWp/3EsbQB8W0ue
ZdtMi4WzwY80wX5h28uJ3YiP1vTTfPWJo7f/j3kLsWWM0lCVbwW3UUCsKp4wmAuV7/Vo0aDVECCP
bunyPOunzGwGSTR/wZ2tVW7Ky0Za+4FX86R0v/zA81E16nBxhdsgeZrumAjmt5SDViYvmw+lKK8q
z0XBrE6/grg6psxyM9K4vG533Q0431PYrOYzAK/flNIeInjiWwqnPvS9Ph/PU/uZ00BlTq80ihh6
Q9P55MB9Zil4KBrZCu6eKOFS0LyZGBnj86J0VRqbPERXWPWjxjysdzj/EjghH2fkB+1nMHaEhbON
rXchWkhw/7aJ3KoZ5eYm5vT6WU7Ykoo09dTHrbkJFq2LmzgYnFW/TISxHPYCbb03fYcecQw1x19q
7xxU+Yjr8C5jMeTYDsWzsR06aIwv7z647MaS0mgbxBHuupjOZ6+/a9Rp8d+Ce6mJyOV2U11Y0Ofn
0NGAYAT6LH6EL3aDEgqZ2dT287UjpmQDWysL9gNu4scg3Sap4i9KnB16PoHticiaiP/fDj9XCgkP
rB746lPWyw598oEbI1wIEbTLxrthrMpJZ6AZiLvgNaMMFbD74Jhc5BMb7FPL6v3RlxNy8oDsLbDA
Ygu3z4zspgePKX1n3Rbfrxgsah/xGYdm/czxbNHA9BNG3VpLNf4EuGi0jJQqDdUyIW5zTzTcRUft
YW/Go590wwoxi4dg1WzSVSeNoG/mplWebV+bQNIFikboqyF3mX6ZoAJPuUflFXaRJz1ucdpfAeeG
vOlp4PRZ4tmX449XTlsp+V4jfaU+Qmp58pPi5k7nBilQLt2HHzItTMHw7v/6Idr1VxkhpNY9fHQ+
jHQR/7yGuBpnxzC62MCz+fkoNGCmhBSS8TCCnGm4oUPlYcfYpbyD2x5fEWuyucOviTffI0zZfzfg
4RuhZhwj4ZIRWGIFQcKdj3GtOH4mB37yCuDe7L4pbgQy/9g+5yi8rtMQe80EbuRT+LMg3aJceGGW
NOHIDT0wVity6ANZNidCQPVzCIparF8DnuWUzmfUipxKRGlD9LPqY+4PaWERrJbXz0Gb1bq0e0Tp
yc6nT/Mv2MODMpp+7BhCzkdSbTH7V/J+lpLhd+km4tx0AC+TaNdDeOBi5DOePWmqOfrqL7pXZZWa
2fRW66izYDA57el1xPm3/n6/gtX8QZu/T7mwxwgNtX4gYuWD8FzJad5lDMBvGwzU8JwZBjNyIXnN
swapKO2izNjU9Nsi4Ntxor1tl6949rcnCzp8WGZM7Kx/0/N2qo1ADIBAOgrS/vVwuLye3p0Yh+Z6
8sNQXI4wp22EhFTThP1WLbP25or3M0JfdUAjCTE9C1kI/mkaHLHUreKsBw1Kz9ts1tgdZS1UR788
2/9HzKhGm5FvvSmnHGz2rH0bf5w35SSN+O+90udbFDDd20/oxBizyH/IoxAOjpBxsf2P+vnjfgWR
Um2pmAgWxS3VUoTkr2u5coC3bB35jDRTfg0zdWtFp7k0i+JACfkZzelDJUsImRxA9CqRsUKYs88h
wb4qXC/pRH7f/YFlBG7QOA3BAiOnei2zwFDU27HKm5XJ2A8v0x2bwhmjFV5XrJ2RWPX8uWcJyzrM
l69A/oKveA/Taq5tLn/ZOkibLESiuBmqzoFBwGMKyoa/uTSwk2Bzd9VwYaGkpmWVsgISdBh5YUU2
OlC+sgHM0ccsGhSJOX9yNNFUAm3c9g5x1HyiSx470KhCnmP/arWfdfahnhbrEDmRi7yGEaPzMZkk
ZFmia0J1qwf5ZKTMA7tFZsyPjLzXrYCKsljLpKlPpADMdlIQ7j8CGlm6Rglebqw+iuv0urFAruSv
dRPtD1e97PYoqYxqW4q5HJEEuu4A8xbSH9f8iRems9yyX1lDclJqY9ucUIqN5LZhojnAB8mZRR4o
vck6ivFCNAqW7yq/Q0Tli5N1/Pw4H820e+tEKiXP0+1Yjscawk+MWMe5F1z/AeqUGBO6l4W0mOA3
wy3Q8IGfJtE72kcKRv828uPsBshRhAXgMbJWSFVwCyum+xQKDUC7b2t54Ib8KCWvgReAzTVDRi39
emPOGsgNDKzG4s2br36Xz2VtoqenzfPcyoLZmyhKJHpHnPu5MrD5uJrrPd1KAZUyAOHg19Ad/lbV
AjkTO2GLNXIsgo77hdnq6efvSAEj/0cdlRelMyTwyAIfLItmiB9KuldHDDlkYhNRPYaYTdLOSYOg
MibPOvkoC+qfFRgtc8BwrvWMeDjWSRUhhE2Vna+udC2xzgfXMokuy2qYDdTEDW4WvcJziakgvFes
aq1Amr0qru9Z93gmUxvVVd5nthuo2bdYQP6LHMg6W9WJ5clQcbwZe4L9891GpE6R4z1N9PLMDxFS
SdPnmG7l/PBtHTXPtnQqVEfOdLjF2fS66oZK04tXORHe2TXsTXok91mCbgkm5iSkA6o9gSdL22pM
uO4nBREc9yBAB53c0A+53cTXlsXw3TvwkQNxUwAZPHfxgkjQIuccanmQDn6NqPwX82u+hzW/HVwX
+/nc082K85uI0yJkO9yYmCnCjEuh6/utqClhNtlCSbnoYncFyJYUoUtxviC7gZQXaNHlASz8zjmF
06BTHZbRQwaNbhiimviOh8su76IwgCK6hR0pGeHaDJ9pYut0h1S19+Md90yNh9z1k3el70gtVgGG
WtqY+i3uF4pbSewD8JOPtDx9j3zCLI/uvdVwsOpXy3T4aOAA2nLuPyCoBu4Qeb5sZMY51eAb91mv
dRhdX4XOiQgLP1IF15lmSe2d4P29rE+tvnykMNtm2vCPzBfVxb0j6eF2AMZG5n+oQo9fQKCTqQP+
cwL56kdZRLQw5rx0LFvI9jb2IZCoX+v8nfWzmPLZzD7xmKjzMbyjNG0s1tmzGKrOv/nVb41dc3hs
QIwX/Yk/5DiEb+g5gmNCYf+JXMakVuFkV9R59LGqZu1yrf0qW9Iog0yLejccLdcqOTDgaYL4ZTtj
z9K8PgpVi5BI/G10A8R9KqYyo0ZoKEgVVr1C1RK2Vvl60NftBArc7tg/6wTex8jKmO1uFUHA7GRl
7GEqCkDfANUuuhJbUz7YruugxbRhtfbPl6tNlJZF7yEu72M5ux4sa71JterqYsT3GuQqJoadbwe0
Oory0AdTcUtOKMbbBfG0SYO4zeWtHJdq63lP8hQttC9LbXdRppGPoc6BObryf2QLIxxUHQyK0Tic
9hrVDWfmuPli3n1FDJ2ETnaavxD47TiUKohaCdseADE5R2Nn05jtVWkJXIWqL7QVV3RIoswfPdoW
27aJhHSsy28VduIVpGIV1AKjBx9ev/Bvu7yA7+Vh9x55Db2216ujaK7OmLws+wUf4ofBQHysdR55
cBT4cWEdmyLgciTMRc9O3e3U8jbji2xF7lg39wh8kzY3feklkJ5d57N/KkqsYK0vLeoJvjBiF+eK
kaajVaA8Y48+T+ddYOEeHZjK7bxLl2VVUj76DyTVsg4Waor5yyhrtcWm/7x/6ReiuUrl9j1YoTJB
szCZVAluVcRRwNCnpbB5DkCfJlfFv8mW0KQhW9Aw14XofqWesp24HxZVDzN7hsiFxLYpd7/YXFnp
oElEo/vlBk4Go1+mR36OFyd4cKtuauQ+BUuHefY7a/s/fnlY6r53ciiZ5YoJ2XPADWVuZHN0cmVh
bQ1lbmRvYmoNMTI1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyODggMCBSIA0vUmVz
b3VyY2VzIDEyNiAwIFIgDS9Db250ZW50cyAxMjcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5
MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMjYg
MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjE0IDIxNyAwIFIg
L1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIgL1RUOCAzMDggMCBSIA0vVFQx
MCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2Ug
PDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTEyNyAwIG9iag08PCAvTGVuZ3RoIDI3NzU4
ID4+IA1zdHJlYW0NCgF0yCoznj/MRyKIRti6BJPQU6I3KtGWYObW7vg7z6aqKYoG5k9MW40y3P9x
3+4H/M1IOYzZp+OonRhp1QE/k4nzB/tNZpQH31Hi94TrwziC7GNaf2fRl7cK9rAyeXeil/QUi7cT
JRYl3Gd3DdCGTjtcaNjKFxKZKPy9ZmwgVyscXX3slgcqVoELK/et2gJAltQOaODo7r5pw8j9jisY
SdBHPltyv4bRyz0b4GY3Ji+Brnm/fJELm1cyFYTWoY3dKkXaRU14sZ9X6UxWIQ7QZ76QkYJGXMME
KSV0J6TFKsfrbrAVYtp/V9LMt81nfUycOQzJDlMTlFOv+Lw/nifdA4fZy/oiDoQe5cLn35ZfZgUF
uZqQjVyEflw+2C8qmKAzEjcQHZZ+NPuY4u+iwarc7meluxRxBM8KGFznbLSfhL9I1Xoa0rw7+H9v
tSk7epqbiIpcPjPGpX/wY+qptPdnKXJZd82MwUcZ/cj3nyY/rKUNx7mFEHSeWs1ALyxk3kl473mR
gybNyZ90Oxf6mpQpMDvmGH6nlBg0eMNidP6zqIQjp1sMN4peyerhW6RYrbT4aoHrbtbDxFF4dPZ/
+7E9u1js3SiwM7/kAgh/HHjjJIN72gkDNtPoGRXui1cRJHjLa53rr+SlgJj28/jKJs8r71vAxf1a
iwjnGfoprZm3onC99/yxbNACcltOcoOnJCWbWJs6AIzSwy0wgpcbONoiWKV4pZHKGQuh80QXcb+Y
7CxpYtuI91KqvabpQVPLFaO7vyuU3foAHjpnHwH1MLyWc6qghyC/wJtd75kIhdQFUsmAOFuxUfTD
06NwGwk0xiXXnFopWp8Rxbfl0x1SwuHzjt9h3kKMMAeq989GMEwV9ZtonOCQ4/lDQ5DcdOQsfwYO
fc8JvoBf4ofKQ4IjiowSv4FizrxBqaVSvzJkX++wwWvWt6Bn7ifTUQezF74N4tDgXLjU8YH/gmnL
YjrdChMGmevh61dBMh1cMKv7ojwxAaexdCpKIu7/f+7sMk0Vx2TJ/CglpL8Eh788qEaZFdJ2I88b
IZl1+c+/rgrTM8mdFrz/wLSXovIBeXxWBBv2GGAlM5u1hWpuIAxce5WLhJM/DEmWvWPrZjV5t9fM
lgp7vTDB7h7uz/Ij/PaVZD3Eu+oDm48T5uAMU8CXHLJWq05bA5/gUtsHU0sR+kNrdRGNLJj8JHqf
yDak4fd43GzaaDpvCFH1A0rgi4zJ8Io9qFRZRliaoC3d+86IzmsH7/+pNhNUKCKoum9aqggsRFGn
9/Fs1Wlk2cHaZ622b+Via6Z1hJlFKGmnDEUJSdedpUOp9iwsaDMQa4PmKHrXy84Xo7yDfeakU323
PYuVOs7yv/65VkPTHKTyEnW2LpAhj8OAn8+DjCSWTBJYEpzeuLli3igxVo70pz+zJAmyKe+BRBoK
Hl+HBgt6iKEliFqxYk6spztxILmD+otpJGMMasilSAjReotqK62u6JSxjZ9jRrWKqHstecZK2zEE
G6vWlSgGml+VcJ3wA3+6lQeBClf9bj4hdlSPCOiU01EC8wu1ifDcjHN9xjTfVN5siZBGBwwbKxT+
oleYwDV8grOrTdR29TV14LkdnRYpIXUfDixdK7nKjg0rWsSVG69FYA5lVfB1fzPIaLLOztuO4Xb+
W3wf3hy+9tw+dI5ViRpA4PKZ4INYufQBIheWLUCbpOdKfzv6/kEewq1Sd1ryt7O+B1zSnA4xcKm+
6eGEOWBRDej/OOHwoeASdJIW18yPVp/eHVs4IbqnlPVSGp9FwmwQmSuvY2LfGt5oUtME08vdXz5F
D1EYAKU03XY00Ye46xIP1igQpMT9h27C/FHgPbmcT4hCsFZBH3XygT6oqkaCWS78g/7d9g2wk0/h
h+prXcBQkMbfPxsQIcvJUbtj+wmsmAwaaU1laI4JUsffoopiWaESLFmxhGJoIG9GwQXYLWUiYC0X
m2/FDNW/Lrxj1U2eDUJtmTMzE9XI2svs05IoJuY7eSSbkjZbDKP72JE27qkXRZz92oI6R6HiY8yF
9kCLedr4ZZgV8oszm3b+WZjdrhMx2SuNLJ6/ZDstsT9QVawq9meXlO2X1EN+BF31SgA6nlvh1zfa
RtHLaes/NFM/6Qb/1C8kHj0zJorPHmX8hFspG8lJx3oyMwbp3kPyNuhbX/NtQvHd/55cfA6BPwJ1
pMpMrDmuerAjEdMbAeRF+EY8mB8lIIW79wdFH37b5Fox5ULoaB063voIH+O/59xgH6YJmVmwq9jq
vBux/TYffTdcEH8zwgV2Mu7oNR2KBZ+KpiOdaXRNdiFxQn7U+xw1vUQKzMal7u782PnmFwtNAdUj
MiegHbdSseqfXye43JvrX3GVyaTVgy0yEFNrkZ58lHeK9fXgKlwT6pVjNs1K4XqYAg4HVvzCQ0Dk
5fHhbXVyZCU/lhgKACRkEj9R6LgWyzSA8GpPFCWpXGe4qZ2bdIuz/19ZxdpvlWCF/O4i0jX5xzcL
GcJuxWp6dCF/vDUO3Kw7uMXsX1XPKnQ+KVRkP1DOC4sVnckX+aUmC2ravAyJdTytJPcu7EOWb+fR
K9T9AqWk35MYVDgrSyD9fZjIRluOGO2ZmY8RoAj/J+YliIBB3BwZ1FtgAeJFEr7mPsuaPaaqWDqX
/vvsyrVsfBxVZlmFRecnQpvl0FUXOcp1DedkgtZzsl/gAWvjrLVIEyGIOhl/h57Ysc8zZzw4MUgi
4YqvRcbxvjXczfFeT44sIDvwg32N+3YLy+7cMtsRrJbmbRoxVjVgSQCh8LpFIDt441mJr5vRXtae
RoB5ofhG1lG7pJ1nd1we71NDcT3E4+QN/xG0j73GFrmgNybl7eNVg1GvkU5dG7ljdPF0U+HCvw4N
zYXzw58c2iXm5RCFNq/33KrlI6bjcRQTwtd2yCjXIsW22fa07QCVu67m9JMP3zyRTq2nlIiXZfY/
nu07u4n82OML/L5zoNyebbsaJwyvI0YTJ7mabyoJj8oJWg7r3+WpqJI1aN/poAP+GR6SKFxRB6Gx
1wxWJUFtJehB5/F1woBeWlZQp/H4I4BFP9gIYw5qiJCL6l+IIOvH4ekbZMgsJSir9FqNcaLl0ADb
CzINTqlk3AQxE7wO7EJYSMUokglFC/epcm9sswUYhlSlDdWuFOqv4faPBAZXu2fGSCZnuJ9hy6w5
7Z+pHwzJiG/3+/9+xzfh+4AJyQubDpG29KEjONDbRkMa4KBjy3/D2PdGU8XvQMR8wyHHMb9JThk/
76peknV2gdPePw7p4UtN0spLtbUHCpjfPcX7L024aKt9shp46C6vFlVKMY7DUPpn0TjvsVG5+6SJ
ptdUWK4GR2FQ0CFN4gGo9z3XPBtYMOVp5G6bvBDs3QvOAZD0CjLb65yIpSkxWSw5VWTte3/jWlC9
bIcQHOo1jnnm8DXDs9euLVT8nJX6Nw9g9ZJEOYDWbbSjnMTazUOofzEMx5yHyXxvnli/SW20mTuJ
aWa6Uoofgm/OGd/7o1/nQuGJXKQa0VbItSujJ3Ds7f9VeQojh9Q0BjgRMpiO5aF+23IJmSrNh6YG
A87FJZZX/VAxVeTbcnLO6mOMoEENp1t33j1JIoJKYoIqdjSb6qNva6251mPF8+IfbzZPdLWKLBd+
0/GU0hWxsnciTOiLngDxDmTGgJpKXQ2b8RG2/8jMuQOeDz3KH+RDgcGWm6CftARVMPUhsXX0oMg7
DBwkTBgzRICgTwx+0hEwrU6j4tyyEKTXdAJm8DhNZahNKQfblg+ZEqM+2qGmizPQYvfBMSfFtz3H
avr+u02a8fzGXwhNFJGh+ewQ7/0od9XXhJLB12vftvimBirWvK5wvAfesaL7rsKsuod/6P/UCHwP
WYU4uBIGprTYsQuAmIE51JwPe31t8fKyrPzdo7KBpAmuKNIdtfzAJvapjN5Vjc35rps/Ucc3MlOl
xEjMD2cvzfUFKWB0ZwkAuOCV8DkI9yZ/AnbI3c/RoueczjHzH5hH4vgWCUiZ1MebrgTeAcIzYunx
Imi4Y2jnfb96F5HbpgZcScl+jl2RoCLP7T6nahiVBag1oWVTcS/kUCQywllqlG3XKQIGoEUT+HFx
q7LQbzCe2hrjoBOe5ybeS40wjrvpoARdX/xghyVgYyupfIKh94cx9+KkhbdGgAYcCm1/5K4z3aOC
KoKlfl/2ZAzLaeKuUPWr4OIpcm5KAQ5T6f+ZOuY358IH7iMtzaTIydglstbuvcBN/hwd50ska2q1
rHK/JairpaOmA+wy12SYzZWLLjjUsPspwFLrX/3y8LrqPWxziFjT1GtINPzI92jXUHoeIKREIOVR
KSJ20nPTSwhb5fa1mYW1PWCLQppjsLFw24mKRUPTVg6pV/TT635uczmWGhRUPROTm/OX2/XsoEjV
Of3uNK45CP3mUKztIY9fS6VKlhiThiQOPxsk82cc5wwZsHOtsEUeFyex9QNajkmVjRq06RhBR+ku
ZTiGLIQKT71HMPqcwIJXIKDFtTE/vf25Oc3+m1DzvS2znsUuhW9lMrMQOkWT5/iQ2byb3KJg6ifn
UwovZAR5wlCCVB9f4uIcWAN7fci17Ls02qlTQKb/PcRnL6sc1h0YML8OjdRCRP2pWdo/+eoZWW1k
8DJPYH4US8ItC865QyrDNCjV/qwOEUdMRKtSJHpZ9RVdmdnUIfwBaDwJ3k+Fuwes8dosu84RWCgq
MwjHtwP0/WDDdtP1Ad0x3jdIr5c7RDbSwiemLCI4XcIo5P/TFsUT6bbTeopVDiS/mh+CmGVRJFor
ZIaVHiZnPOQYTrFOjWhCMt7752esRIBwHxdpjl/7BkBPZxorLpZPBmDh+AjEYhtIz++dN5I2FiZn
PHAnJTnCeUfknQUDjxG5gSpdm1cdKtohTevRcfXMfJ8PYencM6rXS/ss7ClrqRqdYQVNAluYKOz8
F4EuuwZscGIq7mo7JzVDTJxDJ/eVL3PD2GZT/338u85fGkIAwcBsYrJs706VLjuxed1Vq58my4m0
WWds4lpsbAQgjV48cnPlQoXcoYZNpjqryko9rDmhhzUXzj3yzBUxR0mT5N2VLaJLyqRDucwl0Hsw
u1gMIKKmt2snAjPVWYsvIMDY62YpUvAWPusMJ1oLScQ2r0jbmGgWJlpuE9OEEs7jA5EyI8DnTtJi
ClJAWa+4WoRrS9/ljXNTk4ZphMkDZFqn3i5Z2NTK+9nCkNdtwvwF6xGReNkvKXDI5jG44FcXV8db
ftQqkybBaI4ggBMl6BQzk5BQdc1VEQbhQZJH0mVpjtNGCAzOZPTMbfZ5beM0bi5j3BAv83H1O2I/
AtroyNhqrvytk8mV7868p0VgVCUZQFxJ5m5jrcI+I8/nixiMN9KkYqAbKBzVds3UYnbgZsvq4zu5
NA1WNUhynOeqCCSK4yjS6+9fRVyJ00V+zS6gwOySR7JxicR/sLod/ACT3DkKdIG06O/Bq9NN7d6v
aJuQ1jvAof4MBkqNROmi4hd9kBhDejknCjRa5iNgKb7W8A36gIRjHn3oLYP1KLiZ4SEFDNiiGZIE
PAxOhmTFkH/xOESVHqCgkybegk5L9bxqmOX65SKZD3/w9Bfe7RvdeCi3uGEGa5lSD22gZODIV1z8
pRRo7fH4wDyUlXW5OxtJYgm/tXYZTIJUPnq1fK99VY5Sy7B4rQtwQ53zje1AVzyWcyA7Tq94GhM0
sRR49FYcnlRhAYa0jOKhVZuk7TCLqCPCtl31fMUHhg5EvVBEV7wgZPZidfPgWkGOON7lSEBTigSv
lHDPQJZtTXyaY1Fm+3YotPrXW1hlUI3i7j2Jwf1giSGk3/TZDfYIaz7s9nGcmJ/DImseVqBaCRlc
m2XpN6iYIMstxgBG1ewoGn1ecBrOqbT0MASnjPFrhG7mZq8Jio9FBFXmrmKrFPsOP/UAytvT/3ML
NT+qRV8O5so3iZDyUz/7GfkKTS2T7qIZyiO+jD2WqQxSQLRQT1nTbUg2gxENPY1rxrTAP7yYxAd2
ogSupYY6WYeXMdAvXfeTZ0el7rA7wDHFHGIRlFao6YLKIoI0RPbwUVGzJ0nA+vGMqMawemA9bVak
UpxBOiL6gwwsi7i+LVlhCh22np3/CYM99lt53t5q/VU8sOspSt+4s8V5zyJ/MULedjUKitf57ca/
bavMWu2IfA0KgWC6KkEkrEsO8oWK9OVGqqsY61ck/DDZGwT2TfbYfTJs+c3hgUIZ0ebr5RAiC0BN
4uv7wBMCQFVCpGY6Dam/MC2uHDWzWBYX4vM1DDMnUVQGYm3cKIU5vugcX3m/Xju/Ud17jEQqSbFK
gPZ8Gn+F28IuIa19uUh8Tg8qY40Fp0Q/OYM65S0S2szNfKO7hxI00giIDHr6TPCziwkggg7xLZHR
hM8BLILaLDamxPmbMrbm2k0o8Tg3RqQP4CoH1cqmmnp4I55X1dNOABwcItMyj0SFU/JEivPlRqhi
zM6VZZTCF9VL0jOMsm9PBei0y6E1CvzpbczzgXqsSvust60YFOF3PZkPdiQeCVkuGqPZz6dwhyCP
xB751g/kOU9gjIp2jGdr3CoRDM2/1HgO4xNtQkOMorEWSzPqIIvqPAhmJpcySym/sPZ+H84xqDJr
ZUqsF/D+L9VhpbVbXI3lSTSR+aK1NJaQa+dUvDqbtO911tHxFX4OTTe2WJ94kAfEd3TefPi9YutA
yRBNDEEVC3BArYl1EHd+/NUM2qIYjBa3NzFJNFyxjbcP4GhMt+0Z4knpD/q1NkmLco0ViVGc+DHG
1v4g79dQt9HhvzIjBYLzQEoq9t0PU9kM/sYKLtOh9g+VMvGTaEEnq+lxCJKkho+d/3INhKmhs9l5
/NDOuyOs3Md7zg3c4fHt1azOk5FdgoKAZByYDhoWCIdCfL0drUkdpi/RGaJMgAiofZ0lSudTkGQq
lMsdojmEoZLhPnyM+0hH/ou11xzZic0XTHDQ1IMt83xT9X7KKx3+5QJdFRW9vp8KV0kC/XqT95kx
zm4aW2D0vJ/8po6VOqYbvDL3kJceAPEZajsYYsdz0thvlHibSjo23rxZ76/qN5LbCqXAUKsbF2WB
cxQ9PErqT1WDhcKybLkZ+U48KV4A97e/hDT9JquooTLmhsgdSjIq33R3fAy6MNYAyjESwAjUIanA
EWiDt9k467qulblSQKKZtCR/l5fBEuklC2RmWFGVAYQT1rTfzh7bW/fdo1GjzSZ6D6XqTzmyj3rL
qRoKvgTJ2okbht24UWgyAOjVELcxqabeuiBfE16/XTJTIbEXnmfy4I3Pwyogf/0hfHRDYyG+mkDc
+qePue0z/w3YHox6kqWpaIHcVLXN/yjQfDjk0kVIdwHGK29UEVaw8capZcYr/BxhqRA8ZDq7l/Il
XCYgkd3NzFOdkZ9fssQilJuMk/gcNie5CCRO3UxGnsLrzEetCfbHkfoIg3qlux64HT10R8Zg5zEf
zYCsELJEtWvKwOrWX6Ho3smQIqsXhyD/7fHpJes2AkDyUw9rIXY737CkK/0dEUBDNk14E6LliTHQ
fHTYv/1OQuDH+QK7KH5xwCSuYA+KtXSWsQeG64KI51K1UkmqUgUtKNOUuykzu2xH6/a6biezp/GZ
CrxewFXvWBbFHRp8C8gB1o2p5uA5QfbwsPhoL1X/+EjSzmJvLcmeCujHDt/6aBy94V63b8KBORIM
1870Elex9Jw6V5e47f/EQBMukrkKgKY0zO7OFu14OOsK8Ak5bc9TRprayif2nIuXRBO0NsZZC+x8
7KAaBv7zx8Eni5S8hNC9MAXb37SzcWC6O8F5z4R94iCnhXWwjGOZ5Wpo/86LnV9+srxRS0ZWMOk5
l+IajBXvbQaxAmB+c2A646ARmJbQCkADm81MJdmUsf/eelurysxUzYLMOo3lFv9qL/up7B3oceNF
bC1k93LNXdMfWom6dyGbqKEAPs8r+vMBQPKUu4D+gPRVZS3FG0X9G775E73Y7iFRF6bmq46J9TlW
TiAeiLY6kLsTwGORAd1WwfjLr7SCkqrOVosy/7OqiLCc1rQaRTMGRKmWQ43BoWx49/7Gj8+TdAE2
HttEpxLC7FqBgf9IbtHflBfZRBtYhjRFndeu2u2PiSRVDSKP977AcNfXdOl6Q4kwsfo4JZgvg4X0
tbwNlZVNYdjIfZf/xTDslLyxEYolmCyw1TTV6qgmXUVj1BxA8QC5cm3iexnpLn4/SsMZChH35EBG
veXKI1gQDKkS76LWc/blR5DNf37vNJRkoDM8kHUU7Brrt+l+N78gfVOYcPXL+URu9r1hiKVj0zFD
/A1k7uFMToxhg/kLwrIRKyKasX+fU0Ci73fev888dnvag/Hh+r0JCFWkgIHUEi2k2E1riOGiiGAt
+F7eOBORtRxUFqhF3xFLcKN5agCB5fKJaZU53vEp+bC1AyFARPkpcKjdvuVeDOeQdhw2W/vxaHMI
qEBwr2eqSgYlk+uYIzZWmEh5X2tkl8L7RXj9Ow/o6wzgE6fqg/969iuVfmeGdWhJjGAwLCujJhGs
sDtFRSHjA0DqTWo9FSjQTcwmIVILHPgyIymuZixD4yoiyjaDVYzx8xdP/dr+IJ8NEbmKTNmCzr9S
nT4q2o47y3CjmE9ifA/I1WADTwdYpzxNI8pdT9jGRKH9qp9cpa1pKRsDgK2Ix6bYSxRIcG+x1aeZ
K+LDJHo5gbo3uf8dS3/ljo+/mj+/RREPQwpfOWG4rFrR2/0W9bWbHXxYNEtb5gWVQbDChqFcWDzF
VnAgL/2X+pXcVwLHGC0cc/CqLPW4/TeAnnejUt24HlvCg5C8GLiGwoK5dsgY63Q8XxFafhFjdMZa
/vvFpMWgQ1K7G/urAVwYRaa9HSg2KARnstCjwAvxG6OSyj9HtNkeifoAAWPYxBuO33ZmAF4fyAEP
UXu42H6e63RG0rsdwD8iyHJY5MnYZRAE3/ya28v1Jd5rg5Xiko6oq3WEAuzPRfJAqO5qAxtVXDXm
kZnJAYlf/NoJeIbCaB2SAn2wWg0eDHb83QzRrzSYjp4PezhwexsKR38RRHO3D28fbhre655UL9cc
KGFx2y1KG+TCKtzFAHS/z2Up/Pt5nmTYeBj4YC7mMHk56J/w7okmwlQM+kkp05X7If1pzrx6NxuS
rb14XZWcUJo4txyrxGpT8EY9ZpHUGvpJ4A2OGTP5LpTzWMCtM1BHm3W9Yl4oGAM+10hmdGwFerH3
9+sYiS+UjjVndOMg4kQ9RrhiAtJ7au+KLijQcgdRyB90VNHJYOQhIbdAe9qWaDcabeznk+SEtaGd
hs4vpZb310m++FBCQNciI9+wyeaeSZo/Yrv0w3jkERkDmP1OfE+ZPkm3SfJYBc75pEizhWIWIMXa
zvjN42SxNr0qoOBQxCif7T2lvQzSW+Lr1koEYi2FXr73uigH0i2SRgp5Vk71GMu0fAxkmXV0jStF
bq2gwAyR71gYtelNjwu+6mWhSvwkQjSk5EEBxc8EDcev9jyXDzFLcCi3kNpTCubbfOEmiJ8/ow0e
lr0lkwQLQR3dDm+eMsmtVNHdpZeVwGg2vmu6lvN2JcoCQdD7ChfHZ3Wi37Atzq5PVQ+mcD/Obpcr
9uTZYMPQtD6ZOGC7+jkiQ8CQQEgGJ4XhW7J2VNDoQZNP5i4DcusxNEQcjKuQLoge+wuOQh7pV9wv
sbTaFMny67/ICddtMXtj/v6rp6jOGKada/OVXkOOGUL/SakC5AHtdBnaIk+Qk1Q0/0rISCE2YsOx
vaaCSwVKzjgdLWfXMSaDUDmx7cNzlarfnv2/td9RVUtgXWTkw3jf15DDJ5kJ9Dr1gKhl3Pir+20+
4ZTrkPlFrMtzuxbZmaR6IaIbU8RckPO0LRb2ukpCbDN6YTKnNgvzmn2TZEixG7vzi3J2cFPgzblX
K4IVfY7El5IoJFzP3m6CwR+BB++HJFk4Eg2lbNyQCKqTrDNNzAS0XbXDB4XSYBOJ8aYd/PnDbaTP
ea7iMdHr78tOusTMkusszj34+vlMSC+0Reo9YrAe8Z42GKKnILv/XjhjXHouhxs5k8w7PuEwUU2p
s3gYLN7vWCSAoXBje790XXCumk9jnZ9C+7j4BuVIPB2jM2lkSfh/mqx+fnu6ZrfDkfQ3bNjJEZSs
LI+whagFDqTynfrNcfxTXWg1N/4wC9HFZb9tEcAG7g09D1m59gNWkPiBHTLk031RqsE2kwtdJFnP
/iWv8FK8Xxih4K86XR5SH9xAoqyAa5aDdoc/laYCP0O7SiX8LSx8uTv8NtA7alrt+NBkgOzdFMQZ
/7CU4uzzQQ+92H6r1bQBgNjYjCaXMEnkOqLV5qQNxMFc320yuCp9AvSx5/d1sDhpz2GdUpxsmXgw
mBc5fyc/yGM5Yc+QVillQwueRbVVNTLa4+QWbOq24KU8zcwASP09Ibv0gZ4YRa5bhrFHd74Mh77o
MEm0QEc0ghJ4NdV4DT3NTQi7nVWWNxAQPWZOfpns3KCqLFPAu5oEjHEt5WeJctfBjgAzNQnuuzeQ
wQcvtDjlt2F6lHeXSCMK5P4mT0ujhwLoW6hPPnx7L+25m8XA1ApAw7OzBR/UGgbYf5ON5McnAIWW
LMyMMy5VfuJAWdwed5oKORMKATEeLj4PFzdNGJUyJKKh7RvsP7skvKvKXp7SlefGoe/Q6oDgIpdr
rZk8Zg0J5DlsHEUDEJF/Kiemp6yznhm6nVNXIA5KCF5xetDvMEcAsMDLhaKyLN2iiiyXq6CXifbl
Bx364kiXTdX1RMaLwrfYRvnt2DnK4hhXXW843pyfe8qyHZgSl2YToi8h6dw7QIU+ul8ibRRNz8WP
O2TNV1y5PFBcZeJQZPnwjpHSErGFr0CNlD1cx8b+4bNI83LD0GK1n6p9zD68E+spgLkQ5Fb5NWzp
W94YV1u1TuQhUjxpn+wQ6raaBa7uCTS7wj8rfaiD8py8Y73SSJD0jrl/0QtOHlDGN66wVBJvrDPi
JoLKEmgRmxdnXYcb7/uq56ZDY21dmlTd1WG2GugTwT9XB2V+Mxu1/40Wm3P2DXTUcm3jhgKoxnUV
mlFOOV89Wgg5FKYxdyO/I/J/+PQleKZIGMOlivl88aO7eoHfIwpxJa7dgaOwNQMFoUBpIc4RUVtq
QOKhwfPbBqHjOt9KZYC/rVzGtjSPiqWQHJ+FRUghPThZFZjzO5fls5C+E0P5iOYzVT4MBxztZyIC
/fFavUZzh0G47ChsInOf5syIA/gUmOGSatUnp6k1ol4UuaAWbi1Hx01WiNcuhMGVu92asN8mdP31
Q4LTlhNPz8hYG76M17f1t5RSdCwsF1j/Is9vKywMLMhQ2J5xauay9hiISL1W2eGfiZqdgr7MoSTL
UN/+o2fc29hcWFQj+itzIAjlgYvduacnik/R2VDr4ZKTYx2My4rJmWTrzsdf8baJht3A2wT4QTfG
fXqX2442LdZmGUzgTbIOlVRMkl4rClUTjLXGcjr7vilkA9vict+MH+0FQ6mkYPi7RPR/CEzmMdYE
R+cr9J1Ur1AQ3+2NfksxRXfR40vSS1TCVP/aQIwvqXtIDEhMhPEQYZVK85KYiiBZLNPNAYdsmjkN
bhHp0VmB7rYordTGYi0JLeS+Xf7gqHnz/MZ4XOvwNr7+nYSuay2TI8A5PqpCX8KKk4x+93S0odGn
u+Igy4uHGHZSmpuXIaAyvSrx+Safq8MLTtQpoDum7AmY2Hrjwik5WrvoAjelQR9mp58YBTbiGHmu
IWZQZX3jQswa0m1vhMXIMTlJ6/esjz5ULdRvT6oEBt5gWus2PrxaZS4tgRKaKEjQitz75kIFdYvb
CyIJZF7Et8MIScj/kZ3qiL90IxuDntC1e74f/11u+JeF+PqXDEUcKX7W5zR7znWiHKWa9C4QXo5/
iMvJHMXNHaabdb9QmB8HiKNFWOgFcOgrQMQipSP4lS411/b00yYSV6VKQSiICNPDa1eYRdTmebgT
tNNpp7Fg2aZyN2QfyL1PjCCsw7XW0vFO4PofSlVFeeDQidARIaTxsMBO97epSWP1zk1Y03B1BxRJ
G4yFJE1xgl+q4q99GhJE5IVmjdUUq7ulwKWm4OFxnIdwZtV2XMUK5Uji3M3WvDZQUDwHLp/+WEWD
YyAgZDt3YgoC9yg5glJNSLbB2qxScXrrI8cHpk+ebvhoH1MDBVz76LlGR/w+u4NQQpBgdf30q/RM
O8tmoXrNHLrBg0ERvA4+QOzo3xdGnBsWgmU/xcqnsLHEGFv3QkGgSTrbcT3UrOjq8aVLmvyQ1nOE
a/ky5lSOGaMDz8HL3hHpOeR2UQU458p7I/HLL9xhid3jwdpfy4UM4t7xlulfCHoQaXB9FKay3ytY
lZWM8vMxoXRhBZeBbxcPH9K98u0ut9pJVqHO+YITw+Gq/8EmBodgBFRUonWOuwDVBekyoOed1EyG
5Df8oGjtydJoUGjR3K+ym5MbAvwa4Xt6EQQTKZFsVqL3wXNqmhB7ROpAOpLE+Mu9OJbN0vAT123C
OEKzLWsyllky9DT5/Ho9KW+ANG/ALInN4PLRDVbxRq2FlrgN3wt15YCkEeWxGXIuIhrrfi4ih8sD
w0XdR/8yVo5TEQff0WABYwNXV+MzODZelZfrNw41fvXZgbgj3kdKKM+akBatDtwjtgHCUh2fum9Z
E77B5hWzOdDVW3bIjmWVvWejTBch0K5tPpttX69TcnaiV/dZdlIwqoxz5nzuny5gYUj9UhVxsfud
aTKi11+yQYelGw5iUltQoQHwPBFs0of3ttrpmpf7QCsT+4lSwJO2Q/Q66OoSrQ0s2lv26TSk9mUa
Km5yRX7qvWfHwkm4czAWVn5zB0SCPFB5HoGW4RdMgKsvzW5ii3wgf0uLsk2QDPLIaV8xHkY/jXzB
8kLpA7pzB5vVW2Rxudd+ZCxDosFTOUpYQxxci6o7mTbXhNFBXX+fcqcbUOngcHF8+fFGjO8xYYCI
PD3iEAen/5hcIbEtF+omKDc0uJ6B+z549j5NbMgLInfpqCMjJ2OEmeZdl+sypM5w6VbGeRxYoVQj
3u3cyQA2ZByq+fiePjhYy6vD63MF/BfHKdZMoq79FkcUHI8Ty1CQj17KOsaIaYwIswtvH6YL4h0g
i1tzF79oLCogkxpGze9YzIrHMYcgH6QfYOEacTqxXJQFi59Q4IV4ElW/lvyOzQdtypvA6W/g+ocd
VdBW1nC8cHPI6YsWTp97RH6zZPbtGJ6+WC49ZKBCiNwQ8HFIwka9HZW0pYHNuQFW0apLrBfhKn2a
C2gdiwoeK0m11FGcFN2OA5gYfB86lhLUJz/kC9tY9JzdMuALpN0IBhfTwTOlU89c4Xw0KzZO36pg
TEMbo7SZ0cDxs2pMkVbEmlnacQ4S+EEgZMxDB+8dAd1pIr0cfjbFUKNPFlgl6la7wfS0xryph8mO
eoxd11YSzXgiIF+CqMUJWmMo/oSATGOBsJaYkikBm9VaM64j7ngIlMyUubXLF//0yM7F1NyZozrr
+WX5/GEIN/bOUiDNUndOj9P8AEOhNh3qI/suiwYrZHrPrTWJjgamMu3G/F0XQv+kDdAhwWMwpraS
EP49rS2TJg6Kbt90aahDLn1IIezXA+fdbf6hjRvL+JnDLW+K7VX/hUfcYMT/Fdc5+m+ioDvwftDO
HpkjmVAwDUsIsN7FxnbyMOEYnOG2FgXOdObNW3uFRiYwxifqIw1ZQUPxh/e++F06QfCD6lk+U55b
MBvr48HQFLkkSihsNLSUocJowQtyUnVte4awoFkqV1ZVhRCP6OiSQSPfmKmbdlIu7Ym09+bBBdCe
rB9WqloZQ/XP3sZ7YKkRp5m2ShPgk9CYUZkr7LHGUP8Y5anoR9GggdsWzBdmsXkur8JLDmRY9kDn
Bfqfd4+DOtncAxzmKGyA55tEazItWTSNzY73NbvWZPwTXKHOhhHF2JJosUHZ88NB25nPU5VUrrn1
RrPy4ArlM6Q/ukcYmzYVa7WLPfKN8n7/EvSTz8Wqm5Cu4wIcvKIL1Cn9Ocwoph3q3qSJOK8Pnryb
LQrPtySclUczGv8ZO4NAhgn1VVsmjdK3IxIjeF38gNGcKR8lmHkV4eXklqIGwH2J6bwwAEA11cSP
65tSJWzpmHptcvwiCRO3Oz0MXCYMxNGNpO4VneSRkQ8yFDSyO/0mdhjZ57pvREmyinoeWIWhc1jM
tT6UBVYzhZLL+vJOVYEZIwDuw1m7dMYbBEjMv7ikG3SBK+Tylw5U+PsmwBrRx7rlO8uTps7FJ0cp
fT7dpBaJQSyJZ6vDhvewwdWNbgiJw+/Jlp1KZjCSiYPzK40tHpeALVhgpkd7eDJQ4rdChVQKZBgB
qky7e1nBknDjsSozAd9irYT8PU2XCggn8TLseyFyXnDjsvu8ezzO+elUxN09OfN8xOjEB6tcqJSE
PHQdaP1oa80p6PnINi8dfd7F1+qg0+dFtB0do34kc8LEhIKPEDOTgRG2Uj3neyepJcn7WtZNRckL
dOebm+s7jvspXI1zhukPgjBS7QCvSKvb0C0q2BS86qFMVF6alOJImO+K3rpM54xuu/3l3b1BA3vE
P7DkGH1iwYrykrR3AI94035bCCzGeNqomqhQUX0MRAYXHpv8AU20psSP2u6S/ZAorGEunON3cAN4
rLb46mwM4eh9pwBFzFTO0MsJR+9X4WHSwQDD46wGaQMMB2PJYLGpMO/ZWjPidjpmq3iwzGYGYd8b
2dVcRxga0DdMgAVfoRKSnX0lhQhRpXxdED83tUju0lNsLdSJ+qiy0U8aywcXc/ZAcERXGegYjQXY
05ZTWhvzhOFVMNxRWI8acjCUXoKqOi8syUJQz+twT3L/Nhr6uOMU4pfT2yyiJX7Hyq7stAFv9FuQ
cXCH/urBW2k9TdZapLIvSMcpC5HYng1CESHLomu58kM3eQ0xiambDNxfYfxBwselBDAUuZyJIWoQ
dKxouhLKSLzt5nQkb2JHsxbm7r9Rh99TsN8pSG4eWMM1YA1cplHn8ME36yKivN74/b0/1XryJdKG
ddeQkCYdkxN3VEqQxqvK4hBtiqu2A0MRHG+0ggW4cs506h1EDRHXpXwKqrm504GIpVRIySlIRShm
C5QHmZSjcCJ1j6lU71cM4v9Xe33Vc4bwfRryAh93Zwz/FzzB3JSPEAeSpKwjhK6QolqUp8tfSnGZ
O+PbvOPCL1NFoUsYPz5oBOQgYaCk7LyKIrjilgS4G0O0/DZIZozgb31QghvVn9Y5sfqHYXN08soi
uqFWKia42VUbd0dx7vtJLN0BPwisRMmKUZL2/76+gSQcG0EqmVvWxv5dCTL2X1OmLZ70cbZz/5UB
3WK2JtfYwkByK3LyIdKAL5em8iDx9H8koj6FBjztLaxVoS5VDc1cmOWZ9jcdDgdRnCiiBDsZlwot
zE5QOldmJzGN5DGIybkm4Xc3/SPVx2USnaNTQ7YBpyYSv2ffNu0qTCxBp9uuMKO07rW8zRdNe3BZ
Kw/0SWSpNJTDbs7LLLWelbjEe0jvcI96qXfOG5oTw3vcPwuKWSEHFFXhiTPwHIJ5o8wVAXUVIqZn
nqdYwq6zLM4FliLZmxvWMKjz8MHBY6RNpN1HTU9u3NYxWOkhlYeZHXXIXCI/eqBSHOBkirHxyNsX
a5dUxElqr5nmCFFkND5VOdtQUsVDv6d6QmNC05JFN6/WNgQjC7VQKi6XKumdMt4HatVWfUocBGqH
oFy0olUeZkMEK9nZtV69gkIY8iEubP/fpGpNbE4is1Al8p+6JezdP4d2MqrXQYwAdtnSebd4Bj+4
EpQ/KO59N5IPgeW5+IfLMXC71V/Gnr2d762fGsDh6bTPndg9hop58Ek6/AwSmGyzFns6+v5+/iYM
wACt8q3CUU7bMTKg3o1Kp6dTUybWkpDHb2P/1h9gXA5htK1dfHGI0AAPVrPCLqZzjm39ByiOs5jH
5PNb5a43AAgCoC5PAcvdqZvCPGZ2hIZbARsqJ+HW0Cy9hQOcn3a3QYW5olK5pR6p2h45qdapyB4m
PTh/8jg05mPhfksX+M2CYk2HvTwBLvaKV4T04z24vnl2k6kLziu7IcdpRLWMWICGfLR5XnD3ntWX
brLd1v3bkNo007GU49vJIJSAT334lEI1iUxhPrwoKIEFhQ7/hoIRQT60Rftb7Ybyyw4qKS0gYIKh
4LymoYBiCYHRa3OyxK9KJ0AglnDRQIQa9NRUIxvMzjDT1Cus8yWd2iGoRG0jDTG7YrzSFGlU1R+w
I5zvDdrqYXJS2a3HD7F0qSpDdFfihyy29MbhpL4doNOadDTmBbUSmgH4GEib1GKoCh+wwzOf3eIV
cGUq8O5b9aRUBguXBngHRAPeMH+2W1t+NUG9s3gslS97s32wKjy0CliA9LopzAL4Mi1aaVUBK7Km
9MhjqsuUwSlQ5iUe8WoWhc5CjTBlRAPTHycu/psC2294eUT8YwD5Ne7OzSrvbW+Jvvt88WeZ9sjy
rg6l10YmpiqXzj5fFTpEPSaLO6KZoStSd2ee9PILv0RduSjsta1lY9haZsW0YcpEk2z44Pm1vgdV
IUKLHPYshhHbDfikCr55FdkAT7baaYNhiqZTTMS5ebQnIBGZBhBGwQtTkv/WfapBSHaYozarA3aP
Jai4eO3kR1NBePurFWseFDPnzHYcS2NTroCUPA6eQ013PaT86mrws7TLj46Pu6L2iam0kEA4T+Ne
81QLdN7SFe0uDIif5OcXLZoTlC20REv3+vJthtY2V2TvR8DCGLPyWnSByCMd4IaneUjTWi8jOW79
KrptQKSb2ZOL74tC5uxenjunCRr5v9L58jeTzSsY03JZDhEAb69bksz3TlPtAVVXX7Na96sBr58H
KBXSYB8yrtT3ZfvS7IKQRIENzcptEPV5Ue+39bbhVeFPPWhqz65H37HkWQ4TTPndPXd89j9e+C+D
555JD4pkpUPxw1kUwxv6A2rl+OrBOF6XlvcDkxVQXP6XEMYl3tGf8VUjgfXTihKhaAacXkOw8VSG
wcaXP9I8+6yc8uWeyCG/JlA7DFcNMVuPMEBEDRH0mhKos0znf8qdR7jDSTUm2SzKq6HLfXzfSK+V
IysNvVpgkBiMxxi5QMQI45oED3fgEuCG7GMLFCH5VE+hV8O8Bca6un0Zis2ojN8FEnVxQgRTR+tb
A+SkKk2IYTT83Nv2kI+G+Rdq4vfO5JDecuV4YdMSb1vby1ENigd2VYa62q84FJU2XRg9qAS7nZj9
ILXEy8Xd+MRolqR5L+OKWAJzobfr0X7INK3h9rNjyM8mNCA6IuDa3h+LFwBs+nXqsLC2MqxcjU1u
rsXUfNjewUd6mni08oDkEe2YJP4s8qKTfF3P8KmxOG5iJka3LHc/U6vsrUsgnpFAwihcSk81pGz4
4rtB/0tysSt2CnDF+QjomexNcQFlfPpZKd2StwWomytP57RHf625mKj86s/qw/ST6NE9XiinyGgY
CfgkDV0eYt0PXK2b+x17D9ZZ13ezThGgAe0vkIQ1E/dBYOKE+QJydQKZDpulPAz6vAHSZ7EhuTYZ
Yi5TqlzRSv0+BjxO+les5ucobK5iPznFHobUfO0xWDxBXxCXgZkmdCobMyfA0yKLm0t/r6Lrbhs9
8s0drNAQVav3bMxffTFzYbknCczHm6rA7nqq6/hTUsD908RSgbXZ78Z1kwM8acV25IbpbZcgaZ9W
wXoXIoxJjfDonHRG6Mbp87JRSZY34VHSTe8Rw1PjlcX1qeEuguVEZ47x3lbiEIIFD+qtFKK+Losr
riMMCpRMr21HOgSUsW1LJjZclgtmtiaktnnRALIIc3NAS/BhgiUMUF3rJmDK1M+ItE9QX5ZxM6L/
zL0eU3SnZ3WJSxQgzQKQGZzoCeUSdZ9xBk6eaje4cquQNUPs+MHbRl6E7tysWnY4FH9fIAHtyIlq
z/4df15/+YFWgAFFRL+VSg6IlsopGlNmqRh4WyXuBUQO7Z3gyE32QM1yte3jyZWiL10nBEej8Bej
ONUCG4F7BSY+++QA0i8HtiRwFol96Kp4QHlUQY01vVtvBbUWsfSGqeJGSogLBo4M3zz7wnNjK7UI
TxcTVKOCowEjio6clGLc8iSAy3ULbXBpL8HfznM338q7yzwqJLsndAS2TgJoT+9YFH96OEAUqm5D
wuMNjtuTrouW3E1hfXznlG6mA//eKqRMO78k7/nQ//Kvlc4lI3SrixNxGH1VWkH4evgTwm78wBtd
DvUs3Z3rv4jhGAD012ZhFYpaOLKfRRX18IURzdTIzdgcDtpY8m7s6AhCoQfz3MO6e7X2IRQOgCkL
QSFIBTWSqx3ZXfoZgAMF/c1Yv6fbrImRNDMb7UDXRVwBKMPEc8eqzjSVa8wnqTjYR3R5wHvkr/S0
QVsdAiM34+PJfSQucrLftJhcXnRVWkQrHcWHeFKrLDeFvmKNRscvrKML234jKefxf3L+EzDmuE7r
q5ixdhwt0AASQhZRK2pItGsE9Dvyr1Y19GqE3M2wRWCgPW/Qh0kZZqMpi6ddNhguAB2YqRpVUGwd
zb2QyquWFgAQBt/mZmTy5z9AZme/Q5cE+5iUuvJvVi94Mr8RJAIz2Md8dRy+FrVlclTnpkkrxLhP
LGTPYjUKX5gWr86i85GZE3BXvI782p3kVjQ8kf3Vv7qSOgjB8UQYJrgGHvbc0Gd4s3B0/vOu1CWJ
+7eMt/1NxgEfgR6TmFvoyjC8Gw/RXvyIRdXhY+SUQ8rTXWOG4rDg7JggmrRNHPMa8EG9R0jcCfWx
KN7PzqcZjvtRJd6+z5K0Cw38RUaeqVpkMoGMo+IkvaoqdMMOQl4XtrxQ1SPN1paI+d5AtGFecWN/
J5662G5LGXat1aBXDshu0V5P6FcV0SjZjprs3A6S3YifwNqOfrtx+pf0Jb0XFo8qyRh13mB4u3lG
8Hwp3Qp7RbJ8pp4sNJaXuPjq9Pn3YjdlF5pTG8+tr0vnzhxtg0+vJ49DwuSGhPXLObgiqcMtY/sJ
ay5ZTXIoW/tLymLsTsWpyzORRUlgE2FwcOED8LfTQ9ErcGT+4vfpiRrBWmwky2u2fzUXJku3fCsj
ADy7CLLgLyMg1MCK6WcjBK6khF2rfxInjC6YMW+SUWpnW/SPhnQIinBBSBfw3uX9FFtAvb3hZC7e
WlxyJBhkOodmggByeERNs/49gEMqe7T3hLgMfnsuonI17NMQJ54CyuqCskp68UHEVWRaq6TW8Qq0
vALjNScu0FV51Ra99bhxB2s4+TFtI/dkrkPUiJ20ZraQpxa/qbuecbxjnWJH0qd7ByxsiPAMMGuI
km6oDe9b/kGOsFYxI9znB/0rQjmtD0GPTyANKaqyWyQELt23ta85pk1VHKAowc8bomFbIu/wzew9
Rg3q2AwAQIR9VNtf6tIlGZ0wuktAx+FgRUs0gBYGRlXK+gXaqDc8c4Jx6M7KQGgNhLvN8L++eaF1
mUIWZcG22iVr8C9FIpNVQl2WvNh9fRn8oH9ifVCHALAwnDLV8hZ/5SYyBKcNmDHPeBEs4iFqZkfY
T97tQwraNolqkkYEzknpW0nRT88A2jvxPgHSyfqWyv+saJFYgLGzd1acm3x5jjeASyPrOmBTbdi7
bDveXAL37SjL7Kf2Pfc/RldQ/2EU+s96pP4t91JeXVsmNVI3vN1/vrxttJQeFBEQA01Xr+rPZfpG
uuKJsA5dztpGSSNEacDO+z41de24PY+VbQDiZmNW4Sufdq6JQ5iTzOddQkaaeOh/MLspktvFPR48
UjjqPtIBQW2l9ytta+aRs3TKbBBhcogFDHFC+8f+ZjL3QaHipUkDD8+f1aKy5q1YXxxShV9gN/gu
vln1PHzXyhF8f+10G14LDSez4LmxdjpGO5U8E5AabciFYjwk/1uSBJdNU7c8AupxUvZ5TBbctIKL
JO3IINO6Xqul8G/49eUU6vAqxbiZr5ulMbxoIJFbucw1EJJSv6VqjlweqNUEEM7cXhh1VwG6DjcA
USIFfpDLCjAgvwzsvNvxyAdjxZpdEAtQKDu2UKkGTB49eH2ytWu3WmDOXfWus2o9Q4Yv+wmTkMzs
wI+qPF15DalHy5HCHhaQVf4NGB/fPbSIkpKvzRaRl8K/aJqY4Uko7OM30qJS6enTG+cy7wvWzFRk
HvVOKOoyroYLzMnDWG5hpa98cp+Pc+rzKVi0sFDyzrX45tJiU51OVuE9moCtxrmybpj7Py1aYdsa
m16UN7YuN9c+HP8g44x50I5mnFwozTKIcej5JiY0Xw1pwq/Gtt8q1n+/Iu3eiMe0aZIdNqmVgkl6
BrYO3g6kOBzW0deFeKkon8yavUJqz313AllppL+XwJSEKkXsNrlR6MYbrBjvZNlc00u9TqrO//hI
pe8dwmcaKNasLlPGS+ouxcFNtT70A3L04l7AsbBNnqgNUFryN2Shj7pU1pDZu2zc017r9Ys3i/JE
JOit/GOzGqxditiNLBK9jd8tDfAf3g8DYr8CPlXl9WkHOxmEFsrItuVAnG0dG/KvYh2FfFrLtFqy
tOxdERUu8gxQYYptRmy/NoZrdqCGLbByppcChdF2hL5MmIwEw5nodFQVDUnbJA7tYPXMRuxYBZh6
xJ8kDzJB+qHL7SslFjiLdWdLlWaAApGwNvzbtX2Ef2oAvSyLE+O7RJEQ8dAcsqKSRvR1MtmhQ/ym
5kJmzW0Acb/fJIbnhkWPwb8/6b+uR58fKuYSv22Mlb15VmKCtcG/v2EIef9f0puFb9629tUfe4QZ
dcMWmfCQ2FkZ2sIDs6NtNfY2ype4dbcM7/58bbFEgUYSREJ2v6PldTcvpjCIoFdSovKQE/uH7c9V
6rwDDA166k2QMmHyLJU7XWnHhO5sNdCvARE2xDz3kMJbF+sqkLVIr4QSLe/8+S2kpZ7U0cwt+KYr
tCA7wNr++LK543EPQAYYlhXBSJxUyeUWKVjp2VxNjxJLYWJjHxbazPqZRIfwmiu7+pPICKOPx4PQ
K3x8oJpKg0Jg6a0oi/W60uuqCxQgtzLD4oEgDo/y2tO8H9y8fkDdA5Z3CCMgdcd19Tdmr+jmW1Hq
+hDGbVmMvGBBQpEfXdRDi8MmDC0b08KialsqvVc4XqQ2/1i9i8PuTbn3zusF2LVkvNpQaO0Ds0C1
RB7sNZMHxw3UFNNCuPqInaGFgZw3URraabNISXQwJ10gbR3Ks8qJYuPSXoaiZqBvgynwtnG4p+O/
A5bBMvC7a0dO36ld3dSuLRLbTWrDGq1IpYqbXtL6nyv5B5b6SlvaYO2woUv4/MgaOk6tslvMDhuh
tLVn5V9BvWDFThmFNyg+uhMXBl0EBcwZPXXieeIs1Ww9DPJj0/n48F3STL5S3hZhtOxZdYFi00MS
einp+gv/uuZTvS9epLMc+1F5I4wcposoqHn4+xQ1QM+4uUmbLq64caQlxYQ9DWigMeF6JSIzAqf8
85V8cusRtVGeFROwaqVOZmgqJ9ijE31W7U0h2exu+TH1fVhGhku9PbQRmAVwSLnG/NtSlwB55Gjg
TaybEyAc6r20sUq+plCtCg2nHFLOhDZhREAjKkSGTHuBkrmfjqGWsZQfZs528r9c7TIF7/GNfSqv
9oxARgTUFYAu8WfpX13H8B8NlKKifhVlqT1DLaLv/YfkhLMjwH1Dxr2gx76nK79b63ZA0c3yeWnz
HUFfdanpqxBSRAUAE4tCK7bwuEibr0uEebNM/ZZomK64JkcQJxjKcYrwna8l+P4i7kB7wb95ot2X
vIQcWkeqi9jbsH6K3sITcCvaC/H6ANZmzFj3FMddEZ2Wj7Y0lKuCjtO0kwy79vCm8MdyEYZyVMjk
hralr7rcAbO0ox97TkaarwgYto41rK/qqF/nVLV3fbB9XKlAzVOfTyvve+jJBZ+upMGglmsGaNi3
XDSAqEdi4uyBONYsOliGS4vLk2oihlgeQ5bdHPH73FHq6z4ohGWxNt57U+4F6AN28lGWSkyh/j+o
G/gLNq+TmjXfUmdejhqe9gfVscFACcaRNnct9xqTDC3g7ScxBnmCaPnDEZCXytGUFbW47Cav0N74
+vuhUVPwT28AEEW8I8IbyOTWl+qkdAnmHNCtIfo+zlUEryiP1KG64peR57QsqlBbhcxmi3S7bD7L
lxlsZ1mHpFHAqGgGGpzAW8fP+JunAQMsWNKI5fpg28DntEqzYg8nbbRJR3AvpVuW31r6D5nP0jLV
fMZ2hQMBTz1nQQ192++WkxErziuWSLNWSn1b8j4WUo+FfhcLdVR/xOtLqQTaCIYzkHUQx/rWzi3x
Rc1I9y+aQIwUoIN8Bgo2DXnryAJ7RIczxS/PM8+fuQ6Kp+L93Rl8jf9sm4y0gMyYhtlsmxKwYRUo
jpR4HwS+DVwemsqFBjlqZZNMBZoHrcKUc5TOriI7dJEBQ1u6jypsDF6JCLTzeWeV1gB62gjNvAdS
c/FKEUov43vlEFT8xHX4G7aFeh9V+TMmXztc3fuiGxnKnKY79CICuvD+1pexAXqbwUfvywe41Ltc
c9sYAU6uhezB8jhoKrf/v85s60F9+Cw91ay0AAwwftRmCewFuYd31ddOs5X09gY6uGVnX8e14j5N
3p+q357ZB22EoZomm7mPHPKXAHSwBV1i6BEcwdmFJ3SrtycYQQ1snhq87mpofaxtz9sljxG9AUGc
ydm8Jvj/OJI8ts8X34By0csMz9mGxXjCbiGKmv9GT3gcQHYQevJ63PGSbjiPD55i4mOn09JeblSO
RNmQBpF1kKz/DYI5PwWY/MrEzj8Ds/9vgNLAvfzex4hQm9ZNwwLeBQiYrFe0fM/HwOzowm0/nTIp
QRD0TPSBP280tTsImHhgm0MMLz8/4U1+Ncwa3NQNnINenF5uJDVvFCIrv8qj3QWvLnOz4xaQGEL5
ro+c57pIndxRd0nF7vsEGykDyqf6C+xW5p6Mnw3KrhPhF9vfUvx7C0kLhRGCA87nLyY38tJTvu8P
/lhICLl6+xXqRczIdWfyt3d7L+iKqVv9fs2Sce2/BNe9K/GBEKvX3GwxxANWFh7NKJLWcrB3MUns
vI0+Mh6BuydWl5jA5tWAc/FqJK0SImafnoLiMfeCxegqGd6iGmz5Tog5sofnGvG2IQU5o7eqJWS6
XY3+aIAsZaK/uRFvjjClod1Fin2jLmxCSZq6IRuqIrUDobtppPmzLc6WQDcGr/Tia6CD/LkgdpBg
CB8UI8l3bFQldqOLZ/0Hsi+5er677JGQFfFZ8nnfS44q2O4Iqr9Fn+hrDEs1EGC+ANq1nB0o3/r5
3JeTZDxmrCDBzIBwcTcuP/N6lvV9XcV526Y8rR81RNDrX1m1WyYl7ELQk+egS1GXIUuPI2BuWw8c
E0GfKF7Q98h6qouiB3No4yUi05XZOeOa7aA5hcm/t5onxxrYPrpYWHaOFCYSslCVRgt+qbPxx2bP
rgFi6XlhIWrTdY2iE9o9nn1u/zOS9jX0EHWSTLu3p9+Ghuo0Ay0+zAdElWryqnbNjhA6yObTn3pV
YX+W4Q3uh/eG9AKiJCCLSgtpw+yFVK8Bp47n4Vgre9gH1BaupR71OQQmnmJqJbSf9TLlL0bL39ew
ZLJisqn+9rzlNrOycgcCWzZJOPGkn4vp6NwyB3yg1tGUIiTkIp/Sa1FlS7wbc42o3USp36qEcz0G
fs0pBwqaglCCl7hQyWkZHF8Whp7DWCfsUebfJvwWcKh0yEec6taAgsiEkVkDnfjvS2dPKKsxgO7e
lRTxB64YldV0YeJ8F2RT+bgArfa1uTzF58Z7r9I9h5LewiCjUGoj2eGXJqZtEZNHMMqGNk9rEpZN
NOpLvzKDq9s4KrASqAoFm5WrehU6EeFy0pH3ZF7Z9X5uzTgLenJBoXKeaZIY57ckYAeMFYYWmyZs
lRk/LWd61Pyk4Z6xlmxEp6vY5tqWHD6Kxd2uCzkkcEK4hojkpG2exr1+/xfsdJBRDrtAZ4F+UI9m
VNRT3BzJbs9I6DuXFrIp0fqvoJfaB5JWdZ1avHWWX86wGujZNdMwNZbd/Yg0C0Io1eSzOGSgMyn+
UB4BUekqvaoJXJLz7m+cEqktW4hVyXB/rTb7yy7nJFygIiYW69l7o8bR7EfcXX5XDgJg6ff6qmv7
tMf8puorIdVgfmx5nDPud4a+KnIY/+pTfuiYs6QlPOpARnRfYcKrY+XTUjFxsWlctIcEWJBfj8dL
Vho07E9olxfZFyVa6o8JMkx2OWoi1JVZRaOs+pOH7qft8wZIPBQW/uBkUuOr9N3NpwMX3tfjqqDI
TddUDcwzTOBHaqxd52S8YvZWN24ZCLCDit45zMgtzCfLG7e5cJ3qLO5NfxGY3pZAJFHmnQD2/+xb
T6wFKlwutf003NWoY41faLUifV6VkAkZNDTwmqXkP9Myg+dzCvF/LAH7jAKMOeN+E595Uwb2t/dX
q4YYSSKIADHyvSqa/Zt2DQy4s8rN4O9/Kr/bGIBfGERZBGtbuZgZn70bYp0OUUpgEF5ckHLcLQbo
tCCAhJLNCvm2cdF8TL+VtiPkF2COHWYsM51xYZGIq0feghxSsQAIFmY0PYmFifjfTVWBxsn47VXS
vPFRDjeLA/fKHnblRBwIFdyqb2ZzoZ50/AjxPWyOyCwVL7ldmFzS23bLCXaHc7dvHMmAjUIDutOu
ra+Jd50q3ehvs+o63TXU3e6UlKCrvv79jKzf93I5/D4i+TC2v+1SgWlqGfqywjy5R+36TgfNBzyx
YC54Ad8cZz/j79cyDDTvJRaLLpOxfXqRpFfhB9s4fWr2IAKFL7ks31P23L9ppdyz37cnX2C1c7od
8lpQQeasXRdf63biTpipktD61ij+EqtL6DkeCgAHqqMYru2rlacnibUQAh1SFehFTGXtXACMOBgZ
LZwqs8gxeDIWOMaF5h6dQZ5pv42W2HEbsAJMYA3P32hy8hZv1kMizceqNQK1rFY6EE62S4CswKPF
288N3yxftwJw4dQCWkbV4WXbz7zcEDFR2NR26D8rZUpQPCif2W2jVxW59kEet23I4je4OnklplDI
LqQdrELoUxjmV7pHqAkA4tbKtF7XSAgXe/GOq/+NGMHOIAVC9yKtozDCHafvWjhuqKyq3vr6Y+FG
P3Ccf/vEBX5wku/kihd/JgxEUnXfL8l1EQkbq9oVEE+rDmdMV24PazTMMctw/5ycBI+ysV8cXo6V
ESLMhjPFG3TO5rafEeVnI7wIEaL2NoK0ezXwYJ9ryDZvPZasTsFVTjjv/rjIdiQIHnmoENnXjxmU
GdejdnuzTrAbqAKxoMJU+ElMzo1mmevDHVjJDwigr+TUozPKGyBMh6dXk38AXbYhvX+ssIYH4ZY1
SiGctnPVe+/5qpFtVA8Z75uAWIcVeEgbDsWE70onBOpedbXc1+kK33ygJUmVSTY9QKTo/tqDAQkn
XaheXKJku/1R6y49XRRBFjwRd+1OtCkAo3SUL1iQ+1nKJFZf3MDWO0G+u4+tPf91KaltBdgGOoxv
qtBfLXhrOLy061VfMXJFxojMM2BkCvyHGA1yDyBmcrrKZG59r/pwf0ybAIUuOF6LoutOKn8+Y5ac
Uz6wDppUtVUxGpXLdNbaiZfPLXQADEHSK4itAqAfH03i2GxLpElJXjX2nO/ucXbXYrcuAxnvZF+B
WxDrxJNucQQcC3du87xd0RfMWKFMH5AEdu+OA+pyIA1RWsIMwao0VbIkEEnB3/+pWtU7qtXfUnCo
VqK6mHrfFIhE7SV7Dn5QLapdBMU4dvy66JEpJGGjMuY44W4Bqm7nwUoPZBetCzCrKvF5fIWCO5Qw
LtGDPVjHeSxBnzjj9PN2K2N8gmj8Gi8AENsZxAQqSMNlMSV2nkejdGjXO10qUIdTIHhJC2mOEeax
+itvxmNORmv/2tG6Fp7Lv6Bf00Yh2vaWlLVNUJc5Pn7WETWStwO7ycNtMdRr4WaiBOfMJ3OAqFqt
To7bJGLwmT0Y4DP4Etprzh3g3PyJDU4YpFR4SyQcg1U45yh9AGEJcVD3PruHUwjN994xJg9XU6Ui
xV+eBbZwr6iwUOuu5HqPw08hIYusLI85MGgzxtipbKe2+jnYE1PNOPzr8PGMOu9RCVufIVd0+/Es
pS0omwUPZhMf/QdAJvmPcA2vjRedAcaig0ItZ7TcccDJI28VD0ZGmTFH1oXG9LEaoBtaUdCoYtl8
TiC6BKJ4zmsDJotV+SqZqPBDY1ssmCCHrCOx67o6oJBkIoh7Sie4VWeZnepjOsd1hgFbe1mvXj8T
RkeDq1YNV1vliDVaZ+SvXtH5/FltoGvguFeJuOdvG+OVF2XTQBNkDVLoV0rCMQRDVlTydsI3hq3S
mF/Nx2wYQ52ihgUS8w/Tf/NYOhVqPRRgvxj9RS3iStWNqlZwxBswELqRmqw09Io9PTMmuffkSlvl
XGM4c3W3OsWdqnMohUGDTHsZ1AMnngmbQ26IzqapUdFmIgzwlHQ5PEi6rK120QYJm8NaGbDp/wiP
oCtU18O0kqQJqkYWw0aSpPBDEWVlsenDePRgvUDguzxyUCMVG1qgOS4Hs8puPWKHiqVgzmFnuthB
p8+CnLtVl4K1m5IO2w6kcLemiIm/iUE3fxw9+Fnbv+Kfi8UlnnCGLwMESQj8cDAk6MSMYN+RyycC
A3WytWyCa+oD1F3blUoX5kISOCf0hjTmwBLAdQJ6cBxXZFQ35Hr8h6r2grweIGlJfjaxNq9/CbpW
NGLf+0CKmJq8Ct9rhPkQ0VBWfvU2cBHBYPvLCNeNaEQ6jZ6xmQ1YUanNimZK/czfGe3DzXbuQ1Gn
YiWvQqEe9iKjYOw/k10glJadW7vMvQZ5lpYOtShvOi9IudoSJjMz/S5pv9nk7i3u6Sd50gKmU3ri
apxL8FlhcYPWJzJtnhGRfkIL1FrrmxLs3fnQ6pHkaNN1VrOC/1eUsASBVkH9QUDacbv6DGVqPT6A
yjYA5pwGKz0v0n04aQQ+0DVi4MAR2I0UNH2j7+l/ooUqzgfQTn7iH61XSw1gp6HwLf7aHGaWEy0N
ZtOquVFG+SSrkEPE8WBS11q1SY2LM7HrS7G6hcOV5FsR28h2zorgeGR/42kzNWDGaoAQWL6BLyzk
l3lRkZOsD5YlbxsI3PhCt1hfCzLKdB5OBDQqJ0d7wKinsLA5v/M6jw9w/e2eHEkMuXLXQ6XSNqDQ
1n933h8XBX8DPMqqxJRigc3E5gWElwdtUYRiqVoYGXdwO4btlcNSucNmXBXZwOBKGKcvLNz1uEG1
8PhAfa1f04nlzJXaWdTO1KlozboVBgy8PjbkWkAD1kwzxgcVSk/GsR/MW2f/KOoW06bZ2o6cXnio
4kxXuqGTFpYUiSavsSeX4e4X7wLCBqNoPpWYS2wDXKyxlHVu2UwXzcGtgrDXRyhQiWIeNRAB0jm1
5v6zNUrszry7Zve1lEztfCgXDA8DzLYsy4bZ9wZvGyTvylV0h0PU8rI/mM/Fj9hYojun+fQPxfXn
PKdYfyGki9Bqc9UmVcAb9v3kHicUiKMVleUpl4YxQz//WPlEcU6iHgeF2MnxZdHqozjphzM05KUU
nWovjfE46WQ5a/no+36bkn8oM4JbmuwCLWzvv/zKXKW6LgR2sOLBSzCzHDyupDMYmGmQmCYKf9kN
pb3KgLHJTxdepDi/1HNiNmjZkUciFjQc4aCcuUjUR9gAY4yRnejyR+3Qd/KQeuAAhkosYe3lkyAd
jE/b7mk6go5Ks/lyzWBLhsQxtryG5ys0N4Dx85CxOqK1x1CfgTHTbDlPoIxPgslhLi1WbFBaxAhz
R8Hv97l+elX8YCYbEnhuDTgprUs2b8fsKmqyw1BWsK77OuT6sKrNOomqRsshR2Qy7gbF3703QepX
ZO1i+oT74zAOWEfzaa+Hw2HjM0ryIB50QTzybJGF1XqSBLCbjB5VXOKywBVoTlGOxRteaRhEYbqf
zBcRf6vou+c2xrWqO7P24Z408P32nWICskOvvHh4ug26A5NUhVp/LwjHOWTfTPjE7ExooZiBBsfr
gRi6O/iveGyRAr8v/QwdGPmUn0C9rG7OGfqMiLwJwTo6+q/AD7rfTUtUQEGJsaJHf06xuvf/OhEH
bzt4plrs3uFvkgvpWVcQdi1H6ySlvZqQFa+ckgG21dgLrXc9HS5fPh47u67wleGV/0EZkvoVbNYG
zuGGZMvhqVeB2+QpihWuplionR5RneGy7zEkfkOzPwpyYbcegg6/fa9NUW+Ce8EDr5H1nJTTEPRD
yD2CbdDHzlg/IseTZx9URkph+r01YflXkbOInji0w3sVn45Z5zPTPBKy/AoVLpEpiqThKZLAxMdc
DTeRP8GpIO0iTtRzF1ztKvgeo1uDvmgvayTZy2HSkLGUwX0/WSLwyKrVGfY0Pjsk0YPaDfNYatgw
Dw8OtmZ1vICu3xG7rsGcuuSpG0TObgP+f+3GUqjmaLTlrfuHiamzAW4W9QeqXbBM3nqc8HV5Uw5p
yIUnOQUOGXCq7k+dwz7RvPrYD9b79cFKj6w8aclRuAlasr7bMAZH8tUp7iIKErjNB7ErB/UTKN+A
nkHo3ewGiROeUD+EEIgRkxG9o8FydACWZ3C8yiMWL/Zq3PfDGQUCyhI/DcVJbK2RhjgMjsPJ6Xv9
jJmDhyD9G6QD5PyHSj5qoCMgf8n2qi24I56pVQAJaL/fyDQGrKaRr7aH4papqcV7tekZ4NY2A34J
/8nRiw/VbGSwIYL5LgaejguQrR6CNGtV21W4YM1rYJFJCHnREebwfoNPKd+4M/ThCz+HrEADsYQM
L25c/qcGQZy0mUR3R5yoH1DYzjDdGhkHUrI+GS1c6mZum3ppZXmc4ApfvKJ5hW4uD+Xk+4Ip9aa3
CWWRkDBcFofwo3sDnvtntI9Y6G3o1SVSEQtsEvLm+H8RVsopy1poj/8OnQhWihF3EMgqkEAAMAhu
bDZ43bzu/6I1ojWMGjk5zD84336+cNXHGHl+M4CzQgqRLOgSr8A6nPx2k40zIJL95xpDQ/yBzVoa
iGYpQQR4/HD22gu6OH0xI+KFaN/q3JBxKARPJ7COIC5TNUOzs1HG5FcAzn5Kl3bNtCNv6izC0pjh
IgqB+uqElpyEvlgrqxtphJKxd5m0N1yomMWWf3ywq9sO1wwATyMhdHFyHYznGOr7BNzwukYYL0R8
2kHuJhVt1FRziXOBL0VSZNl8uyzpIaHGrWemwRuqdxlnEmeuS8ywgaYilXCxcs1Dqsz7zOZ8XSS5
SVEnU1Gh1TNXchUgiy7vjDR+FoavhhcXaTvOVRNbvXx7/KZ5FVqBhzJIUzNqrpgjBvevBF+e1gr2
55kloDqhhiNncoz28ASrYiy6b76b9oSA3kovAHE1UJuRDd+4akxh1SX82jzIw8x41qoTmqP3BhjN
lHIFvUxq5UvJYVMTA3wmUxY+VJ76lje7DFftEUloHDsD5LlZuhbzHreqLg3qSEL6b7gHTjaYgD97
uKUEEMdR13kayaxoZgxE/2V1yemZOeDFaY+EL1QrX7RwxopkTKgXK0/TZIxR0aTEVPhAZTpw3XPt
bKoxW7169GaeWRuVzfaGJNWVqeEfPeDf2QYS8moWgwUlx95bOmdOaU2MYZZg9dipt//Pu8CIkBuQ
ixr5z2IxTnUSqSns6JWYXQDeRvBmd8DxKHURmkvmsJphlHQDBCCCt81UR3nb8tLojM1DJnY7fZDe
0VFjFirmDjH2zU6BfS2Qzg9MNnLp+mMRhLA50XGF8nM80skhzdf5v5hjWQzi8w53Y6doXA8glTPR
E09ydDfZ9V9X7EOx4UpkfHR9R0lhgs3AXHTdAIlctw7KGqnCJUdmA9ZhzQokvHe8RDWbPTxzNFjO
l/TzofqWWF8tVurfbgKtcDkv/UFb65+Vkn6/17sw3uTAQRKRud+7n6OADn/A/02e8xoND8xoVr6q
4vSY60/XqsJm4CNXCGErSt8jf7NrhXLF8ApmNHfTmTMeY09qt0AwFawdHpywkFqeoSVNju52aZhm
nj90oXpMv4jQreoYUUuo9BDLUAIdPGOAbwDMmHcAHMYgp2s5m/k8heG/V+G0LbZ4HpppujI/W9lM
G0hEvq9ir1TNRe6KchSQf35R4Q1zNiRpNkEJXZera27lOsQ5Y5lRhV5xnXvpl2yDE73r1hYkhLpq
mEtBljuKx7XwMG8Sy8St3ara3MIiwsfhhISTJV2U0TRcDMbtlKrmJUPeDpIqAesw5WvdZqgFR11R
TVgOPIGa50FvJH8gscCJUT8HG4bFoSYLBwZoGvZqlIZleNeL6RfXDnwTvsPwdmqW5sNTzacFAp8T
oB/8Q30Pogbv0yCR6gopsCOrqSHVHJ3NfU8xAERVqxYYkaHUT/VP2Tuu4h7uozWDUJe8pwJu7+C0
GrTgep8AVxNTvNSUcXwQvsfDlf385mfdZpdBldrdYII4FGgVOl/hKO0LPV1SOCuzMxA/rKQlallZ
JAJLVSV8oxarEuZCj0omSacuYP2e6gY45aI9uL/jV/ZG57p5ntjARxj4qJWYGSQuHtZKUG7Py084
v3C/zsSDZG41ZKU/TYnRmOhYWl/qQmJl0dIx3zXehUuxx9JtSyhvvYU9G1RvXYEylj+mSyZ/efDS
veDjcDuOOE3iL0MGhWq0cDc6g2njd/CKuarFrtiwfO/qntjMXCjy66shtmJen2rhaADpsa8LBlSR
CF3pUd8lTMqswmJMv2i6kOXUICtc0WupdZ409I3vihu9oTfUcSXsew1e8rIcsJRMZ3uC178Q5r4g
A5pzUzqAzIRiIzVKI2380MhRMbXFNHiZg+YlerFsPZOQRD+S2C/7wNI2FFhl1rVPZ06unbsThNS6
8qaCWg8jP4YpvevTJs2bv1Rq0W/c+fGbE5+pbFqKwshsx2YZoae/AUluns7yN+hrEMtEV68y6p6I
duBkRFxyybVx6rw3GwP91jpRVWJgp7F/JaK/d51/LifU0VPQbjP38nNz/h3p/prqjip7roqp5jnm
5kS8rHwoT5xbSV3RxBCAZU147ywK4gaVDK2s1L5vcpyPMf+aTr+1o114XfsLrs3Uu6At4j+oWM33
uGI/7K3xFYtPUdpiJDLLFmAzPEOCa8QFBsVUaqfNH55EBMWcqn4lK8+M1mHZCIj3ech4BasohsLL
czNB3zjZgkVWdRAV1BGt0HbdIxgZ+RrN9EBXuofGgHJMvdYQub+ynempeaqneI5km2bmnlez3Q7Q
gEPp7opWWSBoizywaNjqHoToZkNM/TQGrQYcu16JXwTP4aif9PxQjnWxkgeRajvWTRI0YgRrCImV
hMyhJO/L8m53kQt/sONc6osatDCuBjLwft3j0bhD8N9FQAaqywAP/4r1HYQuHbmqc3dH9l46Ps68
xzKtLzbVXLtUSlcoixjcCUuq9q2LYg1r3q+D0CBre/9xWA9yrzrW46wnKoFsZlgILY9nSzbYTKPF
uNj4v64XjwiQk55VagHF/Ds7UVN5Hx69aNG/CFw118GfyHBr/T7ULgDdRMIyxsXa8JwdSAKbwR8x
eVIhmiJYo7IZb+bao+1BgEV/9bU/FhaVPuBfxYA1GizajC4asueIo95wJ5IBFS/zQbZE55Jdgmd4
D5GvMNfYx39AHghJhpma6INXhjdsjKCdRGkjmD7gXJDjhstHTZdYDY6/Slj4C/PJHJonAOhGLX71
cpvb5sNITxzUD/WsFaUe+bDi86yOluOyTYf5LTYTuSRe8KLoVg72GKmi8MQE3K/XjjS3wRD8BDWu
z3Owb0xfJf/f4gyafcxursv6KeT4tISFgARqDbgHqyqJW4xPdiQN07xMlcuxH71TjbZK1OJ+Yr7W
DsDCWTOHtnyg+MpAzmA8QgVJqVY9tAfJnF7DvDX2K0t+H2ULXHio1gjvzz7FkjVAqB7gqgVwqBUe
PH+6XyBvga+eAHnYRPv1SMgtEJa/eWoBcfyCrXluReQJ3CK+8L9/+KhrQnx6OPEaWhPrFvzsTeJx
XbF8+DqZai54iAHc8t+2G8CdccWzVOTs5lqZdV5jfmOGVjpNRYSbF0Unn3mHjEPU1qNU6RXCvHzz
NdUFSxBICJoU65k6DGglU2ehjz+GraIin8FgTG0KuHNJBL1T3tXeZm49BdTEJh/MpX2nHhGZHLsx
Bp3/n6aR4v1msKMvR51rzuJ2Q6GM0gzewfHwsIfIktN6tYbg0IfWFCEHiCx44WEyD8MhCZO7wgin
zpWclW6mz5HqHj3GEuifa952PTrh4sZKuYMpu5S9U0XzNqODFdLOe7jtfNf/mN8EkjupCje4j9qz
WTaQpCSA4FpdObmykP3Pm/VhI35iJxvJOAet6DNeiIzJovl6qKUwG+P22cPHeF7O3rPPgg2/f6s1
buJhcOchyZOhFVMB8EjDK53xpNEG9A0gn5OtnSi3DmWNBlKYEHsiqch8E+4GuB9G/t6KypSnk657
NZCfwjCn/B7o9mPTL8LCqQJFjf/E8ZP9xLGiVd6v8uItzAjbZMFoAMEV6lrCAXZyXxR25JFch89f
5iyslQuM1LhAGlaqEx8Xf7QmMwPzKmfanMuyBWoQ7gSjiZ/+qExi9zxxGpP6PkgybFoJcqTaixvT
zqfpwBDalUVfWozzpiziyoL2ZZj/a/hd+k495N320PKTeFnW00WYtSUpkH/D4ezoasdoUru9uud2
k3lAH5B/LyFD58omXEveBMkOytI3ZG88iCfNH2dNqbNAwSNoJpO3ySm/93Wx9pEIpF0OVf2I6iEe
zR/oZjdM2b9kSbuDYLTpWZJusmeJZYbDD6aRZKs/8uOZDgI9oVq5YdR5wsug/OzbJhMZP+m3CBxL
9ROhRV8AzOMfYXVQUkxrqZ7g1mcXZMG2x6WthTorhm0/nydaPBh7t+uq2Le7kpe/3ZQ6lb4Ar55s
04fpC1/BhYAcOEjgdIf9M237zByuNUopeve8aT5oGkUvpYuL3nYifT/aeTmT0UxRrStWVQaaHwap
JzlJL3kTX9jBhNuxwjY5Ww/9pbhH/COVrRDKApEP+KuvawLhaYnsdjXV6a0tgu+OfV8Rj7kVCbx8
JhlxnuuuJPoE8HHlIL2tADiYseMaQI+dR6/aaXPgdr+8+dlIW4z/M+fCVi9GjZJPF6tQNP9W31hx
uqTiUFQ12DES0SFjdgGvBgiOiS2TAsePfwezV5R4Ivko5a+lO9dD9CbpCd7ctjZdtpKP33O6XNeO
AqhxtCW31WzVDOt9J6YTlKnBS9loamvHB2ptiKBrvqWLkvnBQk/+BgNJEOjg3+q8v5Wll5Rohl1q
hO49u4IL20KY8/fxfizieaRn9ac22FPBJn6W1aBeaYD1zixDN6CegkFqJyxf5UZPvbq7esp9zsSZ
EIE0ejF/T3PtfhSbdUBaD29FiQhqNntItuFwqFxpx0JE9CKFPyMDHgMzVZoqnErC4E4pSpZOXs9L
6Sexn3tqAuQwUXI0oj1P0r4xAo+pGE/VICTvkAFg696phIKXAB+MteQpnmZC0a1IMNIiYOnztY2b
rI/N41bG4Qx2f4RzxXzwGRDqAbGqvHXuQg2Cpqpu0ohEdrjyu7lMfA61/f+M4iDByizlOjNI3wja
g8nC4H6eiT9exKbyxnPRn79vWXEB8D4KWXSh1wWLppznAupfAB2XiAs+kSQUVMYp2bru06BygCLW
DGRs/kE4aFCUygwp6EGxl6vJBSxTrBdurFN/QjSbI55EjD0XGpg23bX9hTumlQ/DmXQVnRNd3tyP
Tz32pXCcnWBl3YmY2a9EZUX4wsjuRsHM1kATDRx0Q5mP5xehmKeRwCNnXsXIl20gAxHcuafq2FAD
idHSGYBp9JIePhrebyAuTQKjfbV2vL76nusor0tjYghcVvkEMFEF9fyffvotzhWvg7uCkvk9jpj+
p5NlPZ5D7D7R4wUiVVq34ghgy5LSyzmsTwuxN8zYZZAezocRVUW8mF8oz/trD2RmarjMBB7moLyA
34t6bf+9c4PAA6Qch/PF72Z7VnohHes3PmiWhP5Aaot2/xnayI6oNVYfOApTt5+bvCSCAWRSD7Z1
g7FS6Y4JIPvMUFnWfnt8Cky2Lgor/J1bw3reFvzaEw6owMg2ZDTvxeFf+pZUyquCFslv76+jABD1
9I0jJlzn9axQABJGdG9DZFd4Z4sMsVa1s5dXQyLgwCHL0NdDbIcA4HKBY6gOLetQhx3cjrxCfOxW
W85TsWVUcAk1j0d+UvL0x6ZnlBQhLvUQIbUcwGpNntUOy1JWNgICY1O4yN1X/pUJ8Yxl4x1RFi8I
y1stTzQj7JL4s4uh8krbNpAUckVTgABrTNchC5u6FTXC+yP965Qlmq9Ne0R+Gkc50OMVWUO8HLw0
naovpFFbhMoEHhnbR4ooADWaJFJJj4dUrX1r+8Rze8gob+V171owsNdM2o5cDP4JvqsB1t41bvF+
GnXAO9neJLZhVHgMNfkexZjswn26SWTXTyDcaXSylZzAhUJdr6ok9pU50VE8iDC9Opp6LthLu/xc
EkfErHXw59SzyCfCBI3Az5YRASrCx/2sGNtOoX4zLRBiU99HV17TY7HxVGqU2wRPdj0rVDWYBJiX
nKONX2zar+ImrztFCCdvy0IrEauc83ApYFw1CONAhuNtticoiTMtB0gaA9abTkYpeJj8mFxcR1kl
RTwBkWahLZ4Fg4XETeknwP4U/gaUMyIg3oAtLp65nEZUUD8dYQZZTapbRJfXrai6ECeWGt3ROH7i
ZK04cX9dERkHcTt16E0WtbaKnqxUpULUgZZjvrJjKeA0YgDGEM9mJAAcz/eJHC620fQzi5YH3tbc
snacnaOse57+d59pfKNN9GG1LfzCmJoQXXl9n/RFRpDTE3aRl7jj9C3ZQGT7iLzx9WKvKdTjndmJ
ij4GBMXYotYib/W4hbedUI/N3qemfoEXru4kDgps+1lC6O04k0zHcmWtJhnDVRYJyQ1h2ff9Ee4i
8z0qw+Z5i074Dg1MzsPZ5QDloqfN8ixTyAkhpmb52nzJo5QopWnIivETRojotmh8Hj++RQ74IA9K
aXCzPuegWHJdfT5BaNOutuv9u1iVf6o8McjAwpn2oeF6ORTu1A72Ff7l99paFwi9y6vf4aYE2gWu
OzstM80XiAh70CK2Eald52VHNPGG5nCKrh3dylXZsciO+Xz9ImSFmVyLvElynpJKBA65dwX6mZsf
HhM47ap+KrOhV/lwM2qboxax6Bj80g9LblOYrOlfhvrbmRfkJW3km0TgbmBUqEvziWO7v19jiJaX
LWtRRi35+fqSzgKg98QnnJg5SnDqLQooEUuqm0Ss4XEQqqJqb1WrkfDe3otZ+Wq7N+1psz8hTTFG
GBan4t3YuRntnnPKp7XfnIsL2Q19+Rd6YJ/floDHPqJHa/EucvfP9SSupCZCtu3QLAjnmMn0yLc8
ho5emOIfzP7WexmbzbHilWBKngv+xqK6AjKUXmRrqs6ZH8AXSDCxI5Udhj9khUm/ous+0S4MDdv8
EwWk9rHwZRy650WQBQvwcZrQtMfqpPmbtgjJN6zl7Sop2YiXHmHzforubHCNHi8BjTIMaK5OeFO3
jlfH2wuuY9bpHCQ07TeYXZ0x7mnUmx+1ZvMJWso7NKW/L3ntO/xTqk6J8MOBc3xc3hZoNioPAfNU
Wd0SrmJ8p3A4/6c+xM+/9xm/2iMIiC/9H0FC7wvAUbfPwgFEKvshcp8E14QTW7b0UrwxTvmTeOUD
hyejuXHYvl3eoEssmdxXgqLAgrxl2S9HyavT2lsQrZ13GSPMe2/w1LL2t/f9uoQP3WHIRVjYckGe
EBKlc8jUCKEtpAufpKa7yMDdmJFjXtGJ09Q9UTQiIs+TCm1BMe9c2xixFgbfTdZfO6rr2V9nb90o
aOHOw1urNSl0r0YkzGx6V9D7Vz0SpFdf1zxDs40QDjj55KXXSnWG/RY0q9EtYRUdXf/Ko+E49rxv
NWwDU82k1oLm7YqkLXsfzcf0B5qYdQbWRjjbFLUUQf2/a7CIzf/DXo7+9AwSxx2NQgq4BmY9R8CR
ZPBPQSvb9JvsgT5w3nYTy25NO/uCuXTaqgK7ym744le+7vyuhcaC/Jz/pZfhuPejVaT3oJY4x08u
VBOtpJloAoETp/b+mhKgnO7xqKsALk0LOCkntj/rxsiChk3EGuOYpRVluZLKbFC4dqoLynJRCRUz
bX3b6cpwOA9rLz7SQtgadazFITfatFMu0yWyve8nGaN9KAV3Zy84WGvVp7J8acP5MJRUMFqXYwU+
dqlkU/LBzxod08fxnEjcaJ4BUPL0mEfhCtiZIJZodM2El7lyFrs0r3x1glJjtN1+7W/hV6CfGpPo
QqdNsLKnf4R1I6BSI2IKd5mUA2r7sYr/YSBnW6EliWweIWEOLPtLDEwCMaUg7fuiL+0vQMj3viZP
mBCtmTVREKVEPLGRBvSXoBcwcRInIyuwlBnwZxqctU89pdrsggU3uO3lZcCzk1qzByWwvNzyBqUO
/MIo4ELIVX8HW4muB1ETURjVRLX/qTTdATmWBTKQdfJvNF3ngKW0yrDLUnh3ZWWS4ngYnSMbqVrk
zeDGKBjO6bm7iX7eZSNVtPnyFdKAGJ2Iwhm1XrxLNzSKiUnTshtq4/A3+Po76ZnMEetvPF3mZH6N
FDvf7noUupmbHUhlse9FNYXv+5cRAMgTC4+UQZf6bcigjn1FrHxeJCfo/MyNf/uU/qQ6kzt7RCUc
YB1E198UMo2auje/R7SG1AhXs70Shf4GHL3eHrbFBuYxSkw9VTYTEyEmoG1S0wsoGOTsz3tyhHs2
KmVdreIQnm4SN99HV3nIsVsU+H6/89WKjO8GbBAEBkiV2yRRDfmwZxNv4tDdD3cAaxOctAXwVSrq
4QAFA0V0Dlbwhl+fIS6d+bXVqfnI8lp8u8+wB6ia0XQZrD9+b4154KQY3aPYichUnaA7mZfGFqkE
XHgvVgtNIQC7WCFeb5kjAm4SopTw77Cyd+D2SJJqFkcda1OH5324XjFgxoirAGX1LCdVCXvSS+V3
2hs8GA9HWLMo8CP8vA2jinBx99rfQcH1lox60Fu00rfEk8KSC0eD+CgTaYWYHaUpe2lyfbr4iUcG
4WproLIJg1VOk2VmEzAO4R+FLJ1pFjnEW/CE9B+TcNd1ld5P+40snarKtzsbXcj050z04GvgXQpD
IEi9hgVdzhRY7LjiDWVuZHN0cmVhbQ1lbmRvYmoNMTI4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN
L1BhcmVudCAyOTAgMCBSIA0vUmVzb3VyY2VzIDEzMCAwIFIgDS9Db250ZW50cyAxMzEgMCBSIA0v
QW5ub3RzIFsgMTI5IDAgUiBdIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBb
IDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMjkgMCBvYmoNPDwgDS9EZXN0
IFsgMTMyIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBb
IDMzNCAyNTYgMzc2IDI3MCBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAv
SSANPj4gDWVuZG9iag0xMzAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u
dCA8PCAvRjE0IDIxNyAwIFIgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIg
L1RUOCAzMDggMCBSIA0vVFQxMCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAg
UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTEzMSAwIG9i
ag08PCAvTGVuZ3RoIDEyMzMyID4+IA1zdHJlYW0NCi4pzGMdNyk52ZkEMeXcnZdyGOoKRCfKhKg8
K3jyEtspmspLEsSJ1fNVINzhQ0Rim9C3PD4Jiea3G/Kqv7IvSuKUvKBNvrKtiX9U1Pnd7IkVOWlh
cgysHKlu1eFJpU8aR20MiiADAR2LhVF91dkFshftwbMXUJFg0jKoYmj90+bmUN1P9MOSH6oPiZGy
NypPJIBjj/x/QqJB3XyiTYsOAQlywarlhb9UPn2am6BG4BXfpYYqITGrWx/gxaptQC2aV0dYZZPG
aYrNR/N7p3r0g95simuJN/ipKSQk442UiTmhj4+eTTLTTjhKE1G2ppHG3kASHe1kREkcvFWq9eKC
PonTtpZV6cOMur+B5mipR6MyjBO8lVEpTkR/GzNPMI3PbSpKrwlJk8TV+1N1bCrH6RWBWqrpG4mc
ZQ8GqbYaffJCe9UV42xmfqbYCy8lgzhIKfOeq9bNrnu/ZgGHF59AoaMDqkXenR7nI2g7AZuzPYci
EYjqiLYcKzZCkXrE+t0UXvuSNcx++xlKx4iRUyWeTyI1A2KNNe987ogtEFetO2E672FNPGBR53bG
BhZfM7/+htG/jQtYUCbANNx5YM2ys4WLbWygmt3kQcfWYfLA+YPqUL/rdc79C5Fh+BohXRmHgWcm
0kCFMkm9UoHAtzGldDDsPSqaN/vSFxF7VfLkOwTH7QSLje4MpNuqNZsCEMCW686SGEE4Iuh5IZcb
R8qZu3uz5tl7j3Q768RQDMlaGfLhmQSTg9HOveFkMIxtRK6/mYVKJ2epX3bnB9pDmbd2trdMw4O6
AFlSiRcglBwkO4Dsvm+hY2WktYHTFSmvjkj8wxQOnDse/2HBAjBERi8tk84/hXqWaP1abhoh/xne
Y3sfOXzZlLrKFRMFsOvoJI8cnAZ7vB5aaXXs5htiIcrl/R49RsV2vce59U2Pi0bZ4Sr8E7tjCM37
jyVaB3ZYBPQObBHMBT67LKRogghS3dof8XgsxWYvtNzcuXSQwzBSKorNF0HTIGaSp60cK0cDzSRM
Weg0vCqKKNVTi7ontDa00GJqwJPfPIWLUQGF1wvWi7eQjtjw8ncRN6MQGWPNTTyg3JUZa49gZSA0
aipdc7nczZtFpqQ1TaMSIrdU1blamU7qSRmYZvV77x0OCzB6sEa9NJvNJH17+ptKl3rXTCCTLknk
SVEQLFdod+Q/r8PhoAC88U+kE+pL/tIaMWY0BBDOW/gcbqNawfljwMKP1CDHWvB369PCONgIqO5+
o4enLyz9lEZ26EEiHJzUxEXwGPbCGMMTya9yLHZYqtsHJOYwvSKGzkmxsoIOSRlpkupqodv1/pmM
UdaGD9FrrXNlV86ydfbooDQSXg/gzbA703EFdYVhmvu2tCcucVK3aV9YsabQWp/uq4zxfu8KaOYV
ctrjVx3+Pxx91wBQG7YYAhbUoTR7vS7xIn3/dBg9ofI7HqCx293o1RuDJacGKNiTGpFaaKC46ipJ
+qGcQaaXdQqpAt6groga3xdwgbkt052E67F/f+34tgdRJUb66qhqmZwVRiqAEm0L21BIJRRGcsS7
3csHR7HkBrtH5DyszP+XCrvOfJ85jzN9NMdyf7nGN3bG1pC9v1rse6lHxuRgUy8dWYK79vPzme/B
jK9ZfUfVjPhOfPsfJiK5H7Z3Jr20knkIeRqleJguPK6srtSZTRHMx2j07uD1sVSDXUdT3s9JGiua
ALz/3F2BKqGorxgXU68myk+fr/iOdDSesKZ2OL8esTmCL4iLK6UE5sLp+fhx+2QRKgWg1WbPFGjU
E6omNjz6BT2phUkg9ZeKMgUeiZ7oknUzLZ/0LtDCIGmtXgRoZo60UK9Lyu2z2kR2MKBS966fsqN0
fjDPdpUrpG3HafJ3rBMl5Wg6a3ujOWFJ83Fu9wpoRLGTaIIh0LXCYozyZKfbREu3IJ/B/kTm8A69
JpfR4OOpZmGTUd1b7+4zoYTIgsmjAtJJi0lpDDmqO35U/VS9SlN5ec5cpGgfLVStaCjrBfaCQYvd
B37iZtACuxvvpi+2HmUan9wgCK2DxmUc+PT2wBxhmefTuAGnarGU3kJXaHiIjHD0+lLsPokx4DVa
eOZMDZVt0nlobeo60CPtvQg+9HKoStHOFWldhUEMF/pLKl/0jtf25sj9QvRckw2ApQPTUm0Xvxam
ym/sck6r7grHqojfjo3TjcFztMIJ5e7u1zEIKeNgYR/nQHB3evZgaVdl6KgHT4bUCNzliym7fCjo
78Yh9k5NvQypFM8zYdee1kd2c40llhcvbZvI51QRwf+h2iTGewaiFPlq4KROMzotn6wWMGSsVIYF
GB2jpRUS2PGvv7gQ3dGeJC/MpiF/bJhX7DwCcgM4JWw98KmsY+LCUR7tmhLUhvOJRjRLT55fmn9Z
IivQKhYIQUucTbGXH5Koqslh95sYysyRs8BYyunWcAeeoxJJ76M0cDZ0nsR9k8ZgJz05n+CcXjpJ
bYKO2QIRA+AtctxBV2BNcyS+v2NGwg59vVgjMAwl/3FHQY8yaPQquN2xWSQ6FjLdYMpH+5Hk12RR
RAteFsbF6noC6nE2BFm2eFpa5/oLdpgOSyx/cLjRt8cchREVtdRih/GKUTn5y70GwJb5lVvdi//o
Ul3Z+zwZGEMyD8kWF9t+aF2IEFzrNfh5gvi1FydiJ+0osFS7unURc1lKzf547oU7MrrhARsL7x8B
qnJt9werGGMt92tG81MLhxuZSCv/LxsNTMB406EENuWcr2u1sM3U2gwtoiHVPzrHUmr+v56jn9K0
M8RJB4QYQtnULSD3nvjPZGdBmkDMZ/XsQD2V2pG2jUey6U2wHcuUwFJYiQTXjcvsv1S7/kSEADTn
pmeDlUX+Hod6ua/KOJeJ0TA3Q4qHWp1/uVxgsy2dEhJIzq6e6q8RzuWlrjTobjl9diatRl3SrMO2
+H8QgWC8eEtutTPaGm3oaWiuyDaj7u1txFJe4tVjzJWoGHwvGcV9aOGMBV6ZZppIVbfZ66CziWMq
Naydsy0wrasj1Q1aozm3NlURvMSf2NZdVlTCYDqJ696ejdgKSokd2F7RWVbyjE50hezhPDgD5JQX
Fpb/DMu/T0GBNGV1DZhFsOspmDnteMnCsL2vywZcT47Exh52BU9SlPXvcDaAzjGidV6Z52KDteME
wQUz3XuhtxysHoz1dA8hZriDGyMMvCt/e963LKiMC/ZJtt+T4LA/AlZfLsPNqr7YhopIQoQIYj/a
RcKNzhty+TwC+irccKNFrSzMMjXXX8jhhDbl+mEjdvo4EhL4vWJVahE/J7GLkQRNs4eM05z6D3uv
0aXkzn6cPMyQvcYgbYnCPFM+L25yLqEL5mN++x0flk/OwilrfTXvdZr0RPQMk4mnsx0Uac+/qTVc
19ClTgxHKrv+BLdUOhK1Xp1D3zoYLWU4dhoE5672a44oMDTzlYnCNkANF5T0KXKUVvpIoapXOfBC
UsrsKBEv9ScYZXzhKWPnC0Z0T5sgF5YzAgD63hYxXggGQ3ZyPxtuRaTV6YP091S+bSr/hXbTln4U
H0YPR8/rpNoRE74hP8MXXo+qbQGzbM4Z+S56Ye6wuMKth9fVNbroqP9HIeMJ0l4ZMLWvX2/C2Pv6
EAvcnc6ZCp7QYbslSqDCEwFeIrbWEqJCQhasEQmEq86pgzF/zjKzY5u5G0pqGKi7XDqfZu23av74
DPdgTTpXCyIKB/ma7GnGgTm6sam7qIwkzPU52gPs26m/sKoC3flJtyuqadNMv7pa7hkT4cqYO93n
F7juqxXSZnuK/PVSBy//PnJop2Us+xHzZYU3MhurEn+N/0+vFLlpC1Zr2toLicL4EutTfTU2qRJO
6hwvgo7rBiJHBDaS7dYWVW+I1+6GFFYWNLM8PnwG11kVY9sLKQGaUhqmQNzaAsFDig/zx8HNNh6f
yPCgPhuiaQT/c33V7u+w95lsa+WGQPWpt86uIJxtnnh8Bc/ki7rJ+XvBTimuFXEJPK1ttanYZI7i
LKRFlk7xpKY4Bbr2cXLdz74R9FSyuO8YZGer9StOUSVS+VfLrXASOCOflfsYfvZLx+aUoz1+r6r2
uPXwKrhgi6cUCrVTzeRQsGJj3xDTDZes3CiDLZrYu67NCmFXXF1o6I5+ze/XGkgn/i8bMN3gaCr0
/IhlBByTkiLFCJ12HZQ8QBEbU+mj13MXfXVtZBFqgCrMOUKWLLinzdNSN3AmLNW/vGKqD6i/vUU5
XdndpTpdzk2fYxR1YKI3VUvpF5cpEpUAiWzzWFC49ypo1SB9dT05eGs4AAaLLwtBqAwno/QP3xgD
LtbMAf6cn7x1b7BtQ1b47+tSazaZR7fqIbps77Pij+Uk8PcE5LKmlhE3XWidUKMFwunD3AyYRgz5
zsOW49KHsWLD2hA5JSHr2WUZoGEOevxqm90DVwuUVtikvzBGFO+HhBh+sHWyiWIGhlXPbpisSBLu
Trz65Ca4wvwBXD0hMipfKTGz0unpJneBM00jK7UBhRgpIn18S0qlSS3kIICXbJFidu71DwRaUrAN
m0bfo3lo/FlVbEz6UMAhQ92Ql6+bw3LHIwZMLfflgq52ZJzdZkgu2WWh6xeg5nAfLpoImJaTcfb1
O+EnJ/5HyjQA7xCSghjPxmQFBRu/KsV2rAoWIfvsZkZZ4+WqJYjZGvi3cFb087b/dTk5NulgEwUQ
d2zrfZdNuVGIb+X7ruNPorJowsoV7PZmb+zqXPXiz92Q3HqlgGspCaOS87zU7ZP/Tqmzr824h6cZ
LTSVXlYHylVvlgPdRsxxfTjTcovbxG1lL0kJtnvoQ8Emg+5vj9PbMgAoeITPpdlJSWpaIwiaCCoY
5rL0SN6to83ecBVRvxRy3D+Af1+Qpsf/Qx6AqJDajV7hd8fZtYrHBZXyGzHyeGLAygiH+mHjXe9W
GKOXUaJb4bjogVAMYa6hhkttXFrHH9h5sYWJqSSvXPobqzRSAOX7m/BPCqMzPo2DCztFfsFF2IYI
3NBWkoCyIOKFN1/KFfNgKlrKGCfOIrYi/JZ81Rhxe1/uC/omvh0Y9k48rJXe9xrqCYDMMW7nNrep
fAt1NSmZ5zH7UcNLfwojnf5xo/65vH8O7chc5MxfImXo006yh8kYrTia252fWkt8SrYKgVkCrdpG
a2ZPzllqFKPdX0Fmpwe7I/okvwI/NAOZlstIqtDYCEGvae3QlW0eKnPE+cWzlLwfXhETMRZdUlML
xxwJbX9Y6IUY8VtXOckXyGCErp/AexZZLN7+7VJJb57SOp/1sz9Wd4tnH+uJX+LkvhkmEr1gpbld
DqUSlWaloTxR0l09O5d8Qmad3YhD/BfBK4pSebhSdNMhMey9hCBZOyF8Pv3xLtm7xYHtfZ3w3zMn
KuvR5pBdFkyigwwnPD3Z2wCkL9Za3MhtXgUAVQh5KlBg6w6elFardvAz83hkI1JtjShp1b3uJtwG
LOknU6/uakZ7t+w+SpZ1W/e85/pkVBwuxvalPdF+pl7FlrFo8sJBUp5KIeLi8kJvrgAwnX2n79qo
FDD1g0DQCDHbLa3PJXTDB/WA3ta5lcYLc+Ww6jxvGMdE+ZuPGKdc4iZRZK7IE+7uMVrtmrKYzyFj
U8uzgzC2FO8x2l8jx3chseOgzG0bm9JW/He5IqpkySX+YdbJXtvqc/rc0gIAgjgqaNIdjOGzj+x2
QtrywH4zb8b2wUOZ0CkCzCcBuxkPhrxeaLLn6/GItFWmo/HBfDwO2yCNasTzVI99wqBHP6GewFRw
FdUWk+UWTGsASMNvcma2lYEjmbWXV2dbLzFpijQ8YYmCjubUpfab4uGiX1VBrwqXgte0iCQ3FuFJ
+BCENy3dX7XFbffu+OwgLyj8dlFLA/Yzlq2ItwDIDb2t0LcRh+Lex9zDJyoBjk7yxbv296aF8Esg
noptT6VfI2RW6U0pun3m0eKsK8qP6hw8d4Fv9Ach4E+Kfv7fNUyejZdqNsKtOMMUdgnEOQ35oaXD
ySx0KdGDAIatel3fT01P6uVGoQ1G6I+F8/u8mOT5NKGoH8Gg03cLUtJbXMLCeb+n8JrMSAh+XC5e
8NFha0c5MF2KZ79kn17NP7roOQJHK9pT0/YNB18bi/DtzwGMmIBgx3s6kPQ0SNF/F7FDdah7/VMv
Gds3z++Yt1e6XNiqAtuFuJ/BpiraR/8/limhC9xOgiBl2HVL78Rq3XKv4zNokYuMcqA4vJeCsqfu
toM21kp06JykQTR3p7R8vUXOUQ0aRNHiRiODqyh30LBEKmuXfU7SqKlB2QMq8mhJAt9L4mdd6uqt
xUaqunDniDo/5LHeVHQMxoz5RY9a+mtb7qx3CAorSHUtqUMtquRd25Qs6DzQYpuecGaHgcN22ech
xhHMeBiDOCTfkbnHuJTUoMlde0vH49nEqtPCGb2lKZ3YPUnVOUGIhr+E/rFGX9Wo5FNt/a+nkg2q
J6gqOtULlP20FvK3AXKwf1ilY8gmN8mBIvz6eo2uVSwpsAdmB1TkB5TjBi4cgwjOTpyVW2jg/tKi
lwtT7/Kt7iE4dGl8fVUxO1TAaN3741HgIZqLgKgfpvZARVrWS1duUTegG7HF8KbG9HzZcJg3+kMn
xGDxEEqnwvCBDxLHYMUA5wXnBLHT2o7OtarHcI+0ZohXUAHCBMVvWYXz2M00ctdrijG8tv4+JRDt
EZUwXYUgbP2gbFzgeOjLc1ya5LXMHQxaLlnhKVDLB8nJYso6u9unx7kfCRT5QWhctCJ4AXL49TPr
pmm24r6fi0oAGXmW4Hu8VDG0CQPhxAhKPhXpDBRQfQl0glNl6COvnQIvouYbikvybLIWUZrup9eW
xxOYYqtNpcni90/T4mUiPEpwOEbdltdG3u7oBIkc2tvZy6sx10cGuhSlJJAJRJLUQ/7U16tCIao/
/AFfQ2vMJUoQvHWNaXBAlkQl12DB4GCTJjAeWwVBZdoCY+F4p5aFYYw/RopnUFKRp6kqnZzpTBRN
NVrpSsBPm6pKxJFIVkqQrcwD+8jwWvnjPhf/CX3t8134qsLLXZDUNOF2uF6ttmfVTAQ56ivXecvQ
+ucqgMwraTvKKFLKavfR4vgyDu8Ug3JWpo+iCoMm1RnYZARR3eeurdKcT9T3MHKUnAVUtqXougAz
EA9qRFTd7yCJnR1t/NeOasm32kim5+LcKYdBXxJxE8JyBPrkVzAVB3m3GFL216wcvPJfx7aZc2VL
1V85n8yW9/7ynTTGQzSYoFsvt2pfBzb9PaE0bthbpYKJxYxPch5ESqOrdEMvIwARrVWlDeMSyaDx
Ex9coYfln8mv0ize1rcik9pkP98ZqMAHMNN7C/wrRUce4qYPXJnlXfGq4jFIBsQbLCGO6HtU0FiN
QgwpmEEpDz2D783JdeuQ5HBYekX+siEbVaLMtnsnMn2XzDrlEVLIE6gSAA9ixBPJg+IkQKD3DNaA
hMo8Y4RFME8GGvEJ9FH5dqJocZxnZmP/a3nWDGbQ9V/IYxMncZiIylrtWZP3IA2GvqPLdlE3m1z+
3seuYLv4uQhPwnmAF48l/1Wu93VjMgHyp/GqQNuQ61bNH9f7s06TrFfzr3NOPzgQbBH/GPvJweWR
x9UtXhgJOpc45nz4kybabDv7woFUro0A3LPI6d/nUGohkv9OP+1Ame4rdJ1ivjV5AZ+sZi6K8oao
YehzONJvfqwjNvL0IhCr3hSpWN39S/TtdY/3BM2vcerLYhf0afaydOIVWej1vq5+ah4xlmL7Gygc
onQJNrXedbk9sqEvd+cHGl/hK8do5MVpMkBVRvAXkHUild/CRF1FY7U8AH+7SJO8F7aJX3gDmf+v
0xv6S2w56nQr8PzV6BfzPnS/pt5ooI2qa3LwHOY7nJvzwnFv1cu79Bfj+3LSeOaXwjHDi/bmdhKT
3fTWfXG6IaRvGzA0uvQyXzl9JYNmZk16WQswHbg0oJ7zT7WINijzHJbNHljCApCBWtsWPb9eCsdA
uvZHad1QjQx84PNfGib96ID7j937wTmIHnIriSpIpO3W+Uze3ZThK2P7I5GGxWN4b8A8LcryXHlH
8gsFkA1seMna2ZMRBkbGnOU7C1tJgEIYjdmpNY5yYfY9mnxrUS71NFuHScVPQ+h7MmB2yvKUn5Nv
nuWHRMfEwpZEBcQh1YJcmS+u9pvGWQKt7v14XO8zmd44KLOQ1Df5etP0YHT6kIslhkG0fUTRFUpi
FEr1tFFWR0biX/Oe2QD+6exjNBopYPgVR6i9c4WrUUY4NCeR5IMNG8J11G5frKHPF768r0U6yqCm
zXXdyaqDm/4k+vLTAhaMB/iOfnh/jl+3NH/b66NVLT8M7erT7bI+2jD1bEByP8LSCjHuEKDQ0dwM
LxbLKC0O2WpfxcrGy9QdlWRZETnb0F8pWVZwTgeF71C6ZZmiUNFtDMT5fYqM9ufuIuWDpTzKEtFr
0Bsx5TR2QaAF7gQtyeKfjAb47Yvmtnzzp7Lz16c/+Db/FmPul9vXRR7D0Lt22jCIR1JR3ilImye+
2UFF93Tp9TEkCztJ/AZqnuIU7cI2A+KS5NEkSctdG0oz+wT+mX6c7BMtjTXmwX0htBQCqlgDeuLu
zttK/MD/YLvHrkdaE4szoB2NIpkqE025UH+Cq7j6I/fxIlg+xSfmhYQjQBR0HLSZVjlvKXw1ydtw
ZuzuLeN/YVGXEJGCzTFv8aZxX7XkcFimpWiV0tWtVQReugdAHORmienNYMup6HKNVrGFvliOuMsr
+Pd1GgxZzVOcPl9uHlraIgvHiOLUaYObni2LfPfRZiqkx9giogEORpvKOQ1wO9HwCIz+Kd4mVuYV
xu7J+Le/A8D1vLnw52wK5XAQGZIecf6rhuyo0/8NPPKU+PoV/qDXBxccvqxjLH9KSf/u61aHokUV
Ivi2dezynGtlIFM0bih+GQCSe34PFr2VQDLPF0t9dEzGKCfd7uWDV79UANGj3ThPpqC8SHJeLfyr
i78lOChlugShckSP9nH+bwhr8BDfeEGUWsx9wKBLJKKEaPHJms47ms/HCzk2S3agauow0i8H6Qbs
vbTnxol9U/MFzC1CuE3p20CPT8WM4PUlvV8LkVfWfIhNQzPCB9NFXQ1xkWua6RxorQOktXHb5Cao
IagAx2+lJfykiNYtBVVU83CkosPDKKJBjMc43pxntOD/45iVz5e/MDAlEQOX1Sv8CgC8Uk29KlwV
+9WkcnHxlySxagmD+hxKIfvrn2WRrFBMb0RipeKxdHTc51SdLX7ltAfwOtodCALEOsGJhcqlkIWF
7U2XACr9UqzDz7FkV4nBEBKpK4e5Q48QGfC9H1KxptiqYSXhF6BZchQj/WpXOgONrhuhVQ2EyNh0
ioXrVzU1O+y/Spu5NUv2kWws1CapHRdwqOkP+RkBf0Q7STHDUdoZARiDUX6127uwWvhEBe+3WIci
YhURzuIzTYwi5rxLG3SrOM1gV9mK3stVtBTHfTkC0nasnP6DCwhrWG6WjBYgFT8Hbsczv4l6IFW0
ghayOW9IAOlJ0sGb8H3QGIH8QJ4jMZJLXJZ54UupH9Ko1XclXqC66O+6DmCVyBrjbYrBsiamOss2
HHBRMOKggGJMiY8RScboACIyiribc2oQFUbIBm6enV5ftN8iF13jKqb339mWhEz3sCZscMhqamxX
tzDCfp/tkW7x4V0TM+NZ1FpasOxABM/1vt5BMbM1IxPubihElcRuq7C+BOcKzFi1PT6inMcOPpzX
OPhPyqzzc3jdQt/gIkNe965S+jib0gLkpNHOCam00CbVpJLJ/d/yQRG753QyCfnfcpJhBz917hC2
DkVgM3Y2nCY8GYoHzWwPUUx1gVjghnuej1qo9mkMGSLCjWGlIULVtVHQqfgZyZ/3suKKe5F9p7WY
NoEF+jkWE9VAGxWQA/cFqxoQCDrnK4F7ZRcArrrv5PsDZMkiI3h0CcOx5OCYFhlWUAEBtduPa0Q7
exdK/ZmDE2SkPcg9OaOizrECoy617OP4mNSPWAwUFmLuI9KSMXc/OYDG7q/vck8L8H2WeEQQ4FTf
ennFC/EB5SFb4yNNW6VfHHV3/S5GgazShBxmCu09hSNczR0OxLRsaefHpimpix7HxegoFVJN9SL0
16ok6KGZ7DupZGY81959xzlkPXX3UXILbAMWSvI+1I9szKDr3poqIm3Ankw3miwLJa7tPtiDLV3S
eUaBIMTwIX/1WlVOa8Lslth/kv3Tp8NQ5T+KEY8v8oUAhNPciTU0itQzEaCkoN8d0nxUCHsHYe6O
iNsI1YHTYvgN3Qh0jHvryN6t6UKMdUdHHdoTBE1TWTsEz9RkXhLTnjT7ccLB3AFjx5st5d8HQMPs
24xNwfLAfEskg5taiiUKO4x1JXGqOcVcZekD8T0m/uXS/UcME2iOm1UUCu00VSd1nUClLPHdamqz
DSz5LBgDICCDBOEv0Fde3oAnu218kAWLYf2FTTOxl6zxN3buxhivstlYghn3Mi6KfzrmFLK/XzGq
P+uHnjUGyeU2d5vW5rcUDrKZ1rGBKm6kQd7aiwdxT3ChZ3XiRLHjnUHnDZ+t9VKNHiNTjlm8fXQ0
HpNzzSYPbj+AIIPtatQRNg9ioBJ8VXK3bKditesWQ2Hue0DMfgMY1LLBG3cNq1owWbxJncx2NRhu
5tEqb9q/t4lTWVBvBXh6PwowYur4Uw0Nz4QN3PGNhaR+s3cp6s1TQXAaEq0hQaFn20EgF37WgYnN
oTxG7syfGHwUq10CEGzWjy8D+BkkJNLSK6FzYCbI3EzJt/1pkv8xku/w1WPHfDyzNwWmF2A0Fm0B
45QcOOHxmyaZcCPGmQyTwTht9c0q0vt0R9AzDfjGiCnykWd9pOVTKdl+i14ZNCqlianYVlmQv+XZ
ZNYEKInuE8pyp/IoORDDdt88EjmoOkfApIvc62yXkIOrxee1b94mMP7K82yzAVx5HU8UwWV/c6fS
mNQxYMendWqs1wZNAZEWFul4QezFZW6ph+WLSmHt0n7CmULblvmDZLjp8goUl2S2C8hJALA1Ye9e
IS5bki7S65q3BISCuima0u0nY6zCyepCHpFqoZE5gtxFyFL2y69uEqkXLNj7ZTKQJuVk1veaKF5l
6tes7KoQKsPPynVJc7Wpu971RBVuGvs0ddyBmD1nv1pTwvIoJ+iodHJ73rqj+ep33ley32WP3iA/
6pOHVQ4NBpr1K0V5SKB6kAlbVB0v3DR4Se7HDhQFXhZKOkmu8Lk94icgYjyuHkFEcd/JNhgv/Rur
/zlZSbu6u1zU7Ktdd4bs9j2lYej768ae9SWdL87mGD0588LJ2aBP/yG134rYTuzYjUqSlXH2o1sr
8jSxaiCrezoCJ/6wpIv+egLcqo1ckr1A265b4Aa5bC4jTrYeex1Ms8/WUd+H7BOg01W80EDxfr3k
OSJoGPF9bnP0qCR46VRT4kTN/6UAHywdn4IAMdfTInSTCBAos59eYl823CHVQRepbXbIms3V2W7l
HjR0YUR1fctpKW79Hpxkq5s9CGxSbWw3ChiaaAATF682OnaG3+K2NZfEXpMFdjLQ/OWdjvyveWb3
b+Usve+dxhmBhigCCyg8PQ3BcfEGzDFkez3EKUlwDLJrkwZDEE92Phde2ri7YK5PLGYbWwkVDsAT
4zdzYOz/kkxIixrgAGLF7d8rSfou6C7kiUAPfdgzBSJeFBh5KRnfEKYU/bIHabj9nVK3snx4ux3n
HPZyr43Asbb7+NjadDayW5/Pq0o2myF1YtWp1mGxyuvb0MLr7xYL42pMdgxLhE/NJaeMxi7WqexB
P+IQxvt1gypvzpsl5JhQh1IteWVzaJyDFFfXPi/1ZiXzXcOf1N8Z5XRNkCHgjVSkV6no2sWBSTPR
GayqV7GJOj4ddPG6k9iXZDGWM+aplT5blY62tgS1BvcLnATG4fGOH38lRmau/kDI2qLQst/51a95
cGXOzufsMA51UdDlRbBBK9SWVEdFTBHe/CjWPBHcfv5l3co3zWOV1P7O/tMdW0ipP4IqvDX3fElw
JkDI06bhqZIenEEb5t8ccJZ3+vY1vvZzR99krNdWDs3nMA8L+3+mng5vwFT1KmaWD2kZrWFou23M
/0oaGyWbrK+3ca5AmfyRJrAflkoj1e8GLn2RkUKmVMkyI5f7DdTC1s33m+JX1xbkhRoQMgWbKKMj
j4giSbjfZrcrLlAoVccEqkheozzC6Undp7DBG8j15REffIU50yQw3E50kUshaCvJmwEkM3iEvPbt
GT9ZNDlr3OA9DmvzWgkM6y+yAGHIJnZhZBKSaGH6R4rIwGcPSxtKaPNH3HegKLwKsD7RaFzGMvYV
3wClOCIJw6RmstpptayDQSpPoH6pK3e9Te+H4xer9+XCwdqAtfxXk+uxisPJHDkxBA/Yfz8jej73
BrBvcGILC6FMf5u8os8D8fKLmGEbiFqtf071efBeIVo0QaeeUTMAXUQLZExkxTHuPqg7XfPh81eH
d65n4TpDaGc3aD6xTb4//N4KG/KHUqzjp1EJTerIGp7kpgx59BWbpPHztvbC3yEhNoo9DwFYGter
xhzgBo9G4HOUrtFx2+xZZb48dHWCzAvVCO1okhMabBIMFg0tpEYy5O8FDqzcDBZ1ig9PnlRdBkw6
1PK8Ef1HZTNDI7cuObykSLqCVU6mNYQd5yyddCHmV4BPtyr95Vnc5VDLhy6jczIV9GJIeT5xwVGO
llv3ZjsbuSXDaSILnF/ZdsDLWxYXy4S3ICk9jyFVkR7xAqvJ9m0Yga0w/+QXx0xtSX+FPgsdm7wM
rSiTzkewQDsr1Kcl0I83EX4CyBniqwovzmaMgoktc/712iGWto5qbNyxdeE+1gXNuHfnnWt26f0u
lQ2e/y35GnHms8r6rgONJKm4DZhcl/Dnh3KIwubZcQ8KVNb33QlEfk3hcLq4E93c+RNz7bcY9VGh
qcpHNICRWfTb0Edb1eyGy63waFHLniKTgVrntYClBEnha+fZ4jbNu6iGUYKU/9iYnYGf42m3sTf9
xhkcFozXiU/AvIhmVE9Ce/sTbTKQ44AddnqadytKs13xSnZXwOu0zuYb1gxKQHra2D0XHj+9/PhM
gESB9XNvUCLADIU3d7rVrf3pfncRRHBteu4vqReDurFM/R/QuJGtFnCfwkRCq379VJTDBRasNY6s
2O2iAlh5VFy702af+rW1ZZ3EHBTRQv6QbSFxkXHcLKQSwjGbv/lFqbrPb83Ec/70EompsVPtwwR5
e9/9h7f0xyrb3wjX4G/j9V1UBmLPRX3epvD2AHzXe+FBiwQllMBQ+1xQrQOgAqvFs4UTbaxo0O/u
cBUJ0FTIPquUp8Zhn7l1ydBHcxWYyEdRVRhPpo19e7nJq/7Z2XII3waw+SuzCposaHtBSt2FMgT5
0NoEOJ2D4COMj4zPmIdKm5ORjdxu/BsbXZIqImAmvRcl/B0RXBKaYKVQiAMKxWjCAvStkxnscPJ0
bNIM61hr5YhbNHZZuOCqU1oR0692beQ0jCyPGanRAEu4GqfE6RBioTLjKxUXpopqL3qNtfXH25Uc
6DGOMzknASj7/JZbM2xTN/76bcpBUtp7K8uWxnDfis+lSiPlAi+HaO2+XxPVnoTxFwbtETpMfHJl
44BwgCKDZWdrzaUzeLawBnU2UySDaI8bUObjPRF/ui4ZpVxmsTlIhHaanTpjnZg3/vTgoEJyqM+l
VwenVp2Vs1O4GW/xdS+6RUfqbVibnFjDenHxV5hsu7i7dniNA1c60jjqnhGFHQKmVR2UVplVMbLP
e2Z3zflPHm3hTdIs+xQR20A6Y68c+o33sEBP0IeBZ8zvBF8K72n1QiSrwy5r/ggffZler9d+Lmiu
V/7gBqTWGTJqz7qUz0qpzmzlEAHX7uiHKvMYtCmJKj0hD8aQ1Et26q8wOuYIzaxc1QEZ9BndlwBs
WyjjUY+qJuYhFS3f5PVNCDWYSZI+/RplWoXEMLCfJf1iGa91nAPjxzwnEDml0aZ+sEws2mayRf0O
YMwUxFR1pxE9p3gGj8EEjoUGKU6CdWzcMGCJM+D4CYVd49QT59pKckoud5giw5tKKIGMZgNanilR
hh4imOjbKkuP/zedE2bVySJD37EBt/bPv9+iSFMrydgDW4/Ore6YtEH4bVImpqm6gZp4LgrpDl59
SM1tr7KGrHTQAn3DCrloQvJdWUZ4NLrIOgAg+Io+ARoH+gWwyjMLYFjZVgeo1vQVUpB1alDERrDx
RjPdBfvcfJtrH06jsZ+4Z/+36jndmlQtJleCHAbwlIWsLum9RzeX0/fp2e7FQOMOCdTo3fp6J2rG
hmfjwWdhcKuUDCpSJEhX0mSIfEuY1n6vXUHUeJf+smdeVXlLpZmY0hVp7tZrvLO8ulHhPyQRi79f
NkUaQIog725jBngysKUDTTR2Tndgfa6ikYKDbLYHU0k8K3GpObX+GYJe9XUttqhJ03h2UhUWIwJz
8PMUzQ4sv8k1DzREDs8grqNgW4h1IbKGd5LoI9muA6OwPDoTmLrDh/GHHtMKyi2JKrJCgxk/7kMS
XtKXGynBP/54HF6He0d00NmyqHfDULaYM8IjRggbbbNdC7zEOnI0ghxbtULUlJ6Cugdnlcjyi+bO
Dd3TUdkC0YKuJ8SQ8b57KR3S6jZbZdMvCDp5YQaj3PvLZauPg0gQyZD4GKCwSxVpUAvip7wt2S6G
fb+oXE/dzffVsxe+waZ4lWYaeGYT8EHr8Nwb9H9dchhS4hT5XLkdhUmJOYiTDkxdxm0MJ7arDRnH
0Rf/SRBnrZj3jG7DxTm+p6B2dvr6cXsvnSeeSw7dDAyGEwzzM/HCM2yE4hYVehdyUZHPVHGxvm65
FilCQc5/tK+DMvdBRIsEJUAIxre6K8o63JFuXxKGRr0ynNR2H49+5rpVRe22t59LzeM6SX/spojD
mra9Td0bzkxeLIdcsar92HqIZwvMroPYc7ZAW/O0XIoyZpUp9/intxLsySgc7LfgYEanVxDkXs/n
tzTv47C7bBtP/RVPGL2ww4TcJp/Kuf6+gyo7bfOa6VktDupPk3LKuMXf+VJfYdyU1CHi7zK3tUiq
QQo60/JpdCE6+sJfYqThxsylstg/39ONi24tNWB+t2qeQNHZHF9caqqql2hx4/DISUcvfR4YgBCz
Cecd5CvZspGbt/k7UQkAEj5pImERHsmx6FtnifxXwQYrfjjT/Zccip2MuA016md5IEoPFedq0msH
tYgFahYVR70Cs2Vp6YRatzlvkZ/ZV4b7yrgrGKrMFWGN8pTB8yf6vYNkxDW115Jiwk3z41gEVaz5
4yBn0JpsVuNJJACcNwqh77o8e6BJ7cIdhjrrrqyLPaRdrVo/tNMRw03XhI5+IkxIkp6lpJR22IHH
cx0fHkkddvefHYasuDooNHY27tbtRCP1tLVXwl4qdQqmaNsFwuvi6t9Ys0SYez5Sq6y5b8z5o3MI
+Rtznscs5m+7OIzFWJ1UqGYxG5wg2+ajrVSe4pPFMCxh5OHLLh/Xd/7OOjZaoKkm+L9LrSUe2Rhf
S1XMFpzT9jIxehqEOow9mBb/37PMB4dpQWbtCrUNTN0LbYDXzF1aDbJgTJxefSbf0yyainyS6eaX
FaygQlAm1RsFHzLwjAUl5e28qtnjRKKH2FeNaGnIg06VkZczuTS4ZkhperVaS3o0gNR8V/x0Kce4
ByhTOz7wdad0Aj3K1UuQjk38jJrd/8nhkX6uu2A0LsK8aHh0jnV1pVFtFepkdGbHxG4eH2fpDSqI
vkkXSYTiCiYyZmatMcA8B1C8yu7irLwebRqZ7j1vZa1z4zFZPFazt3EtgPf9YwOnlx3G31FZh3y5
j0lZEOV3DkqruZmAM3hnXiRQ1zsZl09+9GrAu7iALeGu1DpqPimPOTkq95hSGTX6bsQCt1DmovW5
HkcYrNeYw4f3Mj7mSvJVh+nvDpPXtrwbhgfh9b1SXi/0dOWkmlJLFQK2u5M8+YSamEzOURKW4IvZ
wGzBXNfIH9YjxZqOVS0UWKbEvzgtFBcYA7Y9K1ZsYkgTbyNykjhTGfPshipHeGBbfdExT3wTcomY
z8QIdp/GAKjxUAihK41E0HWyKnny/ujahhz0unDo+IOKokKArRn8SR3nMoswj5uHSkaFd6WoKdJI
3SZiKSSQi/c1HPc77l1j26AS77vv3B4baSMI6oZW2wR/4PX2YbxE/B4F5zH0JUGUd/iqG2/8hqLS
ocbM+3lKceRbkV8ASSigUUJLAFvbACdVm4Ho13g0gTRJkz4jjv36gLA/ejBDv0hOVKs2VEJxV4fQ
vnrL5EIi3Xsp/C5ZtMhQjxjd9vS9a46/PlHnTk+Hhtemn2VX/aG91y3JjWnSXYwNoE+gPpyGpQBR
LjPwapfKNFTY89Vmx5z9KXzZON0DNlMw66/SvUZ3i+Nr2KRHddgQO+R2XMlfU+ffbeOumjdxSkqV
c9I+2sbarrWBAGD3NMn1umj1lykcaESila4pukcqNDVmEsqWaXVc8nskhpcJyQciXBZeDWVuZHN0
cmVhbQ1lbmRvYmoNMTMyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyOTAgMCBSIA0v
UmVzb3VyY2VzIDEzMyAwIFIgDS9Db250ZW50cyAxMzQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy
IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0x
MzMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0Zv
bnQgPDwgL0YxNCAyMTcgMCBSIC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYgMCBS
IC9UVDggMzA4IDAgUiANL1RUMTAgMjExIDAgUiA+PiANL1hPYmplY3QgPDwgL0ltMSAxMzUgMCBS
IC9JbTIgMTM2IDAgUiAvSW0zIDEzNyAwIFIgL0ltNCAxMzggMCBSIC9JbTUgMTM5IDAgUiA+PiAN
L0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMzAwIDAg
UiAvQ3M5IDIxOCAwIFIgPj4gDT4+IA1lbmRvYmoNMTM0IDAgb2JqDTw8IC9MZW5ndGggMzQ1Njkg
Pj4gDXN0cmVhbQ0KyvBBm4bBhO+DgZrgqusYqXxcTC93fsI3rIq4gZCnxMH6DK60NMzMN5YGQSSh
cKr9SYFY33zK9gQg7Y3JkrpOpK6uqC4yOK6Yo4+ivlmF2nu1az82SA1TNY39xy5i1YQxsTnJzbjx
zq22HRYzYwLjs/jm37+SWiDzvirfnCx2LurnMeHNIQm8PjpIXp9zSgFuj9rLteZpNzO1RD+rASXR
blATQflt5ylUPKbT0qs9sPz/KSIxe59WHfXkqEcFLYVHcjRSe/xGgiB9tbXPhoDCL1Cyr1pJEBcS
z03dxOeibE2fG1OxiicKv70/zDOgihpHhm5ZDqH9r2SCQnrw3RKK2dycSVPwhIkknvlFiVdoJi2b
1mu7eN0cTA8pU4ig03q9hxAUOeAMJtE9O1fYVYlUdYhrE3Cq2c0NOu3Eu23l2tjJzQp2MwjlmOKr
4O8XmQ1OsytC0kFPDBj5RR4tpBPuVwsBMTmXXsuofKyDOvsRiRqwQOIMirh8a13apEZeu+V2ErpX
NHmVjybRKPo5CYyqkcA8GLIv9eWi3TpzfySsUEc7AWgYBTPCKShPRiUZd5q9PF+en12t1u+wDM3X
lnQ+rIoQH6UC+k7Ji7+yMAf1DCEnwaOaxgD1GmOoKcP6EHbwIrvl1WlWNjG7yN589RQYzduF5RaO
jzTLq+21GPzLiVshEPaZdrmx9Qh7+gPX5ZaCBHlnBq/B9U5A1VUUCqHe923p8L01HNaxArfkuMak
b8nBH0vSocCMq9BFtEAfHy273pW2dT2/YGCX73nLJz5J3S87x1MrFCRbZfqeXzz7xLzCTRXCKFgi
KjzO03q+9L0i/+MXil0Gjwz/Zyp8HGI3lNMtxCKvhxYzFshDmcZrms8sgAOVfN2PL97+qSzq8NKy
th7ci9To2iKUlVQoobqi2T5Z9eLjBRhP3yLStaDqnbgCuETy3XCmp/7pspzWkmczMRxyjps0o+9p
vmcSCjtQQNuLbSKQDnW0J50R5/V2GScDFHacLMaVwbT5ajQIXJ44g56vgtx1k1wQ6oIuk6B8DPHL
jsDg06cgeL7jDvhB8Soqw06/XYoHoS/JY2ExWv+VvkKtVEAhgZtwZH1sh3mCOdDoVAAv1lfR0dAZ
c/b+RaYxdsFs9d2TAEMbcDmlAmeql4EDWGlrg+ydl5EBaGvp6hmGwxk+Vgv1BVYSUN0wbSKK032y
IqyczpuYGiU7cwr1xlWX3KwN6JBrYQoq4KlgSkNOZ9KvVH9BINsCETFcvGt2Xzt3girSbjR01AZZ
P9vU3gIyTp0OzlLjNsh+LnCgDDdTSYcj5Y8WoaYQ/taxe4cerC2Ode8DpHZGNQqnHyfqzxOaPBZW
amglLgl2+gahrVWgMVu1pE02seop4MZw6J1egQ04EpKwnjMgrdaS48vr3HiyCNmVK8cYLdihe9uF
aQjWYzrp4pQJ6j2FUY3VQdV0WznWF2oNjfFiFhfSK7ZgYY4NXw8l6UtN3xsYLgB5ThX/NTGKGgrU
7kW4WL+HttWBjJPQ9f7abChVm444Zuzd+7cspqh/4+rpvQIkhdKGkQEgY5ueV3FoFVNZuBf4+UR7
zuXFdq87l9stXRHaSTMU2KIwkGE5MN9cWPH29yX7u2GQYoAr2AujlCTV4V/M+P0qFhKZCe42J8dQ
Q1V2S+GUtBSIqV2kWLay57Lyv0SJdOj2MF6sU+7m0xQkh68G4y+A+NRU2IdMbf8ZBsGYt8L9ah3u
3ss00aCBdnkWgGJfvogWvSwwkApfuKisUUhFmHLkdcQGzdhi77mRk6u871QT+XN26LWFZ7/y62JN
wE/U7XihR2A/g4DTvZfICt/1LSE+dw/45OoCOERpLyXPWy3vl8u6i+d+jkN4KMU4fAYhDa44ZYCD
zCal3NhpvoEbM3ZXLctRTl731L3nUq3W4coyyc3DQxkWJpRtL1izEZOftB9Gkcq/aEWKZz2BxjbJ
0UZ5OnbQxTbHemikSDHsQpZv/RPSfM1lpQBifjeX321s311Clw5JEQ/CV3SzRfYVkP//cQ7Kc/Av
x6O73JjHPVFwQL3JNW24B165M+oU4OT+HKpPCMQv/bg43KoFe9Y8bwXck/eCJypq0zumgJi8uGu4
LWGDN5LmgpdhV6wqA38Dd4CpAeUbhznkhwG5tBlD2wUJLNickGDxFmbrhwcFohrzrpFUAjqB7Tz1
p/N6YdTXZwfxAfEErIfZd7dcUs9O7S5VsT8e5ugZ8H5p+IzaXCHDuI0Cihbs7gwtpXK+z5TD60Kh
StKp3nznhTqXOcxv4pOuvccIAbULoT95w5sfxPNPDBYgDXNblPIIf68W3kT3CSIGUmPNKjfyG2jj
kmbYEkmhh19uVlwkgWZLkCaZKq0A6DluSGye48e08LNQoiVoVIcsA+eUY4wIpXJOfw7lb65/2K7j
Xtl+YXsW55tswRKYar22OJUkiH03+XVD2+F7Kef7vlOvoHN70MNgAR8+jByA33YgzFgbbUqezeS1
8YhWJpvgPnVSM/rjVn/3sTeqfyFbLPZBJvrurxbL5hij0yJ6IIsHegBgivaQ6fguEyn33SDAXTv4
RuNy1dOekuOJ5X4GWZjdg53NigI06/CtRb0g2Np/kwq50gwbNnhrdvo2JEsKafxoUMNzm7ch+vPw
2trsvANIxfP0716p48la0s0Xj2BMndkJsGG+kQmlIYZsJ3rysAHVuK/xZR0Vg9kebyugrWTNtYjZ
u+Dw09hflvF+dgZsmY9Dv8sIq5GuOgL2HhJnhEJbBoC8KeWDl0dxt2muAr7TJ0t3ZJKp83fCCl7D
/lmB412j3B+nPcjzA/9m5yzmheVSsW84tWxIKYWraqvEwWDuoQ8SSSjt4epWdMKaKX0S5fVCD4mL
dGw+h65VErmoug+MjMiAAGuLQJ8dxSYkILhDhkAlAg4m594ZE09+qDPtg2Ff1MZ7Co/hKRTmimAe
vIR824CAJifIrGN3W3/IbxcQhoSo2S5nknKM+Ql3kC3k0Kj2SFIN6cuDKIsR8N7FjgRy5LoMDox/
edycFomJR25etDz3S6qmXnBau0oAhngosDMMBXAc/mi0Zb3qXdikOXKPLRXPSxNRt2vPX7HfuPp/
5bW65FJwFeYjxdTOhKztjm3HdDnV/Rug8KiTq6lsYotE5MmNGJ0IqG4BFhX32kGp1h6Mo17zYHVy
KLq035E1qe8fCLSrFE2DkflATFFRsngZ5n80giWCV+xGOTPAO832X8s5PTEF0JfGe6gbLpMoam6i
xSMGJAzBOkmHGDGZY5aXN1HgK6UH28CP+iuSWaq2EchPwyDbCQphJF6otrK3QC9VPqraSxQOb6xw
U/GbHun3v3jyvpIvxc0prIGyjaBDX/Sf0VitZ04+TYEVzQCgctSa+Mh2klJDthLMzobxKgutrO9q
m032ILnhcr4c4Vl/WKAHMn8DfsnFt4N9k2d+pgEQuWtSiXCnUGjaU1C9eKqRgSyP5gaaqXuRzeWl
EO1jjz0wSrxAZucb6dZtdvKh/7F54UkLGnOAHrbg8EXLgD4k5Ne2xxJ5f+93P3zXPsGpDgYmKNta
1zLIISCL9yWSC5mPn9VmhojmI9VLowtPU38pP6Xy/EV7lD8sgo4U4rBxcsmNxo7TP+EbZmfU/Dxx
aDSopGI8zQu4g42LTgbdCFnYsWhGCWFTW3FHgLPr0pNzY/fRA6FtVouFtAndsXjH8W6IYIhTRBhA
VU3V1pmm1Yh/o+lKKxWiuaZC7wKJlAyo///6cZSTuF5vkvWTjbZL7n6N8bNab4fKgYchVLSFBZFa
iYWYh3jD9jxflM9NmjnNbJlyfzJr3rYC+u+rRIR4v8mkQNhJ+M6Y/pZoYXJw75I72XPP38Qt+nF4
7kGa1MyOvk/ROkfMIKsTmrBElHreR0y1X0A29z9G5jAIu9xSytMYlxrYL04cooR3/X0DK03/cX7p
HDyx+y7MrnIL4uQTSygrk6P3rh8IFoLhmui6KAcNJ5VGPJVTE5OcSI2DQsxP/KKCqCfyQWimFx5W
R676oW3hkzNJAa6kutHra5G77ZglxVTNoKDUllD5dLS2NtcJ7ZKTciyhpVMK15DCEt6/l6168ORk
/R+ubDsLl5aaIVoJ/u5qlg1GXFkWwbXdpUJTFwcve4Q0B48GEpAf8tDVBTxhtaiVi3aeSq5R7R1T
AgKyFb0w88hiTvo8UKpDM2dLqCzWt9hcnC1bn/SCojMRolCK8rCBynBloj6T2FWS0mD0x4I0VF2p
t8ZZrPE72VR3b1d5JiK6IFJqTiy0w7grDH4AlF64KBCXLLcYGACu9mPktybpH2v0KUuU6TjehroM
LB2IftmdpiY2e6FqjIKGkcs2KxHAcUUdqqwQsv6qNTrP1kogQsCB5nO9wVmtPpASnk62GvlJk2Li
jI3F5kVjm13Ewoga2qRLF7VySFdGVT/YJ05skM1ReXUIhM7jOlxXCfihkzZceWYZJ09DodYf8PwH
UPy4NZGgZsI2wcKY1z41gkmE42dZ8ekCl8BMB8wm9kOu4ewe43wqUBfuywSefzqz9zXXeQON6dh5
axnYC/gkNogFvk7JnujJGgT4Drs6BgccjDsMFoeq3NhbvraEpdHLQ+s++iYjAFFqbGmk9jRrWBIB
+rDCiTIq8oWGVnx52WcjVJ6/+kBmLUuZNLnDOutrdoxcFF+6+Qk6uEyv6PYnwrG4G327BYgiYoq6
tyic5m4i9lrQkFKVNOxUY9QlasmPRUNhzVSZtXODfFm+Ffi8EVwNNIKJkpopHwEwLXjR0WlRwQo9
OYlxG73EyMtfzoBfUIdbx/JjMvfc7eXXSqYgsR4KX4Mgbts/cn0cSGRWI2rQSN1uLrMSMlEhJRwV
tru7oLfppwm8IIiwktBTQ/8qSRaTooOo6y6ipQT4yjevmwfelP3KqSLCaksIQbi4mF7cMY+RMK2k
WgvhpUhRad3yLtP9wDXg37QlIrN4ofddta7mDhm7eDJHV5QYdrCEHc5Ppc42f2GZntOYGkbZWHvR
cj+QQesp1vb4AAViYj8g8gC9Qt93i/aFYy6/oIPN+4/MmJwdnArA6QBWxbAtsRcoohhVXtnT//JS
Ec4Khhmh3YzDe/cfDqWZ6IYNNnxJKVgTx+/ca9DbZvNZBLwbhNwOP0g8t/QPvBv5HtpPDdc8Yv9s
QHiR5wxpDUc7oJdf3IDGYOJwfYly5McTCEgOKwd7fij1CZq1WbUxHwI4E8mFdz3SHipy/4En6IZU
4FCYRFeWJai/fd4uXDM4VhtpPQOLKjOIHSnu7aQHRIkOyvLOXzVHswV/BLolqcMTDTxZureaOMVm
v8kaaYGvUun2rcI0LC4JFvIl7lQ+vbiHfxNhB1WjSyN02ckN3yzO3Z12XJsZaCvCIuMVXyfU+6xp
Os2SgWfcPfak5+BMAtU8rDfEscVsrL1Yb8h0/xmL8YYPeT4qmUnjaqLwYzySoNrsQDDHDT4lyKkE
7pJIpNSsGAzmtxiKDoqhDUHY09CKw0hO8c676fHDEgTi3WFCRO45bMnZaC/W7eeiSI+rk4N7Bw9j
FkEkOg26mlQG7zzGXL1LBHKvBLcA1wUlze9ROByv17ZlCrDbwu0bj2gT8uVJ9XrjxzgkugXRgdF5
oeQZxLhZvnJ2yxvk4EYruR6J2V7kvCDc9/LelueDUnttxJj1CGw7kN6emuBb1xYIvatyX/DwpGg8
zeomGtVLqiX56UAv9axEJmci+s8sckM/29l932XJ+W2NYbBGrOReYoc2DIJOp9kzeLwAbOUTbLV3
iJ+MZE0z8NNcCqqG3c+QPgftogJ+RxZEjOmn/bGk2mHu1fMB1CUlRzyTnJQS93JAT/UaNNESeEm4
X7Bu43351i8Jzmbh+JzbnmExluDsCuxA6fg2PdALv85j+4MgX0QGjO6SI03xZJTzbysZjhItWv2X
cQbUxm6zEab+w6eKPzgiXdZu7eQsaERW0UzS1Gd8XTgglzJ+5VNaiRM405V1Gr6G/QFOlpdj+emX
dHqrcA6W/lh7T3dnXQKDTibTq7qWQVDb37W2nx23qbIAmeB6FEqbUjGX/UtbBR7ctzDCp/0laSHy
X5jaL0//LzQscMfYCoFw442tE0Th9zdbFgAIPJ7l+q5yRFXzX7QUHKB4nJBbRGRbcF1P8DbMc1Os
L7DezXUTI1zjP5bQLlIMnE9W3ZbbT7pPR07VaL/esWw4lVi7xrtRBuumbS1c2x9ocxHn8c+wi+YV
Q0JmlVOiJiAyjBXwHniA8mJ16gKm7lPzTvRlDoTYa+VqHd6DQBkJ1IYJEpjkiCCrDhlf9nmp2X3z
Mj/G+FtU4uXwe3n72YajEZuCRZMVhhbcEMjxmhs0HY4Il3tOqAVUljVdUD/qEv1n7BMzFM0h1lbI
k9VhLs9aU9Fj8BergG29+dfzChSf5fr7icNALd3mWoolmbKOx46e+tvcxkzqPlPqVerwexJNJFzT
uJikGq+AyXWkhB2v6hoMbqXOS0xpyIQbMzJCSSJ94jIZkl+Vgroqjp+ZqU7nt4OnaiLjMh8ODxrX
OtpVwDpNdXYtriwUGpDa8vFx9WFXU4hWWB1bUB83WQwjP/YsZC0tQMfMMMl6AtdlAIiQFaI2lm0T
1erLWdu75QWdoxQPZLkwl/hicymXWRQIrwugXj/rThoWhv0xELTD5yJEGEKX7DkrpxXMtlr7gk4r
X1Ymro3HS4XU1Eb7PTzhhN5EdvnUadNTkcOo/M8HBxjS0SzCLSe1hN13uD5WQ5VrOgZEBgYhHApO
kx6w7tRrM/3QtSYmEnqdhKahriHKC43I4SgN9sjO3+GMo5Gu35E1sq3ZlY6WW5RQtOI7+a3Qz+zk
vRvDthcnGdzDsTIjUVz07OJkC9CUnMD04dBGOGYWnPoA7+MMz1KcupvJBMWUitZ1d8pAtiSThA8l
fdoIKntzu7m08QxO0J6dmVV0ypHERAwQQbSEmKIhU8I3ZEVhUeODaTO0TNM5a8/EnXvCxe62xBe/
LBrYd9alS4YEcYqGmNE8qU6af1BSJ7bW8haSewFNDf4lORJe3/xs0LU52okW5M+JpE9TLWp3xMmJ
KRYv0CnoJ4H7vYBA7LR5e5NtQ5eid9L9Ioi2lGjjBBZeOsAKGC61qS2334/oIgc32iGoEvlW/eFB
AezHGLXtwLp3XsXrJzj5GC4JlmGUW5IdsXh8tIOkuPtYFMPp13w0Fd5UGwtNT99gqjmnRQQvvW0o
Qzk2U4E4j3KhIc9SjyYxSjYDKiVywv8NTQ+yzpuqfNgF+CFTUOXt2kgyzVvo2oLe5UjEBDXsInLC
G58my2rSxkYycKPaX8JvX35MfNghW1cxBY+IcBiWrt44mFTZ5wgjoe7GuU064/8g2lw00IE2mqFl
HrDmXqNy8HoATWUAviLWpiLttwEzcCgxa5Hhq53Kf50K380UcVo+iPpKMLlnmC2Q2L2dPsisKXls
DNnX/9H33y3gBac9KT0fow1fs3zYyTG91BS7fhCqVooiIHun2AkWdQbEpNzPcy096MU51iVyCP6K
4urD5NzpDBEQYqDpg/Zwc+8vEgodV69rBhR52SVrIBh4NzFC5RqzR48jBdJ3XcjgZ705Q125picB
eso94DWWwSKcK3w6F45FyeNwxgvGmuFaKYOortdKSC9Kjghf9C/3TH8zxHgIwkQAZBw5pFOnpdDX
9KpkW7X+yGu74VMExiTplIlH9Z0af1K1yW4Cn6aWb1VRHZuIT70d634V5RWWWVS5ZJyIGiMAdmxV
KfpfUUF9W8UnfFEuN1BGwVSbQPZZJ9b1nA2SbLpYzWELkXBluJxo3PCVuojyaAhoLm1+SCXYz432
X8tf5mJdz49hQV1pfXSXSGOjzpQOtOJeAVB3w9VG+0rNX0JrqfO45PerTX/w9Rb4V1aglgwRWgFs
IWsi8ZoD8NpPoRzGBzzVmjkZgDDSvKPWC8/Rs7IzfIeY1cRsC35l8mHoMisn+uWC+DxSK5u7bcjH
y7qYm0Vhnsi9Q7HS1itgJ3Ap0dwGFiv4oD795w3ZutMd86jR+El+yWwxl29Fm5BOZRAFGNy9Yj+V
zVDF1Bo6r3VfjfHTnYAkaYauUjc0fl0Hmd1v6xMHDPuKOaOipcWhf5rs0g21bUeAWda0F2zJDkr2
SMdIBAH4Un5B148IM0EPmoetaSuo48h94/htDNA7l+vpmUUADjkjaOoVpdBWlIYNzEDEdmj+L99w
WBHDb5kFyX/vciGi876m1zkt8awrfcokNRQksVoq/fVtvl9tqqr9YjqS3LfzFxObvJQghLCfa/Wm
Ew2eMk2goO2Qyk5j0yqLDa+pPYeMTFJD42VKHHPf8L2miIgjYob57+Wq4QsOEHqRT83++H+l3pUx
1jSeRmA60MSUgtxjiuhNC6w4JxGg9wQIuG599HIiu6Ac0SyRf9fTDfcpYinRwmb7CqLohcZ7fQXO
pd8Gl0mrYbMy3qO53eVqnjyYnp1AFZYBCCXgpuKQ8cUWPROGRRnXM6+Jp6bxP5H3DUHik0WARfZj
LwVcQvrPoo4Pjb3vZdAjQQvwJrNtG+1Z8BhgS7inE3SO1eQNAvr4z+HFGp9aOq9AH4Avgt/tWdX8
SOO1Jl323bH1Mx/smIxw0RHjXkqZGTuaQyn0R0fK1Jg8C4CRwR0FH8od/EiYImqJc9vragwBdbXe
wGG/CLA9pqeX3crIAC1f3J1exZsMVawHKqgqUilLLj2JyKO3DbKMnrh1zx8LO+sluDR/USBcdKJg
4vr89Fcyn1XVNinnLVqFD+WEDPlXSD2Ns1XONd7ArFIr5OOdLZN5yHQ2k/VkQaEaQONNYAB3KuNC
26XDlY2JHnbm+8sfuu9YVFYmD57txqV3IHhe2HcA5qxashOIOGlUn5Wfuqf/lYl69FLKT+CTgg48
BEQZwS0SkwOrVJTLlijvC/gad8OxICdKUnTmTdArY0rhVu4LTHasAu6HHzXRiQPP77gdlQN+co8r
YaR4So02qxG8BYJ9rxmRjD6ohSQUV5UIyzPT4yJgd/y+DOrvMOsYr0djnaFtDZ0F06N+JI5yGGH8
vd27Ff8csQ+8lcJ29KmGxUxVl6JhVxbW6mCRf2smCuk+lqUfLMGJN/0W57KwPUSR931PnlAK3eAf
to+69UJL9QX4ynp38hrXIMuY8ro50nLubB1H/BkETZ1dVNqNiZYvN3yxcoo8iNYgIRCXE23QMxtX
WSP+K9wVVsT85k+amumB2R2uLVzOWu0S+AnlsKC26Hmu6yLKqXh/GjDjxOlufnWlBM77AICDsF0U
jmWXiK1hOnWnu8zy9fXaumMw8mZ3es/Njl0BRiiB6tSKho1ft1pgWP3pB3Tp1jUqAUtxXFY8xcRz
Juwod3FIWBn3MbWD6FlQMVold6QB1NyB4+ZQBBNRP+fDeijBYsAjjhhIaxmhsZk+waL59bCP4TIQ
LmubICmGWVepalqvs1H84EJBHIsKT527C7zjC3ze0kNnguafWp2E2v6cdyKcktkGsqmkFSoHGE+K
1FfJ6MrFhaW+703Nq9QNkyqHqFq+sc5MDE8D39jg5ItjJnAhbiId9f4GdTtE/xYfDa6VdVyBAknt
dKTIHJJgCornIxd0/FvRKTMuJxfT7AvCQ7huwMMUWMh7n6naMtLUjXMY0oOktalYR41Sbi8lXw2d
9LLZuaBgOeqnW4uZZ5zmbamFsgQtlEeP4p9fRub1Dv+Gy/LYYEXa0KDkC44BqQeV2hx0APcTIs7M
v7LBgCIaKG34mYcvBqfF4o3gFmMkOq5z1WlfiLcI8mjxa2Ly576xK7EdsDxUxjV/oPW/lqnNEBth
Q+FNNXhPacVaZiqE96UiAULkDFBZXajegFafzPUhfX9Rqm05SXK3U01PlOcw6dYT8erpER+CXWG/
arDefFqvgapJY1K/kBSg+uFTf2YpOC8/32cEZ2MTkaApnmMbtKmzSeYsKFsXpdQbTUgrznFC0fz6
wrrVn1BbrKUDxtmjqGz8khHCWwMI4rFQvcd6jxSE42tnC9aGZTR5q+oPaAAsBPiLuVhzA2Vm2pn3
cz3pTfyPrQhzEMJQGGEw5LY2n/Nql7zHJpuWLwbzrUHjfQfCngvO8ViO9+pRZC4tpIymI3JSXqAm
xDQXbi1wIapMdEP/tyvGQAeFk3gtZVbspFfzRwKIKBKTYiwL8fY5pH/fOdMF0CKsvSQDU9IAWtv8
cy7z8rZz9zptl3+25db4FSZSeVm0Ym8t94+BLzyFpUE+A46kpIhWjEnEumyW0NzZoQF7ETAqidVQ
L1ZwnTWjON6jNWFpfSQ9PMN9KhRpW2k+m7VkA+bqPknb/2e+GJHRpTWziazSxct4a47Ouw4Dzyvj
/25Zz80R49tW3skgVYyyncNbZIa1uF7tNQ0POn7t51JT2+EHLi9rIUJGbJQCBhaPU6PaCOLQTuiF
grcBp5DpRsf9b5xfFOqffrtuyZ+jpdLaMwJLWOYrBSY+mkg1Jz/0+vP2QQpbyZYob24idmZm11h0
9X4O4/yxv72QAdSy5a7JS6mkNKYy8ZEmZ7bNWSzoTCq4k71nejMRujNcxKb3ObWjy68egwqlyrFY
q0pt67TUxVmNcBC5Lg6zNbsOdluiPhH1I5y93Id4qomMXgZHqB4GfB4HYk6Emz33mEjjVvoIf2nm
WfQHqVAn5hgQNlhY944morS1y7uvzI6DhETZgZ7RFiUzf+eOAAp1DAaJIcf+Dxy8iROpc4rCO4nE
7X1HO1HnyoNy8J9XN8U8CcF8ebz8zRO19BLBUgDuIWw70vaKSMEkRqcMOW5Sa0vfDMTuALSjAC/I
lZLPFO8xiOuX1ug7qYnMhUD2hJZLt2hpJ3A4RhQrgoILI+UwmxZ76f4fM8L8upAAZDJu7TTADL7Y
nWBrUMceNU4WTJdCY21ruLykUggSyKIzV9htHMUzXprj0o0z/17YJL+Zkteuf4KJY/2tkQUGdyr0
rME0UYOp44md9AVgHdhjL6ULycJp1e6cdT/zYDuu9bCdDMXcYdI9Zhr7EcfAdMco7BZP4gkX6Oj7
ZhD6JB526WZRp9y2llLNRRJdcOVU/FiDpjptf7xeK2hzmSrZvz0btQ5qz8JFMz7pUyKiWKyIgwZ6
+zPn4297cIU7gG8PQ+0k8A3ONl5iJw24601amkLT9PWQWtAgYXy6pn/OvGnWhlJuCeboP+ozDAzC
gGZuk4sG4WqAq8mbzf6HMm2Ve230a626IslIwdvPH8TXPaTUsOg2ohQclqCwVhf7yHfP/+uSZxHw
njE6mWip+HiwTDMkICaPsn8DnCIeEdB6HUj8v6nFEtKYKTruwptcqT0QyJoWfQukZZFguOScjyjN
gZE2dfuEZxFQsRmrw+kmj8R6M8Xo3LPKpWwFUhbNNZ/vPyzVDN6awG0XmusIb6QixTYQGfbUGywO
BWpZBpB4zwKsHrFsclriF28JnKNdGCeOHU2hm+GLBvvOg9nwiMS6WZWj7AI/OMITAZaO2P8dRNv4
KWMFOYwmOLhqkExQ1DUM0ac+UoMTF+yybG2Qb9d1jnTWn+57sQfzCLC6x3OJJxe7HjKSjw86IkOe
pc+KSNOJUIHOjCmMw50snOsrs8MIa0DeJ1j7S78Vfl/HFHpYveLLfBVnrAyFClOyih9u1Yp+a8qB
UM4LHua/13WkJAJyieyNFDLH36qklMfvi/iJf1pM841kfGLgZtPZPOd1gbjNC2u1eFwp5jD9x9nl
OOWcl9Usug8RAi1T4OAKA8sbgdD/J+XQl4SYBLuY7HcdvCijgn6yiSl1pHPaGSlN7ydO10pgxR9K
BUqdyLubvUadJ9WAAxdtwmkwANqFAkMMdyQE4rbXa3sB1npntUG78U2SJjE1CyG587E5YYhgujEW
jpEeecs+YOI5IbBGCL+EEWIit78G5aEC3GwkLYNgxr2NGoPp8ARxHX/ygqV4STKK3nbHGbhufFzt
TxVypOLSyKfAgtKf3wvo0WhMbMk+njw9JWDq0WhktT8djSRM8DUCoEttTb3UlNMZPpnaiNZXcOwh
OaEEz3zzmVx7fb7WNmILtAstzGqGwpaA6tXF6CKXhovXrisAH9JM92LSUuZ5/mtyJgakY/RZs1WR
WmHx0sOLH1deil20lU57iL+X6nyqG0+Ll96Wc1GGI3ivUVHkZI3cSgNAlwTu8JPla3lkH5hzC9nt
Z27p9oGoE569cXv6SEusaLGd8i/7GsthC09b5Wh9xkV4PRzkLfNrxoDfxkw26lZEWPPjhHK+DGzM
rOadkNbj3YbOOv5A9YjanBtGOlFyAeeDbPSxGKJMVb7dqEBbttc6x83TABjSRgSJw8s43DGTIf84
69fD/F4PDAJ+GtaVwZVgyTnxi9+mau9e6CtMwChpc8r5wnfPnrTAShUQtDZsBwYhWDDN4UW8pucz
yqoWvDoC4x0UlwmnAqDdmMLZ4BkVzMnds8kRGQNBrDWxZ9WqjBnpJX5PRsxdqijcbq5QbtDuiuYt
4GfTqpi6RXHkweyc7Rg6+7mSzl4DvM1x+wFmwno1gICrgMgsWBklJ2nhaU0f5R0tiG0OFNATwyxa
AUtDg2KTizOy/DO8QZgESL49TgNiMvoMpbhCjx927aKDttx2yAneJ3YBfRkqo8fgJ6gNrnQ1IdZi
E3y34lOrGuNs0QI5XQAV6MGrJg7x7TH1KWzXgQS9VDyTuIzpfNvGO42q+BRpAL1uasRxt0SctKWO
RVOhWHpYYaSIIOGWO2hAlr39Kj8wGJo+6SQZo5TlhV6FD7XKNjWWKGU6bUku+JJMPmqnRYvJFf7t
C4VufMi+52xJbc0U44EBRA1GECySNdx9N8LwwAQceT0wfYsFx+0BC8XdH54Be59hyM9LhEbJ49OB
cOA8rKYIBHi8LputJExN1c3FE6udBKPd7HKVRIVkqqGNb/93EG7zq0fN59TxioMwBTb0yvMzFc3n
48LqmXl0WDZ7wqq7ejrs3dDCugfYcWzkl/zl3WZGIDgAXaGdddXUZLqfENIPXWXjwuxM4Hszbrkl
gZ/7MFmihzunzxfBDqqfkNepL/2l4TX4QA4x10ct/CLp/V44CbGfvLVoiio6JnMg9bQ9XvC7czPX
MRHsbK6hcB4h2kKsbQLKbVk6zdKJrdaGOigD+IFZlE8GcqUQlkDMyGQKiF9cOpaprY7fe6dLbCmE
wm5bA0E6vEL5588ctSOLgq0WrW6zsXTCqEI86s/g9+HtLUGuAMC8FyU0Smd8BqzltEIyc4vepvrI
K4rAU8+nEubvZD4sLYzvuDIutOl6iYZD/4w8cazYrkH+0oidcs3W876Rdp+Iku9neVC6klXwtkCO
4p9xEo5SQNve4UtVTwTdj+/J1GyJAVT8TGF3zlIJTcPihtlMlzxEpLO6Wp20nttmeUqMdWxTCT+6
OsxyTl1YvAmSRRTvLOwjihtmH+3voKmTk8Q0B5dSZfQ2mej3+lTM1pTf5p/UB5lHsqaOjeMZeEZh
zYHY0uJgT2GzXHDp6ZOn+GSZ+SY0KB7oSc+gk2KQt0Mw+rZFtg0drx/Rh55Xp5QFQfs8wR+zGiAJ
4387esBv+odPS2hLc7g7IOPgim/mSlQ75cEvg6mxEe6RFfYZLZ+I732ZxVJxqjxdjEScfeHsAvlT
vfeoldfO7cfv2s2L/nwRZ2eaWFuGSKn87aLU43d5jkkrtMlMkH/OyJqTAxNQz8xTu4KaL0EhZzK0
B+R2b85O13JHp6JYVvz0Q3mXV5JkQmbjybbj0h/Ghu9+tT+K8UE6MSiTG7bao3wMkZ8ivMjnX/Yw
QZHd42u3//FAI8wjc9eFtCvNijCLfMzAHhsuhgQ7aFgN+79U6pdwRyVuyL/6ps8P7p6qKqhJiu7/
wmgmNsaoKDXk5ee7UUkWiRRtp+YwRyBAT6LTUJpmHnaaYDEa8isv7nltWukCCOo08L2/QCTYGnB0
mlzNkTCy2RS1NsWhBMjvt7sJXM92Ea2BDyV0ZkvBUf2lUsNUXOqvgdU+uam+GD/TyLRboELQj1v7
ZiYSz1OK58Ma0nHyYPOIqS0JDQFOkaLdrXe/VQTQKH1WJvrrMZ1Y0XDFnRxZPe1W6UReu8lM3gWm
wEExA3i2lB0XDUp34YZmQlE31VB+tUw/z7O9Q0NgNy4pkMtI62nWnaK5orpXSuFLRpZyFy2ET7pU
IxZaoODIA5pRkonOqUKsy9auCtMz+OL2kw9aAQ8CLnd9/ZxMNA/hG/EI39N2YxFYh2F8IfXVMq8e
6q5P5nivWGdpTYjAADHHiebtpyZObWVOXO3hT+N/6SUCCwsR8Y1kJ+yPipKR7i4HcTXHWB7dLX+1
XnheZ1tYfLslvC2zONMdE+OSu4kAz5SGBwHs2cRU6hNa3vVMlSY0lM9jCglF/v9OE7ksuLymvhEw
Bav4y+p04tKRX8gC3dYWhVOl9uv2XzY53k1SmpfA4WN7CtxQx7lihsXCXdaZT8A82QyuAzUoAkpc
zzYBjr04fEPZOkzD05XxzGL4ZQcQhQEQwMGC5dgxLGtU94Wvd4ncNiD8G25GWB/UJTEgK87C1dj8
r3FQSLeQcWIKO/5KRpZTt0GmQ6qBKd0JUhAD1aPUfq3QtFf87QNb9HXyOOEoFNhFwhAnhqc5s9Ky
hcVShDKcWitjB17Oz//oWKBbqqcduMcWgglbOY6BZQIRBv9YMJme9wQ+pGIf4wBVXChe3VPlVBWe
XDHUCMkIXphxvxfdzFHgkBMw/DmG7FUkehYQx7oe3nFLsSXTIi2xA2dzy5KSEJxOyWXq8rm6HXHB
1JLG73+K2lkHHlZap5mPLQdXwWFpHekkrgDx74EVs/N8Ap4eZQxDbFR5NZC3jLawnlcNPR1kS2IT
J6ocRKHuLv1jQAjtWl0uN8I6LoDxkAoqBypsEGpZqxUflftk9ycYA+Sgbowti+2DVuJ8b540P0wJ
sNAxgiRRE9NXrm+iQyU98EafUd52DbB7NswxK8TVXY4WGL/1ErS5KBQPVHv6peD2FtKtzEWpbnlR
BphRr6KukKY8Eqc25lXPJ03thlFMTRf26qViosBG3zphlNzftlWE1AG8FcJ/ICo2amxOCS4yTPEc
+vr/1SMRM1f+1vvJrHwsDvoOCpKZBUigkuJef/Kae3ol93sH0RhIuZsFTuAF5diekjm35zHWgxAv
toaaDbPFym/IuwQgO0AwuahNbD+itbE1XzoFzss6H5p0n/WJ0O0hVen9bFKNZlMsO1p96gYztzXh
X2g2zMGGZSO4TJbVS58QCMaldzLou0Sc70aGKMHB0lpAZJa2+g2r4UsDeobapu45LuC9CdaU8Bjo
8TgxJaPTTBOPu4sEqEmpQ6TcegEokJAlxTpfDDvW7yU7nAGe3/oOS7oPCIK4Gu6HfMvOuMp8l4+A
zF3ngnNSpoiHfbfPdBgLqHB4AGsnvXcRMR95PEzOcS8RvUNhf8TmyPZ9Ux+fhET0i/Wwwusk2gZu
BX8Bq5FWfr2Q/mvCbnWJswH4iQ2Rg28FY168phx7aLuNivXuzI0N4xDwXoNL7LW4J4Sws8wuHKYA
jC1MCtDKihg4TLwTX29jvTi3i4O8x2Xk+KJj5sUvREApBUNi0tFxnYOP03Jhis5X0F9SHgzm9S56
qM+/blgWEeaSMv9B4MtQAVPo3CN37B/vgsxiqd0lXgwbAjIphH6VxOyBkZnK55td8xDex5j9PcFF
lYLz9y3eKf9LfEZI1JPC0/NoEyZZ2ptnKaMQFsl9F0GVzOb4XCnsraswvB1ybN2/dd3/Lp1I59SO
VgJk2clzezKgdIRf0Xofr9WpAQZH/53L2lMIAvKtRETi/SJGaJMLhlj91MtiP4bAlDpc290nd+hT
Q3KxLPXdFnpVEMBdMwDSgSV9PXpNjXfn9odrAynIYqKjtWFB9wJUFy19bYUKWFvqII1jq+XB2yu3
kmxCe8obpp6EwZsQTd8zbu/oz/FZGClFbzQ9KRpmajrZOmYXPgqrsMu1To2BQUUsIQf05T1LtdR3
qvbOsnQ/fx4dmEClotemmyEBVsp4xAEsjiEcyPm0lId7UK/R1TP+q4rXkDeL7iGzb5I57hG6nkOr
/v4fbjHgpDfnhU41eLA33+GOy1n6I2JlL9DKXo+lr+XAaTdDdVJX03lWBOEVPwnZTF8CEs7NFt8N
6jcPSJdmbpz0xNBxI2w4+NcCnENMCHPEi/W92qSvhiGXjtIB89tb0PsZb4P7jjONdMiDcoS6y0aA
PjPX2+UWk6lC4fZESCoxkNenNriZUT9570XygYuPQPom1Z/PO7sgu3oFYkfSU2+oUmz7pTk7/he2
MwZsg7+PbOzHFgYDw9SZA89ONkmmhn0W2eXaTZQgj4lrZ6AWlB7hzmd8Wo0R/uOjkVrsBuZp8Gwd
vwC9UycBZvgg0BzG776n5rkWRGS0M5jke4ij7q/HCtl6IKPQbOmhq8ngDctCRFxxrwqZ/DzHp2kG
WRjKaHtN6iMk2rfW71dAg+qVZ6GLuXhCMGhCU7vSwOWa18cv9PivZiHN3V3bIabfUjGGB7V3Vnmq
jxvIYH/eZ64Xr5VAAzzkK/GmNKtn0ZCA6QVB3hdZSwRrtHTQ9wtyb2HIEpKxaHdHbpC8nc48VwxO
8+TiPqetwtb4AOfRMRXehjRSFB1H1ZYDZUYOnT4OaiaE0p17ijX6fbTnWE6ymqQwkWjg1XW2K7rb
7Ck+pfjLwA0Vw7k17LrJK9iLxk1/f9yfYY0wyrWRTWwWcwWZgLmvF3OfUlz6HZx20dUF5FGtTTVt
TUmkCAcW6gyOXF39avaL/VAKtggLVA9YEZmXfEGpCGgASKfTXZsOyNiWqP3TqALAc9/QkyqnCPAV
yzBT2Fq2fXmz4AC5h5tBSkHFBsr6nYcAz3wf2AOVcWYKYq3fIW1rK5aDkkEURgehMspsJPoc/4As
gY6Fn064kQozqEqLmIz1DCh9bxwiFS2Cga17yRKnpbS2XnDR3YqlI9BrXw/WhivjlRFdfUwjknsI
bj5T+tibXbhQPghDABvf6hlAuXNkDDFlBub9980hnH/bJrs2WKot7EhH/QVKJdQBRfWgWmtDjjBr
PIYy06GW9x3BXeh8XdDnyeY5hw729qLiWRpNukUPFeNilankxrZtEcY8IEGd8qxXeqp4JfybdDw6
8ZEKb/jilPr1R3yH/vgLXjDx7B5CoRJe+w/TTAx4EE+IXUcgQeIs4wOo1pHowMT817sAswat9nj+
KFBEoGf2hfDjyTA+8/trSox68GgltQIIhdszLzP1kodUiObmMZShrXp2zJIphrmczDNyn33Fta3G
g/MhYWWmcTAlC1ykmOTH1JNl/B4V1eYOoXRGNaMJgG6emW2haaK4/3JxTS+Fxp2mCd9G9AxQUHHz
BxGMrL32c6ZJTVbFfyCUCHeHA7EyN87M2f7NcqfdV8gP4U8ELK9YKbUUqNPbQciPLY2R4GRfmwso
sq8u6juIjgP8smfUufsq874YdW6C0MIAcTRrV/2cdcbBkUVtiBkgPVrE5P36CVKToHBtFCaH08UF
xUUrV3Ru5wpDBssErruS6NsqxFpguM+Off5jQwpN1YeEWPmHq8L8XuvJZmGLy/HqPYfk7nzMuP3g
uvEvc99uSuQY4tfnkUnvftCNesrWpHEdT9WHF4lqYsBeoOPtOUa3M8x/5yEqOGoZr4eUMbUxnnUu
urfryiAyhASA+fCfDOKUHZo1xNQ2TYO2W3xlTNkVRJnVb2zYngAjfMd9xSOXV33hVFFehnW6ZmI5
b1lz9vAqvOYbK6i3iBNq1uxzNOcWnhLiDzf+/IOYz0bVvBQ2ip1y8NuIT5yS5yqh1UexcypqqmQc
WgEEzDUxqupkAJoUEqFgyJNTF/zeRnIGYAHHznAqvk+xDmNqAjENLW28QobmMnwKzYwQaudnAaDq
3FrJdNNw8hv5vEH4eGLx3HF9T3Cn/AZYloAFP5VpsRMXc4ZLYC8+gIZKlwOoOV65smDdeMMSr50s
QFj/ONyNx+MtqphhCYzAOcnuskWwUOQkV3lxgNh06R4stzop8gZb2bTmHAqHjGPVEh2wRq1sJKP9
wZ98N1S/m4RXw2NzpD4OMyVRdZuEEqRk9/JjqCDm+iKR96s5M0x7yB4YrPtWwzaDymHk7BCA8QmP
zl4E+fmBmT5mfOUo8a++kPsqkvL/qksIlDbEklzD4SfZ6h+oB4c7uudc5MWeqHBd7G9BWmno3W6Q
Qx9Ryjsdpk9qXqmEF0f6c0fhgCyUfrOvtra9vbC9cuJqKMgBg1rP1QJbR7LuZoaeKmsm1dbyWnXI
ixfKm+u8hmxppc3pvZDrXP44LA4QgK5w9R1lzpwcqleQHDSAR2XL+FSgCSDCTkjTWYF+sOaQbi0k
dcq+ManaxJIibAQl2lp3IYnc61WsFmU1+yJ93/9P+Yq3bzUJ0wdNl06U+sg9QcxnRJDOzbARph0k
6KLokprLoGtN6JItpumi8QZtGi3M6joa+I2UTDY5I56ybeJdJmCDjOTlQrkMYgFPQIiya93bI/HG
5tC1VHJhj33Ea03s9GRK9DJzRYW3PCl6ystgg62r5a68XBO74M5EaSGwLA05EK3iA/18EgYgwe6N
CWqjYaR3KD6Uz2VJuRInIS81ex8cowvIPuvIBfsI8YMPHW2ZvMrq2hU5JHyUmmXuyau3LTM6Rkel
YmDbqcrRPRthg9fFkBZmpM8xCteDnX0VOJ1bbeZwWk+Jg6iWFO2tUBX5GcfZ8bA6n5d+YJZOS5T9
fmh/fhO5IqHnVH7slXVjFQi91cE8tLXVZTmBorNXZbdwO6i8EgLBFhe+iv1mIAbaxqjmWtUOn/KM
dJNSRz2qblNUUdQA9PFLBPLdiVnssbI4EqQ0vSx6HwQ+Es1CFRWYMWXNc3lZxWpVWp540sXEcf3g
xnavML0r7LB26hnVj9lz2zV42Jm5z6MJvpBbwHY1MuTc0NsPYOkOIQ7RQNN+/392Fc1BqLbx8MBK
Yyov3mkbV8rcJO0WVgwXh3//IeucBrtb9Hq9uAavu4f/WqFEFITc0meJ5zS+ckYsyfvUTVP/xeIg
DTVGtQTCIAgZmdSfbY2eeTVZZ4DW9Ow8DD1uh236oOSXLepsXpnXcKQVTPmKMbFH+l/v6TQBN57g
4UVl9oD9zCicxp+kTBG0vTEI3/HQdokXOz3EM/RNIGePvqv44LiAH5L6KyqA4edtO7A5rGt6IyWi
L6gdeUtnmPgGgCjq9LRkm26AlDHm0vDqagj1Jzw+Q0KUzpoNQ89EV0nP/79FFql8DJwRcTVSO1bT
NKSGrA01iM8q3p1mkDPQO49wo97IPj2TamB+IzdAHK+8GoQblSAbsh42IHP2016wVqdmCEc9Q8Gx
yaizo3eYHxF04nyJT0Y8Z0l6q+7DoqkyJNzawRXxlpzH0TW/Rn5RmmdJBfjdLoq0CbypkREvUrZv
Fx8NbX5F+ftDS9xACTiSry7QfKcoICBIzGNxnnSyjfiX14HtRgYkxlk2+25VeUk1ikt4UyZVoOUz
swe0c0CyswDTDYOoz2e14NvTVgaOGX5TfSbx8KUaCeKpzfHtGMNf0Irs32G3uF0f6yAz4xmBNlvg
KoHa95pYYbURniiqV6abCfWVtBsoc9JQCPKoUX2wtmzK88cnFUp7B4i8Muouxr1+J9l3s0sEuGun
q2nMyiVaQBMjSEHnJTvEqjmyXxvxuizy10ycn0vo5tbEo0ZxQ9XSeAONfYQt2032G84Hb9z8fr11
qXZAojtCMs+ZsSRfHAVqRp9VnIL2fxgTDPSGt5D+DYNB5mldu5Lnrfo63beTEIEWpKFsvL/3gg9v
nJL31WIeGeiwLqe+Qi0mnGTzJQsyvLsccA4VPcoxIfg/GIlH61DeeiVBDFaOg9zHA5+oi1y156zE
rlK7LiWyveYhMtahUQfg2qKoVULCmU/wGjt2ei/+IfJ0f4IL/YtZNRKFUghwSOx6YEgmrGzD6WjF
OQ9BVqjqEX+vxjIA8/Wkd5f1+izox7UedBx364zBlT+WkBx3/mKLJ4b8uJCWECJzllQ7EeN9hXlp
q87AgZdvimLB/PCDfVOxTr8BkuwEds8OQ9W/WafYtH5L7SECeMwHl1IPoXiaR+wolumy9DgBEGdC
lDd1FuqT3GdNyEJgP4qIGtPM/7zinxZLAQV/HMnWH9xtXFVS9aW+ifNOnY6409lLiYPpLc2pvc0A
5uSX5c1QnPX1rbqD0jl/vhe85xbSwiNBVgwcuVreOugXgCuiDbT+jvLb3aiB6Z5fL2OjH6e2AeY9
PMUyYUggu0zAkUU387imQzG3rquaHJPmDrl4RnC/lr+qdGSN94GZOCFGmZ1FLwMn7LM4ZDnoYQaC
pGMZ/6T4HDWpSqOeEgf61Sxz5swNiZX/KHjXlLjVnEjxS2tssw6fy1jvZjLQq62fB0Ia5o9WV1gl
zv7gW8pggaPT7gF2MdijdHKj/29NwBOtDUW6HOOgavpx4/oX6N3QUxxm9kWSqiqqn30pzDdylEdE
04QhZ+75uDZmHr2EkpwAZTqsdMlp8yv/6DrUOPEQ4Pt6BN8tenPV8eWyVXCjaJ2QsyUmJVKBeaTr
UAet3xIRXRhXopYkYBhluJH/9EQfLaE1+efAvJPw6AmaYr3Yt56zWaVinXCISDJvWR+1+C86zwxI
HUcKssgui7We0sb9NILVWQ+akN7UM3Pb/e5ynjO9dTBrt7CYi53PEhBioGa9WmRh8npFHbfC96pK
wvXCWsNBEJnh0N/UYZ82cuL6qTiRcpxEH3EcizkBZf01hYlLQD+Z/DtuaYOUheXKsfe0xbZNxzit
WGSfvPEpzg68VidreZ4M/WrVGejN90DTh9yzxW7hp9phVJTIlGNGi2F6k46ssKkIqsxnIUf4gwDQ
eWZkizS8rE9dpbsb7QeW5LTbae26335Pc1C6aip1Tpd+U4yOXzVwTiUXhB9JnpWPgbFHQFH7scZB
x6jv9kBf6UaISRamJUtidpXdeJmCzKahNqKzmRVughci+5mBcAIQWU5BvHOWRcbixMfeehiscuBC
3QNZXPmbrKT7i1HYkK3U6wET3ZngAZGBDT8Bdet9Dz7zbFa4HNvnaKjqzY7epmjW8JvlxG4ywBX1
zcd+hSp2Xxe1PKouAR+c+9GiEu2DayFRif+r+x5qNwQ8/Sxv6j1I+V/5udQN5agqe6zPNuo/8Zbh
jxNW9Eolb8QI+6fB+noFM5eIvPgdIk0Cr3zwwiyv8Q3cA14wJ/zZ5lFHemN4uG9zUiqqfDnad8RY
7UOVllsQTWs9QEidNNe3CbmRT2bRmpSzVl0gcaI+9sDYWqT4umBm+k3EJdWz75NF2KIR2vfzOPRq
A1QSkfVzaQqoM/k4dDvTGAKoQATH03PXNAIxqsQ57rnWBfTZisSmJ++LXLs9Fb2ISfKHf0c+Jyri
cI8KFpbe2MLZq+xTKVTGU2Db7eEdjE8eGWXRfCRCd9ooACwvrrJyRWht5Cm1beVxpGsS2mOv94OF
gA0+DHNjwj++/855022VUO57xNBLdlnq/HZKr5c6cmBLZZo0AzuC19wOnYAEdVOe+sV2REbge5jl
NAk+kqqu384VJ9lxT89Oxg2T9wvGwEdNU4aQgE47AItBaxEBQqNsFI7WkKTXJb1oRSea5mT12f49
gdiqnDVKn9VQ/64OVTOG7OkMUuBN0YNNDZ2rX3wxuTBZzJz7xMqvY4BxQaE0ohgPO56D/n2M4H3I
vMnWQCEWWDkr/uT1FTKKmESgffV8fUPwJsb1LLj/2SXKxsffrDOZIdIdKvF3y7JwPmN+KALaFRr2
mowm03PBeDnOXryYOrg2bNKlBNWAPTO9hISGoudShA7kY3grPC/2x1qjlIaxFqfqY1HlIcmFOgtS
IzrPhV05YR5Wauq+LknzIMgGJX9gxaPqzsgVZQE1xHsM7skY8/9t5/LXKXtowk+euiXDuc8/gtJe
feegzMOrSjZB7JzHtKgNSdtY82PJbtoajf6FltEQLDDCfi3OUaM6UFi92YW362qR02vVRsxhOHuS
634+l5/NJ+tZdwgjDEnHsKiKylAIOi8+UvdvmqylcHy7xggXrkGoI1fhZ/VhHFrCFGYGrr3mRlpP
xX3vmWmXMDWuVXnyfkCxfGcfvbzD45ZN4TnIjCXRw0PshDU2WXea2YwUwCL2JSk5/3DaWW/OWRf/
hj8Yer57ywtIcCQjlVbyhUD6XLZDS4IjfM59bO9D+JiXCCamQn2gEXh4ZefRR5UOZjLLpwM8UHFN
cFUeYURo6LUu6b+edAiXGAwApHXOVcrUA1JxEwOCEGnPdW5UoeKLktrQKspzwED+gtNFd21TyiER
8BXYUOcXE8h3tVifHb0wfsjnc/X98djoq92jTmZezri+VftncrJfNsJeG1Mn5+U08WZfQpsOd8st
xvk2p3qLclsIf7xobqHixn9zZpF4UvD2ng/swLXTP31oZ6nkhkujTCqkco2/cqSxNFfrFoyX3Zy6
8w0l2ePb/KICjsv+FjqbcJh40QWjHW7MVGdoyzzt+vVQa/t3zXLsZwDp7JFeifMlpNv2nZ4CYQdY
w9GagAF0HQuV9drSnDDB9Gpf2qd0qST4vyMyAgqXV4TiVZ0JM2kVn0Dq3a5u8c1IADTXRCpIfucn
cx98918f5bN5qV1lTsDTLUX0UMzsqxHsfI9jAIz/4GrU56nO8NXxMKk1zec1lyVbPfZMgkpvM/MM
XLDrTQrQm8XSJxa+ohYZgPwjTWSEQrli/ZqnVuCDNx3Z3XbjzK06Yx1JexEp/lvEXNhto5Qhut+l
qPiDJAuhi/3xBEIEiMTnKwXaKKu1N+7EZAwHEHXUedK+1df25pjyW7p1TiA5qsTyETMFq3Q9+cQp
5XW/OIVrG/bzMexTPRA3DTSR+jXVmuKRFjdvk9xTOHpI7HSYNvb/LhmwGDmrWhUM7bBKsC9s8znL
3HYvEADhnaWk9bSe33CnFpLrmD/Mnv6S4UdZJX8UIn1cZi6/fz0tBjLs3QAPc1CNV9v4lAqb0DRx
4f9SXp4rfenDw6FcCJe27rp9tlaNqhXVrWAdPP1T2qneJUz/ZhZpVnOTryX6SmoWHs7cuqYV25X7
xUBDZ1kFGYNanRkZ7ndQMl2XN9YPo7yS3T47t9eACrOiY8Suj591p8tB22pwHkA0A6oyFwu+giyj
heLC4ha5Q+OSjliRJbGBLzopiGG5Xefd4n1KH+rveE8tfB8qHTsQtycn6p9neZK9Lxp3RolFmepZ
AAWjnw5foggQt0MosR5c3uyo1vA/Xg0j+XzVJFItUMmqF8SadtUcgkiCRONBrhTA0zWuV+54IEFJ
l7lNIGP0gSm6Ohmtpa+cyGgmBQRb1IxxBNd7HMErcq9BEG/U7qutZstCh5UiD4BkBhm/gREGGOva
qcI0/W9h8lHguGhkxKAVgEn7lOnvw/z0f62lOKdqjD6qQ38KweNlPEp2IxHL7pX5fNj0RUAZSgdw
Gby9tTXQni1OGE5eMCuUsoUL0u+ZJNPJuOX1cGrgekxuK0rWlakiRp9sXFihVU3+b7GxiKaX+LTg
NzuYBPr5UPdphOaM8gP+Ay2UtyJxz9VVwxHIfRRKDgEvDWIl8zWlUDyN/gPgOYbWnaqsb00oJh3k
YF5ElidwUYqRUHVODBDJmaWVgB2kmI4lD31pDXLOwX5NowvvpSVaWf2Zv38FYzzyExEE/hZKGZZb
C9TqhQU9AXg4lF7cqDhCFQN3M7DiH4VwSdF1ZHAl1rvf29ML6KulKzRgjQBGzsX26K+a2L6soJ3Y
6wHu6hWn0c+tPWa0G+VBjlPTtjS2uRPqwEJZODNY30Ef3E2wceE9+zaConOLTMVJE7nWDBIkiRcF
oZyKAkzz3BlbRuqxtsjonY9pz6NVfIi6MGszoVHE4oQ387TtVU+gAg59vIVRloZtbAJUsJrx9Kzz
Hx5Fa/oDwYxC2UkyAw1TWW91TnOGQC0fbn34KW/1RCBxojskU+WL78X5UX5EoeOWDiNUWaZ0xv/m
QotXHTUHbthBgOZl1QftYwOn/lkcxBZu4AdwAC0lWkKd3JX1GctswwyT3xxbguQ/SA8zZ+bTDLWY
ogqj66RozksT4lmUGTTT++CCO82vwWpdZs0tpaumaSY9MULt1fLNC24AOXromEMrOBOdGE7LfJ/W
dREOkY59UdQYVp8gKtAuEyoHIxHT9uLLltynxpiNZu7gZra+3L/MvubrxXv4tALaAAwoNR0imkGO
ip+V0g0udm+fmL5yd3Db0aHVKyETiQShH48naf7Qri9+CtkBqMO8NwluD7k/gTgl8LUIIOQEq8cg
2Ey2BmoPhhu2LyTpc1CgI04tfctI78RkYpgev2nwdXeIeCgeRDO7Kgw2rAXOxnmUnBgI2BlSs8sQ
bauFmI5iHdqzZ+3W5NAKMlNM3kSsN5+IzGVdaXN4lBLSacqDcNSFS8hvBR0oHbAKDNJuM4jR863m
iTQ6g153upn10DvnTbYyhx+0WB5YQGFfL8w7MtsgkIvb/KD5tmfVI5nYO0X99BTvf4VQyBDc3TA7
6OYzUJOpd9XuT1EwU9kNEah8/1zNd2RSWDXqtdcRQQ+OIC0OVjm/ubxRSS4jcEsE2wG4y3ALf1GW
XvvOwkbGHuhqq1yuofajgjiERgaN9kDlUl2DCoLdSysSgFeo20g4i681ZBfCvzf3FwZ54ciih6x4
gdJKjpVPHFH3izg0IxSWc3Q8k0S5WoiuThjVPVETM0syoMIql+enfrguKt/SIQzvHHY1cni83LwN
N/kVjdqCmw/V9BN4QPjWF/snvr7MtpIqV/qlCY4HrIuti63UIqfAFn4tG/6C8fe//XND2nhCLu0P
Upx4IWvVPwzBsAEHVnQwkeeTH8tkjom8Kuntm3GynmqgFFBZ6DoLFTcWefPDJAQJEv3IOs5Bn6XT
gXJuNPZbkJ5AtbjnNiZwwzFAunL+/ZA1+m4Z38vc4thAo4bRAMcxWz3SMx1JG2LGUQbt8fV7fRZ0
xvjZ5EocZINcZL4tAnKIy5wzmPxUDhtC85IOCFlpcZ8hweb3qRflhwheiAPxA1gTzVTpbxFwmMfZ
tBuTjyJBTMeLgE9qcmRM7M9NMFm3Pa9MCD4NzNfmyhFqD8i+e1db3wv20uKYZMnVUePAnV4oqYlt
DykbCaHFAUT8VHcO8okqfrz0bUoN2N2CtO8ukCcQHqsb5UC2GMESs3vF8KnYgeeTy06+VCTbzxN8
NN5AjdQL5SfVNus+lsmL88EodUjdyjvLjoxvj/NOvKr1DSo8e8opOneFKdFmpdkrzbeF90QFFfyY
AEaAPXysFCWllWy11McmETUF5XU8qjgE6laVbAjbi2LT/aDUTqT7qjvKe3Je9lN/5B7xKA9O8W1P
oJu5TAbPqtA9h4lk0OiGX6IRV691wIc0+j7YYLKlhLdm2sKY15xtnIm33fxTxtbEmYXDZ6Ck96QM
P46g/fx5etOkzZCiy3/kuMk8nJ62bMZ7LfD5XGIxrNO44MxIIvGjFXrVfkpRRr36PFUrBaw/iMkn
SMSQQT3CcX90gn1NyBiGz4RgRootzsxAFJDT9qBE0V242Vp8kdXmD3yZ8dZw5JSg5rMTw7edkx5A
3inMl7RYUeMe9IRqGrKd5za6OTXrGE4wYb9mOa/d0lwt5L2T36FEDaT2rGT0TMjQI1zJVwr6w0IE
ZJksMTMdMibjJt5ZLG66nEGercgKCSuO8FtnCGU/yeUmvhx5laUaCwliGyMted2vsL8paT2qNo8K
uDtdNctS0r/Ey0ewvmvqTOZgT47FGNT93Bqkse7QeCSnnxjcc5yF0FniLQBjcnpVDW3xuGyPCtUg
QlYyVPam1uXxP+82jDf7ckvygbXPYRuq/Xj9UpJOSJpE5wVP/Y++BNpC8vqzuKsL6QaUbVnoXB62
Z+2kpHwNjq/sousRw2fbkB5vamlIKGRVeg/W6aw1AkvYHLLBMmRhucY3ZgYWImD+Hwb2Rxc2RIcZ
QfKKc6Db7Pw+XxS3xvjCv4TY+O1Z2UDsQ/PtZ9gN5u/M0DD4uA7lfr0rwAa35GNrIL6d8YEadzHi
W9GsyYQecy3eqNggftZjWvTOx1Y4ogkKclfJc4144Dtiirb8PhZ3cM5TxHknngTEJS9ATdJaorTk
QY/2AaWUtemes2p+k5ipuItI5SUrodP/9+CZJzxYPYe1Wxn31vPHlxfTKiOIqRx8B6TO9uQU/+mH
YqsSV+E2M2Ywrw3OB4lvqN/Y+CT4+yoOTHv5KaYn6LatiTg6ggNemN/SjJFwT+7rng8hyLTeeQv0
Kn1qqbKYiTJIupaQ829F30jsi46SFz1xUFXiYciNE3bMgJku8q9r/8O3nqKlwLWvPOTzvEjvUQnT
vO4cKuEPwXJ51iqHhChXQjX5GqEVefti94rIFDPZ4KPSOWc4uFDXr6Om1dZxI+e3u70+7qAy2CSD
/Y0DrMaVmYr3tO/ndahh4Bxgu/6cPb/6ubtHo27JlBCODohZpgfbWfylQQRWugV7+GO0O/BrYhDu
RmOXpQoxOJoNBI2Mm8rQTOGYCoXUrSdp0RRyC7b0Uu57btbLoVkFl8+H/p0YIO15l7mqkRIvRHiE
5i19HbHh1s18JwaynXy5X2LoI8qsfD3Z8vDCfoegq1HbUbJb/BeD1KRxe19pab2qTwg8/mmxoTN9
vsFnKj7/WSHcFQwaQBVJNqpuJEwlPMi9gbpUZkxYiD8bZ4joJyCoQ2RT98MbzHomkicl0A7TWT+b
0c/NGU9hltlsXwSLs4MLbwdqCIcg4HT/w/06oYftWNLEftU0HXitvYo9/IT0wUMHBpuykpSaWISN
EbLCH+7K6nGX4bRf7LF4lyzVqLAOXo+BVgMJ9BskAIohUSbXgcRO2m1WzoVmmGLl1bHzFODsDTJB
NLDmD+2svih4xItK/Q9+MQ5uEThLOb+wN1XjCj13sTPjuzAnEFgAiFQ1YV35TT/FhRLkp/KOFxWv
3qxdahc0ZDF/cH5wHMFx8Iac+ZTlz4nPrXKXsbWDkeBkM+HfCedABGFlXU2vmrne/MFNi9K0Djqs
SXVg34Ov9Q+Ccg3iZ6gGQDi3R8JDVQCmLavYlLUDDJ/CtFWM7TU9m3VBCAtP1uCLU5g2M9Ri8sHj
QJEzC+7vCKKvZGafObf/7BPsMXQpylPMRKuklMsKyzYDDXycTKjq+uFbyoVqJrrv536p6Wt1ETSk
/sq4A1TLeEAInZ65S+UQsG11w3bkfx/h6orMqaOSwRf48Zskce9lpHoxpbqrVbxpb2FD6ABawyDO
GE/rstO0FccqEID+Dmdl8VIHOdl9vV3p392W3ZRKLm/l5eJ9cV5fKNUxgWzhT8dQsMRGO/GqohzU
g06bU2N5lserYmrgZoYKsopefR3d/uZMKDBagEFw1teBG9FcHgsU94V8q0Gmm6QQv4/Kg+eD7Lro
V0vFgC8dWC/osOu2SBLgjy1mJpCDfQ6Qc1m7WmzC1dgpxKX1BEPXVGaLsCKH9/2StIB/kSP2VeXV
CdXmb0QRYNYlnNKPIFqGcOzjg6l8B214LGcAEkCSmtJ50Wj/uun1rKeZoKU8szxPx+ZV6+BZDJiY
gcUxUzPdzUSb0D66yMBQbq8SC4dcIupuwSUF4A9QlXjIjWLY5Jt3x5VAOrmgskkE52bj95KI+3Jq
89SxHasKHD5vhrPs908QphkhNc6LG0Xye3Zg9dFwM/rNFcreZucTRuQ3upUuDsIJO9iE89mghkG2
sevjPPpU9AmhO/CkgTEeR4AsHaNdnthJi8M0qkrCrStGkcOfcou2HqyUxl3btaSx4W5iX1ihbXqj
YrWTY1foVtrosql3hKssoL1aT4nMtk2OiGF85eyOH+e9FJ9DbHZ4b9N8apwpGir+x1LjOxLOKFfL
qFmKTr3ewZBjkoFznqjKt29060vN4SBz5K5MkIGOk9RNfn4ylyYLAi60Oq47Z2UEDcqjEMUEPisP
vGfWP6kRMTlsvQhWtwqZFsHr0DpRFnnV4bSTxn8oHUKFWR2zUTcaylcoiBNhL5G9JTAGGBdG2rqY
01CCIut/nJEkYerB6Ija+rgoiLvcH/2GEU46uMf2ljCl3JpNyvskDyce5ZIPlaowJRpM7tLHq4zt
auGO90tGFdTaKWYRjXhNZKv9ubGLCErJHLOBMBKh3Y0wRXlmXGbGoncajShb3jX9WOElVdxge6IM
50M8R1Y/LnB5WoKcMIblx21BbpzQX2MXLAWBK8V9jxNCKuI+Mk9ufHhCZzAmn/m3tq3bqdEwEDWO
sZUyZLs1f6yb89N09/clvVOJLb/9JKp2NyiHjnRWN2wvp7ccUA6ul4BQHuzqNYeZSh9ZLBTjPFoY
whobvFn5N+nV5zn5BMXaOPEvllnm3MroSPCKM4lGcbPbag/NIvcChy2KOKSzxi9GAIr0nfspS3s7
Y5Tu8iHjsSawZLpRHptRf4MwYr6Z8dMc+uZU475QjpMWDie/TtQXQEv4m5PvyXqXVT1CNmCNe5Ei
IM9sEu4XKIzTaBxJkH6iyfejWNKDvOnnBI40bgz7L8weyLhRpdrlfeN+iPFZTOeiLdVGF9EtCVBI
b0vIzmoaDyrB79y04VQqTZbhj6/JKzMgWWp/ExbJVkbkveYmM9bY69LiT/A5zm2yECMV/wyRYwgC
ao4Iuv1+/mMQ5slc2N8Zeokv4t9a26sLdGIM1ahvJtEd4udzk1I9IoEoP+LCXNZl9xQ2fTiAcCUY
a9H2uuJgQHDA3Wnz9h2kN5UvefbZItsYTSLx+ytUucH7Gp46Zm/iG4J+39/niW6QeYYJchjf4ssA
4o93vqsNDb9u466YNNYzY3sulaSR99Shv/EWLi+BMHmg+xQ42J1dlBGovYf64/Qmb1vxIo+LmKRr
xPTD7ypci4GZ+TtACf+eUB31ygm5qwld1QAMMtgd8XsfwC97HpvLlK7889JwN2n1AQfPlUkDGNue
5EmP+Y0zlwzDKWnMTLDU8s5ZXrcGOZBCyDPwNQBch3fX1mlvtUwmKZTQ66gqB1uKaDYRD1W9+9KE
EgbqbkdOM9f1yyRBvf3oULUN75DmNEfn3nyoBIydHm7dXJ/twc7tMoEZHPr8U+PxfRTvUclVWsS+
UPpqA7lvRLuNQPGtl6R0FOgrElvdi2BOTwsimfYLXFOvQFEmjSErhCcsRGIF6o/XVkGpIyzPbfap
lo/kx/V4X3kkdsb0ZcMn6O8r1Egd9BJS0rBXwKklhdlv8AJZwqCnFa1MiOcURHO1QHA22YPCZ3zt
L02+TXd4sz8G5dN/jkUDHzLTUTMo7qZ122voZj2rFhtqcQAnvS1vyP23xCp98HVz7UYibo9SNXGJ
sO21VbWkHSrFw/bsxgEt43sfvtqoyvVBBLu09YEIeblyHts9m6FY5KerV9VngNPZnIWbjWqrJdTY
9+/KlF7JtlDVBfrDtkgjms9CPBmCCkWl+AfM92cyiu1qq8Uc2vlja4id47Lzf6J4KeFv7LEvA4xu
otmB4EHWeNyvzBd+MCDU0y56xdYdx6naS+J9eQLgfAdyBBLwvtLv7z883CjHCkU0w8cw7VmTku2S
GhmbuXi0tusO/LEtnSo9TL8tqDtsmBT7gx7OnhooUJYAvNSamfEP2Q6AKw67xLV2cbbhu2JgIw3X
MDJqsowF/fo3I/1g7gDu9F8Rce56EkUQn/wJMMqLTF7lgFxCO+BCn8XiXHv7Q9mttnhHTpScG0A7
ApnXgwSY6f+GOo+XceSjG3nr1pwvphUpKh09/tM5EW1s3VccpYCMeGqmPrDs0ySCeAk7xZX0qqMd
IcUV4SdbpYh3YNMxdPo5cN3KRtdmntWvYy6WyKXagGtQjQ/9+uPQT1D8YHp77AfxUJwPMevRWgCk
/j1OPSGAD142X+2lXmEJ5o+Ixs4qr41T0Q0CYZ4Zps7MThnuPdCsX7imR3FJlYzbzU/PBi9XisUS
nGjAuazytDO5sOyH/zdplqbKbU54h+AvZOQ0qCKuO8Vs5/7/YvrTvvJPINlaAxNjHK9fWAS9UFAR
TDskY6O9DscA9kJfZeOJKo3o6CjFwbvqxAgIWcUiccVkml5erVCFU2qAd4vCHs2XLGzPEmP7brmZ
uHCM/UW99gnoiYuHyUrjpFJyJAhdP88kvLX2C50BlW2aODSUTEkuDJ2P3Aw9xJJv9wVnP2Veiwqf
/zSJdyP3xn0S3FKsbnrMo3gefMCxXxRksZwFPniBApOILvrcZnF5bvUADqcAtnxvBZ0czUIyZ2Ob
Oq/oV11qDZXFpYSd5h+alBazJ/5XBagPeqnZrefcxFhyYCkegrZRyzcq0t3qFqKht4Ta8SMQZaF0
gtg+BOCOIR2JpbaHWoK6E2DICRaP1RZ0doAVatkpaHBUgXD/oXQaO31qS89tVHVZAGIHSiCvvUAk
wPCRrk/0VT30M+keHAF+9tmgbIpyxNlhO/LwSdtD4MS5BmTe/ojud7dP2kDY4QxrRl3ijUPX3JLa
fLuyWQUfSjsfGt3Wc+YHIIhwfBNmGDaVVOcoX+6l3sLw9/9h17Lpj9Y7dmhZMzraMv8m7l03hCxQ
94SOPXcHuzhCWz9AdYIF1EdTVVitGJatLGJ/Ni6a+2UOmZWFrdoWKtvEjfMnMMF43rjjxQzn/AYI
t5KXado2tAl/yaU0/jy9NSd10DqeM4mN4w5XI3e7luPhNhEhVJBdFaSAjrVVZx4AB0t4si56gF/a
nBxmBgYHAonFIxiEZ9V4m6dOvPppOsXa96+RwDPSJEsye0yGPfhJLDsD6OVBsqt9q7djfXnexY8C
/OGfLoj2aj9sIQPMXnJH12QPQcZ1QmqPD2CGWF56aalB/6Xo21f9FzZPOhmAWcxylw0EaNUT+soI
uBm3Tsi30tYWszooeh+iQBlyl02veof9hNb2I8GxGVzJm5BcajV7Trs80CleAHnm5pOIfydu63mN
Ue/Z2gROm+Tv7rR47UiTxBfTAAwGQ4JuZB4PGaLErAKITppl5mD/QmRVSFQX1x1yIe3dflxXcCcX
ekgYMDN8HnspM3js/QR70+3G016iCn9OzTsjqnb3NS5CGus3aZdttL50WLS0hc35uYoFRqihSH4y
uma0HZXYgGDfTS3DBeidqnm6lbvGw5oxpCYBvyNHdeacFKl0L52HumI3wup6MuKVxalCOuLOZk0s
y3KlG5E/6SCj/m39L6OfJ3yJBVxtVllZG419/Mtr1/oATS6wWpYeisyllNBB1iOm0UmhNgtdk2KI
sa8LStOLm0BVXhN7tpgtP6eiNaCklNSCDql9EdoMKx5CPS+Js1zoRxUs6LJ2nZlgcPPh6rdDju8L
J9UBbSx5by4wXdO4ZqR+vJwMQskMxhUht7GRTeQIk67gWAylMNAnF70lVq6TKkrJevMe7QEgVQjo
VUPQbWZbBIKokF6OuvrYcAXPKLFEJbz2+0o6H93ejPDIkxqjVaI4GP/OVB4U3QFWSnL1LQgGW4UC
lETuMR8nnJ1KPElHWEfXlOT/Z3xowX1Sh1wth3STxJyjVQGy/Otj7ZQSFLlpEzWyB3xxcVJ4Rnxx
rpq0JK33mnBXA6O9fiV/u/GLokZQCpeg92JSz5Ig6YNhmsf+/T9btPyMwqb3pnZ56QAxY0ZHZPML
+yWKma9fZbCVqPU5SMumDuh31wIU8RlubY7kmrz4qWztiBloFOPX44sHlZ2fKWFow56qWDOr1Xnf
QKiCrnbkTXXJUjuellVpciBs9+/YSSqClzcGH8jM4gsJE30pmyLM6yIwNknVu0t/pIELXbSPrcVD
bcMxuVUtBoyEVQm9OW3drM69m3fS9aVqALOJOybVP/8buy6Uu+5pp2CP95sEJgMGnsHcajPCca58
E8F4vlnCv6tXSV2w8aYfczAaK+8oqG5ViTln8ZFzgRpDFMDgVr6/iMmCFdML/8WnB1fpRve7MhGN
xGEfsxcH3LPepCR85ouvskcSnaPnT/pBeCL92aVylVYvKo5TSdJYT/biuXxTTUn/K07N1cJnx1ww
XkT+1KH9gm7Ht27JhqpZJ7gui3g1d2XLgCsDWsXSffkzK+FO9GGPVLzQmTLapKHw8vEJ4tSKu+h7
NzEXTbsmzW8eSCZaNWGASlIbpm+OEwUb5f9sES+BLtL/F2kR0Kdo+Xtf93AzlZUzoCnvGJ7OGf/d
iqjb7o+0qmsIDjF9CfxiQln9m9nnKqSarlTGN4Vpey/d+kDy+q8MliZganSGnsDo8wiKU/yHjhC6
ja9iVkZ77J2qN3QQO7Vi1Q7MJc14IyOHK+rmcsm1H58EulcZKs0kMwVVTuE+G9h8XP+2luq3hRLm
z+/xPzrd2s0j6PcvojapzqAfVcAytpW8fVPqpr2FRhnqX8ugmdp1+LsdfKzl9Q4Q7PfriLRSZ+bs
zCYv7Kr1ZIVE+YH/oXwecc9gXzHiJlvljBUNfTegdULGSQG7jowpqYtLIqisJaZYDN3I0Bw6PH7K
26ALEyKfO7hGfz5WnJ3F0RcrjaS0ytVBfYudHpxQ8L7xtWjAI1A8db2UmoElDrXIbtIlLUGACU1w
N0qFYFCpKh1+5VUJ8mResNyW8oy4hv4JXUzp7NKqiNPXfncPD+4cmyJeO4bi19u1eJD7g264/DpF
tlFcg5WgEcpW6EiM9USNz52qkCzTkawrGrxM5aWaSH8TfhTLNuTCgZUb+GvX7B0tbBvPRseYUii/
Gu/ldC0qDBFgesBlXbwtBfvbmjg6kRklGr/1keV9sv4BBS5PY+RfGSQnvi/R5pq3xSdWV8DeXmHA
lIceyW+VY8/BQnJj3oArwW3kcLDczgBm6D+JDcIqf0iyQKS9qGXl5kn5VtAo7AlDEeunYMmZKaVF
/+Mjap0Fuwn/J1qpQ/900cC+lTwVaT7JVnelEgMuojKSiJtK/vQq5pFs04a7Q37Ej3H9B8ujAloe
uCjenxDdv7HJrYu83oOp8I1o+O7+jEUqwTEgTKEVWpYx/I+S8u0fTl8040DMafChZq9bv5NKlKMS
zT43e1huFkbTfOGWaJlXmJgdrafyCQfVpzRPEAHLRQnXVfhMhqnrIvZurxPR9pMnsA9xHPds3ur1
AVWa37zf2ZMsZ8UvEEDceA7bh7gfN06Kn0z35POl2pPDbxzFBKbf4OJ8IUTnqQ6XUU/U5a6PeVwi
Ki6kShANDyqKP23VTV+YyhHhFdwoktVGdYWXVCp2a9XUpQ/UmckcUqV2xxD0HyrdwussXGglxEUC
Wvr7tl/JIEQko1SUVINGAv6N3qLtRNzn7wq5EhF0ueZSmuEYo0m+PlPp+mgB6NXuLjKZUoQzN22i
75U7HEamHAfii7Z1cvROUr1kmrGq41uY3XE4Dbi+aAQkn0plSKVU321uym4W5rN2UwTx25yXid9L
kTzd270qL57sp8nr+e0yFnzj9Hz+epTCAaqQu+yM6cKJO1TOpz0WISLrQZyoGAEcaoq6ROg5HP6R
nSKjtybPdDzfoCxDNrK2o2CQygCLrgdMzbL9Jg29xVX4DB127gq7WZNl2BWkEA73nUe0C3cLcn/9
j4pnal2GSgbx3qNUMvcG0frfyUTAI6V7P94lx1LwauvglzJd1y3MxcK2wVwkdFHKz/9BhIKve8aS
mM986+tNpgxpDI60ZTI5kHhxQgMgE5kIsdOR+Bx8LMTeMXCagPViSwWTBElWZbMGr96Of6zxwndJ
WNmXATWWq4KPzm7Y48n30F8t2fB0jps7mOq9jmqN7pt6SR8Bk98KySPbKP1nG4wzlOv1zwCGGp3e
5uKMnO1kmTk/hvFZPbknM+tLPv/EC79dVPcoIruqVxt0zW+2VRag2O4ea8w5wbSYWViq8ikqIROm
GiDW7s2CS4xG394446TR9iKVXixEfcaPcxk10ttRMxNgU9junLHnUjONR8yhfl4G8H7ZnC81vZAu
JQNGKPc8ys+cUfKLJah9A/ThutkOs7tnT7ZYz9vYjTfQKVrLby8JinhTp3kbhN3mwJD1YOPfSUKe
yQxsaM/JxvAxP+V8I+5klwcB/rEDjKvfSlXGsXxUR/8kLGLGlL4wXTJcLW55RFR2DEgTrHvsnVKt
RfKmPl59kzFotEL0kk1Ncd04EBB+YZq3hRxfQb/kU/D52+7nZKA0P/9XaFIgGydoOtLjBxM3rFVe
bTSgtWKR+S+sb0a5m+gu02nhstneit05BGwSq/4IK5HAjDXoeCYhr6kBRLvIMZX2Ff41MczaJ03q
z0tK7ZeaQ/WsR4ql3EkQrobXSZuj35k794X7rPEf4C+NsuZNqcKxGV+R1goPqE/mDhcp3vrTiRf5
ubGHt2Q/S8dzMby+ak15bOZBzZptY/Wn+3tGILgX5xnIKujfaaXP9q3X8OPl9jAVCidgEKieFMaZ
+uRYPJs5wBXp3OhpOXcwTuKMediq7FLaYMT4ro6kkHVZdYqdvrM3kNdMXnlZgrlVPpO18oLitcCw
2xHy3C5KS6QI07VZjvfpV5NuQ5mgpEFqCaNmNz6JDQimQ9Lnux9aGJ+LKW0fM7rrq466YYrBRU8v
hg3bQRp4DcCY8bgWFSupvxOF5bqtcPStfUd/i96MTHNErCZhBKIij9rLUkNiGLsqebil5b0qrq5h
DC2yL+dAY3WtPeChxgQ8HI/JYRzpYcZhx2CvjTCoPpUwPAtY5wcKKDNie0yA+EyTWvYoI4Z9oOi7
YmQhUMBwww4jmJrC9Ldr5h1pelVxlE29dx9tBHcmyoLxLKBvaLZQVEqqxSULVE5Y1iTx7CJ4kvxa
HPJO+fUPDe51+/PFXvFEa+HQpS6dTgCArYfDbHebZuxIv2kr8Xmhbnvk5zznBZtnDH1qPpSJonTl
8ZGAkYdSVC+6EFQdowTkdIJMa1zvVJ2fLxDz3oS3Vs0jISb/w+8vfySZUBq8zEUWN12ZsA/Hvng8
5Id8Ohg/VbCXx4nXcg3taqbImN4SOaWeuv7zoaUBny5cUx9xPlK1jK+7Py7b6eG6Ct0cDTqtvpQJ
gR0r19A2u+MR8iGxvHMEevs9/V4m8gIo2WZMx5ZUK2aTfLGxlK6QL7nsEd7FTLcGc6F9azpRCvFl
5y57XMXBXeStajRbEbsmT39Ff+0WdEKW1oMxitKBL1d3roJRkwXRUsf3zJ5i1EQIsoXwTgZRMMxS
W5BG7wXcU5mtAF4PjsgFEnJZQrGMbk3Dt4vnUEu+/36iNAw+7StUHFizkQuk5aL0+/uawOIeXiJo
lrktqIUj5CtCLiMGI2r2XjGb31bjxIrDMU2k6gVsyKoZN0Cn1+fb5Jcn3wo96U0LLSFVJgjQ/u1P
z/swbYNiUtbYxmBqUZgDd6yC7oBfHoCrRlvScl3YVC743K+6t0WdPXZ08JhElHKVp8I5rh4uI5e1
m4uIMjOhdpwUc5dK8Y7HJHHLnrrsU9oI8qOBJmz0NMP3E/rmGBtr6afS9WUh6CybGU4NWsov2R8Z
ovN3MDSsN6+5nzv29c1CCeohcdtch0BPXTvCnFZntRSi8MVBsEXUE7cjjHmDit7AAzaSw6pnUqR/
37B7t2ARh1p65ugzRZ8Q/uW+CSzjIbPhLe6GFGHhyFxncgtuBHtgNcEo9g+ApxvCRNwMNygLg3qC
6FBzKMWM5+uDH5kaW5pH9mHMGq6eBIs6c5SWuu0cvCBtcEmeOa/gu9pZYSkDJ/5czE1adw64RcGb
jFh29+pRA4pSdrGjM13NOAJwg5u0JRWNaKrR0OwYGkyUVbtFYIf9L1M/6d27XWEtcahM0OW45gTq
7gkzTEXJtmVZvS6EspHa8wGLfrhI++tKqsqVygaBfbYEw8Vof3ZCjXUb8Pn3TAIgFo5Nj98gJTzb
m0mrA3P6jHNKf8nXCpjflUBTDG5B5Wb61v3wycrbu6KxtSEGwoxIxKob1tDyqUpGGtPKssIYE+7s
qXezs4wghNpXxE17pEVnjsuJTouhcLEY7e+/im50GWskIlDmjGHFhEZ3lq8+ekZYaeiuEHlTNW8N
qPYlqLKneGyBdUse0LUoi3jck+BylkQNx3OS5UoI8dWtiHYzXFRTbsWzWHoFa/jmSgynExx8Zcvf
R5lyqeJzy4jIevX7Fp0oe/gTY0MA7g1LYiGZ1Qxqi6r8VpKwrFlyBO9UkxLdskKubH+NYLGBbY8L
vsvg44QylCaKYcI31pMATCofyf5kPTO1I3Pm+otWniiCu+CrpmcDemzjxxTuC3FX6ljYra61yj58
SOhioKG46LoldamUz0LUSXmhu3TotUlBbyI+UpfdHs7znEqK7ya8XBJgrGn1fxbAihpgUP15TA4G
pnOTh4VSqAkMmv7E1EE6tvJtcpZVGOZ00x1/6eR8V/eydrtlEWyn7eSNx8d5/syxcJRphdDKUdbI
CvCmL1l1BnvItJJoJfDxNcfMjuy5aVbwWQza/4FIVVXTorkr7pjxlgGThaw41Li9isGUO+LSumgr
ai4XDpLwdVO8ukELanrX6f+4cn35I5t3kFgN20tTTN1o7v1UQmZDFFdWz0ymWkZHwRSHZt0vNWCC
KA6xILBaoqNOcWjsTKP4EgAISa6p9Kku+MQFs9kksaDtcv7BkhNSToxytkr8qIyCtBcg5ApRsxJo
+MJFYOirOId/3J2+BTmLpeB6x5hK7nLG72n9uVtz38idi75xytqgIZ2nSl2bijf0zYtk7w2J5ER8
e5PHtN3v2OoWZ/1LdypTnmBbBLOezBAicxpYpmSKKWJyqgYWH1KM4J0kSxC+H9V/AW85znZedXoZ
VKNCTE0WZYNOr+Oc2tHIkfEk7PXFVTY/rbhYzkmsF8kCuE+FypyETi3JZfqr82WC4dgzrkxlcr7i
6vgXRu+WLR05nqPtqJA+2urhlKwSprRfiD0MAybe2P8SyLfQp+ICqtbsfCbZS/zLGfg256X5CchH
p+hQ6hjw5BGNlN1pDBmO45Bs99rWG9kSSwrFN/wVHlGynP8U0tEqVsbufSB/T6Iaz9LAB4rgGiny
ggac8L7f8nm6P3+chLxBNtdaVeBVnd8PQIvD8VT1bnugMjecsQvEMCROxok/HwWYFHhXuoyMEhPC
9UJkI/1LjSavNH4iPK7OIi/NTwhdGBvY6wFBIOaQeRDw/0GpsmORWOi5OnUq1n2IJUBShfEsmgCN
d2t2AYq/fIWtlHwmJ5yMuUJCjvy0tUmEvymMHsn6Y6upp8N6TFSdNYsukKlIKlVJjDAtR0O83xU1
Fmta9Rkc+PnmtgkxBvyDdd4HrA/zIU2CnRp9VmulCwuErwhgeWYhE6o2CGGbZHW0ybOxOc5nL8mA
u2/h0NEd3qfg8MtE4hvBP1NJFwmQzIEQDPfQHhXtOOSmBGjHK6RmtGDYTizJUGsdmiyfPu4CMpjA
b4bypANPJwREs0W9IQ6aydzLtslbM8zRlXUPG+1m6gyLFsg2wMmn2u6zrsymsvY8Yke6NZ/Xu8FK
dLq6WzMIoClviFnst5qshw7C3efNo57657E39cIc9l6JRikbiMiWZ5kbojGOFPe+gDvCbbeEZsEu
vz3UccHgARxl4XC4mHOriRvAqnjlIphf6YcjC5LImJ4Umab/Ome1VJ7vfcILNY8tVZbCeJbCBoyR
+hHFJXk1tmBAYmOCqM41lewidHiWpuRd8MgabiTDaMe92MD5vq+ItwvDMVo2x7BYoIQxanxH0P9k
cKqoU2DqAtOaUpleW3bPteFJesmVA3rE6WJLQ49maMxy3AEkisUniUZyiTE2PbJX7hwwMeAtaKHQ
G4szEN4sGORZ+MFN/OBVQW34ba4zAKHCHuSqYGtf4fA7CoE5WmZIIpk4Y4umTtlMHcSSapgZhIbp
zZB2aJXPJhvE7nKvFw6E4bTccR7lwbFPgQSn9d3tRZDeL92dqv6AlBrnbGkd47+zg81C91TJaFFs
d10oSJ1xwTbvjTLcpH09dpOHHWhB4ZMon4D211paSA+U3Q1YUL43Y6jMsB7l3BbQ8HDIOqZ36VGd
S/iQGMO7kgYyLn26zvycB/mmorXVEPP6UpQJjvUD9zSuEr4xC2nMCIa4sbEqxnQSpR9f6RaoNb+m
80MmiWqmLN0CFSlKPfgw+j/u6/wL0mmtFpc0gIuJQrO3EJj7hQA20ftLtMTvlcH3LcQBbmK8i3SU
vA9M80vDwGZJzrETn2DX1M1zn6KuvCphBWRTOiDZbDxcQWRAd/ilFFJP7FPEaR/eWX48CvQF/X3v
p3k1jX2H6NwH4E9yUXjo8hEbNR1pZ8fZkwten+KrYrgRFr5uYWJp7EzDWOGG+43T6MxqTagNH9Me
G7uW/3HP4svLqg9ywklBBgyNszGRPWJyF35s1bk14vfyuRkXB5jxpg2YJ/Z3IE2Cv6FE/QHRd2Na
80oUl1m9y4Oexn+N+P3DAzLMYHL1nUN1Cpupso1v+vh8CHatHVhwLJkTkb3qw3VtXEawxoE1mFgG
Ad6pEChF/nYVS2FstqkSFVBM46aSXqBleFrMxFrpTAMRtklIg/JCBQ9m9paIHDaDrCAGzrwusKQU
7VE4MWKRN1kFvZkFb+QdjH9W0z2onde5M3+9oQvgIw7GmXYyLcvQZzqIsTZOKJrPRgukvQ7slyqX
aw+87T2EH3dpod8eykGqRYZfjUYSKakc4BsQa7UBfvZlQhHOUiKPFkdWEecFkz4UOjfgpm3f/DBr
drKCR/ofaYH0KYBINOh+MJoC2LkstD3otyLPh7VVgkjaxcBZhjBN4V+wH3keBig3A02lwbYJJVsu
W2+sxz2+XMkJPPzkPN91CyH/tQR8uapSi9Ol+buWunminnMOwBxQMz5M2fldpJCwcxVoX+GGSHfE
RVq8rx7YLn5D6gkTEv1Pe1nWHokFoGi/zdY1YeAZo9YA5NPGK7PH1j7sBvHbEPQR2fusTKCCbADb
HFTPvsQAGyTVNA6/galkRierkbISEnZSvR7ycfr0JWKbkcYqbMIPnOjOXTW+1cj22S0QjWwQqEmd
0kgDpio+HOxeB9cWlYDGQ9qMJnKMAeVCEkVBgAZrcE95OMtciGvvYl3sgUbCds8mfM5lnr2VlRsF
Fps7N3WhL8drHKWGARa+vQl7YCu4NAsJEXnr6aUfcrAuSir1NrVktdHSd5ce/CBLVC93oz48WZHv
o4AMXUEB1BMxQ6YFspGYrYl5mYghUl+YzmK9NDGVRkap0KFGfYGRU2krnzD2BK6W3nk87SqAY5lP
b7IYR0s7ouzU5Hq3xmrS14HQc/eUKY86VpvGAq/zsHxqLcuQAHAEerS/wgq3AbT1ChWl2X3d662S
TXPrtcp9lNiFWMqudDqvoppWUmYERBV/pq0pWJE5J+Z6EZ5cYqAVBSCsCxRWYqBIteIbG2KI0DcQ
JuXCkZBMzdXscfs4xU+9uIhdMHzv20vv7jq6GpB9jx8AYpAQES0XSQ2Z/XLwv6EXDD+MXwQUXjBI
blIPWjFpGtSQ32GFwqpSDWWV84NFK1ZuYUVLXhxzDbVEgUtPX5Y/lOuUpT8HkiPg6bQUocONhbAB
HcJZzHvCMCwGJqCvtQlfTr+HlFpp4+zHYvUWuQi4bq3zSbW/Z0slL6DJ01Ie1VDYvWcfdBzB6q9E
1Yq63Hz7BeF0EyEedEz5i7J5yxIBjSwoqJsuwe/rmM+j1L0JRGt586Vc6tQ9RF0pIHUrpIhWzXGB
qx7L/2hnn2D+PSpe8a1BX5rGg4lQPUKi7XY5ML0SSpkdMCxVPDTkZ60cjGWnekxTPNkGkJ8N/VQS
aFr6bGKu+uOthiLDwuosTf3Ca/DSIyD85ENU+TVA4kmPdE2jW1qSJ5Bvm/8ijzQoMGWrdADFrxIF
emIi5yBP0LVIVE5ZpMHmwOF30xnCw6scYvk7aVB/LTOzn1/BRvrULmJVQ7rmXGFNByfzrKE4hq59
XxJU1qYgbvn0+4CDGDefR+MghmjekkYM/mrwHLIPzUktp3TMEiLEIhW63E/HMz4h7RHjYL41sqX0
lqyzr4uzLdDY+PGKB8Mj8PrAV8D296nMVNhOo649GACQ5npCczQZbSxqzYNmWQt2DCcaVcaS8+9x
aqThCIKY52zgs+4tOOTO3dPxRxW7Z8tUi6INlhOOlM87wBYxXhIy/Vn/TjZj0i06SiN2cKY/YqWS
3gfjQMY8gGGQsPp/g2caDElIBlD9q4a7b3HRuyYvox0Mrrx9KteIRa5lAReMOCBcw6Q4tBnaz2p+
e5ba8Zf2GEYOd+fgp4tYq0JvSZsBEknMvXPDrqKLCbK+H8vSGuhmrlOo/TNqoWg2jsshK2+0M97R
1mL/RERAjNZSmEzxJYN+NZcurQgUOLzcsIe8fv8WVWrin1Yk9buBItTuzEKKKNuFanIdrrdIs6Ph
Dq9b7JiRcKcJV+kQ/rCM1edNmQU+CS32NOdFj6x3kSsyxrEIXEvljA/cQBhd43LH1e6zSipm+FSO
mqdCoqMn3x91RTvgtGXfWccVOjy480xhrtwlOt0bDuBvzvH3+Sf/CgqW2dJ9uRrhoiFVb419uuRe
1ld5WMUhwLIWD5kQ7rU/bTcVt0E5Fjk7Ni2Cgz/j09WqYmOSyb+qvHCaIDKwfJdvr1MaCNWuLEyD
apez7CBCEt18vJFwHec923XT3ntfv8/l7HSx5zTH/SEvjJYnW3o3zw86eLYiILTXUaCbHJATXg3Z
2E27rKsqjUegZXEiUJKupmgLIDi2zTQXeRrhE/EL9RBlNKbNIeG8uAdIKUrxfnUM8R67ElYOpig/
lwgORqj60fdivg1/MFeHbyBK03RwLbrN7eewFxOyoQpYRC5+7WZNUc3rjHx/7JRaszrJIijiUUs7
1gN5ztjAxvf3haTlP/cWqDMT1GC2qUgXi2OJh85NaoZrsqWGsUg3lh6kbWcfLHRGkWlTbNkjv8xV
LuTCadnyfq/+djm4WP1as/0EoKVl1FApblH3HYfoYHts/OdVc7Vywu1gOyIWM6aeIxtPuC3s5D72
ZDl8HqYoLkzyaqU+/tEcw9I9iE2JNMtV/Iz9KWnnpdZ/R/6x+PvdlmetXkfONwWJo9QTK4MQyJ3I
uPFUIC5tH/195p3BSGJjkcRaHxt1Lriv4rZSnVVgbEDLVVhlDZtaPTWHccubHKs39XdDLxKbztIn
WlbRBYCRFb9Xn+SVk+bWmzQs82Vi9ScRQcGK6AvPRilQ5r9OJ2By56BZ912BR5vDDj5DOrj5y5aR
BmUT3OKlGwUWrhsTWbj1JlrtnzGQYJEI78x0F62knvH2sK4eP+ESkGnfK2SzHYyLWMoSluWmayK+
5tbhCS/y3m4jv9aLo/gJW92iKeSzKECJ2dexz93FDAOfwlVELdIADU0CA05waHIxj6TeUlJxhH6+
hJnw7i0PbICBdTyD5ZDSN64ypEZ1X5znxMEQiNtdieRjbU9xqgo98Cz22fDMf9NZ3HjMGb6CWI7U
C23vCP833CuJy1+oNW4+4tYLfjiEhQvmMPGWsh1EDg0hRtk4a562Tj98oHIe2NZCKRmRnMS7K03t
tWfQzOr7CiaWRvO26r0hDqVpPEYPtf3DU0cL4OMU2GDOCMhzh7NKUQPnOSaf0r3d4TW3ztMrS8/q
Z4rlTQNyfsXMMlnN61IZM83E7CvmYA5ICdoo7DJmYmLZaTzAzkskec7QamdTyZXFtsJJh2jxRKwC
rUq88b1Ze7VmMfiFJg4BEwBAhMN7KiCOH9MAhJ2CzQtgQX6OhU1JKnmxFjuDwB49ifT2ny4MCFVw
SkXSR6Xel7FdBHItHtAlpT7ufgF8tmmPtqtCMdrL0kixDrdpDRZuwPP8U8lH8LIx4nD4NylCmDzk
5rMtCfnhbUNZ7heE4baTOFl+Qgp/6iZxmGfHd9hBaQSr9niYe5BALGbPmhUz+5ggl2ULAyiyqq3U
RK57Mmge7Ucg6tmW5GB/fbgxUwul7AGkMq60pm1TFLCTibaCRhNUxr8rE9oPRRw/S96d8WtvqZ6b
kk+bjTmoEpRLaXM9SPI2JANkfsMskrzeYw89OP8c9zcg7djP6dHJxyiQpygbNZgiK6qXT3Q2HvXe
gf1A0qsmI5drpN0Vg8EDR99dXA8/wdSg9+OW7YiVM7oNOokf9+Acjbi3GCKMZpUb35m9kUeNdz9P
WnaM5+dMbCjomH4rvRV6DIMzCqrU4UHcvgsD8zPwYR5DQtCLLcsDcJxm9KEgiDHznccM5E2XPNjp
B4tQp0tW7BIdYym/3R6NrmbYcf2qIbCA/bNmggne51gE5fh5h6j28SyXlPEP2AuAIYM10pFkeMLR
kIgpun68EzB2cD3V19RZVd7UPOSb39Vihn+eQF9m/cpFZqNKv+i1jpFGu8B5uAVlRFVDYHyX3Ys9
eG8KGQlRkqR/S8ogLXkf4gYxf/P+79OF7vhkOBZ3pwiuWsC+2LMGxwSbvuFpwMQ+IPNY1a0UwP3b
WFDNWe0YTo5IonCr6fr3MzXc7HOriRMe6ffJEgXTIb0oBhk0ahQxDjRKOaQG3i9LkKd5BFIV8ViS
E+feHEy+l+lYRTMIlM+fJJFHWpV2yRV8ygqYjOXvyV3QdgS02mCPQO/gICeuAwxNuf9q6qHmZevM
yFImYJ1aoUx1ZQhFc5Rp3cewT3AqXmN/p6x0v8TN+s6r/EVjWGmFLto+RPPFUasa4ZxvABfe0AZD
Gdqpm8IppKlKv4Y0L6zRbUO9A+g3/5FDzWnReEdGfo/H+IBJ/o4l9K1PkMYt2gD2bBtdf7MmTyNy
KSEu2pEKG7v44y9x/KxoFLNWFIZA61n52tmROSPzgrdyzyUclS4vfFJp3RVBZAmYUSqcU5fwTNlz
OaYhpJ7wqvwKJ96F3rCDxV9dSx9HXn3rBVJTj9IpnqxUb96xYPSf+E99LLrPOB+errM0xtnx4Awa
+3EFSXjSfg2Zs3vtfhNYfEaHMFGWbtgU3Dc0cL8DvAXXD3rSgnrwUPAvTpyHqt61owpEOcAbkPDM
BZKgH6lh/C15H1WUJ3pXXupiRLuvG0gm2y6hqzufB00yr2g6Ft5Yz/oMHuIBPeIupo5tOiWkqDHT
pPMeZHSZZi+dtmnkQsMu7Z9m5jK9ueeRGhpOpFNFieBz7D8gHDjnMB1RxO9Vho5ehGfuL48ttaz8
Z+ZAFMoPJbYF7/qrtmw4ifyO3lzIcgmhKMF7FBCQLkguY5cZhfPHyEjmjXEHWUQCzK+fB3g+TOBo
qQMAkJjk/SohDF8W/hmOKXbIAAzP1oRK8iiGjkUh1R5MbOeBQpjbXYxFwqGsPlmFBWu9nMoWvhbQ
KTCh8vacu+1jYaG0Tsn6yEW0qyIlAoZ1Bdr/hZHaI8ttaVj96Y3BkpkBFecxiojwR2n2w7x8ZsSH
cPFip0t1yJM7tW2IeyZkAnSmTGuWRffbgIZsWIXPXTMfOoUbjoS+HVPxShbhvypdOHuqxmi/vZzN
6ujf8f1LKe9Ta8cezIwL6mfoePi2q45QPfJcrhWElE6fci+KiM8APwqzu3XTVfll8cITOp1/yce8
ETJNoHpN3qC9dmQ2D8SEvh3xEwbYzAsEHApzuGict3ZF8SVwSQoLe5RVqhU351Bql5ln17lQDHQW
WUiDkNdNoSCMFCoVMQ4Y5B+TNmhS2Xvk+Xamg7nx70C+sDrvdFCILFS0IeeZMU0QSiEk82+I8iDS
030ZrDgDz/xafmHYUv33U2MI27TuNsr60zlQ9trtAhGg/TKDZBAB/cqHxAq36bnNpDfgL7zhiRu8
D9RjggBu8GMHu1YDp2nGZ1WirvpoMPhFyJjtNgsDMPx82f2ggBYrLvoulVGMi+ORCeiInWsYHaSx
UrGaA+2oPIiUtDdDVdo7EtOV5ofG3RQv+QDPDRHTv61IcyyM1Y6POi2icJis/MLS4rI6VP4ImEQ4
sIkGhbKQckW3u6S/7gg2/beQ/8MBIe1ySsn8fKVH86NSOhWbv+WpPZ2lYjb66oQDRAYz7zqr62je
0GPNgfo8EqIrb+SwUIoTdfM/pT7To/dTyI/yh8H3MOJi4ic/Pl95WQlD59j0iAtXX41KhZVe05sz
2+bXo5rEQfCk0DbXMHh6+3ibI/utFzCuuVy2ZVSrqPADekdADekKHKhWruCA9bXzBj6oCfSpUNV4
ol8nOQV2C6UUxvswtfwajKg4wFXztc44bq7QVj6RbsKESnNPLwJHdx7DGTfHclh7QcyzXAjG7+kN
pyNCwz2LdeyUBBjVV37LU6bGKVwwqEgpN3UmJXO12Dp1l63M3oiPjSTLCkv++hIXA4eUATUix+Jb
ppwCkZ48OW1wanE+wfJ5Okc/slp7aRE5hGW/Kf5rnALA09eXc5NXtTQT39DZtphEfnz9lQqAJa3O
IL/xbTVd1MMMgnC+0JrOCFEkibUhHknFNhkmGxvBzTGOA6N1skF/0VDJgRRqeQZ9h/+y5obs0Bdh
mz0fl1W2BD9Mjw2mEkzenF+xadLdxBLQQuoOm6Wx4H3iNrqrVb7/qWf69EoE0ecC+xqKLz174bc5
zbkE6GRHWYQcX5oz+iAXpd2NF1R7o9HAHu5uRQvDbGzLVuBBdQFdutjNO7O4nAtNq+REXNZGvJ2b
qWSazXzFO+9RYGTbGg6h6/dH0xMwfB4gi8/w76YL+0pej4W1ayvELmPbJSuVajnpWgllZ7vIgvGA
D5IwoB3JnN3VhtxLPoNsbI7690Sf/1kQ8pRtzVT6Xv2oWZlaIdPHtcuNSndM0VVmimIwqkEEwofN
2+ik0Jo3w4HYwKVv2Rtg7GZtjhzUojgvXgb2pxIQyAfUAMypWTgYP94uvxW+DzLGd5poon88iPMx
qrgf6gINxkxRofc4SWAN177uqJOqFhEXwpgNSIEeGiug7yop4MCYF8zE589fWHCtUZ8KG9V4LGfo
Le9sz2xwppgRH85GGTQ7/eWRc5NQ3zpaPDzVA8saTnd2VQ5YRD3A+/HuyFUpcjPPGjsgf/jy5M+T
0oOY3p8+FybURhHiHWeYXITK/c23qIDSgYh8HXdzF96dJctwSHET2Dz3bix1pQgKnybx5CO2VGRW
U3IDt+lu6XVn348UJ4wvsh8Gm/GnrMLRECANjhyeQiBCMp0EXtCkIf0R1rMBTD9kDoA8708WjRW+
YkcRnCW1uFQTgCJ2J/MKMOv8h9tsmk4mGmMBN2j2N0MvXBsK75DcexyaGTHl51+ik+veNX+txEDo
O7JrWYKkaCogZMHUvEhhvrc5QazWswkVd4ZbSV70eJRh74B+SpLxnjyHOLOJU5aVl8S9zu5SpUTS
lQ4n823xOVImy8Ywk7iXkTQ0aAfv+bEcs26oIxY9jAo+Jlu3eJdqd/g2lVuSPvH65ckjWpqv5R7n
EOhbyT8rGc9IoEsUs7rOniS9SsGj8zj+mX7EsICeBto8Y4YgGUVbNRQtJ6ko06Np4Ss3bqdrieie
gKxOzIM6GyaQX1AKwNMCK/DLzFyE8GFdLmns5bxdK/NDE4m9iOgDhLc+IIEPFV3GIP+1CUzF7jCW
zDeW+CyPv5K1lHyTUNvMH20F18hYTSG2h3T9aH4PumLMSQAb6O066olpTahgjRziZKiuJQQtwvYQ
LFWDtH1yv/p792Be3jik0L+BCSyuMQSkPd72u+Ba9OOrnozt2+dkW0ztAJKZHO4FKrONVuPHw2O2
iu1t1BHAjb2ThYggRFU6oMj4UsP7EzdH2i2bnuN3BHb4JXCRpVKbL9kDKTMuHn8itan/+EN5imlU
h2gkkIT4KlB2U8A9Z5wBUqimL74BZWDgGU6IJVQvGHGm8lgokKVMVPJ0tijbFRrlFxhKqbEcqJA1
vnYctesvKVjL9l+U2DguBede3Bq2SqJLBSykChQL3paC7GrzpmL77t7UhQ436HT/0gsQMApFbmv8
xLfxD9rNXMY1w4Wgz0/6YeuWhqqKPY/EtgxjyNKHYJba5S8aWfFLg4g32A8awbKARRBODHjHob7T
HmGQu4WQJ3a48bJ3h9i7BEa3ARFRpBnktlriAnMygwz/30Mp/3vUmNdlgPXTOLKnSLrprmrKK26m
K+woeW1jsR6K0VSJ7yuJizT14asVvdG7m2+pbFYihNEkn98ByUzfL/PlO7vYpvVM0T3z7IF1LOoY
QwetZBYf9eeO9e8fwQ8B2Dx7/i9NS8/YZcV13OqSaQqPd4e83/so7oMAjx4EyLg5F53aKZuk1IK8
thQNj+vgAMx8TNte+hUNUDM2uu6bvfut8a/zzd7v6d0FKhHznnrd2szeXABqXNZrqnU/m2vvrtgy
aPLEeMJsAF+nR5I6SRzj7d9YKNoO920ZQns4vsFMtA2/QmUlmQlVDWVuZHN0cmVhbQ1lbmRvYmoN
MTM1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjAgL0hl
aWdodCA0IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxOCAwIFIgL0xlbmd0aCAy
MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrWCjDyZ5Ypn7v8eN4fmKoVw+kGJr9e
7g1lbmRzdHJlYW0NZW5kb2JqDTEzNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgNCAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj
ZSAyMTggMCBSIC9MZW5ndGggMjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KTtQh
hkLIFP/Y5TgeNx/Jv4awn4o9IQ1lbmRzdHJlYW0NZW5kb2JqDTEzNyAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCA0IC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDMwMCAwIFIgL0xlbmd0aCAxNSAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQq0K2U74UPt4GUcCxwo62kNZW5kc3RyZWFtDWVuZG9iag0xMzggMCBvYmoN
PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMCAvSGVpZ2h0IDQgL0Jp
dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjE4IDAgUiAvTGVuZ3RoIDIyIC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCq0srhV1qxs4VQl/3JA4ZzAfUrPnsXcNZW5kc3RyZWFt
DWVuZG9iag0xMzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0
aCAxNSAvSGVpZ2h0IDQgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjE4IDAgUiAv
TGVuZ3RoIDIyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCpAuIbvYwhV0W3YWl6MK
OYyCFwA4pWkNZW5kc3RyZWFtDWVuZG9iag0xNDAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy
ZW50IDI5MCAwIFIgDS9SZXNvdXJjZXMgMTQxIDAgUiANL0NvbnRlbnRzIDE0MiAwIFIgDS9NZWRp
YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw
IA0+PiANZW5kb2JqDTE0MSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9GMTQgMjE3IDAgUiAvVFQyIDI5OCAwIFIgL1RUNCAzMDMgMCBSIC9UVDYgMzA2IDAgUiAv
VFQ4IDMwOCAwIFIgDS9UVDEwIDIxMSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzMTEgMCBS
ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTQyIDAgb2Jq
DTw8IC9MZW5ndGggMTM1NTQgPj4gDXN0cmVhbQ0KnmGboaZuFz27lahLlBNsxJJ5OpnkeR04vcQU
2nBeYOv7sTplPehylPzC6qdY3nP/gAklsYByLKKMvRqxNZLohhAuDuiTBii5+nmpczPsF1Bh8VU4
9bACNHjr+/2F7M0QRd9sywHCz2WYKh7JWg6w3NgPfdMKPvrt4KhJBaNAWOmxi/c7vhvuH7qhZJXs
eTGAeMYm4fBJ2T+SuvsB+TzzUY9BMxfP6hbeQXCx8OnK25X+i2mW8CHIz8cWTX5PqgXDU/CMgXd7
MgOb8A5uYqz0oUaH+1EkK74RddNCXqZPeZxS1yr1LfkLat+IlU2TOtD+nQQhNudWMQ/DyKu7QvQG
w1IouUPejiNGrMAKdcDv4r0TipIR5NxFbdvvBcxFub4p6xUI5S4SmC+PU2+RWMg6Q3yBH1MWtbrO
lImi6yct3wxK4TdcQlCYVd5qhMnq4Agjjj+GWXXEbFR8jQAgEbhfwEDyCwLjtpMElmQulP9tFqfL
bWh6gNdA0aSFt/3HumOujt31m7++4grlZQYJM3P1arTeFoGyB19DW7+ZSiquICIf+WAr91izQxi8
llVVpLrNQvCZipEFUBWwhfnPJ9M0ydoTJIczoVz+qOoVuELX/3a/3D9LG6mNVtDbkPuov+0Zxejl
8ppNvCkQlpuDFSgmpUhrl/aUcJNsAJ7N0ODZsK3L3eTy9CQfDVbcVmML1Suc8RBnqVM3I0o3zKqf
8e6vtu6aKYGnIMNH78pswIDcT2/mTaYx8gzWaLd3cmGbPMZvePrRC6p9EwY/x6P/l73dQNMzlJHG
iD4Ii5uWsR4nnjpAueOHIBxh71Dt1tXE8lcgySQpuz4MFC+J1mYZeTLX3HHGTe/3GKeWFsiwlbNZ
WPRHlo0M5WNIAmNPTa4QFDokJtIt1nOgXrhHQC0cp0/vqrLNNc07V9RwJKZFzbh01qReB3mxN3fB
UtVOf7GTj0ytgiOX7BHkmbwxpHQRs5LweWfZYKkEiYi38rfwtb/yA4/sAoHzbzNlZoir8QhsmMFJ
vD7v8JnZceyt7lmO7qQndodhEMdMhMeBGsEt6fTHPgbkv9jO+dLZWcYzWNWcBDTQ/IKKGV8Vjs1e
xy1JhdCxPufGRPJXGcbK9zU1jFznQk7KBEpf4mbVQhADwQQ1MXOPs24P3k7AeDT3UwC4HWOJDRRa
iu++hd1HsTjss9p4TdvVQiFsXEB+w+B2tNZkOPBoYZyVWRLkKHhebO195aqh0l6wU/c7OmqM76B5
I6u4q8wDmsG6hTl9M+fsZY9hKWmpXocM/4fio/18tPvebMXFg+CQSMh2yw5MQh86jCkR2Grcc5D8
+y4P689G50cUOc4QMYH+MC1Xnp74tQqcWTx+41Xlbvtora9XJqXqiuFtmrHvosEW4tFd8NCsZ5cf
I2eqb6pCq88qt3NJKn84+zLXX6XLRuuOpEQpAyMAlzF/HiLo0cKPifLNQ4bN5+MpFr8efBQ8eNCL
XDEY9JKT252HFJt6qt3QSsPVHLt2PrGToS/DGUgebyM5GkxcJ4zE1MC2/Kwwx+gjCbNBPqv26BG9
x2/UWnScSgTr9J7E4LEWYQMwrJH65I9ZNvWVgwSDs6MHLAnaclhnzilezDNQ9kQxBYnvnrK8alhw
/5Vfs7M3Hx2dmlAGeccZAjDbViWupTMoTMCJTG+DWwuvErwmqcJjZkhDG6jPECxZDLJ6fd9bo5AA
TYqVVZ+tyIbKrJUJf56Gu0SzLu+tSGpdYWQOtTMNoTILMWs5ylkQ/UGPI4rF+YQd6caHUrFoJXvJ
2l6vrgqj/piXEHG7paWQ3mAQxNsnFB4uFQ5ivJxJ6lE+z2wQul2zs4d5DgQIEAABOdI5ngmVe9iZ
WgoyPcdSuYVRyqwaVrZx7wecPSxJgsJ7eNwkdxKagxi2M5mTmz0pKJCnl2ivK2zWQWQN9eTwUFHa
T5st6smSzfEUCoE9Hb8f1VaqVWolOkn96eafGfSwlylMcOYn8R+oRp/Xqyh00eLot9Er2lfep1xP
hbtJAdGCj7S7OgerUp9PV+NOLoHayORE9ca0OOa3XXjLfjq8iCBgeto+qhMzOJyNezT26HfRT+yZ
zvIGQ2B8ch49r59AdQLHSAbGHUxxqagwpkQrpvFROg9vHs0I3L5a71pSkzo0xFQO2FCr77u0pamM
A2TPkbIyz10ehAZGB5GGr5MdcZicCu1J/gHNAn5hM8A8KKBsfYQTPtkHGT1Ik7BRupG9kP1IRjIY
CL6Pbti8WMGwDnMihRBzSqH9da0R6BhRKO0IP1akJx/gr26SnaJeAtTtMuAEeFR1ZO61xa2ER8q0
5SempYgghxO2yhsYzI04bxZcc/vEoJ7j6hBCMZfkngJt9ZQ7ENcLT86GKjzRy5QdMYg4y+JFR/wZ
FjoR+Xb7WTLsLKhWwoh700e4L/BwuEjfhX4BXjd/80TNtl/oz24SWQxz1dwpbqFohQzRTzf3kbmc
3BELXI6JfayzA3dS0c9JRNb41j9Ya71Yxydn0eN1vI3VYG7Du9iuinXE79Kgxa478P2VLJSuV7y+
lTW4+y02T6KmHNjAHLNPR4mpOIZeBaZ62bplZs0kXw4feZ/o7zP2+D22USNJFQeEgl8c6m30TEIs
QT195Jf9QHofnBKbr9o6ffuyY+kDmh3mSuGeTOKE5MQjMo+LbGQ+/AcdrPajFOBJK08+UepmmDtl
pNds4NNGurB42/Iv9SxPTzvGCu7ObLDESa7OcccTQGuzQt7k5ckgfGOr4J66mA9Coq7v2v+q2IWh
LughBGkk0BBoWe+/xlbCWkApELKQu1PIPQZtT4h+p4S3cpvlHLwXfqylgqe6WpG2sODCPG14Gg7N
hM+ifU832zpd6r37QnKNdL5/gSiNQvA5WTBAfVbz8UZUwMTQeY69d0xX/nIefOpKrUrBouijvriO
b/frqX+l5okqwtpXiYuHar2HL1x9EdB4S/ZZFkaKlFiz9oay9Zb2vb+mNnWXsNlPM2ul9yKIOeQa
JamEhdu/+RRwxwp0vqFlpOmGJ1mKNj919XEr27GHd6MqCpxf4PPhgbD8+KufOUvVW2ohRL6/3FaU
vKAsLDhCtQpvPdgaQjDVRzjRH+pWVI1Ujs0/eDfZ9hPK298Hvl1UKSIGNJwX6hj9gUNxRGpRSWgd
+SM9kd8UxReCSsEPE5WWWJw+X4VgQuSowBgA3uJ4WxZS/oVzKyZ0hIOrQ8KzlTo/Enk7U8+fmmAv
oiCWjg//w8Hp81th1Y+o92FGrUHlyq50TBVJ8HlXBi9+Voc0/+BZSpJkC+OmkTC5zH/quaXGA7df
MR9kZcb74nepm85XVa6JKHjKVSDl9DAdKxOShuirlyByOO0igVfxobSDAiZ6rlEj+YNBuwthkeEo
Az0SoT52i9J1YTKkU5pMILvOmK7kn9eueHSiqJhImw7bJj08VVBXPv35v11e2KZoGqreeeuNuAmG
ptvI/u+5VzgrskXNRo5dCIQ9+Bc5kUp4AK/5UBk+Y3qID7SmqCvPS8QvgobojUb4FeNPEoDp+nVF
WHp0Y4NUp/e9SjP7nOmVMkroCNIvdRg/dZr88ymkpPeqBQQUK1Dtvf1StC5S3D8ZPEDZU+fvm/PF
aydis6nG8eHDwBj8hz+B64ZGYxIw615q9+JnrO7KGmRLr9eSAfzX47ri6dj9XxNlQLof29YwYrfL
h0kPBQV9bL+vgQYT3p6NYsL8TN+U8Rx7QAn1LZ5iNjUtgErduv35aB5ctHVkpVpkxFgPmyE98R+N
VmHyYmJlQgmQqNC7R1HmLpulrucrI7vOAs477Kc4cZkywd9NfOz9qTYbptnAKHGA0K5Ive2/3Q/K
sZ5m5wUiHEElb/Fonbuxx5n81nZSMb6TaVwOd3A9rDmnS5WqF4aYqqGmrDW0YMpHfd/PLobR8zEe
H38x92Ql3abCElAvET5IogQ/IxPENxbaUZ/H/W7tPGY8iZaXyWQHGIs4Vjv4bz7xX+uAd4u5+PkQ
yg+Uu8XTWDI/qWjJRUEKrMpgBU6LPuJ09gD4dnUN7AW5xrv9CrThwLlAg1tHXZ5PhpoFLUqk1Vv1
k73/wr6jCyG369xyysWED7Od6x+2hV85anbw2/uhTblVEbCnVW1iIrfW+Dixec1x2ipY4mwe7wN+
7DRn0XYU3zGy7foDS5AwO4OKzh5QolqLTUuo7pOWJS953QJ2mM4Ii/NqBgeQqmi0V8yFZda9H0V2
6k015YND/Xg//oWm5IgBJiI/A9rv8ZMD/swdhKptUzsQE4JqaaVCRZoWpXiMQR108PcP4Bp/64p/
DhtPwgQaqarEg/tYMR0LS9zvFUZwgB40blZ4wiRDO2XT8IIv8QlqviVf+owEx9U6O57pk+E0grqh
wkroyAssiksVe9ghu81rPhPopaeP+99fcyVpYOH9UpH8CJW6kp9zVkXx9jOPpY+PEq84aufcMKES
5Mo8H4RXtWqbultfB4qrz7jAzGZQN3jytb3O6rACRwRLh3bbZAMR2d29zdPzcgfpqTuMleIv8SrN
5n/EJjZ6QlEzE56+RA2WTokkLoMHW820UwJG4DkW9QpxK5Uq1Gj8SX26wwt1fpsz2o9gh20IY0RN
iixlR9S+G5XfK2LKlQkIw5DWNmAMU7ysbRHSAtxsTtz59Uc8F/WkPqKJnXa0OqOVEuCOjTbDzwAK
eMCWEd2PfMK18GWvgy5IuCzoYPOFiODLnpeNRodacY1g5LeobABugmEtPnxfPED1zZ1qDaq7Bt8O
N3qlO6KfulJUCT/UvQnhpG6mokImoQR3Vf66ATKhYUq6fD1Hyn9D4Z6OHyxVvJeVDpbdwjmAFXSt
eCm9wcHeTHd7kyVjToY4bvNRz6+YGUOF7vfMkZJzMDsWRnExE++NeqcQFqAVewZTXCwCtBTJ6Kbu
Eta3Smi+QBepiMGsH9DYmUenxQArP5R0lrjChYv+KTpbQ2q+aO35WIPZDfSd3qlcZIz5eWDioDkq
ygE2AXh+nPtaTC5sQemKm3Y2cYZ0EWTfxIJWK1UqGlIBOZwFV+OTQaLCLHlSu+JIJ1JnwKNco8CV
ePcVGDRkva0znnWHDbhmTc5QIfNLuxFN7x1QDrALLw4jJUtBLlk+tF+csn3l5wxtAQwrCpbb38zN
zkRBjTrO/1UNbWMiOYjyeYTz3VLiv3Ul2wi3THjE7zKxa30Lxkw8JlSHWhqPYTIBFU5ZRBD1MuYr
ToLGXX1PkSFzd9qqSsALVnF0kOt1iyoVg7h9U5+LGVXIi2p9P9R/cB50HX8k47/5iEKo9RKafMc4
tKMs7Enqv2wEgND58V6EXUhnzwXU7YX9fw79p+GAWaTvjI7wppfoY7vOJvN9F7Mz/psg8uhR8YHE
rd2yHohWdol3fdjQh4gXQQgyoaqeZmQzCdR8VvxGbCrxgFEYvKA33vXKfr0U/JvdUNu5U+weKX00
T76x+WnLsrTZFb0kHflP4m/xFwuB2+pKGWnavT9NA8E4CTb58NfY8WN/+jdX/GpTs7+KjPGj7wyP
OMzWHiypsP2mH5ekyq/Ierw5foVY8WRyiO6J9uODH28DWv4QLN0naHefIqa3N0Dv7eSGTbOGx05x
9st6yRJdwgiC0M0gw1Xh470q2fniqSeBa/1megGfhVDK6afeAqh4AK844KgsTVjJXUj55XrEvIiO
uvZM/FrrzjzVjIse57BjN6d5AW2Yg5qi8Kf8VHzQDKOR88IAQe5OD9JLCnwTBw1g4b5vxxY7fg+s
ODvSWC5a366BDRUV14WFcrbMtP0PJGtbs/Lv6PrDDpmTSoIoE7sFY+CRzAKGlde8dPdnDCk355y0
+TQ5jIoJRk9Qswv3GJBSovZfDE1o0zDVRTacyJ0469TO/17NJQ2JZ9LVOkvL+4WEL6GqqMHvxRC/
75qskppZEA78keYpv8LvR5qhjku20Nu87T3u/Ve5c9nRAGZ4PJPlHDUwglLaXOD1VZBJQqrwMOM+
XzXKJ7WtPIsI0KOp5UP96abDrKGnHIMmTQzKfGEmXs2yPDBqBtABNbV+H4XZvSBPpwLeYRLWZeX8
w8CcXDszlpFZZKDmMQeShJHXelWiLM2VOCPD3MvIfHr3i3uucXEcePFOEqSIGh7T+Qf649voRTsG
5wZThcBujzQiaYuuERbp0hUF+2gUeC0sCd/0aLOOdgR6YCPzhV6zFR+BuU8rCkPFmrFBV676h67I
WDVJd3+XlOt6th5vrVFGF24jUwvBeRrVjQ3x6s47AgTiQNesB2ZUbe5mCwRucziw5Ey0215kLu6Z
dhmkT2Af3G53DBgE1FpXKyYiHVOBj9UEjjtES15O/H92gNve1XtPI7xqCkCRAIk/tnUczbw0BX30
KHje6hp08M0sjGEIR1Kwear+qXekKeyxAEtPDlHvTULd/+IlJCf1XQMmq3whExfx87FDZ4OSC8bk
dvsK1KfYFAjyILYAwtXuxQIwkftN5TckolcUXc7JcaYfH+BPuFTt5Mrm4cRYkhqDUxV/TN7adYLm
SfSORWEa87hWX9LMJ3okJKwIsez42COETSWhcpoSg81Mgm1PY2Uy7PUE5iD9ZiEyY3YXN3GZwyGF
qtC7M7zg/EZ/xBa9VQm3HnGv1Y02dXURIQS24y8NUnSjk9AT3OLMjDsslfqw4GWeib3M3wZqX+DA
ol+Dbujej1gPz6z+Psj/ozL2hrUxvta/O/AfLhTgQvpEUkG8pHDNiafUXSB0wQM8+wAk4vMh8DZG
PYiD1hfu8v6oUjYnpCA/ubKteIwOYEzCzeKmreYDn/w6HW+ELef879vTMjMdVZG3qqh4hNgyfH4U
kehmxWIM4p3Xw78+JlES8BROPV9qixlVOEXaVAtctD7ikP3dghOztHl0EWyr6IJ3eVwqkzDSd44V
pMqc3qCHDAmS8034+knTzNYCXC3+QGShYP2uhZAo7e5xSkC56p5iWPJFqxWmuqtAOGKhksEKg4yL
S3PalbouXCAM5W7J8+8DbZh+OCl3OOy2tJntfGNyfsK+nW8w/tiFDIvctjyaSSxbxvi6rt872ELF
y/qD+LiD2ELsE/mkKqj0R0mJx8EQ6vF0uPajJ5jtlGxCwUbu4T1Ky9Yy4uGNmuzIzKJcL/ubyScr
cfFajmuyGwp31rgVjTdmcXvEoMeeDVxZNmRMAmx4J17X+1CI3OZky9m5eHHUaOr5qy13IeYpu2Bd
TegD62B2J1nTh4Y5JOYKy6+CCUFHDwRmdzi5b1gA1O1xzxWINGd3nwn9lCD3hSiIEQSOgpyWKGPy
bKyNn/zPosfrgnLofMiSsag/Ve4Z7X8SqR71raNEB6s9tSIBjTAmLQNiwSgkduGkEa/6N7gWFBb0
16c0q/3AS7dCe3xHIdqlc5PkyUX6H5DTOg6ZJumkRcKKx7qIKkUHoV2nPWxg0qGgYQvdOwBAK6l2
9+ma3Offc8rsXSq07Dq1wLS19lR1xVUJRL5ERSlUwT4wIzaOXu4h5IU7zQDCIAKiL8iNYd6jCrTW
WnaYineB2rUWQUnb9U7UY2hRmOwMCR4saBhoBV2VV+D3zw+CYNHHNT1EpllA5UsSRAzyvTH4fyQ7
cXHO/7ggxnLCh6ZKsYU1ZHqgW+6MwqqAnVNF+ikU+ND7QUeKT6SBt1/SMmsNfRb7oW1z5D391Z7q
yGCgiZYgctdCpdra11UtPMRqCZiudIsQxFho1cerYpMeovkqI0XRInhFobUWlurz6rVyd+n+YNRF
mMfpDPQH6Uwb5vA6SHL58RU3j144wezZHEXH/PQANbgqNPk8zwwHW7KnJHwP86YGw2VMNCjMq4xR
7uhUtOqPa88jtOsUsNSDtHfhLH6/HBzl42+x0H1o+mCZlQIIEbQaW9BvCGhiPL5uXdWWcncmruKB
3xtNHXdNANWjscUmUyFNfiwbdmKoAqFCPYDvEoL8o1vEaybrKfvbzUP3G843HoUbycdeBPCjuaMe
NxgROexktMLfi5ywPAm6iajP+k8jfLQZ+eTAzBb92T4hR3/9ulSuw8hXplGJeRdMm51JW4x+3nK6
HhDmYv9e5DOTYKbUgRDRkORu3GX/Y65W11h/6WB34OHx1nEPTPykj16sNVyW20S30MTNnk1H+ybp
NlFUnh+0KZ45M1uHG3R2fmSFo/kMLEgF88RIKbxnRv7p7RzMxgZZvigmNJ6zhY+IB240XlvUTEUT
ewgNn5Gy24r1ueRqHaq+ezHG8lDwFrofN5t70rlOuK/5xtjRDZ3AiRdToCO5WVJYuoOe2xYWk59V
+a7wKBsU/5PuGsEWG2RwIiD6ckBWF4qJU8ZWg5WLu8iPQlc5Yl/0M/1mpAoJa/nIoIDR0AmvqqOX
Uj0sjvgtCYWjL30NqgCVUterFM3OjlxKCTlpcvAhAZ3MMXYVKzOhqvOyZEsiIN0RUKclbBhg7SxA
aKhEw2gi8FyZ+2g3nERV/IUNFAUEvlZemb7l977MmgHOrTipBvIGi8obVoGyS9ZY52XumMO51neV
H05wcEZRbosVSS7Pexbe9DosZYQPKvHD10i+gdXK/hpVd1ewRQ6HfdLD+/LUyFdnhTFzYIlRP3NI
pTl/hg5eWWOFazBsByOA3UbeEG0br3IcPL5GTJa517Br1VrCrX6bVTErC4i9/DWnFsrOSC7gT+P4
z1tBMoBAdydw6hRMcBP1KBprFIrfw1wqktTYmuIF3Lmjxpf0PyS0W55Upmj4j5Q0nJSrtU1oAARA
kkgkwTtLbcQYjSyFRY/G1lLvhgFfIg5aQ6cNgo2obhzzWFWMPUXkx55QbS1AQN3P0SODeiTSxF3x
QE7bYbQGwp6Bz92/wFf9YuMX/pTAgYr1iNNy4N+xdb3kFbSJ7+RflHntPVdGPMer2FUjLev9G1i0
1+pOSRANfGux5KvML/L1BYqzPVU60SDBEN2X1kfZ3lm9uqxEFoJA1XfzBprTJct5+M2+pwAScmXa
M5aJuRK/RMIwjuhZYukv1YTddGaNvVMYqaoXK3cNxdbAOBQsEAYSOFZuMTz0qjWaELJKfNj3s8Qj
v+pJM3LEKHD/wtPAGGZM7pLCKzzU2wxbQRzF3BYga0Nfi6IkO2FlWgywnWbozUBXaAKsFi7PYMBK
u0YKxPlG1HDgr6viUgnZObLtY9VZZo2IISSLpP8lOTx5nXjQizfLdYgfMwL/M7HDfS6iQqw2XE5o
0VpnXJuNJt0v4NLr3aQqmEtUDTwrAqkq5ftm0jUE3dLkdo6JRc1JtokKElkU5rm1r7z/5LJyqaf6
ShzRlLZDP7/Z/oBJ3n2gxHfwDeDFt1M6OXnPeOEYl9wZNUPsIxjDpbNVoRTs7jCa+t9NmRMDT737
uAIM6EKBH7ZE7VtsE7Zvv9hdVyj37IqPMH5H881pmBBK2FL919hoV8VPGBwu/TmgpeJZq4z99Nus
qcpxim6YrfZAgU85wRA3gDAhwHnv2+wUmSlckFh3D6l6aou1yd498kmprR9+v73OjF5z7Davd26s
2MtapqmNe533ySnWvCtCbXCMYjG5jknkXaW3TZDnw3x3KVULN9oncTnYK1wTTNybj79/anYDwUSS
a1qZOey1Tm+AvU6oJSRISJpLIL6ehaM2X/3Pb5zY6iDddTvHtkLv7k3e3/16/sGsuItoTatPkWDb
RV2OKzCq03zdIIewDVWxmF8ODvxVM6NoCWhE1z373i0HzN+bFPIHgLpUzPVW8euCl1UALEXw1PMz
RmmKkUCI8REclN8VlnjwJSqvPui17THi0cVcMmc5OqtcLoBOmQziQw+U1hMdSNJSJa1HQtztER5r
p6pe9WOpvElSSVxjFcNAcQyJp3vUPtpLteDJV0bxhmBUFMSmFNg67AlwvhJxgCY5st9aWg8aqR3x
lr/jAO4mXz3zhYe1ySvq670TBTTKUEjuKZwPC4Ye9z3BEnJ6+rlEszc4No6XlwPVOmy8LB903sBQ
yjZmMEtV+fDKC78h8HrNUKijJTTifPpjXZI6trCDza6lN2oGnmZZiKFmty1sSmzyjxSQ7DBJnXsk
kS7UHHOQSkqdlnXGQubOuu8um5JQLP4cnBJi+u2BhY9NlQ9akoVTOnvedDmBO2A0F5W7dHW3Hi/M
s14ygwZw2cSiCcLRZxqafCZHHY4hbkfAjrLF68MlbPRHoV/8M7RaAolfMAd48CT5MtIkgW5S8c1x
jhhPc+VJPE0RJwS51GX3UNLfgkBTtTkAIM8Xljy34MyYtNtkXPS66dwDg5rG0qrATRfBDBjstNy3
oqFhb9HnLgZwhCGKhklNgzPBaPhGe3OOLBnU2n4rvhFQ7xvLwXK9b/jloNFyXHB8YHbMe3RXa9Rb
5tLILDF5nxK1S77Y7G+mqqdRjAF2nElpKVDGh/Cwau/K3HgcGDYGdlNUOcreSibDY3tTb1PAxm8U
e1j7k0PyWctBh59KX8Mr81QsHNeD74mxuiDUortgx8Kv5UAgXdj/G4FPcNLSrRpzdjjAfYs9dINd
pqTuPWTFrrwFm/hIR5z61P1VKHtRHEC9QXGw4dAMg1ExZiHIuTe1HC/utEbswYEaOaDxWSvU1MCf
iuJNdtiChVfkftapPo3E1fu4JKUCHkCUMtATqFkrQSw1yupaGBaaFf9gM34E82+054E7ldxAGBUc
BgNiCpw+6QTzq+8M2fbfl90HsaBIBHqqQqIioDrxwp2O6bMRj78NMDTWqXE/vl3Z8STANaFj3i/1
ENlfBGNaC4JUyApcVcHoU0cZP8aIm8k9PC7okrAC3V2k9VsH3DmKZ6y8ODdisa8YPFC6e5QKL0Ko
AbLUlTV+uELewdyNDyYP9sC/kLYxx7OK4dkLR9K32vI1vhzAErPH8c4a8e+cIk0Fhw7xYy21J+m7
j1juvmdT7SFtUkPdF4SockyI/hYnys7Fn0QEy8+3BfdwoC6pjfLy5dRkO8m3i+lAWNXBLMCJv6bB
a9SSEWWeNdjObZ0FELTfTiBULzg7xayabT7QN/bR5OvFp63CqCwdUL5mA2Svo/Q/th4+WlEkBL3T
l4msO6fzrofScxC/QWo5iYkR1CYvLiRfYIsd8aUyD69IeNu1IFOUGMqaPnNAhrLfk0x0jnHfWIs4
08gHVFOwE6PzHFljQPC4H7Ujp3Mbjuq0NMhsh6y3xwymvutYyEHELgnFr2mU4TwzU5PhaJ1oVEPQ
pl74pL/HSRBI0bTjZT4PcykECpIh2tCtudH94zLy+D8HR5W0PfAsc44+LQyw8BnPgUjie0TJTebq
oxZVwKsJxl8eTQVCcOnQdPUEwLauJkS+Nhu2s3X7a8aaPfTbJcG296+wSgj1jv5BNX2e+1sJ4oKx
cwKT8CG4NgnpL7p1UFLfzCwz7HL3OATD2ggp49MSZz61JN6vkEbJgx7Sd0tBx0KWdF7aWAM4FuIh
D/6GSVTP065ZIMoUT7cvFbA7mE0F9zKa7U9PpKiS34JhWbsjSjLc7JUCV2+9J79tNk0zzHDAvdIL
fZNbuaviaxNJg/Hudrrt5UISGwzm6Enmo9pznQy+RZjCCopyYmRT3P2UsEVScBoVWIdFDGnXvSep
QOdTI9AJwRm4y6puHW2uyNRH0v3RU/ksHI3uJ2Fnixzv8pB337uQEHJM8uYFxZMBnmo5P95ieRW7
EqWku3HXceWZaJdzNntbozp+lprUFgn6n3ErkrLJdsHmZhbNB2zi8xOeJvU7sk03ac1EeeGjZ1r6
UCkf1D+m708Ay2dQ4YmAyJYL5UWbdbM5bRXDeOFwGbM0fV/1kZcOzgCF7XyQdP2Iu9uY3tDzhTUW
sZ8HVIRKyHk6tmgbJMcbbgD2CYbn7dgKFHh4aOHqZPCyLJhdnhT7RrziNUHijIdrwZt+dv5tAh4L
rjAvZJpPJvBD6kfH57r0umNFXcdeOeOx3gm9sJK7mZ8HUXxKrUaej3rhfrMkdvV+HRtl0iHHBwsL
C/0oFVj4riliR/ComtevH2Yx6dUmVTWOIVhUYkon/LDRSycKTqZHSJQ5lQrDJLqZh1XEAQP0Po8n
Rplwdt+qcN68d1H1IqeDCsBEx2mW7FgDv6FUoJfGYZVY1edvvOl+ov/TQO6xGZK5LJ8zYi7nlMvc
vxkoDC1J3sMrawWclHcBfYPU2ubLWpetFvmaglmY1dZNcyEF7fElDzie94ir1pSschaOEMIMAT2v
hGgOzwGab+U79VxA0D2RwOAt61UWtgOYmeHaT0avDRcer2UQikv9MQGKjgt8fak/fckKW1V2ArQ/
bDhVhn5feF0tYjs1J9quIHwIcLv9DqyUyj8yJ4WjGfyJahDUGyQ5kkJ8o84pLHIjUj+q3XaZaeME
7FaIXljPtbtucE+KuIboyPc97VuHbQixcgphSbaP8wgrjsKjDDy9w1AgJ6djkFM5kCVH9sfeAewW
0VUzQtwW8ytEhFs/+W6FtEt8g8On4QITnR5Qh4bACFPFT1KnwBpwNKvbUUNhZL+KhkGj3JGJQPuB
ZwkqQW67DUuff1aDNPv72xF9gmFd2arwQDu1WF7J222ETSKud/+EeoMIC6enrJQP8bE/9ZlLGsUe
7A8jMS5Kfc92o/oDMwJtVjP2ZlKD+oPNsJ06OEFb5Fk8bx17hp8MyhyvKkPeZATPCa61A0V2vWpo
ivCwvxPRufva7cwUFH0OmRhwIO9Fh5uwxnx3b5GPtGVGvxWtyJqBrBaZXe6/++jdFAV/obmx2MAt
IJ4Ys6EtS+kB24JQs+KfDuMRFuM31HFv+W8aKb+wuhrY4vNYslBI9GZKHWoznPj77tMA/vGKzMav
9MupRAWtPSE5ffILmTrR7jJY0gm2sVLdAlovACRcadkkTBLJXUFHk4gnPVJ6IuvDVUn/8nIPd+pn
48yw8DdFiXuY7jBtLGlYVscq0VRN48bKEDB8l8VLF4xgszWg5X9xJa12/EO7dMTrN2nGhyuGLP+K
1sY2bLL7BPS/balgwPhytxy6t//+yeOXBPTdZFSiPFIFaAayP+r6g7roFNaNIHw+VPFPn25V6v1H
jFN1gvCRosGxvI/5wxT5GhWWqZYr5DFrX0OSLiGLtfOhXQP2r9jQAbxkdv3XQctPevhFldlD+u2y
Ij4RdFELWNMEDx9aw7+NrY/cLXh9Abor85uSBZrfyEd1PaOtftyhMK2nMtRkim6oovTzwD6RU/E6
wJISQPVzlrTVPBwe9PBGYaiAgV9IROMpSboQaWqO2/29Ri5jqvPctaParja1k63fiBT6P/IIJQPP
yDblRNn4FblDZwarAfZ4wP5jcHQpiTjFNoMGMGVS2jENrDyVJ0/YmTMl8zYqqCmPUxdxy+26dVKP
81hBcWHN4qPaxbIL0z6mDYZwcW7AbVCFKPSfyfBFDj03zj+mFJ0dOvtC9/4v/vNA1Dz5zaAj5Mtu
vqt2ByPcmCJsioRhCiravbOliMscvWfz9tErRE3ZX6Fw+SdaZC/bCoFBuzB/p2/gAJizVn0dS9TJ
EquLAtVbvM3+KRfmRSnC1yVQ396fF/qbdmTUCq9Sz1D54/1HShJJTJfSE0phhbatKti8VwkDs06T
onOV0wcDkRv9mA6pNwSnvgMgsLFlThhNkVAmJzsIyx9tlMPD7gCw18aOvbNmforStcXUoiCCYg36
+kJbzzt9bbsi4bkRXioLvMCb71U4ZRuwphE5YBcAVSlVhMMAc1xEH3VyGHN53yuZOSbPTWWNv1BB
2W52TurikC+exCnxY1WErf93sP6RGtM4OCj28CzDzGGMN4mtj6HEZfwkofIv9C1vSkzht4jYxrf6
+j4M2ZZ4NubRRh5nqNrRh7ggEymBW93LqRmwaucIR2MKGFpax3mmODc1R6J9V9V8KT0i8Z0FFV7s
ytdMToDlKCU7Hg0q+zunC3R4J6Xeaz0/Mj78gl/RkDdF6xnb4L21QhLhmbYMoMGVeJaoHGBNPfoZ
7rktVi4QcQrogiUJcLY8sQnNxrHhMSn4pJzp1QwlKmcOAer7LR3NVp2nTM2fW/bbQvde/rQOdiyp
5bKmWtTF0r+o5Q94Q2X0UscOOtafJJ8LJ6YnLUXZbixZrtLhjCtkZZamflDaw6EcIj2vh4XlExxs
MFuUBIKDa09K7iexfZTq6p02696iIAsJKvGVmGLhLbI97rnYts87aQLipLsjbagefXI9adrNNN30
paoe1KUsxx+yYag/X5/gnjzaJ8KRl3pQWzJQvjRYQilBrKKWMIDd11MvDnShxeJvf2xbcQDd2zU5
ooIz8csVtp+qFyUwKiMQI9bvXCtzD03EBsDnzv8hb1wDpQiUGNY3F9EhgdN0N4JGDwxkzhxq0Aal
OoiZCU5rTDQqw8DAdCI66u2oGSWe6IjYu8hjze25k0dRN3xbIMVP23RkV94eUoHNaqlwfYZwr2+i
f+zIZj3sWeRQ6aa9PEG4NoUVBwWNs3NBL3/7p7ocpLzz7viJT5SbHFWifL3wwWuVmr4Mpy9k9RWv
XCcYvVCKAct8TZtatuMW7NqBoN5VAQkuyMrXIHMf8unoJCO47+M6oNg9Lm8g5gkCR7FKr4RUNSGZ
WmMMyeQBfecwZl/ovdld0JjzqoV0/zHNBfrU+PuMC01NGxRW2W/Z9Vw4fTn3GppMaoL0ONqsYOQO
BXVy2L8v5XJvdt9MmkQqpnJRV404lG4BUgSZb6O8aYsFYD0GdjLEcCgyzBIXDvlIxXLErsO6Cal3
fzyO7ah8Mlc22WDLfzHqifR7act36eiYbcbxuRpIjUKPk9L4GY//btb14CSxhlm7G7XGWaT3pQVa
P8U6mMf8HdxxW3WFzZZTdPKNvVjr4FqCfHyHexFs76u2kGduNyrTNX+Qft4NmN3ZQgWXk5pxbXfG
fMIg5YZCz5+5zdTO4DDbjZP4Dv7qvFVOZlPlpEQIdBIW05mu9LUrg7weueoI5eKlNRlLyBoiEhZo
l7UyoTcdmtk9GjDXlS17SHog5YIbq4O3CB0spXBttOWbLF79IrekC3SJqglz5JbF1RKHktjHjPbW
QnCvOxbDcz1MG9f8sLqkfotf9DZXOv/X/EEcGxdOMnEWYL/4sMAR54Z4QAkIs7UJjfqMxGHF0S0a
7KBHWK0rddMrUmRxiDXc9m9BQkWUhwtmzb6ZqqqwFITIvzpMaa/Av2v6OAVKb6s7J6rjfoAzHQ9Q
uvgTfX0DZXw5tmYgNw22E++eJVGPT9QNIegHcwkqrUw3EVDMJ+91mfF//TiZdUr9xLELi/39U8Pn
12f3xFeUxD1pc8LkNa2Q/41vuAOdmvWOgw2bSD4DIhQH7xhlNrUkmHxrwgzxQdiZJ5Xk4v3T2ycG
nJUW31eUvi1oZW3hTno2aMYKI3qJ7JZLFq/mLhyBjJzkg8McTbFLAqY1cfEiAoNyX3NlHgjk1NO1
x4iEanqLusWvALAzIaCyAYt1UDO6UPfduSvzXqNKSEUAqk/mNUrISptzAEqlp9DDN4Q7Hp/KWila
EICcTHZsrMlBTwuPXoGEPiX42prcx/2x6xawZQssGA7HxzqsBgE+wxtRYDeqbkiHbr/mxvt55kOS
07/IGvt3dPbpPk0FFq7EOGvgD1fjcqfC4ZfuaJhBdyX/HVT0qKx4G2gGfONGBpo+nKXhi5Fj/ULC
kdKDawLOGzZNSwIuIofIgUi9psHfY0qccu2gGPBIphlxgaQgFL3dDO3LMBfOx6QwVjBUDpUbJQwE
PTARW5weiE9ho80dX1Dc6Z6z8n/6ItZT4uD9TzFn5NyXNSO81djN1pFL3aa8YKDmxnn+9G3Lt0mb
/LW3NcuVDww4XHTie+UQv12LkX9X3UYQrTokdh+ALYUjt8zgOUC0wyZjl81fDyiZAm5CoeACe39X
swQieJryMDRYAuS+rblEnGoADxdmSyadUq6+CpNHCpN/gpPpC+s+RwtIAhUA/Pwtzrfdc98NaDgv
QCl+zc8q/5GFSQ9OLUv3/WrTRGmMYzFH8hsSYhEeC+Zv03UKZIoBgqpB3INwVOL0V5OQR7AB33zS
ctRO9TX9/FWcVdD85ZkDAwvGaLJTWIG5JKBFaE/drW+LS/n0+Dx7An8ZKFOaEteBkbIHG/vy24NP
NjnXFxhVwanzlpSyrGqHlYawUegTDJ5H4U8t0gPkafFN2Mz0cNDeqex2vVTdDNYVFOD2soK2GUDx
4ln4r+DMb+4Rqeq33GxCBqldAhoDaUfsRbn95/LUSk7nGkwetPB6XhRdiSdYHZpL4BwyBL6+dbv9
kiIel2ULd8RBB1PMioLY/OUemS0E95YyPkc9Jv+mv895/VmZtKEfNew3vpV/Zqoa6/ncnoe34gpV
CwExD57vmw3E1S9mhcyNFkyUyg3seKTuHjwagfGWY9HcH5dNwEdDaOQ6yme6efVrG95w50stTQa/
/Z6bMiVZsyrhAx5uUL/W4LSUBa+FqDHt3ONzn/gyrFlil4/bsPGtqI14NsMA6SWgKfaVpeM8QHGe
hOIWVCyk2PK6K66cDnT6SIVsjEMlx+HkYPjh3aE+2f8wg9wfKY/WZahSQoZiC6oX29FM1zUHK1qm
EGH3AJ+q1mO7udBHki9dherRWWnvTPHhiEdfUx4nnHYsSel1ucPEkvItZFnuZ5BTW4aoAeJFpepU
q7YqGY2eeyeXzlnQ/KAn0wSfE62hPc6tRe6zRkSWlMxGCYZoREAsU0JxBRYAcWmCopjiBcXLxpNP
45MymuX7qNn+sBN2Ag/NkqlWplCLFS2WDF5ci1bLgE/kd8w6EEQcrtTStuUEYDzj5cgCQ3nY2i69
GHtRsC6FegfFwdqPSaN1JRRD++rF6JL9M53MPyVKQIdtemROmTn8sNa8JJHDCKz4m/XHBJKnu7DJ
gadNburo/mw253KD1Y8EsbDQW99xHI0Nd+vCbCkqTOzdodrG1UEA67LzR3dwxzqC1+Ncg6MQw8ec
dEPefpFDjA+fRWladJD4qyIz25rz9UawpjCjgnHUoBqguLVinL6SQI/6lC8AoR+7kczyFBXYu8yO
sHm98HlZtjvGBizEhOmaczH8dXffhh2FW5q5UWzr4pp7mBGxdisCB5qDGM20bi/cskCzd1IGlMGU
xmpN8e7oyistC0yRFmctKfWGnMDifEvakzjMjEUYhOBpYZqVCzGYsXlzIa+QEbToC8LfXUjx9FF0
0WNy82L9jZEOWDyg+ReSYFVhmxVO/VOBkERskOYi5ZKs1BpRK0n8KkZBDrCQWPgS+r8NJaPo3MoF
4XVBzPQ+sZHRZaHpNz7YJf4MWi2PiPnvOTADdD5soWBk1RAKLxbHqmiARE6W8U4n7NB/S1cn3lNW
DwPE7jDk2D+8PPD+M0IYmn45CXcLcUWlX7OGMyjzymVJ3RMQN5Q+IXVc3cALBrcrMMokx+5McCp7
HPZQ+e9861MhIGuZTvsHyEBbQ57WXAp9NuWCD1TzaPSHSMlFtBpTjmDkI4XHVdCpOpq1QB4frTi+
Kjdo+0oofj9Q4ljxIdyommHiE4x/Alw0hcLSakx7XUFhF4F2RfZ5k6qmeIugaDyr8XHmwQdBg1CY
mMlX9cLZl7TZ7FqQ1gt+EtfXrGBcWgMF2NoshmpCt3UPhlqGFLoaW0H0RnUmIDp3ZT0ZnmbwB04I
22sHKACA61qrUFv/D3fqzajsngmhRIlXndkM3uDY+hKJOpOLFXRzb7qLGyjMzyGhUwKkkAwDxq79
8EgXk2mEirkfTRH56n9lA+9qP95l9tUOrYkaIeOp4F+NC/M/kviqujdp10rVKu89Wk7O7Pv2gJNR
Wv1y6uHucBMB0TXjSHVlGqyo2ZXMuAzZzKKLnAm5JTUdZyMTPSqruWIU5Um5/4fHp606XqOZAl0g
Wy7Gv7mBBLuymSlA5BqfFzDhwB/Wb2YzyuwCHkC9XZs2yBDi0HExhhBZi38Q6UDFKwdWaV42U8WH
1FZZOg8lP3D29Y8wauORX4r/L5ijeSgbfYOuxgxdxFoNcH9siEqkE+I/smig4ZVX3lw3O3Mp/28i
ubHrFtK5QgKamvGtfnfxDakG0XIjKR3ebdpM8iSkFIstQcXNxQKertdEkymEyvXzVQ6SGcMJQzKa
RJ0zTktkiVxR3FgdXpgNkVN0VrS6xMx0kc5Tg0exBpAbVphIEmzEYxtm5/oByWm+IDOGHFzaze1u
vkjzMTk3iJUwvgp28NAH6Mt+DWVuZHN0cmVhbQ1lbmRvYmoNMTQzIDAgb2JqDTw8IA0vVHlwZSAv
UGFnZSANL1BhcmVudCAyOTAgMCBSIA0vUmVzb3VyY2VzIDE0NCAwIFIgDS9Db250ZW50cyAxNDUg
MCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0g
DS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNDQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4
dCBdIA0vRm9udCA8PCAvVFQyIDI5OCAwIFIgL1RUNCAzMDMgMCBSIC9UVDYgMzA2IDAgUiAvVFQ4
IDMwOCAwIFIgL1RUMTAgMjExIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4g
DS9Db2xvclNwYWNlIDw8IC9DczUgMzAwIDAgUiA+PiANPj4gDWVuZG9iag0xNDUgMCBvYmoNPDwg
L0xlbmd0aCA3MTgwID4+IA1zdHJlYW0NCqxmDcV4hvuFttQQ5GSNqKc/mt7rjBWn6e+G97e+mDpM
LJuunxLzQuizfbX5U7mqr4VgnJQ3OUL4gYDQmjlfUdBzCdW167LM9a8o17dHlOvvkZ7yKux1GJZT
80m8h3ElSNY8bvru45xRz4rv9jPztH5a1g40yRvT9bGaQVjwF4aDA3QWFyGuSMbS+ILrOIjGajve
grmxClDXLA2A3AmMvYVfWfFmMsQvA4IIia29DDCT4sIU0llezFq1FPOdXy2DnkjFo7WfLswbx6NI
B1BJVU7PlLorSKwA2t0deyT+Tpaw2TfgxeKjy1VQZ77Hziex/B8BTKA36rBEGiBDn3QX3EAyh2jQ
3qiUbUveojbhf2mk7fmWFnmvcSRRIftbJZoRzZn9HjtiEihB/fgBbo6c/xdihNxyPNxt2RkuWTEv
kZC1FJCa9+mXWZHqKSq4XfNT5y+mIIseMjhYxj1SP5dhYAXjKNsjYzNtN3A1C7dbVIWU001g9iDu
VGbM21IADmtFsx9S5bpo7XlJfQpiRcRtC6JIrh4kLX8fhorg83B4NbmZVWfIdFnPI4zIk6xR6yoX
C/y669kN4SIyMK64uVaqDVmbl39QWyW95CXszut4ejt9LFE1L3PSb9RKkjPMJIdpZwpr0VYblCOK
i9Xvh6xUq01JpHUi9dMextew7SCkNfIGDnSYndgj/rkMEL3th93v3U+Yoh8E+8GDfgORvPnSrWoC
M8Fjz82a/KnQPaygmFsW0iFVzzo+vlKC8k4Bdn/H2LUNBzMlcbuChKpuOacgk4ReMTAvbybMhxsO
ZUxmAjVJ1OE31Mnp/pXs4gfL15YtB0bD9Olbvi1Se0eXmw/ZQeycyi1MxoZn/jB75vJHlVIsKTQ9
6OnmWu8ZSKdOihnxSY/nd9ylYJbbEHFU1BvRfkdLhPxfkXYlwk/DjiKBsUd02Vjv7vIQpI6afCm+
i277l20SC0EOUZvCy690jMZieFLOEvdw1/3rp6KJ7G+esOSGbM5NlkDyvK1selqx+clLlVghJ5g+
d7BWXO6zf6+mFe+04AIlDkptYcZRgl+uVPsuJfZSxiNhcPjVRjxxucFunMaKcu+hgueUsPHMNoxt
5J6PARLb77vVXaXoSCCuPsneM4Z7eF+fFVIFXCP8rC7UwH5RSecYhrdrraeQ5Z461flZnTNtMXcQ
o139ohLJHnP6drrMEMchmw/BPpsZS2+xuZlmuEEQ5Li/lP+WCG7TiOU+ybzr6vLqyIh2arFCwjN9
Gtc+zTEiSdkTC1CduUUHNwLnkwD0Prw8iTzWfAuVX8hUlPTkt6XiwWxtzhqwqeluLW/GZxdd1ACG
ih7WMIUtmYyeMwoVpo18j0FtCBYCKsmFghtgr4jWQGsix/YKeODgLAq71/p4A9gTS/c3BcKSPS6+
91rWwTMkM0Atqp5dIZ8yx6xmJYT0URbVD8LdaNZkZzUmuA4B1xAd+SSo/MAExI1Xv9Q3lRg+Epyl
yvecmLneodpGg+4Ig61ViBo0vBhUJi+9XIkK7dg2Wf4OdcsK4kL8iQAXy8ZLZVsUmI75QCtAt8K+
fj2fLLtJKcIOeYqqxDc0eg124aeMJ5UfqyxR54BPMFdLcsz3co8hg7p2T2t/mok5dE2EMECjU0ii
I68Fh2Wg7WRKT310IOJoJUk5VmuDcKgttZNBzN/eb+EWda9ZlaG5ACAhWKhU40i1i3opzm40T0H2
1uTNxk4SvXfopVuk03aWVEbXk/VjvMxvl+MWzNGa6NwLHCPjC2TjGDFDe62nz634z+JEVru9kG9N
644Bxj4whF/29BTI2f0E2A9nyu7iRvXw791x74jiUFIrZFj0m4g+bYRvEsrCSa7oqyORioheNtKO
IAgfR5Hk+RMT70CUhAvwq1dH48crsvL06JYfxMaSYMfvUTlytNlUJjmpMXeY7yYqD/ALzsLYw6Dn
K5WnoHK5qr0Q/vYfocIHiaDlWB8+VYEg9Gh1RliiI0TzFJg+uvO0AcLzmfy8j3uppzeKN5uvYFLU
v2yZz93ePIXnr+2Y4T2WocjOQK9IObFEaxMhcV7JP3kZZYKVxwoKFLjKz9tgqXh0UFrsVQLSgbRZ
kHldLaHSfKF8ZbX5F9EsDO/whTBb70JVbWNW8C8naLs+39124/wmgGv/vzIsS5+OnrkgCp3V4KfN
x5d9Wa7WLKmF2a+vIg5Xh9esP9GK6iX0eoRwb6DMcas1kuPQUL0RdyXFIquYDCo8vtfcK6ylNeUc
8a0j9OpSljD4vam2P7Zp+bwHIk+ppNAiv7qo6s28X3geSyiOjVPGymp/Z97Cmr89DwPvMCTeSvTi
KJ4Doz9JWvYjLXJXVGg5WQ2LI+sjn64k7AYUSRg+BUNVVgf/DOHUVN0OXJ2ZevbJXub6YaOFKDM3
wivpoeFuQe9q7XXxFgGcSYeO1SeWPytmriUUJQgAEy2qetogjrNdn32aLnup1Z4wdh5pu3Jz4yFb
OfKDpqOBNRU8CspzDyLytXBn36WUNUhQFsRY6vdlc3im4/yeUH69L2GDFuEaq0f31L8IK0jciPG4
+g3FBfTARl5XPYob5+dKnWglZrmwJXWnwPDmtYUI4im/c1LYoSf5baelz1V/x+ErwA5X1tcRjIZR
oMbv6EJT5X8qrUXJ/eX4mnH6mlxS0EvXFl6xUC3YDZRPLDokVlH0nfbvgc61Niwxnhw2yQgH4Vdi
EIeocMmbNvnfgsRv2VYsDz36zb0dng0YdegXrZDbRCp7phOyiSPCPe3zsk7SbZ4sBnw/dF5RHz7m
dT0x/wMhEihvQfcwNHQzE6ehYMMus5KDRJ5NUdSpOl4zrbR6P3YViGFAhStKoBC19/y/FDodqkRa
s5WKe2fcJVAk/3zhTAei3g91lua2Ve1Q6vOsmivyymxUmlDeAbeeOjndn9FKinpus6pkmzqefuDc
aQjXIBqI1rqEduE2Hos+91vclswuyF+/S9o26fPiiA0laHuZG/Zt7GVod82TrL4Jrl7wDqIEvNHi
496NifWBZ9fEr+9VSEJaIYamPtJvLtQJhiBIweWjBGBA3nUDIRUEdOP1uY/mnmUNpiGC3MlWEZZW
afiys+D3ytpTceXcIrURJ0la/ZTTJW15fnguxkMWM+ByMk0FgxgUjVOBouVZC2yjkTksGA6YzXKI
RBAe5xsHpQTKtV3B3rvUJ8iih7a3LDjnTTsJMM0y/P5pEZ1q8prGKq6xuCoJDlxpyEFxjk4ibv8s
kCEWZg7GpUFUQhmRk/SZtelOWAsZfKOfpGrF7eJ74xGhV5EJKRbvEbFRkz1366fzEzUin2ySQqIJ
iiGeKcZMdYAe7bf/QA3Hp/R5r5K3L+oQNyGPv8K96a5u1eTCRlxocgB42rIWMujmq10NtoSw0y4w
thtyAnxHm+2J2aHMO5A8KDElu0TBaMF2geuNC6iBoJuQDUIwQJjveP+K+naO3zOvsN1WPKHc925z
pCzo0zo+3EWMuk2Uku8s7PS8rF2oExZKrAUc0WsU8sJuwV+4P8cypcLKR1HAyX0eg8Ujosp+a05Y
/mV1kE5qBsxsNYO1hw9bAHcuJ6gnKZcAR1p02+71uDX1bwjzJb6E6p4GRwSjPFzMiCGzJ0zA4kVO
6HUJypE3tXlHXqSLSVFRXsn/ToRef8/M2fxBspX1uG1D6zFDWEYgYfZ4nVO1S84SlhpawBtcFRtR
6KzeQhajBEg26ezfoxDkA4dtEfIKIM/03Qt1VQevUb/MgsIcQU9EJtMIZD9mPsKee3xKMT+cCssq
O4Z8rUb68AEwciuMcp8wLgvkev2ySklI8sHRnyuXB823RnmQkzXwCPyG04ZsTzKoFsuEHiBUaRQ8
d4G27a1b1yOcg8UmrFRkWbMhUr3b5FmXi0SMDsOr2KQZkYK01snOTN6SGYQ7YC2vVUUDP4a6q/xk
UMqVPS8ECmq4iLaRNVzUQAanIWu7YnKZWC5J9V2qDUaMTDPGiB3ECH3BZpzr2vO+4gvthLjmt4xc
99xWwbpNidtg+SU+q4OLtViRuxoOaERyotO2jWiCLiGspNQU+1ICg70BI9dFui8F4sNxO3tf5AtF
KoeofD8bBnniCTVF5UbBvirwmlGQb9qo4jUqlfysPJ49iBS22b0pVUTD/FAGklpagC04vi0RCBbz
vYebiBTioN/PuuRuXa/rdmhAM/Ay9b+KaYmTT1P4H40+48ORl6WRhSG8CuKT4lfRF3nryZK/HslH
NnqmkVXD/tSVS9E+uKFVa6i8l/mAj52V32LyENqm+qhYJwF2M7m6XRMYoPb24kYo1xk8JuBxxpgr
ktC6Z63NklbISwqGLM0LuATWEEF4z1YsPI0WSf3KYDg/Zk/ntNcsMZMq+BkHsaLT6qu1J1Ys93Xg
vAD+FXmno9dDWCGohawWJCgJdMbx1PKqJ7dnkn6iwB28SuBVhNSqiQDXT0M0LW7uSgdi9tUga4VA
FiSVqNqRd5UA9qr46q8rJ9jMgURcIL8W1uOZGJdE7cfsqrWMCct3C54nPodrJ4FVidc1uUsAKh+A
1/2AXgBOg4nJW96hdegvLir6NNIHTmOUDGtMshNBTVjl9n7uM46vtlNN00NMgRPGqczpPN35V+Qg
s4HQFxUR8UHDt8LvzIxT4s0Ur8EvvXhRGCHIzHDGGcGWVWBKKH/qNLkvfCvA8rQH+kSKu7wJDhpP
FIQyZ24EjTpICMzy9ASEF+EcDHrmCiqcjVcn2F/lluIplKZ5Kb7Xec3Vgv+jSXnb/lB9SfNX+C6u
eo2mWIZQcB4108qXZ2rYbWfQrZAVIV1VCKvzO076vFNzwOnEGYwAnfHzQyZ7ByVc5cvWizLY+83s
Uvoiltuf5XS0jH26iUebYr00nxwtiCLn4vpfhR+edOrhV/O19dv5KepRteOthRstTgOC9J9aXjfe
xU3roCQDyp3rMIHbQCre6yPqMTTsnGXJJWuZWw3+9NDv8vzOmz1x94A/NeKjUtC2CuYWgN4eqO/g
t4eevB2YMEqX9KMy6micPjoehMcmRw5Mc91t8PsT50KyRiNWXOHXM6PcGdc6jJIptCctir3jU35b
qQZLMmAxpopLu4a0KI2pvna9UdAif7rk9xza/LAc2uqGIHGuuTb9Nci0J9cSsTphTcZn+3szptcm
rvbyt0Fn607jNKAVkindsrOBBOCv1oKQ4y6cFVWuy5bJEd+i0mErRtAdHwOt0AhmXoBDwlwEg7jZ
YDxlqPFrIeTSqen0EozNN32EtyQc0fhFY3bFBSSAq1YEkL0nBl5r7kj47A8Ktyi+hRMLQ8TSFnI3
f07mQUVU3NDJYh/c5cHWNalsbNHsZPR/aRH76kPVMGyajR8ZrLzlYeSwn7Ulti47FhWFX1LDwRw5
bkdcmtnpdc7j74OMn8KrCaByQfS9t2xsE7nM7s2OFpuEDP0x6BEXJLvR5Ah0WE0RNXi48exL3mjM
PGdv0yF+NraX4PFB/ZetmXV4DZecajWetUF50CucWhvpSrRUYW7cZQaFUKFLts1WWlh0MsImFW4U
arSCWQj/X19OK4ntOZ7rMfzsO2gxxBt772KG5JYCraPqICWuq/IVlF54wdWIwUTzj4scSr+Ttaha
+/mjgimJ9ApW9ZOv/MTW6IXWIeenGaNDUIAD217BFZcAebQ8OdJIltzKx+29R1Lz0wK+NdktEGRR
HOgjRu6THVmabwgx3eeImw7Za+CXQj9G3MEh1Gkzboi1O9BNHZIkPsoJMNFE2u0lk7kLYQiD41bd
jTVFUhjlyHwW3g5D4XWHPG87psc92SwQDvcAXt1zQaGyYe3elw5n320WXpFJce+8ZAuQnPpU3JFZ
0pCL7jQZezh6Me1exSTiDvXn68KRbpnOB5JweWDqjtaxatDbU7RdpYkTzHHM14VDY/TfCEAaN0QP
4sRAkMo7WuxTcXS9GOaTDGCT3c4DFuGpzaPjP9ogwlDWtX62y5FwMeEj+CCbQSYCZYmn5kHSFu6j
WYAXioZJPF1xOpUb9bFNjuR23AP3a520SSVTK+IHEywR0POlOAa0acl3mgsEZ7S9KerC5yq4NoVw
XLEtlC7eAls3pu0Zh4Ra6DrlQSFlrWewS6vvh8CGpzpj3aHZlNVMQ2Tv1WfhXBMPuoORXcv1yGBN
IpdTzZDdYRjuC97vPluZqdCtDf8pIQajZ03Zck8Fc2LajtL7qbxx3+J+umc8KFfkdV/myW+rN51R
y31/gUU2QCJcg6FX+PXX+tEPzhK7Zs6HhPKs4aa8UvZ1xyhkCbD0sMRA0ZcFTd2kSlhvUkCmtpMq
wxLDmyUb96aRq21kSTvWmZyXJzoQinQNjr2SAr8hLWOEmkKzUdKpN03KQRHllWY3ZUWwvipIVl+3
inkXGCk7iffDjG1DzKHl/4p1Otwe3gwaDijIQf/ecZEpnG/XCWfmkS4HVwYLBaDPzit8j3ypwzXX
zjeKSIak27GhADOIfDGdzcXfpupAzoy1sRdppKFyfB2Q3c9rv++M3YkChWY5Rb5NZ5yoyvK2IQeL
fwll1bf3vmxJMw8QHWA1yCm/UnrQlaG3febKNhRUyqdqsNKfR1iI8wNVF9q/xS3yQlGw7kKDfokS
kejh3y9p5INEjJ+/2MC6ituBMDVnBcLyMANyvyLOBXNwVHLLUNmDW5CuXMHa4CgBPIkUMf1/zrhL
AKnlYqvmijhiajV2O79AMAoyR00RrltnPKFGKMSjBij+wdVdt/IgnX8yDDdBUBnfpd5ar1F4n3sd
y+BIVHEOI7UmMQHgmGLhkA6HxvpByXcquq4xhYcamqz4MMZVsVMLQfwL4X/Ab8/d73BNFmCdzd9N
Hukkv4BVGnYUoEeeFgmBRXqK/Xrg9y18fp+T+pfsF5Tzl0pr+EkQ6NCFthBkcZCCs43LUlhMADyj
AwgEZ5usYMaJ+CzakIIc/kD79mw83vHge19537NFsNDueS1bAV6bDlQHvF+8iiEm2rST0f9LoTx3
545SjJb4XRRgtt2a8aYVSv5LXGy1Apq9ql78M8jkiBVGEEU1I/gYCnh7xeAu5VscuGorsDzSouBc
DM2QBDvU2KSkDT4Eh52hIVwwpcgwNqhQmj9yNoxjBFBTgxwy8MasKRPbCbfnsPYeUdw9dY9FuDUL
2NULzlbvngXBaRC6lfDxa+bzRCnJMv/iT4TPNrj4MdttcBzM8P6ic/DiQKT6BBM88JFW/sQN60eS
JmQPMRbSknmVJ3ST/0tmgxwte/gw9stGR3SbwlWAxNoxgAGqV/Khx3iy4dtmF4iaNUQA+n3l3hzL
oMBgBdhkbHPwd7vLKCDMgltrCjk6GdV30mCh3848KmbP1vQf/4wC7xugbJKkJx+8oimEHDNvBBBj
o0oHkhyfCspZfx8CtaRmmySUH43j8cC5lgi6uVm1BGySzXfo1iWFHZBokOel2nVfXW+YTroAJsKF
Jy2LRHeZ5DZFS1frO/L6NIn/i4qPx/ObxHjXMyw3iNL9KU3Xpe20qfMbZsN/n5v/b0WWjRpl9ZA2
TaNvRraB7Ou9Z6/cRxNH+CiUmcTEshc2H0MjIZ5PjuhIGSYGFY5t2Uv69AxlRFneoQLXDiScJdhP
XoyWqurGaP6ygII1taj9p38YeolspB4Qbu7huSJR1OVCCAwbrOsxmi2gO4QI3kBhv0BI1QcjPIPr
VgsJKw+aQgH7iSVBrLwJ+dWkck4yCcTFK6kzbUw41TQhSBSAlVFHtM2OqJ5DSzTvyQPsPRRWpm6u
pXj+4bwPVlZ4zqboeLlx7hxiKKh4Jts1SphLc1IcqI0LoAQnm8gYJjCoRqIlLr+oUNkKLpJtrz5n
7VoKvJRhs9HcVQAtYilnU7Gxx6f7kkZxFdypvLJ5Ffg4nFKFE27rLpOvph+uYs13LIneBT8amfdC
pyKjzTwGDWzc5MFXc55+MVaPZhGfjSZQzFMeHaKXJ69/Ev6ZOBjAolnIyLWos5mMl12pm+FIIsMN
EJzBk/bloVvElGSjdzLcuKA8lM2T1VpfRPBsxJVi/IKrgNggTJgT8+hbpzScVVEiBKs0jgh1P07C
A/hukxLjEilXN15XCaqss719VFy4GeDxg9bW5HkPCL4dbSTKxwid87XDkC1YaGMrQOJ4EyEFn9Az
viRroXXHC8kg8OTqGADWxTdHnG27GoZSAfiQTXZQjXZzIg3ZAAY2q8TvH8BOR0nOIRUiLLnmhfw3
bFErWV3lLhRqDn9W7RvZwWNh2cXSGODaK69UNJAsvnHaXFE9sXRlsY1FpMM1Fs851FSVB37tBvqT
0NkYm6XUBzLivkRE6Xtej23RPTHYQBlIuILUxmNAlrz07CwBP53Uu8nEYSMT8GUEAYEeCUeJsELv
xvSFplrHgU3UtKEylXUjXgkRI5jwPxz26QdMN/mzdt8mhPfqjorYprRs3mTBFvUyv3gGXa7xhugx
OmcrcEeuEheHyv+/LMsgaoZ0Pjd0Br5qwP5fI1BgnKvUCQRuhzgFXxFv0p9yzcsNtrQACo78HdaM
52UHR4NoFe0mLLP5zkU2FEm4w+CjWmua84E8KWfd6hTQxevNugLTTHUng+gyfddVamKSu+D6Lp+K
WYFApmcGvAR8uD273kpP32eW4I2MvOOHOJB101qW5wFm86V15hKlpQVKU6OEebso/njHPEy2q0ER
i2DEz5/g3A7d32H9GA7VfTaGc93vWh0VjJvhpI0ooOl/u0nSVcRRHRAkad5rIvSBi4UhPJk4GO71
X/B5NcmqJyquOR4oIeTKN4X/jswx4bGZ/pIDWHjEileFa8EgaMw77uMFXDDxCNKmxkRp71gCSBXk
TwgXSU1m4zRpdrBpyvCFwDNqheOnsyTGWzRjudvRkdXzha/MYIf4QB7yBAGcEmyplvyiVr07M5we
YGKF92tHSirTEqMt9v/tH6ISwADmthK/Z+6NSg8E/O/FCdxJTRaMao8PEkrwSe1pW2SfeYTF2p8R
ryLymK9M200FGZbZxvCXW4CQZfMqszvy1I2T7QZklx6jp2G4q9QxBjfHxdBTnk20selmgwg3df8a
EhqMPExlg2COFIPFNnbAxT/zBL1YP2COmxRZKPKtkrmmnWi2xOHlsZX8dy4Fby2Vro8tM5nhKC1Q
+fzW0aSkjnpIINvg58O9uiSVpe3Al0aYSUr2WJjez1xvxOb0jeL38kXFDrxBKdcdGHrDdJSNqzUk
7uVMhOURonvaZCEZ7EvDQjw5cjKZli5ZIt9grhIoOefrR0Kt3LSfLesHGCkeeXCl8NKF8i1wIeQA
VwXk2GY+pjhS6k9MnKk5UVLk7utamcusseM641D1GXn0ZLem88aPqeOoVzIhWeNqxM3vb9xNfUoK
myqdEJYa79Ag+VUVaJRac3NxNHU2auXJYIUR71UzKqUq+WSrykHBvShfmjy97kv93WU/60E6/hHD
JJcv5YNHBfcbth4wq3B1nE4eX8uUxx+R3dQNhmuDi+dhEqwajDKx6m++3Yjxz8QxwUEBbHBtyZZ8
hjPaypZTVmKDAeSK7X5jD7EepEtwJnfkrup/GlkYCxykUHHCbjDL08oLDzebgiqHTMOqo/gtWHC4
1DifxSbR7mB7yDYsXDOuBQatSgVmBaENZW5kc3RyZWFtDWVuZG9iag0xNDYgMCBvYmoNPDwgDS9U
eXBlIC9QYWdlIA0vUGFyZW50IDI5MCAwIFIgDS9SZXNvdXJjZXMgMTQ3IDAgUiANL0NvbnRlbnRz
IDE0OCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3
OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE0NyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYgMCBS
IC9UVDggMzA4IDAgUiAvVFQxMCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAg
UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTE0OCAwIG9i
ag08PCAvTGVuZ3RoIDYyNDcgPj4gDXN0cmVhbQ0KY7SORtHYy2y+TF4KhJVX+5nxiSDCfQatRZa0
AJubyiy+kj9iX/8bzLvZADijmhJqtypKPqjHz9/zll3UFGZGo4Q8/kjWaViw5JEKRKscPDN6mxj5
dkyyDN3oEvRjEzWAC/+YSvJQCVqnuv+o6K8EFm32fVFhXwPj1/U4X+IH5fIjlcyHFoIxddzmlvjh
nuZXOzdlY929FFfuEo3aCeMbgqHWDKKNcbjdE3IpY9DU2rlgEtMjQfZkCdOL6BHNgISZZlzOHbjZ
DL8pFquPmBUDvaOSyEH+RDvvgaFru+z0TOkyZyPqwa8vlTPs2ql7mn6f4SHScMt1CMyQolWC18JK
YHPg7qZwOczEZZa32iKoMTQSE+MTCcFptalg0susxTH9HBtqYDw2QH2tmR+J91EvjbelTSqz1X9S
sK7FlT5y9fakmKqFsr2Aon9hkunHX+VEVqOzTFcgBgmhabAZSq8XAQ+rMDhD2KyFFGOFdV/UUi9N
zpaAAyuCv1PWaJHYXD1MZ8JSQ6Hd6apRzM2ZEGONlH6cVdOWsTNMkMQNsE+xpQtzcyJfeJWRcJS4
8CCyRAxy8ckAxGUckmsLvWkZg8cp1Ll49ZxYBsesoKVOMNbS5+WJTHjqbOaKSFtP9h4kz39B6Zcr
OxtGER1y3jAJ5KjhgrqaNOx1OJR+twfP7OdkvzUWAKP8CnI0R313mMhKqvLpchSZlVNR5sBq7YP9
uuawl1RUHHFNpu/fLSvG3Y5IYNouYhdYo5WiLPn+kgG1xTSuDH1yC8xkWxVmJge946gB2lZaFOi+
VFdPPPxFiKmpMzbtwdzVHZXwU6pUe5lo+gtzpLLco8w1ypT0jy81xbf4dNo0L531RTHD7JKdLke/
JFU3VHnYfTe8oPb922atvOKl87EOnlscdQxcdVc/YF/dl7zazR7tXM0yKsGsu2FXl8vslmdrbWZ5
3xXI7xbGWc7ArxuPRW68ce7H1mcpSfH4B5h9ZmKx6X5juAIZxVaR8mFjwILg+8tTH7ZUpX4yPt1i
V0j9ew9q4rzWbOBLfTNlOiz7zof4C8bUi55m8V7RX/I2jH9WUV/b6qC1cwzZyXGOPUg0O8xGpLeW
qw/4mb4Fd1Qmjz6Tv1sZ/yqI4ZN6vtYCrZNk9l5/Sah6Xaim9EftzsCMTPYYYkSWHjJRvdn4Xriz
AnOyAOVpB50ZYSITNwkTktD0Fs2goVgb0OQeK3sU7Vvfcb23V2HEnmi+HQbV1pXDbBOGCQkYQISC
mflW63c1BYYnpE1x3P3cO1jtqrkXbkYIN5NZWdjFEvfeO/gIXmrciNJVMnknvhx38vfDvk9FK7f2
/X8TfLnPS3U4jPoiMBawL5txI6QIUQUbyd6gYVyn+/wCKRrLLzjPSOS++SS+zMrSiiswSgD7RrVw
DRY81M502KV7tmEdZNrJlxXUz4/FtebLaT3uTSfAMlI3VRo9GJhz9Uh+tOE0sCz9Tpi77m3PJ1Dp
7p+KThjR/rdS9V4IWVPoFTKDHRSbKXDt2GA+cGHhewQR9f+F6+fcDi2G1MzPjNnWctPBbQE2gqiC
lX6t2qtZXqw9W+xyEQ1HjYE4lqyhxnaKS/rJ9WubFCUNfPQjGUiOFQOygoMQElzmEZgjHs5W7HOB
MpXKEP8dCCHZIPl+QC5dDkayhmgpp675s5HIdeRO2+P+oupuVVApBWx6NykiN5msnoXpQxGTre8a
Xz1rNQcuX1q5z6dLo4fSkkGASF4Z45qDykYudd24LLIiCQTwuAmctOnOtdTzYMR8mvuplwAPb9eR
8cq10y3oee/yn4ES5aZ+0x4+lSX97K74wCPLJhuC35zT04BWSJAtt04Ud2qJDHO/CjPBEV1eYXDt
GHRXCJOsopIx0PDs2D7Lp6NOGcBApxvDtyZRFvRoBngLl4IWo8Fjs0E6WNn9pGt8vYNlJCUXuoWa
rzeQpWiIEgGtWgAKbqVl1DwhU3hSM9ZBSUX8ugnW97SWy70IAFp4wCuLEpZPkM6eAhKokZLIxfuv
YZCu/j3f99oE183ItPFmDaL+/J7EOWQ0r/hbrmpVVZFLGOdCEm8thb1L8edV66A7SzLsIkc2izSJ
6OztZYHfRIXz19YYoPczl7CIz/E86YEjWMi9bbOOrcFtcxkNisehNJZAh7YH/tPPcBgW18lqUD5H
/VvIUhRHWisWltzSSGvhcC8q8g2RKjL6g1sMDJOrf11XcnrmeNAGGClhYpophQLhfS0ORKvx1ope
Yb9oYkUSRDKUEqj4cl+AvwOOMfp8Q7CDoWz7qzm7EnxxkEVXxZX30jn7OaLJ1QyZywojAkoIwwAo
z5zGrbhDOcufH7T/hBpnCco0eP1QPI2YpepnHvQpqhpLPKkX8HGzrMjB/oxcCvCH0JgG688V4VI/
waRDfOoVvwWclrhVB7DggyEbDebc/jsaKQGH3hgam1+9zRqI4Wsn7ijJ/ZpglULGibZ5TCGmc5E9
3yK8GPT71PgvQYVb9S+xKXl/jg3zzrCJLML6tWEvJvMpGF+ta7MAUItVgG5GQ7Q1IadIhucXEDMd
Crtkp2v5F6I/wy0kDnA/GsWmd1HoqlaOd3yXb77A6hxKojPR63Mxb7pChmWGSkhNKQnHaCKWuLFd
XuBcYlyyf1S02DJK0wQ1JD/AvPuctsLe/S/n5crfWxRrj3n677EkZmp0clKrx/TfottiYi/z/PVE
lE67bYcJE6QJrB+sDmvSKCadPg/k8d3s24GKRg/HJhL7jEX7MfBvNlPG3kKrCp7Xui8mcMCCtTNH
I3DbUguxwm1v/UcJa/O2zb0kWrxOahyMPp30osQol8+cnQ/pBmCuCIncPeKVi3Cfs2hyfOpQNmVN
ZyoKku0X6JyTivFNDg3WFZmJNG/CEpAu6Ug6ESv80FsYlh13upW6EG2ol/FYTXgnGAaE6ZTy/iP1
SgiAG+aEz7O6okyqjyaEvxMCIFnfMk6Ae2QIe0p2BPuSa1ZweF4a66VW3hfBZHN+mVZISjmOOfB5
QpZT8eYaFIi/09PRDlNOBmfhLUjfnON61zse/p7dBOcZWWDQ7KiNWikwXZbP6Sk9o9EyP0IlD9Gr
cFo8q86AuIAawwbQUbwVePXEzR6aUFikUq+cbugTjEUt1XWm8UwpTw6VeJt4tEH4WEW3P31hgIof
1eGF9XlnmfZY+JavuDbldtCP6fP/3ed7U1fbVA6LUUfqI9GGQb4v6haPRT+mV2a06FNiLFDpTmIs
kvc6UH/n9a3N5Na+tP2739Vp/sN4BVZRjVcEPeurevRpQRRSDwmM1iHRuJAFTK5GvTCkaBnF+Al9
jSiHYnYEz86Ens8LlKV4DkwmPSpbdChUNnYPXktvODy34ouWoWgewCkq83UFVzDZJfWt6sBlcMmu
p6n08mwqUmDgc6RCYx0qtVclOalp5+W8gQhGp0QCFb9To2xn6ijMKe/r6nAiCnZCq20w9Cxq4ZVE
n5jY/Xn9YV2WQdOBn66GMJavlnfD8+x74Q8XYF4hSgsZ6lQnFvWDdthPWA5r3Qx/aoAUIslmiaVJ
w+IiqRdgm+nxVVoPTlPQvGY6iSo+4rTrgpLjQmGneMsm6EllevDvzxlu9bjzlLxOUoGcG7Tw8p6Q
5NiR4OuB751U9/LbjZE5Xy/nEq95Fpt5uUTA2bFiMmP0/R4IWH2jNzv0W4ee/SaGekY756EqwePl
YLRf2O8lxJ6GLumkuv/5xqsmsODro8Az6NbcfltgirpRR4DWgWMexWXjfTfucseqDrDKmxubNOPT
6eUkZbq1sNnS8birO7wZdClYtVbGijgYRn8idJr3eVuCCxGL8lmDYaryvo5LZvR/3VDk27I2DR5Z
Kpzek6XYwHccE6HebuNggxshJtgZ9LIA9cUZv5zVl4pfHa67ZDD+m1jrFeU9O/c1cq5U7wCwnK3d
Db1tBbcqnGbTm2u4kvdfg2sWglMIHNmSSupf0oj26Ltmz4AjeQtboCClv9aMbvquMy84PZLmPSOR
7wWnJoIsLCfJG5wORQPbH500lf0HQG7YSszO3gEYKmp1ZnDTpj+qjjE1udURgEKlPbECoBVNKWWu
h+3jUYA/CxnsPcTbeyaE7D6eg7lRNDzh5nubh0KRVf5fcSKY21mU52ZekXvkj2V0QNdMJsHec/sR
8BXdzqGVs7XkDyE7cg+hEqb08M5Qmgy+Y8tk8tGmwil04FZF5JEeUe/7FOf9P/RlNZoS4naYJL/l
+5lLY1xWZnkVqVU6SUaqkbJDlingQJfuBAHEbyL/majcDhm9GAMQlIO6lg96B08kKYy/YcWsnobi
XCHyrBNzqiHV00ea1nLlFlQ4yTF7sFJpTqFof/RN2V0tRp0Jdx/qbPQaJVKZpgoUrG+wcl+PuOSi
SSrwMy76ZrP/uqUIs82yxjkWaZKa+eXp8dxbMpkH/GBqAsxeSvHvWK/dgyGzDoRCGq6IYMcKjoOO
owc7J6O+xz8KSj1l9Ge/N2dkQqwoWiRmqyueqRH/hZeQp85U+X52augQxjiDyipgKfWyBhqsujLH
w4G16Z6/xpRrH0KufOjLFDa/iMbUNHRjEMPgJ2+g3qt/fZC+PPl8nPsSLjJvpYCFUH8pqMGKxdS2
4XN2bF8G6gXxlEbMgM9Eq4O2j7E2SbSvsh08SaYMHTtQCDoLBfYGraF3uNALiEDVLbjXSX7qNzQv
RsJ8gXFodl4cYqsHvCvekE7ExeERfcsjqS5AiiAn8dZkF9/gmMNFXbc9MbBE1QA9rOD74kyciUou
Oy5zF0FUYBe69bsDm3nDHb99I4m+JGenZN9rRz+djRxCxciiwHntau0R0cR+z00rYWFiNDHYkga4
ri9z+6yiavB9n6Er315b4oXB4F2JA7waExlOl+y7RbWmawZcOyPnpYliGyonGHm+E5z8NTuNloC3
olXDxMynZc2m/Kiu4jQfqR29gGEWv9gJhjhdHLoJY2FYOoLTItf4FtGD9+YxFhIjG2SVa6NkfIGq
34svMrC2j5kamYS8y7iGb+BZHpfAoMkUwnirJ2+VaNvIJCQLChyNqUa8i41danfFwe7ubdwdslQv
nSV2hboPfOqYO4nknQkpOF4JNsWjba4ofC6iZVMWjudHd3FlziuNBqpDfxE9MclThiHBrkP7rNUl
apT2dSX8oGZQkVv63mNL9A9Qt6JnikjxoZJOHcW6b9/I6qGeMM9ik38f+RCJ4dKHH/eKsVAio+E1
1QLfeeE7xN7Z0EDWiT/pd5qA+9+WJWfsnNqDpzu4+E3/weNKFQE80qvAEZSCdAE9QzQMybq7vxdB
nihAyPMcok+Fmrdem39/pVIRKyjCHjflhMFRbBFQWsfT+Iz4UgG0mnzGIwI4VnvSdbU5K3clDmWe
FAW0/YeFzT1O3rOSCR5zjOXDiof88GdBQc8DXlCQmKDwQLwdSdjdMT+SQ5kHngnepOU3UpmV9r6J
L5jZ8JAqwVVPI0tvj+AL41FspRmABp+jy05955J18jClKNEViIuIcim7YPmUAoWdmRUGpyC2Y3Ft
jEJIYXdr6KapLYgkrIpcwpzQQVxOmXsZ8QVW04Z8vgBh1SWWfHp/+37iQAUqy/RyWWMsBnh00wLS
Un+xQwO2KpebtrEuVvo4XVy07ckuj3pj3L915QPoVE03MaIYDVijlbTilw+7FP28PWLBpkizWszx
FFyLO2EGmx5EmXDB9yLMkZIzyajq/esYaNvtwkGaDJkX8AiOHqfIjswsYeo1tBLFZUv/tK08p0FD
CyqU0OHJ03vu9n8l41UYoGLwJh/McnfkFx/Hfcm1l+tM4c9JAEQiOTHC83qLgiMlxBfn2hv12/tp
/XE5eRKE+G6nhgMS3nvz2Mtv/xXSglMB6leZwPED4Meeb4giw20HkXpQ2KaVQV6GK6t6VqeG7//c
byupvGZoWepdnro6kFbJtdDC7a5ZGxiNaFDzTpw1fOWyz8iyaTS5uEqBNRaypJ2NZiYINMHRRZXY
l5JfuEBy+M3eE3CyIAS7ZsU6Lli42h/BlTK6bt6jAnFparGyaoCpLndhGonr0RspzgU9fWMffNpF
sLvyF7lQolIIpfqWwAxKHb17WnCa0apFC8TE0A8N80oQ2OYTFCaGGULFN++T0VvmG+BcsEYKQrKA
1oKAMJ9nAXPvoKF7DfZFwUH2zzmnlcTzDQTLoDIBvXeIoKdiWEu0VcWBQ9XIb2ISLkBftAY9Og86
aCJeh8UTdYJs+uhjHL/AEe/0TYFQDXCw2TENVOEnOkpWuXEROWFn98Nhayqq4U72KbMrIPMKSk7V
MA1YA1dsl5gvIv1h7n2KVflM1jbHokI9JTuz9Pa6mpzj/VQIKbVCH+AoymWnPjb30YeSCeoX+QZ9
kSITx3S8d1SJHP5qvZDq5UBZp5K09jg8AdWb7/r9C91s92jEdc4UZtc/wUPHWl/a0eq+ySTjSkBs
RQLvANtJcCnBINg0CtTA+VtriyZPqYPBcWvVCCdXPh6akkTmNTJwIa6A+16aWx+pwGSuP7FgxwYx
59HaMk94pHR+ABveO3kgab20DqEzaYU9Ccg4V7KC2TadxM/KQw/WdVe9v7AFSBvOSY2nmuX/b0qD
YqEuXxE/B2kTIsR49syh4kZ5dTM/vTu209Klfwmv/2jmqlSd6uk6XR76RqiE81/v2doAvFwgYPkE
eJHi0IwZblKP3/nsCxBv00GthDGrhNFD/9nDyY43q3kfWeIkwnImn8nmqBLrjp7U1NS8J9Nmif4H
vIP7mZ1bGCh6wkSWiJDNEYUu8KPbmZTusiJk6SEs312wx4BM7UO2v305PLqy81CotnsKebXLqvoE
nj2OCvQhJcjPYf9kUXIoWWFCNSCrYjv3qiaBEq8mevi5bDhgJI6ozn5R/TbkbOxa1jtkrroSTTEm
QoR4RgNBww6pTuhGYymHzLGWUFfoeJPOepn1QXhpAlaDlnpz3M5TDL9vMc89nB9QCuqAY/nehodB
/DlK1DmOmJP1ZaFCLFVODnVW4DlCH84+GNvn6znoetqQg4kK3PR/ZTrFCAOY4sJDoUqKGK9BEXjf
GBHPZ0llZVWmXwAsYgiHQxJb+DIau3btDBBzq0vQSkznWeDsvckmoyzmGs+6X8XEdIOjk/itSA7B
bc/MuPhJhiKohtZukdvu4zGLedBcFNlEvkrg/vGOobAs853FYDXfsfA3cVkCPlvr4C3NssvlY0j5
Y+0E4XsuXmHLeX3sCFUflECROdLJ41CQzy8x644kc+b+QdWa/W8vr/i2cYTMAhHhsmvb8LTMWvSw
Uey0LnWOQ8AMetNFqvLBgNKoOJ/AqQLx/5qj2/gp4xX6Vkt1ZbZ4nxJjqC78njByN5pEsgeCVRhw
hC0CLmlj5HuxEs7tdBMUy+Ebr73yjySLkEPsL4uxS88WD2xvUpnNFk8reQVv+9q1bMJI3cPQXSSN
H3vg2D9+2Ra6zdkXVZh9uq7Z4e1r8C8CBJ/+APIvFuDqOWT4YClz5dTcvJpc2SPbys7F1CFRdkN+
QFS4GtlwX1IcRansvmuBUmeTWagIxc/dcDpe3uehwf0GykLCswNgBppw7oRMtV0AIEW9wOUFj2hQ
dqb+iuWkDcRG1pbIPA7CAhW6/Dl/YrkzYNlN0JYWqQBWStaEuUuM9JY/OC7WVCS+IMVUbHe0hwVp
4TVMEGKtON41Eqac38VjN8ogRttJqzeDDRClGjwCbH38F5xZ1hZvqPPK2tRT+6Y/dmbeefWscC0E
UK5a7cu1y4u5Nl0afRzWpesTZzt5LI9qY13p2+hyRknoN1k1ba2iEbTyN1d6kDs3RLoj59nqgK3U
BveSk5biNOmxo6uiVhIQEuZ+MHO7UqHwj7C4xEbQcjGLA1wpnsQGvxaORzbEaVSS8A9KTD9733C1
q29KDOI+b6QMVXN4qfx28ehpxU/4wHpxnQZCQaBjAsCkl6X/f8aARQxWQGkKD7uKRAjacWFes4Ir
uNqv0C9VXPMUb/tChK3yl1BXjqdr2PZhav78FWYfgAT74+1v5l4oqyEqsSMgo88UZMhNdm5Nwkpg
95vQgYsM7E410hzapUshiAYqJrjrMShgKRfTP5Wsi2ATX7Eq6eiTDxSIZvOS0FWzIbTS5v4bahHi
D9by563KVJf76+syu+oTy2fyknjv5H3r7GrAahNosEuVTTEhdazfCHQXJ+SCxSRqS4CiRrQFtru6
3bwnewzjisAyV0Wf3ris955bpDoPAFEy27rCERn1lKs78nX3e5CLRipZrdcv8bjBWkIs6Smi6Nzx
wYgnOtCWwQyTi2ArArsyoDUJuJNXYZRAVPH3lnNU/bKOx45K4qaWrkCvUX/fKI+U77Af1FXRS3Ln
6i1Saw23zA1lbmRzdHJlYW0NZW5kb2JqDTE0OSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl
bnQgMjkwIDAgUiANL1Jlc291cmNlcyAxNTAgMCBSIA0vQ29udGVudHMgMTUxIDAgUiANL01lZGlh
Qm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAg
DT4+IA1lbmRvYmoNMTUwIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg
PDwgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIgL1RUOCAzMDggMCBSID4+
IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAg
MCBSID4+IA0+PiANZW5kb2JqDTE1MSAwIG9iag08PCAvTGVuZ3RoIDY2NTkgPj4gDXN0cmVhbQ0K
rKJouZ26F1+KzF8Jn97sq4NNGMVc/GwJLByvntrSl6ZsQ1gsKri556Ismalf7HLtpDmDVMIsoQXq
o5I2xtWHIXpDJmHWI6ZYFqb3McxRkTxWoTC0vbFL8lLsMFh/vJjhwJuRIlASxB5xTi2zIjMGL10T
Oxh5uPfndKA4Wu0ZooVb763kDJ97fJSbV07nibsGnwFZGddBwtB2wCj+KmN1bXLU3ZLow4tGjai7
Smlm3+TJ5/thTMQeM0LpfN8PvBWI83NuO1YaFn7H8yRUEvN/ypQMY3wekcQoXU4gXYek79Mj7aIY
Rn2+CoH8iiT7uVXrO6sZwU+OR+hM+G5Eaf8WZdImqQQvszNgCHV/XTl5eWY3eFANFmWUevxIE6mM
X1etKb7m8msz9LktbfsFoIohvanZzgvDIUrKILQ+e4qe2CDgTekZ48JmeNkkybqmNPs251xvfOFO
+IyxueT5Xg2DmEmuwyQivOU/XGk+c7rAuK2aKl6S8zJSB2EokT5jWLKcCZBPGtS8P2KKOxunJHSk
Ywh5crJlEWJzN9H70iPr3OJ+bfzhvAc4UXbHyQDmrZrDiD0lVHRrTbveaEU3UWxTrpsy1o4cJ5bE
KDZu/vJ81g+f1poo4ejtZyW/0n0SFlZir1e7cefJqgpYfmTSfA5DXe09UkQ1KRhSrxf5Q7auLUqE
l6RC8Cm7AZ4Uiv30h/jKX0rXibRgIdtn71RvV6lhDxBY4X98t8zGUOgi73MT5WRKXtx56Nj2ju9M
tqGjtP9/YiN+OD9j+i5mpaC3Jn12UnTAmxDbkU3oZ1a7i9Y6eTOE3Feo3wd8W2QayG/yrImujJ2m
x0m7t574bu63RPuVk8IwFCnM5l47yaB73HezUTcJ3f70X+V47NALbop+YCt5y+Z3tgN2q52PqlP3
WNruCqjWJEt+aPdpoRVQlAAAB/zJb7WXpirPXxoeDLBB4p4m+O6oLKjjJBSqyhLlIxLOJaQy4ifS
EAOvGWEAiclxuWphKcU+ZvzgkIqp3rkqjTBFUWTqD4k63oABdVrjd1vMJdLi88AoehRDJUPEyQhJ
ybFQv3Fm0vLdY3nSu1stsQTnlnkQaGZ8exmEM03IMFdTveFFGh8hy22KqX3+8oxjQ56N6tbJFvVT
bi6IDU1c4j6oeGX4zVdEyubf58MnYml+27bG/OfpsS+KJ0JfwW7gbQ0vIqWXiVSwGYl5jsaRvqyd
ia2c+kHu9WHihRDevoSxucTs+emJGoRDO7kHTWTAfuE6p0YazEOR3mB6bp9G7nZLU6X//X8OcVHo
qZvv+qoca2+k/mgACZqYkaZdLDUymY/DcmBMbD4UKHHjxcfMMONpAnA4a+9YIVPmPmv0Rb1cyzFU
tNR3NyX+uyhP28wEHGq8w0RPgQ0y1Cqd3fpIFRwE+HaNnZd+WFXj3ATTzzh++N83YvJSDd+FpLQF
XmAVoVLtZZRwdO/755f+yLAmXKeZ4zwuB5u6ESmr5ViOpFYZsye4bDlN/3O/nfIn/wFT/1WrJDH9
nHhjLdpDE7LsFNUYqK6tEEdRb+gStDoq3bFhaMzh3GwOQ6r+tDNYvPlnxd7BP5kJg9kb55U6lmKJ
kKAMR8ZgVwyQty8sTGOBtKdZZQIroNAB5KAVNvtnidnq1ExzFzBrikMHztgKAaZC7Feve7TK8o1X
G9CNCyzF45X9hTdQoG7wpjM8XleP6N2gFSTEJJ+oTurFxYORngGccYkMRcPm9o+YsqPMZNyKIlST
87zNf2ehcRBSjy4baJ0GqQOLY95TlfhDjkAjZTl1ZdmmVacbLSJTNdAx56arc4priRSdrCScEr0f
xOe9IQl0QOT8frxmpivG8W/4Co+7cH9vW7U4SU/0KrHlg6vkfS+Hj2cDYl2TGx/nhyxEDEibFED9
GS7xEkSUmPqtNC4Vret6imWk1sVNCQHLY+Lc5MmAiP4n1RC04j5tqnu7EJIkpDHz6HaiCDEt/OOm
5zqRCbT48G/RwXj7/QnpGpQ65ZuRJ79GXgG2uugCPvFe5xS7hp2wyOuszZHPg0JfpGY2XXxrGZn8
v+P9QpIiprRvfHnoinw00CtMEJa6uxlDo0LFX2HEtZgrTOj6f8LqBfBsxoer3/tnZ3ve8A33+Mrv
+U1h2KnmyWr4Vu+QFPz4WoUWZMKfSaVnwudzskIA4poWUpCrgC2KpcKc5GcgicQY+uz6rWg/hTBY
Norvrd/wtVxokGcnFB/1SVlchrP3fkv6vRmAUkUtW228cK2TX4dmtwlBMg+t7W+aiFaBE/yBntzv
nD/EHj70wIdB4vRcOf20JSotgdfi7vXa2Lbm7RdE2W0ONxG/w+p6AAEhp1Go8abwY2lY2Hi6Nr52
4yUZTTdaRqFj+zHD6QB56AoGm5+c3QVftXHEbER7Xv4OX9NWTJEExXoOuzNBKe/XJtJ4Et5BmEIe
h6JrOyaQwuCLSKBGGr8xcOFriHGduL5ikCZLjDi1fbFQzuFwOL2tim+QwT4iN8pv4orSfr7fRjPc
RFKbWCuUkzN0PuOAyazK3imwddPY8s/hGJO+TPTWH0gEh/4L6+3NTctZSgs1u4L7Q3Gc8SucRp2s
VjrOtC1izelvvf7sTAgZNeE49fFRPPJSh2CLSDoO3fl4Osp1rg2nDgh52BndkLJgOpD5/h+SJFX/
umOzsxTTG6fTnirG38MBjEnMLj5CtTlKiWiWG2Ab6J7F0N/BHFHBjE6aW0jkDnDBvG5+hKmV7FKJ
9tswB3axitzGibrpA1BYrrdmQzlW5PkJsX/GQGLzuBivd1GuOOd986s1iCXzYhlM2TuTiO/LLTMf
NegzWHjgEwQwnIMaOYG6hle1JBnGTv4QxM6x6hyhEN7gqPX7fvTgl8KsugUZ/tRROl7s8OLh8eQB
bYLoSJj4W6otXUFW2ARkcAzalU+wWcUbAdElHspFsRLqDlvq7YaUYt3kRFIBzl5ShE1tPDmgnwux
u9EPnYBS+Ub5vOSk8CpBl+LDhYX7LARA3+1Oz6djxJ6m04bPKWkxakDLyRzCy5wdGiXI2XkxX3gZ
MwLBQJ2uIeCGNn4JKKWn3vcnyBYgzVl0+ijXr9FTLHe2a9BPFP5YBDew+eL6Xmv5uPLDZsx8Z+9W
ii36BNPDnftlqZaz44ztLcbQlA4dfFLAnftNXxwZDxMNY0Xfquq0fM/iTx0Pwm4VxpncWoipj8b5
x4Xfk8fxXje/NYr4KzQFkeUyYijWxVlMk5JYU8VdLvWfvou8hMYXEjy8jA+SfjqJbIx2FiERBwlk
B90fD3jHgdBjy4JhQskyZU+nVV8faMyZDOYgrRM46uJ7fAmE4BpiZbD9LMcENl0mDGDpb/h/14xx
6ISCBeLTixM0xrAZLTcNb0mYBva84fNL6EqOTBroylmwfXKfsbCOzLISksEjvm6p+kcPudpvS5xa
3GTT8c8jNcLC1q6k8WoJHx+TG2QQAOt/llwjA52DehrhhQIFfVGT1FQnJPzIVoUmzT/sGc0ffa0q
PeCSsbNoC5VykKfBtoGa17bZz7OGTN4ZEAHQ+vNdWX2TQUrBMpvGWRPxPwQRKIA5TlMv5es9jlMq
oa6lF3yfgQ60d7h1MTlOp9e5UOZmGjucIfbZmtKGjha9UiejdhesdEQk0bLo1Zr9hStTkp8yKkbI
FnUyEBCY07Lu+DlaclmSn1kJ0Bl/NRdNngwLKzG1JGLTNEgKswgfmAiQ5WdEwkGPrXmntTHA8mI0
xbx1+IKC/tcGZNvJED7ZONndTQlrna073xYfCV7l/R+uroiY3i1QvtiSxSFWNkJlDqYskblxtd7T
5KKR4ptOBQLZ1fZ9PeDl11OXRBvrXjrTtC0fbZcYl/fQCQp2Cyyp6BO2hJ1Z6T1YbEK8u4ERogn2
YRQwjY1a95A6vHPeZKBtLX6KJzxZFPIvTwDeUHnDUwpMA6eWbJmmXMeyrXdlThxslnUNcNyYctUm
9Z52x9M/EdBmzmcalZ39BFl384j+p09+X37bNko+fVnpfT63Xi9ADWCScZD4gUlNOsZneSC1QLu7
MmeEVSmiLZONyZpZKdVp46fESYdhMOBjqkiGzUH2VHdtlIii1+zNkdycdf/z094HI0DM1ei3CtDa
qgByUue41hLSH/qoI8/TeWtXbn6VFgaHFP7p8DQh96M8IYiGJxgepT4Q++G8n3qJ4GALaVa8oiav
MCG2Oia6/tcAOa2Apwk9crN/ZshKdc4rUMyfgI54V9Caux28Lvq2bCWpEXbatG4f7uX9Dxr79KGr
Wxq3ZFd8knIE1xPX8pqbskWzvllonBCtPa0QLKxGmZ/MmwhyiqyCoIoAwCK+9/2ZiR//r/TWceIm
r1OAy6eu69qA++k/vl039f6jNOorM2S7pQ6XImpG0Ui4acATuyephDMrh/FB5jMr2ltDwQ4rnNlG
stMuuEmDDwyOpRftN+qj16NPELb8L96/KlPfSogj7fYkNFwUFgfC/EdW94XuaLwAk4n6V83CDkCi
pSmwuDKcHa5hZNVLMY/Odo9p/yTZ/L5TcG4XWSNYOJPdm6FGxtl21DbegOsBEnt7WhMMyNc7r2YI
scfHuzDel+gCDpfLjE818DiURDdnoMPVjdTFFXkHJ83Bp38xz4sJwX26sBrNxC6Yd5/+iUpebqzS
IvQ/7LeqpMljzNMGkZ8KLsd2UDKDhDEbln5gg56isq5ycs0h0GIghnhTbJu6Mq9i13jog8g0o97Y
NGGwCuWH4Un28rYuj5rXSHzSxRvMQdCWKNCjCpZDHQZPf5bH/TCpBjHFtfM6nuIoCSkay+22a1MZ
KtybsNLKg6Een+xtEtfUPUVp+jnuuMIFrkz5E5tJ1xyNXp4iGNooYulgo7J3UkMvn+J8lvmzmTGc
ntryMd+8f0cWvFcCOwc30RD8xBtcTwwZ91ABYsjbmzncmS5j18roVHTqb7OwY65Zw0w0ChwvCnch
6s5MA5+oIA1Ur+EarJtDBdc0DQsUzpPXHitSnjikM3yhYFSOCauVx4hG17sGszIxzKPIMyn3hiW5
tZ8+JenUXivpg5fh4eYDQO2ycI91Q4HvQ7y/b4Cg7CrVGvpD19Or7Am4KvxpTeSJd4czhEOUBNFC
ce8Uqr2fjk5L1fHB+7LJcliNniMwEXSow/I5nb1bxehE/KJ1c0kPhU6DnonQz+Km8HACuP9hYbQh
IBRW5Ja0VLB1lRY+RCR9sSpcPL5ogExZzZZm9mw1uHnDxPXe2Aeim1bwcHVnCYEAowzfiEAvEX4H
/IDQmLZhZVjNdHxUZ72p1mOhnYEOP25ex+bjorofRtzMkEafJvOduA8o25psCRrB7biedCsrbXVi
BaYenlvkH9twlunb4OAoJhCKxPObb5YzwwAp1cBOuYu9kmetjBVAQjhM60m6iawI0q0bZkOW2g4b
rUXkpDJRFVliQyDhqZ91NhTTl4v+RAWxWJr8rhUc8+ajDDtu4Et2/GV8OyarpbEbSqhVzzOsjRW7
FDW8fqywmRoKXitGBhdJJfDh/Bekflyear2YySb3QaMtMKwdxjtyoQvXBAKNrTewBGWdLk/WQIzs
TtEPh+aDkBWAMauJ3xLA18JpEV3qqIzaHFHqum+9FUxOItlQs3wx775FsFrnB7VpbLZQVvjrN9P0
lzx5ADmM8UtWArxKK30BIehiqOm6GIX4nKgrem3WX0/LERFDMoyHlPIkBnLXmVGZb3KdgntlqhA4
BThXpERxsMunQHJajs+rt7TdH6XPTrgRdvY+h73NN2NJMH8atOZJxiOYszbjzeACC9/r3gonUZtu
La/S/G5JvtxsngBbpNLnfu5RYm8619JYYO9enu7lRuZoCXnD8jVoppC+gC892iGbD48OThYbBpU1
1lYkzhAXbIqlxup35MvAW14rq7jURl0i0ir1peyx2rL81tvLkiMwxeAgzGSF2NuhvkOzpYeakTaf
R6E7kmW1Gzn7OgB6W3KfVpcb7juj70NJNPqNWO2LSYl12cR24P/gZKI4gr8/CPSNNX1x/28rO3sF
iQ5tp+Hf6hGjQch2wxRTLn2Il/SSZ3NVinUiCCtT4WEhpFIq+bqR35Zf6taIsOdGj+zmS3JbFUYe
0PwE8HWGPwnWX4p6pXSX7S4+O90c69BY6/OwCkNTk6Q5T4v7E7IXPdwRM7k4kuYNCwVUj3VNEWcJ
xbGqOla25c8VOYckVhz263zbuV6zkYOqKGK972DqqviLMGpVivz/Q8dH8peutNh/1EibZubJ1WzD
ZFHbC5Npq44Bjq4Tq1he0mIeBLCAr3CFGCi5uyNvuQR/aCeZPH9GVTzcClfq8e4W4wjuvk8HOqcT
Ls2LX4qyJ+mZ1Xjhad77SEMn8BvdAghdSdAIgcAaNmTtAmLnVr2OnY2doCY7nj6bd0PdFUunAftj
IRS1vrzPBTN9YWnUYrPrfr/KUna2JH+jytt6/+veRubYvU6xzgmVy8k2mal0YxLDsMYw/FuphZma
Bc4+sVfzwFfRwVj8J3GUyuIJhBucUT/bzTV/egPCbQaKaPrg9qwr1mQND4U4MTH+b1xhyCtvvBXE
g9Ls8kXfwYeWRuz1PW66SKgn2DJSGlYEfIpL5SpYuWPRT6O0X5ugMGUST2Hm0D3HL8XJD6Z7aHPT
HrdCrn6MujbztSUuSfve4iauh6MxjWmIEvyoXXNzA21a9NapULD8wbVb3jjLtB157OG52FMqN8F6
9+UJLkpVBmHTVHdfhSi7SWSjS0EbHxcbpQBHEvpKvVuxzNCDZ9R2v5CSb1NGuwGmY/wqiBp9YR+c
BayIi0t4CmOGSrsl68fT5sM6GnbvTbcMR2KbDj2sgiC24lavdZc2Z1ChmJRoj7uV5Zor0oyl5y5E
lIqFfMsMIFRfge7ZFrylj/jUPWBvHvRVJgrXCaNqkRCG/8Zu3oBw/rqmyOf5IfrGUvXqsAulv1WN
yB/SnPepaXuf+ipoDJyR3A1erNkFFLWfvxxwUSGjJyJuRiy0ZGR2RrI2q3+O0MOnfExZjeVgqYuY
5TJWjHzkHjc1FnRfo8jP2FwtGCAm3w0SGWc9X6/7dfUECkMZt9mBXYSRlhVKKDdAMefajrdDLxYA
t4cdECPDdPzxsSc2M8tSRJ8CIrFrIT5xaiU+lbgZqF1U8SrPA7SsNU07zfLt+pfeqwXk5TcpCavu
8CIxJkWixk/hQnDz03+phigyM74nk+yRXIOy9vhRBrE9qaJ+jQhFFhRpovFXRtcAj4QKwcYwdmG4
14qObc9NxXjO5HeaZ4X2Ty1z2cZ74WyGuBRHol27ummc/JGtrVfRwrX0UmSgmSj/l9c44FUtHTys
vKZLnGVlFfaNEbcC/SN36BnHdrnmYZj9c16JgxgjHrFPxcZyvXf3YQU8Ck0rkucSU+vdmQBIf86r
QRNj0I9JEcEOvP7a64thvRM7Em4fU+zz0xq1bzHPwopSsJVQiuUavD8qfSXIoTrBipcof10x5dmB
f/Tf4gfWkNV/vlRBEPi+VnR9n+5Ra6caYvu71+BUVDNw663bySnJCisWjx9GSC8iJFBFOAhGBy+K
ti39tbM2HE3SpoNvzRCH5691WdsHt5qB0yab6PhrI2y+qBkjYDkQR7jWiJdoxYUpq8Np23tLjeiM
1flTyzdAgolNL7ovxUwS18vQ3zQvk67mxDLpgkXBoRXnKmjUbuNDkg8wcnTEHPiCvc3dWpGYVJLT
LfGZds8INdNDepYhvZrPcFIaDPHpFxMcXyZRlFE6cxIgOvfnUsGVsX5UfzldG3n2fH1rvVDfHISA
ibNCKwCygShNrKWgzZYI9KINCYlzfDaTG1VKd95TlNfEuoYhDXpytNQgh3A4zsYgQTtXSnqQPVbl
/shjwfkFMeRYtPMo+04UFd1yZYC532Whub0DbPNPkXe/XJyW50iqSYUwIH3Bxs1zo+eLkFj99FlW
b6f+Bm25qUOjgYB0WVNLy+gQ93gTHEkRhNUyvnSYv7zMYwg44inYlS5B/p6yGZ2lS7XAywY33eUX
Ta9KwPVU28l9s3CB+ej9g1DK7a79gBZSQ4yc2XvgMPdhMx8U7pA7JoTjNY7Teeg8ZJRdSZusltEU
3qMa/HLp3351yI73Uh4NR2IYfdidSIP652oKMg1DKUFtYjbIiW2DKMx/o6rx095uTlnMXQiDPm2C
25zkVw0VORjgTOz3LkT4Urfme4tvcBuOGtBKGXisEGUdlPjMVyFRmGQH3YSFV5IX67wVDn2B/eju
dpf0sYiToprY8vLczvrFOUt8MHVcdgaSmWn5Qpu3aYKBxXCpCds3x/21iHWHEXr32wZQd/efZVwU
Y3vDll/a9Y/3h6i0Q9kzd3JPaV4n7ZW18Z9J/5rbQQQ3PG5zpg4ndOfzs6kkUwoCgComCJbfg3dX
zDbqhr9XnktsaUaQ9qvADaPw0aYKVbkm4/SNHxTLRWmhpQycXVFarIhfDyEeFTtORgc8L/rDVdFn
d6y6VJPseEsisXHw8xPl4LI6sLEam/sTjnnjSZ08V9b5G3+SSzmGQkap/RfqI05ASXEKkdU9OlxX
djgVbMe+ZJYEfeHz9Y4EEu9wP4w3pVS0lCn62vozv6blH0QOkkwFcQvuRuUvsVx+dxWa/9OjjJC6
mSYAaLPEwl57F0CuMmByTtod0qq1klcKAuzcmsk6g0SIW0zk9lMaSxsN04RF+49v57jwwTIh8RtN
WnFVmGTh5vdPR5FnvNj4uX6bj0vVKSXGKX1W1BCUeKMfpkN2Zn4Y4Ghbo7QaUT72UdJnz13iFAoJ
mg6oN7ohmz/2/kBkbZfC88HyGfOwjlVm3OsuIHtNZ7+CYGuTOjDI7xM2HOCCSAGd6KRbgYHJ9EK0
lVn5aDKnWZ6EGTCvjGYH60MwImsgge3cQrvm/vbRkS62Q7NYMdlmvi74BdJwo6ENZW5kc3RyZWFt
DWVuZG9iag0xNTIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI5MCAwIFIgDS9SZXNv
dXJjZXMgMTU2IDAgUiANL0NvbnRlbnRzIDE1NyAwIFIgDS9Bbm5vdHMgWyAxNTMgMCBSIDE1NCAw
IFIgMTU1IDAgUiBdIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNTMgMCBvYmoNPDwgDS9EZXN0IFsgMTk1
IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDM5MyAx
NjUgNDgxIDE3OSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4g
DWVuZG9iag0xNTQgMCBvYmoNPDwgDS9EZXN0IFsgMTk1IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5u
b3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDQ3OSAxNjUgNTIyIDE3OSBdIA0vQyBbIDAgMCAw
IF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xNTUgMCBvYmoNPDwgDS9E
ZXN0IFsgMTk1IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVj
dCBbIDkwIDE1MCAxNDIgMTY0IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9I
IC9JIA0+PiANZW5kb2JqDTE1NiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9G
b250IDw8IC9GMiAyMTAgMCBSIC9GMTIgMjE2IDAgUiAvVFQyIDI5OCAwIFIgL1RUNCAzMDMgMCBS
IC9UVDYgMzA2IDAgUiAvVFQxMCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAg
UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTE1NyAwIG9i
ag08PCAvTGVuZ3RoIDU4MTIgPj4gDXN0cmVhbQ0Kx20iOlmskfslrQnDyuZ1WyN5+7ZQXAKTplDG
rEes+rNMN1cEWxn1inFjboLvaY+mJiAEzJF1gkLrixo0LpISR3e7avGph2mYSu/nBdv6Xv6I6qfO
eGr9bcsXzE8DvB3fR9q9F3xCTXs2nTw7YLv91lZO66QJm2FFSyw42c2P10fQ3XRdhIZQbeIeeBkK
f14vAe6rhyokkH/Ao7Pypfg1dJdWhKBhs2prXm2m78XbeRb5RmlhBCnKdt+N4Rmg5fnVl5jlbb/D
rbkrKLXGEMtONtzOCBDzb0Avu0g9qxrTiIIuDAGxt5t4YnbEOslNJv5hNLetaTdbggthmv4C6fkP
uuBZUyIfwOGBvlBgoP4BYNkwFjNkpDC3CrUfbaxHPPxtpiWGN9naDGXqkDQ1tz41BMjOfZn76F0o
Lk2MrMQK2JYoxAN2e5AeITWx8pb5+ATM/d46bGBL07sksnxLYQZVKc/5RqIJe4pULEhkARTLqNvS
CHnRvyiyxs1dx3oYRoj7KlH2kbCrA2tfPltj7JOC8/A/+IT9YwqklO6BPWpuui4A4dLCZcOF/X15
pG2AGkn/YuqRpp79zx9cZGF4YLpEs6iDHIIObQpPrkJQwoLz/rVj4VZvqw2KnwChuiodU03E3rdM
q8hvAz5jDL7jq4IZPLafRND909zjk7qaOTa/qQsrzgof8H2LWSfXz0K+b9Byd5OO8ekasAh3uzZO
/UmrCflhW+2UiGMOfLQDC6dte9x1rDakLHWKIRJly9ObFElX4gl8au9qQNK33/tYc5nATimWlei1
9SnVrnAvo9YD/wAzS9ag2KPn1ye1alwEzXOAF9mBNzGfK9fEhah5Thd08/9egMYm9WT8d9d3zaLb
Cj7f8S3sV2gqIo7OOBa85usJibozvgqM/3apDWAyKJGFrgWBmGa2Yxjr8X+YSb8SIkZwLwKhwZI3
TunSJjS9mczYBbZ6JyMlMlEZO6bbc9GIAMzEjYesYfigJNJaBzS95B58x+FyY5zMb+6q+EuIpNRi
aoJ4Z5RPCI6rgCaNYHFrt2ep9PCMZO9gkQtp6DNQVJA4DGAQo7P3fqx6XGdtUZ1eOgp84vBzXClt
lH1WXHepvrnkpC0yBojXyhCW+wFjqlkEgZ6IT/dkkBgVHRnZI2jPHCKThEF0UMFYzWzNJsF6EeSd
J5kXbZJVtAbMZCDVerS7gq7lzDIIgZrIhFQDhqpoaCc3QctKiDxL7EPUXvIPYpNXUjt7BI4AMoqT
HXT21a1W0U6NzDved+Tpw0x8H8cHI1R2GcHtPs8xLBS3QAyCmwYs0uSdTyq8VJ1juivSQsEAzuaI
kXS7/Qu1bF20VC55hOUsUQ8MSuxVQ6WPeTkVmK89AzDMMvv/AynNc1+vUVakueUg93jKVtL922On
gU9dTq7+329jW03vgw0a7CHT1PeRt1/x7aondrwdrcf3JwvqbDUqJppabged70HT+7Xc+tWtAd8s
fT2t/b2SdqU53bXWi0ERVILqRQrNb+6Bqwph6/2p+HVUr1F1hw70l8CevlYCADTBT4eIUuraRZAX
L+oB9GEQoBkBvnFyeeX+RgpG9dyFDuW1QFhAi8Pras5awvc7PnZ/glo4Z3BX4mZfQAu7wA86ZsCk
itWUprt1WZutW227ulVqqeU7DIvgiiLju2CMf4aUjvcXzwcN+T+Z9TTErrtbEi2hOHe2cnpoRv1D
wigC9ke9VGPtk9PgYuriPdEtgFVSgbegPFqkZdfl1noYT6aZ3lJSxzWeob3qNvHN6Y0QiM9e8p+m
2b3OVxwar7jmraB5XmEgGL1j6dW/IfM4GZ7kj5H8I5jZv75MEQJfi9c4azhY4FXJRbgwOcW0usE8
1DfA4zBEDty5FxWhsfeTzn49P1hx0f83vAdpCr6NfWhz/eJzfLo1rME2EOBb1LIPgdLX3OeAStNC
8HOFpPZd7oRCtABKDwn0vwA08huPto9rzCRuqZmHnX22bcdE7i6PQjYti78ZFcLrcKjsI22jl5k5
9BwXhkcyaiwrvTE9JkD96uMuF0BMa/xx00jdAUCKzhDnCNw6yT2enuL9ofY1BCu9qFADLGoycnj6
bpEHWb6Mp6KtL2hhfdvXEree47fSFSho/8E9P26HTWUI1jagxQ6susYI+AwC9la3YS+oSQHiYZto
hS67xri6TFV1NkIfQ0E7lGD5bf9ncSBO8r0jMBIYJ2vL8zFixJRo5Za6AIp6DUnwIutSI02YutKn
qmfNkT9zxUFa+wz9LBjy+BKmjO8UbqjOHG4rLPIP6caLEWd7S6PY6F6kobbset9DOQzoHoRJeYQd
k+9b8gAAp8CwsmSvZ9AMzn+JKgT6cWvmJj/O1XKW+zlBPxc7bBloFrbTbtBGuELf4i2L2IxWhQB3
ytuN/mB7Fent/15ZMC7bTb6UZ9Jz2eT5cVnLmtZQeGVRJcTxH/1kWDxwBoqru+cck1uGyQwn1Ycu
nYBQqRtXGlmMm8LQZQKChqa/0ZSOcIyjlA1tC61/AemDT8gYNAOy5siaEc0Jo2eK5RQRfbnOHkWj
tqtpcanD/j6QaaEKfJPIYa71Hp8oOe6M+WP4qLj6Us6VKDqLewN6CM3kqIyA2D3WevYIdmtBKslD
Mf5zezbk+EIr+VtBpGV27JsmadU2nfEDnPINhNAlmCFWoCNQQiQkHwDmAv0biy3Irp+lOzpR57zz
ILOhz1b6oFwdMqPQ0lLusqTjAqpWS4fQXQ7XK6Ew4mQBIFSEhHE+bqGsT5vIoVaJcG/kTnk7053/
FJB08qV3wlXX9xBxXb1VS8odnTyUV4T6otnukpEnT1DAxl+8Im1f+Iu/UNbG3Ip4oQ812QPnebq+
IUuqcSELRdC/mwNZ5gD8hpJh3TGTn9kO5NIcqVfadR9ALKlcQkuTYCtyYanjg4ah5QdCEzcLo55N
HRV+F7N30xp3T4dkhYLUw921JVFUjU3mWeAe40/vAx8vT46EK2OutABXbOI6gntGVl+jhbYDY1Yr
FnyFKg/jKUFP6aJPqRjq86aTr+n9xsiR5h2YmVzn8N6miyaksyh9rmjshb53L3qld9baqp/Qw55n
Jj8jkaxpoRgPRiALIiS+6C9SJIfiXACrWat3N9VR4DYX1/f/Wko88z1XGzG6/lTwFfpcuDCGSX8V
MweX5yqgPTjbgylYxIPOvjtVV6DCpTpbxkxCUR0mccJan7T1aEA2Sbf7LqE3rugJ0o86HjL3+cLT
4X5lSa9Gk7yFSEDnlW2aqyTqM6WOhw061y2cpJ89PdSNXsnoDgRDnKE+ixHXqYAFwspWFaRxuGZV
6QDq5cQmxcl4xKIWPgy0Prg6s4tlzSpNJVTE/rp5i82+ZKjV1zZ0dww/dhsMEt4ru2ujy2P1etxw
oc00qGx0DRWHQOfU2BM9tcg5/Ziv0uU7CnKVrUJECXACD0CorVtaYnh/M3nBwXbPhUnscqqXZq/7
ffilCkNDyftFAgkmmA0kjiGl/VDa2YljO5/RYiILt4kPFSDSaO8szS4sL5TNmgcxH6fclfZEDYrM
KJwJaw57/JbSFtIdOo6viFQpFzy1ybLOMekZVI9qmyIxbNkwcA1el9hazevI8dOo6vRg7Z+LBYWV
bbjPF3purxhk3pwjPNN46JkXHE5+BH5aBJVvge7/FzK2zAekPzIqa6mexffCIEvB3JykLmR9JtMn
jwGlUtbHOqdBBR9y/4HasxpHpGmqSbCqFagkY3uc7UDOGzGWdeF0I/G5lNlmO6tYGxCeiM30RLgg
0KRIabwfzYh/mSDJPMt7wyHWB6PWz+uNEENRWxews4X+EBVvO1D0tBWvVQJqZMh+jsB9IE0Rs9fu
ZL4dptyi4UH1GP84V2F8PLzua07/NEoUBNtU/ogA5bRTWBt6dMzM3b5rYcpCBPLVwYkK1jI0CaYi
sKWvfvuWKqDdtJcQDqYvUZ0ShnqrI7OsPut92zLOfCQ9+K8293cm9Gl3TjoRoAufzAAEUSK3C2nV
Y21t2dcn8LlGh438PN29eiomxTlenwV5o6s3ow+QUOQh4+zBpZH3eW6xN65vawtIylgejDw5bJ+8
JF+/jgrb8LtCsK2TEzXU1iarqQC9RWL/ig85hZ9i6UNMc9Petp3zupeoh+3/3kW7xvykfcoRFXzQ
rlSX4fdU2J7tgKCyiKsgmrY7tjKuj9iCSXa6yMqWYtjqeWFbyCc1QgU2z2pb4fI3cYCvdbwth3H2
4L8KbhdRkuqu2xbi3UTR4+3EO04JQryl59en6BSTfUs3ZLNGeWEb/EVS2GxeZBGn/3H3A+dapR64
N4tsndyPktNXuS/yxzKCLLSThcyddLuHWY6tjoec34NRZl75mIYNyqCFbjwadJ1FqUTPsI1+UQ0j
JkYhOlKMvtkk40p23EZ5vMBd7DSM9zZS2HV3t8swh30t2WlW5ZHFQZL+T3oLmoym/BWgFUB3B6UA
1uiUpPg16WD7v/NU9UQTYXcGGwpfgSf2JsE5N70u9dt+aCtIt7XNQQ4tjWOTSLNQzAKC25ddxffR
1IfB2E+fDI/tmsOhoYorq+5JokrA7jSsWWD0/BTvsWkffF7kHy2G+g0VMc9C5tYWeK5t3edFavwc
ZoziYxWg6XEBmCblCUxWGaSJlNfUP28SNMK4BnIMmtc7qcWOlmVXmN7fnQKCvv4YTE2IRUTlOpMQ
dbRMC3jshl2W4JOQJc07w6to8f21HhoiJAkAtBDGj6M/VUQp+A2idtXNgPkvq1hJcu+Hw0P2offe
S6LmOhvXu75A7bhtu1tu9pphCQpZ02qBkI1t8GoEfxEIyY5ibna/U/q7QtpuZVGFXz82qmRBnHSA
H0mxkHzFfPVifH6cPTmS1Gq9jVaaQGHBVkGQnhyAWLbg84ucPE/IiqWsgIPK9I4KEeD8tdt7WiBd
NUHXETz9Shk+cOdXqrBdSiiR4zymlSnOwy6CjlQ1AoYcQg7xYsMJt94WwCJ1vRWq2oaMANjwNbp4
Yfx5m01tZihWkJ6/gHR++BBi2C15bBpXWgNU3Lx7zSoy8AHP2IiV4sTA/tk7pOfCnoXvpPXI9g77
hGD8TsmL+n15APuB3T6+ZLI0QGCg/Oej5x5c7pVSOlRPyzXHOb5H5FlgkA1h/WgiAPSfjfEW+mpI
BuUBdsAp68Ch1irGgq5lt7R7f93usGu17dZGB6bTtk94DrS04Pq6NCWVjy+IejJViW/mP3H3gjoP
1IHbInQf0dFJWi2H+ozH5tVZWTvOpVem01U5a0T4uFn7FGvseKo6dq0aEONbIRlxQg8qa0U+0D9P
axfUEfvZdpZevp0yTYDMt8iKiB7yrrt6Ck0DpYBijRqVwrdJOZLrIoAS4lc/4jNHWrLBMfvbX4N9
uzhQhK4jLOGMbhg9Dif0zqmffZ+lFfcgx2mtRYjuI4/I+yrm3egGnc6Kcug5V6XL2U02HP6+XZA0
z9b4sH40ZZGJqCt+tay81YFC6Na2FQ3CZh7biitO1TLLXooqQqbJzLu/6SkdfeABXgbH+xdiRY7j
S4stqghHykV3/KPkwy9NPoQfkjGzPMv5w6laudrDv7FgbLE38AwG8YzcjzY2Xtu7wZRJJ1xxuALC
YxiDLXtsK3OD1QtBzuIFw/kYZze3euLdKCqZ+juI8U1uwDb0fpVDQkSTa6vXxK584B+iomL3UJXB
snfMNSMCpFWsA8SZlLJs+tUcaI0FU+SgyUad9sX24Ewbukd9xEiGGZ6v+bi2qrEAQfzZ/OqHWamh
nihwkArxUW3eVma//VyGnwtxpHwzUOfiH4Ro2bo9s1zR8y+kNw+V5OLChfBV22o1qjlUl6uzH1tL
L7cFsfEszpIhnIUIPu2up72TXSAGCJxyr3czKDpleSJEXz4s+YN5v4QvdGcUxjJI+WYT6qPHe9I8
zQvLkg1rnHLT+h44U8Uxu6nHZWB+QuC+b/ptoY8ETRFnjcLeeWuK+lczP5SuRDFT2N8GQp45Kk1J
eASZe7SakeOE0HRn6i4BELPJNH6zXJUbYsroCyv8LZOTzC36xoWt/1qiDk/itd8PJQSOivs03UHM
Zi5X3hkFg9N1MBnHYW3Qb1nWoEqrh+zRSGWX1uZwHXK7l3jGfOIsV6UYvykSM1cCeuW3CJqR11YB
UBpUB+apzG7c/EfEJfqrGmqS0rtQXsmPI75a72j0o+KKNmR72ikyX/tg5n9MhkeHJJwP9SyjEhyy
i9TgXRnHKAPbRcAO7G1h87ZjvKGR3MdgQgAA+qyCYskdAGpbGjFmOq+dJL82cOiTWCs6CUkTQRuh
i7xOczFyJV5qSNBDZ+jagtcnVN/v9SkQ1ByJmPOODzbEzpqx1ozDIo1UvQYVIOQD7D3nt80ZSRp5
zRy0dl0opG0MFUothmuHXqLMDobA2B5IzJrDp+eSMjFYwavFSHitNbj+kxlKaLbTNCAg0514QzTt
+enCKINeZnQCGlDVoxvT45msFa685FJ5tWC8/WlXKW4uQ4CSJXuXnacDNXbYtrksVfhvvWleCd7x
sn4eF5xBnvIjtKLRNd5xVkCTQsq79teiucWSexzkzcOPnAPnEmAnIAJ6R7BFa/N2dzukULJatt/P
o5cVc50lsa9xnTCLwvg6KOteGrZg2+4Xio27T8mOUp6aOejjXq4bv7WQzZIy8zmfo4H0YjkQwkOm
mUuLSqZ3+cxGdC0MBOWE83caaI+1b2Le/s/zup9Bz3qybGjZxdz9Bw9suyBkSnZDm9GPns3Jq21s
Mipd6lQEH4uB/EGpCyXgDD6NflT120t8h1rxYh1XXeLNaugdIEfIXU0w8l3KJmsYaagAvFaFrvYT
Qe29rE0G2nY838hZ7gyY8HEVyTs7SF9Ta3TpF/s+JVSkUTozCNlK9f0Aw3r61Hn/SgxFMw6HB5Yx
LmmnY62PoPn5B+cofymt6GBpAMq4I0qPZT/P6vX3vlxU3h8YwTBXX1PhzfZRyJoTI9jJodZ0olIT
uUWRjS//1EgoOYFve5G3eNkX7Oi3LPljwmEOmZkc88ScG+S9Gje2OZsWx2PdBUv+STR6Xp66raka
cC+SPBGaPigq2EtEtcP2kjJEkNQE/qMZxTKHum5GPvTtKbL9mXFuIvFSNiPueCXNcADiQT1K8N4t
qSuuNgqv638S0hy1QJsifCZyRKVnF5CmZeVp/9SizRI1PULO2PqBgHNGPRyrmq/3RTyXGdn32cNk
LQh3xnKnjeLA5VKo4v6NExqT9iP2cX8ADini5z84GzJQSVzNuJtIN2XWz9Dj7Marr6toJ5SPbgbW
Rl348i22bOmzqOH2W0M8M+1CEJi2RVjyqBgC6n8M7YZEDU6PsT8jBKYI/QhpgSQiCFYHBXJPFwBx
nFgdHeDVrso85XMfCqjZ55v/gkHbNsaza3XSc47KmHqCC4fYNcdozbMULzqhsg1rBQAJXHpIl7DW
iZ5PyuUz68zO6WkJ8SHVMqo3k54OtOwh+kLFPiWBscdwbJNgbVXvAPVV0D3e9AGr83Nr4LIhEoz8
FYavbjWhVOxy1vu4Pg8tPdn1YzZr8m2eiq6NOg1Yr0jwccPHVGxAu4vAIJCIwSupLLqX1ScdK9IW
Q1EIT11arLFaO2uxM95InglC1NvBDbB2pdC8nAz+J82oHyHxKNFXh+Lolu+9m0FWkXxFJ11vWKB0
9uL3SaobNgh7kwb9Ztbj4/uUCjGNFVX5QhOzjGC4JqSN8oL6IdoGPnLSfeSovMkCCoW0Z6Yae0n7
nKyPUwNhRgHbyWiM7P/ghnyfu/bVBTZ0NUz7hw1lbmRzdHJlYW0NZW5kb2JqDTE1OCAwIG9iag08
PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjkwIDAgUiANL1Jlc291cmNlcyAxNjEgMCBSIA0vQ29u
dGVudHMgMTYyIDAgUiANL0Fubm90cyBbIDE1OSAwIFIgMTYwIDAgUiBdIA0vTWVkaWFCb3ggWyAw
IDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVu
ZG9iag0xNTkgMCBvYmoNPDwgDS9EZXN0IFsgMTk1IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3Qg
DS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDMwMiA1ODIgMzkzIDU5NiBdIA0vQyBbIDAgMCAwIF0g
DS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xNjAgMCBvYmoNPDwgDS9EZXN0
IFsgMTk1IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBb
IDMxNCA1NjggMzc2IDU4MiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAv
SSANPj4gDWVuZG9iag0xNjEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u
dCA8PCAvRjIgMjEwIDAgUiAvRjE2IDIyMCAwIFIgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAv
VFQ2IDMwNiAwIFIgL1RUOCAzMDggMCBSIA0vVFQxMCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8
IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5k
b2JqDTE2MiAwIG9iag08PCAvTGVuZ3RoIDc0OTYgPj4gDXN0cmVhbQ0KMpTqL4rt0dDK49ojIepo
9N0ErTTaShmPF7y4Jk9LjgKUWHy0uN1VqGptooSYN5tIqYW4M3P9XmciqwzpolNztQAQv+QXzaLp
1FmS9vk0ndKEX/5vFLdmOB3VAMABnpz7bcR9UmrH3PNEoh2JQUf/by1beB9Jd1YBMgVJHNVizWYq
4498ITzLg9u6CyDcJwLJVtiOtURRf9Lu0yoqOt769+wBf76tlIL+gVkTM0kJrRNlFkLn4BXBn6/O
qwUvxwquJVSTyIqb+KB5T4k29bR6vAg61kn1Dxo9Z/ppzPhHMEr+GSb0QzM5eRDbPj27MePTDn59
DIGubHmDZ/9AeuzFI5rxGSb/amav8cU1rmxxTSX+DJbpMw4oU5SeaUquX4D55tAhbuWmXu72uzuT
sgSPa7NmTh+MQOADYsnRxSPIlTJbJskqZazRkFTIzdRCLvE/WUloWr0qmcPHvGT/WvbgJFpbcFEf
LQsvy5Q36o+C1VCzMPt21txs9uaTaXTpjfU7bmBJg8ZkBzGFXGVGujR/0geurMla329a4Et4PfAX
03dDtIJqkvMHg7m66UAo1UM9EQVZ+4xxfLonrbw9dfAThJSdnwJ2erMblasZkwGLhfJMnPjbH9f2
Q8bSZZRDfCDr39y/Kv7MDuHneK/KiWZNkkBGCiBTEhPeAUVr2iGxdGNjkbs87pwVKYqWY/yNXOiP
O0AfYm71YI+Aq2kveJqDlU+nYYEnHo/9TsO8dm++4m74OAcYFU4Wb1mGeHlaeAVgy22FnsKP3u4Y
BY316RfYvXrY+Qenu+zFWrbOvxJR9vsa6qqDla8PI7yUP/y0TKB0qnDufwmun5TIw3ID4gywrqep
fSf0RM37lJMmMshlFSDtdxVQyyBzC8Pafln+OVwV1d/0Z90t/CK31LSR/RwoEKSrDPuABhNfr1S1
BfBs/iBS3qbBDVeKjevkcPdIJgJjLO8I8RY3phwrBTbuI6qJXIL878p/ICHy7FHijfQGNkuuZNcY
r1kGjR/JOAsOuM2/YQfIIjaqX9iEcoyHI4nLjj4tEYZQv+4O9iaXWP5q0YGjiYHSUlZqZTSRnPle
ZnolZJLMYgi1s7mkV8hXJXAN4AnUbtBuuSjAzfKRSFMb/ExC75S6EKjsU6YKEHMycj0dZzJxUddI
kSn6wzzcXwi0HJqyVdKndGQXuQ/vEQjULBLej3BdWnzyYMw5ylpIYndkt7f5lSyv75BBnpCgzi8o
2cCd8YHDrT7zO+PTkrgNAMkV+BI72/f72imP7e3kGPJ3JRZxdKUixjMFCnRYReqmewzbDDesUq7O
eGi9mH7jYngXETWEgBwi0OAHAu0hxK/3nn1zHg11VbMiI4dkWUhpz9cdlDP3hAyuUbp2arLktLZS
krwhbMjrZBHfco0lYYx8249srqBRj6DPzUPN8j3jrMZL+qW82QdvblOao27zN7SoaT/RQL0/xJsj
ntTFQqvP07YLc7F/ulav+czSlmWmbGo/KU77FpsmCpvanxPTX3wgMbr5SkJ7ai6KAAHe0kadaFpL
DefcapBeKngBga68846FIXlshffxmgGVc71TiuVnk1Y+riXMuexT9kmOwZcgpVLhAK6aX5Otw6Dw
ROP7S71sZ/XyKAf/jpdaSnPAT2JZfLM3Qo/G+9KzICMlaECfPH8dClU5OUZusJ1LjJpgpj7U5UVs
MKHDws1TDV9Svz/ZI7iQVlZ4u1pPsqiykCQ7qo87PXZvLoxOKQ/XR0VXuUlRExBRXw/nnNQIJKA/
I1EIexl0r+8k5uqwHhWSIDAKYklizT/JnhToTU9NdvnXwYlJYCTmMIzzDdfargIvSTf3LaG1OBem
v44LcRmgPLLLkk5w5/82KjrH+UaiF9+YRAcdD82leHKuKFnt9JqkQLVYjtnYYwvsFGNjPja1YGX9
+SLQ0tqfU5zaM3pJbetUqCdOuhOAXSnO9OF+gE3CIoVVM30vSvqPvsMPJ3dm6Rs4RY75iB/ascyZ
uJVqcTT9C4ejMWThh0HAjqt8+tghg0ZiTc0Ol3YlgKQL0o/oqMqEoBDEiTZwJNpuuY8UTg69yFno
k5XElq3JN5im6ShXJEgcjSu/H1R7oKYYiu6CphtXDm+eO2jsR8Fi6kUmv6bIe5aa8LTyYtrQrYgz
EqGcbTmEQ2JV8+OiiucARnFUBtxgWOGinj2+g6bVkgb4S0PNJZxvMDGVn2uWaChejHOVg0uYR/ov
Yxi89nx9lKjbgfR+Ne04zBGKl7Ckd7OOxcsYJuqsMSzgN4VzQjzCVE9kxJXEg3wft940pDyIcyyJ
vFyKh6g6qh3IB9q+nCFliCxh9H1rY2Wii4toq8FmnktPI6BvmaQj+uMdFIjP2D/cuGW0emRK95jb
fkoxeYx9mi15aXV2j55na9Si8PBW7vG34FA+ilJpSvaWSuCWR1No57XAbt3pHiXtQVf0Q+r1z2B3
Cpq7qzaUzjjRdGimf0keDi9HCqcbOuewVidp92hr1Q+GDsqi+akT3b+h82qAAfGvvdkTKunxJYUJ
e94v64zPdOnPSaRnGgbKfqzd8vl9j/IGl67OTYH8VQC3V+UW9EqtTEh7dO1rkKKSwk3i7j9MBBKM
JDWL6g8y7q3JaOQXA979ZxvJo29M6rX2XMH5L7xy1RMCfgpDCyugoObGJ62AjWZ28qRXZ+yyCCpU
v0/j8X3eQL0kGviDHh1+sKeEJpjk/M0o+eJIswx+vvn0z7JyCZxyw3RprQqgLpyiVsWMILzVw0x2
5It+IGOG6SXS/AU6hGvcefhB9uqAu0htvgaosNIAqrWPMZLZrvF0o4076vvO0o+85hdNv6F0nXsv
YsLj4pO/iOwtseMHKUh0zSAH/OtgQRNUkgUKAXIyC/jHwrt20rM3S0tAzo+TjVqgGIm+VTevVr3l
3g/g36+zd/wkupPBo3N4IP5e700S1L63P1ZCeMp5yPCkund3wdMFicvZDzfSGk+FSFYlVsC5I+wW
NjT/MQVh/gm1+Lmm5Z0e14hHFmU3aZ+8bOBV6Y2bSOLD+LrX0BbaQf/ijmA6jDJyp4V8Sn7ZtDJg
xllkybqKBG22+M2PQVQeaELuUEIMbcn3tRwm8817CF8dNARgkanTU3PmbfSuB8V7Xx9E6ZBjrBV6
iQKezi1duoKVXEtqkEwqJUyfbMKXeQYkQx6AdNXHqOoNNLa/fJ0UoW4fykoD7ZjzCJhF6lGRWnSm
wQvagVJXCXYGERfiRABvhB8rcNYjcmIHOWoM1NmwEjFGJswapM5nG1QMa8OGAS2haDVdU8qgt2LP
wJE26lXkqIfya+dOQZAUiJkVplIdbKkFS341tlpejSOGHJ063AGLLGUAADGFpOwmRi3QpaS3hRCe
VLIyOBwm9anoa0Z//YxSqogCRD0iK7/WpoP6fCl8hkZQGpdqMeTJCwBUBGTW1Bb4DzkpyilvSTea
VCAKN7q8L6O9pO9/BxdxfbLl3yYn/J4L5S1VTtb/f2E+XoKCN101JrDB7g33BD2KeWns7GKs+bvo
EACpVajNRHb7/DJUv8uDv+AaFLXF5/HcnXdxMIu+DxWthwubkL9iAijBQ4VMfdbzULNFQlSBD/CG
t7pxeaSio7PhfznRgw4UYH1XnjNyOWAm7BCCT8kuDXhyOp8jRM2VfNzFADqsb8jXl60tK3uO3R/G
Tb6VKW20t8DbiYdxWRIBhmhHJeEpaMZnaenAyfc9F6yyhPBG5EhjVmgVGcyFyMI3om9Gwy8EfQum
aEFAte3VQ70KO9yYO2tdhxJQ0Ol8rvwSCsWiDPF1a2jGDNaWcltKXYzxl1mtgs7mtRmMXLbcXfDr
gwrAbug2ltje91nKkeVP6Vtw79T0wX757EPIB1yUG6Z4NjRjqPtS+U5hskpjlvy+3f2365D4pCNn
3QmSv+kMlD8+SzOyu/potUc7s6b74UPYQ02n1VELmHbMGg1ZFAcMKEQlPcwmTkVHZ2HZH/7bqPX4
060bsEw4QltYtMATYppG1m6vLOoDlvmVY7EZ+WKidK1bFvvLXvpP4hr1lYJJ9xvbieYmzsoGR/gE
BLyp3yo70c+hvapAt3ql1keL95brGsosAcZ4FiGv2gP/sFCpkqEXuJaW11I4dB0p79rjaxcPpNGE
kMnXVMj4XKYc9c4s3kY1sYhHV6rRMSC6+zRiB0DpYr3sE4fFN3Dpt3uncbtRl35knZrpPHMf1CdQ
yf+Q4c7lJSFENesQ/f6g9dU8wUz7AomwWmS86Orn12wbiXlyFPrKQ5qzsx6+KPfkKSMMYGq5pBTN
dfJD7geRtmTBnMZV11hpZdpdyon7bjFitkAHhf3GYC1RKqY9JePNbNVIhVA8334uFv4JdO9yYKgW
PFL0p1sNyRAtBG3+LB0COJxW0edAFfjTbRi3+wyGk1p59HOwM/TaSxjCeo6EpxAPDXQUGWPari89
PtWJtZngUzE6L8gvpf+A+ZsEk1V8RjJxRgl2IavEpZaHl7uICd4sCxObDA4hCeMP6Vs3szGevvIg
sLuewCLTZXPk1Lh+IPWRlEHOnXHFKux+o9oFoN9+QRH80wZ0YcodaPSqrTyACyICc49t8744xcU9
vRRF4cRAfkEk1fRjvIUOUlxwbSjSyTNXnofEeQXFl18H+4x0kNsj2GNMkwDebrEzZOQKN0UWh2Ca
QwzD0dQgY8J8smthjEAavsQOyYGTTc32GkWfElLUhnchQn22G2rPuTUC2biuK/YsKjEDA4Um8E0C
gqGW1z9KcSowNLR03eVisWIyXiQkVnOoD7/IARMaunN5P4TLiI64ztNB0tvwBNV8gQrxItnSHHAj
09clcpzO6IjK3UQXO57v3Z8hxn7ys3GLWqRvRMXCW5x9R5teo1m7Biy5wbMdgR4ThRdZsvDM02Xr
l21phpmLUpnobxcsoVHMCsKU7vOZj6wp7RG3Y/gWIfMunOEnkdBXxWu9Z2BSov4pjRu2EoTjdQXi
Vz6UyN1+eSURER29UAzCkLaxR8dnc58DmAG1zltQcMjp/K7wnfspfT/FSzY1OAQmbAn9Z5vxhzVa
diR5TZjZbBX/3KffI+i74ijeRRW+7C4MKRddgIpbeYoa/OzXad4bU5GW8vLGA1Xa3rOQYjw/ixN5
w3WMtmGTW4sG2b1qdjbfVLz6Jrsk14/QmQGihBQiBv1hninxru7KidRHYVO6cVEb5CYyCAjSyobp
hms3y452ourdo+6gYVPt3r36nnpcFKF4FStknSruYyuiUmsuPMLVEX+ucwKk17VpUmjHH/34nV7h
l+YD4rG/d4aVlVpgj4X63GaU6TML7pXq9hAUymkeyJhifteAP6OxWxxolGBKHjjt5dexLufwBtSM
lHYeAl0K7xGS6aEhK1xmUAm3L/dhZ0DUR3wQHw92195PLkFaQWFovLGwvIgCMSl207xj9wCEEAj9
ry5N61uYzg0Wia0XLo5ipypd5PG0ay2Nb4nTxbi3CP6ZBT4esH3/DASyXjTfvI2o8IAmnvFCEH2O
G0fNTvvrQUhKdZSq78KeAYOzRZ12+Sr8Pkc9frfmB8XPhkmJn7Nev7EwTFarN3ik0/TjxVU0shdR
eebTjns/XqP5mTOzFAd8/P2dFTDZyE/zTGmpITnrKjAKxDSzL2M+LMEXs1tOm93282SAH7+FZKBa
lHjFSqV4NPAcYcB7IGPqJAzh1kf4yUdazKK0iDeydM218qWrGyWUIl7VqsOm9adwNvWWCeow/Qr/
r2135iJE9eoE76gDsh85vo7rwYq6WeyyKMKLYEG5LlFsczk2Y09d/jSHvmv+ZkNCOHBKKSOsKVN8
PnOIru+ofdK4xiuxNUTZJIh9qCx1+q0XCIbYaOyNGHg4DqkoCBe51nwbDJsjz9rrYf5Ys1oq4Urc
C2We+LNxtfUvvAb2dHa0J48coh/ad+lrIvsTslli+KxldRjx6TMWpmQK96GuWvRcGaTcuaBWI+lI
GI8/Cm022x0dP2mmeVXzESml9NHf8bGCag17OWEc4eLrs/SlKCuAJTGb5FMBv5dAkOTqYnCMM8G2
fiH13bVufJYmydxD3+Lf5OE8MILrrKd27+1kl8zPq4gjgjGaVNLQ8ffb9juedPXU2VNMiyX9KAFZ
TCi8yfW7crJ3SATc0Uf2dZjY22DtBXF1I75meUJrRk/P87bR93l6+xVHbc0pQ0j8Z4mS5x0PCEd3
kdukUu/z39MS7gR8oBo+O+7idxq04BCHM9aPL35DyFyjx3Jn/EFo+7zKw6JSGaUe4sqxlC+WlwN2
/3VgvAlN82+7iL/8z6vaDKuRrpRkuXa7ADU8rn8RSSNVj6bWGUQgHjFE3AW6VkZftJapsfB+slHM
EQFOEosbDGA6iZ+d9tb1xDWc5Phz+KrXedlLSwtebB94PGtaikYxildob9M51zt94n9OeWJyYAfT
D8P20h0aQrbupT+8AQp9etYPow/Th+ijl9Pucx4S26b1y5Nelfy0MO4BI+SGsmhATlHLJ5TvMIP3
+AIiQEAC7U/ua9malE1z27lH3zooa+cJ1itYGXWQ0z64OkjQUFu1qinQrv0pL+B8ZKFy5brpZ4cq
AAq9AX0MhMnCfaU+jY4DuzjpfKps/iTCEE1NRfXjjJfgJtchY1CKVG9+yTja1zUvx4LG8DC+ACoH
xB2x/g7AVmpxVBbnU6tPfvEXGQag5wEtw88tttWX+Fvm72ZExqe6z4oqOFkmXYFz+WrptcI4FTrA
jruzVKGgwLSYaeR0qUPofK56uCz7hCj/pDcxQY+Z1OPxoMpCee5v0+O+7tsCaV3Y2tsFkT7EmFUT
VH86HV1g9gEnmH0yPGeOnaGO9T21lj7VgXvU/XrNmINHwnaQ9SCicz2eeC6U1JE6xF7MCcmdS+JO
ZMwVLzup/5rPrGs7O9P/RP70xKq3Afv9SbNuVOFOSTc3O4NeyoygCyaVO2hTDA0xy0qEDqsLqPPy
htOl2eAKitrlH1B97OaV4MKEq/2ISqigpxmxp6c7CWPZ+1rCS1Jdkr24lrrh1jSsIpSWIbfcUqkD
fAiOLcFAr8FR8d6laFfUzi1hGWIAblFtuI8f/0RmrpZpN1LqifVijWL/4rEPIU6XZ0ZKbhhVJk/J
/mOgNz1Q745drJx4u5b59JQ/7r7bzpH22a6KGuPSxT7i6NeRljqw2tZmkjGfMcD+47Fn4c8x/UKl
FAxQuLptdqJT71hon8u6X00FaPVKFqcveDShqL12Wc8fS8Dmtv2V3898yBoPowbI4FYOmD0znXo/
AIJumpf4Pkp5yiSiaJ9MLkpD3CaZV4gNoOUitn3LiLWQ2168xW1gX7SucKS21lPbS8b8sTv6m+EJ
35yjB2z/rs2RAw/pVhVUOGu6kDmSBpEr1vfnOQ0sAfYxtyup5/UBQZU0OQ7z7C11wBBC+12DfoPU
RZXXBk+iKpSQLHX5iS/UnY6hlwOtXPXZGV+vwznUWmwex45ECpkO8VvLGTE++JmzLSKRCSY4rZg4
F6G0YNp7kBRAedZhbBBy1kM2kyPXBLzupp9xp1cNV/fTksbAGYimGEWwJyDQzjhe0ttwhBDA/Ai7
sen1MOCjYrq/4IuE2IIZOTGWE3dEi1yYoGZgNYw6VqHHtYiRRgx8+urNiyNc9p7++WYT+gPzb9c3
sDL0/4vHpYn3Qipc/qufA60I2WI17BuG7ytSLF4bPXqSFBs9MBrv/nn08R09H4xXPkePtmIj06j9
h8yGxXt8/c/atu333TcnoHwTeROhvHDYuGxjUtFvF9J5tkb60Wk5FeHwuQeCsD4v4kQRNCoC6Zve
2XMrAkoxL2c1stQALjXqrtuy8KmTW3LF++Ndq3lUcosAwVV4eVusQYmaXhz/0kTIzEE1QGq/cma8
oq/Oe9vJbmKfgYJdACKzN3DqvGXdrQfYFuYcCk93fMo7H/ajaqO4umFDvFmA0+o5KkSnmZm8gmiL
fkyvmqopQ1tY1WBwgWbwlxyFsS+K/CDKTfCqmuqG4DRV9bHsFNzUHikFYDTiQBwYk1WOfpl3cbA8
6TWH4yK7x7sY3YDKhW3y3cQwHhFIgpyicGKIot+0u1fx4VZn1C6+HbVBTOmLl+3v3ugFGe9YD/9S
IWMMIqxUNboZO3bIk0h2zCOMbSt9prBpubF6/qhV01OIIodibCsNHhGOm/xWAyJD9ItFAGArefCu
dWYf7+Fqe6nAGGgcw7C/3JHDK56TOCqE1IEFoqHolFSFEqsOP4xBNx6b1lpi+lJ6GdnTKAZGfw1E
qdebzLdpp/NJXUNYg88WGZt6xATu8ajAJUKdf3UhMO9i0I3RE36R667h5OHrt3XP9cZawwknepgo
2VZHAzSwlx5usPUvXjfUCQE1S2gsHOY5wuo9Q/BV40bkU/Uh/3UOrCp56CUJ68OoR4NArXpT7lUS
JbSr/Vl4inz8EMruJhavUGZERVj76qkx9dcAnm/XLI9IZCFd1A9NASgt6XfHMFA5HAQ8D4p/1SnK
+ka3PwisYi5z8v+y5pw198NUeuc2s0vqzXiT8/XU43xp8nGngrRkt2YOrZ8ZAiTFwdR9NPZ+E2RZ
nvG08iETdoDVnvZ3BZVXem0Ia9h2mtPMm3+2yU+1JtdQKttJBHEUrCz8QC68BzxvCse1jTlEnPjT
Fx+ohJgp/iT1pslOQs73tCol8mLcOEJBQgbnG5R2lwz4KICd0kXfAjubffLdMFOJ+f2wob0XI7fo
ZwdDncU/uIrYgdn9RWyqpinCPOdUy5Qi0NYmSie48Ylv/r5JJSqDodyY83F6VJ6wdVQlSDemD9gW
ns4QJO9G4NeOVnO9lQEy9H0n1Zq8NSBpI+5mM/AUWmdyrTQk7yO8a5pRk+ZpdLYXWRKxb/rhG9qS
ncHGUWYQMvWikp2fqVlgxXygQIrHMc065Q8txNeTzWDeugLAt+hmEDqBw7VQ5b0HV+NVSs9/SG2b
87sxULNEnv2lJwE3qsj/KYNRGdRjucG3ua5aaEUhBatUE7n5x/1YQi952oD2BMRp6VbmR40mRYqu
pbDI6PNDfhDCDXumqvBwmQXwu/YOcXpbN/Z+bk+2NOhEemRK4dOpoVJ2B8g61IQ0vb9o4K7Y2sE0
VnXNQEr0Vrd27CYFrhMynfN6PFKIIBLtH+T7wC6JFHHeYLJQz9cED2sP8vTvSdRpl+dFbnr7t68s
9zjC9ShBVKyDTVJ3xThSfVqd2mDKjDHITejmJUMCzHAhKyTFBybNJ0ryAge1Khz32sXx3VWi8pJe
nB1gwD6Ij/zBDADhC8gtafEQZnm92UqLEpIy6wunounw4Qp9CCkYIi7TNlu85mTK2j1TYIUr7M+6
7V4PY/2g2csUe/63jtekC2aZzjoQaa+6Y82fRYZKv7l6s6GFMRNtBiyhmo5NUnyWNSEuNXZGoy5f
/EE9+laqA7+WMV1Ti+V46gn/K/ghOnj60tR6m8wTxqB4xXTQK+WDNUMHoqVEB0RpRGAuvm2S850i
oWkOV7X5/VcrjUnqlghVZxCjgQhjGORu7iLzodhezus0DXeIknHQ1reBuovuostgDYsVt79AFQOv
XzAjhwTDx+GNZqUA/DdyWSv6ZZdWEjeOy35BidBsTW3qiHsvuGLLeSZ+P/dziXRNwRmcoZcWXu3e
HI2B6Y9SgLMneaYCfwttrmOLzD/1qp+OPuyMWPY0pqJ+PDwAcx4glOg8F52QkbFxpay+e1NFM9B7
WPk31uA/hzPjhaCC1PL4IhHTNJQvZ1Kb0LO0Mcz5Tt8CLfMEpasHcOAEioxmv/7dV1cr5YWMtdxL
PqfdxHtI9GK1fHo1ZTTtPr+duKepbJbOhXyu5+h8ZMMI4n31i9GcQcqnyi421+DBiac9YKR9Puz4
cZrm+R+9QWvU+ZhZFdw5AAXJZXQ/aIX5z8flUVt1PoP41VZ+wy6cfJpRjjZGwOSbeWBdKjgDNfRp
9yptDSz9FQ0JEVyMkSDtT/pyc1R3JbYPY9IBDgXM65pvRZgWt1/HJMFbHZsv7INtavszzsFXMAAO
WuXJUBaRHFRUT2ojR7ANZW5kc3RyZWFtDWVuZG9iag0xNjMgMCBvYmoNPDwgDS9UeXBlIC9QYWdl
IA0vUGFyZW50IDI5MCAwIFIgDS9SZXNvdXJjZXMgMTY0IDAgUiANL0NvbnRlbnRzIDE2NSAwIFIg
DS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1Jv
dGF0ZSAwIA0+PiANZW5kb2JqDTE2NCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g
DS9Gb250IDw8IC9GMiAyMTAgMCBSIC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYg
MCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0Nz
NSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTE2NSAwIG9iag08PCAvTGVuZ3RoIDY4ODIgPj4gDXN0
cmVhbQ0Ky0b5Fc2X3ThDPSs3NJosUQaF5vnJxNITFG3e0ioamI9eDdXQ2t/SzjyOV4f2EJgYqWWw
bVatD166sr5m+PsBqQ6ToHeAqdR53Znk1L8Zd+vleUdF6KWbqtUCO3ft7QskihpPWGg4noLy8DpB
U7WLt/LDs81wVi5UI9jVqLYsbaaQEvRZZ6PkOZkp9ip6Gaf94qXtPRljdt22R9KM6AmVTptyroAz
C3vhsoOUofDdQAtnCdeHE13+A0umuBnZN4sDWmtqjDoA2AvNNw/tP9sMKUCT3rJJg7J/Ie1s349W
06aZ2G8Cl6ukxLvbEGr7b297eJ/YTzzVOX/DieetLh6hAErG6XdJhQcDffnMkf2Q+CEhVcrNT7KP
tMi4Xr+Dz9F8ZsdVwFBLHVf9B6xRLj4bT846KT5TtT7cMhHwgLjL36kq8xw45HtqJ1dw4dcs7VFa
lcxt3MzqZY63jwTLeCuym+ZH+eDOfbcZEu8FW/Xr02J3YFplZKu9wekNJtlhmWbzRABtJNI1nPE5
oXmdiqvB1C0fYIf+5p02NEWEsixgu9G5TOS9iPdPn1PVNvjwQDlOxxKzbCFyrQv89arOxLSyN3mq
90N0aZbWv2wlPRCchSxZnaSweAOTq/6ZOoA02HZUVSxnuxpRQ+3c5MIbstt/cMUQT2V9xqiTbJ7N
eGvoTb1KVYVFgHB1L8wQQ5OQYcfTb/lnXkL/Tsx/duSCgFyvBVlLrLtjar7OWVIJZq80qX6Dj2/F
1KhGhQXHEVux/wQ31QpT/vdQ8y0gEya4TbRBPgosLPmu6nIwxT8tCdQ/u3b3+23PLWnDh9ooz3jV
NWsa8yvs3Oj6+UnerYrCQ1u8aGi8hieP949Ua7A8/+VxU+k05APy5BwprdGyvxryo7HIB7VyxITG
s1xNcdYFakeiQuflEjMmXZfByHvP+fo1JwoM8djQYNKIk0kfHe80GTvm33UJrapUgzNe2atAMO+J
mH79XcQSJgnakCBTqY9tI5iGninJCOHfAwT26bn1TfqYePSAbSwVD+kS13TatswUbG++AHLJKtL+
zwaosx4PzWy0ssXZ7ntf9uPdOLtK8qkKNlCeCPrNoGP35heGo9CqILYaQIM9JLebNkNSqAskozBw
gWgfmg8qdWEBGKxDQg7e7qq7AR3qmVDn7/7ljckIt4FINlMzBegOU4H8VTw5l6ICKNJtHtQ3RBnh
20jfuVRIBN9Sr7nWhPliKw0NUa/5kzfT+Q3ztUs+VheIGAydaQaKlzpvBX80Kf2UCPlt2EC8Acjb
HLDWwtYXpyKNURNiG4rESrKWzvAz5oQXHlqnyivHaY4pR+/4DxEyyf+mCq1nnhm4/SRKcT4a5SO4
Sn9ys3WjZwVmR7d2TW/27imUa7E3greyaRmddNIZwEW0gEDmDvDeObTGyW4HJoWWw9i+gP3Zjv+F
XPaCkN471b2FBTGYa5hhJB3m6iWP9JUqiZSJcgGop0VkRxekwGyDF3X8htxGAoP6n2Y6oNlCf6zX
dtbDa9Pmgmna5SiRq7my5lz1ILS8Dc20jUEOeDr3tEmF3+WRPnKXnAND261iUQefUsMzlYDWedzf
p8WOmDZz7P/ql5mOo6Ri/ntXgqLm2WKeGJ8kTgNs7qvifRWlciDAR7VmOSAWgKjJLcQ9f+0vQ4cW
h+1vwJabZbNAweSbk9Ny3/NIbBjteQD/DfFS3/3k54MfrK5QZOFQOFpavBovIZLBwgY4voSDz7my
o1ME7T0oo0H2WL3DdUYKsmMBFEeiw3BAzrhs/F9w6zUf0NFuA9YfeOI6QZRI6wOYz6mj0MDsqpn1
9+MfKCIRiPMKGwJWsjlbAEi4J/Oz/WrtzXEHBm1O3qjm4/3NHa1swge7Uq73qbtm1PrtOFKd1COG
ouY1iaFkCiWFNR7ubfDqD/BWjweMoATYhKrHJWMs+nq9hxHFZRZljpehBQCQHt7asK31I4U0glWq
uTEMcsPoUq21Rgqp95W5f6M9vg/0pEx4yPK7Zr6/uXkTXlYHwddfD3Wmy5HgL19jatgLYGoUATMd
8JYxALDIbdp5hAGqoAcHi7ZoBq0dCQjT60DIKiku969Wg4wyefOwu7BwB5JZszafLDBD8fZCgEc+
gzMtqV1cnKtQ//A+DtER4jBhgxuRO47WgXXiTjrSShAQRi/xLy1OYBKO7nRuFnSOBJtKTDc4X8FT
qt76RVcJRj+P8ZWs1NWffO/k1tqj+wbtOP8wsYdfrrR66qM92nNmtN+5fSMJzH4kX8+5etJBJtud
QvoG/TmPKaFBQy0gFx0XW75dgwctmI0FlzmWE+wdb5ed61PXjPcmh7VnTmK4k3CCY+mNmtBOSDXU
P053x8bevVQ9Hzwavtl91ZzPOqGn614eliAQXkYbmegXZJ4Vr1QfE7WcQTCwvOPDwh+5YEC1a5Qy
pQGZUx9wjLo4tUZhpzhRFJ0+YjbSNJDMRbtudwZUC1viBfS+fVZLvScPCBeqdas3yOys0tbbbBan
TnUzmKrIwq9nL/gnw9wmhsNYZVoUULr0F79WgZdDGSe/ixFWt69hYCIY5Xo2P+PK3pwmBEWPVGhe
3SiPw8+Gv7bUgCDeJNuoacBM4SebXcIkSbKIVfod9FO8NPWiq8xNKtrAkNFwXkSkPDks0jFy54cS
+D0r9NT0sR09QDZ0wgs7T4nZAGK8Z0m8qgMrqBdw+agSPzzUkI2ctr4xexwUE/eNIlUMHwIXfBdy
iQepLuz7mW7V6AQlDCwO8ZFL2Qoz3gZ0R5nP2rchKW8tRjJYhfeVzcJimpoDOXr3SSUnjhR7jepQ
fV40S4BZi+PHVaHnf81zcyaLZ9s12B9+WMpExNJof5hldAJbFwufh1xbA6ALtwIHd2hhNgqHpfhY
+J54gHHN9DlFDIgNEbNK30TcfA4Iysb3Wa9ewLqAa2IPRO8g6SLt2wvuPn6bxkQXnB1cvDUDNnEP
2y73cdD0K92Lzgu07AqvJwSB9WZYHlXIHnODsv2p+Cg7W/sRS5IsRAUWUToOh5oxd6HmBsRwiqjH
El3Eq/9skH4vvyRpTyc03J+DGp6Ir1WW8vW+gdh1Eq3lb4Vacm0GJL/ObZSxE+2gF94DYyTCIx5P
YHr24+VCMRcoo6rnP81xnqm2SA+uhHGcKDFJKi2wSX0Wzoj7dvTP34v3iYi/f7E05xoIpRhNdPtB
/3kUVtz/kWeQejbdLu6IRiJBNs3uB6qHpnNV6Aq31xPSfbP+oZTghGtBCIxWlJOE8KgiS3FeGf6b
4f/CbfSUttFm1GsyKo/1ifUHBPpSlMOz5sQykQFp2hZLo6VmHIoUfDciXyM88k8b7ZwO9mwlAWL+
bNSQxpkMq/8ACWzEL2xm1JSNIkuBMwFJrEAs+cg6nrB6mLWxOy4V4a6u0z79SZ+0H8MrTGadc4q7
jXvJMrqM4OawIwA36Wltiy+jem9lzpyGHesHv7HWCeK9M6x6nZwPgDJC4A0A/QXRuHjOhtD8q+ee
4fIK9mb/84+1uLQQ0Ww/Fd0boAT/DaqIBH+7sq2w45hhKbhIea531c1N7G6qWPE26whW6kiITaHK
jidzOtnR03WY1LJIELTO+CQq11LBQvyDCL0HtBH51rRGx2R4Gs7zqCEm0cmPIm8fm11vx05nTHTK
5GiauxOrz/BpylzM5VsVURP8RuGnxRkQpuLl8Qq2/yEJljEAw7ltTJv4X1HqbMNwTuEKqsbaZQUG
50VDba6TynGP0SUQF8M1dDhB5OiP/LPQDDY/B3X0Zt/Kj8ilQnBspNV9qSLY81M0rpFJrOcQPdB9
vFXbTA4D9uTtLmx8n6VcjmDDWp++D017udW/4MjiiLnObQJnLewvVBrrHr5gpavbV9c7DA2aXlB5
xsgPKqz+fAMe3s41YWT6E3pQdbrWNRnF/EXw2xdZMwiH/t6TCBFnWHGf+At1JW338LxjBoM92xSL
2+WefwVdsPjiGWK15DeaKSge2zak85u53b8Vb4mLVpjbHM9UOijDZyYAz2QrGCfvD5sfotOWXfz4
ThdpTtny5FK83q3TXKTdah+09mKmZVudzZ+uYdzHQZyvzZ/2MeDKIm/jeqAK6cnXAAsBc87vffd6
HsHk9N0tTqD7Bh1/O2+1y22p55ccGq8uMOnsUQ3VnAYwGk32mbx75nF+VOjlrUlgSt4sLFvJ9YAE
usSMDJyYSdZImPIlAzhlMTBvjjFmTzF+m8xQlKqKHwXs7HVS3UWdyqKuzwdtPeC/c8oNYaQIAYOT
DYdIXJAwWD7Ke1VoaJ/x5Z3kYWDfz7hP2TXlammQjbKicJXSqv/q4Ws62zD5lvLMtouQbVgrOIsj
ic1ktruYQWKcEelzZzWxDkRFbPGu51xOCQy/B09I9Aq9z9zhuVZLAx9ey917Q/0WV1jfEqTnoTRM
A9ku614RvQOR5hl81pBZYtENJC/4fxjCXrBdJi2krVXvxZpf28zo3a6K0cqO2UIbqZB+qCw3CtVQ
7G9BSQM+W9r1wycHQhIa6B1aG3UVRrOHCncHSeZcAT72Xv1xKquJw7u7AmVDHBJaxgIu/NxIMaiE
5TbODD6cN4Of3BUQ0AjB9sMe8NUYW943cl9eqz9CsxI5ET7AmrgmvsH98r00x4U59Uh3Cef71XuD
SSIR+BLrSyLj++68KgtuFDI/Zz/sfUHwINHUg58tY4dakZWbbA7wCTcVaGqVI4slQXwaazdowqhd
gAp8GgMTl2biCkgtQxhDVgTs7F7HCGzea42Do8ycdRLGqfHYUWXEzP0qIixKuoJMaH5OSD77tp5H
NqkeUJc1BcrWnpaWB6gA1XivIRRLkVinKBzwA6kHJa79V9pAtub6IUxb5H0UvKaRnAWvbeTRxNIR
olRcWXuN3btzi3ekLV1lBfpfCK3TbUt/YU3ZCbihgg87RoXKpCv3noITbjRMzBhFnRmY16Tt/kvt
cOHReqGA7qISN+OIzOyEWjotgTzDkZsZJCock5/yTsKntqio5knDN1mfJ0Ebl2s4fQIL5FL/q8NV
Bbqfjg6CxftjcUX9lrlBt//SqeWACPFYO+p40ypw+Vz/OYuGOqj0XHBu7ycIfRjdn9kyonyKd2yb
IDSsR7T48UkqQXVFnA0/6BxvepQMR6bTq6lSBWY8VnbMbw+ECt6D4DdwMCSoFSKlRgexlWj8L2aB
T10FUMSPKuxnPF+G1UCC1kuNIgCKlPAmD4CfRQ/cYtadI8oyAg2njdxoB1QaTxuzVUqLdKDh8NKR
vDLkbByfTntCM4RXkUCwJE081DJ6QXXMCp1BYIRkBMYDWgEtWdGe4ROKSYbldjXfa+NAVxeZPKlT
1gEjxdQ5hRmJZclk3EwyqWBWPmSjkQbBo6oMA5Jqbkx/Ek3OXhcOXNep9pZY2srW5ImTp8ycK02n
dFQDX+DfLtFa7He+cpF5rIYetfU4Wy7B7LXti/sr3Mjfy6ok6uoqDydCFFjlUeQd5XJE2halbHj1
sr+iaG8ypC5rMOUECz6AwOqw2ticyozF1IGVWHouvCnsETXWhhHd3mNDtBqAyZw9zpnp1t2J5b5Y
lDHZwTnpyewh9dSDddyhAmrdLwIEfF30ZiwDh+3kznbPlu7JsgA7RcI4Y79T92OHTBVCMbKA03jG
dG4iBT9vPU284Jwh9LpwEIOTRWW6Yobhr0WyZZOt2XOIyABluq93hbkzsu96b3tehnA9B/vpYau8
VZJE5LPDUnYDPAX73ElIAUhgDHzV02DXXOVLRdJwoDUKvJ6D1H9ytmrvr0NTFVPipXLbhjVToCeB
Z+XBNHqhV+lAnxZltuKa17NF5hoyKyzEk03Nssotq9GHL6Fq9S6gaIB78+G1aF0raODNnVjQJdLb
Ujj4AxIW8fFK6hqnHfO1tcj5nq9jpaw84cSrpzRAc/vsKLHsjFUdS/YNyWVqiLxvmGxrFK6IvdO6
yh6iXGj2KkbSmJAgFcta44lyRRBfwBvYQm4VouQxgKl3T+KWstzteahup8S4rnIg0Qna5MvYWq9C
iNdxWx7xkwg1bLfKleZuF9CwNDBnv7hS6qCABDYxo8PvMqMpx+0fhAT7KfJu+KNADhUX7+5i+0Bz
WUTy4+6rpIkUlz12FaVjafKXeA9AP5gi8i8ssUNF4Dk4eY0dYJGsmC9+KtKXyhgWTuDnEDpuDwgc
0Q7HkS3a7qDZsf1FUUDNjfWptI9dMJqnlJ5wXL44V2nvKhU+fpbvUxZaJXwRoTzdddynkwJuRK/g
Pk7Ywq6Nyu9/KAeG5Vd8sjpxUoCvxZqzH6lH5c4XEQ3ufwPFrIrXbv4axzH1upbx0JRFcGudyOBL
A2FvkvVImztBmEwo+SQNSV4uibXVtbXPXGhog+wPoN05vd12G5wRrde3qmi+tF1Dn2AnZzk/F5qT
1yyMrWvULKh1vzmx7M1F5XiOr1u+terY0oR+VxqKxZTBxtDS4FbaP28pNAteTwlqDQjE+HG88Bv6
czVfV7UuhJGLxNl0FVQc+TYCxTKRrGkNrfgeWJX4Omj5+cpsUbi1+LZ4mO02FU3LQMuHHHrVZRA4
7++0W13Sss2uPrpRWvmLioBwUiDXuJA8hzS3Wp9dLqocL2B3pG5hxduMNAxiJ9sGybnnpq70pSp2
UZLqQKZDOFNTkBQSS9ba1HpFbGtUQ0oJnm0jrC4G5rXFsS3mwD2IusjdsvTKROaZzhS3glvENai2
C4V0xU1kQXkDkjdjeRNQnXQfk6EpzjzgMF3KkEr7XcqpRLbPh44Ln8mGlHdLxEUrUKKamWUPSwnT
G9AA6rFOwZs4vANlsTk2JFY9CNxoBb4N74vvWGAq3qKijFr5dwRFX4eRrdco2pHwqb7vz3O9nesr
kypzGwBP8k+raxbyzHLVmLio9lLiMxWW9EsDwSL6ZVzyrCsxNApO73oYPEOypnp58WGvs86gLIIm
yvTEgFi5DyRJvAL/C2J6CHQO7G796KyAR/S2kaPDeoVPCljYgPW3Fw1P3AGCwqPNnLSQMQPqlbpc
0rURql/kGhSIDnxl9AXJYlrjTiGgp1DbArCurVeeduInRSCJnaVXQ+f8nCGu3QBYZUke266LKIop
n+a7AaeLGwxkU70OsCum85qXSR7+Qc93sjmEPJVmDw0/JmTenRK0K1uNIQUl/a+AHG/qNj5Lyk+1
7D0UtgqtjAJwQ7QM8W1Xb/3s4KL+nt3q1To/ekTJQe8pT5Kseyq3VlKmFzERsr9bNNF6F64q4CEo
Pqq8SFYj82xKJLvswY28bollxirUbuQYz/mkZ6B7O+czaH6CPVM2KL3sbfNfB4SqIq/vvrB1GeDw
idzkmeVU8SpvVFG8ZtHv7gTfxeZJXZ4svbDg9K9BJCdwDm6PClbD6gF7Hx9gckxhmwBZdGEL8CP+
Sq/Fsxqn2sJCGAl9n6XjF5mXlfaMtwVVmzA8RMnwd2o6iH2kI9ZfNL5GhcTPr/KUtsA/7nZnZd21
oQObJK7Bp5lQoyDq5b1S3vTOSucB9tTCcdn24ZnnDyOukOHtQahuo1i3S3h1vDaPojMSmBS0IP+R
1oB1N7QwXEVJBQE36bVRqFgUvKk2YnlsJgoT6bV4EMTcg7CF9VfNk9fUzNg6ZOdaYGiiKIy4yIGe
w+jVPzlh0cp1RCMhqEZoVUyAzMMFEemYEw35f1u/C6L5oUGcn/3TqS5qlcPDVQhN9G6iBsUN9FCd
WRbjytzWpRRi3JsOrwiP1QdvYJQVPVVUJ/wR4g/2WfH23KZMADI7Vve+lx/PLN4tEmHaiuRgNEm+
9oIegZVORvRnMTjTKTGJE/Gn70+CkmmS1fCMbl8a+svJd7OZKpiIOqFOqwZpkICXRaTPv0c635nH
lj7BdhIaFE+EMWW5xJQXaI7yLh3FwTYFIpJIccYt/b4syn7venBJVSxgj64gll5Q6tFT9Yan5sLM
D0uHd7H+eHlxVbSXcrJyHIrk0QQ+jieHN8qZT9+r76XVVphzvlJCGdX1pE3pC55Nqy43IUDfC9dY
Vn+10JBhlqjO6NpKfQ6BH59oLVH6BTN9oi0YwVP6nj/Lu8BcqKqGgD1OiwHDyMkynpDMVnZui9Zv
inUHI+1FcLYw8HIUm/+V4C8ry1c/uFKQhEAEBtDx454yHAlW2yKbB7QIiuU4gE+DbWyR3vzKNf/T
3qThE2v5pg+f8kTCLIlsHZBk1rGT7AD9YXM/jHIfdFxm/DFiypPJ2g4KQ498GjJUpINoR74LIwC0
mxYgjrdA9Rv9dEmW76YIZW1riHFBl8Uj+GkXIO92xPJfp5qh/ijAZZiCkASSSSERMQJ8/qGpk4Zv
9Rm98YCElzZbnoawI08Q7lwecyV+2lOgq6VQWR2jHwXp+eTUV49OTJ5mJUOqoU8f8M5kBKasuoWY
L4w+HEGo/gjLDJif3AISUIIxBnp3Snno+wH2rrTtfxzKxlMYUgWdIHU51Q4AReo9vVXIc+1EqB7P
9qeaSgsiNguEyR399gGEohUbHCKkWrIdUeSqhQjiE3fgJsw5N0hHhYkGcWvlVSx9QnmHtzusy0cB
psID2d3al4cB35IewAvbcixBOWxfNmKJzg3noNdD74GLOsPg6r3gSbCZnTtZm+UOTZyXPAKxvXHd
5Lw2o/tV03VB4dYeBvUATDiT6Xxnlrur5Tu7EiGxOHtUzSrsQCNcnsmYNxJZP6v/8or9EweD1mrz
TwC/f3On0n8REGQiwT2QpYkEFCLxmxfm8GDPOFAkUXAipTwSiQ1mIT3/pXCkqTghmXDFOLvGjjjK
zS54DLHPdWu9JdTtuk51PMCEJvGEX1Sh1LdIiG/VQfyrRi671BZIP83dTlcZBs+K12S4BJRIvqey
WpdgwEPrPGeaqxrZGTW3wcLbb8YuSBsz44Gk4aC0r9b48AzFPsvP+nR+eUT7Q230nG0bJ9m7FwIb
lmRGFm+XHhWqqApVqqYwsLPmYt1CUg/abtJDW57XZE4XxntYxZAUFFG8Tc1FR8xtLkBddV8MRhEX
HEYlgi7QeuKZYtZ9iGjjORinOE9yW6GwoETegtNLmo7a4Fr6O/SsvWB89HD8IV1EyD4IETogsw1q
G5MHHroeTS5dFNWp5bQpAF3FEtOKTWKd1DcRn5/i1iNtRtNA1Qsqocj9jm+A5Ru6sDnJ3D3ihBaZ
Rv1KtFkVpWVcrs62NUJMHoP9jaCjB4mxxDMkMmVkbwLnfgRyLkAgmJIoHu43vBMKDWVuZHN0cmVh
bQ1lbmRvYmoNMTY2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyOTAgMCBSIA0vUmVz
b3VyY2VzIDE2NyAwIFIgDS9Db250ZW50cyAxNjggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5
MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNjcg
MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgMjEwIDAgUiAv
VFQyIDI5OCAwIFIgL1RUNCAzMDMgMCBSIC9UVDYgMzA2IDAgUiAvVFQ4IDMwOCAwIFIgPj4gDS9F
eHRHU3RhdGUgPDwgL0dTMSAzMTEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIg
Pj4gDT4+IA1lbmRvYmoNMTY4IDAgb2JqDTw8IC9MZW5ndGggNzg4NyA+PiANc3RyZWFtDQoYydd0
7iuHYSUXcPajN+FE7XLIJoQ2DTfPzppVuwYJHg1mB9kFWxm9j/HHdQR1gkI7bU3rFxDzUreC7PKH
N4jn1SuTpCZ6f3Q7Dto4NWGyaKl+REA47E8Gaig+lSKLMMZuxQFIkrBzT6uywgOk0U/GLLg/mW72
uDh7Au+2qA1XqHNMn1OSlLyimcO4GVYgUyu1TAOfVL8x4s1NZGGoZcy/6Y+MEj6O1dtDWBFA60we
L3AJs5X9UAqV6C3Xbcwpi8k4zcYSwz2IvMal7PQWHn3G4cXO5OqyYNO90cfNe5TPsUfnytNsb9Ru
w3IcSEHqJPUcke+eU91Wt4SjpLF8PiaEa8QmNeBn81hE6B7DXS9KtIUZP8xcx5mh7UaKhUxBkmpP
5R2rdMgxQm5PKRiNlXGAYKd8txvKSMLbmwnqO+MNHEnjUke3nLmuj6rLCcsG9eknlYFHDjHTj0nY
1Src+5Giyu4ml7fAvaULX1nMA2qflUIysp3RltCRouSlZaKfEXkUXAHj/l0+kpCP3rbsz31qsXDI
lGI1oPwJZ+MGnI1wtPKlMglm7m4wtF9I67kAV7qVKpQq3IP+zU8hoXFSu5LtBqaxjYmlH4hJ+/a0
tQzih5jepkDN3jw+0wvRaGi8p0ITvuU17YA3/5M3VfFo8Efywl9ghCj38XnCaIn2w68LY4YPsQeM
reZuXEXi2Sfs6gdOF5LLev7Q0EcSiN/ns84mYhAYBMNgfRTnT+PGHlFiANzI5Fj9wBYULVBIRZYM
33GsyvpWGTxUeAMU1cvNDy/p8BZkDlGzWrvK3+dbXbYwISMAJOyn6Oz/sUkYUHyvkLn/5m4pFhvK
VmYFkszf+JZEGUh9ask/Fh1RkdiSiO0sQyg1rX5qLQL+J2NopfdtEI51aP0Uwj9zzhzUSOWhirsY
3zGgdn83GNhS52dODWsWUL3Gowl5+dnLFF8RG+NZ+oOxwJNRo39w/mcvoKhgUDd/8bVS0JaIYGtx
ENWYA/Mb24YAvoZ4iFQLvbDR+Qi+BmaL8ZV13Sl3lFiz6LDfBW0ps8yA5tLu16bM1XN8XlZchyHz
+mbRn7BKF+9QLm8CI4zRFlqDH+MEX4dFM/rHlK4/7TSqHPQYstm0w9I17MAFMxD1hXKk2J0v5FDP
OgD+WYKaYu1qQkSL+05GYZdZkGw48kThtc60IqL3dw0KASIVowO/TBGNWnatHaPTmYDbn9pbmI0m
q/uPL+sNK0d4LDYozAYfGmoiirm1o2tn6nfuxLqkFlQmyf70VDoLoUbEySncH4u65x5w2CM0lNdZ
rjG2M2omVGSxLkWbEXMeFYmaof2bu3kRNCCDGRdOeE8j8KS+a+hWELE2EUJK4vzIEIyDDS9+d6+M
hAvTzr0GO2q0zWsOCcTYE9xqbLx/77Hu6Wmil3+B8ZfBggQKS39UyaKE945v0xtcg7zrNVprMCqF
mR/1FSpUHXSx+u9DG2WZ8//B7T3QxymFsetS9r5pSU+s6rmELVttSq64E85C6bJeS4KHalchAMHX
BY/lp33xrjI/NYgJSt+f2h3yfIoFUtI1kJLnEp8Jtwi7+ctRyKR1jsfl2NPlxjfBmwmZm9XytRtM
mp51b2la83aGJi0MH5HZ/zsbJQaPs5TUGmAuEvHtin601JoKGnghqYwqPaRvjqDeBByeCl8zq9Ne
gUqfJ4VBPqymQzM0V+DdLcv2mfgGTnG+jmwEQw/hB/lIRyTUd+IjUjvhATBPWr4hFvA4m6qXRTd5
y2HONxXAsXp1hYivHQwBckTQC3iiVhq8n9D+FnhDCoYPOdWf6WLLWBoXdfzoeDfV+CIMeLkfifyj
8n6JBa1RXTf0ctqSO0rYcawvIf5i9MumT/m1jy6+3sXB6yA4Q9M6KyMb9Bd3JJtzpM2zSmondWLG
OD0QZyx/BXhlQH0htmBNqE8fS+Y8pAA0aibu8pePT7IAwvCG1eOciHKDDKzCQ4/Ct+MaBsOOyCgW
XTTZ9jy/VsQHtzDBe6IJI0A0x6yKku8z0UbCOsD9Z/OkWx+YNF9JpLuDz978F8syGQC3PaeYTU7L
pSuoWrf3dfQUHz9FLrmfcqMFcQvlh3HGbG/kt2MlBdqlb3GG5i/23rkxQjHt5v/pQ0+VqQsBROx3
WCgdL0rWdO4CWP782UkYbFbtERjuAEjyvNJdih5wdVIiTR+rOpjE8FUmqU/dHtD0de7u+++Es1Jx
NrvpcesaAh8dQgp/mvySDpS6238h8oCVLv0ssnwjIo2/tqcxrBpKPXGoJVyvjeKu9WExWb2aO+/e
F092MXnTN3k3DioMyFS8jTkkr3VhkOWt2AH/3mgM/BewpgnNq9okcGlC5oGW4ehYdizo5uFHjHB3
t7xYhKIpbEYgCvMPt9TH7I6E+8Jkt2QKqmWbk/AS4etFJFsz4rmA/73ILjD4dbvsNEfP4v67F1Aa
aV66orUaeCx4sjQiHMwMz0kPy7eYCk/c228RjBKGkxGb9cwAf9si7O5irOS8BynsdMKFJ4Zrm30M
IypvIQN7qYke39j4SCT8DCCXvavaTh3mcxYDN1kdtyK549Im9LaGZiIl/LGc2xvEhxJp3mfGmZvW
drD/HJMerqXNUXGfyGYpNghMlfZ8D8trXHVpijx23OtH3cNmo+d7pUYrK0YZ5vdt21iAf5bVnqsF
DjIt6SrKR253ifNT55CsrghGxZ012PWN9saEv/ZZLTDBTxPcvD2ZN6OJf5Qrr/bVtNlIBY7cpWm5
H0QRDzECwT0ol39oQstnIlp4QXpmB7pVmbO6IqxDRDT8wxnXzCWIiW3j/acok2eOzDig/THn1G3l
28sGDOUk5FwurhP2s4L9PoZ0lZnwpb16BWaQR1PAqTNbleh7zRbQJUP1tpZIcOnkAjdMUPKzh4C6
HeygTR7aoaQBtPa70oyWOQrC+rc0vGcaVIIkqQqgW41XyhXn5Ly2yniE76CiQZ7vWnxSDX09H1OG
NqwGPWiKv7V4yUqyG17pSEgQ5FlI2AklLw3O6Ega6+6Zqhozw6ZQgaW7A2ERzlKbGUGZ6Ii+sZeO
+pu/etWCZ7LkKGfDlJy+ln6FlIArNjryCpbeQIjJ8rjJaaAt/Mfvx8VJpp7bPBeEQdLsgbIkBOv+
l4R5uob8yEmHhWx0nRrblMxMy4QVa9Z0+CfDIhPHbq6QaSEBLFzWx34ExGGUOJY8johV2iUW3lzr
3Ib9HkUIaN4AvHaDbj07aWpwebgZ5s75fosY2xrhJEQx+PX1UOx73mOck/w3ei0EBkaKrJMg6abF
9JYCXP2YOnvhVsXVV66mzFlYmzjboi1lCBcXYW9mvlUnWc4nKOXg3HmI5rDYHdsroXCgnkYKqRdO
B1sqJTzQpXoUE+GTzIC6GpLgFiyVh6ljbF27itpDD/8mMW0Jm9ydPSekJWjz7+8Bwu4apB2ZXDrM
2PiOR9Tj5/K+ioCGu2FBj3JCFjQ3wly4OThUpsNeeEuFY3fAydn94Pk0djCR80CSsm3nLpQzgpYF
EzFdrHwIDW2BvaoVHF/Dr+UauaE6X9NNS3PezSb+jAjj8wAP8PYecKcWnPFjI/MAIVgH3pX92tR1
736JiNjuny0S6ivQbwLdrJunQFUD6gKKOtntZaccOnlVUogHQijb8DbKin4NHbUSU+SdByBUkpEN
ceQiyMdlQ9JAxFuhCPEekfzyOiDX4W9tob1zkYN0guhHA+HW+HjxFhXgK1m4MQP2+7/JAr3/Fbp8
0/ylQaoptHA/nkC8/yVpoURXdOFoge2EF5puSJztHi2xdsPQAts7GwwxG1aDi3OEfSjA1wZ7Ze2v
nD43wmtNo2z7jdKL1pRnvjQG1vMp6pD4WRnpmcw6Hc+1HrcVxSZcbJHQvAfn4XxIVqvs/rV8iWaT
5aqNb56jG7QuWQDv6rNIYf6h/I+pE5buD7jdA21SedrjLPM6hXVXjolRxBOXbT+DEXYbMb1bsZ+P
EZnQpSvhQoBJt/B7ci76SAZgp+z54mhm+k2lK3XKpZInthZSGNF+tk4Y2gFbrjzPykQReIIbe4kH
f2MXYoE82qvlN5ny+XU2bObs92R7RiSUUt6Qh2+IsXzIdGpkanDfBrdyRfdQrCUNxgXv64fis+hY
mjcs5gycgQtFCkROVRvqlXczZMdFETMfb+NV1YeqPGpkCXMHF02ZzEOIxBVFkAZ4o5ThAqe1Z3mC
nwwGtzqmMUJY7zmWzUsX8B77UNVtPWQGF59j4TWWimt5iQNYMiWkMH+Uz49CbCfKZdoeFMWmjzhV
imyaq2cTX/F9h2DVC5WGFBxrMyOblvJQ6EUNhU36TFrlN/gsuLfFe2VhH8gthlvYVhGRApVA0799
IRJhYjICxjZyZGeT4zOQYh7wXWrq6c3Mb1bgO6WDYGD0HGIGFgQaxy/gZXhzKI642ZOAXWxQc+Vl
U11lzsYl+6m62aVPgIogmDgRw6iHzoB1VKZMfHHqvsUIm8g6gA10u1OKd9c/M3yvkJH9Nq4rOuQv
Q84es4pnBi0i/zMnlUbV2jg8xqUfm4MVi3GZbiwxSY5tn9K/3vxoJyjiaS0xSaqAmZLBBOn4HXeH
ZURSedZGFWjPhwAzGbobve5ZD4f8ufhuq4NUizfYYXxE/VH7ztZNRdLN8/3UGV53MN3xmU4vLLBt
5Dngf53ayrkL1+RbCslqRho+AzLLMSAVwPiVvX/PPc8iSwS+a46hnoLDjC0I2HZnfUE8soVt5LOK
elOIiqxW3cgoxWxOy+NdxfjJlb7chDP3xbX5+R2r+FaPFgxJvzIP3KxAzx2PVUH6e3Y/HZP3GnDw
LrBVHCjeEfhsZiR4mAA6lKNcm+tTCPuO+6727ArtOZdIA03NPGW/7GZdiQAWRqRhL1L4+qRqE6ZE
VbOqiuO2b8d3DSSYU4yQztaHkScur6+5FlOBEtsqZZ4L2Z/pOjw0FHBZdbRS5RJFl0VF+JeTowuz
yr4KkMtrP+EAhf79lp87rrKMNtIA0gPce9sdPygHCkQhbslkqNK65aHhNzMcQ1V2w+WcpDBHT5J0
z0zmlFbI/+67qhpsxl2kvevol5PKptRokWMzOh503DD/HjeykIUxeTLocyLlEgAPilcmasEhg6gZ
5J6aNUBC9Kxt6+OW60r1ytqI7vCvPOtWWTaRY8TCdAjEBvxa/g/ICI5nFrBbgSzr2qwlRM0iVelQ
cJy4x23edASxjpLtxdOKz4mUflf5vnTHCc2vQJVzodboX0CUpeuBddxI3EAP4Uj/cGWqHDYZH++z
ZoLk8kyXQqJc7xUbxNDjhOJmv+kPpylCCJJwxgw3FT+pY6ebh3mPf5EpA61dcfWmCv0YDI2mlHiv
BW2iHQKTlTZ2PlLReqenMZ3ZOFEE+bteotvSw8si8BoZPECbM1Q4viezVjWXtK0qLzCL+6CyMJzO
TSQBaKzrtTH4Hl5s4b7svELtGhbjsUiOxAPXOOdGLMQrcT+KOidsiR4mmeMsac9oB4qEXeWRlw2k
EO/FAZNbL3c7gtv3M+ELdTiY37olEmNdvTq+jMJpIIjkuo8V9dmUYHVgyMnYJo6q94E6y6RW1mFO
TCk4/0DEUIsoMUzPpTrawFjlMncAXOKKlyBOIiIPni5tav0eqWvMSzAU3rF+48FK/IpkuLXqtPDY
mP8Yi/anhhocRNNkjGGz156lqTABWsU6sdXyWFFqtdgzIGqW9o/iW7g6gBKR83GTxdpITyXw+CnU
3n9HdVpAdtzP7A3ia3gKy7u0UAtrEGAi5W/Brv6szJ5gA4NkZdgRGDzO8EzP2l6Pcc/QhS61xn6h
5Ifn7KCmm3QJnagt5LzJ4JIuzCtMf2wv4VmzdScbhm9jWhmJzd7kVMpdeVyy5NDNKxMafxYPntt8
75QT2v656w/FBbustgBOB8oNci4gUnf1w1JGXJgrUYq90pPQP+cnfdDEwurLqVts30yp81mAzmS5
HUHHyUuizFWTJOj2ySdJXMsVg4xRwo96ZhjuO7k42T7Ug9fjMnO0aD0qs5D+1J3G8as96N3don/N
CWVXSx9/sWx6uiJFRbDzHF0cbL5Eyu2bGkLHg0ql+GtcCsl/dardAsVlORb9JSu5DVfniAG6sH6Y
lpVI5pTGnBmuv23nciPkJe2V4V7nPYZspoH8YdTOAXX9BvNkD4h4rkFSE5QScIlRi5I3fmZoCQHn
7UebLSrYsoggS583wd4wTp87AsZ7WPhnHgfJqlAzn0Tgb4jQbCJtotMabFtKTUe+AK4UAiZXayYJ
YaiXvvh17Ko99d0TP1UhKQgIZ9tQB0cRxmUdUiMc4pjfKnPSlI9otVSNA9VMl7kt4mcabjyT7VWa
tdKM7XFvqPuXaD1qx2S+h24DBEnCsruh0cfImV3UngB7wUbhSrHTuCE2zqO/qzNXhNo5HFHWm+rt
4BnrNhN8WVyY2FN1WiGp51YYg1fD70ggoy8WdQAlsnUsEx1JM/v1H+J6PP78KBAgqYc2xDMdpGyc
xQmGCy3T2izcVhKdiwhg1A5PLKOPC7srNlmKWhuFXZ3OAF7kCxN0c+WQKdUjJZtL4/CyeNai8z5H
rYqJkZau9msy2j1x9x2qDm9f0s7M0eRLF0Enf/I6X92LTKAuJkAjht+f8qF7GjoDinpKq+he+Fpk
LOL16PqyrxjPJaJNOqpVDHHOOUW9x5Krn6/szwhS9cjQkBTMANcEHg11qw5c8+W83LqZiGE+928Q
t+uQMhUOYV5wHOeqk+xNuktGQHY6jJLmRTt7XSTq//9okxRvz6v2j5qYBqF9kuKoQlrUYdabyI9v
ALv00c7Una//HPLW3sYXwJXsSMXacjBDBP/I6vL0zHzy5fAMLz+fvsgz3Kmi1Ybo4ft0VeXY7Vp7
GaTsEmjbOA7az5Y3UUR49ncq6AHnhmRynkdkTrG4EYMwtD0uV9LKtabt1QGVKzeaIxjziEoiNNbm
kmBA0sZnlblin77LMm4SSTYg/ah2IpyVk3mPRc89521TxvB7o/0lUYUGahTT1jACTiFBcvGL6Qu3
YEHrf9N+Y5q4ZxSvMNlC0InmPF6s2BZF5c1RVLKZ32sXlWvbt1Xs9eI8RuWSe0cVu7PgUv3nVhsw
ilOGJFkEGdDFxYsMRSE8s/N+w7KEy9BxX714fjTLxXjRnHNHDFlEbt5WanZ1PFVptAbVoJUrGgTL
k3Qq4Cv4C1v157HT+qgJVcb7d32YxUvi8FKwuga+TardBzmLJh3bUVKMkrn19aXXquNZj/A7WDtM
4LMr/Url3Lsk/Q0gJ4prv+SIsccNY4NHmgWNFlP1xDdTVbhJJiCMFduXxQcFP71uNlZqFv22DIwk
H+6WBLS7XZRuHHliSe4DzAITupnqRN10CjmHaUw5FLOatPdehbNP7KFzbSGgsdN2iuv59GfztfdK
C1j7kjKfHENDJMJhw1eNB1Uj+1mo6FxG7efPcQceQB6wTKF9+SP7Vx59e8FgLWQlDyFIn7o4meBy
V7JqWkhEqf5VtHYZqHnw8f2AckqwsRcdENeZv4DzIDxuZLJ2ANpTQiDLPR+husWRsoHPu33VJo+d
fTw5apskn18Wd0ktzMFR1JPrmpPqmeIBzeV7dniDtIi60cbJomfZziYGNxf4iostz70tPUxJjBhc
eF4KMIBsev5eKQSaV8PTTZMyKr6vmzaFn+oRShpEw6iJ/Zz6oSjLUaR0XZKUgmAtK5ZGE7K3dfx3
lHv1DlXKEbtt/7kafcGPXudt2FwopYhNMfFYaDS0DWhq78u1HXr/NhTX7yb5JtY1ZdmIxCaGeEnx
ac2YJr+QN9/E7R4wnGzyJoo//L8EbMb6Q+xASeg3mxOwMFhIFofvhjIkwMEz2e+lr4G7rhNTk0Eb
ONme42u+h5j6T3Os6UFWgXVCLjYsMqIbN5aIdccu4QYKzBBs3ZYXlYcKHFcAzk2+Xh0FZVX9I42B
Y1KukB68/TbBVAlQyftaPTt1Hgm4jxBKM5y+3DSPMNOy1F/hVCfE8ZDW6K0rcHrdoNvpsCxvmlMs
iFc9rWhx9EJxLiX/XC7H6D+9eQyPkTB9KJM342dwDjpEI1PANlXtsFygucMVdoU0z8HWMY0rD6vc
FvQzFPp2lAOQrKbSdNtpN6Od1Vsiz7IhnxqpgiT9x67HHpVFVFiMGWyYD5MHN7miM7+qKpob8sav
+xSeHEEBB0/oJzWCzohrRb7FOqSS1K/nhjiRkzcUszWwI+ZHwh9pSDGLFXsangMuiYVSNSoeh/0+
d1JokJwjXoyBAZXO62mqSnMett2TXVktRuxnWfnXZv7EprbfG/zCX4bZ187gVnXrJFBojMNYLbCf
LS9imMUGKc7+mwu2kE0ytlm9E2aLuJrJlLn/PURl4msV4hceoMt7N0dpKZgZd1rafSElRc2k3oos
Un4lEaZhbsg2OlQx6l3/LidS+y/evnqoBPKgZY3v+P1bddS60Sfm121c65lBsUUA1PcTA0Qb5niQ
17xV0fGOw4O6IxipqJ9sZKLL1n/cWR3QjRuY/ioYXTaIuvTtNkwOOWsNNMRfc6uGgqz0+JJrYt4v
hq2K5nxL9PpmkwXndxIyPtxrDnkpUFDacNvAr4Fg7tlXI+D9hXjY5yXFSJQ3muJbOkqqbCYFZvps
LEdhz7W6jFYoYlZleotzmyCOtdu743sKa1TNNdow+3lvi43LE+HP/NHAaK/xK/lgT1SshYDAHoei
NiFbxV5E/rdNDTR+BJhIZTiSKgMdFYeI0yAH3CBUnQJcWOKJuv8F8FsR7vc4OWabkuJAAul96/3D
pRP4mhAjJqumpggzk1YbnQPsuK3QXBdV/9hRK9a0FXTk6a2lGbtiF+9hBZty+DyR39QM59ORzOxG
jt65cwnEBIOWlIfaGp446RlM9xJIQRyohBXZ5vv4btCiwXIZg3kh1biOtscCeqbnvlB/BvvMeY8f
3/9jYV88YVKpWKxD6n52J/1/Ij2qRvYVYfk1ML1G6o4kH679Mv384P3YYNqEIX1XKibTV1rqvyby
PqCvP/iatt0XniQNyYvRiYtX+WHGWwTf1IlSCqvd67KJCe2v6HL+sWUc5CdcVWR0uEj71163R7Xo
IKYrZLZHn6SyZvqkj6Di0KWUbxmp7Jzx3iUEJ2VK1Q1G8e6uR3i8Py4+HvnwPtQiVzcjB1uVILm5
cJoi+tABVUecuWLRbcDxREKtQvnKo7Sk9S7EYL64LvixPIYUFzXBOKW7pLUKP2+NOK45FW5cZ+xY
on8uIGlGh3DP0G+fTDjDF0W3TDSQ1/Nrtw9ynhFmKUmyLfZmbP4lWNBhqYfs9im1xqnZERJyxHg6
FgEkvS1hu87dYpeZ62ls/GsRFWec2M2jt0xxDP/SFd4gfwfKurr2q9P7Ss5uFXzA6m1P1SvVqVNQ
TpGJ+RzmN5UaIEmR/Mrt3CLWc7ch1YCYRxhCRyDArmJrif46yQL5nnVWIXTGsS4WgTYZr8/0oSw2
LmttDDlBMYHAqbNKQ5vBSGS4OI2TkBrrYOAR8RwEfTP4lnupHiPLY6X9tLeyw3Z2mZcITyRl2X1g
AfYccW41Msu+z1mEKIltXDhrXNM468fUac2vYAoXk2qCpQb+1Qsf+8+PncccOzy9fXSMJaF9OCW2
ynhezXy0SbSjaWfGVlCCfeFObBcAWsakxcSzkT1t/uPpUrFFGsmCELud/oTk/RewByCHPmpDdB+O
oSFSRQ9m80G2VsWaA/e+o5taCBTGOwdPqKn17jHxwdM1JTCcCOyJsh8NU+TOZ4pzdKBeQrNUS6/5
UCNIhU0/BG7mdldoIpjN60KeAcYWQGoVPeBmZkFBTfPhdI+Mn6JFbnUMSV/Kn+bgRhg1svZ417qX
iHS8RqYeKbvgXFOIwbNSZ+EUjx3DyodJO3eSAlg1qoLH5H9Fbm8EDcSypvyR6HlaHXP8o9KId4zj
AcqZ4vaUDTHfAS1RNncM5kruGIL/ae1f1SShTDPl4KzUmI+qc/Gq4/hmhba56W+BSAe0nyKbUg7R
GDkXLPS45CBcP/NP2Je5AZo10Js5m+Pt9pljhTjBVgEGq3nx4brrwNU9/h/oGAmsIi4ASAbni9Tx
LnUyMZ7hYvPeapo2D8fVcRNsxdLpNFJ+WAuFe2o1NM4DzDx7FDPE6+tdkX3FRlw3n2uxKYItgUWm
TwZsgFDuAVmmSKSmkGcJfE3of1mEwulB0/8lrCztx4k03G+WVm5SiGuNZP++I3YArelGDo7fLCai
Y3m8Iz2DugqxlrAp8AhHCM7AdQnr9hrKAXVLftlF/O4zz/SY1mUuBpeMldjFpUh2ke6yFC8Y87zK
zLAiSFV/8AXcJr8oMcl6YoHTfkF9R/khhoISob0V6l9a6zfJUoYQ1Pj9tw0JomNHKU//64r8o2y+
lUw36vgaUHvOdHsR/Eg6YFVq/+voGH90uEgS2POwEsZXcyjIDWCBJumqJ8GCyO3Z5d0YhDYU68Ob
Fk++F+4RgR20/eKZDUbcqD2jEZa0TykSXL3svYrtgnu1sl7rDvIBT6fnLE7KOYlKKchKYfWSZx7h
d+3rHhjUvAJ2hV/OdcjoTFENZW5kc3RyZWFtDWVuZG9iag0xNjkgMCBvYmoNPDwgDS9UeXBlIC9Q
YWdlIA0vUGFyZW50IDI5MSAwIFIgDS9SZXNvdXJjZXMgMTcwIDAgUiANL0NvbnRlbnRzIDE3MSAw
IFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSAN
L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE3MCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0
IF0gDS9Gb250IDw8IC9GMiAyMTAgMCBSIC9GMTcgMjIxIDAgUiAvVFQyIDI5OCAwIFIgL1RUNCAz
MDMgMCBSIC9UVDYgMzA2IDAgUiAvVFQ4IDMwOCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAz
MTEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTcx
IDAgb2JqDTw8IC9MZW5ndGggODEwOCA+PiANc3RyZWFtDQpvWUUUXzqM9l4WyWH/hjr3xxu1RJeq
NaESACVK1TiZx7DRzTf480lehzxah8bq5mbgfezCUeA6ImbpPghNRFUxZXSpIKWKvEqhv7jgTvff
c67GPvoEHD99Ekq/WUYArp0uQV/t+qMaBSwiIZQwB3w79Rmqo9MTq2CyenfY1OdXbgHsHZ2oE/a9
yYo+2lnsP+djiqYbK4HtlOUCxV/Trchn4xpQIZMP/iyk+c8DfqwIfhel8cGEktJhfct3sXPjCq2L
Teex7aEluIGccKXQ1vzufuw8URj0hgmCDb7G+kpY3vPNXET8xlqdXkP/gx/Kn1J9DLKt9Y/Lukpn
dQzpK92OKEDoH0fzmWg79MP7rPagpRSCvaadsmKTvW8KzNgut/MoPBCmK5b0jKl84GHZiczZVIXz
XQ0UmvsqhwlJ+hUZ1zr6767UZLgfObzU90xy7Lco9wkRvJseoHPx6legLFhB09md+QP/UTgUFGIz
Yi+iWgAC88ugjTo7Tq9Kd+Yh7xLq6WOFpZRzauqXRsIC0rqQvatSt3TVpOnRiZ0NfVQenahQMXWl
H/FrOP1x4nZmcA5M1yJ0raRuaqKEu8fBwFm54uWmx2FQJS2PHKrUEN1BFX9zx2uTgbU8MRE0Aps5
i1t8cTryp/sSbHuHIDpD6nXUMh5EjVXzX6I/JEApnGySBK0YV6gZL14qUqch4e7gEJdD54xOsho1
pR2O9Fnj9Uwee9A/ECsUYr7wxEkNhQ7GkdG+ns4W0Ye8X5+h653QpPc3Em/jKJkl+/Bcn8YJcIGd
8JGZKeaNWJTbc2GnLaR0WHyVo+H80xNMJ56L+mWIhXmB2bkVbSQV4r67RXg4XVAlCGnVw0WRFqKX
sHZcqVpfzLsjxmvoGH+ZZsxYKEftgqCT817f6jF/Sl35zIxMDbdY9Mer8AuirIuyHaMqN0SFMjWx
zjvqEP7XzMSz8hmwxeLwfocXmgzlwvF/rn0gcNq4vkrGDZ5U6P32QAa5Bf4zEkRWkURqnmelwgJH
4pOve7E8MoT+yr8jmmgXtWOAeaBdrqQrnq0bJ0k5FJyti7mCs72ti19kWynvRIJPSCC0C6ef6QKf
9GxQTMTSdYNSGEYxFjYKie3zV12Xd+m9Nn4guSGsoMk1I7bn9Y+19TI5ER/0NuiZP9co5TnHufEC
qPG/n8qe8RmkueVwjc92hqt9an9ZpmwSu6bq9tQBR0N3GTA7ITZQ1pXKZbt7GpssvvuWhVr7pJ7r
OMS/2UJ8em6lvyS1rzC7giXk0zH39lne4/1d+qXor4HGM68B1xs0wsWFIs+OoEN47TUAsJ1NdTqd
rqs9s2S/Zy7r1QNgnn1nix+IxZyx3qPV3zZ5lpcxMqCo54rdrHaOILj+Z0YyGZTBzDuM17OnzRdJ
8zMXKtJHO5USTTlpjtC1EgZCgZZKOG+2kaBRaz/PwU5UqPzGIuOMgNx5zcMwKLipSlxuMltrfR5j
vsgG1rhFu50zO4O9bhr6A5316cNW3lv4blTZkJWtLmz855gkXGQLiak35A6HatCpqPpNZDBWF3eE
/WY1IKJxeyRbaed2orKXBeMqP+fWZi4VX2kP0UWCHvoY+Y+Xspv0coaxqIDEHVnLJ5p6zTEXHd3/
KLLb6fptWmhEkwfrs7X7Q1+f9YqK9Tpn9NkVrh6MamOqpumy4yP9730pHmFkKNTed3tg8eZ593Gd
aun6rFthhd2yhxPZam8RPpb69ljnKZyt0etaPF1/LtBhqUH6tkxkU8N8nm4575ulD1gqMRD7XCct
HaETkEHgcGts2dJDjPmf/MxGf09U5xQtHqUZHf7wmDiszuunITk/VqdUg3xnSl2UCqP+vgYaQDy1
JHkjSI81k+R5OhJ9yyc/t5mQwGxvyeOXy2+MrMRQFSqhIPv6diw5G6f7b0VCD8AZYilhoJHntf+k
f6CpRgBlWN8XOf+Gf6PMsiUOtVfaASlvPsX8rCA8iMMKwt60gA5SspTN7zAdKb2gtRBVEwob6eyz
ifkkTgg8cGfddiWzeTLzvbo7qYhibGoGlE/WVxpYmbeKPQET/BBvnR31jvqMMBOmlTJj+TojmRkr
IukVVj0E+c1yGFcHKfkL3rky+74TyiJamJOivhE35dbuI0Z0e5WSG4ZcCXPZIhKbxnXdQ8JlHOXF
8e4x8mXzte+kF18kg0WH9m1BR9wx4c/CRdC1eUpvqvxidW/oGpuppWYm85pT39C1iTGQ2YKx7FcO
jX2oJ+hqAE7EG2MBNE6AcwweoLYkvK8QKbBkA+qYs2cF1SALzIeDN+C7R8f9IPlhFRqsDaMGemse
ilKoao2JaqAFGaqKacQ1ka65ZrxKxwB4nYl6t/YrmeGehcySGZkFUpu9OCTgAMB9thCqMx+wZAxF
HzjV3hg56SocjCQ+lEun7/n/2S6dGL/89z8VcI59heBnPJ7EeiE3/Vli6c/en7dpMhhLRrd2GLfw
ZjlqyA4sZApJRlzNrum7WPEdfJJqZ9PcgMyyTw3qO2KmByx/xUlsm/2hEtA0pmoTW92xozxqUo63
I2r+/3wCNvZas64RLyqDUWQIcy4pFK2ZktSMwIoK58L9rJwCoGZKMeepndUQRnSh+qbS1Dew4EAS
JMLHA6BCqKbbtR1oUhTfgw1a08RTamRJFjsVy/32oT5E8Jx5Ihw8PSVFxmBgT7wrdW2SMhOoOiAB
aiKjbyVk7HHcLo/r1eC9+BFoZZSXdp5eSm/C4H53kCgLiJB4CheQAaSOPo/MkEQbG4WM3Cyd7ABi
PJX4wrkTEtKdo52GkMok8YtnDG9fTsFNFvt2bhrGdLEqNCqXAzcXvWq0iBW3zHuwfI8mLVQCCrk/
ZkRRXKUMzVAmmdTgDuo6+rE+mZn2HcGYp0xE+ybB0opr3oL/C3IupG/iqenW+0QiQ/5/dBJE6Tzz
hbWyv0JasxldzfwraLIMcQ9pstCe4UYRDJApX/IzSJK5DKaV+9nN93DPFR9+Nb0EetjQtDVdkapL
zO4w0qlz2BXNfF7KRSFHS3tnGP8UmkhlZN6YHF2zGUURTeP06T+fqmYjp5QDNokuDgTy4lAih0o9
Nf+1dJG7ooIr8eE21JSFW/DioPpUu4mRk0UWYqKtXbDHLM58nzvCikCDLAn15557ecfNm0p2W/KB
xBYScTkxzrXgdASZzrBb0dK8dRbpJqnIAV/xZDGIqDHn7vXmj4/eAraKSef7RBHoofYTNptAjGo5
lw8KDf/+Ld7LmGqZlduwWvSjRDxlMeYTIoofD5YVtzuA9d2TgEb5mRY3yfF6v+sqqcKf9LqC4iQT
Alm4f7BHKJsY/8eZ9ij48zcuE0hHN58ExW8F5yUwUbY2fDsg/YAmzAq4lnrHrXgu6rx9FX6ALE/9
asNF1zWQXGuCn2ps69/RoOJHgSwaogAWQAMJ3EhK7ZJUHlPC4/yKBsm9FJ1JlJueVI8KHYuoK8g2
NXlH0N7jDissR/yfiT2k0cbCTZ5s6StYlmOuCMRlVmsVngM/vDntnbng/Tn/tl+mTlxsTJsby1Aw
ccYdz5RNKOBX7eAPchCHMo/9qjRPxGwiBb99Izts0bYHCZpDrk0XdyGSelCNZlSNAZpwPUmHXgx7
u4kocREtAO3/wkNibguta/ca5pWTyAGuyWyF2Af9ZYKNXoR4IFoSIxGb+M81eaKgWGB1sEVi8Xss
4gy944WnTtYh6RImL1h8AgqHDlBPuZy9rmDTatKwjazkONbVrVmA1a6wuWvhDyhdtkB0Vqfm5Rw9
XqFioBv6/buhixI/dVqMBPlckcB0Ntkooh0Nr+z2pnm4OxhwG8xjIKj6prnWIry2LYXI+/TEuRP/
EXFUUIkxfNc0b6PRxDJ0AkPnreSBAN1vOU0TjbvSTBwwfzva+u+5ZrCeOsZbDxbsg3zzoNUS926K
icPZ8bPFTP7I1ohV8tg4Bxgp24PT+9Z9FoaUMXa5CaSC/mfM7A0ZIYitNHRMl6eJUsh4EnytkUmf
3BMz7st4y6M4bU0SnUpXUOU3LbfXrBNsgMsF3wnXdZrt/vjxAbsVVLygpz5uWan/3yU1uXoM5JGU
2nrgHxqpxU+7RNJAPqwVDgNXOTnrOLa6KAOWZt6h00u1zyPmCTcT51/5Ebz4PAaRldOBIhfL5V/u
THsK6+SSfYa0br1UQzVZpb/dvx63gHk/thzIf5s2iWePXmEMlrs8rGp82HS1X4siF2QZIhj6qorv
x+FGTJH/CJ9m/VALqi3LW7SuT23BrNjNiX9mOO/L32sH5DO9CVjqSq1eWHq/odvulv7r7z/7M2lW
boi/7z2ggvFIdruXYoqhBw9x9MbDw8imE4+ZPJYk/cbscL3OC2uqMKPfqWZkXVe35UYeps8/Fvef
8H09fuzvS5Y/Y0U4VVfuXLcbbLWO9KkORNGwbQDyJXG+IsommA1uGa/dzO5Fbxj3jOPMq7Zq9Ds6
l7kDLjEFp6XXBvZYLhs1kQXMPHXpIMb40HQ3ciqxY6fp+BGZsPf2nPU5Mp5kLys/Cw+dfxDhEEMK
5ElFjBNIOBFMT/Q12eiV3BstZ8dS71BeHPicJFQZOe1IC1l+nD6SaQJh8/YoxILsAt88UgiKhq+w
Et2srmddEuHL99+HNP89MNPGvfaX8T5iSbhG+2ZaJRbPIuOxTxd6YFFYnBASW/+IqorUe0z+yWow
7eWH4YWINZU4uV9fxd1X+evfCMz0oCxZs+5zKzmwtR0kCmaibccX1ehfiwmyJ6cSIvhOxj5aAt44
UlrewOBn60vJPOGQKz7MhdgUsaGOLl/83Hb29gD/mOa5PFAZtM/cXnZ/J0vIB8WO7K0joKexk2/R
5zuVoCGehCJDef5S5bPO7dlVrYcPhL3ZkwfhH79bHMd0ZuiZAongKtwN3nX0ExwZaFni0uP3KQgD
Zv7joPk9cON/vix29daUoJ4LyNsIgC2KZqYZ4NjU48u9G0U6S+krk+y0gRTzzV5udk/z1zLWy3qB
5BdpAlOsj/sxAvuUMisJfWGOwXyWCI/ZgJ1wknlaqf/5Hn++MUN1/3aOtw25O7/pfwQL8DKqzjxi
2zDRDo2fhhJynA03ULScLS3ixNI/Suas3QrfV8sFXdHXsUQW1tsqsYwJdCLUBAFMZYq6IoPF36QW
J5PTsDJoCLgN7fyGM6EXnOzTi7baDPCjB9o3VA5mFxL3wLEhwMHy5CGLj4LBR8Q7re1PP1ZwgHGh
H9/Xzwvb+KXY4EPj3sut78AHZRk7WohUd/qRlt9eTmBJsks17cSX4isdoTGcqTS4LmFsrbzyOQDY
BHPESDS0qwaADY+NcYvKflBdxqiFnoDX+o6kvxgyq8C9S8wtW/AS4wSw4na+YepiWudF0moDVuzN
hs7YEAhWug/N41y9lMzp0pifm85i6ijFmfWvP1SC2ueKwXpD3V++eHowHA+lBDDzLD4MkTHqUVr3
DYuoZh+z8BAsVODWLREsGsqbuhucsPvPQn4YjPOEJ+p1qvX09Jg2JjTchbHIurHQd1iK/qwNYwON
YwtvYk2t+0pAdxKLcD6jMMkC/LiFeAZoIwlMV3AI1YT11cmE3LhcfCSq0KePnU0YS0+1pixLCT9j
0Czp8wQTRSbgDxnmMJdMzHWRRyqZ9bKRzLxruhccbxJnobMe7OpPBcsDiAk3UWXUZ/3nD3E0tMBT
KOrGtIyUOAWya9oYwluQ5J1OFiNvHZFlzZGj30CDG5SQMB3RNiBu+sgbtLvTiozZBeS2HL00WUsV
Lm/Y0iOXna9DdJvrDuDc2GLptjwHJW82iA0NLx08uiRJ6glb05VdB5vUoDN9d3YWFkypi2xHzruK
ChFv3sdz4WGvzamKGMndTW7fGF2e+kZM9iaYmsfh8AWPVQddaGZyna6kK2+v7k28766ftmqVINu+
sYveqmqwgDWeFjJO4u8piUplAUmp7Til2wZ1WQf8wuTqlirkemOIRC7+lCrFoNqTiRFLlnhBsWAr
uffI+1uFWi8ddiQlyxTfDOW85VK+j8DOn0rdiJgiN9bt8y/JjMqSaSgE9JGxmqpoYd8pYHHWWm2m
LmSmoDkws67FXKWKWOlq8OXgYWmfbkz/sldYpKBQ/KcJgy9dViOwGrxBReZrbEumw2UhltQusUck
+HgYU8ELFc1cVnlDUM7XF42XDWMvLzDTNEPg1X07pzsfvGSE1vCtJQyGYyu44MeRPemAYoQy/es+
jvdtamhF/F8kqde4M4PIAPGMYfPA6/crDKX2dR6p9O+yt0gHTyvycN97kVwiu5yLlFgy8KBcz6Sf
w9HUlyLcNtOKTjDg0grB4tloYDpGtixKDitxs4poAFHx4RGGf5NIJ4nw/bFwmonZ9qLO3o6gQvxV
XNB+eKNqYJR62i0iWhMDataUqGOSGH/v4Zxk/y9nDzhF3hhxUzqdOcMC+dz/Qemot59Qhl52KFHx
cpwniA6PGUvSpA+w9CMaOMefZcSHp60RjvG1s+ZU2AB1xWaiJaIUr2k83Qwrb6cGDAIdfKkbTNTF
7Fhu2GvBbi2DyTZS8IvLS+ssI/GvaU+k9rZfzJKTNBapEOKwVqk54EW5KQsdTRfJxC087y4DqWsE
SCFSuRlPCvO09DjI7lwLGp1OUtpXQZFeRy9fKDX6Xnu9HY3qyGB5IuUK1becKcEZSdrGEyaYCYpt
p+TdQRuZcF9oavV1bVSkdrZkW3xtd0aLk9tUVU6p98QH1G/ab2Y5RiX1qa+u/fK/juViLwX2T+g0
TGZU/HlJCgXAFqnl6gDfUaUgngFijqe5hblEvhs1GQCDWN2xlCb/XCzx4mftfYqfDDLHU1vddXZM
GxTEcDbWrmKKFcfQ45jYZjV+zf/7bnBmswygkHzHA3LmUBgDIhCGEhAi1J8v3lAQ5mBlwjVUlKOU
jEVzK6J1nwZcLb0wINYZMYbrf/nx/6D9rvLh9oRfIZuFhM9lrqXSgfrj/bSyRCYh01/1f4c3/hBP
RKzn3NubQXAIK2hXJNusY6nJXmF8GTgmPkoH+mhmUBUVISGiQxMAxgB6UJGwbCe28IYdpyWIZ/nG
No87Clli5XUOv0thmqh/1ISUzbtnYTBh6Nuzaqw5tML9M2NJJBzPpvF4Zuxt9pByhPxcMl19XcSk
EENi4bubcOEQJHHjQ3JzFKsp+9KAK/kzurCsiL7bJd/c8rjnQiJGlGnvR4xsg9qkCwuy+4RhQUa2
i/lkmkptUfYWqJ2Z21u6LiegUA1YFgbjN3vr9AXRkubbESUtPrTn62uw6g+jNkVDC4UpZqh+Kbbr
gK8sZbt0+LK41h57Q5eTFCsG+VrTn9aDcwKTrXvFr6vxh42Z5gBYc2MCgcqV/0VsqRdmwW7bi794
fIh3HWf5FPyYo5JOfYOhIvKiUaMpWJQl3NlL7jPcHKceGDYJ4sqKBSzBD1YLHsybIIfpLLZNkl4v
u1Z5iJP/qdwdJCWe2dz/MVfCfKIyzfTF/M7Ex7WJSkogL5GQZ0IULl9poFuJbYazSP2DGQZjUPDu
Z2qhe2MUeBc5jEuUkbmsoFdr1xo8fV4MLiwq8x+fUWw76V4KLQxAkkSXdi0SrGP8ZyvcXyKRc/t8
/DnsLu/b3tW3vIKR3UMlifFpDEJbS/BpbyXy8q2TfpTjp8ZgsU6L9+i0hbC1SosGjWKORoaDO6V8
NWH6jZpuZCzFnR2rHA/YqdvaAkRSnujxrcVXnhoMCFm4jDaNcZp/m9peGR2mfa+0KwRxk6yTmzb6
ZRXV3fsTDY9g7JS7dVev39GG2ejibcCexJUmp7u2swGNasILiP1GrkfMWBpHRu0IVMig7mXSdHWn
xYahMZd0zbLcIKeOd63s8tEeO+S7Q6gpofj3J/CT1jJMnJX2Vga72/5RcnKNxl8MIHPc1xoWvjiF
rU0t/BWY30y7PZrFY2si3jX44KDXd037clMrXjpU3tMFOjevMSr61H/XLVJOw30fWPHrLWTo4a1s
IQc+XZsRFdgjdY17ZqPEi0myKEMfro/ut1WkiS0mgzfA/SNMUcLOIuN4Rq33poawLpQkSPspXEJr
xufPuhL9viTBe6jnDlygBj+wReWFRPDAj0paXVTy55wmvkbBDCrtAaWyHtb2OWoIUdYGPC311FtI
shOFWPxMtWdRISDMHpPBfGhWqA4MvAhG9169f5LEcjfy1huK24yCjpPdBNcU3QU5La3Qh+KQE38f
JwurBto1s5JOEYHnEI8yS/e6kO46N8VKhdFKtZESiks7GCmI60hbOjteuJwSJWS7zsmIMcniGlN5
1h4fvgd885mLNUpU3IvfJTYAlwE1CUXa3bbfIGx7WzvLp6+nRyrsPActj+r1vt+cDxFWptKYiM8F
z1d12vgX7+4nV50pHLhwSVADiobfR+qbTBWqIV+NI9PCCNgTkw59W3ksg08uPqR1bnyFiXpXwGV9
77YDT1onf1Ax2cHbwHFz07S0JkvC5sXQMvBpyk16073q/NZKpOAM0C8Dij5UcEXjUW74vjcyBaOj
cvc/a3OlYgRjpCGG4GZ+QrZYdqvngmrXV0V5nzPkcaw7pAOI300GBiD04zj5nVvzZouEB4U+3BCJ
LhiFqhN765yvPtI8oAa/aOjdbWbsDryXamUOZH41clEmpN61uHMt9P8wrFTFDPtB7Boy6PYlvqNz
OQoLgcDF+i+EmpO3hwx2M0Owcboia3cjl3kOGun54gAvxjCIptaWXNGMhNwDClj9Xb8MWoLfF+AZ
ZDp5VjN1ccPhXmJQaaA3Jq1svslDX/ReR3c1sSd3EV2QpZzyQJ8wYo+mpr2LSWEpQbfXl20/Q3G4
aXlMq8tiYavRcrYzetpO+iRsPvIg1je/gr2meRqIJQIKO7fEYJ+qVEHuM0arz5SlOvDXMNKq7nNc
SRdisnhVw9CRe7V2UNCM7COhh5KT23jO1drKDQpGkQwVwaEQBBTsSL7g+1B03zjfPKMV9gZH4IY1
TYeInA1e/lWJKOWyQgC2LxILckQ0TErL/Jgrs5LdUv556+RWhalCfAx1lnbdYGgcsWmYbMiGAZCt
SFbfqJp9kIrE52uHq9iVybUuSbuAYQu1TFYW3QrJnV5UgyC4zgwYJ/ksZnI4Cy+9gdGJXhZ6qIo5
AUNk/WJDCFac4sQJkL2y9xvz7fIGaLMMXwF14d3BOPVGtqdq5h0slEJQvCaBWYPDdvxp940IiW9V
qFs4Rm3FoY2tFuub79PGW94WssQID0sN7hKb4bWp2ZpXyWMfBSbHH2gtjU8s4PFj8eYrnSzP2kDK
kTnDsju73iApj/Y+l+RsLUuRZRAAbgj+JrzMFdPDrPOuIBr0dfTMZIJPjrWFCq4n9nQGpgzJuda3
48ZnkN/TiDzpNmgrsKB4EBODs3GVuN1rBynKO2s2qMmo2O2s+l/hHsfglvv7jfPj7nr7hHt0qSMO
QgW6Z5pqHV6vyeMA3JgWkUYJuLM+nYef4dtkY5G59MKoK0vTYwSt/wiRlSzQCSYXiaVEe/UQHVUH
uv5sYDzxMkmxR7ha85ss0q2wKOaN6IML/lZLjl3FPbLmETu06lsTcDCnw7KxblwR+sgdvQPcdysQ
xQvAQ418hmVyPIC0ESC4QSqr4OfmmA7v58bUMuWFaFmjBTAbTvmeg1M2QT+RR0NH2Kn7SejbC8yM
J27RZVy6jXzuJ/pJeQxZmTODzWufKF/tk6ceYv+bJT1UuK/H8jxI0yt9maTXUgwrdk0AOTIE0ZzI
AgAkrNjMVbu7hsuDkefLWIXZsWMkjjWoBjNXYu7e9egVsENpyhJgSOXdsBiEDKoV4/fbcDkvxUQ4
jDirr3cZxqdqa7TIHU0TyObAc0QILUBXBvgpkEnnKlQHUm4H9SqRu25kBaz3acdk1ry7RMMlPwhs
2nbJiycT1H5/D9XHQ6RM3/g02krgnPEQ8aSPWYHoeim5JdyS9t1Yn7Ey+QlXyXOW4aMJvs7THnQy
it5ipnau+kVcYd559UM9aAAw6MYA74Teynyt7mE0ncrZGpc5OyUMwNQ5IrEPa4FcTKhb0spjOu23
m87xDw3/bkL68dJ/yHSDBUj/25y2HNxO4278efm5hFdvKhMkbtaCCz5LXCZDS5HfIaw9WtkMOEk/
Q1vC/6ayVvUZ50IO1NBuZrrtVYyQHA4klm/dRmTpa+kR8bBK8LoyXtfn1+OgbvFGQPlE/FLd6lcG
eb4P2gwqorzfPL+42MD7DXAkMYMQmgOA1ohmY4jmI10juHiAjgzIcxVuzN8T1fNCXF6gQXj5HpS/
gE/uhM/2ByNmZSts+auA8gKiIuJx8CoinF6lE1bRVXmkk562Js0solndf29JIF9AbG5byeUOTBXN
/Lg7SBEndLDzCXMvsh6dqyuA/MtQ+4WXKb87do/0jaTIYcUIMppLjAZ7RnFigZ/IyExfxtVPP2Ir
6y9XbAFvV1bp4ZtzOnuLh4qoJhC2AlYEea+MedsXzwZJ39Mpoj4l0lyV/u0+7CWkWBnOejnfGNVa
iQzbapzYU7tbDDttrr/PoC4uw4LqOcypbhcKKmgiD89BoFY0H5duMUE/1EpS2zHWgpLSG6jactd5
UZ5XOvKAXFoB48H3Gqb0UHPkxk45ZoYW2RfXw3FF3kepqrk9GTYQGUIDpWFOCUdo+Q5yKc0S+A19
p985kPspvrkV0QgdqIGOz/vkdm6qF4cxIq5Y9y97jegbqXlUoicIDMuT+x4AZH0yzmFqztdlMhgx
PfFrRwGjzo+qMGi/uAYau20wqNM+RxjN+U4IbOuyu6xLaM6IMaf0aRy5AN0hrw0dOsC0Kbq1nwzA
xGb5T4JkGS+lpNu3P84DcSJmyc0GnQLrRtUmMxbkdOdOZ+mYW3wd1t7KqUIHQqH3CA1lbmRzdHJl
YW0NZW5kb2JqDTE3MiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjkxIDAgUiANL1Jl
c291cmNlcyAxNzMgMCBSIA0vQ29udGVudHMgMTc0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3
OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTcz
IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDIxMCAwIFIg
L0YxNyAyMjEgMCBSIC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYgMCBSIC9UVDgg
MzA4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8
IC9DczUgMzAwIDAgUiA+PiANPj4gDWVuZG9iag0xNzQgMCBvYmoNPDwgL0xlbmd0aCA5NDg0ID4+
IA1zdHJlYW0NCuyJP+Vfuz6uP6kDZBAyv7nYyvktO3zEOUyS2EdMNw9cb6yGrSHQyZMqTEzIqyqO
wTr5knmAsw01AFHQrwDgLaft3DzsttdsBg9M0Gn5BbtBV0icTXRt4EIuGZvbXpbAD3bVnSo72MCB
ejho4mi1qShRfVZBweJCBCJKBYlDjrXVj/h+J886RGuxANiRrIci5hyFcs/YeSYGaU+wcnTSdFLi
q4Uye26xsbX6LJJFCpYR0abZ7CCOrdPOhUTqHJkX86J4//G1lceGYKD6wN0k0K/h6iQS9pa5uQX3
h1sxuPqArXqlkoLlejRB76ypXFeiP1x9GRoUXdRZ1+XqNXg9PF4iM9VfgauI6rmQZTYCc7VJN6bP
ft/lQnhIDQ4+knctpLjHqJ/XjitjvUTL38/4/klOrjrGgl9ecuQXWAHJI3/0C6iSFevoN5coevi4
OfuK4wS/qhNjYAuQOeUKMX5lkO4AooaETszQiiS0GYQsWDF6XgJwmBQGQUij/eQTauKToAVGk549
EOl7xr6n3NrYDP4o2UqDlpP4nvueASvE0A493QG48zobt9twAmhqZzmmt6uLrDTHgqTX1Y9pxpSF
YZUXdvNL7t7DOZEvVbxIGxNx61z1WpEblnDRasaRVR/KhL5F+v6Trp9vdv3coFnCPSzh0pTaHrh8
+XiabqoZeqe7k4z3o+QZ6Vw7GmPUpJCedNTG2Om+VIIlGZGAxyalRD4MTTqng1LJckAIHZwxe6kR
bXTue1Eo5v1/n9LASd2NBLS+G5Az3dGH6TGpqBieifbO5pJG5MYAVFZtFyqndO2mzGosccnXDunK
UrowDWxHvZv3XfEPfdH0uvUKCTy1GQ4VmyWiiGOT4AH8ANR3AS0iVoC06VK93MLg/pyIyyxxFRyy
gOAocF4175CLux1rTVU87HskJ0+Y4Bi1obGhyNJi09RdAAR+7c0CeQ5vrV221dqt2f6W1+8ioqAj
jAqtpRlbDQGi+xAyHTFW/7wzfvQcoai6Vb1bYiYlewRA0X1+/A2J5Ys6xAxgut60xy/hhNf4QYt7
tyRzK5WiGc5+79sZGxCdMIuWmyy9UEwN9cp2Ckn5hGCxuGKKM1xQSv6K3E01vLg6DhOHroIvHOkg
91R9093bVE/X4HC5DeHkEh+dAYcBRYW9NIIsBmUzegWi+rCffZgBTh/AQZby0ih72dvu0GeRE/dT
WGwvmO2qYC8GLkmZEFHTSOz4jQviM3sva+cKDH/d1rlEWgChqzGuF2zXpNj6cDUi5+4ScsSiabdp
ZM5xjQup50kfW9DZ0Pgw8Bbuyfz+LGgA2LeSNJhmzFWkUVnSdrdrs/njjKZ429ge0USvdP23imeJ
h+akuGtPwy9FMGe+BFfPZpTazJgn5TSm/zXE99TaT7ScSZmhyS/0II7HMAfgp1A3xZNhDz5Nq10h
zsNOKKO7zL/nFeIDHDOAa5Lsv/Izd9WZt4n56mtKQmGWA6A2LvdUfp6bVgLQN4UjZXC9Q2W8vger
5CG4bs46z+UwPyABG3vlELTL2zmV4IPgloXvCu4NWZ4uyTAEA7kmhunrfI7xHY73F+RdsY+HHkxy
KwGxCJ/CcUHhurUdOxUvAANm3/A5umzaeN6DSbIkmm9MLj4fuhZ27uELrKvN2Sb3CRoWO7lnKeeC
RWg81yijRTJjZdvLUxZO4Xz+3xZy1S9282q8O6mO1VPtlj0xzs7ABkNqw2ZFS5gpINWc2H9zlNX5
fvvzNGhWJgc1cPqyKLqgFd1UFy6bDm5wA6v0VmML4ffX/Q09MOlavUchSSaABilaxcb3/Y5sHJxY
v9p3SX5DeIoJmTHn5m6lTDXWaqkWy4KVuXvkEb9wbcTI5VO4iLe+htxHSyCUyvVAkefoRvGaS0l3
ilWpeOVEB9Pww9DL/QA5I7lsO25IOFPP4O7zabxosPJH02UYUIetKWaSSjvAC+k8ngnSWKyrhja9
aME3IFE27/dki3pMfNme5YqM+IhKz9uTZh6eiZWWyYzRu1ReSEFpi/XxrgFVNYlCJXgnnaw9Ti1E
SFadfsdPq85DLIXU61feUUked0XldF9orLbamCckYh09BZl9ShA42ImT06a7uR959LyZne5+dwEM
1jGAYdJsAmlKlyaHjdsh7Rvt4Ty4ZOE9/KgMBSYVt2yGX9Y7h9KkDujOXILzuqIIMKBGfMYsf1ID
SGTXMnxaV22iaaii7UIpJwiMZvLYDzPTfQp7CddRw+bb1BJbpgVwxnK1OVGqxK+Ym0MyVAYX0SrE
l+1HoPlc/krhYjlbDHPSHIB+Nc6ojxxY0v1mBXdq5q3RLx5hRi57p/+IBlioqZGfTpMow3l45p2N
rPV434qVK5Bu2OBYWlBfPrYwgvCJ9VT2Nb2N8Xsk1LqVV+WH/Wzvy0+X2MqkXRsGb3iweRgO36Jb
EebicSW0FYlDWLuw+PupKepNB13rtfY8IXFnEAPDlzRdlGGTk35BhnhGX1PLuPLhrmb3Kf7b9rxD
hnbRb/vyJTbMEGTvwLZdg+3ngfy3FeyaujnHxTAltWBCgp88lmOV//7Pvz2dkJ4p2SrXt342gwXD
fnvviDDKsKJrpbTi1uUiein3+G0+638OJrHTcT25x8R02jhx2Sw7KTUOMSVN4z9b5xqfCLmw9hxa
wKKCopwVVwT8z4NL3A4AMzj9YEiw/y1bTQRCjmETQ7FfJ4P2EQXwJsE7YWrJ+EtNBAOg52wLOA5G
MBZGHeCE9le9ARpHqf6Zlx14i35pbT/7gqE8n+WMX7v6ZCyJaD0bV3G1XE1wv6DsEbIXgY0t6zox
DTgADp/e7IYFZWuuu0Xw28pQC0MGwrccFVHt1JiDTQ7urYqFvZ8DkUBO/xCGTd6uXoXcK1timMOB
EAbMFvXzVohxggH+qqTzEtIiOHC/CQsW62XJnPX8N/hCTWaOsmeV+toV7Bz0YtsA+Ds8nSdUca37
zzxAkvjWcvGqqLZdLN/uwAVK8t+fduQ5rfCKRvbXFAqCUsargs4mFyHBUhHMVRnlx2wwzOznHAeJ
Qtzul5UCty+TugYKzcpt6gLRdgFhDWOW7uWzm+Lg0zlOLktCXqgJLTlp8tROaLA5evYOkRQNSiQg
lzpT/Xv/wacUvI3Zyp0blTFkyggOpxWCxxTnJgHOTiGQJ6nOTMRzA3r1mMK495sGW22B27vbhlei
Rnf/5p/oPKvEB65oFVagqaL0TbxXkbEldtnOEwaNpmPt2bKssqtZJZKkWowvgAvfqRdWlQ8ZZrDB
CA3jj8vYWx9PjVd6W0A1dl/w7yg2SGXJgtq8uYoTamvQhplSfpphcmQe0l/qd/cwQ4xJeZ6B9nwB
71gPmlglwyrC5QfJgj1B457EfD+I7JzVOUBgYQB/ELxsecBwLifLZ+dQ1B9/5niBspqhOWQ2Rrbn
POAwT2mnc4hKkUZ3NGTXVd7WuzqOYBoAwySvZ4cHzPoU9VZh95fd9SG1HZNJHPUx0phWkmOXNOmp
VWlWpw5vWotCY9Q5SC9/++j0AdbZFc1vj6vEV6YFPWojMxbwC+LEwBWyTOJWfrD8OXDMe23O7xey
XKdWHgGdnWXegrtFrHCOBAj5ZCSRowJT13xuTSashl1oRXDvJlm0E8OXAFIf1vfcJzV5iVyHSh61
6efIFbsIfgO2FG3UnBKVBQD+YWRLuFg9NVPaR25q8WSzAOOgwHRvabeT+PokqNK80pR7LLns5GSp
8FGqeKjq3v1HRmKeR1Wd1QgJwtzPHhDn7gKBbYT+7ul1QLrH+glCGfWEViOEnDyAzePst/GBolxk
roRYlzngKe/42NT63AwVtZYjJn5sNPza1hvBHjhBJyp5HKPK2fp2+aAe/p/TgEWyVTb3FIomxv2b
TuzAvbvTCVW12IZpcuNQNbTXfOX7OW0UGQ+SXhB0hlO7uVatAlfnZ0duPM7OMfwJ140ql3KP4TDq
9QUjB1NgMUJhqgE15aWEa6dHCinBTVjC7B7ccVR4RUNstqn8hlGtolgpC0uMq91WLKeMPwfHVReM
jBIqpNRcvdvXbwQ5qkUfiJjlcfPMbOoW4OpZHui7/LvAekHyKBp+cpc0hxBjgRNU+kfo/XS9iS5U
rYLJb0fcQ7lsRFt5WWB3I2MZdn9Cc1BAiyU5/plHZuVbJh2BzPwwCFv49RF/FRLUqHANWb9qFq86
Ebo6g3ncBBH3ujbVZz9OY2DUFPbDVeYMD6SGtE/ML32eN2vSC8pAIHrP0aTHHXu5N0qHVVJHHWKx
vwKSU5/+fp0llsPwUfQlJQimiBBD8+FeGtAi4ls/0L/z+DngjK9ZeVNDygD2dtlSDafqt5CQXjk0
DtVYsdVywihSEGJQx+BKrbVhmsoKPjrK9kXdEU9S4l0TfDNVsUtY98I5txBkoZW6aIXNWoDDdrdM
yT1bCrST6qT8ORQOClrry7lV4crFWfndpvgTOsMGc8ie202UVtUZ0K08NJdgeYbg73YdsQ0CKnb/
M702b4QQo3+qsWo4tJOxHCHHy1zrD1JXljzKtCY3hBnmJgPOXQWrdpyew8fveAayzXDQqbi2owIu
qcqktXXyLI4sUAJJslOuuqOJIzVXK0auQPvfBQA8ZBcjk96HmxSkLNYvH3ecigV5nupSK1hsuLQx
vSZL+YPNHmSgv2qAjUv0Ro4yJMP34jItaMti3O0oBw3B50PoSPRo5RNMlEATbddmBFMYJPQrJX/C
6pOkivtyHvCEqGmcHiGwi0/Iubx27W8zYV6ektuuNZTLOazIbLeOLN/oVFbypyHsgMxMIpBVd+Ga
Y55WO7JK8gWSvW0Fj08Y13QCu3/vgPRQLj7XM+f9bHLLzmNS1F1U2XfBHMwTqW7W/V4nHehPxryc
bIwBCIeWbQJY69ZXuQK6q3kNLj3Jvne13X/wb5AXH7HDjhrFGOuTb15jTrHT27QckBiXTgTAwJk/
TNfIbozrQe1J7VmdvwuhJ6Snlj+fBBJMUn935VMqSjuQ2sk0uS3B6V3vYwy7Wont4WlWlyF1zAHR
/wJSgpj9Ccq4Prwz8AAYKUq/feh8KTpltibZQlu/tKa07i+ZaHmNVOAOxhCHD7M0TEh2GTlO1fz7
/XXiYOmadUBxLejJmn29Luk58pTZ7bxCUwoZ+wQ82cwhS+a5uLa8iMg7+PaviUaHZUqMFaqUALnN
dO4h+LpYPYXMb2pN64TkfrDxsm81tATO2RXzAMDtCHEP+jf6BupzDHA0CEOlIe8S2fR9Y/awsjEm
zIsaLFER5xEdKc/7s841YMbU8llfQkuoHlMAHPfKCKEgFvZ/13F+SYEXJwFeZwE6SH7c/q98Wl4i
eaErG03BStldqoMCRVLlrRkyrVkU9508e2nZPiHZE8b1RjpgI+hZIrEM/iNoFQmofhkGsvBJg4My
GiqFQGf02k8jhwd/QwqMBpld+xloDX9ORu1n1KKBuhYtwcGIRifi9qAkXeG88hprQGwT1GoPomgx
p6CpjsGDuGI9mlFY9JLuQB/UtHhNTNJ1CF0LaH2xcIGY1WSzO0YTJ7aoeQ/b3qaExvHznoKGlmJj
xNxboVriGjy0zIYqI4fq1w0uqyrfCwRRoN3XJsY/zlXJ8Ncm7E6A9eLdDol/Eo/0LGsxkc8x4XCe
08VHFVCxTBILzkhhdzcVhohhEvEk6VEh8VwH6GxAT+eOi7igvBOje4WGY3u4BHgfqej/MhZFdnT5
3dZm9wNt5WZF1l+iHIWBBbNCIBQboxIao+/Y2em0orsMKRr/y6Fm8Ekr4DmWcpdhfdNn/rwDNPgo
INOoUWhpXb5Hy4gXWBI1lbmHekJdg27cJDUlDw7Vd7wQmAV1Q3iqvsv6T1/VwMshdf9dIOmiS+mc
HlaWMEH8EFEuM8P5ylvE3UqimAMWDpkmx75Ce/YcvpRYww2BavaHAGW7EVxzvQRqnSjoZ7mGsNL2
ecL/4/CxiJq5HC8eoxxz7n51QUhrFD4DLUAan1KrQDKLA18fsAAMnu0vXhIROKADsnNhuzCVItdQ
/E5pSsrGo/pVZ7oVa9fePo9+/JepkFpb/Thyl2C7/s3cM9FBvhb1Nu47z5mI6so6VbSc+JIfmEAh
q8NviDSJBF5GGW38lFrLlDhETPTGYChFz/LFXDQBXjBZTJtkRidqRXnd944Vx9n1r8vL4doYrb2F
0+xUvb/hlfUYUQ2+MkRpiP6S+eBr+3ylCpl9ML3pMHKwpHd5KjIgIjy0IQ5YVqOnG0BTWKhtXKsD
7UEvT4Su3xlWHgWBXBX2LhXzZfoC7lJ3RrYMGS3cFb4HkoCqHaiuk2rOMh/s7mneaCwcJTzfj587
7Q5M9c9EcwIpAMrOX5ivUtnZQb+vGvyzuzAgu4CXARyKRLUOI4GlHeXB3+LqmGhS88wBWNm399YR
8LBkXp5rCJk8w+u5PAyCI7bDaqqFjsYOWF8VY1ui5byDQaaQDKMn9A/lrZRzWVh9ChseZBhGv/Rp
CVV8ja2RoDsEVUbDywkbzId/fTvIq1bScSKLx3aBT0J31M7YJJ7KZ9QeHZSD2my+rRnua2d5xRiG
uE4ogydQ2C5Mriu5GFOLQewUuRzff5r1jKJIkV0bL2/8h9AMVPLQIP2o9vbVf0zq2Vi49vq7IlGi
DMJhBvYXObgk+zTOQnAH5n2+xiC521fj7TQf9odsgzOrK0yYqmVDWa5uSkZKVxmmcp8MLquAQweO
puEufvE3tE1qlP22lIiXZhkc2qsa5roxIMlF2R2P+caYj9DaUhYv4ofT8CuZC7R+DUO6xC/veVUQ
0WCbVle+2jtoXoMDkzL+T7cwksEybNIZnu9zqZzXYKBE8zp9+U+06QXe77KNzybZTepIVk94qy5D
y7V3rr3JGWdtLFXHxH0Oo0uohy6aPx6S7c0GCLUNazdnT8YrsDBEbgqfHiplDMysRjivSYKOO51F
nLdA3a6nhR7q8c9ok5cBHq2yzB0qRMwBQYuMkU2NrorBfKX/MInhUu7fySaxScKJviY70uHMEV8X
aKwsTgt3w/E2d8DnNVQoGYF24HROe9lL6YPdPwdoUA2C8dkEz4YAPT3tDDT0nTj57q2RGZcOJIDN
xZeORmXIDowiVNsQZ7PMJfRR6HZPIHyCAJUhOR6lI5TOiIJK1MP6g7Diocif1K8IyrUBD1xJiD2N
C0LSVf6s59uy6MtGap1z+61mbn8yjS+8wRd276i9fUejnNWIJydVm4RmEVKtvrELkXZQE8p7EBEQ
G4BAFTsV4I2gwRg3+KwpvQybLhn8Kaw12AETm0yoh/4yQRjqafzYORJKb1Mu8LkcWjkIfTmCbS4t
nSp0jKFdlYGL8TPxc9T5ERIZRGH11CkiDt3fDlXqptXHZAeuWII4H+/CQ/dcRJIclrHUbhl4gF1y
9pYu8zyZitaUK0/VRgEpl5iG1W4PZG57dzTrA/M5d/ZdmzxFRb39TUAx/9D38SEjLEgWDQL4i1In
NjJie7W33Yz6S83sV249/h8Rf9oLP8SN531z3ITVBh8Anvwy7/AH5xnl4OdP8Yyie67XKKxTRYEn
DrBJA0LO74NOFp2zfEsAW9sxxTMCGx/ni/uod13pLN1hzFlyTdds9wQGIuKRD7Wn2GkkDhlGgV0X
wO2O0mj/Q/5HHGDOo2bU+7AAqp3GbgqSIFFsWYe2eb/ZSfUSbjOH9MM65X4C3cYOlcTgB7CEVvhe
hCCIyvcvkKVKU9qXCvB2NGRsO/V0upSFqzXZIaWjZU0vzuFD2CH+DNEUzQhM3+L5MMBRsegkktNw
AGWioJvVIjl+n/mticr/A77Z2sYLJgVDhew4fuzODoBAadg/JWVSQaqTFPRXG5IGTkCzNwNAzkNZ
gawn5gDWj8OzOpY/vw9u1rf3sPRQKWEigjh4jFGKBj/I2i3SSvMo94f5TiYbIPZ4MCKUmEUao6B2
yW0thDuNv/tnDINbzxiIVhy8stDQQA5XBCMNGPi1NPHW8+dhx3Ra3yxm0+8oM4CFSxeV1ohzZt2k
j2V6TRILbDoAey9hPQk5D3P2XK25BHB+rBEkowWcIaThVAYjAhpnBCC2bIn2gKqQjm75AhcP3xyj
NRfTM7q7jer53nATSt8OVzCGrg/7iix0gP029kBFPz5SZ0jAz2IfKwcVBfXYHzSsJ8ooui8ZulVd
H+thjiiLlv9kBMRVPCoZ5LXGUlQ6vPZuMUsm+0WF2vwF1zkRbi4cFeUZBYUsHMcbuAq/CkvYts+r
KtlLBUsF47rmQEVuDUKJIczLq2SxNB3NMmpvkXkW2rpxvqpbq1OerjDRKBEJHjK0ctffQphAUrt4
73F4BG0Lxg7wvd3QS7pSnZwqoD5mK+MgQpko4Rb6izST8MMMXi9Sh4W/4ExK6lEY4LOvH+DF5Kjc
2vIFpUKPDHXe+ZjYATNCfh6DUhTsfupcSgU/NP9RyAj3AowHzaKF5qrTPCxrCO4H0mWCvssWw8Vw
llUcprUepmjrJFZ+CAjJMEculRT3Fs90UXLwcVPR2NsgR8GFnps8BWrIhhTf3MNBzQnIzZMwrmVz
pY+4xGxMqn2jGt4SEyuv301EDw3zSct5qlxzcHygXZWAJnvC0HXTh+VRaS3+CrlonkELWO1hm7zr
5CuLKAjb20hwXVe2h7DJU2uhzhDLpyMEN42Mk6ep+OCaM2FwHfNnRamBixhWNk5GXIXSb3qTPqBM
XfEmSOO0Pb5yefHKcnvXkFCYTGIw5ZXf8cus7MSliw2fsXletMrKdCtwj85EHHAd60wuG4NNszwg
FADEKC7FVOg5lsnBaYhpjXOZ0nXVPPbfE8FsN7IkXKMxBQ/3dYkcP1MV8rkixRuHVZXdE+nqQ/Yn
If26yiEyVXecaj6h6hxItL9CSdMsNOhGfkQijYe6qfSIp3nLZOpsd6KfSKC6pTgu3DRtfW4rnnf3
m62IS3Fn2jri5qGvJZoQ13KOTg1jTJ7VgrmpHslRfA2vDOvIreR1nrTAd6cUVVtKWcC+YLLhg8Z/
pcHqzdF4eAfq6T6RULW+RSMvB8hnoEsnLVvo24mUmcOPVTIr+Jq3weGO0AKhQHqX5+qQzf5/qiBL
yidlHKZPwY5q8+vwauhfPBDuibD52jghnB24Wp0flvJevGFTCK4Q2Es1nCGpFOaa862fzSXH8S4y
bg+/9/ATsdkyHWumclpH8wJjlYksTmhj7/YOTBdCqBN4S/reedSUwtVCviWr0uySIU7ZnHaB4JB+
ao6hT9TMdJBkyDLg5YXBuwg16zx+iwTVZjbiEDMkP5tCxOGhEiyFH486TPSV2TsBU+/Na9ivoTR2
Cx3IHOxWbibzDq7EM4KDuh3Jcpe71tBvs9hLVMbI6qj6pwW9mSq884clfO/ZEgfPCZXo2801qogN
8wQxS7tHZFwjmcXcr0sBmWR7L8aoTRYeujWAaO3/mFlHHYecxyba7Y0IGYiESyak5Aw2Q9QH/gdK
7boDqsfxtJYABFOT/wSwaJqxsYGShzTHrySYINhQueOCNjxwm0HeowZ0BOaBJO2p+CwVXYTUyAg6
bJqpJKu3MIzUhTwsMbPSlQEmOutqym2DLS50PQYfVwQAbaFBEsRIZIaazr93AzrhAvPvqyMlKoOC
wzprgXIjh2F6kZ7oYF+X5hfOv8vtjRgZBfJAnGWjcxKXUFcKyJq6FXvm03tG7KhSbIbOis/viGyO
6d3hyVs2G152jY1b8Ng6ivTCnN3HjwF3Gh7U9ShMbo51elbeVY2hkce9pGl8ZKEpUq7ku7mbsSRL
f9im6+L/HhzZrpEV+2Wht9FQaYdbe4YisUUmyJsVVCvSYOVoGmBSNOikTZvbBEsiMQKTuq3GA41J
B+4CJ/dBFor3jPz2cNr4rUrTKVPYh6v4s+DV16vKEo/FLd4SKbksXmvVoLqnBgoKlXoh1Ubi/0VJ
KeFKJ5GlvwveC2/72phNeK4STyLEPvDixyWNVgB27JH+ThqEpguu9T/bcE5Own3e9X6DcclQQlwD
au1QORwggeGAnG4fjp+V+NWJ0EXuxmt+NtT9/EEYefsZxGvKllBBYWHqjqFA25aQKu12WUXD75SJ
PK8x0UN6NRgKQlhONI4jSnWt3K1lb2Y3C/9h2gdIvJfJDY3q1rcMRDga+3MSetnwAgphCJi6R7sG
EhyH7eZ5NbduIKMcz1UNqsljjsDnGkMOVflsrVF8bSPuIc7OeeX12F8YQ7TLovG7TeZsfMa0d9fH
Jm0EYOHU2JfSR9jeuvG5RfKEFr9PpTjjoSDCTYln/rJS16VFrv1/EDFgoACjhlk9YVTiRB4+1zn5
L5TtIDNtS1GALGA+AdJ92xHjo13IjfDsiw+PcpI8Dj410m3YV9GBkwgkvC9k5b5pHQH4sN+80nnT
nkksoymaVvqiY2bFRF7yNwvjDaOChqbRHiPPMR/bXvDaEIzg97sVWhFhrloEMB1ugRUtJc7B47Bf
LgjtN9qzWsLMqASA8Y0/LIL3NwCvkZ9rwlzuPpCd4hA4JWJbj1ZtAav/UkHGBffi/BXgJ2HRwsUV
bg2Yuvh5WG+1H494xLXLm0ON8Dpu+40VmY1m4pmSmwBVFDiiFDU8PUwKyIQGp0/P5h8rdQoNlEYC
jLTplUdzSaFO0kHoqKVHj2Ns0CoQTxpSp6YUB+8NfYDeQFvJPtVgEh62rQF2NdwXHmzxaLO0A58z
0u4gEV1P+Q6vtmbbNPti39ivz13hXi2XQ+R66gh5lmMaXezuX15QTvlZQRay1KBoHpS77nspNEOv
YNRdu1atYqjYw47urMyuFYWV+199zhD0ip9E+3tQbYHasBLLEeJQeU79sVtWbdXGMa7rbPwX59v6
SNrvbqJVxtL7nIDipV9L8ZxbEd5c3hi9Ffr/E6ZIlE8jImx0tLrmcT04ilZliNneHXCf8fn3l7DX
mcEqueqh1zCYWib2sLRFlewvJBzJxhqWZmCGWzVt7nNWf9O2i2tHgvNaRgJI8gkdG4qpBIIGzgKu
pZoDKCIWU2W2U3sDVEvFOE3tFm1kKUqyhuiKEkyoT75nspDRUyalM1yjy77f1wktp5kmssHr8BXZ
AfsE0c54UkUMOX9eiJH8K/CC2QqnT4/HBs8X3lASSi1LpX0cfvtM2ZgWH9O02IvkBxJD+p2Z6QUd
PMDzI9Gxywkwe/Mt4FNEJAL2ia4ym4aSdB9BNDuwTC2y0Qonw4wf8v66BjmNEvobxRB1TMSDK+89
jLQqFW7sMiOlZqTeCGSLfz7BJOTSaASHpubedEIUgwy/eEB5RmkLYTST53e7pJWVxp91U9YMIJz2
jEoSHGzWY42q9AgDIf4HOgHivVEjEZNyDWzaJVtpbA4c0hRlEZY1QWiQAZCefCO8gdDtoz3JRj41
wTJsbAsE52sQV/c+sjiUd6AhBsVGnHow2UadQAIgEBsOrIQfylwOWP+ZxbCR3FvzJQ+gVG9JtZPW
1y70ppWwPuWO5LYEeeuLDOR/Bi/9v4/mcgBMsCDSCIwj9H4vrrCdUcPr5UrLUifSJ2nkIOg4rI3F
a4s50pkA2ZIg7s0OH7hj66OOfLEYaxsCo7667+W16Vws+VA8Ca2DIHBJtUH/Z5cSqS0B1xjWynRE
4YrC448TEKqVgMcJtHSUkELONHhqttjRyqQH/uMrdwscY3LFV2PZGvAmZOuEUxOv8VeQBiPCiPHT
hhg/g5n7dNI4OwzuA7p+v4szXJAExKxu/o38KxyoeCJQT3SDxLj4tK4sWR1GczwHNrS4zdFajkzU
RrTsPvLhHfn0ZqThkEKG6bCh2dbwxGPmAJjfdgzAjDCMaet7KwlGXo9r0xz5N9T2/vwnL+vzkK0p
CzG3H6mLY+tOKKXK1DTkzPGP+TRise7CeEnnw4qWNFnEu9lLs1YcA8vxjBeZvoGHjLDS9JCuHQEJ
vSzERR/VtVuy9feiaVl08ugdzvEQE+u9Kq2guUWG3yqT61VVkubR/mAw1iaGM1JRDRw/DUlSbQ7f
fLGUhvfzMrP3RFwxGw/d2O9wQVpUOH9yWjLTKP5A7MdBFjGkuDH5IU43gvEP0QhplCj7zMfaO2YA
TpnP6B3gku/8vuBobQQjjVRhD6LsgwbG3Z/rsxg8nC84uPxOS6CH+5pst55d59zC2iJRTE/VqK4z
lRWSAKzq09XE/nK5KhFmKNiMFR7xNtNeGkpHv77qix2oPDD16NT3xTIPIEK9jlDmObuU0zbAyRr2
tAAZl2UU6yB04mKrA/bG7Pa4xakT55ZTc9GADUP2dIFHASge5mutFQdrADMsee89TgwehWnO9ZdB
0EJdY/Xi6iCJP9mYZnyEn/FcsU6gvpI7myQVUhEIaCOquWbLEGcJY14A2A4PmC/he2R1CYW68seu
apfmtzNhRrRrMkI0HdYBzYHPT4saZ1vmfGYEwrRDwaEFOzsY4fLxaHD03muEWMZEmkIO5GfwaUJg
qfh4gyOlpgtVsW7LCkxGCssGEYD6VB94LIGzxm9k8GNY+0+YhMWpberW1TDohqQ5M/DI130vSj8y
zpYsQQXsx4wP1RKje1SAys3lWA1VRTigHDiZXUTIBwr2PkLMQMfGMcsxlfAIa/eoM0PjVvpQ6i0t
eVoFfwj5Mj1jTMcNvKzprghmub6h+NDVgWcJkufX+iCXvvAUT3ah/q6YEHwcOgBqggvTx/usJn4z
b7hGqI/4tys66t+Opz4ZDEIKw7YEBsnIR0QhL2wyxAANZW5kc3RyZWFtDWVuZG9iag0xNzUgMCBv
YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI5MSAwIFIgDS9SZXNvdXJjZXMgMTc2IDAgUiAN
L0NvbnRlbnRzIDE3NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg
MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE3NiAwIG9iag08PCANL1Byb2NT
ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMTcgMjIxIDAgUiAvVFQyIDI5OCAwIFIgL1RU
NCAzMDMgMCBSIC9UVDYgMzA2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4g
DS9Db2xvclNwYWNlIDw8IC9DczUgMzAwIDAgUiA+PiANPj4gDWVuZG9iag0xNzcgMCBvYmoNPDwg
L0xlbmd0aCAxMDc3ID4+IA1zdHJlYW0NCuQ+AcWSXymn8n3G6AlYg3Z92J0rk9aib4ixASgPT6ki
hGpA+k6i7dL0qEn+Xj2F2o4gmisPpgyFVw8N1jm9GazABSL1qIeY/h4wpFP9YauOjR6tCUxuHhSY
O6oLLBZNPNMfDo/RyPaRZ06Q52Vdl297//GCS0YYaD1BVpApc2wrafweTpA5S5MT0yX6sslagwM5
z7dM7mak9MM52RItTAUBJ9b4TqWnQV6x3zLb5/+B0ZCBnF0P3mEt1d3ymXohsNbXJ/qCeBgt/S3k
3E+e5ixGo3JhaHUNWQfu+3mnPhD/nDds5JXAQ+S2xXwJfDe9d8m/WMDn+gTQAQtdI0uSiUFcEXaU
DrynyMjrd1+ObI0VcpalhqIt1yRAoV6fJedCyDQCbPhAikIdXESADrS8bi7FeSwSAM2mE6h4DzWp
HaLxdxzdZvhRNYrYY4iCikJgn3lbv/gB5TzDUmHN2Lo8cqrj8gkI3uU113UgGcaQIEoh7/fuJt70
y84XTFsEycu6OVdhh08l4w8Qx9NfczKuPAjZ8vYdezBvK9008vFWb4TB3JjW/glVnCgVAK20OFp6
CYqigEeOq7QJ/yf+3en/HDRTWdBHlbzY/vB2LWK3EgXDqhQ1YL6/t+g8JC53BP5xQ2BWkt2Rua81
+4pT6qTDzSl8pYQTtdHBVJ1jtuGqCoYwLg7+TAzwMuXKwTOxQacHobqra/OtBjS8gLR2eA1IVhvh
N1Txz3AjKq7O3vFbXhM/7qdIYm3wQ0l5kgT73W+hAYFfole0sVNDN5PgF0Ue0wqV2hrAw+puuf24
6QbhBjJnMOX/biGW07bUw5H+8DhPGGianzDV5AsUp5qzWOWDWgaR/dfihP4KIfb9tMY54WTur6s3
P/gl0NbWRIM8bf7PfS1h4rwGPii9eXfz/zw2R5U90Qdr8LFw/xC+D56Xnj8qNv8cDg5C2Rp9dqAN
VfwPlJqZ04VPb+fm4iOqdybRhvfLVYsz2H3YjKm9zP0WLW54cfTq8D3KFGKZH1P44DlsYnHkvK7X
7X9VHv6JbEkCqtwv7nZcImtxeRc5Ok5UhGh+PK3sGmjY8/z683e5/PWUMzqn6RPMrxCMukZxI9CP
5rtf/CMXIfZmHKlEZFcgPGoYRtlixpd7dWK2sLnP/bFkY6X9KXHqRXkt4G0ZzB7WV3aXW+byfI6g
7W63GcdHqrMLJKZLGXZTOojugNoJl+bAgUgJPiGH5g9O7eBdatqZGD5kZXrNuTIJtk8hYrtjNaaW
wuanveeF1yTI1Nv+6PIfWOUdqyut4WIMTWyG2ZlvlfeZL1hv8TWTvDFTgo9HgIymQ0EFUlXCm0X4
6xd/Ag+iCnqX9yTcK1Ivt5NrbaZg40i6EtKFroB0ZLJ/FH3OECni6T4xiaFa0iC5PYqgA2mdT5rL
fQPN9BTyLxALqRwcaoJaYLFaXQ1lbmRzdHJlYW0NZW5kb2JqDTE3OCAwIG9iag08PCANL1R5cGUg
L1BhZ2UgDS9QYXJlbnQgMjkxIDAgUiANL1Jlc291cmNlcyAxNzkgMCBSIA0vQ29udGVudHMgMTgw
IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBd
IA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTc5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl
eHQgXSANL0ZvbnQgPDwgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIgL1RU
MTAgMjExIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxMSAwIFIgPj4gDS9Db2xvclNwYWNl
IDw8IC9DczUgMzAwIDAgUiA+PiANPj4gDWVuZG9iag0xODAgMCBvYmoNPDwgL0xlbmd0aCAzMDUy
ID4+IA1zdHJlYW0NCi9nMcKVO+24XppGzWMt1VRNOuk/WRGQtrgkw8PiD3gPNz7yP6PGqohpHkwU
vChy18WzzFXBMpW6I8uhjI3FLFff+/CrL3ftIx0svdnFkOqR9lI8nk2F9d16RLGIuAysWLf9Ucrj
Nb1ZoZabOdARlD25ZDcRDd5/dsGOgh954/ecuEk6vFrJfSqUJVLlto9dtYCG8gGIIKo8dHRoWabd
pSAJ9dgPU4IubYKN+DX8ji6LAVvaX3la+5Lhw3sMNWN+H2oi13um3UyCqnhrtQJghWmVw0edmgV6
lLEkjDRo8eDEV5dD4enILqz7wFhErQULwOM94xI8BxWYEKqwyJ0XsGuND/5Kao9B09idCy0wW8wK
YEJfIrielMS9dvBzyEdqTo75Ac5VGNxFUzYvK0uPAXK+pfWJwkQWvoPN5Z4WAf8xYb8WKc7s+y7z
BOjzCN45bEo3BlIBKpWId7xj7rGFn4X+giW7wCbU/sfhNv8hEL04e6Dukdo3Nnz5WA+Ic+1HtOW+
4Z4SbhsKJ8uoH2wawLzLf5kS1axz8EmVJ9XwkvY/pQKJGV/ukl0AxrTprATWUDpkD9HvaDHMCgJu
ZqRuwfwsQ8GCygfDwUXHNIKz484CHs4WIBMj0F2W4CrByY6SWJutvxOAaDv5vUsrF1OZHDO2viT6
VhXgK1vKHJ4NRJt32E7q0GWpelrtgQWPmpNQvnFPnj7qmxNke1CyfUCe5UnhI22+c4DPbW2roU5P
ylWnB5+dQMb31TYF1GCSMFSWaoYPta2sSPVBxym7bTi2UE7wp3J0LE1VcV07a5vOQ1rq6ML9Wl7Y
IOSPvVB+LqeNmPikv28/O/BlLlpyQ20AonaJCcXSiabiHQ/9kVbEobHJ8qetXxarusA75pwAOG7e
G1IHP3FWnQa8JYBUBxtk9WEsNeylQadQz06QwXuQcPAheAv94srhlRWAD69LAd/Z5abuFMgHIwNK
zXvTZechnDoA4EffyyygIc4T1Po8zF9JlXtixsvfV19hOyUkzX1C3T4WkkGEjPEAMqMZCGfa5Otv
yjYogHuw/3FpyC/99gZLYYj9X9XEqtC7mu7gjcwsxQDSjmzS0e+QsH0mx1oN71L7EbGXqj5wX46c
V9zvy8Jdp1x+pVOEzdVCrIjCB2+JVrEjfE1tIrRDo8DfHbD+qPt/qXtWvbIaGwfUss2d6VALp8AV
6g8S0xmzTrsUqo8++ZcHr03aDkzPz3QUhKRqaUt10Jp7dsbmPZhuW3DqYvoXr+S0ZNsoY/9dE2CQ
xzpeircG9T9CFmGw0VFPc5TCOk4HXEyIp557mzUUCVwjFp0aCXwpXJMvmuskrIkRYON+Mea/luY9
QCsmr+794yWE4ckHp/7QJLa2Q8QVFIRYmfi9UNTzJZCmPrXuZ2ppvBfx6y2ulhNu8BSqVyfmb1BK
fetmb3ArkYAmv1F/KHSjdBiuXZW6up8ErqqSfvCYMDbzG7yLk89+7wy6BiTG45AIDjmIkSmucnxq
kT72QwwoLT78hOoNveXqU6pjPRp7f8EcWk2nhb+zykP089n28F3Fvihy5ZqSVDMCs6Mx/vwuQK8p
Ndgk8aCFBMads5KNu2j4OkXwpc4QvSzKbxnXnpl6vz3CUzEzsVSKPUgKz8tHBY1YLQkNATqu8Uf5
SYLbOyg0z9G945Hjhq/Q9AEFtJoR0YNqd5rPs50SlLf/nkuWwqJ5nXes8h3k1EgnWyd4R965E0BR
JgaH1IV95gfC3JcFtHHFWBcH0o3+PSgIts5cv5xPiLXRFF+RGPrZh9WJbhuMHU7fFXLzpcncDA95
O8wHIIsx3Qhwi0ZfgcP0fF1wNyL8wreTKwL7mcf6qVD5llafD3cAwVdfN8Ayfr2IX8mBSMIVGZRp
K/6vN6ZLaQBhJ8dU36EQLeZibhjQPpIEqbxfW0Uu9awv9u1PIHNEFqwzLj5ND+Rl/8v00wepFkf5
PRu/MgVtzqUdk6dvahHlmwFc3f1Ku4w86bAPo5uVsVCc31/hXWDhlytMrUnYXOlu86rNu+IRjhr7
rdNgos23xamnClgO7zmsxgw2Vs1TckP45NSmCfvNhckxep0WUjRkMb3K6GIBnYnjUoeIc2M6UrES
IgpSfjliu4ZAmR1FpeTpkgXY42TMyumbCkRscdd7OdH/mGm6RIO1JoeRrvFKZ711nm5f664bnEW9
WKcHUddPN0p4PT3sBMmC/mxsehT4CWg6ayq9DPgAU8OcZaMGeZl1e9vDXxeCQn1IzjFl7U2+mMcH
ag3dJHwOLWtFlr8dWrcFFrEIr6yZkiO9cdYvPyvlzZ70O6QuB6cSfbnNwcSDTQhh+m2XxmU+G7yQ
eXcI1kr3wd9/1grB+lbNFCB9RWJ3BwvILdBhHbC7WWtvTspzR1Y0H5vpw6Odet5n9f2YGcsEVQSf
ec6Zt99coMm4SV5qQ7LqDXZjajkKAFBJJjAMgOL4J2njglJX7Loj4XXmXlT9P7nTOwCNEEWybt6X
5o3V4voxpBRylgph5tCOkQBgxVu0LQ6qIzNy1vrg1Dswcy81DWqdNKd9OrPAG9Drk38Xy3KkPSia
EO75WkqlOoj0fKM7jajeIYxvdf9b7F199ZWtKXPc1HXnaeC3EjE83jfq7w+oDmiuuGN6mIOVnhNo
fL+gmQwtiFd71pEIwXZ2hM1qVdzjbsmrrR4RPlqFi//xH4W+ZDzF8nATwyvEQtQaE45ws4tK6jBv
IPthYcrlhqlFaZ68xIkOhwa4rQOw39xdjJu45JlNlm6+xxR+ngijEehwaDmboeMTcqpqwXh+4ks0
WFkphU1jUjgVRbwERD8B7xebqT/5ZWPmRULtZWPnetcDr9a7oB+HA+0UPDEU4XeupflrTiUXoQwJ
x440SWN4+iJ45PchIbMBUuiuibUHl4jhGJJGRH1lfDeypPLEREu2I4ZgNV+0upNtGbcgsNLlOXif
yjT5FUmMYwwLGsWI9mBvhn1EDQ2RJl1Oz0W3OTynuYdXik88+VI8rGZsyssWINNxbvSg3LmapaO1
Hwq9/XtJhaTBYRpjxDApCgorron47nnI/wgZKczk1J+QV7tkB2oK43nR8usU2Al9m5Os6Atciyrk
tH0JlcV8my22h3LB+n+w7fJQTqmYltib+TB6WkH7ejZ3OgZE658My13q3DWO/Q4bwGLacB/22o5w
ObcYzgOXtk8FZ+vLWSn5uaY6ynmIR0Te6Jq/ajFHJZULU+xKWI6DrPjI05IgMs4JiNCsATswAMjK
/QgqCY3sUQ7W357YTgkJwhA6eS0KVIV9AZ1/4PUznYqVZwhNRgCCQtq7RIb9btEMwfD1SCioDzSr
iiJtoNnxSyCOm56kp6+qxD772c6FEQtJzcnfFSrG4Pgh+nUE8gu67XMTaKGl3sQxxXTo6v5P1Ji1
/rErD5/MsrImZI+RxvMWEhpXosf411+G3e0vaUiNva/plbWroIrgTcdI/ut+YGLytWi1MKY7mLI+
bCffqbXqeJxIAUl3aO6olhPm5w/RjC44Zvd5WjBicW6aFqNy6xtwvko24OUO8YE3rEhoGtopQRlj
l+eG+4EfsZQBhsrKaAVzbms/0mYBj7EyUfcR4Vj3QlWdANATeiWTMGfRGhr/KC0h0m10npJ1jyq8
M3XXYtjoDQj1Nm9PEQn+2bETUxxdI5xDa2lreBDD9DGn+dfFx/6V6ZgxBS69sOZD1/j3+BnI1aMd
6ACkzRqUtVPl6vYG+ebgNS5OTgXupnEFQB9sl4PAfkUCyEGe9IcJUdnoYub8pyEOfQCBehSz4t2L
3W/ROteKw9tUqPl2oyE8fUy2DU7WGhRJf1XmdcLbqYFCrY/gKhyrjYdH6XMX+OmAJR7ZWd7JAHh8
t4QilTRfiG1FqMddoVEvM6HLtBauWx13WeqGc3RJAxEurHUURhK8D/uTt0iTwBNf+sArULkjSPym
PP3M0q3MwivAOzXIsNUceIJ01wn0I9YpZ2xK2UQXIErkZ/Mbhvadt23LA0xWzsS65iCzigw5ynme
LHNKUOzw+2ws0G8I3g2A8TVk3YWikzVEveh1tQSdteIbvSG3K03jNUEtIPUNZW5kc3RyZWFtDWVu
ZG9iag0xODEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI5MSAwIFIgDS9SZXNvdXJj
ZXMgMTkwIDAgUiANL0NvbnRlbnRzIDE5MSAwIFIgDS9Bbm5vdHMgWyAxODIgMCBSIDE4MyAwIFIg
MTg0IDAgUiAxODUgMCBSIDE4NiAwIFIgMTg3IDAgUiAxODggMCBSIDE4OSAwIFIgXSANL01lZGlh
Qm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAg
DT4+IA1lbmRvYmoNMTgyIDAgb2JqDTw8IA0vQSA8PCAvUyAvVVJJIC9VUkkgKGXBeV7/ejlMP7qA
IKi0hsyXzAHpZWpbqnWtNbJ+wJkyveR7KT4+IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5r
IA0vUmVjdCBbIDE0NCA2MjYgMzExIDY0MCBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAg
MSBdIA0vSCAvSSANPj4gDWVuZG9iag0xODMgMCBvYmoNPDwgDS9BIDw8IC9TIC9VUkkgL1VSSSAo
d/U949Toi9ne0aPhXHILK9yuQ4fZBFm7ApFoLMgYqcgeidGVKT4+IA0vVHlwZSAvQW5ub3QgDS9T
dWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE0NCA1ODcgMzExIDYwMSBdIA0vQyBbIDAgMCAwIF0gDS9C
b3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xODQgMCBvYmoNPDwgDS9BIDw8IC9T
IC9VUkkgL1VSSSAoe2rxMnbslUQRu63W/SFg/s5cKMOEIRLDUDBevrz73s0gZ2QaKT4+IA0vVHlw
ZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE0NCA1NzMgMzExIDU4NyBdIA0vQyBb
IDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xODUgMCBvYmoN
PDwgDS9BIDw8IC9TIC9VUkkgL1VSSSAom0jagsayx33ulxXB6u+CXFygEQFbBggyWv+KvNBaj2Cl
RbLXKT4+IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE0NCA1MzMgMzEx
IDU0NyBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9i
ag0xODYgMCBvYmoNPDwgDS9BIDw8IC9TIC9VUkkgL1VSSSAoizvBr5UJV61wapJt2WPuq0Ra7qvR
GjymVbSlEByGmx8t7ckpPj4gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsg
MTQ0IDUyMCAzMTEgNTM0IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9J
IA0+PiANZW5kb2JqDTE4NyAwIG9iag08PCANL0EgPDwgL1MgL1VSSSAvVVJJICi4VIt0gweMokyV
FnpkHRHA4DQhtmrY/UVuWAu6aLfWhV6sRik+PiANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGlu
ayANL1JlY3QgWyAxNDQgNTA2IDMxMSA1MjAgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAw
IDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMTg4IDAgb2JqDTw8IA0vQSA8PCAvUyAvVVJJIC9VUkkg
KHGEitzatM5/FbalOFwouqcPQ/Xr9hRuc7+7DAHSlhJWEwB2fyk+PiANL1R5cGUgL0Fubm90IA0v
U3VidHlwZSAvTGluayANL1JlY3QgWyAxNDQgNDY3IDMxMSA0ODEgXSANL0MgWyAwIDAgMCBdIA0v
Qm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMTg5IDAgb2JqDTw8IA0vQSA8PCAv
UyAvVVJJIC9VUkkgKAbtY4SNkj16FYQV75GvFzqG7x5E+CTh7+N2Yn5dWAJI1YaivVxcB4QUvOr2
Gzdg9G+pZ7Bns8NFP/iD/2ccT7QmquJWtLaMiVwN+qYGJ/ApPj4gDS9UeXBlIC9Bbm5vdCANL1N1
YnR5cGUgL0xpbmsgDS9SZWN0IFsgMTQ0IDQyNyA0OTggNDQxIF0gDS9DIFsgMCAwIDAgXSANL0Jv
cmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTE5MCAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAz
MDYgMCBSIC9UVDEwIDIxMSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzMTEgMCBSID4+IA0v
Q29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTkxIDAgb2JqDTw8IC9M
ZW5ndGggMzEzNiA+PiANc3RyZWFtDQqTgwba6SOOXBFTfsLEPa28uZ/ZhFEpPwS0RhErEyHI5Jm9
Du6Elch9iZLP0qxObjG/yfZcAg3YEmh8ptiVKInDy/LsUVesyjgxFECFrajHpmBsBFeIdzBn1MmX
s0mTmCdcxNrykOj/GLYN5O8YcfWPr+ZxydazGzv/eSwS42uLOlMyHkQbYDTvFOfDIVw1iGRa8PZe
P4IimwXFMBUL5/dvVVnb1IjMuQFNrwlt5SC7Yty0nhSG1jPYgXvsjiIQkZpKb1r2f0S8C9FnDr5v
XNAljfYVHXCdDbsCjScXBfBdsEGAuVTWHXFFN11FwqcpF6TgCX6Zv+XdwiYNHQrz2vexwdu5nb5w
nM3mG3j5k2PGNf/BsXLue9n7jF5rWYQVf7ny9erm6WG7QoN0NCWw+gLWRcTGwd5ptEgPSmCnRS7F
HVhlcgzKk5Bd3Lf1mm+NFUKQbTX5mSvg6mb1wWZsPiNsTSFiv3c1yGRW3OF9f0TlIdvDz1D+9G1I
P0Xe1rZbPBpMIf0LM+PVQfmqir0LpiwJ8w+XTjY+bYLHn8V3KD9Th1KZ6IMnOooRPoYT4j5BXqHs
u7Au7PIvZX4nraEs7ZOSJD+Y4c3awK8/dgA8m0y33zPNf2Sthz+f7tm/OeQ+F8zFBf7cW358Kzgk
mu0AWNezQVblpD0kZxnxvYK7+lce8Wpp2U7dN60nq2+rbTmxSqM0j6R5EqLfTj5iUYLTdXetUKeo
EF1D5OvMCu0whwf5PwredLjZB6+b0tH4Xfw1vnyagy7Je753kcvKZ4rhu+bmGGLcpWmg866Y26Q/
DiysDox1PI3okMH//pO41bWPHDoAPa7J0eyadFSyvuAgWFO2pjlo9iIZUNit5Grg6H8Kveha5HoJ
FqprFMe9bCa8TutIeGV6aHWKBkBf7AcdyEWVjg9HulQcOIYeg434jkJUaMyhhuT4sBU9Jp+bHtsd
zdBaHYJaUeIZsezSlGKoUKEyqcNJwAuZxGqD9bb3qhKCrdhiJQcleo2UcGh+0zKyqCq8HC03qufF
3mvHFWdmNXQwYMgokJLqpHNcavdKFym13370MPSRjjPI+nqWtoMl6+2b9QcqBnIm/m8sz13qj2DZ
n/Nv69cHiYRuq6fxQaNwLNfJLqOatJZofmD0Zt2ZmNLJJ1NPd73ahWZFH4fGLPKEyEWXxjcdP5xd
Jjv5tiXICnmQR2jvQ2ZPhKnxJv4pQCunt0NFRKApu9lJmU9798njVIYtFH6GWEM+ZiCU0noCZ3Eu
/xy5qUq+zS7YMbuPEaTFdzCjJCZQ8wog9RqFziqiTTufYspxXsC07yIN4K2ER5FJFUNuZd4kg6qX
MvNItvoGM0k6YjeMunN/NWCXqD8Q5MpKG2FBmVFNAdnsrhkbwgqBjcGzcQpyuYhow8OvY/8gSUOO
TbzusgSKcR9UIatFutyTAMpLYS7LoeRbUW5JBk6YfW5Goatk4cbAZvtDaEge1OlIZU2EHK0lEWoC
Zn/Rp3O4bTvWQQ+3j3/gxPq58JSvG++/6vAY20lVx4ES8T/vQXq/Yo9YCkkDS8JjjbcPPWkQ0FFO
KfWntdYPitvH8Vmff3wmsgHD10mx+3s4iZ78Zxe6ijB8T612MhAS0S1l4KmXcSMBLDXORV1dq/Ro
7YJjZaBpdBCCiCOt9snAFOiPrwfmvR1f0mplVbSTFhAp7KAUSKnMEalwpJhncKyz7Cdw6B0yaaz2
HOoGbK0ttKW1RD+mson1BPTZk1w8QMVrenoAFIahNeGRZJ2NrHmD879HIad6Sr4KLGXEyHRVB5ci
ixFLfFk3sc4Rj3b1vB2+8zyFW6ZDg/JRBlE2TVKS1wwjV5XLlGXJHegLo83/141xnVbCKVtcLcoS
LEUCnkTMo769vmERr0YYJr2DgfUD126f/9KIw31U8e6AefVawxxO1HyfVwxGB7gPwX9Edq3TQ0Tv
23F0ImIVCRCw2JYc5oe91rGooYD7cLYdxxhCga23O0kZ5W7Hwpi44POUoKNMeXHTEOdHrtMBhE3O
qLezDpxZQuqfAciNNwQxjcppySL3fiPpW9bNMn/lYctZ3lQmJR47zO95Kx3aKQzAB/puoFdkEKEd
19wn9fdjWKvZZY7BFvGBUlCHmsNSlDvL0H8el7brg8SPnURjb0zQVONhqTve6fA0xCBysFU4Pocq
r3wylHTshPqUiCsfalX3e1vGeBW7MJ79ZM84BLvepn3jxfwvlLxkqjcsHZ0kNUHqwItjmkSVdO/b
ZAThJc525a9AVXnBljkb2OjbHxzih3srr4qv1Wwqxw5XJ4rNmKHyXiEGrL4inXG2g0KP1Iazra1d
RDKYHbmNsAhKmYXOmA8yyuGoYqG72GIp1MlRPP09ERiLeTdg+6mPEvtv4AbtkKSl72ZTuAEHierP
ckkmFlTRPwwPW4EtgfV0aP4Oh6JDdeaOOeK9eiM8rJ2k6fDQmxVr2sQ9jWIgAZb2Mevsq0PtJzkk
RQaLkggWseV2uWBHfU8T7VwkeZl3SO3wfVhimt/8/PWhDtlDn7dCq0LIrEczCEj6dv3bowlDeenB
Enak+PBNyUxTF/Rwv4zOY+LE9d8rISAOnkrKSGHFBuV2Sb5EfClMy1Xp6fxImVNMaCtmCMut3NaJ
00zAda7dERnPVe8T/ldOSvQyEqRJ7ZNMi0doe/cZwvIAeMUYBVo5HZE9MfHb3uQO+AiqUiwgTeyg
tIB2Yj/pKExxntrB+tPwxgWSBmmLKQiHVlLhLWtaMaaRCP8DW85q//duYlUVFYdnm1wGzfeshztx
U8bpRFzXWhkhcVQaB/HhHgQPJnnt5YHw1fDsiCPfpqfrzFAWKxsVGFIVhOgNsJnXN/2GYFwxWMML
YIRKhcUZmQx/jw1CgtmYJRKyG6KIN/cecJN7hl3jOs6/r6Up8y3fFcb50owAh7QyeX1xrp7LFoJ2
uDFytzm6L5wncgng44TiG4Ur22agZbTYaT9WgBG6cOrZRgI7IK66Qt29Yz5gXysY7UN268F74Rxk
FZk97jWdsAADsvCHXZoIhP9zHBi4leIMPajkyksC7gC5PXGT+ppaRjVWZd0C/ot4BeL9MG0UmSMJ
EvXHz4cX+WZzx6DVJTA6NDhZqXIuZSBKi1qq/idLYs4Euu3gm4e2J26ENkMSq2bcASMPmSHZ/kwZ
4benwaIL+YALA4UiGEzSlmC62EtWhNBmPoXntyGqoV4HILOiuZWOq4z/idGS6ZNDNJTeRlHb43+w
t77kATHFBiibI8LRXc0nvtGzeOVv4Ia+3JKfQfOtlAM0cPzgzgAykZ8dR8iMiA4XTG5Nn+f8Y/F2
qUBt8aMGHpFDvH8JwYZ6Y/z6e3DWIYdyQDRYAyT/G1cNtyR+phiTA+6YbgLfpQPyDGjvxr4Jt9xa
UjBeH0jZYVcJKsfrgJtPzpMKd/R2QUPDca1XUu2nt4ystAzoxmT9HsxmE2Gp+mDcOqs5AjpR3yOx
4Ur+N2EWNaiyA4IQbbOOVNcDoP/46NqdDKOUvTTQZlo+dcZKrizsRBd4IxCGwHpoT2DCtpY3szWd
8QeYez7e/xxi4nCyKSBfJRNPb0lRDddVKGkOcqc5i6lkU6TuokHmvGyQXtEsgebZJi+tS7ma4NKA
GH3tv53qUIKnpt4l0GsyYvOdcM61Dp+yB64XK3WZETCJS0JC6gy43iELdQOHn64/cNOHcS2+/y6Y
z06HuQ+PKz00Swp7sz8agBsrcLKdf2F5pbdi3SHLtjAxgClgc+eOnGDlu97+9z0wFjJg4y8Ni1Qp
9daWupVsWok6k9aIeLz8VZk2g8IBtp33LWluRI7338BTjLRHrxrzcTNAaJquWRyGrcWE+4jqbCQX
as8C0lv5x1t5ltjbGhZbFxMFxPNtEEI4f2FvFuUTAXzn7ZtwOGOjdQRBdJk1M43aCE8N24Jei/JO
I9unKJte8vpJHCGtAD7+z0z265QQq5kmegBL310/m/0jycPuMGJMAhPYUuJ2EB09uDebGKk4WM3m
Gs7fPMwzFaslgt5EJYCH+FEVD8n/0YIlpbpeCHZkjNY9ka5ZdQE/ZRRIf+PYCeRZlYLFdmWDqS7C
y1LwCWyaMvQGVXoKhZAgC+o1aS5za8vWmIwS6JNawoqpS8rEcyvxy5qxH0vzrrcSq3R+uJuQXomC
Dd+4Z3Z7BgWIc+i11TqBquQmG7taFHqsDWVuZHN0cmVhbQ1lbmRvYmoNMTkyIDAgb2JqDTw8IA0v
VHlwZSAvUGFnZSANL1BhcmVudCAyOTEgMCBSIA0vUmVzb3VyY2VzIDE5MyAwIFIgDS9Db250ZW50
cyAxOTQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIg
NzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xOTMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvRjE3IDIyMSAwIFIgL1RUMiAyOTggMCBSIC9UVDQgMzAzIDAg
UiAvVFQ2IDMwNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzMTEgMCBSID4+IA0vQ29sb3JT
cGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTk0IDAgb2JqDTw8IC9MZW5ndGgg
MjI2MyA+PiANc3RyZWFtDQqnKlReHQ5g0TKJoCiHH7H2yv7t/001MNg5wN8CenbuPTBtopdj9N30
uE9Lh9om6nD4GDS0flzmL4HvRnC2b4VMQIM73lRij9L+1qzHLlzPGW41u4iHGrl1LbfiSjXlrkVx
cjhJ8Bv2kSGJf+qmcWUH5StnbTFAGuyPUxzyXaVQECMrg9Y446AFxB7ULi+cKLBQYI0m+zeTgg6r
0v1YHiF69pQvq9+GYEma4eInoqWrsL/KRZnn8sBkvGbmjyeeD7/ao0elcQCtOGQosNqnUSRw4GOD
saCRrYqgGL06arRZnd1wVWo2jPzkDU0fDbNA6vfCHJDiRb0PdRBDLWpc+Og/I/9d1t6ks7Cab4EY
b/M+YHE3i7ocGoZLSpd8qh0Q5tg+mkMjeOCYkBRiaOwPiA/RGZfMb47grpAhpkjM9z9xLaYW9nfU
gDeBE4KiOhrGbjBGbQ+NyxZg+SfJ2o/O01vfk7w6PkA7n1jYukI0wEO+EOLxJU8bZfGKhg76wzv8
Rv6GckuQ643KbShG72y3Xez3Ujl0MfJeD75igZ+bjQfTBAD9UFIzPLA1+oCDWM2Sh5OIxNX/CzaX
XosvMEpEOYjQVAfPsjFhhLp0ripSZPIWshpIXrbo58Yu2qT7p9IACfMq4c9p3EdmrOnRjOLFSE4a
3T1RmtcRe2AZMeo2x2/eBi/uiVhfqIFsvlFygXaOAmGrsnWtCbnE1H3OPDAbCq8PecshF0vILC2V
fDoBGyHN3lvpAaGcn81pieupB4j1wI1OyN24LlwkPhY66U9AEYcgZkgR+oGdzOXprzHsT/PxpN2z
U4idUxXtKj0b5kvS5iXQmIex17lkvQXwBjCNjLIT241WT/jHssRCRV607PrCEDzYtb562x7pQnqu
iTAw6gA1Qx7Hff8xlcMli2dp+eQuTCCjh9104+/L3xsKtddeskY99xIKrWGisaQVzs+4ndf14E00
bgymmgVpd270P21maEcMqiW48+Rtj7Bk73m6Rht0P3zfXWfDP6CIvYqo20LFIP48dS1lP1Xh76lR
93gDoqqM9jzkKjCnZmlNAH7TmnzQwtcQl4DrOX87DdOsITzz3MhhAq/iPgKg4X7Z0hhHoY8ux/4R
IaxNC58rsKeNt4/2EeoM6qKstZfRmwTAA+TGe5EDQEOXQcKlpfPNlNn7UukERRKkvsc1uWSGQShU
AZsq9sRp7ESdueQQO0mX0KkwbZ72/K+4sxHpRldY/BEDuqtrghp6f+JBXoZc+Fyz3ZoZdj+M91C3
gcn2J2ubx6b8NDZAh+fx74B5aiRZxPYec/pMWKEcR+vxfXomTcwl/8trFgJwzihF4vIMgUzM9ZJe
V4759bErEH6iAaHISsf8DZivcdsAJNCILHDVb0JpU0dIrYVY3zSvbcWZZCEYhX8z0VJhAW0KBdGA
1+HjbTkK7yrH5lejfom9Sqkh1A0QpRnCr9gKOUjmum2CGXX0SOCkcMqKac9Lftcbke5bUroR4dWi
BU5xz/7U+czEdFY4C9UEivFfiNTWMENRVQSueMCSTqTITiH7sVgiH7CfkE5i+fx5w1o5gDPJ+uqE
QxpjxEj3/8hpkz5/bCZ5x0shX2LrEF/7u3Ub++yE9mKxGmEXHYwOon5+JvWKq94rW5GLYoyAPpXS
Vhl6wu1oXyuTblB3WokvISx07DRgvrdRrmxP5AVzpgStRhlybBPrAUkuT0H3bNSVzwoyPNC4L6dr
BtUaDIbWMpFBO+Yyi9qy0E/bqHnXxC8+orC5ugtBAFysmY47R1ggE7mii8Kfc5S9Tv31jcJwdzD3
K1kBwUXD5SIMIsfRP6gKoKUHzOx+7U20BbApH5OU24+7ZENTAnzlCsRw9o1YaCGeQayMaLMYDF+a
yX5k/nesgRHzeBgA/pDxt1ip6kT/qT4nIBta3zQjeXHQIVjGI0sFKr5e1hlsdkfC2w5Sur5hjVv4
T3d911ta3OUsKnwDhJ4+BYFDZAi8lUKfEs7Z97BTbtxq1BY2jBFQx4wf0eRooPPBchRj3nqGDzNl
UBBPimgF5WQ70E0wQCvmfBxdKZ8qA8d3fXjG4YZLTK/Kp72CnAa1FZKHCKuxNFQIKUX28XcHaJpp
/CzMMegDbyaYOEjcnHzMRPophp7ctggvkr72pi7r/rqk1h9aYzCvXTG7Ox/tfHVrtJHzdeNSjAN+
K9m11kWMBy/7nWUlGE4q6F+G87Fxy75sCNBsCpf+BljLOFHGROwSkvUaBbTcyS4pUM8YrdJ9ythx
I6YF+irTt0UXeuFs5cWYkVnwgapn6XiNqBJHqmpoVn/y2X4b9AFxwIdU7ATrBLvyeFx69956eWY+
e8drkDv2DOLIs4IVwf4RtrI8XTgL36dPqGhXvECAHsCJg8Cns1CGrFCWoXxLT0tnmfwppE8JEOTV
0cTfzbvnhImDj5/kcsAzSFtnhJnmrfgfC8sxY8MX7C4VuJ+kFewdoj/YqdXY07ok5/vwTna8Ddgz
TDRGzifYcc2wK9vEeRkEME4o3aF6T4ZYNVK46FqtxakNKAb2Kz5zZWNqw7c/Rx3LERmT730b2SGu
Tc1xHyt5ZEhFdSmxrSMEMTl9LBrdsZlbtBZbcX2lNdZ+3d3oWqwGPR4eyTkRAumOLI2kt+T/eTIY
f2vSSp1y2WrQ34J6kGxefanypJfQYiGgKRZpN5QYELyYfDSyeesSm1pzggYeIgQJ4On0ieWhqy41
/PI0G40/MqnCQsMqAPmE5AkG6iLdg6/JaFKkRa7/u89goQqBxrsw1IhpAQ+vnHAZaN9E6lUOLnXr
EXg/R4vjLpKavCeqnmgdJqGq57F+7+Pyk3+Vb90pXkbdSULd/I9gFQA4sqTHrC5oeMOos7qsD7wS
rarQKaFTarmiVajTx7rtTkReaGSJdnvVgCzAUkCyu3pvipNBKb85+If1jsiDkpFDqgEt4jLMyvH3
vOk7G2Q92wf8AQzm0RZOUCZMeGsFIAS2f0DqLt4AwVrzfLDrrhlDQ+qETEuCW1cy1KFwfow6S1a2
DWVuZHN0cmVhbQ1lbmRvYmoNMTk1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyOTEg
MCBSIA0vUmVzb3VyY2VzIDIwNSAwIFIgDS9Db250ZW50cyAyMDYgMCBSIA0vQW5ub3RzIFsgMTk2
IDAgUiAxOTcgMCBSIDE5OCAwIFIgMTk5IDAgUiAyMDAgMCBSIDIwMSAwIFIgMjAyIDAgUiAyMDMg
MCBSIDIwNCAwIFIgDV0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAw
IDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE5NiAwIG9iag08PCANL0EgPDwgL1Mg
L1VSSSAvVVJJICjRiHtl28EwWsu28e3hg4NJEiHPLy3rY2X5KT4+IA0vVHlwZSAvQW5ub3QgDS9T
dWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE5OCA2MDcgMzQzIDYyMSBdIA0vQyBbIDAgMCAwIF0gDS9C
b3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xOTcgMCBvYmoNPDwgDS9BIDw8IC9T
IC9VUkkgL1VSSSAoyC6pu3iedt2Lhd5mPVQacLzeqZa0uhDJxF6fJ4sxg6nolt42nLS1my/rQjYe
rCk+PiANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAxOTggNTYxIDQzMyA1
NzUgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoN
MTk4IDAgb2JqDTw8IA0vQSA8PCAvUyAvVVJJIC9VUkkgKMh5XhtMOvFkHfEe98dPRQT4cCCurM03
v/G2ls0hVvfxPA8pPj4gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjYx
IDQ4NCA0NDIgNDk4IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+
PiANZW5kb2JqDTE5OSAwIG9iag08PCANL0EgPDwgL1MgL1VSSSAvVVJJICgxmd0vhjZucTGSl3YV
Y56hI4/UfMwfOwRcbsCOuxoGSHE7AIiempCLJm86/APiXG6HjKsTOU+GuSB1gKUfOsZ56R2jC7mj
bZNcDSVQTdUpPj4gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMTk4IDQ1
MiA1MjIgNDY2IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiAN
ZW5kb2JqDTIwMCAwIG9iag08PCANL0EgPDwgL1MgL1VSSSAvVVJJICj9COuyki6nk8jfm6PRgGip
W/JIIO7utKGc3itcck0SVff09YRJolF5yYAkfryOga6+cTRcbpxcKOgTupVZ7433jBrLelMrQRhc
DX+deqtsKT4+IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE5OCA0Mzkg
MjgwIDQ1MyBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVu
ZG9iag0yMDEgMCBvYmoNPDwgDS9BIDw8IC9TIC9VUkkgL1VSSSAoZaKWtbevXG6l7uW6uxJZgEyh
txSgihXWbgf5owxL43uL2a+yZtgkSiBFVb3bwLNZXHK2wyk+PiANL1R5cGUgL0Fubm90IA0vU3Vi
dHlwZSAvTGluayANL1JlY3QgWyAyMjggMzc2IDUxNSAzOTAgXSANL0MgWyAwIDAgMCBdIA0vQm9y
ZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMjAyIDAgb2JqDTw8IA0vQSA8PCAvUyAv
VVJJIC9VUkkgKDhITYP4zwzKgbPcsoC7fyujZXUAfKbEbGn9LltazpxqOSk+PiANL1R5cGUgL0Fu
bm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAyNjQgMzYyIDQ0NyAzNzYgXSANL0MgWyAwIDAg
MCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMjAzIDAgb2JqDTw8IA0v
QSA8PCAvUyAvVVJJIC9VUkkgKBGbHt73gydoHn+Ttlb8IbsfPRW/fN7F6lv77FxuMeheN5ZbdTVc
ctTciT+wjWqK5zLmFQYpPj4gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsg
MTk4IDMxNyA0ODUgMzMxIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9J
IA0+PiANZW5kb2JqDTIwNCAwIG9iag08PCANL0EgPDwgL1MgL1VSSSAvVVJJICj2frb7nWUUT3+u
wCX59uPUTLBeJSrQbj+rGpS3Z9vCxnopPj4gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsg
DS9SZWN0IFsgMjM2IDMwMiA0MTggMzE2IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAx
IF0gDS9IIC9JIA0+PiANZW5kb2JqDTIwNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0
IF0gDS9Gb250IDw8IC9UVDIgMjk4IDAgUiAvVFQ0IDMwMyAwIFIgL1RUNiAzMDYgMCBSIC9UVDgg
MzA4IDAgUiAvVFQxMCAyMTEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzExIDAgUiA+PiAN
L0NvbG9yU3BhY2UgPDwgL0NzNSAzMDAgMCBSID4+IA0+PiANZW5kb2JqDTIwNiAwIG9iag08PCAv
TGVuZ3RoIDU4OTkgPj4gDXN0cmVhbQ0Kr+7iFvUmIsqR5wcES5PtOdKL+B4b7GG862owxxVlkBtI
Vumwnj7IYIlh1447lVbgeLCAl7HOZHbzaEhMKVwz/735Lry4jskxOYXWJqPcgoZx1wrIERZcetHX
ymIAmF25keVeyC8DMPVl7G5ee0EvfJprlDRaPn4U0lAaOXP/rqd4ipJXFpe8CaaAoSeM7cTrx0XC
JudPzoNbnAIL+pG7uGLBPAa41Vk/jL4NNrOt8gh2Fzq+dvV0r7SC9pP+mNVQZ069HNWCmCAV0dr3
eCuv1oiZMDXsk98vhAtwZWWDGpG2XfmxC84/Epxcciub9zrcnhUgqdYyw3mwxve9aVXOh4/bHyGV
ZtyBUkzfqen3WbieKlolNpL0WXDA8Icsq15oVKh8IGcFJhB97wtrKz3NTlQlsZ+Lhr4xWysJifAH
mxbxuFUFXD15/3zrpWZbrW6bek0zWytTBZpPSPCKK30SLWrNT7XdBQrtzvxoodtTEvrEEUXG/wDt
vrXZHA9Z+iaCe/5unyZ4r0anAS1XtXW90RRvF3FnlMFBmKglnZcPlA45VPT+GtcsiMJEtJuffp0Q
B1NA8pKSd3WXOql3Qmp+XSyOa020dG7PMY/a/zxH3/N/AGOjMs4cbwa2fVysRO6hb0dxKHCrG4xP
HnwNm3/7QqRIrGD+oSSPhmUiCF75YSCjw4pxAhTGsI0nyzJzs+59H9zrFXHC7fja7CIOZj+AghGH
73Z7kXZKn1pzfXrh+S0+H1hnp24aMdRk7g6VXqXybfSHlmsktWjt4jOAfPSo+BcMml/bAdjnx08Y
BllM8yjYuFIyOZbywhyYe9x3zUEad+0ifNgTh1VIflXug9dw2WkHQVfze/nWLdJ3BrlbZZcYtXlR
86CnmPsWKZGj8bPej4/cHJZyvPmasx00mUwbn+pSdqmP9NvU+kKbLV7/UD/rUwP5/K0hORg6dSrT
ayNhcBAiLaw/0AXhYvovKkL1qmI2hSPzeYYtyB5+JcRAKjYayMpeTE77WC7MEocd33m4KcdKkG8P
eZBIhsPRCbF7jHyuEbqf4bVmN7SU/k04DhV1rFea6JqFnwrFI/QUcKgiKl8xKZpjcRsN/soS6L2G
ZMpGst/y4fzHr9pDx8xsvFdsSiNI9XAG75LBYEAJ4eo02GdBxZZx5fBI4lrPYFV6qwMgWD52DmaP
If3V6ux6ddgJaeoEz9SGjWOjFMQ1OeZYJw1b2TSz7LkgBIFV6bjOM/1noHgcoa8N0/DZ5oy3Qmah
/MwivEEKQuAV+N4EulYv4kT7bTnZWjEKjZ2Hhb/9Ma/GqcJXJ6bN+6ejsiP+D1QdbnFsOl/MrCO7
0whcYiVUTOpcpLJ861O9flgKLpJkpTLyhgAnNwYZ8U7AqHjajs+wUY6LLRaHW54pnZ0RbGjh1RKr
iwylUPFGvcJm92NkT7Be2JP39A6XvABjeZ5TaZZtRZN/giGcTPP67A6RhV3Xqz3hAXZeAH3ocmfp
duLeLrYo2gDJMiXJuWUxmNoTatLRQba/l9hpK+32SdxVxCHb4BE630o/ZfZ63LiIhmjfhyWEeGPd
L4eBjRij5cXBj1rvYCtrNShiDLxIG59w7rodmHAhFFf/9L95QA9yd1xCXgyu47kwjxePHxET3Tnz
LJcI/Ogu3ytWZW4dcTjN3rtjZlK3816sjg+E+ocSq7nwW1XCewGurQfUNPlJIB7tohADSeTmOUL1
OW209o96nXsdUVWs8hevphFex263MlHE+f7dNPOwDx5VhFnZli6x33RaVxdZf+oKoe7C/IFBSFLS
P7+CZNspNE19jrxzATV+tJzk98u0UPztGXw1/FEz9LLnr2Q40wdCXUr6HFCMoSxM2AwOQ6li8XBS
FXPMXAQvcjrccRxTJfXZmq0rVY3X3X5HN+Ea9kkFHK01jSkYlgHmNMB7Zp4tMPJolEbt3yiCwoIp
92EjPLJBOCg8qOgl4BqoiqNFHxP7LKaDtQoUORVU8FlBci0mHRfApf28UMsm01YwG/IS1fheEemm
Yd5PcMwY/QlDiW7Nhe4mYt4FNxwoJuVgAKeg1UiVnf/peczAKX3zMcPjkqkRR2adahGB5apAnsNz
5BPxRY6JiaH2i/RXo+LuHOExger9PfTzv1xplY8BjYdlfKLxEtvtr+qAX6ZoHNRWtgQUWfR6iMKG
+6iRKDdM+cvW0hV3GhMR2P4rdnDb7ypR9jCGIx7Lw9igtoFqbLy6O+QAAGvgFbbkwajY3HzdnpQO
ruRQECWwsZiOtRxieQNSpcCl53RcEdQuLcA4OsZE0BpB2Msj7SywwSyEsmworNzVOD/aaWu8+UNv
VLJ3TY58fOQVh9K7XS4DY/s4Z+iaEj9J3ZBe8G/VaddRDRJMvK9taRyFAYVlqcfLk+Zl/VLVHOGT
4pOc4YkybfGU8bZUQ0CIYYPmRs5jJTdfJoRwxp2/hmA6c87+fib+Kedg4xRm+LQzSqGQ9JhtStly
7uRDHo7P0sED4MvidaP4V4ENKx/hjW4lV7FQn1NrkpGimwAv56ZZ5I9Iyhp81sYIC6b+B0kiArty
kPZKmTKMwv/54VNSCt3W4qnCQ5/32yhRJNHhLf8Q2BvOEhTPrlvRElFDrnO2ycb/teZOGZqBg5Ez
liIqLr1dekj2fOW2++J12zB5Ul85hHVHrt0cHYgt/LyqnYtYoNWbdQE1TLmswlmRD7nMd0A8GUZ/
T8TJzVr4fdFtaSqajDUB74Xfjfcc/QkEiKfNwRNmH+HybMmoEju/05FY4iNVz2iWKkFDp7/uKV9m
eVMCfm8X1utrwSsFhL4TqJLuMljlRCo49QmW4kqeVLEZSYUoBP0ZvxbCiqAbPpo6zBzn4y0oTufb
FT8svQyafX8CznfK0dFL3Mlvn3ifBJ/5L9GjVHMemyb4iu0MKHtzxhjWe0JTvPDyyMYDCyAZTBdV
uEF/nVdB46Go/93gma7iXgfCayYn0MSPgCtNDZO6wIETwW933jEngyOHCcYVZjdFqFzxGIFI1os6
i7OLRrshWSpt0FNV14XvWAfPVLosU+ar+cYDw9/ondKm1iDHvlsshyQRQYXOo79VQsdmwadzRhNl
isDA4yesMpPpqVGTZoHBGuh8Q4VXWMvVVmuwPB+u9k4Y6o2xXZxRaFF6jk2BEiQwYt5EdezYt2Lp
J+OyeL4hx8I6iQ1tn3eZe0EE/zEzwvR1CF0x6/seiHWIhV9GHQ/qwCOZIyhZb9kYoHvB1a71hqw7
hczc0twToFfYhMbBOflf1dkuZNkm74aiytxxW6mMiIBAKfwzdeV9W9hcto4rNPFB7XxBK33Wj486
hJNH5LqRnX/2gnAzjBQGPd2FXBMg6UnkgmpC/zq9Vgl/1XOSF4u2uE5uiL84xIfg2hCnZfA3jmU8
wjhC1wB30twkuLmcUmzL1pYUcklmKzRuh17yDgmq62rulPmbB3157oPkV2Op/L+17F4KTePJmSaG
/rqwcWL/0FcCK1bhK/YkVRPPne/RKUQpA7iJVGTgeRLjrpTTgnk8n80h0PTg/3YXCPF0szDqZLqO
TARDydLfX297/AGCTdSTBxunjEtMaDgBbWe4JF94Gc8bz6ej6JZRkSn/gRl31jyxZvHgLfrq7KJu
ruL6ksBBVeyEulrqjBzGiJDPwrD/GCA/Kv9OkLHJbInLdReWq5FDGN+Nt8vUr2DzKwQsvP+I7nQK
1VM1jUirpfkDdVarnPjH48N5avQL8KNlypPOd4holrsRrEzFfBCjbxstdl42ll80HLgsL2BplY+L
fqMtAUODCHP6V+cbti2TDzjUViQKYfW76/7wsrGtmkDOmSLWiWCdCc1N+O0lkXMiV+GoiPFGBs8H
u+uudGjlGcEQH2x+wihfiPejouSssRZXsAexS8sccnOo0ikN33Y6hXtG+ANYhlZWj54nHf7yu0Om
wyevB+VGJPIC6yyO/smARKNjHUvdu6yPaGQXGQWAdIUvVpWT2Fp7WoFnPcRB38in+Y3I1w+bNx5A
pAJM+lLRDI6zU+0umN8ekuw012ucdbuJ3X8+eMn1ibjZ12STo0GLGJWLJsbA9P/ahIh1J7ZC3D5M
VyOG9hVQT4GSMr60/aS8KT/rVC8Uk1lcuNxnaYTlO0Wyz9xx7BHTf+yRXwVBYRvCgZH6gOf6S3Tq
I+UlPFikTFzTrG4extYKYeoizweUSJfjWzqd/4FUAFlPGho7agOw7NfMmxlBUxA77v3OVznU3xGe
qAiFTzdFbSMHqIS6bDLne6OXa4MuTOXHYg19MwbsSNAPp4N6lw9YLIPnmAwKNSL5m8Cead0TB73+
p9GP/gyM6d050dg/+MjCaaZcdmLAo60h8SnCiAOhftrttMo96JvT9LBzxuqJwX2mzt1gicXcZdIb
bT30NuFQxjwQ5OI0283b6jmRLL0UzECG63Z/h9lpP7b6cCBUsi2Abax1xUVvUX22qAJ4+CX8+w5t
pr8xZ+IwpQsZkJhMQF3sx7790mXl+jzEBypjh7XZ72xJKFsyQ9jkJsvPJg2A14/lJ5TagoMzxnPg
Cz8pjiPMAW2F0vHnvbaas6qzRlJAaBIughEA0qw/vEqTXLkYCp2ERp4S303sJ0HkxNu+G4JE7MaR
0Ak6HR3wR70Ky5mIu8f6Eu/NLYKL6cAJur0pUorFGvyynQrRPTBp7ytMRyGwTcoLt4XzGxm/3S+x
nLLutG+X6eoZttF+QeM8S+rUaTyF1ff4KNA9DguZnLJC/Wb46U65X0TMyE7fRxMDQ7RxaHXy98Gx
2qYg1G8u1I03fDQv7jVHMy1MhtLnNLp8K5R+mduHvaiHFMGuJvM4v8KSATAESEEPJ1jwqXLrKvyj
tA7c9MThr7P8ZNZWgCBE52Xz1UiVGdZbDBfanbyvyRrd7dW18Virq0SpWtB8y/5Ec6UgFU5DgOPv
B2DwYyt8hnu9NsSRCYA5yq+3tIzI3uIyC6HI4XIjS4wZ5Y7Heuvr3RRNBiD8dZqbxMQ4NQgKAo9r
v5yCQVp4MOM8xOY1haZnu8EPY5at7avvG21KMHOrObTK3Bsj9+JHpoc2DqKxhDqinql+mZNJNcbL
Scoo23pRQCBYzq8r+WCS+q7q9RGwFzzfG8HnnpVMjS9Zwk4oUSlMGp6NtDvBwhzHhmWYFaUVyexZ
vFWkQEL03tyautaqozmKXN4oGNk+n6JlOkg5aPZXK+d3bCzTN1kXbVpSMfmE0QjnE2yxMhwYBYD5
5m7XOlAJ6GlmThczNBb6XpCatqnVXvmmWOsCdSt3bdIE2TWz/onjatrbRivSdlm/NotgX5Z001TD
Quea33uYj2xpFpMf8iu73d+qNmkKomNVfQjIqMoYVFxFav9px7ftatxJp5Q2AXuRSRq7fVs52L+n
AEAqc58Je4pQTt9UqR3PvrxK8gDNwL8nvHRELaD+4k0gRqM6RWo637e0wpqpv4t5nlquHzTXKSfe
AJfcw7gskxUz6Ynux/GEsjj6zCoesk1ZnLhKXxETkmvMhcjUEcMGz2rHpEkl0if0dmxpPAbE31ju
1QYWTyWU6HB2UueCyb7DSyYoczfxrND35FhtrB9MQE12y3S4eM3lk5+bRlbst6m+mJKlIslx8oIs
UvxjVsuPSTJPrYA1QaE7oyW95HEeRZJsewbm3W27AJD5uTY8K5tUo9nQrxMIm9BzLBBK3xitz2pL
O6DleKuBvHHEfVNzVqctFOMmzbPqBRLkkWwQUUpT1hxYKIRdSrGH9+I21Aj6STdm3F9iOyLV6Pfx
BU5sH5SM4hfqYosYmEASZt8YA7AwjUoAq1BqUaVgzlWysGunM0HwZZ4ZSRXUv5RaOj6mvS77IJYY
k9RvP3QDZCPuAAvPTD4fOsHengG3oUg8W1dd/dMskSwr/yHqLjYrcCl9B30SGxvZraLSPWPn+YZG
UAJpjDfuXTyKR1HDVycknPzuWk917cr/4zEwKLA5jp37OQGNoWM9MMiEHqhyboMK3qE24zYLJ4t8
jPjs+Wi80oE0VlanNVui565HF33t6FfpnNxfqcS/4/jtzJFUArBjoJVjBDi0gTNn04FRg+j9TNVY
3J5eg1KA4p+TQ1hNYl4yzVgigTkbieQIrjwkKmkytrSdguuhbokBhU/0ekP95GLHVrDLWSO3GFcl
+OXLqL9y5VsCAviY3q+JhKisRvCXxeo8j2lgdz0QbihxdUJyZkI99xnPJvvpk4gS/+QByOZw9Cc1
5MAzd9tfqUMe36fZuWXTnRuXe32gFUa3Kfpg1kYaNpKGoaUsutxuYJdAIgUxI77U/uK65GMVDGZL
jVdQ1x+7AiespdyUz7n6EwY+DpRIgzBoCQYRhTW7NVZoFM59oxyHggl2+IRU3ed6CxinDBVqCoXh
fe9VB+qjBIGO0XSEdz7eambNT1UT6a0hhFv4pj0OepDUXUZjIiYl3t7YQTRmSKYMacE0kb7Xbf1s
zw5wJPj4r16tepoL2cVCN7AvN3W3eKAUb3E3NLX68YfZY/3NrIOV2oFF08QhXXWcy1jFq20i0Nsi
3PM+SoiRM55uhrx20nWXCWHCbg++ef5chIIXR+o0ADl4xV/RjA6cNM1FJIZL0YnKlDoVNTppmCg1
k4pUn9IFMwUjlLMoec7FXfzz+APhmxgiGCgv0Gm4JaSsVNd61CtNjeib5jUvEAH/X3GSS8g2zRXz
lG6ZsXVJho3bFaarnYt/kdzYkO72GLYiatj4dXB2oXMsNSrAPVmprAbgCy6Py7NWWszKUqzFfdH/
AmiAMzpjcc13V1aKjewS+tG0qbkDPOFumS4y8KZzubCIfCQ7UHkALGsTGGAO82whcaQZTlHPMYuH
ySo6zVWFwUQPBZ4wELKov3/0uG/nqpdkQmoM+uqWUIHQPjSWrlfF9Z9tm9xZZRHNto8JJRjkfFQb
/RfV24ghXQ//N3A/tw7QBb3u3RqvVr812K7Mnh3asUwrVg2sDALcAzHD9JL+zzM5zHvYgwEJdbeA
ik3fhRt9jLQ0bLFUxWJVYpjThe9oCCuJBrk3yDE/2TnYdEckON4Dezu69tB3VJ60B+5GlVS0bVQ1
T9W3ap3YwjzzzHHGMFbBSZbz9aBWdcryexL7R/JrOaRybiPG4Pxig5jae6g8oZfsIcD6E6dX5KYd
fpinCtW2/kV9VKjFnwHoBAm5CzVv7900kJTjMsGgeOfoiOGt9AHKNbUf9CkKMjFa/ZiRxbthafgp
XpEeLFmPISTmJusnIiNdbie7m08O2d9nQ9vei8i8emsmC9Ua4Q5Hk8vEZ8PTu5bmfUVURmUqmaq2
vKSuz4Leb2xMqfo8UHy/V5/GLLgQoIiQuHYvD07yN+PilaEKYJ6aRlCIbSW1QP6qHwb5jV9oPcTD
bBTMkFabkbnSEYJL2YnhMQkZkl9yr5dFXwvqSPs+Q9Fck5xgdwqV4HdY/Se0Xez7s3qHVAB6YLOr
S3pZklRlbwBl4kITRj/JkihA5fYYlHPZ7qaj1HO4Be96TYYjl/tvI6B554vQhdFLXMdiyFPZ5tpS
6ZEPLDA1H6aBXFMskOjfbce0BgKSwkMhm6oK39bk+WZYmLYmCyOw0NcjOXftOafeqFeMGxFURzbL
AFz7rYMNo4cJ7fuc7yGNE7ZDRb0sTe48C+m3N+58FZHQ374URSm5+TD2JrwORrxGd+pKFBqjMgf9
0nEK7cdRm1IiPJibd4TA2aCTq66p5XHESca/JraJp/jLs3eBII/JNbyWJTs4PkXSD85OuGrNMosg
R1avluAx1V4o4UUv7/rE/9ley7GHnJyEV9mvzvL2iETLehQXR4Td4rXQSpA27IRD3tX3tGbnQRy/
+1LbdKEVDk4ttWnY83om30EkZB+p8YepYSfiuVKjZTn5Ux/z+nlfeZF0w/N35AGjREK2yg1lbmRz
dHJlYW0NZW5kb2JqDTIwNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjkxIDAgUiAN
L1Jlc291cmNlcyAyMDggMCBSIA0vQ29udGVudHMgMjA5IDAgUiANL01lZGlhQm94IFsgMCAwIDYx
MiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoN
MjA4IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyOTgg
MCBSIC9UVDQgMzAzIDAgUiAvVFQ2IDMwNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzMTEg
MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMwMCAwIFIgPj4gDT4+IA1lbmRvYmoNMjA5IDAg
b2JqDTw8IC9MZW5ndGggMzAyOCA+PiANc3RyZWFtDQqSiSC9gHZN9a4uBoCXzUfi2y2D2G+TWkqo
3acJQ24rFeufC6Y8bqPp8BArHw9MQH4KL2xyFqI2suZeZHxPFss5y9fPMP+Eao5ykLBI+W/gGSgQ
yN88Al93us9yYyt2TSjplJajd1hmT7PU+LIGem746qFayhW+4miWHWPNliltPvHzycNX6mY1roD5
NS6sDNTWW+m3Bwg2VwWRG39n3SO+QPxoZ1ktazIl6Bsh1AoI1KiJZ4pu07EGMzgqrnd2vej153KC
YtwTBXi7bvRIuDN4ImuIvxKw9vxZOKqX8kitxe1dBtVcZoL/XoELMGx0x1zNmG16W66rWWXgZgvE
tMUIzv3pkXDf5d+RU2x9qzIk/zyl11GHJtR3VB+MUmoCYMinvu+k5KG3lujSbcexk3D9N3Wt9VPS
x0P0A1Pms+CFXgUN9tKCPMithhUoTVvOcsKAE/h2fIFSksEahK4PwwoyYnMAGzsjHyQGbmS+rhag
XSOStYoTlLjr5hBnhnpWMHGnedayWO+Gt4RdjBtMHjVdnMIFr5KgiqKE2hHksTKr0MeqRAilAN4M
35aWMPl1T2MKPD0eFKuraZVK0noOg/MqDtHJacbqx0AceCWtyfJv6vMqxUsDgU6Rv5fHUNYQo7DY
FNKtiv05pKPTnUgPvVFdeFO30PuuEbwDo3Gb9AXS2n4EHhcU/YO9ienKQcPuyuPTgHf5kMzEVNdt
woLqdbN2p7bPnkwq6d3xNQA1NI29YtTmZuY61gdTLIm61W0V6N0UcxD5UnwkFCBzhjj+5W+liyB5
fy5jfIwmag5YGdp+/3S8FymiDXnQ8FR9q/f7/fQO0MYRgUakSqtluBfQ1IMAXb5zvMs2jbf8HOHC
T6Q/mcut2bKVXJPqZIFoKHYLLW8oVNzEjBTuqeognBkQMNCjoN/e8hyQ1u3W9/+qcuqkgc586Id+
gvKvHbTWclaTBMByfcOegDKa8dydTXv3m7W45XfOgHZG8sMoLdNbeco4P+6B1oI//06j/hkn12hB
pA2WYkY9u8r8uyX8oxNHVL74tINIfmmM23JH/LpsTYWcsQrOOtdP3ybwViIt2hL0DhOH8fajV604
qm2okbYndTTJacYToDr2xeSYAJ4Is51OI6whchA+1YrKwkZOJnWxZBIAIvVmOX8I9WSbMnwAcsBJ
cMf8rUDH+UUksey0Irv7c0NEyNYdUHVPFEmuY5AAZcqQg3rjisdmRGCZZ/GB6DrFz/WfvB+zwx4k
JQT3ZyvaN/sfqjOL0RzR3jENIuCPBH9hiKbqVCloAG51Zo2IlM1Z9ogSca7GqImxHdEa6ZweykQi
KorVR44qmUwlnGc6Ol0RWKNzxu1KRpMimhCrKBGqZVWtOvgmScD38PKUMk89rXcRHUGo2AdEr0dA
QT/XXc3TSWzY+jzga6KnjOPIbYFuKKDDJnvZ9KNPwbpJtWR+tJirBTkA1M0QC32e/NW0k+jri8S9
HqGPCCiO1c65uM7SVyYKXzoBOt1+cLheDDwwaUKX7YX0lAaNncGbQOEFwwYbchfQZAqLIke3Luyt
S1Z0xHGElLGXQbRJXK1/CV9YUm/CuitRTNe+WU9anUdBhAWOki35zB+n7O4/o2Ujt8tyRbQYi7J1
iBqIqumUZ3c8jrujqY/EmRFc7bToI9XqNt7QjJykKgKSkUOknbSi6OqJi2k/xN3WFeWLGU78ebGr
80xOSugAyleoX+HBd1ae2yZUFYQTZS5UWHz3Ch0a2uWxWiCsNgq8TsLiqcqTEgDfibLjFYDlwRsR
V/dFdkC/MSLo6rdcvW4m8AXVtdyRmAKZlXE4InH0b82qn88cPHMFAbmx5/k5mSNZNOAtLS7PNdpl
+c0q2b9g7qo83ElEEKMR9MdEEE73FTect086QHZoV2w0vQNx5as/agHBVbUUmUMsP2cuwOafCVY5
silJ//YLsoVs9W6OHDQvNvK5OWC2y8yWOMRl5g86jIZtQl8xFYNnxz3hi0/wVSGsALsNjAP1U4VG
N/FS9hYe+4Rl1WPBoHRfat6EcIknw2htXsiNfIYyzEihHzXqAimFJPPWa8JEeHyQvAMGUk2l4aXL
eJ0MupHSEYXFDnFg76ki4arpv5wTcrLTLERHTD2+IiDPcx6Zhb2+v/+wxOKV3MdwRTaUTPCF5ONC
F5KTWzDe8ur7n7ma/0q9kuyhWS301UPicNkiKTVRPWBGu/Rry4Du4yALkH2fNbjJQLBES2vEPJkG
fvJSG0d1xHhcm18igSkYiA++yKs1A9ByiZD0rxcndzCONw6eW/8jL0btWbxkSMRd9X3UuxAesTC6
A2HWPnuSijoZSxZSF7vXtLppXiaay1FPw33m+h9QnK/8gDNVV2iTzNrGPfTBtA2uXlgM2LXDEiA4
9Vej3A7oFYwOtm0gTDcVRDujL32KUCE20k1tdcT865moJQmXpE0AXEzLPUMR6aJJYsWgy8GLcMcT
9RLyHu2az0oc1kjlwtf2TXFk+9/IgWN0eLAUK52b29vNpkw51LWgFE4hwjP+k54qbgozVqFFDyjX
YhSqnIn8U0MWatkZqB6nA2o+Nqw03wKkG8ODY76KhhUDhrFv5zxUCtbna2mFMe8bUbpPpO2ppPUO
y0lbFbkXxCqjpcToTQP9ZmoQ7IBoKf10zNDjUjlIYzBZic79uZSrDydN2AyoigWXOlvg57APPLyZ
UslOEGCVvzjH/v8j+ocKsATAxFscauDOgs/Jiyl2vamnPKb0T9JIBsMNF7kFoPndWuVwTGe4YHw4
H73Vk8r0D1YxcEZwFu03VX0vIV8Gfui9qDshNL0xuPVWbuj/B99aoIUwqvO8UzARVTyRX3bqUDdB
kgRNcSUY2pKhzsRBNPdMGsljFz7lrWXK3fzw253hnFU5SOD+WW8GL863xFA0eCT9El4U9dFDBIKN
P493xgPeNqR+5LVVtN+UNOiD9bJE6tMMjZVDP/XwW1+2q/LTLKBf+hIrbfFN3kopu79BHkKZe6sd
PNUFGV5GpB5IL2ZPU/XFSycfE92VU70k6mpJuiC838tFT8qHyL9qr7Spo7UB04g8lUeD/0j4xhGy
Tb6CAVy0AUkZQWvRVIf2g2ZJkPUwyEMtqy1H6O2xMqeDD8fKs9XtYJwjFOiaRcOLq0UojA9NyDPm
9f9S+aXdjha7xHDF+mHbW+ayK6wDvokFIropvaHCRDFSJeL2rNA2bk87fN4kzSgtL/c56AUmIjBW
tmwmag5BQnWDtBRAGJvHrfmw5NJnNqE8tajdr24eKuJrrAWKXTPNpVpo5aDJSvFe2zcKSA+tQbtl
HSEce6hf2NOiUfPLLR+AUcX2U1JQBjNfNPlgrZ3oT3AYjKNI8QErwOr7zXjhkOonplUA7vXGafWQ
UH4vaUTWJE8FilKvocs2w7ct+icfaIGtlbv1HUoGAz9puvh3AgcfBte7nPaz7H502Rhzh8KlgdOO
tjSAQPug/j4eMF0pSdqCx8SpeOFb3lVZ1KSdIvbs8cqFxjg7YA5K5uSRevhtoqgmOb5QB0ZPSJT2
JVXsI9Duu2KCVUtZgYu9kidWs0M7pLPgGY+3lUQzcgYXsCjV5atzb3An2NTeF5gBCDIYBSkf1fcV
TYNKii/TWxoPZHc7E2hRg527K2SOvXegi42EQik94d98523HoxcyBFLekrwYiQdyljm3bb7f/P8z
YvWK/mPYTqWF2VrajAdbsT0bOgt6esHM3yLOLyhqsPoLnrC8RGk2+6gd9xaPjQ46oswSsnOD3Arj
7C9m+Vb6OpK5r7l2Aywdk5L4TM70v4pUMVvmKa4QSbjIzHD4Rub3l7NVrvdfYWYGqr6SylnpUJ33
tG+F4ftKa/AuouUKYt6apVSpwiB9gjnyxVtANukcvFPZhKLn3mAvUhrBMeWY1MLUl2/qNJQC806J
HAf/U8fcEm6yMoFn1I4nNIrgUxfytZCHbqDkCIr7wD9r+D/33aiNAXOnyNzgIt1+bsSsgUE/sZvU
G++O66J99tzokkpl8+i800tGUbwqS11vdZpzR+l53aILxkL5qjfLDWVuZHN0cmVhbQ1lbmRvYmoN
MjEwIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dp
bkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9Db3VyaWVyIA0+PiANZW5kb2JqDTIxMSAwIG9iag08
PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RD
aGFyIDEyMSANL1dpZHRocyBbIDI1MCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAyNTAg
Mjc4IDUwMCA1MDAgNTAwIDUwMCAwIDAgMCAwIA0wIDAgMzMzIDAgMCAwIDAgMCAwIDcyMiA2Njcg
NzIyIDcyMiA2NjcgMCA3NzggNzc4IDM4OSAwIDc3OCA2NjcgDTk0NCA3MjIgNzc4IDYxMSAwIDcy
MiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgMCAwIDMzMyAwIDMzMyAwIDAgDTAgNTAwIDU1NiA0
NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzggMCAwIDI3OCA4MzMgNTU2IDUwMCA1NTYgMCANNDQ0
IDM4OSAzMzMgNTU2IDUwMCAwIDUwMCA1MDAgXSANL0Jhc2VGb250IC9GQkRJSkwrVGltZXNOZXdS
b21hbixCb2xkIA0vRm9udERlc2NyaXB0b3IgMjMyIDAgUiANPj4gDWVuZG9iag0yMTIgMCBvYmoN
PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMSANL0xhc3RDaGFy
IDQgDS9XaWR0aHMgWyA4ODggODg4IDg4OCA4ODggXSANL0VuY29kaW5nIDIzNCAwIFIgDS9CYXNl
Rm9udCAvRkJETEdQK1RUNjQ3bzAwIA0vRm9udERlc2NyaXB0b3IgMjIyIDAgUiANPj4gDWVuZG9i
ag0yMTMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIg
MSANL0xhc3RDaGFyIDIgDS9XaWR0aHMgWyA4ODggODg4IF0gDS9FbmNvZGluZyAyMzUgMCBSIA0v
QmFzZUZvbnQgL0ZCRExITCtUVDY0OG8wMCANL0ZvbnREZXNjcmlwdG9yIDIyNCAwIFIgDT4+IA1l
bmRvYmoNMjE0IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RD
aGFyIDEgDS9MYXN0Q2hhciA2IA0vV2lkdGhzIFsgODkwIDg5MCA4OTAgODkwIDEwMDAgODkwIF0g
DS9FbmNvZGluZyAyMzYgMCBSIA0vQmFzZUZvbnQgL0ZCRExKTCtUVDY0QW8wMCANL0ZvbnREZXNj
cmlwdG9yIDIyNiAwIFIgDT4+IA1lbmRvYmoNMjE1IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1
YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciAyIA0vV2lkdGhzIFsgODkwIDg5
MCBdIA0vRW5jb2RpbmcgMjM3IDAgUiANL0Jhc2VGb250IC9GQkRMT0QrVFQ2NERvMDAgDS9Gb250
RGVzY3JpcHRvciAyMjggMCBSIA0+PiANZW5kb2JqDTIxNiAwIG9iag08PCANL1R5cGUgL0ZvbnQg
DS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIDIzOCAwIFIgDS9CYXNlRm9udCAvU3ltYm9sIA0v
VG9Vbmljb2RlIDIzOSAwIFIgDT4+IA1lbmRvYmoNMjE3IDAgb2JqDTw8IA0vVHlwZSAvRm9udCAN
L1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciAxIA0vV2lkdGhzIFsgOTkw
IF0gDS9FbmNvZGluZyAyNDAgMCBSIA0vQmFzZUZvbnQgL1RUNjRGbzAwIA0vRm9udERlc2NyaXB0
b3IgMjMwIDAgUiANPj4gDWVuZG9iag0yMTggMCBvYmoNWyANL0luZGV4ZWQgMzAwIDAgUiAyNTUg
MjE5IDAgUiANXQ1lbmRvYmoNMjE5IDAgb2JqDTw8IC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0K7z+24dA11HpKFU5EqhurRN7qGpyDyA2UDWVuZHN0cmVhbQ1lbmRv
YmoNMjIwIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2Rpbmcg
L1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9Db3VyaWVyLUJvbGQgDT4+IA1lbmRvYmoNMjIx
IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dpbkFu
c2lFbmNvZGluZyANL0Jhc2VGb250IC9Db3VyaWVyIA0+PiANZW5kb2JqDTIyMiAwIG9iag08PCAN
L1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQg
MCANL0ZsYWdzIDQgDS9Gb250QkJveCBbIDAgMCA4MTMgNzI2IF0gDS9Gb250TmFtZSAvRkJETEdQ
K1RUNjQ3bzAwIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDS9DaGFyU2V0ICh2N4dIso5KzODb
XCmYhEZcKcMpDS9Gb250RmlsZTMgMjIzIDAgUiANPj4gDWVuZG9iag0yMjMgMCBvYmoNPDwgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MTcgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFt
DQpTNBd+GhFMbi4A0WZEeLWQZHrDipK48g1hQyLrsH+oFpKWjN2rgaEHlulwLycHKJ6u8wyJFuTC
9JXR2NPHtv3OzeIpDVfO0xWoQh2uUSyhzcA2IwWQUd1eQqGlwoBML/fTu0wvwllTC72FSyNZDhEm
I4gfdpz28LkeFXe8N77z4c8cn4wV+p8S66jcZNcZmZG5tIIucMuXNqmJ0ny9tKuit+Fr4c7JRa3h
LbHYWZ0UdHMZcc8cS3YmwDp+9MJuOVHKZxw87Gol1Qt2pVC3KcB1xjP6iML5JCLQ07tiYomjqwvr
ByDh+GYyvJjcTvSE/HsjFY9OtQlNH/VZcDZkQJOami9nza2Df+TSgYhC7jVoDCYnqbQpHnbuCN6E
66y59W2Fs79l8VuzU6cgH6EB3W3FFYhvcWjoMHgqkDgHk5DF3jWJUnyFqbukw33QW6IsVJW9jMNe
o3NCXdK+/XZCyvyfvmG7wZXA47Xmb7nN0R/abHnyLS6rdScT+bSI4wtdG/IKjVWI2BX1gDpWV3VG
FeM4pqv96Pp5QKnx3J8NZuoHKsDM4L3/RndJJAhYE6FOdPX9O6GznDDhukBs7hPXepXdxxU40GUm
F2oFgeMekmVaAqQmVQgrd9qljavukjoYb6AeaVo0yN6+DYidzf+26fcHy7RO+C5owTMNVHsidsB2
5ZNH+cVoDWVuZHN0cmVhbQ1lbmRvYmoNMjI0IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0
b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxhZ3MgNCANL0ZvbnRC
Qm94IFsgMCAwIDgxMyA3MjYgXSANL0ZvbnROYW1lIC9GQkRMSEwrVFQ2NDhvMDAgDS9JdGFsaWNB
bmdsZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQgKMBzTTbdoX7sKQ0vRm9udEZpbGUzIDIyNSAwIFIg
DT4+IA1lbmRvYmoNMjI1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNDQ5
IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KAhvcUwdORVQxCZIvQzfzI0ta3s5fce4FGosy
Ld7IEYCFc13M8SinYq/171pRR2ba6kBfjaQ1C/NPu1y08k6AJtfTqd18eIOC7OpafLFrmGT9Qtzd
xf4SbO7x9/u87ZBbZjF5oG6xphKknlnjjb2hKfLCvNv3ATIRV5zGMzIxlqjbA6CssSKkGUc2AEG1
FkTDhclntm6X7sqMMdfXZga+KuceXqzha4FoNrieQLIP/PtJBlK28Ewy+n221wSdhAVYmB1tSfT4
tWek3qRSMuPuBcIsQ93AV97k6AMa0APWVRmh1g/7C3Ka7rVXUN0wgT/9c3FqMgHbjd1KCqsigJXZ
+IFwbwU5jvqOcUzJqsZf8dj9OYyZRPdqWIZ0XnBcP04hqXJ3zuYXYoZUrndbUmWj0I8tlHfhNmAZ
dsDPC7FVS0EAxIapX/RRU2H0v1T88hQaKWIcv8mTGa/jrwSCz657g4iJYCEDWCh+ErJ0fgw1LRwg
CgB44Mvy9p8U2eenUGkQh9mT+4oyTL5Fai/nxgxRxYFmX8SZD0ZLOZS5dQ39wSgYH/8yVQrlziGV
mPQGvHwtow9op0WewSwx2mxctyEVDRsNZW5kc3RyZWFtDWVuZG9iag0yMjYgMCBvYmoNPDwgDS9U
eXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAg
DS9GbGFncyA0IA0vRm9udEJCb3ggWyAwIDAgODAwIDcyMCBdIA0vRm9udE5hbWUgL0ZCRExKTCtU
VDY0QW8wMCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hhclNldCAoEKi1Lu8Jhtb4Issq
8T1E62r7WQjzwOP3KQ0vRm9udEZpbGUzIDIyNyAwIFIgDT4+IA1lbmRvYmoNMjI3IDAgb2JqDTw8
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNjIzIC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0
cmVhbQ0KxIzHqTihHRB2E1D7myVg75IcqxgZED1oYGWZR17k1B076w5kPZ+0ZkewETCVM8vu6G2X
ae5HdCW8LOlZgUjGaCJ/3m2Wq36ik8Ri8GBUjXHjZc5mLEQ2ftKBGzSokAzgxmglrjPVbYQkRwRl
vpWUxfopKMhiMDTws7GZn8c21U7b3eE8skt1HidVdtPLO1v2Lfjo10y91PmZL0AhFm3Hp50sC5Rq
rfazfPDeLTG473STqI+AsnMAFVqqibaf3QQ96GXSGw4h/tT+e9mqca2oHVABPTrwU2QI1JQhTmy7
d0RSHBLCVx7DO2S7CpQ3Y71eOPrN/Xla90rOc/jJ6NcKRskokN8WDrUAUpjUSn0neflm2pdYVz9v
AxUSPX0txwmYpEN9UCKKciRHJJCyY10ilHdVA8hW0wzM+xPgQU4k3i/TV8QCNOBz7wqJMvbmLG0D
7BIgouQC85GPIdsRLrqyfhXVTd1NiDDVuWTaUU6xvYmY9l8qEuIPhTEZmCm8X8nFsKjyccfvh4Tp
eFJwGDgHLDA25MeFUjOtDkaXVTA+bNeMSGMeVZOfSL0oW85KsDgz11kDbCNdaICB0PtE0LyLS9Lp
mGW5R1Sh/4ytgftFZ32kNb6eHvqiTFJDtSs0hGduqTKNYVSpxLS87v+ynUqKy/3RIa4o27Py9AEb
v93WoXYXlV9/cs/L+djZ9nZhSfRdcH1flmiWZHo6L6FmQvj5f+vqbRvhEqInrqq+UmMo36nBCVr0
MBtnsQ3hz2+gEjVJRz2pmv8uYb/ValXraK71kSOH5Mfd4iRcBRMX00++59P0e300Y/zrluf7Fx/8
c20NZW5kc3RyZWFtDWVuZG9iag0yMjggMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciAN
L0FzY2VudCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyA0IA0vRm9udEJCb3gg
WyAwIDAgODAwIDcyMCBdIA0vRm9udE5hbWUgL0ZCRExPRCtUVDY0RG8wMCANL0l0YWxpY0FuZ2xl
IDAgDS9TdGVtViAwIA0vQ2hhclNldCAo4cKpR9gRzoYpDS9Gb250RmlsZTMgMjI5IDAgUiANPj4g
DWVuZG9iag0yMjkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0NTggL1N1
YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQrUrJzLEkVNWo/esxh9NHdq99wF+bsRT5U6M0iNMlm2
EuYEOQhJpfyeht4vd7tNnJj19aEIEueGZRUfDxGChA/8kacZSotoQ1xJmQcgN3voRX9qGeUbJ4bA
JuKEk6cN2MVVeaJQk5wwUw0otK6lB3AAFJIFqtvaCT+3jPpxaOguAczbtUtVDBSobj0xxA22adr1
VIi6tjmg/pk4xCL2Ahek/Z3jXVBZOX/MWaLc8scyJNpESPFP+3hYC/AWUl1r6qgjYBW2qGQh11R2
ZCP9iPgxssK7Tay/U1OSpMnW9hzWQRhvxti4rlYXY0sOZ8WqHKPko6ja7ewKJRqGrSeo2dJ/OCpL
UKbwoqCRALDWs5RdxBZpkFfkqT54VvLVgoZ+20PZgbEAJ4kqd65lNp707IK99TBF9jloKNtSaThY
MeWeDcmza99PpbACFf4kBEZ9YMG6F0z+QDkuIBKQaYmsiIqxjLc+Icg5iyft03uN+I1Vm9Z6W+j+
mShaJ4tHV+Qhmy098PLL7yrFuBgZl0DGR2whKNwRD7AvWfPiag9w5YxEADsDnPJ0oEPtWRMV2KoY
9u3g3C6jvRRuytGHdD39/g5CQ0OKhwZOyZeRzw1lbmRzdHJlYW0NZW5kb2JqDTIzMCAwIG9iag08
PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2Nl
bnQgMCANL0ZsYWdzIDQgDS9Gb250QkJveCBbIDAgMCA5MDAgNzEwIF0gDS9Gb250TmFtZSAvVFQ2
NEZvMDAgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANL0ZvbnRGaWxlMyAyMzEgMCBSIA0+PiAN
ZW5kb2JqDTIzMSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEyNyAvU3Vi
dHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCnQRyY6zFMtrblvA8khLg8S8oOC0u74M81QQ2qyVAAT1
b61hYS1m12+cZkrS22yerBSDLO2nomsSuNsXyo33FFDUPthLW+W7aeuo6bDlxWRkq+FfIS8+SVDk
xr/KvHIOrv2S+3IkYCclnBJEW7SzLP3OnJaknXlDSHB5roBPB2YNZW5kc3RyZWFtDWVuZG9iag0y
MzIgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWln
aHQgMCANL0Rlc2NlbnQgLTIxNiANL0ZsYWdzIDYgDS9Gb250QkJveCBbIC01NTggLTMwNyAyMDM0
IDEwMjYgXSANL0ZvbnROYW1lIC9GQkRJSkwrVGltZXNOZXdSb21hbixCb2xkIA0vSXRhbGljQW5n
bGUgMCANL1N0ZW1WIDEzMyANL0ZvbnRGaWxlMiAyMzMgMCBSIA0+PiANZW5kb2JqDTIzMyAwIG9i
ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI1NTUyIC9MZW5ndGgxIDQyMjA0ID4+
IA1zdHJlYW0NCk4wHtmIFLnQTK0BNZB/0kYEZu+aPXisF1PmQ60lyy6jmtSuggQ5RacDcQE4sS9b
4OW+UfP/o7Euu+kmr7ApKKnokXq7khu8NsnJwTqAcfzrihnCh21BnD7fabfJHumZhzCSgKq0KhfF
ZpgA5Gi3Zvfc2jrrU/QIPEpN5oCz6CHSygD2bP+l7NefIIeVYrO7FWexNL3uxSWUPdMv3R60b56b
sLKE4pFz0vdgsGUr8xBwGLmDH2hc2WkfeyuwNR+UzrTvDGScty8ctGUshT8Dh2A7j5QX65Be41q4
okqZ3oESgWLsG3uNDlvk1/Jb4MOHCbVwPEzhWHHx0TR+ct/jzyibwu4IxCW0nNEeBTaVwNCamFlh
SXnLOI6Djp8dpP0K5WIVlq5kRzpHats8vW2plHTnuHDN/dPbVmvlxDC6JdDZFU8n9fJZbb84AXae
uE+vx/HLKhokvHVCA6n3kEtfXY2gumZFOnvTv9pg+Or6+O6zVrSNAIEphpEIurBVmcZ5silzQREb
fkbydtBWVpjC6iGXselaVpEsVZArb1VAuCQ0HmXhfGbd+JdDZ+vCvs8e36BpxFEcCzfaJ8w6gYMk
LJmttmfh4/r1OoDQ+TrlsHk1t5h+ufalepNEQhZdrmMoR1+COzmdAKZcAG2EXOf91pl/y8rBr60o
byBE6xwIsYHKY2jT/w22O8yAqucAnckRWMZ3xY330440Bm3pfvG6qQCmP1eOWN6NAqgxjD7lB230
+fq7NuhQ/L79rtx0kSgUFBE5V4l41Eg1p1+dcbVaUG3ulUN/i1oPEmsNUhKMFJMF5N4QkiEk4soK
bUysi3od9NOPIdTTZA67CQewQK40HCZ2f1y1ulQAzcjDD0geA+PgOaWGyWtGFvbOIZLDgUbXSbEO
TKU7TPfKTHPbSifW9rLs6wwIE7NmTvBNwNgWSDqlf65wDVW99uiXEMHfMNTfY29eBrt4R4RoOR6f
Es5muZ8YSq/Ur7o7hOVsqWVeLyIXOPVTmUCD3JgUyK4QMuuqphzKCtv4na2FDYy/tiQyA8pKoLl2
GEIqS6tKhIflr0JZDFh6mGJTJotHpK86EpFIHPGs8cJv8bDsSySpp7gHAtfcZ7rwkq4rZOmMLUmV
EAPmMSDtJSxTxOWoYt1idnr27oxhkmKCg49naLuFTWZqu34aZ9R9RKZxBzeZVboV7HpPEuZeeXeA
GlXCRdoMb53WQ/a+ryhoaa01IOaYssgAvhn2AE9JxEzjCx1eLDSkvXhZOaMDkvCguwi8ftR81+Lm
anqHYi0MMWsohciZl21reQl+3Dm0rC+strJmYaEOIL4FR8xh3bULlsc1u6TgE2aXMuNM94GTxDYy
pYAf03ZfbRnusxHXUphTzOzQrxUf5UqcmqvMyhsdEcVRdt+Jjw5u3qJ5ENOKq+uNn/nLCsj03iWu
KBEsVbZGCESKuIV32Txja3kleataiadXHWFo5FCS1sScV1XZaxXcB/uFnVECmNZvzVGNt1/IO5ax
HSgj3wSFPp5hBqgIlKMa+Cvj1Vvkz19r0Kp9MYApHQ9yzePEKVfQ0Ykjv3q554EDFA40PioFrx/e
xcyeeCy1g8o/bPq3uE1BdFjWDJhMIOF4zxnwzWk7bjjpKLLEScmy5UcsFrNugFpK9zltpkOs8KX0
GqBQF+OdvXsIcUYCfd14VpgYAh99QDJ2RMo+rQEY0nRqLyF6V9sjlKdci50Ia0WSxwSuvsI9rP1S
mTHx1mV/ynK6ZkavdKy8ipCqlotViwUdk9NN+30SP0PHWOv0k0ePL72g1JFIwoEje0IhD0pvt2IX
leDlbGAlNJTaojaseC+3zyq29L3hIoyT9ZGzyc/4MSoGPmn7oswaw2d9GqC3wjQrNzOKeiRd1PId
KKG+tLe/UPOAoItIN0uFhjnLJC2PcXO3zs2cUxpfz/gSFmFxF3e01cM29YBq6Yt2U0qGOCrjvHsc
2d2HB2hV0M7Ge4VG9Ts2+btwDgc5Yvq+Z22DlrsVK4f9Qvatj17DQeC4EnrhwL/0KJXwDbPOYryo
gW+Z+g4zAEPl2E1pwonbvcKKHlwjZqNQRtfIrOP2Omrpm7zkMIGxKMwN3Q7bHCAuOBHAmcs504IZ
fRCnWKinBNv5+PbP8y5bNHCSVxGck9TMTk1zuzEcvLZWyeTHe5PHhObASzPlSaPq8x3LXJSTHGer
6GWyf67IQMWuisAqc9JFDcVuDJeIqvqNI92Gn+Yqvr93TrctPLXKnSc9huoUQACvV1dBDisWqSkd
CuMXU5bmCPV4n1pooP/6ra/W2EOXIWVccTJLDPAFcuNfKM27YwJe3Y3HBUk3aAusv4ymeqQpMEat
dVcIkNjDQTmRBEAAJ1fHpqSqNMp91zDRK1NsXbwVjiQfy2SitROY/13DnQqSIivyf0uITaB8cpSe
aaRbADmssE+LOA/4Jv6LW1pwshIefcFriCGDvto91/XtYSaflOXGyt0JiYIkQ5OXsn0nZola9lmj
DtCzFWMUpB7Ud+HCqpOnBD9G0SvzizX0yXIWNrvs2yVamoIFa4Zim6cnGi1m6Snq9A3wmNXWG2vJ
3yq1bJnUpDbXv/4NXxNrmlSrPuGVDlyDFExxiY/4h8DpqBYX0tD8XU5Ks1v4tilYXbzPZtOHLcSv
cnEmOm0K4NsuCNVQXWcPOxapRdJpai/eG5/Lx99R/zUEELU8tZVa98PMvH8iZykzanYSoT3ZOelD
v7sUOt3JXTv73ocr0+VRVnMPTHGVzv372gvzpYzv1OGo6AWO2GOqrChTsxdDbS5y0jedVKm/NqCg
5L8ZCSHkCxtchQbK1E+W2mA7CtPBnaUhZvya/uAbNfTCakr37pBHgHB2s303SBcOmgCIpoohBk99
6PIS5k7nDRSFvb5fRyHUQCkaCMHF3tqCemh7X7P9gdMkCx7yYeeQHzmnyUukQM5yoNxkkL/zqZW6
U8s4PsnQdnfx+jxtaLxwMP1oHJ42tI/liQ6ZY9u0UDC1lBHRE8qlXkb3BknGYCYsDm7qisfGwwv1
0qF4ESz7xqni6h51HULTwwoXJLEh8HynebidhC0I5cD5+MuQbK+GJJO2by+5mQNgC7UeyUMRo7Dq
hitq3EU3ZkLhCkpbIFKBY1mav/IZ53RX5mCBGLGqTQviMDngWUeAbOThsnNtSaZIr7FE3RJFKrJm
U4HnSv33a5zop0x8XGdyCDhtYsVQ/jEEyriYTJNbA810ii6UhHMHEXizWTJtDN5MsRh6CKKojBjU
QyFj08LqFAnZL17+qDyHE91tTDGimUIYOvtM8VpNJVQjZr2oT+osdvkm5DHdIRl8+P7rMWUa5+Og
C2haaVJuKABHWwt4nY80HmfsXeSnGgkY295EMsDC1UchOmZcEzuoQ1k5+c5peTWYyyHy1JOFUEAU
G7Q2stKUyAk+yddBAo0J8J6jXR3+h0NGUspHsMqs+1c5gUouJf6uQyR4czeE87cXo5AjfwjnSvNc
yGGeSTjNr3kHPWIQh8GEqm4JgfLN+76SkmkBR7p+hcULWqMRwZ7eettuKO/YPyRL1o943Q+QWafv
4iSw9hA7+Z3Qogw3i5zlXjqLP8H6bulUjBGHhzerIYUv+vT7B1zh8vGYOTh8rZXLDsiXNntCxYnI
G1O6LWe2xvyWZDK7YqDTkSa2YgeWOmcrMDaNEYurld5f/4Qtc62mV//m8aEjTeS0dR34XTvdkYpN
aOp3gYcEqCFYsxg9GwfqQwy8G2qKj/njmJZZYwBL4YGglMRpEzv61zSIid/Ls5C8Cs31un2auPXx
3EcE9peviJWL4dVEQMJcBwQaYIvlwbQeQmzb6xkuRDKEWcTey25yPbccf5jFdjso7WTB6cAbCX9T
qey0N6ztqavxzgSjT2KgZw0Ygu/RgVbGpn8l7adlSBo/zWn6WnHKmNIXQJar2LOjNWRKhO1BUXks
0YWLnCCWGL6vPB/Xd8iG6AepnMZ492zoNFgnPl+DgNzAqPmTjYQ00klkC4btD5nQW5VhrrE9Q7Mv
nE376YF/YHC/Ew4vS59qK/AG2qsdgthu6O+2UE1NPBduKzhA1jMv615+py93xpe/nNzIbKOwvhuK
TrWKUcPHPhKxi1K9oo6m6GummdefpkJPvyGHrnt4Zc0E9DZfU0shBOdSanfxBsW+kr0Q6TTlA3bQ
s97/MABZ9dueSfkLBfEJVaEYwKIN8g0E6IQLON/q6h10kuLNG7IeafeFfjf+kq10bJg2T1Rtnp6T
Ww+S6KW8MtmsLIqvN3kIn13i0RjW82D9ocNje9JoVVZ/fMH1N+6QOByu7CiMepZARFWO0i4MUjfc
2v+lezJ9roTk7/QMvx9zTrLsXtktpD057KXYGYI3i27EtNzZ0CzABvZhQOc0lJxKmzGrvNmCllKy
wxAp8TAURInA5XdsYnJbPj4pgLCLI0OXY1feMCsXxE225KFhWUuy8SCOB5k1bwPUSQzR7AMFJf27
SBuRtECDXrR+7DaQu1fUtpo9KQF8BXLcLT5Qp/ThMWSTHN/35EEtCc7zgW8m2Bpmp2wsqDaV80JF
iixUDWytDiTpbu9sVQkSnhd2FdTmtiZgtQuKQHuMRIP5aBUDHEBO5dS4qA+fj0VoilTGZlJbb85H
wfKMvTINNL+oBt/hI9P2Vf9WKCQfR1arzpReqD4xiuvweQyz4xZDMzceMrSalrbDrLSpBH7G4oUu
TzJkAxHBPAPG1CuQ/m1lw4ru8aINWDtkckHQgGf0AzSuDSK0eZccUfDJi7BqIaBPj6B6+P8liqCP
WiCk+JYv7GPnbNHbW01BzOp7RiaFIen3sA7mpKosbuV2nFctJhTeRR8C+/Aju3Pt3XfGiSDOjZ9l
NdMFZ8VAkfHApiTYjNMcaruonxsuo/81sQaGc9xBKCENXSJlj8vhJN6GqwFVOA3Pj3BN1BKpvibH
f49rOvMcTpAsFxD/XOvcjDiiX8yPyGg/GpSbspYapPMcBVhD8Z+6isH2RbdM9QHR2zLe0f0wxRVt
rfPPLu3nv0dxxJVrE9U3vaylAnH28j99kotJMDJmiubKcyDGQR8L5E5U6iQMbD1Yvi+aSJwS2zVv
IlN4IQVtjkOKhil65oRAvA8NyoizEGOriZbNmoZXZ4c0WjKp/FZpjeneP6W3FThwSKqidAtOnxlO
/loFfXT009Ji0Amba4MKQ4jvNc4FHmuXJgjEgb8ttyiEQNkb1fd6oQ9bCpoA/TisZEl0a4nGruN2
4KyDnwOrNTAPOQ0NS1VdOsmBpNdIytbB8Jpn3xR2B6vY0i56y4WMqpdk6RD5pxD+mw8sP1Iadt3H
bOg1Ah++Ij/XaCgkBuWMabup6iEMPiJ1Qbju0LBw4Ai5Fs0gclMKTSzzZix9bMcM69udF+cp+wBk
gMbTgfvsH8hj/i7t5EpA9TDvWgQFULIj9XwZ5BuQT5GL0RaUKn+YALipr9ESicCWM8ZDHfM7satj
OCwTc0dkk8GX6QTWShdQJBvc2dHRyQHhOCp8N9RgTFIWioUSu+VJLO1I93Pu3qNZTHo8njnfFbrw
ICfmrUVgx9roqTHQYUNZKrSqm7oL/qWw5rguAwvren8hNOHRJX10OiJ+TQXApTDiamS5vPF83x4W
1NZjceffwfsP7l0Y3FokBdLSdl5Uwr0e4/S8MPf78jYBsdKHOL6IHL2VGpysq6Gi0dht82+QzGfu
efXL7cI7+NEeTH6fYcGKH8ki1fZUO6rYTxm+h4HPYTpkm5LBRsKK6ZzzlgslABsmS2fgaSqUlzhP
D6WwBB6SFUk11ISHcNMn/Hgo2MhFbFJfq1HU6u4bnmL68DKz1D7BY4iEPB09mnDgSd1l+t4BT4N3
WEtwNof1LH4e8hSBB2aQBaOgP+qyYgbIuIyqdii/WfZt7R61XMY8NkbeZiIOJj3T4ufABtZtTSx+
8r15nSSavJ9XcwF5xFQcLoLpl3WMGl0s3jrwWuv+sX2N4usoz8/BXwdvu8jLB+IRbxQrsmXTUrNy
yQP96EiH7fSgAsWnWfZ+DTqbt+pZ+WkwtmRwB5c+0r9w+5s98dSuc0sYjdkPiJDEVlHe8ApZpem0
ykV8zCDoBe3u3ogSXJmHNM2hXgMB6eWfPiyltRVKCWkHS0NVGAsLEnl9F1BQ0ptxI45y6KhH/F1h
thhKMqxR2OXRbD+HKbljHTZQpoUmzgELdJCKBOflnkZmgv7Bssnkm8Y62z+L9dG63DTfVPUzbtqy
R2cqvNprauCOONEDX8318HWcigorIOmk4Wp8RYM2P0o2eDY0ltf4C61IywDUgM445ZLvxVgQKHQp
BFLGImWGzfJBRedjwn9d59Knq6aGpgIYwVxy6WNZ4zo5BGIIkmtVghamupHq/9djSsF83JQC+wBn
NmD7shC/wuUdlJwGqZkbydar3sn1or1karLOYTFWTILFdBvZNSr7OmtNEzpcb4Oe4rWgHIRC/Nvj
2sI9HOAjZOy9a8UnglzFlQCd7I6rre81Ob0sk70Ud9cjhX6btI20QlneKwn7FDPEn2L+5u5NsUWN
LEVLkWkGEh4Z5IF/oe9Jkvcd1uKrEF/DFDWFcxi1brHRJdRhFJyTTslyf1kXQkcU74joun9HH1d1
xjW82NH93rWY1VVzlWwDDNES5Plx+w5y58WeywVQaYfd4uS1yq5paEgVwS/Y894/7LQfauSaJ7Mm
lxH01ACFm+UB2yR4//4Zx7fYOxFB1n3T26raa8I86xdGjuxJSTos1xILPE7LtuT0l3i2qmRIDYye
ZvWPpeK/Um+mHUu5N+4KdoBQfsrQK0jjYrbX37eTUYyEgcFMwpZJ5QSt3amXsCh7Owcr4ZeqjUKG
mFsNoYpXN/vg02LObBqbzNHWicAabeRsRps890XwefxNi1SMIzECDAAei5mO1ztdjkYxIEZxycjy
C121+GrO7Qp5kes9mavPHa79QElakcrbOej7oWUqduRHubP5/JlP6RnLdSkSXclDFcBbI8KdTgUh
gW1U7dH/YVx5an0w23dNjMtfy6Z+o3VMOvjZ6hEiGbLQsrmtrlql3glDr7GTniL50Mr+YWKOf4D/
mCoRc5rH/nA4RMzeSrMWt+poWWTPK8I7jjY1NdEesXLm5PNTKAXmuOHHbBOsfaSJkgRd29s2Xs8u
2bJlO+v0wPolDcX0ctBEVzD1hkBwtFB2dEBUARYyltyJ4WMBi/m7WmAJv2RYKnbmnIGu38E8NrDV
BYeFKb+wv05Zet0iHTh0DHm6dfEMK7X+aF6Z3pNzn5fryFg4ImEKH1Lq5dOoSiDSCjxbAkdo8HDk
sbmblouFRQFIZLiKjh0Abtrx2TmoWxtw2qL9zrNUF82jCv+hUER5soNIwZuPXqRYJQbu9wtKjsdy
ODqt5Yc7SUXjElMjNbb1EgXlDG79eOcIiD6cmhesgvA1N1Yr/D4O7888+2zvHPgOVBlS4DLFOnU9
xRp3L6ZvBD0IV+PxJV5XSo7y8cjgFtXcMFi7dmRy/IF+AaE2Tfrvni5n+FhQrE3DTTmGGvkzzZk/
n3f+mUAXox6Q5csimyqFwYRHCqlu9/Tzgqh+Dx0qEAVO2RObSAMLyAlzXRPCZz3fmAsgYgroquxU
dReVO3g5LcjvHWodVg+MO4KC6w9kA6fvMFIyKUK/1U5n+39auwb4WHESXRct477mqQ3S0E5g3ADH
Sw9jJLFJGuxHMcCgjRLowC9N0PnJD0xy3Lp+CsY8wGjSN7SGgKxJbpmI/E1l9jRjXzljvvdvTSQS
tF+M6brPCk7lm6RyxNt3PpO4yQWAtpUwROEy61jnpaXSv2amfIOf6v7BtKghAKe8A4TglBhGNLAm
xREBTCmxWxibuZVsMdksfzXArLP36/zo3/fOcMoxha9XS1bvxZnUNb1yfClqLdlUBZw53i2KllCf
DJeB5OkWfVf9qIkPjM3lt3qmxYZ/KcwHB9+gLrch+D7jbQ/qvuNTT1AD6+nrDoMfFBCQknLz07Qb
MMR7D+yH8TAhwEwVGUp730KVp+c+FKcQQ6bMxHQ/1fytzASXkZaLPZKFfLRutxln3p92TyaREL8b
EX9ZjAmyOXbRa9LcPaWYfHhx/m/7PWWJ9XR70rYQpUPr8W8CVKRY10vD5hrsVQ1BAgEaz22xSBPb
JRoI9DopqcEW7mo+TYcUYCldZIzJy65VeIYWPioipzBN1k5nziLKZxbW1/qHXV+2Ew9aM7SOJx3F
dXTAl9ccHEjtTddajqZd5Q99zScUEGi89Xi3q24uEbY+7ZS3fDDI+yVeHFdQGoaxhzVFRQXL7GVV
2Gx9/koauS9sVGcQxeQFsVNoe973f3IyeDGzIuWj6c7efAuqDvXMmV6gi+PrPbLz6FL9Bm9iR/jP
ZrrO4o/WWhqmnlS4HYcQEISZfdtpNCcynAODoSU+j9qnVlFeRpL3y03tFw2uSDY79UhdoWDo0S7b
hL6wo62v9sCMIYSQ12LYfRbyGSXTnacg0cRLN+OroJaRoJKPfp5dcS3wz6vZ6g1jvgcEF63K0yTf
+tfMaqn8GIpcMVcMZXqjTY3h3uKSefsBo/OSS7vQ7920joWfxcLg/XXc2HyQJxJ1fs3AyeKiZfWF
AzqjxYC/7980ph8YqarJHusHB3Kla24DStjLU/QSkQusNorSZ+SB9kl8DrSulpCYfVLP9RfoinFd
HcGdmtAYBHy5EuR66I87F33q2JBWwshYDDor4+OgWZPtmhbdwBTwjMq4kiz+vZno+bsNQ7BSF9R5
tCYLS0FPcs205KoeTp1d2YEkaX/2i8bwvUYhn5iaLyI1aTqloYa1KTGvsQLhIMON4t+en6Jsqo5Q
NWvCZk6iXUKrzeLLLXdDKZMH5OiNZLrDMiiAFvmiZt/88eIMJzCQ8vkPpVdnS9QWQMmscXZ59gy1
dqL7Og1LsmbRuErOirWKhC/W/1jaQJPwVmIiCsi2tiaznsdO0c1SObEiBCNaledOT5PACiyEEXzk
c7QpzM2p4GnRaBFA25sLAvwpfX/iuF+OGmKvmI27hXL/AO0jfoi8HuKyP0gZsERpRQzSODxqRttL
jfhYHV3qV3bDwWR+2721hmXHvbN7vDxc6IGiUkIwfhSoLwG6ugUDIj9juUUDX1A81q8IMRr1Zx9V
u2UTi3nTgMVTFxGzzeqv9tEjwzUNH2Ksnw1p961tBATN9+bk9eKGWGyRyMAvADTt8lTD6OMFNdOt
AVzQpu1CrBYG0dMctQb+uTv2ef0kzNfJAl02iuKsyddwMekj/UKSUiVHJJ6Y3fcbE8AO0gZirpLX
tPo5i0fROMNEvyFerrSLFIOXPehxP7NXBfotObFcxqNn3GTeJZBACEUYDPv+tXlHS5wEhK30OH1W
mnsFSk0iogtYNsmpicq7bk8pceaywHFWCuT7bwrmPmZXUX4DvpkH1oITVda8He+aNNC9gv1nvSId
AyfWSAw9FTiBbXe0g9ci96Y6MVXyFwGUEj7vz2Eon2imwyERwu2WLEG4sR5GWtLE9V226sfa7svv
pS3TSO8stcJl8WzBVTSHG7pivs3yd8DlyKUNzrN2p359GHWqafADzvZd62A5w3sPCC6/FtmOk6t8
NreJk7Yah1d2wpisvK+SjPrVTTaSnrbMIbKLcWj1H9SFEJxdu2WLCo57Axti0blGvGVkQ5pDlL4Y
slgNGLuHlpfUqFdDPpYrWaEu3JZV0jtDftF/47u3dZNWzLe6knx8lDA6RwIPxs5uiGDkkvHGXtkl
6MLWZeUbZlhn17APKQntChYyjkdSxKHF26YZtZYBAf0CmZ0X8M5hAtIqNpQveyldEngxkBVYGRib
HdhTGsbusntZHoffn9kXPZJGvKIQzqEFA5dDBcC9z9GY9z+KZ2Ak1w4BF37OJufP75QpHH60EBSm
93GFCQPkFuYEKQU5zTZotB3/n3XjVOhuC8H3wPARnkhMQHw9TvceqgTiVEpFm7pPcMaMZeRoD77M
voh4006YdJ8J6rda8moTupmTbQaOsEgiLVQiTXAJxU2Hy6ZAce+w7kqAP5chKXF5mx09v24h/+pz
9O9Uz0BcAnH9jB2wOzmnJVt29yqVTJRPrviKHGFBb0/ORSioPOtVrmV2mILkPbdwDO2Fs3nwBJMy
/x1EzIy37zmXvPkE0nIvJCKRTiDXPvmlvB+0tOdpWSPi6sc0oDZq1Sc/joh6iQPSq3k4jPSarl51
UuH9zlMtiIQSRU27efkgl6LLsRbgWV4Db0wuWEHserr5EiqlA7OuV8BSfaVdE8ubxaEAojH5bhJN
cI6NDxWcO1Q2rysLGsKvz0RLl8p0iTj+SQvMr30G0J/VZBW7htctxnzzwBRcGVx2wHox9lo3sw5E
0lUCp/mSFFSrluDOuQfhekRosL4J3HSm5EoTsU/BpYzu0qgKNO1A4cUZWdsafBNCnKp9lAylUd5P
SNSJji8zVypGujCWmLvkIoijc40kJ56YY4c2O/SDDdMqeLm077PZm8JiSHFTBCaH1SWlqHjAofyc
6dMGxshjFSJEVksCHCFItvWlcyJliLsNnuetQWdacGtQQu16YqvX00V32c9rjYxKo8ipUgcAuNdo
JAdVL2+Hd7o7RnpFQpa3EOroliq7cBLWGhAozE9mHCDI+9X0yI7TdEBQ44R6OebRqr8rj5hH3e+P
JHGgAYqinqHMFz35IgkZPGM/JCyQ18fqrvTeupoeNDNP7IyLeFrvP5ZEa6kNFlvHTFExpuOHQ4aK
VXq2WWQIZbE4WkCcd05UaIOrjUY0NBk8xLzqLkdj2/hBPDalB7ZO5K/lHV8c2FSIkHZYzArl5npD
0ne9Z38FTx8AM/HDimAMecumcQF7ktrNg3m1btj9clwZL0lweE153OwSavpDEg5akfThCPn+Lkq0
PmhDVmVr2VpfFwALH0nqNWg+ORCZ4lJrhA3t9R56dyI89rjWecUyFC5XFx8u2tOBYEeKGcV6F80X
JgvRGmMSoDPAIk2fZUO8pRkx+oU9lx/zciGAGbvKD1i4jmdo5UOkH0ZG7PBAlOOeezvPb/S89kui
ZeGCMlJi5laAczN3ku0VDxkBscYwmQDNXVGWjG/DDtzn6MGrD1k/2ylRz33YzfLUE5Nz06JWtm7T
JEguyD+wkDXNQAM5KX6E24w8n1KSzaRpcNR5j6+IplZSDg67r0dVt0uxbYUW2I5rxMODws4Qiv2d
gS9CACFV0DxDVjZXk2NX3OzGMu4qBix2S08d3SzmYA1lZl3WoPUFokDTUY8aqvrZUwZRpZZ4oABb
QrWXLakyo0SbYurFSdSd8nxgnmqwAuFOlt19r7FDlNdL7YowpLFI4T/7MMgp/qTWvDZ7WSwGQcMH
rD3vloyXZSA1eYQxDS67r/o3v4Kr/HI1CFPk0cHomEEg/gvRSVBkEIbtwvx9zZkwpynKvpD1PJWK
/RVywRu3qrch3ukdMwiVcfB7mFJJe7yEyDyGaPf+ZePcV57/2iW7VnmzdnqBQyiD57FV6xEP7fku
TKGBLT/6S6bAm/uWPWf402jHHesu5oOmXlaJNETgLm2lQt7BK/Dinpq4kEOjd2hALRBWQX1erjcv
uO2nju64FAxvUqTbNBESTeNU1FbR9q7fy0qygSHsXCLo96j4lVv6Kn6cS+ylp/4uL/mEHOmRFsPp
lSshOPKO8mpgj5744I7hqYsMQBozWsW5nfpVVd/GvplTiLVnXOcRe16K0NlXvReTMdxnphQ4zDXI
f+a07dnTrxaDGCsRCpwg13Q64O5+F1yDUIPYc+sYWuQymToFDEdDrBpDBl7xut3qkl5pupxnMVq3
gqMEzTCUn0g6Juz4XwWTHSEu8Jx4o1I0e5UkbPHs6I/6bSidfT8T4EgPrltwA+TyrVx9q/FMMerc
GpIOsgMKhwNS7egUzIXXTdP5dASDMS4UNEWUwJd2A+uj/TsQR3JVISw2Klh3SlUbdcxNnapwspN5
ECxIvsQ+jyVTqAPBS5bX3Bb/5Pxt5y7ZCoVBEpITC0t+vi+bD8R4ArHJSIGuvzAPKovxR49CD5UU
u3YQ56s6CVmJAV0ptpdYVWB7TUgWdMGyOiWx40+2hjFjlu/06ZZX8cwsXji93AeJOGH4AjdZ0edW
8IwCQqmQ6UZCYE0p4WqjwqDWrlwddLEm2xN8Fk6sqI8H1auL4JyrEl0O3HVp4wi2zICoti0MxAp4
h7A205WOydMfDNv3N5UzDaY1sA/Ja9u0a6T6vEyzSpOk1OU/DP8WFBIqS2+n6wlel8Iq8yHiRUwl
S26VuWmElkXQbUX4eVwmO9aKXLUvJI+Zbvr8eYeVFn2AOT+oY2voNShzjTbpfO/9WaM+HAH/r7ud
Og2vnkGsveS76WlZWEy4YfYwD1gBdvtcmTmk8TX8QZFHH+N1otOruGGbKsXKRBLfKDgbWsoE1ejN
KsXYNmFnRu2/VBNmFXoT4SbF3V3YU9n82GFh1UyYIzUmFCZjN5lTNYNihbM9VhFuzAeVQ0qStQxd
WZdMRm4T753YF350KU8lSFo4EQOkPRNVvEOZnevJKHxOMsaRAyhpJghgUzv5vodpGcRUj4UKG9CS
xij5ExM71ICRQnqd1AB9prnNwtCs6YPrwoIldQyUSfupWlohjttEKuV6x4YJmFjb3HiInvvmm792
L3uvjnraGZ3q9L2HL7TWtVcy6cDCpKMR3tMdIW8SRU3I7RG9pq8rssr7LhMkWzXiyvdZJ1xv0ZNh
JXrdLYmV+lhWRKC2yUfy/nOWFiYjsp32ky1k82TBO8ncmC2Lnmm28pUQgLjHRj6THQ7hquao1rnI
agoe7K0Y+CV3EQSOaTakIagVvYT6oM/AYiTUSIvcOsM/SUlXqAV9LUk/JGoW6kyvan2iLwGmmwZT
H9dOWLBwMiIQs0sSH0IvZ6vN6kp0UeMrUX4e4H3/XeSlaIJfniF9iyvaBgp7Nknjo8L0MxQF1775
kiLPghUNZ9IKgXBLrJvZW10YeEtKAP1Atxm7pNYFP3ccI6ae2cdB6UKmsojm0UW+//5HipVaex59
7Qpv9XDmg6OX7iJbt7qhiRNhTus+IcB1Uq9ISfV+EZjM5L2zA9tSIdaAWxv8c56f7cyJEbaLGLfH
pnC7QlfYZfgV471VEY0wwmzTzssJPIL0EKBlw5TkKRvS8CKgbq/tfHa5eXdBCAtMf5D80oQ5n7VN
zTu96FrviYlhg0TIClZhkKIZZNl9DqxGvZBUCZI24xogtoFDlbDTYHBMbVd2B/gKpnFrnB2QHrt5
QcGjBtQWuss+LOWRrwSQ85UGPcMp+c1Z16g//EwFLbKGNk1gqJmN7zeiOW7hLSbBFpT+aR3rLpTu
2vXky1O1fPFjLkBMXOt5d7IjseLEiMhWASr1Y29hht67lh1WMMSccEpjRrAlW8UIACQPmduSp7AA
VelPXmV+jSJzDqb1EUWnayIylXIqHLsobbyMhMzx4Xi2b1RSVQnveuYh3Cof26WBeK/ixqkoVzjF
6bZGEIX1+LiCZNv98+7AleM2KcW9lE5Y0jRTBHk+8vaJjNdYNSp697MEwYHEoADhViOoQ1T+AdcL
0o9QQDGgC17MBblSlS1BngyjzLRkEDpOvh1LSiK3KimItNa/hbU+r3FfLZ6+d7FPFbvKK4LBy+By
9f0qwwSmBVGMb8QyinSHZVvVHBdR7/9T2DWbUkJDSfDyc+lvg0Sluy9HyofGcohT3bMVmieu1X6y
p9PLNkmOlLAN+OtIqRndiruLGJ0ay0ocovmcJdWscQ+7kRYQBSuU6px7xF8sO1IenVRdVjJr5Cv3
VAPcc6MEP9UfFEh9Mg4fzpWAKUkzzGiIUjLstadNnzzKP3pRmm1o53TtOf3eHHteVjEcJUp8zUh+
b2l7bd9GyxPbXP90s0xfsLTzaCxk5YipBcG5HgA5Sz8bqSQb3uidHjXIQWzmPGUdbMczPaKi5JiL
6T364Ml1/Vk4SBpIWHEM3+F49Op/QmJsZhvJ4ZW8ROs7jRbQHIrtUPK1Wip6dq9OukA5tgkjDxDn
Q79bc9SGgK+s5kgQY5u2m94F9obXR2rbjPwAx+7iXCBT4rdep4UCh71CsRJuY5jDBGkGJk3ovVLT
MLffcDKlP82wtmwJTwWzMro5W+MZxxz+Mkf6g3suFiKIP9P5qmP5skNJiKCZc7ruXSkCV3a6Wlye
PFvP9Nnm1PzMAxWaD+jLFvRlAYAom9ucd8DGhxZJqL5f4Du7aGkjHZ8Eqgzmh10uG7gR7qOl1h+v
m0zZq4PoYhm/+34mjMKC+b71Pek6qNNRtm1lmg6hth4xBdrKxuD1MSLDIjPEFcgNBqhJzngkjs9S
NK3F9UJqECc0ywaCf/2jyzLa4ngK8o8B1tabHPdIGPn5eH2Q5A00kZu1izu9k3cW/M8MYrZad+Tm
JLeR4wjY2ngOkyEYSwXDMI/MHmGwMI9n8PCcjNq4oFdWdABHTAfjeQGa0cM/JfhoMh+xFxbk5jZ6
HlsyYujgACg5IAwwICm5Htthz1/pmmHcOQgif9a1tTgR+g694/ES4ZurYAG7PdSmkXoAIBcNKxnS
Ohi4+7AfAkLPlyIL965ymAf2oTS7J3LqZVj1kRFjdH6DWnlPGr/yCzEVWq8gfLB8PPnQgrP1vi+d
VMmO9f5j6yQeKHqSWe1RzPUoGm3ynUD8sJrHVp3i3WtooKTGl52PIVlRrtuiY8B7+j0MFn6CjAp5
Dc5a3DmhHOhDbucmWSvApH5DpalvTEYKc4U6qhOEFujetdakxz439EzkGE72XsY5HWDB3sFHgFCB
p1627zKANpJCjSW30TVynesbC4S7CEv0HJ36dyQ2lKgZGZN8BxN88FR+7qJeB9WTHMSoMLgBMKqh
cCO0YMwR8UlYw++t+K/EHPk3H8RAe6ZDQ+jB36YSqFkr+BVX5pIrhgZUKDtPGyq2tV95awP5xBWb
J5WE4PC8F6y1tyrZzDNuXaRvWnDpbXRRiOqDR+HfyAT/qZFq3uXys3MWrLYd3F6NLI899vJE03rH
lTDF+SaiSXryV0bySO1YF/Kkdnuh7PNhySKucxX5xf3eSwqZVrbj/Yf1jilzphv6J51BYh/A+Ons
t7D2A/PilTy666Rm3BB0gMf5fBSCHo8zoRZzEUuuFQmo1AYliVgO8DdlGfPKV4W4TtdemIMj8wpe
/aQ7PPkG2JwzaghHt0Ahws0iI4Q2wgw/7rx7yWQmz0LG+Rg2zuFl1Y1/lW6lcf0BDBDCBSMKQel3
vMi/G86P39BWJ5Fr77q9PRY0vYL6t8MJKBE8xTqLBEDsDhXrJ5dxRZ9HDWpFewhmPDAUCJeyxL+k
/VO+YziiqivEMSMFoPMd3mhtz2ZBLnWxi4VmNxnZr2YBQNuHjP6M+jDAMw9HX+iZDYcuHoPG06/d
6+pp0AYZPhLOnUuDqN7Nul4irog2YTiNkU5BBLciKwEsbJ+UJegZH9ezxWDs4t6eEHlBxbKjyeG9
QkIsDUmCHcxJWn1SMNiwiGwYg4zWpI/R4t96Xtf3NJPA6BXTC+LURNgsXLon3rYBCW3oGIFowUGI
V3zO1FtatK+aipU3xevGUtRqqHZ9RCDIUuQU30wxwXJ+DpmgfXh8mr9OuyE7DiTCPUfZM6e97put
PNT+9SoPi86bn+B+EDUuM33iES6lJIIepMfps+GZDKeTuGS+DgqeT2TVBLS2yfsFtHYOzWidZrU+
KI7DNJ4Xi+kBiNZ6aapKQN+6ZyLMC0FJpoBCkoQusauJniWcNyjXieiuqu2pJzNm1M53pBXIHC8d
cmxjJlHciyHOSOWtYnhjpvMdmmYUVXE2NEDNXbU+hj3koIWPvITJe3C9CdAmmeVMRx0zA2gjsHA6
IgP12NNxYApD4M/sVfp01rqk5WlgDCmwV3jQrOXVwmCvqJq8PXSBwcDxKdjwOwKEVgNg1vWB1YQf
Jo4EPty1RnLl3u1aqv/GB36FTYO5HFzoGaJH5p1j+MvFTWxHGIMRogi1LDFY9N5Z7d4ytRglxBLZ
lAZ3jtpwlXdp51dUiNIggcvXl6lvU9TjQe2WkvUdCIgcf+hQ0VMYHZ3YQWlxO/++ZcL/iQApXS4i
a8OrMjwAyyjgpu+fXvhdq//cH7Fc6E+BCeZlVqiTwYd3pLGTSrbHCRqSlGhU4cAsKnTC0eSSAyHG
D3jM9XtPGG2AHgmQLGshgIEfrMIUq6+LVzKL///d5zNIEVDwaQqduKRgTJhQpJMvarKmzG+lVDdl
LtLJO+Z6ChBMK7Ql1YwxtbWz24bn0fznVTSM560MnL82KwpKGjxOhrepLlMLZwYn4o0i2lBmCz7r
Dt5SCq4MViiXaAEjx4y535C8Ni5+bXllBG7EbNyHUGF9WI5QWNS4i0N0xf20s6aJOQ3x04zZvtxG
hMJtLZqazjEE2Ac27RSLTZGsqoE3yAvbKpEdA0JUW8XTGD/1su0jUjBr5fdgv4J1HZXTZe6vlC8B
T2hjq3xoF7+zNZLBLW0BTIrIv1HKtwVBf1jnfP0Et/sB9aytloPvTKQZGziR5rqgBmB8Tp36MJXA
v7Esh/DmfafEMPPScmJmviDXmMHKgaZ94ZbiqKQt+QJ7ujQrdcxw7iUta6CBfpMcNyUESbplwMSk
7rh+EUs5+1B0C0BQI43um40tLPmXjyovn5OEkPbq3eIGsu4bsEqJ1LTm2Z39o7vkREdAiHVSuBPH
FqZo8TGbkXN/XLbuF/GiAbzURM9NhICqKG1zYl1ZrAmILcWmoBv4WVBlvMpKlEWVs8nJT4HVgTtl
HhnHa93LI+CaQPZuqnJAp/FasXy9tZgTFyRipjizeqv/3lBfaGYl70NQr4pWQ8vqK6uWux2BIHKg
FGiZM7kG4mXOrISaDxKLSTelZKxmtCdPBfUlNNELL6riRBWu9gf/LloCPtOOHxwgM51tey1tFgNb
xtdayqj7rGPrrBbrPGix8ifJE2B2TcJO4HpiLlS1JEZ2wWvzP8o8//NWQ9qjjzwly9B5VlJ+cvBI
qH6Ww5mpwazmfGasy5HtpeQh3K5BpI9yMZxCFswMSNInL2sWvJahIq+dMPHK00Tv6WK7UyBrK5nf
eaxgOB6Mv4dT+wA3FlOOZGdc//gTvIKpNryDJpm99jEKEnLxZjyUyv0RQ/ry7w6KUYhGODDym5II
u6eNJblHfDEarcYH2gn236vheR3TyruSlTbRx1Uq6z+F/w8Oeo36hidxx4jsAxL0+ptxiqGLKO/t
BWVQUtKlg2ghzVBBZOR1+9hjW8qNPBkOTmy4t/bn8SkaBNt4HyI1H/NkZ+ohaUBuTePCJPyI3lD4
31Pw8R0AeZlq4wHXIK3RVlZO352r4JTwYjNxzf1pBGQr8m2o1PsgrnnRJ7wDJh/kdNsmawbX9ScU
okmsCf/pys5KNIvyIJaS/4psk73IBSgtUkBEMO2wr8iPJZwaEnrC0WJ/po24hFtosNJMdSd3Ox5B
Gj0dGWND0LviVz8LPSAC4Z0/sqQbNasRvy1A/qPz4iv/M7Da6jhu3vzllLJVAN5AQFoSeroq6/2/
UqQz+/LfPWTpjgu4jsbwWXodqwaXZjq4Eb5VbUGGRb4HlYZmDEYpg2l2vJEUKKOkMSa9LCzz3a/r
a5VxrjxfVK7GIjvJ+u5pwG6WQL1AluQezRdwXhhsTizmumjmrSjY0sSj8Cnk8WSrlq8akFV6GrmL
c0UWVj524Vo6kHA5eO/6GYfo/cQ2q0KLgAskbks4MlRE4k9RBCy9DURn4egU7MIDclIOCaulxDQN
FOZXwQ1L03Higaf5Uji5io6ak2waKZ/1+LGKl+7drTUGEZsl3sdXquIAoRuQcixg9AEvzVETQUPh
++036FNRPCRE5ukUDreSG6D7mV1mtkpvbfUhCF0sdTHhlKKsom5grEsTn0Od21wZSHHUBWYPvEXi
cUphBQui0ikwe1eqqlUIpDx9gDRpEOD4w7OZJXnPac95fyq1lSDIbt90FcYB6HjE41g0ZxkPnnxr
Li1yCdyQiLnumjD/nT5yurxDUEseY1hi1LRxJMUiQ5VMizuaX4xwWNU7ZSB//D/UMDzlV0QV9tFk
2GhSN2ebWSbDqNUgs9qEY5Hca1+69nUhFjcQR+3t4M3XGnlFFzoB0hlSDfk6ZJorYi2amrD2z+iz
67oQeOZGfwU40RNJWkCO3KCXqx6+Psmt8rW3qftWyJxaheBKcFkT4360p54Yr7qR/GJHDUTGIJix
ZYsjsFC6pcif1Ot368dTj85x04tayYFB93sKOvBNZk1OJu90anQj+9gmr70B2kfgYal6WxrpeEQc
De/qSXsLn8iNBGlGQ1h0gb8XeYIJEmlSjpw/2UgoiKdaoPxmrIUqnfNT7SY28gRu+mTeq7cUp3MY
ITQQb3ux1BzP4ZuRLJYtVMDDxmAuaBzJO1uFvgi3hpy9gBEKJXoiwhjSimcOpR7s3GckaLDVzkE7
AhDXkNLtAvc20tI1xwObdZ1zHaJcdduqNL7ew9vnNpZZyZsf28FqO5wiSkuIaYqk/dtTa0qyf4EL
Q1/FuPaEpt2MQrl0T5qQ5rYJDtfLY45Exr7EwAM5jPDDvDKXisHoLFmRooByUbyyZbVgUS64pSLK
3zqAfmA5Q1h7IAKqszDfyvB1yWIYsa3dqoGXjcGgm+Z99x4NyrIiO/YbmLRhFud5kiB2SNTxRajq
JM9vYQpJl5H8WnKm2l5I268almE7pyJjCk6x5XBo08qoSKkVudpv5EZEkLWbB2WPy6Nlv/y33/pK
xHnwZbtp5n9Y1nV07g/js+cnNxuRK7zWMoSV2vFB85e15jvXD9Vd4lPdt8xrgi0EorxxzC4uRmMT
ktGILeZzOgfkgsO/W7QaiskYaiRzM3i5+CZPbZJuwrjWhFH4GhRTOd+K/a4kPPoLiGwOOtp5KQYT
AEkK7I16stuQ+4UyFpHyEZsXNAVCFTV891YvB7G1xMKJAFjLTfOQob+nLlK508Zwe0I/ZFr0j0P5
+k2Ml0gj4mGOA+HU/IT/KtViHgFau3/WNCRkskRD9sI51jWIpv1ocG4fD0spnMZ2zLhXgPhDpJEv
DXz5ErEn6Y58wq4x3AYZNXbOcO4BXmcT599qVo96JpcBsZIk1vsDWPvPoFcIgRwabpRI+DVhfpR8
kAV/Svq8j/iLJOQCUxeGEA8OuA2Doh5Hd9i1Oqg/pmNg7rFSp8K3ADnOoGWBPdr0OSaECNvRSKMS
vUygjPEVEW75Gi7VOtEx3fKeYdBhL4vHbTB3HMfgx/3gbQo3ln1QG8eRjjI8SyOrZe+vBAIEMQ6U
ofaE8x2L9njjyRT18nfk9P5vi4aiwFSfyuKrRaHKCkfsS6VscuV1sSSKFOzii5ixv2CF3aCirCy2
5fQx5Z9d3ECle8Vyk2F8h8KmCZAt7x4HSwBlkKyh9h0UgETCGph68YYCOoUr1x0VTXPlYdFQ6qTl
+wBCP/b0NKKTUXaMyUtkkXwdX8Tmdcsl2KBEHV8TCAGlyHShS1yWvWsx0Sh49q9YY+UH65r8s4vU
RDCV3EJIfX/Q1kZPoLCiABqFQwYj/czDGI/jLwm6RCCyG+4+g0DvB+gXkrQ4/uXc0mhgva03UvK5
GMLldt3275n9NrdPHYCvZOPLzn+3dLU5IfCTMvIBm3fJDd+igXBJwu2NxU2HMq/vVtkcZb8Ejcia
0W8zzEDepmVZlIOSXVuVvubVPEvEzTKBTSA8hdV3SvogmuIUFDzWa+hTJn0d6p1mSr71v5gPps8B
4fhixRgykq4F9PB8/X8866R7EWiAmjjUH/Mg1o4AKi1fYaCHMKqLRTj89G71B2EXFsrXoQa+PoRW
kjTs6654a5oNQqz9Z4YwQRxCc4M8MwJ4ywnYDoW3dXqhDPl0ZmZnTbdhqDGWl43e0qyjFTxHFNGJ
gztRgDQyNIsEP8C1md93Vou8CzHC1qe0c+7o8y61F9R/r28KRzkbufjRV32r5E2bLPB9oK5lQAch
ZIJd7UJ9lh55TQyshd8alNlZ8HiF2DG+jZxfo8Eqch1vYxM+/WK5j+HNcgQqW+whRqvcBPVs9Qqj
o0XGfDw9il80hjv/aT4IyzvpW1971UmnHmwJtVimhEBFcorJaGb0v1XgPx+PjoX6Bo/eJQMbOkU/
anP0/AOc8VgxJTsC/8OQ17ssGN/qwKS5a/D7ZRLpePp7z/nSaQVDqMEYXLViSZHz/KUb2G74fuLY
MPwBpi/yYOhSzydaeYc1nbFJPlkG0BT1RttkawOwWCaV3f1Rc8Jep+3D3OQJ8/K9rmLsgMwwh8hu
5149IS0x5ch4dhe+aiLH+MUUkX/HDmHCkjXSRevPBIUanLZr9Os451sXi/5EY5tqnRj90fEAr6Wl
uC1hBZzMVsRz+TlAzU3oDYHd/TDoNW0/TVfs1z3aq6aLuAg1mrH2eX/GypngWVKHLRrYDVtwjEIC
4pL/2YPKCfc7HOjSPw4HGXiW/IFX+/mpr8v8fvlfUmcbSqxm1xETalsr90y1Wdi0I3XIMxRd39Cj
0YHn550X+rNpu4tSMyTwNAq4TIMePpP83Vr49bUCct3Fe3HLm723Op12tnQjr1Q1C+MNIOA0O4GQ
74dXWmTukKXiEUX5B8evUBh3l0IrDSG+AuP00/n5AiwIin9cdH9NF2xgGppuOoNC83r5GiGQjU5C
UmV2BB97phKJd36D3qpmxhuj9NuzCp8QnxbyH397MnkPf3DjzkFyVxzXz4veBvLOB8OwUFiSaj1F
kMT2E0O4D+QoJSWt+Y2kaa0cM/lJSSuCtzlptq8DkEL8qncj3FFbPSfkxxqwJRzuxUxobg1CBBaz
c7DUQI/QpcWnJ9WfkEmTnrfuymPz2jvC6zDZZDPpXztVipQWMUVXqTI3FRUWc/quDr7nj0IoWttJ
N34MCbiISBsu64IDkBxYLuQ0aPf3Z7kiNt/qk23yyGEGf7inSNzyGqffk9TxiugaBMHF+gy8C+VJ
4Hx5gt1/X8aXg3lQ5XoSAd6/i1d1+oAOu6cLAPXwwmuel5b84LaP88FspwSAyNk9sLgUlqFH+Qkj
5oZM/z+dFzxpESCp65SsaPK9h9UfrQuHYLI0/Re5pKvyFV7x/VGcfxAKe8EWzY5rbIKB5Lfh1toJ
fLJ3IfL/aziuyYxmkKuT+EcglwJ6a+dysK4W1mo13Z+D8w2fV9F6lRNOLxRo/i7v8PxRof+5mz0z
gvsLWBVpTcDx5cUpRxxZxJo0Lm9OodGBu0WdVMvY3VC6c+AheYohhA0dtoTNXcw4opttUOe51THd
qMeF/KqydFAEwUoY683nfA3mArVJ59991/X3k3aVP+HDMB64RBWAKbXKF3sUYzym9MT91gYX0/0h
8oqRLx6NiUPzYvxbyXKxLVvhoGq6DmGlxLg8yo4TTemG5sZDLDKjhjlYpThTgRpy7WssT2d0j2k3
4irITMM6LEX8WUXGjRM5ViZPuzn6DyM5RTbL+MHQl2eqRAoYvNjqiQn9b1R5cpI7sOnPVizjg2LV
3rO5zLhy274A1QqYFqWUgLILRSbpNTf/Fkj7hu879DHo8b3cbLTLyTcM4qiBhU8iRIh8DcAst6td
MvJXGlbnY7JzbDAKdZyZoGKArKBu5H/0pgK+hHN47mbnwgl5xDKCnxYVUL5ycfHkT3BZTB6T3q/2
K2PHu8TsiguTEwof/axsxZSK4kfXjQgC85qtPB24ScIlDx7HSVcMrcU7QCxSmIquqymET4J4p+hS
jvGL7kt2A2g5DRviba6tc2k6Dwud+kTYLH3TidOynOUcd2lf1adwjTH0zpPKn3U8tVx5ymTXjqrR
tzJx9EhTzX7C0rkQ19PSDFbX4vZPw2mAu0wDaD1G7EWrHd+yOPiO1ODojYZIlR194hFV9TdHOzTt
/sn2dMdW5x6cioS9py0iAkrY0RqGpQZlpGEx8lVBGbYW5aEH0SVgbcApAshnNVNXaHaNegSd9IAd
8ZmZvZb+6NmQvJ6zGajlvRDiNh8o0dIMv8Fv/zvuRMPONqY8dCR/v851AZLTO7QXIBd/UTSFCrGw
vtIziHhQ3j0tpzEWvjdvQJQUHJr91AbJL39fUu9rF6mu9jnSPatK0sdO6efnPUA+BoPWAjHTztt8
ooYqX/TyPcljYqPIIOQUNg4nlywn8faTytzWNWkmRyX4KCwn0SuvHuf9JG5NKk5wAuo/YdNULq5I
JXSx5koZIZ6yxdFWPhDubDn7wki7csWybD6ozVTwgGS0j+NiCl7gPkngGjWzN82U34i8Ibu45FVe
o/bfdIXM3CoONGLtqde/ciGCgGKMQmdL6ibAno3r4rXHBVvZpOq1JovLO0zsdlsIYTQ1ILCV3ozQ
TAL1Ngjg5S9D4Ns2/Z1FtK9p0Avvo/XflMX3mHCIpE8OqHQpU2afQzaF88zaiPToDSTbT6k4rbyf
gcrAj85uhLPAlzkVnYa3aezlzLDZ6e/RZWmggMADp//NEYPYbfjsqMtWkbdEbjGi7sporTdks0ow
6vUVShkDTmihe96TyPfqE2JwSHB6cWkVpjp/5FcFiHikAnYeKxO7bIpN9ZbbYvwAQphLVm9zlFbc
0YF0pDE4+BAltO5geNJYp+TZb8D1iDk92Qyh+oDirYo8P1SnxzWU6miarvlwsPwVjUCOYg9LpB0h
Fk1s3LyLkwEG8vCNR/TZ8yZ1b+iA8LPntele3u1HS4j04qNrEnOPRnrnbfTHLhHPhaV6uV/y0z6h
+RdSLYc43R21JHLjT8XZMXnWgPK32HzLiRB2iF9YcONwM2ZZgSwFvCC2zPVYlhM3l2YBO954xBSd
JjukfXwrTyrPdes/AFzBStFgAWJod+7phWSZRAG8L0FE3jxKHz2f0F6GG9HCzUrTAnwC5UQ2N5Ht
LuJcDVeW5xfDB07JUA6FL3BKxQa9lQ1R13jVtC0FdOJTFV1TvmMFu29A4zjBEW3iVT3N8xNEM8Ho
QM6NIL+woqy1q/hKQUDnoxuxAqG/UDaDgMjF0OfDupLxNggRVI1cP8aPdfqsAjxgfi2/ufQoFLFF
AKzpvGVmV1wct2GWsIS4JfYLVmQ6K6MwQRy2PpNoM3GKz0y7WWTjqHdLkwVA+H0ZC/qLbkeSnT7i
Oko/hSceADKYFY2bhpCzBOrLO3Clrp78nKVQVskND8TbepeXAJUbTsj2HVOApTS4HYli+cLafk/8
rSjedwwtQXuS1gQ3sDwpn7AonJMcaoPtdOgKXg+jNV+WBecLMLB2HDBLkvvNh7j8lvOLyBhekDiL
IKm/uuh7W+Svcune1Ct2WVoxpAM3Y3zCjbFnPmXDJjJBXnVkrqNUjE+qat3Evo6XrnaMSwcPIDM/
gFCHBO5WVAGCmwVLLrjZ9X3haOyTC7sPZRAziHnNM3jt9dIUpDdUbyiTm/Hp8AAWCDXb43cY4en7
bhKd/KX+MQum/szUdixH8Vclk4/goWU4G7ecGd2wda5E71qHiDm4Cn73rKoK8XddEHIwbgP4Op8y
VcSpIi/1lvhcWkRuAE941P5Lr+6wux8TOLOOo5qOh2d1m0uGxOdlJ3daTG7A9kqwbsC9cApbCzTE
l5N8U/lKommooSDUMMSY/4lCdOIaFhkUmZx1JxcyA9JgrKUz8/za4Khr2Eo5zmSZk3uG1AMJxTcG
9f7rZVAWf9+XUJq/75PkQeZ9kC2EMBZ4Bb0HwTtJopjYmKfs5rcU5ZTktb2TsVzeQdh4lim9UiEK
0ZA2rFNOazWLH9fH2yKDzJ5BKrp0sDXQmmnTrVtD26Le0u4vKBQjEBYwYgl0zuMMi3922BdsXTE9
oF5AhNKuVeWuZd3y1eIDwtMMqk/sD4IxcjJQQ675P3QiYxKfA9w9BsRCUeMpi+jsl7JN+DWGfsg7
Qh5a9mrnu4miMcGw9U4WewNo192PX90ngWd1gjC/jalrKBcJbTM+GpZixUL+8f537Ybjt8S6F0Pi
c5XYbmYV4U3XXRTEu/UWqJUAiL4wrgqBC/0t3HbJmIGUueWRVEFGCDjkwH8kGiFj7Rs+QCuxC57l
MytdiXQYA0UuGPvv04dKfhodbDQHRFhjeezb3dlIo3i3Ka/6xI6j6xF9Pc21gqGmE8IE8dGy4n3e
movJcA7FFSE3OSwCvQpdwDZ4HRB0CAWzfeP6HqcCxIuBbvuff2732En8JuuFjHNvaV8AOi3IdhIi
Y1DWVj4YGczS1vRYHhRkRGWLIjXjzvk6iDV2b+hqBX+lO34pQr/tcX2pAh7l14SHrbHL/eIBSnw3
Rbhx8nK0lstffKtJOs4OeRBFsmZnDSh0e7+r996e4VI0D521zTZGyhbgFqXJvf0qUdhTp+si24K4
gWYe1IyiLuXTuiKgQbLRUm2692yKjL77Tcu/lWTYLpu5w3bdFGIVYVT/v4BFUyLKa7jlYXWfxPak
wQpnpOMDzIpzvHEN4QNq0yda5Okz3JRt/GMO0zk+t+DAQu1qz52Z9zsjipupmmIiNlSwRMJNzU/p
/2i7Ju7QFwk/ryuBiEmhTGTXFyAP6WnPl7P+YG2Bt8nzQRxkQ8P9EmCrhKndKTdqN27XaEKuru+H
vOb+pBHt71ELURBVPjrs0qpOoo8lpx6WnlkNG5wKky3afIhReYWuqmrDYR/iicF7EMmMwjaHLtyp
1ix5//pLbQwS+VnKzcSHPEGxmQgnUh6R7IuDHyGiXy7qJ5GQuN9ufepF9na6PekML0tUbM8BOiL9
KqwpG2Tfl1yLP0lpNEV8IGPjUGnipj4n8ubo7K/MLnIlS3Q/0uWwOjfyWwAmOUqsmEoAvXYARABg
cBEzMiPHFX5djHhqbG3sB8tH36gqvK6gqRoZ1Pj9d7etfQbbBajuLuw8OkOng6t6XflScyoE/J9p
wepE9qVWijGhgVQlOAbwOm3GRCU5sh4Roml8mIyDPVgxduxIg90k6wSMY3zVn1Uveh+QdDgcT9f1
xCNyMJguWTykjDXtPk28P2WhwsYNRXTUahRsG+9DV9oGDsxIWS371tZkgjT3QzaTvN7vqKDon8AK
DQ5Nf35586Qu83cSt/4oCYnLnnE/EFy3csvFZFdkdh4M444iuviB510RvULjN0JdQa1ku4r3S8W4
jRkgtf3lmqJfh3sgFC0AtKEuIH0YAKC5r9eX/dKcLtiq0XOYkogCXRnpcaZtjv8KJiAMtKiD/ToC
BMvlKdCa/C/FV1mKY3HchdV+CnU7Zbj1fT/I822vp2AP5B5ruYcmlDA0UpphdGXevnvLnuK9ChCi
ZhDC/qUgQIhaXHd8LS3O5gE/DqggsZKwX69E9YM31afUbKbBtK7Qbm0puOr231ZAFFtQ/jGT7yrX
EOFtbeR9UjlGQrqEsEHsHh0paV7ujh5wvrxwzH536T6FWuc9YCwvDruTh0hALLVexZ0I2AkwmDUu
+YtJwbtGIjmldhgnpyQIHmaOokb5LUF/mt/QPm310b3fwro7Wmdv3xsHNWp92c0LPSklItdIkzVX
vWqXbegfW0LCppQ1GzbepaNa+i9tDwW+pyk3OEGfLg4DjXGm/HqPdvuzt2YscOxlhEQrFUmAgRro
DB8quuUR2jskVuylxt5e+GvI5Csk5daZ/lhhFhKrixXqq15YBNqMkasc7Fnn3v8QdcHdgajEn2m8
fuGntAt7wWFJtVKO8VzXMye2EYjYyFINXgs46rv9b1WZcPhcWAKmZiNWRzwqL4AS9DLlAg4I8bZ4
AziRTob8Vh4mvhj5L5tzgPLUmd+sQKKY8kHLmZZRoH+TDuHmEzvwSJAyqNNj/Daionhp6A0HDRAe
ghb1hAizntBm/aKBd8i3j51HU4l3tkOSRGfDYPYTptNQM0f7xWeqZz5ioNs8hWrsdX3b84NYaznU
UQuKmNxSSAt03t6X9aLT73DllAO97iWrRKkx1ze/VTfcU4OdOuiCbsKDU9W/K4DaUmPXYmIhoq63
tSichyoOZ3sk45vT/3GBRuUlxW9Rskq6LHZ5sjyOacM9WmvvgFaLM8h5hI7tVZpmQ6DvoK1Y2z02
P+ZjqrXs2b2twHgnKvkqWru1B1FrO/y/zwYCEmapHNF1Eqwjhk6+d4yl/SCoZbwGrbTwA9SlZYZ3
AIe7tgPYRWdLEBNOxjqSObpIqBNxAERSx7Zte3uRkQ3zx2H6soG8KnmlNjmQkd7w//qB26rPzV/S
XyA5vDOvcmvqgvasEuHBjoLhJZ3hJ2yt+8YUtMk4pB9Nhg5enJ3FMrWKc5G+8cOKNd/cQHdZRSm6
Bu/AQCx/U0crCR7MP1YXjV7rabRyA226f/13uqA09vt+tVftGwM69efmLw5GsgnUZixWiorRSV0e
Px3uGY6LnR598Rk6Pj1lAqfumR0Chxz6guW4rVyE4Mq+ldeYraYbWXsl//iqAkULxmbZga+eu/jY
Hj2COGu/nvsg6XTLW9KvgaXbMZxNy5wt/xmJcXz0lkGOp4vnQ8H+JG4jkAB9169p5LKshfeVP86I
q2C7bTWFlwJjwUDzR1Wdjp5iqeAP9G3SOqZs9AIAcKYbchCtPAJ/2p2/iBTf83Es9EJmKY9hwugE
h+IhJYfBBJLckKFlZ3wBM3caYmsPujZRjHOFfhfEc0D/HYDsUG1G8IvajUk2CNp7belSxeE4ocAf
BCf2herEN6saxZ62UvN1TQMp+OrEOUrNYjnCQrxGCeiQYfgG9mtb/JIT2N9IDJ/UCQeMbcuVlH2t
i/Zicjjwkv5tVJiZEoWiCKYCPlvVhmiqSpEI+uK8UUoDI7k8F8y6rU+zKXKVYGjl0B9sqrstLdgy
PjiUzqSf2cPCs2Od5uAZfT3wcB8xe/7e+XN5Tcq4uXrseTGVz7cBMUTSyJydVG+zS5e+pJW6Zbjl
Saq+hJOw/Jh5Dk3eIcLwbjUR3jc9Rk7zDhFSGOz3qvvohiy3qG15o/EhGQBcwv7wtKcK1TZB0Nf1
SfFpb97SKm9OdiWSzmAL22hdzoVkX0gIplc7rlNiqUNxw8UV4DfqxIjG8je+kZ52g/zFUxVIqRPv
Vu/ElzpWGudX7P97cuEgdKDNA0xmd6+iDa0HzgQY+OnscDEJIxbaYI5Fd7YYsmO+8/enGMEKNCd+
FzjxUnYm3vuNDP8ubdDBec1x6na6cFf13/e0z0r+Lnc3ctWqj/3KbleMBLxVYLuEDCf3v582xJc9
wnehXq/NuNLpQ8cFpr+ix+iBr6P/3th1MxwkWTUNMMKDQF+euE548Fv8a9CWuddUcUIWDw4HLbIV
E5iwFgUqFhTZJkyvtDYRBtpD+8oY4D80t8JrNyQPspZ0lWTBTQdc4YHlc/iWXDFqsOZDlM/2uG2z
Csk9c8jfiAldl9Y8r9mkroeH8EjhihIbAO0p/jnmorrfsBZ3gAS9finjrsEmt90ZkzhehD/KEX3E
LlVZ2Tca1ea0cs0n2kr9AOoMauap5xtUsFahQ3xf3bt+BLvfYYxBUYYoiR/Ts/a0nMj2sPM3yb9x
e1V+Rh3KiVJKZ30bwFmFvC63AdpywgDZXUNrcXE6XbCiJYRym41I15tmgVqJPfdt/LY1uPuVlpAy
mkpIiyHyhOxK0FElwJZKWarw1gljT4BejBKESUPMShbm36Rmxw0uYXsMKqeOquKuvKjzwRLBR82C
xpG9VSCfrPw+m1AbvLNrOMt0XplaluRhUK5SYbeq8TCgId30TqYkkEWpxYR/tNVT3V5DOqPBmxuX
v6CBbxskxPCA5M1uxVppMnl3Y+O5wJjQqKpd02Vn/3YNhOqb2uiBnkr++fJHPf5MRyvLZ5S7uhT4
h9RI3uaqp+gBO3KNLMpm+yDDR7AZElOo72kek/r3gDBNsN3pVY2+GsFkpEe3lOUz3RCWfR0AStyQ
WpdO9zNZc4H44xVX03chJVIA04MatgILzoNi3H10Q516QpebnGkX0yhFgwwe8/C/Nbnn8v1omYjn
bC5VSD52zz9zcocmvObxAaKaXLdbdlm2YnN3OBtI3NsinfGgEKGh/Gtbp/cp+GTrEEWuu1O1d2h2
ju2o4JOpn5zeuvUMPmTnBePcSqA0/tmm2TnaIUwVmrjlFZua4YBsHY6LgJ0n6d9LqV/og/YeTNy+
Qf50gYKFGCxlEG2lcoeysB5XGUWztl1sh7paWJVvwjtCZetns0ibNPN8ITz9WWZX666lzQF0FfAg
4jOI9x+22uu7p+uM1IoSddUYSxfuQiTn/oN5asQTstxeM0W0k1Rn4aTLKwLfc4NGD516sumUlkLO
9bzFFBUBS/2WpP36+8jTPqfohjuIgs9VDCt9A6XP5ElPdB73KrgZJR6L/1J8RBZRx5b9H7lzGZPB
XrU3HlpeKYgqy2gL2vu+TEEN+CzJ1JBEeBHYGYcyWph6A+SpqmjfFDULovlIJrcZXJzdq48EjA3o
ORT1hdiT6j5fEYgPc4j7/u1SLiCQ2ekWqMc8UaOF4+f1oBks3AuNoEEPfxO+SkQ9klUQKzLO3YxW
an/QOiU0epCZ8tbng9zFw0YLncdc+zU4HfVLurHLaUB4hh6suSPgg4BEm3cBXaK90lXsvVS5eUln
n/qrgIEDnLW/g8k+RahK0cmRcaSCd7S/2Z03ALeYAlzYiklKnYXH/1OdKt+xmSjiwxCEvRnXYLgb
8V5evKXfhFvKhZxEHwPQhiKuiRI6dwdeOFSWIXSeHuZuFRUcGEz78gaqaStziukJ+zaUJFMWBThX
yYY2tWXEZQ+TE1BiyQ+hafYuQMkblzJUGMvawctONZvCP2MkmteKJcuU59Kk3bZNpyYPXuS95wdq
kod5tSOXJ//LOmM4rt++LPrYMUtnRAl215gTNbfl8fgSZYuUQIPhdHtRRzPSKUbFq7gRpCUDnlDH
8jVGisZiAz6LBm2UbpHoFo/g/pR+2dk98aI9XReTXuWA3YexJlYU7rArOUhAcjrgZkcGE6IcMd++
dfeID4M2fvodzH7M9wyC9HL14T+6hMIVT/Vc6sNAgP0MCGQycPewgFQePyleSz+8b7oPYewxEWS4
vo0nckkFsKHzaJ+fa4bdXcqw5NUPP1Cg8HCEW1CVd16u8gtsOe6pHpUqSQ9HX3QFbisS5f78Gcbn
dGT1MV+fS9X7hUXu19fQ7ddus2gvsSDkqc9qgLUINbR9zHuBBuC7F7wyoNAKQH0j/ELf15ndYAKZ
+cYuFNUDtFid75yccZGwFyMb4EpOft9gCDEJe+1oWQ4rn7YYUNh5esp2kWK1ezg0GpOTJ813IDc3
Ur7ECYvSrQQjtV6So9gIuTHBzeflWRlhP4hxXq81qyKEIlo7odcv3TPnI1K1ygHFXgixyy7BI+TJ
5ctTFTGIKWIswRTuLdrKek8mFvj61+/gGpZyIvNg5L/1iTvzDYAIJLeBQephPMQUfR7QDgvHU/Hw
S1WE9YrvKUib2vl4WhiPPDSaQmFQ4vYL5eJMuitNjuHVoOCc8Zr1ZDhixuqEUcBqymBdpVpqQoax
7/sZ73lGX60Ue1aPpnpn83me38H5Nz7byNbD8L+jMY6G5S0LC1Pl4l3LKsHtSUc+UAToLy+FVA2t
YJ8UMaR0oUSQidthObEx6V40oC61BBeX5mNyQM708fnL0do9F8Bf/6iBGlga/6yMdr3FLEEYJTEU
TA7Jchq75Qo1MepsgyakTxWL23osKvzjvtplsuxxYlI+W1zgRxGAj8gl2i+y80Z7JwEjQK5CUjhx
8Gx5uL/hvgZLu/EMwxZHOe3ODgD8m3SSDzhRoS4gBJi2gqQ9mLKAaFRM0Pb5gDWzlnssaNM1m4Ou
HG9KUOwQnsYwFLwgmLH0lQRACzUKMwc0Q/T/J0dYIzkgtTV3+WL+i1K5fgY/EUIlekZbsCGku6HA
W7LmF5Cen9uU0LfAOk1GYiZTJk/FlBriN4MBYO2gUzGzWuM+HCJ6VTwLhNFfisdLbpKD/bQsq8Jb
CS7Jh/KdgqpaOMUtHBk/sov75B/v6fY7rv3pC0QkCfPKew/4I8yBh8GvOx+Dqc93dz2Lk/of8sG6
nRmPJ+T/dmyhHZVP7HWsSiLolhHkQ36hxppuAc+CT06RUgMvqX0lbFHhk8KmQvSMc6Y4DTEPSWu7
oP/NHwbhnDAucZe2rTrome6onaTflDe0hs4KPxFtUK/eKH6KZPKPgmRxfsT7kHA5YnoBWbXZ+SSE
msJgKZWj+gtQjEnUSKbl+t18YCyLEqWmaIgbgYRBO06plL10nbNiqOVeueg4tliZ+Hb2KKPv5PoR
XvBXv8Q3BxdaKsme2FHNMsxdGoWBHvRQtPexfJFHy0q9sN5/6n44+H1lcK+aEaUmrNHOArokU82+
X42lECiUQxW/HF7Sx9KL/q3kLeyjy/g3M20qOdY0yDSH7TvB7YD7TyJBNgQVVySGk6BMtY1m4llE
aCHpBvivGiSm2WhRoXr/ll5Ae+58wNsngDrWygsYNyt7MsqcABGodum55pYeZALGulZNu+idAHE2
QKjtnCxvBjSjMV4BvKCEX65tx+rJ8A4IZSIocPfrJKBGXhCkAItdRjzoADxJFKJXqZEqMtmRVH/J
7FshUIDTix0BO2itqWugc49uveoO6j4/juf+xMiFlsrz8e0ROnbgnHiZMBpYVZRaBynPBsNfXZxo
8IuiqG4UA2Q54w4EhayrpajkqrGQDjxWMJRoKLHOH+hAATmp66+8bflGSdg7c+ItNRGoMd1kRfLV
JRlMfiFTwjFzzAVDR6ReYYxqb4diVvUcbl7WBGq8BM9dljiMlmkNqWZJwNpPkKWrjd7/5LwMf2hf
j4i1EUA0+Wk+r+ilOkze9dgsldsGgB5GHzayswmDquIrPPZcL1Voog/SpAbkFA+sDUJjwN62tGT9
fuS+GNVpbt5yh1sqho2M+ayt7CB+MO1+6OTcluhDgDfvjdukUoJF/PSP9HPLPMm38liihAh9Dx9U
/Fs2Dd8WnLmoV8PAViD3IKEbXSeQaynHDMFh3wDSScGS8yrTawbokpmrCbKKaB5kNd3XLfj7KPfY
gYTPV96xSlt2CX/PuzTgMv4yI0/Ee7azg43VdJxo5CWn0ksnptP8nok7msC9Es0RNJm9Epv2LpuA
RSEH2W14jqi2p62L3CQM1kxllqN5rqWKqBbO+5nC2TnObhO01FR0sG094P8G4PiaO/Ru44iQjZOU
zRe740+YPqhJ3hiAS3X88i50DqJgohnlL9zjjLMDWB/2PafSc6lUASOmTbKsPARjMlnqKHb9jSMg
vjE1ifsa8xQki5vEP+fA16Zr2g/w3PM/JATqa/3GSFln9JN0Kuc22FgysXvbCVp4RulpFwDc3KI2
VS7EUkv+x53l/u6Tqgheur2isJfzphuuO6GnoZRKJ1jSVy9oHwoF/ecZLmHz8l8JIBnXBpbZGwH2
cNNyMSlTqBvgLcuRQ1uNyKj66XNDtC9NStuJhpU5pfbLSunZCoZjIITOlRAqHMyHngxYxyqSjwK2
l7pgfYMQjBa2vgkDuWsZter90soXzUr5j5rtqBzdSqmLOlvJrW2gNncAwAZMLHoxz6jEzjoByW9R
+jTJhAjwSWuSvSYt6hwoRQF5RkhTJk05tJ78h3UET0VhS8YaLxnfUMRA6no9Nnrfr0FsJuG3vLK1
El7mEaktJy4P8hc2fYuSl4poHevD+y71AhOpqtBKwheL2FmI2sp8lzaCEastF0QctT1I9wmzY2G0
FD2ozpplKQjMqc4lGKE84r3TJ1HKHmmsYpQKozxCD0/3cWeLF4WOq+XSw8TvD5zes//PLYnm3TJK
yHDCx3hwgl6YBh3h8kIBl/2SIiGsjJM5b5NlAfc0TR2OMHnqBApYV3bdPO0s8sEwCif0hZrF/93g
Yf5BUQ8B6+kUL0fioL9E7POdGJ2tXLBZCwYRZfDeO+FMTTEO4ytXWdy5NEKm5ZIWG/oRIY4Ku2CF
0lXvFedM1KQ1U1+KOnhaB5CJsCOjD+2lierDQmHHWhUpGqz6fySUikTetlDXv+PiotMVd6mQmIAe
bBQzhhri9+KqnFfuEUK21eQYjSm9lfHYpmgYAhU0YUPZF8sMAQrpLmhkkuUiL6iyxwORs9T6PqGL
bTFzNVLpMQoBLjK3aW/0IktKHI4YxVIjdgrTJf+soHG5jLcc0rk64BiP1Hh8ILy95Lb+v3L8c5aC
eWaEysO84T8BqaUQ8NhTbgIuBQ+mwoiZ4hj2pkV1N1SKRBl/GVMs6cO+ADEBneiCNSZetAho9rr9
kXYXiwLM5hLezPp9ZVRnz+qeN2xYOCcFCKRJQuGN8gRulcbCGKC+q0Fj8X9Hmy2ULSgNhJn9BHvB
xTr8YjCEQ2CSS1gWqBNUy9WEzGAMS8XT9lW6vRJQpRSQ9W+p+JTbEEVt9VltLZtFPHsGeOXx3SvJ
c/vkC//RzHp54vKfyLeUKxyASmFsCeexMePgNsmCdsG0QvUE/0EcK30iy/MVdCYDl4PKMOjIB1MQ
V4eXvAl3be210ZUeq6Fs7SqjTBy6phUT6NFK/rSETW0qI2F1YHbaAmY9KAc1mQwjzapI1WVltwL8
Zkz4NogQmWXpDWEjylhkDla1bSUenlE2MP1t9oQ/jVJc5DaTKJiQhe3Q8dj6FK6tYIJHrjZ4ZBzQ
1wEDxOFfUqVoIEMOy80rZ4bE4V1wT2Uw5U8gFJchhFvoRBXyvADE21csS3mDyf24KITPqzdTkYq6
+I/obYlKQP40WE+QZF4cVsRx7uS2uokWgp7Dxl3/0yXiGMKVg5BVwq6uoqTMlTjxrrfZH11c2Ppx
EEratlloaW6RYr9k5WADY3xmgo9OOvjwnNkf+MIyUpywzu/ub4SyQitle6WtHNB/x/4uyx0EPYRl
pFeqvaai/xYWJFZOLSlFvZh8pc7A+YF5sbhXjJtx5LRR3ktMKIH/960YbBXjx79aYpJ8Yxk2EE4z
Ckgi22VjA9soTyIpXiSJEP0fxL3j6kuAUagyqK/snVFKUQze7OjakyxEIpe96QuLTG7P0oPg4WF1
LinfHj+j5dPybDL4dqWjC/PBLxTZRr4+oFpvA5GvnSyC6XPn8GHVRIxezSOyaDeCn+qDO4dwlEhp
LMBiPP3BILToKzqHaQx6ucvANhZM3tErkgD8kIIEmpGw1x6oN0QF8PyCtNUstJ6ig2VIO1PN62B3
MyrRSMyEoUEwLGcI5y2BAq71MrVrCixXdaNEwT2aO0lzUMtk/xRMzEGJjsFUkwAyI1DlwuUkMztO
2RTxuCdhqPemnPqAT0alXxfliXQW1dcyW/efoOT/rUPPdS+nf7HWmmYV0DxJ21zD35ShcJ9NENP5
mzJhqlcRrxeCxmTLg3buD8iBbas/4JoZQ5HgnqivZA9IyfRmtgeuxpqH8my9PeGjsAldXOGsshE2
9dLri3P4u467tR8gD/cPdjppO4+/HPh37/3Tu9TnFZUqxnmi/zR0WdlLKYLdqP8un9KZ3ab8Jh4I
pifBtOXo/j/NfTWj9efhiJa+WFxyDREsrKr6O6EKgUdWlDOFMG4BwjNwHbSJxaGvjh3EyR4MNsGu
7HesJMdBCq+Fm2tBSrJ9lG4rg7KAPymLeCLv4agWW8HZTYGudD6F0NKvBE4t0LcK9qmXKtwcbIjd
PlW8xHS1iBUDWxELQ2ifRAnzNARW/vwoW/ny1bQgkRIzmFV3SDWjucUkTLN+AZuArgTYsLyZMzvM
wvJHiUvAeFifQy2Te6lKEdEH30iT8gOHEshVn28iuxLxl5NQ7T06BNV6npCdn8k0pjjwTWWIsfrY
u5gjwGWDIU5GRGDBPngLrYLSrslRqpIpnlFe5htsy3xzNz7CKA8aN4Nqwa6eyJ0yKBItCHc3l4Qk
yxISaSXOcuwovstZSju45FytSmE2CQgPy+MAsMY6V7GrIR4wXcmJdr/xkwdQvWdVKPQIIj2e76AZ
sAoin9I+rPbNtCBqIYDVoOfi4g/lQ5yarEWyTdBLYDeYyAkR5g6A2GRjMjZt30R1Eu0LcDX6gp0l
jznhItEAamA0BbIo3tjmrSP3+hVKS8RiyQHMJn8RbGLiRhTFLRrWG60GGbAkX7ky4uduJXr5H2Qw
YfYCuhV9LSrwTXgJPSxSAorNzjQvR18YkMjI0BE1Ms9k0fQEzDXepJCxvl0K33expnHRwYRqKmC3
9cVI1w7A/qxmRxZcCGnLJSmTpAPIsGSGZPDLI7QkJibsEu31/2ZuLAHur1+jUtAfFYTyb7WgYJBD
Clvohn3E3/bn1aejeZqItVWdDokcvwMxk6sNZW5kc3RyZWFtDWVuZG9iag0yMzQgMCBvYmoNPDwg
DS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvRzhkIC9HOGUgL0c4ZiAvRzhjIF0g
DT4+IA1lbmRvYmoNMjM1IDAgb2JqDTw8IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBb
IDEgL0c3OSAvRzdhIF0gDT4+IA1lbmRvYmoNMjM2IDAgb2JqDTw8IA0vVHlwZSAvRW5jb2Rpbmcg
DS9EaWZmZXJlbmNlcyBbIDEgL0c4YyAvRzhkIC9HOGUgL0c4ZiAvRzIwIC9HOTAgXSANPj4gDWVu
ZG9iag0yMzcgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvRzc5
IC9HN2EgXSANPj4gDWVuZG9iag0yMzggMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZl
cmVuY2VzIFsgMSAvYnVsbGV0IC9zcGFjZSBdIA0+PiANZW5kb2JqDTIzOSAwIG9iag08PCAvRmls
dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIxOCA+PiANc3RyZWFtDQpx2cFaL8cm0M4ly+kqEdBU
NemFjQLGUX0ZkI7t1liaXncyjZ1iTpFpm6ejnMAeCAP545hYEjMtFPDgrl3Ek5qzgFxjjbVNxQZ6
q4TOG8VYKJbUf64xA0tRaTDxjcWW6PmB49LkbiCMyt0bnX02ozMzQCTYn2lccuGoG2ltMzWSwcHd
tGa6frADFe9itKfVdKeSxU9oQLLsOncfIioGKshZaokY+E7WnIJyP1a5qFgkXPVMwF3dkYVjDUtN
L3pwd57ojQYop3n68iHSRpsQ3QyhHXMm9z6fnkK5Ww1lbmRzdHJlYW0NZW5kb2JqDTI0MCAwIG9i
ag08PCANL1R5cGUgL0VuY29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxIC9HZTAgXSANPj4gDWVuZG9i
ag0yNDEgMCBvYmoNPDwgDS9Db3VudCA0NSANL0ZpcnN0IDI0MiAwIFIgDS9MYXN0IDI0MyAwIFIg
DT4+IA1lbmRvYmoNMjQyIDAgb2JqDTw8IA0vVGl0bGUgKJnjrreCmIlBJlfiXCj6I996PPyr1HtS
deNHo6wZeikNL0Rlc3QgWyAxMDYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjQxIDAgUiANL05leHQg
MjY1IDAgUiANPj4gDWVuZG9iag0yNDMgMCBvYmoNPDwgDS9UaXRsZSAo++VpRBoA7RKMLlZAks+R
Zc3t+Ls75zWtYSkNL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjQxIDAgUiANL1By
ZXYgMjQ0IDAgUiANL0ZpcnN0IDI0NSAwIFIgDS9MYXN0IDI0NiAwIFIgDS9Db3VudCAyMCANPj4g
DWVuZG9iag0yNDQgMCBvYmoNPDwgDS9UaXRsZSAoyRURTz+aUvUAjeacKQ0vRGVzdCBbIDEwNiAw
IFIgL0ZpdEIgXSANL1BhcmVudCAyNDEgMCBSIA0vUHJldiAyNjUgMCBSIA0vTmV4dCAyNDMgMCBS
IA0vRmlyc3QgMjY2IDAgUiANL0xhc3QgMjY3IDAgUiANL0NvdW50IDIxIA0+PiANZW5kb2JqDTI0
NSAwIG9iag08PCANL1RpdGxlICh+MazOG6JNjxFJUIWlIWXjwikNL0Rlc3QgWyAxNTggMCBSIC9G
aXRCIF0gDS9QYXJlbnQgMjQzIDAgUiANL05leHQgMjUyIDAgUiANL0ZpcnN0IDI1OCAwIFIgDS9M
YXN0IDI1OSAwIFIgDS9Db3VudCA3IA0+PiANZW5kb2JqDTI0NiAwIG9iag08PCANL1RpdGxlICiW
0EEna1uAzan8HBL++9FPeIL04ntjyV6KGt2g6TxoOv7M5mAlQrFNKQ0vRGVzdCBbIDE3MiAwIFIg
L0ZpdEIgXSANL1BhcmVudCAyNDMgMCBSIA0vUHJldiAyNDcgMCBSIA0vRmlyc3QgMjQ4IDAgUiAN
L0xhc3QgMjQ5IDAgUiANL0NvdW50IDQgDT4+IA1lbmRvYmoNMjQ3IDAgb2JqDTw8IA0vVGl0bGUg
KIisWmD04n2EDifuScCqLhh0llYnvqNcXINIzoa9O60HPgvFvWg/lSNcKPwpDS9EZXN0IFsgMTY5
IDAgUiAvRml0QiBdIA0vUGFyZW50IDI0MyAwIFIgDS9QcmV2IDI1MiAwIFIgDS9OZXh0IDI0NiAw
IFIgDS9GaXJzdCAyNTMgMCBSIA0vTGFzdCAyNTQgMCBSIA0vQ291bnQgMyANPj4gDWVuZG9iag0y
NDggMCBvYmoNPDwgDS9UaXRsZSAoaMnWu3w62sK9JT6KnGCcylxu5/C+McNXoiwcsUf96CkNL0Rl
c3QgWyAxNzIgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjQ2IDAgUiANL05leHQgMjUxIDAgUiANPj4g
DWVuZG9iag0yNDkgMCBvYmoNPDwgDS9UaXRsZSAo+G7FQtvGGS5/us1QtlqbRj98nvqTLpF9h4CM
cXKs+/BOULUwKQ0vRGVzdCBbIDE3MiAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNDYgMCBSIA0vUHJl
diAyNTAgMCBSIA0+PiANZW5kb2JqDTI1MCAwIG9iag08PCANL1RpdGxlICjSYNS7iYAVuGaYAEDl
sKWHjMTHujWOCxpZ3wZsKQ0vRGVzdCBbIDE3MiAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNDYgMCBS
IA0vUHJldiAyNTEgMCBSIA0vTmV4dCAyNDkgMCBSIA0+PiANZW5kb2JqDTI1MSAwIG9iag08PCAN
L1RpdGxlICg2k3pCRwgvJWfcoT30G9r0dP0QxLTRlvxcbrWwnnElWY4pDS9EZXN0IFsgMTcyIDAg
UiAvRml0QiBdIA0vUGFyZW50IDI0NiAwIFIgDS9QcmV2IDI0OCAwIFIgDS9OZXh0IDI1MCAwIFIg
DT4+IA1lbmRvYmoNMjUyIDAgb2JqDTw8IA0vVGl0bGUgKEf+B+aCQ7q2/+/e/r9oBP95vTXoxNPF
TIx+5SkNL0Rlc3QgWyAxNjYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjQzIDAgUiANL1ByZXYgMjQ1
IDAgUiANL05leHQgMjQ3IDAgUiANL0ZpcnN0IDI1NiAwIFIgDS9MYXN0IDI1NyAwIFIgDS9Db3Vu
dCAyIA0+PiANZW5kb2JqDTI1MyAwIG9iag08PCANL1RpdGxlICidbMttcNeJiA+Y+GXemXyOMmGf
iLwcwKUpDS9EZXN0IFsgMTY5IDAgUiAvRml0QiBdIA0vUGFyZW50IDI0NyAwIFIgDS9OZXh0IDI1
NSAwIFIgDT4+IA1lbmRvYmoNMjU0IDAgb2JqDTw8IA0vVGl0bGUgKMczMC1untP2o/F++IEQeSMF
u+ZgIH/hsPXwmwvW408Pcpnj/ABQpSkNL0Rlc3QgWyAxNjkgMCBSIC9GaXRCIF0gDS9QYXJlbnQg
MjQ3IDAgUiANL1ByZXYgMjU1IDAgUiANPj4gDWVuZG9iag0yNTUgMCBvYmoNPDwgDS9UaXRsZSAo
1diApkOdwtLOVGC6gG9murSWzCQld2jWzctcXGDphRkpDS9EZXN0IFsgMTY5IDAgUiAvRml0QiBd
IA0vUGFyZW50IDI0NyAwIFIgDS9QcmV2IDI1MyAwIFIgDS9OZXh0IDI1NCAwIFIgDT4+IA1lbmRv
YmoNMjU2IDAgb2JqDTw8IA0vVGl0bGUgKPLX2jaR6upmeD6e5cAtN8vzzDAb7dNOfhMpDS9EZXN0
IFsgMTY2IDAgUiAvRml0QiBdIA0vUGFyZW50IDI1MiAwIFIgDS9OZXh0IDI1NyAwIFIgDT4+IA1l
bmRvYmoNMjU3IDAgb2JqDTw8IA0vVGl0bGUgKP7+2ZliGaLvErChr3+nEkY8qK3qaiWFmMGCMiKX
VjXeFikNL0Rlc3QgWyAxNjYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjUyIDAgUiANL1ByZXYgMjU2
IDAgUiANPj4gDWVuZG9iag0yNTggMCBvYmoNPDwgDS9UaXRsZSAoQJl/Az1PRvX6r3FlMWSgyqxm
npApDS9EZXN0IFsgMTU4IDAgUiAvRml0QiBdIA0vUGFyZW50IDI0NSAwIFIgDS9OZXh0IDI2NCAw
IFIgDT4+IA1lbmRvYmoNMjU5IDAgb2JqDTw8IA0vVGl0bGUgKGovS4gUEVm0d3Dd6VwolcZy3LjA
XChIMwMPrvJvoyRoz2LQ94nak6TCrlqtx7IAUTMpDS9EZXN0IFsgMTY2IDAgUiAvRml0QiBdIA0v
UGFyZW50IDI0NSAwIFIgDS9QcmV2IDI2MCAwIFIgDT4+IA1lbmRvYmoNMjYwIDAgb2JqDTw8IA0v
VGl0bGUgKPVFwsL2bNEeAvFG2oDfeVj+fr4zMiwCocOtOCd3JgfcjeNylQApDS9EZXN0IFsgMTY2
IDAgUiAvRml0QiBdIA0vUGFyZW50IDI0NSAwIFIgDS9QcmV2IDI2MSAwIFIgDS9OZXh0IDI1OSAw
IFIgDT4+IA1lbmRvYmoNMjYxIDAgb2JqDTw8IA0vVGl0bGUgKM6VyRvzG0ozWToIk+Xo4M3yMtwr
h4lOhWZccrTqU7Oh4UeVeikNL0Rlc3QgWyAxNjYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjQ1IDAg
UiANL1ByZXYgMjYyIDAgUiANL05leHQgMjYwIDAgUiANPj4gDWVuZG9iag0yNjIgMCBvYmoNPDwg
DS9UaXRsZSAotpMDwuiIIPtt3JviserAKt2sN/Jyjgnh/wid5i6qLWz+NoKiKQ0vRGVzdCBbIDE2
MyAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNDUgMCBSIA0vUHJldiAyNjMgMCBSIA0vTmV4dCAyNjEg
MCBSIA0+PiANZW5kb2JqDTI2MyAwIG9iag08PCANL1RpdGxlIChUtT1SD1/HaUbdXCgOC1HGpfZi
zb7CnwjrB+hAdVMpDS9EZXN0IFsgMTYzIDAgUiAvRml0QiBdIA0vUGFyZW50IDI0NSAwIFIgDS9Q
cmV2IDI2NCAwIFIgDS9OZXh0IDI2MiAwIFIgDT4+IA1lbmRvYmoNMjY0IDAgb2JqDTw8IA0vVGl0
bGUgKKy9jnn3xUQyLquep2kJV4KneiEIECSa6ddSNykNL0Rlc3QgWyAxNjMgMCBSIC9GaXRCIF0g
DS9QYXJlbnQgMjQ1IDAgUiANL1ByZXYgMjU4IDAgUiANL05leHQgMjYzIDAgUiANPj4gDWVuZG9i
ag0yNjUgMCBvYmoNPDwgDS9UaXRsZSAozkOGFZ15piG8LFCxKj0Qas9WqDCIw2m0AhUpDS9EZXN0
IFsgMTA2IDAgUiAvRml0QiBdIA0vUGFyZW50IDI0MSAwIFIgDS9QcmV2IDI0MiAwIFIgDS9OZXh0
IDI0NCAwIFIgDT4+IA1lbmRvYmoNMjY2IDAgb2JqDTw8IA0vVGl0bGUgKAYbdusXHiZz8ikNL0Rl
c3QgWyAxMDYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjQ0IDAgUiANL05leHQgMjc0IDAgUiANPj4g
DWVuZG9iag0yNjcgMCBvYmoNPDwgDS9UaXRsZSAoSUE8yW4iYpPRL6cwcDmkKQ0vRGVzdCBbIDE0
OSAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNDQgMCBSIA0vUHJldiAyNjggMCBSIA0vRmlyc3QgMjY5
IDAgUiANL0xhc3QgMjcwIDAgUiANL0NvdW50IDUgDT4+IA1lbmRvYmoNMjY4IDAgb2JqDTw8IA0v
VGl0bGUgKMuNOo4BrzVBXX7d2ui1ujcfSV4cj2baBX6djfXwpCONKQ0vRGVzdCBbIDE0MCAwIFIg
L0ZpdEIgXSANL1BhcmVudCAyNDQgMCBSIA0vUHJldiAyNzQgMCBSIA0vTmV4dCAyNjcgMCBSIA0v
Rmlyc3QgMjc1IDAgUiANL0xhc3QgMjc2IDAgUiANL0NvdW50IDEwIA0+PiANZW5kb2JqDTI2OSAw
IG9iag08PCANL1RpdGxlICiot5EvTikNL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0gDS9QYXJlbnQg
MjY3IDAgUiANL05leHQgMjczIDAgUiANPj4gDWVuZG9iag0yNzAgMCBvYmoNPDwgDS9UaXRsZSAo
olxyeZ7+AOFdNtMpDS9EZXN0IFsgMTUyIDAgUiAvRml0QiBdIA0vUGFyZW50IDI2NyAwIFIgDS9Q
cmV2IDI3MSAwIFIgDT4+IA1lbmRvYmoNMjcxIDAgb2JqDTw8IA0vVGl0bGUgKLAXeUDX8nvYZjQQ
NMrC5jmhZDTUKQ0vRGVzdCBbIDE1MiAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNjcgMCBSIA0vUHJl
diAyNzIgMCBSIA0vTmV4dCAyNzAgMCBSIA0+PiANZW5kb2JqDTI3MiAwIG9iag08PCANL1RpdGxl
ICh2sckdObr5I9C9gWDycRrguE9HvCkNL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0gDS9QYXJlbnQg
MjY3IDAgUiANL1ByZXYgMjczIDAgUiANL05leHQgMjcxIDAgUiANPj4gDWVuZG9iag0yNzMgMCBv
YmoNPDwgDS9UaXRsZSAo7fFJaec5BQeRagStZl/3vhUpDS9EZXN0IFsgMTUyIDAgUiAvRml0QiBd
IA0vUGFyZW50IDI2NyAwIFIgDS9QcmV2IDI2OSAwIFIgDS9OZXh0IDI3MiAwIFIgDT4+IA1lbmRv
YmoNMjc0IDAgb2JqDTw8IA0vVGl0bGUgKFlYF8+ItUI/4JvotH6sVtMUNZ0LiKXzKQ0vRGVzdCBb
IDExNyAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNDQgMCBSIA0vUHJldiAyNjYgMCBSIA0vTmV4dCAy
NjggMCBSIA0vRmlyc3QgMjg1IDAgUiANL0xhc3QgMjg2IDAgUiANL0NvdW50IDIgDT4+IA1lbmRv
YmoNMjc1IDAgb2JqDTw8IA0vVGl0bGUgKOeuDrIsJikNL0Rlc3QgWyAxNDAgMCBSIC9GaXRCIF0g
DS9QYXJlbnQgMjY4IDAgUiANL05leHQgMjc3IDAgUiANPj4gDWVuZG9iag0yNzYgMCBvYmoNPDwg
DS9UaXRsZSAoGTTLXCho9RwpDS9EZXN0IFsgMTQ2IDAgUiAvRml0QiBdIA0vUGFyZW50IDI2OCAw
IFIgDS9QcmV2IDI3NyAwIFIgDS9GaXJzdCAyNzggMCBSIA0vTGFzdCAyNzkgMCBSIA0vQ291bnQg
NyANPj4gDWVuZG9iag0yNzcgMCBvYmoNPDwgDS9UaXRsZSAoZpXJs2EpDS9EZXN0IFsgMTQzIDAg
UiAvRml0QiBdIA0vUGFyZW50IDI2OCAwIFIgDS9QcmV2IDI3NSAwIFIgDS9OZXh0IDI3NiAwIFIg
DT4+IA1lbmRvYmoNMjc4IDAgb2JqDTw8IA0vVGl0bGUgKG7+XHLKA/X4RLDkywkHT1NlwpjLP+4p
DS9EZXN0IFsgMTQ2IDAgUiAvRml0QiBdIA0vUGFyZW50IDI3NiAwIFIgDS9OZXh0IDI4MiAwIFIg
DS9GaXJzdCAyODMgMCBSIA0vTGFzdCAyODQgMCBSIA0vQ291bnQgMiANPj4gDWVuZG9iag0yNzkg
MCBvYmoNPDwgDS9UaXRsZSAo9CGfoFwpV+jBfS0kvwPYLvyZTZwUTi0APZFYez+aKQ0vRGVzdCBb
IDE0OSAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNzYgMCBSIA0vUHJldiAyODAgMCBSIA0+PiANZW5k
b2JqDTI4MCAwIG9iag08PCANL1RpdGxlICiE9HFSqEVLPPmNwh3JZEKA+1woPs/LpbtztCkNL0Rl
c3QgWyAxNDkgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMjc2IDAgUiANL1ByZXYgMjgxIDAgUiANL05l
eHQgMjc5IDAgUiANPj4gDWVuZG9iag0yODEgMCBvYmoNPDwgDS9UaXRsZSAoLqd9+AxmOmrY/jWT
jLPTAaQ4w1nNKQ0vRGVzdCBbIDE0OSAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNzYgMCBSIA0vUHJl
diAyODIgMCBSIA0vTmV4dCAyODAgMCBSIA0+PiANZW5kb2JqDTI4MiAwIG9iag08PCANL1RpdGxl
ICge6XsUDvCWhxdcXOSlvglaGBYTe9nIwV+A7ykNL0Rlc3QgWyAxNDkgMCBSIC9GaXRCIF0gDS9Q
YXJlbnQgMjc2IDAgUiANL1ByZXYgMjc4IDAgUiANL05leHQgMjgxIDAgUiANPj4gDWVuZG9iag0y
ODMgMCBvYmoNPDwgDS9UaXRsZSAoyK8ycaB/hQJW5a+wl6F1dZcnXFynw0dMP8YpDS9EZXN0IFsg
MTQ2IDAgUiAvRml0QiBdIA0vUGFyZW50IDI3OCAwIFIgDS9OZXh0IDI4NCAwIFIgDT4+IA1lbmRv
YmoNMjg0IDAgb2JqDTw8IA0vVGl0bGUgKPhAMiE7fZfAiy6S25FAbcPsVZJvaz12sNspDS9EZXN0
IFsgMTQ2IDAgUiAvRml0QiBdIA0vUGFyZW50IDI3OCAwIFIgDS9QcmV2IDI4MyAwIFIgDT4+IA1l
bmRvYmoNMjg1IDAgb2JqDTw8IA0vVGl0bGUgKNOfzPz4Sk0CZMduqW92pp+p8xaRg7/Rakv0r9y1
RdE2UqnlI9KigQEuKQ0vRGVzdCBbIDEyMSAwIFIgL0ZpdEIgXSANL1BhcmVudCAyNzQgMCBSIA0v
TmV4dCAyODYgMCBSIA0+PiANZW5kb2JqDTI4NiAwIG9iag08PCANL1RpdGxlICiIXG700Vvsym+s
aDmOnsJVC0fFq+QM0pshtXh5/L4cGiLJzHdJqrVCDikNL0Rlc3QgWyAxMjggMCBSIC9GaXRCIF0g
DS9QYXJlbnQgMjc0IDAgUiANL1ByZXYgMjg1IDAgUiANPj4gDWVuZG9iag0yODcgMCBvYmoNPDwg
DS9Qcm9kdWNlciAog1xyTaKxXCmlHpEhJY8b1hjaam/RE+Xq4IzeoRMQ9QGeLgLZKQ0vS2V5d29y
ZHMgKJQLTaSAIbZQ9QE42zHVGtlxK4BTtropDS9Nb2REYXRlICiGVFxy/eN54QbkfWfLQ4NFjTV/
0hrl7+cpDS9BdXRob3IgKJIGVqG/IaEenVwpOpcT11n9eSSATykNL0NyZWF0aW9uRGF0ZSAohlRc
cv3jeeEG5H1ny0OORo8pDS9UaXRsZSAomkN0jIAb6x6NBRrbOd9ccp9ZXCiXWLCypYTF82Ai7hmT
IhCKt4To6s9wcpbrsfC40ykNL0NyZWF0b3IgKI8HXFy/vDu+WKFoAZQA3lSGNn8pDT4+IA1lbmRv
YmoNMjg4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjk1IDAgUiAxIDAgUiA3NiAw
IFIgOTkgMCBSIDEwNiAwIFIgMTEwIDAgUiAxMTMgMCBSIDExNyAwIFIgMTIxIDAgUiANMTI1IDAg
UiBdIA0vQ291bnQgMTAgDS9QYXJlbnQgMjg5IDAgUiANPj4gDWVuZG9iag0yODkgMCBvYmoNPDwg
DS9UeXBlIC9QYWdlcyANL0tpZHMgWyAyODggMCBSIDI5MCAwIFIgMjkxIDAgUiBdIA0vQ291bnQg
MjggDT4+IA1lbmRvYmoNMjkwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMTI4IDAg
UiAxMzIgMCBSIDE0MCAwIFIgMTQzIDAgUiAxNDYgMCBSIDE0OSAwIFIgMTUyIDAgUiAxNTggMCBS
IDE2MyAwIFIgDTE2NiAwIFIgXSANL0NvdW50IDEwIA0vUGFyZW50IDI4OSAwIFIgDT4+IA1lbmRv
YmoNMjkxIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMTY5IDAgUiAxNzIgMCBSIDE3
NSAwIFIgMTc4IDAgUiAxODEgMCBSIDE5MiAwIFIgMTk1IDAgUiAyMDcgMCBSIF0gDS9Db3VudCA4
IA0vUGFyZW50IDI4OSAwIFIgDT4+IA1lbmRvYmoNeHJlZg0wIDI5MiANMDAwMDAwMDAwMCA2NTUz
NSBmDQowMDAwMTExNTU2IDAwMDAwIG4NCjAwMDAxMTIyMjYgMDAwMDAgbg0KMDAwMDExMjM2OCAw
MDAwMCBuDQowMDAwMTEyNTExIDAwMDAwIG4NCjAwMDAxMTI2NTQgMDAwMDAgbg0KMDAwMDExMjc5
NyAwMDAwMCBuDQowMDAwMTEyOTQxIDAwMDAwIG4NCjAwMDAxMTMwODUgMDAwMDAgbg0KMDAwMDEx
MzIyOSAwMDAwMCBuDQowMDAwMTEzMzczIDAwMDAwIG4NCjAwMDAxMTM1MTggMDAwMDAgbg0KMDAw
MDExMzY2MyAwMDAwMCBuDQowMDAwMTEzODA4IDAwMDAwIG4NCjAwMDAxMTM5NTMgMDAwMDAgbg0K
MDAwMDExNDA5OCAwMDAwMCBuDQowMDAwMTE0MjQzIDAwMDAwIG4NCjAwMDAxMTQzODggMDAwMDAg
bg0KMDAwMDExNDUzMyAwMDAwMCBuDQowMDAwMTE0Njc4IDAwMDAwIG4NCjAwMDAxMTQ4MjMgMDAw
MDAgbg0KMDAwMDExNDk2OCAwMDAwMCBuDQowMDAwMTE1MTEzIDAwMDAwIG4NCjAwMDAxMTUyNTgg
MDAwMDAgbg0KMDAwMDExNTQwMyAwMDAwMCBuDQowMDAwMTE1NTQ4IDAwMDAwIG4NCjAwMDAxMTU2
OTMgMDAwMDAgbg0KMDAwMDExNTgzOCAwMDAwMCBuDQowMDAwMTE1OTgzIDAwMDAwIG4NCjAwMDAx
MTYxMjggMDAwMDAgbg0KMDAwMDExNjI3MyAwMDAwMCBuDQowMDAwMTE2NDE4IDAwMDAwIG4NCjAw
MDAxMTY1NjMgMDAwMDAgbg0KMDAwMDExNjcwOCAwMDAwMCBuDQowMDAwMTE2ODUzIDAwMDAwIG4N
CjAwMDAxMTY5OTggMDAwMDAgbg0KMDAwMDExNzE0MyAwMDAwMCBuDQowMDAwMTE3Mjg4IDAwMDAw
IG4NCjAwMDAxMTc0MzIgMDAwMDAgbg0KMDAwMDExNzU3NSAwMDAwMCBuDQowMDAwMTE3NzE5IDAw
MDAwIG4NCjAwMDAxMTc4NjMgMDAwMDAgbg0KMDAwMDExODAwNyAwMDAwMCBuDQowMDAwMTE4MTUy
IDAwMDAwIG4NCjAwMDAxMTgyOTcgMDAwMDAgbg0KMDAwMDExODQ0MiAwMDAwMCBuDQowMDAwMTE4
NTg3IDAwMDAwIG4NCjAwMDAxMTg3MzIgMDAwMDAgbg0KMDAwMDExODg3NyAwMDAwMCBuDQowMDAw
MTE5MDIyIDAwMDAwIG4NCjAwMDAxMTkxNjcgMDAwMDAgbg0KMDAwMDExOTMxMiAwMDAwMCBuDQow
MDAwMTE5NDU3IDAwMDAwIG4NCjAwMDAxMTk2MDIgMDAwMDAgbg0KMDAwMDExOTc0NyAwMDAwMCBu
DQowMDAwMTE5ODkyIDAwMDAwIG4NCjAwMDAxMjAwMzcgMDAwMDAgbg0KMDAwMDEyMDE4MiAwMDAw
MCBuDQowMDAwMTIwMzI3IDAwMDAwIG4NCjAwMDAxMjA0NzIgMDAwMDAgbg0KMDAwMDEyMDYxNyAw
MDAwMCBuDQowMDAwMTIwNzYyIDAwMDAwIG4NCjAwMDAxMjA5MDcgMDAwMDAgbg0KMDAwMDEyMTA1
MiAwMDAwMCBuDQowMDAwMTIxMTk3IDAwMDAwIG4NCjAwMDAxMjEzNDIgMDAwMDAgbg0KMDAwMDEy
MTQ4NyAwMDAwMCBuDQowMDAwMTIxNjMyIDAwMDAwIG4NCjAwMDAxMjE3NzcgMDAwMDAgbg0KMDAw
MDEyMTkyMiAwMDAwMCBuDQowMDAwMTIyMDY3IDAwMDAwIG4NCjAwMDAxMjIyMTIgMDAwMDAgbg0K
MDAwMDEyMjM1NyAwMDAwMCBuDQowMDAwMTIyNTAyIDAwMDAwIG4NCjAwMDAxMjI2NDYgMDAwMDAg
bg0KMDAwMDEyMjgzNiAwMDAwMCBuDQowMDAwMTMyNTk0IDAwMDAwIG4NCjAwMDAxMzI5MDQgMDAw
MDAgbg0KMDAwMDEzMzA0OSAwMDAwMCBuDQowMDAwMTMzMTk0IDAwMDAwIG4NCjAwMDAxMzMzMzkg
MDAwMDAgbg0KMDAwMDEzMzQ4NCAwMDAwMCBuDQowMDAwMTMzNjI5IDAwMDAwIG4NCjAwMDAxMzM3
NzQgMDAwMDAgbg0KMDAwMDEzMzkxOSAwMDAwMCBuDQowMDAwMTM0MDY0IDAwMDAwIG4NCjAwMDAx
MzQyMDkgMDAwMDAgbg0KMDAwMDEzNDM1NCAwMDAwMCBuDQowMDAwMTM0NDk5IDAwMDAwIG4NCjAw
MDAxMzQ2NDQgMDAwMDAgbg0KMDAwMDEzNDc4OSAwMDAwMCBuDQowMDAwMTM0OTM0IDAwMDAwIG4N
CjAwMDAxMzUwNzkgMDAwMDAgbg0KMDAwMDEzNTIyNCAwMDAwMCBuDQowMDAwMTM1MzY5IDAwMDAw
IG4NCjAwMDAxMzU1MTQgMDAwMDAgbg0KMDAwMDEzNTY1OSAwMDAwMCBuDQowMDAwMTM1ODA0IDAw
MDAwIG4NCjAwMDAxMzU5ODAgMDAwMDAgbg0KMDAwMDEzOTIwMCAwMDAwMCBuDQowMDAwMTM5NDAy
IDAwMDAwIG4NCjAwMDAxMzk1NDkgMDAwMDAgbg0KMDAwMDEzOTY5NiAwMDAwMCBuDQowMDAwMTM5
ODQzIDAwMDAwIG4NCjAwMDAxMzk5OTAgMDAwMDAgbg0KMDAwMDE0MDE2OSAwMDAwMCBuDQowMDAw
MTQ2NjY5IDAwMDAwIG4NCjAwMDAxNDY4NDggMDAwMDAgbg0KMDAwMDE0Njk5NSAwMDAwMCBuDQow
MDAwMTQ3MTc0IDAwMDAwIG4NCjAwMDAxNTE3NDIgMDAwMDAgbg0KMDAwMDE1MTkwMCAwMDAwMCBu
DQowMDAwMTUyMTQwIDAwMDAwIG4NCjAwMDAxNjQ0NjAgMDAwMDAgbg0KMDAwMDE2NDYzOSAwMDAw
MCBuDQowMDAwMTY0Nzg2IDAwMDAwIG4NCjAwMDAxNjQ5ODkgMDAwMDAgbg0KMDAwMDE4NDEzMyAw
MDAwMCBuDQowMDAwMTg0MzEyIDAwMDAwIG4NCjAwMDAxODQ0NTggMDAwMDAgbg0KMDAwMDE4NDY2
NCAwMDAwMCBuDQowMDAwMTkxNTc3IDAwMDAwIG4NCjAwMDAxOTE3NTYgMDAwMDAgbg0KMDAwMDE5
MTkwMyAwMDAwMCBuDQowMDAwMTkyMDgxIDAwMDAwIG4NCjAwMDAxOTc4NTYgMDAwMDAgbg0KMDAw
MDE5ODAxNCAwMDAwMCBuDQowMDAwMTk4MjIwIDAwMDAwIG4NCjAwMDAyMjYwMzUgMDAwMDAgbg0K
MDAwMDIyNjIxNCAwMDAwMCBuDQowMDAwMjI2MzYxIDAwMDAwIG4NCjAwMDAyMjY1NjcgMDAwMDAg
bg0KMDAwMDIzODk1NiAwMDAwMCBuDQowMDAwMjM5MTE0IDAwMDAwIG4NCjAwMDAyMzk0MzAgMDAw
MDAgbg0KMDAwMDI3NDA1NiAwMDAwMCBuDQowMDAwMjc0MjQ2IDAwMDAwIG4NCjAwMDAyNzQ0MzUg
MDAwMDAgbg0KMDAwMDI3NDYxNiAwMDAwMCBuDQowMDAwMjc0ODA1IDAwMDAwIG4NCjAwMDAyNzQ5
OTQgMDAwMDAgbg0KMDAwMDI3NTE1MiAwMDAwMCBuDQowMDAwMjc1MzU4IDAwMDAwIG4NCjAwMDAy
ODg5NjkgMDAwMDAgbg0KMDAwMDI4OTEyNyAwMDAwMCBuDQowMDAwMjg5MzE5IDAwMDAwIG4NCjAw
MDAyOTY1NTUgMDAwMDAgbg0KMDAwMDI5NjcxMyAwMDAwMCBuDQowMDAwMjk2OTA1IDAwMDAwIG4N
CjAwMDAzMDMyMDggMDAwMDAgbg0KMDAwMDMwMzM2NiAwMDAwMCBuDQowMDAwMzAzNTQ0IDAwMDAw
IG4NCjAwMDAzMTAyNTkgMDAwMDAgbg0KMDAwMDMxMDQ1NCAwMDAwMCBuDQowMDAwMzEwNjAxIDAw
MDAwIG4NCjAwMDAzMTA3NDggMDAwMDAgbg0KMDAwMDMxMDg5NCAwMDAwMCBuDQowMDAwMzExMDk4
IDAwMDAwIG4NCjAwMDAzMTY5NjYgMDAwMDAgbg0KMDAwMDMxNzE1MyAwMDAwMCBuDQowMDAwMzE3
MzAwIDAwMDAwIG4NCjAwMDAzMTc0NDcgMDAwMDAgbg0KMDAwMDMxNzY2NSAwMDAwMCBuDQowMDAw
MzI1MjE3IDAwMDAwIG4NCjAwMDAzMjUzNzUgMDAwMDAgbg0KMDAwMDMyNTU1MiAwMDAwMCBuDQow
MDAwMzMyNDkwIDAwMDAwIG4NCjAwMDAzMzI2NDggMDAwMDAgbg0KMDAwMDMzMjgzOCAwMDAwMCBu
DQowMDAwMzQwNzgxIDAwMDAwIG4NCjAwMDAzNDA5MzkgMDAwMDAgbg0KMDAwMDM0MTE0MiAwMDAw
MCBuDQowMDAwMzQ5MzA2IDAwMDAwIG4NCjAwMDAzNDk0NjQgMDAwMDAgbg0KMDAwMDM0OTY2NyAw
MDAwMCBuDQowMDAwMzU5MjA3IDAwMDAwIG4NCjAwMDAzNTkzNjUgMDAwMDAgbg0KMDAwMDM1OTU0
MyAwMDAwMCBuDQowMDAwMzYwNjc2IDAwMDAwIG4NCjAwMDAzNjA4MzQgMDAwMDAgbg0KMDAwMDM2
MTAxMyAwMDAwMCBuDQowMDAwMzY0MTIxIDAwMDAwIG4NCjAwMDAzNjQzNTYgMDAwMDAgbg0KMDAw
MDM2NDUzOCAwMDAwMCBuDQowMDAwMzY0NzIxIDAwMDAwIG4NCjAwMDAzNjQ5MDQgMDAwMDAgbg0K
MDAwMDM2NTA4NyAwMDAwMCBuDQowMDAwMzY1MjY5IDAwMDAwIG4NCjAwMDAzNjU0NTEgMDAwMDAg
bg0KMDAwMDM2NTYzNCAwMDAwMCBuDQowMDAwMzY1ODYwIDAwMDAwIG4NCjAwMDAzNjYwMzkgMDAw
MDAgbg0KMDAwMDM2OTIzMSAwMDAwMCBuDQowMDAwMzY5Mzg5IDAwMDAwIG4NCjAwMDAzNjk1Njcg
MDAwMDAgbg0KMDAwMDM3MTg4NiAwMDAwMCBuDQowMDAwMzcyMTMwIDAwMDAwIG4NCjAwMDAzNzIz
MDIgMDAwMDAgbg0KMDAwMDM3MjQ5NSAwMDAwMCBuDQowMDAwMzcyNjc2IDAwMDAwIG4NCjAwMDAz
NzI5MDEgMDAwMDAgbg0KMDAwMDM3MzEyNyAwMDAwMCBuDQowMDAwMzczMzI2IDAwMDAwIG4NCjAw
MDAzNzM1MDYgMDAwMDAgbg0KMDAwMDM3MzcwNSAwMDAwMCBuDQowMDAwMzczODg1IDAwMDAwIG4N
CjAwMDAzNzQwNzcgMDAwMDAgbg0KMDAwMDM4MDAzMiAwMDAwMCBuDQowMDAwMzgwMTkwIDAwMDAw
IG4NCjAwMDAzODAzNTUgMDAwMDAgbg0KMDAwMDM4MzQzOSAwMDAwMCBuDQowMDAwMzgzNTQyIDAw
MDAwIG4NCjAwMDAzODM5OTkgMDAwMDAgbg0KMDAwMDM4NDE4MiAwMDAwMCBuDQowMDAwMzg0MzU3
IDAwMDAwIG4NCjAwMDAzODQ1NDkgMDAwMDAgbg0KMDAwMDM4NDcyNCAwMDAwMCBuDQowMDAwMzg0
ODM3IDAwMDAwIG4NCjAwMDAzODUwMDEgMDAwMDAgbg0KMDAwMDM4NTA1MyAwMDAwMCBuDQowMDAw
Mzg1MTUyIDAwMDAwIG4NCjAwMDAzODUyNjAgMDAwMDAgbg0KMDAwMDM4NTM2MyAwMDAwMCBuDQow
MDAwMzg1NTg5IDAwMDAwIG4NCjAwMDAzODYxOTkgMDAwMDAgbg0KMDAwMDM4NjQxNSAwMDAwMCBu
DQowMDAwMzg2OTU3IDAwMDAwIG4NCjAwMDAzODcxODkgMDAwMDAgbg0KMDAwMDM4NzkwNSAwMDAw
MCBuDQowMDAwMzg4MTIxIDAwMDAwIG4NCjAwMDAzODg2NzIgMDAwMDAgbg0KMDAwMDM4ODg2MSAw
MDAwMCBuDQowMDAwMzg5MDgxIDAwMDAwIG4NCjAwMDAzODkzMDIgMDAwMDAgbg0KMDAwMDQxNDk0
NyAwMDAwMCBuDQowMDAwNDE1MDI5IDAwMDAwIG4NCjAwMDA0MTUxMDEgMDAwMDAgbg0KMDAwMDQx
NTE5MyAwMDAwMCBuDQowMDAwNDE1MjY1IDAwMDAwIG4NCjAwMDA0MTUzNDIgMDAwMDAgbg0KMDAw
MDQxNTYzNiAwMDAwMCBuDQowMDAwNDE1NzAzIDAwMDAwIG4NCjAwMDA0MTU3NzAgMDAwMDAgbg0K
MDAwMDQxNTg5MiAwMDAwMCBuDQowMDAwNDE2MDUxIDAwMDAwIG4NCjAwMDA0MTYyMTIgMDAwMDAg
bg0KMDAwMDQxNjM2MiAwMDAwMCBuDQowMDAwNDE2NTM1IDAwMDAwIG4NCjAwMDA0MTY3MjYgMDAw
MDAgbg0KMDAwMDQxNjg0OSAwMDAwMCBuDQowMDAwNDE2OTc3IDAwMDAwIG4NCjAwMDA0MTcxMTIg
MDAwMDAgbg0KMDAwMDQxNzI1MiAwMDAwMCBuDQowMDAwNDE3NDI3IDAwMDAwIG4NCjAwMDA0MTc1
NDMgMDAwMDAgbg0KMDAwMDQxNzY3NCAwMDAwMCBuDQowMDAwNDE3ODEzIDAwMDAwIG4NCjAwMDA0
MTc5MzAgMDAwMDAgbg0KMDAwMDQxODA1NSAwMDAwMCBuDQowMDAwNDE4MTY3IDAwMDAwIG4NCjAw
MDA0MTgzMDggMDAwMDAgbg0KMDAwMDQxODQ1MiAwMDAwMCBuDQowMDAwNDE4NTk1IDAwMDAwIG4N
CjAwMDA0MTg3MzggMDAwMDAgbg0KMDAwMDQxODg3NSAwMDAwMCBuDQowMDAwNDE5MDA5IDAwMDAw
IG4NCjAwMDA0MTkxNDIgMDAwMDAgbg0KMDAwMDQxOTI0MyAwMDAwMCBuDQowMDAwNDE5MzkxIDAw
MDAwIG4NCjAwMDA0MTk1NzIgMDAwMDAgbg0KMDAwMDQxOTY2OSAwMDAwMCBuDQowMDAwNDE5Nzcy
IDAwMDAwIG4NCjAwMDA0MTk4OTkgMDAwMDAgbg0KMDAwMDQyMDAyNiAwMDAwMCBuDQowMDAwNDIw
MTUwIDAwMDAwIG4NCjAwMDA0MjAzMjEgMDAwMDAgbg0KMDAwMDQyMDQxOSAwMDAwMCBuDQowMDAw
NDIwNTYwIDAwMDAwIG4NCjAwMDA0MjA2NzIgMDAwMDAgbg0KMDAwMDQyMDgyNyAwMDAwMCBuDQow
MDAwNDIwOTQ5IDAwMDAwIG4NCjAwMDA0MjEwODIgMDAwMDAgbg0KMDAwMDQyMTIxMCAwMDAwMCBu
DQowMDAwNDIxMzQzIDAwMDAwIG4NCjAwMDA0MjE0NjEgMDAwMDAgbg0KMDAwMDQyMTU3OCAwMDAw
MCBuDQowMDAwNDIxNzExIDAwMDAwIG4NCjAwMDA0MjE4NDQgMDAwMDAgbg0KMDAwMDQyMjE0NSAw
MDAwMCBuDQowMDAwNDIyMzAwIDAwMDAwIG4NCjAwMDA0MjIzODUgMDAwMDAgbg0KMDAwMDQyMjU0
NCAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDI5Mg0vSURbPDdmYjlmNzhiOTE2MGI0YjY4ZTBm
NDkxMDkzMGE5ODE0Pjw3ZmI5Zjc4YjkxNjBiNGI2OGUwZjQ5MTA5MzBhOTgxND5dDT4+DXN0YXJ0
eHJlZg0xNzMNJSVFT0YN

------_=_NextPart_000_01C125B5.BE2B94C0--

From MatthewChalmers@firstusa.com  Thu Aug 16 17:38:17 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA21205
	for <saag@jis.mit.edu>; Thu, 16 Aug 2001 17:38:17 -0400 (EDT)
Received: from pm01sm.rst.cw.net (PM01SM.RST.CW.NET [204.71.247.136])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA23182
	for <saag@mit.edu>; Thu, 16 Aug 2001 17:38:16 -0400 (EDT)
Received: from [168.118.4.215] (gw1.firstusa.com [206.151.92.65])
 by PM01SM.RST.CW.NET (PMDF V5.2-33 #42201)
 with ESMTP id <0GI600IA9K3SXC@PM01SM.RST.CW.NET> for saag@mit.edu; Thu,
 16 Aug 2001 21:38:16 +0000 (GMT)
Received: from swilnts808.wil.fusa.com (unverified)
 by (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5568dc6c75a87604d7414@>
 for <saag@mit.edu>; Thu, 16 Aug 2001 17:38:16 -0400
Received: by swilnts808.wil.fusa.com with Internet Mail Service (5.5.2654.52)
	id <RBNQ8W0X>; Thu, 16 Aug 2001 17:35:09 -0400
Content-return: allowed
Date: Thu, 16 Aug 2001 17:35:08 -0400
From: "Chalmers, Matthew (FUSA)" <MatthewChalmers@firstusa.com>
To: "'saag@mit.edu'" <saag@mit.edu>
Message-id: <B39104ADF3A0D311878200A0C9B41A1F05BC13FF@swilnts814.wil.fusa.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-type: text/plain; charset="iso-8859-1"
Subject: [saag] infosecuritymag article
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Did anyone catch the article in Information Security magazine, "Security in
Writing"? It appears to have made no mention of SAAG's discussion of the
subject or the I-Ds
http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt and
http://www.ietf.org/internet-drafts/draft-rescorla-sec-cons-03.txt.

--
Matthew Chalmers
Information Security
FIRST USA BANK, NA



**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

From kent@bbn.com  Fri Aug 17 18:26:10 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA28809
	for <saag@jis.mit.edu>; Fri, 17 Aug 2001 18:26:10 -0400 (EDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA29770
	for <saag@mit.edu>; Fri, 17 Aug 2001 18:26:10 -0400 (EDT)
Received: from [128.33.84.35] (comsecpb.bbn.com [128.33.84.35])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA27245;
	Fri, 17 Aug 2001 18:25:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p0501040ab7a32b9276d3@[128.33.238.58]>
In-Reply-To: <5.1.0.14.2.20010808101114.01dee0a0@localhost>
References: <5.1.0.14.2.20010808101114.01dee0a0@localhost>
Date: Fri, 17 Aug 2001 16:18:26 -0400
To: Robert Moskowitz <rgm-sec@htt-consult.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security  
 Considerations
Cc: Aaron Falk <a.falk@ieee.org>, karn@qualcomm.com, pilc@grc.nasa.gov,
        saag@mit.edu, mankin@isi.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 10:20 AM +0100 8/8/01, Robert Moskowitz wrote:
>
>I have been looking at this vis-a-vis 802.11i.  ESP is very usable 
>as a link layer protection mechanism.  It just needs an applicable 
>KME for sub-IP (layer 2.5 if you will).

What's a KME?

>This of course is a 'different' ESP than 2406.  The nature of the SA 
>is different, no IP address for the tuple, at least.  But the format 
>and much of the code would be the same.

Remember, Bob, a protocol is not just syntax, it's the processing 
part too. What you suggest is definitely not ESP anymore.

>ESP overhead can be 'managed' by selection of the transform.  ESP 
>contributes 10 bytes (14 if we increase the size of the Seq#). 
>3DES-HMAC-SHA1-96 contributes 20 bytes with an average 2 bytes 
>padding.  But a dual-mode AES transform could be much less overhead 
>(conversations with Phil Rogaway seems to indicate that AES128-OCB64 
>would be 8 bytes plus padding).

I saw Phil's message, and it talked about covering static data, but 
the sequence number, unlike the SPI, is not static, so there might be 
additional overhead.

>
>An effort in the security area to define a common security mechinism 
>for link layers would be a benifit to the community.  When I 
>attended the 802.11i meeting in Portland, it was mentioned that it 
>WOULD be nice if IETF did this generically, but since they don't 
>WEP2 needs to come out of the 11i group.

IEEE has a layer 2 security protocol (802.10-SDE) that 802.11 seems 
to be ignoring. I wonder why? That protocol already has a format 
appropriate to the MAC layer.

Steve

From rja@inet.org  Fri Aug 17 19:59:38 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA29220
	for <saag@jis.mit.edu>; Fri, 17 Aug 2001 19:59:38 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA08222
	for <saag@mit.edu>; Fri, 17 Aug 2001 19:59:38 -0400 (EDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 47CDB8266F; Fri, 17 Aug 2001 19:58:58 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010817195228.009d1130@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 19:53:40 -0400
To: Stephen Kent <kent@bbn.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security  
  Considerations
Cc: Robert Moskowitz <rgm-sec@htt-consult.com>, Aaron Falk <a.falk@ieee.org>,
        karn@qualcomm.com, pilc@grc.nasa.gov, saag@mit.edu, mankin@isi.edu
In-Reply-To: <p0501040ab7a32b9276d3@[128.33.238.58]>
References: <5.1.0.14.2.20010808101114.01dee0a0@localhost>
 <5.1.0.14.2.20010808101114.01dee0a0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 16:18 17/08/01, Stephen Kent wrote:
>IEEE has a layer 2 security protocol (802.10-SDE) that 802.11 seems to be ignoring. I wonder why? That protocol already has a format appropriate to the MAC layer.

        I've been wondering this myself.  It would seem that the
obvious approach for 802.11 is to use the existing 802.10 work,
yet they ignored it earlier and seem to be ignoring it now.

Ran
rja@inet.org


From warlord@MIT.EDU  Sun Aug 19 10:16:58 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA07413
	for <saag@jis.mit.edu>; Sun, 19 Aug 2001 10:16:57 -0400 (EDT)
Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA02500
	for <saag@mit.edu>; Sun, 19 Aug 2001 10:16:57 -0400 (EDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3)
	id KAA28335; Sun, 19 Aug 2001 10:16:30 -0400
To: RJ Atkinson <rja@inet.org>
Cc: Stephen Kent <kent@bbn.com>, Robert Moskowitz <rgm-sec@htt-consult.com>,
        Aaron Falk <a.falk@ieee.org>, karn@qualcomm.com, pilc@grc.nasa.gov,
        saag@MIT.EDU, mankin@isi.edu
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security     Considerations
References: <5.1.0.14.2.20010808101114.01dee0a0@localhost>  <5.1.0.14.2.20010808101114.01dee0a0@localhost> <5.1.0.14.2.20010817195228.009d1130@10.30.15.2>
From: Derek Atkins <warlord@MIT.EDU>
Date: 19 Aug 2001 10:16:30 -0400
In-Reply-To: RJ Atkinson's message of "Fri, 17 Aug 2001 19:53:40 -0400"
Message-ID: <sjmbslc2kzl.fsf@rcn.ihtfp.org>
Lines: 26
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Do we know anyone on the IEEE WEP-2 committee?

-derek

RJ Atkinson <rja@inet.org> writes:

> At 16:18 17/08/01, Stephen Kent wrote:
> >IEEE has a layer 2 security protocol (802.10-SDE) that 802.11 seems to be ignoring. I wonder why? That protocol already has a format appropriate to the MAC layer.
> 
>         I've been wondering this myself.  It would seem that the
> obvious approach for 802.11 is to use the existing 802.10 work,
> yet they ignored it earlier and seem to be ignoring it now.
> 
> Ran
> rja@inet.org
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From randy@psg.com  Sun Aug 19 12:11:24 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA08070
	for <saag@jis.mit.edu>; Sun, 19 Aug 2001 12:11:24 -0400 (EDT)
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11454;
	Sun, 19 Aug 2001 12:11:21 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.33 #1)
	id 15YVAV-0001EO-00; Sun, 19 Aug 2001 09:11:19 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Derek Atkins <warlord@mit.edu>
Cc: RJ Atkinson <rja@inet.org>, Stephen Kent <kent@bbn.com>,
        Robert Moskowitz <rgm-sec@htt-consult.com>,
        Aaron Falk <a.falk@ieee.org>, karn@qualcomm.com, pilc@grc.nasa.gov,
        saag@mit.edu, mankin@isi.edu
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security     Considerations
References: <5.1.0.14.2.20010808101114.01dee0a0@localhost>
	<5.1.0.14.2.20010817195228.009d1130@10.30.15.2>
	<sjmbslc2kzl.fsf@rcn.ihtfp.org>
Message-Id: <E15YVAV-0001EO-00@rip.psg.com>
Date: Sun, 19 Aug 2001 09:11:19 -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Do we know anyone on the IEEE WEP-2 committee?

i forwarded the hint.

randy

From pete@loshin.com  Sun Aug 19 13:06:53 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA08381
	for <saag@jis.mit.edu>; Sun, 19 Aug 2001 13:06:53 -0400 (EDT)
From: pete@loshin.com
Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA22963
	for <saag@mit.edu>; Sun, 19 Aug 2001 13:06:53 -0400 (EDT)
Received: from elmo.loshin (h00a0c5e1478f.ne.mediaone.net [24.147.211.223])
	by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f7JH6cx05800;
	Sun, 19 Aug 2001 13:06:38 -0400 (EDT)
Received: from elmo.loshin (pete@localhost)
	by elmo.loshin (8.11.2/8.11.2) with ESMTP id f7JH7ru19618;
	Sun, 19 Aug 2001 13:07:53 -0400
Message-Id: <200108191707.f7JH7ru19618@elmo.loshin>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Chalmers, Matthew (FUSA)" <MatthewChalmers@FirstUSA.com>, saag@mit.edu
cc: "'abriney@infosecuritymag.com'" <abriney@infosecuritymag.com>
In-Reply-To: Message from "Chalmers, Matthew (FUSA)" 
 <MatthewChalmers@FirstUSA.com>
   of "Thu, 16 Aug 2001 17:32:39 EDT." <B39104ADF3A0D311878200A0C9B41A1F05BC13FE@swilnts814.wil.fusa.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 19 Aug 2001 13:07:53 -0400
Subject: [saag] Re: "security in writing" article
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Matthew, I'm glad you found the column interesting. Thanks for pointing out 
these drafts.


> I just read the "Security in Writing" article and am wondering why there is
> no mention of I-Ds
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt and


That column was submitted in early June, a full month before the draft was 
announced on the IETF-announce list.


> http://www.ietf.org/internet-drafts/draft-rescorla-sec-cons-03.txt,


Thanks for pointing this one out. I must have missed it, though most likely, 
from the filename, I inferred it was a fourth version of a non-WG draft.

Will SAAG be adopting this draft or will it be folded into the 
draft-ietf-saag-whyenc draft? There didn't seem to be much discussion of 
that draft in the list archives.


> or the
> fact that the SAAG has been discussing this subject...


Thanks for pointing this out as well. I've just subscribed to the SAAG list so
I won't miss anything in the future. Suggestions for other topics or pointers 
to important new documents or discussions are always welcome.


-pl




From ji@research.att.com  Sun Aug 19 16:39:01 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA09229
	for <saag@jis.mit.edu>; Sun, 19 Aug 2001 16:39:00 -0400 (EDT)
From: ji@research.att.com
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10584;
	Sun, 19 Aug 2001 16:39:00 -0400 (EDT)
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 1B5811E01C; Sun, 19 Aug 2001 16:38:56 -0400 (EDT)
Received: from arran.research.att.com (arran.research.att.com [135.207.24.12])
	by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id QAA09814;
	Sun, 19 Aug 2001 16:38:52 -0400 (EDT)
Received: (from ji@localhost)
	by arran.research.att.com (8.9.3+Sun/8.9.3) id QAA00329;
	Sun, 19 Aug 2001 16:38:51 -0400 (EDT)
Date: Sun, 19 Aug 2001 16:38:51 -0400 (EDT)
Message-Id: <200108192038.QAA00329@arran.research.att.com>
To: rja@inet.org, warlord@mit.edu
Cc: a.falk@ieee.org, karn@qualcomm.com, kent@bbn.com, mankin@isi.edu,
        pilc@grc.nasa.gov, rgm-sec@htt-consult.com, saag@mit.edu
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security     Considerations
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Isn't 802.1x also applicable (to the extent that any of that stuff is)?

/ji

From aboba@internaut.com  Sun Aug 19 17:42:25 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA09464
	for <saag@jis.mit.edu>; Sun, 19 Aug 2001 17:42:25 -0400 (EDT)
Received: from internaut.com ([64.38.134.99])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA15792;
	Sun, 19 Aug 2001 17:42:23 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id OAA15578;
	Sun, 19 Aug 2001 14:35:11 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Sun, 19 Aug 2001 14:35:11 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: ji@research.att.com
cc: rja@inet.org, warlord@mit.edu, a.falk@ieee.org, karn@qualcomm.com,
        kent@bbn.com, mankin@isi.edu, pilc@grc.nasa.gov,
        rgm-sec@htt-consult.com, saag@mit.edu
Subject: Re: [saag] PILC IETF-51 discussion on LINK Security     Considerations
In-Reply-To: <200108192038.QAA00329@arran.research.att.com>
Message-ID: <Pine.BSF.4.21.0108191416410.15550-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Sun, 19 Aug 2001 ji@research.att.com wrote:

> Isn't 802.1x also applicable (to the extent that any of that stuff is)?

Before improved authentication and key management would help, there
is some basic infrastructure that needs to be put in place first:

a) per-session keys (most current 802.11 Access Points can't handle
   per-session keying, only per-enterprise keys)

b) a keyed MIC, so that you can support per-packet authentication, avoid
   hijacking  and tie the derived session key to subsequent packets.

c) a credible cipher (e.g. not WEP)

Unfortunately, current 802.11b chipsets are so inflexible and typical
AP processors are so slow that it is very difficult to deliver this on
legacy APs. So I think it is more likely that we will need new chipsets
(and new faster AP processors) before anything defensible emerges.

For example, the Intersil Prism II chipset sends the frame as soon as it
is encrypted so the best that can be done is to calculcate the MIC prior
to encryption, not after. Even this is hard because there are so few
cycles available on a typical AP processor that even UMAC may  be
infeasible.      



From HUITEMA@windows.microsoft.com  Thu Sep 13 12:43:12 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA18398
	for <saag@jis.mit.edu>; Thu, 13 Sep 2001 12:43:12 -0400 (EDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id MAA04288
	for <saag@mit.edu>; Thu, 13 Sep 2001 12:43:12 -0400 (EDT)
Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 09:41:43 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 13 Sep 2001 09:41:43 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 13 Sep 2001 09:41:43 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 13 Sep 2001 09:41:05 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 13 Sep 2001 09:41:04 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BF7E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: How important is source address verification?
Thread-Index: AcE8cs9/FfJgo1HQTPe+ohfXDqqYyA==
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <saag@mit.edu>
Cc: "Pekka Savola" <pekkas@netcore.fi>,
        "Brian E Carpenter" <brian@hursley.ibm.com>,
        "Keith Moore" <moore@cs.utk.edu>
X-OriginalArrivalTime: 13 Sep 2001 16:41:05.0277 (UTC) FILETIME=[E1A5EAD0:01C13C72]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id MAA18398
Subject: [saag] How important is source address verification?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

A question for the security area:

We were having a discussion on the security of "automatic tunneling"
schemes such as "6to4", which carries IPv6 packets to IPv4 addresses
embedded in the IPv6 addresses. Such schemes can potentially be used for
laundering a denial of service attack, in the following way:

* an IPv6 packet is tunnel from IPv4 source A to the "6to4 relay" B,
* B ditches the IPv4 header, looks at the IPv6 content, and relays the
packet to the IPv6 destination X.
* X receives a packet that appears to come from IPv6 source Y. All
traces of address A disappeared when the IPv4 header was ditched by B.

The scheme can is fundamentally a source routing mechanism, which means
that it can be used for classic source-routing based attacks; it is a
laundering mechanism, which means it can be used to send untraceable DoS
packets, even if the ISP servicing the hacker, A, is actually
implementing source address filters. The source routing attacks are
relatively easy to deal with using access control lists at the relays;
address spoofing, on the other hand, is hard. 

We could in theory require that IPv6 source address of the tunneled
packets "embeds" the same source address that appears at the IPv4
header, thus making the IPv6 source address control just as good as the
IPv4 source address control. However, we cannot apply that requirement
to relays; in our example, if X answer to Y, the reverse path will go
through a relay such as B, and B's address will not be related to X. We
must distinguish between ordinary sources, for which the test would be
applied, and relay routers, for which it should not. A possibility is to
let relay routers use a conventional source address, the anycast address
defined in RFC 3068.

However, any enforcement of source address screening breaks things. In
our case, it would make deployment of relay routers a bit more complex,
since they will be required to "spoof" a source address; this would in
practice prevent dual-stacked hosts that have a "real" IPv6 address to
send packets directly to the 6to4 destination; they would instead be
required to route packets over IPv6 to the nearest relay router. We
could special-case that, and tell hosts to accept packets from any
source if it is bound to their specific local domain; this would
slightly relax screening for enhanced practicality; in practice, this
would mean that screening is only performed by relay routers. But even
this relaxation would not get us out of the woods.

We can expect that IPv6 hosts will very often be dual-stacked, to IPv6
and IPv4, and thus potentially multi-homed, to a native IPv6 address and
to a 6to4 address. Multi-homing and source screening don't play well
together: what if I start a conversation on one interface and then
discover that sending packets on another is more efficient, e.g. because
of a routing change? There will be error cases, as explained in
draft-draves-ipngwg-ingress-filtering-00.txt.

So, given that source address screening breaks things, my question to
the SAAG is, how important is it? Do we have a doctrine on that?

-- Christian Huitema



From pete.chown@skygate.co.uk  Fri Sep 14 05:22:16 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA27135
	for <saag@jis.mit.edu>; Fri, 14 Sep 2001 05:22:15 -0400 (EDT)
Received: from lion.skygate.co.uk (lion.skygate.co.uk [212.134.128.34])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id FAA28772
	for <saag@mit.edu>; Fri, 14 Sep 2001 05:22:14 -0400 (EDT)
Received: from hyena.skygate.co.uk ([10.0.0.2] ident=root)
	by lion.skygate.co.uk with esmtp (Exim 3.20 #2)
	id 15hpAp-000505-00; Fri, 14 Sep 2001 10:22:11 +0100
Received: from pc by hyena.skygate.co.uk with local (Exim 3.20 #2)
	id 15hpAl-0005Tz-00; Fri, 14 Sep 2001 10:22:07 +0100
Date: Fri, 14 Sep 2001 10:22:07 +0100
From: Pete Chown <Pete.Chown@skygate.co.uk>
To: saag@mit.edu
Cc: Christian Huitema <huitema@windows.microsoft.com>,
        Pekka Savola <pekkas@netcore.fi>,
        Brian E Carpenter <brian@hursley.ibm.com>,
        Keith Moore <moore@cs.utk.edu>
Subject: Re: [saag] How important is source address verification?
Message-ID: <20010914102207.A20946@hyena.skygate.co.uk>
References: <F66A04C29AD9034A8205949AD0C9010418BF7E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BF7E@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>; from huitema@windows.microsoft.com on Thu, Sep 13, 2001 at 09:41:04AM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Christian Huitema wrote:

> We were having a discussion on the security of "automatic tunneling"
> schemes such as "6to4", which carries IPv6 packets to IPv4 addresses
> embedded in the IPv6 addresses. Such schemes can potentially be used for
> laundering a denial of service attack ...

Whether this is a problem depends on how IPv6 comes into use, I think.
If we end up with an IPv6 Internet and an IPv4 Internet, connected at
backbone switching points, it might be a problem.  On the other hand
if we end up with most conversion being done at corporate gateways, it
should be easier to trace DoS traffic back.

The other potential problem arises from spoofed connections.  My
personal feeling is that this isn't too big a problem.  It isn't
sensible to use rlogin over the public Internet any more anyway.

I'm not sure what the answer is.  Perhaps something along the lines of
an ICMP traceback message from the gateway to the destination?

-- 
Pete

From owner-saag@MIT.EDU  Mon Sep 17 19:15:06 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA17061
	for <saag@jis.mit.edu>; Mon, 17 Sep 2001 19:15:06 -0400 (EDT)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA00864
	for <saag@mit.edu>; Mon, 17 Sep 2001 19:15:06 -0400 (EDT)
Received: from guinness (mx.last.plus.net [212.159.3.230])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id TAA29367
	Mon, 17 Sep 2001 19:07:00 -0400 (EDT)
From: Internet-Drafts@ietf.org
Received: from [212.159.14.227] (helo=warrior-outbound.services.quay.plus.net)
	by guinness with smtp (Exim 3.16 #2)
	id 15j7OO-0002J0-00
	for saag@lists.tislabs.com; Tue, 18 Sep 2001 00:01:32 +0100
Received: (qmail 29202 invoked from network); 17 Sep 2001 23:13:47 -0000
Received: from unknown (HELO NEXUS.replicants.org.uk) (212.56.122.201)
  by warrior with SMTP; 17 Sep 2001 23:13:47 -0000
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Tue, 18 Sep 2001 00:13:46 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 14:30:12 2001
Received: from [132.151.1.177] (helo=loki.ietf.org)	by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15Esus-0006g0-00; Tue, 26 Jun 2001 14:30:07 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19010	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18553	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:01:48 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27137;	Tue, 26 Jun 2001 07:01:47 -0400 (EDT)
Message-Id: <200106261101.HAA27137@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 26 Jun 2001 07:01:47 -0400
X-OriginalArrivalTime: 17 Sep 2001 23:13:46.0915 (UTC) FILETIME=[67218F30:01C13FCE]
Subject: [saag] I-D ACTION:draft-mcgrew-saag-sst-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Stream Cipher Security Transform
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-sst-00.txt
	Pages		: 12
	Date		: 25-Jun-01
	
This document describes a cryptographic transform which uses a
stream cipher (which can generate keystream segments in arbitrary
order) and a universal hash function to provide both privacy and
authentication together, or either security service separately.
This transform is efficient, provably secure, appropriate for
network security, and is believed to be patent free.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-sst-00.txt

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-mcgrew-saag-sst-00.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-mcgrew-saag-sst-00.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:	<20010625095516.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-sst-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-sst-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"


From rja@inet.org  Wed Sep 19 09:04:11 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00989
	for <saag@jis.mit.edu>; Wed, 19 Sep 2001 09:04:11 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA24066
	for <saag@mit.edu>; Wed, 19 Sep 2001 09:04:10 -0400 (EDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id 0F7358266E
	for <saag@mit.edu>; Wed, 19 Sep 2001 09:03:16 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010919085444.00a34ec0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 19 Sep 2001 08:56:24 -0400
To: saag@mit.edu
From: RJ Atkinson <rja@inet.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [saag] Steganography, etc.
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

http://www.washingtonpost.com/wp-dyn/articles/A52687-2001Sep18.html

	Above article discusses various things, including the use of
steganography by the WTC adversary.  

	As with all articles from The Washington Post, no annoying sign-up 
is required to read the article.  Also, it works without cookies or 
other such gorp.

Ran
rja@inet.org


From smb@research.att.com  Wed Sep 19 19:43:32 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA04498
	for <saag@jis.mit.edu>; Wed, 19 Sep 2001 19:43:32 -0400 (EDT)
Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA08322
	for <saag@mit.edu>; Wed, 19 Sep 2001 19:43:31 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 022E77C00; Wed, 19 Sep 2001 19:43:16 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: RJ Atkinson <rja@inet.org>
Cc: saag@mit.edu
Subject: Re: [saag] Steganography, etc. 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 19 Sep 2001 19:43:16 -0400
Message-Id: <20010919234317.022E77C00@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <5.1.0.14.2.20010919085444.00a34ec0@10.30.15.2>, RJ Atkinson writes:
>http://www.washingtonpost.com/wp-dyn/articles/A52687-2001Sep18.html
>
>	Above article discusses various things, including the use of
>steganography by the WTC adversary.  
>
>	As with all articles from The Washington Post, no annoying sign-up 
>is required to read the article.  Also, it works without cookies or 
>other such gorp.

Also see Niels Provos and Peter Honeyman,
"Detecting Steganographic Content on the Internet," August 2001,
http://www.citi.umich.edu/techreports/reports/citi-tr-01-11.pdf or
http://www.citi.umich.edu/techreports/reports/citi-tr-01-11.ps.gz

		--Steve Bellovin, http://www.research.att.com/~smb
				  http://www.wilyhacker.com



From Karen.Hewett@VisionInBusiness.com  Tue Sep 25 05:23:55 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA21648
	for <saag@jis.mit.edu>; Tue, 25 Sep 2001 05:23:55 -0400 (EDT)
Received: from crsrv1.visioninbusiness.com (mail.visioninbusiness.com [195.12.232.82])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id FAA19107
	for <saag@mit.edu>; Tue, 25 Sep 2001 05:23:52 -0400 (EDT)
Received: from SMTP agent by mail gateway 
 Tue, 25 Sep 2001 10:22:51 -0000
Received: from crsrv1.visioninbusiness.com (not verified[192.168.1.1]) by crsrv1.visioninbusiness.com with MailMarshal (4,1,0,0) 
	id <B000058619>; Tue, 25 Sep 2001 10:25:06 +0100
Received: by CRSRV1 with Internet Mail Service (5.5.2653.19)
	id <SG25G3JB>; Tue, 25 Sep 2001 10:25:06 +0100
Message-ID: <A5BC20AE00F5D311BC9600508BA8E4DC539486@wssrv1.visioninbusiness.com>
From: Karen Hewett <Karen.Hewett@VisionInBusiness.com>
To: "'saag@mit.edu'" <saag@mit.edu>
Date: Tue, 25 Sep 2001 10:25:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [saag] 11208 IP Fraud and Security
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Please find attached the weblink for our event IP Fraud and Security.  I
believe that it is possible for you to make this available to your members
of the Security Working Group.

http://www.visioninbusiness.com/elink.taf?EventUid=100155&CatUID=1&id=(11208
KWG)

Would it be possible for this to be distributed in the next couple of days
as we would like to give your members enough time to find out about this
event.

Thank you



Karen Hewett
Marketing Assistant
Tel: 0207 839 8391
Fax: 0207 7839 3777
www.visioninbusiness.com

Please note emails may be monitored.



Vision in Business are proud to be winners of the Queen's Award 2001 for
International Trade

==================================================================
Visit our web site at http://www.visioninbusiness.com
==================================================================

This email and any files transmitted with it are confidential and
intended for the exclusive use of the addressee only.
If you are not the intended recipient, you should not use the
contents nor disclose them to any other person and you should
immediately notify the sender and delete the email. The statements
and opinions expressed here may not represent those of the company.

Note - emails may be monitored from time to time.



From phoffman@imc.org  Thu Oct 11 20:10:22 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA18006
	for <saag@jis.mit.edu>; Thu, 11 Oct 2001 20:10:21 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA07515
	for <saag@mit.edu>; Thu, 11 Oct 2001 20:10:21 -0400 (EDT)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id f9C0AGD19646
	for <saag@mit.edu>; Thu, 11 Oct 2001 17:10:16 -0700 (PDT)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05100310b7ebe4d816ce@[165.227.249.20]>
Date: Thu, 11 Oct 2001 17:09:39 -0700
To: saag@mit.edu
From: Paul Hoffman / IMC <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [saag] Fwd: Last Call: AES Ciphersuites for TLS to Proposed Standard
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This is probably relevant to everyone in the security community, not 
just the TLS folks. Since they are first to IETF last call with AES 
cipher suites, other WGs will probably be required to follow what 
they did, or justify the differences.

>To: IETF-Announce: ;
>Cc: ietf-tls@lists.certicom.com
>From: The IESG <iesg-secretary@ietf.org>
>SUBJECT: Last Call: AES Ciphersuites for TLS to Proposed Standard
>Reply-to: iesg@ietf.org
>Date: Thu, 11 Oct 2001 15:56:20 -0400
>Sender: scoya@cnri.reston.va.us
>
>
>The IESG has received a request from the Transport Layer Security
>Working Group to consider AES Ciphersuites for TLS
><draft-ietf-tls-ciphersuite-05.txt> as a Proposed Standard.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>iesg@ietf.org or ietf@ietf.org mailing lists by October 25, 2001.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-05.txt


From rja@inet.org  Fri Oct 12 10:22:41 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA21449
	for <saag@jis.mit.edu>; Fri, 12 Oct 2001 10:22:36 -0400 (EDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA01796
	for <saag@mit.edu>; Fri, 12 Oct 2001 10:22:33 -0400 (EDT)
Received: from mosquito.inet.org (unknown [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 22C6E67103; Fri, 12 Oct 2001 10:18:49 -0400 (EDT)
Message-Id: <5.1.0.14.2.20011012100117.00a0e430@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 12 Oct 2001 10:03:38 -0400
To: Paul Hoffman / IMC <phoffman@imc.org>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Fwd: Last Call: AES Ciphersuites for TLS to
  Proposed Standard
Cc: saag@mit.edu
In-Reply-To: <p05100310b7ebe4d816ce@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 20:09 11/10/01, Paul Hoffman / IMC wrote:
>This is probably relevant to everyone in the security community, not just the TLS folks. Since they are first to IETF last call with AES cipher suites, other WGs will probably be required to follow what they did, or justify the differences.

Good point.

        IMHO, the TLS AES document should be particularly reviewed 
in conjunction with the existing IPsec AES I-D, partly because the 
IPsec AES I-D is there to be reviewed and partly because the 
IPsec AES document is written by folks actually working for NIST.

Ran


From paulfordh@uk.ibm.com  Tue Oct 16 12:11:14 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA10484
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 12:11:13 -0400 (EDT)
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA04910
	for <saag@mit.edu>; Tue, 16 Oct 2001 12:06:50 -0400 (EDT)
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA117582;
	Tue, 16 Oct 2001 18:06:15 +0200
Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16])
	by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f9GG2JW27450;
	Tue, 16 Oct 2001 17:02:20 +0100
To: "IETF Transport Layer Security WG" <ietf-tls@lists.certicom.com>
Cc: saag@mit.edu
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
From: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a
 |January 17, 2001) at 16/10/2001 05:01:24 PM,
	Serialize by Notes Client on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a |January
 17, 2001) at 16/10/2001 05:01:24 PM,
	Serialize complete at 16/10/2001 05:01:24 PM,
	Itemize by Notes Client on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a |January
 17, 2001) at 16/10/2001 05:01:24 PM,
	S/MIME Sign complete at 16/10/2001 05:01:24 PM,
	S/MIME Sign by Idle on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a |January
 17, 2001) at 16/10/2001 05:02:16 PM,
	S/MIME Sign complete at 16/10/2001 05:02:16 PM,
	Serialize by Router on D06ML035/06/M/IBM(Release 5.0.8 |June 18, 2001) at
 16/10/2001 17:02:20,
	Serialize complete at 16/10/2001 17:02:20
Message-ID: <OF1CAE41EF.35A0C3D7-ON80256AE7.005777DF@portsmouth.uk.ibm.com>
Date: Tue, 16 Oct 2001 17:02:17 +0100
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z18029_boundary_sign
Subject: [saag] RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This is an S/MIME signed message.

---------z18029_boundary_sign
Content-Type: text/plain; charset="us-ascii"

I have been asked to re-post this question, which got lost in the TLS 
pathsec discussion:

Should this discussion really be in SAAG rather than TLS ?

Paul

==================


I was under the impression that the IETF direction was to negotiate SSL
within an application exchange (RFC2817 for http) and not perform SSL
blindly upon connection (RFC2818).

(Quote from RFC 2817
"At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors and the IESG reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can apply Transport Layer Security [6] to an open
   HTTP connection.")

It appears clear that the TLS community is trying to preserve the
Informational RFC2818 approach over the Standards Track RFC2817 by the
proposal of DNS name in the TLS extensions draft.

Is this deliberate ?
Is there tacit agreement that RFC2817 is a pipe dream ?
How should that impact other SSL protected protocols that may require
multi-homing ?

Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh@uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html


---------z18029_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggMLMIICdKADAgECAgIJEjANBgkqhkiG9w0BAQQFADBMMQswCQYDVQQGEwJV
UzEbMBkGA1UEChMSRXF1aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4
IFNlY3VyZSBFbWFpbCBDQTAeFw0wMTA4MTQxNTIxMTdaFw0wMjA4MjgxNTIxMTda
MHAxCzAJBgNVBAYTAlVTMREwDwYDVQQLEwhFTVBMT1lFRTEMMAoGA1UEChMDSUJN
MSMwIQYJKoZIhvcNAQkBFhRwYXVsZm9yZGhAdWsuaWJtLmNvbTEbMBkGA1UEAxMS
UC4gRm9yZC1IdXRjaGluc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDB
Ju6r/+l27iqWEjYBodNeQ3CV7IgTY5xrpIgSH3dDdax91Jxpo+cNm/6JWEnxG2xX
Pk7RQ4j6ObbJ/v6FuwhDwIpbRF1zRaDAHPa8zm30AgBTwH/U/YfgDEtAzI1/lzfe
oct21pxonj5fyq9fR530MAzAlDmal/N89xxWz0VgTQIDAQABo4HXMIHUMA4GA1Ud
DwEB/wQEAwIE8DBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vd3d3LmVxdWlmYXhz
ZWN1cmUuY29tL2VidXNpbmVzc2lkL2NybC9zbWltZTY0Yi5jcmwwdgYDVR0gBG8w
bTBrBglghkgBhvpMAQEwXjAXBggrBgEFBQcCAjALMAcWADADAgEBGgAwQwYIKwYB
BQUHAgEWN2h0dHA6Ly93d3cuZXF1aWZheHNlY3VyZS5jb20vZWJ1c2luZXNzaWQv
c21pbWVfY3BzLmh0bWwwDQYJKoZIhvcNAQEEBQADgYEAXkOQjJRTVBCvyZkFfqeY
/t500W2D2BOqe9eFQKnvpgqlWNVRCc5btJINrabnzY2gt6ZvV1nJ+hJB/GIxFQn5
sa1awWWUZmezi89pxR9bPQoDuj9bsvNuxDYrcofKBkoA0w097OestfcqLVA0Qkdr
k1Cny2TXgUEncMAfVp8b54wwggLGMIICL6ADAgECAhAyUUtmqxxV37wOus3CAbYI
MA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u
MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAxMTAxMDAw
MDAwWhcNMDIxMDMxMjM1OTU5WjBMMQswCQYDVQQGEwJVUzEbMBkGA1UEChMSRXF1
aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4IFNlY3VyZSBFbWFpbCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnmf+Gzg6AUfgU5XrJvA3dpKo
bSG3hsbwbnJUfmw19NpjcKaD1dx3i5hU/qvJpZSeUd8eiCYB2VlMM+7LW+PswzQI
8HeY39yxLJGnQmfjukRCYac+z0aG8WIX3a/abmFaWwaji1J5hsDrd+n4D3V7tYqt
43rvAvhd/nupGu4ZXtMCAwEAAaMjMCEwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV
HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAfegBKd5iW9WaDV36QvYAkVeTQDpd
MdmIg76FyOiODY6GskUdJPGufemhagP7t0COvySgATBwDdlQaucH7V4pCZqcSYJ6
XMCOHb+uOJFqe46BXLj6V8GABvJC7SpGOO3wmiIUQgYh74w0ByAV9Aata6xV5fy0
EVDFC5pJ5hwP8C8wggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
IFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0
aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVt
YWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB
0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1m
cmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDU
adfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbq
o925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVL
VX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB
Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+N
YFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+du
AEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WL
DN1RhGvk+NHOd6KBAAAxgDCCAaICAQEwUjBMMQswCQYDVQQGEwJVUzEbMBkGA1UE
ChMSRXF1aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4IFNlY3VyZSBF
bWFpbCBDQQICCRIwCQYFKw4DAhoFAKCBqzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEwMTYxNjAxMjRaMCMGCSqGSIb3DQEJBDEW
BBRCH0E7Xy4cRXrI3sryoT0seXxRijBMBgkqhkiG9w0BCQ8xPzA9MAcGBSsOAwId
MA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzAHBgUrDgMCBzANBggqhkiG9w0D
AgIBKDANBgkqhkiG9w0BAQEFAASBgJQfFQPoZ6OylolY/+wgzfASz9YECc6fVyDp
pFHKJY9dgXuGxqXTd0op2X2YGYAsQ0bL8+B81d2ApDSA/pjFGg6sMai7NwYG6W3n
V0I/DBasoKyG/5nKwo9GZuJ5izHylfjocbhFKGzqlvixA9rGuVbdEEGAjvl9G3Gb
4qqn8/a5AAAAAAAAAAA=

---------z18029_boundary_sign--

From moore@cs.utk.edu  Tue Oct 16 15:03:11 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11697
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 15:03:11 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA16919
	for <saag@mit.edu>; Tue, 16 Oct 2001 15:03:09 -0400 (EDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id f9GJ3dP15146;
        Tue, 16 Oct 2001 15:03:39 -0400 (EDT)
Message-Id: <200110161903.f9GJ3dP15146@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
cc: "IETF Transport Layer Security WG" <ietf-tls@lists.certicom.com>,
        saag@mit.edu
Subject: Re: [saag] RFC2817 or RFC2818 ? 
In-reply-to: Your message of "Tue, 16 Oct 2001 17:02:17 BST."
             <OF1CAE41EF.35A0C3D7-ON80256AE7.005777DF@portsmouth.uk.ibm.com> 
Date: Tue, 16 Oct 2001 15:03:39 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Is there tacit agreement that RFC2817 is a pipe dream ?

the pipe dream is believing that SSL/TLS authentication, or even encryption,
can usefully be separated from the application, or that port numbers are
a good mechanism for protocol feature negotiation.

Keith

From ekr@rtfm.com  Tue Oct 16 15:12:50 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11795
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 15:12:50 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA13560
	for <saag@mit.edu>; Tue, 16 Oct 2001 15:12:44 -0400 (EDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id f9GJJ2Z73310; Tue, 16 Oct 2001 12:19:02 -0700 (PDT)
To: saag@mit.edu
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 16 Oct 2001 12:19:01 -0700
Message-ID: <kjheszmlzu.fsf@romeo.rtfm.com>
Lines: 56
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Subject: [saag] [Eric Rescorla <ekr@rtfm.com>] [ietf-tls] Re: RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

NOTE: When I replied to this on ietf-tls I forgot to cc SAAG. if you 
followup to this message please cc ietf-tls@certicom.com as well.

"Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com> writes:
> I was under the impression that the IETF direction was to negotiate SSL
> within an application exchange (RFC2817 for http) and not perform SSL
> blindly upon connection (RFC2818).
> 
> (Quote from RFC 2817
> "At the Washington DC IETF meeting in December 1997, the Applications
>    Area Directors and the IESG reaffirmed that the practice of issuing
>    parallel "secure" port numbers should be deprecated. The HTTP/1.1
>    Upgrade mechanism can apply Transport Layer Security [6] to an open
>    HTTP connection.")
That's the official word, yes.

> It appears clear that the TLS community is trying to preserve the
> Informational RFC2818 approach over the Standards Track RFC2817 by the
> proposal of DNS name in the TLS extensions draft.
>
> Is this deliberate ?
I'm not necessarily sure that this necessarily follows from the
introduction of dns_name. Rather, think of it as accepting that
HTTPS isn't going away anytime soon.

> Is there tacit agreement that RFC2817 is a pipe dream ?
It's important to distinguish between the general idea of
an upward negotiation strategy and the realization of that idea in
RFC 2817. RFC 2817 is pretty badly broken:

(1) There's no adequate way to use upgrade with proxies because
Upgrade is a hop-by-hop header and what you really want is to negotiate 
TLS end-to-end. In order to get Upgrade to work you need to tunnel
through the proxy using CONNECT. Obviously this is bad since it
means that proxies become essentially useless.

(2) There's no way to indicate in the URL that RFC 2817-style
upgrade is expected. This has nasty consequences:
	(a) If the client ever wants TLS to be used for his requests
	he needs to send an OPTIONS request (to probe for Upgrade)
	before sending his actual request. (The server can request TLS
	but the client has already sent his request at that
	point). This creates an unacceptable performance cost.
	(b) No reference integrity, even of the "require security sort"
	that is allowed by the "https://" URL. This means that an attacker
	can downgrade you to ordinary HTTP.

However, this isn't to say that you couldn't design an upward-negotiation
strategy for HTTP that would work. You certainly could.

-Ekr

---
You are currently subscribed to ietf-tls as: ekr@rtfm.com
To unsubscribe send a blank email to leave-ietf-tls-3174256S@lists.certicom.com


From slawrence@virata.com  Tue Oct 16 16:33:05 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12345
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 16:33:05 -0400 (EDT)
From: slawrence@virata.com
Received: from firewall.ma.virata.com (agranat.com [198.113.147.2])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA18610
	for <saag@mit.edu>; Tue, 16 Oct 2001 16:33:04 -0400 (EDT)
Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130])
	by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id QAA27597;
	Tue, 16 Oct 2001 16:32:10 -0400
Received: from oyster.local (dhcp74.ma.virata.com [10.21.0.74])
	by agranat.com (8.9.3/8.9.3) with ESMTP id QAA21971;
	Tue, 16 Oct 2001 16:32:10 -0400
Received: (from lawrence@localhost)
	by oyster.local (8.9.3/8.8.7) id QAA02149;
	Tue, 16 Oct 2001 16:32:10 -0400
X-Authentication-Warning: oyster.local: lawrence set sender to slawrence@virata.com using -f
To: EKR <ekr@rtfm.com>
Cc: saag@mit.edu
References: <kjheszmlzu.fsf@romeo.rtfm.com>
Organization: Virata Corp.
Date: 16 Oct 2001 16:32:10 -0400
In-Reply-To: <kjheszmlzu.fsf@romeo.rtfm.com>
Message-ID: <82bsj7milx.fsf@oyster.local>
Lines: 26
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [saag] Re: RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla <ekr@rtfm.com> writes:

> It's important to distinguish between the general idea of
> an upward negotiation strategy and the realization of that idea in
> RFC 2817. RFC 2817 is pretty badly broken:
> 
> (1) There's no adequate way to use upgrade with proxies because
> Upgrade is a hop-by-hop header and what you really want is to negotiate 
> TLS end-to-end. In order to get Upgrade to work you need to tunnel
> through the proxy using CONNECT. Obviously this is bad since it
> means that proxies become essentially useless.

Which does not distinguish between the two strategies at all - to do
any end-to-end encryption through a proxy, one must first use CONNECT
to create a tunnel through that proxy.  This is exactly what all
browsers do now for https:.

> However, this isn't to say that you couldn't design an upward-negotiation
> strategy for HTTP that would work. You certainly could.

One that does not require either communication with the server or
changing the URLs?  I don't think so.

-- 
Scott Lawrence                            slawrence@virata.com
Virata Embedded UPnP & Web Technology    http://www.emweb.com/

From ekr@rtfm.com  Tue Oct 16 16:50:23 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12486
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 16:50:23 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA24479
	for <saag@mit.edu>; Tue, 16 Oct 2001 16:50:21 -0400 (EDT)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.11.3/8.6.4) with ESMTP id f9GKubS73615; Tue, 16 Oct 2001 13:56:37 -0700 (PDT)
Message-Id: <200110162056.f9GKubS73615@romeo.rtfm.com>
To: slawrence@virata.com
cc: saag@mit.edu, ietf-tls@certicom.com
In-reply-to: Your message of "16 Oct 2001 16:32:10 EDT."
             <82bsj7milx.fsf@oyster.local> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 16 Oct 2001 13:56:37 -0700
From: Eric Rescorla <ekr@rtfm.com>
Subject: [saag] Re: RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Eric Rescorla <ekr@rtfm.com> writes:
> 
> > It's important to distinguish between the general idea of
> > an upward negotiation strategy and the realization of that idea in
> > RFC 2817. RFC 2817 is pretty badly broken:
> > 
> > (1) There's no adequate way to use upgrade with proxies because
> > Upgrade is a hop-by-hop header and what you really want is to negotiate 
> > TLS end-to-end. In order to get Upgrade to work you need to tunnel
> > through the proxy using CONNECT. Obviously this is bad since it
> > means that proxies become essentially useless.
> 
> Which does not distinguish between the two strategies at all - to do
> any end-to-end encryption through a proxy, one must first use CONNECT
> to create a tunnel through that proxy.  This is exactly what all
> browsers do now for https:.
Yes, but with HTTPS you only do this when you know you're going to
get SSL so you don't lose anything. In order for Upgrade to work you
need to ALWAYS use CONNECT whether or not you're going to get SSL.
That's the problem--you can't even offer Upgrade to the server without
first tunnelling through the proxy. This is bad. [0]

> > However, this isn't to say that you couldn't design an upward-negotiation
> > strategy for HTTP that would work. You certainly could.
> 
> One that does not require either communication with the server or
> changing the URLs?  I don't think so.
No, you need a hybrid strategy.

There are two goals we're trying to achieve here:
(1) Allow opportunistic encryption--if both sides want to support
TLS they can discover this and negotiate it. This sort of approach
is always subject to active attack. 

(2) Have secure links--the client knows that the URL is supposed
to be dereferenced securely and will only communicate via SSL. This
requires somehow providing the client with a suitably tagged reference,
e.g. via the URL. This approach is not subject to active attack
provided that you obtained the link securely in the first place.


HTTPS allows you to have secure links but not opportunistic
encryption. Unfortunately, RFC 2817 doesn't meet either goal: it
doesn't provide secure links and the hoops you have to jump through to
get opportunistic encryption make it impractical.

-Ekr

[0] Proxy interaction is only important in the opportunistic encryption
case, since some clients and servers will want to offer SSL at all
times but still have proxies (and especially caches) operate normally
if HTTP is being used. As you point out above, proxy interaction is
irrelevant if you know you want a secure link. You just need some
way to tunnel through the proxy in that case.

[Eric Rescorla                                   ekr@rtfm.com]
Author of "SSL and TLS: Designing and Building Secure Systems"
                  http://www.rtfm.com/
  







From warlord@MIT.EDU  Tue Oct 16 17:07:51 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA12629
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 17:07:51 -0400 (EDT)
Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA09256
	for <saag@mit.edu>; Tue, 16 Oct 2001 17:07:50 -0400 (EDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3)
	id RAA03456; Tue, 16 Oct 2001 17:07:35 -0400
To: Eric Rescorla <ekr@rtfm.com>
Cc: slawrence@virata.com, saag@MIT.EDU, ietf-tls@certicom.com
Subject: Re: [saag] Re: RFC2817 or RFC2818 ?
References: <200110162056.f9GKubS73615@romeo.rtfm.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 16 Oct 2001 17:07:35 -0400
In-Reply-To: Eric Rescorla's message of "Tue, 16 Oct 2001 13:56:37 -0700"
Message-ID: <sjmhesz1eg8.fsf@rcn.ihtfp.org>
Lines: 25
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla <ekr@rtfm.com> writes:

> (2) Have secure links--the client knows that the URL is supposed
> to be dereferenced securely and will only communicate via SSL. This
> requires somehow providing the client with a suitably tagged reference,
> e.g. via the URL. This approach is not subject to active attack
> provided that you obtained the link securely in the first place.

I don't think that https: (the URL tag sequence) will ever disappear
for exactly this reason, however HTTPS, the protocol separate from
HTTP, may disappear.  In this manner they are separable.  There are
times when the user will specifically want to tag a reference as "must
use encryption" (hense https:...) but you could still use the HTTP
Upgrade method to obtain the encryption.

If the Upgrade fails, it's the equivalent of port 443 not responding
and you report an error to the user.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From ekr@rtfm.com  Tue Oct 16 17:10:58 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA12694
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 17:10:58 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA10583;
	Tue, 16 Oct 2001 17:10:40 -0400 (EDT)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.11.3/8.6.4) with ESMTP id f9GLH5S73694; Tue, 16 Oct 2001 14:17:05 -0700 (PDT)
Message-Id: <200110162117.f9GLH5S73694@romeo.rtfm.com>
To: Derek Atkins <warlord@MIT.EDU>
cc: slawrence@virata.com, saag@MIT.EDU, ietf-tls@lists.certicom.com
Subject: Re: [saag] Re: RFC2817 or RFC2818 ? 
In-reply-to: Your message of "16 Oct 2001 17:07:35 EDT."
             <sjmhesz1eg8.fsf@rcn.ihtfp.org> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 16 Oct 2001 14:17:05 -0700
From: Eric Rescorla <ekr@rtfm.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Header edited so this goes to ietf-tls as well.

> Eric Rescorla <ekr@rtfm.com> writes:
> 
> > (2) Have secure links--the client knows that the URL is supposed
> > to be dereferenced securely and will only communicate via SSL. This
> > requires somehow providing the client with a suitably tagged reference,
> > e.g. via the URL. This approach is not subject to active attack
> > provided that you obtained the link securely in the first place.
> 
> I don't think that https: (the URL tag sequence) will ever disappear
> for exactly this reason, however HTTPS, the protocol separate from
> HTTP, may disappear.  In this manner they are separable.  There are
> times when the user will specifically want to tag a reference as "must
> use encryption" (hense https:...) but you could still use the HTTP
> Upgrade method to obtain the encryption.
> 
> If the Upgrade fails, it's the equivalent of port 443 not responding
> and you report an error to the user.

I don't think you could safely use the string "https:" for this
because it creates too many incompatibilities with servers and
clients that already expect HTTPS on port 443. Better to use a 
URL scheme. I suppose "httpt" is free :)

-Ekr

From jpierre@netscape.com  Tue Oct 16 17:31:52 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA12856
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 17:31:52 -0400 (EDT)
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA10609
	for <saag@MIT.EDU>; Tue, 16 Oct 2001 17:31:51 -0400 (EDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f9GLVJx20295
	for <saag@MIT.EDU>; Tue, 16 Oct 2001 14:31:19 -0700 (PDT)
Received: from netscape.com ([208.12.60.44]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id GLBIG701.T97;
          Tue, 16 Oct 2001 14:31:19 -0700 
Message-ID: <3BCCA72B.E3220918@netscape.com>
Date: Tue, 16 Oct 2001 14:31:24 -0700
From: jpierre@netscape.com (Julien Pierre)
X-Mailer: Mozilla 4.77 [en]C-AOLNSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>
CC: slawrence@virata.com, saag@MIT.EDU
Subject: Re: [ietf-tls] Re: [saag] Re: RFC2817 or RFC2818 ?
References: <LISTMANAGER-5202136-4190-2001.10.16-16.13.31--jpierre#netscape.com@lists.certicom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric,

Eric Rescorla wrote:

> I don't think you could safely use the string "https:" for this
> because it creates too many incompatibilities with servers and
> clients that already expect HTTPS on port 443. Better to use a
> URL scheme. I suppose "httpt" is free :)

I agree with you completely. I have been arguing with Scott in the past on the IETF
HTTP working group mailing list that a new URL scheme was required to tell HTTP
clients that they need to first connect insecurely and then upgrade to TLS from a
URL. In fact "httpt" is exactly the same URL scheme I proposed over a year ago, but
it was rejected. As a result I just decided to leave the TLS upgrade support out of
the product which eventually became the Netscape/iPlanet web server 6.0 . It could
have been easily implemented but the specification was not good enough for
practical deployment.

Here is a summary of the arguments of that discussion, as it pertained to the web
server 6.0 implementation of SSL/TLS . This was written earlier this year in
february ; web server 6.0 was released in may.

I considered implementing this for iWS 6.0, but decided against it for the
following reasons :
1) This upgrade scheme requires new clients that support upgrade. Old clients
either won't work at all (if the server requires secure mode with upgrade) or will
end up being insecure, which is very bad.
2) There is no URL scheme defined to tell which objects are secure and non-secure.
The proposed URL scheme for http with TLS upgrade is the regular "http://" used for
non secure content, and when to the negotiation is left undetermined.
The result is that if you have both upgrade-compatible clients and servers, all
connections will be secure. If either side is not upgrade-compatible, they are all
insecure. Neither case is desirable. Security has significant performance on
servers, and it is desirable to be able to set which portions of your site are
secure and which are not. Most content doesn't need to be secure and you don't want
it to be, unless you have the money for spare hardware to handle it. Even then, the
user's experience will generally be a bit slower. No security is obviously not
acceptable for some content.

Some will argue that it is possible to resolve this secure/non-secure control by
setting ACLs on the server and configuring which parts require security. But this
means a lot more work on the part of the server administrator to determine this. It
is infinitely easier to simply set the "https://" URL scheme on the pages that
require security, as it is done today without TLS upgrade. Unfortunately the
SSL/TLS protocol specified with "https://" is not directly compatible with the TLS
upgrade scheme, since it doesn't have an initial insecure handshake. When
specifying https:// in a client, it is expected that the SSL/TLS handshake will
occur at the first I/O operation, but that is not true with TLS upgrade.

In addition, the URL scheme can be quite a headache to manage this with dynamic
content as well, since "http://" has to be specified in all dynamic pages. It would
then be up to each individual application to check security in its URI space for
each request !!!

Because of this, I think the TLS upgrade scheme proposed is inherently flawed and
not workable for general-purpose applications. I discussed this in detail on the
HTTP working group mailing list. The author admitted that he created it
specifically for use with the "internet printing applications" and that it was
never intended for general use in web clients and servers.

I think the problem could be easily resolved simply by adding a new URL scheme
(such as httpt:// ) which would mean to the client : send the host header to this
server with HTTP, then upgrade the connection to TLS and proceed with the request
securely, in much of the fashion as with https (same protocols/ciphers/etc). This
would resolve the huge ambiguity that exists today in the proposed TLS upgrade
scheme.

Unfortunately, as simple as the solution is, I haven't found any support for it to
make it a standard, and I'm not the kind of person who likes to put proprietary
extensions. Therefore, I decided to just leave TLS upgrade out of iWS 6.0 ; even
though it would have fit very well in our grand scheme of SSL virtual servers, and
would have been fairly easy to implement.



From jpierre@netscape.com  Tue Oct 16 20:01:04 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA18413
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 20:01:04 -0400 (EDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA02534
	for <saag@mit.edu>; Tue, 16 Oct 2001 20:01:03 -0400 (EDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f9H00TY11039
	for <saag@mit.edu>; Tue, 16 Oct 2001 17:00:29 -0700 (PDT)
Received: from netscape.com ([208.12.60.44]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id GLBPCV01.PBV;
          Tue, 16 Oct 2001 17:00:31 -0700 
Message-ID: <3BCCCA23.1B73BBED@netscape.com>
Date: Tue, 16 Oct 2001 17:00:35 -0700
From: jpierre@netscape.com (Julien Pierre)
X-Mailer: Mozilla 4.77 [en]C-AOLNSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: tim <tfs@mystic.uprising.net>
CC: ietf-tls@lists.certicom.com, slawrence@virata.com, saag@mit.edu
Subject: Re: [ietf-tls] Re: [saag] Re: RFC2817 or RFC2818 ?
References: <200110162327.TAA33087@mystic.uprising.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Tim,

tim wrote:

> [history snipped]
>
> While I can appreciate your interest in not propritorizing this, I agree that
> it is a good approach. And, while their are many quite debatable factors
> associated with what part of an URL to put it in, in the interum it'd be
> nice if the holy wars associated with that wouldn't inhibit development
> and running code in other areas.
>
> Perhaps as a development solution `httpt' or some other ridicoulously long
> and innocous element like `tptthtemp' could be used...
>
> That way people could work on it, and where appropriate it could allways
> have a runtime switch of say, -pt to invoke it at start.
>
> It seems to me at this point that there's enough work to be done
> that it's a bit of a shame to see it held up on things like this.

Yes, I think it was a shame too to skip it. However in the context of commercial products
shipping and something as pervasive as a new protocol handler, there is not as much room
for shipping experimental code. If a new protocol handler for this is available,
customers will start to use it, and reference it in their HTML. The web server has to
know about it to generate dynamic content with the right prefix in server applications.
The web browser has to know about it to do the proper handshake. Both have to be changed
to support TLS upgrade. But what happens with interoperability with other clients who
don't know about the new scheme ? Answer : it doesn't work.

For this reason, it's not something that I felt comfortable "experimenting" with before
having a real standard available. Both client and server products had to ship for a
variety of reasons, and could not wait for the new standard to be finalized, so the
feature just did not go in. Even if/when a standard scheme for this is approved, it will
be a significant time before everybody upgrades to the new versions of web clients that
will be required to access the new type of servers. So I think it's important to get it
right the first time because if we don't, it will delay the actual deployment even more.

> Personaly, I do not, and have not since the beginning of it's real
> useage, consider `https' to be a useable convention for things like
> this. There have been far too many limitations coded into the
> `https' convention at this point to make it's use beyond the normal
> current useage anything other than a total nightmare for people
> doing development on software that doesn't work around the evolved
> limitations of `https'.
>

It may be limited but in fact I think it does the job pretty well, at least the way that
current browsers & servers are implemented today and their default security settings.



From tfs@mystic.uprising.net  Tue Oct 16 19:27:41 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA13882
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 19:27:36 -0400 (EDT)
Received: from mystic.uprising.net (mystic.uprising.net [198.22.109.62])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA14721
	for <saag@mit.edu>; Tue, 16 Oct 2001 19:27:36 -0400 (EDT)
Received: (from tfs@localhost)
	by mystic.uprising.net (8.9.2/8.9.2) id TAA33087;
	Tue, 16 Oct 2001 19:27:10 -0400 (EDT)
	(envelope-from tfs)
From: tim <tfs@mystic.uprising.net>
Message-Id: <200110162327.TAA33087@mystic.uprising.net>
Subject: Re: [ietf-tls] Re: [saag] Re: RFC2817 or RFC2818 ?
In-Reply-To: <3BCCA72B.E3220918@netscape.com> from Julien Pierre at "Oct 16, 2001  2:31:24 pm"
To: jpierre@netscape.com (Julien Pierre)
Date: Tue, 16 Oct 2001 19:27:10 -0400 (EDT)
Cc: ietf-tls@lists.certicom.com, slawrence@virata.com, saag@mit.edu
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Julien Pierre wrote:
> Eric,
> 
> Eric Rescorla wrote:
> 
> > I don't think you could safely use the string "https:" for this
> > because it creates too many incompatibilities with servers and
> > clients that already expect HTTPS on port 443. Better to use a
> > URL scheme. I suppose "httpt" is free :)
> 
> I agree with you completely. I have been arguing with Scott in the past on the IETF
> HTTP working group mailing list that a new URL scheme was required to tell HTTP
> clients that they need to first connect insecurely and then upgrade to TLS from a
> URL. In fact "httpt" is exactly the same URL scheme I proposed over a year ago, but
> it was rejected. As a result I just decided to leave the TLS upgrade support out of
> the product which eventually became the Netscape/iPlanet web server 6.0 . It could
> have been easily implemented but the specification was not good enough for
> practical deployment.

[history snipped]

While I can appreciate your interest in not propritorizing this, I agree that
it is a good approach. And, while their are many quite debatable factors
associated with what part of an URL to put it in, in the interum it'd be
nice if the holy wars associated with that wouldn't inhibit development
and running code in other areas. 

Perhaps as a development solution `httpt' or some other ridicoulously long
and innocous element like `tptthtemp' could be used... 

That way people could work on it, and where appropriate it could allways
have a runtime switch of say, -pt to invoke it at start.

It seems to me at this point that there's enough work to be done
that it's a bit of a shame to see it held up on things like this.

Personaly, I do not, and have not since the beginning of it's real
useage, consider `https' to be a useable convention for things like
this. There have been far too many limitations coded into the
`https' convention at this point to make it's use beyond the normal
current useage anything other than a total nightmare for people
doing development on software that doesn't work around the evolved
limitations of `https'.  



Tim Scanlon







From slawrence@virata.com  Tue Oct 16 21:22:48 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA06324
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 21:22:48 -0400 (EDT)
From: slawrence@virata.com
Received: from smtp1.bignet.net (IDENT:root@smtp1.bignet.net [64.79.64.13])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA17982;
	Tue, 16 Oct 2001 21:22:48 -0400 (EDT)
Received: from oyster.local (host89.64-31-7.bignet.net [64.31.7.89])
	by smtp1.bignet.net (8.11.0/8.11.0) with ESMTP id f9H1Mkj06870;
	Tue, 16 Oct 2001 21:22:46 -0400
Received: (from lawrence@localhost)
	by oyster.local (8.9.3/8.8.7) id VAA01328;
	Tue, 16 Oct 2001 21:22:30 -0400
X-Authentication-Warning: oyster.local: lawrence set sender to slawrence@virata.com using -f
To: Eric Rescorla <ekr@rtfm.com>
Cc: Derek Atkins <warlord@mit.edu>, slawrence@virata.com, saag@mit.edu,
        ietf-tls@lists.certicom.com
Subject: Re: [saag] Re: RFC2817 or RFC2818 ?
References: <200110162117.f9GLH5S73694@romeo.rtfm.com>
Organization: Virata Corp.
Date: 16 Oct 2001 21:22:29 -0400
In-Reply-To: <200110162117.f9GLH5S73694@romeo.rtfm.com>
Message-ID: <82lmib12ne.fsf@oyster.local>
Lines: 15
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla <ekr@rtfm.com> writes:

> I don't think you could safely use the string "https:" for this
> because it creates too many incompatibilities with servers and
> clients that already expect HTTPS on port 443. Better to use a 
> URL scheme. I suppose "httpt" is free :)

I agree entirely.  Defining a new URL scheme was a bigger bite than we
were willing to attempt at the time.  We made clear, for reasons that
all here seem to understand (though not all did then) that we did not
intend to redefine https.

-- 
Scott Lawrence                            slawrence@virata.com
Virata Embedded UPnP & Web Technology    http://www.emweb.com/

From slawrence@virata.com  Tue Oct 16 21:47:08 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA06470
	for <saag@jis.mit.edu>; Tue, 16 Oct 2001 21:47:08 -0400 (EDT)
From: slawrence@virata.com
Received: from smtp1.bignet.net (IDENT:root@smtp1.bignet.net [64.79.64.13])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA03323
	for <saag@MIT.EDU>; Tue, 16 Oct 2001 21:47:07 -0400 (EDT)
Received: from oyster.local (host89.64-31-7.bignet.net [64.31.7.89])
	by smtp1.bignet.net (8.11.0/8.11.0) with ESMTP id f9H1l4j10481;
	Tue, 16 Oct 2001 21:47:04 -0400
Received: (from lawrence@localhost)
	by oyster.local (8.9.3/8.8.7) id VAA01344;
	Tue, 16 Oct 2001 21:46:58 -0400
X-Authentication-Warning: oyster.local: lawrence set sender to slawrence@virata.com using -f
To: IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>,
        saag@MIT.EDU
References: <LISTMANAGER-5202136-4190-2001.10.16-16.13.31--jpierre#netscape.com@lists.certicom.com>
	<3BCCA72B.E3220918@netscape.com>
Organization: Virata Corp.
Date: 16 Oct 2001 21:46:58 -0400
In-Reply-To: <3BCCA72B.E3220918@netscape.com>
Message-ID: <82g08j11il.fsf_-_@oyster.local>
Lines: 42
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [saag] Re: RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

jpierre@netscape.com (Julien Pierre) writes:

> I agree with you completely. I have been arguing with Scott in the
> past on the IETF HTTP working group mailing list that a new URL
> scheme was required to tell HTTP clients that they need to first
> connect insecurely and then upgrade to TLS from a URL. In fact
> "httpt" is exactly the same URL scheme I proposed over a year ago,
> but it was rejected.

I don't recall that discussion, but I've got a notoriously bad
memory.  It's entirely possible that I was disagreeing with something
else, not understanding what you wanted.  In any event...

It is true that we did have a need (for use by IPP) to properly define
what Upgrade meant in HTTP/1.1 (the descriptions in 2616 were not
complete enough), to document the CONNECT method (which, though widely
implemented did not have a standards track definition), and to
describe how the two interact.  RFC 2817 accomplished those goals,
along with creating a couple of IANA registries that also should have
been there already.  IPP implementations have been created and
deployed that use the system we described.  That is not the same as
saying that what we did was specifically for IPP - I have on a number
of occasions shown how the identical mechanism can be used to switch
from HTTP to whatever other protocol is required (the purpose of
Upgrade). IPP was just the 'customer' on the critical path.

In any event, I would not have any objection to a new URL scheme to
provide an indication of security requirements.  Before jumping into
such a thing, I think that we should consider carefully just what we
want the semantics of such a thing to be.  What are the requirements
of a security label in a URL?  Rohit and I, while working on 2817,
felt that the single boolean flag secure/insecure (the scheme token
http or https) had caused as many problems as it solved, and were not
comfortable with doing that again in the time we had available.
Personally, I always preferred message-oriented shttp over
connection-oriented security, but didn't implement it in my server
because it didn't seem to have support in browsers (though it was no
better as a security label in URLs).

-- 
Scott Lawrence                            slawrence@virata.com
Virata Embedded UPnP & Web Technology    http://www.emweb.com/

From ekr@rtfm.com  Wed Oct 17 00:06:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id AAA07207
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 00:06:50 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA02390
	for <saag@mit.edu>; Wed, 17 Oct 2001 00:06:36 -0400 (EDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id f9H4CO574569; Tue, 16 Oct 2001 21:12:24 -0700 (PDT)
To: slawrence@virata.com
Cc: IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>,
        saag@mit.edu
Subject: Re: [saag] Re: RFC2817 or RFC2818 ?
References: <LISTMANAGER-5202136-4190-2001.10.16-16.13.31--jpierre#netscape.com@lists.certicom.com> <3BCCA72B.E3220918@netscape.com> <82g08j11il.fsf_-_@oyster.local>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 16 Oct 2001 21:12:24 -0700
In-Reply-To: slawrence@virata.com's message of "16 Oct 2001 21:46:58 -0400"
Message-ID: <kjwv1ulxav.fsf@romeo.rtfm.com>
Lines: 40
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

slawrence@virata.com writes:
> In any event, I would not have any objection to a new URL scheme to
> provide an indication of security requirements.  Before jumping into
> such a thing, I think that we should consider carefully just what we
> want the semantics of such a thing to be.  What are the requirements
> of a security label in a URL?  Rohit and I, while working on 2817,
> felt that the single boolean flag secure/insecure (the scheme token
> http or https) had caused as many problems as it solved, and were not
> comfortable with doing that again in the time we had available.
It's important to distinguish between a number of different goals for
a security label:

(1) To provide reference integrity.
(2) To streamline negotiation.
(3) To provide the client with information about what security
properties to expect.

Since SSL/TLS has protection for the handshake and verifies the server,
just telling the client to expect SSL goes a long way towards providing
(1). I tend to think that streamlining negotiations would be nice
(that's why we did it in S-HTTP) but it's kind of contrary to the spirit
of SSL. Again, (3) would be nice but I'm not sure it's worth adding a 
lot of unnecessary complexity.

What information do you feel should be carried in the URL other than
the bit of secure or insecure, and why?
    
> Personally, I always preferred message-oriented shttp over
> connection-oriented security, but didn't implement it in my server
> because it didn't seem to have support in browsers (though it was no
> better as a security label in URLs).
I'm not sure what you mean by this. In general S-HTTP carries it's
security labelling in attributes attached to the anchor, not in the
URL.  The shttp: is just a signal to do S-HTTP and that you should
look for security attributes in the anchor. S-HTTP did allow for bare
shttp: URLs but we always considered that a hack.

-Ekr



From tfs@mystic.uprising.net  Wed Oct 17 00:35:30 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id AAA07390
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 00:35:29 -0400 (EDT)
Received: from mystic.uprising.net (mystic.uprising.net [198.22.109.62])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA28058
	for <saag@mit.edu>; Wed, 17 Oct 2001 00:35:29 -0400 (EDT)
Received: (from tfs@localhost)
	by mystic.uprising.net (8.9.2/8.9.2) id AAA39537;
	Wed, 17 Oct 2001 00:35:23 -0400 (EDT)
	(envelope-from tfs)
From: tim <tfs@mystic.uprising.net>
Message-Id: <200110170435.AAA39537@mystic.uprising.net>
Subject: Re: [ietf-tls] Re: [saag] Re: RFC2817 or RFC2818 ?
In-Reply-To: <3BCCCA23.1B73BBED@netscape.com> from Julien Pierre at "Oct 16, 2001  5: 0:35 pm"
To: jpierre@netscape.com (Julien Pierre)
Date: Wed, 17 Oct 2001 00:35:23 -0400 (EDT)
Cc: ietf-tls@lists.certicom.com, slawrence@virata.com, saag@mit.edu
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Julien Pierre wrote:
> Tim wrote:
> > It seems to me at this point that there's enough work to be done
> > that it's a bit of a shame to see it held up on things like this.
> 
> Yes, I think it was a shame too to skip it. However in the context of commercial products
> shipping and something as pervasive as a new protocol handler, there is not as much room
> for shipping experimental code. If a new protocol handler for this is available,
> customers will start to use it, and reference it in their HTML. The web server has to
> know about it to generate dynamic content with the right prefix in server applications.
> The web browser has to know about it to do the proper handshake. Both have to be changed
> to support TLS upgrade. But what happens with interoperability with other clients who
> don't know about the new scheme ? Answer : it doesn't work.
> 
> For this reason, it's not something that I felt comfortable "experimenting" with before
> having a real standard available. Both client and server products had to ship for a
> variety of reasons, and could not wait for the new standard to be finalized, so the
> feature just did not go in. Even if/when a standard scheme for this is approved, it will
> be a significant time before everybody upgrades to the new versions of web clients that
> will be required to access the new type of servers. So I think it's important to get it
> right the first time because if we don't, it will delay the actual deployment even more.

That's all quite true. I think that there is a real problem here, and 
the details of it illustrate the quasi-deadlock in development that's
occuring. Or perhaps that's better characterized as progress or
evolution, given that there's a lot of code waiting in the wings.

That's why I was suggesting something interum to begin with, but it
is fairly obvious to me now that isn't a viable alternative.

Also, and this is the other side of the coin of the idea of using
http/https straight up, debugging that integration would be something
of a nightmare in practice, and client support would run a high
risk of becoming much more problematic than it should be. 

> 
> > Personaly, I do not, and have not since the beginning of it's real
> > useage, consider `https' to be a useable convention for things like
> > this. There have been far too many limitations coded into the
> > `https' convention at this point to make it's use beyond the normal
> > current useage anything other than a total nightmare for people
> > doing development on software that doesn't work around the evolved
> > limitations of `https'.
> >
> 
> It may be limited but in fact I think it does the job pretty well, at least the way that
> current browsers & servers are implemented today and their default security settings.

Well yes, I'd go further to say that it does the job very well. In fact I
have found that becasue things are pretty straightforward & understandable,
communicating with parties that have widely divergent knowledge bases and
focuses (end users, web developers, server developers & admins etc.) is 
possible because the basic design facillitates understanding. 

The thing is though, that basic as it is, there's still a good deal of
ongoing development being done with SSL that I fear seeing having
to be modified to deal with a restructuring to accomodate truely
unpresumptive negotiations via the https/443 mechanisim. I do not, 
by any means at all, speak for anyone doing SSL development. But 
having had to deal with any number of implementations and problems
with getting everything working over the years, I'm pretty
comfortable saying that trying to force this, rather than evolve
to some of of the goals that have been referred to in the discussion
about this, would in fact make development harder. 



Tim Scanlon






From paulfordh@uk.ibm.com  Wed Oct 17 05:12:51 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA08392
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 05:12:51 -0400 (EDT)
Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id FAA15471
	for <saag@mit.edu>; Wed, 17 Oct 2001 05:12:48 -0400 (EDT)
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147])
	by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id JAA103058;
	Wed, 17 Oct 2001 09:58:31 +0100
Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16])
	by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f9H99Eb221168;
	Wed, 17 Oct 2001 10:09:14 +0100
To: "IETF Transport Layer Security WG" <ietf-tls@lists.certicom.com>
Cc: saag@mit.edu
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
From: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a
 |January 17, 2001) at 17/10/2001 09:58:23 AM,
	Serialize by Notes Client on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a |January
 17, 2001) at 17/10/2001 09:58:23 AM,
	Serialize complete at 17/10/2001 09:58:23 AM,
	Itemize by Notes Client on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a |January
 17, 2001) at 17/10/2001 09:58:23 AM,
	S/MIME Sign complete at 17/10/2001 09:58:23 AM,
	S/MIME Sign by Idle on Paul V Ford-Hutchinson/UK/IBM(Release 5.0.6a |January
 17, 2001) at 17/10/2001 09:59:30 AM,
	S/MIME Sign complete at 17/10/2001 09:59:30 AM,
	Serialize by Router on D06ML035/06/M/IBM(Release 5.0.8 |June 18, 2001) at
 17/10/2001 10:09:14,
	Serialize complete at 17/10/2001 10:09:14
Message-ID: <OF571AE306.12375521-ON80256AE8.002F20D3@portsmouth.uk.ibm.com>
Date: Wed, 17 Oct 2001 09:59:33 +0100
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z64654_boundary_sign
Subject: [saag] TLS in application protocols - summary so far
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This is an S/MIME signed message.

---------z64654_boundary_sign
Content-Type: text/plain; charset="us-ascii"

Summarising the discussion so far (as I read it)

- The separate port approach is a bad idea and no new proposal should 
include it.  In the protocols where the practice is not widespread today, 
it should not be encouraged.

- HTTP TLS upgrade (RFC2817) is not deployable in the general web 
client/server case.  To migrate from port 443 (implicit TLS) to port 80 
(negotiated TLS) will require RFC2817 to be replaced - there is currently 
no work being done to do this.

- The multi-homing problem can be solved for https: by the adoption and 
implementation of the DNSname extension to TLS.  This is a pragmatic 
approach.

- For other (not http) protocols, virtual hosting should be achieved by 
the application protocol, prior to a TLS upgrade.

========

I guess that begs some new questions:

- Once DNSname is out there, will there ever be the impetus to replace the 
port 443 approach ?  Do we care ?

- How tenable is it to have fundamentally different approaches for 
different protocols ?  (The way we want to do it for most protocol vs the 
way we don't want to do it for the most used protocol)

- Should we insist that the DNSname extension addresses the fact that the 
application layer may be also performing a host name negotiation (either 
before or after the TLS one) and specify behaviour ?  (is there 
precedence: app vs TLS; first decided; or must there be agreement ? - what 
to do in the case of failure). 

Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh@uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html


---------z64654_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggMLMIICdKADAgECAgIJEjANBgkqhkiG9w0BAQQFADBMMQswCQYDVQQGEwJV
UzEbMBkGA1UEChMSRXF1aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4
IFNlY3VyZSBFbWFpbCBDQTAeFw0wMTA4MTQxNTIxMTdaFw0wMjA4MjgxNTIxMTda
MHAxCzAJBgNVBAYTAlVTMREwDwYDVQQLEwhFTVBMT1lFRTEMMAoGA1UEChMDSUJN
MSMwIQYJKoZIhvcNAQkBFhRwYXVsZm9yZGhAdWsuaWJtLmNvbTEbMBkGA1UEAxMS
UC4gRm9yZC1IdXRjaGluc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDB
Ju6r/+l27iqWEjYBodNeQ3CV7IgTY5xrpIgSH3dDdax91Jxpo+cNm/6JWEnxG2xX
Pk7RQ4j6ObbJ/v6FuwhDwIpbRF1zRaDAHPa8zm30AgBTwH/U/YfgDEtAzI1/lzfe
oct21pxonj5fyq9fR530MAzAlDmal/N89xxWz0VgTQIDAQABo4HXMIHUMA4GA1Ud
DwEB/wQEAwIE8DBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vd3d3LmVxdWlmYXhz
ZWN1cmUuY29tL2VidXNpbmVzc2lkL2NybC9zbWltZTY0Yi5jcmwwdgYDVR0gBG8w
bTBrBglghkgBhvpMAQEwXjAXBggrBgEFBQcCAjALMAcWADADAgEBGgAwQwYIKwYB
BQUHAgEWN2h0dHA6Ly93d3cuZXF1aWZheHNlY3VyZS5jb20vZWJ1c2luZXNzaWQv
c21pbWVfY3BzLmh0bWwwDQYJKoZIhvcNAQEEBQADgYEAXkOQjJRTVBCvyZkFfqeY
/t500W2D2BOqe9eFQKnvpgqlWNVRCc5btJINrabnzY2gt6ZvV1nJ+hJB/GIxFQn5
sa1awWWUZmezi89pxR9bPQoDuj9bsvNuxDYrcofKBkoA0w097OestfcqLVA0Qkdr
k1Cny2TXgUEncMAfVp8b54wwggLGMIICL6ADAgECAhAyUUtmqxxV37wOus3CAbYI
MA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u
MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAxMTAxMDAw
MDAwWhcNMDIxMDMxMjM1OTU5WjBMMQswCQYDVQQGEwJVUzEbMBkGA1UEChMSRXF1
aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4IFNlY3VyZSBFbWFpbCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnmf+Gzg6AUfgU5XrJvA3dpKo
bSG3hsbwbnJUfmw19NpjcKaD1dx3i5hU/qvJpZSeUd8eiCYB2VlMM+7LW+PswzQI
8HeY39yxLJGnQmfjukRCYac+z0aG8WIX3a/abmFaWwaji1J5hsDrd+n4D3V7tYqt
43rvAvhd/nupGu4ZXtMCAwEAAaMjMCEwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV
HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAfegBKd5iW9WaDV36QvYAkVeTQDpd
MdmIg76FyOiODY6GskUdJPGufemhagP7t0COvySgATBwDdlQaucH7V4pCZqcSYJ6
XMCOHb+uOJFqe46BXLj6V8GABvJC7SpGOO3wmiIUQgYh74w0ByAV9Aata6xV5fy0
EVDFC5pJ5hwP8C8wggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
IFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0
aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVt
YWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB
0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1m
cmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDU
adfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbq
o925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVL
VX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB
Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+N
YFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+du
AEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WL
DN1RhGvk+NHOd6KBAAAxgDCCAaICAQEwUjBMMQswCQYDVQQGEwJVUzEbMBkGA1UE
ChMSRXF1aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4IFNlY3VyZSBF
bWFpbCBDQQICCRIwCQYFKw4DAhoFAKCBqzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEwMTcwODU4MjNaMCMGCSqGSIb3DQEJBDEW
BBS5uA/sdC2iWM7KjBaqSyoS8gLe4TBMBgkqhkiG9w0BCQ8xPzA9MAcGBSsOAwId
MA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzAHBgUrDgMCBzANBggqhkiG9w0D
AgIBKDANBgkqhkiG9w0BAQEFAASBgIIPzKWhv5zZIDvNi8if6lTSuvfw+zrqhWWd
tvc2+RIm2Nt9hz+loseiCWqxzbSJMEQPhNfI12+Ucl9KmTC1GbQ789v+hcWFX8M7
9Ih5fogrepItPPBbmsIQwHz+VCM5iM++3gpB/Qct/Qg6BQF+AOAd1fuRAaTfG2V7
it0npFo/AAAAAAAAAAA=

---------z64654_boundary_sign--

From slawrence@virata.com  Wed Oct 17 08:40:18 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA09403
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 08:40:18 -0400 (EDT)
From: slawrence@virata.com
Received: from firewall.ma.virata.com (agranat.com [198.113.147.2])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA13387
	for <saag@mit.edu>; Wed, 17 Oct 2001 08:40:17 -0400 (EDT)
Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130])
	by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id IAA30979;
	Wed, 17 Oct 2001 08:39:37 -0400
Received: from oyster.local (dhcp101.ma.virata.com [10.21.0.101])
	by agranat.com (8.9.3/8.9.3) with ESMTP id IAA20856;
	Wed, 17 Oct 2001 08:39:37 -0400
Received: (from lawrence@localhost)
	by oyster.local (8.9.3/8.8.7) id IAA01369;
	Wed, 17 Oct 2001 08:39:33 -0400
X-Authentication-Warning: oyster.local: lawrence set sender to slawrence@virata.com using -f
To: EKR <ekr@rtfm.com>
Cc: slawrence@virata.com,
        IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>,
        saag@mit.edu
Subject: Re: [saag] Re: RFC2817 or RFC2818 ?
References: <LISTMANAGER-5202136-4190-2001.10.16-16.13.31--jpierre#netscape.com@lists.certicom.com>
	<3BCCA72B.E3220918@netscape.com> <82g08j11il.fsf_-_@oyster.local>
	<kjwv1ulxav.fsf@romeo.rtfm.com>
Organization: Virata Corp.
Date: 17 Oct 2001 08:39:33 -0400
In-Reply-To: <kjwv1ulxav.fsf@romeo.rtfm.com>
Message-ID: <821yk2wid6.fsf@oyster.local>
Lines: 36
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla <ekr@rtfm.com> writes:

> What information do you feel should be carried in the URL other than
> the bit of secure or insecure, and why?

We've seen suggestions (from others) in this thread - what CAs
are acceptable and what cipher strengths should be used.  Those issues
were raised when we were reviewing our upgrade drafts, and were among
the problems we didn't 1) have time to solve, 2) need to solve for the
case of switching to a new protocol from HTTP.  We recognized then
that we were not solving the reference integrity problem, but if every
new RFC had to solve every existing problem we'd never progress.

> slawrence@virata.com writes:
> > Personally, I always preferred message-oriented shttp over
> > connection-oriented security, but didn't implement it in my server
> > because it didn't seem to have support in browsers (though it was no
> > better as a security label in URLs).

> I'm not sure what you mean by this. In general S-HTTP carries it's
> security labelling in attributes attached to the anchor, not in the
> URL.  The shttp: is just a signal to do S-HTTP and that you should
> look for security attributes in the anchor. S-HTTP did allow for bare
> shttp: URLs but we always considered that a hack.

That's just another reason (IMHO) why shttp is better.  If you want to
indicate that an address is itself information that should be secured,
then you should so indicate in the message that carries that address,
not in the address itself.  Put another way, putting the security
information in attributes that accompany the URL is better than
trying to pack them into the URL.

-- 
Scott Lawrence                            slawrence@virata.com
Virata Embedded UPnP & Web Technology    http://www.emweb.com/


From moore@cs.utk.edu  Wed Oct 17 09:25:02 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA09870
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 09:25:02 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA26128
	for <saag@mit.edu>; Wed, 17 Oct 2001 09:25:01 -0400 (EDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id f9HDMgP06016;
        Wed, 17 Oct 2001 09:22:47 -0400 (EDT)
Message-Id: <200110171322.f9HDMgP06016@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: EKR <ekr@rtfm.com>
cc: slawrence@virata.com,
        IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>,
        saag@mit.edu
Subject: Re: [saag] Re: RFC2817 or RFC2818 ? 
In-reply-to: Your message of "16 Oct 2001 21:12:24 PDT."
             <kjwv1ulxav.fsf@romeo.rtfm.com> 
Date: Wed, 17 Oct 2001 09:22:42 -0400
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> What information do you feel should be carried in the URL other than
> the bit of secure or insecure, and why?

insecure vs. secure seems like the wrong label, since many SSL 
ciphersuites are notoriously insecure, and since in a particular
case the communicating parties might be happy with an insecure
connection.

why don't we think of that bit as TLS vs. non-TLS, and not have
it say anything about security? 

what (I think) this implies is that client and server get to negotiate 
security levels via TLS (with at least some potential to avoid hostile 
downgrading) rather than assume that there is no security at all.  and 
if client and server are both happy with no authentication or no 
encryption, the TLS protocol shouldn't interfere.

Keith

From ekr@rtfm.com  Wed Oct 17 10:08:18 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA10436
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 10:08:18 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12346
	for <saag@mit.edu>; Wed, 17 Oct 2001 10:08:16 -0400 (EDT)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.11.3/8.6.4) with ESMTP id f9HEBuS77197; Wed, 17 Oct 2001 07:11:56 -0700 (PDT)
Message-Id: <200110171411.f9HEBuS77197@romeo.rtfm.com>
To: slawrence@virata.com
cc: IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>,
        saag@mit.edu
Subject: Re: [saag] Re: RFC2817 or RFC2818 ? 
In-reply-to: Your message of "17 Oct 2001 08:39:33 EDT."
             <821yk2wid6.fsf@oyster.local> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 17 Oct 2001 07:11:56 -0700
From: Eric Rescorla <ekr@rtfm.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Eric Rescorla <ekr@rtfm.com> writes:
> 
> > What information do you feel should be carried in the URL other than
> > the bit of secure or insecure, and why?
> 
> We've seen suggestions (from others) in this thread - what CAs
> are acceptable and what cipher strengths should be used. 
SSL knows how to auto-discover most of this information so these
are just optimizations--as opposed to S-HTTP where the one-pass
restriction meant that they absolutely had to be associated with
the URL.

-Ekr


From ekr@rtfm.com  Wed Oct 17 10:13:01 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA10502
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 10:13:00 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04301
	for <saag@mit.edu>; Wed, 17 Oct 2001 10:12:52 -0400 (EDT)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.11.3/8.6.4) with ESMTP id f9HEGSS77216; Wed, 17 Oct 2001 07:16:28 -0700 (PDT)
Message-Id: <200110171416.f9HEGSS77216@romeo.rtfm.com>
To: Keith Moore <moore@cs.utk.edu>
cc: slawrence@virata.com,
        IETF Transport Layer Security WG <ietf-tls@lists.certicom.com>,
        saag@mit.edu
Subject: Re: [saag] Re: RFC2817 or RFC2818 ? 
In-reply-to: Your message of "Wed, 17 Oct 2001 09:22:42 EDT."
             <200110171322.f9HDMgP06016@astro.cs.utk.edu> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 17 Oct 2001 07:16:28 -0700
From: Eric Rescorla <ekr@rtfm.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> why don't we think of that bit as TLS vs. non-TLS, and not have
> it say anything about security? 
That's what HTTPS does now.

> what (I think) this implies is that client and server get to negotiate 
> security levels via TLS (with at least some potential to avoid hostile 
> downgrading) rather than assume that there is no security at all.  and 
> if client and server are both happy with no authentication or no 
> encryption, the TLS protocol shouldn't interfere.
This is why anon DH and the export suites are problematic, since
they are both subject to active downgrade attacks. Anon DH is
relatively easy to handle at the policy level. If the client
is willing to accept it then it's presumably fine. However, 
it used to be necessary to suppport export cipher suites for
interoperability reasons and SSL is subject to active downgrade
to export cipher suites if the attacker is really powerful. I
agree with David that banning export might be a good idea.

-Ekr



From david.hopwood@zetnet.co.uk  Wed Oct 17 00:12:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id AAA07272
	for <saag@jis.mit.edu>; Wed, 17 Oct 2001 00:12:38 -0400 (EDT)
Received: from zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA23519
	for <saag@MIT.EDU>; Wed, 17 Oct 2001 00:12:37 -0400 (EDT)
Received: from zetnet.co.uk (man-s198.dialup.zetnet.co.uk [194.247.45.69])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id f9H4CWB06344;
	Wed, 17 Oct 2001 05:12:32 +0100
Message-ID: <3BCBA417.F30793BC@zetnet.co.uk>
Date: Tue, 16 Oct 2001 04:05:59 +0100
From: David Hopwood <david.hopwood@zetnet.co.uk>
Reply-To: ietf-tls@lists.certicom.com, saag@MIT.EDU
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: ietf-tls@lists.certicom.com, saag@MIT.EDU
References: <LISTMANAGER-3174254-4197-2001.10.16-16.31.16--hopwood#zetnet.co.uk@lists.certicom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [saag] Re: RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

-----BEGIN PGP SIGNED MESSAGE-----

Julien Pierre wrote:
> Eric Rescorla wrote:
> 
> > I don't think you could safely use the string "https:" for this
> > because it creates too many incompatibilities with servers and
> > clients that already expect HTTPS on port 443. Better to use a
> > URL scheme. I suppose "httpt" is free :)
> 
> I agree with you completely. I have been arguing with Scott in the
> past on the IETF HTTP working group mailing list that a new URL
> scheme was required to tell HTTP clients that they need to first
> connect insecurely and then upgrade to TLS from a URL.

There is another advantage to defining a new URL scheme for this:
use of that scheme could imply that strong encryption is required
(i.e. not export or single-DES or anon-DH or MAC-only ciphersuites).
Possibly it could also imply forward secrecy, and a minimum TLS
version number. Since all clients that support httpt will be new,
and since the old export restrictions are not relevent for new
clients, there is no reason not to require this.

Of course this does not solve all possible problems that could lead
to negotiating an inadequate security level (the client could be
configured to accept untrustworthy CAs, for example). However, it
allows you to say a lot more about what can go wrong and what can't.

> Unfortunately, as simple as the solution is, I haven't found any
> support for it to make it a standard, ...

I'd support it. I've always thought that RFC 2817 was broken. In
particular, the following text from the Security Considerations section:

# The potential for a man-in-the-middle attack (deleting the Upgrade
# header) remains the same as current, mixed http/https practice:
#
# o  Removing the Upgrade header is similar to rewriting web pages to
#    change https:// links to http:// links.
# o  [other points snipped]

is simply wrong, since it doesn't take into account that the URL may
have been authenticated. That will be true if it was received in
another secure communication (possibly HTTP over SSL/TLS, possibly
not), or by some difficult-to-attack out-of-band mechanism.

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBO8ujrjkCAxeYt5gVAQHfjQgAjoUXkHstV24f+w+81pAsaxFNpqwzq4gH
hR8vnjPfugsGmcmgrtXn1BkvAcUkGfXD0qBg7+Tizwwh7Wua0yG3ZMzJhYR7eZ0C
qzjQyFlAkNG1BIPsFcHCcfgeKu3Rv+ypswj9ZqCO/5Oz95euiMwBBQ33lUm3Lm8I
BH0W94vMRwBMVQUEwCCRk6dRezlZHCp1v1ookvloAkGNDaKFV+Wtxju2wNlSyaEw
RX/sK4pHI1ObX4KTnbqIdVSvHTfPuf34aE+nQbduWSDWu4qwwrZQD2p7SVsDItvY
26SoVYM+Awn2TIuu/ZIDv4+VnnwdfagARIgP8HawQ2ZshXX2KvXJrQ==
=FrCa
-----END PGP SIGNATURE-----



From paulfordh@uk.ibm.com  Mon Oct 22 09:09:28 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA25578
	for <saag@jis.mit.edu>; Mon, 22 Oct 2001 09:09:27 -0400 (EDT)
Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA19874
	for <saag@mit.edu>; Mon, 22 Oct 2001 09:09:25 -0400 (EDT)
Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148])
	by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id NAA88654
	for <saag@mit.edu>; Mon, 22 Oct 2001 13:49:31 +0100
Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16])
	by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f9MD705166996
	for <saag@mit.edu>; Mon, 22 Oct 2001 14:07:00 +0100
To: saag@mit.edu
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
From: "Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com>
Message-ID: <OFE3E926F2.F50C8AA1-ON80256AED.0046F19D@portsmouth.uk.ibm.com>
Date: Mon, 22 Oct 2001 14:06:59 +0100
X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.8 |June 18, 2001) at
 22/10/2001 14:06:59,
	Serialize complete at 22/10/2001 14:06:59
Content-Type: text/plain; charset="us-ascii"
Subject: [saag] Re: RFC2817 or RFC2818 ?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla wrote:

>"Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com> writes:
>> I was under the impression that the IETF direction was to negotiate SSL
>> within an application exchange (RFC2817 for http) and not perform SSL
>> blindly upon connection (RFC2818).
>>
>> (Quote from RFC 2817
>> "At the Washington DC IETF meeting in December 1997, the Applications
>>    Area Directors and the IESG reaffirmed that the practice of issuing
>>    parallel "secure" port numbers should be deprecated. The HTTP/1.1
>>    Upgrade mechanism can apply Transport Layer Security [6] to an open
>>    HTTP connection.")
>That's the official word, yes.

In which case, why does (for example) draft-ietf-rap-cops-tls-02.txt 
specify TLS upon connection on a different port and why has it been 
allocated a separate port number (3183) by IANA within the last six 
months.

Is there any way (or will) to enforce, encourage or publicise the 
'official word' ?

Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh@uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html



From keith@rucus.ru.ac.za  Mon Oct 29 11:55:05 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA26921
	for <saag@jis.mit.edu>; Mon, 29 Oct 2001 11:55:05 -0500 (EST)
Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA08308
	for <saag@MIT.EDU>; Mon, 29 Oct 2001 11:55:02 -0500 (EST)
Received: (qmail 93657 invoked by uid 283); 29 Oct 2001 16:54:53 -0000
Date: Mon, 29 Oct 2001 18:54:53 +0200
From: Keith Burdis <keith@rucus.ru.ac.za>
To: saag@MIT.EDU
Subject: Re: [ietf-tls] Re: [saag] Re: RFC2817 or RFC2818 ?
Message-ID: <20011029185453.A52445@rucus.ru.ac.za>
Mail-Followup-To: Keith Burdis <keith@rucus.ru.ac.za>, saag@MIT.EDU
References: <LISTMANAGER-5202136-4190-2001.10.16-16.13.31--jpierre#netscape.com@lists.certicom.com> <3BCCA72B.E3220918@netscape.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3BCCA72B.E3220918@netscape.com>; from jpierre@netscape.com on Tue, Oct 16, 2001 at 02:31:24PM -0700
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Tue 2001-10-16 (14:31), Julien Pierre wrote:
> Eric,
> 
> Eric Rescorla wrote:
> 
> > I don't think you could safely use the string "https:" for this because
> > it creates too many incompatibilities with servers and clients that
> > already expect HTTPS on port 443. Better to use a URL scheme. I suppose
> > "httpt" is free :)
> 
> I agree with you completely. I have been arguing with Scott in the past on
> the IETF HTTP working group mailing list that a new URL scheme was
> required to tell HTTP clients that they need to first connect insecurely
> and then upgrade to TLS from a URL. In fact "httpt" is exactly the same
> URL scheme I proposed over a year ago, but it was rejected. As a result I
> just decided to leave the TLS upgrade support out of the product which
> eventually became the Netscape/iPlanet web server 6.0 . It could have been
> easily implemented but the specification was not good enough for practical
> deployment.

 [SNIP]
 
> I think the problem could be easily resolved simply by adding a new URL
> scheme (such as httpt:// ) which would mean to the client : send the host
> header to this server with HTTP, then upgrade the connection to TLS and
> proceed with the request securely, in much of the fashion as with https
> (same protocols/ciphers/etc). This would resolve the huge ambiguity that
> exists today in the proposed TLS upgrade scheme.

Could this be extended to support an upgrade to something other than TLS? In
particular I have in mind SASL with a security layer. Or would another URL
scheme be needed for this?
 
  - Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras					JAPH 	QEFH
---

From ekr@rtfm.com  Tue Oct 30 10:30:04 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA25997
	for <saag@jis.mit.edu>; Tue, 30 Oct 2001 10:30:04 -0500 (EST)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA18862
	for <saag@mit.edu>; Tue, 30 Oct 2001 10:29:58 -0500 (EST)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id f9UFT5930935; Tue, 30 Oct 2001 07:29:05 -0800 (PST)
To: Keith Burdis <keith@rucus.ru.ac.za>
Cc: saag@mit.edu
Subject: Re: [ietf-tls] Re: [saag] Re: RFC2817 or RFC2818 ?
References: <LISTMANAGER-5202136-4190-2001.10.16-16.13.31--jpierre#netscape.com@lists.certicom.com> <3BCCA72B.E3220918@netscape.com> <20011029185453.A52445@rucus.ru.ac.za>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 30 Oct 2001 07:29:05 -0800
In-Reply-To: Keith Burdis's message of "Mon, 29 Oct 2001 18:54:53 +0200"
Message-ID: <kjzo69du4e.fsf@romeo.rtfm.com>
Lines: 47
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Keith Burdis <keith@rucus.ru.ac.za> writes:

> On Tue 2001-10-16 (14:31), Julien Pierre wrote:
> > Eric,
> > 
> > Eric Rescorla wrote:
> > 
> > > I don't think you could safely use the string "https:" for this because
> > > it creates too many incompatibilities with servers and clients that
> > > already expect HTTPS on port 443. Better to use a URL scheme. I suppose
> > > "httpt" is free :)
> > 
> > I agree with you completely. I have been arguing with Scott in the past on
> > the IETF HTTP working group mailing list that a new URL scheme was
> > required to tell HTTP clients that they need to first connect insecurely
> > and then upgrade to TLS from a URL. In fact "httpt" is exactly the same
> > URL scheme I proposed over a year ago, but it was rejected. As a result I
> > just decided to leave the TLS upgrade support out of the product which
> > eventually became the Netscape/iPlanet web server 6.0 . It could have been
> > easily implemented but the specification was not good enough for practical
> > deployment.
> 
>  [SNIP]
>  
> > I think the problem could be easily resolved simply by adding a new URL
> > scheme (such as httpt:// ) which would mean to the client : send the host
> > header to this server with HTTP, then upgrade the connection to TLS and
> > proceed with the request securely, in much of the fashion as with https
> > (same protocols/ciphers/etc). This would resolve the huge ambiguity that
> > exists today in the proposed TLS upgrade scheme.
> 
> Could this be extended to support an upgrade to something other than TLS? In
> particular I have in mind SASL with a security layer. Or would another URL
> scheme be needed for this?
You'd probably need another URL scheme, for several reasons:

(1) You really want the client to pipeline the Upgrade request with the
TLS ClientHello. This is safe if you know that the server speaks TLS
and removes one RTT of latency.

(2) Otherwise an attacker might be able to force you to negotiate 
either TLS or SASL which is a potential source of downgrade attack.
You could presumably have some kind of check of this after the security
layer had been negotiated but since SASL contains some rather weak
mechanisms I don't think this could be done safely.

-Ekr

From narten@us.ibm.com  Tue Nov  6 14:59:08 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA25888
	for <saag@jis.mit.edu>; Tue, 6 Nov 2001 14:59:08 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08569
	for <saag@mit.edu>; Tue, 6 Nov 2001 14:59:01 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA11468
	for <saag@mit.edu>; Tue, 6 Nov 2001 13:56:24 -0600
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA6Jx0N224830
	for <saag@mit.edu>; Tue, 6 Nov 2001 14:59:00 -0500
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.9.3/8.9.3) with ESMTP id OAA06844
	for <saag@mit.edu>; Tue, 6 Nov 2001 14:58:37 -0500
Message-Id: <200111061958.OAA06844@rotala.raleigh.ibm.com>
To: saag@mit.edu
Date: Tue, 06 Nov 2001 14:58:37 -0500
From: Thomas Narten <narten@us.ibm.com>
Subject: [saag] Home Address Option in MIPv6
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I'd like for the security community to give some thought to the
following issue.  Mobile IPv6 (draft-ietf-mobileip-ipv6-14.txt)
defines an option called a Home Address Option. It is designed to
allow mobile nodes to circumvent problems caused by ingress
filtering.

The reason for asking saag now is that there has been a lot of recent
focus on security issues related to MIPv6's use of the Binding Update
option (see draft-ietf-mobileip-mipv6-scrty-reqts-01.txt).  The topic
of the Home Address option has not received as much attention, and the
authors of that document want to be sure they're not overlooking
anything.

Background:

In MIP, a Mobile Node (MN) has two addresses: a Home Address
(permanent, typically stored in the DNS) and a Care-of Address
(temporary, reflecting the MN's current point of attachment in the
network). A MN can (in theory) send a packet with a source address
equal to the Home Address regardless of where it is connected. In
practice, routers employing ingress filtering may blackhole such
packets, if they come from a topologically incorrect source address.

The Home Address option is an IPv6 destination option that holds the
Home Address of the sending node, so that sending MN can insert the
topologically-correct Care Of Address in the source address of the IP
header.  At the destination, the receiver replaces the source IP
address with the Home Address in the option. Thus, after processing,
the higher layers see a normal IP packet that looks like it was sent
from the MN's Home Address. (Note in particular, that a response to
the packet would be sent to the Home Address unless the receiving node
has a binding in its binding cache to send it directly to the care-of
address. But that is related to the Binding Update in MIP and is
probably not relevant to this note.)

It has been asserted that the Home Address option makes source
address spoofing easier than it already is.  Contrarily, it has
also been asserted that the Home Agent option does not increase the 
vulnerability/risk of source address spoofing.  This depends perhaps
on the amount of ingress filtering that takes place today.

Conceptually, the issues and concerns here seem very similar to what
happens when tunnels are allowed to terminate at arbitrary end
nodes. For example, the packets coming out of the tunnel may not have
source addressess (in the inner header) that have any relation to the
source address in the outer header.

The details of the Home Agent option are discussed in Sections 5.4 and
13.2 of draft-ietf-mobileip-ipv6-14.txt.

draft-savola-ipv6-rh-ha-security-00.txt also discusses some of the
security ramifications.

Questions:

 What sort of checks (if any) should the receiving node perform as
 part of processing the Home Agent option? Is it OK to accept and
 process such packet without applying any types of filters?
 
 Should a node restrict itself to accepting packets with a Home
 Address option from those nodes that it has made prior arrangements
 with?  (e.g., see the recommendation in
 draft-savola-ipv6-rh-ha-security-00.txt)

 Does use of such an option create new avenues for DOS attacks (e.g.,
 reflectors attacks, etc.) or other problems that need consideration?

 In the case of tunneling, I would expect that there is a fair amount
 of existing practice in terms of what sort of filtering/processing
 rules should take place at tunnel egress points. Are the same types
 of processing rules needed in the case of processing received Home
 Agent options? If so, what are those rules?

 The general question here is whether use of the Home Address option
 is safe enough to implement in arbitrary notes, and if not, what can
 be done to make it safe enough for general use.

Thomas 

From Marc.Blanchet@viagenie.qc.ca  Tue Nov  6 20:39:40 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA29543
	for <saag@jis.mit.edu>; Tue, 6 Nov 2001 20:39:40 -0500 (EST)
Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA22857
	for <saag@mit.edu>; Tue, 6 Nov 2001 20:39:40 -0500 (EST)
Received: from viagenie.qc.ca (boitepostale.viagenie.qc.ca [206.123.31.3])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id fA71l6a81756;
	Tue, 6 Nov 2001 20:47:06 -0500 (EST)
Message-ID: <3BE89170.1000504@viagenie.qc.ca>
Date: Tue, 06 Nov 2001 20:42:08 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.4) Gecko/20011025
X-Accept-Language: fr-ca, fr, en, en-us
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
CC: saag@mit.edu
Subject: Re: [saag] Home Address Option in MIPv6
References: <200111061958.OAA06844@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Thomas Narten wrote:

> I'd like for the security community to give some thought to the
> following issue.  Mobile IPv6 (draft-ietf-mobileip-ipv6-14.txt)
> defines an option called a Home Address Option. It is designed to
> allow mobile nodes to circumvent problems caused by ingress
> filtering.
> 
> The reason for asking saag now is that there has been a lot of recent
> focus on security issues related to MIPv6's use of the Binding Update
> option (see draft-ietf-mobileip-mipv6-scrty-reqts-01.txt).  The topic
> of the Home Address option has not received as much attention, and the
> authors of that document want to be sure they're not overlooking
> anything.
> 
> Background:
> 
> In MIP, a Mobile Node (MN) has two addresses: a Home Address
> (permanent, typically stored in the DNS) and a Care-of Address
> (temporary, reflecting the MN's current point of attachment in the
> network). A MN can (in theory) send a packet with a source address
> equal to the Home Address regardless of where it is connected. In
> practice, routers employing ingress filtering may blackhole such
> packets, if they come from a topologically incorrect source address.
> 
> The Home Address option is an IPv6 destination option that holds the
> Home Address of the sending node, so that sending MN can insert the
> topologically-correct Care Of Address in the source address of the IP
> header.  At the destination, the receiver replaces the source IP
> address with the Home Address in the option. Thus, after processing,
> the higher layers see a normal IP packet that looks like it was sent
> from the MN's Home Address. (Note in particular, that a response to
> the packet would be sent to the Home Address unless the receiving node
> has a binding in its binding cache to send it directly to the care-of
> address. But that is related to the Binding Update in MIP and is
> probably not relevant to this note.)
> 
> It has been asserted that the Home Address option makes source
> address spoofing easier than it already is.  Contrarily, it has
> also been asserted that the Home Agent option does not increase the 


Thomas, just to make sure:  s/Home Agent/Home Address/  ?


> vulnerability/risk of source address spoofing.  This depends perhaps
> on the amount of ingress filtering that takes place today.
> 
> Conceptually, the issues and concerns here seem very similar to what
> happens when tunnels are allowed to terminate at arbitrary end
> nodes. For example, the packets coming out of the tunnel may not have
> source addressess (in the inner header) that have any relation to the
> source address in the outer header.
> 
> The details of the Home Agent option are discussed in Sections 5.4 and


s/Home Agent/Home Address


> 13.2 of draft-ietf-mobileip-ipv6-14.txt.
> 
> draft-savola-ipv6-rh-ha-security-00.txt also discusses some of the
> security ramifications.
> 
> Questions:
> 
>  What sort of checks (if any) should the receiving node perform as
>  part of processing the Home Agent option? Is it OK to accept and


s/Home Agent/Home Address/


>  process such packet without applying any types of filters?
>  
>  Should a node restrict itself to accepting packets with a Home
>  Address option from those nodes that it has made prior arrangements
>  with?  (e.g., see the recommendation in
>  draft-savola-ipv6-rh-ha-security-00.txt)
> 
>  Does use of such an option create new avenues for DOS attacks (e.g.,
>  reflectors attacks, etc.) or other problems that need consideration?
> 
>  In the case of tunneling, I would expect that there is a fair amount
>  of existing practice in terms of what sort of filtering/processing
>  rules should take place at tunnel egress points. Are the same types
>  of processing rules needed in the case of processing received Home
>  Agent options? If so, what are those rules?
> 
>  The general question here is whether use of the Home Address option
>  is safe enough to implement in arbitrary notes, and if not, what can
>  be done to make it safe enough for general use.
> 
> Thomas 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag
> 




From narten@us.ibm.com  Tue Nov  6 21:23:15 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA00127
	for <saag@jis.mit.edu>; Tue, 6 Nov 2001 21:23:15 -0500 (EST)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA05990
	for <saag@mit.edu>; Tue, 6 Nov 2001 21:23:14 -0500 (EST)
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id fA72Nk002651;
	Tue, 6 Nov 2001 21:23:46 -0500
Message-Id: <200111070223.fA72Nk002651@cichlid.adsl.duke.edu>
To: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
cc: saag@mit.edu
Subject: Re: [saag] Home Address Option in MIPv6 
In-Reply-To: Message from Marc Blanchet <Marc.Blanchet@viagenie.qc.ca> 
   of "Tue, 06 Nov 2001 20:42:08 EST." <3BE89170.1000504@viagenie.qc.ca> 
Date: Tue, 06 Nov 2001 21:23:46 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hi Marc.

> Thomas, just to make sure:  s/Home Agent/Home Address/  ?

Yes, everywhere you cited. (I don't believe there is even a Home Agent
Option!).

Corrected text below for completeness.

Thomas

I'd like for the security community to give some thought to the
following issue.  Mobile IPv6 (draft-ietf-mobileip-ipv6-14.txt)
defines an option called a Home Address Option. It is designed to
allow mobile nodes to circumvent problems caused by ingress
filtering.

The reason for asking saag now is that there has been a lot of recent
focus on security issues related to MIPv6's use of the Binding Update
option (see draft-ietf-mobileip-mipv6-scrty-reqts-01.txt).  The topic
of the Home Address option has not received as much attention, and the
authors of that document want to be sure they're not overlooking
anything.

Background:

In MIP, a Mobile Node (MN) has two addresses: a Home Address
(permanent, typically stored in the DNS) and a Care-of Address
(temporary, reflecting the MN's current point of attachment in the
network). A MN can (in theory) send a packet with a source address
equal to the Home Address regardless of where it is connected. In
practice, routers employing ingress filtering may blackhole such
packets, if they come from a topologically incorrect source address.

The Home Address option is an IPv6 destination option that holds the
Home Address of the sending node, so that sending MN can insert the
topologically-correct Care Of Address in the source address of the IP
header.  At the destination, the receiver replaces the source IP
address with the Home Address in the option. Thus, after processing,
the higher layers see a normal IP packet that looks like it was sent
from the MN's Home Address. (Note in particular, that a response to
the packet would be sent to the Home Address unless the receiving node
has a binding in its binding cache to send it directly to the care-of
address. But that is related to the Binding Update in MIP and is
probably not relevant to this note.)

It has been asserted that the Home Address option makes source
address spoofing easier than it already is.  Contrarily, it has
also been asserted that the Home Address option does not increase the 
vulnerability/risk of source address spoofing.  This depends perhaps
on the amount of ingress filtering that takes place today.

Conceptually, the issues and concerns here seem very similar to what
happens when tunnels are allowed to terminate at arbitrary end
nodes. For example, the packets coming out of the tunnel may not have
source addressess (in the inner header) that have any relation to the
source address in the outer header.

The details of the Home Address option are discussed in Sections 5.4 and
13.2 of draft-ietf-mobileip-ipv6-14.txt.

draft-savola-ipv6-rh-ha-security-00.txt also discusses some of the
security ramifications.

Questions:

 What sort of checks (if any) should the receiving node perform as
 part of processing the Home Address option? Is it OK to accept and
 process such packet without applying any types of filters?
 
 Should a node restrict itself to accepting packets with a Home
 Address option from those nodes that it has made prior arrangements
 with?  (e.g., see the recommendation in
 draft-savola-ipv6-rh-ha-security-00.txt)

 Does use of such an option create new avenues for DOS attacks (e.g.,
 reflectors attacks, etc.) or other problems that need consideration?

 In the case of tunneling, I would expect that there is a fair amount
 of existing practice in terms of what sort of filtering/processing
 rules should take place at tunnel egress points. Are the same types
 of processing rules needed in the case of processing received Home
 Address options? If so, what are those rules?

 The general question here is whether use of the Home Address option
 is safe enough to implement in arbitrary notes, and if not, what can
 be done to make it safe enough for general use.

 

From rgm-sec@htt-consult.com  Wed Nov  7 08:57:05 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA06412
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 08:57:05 -0500 (EST)
Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id IAA28124
	for <saag@mit.edu>; Wed, 7 Nov 2001 08:57:04 -0500 (EST)
Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 07 Nov 2001 08:57:04 -0500
Message-Id: <5.1.0.14.2.20011107083515.01f49058@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 08:56:23 -0500
To: saag@mit.edu
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [saag] Standards for Key Derivation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At the NIST Key Management Schemes workshop last week (www.nist.gov/kms), 
there was a lot of discussion on a Key Derivation funciton (sec 6.3 of the 
NIST Schemes doc).

NIST has derived a method from ANSI X9.42 that is quite close to what IKE 
does (RFC 2407), but still different.  As far as I know, IKE is our only 
serious effort at a Key Derivation function.  Discussion on PPPEXT (between 
Aboba and me, some discussion :), points out a value to have a Key 
Derivation function standard.

At the NIST meeting (Tim Polk and Russ Housley were there too), there was 
an interest to include another good kdf.

It seems to me that we can look at the methodology in the NIST doc and the 
algorithms in 2407 and develop the IETF kdf.  Is there interest in doing this?

There are two key differences between the 9.42 and 2407 methods.  2407 uses 
HMAC instead of a HASH.  2407 feeds Ki into K(i+1).   There are also order 
differences in the two funcitons.

With the work for IKEv2 and new EAP types like SRP (which in 2945 has a 
totally different kdf), it might be worthwhile for some of those here to 
put forth a IETF kdf for all IETF work and for inclusion in the NIST schemes.

btw, the importance of the NIST schemes is it will influence gov 
procurement, so it is "worht' paying attention to....

Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com


From gdt@ir.bbn.com  Wed Nov  7 09:08:52 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA06639
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:08:52 -0500 (EST)
Received: from fnord.ir.bbn.com (FNORD.IR.BBN.COM [192.1.100.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA01602
	for <saag@mit.edu>; Wed, 7 Nov 2001 09:08:52 -0500 (EST)
Received: by fnord.ir.bbn.com (Postfix, from userid 10853)
	id A9AC13C28; Wed,  7 Nov 2001 09:08:51 -0500 (EST)
To: Thomas Narten <narten@us.ibm.com>
Cc: saag@mit.edu
Subject: Re: [saag] Home Address Option in MIPv6
References: <200111070223.fA72Nk002651@cichlid.adsl.duke.edu>
From: Greg Troxel <gdt@fnord.ir.bbn.com>
Date: 07 Nov 2001 09:08:51 -0500
In-Reply-To: Thomas Narten's message of "Tue, 06 Nov 2001 21:23:46 -0500"
Message-ID: <rmi4ro6y8p8.fsf@fnord.ir.bbn.com>
Lines: 57
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

  In
  practice, routers employing ingress filtering may blackhole such
  packets, if they come from a topologically incorrect source address.

In the typical case of a border router between the greater Internet
and an organization's internal network, packets arriving from the
Internet with source addresses that belong on the inside are dropped,
since they are "obviously" fraudulent (except for Mobile IP, of
course), and because such forged packets might cause hosts that rely
solely on the source IP address of an incoming packet (with no
cryptographic authentication) to take undesired actions.  When
combined with a means to guess the initial sequence number of a TCP
connection, such packets could be used to inject commands via rsh.

  It has been asserted that the Home Address option makes source
  address spoofing easier than it already is.  Contrarily, it has
  also been asserted that the Home Address option does not increase the 
  vulnerability/risk of source address spoofing.  This depends perhaps
  on the amount of ingress filtering that takes place today.

I suspect that it also depends on whether one views ingress filtering
as an architecturally sensible strategy or a kludge to work around
hosts that take action based on the source address of packets without
any means of authentication.  If one accepts ingress filtering as a
reasonable strategy, then it seems that the Home Address option does
make these attacks easier if the Home Address carried in the option is
used for access control checks.  Given your description, it seems
clear that the address has already been replaced by the time TCP or
UDP see the packet, so this seems to the case.

One strategy is for a receiver to process the Home Address option only
if a matching authenticated binding is already installed (mapping the
Home Address in the option to the original source address in the
packet).  The negotiation for the security association protecting the
binding request could be carried out using the on-link address of the
MN, or there could be a bypass mechanism for IKE to receive packets
with the Home Address option even before an authenticated binding is
installed.

Another strategy is for the receiver to refrain from making decisions
based on unauthenticated source address.

It would be nice to retain the original source address for use in
logging (e.g. when receiving a SYN for a port that is not open).
This is probably not very important if the authentication scheme is used.

I believe that not only ingress filtering but also egress filtering
should be considered.  Egress filtering has a different motivation,
which is for an organization to avoid being a source of forged
packets.  Here, outbound packets whose source addresses do not belong
inside are dropped (the opposite test, in the opposite direction).
Here, a packet is leaving with a source address that is correct, and
a claimed source address via the option.  Hence, there is no
untraceable fraud, and the motivation doesn't really apply.


        Greg Troxel <gdt@ir.bbn.com>

From warlord@MIT.EDU  Wed Nov  7 09:19:47 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA06781
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:19:46 -0500 (EST)
Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA05544
	for <saag@mit.edu>; Wed, 7 Nov 2001 09:19:46 -0500 (EST)
Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3)
	id JAA00668; Wed, 7 Nov 2001 09:19:28 -0500
To: Greg Troxel <gdt@fnord.ir.bbn.com>
Cc: Thomas Narten <narten@us.ibm.com>, saag@MIT.EDU
Subject: Re: [saag] Home Address Option in MIPv6
References: <200111070223.fA72Nk002651@cichlid.adsl.duke.edu> <rmi4ro6y8p8.fsf@fnord.ir.bbn.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 07 Nov 2001 09:19:28 -0500
In-Reply-To: Greg Troxel's message of "07 Nov 2001 09:08:51 -0500"
Message-ID: <sjmofmell3j.fsf@benjamin.ihtfp.org>
Lines: 89
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Another option: If the MN and Correspondant node have _any_ IPsec SA
setup, (even AH), then you are "safe".  The reason is that you can
just create the SA using the Home Address.  Then as you move around,
you can verify that the Home Address option is correct.  Keep in mind
that the Home Address is "static", and quite clearly you "own" the
address.  So, authenticating that address is easy.

Binding updates are a completely different problem:  they are
ephemeral and, in general, you do NOT "own" that address when you
borrow it.  The question about authenticating a binding update
is: how do you prove that you have the authorization to use that
care-of address?

One option off the top of my head is to get a signed authorization
from the "network" when you obtain your CO Address.  The signature
could be for as long as the lease-time, and you just get new
authorizations as the lease is renewed.

-derek

Greg Troxel <gdt@fnord.ir.bbn.com> writes:

>   In
>   practice, routers employing ingress filtering may blackhole such
>   packets, if they come from a topologically incorrect source address.
> 
> In the typical case of a border router between the greater Internet
> and an organization's internal network, packets arriving from the
> Internet with source addresses that belong on the inside are dropped,
> since they are "obviously" fraudulent (except for Mobile IP, of
> course), and because such forged packets might cause hosts that rely
> solely on the source IP address of an incoming packet (with no
> cryptographic authentication) to take undesired actions.  When
> combined with a means to guess the initial sequence number of a TCP
> connection, such packets could be used to inject commands via rsh.
> 
>   It has been asserted that the Home Address option makes source
>   address spoofing easier than it already is.  Contrarily, it has
>   also been asserted that the Home Address option does not increase the 
>   vulnerability/risk of source address spoofing.  This depends perhaps
>   on the amount of ingress filtering that takes place today.
> 
> I suspect that it also depends on whether one views ingress filtering
> as an architecturally sensible strategy or a kludge to work around
> hosts that take action based on the source address of packets without
> any means of authentication.  If one accepts ingress filtering as a
> reasonable strategy, then it seems that the Home Address option does
> make these attacks easier if the Home Address carried in the option is
> used for access control checks.  Given your description, it seems
> clear that the address has already been replaced by the time TCP or
> UDP see the packet, so this seems to the case.
> 
> One strategy is for a receiver to process the Home Address option only
> if a matching authenticated binding is already installed (mapping the
> Home Address in the option to the original source address in the
> packet).  The negotiation for the security association protecting the
> binding request could be carried out using the on-link address of the
> MN, or there could be a bypass mechanism for IKE to receive packets
> with the Home Address option even before an authenticated binding is
> installed.
> 
> Another strategy is for the receiver to refrain from making decisions
> based on unauthenticated source address.
> 
> It would be nice to retain the original source address for use in
> logging (e.g. when receiving a SYN for a port that is not open).
> This is probably not very important if the authentication scheme is used.
> 
> I believe that not only ingress filtering but also egress filtering
> should be considered.  Egress filtering has a different motivation,
> which is for an organization to avoid being a source of forged
> packets.  Here, outbound packets whose source addresses do not belong
> inside are dropped (the opposite test, in the opposite direction).
> Here, a packet is leaving with a source address that is correct, and
> a claimed source address via the option.  Hence, there is no
> untraceable fraud, and the motivation doesn't really apply.
> 
> 
>         Greg Troxel <gdt@ir.bbn.com>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From gdt@fnord.ir.bbn.com  Wed Nov  7 09:30:11 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA06909
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:30:11 -0500 (EST)
Received: from fnord.ir.bbn.com (FNORD.IR.BBN.COM [192.1.100.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA09228;
	Wed, 7 Nov 2001 09:30:11 -0500 (EST)
Received: from fnord.ir.bbn.com (localhost [127.0.0.1])
	by fnord.ir.bbn.com (Postfix) with ESMTP
	id 135FE3C21; Wed,  7 Nov 2001 09:30:11 -0500 (EST)
From: Greg Troxel <gdt@ir.bbn.com>
To: Derek Atkins <warlord@mit.edu>
Cc: Thomas Narten <narten@us.ibm.com>, saag@mit.edu
Subject: Re: [saag] Home Address Option in MIPv6 
In-Reply-To: Message from Derek Atkins <warlord@MIT.EDU> 
   of "07 Nov 2001 09:19:28 EST." <sjmofmell3j.fsf@benjamin.ihtfp.org> 
Date: Wed, 07 Nov 2001 09:30:11 -0500
Message-Id: <20011107143011.135FE3C21@fnord.ir.bbn.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

  Binding updates are a completely different problem:  they are
  ephemeral and, in general, you do NOT "own" that address when you
  borrow it.  The question about authenticating a binding update
  is: how do you prove that you have the authorization to use that
  care-of address?

You don't need to, since that doesn't address the threat we care
about.  The real need is for the MN to prove to the HA that it is the
MN requesting that the MN's packets be sent someplace unusual, to
prevent others from stealing the MN's traffic (or stealing and
reinjecting it to effect a MITM attack).  Having an HA send an MN's
packets to someplace random at the request of the MN just isn't in my
threat model.  The typical assumption is that the HA and MN are under
the same administration, so the MN user could log into the HA and spew
at someplace anyway.

I believe the authorization issue you mention is a real problem, but
the enforcement point is at the routers of the visited network, not at
the HA.  After all, the HA and MN could be colluding to use network
service without authorization, so any HA/MN measures can't protect
against this.

From ekr@rtfm.com  Wed Nov  7 09:34:36 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA07005
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:34:34 -0500 (EST)
Received: from romeo.rtfm.com ([198.144.203.242])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA06135
	for <saag@mit.edu>; Wed, 7 Nov 2001 09:34:33 -0500 (EST)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id fA7EXg159375; Wed, 7 Nov 2001 06:33:42 -0800 (PST)
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation
References: <5.1.0.14.2.20011107083515.01f49058@localhost>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 07 Nov 2001 06:33:41 -0800
In-Reply-To: Robert Moskowitz's message of "Wed, 07 Nov 2001 08:56:23 -0500"
Message-ID: <kjn11yr6pm.fsf@romeo.rtfm.com>
Lines: 11
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Robert Moskowitz <rgm-sec@htt-consult.com> writes:
> NIST has derived a method from ANSI X9.42 that is quite close to what IKE 
> does (RFC 2407), but still different.  As far as I know, IKE is our only 
> serious effort at a Key Derivation function.
TLS (RFC 2246) contains a KDF (called PRF there) as well.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/

From warlord@MIT.EDU  Wed Nov  7 09:41:39 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA07117
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:41:39 -0500 (EST)
Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA13717
	for <saag@MIT.EDU>; Wed, 7 Nov 2001 09:41:38 -0500 (EST)
Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3)
	id JAA00757; Wed, 7 Nov 2001 09:41:38 -0500
To: Greg Troxel <gdt@ir.bbn.com>
Cc: Thomas Narten <narten@us.ibm.com>, saag@MIT.EDU
Subject: Re: [saag] Home Address Option in MIPv6
References: <20011107143011.135FE3C21@fnord.ir.bbn.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 07 Nov 2001 09:41:37 -0500
In-Reply-To: Greg Troxel's message of "Wed, 07 Nov 2001 09:30:11 -0500"
Message-ID: <sjmlmhilk2m.fsf@benjamin.ihtfp.org>
Lines: 41
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Greg Troxel <gdt@ir.bbn.com> writes:

>   Binding updates are a completely different problem:  they are
>   ephemeral and, in general, you do NOT "own" that address when you
>   borrow it.  The question about authenticating a binding update
>   is: how do you prove that you have the authorization to use that
>   care-of address?
> 
> You don't need to, since that doesn't address the threat we care
> about.  The real need is for the MN to prove to the HA that it is the
> MN requesting that the MN's packets be sent someplace unusual, to
> prevent others from stealing the MN's traffic (or stealing and
> reinjecting it to effect a MITM attack).  Having an HA send an MN's
> packets to someplace random at the request of the MN just isn't in my
> threat model.  The typical assumption is that the HA and MN are under
> the same administration, so the MN user could log into the HA and spew
> at someplace anyway.

Greg, I think you misunderstood.  Binding updates don't bring a Home
Agent into the picture.  A Binding Update is between a Mobile Node and
a Correspondant Node, which tells the CN "hey, I just changed Care-Of
addresses -- send my packets to this new address now".  You don't need
a Home Agent to effect this MitM attack!  Indeed, without any
protection I could get _your_ traffic from any particular CN rerouted
to my host regardless of where I'm located!

> I believe the authorization issue you mention is a real problem, but
> the enforcement point is at the routers of the visited network, not at
> the HA.  After all, the HA and MN could be colluding to use network
> service without authorization, so any HA/MN measures can't protect
> against this.

That is not sufficient to protect against the aforementioned attack.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From gdt@fnord.ir.bbn.com  Wed Nov  7 09:56:49 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA07348
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:56:49 -0500 (EST)
Received: from fnord.ir.bbn.com (FNORD.IR.BBN.COM [192.1.100.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA19565;
	Wed, 7 Nov 2001 09:56:49 -0500 (EST)
Received: from fnord.ir.bbn.com (localhost [127.0.0.1])
	by fnord.ir.bbn.com (Postfix) with ESMTP
	id E92A83C21; Wed,  7 Nov 2001 09:56:48 -0500 (EST)
From: Greg Troxel <gdt@ir.bbn.com>
To: Derek Atkins <warlord@mit.edu>
Cc: saag@mit.edu
Subject: Re: [saag] Home Address Option in MIPv6 
In-Reply-To: Your message of "07 Nov 2001 09:41:37 EST."
             <sjmlmhilk2m.fsf@benjamin.ihtfp.org> 
Date: Wed, 07 Nov 2001 09:56:48 -0500
Message-Id: <20011107145648.E92A83C21@fnord.ir.bbn.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I did forget that Binding Updates are to any CH, not just a HA.  And I
didn't mean that BUs don't need to be authenticated at all.  My
understanding is that the current protocol specs call for all binding
updates to be authenticated with AH, but I admit to not having read
them lately.

Clearly, one needs to associate (strongly) the data in the received BU
with the home IP address of the MN, and I think we agree there.  But I
believe that there is no particular need (from the MN or CH point of
view) for authorization to use the care-of address.

So, a message that says (skipping over details that don't matter for
this discussion)

  (send traffic for MN home address X to temporary address Y)
      signed by key Z
      cert binding address X and key Z (issued by someone appropriate...)

is fine.  I was only trying to say that what I thought was _not_
particularly necessary was an additional

      cert saying MN X can use address Y for time T
          signed by some entity authorized to speak for address Y

This is more in the realm of internet-wide DOS protection, rather than
concerns about stealing MN X's traffic.

From rja@inet.org  Wed Nov  7 10:05:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA07481
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 10:05:38 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA23123
	for <saag@mit.edu>; Wed, 7 Nov 2001 10:05:37 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id C336D67103; Wed,  7 Nov 2001 10:08:18 -0500 (EST)
Message-Id: <5.1.0.14.2.20011107095346.00a77ec0@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 09:56:02 -0500
To: Robert Moskowitz <rgm-sec@htt-consult.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu
In-Reply-To: <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 08:56 07/11/01, Robert Moskowitz wrote:
>It seems to me that we can look at the methodology in the NIST doc and the algorithms in 2407 and develop the IETF kdf.  Is there interest in doing this?
>
>There are two key differences between the 9.42 and 2407 methods.  2407 uses HMAC instead of a HASH.  2407 feeds Ki into K(i+1).   There are also order differences in the two funcitons.

        I would be MUCH more inclined to just run with the methodology
that is NIST approved.  There has been significant peer review of that
method to support its validity.  Changing it does not seem worthwhile
to me.  This is an area of some subtlety, so is not a very good place
for IETF to do something different.

        Perhaps I'd just suggest having the appropriate NIST folks
publish their method as an Informational RFC that could be more easily
cited by IETF standards-track documents.

Ran
rja@inet.org




From Basavaraj.Patil@nokia.com  Wed Nov  7 10:10:19 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA07569
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 10:10:19 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20317;
	Wed, 7 Nov 2001 10:10:18 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA7FB0Q25820;
	Wed, 7 Nov 2001 09:11:00 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T57127b3122ac12f255079@davir02nok.americas.nokia.com>;
 Wed, 7 Nov 2001 09:10:18 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 7 Nov 2001 09:10:23 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [saag] Home Address Option in MIPv6
Date: Wed, 7 Nov 2001 09:10:17 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CD04F@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [saag] Home Address Option in MIPv6
Thread-Index: AcFnmk+Wg9NZJdOLEdWpXwBQi2kYTQAA/d4g
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'ext Derek Atkins'" <warlord@mit.edu>,
        "Greg Troxel" <gdt@fnord.ir.bbn.com>
Cc: "Thomas Narten" <narten@us.ibm.com>, <saag@mit.edu>
X-OriginalArrivalTime: 07 Nov 2001 15:10:23.0781 (UTC) FILETIME=[52FBC550:01C1679E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id KAA07569
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Derek Atkins [warlord@mit.edu] wrote:
>Another option: If the MN and Correspondant node have _any_ IPsec SA
>setup, (even AH), then you are "safe".  The reason is that you can
>just create the SA using the Home Address.  Then as you move around,
>you can verify that the Home Address option is correct.  Keep in mind
>that the Home Address is "static", and quite clearly you "own" the
>address.  So, authenticating that address is easy.
>

However there are other issues as documented in
draft-arkko-mipv6-bu-security-00.txt with the use of an IPsec SA to
secure BUs.

>Binding updates are a completely different problem:  they are
>ephemeral and, in general, you do NOT "own" that address when you
>borrow it.  The question about authenticating a binding update
>is: how do you prove that you have the authorization to use that
>care-of address?

There is no issue with authorization as far as the care-of-address ic
concerned. The COA is a dynamic address that is either assigned by the
visiting network or generated as a result of address autoconf.
>
>One option off the top of my head is to get a signed authorization
>from the "network" when you obtain your CO Address.  The signature
>could be for as long as the lease-time, and you just get new
>authorizations as the lease is renewed.
>
>-derek

-Basavaraj

From mcgrew@cisco.com  Wed Nov  7 10:50:03 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA08074
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 10:50:03 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA06287
	for <saag@mit.edu>; Wed, 7 Nov 2001 10:50:02 -0500 (EST)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fA7FnVr18341;
	Wed, 7 Nov 2001 07:49:31 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AAE91165;
	Wed, 7 Nov 2001 07:45:04 -0800 (PST)
Message-ID: <3BE92FA7.BBB20988@cisco.com>
Date: Wed, 07 Nov 2001 07:57:11 -0500
From: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Moskowitz <rgm-sec@htt-consult.com>
CC: saag@mit.edu,
        "Mats =?iso-8859-1?Q?N=E4slund?=" 
	<mats.naslund@era-t.ericsson.se>
Subject: Re: [saag] Standards for Key Derivation
References: <5.1.0.14.2.20011107083515.01f49058@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Robert,

I agree that key derivation is an important topic, and that it would be
good to standardize on a kdf that is generally applicable. 
Unfortunately, I was unable to attend the NIST workshop last week, and
I'm very glad that you're bridging the two standards efforts!  I would
like to see an IETF standard in this area, though I'm not sure that a
single spec could cover all key derivation needs.  Still, providing
guidance even in a subset of cases could be valuable.

The Secure RTP protocol also needs a kdf, and I've been discussing that
function with my srtp compatriots recently.  Also, TLS, SSH, and other
work also includes kdfs.

Section 6.3 of the NIST document is a good start, but is not sufficient
to meet the SRTP requirements.  For SRTP, we need the ability to
generate a sequence of subkeys, given a master key.  We also need to be
able to generate the subkeys out of order (srtp can be multicast, and we
don't want to require members who join the group in the middle to have
to play catch-up).  

Yet another security property that an application might require is the
forward-security property whereby K(i) can't be computed given K(i+1).  

It's interesting that rfc2407 and the NIST work both construct
pseudo-random functions from a particular MAC (in the former case) and a
hash function (in the latter case).  Why not allow the use of a
length-expanding pseudo-random function directly?  Such things exist,
SEAL and Counter Mode being my favorite examples, and in fact both of
those ciphers can easily accommodate the seek-to-any-subkey requirement
mentioned above.

Also, is there a more in-depth explanation of the NIST work than the
one-page description in Section 6.3 of the online document?

thanks,

David

Robert Moskowitz wrote:
> 
> At the NIST Key Management Schemes workshop last week (www.nist.gov/kms),
> there was a lot of discussion on a Key Derivation funciton (sec 6.3 of the
> NIST Schemes doc).
> 
> NIST has derived a method from ANSI X9.42 that is quite close to what IKE
> does (RFC 2407), but still different.  As far as I know, IKE is our only
> serious effort at a Key Derivation function.  Discussion on PPPEXT (between
> Aboba and me, some discussion :), points out a value to have a Key
> Derivation function standard.
> 
> At the NIST meeting (Tim Polk and Russ Housley were there too), there was
> an interest to include another good kdf.
> 
> It seems to me that we can look at the methodology in the NIST doc and the
> algorithms in 2407 and develop the IETF kdf.  Is there interest in doing this?
> 
> There are two key differences between the 9.42 and 2407 methods.  2407 uses
> HMAC instead of a HASH.  2407 feeds Ki into K(i+1).   There are also order
> differences in the two funcitons.
> 
> With the work for IKEv2 and new EAP types like SRP (which in 2945 has a
> totally different kdf), it might be worthwhile for some of those here to
> put forth a IETF kdf for all IETF work and for inclusion in the NIST schemes.
> 
> btw, the importance of the NIST schemes is it will influence gov
> procurement, so it is "worht' paying attention to....
> 
> Robert Moskowitz
> TruSecure Corporation
> Security Interest EMail: rgm-sec@htt-consult.com
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

From MatthewChalmers@firstusa.com  Wed Nov  7 11:20:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08444
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 11:20:37 -0500 (EST)
Received: from pm05sm.rst.cw.net (PM05SM.RST.CW.NET [204.71.247.140])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA22149
	for <saag@mit.edu>; Wed, 7 Nov 2001 11:20:37 -0500 (EST)
Received: from swilnts850.wil.fusa.com (gw1.firstusa.com [206.151.92.65])
 by PM05SM.RST.CW.NET (PMDF V6.0-24 #47875)
 with ESMTP id <0GMF0ALEHUQCO8@PM05SM.RST.CW.NET> for saag@mit.edu; Wed,
 07 Nov 2001 16:20:36 +0000 (GMT)
Received: from swilnts807.wil.fusa.com (unverified) by swilnts850.wil.fusa.com
 (Content Technologies SMTPRS 4.2.5)
 with ESMTP id <T5712f27e79a87604d7488@swilnts850.wil.fusa.com>; Wed,
 07 Nov 2001 11:20:36 -0500
Received: by swilnts807.wil.fusa.com with Internet Mail Service (5.5.2654.52)
	id <WN9S43H7>; Wed, 07 Nov 2001 11:19:01 -0500
Content-return: allowed
Date: Wed, 07 Nov 2001 11:20:06 -0500
From: "Chalmers, Matthew (FUSA)" <MatthewChalmers@firstusa.com>
Subject: RE: [saag] Standards for Key Derivation
To: "'EKR'" <ekr@rtfm.com>, Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: saag@mit.edu
Message-id: <B39104ADF3A0D311878200A0C9B41A1F06CBF5A9@swilnts814.wil.fusa.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-type: text/plain; charset=iso-8859-1
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

One of the questions that came up at the Key Management Workshop was whether
there are any proofs that the output from any existing KDF is 'good' input
to use as a key for an algorithm? That is, is there a proof that shows the
output of TLS' (or SSL's or whatever) KDF would make a good DES key, for
example? Are there situations where the output would be fine for input to
HMAC but not AES, for example? Or is it just generally accepted that the
output of existing KDFs is random enough that it will always serve as good
input for a key? Should weak key tests necessarily be performed on KDF
output?

--
Matthew Chalmers
Information Security
FIRST USA BANK, NA


-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November 07, 2001 9:34 AM
To: Robert Moskowitz
Cc: saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation


Robert Moskowitz <rgm-sec@htt-consult.com> writes:
> NIST has derived a method from ANSI X9.42 that is quite close to what IKE 
> does (RFC 2407), but still different.  As far as I know, IKE is our only 
> serious effort at a Key Derivation function.
TLS (RFC 2246) contains a KDF (called PRF there) as well.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/
_______________________________________________
saag mailing list
saag@mit.edu
http://jis.mit.edu/mailman/listinfo/saag


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************


From rgm-sec@htt-consult.com  Wed Nov  7 11:24:32 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08499
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 11:24:32 -0500 (EST)
Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA24210
	for <saag@mit.edu>; Wed, 7 Nov 2001 11:24:32 -0500 (EST)
Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 07 Nov 2001 11:22:57 -0500
Message-Id: <5.1.0.14.2.20011107111431.01f55808@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 11:16:02 -0500
To: "David A. McGrew" <mcgrew@cisco.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu,
        =?iso-8859-1?Q?=22Mats_N=E4slund=22?=
   <mats.naslund@era-t.ericsson.se>
In-Reply-To: <3BE92FA7.BBB20988@cisco.com>
References: <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id LAA08499
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 07:57 AM 11/7/2001 -0500, David A. McGrew wrote:

>I agree that key derivation is an important topic, and that it would be
>good to standardize on a kdf that is generally applicable.
>Unfortunately, I was unable to attend the NIST workshop last week, and
>I'm very glad that you're bridging the two standards efforts!  I would
>like to see an IETF standard in this area, though I'm not sure that a
>single spec could cover all key derivation needs.  Still, providing
>guidance even in a subset of cases could be valuable.

For those of you that have not gotten around to looking at the NIST schemes 
document, I was sent it in editable format (as they are expecting comments 
from me!), and here is section 6.3:

Function call: kdf(Z,OtherInput), where OtherInput is U, V, keydatalen, 
hashlen, [SharedInfo].

Input description:
1.      A bit string Z that is the shared secret.
2.      Bit strings U and V that denote the identities of the participating 
parties, where U is the party that initiated the key establishment process, 
and V is the responder in the key establishment process.
3.      An integer keydatalen that is the length in bits of the keying 
material to be generated. keydatalen must be less than hashlen ? (232-1).
4.      An integer hashlen that is the length in bits of the hash function 
to be used to derive the keying material.
5.      An optional bit string SharedInfo that consists of data shared by 
parties U and V.
Process:
a. Initiate a 32-bit, big-endian bit string counter as 0000000116.
b. For i=1 to i= , do the following:
         Compute Hashi = H(Z||counter||U||V||[SharedInfo])
         Increment counter
         Increment i.
c. Let Hashj denote Hashj if keydatalen/hashlen is an integer, and let it 
denote the (keydatalen-(hashlen (j-1))) leftmost bits of Hashj otherwise.
d. Set DerivedKeyingMaterial = Hash1||Hash2||…||Hashj-1||Hhashj.
Output: The bit string DerivedKeyingMaterial of keydatalen bits.

[Question: Since both parties need to compute the same derived keying 
material, does the necessity to provide U and V create a problem? For 
example, can all applications determine who the initiator and responder are 
so that they would know in what order to place the identities? Or would it 
be better to alphabetize the identities? Rather than using “U||V”, would it 
be better to use a function of the two entities, such as “(U OR V)||(U AND 
V)”, where “OR” and “AND” are bit-wise logical operators?]

The derived keying material may be parsed into one or more keys or other 
cryptographic keying material (e.g., IVs).

Any scheme attempting to call the key derivation function  for a bit string 
of length greater than or equal to hashlen (232-1) bits must output 
“invalid” and stop.

Note: The security provided by the derived keying material is limited by 
the cryptographic strength of the key establishment scheme. For example, if 
an elliptic curve scheme is used with a 160 bit private key, a strength of 
roughly 80 bits is provided to the derived keying material, i.e., a 128 bit 
AES key derived from such a scheme provides no more than 80 bits of 
security to the information it protects, not the 128 bits of security that 
might be expected when using AES with a truly random key.

Note: This technique differs from the key derivation functions defined in 
ANSI X9.42 and X9.63. In this workshop document, the identities of the 
initiating party (U) and the recipient (V) are included in the data that is 
hashed. In ANSI X9.42 and X9.63, these identities could be considered a 
part of the SharedInfo, which is optional and not defined. ANSI X9.42 also 
includes a second key derivation function that is based on ASN.1 DER encoding.


Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com


From rgm-sec@htt-consult.com  Wed Nov  7 11:24:33 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08504
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 11:24:33 -0500 (EST)
Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA24215
	for <saag@mit.edu>; Wed, 7 Nov 2001 11:24:32 -0500 (EST)
Received: from portege3490.htt-consult.com ([65.84.78.214]) by homebase.htt-consult.com ; Wed, 07 Nov 2001 11:22:58 -0500
Message-Id: <5.1.0.14.2.20011107111603.01eee590@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 11:22:41 -0500
To: "David A. McGrew" <mcgrew@cisco.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu,
        =?iso-8859-1?Q?=22Mats_N=E4slund=22?=
   <mats.naslund@era-t.ericsson.se>
In-Reply-To: <3BE92FA7.BBB20988@cisco.com>
References: <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 07:57 AM 11/7/2001 -0500, David A. McGrew wrote:

>Section 6.3 of the NIST document is a good start, but is not sufficient
>to meet the SRTP requirements.

This could mean a basic kdf and advanced kdfs.

>   For SRTP, we need the ability to generate a sequence of subkeys, given 
> a master key.

I am missing something here.  I thought that is what a kdf is for.  get 
enough bits so you can pull out a bunch of subkeys, in sequence.

>   We also need to be
>able to generate the subkeys out of order (srtp can be multicast, and we
>don't want to require members who join the group in the middle to have
>to play catch-up).

ALmost sounds like a codebook kind of thing, where you have a very large 
random input and at time T you start with bit z.  Just listen to sec 6.3 
warning not to produce more than 2^32-1 bits!

>Yet another security property that an application might require is the
>forward-security property whereby K(i) can't be computed given K(i+1).

I think that is where [SharedInfo] is supposed to kick in.

>It's interesting that rfc2407 and the NIST work both construct
>pseudo-random functions from a particular MAC (in the former case) and a
>hash function (in the latter case).  Why not allow the use of a
>length-expanding pseudo-random function directly?  Such things exist,
>SEAL and Counter Mode being my favorite examples, and in fact both of
>those ciphers can easily accommodate the seek-to-any-subkey requirement
>mentioned above.

Russ Housley was involved with 9.42 and perhaps can address this.  Ask Hugo 
about 2407.

>Also, is there a more in-depth explanation of the NIST work than the
>one-page description in Section 6.3 of the online document?

x9.42, I might think.  in the feb 2000 workshop there was a strong desire 
to focus in on 9.42 and .63


Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com


From smb@research.att.com  Wed Nov  7 11:44:51 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08862
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 11:44:47 -0500 (EST)
Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29444
	for <saag@mit.edu>; Wed, 7 Nov 2001 11:39:48 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id D5A6D7C00; Wed,  7 Nov 2001 11:39:00 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Chalmers, Matthew (FUSA)" <MatthewChalmers@firstusa.com>
Cc: "'EKR'" <ekr@rtfm.com>, Robert Moskowitz <rgm-sec@htt-consult.com>,
        saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 Nov 2001 11:39:00 -0500
Message-Id: <20011107163900.D5A6D7C00@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <B39104ADF3A0D311878200A0C9B41A1F06CBF5A9@swilnts814.wil.fusa.com>, 
"Chalmers, Matthew (FUSA)" writes:
>Should weak key tests necessarily be performed on KDF
>output?
>
As has been pointed out before, weak-key testing is probably a bad 
idea.  The odds on encountering a weak key in practice are vanishingly 
small (1 in 2^52 for DES, as I recall).  That means that the code to 
test for and recover from such keys won't be well-tested, and is more 
likely to break something else.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com



From sblakewilson@certicom.com  Wed Nov  7 12:14:14 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA09336
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 12:14:13 -0500 (EST)
Received: from ns.ca.certicom.com (ip5.certicom.com [209.121.99.5] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA16115
	for <saag@mit.edu>; Wed, 7 Nov 2001 12:14:13 -0500 (EST)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25])
	by ns.ca.certicom.com (Postfix) with SMTP
	id EC1671817; Wed,  7 Nov 2001 15:09:53 -0500 (EST)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256AFD.005EACE2 ; Wed, 7 Nov 2001 12:14:06 -0500
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <sblakewilson@certicom.com>
To: mcgrew@cisco.com
Cc: rgm-sec@htt-consult.com, saag@mit.edu
Message-ID: <85256AFD.005EACBC.00@smtpmail.certicom.com>
Date: Wed, 7 Nov 2001 12:11:32 -0500
Subject: Re: [saag] Standards for Key Derivation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I wrote 9.63 ... I'll speak to a couple of the questions below in the
context of the 9.63 design. I believe the 9.63 design was one of the
inputs to the NIST design so this may (or may not) be useful here.

> Section 6.3 of the NIST document is a good start, but is not sufficient
> to meet the SRTP requirements.  For SRTP, we need the ability to
> generate a sequence of subkeys, given a master key.  We also need to be
> able to generate the subkeys out of order (srtp can be multicast, and we
> don't want to require members who join the group in the middle to have
> to play catch-up).

I believe this speaks to whether or not [SharedInfo] can be varied
for a particular shared secret. Some standards allow this, others do not.
If it can, then just include some kind of key identifier in SharedInfo
and go ahead and generate a bunch of keys out of order.

> Yet another security property that an application might require is the
> forward-security property whereby K(i) can't be computed given K(i+1).

I believe this is satisfied by the NIST design ... provided the Z value
remains secret and the hash function satisfies some unspecified properties,
different parts of the KDF output should be "independent".

> It's interesting that rfc2407 and the NIST work both construct
> pseudo-random functions from a particular MAC (in the former case) and a
> hash function (in the latter case).  Why not allow the use of a
> length-expanding pseudo-random function directly?  Such things exist,
> SEAL and Counter Mode being my favorite examples, and in fact both of
> those ciphers can easily accommodate the seek-to-any-subkey requirement
> mentioned above.

This was discussed briefly in the 9.63 work. A couple of issues came up:

- the lack of an obvious ANSI approved PRF to reference.
- At least in the case of DH and ECDH, I'm not sure standard PRF analysis
  applies. If I remeber the def'ns correctly, PRFs expect a short, truly
  random string and output a longer pseudo-random string. In the case
  of a DH or ECDH shared value, the input is definitely not random ...
  for example it may belong to a subset of size approx 2^160 out of the set
  of 1024-bit strings.

> Also, is there a more in-depth explanation of the NIST work than the
> one-page description in Section 6.3 of the online document?

I'm not aware of much in the way of written analysis of this in the ANSI
work. There were lengthy discussions at the meetings, many of which focused
more on whether to mandate use of ASN.1 for encoding of [SharedInfo].

Best regards. Simon



From rhousley@rsasecurity.com  Wed Nov  7 13:39:14 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA10198
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 13:39:14 -0500 (EST)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id NAA19565
	for <saag@mit.edu>; Wed, 7 Nov 2001 13:39:13 -0500 (EST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com
          via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 7 Nov 2001 18:35:30 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA00935
	for <saag@mit.edu>; Wed, 7 Nov 2001 13:39:09 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1])
	by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id NAA09371
	for <saag@mit.edu>; Wed, 7 Nov 2001 13:39:06 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19)
	id <T1DRB1HJ>; Wed, 7 Nov 2001 13:38:47 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.25]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id T1DRB1G0; Wed, 7 Nov 2001 13:38:32 -0500
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: saag@mit.edu
Message-Id: <5.0.1.4.2.20011107121825.02fac568@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 07 Nov 2001 12:23:19 -0500
Subject: Re: [saag] Standards for Key Derivation
In-Reply-To: <5.1.0.14.2.20011107111431.01f55808@localhost>
References: <3BE92FA7.BBB20988@cisco.com>
 <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by sdtihq24.securid.com id NAA00935
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id NAA10198
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Bob:

>>I agree that key derivation is an important topic, and that it would be
>>good to standardize on a kdf that is generally applicable.
>>Unfortunately, I was unable to attend the NIST workshop last week, and
>>I'm very glad that you're bridging the two standards efforts!  I would
>>like to see an IETF standard in this area, though I'm not sure that a
>>single spec could cover all key derivation needs.  Still, providing
>>guidance even in a subset of cases could be valuable.
>
>For those of you that have not gotten around to looking at the NIST 
>schemes document, I was sent it in editable format (as they are expecting 
>comments from me!), and here is section 6.3:
>
>Function call: kdf(Z,OtherInput), where OtherInput is U, V, keydatalen, 
>hashlen, [SharedInfo].
>
>Input description:
>1.      A bit string Z that is the shared secret.
>2.      Bit strings U and V that denote the identities of the 
>participating parties, where U is the party that initiated the key 
>establishment process, and V is the responder in the key establishment process.
>3.      An integer keydatalen that is the length in bits of the keying 
>material to be generated. keydatalen must be less than hashlen ? (232-1).
>4.      An integer hashlen that is the length in bits of the hash function 
>to be used to derive the keying material.
>5.      An optional bit string SharedInfo that consists of data shared by 
>parties U and V.
>Process:
>a. Initiate a 32-bit, big-endian bit string counter as 0000000116.
>b. For i=1 to i= , do the following:
>         Compute Hashi = H(Z||counter||U||V||[SharedInfo])
>         Increment counter
>         Increment i.
>c. Let Hashj denote Hashj if keydatalen/hashlen is an integer, and let it 
>denote the (keydatalen-(hashlen (j-1))) leftmost bits of Hashj otherwise.
>d. Set DerivedKeyingMaterial = Hash1||Hash2||…||Hashj-1||Hhashj.
>Output: The bit string DerivedKeyingMaterial of keydatalen bits.
>
>[Question: Since both parties need to compute the same derived keying 
>material, does the necessity to provide U and V create a problem? For 
>example, can all applications determine who the initiator and responder 
>are so that they would know in what order to place the identities? Or 
>would it be better to alphabetize the identities? Rather than using 
>"U||V", would it be better to use a function of the two entities, such as 
>"(U OR V)||(U AND V)", where "OR" and "AND" are bit-wise logical operators?]

Sort order is better.  This allows the KDF to have a loose linkage with 
protocol state.  Otherwise, the protocol role (e.g., initiator and 
responder) must be used to set the order.

>The derived keying material may be parsed into one or more keys or other 
>cryptographic keying material (e.g., IVs).
>
>Any scheme attempting to call the key derivation function  for a bit 
>string of length greater than or equal to hashlen (232-1) bits must output 
>"invalid" and stop.
>
>Note: The security provided by the derived keying material is limited by 
>the cryptographic strength of the key establishment scheme. For example, 
>if an elliptic curve scheme is used with a 160 bit private key, a strength 
>of roughly 80 bits is provided to the derived keying material, i.e., a 128 
>bit AES key derived from such a scheme provides no more than 80 bits of 
>security to the information it protects, not the 128 bits of security that 
>might be expected when using AES with a truly random key.
>
>Note: This technique differs from the key derivation functions defined in 
>ANSI X9.42 and X9.63. In this workshop document, the identities of the 
>initiating party (U) and the recipient (V) are included in the data that 
>is hashed. In ANSI X9.42 and X9.63, these identities could be considered a 
>part of the SharedInfo, which is optional and not defined. ANSI X9.42 also 
>includes a second key derivation function that is based on ASN.1 DER encoding.

The DER encoding is used to cause a SET to be sorted.  This provies the 
sort ordering discussed above.

The X9.63 KDF does not seem to require the algorithm identifier, but the 
X9.42 does.  I think that it is good to bind the type of key that is coming 
out of the KDF.

Russ

From rgm-sec@htt-consult.com  Wed Nov  7 13:51:00 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA10348
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 13:51:00 -0500 (EST)
Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id NAA24121
	for <saag@mit.edu>; Wed, 7 Nov 2001 13:50:59 -0500 (EST)
Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 07 Nov 2001 13:51:00 -0500
Message-Id: <5.1.0.14.2.20011107134628.01b81220@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 13:50:43 -0500
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu
In-Reply-To: <5.0.1.4.2.20011107121825.02fac568@exna07.securitydynamics.
 com>
References: <5.1.0.14.2.20011107111431.01f55808@localhost>
 <3BE92FA7.BBB20988@cisco.com>
 <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 12:23 PM 11/7/2001 -0500, Housley, Russ wrote:


>>[Question: Since both parties need to compute the same derived keying 
>>material, does the necessity to provide U and V create a problem? For 
>>example, can all applications determine who the initiator and responder 
>>are so that they would know in what order to place the identities? Or 
>>would it be better to alphabetize the identities? Rather than using 
>>"U||V", would it be better to use a function of the two entities, such as 
>>"(U OR V)||(U AND V)", where "OR" and "AND" are bit-wise logical operators?]
>
>Sort order is better.  This allows the KDF to have a loose linkage with 
>protocol state.  Otherwise, the protocol role (e.g., initiator and 
>responder) must be used to set the order.

the question comes from the NIST doc, not me.  Russ made the above point at 
the workshop.


>>Note: This technique differs from the key derivation functions defined in 
>>ANSI X9.42 and X9.63. In this workshop document, the identities of the 
>>initiating party (U) and the recipient (V) are included in the data that 
>>is hashed. In ANSI X9.42 and X9.63, these identities could be considered 
>>a part of the SharedInfo, which is optional and not defined. ANSI X9.42 
>>also includes a second key derivation function that is based on ASN.1 DER 
>>encoding.
>
>The DER encoding is used to cause a SET to be sorted.  This provies the 
>sort ordering discussed above.

Sneaky and non-obvious to those blissfully ignorant of the joys of DER 
encoding.

         I wonder how many of those are left in the IETF?  :)

>The X9.63 KDF does not seem to require the algorithm identifier, but the 
>X9.42 does.  I think that it is good to bind the type of key that is 
>coming out of the KDF.

So NIST tells .63 to change ?

Obviously there is a body of work here and perhaps those in the know can 
provide guidance to protocol designers like me.......


Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com


From sblakewilson@certicom.com  Wed Nov  7 14:25:56 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA10838
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 14:25:56 -0500 (EST)
Received: from ns.ca.certicom.com (ip5.certicom.com [209.121.99.5] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10231
	for <saag@mit.edu>; Wed, 7 Nov 2001 14:25:55 -0500 (EST)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25])
	by ns.ca.certicom.com (Postfix) with SMTP id EBBED17E0
	for <saag@mit.edu>; Wed,  7 Nov 2001 17:21:35 -0500 (EST)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256AFD.006ABA43 ; Wed, 7 Nov 2001 14:25:44 -0500
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <sblakewilson@certicom.com>
To: saag@mit.edu
Message-ID: <85256AFD.006AB881.00@smtpmail.certicom.com>
Date: Wed, 7 Nov 2001 14:22:58 -0500
Subject: Re: [saag] Standards for Key Derivation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

>>The X9.63 KDF does not seem to require the algorithm identifier, but the
>>X9.42 does.  I think that it is good to bind the type of key that is
>>coming out of the KDF.
>
> So NIST tells .63 to change ?

I'm not sure this is the right forum for a 9.42 vs 9.63 debate, but maybe pieces
of it are relevant to this discussion ...

It seems to me that designing a generic kdf is hard for two reasons:

- backwards compatibility with deployed kdfs
- technical problems

By technical problems, I mean that kdfs get deployed in a wide variety of
situations, which have different requirements. Take the issue of whether to
include identities in the kdf. I'd conjecture that there are circumstances where
there's a lack of "appropriate" identities (for example SSL with server auth
only?), and there are crcumstances where it's useful to order identities based
on protocol state to bind the key into the fact the U is the protocol initiator
or something. I'd argue similarly that it's often sensible to bind alg id into
the kdf, but there are occassions when it doesn't make sense (for example if the
client and AAA server are using the kdf, but the client and NAS are selecting
the alg?).

Bottom line: based on these concerns (and forgetting backwards compatibility
which will never get solved unless there's compelling reasons to update the
kdf), it seems like the only generic kdf that makes sense to me is one based on:

Hash(Z|Counter|[SharedInfo])

or something like that, along with rules about how to bind in various pieces of
info like ids and alg ids IF they are present.

Best regards. Simon



From rja@inet.org  Wed Nov  7 14:30:32 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA10929
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 14:30:32 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA11970
	for <saag@mit.edu>; Wed, 7 Nov 2001 14:30:32 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id 6601C67103; Wed,  7 Nov 2001 14:33:43 -0500 (EST)
Message-Id: <5.1.0.14.2.20011107141754.01d94820@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 14:21:23 -0500
To: "David A. McGrew" <mcgrew@cisco.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu
In-Reply-To: <3BE92FA7.BBB20988@cisco.com>
References: <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 07:57 07/11/01, David A. McGrew wrote:
>It's interesting that rfc2407 and the NIST work both construct
>pseudo-random functions from a particular MAC (in the former case) and a
>hash function (in the latter case).  Why not allow the use of a
>length-expanding pseudo-random function directly?  

        I would not be comfortable with that approach, simply because
I'd want to use an approach that has had LOTS of peer review over
a long while.  Colour me conservative when it comes to key generation.

Ran



From rja@inet.org  Wed Nov  7 14:34:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA10980
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 14:34:50 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA13420
	for <saag@mit.edu>; Wed, 7 Nov 2001 14:34:49 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id 8297167103; Wed,  7 Nov 2001 14:38:01 -0500 (EST)
Message-Id: <5.1.0.14.2.20011107142150.01d94ec0@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 14:25:42 -0500
To: "Chalmers, Matthew (FUSA)" <MatthewChalmers@firstusa.com>
From: RJ Atkinson <rja@inet.org>
Subject: RE: [saag] Standards for Key Derivation
Cc: saag@mit.edu
In-Reply-To: <B39104ADF3A0D311878200A0C9B41A1F06CBF5A9@swilnts814.wil.fu
 sa.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 11:20 07/11/01, Chalmers, Matthew (FUSA) wrote:
>One of the questions that came up at the Key Management Workshop was 
>whether there are any proofs that the output from any existing KDF 
>is 'good' input to use as a key for an algorithm? That is, is there 
>a proof that shows the output of TLS' (or SSL's or whatever) KDF 
>would make a good DES key, for example? 

        For openers, one should check any potential key against
the list of (believed weak, believed semi-weak) keys for whatever 
algorithm (DES, AES, or other) was being used.

>Are there situations where the output would be fine for input to
>HMAC but not AES, for example? 

        If a potential key were a 'believed weak' key for AES, 
it still *might* work for HMAC MD5, depending.

>Or is it just generally accepted that the output of existing KDFs 
>is random enough that it will always serve as good input for a key? 

        Cryptographic randomness is not the only metric to consider.

>Should weak key tests necessarily be performed on KDF output?

        Absolutely yes.  Such tests are not always made in all existing
(freeware or commercial) security products, regrettably.

Ran
rja@inet.org


From rja@inet.org  Wed Nov  7 14:39:04 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11036
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 14:39:04 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA15526
	for <saag@mit.edu>; Wed, 7 Nov 2001 14:39:04 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id 8CDB267103; Wed,  7 Nov 2001 14:42:10 -0500 (EST)
Message-Id: <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 14:29:51 -0500
To: "Steven M. Bellovin" <smb@research.att.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Standards for Key Derivation 
Cc: saag@mit.edu
In-Reply-To: <20011107163900.D5A6D7C00@berkshire.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 11:39 07/11/01, Steven M. Bellovin wrote:
>As has been pointed out before, weak-key testing is probably a bad 
>idea.  The odds on encountering a weak key in practice are vanishingly 
>small (1 in 2^52 for DES, as I recall).  That means that the code to 
>test for and recover from such keys won't be well-tested, and is more 
>likely to break something else.

        I'd disagree.  I'd also say that the code to test for and
recover from weak keys has worked well enough in the products
with which I'm most familiar.  The trick seems to be using good software
practices (rigorous specs, careful coding, both black-box and open-box 
testing, etc.).

        If one accidentally uses a weak key, then it can be trivial
to get in.  A clever adversary first tries the weak keys, precisely
because there are few of them (so its tractable to try them) and
because lots of products out there don't check for them.

        Btw, this is one of the ways that Bletchley Park used to
get into certain forms of Nazi cryptosystems during WWII.

        Colour me conservative.

Cheers,

Ran
rja@inet.org


From rja@inet.org  Wed Nov  7 14:39:47 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11043
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 14:39:47 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA15781
	for <saag@mit.edu>; Wed, 7 Nov 2001 14:39:47 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id 2D40B67103; Wed,  7 Nov 2001 14:42:59 -0500 (EST)
Message-Id: <5.1.0.14.2.20011107143007.01d97d90@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 14:30:40 -0500
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu
In-Reply-To: <5.0.1.4.2.20011107121825.02fac568@exna07.securitydynamics.
 com>
References: <5.1.0.14.2.20011107111431.01f55808@localhost>
 <3BE92FA7.BBB20988@cisco.com>
 <5.1.0.14.2.20011107083515.01f49058@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 12:23 07/11/01, Housley, Russ wrote:
>The X9.63 KDF does not seem to require the algorithm identifier, but the X9.42 does.  I think that it is good to bind the type of key that is coming out of the KDF.

        Agree.  An excellent point.

Ran


From smb@research.att.com  Wed Nov  7 14:48:43 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA11195
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 14:48:43 -0500 (EST)
Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19966
	for <saag@mit.edu>; Wed, 7 Nov 2001 14:48:43 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id B8EDB7B55; Wed,  7 Nov 2001 14:48:31 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: RJ Atkinson <rja@inet.org>
Cc: saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 Nov 2001 14:48:31 -0500
Message-Id: <20011107194831.B8EDB7B55@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>, RJ Atkinson writes:
>At 11:39 07/11/01, Steven M. Bellovin wrote:
>>As has been pointed out before, weak-key testing is probably a bad 
>>idea.  The odds on encountering a weak key in practice are vanishingly 
>>small (1 in 2^52 for DES, as I recall).  That means that the code to 
>>test for and recover from such keys won't be well-tested, and is more 
>>likely to break something else.
>
>        I'd disagree.  I'd also say that the code to test for and
>recover from weak keys has worked well enough in the products
>with which I'm most familiar.  The trick seems to be using good software
>practices (rigorous specs, careful coding, both black-box and open-box 
>testing, etc.).
>
>        If one accidentally uses a weak key, then it can be trivial
>to get in.  A clever adversary first tries the weak keys, precisely
>because there are few of them (so its tractable to try them) and
>because lots of products out there don't check for them.
>
>        Btw, this is one of the ways that Bletchley Park used to
>get into certain forms of Nazi cryptosystems during WWII.

Well, yes, but those keys were not machine-generated random sequences.  
Furthermore, they were often related to some other quantity.  In the 
situations I'm speaking of, we have a rigorous bound on the 
probability.  (If the pseudo-random process that is being used produces 
predictable keys with a higher frequency, that's a much different -- 
and more serious -- problem that should be addressed at that layer.)

I'm conservative, too -- when it comes to software.  I've also noticed 
the apparent scarcity of your list of good software practices...

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com



From ekr@rtfm.com  Wed Nov  7 15:40:07 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11819
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 15:40:07 -0500 (EST)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA11661
	for <saag@mit.edu>; Wed, 7 Nov 2001 15:40:06 -0500 (EST)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id fA7Kd3964485; Wed, 7 Nov 2001 12:39:03 -0800 (PST)
To: RJ Atkinson <rja@inet.org>
Cc: "Steven M. Bellovin" <smb@research.att.com>, saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation
References: <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 07 Nov 2001 12:39:02 -0800
In-Reply-To: RJ Atkinson's message of "Wed, 07 Nov 2001 14:29:51 -0500"
Message-ID: <kjk7x2pb89.fsf@romeo.rtfm.com>
Lines: 22
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

RJ Atkinson <rja@inet.org> writes:
>         If one accidentally uses a weak key, then it can be trivial
> to get in.  A clever adversary first tries the weak keys, precisely
> because there are few of them (so its tractable to try them) and
> because lots of products out there don't check for them.
I'm puzzled by this argument. It seems to me that if one accidently
uses a key that happens to be early in the attacker's search order
than it can be trivial to get in, regardless of whether you are
checking for weak keys or not. If the attacker discovers the value of
your key I don't see that the situation is any worse if it happens to
be a weak key.

Or is your argument simply that attackers test weak keys first
so we should avoid them? If so, a similar argument could be made
that we should avoid small keys since attackers often check keys
in sequence.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/

From rja@inet.org  Wed Nov  7 15:48:51 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA11940
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 15:48:51 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA14198
	for <saag@mit.edu>; Wed, 7 Nov 2001 15:48:50 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id 4D6E867103; Wed,  7 Nov 2001 15:52:03 -0500 (EST)
Message-Id: <5.1.0.14.2.20011107153644.00a13c10@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 15:39:43 -0500
To: EKR <ekr@rtfm.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu
In-Reply-To: <kjk7x2pb89.fsf@romeo.rtfm.com>
References: <RJ Atkinson's message of "Wed, 07 Nov 2001 14:29:51 -0500">
 <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 15:39 07/11/01, Eric Rescorla wrote:
>Or is your argument simply that attackers test weak keys first
>so we should avoid them? If so, a similar argument could be made
>that we should avoid small keys since attackers often check keys
>in sequence.

        Clever attackers would test weak keys first, given the current
state of commercial crypto...  Notionally, the weak keys are also
called "weak" for a reason -- meaning there might be other efficient
ways to attack that would cull out a weak key, but not a strong key.

        Whether the user cares depends on whether their threat model 
includes folks who might try to break into the crypto, one way or another,
and the value of the data being protected, among other things.

Ran
rja@inet.org




From kent@bbn.com  Wed Nov  7 16:11:00 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12219
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 16:11:00 -0500 (EST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA25078
	for <saag@mit.edu>; Wed, 7 Nov 2001 16:11:00 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA11953;
	Wed, 7 Nov 2001 16:10:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010412b80f4f441530@[128.89.88.34]>
In-Reply-To: <5.1.0.14.2.20011107153644.00a13c10@10.30.15.3>
References: <RJ Atkinson's message of "Wed, 07 Nov 2001 14:29:51 -0500">
 <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>
 <5.1.0.14.2.20011107153644.00a13c10@10.30.15.3>
Date: Wed, 7 Nov 2001 16:01:06 -0500
To: RJ Atkinson <rja@inet.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Standards for Key Derivation
Cc: saag@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 3:39 PM -0500 11/7/01, RJ Atkinson wrote:
>At 15:39 07/11/01, Eric Rescorla wrote:
>>Or is your argument simply that attackers test weak keys first
>>so we should avoid them? If so, a similar argument could be made
>>that we should avoid small keys since attackers often check keys
>>in sequence.
>
>         Clever attackers would test weak keys first, given the current
>state of commercial crypto...  Notionally, the weak keys are also
>called "weak" for a reason -- meaning there might be other efficient
>ways to attack that would cull out a weak key, but not a strong key.
>
>         Whether the user cares depends on whether their threat model
>includes folks who might try to break into the crypto, one way or another,
>and the value of the data being protected, among other things.

Ran,

I'm a bit puzzled by your comments re weak keys.  To the best of my 
knowledge, the term originated in the public literature when DES was 
published. It referred to keys that had the property that, due to 
symmetries in the DES key schedule algorithm, would result in 
transforming plaintext into plaintext, when the algorithm was applied 
twice, in ECB mode. Since ECB mode is not intended to protect user 
data, and since super encryption of this sort would thus be very 
unlikely in general, the risk posed by weak key use in DES was always 
pretty marginal. But, the list was small enough to make checking easy 
and thus it was recommended that such checks against the list be 
made.  (The term was later extended to so called "semi-weak" keys 
which did not have the above noted property, but were still of some 
possible concern due to symmetries in the key schedule generation 
procedure.)

Now, when one applies this term generically, I'm not sure what 
criteria one is applying to keys to determine if they are "weak." So, 
what you said above might be true, but this was not really the issue 
for DES weak keys. If keys are chosen randomly, there is little 
incentive in trying those keys first (to decrypt ciphertext), vs. any 
others. certainly we should require any algorithm to specify criteria 
for keys that should/must be avoided IF use of such keys would 
significantly undermine the security of the algorithm.  However, for 
most modern (symmetric) algorithms, I don't think we tend to have 
such problems.  For example, AES does not have weak keys, based on 
the analysis performed.

Now, for public key systems the situation is different.  there the 
bit strings used for keys have very definite criteria that must be 
applied in the selection process to avoid weaknesses, but all public 
key algorithms describe the tests to be performed, in the key 
generation process, so I think that's not the issues we're addressing 
here, right?

Steve

From ekr@rtfm.com  Wed Nov  7 16:21:33 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12376
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 16:21:33 -0500 (EST)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA28961
	for <saag@mit.edu>; Wed, 7 Nov 2001 16:21:10 -0500 (EST)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.11.3/8.6.4) with ESMTP id fA7LKHI64572; Wed, 7 Nov 2001 13:20:17 -0800 (PST)
Message-Id: <200111072120.fA7LKHI64572@romeo.rtfm.com>
To: RJ Atkinson <rja@inet.org>
cc: saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation 
In-reply-to: Your message of "Wed, 07 Nov 2001 15:39:43 EST."
             <5.1.0.14.2.20011107153644.00a13c10@10.30.15.3> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 07 Nov 2001 13:20:17 -0800
From: Eric Rescorla <ekr@rtfm.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> At 15:39 07/11/01, Eric Rescorla wrote:
> >Or is your argument simply that attackers test weak keys first
> >so we should avoid them? If so, a similar argument could be made
> >that we should avoid small keys since attackers often check keys
> >in sequence.
> 
>         Clever attackers would test weak keys first, given the current
> state of commercial crypto...
But if we actually start checking then attackers will check weak
keys LAST because they know we don't use them.

It's a really bad idea to bias your key generation algorithm based on
your model of what attackers currently do because attackers are
adaptive. The MAXIMIN strategy is to use uniformly distributed keys.

>  Notionally, the weak keys are also
> called "weak" for a reason -- meaning there might be other efficient
> ways to attack that would cull out a weak key, but not a strong key.
There are so few DES weak keys that the amount of time required to check
them all in the conventional way is insignificant. 

Granted that if some significant fraction of the keys were weak
and it were dramatically faster to check the class of all weak
keys than to check an equivalent number of non-weak keys then
it would make sense to avoid weak keys. However, in this case
I hope we'd opt to find a better algorithm instead.

-Ekr


From rhousley@rsasecurity.com  Wed Nov  7 16:39:22 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12639
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 16:39:22 -0500 (EST)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id QAA06998
	for <saag@mit.edu>; Wed, 7 Nov 2001 16:39:22 -0500 (EST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com
          via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 7 Nov 2001 21:35:39 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA17763;
	Wed, 7 Nov 2001 16:39:22 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1])
	by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id QAA27708;
	Wed, 7 Nov 2001 16:39:21 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19)
	id <T1DRBH9K>; Wed, 7 Nov 2001 16:39:06 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.66]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id T1DRBH9A; Wed, 7 Nov 2001 16:38:55 -0500
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: ekr@rtfm.com, rja@inet.org
Cc: saag@mit.edu
Message-Id: <5.0.1.4.2.20011107163315.02fd83d0@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 07 Nov 2001 16:36:12 -0500
Subject: Re: [saag] Standards for Key Derivation
In-Reply-To: <5.1.0.14.2.20011107153644.00a13c10@10.30.15.3>
References: <kjk7x2pb89.fsf@romeo.rtfm.com>
 <RJ Atkinson's message of "Wed, 07 Nov 2001 14:29:51 -0500">
 <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

>At 15:39 07/11/01, Eric Rescorla wrote:
> >Or is your argument simply that attackers test weak keys first
> >so we should avoid them? If so, a similar argument could be made
> >that we should avoid small keys since attackers often check keys
> >in sequence.

At 03:39 PM 11/7/2001 -0500, RJ Atkinson wrote:
>         Clever attackers would test weak keys first, given the current
>state of commercial crypto...  Notionally, the weak keys are also
>called "weak" for a reason -- meaning there might be other efficient
>ways to attack that would cull out a weak key, but not a strong key.
>
>         Whether the user cares depends on whether their threat model
>includes folks who might try to break into the crypto, one way or another,
>and the value of the data being protected, among other things.

The FMS attack on IEEE 802.11 ignores all of the packets except those 
encrypted with weak keys.  In this case, the packets carry a plaintext 
indicator that tells which ones used weak keys.  That was a very attacker 
friendly design. ;-)

Russ

From mcgrew@cisco.com  Wed Nov  7 17:01:50 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA12965
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 17:01:50 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA15411
	for <saag@mit.edu>; Wed, 7 Nov 2001 17:01:49 -0500 (EST)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fA7M1QB13511;
	Wed, 7 Nov 2001 14:01:26 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AAF00233;
	Wed, 7 Nov 2001 13:56:52 -0800 (PST)
Message-ID: <3BE986CA.6F624A93@cisco.com>
Date: Wed, 07 Nov 2001 14:08:58 -0500
From: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Steven M. Bellovin" <smb@research.att.com>
CC: RJ Atkinson <rja@inet.org>, saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation
References: <20011107194831.B8EDB7B55@berkshire.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

"Steven M. Bellovin" wrote:
> 
> In message <5.1.0.14.2.20011107142616.01d97a40@10.30.15.3>, RJ Atkinson writes:
> >At 11:39 07/11/01, Steven M. Bellovin wrote:
> >>As has been pointed out before, weak-key testing is probably a bad
> >>idea.  The odds on encountering a weak key in practice are vanishingly
> >>small (1 in 2^52 for DES, as I recall).  That means that the code to
> >>test for and recover from such keys won't be well-tested, and is more
> >>likely to break something else.
> >
> >        I'd disagree.  I'd also say that the code to test for and
> >recover from weak keys has worked well enough in the products
> >with which I'm most familiar.  The trick seems to be using good software
> >practices (rigorous specs, careful coding, both black-box and open-box
> >testing, etc.).
> >
> >        If one accidentally uses a weak key, then it can be trivial
> >to get in.  A clever adversary first tries the weak keys, precisely
> >because there are few of them (so its tractable to try them) and
> >because lots of products out there don't check for them.
> >
> >        Btw, this is one of the ways that Bletchley Park used to
> >get into certain forms of Nazi cryptosystems during WWII.
> 
> Well, yes, but those keys were not machine-generated random sequences.
> Furthermore, they were often related to some other quantity.  In the
> situations I'm speaking of, we have a rigorous bound on the
> probability.  (If the pseudo-random process that is being used produces
> predictable keys with a higher frequency, that's a much different --
> and more serious -- problem that should be addressed at that layer.)

I agree with Steve that weak key checking isn't useful.  IMHO, weak keys
are a pernicious abstraction, to paraphrase Abraham Lincoln.

If the size of the set of 'weak keys' is negligible relative to the set
of all keys, then the security benefits of avoiding weak keys is
negligible.  If that size isn't negligible, then the cipher in
consideration should probably be considered defective.  

The cipher that comes to my mind, for which a weak-key attack actually
provides some advantage, is IDEA.  I forget what the degradation in
effective key size is, but it's pretty small.  For DES, I don't believe
that there are any ways to use weak keys which provides an advantage
over exhaustive search.

Are you aware of a cipher for which the use of a weak key can have a
non-negligible effect on security?  

thanks,
 
David

From hallam@ai.mit.edu  Wed Nov  7 04:15:44 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA04038
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 04:15:43 -0500 (EST)
Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id EAA15243
	for <saag@mit.edu>; Wed, 7 Nov 2001 04:15:43 -0500 (EST)
Received: from Phillspc (desop10.inria.fr [193.51.209.140])
	by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with SMTP id EAA00372
	for <saag@mit.edu>; Wed, 7 Nov 2001 04:15:42 -0500 (EST)
From: "Phillip Hallam-Baker" <hallam@ai.mit.edu>
To: <saag@mit.edu>
Date: Wed, 7 Nov 2001 04:16:11 -0500
Message-ID: <000201c1676c$d830f2e0$8cd133c1@ne.mediaone.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Subject: [saag] Anyone know anyone reasonable at Netvision?
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hi,

	Does anyone know of a reasonable person at Netvision in Israel? One of
their users has been bombarding me with Sircam for two months and the system
administration have failed to take any action.

	It is the sheer volume of the attacks that is a problem, 40 odd messages at
200Kb each every day. Before you suggest, no procmail is not a solution.

	I have tried polite requests, procmailing some of the attacks back to the
sysops, threats of legal action addressed to the CEO.

	Their complaint response algorithm is

1) Ask the complainant for the 'full headers of the message'
2) If the full headers are presented then tell the complainant that a case
will be opened
3) Goto 1
4) Tell the complainant that they have to wait a week before another
complaint can be filled
	Goto 1
5) Goto 4
6) Ask the complainant for the 'full headers of the message' Goto 2
7) Tell the compainant that they do not accept complaints on alternate
tuesdays, wednesdays or thursdays, goto 2

8) Demand evidence that a sircam infected message has been sent
9) The anti-virus filter at Netvision bounced the message, Goto 1.

10) etc.


	Please DO NOT suggest a technical fix, the user is obviously attacking many
users, the attacks should be stopped, the Netvision support staff should
have taken action immediately to stop the attacks.

	When I was a sysop some years ago we would have suspended the users account
immediately and had a talk with them. I find it very odd that companies
would have policy that would require them to wait over a week before they
took any action in a case such as this - not that the sysops are taking any
action after a week.

	I have had previous experience of this type of run-arround in a previous
case where we later obtained the emails between the sysop and the attacker
that provided the explanation for the sysop behavior.

	It is just possible that the sysops are incredibly stupid and cannot
understand that it is impossible to send them the infected messages when
their new virus filter is rejecting them, I doubt this is the case.


		Phill



From crawdad@gungnir.fnal.gov  Wed Nov  7 09:57:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA07378
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 09:57:38 -0500 (EST)
Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA19962
	for <saag@mit.edu>; Wed, 7 Nov 2001 09:57:38 -0500 (EST)
Received: from gungnir.fnal.gov ([131.225.80.1])
 by smtp.fnal.gov (PMDF V6.0-24 #37519)
 with ESMTP id <0GMF00MI3QW13Y@smtp.fnal.gov> for saag@mit.edu; Wed,
 07 Nov 2001 08:57:37 -0600 (CST)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fA7Eval10391; Wed,
 07 Nov 2001 08:57:36 -0600 (CST)
Date: Wed, 07 Nov 2001 08:57:36 -0600
From: Matt Crawford <crawdad@fnal.gov>
Subject: Re: [saag] Standards for Key Derivation
In-reply-to: "07 Nov 2001 06:33:41 PST." <kjn11yr6pm.fsf@romeo.rtfm.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>, saag@mit.edu
Message-id: <200111071457.fA7Eval10391@gungnir.fnal.gov>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> > NIST has derived a method from ANSI X9.42 that is quite close to what IKE 
> > does (RFC 2407), but still different.  As far as I know, IKE is our only 
> > serious effort at a Key Derivation function.
> 
> TLS (RFC 2246) contains a KDF (called PRF there) as well.

And draft-ietf-cat-kerberos-revisions-08.txt (now in the krb-wg, not cat).

From uri@lucent.com  Wed Nov  7 11:57:25 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA09049
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 11:57:25 -0500 (EST)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA07941
	for <saag@mit.edu>; Wed, 7 Nov 2001 11:57:24 -0500 (EST)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fA7GvNU18389
	for <saag@mit.edu>; Wed, 7 Nov 2001 11:57:23 -0500 (EST)
Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA04269; Wed, 7 Nov 2001 11:57:20 -0500 (EST)
Cc: Robert Moskowitz <rgm-sec@htt-consult.com>, saag@mit.edu
Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA04255; Wed, 7 Nov 2001 11:57:17 -0500 (EST)
Message-ID: <3BE96740.552D66C3@lucent.com>
Date: Wed, 07 Nov 2001 11:54:25 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <ekr@rtfm.com>
Original-CC: Robert Moskowitz <rgm-sec@htt-consult.com>, saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation
References: <5.1.0.14.2.20011107083515.01f49058@localhost> <kjn11yr6pm.fsf@romeo.rtfm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla wrote:
> Robert Moskowitz <rgm-sec@htt-consult.com> writes:
> > NIST has derived a method from ANSI X9.42 that is quite close to what IKE
> > does (RFC 2407), but still different.  As far as I know, IKE is our only
> > serious effort at a Key Derivation function.
> TLS (RFC 2246) contains a KDF (called PRF there) as well.

As you're talking about Key Derivation [based on keyed hash or MAC
function],
let me pipe in and remind that a provably secure PRF-from-MAC draft
has been
submitted [by yours truly :-]. It differs from the IKE approach, but
then it
is provably secure, as I said.
-- 
Regards,
Uri.
-=-=-<>-=-=-
<Disclaimer>

From uri@lucent.com  Wed Nov  7 16:42:25 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA12727
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 16:42:24 -0500 (EST)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08087
	for <saag@mit.edu>; Wed, 7 Nov 2001 16:42:24 -0500 (EST)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fA7LgMZ19103
	for <saag@mit.edu>; Wed, 7 Nov 2001 16:42:23 -0500 (EST)
Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA14395; Wed, 7 Nov 2001 16:42:20 -0500 (EST)
Cc: RJ Atkinson <rja@inet.org>, saag@mit.edu
Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA14372; Wed, 7 Nov 2001 16:42:16 -0500 (EST)
Message-ID: <3BE9AABA.2AB84D2B@lucent.com>
Date: Wed, 07 Nov 2001 16:42:18 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
Original-CC: RJ Atkinson <rja@inet.org>, saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation
References: <200111072120.fA7LKHI64572@romeo.rtfm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Eric Rescorla wrote:
> It's a really bad idea to bias your key generation algorithm based on
> your model of what attackers currently do because attackers are
> adaptive. The MAXIMIN strategy is to use uniformly distributed keys.

Assuming that the keyspace is linear.
-- 
Regards,
Uri.
-=-=-<>-=-=-
<Disclaimer>

From ekr@rtfm.com  Wed Nov  7 18:00:01 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA13695
	for <saag@jis.mit.edu>; Wed, 7 Nov 2001 18:00:01 -0500 (EST)
Received: from romeo.rtfm.com ([198.144.203.242])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA07264
	for <saag@mit.edu>; Wed, 7 Nov 2001 17:59:56 -0500 (EST)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.11.3/8.6.4) with ESMTP id fA7Mx2I64662; Wed, 7 Nov 2001 14:59:02 -0800 (PST)
Message-Id: <200111072259.fA7Mx2I64662@romeo.rtfm.com>
To: Uri Blumenthal <uri@lucent.com>
cc: RJ Atkinson <rja@inet.org>, saag@mit.edu
Subject: Re: [saag] Standards for Key Derivation 
In-reply-to: Your message of "Wed, 07 Nov 2001 16:42:18 EST."
             <3BE9AABA.2AB84D2B@lucent.com> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 07 Nov 2001 14:59:02 -0800
From: Eric Rescorla <ekr@rtfm.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Eric Rescorla wrote:
> > It's a really bad idea to bias your key generation algorithm based on
> > your model of what attackers currently do because attackers are
> > adaptive. The MAXIMIN strategy is to use uniformly distributed keys.
> 
> Assuming that the keyspace is linear.
Yes, quite so.
-Ekr

From mleech@NORTELNETWORKS.COM  Fri Nov  9 11:35:57 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA06512
	for <saag@jis.mit.edu>; Fri, 9 Nov 2001 11:34:35 -0500 (EST)
Received: from rftzy05y.ca.nortel.com (h161s130a130n47.user.nortelnetworks.com [47.130.130.161])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20439
	for <saag@mit.edu>; Fri, 9 Nov 2001 11:34:35 -0500 (EST)
Received: from rftzy232.ca.nortel.com (rftzy232.ca.nortel.com [47.130.185.32])
	by rftzy05y.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fA9GY3F05022
	for <saag@mit.edu>; Fri, 9 Nov 2001 11:34:03 -0500 (EST)
Received: from NORTELNETWORKS.COM (wftzh00e.ca.nortel.com [47.130.116.9]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WA4JDH2D; Fri, 9 Nov 2001 11:32:14 -0500
Message-ID: <3BEC0588.A7DDDA9D@NORTELNETWORKS.COM>
Date: Fri, 09 Nov 2001 11:34:16 -0500
From: "Leech, Marcus (EXCHANGE:FITZ:8M86)" <mleech@NORTELNETWORKS.COM>
X-Mailer: Mozilla 4.73C-CCK-MCD  [en] (X11; U; HP-UX B.10.20 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [saag] NMSEC BOF/WG
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Bert and I discussed today the potential creation of a new WG in the
  Security Area, whose purpose is to define security requirements for
  existing NM protocols (SNMP and COPS are immediately relevant).

Bert will provide a co-chair from O&M, but I'm looking for someeone
  from the security side.  If you think you have what it takes,
  please e-mail me a note.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  +1 613 763 9145
Security Architecture and Planning       Fax:   (ESN) 393-9435  +1 613 763 9435
Nortel Networks                          mleech@nortelnetworks.com
-----------------Expressed opinions are my own, not my employer's------

From owner-saag@MIT.EDU  Fri Nov 16 06:57:03 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA26949
	for <saag@jis.mit.edu>; Fri, 16 Nov 2001 06:57:03 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA08686
	for <saag@mit.edu>; Fri, 16 Nov 2001 06:57:03 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id GAA03495
	Fri, 16 Nov 2001 06:47:43 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26736;
	Fri, 16 Nov 2001 06:56:59 -0500 (EST)
Message-Id: <200111161156.GAA26736@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 16 Nov 2001 06:56:59 -0500
Subject: [saag] I-D ACTION:draft-mcgrew-saag-icm-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Integer Counter Mode
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-icm-00.txt
	Pages		: 8
	Date		: 15-Nov-01
	
This document specifies Integer Counter Mode (ICM), a mode of
operation of a block cipher which defines a keystream generator.
This mode is efficient, parallelizable, and proven secure given
realistic assumptions about the block cipher.  Test vectors are
provided for RIJNDAEL.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-icm-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mcgrew-saag-icm-00.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-mcgrew-saag-icm-00.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:	<20011115154225.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-icm-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-icm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011115154225.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-saag@MIT.EDU  Fri Nov 16 06:58:34 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA26981
	for <saag@jis.mit.edu>; Fri, 16 Nov 2001 06:58:34 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA10130
	for <saag@mit.edu>; Fri, 16 Nov 2001 06:58:34 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id GAA03500
	Fri, 16 Nov 2001 06:49:14 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27048;
	Fri, 16 Nov 2001 06:58:30 -0500 (EST)
Message-Id: <200111161158.GAA27048@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 16 Nov 2001 06:58:30 -0500
Subject: [saag] I-D ACTION:draft-mcgrew-saag-tmmh-01.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Truncated Multi-Modular Hash Function (TMMH)
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-tmmh-01.txt
	Pages		: 6
	Date		: 15-Nov-01
	
TMMH is a `universal' hash function suitable for message
authentication in the Wegman-Carter paradigm, as in the Stream
Cipher Security Transform.  It is simple, quick, and especially
appropriate for Digital Signal Processors and other processors with
a fast multiply operation, though a straightforward implementation
requires storage equal in length to the largest message to be
hashed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-tmmh-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mcgrew-saag-tmmh-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-mcgrew-saag-tmmh-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:	<20011115154634.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-tmmh-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-tmmh-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011115154634.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-saag@MIT.EDU  Fri Nov 16 06:58:39 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA26986
	for <saag@jis.mit.edu>; Fri, 16 Nov 2001 06:58:39 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA10149
	for <saag@mit.edu>; Fri, 16 Nov 2001 06:58:38 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id GAA03503
	Fri, 16 Nov 2001 06:49:19 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27069;
	Fri, 16 Nov 2001 06:58:35 -0500 (EST)
Message-Id: <200111161158.GAA27069@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: saag@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 16 Nov 2001 06:58:35 -0500
Subject: [saag] I-D ACTION:draft-mcgrew-saag-ust-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Universal Security Transform
	Author(s)	: D. McGrew
	Filename	: draft-mcgrew-saag-ust-00.txt
	Pages		: 14
	Date		: 15-Nov-01
	
This document describes a cryptographic transform which uses a
keystream generator (which can generate keystream segments in
arbitrary order) and a universal hash function to provide both
confidentiality, message authentication, and replay protection.
This transform is efficient, provably secure, and is appropriate
for network security.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-saag-ust-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mcgrew-saag-ust-00.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-mcgrew-saag-ust-00.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:	<20011115154710.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mcgrew-saag-ust-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcgrew-saag-ust-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011115154710.I-D@ietf.org>

--OtherAccess--

--NextPart--



From stephen.farrell@baltimore.ie  Tue Nov 20 13:54:32 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA08184
	for <saag@jis.mit.edu>; Tue, 20 Nov 2001 13:54:28 -0500 (EST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA07300
	for <saag@mit.edu>; Tue, 20 Nov 2001 13:54:24 -0500 (EST)
Received: from Baltimore-FW1 ([172.19.1.1])
	by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA04570
	for <saag@mit.edu>; Tue, 20 Nov 2001 18:54:23 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T575781321b0a9919350ad@emeairlsw1.baltimore.com> for <saag@mit.edu>;
 Tue, 20 Nov 2001 18:50:39 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA28678
	for <saag@mit.edu>; Tue, 20 Nov 2001 18:54:21 GMT
Message-ID: <3BFAA6E8.65525AA0@baltimore.ie>
Date: Tue, 20 Nov 2001 18:54:32 +0000
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: multipart/mixed; boundary="------------6486B4FD7BB5975C24E32104"
Subject: [saag] XKMS meeting in Salt Lake City on Sunday dec 9th.
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This is a multi-part message in MIME format.
--------------6486B4FD7BB5975C24E32104
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


If you're attending the IETF meeting and are in town early
there'll be a meeting of the (in formation) w3c xkms working
group. The meeting is open to all and will include some
tutorial material at the start.

Follow the instructions in the attachement if you'd like to
attend.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com
--------------6486B4FD7BB5975C24E32104
Content-Type: text/html; charset=iso-8859-1;
 name="SLC-Logistics.html"
Content-Disposition: inline;
 filename="SLC-Logistics.html"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id SAA28678

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8=
859-1">
  <title>IW3C XKMS Salt Lake City Logistics</title>
  <link rel=3D"stylesheet" type=3D"text/css" href=3D"../WG.css">
</head>

<body>
<p><a href=3D"/"></a></p>

<h1><a href=3D"http://www.w3.org/"><img src=3D"http://www.w3.org/w3c_home=
.gif"
alt=3D"W3C" border=3D"0" height=3D"48" width=3D"72">
 </a>=A0 XKMS WG</h1>

<h1>Salt Lake City Meeting Logistics</h1>

<p><br>
A meeting of the W3C <a href=3D"../Overview.html">XKMS Working Group</a> =
is
being hosted by Baltimore Technologies at the Grand America Hotel, Salt l=
ake
City, Utah on Sunday, December 9, 2001.</p>

<p>A final agenda will be posted later but the meeting will start at noon=
 and
end around 5PM.</p>

<p>The outline agenda is as follows:</p>
<ul>
  <li>Welcome/Introductions/Agenda-Bashing</li>
  <li>Overview of XKMS (tutorial material, about 30 minutes)</li>
  <li>XKMS Requirements Document (the main agenda item for this meeting)<=
/li>
  <li>Planned revisions of XKMS and XBULK</li>
  <li>AOB</li>
</ul>

<p></p>

<p>This meeting is co-located with the <a
href=3D"http://www.ietf.org/meetings/IETF-52.html">52nd IETF Meeting</a>
(directions, hotel information etc. are located on the IETF meeting <a
href=3D"http://www.ietf.org/meetings/IETF-52.html">page</a>).</p>

<p>Details of the room will be posted later. Refereshments will be served
during the afternoon (i.e. you're on your own for an early lunch).</p>

<p>You must make reservations with the hotel directly (the IETF meeting p=
age
lists other hotels in the area as well). If you are going to attend, plea=
se
send email to the co-chairs <a
href=3D"mailto:stephen.farrell@baltimore.ie">Stephen Farrell</a> and <a
href=3D"mailto:shivaram.mysore@sun.com">Shivaram Mysore</a> indicating yo=
ur
intention to attend. (If you can do this before <strong>Tuesday November
20th</strong> that'll make it easier for us to get a right-sized room.)</=
p>

<p>If you cannot attend but would like to take part in the meeting via
telephone, please send a mail to the co-chairs indicating this. If there =
is
sufficient interest, we will arrange a dial-in number.</p>

<p><br>
<b>MEETING SITE:</b><br>
<b><a href=3D"http://www.grandamerica.com/">Grand America Hotel</a></b> <=
br>
555 South Main Street <br>
Salt Lake City, Utah 84111 <br>
Tel: +1-800-621-4505 <br>
Fax: +1-801-258-6911<br>
</p>

<p><strong>Note</strong>: This group is not yet an official W3C group, bu=
t is
expected to become one around the time off this meeting. XKMS discussion =
is
currently taking place on the W3C's<a
href=3D"http://lists.w3.org/Archives/Public/www-xkms-ws/"> XKMS Workshop
mailiing list</a>. Updates to this announcement will be posted there.</p>
<hr>
</body>
</html>
<!-- context info -->

--------------6486B4FD7BB5975C24E32104--


From hwangheechoel@hanmail.net  Tue Nov 20 19:09:17 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA10596
	for <saag@jis.mit.edu>; Tue, 20 Nov 2001 19:09:17 -0500 (EST)
Received: from smail-5.hanmail.net (smail-5.hanmail.net [211.233.29.95])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA09193
	for <saag@mit.edu>; Tue, 20 Nov 2001 19:09:15 -0500 (EST)
Received: from www4.hanmail.net (www4.hanmail.net [211.32.117.24])
        by smail-5.hanmail.net (8.10.0/8.9.1) with ESMTP id fAL098E06213;
        Wed, 21 Nov 2001 09:09:08 +0900
Received: (from hanadmin@localhost)
        by www4.hanmail.net (8.10.0/8.9.1) id fAL07p229453
        for <saag@mit.edu>; Wed, 21 Nov 2001 09:07:51 +0900 (KST)
X-Originating-IP: [210.126.9.213]
From: "=?EUC-KR?B?yLLI8cO2?=" <hwangheechoel@hanmail.net>
Reply-To: "=?EUC-KR?B?yLLI8cO2?=" <hwangheechoel@hanmail.net>
To: <saag@mit.edu>
X-Mailer: Daum Web Mailer 1.0
Date: Wed, 21 Nov 2001 09:07:51 +0900 (KST)
Message-Id: <20011121090751.HM.30000000003AI5r@www4.hanmail.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Transfer-Encoding: 8bit
Subject: [saag] mailing list!
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hi! 
I want joining your mailing list.
Thank you~~  Have a nice day!


===================================================================
¿ì¸® ÀÎÅÍ³Ý, Daum  http://www.daum.net
¼Û±Ý, 1/nÃ»±¸, È¸ºñ°È±â! ÀÌ¸ÞÀÏ ÇÑÅëÀ¸·Î ÇØ°áÇÑ´Ù
¢Ñ ¸ÞÀÏ¹ðÅ· http://mailbank.daum.net/

From Black_David@emc.com  Tue Nov 27 19:36:00 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA14665
	for <saag@jis.mit.edu>; Tue, 27 Nov 2001 19:36:00 -0500 (EST)
From: Black_David@emc.com
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA05963
	for <saag@mit.edu>; Tue, 27 Nov 2001 19:35:59 -0500 (EST)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <W739C42S>; Tue, 27 Nov 2001 19:31:37 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14>
To: ipsec@lists.tislabs.com, saag@mit.edu
Date: Tue, 27 Nov 2001 19:25:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [saag] IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Picking up a baseball bat and carefully drawing a bead on
the hornet's nest ...

Over in the IP Storage (ips) WG, we're picking up a subset
of IPsec (primarily ESP and IKE) to provide security for
our protocols (TCP/IP encapsulations of SCSI and Fibre
Channel - iSCSI, FCIP, and iFCP).  This approach is being
used in order to avoid putting out new protocol standards
that require things like DES and AH (comments in favor
of DES and/or AH should be sent to /dev/null ;-) ).

From a protocol specification standpoint, the IPS WG is
not prepared to require Integrated or Bump In The
Stack implementations of IPsec.  In other words, the
WG does not want to foreclose the ability to take an IP
Storage protocol implementation without IPsec, hook it up
directly to a security gateway IPsec implementation and
obtain a result from the combination that complies with
the security requirements of the IPS protocol specification.
The protocol on the link between the IP Storage implementation
and its security gateway would NOT be compliant because
it would lack required security functionality (this latter
point was explained at length by the IESG in the London
plenary).

Since IP Storage implementations could be based on host or
security gateway implementations of IPsec, the appropriate
thing to do in the IP Storage drafts appears to be to
REQUIRE tunnel mode as the encapsulation mode that
must be present for interoperability because it is the
common mode required by both classes of IPsec implementations.
OTOH, I've heard concerns that tunnel mode may not provide
a suitable bias towards end-to-end security - it's not that
difficult to terminate an IPsec tunnel someplace other than
the far end of the communication session running through it.
OTOOH, this concern strikes me as a policy issue - if some
node other than the far end can terminate the IPsec tunnel,
that node must have the keying material required to set up
the tunnel mode SA in the first place.  In turn that
reflects a conscious security policy decision by the
administrator who configured that material into that
intermediate node and got exactly what s/he asked for.
This policy aspect is unavoidable, as the only way to
remove this option (tunnel mode to a gateway not at
the far end) from the admin's hands is to forbid
tunnel mode, which seems like a really bad idea.

I'm looking for comments, advice, and insight on this
issue (which mode to REQUIRE) in the hope of resolving it
in Salt Lake City in a fashion that won't come back to
cause problems in IETF Last Call.  For more information
on IPS Security, see draft-ietf-ips-security-06.txt (-05
if -06 hasn't hit the servers yet).

Thanks,
--David (IPS WG co-chair)

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

From srao@intotoinc.com  Tue Nov 27 22:23:10 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA16259
	for <saag@jis.mit.edu>; Tue, 27 Nov 2001 22:23:10 -0500 (EST)
Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA18131
	for <saag@mit.edu>; Tue, 27 Nov 2001 22:23:09 -0500 (EST)
Received: from localhost (srao@localhost)
	by intotoinc.com (8.11.0/8.11.0) with ESMTP id fAS3O1b17964;
	Tue, 27 Nov 2001 19:24:01 -0800
Date: Tue, 27 Nov 2001 19:24:01 -0800 (PST)
From: Srinivasa Addepalli <srao@intotoinc.com>
To: Black_David@emc.com
cc: ipsec@lists.tislabs.com, saag@mit.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14>
Message-ID: <Pine.LNX.4.21.0111271907310.17764-100000@intotoinc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [saag] Re: IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hi David,
   It seems to me that this is policy and deployment issue.
   It seems that you have following scenario:


StorageClient---Router1-----(Internet)------Router2-----StorageSrvr

   StorageClient and StorageSrvr terminate iSCSI connection.
   If end-to-end security is needed, then both client and
   server should be IPSEC enabled. In this particular case, these
   are IPSEC hosts and as per IPSEC standard, a host MUST support both
   transport and tunnel modes.

   If end-to-end security is not needed, then Router1 and router2
   can be IPSEC enabled. In this case, tunnel mode is required in
   Router1 and Router2.

   Alternatively, IPSEC session can be between StorageClient and
   router2 OR Router1 to StorageServer. In these two cases, tunnel
   mode is required.

   If IPS group likes to allow only end-to-end security and avoid
   any admin mistakes, then transport mode can be made MUST. But
   I am not sure whether somebody would like to do that.

Srini



On Tue, 27 Nov 2001 Black_David@emc.com wrote:

> Picking up a baseball bat and carefully drawing a bead on
> the hornet's nest ...
> 
> Over in the IP Storage (ips) WG, we're picking up a subset
> of IPsec (primarily ESP and IKE) to provide security for
> our protocols (TCP/IP encapsulations of SCSI and Fibre
> Channel - iSCSI, FCIP, and iFCP).  This approach is being
> used in order to avoid putting out new protocol standards
> that require things like DES and AH (comments in favor
> of DES and/or AH should be sent to /dev/null ;-) ).
> 
> >From a protocol specification standpoint, the IPS WG is
> not prepared to require Integrated or Bump In The
> Stack implementations of IPsec.  In other words, the
> WG does not want to foreclose the ability to take an IP
> Storage protocol implementation without IPsec, hook it up
> directly to a security gateway IPsec implementation and
> obtain a result from the combination that complies with
> the security requirements of the IPS protocol specification.
> The protocol on the link between the IP Storage implementation
> and its security gateway would NOT be compliant because
> it would lack required security functionality (this latter
> point was explained at length by the IESG in the London
> plenary).
> 
> Since IP Storage implementations could be based on host or
> security gateway implementations of IPsec, the appropriate
> thing to do in the IP Storage drafts appears to be to
> REQUIRE tunnel mode as the encapsulation mode that
> must be present for interoperability because it is the
> common mode required by both classes of IPsec implementations.
> OTOH, I've heard concerns that tunnel mode may not provide
> a suitable bias towards end-to-end security - it's not that
> difficult to terminate an IPsec tunnel someplace other than
> the far end of the communication session running through it.
> OTOOH, this concern strikes me as a policy issue - if some
> node other than the far end can terminate the IPsec tunnel,
> that node must have the keying material required to set up
> the tunnel mode SA in the first place.  In turn that
> reflects a conscious security policy decision by the
> administrator who configured that material into that
> intermediate node and got exactly what s/he asked for.
> This policy aspect is unavoidable, as the only way to
> remove this option (tunnel mode to a gateway not at
> the far end) from the admin's hands is to forbid
> tunnel mode, which seems like a really bad idea.
> 
> I'm looking for comments, advice, and insight on this
> issue (which mode to REQUIRE) in the hope of resolving it
> in Salt Lake City in a fashion that won't come back to
> cause problems in IETF Last Call.  For more information
> on IPS Security, see draft-ietf-ips-security-06.txt (-05
> if -06 hasn't hit the servers yet).
> 
> Thanks,
> --David (IPS WG co-chair)
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 

-- 
Srinivasa Rao Addepalli
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
USA
Ph: 408-844-0480 x317


From azinin@nexsi.com  Wed Nov 28 02:46:43 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA18832
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 02:46:43 -0500 (EST)
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA12874
	for <saag@MIT.EDU>; Wed, 28 Nov 2001 02:46:42 -0500 (EST)
Received: from mail.nexsi.com (mail.nexsi.com [172.16.0.54])
	by relay1.nexsi.com (Postfix) with ESMTP id A33693F65
	for <saag@MIT.EDU>; Tue, 27 Nov 2001 23:48:48 -0800 (PST)
Received: from khonsu.sw.nexsi.com (cscovpn0.nexsi.com [172.16.213.0])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id XAA16870
	for <saag@MIT.EDU>; Tue, 27 Nov 2001 23:49:54 -0800
Date: Tue, 27 Nov 2001 23:49:53 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <12738887757.20011127234953@nexsi.com>
To: saag@MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [saag] Recommended Authentication Mechanism
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hello,

  I'd like to ask the SAAG about the recommended authentication
  mechanism for an IP-based protocol with two entities per session.

  The protocol runs directly over IP and we can have an
  authentication field in the packets (in fact, the proto is already
  "patched" with MD5, but we do understand it is not good enough).

  If I recall the security tutorial slides correctly, HMAC is
  suggested for simple authentication. Is this still the case
  or should we go with IPSec? If HMAC is recommended, what about
  the replay attacks?

  BTW, at the meeting in London I suggested to Rob Coltun that
  that we  should have a security requirement document for routing
  and signaling protocols. Is there a document of this kind
  reflecting SAAG's position?

  Thanks,

-- 
Alex Zinin



From rja@inet.org  Wed Nov 28 09:17:28 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA22212
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 09:17:27 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA12983
	for <saag@mit.edu>; Wed, 28 Nov 2001 09:17:27 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id E15466710A; Wed, 28 Nov 2001 09:23:37 -0500 (EST)
Message-Id: <5.1.0.14.2.20011128090413.00a05590@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 28 Nov 2001 09:07:37 -0500
To: saag@mit.edu
From: RJ Atkinson <rja@inet.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [saag] RE: draft-ietf-dhc-vpn-option-01.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

>        Title           : DHCP VPN Information option
>        Author(s)       : R. Johnson, K. Kinnear, M. Stapp, J. Kumarasamy
>        Filename        : draft-ietf-dhc-vpn-option-01.txt
>        Pages           : 6
>        Date            : 27-Nov-01
>        
>This memo defines a new DHCP option for passing VPN information
>between the DHCP client and the DHCP server.  It is intended for use
>primarily by DHCP proxy clients in situations where VPN information
>needs to be passed to the DHCP server for proper address allocation
>to take place.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-01.txt

        IMHO, the proposed DHCP option above is too dangerous to let it 
go out as an RFC -- unless/until DHCP has some reasonable cryptographic 
authentication mechanism standardised AND anyone who implements this 
DHCP option MUST IMPLEMENT such cryptographic authentication in their
DHCP server/client.  I had thought that there was work by Ralph Droms
on DHCP Authentication, though the above draft's text indicates otherwise.

Ran
rja@inet.org


From rja@inet.org  Wed Nov 28 09:19:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA22264
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 09:19:50 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA13792
	for <saag@MIT.EDU>; Wed, 28 Nov 2001 09:19:49 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id E36AE6710A; Wed, 28 Nov 2001 09:26:00 -0500 (EST)
Message-Id: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 28 Nov 2001 09:10:00 -0500
To: Alex Zinin <azinin@nexsi.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Recommended Authentication Mechanism
Cc: saag@MIT.EDU
In-Reply-To: <12738887757.20011127234953@nexsi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 02:49 28/11/01, Alex Zinin wrote:
>Hello,
>
>  I'd like to ask the SAAG about the recommended authentication
>  mechanism for an IP-based protocol with two entities per session.
>
>  The protocol runs directly over IP and we can have an
>  authentication field in the packets (in fact, the proto is already
>  "patched" with MD5, but we do understand it is not good enough).

        Please don't be coy and do be very much more specific about 
precisely which protocol you are discussing.  Now is it OSPF or IS-IS 
or something else...

        Asked the way you just did, a wide range of answers might well
be valid, though none are likely to be tremendously meaningful.  Asked 
in a more specific way, a possibly different, possibly less wide range 
of answers might be valid.

Ran
rja@inet.org


From smb@research.att.com  Wed Nov 28 10:00:40 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA22709
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 10:00:40 -0500 (EST)
Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29204
	for <saag@mit.edu>; Wed, 28 Nov 2001 10:00:35 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 9339E7B55; Wed, 28 Nov 2001 10:00:34 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: RJ Atkinson <rja@inet.org>
Cc: Alex Zinin <azinin@nexsi.com>, saag@mit.edu
Subject: Re: [saag] Recommended Authentication Mechanism 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 28 Nov 2001 10:00:34 -0500
Message-Id: <20011128150034.9339E7B55@berkshire.research.att.com>
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

In message <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>, RJ Atkinson writes:
>At 02:49 28/11/01, Alex Zinin wrote:
>>Hello,
>>
>>  I'd like to ask the SAAG about the recommended authentication
>>  mechanism for an IP-based protocol with two entities per session.
>>
>>  The protocol runs directly over IP and we can have an
>>  authentication field in the packets (in fact, the proto is already
>>  "patched" with MD5, but we do understand it is not good enough).
>
>        Please don't be coy and do be very much more specific about 
>precisely which protocol you are discussing.  Now is it OSPF or IS-IS 
>or something else...
>
>        Asked the way you just did, a wide range of answers might well
>be valid, though none are likely to be tremendously meaningful.  Asked 
>in a more specific way, a possibly different, possibly less wide range 
>of answers might be valid.
>

Right.  There are a lot of subtle traps possible; the details are 
*very* important.


		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com



From azinin@nexsi.com  Wed Nov 28 10:40:40 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA23195
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 10:40:40 -0500 (EST)
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA15732
	for <saag@mit.edu>; Wed, 28 Nov 2001 10:40:39 -0500 (EST)
Received: from mail.nexsi.com (mail.nexsi.com [172.16.0.54])
	by relay1.nexsi.com (Postfix) with ESMTP
	id 7D0C53F62; Wed, 28 Nov 2001 07:42:45 -0800 (PST)
Received: from khonsu.sw.nexsi.com (cscovpn0.nexsi.com [172.16.213.0])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id HAA17992;
	Wed, 28 Nov 2001 07:43:49 -0800
Date: Wed, 28 Nov 2001 07:43:45 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <17667319189.20011128074345@nexsi.com>
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: RJ Atkinson <rja@inet.org>, saag@mit.edu
Subject: Re: [saag] Recommended Authentication Mechanism
In-Reply-To: <20011128150034.9339E7B55@berkshire.research.att.com>
References: <20011128150034.9339E7B55@berkshire.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Steven, Ran,

 No problem at all. Sorry for not being more specific before.
 I'm talking about LMP, hosted in CCAMP of Sub-IP area, see
 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-02.txt
 [It couldn't be OSPF or ISIS as those do not presume only
 two entities per session :)]

 Some more info:
   - the protocol runs between OXCs or btw routers and OXCs,
     i.e., it is a control plane protocol in an optical network
   - we're authenticating the control channel only
   - each session may span more than one hop
   - we do not need content encryption, only message authentication

 Let me know if you need more details, pls.
 Thanks.
-- 
Alex Zinin

Wednesday, November 28, 2001, 7:00:34 AM, Steven M. Bellovin wrote:

> In message <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>, RJ Atkinson writes:
>>At 02:49 28/11/01, Alex Zinin wrote:
>>>Hello,
>>>
>>>  I'd like to ask the SAAG about the recommended authentication
>>>  mechanism for an IP-based protocol with two entities per session.
>>>
>>>  The protocol runs directly over IP and we can have an
>>>  authentication field in the packets (in fact, the proto is already
>>>  "patched" with MD5, but we do understand it is not good enough).
>>
>>        Please don't be coy and do be very much more specific about 
>>precisely which protocol you are discussing.  Now is it OSPF or IS-IS 
>>or something else...
>>
>>        Asked the way you just did, a wide range of answers might well
>>be valid, though none are likely to be tremendously meaningful.  Asked 
>>in a more specific way, a possibly different, possibly less wide range 
>>of answers might be valid.
>>

> Right.  There are a lot of subtle traps possible; the details are 
> *very* important.


>                 --Steve Bellovin, http://www.research.att.com/~smb
>                 Full text of "Firewalls" book now at http://www.wilyhacker.com



From warlord@MIT.EDU  Wed Nov 28 11:01:44 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA23549
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 11:01:43 -0500 (EST)
Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA23035
	for <saag@mit.edu>; Wed, 28 Nov 2001 11:01:43 -0500 (EST)
Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3)
	id LAA30388; Wed, 28 Nov 2001 11:01:37 -0500
To: RJ Atkinson <rja@inet.org>
Cc: Alex Zinin <azinin@nexsi.com>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>
From: Derek Atkins <warlord@MIT.EDU>
Date: 28 Nov 2001 11:01:37 -0500
In-Reply-To: RJ Atkinson's message of "Wed, 28 Nov 2001 09:10:00 -0500"
Message-ID: <sjm8zcqx4ta.fsf@benjamin.ihtfp.org>
Lines: 42
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Regardless of whether it's OSPF or IS-IS, using AH (and associated
IPsec SA) will most likely do what you want..  Or, alternately,
you can use ESP authentication.  Do you want to be able to provide
privacy of your data as well as integrity?  What is your threat
model?

-derek

RJ Atkinson <rja@inet.org> writes:

> At 02:49 28/11/01, Alex Zinin wrote:
> >Hello,
> >
> >  I'd like to ask the SAAG about the recommended authentication
> >  mechanism for an IP-based protocol with two entities per session.
> >
> >  The protocol runs directly over IP and we can have an
> >  authentication field in the packets (in fact, the proto is already
> >  "patched" with MD5, but we do understand it is not good enough).
> 
>         Please don't be coy and do be very much more specific about 
> precisely which protocol you are discussing.  Now is it OSPF or IS-IS 
> or something else...
> 
>         Asked the way you just did, a wide range of answers might well
> be valid, though none are likely to be tremendously meaningful.  Asked 
> in a more specific way, a possibly different, possibly less wide range 
> of answers might be valid.
> 
> Ran
> rja@inet.org
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From azinin@nexsi.com  Wed Nov 28 13:15:44 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA25163
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 13:15:44 -0500 (EST)
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA21856;
	Wed, 28 Nov 2001 13:15:43 -0500 (EST)
Received: from mail.nexsi.com (mail.nexsi.com [172.16.0.54])
	by relay1.nexsi.com (Postfix) with ESMTP
	id 3BA6C3F64; Wed, 28 Nov 2001 10:17:49 -0800 (PST)
Received: from khonsu.sw.nexsi.com (dynam484.sw.nexsi.com [172.17.15.228])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA19031;
	Wed, 28 Nov 2001 10:18:55 -0800
Date: Wed, 28 Nov 2001 10:18:55 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <107490875.20011128101855@nexsi.com>
To: Derek Atkins <warlord@MIT.EDU>
Cc: RJ Atkinson <rja@inet.org>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
In-Reply-To: <sjm8zcqx4ta.fsf@benjamin.ihtfp.org>
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>
 <sjm8zcqx4ta.fsf@benjamin.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Derek,

  Let's leave OSPF and ISIS for another discussion and
  concentrate on LMP so far :) (see my previous message to
  the list).

  We do not need data confidentiality, only authentication
  and integrity check, so no encryption. The threat model can
  be briefly described as follows:
  
   - level of trust: depending on whether LMP is used for
     NNI or UNI/public-NNI, the peers can be under common
     or separate administration, so peers may be untrusted.
   
   - attackers: mostly outsiders; however, as a protocol
     session can span multiple hops (in cases where the
     the topology of the control network does not follow
     the data network one, and when used for UNI signalling),
     it is potentially possible to imagine a middleman attack.

   - attacks: definitely passive one, but again with no privacy
     or confidentiality, only those leading to active ones,
     i.e., key eavesdropping. Active attacks would include
     packet spoofing from outsiders and replay from the middleman.

  More data on request.
  Thanks a lot!
-- 
Alex Zinin

Wednesday, November 28, 2001, 8:01:37 AM, Derek Atkins wrote:

> Regardless of whether it's OSPF or IS-IS, using AH (and associated
> IPsec SA) will most likely do what you want..  Or, alternately,
> you can use ESP authentication.  Do you want to be able to provide
> privacy of your data as well as integrity?  What is your threat
> model?

> -derek

> RJ Atkinson <rja@inet.org> writes:

>> At 02:49 28/11/01, Alex Zinin wrote:
>> >Hello,
>> >
>> >  I'd like to ask the SAAG about the recommended authentication
>> >  mechanism for an IP-based protocol with two entities per session.
>> >
>> >  The protocol runs directly over IP and we can have an
>> >  authentication field in the packets (in fact, the proto is already
>> >  "patched" with MD5, but we do understand it is not good enough).
>> 
>>         Please don't be coy and do be very much more specific about 
>> precisely which protocol you are discussing.  Now is it OSPF or IS-IS 
>> or something else...
>> 
>>         Asked the way you just did, a wide range of answers might well
>> be valid, though none are likely to be tremendously meaningful.  Asked 
>> in a more specific way, a possibly different, possibly less wide range 
>> of answers might be valid.
>> 
>> Ran
>> rja@inet.org
>> 
>> _______________________________________________
>> saag mailing list
>> saag@mit.edu
>> http://jis.mit.edu/mailman/listinfo/saag



From Black_David@emc.com  Wed Nov 28 17:58:34 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA28340
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 17:58:34 -0500 (EST)
From: Black_David@emc.com
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22358
	for <saag@mit.edu>; Wed, 28 Nov 2001 17:58:34 -0500 (EST)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <THT9PXC7>; Wed, 28 Nov 2001 18:00:34 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14>
To: mat@cisco.com
Cc: ipsec@lists.tislabs.com, saag@mit.edu
Date: Wed, 28 Nov 2001 17:47:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [saag] RE: IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Since this is a host-host application layer
> protocol, that pretty much implies that you'd want
> to use transport mode, since you end up with the
> same IP src/dst addresses if you used tunnel mode,
> which sounds gratuitously redundant.

The configuration of interest is:

|--------------------------|    |---------------|
| IP Storage without IPsec |----| IPsec gateway |-->
|--------------------------|    |---------------|

Where the link between the two boxes is not attached
to anything else.  The only IPsec implementation on this
end of the connection is in the gateway, and the only
link in the above diagram that complies with the protocol
requirements is the link on the right hand side of the
gateway.  The gateway does not implement transport
mode, hence the interest in tunnel mode.

> Thus -- and I'm sorry this is rather circuitous --
> I really don't see what tunnel mode is buying over
> transport mode here, other than adding extra
> overhead and making things more confusing.

It's buying the above implementation approach in which
IPsec does not have to be implemented on the IP Storage
box in the diagram.

If IPsec were implemented on the IP Storage box, then one
wouldn't need the gateway for protocol compliance (although
it might be present for other reasons), and if both ends
of the connection implemented IPsec in that fashion, then
transport mode would be the more efficient choice for the
end-to-end SA (but that's a policy decision, and negotiable
via IKE).  Please note the two "if"s in the previous sentence;
the IPS WG is currently reluctant to impose them as
requirements on all implementations.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, November 28, 2001 3:36 PM
> To: Black_David@emc.com
> Cc: ipsec@lists.tislabs.com; saag@mit.edu
> Subject: IP Storage and IPsec encapsulation
> 
> 
> 
> Let me see if I understand this: you don't want to
> preclude the use of security gateways. Fine,
> that's impossible to do anyway. You say that a
> host which doesn't implement some TBD profile of
> IPsec wouldn't be compliant with the draft. Fine,
> nothing that affects either intermediate security
> gateways or the choice of tunnel or transport
> mode. Since this is a host-host application layer
> protocol, that pretty much implies that you'd want
> to use transport mode, since you end up with the
> same IP src/dst addresses if you used tunnel mode,
> which sounds gratuitously redundant.
> 
> Now, if you wanted colocate your IP storage box
> with a security gateway so that you can attach it
> to another security gateway -- possibly in a
> non-compliant arrangement -- you might want to
> have a tunnel. However, there is nothing to
> prevent such a box to still be compliant since you
> can always place IPsec protected packets
> (transport) into an IPsec tunnel. This doesn't
> require anything new as it's just a standard
> feature of RFC 2401. 
> 
> Thus -- and I'm sorry this is rather circuitous --
> I really don't see what tunnel mode is buying over
> transport mode here, other than adding extra
> overhead and making things more confusing.
> 
> 	     Mike
> 
> Black_David@emc.com writes:
>  > Picking up a baseball bat and carefully drawing a bead on
>  > the hornet's nest ...
>  > 
>  > Over in the IP Storage (ips) WG, we're picking up a subset
>  > of IPsec (primarily ESP and IKE) to provide security for
>  > our protocols (TCP/IP encapsulations of SCSI and Fibre
>  > Channel - iSCSI, FCIP, and iFCP).  This approach is being
>  > used in order to avoid putting out new protocol standards
>  > that require things like DES and AH (comments in favor
>  > of DES and/or AH should be sent to /dev/null ;-) ).
>  > 
>  > >From a protocol specification standpoint, the IPS WG is
>  > not prepared to require Integrated or Bump In The
>  > Stack implementations of IPsec.  In other words, the
>  > WG does not want to foreclose the ability to take an IP
>  > Storage protocol implementation without IPsec, hook it up
>  > directly to a security gateway IPsec implementation and
>  > obtain a result from the combination that complies with
>  > the security requirements of the IPS protocol specification.
>  > The protocol on the link between the IP Storage implementation
>  > and its security gateway would NOT be compliant because
>  > it would lack required security functionality (this latter
>  > point was explained at length by the IESG in the London
>  > plenary).
>  > 
>  > Since IP Storage implementations could be based on host or
>  > security gateway implementations of IPsec, the appropriate
>  > thing to do in the IP Storage drafts appears to be to
>  > REQUIRE tunnel mode as the encapsulation mode that
>  > must be present for interoperability because it is the
>  > common mode required by both classes of IPsec implementations.
>  > OTOH, I've heard concerns that tunnel mode may not provide
>  > a suitable bias towards end-to-end security - it's not that
>  > difficult to terminate an IPsec tunnel someplace other than
>  > the far end of the communication session running through it.
>  > OTOOH, this concern strikes me as a policy issue - if some
>  > node other than the far end can terminate the IPsec tunnel,
>  > that node must have the keying material required to set up
>  > the tunnel mode SA in the first place.  In turn that
>  > reflects a conscious security policy decision by the
>  > administrator who configured that material into that
>  > intermediate node and got exactly what s/he asked for.
>  > This policy aspect is unavoidable, as the only way to
>  > remove this option (tunnel mode to a gateway not at
>  > the far end) from the admin's hands is to forbid
>  > tunnel mode, which seems like a really bad idea.
>  > 
>  > I'm looking for comments, advice, and insight on this
>  > issue (which mode to REQUIRE) in the hope of resolving it
>  > in Salt Lake City in a fashion that won't come back to
>  > cause problems in IETF Last Call.  For more information
>  > on IPS Security, see draft-ietf-ips-security-06.txt (-05
>  > if -06 hasn't hit the servers yet).
>  > 
>  > Thanks,
>  > --David (IPS WG co-chair)
>  > 
>  > ---------------------------------------------------
>  > David L. Black, Senior Technologist
>  > EMC Corporation, 42 South St., Hopkinton, MA  01748
>  > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
>  > black_david@emc.com       Mobile: +1 (978) 394-7754
>  > ---------------------------------------------------
> 

From thomasm@cisco.com  Wed Nov 28 15:36:31 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA26677
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 15:36:31 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA19929
	for <saag@mit.edu>; Wed, 28 Nov 2001 15:36:30 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fASKZqd09762;
	Wed, 28 Nov 2001 12:35:53 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAK30744;
	Wed, 28 Nov 2001 12:35:17 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26681; Wed, 28 Nov 2001 12:35:51 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15365.19111.840356.297735@thomasm-u1.cisco.com>
Date: Wed, 28 Nov 2001 12:35:51 -0800 (PST)
To: Black_David@emc.com
Cc: ipsec@lists.tislabs.com, saag@mit.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14>
References: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Subject: [saag] IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Let me see if I understand this: you don't want to
preclude the use of security gateways. Fine,
that's impossible to do anyway. You say that a
host which doesn't implement some TBD profile of
IPsec wouldn't be compliant with the draft. Fine,
nothing that affects either intermediate security
gateways or the choice of tunnel or transport
mode. Since this is a host-host application layer
protocol, that pretty much implies that you'd want
to use transport mode, since you end up with the
same IP src/dst addresses if you used tunnel mode,
which sounds gratuitously redundant.

Now, if you wanted colocate your IP storage box
with a security gateway so that you can attach it
to another security gateway -- possibly in a
non-compliant arrangement -- you might want to
have a tunnel. However, there is nothing to
prevent such a box to still be compliant since you
can always place IPsec protected packets
(transport) into an IPsec tunnel. This doesn't
require anything new as it's just a standard
feature of RFC 2401. 

Thus -- and I'm sorry this is rather circuitous --
I really don't see what tunnel mode is buying over
transport mode here, other than adding extra
overhead and making things more confusing.

	     Mike

Black_David@emc.com writes:
 > Picking up a baseball bat and carefully drawing a bead on
 > the hornet's nest ...
 > 
 > Over in the IP Storage (ips) WG, we're picking up a subset
 > of IPsec (primarily ESP and IKE) to provide security for
 > our protocols (TCP/IP encapsulations of SCSI and Fibre
 > Channel - iSCSI, FCIP, and iFCP).  This approach is being
 > used in order to avoid putting out new protocol standards
 > that require things like DES and AH (comments in favor
 > of DES and/or AH should be sent to /dev/null ;-) ).
 > 
 > >From a protocol specification standpoint, the IPS WG is
 > not prepared to require Integrated or Bump In The
 > Stack implementations of IPsec.  In other words, the
 > WG does not want to foreclose the ability to take an IP
 > Storage protocol implementation without IPsec, hook it up
 > directly to a security gateway IPsec implementation and
 > obtain a result from the combination that complies with
 > the security requirements of the IPS protocol specification.
 > The protocol on the link between the IP Storage implementation
 > and its security gateway would NOT be compliant because
 > it would lack required security functionality (this latter
 > point was explained at length by the IESG in the London
 > plenary).
 > 
 > Since IP Storage implementations could be based on host or
 > security gateway implementations of IPsec, the appropriate
 > thing to do in the IP Storage drafts appears to be to
 > REQUIRE tunnel mode as the encapsulation mode that
 > must be present for interoperability because it is the
 > common mode required by both classes of IPsec implementations.
 > OTOH, I've heard concerns that tunnel mode may not provide
 > a suitable bias towards end-to-end security - it's not that
 > difficult to terminate an IPsec tunnel someplace other than
 > the far end of the communication session running through it.
 > OTOOH, this concern strikes me as a policy issue - if some
 > node other than the far end can terminate the IPsec tunnel,
 > that node must have the keying material required to set up
 > the tunnel mode SA in the first place.  In turn that
 > reflects a conscious security policy decision by the
 > administrator who configured that material into that
 > intermediate node and got exactly what s/he asked for.
 > This policy aspect is unavoidable, as the only way to
 > remove this option (tunnel mode to a gateway not at
 > the far end) from the admin's hands is to forbid
 > tunnel mode, which seems like a really bad idea.
 > 
 > I'm looking for comments, advice, and insight on this
 > issue (which mode to REQUIRE) in the hope of resolving it
 > in Salt Lake City in a fashion that won't come back to
 > cause problems in IETF Last Call.  For more information
 > on IPS Security, see draft-ietf-ips-security-06.txt (-05
 > if -06 hasn't hit the servers yet).
 > 
 > Thanks,
 > --David (IPS WG co-chair)
 > 
 > ---------------------------------------------------
 > David L. Black, Senior Technologist
 > EMC Corporation, 42 South St., Hopkinton, MA  01748
 > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
 > black_david@emc.com       Mobile: +1 (978) 394-7754
 > ---------------------------------------------------

From rja@inet.org  Wed Nov 28 19:53:28 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA29649
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 19:53:27 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA25866
	for <saag@mit.edu>; Wed, 28 Nov 2001 19:53:27 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id DD4CC67103; Wed, 28 Nov 2001 19:59:41 -0500 (EST)
Message-Id: <5.1.0.14.2.20011128194044.009feec0@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 28 Nov 2001 19:43:36 -0500
To: Black_David@emc.com
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
Cc: ipsec@lists.tislabs.com, saag@mit.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 17:47 28/11/01, Black_David@emc.com wrote:
>The configuration of interest is:
>
>|--------------------------|    |---------------|
>| IP Storage without IPsec |----| IPsec gateway |-->
>|--------------------------|    |---------------|
>
>Where the link between the two boxes is not attached
>to anything else.  The only IPsec implementation on this
>end of the connection is in the gateway, and the only
>link in the above diagram that complies with the protocol
>requirements is the link on the right hand side of the
>gateway.  The gateway does not implement transport
>mode, hence the interest in tunnel mode.

IP Storage really really needs end-to-end security IMNVHO.

So I think the above is just a bogus implementer being lazy
rather than a valid security architecture.  The above can't
provide the kinds of end-to-end security properties that 
one needs for IP Storage applications.

The IETF went through a similar discussion in the NFS context,
concluding in that case that fine-grained end-to-end security
properties were needed.  The above can't even coarsely approximate
what NFS (which has lots of similarities to IP Storage otherwise)
was required to provide to be on the IETF standards-track.

Ran
rja@inet.org




From Black_David@emc.com  Wed Nov 28 20:21:36 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA00030
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 20:21:36 -0500 (EST)
From: Black_David@emc.com
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA26872
	for <saag@mit.edu>; Wed, 28 Nov 2001 20:21:36 -0500 (EST)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <THT9P61S>; Wed, 28 Nov 2001 20:23:36 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E02937211@CORPMX14>
To: rja@inet.org
Cc: ipsec@lists.tislabs.com, saag@mit.edu
Subject: RE: [saag] RE: IP Storage and IPsec encapsulation
Date: Wed, 28 Nov 2001 20:10:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Aha, found the hornet's nest ...

> >The configuration of interest is:
> >
> >|--------------------------|    |---------------|
> >| IP Storage without IPsec |----| IPsec gateway |-->
> >|--------------------------|    |---------------|
> >
> >Where the link between the two boxes is not attached
> >to anything else.  The only IPsec implementation on this
> >end of the connection is in the gateway, and the only
> >link in the above diagram that complies with the protocol
> >requirements is the link on the right hand side of the
> >gateway.  The gateway does not implement transport
> >mode, hence the interest in tunnel mode.
>
> IP Storage really really needs end-to-end security IMNVHO.
> 
> So I think the above is just a bogus implementer being lazy
> rather than a valid security architecture.  The above can't
> provide the kinds of end-to-end security properties that 
> one needs for IP Storage applications.

Could you be specific about what can't be provided, and how
requiring transport mode would force/encourage it to be provided?

> The IETF went through a similar discussion in the NFS context,
> concluding in that case that fine-grained end-to-end security
> properties were needed.  The above can't even coarsely approximate
> what NFS (which has lots of similarities to IP Storage otherwise)
> was required to provide to be on the IETF standards-track.

NFS is not the best analogy because NFS is an RPC-oriented protocol
for which it makes sense to provide security at the granularity of
individual RPCs, as a (user) identity can be associated with each
RPC.  The IP Storage protocols are TCP/IP encapsulations of SCSI
and Fibre Channel -- these are session-oriented protocols for which
it does not make sense to provide security at a granularity finer
than a session as a (machine) identity is associated with each session,
but no other finer-grain identities are associated with individual
commands/messages/operations/etc. within a session.

In the above diagram, a separate phase 2 SA would be required for
every TCP connection (i.e., the typical security gateway behavior
of running all traffic destined for the same remote gateway through
the same tunnel would not be compliant); this is at least session
granularity, and potentially finer grain depending on how sessions
are formed and how phase 2 SAs are associated with phase 1 SAs.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: RJ Atkinson [mailto:rja@inet.org]
> Sent: Wednesday, November 28, 2001 7:44 PM
> To: Black_David@emc.com
> Cc: ipsec@lists.tislabs.com; saag@mit.edu
> Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
> 
> 
> At 17:47 28/11/01, Black_David@emc.com wrote:
> >The configuration of interest is:
> >
> >|--------------------------|    |---------------|
> >| IP Storage without IPsec |----| IPsec gateway |-->
> >|--------------------------|    |---------------|
> >
> >Where the link between the two boxes is not attached
> >to anything else.  The only IPsec implementation on this
> >end of the connection is in the gateway, and the only
> >link in the above diagram that complies with the protocol
> >requirements is the link on the right hand side of the
> >gateway.  The gateway does not implement transport
> >mode, hence the interest in tunnel mode.
> 
> IP Storage really really needs end-to-end security IMNVHO.
> 
> So I think the above is just a bogus implementer being lazy
> rather than a valid security architecture.  The above can't
> provide the kinds of end-to-end security properties that 
> one needs for IP Storage applications.
> 
> The IETF went through a similar discussion in the NFS context,
> concluding in that case that fine-grained end-to-end security
> properties were needed.  The above can't even coarsely approximate
> what NFS (which has lots of similarities to IP Storage otherwise)
> was required to provide to be on the IETF standards-track.
> 
> Ran
> rja@inet.org
> 
> 
> 

From rja@inet.org  Wed Nov 28 20:58:55 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA00514
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 20:58:55 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA07210
	for <saag@mit.edu>; Wed, 28 Nov 2001 20:58:54 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id A80CA67103; Wed, 28 Nov 2001 21:05:09 -0500 (EST)
Message-Id: <5.1.0.14.2.20011128204452.009fbec0@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 28 Nov 2001 20:48:56 -0500
To: Black_David@emc.com
From: RJ Atkinson <rja@inet.org>
Subject: RE: [saag] RE: IP Storage and IPsec encapsulation
Cc: saag@mit.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937211@CORPMX14>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 20:10 28/11/01, Black_David@emc.com wrote:
>Could you be specific about what can't be provided, and how
>requiring transport mode would force/encourage it to be provided?

If one is using transport-mode, one knows that the end point is
really the end point.  And that end point can use fine-grained
identities in the IPsec Security Association that are not available
to a tunnel-mode (in the scenario you outlined) because that
granularity of identity information is only knowable inside the
trusted computing base of the originating system.

>NFS is not the best analogy because NFS is an RPC-oriented protocol
>for which it makes sense to provide security at the granularity of
>individual RPCs, as a (user) identity can be associated with each
>RPC.  The IP Storage protocols are TCP/IP encapsulations of SCSI
>and Fibre Channel -- these are session-oriented protocols for which
>it does not make sense to provide security at a granularity finer
>than a session as a (machine) identity is associated with each session,
>but no other finer-grain identities are associated with individual
>commands/messages/operations/etc. within a session.

I don't believe the above is strictly the case.  In any event,
the session-level granularity you say is needed can't be provided
by a security gateway in the model you described (perhaps there
are more details in your head but not in the email that would change
this ?).

>In the above diagram, a separate phase 2 SA would be required for
>every TCP connection (i.e., the typical security gateway behavior
>of running all traffic destined for the same remote gateway through
>the same tunnel would not be compliant); this is at least session
>granularity, 

        Not necessarily.  Perhaps you are using a different
definition of "session" ?

>and potentially finer grain depending on how sessions
>are formed and how phase 2 SAs are associated with phase 1 SAs.

        Fine-grained isn't available because the remote KM
instance can't know the identities in a fine-grained way
if they aren't local to the remote KM box's trusted computing
base.

Ran
rja@inet.org
 


From azinin@nexsi.com  Wed Nov 28 22:34:45 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA01565
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 22:34:45 -0500 (EST)
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA05003;
	Wed, 28 Nov 2001 22:34:44 -0500 (EST)
Received: from mail.nexsi.com (mail.nexsi.com [172.16.0.54])
	by relay1.nexsi.com (Postfix) with ESMTP
	id 9D04F3F62; Wed, 28 Nov 2001 19:36:50 -0800 (PST)
Received: from khonsu.sw.nexsi.com (dynam484.sw.nexsi.com [172.17.15.228])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id TAA24817;
	Wed, 28 Nov 2001 19:37:56 -0800
Date: Wed, 28 Nov 2001 19:37:56 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <11911081133.20011128193756@nexsi.com>
To: Derek Atkins <warlord@MIT.EDU>
Cc: RJ Atkinson <rja@inet.org>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
In-Reply-To: <sjm8zcqx4ta.fsf@benjamin.ihtfp.org>
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>
 <sjm8zcqx4ta.fsf@benjamin.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> Regardless of whether it's OSPF or IS-IS, using AH (and associated
> IPsec SA) will most likely do what you want.. Or, alternately,
> you can use ESP authentication.

Should this be considered as the SAAG recommendation?

Alex.



From warlord@MIT.EDU  Wed Nov 28 22:48:29 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA01728
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 22:48:29 -0500 (EST)
Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA07760
	for <saag@MIT.EDU>; Wed, 28 Nov 2001 22:48:28 -0500 (EST)
Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3)
	id WAA16367; Wed, 28 Nov 2001 22:48:27 -0500
To: Alex Zinin <azinin@nexsi.com>
Cc: RJ Atkinson <rja@inet.org>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3> <sjm8zcqx4ta.fsf@benjamin.ihtfp.org> <11911081133.20011128193756@nexsi.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 28 Nov 2001 22:48:27 -0500
In-Reply-To: Alex Zinin's message of "Wed, 28 Nov 2001 19:37:56 -0800"
Message-ID: <sjm4rneutis.fsf@benjamin.ihtfp.org>
Lines: 21
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Alex Zinin <azinin@nexsi.com> writes:

> > Regardless of whether it's OSPF or IS-IS, using AH (and associated
> > IPsec SA) will most likely do what you want.. Or, alternately,
> > you can use ESP authentication.
> 
> Should this be considered as the SAAG recommendation?

Probably not, at least until after SLC in a couple weeks.  I certainly
do not feel like I speak for the SAAG, although there may be rough
consensus agreeing with what I said.

> Alex.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From azinin@nexsi.com  Wed Nov 28 22:57:15 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA01811
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 22:57:15 -0500 (EST)
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA09401;
	Wed, 28 Nov 2001 22:57:15 -0500 (EST)
Received: from mail.nexsi.com (mail.nexsi.com [172.16.0.54])
	by relay1.nexsi.com (Postfix) with ESMTP
	id 4A5EA3F65; Wed, 28 Nov 2001 19:59:21 -0800 (PST)
Received: from khonsu.sw.nexsi.com (dynam484.sw.nexsi.com [172.17.15.228])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id UAA24913;
	Wed, 28 Nov 2001 20:00:27 -0800
Date: Wed, 28 Nov 2001 20:00:27 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <9312431836.20011128200027@nexsi.com>
To: Derek Atkins <warlord@MIT.EDU>
Cc: RJ Atkinson <rja@inet.org>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
In-Reply-To: <sjm4rneutis.fsf@benjamin.ihtfp.org>
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>
 <sjm8zcqx4ta.fsf@benjamin.ihtfp.org> <11911081133.20011128193756@nexsi.com>
 <sjm4rneutis.fsf@benjamin.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Derek,

>> Should this be considered as the SAAG recommendation?

> Probably not, at least until after SLC in a couple weeks.  I certainly
> do not feel like I speak for the SAAG, although there may be rough
> consensus agreeing with what I said.

Do you mean SAAG should discuss this matter there?
The document is going through the WG last call and I'd
like to fix this part sooner than later, if possible,
of course.

Thanks!

Alex.



From warlord@MIT.EDU  Wed Nov 28 23:14:22 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA02080
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 23:14:22 -0500 (EST)
Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA12732
	for <saag@MIT.EDU>; Wed, 28 Nov 2001 23:10:24 -0500 (EST)
Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3)
	id XAA21481; Wed, 28 Nov 2001 23:10:23 -0500
To: Alex Zinin <azinin@nexsi.com>
Cc: RJ Atkinson <rja@inet.org>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3> <sjm8zcqx4ta.fsf@benjamin.ihtfp.org> <11911081133.20011128193756@nexsi.com> <sjm4rneutis.fsf@benjamin.ihtfp.org> <9312431836.20011128200027@nexsi.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 28 Nov 2001 23:10:23 -0500
In-Reply-To: Alex Zinin's message of "Wed, 28 Nov 2001 20:00:27 -0800"
Message-ID: <sjmy9kqtdxs.fsf@benjamin.ihtfp.org>
Lines: 35
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

What I mean is that I, personally, do not speak for SAAG.  This
means that you should not take my opinion as the SAAG consensus.
I also suspect that there will not be SAAG consensus until SLC,
at which time we _can_ discuss this, if you wish to bring it up.

You might want to contact the ADs and ask them directly.

-derek

Alex Zinin <azinin@nexsi.com> writes:

> Derek,
> 
> >> Should this be considered as the SAAG recommendation?
> 
> > Probably not, at least until after SLC in a couple weeks.  I certainly
> > do not feel like I speak for the SAAG, although there may be rough
> > consensus agreeing with what I said.
> 
> Do you mean SAAG should discuss this matter there?
> The document is going through the WG last call and I'd
> like to fix this part sooner than later, if possible,
> of course.
> 
> Thanks!
> 
> Alex.
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

From azinin@nexsi.com  Wed Nov 28 23:23:01 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA02184
	for <saag@jis.mit.edu>; Wed, 28 Nov 2001 23:23:01 -0500 (EST)
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA15602;
	Wed, 28 Nov 2001 23:23:00 -0500 (EST)
Received: from mail.nexsi.com (mail.nexsi.com [172.16.0.54])
	by relay1.nexsi.com (Postfix) with ESMTP
	id 87CE03F64; Wed, 28 Nov 2001 20:25:06 -0800 (PST)
Received: from khonsu.sw.nexsi.com (dynam484.sw.nexsi.com [172.17.15.228])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id UAA25042;
	Wed, 28 Nov 2001 20:26:12 -0800
Date: Wed, 28 Nov 2001 20:26:12 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <813976937.20011128202612@nexsi.com>
To: Derek Atkins <warlord@MIT.EDU>
Cc: RJ Atkinson <rja@inet.org>, saag@MIT.EDU
Subject: Re: [saag] Recommended Authentication Mechanism
In-Reply-To: <sjmy9kqtdxs.fsf@benjamin.ihtfp.org>
References: <5.1.0.14.2.20011128090812.01db5bd0@10.30.15.3>
 <sjm8zcqx4ta.fsf@benjamin.ihtfp.org> <11911081133.20011128193756@nexsi.com>
 <sjm4rneutis.fsf@benjamin.ihtfp.org> <9312431836.20011128200027@nexsi.com>
 <sjmy9kqtdxs.fsf@benjamin.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> What I mean is that I, personally, do not speak for SAAG.  This
> means that you should not take my opinion as the SAAG consensus.
> I also suspect that there will not be SAAG consensus until SLC,
> at which time we _can_ discuss this, if you wish to bring it up.

> You might want to contact the ADs and ask them directly.

Thanks, I will.

Alex.



From kent@bbn.com  Thu Nov 29 11:07:25 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA08690
	for <saag@jis.mit.edu>; Thu, 29 Nov 2001 11:07:25 -0500 (EST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28932
	for <saag@mit.edu>; Thu, 29 Nov 2001 11:07:24 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA04393;
	Thu, 29 Nov 2001 11:05:53 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010400b82c0b16e7ad@[128.89.88.34]>
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14>
References: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14>
Date: Thu, 29 Nov 2001 10:57:51 -0500
To: Black_David@emc.com
From: Stephen Kent <kent@bbn.com>
Subject: [saag] RE: IP Storage and IPsec encapsulation
Cc: mat@cisco.com, ipsec@lists.tislabs.com, saag@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 5:47 PM -0500 11/28/01, Black_David@emc.com wrote:
>  > Since this is a host-host application layer
>>  protocol, that pretty much implies that you'd want
>>  to use transport mode, since you end up with the
>>  same IP src/dst addresses if you used tunnel mode,
>>  which sounds gratuitously redundant.
>
>The configuration of interest is:
>
>|--------------------------|    |---------------|
>| IP Storage without IPsec |----| IPsec gateway |-->
>|--------------------------|    |---------------|
>
>Where the link between the two boxes is not attached
>to anything else.  The only IPsec implementation on this
>end of the connection is in the gateway, and the only
>link in the above diagram that complies with the protocol
>requirements is the link on the right hand side of the
>gateway.  The gateway does not implement transport
>mode, hence the interest in tunnel mode.

David,

The box in the above diagram looks a lot like a BITW IPsec 
implementation, rather than an SG, and if so it could use transport 
mode and be compliant with 2401.  Only if the IP storage behind the 
IPsec device has multiple addresses would the IPsec device need to be 
viewed as an SG and thus implement tunnel mode only.

Steve

From kent@bbn.com  Thu Nov 29 11:46:49 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA09410
	for <saag@jis.mit.edu>; Thu, 29 Nov 2001 11:46:49 -0500 (EST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20822
	for <saag@mit.edu>; Thu, 29 Nov 2001 11:46:48 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA12159;
	Thu, 29 Nov 2001 11:45:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010401b82c13b4edf4@[128.89.88.34]>
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14>
References: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14>
Date: Thu, 29 Nov 2001 11:39:32 -0500
To: Black_David@emc.com
From: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com, saag@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [saag] Re: IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

David,

I'm trying to make my way through over 1K messages (that's what I get 
for going on a week vacation when new IPsec IDs come out ...) and so 
I didn't read all of your messages in order.

Looking back at your original (?) message about use of tunnel vs. 
transport mode I agree with you that this should not be a problem for 
iSCSI use of IPsec, from a standards perspective. As you note, people 
need to be smart in configuring an external IPsec device (or set of 
devices) to ensure that, within their context, the desired security 
properties are achieved. Thus, merely because tunnel mode could be 
terminated at a point which would undermine security, in general, 
that does not mean that its use should be avoided in your spec, for 
the reasons you cite. My previous message also noted that the 
outboard IPsec device could be a bump in the wire, vs. an SG, which 
would allow both transport and tunnel mode, but this is a minor 
difference relative to your bugger question.

As you noted, it is a local security policy (and architecture) issue 
where the IPsec devices are placed and whether that placement 
provides adequate security.

Steve

From WDIXON@windows.microsoft.com  Thu Nov 29 21:41:11 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA15744
	for <saag@jis.mit.edu>; Thu, 29 Nov 2001 21:41:11 -0500 (EST)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA25483
	for <saag@mit.edu>; Thu, 29 Nov 2001 21:41:10 -0500 (EST)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 29 Nov 2001 18:40:02 -0800
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Nov 2001 18:40:02 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 29 Nov 2001 18:40:02 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 29 Nov 2001 18:40:01 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Thu, 29 Nov 2001 18:39:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
Date: Thu, 29 Nov 2001 18:39:19 -0800
Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: IP Storage and IPsec encapsulation
thread-index: AcF49th/4UY3rX2uSOe5rknaplDnxgATrr3Q
From: "William Dixon" <wdixon@windows.microsoft.com>
To: "Stephen Kent" <kent@bbn.com>, <Black_David@emc.com>
Cc: <ipsec@lists.tislabs.com>, <saag@mit.edu>
X-OriginalArrivalTime: 30 Nov 2001 02:39:20.0192 (UTC) FILETIME=[367E0800:01C17948]
Subject: [saag] RE: IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require
a transport layer interface definition for using IPSec security - in the
iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port
connection, deal with the binding of the authentication credential to
the traffic in the SA, allow/disallow iSCSI awareness of IKE SA
credentials, and IKE QM/IPSec SA state, and deal with the programmatic
policy addition to an otherwise admin defined SPD.  

Practically, shipping products that use IKE and IPSec in either mode for
TCP connection security means a well defined "policy" so that client
(iSCSI initiator) and server (iSCSI target) side products interoperate
with just credentials configured properly, ala web-based usage of
SSL/TLS.

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Thursday, November 29, 2001 8:40 AM
To: Black_David@emc.com
Cc: ipsec@lists.tislabs.com; saag@mit.edu
Subject: Re: IP Storage and IPsec encapsulation


David,

I'm trying to make my way through over 1K messages (that's what I get 
for going on a week vacation when new IPsec IDs come out ...) and so 
I didn't read all of your messages in order.

Looking back at your original (?) message about use of tunnel vs. 
transport mode I agree with you that this should not be a problem for 
iSCSI use of IPsec, from a standards perspective. As you note, people 
need to be smart in configuring an external IPsec device (or set of 
devices) to ensure that, within their context, the desired security 
properties are achieved. Thus, merely because tunnel mode could be 
terminated at a point which would undermine security, in general, 
that does not mean that its use should be avoided in your spec, for 
the reasons you cite. My previous message also noted that the 
outboard IPsec device could be a bump in the wire, vs. an SG, which 
would allow both transport and tunnel mode, but this is a minor 
difference relative to your bugger question.

As you noted, it is a local security policy (and architecture) issue 
where the IPsec devices are placed and whether that placement 
provides adequate security.

Steve


From owner-ipsec@lists.tislabs.com  Thu Nov 29 23:09:07 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA16643
	for <saag@jis.mit.edu>; Thu, 29 Nov 2001 23:09:03 -0500 (EST)
Received: from adga.ca ([206.222.76.33])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA12470
	for <saag@mit.edu>; Thu, 29 Nov 2001 23:09:02 -0500 (EST)
Received: from e2kdc1.ad.adga.ca ([192.168.10.50]) by gateway.adga.ca with ESMTP id <117153>; Thu, 29 Nov 2001 22:57:39 -0500
Received: from mail pickup service by e2kdc1.ad.adga.ca with Microsoft SMTPSVC;
	 Thu, 29 Nov 2001 23:09:15 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
x-receiver: m.gratton@adga.ca
Received: from lists.tislabs.com ([192.94.214.101] RDNS failed) by e2kdc1.ad.adga.ca with Microsoft SMTPSVC(5.0.2195.2966); Thu, 29 Nov 2001 23:09:13 -0500
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13489 Thu, 29 Nov 2001 21:31:36 -0500 (EST)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Class: urn:content-classes:message
Date:  Thu, 29 Nov 2001 18:39:19 -0800
Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: IP Storage and IPsec encapsulation
thread-index: AcF49th/4UY3rX2uSOe5rknaplDnxgATrr3Q
From: "William Dixon" <wdixon@windows.microsoft.com>
To: "Stephen Kent" <kent@bbn.com>, <Black_David@emc.com>
Cc: <ipsec@lists.tislabs.com>, <saag@mit.edu>
X-OriginalArrivalTime: 30 Nov 2001 02:39:20.0192 (UTC) FILETIME=[367E0800:01C17948]
Precedence: bulk
Subject: [saag] RE: IP Storage and IPsec encapsulation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require
a transport layer interface definition for using IPSec security - in the
iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port
connection, deal with the binding of the authentication credential to
the traffic in the SA, allow/disallow iSCSI awareness of IKE SA
credentials, and IKE QM/IPSec SA state, and deal with the programmatic
policy addition to an otherwise admin defined SPD.  

Practically, shipping products that use IKE and IPSec in either mode for
TCP connection security means a well defined "policy" so that client
(iSCSI initiator) and server (iSCSI target) side products interoperate
with just credentials configured properly, ala web-based usage of
SSL/TLS.

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Thursday, November 29, 2001 8:40 AM
To: Black_David@emc.com
Cc: ipsec@lists.tislabs.com; saag@mit.edu
Subject: Re: IP Storage and IPsec encapsulation


David,

I'm trying to make my way through over 1K messages (that's what I get 
for going on a week vacation when new IPsec IDs come out ...) and so 
I didn't read all of your messages in order.

Looking back at your original (?) message about use of tunnel vs. 
transport mode I agree with you that this should not be a problem for 
iSCSI use of IPsec, from a standards perspective. As you note, people 
need to be smart in configuring an external IPsec device (or set of 
devices) to ensure that, within their context, the desired security 
properties are achieved. Thus, merely because tunnel mode could be 
terminated at a point which would undermine security, in general, 
that does not mean that its use should be avoided in your spec, for 
the reasons you cite. My previous message also noted that the 
outboard IPsec device could be a bump in the wire, vs. an SG, which 
would allow both transport and tunnel mode, but this is a minor 
difference relative to your bugger question.

As you noted, it is a local security policy (and architecture) issue 
where the IPsec devices are placed and whether that placement 
provides adequate security.

Steve



From aboba@internaut.com  Fri Nov 30 02:35:59 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA18774
	for <saag@jis.mit.edu>; Fri, 30 Nov 2001 02:35:59 -0500 (EST)
Received: from internaut.com ([64.38.134.99])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA15353
	for <saag@mit.edu>; Fri, 30 Nov 2001 02:35:57 -0500 (EST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id XAA04266;
	Thu, 29 Nov 2001 23:24:24 -0800 (PST)
	(envelope-from aboba@internaut.com)
Date: Thu, 29 Nov 2001 23:24:24 -0800 (PST)
From: Bernard Aboba <aboba@internaut.com>
To: William Dixon <wdixon@windows.microsoft.com>
cc: Stephen Kent <kent@bbn.com>, Black_David@emc.com, ipsec@lists.tislabs.com,
        saag@mit.edu
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.BSF.4.21.0111292318270.4261-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

To add a bit to the debate, one has to consider not only the
impact of the tunnel vs. transport decision itself, but also the other
implications. For example, while iFCP and FCIP endpoints are
typically statically addressed, iSCSI initiators are often hosts with
dynamically assigned addresses. Therefore if tunnel mode is used with
iSCSI, there is a need to dynamically configure the tunnel parameters,
including IP address, configuration, etc. There is some additional
complexity required as a result, and also some potential pitfalls, since
most tunnel mode gateways don't yet implement the IPSRA WG recommendation
for tunnel mode config, draft-ietf-ipsec-dhcp-13.txt. I'd hate to see us
do a lot of work to specify how IPsec tunnel mode would be used to secure
iSCSI only to find that the implementations won't interoperate
because they were using various proprietary tunnel mode authentication and
configuration extensions.

Been there, done that ;)



On Thu, 29 Nov 2001, William Dixon wrote:

> Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require
> a transport layer interface definition for using IPSec security - in the
> iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port
> connection, deal with the binding of the authentication credential to
> the traffic in the SA, allow/disallow iSCSI awareness of IKE SA
> credentials, and IKE QM/IPSec SA state, and deal with the programmatic
> policy addition to an otherwise admin defined SPD.  
> 
> Practically, shipping products that use IKE and IPSec in either mode for
> TCP connection security means a well defined "policy" so that client
> (iSCSI initiator) and server (iSCSI target) side products interoperate
> with just credentials configured properly, ala web-based usage of
> SSL/TLS.
> 
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com] 
> Sent: Thursday, November 29, 2001 8:40 AM
> To: Black_David@emc.com
> Cc: ipsec@lists.tislabs.com; saag@mit.edu
> Subject: Re: IP Storage and IPsec encapsulation
> 
> 
> David,
> 
> I'm trying to make my way through over 1K messages (that's what I get 
> for going on a week vacation when new IPsec IDs come out ...) and so 
> I didn't read all of your messages in order.
> 
> Looking back at your original (?) message about use of tunnel vs. 
> transport mode I agree with you that this should not be a problem for 
> iSCSI use of IPsec, from a standards perspective. As you note, people 
> need to be smart in configuring an external IPsec device (or set of 
> devices) to ensure that, within their context, the desired security 
> properties are achieved. Thus, merely because tunnel mode could be 
> terminated at a point which would undermine security, in general, 
> that does not mean that its use should be avoided in your spec, for 
> the reasons you cite. My previous message also noted that the 
> outboard IPsec device could be a bump in the wire, vs. an SG, which 
> would allow both transport and tunnel mode, but this is a minor 
> difference relative to your bugger question.
> 
> As you noted, it is a local security policy (and architecture) issue 
> where the IPsec devices are placed and whether that placement 
> provides adequate security.
> 
> Steve
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag
> 


From Black_David@emc.com  Sat Dec  1 18:48:11 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA10645
	for <saag@jis.mit.edu>; Sat, 1 Dec 2001 18:48:11 -0500 (EST)
From: Black_David@emc.com
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA13647
	for <saag@mit.edu>; Sat, 1 Dec 2001 18:48:11 -0500 (EST)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <TJVJ6Y4L>; Sat, 1 Dec 2001 18:47:41 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14>
To: rja@inet.org
Cc: saag@mit.edu
Subject: RE: [saag] RE: IP Storage and IPsec encapsulation
Date: Sat, 1 Dec 2001 18:37:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Ran,

First, I should apologize for my delay in replying; every
so often my day job interrupts IETF work :-).

The word "session" is definitely part of the confusion between
us.  Let me set that word aside and modify my assertion to say
that security at a finer grain than individual TCP connections
does not make sense **for the protocols currently being developed
in the IP Storage WG**.  This is a consequence of some specific
design decisions in those protocols, and I can think of alternate
designs that would require finer grain security.  I'd suggest
taking up further discussion of this point either on the IPS
list or directly between us - I'll be happy to explain in either
forum in order to keep lengthy IP Storage design discussions off
the SAAG list.

Something else I may not have explained is that the IP Storage WG
is prepared to require that the appropriate granularity of
security and identity be present and used, over and above
what the IPsec RFCs would require by default.  One example
is that the requirement to use a phase 2 SA per TCP connection
would be imposed by IP Storage documents, in contrast to RFC 2401
not requiring implementation of port selectors.  In addition, there
should not be a problem in requiring checks of IKE identities with
respect to identities in the IP Storage protocols where this is
necessary for security (a specific example involving FCIP has
recently been discussed on the IPS list) - such requirements
force the relevant identities to be available in a trusted fashion.
(NB: my use of "trusted" is based on the usage of that term
in RFC 2401 - I suspect you have something more restrictive
in mind in your usage of "trusted computing base".)

As for transport mode necessarily resulting in knowing "that the
end point is really the end point", I would agree that this is
more likely to be the case for current IPsec implementations than
with tunnel mode.  OTOH, it is not that difficult to hook a NAT
implementation up to an IPsec implementation in a single node
and run IPsec in transport mode for traffic forwarded via
the NAT.  All the code needed to do this is readily available
for Linux, and results in the endpoint being on the NAT/IPsec
box, not the actual endpoint of the connection despite the use
of transport mode encapsulation.  If the NAT is actually NAPT
(e.g., IP Masquerade), the IPsec implementation would be capable
of asserting one IP-based identity on behalf of multiple systems
with different IP addresses whose traffic flows through it - this
clearly splits the IPsec endpoint from the actual endpoints of
the traffic flowing through IPsec.

IMHO, I think the conclusion from all of this is that ensuring
end-to-end security and use of the "right" granularity of
identities are essentially matters of security policy that are
largely independent (in principle) from the use of transport mode
vs. tunnel mode.  The IPS WG is prepared to place appropriate
requirements and restrictions on security policies to achieve
or encourage the achievement of the above ends in the IP
Storage protocols, but I don't yet see a case for how
requiring use of transport mode would make a significant
contribution to achieving those ends.

Thanks,
--David 

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: RJ Atkinson [mailto:rja@inet.org]
> Sent: Wednesday, November 28, 2001 8:49 PM
> To: Black_David@emc.com
> Cc: saag@mit.edu
> Subject: RE: [saag] RE: IP Storage and IPsec encapsulation
> 
> 
> At 20:10 28/11/01, Black_David@emc.com wrote:
> >Could you be specific about what can't be provided, and how
> >requiring transport mode would force/encourage it to be provided?
> 
> If one is using transport-mode, one knows that the end point is
> really the end point.  And that end point can use fine-grained
> identities in the IPsec Security Association that are not available
> to a tunnel-mode (in the scenario you outlined) because that
> granularity of identity information is only knowable inside the
> trusted computing base of the originating system.
> 
> >NFS is not the best analogy because NFS is an RPC-oriented protocol
> >for which it makes sense to provide security at the granularity of
> >individual RPCs, as a (user) identity can be associated with each
> >RPC.  The IP Storage protocols are TCP/IP encapsulations of SCSI
> >and Fibre Channel -- these are session-oriented protocols for which
> >it does not make sense to provide security at a granularity finer
> >than a session as a (machine) identity is associated with 
> each session,
> >but no other finer-grain identities are associated with individual
> >commands/messages/operations/etc. within a session.
> 
> I don't believe the above is strictly the case.  In any event,
> the session-level granularity you say is needed can't be provided
> by a security gateway in the model you described (perhaps there
> are more details in your head but not in the email that would change
> this ?).
> 
> >In the above diagram, a separate phase 2 SA would be required for
> >every TCP connection (i.e., the typical security gateway behavior
> >of running all traffic destined for the same remote gateway through
> >the same tunnel would not be compliant); this is at least session
> >granularity, 
> 
>         Not necessarily.  Perhaps you are using a different
> definition of "session" ?
> 
> >and potentially finer grain depending on how sessions
> >are formed and how phase 2 SAs are associated with phase 1 SAs.
> 
>         Fine-grained isn't available because the remote KM
> instance can't know the identities in a fine-grained way
> if they aren't local to the remote KM box's trusted computing
> base.
> 
> Ran
> rja@inet.org
>  
> 

From hughes@jimsmac.network.com  Sun Dec  2 14:54:40 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA20430
	for <saag@jis.mit.edu>; Sun, 2 Dec 2001 14:54:39 -0500 (EST)
Received: from storage.network.com (storage.network.com [129.191.1.4])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA09518
	for <saag@mit.edu>; Sun, 2 Dec 2001 14:54:38 -0500 (EST)
Received: from cremaster.network.com (cremaster.network.com [129.191.63.2])
	by storage.network.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19533;
	Sun, 2 Dec 2001 13:54:20 -0600 (CST)
Received: from jimsmac.network.com (IDENT:root@jimsmac.network.com [129.191.222.11])
	by cremaster.network.com (8.9.3/8.9.3) with ESMTP id NAA07416;
	Sun, 2 Dec 2001 13:53:46 -0600
Received: (from hughes@localhost)
	by jimsmac.network.com (8.9.3/8.9.3) id NAA09316;
	Sun, 2 Dec 2001 13:51:51 -0500
Date: Sun, 2 Dec 2001 13:51:51 -0500
From: Jim Hughes <jim@storage.network.com>
To: Black_David@emc.com
Cc: rja@inet.org, saag@mit.edu
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
Message-ID: <20011202135151.K17080@jimsguin.network.com>
Reply-To: Jim@storage.network.com
References: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14>; from Black_David@emc.com on Sat, Dec 01, 2001 at 06:37:00PM -0500
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hi:

I wish to make a request that will seem to come out of left field. 

---------------------------------------------------
The current iSCSI recommendation is not End-To-End
---------------------------------------------------

I believe that the definition that is being used in this thread is
incorrect. End-to-end in the famous paper was from host to host
carrying on a conversation, and in the section of that paper that
discusses encryption argues against the current IPsec scheme since
that only protects the data over a group of network segments and not
from machine to machine. In the traditional terminology of end-to-end,
the disk drive is an intermediate, not an end, since it does not
require the understanding of the information, it just stores it in a
persistent data channel. 

I believe the correct use of end-to-end encryption is when the
encryption is applied to the data, not the network. That is, if the
data is encrypted above the SCSI layer, stored encrypted, then this
solution is truly end to end because the data is not decrypted until
it is in the hands of the next process that needs the data in the
clear.

IMHO, I believe a long term goal of the encryption of storage is in
many cases more valuable than encrypting the network. 

--------------------------------------------------
iSCSI should make IPSEC recommended, not mandatory
--------------------------------------------------

I believe that making IPSEC mandatory will: 

1. inhibit the deployment of iSCSI because of the cost of external
Gb/s IPSEC units. 

2. delay the implementation of encrypted storage. 

3. be an unnecessary burden on customers that do encrypt their data
above the SCSI layer.

I believe that the terminology of the IPSEC recommendations should be
'SHOULD' and not 'MUST'. 

Thanks

jim


From phoffman@imc.org  Sun Dec  2 18:07:18 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA22427
	for <saag@jis.mit.edu>; Sun, 2 Dec 2001 18:07:17 -0500 (EST)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA09541
	for <saag@mit.edu>; Sun, 2 Dec 2001 18:07:17 -0500 (EST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fB2N7C225935
	for <saag@mit.edu>; Sun, 2 Dec 2001 15:07:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101000b83063571a86@[165.227.249.20]>
In-Reply-To: <20011202135151.K17080@jimsguin.network.com>
References: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14>
 <20011202135151.K17080@jimsguin.network.com>
Date: Sun, 2 Dec 2001 15:07:09 -0800
To: saag@mit.edu
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 1:51 PM -0500 12/2/01, Jim Hughes wrote:
>I believe the correct use of end-to-end encryption is when the
>encryption is applied to the data, not the network. That is, if the
>data is encrypted above the SCSI layer, stored encrypted, then this
>solution is truly end to end because the data is not decrypted until
>it is in the hands of the next process that needs the data in the
>clear.

It is also nearly unusable in the Real World because much of the use 
if iSCSI (and any remote storage protocol, for that matter) is for 
access to data that is available to many people, not just one person 
who knows the decryption key. The assertion above only makes sense if 
the data being remotely stored is private data where the all the 
people looking at that data know the decryption key before accessing 
the data.

--Paul Hoffman, Director
--Internet Mail Consortium

From hughes@jimsmac.network.com  Mon Dec  3 09:59:50 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00924
	for <saag@jis.mit.edu>; Mon, 3 Dec 2001 09:59:50 -0500 (EST)
Received: from storage.network.com (storage.network.com [129.191.1.4])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA01232
	for <saag@mit.edu>; Mon, 3 Dec 2001 09:59:49 -0500 (EST)
Received: from cremaster.network.com (cremaster.network.com [129.191.63.2])
	by storage.network.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19498;
	Mon, 3 Dec 2001 08:59:44 -0600 (CST)
Received: from jimsmac.network.com (IDENT:root@jimsmac.network.com [129.191.222.11])
	by cremaster.network.com (8.9.3/8.9.3) with ESMTP id IAA07878;
	Mon, 3 Dec 2001 08:59:11 -0600
Received: (from hughes@localhost)
	by jimsmac.network.com (8.9.3/8.9.3) id IAA27777;
	Mon, 3 Dec 2001 08:57:28 -0500
Date: Mon, 3 Dec 2001 08:57:28 -0500
From: Jim Hughes <jim@storage.network.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: saag@mit.edu
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
Message-ID: <20011203085728.S17080@jimsguin.network.com>
Reply-To: Jim@storage.network.com
References: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14> <20011202135151.K17080@jimsguin.network.com> <p05101000b83063571a86@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <p05101000b83063571a86@[165.227.249.20]>; from phoffman@imc.org on Sun, Dec 02, 2001 at 03:07:09PM -0800
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Several comments. 

1. The issue of key management is a technical challenge, but not
impossible. There are existence proofs that this is possible. 

2. The vast majority of iSCSI use will be shared-nothing private
volume services without any sharing. 

Thanks

jim

On Sun, Dec 02, 2001 at 03:07:09PM -0800, Paul Hoffman / IMC wrote:
> At 1:51 PM -0500 12/2/01, Jim Hughes wrote:
> >I believe the correct use of end-to-end encryption is when the
> >encryption is applied to the data, not the network. That is, if the
> >data is encrypted above the SCSI layer, stored encrypted, then this
> >solution is truly end to end because the data is not decrypted until
> >it is in the hands of the next process that needs the data in the
> >clear.
> 
> It is also nearly unusable in the Real World because much of the use 
> if iSCSI (and any remote storage protocol, for that matter) is for 
> access to data that is available to many people, not just one person 
> who knows the decryption key. The assertion above only makes sense if 
> the data being remotely stored is private data where the all the 
> people looking at that data know the decryption key before accessing 
> the data.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag

From hughes@jimsmac.network.com  Mon Dec  3 11:09:15 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA01696
	for <saag@jis.mit.edu>; Mon, 3 Dec 2001 11:09:15 -0500 (EST)
Received: from storage.network.com (storage.network.com [129.191.1.4])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA11612
	for <saag@mit.edu>; Mon, 3 Dec 2001 11:09:14 -0500 (EST)
Received: from cremaster.network.com (cremaster.network.com [129.191.63.2])
	by storage.network.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22230;
	Mon, 3 Dec 2001 10:09:08 -0600 (CST)
Received: from jimsmac.network.com (IDENT:root@jimsmac.network.com [129.191.222.11])
	by cremaster.network.com (8.9.3/8.9.3) with ESMTP id KAA09969;
	Mon, 3 Dec 2001 10:08:38 -0600
Received: (from hughes@localhost)
	by jimsmac.network.com (8.9.3/8.9.3) id KAA00896;
	Mon, 3 Dec 2001 10:06:55 -0500
Date: Mon, 3 Dec 2001 10:06:55 -0500
From: Jim Hughes <jim@storage.network.com>
To: Jim Hughes <jim@storage.network.com>
Cc: Paul Hoffman / IMC <phoffman@imc.org>, saag@mit.edu
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
Message-ID: <20011203100655.V17080@jimsguin.network.com>
Reply-To: Jim@storage.network.com
References: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14> <20011202135151.K17080@jimsguin.network.com> <p05101000b83063571a86@[165.227.249.20]> <20011203085728.S17080@jimsguin.network.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <20011203085728.S17080@jimsguin.network.com>; from jim@storage.network.com on Mon, Dec 03, 2001 at 08:57:28AM -0500
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Mon, Dec 03, 2001 at 08:57:28AM -0500, Jim Hughes wrote:
> 
> 2. The vast majority of iSCSI use will be shared-nothing private
> volume services without any sharing. 

I have been reminded that iSCSI does not exist yet, how can I make
this claim. 

iSCSI is another media that is expected to extend the capabilities of
SCSI over FibreChannel. 

There are 100,000 SCSI over FC interfaces in production to disk today
using IBM, EMC, Hitachi, LSI etc. disk controllers. People are using
these today. The vast majority 90%+ of these interfaces are shared
nothing disk volumes because SCSI protocol is not robust in this
area.

While the amount of sharing will go up over time, there is and always
be a shared nothing pooling of disk space in the storage market.



===============================
Another reason. 
===============================

Qlogic already has announced a host adapter that talks iSCSI and IBM
has announced an iSCSI RAID controller. 

It seems that if I put a piece of fibre between these 2 items, that
without two external IPSEC encryptor, it will not be "compliant". is
this true??? Why not 'allow' this?

Add to this the fact that each of IPSEC encryptor will (at least
initially) cost more than both the interface board and RAID
controllers combined).


From Black_David@emc.com  Mon Dec  3 11:22:24 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA01897
	for <saag@jis.mit.edu>; Mon, 3 Dec 2001 11:22:24 -0500 (EST)
From: Black_David@emc.com
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08713
	for <saag@mit.edu>; Mon, 3 Dec 2001 11:22:23 -0500 (EST)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <W739JQSG>; Mon, 3 Dec 2001 11:17:55 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E02937240@CORPMX14>
To: Jim@storage.network.com
Cc: saag@mit.edu
Subject: RE: [saag] RE: IP Storage and IPsec encapsulation
Date: Mon, 3 Dec 2001 11:11:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jim,

The following question was answered by the IESG at length during
the IESG plenary in London.  The short summary is that protocols
that can only be used on private networks are of no interest to
the IETF - protocol specs must provide the mechanisms to enable
reasonable use of the protocol on the public Internet.  One can
always turn things off that are present but not needed, but it's
very difficult to turn something on that is needed but not present.

Please send me email offline if you want to hear a longer version.

Thanks,
--David


> ===============================
> Another reason. 
> ===============================
> 
> Qlogic already has announced a host adapter that talks iSCSI and IBM
> has announced an iSCSI RAID controller. 
> 
> It seems that if I put a piece of fibre between these 2 items, that
> without two external IPSEC encryptor, it will not be "compliant". is
> this true??? Why not 'allow' this?
> 
> Add to this the fact that each of IPSEC encryptor will (at least
> initially) cost more than both the interface board and RAID
> controllers combined).

From rlmorgan@washington.edu  Mon Dec  3 11:23:41 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA01932
	for <saag@jis.mit.edu>; Mon, 3 Dec 2001 11:23:41 -0500 (EST)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09306
	for <saag@mit.edu>; Mon, 3 Dec 2001 11:23:40 -0500 (EST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout2.cac.washington.edu (8.11.6+UW01.08/8.11.6+UW01.10) with ESMTP id fB3GNdx08650;
	Mon, 3 Dec 2001 08:23:39 -0800
Received: from [192.168.1.101] ([12.228.73.122])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.0+UW01.09/8.12.0+UW01.10) with ESMTP id fB3GNcUm006391
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 3 Dec 2001 08:23:39 -0800
Date: Mon, 3 Dec 2001 08:23:43 -0800 (PST)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perx.cac.washington.edu
Reply-To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: Jim Hughes <jim@storage.network.com>
cc: SAAG list <saag@mit.edu>
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
In-Reply-To: <20011203100655.V17080@jimsguin.network.com>
Message-ID: <Pine.LNX.4.40.0112030815070.14703-100000@perx.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

On Mon, 3 Dec 2001, Jim Hughes wrote:

> Qlogic already has announced a host adapter that talks iSCSI and IBM
> has announced an iSCSI RAID controller.
>
> It seems that if I put a piece of fibre between these 2 items, that
> without two external IPSEC encryptor, it will not be "compliant". is
> this true??? Why not 'allow' this?

IETF standards do not and cannot mandate what particular deployments do
(except perhaps in the case of core Internet infrastructure like DNS), so
your question does not apply.  IETF standards state requirements for
*implementations* that claim to conform.  So, if the notions of security
that are being promoted by SAAG folks here prevail, if the above Qlogic
and IBM implementations were to not include any IPSec capability, then
they couldn't claim to be iSCSI compliant.  This wouldn't prevent these
companies from selling "compliant except for the absence of security"
versions of these products, and if people want to buy and install them,
they can do so.  But the IETF's intent across its large suite of protocols
is to ensure, as much as possible, that those who acquire compliant
implementations will find them able to work with acceptable security even
in the typical hostile Internet environment.

 - RL "Bob"



From rhousley@rsasecurity.com  Mon Dec  3 15:14:52 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA04513
	for <saag@jis.mit.edu>; Mon, 3 Dec 2001 15:14:52 -0500 (EST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id PAA26761
	for <saag@mit.edu>; Mon, 3 Dec 2001 15:14:52 -0500 (EST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com
          via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 3 Dec 2001 20:14:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA13894
	for <saag@mit.edu>; Mon, 3 Dec 2001 15:14:48 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1])
	by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB3KEUx03675
	for <saag@mit.edu>; Mon, 3 Dec 2001 15:14:30 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19)
	id <YFW8S70F>; Mon, 3 Dec 2001 14:59:42 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.87 [10.3.1.87]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YFW8S6X4; Mon, 3 Dec 2001 14:45:29 -0500
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Jim@storage.network.com
Cc: saag@mit.edu
Message-Id: <5.0.1.4.2.20011203142825.00b18f48@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 03 Dec 2001 14:33:16 -0500
Subject: Re: [saag] RE: IP Storage and IPsec encapsulation
In-Reply-To: <20011202135151.K17080@jimsguin.network.com>
References: <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14>
 <277DD60FB639D511AC0400B0D068B71E02937235@CORPMX14>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Jim:

A few years ago, I looked at this in the context of FTP security.  It is 
important that such solutions support many concurrent users.  In the FTP 
environment, we showed a way that the server could keep an encrypted file 
store.  Fetching a file had two logical parts, the wrapped the 
file-encryption key and the encrypted file.  The file-encryption key was 
encrypted in a manner that only the client could decrypt it.

I think that you are seeking a similar architecture, but at a smaller 
granularity than a file.

Russ

At 01:51 PM 12/2/2001 -0500, Jim Hughes wrote:
>IMHO, I believe a long term goal of the encryption of storage is in
>many cases more valuable than encrypting the network.

From smb@research.att.com  Tue Dec  4 20:44:43 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA22173
	for <saag@jis.mit.edu>; Tue, 4 Dec 2001 20:44:42 -0500 (EST)
Received: from berkshire.research.att.com (H-135-207-4-107.research.att.com [135.207.4.107])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA06644
	for <saag@mit.edu>; Tue, 4 Dec 2001 20:44:31 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id 555677B55
	for <saag@mit.edu>; Tue,  4 Dec 2001 20:44:04 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 04 Dec 2001 20:44:04 -0500
Message-Id: <20011205014404.555677B55@berkshire.research.att.com>
Subject: [saag] AES, etc. (fwd)
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I just received this email.

------- Forwarded Message

X-Sender: ebarker@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 04 Dec 2001 15:47:47 -0600
From: Elaine Barker <elaine.barker@nist.gov>
Subject: AES, etc.
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_8141635==_.ALT"
X-UIDL: c85f892c16617de5a0990b0fb97e01b7

- --=====================_8141635==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

AES: NIST is pleased to announce that the AES was signed on November 26, 
2001. The standard and further information are available at 
http://csrc.nist.gov and http://www.nist.gov/aes. The notice will appear in 
the Federal Register later this week.

Modes of Operation: The initial Recommended Modes of Operation document 
will be available in a few days. The initial modes consist of the ECB, CBC 
CFB, OFB and CTR encryption modes. Other modes will be added at a later time.

Key Management: The presentations and a list of issues that were addressed 
at the Key Management Workshop are available at 
http://csrc.nist.gov/encryption/kms/workshop2-page.html. The AES Key 
Wrapping algorithm is available at http://www.nist.gov/kms.



Elaine Barker
National Institute of Standards and Technology
100 Bureau Dr., Stop 8930
Gaithersburg, MD 20899-8930
Phone: 301-975-2911
Fax: 301-948-1233
Email: ebarker@nist.gov



From rlmorgan@washington.edu  Wed Dec  5 03:27:57 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA26059
	for <saag@jis.mit.edu>; Wed, 5 Dec 2001 03:27:57 -0500 (EST)
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id DAA02972
	for <saag@mit.edu>; Wed, 5 Dec 2001 03:27:56 -0500 (EST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout1.cac.washington.edu (8.11.6+UW01.08/8.11.6+UW01.10) with ESMTP id fB58RuD25803
	for <saag@mit.edu>; Wed, 5 Dec 2001 00:27:56 -0800
Received: from [192.168.1.101] ([12.228.73.122])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW01.10) with ESMTP id fB58Rsd1032586
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <saag@mit.edu>; Wed, 5 Dec 2001 00:27:55 -0800
Date: Wed, 5 Dec 2001 00:28:12 -0800 (PST)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perx.cac.washington.edu
Reply-To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: SAAG list <saag@mit.edu>
Message-ID: <Pine.LNX.4.40.0112050021350.25837-100000@perx.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [saag] [WG ACTION: Protocol for carrying Authentication for Network
 Access(pana)]
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

This new WG is in the Internet area but I suspect will be of interest to
some security folk.  It's listed as a BOF in the IETF 52 agenda but I
guess has just become a WG.  Apparently the IESG mandate for concise WG
charters is not universally applied.

 - RL "Bob"

---------- Forwarded message ----------
Date: Fri, 30 Nov 2001 14:39:40 -0500
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:  ;
Subject: WG ACTION: Protocol for carrying Authentication for Network Access
    (pana)


A new working group has been formed in the Internet Area of the IETF.
For additional information, contact the Area Directors
or the WG Chair.


Protocol for carrying Authentication for Network Access (pana)
---------------------------------------------------------


 Current Status: Active Working Group

 Chair(s):
     Basavaraj Patil <basavaraj.patil@nokia.com>
     Subir Das <subir@research.telcordia.com>

 Internet Area Director(s):
     Thomas Narten  <narten@us.ibm.com>
     Erik Nordmark  <nordmark@eng.sun.com>

 Internet Area Advisor:
     Erik Nordmark  <nordmark@eng.sun.com>

 Mailing Lists:
     General Discussion:urp@research.telcordia.com
     To Subscribe:      urp-request@research.telcordia.com
         In Body:       (un)subscribe
     Archive:           ftp://ftp.research.telcordia.com/pub/Group.archive/urp/archive

Description of Working Group:

The AAA working group is specifying the Diameter protocol for
communication between servers i.e. where Radius is currently being
used. There is currently no general protocol to be used by a user's
device when wanting network access, and this WG will attempt to fill
that hole. That is, a protocol between a user's device and a device at
the network access point where the network access device might be a
client of the AAA infrastructure.

Currently the authentication mechanisms in PPP are being used for many
wired access scenarios as well as some wireless access, which requires
using PPP framing for the data packets. This is not viewed as the
optimal solution in the cases where framing protocols already exist.
Also, IEEE 802 is working on 802.1X which provides EAP authentication
limited to IEEE 802 link layers.

Network access technologies for wired and wireless media are evolving
rapidly. With the rapid growth in the number and type of devices and
terminals that support IP stacks and can access the Internet, users can
potentially use a single device having the capability of attaching via
different multiple access media and technologies to interface to the
network. The model for providing the users' information to the
network for authentication, authorization or accounting needs to be
the same and NOT be tied in to the underlying access type.

The intent of this WG is to develop a protocol but the working group
can't start doing that until the requirements document is done.

The working group's primary task is to define a protocol between
a user's device and a node in the network that allows:

 - A device (on behalf of a user) to authenticate to an agent
   in the local network. The agent might be non-local, but at the
   boundary of some AAA-equivalent function. The agent is called PANA
   Authentication Agent (PAA) in this charter.

 - The device to discover the IP address of the PAA.

 - The PAA to use either local mechanisms/knowledge, or the AAA
   infrastructure i.e. being a client of the AAA, to authenticate the
   device.

 - Outside of the scope of the protocol, allows for the PAA to install
   access control mechanisms in the network, based on the results of
   the AAA protocol exchanges. This follows the model of current Radius
   being able to provide filtering rules to NASes.

The working group will also provide documentation on

 - Requirements placed on the protocol (in requirements draft)

 - Chosen approach for handling the security issues and which existing
   security mechanisms that are chosen for the protocol. (in framework
   draft)

 - What assumptions the protocol is making on the AAA infrastructure
   e.g. in terms of security. (in framework draft)

 - The relative location of the PAA and any access control functions in
   the network and how their location affects the performance and
   scalability of the PAA solution, as well as the tradeoffs in the
   level of access control enforcement. (in framework draft)

 - The relationship between the PANA protocol and e.g. PPP and 802.1X
   in deployment where both might be viewed as useful.
   (in "interactions" draft)

A naive view of a PANA protocol would just be to define how to carry
EAP (RFC 2284) messages in an IP based protocol. However, EAP makes
certain assumptions about PPP like link-layers such as:

 - The link-layer is point-to-point i.e. a single NAS or Access Router
   is involved in the EAP exchange. For PANA there is a desire to be

   able to support redundant ARs on multi-access link layers where
   inbound and/or outbound packets might use more than one AR.

 - The link-layer providing a disconnect indication. PANA should not
   make this assumption. The assumption affects both the ability to
   tell when the session has ended from an accounting perspective,
   and it affects the frequency at which the device needs to be
   reauthenticated.

A possible way to address the need for more frequent re-authentication
is to have the first authentication, using the AAA infrastructure
and the assumed shared secret between the device and its AAA home
domain, create a security association between the device and the PAA.
Then re-authentication can be done using this security association
without involving the AAA infrastructure. Note that this local security
association is between a pair of entities: the device and the PAA. It
is not intended to be viewed as some general security association
between the device and the operator of the access network. In fact,
such general security associations are outside the scope of PANA.

The WG will not directly work on solutions relating to mobility of
the device. However, it is noted that the ability to re-authenticate
locally with the PAA, can be an important element in allowing efficient
handling of mobile devices.

The PANA protocol needs reliability and congestion ontrol, taking into
account that the PANA protocol needs to be able to operate over
multiple router hops. The congestion control principles are documented
in RFC 2914.

The WG will not invent new security protocols and mechanism but instead
will use existing mechanisms. For example, already specified EAP
methods. In particular, the WG will not define authentication
protocols, key distribution or key agreement protocols, or key
derivation.

The protocol must support both IPv4 and IPv6, but given that the
MOBILEIP WG is building Mobile IPv4 specific solutions to this problem,
the urgency for solutions are likely to be higher for IPv6. The
protocol must not assume a particular method of IP address
configuration. In particular, it must not interfere with standard
techniques and protocols like IPv6 stateless address autoconfiguration
(including the temporary addresses specified RFC 3041) and DHCP.
This implies that it is desirable that the PANA protocol be independent
of IP address configuration.

 Goals and Milestones:

   Nov 01       First draft of Usage Scenarios I-D (Informational)

   Feb 02       Submit first draft of Requirements and terminology I-D
                (Informational)

   Mar 02       Usage Scenarios I-D sent to the IESG for consideration as an
                Informational RFC.

   Apr 02       Submit first draft of Framework specification based on
                scenarios I-D (PS)

   May 02       First draft on PANA interactions with PPP and 802.1X (INFO)

   Jun 02       Requirements and terminology I-D sent to the IESG for
                consideration as an Informational RFC.

   Jun 02       First draft of Protocol specification I-D (PS)

   Aug 02       Framework document sent to the IESG for consideration as
                Proposed.

   Oct 02       PANA interactions with PPP and 802.1X to IESG

   Nov 02       Protocol specification to IESG

   Dec 02       First draft of MIB definition (PS)

   Mar 03       Submit MIB Definition I-D to IESG for consideration as
                Proposed.

   Mar 03       Close down or recharter



From narten@us.ibm.com  Wed Dec  5 10:21:02 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA29794
	for <saag@jis.mit.edu>; Wed, 5 Dec 2001 10:21:02 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA11569
	for <saag@mit.edu>; Wed, 5 Dec 2001 10:17:38 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA03154
	for <saag@mit.edu>; Wed, 5 Dec 2001 09:14:19 -0600
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.21.26])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB5FHZP40106
	for <saag@mit.edu>; Wed, 5 Dec 2001 10:17:35 -0500
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id fB5FHLL04354
	for <saag@mit.edu>; Wed, 5 Dec 2001 10:17:21 -0500
Message-Id: <200112051517.fB5FHLL04354@rotala.raleigh.ibm.com>
To: saag@mit.edu
Date: Wed, 05 Dec 2001 10:17:21 -0500
From: Thomas Narten <narten@us.ibm.com>
Subject: [saag] Home Address Option in MIPv6  (retry)
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I didn't get as much feedback as I'd hoped the first time this was
posted. I'll assumem that was just because another thread popped up at
the same time that seemed more interesting. :-)

Now that folks have had some time to think about this, what are the
issues the MIP WG should be thinking about? Does anyone have a
recommendation for how to proceed?

Thomas

------- Forwarded Message

From: saag-admin@mit.edu
To: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
cc: saag@mit.edu
Date: Tue, 06 Nov 2001 21:23:46 -0500
Subject: Re: [saag] Home Address Option in MIPv6 

Hi Marc.

> Thomas, just to make sure:  s/Home Agent/Home Address/  ?

Yes, everywhere you cited. (I don't believe there is even a Home Agent
Option!).

Corrected text below for completeness.

Thomas

I'd like for the security community to give some thought to the
following issue.  Mobile IPv6 (draft-ietf-mobileip-ipv6-14.txt)
defines an option called a Home Address Option. It is designed to
allow mobile nodes to circumvent problems caused by ingress
filtering.

The reason for asking saag now is that there has been a lot of recent
focus on security issues related to MIPv6's use of the Binding Update
option (see draft-ietf-mobileip-mipv6-scrty-reqts-01.txt).  The topic
of the Home Address option has not received as much attention, and the
authors of that document want to be sure they're not overlooking
anything.

Background:

In MIP, a Mobile Node (MN) has two addresses: a Home Address
(permanent, typically stored in the DNS) and a Care-of Address
(temporary, reflecting the MN's current point of attachment in the
network). A MN can (in theory) send a packet with a source address
equal to the Home Address regardless of where it is connected. In
practice, routers employing ingress filtering may blackhole such
packets, if they come from a topologically incorrect source address.

The Home Address option is an IPv6 destination option that holds the
Home Address of the sending node, so that sending MN can insert the
topologically-correct Care Of Address in the source address of the IP
header.  At the destination, the receiver replaces the source IP
address with the Home Address in the option. Thus, after processing,
the higher layers see a normal IP packet that looks like it was sent
from the MN's Home Address. (Note in particular, that a response to
the packet would be sent to the Home Address unless the receiving node
has a binding in its binding cache to send it directly to the care-of
address. But that is related to the Binding Update in MIP and is
probably not relevant to this note.)

It has been asserted that the Home Address option makes source
address spoofing easier than it already is.  Contrarily, it has
also been asserted that the Home Address option does not increase the 
vulnerability/risk of source address spoofing.  This depends perhaps
on the amount of ingress filtering that takes place today.

Conceptually, the issues and concerns here seem very similar to what
happens when tunnels are allowed to terminate at arbitrary end
nodes. For example, the packets coming out of the tunnel may not have
source addressess (in the inner header) that have any relation to the
source address in the outer header.

The details of the Home Address option are discussed in Sections 5.4 and
13.2 of draft-ietf-mobileip-ipv6-14.txt.

draft-savola-ipv6-rh-ha-security-00.txt also discusses some of the
security ramifications.

Questions:

 What sort of checks (if any) should the receiving node perform as
 part of processing the Home Address option? Is it OK to accept and
 process such packet without applying any types of filters?
 
 Should a node restrict itself to accepting packets with a Home
 Address option from those nodes that it has made prior arrangements
 with?  (e.g., see the recommendation in
 draft-savola-ipv6-rh-ha-security-00.txt)

 Does use of such an option create new avenues for DOS attacks (e.g.,
 reflectors attacks, etc.) or other problems that need consideration?

 In the case of tunneling, I would expect that there is a fair amount
 of existing practice in terms of what sort of filtering/processing
 rules should take place at tunnel egress points. Are the same types
 of processing rules needed in the case of processing received Home
 Address options? If so, what are those rules?

 The general question here is whether use of the Home Address option
 is safe enough to implement in arbitrary notes, and if not, what can
 be done to make it safe enough for general use.

 
_______________________________________________
saag mailing list
saag@mit.edu
http://jis.mit.edu/mailman/listinfo/saag

------- End of Forwarded Message

From aboba@internaut.com  Wed Dec  5 11:01:38 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA00296
	for <saag@jis.mit.edu>; Wed, 5 Dec 2001 11:01:33 -0500 (EST)
Received: from internaut.com ([64.38.134.99])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA11324
	for <saag@mit.edu>; Wed, 5 Dec 2001 11:01:32 -0500 (EST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id HAA15896;
	Wed, 5 Dec 2001 07:49:37 -0800 (PST)
	(envelope-from aboba@internaut.com)
Date: Wed, 5 Dec 2001 07:49:37 -0800 (PST)
From: Bernard Aboba <aboba@internaut.com>
To: Thomas Narten <narten@us.ibm.com>
cc: saag@mit.edu, wdixon@microsoft.com
Subject: Re: [saag] Home Address Option in MIPv6  (retry)
In-Reply-To: <200112051517.fB5FHLL04354@rotala.raleigh.ibm.com>
Message-ID: <Pine.BSF.4.21.0112050729020.15819-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> I didn't get as much feedback as I'd hoped the first time this was
> posted. I'll assumem that was just because another thread popped up at
> the same time that seemed more interesting. :-)
> 
> Now that folks have had some time to think about this, what are the
> issues the MIP WG should be thinking about? Does anyone have a
> recommendation for how to proceed?
> 
> Thomas

OK, I'll bite. 

> 
>  What sort of checks (if any) should the receiving node perform as
>  part of processing the Home Address option? Is it OK to accept and
>  process such packet without applying any types of filters?

It seems to me that this option would need explicit support in a number of
higher layer protocols. For example, within SCTP, do I have to include the
home address as one of the addresses in the INIT chunk before I could
include such an option in an SCTP packet? Otherwise, it would seem like an
easy way to circumvent the DOS functionality of SCTP. 

Similar concerns would exist with IKE/IPsec. It would seem to me that a
Home Address option could not be blithely accepted within an IPsec packet
unless this had been exchanged (and verified) beforehand within the IKE
negotiation. This would be particularly dangerous within an IPsec tunnel,
since it would allow an attacker to circumvent the negotiated filters. 

>  Address option from those nodes that it has made prior arrangements
>  with?  (e.g., see the recommendation in
>  draft-savola-ipv6-rh-ha-security-00.txt)

I think that some "prior arrangement" is needed -- but as described above,
the nature of this might vary depending on circumstances.

>  Does use of such an option create new avenues for DOS attacks (e.g.,
>  reflectors attacks, etc.) or other problems that need consideration?

Yes, it does. Might also complicate traceback. 

>  In the case of tunneling, I would expect that there is a fair amount
>  of existing practice in terms of what sort of filtering/processing
>  rules should take place at tunnel egress points. Are the same types
>  of processing rules needed in the case of processing received Home
>  Address options? If so, what are those rules?

In the case of IPsec, one is supposed to check that the source address
corresponds to that which was negotiated for that IPsec SA. 

>  The general question here is whether use of the Home Address option
>  is safe enough to implement in arbitrary nodes, and if not, what can
>  be done to make it safe enough for general use.

It would seem to me that it *could* be made safe -- but there
are probably quite a few loose ends that need to be tied up. 


From stephen.farrell@baltimore.ie  Thu Dec  6 10:50:45 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA13859
	for <saag@jis.mit.edu>; Thu, 6 Dec 2001 10:50:37 -0500 (EST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26305
	for <saag@mit.edu>; Thu, 6 Dec 2001 10:50:33 -0500 (EST)
Received: from Baltimore-FW1 ([172.19.1.1])
	by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id PAA13980
	for <saag@mit.edu>; Thu, 6 Dec 2001 15:50:32 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T57a93e73e40a9919350ad@emeairlsw1.baltimore.com> for <saag@mit.edu>;
 Thu, 6 Dec 2001 15:46:37 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA16876
	for <saag@mit.edu>; Thu, 6 Dec 2001 15:50:29 GMT
Message-ID: <3C0F93E0.8464F25C@baltimore.ie>
Date: Thu, 06 Dec 2001 15:50:56 +0000
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [saag] XKMS meeting details
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

All,

Details of Sunday's xkms meeting are at:

http://www.w3.org/2001/XKMS/Meetings/SLC-Logistics.html

Please let me know if you plan to attend,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

From Jari.Arkko@lmf.ericsson.se  Fri Dec  7 08:04:37 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA26317
	for <saag@jis.mit.edu>; Fri, 7 Dec 2001 08:04:37 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA08492
	for <saag@mit.edu>; Fri, 7 Dec 2001 08:03:38 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fB7D3Bu19523;
	Fri, 7 Dec 2001 14:03:12 +0100 (MET)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id fB7D37Q4021906;
	Fri, 7 Dec 2001 15:03:07 +0200 (EET)
Message-ID: <3C10BE0B.E39F04F2@lmf.ericsson.se>
Date: Fri, 07 Dec 2001 15:03:07 +0200
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
CC: Thomas Narten <narten@us.ibm.com>, saag@mit.edu, wdixon@microsoft.com
Subject: Re: [saag] Home Address Option in MIPv6  (retry)
References: <Pine.BSF.4.21.0112050729020.15819-100000@internaut.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

>It seems to me that this option would need explicit support in a number of
>higher layer protocols.

I thought the intention in the MIPv6 spec is to have
upper layers (including IPsec policies) not be aware
of the CoA at all. That is, the home address information
would be already replaced at the packet by the time
SCTP or IPsec policy engines would take a look.

This would still allow, for instance, someone to send
an SCTP packet from source C1 with HOA H1 where the
SCTP is set up to say H1 and H2. SCTP would gladly
accept such a packet. If no other security was in place,
this would allow anyone in the global Internet to send
a packet to your SCTP box. The difference to the current
situation is that they could then bypass ingress filtering
while they now can't in those areas where ingress filtering
is in place.

In conclusion, I'm not sure I see why specific higher
layer handling is needed, but I do see that HOA allows
you to send IP packets more freely without regard to
the topology of the Internet.

>>  Does use of such an option create new avenues for DOS attacks (e.g.,
>>  reflectors attacks, etc.) or other problems that need consideration?
>
>Yes, it does. Might also complicate traceback. 

Here I agree.

Jari

From aboba@internaut.com  Fri Dec  7 11:05:59 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA28042
	for <saag@jis.mit.edu>; Fri, 7 Dec 2001 11:05:58 -0500 (EST)
Received: from internaut.com ([64.38.134.99])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA03326
	for <saag@mit.edu>; Fri, 7 Dec 2001 11:05:57 -0500 (EST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id HAA20066;
	Fri, 7 Dec 2001 07:53:51 -0800 (PST)
	(envelope-from aboba@internaut.com)
Date: Fri, 7 Dec 2001 07:53:51 -0800 (PST)
From: Bernard Aboba <aboba@internaut.com>
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
cc: Thomas Narten <narten@us.ibm.com>, saag@mit.edu, wdixon@microsoft.com
Subject: Re: [saag] Home Address Option in MIPv6  (retry)
In-Reply-To: <3C10BE0B.E39F04F2@lmf.ericsson.se>
Message-ID: <Pine.BSF.4.21.0112070749450.20024-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> In conclusion, I'm not sure I see why specific higher
> layer handling is needed, but I do see that HOA allows
> you to send IP packets more freely without regard to
> the topology of the Internet.

I wasn't suggesting that IPsec/SCTP wouldn't work with the Home Address
Option -- merely that the HAO would undermine  denial of service
and spoofing mechanisms that took a lot of effort to design. 



From rja@inet.org  Fri Dec  7 11:07:50 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA28097
	for <saag@jis.mit.edu>; Fri, 7 Dec 2001 11:07:50 -0500 (EST)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA04324
	for <saag@mit.edu>; Fri, 7 Dec 2001 11:07:49 -0500 (EST)
Received: from mosquito.inet.org (unknown [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 0D33167103; Fri,  7 Dec 2001 11:15:48 -0500 (EST)
Message-Id: <5.1.0.14.2.20011207105545.00a036b0@10.30.15.3>
X-Sender: rja@10.30.15.3
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 07 Dec 2001 10:58:17 -0500
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [saag] Home Address Option in MIPv6  (retry)
Cc: Bernard Aboba <aboba@internaut.com>, Thomas Narten <narten@us.ibm.com>,
        saag@mit.edu, wdixon@microsoft.com
In-Reply-To: <3C10BE0B.E39F04F2@lmf.ericsson.se>
References: <Pine.BSF.4.21.0112050729020.15819-100000@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

At 08:03 07/12/01, Jari Arkko wrote:
>>It seems to me that this option would need explicit support 
>>in a number of higher layer protocols.
>
>I thought the intention in the MIPv6 spec is to have
>upper layers (including IPsec policies) not be aware
>of the CoA at all. That is, the home address information
>would be already replaced at the packet by the time
>SCTP or IPsec policy engines would take a look.

That assumes a very specific approach to implementing
both IPsec, Security Policy processing in the OS, and
Mobile IPv6.  It isn't clear to me that all existing
implementations do it today in the way you assume above.

Usually, IETF tries to avoid applying lots of constraints
on implementers.  If it is really necessary in this situation,
it ought to be reviewed by ALL of the applicable WGs and
it ought to be really clearly documented that this 
implementation constraint exists.  Obviously, such a
constraint needs to have a clearly justification documented
BEFORE it is put in place.

IMHO,

Ran
rja@inet.org



From aboba@internaut.com  Fri Dec  7 12:32:08 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28994
	for <saag@jis.mit.edu>; Fri, 7 Dec 2001 12:32:08 -0500 (EST)
Received: from internaut.com ([64.38.134.99])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA09745
	for <saag@mit.edu>; Fri, 7 Dec 2001 12:32:07 -0500 (EST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id JAA20264;
	Fri, 7 Dec 2001 09:19:53 -0800 (PST)
	(envelope-from aboba@internaut.com)
Date: Fri, 7 Dec 2001 09:19:53 -0800 (PST)
From: Bernard Aboba <aboba@internaut.com>
To: RJ Atkinson <rja@inet.org>
cc: Jari Arkko <Jari.Arkko@lmf.ericsson.se>, Thomas Narten <narten@us.ibm.com>,
        saag@mit.edu, wdixon@microsoft.com
Subject: Re: [saag] Home Address Option in MIPv6  (retry)
In-Reply-To: <5.1.0.14.2.20011207105545.00a036b0@10.30.15.3>
Message-ID: <Pine.BSF.4.21.0112070913510.20251-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

> That assumes a very specific approach to implementing
> both IPsec, Security Policy processing in the OS, and
> Mobile IPv6.  It isn't clear to me that all existing
> implementations do it today in the way you assume above.

Where IPsec is implemented as a low level driver, it will typically
process the packet off the wire. While I suppose that this kind of
header manipulation could be wedged in early on in the
packet processing, I doubt that many implementations have support for
this kind of thing today. 

This will be particularly problematic with implementations which
support IPsec acceleration on the NIC. It is unlikely that IPsec
acceleration chipsets will support the required header manipulation,
since this would greatly complicate the design of the hardware. 

> Usually, IETF tries to avoid applying lots of constraints
> on implementers.  If it is really necessary in this situation,
> it ought to be reviewed by ALL of the applicable WGs and
> it ought to be really clearly documented that this 
> implementation constraint exists.  Obviously, such a
> constraint needs to have a clearly justification documented
> BEFORE it is put in place.

I agree. We shouldn't just be "slipstreaming" in these kind of changes
without discussing them in the WGs that are affected.


From coley@linus.mitre.org  Thu Dec 13 04:06:35 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA07617;
	Thu, 13 Dec 2001 04:06:35 -0500 (EST)
Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id EAA03598;
	Thu, 13 Dec 2001 04:06:34 -0500 (EST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58])
	by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id fBD96Y801782;
	Thu, 13 Dec 2001 04:06:34 -0500 (EST)
Received: from linus.mitre.org (linus.mitre.org [129.83.10.1])
	by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id fBD96Xs04863;
	Thu, 13 Dec 2001 04:06:33 -0500 (EST)
Received: (from coley@localhost)
	by linus.mitre.org (8.9.3/8.9.3) id EAA24120;
	Thu, 13 Dec 2001 04:06:33 -0500 (EST)
Date: Thu, 13 Dec 2001 04:06:33 -0500 (EST)
Message-Id: <200112130906.EAA24120@linus.mitre.org>
X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f
From: "Steven M. Christey" <coley@linus.mitre.org>
To: saag@mit.edu
CC: jis@mit.edu, cwysopal@atstake.com, coley@linus.mitre.org
Subject: [saag] Responsible Vulnerability Disclosure Process
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Enclosed please find our submission for an Internet-Draft, titled
"Responsible Vulnerability Disclosure Process."

As stated in an earlier message to Jeff Schiller, we appreciate being
notified by the Security Area Advisory Group when it was clear that we
were going astray of the openness that is the lifeblood of the IETF
standards process.  We never intended to keep this document private
for a long time.  We were just soliciting the valuable comments of
some reviewers who truly have a stake in this process: well known
reporters, vendors, and coordinators.  They clearly augment the
knowledge of ourselves.  We apologize for any embarrassment or
inconvenience that we have caused SAAG or other members of the IETF by
letting it be publicly known that we were contacting others for their
comments before submitting the document as an Internet Draft.

We humbly suggest that the "Considerations for Internet Drafts" page
at http://www.ietf.org/ID-nits.html could be modified to discourage
such behind-the-scenes creation of a draft without notifying the IETF
first.  For example, one comment says "Individual submissions (whether
general or to a working group) may be made without prior notice."  We
fully intended to find and notify the appropriate IETF authorities
before submitting an Internet-Draft.

We appreciate the opportunity to submit this draft directly to the
Security Area Advisory Group, especially given the imminent meeting of
your group.  We hope that this document, as late as it is for you (yet
weeks ahead of our intended schedule), will convince you of the
sincerity of our plans to operate within the IETF framework.


Best Regards,

Chris Wysopal (@stake, Inc.)
Steve Christey (The MITRE Corporation)













Individual Contribution                                   Steve Christey
INTERNET-DRAFT                                     The MITRE Corporation
Category: Best Current Practice                            Chris Wysopal
                                                            @stake, Inc.
                                                           December 2001

              Responsible Vulnerability Disclosure Process
              draft-christey-wysopal-vuln-reporting-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

      Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   A vulnerability is an issue in a software or hardware product that
   enables a malicious individual to subvert the security model of said
   product and potentially cause harm.  Responsible handling of
   vulnerability information allows product maintainers and users to
   remedy the security issue at hand while minimizing the impact that
   the information could cause in the hands of malicious individuals.

   The purpose of this document is to outline a process for the
   responsible handling of this information with the requisite
   interactions between vulnerability reporter, product vendor or
   maintainer, and ultimately the product customer or user.





Christey & Wysopal         Expires June 2002                    [Page 1]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


Table of Contents

   1 Introduction and Purpose
     1.1 Background
     1.2 Major Roles in Disclosure
     1.3 Motivations
     1.4 Goals of Responsible Disclosure
   2 Phases of Responsible Disclosure
   3 Responsibilities in the Phases of Vulnerability Disclosure
     3.1 Latent Flaw
     3.2 Discovery
     3.3 Notification Phase: Initial Notification
       3.3.1 Vendor Responsibilities
       3.3.2 Reporter Responsibilities
     3.4 Notification Phase: Vendor Receipt
       3.4.1 Vendor Responsibilities
     3.5 Validation Phase
       3.5.1 Vendor Responsibilities
       3.5.2 Reporter Responsibilities
       3.5.3 Coordinator Responsibilities
     3.6 Resolution Phase
       3.6.1 Vendor Responsibilities
       3.6.2 Reporter Responsibilities
     3.7 Release Phase
       3.7.1 Vendor Responsibilities
       3.7.2 Reporter Responsibilities
       3.7.3 Coordinator Responsibilities
       3.7.4 Customer Responsibilities
       3.7.5 Security Community Responsibilities
     3.8 Follow-Up Phase
   4 Policy Publication
     4.1 Vendor Policy
     4.2 Reporter Policy
     4.3 Coordinator Policy
   5 References
     5.1 Disclosure Policies
     5.2 Commentary on Disclosure Details
     5.3 Commentary on Disclosure Process
     5.4 Commentary on Advisories
     5.5 Commentary on Vendor Accessibility
     5.6 Discovery of Issues in the Wild
     5.7 Researcher Credibility and Vulnerability Reproduction
     5.8 Miscellaneous
   6 Acknowledgements
   7 Security Considerations
   8 Authors' Addresses



Christey & Wysopal         Expires June 2002                    [Page 2]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   9 Full Copyright Statement

Document Conventions

   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
   NOT", and "MAY" in this document are to be interpreted as described
   in "Key words for use in RFCs to Indicate Requirement Levels"
   [RFC2119].

1 Introduction and Purpose

   This document provides guidance and recommendations for the community
   of developers, vendors, end users, researchers and
   security professionals who wish to perform responsible vulnerability
   disclosure within the information technology arena.  For purposes of
   this document, the term "responsible" refers to the recognition of a
   formal, repeatable process for the reporting, evaluation, resolution
   and publication of vulnerability information.  "Vulnerability" refers
   to any bug, flaw, behavior, output, outcome or event within an
   application, system, device, or service that could lead to increased
   risk or security exploit.  For purposes of this document, we have
   standardized on the term "application" to encompass the full suite of
   products that are addressed by this document.

1.1 Background

   Vulnerabilities are an inherent and unfortunate part of the design
   and development process.  Vulnerability detection may occur during
   any phase of the product lifecycle, to include design, development,
   testing, implementation or operation.  Ideally, vulnerabilities are
   largely prevented through a design process that considers security.
   However, due to a variety of reasons, many vulnerabilities are
   detected after an application is implemented in an operational
   environment and supporting customer objectives.  A variety of
   legislative and social issues directly influences the process for
   vulnerability research, detection and response.  Developers,
   customers and the security community all have divergent perspectives
   on the impact of vulnerabilities.  Currently, vulnerability release
   is inconsistent and largely driven from the perspective of the party
   who has the greatest ability to control the process.  In an effort to
   create a common framework by which objectives are met to the benefit
   of all parties, this document communicates a formal, repeatable
   process for addressing vulnerability disclosure in a responsible
   manner.  This document provides a means to address the common goal of
   providing more secure applications while reducing the risk to
   customers.



Christey & Wysopal         Expires June 2002                    [Page 3]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


1.2 Major Roles in Disclosure

   Several types of individuals or organizations may play a role in the
   process of vulnerability disclosure.  These roles may overlap.

   A Vendor is an individual or organization who provides, develops, or
   maintains software, hardware, or services, possibly for free.

   A Customer is the end user of the software, hardware, or service that
   may be affected by the vulnerability.

   A Reporter is the individual or organization that informs (or
   attempts to inform) the Vendor of the vulnerability.  Note that the
   Reporter may not have been the initial discoverer of the problem.

   A Coordinator is an individual or organization who works with the
   Reporter and the Vendor to analyze and address the vulnerability.
   Coordinators are often well-known third parties.  Coordinators may
   have resources, credibility, or working relationships that exceed
   those of the reporter or vendors.  Coordinators may serve as proxies
   for reporters, help to verify the reporter's claims, resolve
   conflicts, and work with all parties to resolve the vulnerability in
   a satisfactory manner.  Note: while Coordinators can facilitate the
   responsible disclosure process for a vulnerability, they are not a
   requirement.

   The Security Community includes individuals or organizations whose
   primary goals include improving overall information technology
   security.  The community may include security administrators and
   analysts, system administrators who are responsible for the security
   of their systems, commercial or non-profit organizations who provide
   security-related products or services, researchers and academics,
   informal groups, and individuals.

1.3 Motivations

   Individuals and organizations have a wide variety of motivations
   (some in direct conflict with each other) that make the disclosure
   process more complex.

   Vendors may have one or more of the following motivations.  Some
   vendors believe that public notification may help their customers
   address vulnerabilities, at the possible cost of negative publicity.
   Some vendors may be unresponsive, or secretly fix vulnerabilities,
   for fear of negative publicity.  Some vendors may not have the
   technical skills to understand the nature of the vulnerability and



Christey & Wysopal         Expires June 2002                    [Page 4]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   the risk that it poses.

   Customers often wish to have secure products, but security features
   can make it more difficult to use those products.  Many customers do
   not care about the nature of the vulnerability.  However, there is a
   small percentage of customers for whom vulnerability information
   plays a critical role in their usage of products.  Some vendors may
   be customers of other vendors.

   Reporters have a variety of motivations.  Because reporters are often
   the means through which vulnerability information is communicated,
   they have a major impact on how the disclosure process is followed.
   Reporters may be motivated by altruism ("to make computers more
   secure"), recognition or fame, marketing to highlight technical
   skills (for individuals as well as companies), forcing unresponsive
   vendors to address a vulnerability, curiosity or the challenge of
   vulnerability analysis, or malicious intent to damage the reputations
   of specific vendors, wreak havoc, or cause financial damage to
   customers.  The vague goals of altruism are often open to different
   interpretations by different reporters.  Reporters may be
   inexperienced, malicious, or have insufficient resources to follow
   the full process of disclosure.  Reporters are seldom compensated for
   their important role in enhancing Internet security.

   The motivations for members of the security community may vary
   depending on the specific tasks that are being undertaken by the
   members.  Community members may have motivations that include those
   of vendors, customers, and/or reporters.  In addition, members of the
   security community may wish to track trends in vulnerabilities,
   identify new types of vulnerabilities, or design new products and
   processes to reduce the impact of vulnerabilities.

   Coordinators are often members of the security community, and as such
   may share the same motivations.  Coordinators may also be required by
   their mission or contract to perform this role.

1.4 Goals of Responsible Disclosure

   The goals of responsible disclosure include:

   1) Ensure that vulnerabilities can be identified and eliminated
   effectively and efficiently for all parties.

   2) Minimize the risk to customers from vulnerabilities that could
   cause damage to their systems.




Christey & Wysopal         Expires June 2002                    [Page 5]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   3) Provide customers with sufficient information for them to evaluate
   the level of security in vendors' products.

   4) Provide the security community with the information necessary to
   develop tools and methods for identifying, managing, and reducing the
   risks of vulnerabilities in information technology.

   5) Minimize the amount of time and resources required to manage
   vulnerability information.

   6) Facilitate long-term research and development of techniques,
   products, and processes for avoiding or mitigating vulnerabilities.

   7) Minimize the amount of antagonism that often exists between
   parties as a result of different assumptions and expectations, due to
   the lack of consistent and explicit disclosure practices.

2 Phases of Responsible Disclosure

   Following are the basic phases of the responsible vulnerability
   disclosure process.  Some of these phases may be bypassed in specific
   situations with agreement across all parties.  In other cases, one or
   more parties may not be responsible, skipping some phases.

   1) Latent Flaw.  A flaw is introduced into a product during its
   design, specification, development, installation, or default
   configuration.

   2) Discovery.  One or more individuals or organizations discover the
   flaw through casual evaluation, by accident, or as a result of
   focused analysis and testing.  In some cases, knowledge of the flaw
   may be kept within a particular group.  A vulnerability report or an
   exploit program may be discovered "in the wild," i.e. in use by
   malicious attackers or made available for use and distribution.

   3) Notification.  A reporter or coordinator notifies the vendor of
   the vulnerability ("Initial Notification").  In turn, the vendor
   provides the reporter or coordinator with assurances that the
   notification was received ("Vendor Receipt").

   4) Validation.  The vendor or other parties verify and validate the
   reporter's claims ("Reproduction").

   5) Resolution.  The vendor and other parties also try to identify
   where the flaw resides ("Diagnosis").  The vendor develops a patch or
   workaround that eliminates or reduces the risk of the vulnerability



Christey & Wysopal         Expires June 2002                    [Page 6]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   ("Fix Development").  The patch is then tested by other parties (such
   as reporter or coordinator) to ensure that the flaw has been
   corrected ("Patch Testing").

   6) Release.  The vendor, coordinator, and/or reporter release the
   information about the vulnerability, along with its resolution.  The
   vendor may initially release this information to its customers and
   other organizations with which it may have special relationships
   ("Limited release").  The vendor or other parties may then release
   the information - possibly with additional details - to the security
   community.

   7) Follow-up.  The vendor, customer, coordinator, reporter, or
   security community may conduct additional analysis of the
   vulnerability or the quality of its resolution.

3 Responsibilities in the Phases of Vulnerability Disclosure

3.1 Latent Flaw

   The following recommendations identify how most latent flaws can be
   avoided.

   1) The Vendor SHOULD ensure that programmers, designers, and testers
   are knowledgeable about common flaws in the design and implementation
   of products.

   Rationale: Some classes of vulnerabilities are well-known and can be
   easily exploited using repeatable techniques.  Educated programmers,
   designers, and testers can identify and eliminate vulnerabilities
   before the product is provided to customers, or prevent their
   introduction into the product in the first place.

   2) Customers SHOULD configure their applications and systems in ways
   that eliminate latent flaws or reduce the impact of latent flaws,
   including (1) removing default services that are not necessary for
   the operation of the affected systems, (2) limiting necessary
   services only to networks or systems that require access, (3)
   providing the applications with the minimal amount of access and
   privileges necessary for proper functioning, and (4) using security
   features of the application or operating system that reduce the
   chance that a flaw can be successfully exploited.

   Rationale: A large percentage of computer intrusions involve
   vulnerabilities for which a patch was available.  Many of these
   intrusions involve unnecessary access to system services.  In some



Christey & Wysopal         Expires June 2002                    [Page 7]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   cases, system configuration can reduce the overall risk of
   vulnerabilities (known and unknown).  For example, the Code Red and
   Nimda worms of 2001 were largely successful because of these factors.

   3) The Security Community SHOULD track all known vulnerabilities to
   identify new classes of vulnerabilities, educate the public about
   these types of vulnerabilities, and find ways to detect or prevent
   them in the development, testing, and deployment of products.

3.2 Discovery

   1) The Reporter SHOULD make a reasonable effort to ensure that:
   - the vulnerability is real
   - the process of getting the application into a known
     exploitable state is repeatable.
   - the vulnerability has not already been reported by the vendor or
     well-established vulnerability information sources.

   Rationale: Some vulnerabilities are re-discovered after they have
   already been fixed, or the reporter has introduced the problem due to
   misconfiguration, or the reporter identifies the symptoms of the
   vulnerability without determining the cause.  If the reporter ensures
   that the problem is new and real, then the reporter will will avoid
   unnecessarily consuming the time and resources spent by vendors and
   other parties in investigating the problem.

   Note: in some cases, a reporter may not be able to make a reasonable
   effort due to limitations of time, resources, access to the product,
   or expertise.  In some cases, the problem may only appear
   intermittently, or the product is only temporarily accessible to the
   reporter (e.g., when the reporter is a consultant who discovers the
   problem in products that a customer uses).  In other cases, the
   reporter may discover information about the vulnerability without
   having any access to the product.

   Note: in some cases, the reporter may be able to coerce the product
   into a state that is known to be exploitable, without creating a
   fully working exploit program (e.g., a buffer overflow with a long
   string of 'A' characters may produce a result that shows that the
   instruction pointer has been overwritten).  This is considered a
   reasonable effort.

3.3 Notification Phase: Initial Notification

   To facilitate the disclosure process, Vendors need to be accessible
   to Reporters, and Reporters need to find and use the appropriate



Christey & Wysopal         Expires June 2002                    [Page 8]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   communication channels for notifying Vendors.

3.3.1 Vendor Responsibilities

   1) The Vendor MUST make it as easy as possible for Reporters,
   Coordinators, Customers, and the Security Community to notify the
   Vendor of vulnerabilities.

   Rationale: It is often difficult for reporters or other parties to
   notify vendors of vulnerabilities, especially if the reporters are
   not customers.  This may cause the parties to bypass other phases of
   the disclosure process, or adopt a policy that avoids vendor
   notification because of previous bad experiences with vendors.

   2) The Vendor SHOULD establish a Security Response Capability (SRC)
   that consists of one or more individuals or groups that are
   responsible for responding to vulnerability reports, verifying
   vulnerabilities, releasing bulletins, etc.

   3) The Vendor SHOULD ensure that its staff knows how to recognize a
   reported security issue and direct it to the Security Response
   Capability.  This recommendation applies to staff who provide support
   online, over the telephone, in person, or through some other means by
   which reporters may interact with the Vendor.

   4) If the Vendor can control the e-mail addresses that it uses (e.g.,
   it has its own domain name), then the Vendor SHOULD define and
   publish the "secalert" alias for use in vulnerability notification.

   Rationale: Currently, Vendors use a variety of aliases for
   notification, including "security-alert," "security," and "support."
   Some Vendors may use the "security" alias for physical security
   facilities.  The "security" alias is also defined in RFC2142 for use
   in incident handling.  The "security-alert" alias is longer than 8
   characters and contains a dash, which could make it more difficult to
   use or locate in search engines.  The "secalert" alias is not
   commonly used at this time, and as such it does not have the types of
   issues that some commonly-used aliases have.

   Note: smaller vendors may not be able to control which e-mail
   addresses they use.

   5) If the Vendor operates a web site or other means of distributing
   information regarding its product, then the Vendor SHOULD create and
   publish a "security" page or folder that identifies how vulnerability
   reports should be made.  The Vendor SHOULD make this page easy to



Christey & Wysopal         Expires June 2002                    [Page 9]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   find from other locations, such as a separate contact page or index.

   6) The Vendor MUST provide a facility for individuals or
   organizations who are not Customers to report vulnerabilities.  The
   Vendor SHOULD NOT require (1) an active technical support number, (2)
   telephone access that is not toll-free, or (3) user registration for
   a web site or other facility that would be used for reporting.

   Rationale: As described earlier, some reporters or coordinators are
   not necessarily customers of the Vendor.  If the Vendor is not
   accessible to them, then they will be more likely to bypass other
   aspects of this process.

   7) The Vendor SHOULD recognize that inexperienced or malicious
   reporters may not use proper notification, and define its own
   procedures for handling such cases.

3.3.2 Reporter Responsibilities

   1) The Reporter SHOULD make reasonable efforts to use the appropriate
   channels for notifying the Vendor of the vulnerability:

   (a) The Reporter SHOULD attempt to notify the vendor through the
   channels described in this section.

   (b) If the Vendor is not accessible through those channels, then the
   Reporter MAY attempt to contact the vendor through technical support.

   Note: in some cases, a reporter may not be able to make a reasonable
   effort due to time limitations, lack of proper access to the vendor,
   inexperience, expense, prohibitions by the reporter's own
   organization, or the reporter does not meet some criteria for
   notification (e.g., a support contract number).

   2) If the Reporter is unable to notify the Vendor, then the Reporter
   SHOULD ask a Coordinator to notify the Vendor.  The Reporter SHOULD
   provide the Coordinator with a list of contacts or mechanisms that
   were used to attempt to notify the Vendor.

   Rationale: a Coordinator may appear more credible than the Reporter,
   or have a previously established relationship with the Vendor.  The
   Reporter may be prohibited from disclosing the vulnerability directly
   to the Vendor.

   Note: the Coordinator will not necessarily have a different way of
   reaching the Vendor than the Reporter does.



Christey & Wysopal         Expires June 2002                   [Page 10]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   3) The Reporter and/or Coordinator SHOULD record the date of
   notification.

   Rationale: This helps Customers, Reporters, Coordinators, and the
   Security Community track how long it takes for a Vendor to resolve a
   vulnerability after the initial notification.

   4) The Reporter SHOULD provide the Vendor, and the Coordinator (if
   any), with all known details of the issue, including any programs,
   scripts, or pseudo-code that would allow the Vendor to reproduce
   and/or confirm the vulnerability.

   Rationale: such details make it easier for the Vendor and Coordinator
   to reproduce and diagnose the vulnerability, which then allows the
   Vendor to identify or develop a resolution more quickly.

   Note: some vulnerabilities may be theoretical or not well-understood
   in this phase of the disclosure process, and the Reporter may not
   have developed programs that exploit the problem.  In other cases,
   the Reporter may be using proprietary programs to demonstrate the
   vulnerability.

3.4 Notification Phase: Vendor Receipt

3.4.1 Vendor Responsibilities

   1) The Vendor MUST notify the Reporter and involved Coordinators that
   the Vendor has received the notification.  This Receipt does not
   necessarily imply that the Vendor has researched or reproduced the
   vulnerability, only that the Vendor is aware of the notification.

   Rationale: if the Vendor does not respond, then the Reporter or
   Coordinator may not be sure if the Vendor is truly aware of the
   reported vulnerability, and/or if the Vendor intends to resolve the
   vulnerability.  This often causes Reporters or Coordinators to bypass
   later phases of the disclosure process in order to warn customers of
   the risks to their systems.

   2) The Vendor MUST provide the Reporter and involved Coordinators
   with a Receipt within 7 days.

   Rationale: Other time frames (such as 5 business days) were
   considered but deemed unworkable due to international issues (e.g.,
   "work weeks" may fall on different days in different countries, there
   are different national or religious holidays).  Defining a time frame
   relative to the Vendor or Reporter could not work without some form



Christey & Wysopal         Expires June 2002                   [Page 11]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   of communication between both parties.

   Note: small but responsible Vendors or individuals may not be able to
   provide this degree of responsiveness, especially during vacation
   periods.  Reporters and Coordinators SHOULD take this into account
   during the notification phase.  Small, responsible Vendors SHOULD
   post some clear notification when it is known that such delays will
   occur.

   3) If the Vendor's receipt message is automatically generated, then
   it SHOULD include a time period or date by which an individual (or
   the Security Response Capability) will provide follow-up on the
   reported vulnerability.  The time period SHOULD NOT exceed 10 days.

   4) Within 10 days of initial notification, the Vendor's Security
   Response Capability SHOULD provide a clear response to the Reporter
   and any involved Coordinators.

3.5 Validation Phase

3.5.1 Vendor Responsibilities

   1) If the vulnerability is found in a supported product, the Vendor
   MUST either (1) reproduce the vulnerability, (2) determine if there
   is enough evidence for the existence of the vulnerability when it
   cannot be reproduced, (3) determine if the vulnerability is already
   known (and possibly resolved), or (4) work with the Reporter to
   determine if the vulnerability is related to the specific environment
   in which it was discovered (including configuration errors or
   interactions with other products).

   2) If the vulnerability is found in an unsupported or discontinued
   product, the Vendor MAY refuse to validate the vulnerability.
   However, the Vendor MUST ensure that the reported vulnerability does
   not exist in supported product versions or other supported products
   based on the vulnerable product.

   3) The Vendor SHOULD NOT assume that the risk or impact of the
   vulnerability is limited to what has been identified by the Reporter
   or involved Coordinator.

   Rationale: The Reporter or involved Coordinator may not have
   sufficient experience or time to identify the full scope of the
   problem.  Sometimes, a theoretical vulnerability is later found to be
   more easily exploitable as a result of follow-on analysis or the
   creation of a tool.  For example, it may be easy for a Reporter to



Christey & Wysopal         Expires June 2002                   [Page 12]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   find evidence of a buffer overflow vulnerability by providing a large
   argument that causes an application to crash.  It is an indicator
   that a carefully crafted program could be used to execute arbitrary
   code.  The Reporter and Vendor may not have the skills or resources
   to create such a program, but such a program could be created in the
   future.

   4) The Vendor SHOULD examine its product to ensure that it is free of
   other problems that are similar to the reported vulnerability.

   Rationale: some Vendors reproduce and resolve the specific issue that
   is identified by the Reporter without extending their analysis to see
   if similar mistakes were made elsewhere in the product.  The
   Reporter, others in the Security Community, or hackers may conduct
   follow-on research to find these other vulnerabilities.  This can
   result in a cycle in which vulnerabilities are discovered and patched
   so often that it becomes difficult for customers to manage the volume
   of resolutions that they need to apply.

   5) The Vendor MUST consult with the Reporter and involved
   Coordinators when more information or analysis is needed.

   6) The Vendor SHOULD provide status updates to the Reporter and any
   involved Coordinators every 7 days.  The Vendor MAY negotiate with
   the parties for less frequent updates.

   7) The Vendor MUST notify the Reporter and any involved Coordinators
   when the Vendor is able to reproduce the vulnerability.

   8) The Vendor SHOULD attempt to resolve the vulnerability within 30
   days of initial notification.

   9) If the Vendor cannot resolve the vulnerability within 30 days,
   then the Vendor MUST provide the Reporter and involved Coordinators
   with specific reasons why the vulnerability cannot be resolved.

   10) If the Vendor is aware of other vendors that share the same
   codebase as the affected product, then the Vendor MUST either (1)
   notify those vendors, or (2) notify a Coordinator that other Vendors
   may be affected by the reported vulnerability.

3.5.2 Reporter Responsibilities

   1) The Reporter SHOULD work with the Vendor in a timely fashion to
   explain the vulnerability and conduct further analysis.




Christey & Wysopal         Expires June 2002                   [Page 13]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   Rationale: if a problem is sufficiently complex or only appears in a
   portion of deployed systems, then the Vendor may not be able to
   reproduce the issue.  In other cases, the Vendor may not understand
   the problem.  If the Reporter is slow to respond, then this can
   extend the time window during which Customers are at risk.

   2) If the Vendor does not understand the nature, risk, or resolution
   of the vulnerability, then the Reporter or involved Coordinators
   SHOULD provide the Vendor with resources that help to explain the
   vulnerability.

   Note: Some Vendors may require - or insist - upon extensive
   consultation to identify the vulnerability.  Reporters and
   Coordinators may not have the time or resources to provide such
   assistance.

   3) If the Reporter does not have the time or resources to conduct
   such analysis, then the Reporter SHOULD notify the Vendor and suggest
   alternate contacts (such as Coordinators) who may be able to assist
   the Vendor.  The Reporter SHOULD NOT attempt to bypass later phases.

   4) If the Reporter finds that the Reporter is in error, then the
   Reporter SHOULD notify the Vendor and involved Coordinators.

   Rationale: if a Reporter does not perform this notification, then the
   Vendors or Coordinators may continue to spend unnecessary resources
   on further analysis of the issue.

   5) The Reporter SHOULD grant time extensions to the Vendor if there
   is evidence that the Vendor is acting in good faith to resolve the
   vulnerability.

   6) If the Vendor is unresponsive or disagrees with the Reporter's
   findings, then the Reporter SHOULD involve a Coordinator.

3.5.3 Coordinator Responsibilities

   1) The Coordinator MUST attempt to resolve any conflicts or technical
   disagreements that arise between the Reporter and the Vendor.

   2) If a Vendor is unresponsive or does not appear to be acting in
   good faith to resolve the vulnerability, then the Coordinator SHOULD
   attempt to convince the Vendor to follow the proper process.

   3) If a Reporter is unresponsive or does not appear to be acting in
   good faith to resolve the vulnerability, then the Coordinator SHOULD



Christey & Wysopal         Expires June 2002                   [Page 14]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   attempt to convince the Reporter to follow the proper process.

   4) The Coordinator SHOULD work with the Vendor and Reporter to
   determine if other Vendors are affected by the same problem.

   5) The Coordinator SHOULD work with the Vendor and Reporter to
   identify time extensions (if any) that are acceptable to all parties.

3.6 Resolution Phase

   The "Resolution" of a vulnerability involves action regarding one or
   more of the following:
      - patch creation
      - recommendation of configuration change
      - design change
      - workaround
      - no action

   If the Vendor does not participate or is unresponsive, then the
   Reporter and Coordinator might not be able to create a patch or
   change the design of the product.

3.6.1 Vendor Responsibilities

   1) The Vendor MUST identify the fundamental nature of the flaw within
   the source code or in the design of the product ("Diagnosis").

   2) The Vendor MUST either (1) provide a patch, configuration change,
   or workaround that appropriately reduces or eliminates the risk of
   the vulnerability ("Fix Development"), or (2) provide the Reporter
   and involved Coordinators with specific reasons for its inaction.

   3) The Vendor SHOULD request time extensions from the Reporter and
   involved Coordinators when necessary.

   4) The Vendor SHOULD test the patches, configuration changes, and
   workarounds sufficiently to ensure that either (1) they do not
   adversely affect the operation of the product, or (2) it is clear
   which conditions may adversely affect the operation of the product.

   Rationale: Vendors may be pressured to quickly resolve
   vulnerabilities without sufficient testing, especially when Reporters
   have bypassed the Notification or Validation phases.  As a result,
   the resolution may adversely affect more systems than necessary.

   5) The Vendor MUST provide the Reporter and involved Coordinators



Christey & Wysopal         Expires June 2002                   [Page 15]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   with all known configuration changes or workarounds that address the
   vulnerability ("Fix Development").

   6) The Vendor SHOULD provide the Reporter and involved Coordinators
   with any patches ("Patch Testing").

   Rationale: this helps the Reporter and Coordinator to confirm that
   the vulnerability has been reduced or eliminated.

   Note: the Vendor's business model may require that only supported
   Customers can have access to a patch, which could exclude Reporters
   or Coordinators.  Such Vendors should recognize that this practice
   may result in an incomplete patch that does not address the
   vulnerability in question.

   7) If the Reporter is unresponsive or uncooperative, or a dispute
   arises, then the Vendor SHOULD work with a Coordinator to identify
   the best available resolution for the vulnerability.

3.6.2 Reporter Responsibilities

   1) The Reporter SHOULD recognize that it may be difficult for a
   Vendor to resolve a vulnerability with 30 days if (1) the problem is
   related to insecure design, (2) the Vendor has a diverse set of
   hardware, operating systems, and/or application versions to support,
   or (3) the Vendor is not skilled in security.

   2) The Reporter SHOULD grant time extensions to the Vendor if the
   Vendor is acting in good faith to resolve the vulnerability.

   3) If the Vendor is unresponsive or uncooperative, or a dispute
   arises, then the Reporter SHOULD work with a Coordinator to identify
   the best available resolution for the vulnerability.

3.7 Release Phase

3.7.1 Vendor Responsibilities

   1) The Vendor SHOULD work with the Reporter and involved Coordinators
   to arrange a date after which the vulnerability information may be
   released.

   2) The Vendor MAY ask the Reporter and Coordinator to allow a "Grace
   Period" up to 30 days, during which the Reporter and Coordinator do
   not release details of the vulnerability that could make it easier
   for hackers to create exploit programs.



Christey & Wysopal         Expires June 2002                   [Page 16]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   Rationale: a grace period provides Customers with a time period in
   which they can fix their systems.  During this time, the lack of
   details may make it more difficult or resource-intensive for
   attackers to determine the nature of the vulnerability and craft an
   exploit.  However, some security-aware Customers desire such details
   so that they can better decide whether the resolution of the
   vulnerability is appropriate for their environment.  In addition,
   some members of the Security Community desire such details in order
   to (1) enhance tools or techniques to detect vulnerable systems on
   Customer networks (such as vulnerability scanners), (2) enhance tools
   or techniques to detect attempts to exploit vulnerabilities on
   Customer networks (such as intrusion detection systems), (3) provide
   databases or other information that Customers use to identify and
   prioritize vulnerabilities that may affect the Customer's enterprise,
   and (4) perform research and trend analysis.

   3) If the Reporter has not properly followed the process and publicly
   announces the vulnerability, then the Vendor SHOULD post its
   awareness of the vulnerability, and the Vendor's progress in its
   resolution, to appropriate forums.

   Rationale: this allows Customers and the Security Community to know
   that the Vendor is aware of the problem and working to resolve it.

   Note: some Vendors may not wish to acknowledge such vulnerabilities
   until a patch is available.

   4) If a Reporter has properly followed the process, then the Vendor
   MUST provide credit to that reporter.

   5) If a Coordinator has properly followed the process, then the
   Vendor SHOULD provide credit to the Coordinator.

   6) If a Reporter has not properly followed the process and publicly
   announces the vulnerability, then the Vendor MAY provide credit to
   the reporter.

   Rationale: Some people believe that even if a reporter has not
   followed the procedures properly, the reporter has still provided
   valuable information that is useful to the Vendor, Customers,
   Coordinators, and the Security Community, and academic integrity
   would dictate that reporters should be credited.  However, since
   credit is a motivation for some reporters, others believe that
   irresponsible reporters should not be encouraged to bypass the
   process and still get credit.




Christey & Wysopal         Expires June 2002                   [Page 17]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   7) The Vendor MUST NOT assume that the lack of vulnerability details
   will prevent the creation of an exploit.

   Rationale: If the Vendor provides source code for the product, then
   any entity who has access to the product could easily determine the
   specific locations of the vulnerability and identify possible attack
   vectors that reach the vulnerable code.  If the Vendor does not
   provide source code, then any entity who has access to a patch could
   use reverse engineering techniques to determine how the code was
   changed, then infer the nature of the vulnerability.

   8) The Vendor SHOULD cryptographically sign all patches using a
   method that is commonly accessible on the platforms for the Vendor's
   product.  The Vendor should clearly advertise its cryptographic key
   and provide cryptographic checksums for its patches.

   Rationale: This increases the assurance that the patches from the
   Vendor are authentic.

   9) The Vendor SHOULD provide an easily accessible mechanism for
   Customers and the Security Community to obtain all security
   advisories, such as a web page.  The most recent advisory SHOULD be
   listed first.

   10) The Vendor SHOULD provide a mechanism for notifying Customers and
   the Security Community when new advisories are published.

   11) The Vendor SHOULD provide a means for the Security Community to
   identify which reported vulnerabilities are genuine, but are not
   regarded by the Vendor as important enough to merit a security
   advisory.

   Rationale: Vendors are often unwilling to release security advisories
   unless the security issue is critical for its Customers.  This can
   reduce operating expenses for the Vendor and most Customers.
   However, some members of the Security Community, and some Customers,
   also prefer to protect themselves against less serious
   vulnerabilities.  If a Vendor does not at least indicate to its
   security-aware Customers that a security-related resolution is
   available, then those Customers may remain at risk for
   vulnerabilities that they would otherwise wish to resolve.

   12) The Vendor SHOULD provide an easily accessible indicator that
   allows a Customer to determine if the resolution has been applied to
   a system, e.g. by modifying the product's version number or providing
   the Customer with a tool that identifies the resolutions that have



Christey & Wysopal         Expires June 2002                   [Page 18]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   been applied to a product.

3.7.2 Reporter Responsibilities

   1) The Reporter SHOULD work with the Vendor and involved Coordinators
   to arrange a date after which the vulnerability information may be
   released.

   2) If the Vendor has not resolved the vulnerability within a time
   frame that is allowed by this process, then the Reporter SHOULD work
   with a Coordinator to announce the vulnerability to Customers and the
   Security Community.

   3) If another reporter has not properly followed the process and
   publicly announced the vulnerability, then the Reporter MAY announce
   that the Reporter was responsibly following the disclosure process
   with the Vendor and involved Coordinators.

   4) If a Vendor requests a Grace Period, then the Reporter SHOULD
   follow the Grace Period before releasing details of the
   vulnerability.

   5) After the Grace Period, the Reporter MAY release additional
   details.  The Reporter SHOULD carefully consider how much detail is
   needed by Customers and the Security Community.

   Note: in some cases, the nature of the vulnerability could make it
   difficult or impossible to release vulnerability details that do not
   allow someone to exploit the vulnerability.

   6) The Reporter SHOULD provide credit to any Vendor and/or
   Coordinator who has followed the process.

3.7.3 Coordinator Responsibilities

   1) The Coordinator SHOULD work with the Vendor and Reporter to
   arrange a date after which the vulnerability information may be
   released.

   2) If the Vendor requests a Grace Period, the Coordinator SHOULD
   follow the Grace Period and encourage the Reporter to follow the
   Grace Period.

   3) The Coordinator SHOULD provide credit to any Vendor and/or
   Reporter who properly follows the process.




Christey & Wysopal         Expires June 2002                   [Page 19]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   4) The Coordinator MAY provide credit to a reporter who has not
   properly followed the process.

3.7.4 Customer Responsibilities

   1) The Customer MUST NOT assume that the lack of details will prevent
   the creation of an exploit.

   2) If the Vendor has released information regarding the
   vulnerability, then the Customer SHOULD assume that the information
   is credible.  The Customer SHOULD NOT require that the vulnerability
   be demonstrated before applying the resolution.

   3) If the Vendor has not released such information, but a well-
   established Reporter or Coordinator has, then the Customer SHOULD
   assume that the information is credible.  The Customer SHOULD NOT
   require that the vulnerability be demonstrated before applying the
   resolution.

   4) If vulnerability information has been released and a Grace Period
   exists, then the Customer SHOULD apply the resolution to its systems
   during the Grace Period.

   5) Where possible, the Customer SHOULD test any patches,
   configuration changes, or workarounds on test systems before making
   the changes in an operational environment.

   6) The Customer SHOULD inform the Vendor and the Security Community
   if a patch, configuration change, or workaround does not appear to
   work properly.

   7) The Customer SHOULD give preference to products whose Vendors
   follow responsible disclosure practices.

3.7.5 Security Community Responsibilities

   1) The Security Community SHOULD publicly recognize all Vendors,
   Reporters, and Coordinators who follow responsible vulnerability
   disclosure.

   2) The Security Community SHOULD adopt a set of terms that allows all
   parties to describe the inherent risk or impact of a vulnerability
   that can be interpreted in various environments, threat levels, and
   policies.

   Rationale: Customers have varying operational needs at different



Christey & Wysopal         Expires June 2002                   [Page 20]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   levels of security, which can make it difficult to define a "one size
   fits all" risk level for any vulnerability.  Current terminology
   often uses a "High, Medium, Low" breakdown, but there are no formal
   definitions.  As such, this terminology is used inconsistently,
   partially because it is based on the perspective of the entity who is
   using it.  It is also insufficient to capture the complexity and
   tradeoffs of vulnerabilities in today's environment.

3.8 Follow-Up Phase

   1) The Vendor SHOULD clearly notify Customers and the Security
   Community when a resolution is (a) faulty, or (b) revised.

   2) The Vendor SHOULD NOT re-release the same advisory for newly
   discovered, closely related vulnerabilities.

   Rationale: The re-release of an advisory may not be noticed as well
   by Customers, which could cause the Customers to believe that their
   systems are secure because they applied the resolution that was
   identified in the original advisory.

4 Policy Publication

4.1 Vendor Policy

   A Vendor SHOULD publish a policy and procedures statement that
   includes the following information:

   1) Where it complies (and does not comply) with the process outlined
   in this document.

   2) The typical amount of time after notification that the Vendor
   requires to produce a resolution.

   3) The Grace Period, if any, that the Vendor wishes to observe.

   4) How the Vendor determines whether a reported problem is serious
   enough to merit a security advisory.

4.2 Reporter Policy

   If a Reporter is a member of the Security Community and the Reporter
   frequently finds new vulnerabilities, then the Reporter SHOULD
   publish a policy and procedures statement that includes the following
   information:




Christey & Wysopal         Expires June 2002                   [Page 21]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   1) Where it complies (and does not comply) with the process outlined
   in this document.

   2) The maximum Grace Period that the Reporter is willing to follow.

4.3 Coordinator Policy

   A Coordinator SHOULD publish a policy and procedures statement that
   includes the following information:

   1) Where the Coordinator complies (and does not comply) with the
   process outlined in this document.

   2) The maximum Grace Period that the Coordinator is willing to
   follow.

5 References

   Note: many of these references identify posted messages to security-
   related mailing lists.  These messages often resulted in long threads
   that explore the related issues in more depth.

5.1 Disclosure Policies

   RFPolicy 2.0
   http://www.wiretrip.net/rfp/policy.html.

   Bugtraq Frequently Asked Questions
   http://www.securityfocus.com/popups/forums/bugtraq/faq.shtml

   NTBugtraq Disclosure Policy
   http://ntbugtraq.ntadvice.com/default.asp?sid=1&pid=47&aid=48

   CERT/CC Vulnerability Disclosure Policy
   http://www.kb.cert.org/vuls/html/disclosure/

   ACROS ASPR Notification and Publishing Policy
   http://www.acros.si/aspr_policy.html

   NMRC policy
   http://www.nmrc.org/advise/policy.txt

   @stake Security Advisory Disclosure Policy
   http://www.atstake.com/research/policy/index.html

5.2 Commentary on Disclosure Details



Christey & Wysopal         Expires June 2002                   [Page 22]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   "Full Disclosure is a necessary evil"
   Elias Levy
   SecurityFocus web site
   August 16, 2001
   http://www.securityfocus.com/news/238

   "It's Time to End Information Anarchy"
   Scott Culp
   Microsoft web site
   October 2001
   http://www.microsoft.com/technet/columns/security/noarch.asp

   "Security in an Open Electronic Society"
   Elias Levy
   SecurityFocus web site
   October 21, 2001.
   http://www.securityfocus.com/news/270

   "Is Disclosing Vulnerabilities A Security Risk In Itself?"
   Bruce Schneier:
   Internet Week
   November 20, 2001
   http://www.internetweek.com/graymatter/secure111901.htm

   "Script Kiddies Suck"
   Marcus Ranum
   Black Hat Briefings presentation
   July 2000
   http://web.ranum.com/usenix/blackhat-2000-keynote.mp3

   "The Network Police Blotter: The Slaughter of the Innocents"
   Marcus Ranum
   ;Login:
   October 2000
   http://web.ranum.com/usenix/ranum_5_temp.pdf

5.3 Commentary on Disclosure Process

   "Bugs in the Disclosure Process"
   Ivan Arce
   TISC Insight, Volume 3, Issue 3
   February 9, 2001
   http://tisc.corecom.com/newsletters/33.html

   "SUMMARY: Bug announcement rule of thumb."
   Bill Stout



Christey & Wysopal         Expires June 2002                   [Page 23]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   NTBUGTRAQ
   August 13, 1998.
   http://marc.theaimsgroup.com/?l=ntbugtraq&m=90310164223252&w=2

   "Microsoft admits IE security alert lapse"
   Wendy McAuliffe
   ZDNet
   November 19, 2001
   http://www.zdnet.com/filters/printerfriendly/0,6061,2825716-2,00.html

   "RFP2K03: Contemplations on dvwssr.dll and its affects on life"
   Rain Forest Puppy
   Bugtraq
   April 20, 2000
   http://marc.theaimsgroup.com/?l=bugtraq&m=95633636721100&w=2

   "Xato Advisory: Win2k/XP Terminal Services IP Spoofing"
   Xato
   Bugtraq
   November 14, 2001
   http://marc.theaimsgroup.com/?l=bugtraq&m=100578220002083&w=2

   "Vulnerability Escrow (was: Extreme Hacking)"
   Crispin Cowan
   NFR Wizards mailing list
   July 7, 1999
   http://archives.neohapsis.com/archives/nfr-wizards/1999_2/0416.html

   "Can we afford full disclosure of security holes?"
   Richard M. Smith
   Bugtraq
   August 10, 2001
   http://marc.theaimsgroup.com/?l=bugtraq&m=99747112928288&w=2

   "Anti-Web 'Vulnerability' is a false alarm"
   Doug Hoyte
   Vuln-dev mailing list
   December 1, 2001

   "Windows of Vulnerability: A Case Study Analysis"
   William A. Arbaugh, William L. Fithen, John McHugh
   IEEE Computer
   December 2000

   "Sun denies Unix flaw"
   John Geralds



Christey & Wysopal         Expires June 2002                   [Page 24]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   vnunet.com
   November 20, 2001
   http://www.vnunet.com/News/1126973

   "Open Response To Microsoft Security - RE: It's Time to End
   Information Anarchy"
   Steve Manzuik
   Vuln-Dev
   October 17, 2001
   http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0195.html

   "A Step Towards Information Anarchy: A Call To Arms"
   hellNbak
   Nomad Mobile Research Center
   November 2, 2001
   http://www.nmrc.org/InfoAnarchy/InfoAnarchy.htm

   "To Disclose or Not to Disclose, That Is the Question"
   Mark Joseph Edwards
   Windows 2000 Magazine
   June 27, 2001
   http://www.windowsitsecurity.com/Articles/Index.cfm?ArticleID=21618

   "Towards a responsible vulnerability process"
   David LeBlanc
   NTBUGTRAQ
   November 3, 2001
   http://archives.neohapsis.com/archives/ntbugtraq/2001-q4/0097.html

5.4 Commentary on Advisories

   "Writing security advisories"
   Kurt Seifried
   September 10, 2001
   http://www.seifried.org/security/articles/20010910-writing-security-
   advisories.html

   "Xato commentary on MS security bulletins"
   Xato
   Bugtraq
   December 7, 2000
   http://marc.theaimsgroup.com/?l=bugtraq&m=97626305317046&w=2

5.5 Commentary on Vendor Accessibility

   "Getting to the Third Wave of Security Responsiveness"



Christey & Wysopal         Expires June 2002                   [Page 25]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   Scott Culp
   January 2001
   http://www.microsoft.com/technet/columns/security/thrdwave.asp

   "An informal analysis of vendor acknowledgement of vulnerabilities"
   Steve Christey, Barbara Pease
   Bugtraq
   March 11, 2001
   http://marc.theaimsgroup.com/?l=bugtraq&m=98438570915835&w=2

   "Shockwave Flash buffer overflow"
   Neal Krawetz
   Bugtraq
   December 29, 2000
   http://marc.theaimsgroup.com/?l=bugtraq&m=97845942432045&w=2

   "Re: Shockwave Flash buffer overflow"
   Peter Santangeli
   Bugtraq
   January 5, 2001
   http://marc.theaimsgroup.com/?l=bugtraq&m=97897439808223&w=2

   "Re: SafeWord Agent for SSH (secure shell) vulnerability"
   Leif Nixon
   Bugtraq
   November 29, 2001
   http://marc.theaimsgroup.com/?l=bugtraq&m=100706579514862&w=2

5.6 Discovery of Issues in the Wild

   "sadmind"
   Nancy Lin
   SF-INCIDENTS mailing list
   December 9, 1999
   http://marc.theaimsgroup.com/?l=incidents&m=94476722417209&w=2

   "sadmind exploits (remote sparc/x86)"
   Marcy Abene
   Bugtraq
   December 10, 1999
   http://marc.theaimsgroup.com/?l=bugtraq&m=94486731225359&w=2

   "IIS %c1%1c remote command execution"
   Rain Forest Puppy
   Bugtraq
   October 17, 2000



Christey & Wysopal         Expires June 2002                   [Page 26]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   http://marc.theaimsgroup.com/?l=bugtraq&m=97180137413891&w=2

5.7 Researcher Credibility and Vulnerability Reproduction

   "vCard DoS on Outlook 2000"
   Joel Moses
   Bugtraq
   August 31, 2000
   http://marc.theaimsgroup.com/?l=bugtraq&m=96774764029236&w=2

   "Microsoft Outlook 2000 vCard Buffer Overrun"
   @stake
   February 26, 2001
   http://www.atstake.com/research/advisories/2001/a022301-1.txt

   "Re: Microsoft Security Bulletin MS01-012"
   Joel Moses
   Bugtraq
   February 23, 2001
   http://marc.theaimsgroup.com/?l=bugtraq&m=98322714210100&w=2

5.8 Miscellaneous

   "Vulnerability disclosure publications and discussion tracking"
   University of Oulu
   November 20, 2001
   http://www.ee.oulu.fi/research/ouspg/sage/disclosure-tracking/

   "Devil in the details - why package signing matters"
   Kurt Seifried
   October 24, 2001
   http://www.seifried.org/security/articles/20011023-devil-in-details.html

6 Acknowledgements

   We gratefully acknowledge the constructive comments received from
   several contributors.  Any errors or inconsistencies in this document
   are solely the responsibility of the authors, and not of the
   reviewers.  This document does not necessarily entirely reflect the
   opinion of the reviewers or their parent organizations.

   We would like to thank Andy Balinsky, Mary Ann Davidson, Elias Levy,
   Russ Cooper, Scott Blake, Seth Arnold, Rain Forest Puppy, Marcus
   Ranum, Lori Woeler, Adam Shostack, Mark Loveless, Scott Culp, and
   Shawn Hernan for their valuable input.




Christey & Wysopal         Expires June 2002                   [Page 27]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


7 Security Considerations

   This entire document discusses security issues.

8 Authors' Addresses

   Steve Christey
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA 01730
   USA

   E-Mail: coley@mitre.org

   Chris Wysopal
   @stake, Inc.
   196 Broadway
   Cambridge, MA 02139-1902
   USA

   E-Mail: cwysopal@atstake.com

9 Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organisations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING



Christey & Wysopal         Expires June 2002                   [Page 28]





Internet-Draft    Responsible Vulnerability Disclosure     December 2001


   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

   This document expires June 12, 2002.












































Christey & Wysopal         Expires June 2002                   [Page 29]



From pete.chown@skygate.co.uk  Thu Dec 13 06:29:03 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA08151
	for <saag@jis.mit.edu>; Thu, 13 Dec 2001 06:29:03 -0500 (EST)
Received: from lion.skygate.co.uk (lion.skygate.co.uk [212.134.128.34])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA14209
	for <saag@mit.edu>; Thu, 13 Dec 2001 06:29:02 -0500 (EST)
Received: from hyena.skygate.co.uk ([10.0.0.2])
	by lion.skygate.co.uk with esmtp (Exim 3.33 #1)
	id 16ETzq-00087C-00; Thu, 13 Dec 2001 11:25:50 +0000
Received: from localhost ([127.0.0.1])
	by hyena.skygate.co.uk with esmtp (Exim 3.33 #1)
	id 16ETzo-0001LN-00; Thu, 13 Dec 2001 11:25:48 +0000
Subject: Re: [saag] Responsible Vulnerability Disclosure Process
From: Pete Chown <Pete.Chown@skygate.co.uk>
To: "Steven M. Christey" <coley@linus.mitre.org>
Cc: saag@mit.edu, cwysopal@atstake.com
In-Reply-To: <200112130906.EAA24120@linus.mitre.org>
References: <200112130906.EAA24120@linus.mitre.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 13 Dec 2001 11:25:48 +0000
Message-Id: <1008242748.3349.1.camel@hyena.skygate.co.uk>
Mime-Version: 1.0
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

I've just had a look through the draft, and in general terms I agree
with the aims.  I think setting out the expectations of the "security
community" is valuable, and I think that what is described is broadly
fair.

Here are some comments:

I think the document is too long.  I take the document to be saying that
vendors get thirty days, plus such extensions as they can negotiate with
the reporters.  Of course there is a bit more detail than that, but it
shouldn't take thirty pages...  The longer the document is, the less
people will read it.

What status is it going for?  Presumably Informational or BCP.  In this
case I believe the requirements language -- the capitalised MUST,
SHOULD, and so on -- is out of place.  This language is used to describe
compliance of software with a technical specification, not compliance of
people with a standard of conduct.  (This is related to my first point;
I think the document is made unnecessarily complicated by attempting to
be too precise or legalistic about what people are supposed to do.)

I feel the general security advice should be removed (for example 3.1
paragraph 2).  This advice is valuable but it is rather off the main
topic of this document.

-- 
Pete


From owner-saag@MIT.EDU  Thu Dec 13 11:36:48 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA09548
	for <saag@jis.mit.edu>; Thu, 13 Dec 2001 11:36:48 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18874
	for <saag@mit.edu>; Thu, 13 Dec 2001 11:36:48 -0500 (EST)
Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id LAA23183
	Thu, 13 Dec 2001 11:26:52 -0500 (EST)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30])
	by mail-blue.research.att.com (Postfix) with ESMTP id 17E924CEE2
	for <saag@lists.tislabs.com>; Thu, 13 Dec 2001 11:36:47 -0500 (EST)
Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10])
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA08788
	for <saag@lists.tislabs.com>; Thu, 13 Dec 2001 11:33:55 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id A8DAD7B55
	for <saag@lists.tislabs.com>; Thu, 13 Dec 2001 09:36:40 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: Steve Bellovin <smb@research.att.com>
To: saag@lists.tislabs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 13 Dec 2001 09:36:40 -0700
Message-Id: <20011213163640.A8DAD7B55@berkshire.research.att.com>
Subject: [saag] Announcement of NIST Modes Recommendation (fwd)
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

------- Forwarded Message

Message-Id: <5.1.0.14.2.20011213101514.00a9f628@email.nist.gov>
X-Sender: dworkin@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 13 Dec 2001 10:19:03 -0500
To: dworkin@nist.gov
From: Morris Dworkin <dworkin@nist.gov>
Subject: Announcement of NIST Modes Recommendation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-UIDL: 994f7d3e5e05269c60b4138aea5cd08a

Now that the AES FIPS has been approved, here is an update from NIST on 
modes of operation.

The NIST special publication SP 800-38A, "Recommendation for Block Cipher 
Modes of Operation," is available online, at 
http://csrc.nist.gov/publications/nistpubs/index.html.   Five 
confidentiality modes are specified for use with any FIPS-approved block 
cipher, such as the AES. The modes in SP 800-38A are updated versions of 
the ECB, CBC, CFB, and OFB modes that are specified in FIPS Pub. 81; in 
addition, SP 800-38A specifies the CTR mode.

NIST also expects to publish a 2002 edition of SP 800-38A in which the 
domain of the CBC mode is extended (to include plaintexts whose bit lengths 
are not a multiple of the block size); all of the technical material that 
is specified in the 2001 edition is expected to remain valid.

The next document in the series, SP 800-38B, will specify a variant of the 
CBC-MAC authentication mode.

Modes development is expected be an ongoing effort; later parts of the 
series may be devoted to the specification of new modes.

Regards,

Morris Dworkin



------- End of Forwarded Message



		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com



From rgm-sec@htt-consult.com  Thu Dec 13 11:37:01 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA09555
	for <saag@jis.mit.edu>; Thu, 13 Dec 2001 11:37:01 -0500 (EST)
Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id LAA18958
	for <saag@mit.edu>; Thu, 13 Dec 2001 11:37:00 -0500 (EST)
Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Thu, 13 Dec 2001 11:37:01 -0500
Message-Id: <5.1.0.14.2.20011213113602.01edeaa0@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 13 Dec 2001 11:36:37 -0700
To: saag@mit.edu
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [saag] FWD: Announcement of NIST Modes Recommendation
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Date: Thu, 13 Dec 2001 10:19:03 -0500
To: dworkin@nist.gov
From: Morris Dworkin <dworkin@nist.gov>
Subject: Announcement of NIST Modes Recommendation
:
:

Now that the AES FIPS has been approved, here is an update from NIST on 
modes of operation.

The NIST special publication SP 800-38A, "Recommendation for Block Cipher 
Modes of Operation," is available online, at 
http://csrc.nist.gov/publications/nistpubs/index.html.   Five 
confidentiality modes are specified for use with any FIPS-approved block 
cipher, such as the AES. The modes in SP 800-38A are updated versions of 
the ECB, CBC, CFB, and OFB modes that are specified in FIPS Pub. 81; in 
addition, SP 800-38A specifies the CTR mode.

NIST also expects to publish a 2002 edition of SP 800-38A in which the 
domain of the CBC mode is extended (to include plaintexts whose bit lengths 
are not a multiple of the block size); all of the technical material that 
is specified in the 2001 edition is expected to remain valid.

The next document in the series, SP 800-38B, will specify a variant of the 
CBC-MAC authentication mode.

Modes development is expected be an ongoing effort; later parts of the 
series may be devoted to the specification of new modes.

Regards,

Morris Dworkin

Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com


From mcgrew@cisco.com  Thu Dec 13 13:05:38 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA10177
	for <saag@jis.mit.edu>; Thu, 13 Dec 2001 13:05:38 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA29002
	for <saag@mit.edu>; Thu, 13 Dec 2001 13:05:38 -0500 (EST)
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBDI5bp05457
	for <saag@mit.edu>; Thu, 13 Dec 2001 10:05:37 -0800 (PST)
Received: from MCGREWW2K (sjc-vpn3-192.cisco.com [10.21.64.192])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AAL07961;
	Thu, 13 Dec 2001 10:01:11 -0800 (PST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: <saag@mit.edu>
Date: Thu, 13 Dec 2001 10:12:30 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFKEHGCCAA.mcgrew@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [saag] Announcement of NIST Modes Recommendation and draft-mcgrew-saag-icm-00.txt
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

Hello,

below is the announcement from Morris Dworkin of NIST about the NIST
publication describing approved modes of operation of block ciphers and
providing test vectors.  Counter mode is included, and the definition of
that mode is open-ended in that the counter generation function is not
specified.  The inclusiveness of that definition is a good thing; however,
it can't be used make interoperable implementations.  Appendix B of that
document recommends a particular technique (Section B.1, The Standard
Incrementing Function), though it does not address all of the details.

The recent individual submission draft-mcgrew-saag-icm-00.txt specifies a
counter mode variant that is appropriate for packet encryption.
Fortunately, that draft is consistent with Appendix B of Morris' document.
The definition in that draft is also adopted in draft-ietf-avt-srtp-02.txt,
the latest version of the Secure RTP draft.  Other packet encryption
applications, such as IPsec ESP, can also use the method described in that
draft.

There is one security issue to which I'd like to call attention: the need
for a random offset, as used in draft-mcgrew-saag-icm-00.txt.  This
mechanism protects against attacks like Hellman's time-memory tradeoff and
the key collision attack.  Without it, counter mode with an 128 bit block
cipher can be broken with a work factor of much less than 2^128 (2^82 for
the TMTO, and as low as 2^64 for KC).  Recent theoretical work shows the
benefits of counter mode over other block cipher modes, but it is important
to realize that the attacks mentioned above would work even if the block
cipher were ideal.

David
mcgrew@cisco.com

> -----Original Message-----
> From: Morris Dworkin [mailto:dworkin@nist.gov]
> Sent: Thursday, December 13, 2001 7:19 AM
> To: dworkin@nist.gov
> Subject: Announcement of NIST Modes Recommendation
>
>
> Now that the AES FIPS has been approved, here is an update from NIST on
> modes of operation.
>
> The NIST special publication SP 800-38A, "Recommendation for Block Cipher
> Modes of Operation," is available online, at
> http://csrc.nist.gov/publications/nistpubs/index.html.   Five
> confidentiality modes are specified for use with any FIPS-approved block
> cipher, such as the AES. The modes in SP 800-38A are updated versions of
> the ECB, CBC, CFB, and OFB modes that are specified in FIPS Pub. 81; in
> addition, SP 800-38A specifies the CTR mode.
>
> NIST also expects to publish a 2002 edition of SP 800-38A in which the
> domain of the CBC mode is extended (to include plaintexts whose
> bit lengths
> are not a multiple of the block size); all of the technical material that
> is specified in the 2001 edition is expected to remain valid.
>
> The next document in the series, SP 800-38B, will specify a
> variant of the
> CBC-MAC authentication mode.
>
> Modes development is expected be an ongoing effort; later parts of the
> series may be devoted to the specification of new modes.
>
> Regards,
>
> Morris Dworkin
>


From owner-saag@MIT.EDU  Thu Dec 20 16:33:32 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA08612
	for <saag@jis.mit.edu>; Thu, 20 Dec 2001 16:33:31 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06427
	for <saag@mit.edu>; Thu, 20 Dec 2001 16:33:31 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id QAA18627
	Thu, 20 Dec 2001 16:23:26 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21261;
	Thu, 20 Dec 2001 16:33:26 -0500 (EST)
Message-Id: <200112202133.QAA21261@ietf.org>
To: IETF-Announce: ;
Cc: saag@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Thu, 20 Dec 2001 16:33:26 -0500
Subject: [saag] Last Call: Encryption and Security Requirements for IETF
 Standard Protocols to BCP
Sender: saag-admin@mit.edu
Errors-To: saag-admin@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag/>

The IESG has received a request from the Open Security Area Directorate
to consider Encryption and Security Requirements for IETF Standard
Protocols <draft-ietf-saag-whyenc-00.txt> as a BCP.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by January 20, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt


