From nobody Mon Apr 11 08:38:12 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27D3A09B7; Mon, 11 Apr 2022 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dudD-RgWMD5l; Mon, 11 Apr 2022 08:37:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4828D3A0FE2; Mon, 11 Apr 2022 08:37:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 83D4038C3C; Mon, 11 Apr 2022 11:49:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sw8hvGqwY5yR; Mon, 11 Apr 2022 11:49:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F1CE38C27; Mon, 11 Apr 2022 11:49:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649692160; bh=C6JYezNT1qyyXdl/X+70PXPdxEUeP42AY+HRTQIzIII=; h=From:To:Subject:Date:From; b=8F0TMyivGtY5izxXixK+ZgsMrGp/FXtRf+W1x/zAAV+SIk5orSiNcgJ4FPIEYag8C teIlsDjI6q035vFYqwbdAexh1jkogWpEurSQy/H8c8uXnVlG67aisnTUHPUI9AFM4p 6Lbud1rykblstkyqm+9epnyNRdVRotS4qHov+aY/TucwKpIr5LMJ/nZeJs6wzLH0il g2znib1okeSb0lnQZmMON5nvryCqV/GoxK57WSV/5DvIaT8kgIc/93vPFcJSjMgJaZ 50NrBYm6f8hyi7TmvJEfVKWRGonqW8PId3Q7Qhgfn7WuylwBNp6x/U+0vvPRBTlCEg q1KANyTXE0vZA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60D29A7; Mon, 11 Apr 2022 11:37:49 -0400 (EDT) From: Michael Richardson To: dnsop@ietf.org, mud@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] looking for reference for reverse maps do not work X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:38:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, in reviews of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerati= ons-04.html I was asked to expand upon why the reverse map can not be intelligently use= d=20=20 for MUD ACLs. (section 3, XXX stuff) (MUD controllers, upon being presented with ACLs made up of names need to do forward lookups of the names and build ACLs based upon the IP addresses.) There are two aspects of this: 1) even in an ideal situation, it takes too long on the first packet to extract a name from an IP address. Yes, that could be aggresively cac= hed. 2) forward:reverse maps are N:M mappings, often with unidirectional parts= , and often broken or not delegated. =20=20=20=20=20 Further, there is no authorization of the mappings, so an attacker who wants to be able to reach IP address 2001:db8::abcd, can insert a reverse name of their choice, including updates.example.com, which is permitted by the MUD ACL. While I can write the above paragraph, I don't feel that it's detailed enou= gh for what is needed, and I feel that we (the IETF) must have documented the security issues with reverse/forward mismatched at least twice over the past 40 years. I'm looking for a good well reviewed reference to use rather than repeating this again. =2D-=20 Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUS00WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZds5B/4mtGf3HeCwsNYMjd77ieEwJZR+ lffP/2xEfyj1VA9ou/a5hGssBKQQSob4zjOfLbW3iiTt9jexq0Qg/I/VsIpORUud o/fFOcKxdPjnMLSwuPyEJ47XY5XERovDYmiu9OUjyLeyfFdtzJcSqt649VUUrtnL rqQ6a0xXQlCx4sPfDtgygL1kwMGNBPWkRRlhUNFojB2HMpotrZuuzcOf839daaxV EED2m33gRxkfQx8KxDjytyTl+ZtmeXjX5rx7+IsHbw3bfF7KghY2kqtAwiD1RLvW nz0Ds+jtCD/D5EghwESYh3ZyijHsZY3edPJ0tFEQHkar9KBnVYhr7tJ8TMcc =I9iN -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 11 08:45:59 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721FC3A112A; Mon, 11 Apr 2022 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Oqveamdw; dkim=pass (1024-bit key) header.d=yitter.info header.b=ci2nyVW1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhOnGaKn_Bzu; Mon, 11 Apr 2022 08:45:47 -0700 (PDT) Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D372E3A1122; Mon, 11 Apr 2022 08:45:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 92958BD5C5; Mon, 11 Apr 2022 15:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1649691943; bh=Nh43tYT1UxS2UWkzutCDJJRkJ6h0P2/en/DUkunrLuM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=Oqveamdw7YqK0rpwlZWh7uZKQNGq+/DMZq41UANRw/1j8jnyxVugvSzPOucssuTSK 86rcxVL/Cew2dLX/gCszBe3Dqgo1/mKNes9lD9bu4OwgTCo9Sgq9Ua4l04luV2wzFx yl2qowdAiS0c2j0YlQt9dw7q89T/voesUAX4rxww= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4uScjukLMiG; Mon, 11 Apr 2022 15:45:41 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1649691941; bh=Nh43tYT1UxS2UWkzutCDJJRkJ6h0P2/en/DUkunrLuM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=ci2nyVW1Q9H79yuZV1pDNZotPInsXt9L3SpOOICFz0PDgaNcax8erlSH5nSgPmEsA N0ZMn69OdrFvaUCQgaLHSzhYaKa1K3UD3m5dsV+Lbg41iYKOMlPrvMuUixE37cX0gX MMU+5wukJPkHqiv4S2UNq/L92QgE9v8U/zhwgbYg= Content-Transfer-Encoding: 7bit From: Andrew Sullivan Mime-Version: 1.0 (1.0) Date: Mon, 11 Apr 2022 11:45:39 -0400 Message-Id: <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> References: <24231.1649691469@localhost> Cc: dnsop@ietf.org, mud@ietf.org In-Reply-To: <24231.1649691469@localhost> To: Michael Richardson Archived-At: Subject: Re: [Mud] [DNSOP] looking for reference for reverse maps do not work X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:45:52 -0000 --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to document this ages ago in https://datatracker.ietf.org/doc/draft-= ietf-dnsop-reverse-mapping-considerations/, and got so many contradictory ed= its (see the history) that the final version ended up saying =E2=80=9CA or m= aybe not-A, or maybe both, your choice,=E2=80=9D so the then-chairs decided t= he document wasn=E2=80=99t worth sending through publication.=20 A =E2=80=94=20 Andrew Sullivan=20 Please excuse my clumbsy thums > On Apr 11, 2022, at 11:38, Michael Richardson wrot= e: >=20 > =EF=BB=BF > Hi, in reviews of > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerati= ons-04.html >=20 > I was asked to expand upon why the reverse map can not be intelligently us= ed =20 > for MUD ACLs. (section 3, XXX stuff) > (MUD controllers, upon being presented with ACLs made up of > names need to do forward lookups of the names and build ACLs based upon th= e > IP addresses.) >=20 > There are two aspects of this: > 1) even in an ideal situation, it takes too long on the first packet to > extract a name from an IP address. Yes, that could be aggresively cac= hed. >=20 > 2) forward:reverse maps are N:M mappings, often with unidirectional parts= , and often > broken or not delegated. >=20 > Further, there is no authorization of the mappings, so an attacker who= > wants to be able to reach IP address 2001:db8::abcd, can insert a > reverse name of their choice, including updates.example.com, which is > permitted by the MUD ACL. >=20 > While I can write the above paragraph, I don't feel that it's detailed eno= ugh > for what is needed, and I feel that we (the IETF) must have documented the= > security issues with reverse/forward mismatched at least twice over the pa= st > 40 years. >=20 > I'm looking for a good well reviewed reference to use rather than repeatin= g > this again. >=20 > --=20 > Michael Richardson . o O ( IPv6 I=C3=B8T consult= ing ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Transfer-Encoding: 7bit --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to document this ages ago in <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-= considerations/">https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-m= apping-considerations/, and got so many contradictory edits (see the his= tory) that the final version ended up saying =E2=80=9CA or maybe not-A, or m= aybe both, your choice,=E2=80=9D so the then-chairs decided the document was= n=E2=80=99t worth sending through publication. 

A
=E2=80=94 
Andrew Sullivan 
Pl= ease excuse my clumbsy thums

On Apr 11, 2022, at 11:38, Michael Richardson <mcr+ietf@sandel= man.ca> wrote:

=EF=BB=BF
Hi, in reviews of
 https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-consid= erations-04.html

I was asked to expand upon= why the reverse map can not be intelligently used  
fo= r MUD ACLs. (section 3, XXX stuff)
(MUD controllers, upon be= ing presented with ACLs made up of
names need to do forward l= ookups of the names and build ACLs based upon the
IP address= es.)

There are two aspects of this:<= br>  1) even in an ideal situation, it takes too long on the firs= t packet to
    extract a name from an I= P address.  Yes, that could be aggresively cached.

 2) forward:reverse maps are N:M mappings, often with uni= directional parts, and often
    broken= or not delegated.

    = ;Further, there is no authorization of the mappings, so an attacker who
    wants to be able to reach IP address 20= 01:db8::abcd, can insert a
    reverse n= ame of their choice, including updates.example.com, which is
    permitted by the MUD ACL.
<= br>While I can write the above paragraph, I don't feel that it's detai= led enough
for what is needed, and I feel that we (the IETF)= must have documented the
security issues with reverse/forwa= rd mismatched at least twice over the past
40 years.<= br>
I'm looking for a good well reviewed reference to u= se rather than repeating
this again.
=
--
Michael Richardson <mcr+IETF@sandelman.ca&g= t;   . o O ( IPv6 I=C3=B8T consulting )
 &nb= sp;        Sandelman Software Works I= nc, Ottawa and Worldwide
___________________________________= ____________
DNSOP mailing list
DNSOP@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnsop
= --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Type: application/octet-stream; name=signature.asc; x-apple-part-url=1D73C416-64BA-4E16-A239-6ACCB655700F Content-Disposition: attachment; filename=signature.asc Content-Transfer-Encoding: 7bit Content-Id: <1D73C416-64BA-4E16-A239-6ACCB655700F> -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUS00WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZds5B/4mtGf3HeCwsNYMjd77ieEwJZR+ lffP/2xEfyj1VA9ou/a5hGssBKQQSob4zjOfLbW3iiTt9jexq0Qg/I/VsIpORUud o/fFOcKxdPjnMLSwuPyEJ47XY5XERovDYmiu9OUjyLeyfFdtzJcSqt649VUUrtnL rqQ6a0xXQlCx4sPfDtgygL1kwMGNBPWkRRlhUNFojB2HMpotrZuuzcOf839daaxV EED2m33gRxkfQx8KxDjytyTl+ZtmeXjX5rx7+IsHbw3bfF7KghY2kqtAwiD1RLvW nz0Ds+jtCD/D5EghwESYh3ZyijHsZY3edPJ0tFEQHkar9KBnVYhr7tJ8TMcc =I9iN -----END PGP SIGNATURE----- --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587-- --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6-- From nobody Mon Apr 11 10:37:58 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069083A09EB; Mon, 11 Apr 2022 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vkfnYLmbLLD; Mon, 11 Apr 2022 10:37:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431A33A099D; Mon, 11 Apr 2022 10:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0AB9D38C03; Mon, 11 Apr 2022 13:48:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3xOTkk4AzsE4; Mon, 11 Apr 2022 13:48:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9AA0538BDC; Mon, 11 Apr 2022 13:48:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649699329; bh=riXWPdkWrG8cp0AcvFbzHrImVVOLEo674lIlzGUnLg4=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=OLQJB64OR0iXVgo7A9Yr+nqIcgYk9gAkFcZHCoCDHOewcZ3rwKhOwEYZOQ5PTQjO5 ocCJ4+YEHZeTKIMr9UPFIr021AeeMzuhpt48j033FVRBLSBSmi+5XxEMMMAmxIVBEf BQTPrbCoaRn6h8Aw3TaNV2NppPrE0X6EW67CxiMRD3ozKm/XhVPU7BKibTnB0pnWzw 731flXvPXPGs6DEpMZP9QdM5eUGD8IA0ymUKscIMWxuc5Oky6FE31oBVKe6zqTrnZ6 eKUEX3AsDnSlvreZaX8+ELdVHYSO1P/V57/jnIRBj4a4G8qZrOC7lksIKommlFivwu yLbhIO9T1aayQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D2553F; Mon, 11 Apr 2022 13:37:18 -0400 (EDT) From: Michael Richardson To: Andrew Sullivan cc: dnsop@ietf.org, mud@ietf.org In-Reply-To: <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> References: <24231.1649691469@localhost> <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mud] [DNSOP] looking for reference for reverse maps do not work X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 17:37:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andrew Sullivan wrote: > I tried to document this ages ago in > https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-con= siderations/, > and got so many contradictory edits (see the history) that the final > version ended up saying =E2=80=9CA or maybe not-A, or maybe both, you= r choice,=E2=80=9D > so the then-chairs decided the document wasn=E2=80=99t worth sending = through > publication. Oh. That's why I don't want to attempt writing this myself. So, that's not encouraging. =2D-=20 Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUZ04WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZTtvB/98FdfSaxP5k6Dt1RJnjnEn9V// 9KnV1xiQIlXPvIRN0Y4gvXP0yzzhYc/QIsHn+1XDAvfI3rDPR7PZktKeinL5/D0m 8CmvOosx7J4TY9QNeOE6Z6RpSX+EVmiydoqVl7s8m3Ip1S4X1FJZFpSBAxfFBV3T xfqbZ/EZT01NlF8G21VVPjEWT+htj3iZDSds6l+kKwd546UJQU5RjXCv4JsLRHYW YCeRj2jwGTSer6BHKYtaH+yc+2cuzUlTYNgx5h1/d3+16JQFtENzWwsYYsPHX2c+ UDwYkd/rQOAIIt2y4uuZmRf07zppmpt9bp4S320V2ijqO1WKdapPivPf5Xyz =t4BT -----END PGP SIGNATURE----- --=-=-=--