From nobody Mon Apr 1 07:04:39 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE18312014C for ; Mon, 1 Apr 2019 07:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cRIA-DtpcKUp for ; Mon, 1 Apr 2019 07:04:36 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D3D120147 for ; Mon, 1 Apr 2019 07:04:36 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id n25so11609745wmk.4 for ; Mon, 01 Apr 2019 07:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=6cWNTjaarpR5oB1rZU1FI9lMq9gKG3n/T+9wrlNo0Mw=; b=pwJpujoCUDAVEX55vN2aWU7nZR9lGixNU9JuaTfYYx3P48rv98HV0Kh5moyXBswLYA 7RwEKQQkqg8GKdL/T2OgDO0pfM4aHsdfENkicpahzmqGjCZtB8c7eV31Qu9pKFbi+bPj igHqO7mVOI/6Zpc1dGmesXUqHLznvMg/uz6MpVa+Ga0FnVInAZKpbe4saUqAjxVl5TlC JL/hqLWqrDkz+B/NPsYrpUVE5uiSSeY5D1E1Y+x2FO04Mc7doQRhk/nUpoZ5iX2GbIJ2 7PLUzNiyx7Z6hAwQK5xJIF/J/2JnhXSjxSOvey0lrssOJD19kF4BmexehAoDXu2XjqQA ZPNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=6cWNTjaarpR5oB1rZU1FI9lMq9gKG3n/T+9wrlNo0Mw=; b=grxedgobv68NhfAAQbkViRHBqbGqXo8n/NSykHAWOwIqPRT2mWBuiNLj/8G0aI/IGf EcPFOlqrQixpZizi4ziSvqrGuyL9q3cA8Tv82y2EIU/uBeDQZtEWf4Uz4s9Ge3oY/vRa g2+6c2ivdgZO4iBKh3NMV7D33EUPNuYoNYjdsqC1waTRvWuiDn746/2bNqqcx+41d3mW E21QCM3IwGK2LYQffLlCLlPx2ByKD2QwmLNcql3N2RNCmgK9st78mzfmtRjaPR2zDnhT 0iaFrjUFkUFtrE6kGePU08uYPyPwkT+90orDXkNWFo8owtl3H5DcnCzVsNlTB2sViuQr 3r9g== X-Gm-Message-State: APjAAAX3RRZJ/gx1kZh1I3upSFOzqRnmppSSMTGeqAt9ySQqeotEcrnW EjcBxqicVhE3AdJVyvQLOVenxj8+ X-Google-Smtp-Source: APXvYqyK8QrvXNq1yGYP071bTUEYsH1y0IsCCZpa5HKPQL8MJrPgay2swL3Sv5Hek/ClugbayOJB9w== X-Received: by 2002:a7b:c111:: with SMTP id w17mr13231510wmi.6.1554127474519; Mon, 01 Apr 2019 07:04:34 -0700 (PDT) Received: from localhost (port-92-193-8-174.dynamic.qsc.de. [92.193.8.174]) by smtp.gmail.com with ESMTPSA id c6sm11685170wmb.21.2019.04.01.07.04.33 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 01 Apr 2019 07:04:33 -0700 (PDT) From: Justus Winter To: openpgp@ietf.org Date: Mon, 01 Apr 2019 16:04:32 +0200 Message-ID: <871s2l4ya7.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Additional (En|De)cryption Subkey X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 14:04:38 -0000 --=-=-= Content-Type: text/plain Hello, I noticed a new key flag appearing in RFC4880bis-05, the ADSK flag. However, I am struggling with the meaning and how it is envisioned to be used. The Information in the RFC is scarce, and the corresponding commit message merely says "Define an Additional Encryption Subkey flag". % grep ADSK draft-ietf-openpgp-rfc4880bis-06.txt 0x04 - This key may be used as an additional decryption subkey (ADSK). The ADSK flag helps to figure out an encryption subkey. Would you be so kind to clarify this part of the RFC? Thanks, Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyiGnAACgkQiNx+Mzhf eR0+KAf/ZG8OBUlXB7yflce+z0zBj1U9AuR+i+BslJof/3dKyPUwI5qX4w1fN2UO Io/671XtTxkr9H3nu9bfAxklSl41Yhnq6XQncTE4iumaypW6/iLtkQmhiKvQGGNT +4gzs8H3oosXivy4WecHpVgu3mvzyKKzXrGSsyfJQJLmRTB/ZwfkGVyjmzsNbt1M g3PEuHHYDxlTcqXMOT4X9JrV1XL9Nt7jgz98Lh8U1d8vpEpxHUalBKt2bJhIzAZ0 y7WG4oQjMAI/notWngXhiSQStTrT6C4OtIiRq+nXjWdaYt1JC28bNTSsOZ3vrPwH DbfogXA4JjXUJoCK76NHXUWcx3aWrA== =D6UW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 1 09:10:41 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07D31202CB for ; Mon, 1 Apr 2019 09:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 XPz5LGxjLfdS for ; Mon, 1 Apr 2019 09:10:39 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE20A1202D3 for ; Mon, 1 Apr 2019 09:10:38 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x31GANqt031972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 1 Apr 2019 12:10:26 -0400 Date: Mon, 1 Apr 2019 11:10:23 -0500 From: Benjamin Kaduk To: "Neal H. Walfield" Cc: Bart Butler , "openpgp@ietf.org" , Peter Gutmann , Justus Winter , Jon Callas , Jon Callas Message-ID: <20190401161023.GG84783@kduck.mit.edu> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <20190330150438.GS35679@kduck.mit.edu> <87k1gg12rl.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k1gg12rl.wl-neal@walfield.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 16:10:40 -0000 On Sat, Mar 30, 2019 at 10:16:46PM +0100, Neal H. Walfield wrote: > Hi Ben, > > Thanks for your note. > > At Sat, 30 Mar 2019 10:04:38 -0500, > Benjamin Kaduk wrote: > > I also have a use case for authentication of large chunks of data at rest: > > they allow me to use a cheap bulk storage service that provides > > (best-effort) replication and archiving but has poor physical security. So > > I encrypt my data to myself and put it in storage, but when I get it back > > I need to know that it's valid. I can imagine at least one case where > > knowing exactly which chunk was corrupted would save effort; it may be a > > toy example but perhaps it is illustrative of a broader case. Note that > > there are algorithms to compute pi to arbitrary precision, and even to > > compute the Nth digit thereof without coputing the previous digits. If I > > need to have random-access inquiries into the value of pi, I could > > precompute using softare I trust and do this self-encryption thing, and > > when a chunk is bad I can recompute only that chunk and still trust that I > > only ever use values generated by my trusted implementation. > > Just to be clear: when you say "large chunks of data at rest," you're > not arguing that large AEAD chunks are better, are you? It seems to > me that if you use small chunks, at least in your example, you have > less work to do when you discover a corrupted chunk. Thanks for spotting that; my "large chunks of data at rest" was meant to just be large quantities of data (e.g., TB or more), with no relationship to the chunk size used in the encryption thereof. -Ben From nobody Mon Apr 1 18:46:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0546412006E for ; Mon, 1 Apr 2019 18:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, L_8BIT_MISMATCH=0.01, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 Rya7mFgzmlow for ; Mon, 1 Apr 2019 18:46:45 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639C4120021 for ; Mon, 1 Apr 2019 18:46:45 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 492FD20E40 for ; Tue, 2 Apr 2019 01:46:44 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=IZjlIxowoeVgyS+eRafKXVSQ7kgJMl1ygp80FBaJVTw=; b=W1OmvM4dhmic/yLl7yap/JVtV5aZ3xLvCSAfIHmVbI9mAxTwJCO6ng0zW1vCd/WXQXlZRlse9aua+XZdlL4BPG+ESCSeWW9A6WmqU3Hx0cNCMofG8jhgWM2Wi4CfVEqws8GQ9CK3mJkqRbTtj80geeYKSRXk+oNioHwAe8MKDRhRcB3fKn7pzRJEdC/3+RGb978i/0geQALmcVAlfS5v6IIuKvp8dkBJeF132bH74dHnDC9XiwjgR3pMA9+blSj35P09LaId3f307jq5ibs9J4quJKzzTwrw/SCLhVtnGRqkdglpmTYbeSrWDmbibofIkZoeT7RDfCvOrwkSKaIWAw== Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Tue, 2 Apr 2019 01:46:43 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 96606406B6; Tue, 2 Apr 2019 01:46:43 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 01 Apr 2019 21:46:43 -0400 To: "Daniel Kahn Gillmor" , "openpgp" From: vedaal@nym.hush.com In-Reply-To: <87k1gebu9o.fsf@fifthhorseman.net> References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> <87k1gebu9o.fsf@fifthhorseman.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20190402014643.96606406B6@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 01:46:47 -0000 On 4/1/2019 at 12:03 AM, "Daniel Kahn Gillmor" wrote: > >On Sun 2019-03-31 13:10:24 +0100, Damien Goutte-Gattat wrote: >> * Is there any interest for a “more modern” S2K, or is the >> Iterated+Salted S2K still considered fine enough for >RFC4880bis? > >I think having argon2i included in rfc4880bis would be concretely >useful; iterated+salted hasn't been the best practice for S2K for >well >over a decade. > >The main argument i can imagine against it is if no OpenPGP >implementation has any plans or desire to implement it, or if >there are >specific objections related to IPR. ===== Will the new S2K be only for the V5 key format? Or will it also be used for Conventionally Encrypted messages? If it will be used for Conventionally Encrypted messages too, then there can be backward incompatibility issues, as well as intercompatibility issues with different implementations. (I still think it's a good idea, but may be a really lot of extra work, so maybe only for V5 keys now). vedaal From nobody Mon Apr 1 20:32:09 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8F51200D7 for ; Mon, 1 Apr 2019 20:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 RYm-zlejlXkC for ; Mon, 1 Apr 2019 20:32:06 -0700 (PDT) Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1573712001E for ; Mon, 1 Apr 2019 20:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1554175925; bh=RvA4Zpv8cA7XQiFR+DeAHd61tBk86q2O5Odxc4Rel+4=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=SACXe8KcEqKEhxWMmwNlfs4ATNPkzXvJeARibejlzOUu8eL2MZJg3wwZxeQzdH3Hw CcvjQBT/xl/ICYPxfA9uGcw37gAsxamJe96N7nBOAL5N3cmF78LTXa7y1Lp8q02fgp RdoR9lUbEGOaBExblQ17Mkx9L81U/hnKnxA2dScB2P9O2vVHVAhp3/+q4aGolWRAsx 8Xn+on7x74I8dWiYjdzleCwZHOPzKIiH8rNxQPhCn4W2Sa9Rq+XDhA/GGkSOBeIcAQ S3aAzUnF1EYIIi2bqv4s9OvxND0qWx3C3yqn2I9m2rO7YIG64YFuQJgZwcpvl4uscH JRO9Ihn6e0n4A== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06021801.me.com (Postfix) with ESMTPSA id 10CD3180057; Tue, 2 Apr 2019 03:32:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> Date: Mon, 1 Apr 2019 20:32:04 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> To: Damien Goutte-Gattat X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-02_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904020024 Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 03:32:08 -0000 >=20 > * Is there any interest for a =E2=80=9Cmore modern=E2=80=9D S2K, or is = the > Iterated+Salted S2K still considered fine enough for RFC4880bis? I=E2=80=99d love to see it modernized. I despise the present S2K = function. I recognize that most of my reaction is not entirely rational, = but I still despise it. I know that what I despise about it is the stupid one-byte floating = point number for the =E2=80=9Ccount=E2=80=9D and the fact that the count = is a number of bytes generated, which means that it has massively = different characteristics if you change the hash function.=20 (Consider the same count with SHA256 and SHA512. Since it is a byte = count, you end up with half the number of iterations of SHA512 as = SHA256, and on a 64-bit CPU, they run at more or less the same speed = with SHA512 often marginally faster. This is completely = counter-intuitive.) =46rom a security standpoint, though, there=E2=80=99s no real advantage = to PBKDF2, even if it=E2=80=99s better architected. So all in all, as much as I=E2=80=99d like to do something, keeping the = existing one is good enough. >=20 > * If we want a more modern S2K, then is Argon2i the right choice? I view this as primarily an implementation issue. If I were to write that section, I=E2=80=99d put both Argon2i and = Argon2d in. There are reasons to go with either, and I=E2=80=99d leave = that to the implementation. Interoperability matters only when you transfer keys from one = implementation to another, and as time goes on that is less and less of = a problem. (And the grumpy part of me says that if you=E2=80=99re going = to transfer to some new implementation, maybe you want a new key, anyway = even as I know that=E2=80=99s not friendly.) I believe it=E2=80=99s important also to have something that is merely a = spin loop, like the present iterated+salted or PBKDF2. Jon From nobody Mon Apr 1 20:34:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE631200F6 for ; Mon, 1 Apr 2019 20:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 PTQg_O-FvqYM for ; Mon, 1 Apr 2019 20:34:46 -0700 (PDT) Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC61C1200D7 for ; Mon, 1 Apr 2019 20:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1554176085; bh=JWKEnucjYmJVr42kBy0h9u5iVetIVVJ3hfCt4F23tNQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=d1vnl7voF19Rpa3XcRwH+3znIuhtBZPD5HKRcrtWou1lmN6CWeb6KdXA6ZsRUWkt8 GrSgu2YSt4LTy2aV2ooiRnFkxDaiwjM3FrzJt5CZbCiogJLgj21ta27UYO8yvzyNOI 53Sl1HyXIIRBPBerTzkoS2bGkMBGT9vEPIv1oxW81mrMkVTN2qccm492PYJ/ldsFDP 2O7057VEoB3pQm5w3zFu6Q8mQ2B7B/rAz2SBmuPDiV28Fq3B1mB8fx8ekxwcBzwY9Y Qxq2qhEkZakBpbalJca4vTJUougFX45+RHFjk1HV/MzeSZ1JUCyBh11OXdOeQpALI3 aCZtZACeQYi6A== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06021801.me.com (Postfix) with ESMTPSA id BCD93180149; Tue, 2 Apr 2019 03:34:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <20190402014643.96606406B6@smtp.hushmail.com> Date: Mon, 1 Apr 2019 20:34:44 -0700 Cc: Jon Callas , Daniel Kahn Gillmor , openpgp Content-Transfer-Encoding: quoted-printable Message-Id: <05B2C0AA-E6EF-4C6A-BE17-A2814AFBF2C5@icloud.com> References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> <87k1gebu9o.fsf@fifthhorseman.net> <20190402014643.96606406B6@smtp.hushmail.com> To: vedaal@nym.hush.com X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-02_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=524 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904020024 Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 03:34:48 -0000 > On Apr 1, 2019, at 6:46 PM, vedaal@nym.hush.com wrote: >=20 > Will the new S2K be only for the V5 key format? > Or will it also be used for Conventionally Encrypted messages? It would be for any key, or for conventionally encrypted messages. >=20 > If it will be used for Conventionally Encrypted messages too, then = there can be backward incompatibility issues,=20 > as well as intercompatibility issues with different implementations. >=20 > (I still think it's a good idea, but may be a really lot of extra = work, so maybe only for V5 keys now). Remember, definition is not implementation. You=E2=80=99re right that = from an implementation standpoint, it might be best to make messages = default to the old S2K for a while, but do it for V4 and V5 keys as = well. Jon From nobody Mon Apr 1 23:15:20 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD49120058 for ; Mon, 1 Apr 2019 23:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CEWwc9ERtwsf for ; Mon, 1 Apr 2019 23:15:15 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D37712001E for ; Mon, 1 Apr 2019 23:15:14 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hBChM-0001mC-S0; Tue, 02 Apr 2019 06:15:04 +0000 Date: Tue, 02 Apr 2019 08:15:04 +0200 Message-ID: <878swtgcgn.wl-neal@walfield.org> From: "Neal H. Walfield" To: vedaal@nym.hush.com Cc: "Daniel Kahn Gillmor" , "openpgp" In-Reply-To: <20190402014643.96606406B6@smtp.hushmail.com> References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> <87k1gebu9o.fsf@fifthhorseman.net> <20190402014643.96606406B6@smtp.hushmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 06:15:18 -0000 On Tue, 02 Apr 2019 03:46:43 +0200, vedaal@nym.hush.com wrote: > > > > On 4/1/2019 at 12:03 AM, "Daniel Kahn Gillmor" wrote: > > > >On Sun 2019-03-31 13:10:24 +0100, Damien Goutte-Gattat wrote: > >> * Is there any interest for a $B!H(Bmore modern$B!I(B S2K, or is the > >> Iterated+Salted S2K still considered fine enough for > >RFC4880bis? > > > >I think having argon2i included in rfc4880bis would be concretely > >useful; iterated+salted hasn't been the best practice for S2K for > >well > >over a decade. > > > >The main argument i can imagine against it is if no OpenPGP > >implementation has any plans or desire to implement it, or if > >there are > >specific objections related to IPR. > > ===== > > Will the new S2K be only for the V5 key format? > Or will it also be used for Conventionally Encrypted messages? > > If it will be used for Conventionally Encrypted messages too, then there can be backward incompatibility issues, > as well as intercompatibility issues with different implementations. > > (I still think it's a good idea, but may be a really lot of extra work, so maybe only for V5 keys now). s2k is also used for SK-ESKs (symmetric-key encrypted session keys) [1]. When using SK-ESKs, we may not have a key as a reference point. That is, it doesn't make sense to add a restriction of the form: only use argon with v5 keys, as there may not be any keys when we want to use argon! I agree with Jon that the implementations can figure out when to phase it in. That's at least something that we have experience with. [1] https://tools.ietf.org/html/rfc4880#section-5.3 From nobody Tue Apr 2 05:50:30 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420541200FF for ; Tue, 2 Apr 2019 05:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7odZ09i98nan for ; Tue, 2 Apr 2019 05:50:25 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97DF1200FE for ; Tue, 2 Apr 2019 05:50:25 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id u15so289201ybj.13 for ; Tue, 02 Apr 2019 05:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wVu2HuH4s9JU8zvnJQADKlKs0FwPZI0PydfYeJgiSRU=; b=YIxe/ZDF0M6mAHoRcGJNsuOO6Ui53mnrS5Ym4gTcw34RnnKnWzqTSpjj+Q+PBDPoqd eIR03ClkkNWY69ekkETW3jIcbLTJ6a8MoX8pW8z4u/Di64RiULG1EynATIehnHWC58Km tONmXcT9bMK0cs9IKJ4roPFWqFDcREJSGyyC1qT5bGjaJisHhsw3IU1ZRGxCI7JTwazq 2GThuFol7meyXckTg6C41bRYEpOjLU+rKfVtYcWAah8B7q4ohXSgbtA5qD7dLT4klM3W RxrREaoUtejhMjgCnJg2wHopCkdJ/HsjdlhTKA3eptYwT3eCTjjFeVRpGvAtIDbo1QF1 04eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wVu2HuH4s9JU8zvnJQADKlKs0FwPZI0PydfYeJgiSRU=; b=WFZLKyqcokai0Sai5j7/SAYEz6k3Az7J805HMe9mm15I1Rw3kMdbiuuOjuqK8OeY7M 7HrnjMLsn5aZwpHf7Fd+L8wsGOJKsZCE7C4E8uuAQ/Uutq5YNGqc3/zn1DZF3mKu9vFN qbAcupn3XgzA8frpfZTFytXa8OHAtLudcxLIzO2mohsKeyh8JZY1KgAjvkRxFYnQDqRo Vx/6+AEiVVqd74Qd1oKesn7Y4zLXwG6+JI+uCu98zmRD/gNUl5/Znfz3FUDgzSA9RsV5 EjE+kiC69uaqwUoim5bnbKmctmznUBZrkygF7fMrzbYT2EXoNmv86WEsImyMwfTZinfB jasg== X-Gm-Message-State: APjAAAW7Zz+jdkZF59u/hP9UIqZx4JK/ESr43p+xQJm6+NonYzIi1Tqt tBfNGxeqniUVyEQ8Gt2Ox7K+tADB7eGt/An8T1M= X-Google-Smtp-Source: APXvYqwR/j0P7DtrRn+OzZndrZis2baGydM7HDo+ufok5zoGAmaDEWN/R070xj7BZt/PGE6ipHxXx4Ip1f429QtUk3c= X-Received: by 2002:a25:7492:: with SMTP id p140mr15356011ybc.394.1554209424807; Tue, 02 Apr 2019 05:50:24 -0700 (PDT) MIME-Version: 1.0 References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <1553867007783.37940@cs.auckland.ac.nz> In-Reply-To: <1553867007783.37940@cs.auckland.ac.nz> From: =?UTF-8?B?Q29ucmFkbyBQLiBMLiBHb3V2w6ph?= Date: Tue, 2 Apr 2019 09:50:12 -0300 Message-ID: To: Peter Gutmann Cc: "Neal H. Walfield" , "openpgp@ietf.org" , Justus Winter , Jon Callas , Jon Callas Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 12:50:28 -0000 (Sorry, I'm a lurker in this group, but wanted to chime in...) On Fri, Mar 29, 2019 at 10:45 AM Peter Gutmann wrote: > That was due to broken email apps. If I can convince your email app to > forward the plaintext of a decrypted message to me, you lose no matter what > encryption mechanism you use. > > Admittedly CBC/CFB made this easier, but it was the email apps that needed > fixing, not PGP. I believe that's not true. The second EFail attack was caused by PGP allowing removing the MDC or downgrading packets. This would not happen if PGP handled authentication correctly. > > I'm not saying it's not worth addressing, but before endlessly debating > solutions we need to figure out what problem we're solving. "We have this > cool AEAD mode lying around and want to apply it to something" isn't a > problem, or at least not a problem that a PGP user cares about solving, it's > something interesting for geeks to play with. > > In the last five years or so I've received approximately zero PGP-encrypted > emails, and I'm one of the people who helped write the thing. OTOH I've > probably encrypted gigabytes of data with it, almost always symmetric-key with > the key communicated out of band. In none of those cases would blocked auth > protection have been useful. > This whole discussion has nothing to do with AEAD itself. With "manual" encrypt-then-authenticate, the issue of chunk size and releasing unauthenticated plaintext is the same. Even for data at rest: many people store the data in cloud providers, where it could be tinkered with by attackers. If the problem is to be resilient to file corruption, then the answer is error-correcting codes, not ignoring authentication. (Though I agree that's an important issue that is mostly overlooked in crypto) Conrado From nobody Tue Apr 2 06:12:46 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DA512011F for ; Tue, 2 Apr 2019 06:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Rq2cs83VDb8t for ; Tue, 2 Apr 2019 06:12:42 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC48012011A for ; Tue, 2 Apr 2019 06:12:41 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id l5so4560821ywa.0 for ; Tue, 02 Apr 2019 06:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PWJJ8V34nuI+PuBZGN/qSgLlJI4FB4OzwnXSZjy4wlk=; b=JquBqZ/daBaXmJSHPm0rjHKOcG/ehT34rsNRw869v8PHCX97VULewj3vMrfiVhxqrW 7GDaD52rTUjUDPAz7+TySvJmLqIPuCGlU52UZ8evL9oxvMVmDlxb0VVmzESGznm71Kj8 ia3m1O3Q9ynd9f1ne2q4WNKNl+L1U2RIubCDgDcrps7GmMimXQd37OJK4Uojj5JqzM8W ygd7tMBuZkkvJwuPHtVyFK/UX7UoH6faMbkgdBltiky+1Yl2ge5a2LvGBzKJWLMO3eOq BvsKna0RN3N/M5vR9FmFJXwy26VSbosFysqfoOkbqCgJTcj/6mXUVJjsWWodpmIT/hQf NoDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PWJJ8V34nuI+PuBZGN/qSgLlJI4FB4OzwnXSZjy4wlk=; b=YKTFmGaSfjzjDmSrvcrhTFDUZJ/Cyf/jQPBYn8dWNBUV3nUpwow9cnGMX4btdJzhTh za/PgVOHCJVB1r3Svt7La3aaJtTz+HrKNfHo1KGlqa9OGisH98bh/bgxGcuuqO01CiDI vHfjdg+aN7Rsc+EkA/Lb2DkyBPUNQ4xmJBV7isR8xBBAu6DmR8hDjgJj6RyCH7fSWAoo C9ikPAOmSE9OM1TryrLaQ5y5Zx1aZfMYHrx2raGmYODHEzvB9lCnnvMXyxwRO+NuswBv F9FbCVKl9cumKbQb/5HXJtGsSAxieIXZ613UkhO5aEeJ56R+mXbhaIDrOSpe6u2STUlG dSSA== X-Gm-Message-State: APjAAAXKuKC7P6RdAH+0bGlPCUPvThiErDBHctn7ENWyRFucDJveKfzi McUskdBAb3deLsacIctqJ3IOqZgqVwUmI/ZT3xg= X-Google-Smtp-Source: APXvYqwoJzjjievLgPfeCgmcj0KbReBPSh14AoXmlv80dVHIIBfwxWypgS8OEx8l+YfrglQYDKJIt6y0R+9tCBJ3zuQ= X-Received: by 2002:a0d:e403:: with SMTP id n3mr34002559ywe.408.1554210760922; Tue, 02 Apr 2019 06:12:40 -0700 (PDT) MIME-Version: 1.0 References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87zhpd21d3.wl-neal@walfield.org> <1554001112803.75759@cs.auckland.ac.nz> In-Reply-To: <1554001112803.75759@cs.auckland.ac.nz> From: =?UTF-8?B?Q29ucmFkbyBQLiBMLiBHb3V2w6ph?= Date: Tue, 2 Apr 2019 10:12:29 -0300 Message-ID: To: Peter Gutmann Cc: Jon Callas , "Neal H. Walfield" , "openpgp@ietf.org" , Justus Winter , Jon Callas Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:12:45 -0000 On Sat, Mar 30, 2019 at 11:59 PM Peter Gutmann wrote: > I'm not saying remove it, just get some data to support making a decision in > some way. In particular, AEAD is a good thing, but there's no evidence that > chunking with AEAD, which complicates things greatly, is useful or necessary. > I know you're tired of hearing about it... but EFail. Even if PGP used AEAD, but without chunks, EFail would probably still happen. If the AEAD data is arbitrarly large, then implementations would be forced to provide a streaming API that discloses unauthenticated plaintext, and the same thing would happen. Unfortunately I'm not aware of other examples, though I'm pretty sure they must exist... But why should we wait for more of this issues to happen before fixing the underlying cause, if we can fix it now? (And "now" meaning many years hence, since the standard will take a while to be adopted). Adam Langley has a good post about it: https://www.imperialviolet.org/2014/06/27/streamingencryption.html And many examples of cryptographers claiming releasing unauthenticated plaintext is dangerous: https://crypto.stackexchange.com/questions/41087/is-there-an-upper-limit-to-plaintext-size-in-xsalsa20poly1305/51439 https://crypto.stackexchange.com/questions/51537/delayed-tag-checks-in-aes-gcm-for-streaming-data Conrado From nobody Tue Apr 2 10:43:03 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEC912019D for ; Tue, 2 Apr 2019 10:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 swAMG6EcavMD for ; Tue, 2 Apr 2019 10:42:55 -0700 (PDT) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DEE120147 for ; Tue, 2 Apr 2019 10:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1554226974; bh=53OJTzVX/DWG/Pf49mKStZdLpilOprcwcy76BUbGd7o=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=YWsdnalORGBrgZrtYd0uUTEIhFO5Os0hN37wJS1LZibM5tdqc7RFyq3ypH216bJKA d8uWs8Xi1bExa1QBNUizDC0YdEwP5rRBmNaSTrruGyPsg9Ju1kfJpsM0vzeqnMbJap GzZlglFk+l/lAfOxBa/45P4g+PjOQUE+girpahU7u41Kl6x02FD1rtHhih8j6WmdE6 oij5Pgxk1KY2/LcnMzcxINo6YjM/1AkPh0T7vwblQsTMRLkuFCCpaOoqzgHTjqs9OO xbu6fjM36sD58HiybwM904jQFZpqaEfogppwhQ2JMMiRtrX76qryhEh+6dJ9J3rJA9 Hag0xhNwZiogQ== Received: from [10.125.12.102] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id 8A138720106; Tue, 2 Apr 2019 17:42:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: Date: Tue, 2 Apr 2019 10:42:50 -0700 Cc: Jon Callas , Peter Gutmann , "Neal H. Walfield" , "openpgp@ietf.org" , Justus Winter Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87zhpd21d3.wl-neal@walfield.org> <1554001112803.75759@cs.auckland.ac.nz> To: =?utf-8?B?IkNvbnJhZG8gUC4gTC4gR291dsOqYSI=?= X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-02_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=633 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904020118 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 17:43:00 -0000 > On Apr 2, 2019, at 6:12 AM, Conrado P. L. Gouv=C3=AAa = wrote: >=20 > On Sat, Mar 30, 2019 at 11:59 PM Peter Gutmann > wrote: >> I'm not saying remove it, just get some data to support making a = decision in >> some way. In particular, AEAD is a good thing, but there's no = evidence that >> chunking with AEAD, which complicates things greatly, is useful or = necessary. >>=20 >=20 > I know you're tired of hearing about it... but EFail. > Even if PGP used AEAD, but without chunks, EFail would probably still > happen. If the AEAD data is arbitrarly large, then implementations > would be forced to provide a streaming API that discloses > unauthenticated plaintext, and the same thing would happen. No, no, it=E2=80=99s okay, because this why I was saying, =E2=80=9CLet=E2=80= =99s not talk about Efail.=E2=80=9D The AEAD discussion is good, and = there are many reasons to upgrade to allow its use. If one of those = reasons is complex, then having that be the major reason means that = there=E2=80=99s a counter-argument that is essentially, =E2=80=9Cif this = isn=E2=80=99t the silver bullet claimed, then maybe we shouldn=E2=80=99t = do it,=E2=80=9D and worse, it=E2=80=99s a completely reasonable = counter-argument.=20 There=E2=80=99s one more small issue around AEAD that I=E2=80=99ll bring = up in another note. Jon From nobody Tue Apr 2 11:20:35 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CF0120167 for ; Tue, 2 Apr 2019 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 8KutOuzx9-Ri for ; Tue, 2 Apr 2019 11:20:30 -0700 (PDT) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AC812013F for ; Tue, 2 Apr 2019 11:20:30 -0700 (PDT) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 56EDDE0A6B for ; Tue, 2 Apr 2019 18:20:29 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=KfNmrac54ooVdNcnQxISxe8MRjrRbRGkUrEfDUjc+gw=; b=NaUrEderriXMkHAPwnXEy12HrcxbrUMAUjEnH/bOHI/7wW3CJN2eGFMYbkBBqJnXUbQTfwAVsEHSDfXdMGJY6PgEDHDBzD+sVnnFNdpI+tIErKORj5ZSRk3jZ+RgzYqr7Lk272kbzj2O6d5QcSpjh15+0cIfcmxokUpYE88aO9U0lWllVDaXmG8kDcSoTwprxiJeJ7LaVuBaxk0IHS8J4jBb0p6xp2zpCfOjFuLi8YYHZvWKilTCVLArXtScyZZp8UGOInKHFEkN3YngGPpsNJ7GyKwmr2C0mQZ6ce8pmfiT/trVfLqSrnP+5R7TuEgFywGS/DQS9Wt6klF+s6+ccA== Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Tue, 2 Apr 2019 18:20:28 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B7D3BE073E; Tue, 2 Apr 2019 18:20:28 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 02 Apr 2019 14:20:28 -0400 To: "Neal H. Walfield" , "openpgp" From: vedaal@nym.hush.com In-Reply-To: <878swtgcgn.wl-neal@walfield.org> References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> <87k1gebu9o.fsf@fifthhorseman.net> <20190402014643.96606406B6@smtp.hushmail.com> <878swtgcgn.wl-neal@walfield.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20190402182028.B7D3BE073E@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 18:20:34 -0000 On 4/2/2019 at 2:15 AM, "Neal H. Walfield" wrote: >s2k is also used for SK-ESKs (symmetric-key encrypted session keys) >[1]. When using SK-ESKs, we may not have a key as a reference >point. >That is, it doesn't make sense to add a restriction of the form: >only >use argon with v5 keys, as there may not be any keys when we want >to >use argon! > >I agree with Jon that the implementations can figure out when to >phase >it in. That's at least something that we have experience with. > > [1] https://tools.ietf.org/html/rfc4880#section-5.3 ===== The issue is, that if it is not expressly implemented otherwise, the S2K used for the V4 or V5 key private key, will be the one that automatically defaults to the S2K for SK-ESK (reasonable behavior, actually: The most important security choice for the user is how to protect the user's private key, and presumably the user would like to give ESK's the same protection. This is also why the symmetric encryption algorithm choice for the private key, becomes the default algorithm for the ESK). Current Implementations already do this by default, and implementers need to be aware to actively 'undo' it once the new S2K is adopted. vedaal From nobody Tue Apr 2 14:07:32 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1932A120077 for ; Tue, 2 Apr 2019 14:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 x2VTZmXyZ_BP for ; Tue, 2 Apr 2019 14:07:29 -0700 (PDT) Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445271202ED for ; Tue, 2 Apr 2019 14:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1554239245; bh=325pI9f78TTZKGIUbb3owzKFtBkzykWYCVO0z1mIy30=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; b=eXqFMe6Ns0eksrSdbXlWI7jRuhC9v8pDebIg1q0c97wfUuX3TJ4VrKHXrerasOePN wx+xw+pVXoJJfcakIgFPc/9SVJsaenMD4AIhBYOYcz5FBNnddDgj5J9Xk0Mq7Xwmnp 2cmsCX0fnsMkDrIOaZlfYyQanoZIE9xAzR/cEyw8qWDCu6QlPVcyVbqIblu4NG5WEE rZ7UvgUYklJSihaP0cWZmGdiMfOri9BtaC5YU5vruLIdEss9BdzpdM7Bbj/nlK8THL /Buq2NMAryroJI4C2C6A2jibinvgL9HwmtNCYM/YaKxPVBZWjZWu2/FdPT1WZ7HUBt n33kQYISEC3qw== Received: from [10.125.12.102] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id 89AF1A000FA; Tue, 2 Apr 2019 21:07:25 +0000 (UTC) From: Jon Callas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <575B7FAD-C8D6-48CF-AF6A-AC975EF3BF5F@icloud.com> Date: Tue, 2 Apr 2019 14:07:24 -0700 Cc: Jon Callas To: "openpgp@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=786 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904020141 Archived-At: Subject: [openpgp] One last AEAD nit X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 21:07:31 -0000 This is another issue about the different semantics of communications = security and storage security. Consider the case of someone who archives files and encrypts them with = OpenPGP. Handwaving a bit, let=E2=80=99s just say it=E2=80=99s a = .tar.gz.pgp of some source tree. Now consider that there=E2=80=99s a = media failure and that failure affects one byte. If that was encrypted using the new AEAD encrypted data, we have = nominally discussed that there should not be a release of the data. Yet = I need it; there=E2=80=99s no other copy (or there *are* copies, but the = copies are of the same damaged file. The owner of that file needs to get as much of it back as possible. = Thus, there needs to be an option to ignore the AEAD error and just give = the plaintext. If the specification says MUST NOT, then this an issue. = We need an escape hatch. I can think of a number of ways to do it, for = example it could say something like =E2=80=9CMUST NOT by default..." Nonetheless, we need one so that people can pry open a damaged file. Jon From nobody Tue Apr 2 14:19:18 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844A31202F7 for ; Tue, 2 Apr 2019 14:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 DAmHMmzPv5c0 for ; Tue, 2 Apr 2019 14:19:14 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C371200CC for ; Tue, 2 Apr 2019 14:19:14 -0700 (PDT) Received: from [213.168.90.194] (helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hBQoJ-0002WV-PY; Tue, 02 Apr 2019 21:19:11 +0000 Date: Tue, 02 Apr 2019 23:19:11 +0200 Message-ID: <878sws14xc.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: "openpgp@ietf.org" , Jon Callas In-Reply-To: <575B7FAD-C8D6-48CF-AF6A-AC975EF3BF5F@icloud.com> References: <575B7FAD-C8D6-48CF-AF6A-AC975EF3BF5F@icloud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] One last AEAD nit X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 21:19:17 -0000 At Tue, 2 Apr 2019 14:07:24 -0700, Jon Callas wrote: > This is another issue about the different semantics of communications security and storage security. > > Consider the case of someone who archives files and encrypts them with OpenPGP. Handwaving a bit, let$B!G(Bs just say it$B!G(Bs a .tar.gz.pgp of some source tree. Now consider that there$B!G(Bs a media failure and that failure affects one byte. > > If that was encrypted using the new AEAD encrypted data, we have nominally discussed that there should not be a release of the data. Yet I need it; there$B!G(Bs no other copy (or there *are* copies, but the copies are of the same damaged file. > > The owner of that file needs to get as much of it back as possible. Thus, there needs to be an option to ignore the AEAD error and just give the plaintext. If the specification says MUST NOT, then this an issue. We need an escape hatch. I can think of a number of ways to do it, for example it could say something like $B!H(BMUST NOT by default..." > > Nonetheless, we need one so that people can pry open a damaged file. I agree that we should have an option like this, and that it should require explict opt-in by the user of the library / tool. From nobody Wed Apr 3 03:15:09 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5576412008B for ; Wed, 3 Apr 2019 03:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 tRBW7t9ncSHy for ; Wed, 3 Apr 2019 03:15:05 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C7212009A for ; Wed, 3 Apr 2019 03:15:04 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id k8so5926120lja.8 for ; Wed, 03 Apr 2019 03:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to; bh=5SNH2Zm/eixXnRnmsIWlnq+4kH+K7VanpJbj2IGoKOc=; b=JnexPWAh9GXRtCGaVa36br4/ZSsSWnFzfKCT2rbBmVmZm1nZiYDHaMYAfZxGzS/2Hn lKoN5F+HUtOoMM8SRd43x5OmdRfOAd6wMKY0TPSEGd+rcEW2uy3KHhRLCU+K7XCK8WVP cnSojc3NSz74gAmFMMQA/1FRkLyaxluNFhlpa8drl2PuAGXsH0HLuFrqxcmAD3304qfS lZN1aQNkRSWTIFcS4nIKM3nlWitPsB1p+Vp3YvoqlWMnAyFyln4zLk4sPW2JqNvM6YPV 55H5q/4f556q3Hd9bDKnbxLRn3BzP9+8e3PcIYlyaBczvxWouXPgZJAPHhpeUPtwM0KB Z8iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to; bh=5SNH2Zm/eixXnRnmsIWlnq+4kH+K7VanpJbj2IGoKOc=; b=iRxr6s4lteR4Sl+EQimK6rjEe99x4sirAZjNjnSfjJsXxqg2FtJe86QscA9boGxkWo NfXlm0gLtqrnzrszMAWP7GzZIwMoSw4i1WBZ9ug8pPo8UZjTLIcG1gl3/BBXEGw1Tnxs Nst60q9xDtGw8hmO6/+S8flbqRSUXZnmF0aWF0x+ZqBVGjsKv+1GNopEArnp4JU93ElI i0a/aLi6rywFpE6ohRL8sYWAraByeg+P1A4xqyPTjCIPOxBTYOcc55ZANZP52A3H+vYW PWxrrFLEHYMMGb2FCAtaqPm+YMnDZb5f4waGDrFgC2l4BiHpHULtWkPM+tS4iwDRRyk/ 2kNg== X-Gm-Message-State: APjAAAVBw/BtZczY2T0iqOyRUjLApkkotN5LI6GeFZHp38e+rXQOjIds KK621AKMGb0ye7cxHyICdPspY9pi1a5pMA== X-Google-Smtp-Source: APXvYqyWVQl7fU5vf/F1LKmzPKfz6nRzZJX0zSB379W4LjWvg/YO3hu89DqqNobN5/WVOUr7rIrjXA== X-Received: by 2002:a2e:9682:: with SMTP id q2mr3285997lji.168.1554286502730; Wed, 03 Apr 2019 03:15:02 -0700 (PDT) Received: from ?IPv6:2a02:a317:4e3d:46f0:8257:3c28:8576:2eba? ([2a02:a317:4e3d:46f0:8257:3c28:8576:2eba]) by smtp.googlemail.com with ESMTPSA id a24sm3213952ljd.32.2019.04.03.03.15.01 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 03:15:01 -0700 (PDT) To: Daniel Kahn Gillmor , Werner Koch Cc: openpgp@ietf.org References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> <87y34uaat4.fsf@fifthhorseman.net> From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Wed, 3 Apr 2019 12:14:36 +0200 MIME-Version: 1.0 In-Reply-To: <87y34uaat4.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kzb02qo7RGdGxCHCGxnGk9Nn9X5aJMmBs" Archived-At: Subject: Re: [openpgp] Web Key Directory and CORS X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 10:15:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kzb02qo7RGdGxCHCGxnGk9Nn9X5aJMmBs Content-Type: multipart/mixed; boundary="j6F8eqbISz0zxPjGr7jhrk37usviaJU8h"; protected-headers="v1" From: Wiktor Kwapisiewicz To: Daniel Kahn Gillmor , Werner Koch Cc: openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Web Key Directory and CORS References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> <87y34uaat4.fsf@fifthhorseman.net> In-Reply-To: <87y34uaat4.fsf@fifthhorseman.net> --j6F8eqbISz0zxPjGr7jhrk37usviaJU8h Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Daniel, On 01.04.2019 01:22, Daniel Kahn Gillmor wrote: > I don't know CORS well enough to know how to properly constrain such a > header, but if we do add guidance, i'd want to make sure it is narrowly= > scoped so that an administrator deploying WKD doesn't accidentally open= > up the rest of the site's data to external cross-origin requests. If by "how to properly constrain" you mean configuration on the server=20 side then it looks something like that for nginx: location /.well-known/openpgpkey { add_header Access-Control-Allow-Origin '*' always; } or for Apache: Header set Access-Control-Allow-Origin "*" I agree that it's a good idea to expose it as narrowly as possible,=20 though it doesn't give JavaScript code in the browser more power than=20 "curl". (I can discuss details in case anyone is interested). Just in case a proof-of-concept is needed I wrote a simple decentralized = encrypt-then-email page that utilizes OpenPGP.js, CORS WKD and mailto=20 links: https://metacode.biz/sandbox/encrypt Kind regards, Wiktor --=20 https://metacode.biz/@wiktor --j6F8eqbISz0zxPjGr7jhrk37usviaJU8h-- --Kzb02qo7RGdGxCHCGxnGk9Nn9X5aJMmBs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJyBAEBCABcFiEEWaKd6o03OIxlaGPfuXoe4J20F+wFAlykh5IpGGh0dHBzOi8v bWV0YWNvZGUuYml6L0B3aWt0b3Ivb3BlbnBncC9rZXkUHHdpa3RvckBtZXRhY29k ZS5iaXoACgkQuXoe4J20F+y4jhAAnDz8gORAmhOqpbGC38CkkObQte7O0RJdks// 07nGF0N9e3JPH+xTEbbkIyduiLHyd6mO2KvhspQhg29hJTNHD8mdA5Kt0SpsCsIN 7E+ZrDBYKTCjOf2s5Gry/lBMydQ8ImHyj/P18qhKtB/rqUbjhdSdq5a6PRln7qvm K0m1bnSqwfu+E9sZ/epAlF3HK4hPoP8OXYiC4qhUOBRy27/myUqdD/yLCNFNvgR/ rxFkoZTmkAeHxQkd1cQAtmIzpPW52lfa0azfDPuKZDqGptT2WfKs5XEgmq0bIX6q 4RtRbYVeGNNkxD+ynTabvD29HOkap82VhokG+3lWPurU2zMbFC2TKHZKn2ljBFKl lSwmiDtMBwl8v+R8cYMZX78hbVNOCI378xEAfvDH+M+FuCE9k63Se/ekJDky1siV IvPrBIN78tigeFhK5kKnFoOG7KjLaj4r7eWPI/VasqERsjsmsJ1d5QU+YjzMxNib PrCdJrlyIBMh64CjGyGqnaZuYNpFTrIWxZ91s4n4ZUtNlPRxV3o1H16s067FrS5w xi52K8si2hpTEfCtM2LpT+mpF7rAhLYVqWbRRv6nfL982LQ7kWOPCHmr/mw/f6Sv BPfuehz7lWlkhSiFosCXAND58+UXS2aswSr92FKgzoCtkXC+LXuhkiQzgVDQIprD 6OU0uHA= =piZF -----END PGP SIGNATURE----- --Kzb02qo7RGdGxCHCGxnGk9Nn9X5aJMmBs-- From nobody Wed Apr 3 04:47:18 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1226612009E for ; Wed, 3 Apr 2019 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Z9DthMBO; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=UkU6BIlc 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 VGoi2_SdL7Fv for ; Wed, 3 Apr 2019 04:47:14 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39857120089 for ; Wed, 3 Apr 2019 04:47:14 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554292032; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FmZJ2mEXSym0dgHgsMYwH6H4Z3P74vHLEaBjYY5nbVw=; b=Z9DthMBOu4Y+gRWTdQi8hfrJHAefzWW4whOeqHF7U5sVt2FXkWMamj21 uAC616TSCxEhqs4wC2h5KVeo2pB1Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554292032; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FmZJ2mEXSym0dgHgsMYwH6H4Z3P74vHLEaBjYY5nbVw=; b=UkU6BIlcSLqBjwbO7latZat+Q3kG6327EVoCJhvdc39aw1vKAP3Wdk+a bx62/FcJllkbtrQ4JyqCE9AdBuRj0r9OdrM+7ZmFXhQ7wDSlQIdpEy2vK7 D2CWipwbLE0J44fr/06KkJn5/z7J+gmh8d1N2fuhz84TZyOt/uWaMai90E W5ODmrnOONnyba7SMuXHU6pJ3++96cwlhCEU/DvurXiZhI2ALWFY/U+NUA 4D1WyFkL9LUgbI00b42TqNIjEv8jHB3D1UCjTh0Qsuo6JMLY+71SsusL6i jVoXlExHsEIJaZ/dfays5fBBOJbYpw1P/fZaQGZjvkeSpjPTkr3C/A== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:d0f0:7dff:fecb:e7a6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id BDAFAF99D; Wed, 3 Apr 2019 07:47:11 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C42FA203C8; Wed, 3 Apr 2019 07:47:08 -0400 (EDT) From: Daniel Kahn Gillmor To: Wiktor Kwapisiewicz , Werner Koch Cc: openpgp@ietf.org In-Reply-To: References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> <87y34uaat4.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 03 Apr 2019 07:47:08 -0400 Message-ID: <87y34r48g3.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory and CORS X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 11:47:17 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2019-04-03 12:14:36 +0200, Wiktor Kwapisiewicz wrote: > If by "how to properly constrain" you mean configuration on the server=20 > side then it looks something like that for nginx: > > location /.well-known/openpgpkey { > add_header Access-Control-Allow-Origin '*' always; > } > > or for Apache: > > > Header set Access-Control-Allow-Origin "*" > > > I agree that it's a good idea to expose it as narrowly as possible,=20 > though it doesn't give JavaScript code in the browser more power than=20 > "curl". (I can discuss details in case anyone is interested). thanks, this is super useful. Could you propose text to be added to https://tools.ietf.org/html/draft-koch-openpgp-webkey-service as deployment guidance? > Just in case a proof-of-concept is needed I wrote a simple decentralized= =20 > encrypt-then-email page that utilizes OpenPGP.js, CORS WKD and mailto=20 > links: https://metacode.biz/sandbox/encrypt neat, thanks for this! It's a shame that it can't produce PGP/MIME messages, but rather does inline PGP, but i can see that's a limitation of mailto: itself. I'm assuming this is yours as well: https://metacode.biz/openpgp/web-key-directory that's very useful testing harness. It doesn't seem to match draft -07 though, because it's missing the l=3D query parameter (https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section-3= .1), and i can't tell whether it tries the "openpgpkey.*" subdomain first. Many thanks for putting concrete testing infrastructure in place for this, and walking through what such a tool needs to be useful in the browser-based message composition context! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXKSdPAAKCRB2GBllKa5f +HrJAP4z2Ml9NYCUe+EeBYvPwHZipWP+KPnV/LfW47OW1IgROQD/RST+lbKi+CBR sZklMUW/VkMGUUzmn+Dr10HoWWQiwQ4= =4FHI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 3 05:07:54 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7111B120089 for ; Wed, 3 Apr 2019 05:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 DNhTBWFgFbGU for ; Wed, 3 Apr 2019 05:07:49 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE241200EC for ; Wed, 3 Apr 2019 05:07:49 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id a6so11539656lfl.5 for ; Wed, 03 Apr 2019 05:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to; bh=kgVnbCyt1Pk35wQoIOGDxl6mlttQDSBbRzloXHcc0Jc=; b=1WO1mzQwHE4hHtYtoOpWwpNnaeTlJ2hApR8BNWM7JH0Na5foGJEwrIuB/9l7THeRne GJetlbIyAl11cnps7ziF/afyUV/DSE3jfzxep8sPPtJVf8riFJh0I48tWq6ZPrhbmZU/ mqcqhVRDDLY1mtU22rqq9PpvRvsFzccKWWAzICkLJGoppQa8H7GUOsjQwrSq4xwKt6cr olfuHQaBZllq/QXO7C/f22SUq+nKil1tlQMwIfEWXE2/wbfIWY2jQbkCtpN7fzhb4GNx 8CTd3bqTFFb2WuS8An28wp1w8VmSLNyIkubx1V6H8DlAQph24/7eHLEx53IdQFUCj8CR EXsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to; bh=kgVnbCyt1Pk35wQoIOGDxl6mlttQDSBbRzloXHcc0Jc=; b=b0x2HI2fF+H9GxHJ90uf3sNpWw8zJhTlMvnVz9HfFRijtp4dpeOiOK0r3VJbpawjo6 yUlYFOtsdj+OVGiPogMbjQBJrdO8XjwPyGnrCyXzEu59VV1gQIjI1OrY54S8w6KuiI+w f074EZHCjRqxWdvY6x5d1iP2aidNBReBxik2pEfz249H5YJrLJnrNNIMGt6TiIhNvO21 JYqdIhHDgJNzzNMrniLwdUXZ0072oAnJM1dz4tLRFQor4ddpXabGjpF8RDbm6hCpAyEk DKi+CiuPJY5++PR3qCex7Y5uaSbS1iim55mEsMn10pQgKDHfoupHIw9nsy2643VKp0CT u1Ww== X-Gm-Message-State: APjAAAVMX/xblKKu0DePEaxvbiCZk6MXrxTzW5UhvwNR2tp9OnI+MWpC MtKfKSUDyQmig6lqsZDZhh4TVonQO1CX4Q== X-Google-Smtp-Source: APXvYqxEgjEnvfv9o8E+YCZkvsIO5AkiOOQmjOMO73NEbJ/kVNwgu17WzHOFAqOY5mMnJlz9VjMxbQ== X-Received: by 2002:ac2:4551:: with SMTP id j17mr16226793lfm.141.1554293267209; Wed, 03 Apr 2019 05:07:47 -0700 (PDT) Received: from ?IPv6:2a02:a317:4e3d:46f0:8257:3c28:8576:2eba? ([2a02:a317:4e3d:46f0:8257:3c28:8576:2eba]) by smtp.googlemail.com with ESMTPSA id f4sm3252137ljg.37.2019.04.03.05.07.45 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 05:07:45 -0700 (PDT) To: Daniel Kahn Gillmor Cc: Werner Koch , openpgp@ietf.org References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> <87y34uaat4.fsf@fifthhorseman.net> <87y34r48g3.fsf@fifthhorseman.net> From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: <339f7925-ceb0-1c04-ff9b-364513c606a8@metacode.biz> Date: Wed, 3 Apr 2019 14:07:25 +0200 MIME-Version: 1.0 In-Reply-To: <87y34r48g3.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HOtFMmqM9bbGs1XlGl3EYJaMOrgwPg8gj" Archived-At: Subject: Re: [openpgp] Web Key Directory and CORS X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 12:07:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HOtFMmqM9bbGs1XlGl3EYJaMOrgwPg8gj Content-Type: multipart/mixed; boundary="9SFeVzWt70sbEuTIHqPH1WefuIgTLVIvQ"; protected-headers="v1" From: Wiktor Kwapisiewicz To: Daniel Kahn Gillmor Cc: Werner Koch , openpgp@ietf.org Message-ID: <339f7925-ceb0-1c04-ff9b-364513c606a8@metacode.biz> Subject: Re: [openpgp] Web Key Directory and CORS References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> <87y34uaat4.fsf@fifthhorseman.net> <87y34r48g3.fsf@fifthhorseman.net> In-Reply-To: <87y34r48g3.fsf@fifthhorseman.net> --9SFeVzWt70sbEuTIHqPH1WefuIgTLVIvQ Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Daniel, On 03.04.2019 13:47, Daniel Kahn Gillmor wrote: > thanks, this is super useful. Could you propose text to be added to > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service as > deployment guidance? Sure. I'll check out other RFCs for a formal language and I'll be back=20 with a patch. > neat, thanks for this! It's a shame that it can't produce PGP/MIME > messages, but rather does inline PGP, but i can see that's a limitation= > of mailto: itself. Yes, lack of PGP/MIME is sadly not there, on the other hand the entire=20 page has just 7 lines of readable JavaScript (not counting OpenPGP.js of = course). > I'm assuming this is yours as well: > https://metacode.biz/openpgp/web-key-directory >=20 > that's very useful testing harness. It doesn't seem to match draft -07= > though, because it's missing the l=3D query parameter > (https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#secti= on-3.1), > and i can't tell whether it tries the "openpgpkey.*" subdomain first. Yes, that's mine and yes it hasn't been updated to match latest drafts.=20 Sadly the amount of time I can spend on it is very scarce but bringing=20 it up to date is definitely on my TODO list. > Many thanks for putting concrete testing infrastructure in place for > this, and walking through what such a tool needs to be useful in the > browser-based message composition context! No problem. Actually that's what I like in standards - implementations=20 work in a wide variety of environments and still interoperate with each=20 other. Kind regards, Wiktor --=20 https://metacode.biz/@wiktor --9SFeVzWt70sbEuTIHqPH1WefuIgTLVIvQ-- --HOtFMmqM9bbGs1XlGl3EYJaMOrgwPg8gj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJyBAEBCABcFiEEWaKd6o03OIxlaGPfuXoe4J20F+wFAlykof0pGGh0dHBzOi8v bWV0YWNvZGUuYml6L0B3aWt0b3Ivb3BlbnBncC9rZXkUHHdpa3RvckBtZXRhY29k ZS5iaXoACgkQuXoe4J20F+wk5g/9E1eUcCo93sjxoveCvHOGZa8I1uiHthY4FxY+ tJSVpQK2XaWndOfvfSqHr6E1ti22LoB1qMB3ZQMRDWsOiqkoVS5fE8E9TTZMXy/3 hBccYGN8uR6TWt/3lbhjhnddQ7jBPaubZToXBhkqqlAxr3AjtRTNRSZMw3LrhF7d V8GIFfKiG1NBxXmnVx3Qm+2C2jLeb4XceX3SSLu75Fpl7IcLML+fHsKi8ZqIhBc8 iUXSrYu501zOg51mVMHeAoohPxhZ3yLMTsa5PUNfZrdT+p4Rjr7UkF35Iu5rrf8r +LSMxrwI4yeqNHCB2WEh74qe19gbzx05osCdUk4kJmtIUX3x9XVgnjEp8wZqVlNY N2/gYVzXr51DcKnoQnSVRljGZ1smtl/Su1JkHbAAw85tSSs/YU+rUxA1wfL8bCbC yYGawH0LQcimFQPaMntOnzsh5SGXXZ15EjOJiLwEzMUZ92rV4p7cG+xE2vt5iSqL PiTAf4mb06pg9qGnXRL4GBKoArmTiBZQ2+KqNxb+cMUFtH/dFXgHCKoJ8QlpTXWI HltM7V+no9y5sq7lRtGAMig5jrYKaxxYgeNhh5KWcxXPEwNrjZEhkCdb7NOrSjSw /6IXeod9dwN1tZGetHxyk4GmxMfdzaT3RduE3Vs0EYCsGiY5h67JPBDTN9DhZP19 i0VNKgM= =jLoq -----END PGP SIGNATURE----- --HOtFMmqM9bbGs1XlGl3EYJaMOrgwPg8gj-- From nobody Wed Apr 3 09:34:49 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AC6120094 for ; Wed, 3 Apr 2019 09:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=8STQghtF; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=0SDdQGe+ 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 VDX2GDTubsDt for ; Wed, 3 Apr 2019 09:34:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB1D1200B6 for ; Wed, 3 Apr 2019 09:34:45 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554309285; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=KXEKUserf0yzRXik3nEWBu2iyGulX2IC28RVmrAQbtY=; b=8STQghtFTBAa8aU3t6lrTmh6wwdy1l8vNxLD5FFpRR3519qqxiMPJtD9 tepjwZ7m7FH0tzTTDv67NcL1p1ICCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554309285; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=KXEKUserf0yzRXik3nEWBu2iyGulX2IC28RVmrAQbtY=; b=0SDdQGe+mnyqBYMqZGi6aPEXb8tskIbuYOdbuocUjFUDU3Zrfw6NM48c vl//ejL3b1WWWHreXkxzN3OacOF/tj1MiP49fP1VIXEzH18ZYKcj08Cf0x eFEnPemdyR7Q5zKCNaZ2PfO1oThuwR7fn6879bK73erlO+ZiCRVdGo1hoH wFoCiskzAgxfR2FHZHN59iPw0T3wizm9Sf4u3VhW7xIXBw7msupiIJOm8h M2PIZpr/jMA337P7k+YaoOeNMYmYC8r3dCR4loVrPGRxSEuIgQ4LzVRB0m T03Xv4vT+VAKdre2aH8uIoyNsZ7JhTTNaT2WDGatWYemTlK/QXMOIQ== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id ABCD6F99D; Wed, 3 Apr 2019 12:34:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9814D203C8; Wed, 3 Apr 2019 12:34:39 -0400 (EDT) From: Daniel Kahn Gillmor To: Jon Callas , Damien Goutte-Gattat Cc: openpgp@ietf.org, Jon Callas In-Reply-To: References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 03 Apr 2019 12:34:39 -0400 Message-ID: <87pnq33v4w.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 16:34:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon 2019-04-01 20:32:04 -0700, Jon Callas wrote: > I view this as primarily an implementation issue. > > If I were to write that section, I=E2=80=99d put both Argon2i and Argon2d > in. There are reasons to go with either, and I=E2=80=99d leave that to the > implementation. > > Interoperability matters only when you transfer keys from one > implementation to another, and as time goes on that is less and less > of a problem. (And the grumpy part of me says that if you=E2=80=99re goin= g to > transfer to some new implementation, maybe you want a new key, anyway > even as I know that=E2=80=99s not friendly.) It's not quite this simple, as S2K is also used in SK-ESK's (as Neal points out elsewhere in this thread). So that means "password-protected" OpenPGP messages, which are very often exchanged between parties, so interoperability is important. having both specs in the standard makes interop more challenging, so it would be better to just have one if possible. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXKTgnwAKCRB2GBllKa5f +OrwAP4zA0DtiUkbqQG0htCPvvhfQpyUyk+8Mx15g0acTOetigD8C2ImbFVLt7TH PhNbrd9sPTgow2lPvaMMEODbYf3SXAs= =YEEJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 4 15:41:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17212027A for ; Thu, 4 Apr 2019 15:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=TyBhM/s4; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=sIEBGrya 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 e4sGK6zWSgzp for ; Thu, 4 Apr 2019 15:41:21 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD016120233 for ; Thu, 4 Apr 2019 15:41:20 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554417679; h=from : to : cc : subject : date : message-id : mime-version : content-type : from; bh=knLWZNeIptDtVI+Zkoh9grofI1V0qeke8nJoH98bKCI=; b=TyBhM/s4ad30RNPP78L67abzUNXjWRkgSXrr6gq/klvYy5g1qpQIUyCe oW5MMh9At1mH3vOvfvTfl5m/lxcVCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554417679; h=from : to : cc : subject : date : message-id : mime-version : content-type : from; bh=knLWZNeIptDtVI+Zkoh9grofI1V0qeke8nJoH98bKCI=; b=sIEBGryauc8kDsjwPW01Bcgy84S0l7QfnXHgJm9Z7Lf9whQQDhyG7hic DFmJfPsZvWyHBqaEPGS2LPavuVuEVy5E0N84huDbU4egLmdOBElx9FGnk1 I0LvvnIIlIjF9EsmyFTkv5JIT3yGTyQDCkgdovsakAf2cKqQp4QNS1AhbT gKi9mYtpqn0r2+GdnNAj+aXNv+N6JvkNgU1xqyJ7/2EQsbt92tMIWWCvWI l/lrouswIDsm0z8b2qNvUK8kN5MYe8bs2OQMiQ4EQp6ejhRYZj9yIqBQKN g1zYYemXAcqacLShscvyray3eF7plbwIZwUKCjnOIgWQ2N2IuIDdyg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 129BAF99D; Thu, 4 Apr 2019 18:41:18 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7B5132022A; Thu, 4 Apr 2019 18:41:15 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org Cc: SKS development list Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Mail-Followup-To: openpgp@ietf.org Date: Thu, 04 Apr 2019 18:41:14 -0400 Message-ID: <87v9zt2y2d.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 22:41:25 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [ mail sent to both OpenPGP and SKS mailing lists; please respect Mail-Followup-To: openpgp@ietf.org, since it is more than just SKS ]=20 Hi OpenPGP and SKS folks-- As you may or may not have heard, the venerable OpenPGP keyserver network is dying. This has implications for key discovery, revocation, subkey rollover, expiration update, etc. across the ecosystem of tools that use OpenPGP. The keyserver network dying because of several reasons, some of which are discussed in a thread over at [0] -- but one main issue is that the SKS keyserver network allows anyone to attach arbitrary data to any OpenPGP certificate, bloating that certificate to the point of being impossible to effectively retrieve. SKS isn't the only keyserver that is vulnerable to this kind of attack either [1]. I wanted to put forward a "simple proposal" (ha ha) about how to think about a keyserver (or other public keystore) that would be more resistant to this kind of abuse. Such a keystore is unlikely to be able to synchronize with the existing keyserver network, and need not be a synchronizing keyserver at all -- these rules could just as well apply to a centralized keyserver that valdiates e-mail addresses, or any other authority. I've documented some thoughts on how to resist this abuse in a new Internet Draft: https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keyst= ore/ That's being developed in git at: https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore I welcome feedback and edits. The markdown source of the current draft is attached below. Regards, --dkg [0] https://lists.riseup.net/www/arc/monkeysphere/2019-04 [1] https://github.com/mailvelope/keyserver/issues/85 --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=draft-dkg-openpgp-abuse-resistant-keystore.md Content-Transfer-Encoding: quoted-printable =2D-- title: Abuse-Resistant OpenPGP Keystores docname: draft-dkg-openpgp-abuse-resistant-keystore-00 date: 2019-04-04 category: info ipr: trust200902 area: int workgroup: openpgp keyword: Internet-Draft stand_alone: yes pi: [toc, sortrefs, symrefs] author: - ins: D. K. Gillmor name: Daniel Kahn Gillmor org: American Civil Liberties Union street: 125 Broad St. city: New York, NY code: 10004 country: USA abbrev: ACLU email: dkg@fifthhorseman.net informative: RFC5322: RFC7929: I-D.shaw-openpgp-hkp: I-D.koch-openpgp-webkey-service: SKS: target: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home title: SKS Keyserver Documentation author: name: Phil Pennock ins: P. Pennock org: SKS development team date: 2018-03-25 GnuPG: target: https://www.gnupg.org/documentation/manuals/gnupg.pdf title: Using the GNU Privacy Guard author: name: Werner Koch ins: W. Koch org: GnuPG development team date: 2019-04-04 MAILVELOPE-KEYSERVER: target: https://github.com/mailvelope/keyserver/ title: Mailvelope Keyserver author:=20 name: Thomas Obernd=C3=B6rfer ins: T. Obernd=C3=B6rfer normative: RFC2119: RFC4880: RFC8174: I-D.ietf-openpgp-rfc4880bis: =2D-- abstract OpenPGP transferable public keys are composite certificates, made up of primary keys, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and distributed in public keystores. Unfortunately, since any third-party can add certifications with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these third-party certificate flooding attacks. =2D-- middle Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements Language =2D-------------------- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here. Terminology =2D---------- * "OpenPGP certificate" (or just "certificate") is used interchangeably with {{RFC4880}}'s "Transferable Public Key". The term "certificate" refers unambiguously to the entire composite object, unlike "key", which might also be used to refer to a primary key or subkey. =20=20=20 * An "identity certification" (or just "certification") is an {{RFC4880}} signature packet that covers OpenPGP identity information -- that is, any signature packet of type 0x10, 0x11, 0x12, or 0x13. Certifications are said to (try to) "bind" a primary key to a User ID. =20=20=20 * The primary key that makes the certification is known as the "issuer". The primary key over which the certification is made is known as the "subject". * A "first-party certification" is issued by the primary key of a certificate, and binds itself to a user ID in the certificate. That is, the issuer is the same as the subject. This is sometimes referred to as a "self-sig". =20=20=20 * A "third-party certification" is a made over a primary key and user ID by some other certification-capable primary key. That is, the issuer is different than the subject. (The elusive "second-party" is presumed to be the verifier who is trying to interpret the certificate) * A "keystore" is any collection of OpenPGP certificates. Keystores typically receive mergeable updates over the course of their lifetime which might add to the set of OpenPGP certificates they hold, or update the certificates. * "Certificate discovery" is the process whereby a user retrieves an OpenPGP certificate based on user ID. A user attempting to discover a certificate from a keystore will search for a substring of the known user IDs, most typically an e-mail address if the user ID is an {{RFC5322}} name-addr or addr-spec. Some certificate discovery mechanisms look for an exact match on the known user IDs. {{I-D.koch-openpgp-webkey-service}} and {{I-D.shaw-openpgp-hkp}} are both certificate discovery mechanisms. * "Certificate validation" is the process whereby a user decides whether a given user ID in an OpenPGP certificate is acceptable. For example, if the certificate has a user ID of "Alice " and the user wants to send an e-mail to alice@example.org, the mail user agent might want to ensure that the certificate is valid for this e-mail address before encrypting to it. This process can take different forms, and can consider many different factors, some of which are not directly contained in the certificate itself. For example, certificate validation might consider whether the certificate was fetched via DANE ({{RFC7929}}) or WKD ({{I-D.koch-openpgp-webkey-service}}); or whether it has seen e-mails from that address signed by the certificate in the past; or how long it has known about certificate. * "Certificate update" is the process whereby a user fetches new information about a certificate, potentially merging those OpnePGP packets to change the status of the certificate. Updates might include adding or revoking user IDs or subkeys, updating expiration dates, or even revoking the entire certificate by revoking the primary key directly. A user attempting to update a certificate typically queries a keystore based on the certificate's fingerprint. * A "keyserver" is a particular kind of keystore, typically means of publicly distributing OpenPGP certificates or updates to them. Examples of keyserver software include {{SKS}} and {{MAILVELOPE-KEYSERVER}}. One common HTTP interface for keyservers is {{I-D.shaw-openpgp-hkp}}. =20=20=20 * A "synchronizing keyserver" is a keyserver which gossips with other peers, and typically acts as an append-only log. Such a keyserver is typically useful for certificate discovery, certificate updates, and revocation information. They are typically *not* useful for certificate validation, since they make no assertions about whether the identities in the certificates they server are accurate. As of the writing of this document, {{SKS}} is the canonical synchronizing keyserver implementation, though other implementations exist. =20=20=20 * An "e-mail-validating keyserver" is a keyserver which attempts to verify the identity in an OpenPGP certificate's user ID by confirming access to the e-mail account, and possibly by confirming access to the secret key. Some implementations permit removal of a certificate by anyone who can prove access to the e-mail address in question. They are useful for certificate discovery based on e-mail address and certificate validation (by users who trust the operator), but some may not be useful for certificate update or revocation, since a certificate could be simply replaced by an adversary who also has access to the e-mail address in question. {{MAILVELOPE-KEYSERVER}} is an example of such a keyserver. * "Cryptographic validity" refers to mathematical evidence that a signature came from the secret key associated with the public key it claims to come from. Note that a certification may be cryptographically valid without the signed data being true (for example, a given certificate with the user ID "Alice " might not belong to the person who controls the e-mail address "alice@example.org" even though the self-sig is cryptographically valid). In particular, cryptographic validity for user ID in a certificate is typically insufficient evidence for certificate validation. Also note that knowledge of the public key of the issuer is necessary to determine whether any given signature is cryptographically valid. Some keyservers perform cryptographic validation in some contexts. Other keyservers (like {{SKS}}) perform no cryptographic validation whatsoever. =20=20=20 Problem Statement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Many public keystores (including both the {{SKS}} keyserver network and {{MAILVELOPE-KEYSERVER}}) allow anyone to attach arbitrary data (in the form of third-party certifications) to any certificate, bloating that certificate to the point of being impossible to effectively retrieve. For example, some OpenPGP implementations simply refuse to process certificates larger than a certain size. This kind of Denial-of-Service attack makes it possible to make someone else's certificate unretrievable from the keystore, preventing certificate discovery. It also makes it possible to swamp a certificate that has been revoked, preventing certificate update, potentially leaving the client of the keystore with the compromised certificate in an unrevoked state locally. Additionally, even without malice, OpenPGP certificates can potentially grow without bound. The rest of this document describes some mitigations that can be used by keystores that are concerned about these problems but want to continue to offer some level of service for certificate discovery, certificate update, or certificate validation. Simple Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D These steps can be taken by any keystore that wants to avoid obviously malicious abuse. They can be implemented on receipt of any new packet, and are based strictly on the structure of the packet itself. Limited Packet Sizes =2D------------------- While {{RFC4880}} permits OpenPGP packet sizes of arbitrary length, OpenPGP certificates rarely need to be so large. An abuse-resistant keystore SHOULD reject any OpenPGP packet larger than 8383 octets. (This cutoff is chosen because it guarantees that the packet size can be represented as a one- or two-octet {{RFC4880}} "New Format Packet Length", but it could be reduced further) This may cause problems for user attribute packets that contain large images, but it's not clear that these images are concretely useful in any context. Some keystores MAY extend this limit for user attribute packets specifically, but SHOULD NOT allow even user attributes packets larger than 65536 octets. Strict User IDs =2D-------------- {{RFC4880}} indicates that User IDs are expected to be UTF-8 strings. An abuse-resistant keystore MUST reject any user ID that is not valid UTF-8. Some abuse-resistant keystores MAY only accept User IDs that meet even stricter conventions, such as an {{RFC5322}} name-addr or addr-spec, or a URL like "ssh://host.example.org". As simple text strings, User IDs don't need to be nearly as long as any other packets. An abuse-resistant keystore SHOULD reject any user ID packet larger than 1024 octets. Drop or Standardize Unhashed Subpackets =2D-------------------------------------- {{RFC4880}} signature packets contain an "unhashed" block of subpackets. These subpackets are not covered by any cryptographic signature, so they are ripe for abuse. An abuse-resistant keysetore SHOULD strip out all unhashed subpackets. Note that some certifications only identify the issuer of the certification by an unhashed Issuer ID subpacket. If a certification's hashed subpacket section has no Issuer ID or Issuer Fingerprint (see {{I-D.ietf-openpgp-rfc4880bis}}) subpacket, then an abuse-resistant keystore that has cryptographically validated the certification SHOULD make the unhashed subpackets contain only a single subpacket. That subpacket should be of type Issuer Fingerprint, and should contain the fingerprint of the issuer. A special exception may be made for unhashed subpackets in a third-party certification that contain attestations from the certificate's primary key as described in {{fpatpc}}. Drop User Attributes =2D------------------- Due to size concerns, some abuse-resistant keystores MAY choose to ignore user attribute packets entirely, as well as any certifications that cover them. Drop Non-exportable Certifications =2D--------------------------------- An abuse-resistant keystore MUST NOT accept any certification that has the "Exportable Certification" subpacket present and set to 0. While most keystore clients will not upload these "local" certifications anyway, a reasonable public keystore that wants to minimize data has no business storing or distributing these certifications. Accept Only Cryptographically-verifiable Certifications =2D------------------------------------------------------ An abuse-resistant keystore that is capable of doing cryptographic validation MAY decide to reject certifications that it cannot cryptographically validate. This may mean that the keystore rejects some packets while it is unaware of the public key of the issuer of the packet. Accept Only Profiled Certifications =2D---------------------------------- An aggressively abuse-resistant keystore MAY decide to only accept certifications that meet a specific profile. For example, it MAY reject certifications with unknown subpacket types, unknown notations, or certain combinations of subpackets. This can help to minimize the amount of room for garbage data uploads. Any abuse-resistant keystore that adopts such a strict posture should clearly document what its expected certificate profile is, and should have a plan for how to extend the profile if new types of certification appear that it wants to be able to distribute. Contextual Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following mitigations may cause some packets to be dropped after the keystore receives new information, or as time passes. This is entirely reasonable for some keystores, but it may be surprising for any keystore that expects to be append-only (for example, some keyserver synchronization techniques may expect this property to hold). Note also that many of these mitigations depend on cryptographic validation. A keystore that needs to be append-only, or which cannot perform cryptographic validation MAY omit these mitigations. Note that {{GnuPG}} anticipates some of these suggestions with its "clean" subcommand, which is documented as: Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring. Drop Superseded Signatures =2D------------------------- An abuse-resistant keystore SHOULD drop all signature packets that are explicitly superseded. For example, there's no reason to retain or distribute a self-sig by key K over User ID U from 2017 if the keystore have a cryptographically-valid self-sig over from 2019. Note that this covers both certifications and signatures over subkeys, as both of these kinds of signature packets may be superseded. Getting this right requires a nuanced understanding of subtleties in {{RFC4880}} related to timing and revocation. Drop Expired Signatures =2D---------------------- If a signature packet is known to only be valid in the past, there is no reason to distribute it further. An abuse-resistant keystore with access to a functionally real-time clock SHOULD drop all certifications and subkey signature packets with an expiration date in the past. Note that this assumes that the keystore and its clients all have roughly-synchronized clocks. If that is not the case, then there will be many other problems! Drop Dangling User IDs, User Attributes, and Subkeys =2D--------------------------------------------------- If enough signature packets are dropped, it's possible that some of the things that those signature packets cover are no longer valid. An abuse-resistant keystore which has dropped all certifications that cover a User ID SHOULD also drop the User ID packet. Note that a User ID that becomes invalid due to revocation MUST NOT be dropped, because the User ID's revocation signature itself remains valid, and needs to be distributed. A primary key with no User IDs and no subkeys and no revocations MAY itself also be removed from distribution, though note that the removal of a primary key may make it impossible to cryptographically validate other certifications held by the keystore. Drop All Other Elements of a Directly-Revoked Certificate {#only-revocation} =2D-------------------------------------------------------- If the primary key of a certiifcate is revoked via a direct key signature, an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation. Note that the direct key revocation signature MUST NOT be dropped. In the event that an abuse-resistant keystore is flooded with direct key revocation signatures, it should retain the strongest, earliest revocation. In particular, if any of the revocation signatures has a "Reason for Revocation" of "Key material has been compromised", the keystore SHOULD retain the earliest such revocation signature (by signature creation date). If none have "Key material has been compromised", but some have "No reason specified", or lack a "Reason for Revocation" entirely, then the keystore SHOULD retain the earliest such revocation signature. Otherwise, the abuse-resistant keystore SHOULD retain the earliest direct key revocation signature it has seen. If any of the date comparisons results in a tie between two revocation signatures of the same severity, an abuse-resistant keystore SHOULD retain the signature that sorts earliest based on a binary string comparison of the signature packet itself. Implicit Expiration Date =2D----------------------- A particularly aggressive abuse-resistant keystore MAY choose an implicit expiration date for all signature packets. For example, a signature packet that claims no expiration could be treated by the keystore as expiring 3 years after issuance. FIXME: it's not clear what should happen with signature packets marked with an explicit expiration that is longer than implicit maximum. Should it be capped to the implicit date, or accepted? Warning: This idea is pretty radical, and it's not clear what it would do to an ecosystem that depends on such a keystore. It probably needs more thinking. First-party-only Keystores =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D In addition to all of the mitigations above, some keystores may resist abuse by declining to carry third-party certifications entirely. A first-party-only keystore *only* accepts and distributes cryptographically-valid first-party certifications. Given a primary key that the keystore understands, it will only attach user IDs that have a valid self-sig, and will only accept and re-distribute subkeys that are also cryptographically valid (including requiring cross-sigs for signing-capable subkeys as recommended in {{RFC4880}}). This effectively solves the problem of abusive bloating attacks on any certificate, because the only party who can make a certificate overly large is the holder of the secret corresponding to the primary key itself. However, first-party-only keystores also introduce new problems, for those people who rely on the keystore for discovery of third-party certifications. {{fpatpc}} attempts to address this lack. First-party-attested Third-party Certifications {#fpatpc} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We can augment a first-party-only keystore to allow it to distribute third-party certifications as long as the first-party has signed off on the specific third-party certification. An abuse-resistant keystore SHOULD only accept a third-party certification if it meets the following criteria: * The third-party certification MUST be cryptographically valid. Note that this means that the keystore needs to know the primary key for the issuer of the third-party certification. * The third-party certification MUST have an unhashed subpacket of type Embedded Signature, the contents of which we'll call the "attestation". This attestation is from the certificate's primary key over the third-party certification itself, as detailed in the steps below: * The attestation MUST be an OpenPGP signature packet of type 0x50 (Third-Party Confirmation signature) =20=20=20 * The attestation MUST contain a notation subpacket =20=20=20 * The attestation MUST contain a hashed "Issuer Fingerprint" subpacket with the fingerprint of the primary key of the certificate in question. =20=20=20 * The attestation MUST NOT be marked as non-exportable. =20 * The attestation MUST contain a hashed Notation subpacket with the name "ksok", and an empty (0-octet) value. * The attestation MUST contain a hashed "Signature Target" subpacket with "public-key algorithm" that matches the public-key algorithm of the third-party certification. =20=20=20 * The attestation's hashed "Signature Target" subpacket MUST use a reasonably strong hash algorithm (as of this writing, any {{RFC4880}} hash algorithm except MD5, SHA1, or RIPEMD160), and MUST have a hash value equal to the hash over the third-party certification with all unhashed subpackets removed. =20=20=20 * The attestation MUST be cryptographically valid, verifiable by the primary key of the certificate in question. =20=20=20 =20=20=20 What this means is that a third-party certificate will only be accepted/distributed by the keystore if: * the keystore knows about both the first- and third-parties. =20 * the third-party has made the identity assertion =20 * the first-party has confirmed that they're OK with the third-party certification being distributed by any keystore. =20=20=20 FIXME: it's not clear whether the "ksok" notification is necessary -- it's in place to avoid some accidental confusion with any other use of the Third-Party Confirmation signature packet type, but the author does not know of any such use that might collide. Key Server Preferences "No-modify" =2D--------------------------------- {{RFC4880}} section 5.2.3.17 ("Key Server Preferences") defines a "No-modify" bit. That bit has never been respected by any keyserver implementation that the author is aware of. This section effectively asks an abuse-resistant keystore to treat that bit as always set, whether it is present in the certificate or not. Client Interactions {#client-interactions} =2D------------------ The multi-stage layer of creating such an attestation (certificate creation by the first-party, certification by the third-party, attestation by the first-party, then handoff to the keystore) may represent a usability obstacle to a user who needs a third-party-certified OpenPGP certificate. No current OpenPGP client can easily create the attestions described in this section. More implementation work needs to be done to make it easy (and understandable) for a user to perform this kind of attestation. Side Effects and Ecosystem Impacts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Designated Revoker {#designated-revoker} =2D----------------- A first-party-only keystore might decline to distribute revocations made by the designated revoker. This is a risk to certificate-holder who depend on this mechanism. Perhaps this document should be amended to include these Certification-capable Subkeys =2D---------------------------- Much of this discussion assumes that primary keys are the only certification-capable keys in the OpenPGP ecosystem. Some proposals have been put forward that assume that subkeys can be marked as certification-capable. If subkeys are certification-capable, then much of the reasoning in this draft becomes much more complex, as subkeys themselves can be revoked by their primary key without invalidating the key material itself. That is, a subkey can be both valid (in one context) and invalid (in another context) at the same time. So questions about what data can be dropped are much fuzzier. The author of this draft recommends *not* considering any subkeys to be certification-capable to avoid this headache. Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D These mitigations defend individual OpenPGP certificates against bloating attacks. They collectively reduce the amount of data that such a keystore needs to track over time, but given the near-infinite space of possible OpenPGP keys that can be generated, the keystore in aggregate can still be made to grow without bound. This document proposes no clear measures to defend against such a denial of service attack against the keystore itself. {{designated-revoker}} describes a potentially scary security problem for designated revokers. TODO (more security considerations) Privacy Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Public OpenPGP keystores often distribute names or e-mail addresses of people. Some people do not want their names or e-mail addresses distributed in a public keystore, or may change their minds about it at some point. Append-only keystores are particularly problematic in that regard. The mitigation in {{only-revocation}} can help such users strip their details from keys that they control. However, if an OpenPGP certificate with their details is uploaded to a keystore, but is not under their control, it's unclear what mechanisms can be used to remove the certificate that couldn't also be exploited to take down an otherwise valid certificate. Third-party certifications effectively map out some sort of social graph. While the certifications basically only assert a binding between user IDs, the parties those user IDs represent in the real world, and cryptographic key material, those connections may be potentially sensitive, and users may not want to see these maps built. TODO (more privacy considerations) User Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D {{client-interactions}} describes some outstanding work that needs to be done to help users understand how to produce and distribute a third-party-certified OpenPGP certificate to an abuse-resistant keystore. IANA Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document asks IANA to register the "ksok" notation name in the OpenPGP Notation IETF namespace, with a reference to this document, as defined in {{fpatpc}}. Document Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \[ RFC Editor: please remove this section before publication ] This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by e-mail to the author. Please direct all significant commentary to the public IETF OpenPGP mailing list: openpgp@ietf.org --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXKaICwAKCRB2GBllKa5f +GhMAP9intTqk4qJAp7opnQhIU7CQtq7W1ouCMayMzhGKoA1HgD/XMk9lrIBpLzb nnoQkyTaMJUohvLwooTJZe0yUvMyqwc= =sijk -----END PGP SIGNATURE----- --==-=-=-- From nobody Thu Apr 4 18:06:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29D1202D5 for ; Thu, 4 Apr 2019 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 p8FfPvpoCKyy for ; Thu, 4 Apr 2019 18:06:40 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA681202C9 for ; Thu, 4 Apr 2019 18:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1554426400; x=1585962400; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e8XmoJR7EfeJF6ZiTY7/sUM09UnkxeFNyjJocAmWXuk=; b=Tdh9WzQAuVFWpRtbuavdxQ6hxSC12vbOU7QztaSeF/ZQ0Qo8r3fj/Yxu gXxNref2c1ubOfekfGT9ZRv3cYXdUR1fEdrOpeSnO/sDRX1RQcUznAl/V UE6VHqfEt4Tg7QuFLfrklD35pJeKz2npE9P9OwWwzsx7KHQgjV7kdI6vN pCQMBJBxv/I6iL35eWQ5tfCN5wdfOo4JgW9JDgtKq8d2euNsI2MUU0Tfu ZXsg18/HBWSDeusOmu5OOtHntW9a0G1uk1Tbke1EHCsnhTmxwkPPlZIsZ eYreI2WQXwFJvCclB4M7pJDXEixxPwF/ALd4UZ/dqg1JYdBX3EW5o+6aH w==; X-IronPort-AV: E=Sophos;i="5.60,310,1549882800"; d="scan'208";a="54642362" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Apr 2019 14:06:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 5 Apr 2019 14:06:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 5 Apr 2019 14:06:35 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , "openpgp@ietf.org" CC: SKS development list Thread-Topic: [openpgp] Modelling an abuse-resistant OpenPGP keyserver Thread-Index: AQHU6zeg9qCEF+Hfd0ew9vWRjgNolqYswSP7 Date: Fri, 5 Apr 2019 01:06:34 +0000 Message-ID: <1554426372909.29918@cs.auckland.ac.nz> References: <87v9zt2y2d.fsf@fifthhorseman.net> In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 01:06:43 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >I wanted to put forward a "simple proposal" (ha ha) about how to think abo= ut=0A= >a keyserver (or other public keystore) that would be more resistant to thi= s=0A= >kind of abuse.=0A= =0A= Put keys in the blockchain? There's got to be something it's useful for ap= art=0A= from fuelling pump-and-dumps.=0A= =0A= Peter.=0A= From kissg@ssg.ki.iif.hu Fri Apr 5 00:06:03 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED14C12012E for ; Fri, 5 Apr 2019 00:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 Mvyqkv71N7mH for ; Fri, 5 Apr 2019 00:06:01 -0700 (PDT) Received: from linzer.ki.iif.hu (linzer.ki.iif.hu [193.224.163.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91B51200B8 for ; Fri, 5 Apr 2019 00:06:00 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by linzer.ki.iif.hu (Postfix) with ESMTP id 8C1354060D6; Fri, 5 Apr 2019 09:05:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from linzer.ki.iif.hu ([IPv6:::ffff:193.224.163.7]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id ASxERB42lJZ2; Fri, 5 Apr 2019 09:05:57 +0200 (CEST) Received: from bakacsin.ki.iif.hu (unknown [IPv6:2001:738:0:519:f816:3eff:feb1:97cd]) by linzer.ki.iif.hu (Postfix) with ESMTP id B08964060D3; Fri, 5 Apr 2019 09:05:53 +0200 (CEST) Received: by bakacsin.ki.iif.hu (Postfix, from userid 1000) id EDAC734870; Fri, 5 Apr 2019 09:05:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bakacsin.ki.iif.hu (Postfix) with ESMTP id E102234848; Fri, 5 Apr 2019 09:05:52 +0200 (CEST) Date: Fri, 5 Apr 2019 09:05:52 +0200 (CEST) From: "Kiss Gabor (Bitman)" X-X-Sender: kissg@bakacsin.ki.iif.hu To: Peter Gutmann cc: Daniel Kahn Gillmor , "openpgp@ietf.org" , SKS development list In-Reply-To: <1554426372909.29918@cs.auckland.ac.nz> Message-ID: References: <87v9zt2y2d.fsf@fifthhorseman.net> <1554426372909.29918@cs.auckland.ac.nz> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) X-GPG-PUBLIC_KEY: http://keys.niif.hu:11371/pks/lookup?op=vindex&search=0x776A223ABB6ABB38 X-GPG-FINGERPRINT: 7EFD BC59 085F 9F6B 587C A92C 776A 223A BB6A BB38 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Fri, 05 Apr 2019 01:43:58 -0700 Subject: Re: [openpgp] [Sks-devel] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 07:16:03 -0000 > Put keys in the blockchain? There's got to be something it's useful for apart > from fuelling pump-and-dumps. AFAIK blockchain per se is not abuse resistant. Anyway storage medium does not matter in the first round. Gabor From nobody Fri Apr 5 01:57:39 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C8A120391 for ; Fri, 5 Apr 2019 01:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 mz73uZOEuNma for ; Fri, 5 Apr 2019 01:57:36 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A971201BE for ; Fri, 5 Apr 2019 01:57:35 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id r25so3801429lfn.13 for ; Fri, 05 Apr 2019 01:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XV3c/O2cpdtYE/aHA2xw4fSYIxV0SJR2AnsJb+in0HY=; b=K9xgWvb+rr6ltWq3P+STJZfwy7IUPSbtdQauizz8YDbvhSWkPHxUbtGEJ6sdWkVZK/ znUFKTcYS+RGu10AmrTD+MgKtgkQm1/8lOBv8NqQ5MK1cwIL/XyUhoXRy4ogZ/mXei66 8mkJETL8t935nuF2XfEgTHY1qQsysS2VinwVEvcTnpuQKaV4HNlUeOTCUuCev946tex/ 6001yC/+ezs0lTt9zFehKFt71mrCVJXbGdLEpKKuhILQuS12oy/E8zwNyY/gNBBic6vk 7lfdEXQeBuzA9YKWkugCz6JNmjBKwl3esm+NJJzLdvxy1xHjYBuC8QWeeGQ5UhUgt/so WKcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XV3c/O2cpdtYE/aHA2xw4fSYIxV0SJR2AnsJb+in0HY=; b=N4vsdVKaKn6EYwrJljJ7Vs0vaYRqYWenN/FvieLpWd+IJRjaNeo6Ov5TQ/aEthPBr0 KjY5gEBERV6kdkIM/+bROqhSURm0fglzaepsIeFRqWzxsrwDya9bXCQprk+W4ylDzyoE 0niA3je0upYIzGawaUnYteLSAB7ZmorrdLOp/hEKqzIG4BurpsTy76OGNDRc9yMiFMEp 4cyOxDPzRjtj0dbEQm+a3kM3RNtjvubZcXElG9YiRm010qCevCta3DLJMjIeg69fc8U0 xWerbqP+IIs7syY1mR7+8LdS90WKHPw7psky+OLliDCpI+g2pB+5HybbIrqlu4v3qs2+ rwkg== X-Gm-Message-State: APjAAAWAZZmfEuflOcjOlxv6cjRr7bCZpxE0/6pug/s6m9VlEzsoPp3v iXG5l6oXID6Fti78Sxh857R3j5bzscGGjA== X-Google-Smtp-Source: APXvYqx3IMGq12wzXFq9M8y2uCUyCdfLgmzgdG8wbK4vyjIdw1AfJuzmgA13Oq4nMxjbq329/0NV2A== X-Received: by 2002:a19:f809:: with SMTP id a9mr5833353lff.8.1554454653575; Fri, 05 Apr 2019 01:57:33 -0700 (PDT) Received: from ?IPv6:2a02:a317:4e3d:46f0:8257:3c28:8576:2eba? ([2a02:a317:4e3d:46f0:8257:3c28:8576:2eba]) by smtp.googlemail.com with ESMTPSA id j76sm1037813ljb.78.2019.04.05.01.57.32 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 01:57:32 -0700 (PDT) To: "Kiss Gabor (Bitman)" , Peter Gutmann Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , SKS development list References: <87v9zt2y2d.fsf@fifthhorseman.net> <1554426372909.29918@cs.auckland.ac.nz> From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Fri, 5 Apr 2019 10:57:17 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] [Sks-devel] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 08:57:38 -0000 On 05.04.2019 09:05, Kiss Gabor (Bitman) wrote: >> Put keys in the blockchain? There's got to be something it's useful for apart >> from fuelling pump-and-dumps. > > AFAIK blockchain per se is not abuse resistant. Not in general, bit for example for Bitcoin it costs at minimum 0.00001 BTC per kB of transaction [0] (not kB of data). Given current rates that's 5 cents. [0]: https://en.bitcoin.it/wiki/Miner_fees#Settings Other blockchain based systems such as Certificate Transparency logs don't have this requirement but one needs to go through trusted CA to get their data there. Still, files have been put in CT logs: https://github.com/JackOfMostTrades/catlog#catlog Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Fri Apr 5 02:13:26 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2151200DF for ; Fri, 5 Apr 2019 02:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earth.li 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 5hBv-GZZNekB for ; Fri, 5 Apr 2019 02:13:23 -0700 (PDT) Received: from the.earth.li (the.earth.li [IPv6:2001:41c8:10:b1f:c0ff:ee:15:900d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD1D120398 for ; Fri, 5 Apr 2019 02:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Gqpoe8zzAnJ4wbAmUpRZKpo7YuMToa+Y1oJevEOmnoY=; b=I2RnbpwErvw0FBOCn3ZPGagZsY muy+LmrtQeSO+GltHdY1o7D5r3kxu1uXj3Dgyz88xJ8AZZixqsTxkC7OQ/ytv/+p78xa2AJJLnUzn EloxYN2canTjv4sb2AZJdiZR/yQAZtvRTdwVJWGDViUVVPRC75E2ZB6VeFQxOBv2pLwzslGPhmS7k xLs4CY9h9lFmnQkxyc6NkArUPVc74m8rqcXVTqIDMrM6YtwRlGL4iSdFdTWQ9Sn/T0YBb10C9a2cC APSzOh2DrQDrE5CyFIZmNH5ov9UMRZLPzzgBtl2Y2Kl2vS46vUUKafZwC5XLQ6yCWC/fWk17Nr0zC PBEH8BsA==; Received: from noodles by the.earth.li with local (Exim 4.89) (envelope-from ) id 1hCKuX-0002xx-4W for openpgp@ietf.org; Fri, 05 Apr 2019 10:13:21 +0100 Date: Fri, 5 Apr 2019 10:13:20 +0100 From: Jonathan McDowell To: openpgp@ietf.org Message-ID: <20190405091320.mnkbjvsrn5jm46z5@earth.li> References: <87v9zt2y2d.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qlhq5vucaniduhvm" Content-Disposition: inline In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 09:13:26 -0000 --qlhq5vucaniduhvm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 04, 2019 at 06:41:14PM -0400, Daniel Kahn Gillmor wrote: > As you may or may not have heard, the venerable OpenPGP keyserver > network is dying. This has implications for key discovery, revocation, > subkey rollover, expiration update, etc. across the ecosystem of tools > that use OpenPGP. >=20 > The keyserver network dying because of several reasons, some of which > are discussed in a thread over at [0] -- but one main > issue is that the SKS keyserver network allows anyone to attach > arbitrary data to any OpenPGP certificate, bloating that certificate to > the point of being impossible to effectively retrieve. SKS isn't the > only keyserver that is vulnerable to this kind of attack either [1]. I like the suggestions you've made so far (though I think do think that various people seem to find image UATs useful, so limiting the packet size to 8383 is overly limiting). One additional thought I've had in the past is that if the keyserver is capable of cryptographic verification it could only accept new keys that are signed by an existing key. This would prevent a random flood of unconnected keys (such as Evil32), and mean that in the event of such a set of keys being uploaded it would be easy to trace which signature was the link (and potentially blacklist that key). J. --=20 =2E.. I'm dangerous when I know what I'm doing. --qlhq5vucaniduhvm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEERUuPEyEc/2gMWDpQ/xYvxc8/utEFAlynHDAACgkQ/xYvxc8/ utGqcg/9GRXlvwC9Pog6ayLyQNzixFF6ffGrMaSuB2Ub8XZZx8UaePMsMZFZ1+DM UI19XEldhgl9R9wAHC0JeosXLh+yH7bEAkz0QAL2UeqA+BG2ZGLtNsiRFd7vxLsF aWuqj6n03I5YVA/eKSGrSdb2viFgAItl2Hm5hAUKma3Y4nEVCF/tZYytW6u1vQgE IvUEBPEsgUw4UAiXwvufK6X/QQ80vlkgfWvH94QKkKFpjivxAIgrsOrseix6Y6rD MCktY8M7AMUhRxIJKQvIGkuWooO6a/SedADjyRFiks27gdQDGUKyPaCcbd45LXk7 bopEEL2sNfwT67Ueo+657MbT8IDQvZytjer0wsUoZrcYh8k4Eg0jSMbnauAKx5G2 QQWdRLr2xG089C7dMnqMyF7v1XT6+XIFupNAq9l5HxG9XQod+ZM4RpMgddxsB9re kMmyEgGpTvNpugGhUsJ5vlQc5FEpTfudmTO+V3IHFueRKgNx0aAIRj81b9dJLkXv vfjMtEsKVpxYhgBNmWf17q3oakEPlJuajzzywO61W5qojk+6HdJ35Kj3SRBcZAoN KL8jGJij4+wpEb4ICy6Q0Jynbzr6UerBguNaQZIYB84a5ZMLE9Si8EsBwksdXI8Z r149irAnRu+5CoQQ5BKCOCAuaHwVTLF3u3Mfm1I5I4QRcSsOKFc= =SkiK -----END PGP SIGNATURE----- --qlhq5vucaniduhvm-- From nobody Sat Apr 6 19:47:53 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1A1203BA for ; Sat, 6 Apr 2019 19:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=v36aMXcD; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=rFqN2/cc 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 YWY-uTt9ghYa for ; Sat, 6 Apr 2019 19:47:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7A11202D3 for ; Sat, 6 Apr 2019 19:47:46 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554605264; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=nWvqsgzIIW28jr75O2igH2XAT2UMk0mU5efqNe+W0o4=; b=v36aMXcDI+S9nP+HNRskDoJJ6uV2oiI/p1cYmM6RvnkZgCIomwjHAkpk aWmlmkywAIjRcpATzfbHpJac7MzGDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554605264; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=nWvqsgzIIW28jr75O2igH2XAT2UMk0mU5efqNe+W0o4=; b=rFqN2/ccQlIVrHTVLDxphnfcfpuAGphF9UVAyL2Zy9pY+SFWTZmD3d6A H6N12Fu65iiWwivbl6to+jvmxAbDtn/8LeRGswX20Z195oLJKdCfxRrzoH naIHMFirHQZAPRrWc/VJtM1vkWYVxQBVpBFUPfmeeosRNQisA8epk/OPRD Vfa0/3KzkycJNW9mhJNw2WQHjZJUkSNjdNzLHQa9nj8QQXGFz84paQT8tJ LnRTG4x1590MfS1jzBC6VrsBfRmohJCiK3MWZccSumsTZ+25WhEvzjYqtN s5eUuy6DzAQM6Z35xdDa9HAlGipYLBdO8t4qUC0ZnSSYgyPV2hwbiA== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id C2B16F99E for ; Sat, 6 Apr 2019 22:47:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 885B52065D; Sat, 6 Apr 2019 22:47:41 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net> References: <87v9zt2y2d.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sat, 06 Apr 2019 22:47:40 -0400 Message-ID: <8736mu350z.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 02:47:52 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu 2019-04-04 18:41:14 -0400, Daniel Kahn Gillmor wrote: > I've documented some thoughts on how to resist this abuse in a new > Internet Draft: > > https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-key= store/ Thanks to all for the discussion around this draft. I've tried to incorporate some of the feedback i've gotten, and added more mitigations and considerations, producing version -01. Substantive changes between -00 and -01: * split out Contextual and Non-Append-Only mitigations * documented several other mitigations, including: - Decline Data From the Future - Blocklist - Exterior Process - Designated Authorities - Known Certificates - Rate-Limiting - Scoped User IDs * documented Updates-Only Keystores * consider three different kinds of flooding * deeper discussion of privacy considerations * better documentation of Reason for Revocation * document user ID conventions The source for draft -01 is attached to this message, and remains available for merge requests and open issues at: https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore The most unsettling evolution of my own thinking on this has to do with clarifying the inherent tension between accepting unrestricted public certificate uploads and permitting useful certificate discovery (by user ID). (see the final paragraph of the security considerations section) In a world where the public contains people with malice (our world), i think we can't have both of those features due to user ID flooding. This has unfortunate implications for use cases that depend on public keyservers for both certificate discovery and unrestricted upload. This isn't a particularly novel or surprising insight, but it's definitely sad, since that was a nice set of features offered by the keyserver network, but i don't see how it can possibly be sustained in the face of deliberate attack. The implication is, i think, that we need to think differently about certificate discovery in most cases. In particular, i'm thinking that we really do need to expect in-band certificate discovery where possible, falling back to reliance on a deliberately curated keystore (which means being vulnerable to the curators). We'd then mainly to rely on public keystores for certificate update (and not for discovery). Finally, i'd like to call people's attention to =C2=A7 9.3 ("Assessing Certificates in the Past") -- this suggests that either our keystores need to be append-only (which is sad because of the risk of growth without bound) or we need to acknowledge that they can only reliably be used for online verification. Again, in-band certificate mitigation might help with this (i.e., distributing some form of certificate alongside the signature that needs verification, which can then be merged with any updated information from public keystores). --dkg --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=draft-dkg-openpgp-abuse-resistant-keystore.md Content-Transfer-Encoding: quoted-printable =2D-- title: Abuse-Resistant OpenPGP Keystores docname: draft-dkg-openpgp-abuse-resistant-keystore-01 date: 2019-04-06 category: info ipr: trust200902 area: int workgroup: openpgp keyword: Internet-Draft stand_alone: yes pi: [toc, sortrefs, symrefs] author: - ins: D. K. Gillmor name: Daniel Kahn Gillmor org: American Civil Liberties Union street: 125 Broad St. city: New York, NY code: 10004 country: USA abbrev: ACLU email: dkg@fifthhorseman.net informative: RFC5322: RFC7929: I-D.shaw-openpgp-hkp: I-D.koch-openpgp-webkey-service: SKS: target: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home title: SKS Keyserver Documentation author: name: Phil Pennock ins: P. Pennock org: SKS development team date: 2018-03-25 GnuPG: target: https://www.gnupg.org/documentation/manuals/gnupg.pdf title: Using the GNU Privacy Guard author: name: Werner Koch ins: W. Koch org: GnuPG development team date: 2019-04-04 MAILVELOPE-KEYSERVER: target: https://github.com/mailvelope/keyserver/ title: Mailvelope Keyserver author:=20 name: Thomas Obernd=C3=B6rfer ins: T. Obernd=C3=B6rfer DEBIAN-KEYRING: target: https://keyring.debian.org/ title: Debian Keyring author: name: Jonathan McDowell ins: J. McDowell org: Debian TOR: target: https://www.torproject.org/ title: The Tor Project PARCIMONIE: target: https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ title: Parcimonie author: name: Intrigeri PGP-GLOBAL-DIRECTORY: target: https://keyserver.pgp.com/vkd/VKDVerificationPGPCom.html title: PGP Global Directory Key Verification Policy date: 2011 author: org: Symantec Corporation MONKEYSPHERE: target: https://web.monkeysphere.info/ title: Monkeysphere author: - name: Daniel Kahn Gillmor ins: D. K. Gillmor - name: Jameson Rollins ins: J. Rollins normative: RFC2119: RFC4880: RFC8174: I-D.ietf-openpgp-rfc4880bis: =2D-- abstract OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores. Unfortunately, since any third-party can add certifications with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various forms of flooding attacks. =2D-- middle Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements Language =2D-------------------- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here. Terminology =2D---------- * "OpenPGP certificate" (or just "certificate") is used interchangeably with {{RFC4880}}'s "Transferable Public Key". The term "certificate" refers unambiguously to the entire composite object, unlike "key", which might also be used to refer to a primary key or subkey. =20=20=20 * An "identity certification" (or just "certification") is an {{RFC4880}} signature packet that covers OpenPGP identity information -- that is, any signature packet of type 0x10, 0x11, 0x12, or 0x13. Certifications are said to (try to) "bind" a primary key to a User ID. =20=20=20 * The primary key that makes the certification is known as the "issuer". The primary key over which the certification is made is known as the "subject". * A "first-party certification" is issued by the primary key of a certificate, and binds itself to a user ID in the certificate. That is, the issuer is the same as the subject. This is sometimes referred to as a "self-sig". =20=20=20 * A "third-party certification" is a made over a primary key and user ID by some other certification-capable primary key. That is, the issuer is different than the subject. (The elusive "second-party" is presumed to be the verifier who is trying to interpret the certificate) * A "keystore" is any collection of OpenPGP certificates. Keystores typically receive mergeable updates over the course of their lifetime which might add to the set of OpenPGP certificates they hold, or update the certificates. * "Certificate discovery" is the process whereby a user retrieves an OpenPGP certificate based on user ID (see {{user-id-conventions}}). A user attempting to discover a certificate from a keystore will search for a substring of the known user IDs, most typically an e-mail address if the user ID is an {{RFC5322}} name-addr or addr-spec. Some certificate discovery mechanisms look for an exact match on the known user IDs. {{I-D.koch-openpgp-webkey-service}} and {{I-D.shaw-openpgp-hkp}} both offer certificate discovery mechanisms. * "Certificate validation" is the process whereby a user decides whether a given user ID in an OpenPGP certificate is acceptable. For example, if the certificate has a user ID of `Alice ` and the user wants to send an e-mail to `alice@example.org`, the mail user agent might want to ensure that the certificate is valid for this e-mail address before encrypting to it. This process can take different forms, and can consider many different factors, some of which are not directly contained in the certificate itself. For example, certificate validation might consider whether the certificate was fetched via DANE ({{RFC7929}}) or WKD ({{I-D.koch-openpgp-webkey-service}}); or whether it has seen e-mails from that address signed by the certificate in the past; or how long it has known about certificate. * "Certificate update" is the process whereby a user fetches new information about a certificate, potentially merging those OpnePGP packets to change the status of the certificate. Updates might include adding or revoking user IDs or subkeys, updating expiration dates, or even revoking the entire certificate by revoking the primary key directly. A user attempting to update a certificate typically queries a keystore based on the certificate's fingerprint. * A "keyserver" is a particular kind of keystore, typically means of publicly distributing OpenPGP certificates or updates to them. Examples of keyserver software include {{SKS}} and {{MAILVELOPE-KEYSERVER}}. One common HTTP interface for keyservers is {{I-D.shaw-openpgp-hkp}}. =20=20=20 * A "synchronizing keyserver" is a keyserver which gossips with other peers, and typically acts as an append-only log. Such a keyserver is typically useful for certificate discovery, certificate updates, and revocation information. They are typically *not* useful for certificate validation, since they make no assertions about whether the identities in the certificates they server are accurate. As of the writing of this document, {{SKS}} is the canonical synchronizing keyserver implementation, though other implementations exist. =20=20=20 * An "e-mail-validating keyserver" is a keyserver which attempts to verify the identity in an OpenPGP certificate's user ID by confirming access to the e-mail account, and possibly by confirming access to the secret key. Some implementations permit removal of a certificate by anyone who can prove access to the e-mail address in question. They are useful for certificate discovery based on e-mail address and certificate validation (by users who trust the operator), but some may not be useful for certificate update or revocation, since a certificate could be simply replaced by an adversary who also has access to the e-mail address in question. {{MAILVELOPE-KEYSERVER}} is an example of such a keyserver. * "Cryptographic validity" refers to mathematical evidence that a signature came from the secret key associated with the public key it claims to come from. Note that a certification may be cryptographically valid without the signed data being true (for example, a given certificate with the user ID `Alice ` might not belong to the person who controls the e-mail address `alice@example.org` even though the self-sig is cryptographically valid). In particular, cryptographic validity for user ID in a certificate is typically insufficient evidence for certificate validation. Also note that knowledge of the public key of the issuer is necessary to determine whether any given signature is cryptographically valid. Some keyservers perform cryptographic validation in some contexts. Other keyservers (like {{SKS}}) perform no cryptographic validation whatsoever. * OpenPGP revocations can have "Reason for Revocation" (see {{RFC4880}}), which can be either "soft" or "hard". The set of "soft" reasons is: "Key is superseded" and "Key is retired and no longer used". All other reasons (and revocations that do not state a reason) are "hard" revocations. See {{revocations}} for more detail. Problem Statement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OpenPGP keystores that handle submissions from the public are subject to a range of flooding attacks by malicious submitters. This section describes three distinct flooding attacks that public keystores should consider. The rest of the document describes some mitigations that can be used by keystores that are concerned about these problems but want to continue to offer some level of service for certificate discovery, certificate update, or certificate validation. Certificate Flooding {#certificate-flooding} =2D------------------- Many public keystores (including both the {{SKS}} keyserver network and {{MAILVELOPE-KEYSERVER}}) allow anyone to attach arbitrary data (in the form of third-party certifications) to any certificate, bloating that certificate to the point of being impossible to effectively retrieve. For example, some OpenPGP implementations simply refuse to process certificates larger than a certain size. This kind of Denial-of-Service attack makes it possible to make someone else's certificate unretrievable from the keystore, preventing certificate discovery. It also makes it possible to swamp a certificate that has been revoked, preventing certificate update, potentially leaving the client of the keystore with the compromised certificate in an unrevoked state locally. Additionally, even without malice, OpenPGP certificates can potentially grow without bound. User ID Flooding {#user-id-flooding} =2D--------------- Public keystores that are used for certificate discovery may also be vulnerable to attacks that flood the space of known user IDs. In particular, if the keystore accepts arbitrary certificates from the public and does no verification of the user IDs, then any client searching for a given user ID may need to review and process an effectively unbounded set of maliciously-submitted certificates to find the non-malicious certificates they are looking for. For example, if an attacker knows that a given system consults a keystore looking for certificates which match the e-mail address `alice@example.org`, the attacker may upload hundreds or thousands of certificates containing user IDs that match that address. Even if those certificates would not be accepted by a client (e.g., because they were not certified by a known-good authority), the client typically still has to wade through all of them in order to find the non-malicious certificates. If the keystore does not offer a discovery interface at all (that is, if clients cannot search it by user ID), then user ID flooding is of less consequence. Keystore Flooding {#keystore-flooding} =2D---------------- A public keystore that accepts arbitrary OpenPGP material and is append-only is at risk of being overwhelmed by sheer quantity of malicious uploaded packets. This is a risk even if the user ID space is not being deliberately flooded, and if individual certificates are protected from flooding by any of the mechanisms described later in this document. The keystore itself can become difficult to operate if the total quantity of data is too large, and if it is a synchronizing keyserver, then the quantities of data may impose unsustainable bandwidth costs on the operator as well. Effectively mitigating against keystore flooding requires either abandoning the append-only property that some keystores prefer, or imposing very strict controls on initial ingestion. Simple Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D These steps can be taken by any keystore that wants to avoid obviously malicious abuse. They can be implemented on receipt of any new packet, and are based strictly on the structure of the packet itself. Decline Large Packets =2D-------------------- While {{RFC4880}} permits OpenPGP packet sizes of arbitrary length, OpenPGP certificates rarely need to be so large. An abuse-resistant keystore SHOULD reject any OpenPGP packet larger than 8383 octets. (This cutoff is chosen because it guarantees that the packet size can be represented as a one- or two-octet {{RFC4880}} "New Format Packet Length", but it could be reduced further) This may cause problems for user attribute packets that contain large images, but it's not clear that these images are concretely useful in any context. Some keystores MAY extend this limit for user attribute packets specifically, but SHOULD NOT allow even user attributes packets larger than 65536 octets. Enforce Strict User IDs =2D---------------------- {{RFC4880}} indicates that User IDs are expected to be UTF-8 strings. An abuse-resistant keystore MUST reject any user ID that is not valid UTF-8. Some abuse-resistant keystores MAY only accept User IDs that meet even stricter conventions, such as an {{RFC5322}} name-addr or addr-spec, or a URL like "ssh://host.example.org". As simple text strings, User IDs don't need to be nearly as long as any other packets. An abuse-resistant keystore SHOULD reject any user ID packet larger than 1024 octets. Scoped User IDs {#scoped-user-ids} =2D-------------- Some abuse-resistant keystores may restrict themselves to publishing only certificates with User IDs that match a specific pattern. For example, {{RFC7929}} encourages publication in the DNS of only certificates whose user IDs refer to e-mail addresses within the DNS zone. {{I-D.koch-openpgp-webkey-service}} similarly aims to restrict publication to certificates relevant to the specific e-mail domain. Strip or Standardize Unhashed Subpackets =2D--------------------------------------- {{RFC4880}} signature packets contain an "unhashed" block of subpackets. These subpackets are not covered by any cryptographic signature, so they are ripe for abuse. An abuse-resistant keysetore SHOULD strip out all unhashed subpackets. Note that some certifications only identify the issuer of the certification by an unhashed Issuer ID subpacket. If a certification's hashed subpacket section has no Issuer ID or Issuer Fingerprint (see {{I-D.ietf-openpgp-rfc4880bis}}) subpacket, then an abuse-resistant keystore that has cryptographically validated the certification SHOULD make the unhashed subpackets contain only a single subpacket. That subpacket should be of type Issuer Fingerprint, and should contain the fingerprint of the issuer. A special exception may be made for unhashed subpackets in a third-party certification that contain attestations from the certificate's primary key as described in {{fpatpc}}. Decline User Attributes =2D---------------------- Due to size concerns, some abuse-resistant keystores MAY choose to ignore user attribute packets entirely, as well as any certifications that cover them. Decline Non-exportable Certifications =2D------------------------------------ An abuse-resistant keystore MUST NOT accept any certification that has the "Exportable Certification" subpacket present and set to 0. While most keystore clients will not upload these "local" certifications anyway, a reasonable public keystore that wants to minimize data has no business storing or distributing these certifications. Decline Data From the Future =2D--------------------------- Many OpenPGP packets have time-of-creation timestamps in them. An abuse-resistant keystore with a functional real-time clock MAY decide to only accept packets whose time-of-creation is in the future. Note that some OpenPGP implementations may pre-generate OpenPGP material intended for use only in some future window (e.g. "Here is the certificate we plan to use to sign our software next year; do not accept signatures from it until then."), and may use modified time-of-creation timestamps to try to acheive that purpose. This material would not be distributable ahead of time by an abuse-resistant keystore that adopts this mitigation. Accept Only Profiled Certifications =2D---------------------------------- An aggressively abuse-resistant keystore MAY decide to only accept certifications that meet a specific profile. For example, it MAY reject certifications with unknown subpacket types, unknown notations, or certain combinations of subpackets. This can help to minimize the amount of room for garbage data uploads. Any abuse-resistant keystore that adopts such a strict posture should clearly document what its expected certificate profile is, and should have a plan for how to extend the profile if new types of certification appear that it wants to be able to distribute. Note that if the profile is ever restricted (rather than extended), and the restriction is applied to the material already present, such a keystore is no longer append-only (please see {{non-append-only}}). Accept Only Certificates Issued by Designated Authorities {#authorities} =2D-------------------------------------------------------- An abuse-resistant keystore capable of cryptographic validation MAY retain a list of designated authorities, typically in the form of a set of known public keys. Upon receipt of a new OpenPGP certificate, the keystore can decide whether to accept or decline each user ID of the certificate based whether that user ID has a certification that was issued by one or more of the designated authorities. If no user IDs are certified by designated authority, such a keystore SHOULD decline the certificate and its primary key entirely. Such a keystore SHOULD decline to retain or propagate all certifications associated with each accepted user ID except for first-party certifications and certifications by the designated authorities. The operator of such a keystore SHOULD have a clear policy about its set of designated authorities. Given the ambiguities about expiration and revocation, such a keyserver SHOULD ignore expiration and revocation of authority certifications, and simply accept and retain as long as the cryptographic signature is valid. Note that if any key is removed from the set of designated authorities, and that change is applied to the existing keystore, such a keystore may no longer be append-only (please see {{non-append-only}}). Decline Packets by Blocklist {#blocklist} =2D--------------------------- The maintainer of the keystore may keep a specific list of "known-bad" material, and decline to accept or redistribute items matching that blocklist. The material so identified could be anything, but most usefully, specific public keys or User IDs could be blocked. Note that if a blocklist grows to include an element already present in the keystore, it will no longer be append-only (please see {{non-append-only}}). Some keystores may choose to apply a blocklist only at distribution time and not apply it at input time. This allows the keystore to be append-only, and permits synchronization between keystores that don't share a blocklist, and somewhat reduces the attacker's incentive for flooding the keystore. Note that development and maintenance of a blocklist is not without its own potentials for abuse. For one thing, the blocklist may itself grow without bound. Additionally, a blocklist may be socially or politically contentious. There needs to be a clear policy about how it is managed, whether by delegation to specific decision-makers, or explicit tests. Furthermore, the existence of even a well-intentioned blocklist may be an "attractive nuisance," drawing the interest of would-be censors or other attacker interested in controlling the ecosystem reliant on the keystore in question. Contextual Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some mitigations make the acceptance or rejection of packets contingent on data that is already in the keystore or the keystore's developing knowledge about the world. This means that, depending on the order that the keystore encounters the various material, or how it discovers the material, the final set of material retained and distributed by the keystore might be different. While this isn't necessarily bad, it may be a surprising property for some users of keystores. Accept Only Cryptographically-verifiable Certifications =2D------------------------------------------------------ An abuse-resistant keystore that is capable of doing cryptographic validation MAY decide to reject certifications that it cannot cryptographically validate. This may mean that the keystore rejects some packets while it is unaware of the public key of the issuer of the packet. Accept Only Certificates Issued by Known Certificates =2D---------------------------------------------------- This is an extension of {{authorities}}, but where the set of authorities is just the set of certificates already known to the keystore. An abuse-resistant keystore that adopts this strategy is effectively only crawling the reachable graph of OpenPGP certificates from some starting core. A keystore adopting the mitigation SHOULD have a clear documentation of the core of initial certificates it starts with, as this is effectively a policy decision. This mitigation measure may fail due to a compromise of any secret key that is associated with a primary key of a certificate already present in the keystore. Such a compromise permits an attacker to flood the rest of the network. In the event that such a compromised key is identified, it might be placed on a blocklist (see {{blocklist}}). In particular, if a public key is added to a blocklist for a keystore implementing this mitigation, and it is removed from the keystore, then all certificates that were only "reachable" from the blocklisted certificate should also be simultaneously removed. Rate-limit Submissions by IP Address =2D----------------------------------- Some OpenPGP keystores accept material from the general public over the Internet. If an abuse-resistant keystore observes a flood of material submitted to the keystore from a given Internet address, it MAY choose to throttle submissions from that address. When receiving submissions over IPv6, such a keystore MAY choose to throttle entire nearby subnets, as a malicious IPv6 host is more likely to have multiple addresses. This requires that the keystore maintain state about recent submissions over time and address. It may also be problematic for users who appear to share an IP address from the vantage of the keystore, including those beind a NAT, using a VPN, or accessing the keystore via Tor. Accept Certiifcates Based on Exterior Process {#exterior-process} =2D-------------------------------------------- Some public keystores resist abuse by explicitly filtering OpenPGP material based on a set of external processes. For example, {{DEBIAN-KEYRING}} adjudicates the contents of the "Debian keyring" keystore based on organizational procedure and manual inspection. Accept Certificates by E-mail Validation =2D--------------------------------------- Some keystores resist abuse by declining any certificate until the user IDs have been verified by e-mail. When these "e-mail-validating" keystores review a new certificate that has a user ID with an e-mail address in it, they send an e-mail to the associated address with a confirmation mechanism (e.g., a high-entropy HTTPS URL link) in it. In some cases, the e-mail itself is encrypted to an encryption-capable key found in the proposed certificate. If the keyholder triggers the confirmation mechanism, then the keystore accepts the certificate. {{PGP-GLOBAL-DIRECTORY}} describes some concerns held by a keystore operator using this approach. {{MAILVELOPE-KEYSERVER}} is another example. Non-append-only mitigations {#non-append-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The following mitigations may cause some previously-retained packets to be dropped after the keystore receives new information, or as time passes. This is entirely reasonable for some keystores, but it may be surprising for any keystore that expects to be append-only (for example, some keyserver synchronization techniques may expect this property to hold). Furthermore, keystores that drop old data, or certifications that are superseded may make it difficult or impossible for their users to reason about the validity of signatures that were made in the past. See {{in-the-past}} for more considerations. Note also that many of these mitigations depend on cryptographic validation, so they're typically contextual as well. A keystore that needs to be append-only, or which cannot perform cryptographic validation MAY omit these mitigations. Note that {{GnuPG}} anticipates some of these suggestions with its "clean" subcommand, which is documented as: Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring. Drop Superseded Signatures {#drop-superseded} =2D------------------------- An abuse-resistant keystore SHOULD drop all signature packets that are explicitly superseded. For example, there's no reason to retain or distribute a self-sig by key K over User ID U from 2017 if the keystore have a cryptographically-valid self-sig over from 2019. Note that this covers both certifications and signatures over subkeys, as both of these kinds of signature packets may be superseded. Getting this right requires a nuanced understanding of subtleties in {{RFC4880}} related to timing and revocation. Drop Expired Signatures {#drop-expired} =2D---------------------- If a signature packet is known to only be valid in the past, there is no reason to distribute it further. An abuse-resistant keystore with access to a functionally real-time clock SHOULD drop all certifications and subkey signature packets with an expiration date in the past. Note that this assumes that the keystore and its clients all have roughly-synchronized clocks. If that is not the case, then there will be many other problems! Drop Dangling User IDs, User Attributes, and Subkeys =2D--------------------------------------------------- If enough signature packets are dropped, it's possible that some of the things that those signature packets cover are no longer valid. An abuse-resistant keystore which has dropped all certifications that cover a User ID SHOULD also drop the User ID packet. Note that a User ID that becomes invalid due to revocation MUST NOT be dropped, because the User ID's revocation signature itself remains valid, and needs to be distributed. A primary key with no User IDs and no subkeys and no revocations MAY itself also be removed from distribution, though note that the removal of a primary key may make it impossible to cryptographically validate other certifications held by the keystore. Drop All Other Elements of a Directly-Revoked Certificate {#only-revocation} =2D-------------------------------------------------------- If the primary key of a certificate is revoked via a direct key signature, an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation. Note that the direct key revocation signature MUST NOT be dropped. In the event that an abuse-resistant keystore is flooded with direct key revocation signatures, it should retain the hardest, earliest revocation (see also {{revocations}}). In particular, if any of the direct key revocation signatures is a "hard" revocation, the abuse-resistant keystore SHOULD retain the earliest such revocation signature (by signature creation date). Otherwise, the abuse-resistant keystore SHOULD retain the earliest "soft" direct key revocation signature it has seen. If either of the above date comparisons results in a tie between two revocation signatures of the same "hardness", an abuse-resistant keystore SHOULD retain the signature that sorts earliest based on a binary string comparison of the direct key revocation signature packet itself. Implicit Expiration Date =2D----------------------- In combination with some of the dropping mitigations above, a particularly aggressive abuse-resistant keystore MAY choose an implicit expiration date for all signature packets. For example, a signature packet that claims no expiration could be treated by the keystore as expiring 3 years after issuance. This would permit the keystore to eject old packets on a rolling basis. FIXME: it's not clear what should happen with signature packets marked with an explicit expiration that is longer than implicit maximum. Should it be capped to the implicit date, or accepted? Warning: This idea is pretty radical, and it's not clear what it would do to an ecosystem that depends on such a keystore. It probably needs more thinking. Updates-only Keystores {#updates-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In addition to the mitigations above, some keystores may resist abuse by declining to accept any user IDs or certifications whatsoever. Such a keystore MUST be capable of cryptographic validation. It accepts primary key packets, cryptographically-valid direct-key signatures from a primary key over itself, subkeys and their cryptographically-validated binding signatures (and cross signatures, where necessary). Clients of an updates-only keystore cannot possibly use the keystore for certificate discovery, because there are no user IDs to match. However, they can use it for certificate update, as it's possible to ship revocations (which are direct key signatures), new subkeys, updates to subkey expiration, subkey revocation, and direct key signature-based certificate expiration updates. Note that many popular OpenPGP implemenations do not implement direct primary key expiration mechanisms, relying instead on user ID expirations. These user ID expiration dates or other metadata associated with a self-certification will not be distributed by an updates-only keystore. Certificates shipped by an updates-only keystore are technically invalid {{RFC4880}} "transferable public keys," because they lack a user ID packet. However many OpenPGP implementations will accept such a certificate if they already know of a user ID for the certificate, because the composite certificate resulting from a merge will be a standards-compliant transferable public key. First-party-only Keystores {#first-party-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Slightly more permissive than the updates-only keystore described in {{updates-only}} is a keystore that also permits user IDs and their self-sigs. A first-party-only keystore only accepts and distributes cryptographically-valid first-party certifications. Given a primary key that the keystore understands, it will only attach user IDs that have a valid self-sig, and will only accept and re-distribute subkeys that are also cryptographically valid (including requiring cross-sigs for signing-capable subkeys as recommended in {{RFC4880}}). This effectively solves the problem of abusive bloating attacks on any certificate, because the only party who can make a certificate overly large is the holder of the secret corresponding to the primary key itself. However, a first-party-only keystore is still problematic for those people who rely on the keystore for discovery of third-party certifications. {{fpatpc}} attempts to address this lack. First-party-attested Third-party Certifications {#fpatpc} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We can augment a first-party-only keystore to allow it to distribute third-party certifications as long as the first-party has signed off on the specific third-party certification. An abuse-resistant keystore SHOULD only accept a third-party certification if it meets the following criteria: * The third-party certification MUST be cryptographically valid. Note that this means that the keystore needs to know the primary key for the issuer of the third-party certification. * The third-party certification MUST have an unhashed subpacket of type Embedded Signature, the contents of which we'll call the "attestation". This attestation is from the certificate's primary key over the third-party certification itself, as detailed in the steps below: * The attestation MUST be an OpenPGP signature packet of type 0x50 (Third-Party Confirmation signature) =20=20=20 * The attestation MUST contain a hashed "Issuer Fingerprint" subpacket with the fingerprint of the primary key of the certificate in question. =20=20=20 * The attestation MUST NOT be marked as non-exportable. =20 * The attestation MUST contain a hashed Notation subpacket with the name "ksok", and an empty (0-octet) value. * The attestation MUST contain a hashed "Signature Target" subpacket with "public-key algorithm" that matches the public-key algorithm of the third-party certification. =20=20=20 * The attestation's hashed "Signature Target" subpacket MUST use a reasonably strong hash algorithm (as of this writing, any {{RFC4880}} hash algorithm except MD5, SHA1, or RIPEMD160), and MUST have a hash value equal to the hash over the third-party certification with all unhashed subpackets removed. =20=20=20 * The attestation MUST be cryptographically valid, verifiable by the primary key of the certificate in question. =20=20=20 =20=20=20 What this means is that a third-party certificate will only be accepted/distributed by the keystore if: * the keystore knows about both the first- and third-parties. =20 * the third-party has made the identity assertion =20 * the first-party has confirmed that they're OK with the third-party certification being distributed by any keystore. =20=20=20 FIXME: it's not clear whether the "ksok" notification is necessary -- it's in place to avoid some accidental confusion with any other use of the Third-Party Confirmation signature packet type, but the author does not know of any such use that might collide. Key Server Preferences "No-modify" =2D--------------------------------- {{RFC4880}} defines "Key Server Preferences" with a "No-modify" bit. That bit has never been respected by any keyserver implementation that the author is aware of. This section effectively asks an abuse-resistant keystore to treat that bit as always set, whether it is present in the certificate or not. Client Interactions {#client-interactions} =2D------------------ The multi-stage layer of creating such an attestation (certificate creation by the first-party, certification by the third-party, attestation by the first-party, then handoff to the keystore) may represent a usability obstacle to a user who needs a third-party-certified OpenPGP certificate. No current OpenPGP client can easily create the attestions described in this section. More implementation work needs to be done to make it easy (and understandable) for a user to perform this kind of attestation. Side Effects and Ecosystem Impacts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Designated Revoker {#designated-revoker} =2D----------------- A first-party-only keystore as described in {{first-party-only}} might decline to distribute revocations made by the designated revoker. This is a risk to certificate-holder who depend on this mechanism, because an important revocation might be missed by clients depending on the keystore. FIXME: adjust this document to point out where revocations from a designated revoker SHOULD be propagated, maybe even in first-party-only keystores. Certification-capable Subkeys =2D---------------------------- Much of this discussion assumes that primary keys are the only certification-capable keys in the OpenPGP ecosystem. Some proposals have been put forward that assume that subkeys can be marked as certification-capable. If subkeys are certification-capable, then much of the reasoning in this draft becomes much more complex, as subkeys themselves can be revoked by their primary key without invalidating the key material itself. That is, a subkey can be both valid (in one context) and invalid (in another context) at the same time. So questions about what data can be dropped (e.g. in {{non-append-only}}) are much fuzzier, and the underlying assumptions may need to be reviewed. If some OpenPGP implementations accept certification-capable subkeys, but an abuse-resistant keystore does not accept certifications from subkeys in general, then interactions between that keystore and those implementations may be surprising. Assessing Certificates in the Past {#in-the-past} =2D--------------------------------- Online protocols like TLS perform signature and certificate evaluation based entirely on the present time. If a certificate that signs a TLS handshake message is invalid now, it doesn't matter whether it was valid a week ago, because the present TLS session is the context of the evaluation. But OpenPGP signatures are often evaluated at some temporal remove from when the signature was made. For example, software packages are signed at release time, but those signatures are validated at download time. Further complicating matters, the composable nature of an OpenPGP certificate means that the certificate associated with any particular signing key (primary key or subkey) can transform over time. So when evaluating a signature that appears to have been made by a given certificate, it may be better to try to evaluate the certificate at the time the signature was made, rather than the present time. When evaluating a certificate at a time T in the past, one approach is to discard all packets with a creation time later than T, and then evaluate the resulting certificate from the remaining packets in the context of time T. However, any such evaluator SHOULD NOT ignore "hard" OpenPGP key revocations, regardless of their creation date. (see {{revocations}}). =20=20=20 If a non-append-only keystore ({{non-append-only}}) has dropped superseded ({{drop-superseded}}) or expired ({{drop-expired}}) certifications, it's possible for the certificate composed of the remaining packets to have no valid first-party certification at the time that a given signature was made. Such a certificate would be invalid according to {{RFC4880}}. OpenPGP details =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This section collects details about common OpenPGP implementation behavior that are useful in evaluating and reasoning about OpenPGP certificates. Revocations {#revocations} =2D---------- It's useful to classify OpenPGP revocations of key material into two categories: "soft" and "hard". If the "Reason for Revocation" of an OpenPGP key is either "Key is superseded" or "Key is retired and no longer used", it is a "soft" revocation. An implementation that interprets a "soft" revocation will typically not invalidate signatures made by the associated key with a creation date that predates the date of the soft revocation. A "soft" revocation in some ways behaves like a non-overridable expiration date. All other revocations of OpenPGP keys (with any other Reason for Revocation, or with no Reason for Revocation at all) should be considered "hard". The presence of a "hard" revocation of an OpenPGP key indicates that the user should reject all signatures and certifications made by that key, regardless of the creation date of the signature. Note that some OpenPGP implementations do not distinguish between these two categories. A defensive OpenPGP implementation that does not distinguish between these two categories SHOULD treat all revocations as "hard". An implementation aware of a "soft" revocation or of key or certificate expiry at time T SHOULD accept and process a "hard" revocation even if it appears to have been issued at a time later than T. User ID Conventions {#user-id-conventions} =2D------------------ {{RFC4880}} requires a user ID to be a UTF-8 string, but does not constrain it beyond that. In practice, a handful of conventions predominate in how User IDs are formed. The most widespread convention is a name-addr as defined in {{RFC5322}}. For example: Alice Jones But a growing number of OpenPGP certificates contain user IDs that are instead a raw {{RFC5322}} addr-spec, omitting the display-name and the angle brackets entirely, like so: alice@example.org =20=20=20=20 Some certificates have user IDs that are simply "normal" human names (perhaps display-name in {{RFC5322}} jargon, though not necessarily conforming to a specific ABNF). For example: Alice Jones Still other certificates identify a particular network service by scheme and hostname. For example, the administrator of an ssh host participating in the {{MONKEYSPHERE}} might choose a user ID for the OpenPGP representing the host like so: ssh://foo.example.net Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document offers guidance on mitigating a range of denial-of-service attacks on public keystores, so the entire document is in effect about security considerations. Many of the mitigations described here defend individual OpenPGP certificates against flooding attacks (see {{certificate-flooding}}). But only some of these mitigations defend against flooding attacks against the keystore itself (see {{keystore-flooding}}), or against flooding attacks on the space of possible user IDs (see {{user-id-flooding}}). Thoughtful threat modeling and monitoring of the keystore and its defenses are probably necessary to maintain the long-term health of the keystore. {{designated-revoker}} describes a potentially scary security problem for designated revokers. Note that there is an inherent tension between accepting arbitrary certificate uploads and permitting effective certificate discovery. If a keystore accepts arbitrary certificate uploads for redistribution, it appears to be vulnerable to user ID flooding ({{user-id-flooding}}), which makes it difficult or impossible to rely on for certificate discovery. TODO (more security considerations) Privacy Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Keystores themselves raise a host of potential privacy concerns. Additional privacy concerns are raised by traffic to and from the keystores. This section tries to outline some of the risks to the privacy of people whose certificates are stored and redistributed in public keystores, as well as risks to the privacy of people who make use of the key stores for certificate discovery or certificate update. TODO (more privacy considerations) Publishing Identity Information =2D------------------------------ Public OpenPGP keystores often distribute names or e-mail addresses of people. Some people do not want their names or e-mail addresses distributed in a public keystore, or may change their minds about it at some point. Append-only keystores are particularly problematic in that regard. The mitigation in {{only-revocation}} can help such users strip their details from keys that they control. However, if an OpenPGP certificate with their details is uploaded to a keystore, but is not under their control, it's unclear what mechanisms can be used to remove the certificate that couldn't also be exploited to take down an otherwise valid certificate. An updates-only keyserver ({{updates-only}}) avoids this particular privacy concern because it distributes no user IDs at all. Social Graph =2D----------- Third-party certifications effectively map out some sort of social graph. A certification asserts a statement of belief by the issuer that the real-world party identified by the user ID is in control of the subject cryptographic key material. But those connections may be potentially sensitive, and some people may not want these maps built. A first-party-only keyserver ({{first-party-only}}) avoids this privacy concern because it distribues no third-party privacy concern. First-party attested third-party certifications described in {{fpatpc}} are even more relevant edges in the social graph, because their bidirectional nature suggests that both parties are aware of each other, and see some value in mutual association. Tracking Clients by Queries {#tracking-clients} =2D-------------------------- Even without third-party certifications, the acts of certificate discovery and certificate update represent a potential privacy risk, because the keystore queried gets to learn which user IDs (in the case of discovery) or which certificates (in the case of update) the client is interested in. In the case of certificate update, if a client attempts to update all of its known certificates from the same keystore, that set is likely to be a unique set, and therefore identifies the client. A keystore that monitors the set of queries it receives might be able to profile or track those clients who use it repeatedly. Clients which want to to avoid such a tracking attack MAY try to perform certificate update from multiple different keystores. To hide network location, a client making a network query to a keystore SHOULD use an anonymity network like {{TOR}}. Tools like {{PARCIMONIE}} are designed to facilitate this type of certificate update. Keystores which permit public access and want to protect the privacy of their clients SHOULD NOT reject access from clients using {{TOR}} or comparable anonymity networks. Additionally, they SHOULD minimize access logs they retain. Alternately, some keystores may distribute their entire contents to any interested client, in what can be seen as the most trivial form of private information retrieval. {{DEBIAN-KEYRING}} is one such example; its contents are distributed as an operating system package. Clients can interrogate their local copy of such a keystore without exposing their queries to a third-party. Cleartext Queries =2D---------------- If access to the keystore happens over observable channels (e.g., cleartext connections over the Internet), then a passive network monitor could perform the same type profiling or tracking attack against clients of the keystore described in {{tracking-clients}}. Keystores which offer network access SHOULD provide encrypted transport. Traffic Analysis =2D--------------- Even if a keystore offers encrypted transport, the size of queries and responses may provide effective identification of the specific certificates fetched during discovery or update, leaving open the types of tracking attacks described in {{tracking-clients}}. Clients of keystores SHOULD pad their queries to increase the size of the anonymity set. And keystores SHOULD pad their responses. The appropriate size of padding to effectively anonymize traffic to and from keystores is likely to be mechanism- and cohort-specific. For example, padding for keystores accessed via the DNS ({{RFC7929}} may use different padding strategies that padding for keystores accessed over WKD ({{I-D.koch-openpgp-webkey-service}}), which may in turn be different from keystores accessed over HKPS ({{I-D.shaw-openpgp-hkp}}). A keystore which only accepts user IDs within a specific domain (e.g., {{scoped-user-ids}}) or which uses custom process ({{exterior-process}}) for verification might have different padding criteria than a keystore that serves the general public. Specific padding policies or mechanisms are out of scope for this document. User Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D {{client-interactions}} describes some outstanding work that needs to be done to help users understand how to produce and distribute a third-party-certified OpenPGP certificate to an abuse-resistant keystore. IANA Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document asks IANA to register the "ksok" notation name in the OpenPGP Notation IETF namespace, with a reference to this document, as defined in {{fpatpc}}. Document Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \[ RFC Editor: please remove this section before publication ] This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by e-mail to the author. Please direct all significant commentary to the public IETF OpenPGP mailing list: openpgp@ietf.org Document History =2D--------------- substantive changes between -00 and -01: * split out Contextual and Non-Append-Only mitigations * documented several other mitigations, including: - Decline Data From the Future - Blocklist - Exterior Process - Designated Authorities - Known Certificates - Rate-Limiting - Scoped User IDs * documented Updates-Only Keystores * consider three different kinds of flooding * deeper discussion of privacy considerations * better documentation of Reason for Revocation * document user ID conventions =20 Acknowledgements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 This document is the result of years of operational experience and observation, as well as conversations with many different people -- users, implementors, keystore operators, etc. A non-exhaustive list of people who have contriubuted ideas or nuance to this document specifically includes: * Antoine Beaupr=C3=A9 * Jamie McClelland * Jonathan McDowell * Justus Winter * Neal Walfield * vedaal * Vincent Breitmoser * Wiktor Kwapisiewicz --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXKlkzQAKCRB2GBllKa5f +CmRAP43x06bh9x0xKRNrJgRtAVR9yOLECgEN4d3DcFHowAIvQEA8aGA4BWV2md4 ESiyDFFWrZxRPxcKIQ02QYevGDV16wA= =tDfx -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Apr 8 10:06:45 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0612002F for ; Mon, 8 Apr 2019 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theintercept.com 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 CAMrEhNKiJoh for ; Mon, 8 Apr 2019 10:06:41 -0700 (PDT) Received: from mail.newconews.org (central-mail01.newconews.org [8.25.220.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7740E1200FA for ; Mon, 8 Apr 2019 10:06:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.newconews.org (Postfix) with ESMTP id A515A409274 for ; Mon, 8 Apr 2019 17:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=theintercept.com; s=ticom20140908; t=1554743200; bh=lLxelfNbi4fIW5FNrghPwqzwivbMeV1TqzFT2mz6XdU=; h=Subject:To:References:From:Date:In-Reply-To; b=GJxRdUoqWYsovs4ogDk3g3fOVTXw3VdxF3L2ECbKLzVZWhHIF5mayOz7LNs/LuWp2 8Zl3DyrOUFrrwfDFmjq/Y5q45SY2ExDRVMJ/UBMk97j86jlmlihI2y3R0PNEYYDdvt oHS8J8t/mANnCuvQrTEmvCh1FJl53qPY/2LXPyEA= Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.newconews.org (Postfix) with ESMTPSA id 67CB7409273 for ; Mon, 8 Apr 2019 17:06:40 +0000 (UTC) To: openpgp@ietf.org References: <87v9zt2y2d.fsf@fifthhorseman.net> <8736mu350z.fsf@fifthhorseman.net> From: Micah Lee Openpgp: preference=signencrypt Message-ID: <2885d227-9dc4-c393-d259-fcbfd52a5c71@theintercept.com> Date: Mon, 8 Apr 2019 10:06:36 -0700 MIME-Version: 1.0 In-Reply-To: <8736mu350z.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gktkq8N0okL20Pm5HbVMx4lMV1hqESHjR" X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 17:06:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gktkq8N0okL20Pm5HbVMx4lMV1hqESHjR Content-Type: multipart/mixed; boundary="PyO0UX5dKzOdjqRH89XzS9iqJApRzGOAg"; protected-headers="v1" From: Micah Lee To: openpgp@ietf.org Message-ID: <2885d227-9dc4-c393-d259-fcbfd52a5c71@theintercept.com> Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver References: <87v9zt2y2d.fsf@fifthhorseman.net> <8736mu350z.fsf@fifthhorseman.net> In-Reply-To: <8736mu350z.fsf@fifthhorseman.net> --PyO0UX5dKzOdjqRH89XzS9iqJApRzGOAg Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/6/19 7:47 PM, Daniel Kahn Gillmor wrote: > On Thu 2019-04-04 18:41:14 -0400, Daniel Kahn Gillmor wrote: >> I've documented some thoughts on how to resist this abuse in a new >> Internet Draft: >> >> https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-= keystore/ Hey dkg, thank you for putting in the work to write this draft. It's very necessary, and I think you lay out the problems and mitigations well. Here is some feedback. In section 2.2, the draft says: "If the keystore does not offer a discovery interface at all (that is, if clients cannot search it by user ID), then user ID flooding is of less consequence." I completely agree with the (unfortunate) sentiment that searching by user ID is not appropriate for key discovery, because user ID flooding is trivial. However supporting some advanced querying of data in the keystore, including by user ID, may be useful for non-key discovery reasons, like to determine if someone else is impersonating your certificate. I also think it's worth adding a mitigation that specifically deals with this SKS Keyserver bug [1], probably in section 3. There is never a legitimate reason for a certificate to contain a user ID packet with a signature that doesn't verify, or with a signature that verifies using any key other than the certificate's primary key. If such user ID and signature packet pairs are found, they should always be rejected. The same (I believe) is true for revocations, except in the case where there's a "designated revoker" (I have never used this feature of OpenPGP, so I could be wrong here). Any revocation and sig packets, where either the sig doesn't verify, or verifies but isn't signed by either the primary key or the designated revoker key, should also always be rejected. Otherwise, people can abuse the keystore by fake-revoking other people's keys (which SKS is currently vulnerable to). I also think that it might be reasonable to add a section about user interfaces, specifically to avoid the issue that this SKS Keyserver pull request [2] tries to fix. (This PR was approved in June 2018 but has not been merged, and no releases have been made since then; the project appears to be abandoned.) At the moment, SKS keyserver provides a web interface that the public often uses for key discovery, as well as to link directly to their PGP certificates (for example, journalists provide these links in their Twitter bios). But this interface shows users provably-malicious data (like user IDs and revocations with signatures that don't verify). If an abuse-resistent keystore wishes to provide a UI at all, as opposed to just an API, then the UI should focus on protecting users from abuse, and make it clear that certificates don't necessarily belong to the people or email addresses in the User ID packets, and, if the keystore doesn't reject malicious user IDs and revocation certificates, make it clear that all of the information displayed about the key might be inaccurate as displayed through that UI. But, perhaps a better option is that the keystores should not provide a UI at all, and instead only provide an API. Also, as others have pointed out in this thread, I think that hosting a keystore using modern distributed blockchain technology is a good idea, and one of the few genuinely useful uses of blockchain technology. Storing data in a blockchain is also much more reliable than keyservers that periodically sync with some set of other keyservers, because every keystore will have an exact copy of all data, rather than various keystores having various different states of the data. Section 5 is dedicated to "non-append-only mitigations", which wouldn't work with a blockchain. However I think that all of these mitigations could be applied at _query time_, which would allow the keystore itself to be append-only, but still provide users with the same resistance against abuse as if this data was dropped at write time. Finally, I found a few typos saying "certiifcate" instead of "certificate= ". [1] https://bitbucket.org/skskeyserver/sks-keyserver/issues/41/web-app-displa= ys-uids-on-keys-that-have [2] https://bitbucket.org/skskeyserver/sks-keyserver/pull-requests/59/add-dis= claimer-to-html-template-educating/diff --PyO0UX5dKzOdjqRH89XzS9iqJApRzGOAg-- --gktkq8N0okL20Pm5HbVMx4lMV1hqESHjR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkn9BnX7ILC8UnBvRQDwmV82ZT3MFAlyrf5wACgkQQDwmV82Z T3MOyg//YHqBynIq5SPqoeKfUjzZglqaryUNO6vzbHv8KuQ6M/ulOb/g0qXKIIMG XdofGse4xXuF4XJwIJ3ZNCnWqs2Tn3dWZcRyEzyx9gADU1eeN2iGFdElMUI/7T0R AWIQ2FFK8VkYTIzSVnexr8A3dHZGKxfLjsM0KDGAmv1b5FwtcH1s1vMsKee9Eq3I bxJF81q+PcSOIjVRr8kUI71DosAtchjCb+QrDWf/LwwpgZAgh94oBvTG5BjFjvgj kGQ0GOqtl/kzCRV20CPa3s9FqqMFGOH6huYTLeq87QEXPzoEYnQpDblqvNBIapDR D54UzMv29pr6C2erUftMAXDKhksMm4O9zgVmCbYQlkmXAV0gWLS5Ol+a7ZkAGVWD +xZCjp6LZPrtlGvQAGrcWoTduMaD2ds05RBqXV3Tdf85kLTw+dh/SSiYBbS8EwtW E67lH2W8kViKtEJM5aMwAXW/+36roUzDxCSycZ8Q+cECDtuqwq1zMpBZIA+4UEoq 9AyngOM1stc143XbLcqkukdXmcf7q2m17gXpLknaudGlQs2O8rzCRORxgYX8ClEF s2mXygmncWHIf2uIoVyqj/aM9cP0BfYfCtc5WzOOAQK44Ml6bHzbPBfAf/jQBNpN h5vR+OQp1PvPT2Be2HkArRo5xa6YP0Q+PV5tvI9ZsBNcwTgMi88= =jU9a -----END PGP SIGNATURE----- --gktkq8N0okL20Pm5HbVMx4lMV1hqESHjR-- From nobody Mon Apr 8 13:15:05 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25D412044C for ; Mon, 8 Apr 2019 13:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 l33aX_Mtq8TF for ; Mon, 8 Apr 2019 13:15:01 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0B3120421 for ; Mon, 8 Apr 2019 13:15:00 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id v14so10534229lfi.0 for ; Mon, 08 Apr 2019 13:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v1cBj3+563F4jgujwamquOi/xKfm5ym3uwjuxuOPM90=; b=Obr/oo3ITFHM1DNWPUQhVKpEEWKDGRhMsDWMyZ8RClsHhiAktNqzRR6VfWnQc6hRiJ 07b1LDETA2HhrNsfNDIwojvE+8Ofc1PSB5QCDYL+/TyUTgtC/9ZkoKmcoevXwhfXkvOC QS61XAFtDGUIEIR2zmF6TlDyzwnaYWUxV2tRGyEzNHRs2zYOPBUkYdIBBC6ZPKrdJasf V61R1Gy1tTMigUdNZtVvVtP9ygMfigfpiEp3LkOKwj+qKY/RqLoFLpG375HcoIUdHlS2 rfs4xjMb/MOixlV+tS5EbpW+NpTVMZUixrc6lnyIPKEw/FdjMF7bs/8NKhgv8CAPsNAR ZzTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v1cBj3+563F4jgujwamquOi/xKfm5ym3uwjuxuOPM90=; b=Enm2YLJdxNrA46wUNTjwGMhgumspzilCtHQvoHzau17on2Cwgxq6ExCsOjUM7K1utF 657Ge8KjnCcTk7iMPG9zHxztPI/Z/1c+QsxqTfF7C8C4u24NbMTlgs6g2/7dg9Lb1lvY qOd04lnDqQDQXDh793GqOGChEh9jDUFU9P1tFU2yoVVIZ7SPdEBxxCOV6qUMIHccuYF/ kbSRmqzhiKMHqe7IK9kJr9VMuXIeDwfxg3UguWXTTyz4PIx3gxRuFqhsLimxksn0YVJG /VXw8A76Tix3V3iNwiGlIyqgZYaVflQbTRpvt6QrAg3/GKpKR/H9sZjJ30XcAuztgsWJ ZBYA== X-Gm-Message-State: APjAAAXMUOC4ZhMmGNLGS7Qp/xdZD6440ag2DxNiM6aWDTg2YPHVzAaw AwTX++Na8DP4Qa7A0QLle3hbAbNTXNeKTNmHLx1uT2bYPV4= X-Google-Smtp-Source: APXvYqxUhBOBMJjklSpjm9FWUXx45hLylsNHjVh+qaErLWqdLbO0D/wZtPMLTrzvSNydnwuCDBdguuZd2Ltw0HasNCw= X-Received: by 2002:a19:7503:: with SMTP id y3mr16892992lfe.83.1554754498315; Mon, 08 Apr 2019 13:14:58 -0700 (PDT) MIME-Version: 1.0 From: Nils Durner Date: Mon, 8 Apr 2019 22:14:47 +0200 Message-ID: To: openpgp@ietf.org Content-Type: multipart/mixed; boundary="000000000000970b7d05860a7dd4" Archived-At: Subject: [openpgp] [PATCH] Updated S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 20:15:04 -0000 --000000000000970b7d05860a7dd4 Content-Type: text/plain; charset="UTF-8" Hi, please find the patch for updated S2K attached. It's essentially the content of https://gitlab.com/ndurner/rfc4880bis-s2k/tree/master/misc/id/rfc4880bis plus the Normative Reference updated and now being diff'ed against git://git.gnupg.org/people/wk/rfc4880bis.git Comments? What else is needed to get it into the official draft? Best regards, Nils --000000000000970b7d05860a7dd4 Content-Type: application/octet-stream; name="rfc4880bis-s2k-20190408.diff" Content-Disposition: attachment; filename="rfc4880bis-s2k-20190408.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ju8skc2b0 ZGlmZiAtLWdpdCBhL21pZGRsZS5ta2QgYi9taWRkbGUubWtkCmluZGV4IDg0NTQyMDEuLmQzYTdl OWEgMTAwNjQ0Ci0tLSBhL21pZGRsZS5ta2QKKysrIGIvbWlkZGxlLm1rZApAQCAtMjU0LDYgKzI1 NCw3IEBAIHJlc2VydmVkIHZhbHVlczoKICAgICAgICAgICAgMSAgU2FsdGVkIFMySwogICAgICAg ICAgICAyICBSZXNlcnZlZCB2YWx1ZQogICAgICAgICAgICAzICBJdGVyYXRlZCBhbmQgU2FsdGVk IFMySworICAgICAgICAgICA0ICBBcmdvbjJpCiAgIDEwMCB0byAxMTAgIFByaXZhdGUvRXhwZXJp bWVudGFsIFMySwogCiBUaGVzZSBhcmUgZGVzY3JpYmVkIGluIHRoZSBmb2xsb3dpbmcgU2VjdGlv bnMuCkBAIC0zMzgsMTEgKzMzOSw1MiBAQCBldmVuIHRob3VnaCB0aGF0IGlzIGdyZWF0ZXIgdGhh biB0aGUgb2N0ZXQgY291bnQuICBBZnRlciB0aGUgaGFzaGluZyBpcwogZG9uZSwgdGhlIGRhdGEg aXMgdW5sb2FkZWQgZnJvbSB0aGUgaGFzaCBjb250ZXh0KHMpIGFzIHdpdGggdGhlIG90aGVyCiBT MksgYWxnb3JpdGhtcy4KIAorIyMjIyBBcmdvbjJpCisKK1RoaXMgZW1wbG95cyB0aGUgcGFzc3dv cmQgZGVyaXZhdGlvbiBzY2hlbWUgQXJnb24yLCB3aGljaCBpcyBtZW1vcnktaGFyZAorYW5kIHJl c2lsaWVudCBhZ2FpbnN0IHNpZGUtY2hhbm5lbCBhbmQgdHJhZGUtb2ZmIGF0dGFja3MuCisKKyAg ICAgICBPY3RldCAgMDogICAgICAgIDB4MDQKKyAgICAgICBPY3RldHMgMS0zMzogICAgIDMyLW9j dGV0IHNhbHQKKyAgICAgICBPY3RldCAzNDogICAgICAgIG9uZS1vY3RldCBwYXJhbGxlbGlzbSB2 YWx1ZQorICAgICAgIE9jdGV0cyAzNS0zOTogICAgNC1vY3RldCBtZW1vcnkgc2l6ZSB2YWx1ZQor ICAgICAgIE9jdGV0cyA0MC00NDogICAgNC1vY3RldCBpdGVyYXRpb24gY291bnQKKworVGhlIHNh bHQgdmFsdWUgY29ycmVzcG9uZHMgdG8gdGhlIG5vbmNlIHBhcmFtZXRlciBvZiBBcmdvbjIuIFRo ZQorcGFyYWxsZWxpc20gdmFsdWUgZGV0ZXJtaW5lcyBob3cgbWFueSBjb21wdXRhdGlvbmFsIGNo YWlucyAodGhyZWFkcykgY2FuCitiZSBydW4uIEEgcGFyYWxsZWxpc20gZGVncmVlIG9mIDEgaXMg UkVDT01NRU5ERUQuIFRoZSBtZW1vcnkgc2l6ZSB2YWx1ZQoraXMgdGhlIG51bWJlciBvZiBraWxv Ynl0ZXMgb2YgbWVtb3J5IHRvIGJlIHVzZWQgd2hlbiBkZXJpdmluZyB0aGUKK3Bhc3N3b3JkLiBU aGlzIHZhbHVlIE1VU1QgYXQgbGVhc3QgYmUgOCAqIHBhcmFsbGVsaXNtIGRlZ3JlZS4gVGhlCitp dGVyYXRpb24gYWNjb3VudCBzcGVjaWZpZXMgdGhlIG51bWJlciBvZiBwYXNzZXMgb3ZlciBtZW1v cnkuIFRvIHByb3RlY3QKK2FnYWluc3QgdHJhZGUtb2ZmIGF0dGFja3MsIDMgaXRlcmF0aW9ucyBh cmUgUkVDT01NRU5ERUQuCisKK090aGVyIHNlY29uZGFyeSBpbnB1dHMgdG8gQXJnb24yIGFyZSBu b3QgdXNlZDogc2VjcmV0IGtleSBLIGFuZAorYXNzb2NpYXRlZCBkYXRhIFggTVVTVCBiZSBwYXNz ZWQgd2l0aCAwLW9jdGV0IGxlbmd0aCB0byBBcmdvbjIuCitUaGUgdGFnIGxlbmd0aCBwYXJhbWV0 ZXIgdG8gQXJnb24yIHRoYXQgZGVzY3JpYmVzIHRoZSBsZW5ndGggb2YgdGhlCitkZXJpdmVkIHN5 bW1ldHJpYyBrZXkgTVVTVCBiZSBlcXVhbCB0byB0aGUga2V5IHNpemUgb2YgdGhlIHN5bW1ldHJp YworY2lwaGVyIHRvIGJlIHVzZWQuIFRoZSB2ZXJzaW9uIHBhcmFtZXRlciB2IE1VU1QgYmUgc2V0 IHRvIDB4MTAsIHRoZQordHlwZSBwYXJhbWV0ZXIgeSB0byAxLCB0aHVzIHNwZWNpZnlpbmcgdGhh dCB0aGUgQXJnb24yaSB2YXJpYW50IGlzIHRvIGJlCit1c2VkLgorCisjIyMjIyBOT04tTk9STUFU SVZFIE5PVEVTCitJbXBsZW1lbnRhdGlvbnMgY2FuIGltcHJvdmUgbWVtb3J5IGJhbmR3aWR0aCB1 c2FnZSBieSBjaG9vc2luZyBsYXJnZXIKK3BhcmFsbGVsaXNtIGRlZ3JlZXMgdGhhbiAxLiBUaGUg bnVtYmVyIG9mIG1lbW9yeSBibG9ja3MgdG8gYmUgdXNlZCBpbgorQXJnb24yIGlzIGludGVybmFs bHkgcm91bmRlZCBkb3duIHRvIHRoZSBuZWFyZXN0IG11bHRpcGxlIG9mCis0ICogcGFyYWxsZWxp c20gZGVncmVlLiBUaGUgaXRlcmF0aW9uIGNvdW50IGNhbiBiZSB1c2VkIHRvIHR1bmUgcnVubmlu ZwordGltZSBpbmRlcGVuZGVudGx5IG9mIHRoZSBtZW1vcnkgc2l6ZS4KKwogIyMjIFN0cmluZy10 by1LZXkgVXNhZ2UKIAotSW1wbGVtZW50YXRpb25zIFNIT1VMRCB1c2Ugc2FsdGVkIG9yIGl0ZXJh dGVkLWFuZC1zYWx0ZWQgUzJLCi1zcGVjaWZpZXJzLCBhcyBzaW1wbGUgUzJLIHNwZWNpZmllcnMg YXJlIG1vcmUgdnVsbmVyYWJsZSB0byBkaWN0aW9uYXJ5Ci1hdHRhY2tzLgorSW1wbGVtZW50YXRp b25zIE1VU1QgZ2VuZXJhdGUgUzJLIHNwZWNpZmllcnMgdGhhdCBpbmNsdWRlIHNhbHRzCisoZWl0 aGVyIHR5cGUgMSwgMyBvciA0KSwgYXMgc2ltcGxlIFMySyBzcGVjaWZpZXJzIGFyZSBtb3JlIHZ1 bG5lcmFibGUgdG8KK2RpY3Rpb25hcnkgYXR0YWNrcy4gVHlwZSAxIE1BWSBvbmx5IGJlIGdlbmVy YXRlZCBpZiB0aGUgc3RyaW5nIGlzCitlbnRpcmVseSByYW5kb20gYW5kIHRoZSBzYWx0IGlzIHVz ZWQgYXMgYW4gSVYuCitVc2Ugb2YgQXJnb24yaSBpcyBSRUNPTU1FTkRFRCBhcyBpdCBvZmZlcnMK K3Byb3RlY3Rpb24gYWdhaW5zdCBtYXNzaXZlLXBhcmFsbGVsIGFuZCBzaWRlLWNoYW5uZWwgYXR0 YWNrcy4gV2hlbgorcmVhZGluZyBTMksgc3BlY2lmaWVycyB0aGF0IGRvIG5vdCBpbmNsdWRlIHNh bHRzLCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxECitpc3N1ZSBhIHdhcm5pbmcgYWJvdXQgcG90ZW50 aWFsbHkgaW5zZWN1cmUgbWV0aG9kcyBiZWluZyB1c2VkLiBXaGVuCityZWFkaW5nIFMySyBzcGVj aWZpZXJzIG90aGVyIHRoYW4gQXJnb24yaSwgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBpc3N1ZQor YSB3YXJuaW5nIGFib3V0IG91dGRhdGVkIG1ldGhvZHMgYmVpbmcgdXNlZC4KIAogIyMjIyBTZWNy ZXQtS2V5IEVuY3J5cHRpb24KIApAQCAtMTgwMyw5ICsxODQ1LDkgQEAgZm9sbG93aW5nIFN5bW1l dHJpY2FsbHkgRW5jcnlwdGVkIERhdGEgcGFja2V0LCBmb2xsb3dlZCBieSB0aGUgc2Vzc2lvbgog a2V5IG9jdGV0cyB0aGVtc2VsdmVzLgogCiBOb3RlOiBiZWNhdXNlIGFuIGFsbC16ZXJvIElWIGlz IHVzZWQgZm9yIHRoaXMgZGVjcnlwdGlvbiwgdGhlIFMySwotc3BlY2lmaWVyIE1VU1QgdXNlIGEg c2FsdCB2YWx1ZSwgZWl0aGVyIGEgU2FsdGVkIFMySyBvciBhbgotSXRlcmF0ZWQtU2FsdGVkIFMy Sy4gIFRoZSBzYWx0IHZhbHVlIHdpbGwgZW5zdXJlIHRoYXQgdGhlIGRlY3J5cHRpb24KLWtleSBp cyBub3QgcmVwZWF0ZWQgZXZlbiBpZiB0aGUgcGFzc3BocmFzZSBpcyByZXVzZWQuCitzcGVjaWZp ZXIgTVVTVCB1c2UgYSBzYWx0IHZhbHVlLCBlaXRoZXIgUzJLIHR5cGVzIDEsIDMgb3IgNC4KK1Ro ZSBzYWx0IHZhbHVlIHdpbGwgZW5zdXJlIHRoYXQgdGhlIGRlY3J5cHRpb24ga2V5IGlzIG5vdCBy ZXBlYXRlZCBldmVuCitpZiB0aGUgcGFzc3BocmFzZSBpcyByZXVzZWQuCiAKIEEgdmVyc2lvbiA1 IFN5bW1ldHJpYy1LZXkgRW5jcnlwdGVkIFNlc3Npb24gS2V5IHBhY2tldCBjb25zaXN0cyBvZjoK IApAQCAtNDcyNCw4ICs0NzY2LDcgQEAgU0hPVUxEIGJlIHJlamVjdGVkLgogICAgIE1EQyBNVVNU IGJlIHVzZWQgd2hlbiBhIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGtleSBpcyBwcm90ZWN0ZWQgYnkK ICAgICBFQ0RILiAgTm9uZSBvZiB0aGUgRUNDIG1ldGhvZHMgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQgYXJlCiAgICAgYWxsb3dlZCB3aXRoIGRlcHJlY2F0ZWQgVjMga2V5cy4gIEEgY29tcGxp YW50IGFwcGxpY2F0aW9uIE1VU1Qgb25seQotICAgIHVzZSBpdGVyYXRlZCBhbmQgc2FsdGVkIFMy SyB0byBwcm90ZWN0IHByaXZhdGUga2V5cywgYXMgZGVmaW5lZCBpbgotICAgIFtdKCNpdGVyYXRl ZC1hbmQtc2FsdGVkLXMyayksICJJdGVyYXRlZCBhbmQgU2FsdGVkIFMySyIuCisgICAgdXNlIFMy SyBzY2hlbWVzIHRoYXQgbWFrZSB1c2Ugb2Ygc2FsdHMgdG8gcHJvdGVjdCBwcml2YXRlIGtleXMu CiAKICAgICBTaWRlIGNoYW5uZWwgYXR0YWNrcyBhcmUgYSBjb25jZXJuIHdoZW4gYSBjb21wbGlh bnQgYXBwbGljYXRpb24ncwogICAgIHVzZSBvZiB0aGUgT3BlblBHUCBmb3JtYXQgY2FuIGJlIG1v ZGVsZWQgYnkgYSBkZWNyeXB0aW9uIG9yIHNpZ25pbmcKZGlmZiAtLWdpdCBhL3RlbXBsYXRlLnht bCBiL3RlbXBsYXRlLnhtbAppbmRleCBmNzE3OWM1Li5jNTUwMjQ4IDEwMDY0NAotLS0gYS90ZW1w bGF0ZS54bWwKKysrIGIvdGVtcGxhdGUueG1sCkBAIC03Niw3ICs3NiwxMyBAQAogICAgICAgICA8 ZW1haWw+ZGVyZWtAaWh0ZnAuY29tPC9lbWFpbD4KICAgICAgIDwvYWRkcmVzcz4KICAgICA8L2F1 dGhvcj4KLSAgICA8ZGF0ZSBtb250aD0iT2N0IiB5ZWFyPSIyMDE4IiAvPgorICAgIDxhdXRob3Ig ZnVsbG5hbWU9Ik5pbHMgRHVybmVyIiBzdXJuYW1lPSJEdXJuZXIiIGluaXRpYWxzPSJOLiBELiI+ CisgICAgICA8YWRkcmVzcz4KKyAgICAgICAgPGVtYWlsPm5kJiM0MztyZmM0ODgwYmlzQG5kdXJu ZXIuZGU8L2VtYWlsPgorICAgICAgICA8dXJpPmh0dHA6Ly9uZHVybmVyLmRlPC91cmk+CisgICAg ICA8L2FkZHJlc3M+CisgICAgPC9hdXRob3I+CisgICAgPGRhdGUgbW9udGg9IkFwciIgeWVhcj0i MjAxOSIgLz4KICAgICA8YXJlYT5TZWN1cml0eTwvYXJlYT4KIAogICAgIDxhYnN0cmFjdD4KQEAg LTEwMCw2ICsxMDYsMTcgQEAKICAgICAgICAgPGRhdGUgeWVhcj0nMjAwMScgbW9udGg9J05vdmVt YmVyJy8+CiAgICAgICAgIDwvZnJvbnQ+CiAgICAgICA8L3JlZmVyZW5jZT4KKyAgICAgIDxyZWZl cmVuY2UgYW5jaG9yPSdBcmdvbjJpJworICAgICB0YXJnZXQ9J2h0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaXJ0Zi1jZnJnLWFyZ29uMi0wNCc+CisgICAgICAgIDxm cm9udD4KKyAgICAgICAgPHRpdGxlPlRoZSBtZW1vcnktaGFyZCBBcmdvbjIgcGFzc3dvcmQgaGFz aCBhbmQgcHJvb2Ytb2Ytd29yayBmdW5jdGlvbjwvdGl0bGU+CisgICAgICAgIDxhdXRob3Igc3Vy bmFtZT0iQmlyeXVrb3YiIGluaXRpYWxzPSJBLiIgLz4KKyAgICAgICAgPGF1dGhvciBzdXJuYW1l PSJEaW51IiBpbml0aWFscz0iRC4iIC8+CisgICAgICAgIDxhdXRob3Igc3VybmFtZT0iS2hvdnJh dG92aWNoIiBpbml0aWFscz0iRC4iIC8+CisgICAgICAgIDxhdXRob3Igc3VybmFtZT0iSm9zZWZz c29uIiBpbml0aWFscz0iUy4iIC8+CisgICAgICAgIDxkYXRlIHllYXI9JzIwMTgnIG1vbnRoPSdO b3ZlbWJlcicvPgorICAgICAgICA8L2Zyb250PgorICAgICAgPC9yZWZlcmVuY2U+ICAgICAgCiAg ICAgICA8cmVmZXJlbmNlIGFuY2hvcj0nQkxPV0ZJU0gnCiAgICAgICAgICAgICAgICAgIHRhcmdl dD0naHR0cDovL3d3dy5jb3VudGVycGFuZS5jb20vYmZzdmVybGFnLmh0bWwnPgogICAgICAgICA8 ZnJvbnQ+Cg== --000000000000970b7d05860a7dd4-- From nobody Mon Apr 8 16:15:38 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C45120125 for ; Mon, 8 Apr 2019 16:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=UppMrXlq; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=51RrltTP 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 htj9e3da5JgN for ; Mon, 8 Apr 2019 16:15:33 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61C4120123 for ; Mon, 8 Apr 2019 16:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rqZuf3kMi2WDa6OprTdbL4qiCWC4rSTwil//boUg+ro=; b=UppMrXlqfxpmnWsPp/AojYvF4i eHEy3feooYmbsE5yPKhMzxpsYDfFSNiLKzjznVNb3sGwI1qNc2ETHbZ0pkhTfS1mzKBp6otQlbhVw kgFJcxdLSqjia/CQOFE+zjcI3OMJRk2mFxKoxu9O0JUaTpq3AHQBzPwXzkIq56c7xDQ4HBBile8bk SgtZR5qMZZFZvS260ARAu4PtCf31cNphzE0tcGtHTVBLH0Kx1oCmI1ziKum48v9IgOAaSzP3iHNRz +JukheQ05Mnk1oFkpv0SvuvWPKhHaolJhnDqkQVwcDV4XRHYKps/3tUFwr5udtiPsJPkjnQ/4+WbF CyF8RqTw==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rqZuf3kMi2WDa6OprTdbL4qiCWC4rSTwil//boUg+ro=; b=51RrltTPXyZ9X/Dgs5ySk7xQA Pgc4h4NmnFhqP2hCL8kqAQT1rmvil/vmn2+msTpT4KGiiWSGmg93b3jvvFCCw==; Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hDcic-0007tG-V8; Mon, 08 Apr 2019 22:26:23 +0000 Date: Mon, 8 Apr 2019 18:26:20 -0400 From: Phil Pennock To: openpgp@ietf.org, SKS development list Message-ID: <20190408222619.GA81055@osmium.pennocktech.home.arpa> Mail-Followup-To: openpgp@ietf.org, SKS development list References: <87v9zt2y2d.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 23:15:37 -0000 On 2019-04-04 at 18:41 -0400, Daniel Kahn Gillmor wrote: > I've documented some thoughts on how to resist this abuse in a new > Internet Draft: > > https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/ Hey, this is good stuff. Thanks. The references section uses my name in the SKS reference. While I certainly wrote much of (a vast majority of?) the SKS operational documentation, I did not write SKS and am no longer at all involved in it. Another person's name should probably go there. The rest of this mail is on just one topic; otherwise it'll get too long. Others are suggesting blockchain approaches. This makes the reason that I stopped volunteering my time and resources to host an SKS instance, and helping others to do so, relevant: people create spamming tools which make it easier for non-technical users to abuse the append-only trust stores; history has shown that this ease-of-abuse barrier-lowering does directly lead to more abuse, including attempts to just spoil the entire keyserver system. In my jurisdiction (and under my own ethical code) the big concern was child porn: not because it's a sane means of distribution, but because of the spoiling effect. Even without graphical-representation attribute packets, there is speech which causes trouble in some parts of the world. Eg, in Europe, folks can insist upon having their own data be removed. This happened, a decade ago, leading Peter Palfrader to shut down his keyserver after receiving a legal demand to delete a key from the keyservers. So locking down towards a "blockchain" approach (with whichever subset of functionality the speaker intends that to mean, usually just a merkle tree), trendy as it might be, risks creating a system where the operators don't dare host the data sets. Financial blockchain systems might be able to bear the risk because once there's money involved, there will be pushback against censorship, but a OpenPGP key blockchain would not have that politically powerful vested interest protection. An append-only system where the operator of a keyserver has no ability to filter what makes it onto local storage would not entice this former keyserver operator back into the fold. It turns out that "ability to resist censorship by governments with global reach" is not directly the biggest threat model and trying to protect against it will hinder protections against the actual abuse observed. As long as OpenPGP client implementations don't get tied into only one keyserver interaction method, and instead keep WKD and other approaches, there are plenty of ways to get keys out there; preferred keyserver annotations help too. Folks who need to bypass extreme censorship will likely need to use private keyserver setups, eg run along SecureDrop by friendly organisations. -Phil From nobody Mon Apr 8 23:13:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14669120772 for ; Mon, 8 Apr 2019 23:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 DgjHcmOTUMJy for ; Mon, 8 Apr 2019 23:10:10 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C711120777 for ; Mon, 8 Apr 2019 23:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wNrdJZQIcOOnfrT7Tu894HrLB/TitJUuS0Ke3xb09Nw=; b=CG7j8fTFXPfd/nPOlUeFNGKwH4 IvorGXM9kKheiUxVVz83JPJ6d1gRlxdnM+bSVsvsudS+jeOH12j5+MpvSw0Yn0qXRM2N/uWRV7rS5 wWKbRcRofTb3H7EVyW6txA/zVmEj1oL95i1X4BOXSeuLn49y2dLVmHhUWsIoSL8LBknk=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1hDjxQ-0006iM-W1 for ; Tue, 09 Apr 2019 08:10:09 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1hDjul-0006ql-5Q; Tue, 09 Apr 2019 08:07:23 +0200 From: Werner Koch To: Nils Durner Cc: openpgp@ietf.org References: Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Nils Durner , openpgp@ietf.org Date: Tue, 09 Apr 2019 08:07:17 +0200 In-Reply-To: (Nils Durner's message of "Mon, 8 Apr 2019 22:14:47 +0200") Message-ID: <875zrnn23u.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Dateline_Meth_Lab_spook_Brute_forcing_NRC_Cyber_attack_MIT-LL_Plume="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [PATCH] Updated S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 06:10:16 -0000 --=Dateline_Meth_Lab_spook_Brute_forcing_NRC_Cyber_attack_MIT-LL_Plume= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 8 Apr 2019 22:14, ndurner=3D40googlemail.com@dmarc.ietf.org said: > 3 Iterated and Salted S2K > + 4 Argon2i I do not think that adding a new S2K algorithm is useful: The major use cases for OpenPGP are public key operations. Here we do not require an S2K algorithm at all. The S2K is used for the Transferable Secret Keys which should be a operations performed with all due diligence: It is better to use a secure channel and best a symmetric encryption based on a full entropy key. Without a pairing algorithm it is often better to write down the key and employ a courier instead of relying on a weak passphrase and resource intensive KDF. The KDF would anyway be needed to be parametrized in a way that it can be used for export or import on a low end machine. This is a case by case decision and we would be better off to not extend the Transferable Secret Keys format with new methods but use the existing OpenPGP symmetric key formats. The other use for an S2K is symmetric encryption. OpenPGP has only basic support for this and does not provide any key management functions for this. Eventual we will need to add such functions to OpenPGP to make symmetric encryption a first class citizen of OpenPGP. Right now the secure choice you have is to use a full-entropy passphrase and store it in a separate symmetric key database. In fact this is a real world use case of gpg. I doubt that a Argon2i is in any way helpful here because it convoys the message that a low-entropy passphrase along with a resource hungry KDF is an alternative for a secure passphrase. > -Implementations SHOULD use salted or iterated-and-salted S2K > -specifiers, as simple S2K specifiers are more vulnerable to dictionary > -attacks. > +Implementations MUST generate S2K specifiers that include salts > +(either type 1, 3 or 4), as simple S2K specifiers are more vulnerable to The SHOULD is there for a reason: Taking a full-entropy passphrase out of a database does not require any salt. It even demands the fastest KDF we can provide. This has been discussed in the past. > + + target=3D'https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-arg= on2-04'> This is not a useful reference: It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Dateline_Meth_Lab_spook_Brute_forcing_NRC_Cyber_attack_MIT-LL_Plume= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXKw2lQAKCRD/gK6dHew1 jfvtAP9P6SYRqteQIHjLu3lt6bJIj3ElMJpY1JHuSznWC1biLQD+NbLztA18cK0q /gu2j6M+766pgP1hVaLPRq3z1qqTnAY= =V1vi -----END PGP SIGNATURE----- --=Dateline_Meth_Lab_spook_Brute_forcing_NRC_Cyber_attack_MIT-LL_Plume=-- From nobody Tue Apr 9 01:23:42 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22DA1201AF for ; Tue, 9 Apr 2019 01:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 r7GBy3Iun4sc for ; Tue, 9 Apr 2019 01:23:38 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8BD120116 for ; Tue, 9 Apr 2019 01:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1554798218; x=1586334218; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VoHbi0DsRXnCcngWH69amwZDtv9aP+cjF0l7fELW96g=; b=av+MA7OQn+ExQkPL7WwBmFrani9Wk9nMlR5rrfmRYuOp3YYhQrUb007t YB+96b3VE7aZRY/gQIyh1nqMS0eJTR25kn6NG33Fm8YJr9kd1cZd8phDt piEMwt423xIDZeQ9AzBaBYxLAkRjGuNV0A/wgSG5GwF4gYtajTBonmR1D 9ha94LR5xiCYHtRgY3Kv7r4t37ObWNmtJaCksHRMTJwALWBPgnh6zedXc NgDzeC15Gh3dF9z54Gin5xtFHJ+AJmMk0zK/AyKBj64tyYlcUWIS5PHeL wZEmfTl9gfBCR1CpB+1ShC5BcbwdHXfWTtdqfwFQh8R3FVYU9dlw34P2t g==; X-IronPort-AV: E=Sophos;i="5.60,328,1549882800"; d="scan'208";a="55406404" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Apr 2019 20:23:34 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Apr 2019 20:23:34 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 9 Apr 2019 20:23:34 +1200 From: Peter Gutmann To: Werner Koch , Nils Durner CC: "openpgp@ietf.org" Thread-Topic: [openpgp] [PATCH] Updated S2K Thread-Index: AQHU7kfLNySHct1n/06RMEm9imFHEqYzWXbMgAAk8jk= Date: Tue, 9 Apr 2019 08:23:34 +0000 Message-ID: <1554798183382.7116@cs.auckland.ac.nz> References: , <875zrnn23u.fsf@wheatstone.g10code.de> In-Reply-To: <875zrnn23u.fsf@wheatstone.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] [PATCH] Updated S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 08:23:41 -0000 Werner Koch writes:=0A= =0A= >The major use cases for OpenPGP are public key operations. =0A= =0A= Are you sure? PGP is pretty much the universal/default standard for passwo= rd-=0A= based file encryption. I have as little data for that as I assume you do f= or=0A= public-key use, but I'd say there's a lot more password-based encryption do= ne=0A= with it than public-key encryption.=0A= =0A= Peter.=0A= From nobody Tue Apr 9 12:27:57 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57C312089D for ; Tue, 9 Apr 2019 12:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 2IZaeyoC9Vtg for ; Tue, 9 Apr 2019 12:27:46 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC02412040F for ; Tue, 9 Apr 2019 12:27:45 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id y13so38544wrd.3 for ; Tue, 09 Apr 2019 12:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=u0GxSI//ZzVQKyJ+oosyhZh2PvOlx5MmpgUaXVAqvzw=; b=b2FPcOXosWfdGBH9gRdE9mSld2gCwu8zAxp9J0QQR22cA3rQnYORE+PUrJ5XtTOuKw EnZ3vnrepfwePIe3T/7XEKjOE9ww1fKHpiy7UYep1FVGFy/75hzgxOtY+MwPUUSNfCAZ ehWgPZioRqZ3L9arI2qsbRKt9fRkg9bElTNdNe1+qde3Cd7wjMKeARzHy80b8YONWiqc ZrasPF6sVtCCrT/Jp/2tMFNtqtUrrQszxsZYKnEqJX/6NM7vFdQWR+6NtTvWkd5DxCkM GINVdAalMKCTWPPyTH6s2SsBakiLDkkKpRA7PeChcX3wn9MchQezjA2gfq22Mn18sEM1 OLdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=u0GxSI//ZzVQKyJ+oosyhZh2PvOlx5MmpgUaXVAqvzw=; b=R2073PU9JkftyFP3Uq0Adz0+lRvzLmnekv+XYUJ/QWuQybH/Z/K/PyXC3ImR62h1pm hKmGNGLNMKJfF02n36KAtznSAqglJu1ej69ZvUcbJ+sENAfUnY88LggxjpVv42GLAjiP Mtdmw+GMHLOWVq2+bHUoqOv4pRFgI1MN+qTQvayke1kJMnhyCqv/jhFLR75Li4U/epBq SVpclMHujqtOit1I5YlHOHFXshr8k8PDb5Wg0Ebon5QbuSgZMy3vE6F/ft0FZE/STr5r xxpURryEL67r1+vdsrgZR1PBGl+yQr7HQKP369M7Fp3enG3KoXXuMDmFu1bpNT+VyjVL PR4g== X-Gm-Message-State: APjAAAX9WsKQXut6ZX4283yHNrAHb1EjkRgi2Yk68taopJdQyxJXcjxC rhPmcRPb/9Zwzhzham/rmIsSJN+P9OU= X-Google-Smtp-Source: APXvYqwcbcaKUPEGebLclLZ+Lhq1uH82Q2UpOrPP+JfI9q2QG30mlcrfo6zx84I9coF7hP3S7IFpew== X-Received: by 2002:adf:ff88:: with SMTP id j8mr24135404wrr.1.1554838063628; Tue, 09 Apr 2019 12:27:43 -0700 (PDT) Received: from nilss-mini-2.fritz.box (x4db6b1cd.dyn.telefonica.de. [77.182.177.205]) by smtp.googlemail.com with ESMTPSA id d3sm36410875wmf.46.2019.04.09.12.27.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 12:27:42 -0700 (PDT) From: Nils Durner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 9 Apr 2019 21:27:41 +0200 References: <875zrnn23u.fsf@wheatstone.g10code.de> To: openpgp@ietf.org In-Reply-To: <875zrnn23u.fsf@wheatstone.g10code.de> Message-Id: <4A046D7E-5E5D-4817-8AEB-C70FE01B37D8@googlemail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [openpgp] [PATCH] Updated S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 19:27:55 -0000 Werner Koch writes: > Right now > the secure choice you have is to use a full-entropy passphrase and = store > it in a separate symmetric key database. I agree that this may be the most secure option if it suits your use = cases, bank account and exists. Anecdotally, I personally like to keep keys in my head - and distribute = them orally face-to-face, if I need. My use cases include backups (kept = on other people=E2=80=99s servers (aka Cloud) and in other people=E2=80=99= s homes), proof of prior art (drafts passed on to a lawyer, = non-digitally timestamped) and ad-hoc data exchange (data stored on = other people=E2=80=99s servers or removable media, key passed on orally = and most of the time without even spelling it out). Far more often than = I like, this is accomplished with encrypted ZIP files, something I would = like to see improved as I believe the ZIP key derivation function is not = remotely up to par with the craft & science practiced at PHC. I do not = see how storing a full-entropy passphrase in a database for use with an = OpenPGP implementation would help with this in a way that would justify = its operational and monetary cost. > I doubt that a Argon2i is in any way helpful here > because it convoys the message that a low-entropy passphrase along = with > a resource hungry KDF is an alternative for a secure passphrase. I=E2=80=99ll be happy to extend my patch in way to make this clear(er), = recommending that the UI/UX reinforces the notion of strong = passwords/-phrases, best to be chosen completely at random. >> -Implementations SHOULD use salted or iterated-and-salted S2K >> -specifiers, as simple S2K specifiers are more vulnerable to = dictionary >> -attacks. >> +Implementations MUST generate S2K specifiers that include salts >> +(either type 1, 3 or 4), as simple S2K specifiers are more = vulnerable to >=20 > The SHOULD is there for a reason: Taking a full-entropy passphrase out > of a database does not require any salt. It even demands the fastest > KDF we can provide. This has been discussed in the past. Right, my mistake then. But what=E2=80=99s the sense in hashing it prior = to using it as per Type 0 either? I=E2=80=99m currently more inclined to = establish another type =E2=80=9E5=E2=80=9C to make raw key use explicit, = as Peter Gutmann suggested in 2015. Any other considerations/opinions/=E2=80=A6 from others? >=20 >> + > + = target=3D'https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-04'= > >=20 > This is not a useful reference: >=20 > It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress. What do you suggest? Revert back to: Argon2: the memory-hard function for password hashing and = other applications ? Best regards, Nils From nobody Tue Apr 9 14:54:51 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368C6120456 for ; Tue, 9 Apr 2019 14:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 VWYO0RuuXtas for ; Tue, 9 Apr 2019 14:54:46 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80BA120454 for ; Tue, 9 Apr 2019 14:54:44 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44f1KX3K8dz4x1B for ; Tue, 9 Apr 2019 23:54:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1554846880; bh=J/armKAxfU3ASk+apZsEb5HfIwvyRpUg3JvJ3YqEmoE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=u1Sb3z2WFvz3GGmdwaScY1n/qS6/Ph64JuDojTyvc0Bc9oT7TrDG57lZdwedfUv1j tpb41HySPen6v+VSXsurc1CVAznss/9oXMkPWo4ykBGWjuBkuDDiupxGcoc6w3aLcR Cshq5syfCRshCZARyxO43LzahX0EFfqmVX2edkhI= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44f1KW1CXDz4wyd for ; Tue, 9 Apr 2019 23:54:39 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44f1KV39VDz4x0g for ; Tue, 9 Apr 2019 23:54:37 +0200 (CEST) Received: from [192.168.142.181] (p5B0491D4.dip0.t-ipconnect.de [91.4.145.212]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44f1KS4D4czysq for ; Tue, 9 Apr 2019 23:54:36 +0200 (CEST) To: openpgp@ietf.org References: <875zrnn23u.fsf@wheatstone.g10code.de> <1554798183382.7116@cs.auckland.ac.nz> From: Marcus Brinkmann Openpgp: preference=signencrypt Autocrypt: addr=marcus.brinkmann@ruhr-uni-bochum.de; keydata= mQINBFZU6WABEADoVonKbB/tV0v25cm39DaSZyN7it70RhTZHLESbpDiHCwiAMi74MK/HB/q VR9LZDkTDF1x5xUnxxMHa2rpxO329dlk5dQFq1iELxIC/yBCEh5HMLT5MkWqwb8UkINYpaFU csQdPvdC2RzZ4Wt5/xX/6mvSnA4g7hSmUKwIiDX6489Fj5jHK3i0UQFnzKty3O7mqSbedTHs ym2q6fPcIlEOvU6unzxJRK4bgfW2NBM6aMqgLeQkKYIkd1Q/OXEWCXC4hQJepak+n34ChIrV RRHIBJ0GHRkEgHQgQUqPLS0fJlMYCaSZFmOAaqmigxVn1ErG3jTnFQPbPkfE5SCssFP2grNV N1ikJzOEpBLYA/4pOaJzSnZ0xx9aKPdUsyBksKmCsLQNiRt4ZTNFpJ2DJ8NbXYAFkrcu15og lrB//CVQj3CfkzUbpyfcwJHAho1K6XaPybI14znuorTJF3ml0qDd3XDkcmnF58s4hfvGHQtz +CEW+85gUF+T9jKLpwNGcNdBhbvdE6d3cSbR7dXeZsxiA4AmqqEhH6SnVmkSqmhX4+k6RksE MrHJnzefTyA4kXIR2QvD60nZXqta35VhhCzIcpkUpxcwABBR7C8nCxiGV7wNmGECgHv+Zl/O hQhWF1Ld1G93xCg7D+Nz0RerRdwtBOUatmCp+2HRTcRXNOW8jQARAQABtDZNYXJjdXMgQnJp bmttYW5uIDxtYXJjdXMuYnJpbmttYW5uQHJ1aHItdW5pLWJvY2h1bS5kZT6JAjgEEwECACIF AlZU6WACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIiwjVpXtiFAHDUP/0PuDwhn Cyn7b2S7Lrn0BBmi3LOS4ioalCZkV6BenkXydeGwJ9CVVix9WEbiLzCz/DHfvz97l/T9lxcM bACc1tX5a+qvqydzKd2eXFnVdH1JaihqdhG7sWYi22H1uWSyWbHd3rBZaDAts5Qialdg+WC0 kHh9pkmmlUE3BIkTaIOA9k4J93hz4QDOEO7xjB9XMOIRuasZ0lOOPraezS/pKLaQHlzPJZfo QEGL3ndn8U1FXZgR2DWhGtbClEvLaNXJ7RYhIlCeEwCwsTuGg48iDYC0+phvj/nwhZV60+Eb lR4Kux4DjY65s4Rp4kIzh51PRE+bLHtULPx1x9X1x5ZekYQdgwf6doBIIauARZFaxI6dt3i+ HSMjpga3k2Xn5iCaf6NeG1J2bh9sEAH7nntibOOp4sT8YR2SiQ5ab8PnDkydwbghUZcJ39a/ CZnN3f1RFeRX6d3zbfULPsf7o0LM/IvNKFvBoVzVb3AVYdhe5FNOE0DfhOe8lpE88ofu+es6 ECGumfR8UEcQc/O4dSyprngxZjjEdgdo5KqUkCEeGM8lVp+EFcmtLME3uqFhsUihk3YfF9Ni vZ0/0ZcLsmMp3zCZ9wS6HWr2UTkYrgc7Nr3YBClDs9W/jurcSPMmpwwhq2ycWaMMMPqULS4c U2vhGKh6JDPqfIfXFQIfhiVwCMx1uQINBFZU6WABEAC3meKoeQn4r37Z1WCvl/lRVgwYLIEw GX94WCZODxPPEy2zTWStj45yv1ZrSI0HyAqssZzXPelOFJzlM8M+iccxIMRgjnnGJJR0YqYU draf1Z2YQk/x2WjYNUg0blChdyeqwBhLAQKtnPOKkTPZBBGzPjsS+JeB8yN5r4vouFGMG+Cm YFUy4oCmcmuUrdLm9NlzM5ituyTJsPG9CDO834e4qlZsNW/yEzyPsYDW0PxJxgEe/WjLsDJ0 aiwaDhBpR8/i2FfEUTGXl+6wvdXR9lhddBoiUCVlNRu9jiKVxv2JVJepcZa9B/atJwcsDAkZ JgnjP0qRybixx/wo14KromgWVBGwpZ89sFEgZF6HcxPMKuWtieIORzs9kb0jpMFi1hW9xi60 UBHikrpDG9MnwA35d1lg/9kUlrF1nqTnyoz43UxntlgQejl6JcBR2Poaaib3ZtCR34yxslFz 4znXBermA2eEvusEmjYJlxPWozW18grbSYUr1tCmjvKZAIMrspVx37+WSm/4fy8Mq9iqhkIw eFQM10GL+fRQOGJTpSY/KiGxmkaTPtj9iaovJOcGAjUzzreGhi4toIrWWULPNKS6vuV4VgMB F4XxIcVqC9I43yzJ6/cYciwL9bxoWQ4EpHuIG3sewvOWbceeDO9j9DRSd9E6GX67NzrruDPX Ooge2QARAQABiQIfBBgBAgAJBQJWVOlgAhsMAAoJEIiwjVpXtiFAHBwP/3x5953X/1jR2Aeg R6oHSF0HAD8kMnKLP5cwLqrOzUpCwqzFGBCbYdvxrWG106jyvcZdUvtBSGd8n1FuE2WrpQrK gNjdRG65cN2kduk/w66Oq57EqSuO/r6OnadG9hgVZ1YP/QUsL6n4oF7coD0CJiH98UyLw1yP 3Em1ONX8ditvMVHNudVC1VoEN1BFjIX9VWqWoU843vPct9wKi6jLYHHAX3UpnEJtfqLHCj55 4s+0yhMhoaAIfNQZWU9iKzldM6Y0j8DJ/YBSThhw9S/TX7mClhXArJ/iPJSr6FPhlQMMcZRQ aSiQu1gDL76I5G03SkBWCnXbSpeNtTeMiSpsA58c8rpr2T4giCiV29FPgEj4We2/jBrBcwWA /XjSLE2RNOnF2G65dVxHAlaCc84lC2+bh9kVU+Tb+9YDWfHyNO+pNk/Lpaef2Kg6ScKmte6+ wVkWQZFTU8mgkHZqFvQk29RnV02phRTM0ryvWWldNgf3vzztS3iyD3GrJCPcxjm24cAflp+7 JfQ4qV/ec598k++HI4r3SfmSFKFcsxh+073p+oVjs5kIHxM0SExdjKewLOE3BKQYjn1r17xW XogKlIGbTEluQ4Odyh4n88/iA8ZLNPKjvjno7UuwBsZyJxdaTOXlQYt+ZRZNfIBSWqv0U9fY tp9qPuy4vCfkycCucIgO Message-ID: <44f92b79-39fa-823e-b84e-ac5937a7e7f2@ruhr-uni-bochum.de> Date: Tue, 9 Apr 2019 23:54:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1554798183382.7116@cs.auckland.ac.nz> Content-Type: multipart/mixed; boundary="------------95FFF33748AAEF7C5BDB07F0" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] [PATCH] Updated S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 21:54:49 -0000 This is a multi-part message in MIME format. --------------95FFF33748AAEF7C5BDB07F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, please see the attached graph of SKS keyserver uploads per month and daily enigmail users (a plugin for thunderbird). It's pretty obvious that Snowden created at least some use of PGP email (although there are signs that post-Snowden activity has peaked and is already stagnating or in decline). >From a standardization point of view, I think Email is a much more important use case than plain file encryption, given interoperability concerns and lack of alternatives. From my experience, PGP is basically synonymous with Email security for people who are familiar with the term at all. Thanks, Marcus On 4/9/19 10:23 AM, Peter Gutmann wrote: > Werner Koch writes: > >> The major use cases for OpenPGP are public key operations. > > Are you sure? PGP is pretty much the universal/default standard for password- > based file encryption. I have as little data for that as I assume you do for > public-key use, but I'd say there's a lot more password-based encryption done > with it than public-key encryption. > > Peter. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann --------------95FFF33748AAEF7C5BDB07F0 Content-Type: image/png; name="graph.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="graph.png" iVBORw0KGgoAAAANSUhEUgAABtgAAAPKCAYAAAAeY16jAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAC4jAAAuIwF4pT92AAAAB3RJTUUH4gwJAR4Papz62wAAABl0RVh0Q29tbWVudABD cmVhdGVkIHdpdGggR0lNUFeBDhcAACAASURBVHja7N1nYBTV1wbwJ23TGy0EAoTeew0QepHe QQUs2BBEFLADFkAsFAuoIAqIFGlKUXovCZDeGxAgJKT3trvJvh/444sYkp07s5tNfH6flMy5 d9rOzs6Ze66ZTqfTgYiIiIiIiIiIiIiIiIj0Ys5dQERERERERERERERERKQ/JtiIiIiIiIiI iIiIiIiIJGCCjYiIiIiIiIiIiIiIiEgCJtiIiIiIiIiIiIiIiIiIJGCCjYiIiIiIiIiIiIiI iEgCJtiIiIiIiIiIiIiIiIiIJGCCjYiIiIiIiIiIiIiIiEgCJtiIiIiIiIiIiIiIiIiIJGCC jYiIiIiIiIiIiIiIiEgCJtiIiIiIiIiIiIiIiIiIJGCCjYiIiIiIiIiIiIiIiEgCJtiIiIiI iIiIiIiIiIiIJGCCjYiIiIiIiIiIiIiIiEgCS+4CIiIiIirL3oNH0KiBB7p3bm+y63jqvA8O HDlZ7jLzXpqJ5k08q+xxuJeSipDwKNy4lYD42wlISk5FQUEhCgoLUVSsho21Cna2trC1tYFb 7ZpoUL8eGjWoh1bNm6JFU0+YmZlV6fMwNy8fQaERuB5/B/G3E3DnbhLy8vNRUFiEgsIiqKys YGtrDVsbG9Ss4YqG9d3R0KMemng2RIc2LaFSWVXp7ddotAiLikFM3E3cvJ2AW3fuIic3D3n5 BSgoLIQZzGBrawN7O1s4OTrAo15dNPSoB8+GHujUrjWcHB14MSMiIiIiIjIAM51Op+NuICKi iuTk5uHy1QDh+E7tW6NundoGXcfU9Az4B4XJbqdd6xbwqFeXB53+07JzcvHElFkoKi5G6xZN MXPqeAwd0AeWlqbxfpZOp8OGrbuwYcvOCpfduHaFSScJyxJ38xYOHjmFy1cDcD3+tnA7ri7O 6N65Awb364UBfXpVmWRTRmYWDhw5hQs+1xASEY2SkhKhdqxVKnTu0AbeXt0xaugAODs5Vont L1arcfzMRZw+74NrgSHILygU+7FnZobWLZqid48uGDN8EBp61OPFjYiIiIiISCFMsBERkV4i ouMw/ZUFwvFffPQOhg7oY9B1nPPWh/C5FiirDXe32vjtp2/g6GDPg07/aT/9ugfrNm37x7/V rVMbT04cjYmjh1XqZyQvvwCLV6zBuctX9Vq+KiXYzl66gl93H4B/cJjibbu6OGPciMGYOXU8 ari6mOT2x1yPx5ad+3Dy3CVoNFpF21aprDC4X28899QktGjqaZLbn5GZhV9++x2//3kCObl5 irffo0sHPD15LPr37sGLHBERERERkUxMsBERkV5MPcF24MhJfPT5N/K+FM3M8ONXK9C1Yzse cPpP02i0GPXki0hNzyjz7/Z2thg/ciienjwW9erWMeq63U5IxBsfLMfNWwl6x1SFBFvsjXis WrcJVwNCDN6Xg70dZk2fgumTx5rMiLbMrGys/2k79h8+BkP/PDEzM8OEUUMxZ9YM1KzhYjKf uZ37D2HTtt3Izcs3eH/dO7fHgjkvoFXzJrzgERERERERCTLnLiAioqouLT0Ta777WXY7z0wb z+QaEYBjZy48NrkGAPkFhdi+9yDGPP0y3vn4S4RHxRplvS76+mHG7IWSkmtVwZad+/HUS28a JbkG3B8B+M3GrZgxeyFu3blb6dvvcy0QE5+di32HjsIY7/7pdDrsP3wcE5+dgws+fpW+/Xfu JuGZOYuw9vvNRkmuAcC1wFBMf2UBNm3bDb5vSUREREREJIYJNiIiqvI++/oH2aW0mjfxxJxZ M7gziQBs33NAr+VKS0tx/MwFzJi9EL//ecKg67R5x168/t4yoyUgjCE3Lx9vfrACX2/YIjzH mByxN+Ix/ZUFOHH2UqXtgx+27MTctz9CVnaO0fvOyc3D6+99gm82/lJpSaazl65g+isLEBV7 w+h9l5aWYv1Pv2Leu58YpBwlERERERFRdccEGxERVWknzl7EqfM+stqwsrLE8g8WmEypNKLK dC0wVPLDfpXKCv17dzfI+hQWFeGdj7+s1CSIIeTm5WPOWx/i7KUrlboe+QWFeOfjL3Do2Gmj 9qvT6fDp2u+xYcvOSj+um3fsxfLV642+HkdOnsPCJSsrPWl86Yo/Xl30IZNsREREREREEjHB RkREVVZ2Ti4++3qj7HbmzJqBFk09uUOJoP/otYeNHNIfNVyVn8vqblIynpv7No6fuVCt9nFu Xj5eXbQUYZExJrE+Op0OH372Nf46cdZofa5Y8z32HDhiMsdk/+HjWLHme6P19+fxM/hgxRqU lpaaxPZHRMfi1UVLq9UIUSIiIiIiIkNjgo2IiKqsL9dtQkZmlqw2Ordvg2emjefOJAJwOyER 532uSY57evJYxdflakAIZsxeiJjr8dVqH5eWluL95auNNm+dvnQ6HT7+8ltERMcZvK/NO/Zi 36GjJnds9h06ip37Dhm8n4CQcHz0xbcmNyIzIjoOH3/xDS+EREREREREemKCjYiIqqSLvn74 8/gZWW042Nth2ftvwtycX4dEALB970HJD/17du2E5k08FV2PHfsOYc5bH1bKvFyG9v3mHbjo 62eS66ZWa/DWh58ZtFSgr18Qvv1xm8ken7U/bDboyMKUtHS89eHn0Gq1Jrn9p877YPveg7wY EhERERER6YFPFImIqMrJyy9QpJTXotdeRH13N+5QIgA5uXk4dFT6PFwzpig3ek2t1mDpyq/w 5bc/oqSkpNrt46sBIdi0bbdJr2PivRR88e2PBmk7Mysb7y1bZdJz6Wk0Wry/fDXUao1B2l+8 Yo3skdeG9tUPWxB/O4EXRSIiIiIiogowwUZERFXO1xu24l5Kqqw2Bnl7YdyIIdyZRP+z79BR FBYVSYrxbOiBPj27KtJ/cmoaZr3+Lg4dO10t969arcGna7+vEuv65/EzCAmPUrzdr37YUiVG Jd65m4Ttew8o3u7Bo6dwLTDU5Ldfq9Xiy3WbeFEkIiIiIiKqgCV3ARERVSV+QWHYe/CIrDZq uLpg8cI53JlE/6PVavHb739Jjps+eQzMzMxk9x8UGolFH65EekZWtd3HW3buw607dxVpy9XF GW1bNUftmq6wsbFBbm4eEpLuISI6TrGRV59/8yN+/WGVIscXAPyDw3Dw6ClF2rK1sUHrFk3h Ua8uHOztUFBYiJS0DIRFxihW3nLTtt0YM3wwatV0VaS97JxcfPXDFkXasrCwQLPGDdHEsyGc nRyh0WiRlZ2NiOg4JCWnKtLH5asBOO9zDf28uvMCSURERERE9BhMsBERUZVRVFyMT778VnY7 H749D64uztyhRP9z4uwlJKemSYpxdnLE6OGDZPe979BRfP7NRmg02mq7f7Oyc7Bl537Z7Xh7 dcPMqRPQvXP7Mv9erFbjxNlL2LxjL27E35HVV0R0LC5d8UffXt0U2Qdfb9gqu41mjRth1vTJ GNyvN1Qqq3/9XafT4WpAMLbtPoBLV/xl9VVQWITtew9g/ivPKbL9W3ftR2ZWtqw2XJyd8PzT kzBm+KDHfoddj7+N337/E/sPH5ddZnXj1l1MsBEREREREZWDJSKJiKjK+O6n7bhzN0lWGxNH D+MDQ6JH/LpHejm8SWOegI21tXCfGo0Wn679HstXf1etk2sAsGPfIcnlNx9mZ2uDVZ+8h29W Ln1scg0ArFUqjB42ELt+/Bovzpwqe7237f5Dke2/4h+M0IhoWW289Mw07PxxLUYM6V9mcg0A zMzM0LNrJ6z7/EN88dE7sLWxkdXnvkPHkJdfIHv7c/PyseeAvJHX/by6449t3+OZaRPKfUGk qWdDvP/mq9ixcS0aetST1Wd4VCwCQsJ5gSQiIiIiInoMJtiIiKhKCIuMwfa9B2W14VGvLhbM eYE7k+ghgaERiIiOkxRjaWmJaRNGCveZkZmFVxYslp10qAry8gvw2+9/Csfb29nix68+xeB+ XnrHWFlZYu4LM/DBgldlrfvVgBBExd6QvQ8279grK37xwrmYM2s6LC31L74xdEAfbPr6U9jb 2Qr3m5uXjwNHTsre/t9+/1NWom7UsIFYu+IDODs56h3Toqkntqz7HM2beMpa922//QEiIiIi IiIqGxNsRERk8tRqDT7+4luUlpaKf+GZm2PZe2/KethKVB39ulv66LVhA/uiTq2aQv1FRMdi +isLERgaIRTfs2unKrV/j546J2tesJVLFqFNy2ZCsZPHjsDMqeNlrf8hmfOmxd9OwBX/YOH4 556aiEljhgvFtmnZDCsWL5S1/gdlJthKS0tlJZI7tW+ND9+aB3Nz6T/bXF2cJSfmHnXB1092 aUsiIiIiIqLqigk2IiIyeT9t34O4m7dktfHcU5PQqX1r7kyihyQk3sOZi76S46ZPHivU3+Hj Z/D8vHdxLyVVKL5Pz67o37tqlXj988RZ4dgJo4bCW2ZJ29denCmrVOCJs5dkvdxw+PgZ4dgm ng3w6vPTZW1//949MEbGXIEx1+MRfztBOP5aYAhS0tKFYq1VKnz8znxYWYlPm13f3Q1vvvq8 cHxJSQlOnb/MiyUREREREVEZmGAjIiKTFnsjHj9vl1derFXzJpj93FPcmUSP2LnvEHQ6naSY rh3bSR5RVVJSgtXrf8KST9dCrdYIrWtDj3pYuWQRwqJiq8z+TUi8h6DQSKFYG2trvPbiTNnr oFJZYcGcWcLxqekZwqMNdTodjpw8J9z3G688/9j51iS1M/s5WKtUwvHHTl8Qjj18TDzBOG3C KNnzqAHAuBFDhEdBAsDxMxd5sSQiIiIiIioDE2xERGSySkpK8NHn30Kr1Qq3oVJZYfkHC2SN ACCqjkTnl5o+RdroteycXMx9+yP8uueA8Lo62NvhqxWL4ehgj9CI6Cqzj4+fEU/MTBw9DDVc XRRZj35e3dHEs4Fw/JkLvkJxIeFRSLyXIhTbslljeHt1U2T7a7i6YOyIwcLxZy9dEYpTqzU4 fcFH+LvrmWkTFDsXn31SvC2/oDBZZU6JiIiIiIiqKybYiIjIZP3y2x+IiJY3WuX1l59FU8+G 3JlEj/j9z+PILyiUFONRry769+6h9/KxN+Ix/ZUFsubgMjMzw6eLF6FxIw9kZmXjzt2kKrOP L18NFI6dMHqYYuthZmaGSWOeEI73CwoVivPxCxLf/lHDFD0Wk8eOEI6NjrsplGAKDo9CQWGR UJ/9vLqjZg0XxbZ/kLcXXF2chWJ1Oh38g8N40SQiIiIiInoEE2xERGSSbick4octO2S10aNL Bzw9aQx3JtEjSkpKsGv/YclxT08aA3Nz/W8f9xw4grtJybLWdd5LM/8eyRQaGVNl9nFBYRFC IqKEYls1b4JmjRspuj7DBvSVdOweFh13E9k5uZLjfAUTbBYWFnhicD9Ft79FU0/hly10Op1Q ktFXRoJx1LCBim6/paUlhg7oIxzvFxgKIiIiIiIieuS3FncBERGZGp1Oh4+/+FZ4riYAcHSw x0fvzIeZmZnJbqdarUFKWjoKCotQVFSEomI1rKwsYa2ygouzM2rVcFVk/iGSrlitRlp6JrJz clGsVkOt1kClsoLKygoqlRWcnRzh6uxcZUuPnjp/GUnJqZI/U2NHDJEU8+arz8M/OAw34u8I reeoYQPx/NOT//7/4LCoKrOP/YNCodGIlbf19uqu+PrUqumKDm1bCs8J5xcUhsH9vPRePjcv H2GCCdEObVrC2clR8X0woG9PXI+/Lbz9g7y9JMX4+omNYFSprNCza0fFt3+Qdy/s/uMvodhr TLD9Q0FhEVJS01BQWIjComKYmZnBxloFB3t7uNWpJWvOv8pWWlqKlLR05Oblo7hYjaJiNczM 7s8L6ehgj5o1XGFvZ8uTgKqEvPwCpGdkoqCwCMXFaqg1GqisrGBjY42aNVxQ09VF+OUTIiIi IoAJNiIiMkF7DhxBQEi4rDbenf8K3N1qm8w2JSWnIjAkHGFRsYiIjkNCYhLSM7IqjKtbpzaa Nm6Itq2ao0uHtujUvnWVfnBnikpKShAYGolrgSEIjYhG3I1bSE3P0CvW2ckRHvXqwrOhB5p6 NkDbVi3QrnUL2NnamPQ2/7rnoOSYCaOGSX6oamtjg8+WvoUZsxdKSpjb2dpgwZxZ/yprGB5V dUawBQomsgCgd/cuBlknr26dhRNs4VGxkhJsYZExKCkpEeqrT8+uBtn+3j264Kdf9wjFSk0W FhUXIyr2hlBfndu3ha2N8teQzu3bwsbaGkXFxZJj427eQlFxMWysrf+T3xPRcTdx+WoArgYE 40b8HaSkpZe7fO2aNdCqRRN0bt8GXt27oFXzJia5Xbl5+QgICUdYZAzCImNwOyERyanpFX52 nZ0c0dSzIVo1b4LOHdqiW6d2cHF2qnLHNSc3D2cu+iI0Ihox1+ORnZOLvPwC2NpYo1bNGmjk UQ/tWrdA5w5tFB9VTMqLuR6P4LBIhEfFIir2OhLvpSA3L7/cGAsLCzSo747mTRqhQ9tW6NKh DVq3aGZyL+jlFxQiIfEe7qWk4l5yKpJT05GTm4ec3Dzk5uVBrdZAo9VCq9XCzMwc1iorqFQq 1HB1Rp1aNeDuVgctmjVGi6aNq2yCPCHxHs5dvoqwyBjcunMXObl5KCouhr2dHdzdasOzoQc6 tm2Frp3aoU6tmvxAEBGR0TDBRkREJiUpORXfbNwqq42hA/pg5NABlb4tKWnpOHjkFM5c9EVE dJxQG/dSUnEvJRWXrvgDAOztbNGvdw+MGzFE8giHjMwsrPzqB+h0OlnbNaR/H8XLtz1w7vJV HDp6Sii2dYtmeGHGFEnn2o69B/HXyXPIyMwS6jM7JxfZObkIj/r/uQLNzc3RpmUz9OnZFd69 uqFtq+Ym9RkLCY9CaES0pBhzc3M8OXG0UH/Nm3hi0dwX8ena7/VavnP7NvjkvTfgUa/uv/5W 0YMyUxIVe10oTqWyQpuWzQyyTt27dMD3m8VK78beiDfK9gNAx3atDbL9Hdq0hLVKhWK1WnLs 9Zu3oNPp9H7oGhN3E6WlpULr2am9YbZfpbJCx3athOZE1Ol0uH7ztsldzx719YYtes3TaGZm ho/ffaPclyE0Gi0OHz+D334/jOi4m5LWIzU9A6k+Gbjg44dvNv6CJp4NMHH0cEwaM7zSk5SF RUU4cvI8Tp67BD/BkbbZObkICAlHQEg4duw7BHNzc3Tv3B6jhg3E8IHeio++L1ar8cHy1Xov P2LIgHJfCEhKTsX3P2/HsTMXHvvyx92kZASHReLg/+5J6tWtg23fr0INVxejHatP134vfH/y QONGDTD3hRkGWb+ExHv46ofNQrHW1tZY9t4bskePRcZcx+Fjp3Hmoq/kkfnA/Zes4m8nIP52 Ak6cvQQAqFOrJoYO6IPJY5+AZ0MPo39G09IzERYVg9CIGMRcv4nrN28Jbdvj7uc6tG2Jfl7d MXLoALjVrqX4+kdEx+Ln7Xv1Xv61F2eWu5+DwyLx3c/bcTUgpMy/p2dk4XZCIq74B+O33/8E cP9FnXWff8gf1kREZBRMsBERkUlZvno98gsKheNr16yBDxbMqdRtiLkejy079+HE2UvQarWK tp1fUIgjJ8/hyMlzaNW8Cea99Ax699BvtEsNVxckp6ZLTq48Kik51WAJtoNHTuH0BR+h2C4d 2+m1XG5ePr7fvAN7DhxR/PgA98trPRgNsGHLTri71cawgX0xfuTQSnlQ86hf9xyQHDO4X29Z I0KnjBuBK/5BOHX+8cdWpbLCq89PxzPTxleLck1SH8g/0LJZE4OVhm3doiksLCyERpbFXo+X tHxkjFiC7UGC2iA/fCwt0bplU6FRfAWFRUhIvIcG9d31Wl509BpwPxFoKO1atxBKsD34bjP1 BNvVgBC9X2iZOHo4vLp3LvNvV/yD8dnXGxB/O0GR9boRfwer1m3Cz9v34rUXZ2LCqKFG3zcZ mVnYtvsP7D98HDm5eYp/713xD8YV/2B8u/EXzJo+GVPGjYCFhYUi7Wu1JeV+f5T9vVV2gm37 3oP4duMvkhPt91LS4OjgYNRj5mBvjz0Hjshqw8rqGmZOHQ8nR+XX/bzPNcnH5YFB3l6yvuvP +1zD1p37ZVe8KEtKWjq27z2I7XsPYkCfnpj/yrMGvX/Lyy/AFf9g+PoF4Yp/kF4vCcj5rAaF RiIoNBLrf9qOQd5emDPraUW3Ly0jS9J50a1T+zL7LyouxmdfbcCBIyelf2fL+C1JREQk+Tcs dwEREZmKg0dP4fLVAFltfPTO6waZu0cfGZlZWL76Ozz54nwcOXnOIMmbh0XF3sDctz/CgsWf 6v2G87TxI2X3GxEdp9ibtA8rKSnBtcAQoVgzMzMM6d+7wuVCI6Ix5fl52LnvkMGPzwNJyanY uut3THhmDmYvXAL/4LBK+4wl3ksRehg2Y8pY2X0vfWveY5N0rZo3wfYNa/DcUxOrRXItOTVN eNRBy2aGKyVnY22N5k0aCW+TlIfyogmmhh71DFpitW1L8QRRjIQko5wRfIY8B9q1biEcK3UU o6nzC/r3tbi0tBTfbNyK2QuXKJZce/Q+4ZMvv8Wri5YiMyvbKNup0Wjxy2+/Y/zMV7Fl537F k2uPSk3PwOffbMSTL74hnGiXKzg8qsx7jCWfrsWqdZuERrG6u9U2+ryrk8c+IbtUoUajxbnL Vw2yfqLzTAL3q02IXodeWbAY899bZpDk2qPOXrqCKbNex7c/blP0vlGt1uDY6QtYuGQlBk+Y iUVLV2LvwSMGTa6V9Zk4cfYiJj8/D1/9sFl43lhDfF7TM7Iwa967Qsm1B/cSRERExsIEGxER mYS09EysXv+TrDamjBuh92gupV2+GoAps17HvkNHZZdglOrMRV9Me3E+AkMjKlx26IC+cHVx lt3nyXOXFN+OsMgY4RKAndq1rnC+hbOXruCF+e8hOTWt0s7zK/7BeHH++7gRf6dS+t+575Dk snXt27REh7atZPft5OiAlUsW/WNEg7m5OV6YMQW/fLeqWs1vc/OW+IP5Jo0MO8qxiWdD4dhb d+7qtZxarRF+SNjUs4FBt7+pjPPsdsJdvZe9IXgOODk6oGYNw5Wga2qE419VPPqyQ7Fajfnv L8fmHfsM3revXxCenfs2bickGrSf2wmJeHbuW1j7/Wajl9iNu3kLz732tuwRWKL3lHeTkv/+ f51Oh0++XIfDx88It+lRz93o21Gvbh308+ou/57trPL3bBqNFv5BYi8MWatU6Ne7h6QYnU6H LTv34+mXFzy2VKChaLVa/Lx9D2a9rsw95OYdezF8yvN495MvcfqCj6Q5ag2hpKQEW3f9jlmv v2u0xP/DgsP+Oao8Ny8fc95aKitBr+9ocyIiIiUwwUZERCbhs69/kPVWdUOPenjz1ecrZd2/ +3k75r79kex5MuRIS8/E7IVLcN7nWrnLqVRWGD9Sfmmqk+cuK74Nvn5BwrHDBvYt9+9XA0Lw 9kefV9rbuQ9zd6uNJgZOIpQlL79A6E1gJUavPdCxXWvMmfU0AKBRg/rYuv4LvPbiTKOPCjC0 u0n3hGMbNzJwgknGuXcvRb+Rq0nJKcJ9NGpg4ASjjASmlJG7oueAoY9/fXc3WKtUBj3+VUV4 VCwKi4oA3E8KL1r6GS76+hmt/zt3k/DSGx8YZEQ4cP/lm6dffrPSRpE92K+frv0e3/283eh9 hzw0Kmbrrt//nktNVGU9sJ82YZT8+yv/IOTlFyi7fyOiUFBYJBTbt1dXSSOV8wsK8fp7y/D1 hi1Gqz5QltCIaMya967sUWZ3k1KQlZ1jctfEsMgYvPzmYqOvW1JyKlLS0v/+/w9WrJE0Yrws Zc3jS0REZChMsBERUaU7cfaS8BwOAGBhYYEVHyyArY2NUde7tLQUy1d/hx9/+c0k9qNarcHC JSsrLEE4ZdwI2WX4QsKjFB8JJjov0P3ykI8vNZSanoF3P/nSJJJrANC/T89K6ffAkZOSRzC4 u9XGIG8vRdfjuacm4e15L2HXpq9klaszZXeTxBNMcua600eD+uJlk/RNBDw8ckSqenUNu/1y ykbpm2BSqzVIS880yeNvbm4u/ODxXnL1SrBptdq/kzAr1nxn1OTaAylp6XjtnY+EExWPc/Do KSxa+pmsOW2V9OMvv2Hzjr1G7fPBqP7ouJv47udfFbh2Vs4D+17dOskud6dWa3ChghewpJLz UtTwQd56L5udk4vZC5dUyuezLIn3UvDKgsVIzxB/qe5x8wOagribt/DuJ6uE5mqV48Eotj0H jihyrlbW55WIiP6bmGAjIqJKlZ2Ti8++3iCrjRdnTq2UB/Ur1nyHfYeOmtT+1Gq1WLT0MyTe e/wDfne32oqUHDotIyn6qLz8AoRERAvFdu3YDrVquj72719+u6lSSt48zoA+PYzeZ2lpKXbu OyQ5btqE0bC0VHZ0mbm5OZ6aNAY21tbV9rqWeE88weRWp5ZB162ujPb1TbDJ2f66dQybYHJ1 cRYfwZWcZvDtN3SCTc45VlBYhOyc3Gr1Wb0WGIp9h47JHt0kx434O/jqh82Ktffn8TP48LOv JZcDNrRvNv5S4Sh7JT1Inq5at0mRF2wqa0SMmZkZpiowf+6p88pWHvC5Jjb/mo21Nfr26qbX svkFhZi9cAnCImNM6lxOSk7FgiWfCo+m69apPZwcHUz2unjFPwg79x82ap/BYVHIyc3Duk3b FGmvMkq6EhHRfxcTbEREVKm+XLdJVmnFNi2b4cUZU4y+3lt3/Y79h4+b5D7Nys7BslXryl1G iZJDSpaJ9AsKFX5btrzykJEx13Hi7EWTOTaODvbo0qGd0fs9fcFX8qgiO1sbTBg1FCTdvRSx 0Z3OTo4GTzy6u9URjk19qIRTeZKSxUe31qld0+DHp65gEkvfUbuixx9AhXNJVvY5kKLnOVBV bN9zUPZLPkrYc+CIXvOoViQwNAKfVPD9X5k+/uJbWeXApYi9cQv7Dh2DX1CoIu1V5pxOY4YP kv3dcNHXX7GRkjm5Fcp60wAAIABJREFUecKlR729uutVcaK0tBQfLF+NqNgbJnkuh4RH4Zff fheKtbKyhLcCL7oZ0g+bdxi19L1fUCi+37xDkeuDs5OjSScwiYio+mGCjYiIKs1FXz/8KWPC eWuVCis+WKD4CJuK+AeH4esNW0x63/r6BeHIyXOP/XvPrh1llxwKDI2QVSLnYaJvQpubm5db amf73oMmdVz69OxaKfONbd97QHLM2BFD+IBCkOiISRdnJ4Ovm6uLeB/ZOXl6Lic+f4urs7PB 90ENF7E+cvPyodPpDHb8jXUO1HB1Nvg5UFUUFRdX6pxOD/t24y+y4rOyc7Bo6WdQqzUmu78z MrPwzcatRunrfhnv9Yq1V5lzOjk5OmDk0P6y2ihWq3HpijJlFq/4BwuPkKxoztwHfvp1D85d vmrS148NW3chIVFsvs1B3r1MetvyCwrx2x9/Ga2/6Lib2KXQqDnOv0ZERMbGBBsREVWKvPwC rFjzvaw23nz1eXg29DDqehcVF+OTL9fp9ZC1sv2wZedjR4UpUXJIp9Ph9AVlykSKzuXRrVM7 1HB1KfNvxWo1zlzwMaljMqAS5l8Lj4pFUGikpBgzMzM8PWkML1SCRMvoGSO5YmFhIZw4zcnV b7uyssUTbM5OjgbfB66CCTadTqfXPIZyyiga4xyQ04e+5wBJFxgagasBIcLxX3z7o1FHnIj6 46+TwkmJylK7Zg2jz/P7qKnj5VceOHFWmcoDV/zF7tnsbG3Qt1fXCpeLu3kLP277zeTPC7Va g03bdgvF9u7RxeRLZe8/fMzkSs3qQ+4LhERERFJZchcQEVFl+HrDVtxLSRWO79WtkyJlDqX6 8ZfduJ2QqFh7TT0bwqNeXbi6OMHB3h7ZOblIz8xCaES0Xg9yy3M7IRHHTl/AyKEDyvz72CcG Y/2mX1FYJF4y6OS5S5gyboSs9UxKThXep+W9Ce0fFKZIOaR6deugdYumqFnDFTbW1ihWq1FU VIyUtHQkp6bh1p1EvcpbWlpaonePLkY/Z7ft/kNyzIA+PSu1HFZVpm8SpixOjvZGWUcXZyeh Mkz6bpdoiSc7WxujjPCUM4ovJzevwgSlnASbMc4BVxkJNrnfS1S+fYeOoUeXDpLjKhq1LlWd WjXRvKknXJ2d4OzkiMKiIqRnZCHm+k2952J8nJKSEvy8fQ+WvjWvyhwXU/g+bNmsMTq1by35 hZmHXfT1Q1FxsezEjuhLUf1699Cr7+Wrv1Nk3rwH916tWzRFnVo14OriAmuVFTKysnEvORWh kTGyR7AePn4GLz0zDfXd3STF2Vhbo0/PLjh13sdkz/u09EwEh0ehc/s2Veo6yvtXIiIyNibY iIjIqG7E38GOfYew79BR4TbGjRiCt+a9ZPR1z8jMws59h2S34+5WG7OmT0a/3j0eO9+ORqOF X1Ao1m3ahojoOOG+/vjrxGMTbI4O9hg5tD/2HTom3L5fUBgys7KFR4QA4uUhLSwsMMj78eUh QyKiZR2ntq2aY9HcF9Gpfetyl1OrNYi7eQsBIeG4FhCCa4GhZSYtu3VqB0cHe6Oes/dSUoXm yps+ZSwvVoJy8/KF3/i2s7U1yjo62NsJxembOBNNMNnaGmeEiJz9rM8+kDOHjDHOAXvB4y93 26qqFk090aNLR7Rp2QyuLs6wt7NFYVExkpJTEB4Vi/OXr+k9P19Fzlz0QVZ2juRRhus2bZPd t62NDaZPGYvhg7zRrHGjxy4XGXMd23b/ISuhd+z0Bbw176VKHxWmL1N5YD913EhZCbbCoiJc uhJQbmntitxOSJQ8p+sDQwf0qXCZCz7XEBwWKXtfdWjbCs8+OQE9unR87Hdebl4+Tl/wwbpN 25CWninUT0lJCQ4fO41XnntKcuwgby+9E2xWVpaoV9cNDT3qob67Gxwd7GFnawt7O1vY2drA 0tIShUXFSM/IxPX42/APClNkzsyA4PAql2BjiUgiIjI2JtiIiMgogkIj8MdfJ3D5aoBwGy7O TliyaG65SRVD2rb7D1mjvQDghRlT8NIz02CtUlX4Q9qre2f07NoRG3/5DRu27BTqzy8oDPdS UlG3Tu0y/z51/ChZCbbS0lKcvuCLSWOGC7fh6yeWYOvWqX25ib24G/HC69SxXWtsWLOswuME ACqVFdq0bIY2LZthxpRxUKs1uBYYgjMXr+DsJd+/56mrjPKQu/Yf1mt03cNat2iKrh3b8aIl KL+gUDjW1sY45aJEH2rru22iI0eN9bDdzk48iaXPd4Ccc8DGCOeAnP1cIGPbqpo2LZth0Wsv lvtwedyIIXjn9Zfx18lzWPv9Zlnz7wH3X665eMUfo4cN1Dvmoq8fwqNiZfXbz6s7Fi+ai9o1 a+j1HfHp4oUYMbgf3vrwcxSr1dLPo8IinL14BSOG9DeZ4+3oYA+dTof8gsJ/lQE3lQTbkP59 sGr9T7JKgZ46f1lWgk109Jq9nS369Ky4POSGrbvkXd9tbbD0rXkYPshbr2M+bsQQDPL2wuIV a3De55pQn3+dPCeUYPP26g4rK8t/jdZzdLBHp/Zt0LZlM7Rt1RyeDT1Qr24dmJtLm+Hl8tUA rPnuZ1yPvy28P6PjbpjctdnCwgIO9nZQqzVlfic3qMcRbEREZFxMsBERkVHskDnyy6t7Z3z8 7ny9Hv4Yglqtwf7Dx2W18e78VySXtTQ3N8fs555CUVERtu76XXKfOp0Ol68GYuLoYWX+vUVT T3Ru3waBoRHC23Xy3CXhBFtpaanwnDPllYcEgKRk8REFi+a+oFdyrSwqlRX69OyKPj274v03 Z+NaYCj+PH4G/Xr3MOo5W1BYJHTOTp/M0WtyaDQa4VibKpBgKikpgYWFRYXXSxHGSrDJ6Uer rThhrZZxDhhjH9jLOP5aiQn7qmr8yCF4/805epUstbCwwJjhg9CtU3vMfftD3LyVIKvvi75+ khJsu37/U1Z/I4b0xyfvzoelpbRHA95e3fH5R2/jzQ9WCM1Le8HXr1ITbF07tsPo4YPQuX1r NKjv/nfyQq3W4G5SMsKjY+EfFIrzPn4mMyLGysoSE0cPE573C7g/Qkyt1kClshKKl1MesqL7 qrDIGFnJYkcHe3z72VJ0bNdactwXH7+DVxcuFbofvp2QiNsJiZLn/nJ0sEf3zh1w+WoAGtR3 x5D+vTGgT0+0bdW8wu9ZffTu0QWd2rfB3Lc/FB75GB130yTO+yH9+2Bwv97o0LblP34L5hcU 4tadBISER+NaYOjf+5KIiMiYmGAjIiKTplJZYf4rz+GpiaNhZmZWaetx7vIVWaWxpk8eK2vO uNdenIkzF68IzVUWHBb52AQbAEwdP1JWgu1aYCiyc3Lh7OQoOTYq9oZQOTlLS8sK38DOzskR 2h5nJ0e0a91CkfPG3NwcPbt2RM+uHY1+zh48clLyfEm1arpi2EBvXnhk0CcB8zhWlsa5NZfT j0arrfDBn2gSxhjzr8ntR58EqpxzwNII54CcPuTOV1QVDOnfG0sWvSZ5tIi7W22s/+JjPPni fFn3C1ISGGnpmcJllgGgTcvmQsm1B/r37oExwwfh4NFTQvcmlaFxIw98+Na8xyZhVCorNG7k gcaNPDB62ECUlpbK+kwrbdKY4di8Y5/k0ekP5OUXwMcvEP0FXvopKSmBX1CoUL/6jCgTOY8e 9vG78yUn1x6wVqnw0TuvY9Jzrwld54LCIiUn2ADguacm4ZlpEwx2n2hna4MP35qHCc/MEYq/ nZCIgsIi2NlWTjlXb69ueP/NVx9bicPezhZtWjZHm5bN8eTE0SgsKqoypWeJiKj6MOcuICIi Uzawby9MHvNEpSbXAODP42eFYxvUd8drL82U1b+lpSXmzJouFBscHlXu3wf3642aNVyE162k pARnL10RihV9MNijS4cKE3pFxcVCbddwda7yn5vS0lKhUaNPThhttCRHdaWRkYCwsDDOrbmc fh4tZVX2MmIjuIx1nbeUMTJAn+Sh1sTPAUMf/6rMrXYtoeTaA+5utbFgzixZ65Cdk4uExHt6 LXv09HnhOR+trCzx8buvy07qzn7+aaHRNon3UoTnvRLl7dUNOzaulZSEMTc3Fx7tZQh169TG gD7yRsSfPHtJKC40IkbyizvA/ZFaXt06V3jdPHb6gvA2jRjSHwP79pK1Xxp61MP4kUOFYkPC xeb97d65vcFfwvJs6AGv7p2F4+WWvhX16vNP45uVSx+bXCsLk2tERFQZmGAjIiKTduz0BcyY vRAx1+MrbR3Uao1wGUMAeOXZJ2FjLX9enQF9ewq1czcpudwHcPdLDg2XtW76TtL+KNFSQxWV hwTEH9anZ2QJP7A0FecuX8Wdu0mSYqxVKllz6dF9JTJK6JmZGefWXDR5oO/2iY72UKIkln7b L57I02fb5JRRNDfCOWAh4/hX9xKR8195Fk6ODrLaGDV0AOq7u8lqIyJavzJ5F339ZK1ns8aN ZO8zd7fa5c5TV57bdxONdmx7dOmANcveV+R+rLJNGTdS9j2CSLLc11/snq1/7x4VJilDI2OE R36am5tj7gszFNm3+oy0K8sdI57LIrp1Ep9bNy+/wOjr+9Iz0/Dys0/yppKIiKoEJtiIiMjk xd6Ix4zZC7Bl5/5KSXyERESXOYm2PurUqqlYyT1rlQrdu7SXHKfVapGcml7uMpPGDJf1cNvX L1DyW80FhUUIDpdeIsrS0lKvt5TtbMXmGcrJzZP1FrUp+HX3Ackxo4cPgouzEy84Msm5RslJ /Ejrx9yg2ye6D4y1/XISmTpdaZU/Bwx9/Kuqxo08hB+uP/odNXPqeJn3PbcqXKZYrZZV3nmG zHV8mLdXN6G4xHspRjm2zk6OWLlkkVFKsBpDz64d0biRh3B8bl4+rgYEC9zrib4UVfHn6op/ sPD2DO7XW3ZS+4FO7VrB0cHeZM9lUc2beArH5hcYN8HWtWM7zH7uKd5QEhFRlcEEGxERVQka jRZfb9iCF+e/j7tJyUbt+1qg+Oi1EUP6KVpyr1ljsR/IySlp5f7drXYtWSWHNBotzl++KinG PyhU6A3qXt066TXCQGROuAc+Xfu9rHltKlNEdBwCQsIlxz09aQwvNAqQk6g2VvLC0HOEiV7z jDXPkZz9rM/xlVOCssQI50BVmCewMkwZO0JW8vFhA73llarTp0RkcFgU1GqxcqxtWjZDU8+G iu070Yf3Fd2bKOWlZ6ahhqtLtTpfp8ocxXbynLQykbl5+QiLjJHcj6ODvV4lEK/JqBQxZvhA xfarpaUlGjdqIDnunpHOZVFyXqAy9gi2hXNfUOxaTEREZAz81iIioiolMDQC0154HUdOnjNa n9GxN4Rje/foqui6uLvVForTZwTe1PGjZK3byXOXJS1vyPKQAODZoL7wtuTlF2DOWx/i3U++ NHpCV67tew9KjunTsyuaeDYAyWdpKSO5UmKcBFtpqYwEix7JM9EkY2mpzijbL6eMpz4JJlM/ B0oMfPyrIgsLCzwxuJ9i7dWpVROtmjcRjtcnwRZz/aZw+317dVN0/0mZI+lh+QWFBj+2NtbW wvNqmbLRwwfBzlZ8vqkzF69Imi/yWmCI0LVzkLeXXnPYxd6IF9oOlcoK3Tq3r/TzWavVCie8 jcHKSnweQWPOvdm5fRu0btGUN5NERFSlMMFGRERVTn5BIZZ+9jXCo2KN0l/czVtCcSqVlfC8 JI8j+ga2Pgm2Hl06yEqyXL4WIOlhmchcHlZWlhjQp6deyzZv6il7fx87fQETn52DDz/7GpEx 103+s5GSlo7jZy5KjpsxZRwvLAqRM8KnpMRYI7jEE1mWFoZLMJWUGOchnpxRYvo8pLQ08XNA zvG3sKieCTY7Wxu4ujgr2mbXjuJzHt1LSa343uTGLeH29RlRJEXNGmL3JsXFxQY/tl06toW9 nW21O2cd7O0wapj4yK3snFz4B4fpf88m+FLU0AF9KlwmKTlVcpnxBzq1aw1bGxuTOJ+LjHA+ VwY5L41IJVpuloiIqDIxwUZERFWSVqvF+8tXo6CwyKD9FBQWCY9gauRRX/G3/UVLmxUXq/Va Tk7JIbVagws+1/RaNjk1DTfi70juw6tbZ73nxvDq3lmRfa5Wa3Dw6Ck8/fKbeO61d/D7nycq ZcJ3feza/6ekN9IBoFnjRujVrRMvKgqRk1wRnetRKjkPAfW5pqkE35QvLDLOw0m1Wm3Q42tl 4udAsYGPP93n2VB8FHV2Tm6Fy4iO+AGgaHlIQDwxXCzjs6gvlYyRO6Zu6nh5ZSJPnNW/8oBI gs3J0QE9ulSczI2TcS43UfhcNvXzWfyakiP+vWdhvASbSqXilwcREVU5TLAREVGVdTshEavX bzJoH3LmB2nUoJ7i6yM1efL3j2M93z4dNWygrDe99Z3Tw9DlIYH7iaNGMspEliU4LBKffPkt hk58Fos/XYsr/sFGmzerIoVFRdh36KjkuKcnj+XFREFySnYZK8FUJNiPtZ4PvmxsrMW2v9A4 CUY5L2bYWFe8D2xlnANFRjgH5Jxn1nz4KeEewEM4VqPRVjgiXHTOJxdnJ1lzlJZ5byKYkOA8 S/I0a9xI1kjJMxd99bqHuZuUjDt3kyS3P8i7l15JeTnzl3kqfJ8HiCfYLEz4fM7IzBaONeYI NiIioqqIryASEZFRLF44B316/v98ZH5BYVjy6VrZ7e4/fBx9enbFIG8vg6x3anqGcGxASARm vrpI0fXJyhZ7A1XfuRcc7O0wcugA7DlwRKifS1cCUFhUVGG5HpEEm0plhX69e0iKeWbaBCxb tU7x86KouBh/Hj+DP4+fQd06tTFy6ABMHvuE8Bx5Sjh87AxycvMkxbi6OGPk0P68QCnI0cFB OLbACPMRAeKjpPR9KO/k6GjU9ZLcj4wEm5Ojg0HPAWPMSSVnPyudmKnO6ru7yYrPyc177Asv JSUlyMzKFj7/lb43EX35pzqPLjOWaRNGSir1+LCMzCz4B4ejewVzmPn6BQq1P2ygt17LpWVk Cm//jn2HcPj4GUX3qWjlCisDn88ajRa3Eu7idkIiklPSkJKWjtT0TOTl5SM3Lx/5BQXQaLXQ aktQWloKMzMzWFlZQmVlJfn+8GHm5kywERERlYcJNiIiMgonR8d/TBo+ethA+PoF4U8FfhQv W7Ue7du0RO2aNRRf73QZP/ozMrOQkZllEvvfzlb/UWnTJowSTrAVFRfjoq9/uXNu6HQ6XA0I kdx2nx5d9S4P+cCY4YPw654/cPNWgsH27b2UVPy8fQ+27tqPQd5emDFlLDq0bWXU46vT6bB9 70HJcVPGjeCIFIVZWVnCztZGaJSUnAdgUogmcfRPsNkLtZ+XXwCtViurzKY+CgrFk1j67ANn J/EEmzHOATmJXCbYpHzvypsXqrxSnumZWdDpxObSK1arERYZYxL7yN7ejieKTAP79kLtmjWE Xwg7ee6SHgk26S9FuTg7VdjuA2kyXma7nZBYbT7zj0pNz4BfYCj8gkIRGhGDm7cThJPZcugz cpuIiOi/jDUZiIio0rzz+suKjPjJys7B0pVfCT9sKo+xHngbmquLk97LNvVsiG6d2gv3dfJc +XN6RMfdFEo8lpe0exwrK0t8/M58o5ShKikpwYmzF/Hs3Lcx/71lwm9Ai7jg64dbd+5KilGp rGTNuUePJ5qEyMzOMcr6iY6E1Xe7nB3FkzDZOYa/5mZmiW2/mZmZXkl+OUmoLCOcA3LOMybY 9CflxZayaMp5kF5d7k1ceD7JZmlpiYljhgvHn77gU+79c2lpqdBLUYP7een9skR1OJ+dHB1g ocBcZZlZ2di57xCen/cOhk16Du8vX439h48j9kZ8pSTXAMDOzpYfNCIionIwwUZERJXG0cEe H70zX5G2fP2CsGPfIcXXsahYXS32tauzs6Tlp44XT7xc9L1W7kTvPteklxqyVqkkl4d8oH2b lnhj9nNG3d/nfa5h0rNz8eMvv0GjMfwDke17DkiOGTG4P2rWcOGFyABEkxDGSK5otVrk5uUL bpeDQbcfADKzsw2+D7JyxPazo4O9Xsl6k0+wZWXLOLcd+AHXk0plJevlDo1G89i/qdWa6nFv 4uLME0UBk8YMFx75m5aeiaCwyMf+PSI6TigBNnSA/nPmFleD81nuuXzrzl0sX70eI6a+gC++ /RFBoZEms21yXxYgIiKq7phgIyKiStWjSwdMnzxWkba+2bgVsTfiFV2/8h5wVRUqlZXkRMrA vj1Rp1ZNof4KCotw+WrAY/9+xV96qaG+vbo+di4afcycOh5Txo0w6n4vVqvx3c/b8cqCxUhL zzRYP9FxN4XeLn9aoc8d/ZvoZycrO6fc5LQS5IxeqlnDVa/l3OrUEu4jJTXd4McnI1MswaRv GWLR4w8AyUbYfjlJvFp6ngOkBLNyv1+qg4dLh5O42jVrYGDfXsLxp8qpPCBSHrKGqwu6dWqn 9/LqanA+i57LObl5WLVuEyY/Pw/7Dh0zyc+2PUewERERlYsJNiIiqnTzXn4GTT0bym5Hrdbg g+VrFH2zW1NJ5ViU/tFvZmYmKcbS0hITRw8T7vNxZSKLiosRGBohub1hA/vK3g/vvTEbT00a Y/T9HxgagVmvv4uk5FSDtC8yeq1n145o0dSTFx8Dca9bRzj2noHOEyXar+/upt/2u4lvf1Jy isGPT3JKmlBcPXf9tqteXdPeftFrkZ2tDUccSaDT6VBaWiocb2X1+BFJxhgZbQz6fqaoYtMm iFceOHX+8WUiRaoODO7nJalcYnU4n+sLnMuBoRGY8vw8bN97sNLKP+qDCTYiIqLyMcFGRESV zlqlwrL33xQub/Ow2Bvx+GbjVuW+KCUmpkzzR7+bUNykMU8IH5MLPtfKTHQGhkRIToDaWFuj b6/usveDmZkZ3p73EhYvnAMba2ujHoM7d5Mwe+ESxecZSc/IwtHT5yXHTZ88jhceA5KXYDFw gi1FToKtrp7bLz4qJfGeYbc/IzNLeISAvtvv4uwEO1sbkzz+cs4Bfbef7lPLHAFvrVI99m8W FlX/Z7xKZaX3qFCqWNeO7dC8iafwNSEsMuZf/55fUIiQiGjJ7UkpD1ldzmePetKuj/sOHcVL b3yAlLR0k94uG2trReaWIyIiqs6YYCMiIpPQukVTzH7uKUXa2r73oFBJm7KoVFZVft82adRA KK5WTVcM8vYSis3Ny8cV/+B//bvIm9DeXt2EH1aXZdKYJ7B3yzr07tHFqMfhdkIi3lu26rFv iYvY9fthyW9+N/Soh769uvKiY0ByRnDduHXHoOuWkJgsY7tqG3z7428nGHT7E++JjxCTkjgV 3Qc3DXz8dTodEpNSDHr86X/fg7n5suLLu/9QWVWPexOzavASkymRUwq7rMoD/sFhkkdW1azh gq4d20qKsaoG53NjCffaew4cwfLV36GkpMTkt8venqPXiIiIKsIEGxERmYznnpqIju1aK9LW kpVrZc0z84CqnDfIq4qmjRsJx8opOXTy3KV//ZtI4lPqm9D6qO/uhvVffITPlr6FZjL2j1SX rwZg78GjirRVrFYLtTVjyjg+1DSwxo08hGNvxBs2wXIj/rZwbIP67not5+riDBdnJ6E+rstY P0O3r+/2yzkHcnLzDDpn492kZBQVFxt8+wmyRyyX9xmqDvcmTRQoDU7/NGrYQDjY2wnFnjp/ WZF7tsH9esPcXNpjJuvqcK+t5/ns6xeElV/9UGW2y97Ojh8sIiKiClhyFxARkamwsLDAsvfe wLQX5qOwqEhWW2npmVi2aj1WL3tPVjuiDyoAYPrksWjUoH6l79fePToLx3bp0BbNm3gi9ka8 5NgLvn7/+P+CwiLJ7dja2MDbq5vB9s3wQd4YPsgbvn5B2L73IC5d8Vd0hFlZ1m3ahicG94Oj g72sdg4fOy05iezk6IDRwwfyYmNgng3qQ6WyEpoPMjruhkHXTXSEXH13N0nnbMtmjcscxVqR O3eTUFBYpOio1YddvymeYGvZrIney7Zo2vixc1Hqcw7UqtnVpI4/ALRs3oQfbgnklH5zsLcr t5SxnHsTb6/u8O7VrdL3T5uWzXiSKMzO1gajhw/Crv2HJcfeTUrG9fjb/0gUBYdFSm5HZM5c Oefz+2++Wun73cxMv3LsGZlZeH/5akXuMy0sLNCqeRN069QOTTwbom6d2qhXtw6cHB2gUllB ZWUFMzMz5OUXIL+gABd9/bBizfcCx8aeHywiIqIKMMFGREQmpUF9dyycOwvLV38nu63TF3yw //BxTBw9TLiNmq4uwrEd27UyyOgrY5s6foTQj/LMrGzcTkhEQ496AMRKn/Xr3d0o86X16tYJ vbp1wr2UVBw5eQ5/nTiHuJu3DNJXTm4edv/xF16YMUW4DZ1Ohx37DkmOmzTmCdja2PBCY+gb bEtLNPVsiMiY65Jjo+NuQK3WGKQ8rVqtEUqWA0AricmV5k08hRJspaWlCI+KRffO7Q1ybMKj YoXinBwdJJVIbNGssfA6hkbGoE/Pria1/SLnwH+dnPn0alRw71Gzhvi9Sd06tWSVEiQTv2cb N1IowQYAQaGRfyfYdDqd5JK9tWvWQOf2baTfa8s4nwf386rw82IqNv7yGzKzsmW10aZlMzw1 aQwG9u0Fe7uKyzc6OtjD0cEedWrXEurPgSUiiYiIKsQSkUREZHImjXkC3l7dFWlr1bpNuJ2Q KBwv50d7cmp6tTgeI4cOFB5tFRga8fd/i5RmM3aCsm6d2nj+6cnYs/lb7Ni4FlPHj5Q90qws R06ekxV/+WqA5FKClpaWskp+kjQtmoolWDQaLSKi4wyyTuHRsZLn7HtAyugtQN5op5DwKINs v1Yrvm9bt2hqlOMP3H/IbSgiI1KA+/OBNW7owQ+2BHLm06toNIyNtbVeD9fLklJN7k2obI0b eaBn146yrw9JyakoKJRWTWLIgD6Sy0P+V+61k1PTsP/wMeF4WxsbfPTO69i+YQ1GDxso/PmX yhgvuREREVXULqzTAAAgAElEQVR1TLAREZFJWrroNeE5fB5WWFSE95atkjxJ+wNSRiz868d0 Slq1OBYPSg6JePhhjdSHjfZ2tujbq2ulbXfrFk3x3huzcWL/Vnz87nw0b+KpWNvX428jIfGe cPy23Qckxwwd0Adugm8wk3Ry5pP09Q8yyDoFBIcLx7Zt1Vza9rdtJdyXz7VAg2x/WGSs8Pxj bVpK2353t9rCn7fA0HDh9SyPWq1BaES0UGzLZk1gacniJ1LEXI8XjtVnPqe6dcTuT+SUrqSq Yco4sZdpgh66Z7sh9FJUH6F+Rc/lqnQ+Hzt9QfgFFxtra2xcuxzjRgwx+nobYjQ9ERFRdcME GxERmaRaNV2xeOFcRdqKiI7DD1t2CsW6ujgLJ/rklOIyNVMFy0k9/LBG6gi2fr17mMTE99Yq FcY+MRi7f/4G6z7/ULFEW1Ss2FxbcTdv4YpAAmbGlHG8sBiRnBKHFx+Zv1Ap532uCcVZWVmi k8SyXw3quws/NA0Oj0JuXr7JbD8A9OzaQXJMN8FzQK3WwC8wVPHt9w8Okzwi5YEeXTrwQy2B VqtFWGS0cHzTxo0qXMazodgcr3E3b8me55ZM24A+PYSuv3fuJiEjMwuA9Pka3WrXQifBF0tE z2UACIuMqRLHRHROTgB47aWZaNe6RaWst5UVE2xEREQVYYKNiIhM1uB+Xhg9bKAibW3ese8f 5QqlEC2LFRYVU20eYnk2FCs5dPNWArJzcv/+bymGDTS9+ev69OyKHRvXYOHcF2Qn/0TeDgeA XwVGr3Vu3wZtWjbjRcWIPOrVFR4BGx4VK2uEY1lS0tKFRy91bNsadrbS5+7r1qmdUH9arRan L/gofkzOXPQVirNWqSQnGAF5SdbjZy4qvv2nzovv017dOvNDLUFoZAzyCwqF41s09axwmSZ6 jHIri0ajNVgZVjINFhYWmDRmuFDsgxejpJahHtK/N8zMzIT6bORRHxYWFkKxfkGhJn88tFot ouPEXqqytLSslJFrD6iYYCMiIqoQE2xERGTS3n79ZVllGh8oLS3F4hVrhEZFiM4lpNFoERgS UW2OxdTxYiWHQsKjUVRcjLtJyXrHONjboXf3Lia5HywtLTFjyjj8sHqZrNI5mdk5kmMyMrNw 5JT0+dumc/RapejRpaNw7F8nziq6Lgf+OgmdTicU69W9k1Bcz26dTGb7A0MjEH87QSi2c4c2 Qgl1Ocf/9AUf4dFmZSksKsKx0+eFYu1sbWSV/PwvOnH2knCsg70dWjareA4/qfMiPuyKfwgP UjU3cfQwWFlJL+saHHY/+Sp1BJucl6JUKis0adRAKDYsMhZ5+QUmfSxu3k6AWq0Riq3v7gYH e7tKW3eWiCQiIqoYE2xERGTSHB3s8fG7byjSVuK9FHz29QbJcV06tBXuc+/Bo9XmWPTv3UMo 2RkYGoGbtxIkPdzv36enyf+o79S+NZ6ZNkE4vkBgdMPuA0ckP6Sp7+6GAX168GJSCQb38xKO 3X3gL+EHco9SqzXYf/i4cLy3V3ehuH5e3YUe8ALA1YAQWXNYPWrnvkOyrn0i3N1qC48czS8o xB9/nVBs+w8dPS38ENqre2fh4/hfVFhUhCMnzwnHd+7QVq/RPJ3bi8/zeODIScWuL2Saari6 YEh/6XOiPRjBJuWFBHe32mjfpqWs9e3coY1QnFarxYEjJ036WMiZk9lKobkvc3Pz+KEgIiIy ECbYiIjI5HXv3F6x+aP+OnFW8oOvrh3FE2xnL13B7YTEanEc7pccekJyXHBYJG4a8U1oYxJ5 ePWAtqRE0vJqtQZ7DhyR3M9Tk8YIl14ieXp16wwnRweh2PSMLOw/fEyR9dh76CjupaQKxbZs 1lh43kEnRwf0kjGKbePWnYpsf3TcTeERRZaWlhg+yFu4bzmx2377Q5Eyw8VqNX76dY9w/CiF SjX/V+w9eBRZAiOUH9C3HHMNVxc08RQb9SM6GpqqlqnjpFceiIyJw527SZIqPgzp30e4POQD oiWFgfsvUJRIvKcyJjnlYtP/Nyee3P5F56IWHPhORET0n8IEGxERVQnzXnoGTQXnG3nUyq9+ QFKy/g+ba7i6oHWLpoI/THX46oct1eY4TBg1VPJIhoCQcCz+dK3eyzs62KNX105VYn+4ujgJ x9raWEta/q+T55Ah8UGLg71dpc7d8V9nZWWJQd69hOO/+3k70jPkPVy7l5KKHzbvEI6Xm1wZ PlA8wXTqvA8uXw2Q1X9JSQmWr14vHN+7e2e4ujgLxw8d0FfWsfvxl92yz8P1m35FSlq6UKyz kyP69uzGD7OEY7Zx6y5ZbQzp31vC+SleSnnDlp1CZbOp6ujUvjVaSSxzrtFoMW7GbEkxSrwU 1aNLR+GXge4mJWPX73+a7HEoKi4Wjs3MysatO3eF40tLS7Hk07XC87qWlpbwg0RERFQBJtiI iKhKUKmssPyDBbBUoFRKbl4+Fq9Yg9LSUr1jhg4QH6l05qKv0Mgjqa4GGH5OFdGSQ1LKQw7s 20vR8pBp6ZmIiI4zyP7IyMwWjnVydJS0/I69ByX3MX7k0Eqdu4PuHwM516r3l6+CVqsViler Nfhg+Rrhh+iWlpYYMbi/rO0f1M9LeBQfACz97Cskp4qX11r/068Ii4wRjh8rM0Ht7lZb1ii+ rbv2w9cvSDj+go8fft1zQDh+xJD+LA+pp8KiIixa+pms+aA6t28Dt9q1jHJvkpScimWr1ht8 vwSFRqJYreYJUkmmCIxik3LPVt/dDe1at5C9ns5OjujRpYNw/DcbtyIq9oZB92VRcTFCwqMk x4nM4fkw0d8QJSUlWLLyK5y56Cvcd0lJKT9EREREFWCCjYiIqoxWzZvg1eefUqStgJBwbN21 X+/l5YxCAIBV6zfhoq+fQfZL3M1bmL1wKV5ZsNjgDxcAYNr4kQZtX84Dw7IcOnYK019ZgPnv LYN/cJiibV/xDxaOre9eR+9lff2CEHsjXtpNnrk5npw4mheOStaxXWu0bdVcOP5qQAiWrPwK Go20JFuxWo33lq1CQEi4cN+jhg5ArZqusrbf1sYGE0cPE45Pz8jCvHc+ERqBtXnHXmzesU+4 74Ye9RSZv3D65LHCsaWlpXj7o88RGBohdH165+MvJD0sf5iFhYWsda9KioqLEfy/uadEZGXn 4LW3P0Z4VKys9Rg3UlpCt0PbVkJzoz5w4uxFfC9jhGt5MrOysfKrHzDr9Xer1Xy0Vc2IIf3g 6GBfJe7Z5JTUVas1WLjkU+GRWhW54OOHaS/Mx8KlKyUnjF2cnWT1vfvAX5K/A7KyczD37Y/w 14mzsvqW8jIiERHRfxVfRyQioirl2Scn4ryPn6wHYQ989/MO9OzaEW1aVvzw26NeXXh17wyf a4HCP/zf+GAFZj/3FJ59cqIiIwIiouOwZed+nDx36e8HqBu27MTaFR8Y9Bh0bHe/5JAhknlO jg7oqXB5yINHTwMAzvtcw3mfa2jWuBHGjxqKEYP7oYari3C7mVnZ+OW334XjGzfSf+4ckREo g7x7ob67m0l9fq8GhCA8Snw0UVp6plDc0VPnEBYZLRTbqEF9DPL2krXd0yePxfvLVwvHHz11 HvdSUvHR26+jUYP6FS4fHXcTn3z5rayRm2ZmZpg1fbIix33q+FHYtvuA8Bw5sTfi8cyrb2Hp W6+hd4+KS+JlZGZh1fqfJM+3+ajnn56syPyFfXp2RaMG9YXLfOXm5WP2wiV4/eVn8dTE0TA3 N6/w++bXPX/gu593yJqX6InB/eBRr+5/4t5Co9Hi+Xnv4ulJYzBr+mRJ3w0nz13GqnWbZI20 BICaNVyERoxOGTcC32z8RbjfjVt3If72Xbz3xiuyEwHA/TKZu/Yfxt6DR/+ee2rzjr2YNGY4 bKytQcZla2ODsU8MxnaBUfD6UDLBNmxgX6z57mfk5OYJxSfeS8Ezc97CBwvmYHA/L9nrU1JS gvM+17B5xz6ERvz/PcTeg0clvXwg915Mo9Hi9Xc/wftvvooRQ8q/RhQVF+PP42exbtM2WXNB PtweERERlY8JNiIiqlIsLCyw7L038OSL81FQWCSrLa1Wi/eXr8HOH9fC1samwuVnTBknnGB7 8EN9/U+/4sCRk5g5dTyeGNxPcum05NQ0nLngi0PHTpf58PzspSuIiI5Dm5bNDHocpo4fhU++ /Fbxdgf27aVoObKwyBjE3074x7/F3byFVes2Yc13P6NHlw4Y2LcXevfoIulBcmhENJas/Ery nGgPWFlZ6j2q6Ub8HVy64i+5j+mTx5nc5/eirx+27f7D6P3uP3xcOHZwPy/ZCbahA/pgw9Zd suZRCQqNxJRZ8zCkfx+MGjoAHdq2+seohMysbASFReKvE2dx+oKv7LfOhw/yRkOPeorsf3e3 2hgzfCD++OukcBvJqWmY+/ZH6N65PcaPHIouHduibp3/H7lTWFSEyJjrOHH2Eg4fOy2rTN+D dR41dIAi229mZoaXZk6VNBflo9RqDVat24Q9B45g8tgn4NW9M5o0agAzM7O/v1+ux9/BRd9r 2H/4OO4mJctaZ3Nzc8x6ejL+S3Q6HbbvPYh9h45hzBODMLBvL7Rq3uRfc/AVFRfjRvwdXPEP wuHjZ3Aj/o4i/T81cYxQeeSJo4dj49bfZD0IP37mAnyuBWDq+JEYP3Ko5MRqXn4BLvr64djp Czjvc+1f15/0jCzsOXAEM6eO541sJZg6fqRBEmwe9erq9ZKavmxtbDBpzBPYvGOvcBuZWdlY tHQlunZsh6cmjYF3r26SP1cx1+Nx8tz975Ky5mz+efteTBw9TK/fDsD9BJujg72sOQ/z8gvw /vLV+OnXPRjUzwutmjeBi7MTtNoS5OX/H3v3HV9Vff9x/H33vdk7EEIIK+y9QZYgUxAUUcE9 Wtuqra3Wals79FdttUOtrdo666xbcVZFGbJl75EQsvfO3ff3RxRFhjk3ARJ9Pf+BR+4533PP 55xzc3Pe5/v91utQfpF27N6nT9duaPHvv6/6IiQHAADHR8AGAGh3OnfqqJ/+8Erd+ed/tLit g4fy9ecHH9OvfvbDb1x27Mih6turp3bsbtkQUHkFRbrrbw/pj/c/ogF9e6lfrx7q2iVdyUmJ io6KlN1mk8/vl8fjVWVVtQqLS5R9ME9bduxWbl7BN7b/0BPP6v67bj+px2Dm1An620OPh/2U 8fG0ZHigY3nj3Q+P+1owGNTq9ZsOz2+UmpykPlnd1b1rhjqmpiglKUEul0tOh11en08VldXa l31QK9dsaNGcTpI0dGD/Zs/J8ezLxm+K9evdU4MH9OHDoq184bZa9ZNrL9eNv/y/FrXj8/n1 zgefHO6ZFR0VKZfTqYbGxla9oRbhcurH37+sVWvww6su1nsfrVCju2UPRqzbuFXrNm6VJDkd DsVER8nt8ai2rj7soRCP5ebrr2nVsH/WWZP07Mtvtng+yKbfWY9KagrqY6KjFApJNbV1Yc/V dywXnXu2umV2/k5er26PRy++/s7heY+cDoeioiJktVjV6Haruqa21beZmpykRQvmhLVubEy0 zj9nZosfXqitq9ejT7+oR59+UV27pGtQv97q0S1TqclJiouNkcNuUygUUqPbo7r6BhUWlyg3 r0Dbd+3Tnv3Z33j+PfHcK1owd0azQwm0noz0tBaNwnA8LR0+/VgWnTdHz7+ypMW/KzZs3qYN m7cpwuXUkIH91LtnN3Xu1FHJiQlyuZyyWa3y+nxqbHSrrKJSBUUl2rs/R1t27FJ5xYkfnqqo bAqML71gfrPei9ls1uABfbR8VcuHit+fk6v9Obmn7NwhYAMAoBl/71MCAEB7dN6cGfrk03Va vmpdi9t6+c13dcboYZo0btQ3LvuzH12pq264tVX2IRgMavO2na0y3OVXLV+1Xtt37W3RvE/f xOlwaO6MKWENXXg8sTHRGjFkQKu15/X69N5Hy5u9fHFpmYpLy/TxyjUn/fydOXVCs5arrKrW kveWGm7/4vPP4UOijZk0bpSGDx6g9Zu2tlqbtXX1LXoi/nh+cOXiI3qHtYbkxARdeuF8PfzE c63WptvjOSnDV00cO1KTzxjdqm2aTCbd+IMrdc1Pbmu1Nn0+/zfeCA5HSlKirr1iERftST7P vurH37+sRcHT1Zcs1Bvvfthq4V/2wTxlH8xr1X2sqKzSC6++rcsvOpeT6jS4YP7sVg/Ypk1u /YAtKTFel190bqvNDdjQ6NbKNRvCGgngRJ58/lUtmDtTEa7mXbdTJ45rlYDtVGsgYAMA4BuZ KQEAoL36zc3Xt8p8IZL0+3v+3qz5nYYO7NfqvaxOhta6MXEiC+fNatX2pkwYI6u19Z79WbZq Xav3sGsN8XGxzT6HXnrjXXm8XkPtpyYnaerEsXxAtEG/vulHbb73xsB+vXXRuWeflLavXLRA Pbtltun9j4mO0i0//v5JaXv44P469+xpbf48/dXPfqSoyAgu2FNk/JgR3zivUnPO2+uuvrjN 7+tTL7za4uG9EeZ5Nnq40jqktFp7Gelp6t2z20l5r5deOL/NzSH7dU2B8VvNXn7qxHGGh4Vv C07GQzwAAHzbELABANqtxIQ4/epnP2qVtiqrqvWbP97XrCHGbv3JtUpJSmzTtVm5ZoO2bN91 UrfRuVNHjR05tNXaa+0nod88wfCQp9NlF54rp8Pxjct5vT799/W3Dbd/wfzZrRpUovVkpKfp puuubrPvLyE+Tn/67c9lsVhOSvt2u03/96ufhjXP1KlgMpl09+03q2Nq8knbxk3XXa0unTu1 2XPg6ksWavyY4Vysp0hSYrx+d8sNrdLWgrkzNW7UsDa9v5VV1Xrh1SUc+NPAbDZrwdwZrdbe WZPGnbT36nQ4dOdtP5XZ3LZvVz31wqvNHkIxwuU87aMLXHbhfPXJ6m5onbKKylYdfhkAgG/l 9yxKAABoz6ZMGKM5089slbY+XfuZnn/lm2/8xMZE647bbjxpN6Fby6noxXbB/Nmt0k58XKyG D2694SErKqu0cu1nbe6YdM/M0KLzmjfPzrsfLWtWr8qvcjmdOm/OdD4Y2rBzz56mWWdNanPv y2az6p7f3aLU5KSTup2e3TL1ix9f2yaPzfXXXKIxI4ac1G24nE7dffvNioxwtbn9P2P0cP2A oSFPGYfdrnt++wvFx8W2Wpu/u+XHSk5MaNP7/eTzr7bqnJFovnmzzmq1BxymTT65ozkMHtBH 115+UZuuZ1V1jaHA+JIL5p22nnljRgzRj79/ueF58/x+vyqrqrl4AAA4AQI2AEC7d/P117Ra j4O/PfyE9mUf/MblRg4dqN/8/Po2XZfV6zdp09adJ3UbZ4wa1io3C6ZMGNuqgeU7Hy5TIBBo U8fD5XTqrttvks3WvN5lz770huFtzJlxZrscgui75rc/v0Hjx4xoM++nKVz7hYYO7HdKtjd/ 9lm6/ppL2tQxuWLRAl2xaMEp2Vbvnt30lzt/2aZ68o0aNkj3/O6WNt9j5NvCYrHont/9QoMH 9GnVdhMT4vTgPb9VdFRkm9336ppaQ0ProfXEx8Vq2qSWjxaQmZGurO6ZJ/39XnPpBZo3a2qb rqmRwNjpcJyWB/R6dO2iu2+/WSaTqVnzTX9dzqF8Lh4AAE6Av6AAAO1edFSkfveLn7RKW16v T7+888/yen3fuOyc6Wfq59dfI5PJ1Cbr0j0zQ1FRJ3ceHbPZrPPmtHzIodae166tDQ9psVh0 x203Nnv+qTUbNmv3vmzD21m8YC4fCO2AzWbVn377c40aNvi0vxe73aY///42TRw78pRu98rF 5+uqi89vE8fjqovP1w3fu/SUbnPk0IH6029vkcNuP+37P2rYYP3tD79q1tC1aDmnw6F7fnfL SRuKs2e3TN1316/bbMgWEx2lzIx0ToTTpDVGHjiVcxH/6mc/atNzHw8b1F/BYLDZyw8Z0Fe3 3PC9U/b+unTupH/c+7vDD1917ZKujPQ0Q20cyMnlwgEA4AQI2AAA3wojhgxotbkN9uzP0QP/ eqpZy1503hz95c7bFOFytpla2O02XbHoPD3zyF/Uo2uXk769+bNbNuRQcmKChg7s22rvp76h UW6Pt00dj7tvv1lTJoxp9jrPvPS64e1MGDPC8E0TnD5Oh0N//+PtuvDcs0/be0jrkKLHH7j7 tM25dd3Vl+j3t/7ktPXk+qI3wXVXn57edBPHjtRjD9x10oflPJHFC+bq73+8nXDtFElOTNCj 9/9Bk88YfVK3M2RAXz31j3vUuVPHNrX/UyaM0QuP3mfo9yFaV/8+Werbq2eL2phxCgMvi8Wi u359k6659II2VceE+Dj99pYb9Jc7bzM8csD558w8JfOxDh3YT08++Kejho012ottx+59XDgA AJwAARsA4Fvj+msubbVA6ekXX9eaDZuateykcaP0zMN/0ZABfU/r/lssFs2eNlmvPPkP3fC9 y05Zz4i42BhNb8FcHNMmn9Gqw5JFRrj00uMP6NafXNtqQ4eGq2Nqsh67/25NnTi22evk5hVo +ar1hre1uJUCZpw6VqtVt9zwPd1x242KjYk+pdueMmGMnvvX31p8o7Wl5kw/U4/df7e6Z2ac 0u1mdc/UU/+8R2dPm3xa979vr5565uG/aMIpHjI0Pi5W9/7+Vt103dWyWq1cjKfA9DPH68XH Hzhl11xmRrqefujPmj/7rNO+70MH9tNjD9yte39/qzqkJHMynGYL580Me93ePbud8h6IJpNJ P7xysR64+/bT/r0uOipS37vsQr3xzMM6Z2b4w1cuXjA3rHCuufW6YtECPfTnO4753WLiOGM9 1jdt28lFAwDACRCwAQC+Nex2m+647cZmz3H1TW6/6z5V19Q2a9nMjHQ9ev9duv3m65XWIeWU 7nd8XKwuv+hcLXnuEd15242nZQL1lgw5NHPqxFZ/P1arVQvnzdIbzzysu359k0YMGXBK62Gz WXXJwnl68fG/q19vYzdTn37ReO+1Xj26auTQgXwItFNnT5us1/7zT5179rSTPuRsj65d9NCf 79C9v7+1zczX1693Tz3/77/pxh9cocgI10ndVlxsjG678Qd69pG/NnvI1pMtMSFO9931a913 16+VntbhpG7LarVq8YK5ev3ph+hFdIr07Jap+++6XXfffvMpD9JjoqN0+83X69/3/UGD+vc5 pdu2222aOXWinnn4L3r0/rtO+0NI+NKMKRPCPhennznhtL3vM0YP10tPPKgrFi1QVGTEKd12 Zka6br7+Gr3z38f0gysWtcrvqslnjNZLT/xds1vxQY8BfXvpsfvv1g3fu/S4fw8N6tdbcbEx zW4z+2CeSsrKuXAAADje31iUAADwbdK7Zzdde/lFeuBf/2lxWyVl5brj3r/r3t/f2qzlTSaT 5s8+S3NnnKn3l67QS2+8q41bdygUCrX6fsZER2ncqGGaOWWCxowYctp7IPTr3VN9e/UwPIxM Rnqa4QDK0Bcdq1UzpkzQjCkTlF9YrPeXLtdHy1dr2849J2V78XGxmn3WJF288Jywhn2rqa3T m+9+ZHg9eq+1f3GxMfr1TdfpikUL9PwrS/TGux+qtq6+1dofOXSgFs6brUnjRspisbS9P0qs Vl16wXzNm3WWXnv7f/rva28rv7C41drPzEjXwnNmas6MKaf8xmxzTRgzQmNHDNGHy1bp2Zff 1Jbtu1r1/Jo/+yydf86s094DpC2y2206Y9RwfbxyjaH5lE5k+OABWjhvpqZOHHfa52odNqi/ nvj7H7Vx6w499/KbWvbpOnm83pNSx6ED+2nGlAk6c/yYNjsP3Hedw27XvFlT9eTzrxped8aU 0zsfWoTLqRu+d6muWHSeXnrjHb3x7kfKyc07KdtK65CiyWeM1qyzJp60nqfJiQm687YbddXi 8/XcK2/q/aUrmv1w31evuzHDh+jcOdOb1RvaYrFo/OjhevO95n/fXL5qvc6bM52LBwCAYzCF TsZdPwAAIEkqLa/Q0uWrtX7TNm3buVuFxaVhtZOSlKhePbuqf+8sjRkxRP1692zVYRVbw3W3 /E4r12wwtM73L79I115+0Sl/r+UVVVq3cYvWb9qm7bv26MDBQ/J6fYbbsVgs6tE1Q8MHD9DY kUM1cujAFoWdjz/7ku5/5ClD6yQmxOnt5x89bfNY4eRoaHRrzYZN+nTtRq1ev1F5BUWG1nc6 HBo6qJ/Gjhyq8aOHt7v5+YLBoDZt26mVaz7T6vUbtWvvAUPBh9lsVp+s7ho7cqjGjRx6ynvv tIYDOYe0Ys16fbr2M23autNwIJKRnqbRwwdr7MihGjN8yHfiM2Lx938a1nxB0VGRWrbkORUW l+qNdz7QslXrDLcTGeHSoP59NHzwAJ01adxJ743Y0s+X5avWac2GTdq6Y4/25+SG9TBQdFSk evXopj5Z3TVy6EANG9xfLqdTaPsef/Zl3f/Ik4bWGTaov/593x/a3L7sPZCjj1es0aZtO7Vt 5x7V1NYZbsNkMikjPU29e3bT4P59NGbEEHXp3OmU70sgENDm7bu0edtO7T1wUAVFJaqsqpbH 45XZbFKEy6XIyAilJiepZ7cuyurRVcMHDzDco66+oVG1dc2vU2REBIE5AADH+x5BwAYAwKlT UVmlvIIiFRaXqqikTPUNDfJ4vHJ7PDKZTHI5HXI4HIqOilRqcpJSkxOVntZB8XGxbXq/fD6/ Js1dpIZGt6H1Xn/6oTZx4z8QCCivoEj5hcUqLa9QWXml6hsa5fV65fX5ZLFYZLfZ5HI5lRgf p8SEOHXu1FFd0ju12k1rn8+vsy+6xvAwPD+8crGuufQCLq5vudq6eh08lK+cQ/kqLatQo9ut hoZG+fx+uZwOuZxORUdHqXNaR2VmdFKnjqltLoRvCa/Xp4N5+crJzVdRSanqGxrV2OiW2+OR 3WZTRIRLkREudUxNVmZGeqtem21BMBhUQVGJsg8eUl5BkerqG5rOgUa3LGazXC6nIiNcSkpM UGbnTly0JtUAACAASURBVMrMSP9O3gxtacD2VVXVNdq974AO5ReqvKJKdfUN8vqaHsRwOR1y Op2KjY5SeloHZaSnKT2tQ5vsHdoc9Q2NOpRfqMLiEhUWl6qmtk4ej0duj1fBYFAOu11Op0MR LpdSkxOVkpyojqkpp3xIbLSeH9x0u1av32RonV/fdJ3OPXtam96vUCikgqISFRSVqLC4RGXl FWpodMvj8crj9cpmtcrhcMjpsCs+LlapKUlKSUpURnqaIlyEwwAAwDgCNgAA0GKfbdmuq264 1dA6A/r20lP/uIfife7t/32sX/7fXwytY7fb9O5/H2vzASwAnAqtGbAB31Yer1eT5iyW2+Mx 9H3jg1eeohcTAADA15gpAQAAaKm3//ex4XXObsVJ3b8NnnnpjbBqSLgGAACa66NlqwyFa5I0 cexIwjUAAIBjIGADAAAt4vZ49P7SFYbWsdmsmn7meIr3uQ2bt4XV62LRgrkUDwAANNvr73xo eJ0506dQOAAAgGMgYAMAAC3y3Mtvqrau3tA6E8aMUGxMNMX73DMvGu+9NmbEEHXPzKB4AACg WbZs36U1G4zNvZYQH6cxIwZTPAAAgGMgYAMAAGErLa/QY8+8ZHi9c2ZOpXifO5RfqI9XrjG8 3sXnn0PxAABAswQCAd374KOG15szfbKsVisFBAAAOAYCNgAAEJZGt1s/ue3/VFffYGi9jqnJ GjdqGAX83LMvv6lQKGRonW6ZnTVmxBCKBwAAmuWP9z+irTt2G17v3LOnUzwAAIDj4DEkAABg WGFxqW7+zd3asXuv4XXnz54ms5lnfCSpprZOb7zzgeH1Fp03VyaTiQICAIAT8ni9uuuvD+n1 ML5vjBo2SBnpaRQRAADgOAjYAADAMS1ftU49umWqY2ry4Z8Vl5bp9bc/0FMvvKr6hkbDbdrt Np03hyehv/DKkvfV0Og2tE5cbIxmT5tE8QAAgCRp647dslqt6pPV/fDP6uob9NHyVXrkyeeV X1gcVruLFzAcNQAAwIkQsAEAgKOEQiH96g9/VU1tneLjYpUYH6f6hgYVFpe2qN0506coIT6O An9u5ZoNhtdZMHeGnA4HxQMAAJKkJ557RR8tX6WoyAglJSYoGAyqsLhEPp8/7DYzM9J1xmiG 9AYAADgRAjYAAHCU7IN5qqmtkyRVVlWrsqq6xW1aLBZdftG5FPcrHvrz7/X+0hV64rmXtWd/ zjcub7NZtXDeLAoHAAAO27Rtp6SmXmtG58Y9nqsuPp/hqAEAAL4BARsAADjKFzdqWtM5M6co Pa0Dxf0Ki8WimVMnaubUiVq+ap0ef/Zlbdy647jLT588XsmJCRQOAABIknLzClRRWdWqbWZm pGvmlAkUFwAA4BsQsAEAgKNsbuWAzelw6JpLL6CwJzB+zAiNHzNCm7ft1GPPvKRlq9Ydtczi 85kLBQAAfOlkPBR13dWXyGKxUFwAAIBvYKYEAADg61r7Zs0Vi85Th5RkCtsMg/r30X13/Vov Pv6AZp016fANrhFDBqh3z24UCAAAHNbaD0WNHDpQUyaMobAAAADNQA82AABwhIrKKuXmFbRa exnpabqMudcM69G1i/7vlz/Vj666WE+98KrOGDWMogAAgCO05kNRdrtNt9zwfYoKAADQTARs AADgCK15o8ZkMun3v/ixHHY7hQ1TWocU/eLH3OwCAABHqqmt04GcQ63W3rWXL1K3zM4UFgAA oJkYIhIAABxh87ZdrdbWdVdfrEH9+1BUAACANvydbezIobrswvkUFQAAwAACNgAAcITW6sE2 bfJ4Xbn4fAoKAABwEmzcuqNV2unSuZPu+vVNMpu5RQQAAGAE354AAMBhXq9PO/fsa3E7E8eO 1J233UhBAQAATpLNrfBQVOdOHfXIX+9UTHQUBQUAADCIOdgAAMBh23fvlc/nb1EbC+bO1M+v v0Y2G18zAAAATgafz6/tu/a2qI3BA/ro3t/dqsSEOAoKAAAQBnqwAQCAw2KjozV6+OCw1k1O TNAff3OzfvnTHxCuAQAAnERen08zpkyQ3W4zvK7dbtO1l1+kh/98J+EaAABAC5hCoVCIMgAA gK/KzSvQ8tXrtXbDZu09kKOikjId6yuDy+nUgL5Zmjl1kqafeYZcTifFAwCcFvc9/IQO5Rca Xs/ldOoOhjVGO1VZVa0VazZo9fpN2rlnn/ILi+X1+o5azmKxqGe3Ljpz/BjNm32WkhMTKB4A AEALEbABAIBv5PX6VFJWrka3W263RxaLWTHR0eqQkiSrld5qAAAAbUEwGFRJWbnqGxrl8XgV DAYVHRWplOREHoQCAABoZQRsAAAAAAAAAAAAgAHMwQYAAAAAAAAAAAAYQMAGAAAAAAAAAAAA GEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDABgAAAAAAAAAAABhA wAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAG AAAAAAAAAAAAGEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDABgAA AAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDABgAAAAAAAAAAABhAwAYAAAAA AAAAAAAYQMAGAAAAAAAAAAAAGEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAA AAAAGEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDABgAAAAAAAAAA ABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAY QMAGAAAAAAAAAAAAGEDABgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGEDA BgAAAAAAAAAAABhAwAYAAAAAAAAAAAAYQMAGAAAAAAAAAAAAGGClBMcWCoVUU1unz7ZsV0xU lPr16SmnwyFJqqiqVm5egcrLK4+5blJivDLS0xQfF3v4Zz6fT1t37FFObp68Pp9SkpPUu2c3 dUxNlslkouAAAAAAAAAAAADtBAHbcZSUVejt/32sV9/6n3r37Kqb0685HLBlHzykV5a8r83b dslmPbqEwwcP0NyZUxQfF6tQKKSS0nI9+/KbWrVuo+w2m8xmszxen7p0TtPMqRM0YcwIWSwW ig4AAAAAAAAAANAOELAdQ0NDozZv26lnXnxd+7JzFQj45fF6D79eWlahHbv2qaa2TvNmTT1q /W6ZnRUXGy1Jqqis1kfLV+u5l5do8IA+Gjaov1wuh/Zn5+qzLTvU6HYrOTFB/ftkUXgAAAAA AAAAAIB2gIDta4LBkPZl5+qjZatUV9+g1JSko4Zw9Hi9CoZCGtC3l376wytP2F5+YbGWvL9U NptVP7r6YvXJ6i67zaai4lI99MRzWrlmg5auWEPABgAAAAAAAAAA0E6YKcGRysortHzVOu3Y s19zZ05RSlLC0QGbx6dgICCXy3HCtgKBgIpKSrVz9z6NGj5YfT8P1ySpQ2qyBg/oI4fDoc3b dsrr9VF8AAAAAAAAAACAdoCA7Su8Xp9WrNmgT9d+pj5Z3TV/9rTjLOeVPxCQ2WRWcWmZcnLz tD8nV7l5BaqsrpHf75ckNTS6VVxaJrfHq/69e8pkPrLcHVKSlZQQr7LySpWWV3AAAAAAAAAA AAAA2gGGiPyKfdm5+uCTT2W2mHXpwnmKcDmPuZzb41Wj262c3Dz99R+Pa8Pm7aqqrlFKSqJm nzVJM6dMUEbnTmpoaFRFZbVsNqtSkhJl0pE94aKjIhUTHaWiklKVllWoU8dUDgIAAAAAAAAA AEAbR8D2ObfHoxffeFslZeU6b8509e7VXXn5hcdc1uP1Kr+wWEUlZYqIcGn6lPHy+fz6cNmn +vODj2rv/hxdufh8JcTHyuv1ymQyyel06Gv5mmxWq2w2qwKBgNweDwcBAAAAAAAAAACgHSBg +9xrb32gLdt2a/TwQZo2aZws5uOPnjlx7AilJCUoLjZGfXv1aArPQiEtmDtDv7/n71q2ar36 ZPXQzCkTZP68nWAoeFQ7wVBIwVBIJpNJ+w4c1E9/9QcOBAAAAAAAAAAA31GxMdE6Z9ZUvfDq W5o1daIuPPdsde7UkcK0QQRsknbt2a833/1QnTt11Pgxw+VyOeX2eOTxeBUMhiQ19Vrz+f2y Wizq3rWL0tM6yGazKTLCdbid+Lg4jR89TPuyD+rgoXzV1tXL5XIpGAyqvq5BCoWO2K7H45XH 7ZHValVSUoIG9O3Vov0oKCrWmg2blZKUqLEjh8pkMnFwDcrNK9DWnXuU1b2renbrQkHCcODg Ie3em62sHpnqnplBQQzIKyjSnv3ZSoyP16D+vSlImNfwnv056piarH69e1KQMOQcyteefdnK SE9T757dKEiYn4N79uWoR7cM9ejK7xIjfH6flry3VJkZ6crqnqnIiAiKYlCj260l7y1VVveu yuqRKZfTSVEMqq2r1/tLVyire6ayuneVw2GnKAZVVlfr4+VrlNWjq7K6Z8pms1GUZiqrqNTe /TnyeLyadMYoChKG0rIK7dmfrWAopPGjh1OQMBSXlmnPvhxZrRaNGTGEgoShsLhEe/blKCLC qRFDBlKQMOQXFmvP/mzFxcZoyIC+FMSgDz75VFGREcrq0VUJcbEUJAzvfbRc8XGxyuqeqbjY GAoShrfeX6rUlGRldc9UTHQUBTHAZrOqtLxCu/dla+jAfvJ6fRSljSJgk7T2sy3acyBHB/MK VFVTo0hXU2hW19Cg/dm5kqQ77n1QUyaM0eTxY5TeMVUup+OodsxmkxIT4uWw2+X2emW1WpSU ECe/P6D8ohKFvhawVdfUqLK6RhEup/r16qGOqckt2o8Vqzfos807lJmRrmuvuEgWi4WDa/QL yMefKudQvs4YNVTnzZ1BQcKw5L2lKiop04SxI3TOzKkUxICPV6xRdU2t+vXuqR9etZiChHUN r1RldY2GDe6vKxcvoCBhePeDZSovr9SY4YN10YI5FCQMb777kUrLyjVhzAjNm30WBTGgrr5B 7324Qv37ZGnhOTPVsUMKRTGotKxCS95bqoH9emnhvJlKTkqkKAYdyi/UB598qiED++r8c2Yq nptShu3Zl60Vqzdo2KD+On/eTEVHRVKUZtq6Y49eev0dVdXU8n0wTBu37NCLr7+jYDBIDcO0 buMWvdj4riIinNQwTKvWblR9wztKTU6khmFavmqdamvr1KNbF2oYhi3bdymtY6rOmzNdfbK6 U5AwrN2wWVk9umrhOTPVg4fww/LJyrXq3bObFs6bqcyMdApikMfj0b+fepFCtHEEbJJSU5J0 9rTJqqquOeLnNq9VZnNTLzCbzSqrxSqvx6tP136m/MJi9evVU3179zhinaLiUjU2uhUdGaHE hHilJCcqLjZGG7fukD8QkNXaVPJgMKjcvEKVV1apb1ZTuNbSbp75BUUym82KiY7SwH69ZSVg C+tmgN1mU1rHVA3qRw+icGzaulMOu03pHTtQQ4OyD+YpMsKl5MQEateCa9jldCo1OYkahmn7 zj1yOh3qkJpMDcO0ccsOOewOdeJ3iWHVNbUym81KSohT76zuyuzciaIYVFBUIklKTkpQn6we 6tQxlaIYFOlyyWRqqmHfXj2UQkhpXCgks8mslORE9e/dk6e+DWhsdCs2Jkr+gJ/fIWGqqa1T THSUAoEANQxTeUWloqMiFB0VRQ3DVFhcoqjICMXHxVHDMOXmFSgi0qXEhHhqGAaXy6m42Gj1 7NaF+oXJ4XAoPjZGWd0zWzzq2HeVzWZVQnysevXoqt49CXrD+V5otZopRBtHwCZpzIghGtA3 S/5A4Iif5xcUKzevQJJ0zSUL1aNrF1ksFr370TK99f7HGj54gC5eOFcpSYny+wPKzs3TqvUb 5XI51D0zQ3Gx0UrrkKKRQwdo2afrtGzVOg3s21sOu005h/K1ZsNm2SwWjR4+6HDwBgAAAAAA AAAAgLaNVEdSTHTUMceBDQVDh+dcSOuQqoT4OElSrx7dtHrdJi1ftU5+v1+9e3aT2+PR6vWb dCivUBPPGKVhg/vLYrEorUOqzp5+prbs2K2HHn9OZ44frQiXS5u27tD+7FyNHDZQ48eM4CAA AAAAAAAAAAC0EwRsJ2CzWZWRntb0/6/0MBs/ergiXC698Opb+uTTtXp/6QrJJMXHxmrOjCma f/ZZ6p6ZIUmKiozQ6OGD9fPrrtEj//mvnnnxDfkDASXExeqsyWdo3qypDN0DAAAAAAAAAADQ jhCwnUBah1Q9+KffHvVzu92mMSMGa/TwQXJ7PCqvqJRJJqUkJ8lmO7qkUZERmjF1gqadeYZK yioUCAQUHxujiAgXRQYAAAAAAAAAAGhnCNhawGQyyel0Kq1DB8kkmU2mEy5vNpuVmpyokCQT 5QMAAAAAAAAAAGiXCNhayCTJZG5+XGYymQjXAAAAAAAAAAAA2jEzJQAAAAAAAAAAAACaj4AN AAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAAAAAAAAAAMICADQAA AAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0AAAAA AAAAAAAwgIANAAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAAAAAA AAAAMICADQAAAAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAAAAAAAAAAMICADQAAAAAAAAAA ADCAgA0AAAAAAAAAAAAwgIANAAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0AAAAAAAAAAAAw gIANAAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAAAAAAAAAAMICA DQAAAAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0A AAAAAAAAAAAwgIANAAAAAAAAAAAAMICADQAAAAAAAAAAADCAgA0AAAAAAAAAAAAwgIANAAAA AAAAAAAAMICADQAAAAAAAAAAADDASgkAHFf1Dqn+oOQuktzFkr9BsrgkW6zkSpUSRzf9a+Kj BAAAAAAAAADw3cFdcQBf8tVK1dul6q1S1RapLlfyVkj+WslXJwV9ktkqWZySNVqKzJDi+kup k6WYvpLJpEiVKTnSK4v81BMAAAAAAAAA8K1EwAZ814UCUkOeVLFRqvysKWCr3SvV7pECXkmh 469bvkYqXSmVr5eiuksmkwaGdujKQfuUZXldyvFLSeOkiHTJbKPWAAAAAAAAAIBvBQI24Lsq 5G8a/rF6h1S2Wir+WKraLPnrjbXTWKBQXoECQSlociii3q5usVZ18K1WaNd+mVI3S92ukKK7 S2YHdQcAAAAAAAAAtHsEbMB3TkjyVkpVW6XC96WCt6WaXVLAHXaLvoDk9kk+k117y6O0Ni9B AyMHaFKHWjn3/FMmW5zU/QrJlUb5AQAAAAAAAADtHgEb8J0RappDzV0kFS2Vdv6paSjIoO8Y y5oUskQoaImUzA6FTFbJZG1qI+SXKeiVKdAgs79agWBItW7J65NCqlWqvUG9UmOUr0Gqzjpb lm1XyHboZZk6TJFcHSWZOBQAAAAAAAAAgHaNgA34Tgg19VCr3Svt+JOU+6IU9B69mMmskMmu kNkpT9xoeRImyx/VW0F7qgK2REkhWdz5sjZmy161UpH5T8nt98sfDB2eqS3OFdBAZ65qnP9T yDRfDSnnKibnLzI15ksBj2RxcjgAAAAAAAAAAO0aARvwXeApk/KXSDvuluqyj9lrLWSyyR/R Uw1pi+VOnqGgJUYy2RQymSWTSV/0PPNH9FDAma6gLUGRBc/Ka01WyFQh6cshJp0mtxyBbdL+ xxRM7KWQ2drUc85fR8AGAAAAAAAAAGj3CNiAb7uaXVL2U1L2fyR38VHhWshkkT+yjxpT5siT OFUBR0cFrdGSzMduz2SSTFaFzDbJJLkTz5LXdkiW6s0y+8q/aFUmb7mU/bRkv6xpm6GQdLif GwAAAAAAAAAA7RcBG/BtVrKsKVwrfFdqKNDXA66gLVGNybPlTpouf2QfBexJksnyjc2GTFYF 7SmSTLKYAmrssEBWa5Kc5R/I7Kv4fKGA5C6WOe8VmYK1kiNRskRwTAAAAAAAAAAA7R4BG/Bt FPRJ+W9KOc9Kpcsld8lRi/iiB6kx5eymedZcXRUyGxi60WRW0BItX0QvRTVuVXX0JHmSpsvs q5SzYqkU8jctpoCcnv0yOWySPZHhIQEAAAAAAAAA3wpmSgB8m4Qkf72U+19p7z+kov99LVwz KWR2qjFppurTr1Zj6gL5InsbC9cOf3o41Jg6X/ZAiRKrXldkMF+WqHSZItNks0gOmxTplOwW v0yhYNNQlZ4yDhEAAAAAAAAAoN2jBxvwbREKSr4aKe81ac+DUvV2KdD45esms4K2BHkSJqm+ 46XyRfcLL1j7YnNmq9zJM2Vr2KOoms1y1BbLF7LL7DDLGpIsJslmlcwmSUGPlPuSFNVd6jCF nmwAAAAAAAAAgHaNHmzAt0EoIHlKpfwl0tbfSpWbjgjXQiarAo40uZNmqibzZnljh7QoXPvi 4yPgSFNdxvVq7HihzBEdFWHzq9FvUUGNU1arpSlc+0LZSqngbaluP8cLAAAAAAAAANCuEbAB 7V0o0DQMZP4S6bMbpfrcw3OgSVLIZFfAmaGGlPmq6XqLAs70Vr30/c501Xe6XFW971Nl33/q I8/levDTNJX7Er/2PoNNvesK35f8dRw3AAAAAAAAAEC7RcAGtGuhpnnN8l6TNv7s8znOQl++ bLLIH9FN9Z2uUF3mTxW0xZ+8d2K2KWBPUYm3o1YXpmtl1XiFTLYjF2osaOrFVrLsyPcJAAAA AAAAAEA7whxsQHvmLpGy/yPtuFvy1hz1sid2lOrTr5In4UyFzPZT9rYaAi4dCvSVOyUgV8mS I3rUqXSFFNVVShwhOZI5hgAAAAAAAACAdocebEB71Vgo7fuXtPsByVupr/cIa0ydp7rMn8gT P/6UhmtNTPLbUlTX+YcKONMkk+XLlwIeqfhj6cATHEMAAAAAAAAAQLtEwAa0R+7ipnAt+0mp Mb9pfrPDTGpIPV/1aZfKGz1EIUvkaXmLIbNN/ohuqs24XkFbwldfaZonrvB9qXwtxxIAAAAA AAAA0O4QsAHtjbtY2vdv6eDzUl22FAp8+ZrJpobU89SQdrF8UQMUskScxjdqUsjslDtputwJ Zx45/1vQI1VtlXKePXL4SAAAAAAAAAAA2gECNqDdCEmecunA41LOf6TavUeEayFLlBqTZ6m+ 0xXyRZ/ucO0LJgVtiWroeKF8kX0UMju/fMlTLhV/JJWuPDIkBAAAAAAAAACgjSNgA9qDUFDy Vkk5z0j7HpFq9x3R8ytojZU7YaLqOn+vKVwzO9rU2/fFDJM7aYYCzvSv7JO/aajIff+WfDVf G+YSAAAAAAAAAIC2i4ANaOtCQclbIeUvkXbc3RRKfaXHV9AaK2/cONWnXyNf9GDJZGl7u2Cy yJ08S96YIQpZXF++4KuRCt6RytdIQTfHGgAAAAAAAADQLlgpwfH5AwHV1zfIYrEowuWU2Xxk Hun3B9TQ2Civ1ycpJLvdrsgIlyyWowOOUCik+oZGeTxehUJB2Ww2uZxO2e02Co3jCwUlb6VU 9KG08WbJU3pET6+QJVLeuLGq6/w9eWNHtOldCTg6yhs3Vrb6nbLVbvtiDyR/jbTrr1J0Tymy q2Qi9wcAAAAAAAAAtG0EbMfhDwRUVFKq9z9aoeTEBE0eP1pRkV/OaeXz+ZVfWKRV6zZpX/ZB hUIh9eyWqXGjhiqtQ4qs1i9LGwwGVV1Tq2Wr1mn3ngPyeL3qlNZBI4YMVFaPTDnsdgqO45yI dVLxh9LGn0ru4iNfM1nliT9DdelXtflw7QvuhMmy1W2VrW7Xl0NcBn1S4ftS6SrJnijZ4zju AAAAAAAAAIA2jYDtOHIPFeifjz+rF159S0MH9dPQQf0OB2yBQEAfLV+lv/7jce3LPqjuXTNk Mpn05POvqlfPrrrpuqs1ccwIWSwWBYNBHcg5pFvvuFdrNmxR98zOsjvsKigsVlxsjC67cL4u u+hc2awcCnxNwNM0fOLmX0mNRUe97E6covr0q+SNHdludiloT5I3dpRsNRtlr9l45It7HpDi +kn2IRx7AAAAAAAAAECbRqpzDJVV1fp07Qa98c6Hcjoc8vl8CoVCh1/ftHWnXnv7A/mDAd39 m5s1fPAAySRt2LRNf//303p1yfuKj43RkAF9lVdQrBdefUtbd+zR7Tf/SONGDZPL5dSefdl6 +r+v6+0PPlFGepqmTT6DwuNLQZ+U95q0+69Sw8EjhoWUJHfCmapPu0TemKFtcs614zPJGztC 1rqdstVulemLXmySVLVFKl0puTpJzhTOAQAAAAAAAABAm8VkR18TCAT02ebteu+jFerXu4c6 p3c8au61bbv2an/2QQ0d2E9nTRqnzIxOyuzcSVMnjtXg/r21a+8B7dy9X5JUWFyiTz5dpz5Z 3TV72mRl9eiqzM6dNG7UMI0aPli1tfVasXo9hceXQsGmcG3fI1Lllqaw7Ss8cWPV0OlSeWOG K2R2tb9rzJYob+ww+WKGfe0Ft5T7slSzi3MAAAAAAAAAANCmEbB9za69B/Th8lXyBwK68Nyz FeFyHvF6Q2OjDuUVyB8IqH/vnoqNiT78WmxMtPr3yZLX69Oh/EJVVtWoqKRURSWlGja4v5IS 42X5PKyLjHCpZ7cuio2J0oGcQ6qpraP4kBSSCt6WDjwpVayTAo1fvmQyyxszRPWdrpA3dqRC 2WQCmwAAIABJREFU1uj2uYsmq/xR/eROOksh09fmH6z8TCpfe/R8cwAAAAAAAAAAtCEEbF9R UVmtpctXKyc3X1MmjNGQAX2PWqaqulYVVdVyOZ3q2OHoYew6pXWQw2FXeWWVCoqKVVpWoWAw qG6ZnWU2mY5YNjEhXvFxsaquqVVpWQUHAFLxJ9L+x6SyTyVf7eEfh0w2+SJ6qr7TVfLEj1fQ GtuudzNgS5I3doS8MV+bb81XIxV9KFVt5VwAAAAAAAAAALRZBGyfCwQCWr1hkz7bsl1dOqdp xpQJstttRy1XV1+vhka3HHa7oqMij3o9JipSDrtdDY2NKq+oUm1dvSwWi+JjYyUdGbBFuJyK jIiQ1+dTVXUNB+G7LBRsCpX2PSSVfCJ5K798yWyXP6KbGtIulTt5ZvvtufZVJov8zky5U+Yq ZD6yl6gq1kllqyRPOecFAAAAAAAAAKBNslKCJjmH8vXuh8tktVo0Y8oEpad10MFD+UctFwgE FQwGZTabZbUeXT6LxSKzyaRAICivzye/3y+TySSbzfr1fE1ms1kWi1nBYEiVVdX6aPmqFu3D lh27FQgEVFZRqaXLV8tiIT81asfufXJ7PNq7P6fFx6PZF6FZSo5wK8v7vCyF/5O8X/Zm9AVM KqqL0I7SrqoJ9JXytrf5Gu7LzlWj26MDOblauWbDCZYMyemNVlZ5tHrGeWQ2hZp+7CmXN/9j 5dWlKcfX9zt1/m3buUfVNXU6lF94ys6/b5vtu/eptq5OObl51DBMO/fsV119g/bn5FLDMO3e e0ANjY3avS+bGhpU39CoQCCgvIJirVq7UQdycimKQeUVVZKkQ3mF+nTtZ0pMiKMoBhUUligU DCn3UIFWrN6guNhoimLQgZxDCgQDyjmUp2Wr1isq0kVRmmnXngMqKa9QbW09v0PC/k69V2UV lQoGg9QwTJu27VRFZbUa3R5qGKYt23ersqpGFouFGoZp6449qq6uVX5BETUMQ21tvUpKy7V+ 0zZV19RSkDA0NDaqqKRUaz/botJyRh4Lh9vjVWFRidZs2KyCohIKYoDNalNSYrwCgSDFaONM oVAo9F0vQmOjWw/86z9as2Gzzpk5RRfMny2bzaqDh/J1/S/ukCT9497fqnNaR+09cFB//efj Ki4t089vuEajhw0+oq2Vazbo7vseVpfOnbTwnFnasHmbnnjuFd39m5s1bdIZR4ReO3bv08NP Pq9de/br4oXn6I57HmzRfnh9PtXW1ctmsyomKoqzOwwer1f1DY1yOZ1yOR0n/wI0BRXvaNDc rEO6cUKhXLYvPzRDMquoPlJv7Oqov36SIq/f1G5q6HZ75HQ65LDbT7hsjDOgWX2q9evJe+S0 +mVS08dReYNVz21K04NruyoQsn2nzr9Gt0c2q1WREdyICr+GbtltNkW4qGFYX4C9Xrkb3XI4 7HI5nRQkrD8iPGr8/HPQ5XBQEANCoZAqqqoPn39fzF2L5gsGg4eHM3c5HTJTQ8MCwYAqq2rk cn1eQxM1NMofCKi6plYup0Mup1Mmk4miNJPP71ej26NQMHjEfN8wWkO3FJJiovm7ONx7C263 RyaT6Zgj96B5NWx0u2U2mxUdSQ3D+tvO55O70S2L1aKoiAgKYlBVTY0sZotcLoesFvpXhKOy ukZWq0Uup1NWi4WChKGiqlp2m01Op4MaGhQbE625s6bon489q4vOPVs/vHKxunfNoDBtEJ+w kj7bsl3vfrhMo4YN0sB+vVRVXS1JKq+sks/na/p/RZXiYmLksNvldDjk9fpUX994VFt1dQ3y en2KcLmUEB+rqMhIBYNB1dTUSjoyy3S7PWpsaJTNZlP3rhn6wZWLWrQfu/cd0GtvfaDMzuk6 /5wZ3FAJw9ade7R0+WqNHj5YI4cOPMlbC8mpKnW3rNPUyDVf9uCSJJnkDkXrYGiEylOm6sLz bO2qhhs2b9fQAX01sF+vb1zeZW5Ulf6tFOXJIr8kKTHCr5nDYxXbf4LKQl2/M+ffjj37tWb9 JnVKS9W0SWdwQYZ5/q1Zv1k9umVo0rhRFCQMm7ft0uoNm9S/T5bGjRxKQcL8XrF6/WaNGDJA I4YMoCAGuD0e3ffQkxrQJ0ujhg9WfGwMRTGoprZO9z38pAb2663RwwdxczkM5RWVeviJ5zVk QF+NGj6Im3phKCwu0ZPPv6Zhg/tr1LDBp+TBtW+LQ/mFWr1hsxoaGnXZhfMpSBhyDuVr9fpN CgWDuui8ORQkDPtzcrVm/WbZHTYtmDODgoRhz/4crdmwWbExUZo7YwoFCcOuvQe0ev0mdUhJ 0owpEyiIQf9++kUlxMVq1LBB6tQxlYKE4Z+PP6uOqSkaPXywOqQkUZAw3Pfwk+qWmaHRwwcp OTGBghjk8/vEY2ptHwGbpFXrNqmsokKPP/uynn7xdZk+D6ZCwaDcHq8kae6i72vh/Nm65Py5 SoiLUV1dvQqLj+7aml9UrLr6BiXExSozI13ZB/Pk9/uVnZunYCgky9f+eC8rr1R0ZIQG9e2t YYP6t2g/3v1wmd56/2NlZnTSD65cJAtPBhj2ypL3tX7jVo0bNUzXXLrw5G7MUy5T3usyb14i c/DI8DVkiVSg44XK6HSNFlnb1y/xl998T3sP5Gj0iMFaOG/WNy5vCnplr06S9t0ueb+8prrG VitjkFnBfou/M+ffm+9+pJzcPA3u30c/vGoxF2SY59+BnEMaPngANQzT86++pb0HcjRm+GBq GKb/vPCadu/N1oQxI3TF4vMoiAE1NXX6x6PPqH+fLF18/jnq0jmNohhUWFSq+x5+UoP699Kl F85XWocUimLQ/uxc/es//9WQgX11xaLzuBkQhi3bd+vZl97UsEH9dfUl59MTy4C1n21RSVmF Kiqr+D0cppVrPlNRcakCgSA1DNPHK9aooKhE0ZGR1DBM/1u6UnkFRUpPS6WGYXr7fx/r4KF8 9e+TRQ3D8Ma7HyozI10L5s7QkIF9KUg4fxu/8pZ69eiqhfP+n707D5Lzvu87/36ep+/ume6Z nvvGzOAkAAIgQRA8RJMWddKRJTmSI0eWK3FUXidb2Xh3a1O7yVYl3tpKyvZmE2ejOLKjxI6d RJZtObIk6mJ0kCIIgMRB3MDcF+a++3qu/aMxDQwAXtMNcAB8XlVTJJ7nmd88/X1+z9G/7/P7 /T7K7p3bFJAN+IP/9Kfs3NbNL37qBbb3blFA3qNsLs+//cp/USA2OSXYgBc+/Cy7d20jm82t Wz49O8dX/vhrAPzq5z/D/r276Opop6O9lUAwwOmzF3A/9UIpkWU7Dm+cPkskEqajvYVYNEp9 XS3tbS28fOR1/se/88sEAgEMisOmXOofYm5xkWeePEQsFi176JRgIAAYmKZJKBRS19uNnBCW hWEYBALWOw5vWBZ7Caa/A1d+B7zVdat8M0ym+RfJNP8NiDQQMqx7L4YYWJZFKBh8V5ehQvpZ 3IltmM4Shlc8D838BObScXBnIPpgNLAGAgFMw8Ay73D9u48FAwEMo1j/FMMNxvDadVAxLO9c viv3kvtQKBQEDCzLJBQKKn4bjiGl+7BiuIEYBtdiaCqGG45h4Nq5rHq4kWcZyzQwTUNx22gM gwFM08T3fcWwnBgaxbYFxXCDz4NBC9M0MPXdrrxnalP1cKMMo3gvCQYDil9ZMdTzYGViqHq4 EZ7roZHW74H7lUIAWzrbaGtpwvPXTxo4MjrB17/5XQCePPQIXe2thEJBDuzdxYnTZzly/CRf +ZM/4/mfeRLfh29//0e8fvIMTz3+KPt278Q0DTramvnIc0/zpa/8Cf/69/+IFz70LPF4jNeO n+J7P3yZhro0zz/zhOYleJC4WRj7K7j8JVgZ5MahQ33DItP0GTKNn8KNdoLxICRJDXwrQa72 OazsIFZu9NpdxIblK8VY9X5R9UZERERERERERERENg0l2IBwKHTbLHoiHiv1TkvEY0SuzR3Q 3dXOxz/0LJlsjq9+/dv8+NVj4MPVqWn27dnFxz/0M3R1tAJQV1vDh597mpGxq3znpZc5deYC Actibn6B2poUH/3gM+9qniq5T/gOTLwIA/8BFk4X/73GMMjV/zWyjZ/GiW/HNx+sNzty6Z8l MvMiVn4CfLe4MDMGY9+Ers9BQHPIiIiIiIiIiIiIiMjmoATb20hWV5UmRb5xgvh4LMZjB/YS i0Y5duI00zNzADy6fw+HHnmYndt6iEWjAIRCIXq3dPK3/+Zf5yevHmNichrXddm7ewd7H9rO vt07qa7SnAQPBh8mfwT9fwgzR8C9YUhSwyJf+wyZls9hJx7CNyMPXHScaBd21R4C2X7Mwsy1 hauweBamfgLNHwbDVDUSERERERERERERkfedEmxvI5Ws5nPXEmw3S1ZX8eShAxx6ZC9LK6sY FJNw1m3mPQuHQ+zeuZWHdvSytLyC53nEYlGNPfugmTsBfX8AUz8Ge7m02DdDOIldrLT+bQpV +/Ct2IMZHyNAvuZpgksnCK0l2PAhPwODfwKNz4IVUT0SERERERERERERkfedEmzlBjAQoDaV fFfbGoZBslq91R48fnGowyu/B5M/gMLc9TVmCDfaw2rr36KQeuKBGxbyZoXqR3FiWwmunMPw rvXwc5Zh6oeQGYHEFjB02RIRERERERERERGR95fGWxO5k3wPCovFOddG/xJyU9fXGQHcSDuZ pk+Tafz0A59cA/CCNdjVD+NGO26K4TyMfQPsFdUpEREREREREREREXnfKcEmcsf44KzAxItw /rchN3nDOgM31Ei27qOstH1RobpBofogdnwnYFxf6OVh6KtgLxXjKiIiIiIiIiIiIiLyPlKC TeROsVeKQxse+/VriaHrvGANuYaPs9Lxd8GwFKsbwxbfhp3YhReoviFgDswdh5XL4OYUJBER ERERERERERF5XynBJnInOKsw9SM48b9BYQH8672u/EA12cZPstLyBfyA5uS7hRHATuzGrtq3 frnvwuh/u6knoIiIiIiIiIiIiIjI3acEm0ileXmY/gmc/y1YvsKNQxr6ZphswyfINH0WN9LG umEQpcRO7KJQvR//5t59Y9+C7HhxXjYRERERERERERERkfeJEmwileQ7MPUyXPkyzB4r/vuG 0y1X/3EyjZ/CiW0FI6B4vQUvmMZO7MKJ9qxfkRmCuTcgP6MgiYiIiIiIiIiIiMj7Rgk2kYrx YeY1GPiPcPUlcLM3rDPI1T5Lpukz2Ind+GZI4Xo7hoUT66WQenz9cs8uDr2ZGVaMRERERERE REREROR9owSbSKUsvAkDfwjjL4K9cH25YVJIPkKm9QsUqvbhWzHF6l1wI60Uko/iBVLrV8wc hZXBm3oHioiIiIiIiIiIiIjcPUqwiVRCZgT6/wOMfwvy09eXGwGcSBcrbV8knzqEH6hSrN4l 30rgxHqxq3bfGuulC5CfVZBERERERERERERE5H2hBJtIuezFYnJt5C8gM3p9uWHhhptZbf0C +fTP4lsJxeo98sKNFGo/cNNSH+aOFZNsIiIiIiIiIiIiIiLvAyXYRDbMBzcPw1+DK/8OVgdv WGfghurJ1r/AatvfxjcjCtcGeME0+eqDcPOcdXNvwNLF4jEQEREREREREREREbnLlGAT2Sgn CxPfgdP/CLLj61Z5wVpy6edZ7voNwFCsNsg3gnihegpVe8G44XKVHS/2YMtNKkgiIiIiIiIi IiIictcpwSayEc4KTP0Q3vgHkJsG3yut8oIpcnUfZqX91/GtqGJVJi9QRb72A+svV74Hi+dg 4bQCJCIiIiIiIiIiIiJ3nRJsIu+VswrTL8OZf1ocFtJ3S6t8K06u7sOstn4BN9KGeq+Vz7eq yNc8g28E1q9YPAdzpxQgEREREREREREREbnrlGATeS/cLMz8FC7+Lsy9vq7nmm+GydV9iEzT Z7Fj29cPaSgb5pshnEgnTqwH3wheX5GbhKXzkJ1QkERERERERERERETkrlIGQOTd8gowcwT6 /gAm/zt4zvV1RoB87bNkmj6DXfUwmEHFq2IMfCtOoebJ9UNuegVY6YcF9WITERERERERERER kbtLCTaRd8N3YPYY9H8Fxr9V7MlWYlBIHSLT8ksUqh/BNyOKV8WvVEFy6Z/Ft2Lrl68Owexx xUdERERERERERERE7iol2ETeie/Bwlno+30Y/QbYy+tOISexk5W2X6VQfRDfiited+IQGAEK VfvxQg1w41xsuauwcKY4L56IiIiIiIiIiIiIyF2iBJvI2/KLvaQu/gsY/W9gL1xfZVi44WaW O/8n8qkn8AJVCtcdc22YyKr9eIHq64vdHGRHYOmCQiQiIiIiIiIiIiIid40SbCJvyS/2Vjvz T4o91wpz604dN9TActdvkEt/EN9KKFx3QaHmCbxg7fqFuWmY+amCIyIiIiIiIiIiIiJ3jRJs Irflg5eHN/4BjP0VFObXrXXDTWRaf4Vs06fxzbDCdZfka568TYJtCqZfVXBERERERERERERE 5K5Rgk0EwLMhN0m1P0pHKkewMAGv/8/Xeq7NA35pUzfSSrbp06w2/xK+EVTs7uZhspLY8R3r k2zOMixdhOzEuuMkIiIiIiIiIiIiInKnBBQCeaCtDsP4t2H6J5AZ5dH8FL/5M5PUR4ZgZBEK s+B7pc3dSDvZhr/GavMv4QVrFL+7zTCxqw8QWjqOaV8bstP3isdp+hVo/yQYluIkIiIiIiIi IiIiIneUerDJA8qH7Bic/238K1/GXhwga6SxAw3EzRXS/mW87NT65Fq4lWzDz5Fp+gxupF0h fJ8UqvfjhZrWL7SXYeq/g68ebCIiIiIiIiIiIiJy56kHmzyYfL84/OP4N8nFHyaX/iCOZ5Jb /B55x2c1DwUH4mGwTPBC9WTrP0qm4ZM4sV7F733kRtpxol0EA9WYzlJxobNSnIfNy4NpAYYC JSIiIiIiIiIiIiJ3jHqwyYPJd2D4q9hWLZnGz5CL78NeHiO08ia1UZu8TSnJ5vmQr/kA2cZP 4SR2Knbv96Ezw9iJnbiRtusLvQKsDsFKP3iOgiQiIiIiIiIiIiIid5QSbPLg8T1wlmHxHIXE HlxC+BPfhZE/g+XL1zfzIesl8LHIpw5f67mmnlGbgZPYhRvpXL/Qs4tz6blZBUhERERERERE RERE7igl2OTB47uQnQDfxTWjxeTa4H+GxfPrTg0/UE2uah+eGcNw5jHcjGK3STjRbpxIGxjW Dce1AFM/VoJNRERERERERERERO44zcEmD6hibtmYOQrzg5CdKa3xMXDNOHbd8xh1j+FND6Ke a5uLF6jGjbTiBmuxCtPXFtow/Qo4GcDXMRMRERERERERERGRO0Y92OQBrPUBSHSCYWEuncAo zK5bnXFjXCw8xnLXbxD0VjB9Gz9Yjx+oUuw2ETfSgRvtvr7A9yA7DisD4OYUIBERERERERER ERG5Y5RgkwePvQSXvgRuhojlEjD9Ul+n8aUgL/a1cnTpEAY+qaXv4IfrcSPN+GZYsdtE3EgH TmzL+oW+B3PHwV5UgERERERERERERETkjlGCTR4suUno+wO49G/AyWCZkIgUf4KxGuZpY3Te oDdyjo7xf0ose458+nmcSCcacnBzcSOtOJEuMG66jM2/DgUl2ERERERERERERETkztEcbPLg yIzB6J/Dld+H1YHS4mAALBNCRo4d6QWqdnm0p1eJ+zVkW/4GufqP4YXqFb9NxrMSuJFm3GA9 VmHy+oq5E8VeiiIiIiIib8H3fVzXxfM8DMPANE1M08Qw1r9U53le6WdtG9M0bynL8zxc133L bURERERE5P6jBJs8GDKjMPbfoO/fw9L59V+aox0Uqh/FDdWxMtTH4MBl/Po9xNuep5A8iBtu xTeDiuFmY5h4oUbc2Jb1CbbMCGTHwN0NVlRxEhEREZF1bNtmbm6OyclJMpkMhmGQSqVoamqi qqoK0zTxfZ9sNsvk5CSzs7PYtk04HKahoYG6ujoikQgAruuytLTExMQES0tLhEIh0uk0DQ0N RCKRWxJ2IiIiIiJy/1CCTe5/2TEY+wb0/weYP7lulRtpJdvwCTINP48XbuZE//f58rE/4+ON H6Kz6RcUu03OC9XjxLYSWjhyw0HNwdJFSD8GUSXYREREROQ6x3EYHx/n6NGjLCwsUF1djW3b rK6usnXrVvbv308ymSSXy3Hu3DlOnTqFZVnE43EWFxcJBAIcPHiQ3t5egsEgCwsLHD9+nKGh IWKxGI7jYBgGBw4cYNu2bYTDmsdZREREROR+pQSb3N9ykzD6Dej/CsweW7fKDTUUk2tNv4gT 7QJgxa9lciWI41uK3T3ADdXjxHoozo/nX1+xeBZy0xBtUZBEREREpCSbzXLmzBnm5uZ44okn aGpqwrbtUjKtrq6OaDTK1NQUJ06cIJ1O88gjjxCPx5mfn+fVV1/l9ddfJ51OU1NTw5UrV7h4 8SKPPvoo3d3dZLNZjh8/zsmTJ0mn0zQ1NWm4SBERERGR+5Se9OX+VViA0b+AK7+3PrlmmHjB GrKNP89q698qJdfk3uMFanAinfg3DwW5cBby0wqQiIiIiJT4vo9t23iex65du+ju7qauro7G xsZSj7Tp6WkKhQLZbJZUKsWePXtobW0lnU7T1tZGT08Pk5OTLC0tsbq6Sn9/P8lkkm3bttHQ 0EBbWxsPPfQQs7OzjI2N4bquAi8iIiIicp9SDza5P3k2DH8VLvxLWLpwwwoDL5Ak2/hJlrt+ A9+qUqzuZYaJF0rjxLcTXDpxffnyechNge+BofcIRERERAQMwyAej/PYY48RCoWIRqOlOdJc 18V1XQKBAIFAgNbWVmpqakgmk1iWhWEY+L5PoVAgEAhgmibLy8ssLCzQ1dVFPB7HNE0MwyCd TmNZFlNTU9i2TTCo+ZxFRERERO5HSrDJ/cf3YPhrcP53YOXKulVeKE228ZMsbfmH+KbmQ7gf eIEUdmLX+gSbk4PVYcjPQqReQRIRERERAMLhMA0NDQClpNny8jJ9fX0YhkFjY2Mp+VZVVVVK wDmOw9TUFH19fbS2tpJMJpmfn6dQKJSSa2tlBoNBotEo2WyWQqFALBZ7V/vmOA75fB7HsXEd h0wm865+b20fpSifz+E4Dp7rks1mFZANxTCP6zg4jq0YlhtDWzEsN4a2Yrghrls8h3O5nOK3 QZ7r4tiKoWL4/slmc3iei60Ylvi+/562NwyDQCBwR194U4JN7rMniCxc/QGc+U1YHSgm29ZW hZvI1f8cy+1/F9+MKFb3y806kMSO77j5cgur/ZCbUIJNRERERG75og3geR7Ly8ucO3eO8+fP s3v3blpaWko91tY4jsPVq1c5duwYtm2zZ88eqqurmZ2dxfd9QqHQuu3Xkmyu677rRgDXdRkf H+f4saOMDPaxvLLKiy+++K5+d63n3Ns1QFQiCXcny6tkmWcvXGZ8eADP8/jud7+76fbvXijv 9LkLjI8OEotGFcMNlvfG6bNcHRvGyS1vqhjeS8fkjTdOMzU+QizgVyyGm/naVenypidGsdwc R179KTNXxx6I867SZc5OjTMUs/jpT19hfGTwgYlhJctbnJ1ksP8yr7z8E4b6ryiG77G8QsFm ZX6agSsX+clPfsyVS/Wb5jx5P66Fvu/jed57Ki8QCPDQQw/R1dVFIHBnUmFKsMn9w1mB6Z/C 6X9U7Lnm2de/sEZaydb/HJmWz+OFlHC5n/iBapzYNjAs8G+Y42K5D7ITkNqrIImIiIjIOq7r sri4yJkzZzh9+jRbt25l7969JBKJdV/oC4UC4+PjHDt2jNnZWR5//HE6OzsJBoOl4SQ9z7ul kcHzvLdMfN2O53mMj4/z/e99h+GBfnzD5MSJE+/4e6ZpEg6Hb2kwcF2Xq1evMjc3R1dX1y2f ayMNHnNzc4yOjpbmpCu3ISWXyzE8PIxlWbS1tREOlzfCiOM4TExMcOHSZWanZ7CsABcvXtxw ebZtMzY2RiaTYcuWLUSj0bL2b+0Yz87O0tPTQzweLzuGmUyGy5cvU1tbW0oOV+KYjF+dZGF2 hkIsVlYMC4UCIyMjOI5DZ2cnkUik7BiOjY0xMzPDjh07KnJMZmZmmJycpLW1lVQqVeqNWu4x WVzJsLQwi4lbVgzz+TxDQ0OYpkl7e3vZ50k+n2d0dBTXdeno6Cj7mPi+X5pzsrW1ldra2rJj mM1m6evrY2p2nqXFOWanQxuOoe/7LC0tMTg4SENDA42NjRU5xv39/VRVVdHa2lp2g63v+4yP j3P16lV27NhBLBYr69rgeR7z8/NcHRnEt7MM9PfjFnJllTc9Pc3U1BRtbW2kUqmyr13ZbJYL Fy5QV1dHa2tr2cekUCgwNjZGoVCo2LVmcnKSqbFBEhGLwYF+8pmV8submqKrq4vq6uqy78nz 8/OMjIzQ3NxMXV1d2TFcXV3l0qVL1NfX09zcXPb9ZO2YzE+PM3W1ioH+AVaXl8q+Xk9MTNDR 0VF2PfQ8j4mJCWZmZuju7i77OWmtXl+5coWqqira29vLjqFt2wwPj7A0O8nkxBj9fVdYWpgr 6x4/NDREIBCoyHPX2nPSysoKvb29FbmfLC4uMjIyQn19PQ0NDbfUa8/zyOVyt332fqvr9ezs LNXV1bS3tyvBJvL236ZWYeYonP8tmD8NXD/J3HAL2foXyDR9FifaqVjdZ3wziBeqww23YOVG rx/7lf5igk1ERERE5Aau6zI7O8vJkye5fPkyO3bsYN++fdTU1Kz7Ir+WbDh69Cj5fJ4nnniC 3t7eUqN+KBQiGAySy+VKX/J938d1XXK5HLW1te+pccV1XQJWgNb2TsxghM997nPv+Dtrw97c 3ADhOA5vvvkm58+f59lnn6WpqanshqiBgQGOHDnCo48+ytatW8tuzFtaWuKnP/0pgUCAQ4cO UVVV3vzY+XyeEydOkLc9CKcIhEL8wi/8wobLy2azHD9+nOnpaZ577jlSqVTZ9e7EiROqDkHW AAAgAElEQVRcuHCB559/noaGhrIb8+bm5vjmN7/J1q1beeSRR8oe/mh5eZlXXnmFqv5B8kaM VCpVVgxXVlY4evQo2WyWp556imQyWXYMjx07xvnz5/n4xz9ObW1t2eVdunSJkydPcvjwYTo6 Osqu17Ozs3z7299mNW+T8UK0NDeVFcO1Y2JZFo8//njZ58nKygqvvfYahUKBJ598kurq6rLK 8zyPvr4+jh07xsGDB+nu7i67UXlhYYHvfOc71MzMs+IG2blt64ZjuJa8eumll9i7dy+7d+8u e//m5ub4/ve/T1tbG4888kjZjdSe53HixAlOnDjBxz72Merr68uu1wMDA/znv/gWbZ3d/Ozz z/PwQzvLKu/ChQucPn26YufJ3Nwcruuyfft2HnvssbKPSSaT4dixYywtLfH0009X5Hp9+vRp /vhrf0VXzzY+9OGPsL23u6zyzp49y5tvvsnP/MzP0NLSUvY9eWhoiJ/+9KccOHCAbdu2lR3D 6elpDMNg165dPPzww2XfT1ZXVzl+/Dhf++ZL9GzbyYc/+hF6ujrLiuHly5c5duwYTz/9dNn1 cO0Ynzlzhg9+8INlPyetXbu+9a1v0dHRUZrvtxzZbJbXXnuN//yXL9K7fRcf/dgLdLa3lPXc 9fLLLxOJRHjsscdIJBJl7V8ul+Po0aNMTk7y/PPPl33e+b7P6Ogor7zyCg899BA7d+68JSHm +z6O4+D7/rtKsM3Pz/ODH/wA13Xv6HcLJdjkPviGnIHZY3DlSzD5Q25MrnnBNLm6j5Bt/DRO fCug+QnuPwaeFcdO7MLKj8HaBTZ3FbJjxfphxRQmEREREcHzPObm5jh27BiDg4Ps27ePXbt2 kUwm1zXUFAoFhoaGeOWVVwgGgzz11FOl3h5rc7dFo1Gi0SgLCwvYtk0kEsHzPFZWVshmsyST yffcuBKJRokbYaxQjG3btr37J+KbGoUKhcK6Hgfl9hBwXZdCoVDqKdXZ2VlWY97aW8pXrlwh EAjQ0dFR1hv9vu+Ty+WYmJggmUoRWyoQCkfo6uracHmZTIbh4WF836e9vZ3a2tqyGt9s22Zi YoLp6Wna2tpobm4u65j4vk8sFiOdTtPU1ERHR0dZDf1rx6S+vp7p+SXiiTmqqpNlxXB5eZmh oSFWV1dpb2+npqam7BgODw8zOTlJe3s7dXV1ZZe3vLzM6OgoLS0tdHR0lPV2+9p1IZ1OE8oW iCWqqE7WlBXDpaUlLl26VLHzZGlpif7+fgqFAh0dHSSTybJi6F6b6zCdTpeuDeXGsKqqivr6 enIuxOJVJGtqNxzDtd7E6XSa5ubmiuxfPB6nrq6udN6t3RfKieHExAQ1NTW0t7fT2NhYVnlr 83mGwhHiiSqam5o3HL+182RpaanUS7ES1/94PE5NTQ3Nzc10dHSUlczxfZ+VlRWGhoYIh8MV u15PT08TDIVIVFXT0tJadgzn5uZKMaxEcshxHGpraytWryORCLW1tTQ1NdHZ2VlWcmjtmAwP DxMMhamqTpYdQ8dxWFlZIZ1OV6Qers2tOzExUZHnpLVrV21tLY2NjXR2dpZ9T85kMgwMDBII hqiqTtLa2krXBpOUvu+zsLBAfX09kUiEjo6OdXMNb6S8bDbL0NAQrutW5LxbG1q9rq6udG24 uR6+1/nXZmZmOH369B2fr1gJNrnHvyEXYO4N6P8KjH0DfOf6qkAVufTzZJo+jZ3YhZJr9y/f jGIndhOZ/f4NV+YcZEYhexUS3QqSiIiIiJDJZDhz5gwnT57kwIEDbNmyBcuyyGQyAASDQSzL YmZmhldffZWlpSWeeeYZ6urqcByH1dVVDMMgFAqRSCRoa2vj4sWLXL16FcuyKBQKDAwMEAwG aWpq2lCDl2EYGIZRVsORZVmYpnnLz4aft30fwzAqVh5wS1nlvn2/Vs5a/Nb2t5zyboxjufu3 VtbNcSy3zBvrSyWOSbGctRiaZcewksf4xhhallWR8tZieOPxLrdMAOOGulhOmWu/f+M+VrIe llue7/vrYlipawOAaZhQoXP5xmNRif27saxKxPDmc6WcxuAbP6NhGJhl1utK309udy5Xqrwb z+NyYnh9nypTb263f+XekytZ3s3X60rdT67Xw/LLXNuvSl1rbjzX7tRzTcXOEwyMMsu83XWm Es9dlXxOuvn6Wslrw52mBJvcu3wHFs/CwB/CyNfAzV9fZUYopJ5kteVvYif2oOTafV4VrGKC zcfE4IZuv5lRWB1Sgk1EREREcF2XmZkZ3njjDQYGBkilUiwtLZW+eAeDQXp6emhvb6evr4+j R49SVVXF6dOnuXLlSqmcqqoq9uzZQ2NjI729vYyPj3PkyBE6OjrIZDIMDg6yffv2snsoicjd caffbBcREdG98/6lBJvcm3yvmDi58mUY+io4meurjCB21V6WO/8+TmIXGJbidb9XBzOCE98O Zhhch9IwoWsJNhERERERim+y7tixozTXxo2TpJumWfp3IpHgAx/4AK7rYprmurkb1oawMU2T xsZGDh8+TF9fHzMzMxiGwZ49e9i+fTuJROJ9bXwwTZNQKFSxJF+lywMIBAIVeeP5TljrWREM Bit2HC3LIhQKlXrTVGIfw+FwWUOD3ekYBgIBAoHAHYlhpfYxGAxu2mT4WgwreZ4EAgE8z6vo Plb62lDpa2E4HK5YDNfqTCWPiWVZhMPhTdtgvXbeVfIYh0Khisdws14Lb7yHVuoYV7q8zX4e 33jPq9Q+3on7SaXr9b1wT67kc9Jmvye/5X1VX7HknlRYgPO/A8NfBXuxtNg3griRDha3/d84 sV58Q1X8gWBYeMEkTrSTwOolDN8uLs+OQ2aEYsJNb1aIiIiIPMgsy6KpqYmamprbNi6vfakP BoPs2LGD3t7e2871sNZYu/bfzs5OGhsbyefzGIZBNBqtaAPQRpimSUtLC6FQiHg8XnbDh2EY 1NbWsn///rLnvVoTDofZunVrKY6bTSAQoKurqzRfSdlfWQyDlpYWwuEwiUSiIvsYiUQ4cOAA NTU1m7IxKhgM0t3djW3bFTnGpmnS3t5OLBaryDExTZP6+nr27dtHKpXalMmNUCjEtm3bSg3L lSivp6cH13UrUp5hGKTTafbv3086nd509dAwDBKJBAcOHKChoaEi+xeNRnn44YepqqqqSELH MAyam5s5dOgQsVisjHrog+cWR3dycwRNn4DpYvhO8SV1w9zw/tXX1/Pwww9X7DyJRqMcPHiQ dDpdkfKCwSBbtmyhUCiUPSfenaqHjY2N7N+/v6x5r24sL5VKsX//furr6ytSr2OxGI888gh1 dXUVKa/Sx2Dten3gwAFSqVRFhnNsbm4mEAhU7IWoSCTC/v37qa6u3nRJtrV7yPbt2wkEAmXN e3jzc1JdXV3FnpOSyST79u2rWL2+a8+M+pol9xzPhtP/GEb+AvJzN5yJFm60g/ldX8KJ9eAb QcXqAeIbAezEbgLZQXCvJdhy08VebG4OrKiCJCIiIvKAW0ugvZNo9N0/O641zsTj8VIDwftt LZlYX19fkTeLTdOkpqam1KBciUaPcDhMd3dxKPebJ7HfLHWlvb0dz/Mqsn+WZdHS0kJjY2PF 3vaOxWLs3Llz0/bcWEtA+75fkcY80zRpbW2lqampYgm7+vp6ampqKlav70QMK3mehMNhurq6 SnW8EjGsra2lurp6U8bQMAyqq6vZuXNnxfYvGo2yfft2TNOsyHm39kJEQ0NDefW6sADTP4Gp o3D+TT665Qq7Wws0Zb4NSzFI7tzwtavS50k0GuWhhx6qyFyKa+dGJa81d+Ke3NjYSDqdrkiP KdM0SaVSJBKJih2TeDzOrl27KtZj9nYvKJX7mevq6kgmkxV7rmlqaqKurq5ivdgikQg7d+6s 2Hxkd+J+0tPTU7H7SSAQqOhz0lqCbceOHRW7NtwtSrDJvcV34M3/E8b/CvLTlIYCNEzs2FaW uv93nPhWJdceRNcSbJHZ72G4q2sVBvIzsDoI1TsVIxERERG5c4+jm+yN+XebTHzXjQfXhhWq lM3ac+3G41npxF+lj4lpmu8pGXw/xLDS5VW6Xldapc+TSvWEu5diaFlWRc8T0zQr0lujoteG hVNw8Xdh4nv4ro27EKMmnKUn2kd67HfB/hF0/wp0/dKmuf5X8pjciWvNg3hP3sz3kzvxme/E PbnS14bNfj+p9Hl3ryXWSnVTX4PknmEvwqX/D4b+a3HoP39tHgQDO76L1bZfpZA6hG+EFKsH skUjgF21B9+86fjnp2G5Twk2EREREREREbm/LF2Cof+KN/UK2ZpnWa35EEuhGb4z8K+YjHSQ 2NrC3vwgwcE/hnAdNH9YMRMRqSAl2OTekJ+F0a9D3x/A6kixJ9s1dmInmebPkks/h28lFKsH lG9YOPFt+Fa8OLa4f21ejdw0rPQrQCIiIiIiIiJyf5l/A+/qD8mH2lhNHCKfz2Mv9NEcX6E5 fBUrY5M1RzGWlwm4/xyufh+sCATiEGmCqq1QvQPCacVSRGQDlGCTzS8/C1e/B5d/75ZEiRPf Rrbxk+TqPoIX1MPAg83ACyRxI21Y+XEMN3ut/kzDSp/CIyIiIiJyv38jMIxNN1TnvfnNSjEs h2maqodlnsemaaJq+A5yk7B8Ba7+AG/hIoVAO07+e5C5CqPD7K2fYX/tHMncIAXfIRSyCUz9 GGaPgxUuzlMfroN4ByR6INFd/KneXvyvFO8pCkOZ92NFsLw4Kgb3AiXYZHOzF2H6Zbjy+zB3 bN0qN9JOtuGvkav7OG64RbGSYpWJbSe4cvZ6gs1ehMwIOCsQUA9HEREREdnEX9ADAYyCq/ao DTBNk2QySV19PZdHZhSQDbAsi/r6eqqvTmMYpgKyAcFgkLa2NoYnptCJvPF62NzczPxKTo3L N/JsyF0ttm9kRmHpAsy/CXOv4+XncBbnwD4FHkRt2JKGdNQl4Nt4DrgWxalWnOXiDxTLmj8B hgWRBkjuhJoDkD4EVT1Q1QtrowQ9YKqqqghH45j34HxQm+WeXFNTQzAUxrR0P9n4c02KQChc fOlANu/zu0Igm5abhbnXYfA/weQP1j9XhOrI1r9Atv4FnGinYiUlTnw7npXA5NqXas8p9oJc HYLkQwqQiIiIiGxKhmEQjUZZLuTw1DD/ngWDQXp6ehibnOX4mSv4vmLyXkWjUfbs2cP8Sg7r tVMKyAYkEgkOHz6MfeQ4prJDGxKPx3nsscdYyjoYxvEHOxi+A4XFYkItMwLzJ2H2aLGtLD9V bO8obVv8j2lAfTUkIhANFf/tX1/9Fn/HhexE8WfqJxBphMafhabnILmr2MMtmHxgEm2WZdHZ 2Ukq3UAoHNFJuQHhcJgdO3YQq0oSDIYUkA0IhUL09vYSTSQJhcLqGb2JKcEmm/chYvEcDPxR ce61G1dZMXJ1HyXT/Fmc2FbFStax4zuK87CtW7gISxeVYBMRERGRTc00TQzTVHptg7FLJBJU VVdjmhau6yoo71EgECCZTBKPx9WDbYOCwSDpdJpoNKqxvcqoh7W1tURjsQe3Qdl3wF6GzBjM HoHhP4PpH4OTue3mhgFrHVwMAyJBAAPDDOBaIYIBH9MqgOHjWXEM3wXfwfAK3JJ68+xiQm/g PxZ/Gp+D7l+B+ich2lwcWvI+ZxgG8XicYCiMpR5sG2JZFtXV1QSCIfW+KvO5xgoEVQ83+31L IZBN+CQB2avQ92UY/ur6N3IMi3zyCVbafw0n2qVQyS3ceC++laA4HMe1B8XCIixfUnBERERE RO5jmoNNMVQMFcN7mu+BVygm1sa+AYN/DHPv3IvPNCAYMMjaFr4RBMPk/LiBH26gpW0LzdU2 hnsZN2iSq30G017GKlwlkOnHcDOAi+E7xb9/s8mXYOZVaPsE9H4R6g6DGbrve7PpHFYMFUN5 t5Rgk83HycKFfwEjXy/+/9pzhhHEifWw1PuPcSJtipPclmfFccMt+FYcw10pLrSXij3YRERE REREREQ2o+XLxV5jI39enObCs9/FL5lYFoStGIHko0zX/HWcxE7+2df+OU2NDXyhtY6e4DEC wWpWWr9ApumzgA++j2XPElw+RWjhCOGFlwmsXr79n3CzMPJnMPtaMdG29dehSiNKiYiAEmyy 2fgenP8tGP1LyM9Q6oFkBHCjW1jY/lu4kXYwVHXlrRg40U68QDXWjQm25b5ib0hTdUdERERE RERENgHPgewoXP49GPsm5MaLbRhvk1zzjSBOfAf51OMUUocw3QzR8T+mdvk41bODFJbb+c3n LlGX8GgPQ9SvJdfwAtmGn8c3r88p5phh3GAt+eQhVls+T3DlHJHZ7xGe/wmmPXfTftqwOgL9 fwQLZ2Dbr0PbJ+/ZsPu+r95Bit8d+ZyqWw8etTTL5tL/74tvxWRGipOsAhgmTqyb5a7fwEns xjeDipO8LSfahRdMYeXHr93dHLDnYXUQqnpAs1qIiIiIiIiIyPspM1ocCnLkz2HxHOQmr7eF 3aSYVNtOPnUIu/oAbqQdN1SPF6zF8F2ccAuRhVewMn0E7SViIZ88SVaS+/DanqGQPIQXSK4v 1LDwrTi+FccLpvHCzdhVu8k0/QKRuR8Rnfp6MdG2NnSk70BhtjhkZGEBFs9D769BKHVPDRlp 2zarq6sEg0Gi0ajmCHuPCoUCmUyGQCBALBa7Y/FzXZdstjiyWTQavavzkPm+Tz6fp1AoEIlE CIVC77h9oVAgn89j2zaWZREOhwmHw6pfDwAl2GRzcHMw9SO48vuwfKU45nTxbo8T62G15W+S r3kG3wwpVvLO1SnahX/zg6OzCotnINGtyaZFRERERERE5P2Rm4TpV2D8WzDzGixfKPZku5lh 4gXrKVTvo1B9EDuxHTfScW1ajChrLw/7gF39CG6kDdOexXRW+JOv/mtq0o08v+MFutOP3Zpc u93fClTjBapxo124kQ7sxC4i098mtHgM01m4vq2zCgunoDAHuWnY+mvFtpZ74IV43/dZWFjg +PHjNDY2smvXLiKRiOrke4jf/Pw8p06dora2lt27d9+x+OVyOc6fPw/Azp07SSQSd+0z5nI5 rly5wvT0NLt376auru4tE2We57G0tER/fz9jY2MUCgVM06Suro7e3l7q6+sJBJSCuZ/p6N50 As3MzTM+McXK6iqBQIDamhRbOtsI3JAlX1nNMD0zx/Lyym3LqapKUF9XSyIeu37vcV2GRsaY mp7FcVxSySpam5uoSVWr26ibhYXTcP7/gYWT4Oavr4q2k637GLm6j+MFqlVJ5d1VqWjHrQ+P TrY4jEHrzylAIiIiIiIiInJ3eTbMvwET3y3+zJ8E59a2Rd8M40Y7sRN7sKv2FP+b2Pm2STLf DBV7tUXaATg28VU6zCYOGe3vnFy7uSwjiBPrvVZeG058O+G5lwhkrmCsvRDv2bAyAAN/CF4e tvwy1OwFK7apD4Hv+2QyGU6fPs1DDz3E9u3bVS/fo9XVVc6dO0d3dzc7d+68o39rrc38brWd e55HJpOhv7+f733vexiGQXd399v+Ti6X4+zZs5w6dYqWlhaamppYWVnh7NmzzM7O8uSTT1JX V6f2//uYEmxrJ0M+z+mzF3j12EmGRsawHQfDMIhFIjy6fw9PHz5IXW0Ky7IYHh3nBz9+lYuX +zGtW7PXu3ds5dmnHmdrTxe+77O0vMLLR17nlddeZ2U1g+d7hENhtm/dwlOHHmHH1u4Ht7uo VyhO4nrly3D1u+tXherJ1T5HtuETuOEmVVJ519xgGi9Uh29GMLzctYUZWHgTfF8jRIqIiIiI iIjI3ZOfg+mfFKdFufoDyI7fuo1h4US7sav2UEgepJA8iBPted9Gc/LNMPnUkzjRHpxIO9Hp bxJaPonhLK1tUezFNvCHxTaXrs9D+iAEN+8L8oZhEAwGCYVChEIhTNPEcRw8zyMQCJTaZz3P w/c8PM/F9/3SskKhgHOtzTgYDK77nbVtbNvGcRx838eyrNJ2pbj6Pq7rUigU8H2fQCCAZVl4 nodpmqVtfd9fV1YgECAYDL5jG/Ja+bZt43leaR/WhlhcK9e2i/P83bh+bf9N0yQYDK4rcy1O pmkSiUSIRCK33Ze1bdfidnNsLMsqfca1OLiuW/qbgUAAwzAIh8N0d3eX/t/zPFzXLR3HGz/f 2rG83XFYO1Zr+xYMBm+b7Frr3XjmzBlOnjzJlStX2LJlyy3bOY6D67pYloVpmiwvL3Pp0iXa 29s5fPgwiUSCQqFAIpHgtddeo6enh5qaGvViu4/pyF5z/mIfv/9Hf8qFy/10trXQ3FjPaibL a6+f4pvf+yH/x2/8D3z4uaepSSUZHb/KSz9+lcv9gzy859ZM/dLKKrZT7NqdyWR5/eQZfut3 v4xpmezdtZ1YJMbA0Cgn3jzL2MQkX/zCZ2ltanzwgu67xTmxhr8KA3+0fpWVIJ96imzDJ3Di eptE3usTUwA33IoXTGPlx4rL3CwsXSgmdU0LZdlERERERERE5I7ybFgdgskfwuUvwdLZdSM3 AWCYuME0TnwbuboPk09/CCfSCmyOl/HdcBPZpr+OF2nBu/qnhBZewypMXt/AWYXBPwF7pTgF TP0TEKrZlIfDMAwikQjt7e3U1tYCMDY2xtLSElu2bCkNQ5jL5ciuLrO8uIjjONi2zdTUFMPD wywsLGBZFul0mo6OjlLypFAoMDMzw9jYGPPz89i2TSKRoK2tjZaWFqLRKL7vk81mGRkZYWxs DMdxqK2tpaqqilwuR3NzM3V1daVkz+joKNPT03ieR21tLW1tbaTT6XXJr3XVzfNYWVlhYmKC qakpVlZWqK6upqOjg4aGBgKBAIuLiwwPDzM1NYXruiSTSVpbW2lsbMRxHAYGBojFYnR0dJT+ Ti6XY3R0FNd1iUajpf283bxotm0zMDBQ2p81Kysr9Pf3U1dXR1NTE47jMDExwejoKMvLy4TD YRoaGmhrayOZTGLbNjMzMwClYShHRkZKybipqSlWV1dJJpN0dXWVhmJ0XZe5uTkGBweZnZ0l HA7T2NhYSqJ2dnYSjUZvreeuy9jYGMPDw2zZsoXa2loWFxdvie/MzAyjo6O0traWho7s7e2l paWFVCpVSoSm02kMw2B1dRXXdZVgu4/pyFLMUH/jOy9xuX+QT3zkZ/mVz32KdG0NmWyOI8dO 8Hf+wT/iq1//Nnt2bacmlSSfL+Dj8/Thg3zpt//J25Y9Mn6VP/3LF5mZm+ff/PY/4bEDe4mE wwwMjfKv/t0f8sprr9PT1c4vf/aTD1rUIXsVRr4OF//1DXOuFbuiF6oPkGn6DIXkQVVQ2dgD YKQVL1R3PcHm2cU3xPIzYLWCYSlIIiIiIiIiInIH+MWpKpYvFUdtGvxjsJeKy9cYJr4ZxY20 kqt5lkzrL+NG2vCNzddc65thcrXP4oQ7iIX/C9HJv7iWZLv2eTwbRv4c8rPg/jo0fwSCVZvy yMRiMR555BESiQS+7zM0NER/fz+NjY2lZdlslpXlBRbmZ7Ftm9nZWV5++WUymQxNTU1kMhn6 +vq4evUqhw8fJplMMjExwZEjR8hms9TV1WHbNqdPn+bs2bM8//zzbNmyBdd1uXLlCkePHiUW i5FKpejr62NqaopcLsfHPvYxampqWFhY4NixY0xMTNDQ0IBpmpw5c4bh4WEee+wxmpubb0lu +b7P6uoqb775JufPn6e2tpZgMMi5c+fo6+vj6aefJpVKlXpnrZVx4cKF0vpkMsnAwAD5fJ5U KlVKQi4uLnL06FFaW1vZs2cPe/fupaqq6rYJtkKhwPnz56/1AnTX7duRI0fYt28f6XSa8fFx fvzjHxMOh0mn08zNzXHhwgV2797NwYMHKRQKXLx4EYD6+np83+fNN99keHiYpqYm4vE4+Xye M2fOMD4+zgc+8AFqa2uZn5/n6NGjjI6O0tTUhG3bDA0NMT4+Tk9PD42NjUQikVt6sZmmSX19 PU8//TTxeJw333yT1dXVW2K8sLDAhQsXiMfj1NXVUVNTw6OPPkogECgl0QqFAnNzc/i+TyKR uG2c3i1DHQQ2PSXYANfziMejfPCZJ3j26cdJ1xbfsohFIxw8sJfurnbGJ6fIZLMA5AsFXNcj Ggm//c3H97k6Oc2xk6d54rEDPP7oPkLXMv9bOtt4/NF9nLt4mSPHT/H5z/z8gzUWq5OB0b+A i/8S7MV1lw0n1s1K+xfJ1zyBehnJhqtYuBU3lGbdOz2+A4vnIFIPVlRBEhEREREREZEK84vt XrNH4cT/CnOv37qJYeEFasinDrPS8fewq3bfA5/LwIn3stLxd3FivVT3/VNMZxnwrn/uqR+C s1wctar902AGN92niEQidHR0YBgG+XyeQqHA6urqut5WxeEInWs/LrOzswwPD3P48GEeeugh PM+jr6+PmZmZ0rCRs7OzWJbFE088QUNDQymZ9uKLLzI8PExbWxvz8/OcOnWK2tpaDh06RHV1 NbOzs7z00kuMjIxg2za5XI6+vj76+/s5ePAgW7duxTRNRkZGePnll7lw4QKpVKrU226N67qM j49z6tQptm3bxsMPP0woFGJkZIQTJ06UesINDAxQV1fHwYMHiUajjI+P09/fTy6XK/Uue+21 15iamiKVSuF5HpOTk8zPz/Pwww+TTCZJpVIYhvGWw1Vms9l18Vzbv+XlZWzbxnXdUu+8j33s Y7S3t5PL5Th37lypx6Dv++RyxWlffN/H8zyWlpaYn5/nqaeeoqenB8dxeP311zl9+jQ7duwg Ho/T39/P4OAghw4doqenB4CLFy9y8eJFlpeXbxm6co1pmjQ0NADFBNnaUJU3b9Pc3MxTTz1F KpUqDRN5Y++0QqHA2NgY586do62tjcbGxveUYPNcn9yqg5P3yGYLbLf3El6tZXXWYzGev++u llbAIBwPEAzfu9NnKcEGBCyLv/ernwcfAgHrNif/CjWpJKFgcczjfL6A57pEo2WjSJ4AACAA SURBVJG3LTebzXF1aoZMJse+PbswjfUVpbWlkfp0LZNT08zMzlNfV/uAPGf4MPRf4Mq/g9zE +otIsJbl7n9IIfkYGKqesnFupAUvWHfTXcqBxTeh/rASbCIiIiIiIiJSeYVFGP06nPnN4vCQ NzMM7MRuVls+T7bh5/DNe6t9wgumyDa8gBduJHXxf8EsTIF/QzJl/iSc+b+Kvdq2fH5Tfob3 kvAwDKOUQBkdHSWZTJJOp+nu7qa7u5uqqioCgQAdHR3U19dTVVWF7/vk83l836dQKJDJZHAc h5mZGWZnZ9m3bx8NDQ0Eg0GCwSC7du1iamqq1HtuYGAA3/eJRqNks9nSPliWxeDgILt37yYe j69LADmOw+TkJJZl0dvbWxqisKenh2QySTAYxHVdwuEwV69eZWhoiKamJurq6qivrycajRIO h2lpaSESiTA+Pk5HRwee5zE4OEgqlSoli8rtJLI2r9pa77JAIEBNTQ27d+8mEAgQi8VYWVm5 7e91dnayZcsWampqcF2Xjo4OTp06RSaTIZvNMj4+Tk1NDVu2bCGVSgGwdetWent73/G4v9P8 doZhkEwmqa6uLv37Rvl8ntHRUY4cOQLA/v37S8nId335yLmMX1xh6mKWfNZm/9xzVF+KM/hS nsWG6fvqUmkYBrF0gK4D1dQ0R7lX+x4pg3FNOBS65YToHxrlv379m0xOz/KFX/wUzU31xXWF ArlCgZGxq/y///YrnDpzgaXlVRob6vjgM4d56tCjNNSnWc1kmZ2bJxCwaG6sv6WSVCcSJKur mJ1fZGp69sFJsI19vTg289LFYrKteErhmyGWev8xhepH8a2YKqWU98AXasILpimOWX7tQc93 YOHMuiFJRUREREREREQqYmUABv8I+r4CmdFiT64b+FaCbOMnyDT+Ak58B74V594bvcnAt+Lk k4eY3/47VPf/M4KZi9fbWnwXli/DuX8Gbha2/DJYkXvvWF5rsjRNk6amJh599FFOnTrF2NgY yWSS5uZmenp6iMViBINBAoEA8/PznD9/nmw2S6FQYH5+npmZmWs94lxWVlZwHKeUlAMIBAIk k8lSj7RCocDU1BQTExOcOHGCWKzYRmrbNktLS6TTaVzXxff9WxJsCwsLRKNRYrEYhmGU5pxr aWkplb13716OHj3Kj370I6qqqqivr2fLli10d3cTjUZJJpO0t7czNjbG4uIitm0zOTnJ9u3b qaqqKiu5ttZ7zLIstmzZwsMPP8yFCxe4dOkSNTU1tLW10dvbW/rMt9Q8w6CqqopwOFz6fOFw GMuy8DyPfD7P4uIitbW1hEKh0r5GIhFqampuGfJxw2fATTFY6203MDDA0aNHAXjyySdpb29/ y/ny3oppGUSrA6TaQuSyBkvhWaJJSLSa1DRH7qvLpQGEqyyC4Xt7Gh8l2G4yMjrBt77/I777 339CvmATDAb4h3//i3z0g89Qk0oCxQTb5NQMC4vLRMIhmpsaqa3J8+b5S5y7cJn+wVE+9cKH iERCZPM5TNMkHotyc4YtFAoSDodwXIfVa8NP3vdmj8HAf4K54+uSHF6gmtX2XyNf8wxeIIWG hpSyn4PMEF6oHi+Uxixce8PDd2DxDLhKsImIiIiIiIhIBU2/UkyujX/7WnJt/RB5dnw72abP kKt9DjfagW/ey43lBr4Vo/D/s3ffUXLc14HvvxU658kZORBEIAgmECApiUGkZJEKlkXL9srW eQ7PXj8/79v1Htv7wtprr205rZNsrW2tJCtZsiRLsihKEJMIkggCSABEHAAzg8mpc6r0e3/U zGAGYACHBDgA7uecwQyqerp7bld1/bpu3ftL3UZh5X8mfu5vCeb3o3l+Sz88y0+yHf8zcOuw /KcgtDQLCzRNQyk19wV+skrNvH4aEIvFuOmmm+ju7mZ8fJyhoSGOHz/O2bNnuffee+ns7OTo 0aMcPHiQTCZDe3s7mUyGer3OyMjIgoSM67r+/GTzEmSzy2aZpklHRwdr1qyZq1RTSrF27Vqi 0eirJrpm73d+G8TZ5I/neYTDYVauXEkmk2FiYoLh4WEGBgbo7e1lx44dbNu2jXA4TFdX19y8 ZaVSCaUUPT09l5wsmn2+85/DbGvI2fWZTIY77riDNWvWMDo6ytDQEPv27ePcuXPcd999r5hk m63km/3bZ5NsF8ZiNgE5//EvXPZWma06PHnyJPv27SMej3PrrbfS3d1NKBR6w/cXCBm0rojR 1BOlWqmxL7mLu7pvoWPrZlYsz1xb75many4xAzpX88xZkmC7gGEaJOIxGhvSZPNFJiam2Hfw MBtvWEdjQ4aAabLxhrV89McfJhGPsfnGdTQ1ZPxy2YEh/u4zX+I7u56iu7ONO2+7ee5qh1d6 05tbomBwaITPf+Wbb+q5nxsaoW5ZHDl2kv/w27+Hpi2t3qWdKYuPrnuRTu8FNLswt3yqYvLd k1Ge2TWIG/on/Iqjt8fA0Ai5fJHHdj1D75l+2SEW4czAIFPZHN9+/EmOneh9W5/LzelDPNDu sjo9O9JwodjLf/+TP2WsmkappfXu3T84RN/AEKVyhV/7zf8mG9MinB04x+DQCI8/8UPGxicl IItwuq+f4dFxvvX4E5ztH5SALMLJM2cZm5jkq9/8LoePnpSAvAGWbVO3LH74/H6mpnPEYzEJ yhs0O2fwU8/uYXxiimhEWiK/UYViCdf1+MHTzzMyOk44FJagvEFT2RyWbfG9J59lcHhkrtW+ eHWe5zIyNMjLR17CNSLoZkjGg4s0Oj7BsZOnUUpJDBdpeHSc46fOEAiYEsNFGhwe5dTpPoZH xiWGizQwNMzZvkFyueKSj6GpKx66IcctmZdJ11+E2tjC93gF3z+R5OnBEJOBPrzgt7nc576G R8fJF4p86rNfpmGmYOBy0bwa6ZrLQ8sj3NFtEQ3OJIo8G4onofdvOfDSYR4/3c5oYWnNyeY4 DsOD/YyNDPOjo2dJJNMopcjnpslms5w63cef/M0/EouEqdWqxOMJAsGgXy02PcXZ3hPsenY/ qXQD5/rPoJRixaq1hCPHAY1iPsfxl19iz4vH+c5TeykW8vSdPsn+I6dpaWvHMEwc22Z4aICh gT6eP3iceCLJQN9pLMvi4PEBYrE4aBqObVHI5/02hekMZiAwlzDSNA3XdRgeHGByfIwnnnuR VDrjtyO1LKYmxwGIJxLUqjXCkQjhSBSlPMqlIn2nT7HrmT2sXHsD4XCEaqVM/9levvKv38Vx HaLRGAdPnCN0CeNi27I403scq14nl8vzwr4XyebyuPUqJ44dZt/hXlq/8T0q5TKObZNIpdB1 A8e2GBsdZmTo+3z36b0kkynO9Z0BDb6/+yAoxZlTxwkEQ+za/SKBYNB/rbLTnDr+MnsPnSLT 0MjgQB+Vcolv7dpNLJZAAZVykZPHjhAIBHn2wHEikejrbhejw+eYmhjnuYMnSKbOt3n0E5ge mqbPxX16apLB/rNEYzHaO7vZffAEum7MvTaLEYtFuO3mLYy4g7iBGwlENEJRQw4OS/EYICFY qCGT4q47b2XdmhXk8kVOnDrDF/7lW3zmS1+jIfNzrF+zkk0b1rG8u5NoJEJjQ3rudzesW83x 3jN8+ev/xvFTZ7hp0wZCoRCe51Gt1ea1Q5w9ieRgWTamaaAbOmf6z72p5z6dzaGUR6Va5Uz/ 4Jvuh/uWHWhRBHSLtZUfYmYGIW7NZRerboSztWUcKG/gzATA6Nt+MsB1XbK5PP2Dw7JDLGY7 nM7hOC7T2fxFcxpeaU2uItsYB6ZnliiwC2SHXmag2IGtltbAbnI6S61eJ18ovun3g+vVxOQ0 dcsily9IDBcdwyyWbTOdzUsMF7svT2WxHYfJ6SwBieEb+4Dr+leKFoplBoZGCC/iir/rnWX5 Vdr5Qon+weGL2qCL11et1fwP64Ui/eeG33BbFwGlchnlKXL5An0DQwsmfhevzPM8spNjFIol 9JCOHkCOw4uULxSpVKsopSSGi5TLF6hUa5iWITFc7OfiXJ5qrY4n2+GiTc18Pi4Ul/LnY4Wh uWwIHyQSP4thFyHkzlurUfNCHCttYH+lk2OVOKW6x5U492VZFpoGo2MTFEvly/54kcByWkoN NNd6WWueJaTPtov0IH+UyPhZjKE1TOTWUfSWThWO8jxy0znGJyZwjx0jkcqgPEU+N0W9WqFa qzM8OobmuUyOD5NMN5JIpkHTKJcK5AolzMkshUqdsYlJlOehBSIEgiEc2yY7PcHYyAgOBp4R xvNcKnWHY8eOMjYxRSAUxqpVGR8dpFouEU42Ei/VKNVspsZGqdQdkqkMmqZRqZSZnhglnkzT 2NyGbujUqhVcxyESjWMYBuVShalslurRo6QbmtB0nWqlRHZynEQqQzgSZWpilEAgSLqxGdMM UK9VmZzOEo5EMQdHCASDuI5DoVxjdLAfTdfpWraKc8NjrztHGeAnnPIlclPjVCtVstlpTp/2 qBTzTE9MEoylqVgeuewk+elJGlvaiETj/vh7epJisczo+CTZQpnxiUm/Gs6MoJRifHIawzQh EJ1LMJaLBSazWbRglFLdoVS1mBifoFS1SKQzoKCYzzIyeJZUQzOBc0MEXydR6Lou2clxCrlp 9PAw0VxxrirPqteo16qEwhGCwRD1WpWRwT6qlTLNbR3UB4bm4qRpGmYggBkIvuHz9JFwiEgk jOXackBY4uSTDn5WOl8sYcy0cuzuaKO7ow2A27dt4dip03zvyWd5+MF7WdHTRTqZIJ1MXHQ/ hmGwoqeLeCxGoVjGdV0yqSSu6zI+MX1hfo1iqUShWCIcCrF+zUp++eMffVN/x/4Xj3C2f5Dl PV380s/9JIa+NCrYNLdEcOxb3KrniOvOXOWeMiLUI5tx04+wtXktW5fAc91/8DDffPwJbrt5 M+/YebvsHIuwe88Bdj3zHHfcsoW7tt/ytj6XBn2YRqWDM7Bg+UcfWMNE7D4cI72kYrfnRy/x 2K6nWb1yOT/94YdlY1rM9rf3AI/tepqbNt7Ajz/8oARkEZ5+bh+P7Xqa7bfcxPsefJcEZBGe +OELPLbrae7afisPvGOHBOQNqFSrvHT4OBs3rOU9991NS1OjBGURJ/T2HTzMlo3reei+u2nM pCUob9DI2ASHjhxn66YNPHT/PaQScQnKG3R2YJDjp86w7aaNvOe+e/x2+eJ1P5OePHGcx7+n UbQ00ANv+vPh9eroiV6+s+tpPM+TGC7SoaMneGzX00TCYYnhIh04dJTHdj1NU2OGX/zYoxKQ Rdh38DDf2fU0y7s7+dijH1iCz1CBU8Qc+z5b9Gka9DKmNm++Nc3EDbZQid/FZOweVjY0sezW K3ee7o/+8u9pbsjwzrvuYHlP5xV5TFNzqIRPUdOfIFjei+aeT+zd0FKloSHHXWaSXPxuiHYt jVdRKbLZaV4+fJix0RGSqZSfEDHW0t/fT093Jx9634O0Njdy7OgRRkdGiMfjGKZJtVKh4a7b WL9+A+FIhNO9pzhx/BiJRIJ4IoHneii1jlwuS0NjI5u3bCUSiTAxMc7pU6coFgsYpjmTGOum UCiwY+dddPcso1Ipc7q3l5HhIULhMLqmUywWSG67kfUbbqS5uQXbtjl18gTZ6Wk2bdlCOp2h VqvR33eWvrNn/IvENI1KuUzTnbewdv0NRMJh+s6e4dSpkwQCAaLRKNVajeCmNaxbv4G29nZM 08TzPMZGR9jzwvMEg0Hu2L6DTEPDJSWJXNdlYnycQ4de5NOf+2fiIY0bVnXR3LCJfD7P+hs2 sGLlSrLZLEePHCGfz5FIJkEpqtVmOru6WbN2HaB4+chhNDQ2bNyIUoqXDh4kFAqxactNhMNh PM9jYnycAz/ax9p161m+YiX1ep3+vrOcG+hHKYVhmBjGavr6Guns7OLOnXcRjyde82+wbZvT vacYGR5m46bNNDY1oes6nucxNHiOE8ePsXbdelpa2xgeGmT3sz+kkM+RSmcIzrvAMRqNcsOG G+lZtnxRF+3VLRvTkKq1pU4SbEClWuOJH75AMGCyddON9HS1nw+QYdDd2Y7ruuQLRcrVKqPj E+QLJVpbmmhraVpwX6VyGdu2CYUCZNJJWpubCIdCHDvZi+u5mBhzb+AjYxNMTefo7Ghl5bIe 1q9Z9aYPCoZh0NLUyIP33r00dkCnDJO7Ye8uKBfO95/WTJzoOuj8CN2tP0H3Eqm2q1RrfO+p 3axeuYx33bVddo5FmJrO8dzeA6xdveJtj6Fu54gNDUDf48z1awVu6tHghpsgtmxJxa5u2Ty/ 7yArerp46L57ZGNahFK5wu49B1i1YpnEcJGyuTzPvrCftatXSAwXaWxiimee28eN61ZLDN+g fKGIYRgs62rnnh23s7y7U4LyBg2P+u1flvd08s6dd9DZ3ipBeYN6z/Sj6RorlnfxrrvukETv Irx05BiGbrBqeQ/33XMn6VRSgvI6bNumMRnh2MuHGcvX8DDkGLJI8XiM/S8ewXVdieEihUJB 9h04RCIelxgukqZr7D3wEp3tbRLDRXJcl+f3H6Snq2PpxVB5YOVg7AlwvgelIfCc86v1EG64 h1rTu3G6Ps7G4JUfj33y01+kpbmRW27ayOYb11+5bd+7HSe/FmvQIJh7Ds2tzK1rNQdobTgI q26G7vsh3LI0tjXHYeqeHQwPD1Or1YjH4zQ2NvLYU3tYu3Yd9+y4nU0b1pF7xw5GRkYoFAro uk4ymaS1tZVMxq8wKxa3MzQ0RC6XwzAMUqkUDQ0N1Go1HMehra3NT6aVy1Qqd1EqlXBdl1Ao xMDAAC+//DLvuvtO1qxZM3N/RcbGxshmsziOQywWo62tjcbGRgKBALZtM3bTjVQqFTo7O4nF YiilqFQqjI2NMTU1hW3bxONxOjo6SKfT6LpOuVxmZGSE6elpXNclGo3S0tJCU1PTgjnDKpUK d995G4Zh0N7eTjh86W3TLcvi/nfu5F8ff4ZVq1bxwUfex7abNlOpVEgkEjQ2NuJ5HpPvupvR 0VEqlQqmaZJKpWhvbyeRSGDbNrffvBlN02hpaUEpxW1bN2EYBm1tbQRmKtiKxSJ33raVhoYG 0uk0tVqNcvlmyuUy1WoVwzAwDIMnnniCVCrFg/feQyLx2gk213WZ2raZYrFIS0sL8XgcTdP8 jgPZLOPbb6W5uZlkMsn09DQ7bt+GbS+sNNM0jUAgQGtrK01NTYvq6FCt1ggEJH2z1MkrBDiO y1f/9TFy+QIf+8kP8p7EPYRnWjtOTmc5erwXQzdIp5Ioz+Mb39nFM8/t5YF33sWjH3wv0UgY z1MUiiUOHDqKZdt0tbfR3NhAa2sT69eu4oV9BxkYHKGjrQXTMMjmCxw+eoJavc6WjesJBq/B 1jNeHXKH4eX/DqXT899icEIdVFseptryMFf1LIZiaW+CgRRusBmlh85PtAtQOOEnf4UQQggh hBBCCCEulVJgZWHsB/DSb0Nx4dzzSg/hxNZSbf1xyu0fRRnR6ys8ehArfTtFI0pCWQRze9A8 i7mLnqcPABpoJiz7CARSb/tzNk2TlpaWuaSPrusYhkE4EiMWT2CaJqZp0tjYSCaTwXX9SkXD MNB1fa6qK5lMEo/HL1rvbzb+3z8xMcHRo0dpbGxk+XK/qqlQKJDP54nFYiQSCTRNm0vgJRIJ XNfF87y5RNHs4wUCATo7O1FKLWhJGIvFWL58Od3d3XPr5v9eIpEgGo2yfPnyuWKN+etnRaNR Vq5cCXBJrSHnCwaDdHZ2Ek2kaW3vZMWKFbS1taGUQtM0NE2bS5Q1Nzfjuu7c85x9rFAoRFdX 19ztAXp6ehY8H03T/IrBmQSYbdv09/czOjrK+vXraW9vx/M8+vv7qdVqrFq16pIqyQzDoLm5 maampgWPr+s6DQ0Nc0lVTdNobW2dSwBeaPY2mpz7vqZJgg1/3rUdt2/j81/9Jl/46rcolSvc uG41pXKFp57dww9++Dy3b9vC8p5Omhob6GxvZTpX4PNf+Vd0XePWrZupVGt887Ef8NSze7h1 62a23bQR0zTp6ezg/e+5j//8O5/gdz7xl/y7j3yAVCLO957aza6nn+PGdat58N67r8EjqgeF U3D6H2HsqYWrjCjV1g9Raf0gSpd2MeJy0lCBBtxwF2Zl3qC3eFISbEIIIYQQQgghhHhjnCKM fBde+i9Q7lu4TjNwYusodX6causHQbs+W7spLYCV2EJh9e+QOvbrBMovzyTZZkz/CE79Degm LP8Z0N/+ogNN0y6uMLogMTKbFDJepWPYa62fnb/LNE0KhQInTpxgeHiYaDTK1NQU4+PjbNmy hUwmsyB5NJtse63n/UrJG13XX/P3XuvvuPB+3kxM58fklZ7rbNxfrbrrwsd/pedzYQJM0zRO njzJ+Pj4XIJtYGCApqYm1qxZc8mtGl8tttorbBeSQLu+SYJtxs999ENkUkm++LVv8/t/+kkc 10UDwuEwH3zP/fzSxz/KquV+lvyh++4hGonwD//0FX7vTz6JpzwUEItEeM/99/CxRz/Axg3r AEgl49x793b+3//4q/yPT32G/+3XfgvP84jHYzx079389E88woqermsvoNVhGPwG9H32olWV 9keptj6CF2ySDU9cdm4ggxvuXJhgqwyAnQflXrcDXiGEEEIIIYQQQrwBbh3OfQ1e/n3/vMIF rPgmSt3/O/WmB+Rcg2bgRFaQ2/BXZI7+Mmb52MIkW+4IHPtT0AKw4meuj5BoGqlUim3btnH8 +HFGR0fnlm3fvp1ly5YRiUghwpthGAY9PT3s2LGD3t5eBgYGiEQiLFu2jFWrVs216RTirSQJ thnxWJRHHrqPu++8lelcnmKpjGmaNGXSJJMJGjIpAjPZ9Fg0wjt23MamDWvJ5gtMZ3NoaLQ0 N9KQSZNJJefmP9M0jXQqyfvfex933n4zY+MTuK5HJp2kpbmJTCr5pq4GWJKsLJz7F+j9lD/4 mKfWeC/V5vfiRpYDkt0Xl58KpHFDFySxledfaWbnIdggQRJCCCGEEEIIIcSr8xwY+DKc+qR/ PkF5C1ZbmR2Uun6BevoOlB6UeAFKM3HDneTW/gHJ3v+PYPGl89N3KBeKp+DYH/nJyJ4PgR66 5mNimibt7e00NDRgWdbcsmAwSCAQkEqoN2m2Reb69etZsWIFruuiaRrBYJBgMCjJNXF59msJ wfkdMJmMk0zG6epow3Fmd8DAq+ysUWKxKJ0dbdiWP4lhKBR81bLcVDJBMhGnp6sdpRQB07w2 d2rPgsF/hbOf86vY5nFia6m0/wx2/EaUFpCNTlyZTdJM44Q7L15ROguWJNiEEEIIIYQQQgjx GpTnJ9dO/yPkDoNnL1hdz+yk1P2LWMlbUUZc4jU/dFoAJ3YDpeW/Trz/LwkWfnQ+yeZZUDgJ R//QT661PwCBxDUfE8MwiEajRKNR2UAug/kJNSGuBEmwvcob3aUmvwxdxwiHLnkHD13rO/fI 49D/Jcgf9a9GAUDHM5OUun4eK3WLDDbEFeUF0njhDvyKyXkTjpbOgJ2TAAkhhBBCCCGEEOJV KH8KlDOf8ecOc6vn1+ghrPRtlLp+ASt1m5zverUI6gGs1K2Uuz4OQzrB/F40b6bjlWdB/mU4 /sf+XGyt90AgJUETQlw1JMEm3jrT+6Hv8zC1Z96AQ8MzE1Q6fppa0wN4gbTESVzhgVwYL9CE F0ij29nzK0pnwZIEmxBCCCGEEEIIIV7F2BNw+u/9c11OaW6xMmJYqVsod/0CVno76jpob/hm KD1MPXPXzDxsaibJNjMnm3Jh8gU4+VeAgpa7IZiRoAkhrgqSYBNvjco5OPO/YPyZBUkLz0xQ b3gn5c6fwzMzyLxr4srT8Iw4TriH4PwE2+wcbEIIIYQQQgghhBDzeTbkj8CJv4KJ3WAX5lYp I4aV2EK54+eoNbxDYnWJlBGj1vBOUC6aZxMs/AiUc/4Go98HPQia7ifZpJJNCHEVkASbeLOH R3DK0P/PMPhNqI7MO3BGsRNbKHf9PG6oTUIl3r6t1IzjRpZB8aXzC2tjUJ/02xHIBMRCCCGE EEIIIYQAP7lWPgvH/9xP+jjluVVKD2PHb6Da/ii1pvslVm+QMhPUG+9FAzSvQqA0f4oZYPjf /FaRehCad4IZk6AJIZY0SbCJN3NYBKcCY8/AiT+H6vD5NZqJHVtHpf1RrORNEirx9o6NjThO eNnFKyqDUJuAaKcESQghhBBCCCGEuN4p1794vO+LcPZzzJ/LXWkBnNhqqq0fotLyAYnVInlm klrjvSjNIHH2jzCrfQvizNC3/O9GCBrvACMsQRNCLFm6hEAs/ohoQ/Ek7Pslf/ChvJkVGm64 k1rTg1SbH5E4ibd/fGzEcSPLL15RGfSr2IQQQgghhBBCCHGdU2Bl/aq1l3+fBUkfNNxwD5W2 R6m0f9RvYygWzU+yvYvCqv+CF0izYEoZ5cLQt+HoH0L24MIKNyGEWGLkaCAWr3QGDvw6VIcW HOy8QIpay/uodPw70GTONbEUBm4JnFdNsE1IgIQQQgghhBBCiOudU4XRH8CR/+pPJzGPF2yh 3PkxKq0fRmnSEOytoIwY9fQO8mv/AGVEL1jpwMguOPifYPpHEiwhLgPPUTiWh+cpCcabIAk2 sTiFY3Dif8Dk3nmVa35ryGrTj1Fp+RCemZA4iaVBM1BmEjfYxoKroqSCTQghhBDiuqaUnFAQ QgiBf+H46Pfg+J9BZWThKiNKqfNj1JofQsmcYG8hDWXGqGfuJr/md3DDnSysZHP8CrYXfwOm 90slmxBvIddRZMdqjPaWqZUcZEi8eHLJhXjjyv0w+A0493VwqwtW1Zoeotr6/pl2fFK9JpbQ oM2I4ERXYFhj5xdXBqE+JeERQgghhLiOKKVwHId6vY5t22iaRigUIhgMYhjGgttZlkWtVsPz PILBIKFQCNNc+DF69r4sy8IwjLn70qSbhxBCXD0mnoW+L0DukJ/YmTudFeluaAAAIABJREFU oFPu+BlqTQ/hBluQc11vNR3PTFBrfDeaWyM29GnMymnm2nM6VZjaDwd/A7b8HmS2ypxsQrwV 42FPkR2uMdFbJZIyiSQCEpRFkgSbeGNme1H3fQFqYwtXJbdRbXkYO74RpQclVmJpHTj0MG50 NeT3MHdZhlPyW0Q6JTDjEiQhhBBCiGt9TKgUlUqF/v5++vv7qdVqaJpGKpVi9erVtLW1EQgE UEpRKBQ4ffo0Q0NDuK5LNBplxYoVdHV1EYlE/M9AlsXQ0BC9vb2USiVM06StrY1Vq1aRTqfR dWkaI4QQS17pDAx+E8afvuhC8mrze6m2PIIbWQbSGvIy0fACGWrN70FTNtGRL2OWj+Mn2RQ4 ZZh4Do78Ltzwn6DxVjmHI8SbHhODaynsioeSFpFvioz2xaXz6jD+FPR/EfJHF6xyw11U234C K3UbSlpDiqV44NBDONFVXDRxbm3c/xJCCCGEENc8y7Lo7e3l2WefpVAo0NDQQCwW4/Tp0+ze vZvx8XFc16VWq3Hs2DH27t2L67qkUimmp6fZvXs3586dw3EcXNdlZGSE3bt3Mzw8TDKZRNd1 Dhw4wKFDhyiXyxJwIYRY8geGnN+hafixBecGlBbATm6l0vEzONE1KD0ksbrM3GAL1eYfo9L2 49ix9QtXenUY+R4c/3MYe8ovABBCiCVALr0Ql0j5k4r2fREmnp8375rfeq/a+gFqjffhBZsk VGJpbsF6+OIEG8wk2EYhvlKCJIQQQghxjatUKpw8eZJ4PM7OnTtpaGjAdV0aGxt56qmnOHfu HA0NDUxPT3P48GFaWlrYsWMHsViM8fFxnnzySY4fP05LSwvBYJATJ06Qy+W477776O7uxrIs Dhw4wPHjx+nq6iIajS5oOymEEGIpnSiYmXdt4MtQPHl+uWbihTsodX4cK3EzyohIrK4QN9RO tfl9/ssw+s+Y5ZPMtYtULgx90/+ubGi5B4INEjQhxNtKEmzi0pT74cxnYezJBeXySg9Tz9xF uf2ncIPNEiexdMfNehAn3IPSAmjKPT9Aq41BdVQCJIQQQghxrY8HlULTNDo7O0mlUjQ3NxMM BvE8j6amJkKhEMViEcuyGB8fp1Qqccstt5DJZDBNk5aWFpYtW8axY8fIZrNEo1GGh4dpbW2l o6ODWCxGOBxm5cqVHDp0iKGhIbq7uyXBJoQQS1XuMPR+CnJH/KQNADpusJFq00NUWx6WtpBv AzfcSbXlEZRmEhv+3MI52QBGvgO44DnQ+g4IyflIIcTbR44S4vXZRTj9aRh5HOqT5z+g6kHs 2FoKK38bN9QOmnxwFEuYZuIFGvACjRjWyPnB82wFmxBCCCGEuLaHg5pGIpFg69at6LpOIOBP 5u66Lvl8nlqtRiKRQNd1stns3Nxss/OoBQIBGhoayOfzFItFXNelXC7T1dVFMOjPQa3rOolE glAoRDabxbIsQqFLbyumAOV5eJqO4ziX9Dfpuo6mafICCyHEJb/ZeuAU4dgn/G5N8y4k98w4 VuoOSj2/Ism1t5EbaveTbHqI+MBfY9YGOV/JpmD4cahnwS5A1/sh1ChBE+Jaf+tWCs/zUOrS 5oybbel+ucmRQrz+oGP4O9D/BSj3zVuh44aXUVr+H3CiK7mo7Z4QS5FmYsfWoNuTM1VsQH18 poJNyXYshBBCCHGNMwyDSCSy4IP3+Pg4R44cIZPJ0NnZiWma1Go1NE1bkBzTdZ1QKITrutTr dXRdx7ZtIpHIXIJL0zQMwyAcDmNZ1iUlyeYrl0qUCkVczeDUqVOve/tgMEhrayuxWEySbEII cancKgx8xb+Q3MrNO2dgYCe2UOr593gBaT34dvOCzdRaHkGZaVInfxPdyQOzU9YomNoD1qTf mWjdr4EZRc7rCHHtsiyLkZERarXaJSXZstksk5OTrF279rI+L0mwidc4kjlQPAGH/yuU+haO RSLdVNo+TK3hHXLwElcNpRk4sXUEC/vRvNrMu3Me6hP+ANuISpCEEEIIIa4Ttm0zPj7Onj17 mJ6eZufOnTQ3N6NpGkopDMO4qDpstppNKTXXctIwjIuSW4ZhXPLVtfPl8znGR8fwNJ0nn3zy NW+raRqNjY3s3LmTaDQqCTYhhLgUngXFU3Do/16YXAPs+AaqrR/Cjq2XOC2Vl8tMUGt8J2rD X5I68X9hWBN+McCs0lk4+ddQHYKb/gDMOHKeUohrU7Va5fDhwwwODl7SOLtUKtHX18f27dsv 6/OSBJt4Zcr1D077ftmvXFPnr7z0Ag3UMu+g0v6olMuLq4tm4MRWgxaYv7FDfQoqg5BYKzES QgghhLgOWJbF0NAQ+/btI5vNsn37dlavXk0oFMK2bcLhMJqm4bruXCJNKYXrumiahmmahEIh AoEAjuMs+JCvlMK2bWKx2FxC7lKlUmmaHQMPnXvuued1bx8KhUgmk5JcE0KIS1UZgEP/D9Qm 5s27Bl6giVrDu6g1PQCaLnFaMjSUEaOeuo38uj8mcfr3CFR6z5+nVJ5fwdb/FSj3w+bfhdQG 0EMSOiGuMZFIhI0bN7Jq1apLrmCb7UpxOUl2RLzKgGMQjv4hTO0Ht3b+w6Ie8ZNrHR+Vcnlx FY7LDJzoGpQeWLjcmobyOUmwCSGEEEJcB+r1Ov39/ezZswfbtrnzzjtZtWrVXKtHTdOIRv3O BvNb0HieR6VSIRgMEg6HiUQiBINBKpUKnudfTT+bXKtWq7S3t8/N83apYvE4CdvA0wzWr7+0 CgqZg00IIS5RZRAG/gXGn16QXEMLUGu6n1rzj+GZKYnTkqOhjCj11O2w8reIDf0Dwfx+NLfs r1YuWFMw9jTs/1VY/QvQ8RCEmiV0QlxDQqEQy5Ytu+QuEZOTkxw5cuSyPy9JsIlXGHAMwbmv wrmvg1uZ/9GNeuZOqm0fwomuQ0quxdVGaSZOZBVKC89svzNvyFbWH2gLIYQQQohrmuM4DA4O snv3bjRN484772TZsmVzc60ppdB1nYaGhrkP5t3d3ei6Tq1WY2xsjEwmQzKZJBaLkUwmmZiY oFqtzs3PNj09jWVZNDY2vuEEmwZouoaG33pSCCHEW3UAKPlzdp39J7ALC1bVU7dRa3w3TnSV xGnJmqlkS9+J0kNEgl8hPP00ujXhr1ae/xpPvuBPAVLshZ4P+9VsmhxPryilwKtBfZL2eJWI aaOhJC7iLfFGukPMtnu/3CTBJhaqT8HYk3D2c1AbXbDKSmyi2vIIVnLbxRVAQlwlAzIvkMYL NqOsETTPOr/dVwYkPEIIIYQQ1zClFIVCgQMHDtDb28vOnTsxTZOJiYm5yrVYLEYikaC5uZmW lhZOnTpFc3MzyWSSkZER+vr6WLNmDel0mmAwyIoVK9i7dy8nT55k5cqV1Go1jh07RjqdpqOj Q5JkQgixVOSOQP+XIX90wWI33EWt+b1Yya0oaSu49I/lRoR6ejvKiOIFmglP7cKsnJp3Axem D0B90j+v2fV+aLwNQk0SvPmsnB8jKwt2zv+/U/K7mHmW/+XWAA2MCJixV/mKQ7jV/+5W/fkN p/ZB6QzYOX5+22kaW2yapoKQfpef8AxmJP5LZX9C4XlqwbSG4o2TBJuYN6qo+Ffz9H0esi9d POBoeT9W+k6UmZBYiauYhhtZjlk5tTDBVpYEmxBCCCHEtczzPKanp+nv72dycpI9e/Zw+PDh ufaK0WiUrVu3smXLFhKJBJs3b2bv3r0888wzRKNR8vk8LS0tbNiwgUgkgq7rrFy5ksnJSQ4d OkRfXx/1eh3btrn55ptpbm6+IlfNCiGEeB2VIRj5Lox+Hzh/JlnpYWpND1LP7MQLSgLmqqEZ WMmb8QIZ3GALkYl/I1A6jObVz9+mPAB9X4LSWeh8GFruhtQNoAevwwGQNZNwnID6BNTG/S5O 1RH///VJv8WmlfeTZG4NvDo4FdA0MGIQSEIgAWbi/M+BJARSEO2ESBc4ZZh6AW/qAK6n8PQY XckizcHTRIa/hHJfRuv6ALQ/IEm2pUKBU1M4tudXHkrL8UWRBJuY2aHc81fzjO5auMqIU2t+ L7XG+3BD7RIrcdVzoisJ5iLg5GcWlPwrm5wKmFEJkBBCCCHENUjTNNLpNPfffz933XXXResN w6C5uZlAIEAgEGD58uVEo1FGR0ep1+usWbOGjo4Ompqa5irT0uk0t99+O11dXRQKBXRdp7m5 mY6ODsLhsARdCCHebm4dxp6Aoe/4VTrz2MmbqLZ+ECeyTOJ0FXIiK/DaP4IbWUZ0+HMECwfQ nQJz04E4Rf8cZ/4Y5F6CZY9CejOEm7l2p71R/rktO+9v73YeamNQOAmF41A86cfDzi+ch/A1 7g4v79/+tYTb/N2tOkk92EW95b24sbV8au8/sG3Dch5sDrBs8iUCVsGvJmy7VzbgJfMW6eHa 0sLzzZAEm/BVBv22kIPfAOXM+xRqYqVvp9L+KE50hcRJXBuDsPAylB5ZuNAuQvkspG6UAAkh hBBCXIN0XaexsZFM5tWvmtY0ba7qLBQK0dnZSVtbG57nYRgGhmHMVbyBn5SbnZPNdV00TZu7 nRBCiCWgeBKGvwPTP5p/RMAzkxS7fxk7uho0OT16tfLMFLXGe3GiK0n0/wXB7G4Me2rhuc3q EJz9LEzshrW/Au3vnmlrGLv652dT3vlqM7fiX0BePA25w5B7EbKH/XNdbu3yPo/aKJ6Cmq1R KE+i3D3Q4GFZNkPVFiaaP0RL4Gn06ccwRh6H1nfI3HhLYfNR/pd4c+QIIvw32d5PwbmvLZzo VTNwQh3kV/4WTmQl1+7VHeJ640RXoIwLEmxO0W8dIAk2IYQQQohr1mwC7FLpuv66bR41TcM0 TUxTPl4LIcSS4tbh7GdmOjXNaw1pRKi0/Th2ahvKiEmcrvqDu4kTXUNu3R8TG/oMseFPY9RG ZpJsM9kDz/YruH70f0LDNlj3q9D6Tgg1gx7AP+epwHNmKrsUYdMloDtoyvYTWdpSaPus/Ofn uf7fZ+f9irTJF2DqeX/+s/rUpVWn+cEDTUfNfH/lh1RofinbTDbmlTMyjguWrVB2Cab2w9R+ PvEgjDsF4vU2rEgbQbMFo3DcP/8sbSLFNUI+AQh/sDH0Tb9F3jyemSK3/k9wI8vlah5xbY2x IytQ+gWtIO0ilM9IcIQQQgghhBBCiGvB4Ndg7Ek/4TBD6QGc6ApKPf8HnpGUGF0Jyk/JXO7p nZQeotz5s1ipm4kPfJJQbjeaU7zgRq5fzbjnF6DxVlj5s9DxkN/isD4FE8/C9H4oD/BbO35E MDlOSykDpSAk1r79sbQL/vMffxYmn4f8EbCy/t+lHD/xxqWXJHlmCjfchRPuwQ13gH5Be2uv jm5PY1jj6NYEhjWBbk+9cvwVuN7Fy5vNEej9BCrWghd0oGUD1EYkwSauGZI1ud6N/QDOfAYK p/yrMWa4oXZKPb+MndiK0kMSJ3FN8Yw4XrAZpYfRvJkyeXumgk0IIYQQQgghhBBXt+ognPlf kD/K/ISDF2yn1PPv8QLpJVKRdG1THtg1D7umCMV1zODlzbIpPYgd30R+ze8Snn6C6MiXCRQO XHAjF9yqX+1V7IX+L0J8NdQnYHIPSrl4gUa6E3kaojkyA6eh8gSs+jj0fPjKBtCt+O0eJ/f6 ib/8y1CfBKfsr3Prl1StpowITnQtTmQFTmQ5brgHJ7oSL5BBaQHQgyjNvHifUB7aTPLu/HcL 3ZpGt6cwq70E8wcJlA6BPfmKj63ht7FU1RF/V8wdgWN/Aqt/ERpvk51EXPUkwXbdHuFcKPfD 0T/236i9+vn37mArteb3UG1+38Vt9IS4Fmg6brgDZcbRrNkEW8HvUy2EEEIIIYQQQoir24m/ gOxLC+ae8oLN1BrfST1zt8z/dIV4niI/4pIbcGjbGCTRZFz2GWiUHsINdVBtegg7spLw1C4i E9/BqJ1beEO3CtUq2DmYfhHXU9S8KLWG+1BNd/JHn/00a1Z08vAtMdZVTxHo+zyEGqH1XZfv ydsFP+mXO+RXpxVO+tVe9Wm/Us0uLpxf7pVoGl6gCSeyEju2Fie2Fie8HC/YgDJi/pcexTNj oAUWE2G0iIXmWVjurdQaHyB+7pPgPI8dWUXdBrN6GqM+tuC3dBw0hV8pOPgtv7Vlwzbo+gA0 3QZmXHYYcVWSBNv1SLlQG4OXfx8mn/Ovepg98JkprPSdVNo/ihdslliJa5YT6sIzkujMXGHj 1fz9wi5AQNpECCGEEEIIIYQQVx3Pgsk9MPRvYE3PLVZ6EDu2gUrrh/HMlMTpir0eUC95FAdd mtaoK/vQgUbs5C14oTac2HqCuecIZ59Br4+zoI2iU8GzK1iOQdlxcNwjUM6yoWGMaCCDFVxP LayjFw9hnPs6tLzzzfe7VK5/PrYyCNVhqAxB5ZxfDFEdguqIP5VPfcqfP+71aAZOdDV2bP1M Qq0HL9iCG2zGCzbhmem3MKmsofSQ3/HMTOCG2rDjmwgVjmGaGaot70FzihiVswy+9FV64lmi QQ/TgICBnyCsT4A1BcVTfkVb83bofBjSm8GMyn4jriqSYLse1Sfh9D/CwFfBKc0dVJQexkpt 8yd6ja2XOIlrmhvpxjMT8wY3nr8/VAYgdSOX/ZIqIYQQQgghhBBCvHWU55/zOvnXfqJiXmLC iayg1vQAdnyjxOmKvy4zs9Kot+Gh9SBOZCVusA07dgN2YjPB/I8IFn6Ebo2izWwjrgd128Wp 56B2ALIHeM9qE8uokiwWsVxFwB7B0J+Fc1+DSLufCDJjYETAiEIgBprpV026Vf/Lqcz8XAOn CFbOT/zWs36CqTYGtQmojZ+vVJvXZexVaQaemcGJ9OBGlvtzqEVXzrSAXOYnkbUrddpfw0ps IRDbT7x0Css9QyWyARXKsHfwB9AT4oZYgUiwgqF7F++v409B4RgUTkD7u6HlHZBYJVWm4qoh CbbrTX0Chr4NvZ8COz9vhY4d30C15f1Y6e0SJ3HNc8PdKPOCSjW36pffJzdc/tl3hRBCCCGE EEII8daxCzC6C4b/zU9szFBmAit1O7XGd4EekDhdh5QRxU5swo5vwErdTij7DMHCAQLFI+jW KMqxcC+YyiwTcYAxyI/hlsANAXoFjn0CYt1+S8NA0k+yzf6smTOJtfLMV2nme8U/D1ufhPq4 X5k2r6PY69PwAmm8YDNusBUv2IIT7vGr1WJrcSIrUXrwbYuvE99AvflBIs4/01R8jGr1JVw9 RU+qTCwSIBzPoMVX4GgGen0Ew7qgirA25icuC8dnEm0PQOZmCEt3tUVv80pObV4pkmC7rgYa RRh/xr+Sp7Kw77AT7qLa8n7qDff6Jb5CXOPcUMdMgk07f1B3a1A8wdtyWZUQQgghhBBCCCEW x7P8dnO9n5pJXMx+rtew4zdSb7gHN9wjcbreaQZ2/Ebs+AYC5ROEJx4jMvEtlH0GpRtA7ZV/ b3Zzsgswtcf/uqzP08QzoigzjWem8AIZvzotvh47dgNOdCVeoIGl0n3JM1PUGu/HDbYSmvo+ kfIJNC/HhtYKkWgKN30rlba7UHqEQPEgodwejOpZdCe/8I7yR6F01o/v8p+ClrshsRr0INJp 6tIoBXbNxbU9AhEDM6BLUC4zSbBdTwON6f1w9p8ge/CCN8Ek1bYPUWu6Hy+QlliJ62OXCDTg BTIoPYTmzQygZivYhBBCCCGEEEIIcZVQUB2F4cdgYvcFn/0z1Brvp57ZKWES82j+fGXhHjSv iln9Mp7ZglstoTllNK+C5taYzazpmv91+Z6OgdLDKCOC0iN4gQac6Eqs+GbsxCacxCY8Iwos 3WSJZ6aoZ+6int6B5lUxrFF++69+g9U33MqHN32ElW0rAKg13UeteITY8OcI5p5Ht6fQPIvz F79X/f04dwTa7oV1vwapDRDMSNvIS3kdXMX0UJXcSJ2O9XESTSGpZLvMJMF2vQw0ir3Q/yUY /MZFb+C15vdQa/4xuZJHXHfcUAdeoAGjPjyzoOYn2JQnB20hhBBCCCGEEOJq4NmQPQC9f3fB Cp1a4wPU0ztRRlziJC6ijCheIAPBDF5sO9nUIwSnnyOU240zeQATi4ChMAwPw/BY0AVpUbSZ vn06StMBHTQDN9CIE9+IldyKlb4NJ7YOz0gs7d3OVVhlhQJCMQ3dmMniaDrKiOFEVnF6Kkar FcJTfmJQKfBUGDd+K9aaTYRzzxA/9zcEyifQ3NLMZH0z7Dyc+zqMPA6b/xv0fBgibVf1+Tql /H+0C7K1ylMzodMuKe523cOuuQTCOsGIuSCBpjxFccpm/GSVxp4ICdnNLztJsF0PahNw5h+h /4sXraonb6Hc8bPY0bUSJ3HdcUNtFyfYymf9q2V0Eyk/F0IIIYQQQgghlrjcYX/+ptrIgsVO pIta84PY8RskRuJVWcmbCeYPkC4+iRXsYLrtA9RaH+YX/+63uHVtio/eZrMl9TIBbwxPC6C7 xUU/ljKTuOFOnHA3bmQ5dnQNVmILXrgTpQX9SjbNAG3pt/Wzq4qx4xZKQfuNQULx1z6HphRU cy6FURc0CCdNEk3vpL55J9GxrxAb/DRm5dSFv+XPX/fSb8Lkblj/H6Fh28w5u6uLa3uUsn68 4g3BudaNnqMoTNXxXEWqOYTxGi0d7brH9FCVqXNVKlmHjhtitK6KY5jaK8ZbyQw4V4Qk2K51 btW/gmfga2CXzi/XDNxwF8UVv4ETW31VvHEL8ZbvHqH2mZ7V88z2bU9vmunxLIQQQgghhBBC iCXJLsLEszD8nYvOJlfafwo7vkk61IjX3oQSm6m0fpCY/T9pn/hbmnNfxTJb+P37j9KV8eiM OASCrZRafoVqy8NonoXm5NGdIppbRHcKcz9rykHpYTwjjjIT/ncjjmfGUWYSpYdBC6D0gJ9Q 04N+W0jtKrvIW4FrKwpDLm5N0bwmQOj1fsWD4rhL77drKBc6dgSIpEIYwQDVlvdjJbYSmvgB 4YknCVROo2m5eQ9Wg+HHoTwAqz4OXR+AcMtVtZ1ZdY+hY2WUp1ixLYUZ0FEKrJrL4MslnLrH ursCRF4jwWZVXfoPFhh8voxSkGgJ0rTMQzcMaQP5NpIE27VMudD79zDwVagOMlfCrOm4wWYK K34TO7HRf3MX4jrkBtv8VgDzeQ7kX4bkOkmwCSGEEEIIIYQQS9nkc/7ca1Z2weJ65m7qmbtw g00SI/GalB7BymxHmQlCuecwqmcI2gWiQUXJa6CYuZlw5z1YqVtxQx2AQvNsUDaackA5M/93 gJkpRzTTT5ppJkoLzPv/tVXg4FoKq6BwHYVrz8xXZ2qvkuxROHVF6biHM61o2GjOdYT0zBRO eD25QAuEt9Mc+h7JwtfRvfHzv+4UIfsSHP8zKJyA5T8JDbdePduZq6jmHTzHj5dd96iVHabO VRk7WiEY17EqLsGw8YoVaZ6jqJUdSqM20y9YmA06U2dqxBsCZDrChGPm+Tad4oqSBNu1bOCf of8LfjWOZ88s1HCDrZQ7P06t4R0oI4a0wRPXK2+ugm1eD23lQP4odL5PAiSEEEIIIYQQQixV 1WEY/QFM75s3d5OGMqJU2h7FjawATU59itfnmWk/gRbpQbem0Nwyn/2nP6WzazkP3PgwPQ03 45nJ89uYHgSCXPcd+BR4rn+tem7IwakrGpcHMEPzzzVfMN+Yo/AK4FQUnqP803Ea2JbJ8KkU ldH1aLcl0ZMxohNfw6z2zXuh6lA46Xdpq47487J1PnzVtIycLbKtlx2mB6uM91YZ3FMmd9ii YWuIvgN5OjcmyLSFFyTZNKVTnvYoHC0webSOPaKwR1x6v1Zg6lSN5Xcl6N6cINUcnvdY6nyf SClvu6zkKHNNHhVsmHgOev+n34farZ5fFWym1vQg1dYPokyZ5lBc7wOoOF6wCWXG0JzS7JHe T7B5lgRICCGEEEIIIYRYkpSfXBt7EurT55fqQWqN92Klb8eT817ijWxReggn3APhHgD2DH2W GxPtbNe75yXXxEVx8/xKtukzDtWsR7LNnEuwGZgEnAhORcO15uXBXYVrqfP/n7mfetGjPKFT D62i0vgoKtxMePJ7BPN70Nyqv9+joDqNGtoN1ayfbOv+EFogytVQRKI8Ra3kMnCgRN9jJUr7 HdSEYnyyRm3aJZw0STUFMUy/tW2AIKYVpTDkMrqrwPQPLLwzfqauNOFQPeHiWopUW4hkQ8jP qXkKp6awLc/Pr8lmellJgu2aeSerEVAFGqMWLcFxtBN/AVN7wSnP3cwzU9TTd1Bp+whuqE3i JgQaXqAJL9CMMZtg8yTBJoQQQgghhBBCLGmlM/68a/mj8z7iG7jBNsodH5uZDkJOKwtxuXmW 3/rRrinqOQ+nruaKpuJeklR+GVMvBklpNpUpD6/u/55yubgCUPnXvbuOjhvupNL2EZzISiKh NkLZH6LXx9CUjed1UcnfjD2dQRvbR6gI4dX3o0VblvSci8pTVLIOuZEahSGLyhFnLllm7fOo NDnUSi7evMBkvCbiI92MPmdTOKRwT55fqYrgnlMUT9tkh2qkWoIEwgZ21aMy4ZAfqZNuDRNJ mui6vB9eLpJgu5o5ZagOQWUQqqN01PfzyIZxtraX0AaPgXb+MgClh7GTN1Ft/SB2YpPETogZ brAJN9iCUT17/ghf7ge74P8skyELIYQQQgghhBBLh2fD4Ddg+gC4lfOLjQT1hnuwUrddc3Nd CbFUKddvE4ma/fl828egChMppck/bXKqv4pdAKfPTxDZZb9FpJopSpvNtrl1ZpJ0CmWEqGd2 4sRW44baCU0+h1GZwqqtob/vXUyMtKObLt0jp+jWv4a5/N0Q6wE9uDTfuhzFyHNVxl+sUT7r 4E4uTDF6dbArLmpehi3iRQlPpJl+ycPru7gpqSpC5YTLmSeK2FWPnpuS1MouhVM2p9wCwahB z+Ykwf+fvfsOkuPODjz/zczyVV3tHRoehCMIEPSeHI53HCNpNDJAnTLlAAAgAElEQVQT2tGe QneniztF7O3umdDGKS5CsbEXK+3Gxp1Wu9qQTjdyMzKznOFwDGfIoTdDkPAe3QAajfblq7LS /H6/+yMbjW7YRgMNdnPeJwJBRlV1VubLzErz8r1fSu5vLhVJsK3YkwkPpt7CnPlbzMRrGK/A Vh3yex8t4thmfmtVK0aY3Yrb8ws0Oz4msRNi7q6U6EYley45OoVQH4LsOojlJEhCCCGEEEII IcRyUT8Nw/81qmK7cBlvxQgzG6kP/Dcy3pAQS0xrQ+gbdDBTcebPGU9tHgtL26hpi+IBhamD KYDVB6oZVb41imq24s0YQM9vHQmgEn2UV/0uynsQu3gMVYgxNryaicFOYqmQ9s4p9L5vgB6F dV+Fls3gpJZVzIwBFRpqR0OCQQ1ulBybF9eGwa/rS5bfAmWji+ayz8/GZ8gw9ZJHqt2he2Oa oKHxpzWFokf5IR99Z7RitDJoZbAd+Y28lSTBtlKVD8P7/xJTO43X8STeqsdols7SPPzHdGQU mQQ4TlQMrxK91Pt/BbfnGXmCR4hLTwoS3ehE7+VvVI5Dx4OSYBNCCCGEEEIIIZYLo+Hkf4Lq iejO/oVr+2Q/zc5PEGbvkBgJscS7YKOkmTgSUDmlCIqGwsmQ+qjCsq0oSXbZH4Eevnw6vmso DvuEDUPX5vjs60Zfkqwz4Lk2Z8/eR+G9LTBRp3Y8RVCKkeqy0dqGEDj0B9A4C5t/BzruB3t5 pD6MiZKSfk2hGwYzcfXPah1V793Q9KsQnNFUzwac21ejcNIjGNfEOmyMMlGBoDbUij6lUY/O NWkSaalou1UkwbZSnfxTjDdNdf0/x+35IiaWRekXAEPdg4YPHVmIx2zqA1+n2f05jJ2UuAlx CZXoRiV6Ln+jenxeqwkhhBBCCCGEEEJ8gEwYPQw7/I/QnHOH2ooR5LbT6P+qxEiIpd4NDTQK itG3AyqvalCGkaKPdqH1QSeqZFsA7UeVb/VxjTuuaV0dpSlUEwLXRG0nMVgz1VYqMNTOaya+ G8eU2qABaLDiBhXGMcwkjM78LbijsPV/goFnlk/ctCFwTZQIXIrpT0D1SMjgVJXmaY0aMjit BhUaVKBRyqY87jH4VplUS4x4an4RzkxXT4wBowxYYNmWFAQvgCTYVuQvmYLJ1/CyOwladqHj rdEuMDNWlDHRP9cHx9aYWA5jZyRuQlxpd7JT6EQnOt6OHRQvvlE5Fo1zKIQQQgghhBBCiA9e WIfD/waak8wtbwmy22h2fQod75IYCbGEjIagqfHrhqBo0BMGUwB1wmB1gNoZtY40UX7m6tOp QFA26DC6ze2XDW5JR+OyeVEiqjIeEnqGfG+MZC5KBhkDxgUz5/ZdWLPxvSRaZ/H8p7HtBrHJ /Vj6j1CNKuHqrxKLWzix29/VTWtD4GnsC5V9N1iZdqO8wwoPZivkVNkwdbzJ2Z4qq+/MEXia +kSI76rZNpTKN/iuQocGK27huyFTwy7xhE37qjTxpHTDux5JsK24XzIF7nkIKoQtA+h4G1f7 yWrkHyatj2KFFSzdwDhpiZ8Ql7HQsTZUsv+SBNtxSbAJIYQQQgghhBDLQViHqbdh9Ifzus0Y O42f343X8fTsg+dCiKXhu5qJYwFTRwOCgsE0578fJZEWNi3dNFErSKAxqBlWHv60ma1sK54J qZxVOI9bJDJXT9eZuI2K23h+LxNjO8nmCvT1/j3W1Ailyf1M7e2i6+FHaV+Vve1jj3l1xfCh Crn2OKl8fGF/dBM5uEtbT6ohw+j3XbyioqUrjlHRWHkq0LNtKOvnQ87trdHam6S9L0Wzrjiz p0q2I0ZLV5JYIkqwSSXb1UkKckWeVDTAaIydxMw5eRivxnh9MIOx4vhtD+K1PYqO5aOaWx1I 3IS42kE93o5KDlxyFJyM/ilPAiSEEEIIIYQQQnxgDDTH4dSfRtfpF0ovgKDlLrz2J1CJbgnT sl+LRoKwwoWeoXAqpHRIERZvbn0aNfNPG/zzhuJ3FbWXNcYHrSBoGOqjmsC9zpYTs/B6unBT 3YyeX8/05DpC1YvyuqgOt3HuJU1l78uYqOfkbRV4irHDDUpjXtR28Tp0wxA09S0rdDNV8Pdr aoMh9WIQVRcq0MrMJkO9Kc3koSaNcoAxUdKzWVF4NUXgKdxKQL3kE/p6qQvwViypYFtxLEh2 gOVgqxqW9mffGS4l+Na+LmK5NHdt+xpZu4qFjXGy4KQkdEJc7QAWb0elVl/yYgD1sxBWwZHx C4UQQgghhBBCiA+EX4bpt2Dsx/OSazreitf2GEH+AaSGYBkzoJrRjX2x8mnf0DyvUZMmGgdt MRqgqobKiMKd0JiaQQ8DGVA1Q2Ms2s+Va6Jd/lqJHQvCfD+1vgfxnCSun6Hprsdt9lAtdOMX HfTQcTjzLdjwZbidHd5MVI2ngoWll3UN/Kqerey7JbNQhaBomBpsEk/ZeCWFV1foCwk/Y9D+ /DgbZaiOBUwMNmiUQtxySN/WDN3rM6Rb4lLNdglJsK00lg2JTsgMEG8M4njjhOkNYDlUmjZ7 RvK0DW3kji8+RNf0n2DZDjrZGyXZhBBXPtjE2lGpgcvfqA2CX4Kk9HEXQgghhBBCCCFuPw21 U9HNcb80752g5R78tkdQyV4J0zJmgNC9mGSQe/MrfH0aCMdAjVzhPR90eGGtX3tN+8cMI88H qJK5OK0GBIOG8RcCLBuSq+wFzpONm7sXLzuKH3OpNNdw6uB91EpZdOigSgZ96K+xE0ms/o9D vPX2xUsbQk+jgwVUgPmgw1tfJuaf1Ax+p4qTsVA1Q7M6J8E2Z0fVGlRoCF3N+FtNGtMhyjOU 9geM3+ty36/ZpLbEsCTDNo8k2FYiy4b+TxEf/AuShZcwTgaV7CVNiY6sxrZCcvWfka+9is5t QqXWYqy4xE2Iq52ux/KoRG/Ur33uI1W1QQjKEiAhhBBCCCGEEOKD4Jdg+h0YfeGS6/g2mp0f J8jtkBgtd2Ze4aFYobQyhN5MtZPPZdVrpglhI/rMQloJ6mFwh/UVX/eGDVYHJHqvPyETRkm9 0DP48TbcdEjV7qMw3k75TJZELqQw0U/uxD20Bs+Ruj+OM/DUkibZjAEVaryGIvQMXlXhNVQU u/Daf6t8Q+DpyxNgN7Puzhlq5RDSkLzLQflmdgw2iOLn1RWl8SbTZ11qoyGNAwrwcdIW7hFF OeMTeBrp9Ho5SbCtVOt/DavwLtnp54g3jhLkdrHBFPmlXdPsWt9g3cReYo5FrftzUYWbEOLq Bz47iY63o2Ot2EHh4hsXKtiEEEIIIYQQQghxW9mAXT4AI/tBzb2bb+G3PUKQvxcdb5dACbHE jIZGSTNxNKA6pNGlK2dZTBBVQd2S72wu/LPKixJ7yoOp6U4C9x4q03Gaw3H8dIyTegNTo530 nx9lvf86HU85WL0fgdjSdHzTSlMYcTn7fpXK6YBYwuL84TrlUwHmGm01TdlQOxMwdqJOMuPc 0syNqQJVQEdVdXMTZe6w4vRbFZItDtMnPIpv++iSQTcBDPjRNqCVkQTbFUiCbaXKbYLd/xZO /yXJc98mOfJn3GMF3PmRAGJJrJaHKK/+p/itD2KcnMRLiOsdaGKthJk7SJTfufhi9ST4RZAm BkIIIYQQQgghxG2VTShyzUMwPjb/+t1O0uj9RYLMFgmSEEvMaAiamspYyPnXfKpvaMzY7flu 5c60TLxWUicEHRi0isb5q7yqqaZbUCMGUwZdtqhMp6kNJXHLKTq7Rmjv+WMsOwZ9HwPr1qdH VGgojDQ59aMqteMhyQ6b4qBP6S0ffe7qC2OqUN0fMrq/Tu+mDKm2W38vMixofFfPqyp19ynO lOqk1jl4Yxp/f/RmWNJYcQvjG7QPgatRymDH5B7pXJJgW8laNmHt+N9h2++CN8k7r/6IP/h3 /5m+dbv5/X/1r7BjqajlnRDiurSTQ6XXw9wEW1gHbwLCGsRaJEhCCCGEEEIIIcRt8tC6Ovcl i6C8ea83uz9LmNuKcVIrfhlVaAiaBidmEUtayNBGYlkx0KxpJo76TB4MqB3SqKO3qYSpAcG4 oVHQeA0dVV1dbTYvtCE1oCcMpnDJ+wGoSZtmOUEQJGH8GCT+GOwY9H5sSeKmfEPjTEg4pjEh BGWNLizgN6Fs8Bt6ydqq6gKEnp7XItKUDf5+g6oadG2m2g3wT2ishAUuqLqhMu7TKPvkOpI4 kmSbJQm2lcyywUmCk4BYnlJsC4fG0iR70xg7Lck1IW7k2BdrIUivI33pEbE+DM0pyEmCTQgh hBBCCCGEWHJ+gW5O0b/6LNuS9TlvWFH1Wv9XUclVfBg6zXhVzfiRgGy3Tef6OE5cblqL5cMY 8Bua0XcDpn8SEhy/vf0Bw2HD6BsBybxNS8817nMvcLaMtjDGAmPB2IvgpMBOQvfjSxA8onaM 4TIcg/AK8TJVCPfPf8NMgJn5sH9cc+r5Ck7cYstj7WTb4li2/F6BJNg+JCywY2gSeKGNkVZ2 QtywqIJt4+VvNM6CNwk5GctQCCGEEEIIIYRYmotyD849hzn3bSx3lDsrozi5c2RsNfsRYydp 9nyBMLMZYyc/FIsd+obycIgdj6E1fNgelTcmavG37BIM4trrbWacLq2jSqygaghOX14ZtuQ/ C8NQO6io36NIt9qY8OqZNK245vsXlkupOFq3YIcnYezHUYItloP23TcRL4OeM67ZvOqwEJSn UZ7B+GaZreeF75v6nKH4UsDI6jptA0l6NmTI5OPYjuQhJMEmhBCAcTKoZD/GTmHpOSOpNoaj BJsQQgghhBBCCCFuPW8azn4Lhv4/wiAgtPM4qgxBFc+GmA0xx8I4Oeqrfh0da+fDMk66MWAU 0Y158+FbtUZD4JqLyyhWwEqLqtaqEyr676jCG9fgfzCzoypQH1U4CYvG6JXnw2gImwbVBNO8 +rS0ZROESbSe6VLlFWDshSjBtv1fLOrhemPArYYUzjejbdyCXEf84ubugzetCcpmWa1jrQxu WRFWzGxLyOv+2aRh8g2PI/Ei5lOw9q4WbEc66EmCTQghACwHHWtFpVYTa5y6eOZXOw3NCYmP EEIIIYQQQghxq4V1KL6HOfmnBCZJo+9XCKtn0dNnwAPbgkQMUnGIxcFYCYnZCmIw6BBJrq2k dWbArWiG3/IoH1V4E4bmQX3bq9dmKWiMGRpjAdV3rzIf5kIF27UnpVM2YSKOthIY04ZllcAd h5HvQKINtv0zSHREwzLdQMBqBZ9Tr5dRgcFow+aPtM1WhxnfEDZnqtfc5bGOVWjwXU1l1CcY X3h5qamC+4JiOu/hPhygZb8GwJYQCCHEzIHCSRFmtzLvSbjmeJRg074ESAghhBBCCCGEuJX8 Aky9BdWT1AZ+E7fjY/i1CUK3QKjAD6HhOzRUCowiWXobS3sStxVE7sGvrJUVegavqqmf05R/ pGj8RKOHPsBZUhBUDI0hTTh4c1uTduLUMz3UrM00vSdR6i4gCe4oDP4FnP4rCEo3NGiaIUpY NaZDaucDisd9apM+Xk1FlZvLbRWXDaUhn5FDNUqnffRiEqc6SsSKiFSwCSHEhYOMnSLIbCZl ff/iGaD2owSbNw3pfgmSEEIIIYQQQghxqwQVqJ5Ex/J4nZ/ATL4JhffBL81+JHRaqSfXk7Un iNUPg5EHYIVYCkoZSqMh59/zqZ/U6Gmg8cHOk2kY/FFNcI6brqJTUzA6uhbCz5NtTrJp4GXy LeNYTEYP2B/615Dqgf5PQeLGWtEq39AYD/EmNEOvVQnqmnDsxgcfNGGUVJw7ptstjWcVpl72 CBuaxlmFKUum7GZJgk0IIS4cZOw0YXbz5QdQdxTc85JgE0IIIYQQQgghbiXVxAQldKI7esD1 zDehOXbxfcshTG8g6H6GoP4P2N4Ey7IsRIiVviuGhmZFUzwdMvFyiLtHf+DJNQA9Dl7ZXHNs tQUv41lD8SWodq8l29ZBb+8xWkhHdwGNih6w3/d74GSg92mI5xc8baMN2gf/vObc3zQwIehR A+kbnEkfgrpGBRpYmvHNgkFNrTUklOTaLSEtIoUQ4gInRZjZjLn0p7E5Cu6IxEcIIYQQ4kPI GIO5Tp8bs4A+OEZ65QghxI2zLMACHUDlMBTeiaraZuhYG0HLXYT5nVjGcCMVJUKIhZ4MgVvW jOz1mXgvwD9jMGOLPrG6tfPWmKlca9yaaYX7Dc03wddZmh2rMLYzPxC1QTjwf8DUmzc8XIzR BqMgPGxQxw2mOvN6YNDBAqfhG0LPoMKlO680E9A8oQkG9ew8isWTBJsQQlw4wFhxVKIHc+mA po1RaJyXAAkhhBBCfMiEYUilUqHRaFyWINNa02w2KZVKFAoFKpUKvu9f9rkwDKnVahSLRcrl Ms1mE621BFcIIRbCyWAlu3Dqp+D4n4Bfmfd2kNuO1/ExLB0QDydR6dVgSUMuIW41v66ZOhBQ /IkiPLmI5E4DVNWgPFbEwHvaONRa76PR+4mZRP8cpYNw5A9h8rXrTsfoKBmmPIM/pdG1Sxbe BW8kahe54GSWXvoA6kGDmZDt/laQI9IlF1BDZ89x6MgJJgtFkokE61av4qH77yYej897RsYY Q6FYZu+BwwyeGQYDGzes5d5dd9LWmse6ZMf0/YB39x7gxOAZfM+nv6+HXTu2sWag77LPCiE+ QHacIHcnieKbWBfqz93z0DgnsRFCCCGE+BAJw5Dz589z8OBB1q1bx+bNm0kkErPXhsVikSNH jnD69GnCMCSdTrNlyxbuuOMOcrkclmXheR5nz57lyJEjVCoV4vE4AwMDbNu2jY6ODmxbnmkV QohrirdCfjuW8chUX6dh3Nl785P1GPXsAK2JFlorP8A2TYKWXRg7KXET4hYzBrQHasIsulpM 16KxyFbE8gbgW13Uu7+MQ5nM2DfnvKlg6nUY+gbEWqDzgStOQ4WG4miTqSEXd1zRPKYxk/OX 31QhOCQPXn2YSYJtRqVa4++e/QE/fPFVqrUauWwGPwip1mps27yJ//G3vsamjetIxOMopdmz 9wB/+XfPcuT4KdrbWsGyKDz7fe7avpnf+OqX2H3XdmzbRmvD+bFx/uTP/5o3f7aXttYWHMeh Wquzqq+HL33uE3zm408RcxxZCUIshwOsFSPI3kmivAf0TIJN1aM+zH4BEh0SJCGEEEKIlXy+ Zwye5zE2Nsabb77Jnj17+NKXvjSv6sx1Xfbu3cv777/Pxo0baW9vZ3x8nNdeew1jDDt27MBx HEZGRnjttdeIx+OsW7cO13U5ePAgzWaTBx98kHw+LwEXQohrSXZC5wNYiQ6yuoCTNAQKlIaS G8MvnGFz8W/Ju3sIWu/H63gaY6ckbkLcynOjWzUdfes7RC7d+SBoEyPIbKbR98vY/iSpwosX PxA24PzzEG+LxmLLb71sGqGvOL2nwtG/K1N7N0QPXnnhpQ3jh5sk2Gb88MVX+c4Pfkw+l+XT X/g0vT3d1BsNfvb+Af7r8z+mv7eb3/y1X2T1qj5ODp3huR++xKGjJ/nok49wz847sSx4/8AR Xvjp6zzX9hL5XI47Nq5jarrAD378Ct974WU+9dHHefCeXaTSKU4OnuHl19/h2e//mL6ebh64 Z6esBCGWAytGkN2OseZUrRoN3mRUxSYJNiGEEEKIFa3ZbHLixAn27t3LsWPHLmv7aIyhWq1y 9OhRBgYGeOKJJ2hpaWF6eprnn3+eU6dOsWHDBhKJBMeOHaPRaPCpT32K1atX4/s+yWSSQ4cO sXbtWrLZLI48TCmEEFdnFKgGaJeYbUgnIKmjDmmbe0J07Dgtfh3V8SCN3l9CJfuQcdiEWIp9 ceUkx25aA0xoUL7B2CmClrtoDHwdJ5gkXjsCJpw5aZyAke9AvAW2/A6k+uZNRmtoVhS1d0PU cRmL9+eVJNiI2n8cOzlIJp3m0x9/ii995uNksxn8IGD7lk38+OU3eO3tPTzz6Y+yelUfBw4d 470Dh7lj4zq+/qtfZqA/2rl27djGycEz/Oz9/ezasZU7Nq5jZHScH7z4Ku1teX7zV3+RjRvW Eo/FmJouUm80ePGVN3n5jXckwSbEcjmfsGIELTswdmL+G94U1IagbZcESQghhBBipZ7rzSTP Tp8+TT6f57HHHuPgwYNXbOVojCGZTJJIJIjFYrP/VUphjKFWqzE6Okpvby+9vb2kUikSiQTr 16/n/fff5/z586xbt04SbEIIcS3ueRj9UVQtAjh29G/c72PfZIxk2wZaBj6Ln7+HICf3zoS4 5edGGnxX45Y0qv7zkyQyHoSuiarunBxe28PYq3+b3Jl/T8w9G/WQBKidhuF/gGQHbPotiOUw BoKmol7w8apqNh8nfj5JQ3iiMth7797Br3z5czz24L1ksxkAEvE469YM0JpvodlsopTC831O nTlLvd7g3l13zibXAAb6e7n37jspV2oMnTlHveEyNjHJyaEzPHTv3WxcHyXXALo627lr+xYy 6TSHjp7AbTZlRQixHFgOKrUWHcuDNedmiDcJ9dMSHyGEEEKIlXyqZ1lkMhl2797N448/zh13 3EE2m73sM9lslk2bNjE+Ps6RI0cYGhri4MGDVCoV1q5dSzqdpl6v02g06OjoIB6Pz/vbRCJB qVTC9/1FXKAaDFGCbyH/hBBixVJNKB+Gkefm/wzGWjjm7uSvD2/n+2OPU1/1G5JcE2KJ6NBQ OBNy7g2f+nGNqfx8LLfRoBSYmQaZxsni9nyeRt8vo1KrwLpQl6ShehwG/9/ot0oHGBWNvXbs lSKT7zcxNXPL583IsG1XOU02N/xvqUkFG+DYNp/9+Efm/7hoTa3e4NjJQUqlMvffs5OWbJZy pcrUdJFkMsna1QOXTWv9mtUk4nEmpwqMjk0wMTlNEARs3bwRy55fwt7b3UVHRxuFQonJqSJr V/fLyhDig7/tgrFTqNQaYs1zWKoevexNSYJNCCGEEOJDIJvNkk6nAahWrzwoRiqVYvPmzYyM jPDCCy+Qz+cplUps3bqV9evXE4/HCYKAMAxJJpNYVnStZ1kWjuOQTqfxfZ8wvLFHmj3Po9l0 0ZbD+Pj4tc9aZ76rpaWFZDIpK1YIsfK4IzD5GlRPzHvZz+1kZHoXI40RWnypDRArgzFEVRwW WCuoi6lSUDkXMv2TEH+/gcatm7aNjWWs27gCbkAAaqaCbXYSVoL6wNexgwLpie/ieGOABh1C +Sgc+UNIr8K0PkSjHHDu9QbFlwLMxK38XQS/qAl9jTxHNV8YhlQqFYIgWFDirFAoXPVc/1aS BNulFzS+T7FYZnxyiqGzIzz3wxfJpNN86bOfoK+3m4nJaer1Bul0krbWlsv+vq01TyqVpFpv MDYxRbFcIRaL0d3ZgXVJj+hsJkNLLsv50QmmC5JgE2JZ/WhntpCo7ruYYPNLUD8XPWHnyIDK QgghhBAr1YXElNZXfjT4QhvJM2fOYFkW9913Hy0tLUxOTlIqlRgZGSGXy2GMmZ2WdcmdtCu1 nFyIqalJRs9Poi2b55577rqf7+jo4JFHHqG3t3fR3ymEEB8IHUDhPRj53vzfYDtJs/tzhBPt wIjESawIxoBX0zQrmlTeJpmzV06SzRiUD2r61ibXjIa86iDeTGEaS/xzomaqvm4gIaU9CFxz 2d8YJ0d9zX+HHVZJTX0fOyhe/IPSAdj7v8K9/xmj+gjrGjN5i6vXqhA2DDqU7Nql6vU6b7/9 NufPn19Qgq1arXL8+HF27969pPMlCbZLnD5zjj/7q7/nL//uO8RiDts2b+IPfu+f8cC9O8lm MoyMjhGqEMdxZtuAzJVIxHEchzAMcJtN/CDAsiySycRlY7DGYw7xWBytFQ3XpVqr39S8R20m DWGoqNUb0ut/EZqehzEG3w+o1RsSkEXwfB9tDL7vr+wYOmtJWGlmR2IzCt2cxJs+SpjZvDTb X7OJUho/CG769+Dnldv00Frh+77EcLEx9Dy01hLDmzyWaKNpep7E8AZFxw2DH4TU6w2J36Jj CL4fUG9IDBd14dZogJmJYb1BNSUP1tx4DN2Zfdlf1tclF7qWeJ5PveFSqzcIQkUYhhw8dJif vbuHBx64n+3b7ySZTFKr1Xj//fd45ZVXicUTWJaF0oZypUqlWputIqtUa1SqNZxYjIbbJBa/ /n4YBAENt0kikSSdy6Mth4HVq6/zVxaZTJpg5vrPWkmPyy+hhusSqhCltPwGLvZ80G0Sqmhf kBguNoYeSikCuba7qrg/QmLyTezyofnHkPgmivG7aJgKSmmCIPxQ359pNDSBp2i6mnpDEVO3 5rdca02oQtym94HGL3ANXlOhAk3D9ajVwxWTeNLaEIYhrtu8bgy1gtJZzeR+Rcd2m85NDvYK uS0braMQ49/8tIwyeM2AWt1g2dDlryI5kUedX7qVbjzwSopGWaN9DQvMS5nA4LkhtYqLF1rY 9tyRYnLUO75GW22aluaPiDszE9UeTL+DOfhHBPqfo317wd93Q9teqHFdDy9Ymumv2ONGPE5/ fz+ZTGZBny+VStftCHErWEaats9TKJU5eOQ4+w4eYXhkjNff3kOlWuP3/uff4ZNPP87E5DR/ 9B//nKlCkf/ld3+bB+/ZNe/v33z3ff71v/sT1qzq55e+8Gne23+Ib3zrWf6v3/+XfOypR3Hm PFV49MQg/+kv/pZDR47zq7/4DL//b/7Dzf0gBgGuW8exHVIpaRGyGGEY4vkBiXiceFzyz4va DsOQIAiIx1Z2DHf2VvnDZ4a4s/fiSdThiRb+w5vr+P7RjiXb/vwgwLGdKCkvFrf9+QFOzCGZ kBguNoa+HxCPxUgk4hKQRR2Po305EY9d8WEccY2LHGOoN1xisRiJeBzblpvFi4lhrd4gEY+T SMTlhvuibqZo6g2XRCJOIi4xXAylNa7rEo8v/xgGnkutOEky20I624pl2xijqZcL+G6Nlo5e 4skUYEUP4jXrVAsTZFs7icUT1MvTxBIpsvl2rJk7aWHgUaV++6sAACAASURBVJkeI5HKkMl3 YC/gDpsxhmatTLU4SSLXTiyZJjvTxvK6F/XWCutFtdTbn1L4QQAG0mlJkC/qukQpAj8AyyIt 9xYWeW0XbYe2bZGSFq5X9Es7p/nth86xtbM87/V/8d01fP94D1M1myAMsG37Q3ttZ2Nzd/Ao u0tPMZ06z9vZHzJpj6G5+cGXGm4T27aIx+Pz7kXe7uXr12t4tPIMPbU1HO58g9fSzxMQLIvY t5hWciZP3apSsUqXxT2KoU08HrtuDFtMnofcT7KpcjfDLcd4NfMdGladdtNF0qQoWlM0rCjZ 7hCjzXSQNhlK1jQ1q3rN+Ww3XbToVgwGz2pQsKfx8W5q+dMmQ7vpQhGQNBmeKH+RNeNbsczN bSsqFjLUe4Af578JwKPTn2Nr6T6SfmbJ1qWxDLWWIuX0NJ3VftKN3MLO+W3FdMcogy37cUyM qfgIJ2IHLq4Po7m7r8x/+/AYX7irPOecrY2m/yR/8fxncV+4l0Q5fcuXyU81Obb1Z2z8zTjf +49v8cya3yBztANzbnn8drV8OcY9v9PJlsc6SKZvXyZZa73g9pAAU1NTPPvss2zbto3HH398 yVqqSwbhEq35Fu7fvZOd27fgByFf++Uv8r/9n/+W//u//CXrVg/Q19tNKpkk8APcRvPyA1jd xfdDUqkkba15spkMSqnoiaVLVn6z6dF0m8TiMdau7ucrX/rMTc37mbPneOnVN+jt7uLxh+67 bMw3sYAYDo+w/9Axtm7awJbNGyQgi3Bq6CxHTwyyddMG7ti0bsUuRyauSGb/BoOLNfO4SE9b jM891E9u20eX5DtPnznHwSMn6Onu4MH77paNaZHb36EjJ1g90Me9d++QgCzCiVNnOHjkOJs2 rGXXjq0SkEU4dmKIg0eOc+fWO9i+dZME5EYuJPyAb/7j97hj4zru2raZlpasBOUG1Rsu3/zH 77Hljg3s2LaZbDYtQblB5UqVbz/3Ats2b2LHts2k03Jj9EZNTxf53gsvc+fWO7hr2xYSyeX5 sIExhnKpyKnjR+jpW0X/wBpisRhKKc6dPc3YyDCbtm6no6ML23FQSjE1McbgiWNs2rKNlnwb ZwZPEoYBG7dsI53OoLWmMDXJ4ImjrFm/kb7+AewFVPBppTg/MsyBfXtRdhorluBzn3paNqZF GB2b5NDRE2it+eRHH5eALMLI+XEOHj1BIhbj6ScfloAswvC5UQ4ePUEuk+GJR++XgFwiZ5d5 uu1F1rdWLv4OYjPtd9K6+fM8taqVM+fGOXZyiLbWPPft/rBe21nkav1kT6WwO9t5pO8ewlhU BX6zfvTSa+QyWbZu3kBnR9sHtnzxIEv72RaS52Ks3tHHpzufxFj6g4+8sck0esiWe2i0TFPP jWEsNe8zz7/wMh1trWzdvJH2tvw1p2frOO1TPaRPJelb28XT/dFvZ0tpLclmlnLnMF6yBBhs HSdXWUWq3ka14xzNVPGqMbGMQ768lux0D1jgtZQpt58ljDVuar0kvTz5wlq0E9JomSR/Jgev WHCTBbdWh0X7/XmeXPcAYME/xLGTDoTAEq12Kw6JTXFaujPEhh04trDvsmM2bZ1d7Gp7FCu0 qWw8x7q+tpl9MJKKaSZbznKq8Q6bMqei3yq9momxh+kLN3I+k8CUb/0yOWttVj/Yg+dPIOas M9u+oSRZKpW6LQ89S4KNqJXTyOgEiXiMzo42Muk0mZkn3fK5LA/fv5tvfOtZzo6cZ/3aAVrz LdQbLhNT05dNa2xiiobr0t6aZ81AP4Onh1FKMTwyell2tVguUyiWyaUz3LV9CxvXrbmp5Xjp tbd47c13WLOqn9/4lS9/YE+orGQvvfYWp04P8+B9u/jSZz8hAVmE7//4FUZGx3n4gd18/pMr 96aAZUHH5CFMtYilagC0pRWP72jhrm2/viTf+cLLbzA5XWTXjq38D//012VjWoTnf/wKE5PT 3L97J//9b/6qBGQRvvODFxkdn+CR+3fz9V/9BQnIIvzDcz9iZHSMJx65n69+6bMSkBtQrdX5 x+/+kJ3bt/DrX/kCq/t7JSg3aHxymm/+4/fYtWMrX/vKF+nt7pSg3KAzw+d59vmfcM/O7fz6 V75IZ3urBOUGHTl+ih+99Br37b6Lr33li+RzyzNZrrVmZGSEn77Uyvbt29m5axfJZDK6fhse 5tVXXqajo5OdO3eSzWWpVKrs37ePXVs28MSTT9LR3s7x48fZs+ddtm+/k7Xr1uE1m+zfv48d d6zhiSeepKenZ0Fjo4VhyL59+zBenelaiLEdOR9cpJ/tPUitXkcpLTFcpDff3UulWiObSUsM F+mVN9+lWK7Q39MtMbyC2Mjf0zbWINmcc5/MSWHd8Vt85s5PEZDl9bf3UCyV2bRhLV//lQ/v dUlj0mbidYfs+i46tm/ESd6aRmN79h1iVW83n//kR9h6x8YPbPnCpsXEuw7V/TY7PnM3+fV3 LYuia6Ohes6muNeh9U5NfoO6rKXj62+/x6b1a/nCpz/KpvVrZ/5w5k1r/v9rBeVBh8mXHDbf k6Nr9yYwFtMHHdzzFj2PbCHVEbUv9GsWpaMO9SGbjvu3kO3VOGkTff/c1W+BDqFwOMbUTx1w DK13a7ru2UE8exPbiYFmyWbiTQc7AR27FIV9DhMHLMxNJtjifQ67nl5Hz/0DGOBvvrcfy1jQ ZOkSbHmLjh050psy1FI2zSGi77se3yIxnSJRT+GsNmx8ZAvd920ilpof27TjkvbuIZz8c2L1 I2iTpVjop3CsEzO1NNVbuc1J7n9mN22b4cW/eF8OGsv9mCYhiEp+v/HNb2PbNs98+qPcs/PO eT9mfhAQhiEAmUyagVW9sxeOSuvZRFaoFAePHsdxbAZW9dLWmqenu5Ouzg7eff8AQRgSi0Uh V1pz+uwI06US9+y8k66OdpzurptajsPHTmJZNpl0irUD/TIG2yJ0drQTcxzaWvOsXb1KArII He2txGMx2ttaV3wMY/4WjLsXZhJsMePS7kzTvrobnFvfbqanq5NUMkFrSwsbbjLh/vOqp6uD RCJBW2teYrhI3Z3tJOJx2ttaJYaL1NXRTjwWp6ujXWJ4g8qVKpZlk2/Jsmagn/VrBiQoN+jC E32t+RbWDPQzIEnKG6aUxrKgtbWFtav76emSJOWNqlRrWJZNWz7PutWraGvNL8v5NMaQiNmc 3bCODevXsmHdmtl9aFVfDy3ZNPv27ePE8aPkcjnq9TrdXR3ce++9bNy4kUQiQXdXB6lknMHB QXzPxfM8ctkMTz35BFu2bCG1wDH8giBgcnyUllyWhmqiceQYskjnRsfJpNMopSSGizR09hzp VJJsJiMxXKRjp4ZIp5LkclmJ4WU/eGWYPAX6Yq8zY8VRqXXoVc/QnxwAK8axk4MkkwlyueyH +v5MORbidjTp6ImxaiBJPHVrsk+JeJxMOk1vd9cHGj/f1QRnPIJ8QG9viu7ViWWRYNMKpnwf P+/T3ZOgZyCOE5s/Y/F4jEw2TV9PN2tXr0IFhmZVY8cs4imLZlnjJCxSeRujDGO1gHLSJWXS 5K0ExoAbC7Bzmv6+FC3dMXxXMzrq4w/5BOc0XmuSXCxGz44E6bxD4Gm8qiGesUhmbbQyWBMe RTxMaGhtSzAwkCKVu4miCgPVlKKecwldQ85KUHcCLMu/6dpJO2XR3tXCmtUpjAHL3h9lH5ay BkRHbTeT2DSMAnvhmTwzNTPfG2zaOtKsXpUikbl8Zh0/Rz3ukzv7/0Bgo7WDcm2WqttpPBuj t7+TvtVJLEc61C13kmADkokEU4Ui+w8dw7IsbMumt6cTz/M5dnKIN955j66Odnq7u0inU9y1 fQvv7NnHO+/t58cvv8E9O7cD8LP3D7Bn70E2b1zPnVs3E4s5DPT38vhD9/Hcj17kuz94kYfv 300qleTYiUFef2sPmXSaxx++T5JhQixDKrMBHW/F8UZmDtoB+NNQPwv5LRIgIYQQQogVzLIs Ojo6eOKJJ8jlcrMPQwKk02l27NhBb28v09PTBEFAKpWiq6uLzs5OEjPjAbW2tvLAAw+wdu1a KpUKtm3T2dlJT0/Pko3zIIQQK9r0HijtB780+5KJ5Wl2foJwJrkmxDI6WwADWkOzqhk94JPM 27SvjTGy1yPT6bBqV4ILKRDtwfT+kPqYRrkGrSHTczFhE/qG0lBI4SWFGjV4g1FKq3NjnFSL oT6lGTvg074hRvfmi63tVMOgqgZjbt2S6RCK7ynccY/meX3T1WsfFNOExiGNP6EJzgKL6J5p 3CgeV4uvSvTQ7PokdlAgfvIwYRgDLYkvEZGjFpDNpPncJz5Crdbg7T37GJ+cor+3B8/zODl4 Bs/z+dJnP87G9WuIx2LcuWUTH3vyUf7u2e/zZ3/199y7804Mhj17D5LLZvnk04+zdWb8rr7e Lj77yY9w9OQg3/jWsxw+dpJUKsnxk6cplEp85LEHefj+3bIShFiGwsxGTOyStlBhI7oYyG+O TrSEEEIIIcTKvRbMZslkMkCUcLvAsizS6TQDAwP09/ejtca2bRzHmfc527ZpbW0ll8uhdfTE tOM4C2oLKYQQP3d0CKPfh+qpi69ZMVRqFW7PM2DJw+fig2E06NBg2RbWzCHcwiKuUjQLMQpn AtyiZnJ/QLbfIdViUTmjMApUALH4xU28cURTDTTGhfQui3TnnHtHJvqMLhnMGKi0QflRYscY CJqa0qAinrHo3BDHjs35Oy+aRx0ajGZ2Phe/0NA8ami8FYIPprBCV14DwvcNYYZFJdcA1LQh aERxvTILleij0fdVnMI3CVTiGp8VP28kwTbj4089RjaT5kc/fZ1jJ4c4MzwSXSzlW/gnX/0y z3zmo3TPtIdpb2vl4089Sjwe5/kXfsqrb70LQF9PF898+qM89tB9tOWjNiiZdJp7d97J7/72 P+Fvv/099h44QqgUHW2tfP6TT/PxjzxG7022hhRCLI0wtRYdb4/OWi4cOcN6lGBb8wssi74G QgghhBDipljXOKezbXtByTLHcaQriRBCXE/9NEy9Cc2x2Zd0LE/Qsoswux15iFXcbkZB6Bnq BYVf0+S6HVJ5B8uKEmxJv5XKgQRHXnEJK4bGKU3zDoMKDLUzmlSnHSW84jPbrobwrMFUwEpB MA562zVmILxkfgyEdYNb1CjfYM+0rTQadBkqQ4rC6pCuO6yoTeTN7jIqSvR9KDRuYjtwuX7C zHJQyT7c1b+MSo/Jz5WYJQm2GfF4jCcffZAnHnkAt+lRqzeIOQ7tbfkrXnD1dHfylS9+mi9+ 9mMUiiUsLDo72ua1Fbkgk0nz1GMP8sQj9zNdLKGUpjWfI51KSeCFWMZ0vBOV6MXYGayZcdhm E2wYCZAQQgghhBBCCLEgBs59GxrDc+5kW6jUapqdn5IHWMXt2Qr1hWqxqFopbBj8mqY6ClNH A1Y9kCCZc2aLKR0dJ5iyafxUoUcNpgnhOUX9kI6exd49Mz0NRs20cPSBBpgGBIMG9Uj0XQu+ i6SjEUqMYd4fqXOG6ZcUsaxPrschmbVlt7nFP1HX/YiJEcT6cTssjGTYxAxJsF3Csiwy6RSZ 9MKSX4l4nL6e7gV91rZtujs7JMhCrCAqtQaV6CbmziTYlAvlQ1FNv2Mjj6wIIYQQQgghhBDX YkB5MPxtcC+Wyxg7QZjZgNf+hIRomdMadGCwHHAc67JbIVoZVAiOw2zV1bLbCg3UphTViZB0 q0OzrPGmNW5RYxS404bQm9le5yygMRb4ZraFoh4CPWSI7bLQYVTN1qxopk+E+GMa05zznXUI quBVNZn2a4yhZqKkWtiMWkAq3+A3oj6QoW/ARGONhScNfsmglblkLsXt2H7cimLyeEjpfB4d Bkv3XcqgAi1tKFcISbAJIcQ1hKm16EQ3uEMXjnIQlKF6HPLbwI5LkIQQQgghhBBCiKvRPpz/ XtQiUvsXr7czm/DansDYCYnRcmaiBNHEcZ9sp0P7mhhOfG4CCmrTisJgSPu6GPne2M2PD7ZE y1EZDTn5nSaJVouwAdV9mqAaEs9Hz1HfSLci44NqQtDQFIcV4y8HeO+Zea0KTRNqhxVnXvFQ j0Km/cqBUYGhMBxw/h2f+jFNUDTowCWWsmiWDLpxcb7ChkEFrJDGSh+eFKDR0Chqzr3mU/xh iB5dumXTfjQen1bSPWslkASbEEJcg0qvRSUuqVLVARTfg9wGSbAJIYQQQgghhBDXvLBuwsn/ An5pzos2YWaLVK+tAFobvJpm+lhIuM6Q73fmJdiiBJxh+lhIusOmpdtg2R9sYuVC5Y9lMZvj 0doQ+gb3tKG4V0Wfq0BwVGFlIfeEfWNJK2XQgSH0wa9qgqmLVW6zGuC9bZiKh7RuiJFquTzB FtYM1XFFbVQx9UqI97bBTxnq72isjEVqu4V2Z5arCaoOOrzQP/LG4xy1tDSYpUje6Jnx4lT0 HXGdxAot8D4k+4IyhDWDGrkd2/CFKkWpU1zuJMEmhBDXOl9KrYkq2LCYPdPSAUz/DAaekQAJ IYQQQgghhBBXvahuQukAFH4G+uJddpVeQ5C/G53slRgtY0ZDfVpRPBviFTVBl41WV/icmUnY LIOCGx0a6sWo+ifb4RBLWGgVVR/VxhSqYjBjc+a9ESWutBc1LbqRZTA6qj5TvsFcLYnUABPM xOiSietpqB5SnA08vCmDf9zMjt9mCmD1GYxngZ4ba67eavK6Mwy+q6mcV7jjZl47y1sS+xrU RhVuSYEFOa8Vu+F8SHYGgw7mFeHelu8Uy58k2IQQ4lonB04OnexDx9uwg+LMi36UYFOeBEgI IYQQQgghhLgavxiNveaXmTugkN+yC7/1AYwlXWGWLQOhb5g6GXL2Jx5+wZBdZaIk1NX+ZBnk A1QAhaEAr2pYfa+FE3eiFoynAybeDgkGrzCTDQhLUYXbgsPThLA+k1xb7HI3oPmGwTuowOfy CjgfwkmDmp5pPZkBdLQOjAJuMHdlDLglzegen8q7Cj19a2OvJwzF/YrKXYp0u00iTELzw1GB ZQyEnkE3Jekl5pMEmxBCXItlEyZXoZKrLibYjILKsai9RaoHLEfiJIQQQgghhBBCzKUDaAzD yHeZm5XR8Q6Cll0Emc0So9vA6KiqS2uwbHBi1oLGSAuahukzAVOHA8qvaqwEqAcMWl85waD8 aKw2FUbVWtacRkC3c1lD39AoaNwpTdA0pJQhaGrqE5rGMT2vem3e5upGm+mFWbawsbUTVZ+F V/iuIFpmvdCqt6t9ZqZi7Yp/UoDg+JxKswZ4o4bpEwGxlEXH2vnj4V3z601UbefXNe6YJjg+ f7y4WxL/wkyi0jMz+fQP0RhsM105jeGWx02sbJJgE0KI61DJVajUAPHaoYtnbEEZaichuwZi OQmSEEIIIYQQQggxl1+AqTehepK52YUgdxdB9i6MI9fSt2U1uJrpwYDqmCLVatO9JU661YkS YNfgNTTn3vKZfDFEDRmctdY1Wygqz+AWNM2KojalSbZYZFpv7wPJQVMzdSqgcDjESVmo0OBW NGOHfKYPhKjJG8v42TqGbloY9yof0CwouWbCG0jEXfq3l1S1+UcMI88H6BDyfc6CE2yhZ5g+ HTB+IMA9d+vbQ87OrxR43VIOMSxjQSCxWK5sCYEQQlybSq5CJVdf/kbhPQgqEiAhhBBCCCGE EGIeA/XTcO5Z5mYVjJ3Ab32QMLtFQnSbVkPoGSaPhAx9y2fsvQC/fp2x0i5UOjU07qjGPzAz LljdEDbM3E6f0WdDQ+hFBYsqAL9hmD4eJfS0Wvpsi1bRMqrQEDQNhVMhpTcVflETeoZGUTPy akDxRYUaudaEiOZ3zvJZxobwKp/3QbkGHV5/GXUNvKLGrxu0f3MxMWPQPKzxSnr+urgO5RuK gyGjPwpo7tVShXWVbX9ZzY6BjM5hBZLCWc6kgk0IIa53IpTsRaUGwIrN7wtQ3AtBDdISIyGE EEIIIYQQYlbYgMoJmHpj3ssqtZYgfzcq2Scxuk2MhrBp8M8YGj2a2oQilrRw4haJjBW97xli KYtY3CIMDMXhkLH9Po0hPVvppKchdA1GR2OOhb7Bq2mq44rxfT7uiCa7SuMWNV7FEM9oGiWN 8sySJS6MhnpBUTgdkG6LkhBeUaMmDX7BUBtXhE2on1CooWu3RDQhhE1QyuDMbW14lXk3BQhr BhUsIME2ZSgeUijfp3xMY8o3u3/deKWYIUqyhRMGPSz7xaWUHyVpMSybzpYqMOTDDizPAV/W 0XIlCTYhhLjeSYidQiV6UYleHG/O407F96NWkcvp6CuEEEIIIYQQQnzQaoMw+Soob86LFs3O jxOmN0p8bjcD+Ib6Qc1Qi0e6xyfdbTNwXxIVRFVfXVvitPY76NBQPB1y7ts+zTcvSUrNjEGl laEyGjK616d2XlN8K8QfNEzpEK9o8KY19bOK8mmFDsEsUSWbMQa3qBh+ycfJRGPLlQ8o9DS4 xwxnf+gT1gz+iYWNN6ZDc0NVYRfG5brudIeh/KyiklWY+uVtHxe9ThfTclLJ7nAZH1TTRNsq y+MOnzFQLwWsrm8h1kwtWUtPcfMkwSaEEAugEz2EmU3zE2yNYXBHQN0FjpSxCSGEEEIIIYQQ AFSPw/hP571knDR+++NRhxhx22htUM1ozK3ghGF6MMTKQuYhm3jWxoSG6UMhmS6blh4HFc5U 81S5LCmlmhDMJCKaFc3knhDViD6rh6ARalQD+P/Zu/MgOc70vvPfzKyrq280unEfBECAAAGS IDEcDklxOBqNNBppLFkejSVZ2vWuLW84wrvhP+zwRuxGeL1hO9YR1obs2JC0tmXJK49k6xgd HkrDuXhgODxwkABxXw2g0Xd39VFnHu/77h/V6EYTGBJ9orvx+0RgyMkqFqqeynrzzXzyeV4L 4UVL0GHJ7vFINy5+ysI5sEm9LWVcdEycNJgC2H5Xry4rOMYuTmWTlqodogGT1N/HJyXmXGGR Emu3X8/U23PaxOEHnu77XoyYrqQekQ7CsqG52o5fCaCq72elUoJNROR+5kzZDST5R8mOvXnH wc7C+Iew7hnIb1OQRERERERERGpDMH62vgbbHcK250mym3FeWjFaRjaBuOxwcf3/3070VBsd N4MQ58DzIK7WWz6O9SRMXDPYjy45X4Fqr2XsekK2ycdZMGVHMsF0dY0rgxmvr2NmB4HEEaUg 2Lf42Z8kdIz3JhSuxcQFR3y2nkSclUxb4nXG4hHH2OWEaMLdHa8l5MpQ6bUMno9o356mZWNA kP6EGLv6enWyejgLOG/WuoCy8ijBJiJyH0x2I3Hj3vqs885G1+OnoDasBJuIiIiIiIgIwMRZ KBwHO3vRoNr6L2IzXYrPsvFwxiOJ3OxOnVPMBUdpqH59I3vYIyxaqhOWgRMRI99JMDfvruap nbEUDiW07UjVK8jCeqXa7TXFXAHia66+XlQFbKWe3MvtmXoBB9aCsw7P9/CDeX40B3HNMnQu ou87MbULbsHVYc7MfV2z6KJjqJrgatwzXkvFFaD4tqU7jrBfgvw6/xMTbNa4+hp6qoS6d3zi +h9nwQsUD7l/SrCJiNzP5MXPY3ObsJkN+OHAzANjH0I4rACJiIiIiIiI2KR+I+rYyZltno/J biJufgqbalaMPmqJ8jK+SxEW0oz0x4T9tp70+uhfPZWUshGEk45KwVAddCRX7r1mmS3WE2Y2 qb9pd7tS7Y7nuoG7/w4bOWpFS2XMEJYt1XFLQ7tP0/oU6Wx97bQ5h81CVHJUz7vFSW6ZqXW4 5lDl5QYgHngwbQXNBUe4wZLU3H3tY87WPx/G6Tf30fDUoHLLUriRkGv1yTX6s1puOjtT4Wlr yzs2eE69P1c6JdhERO6H52PTHcSNe8nemWCr9EClF5IKpPKKk4iIiIiIiDy8yjfqSylUZ86b nZcmbH8Jk+0CT5ci7+RsfQ0xtwQ5D98FhIMpet+PqZy0H1vhZSeg8GHC5BVD6byZbvl4l6i+ DptNmEkM3kcbxvC6o/etiNFLCUnZUe61NG7x2fJchs5HM6SzC0giRG5RWkG6CJKawxoHbvXs P/f93KnP5BL97u5SgdJJy/D2mPW7U2Qb/VlL2sU1y/CViMETMXHfMuwctv59mdgSmABiJdlW Mh3VRETu9/iWaiduepxs4Y512EwVilfqPeabdipIIiIiIiIi8vAafRfGz9T77QHg4YIGqp0/ hQsaFZ+PsIkjKbs5JUqgnlhJwvqF/iADfnD3BXjPedjYIx5x9Sqzj2FuOSbftNhxh5vkhyas XK2+7pqJ55ZkiM84hscSvAYPPw9m1FHZaslvDFi3w805webu+pfF4RyrJrl2ZzCcitIWzAw5 4qKbSR57M/E1MUzcMIwdNcTnlj7YLnEkocVLgW9SoLXzVjQl2ERE7nfim24jadwPnj/7NqHi Raj2KsEmIiIiIiIiDy9Tra+9Vrwyvcn5aUxuB1HLp3B+VjG601RixM2jZV9UtfScCEmqjs59 aVo21lstMs9CF1cAU7i/9+HM7fc+h/ddAXN56kNPNf/xW+utI+ec0Jpaf608aogm3OJWZK2y RJWrQm3MEhYt2bw/r1abMhXLSaj1WYqDhkyjR0NLMB1P5+qJN1NkUaolP4mtOeKqxc+ocm01 0M9OROR+D3BBM0nDLmzQNPuByakEm4iIiIiIiMjDqngZJs5BNNOL0KVaqK3/Ai7IMe/sj9zF xI7CxYTur4Vc/VaNycEEa1fJm6/U/7h5VuVYCxP9hmvfDhl5I/nE6rz5ClwKzwVzri5cTsk1 x8B3EobOx8Thynqjzq6y9cMqUH7PcvmPa/R/GNVbhT4oocFWixCO46U13q10SrCJiNwvz8em WombHp99YlC8ApVbamQtIiIiIiIiD6/+V6F09c6TaGyqjer6L4IXKD6LwYGJHHHVYaqO8Kyj eMVSHjHENbuik0GL8vEtJJGlNmEpX7fEZ92SVBQ5sDrwCwAAIABJREFUB+1mA42ldZhxD6IV Go8ChBct1YLFxCtsP40dgUnhraJ90nZD+bSlMmKJqg6bPKAk20QC184TXHmXpi3q/7nSKcEm IjKXOUKqkbjl8EeOwCGUrteTbCIiIiIiIiIPG1ODwTegfHPm/DnIk+T3kOT3oeq1xWGNY2Iw YeDDiEqPhQhqNy1Dp2IK1xOSaHkuxi/Gml8uqidh5vJacegYuRYzdDom7LO42lJ9PkdHtJnm wS6SSz6usIJ3igSS2lQyaCXkYmx9P7WJw7cBrLKkrx13TFw1DJ6PqIzbB7O+nQEKEa4UkVIF 24qnNdhEROZyoA0aiZoPg+fNnlGWr0OpGxp3KkgiIiIiIiLycBl6HSo3wc6U0ZjsJmrrv4AW hloc1kBUc4zfTLj17YjyMYsrQHzWMZRKyK3zaduaIp1b2mSmqTiSmqtXy5n5v46bdMQlN6dW fHHNMnwuYfDbMdGpRa5eM/V1tpwDHKRchqCaxvWv/H3DmXp1n+PBp7JtWK+wzDSt0t/ZIIy/ ZfBTEY3rA/JtPs5ST2Ca5fs+yzWIs82MXwOtXrmy6QgnIjKXg5zfQNL42NQ6bHdMW8rdULqm AImIiIiIiMjD59Z/g+oAMyU0Pia7mbD9JcVmoRzENcdEX8LA2YiRswmV8w5zeerhAiS3XL1N 4FQVU+BSZEwjturj4kUswalAeMMxfCZm9HxMMjr/13bleuGjTbj/yisHpuZI+ln0qjKXUE/4 JY7V1JTPxWDCFVbBlrB625VWID7jiAoOZ+r7gjUQlRwuXKYKUQvWgSGFi1T9u9Kpgk1EZC68 AJtuI2ncR7p4Cs9ONeIu36xXsDmj3vIiIiIiIiLycHAWaoMw+i7E49ObTaaTuPkQJrNBMVog axyTAwndr9UY+8AQXneYG7Mv9LsEbMR0giXr8rRNbqN2NU3cy6JWesXnHIMk4ENyZQEJttpU siyqt4n07iOPsKTt+hKwsVt9iaEI4qJbtvag9zMksNqXDavcvePZuL6PiHyUEmwiInOdLPgZ otYjpMsXpmawQFyESk/9jr38FgVJREREREREHoIT5ASG34Jq3+z2kPmdRG3P6QbUBTKJozpu Gb+ZUDhuKH/L/tBkmTUzCSjfpchVm4mHfczNRc52VCA+vjiv6Uw9gXhfrQ2nWjeu2sqoJXQ7 weacVjtctKHNTP2m7IPLF1p9m6uCWkSKiMyVlyZqeRbnZ2fP9Kp9MHlB8REREREREZGHgw3h 1p9BXJo5O/YzJA27iJsOKT4L4aA2aek5FnLz1Yja2R+eXHNVSCbdHckqD8/5EHmLu07ZIjOh w8Tuk0vTHIQVy0RfQmXA4spO+8edP8OonhCSxRMOOQpXEyYHEpJwedtvuhQ438NmG/VFrAKq YBMRmeuBzksTNx/CBk34FICp26duJ9g2fl5BEhERERERkTV+cmwgHIWhN8DMZHFsZgNJ/lFM plMxWkh4ARM7Sr2GyTcMtvtjnjsJSWWmvaGHx2qoZbI1MPEn59esg+KQ4ebrIeNHDXZU+8dc GOMwkcNEisX9qp209HgRzjo69qZxbvkybC7rYxrT0NgJKHO60qmCTURkrjwfk92EyW3B+ZmZ 7dX+eoJNtw2JiIiIiIjIWpdUYPQ9qA3NOg+OG/cRN6t6bbHM57p+4NIEJsDFK/uzmZojKtp6 FdsnBCGuOSq9juSiW9FVeStu/7FQHDQMnImo3LS4qmJyX3EbgPCqIyo57HJf5kv7RJ3bIcjq i1gFlGATEZmnuPkpXKp5ZkM0BqWrEA4rOCIiIiIiIrLGT4onoO8vP7Iolk+Sf5S4cb/i8wAF Lo1vUpCs4DdZgfC6Y+h0THnEfvLaalNrsMncWOuY6E3oeSWi9I7BDSgmK52XWPDAs7GWsVwF lGATEZmnqPlJbNA0e2NtqH4Hn4iIiIiIiMia5eo3mfa+Mqt6LcltIcnvxqbbFKIH+NUELsA3 wcpOsAHRacfYB4Za0eKUPJvf112b+qcD59zdcXRgIkfU6zCXFa/VIAgtnQNX6Ow/Qetu/TBW OiXYRETmKW55Gpdqnb2xNggjSrCJiIiIiIjIGhaNwdiJ+j/vKCuKmw6R5HezGtb/WnPuqPAK XBo/TuPCFf6eK2Cr9QSQMmzzl0w6SoOG4qChPGrq8ZTF+10t91+Z97HNGfxsCmv1Fax0SrCJ iMyTyXSS5HfNbhMZjsDYSbRyrIiIiIiIiKxZtSEYfGP2GuSeT9x8iKRhl+LzALgETFyvYPKd j2c9MCs/0eliR1J7AOtcrRUVqJ139Hw74up3avR+EBKWlZVZlH0zdCRVhzNuWRNtLhsQdW4j 3HqAUr9uVljplGATEZkvL0XcdAiTXj+zzYRQuQWT5xQfERERERERWXuchWo/DH9/1maTVXvI xYkvWAPOuKl/3t9/ZmNHEq6+SjBnwRqnArYFMBcck98xDH47ptRrMQlar24xJBCX6r8rt5w5 S8/DZlqw+Q3Yqr6GlS6lEIiIzF/U8hS5kb+CavfMTDgah+G3oP1J1BZDRERERERE1taJ8BhM nofyjbvOj01uG3i63DhvDqpFy9jNGJtAechQvmlxE/f337q1XrikLNwPZXsgTtUrrqxRnBZl dytD+YZlpD2h2mNxZcVE7qYjnojIAiT5vZjsJpyfxrNxfWM8AUNvwqN/Hzwl2ERERERERGQN qdyE0ffg9jkwgOcTtRzBZDcpPgvggOq44fp3Q6IxR9jnqJ2zuMIa/tAWTAwmcaScd+/LKK5e oWcq2kc+dv+pQlx0mMjh0C3fC45nASpvW2oXYuyYW9u/w9X8Pd2RT34Ql2GVYBMRWcg8MN1G kn8El16HFw7WNyZlGHsf4jFIt4OnbrwiIiIiIiKyBjgLpe56gu0OJr2euOkANr1OMZp3bCEJ HbVJS63fUT5lMUMON7C2P7YZg/ErCY2dPp27MqQbvHuFBhM7kjEHSrL98F1oEuJJh4kVi8Vi e8D2qCJwRe7vDqKaIQlt/f94HkHKI5ML8FPLl2lTgk1EZIHixsdJctvJ3E6wOQNRoX7C0fU5 CHIKkoiIiMgKZYzB8zx83/8hJ+8Oa+s9t3zfx7vHrbHWWpxzeJ43/UdEZE1KSlC6ApOXZm2O Wp/FZrrACxSjebLWURwyDLwfU71uSa7ML5m02lIByRXH4CsJftqjuStFKhfcswrFOXBKHH28 CpiywyYOlbDJmh8zE8vQtTJ958o440g3BDR3pdl6oJmGlvSyvQ8l2EREFjoZbHoMk9sKE8dn prImhP7vQMdnlGATERERWYGcc1SrVYaGhsjn83R0dBAEMxeGjTGUSiUKhQKVSoUgCFi3bh3t 7e2k0/WTdmstlUqFkZERyuUyqVSK9vb2Wc8REVlTJi/A2Af1G0uneYTtP6LqtQUdk+oVWpN9 CYPfjolOzD255kw9SbfqMmwVSG46wnFLEt47MeTsMq0v59bGvqSl6uRhYI1j9GaNi/91gmTS kd8Z0PVkjo7tDTQ0L1/aSwk2EZEFSnI7SXLbcUEOz1SnRvkQ+r8N+/8R0KYgiYiIiKwgt5Nr ly5d4vjx4zz11FO0trZOJ9iMMYyMjHDq1Cl6enpIp9OEYUhLSwtHjhxhx44dBEFAsVjk9OnT XL58Gd/3cc7R1NTE4cOH2bFjh5JsIrL2TJyHsVN3bPCwqSaits9g0+2Kz3yOSQYqw4bRbo/J m4a4l3lVrtkIkppbncmVqH4ZxSZ3rx1mEsfkQMLEDYOZWMLvoQxJ2WGTVb4/xfX16pxzeCph k7U8dlJPvJuKI+61VIDyVoOJ3bLmypVgExFZKM8nadhF0rCLdOns1Mw2geKl+uLP2XXgZxUn ERERkRXAGEOxWOTKlSu89tprXLt2jX379uHuuCJZrVY5e/YsV69e5fDhw2zatImJiQneeecd PvzwQ9atW0djYyPXrl3j9OnT7Nu3j927d1OtVjl58iQnT56kpaWFzs5OtYsUkTU0gFbr57nF q9ObnJ8man8Jl2pC/ejmGdYIRs8kjF82RAWHHZ/fpWGXUF97a5VWL5nQYZK733wSOgbPxAy8 FmP7l+7DuRrEk1NVgKuYSyCJXL3iTx1b5WEZR3sctmZJnrHLXsKpBJuIyGIM5PldJPndMwk2 XP32q5F3oGkXZDsVJBEREZEVoFQq8f7773Pu3Dmcc7S0tMx63FrL6OjodOLt8ccfJ5/P09nZ iXOOyclJrLVUq1WuXLlCLpfj4MGDdHZ2kiQJURTx5ptv0tfXx7p160ildNotImvE5MX6+ms2 nNnmpam1fxbr5xWfeXIGokGHKTvMpMNNLuTFVmkMapBMOqJSff0wPzOTrLUGygOG2ocWV1jq N8LqbxM51U5TbSLXwNiAblu4KyYOTGyxxhHXDCau9451RaDBYWpu2ZPkmumLiCyCpGEnScMu wK/PZm4bOgqbv6QEm4iIiMiKOCl3RFGEc44jR44A8M477+D7/vRzjDEMDQ2RJAlbtmwhSRIK hQKe57F9+3YymQzZbJbBwUEKhQJbtmyhpaWFIAjwfZ8NGzYAMDAwwL59+5RgE5G1Y/z0rOo1 8HBBI1Hbp3FBg+IzX9YR9TrMqMOOMq/2kGtBrccxfD6mqSugZUMK/3b1las3CXJV7SryEM1Z bb3VJ04ptjvFNcPQ9QrjfTXCsmX0Woi9PTZUIRytt4jE1ef9bhkyzZrpi4gsxnw41YZp2IHJ biAI+2ceGH0PwpF6FZun2nwRERGRB8nzPFpaWnj66afJZrP09/fflQBzzjExMUGtVmN0dJTu 7m4KhQLOObZv385jjz1GNpulWq0ShiHNzc3Ta7d5nkc2myWXy1Eul4miiIaG+7/obIwhiWOM ZykWi5/4fN/3yWazSuKJyDKc9MYwfgZK3TPjpZ8jbtyHyW0BT+PQfDkL0Wm3qIk1jwDP+hCu kiBUIDrhGNmU0PW4obkzgMCrJ9fM6l8Xbfl3qtn/rmq2VTjkJo6k5vCUYJuan0MSGcaGSlx7 d4Ibf1khGnWkOzzMZH0Hd0VIKpZyqUqx6CiVSoTh0g+COvqJiCzK7NUnyW0lbtw3O8FW7YXi FWg9AOlWxUlERETkActms2SzWay191wfzVpLuVzm2rVrtLa2snXrVnbu3MnIyAgnTpwgDEOO HDlCkiRYa8lkMrNex/M8MpnM9ONzUSiMMjRYwOLzve997+Onn55Hc3MzBw8epKOjY1YVnojI oqv2QvEyRGPTm1yqibD9RZyXVnwWapGr1lIuRRCncLXVFQNbra+5djsh5ByYyGGjZc4QOUjZ DJ5ZfcdWGztMXF+DzSaO6oSlNuFmdXZdUjFTf7+yegvaBW09uSy34+EY669y6a0Ct96uUjrh cCVHsh7MyB3DSG/EyXfOkOspUSxN0N3dzYEDB5b0vSnBJiKySEx2C0nT41B4ffYRsXAMOp5V gk1ERERkNZzAO4cxhjiO2bx5M0eOHCGfz1MsFgmCgLNnz7Jz5048z5uuXLuXeyXvPok1FpMk WHyq1U/uhZVOp+ecxBMRmZfCiXqS7Y7SGBs0EbW9QH2pBJnbwaaePFqqtbI85+MZb/VUsN3e p6qOpOpw5s5jY32dOqJlfB8GGuMWgmpq1cXQxZDU6skZE0PPsZCBN2NM//Ika2wISdlhjX7m soj7tXWURhP63oqZ+I7FXqtvT4Y+8kTjCKsRrlKhWq0SRUs/cCjBJiKyWJOI7Cbixv04P4t3 561Bo8dg2wC07EXLk4qIiIisbL7v09DQwObNm9m2bRvNzc2kUimCIGDHjh2cOnWKYrFIS0sL 6XSaMAyn13dwzmGtpVar0dbWNufWjR3r1xMHeawX8JM/+ZP39V5zuZyq10RkiTkYPQ7Vvpkt Xhqb6SRuPgSexqA5RdNCrWSJypbysMGUliLxsTqvPdgQoqrDWvdAP4NzjsBm8OLVt2+7ZKrq z9Qr2CZvGEpvGtzAMr0BA8Ywu02lyMKPQljrMBVwwz/8eQ0bsxx5/gk27m1gfHKMarU6r5ve 5kIJNhGRxRrs/Qwmu5GkYTfp8rmZBwrvQ/lmvWe9n1GgRERERFYw3/dpbW0ln8/ftTC67/vT ybZ8Pk8ul2NycpIkSchmszjnqEzdMdvc3Ew6Pbe2aalUinQmgyWgtVXdD0RkhTAhjL0P1Zkr 9C7dTtTyFE5rr81ZEjqGLkQMnY6pDliql5SJmN6vqtQr2BSSebMTUOwxlEcN2Ua/XiVZVlzk ITlcFaHc78GOLE2NTeRyuaU/d1DYRUQWcSKTWU/UcvgjG6dORsrXFSARERGRFc73fTZu3EhD QwM9PT2USiWSJKFSqdDf309rayutra00NzezceNGhoaGGBkZIY5jqtUqPT09eJ5HV1fXnCvY RERWpLH3oTbEnX37THodccszis08mMQxfsMw+EpC4U8N8Tllk2ZROBa2f91yjJ82FAeM1vCS Vc9ah0nqawrez9gQXbF0f7fEUHd12fZ/zfZFRBZz4M90Ebc+C/1fm/3A6HHYeBWa9ypIIiIi IivIR9srBkFAV1cXjz32GOfPn8f3fTZs2EChUODatWvs37+fjo4Ocrkce/bs4datWxw7doxd u3ZRqVSm12jbsmXLx67RJiKyaoy8DVFh9rlvuoOo5YhiMw/OTbXwK7N8bftWS2w+0lrQJI64 ajGhYnPfMSxAPOiIKlNJCZFVyhrH+GCNicGQls7sVOvYT9j/JxzVXkNUNstWCasEm4jIYg7+ QRNJfjemYQdB9cbMA+MfQvES2B8FP6tAiYiIyMM1R7L2rnaLnuc90LXDPM+joaGBnTt30tbW Nuu95PN5nnzySbLZLN3d3QwODpLJZDhw4AD79+8nn8/j+z5btmzhueee4/z585w+fRqA7du3 88QTT9DS0rLkaz6IiCyLoTchHJ0Z01OtJPmdmMx6xWauXP2PM4BROO4KTxWSWj0xZA1M9CXc OBpSOmdwNcXnfpkJMDW12pTVfv7gGOsL6X57kl3Pt9xXRZorgkvqaxCiBJuIyCrkBZhMJ2Hr c+SrN2dG83gCJs5D6Tq07FOcREREZM1zzhHHMRMTE5RKJSqVClEU4XkemUyGfD5PU1MTDQ0N pFKpZU9GeZ5HR0cHL774Iul0etZ6ab7v097eztNPP82+ffuI43j6PWez2elkXC6XY+/evWzZ soVqtYrv+zQ2Nk5/JhGR1T2QW6gNQPEKmOr0ZpvpImncD1p/bc7i0FEZN9RGLK6s7MdH2XFH UnE467DGURoyjL5rCN91UFF87ltUj5+zSrLJKh0LEkd1MqZciKkMJYSV+78jwZQcUcXg3PKc W+hIKCKy2AeBVCu1dS+TH/gjZm6XcDBxpv5HCTYRERFZw5xzOGsplYqcPXuW8bECIyMj02uZ +b5PNpsln8/T0dHB9u3b2bp1K62trbOSXMvho4m1O/m+T0NDA7lcDuccnufdlQS8nSxMp9O0 trbe8zkiIqt3QE/qyx1EY7PXX8tuJm46qPjMNZy2XpHV83bI5AcGO6qY/LA4Qb2CLa46TEnJ tTnHsAa1EUtx0BBPKsMmq0+tnHDlnQluvFWkNmRIIksqfX+dL2wZktCCW55W7UqwiYgs9kQm yBM3P4HJbiSIBmdORCYvwfhZ2PxTEOQUKBEREVlzrLUUi0WiWpnr165wrquF9R0dbN26laam JnK5HL7vE0URk5OTjI2NcebMGfr6+ti1axebN2+mqanpgbaO/Kj7SZopsSYia3NQj2HoNTAz 2Q3npTC5TST5PYrPPFTGDEPfT6i9raTRD+MsUy0iXb1dZKKYzPmnOwojbxmqQ47yRbXXlKX5 jd6ukFyKKXAcGvpPVxj4kxqNTwZzb/e4jHllJdhERBabF+DS7YTtL9Aw/Are7ZORcBgmL0Dl FjTrZERERETWnlKpxM0bN0iiGi2tbTz//Avs2L5tuq2i7/t4noe1FmMMYRgyNjbG0NAQ169f p1Qq8dhjj9HU1KRgiog8UA5MDYa+D8kd7SHT60hy27HpdoVoPlG14CKUXPthIggLjtKwobEj 0Fp181WB6puW6KrFFrW/yeJKio7x3pDx/hrrtjaQyS2sUsw5sInFOfBTHs5CVLUkVYsdX/kV mEqwiYgsxaTZz1Jb/+PkRr83k2ADKF2F0WNKsImIiMjam/9MLfLR1tZGtrGFzVu2sX3bNtrb f/hF2Hw+T0tLC5s2bWJsbIxKpaJKMBGRlcAm9fXXJs6DDac3m4ZHSPJ7FR9ZmrlEDUpnDP27 IzY/k9H6YQtRAXNZYZDFF1233PxWmSDtkftCinQ2WFAVm4kto71VasWEzh154tBy81SRycsx VFd+PJRgExFZikmhnyVs+yw21YwfjwFTTcRL16BwDHb8TfB8BUpERETWDM/zaGxsZOOmTaTS WdLpNH5Qv6P19hpmAMYYjDF4nkcQBARBQENDA9lsFmMMQRAomCIiD1pSgqE3+Gh/vqRhh9pD zvc6gZJFn6wC0UVH8boleswta5s3Ebk/9pqjSMLooyHRC4aF9olMYstwd5XCjRr5tjRh2dDz donSyYX1h12u4UMJNhGRJeHhUnmitufxk3H8eLy+ORyFyfNQuQmNOxUmERERWVOCICCVmjnN tNZSKpUIw5Dm5macc/T39zMwMEA2m2Xr1q2sW7eOIAimW0iKiMgKkJTq7SHdTH8+5wWY3HZM Xueyc+UsRBVLVHa4WFmjjxVRj5HCJLJyx7SSw4QOa+s/1fmm10ziqBUTyqMxtTFDrWSoTsTU Rg223+GK83hvicMkDpsszyCiBJuIyJLxCNs/S2b87ZkEGw4qvfUTlUd0UiIiIiJr+czbMTk5 Sfe1q1QqFZ577jmKxSKvv/46vb29NDQ0sG/fPp577jnWrVun1pAiIitJUoLht2Yl2EzDTkzD Npyny4lzFdcsA+ci+n8QE/cqHiKyBsa1osUkFiw4b+5FbNY6ymMR3ScmuPVOGS/wGLhQptAd Ur58x80ddq7HL0iqljjylqVyWLcHiogsoajtOWymE7w7Wh1VemHodQVHRERE1jRjLf19fVy6 dIl8Po+1lu7ubgYGBnj++ed55plnuHnzJn19fRhjFDARkZUiKdfXD6/1c2cZUZLfQ5Lbyvxr FR7iY2ICEzcM4981mJsqzRKRVa4K4ailVjQUxyKKoyFJdP+ZMGsdlYmYkZ4qt46XGflOSOla zPCFKoNvVwnPmenqNVNyJKGdXu/5fjgLzrplOVrplhMRkaWcRGc6iJsPkqpew49G6hvjSZg4 B+Ub0LhDQRIREZE1yVrDaKHA+vXr2b9/P845+vr62LJlCwcPHgSgr6+P8fFxjDGzWkuKiMgD FI1B4X2w8azNSX4PJrtV8ZkPBzZx2HEHFYXjk5gQrFEiUmTFDmlFCPsNPe8XGbxUIdccsOcz bbSsz97fbzyy9J4vcfWNScZORZhuR5i3lDYkREMWN3THsafgiGuWTH5lrtOsCjYRkSXlEbU+ i8lsvOMolEBtAIaPKjwiIiKydk+8nSOJY/L5PJlMhsnJSYaHh9myZQv5fB7P87DWYoyZ0x2p IiKyxKJRGD02e0z3cyS57djMesVHlnb+UIB4zBFXptZQsoqJyIo8VFy0XP39Ehd+d4KBDytE VXPfLRmtheJQxODRKqW3ElwRbMURjVtc7SNjgplHm8hlpASbiMhSH3CaD2NyW+DOPvXRGPS/ urKPECIiIiILOdn0fZqamhgdHaW7u5uLFy8SxzEbN24kjmNu3LjByMgITU1NBEGggImIrATO Qm0Yxj6YtTnJbcdkN+H8nGIkSy4edIxdNRRvGkxR8RBZkYeLIai9bqi9YwgnLCae2w1zzoEN ma5WswWoXjMko7NfxyUOE9fbRNp45d2Upx4cH1GpVJkolgjDEM/zyDc0sG5dG4E/k4sMo4hy uUItjO75GrlshsbGPNlMZnqbtZax8QmK5QrWWBpyWVpbW8g3aGIistaZ3BaS/G7sxAn8+Hab yCKMvAO1Qch1zV6jTURERGQNCIIUm7dsYWRkmO9+97skScITTzxBV1cXAwMDvPfee3R1dbF5 82Yl2EREVoqkBOWbULk1a3Pc8gQ2u1HxkWURX3MMvhLjErD9qnIXWclcEWzsFtyRwt5yxBNu eu216devQWkgpjaWEA7Yux5/0JRgu/0FWstIYYwPz17kzIVLjI5NEPg+G7s6efEzz7Br+zZy uSye59E/OMzx9z+k+8YtPO/upfJ279zGM08dYvvWTUA9Iddzq5+j7xzjRk8fcZzQ2bGOpw7t 59Dj+1jX1nrP1xGRtcIjan6KzPh7ZG4n2JyBcBT6vwnbvwqpRoVJRERE1tYMyPPo7OzkhRde 4JFHHiGVSrFt2zZaW1upVqs8/fTTbN68mc7OTnxfzVVERFaE6gBMnAFmXyhNGg9gM52KjywL NwDRwANMrDkIXABG12tF7usnY8Akrl6WtoA8x72SZ64CY5cjbOSIrq+8TmBKsE2ZmCzyG//h a/zJN17F8zy2bNpAFMVc6b5B+39s4Tf+9T/j6SceJ5fLcuXqdb72R3/BOyc+oLW15a7X+tzz z7J50wa2b91EkhguX73BP/6n/xdnL1zmsUd3k8tluXGrl9zXs/zSz3+Zv/ff/U0acqpkE1nL 4uYnSfKPkJk8MXOiYipw/fdh85eUYBMREZG1cXLtHEmS4JwlSRKstaxfv5729nY8z8P3fYwx tLe309LSQiaT0c2GIiIrSa0fxj+cvc1PEzfuxaTXKT7ykMxnIGXS+DXdACRyP0w01cLRQrDI Pxs34Zg8EWNDhxt2c/odLwcl2Kb8wde/wbdef4uXnv8Uf++//wX2PLKDarXGD46d5H/+J/8n /+H3/pD/9R/+T+zd/QhhVG8N+aUf+yz/5l/+73e9VpAKyKTTANzs7eNrf/TnXLp6nV//l/8b Lz3/LPlcjgtXrvEbv/01/uo7b7Jz2xZ+5ie1FVmoAAAgAElEQVR/TF+CyFo+0OQ2k+T3YjLr CaLh20cfGHwDyjcg06YgiYiIyKpXq9W43t1NtTjOtSuX+MEP3qIxnwfqFW23k2nO1dvIZLNZ 9uzZw6ZNm1TFJiKyElT77kqwRY0HsOmO2euKy9yp0+Gq+q58F0Csm4BE7usnE7uZCjY+/nfj HFjrcPb+BkVXhOjY/VeuuQTiqiWJlifJpiPjlEq1xsHH9vCFl19k/6O7yWTSNORyPHfkKfbt 2cWV6zcpFssAhGGEMYbmpkaamj6+6mRgcJgfHHufTx0+xOdefI7WlhZ83+Pxxx7lM586zH/5 +iv84N2TSrCJrHk+cfMhkuZDBKPfm5mxuRhu/TnktypEIiIisuoZYxgZGSGslhjo6+XEiZMU Rustsjdv3jxdyTY+Ps7AwABdXV10dnaycaPW9REReeCiApSuQzgya3Pc/BQ21ar4LIA1DpsA kWKxkjnjsGb5Kl9EHspDTc0w1lejOBBjK4v/Y3MJJDVHEtkFrwt3P5Rgm/KVL/8EtTCka30H mUy9+sz3PRpyOfzAB+umbzQJoxhjLQ0NH9/WsRaGDAyNMDo2zk/9+Ms0NzXi+/UMbjaTYef2 rbS3t3LzVh/jE5O03aPdpIisHXHT40RNT5ItHK0n1m679Wew/SuAVZBERERkVWtoaODgoUO0 dGzk8JFn+cKPvsClixfYsGEDBw4coLW1foG2WCxy7tw5hoaGaGhoUJtIEZGVoNwDxSv1xXTu PJdteQqXVoJtvpwDEztMTVmbFa0CpgiVgiHfrqp6kaUaD0uFiEtvjNHzaoX42hJdC3Xcd4Xc QinBNmXn9rurR8Iw4sLlq/Tc6uel5z9Fa0tzfXsUEUUxo2PjfP0br3K1u4dKtUp7WytPP3GA g/v30tbaQqVSZWS0AMCOrVvuOmlc19ZKe2sLt/oGGBopKMEmssbZVBtJ0z6S/G5S5QszDxSv QuF9iLQOm4iIiKxuQRDQ1NREkMrQ0JAniWPWr1/PkSNH6OrqIggCANrb28nlchw9epTR0VG2 bt2qFpEiIg9a+ToUL9+xwcMFeeLGfbigSfGZLwfOgjUKxUoXDzuK/Yb27Sm19BRZIiZ2lAcT qmcNbmj1fx4l2H6IMIy4eKWb3/2DP6WxsYEvfeFlNnR2TD82OjZOFEdkUmmMMZSrVYZGRnnv 5Gl++sdf5uUXn8M5S6lcIfB9Wlua+Gj/0VwuS0NDjjhOmJwsKegia53nk+T3ErU9OzvBZkMY /C5UnlaMREREZM2wzlEql0ilUjQ0NBAEwfRNh0EQkM1m8TyPSqWCMYb01DrWIiLyILj6+uB3 Jti8gCS/F5tej9P6a/OLqoOoaimPGOJJZWxW/uSFeitPEVnSgdEat2Za5uroeA+lcoWzFy7z 53/1XU6fvcAv/o0v88Kzh2lprt+ts3ljF4cP7achl+Pwk4+zY+tmjLWcPnuBP33l2/yXP32F 1pZmDh3Yh7EWz/MIgtRd6/v5vo/v+zjnGB4d5ff+8M8W9L5Pn71AYhL6Bob4k298S3eAzjOG lWqVU2cv8Mf/7VUFZB5OnD5LqVzh/Q/P6SLJPfimzHZneCkX0NZwx+1rw99nuDthYrzK+UtX FjwePKyOf3CGwtg4H567qBjO07snTjE+Mcn7H55TDOfpnRMfMFEs8t7J02SzGQVkDqrVkCRJ uHilmz975dt0rGtTUOZofKIIwPmLV/n6N15Vh4R5GBoexVrH2QuX+eO/+CbNTaown6ue3gES k3Du4hVq5UmGhwb48OI1Oju7CFL1U9A4jhka7Ofq5cvs2vMo13qHp6vbHkbGGK5eucylq9ep JAGkMjoOz9Plq9e51TeAtVYxnKcLl67RNzBELjehGM7TmfOXGRgaIYziVRPDlmzCIXOUXeHw 9LbYwts38pzvfYvQW94WkecuXmakMM7V7pur+/qMCfCG2/BOdeGdbYDCEh3rIqjeijj51i1O 9A8SFSNM0YGq5uYkHjZcPtHPpfIQrhZA4rjrgq58rGTUcP2Dca4PliFp1Goo8/k5Dxmunx5m 3e6GVVdJeT9v1ySOuGhx0dq46UAJtrsuSkxy4tRZ/tur3+PDcxf52Z/6Ar/6y1+lsbFh+jnP PvMkux/ZTktzE1s3zyzG/fkfeY7JyRJ/8c3vcurMBfbufoRMKo1zjjiO7trDkiQhSRJ832di ssiv/9bvLui9l8sV4jjhxq0+fvs//5G+zHmoVKuUShXeOfYBZ85fVkDmuR9Olsq89e5JTp25 oIDcw9Nbiux4oZO2hoE7AneTcp8jnOzg5Ogk13t6Fah5KJUrTE6WKJbKXLrarYDMQ7FUYXKy yPffOcGZ85cUkPnEsFhmoljkte+/w4lTZxSQObDWEscxp85coPvGLdJpTVXnfEKb1K+ivP/h Oa5ev0kqFSgoc72wEidYazn+/hkuX71BEOimtbkKw4g4TjjxwRnOnU9Tmizwze+8QSbXQCqV nopzRBxWyTY0cvLCDdKZ7EMdM+csxfECIwO9pPNtBJmGBZ8fPqyqtZDJyRIOpxjON4bVGhPF Er7nKYbzvbZQqTFRLNI/MLxqYvho2yi5py6za89MRiZO4BsnI97s/kvKkb/s+2GxVKYwNkHf wOrtIdZk23iq9DJ7b2wiU1rCeZmB+JrhatzLydbvsGFsJ27cKsE21/ORPkf/m2Nc+PAk+ypH QNVsc4/hkGPkBxMUGgfYGu/FOaUo5/xz7rUMvT1OuVYmsO2r4z2HjupEQlQ1BCmfj1te2SSO uOzWRHtIUIJtlnKlwtF3jvMHf/INRgtj/O1f+Dn+1s//tbsqwTZ0dky3i5wVzFSKJw8+xtF3 jjE8OkalWqO5uRFjDGPjk3w0w1ap1iiXK2Szafbs2sHf/x9/aUHv/8z5S/z+H/4Z27Zs5Ct/ 7YuqYJtnDF/7/rt86vATPPvMEwrIPLx/+hxvH3ufTz/zJM88dVABuYeW1ASVhuPAn3DnrTw/ tj/haiFiIreNl37ks5BuAk+/47nuf0ffPs6+R3fxEz/6ogIyD8ffP8Obbx/j8KEDfO5HPq2A zMO7x09x9O3jPP/sYZ7/tFq/zkWtFvLPf+03Obh/Ly89/ynWtbcqKHM0MVnkX/zab/LE44/x 0meO0NrarKDM0fBIgf/7N36Hw08c4KXPfIqmpryCMke9fYP85u/8Ps8cPsQLzx4miSN6b/Uw NlYgjkLAI5vNsq5jPZu3bqWpqfmhP3cxxtB99QrfP3qUqknhgsyCzw8fVle7b/Lm28ex1vJ3 fvkrCsg8XLpynTffPkYum+GXv/ozCsg8nL94laNvH6ettZmv/vUvrYr3vNMe5aDXd8cWDz/T xJ4jX2Hj4WYsyztOX7h0jXdPnGJD13q++PkfWb07Q5Ii1bOR1LfScHYJ/54AUjsDdn9uEzt3 fp73/tMNPONBGVUQzYHf6bHx0+2s3/8kI//OgwAl2eYRw45nW2jf5BH9LnghWs9urj/nTT7r DzdDkyFZJdnJykXD1e9N0tieZuvjzaTSH3PMcGtrXFKCbYq1ljd/cIzf+f0/wRrLP/4Hv8qP vfz83d+/c8RxgjGGVDpFOpW663Ec+L5HS3MjGzvX46zj6vWbWOu4s+vJyGiBkdExWpqaOPjY Xo48dWhBn+GVb73GH379G2zdtJFf/LmffqhbrMzXN771Gu+dPM3TTx7gl/7GlxWQeUinUpw5 f4kjhw/xiz/30wrIvUccMpP7sadexTeT01sPrBvg7zwzibd+I0++lILNL0OmA3y12rxff/Tn f8W5i1c5fOgAf/eXv6qAzEM+l+PM+Ut86vAhxXC+k6sgxemzF3n+2acVwzmamCzyr/7Nv+fA vt189We/xM5tWxSUOeobGOJf/NpvcnD/o/zCz/00WzZtUFDm6Mq1G/z6b/0uTzy+j1/6ypfp Wt+hoMzRqTPn+ff/3x/y1MH9/O1f/Bs0NzVSq9Uol8uUy2U8z6OxsZGmpiYymYzOW6i3zDx2 7BgjA70MTtSwBDqGzNPRd45z/WYvxhjFcJ6+d/Rtrl2/SXNTk2I4T9/83ptc6b7B1s2bVkkM HXx4Hq5UoTq1xc/itzzGl3/kKzg/t+zv6Nuvf59rN26yd8/OVX19Jokc/Wcizp6vUj27hFeU M5DfnmHvS3vZ9swhPviz/0SQ+DDEmlnnaDn4WZ9tBzaw5yd28rXfOwlpTwm2uZ4Prw/YfqSL jkc38/3/3A8+SvLO9ee8MWDrsxvJtQd88LXC6pjLXrAM5WoUPxvhjIOH6FKmSiOmXLhyjf/8 R39BOpXiH/zqr/Dyi/e+a3+yWOK3fvcP+Pv/6J/yyquv3fX4mfOXKIxP0LV+HRu7Ouns7GDH 9i0cffsYYRzVE3DU20NeutrN2MQE+/ftJpfL6ksQeYiGXptqIWk+MH0Tj3NgjWPXuiq7OQon /iHu6M9D3zcULhEREVm16jcoxlSrVaIowvd9PM+jVqsxMjLC4OAgpVJp+jxJREQeAFOF0jWo Dc6M30GesOUZdOlwlaiACx0mcqoWWsi8pQomql+jEZE5/HaKYMsQlS1h1WDtw/MjUgUbYKzl v/7pX3Kl+wZHnjxIuVLl9bfevet5h/bvZV17K22tzVy70cN//Nof4/keTz2+n2qtxrdef4tX v3eUfXse4eknHieTSbN962b+2hc/z7/6t/8v//zXfoOv/sxP0tLUxBs/eI+//PYbbN28iS9+ /iV9CSIP12EH31Twqz0kBiohREl9AjdYCvA3fZ5t256iYfS7pC78Ol7Xy5BuVbtIERERWWVT Hke5XOLK5UtcvHiRcrl811Py+Tyf/vSn2b17tyrZREQelIlzUBsAN1Nm4oIG4pZncJ7G5tXC ViGpOt20IiIPhBl39J4ok23y2f3pdhqaUvc8P1hrlGADyuUK5y9e4VZvP+VyhdPnLt7zef/H P/lfeOHTT/PyC5+mUqnxyrde41//P79Nc2MjxhpK5QqPPbqbn/+ZL/LMUwfxPI917a184XMv MDg8wnfe+AEnPziL73vUwpA9u3bys1/6MfY/ultfgshDJAgHyYx9Hy8qMMEW4mQAa+orDzdl DDQ2U2v5NDhHS9/vQM/XYccvQKpRwRMREZFVw1rLrVu9vPvO22QyGbZt20Y+P3tNu0wmQ1NT E57nKWCy4ty+BqTdU9a88Q9nVa+BhwuaiFqe1o2eCx5IwCYOlyzDRWU7lSNVfk1EHsTc/5pj 4JUaQdZj26Fmco2pWXMo5yCOLGHFYKOlHaicdTi3PBM4JdiAbCbD3/2Vr/LlL/7oxz5v987t pIIUWzZt5Mtf/FH2PLKdnr4BJoslADo71rH7ke3s2/MIba0tQH09qm1bNvErX/1ZDu7fy8DQ MMZY2tta2LvnEfbu2kk+36AvQeQh4iXjpCpXsX6eidYfJ1v+Qzzqd3RnUxbiXky1QNzyNLb/ 9/ELx2HbzwFKsImIiMjqYaxhZGSYlpYWXnzxRTZu3EgQBHcl09LpNL6vC7iywvbfxFItJvi+ R64phR8oyyZr2MQZqN7ZHrKBpGEHNtMBaN9fCGshKjtcrFiIyNqX3LKEY4awYnHOzZr3W2MZ 7aly83iRyk2zdG8igrjiiGvL0zJXCTYgm83w4597cU7/zZZNG9i8sYvEGCqV+gqwTU2NBPc4 Mcyk0+zauY1HdmylVK7gnKMhlyWdTiv4Ig8hz1Tx4gJRZjPldT9BevhVAludacdRvIIrHMdu +2lMphO/fAOcUeBERERkNc586OjoYN26dapUk1XDOQjLhltni6RzAVsfbybboDZ5skbFRShe gWhsepNNtZI0HUDrry3OgGKNu7P7pojImmZN/Ualjya3TOIYuVHl5jfLhMeW7jqnixymauvr KS5Dhk0JtoWcKnoe6VSK1pbm+35+c5MqUEQe+rEDB87ivAxJfjdJ42P48QSemVqXJByGsVO4 tr3gBeASBU1ERERWHd8P6OjooL+vl7GxMRobG0mlUvd4nq8KNllxTGKZ6I/INQVYo35rsoaV rkK1H2w4vcmm2oiaDik283Q7maZ7SkRkIWPIqm33arnnTQXWOMKiodZtcMVliOMyfVwl2ERE lvtAGTTgMu2kS1cIbIlw3edIlS8R3E6wOQflG/h938C3Q7D+yXqiTURERGQV8TyPxsZGJiYm eP3119m1axfNzc2z2kQGQcDmzZvp6OhQdZusvHm71VJG8hAonIBo/M7RG5duI2ncr9jMc9wo jRqisqVloy67isg8xpEYTOSwq7GZVRVMzRHXzPRatreZ2BGVLa62tr4vjfQiIsvMBs2Y3HYy 9jWay+9Rbn0SM7wZPxrCsxEAQThAZmyEoKkR2g6Cr5ayIiIissouDjhHrVYjjmN6enoYGhoi n88TBDM3DjU2NvL888/T3t4+a7uIiCyTwvFZ7SGdn8VkukhyWxWb+ZzvG8f4rYTx6wm5z/qk sp4y9SIytzl0FZKyw7Y4PLf6bkCzkSOJXL2AYGodT+fAWldvHbnGKMEmIrLMTG4zYccXyA3+ OV1jf8BQ+y/img9ArRcv7MX3IJcyNAQOMu2w85chyCtwIiIisqr4nkdn53pefvll4jie3n5n pVoQBHR1dalFpKw41oJNnC6My9rmbD3BFs9UsNnMepLGveqisgBJzRFNOpLQYRJHXHa4UHER kftkHDbhrgqwVXV4cQ/PBEoJNhGRZeeT5LZQ2fo/0HjjN9jR/88wfgM2W8JLQ+CD71H/Hy8F 6SY1bxcREZFVx/N9WlvbaGrME8cxxpi7TryttWSzWQVLVhxrHFHF0NCmyyayRjkDxUsQFsDO rPttMl3E+X2Kz0LDax3VccvErYThEwlmWNl6EXlI5lCJw8SOhyXHppmiiMiDONik2qhu+OtE bZ8hN/QXBLVbUDhJOuwh8JOZE56oAD1fh60/oyo2ERERWXWSJGFgYIC+vj4qlQrW1tvCWGun k24HDhzgkUceUYtIWVnzdVOvPlEJm6xZzsDoe2Aqs/f9TCdJ46OKz4LjC1HFMnbJUDxqsN0K iYg8HKJRy+RARLWU0NiWxvfXdtGAEmwiIg+CF2BTbdigBbv5b+GZCudHvsnm2td5NH9p5nnJ JFz5d7Dh80qwiYiIyKrirGVoaIjjx97jxo0bABQKBdavX4+1lpGREXbv3s3jjz8+q22kiIgs xyCdwMg7kFRnNnlpTKYLo/XXFhBXZuXlnXG4msIiIg/JEPj/s3enMXYlWWLf/3GXt+bLfWUm 1yqy9qqurZeansb0CD0DWyMJGlmCYBgybNgwbECCDXmFoQ/+ahj2F41tCV61WCONRuORZiR5 arqnp/eu6iJrYRWruDPJ3Ne3v3tvRBx/eMlMZjG5M8lM8vyARLHyvXxLvLjx4sa550Qd0iue qz9r0juW4/BXeimUn+wQlAbYlFLqcTIBLj8JwFV7hfXVMXrdRcYqG1lsLoWVD2Dl5zD2bYh6 tM2UUkoptS8475mbm6NWq/Gtb32LOI756KOPeOGFFxgZGeHs2bNkWUa5XNYAm1JKPWrewvJP wW0F2HxuBFc4iAQFbZ/7JNLNgBVNflVP6zHgAN/d4hHR+d3TyH4mrI2mrHylw+SLPVC+3jme zPerO0krpdQekUqOkzMVPp4t3jg1AVuH6d+BzpI2klJKKaX2De8djUadAwcO8OKLL/Lss88y MTFBpVLhmWee4atf/Sq5XI61tbXN0pFKKaUexQCdQXsWmle6/97gCpPY4hFtnwdpWifYjmh1 WfX0SoXWgqd61RHZCLwG2e5rLLHgs/07kPiO4O3WxQbiBZt6XPbkDY4aYFNKqT3k9HyBTxYH kPBLmWrz70Lt85vq4yullFJK7V2GMIzI5/PEcUyhUKBQKLC+vo73nkqlQhzHrK2tYa19LK9Q RLDW4py7432ttTu+ThHBOUeWZVhrEU1bUErtda4Na6fAdbgxEuQKk7jiYW2fB/le8d2FcaWe 2uFlBqo/ccz9q5RcqwB6DdU983VoXXFUz1kCuz8LEEoKLpVumVyBVi3j8skqK2cS/PqTNVfW EpFKKbWHLDcjFnoPkZVHydV+sXVDex7m/ggqx6HyrDaUUkoppfa8MAjo7e3l2tVplpaWGBsb o1gsMjMzw/r6OiJCtVqlt7f3sQSlRIRms8nCwgLlcpnh4WGiaOdT5Ha7zdzcHGEYMjk5uXk/ 7z2NRoOlpSWazSZxHNPf38/g4CD5fF47gVJqb7ItWP75Rg23DSbE5Q/o/mtKqQfTguy0kAHG aW7Pfc1R56H5C0+rIAT7tA2lI6QNh8083gmNlZRLf9pg+bsJsvhkfV4aYFNKqT0m63mRZLCX uP4RRrbKdTDzz2H8z0D5CAQ6fCullFJqbwvCkLGxURbm5zh9+jSlUomRkRHOnDnD97//fUSE +fl5XnnllVsGtnbtpH8juHbmzBnee+893nrrLQYGBnZ8HWmacunSJd59910OHTrEyMgIURRt Bgg//PBDzp8/TxzHeO8pFou8/vrrHDt2jFwupx1BKbX3uBasvLexWVKXj/px+QP4qF/b52F9 1/jtMUy1nz43AbS04X3T4ksPzF8EEMw+7Ye+A+1VR305pVCO6DQcyYrDXdISkUoppXb7XCd/ gLTvLVzx4PYbGhdh9RfQmdNGUkoppdSeZ4xhaGiYr371q0xOTpLL5ZicnOS1116jXq+zvr7O a6+9xtTUFGEYPrq5lnOsrKzw0Ucf8e677/Lxxx+TpumOWXTOOZaXlzl58iQffPABzWZz835Z lnHhwgVOnz7Ns88+y6/+6q/yS7/0SwCcOnWKtbU1LReplNqDBGwT1j/eFv2xpaO4/IFH8wpk I4jxBA+RIt3t7VwHbrxuVu1xKbiOYJP9G9hQak+MgUvCyi8Szv+wyupMh3bd4jpP5qCvKRBK KbUH2eJh2sP/JpXpv739htl/DYNvQumgNpJSSiml9rxcLsfgwYOMjY0RxzFBEPDKK68wOTmJ 957BwUEqlQrGPLpFrFqtxsmTJzl37hw9PT0MDQ3t+PwiQqPR4IsvvqBWq3HgwAGCINi8rdVq ceHCBXp6enjppZcYHh7GWkuSJHzve99jZmaGoaGhR56dp5R6+ngv4MEEYII7jKdZDaqfdstE 3rD/mi0eeSQBtiwROlVHlghBaCj2BsTFgOBO11kIeA/GdN/nvbqelWQCc19/f1efgwNnpRu3 lO7+Q64jkGof3U/EdT9LpdQDHEd1aP/IsTjRYfK1FJcJ8oTuT6kzfaWU2osnSLlxkoFfpjz7 Dwns2tYN6x/Byvsw9FUojGlDKaWUUmpvz2mco9PpkCQJURRhrWVlZYWZmRkKhQI9PT2P9mRf BOccxWKRb37zm1hr+fGPf7xjgC1JEq5cucL8/DwvvvgiQRBsBtgAGo0G6+vrTE1N0dPTQxAE xHHM6OgoQRCwsLBAmqYaYFNK7fI4K9RXUlrVjN7RPKXemNtes5CuwdopbgyuAdjCUVx+YpfH YOhUHVd+llC76IhKhoETEaPPxVRGQ4Lw1i88S4XGoiOIoGc4JIzv/sIM8dCuOlprntJgQLE3 fOhBNvHQWLbU5h1JzYNsZOppoEYp9TR/R6WykbH85KYs60xfKaX2IAlyuOJhOiP/BqW5/2fr BteBuT+Cvpfh8F/RhlJKKaXUHp7QCLVajYsXL9BqtfjGN75BvV7nT/7kT5ibm6NQKHDixAne eecdBgcHH0kWmzGGvr4+3njjDcIwZHZ2dsfylNZaFhYWOHv2LFNTUxw6dIjp6ekb3ppsBg57 eno2H8MYQy6Xo1gs0mw2ybLsHptM8M7hjSFN07t6P2EYbgv8KaWeLt4JK1fbXPuwwbPf6qdU ibhthC1dg9VT2x8j6sUXJvHx7u6/Jk5ImkLtgmP5D7qRp/UXHOFfhdJAeNsstrTpmT+dEuYM ha8F9xRg816ozjsWPkw58FaOQk9w50y/e+SssHQ2Y+kTi8+EIDJ4280sfBwCDGA0e04p9dR+ N1rrcG73B2ENsCml1F79MoiHaI/+BsWF38P4DptXGFY/g8Xvw/BXoXxEG0oppZRSe5Lzntm5 Oc6dO8eJEyfw3nPx4kUWFxd55513CIKATz/9lJmZGfr6+h5Zplccx8RxjPf+lqUha7UaZ86c IY5jTpw4QRRFN93XWov3nnw+v+02YwxxHOOcw/t7O6mvVqusr1ZxhJw8efKO9y8Wixw+fJi+ vr5HWmZz38ynrZCljjAOiGINQqonkwikHUd1OqW+mDJ4oEC+GN4igOQhWYX1T7aP18WjuPwY mN0Zh70T0pbQWnOsnM9oXfP4RUFWoeOE+pynU3MEUUgYbb3uUGLirIdsY0+s5rzDBIb2854o b+4+yCaQ1j2Na572s55Ovfv3Uc4QRAbxYBMBA1HecD/DqbdCZ83TmfdEPYZk2RPEkC4J0nnE fcJD7PIYp+OeUuop1Bbq800unVtkbnGWF158blefTgNsSim1V0+UwiJZ+UWSwW+RX/3TjSAb YOuw/FOY/x488++BbryrlFJKqT3Ie8fq6gojIyO88MILiAizs7NMTU3x8ssvAzA3N0e1WsU5 t2dKKXY6Hc6dO8f8/Dxvv/02lUqFRqOBc44gCMiyjHw+TxiGhGGI937Hsjf3k1XWarWorq/h CTh9+vRt72uMYXBwkNHRUXp7ezXA9uX2wdCqZ1z7rM7w4RJDk0W0idSTe/IIzTnLxR/ViPIB B1+qkCvukA6W1aF5BZKl7b8uP4ePh3fttbVrnvlPUlbPWdY/drQ/8sjqxnfFCqx+ZMlXDJNv 5ukZ2irfWLHDDMw9y+p0RhgbbAvq5y1xT8Khb+TpG4/uqtSjbOyH1rrsmXs/oz7rKA0HjD6f ozwQkrY9S+cyghjGjucIc+ae36PLwHY29noTaH7saZ72uDmB1iPuDtINThqng55S6jF+NdXB tQVn5ctViXf7K5H2csLy5XmWmsu7/iXgM68AACAASURBVHwaYFNKqT28LCBRL63Jv0bc+JQw me3O1gHqZ2H+XRj7NvQc1aZSSiml1N47qRbBZpZisUgul2N1dZXl5WVeffVVSqUSrVZrM8tr r+zLICKsr6/zySefMD8/z9DQEIuLizQaDb744gviOGZqamozqy2Xy5EkybbX75yj3W7T399/ z0HDgYEBEsnhTch3vvOd288UjSGKIvr7+zW4tuOHaeg0LNdONimUIwYPFLSd1BPN1oWZf9Gi MhEzcbx8U4BNBGgvYmqf37QxmC0/j8vtToDNWaG95ln4IGP9fUc2LfhLN7yuVaj/yBHkYfhE THkw7F5CKoaiq1CeG2XtkqV3MsR1hNb7ngWfMXQ8oncsAt99Dr/5lmTjbNoQxGzLiEtnhcXP LSuDMPDNkL6piNJAiE2E5S8yooJh+Gh82wCb+G62mnPbn8tlgnfdvYbw4Fa2v8/HsZ6glFKP W7roSVuOMPfoMmoNhr4jPRx98znk2tyuz/80wKaUUnt5XSDIk/T/Mmnv2+RXv0tgaxtnQK3u xtQzfwAn/hMwoTaWUkoppfaUIAjpqVSYn5vl4sWLzM/Pk2UZ4+PjZFnGlStXWF5e5rnnntsz 2WvX9fX10W63mZmZwRhDq9Vibm6OMAyZnp5mcnKScrlMoVCgWq1irQXAe0+z2aTT6dDb20su l7un5y0Wi5TK4EzIwYMH724RwRgNHN1qLu3Btj3eizaGeir6ezYnJHWHTT0i3a3YvBeSpiNt O8zqMvmFJXIygjHdLDYJi9jiMSQaeCivw3vI2h7x3XKL1TnL1Z8lVD90pJ/IZubajdwM2JqQ dWQjEmiQLKQvGSWq51n60FK96Kh/5pFq974uFWzqaVc9y2czGgsepLvPG0BUNoy9GDN4JN5q owzc54IfB/v6Rpxx4yldAj4TXNb93U7xqawjtNYda1cstasOn3XLSuZ7A0rDAWlVyNYEnwjS 1j6plFKuKtTmUnLFENd+RPOxIhQqOYaGB+mt9+3602mATSml9vqJkglpHfi3iVpfEDQ/38pi a1yCa78HB38TSpPaUEoppZTaU8Iw5MCBAywvLfLd734X5xyvvfYao6OjzM3N8f777zM2Nsbk 5OR9lVPcDcYYhoaG+M53voNzbjMzbX19nXw+TxzHfPvb32ZoaAgRYWJigkuXLrG4uEgURaRp yvT0NEEQMD4+fn+BQ2O6mReB7p2jlLpHKbhEsJnHO8EYyBLHlY+rXPzTGmEr5LmhFzk4fJIw 7AbYXPEIPjeMBPFDeQm245k7nZK1hIlXc9TnHUs/sSQndw6uXeeT7j5oIhtZYqtFJudfIFor sP5DBw7ctY3H8N371BccF97tsPITSzaz8UAbmWyF5w3lkZCBQzu3k+8INhM265YJeNvNhtt2 Pu672c0IrM9YLv9Jh/VPHZ1zW0G0cBByU4ZsScguCyYCqWl3VEopd0m4/PtNghy0P3VI/RHN 6QODCXgk5cE1wKaUUvtA0v8OWe/rhMkcQba2cQaSdktFXv4H8OJ/iZaAUEoppdReYoxhZGSE b37zmxw7dowoijh48CB9fX10Oh3efPNNDhw4wPDw8GMNJl1/7utZYLlcjlwut63sYxAE9Pb2 Escx/f39FItFnHMcP36c2dlZ3nvvPY4cOUK73ebs2bM8++yzTExMPBFBMu8FlwlBaLaVWnsS iZetxXVNelP75Rh1gk1lM3Mra3vaNYuzbRAIIkNtPmXhTzuYNMfkN/rxg2XCjSIoac/L+Ojh XOHvrZC1hcaCo73oGTwa0Vn3ZMu3D651j7+N5LWNw893IgrNEsFagF360gG5EQzr1Dy1zx2d H928z5md6Gak3SobzXW6+7LdeKyLFcR1fyUObOJprXlsKhR6AprLjvWPHc0fe2T+hscC0tLG A7W0Tyql1Oa4WofWD+zmv59EGmBTSql9ojnx7xC1LpBb/9nWL9sLcOnvw7F/H/JD3NUOz0op pZRSj8j1jLDr+4QFQYC1lr6+PiqVCnEcP7byhsYYyuUyzz///I5BvhtfVy6X49ixY4RhuJmV FoYhExMTfP3rX+fs2bNcvnwZgOPHj/PCCy/Q29v7RJRu7NQti5da9I3l6RvLEwRPbpAt7TiW rrSJCxt9QYNsao8TLzTWUlYvdchWBKkKtfMZF35axbY8LhN6xmKWz3bI5h3GGtIkj9ywHJj1 vIqPeh/Ca4HmmmfpbEr1vCNZFOZGUmqXHW7+Pg8mMbd8rqwtmKCb+bZTUMutg+3IZqnMbX/f oRvN+9LLcim4rPs3ScOzeDZl+TNLsuapHA5pL3qSK7ItuLZJA2tKKbXzmF1/st+fBtiUUmqf sOXnSPq+QdieJkxmN76lLLRn4Ozfhhf+JsS92lBKKaWU2hO898zPz7OyvES7vX0zmuvZYYVC gRMnTjyWbC9jDIODg7z99ttEUXTbco7FYpHXXnsNY8y2fdUKhQLPPPMM4+PjdDodgiCgVCpR LBYJwydjj9x2w3LlF3UOvw29I3l4gq/nStqO2U8b9IzE9I/n9SBWe54I1BYTFj5qk573SB3W f5DRulzHN7t7gUXDAb4u2PMQjhpEghsCV4as8gryEDLYvBeaK46ZH2VUf+LwVSGZ9bhqd4+1 O7+ZbsDw+r/JAgIbgL85yCa2WwrT5bhlIFza3Sw36W6Thsgtn3azLW1LSFsenwntmmP+g4yl /8/iloS1CYdvg/1CI+9KKaW2aIBNKaX2y8lTkKcz/GvEzTOEydzWqUDWgEt/Dw7+Reh7EYKc NpZSSimlHv/cRTyNRoNLly6xvr6++XtrLc1mk9XVVY4cOcLk5OS2coyP9IQ4iujp6bnj/cIw pFwu73jb9bKR19/Dk5C1tu1z9EJSc7jNvYoe//vzTkg73Y2WcoWQILy/12QzT9p2xPmQKBcg HtKW39wHSqm9P85Cu+ZoTTv8tW6n9ReFzkW31c/Z+jdOEB8gEoMJsMWj+NwIEkQP79hcFbLP uiUb3bm7P5B8B9z1jDMEbECQheB3uLPbCJjd5uElEdKG0Kk5gtCQNoUbm0Lcxl5vWTdbzTaF 9rRn/qMMExjEC1ldsNPdjLX0kg4KSimldjif0CZQSqn9w5aPk/R/g6j5BVH70saZgYXWNFz5 bXjub0DxgDaUUkoppR67IAg5fPgwx599Bu+3VkittdRqNT7//HOazSalUumJCEo9aYG1vSzt OGY+69YbmnyxQqF870sbIlBbTpn9rM7oM2WGporasGofElzm8Z27DP5khjTN4VwfQpm08hV8 WOKhBc7vNwbVAp8IWXLDPmzCA5VplSos/8Jigu41qMunLG5x6wFdA2wiNNccM++nrH/oSM54 5l1GYSCgZ1y3X1BKKXVnGmBTSqn9dPoUFEkH3iFufkbUme5edgfdS++u/lMY/zOQG4BQFwiU Ukop9XgZYygWi/T39d6UoTYyMkKpVOKHP/whKysrjI+PP/ISkWr/cpmwPpvirGfs2TKUbzN/ FhAnOy7UJ03L0vkOlZEcSGHHv/X2hrJ1Su2V88Iv7Ssm/h6OHxvhfAGhSNb7JgSF+3oN3glp SzAGorwhbQtJTe4+2HerNwbd41VuH/QTL4g3t3zvsgrN97rny2EZ6u/7rb3TWuBagkuFrOVZ /8LS+ZlHViEdEZKapzSk30lKKaXuTANsSim1z9jScdL+d8hVf0HUurB1Q/0CzPwBlI9A5bg2 lFJKKaX2hJ3KPwZBQD6fxzlHrVbDOXfbPdCU+jJnPUnd4azcFGzY1v+ckCUe72THUpJ+4+93 Cgl4KyRNh3caYFN7R9ZxVJcSCj0RUS4gbXkku7u/9amhsV5mff05cuVp0t43kPsMsKUt4drJ hCCC4Wdj1q5Yrv0wpXOhWx7yQXgHWHPLIJtvQOOaJ+0VfPPWx6ebgc60J3fAII3t9/N1aC56 gshg692AHICvQWveE8aOdEUg1T6nlFLq1vQMRiml9hkxMWnlK3QGv025M43xN5xNXf1nMPwO FCchKmljKaWUUurxzVlE6HTaiHfbSkSKCGmacvnyZRYWFjhx4oRmr6n76GDdTLZb799nuhlo Dlwq+PvIQhPfzXDR/djU3hlXoVW3nPnuGmPPFxk+VKS5kt02yLTt7+uGudND5MtvUB67ii0e Re5zD2+XCusXLUFkqIxH1Occ1Z857KkHP2C8EyQLMH7nAJu7Jiz/scXkIf3iNs/X6gbjxN18 k70oLP4ko/2sJ1u9oXTkdPex1/od6WXZDLztt/FRKaXUo6EBNqWU2ods8SjpwLcorH6PqHXx hhOIazD/LvQ+BwOvsRc2oVdKKaXU08l7z9WrV7lw/jz1en3bbVmWUa1WOXDgAJOTk4RhqA2m HqqAgCxxiJXuWvMOC87it5fWE5GNjLYbytQptdfGVivUZlIKvSGFckRSdfjkLgNsGXSuxFSf 6aWVP0Rg4nt6bhGwHcE5IWl5bBuCUEgbHtuRu86ke1CyCunP5IEfI7ksBHmPrd3wWK3rj70/ BwARcE6IXf6WAUqllFIPjwbYlFJqPzIhWc/ztMd+k8rl/3H7ysDVfwb9r3TLREZlbSullFJK PZ7pCpDL5RkcHKRQ6JYgExGMMYRhyCuvvMLhw4cZHR3VDDb18InBpoK3t76LyzxZy29mqHkr JHW3Y7aLUnuJT4XFM22ayxkrpxP8vWRZZQabhbTiY5QluKdLMm0iLHye0lxypA2hfs5hDAT5 jM6yR9oP8qY2tmB7hHEt3wJbFXzjCRr6vNCpegYa44S1nB4sSim1yzTAppRS+5TLT9AZ/FVK C79L2Lq0dUO6Dtd+H3qOweSf04ZSSiml1GMRhCGTk5M8d+I43nucc1jbjXaEYUgulyOOY81e U7tHblNCUgRnBdvZWNWX7jVr3qIlIdWelXUc7VpG1vR0rnhWTiU0Tzn8tXvrtDYNqctR4o4h VwJzN9c4CKRtz+LpjMUfWHxbyM53nzdbyYgGDZLc/8EjCfh08/DsBtp2+Vj0dcGucdP+bPt7 3IOk4Sk3+wiq+v2qlFK7TQNsSim1bwW44mEaB/9j+r74r244+xBY+TnM/qtumcjSIW0qpZRS Sj0W14Nn6+vrLC4u0mg08N5TqVQYHR1leHhYA2zq8RFwidBczUjbTitCqj3NO2HpSovzP6pS P28RD3bd4y/eW8+VDJoLea5+XMAWHWPPBeRKwd0cLtiOkFSF5IzHLwAtoNTd58xXAHv/78/V IWt2g+LeAWmAkd0tcegXIG0LUnuChrWNiwWMDzBejxullNptGmBTSqn9fJIVVkgGvkln6NfI r/0pxne6N9gWzP8xVJ6B5/5TMLpwpZRSSqlHL0kSrl2d5oMPPmBxcZE4jhER0jRlYmKCr33t axw9epR8Pq+NpR6LdN0zc6rJ8JESYWQ0fU3tWSJQnU+Y/qMGrQ8cpgTSus9+fzVi6buewrBl 8EhErnQ3LwBsKriWdEtBth7yG3QgrptN6q0gWQC7HSBq3X8b7o9Oo3uwKaXUbtMAm1JK7Wcm xOXGaR78D4lanxN1rrG5aURzGmb/NQy8AWPf1rZSSiml1CMl3rO4uMjJDz4gn8/zne98h76+ PqCb0fbFF19w6tQpKpUKExMTug/bw2hz2drnzui66l21l0uE+owl7TiKPbpEoh4f72WzKIkJ dj6GvQfbkHsuCXlT368bXBVcKnddhlFko4Sq22m8B/OwY9OyRx9LKaWUuoHOHpVSar8vDAR5 0r63aI/+ecpzv02QLm2cfSWw9hFc+UfQ/xLkR7WxlFJKKfXIOO9YWFggjmO+9rWvMTU1RRR1 T0GttfT39/PjH/+YpaUlxsbGNMD2oHNCgeZ6Sn0lpXc4T6k3wgQaZbsjv/GjC/DqMUrbjtXZ DknTEoSGoYNFSr3xLg/SGwGzu8wSSxqe9WlLZ95DesMNLfBNsGuCZHtwbEy7e7uJ1X6mlFLq 4dMzGKWUegKIiWmP/xWyyqtIWL7hLGgZ5r8H1/6FrhoopZRS6pHy3tNsNunv72dwcJA4jgmC gCAIiOOYgYEBenp6aDabOOe0wR50PihCdSHh/I+q1JYSvO69o9Q+OXah07Jceq/KqX+8wif/ fJXaUoKznqzjcHZ3DmZJBNsUXCZ3rIwqAs0Vx9xPM1o/98jq9tvdJSH9RJD5PfhdtCJkVwSp al9Td3twdH+MLqEope6CBtiUUuoJYYvHaI/8BrZ4GEywNTNsX4PzfxfqF/SyPaWUUko9MsYE 5HI5ms0mrVYL5xwigojgnKPVatFsNgnDEKP1DB+cgHNC2nQ4q6uCD9yYSj3KHuchbXraS5bW vKXTcNRXU66dabA2n+Ddw++T0oa0KrSrHpvcvlSkOCFte9IVj7+6wx1a3BR02zNtOw/2vOzZ 16f2HtsW2mueyOZ3fx9ApdS+pwE2pZR6grRH/ixp31fxUd/WL10CtTNw7rcgXdcFA6WUUko9 EmEYMjo6Sq1W49SpU0xPT7OyssLKygpXrlzh5MmTtNttRkZGNktHKvW4iXT3pdIMQPW4+Exw qae1ljH9QZ2VK+3dCbDVoHHGMXcypbFkb9vnRcBnd19Ocs9pab9Sd3lcdKD1hefaD1Iq1QGM JtjfXgnC42DGH/yhzGD3R6n9Rs9ilFLqSZoMhmXaY3+JsDNDYfW7W2dAWQPO/a8w+edg+OsQ lrSxlFJKKbWrgiBgfHycl156iQ8//JBLly5RKBQQEdrtNlEU8cYbbzA+Pq77r6ldnCDDnerf iQjir/90M4m81Qibekxd1oGzgrNCp+poVS3eC4EB8fLwMmpakJwUVoYtIy/G9I4LhHfIJtbD Yn+MeerBjov3heyiJb9eBNEM+9vO9cYgPmywi2DnH6DzlSA6ZiDQjFO1/2iATSmlnjBp5TWS gW8Rtc4RtS9vzbJdAh/9Lfj6/wa9L2hDKaWUUmrXlUolXnnlFQYHB5mdnaVa7W6C09vby9TU FAcOHKBU0gt/1O7xmdBat6QdR1wI2akaabruWZ9JSPoctuVx9s57Uim1a+dz6561awnJgCNZ d6RNh0097Zpl/VqKazy8zimr4Jrc1T5sau8TC1lTsB3R/cMeRAt8C0CDa3diIghKBlN48A4X 9tMNsOW0XdX+ogE2pZR64mY4IZ3hXydKrhHO/J8Yn16fbsPaSZj+XTj270LpoLaVUkoppXZV EAQUi0WmpqYYGRkhy7LuiWgUEUURxhistcRxrI2ldkVWF5a/6ND4SkapN8Z8KUNHBJqfOs6/ W6PvaI7OqoOj2m7q4RPpZksCGGM2g72bGZQbt3WmHRf/ZZ2ewxHNWYs94Ulbjmuf1Ln6/SbZ FXk8r12z1/Y8tyI0ZzzFYY/RzCu1x5hBMH3gF9i5bGsAJjKYomgiptpXNMCmlFJP4sQ6P0Zn 8FeIWufIr3zvhhs6cOnvQd/LkB+BsKCNpZRSSqldk2UZ8/PzXLt2jXq9jnMOEcFsrCzncjmO Hz/OgQMHtEyk2hXeCu1lh038jhk64gV7zlMbyYh7AjavTVPqIRIv1FdTGispGEOxElHujwki Q6uasXS5TWvJgge3Kqz/IMN9XRALacvTrlvWZ1LqpzL8tUe79GxTob7oqM1YbE2Xvfd0P6uC rQm2LVraUO054WFDPGbotD1yi30RTQjxIUNmBX9V2+xOTAXCowa/yiP/blBbNMCmlFJP5Lds RNbzCu2hXyOqf0qYLmzd1rgIV/4RFMe6+7Fp2QOllFJK7QIRYWlpiZMf/IKrV6/S399PLpfb DK4Bm9ltorXJ9sMHuj9ft9/IvrnN9fBSB5+ASwVx2hfVw+eccO3TOqf/yRo+E4ZfLnDwzR5G jhZZvNji9O+u0ThniYe7FxpIQ/Btwaew+kXC9GCdtYsJbl4e+WGf1D1Xf54w889TktN6fCil 7kMvBHkwRTDxrbcKDHIQjBvsAuiGgndmRgzF4yHJtCfVANtjowE2pZR6Qvl4gLT/63SGf53y 7D9gc0dqcbDwPeg5AvkhqJzQxlJKKaXUQ+ecY3ZmhtXVVb75zW9y6NAhcrntG2sEQUBPT49m r+1x4gWbyp4qEScCLrnL1+S54zqdbwrJqsM2dYFK3Vs/BHbc22/7MQRZy1P7JCP90FM9mpHU HIXeiKztaV212HVPPLjxQG1I5jy+JWSLnqzhSZc9tB/1G4QsEVrznuS0IPP6mSul7lEAwQEI esBsTPeCo93929wM0ALT2y0PielmsRFqs90NE0FQNBjdt+6x0gCbUko9wVzhEO3Rv0Dc+IRc 7dTWDckyzPwLKB6Ao8OQG9TGUkoppdRDJd7TbLUYHx/nueeeY3h4WANp+/WzFMg6Dr+HsrvE Q1JzeHvn1+Q6Qpb4jUzJnSMhPhFsXfCJBtjU3R8XnYYlbVtKvTFxYacVYUPadtSWE5qrFul0 MybdvJA1Pd7eonRpHbJPu9FjmYCsKriOIPVdeCN3CEB7K6Q1gd0un+q6eaaa0KzU/mKCbqDH DIKs7nCHQAhHIOoLukNNBNGUIciBrwtmDHreCSlOGjoLgs90ELhJQQjGDbLCTd8DRotSPXZ6 dqOUUk/ySV+Qx/Y8T+vAX8PnRrYuFwKonoGrvweLP0A3m1BKKaXUQ5t/3JDSUS6XCYKALMvw vhvg+PKP2g8fKni39xa+XXZ3fcin0i3/6PWjVA+Pd56Va20uvl+jWc1uOj4MhsCH1FZSzv+k yuwvWtiVrTtlDU/WuXWnlPqXFlJ3qf/ammBvE1gWz10Fsh9Km6bgrfYtpfabaNgQP28wO127 HdBN8bnhGoQgBybfjQxFE4bRb0SMv50j16/Roh3H4V4hPmYwfdo+e7L/axMopdQTfuIX9dMZ /jWi+ieUFn6XwNbYvERx+adwsQ8qx6HvRXQ/NqWUUko9COcczUYDl6V02i3CMGR5eZmPP/6Y EydOUCqVCMOtFRazEYQrFovb9mZT6mES4aZA3ObvNMar7rdfeejULWtXOky93NPtVBvjmFhD XzJOsTnE6rU2s+83WflegixtdLg2pFVP0tzKwhTX/Xnk4/YqZC3BZUIUm8d2Sii2uw+iy2Tb daFKqT3OQFgC33OHuxkwBUM0YQgrBvHd/diCEhSHAkoDAUFem3PH8TEWgjKgpSD3JA2wKaXU U8BHfdSP/dfErQvkau9jXGvjhhQWfwhn/gd4+7e6syKllFJKqfuUJAkXLlygWVvh7OefMTFQ Yn5+jjNnzvDZZ58xMDCwbR+2QqHA66+/ztGjRzXAph7t/NgLtuO1kIN6ICLQqXpc5rlegFQE bCtgavEV+peH+PwP11n7IMN+vBXNlTqki57WmiWMDHhwq0JS8vh12fmJdus91ITqJUf9uCM6 aAjjxzgWy8Zb1cD3A/VJzdZVu64EpgCE3fHCBGACc9uDN+oxVE6EhG+GYAz1iw67KARFQ5Q3 BLE26y2Z2w+KJm8Ijhn8xXsfPE0FTJ9BUkEWn6Cx0F0fC3f/O00DbEop9XR8GyNhierx/46B M3+DuPHp1uWR6TosfB/O/S/w/N/UplJKKaXU/c84jCFfyBOGMaVSmdGxMY4cOQywuf/a9UCa iJDL5YgiPS1Vj544wWYeuWFfOV2UVvfekcAlHv+lvuNTQ8/aIMXpAWbOt5HqzYueriVkbQ/F 7tjo54Rkzt20v460IF0RfGt3ok5+BVZ/buk/llEZCx9vgE09+OfZ6ZbEVWo3BUMQHTT49t3+ AeQGDROvx/SORWQd4WqQkCx2B88wNgTB0zn2XC+rueP+dbf7u0p37zsCQ264m/3XXnI77tVp KtxyD0/TZ8i/EODWhXTxCZkItSGre7LOoylHr2cySin19Hxt44pHaBz8j+iZ/i3ixmdbZ4Xt Gbjwf8Dw12Hw7W5BbKWUUkqpe5TP5zl69BjFygBHnz3OW2+9RW+lh0KhsBlgu85aS61Wo1Kp aPaa2lXib1EKUtjc18o3uhlFRq+gV7fgnXQz1Tb6kveCXO9YOyzgGTGYjsFXb7O4d8NNt1r8 lKqQnvXIbgVNWpDNQHPBkzaFOC8EkY7J+3Ks64BrgW1pgE3tLlM2xGOGbOHOfU0CCEpCfjCg 2BdSGghJW56oZAhKBkmkm2T0FA47ZhyiKQMBZKcFWnf3d8GUIXciID8aEJcNzgBioAh86bvE VCB+PsA3BfvZDt9VJYgHAsQ9OVcZSR1cU7CpoBlsSimlHu6XjIlJBn6FqHmewDYIO9MbZ4cZ NC7CR38Lvvp3oefIxqUwSimllFJ3LwgCcrkcJggIg5CVlRUa9RrHjh2jUChsy15bX1/nzJkz TE1N0dvbq5lsavfmwBk4e/urmP1FIWk44sO6+ZP6Uv/Z6DaN9ZSrH9Vp1ywIjJ0o7Zz1KNLd jk3usKjn767yo9RB6rsbMPFzwsovLPm+DlNv5+kdizDB9b0K0ZKN+6m/Os3GVY9AuPFzN/JC +VXHkW/lKQ8G3T0WN4ZHY57e4cWMQ3y8ux8dHrK7bIngmCF3KODQnytx8K0eFs+3mf3JbSJz RcgfCsjWBHf1FhluT+DUR/zGBVaPgJ7BKKXUU8bH/bRH/wJhukhh6Q8IbLV7g0tg+adw9m/D C38TSlM8lZcQKaWUUur+T2ZFaDQaZJ0Wc7PXOHXqJAZoNBqUy+XNAJv3nqWlJU6dOsXAwMAj Kd/yVLS/14XV7f2x+19bF9K2u2PbyCLIVHdBRryg3VL7j00c7YYlDA2tdcvMR03WL6bgoNgf EeYM4rsBXDwQbCRGJgFBFoK/9fmUpNCpWlwa4B5zxpGsQuvnnqUBy+DxmMoYIJB1PJ11j291 s6OUUmpHgSEoCsGowXW2Z2L5kiM/LPRORMQ5c9tlJmMgyBnCPsEP3nvZxH3VZBWIxww48Mmd 7gxBwZA7YsgNGeLegMpEjrFnyyQNx2K5g73NhRgmNgSxTmp2iwbYlFLqKWTLz9Ie/fME2TL5 le9hJOueQbkOTP9j6H0ODv4m8eRwrgAAIABJREFUFMa0sZRSSil110SETqdD0q5z/uznZI0V RIS5uTkKhcL2k31jOHjwIBMTE4RhqI33MOZ4iSdraYQNwBDgreCdIFY2th++8+KSbwjNJUtj OdO2fNrHMy/UllPO/3SdKBcQ5QytJUv7qiMsG7wTQm/wVkjbHu+FALNZevROGWx2Tlj4WQcT Q3r18fc1aYJrb13x751QnbHMvpfSPufvunSZUuop+74NID9sKL4U0hh1VL/ncOe6t7mcpXOw Tm6oRBhyx2u4TWSoPGsoHwxY63W0f/Bwxx4zCORA5vdI20V3NTVByo7+N0KGD/SAQPVaShBC FAcMTBaYeDNj9r0WJme2Shd/6TNSu0cDbEop9ZQuOaR9bxGkywTJPLn6R1s3tefh4v8NxQkY +zMQV7S5lFJKKXVXgiCgv7+fYmWAl199nV96+xWiMOSZZ56hVCptzUSMIQxDyuUy/f39N+3P pu6Pt4JLRcu5AYEEpG2H79xbY/g5YflkAgKNy5b+w7o38dOs07Rc+2mTxkVLYSyks+Bon3EU nguxiScIuxls3t77QeevCbU/zKDYzZ583KQDPhV8CnhBPDQWHWsfONKPdVBRSt2CgdJEwMQb OVb6Mxqfedy57phh8yn1A3OUxg4ThHeukBQVYPC5mFzJkNUTsgXBXZGHk8lWguiYweQgrcnu XjRQAtN7b4E8U4BgcmMsvnrD2GwEV7GMfSXipbeG6TQs539UxQSGMDKMHisRxobatYzlXKr9 8THQAJtSSj2lJCiQDLxDkC0TpvOEycLWjSs/hyu/A/kRGHobAl1YUEoppdSdee8xxhBFOYZH Rnnrrbcpl4oMDAwQx/HNiwlma7HFOYf3njAMNeB2v/M7jazd2Lu6+67ZbtlMm3rSjicIPWFk btlSUofOJUe1kpLMu4cSrPS2+8kEocFoBfb9dlDhEqH5U0sTi8kZ/DVBjgo2EaLcRrbXfZYU lTpQ3yPvtQXpnLA+bamMhxQqAVlCt3ylZq8ppW4lgDBnyFcM+Z5ga/moBD7wZLk2QZ47Z68F EBUNhYoh1xNQHA1oP+Npt8Gt3jDAlrivMckUIOzrlks0BUF2cVwLDxmiMUiROwbZTARRBcIp QzQObhX8yta4K0aQoiVfCegZyBFGAYW+EAyYwJAvhpT6YvK9AfGEIQOiIYNPBL8K6HLertMA m1JKPcV8bpRk8NtEnWuUZv8+xt9QWP/qP4XCEOSHoHJCc8qVUkopdVsiQr1e59q1q9gsxTpH pVJhcKCboWZ2iCyICM45kiRhdXWVZrPJ1NQUPT092qDqobErwtyH3ZWqykiO0WNFSn23XnES B84+nOd2mWd1toP3wtBkkSinc+p9qd0Nht0YxBbpBtXECmnLbZZW3NfHymVh7rsZUd4w+WYe /MbeckopdTvmjvGzO/05hZ6AkZdiysMhUd4w8nKEeCGdtbiN+wUHwfQa/Nx9ZrUZYLe/hksQ 9EA0aMji7Zc+mXEw8VaGmgkNxTFD5WhIbcLRWfT49tZfmAnoNJukE2vkypOYwBDnA0af7VaF iHIGjCFfDpl8rYf2qqN2IWP0zQKdqmPlVEK2ohdf7TYNsCml1NO+4FA6RnP8rxI1TpNf/xmb l+n6FC7+PQhL8MJ/DvlhbSyllFJK3ZIxhiAIaDaadJo1Zq5eYXp6GoNQLBa3ZaaJCNZaWq0W q6urLC4uUqvVmJiY2DEQp9QDzXfPeWZ/r83yewl9L8YEf3mIqZfiR/PcmWf28wYuFXpH8hpg 20fuNiPNO7CJ4J+AAJu/Cs3M03jD4zJdlFVKbSh1M8BuDGqZALiLLXTFCDvljZsv/U+hN2C0 nCOIwBgYPZ4jbQjLvY7r61ThmCEaNaSp4Fb3cHsFGz83RF7MIMTHDCYPaSYQGkzQLa85/kpM lDMs1DNMsNVWQcXQlCp2dIF8z6sYA3EhZOxYGYAoF2AMFMoRB17oobmaEcRtjny9l/pSSnPW 4jvu9vN3jQ49MG1CpZR66hlc6Rj1Y/8t0af/AWG62K2jA5DV4PI/grAIL/03WipSKaWUUrdV Lpc5cvQIcaFIs9ngpz/5CWe/GKSnp4dSqUShUCAIAtI0pV6vU6/XSZKEiYkJnn/+ecbHxykW i9qQ6qGSOtiPBXfJEfcF2MTffelHAZt4WrWMOB9uLmbd9XMLpE2PTf0TkeH0NLGpo123uLva x+8J+mxTsK3ufo6iXVYpRbfkYTgC2afdzDETQlQxFMYCcv2G4mCA2WGPNQk8LsxuSm8LAsj3 GYoTAe2Z7vpTEBrCG659ifLd0pPbMs6CjYBQaLbG3etb/O7BUrYmb6DUfZ25VwzlFwJ8AniP q3XfTxAZcqWA0khA5ZmQqGwIip7Oex4icIHFRRnXq6cbA3F++8U6QWjIFQLiYkBxMKTYG5E0 LHEloO/l7n2r9eym1xe/EdD7ZkTcE5CuaLry/dIAm1JKKSSIyconWD/x39N/9r8gTJc2gmwC 7VmY/h2IK/D8f8aDJf4rpZRS6kkWBAGlUplcocTRZ47z+htvsLa6wvz8PK1WCxHZzGQrFouM j49z+PBhJiYmqFQqRJGeoqrd5TPBu7uLGojvBsjW5zvUFlLGT5QZPlQijO5jPqyBiv3VT5yw Otvh0k9qNL+w3b3SnrbjxGqAbd+e3+vnph6mEoT93X29so19J00Oek+EHPxajlw5IC4Ygsjc VH5RjMeH2U0XpkR5w9gLOfI9AZe/m+z8vDt81X555xIzDtGUwa0I/tLeajYTQTRBNxiYCgPv REy8HbN61mJrglzPEjYQFQyjz8UMHI5IG57ZkxnTcymS3cskwnRLSBaD7jzFQOVAzOGvVWgs Z3w2u4bpM0h94zOsQN9bMS/+W/00VjLqZ2va1++Tnr0opZQCDBKWSPu/RuPQX6fn6v9M2Jnd +B630DgPV34bigfg8F/V5lJKKaXUrWcVxmBMQLlU5sSJExQLeVqtFs1mkzRNCYKAXC5HqVSi VCqRz+cJw1BLQ6p7J9evCRNuXL0zGAIJN4sybN69DrYmpK1uNpnc4mJt6Qi+5RHXLWfaqTsW P29T6o8ZnCzeU4BNPHcd0FN7oEsJZEk3c219NmHlk4T03NN1Vb90No4t7bb7lwcj+p2qHqIY ggIEQwaPEFSg0B/QdyAiX+pGvbKOEATbs7ZuJQgNpf6QrCOEBXOb+3ULKpnBL5WnLEL4vCHs h9ykIQH8pb01aJkQon6DJIJvGPIDhp7RkPqsI8hD2Gs2A4ZBCKW+EPog7fWsTzuCErjqvTxh NzMwjLqPGwSGQl/IwIE8JoC4EpB/IaCTOmQRKEKuP6DvQL47jdIo0X3Tpts2kRIWl1e4PD3D erVGEAaMDg/xwolniOP4psB5rd7gwqVp5haWAGFibJRnjx2m0lO+6bGttZy9cJmZ2Xkyaxka GODokSlGhgb1RFIptVe+/pGwh/bInyXsXKO4+PuEyVz3JpdA9TM4/3egMA4j72i5SKWUUkrd YWphiOOYnp4eyuUyw8PDyMaKbTcIZ/RcSD3ICTxJ1VNdTOgbzZMrbm0EE7sivc0J1q8mZNXt C26+JbisW7KxtW5vuh3ALQvtCx6TYzPQ4K2QJX6zD9/lS6TTtDSXMgr9uvyyL7qVF6oLCVdO 1ajNZdjm0xllcm1wKaAVw/bfZ1cXkmVPmOqYox7SdK4A8bBh8LWI1qinPe3pfzWkbyrczJSC bpCoPBLS+2JAcsbjF+70wHe4OYDSUMjQVyNsNaPzk+54HMRQfjWg8kxA3GOwbVjpWOygbAvC 7Ym2C9m+T53pXg9UnArofzUgrcn27D5zw889CgJD71ieXCkkX47oHc1hQrM5Pwrzhvx4QHLB I4uy/Sl1Ov5AdLTdkGYZP33/FH/64/e4OjO3MRkWjDG89tLz/OZv/Bpjo8OEYYj3nvOXrvBH 3/sRH336+baj4PVXX+DXf/WXOXr4IIExiAira1X+8N0/4SfvncQ5v3nfZ44e5Fd/+Ru89ZWX Nzf7Vkqpx83nRmmP/2WCbI3Cyh8TZCvdG2wTlt+Dz/8niIrQ/xqEBW0wpZRSSt15gWGPBtOc cyRJQhAE5PP5ba9RRLDWkqYpzjmiKCKXy92UbeecI8sysiwjDEPiOCaKIg0ePgLNS5aZj5qM HC4RF8LuApFAIe1jZPEYl/5lg/TszREC8d3A19rlhPTyDrcvQrboid+4fp4uuAzSpsNtlM27 m49XXDdYs3iyw8FfKesHtseJgLNCcz1j8bM2acPjE4H209cWLhVc9ohLRFrwtnvcmEDHz/vS guycUG144lpeA6QPey4zvjFWzD99770wYZh4I6a16lkbskx+I8fQkZgw3jpWg9gwcDBi+NWY 1e87/MKDDSBhaOifjPBfFRpXHMlp1/0cYhh4KeTwL+fJ9wSsXbW0rjmyBUPWkT25F9v2jgT9 z0SMvhSzcDrFZw/nYaNcwOjREuKFKBdQqkQMTglhFHTnpIYd98lTD6HttQm6PvnsLP/wn/w+ l6avceLZYxyeOkCSppw+c5bf+t//IZWeMr/x699maHCA+cVl/tUf/4D/9w/f5dDBA7z64nNg DJ98+gW/8/v/GoC/+Gd/jYmxEWr1Bj/++Qf8nf/rt5kYH+X1l1+gUCxw8fJVvv+jn7O6VmVo oJ9njh7SD0EptWdk5edpj/0ljGuRX/sBgd3IS3ctmP1DyA/Cib8OfS9qkE0ppZRS+5JzjuXl Zc6dO8fY2BhHjhwhjmMAvPdUq1UuXbrEwsIC1lriOGZycpLDhw9TqVQwxpBlGQsLC1y4cIFa rUYul2N8fJwjR47Q29urQbZdZutCe83eVIIxsgXy9TLNDy3+2vbbJIWk7miuZbRXHLJ06wVA sYL7/9l78yC7svu+73POufe+fel970ZjH8xgH8zCmSFnockRJZKKRckWRSmkxFiJncQqpRzH UVVSSSmSlUSlsiuWZFU5jKXIVsqqkkhJJEVxlTjD2TCDGQyAwdLYe9/77e/ee07+uA8N9DS2 BtCNbuB8qlDo7nffXX7n3LN9z+/3qxv8iqY2HzJ5ukJzf5nmnjjxlINy5U2FNoMhqGtqU3aV e0PUp7pmZrjC5FCF0mgAghuHEdVXcvQ9mB5uugb1siGs3TiU6qq0yxVDUDd4rm077xQzBsGY QWA38t9LRDO4mwVoqC9sABHnXuJF4pmXkhgNtXZJMq9wE3JJTjQhotxqbkLcm3CDAhxPEEvL xTCSIgZekyDeIknkFF5K4KUETlrgtAqCuMFcp2xEZyTM3dc61PBec5MCJy5I5CSxnCQoNzYV iLs/vxe/6i6nHHCJNo5YVhcrsDX421ff4PylYZ5/5km++HM/RU9nB7VanfeOf8AX/8n/wFe/ +R0O7nuMluYmjhw9wQ9eeYOO9lb+xa/8l+zcthmAk2fO8Wu//tt89+9eY+vgAF0dbVweGePP v/5tqrU6//1/82X2PvYIMc/j0vAov/vv/pg3jxzlu3/3IyuwWSyWdUet6SMIXUXqMt7sqwjd 2LppQjj3R+DlYfOXILvThou0WCwWi8WyoQiCgKmpKd58803eeOMNXn75Zfr7ozmZMYZCocDh w4c5deoUXV1dZDIZpqenGRoaYv/+/ezbt49YLMbExAQ//OEPKZVKdHZ2UiqVeO211ygWi+zb t49Uynot3ZeFDu2iag56bvmikq4Z5i/V0aFh/mQdU7jxeXQRZk7WqC2ELHzgM/++T21e0/FY gr69adoGUreVj81YfW1DUK+EnD+8wNBfFSidDEhuVZjgBmXqQ1DVhIkHUMQoQ/WiZvytOjoE U1ubyxo/mmra98WyLvFAph9uE0gFmQ6Fl5LEszfZYLJK+rhwwW0TtB10ad3u4sTE4qWEhBtq yknwdoioLbvPTbabELRuc5GOwE1IWgZddGhwY6u3qcDu9VqDcac1QUQ+l+WF557ixWefoqez A4BYzGPnti0MbuplbHySSrVKGGpODp1jenaOn/zUxxfFNYAdWwd54uBe/uKb3+X00HleeO4p xiYmeff9E3zkiQPs270Lr7Ejsq+ni8f3P8aR90/w1pH3+dLnP4fjKFsQFotlHSGotryAMHVE MI+7cARxZYZpQjj9e1G22cFfgMxWmxHVYrFYLBbLbaG1JgxDhBDLwi2uBbVajUuXLnHkyBEO Hz7M/Pw8Wl/NraW1ZmJigtOnT7Njxw72799PPB5nYWGBV199laNHj9LX10dLSwsnT55kcnKS F198kf7+fmq1GocPH+bYsWN0d3czMDBg0wGsMcaACj1Uzb1uaD9Thcp0SG1BU3onvHldPWuY /lad2bRPcFlDBYbPhRQu+KRaXFp6k7clsFk2SttkKM8EFI8GBJc1YZdE16+/89/4hqBm0Dfw DDAGMBu3btTfNUzNhcQGBLq0xu+wrYqW9bpCIgVGP7w1VCpBqkWRaonyfd0P4cZtEjRtcmjq cVBeVB4CFnObXbfc4qCyAl0296neXPkB3Jgk1RwJg0IJcl1q0baWjYtdDW3wpc//1HUGRIYg DKlWaiTicZRSzBcKjE9MEfNctg4OLPvOts2bcB2HsckpxsYnGZuYolKtsufRHUixdGLV3dlB W0szE5PTTM3M0NneZgvCYrGstyEU1eaXwBgy534Tp3zu6pQnrMHJfxWNFrb+MiR7WbWtShaL xWKxWDYkWmtKpRL1ep10Oo0xhsnJSSYmJvA8j66uLnK5HEqtzWZDYwwLCwu8//77VKtVDhw4 wOnTp5eJfFJKduzYwfbt2xfvTylFd3c3Z86coVQqEYvFuHjxIm1tbfT29pJOp0kmk2zdupXj x48zPDxMT08PnvfwefoHvqayEKAcQTzjINcwn5LR4AQeIpDX9U4zZahOhAjJTcNDXiE8ZQiv WfIPLxnq2zRhYN1sHjhMJIyZIMq7Vr2gMVVzQy9Ho80N1SATCES4cedGZgaCqsHUQY9aycti sVwZHwnEfdg3JCQkDkryOxXxrES6kcBnhMBNSnKbHepzPtX3ovZrCR7RUtUaN8lCCeI9gtRm KJ3ViyEir92YI+wmnQcCK7DdhHKlwiuvH+aDM2f58s//DG2tLczNzVMoFkkmEjQ15ZZ9p6Up TyIRZ2GhyOWRcaZn5nAch4621mVKeiadIpfNMDE1w8SkFdgsFss6nVxJj1rTc0BA7tS/QPpz 16yeVOD0v41mojt/BWK2HbNYLBaLxXJlEGEoFoucuHiBYrHIoUOHKJVKfP/73+fChQskEgl2 7drFU089RT6fXxNPNiEEnuexc+dOMpkMCwsLTExMLLm2lJKenh7a29uJNzZaGmOo1+vMzs6S SCTwPI9SqUSpVKKnp4dYLIYQAikl2WwWz/OYmZmhXq+vXGAzBoMhDMPbep4r/9ZRsVNZCDj7 1hzpZpe+3dklOUHu/QU/lAfLgAwdxI1yZ80bim8FCIebhoe84eUKoOsNzyVjhYcHtvkqgP+2 vuN3wPgCGQoIN7ARyhAes3XcYnloSUbeX+5mcd+zgghX0HzIYeCZGOk2xZXgAFJCulXR90SM sGaY/zvNevGDlXFoftQh168YzdStmLbW/XgjT6rRq78hygpsN6BYKvPam0f4rX/1Bzz2yHZ+ 6ic+SWdbK2fOXcD3AxzHIXadiVIs5uEohe/7lCtlavU6UkoSifgyX1XXdXFdlzAMqVSr1ugW i2Xdop0UtfwzLGz5n8me/p+QYbExaDFQn4HzfxxtKdr530W52SwWi8Visdjxg9aMjIzw/vvv s2XLFsIw5OzZs1y+fJknnngCx3E4efIk/f39ZLPZNfNiy2Qyi7nR6vX6ss+FEMTjceLx+OLf arUaFy9e5MyZM2zZsoXm5mbGx8fxfZ9EIrEocF0Je5lIJKjVagRBsKJ7q1QqlIoFtFBcuHDh lsd7nkdzczOJRGJdlX0YaIqTPsqVq5tPSYNf0vjVKMTnYjnc5CumAGHh7hbfglmDX9FWX3uI MSFo3xAGBhMurwjGRPXTYrE8AGSi/F8PE6IZVK/AhOB2CKQn7lvAIiGi5SYvLYjnFI639EYc TxDPStyUQKyj7EtCgJsUJHISJyXuay40qQReVmIMeP2SWvH6uz9EBtSgQCYFwWWDvrxxBzpB KWRucoG5wvzSjVirUdbG2CHhh5mYmubbP3iV//Cnf4HnuvzqP/4SB/c+RiIR54PTZ/md3/sK 0zOz/PN/+ssc2r97yXdfe+sIv/E7v09vdwef+/TLvP3ecf7f//RV/vf/5Z/z0kefRl0Tf/+D 02f5g3//Jxw9cYovf+Gn+U9f/eZd3ffk1BTvn/iAXDbDzm1b1tUuxo3C5NQMFy4P093ZTncj F59lZYxPTDE8OkZ3ZwedHdabaSVMTc8yMjZOJp1mcKB3/Q2wTIhn5tkRe4d/9vwITYng6gBB OFScHt5Z2Mu/faOHUu3+jGrGJia5NDxKS3MTmwf6bKW6A0bHJ7g0PEpHeysDvT3WIHfA8Ng4 l4ZH6e3qpLe70xpkJYPgIOCVN96mq6ONvp4uEtcsbltuj1q9xiuvv01fTxf9PV3EYjFrlBVS rlR4/fC79Pd00dfbhed61igrpFAs8vZ7x+jpbCfpSfx6jbaObqSUjA1fRIch3f2DUd89fIFU OktLWydSre34wRhDqbjAyMVzNLW00dzWeV2RLwwDioUFJseGUUrR3tVHIpmiuDDHyKVztLZ3 09zavnj/9VqVyxeGUMqhq3cAL3brtkxrzfTEGMfefZNaYJCOe1v9cCyeoK2zh0QyhYPLwMRB Wi8PMLz5BGO5k4SyfrcjQNqKgwycOUChdZILne9QdQrcbHe4QNBU7qf/4h7KmXkudhyh6izc y1Ep6Vorg5cO0nysF7+5xqVd7zPS/D6h8KnMhgx8sJ9tl/fjlVenHzFJzdTBi5zpf7Vhj+vj aI/eqb30vb2b+S1jDA28RsmbWffv8MzsHBeHR3GU4rFHtj8kLZcgW+1g89knyR9rR5RvHgPN JDTV/iJhzMebTzI9eJkLPYepOAso7dJ+dheb3t1NvJS0ScVu971yDOXN8wxteYuKO8/gB4/T OtSLDJU1juV+LoQQpkOEEehEJEo4U96Nw8M6BqRB+HJDv/smpgmzASIQBMmAWr7ImU1vMJE8 gxY3ds11dYLtEx+h991HUQsOxeQchwe/xdTgEIlE7EOtrqSjtI2t555govMcZ1peQ4tg2TEt 1X52nH2WerzCqd5XmPfGl41D4mGGR0Y+Rsd7W5AltaxMgtYaIpAgwAiDO+WBXqV1cwE6E1Bt rTDTfYnp7CV6xnahpeZU7w9Z8CZuMo4SJIM8W8efpPvEdmRMMRaeJ/jCZb78T36cLZv7V16W 2jAzWmX8TAm/qpn4oMLlb5SpvBPS9cUEj/9CG3MjNd7+N9PULmk6Xo6T6nAY+1GFhb/y78jb f12wK6B46Ayn+BY/+4Wf4bnnnlu1ubH1YPsQQ+cv8pd//T3+9tU36Ons4POf+zSHDuxZnFjH YzE818UPQqq12rLvV6vRLsWY55FJp0jEY2itqZQry8JH1Os+tVodRylSqSSed3fbIRzHiZoe IfFcxwpsd2JDJREIHKnwXPt63AlKSUCglLQ2XHH9U41dz2Kd2s5BiDamUy/yevECz3iHyTgF BAZMgFO9SEdlikPpzbzJx/BN1Cat6R06DkLIqP55rq1Ud2zDaPe9teFdvMsIHMfacMVzkUaO HiklrutY+90BuuEqopTC9VxrwzvAD3zEFRu61oZ3gus25iVKIqUgkUiQSCaoV6sEfo18cyvJ ZJIwjCKDKCVxPQel1nb8Y4yh7joopXBcB+9D92CMIQwCiqUCs5NjxGIx2jt7SGUyCCHxYzFc 10M5EtdzF8U5o0OkEI12zLutOqS1xnUdYvEEjvAQjkdnz603CymlSKaSeK6LxEW6EuEIlCvx PIdQ3u3qnkC5CuGAdASu56Adl5sKbEYSU3Ec4y6WbfSde7dy5RqFcAVIkFriSQ/PdQkl+E4j eMxqDkMlSCXxXA/t3vjZlHZRrkTIKM+K422Mvs1xo7x5UoqHqA0UOFpFIbxuI7+QqEniw2mM AhMPka6I2hHXRWkHqYTNTn2H75ZyJI6jbqscLJZVHysAOh4gdaNOmps2I5ikRsc0zoyADZyH EQHG1Ygrz62Ixhaug77JerOrnagdvfYQKXCVs2ydSxgZ9ZFKIB3ROPfyGzHGj+5FCRz3ynrt 0oJwpUKom3jZSRbbFCFXf6nKSCKhVQmUI6NxlLjx/S8Z4wiFbISTNHUTnesu59j5jjiZFo/Q NyRzBWZP1qmdW+5m7bYJug8maRmIU5kOWPiuDxtUYPNaHLq2tFIor/6mZ7v6fQ1nL1ziz/7q b/jRm+8wONDH5z7zMk8e3LtEqMplM2TSKSqVCjMzc8vOMTk9Q6VSJZtJ09XZTnNTnjAMGZ2Y XBY+YqFQYH6hQCIR55HtW/jHv/j5u7r/1956h2MnPqCvp5Nf+Ac/iZR2l89K+dGb7zAxNcOh A3v4xAvPWoPcAd9/5XXm5gs8dXAfL370aWuQFfDm2+/xze/9HVsHB/jZv/8T63qIGXfmqalv k1r4Bqo2ChhcZdjUXOXn8lM8LqsEff8Q3CxrKbJ9/5U3+No3vsPBfY/yc5/7jK1Ud8B3/vZH /PnXv83Tj+/jpz79SWuQO+Cb3/075he+w3NPP86P/73nrUFWQKkc5b/dvWs7n/2xj9PZ3mqN skKmZ+b4/g9fZ8+jO/jJT32c1uYma5QVMjw6zo/efIf9e3bx2U99nHw2Y42yQobOX+Ttd49z YO9j7Nrcy+zMNIODm5mZmeZMa4qPfOQZ2js6GB0Z4Z13kuzevYdt23c0Ngyu4YjGGEZHR/jR q6+wbdt2dj6yazFfmjGGSqXC+XNnOXnyA/KP7+aRR3bR2taG4zgYY5icnOBHr75CV1c3e/ft JxaLYYxhbnaW73z7b+itWT5WAAAgAElEQVTu7ubAwceJ30b4xiAIOHH8OH8pA+arGiNdfu2f /dNbL5pck4PNaJg95jD7huTRFw+S6d93T0IllcclY99ySG/P8fG9m1Bxc6uhIqVRycQPHFKb m3hp7yac+L3dxl8vCCZfc5iZVHhZydMvP0bz7p1IB46+N8Tp6RpiRkBpdeqObJFse6aHZz/2 aby0IawLtA9OwiyxuQ5g/pRiZMph2/NdPPvRT+Gm1r9LwztHj/PnX/82yUTirtcpNhK1ecHY d1wWxiW6eIuDNYiijDZkbJXs+cQmXjzYh5MwmBDe/uoU4UkBZawH220i0oKm3Sn6P74X6Wku 1yQMsbHz2Fk2PhKcfoUKFSLeCA87B1zPQdwFZ0Ag8pLwqIC5DfzYzYL4oIupCOID0DSQYuuB g7j5PSBu3KiZQFA6kaEwptDlyCb5vgwf+7EX6PlwdBcD9ekYC9/L0L93G89t7YbrbAwKSw7z 38sjk5rHnvgYKr08/Lb2JYW3spRGJKa4vG2JD7qYarSBQigIiwKKq2C4NMjtGrffkG736N7S jdPaRvndFCjDY08+j0rdPHy4rilKR9MUJxWmCKJ+97elHIFyFKGjSeYdmnfG8As6GrM0luyc jCA26JBqcfGSCukKhCcwG7QTU3FFU76JrGhZdSckK7A1mJ2b5+t/8wNee+sI2zdv4ud++rM8 9si2ZcdlMyk621vxg4Ch8xfRxiAbhaS15vTQebTWdLa30d7aQkdbC+lUkqPHTxKEYbQLB9DG cHl0nOmZOTYP9tHf082WTf139QzzCwWkVDTlchzav2fNchg8SExMTeN5Lv29XTxxYI81yB1w 4dIw8ZjHQH+PteEKmZmbI/1Gks72tg1hO1PpozoM8clvoGojUQdGSJOa5KnU96D7Sej9LMRa WSuRbXR8klQqSV9PN88+9bitVHfAxcsjpJIJBvp6rA3vkDPnLpKIx9myqd/a8A7GMkoqujra eHz/bjb12TClK2VkbAKAnq4ODu3fQ0+XDXm94nf47AWEEPR0d/DEgT20t7ZYo6yQTDqFlJJN vT184qXnOfLO20xMjFOvVvnkx1/k2WefZXZ2lotnT3PowD5efPFFurq6kHJt3RW01ly40Mrk 6GX2PvYIBw8eWMy7VqlUOHr0KH61xPPPPcOBAwdob29fIgLOzc1RL0fbeg/s2UU+H22uHBoa 4tSJTp5++kkOHTqE697aA8j3fTypOfzWG8j5KhrFx555cmXPExrOyFlOjc2zZ28rXdvTKOfu x2BTl8q8dXKC7kdS7HiimVjy5vNMY2DyfIkjF6bo2pVk+218Z6WU5nyOTk9SyM8hXMHWHV3s fLIZx5WEPlxMn0asYnRXGRN0DTRz4EA7qZzL6OkSc6M1Nu/OkcxeLe8w0JyLzTPdMk7v5gz7 D7aTyq9/j7C67/ODV94gk04/VGOZwnSdN8+NU0wvoFewoOg1K7Y80sYjT7QQTzmEgWH0yJsM WwfoFSHikOtOsG1bE0HNMG1mCI11Y7PcZyS4OYUyCpkQmMBQdcz1BTYHnLzC7RD4oSEYNehz G/SxU4JYiwsh9H4iQcdjHtmuHrz4zXOxhb7hYljjeLZC3TEICenmBLsf2cHWLQPLxgvzowEf nKnQu7OZnj2xyLvsQ1QXNMfOlnHTgm37uklklx8U1Axn5iqcTtcIPtR+izjEWlx02UQCmyOo enpVZCPVBT2fi9N1wMVLSWIZidGGcws1hILte7uJZ2/ertUrmgvVGqdy1Wh/wdy9W0+TUpDv jLPt+RwIqM6GSBmVaWaTS/9H0nRsTeJXwyhywaCgXjeYiY1Xh+sXNCOvVRiXFcxTq3stK7AR 7U587fC7fPM7P6A5n+fjzz9DW2sz45PTS47LZdPEPI/tWwdpbWnm8JH3OXn6LH09XYDh/MVh Dr/7Pp2dbWzbsgnPc+nsaGPPYzt58+2jHD1+kq2D/biuy9jEJO+8e4zQaA7ue6wRRsVisVg2 DkFikFLX50EHJKa+jqxPNhrVAIpn4dhvgvSg68cgvnYim8VisVgslvWBEIJ8Ps/BgweZmpoi Ho/T19dHLpejXC7z6KOP0tPTQ1tb25qLazcjDENGRkZ49dVXUUrR19eHEILZ2dlo8UQpUqkU yWSSTZs2cfjwYc6dO8fg4CDVapWTJ0+SyWTo7u62mx4f6IWE6J8ODPOjNcZPlOl9NE0i43K9 jdJ+RRP6GmPAZnNYh8VporUh6222Dtpg31Ca1JgRBxHYl8Vyj0gSeZTebNzS3GgPbpIqU0iB iBvMTc4lHHDbBaYO+pzZkLYSCYH0Io+9VIci1+3gxIRd1rnV2DchyPQqWre4OJ4AISjPhiBY 4i123+5PChJZh5a+BKPtZcKaxo0rpBTEmxStmxJkW2PMjVVxk5LEJkU4bQgmNl49Dk8ZSnM+ 89vqq34tq+oAfhDw1W98m/MXh2lpbuLEqTOcOHVm2XGffOE5Bgd62bd7F888cYA//do3+Nd/ 8If8+CeexxjD177xHcbGp/jCP/gsex/dAUBvdyefffkl3j5yjP/z3/w7fvLHPk4mneSV19/m rSPvs3/PI7z0nA2jZ7FYNiZBaiflrs8DmsTE15DB/NUVh+JZeP/XAQk9nwKvCTsas1gsFovl 4UEbw8zMDNVKmW3btpHP5/E8DyEEXV1dtLe347rumoeGXFxkEAIpJalUajEHKUTeZBcuXGBo aAghBOVyeTF0JEBrayvPPvssfX19bNmyhbGxMd58803Onz9PpVKhUCiwf/9+2tvb15Vw+KBi QrMs3/majYV9w9x4jdlLNaqzIX5VcyMFLfQNOrTqzbqsQwaqxYCZy1VK4z6mam1yX/uOEPyS hrKdO64qtyE4PUjPqvoFhIbw9E2OGRAIF/z3zQ1to9Lg7RX4Zwz60tLvi3hjfNHIWbZRUf2C 3HOKVI+kcC5EKpBq5ZtDRBy01Bih19XzCQF4q/QONGwlHbGYRw0R1QkvI6/robfWSCmiPKEy uk/VyJknZBRKUipBLKXoeCRBUNNUzobLvAI3TP8+AXrz6l/HCmxAqVhmdnaeQrHE93/4Ot// 4evXPa6/t4fe7k4621v5qU9/EikE/8+f/Bl/+a3vAdDZ3sovfeGn+czLL9HWCCWTzaT52Eee 5Nd+9b/it3/3K/yPv/7bBGFIcz7HZ15+ic9/7tMM2PBHFotlA+NnHqMkvggIkmP/EaH9qx8W TsOx34h0td6/D07SGsxisVgsloeEMAwZHh5mZPgyHR0duK67KDhdK1jdT3K5HIcOHSKfzy96 m0kp6e3t5XOf+xxaL18USiaTpNNppJQ0NTXxzDPPcOHCBebm5sjn8+zfv5/+/n4St5F7zXKP 6lpgMPdh/a5aDDj/+gJDf1Ygt8tFh1GmkmVrkBqwzlHrFqMNMyMV3v/aDGNfr6JHbUnd3wIh ep8Da4rVQjSDbBeEF81DIbKJLLj9YGqCcPjGz+w0g3AFwU081NxWQaxNsFDS6EtX2wpna9Ty LxNQGsLbzbzi1hVJ8DYJuj7ikutVnK/W7tzuKQh8Hy3DNX8GESfaLHGdcpRxcDcLgksmyhN3 l+8S3Lp8hbwzkXJtXpAP/Sog3eSx5Yk8QsL4K1VqaCw3xgpsQD6f5Sv/128Rhjd/4ePx2OLu yp6uTn75iz/LF37ms0xMToMQdLS3kkokcD4U7jGdTvLpl1/i773wDGMT04QNgS2bTeO5Nii3 xWLZ+ASp7ZR7fgGA1MgfLv2wcBKO/x8Q1mHw50Hads9isVgslocBKQSpVIowDBkbGyOdThOP x5eFTXQc5754sQkhyOVyZDKZRW82iMS/LVu2sHnzjbe8KqUWv9Pa2kpTUxO+7yOEwHGcxc8t q4/xG+EXA40bW7ut4WHdUF0ImLtUp3IiJLM9EtisirZxCANDGGh0aKjMBxQv+/gXNKZgbWN5 wPvndoG3WVAr3b3AsGGe2RW39iIWgCTybgIQBpMPUU0CVRXIFMSaJcY3iGuHLUlw2ht90rVL yxJkCzh9Av+swYw1TtsJskWgR826E95UD8S6BLGMwI3LKKzhneKACTRmDTtGmQRnh0AmiHLg jYPTL4h1CowvCOuRgOS2QzgDd9Npi+bIm1FlBPVLhuCkucF4E9yEaITYXMdjQ8Gi2CaVwI0r nJhcWtcBkcH2k8urukUIQTIRX9kLKwWxmIfnuWTSaRDg3GASJYTAdR1cN00iHscASkobLsRi sTxADakkSGyh3P0FhAlIjv6Ha1Y9NCx8AKd/F7QPW37RimwWi8VisTwk86x4PEahUOCv//qv OXPmDPl8Htd1F+dNnuexdetWurq67sv8SAhx3TxpK8mddkVUu1+hLi1RHrS19GDTc4bpEzWE WGD2RA09ZwgrGr+q71e0SssKCYPIa232cpXA14wdr1C5GELF2sbyEPTPXiREiLi1xfI+/Zq2 3tWUN83R/kQaMRIj1iLo2OcyfyFk7q2lThqiEQ7QfEjEk00Ct10QThrChsCm2gXegCDIEf39 9Dp59mZIHZL0vuiR63Hui2f43eK0RGE+hQJdARGDlhcUXU96SAeKY5qJt3zCEncdxlPkIH9I 0bzTYeZEwFQlxGkGFVuqDXgJSdsjUU425a7POh/POGS7PRxP3jSzi9wscNoF/lmNmbDtxWK9 sya4+wmZ696+Ge2ky2KxPKgY6REkt1Lq+c8Rpk584i8QuhFOQNdh/jic/b8BDVt+CaRnjWax WCwWy4M8NsCgtSGTyVCtVhkeHmZ8fHyJkJZOp+no6KCzs9MazHJv6p25Zgv2al1jAma+XWf+ bZ9gwkAFgrKhXg0b+eCs9+J6R4eGuZEaJ/96jqBmmH/fp/JOeI925VtPRssG5mHKzXbtM1+v nXA0lfw8qf44JpSkOiUtgy5+yUQiTnMUhlDEQbiAjoQdhABlELHoPMIDlGCxYVAgE+B1Cepw 07CVa4nIQWarom2nS7pVUZoOG8+zcYpSuKCSoBtlIfOQHVS073Bx45LptM/M8QBf3n0jLWKC VJeidbtLUDHM5kOcvEDFxBKh1okLmnocEJFn2HpDuZKOLUmae+Ikc+5NIzA47YJ4vyKcMYQT tqNbtIs1gcVisVju2WKDjBEkt1Ps+SWMMcSn/wYZLEQfhhWYOwpDX4kWHrZ+2YpsFovFYrE8 wEipGBgYYOuWzYvh+E3DvefK5F1KuZjPzGK567GoifZ1ufUYhKtbp8JThrCxWCoyEBQN9bL1 YNtIlSX0NcXLAdo31Efv3W58v6oJihIZWKHVss64RUp0tQ3wBOG5RkNWvuY7D4LoJhq5ucpL baL6xQ29mYzUyJgm0S1JNEscTyAUqJQg9XFBMG1AQfZRiXQFftEQlAxOQpIaiAL66BCqp5en JRJOQ5i7UTmV165eiHh0P05K4MYFUgmUK0h3KbyUZKNEvXbzgmSvxC8a6hdD0CCd6FkcTxBL SdL9krBqqJ69yw5bRSKecgXSFbidgvR2RSy1VGAT4qqH4/ocrwtSORdy0c3erKyFAhljWdjI hx1rDovFYrHc27mq9PAzuyn1fAmA+Mz3kH4jsHhYgfmjMPQHoGLQ/zPgprG7fC0Wi8ViefAQ QpBIJMikU1SrVcrlMr7vk0qlcBwHrTXxeBzHcWy+Mss9QYeG2qwgNd2MKqg1vbbxza3z+1jW x3yl4WBmgLBqCOYNpmru2bkXpupUTzuoeQna2ttyG/1lwxNqtQUV2QEiKRAeCAl4AtHcyAOW BKdbIFMCX0VeV8FZg+yKBKXgjNnwIptMCJzNEHA195mIg9tP9K7eYF+G8gzd+2IoB0TDAynW Lmh73GXhfIgQ0PdRj3hGUpwMGX3TJzeoaNkaqWczQz7FoyHBbd6n6gGZE/jH18DmjZxlQoEu NuoF0QpNLC3pOeDhJuTic6/vcSek+iW9H/FYGA4pntKEc2bp5y2S3idiCFmn+F79ruwmvKXX zuyQ9D3rket2NoS9lthO2nH43WAFNovFYrGsRveMn91P2QTRwGzmB0h/KvoorEbhIk/8dpSL rftTEGvBimwWi8VisTx4BEHA5OQkH3zwAUNDQwghOHToEI7jMDIywuDgIL29vXie9Wq33D3G GIKywFtIICpr5xVpCpHnXOhrwtAgQ2MXqxbLJCoXcYtd8WtyL9pQLYVUiwH1Skhx0sef1dSG NHrU3LtrFAOCUbmmddCygUmCs1VgqqsvYjkdAqdFoGsGmRDENoGfAH+mUf9lwyOnCWRKEE4b nPbIyyq8/CHPrw2ISgId0XNdEdgg8i4SDpHqfh1RXChItyoE4NcjW6mEINOpqBcNQkCuyyGR k0hHMJ0NSLZK8o2wgJW5EBG7JkTkLeqDbBI4HYLgsll1m4s4OC2RDQIMQl3NQ+d4gnSbE63U bIQuTYCbEWQ6FH7VoNKgS9fcu4jyoWXaIdEsUVkByTt752QLuB1iUZBEgJeTZDoUsQ3k8bei Z+4VqLTYcOLhWmAFNovFYrGsGvXcIa7sD43NfP+qJ5v2YeEDeP83opFI1ych3oYV2SwWi8Vi eXAwxjA3N8eJ48e4dOkSSinm5+cpFotkMhmGhoYYGxvjhRdeoLOz04aJtNyjigeYtR9T+hOa yZNVUs0LxNMO+c4Y8ZTzkLcBUFnwWZiqk252SeZc5H0UHsPAMHGuxNkfLVCZCSlc9KkNacJT 987z0GiDX9WYun0VLbeHiIPTLNAVQxhfXRFLpiC/X5HqkrhJQWlCM/VaEHlKLTmwkUuM6P8o vN0D4KEruG4oSJWG5n0OQsLse9fxMxNmuWAiGqH/aAhSIvICiqUkLTsc0m0K6UQhIle6wUDI NQzB50Xl7eQhu1vRtNlBeWJxaWajCUVCRCEh022K9qddZk8EOHGxZNOLcgXZHkXrcw4TNZ/a 6ysX2URW4DaDVFfrg3Si3x9Uca35Jzza98YpTQUU3wuwyUavYgU2i8Visawq9dwTgMAgiE9/ CxkUrq5+FE7C+/9r9HP3j0OsGSuyWSwWi8XyYKB1yOjoCDMzMzz11FOkUimOHDmC4zj09PTw 5JNP8sMf/pCRkRHa2tqswPYAsub5yO7jWo//gebiX5aYPlYjO+iy+zMttA0qdGAemLJc6aKh 0Yb5yRrnXlugZ08Kx5N4CXVbIpsOo5CbUkW5gO7JM2hDadZn+Ptlim8H6Dlzz/KuXW33IKxr bjsWnMUCUS6nu1yhlX2NOnjpBgckQcQEzTsdunZ7SAdmLgQsnAop0cjBdW03LBr3JB8swUB8 eKjhgZsTdOxzkQqKF8IVnOxDvwqIpQWdj3hIJ2q7tDbRcZLF3GpCXfPd+zn0SYJsEQhH4OYF 7ftd2ra5eIn7cFP3sI5JJch2OnTtN4Q1g5sQS8pdOYLmfoegZigMhdRPhHcmbF/TlwkBTlIg HfFALmnJZuh6IsGWp3NcPFJgPFvFty33IlZgs1gsFsuqU88dwsgo/nhi4msIc01XXDgTiWza tznZLBaLxWJ5gNChZm52jpaWFgYGBgiCANd1EUKQTCbp7e2lpaWFUqlEGIa4rmuN9gBhNAQ1 TehrjFFrtkCrAxD3Ie+VKUD1tZDquyHBJzWFZ+qkW1yqhRBdNxu4HA31qiaoa4QEL65wPHnN e27wayFCCtzY1XI2BmrlkNKMz8zZWjQnqGi6d6RJ5twl9SE6h0YIcGMSY6AwXWd2pEq+M0a2 LXZPRDbTqJe6Zu6t15oPYd0sCsp2T79lzUmCu1WAhnppafjDK6hBQaJfkGiSxLMSKcFLCoQb iWuyXSzx7hIKYjslsU6BP2siT6cH0W7bBMluSSIvI28z5+7aGqkEXvKacwhwYoJEv6S+wyBc SGyTCC/KmOGkBaamqR+5xotqjfQt2QGxbZF3nXAEblLgJeRyEXKVEIByINEmcWLinp7Y8QSJ nCTZLiOB7doikeDGozJP9UkqOzS1hTsPzyokxDISJ24ige0ePMB6E7WFI0g2OWRaPTJtLumd DsGEJjhuezywApvFYrFY1gg/vZtS3z8C6ZIc/ZOlHxbPwfF/CUEJtnwZnKQ1mMVisVgsDwJC oHWI+ZArkzGGMIx2iTuOgxB2c8165U690IKqZuZcjeLuOvG0syY5O3RoCAoCWXKvm0dn1W1V AApQORty4UcFgpqmuhBgwg358gICv6YZPVVk/HQZJybp25OhtTeBdATGQLUUMHqqRCyl6Nic WhTfgrpm9HSRcz9aYOZIjZkjNSZ2Vsj9Fx7JrLPEJaZeCRk9XUK5gs4tKaQjmB2tcvwbs2x9 PkuqybtnXmyrQTCjKYz7kbei3SdguU/ImMDo6zfYohnSByS9z3vk+5xIBLimcRc58DYJZBxM GAkGTlrQvF+R6lCMv+FTdjV0AnWuK+BtRFQPNH9E0fsRj1SzojRzB421YEnesmXlogTZTkXf Cx4mrOEkBa37XObPBbhJQbZXMd7iMzUZYII1DA1J5NEoPRb7yyuhLteym4llFH1PesSz9zZv mRAQzyg6d3u48eWe0EJAqlnR87RHWIfJEZ/w9J09gxsTtGx1QIMXv/uHkJIoTOc6CuwgVFSX 3biia0ea2suaD4pzzF/yo7HPQ44V2CwWi8WyZj1ykNxOqecXMcIjNfKH16xGaChdgNO/D2EZ tv/X4KStzSwWi8Vi2cBIpWhububUyQ84c+YM2WyWarVKpVJhenqa8+fPMzs7y+7du3EcOzVd jxhtCH19R2EOdd0wf75OpRCuSahIYwxhQCSwFe+vGFN/T3OZMkhIt69vxUVrsyw/kDEQDzIk ajkqhYCJM2VO/Pt53KbIu8GNSxxX4niSWjlk/GQZNylJZB3cWLQiWK+EjBwtcemvylRfixat 3ZzEr+ko3GTjWn5NszBZ4/K7RdyEJJlzSOZc/KqmMhVQWQjQoeZerDQaHT3vPbfhDJSnAnRo d/Jb1ltHDORAtkCsXdA04JBqUggJOryar0q1CJzm6L0MK4CI8pLl+h0ynYrZUwGySaBawFSg /t6de/sskuTuz7HSJYlGbjmRFJA0iLQg2aVo6nOJpSTl2ZULbNIFN3HjULZCQiKvaN5kmOzw cTOCpgFFbU7jpQVNmxyK45rpdIhKg/TArEWI2St7mhvhK5eErVxDvISgqde9J+KekAKhRHQa EZVLLuYs5stbejDEUpKmPofproCpxJ3nGZSuINmkFsv7ruupIsobt06GxkKCTEVhNpUjyHXE aN2cINZaABsoErACm8VisVjWcpFGegTJrZS7fwGEIjn6HxG62piZ+lAcgnN/FMX22fHfgpu1 RrNYLBaLZYOipKS7u4uF+TneeustpJRcvnyZiYkJhoaGmJubY/v27XR3d9v8a+sUrSGoGcI7 CHFoTOQJsZaJ2IK6JqwC+v4KbKYA/qihMhmSbHYa9jDrLnZgvRKyMFXDjSkyLVe9xEwgaF0Y pHm6i3OH55keqlG7FFIfFQx9d4Hp81XchKR9W5JMq0dQ1xTGfML6HH4lbIQHNUy+V6U2pDEF EJkojGK9oiMvGyXQoWFurMrQa/OMvF5GeYLQ17QOJpgfreEXNEHVoPW9qRtzY1Vmz9eicHf3 uswN2OCQljXlikByI5FKQNjmk3peEPNiSJelYroQeClJyx6HZLfETQtMCIULIfVpQ9MjDskW iXQiESnzlCTRKSkOafxTd5izqoHsA9UhCC6byCOuypqIbSotyGyVxDo0856OvHKcOxNFhIi8 jLI9CjcuUDcJDSiueLk18tlJGeXpErIhCjWuL2ORJ2JYvHFbIjpBJECP37nN5CA4HQJdi+pJ rFWS36ZI5NWahYdc8kzy3pwj1SZxkwLp3N65hVhq//v9DNe8uusma4oQgmSfQ9shh2xHFK5Z CLFYly0RVmCzWCwWy9ouOMgYQWorpe6fByAx8edIf7axilOPcrKd/+Nogroostme22KxWCyW DYcQZLM5Hn/8cfL5PKdPn6apqYkwDBFCcOjQIbZt20Y2m7UhItfz2M2YyPMnMMtCfa7He70f oSGvey9FQ1DWkVeThqBiCHyNMWZd1HdjoFIMuPBOgUy7SyLr4KloB74OIFNoJXehi6NfmaE+ bQjPGcAwOldlIl/D65LInxPEMwodGAqXfRYu+sy/U0eXwAQGPQNm/po6o6Mwnou5yoxhfqLG xb8tMfOtOgCFkz7Dm8v4RU19QlOvhJh74Bnm1zTDx4tc/HaJ+hltX2zLxiYZ5VQzZYM+d6M+ 2FBvKdN+yCHvpahOL633shEib+DpWJS7UkUi+OVkndJwSPcBj0y7orqgceKC9sddsr2KS36d gnd9Ty/RCWaBWwo/IitwuyNBTyYgGL3Jc9yL4YgLSIi1SDofd6nOG6ojNfxpE3kK3Yk4IqIc dvleD6lA3SSHWJRrTKDuQfhA1S5w2qDOndtM5gVOuyCYinKGpfsl3fuj8l7P4Xhv+kxK0LrZ RWtwYht/09Z6KQUhILfJY+tHc7QPJlGORIfGrtB9CCuwWSwWi2XtJ/TCJUhtp9z98wg08clv IOsTjYl3HYpn4OxXolH+5i9BvL0Rs8BisVgsFstGQilFPpdl79697Nixg3q9ThiGSClJJpOk UimUsn38ekcHhmoxJAysh85KCMqG2nyI8Q1BVRP6S73YjIkEJyFYlUXNyIswuqBQYtlu8zAw FCei3GHhY9femED5HrLgUPhmFKvsSo4VUzBoDByAheE60/kqxdGA0rkAlRL4wwZ99vr1xGiW 5ogyEPoGf0FjJg2mAJXJkMo7jfyMvZLqQki9FuLVFaKRNkoqsWJ7GW2oFUMq50P0ZVuPLRsb kQVvQBBMgR6/wfsGaC/EzQpinqA2++GTgBMTOJ7CRL/i1w1eWlBLChI5iZeQ1IoaoQTxnCCR lzjxG9xTM3iPCIJRCD+4+TsmFAgvEtecVoEuErUrK+XaMJPX8+hLRnnWUAIZAy8jSOQV0tHE Ohp/SwlEw6Nspa7Vp1YAACAASURBVEhHEE/LWwt0IhLYpNsomIb3m3SutssyAU5eRO1iOfKI Uu0C2kHPGvSlxnFJkEmBcO68HROqsbyiQCUhlo3K1k3IDeuVJGQU8vGKve85V+oSEJ6O6q9K gnLFA+/J5cQE6WaXRNqxXms3spE1gcVisVju0xAIP7WDUvfPY4D41LdQtbFoxKkDKF2Ek/8a kDDwM5Dsi2JTWCwWi8Vi2TCEYUihUKBarZLP54nH41y+fJnh4WHi8TibNm2ira3N5mDbAOhg fYU4XPcSSQVKpwPCqiGYvGK7pXddKwXMjlbxkop8R/ymIcbuhKAeMjMchWNv6o7jxZeL2WFN U5ryl+bZM9FYHXNVWFt27suake9WmDlWp3wxJBjTyKzA3CC0mSmArhnqlfCmedBMAWhcM0wb Zk7VOPfmPKlml1hKUS9r2gYT5Npi0aL4SitNaN9lywMwk3ajXF23ytFkaCQ8FDedlnNN1MjF 8HTLcmJd8zfhXqcN9kDlBLpkCG+VX+2apkjIpb/ftg06QXUJwlGDGYs8+gCoG8Lh6PoiC94W ia4Z8rsVHXtdkk0SLyUY+EQMHRhyfQ7qboYg4vaPE0JgMDgxQet2J/JqcyMPuvQeSeteh+KI Zub1ABmD/POKZKdk9r2A4vc1ZuxaG0Z55O4mtKbTJGg74NCyzcWNyY0vntzF/QuPm+YFFHFw egVoCIcNblfk1dm8xUF5D77qJISwMSFv9i5ZE1gsFovlfuKnHolysqGIT30dVRuPZr8mhOoE HP+X0Uy4/6chNWhFNovFYrFYNgjGGObn5zlz+hS1Wo2nn36a+fl5vve97zExMUEymWR8fJxn nnmG1tZWGybScht1CoJaSLUUENZMlOOt8ff1priZAtSPaOon9Q2fpbzgc+HwAs39cbItHspR 99RW9UoUFjGoaZI597oCmyEKC7fSXHlmAio/DKk0FKsoz5q5oSAHoOsGv3ZtiEhuGnbUTBqm /qZG4VRAetAhN+hSmQlx/jNButnDWYHAtpgT0GLZ4Mi+SFi6NsCLiF8J+CLuW2MoEpHgt1Y5 vGRe4PUJakVDuABuJ8i4ACWoKUN40URCZApkQpAbdGjb5uLGJRhDMq/ARDnYlCOuWm0NhiJu XJBujdY16uUoF1y6X9Gx20N6PnNHQmRMkN+uaN7i4JcMpdc1Jgm4DQ+0BLiPCYKLZqnwdiuS jXJS4KQFLdtcWgZdHO8hHIM1HlkocDsEugLhsRu/PzImMNpEwm1bJJI2D7go145fH3aswGax WCyW+46f2kmp54sY6ZEY/1NUfboxMTDgz8Ox34y82jb9rBXZLBaLxWLZIGitGRkZ4dy5c+za tQtjDOfOnWN+fp6XXnoJKSVHjhxhZGSEpqYm68VmuSVBXTN+tszwsSKTJ6roBYOIC2qFkFo5 XLOF3dvlijeWaL/BGLiqKU4GZDo09zq9nV8LKUzXKYz50ft4ozxmjTCVWt/h893k92VtQg1q CwF+JcR1JdViQHk2QFdu7PUWvGcIzwXUhzWlCwEqIagWwuh5VjAlCAONX9Xomg0PadnYqA6B 1yMWvddEHGIHBJldkuqEoZYCM3OdL97Kk+1u7mmnIHVAkOiRzC+skZKtQMaJPLkwEBOoDCT7 JF6roZjQ6DmDSgpS/ZJki8SNCWRDiJTO8rZQuYJYk0C2CMKx1WsrhACnIcr4QiCIPBKdWOTR dsVbUMUETjwKLSliAncXZHZLhCMICyEqK9CzhnAFApsaFKT2SNy0wC8aHE/gPARhDm+EVJBs VWR3h8z5IeGxW5SdFMT3CbLbFfGMfChCRFpujZ3BWCwWi2V9LJgkt1Dq+UWMSpG69PvIsHTN hyU4/lvR/1v/EaQ3s+5WUCwWi8VisSxBhyGzs7O0t7ezY8cOtNaMjo7S09PD9u3bMcZw/vx5 FhYWCMPQCmyWW48X65qJoTIn/mie2lBIeMkgcjDxbpXJXWWaexMYs3FWurQ2aN/cc3HNaMPC ZI0zr8wx9maF9v3xKFTclc8NV9zHAAhrBr8WYszqRoDyL2vG3q3Qsb2C3CQYPVXi4qtFKkPh TcU5U4DgtCa4rEnsV9SK4Y0Fw+t930T55oKahsC+R5YNjoxCNF4Ry1SvoOVZh54nPcbf8ym+ rvmwF5sQAuWJVZtCx7YJul/yiOcktckatWwIWTAL3FUIw5XiZAXtByLl/ZKpUzqqSXQJ+j8W o6nXQdwkd6MQEM9K8lsdpnsCwnNrcMNi+T3c6GPhQfqApP/jMeolQ3VEg+SqwHg7JCHxqKD3 BQ8hYOwN/6F/ndyYoH2Hi3KgOl6jmgwjj9AUi3nvlpSJC00HFQMfjZHIq4dDXLMC4u00yxaL xWKxrA/CeBflrn9IceBXMfJD2ZPDKpz+Pfjgd6B41hrLYrFYLJZ1jsEQhiGxWAylFHNzc0xN TdHT00MymcQYQxAEaK1vGibO8vCitSEM9JJ/flXjj2mC41E4Qn3ZUBwKKM8ES/OIrbf3QUPo G4z+cK6zVbiWgVopZPJYlYX3ovxqoW8I6ppqKWB+okqlEGAaXmtBzeDX9IpEqzsqz1HD7NE6 82N1auWQ2eEqM2/VCd679XVNIQpLGRYNhYk6hal6lM9tJfdsmxnLRie59FfhgtstyPYrct0O sZyIckl9COmAmxZRGMBbLJYLFR2/GD5PRAFkhBSNnwUiKyAJcjDyXnNygnS7ItUmUckofKO7 TaD613ZlXnmCZLMk26lI9kriWwWxJkm2I/I2upUY4sQEsaxAJdeXoiAEyBykeiT5Xodki4zC Ya70PHFwM1fKSuGmxRrtW16/ja90BMm8JNWqFstddgncrQLRfD0jQrxZkm1XuPHVrydR6Nf7 Zz+hrnpVWm7SdlgTWCwWi2UdDW8IvQ4qHZ/BqDjZs/8bIqywGC4yKMHF/w/CMuz4FWjaa01m sVgsFst67dWlIpvNcOniRU6ePMnY2Bhaazo7O6nVagwNDTE1NcWuXbus95plGUYbSrM+M8MV jAE3JinN+EydqhLOm2XHmvWYiO0KFSiPBoydLJPKu2TbYgi5uqtVUc4xg6lDYdjnwtsLpFtc KgsB88N1OnclybR6GA2lkYCJoejeUnlv9e6pAPURzeTpCgATx6v44yuLTelfMFz+QZmwbmjf kaRja5J8RxzliFvaY7UFRItlVfvUPhCpq4KIkFHeqKbdily/E3moXUdBko4h8/+z9+YxdmV3 ft/nnHO3t9ZerCKriluz2ZvYkrqlXtTSaFZ79iUjZ8YeJECQBAicYAwHBhIgwAAJEnuALGPY MDwJYMDOJJ7JrPZY45E10qgltdTqVi9qdTfJZjd31sZaX73tbufkj1ssspo7WVWsKv4+jdck q169uvd37j33nPM9399v1FDq07cVBLSG2qghqGi8oEhd6EWavkMeYU0TVDT9RzzaP25pvJVT +4TG79HkbYdShVMOpVAl8HoVLnbYka11simtCOua4ad9eg8bot7ivO9USNJ6fX277YDSUHtK M/CYR1BRqPn7WnJBaYhqmqFjPmFVb5p4ojywym5IetJNFQJVISDpAMxEkWrU9CgI3E3fvmWC k4FMZzhtt1zk0gbqQ0GRgbW8fW4KVQNKxaab7YLMYgRBEIRtNno05MEeuoN/E5Smdvb/QKdz xbZfHMQLcOnfFSLbo78JQy9KzARBEARhG2KMYe/efSwtLvK9730Pay3Hjh1jeHiYqakp3n77 bcbHx9m3bx/GGAmYsA5rYXkm5v1/v0jatPTsD2hOp0z/dRc7tbOEErcCy6+nnKmsMHgwojYQ bLrAdoV8yTH3rZjl4yleTZG3HDaDsGaIqh42c6y8l3JhvMnw4TKVns2tdZxNOWa/32XhZMzS 6yn5mbtrS3vRsfgXCc0TGfMvxvhf0tQHAox36z4kiy3JisV25d4SdiBl8PYpdB1s5+qXoxHN yKcD+ic89E36FOU5+sYLS5oX3kZgM4q+cR+XO7yoEF7CimL4UR+ti/plex7zSVYsyYJj6NM+ 5UHN3PvZ9Yv/qhBYwicV6TTk721Nv600lHsN0TGNs4VI4Ed3ps4UgqLCVBUqAmKHUw/+eaN9 Rc+jHkNHA8KKvu+0hEpBpd8Q1TVeuME1xFTRBqoEqqTIuglWZ/fdpl75Sv28zcMrK/wxcCnb xrGlDGQ6RauNrW2o1O3bXRtN/74SPXtCgnB7pMNUNfAf0+iKIu7kt639ulWIwCYIgiBsP5Qh D4bpDP0sOEvl4r/AdM+hXEYhss3B1FfBZsXoZ/DFIm+FIAiCIAjb53GuFIODg7z44oscOnQI 3/cZHR2lXq/T6XR4/vnnGRkZYWBg4Ia77oV746qba2eSZ0VaSChqrjVOpzQ/yNCBovFRSvzu 9llQuavzOuPoPJaTdOy6mms2d2Rdu2F12Jwt0j0mnZw8cbimI37FkdSuOsW8I5rW5ZTmcEJ3 KSebcbSmMtKu3XQPoEsc6bIlXYb0PXtPbelmIZm1dA7kZMmtj9k5yOKcuJ2RdRwk0kcIO/SZ GoKOClfY6kMWE0BQUfiRwt5Iw1h12vihvjMHkCpqUl2rLmijCEpX/+2XNH5FoQPwK4qgqtdN xZWGYEwRDils26FrCr3syMtsiotNlSB8ThEMrTrP1GpKzOgeLE9Kob3CyQTgtCucQ5veuLdx aCnwShCUFdootF/EN56De3Vua//2gus9ngpeWKQNVb4jXulg1f0LbFGfxlm3qSKPMqBDRZ4W MVX+NvDFa0C5DRf8tFGY4NbuRbXad/jh9qow5vUXInhcAkRgEwRBEIRbj6Ks309nzy+DyylP /wFe+xTKrs6Kk0WY+grYFPadhHCI/fn3+MK+MzxaHoLGcagevjo6FgRBEARha3GF0FOpVNi/ fz9KKbTWdDodyuUyBw4cwBiDtVZitYHYBJJ2viqyqZ12ydBcSJg716ZnJCTPHC535A1H3nXk bQudHXo7rICNHUk7x1rHlY34NlttL7sxy3hJbJk61eT891donc3X4nWtkJXPOmbf6tKazVh4 O8FOOZJlS5Zszb2Yt7duyTJPLdOnW1x4q0m8mEsHIeyyOfO1f3Fb/Duv+ec1X/Prij1f9Cj1 ay5lKVnTFSLBJhGMKUZ+zMevKBrnNvYet8aSm/R68WuDVR6lFF6JO3NoKagNGya+GDD5ekr7 B3YjmnFDrw/tgakqao8bpi+dIfLuzzpsAsXQoz7OuU0RBW94Ggb0oMKlDje9+7oO4yn8SG+Z m37DKFGkOTXb67hFYBMEQRC29YzBej20R74ESlGe/iO81vGrIlvWgskvw/JxXDTC/niJn39k lv5SEz5IYfgLMPAZqByQUAqCIAjCFmOtZXp6msuzM7TbV7etu1XhzTlHuVzmscceY9++fWit JWgbEffMkaVu25YjuyXO0bgcc+a7Kxx6SWEzV9QS6zra0xnJ/M6uoZW3HXFzVUy7xrJm841r rrSbM3W8xdl/26L9enZDh5i96Fj8SspikOIuu+I9WxRaNwvdU8WC8EY4Ea+U3nPWFbWfPrbm liWW2VMdzr/cJF2WGmw7qCsQrp0VR1ccbOAShQ4U2gflqZsrJQrAoTY4xaFSYPxr6pRdSQmo Vh0vVUXfYY9Sn+by2xlZ06E06AFwdSABHRbpI7nXlH9l0CXQgcKvwcBRD+MrWtMbLKLfwMGm NRhvY2uCaQ+MVihT1IrTATdtV6Wg1GsYfAQWz+T3HsNNRntQ3ae5EJ7ikOm/r88ynqJnpDjR zRJWlFoV1aJiD7cOCvE2NZBOO1QFVLDa7rsg6YLShaCrze44nweNCGyCIAjC9p9geXU6e/4W YChP/z5e6wTKJjiKxTu7/CHZ0jm6yTCNjiZYaZBO/jVm7nX0/l+Fo78pKSQFQRAEYauf30Ac d5mfn2dlpVhJd86RJAkLCwssLCxw6NAhDh06JMHajPjv0AXqNLY0p1OWJuNCLFyx5HOO5g8z snm3I9NDXsF2HXErZ7NNm1nXkc5a3OwtjuXig7tA7OmN+d3OFsJaZyWj3XCU6z5+dLVOTBpb lmdjli/FpEu2KOks7Iz+y4KzsuoLQBnCTyn6P+sR9itsCiYqhJigogjKN67JZcOctNRFeeUN XUDXpkgtqMyqoFZS1McMYV3jlxQ9BwzlfoP2WE1vB96Qovq0Jm9DPGmpHTP4VcXCwr2lDvSO Kno/Z6gdMOgASr2aPHEbKnoBWG3JvWRd/JRePX9vY4KqPagMm6LOmK8oD2h6nzZ0L6/vJ68V lrT+mMi5TdEepCrGbcAODu1tXn+gKK7j3kMefkWRNBydGYtLHMoDNQLlz2p6jxk607vlQaKo DgbkOXi+bHC7X0RgEwRBEHbGgoRXpT3yJZwOqFz6F3itkzibk6TQiiHNU5ZTx5++U2f8qZ9h /HNHKE3/EeHpf4Ua+8UiXaSSgYMgCIIgbBVaa/btG+PQwYPr0kBaa2m1Wpw4cYL5+XmCQNI5 P+y4Kw6kVTdSsmQ5+80m8XxO+70cNwtpx+5ocQ2K0sF2taSwsAHzg9iRdiyzZ9osXYo59FwP faMRSimcg3Yj5fhfLXDxr9o4u+qYEbZ/u+aOtOmgIbGAwvlVe8qw/8dCakOrLp7VMmlKF/XX bjTNzcoJrZ4FTDna0IyGV5w+SgEaKv2GyoDB+AqtIPyUxviK5uVCPFMaSgc0ez/vk6w4Ft7L GPuRABysfJBj77YuYhmiw4rxLwYMHPbRpqi3tngx3fDYZ35KHDTRxq0/f71xWSKDkmb4qI9S Re2ywcM+fklx9uX46jVgwC+rG6bzU6aIyWbUt7u/C2Xn3GNq9TqeeFaTZ47WfM7pr8ak8zlo MMOK/mc9xp4PmHoz2RXLStooRo9UGD5QJiwbhPtDhheCIAjCzlmUMGU6e34JlKb20f8M8TzN GNLVjW+D3iR/+1iI92hGXHsGlTWJzv2vcO734fF/ACaSIAqCIAjCFqGUolQq0VOvXfe9gYEB wjDkG9/4BnNzc4yOjkqKyId1fGcdnWZGcyEhiAxp15I2LctvpWQX3ZrTaqeLa1sSSwd55orU mg9BubFs2dFZznDA8qWELLZXxUtXuAXnjse0Xs8pfcpIFqwd0yeATR10pcWu4FUUpR5Nudes F3bUrebOlsxL1olDG/6cp6iP5QdXU1WaQBX34ZUDVcU0vNSjUVhMWRHVC9ddOKSJ5+7eEWRK irCuKfdotFGb5th2ymJ1dn2cN1Kw1BBWro5/grIi6tFo/2pMlVGY4PoUuEqB6QV7UJG/t712 bihduM7cDtlRYnyF8dWqexbCXkWnqkiMA1OkPo3qGq+sdsUmGaUgLO8+WUgNgwoUbnlrMx6I wCYIgiDsrAmXjshKB0hrn0B3v0marR+Qj/fE0PgT7FmPbOiT5F4/pnUeyQkjCIIgCNtpYq8w xpCmKc1mkzzP8TyZnj6MWOtYnOpy8q8WKQ14pB1LMmdJ37Miqt0leWpZmuqydCbBNne/TS5b sMyd7BLUDMlKTtK9WszOWkg6OVmrSPMlCDv7oXnl2cndiTtqk699pYrDuVMBarVOotJQ6jGM fs7n8rsZ3Q/vPFWkij4WC8WucgUXp3Tnjez1KnCO/AzQBtUPqgL2woM9Dx0pvEhh2Vm7PZQu 0kUOPeGjNCSXHWnHrV1zu+xy23UERzU6UsTHLW5l61pKZjCCIAjCjhtyKlvk10mig2SZxuuc 5so2Xa2AeBbO/SFu8VVsVMO0LwAisAmCIAjCVuKco9VqEXc75Hm+7utJknD27FlmZ2d54okn xL2229r+Tt9nHVniaC9lTL3aIVtxmJIiOXd34pqNIYvdDtlP5TbpfoO4nTN9os3cd2Ls1N39 HpeBzdyOGjLnZxzTX+miI0XliCFp5TjnuLIE+rA4+YRdzi5cuVWqcOSNPBnQXbQs3OU56uBK 9YeH3OWoVlPfXsnwVwazX2HqkHpF/bD8Eg8kfaQyRQ02twPlqKCkGXzEJ08cc69lpDPXx13Y hrdDDUxVYcqKeIuzz4vAJgiCIOw4nA5xpowyESsH/muq5/8ZXvsDlI2vrhB0p1F2Ed1bh9oe CZogCIIgbDHWWiYnJ/now1M0m82rz/FVga3RaDAxMcHY2BjGSP2HXTVWs4VY45xbS91lrSON Lc46gsiQp5bmYsrlc20uvtWie9ESv5FDCejc5bXWdiTtHGu3+UJeDnniVkWgDY65c6zMJ8y8 2yF+P79r959NHUk3J893zmKoW4HkVYuqQTCk6DZz0tiSJna1Dpv4DIQdRlA4kFyXNTdScEQR 9Su02fmr+oqr9cu0pwhKilKfJjqkyGYc9sydfY5XLVImrgkdCrxAEfVrvBukUtyJgbpS5854 irBH4Zfu7Lx0FUyPwu0BXQfXddi23Fp3FX4NflSkIS3t02TLtnCvKUVQ0+DYFXXYdnP7bTUi sAmCIAg7DmfKOL8Pz55ERQO0xv4zSjN/SNB4B5U3V8ekOca10WkKjZOw8BYMPAumJAEUBEEQ hK2Y4AKlUonR0VE6nauKyZX0kD09PYyNjTE4OCgOtl01UHNkiSWeL6xQeerAOdKu48K7DZJO zv6ne1ia7vLht5eZfqND84Psqih0L2khc7AZ2z5vU77s6C7nG+q0u6IhOevoNDKWTyS42Xv4 nCsOth0qSuVdiFs58xc7LE3FDB4oYcW9JuwwzLBCl8G2IZ91eGOKPT/uM/ZcSFTXu8I545UU 2i9OxQsUQ4/5ZLHjXDuhNWNv7rYqr6aHDCh+/ppwKAWVAcP4Z0OimkbpnR0o40N9zBDVNeU+ zd5PBnhBUSPsluOuaDUuGlRYpGnEk40G94LWip69HhM/GnLBi1EGvFAx8mRhjfJ8sbE98HlG cLXGn6qBHlXo4MG0iwhsgiAIws6bQId7SGvH8Be+TV/zr1ms/TidkS+x3HJUkx9Q8dr4BkIP lEuheRZO/g4c/s9h6EXweySIgiAIgrDJaGMYGRnhkcOH1jlJ1OoWbK01nueJuLYLcdaRx468 44hbGVnmyOKc+XNd2vMZI0cqrFxOuPTtNstfS7e8GP0Di0tWOMXuRcRyrohrUb+ouIfyzNJd yUhjS1AyZIkl26Daaztp6dCtQLZk6SxlrMwlTL3bxi9pFOpqikiLZIwXtjcKvCHwBhS2Cwmg a1AZ0dT3GPw7WDhWGlSwTU5HgYkU2ldrtdK0B35FYbzVcYCnqPQbans9vJ4UFYG7icBmDipM D+TLoEO1Npa4QlDWBKVCddvRDjYFUVUz9ukQrSn6MnW1fa97u1GYCph9DjOg0KXVN8vQ6v6a QRftUB81RANFG2gDlUGz5sQUHuAcI4TgEU0SWNxlh/+YpnTEEPZrkiVbpE7dQkRgEwRBEHYc 1h8g6fksYe1lepsvY/IVuuEhZnUFp0Miv03oFwLb2mrGhT9dLdDRhD1fhHBIAikIgiAImz3h 9DyiKJJAPKS41LE8lXD5TJuwYshiS9LMidvFK1mw2IsP0e765EZBuv35OwdxK6MxF1Oq+1R7 fZyD5dmYs282WJlOGXm8zOKFLnljgwQ2q3ZWPbZ5x8JHMXnqmH8/LhamK4ZkwUIHsoZFGYVL xM0hbGNWRSh81upqKa1QRt1W9VYaSv0af1SRlh/8dR6UFUPHPOaDDJuANorKoMaEiqB8rWik 0OY2olgZTA8E44rwacXA4x5BeX1M1KqItxvQnqJUU2vXxC3bfJ+iNGRYHsxJlx0u/dh7PFAj oHxwLaR+2N3cjtek6ly7P0VY2x73SKAIRzS25VCjitGfLjH8eAnjK2aPd2ifzMm3MK2BCGyC IAjCjpx55NE+2nt/nWj6T+hvfQ/bfQ3jpXSUIzd1ojKobIWruYIcXPoypA3I2jD6U1AakRGm IAiCIAjCJpG3HVNvdmhdzjjwXA2bQZ4WaSOdOIpw1mFzblsrzDlHaynlzOsNRo6WKVU98swy farFyT9epn0+p/FSwsq5jPTc/S0oWVek2/TSAJXsnHFyfsEx87Uu8/WE+ExO80SGqSg6x4vU o+kZB7h7Sp8pCFs71VWgivtYlxRedGe1t5RWVIYM4aiisw32tUQ1zd5jATaFxQ8ytAc9ez3q DrzgHqbhBkxZ0f+Ux8iTPqW63vm11m695HFHbV4dMww/5WPClPm3M7KGu+rcXcUbU+gKpOfd aopOWQMRdvCtoYualNZ3YCAaN+x/ocb+p+urKVIVU1/v3HBP02YhApsgCIKwI7FeD92BnyTu /TzR3F/gdS+y0nqbNy99yMjoOC+M1wkar2OSWdYVupj9FsQLkC7C/l8vnGzi7xcEQRAEYZfg ckcWW6x98A6GbMGx/G6CyxzZJy3riqQ9pEaiPHEkXUtYdWSJI23eWmW0uSPpFo6/1lxGPJbT mItpXE6Y/aBD480UuwCXTUxy7v4cgc5Cp5HSvugRNsqoeOcswroViL9liVdV2+z99SvMD5VT UtiZ6EJACgcVaQOU7zAl7lxgU2ACto14or3Cqeat1QVTeIG6r6m30kUNt6Cs0Z6IRFDUBYuq mlK/JhrRZFVH1nBkS1f7PF0B06NQh6C0R+NHSvYZCzv3mq8pSnsM8RKkQ47KhEelz6dc91BK Uen3qBz2iB+18MEWHZM0iyAIgrBzUThTorPnPwLg5RNf51+98ad8/sXP8MSRn6F0+cvUzv1v 6GSBdas4y+/B8f+9ENqO/j0IekVkEwRBEARhV5A0LIvnYzpPpASReWA7/J11pOcs2byi+ohD 5A1wiaPxUcqFH66w/5N18syRd90ts0R2mxkX31+hu5JjU0eeOebOdfjo5QYL78Xk04Urq5vk 0LnfA4SV+ZSVH3gE0x5ksgIrCFs2s/UU1SOa0ecCls5mdM7aHV9P7E6PXekiheFGfubDhBcq Bo/4VPcY8sQxdzIlnr3mwaLBq0L9GY/RZ3yimpY43s11rMEESmJ2s/jU2LI6uqqq6H0i4NAX asyd7tIY0yN9OwAAIABJREFUStn/QpW+fSHKKBQwuL/E0V/o4YdLizSmtmb0KQKbIAiCsCux wQCdPb9EHgzR+8F/j07nWSeydS7Bh/8cOhfhE/8jlMckaIIgCIJwnzjnyLIM5yxZlhLHMd1u 9+YTZaXwPA9jjARvg0iXHYtnY7rNnPqQQz3AFSE3C3QcNoWknZN2HC53OFuISs4+XLKbm4XG aynnJlYYmIhunxrSOtqNlDPfWQHnyOIidknHsfB+TOMb2VrKw41KfWgzS95QqLasJAoP4hny kJ64LoSj0h7NwCGPPHHMljN4CPaAKsALFF5ZQXD7OAnXYwJFuVdTHzHkqSNpWWaDbF0iHx0q 6vsN/RM+QVkCeTfXp/IUfkU90PHUto1Pj8IbVWRTbkuc4jqC2qjP6KNV8rQY444erVDrD9G6 aJ+e4Qj7JJweX4HS1rSZCGyCIAjCrh0KWa9G0vcSi0/8E3o+/C1M+wzqStVfZwsH24V/A50p eOq3YOAzRRVbQRAEQRDuiSRJuHTpIt1Wg4vnz/H2229Tq1Zu+n7f95mYmGBoaAgtlePvHwc4 h01W63ptg8VqtwLtcxkXX2/RmsrQnmLhYpeV2QTbefiaKL/gaE1lJJ3bF6BLYsvSdEzjXELW cphIkcUObcCl4Jbdpl1HSiyHwgMgazo685ak4SDdxTPVEXANoF38WwdQPayp7TX4JU15QDPw vEF5irC6C9L53caJpwzo2zjYvF5FbX+RCnFHTtlVcY52E5zBCq6mzHRFOs4b/n6j0J64AO+u zRTVEU2pT8tS0Q3QdYgOGrrkJBsssH3cGaeGQUXFNeyFmtpggNKKsOyhzdWLWhtFEGqiPoOu bk0cRGATBEEQdvPjvhDZ6s+yfOR/onrunxA03kLlrdXBZw7JIsx+G976b+GR/xLGfgn8Hgmd IAiCINwDaZoyOzND3G4yeekCP3znHUql6Kbvr1Qq1Ot1BgcHH8jx5nlOp9PBGEMURet2Jzvn SNPChWetxfd9giDA89ZPo7MsI0kS0jRFa00Yhvi+v/U7nR3btq5Z542ci5fauC54Q4oT3WWS xZzkQ/vQ3SNuBfKOI8/s2m7rG77POpoLCRffbtL4YUY2awnGNWnXbqr7wObgMunLhAdwbzSg /b5lMk2JJ+2uFdhUPwRHFdmkIz9VfM2rK/a9GDBw0CcoK/r3+1QGDCiIanrd4vHOO2GFDhTm PmrDqQiifYrRZwL6Jjy8QO/EMOCXFWn7Idi9oHZPBY6oqhl5MsD4CiN1/67HAx2CCjb4EhqG 4Kgmn3dk7ztUDcInDLq0+mt9zfChMgPjjlLNu040VlrhlzVE4mATBEEQhA0Z3TlTJul5juaE ozz9B4SL30Inc1emcpA1Ye57kHWgdR72/zpUD4qbTRAEQRDudiEiijh0+BEqPQM89sRT/MRP /iT12s23j2qt6evreyDutSzLmJ2d5cSJE+zdu5fDhw/j+8UWeuccjUaDjz76iPPnz5PnOdVq lUOHDjE+Pk4UFaJh4di7xKlTp2g0Gvi+z969e3nkkUfo6enZ0vOy1pGldsPEkSKN48YsBLpZ yFbrwdgpx/ypGDpbV7Nju2ETyGKL8XURY3t9ukznIO1aVi6lJB9a7EWH6XPYzGHTItXmRuOA LLHYFmBlIVHYYtqQvONIz+aFu2u3zk4r4PUrbAvycnEf6wAqA4ZyXyGmmaoirBTPD6XY0Q42 pcALwQT3fh56APy6ojJgiGoGbXZmHLSv0N7G9d1Kr4ZU3eDrAZA8mPWXtZSfu+AxYnxFuc/c MM6bjgYVgsWiH7JKtrpXEe0rnHEZDkrgDyhMSaE9hdIQlf2rfeRN7o+tQgQ2QRAE4aHAKZ+4 73M4E2GDIcL5r+G1T7O21dvlsPhW4WhLFmD/r0HvMTAlCZ4gCIIg3OmEWGvK5TLGC+jp7WNk ZA9RGN5UqFFKXecc2wqSJOHy5cu8+uqrfP/73+fnfu7nOHjw4Nr3u90ux48f56233mJkZIS+ vj6mp6eZnJzkpZde4uDBgyilmJ6e5pVXXiHLMsbGxuh0Orzxxhu0222eeeYZqtXqlp1Tnhc1 uuwGLKhliWVxqov2FHaDhRy3AmyCsOZ20OJTMmeZ+6hLUNWkDUdjMmF5JiaIzDpnhnMOl4NL inPLV4r6espAPG03RaC0ucN1FUiKSOFB0AbX3uXn6AEfF4gUq3XY1Nq/d0MaP6WgOmwwAfiR vid9Qh+Evr/pMfR04e7bqc4o7Snqew15ojHB/YtP2lP0ThQX0rXOKqWhOmQYftFn8f2M7okt vpBUcWz6PgTV7XgdPwiCIUXPUz7f/b0ZBvXD5/hHgzIKVQNVVfg9mtHnSgwfKWM8va36SBHY BEEQhIfqCZ3UP4P1+sj9AUqXv4zXPH61LhtA6yyc/pdFfbYDvw4Dz0HQJ6ETBEEQhDug2+1y 5vRpkk6TuBszNTXN1OQlWq3WDd8fRRFPPfUU+/fv3zK3V7fb5ezZs7z11lu88847NBoNrLVr IqC1loWFBd59911GRkZ46aWXqFarzMzM8PWvf53jx48zPDyM7/ucOHGCpaUlfuInfoKJiQni OObNN9/k+PHjjI2NUSqVMGaLtto7NszVlHRyPvjmIrU9AdVBf9tfdy6ncHXZnaEKxe/mnP0P TaJBQ/vDjHg2p//gCj17wvWpzxzrBM78jOPcHxb3Uvqe3dRrSRCEzUfVC6fGhotGwfa4j7Wn 6N/v4ca9QgRSt5yqo0rgyqzVpgPw9ij2vugz9umQoLyFi+obLBB5vmLosI9zbEiqQT9QDD8a FNqsv77+VN+4hwkU8ZKlwQMQZhRFnSxf4bByo98jpX2aiRcj3v/j1/mc94mHq2/0rjrQzLgi 2K8pDRsOvdjDyOHKtksTKwKbIAiC8NCRlR+hPfJr2GCY8tT/i998D5VfM4pPFuHc70N3Fg79 JzD0BSjvZddswRIEQRCETcI5R5ZlOGdxOPI8p9vt0ul0bvoz1totPb5Go8GJEydQSvHcc8+t /f3a45mdnaXZbPLMM8/Q19eH53kMDw9z4MABjh8/zsLCAuVymcnJSYaHh9m7dy+lUokwDDl0 6BDvvPMOly5dYmxsbOsEtivnaB15WqQSvFesdcSNnKhnZyyM5UuOuGGxO2Qdz81S1JiicKW5 BJK2xV1z/DZ3dFYykiULq7ePW4HkVVmsFITdgOmF0mOG0oiiNKLx/Pufa2qjUAaUD7nNyXX2 wKewtxWTVJGGrzJqSH/Kkcw5Ou857KxDjyp0BbySwou21r1mRhXpYreI4Uawep4bhgIvuPHn GV/hR+qBpNJUgDEQDWjCuiZVqdzs9xpLU1z3TdXgYdr5EnxGU/+UT9CnsUlG9TGPsE/jlTR+ pPFCve0cviKwCYIgCA8lNhikM/wL5NEY1fP/lKDxBiprXR242ASmvlI42g7+Bhz4O1DaWyTI FwRBEAThhpRKJR49epSwUqdUKjM+Ps6jRx65pYgWRdGWudeupKR86qmnqNVqLC0tcenSpesE tqWlJZRS6+qo+b5PX18fy8vLrKyskOc5rVaLsbExgiBAKYXWmmq1ShiGLC4ukiQJYRhueTuk K5ake39CzE5aynFNR55sXM24LTnm3K3Vy3P59d9PujmLF2JaZ7OHtlbdjsWJCCrc5llkoHxY s/cLAb3jHiaAct/9LRqrVcHFhIU41G406ERLKL29+0WloNSjGX8hYM8nfJbOZ1wwCd0TEIyr tXSaW7merjRUjmkuv3WROJAO+K7bs9cweiyg1KtJVFeC8rC0fW31Ebhyf5/R90LA47/YS6eR MVPrMPp0GWdh/qPuHQ5QXfHfFo4JRWATBEEQHt65r46Ie58nK01QP/3bRHP/AZVfI7LhoHEC 3v9tmPsufPIfQfXI/VVoFgRBEIRdjNZ6VTAzaK0JgoAoiuh2u+R5vm6ya60lyzK01oRhuGV1 2Gq1GpVKBYB2+/piP865NcfdteLYlXPL85w4jjHGkKYppVJp7diVUnieRxRFxHFMlt3dzvc0 TUm6XXJlmJubu+37jTFUKhV8/5o0jhbcarrEe15bcEiawE3GtiBbsbguqCqr7eVWr8GiDl5r PiWd2bqGcNZJu99Xo6aQxdBZwJCToSUmwg1RBoJ+Te+4R/+EVzjP1H1OMRVoU3y2qUM3bhL7 zR0xbQ0iTe8+XTivFcztyyC34AMPwAClNJT2auaPT+KZ1k3fs63r5KnCAaWroEOF9mFLuiQF YVWvpfPMEAfbrh73hwrlFy/viMY2HfnKfQwkSlAZ9djzaIWlqS4rMymD+0uk3ZylCzFZmrG0 vIS1+c3HMg5aiymdZheyrRnUiMAmCIIgPOxDAvJwL8tH/hfS2lNUz/8uOpll3epC2oSpr8LS u/CJ34LxXwG/R0InCIIgCLeh0+lw8cJ5Tp8+veb60lpjrSVJEpRSvPjiixw9enTLUikqpTDG 3NJV55zDmEIkvFb4u+Jmc85hrV37rI+Lg8aYe9o5e/nyZaam57BovvzlL9/2PPr6+vjMZz7D 8PDwhsXHOUgTS56K0rKZZBct+ZLCXXaocUhbliyxOOvoNjPmzndYvpBgm1vTDjZxZLHddnVN dgzOwZk/w039P/DOzxJ2niPGl7gI1/fdoaIyoek/aghrGu2pjRdqNFhld079KwVagfIUpR7N 8Kd8kkctScOxfDLf2kNRgFaYAFKVXL9wriCqa/of8/BLatvql56v6DtsUF8CEyj8qqI6bNBG bUkMlZF7fbdjIsXQj4fUJwImu23yHke24sg/uL97VhkwRhUbD3QhFCujAEdzpcV7Z99l9vLM zcfZDvJWSOe9EbIlBf1bcL/J5SAIgiAIGutVaY/8x+ThGJUL/wx/5T2US68+oW0C7Yvwg/8B Ln8HHv270PMkxVYwQRAEQRA+jrWWyclJvvudV2i1WoRhyMWLF5mYmMAYw9mzZzl8+DDVanXL 3Gt3NLFXas1Rd8V1p5TCuaKmHIDneQRBgOd5qzXnrk7ynXOkaUqlUrnr1JdhGBKVylhl2Lt3 722Ps1wur3evbQDOObLEYlO3ztR/Jeudc9t81/4Owc2Cm7163eSZw1qwFpZmYj74qyVmvtrF Tm2RwBZD2rEEJRFW7+GmgalJOPk10npEt1bGyj0ifLzPXl3kNb3Qf9Rj79Mh5d7NqSWkQ0Wu E6zKNulk2BRnnNJQGTCMf0bjckdzLideirewkYr6ZfoWCWuUgvoej1KvISirbesQDMqKvU+H 7HnCrcXWC9TG1oETHmrCumH0WJm+sZDlcwmtcxm26zb1BvU8Q39/P55/841szkGyopmtRzSD rek/RGATBEEQhNWHtfV6ifs+j/XqlKf/kHDhZXR6TXoml0NnEi7+GbTPw8H/FEZ/CsJBCZ8g CIIgfIw8z7l8eZYgCHjppZcwxvD666/z+OOPs2/fPk6fPs3c3Bye5207ge1KCslut7s2gbfW 0m6319JelstlwjCk3W6vueGuiGvdbpdSqXTX4ldfXx8xATken/vc5+7oWIMgWBXyNnCXv2Nd eknnIO3kZKnUltosnF0NNI6ka1m5mJKcsltaf81Jhsh77OyAxYROeQA38TN0zyQ3rKsnPMQz zX7wDilcAvjgVxRRTWOCzXn2KQ8yneLU5lyIxlOY0uYcuxcoPF/hgDx1BDWF9rZmjKAoBDYT FoKUUzd+5nmhwgvUtk6/qT1FVFXXn6AgbNg1BqUej3KPjxfe28WlxxS6DvmFYvThjWm8aP3G A6VAa4Ufaar1Cvv2PsWtRivOOZoLKW+dm2ehPrUlsRCBTRAEQRCuwXp1kp7PYr0estJBorm/ xG++u/5N8RzMfhPiBVg5BWO/BH1PS/AEQRAEYd0E19LtdtmzZw8TExNYaxkYGEBrzfDwMFEU 8corr3D58mWGh4fxvO0xPdVa09fXB8Dc3BwTExNorYnjmJmZGfr6+qjX61QqFer1OpcvX6bT 6azVZ1tYWCCOYwYGBu5aYNNaYzwfhaFcLm+f8VHqWDgZM3+hQ6XHlzSCG32vZJDHDpuvKlyi dO0scgcZdEd/BGWq2PaHIrAJ6wnAG1TY2OGumMo2UexQenM/X3sKE6nNczOvaldBRTP6jE+5 36D0FqlDq7XLgrqmq5uUb5brcCeIVSKoCZt6fRUpHO/nWvPGFOGoptXIMcOKiV8rs/+zNfzI rOvP6sMBE8/WqPaHlEr+LTfmOQe2G+OHW5dtSgQ2QRAEQfj4A1mHpLVjWL+fPBwlmvtLwqXv ovLmNRPpLix8vxDb2hdg38/C0BcgHJAACoIgCAKFu8r3ffLVFIphGBJFEQsLC6RpShiGeJ5H o9Egy7JtJbANDw8zPDzMqVOnGBoaol6vMzk5ydmzZzly5Ai9vb0EQcDBgwf53ve+xwcffMCh Q4fodDocP36c3t5e9u7dew915RTKse1yMLoMFl5LuPRUi9FHq9tTYHMOmxcJB3aaOOXaqzXY YlssDF05j470IzsCCxhISwfwp/8EmoMikArre3Yf0NfUpdrsPl6B28SLUCnQW1BjKyhrRh4L UPqahfxNH7sU5xbWFU2zRN9WFHAShB2IFyqMr+/53lQ10GWFqSpUGUqPGA68WGP/sfparUCl ilpsPcMhPcMRWnOHWS+2dhwtApsgCIIg3IQ8GqMz/HPkpf3YYJhg8dt43Qurs+hVWmfh3B/A 8vswcRb2fBF6npLabIIgCMJDj9aGvr5+Tn1wknPnznHgwAEqlQqnTp1icnIS59yaI+xBpIhU SqG1plKprEtTqZSiVqtx7NgxXnvtNV5++WXK5TLLy8sMDw/zxBNPUCqV0Fpz6NAh5ubm+MEP fsCZM2eI45gsy/j0pz/N0NDQXddgy7qWIKmR+fe3MOo2eF3VOUc26+gsZmSJ3ZZ12JyDLLbY zvqh2k7AJY7uQk5jLqE6EJC0c9KmpOPcUW2ogaUPYPJ7EP+0BES4wTMHvAFFaZ8m6tk8wUhp hd+vSC/GOLUJIpsqFtarY4awrjdV+FIKlPdgHjZKg0X6YUG4GSZQeKG+pwGhqkH5ix4Dnw6w KTR/kOGVFUFkMH7RqZRqHn0TIUHJoLXaOhfrPSACmyAIgiDcarJsqsQ9z5GVDlKKxinN/QVe +0NU3mFta2rWhLlXoXESFn8AB34deo8VtdlEaBMEQRAeUrTWjIyMsLgwz6lTpxgcHGRkZIST J0/yla98hTzPUUoxODh4D06v+0cpRX9/P5///Oep1WrrHHSe57F//34qlQozMzPEcUypVGJ0 dHTd8fb29vLcc88xMTFBo9FAa83g4CCjo6NEUXTXx9S5DL3tcbp9TZx197yYkDUdWbLxC4NZ 15HF23fB0ebXpF/bSXRg5f2Ms99ZISwbkk6OjaUP2VFY4NzL0F4R95pwU0oTmrHPBfSN+5hN Eo60D/XDhqWTM2iVbsKzE8r9hrHPBASRXnOa7CaUYfW85GYWHtRFyLZP8am0Qt+jwK5HFcPP hzzyoz0snOsy950Yrkltq42ib29Epc8nqnjbWlwDEdgEQRAE4U5GDuThCM2J/4q0/jTVC7+L v/JDdLbE1QILDpIFOPt/w8zX4ehvwujfgOpB8MpIAnRBEAThoXt8KkVvby/PP/888/Pz1Ot1 giDghRde4L333iNJEh577DHGxsYeiMAGUK1WKZfLa262a489iiL27t3L8PAw1lqMMRhj1r3P GLNWky3LMpRSeJ53z+eTtzRRu0Zez3D3OHpwFtJFS9q22NzdchHXWoezxULGdRuQXSFYrdUF A5x1WHvrBUfnimMQ7qLNViB+I2fhSEznsxlW4rfDOjtQqUPPLYIvxdeEm+NXFNUhQ1jZTAcb BHVFyyxTUZvTmQSRwg+94rmxC6e5OlB4JSUONuGBPVO0D351+7q2lFYYX6GUuusuQB9ShAc1 5UGPnj0hcSsnGNb4Vb12vkpBWPYIy962y5hwI0RgEwRBEIQ7HkV4xH1fIK08TvX8P6U095eY eHp9sQ9ni5psb/0DmP4qPPp3YfgL4FWvSbovCIIgCA8HxhhqPXUqlcrqhFmxf/9+RkZG1uqy lUqlB5Ii8srx3EoM01oTBMFtP8PzvA2pIedyh98J8fPovjbO50uO+XNdlo906RuNMN71K7nO QXM+YWU+YWCsRFRdf/x56lg6H5MnlnjBQgI2ceSJxTl30zbLU0trMSVvys7/u2r7lWJI6SRs O4/VXfflEDJkW51wqwdGIYBt9oqxUmxOeshrz2MXX+hqtV6eEweb8IDGptVBw8inFaUeTUa2 7e6PSq/PyBNlyr13P/b1hhXhiEF7ChNo+sciHv+1HrxQUxvw1/qWndTHiMAmCIIgCHeJDQZZ OfjfkfT9COWp3yNc+CbKfrwKvYPpr8HSOzDxq3D4v4DeT0jwBEEQhIeKNE25fPkyc3NztNtt 7MesOZ7nMT4+fk/1ynYjzoLXiAjTCs46uMfUW+k5y4Wvt6iPBFT7Akz1+tjazHL5bJtzr6/w 9C94hJWru4Sdc+Rdx8VX2piqonM8xyWOtONIE3tL8S+JLYsXYpJZ2fkvPCSsmtZKQbEoHwW7 W3wQBEEQNg+loTpgqPT6+CWPdBNSvd4PWivqQwGVXh/tKVbmk7s7PwPaK87T8xX1A2X695VA gR/uzLSzIrAJgiAIwt0PeXCmRNz7PFn5IMHAdynP/BHB8mvrtx27DLqzcOb3YO61ImXkgb8D 9UclhIIgCMKux1nLzMwM7/7wHS5cuEAYhte5vMrlMrVajcHBQQkY4KxCx4YgK5HnDnOPpVzd LHTO5LQXsiLF4w3IM0e3mdOayYjbOXlm8XwNDtLYknUsnbdy6BTuKjUMWHdbZ52zRZ02l0h7 3nW75ZAnljy2uFycEzuG7MoMAUKvENiMrLYJ1+KBroBXKlK+if4qCMKt0J5CBwrjKdw2TFVq PI3xiuWv++nPlFL4oSGIdnZ7ySNfEARBEO4RZ8pk0X7sYA9Z+RHCxe9QnvkjTPfc1eIjLodk ERbfhs4lmHsFhr4A+/8WVA+BDiSQgiAIwq4kz3MuXbzIzMwMzz77LKOjo/j+esVIa01/f7+4 166OLsCCyb3CwXY/n3SbUlA2d8StnOb5jA+/vQTAyOEKzkEWW/K4+P1u5ZrPdHeewtBJKaq7 pn0648w3V8gTR3zerou9sL1vW5zCoVBKYyNNLPqocA1mQDH4WY/x50LKfVocjoIg7FpUDdSQ wl12D804RgQ2QRAEQbiv0YPG+v2k9U+Rh/vIKkcIF75BOP81TDp3dXXJxtC+CN0ZWPkIFt+A oZdg5KegfgRMWWIpCIIg7Cqcc8RJwtjYGE8++ST9/f3X1e1SSq29hGvi4jR2kzcsW+uwqaM7 lXPm3zapjwYMjpdQWhWutxsIBHmncKcJm0PytuXSTAeXgbssCs2O6esyyBJDtztMEM2Q9PeT Se1l4do+vQTVUUPvmIfxlRTq29aNtZq+TtpIEO7tFhpSlJ40xOdysnduMJbRoHxVpILcJfeZ CGyCIAiCsBETa+WTR/vohCNkpYNklUcJFr9F0HgLnS5cfaNNoXW2eC29CwtvwdALMPgC1B8D ryrBFARBEHYF2hTutIX5OeI4xlp7XYpI4XpUqgk7Ea2llLBk7qsWhbXulhkdnSuGJtmCZfF8 zOzZNtooFi/GJIsWri0x21kV2BJ7xy424S7HkyuQr0hwdxypojFVYerSk6jRnDQYx4krV/h4 365B600WblTxe4R7j58fKnoPeJT7DVZlEhNBuNvxfwR+ryKdVtxot5bXqxl4PKT/QIQf7I4O S2Y3giAIgrChg3JDWn2CrHyYtHKUbOGbBI038TofoZP59QOM5uniNfddGP48DH0eej8BtUcg lFo0giAIwg6fYGvDyMgIjeUl3njjDSYmJqhUKuvSQWqtGRgYoKenR1xsV4YSbU1tdpDpD1rU BwKC0r05YWzDkbbtdakm18Sxa76cTTkufaNNazYrCtafTWm9n12X2uduUkQKwsOCS6E767PQ GKSn/wXyxgAoKUIoPIDnh1Z4laLOm3AP8VMQ1jQjTwYYT5GqWIIiCPc0Cbh5HxQOacY+VWHf kzXCircr3KIisAmCIAjCZky0dUjc9wWS2qcIGm8QzX+NoPEGpnthvaMNCjfbmXMw/VUYeAFG fgL6Pw3lfRDtAe0jeUSEXX7HgM1QWZNqmGGURSEruIKwK+5u51heXubVV1+lXq9TKpXWCWy1 Wo0f/dEfpVarYYykVAMgU5iGT3MuLVI1XoPNHc6BNmrdgoSzjjyz5Jm7mp26AUnTYjOHzVdf 1hG3c9Jujs0deVrUfLMXHY2vF6Ka8hT5rMNevL4fdrnDZm5VtJOxiSCs3RuZIq1ExLUJXCsE RGATth6lwIuUuNjuA+MpTK14vlkkJbIg3L7jAS/S+L0alzuyyo3Hh6oGelTh1zWlHo9y3cN4 u2MsKQKbIAiCIGzmZNurEfd/kaTnM/jNdynP/DHB4iuYdB6Vt8BdGbQ76EzDxT+Fyb8o6rKN /Qrs/RtQHoegH0xJcn4IW3HVgs3AJkUNQWcBu/r31e9fO4tfy0Wjiz+VWf36lX9f872PYzPI ViCeg3gOb+E0P3JwiYnSRYLuWYjL4NdWRWZBEHYa1uZMTk4yOTnJc889x/79+ymVSuucasYY hoeH14luQpEmsrOYkcaWsFJ0q3nmWJrpErdy+vdFRJViOu8ctBsZU6eazJ7okC8V/bRLCgdb t5WTJl3mznWImzkrswnt+Yywalg6m5AtFGMRNwvZrEPVbl6UvjtpmTnVZs/hMj17IqlRIwhX Rk8akt49WFMvxk2C8MAeIKsv2awmCMJmdzcKgpJh/wtV4k/krMymXPpmG3ejYX0Jgv2asL77 xvwisN1oYOQcubXgHMaY61KVXPn+x1NtrF1cWmG0vu7nsizHWovDoZXGGC0TSUEQhIfl2WIq JD3vsYqzAAAgAElEQVTPkdY+hdc+ReXi/0W08A1UuoRy2foJkI2L+mxL78LJ34G9Pw37/zYM fBbCPlC+CG3C/V6RhXDm7Mf+biHrQHcG2hcgWYSsAWkD0pVCZFs3WddgoqJ2oFde/bMGXuVj r+pVgfiKCIeC1nm49Oe4s78HS+9SQvE7P5dgzCm8D74N2W/A2C9D9ZBc84KwA7G5pbG8zJ49 e3jxxRcZGRm5YQ02fYO500O/YJEqOgs5aWJXY+mIWxnTp1q0FzIqff5Vgc06VuYTPvzGMpf+ okN26uriftaxxK2MzkrG+/9mkcbJlHTBki87TI/CtiA/87EUkjcR19wKxO/mTL/WYfzpmNpg gPGkbxYEAOcpsswnz5XoGsL6/rxfhrGCIOxeoorHoWd7sblj4VKXlcmUxrn0hu/VgUL7u2/M LwLbDbg8v8D7Jz6k3enwxZeeo1wqrfv+7Nw8J0+dZnJ69oY/v3dkD48dOcTw0MDa1+Ik4ZXv vcH7Jz4kjhPGx0Z59pOf4OD+MZlMCoIgPEyTbx2QVh5j+dF/RKt1kvLUvyaa+yommb7xD6Qr cOFP4NKfQ+8xGP8V2PfzUH9Mginc40WYQbJUiFvtC8WrdW61JuAZ6ExB1qQQ3lzx55XXxxeM 1Nr/WNsue8OvafCrUDsK9ceh52jhyrz073CT/56sdIDu/r/HiuvnH/7j/5Mfe2aMz5spBt79 h6jmGXjs7xe1CQVB2FEoralUK6Rpgu/7+L4vYtod99VFOkZnHc45mosJl443ufhGi6jHYHNH llrSriVLcpoLCc2LGfEb+VWBrAPxvKUxm9BZzlg5ldL6+tW6atk9qABuFrrTOa3FlDx1GFlR EITVm0ORpwqbSSiEa56D/RA+q6gcMQSVzX/2KQ1hXWM8sOSApF4WBGFz0UYRVTycg0pvTu9E QNqytKIbPBB36WYDGQ5fQ5qmvPLam/zrP/5zXn39bcb2jfKpY09QiqJ1k8APPjzLv/z9P+O1 N39AEFyfsujzzz/Lb3zpFxkeGsBax/mLk/z2P/5dXn3jB4wOD+EHHnPziwwN9vNrv/yz/Oov /jSe1BsQBEF4iGZaBqcMWeVxVg78fTrDv0i0+C2i+a/iNd//+GwdbFq8Ft8uRJAzvwd9x2DP jxf12kojoOSRLnzsusljWPkQmh/Cyqni2mldgHi2cKRdua5sWqSDvPJy2TWpSzeQbAXiBVh8 E3RU3Adpg24KTafJvWm6xmNyyfDG0ic5+OJ/Qzn5/yjNfx81/TUR2ARhJ064taa/f4DJS5f4 4Q9/SKfToVwur8viobWmWq1elzpSoKidljlc7mhcTvjgL5e5/K0uYz9fJu1almdizr3VYHky ofn/s/fmUZIc933nJyLyqLurq/ru6Tl67hnMDI4BcXFAEiRNUiRFSFxJlPUscWW/le21d+19 ftZb/7FaP+8f3j8se9dP3qfVyhKXWkmmRIsUJR4CCVAEQIA4ZgACGMx99/R9VXVdeUTsH1lz n91zoGc6Pu9lV3VmVFXmLyMzIuMbv99vLKTyfniJ95mpwsKhiJOvVBGOIFq4dujHRT03zxrq MyFRqPHSy+g51iTRZiyWD64OJjkSLZbzj30dUNihWPNxn84hB6HubDvn+IK+7R5CQkNVKdBh T4LFYrk79zsB2aLLxg8X8fNVKgdCgry+LX3P5Y4djWszX6nytW98mxdefJXKQo2OjgJT0zPE 8ZUDTNWFGjOzc6xft4Z//g+/fMX2cqnIqoE+AMYmJvnGt5/jxZ+8ya/+0rM8sftB0ukUh4+e 4JvfeZ5vfe95Bvt72fPEo/YkWCwWy0p7BpcexushdDqI02tolj6Cu7Aff/ZF/NkfI+K2F9E5 4maytKahfgqmX4djfwDFHdD1RLJkhmy+qpVG3ILmKCycSOrFwvHEI61+OvFEixYgbL/GjaQO mfgDqPC6/fuN86uiGFqBQ1g7CgtjuCLFP3p8Ar/w1+Snpmj5LZzWPN78OxDVkzCUFovl3mnn jCEMQ2ZmZti7dy9vvfUWxWIRz/POi2npdJrdu3ezbt06lJ10eGGQwkB9PGbyeJ041MyONGmM R0TjhtpoxNTJBnGgOfxXFWa+H2AWDOYqAVZab8acjRtkNzmY8Pbsm24awoZGx8tLSWjOxlRG A+KKQCxynogcFjg9gnjGEB+yConFcsfJgCiAqQD1+/tQ3bygOOiQ6VR3PG+lcgT5LgUCWqIO VmCzWCx3ES+t6BxIMzvaQqYv3PBEHtw1EicvLgS7uY+wAlubyekZpmfmeGDrJnq6y7z8k73s P3j4qmWDIEBrzeqhAT7y1Ieu+71nx8b5wY9eYWigj1/8wmdYNdCP4yg2rFvL6Pgk3/n+j/jR K29Ygc1isVhWMEb6xP4AsddLlNlImN9Js+vTuJW9+POvoRonEbp50QfiJMRfMAeVgzC/H6Ze gewaKGyD0sPQuQty661x784ZTEJ5Tr4MrWm2ixf42Y1H2Oi+CXPboLARpH/rPxM3oTkBjbPQ HIP6mSScY2syEV2D2Xa9mEneh5Vlb7lYQxRF5/O8KWBbDxiOIaZmif00WlVg4kdw4N9Dzx4o 7wZlhTaL5V5ACEEmk2HHjh0MDw8jhDi/nMP3fVKXRQyxALGg8lbIe+4sqbKiOR1TfS9Cjxpm 3wjYb2bRgaGyL8RMmuvmTYunDXEt8YS7PfsGOl5m9mrA3N6QsFohOLC4HFhyWND1WY/yFp/J t1tMj7ZWxGxry53pElpuDjUI7mpBcMigbySwSRBFMDPt/zMgUhf9v5zbwXOjrndzTNk2pxaL 5QPt/1/2fx5SjytWfz6L8gVBJb7vjtkKbG1y2Swf2/M45VKRWq3BW+++f82yrSAg1jHpdOq6 3xmGIWPjU5w6c5Yv/MwnGOzvw3GSWZnFjjxbN63nxVff4OCRY9RqdbJZO1hksVgsK7snotBu icAtEeQfxMk/SNjxKM7Ce7gL7+HWDiCDqas0TFPJMrMXUi/DxCbo2JqIbYV2zqvMKpA3aPaj KlkxS4fXwHfsCMFNEc7D7E9h/HmYfAkTB6yKJvjMhkn69bfhwAR0fxh6nob8xut/lw4hbAun 4XyyBLMQzLfXz0Jzqi2oTUFzHJqTiZBmbj3hh3EKxG4nximi3U6004FRWYz020v6KhnaNUJH YAKEDkCHCBMidAthkpCTwoSIuIkMZ5DhFDKaPx+C0pirj0UJNLSmk2iVKRIh+ejvwfRPEo/N 0iNQegjSgyA9Ww8tlmX7gC3o6upiaNUgWutrlvF93xrrak3Me5rJYy2EJzCBgUYimAVvaSaP ty5Zd93mpQKtCU08f3vadl0zxIG+I9GEl9yGVRNvvdb+GDMPLGLfnB5B9840a3bnCeuzTKdb YAU2yxKIgyS0q+Um2oecQBUFInUDewkwBY07rAibBuoge8HpFYSHTCKynRtKq1u7WiwWy7Ii DapLUNzpsuHpDnRkOP5qBe6ziXVWYGvT212mr6cLgHfeP3Tdsq1WQBhGNJstXt/3DhOT0wRB QDabYc3QIEMDfWQyaWr1JhNT00RxzMbhtQh5aeXpLpcodRaZnJxmcnrGCmwWi8ViuehhUhFl NxFlNyE79+BW38WrvIFbO4BqnkE1R5DR3JWfa04ky9Qr4BWh80HofKgtsg0kgkS6H9xiIrjF DZh/H+begWCaTfo1nt14lK3+izDSBR3bITdsz8dVMVA9gjn6n4knXyPyB4nTmzja7OTQWIzJ eJRn3kdVjqCa4zD8a4n3YVRrL3WI68lrVEtCOLamEm+01nTiiXbeO20m8ZK7hdCORqUxKo9W 2UQ4c7IYmUOrDEZl0F4Z7XYTe11otwvtldBOASPTGJnCqOyVApvRCBOCbiWiWltYE3Hz0nW6 jmpNooJRZDCBDGdwq+9APAOOi9HRpV6a5y4D0e576yAJe1k7CWe/A+VHoHtPUreLOyC7Fty8 rZIWy7K7TRrq9RqV+TnC8OrxCaWUeJ5HNpulUChYb7aLzVcFqmAum4pgqmCqNz+Ir88YWkEM jduzX/GUoT4V0ahGZDpclHPl+fogxLdz9lpClws3JfGzCiclE0HTuiJZFlv/ahDVDHFw9/Ow qY1gmqBP32vPOzdTxmCyGqfHITpmMHVQZYHTJ4hGDKYJap2AwBAftvXQYrFYlsO93fEkmX4F nwCvQ5Ifcsl0uMShxs+rdt/x/unvW4Ht3LlfxENcKwioVGscOX6SP/n6txgZHaeyUEMAux7Y ws984qM8uGMrzWaT+UoVRynKnUXEZRUnk0mTy2Q4E4wyMzvP2tWr7ImwWCwWyxVor4dW+RmC zg+jWmfw5t/ArbyJWzuIDKZQwSRC1y8dzTJxIsyM/SBZnBwUtrQFt3b4SK+YCDon/4x4/G8x wqPcDPjY2nmK8Rj63feRg5+BNV+C/KaVPGSS5DnTIZgwedVB4jk29gPM2PO0Upupl58lTK/l WPBjfnB0ErdnPcMepOdfQh7/o6QfYMLE66w1DcH0RWLaVJIn7bZ0ahRGptFOFqNyGJVFqyza 6yH2+9BeD9rrIva6E0HNLaO98kUxbBbzWxIjfJD+TQ9FCt1ENUfIn/wPiOhlcHsJst2IcB6i KnMTx+lMR7hKoyTIy7toJoKpnyRLbh30fQJ6Pw7FBxIB2Svam4bFslzaL2OYmJhk75tvMDo6 Sj6fJ5vNYoyhWq1Sq9XIZDIUCgWy2Sxbt25l69at5PN5K7Ld7pZs4jZ+WQNm3w84ubeCl5Z0 dPuXTCY12hDWNXrh3hKpVnqNM2FbHIqtuLhk4rsvLosSuGsEegGCaXPvenFlEqFMTxvM2GV1 U5pLnR1kIoyLVOLN5g6CXhDEI8Z6sVksFssHjJSCYr/Pti90EocG5Qm8jCLb4aC1YeihPPku 78rgOPcwVmBbAr7v4XkOrVaA7/t87lPPEMcxL77yOt/46+9zdmyC3/i1L7F61QBRFCGEwPPc K3rsSikcR6G1prKwwIHDx25pv0bOjqGNplavc+T4KZSS9mQtkvGJKaIoYmpmliPHT1qDLIGJ qRmCKGJyasbacJGMjU/RbLaYm69Y2y31Gp6cohkEzM7O38c2VMBjCPUwKnUWv/ES/twLZKLT 5NwGeV/jO/pKUSJagJk3kgXAL0GqD8Iacf0s9cITVFM7+dHJKvvefoctAy4fNg16pv4vMvOn GB/6TRZa6r6ypABcZXCkwTn3evGiDI4ESZSEZgznLgrXOAcLR2H6deLmHPV4gXDhzyBu8gjj PPDYFHl3H60jMcoNSKWBt//Vbd1/bSCIJK1YEESCViQIYklg0kT+KqLMOqLMeiJvHVF6GO0W k9GIiGQ5PwDRBEbuehe0UF3LYPRTVL6XSuFXqNQ14dwh9h75Ax5fU2Goo0WHo3GvV+0WjsOR 34Mz34Sep9GDz9LMPcxsw2GhpVak/8HE1DQAM7PzHD1+iupCzTYOi+TUmbMYAzMzcxw5dpKZ 2XlrlEVy4tQI2mhmZucYGR1nZHQMIRTdfQMUCgWMMXgzM0y9/z6tMKbc3cdcZYHvfO85zo5P sn79BjxvZYV/jaKIk6dHCJvRst9XU4X5F0IOqBmCdJXSOoW46F5dn9ZMnQzQk/fGXTiua6bG KsgTNWYnoiT05gokmtKcPThPek4QVXS7z2m56esigsZ8yOhIjbgliBsScTdsKCA2Gh0B8b0j E+uGIVjQGCUQZSAFsldjQnGFwEYI4UKMiUT7s5qgCkYJZKdBY5bt8esWVKabnDw1hz+v76qS 32oFLNRqnDk7RiaTthfpEgiDkOpCjdMjo7iuHUJfUtsSR1SqC5waOWtnsiwS13EplToxWt9T +y2VoNibIl+60JcXUpyPeJDKuSglkPL+qRDCGGOnJ13GO+8f4nf/8E94fe9P+fpXfofB/t5L ZlCeGhlldGyCcqnIhnVrzq8PgpB/8Vv/lu//8GX+wd/7Rb74+U/z9W99l//3v/wF//tv/Us+ 8dGnUPKC6PX+oaP87lf+lP0HjvDLX/wc//O/+Xe31nDHEUHQQkqBo+yNf0k21JpYa6SUl5wr yyIeULVGWxsurf4ZTRxrpBAoZR9ob+0aFii5smy4uafFxzZU+dSWCg/0Nch6ERKNFPoG1yws NGGmLnlrJMO+kQzvjmU4PJWivxDx649N88TaOv/6uSG+d6iMNgJzD/SMRVtaSfbWgDDn3yfb DL6j6c+HDHQE9OZCevIRPbmQnmxIbz6kJxfSlYso+NcOy2iAVggz13E+S7lQzMDSbontvTUX 771AG0k9lBye9Dk85XNk0ufIVIrDkz6n51zCe2CAZbAY8j/umeAXds1weFLxrXdzjMy5aAOD HRHP7qyyoTvCVcmxSJHUZ3mdxDq1QPH22QxfeaOLvzlYpKVdDPKeqLO3DWMIwhClZHIftF5A SzChIQxDlFJJX8bacAk21IRhhJSSOGgQNuv4mTyOlzpvT2M0YbNO0KiRyhaQyqFZqwCGdL4T ucKeZ4wxhLUq28d28OHoF+hnGLXM58OGbotjPe+wP/0ax9RB6qKBRLIzeoQ9k8/SUelCmOV/ /cQqYrR8gmPZd9g6/yhds4P3xH7f9n601MwVJmi4C/TMDeGGNjfioq5hDPV0hQOlN0jpNBum HsIP77yoETotaul5UkEOv5W+InLSsr3uZETLbeLo5D4XqZCW2yDfKOJE3iV2jZwQIzRu6CMQ xCoiVAFO7BKrECMMKnZxI2/Z1QkjNdP5MV7u/CbvOXuJuHuTKML2hH8lpfUKtza0NrwHKRYL fOnnPsf/80df55e/+Dn+8a//CuvXrbaGufHjMAszAa/96Rj7/tMp9hee5+/+m6fYs+fDdyzv s1VhlsCq/j4G+3quuDF4nsuTjz7M2++8z+j4JPOVCtlMhjjWVKs1Lg/E3Wy2aDSauK7D8Noh /vGv//It7deR4yf5zt+8wEBfD5/4yJNX5Hyz3Jijx0/x+r532LF1E9u3brQGWQIHDh/jp+8d ZMfWTWzdvN4aZBEcP3GGd94/RG93mcd277IGWco1fOwU77x/iKHBfh55cPuKOnYpIJKG74WG 18fn2JA5zJbMATZkjlx/MMVAvQW+0uxeVeOhwRqxFkRG0TQ5Ur5LueDwzz+b40Mf+RhTUS/6 HpjRLEVMRi6QERXyco68mqMgZ8nLWQpyjryaJSsrSJGEnJGcy/eVSDHy3Htx486bNjcuE+ul CWwNnaISdTAfdTAXdjATlZgOupgMu6lEBWIt0VmIM4LB1dBvBMZwT3huSQHjXoUX5g7wYOlN /uUzo21bCqQwTEc9vFh5mMP1jXgiYFP2IJsyhxn0z1zzOzNezGOrF3hwsMFYEPJS/XOMhOsJ zcoZJKzW6vz+V/+Mndu38vDObeRzNsfvYpmdq/DVr32Th3Zu4+Gd28ikU9Yoi2R8cpo//+Z3 2bl9M10dKYQxrBleTzqd5tz05SRMZIUjB9+nf3AVXd29jI6cZnpqkk1btpPN5VaUzeI45syp kxz/5jScvTf22U15bOzfwZqtq2huPEmcSlyjnWoH2VfSiBcFtO6B9qhP0v1UBx1rNpM6kEP8 gBUZZk6WBIVHMuQKDvLH8u47t9/jCFfgbXVZ+2A/MnSRz98FG7oQf7hOPDwBx1x4I72kPIR3 DAWmrEGDmJVw0Zw12SVxex1kLIjzIeHwJDgRvF2A9zhfVggQmeQ6Fcfbk666BU6HQlYFoqAw 0iAX2vYOk9/FNUkHvyUu+d3zpAwmZxDzMvnMTRxLcrNexPH3GExHTG5Nikd3PMCu7CB3s5f+ jW9/n0Iux45tm+juKtmLdAn8+V9+j+5SJw9s20S5ZMPQL4U/+fpfs6q/lwe2baKzWLAGWUy7 bJ0WbqFRbr/cJeXLCmxLquCCa4VLcF0HKSXaGLKZDL3dZaIo5sSZES53FpyZnWN6ZpZcNsPO bZvZvvnWBJ3nfvgSzz3/IkOD/fzqL/2cDRG5BP7mhy/z/qGjPPrwTn7xC5+xBlkCf/nd5zlx aoTHdz/Iz332k9Ygi+D5F19lbHKKbVs28uUv/bw1yFKu4Rde4uz4BLu2b1nRNlRC48kWvmgw ZeZwK/vwqvvw5n+Cak0kMWy4IPyca52UNEnrpgygyVLBcwQ+ms2ZAwylRohkNsl7ld+c5GUr bEzyuaX67s7BmQjCeWiMQXMseW1NQXMCWpMXlmA28eAjRooYdcn7GCmi63pC3XS/TVwlR9jV ylyjSTZOntjrJU4NJovbjfb7iL0eYn8QLVPERpExEh9Fl1FExiEyDtrc++28FBpftpCiRtXM E1RO8b/+2/+DLTuf5JlP/CybulazRvsIDL5sIUSd6WgMf+5l/NkXcWqHEHH9kn60koaMjFjt jPNs6muEfT+DWfdlKO4A4d731//YxCS//9U/Y9f2zfzql36O/p5u2zgskuOnTvPHf/4tHtqx lS//8hfpKnVaoyySdw8c5hvf/j4P79zGzi1rqVWrPP74E/T09Jz30g/DkFOnTvFKOc/u3Y+y evVq3nrrLU6fPsUnP/l3KJfLK8pmYRiyb98+fvcnX79nBDaqAmfCZ/Vn1/DAz++k0OsiBFQn Q/ZF84zta2HuAYHNG1Bs/tgaVj2yhaM/qHHqjSZmBQpsqkcy+Fg3mV7F0aMLaCuwLa5PmIXO bRl2fmo7cRMO7Q/vuMAmirD26RIDHy4z9rphMjCEe4HGcrm4wN+WCGvhO2Dm2uvT4A5JCjtT mBa4ZZ/+p/NIB05EhtqpdtkURF6EHogoP5ohWAMqBzKlMCjCs+CvdpA+RBUIp9r9Sx8wAt2A 6Czow4mt5FCyXZ8G2Stw1gjCA6BP3djOcg2YevJdN9XHXQf+AxK32yM73MVHPvpR0h3c1RB5 L736JoP9vXz2kx9l2+YN9iJdAs/98McMrx3i8596hk3r11qDLIG//O7zbBhew7Of+QTr1qyy BlnMs7KUKMflq1/7S2uMRY7RCAFuViL9u3PTtQLbIqnV63zn+z/i4JHjPP3EbvY88egl248e P8l8dYFSsYOe7jI93WX6+7p59fV9BL/+KyjHQZDMUDx68jQzc/M8vvtBOgr5W1amC/lcku/N dSl1dtgQc0sgl80gpSSTTlHqtLNTlkI2k0ZJSSaTtjZcbP3LZXAcRcr3re2WWv+yGRylSKWt Dc8RmIgotZpW6WlkOINTP4q7sB+v8iZq4X2uN2VTEqPaz4GuaOKpJohpCKZh/iDU8zCdAycH Tvai1wyobPv9xcu59ZmkrFBXecqMIaonOc7O5ToLZpOlNQ3BTJJPLm5A3IK4mSQ3OP8agGmB Cu5O5+1cx9fLEIo0RvhU6gFTcw06imVKxQKIGYQzTZhZT5jbjvZ6iL0uYn8A43ZgZAoj0xiV ar/3z687l/lXtpf7Vx4yBCamZlbxt8f+EH+4nyC1hlShn9Tl5fQQUXqYRtencRf2k5r6Hl7l DWQ4d2knV4QU1AxUn4NTZyH+Agx+PhGI7+drPkyu6XQ6RanYQVfZikOLZW6+AqJtw05rw6XQ 2ZFHIMjlcmzeuIG333qL48eO4LmKXC6H1prZ2VmOHT1Mb083q4cGaTZqTE9NsHbNavr7eigU VtYs5zAMKXbkkc49NnlCCySKXCZLuZRBSoEbN/EzNVCte+IQpCfI5FIUi3nSuRChWpgVmMVT OOBnXDI5F+Ha/J2Lr0jg+op8IUXoGqQbccez5qjknJW60/gfinFVwNlWSPjG8qi/Ig0qJTHa gDTQdqoXKUitlQw97RE2DY0JTb7goVyBk26ATNzExGrNjD+C2NLk8Z9/mDg0KDeJ1lAdiZna F9H3lEu2S6Jj0KFJoktEMHc0Ym5/jK4YdMbg7RKUn3YwGqaeizAhOAVBqG58lkQevEFJPGcI Dt/YtqIPCh9V9O9xSZckfl5S6nPx0nc3ypRSCs91KeRz9tl4yTaUeL5HRyFvbbjUW6OQ+NaG S7OdlImOYD3ZFm87JfAyCuGxOM/jJWIFtjbjk9NMTc/QCgKOHj/F9MwczVbAu+8fYnxyCiEE a4dWkUmnmJuv8MOXXuXU6bMo5bB+7RCtIGTv2+/yw5dfo6+ni+2bN5DNpFk10Mczex7nj//8 W3z1a9/gmT1PkEmnePu9A/zwpZ9Q7Cjw0aces26fFovFYrljoyXa60J7XQBE2S0EHY8SZTeS HvtzqByi1fkgTv0oKpgAc1nvQ1yWfshoCKvJcvHsWCFBehct7mX/X7ZN+cmXXyGwadBhW0Br JMJZ1IC4nixR47wH3p2xl0KrDEYV0E6yGKeAURmMyp5fkjJpnNphvInv4Pl9LOQ+QuCt5rV9 7/OjfXvZs3sTnxzO4DZeI/aKVNf8D8Tpde3PZzFOB0a6to6er2gOWuWothSRkVw9S7DAyNQF j7/UWqLMRrz51/BnfohX3YeIL5u23RyHiTmoj8L8fhj8HPR9HJRN9m6x3I2BgYGBQRyl2Ldv H9/97ndxXRetNUEQ0NvbyyOPPEI+n+fYsWNkMhm2bt1KJmNDm94rmMAQ1g1hQ2O0wSzD/Coi D6SBBpiqPWeW+6wHJUC5UF7nEgeGqVcjwv1m+YU59UD1CGQ7+q/XLeja5NKqacYq4dU9u7KG 6ewZVP8cg7uewJjkeHVsmPBDFkZiuja6FAed5PPtvmOrpgkbhsphjVAGkQK3W1Da4mBimNsX E44uToQU6uYDIciyILdW0veAR7askBKkY1O4WCwWy11tH++i1GIFtjZ7336PH778E8Ynp5iv VDl+8jSzc/P8wR9/nXQqBQJ+49e+xEM7t7H7wR0cP3mGN956h//0+3/EQH8vYRhy7MRpXNfl s5/8CI88+ABSSnq6ynz64x/h2InT/MVf/Q3vvn8Iz3U5c3YMgE9//GkeefABewIsFovFclfQ Tgfa6QBjcGqHcGunEIUd1DufRjZHmBx5j4WpE3TnYvo6YlxZRcqbeAA1OhHD4uayPn6j0qlL lQsAACAASURBVIlopi6IZ8n/ObSTxajcBQFM5S6sl2lQ6cSz7NyrTOEuvIsMZ0ktHKXIaVpI Sn6FTT1NVqfP0KEdHD9Ls7yHVvnjGGlzOd3W+uwWE8E4vYYou5lw7hW8+dfwqj+9VIjVLai8 n4QVXTgGteMw8DOQG+auxuqxWFYg6XSazZs3Uy6XmZycZH5+HoCOjg76+vool8sIIdiyZQtb t26lVCrhOPYx9Z6hAY3RiLFDNfycotDlXWOCxAeDXCVI71L43ZLa4YjWy9qeM8t9hxAC5Qnc rMDtXH79GukKUg8K/D5B3DTEtWSd8gSekaQ6JY4rrvQbVRDJEOM0cS4K82W0wMsK0t0SNy1w fXFJd07HglSHIDMkkQ7UPY1wQHkCE5k7lpNHlEB0gNsPKtU+J5ftm8VisVjuP+yTSxvfc8ln MzSbeTryeVYPDlxRxnUdhBA8sHUjvucyONDLgcPHmJ6ZQwjYsnGY3Q/t4MOPPUJ/Xw8AqZTP 9i0b+Uf/7d/lr5/7W0bHJ2g0mqxZNcCjD+/kyccepmxdZC0Wi8Vyl9FeD2F+J+7sKxTjo0wV nyXOr+fkKY8TYw12DmlWZwN8E6LT3cReHzKaR4SzyasOYNmFT5IY5V/kZZa76H0WozKJmOaW 0G4n2ikmr27pgtimsovKhBtl1lPv/0VSU89RqP4UXT/BQ4UF1m6epqfUxPM2EXQ8Tav8jBXX 7nB9bpafIczvIMzvIJp+Hm/hHVTjOEJfFAY1mIXxF6B6GGqnEm+28mOg7LmxWG7b9ag1zWYT rePznmpKJuEiM5kMYRhijMF1XZRStFotfN+nt7cXIQRC2JHIewlTheprEQfFPPNnAtbv6SBX 9pbN/nmbJKt/JkO+z+PotysEPw2u6sVmq93FJ9Wa4F4luYcmIRiXRR5BD5DgdAo6dypyfYqp d0MWDidCt5CQLSn6doCfk9RmbjKOl4Bct2LwUZ90h7xCwHI8QXnYJVNWBAuakR8HNM6a8591 chAXb7N3QwacYYHqAK9H3FXPCYvFYrF8sFiBrc0zTz/BM08/cdPlt27ewJZN6wnCkPlKFYGg s9iB41yZ9yyd8nn04Z3sfmgHs3PzaK3J5bKkfN8a3mKxWCwfCInnz2M4XcfITn0XZ/o/03TX 0O8u0Co0KWUVmUwW4e2iXvooYe4BVPMMqnEC1TyDDKeR0QIiXkDENWRcQ8R3IF+HUBjhYqQH wsVIJ3kVLkgneRVukrdMZRLRzOsi9rqTXGduF9rvRrtdaLeEkbe37dVOkVbpY4SF3fgzP0QG U0zM/ISXjx9kR3EPO9f+N4TZLbf9dy1XQxJ7vTS6P0+r+BTpyW+Tmn4Op3YQGU61RWESz7ba CTj4f8LcO7Dpn0D5UfDL3LEpzRbLCqLZbHLkyGFa9SrNRp2RkRFGzpymVrt6G5FKpdi5cydr 16614to9SnzIMD8a0hzRFId80oVlci+V4HYKysMpCr0ep4sLV3Yz8qByAjct7YB4BFFDE9Ti u5KvxHKf98qGwNssUO0UzcW1inyfQ3Ukpu7rJOSiBD8v8bNJXrXG3EUephna0eQNl6u+QkC6 oPBzEqmubDeUK8j3OOS6DGHTMH86pjmRRDYQEtxOiY400hPIvEBnFhFSM5MImHhgKlzyOVUC Jy/AtV5rFovFspKwowi3gBAC3/Po6SrfdHmb0NFisVgsy4UovZaFoX9I7PeTHvszUsHbPNwx z/rhGplsJ+R3UO39OVqlj1354BqMoerHcRrHcerHcBrHcBrHk43m3INwezEXPxgbhLnyQfnS BlNiUCAdtMxg3GIinDkdF0I6ugW0yrf/LyaCmlvGfCB5tQTaKdDo+VkAXnqjj6+8/Rf8yoYP sSW/y1a0u346FNrrpjb4azS7Pklm7Gukpv4Gp360LQK3654OYPR7UDkAW/4nGPgMZIasN5vF cosYY9CxBmMwJB5tYRie91y7/PlIKXXFess9eN6rEE1pWtWYKNDLJkykaOc+ko5EXDYQL/KQ flLR//E05bUplLOyFbZ4yjD1aou5QoA+a9WBJV0HGlb07exc+sw6OEOC8pMO0hcEsxrpCvys oHNYJaEsswLHE0gBOAJ9eRroAoj+kNZCncw1rm0lr11PpQJU8r3SubDOzyu6HzSEDQMCGms1 c/ti6i/o879rxq59iLIM2Sclfrdk4UBM88cXxDkhBSjrEWuxWCwrDSuwWSwWi8WygtFuJ7XB L1Mb/DIymOTlF77JH3/3eT78sZ/llz7+pWt+Lvb6iL0+guKV3t8irrfD8kXJqwkRJoQ4RBAi TAQ6BMwVkzsNEqNSaKeT2O9LMopbLEsk9georvlntIpPkR35CqmZHyDihWQE7By1k/DWb8Lc T2HDfwedD4F0rfEsliVyLudaKlsgnc6wevVqtmzehNZXz30lhMD3faS08bTueSKIAo2Olp/C cNXx7jR0PuSx9dMleoczNKrRivY6MRPQ+HGiclwtjKblBvZrQlQzxMFl9V+CXAOmcX3hZslI rl1v295WZuYuGCADanUiMMXHDV6/YOBxDzclGHktQAhIdShWPaIwcSJuuamLwjtedgzuWgEb 68zsP0tadNyWXVSeoLzOobTmwlBofVZz2GnQeEUjy+AMCAJMcq4yoAYv+45+Qc9TLp3DDqdT LVrvRssjHKfFYrFYPjCswGaxWCwWiwUA7XUxHq3izEKBamvpA51GpS/zJDMXOazd5KCbEO0R A4vl1gkKDxOl19Ca+hDZkT/ArR26tEDchONfhcpB2PxPYPUvWaNZLEtESomfSiGkQkqJ67r4 vk+9XieKIowxl3isSSlxHPtYej9gIogDQ9jSmGj5uvGIHhCewAQGlRKksgrXVzQXInsOrbC2 dOqga8kcsovnhxnX4A1LohmIxq59Xch17fLzNy+IybLASYlrekypdQJvSBBXDPEMmJpBn75D 11UKnP7k2PVoEnXbSwu8rMTLC5QrUCoRuW5GyXbKgjgTEcomULi1fZNJTjQhkvxsF4eVjEOD kxLggcgJnC5BeCrxwJZl8NZLopn2eZMgfHAzAi8rkL5AuEAJ3C0Cv08g06BSyXmx80YsFotl ZWCfZCwWi8VisZx7/Ew8yIy4xQT34sr/bagUywdatRXa7aLZ8yxxZgOZ0T8lPfENMBfFI9IB zLwJ7/5vMP8+bPrvwe+2trNYbpFGo8HZkTMcPXqUSqVyRTjIVCrFww8/zLp166wX2z2OqcPM oRbSEVSOh9BYnvvprJK43YLmYX39pqMn8eqyWG76GmjPKbuk2ytBZgWydu3OtSiBt16ABN2A 8LC5KW83mQXHF1fPH5gBf62g9xkHIQXTeyOaZzRBez+cYUE8bdDHb8OBZ0D2C2RagIbzDxIi ybHWs90llZeLC0yhaM+1uzWxXggSscvn2s8jApzVApm9LHiGk9hY1JIyKpOco8sFTXe7YOAL iVebUCClwM8J3LR9BrJYLJaVgBXYLBaLxWKxWCz3P0KinQJB/iG000GU3UTm9O+hopkLISPj RuLFduwPoX4GNv1T6NyJHR2xWJaG1prR0VF+8uortFot+vv7SaVSlwhpvu9bD7b75XyfMUx9 r8XsGwHhiFl23lBCgugWqILALUtax68tsKlNAn+9pHlQo4/ZHIGW24AkyVF2jXCCMi2QHpCH 6Iy5RFYSpSQEJXUuyXMmHK4urtH2KOsUlDY6uGlJfUITzhtE1iCyAncg6dvo40uv3+f2Sw2C PywQDpgARFuoEgL8jMBb6yb5ENUH0J8SoDwQzvV/2+0Vibh2UTHhi0sEN5UD6V0pmrldgt4H XLo3eOfLC5Hkf7RYLBbL/Y99krFYLBaLxWKxrBiMShNmN6PdErHXRWb0v+AuvIuI2yNeOoT6 aTjzDQhmYfjL0PtxcDLWeBbLIonjmPGxMRzHYc+ePQwODqKUQlw0/d/mYLu/iPYbIpanIOXm JP76dj27QXWTOYHXJQlGNNqeVsttQPhJyEEN1xTZuEqEdGenIPOAIJgyRGOJkBVXDeEpQ3qj JFWUSHmlkKPWCDJDEj8vcdOC3ICkNaUJ+wUqDzLFLUVjF6XkN2QaUuskXpcgnDM4OUFqSJDu kyhfIJRAftA6k+CaYTQvGOxS7zU5BOkHBNnVknghuQsIdfX00MJNQl9e05vQYrFYLPc1VmCz WCwWi8VisawshEPs99HoeRbtdJKe/Bb+7EvIYDLZbjS0pmHkrxORrTEGg5+FVB925MRiWQTG EMcxPT09DAwMUCwWrZBm+cBQnsApCOKFmxQApfU+sdymbocEp0PAMAQ1gzknsF3Ho+3c9swO ydrPe8wdj5l7L6Zvj0ttNGZ2b0zvky5dG9x2XrOLfi8LuV2SgcdcCn0OUsHAI17SvTkb3rK4 du43vIFETOt93EUqwfS7IV07XQoDCscXZEvqxsLWMsXbLOj/uEu+TxHMtgimrSerxWKxWK6O FdgsFovFYrFYLCsQgZEpml2fQntdaLcLf+YHOI2TF3Kz6RaMvwDNcQimYfBnIb+BJIaTxWK5 EVJJOkslJifGqVarFAqFq1+NQlzi1Wax3PY7vkzCtUlXEN/Aw05kuDIX0638dj4JTWkWjM3p tpLvhylQOYHoMIgOkHmBSEE8ahApkD5IPwk/KPMCnTHIMqT7BZ1rHKKGoX5WUxhUGG2oFjS5 HkmmKJEK9MWulg74XYJCv0MqJ5NwhX2Cma4I4ZLkN7tVnOSY/JKkY5UDBqqnYwoDiq5hFynF PSGuCSGQKrG/aHsQCl+QGpJ0rnXIlBROPjgvsAnVDjdrmyyLxWKxXGgSLRaLxWKxWCyWlUtQ eITY7yP2ekhPfBOnfgShmxcKzO+HA78NrUlY/UvQsQ2cnDWcxXIDhJAUCgWOHzvKq6++yvr1 68nlcpd4sSmlKJfLFItFK7IlVrNZH2+3RaUgU3RZ/aEcccsw8WrzOnUWer6QontbirlTAQtv RXALIS9FD3T8HZee3SkWzkZM/FWTaL/1hFmpyCyUn3UoblBIV1Abjakc1nTuUOQHFEIlTvRz myKm/jYiHAGvQ6BckXiciba4c068ElxV6RG+wM0LlHeuTOKQeTtvsTIvyG9R9D7kkitLDNC7 yyXTqZBK3DMClPIE3dtdsv0KHRhmj8YIqel90iXfq5LLv21DrywpP+BQXOOg3PYx2lFVi8Vi Wbb9P69H4jfVHf8t2xRYLBaLxWKxWFY8sT9IbeBXiVOryI58BXfhHURcu1CgOQmHfgdqZ2DD P4DyY+AWrOEslutgjKHZbDA/P8+JEyc4fPgwuVwOx7nwGJrJZHjqqacoFAoopazRLLcdISFf 8sgUXBYmQqbfbl2nrKB3Z4r1T3Rw6MU5xrzGLf22LAqKWzyGn+pg8kidmTcCov2xPSkrrhIm 9VBlBN27HFY94iMkjO0PQYQMPenT0a8QCHRsSJckC8c04ZhGuIlX26LrnicSL7LF7mpfklNM n77B93dAcVjRu9UllUsmTWQ6FNK5t7y73JSgd4uHjiGoa+KohVTQs80lW1bUZzRCJJ5rqS5B z3aXjn6H+myMdMFZJZB2ZNVisViWX9MrwO9S+PN3Pjy9bQYsFovFYrFYLBbAODka3Z8lTq8h d+o/4k//AKGDCwXiFpz6Giwcg83/FFb/IqiUNZzFcs0HW0FnZ4k9e/bw6KOPXjUUpOM4lEol m5vNcgfrYRIeUjmCdNEhu9qhOX1tkcvxJV5aoZzbUyeVJ3DTEiclb1vYScs9hGPwSgKvJJC+ IFWUeBmJlJDKCzI9Ej8n8FISBOgoEX2kDyrPksQ11BJFrgy4awUyC81pc0V+ODkEIgUiLcht k/gdEjclkU7yY/ei0CQEOO0cdkYLpJuIk44nkCoRz1Jdyb0gVZZ4mcSjUCqB3ynJbpGYyFZz i8ViWZb9PwXCufOzPqzAZrFYLBaLxWKxnO+JK4LcA8yv/y2yqXXkzvzuhZxs55jdB+/8a6ge hu3/ClTa2s1iaWOMIY5jMAYpBOVSibVrVmPMlWHx4jgmDEM8z1vW4SG11hhjkFJecz+NMeeP 0YqFd/GWnQfS3FRuM6EEfRuzGANHvj/PQkeEkDYgp+UO3xMzmq7dDqX1LtKBTFGiHEAICgMO fkEmHmCXVUWVFjjdSwi1KJeePzARz0BmBCJlMJcJbM6QQGYgtUqy5lM+nWuc5FjuiZvFzYuO ol1WAF5aMvSkRxyCmxGk8hIhwc8J+na5KBem342xsX0tFotl5WIFNovFYrFYLBaL5WKEIvYH qK36+8SZteRO/AdUMJYkRoFEcKufgmN/ALUT8OC/hVQf1jXBYoEwDJkYHycKW2hjkEqhlKJW q2GMIZvNng8FWalUOHjwIH19fQwODi47YSqKIiqVCvPz84RhSCqVolgsXpJHzhhDo9Fgbm6O Wq2G67oUCgUKhcIloTBv7gdrKKwrxE3fqvOg1gmcLklwSKPPXD+3mZSCzv4UCDizd4HUOoWb vjT8npD3Vng7y3KuoGCUQadiikMOvZvc87nTRPtWly0psp3qqnVO+eAUxPmyN4t0wenmqp8T AoTT9jSTAuEb5LokZxuAaSXX0FWvpAzIXBLm0isLyutccl1q0fv3QaFSiTfpjS5wKQUqBVIl 9wY3Jeha74G5ILwhEuGtc8ilVTHMHbZhXy0Wi2UlYwU2i8VisVgsFovlcoQi9ntodH0GrQpk R34ft/oOQjeT7TqCxiiMfBuCOdj2m9D5MDgZazvLiqbRaHDw4AGCZg0dJ4OOURRx8OBBWq0W Dz74INlsFmMM9Xqd119/nd27d9Pf37+sBLYoihgZGWHv3r2Mj4/jOA5aa4aHh9m1axflchkh BLVajffee4+DBw+idSLCd3Z2smvXLlatWnVzItvY9+H4f4W3XsdvbrSV6CZxt0u6PuLj+IKx epPgBgIbJDnWpBI4vqTzAY+ujWm89AWBQzoiCeVoPdsst4oyBL0NgsEFUh1dSHWlWHZOrLl8 pZeRFDc6ZPoMuX6JcsQNvXwF4KYFnVsdpBcjXXFZ3Yd0SdL1mJPsh4Bwk0SHEFYNjbOa4MzV hTky4D8mKD6siBuJiCfUHRCj71QTIEC6SWjH6+2yVIJMl8TNCtyUuPBZcY3vlJy3pcVisViW 4zP93blBW4HNYrFYLBaLxWK5KhLtlmiWP4ZWGTJjX8OfexkZziabjYZgNhkc1wGs+3vQ90lI 9VrTWVYsWmuq1So6jjFtP4g4jhkdHaVSqbB9+/ZLytbrdaJo+Xlt1Wo13nzzTU6fPs3u3bsp lUqMjo7y9ttv43kejz76KI7jcPz4cd58803Wrl3L+vXrqdfrvP322+zdu5dcLndeiLsqRid5 HY//EdH8KEEkCbUdqb0ZRB5y2xyGnykQtzTT+wIC9E1/XnmC/p0Z1u4ukCu658dflCtwfWm9 2CzXr38lEFnQ01yRp+w8DtQ655lbfZxC36ab9vSSEnJdiqEP+ZjYoFyReF7daJ9k4hG36lEP 6YXowFzqnakEpTUuuW6VhEsEtAYdwsyJkLMvhUQzV/fEkmXI71AMfdinMhpTPRXfdk1JAK4v UP4dOmdXEzOvcl/oGnYxOgkHabFYLJZ7ubEWOBmBF9z5CXxWYLNYLBaLxWKxWK6DUTlanU9j VBbtlUlNv4Bqnjq3FeJmIrKFVWiMwaovQN56oVhW4sWiIaqj9AKFVIQjLghncRwnudmW1f5G ELdAt9qvAZgQE4fUxkY5ffAVVvV38UB/g2x6ki5T5dQ7Zzn73jiN8lkcaTj8yl7cyiy7Sppe OU6YjojLY/z4zcOczR6nuHktjuslcdmESmKzCQcQiUB/6HcIaxPU0w/TyHcQioatRzdDGpys IN/l0qrFqNRF2wpgjE7i3F1DKRNKkC4q8iUPN6UwBoRIvNeSMHLWxJZrI/sF3hpBcMycD6uo xy8r5BhCv0U9M4WXXsTgnkg80ZyUatdhiFrmpj7q+oJMSeHlIpqzl35GCEjlJH62ne+tvTmO DI25GOmReJBdTad2wM0n3l1Ry9Cc0bf9GhEiEbiFI8D7gM6rTGx07jxYLBaL5d5ECIHrC3K9 DimtuEbw49uGFdgsFovFYrFYLJYbIV2C4uMYtwPtdJKe+g5O7eCF7UbD1CvQmkqWoS9C8QFQ aWs7y/1PWIWFo1A9BGOHyVdf5pn1s+xM/xh/YhV0bE/Eq9uJiRNRLG5cEMhMmLhj6KD9etH/ JoQ4BBNc2B63EoE8brSXZlIuCnBmq6TnDhGFiuD9V/FT0JqrEZw8Q6GgEIdfptpoMf3uGL2d kuLZV3GmNUobBmY15uw8Y2++wsagjJP2Lwhrwk3iqyEgmIbp12iIIZpmgbBSQcZFW58WMXiS LJeuV8Mwr2YxxtDTNXhVD0LR/ntukxDgZxWrdubwUgrlSGtgy4UuwBDggD4OZEB1QH6rJOw3 GAMqLZh/Mb6oboIsxlRbU0SquSSx5hKPK5HcNqR7ow9dlCfsOtsvughuOsShEEkIxeKQQ6pD XpG/8PZd2HfmXsHN7q4V1iwWi+Wex/EkfZuy6HSBYz++87M2rMBmsVgsFovFYrHcJGF2K3qg A+11kRn9/3BqRxAmvFCgehiO/N9QOwnr/z6UdoNnB8wt9zFRHSZfxJz6r5jpN4hmK3gL8zw0 UOUh/2/xDh0j6Po41HpBl679PSZOBDAdJjkOTXiZSHaZp1lch2A+yYEYVSCsJevierJPcT0R zaI6RI32+tqF7VEt8WC7CgLIB7Ddh7ePwavzUM7D6CzE87ChGzLzMD0NzVko5EFVgfY4ut+A VAgL4+MEPUdIXyc1ozHQqh4lDo7CiIsbftHWqVtElg1VZxKtId29GuVdJe/SVUQIP+PQvyEH QKseW0NakqpSAmetQHrQHE9mwAsf0j0Sv2gQSuB3Chqn9KXeX4WY+eo4RjVvfR8EOL5ApcRN i0SLCnMquHEIy3aZQo9DoS/x9ronzp8AJyVuLE5aLBaLZdmjtSYIgvN5j6/Xv852Q6dQuG9z wzymt4oV2CwWi8VisVgslkUQ+wM0+n6BODVE/sRv49QPI+IG50NPBLNw+uuJyLbln0Hvx8Dv toaz3J/MvwsHfhs9u59Wx+PUBh5kIvUWP/jJi/RveYRPdI7jHvxd9OiT6OyH0PVRYjUPJkJX xjCNcagdh1kBegHCSiKche0lmE/WtSYueIi2phOvOXPncrcpCV0FkALeOgEdGZhZgA19UMol g8uRhliD5yblziEl+C6EMegbRKSJzZ0OWrPyEAKMMBhhcFISL6UuURuUI8j1uPg5hbjoxAmR hI685vf2AA0wVWvjFVOX+iD9IUl6lSCYNrQKBlkUSF8gZFJfhGwLOGnQtcvq4SLyAt5wXyQ3 lcdNCIGfk2BAqpsoD7gpSbpPUj+jCWfMjffjTtlbgpNOHH1v35eC44F0rGuaxWKx3Os0Gg32 79/P3Nwcxty4Bz0/P8+pUyfZtm3rHd0vK7BZLBaLxWKxWCyLRKsczdJHCTPDFA//L3iVNxDR AueHynWYhIx84xhs+A3Y+i/AySQ5mCyWDwyTTOk8L+nc4P/Lt53/mgvrzIk/huoxauXPUCt/ nsZ8lVb0LpV6zJFxQ+/gk3TMV5g4+iI1eZQzxXeYd+vQmmViYoKFt0chjmFcJ/l/lsP1bWCy Au+eToS1D62HbAqmF+DwKOwfgVTbK0rKc6HcLnIZEYDQV/EguXIg4OIocJbbz+WihBCQzrsM P9qB68ubHnSXqwSpHZJoyhC8rq1hVwjuWsHAJ12yfYqzPw6opTXualAFLgnfuGiPsTuI8gTl dQ46Bj9zYzVMKEG+VzH0uE+4YJh57erem3f8+EQifmf6FbIrRqUhVvr2iZT2RmuxWCz3PHEc Mzs7y/j4+A0FNmMMCwsL1Gq1O75fVmCzWCwWi8VisViWgnCIU2uZ2f575E/9R9Kjf4oKxi8t 05yAA78Nk38LD/27JC+b9K3tLHcfEyXeleECRNUkpGJUSTzBoipEC8n7c9ujc+9rF+U5a15Y dAuiOiJu0Awigok/whz8U0Td0DUbsK0YM33gOb595PsoNJMViPRRqhPH8BzAQK1lqDYSb7Hl 9fAOJybg5CR8YgdsGgBXwarg/2fvzmPsStP7vn+f9z3r3arq1l7FIllsbs1u9t49PaumNeOR ZC2WHDu2IwFKrFhIHDgI4AAJHARIEBhBECeRAyiRjQixLCWyrYxmNNY+M3LPqEfdM5peyWaT bDb3pRbWXnXXc86bP86tYpEsdnMpLkU+H+DgVt06Vffe95x77q3zu8/zgnPCGycMw/0RYRTi xW3qtkgr7oEwQoyhma1QkylKsYM4IPMTxLUgayLXzEVndaqve84PDd2DUX4Y/5iT7sYDWxZk AOyAEA5asmaKlLWK7VFhilAaspRHLDM9gjco+D2C+BvvOM4BmcO5+5fmGAtxt/3E/XvtrYxA VDQYA3GvwRZSsgSkC1ynu6XtFbyiYO9yFZhYCEqCKUE4aGjHCZncebtWMZJX8+nxVimltrRC ocBLL71EktxcF4uZmRmazaa2iFRKKaWUUuqBJQZnY5a3/RJJYZzChd8gWDq0rnWdywOKyz+A N34Rdv8nsO3noDCqY/cgqZ2F2Tdh4QP6p07wj3/8LDsrf0ZhdhDKX4Kw7/7dN5dCa7YTgC3n l6tLe91l2gnIkk4otn5J6/m8ZS4Fl11ZWP99CmRXf++yznVu3aXrXL96CVkKLm1B2iIQOLgN hrvofLLU4VkoBHlIhVz9aVPfwrbq1S0WN+e56ZGZCGcLOFvEeWWcCXG2SGaL+XVrP+tcZ4o4 E9BqGy4un6DemCJ98bMsDg8jfkySBTByjpmlP+fS+Iv09/fRXv4hF6s9TO9/kUIhJstgamqS mQ++Tf+eXSw/+xTt0M/Hq1MhKC5FkkWCxbcon/kVzMBBasFnWc6WqXvL+ny8F4fupxSj+gAA IABJREFUT9jfrCf07owY+mKTSa9B1wGfys6AiVadJjo/26Ozo3RCn1jo3e/hlwSXwfKZjauq XOJImuCJe6D3740ep/WErh2W1nOOheMp2S6h7TkIhO7PWXr3evjxPQgODUTbDdUnPGpZi/QO n28iQlQx9Dzm5RV9SimltizP8+juvrn5zZ1zOOcoFot3/37pplFKKaWUUurOZH4vjeqXSf1+ CpNfJZz9d5j23Orb+zzgWDgKR38F5g/Bzp+HvpfBBDp499ulP4Uzvw2zb+KyBL/t8dzIImPx 68THTsDia/DY34WeZ2/iP7kE0tVKr/q6pXHNdavf19Zd34Cknl+XrEBSg6yetxvNWpAl+d9f vVz/9cf9zKXrwrK7Y30jydDL5ynbNXjl574HlYi8cu1aAp755IAt87pwfjeZ19VZuq+6ztkY Z+L80uZBGRiceNBZnJjOpV13ne1cevmZdDG0k4xopI/mxbeZTrbTHe3B8yNa7YSZ1jK2OExQ 3UdhYJiekRUmp6eZbVawlX7a7TYX5mdJvSo9o09CZQ+JtdeNmGRt0ngH/tI7lBYPkySHiKnq v+i3wtz4LEdmUriDKiIvNIzuL5M0HfXLKaOfKtIzFrJ4usVSV4Jb0pnzHhUiEJYMI0+FDD7u qM1lnGk0Ng6xUkibLp/LrzMX4FbpTGg8YWBvgBcKtamMZEFIShCMCEMv+QzsC/Ajc0/GuzRu 6N/vceF0C3eHFWzGQHnAUug2eJ2585RSSj0Kr9+yttxt+u5dKaWUUkqpTZD5PbS6PkXmV0ni HcTTf4C3cvzKCi6F5Y/g/BLULsC2n4bhH4PiTh28+2X2LTjz2ySz79MsvkCr8gyTs3X+99f+ GT/2+Wf4UjWhb+I7GDEwMgVhb6eN4mK+JEvrvl/IAzKX5KGYa+ch142+vmq9dT/PWp2l8zP3 4M/3ZNZPPybgXZMnhX6+BB44E+BsGeflFWOZLZB4Zdqr4Zgp4GyBzK7/fjU8i3AmuuprVr8W H8THGR8nAXdyFlVMxsjYbqqnL3Ho/WMkmaFcLrOwsMCxY8fYuXMnfX19xHHM+Pg4ExMTvPfe e+zcuZN6vc4HH3zAyMgIQ0NDGLPR/RCcCUjDQVbGfpl44qsUZt+iq3aUWD6jz8ubZAPBeIL1 DX63wWwT3ILDRJBkLWzm3/4+bYSoZIm7PPyiIapY4opH0GUJdhuarRTq2iryYSeeYAPBCwTr y1qBb9hlwORh2rXSxCENEN+RSnvLnHQTA0HREJYNZt2dNhGEFUNQ6LRZvOt3BGwEQcEgNsPh 7vjveZ1tqJRSSt0NGrAppZRSSim1SZyNaZefIvN7yIJ+ouk/IZh/PZ9/aVVjCia+BbVzsHgM Bn8U+j8LQY8O4L2UNeH875FdfouGN0wt3EeSlWm35in4CSQr1FZaNLMLhO2vYxaPgt+1rvXi cl5llqxAupIHbdfMr7U1SR5oSQAmwHVCK8ReVQ22+r1tXsBjFvGGaNrtOAlZWG7w+luH2bF9 B7vGdzKcvol4dRrdL9AqP91pzdgJzUzUCdvCTngWgYk6Adq66+4hYwy9vb28+OKLHDt2jKNH j+L7PmmaMjIywv79++nq6sIYw/DwME8//TQnTpzg3XffJcsyenp6eOKJJ6hUKp/wqVmhVXke Z2KI9pFNvomzehL4pvbSQPBLhiA2FLs9tn22SO30Io03UhBAMtwmPBfWNp8IguBFQjhkSGYz xBOS8xluSrfHQ6mQF7XmVU/5jiAmD34GD/q0646p99t5d9317wNSSBPAunz+MNk61Y7CbbSX vCt3pPPc08OhUkqpLUADNqWUUkoppTZZGo1RH/g5kmg7sV8lXHgd25pm7Uxc1oT592DldF5F tXgU+j4DPU+BV0TPKm0Cl3WCsE6V2Vq12VJebdZegAvfIFm5RMsLSVa+Da15uhqz/L2XJugu TOHPtGgGDi+dxdTPPsAPNq+IcuKD8a++FG/d996661fXy3++ug5IHnjJargVXrUeq3/LeCA+ /tK7RNN/TJgG1OPHaAbjzKYrfOvEBb40sJvHisMErfdJi/tYGf0PafZ8bkvsPkEQMDY2RrVa ZXl5mTRNCYKAUqlEHMfYTtvHOI7Zu3cvw8PD1Ot1RIRSqUSpVMLzbu7f7XbpAEm0l9rEbhr2 j/W5e5OsL3i+odwX0r8n5szgMo27PD+aSJ4ve30Gv0dYmXe4KW0X+bCRKpje/HAn5urQyY+F 6g6f+kLG5WMJabrB9ndbe58Qm3ewNjFgdX9QSimlPo4GbEoppZRSSt0FmVeh2fN5ksJusou/ STj7Xbz6R0haZ23GqvYiTH0HZr4PQ1+BnX8bug5CcTt4JXSykJvgXF45thakLXe+XoT6JDQu QWMS6hNQ73xdO5/PdeYy0hakjWlWz8t7wGDpyp9PMsgy7sJJRgEx+Rxg2E5FmO3MA3b93GDu msqxK+tYEJ/MK3ZaJxauzEV2bVtFE+O8TtWYLaxVh639ni3c8qNolZ+FrEU0+yq97XeoyRIt m/H5Xcs823OMkZU3sVGBRt9foV16fGv9s+x5dHV1US6X8y22wTwOIkIYhgRBgOucVL/t+R4k xOnZ7Ft+Glmbt++Te1j9Z3wwoSB6RuWhZAYEfxuYcINdTsDzBfuQbnsvErof84iqGbXhjGTJ PRhVbUoppdSD+tqpQ6CUUkoppdRdIh5pNMbirn9EVHmOwsXfwl8+jEnmkax9Zb20ARe+AZPf htGfgrG/AT3PQtSvQdu10kZnqXcua3nbzaXjsHg8v1z6EFbO5ut8Auf42FZyN/y5mDwMWQu9 VsMui+uEZ2DWLp3INd97YEOciclMBDYm68w/li9FMlsEr0RmYpwt4bxiZ53iuiXGbXQW+F5t jnCIlW1/j6TwGNHlb9Jdf4uiqfPXDy4QxhnL/vNc7PoJvPjTBNKFde6eTDa+mTaeR+2a3eEe TaKulLoHL90B2JIgj1jeLQYK3ZYdnw7JEsfc+ZSJN1taVK+UUkp9DA3YlFJKKaWUugcafT9O q/IchYl/Qzz1dbzaR52QbV18k6zAmX8N578BA5+H8V+EoS9D0L3Wvu/GHLgUKw54SFqWuayz pFeWhcN5W835d2H+MCydgOb0bd+ECBhZP4qGLMtDIDEWYzKMZGvtFUFwYnG2QOZXyfy+zmWV LKjibJlsNSQzBZxXykM0G+ff22JnzrHoodm303CY2vDPUxv6W5hkgdPH3+Qf/er/yme++Nd4 eeBTnD96ntL5YwwPL9LX10epVCIIgrU2i0ptOiGf+2oTgwEx4McGGwusy1zt3rySLT3ncEs6 9Ft+16mC1w9+j2AjHpiQzXiCV7j7oZ8XCF6PJcugVXN4kaZrSiml1Me+duoQKKWUUkopdW9k QT8r236ZZvUV4omvEk99Dduaun7FtAETfwaX34CuJ2DXL8L2fx+Cno3/sEuhvYBfO87+wQYF 28SQbe3Bckne1nHubZh9E2Z+mIdq7QXIknWh2509Ts+C7ZwsdyaiRi+Hzy5Sqo4yuuMJAu8C JMdo9H2BleFfIAv7yLwqzkZ0zuJ3JuiRa74nr2RbO8PfuZT11z1kxCPzqyzbnRybjniRmJ5q L0mScO7cOS5cuECxWGRwcJDh4WF6enooFot4nndTVWJKffJxA6xLKId1Ek+wweY810QgrniM PlsiS+HCVG3tZ/62PHSrXU5AA7atrQD+E0L/Fz26xj2MB3GXve+HbGOhPGgRgajLIObuzjV4 3cvavXwZ6TxerZpTSim1VWjAppRSSiml1D0jOBOQFPawvP3v0+z9IoXJrxFNfQPJGuvWc3nA 1F7KA6ZDp+HDX4OhL8Hwj0Hvp8Cv5AHUxLdw57+GLByhp93gN//OJYrlf0rP0R9A+z+AgS9C NPDgD017ERaOwMIhmD8E8+935kqrX73cbqAmBmcLpMEwaTRCGoxgkgW8pXfwoyILlZ9kqfx5 LkzO8t/+2j/hJ778RX5hj08xe4+s8gT1/p+i3fXclbnP9OzfjfdxMWRZ3jKxp6eHocEBdu3a xczMDBcvXuTixYucPHmSSqXCtm3bGBwcpKenhyiKtKpN3Z6Jd+BSEVoFouU6P/3UIk4WmP/o COxJYf9XgOB2d2lEoFDxGXvCo7GQMPF6Pe/46oGNBVsACQT3sFQPPwpHqiEwZchmwM1euT4c Ffqf8hncFyAGvFDu+xxkxgrlAUuxaskSh9j2w7thjODFgvX0NVYppdTWoAGbUkoppZRS95gz AS7oo+W9SBoO06i+QjTzTcLZVzHJ/LoQyeXVbPVL+TxjjQmY+DYUx6Hrcaidg7l3SZ1Hq/QC i62I33n3G3zm4ChPzRylVP8fkfFzsPPvQDzy4AxAeymfI23pOCyfgIUP8jCtNZdXqLUX8sAt bdzWn0+jEZJoB2k4ShYOkQYDZMEAmd/TmbMswpkYXJt46hsEl7/FwMof0d0+RCX1+S9fmeKZ Xd9ivJVgi93UB3+WVvdnHqq2jveKMYY4jomiiEqlwuDgINPT05w8eZJ33nmHt99+m/HxccbG xti5cyfDw8NEUaTzmambfLK34cN/CacSXOslAJoY3p/2CFyLXuvg5BF4/2048J9C2HdrJ0x8 k7fIk06LvtDgRQZbEKJ+mwcBkdBedECq22MrHZt6BX8UWolbC9gkAuMLfmwICiavpHpAWE+w HrQb9+7jHdYTgorgBXJPblQEgoKAE4yerVRKKbVF6EuWUkoppZRS94kzMUlhN2m4jSQep9nz eYKF7xPMv4FtXEDcuk+puzSvWKtPwOJRmP1LXHuZVn2JmjdKYjMWsh5eP1XAH3uOwYN7CRr/ luDSnyDlx2Dbz96PRwhZOw8Cl0/DyhmonYHaBWhMQvNyvjSm8tDtFqs/nC2ThkOdZbizjOD8 HjK/h8yr5HOieaV87rMNArL64L9HGg4TLL1F1JzCyTSP9bWJfENWfZFa/4/Q6v40md+tO+zt 7AHOkSQJrVaL5eVlZmZmOHv2LBcvXqRSqTA+Pk5PTw9zc3NMTEzw9NNPs3v3bsIw1MFTN9bI 4NJ5OPbH0Pgq7dpPkhnBCbSd4fyMDxgqj5Vo+SGc/l3ofwoGX8mrf2+CCNhA8GJzVeArAuUd Pnu+1EVYstQXE05+Z5HF19uP/GaRaud5P/vg31cTgy0I4l3zumNA8/18zsG42zD6XEhYMhhz 9wfFC4S+3T5Z4ggK2jZYKaXU1qABm1JKKaWUUveV4GxMu3yQdnE/7dIBWpXnCBbfJlh8B1s/ iWTNq38lbUDtPGkGjRY0atO49ut4UuUre+cZDo/h6mWaqYetf4g3+Sp0Pw3xENj47jyM9hK0 ZvOlOQutmTw8Ww3T6hc7y6W8Ui27hZPRYsi8Cpnft1aNloZDZEE/md9LGvSRBf2kfj9Z0J+f GbxJSWEXWVClXXkG05ri8sRZ/uWb/xcvfeplfvT5n6PQ9wTOFnU3vQ3OOVZWVpiemuTixYtc unSJpaUlKpUKe/bsYWRkhN7eXnzfZ2Fhge9///scO3aM0dFRDdjUJxxvgOkGnP4QCgu0GpC1 HOI5vDRhR3ed1DmSpQaNlYRseRl74p/D7Fv5XJbGy/s7XnXpX31JgMzESK0I87MwexZ8H9Ow FMrCwJCj3CMszmRcKrQRs8EHBFIHKwswOwXzAo3VuRu3sAJIBdwiULv6ertDMCG03nNX/+xB PUZd873pBb8i2ADtAgwEBYMfGURu6WX1thlPKPXmZYMaciqllNoqNGBTSimllFLqQWF82qUn aRcfp9X1KcKFH+AvvoVX+xCvfhbTmrpq9SSFdgourcPyKWJO8TNPALwG59+lHcak3gre5J/l J4yLOyHsBb8LTNBZ/A2+zqs/yBqQNiFrdS5Xlxakrfwya+VhWWsWGtPQnMoDtdWWlrULtzYG Ysm8MplXzavQ/Gq+hP2d+dNGScNR0miMzCtvyrBnXjdZKa9Qu7x8nq8f+iqVA7t5OdxDrOHa 7Y9rljE5Ocmxox/QbDYZGRnhySefpL+/n0qlQhAEiORztXmex/j4ODMzM9oeUn0yByQOWhku hnY9g7qDFEJJeWJwiTQNuHCiSVJuklUdXPoTmPou2PBKiLZ6zBMfrA+yehz0gTJMvgwTL0Bp CnrfwPgZ5eUnGSpVCS+ewC4sYOcGYfoZaPTnx831GhlMzcDJw3B+GJZ2A/7WfpnqhWCv0D7r SD/sXFnI2yt6VRBfYAvORWfGoPxZS/+zHoVuqwEPecgl97hNpmjhmlJKqS1GAzallFJKKaUe NGJJCrtJCrsxfT9OsPgmwfwbBEvvYlpT2NY0kq7gXIq70XnM9hJZtoSLgflD+SIeBN1Q2AZe AWwxv/SK+WILnesL+Vm19gIky9BehmQpr1JLljvLSr6ktfxybd64W3mcBmcKZLaE88o4r0Tm 95CGoyTxOEm8k7QwThKN5XOmqa21GwNxHHPw4EEqlQrd3d3EcYy19roQbTVgGxsbo1jUUFPd vNRxVZ5jTIaxTbIsP93hgCwDl6WI6xy/bkY2DtMHYC6ByRqcfhfxDtHffoaqKROe+QDkMiz+ HDKxD1obHIxbwGwCEwsw0wvN+xA8dSrOaG1O60aJwHYLyWxndAvg7RNcK3/Suy0akNhBofqM x/DTAXGX0YBN3fQLnY0EY3WHUUqpR5UGbEoppZRSSj3AMr9Ko/ev0Kh+CdOeIZp7lXDmVcL5 v8C153Geh3NZp43k1SdvrztB6JIr857dc4IzQT4PmglxJiLzyqTxdtrxbtLSftrFPSTRTm3J uJX31yyj1WqRZSlJklAqFimVilhrMcbQbDav2UcF3/fxfZ9yubx2nXoIFDqXtbtyOAEDTjbu 5CfyCcfC271ZmScIXr1ySHXdiKQEYYugmpLOG1ztwdp/TS/4u4R0DpLZ2wv4ZKjzeBcBe/Wg SwTBiJDW3FoBn0TgaltkP7WCDDn8ESHuNURlg/VvbhuKyT+LooesR5cAXkHyrrK6Hyil1CNJ AzallFJKKaW2AjFkQT+1wb9JbeCv0/PBP8C590gK22k3ani1E5DWabeaeFYwAkYcRu51xYR0 zjYaXOcSsTgTkcSP0S4/QVJ6gnbpCdrxYzivpNv2IdJsNjlz+jT1pXlOnTzBX/7wLynEN64+ DIJgbT42Y7Q3GJl7KB6GVCF6yWAiqL+bkZ3a5BuwkEaWLLDY/GC3Fu44yVvntrNOACdgDGAs DgEEWfswwvrxdp1vO9dJijFtrL1xda5IgzC8xLYdx2jUIk41Rmie8DY6Kt6/bRGBrQiufZv7 VgH8PYJ4kEyBrW7Qxs9euc54YLcJKW5TKubuhegZw/CXfarj3k2Ha7DaTVSrlx75t2eiIatS Sj3KNGBTSimllFJqqxFLu7ifaOkIXjTK5e3/Ec5lNCff5Hd+61f4wlN97Bt2dAUX8MziPb1r zhZIw2GSaIw02k5aGKddOkC7sDevTOt85N9hdLKVh1Sr1SJLE5qNBstLy6RJcsN1oygi+Zif P0ry+OPhOEtrtwmDP+oRlIVzjTb1U9nmjlUgtAYGWBl7nt7Z1zCDRdKeAAJhyQ/4g48KeO2A fdUQ2+NjDLTLz5BGI4AgWQvJmnnlr2siaRPJGp3rOpdJC99bwQ/b3HhOsQZB8A4Dgz6Li31c qAzQXHeaRSwYmyEmfXBfTqrgGtyw0lAiMDGIJ/hDDq9brptqbnXXFSPYEgQ7hGYL0tktEBhb CAaF3r0eXSMe3i0EbPkcZaKVS0oppdQjTAM2pZRSSimltqBm75fxlw/TM/dNgmyGxeKnmTUw veJTd92U/Qkir0Wr50dpdn8GkzXwGqew9fOYZA5Ja/mSLCGu/Ym35yTAeUWcVyazZTK/myzo J/MHSIN+sqCPNBwlC3pxJsKJjzM+dNpCOhOw8VlZ9TAJgoAdO3dSqPTw2J59fO7zn6dULNxw fWMMhUJB20I+ZEwBSsOWqNtgK+28XeQmtwx01qPV/QQN2UvhXA2/1abhPIxzWAuRWaa3d5aq N0e7uo2Vx/4BaTi8+tvkE1jmi7hs7Ws6X7sso7ZgkSig3dXN3O7/HN/+x7AawLkroVm7FdDM hsm6LURAo3MrZSHZXWXpmVdYKhbJvu8/WBuqAN5uIZtzpB9u8HPrCJ42lJ+wtBccaQ1Kj1na K47W6SuP30RQ2GEBaC06xHNgH+AdtHD1y5FYsL5gLbcclq1fPavnj9943DiTVUoppdRDRQM2 pZRSSimltqCksIva6C8SBf3E8z8kvvwv6Mks//CVGfq7a3SVhmj0/QLNvq/QLuxBXIqkK0ha R1wLXIq4BFyCZG3ENZG0DlkdkzXBOTJbwNlivpgwrzwTDzrhmTNhfr2J8gDOxp0gTcOSR5nL MkAIo4goisiyjCzbuILJGHPDn6mtTcxdbpsmgvMqLO34JdrnTmOcgwwqts1ze5cpFY/RVVnA Gw5YGv8vSEv78+PVLbCBY+DFFM9LSUs7yCQFsk64diVBSVrQ7nK4KJ+HbK0qzAqUK2SVAVyU 4Lzr58q8r9uoAv6gkBhIL7irQlDnO1wpo+cln22fC5k53qa14Bj9dMDixZTlIykUQIrgV4Wx VwLSluP8d1ukt1o4XQC7XSC9QdC3wfoScVstKM0YmB65KwXU6bRj9s0EEwkU9XVQKaWUehRo wKaUUkoppdQW5ExEq/wsqd+P1/0ZbPMS9cVL/NGffo3d+5/l+cd/jHjwOdJwFGfjT/hrWR62 ZUlezeYSwIEEOBPgJNB2juqmNJtNzpw5Q6u+QqvZYHJykrNnTrO0tLTh+nEc88wzz7Bz506t YtOSl1snhrS4m1Z/TFbxwBNageX9yx5Jo8bP/MhBkuIekuK+2zqGeYFQrHogHggbztwGkGUu D8+kgd3u8AahfdIBghPDA1m9WwA7LPi9glhI5yE923lkZUeatcmKKVFfTHnIUp/PsEFGZcgj bTvCYQOfzjBFIeozVIYtSdMRdBmyekY2BkkxD50+aQ4+icAfBZfIdUHfRux2wRuG1ru3OM9b 5zGHY0LWzjcrdOZS87jjz4ZkM7Dy7zLMsGBe1oBNKaWUehRowKaUUkoppdQW5WyBpLiXpLgb yZpctmf59e9/h5/uf47x4isMFvpv8i+ZPESzgZ7iV3fEGEOpVMJ4HsZaoihiYGCArq6uDdf3 fZ84jnXgrjyrdQhuglzbabE8gHTXwaY0TMSh811MFnbxlcGfufPbupVszIApge0SkuKDPYZ2 u9DzBUvfMx5ZG2a2Jcz+QQIJmAMpl6cnCYkwXjfWF7rHLMmAISgI5QGPsa840pbDeEJYFqKy IY1h+EWfdt2RNB3tZcfMOwmLSUp27hPGORSQm9j/C/kYe91Cu+huuYrNFKHrKUvUY5j/MKV5 PMVGghfKHYf8a3PZ9erzWCmllHpUaMCmlFJKKaXUlmdwJiaxvUwu+bQyT0/Tq/siDEO2jY0R RAXCMA/Xdu7YjnNuw1aQWZYRBAHGaIWkujlSvabFn4ANwBaAAFIstXbASvM+7VPmAS74LYDp zSutbD/0PeWx/cUwn44OmP9eimuBt7PFBB8y0NyRz0/mQe9OH+fAeoIfCaV+m+fBkrcCNX5e 4hdVTGeKO0djMSNrO5a+vzrH3eaO8239WixU93pUxz3aK00WbIpYtIJWKaWUUrdFAzallFJK KaWUUptCRPA8DxGDSF4R0mq1WFhYoNVqrYVsq4Fbq9VicHCQ/v5+DdnUJyuA3SGUnjEUBk3e 1q+z3z0IoZZ4EI0Lfo/QOu/Ilh+s4TODEOwRWh86xAMbCF4kuCwPKcUCFvAdLa9Oixpht8FY wfpXAigxsjb2192G7aznhLQNJshbUJrx/Opskk9sAbk6xxoBuMWbWP+WjlFgfSGIDYU+Q/lF Q9Rvbvh4lFJKKaU+jr6FUEoppZRSSim16ZxzLC4u8NGJExw7doyVlRWazSZhGOKco9lsMjg4 yCuvvEJ/f78O2MPEkM9ndQtFQVJd12JvIwXwdgvxXmHgJY+BJwOisuHawqP82/tTw+t3CX0v ePixUD/bolW/v7XEUgXsumAslLy1YuGa9TbYTolpMtd9jsHHP4sf3Xl1l79dwECr7nCfEJiZ QfC2CeJBOgPJCbepIRsCfiwMPRXQvcPDBhCVDFrEppRSSqlbpQGbUkoppZRSSqlNl2UZE5cm OH78OENDQ4RhyIcffsiePXsoFAqcOHGCSqVCpVLR9mwPkwLYbsEGN79NpQr+3rySqn34+jDF jAEe2B4IeoXSkKVr2MPvVF+t/Z0YpJCRLqW4+xCymQgq2yxeKNjS/d0MMgTBPsE1wQQgIXl1 GnmlmgnzKjRBNhyr1LRZiOeoDHrcaXGpBGCKnUq2siO9pipNinn1n0s641gW/D7pzLXnyOZA RiFb6lS03Ql7pYqta9ijMuTyLNjILQXCSuU7b6fyU/cdpZR6ZGnAppRSSimllFJq02VZxvzC Av39/bzwwguICEmSsG3bNnbu3MnIyAjHjx+nXq/jnNOQ7SFiS3nLwZs+6RyAqeRfJhFXVzgV wN+d/yExeRAiFkwnKFkfDUkoSOBwkt6Xxy0CxhOMJ/e9Gsp0C4V9hsKQwS8L9amMxUMZGAh3 Cd3PWEqDFuNB2r7+9x2OTBKMvfMxCXcKXQcsXlGo7cqY+25K8na+5WQI4hcM3QctK2czmlFn 29l8e9uCEH7BEA0JSx9k1F/Nbu+OFCB4Xuh5xhJ1GYyh89j0uKPuYN8uGypjFj80uicppdQj SgM2pZRSSimllFKbzzlclq1VqTnniOOYlZUVfN9nYGCAU6dOMTc3x8jIiM7B9hARgVtNmMQI EoO/F9qnHW4CKIDpzUMWl4JLPqEqzQIGnNyn1oxG1k6yiwXbtW4YBEyYP6ZNbXd4o/EMoLTT Mv4jIUHRMH8+4XS9SWvJUdgpbP9cSM+Yh7FC2r574yUWup+y7PhCSNxlWbg+0GzWAAAgAElE QVSUUL9UZ/lYXqloB4TeFz1GXwq48IMWi13pun0CvC7of9mja5vlTK1JI8q38S3fjwqUnzRs W/e4lbqzfVvoGvIoVi1BrBWQSin1qNKATSmllFJKKaXUphNjiAsFFhfmqdVqlMtlwjBkdnaW er0OQJIk1Ot1sizTAVPYGBgQ0hmH8yHYKwSD+bxhrglpI69e23iHA1sFiRyO+7M/2RCM37k7 vhBsy0/CI+BFQmG3IV3MNmyDuanPvSHwtwlxr6HYZwkKhnYjIx4Usszhl4S42+BHBrlbubbk 4WJQMvixUB7wiMqGpJlhY8GOSx5AhhBUhLjH4JcEb1jwBwQbCWQOsULYZYi6DbYgmN5buxtm DKQikIJfEQo9hiA2GoaoO9/FO3P5+ZGGa0op9SjTgE0ppZRSSiml1KYzxtDb28vkxCWOHTvG gQMHqFQqnDp1iiNHjuCc48KFCwwPD2v12ma7R1VSm04EMQ4CIdwjjPy4T9d2i/WFNHHUZzLm P9q4/aMYofK0pb29SXNy+b7cfRsLxs+r7UTAxJJXYQVCddwDB2eWWyQn0qvbYG6yYJ8w9GWP /n0eXiAYgbjLMvxCwOWjCWnLrQVgd5MXCn2789NO/mqFj+Rzv1VeNnTtsyyfz/AKgjH5WHW/ bKk+6bF4KmX5ZLa6W+TzpkWCNyK49k3uTkNQ+JQhGjGsnMhvxz4A7TvVQ0b3J6WUeqRpwKaU UkoppZRSatMZY+jr62P//v1MTEyQJAnDw8NMTEzw7rvv0mq1GBsbY2hoCGutDthmjfsY2EEh Oelws1vjPkuctxIUQ95KMYZoVOh/3Kdvl4+x4BwsTiSsTGYbztcnForbDLWhJk27BNk9bhMp nTni1s0LtxYMBVDo8UBgoq/NUnAX70cB/H6hb69Pz5iP5+fBVlQy9D3m01x2LJ5L7smQeL7Q Pep1jgdyZVw8KIwa+g74iGkTFPLKRLFQGbcMPRGQ1Josn7q6EtEG4PUIyYLLKxm9/PGuuSa0 NGUo7TZUdlracy4P8vQsmFJKKaU28/2ODoFSSimllFJKqbshjmP27NnD2NgYcRzjeR4vvPAC Y2NjpGlKf38/fX19WsG2iUyP4A932ixugYDN7hcqnzXEIwavIGQtR3u3Ix40hGXBC/LKJucg KBhKw4aguEEVkoAXC+JnZHJvW0SKQFA0FEcMfiS0VhwSQGHAEPcZjCcY26meugdZsnh5q0rj sVZdIwasL0RdhrSZVwXe/TvC1XOdrcs8jScEBaE0bPP2j55Q6M2PA164bpw6hwYvFErb8ivT Vh62GV9ons8IhoWsAfV3M7JT63cuwYsFLxJMDH5RdO41pZRSSm0qDdiUUkoppZRSSm065xxJ kuB7Fs/zaLVaJElCoVDgsccewxiD53karm02CxLkIcsDrwDhXmHHT4R0jVrE5OVfWeawvlDo NmtBmghEZcPIMyF+tEFQImBDQbyMq5Kce8BYoWebR7FqiCqGVi3BLwlDz/tUx/18jqZ7yCsK Nrg+hLSe0DPmURm0ROX7PA+ZQFg2FHstNhCCWBjYH3TGc91qkgeFcbdl9DkhfSI/trgMLu9o M/N+Qu8THs1Fx/mFFq0FBwG4xatvyy8LpSGLF+p8WUoppZTaxPddOgRKKaWUUkoppTaTc47a yjLHjh2jXlthYWGBZrNJoVCgWq0yMjJCf38/pVJJB2szFfL2isYHrHCvg6bb4XcJXaOW7hEv D9jWEeGqMMQLhVKvve76q9a/D8RAVDF5aAUYk4dcxX5LsWowVnD3qKjO9IJXkU6Fmlx/P8sG XKcd530kkm/PYo9dmw+uWLXgoFnLECPYOJ93zS8IfiREpSunsNLE0VzOWJnMKA9bvCjDFgQz ALYfkvNu3W0JNhSCoraIVEoppdTm0rcWSimllFJKKaU2TbvdJmk1OHXyBIFr0dPTTRzHZFnG zMwM586d49ChQzz++OMcPHiQarWqVWybxI4L1c9b/LLQPJ2QPmh3sAASgWsANZBKHrBZXxAr NxWQXRcMdeY+u9/ByVro5yCsGPqf9IjK5rrQ8G6NK7V8/r3yFy29T3qEJbPheN4wnDT3J51c vz1X75v1hO7tFuvnbS3LAxZjr1nX5Pd59XK1laQpgdctpLPX7ydo8ZpSSimlNpkGbEoppZRS SimlNkWWZSwszFNfXqBeq/H8C8/z2K5dRFGEiNBqtVhcXOTkyZMcOnQIz/N47rnnKBaLOnib wB+CwRcCvABmvp/SesAq2EwveDuF5LQjq4H4YIvc0bxkAnhBXqH0QBAo9eYtGL1Q7n5VXSEP Vl3NYfuF6tOWkacDCj3mpqvUjCd4Ud5W1LXuwRB9wv3yAqF/T0DvuMvn1gsEc6MAcP3VJn8M 0mmTaivckznvlFJKKfXo0oBNKaWUUkoppdSmSJKESxcvkqVtxnaMc+DAE/T1VpF1KcPAwAD9 /f2ICCdPnmR8fJw4jrWKbROIn7fBs748kHOwSVHw+oR0GlbbV95x5ZTkc3YZnwemPMn6qy0a 76IC2O0CqSMYEzBCtE0oDlrCksF6N3/7YsAGV6rA7iZj8/aZH7etxEAQy8du0DxYhajLYP38 exNCtEvwykJac5T2WaKq0ZBNKaWUUneNBmxKKaWUUkoppTZFkiTMzMxgrE9XdzdhGF4XnHme R1dXFzt37uTcuXMsLS3hnNPBe8hJFWRtfrjN/uM8cr3/TC/42yFbFkwM8ahh9As+vbt8/Ehu efjuyT5AHrDZ4p1X9okRSgMefmzwY2FlJiMaNvQ962EMTEibkc/6dI15rEyn+gRUSiml1F2h AZtSSimllFJKqU2RJAntdhtjDJ7nXVW5tp4xhlKpRJZlNBoNHbiH2Oou4O0WvGpeuSQB2P2C qXDH6Y7QqRi7F+0YHwQFsKNg+yWfa8zLW216Jega9Sj121uqXrsPe8RNt6782L9iICobopIh aTvEgF8Wusfy01xzvSmVEY/KoEdzIdMnolJKKaXuCg3YlFJKKaWUUkptCuccONdJVT6mvZsI vu/jnCPL9OT3w0rI21aawXw+LFsE8YRwJxR3GVwCNrjzG/FCobLNEpSF+eQhHtACBM8L3S9Z CoMG4wtp09FccBibh0533HLzXuwX0pkrTe787yCdv9fZF4yFoCD07LWEJcFYHrnqRqWUUkrd OxqwbaDeaDA7t0CSpIwOD+B53g3Xm5yeYWFhEeegp7vCYH8fURRet26apkxMXWZuboEkSykV iwz0VamUSzrgSimllFJKqYeLgyxLabfbJMn1iYdzjiRJcM5pe8i7qQDU7uPtS15Z5W8XxOtU rxko7zOMfiagdjljZfLOA1Y/FIYOBlhPuHTcbcntJBG42Y/fdhJBca9hx4+GdI1YECFLHNMf tpk/keTjuxUerwE/FswmV9oZD8RCsc+yrWgIS+bRqGpUSiml1H2jAds6WZYxMzvPe0eO8c6h Ixhj+Ls//zeolEtXtTZxznF5Zo63Dx3hh+8cYnZuAZyjWu3hpeee4pmDj9Pb042I4BzU6nUO HznGa99/k6nLs6RJSqVc4snH9/DCswcZGx2+YesUpZRSSimllNpK0iwjadW5dOE8hw8fplQs XLeOc47Z2VlmZmZ0wO4S8cGOC9mMw03ch9snDzuCLqE9LODAxgI++GVDodfiUmguuDv+f9h4 QqlqO5N8ba2AzYyDty1vm9g65HCzIEP5dcn5a7ZdAF5JKPQaSn0eIpCmjuXplKVItsx5BTGC 8Te3pafxhKAi+JHBDw1B3Dkete/D/mAFCRyZSfRApJRSSj3kNGDrSNKUiYlpvvnqa3z19/+U dw5/wOjQAH/zr/3EdVVmy8s1vvnq9/hnv/GvaLVaHNi3GxHhez94i2+++hp//5d+nh//0hco F4s0W00OHznOf/OP/zcuz87xxP49RFHIO4c/4E+/8xo/9ZVX+OVf/NtUu7t0IyillFJKKaW2 NGMMcRyTJm1On/yI7732GmG4cQ/AdrtNEAQEQfBAP6Ysy9aq7IwxG4YYq+uIyNpyx+6w+sx4 EOwQWkA6ce9DBjFQrFq2fS6k/XxepeZSWDiX5mGbJ1RGPMKyISjInVdebcHPrJpx6P1Zj65d loWPUmbOJrhZMN2CPyJky5AuOqRyg8crYIxQHrQYK0Rls3XGYTPDNQvlIYsfC3HFbMocb3fE goQZqbTR+lyllFLq4aYBW8fs7Dy/+uu/xfd+8Bb9fVVefPYgFy9NbrjuW++9zzf++NsU4oj/ 5X/4r3nhmYP59e++z3/13//P/N4ffovhgX4+9/ILnLtwid/+3d/n9LkL/J//5L/jcy+/QBxF HP/oNL/ya/+Cb33nLxjfMcbf+tm/qhtBKaWUUkoptaVFUcQTTx6k3DvMk08/y1/9yR/bsIJt lbWWarWKMeaBeyxZllGr1VhYWKDRaGCtpVKpUC6X8X1/bZ1Go8H8/Dz1eh3f9ymVSletczuc dfhPCskJd3XbwFthBAkdYu/P+K0GbIUeS55POpKmw9Fi+WKKsVDstZQHLNaTR3KeLNMt9Oz3 6N/v0a45ZkMhTx/zCkQJwNsteP3gEmifdRuOc6nXUui2GE8eyZaIxgrlAUupr7Mv3WdiAXE4 HDoBnFJKKfVw04CtY+ryDEOD/fzD/+yXGOzv5Tf/9ddvGLAdOXaCS5PTfOWVz/LswQNr1z/9 5H4++6nn+LM/f52jH57kcy+/wMTkZd744Tt87lPP89lPvUAURQDsHt/OZ156lg9PnuYvfvCW BmxKKaWUUkqpLc/3farVKkEYU+3tY8eOHZ847/SNqsLupyzLmJ2d5ciRI5w/fx4Rod1u093d zdNPP83o6CjWWlZWVjh69CgnTpwA8taXlUqFgwcPMjo6esP5vD/5P3WHPypkc470kwK21fxy g2q3+1rJI3ll0ZV5tgRjHGHZ0O5yGE+wvjzSc2SJzeci8yOD2WBXsT1Q2G2wsVC/kG0YsEE+ xuYRP7tzr4M1sUKwOsebQSmllFKPKA3YOh4b387w4ABhGHDqzDnEbPzmbHFpmUuTU/iex97H xrH2yscBrbXs272LV7/3Ay5NTjM5fZmJqWmWlld45uDjBL639tklYwxjI8P0VXu4NDHFzNw8 vT3duiGUUkoppZRSW5oxBkQwxmCtvep/pq2iXq9z9OhRTp06xeOPP87Q0BCLi4u89dZbHDly hK6uLorFImfPnuXQoUPs2rWLnTt3Uq/Xef/993nvvfcolUpUq9XbCg+dcRgfJBak+vFVbHY0 Xy858eA3ozOeUN3hUR60RGXDoz4VuXjgRWA9Nix08vuE4c/5+CXDhe+0aBzOwLC153AXtv52 FwgiYfBxH+dg/pzOtaaUUko9qjRg64ijiLhTXfZx7/bmFxaZX1wijiP6e6vX/Xygv5c4Cplf WOTCpSkuz85hjLBtZOi6N8FdXWW6uyqcOXeBqekZDdiUUkoppZRS6j7Lsoy5uTnOnj3Lrl27 OHDgAIVCgWaziTGGlZUVnHPU63VOnTpFHMccOHCAvr4+kiQhTVPeeOMNJiYm6OrqurUqNiO4 IMMFWR6+DIBEQvsHNwjPCmD7BVsR0vOuE77klWs2hKwFbEK+KUNgypAtgZu4/b9jLBR7Onfo UQ/XqmBK4IVy9Qd8C2DLYMK89WFlm0fcZZjpb+NtE4IuyQO5u8GCKXBX24oaC35RMHZr7wM2 ECqDHlnqWJ5OMZFgeiGroZRSSqlHiAZst6jeaNBstgh8n0IcX///TRzjex6NRpOFxSVqtTrW GMql4nXvHqMwJApDkiRheUXfhSmllFJKKaXU/ZZlGZcvXyZJEkZGRnDOsbi4CLDWGjIMQy5f vszc3BxDQ0OUy2WMMfi+T39/PwDT09Ps2rXrFgO2jPrYEvPRFNuGH8M1M8DRLrBhC0i4MleX FMHvEWwgRBXDwMs+c0cTGh+mdzQeUoXiFwzlPZalYykrr2V3FLLplFQgMcSfNvS+6BH32Cut PC0ETwm9X/IIu4TFkykieRvJvid94gFDecgSFMxdGUavWyjvM9R6m7TP1Tf/NgS8QOjabrGB YOwW3xkExAiFHkP/ix7JoqO2kukOrpRSSj1CNGC7RS5zOOcQkQ3bSBqT9ztwzpFlGc65tfYo 1747FclbOzgHlyan+J/+6T+/o/t2/KNTtJM2p86e5//4v/9fjGgj8NsZw6XlFV77/pssLWvo eTveP/Yh84tLfPcvfsDs3IIOyC04ceoMk1OXeffwB/zqr/8/OiC38xw+cZKpmVl++PZhHcPb 9MHxE8zMzvP6D9+h2WrrgNzOcfDocebnF/nu63/J3MKiDsgtaLZatJM2h48c57d+5/eolMs6 KLdo9UNb7x4+ym/8q69RKhZ1UG7R/MIiaZbx1qEjZM5t+KE69fGmL8+QJAk/fOcwSZIShuGW uv9pmnDm1EmmJi9x5KNzNBsNVpaXAOju6aV/cJAoipmfm+H40Q8YGh7hyMmLa0FarbbCkUPv 8vbh47z5/gmi6JP3oSxNuXD+HEtTdaaCs0zIWUrHYoIzFaRmsU3/BgdOaJxu4woZZtZn9sMl /vDrb9PsuYxXK1E8uZNoshe5gzI213TMLMxw4fIU4fIAYdKFfNykU02Y/6DOn37tCPU3zuJM ek+334VLE5w+ewHn3IP1ftAZgsVeun64D2+lyNzyPOcmzvCDb85i2yHlI3sIJ3tp2TbHLp3H XU4oHBvm5O++R73/EibxkcziLiRk77Y2dVwl8yieG6cwMcpUzyQnp9/lo0sfIrObP4aSWUw7 BIHsLxs4ubuBlKQ+hYkx4hNDfDBzkfrQuU3fJ00S4C9WKc8/RpCUaU9kTLwzy+zSIufrlzd1 DE07pPzhPqLjvZwLjrHyzsl7/hy7Vz46fZZLk9O0k1T/t7ut1+JZmq0W/9+//RP+/I03dUBu w9z8IsdPnOLffP0P6dugi5m6mf9NVvjg+Ef89u/+PlXt3HZLCnHE0wcPkCTahnjtrZRzpOnN v+atdpa42zRgu0W+7+N7Hmma0m63NzwxlKYpvu8RRxFBEOCco9lswTVdPdrthHbSxlpDq9Xm j779nTu6bwuLS6RpxuXZOV597fu6sW7D4tIyjWaTDz86w8zsvA7IbZ6UqtcbHDtxmqnLszog t2BpaZmFxWVa7YTmn7+uA3I7z+HFZZaWVzh97jwrNQ3Jb/e1ZLlW46NTZ5nXcOi2j4Mr9TrH PzrF9IweB29FlmWkacb5S5PUGw1839dBuUWr/4CduzhBrV6/tcoZBUCr1cY5x9nzF1lZqW3J +cPut0azSZplnD57gaXllfzDhlvqWJQyM3WJuelJPjp9niCMsJ5Hu9WkXjtMqdJNpbuXVrPO zORFLl1e4MS5ybXHmbRbTE+cxxjL+el5PD/45BMGWcbS/Bz/P3v3HRz5md93/vP8Qmd0IwOD MIPBYBJnSA45Qy53GbRLbqZW0m4prEo6b53KV1dn+a8r21VXrvIF35181p29JcsqrSxbyfYq nNa3VjjvSreJyzQ5cQIGmBnknIGOv3B/IJDDON1okADm/aqaYrHR6P7h+8vP5/c8T2auWcvR BS3l5zW61K36eV9OKaJEkJajt0/UFcpTSd5yUWbFUiTvqjjsqd8eVV/yrGr8Bp2YrFXrXH1l 8ZoVSoFRmJeWbi/rzlK/9s7E1bSUfv+eTYHkjfoavjCla/3nVDS5D3X9ZbM5zcwtSAr1vW10 TW3JVkf+iI6PtSkRWpobntUbxYuajNxVY6lDx6ea1OSl5U0WdfeNIXlWQQfG6jWQG9f1mlfl G29t/YcKVd359qJhQo/MpdUx1qShcExX3CuamJ+SZVtbUkOztgVV++94N7EgpaOLUbVP12lo aVLX09XfJi3Zai0c0InhParLphQWQmWH8ipYeY0Xpqtaw5Rfr8en9qhpMqMxM6OLA2dUMoXd eX+8vKKFxSXlC8VttS/vmHvj5dX2rXMXryoWi1KQCs8n45PTOnPhiqLRCAWpQKFQ1NjElArF oqIRaliOZDKhQrEkz/Mpxsb2VNDQ0NDGcO0f2DYzP6+JiQkdPHhwS5eLO+4y1dSklEwklC+s DgH5zhW3qEKhqGQyoeamemXSNfJ9XzOzc++4eFxZyWl5eUXRaFSHDnTpv/uVX9rUsl28ck3/ 9o/+WJ1trfrln//pHXcjux1cvHJd3/neS3rysYf19FMnKUgFTp+/rB+9ckZPnXxUTz1xgoKU 4cobN/XS6+e0r6NNL372kxSkAhcuX9OPXz+nwz3d+uynnqYgFTh38apeeu2sTjz8kD759JMU pJLj4LlLeum1c/rYyUf18SceoyBlyOUL+rWv/7aO9HTr2Y+f5CnHCiwsLunXvv4NPXTogJ79 +Cll0vQCLNfUzKy+/tu/r+NHDunZp04qlaIXYLlGxib0jd//Yz3y0GE9+/FTisdjO2r5S6Wi rly6pKtXLunxk0+o+0CPItGo8vmc+vtuaWpiQo+ceFxB4OuNq1fUtb9b+7r2v9mDbWVFF86f VSQS1bHjDytxHz1Jfd/X3du39frcNZVWclqyp5R97Lb84rTcYkKN491K9TfLyr0ZlQU1gXKP Tcvt9hWZaJA5JyWPRvXk80f0seZWqeQquNyoMGdJt9/ny+OSSpLe+oB0jaTmUJo0MrbU9FRG zUePKriZkVYsafh9Ps+WogddPfzp/Xq0My3ZH+6Qef13BvXj184pCAN97atf3j4bViipEFE4 7Un5BSVSljrqT0qRR6SSo3AqovBWXpHpiE48eUByfIXnknrsxEE93t4gmS0Mo3xL4e1mheej OvbEXsW8x+SdySkajeiXfvandvYBybcVDtUrvJZU/bFuneiorf42GUrhckLBKylpwcjEjWqP pZSaTulAQ6d+9qc/X8UDlKPgSpPCKxEd/cRePXTgJyVrdw5LefV6r3782jntaW3WT3/hBU6u ZfrN3/33aqir1TNPnVRn+x4KUoF/8Vu/p/Y9LXr246fU1tpMQSrwa1//hnr279WzT51SS3Mj BSmDMUa27dC+/xaFQkE3b97UyMjIfQVsy8vLGh4e3vLlImArU10mrcaGWuXyeQ2NjG0MFymt dlMcGBpRvlBQU0O9Ova0qqWpQbZl6Wb/HQVBIK09ARuGoSampjU9M6fGhjod7unWI8eObGrZ Uom4/uA//t9qbW7Slz73PE/bVsCyLP3o1TM6dvSgfurzXMBVdrAr6tzFq3r42GFqWKZIxNXV m7fU3bWX2m3iAuTq9V4d6umihpW2Qfi+Lr1xQw8dOkANK5TPF3Th6nU9fJTjYLmWllf06//q d9W1r10vPPcJGgMqMDE5rV/7+jfU3dWpz3zyabU2N1GUMt0ZHNZvfOMP1bN/rz73/LNqqK+j KGV642affveP/kyHerr0hU//hNI1qR21/MViUXXJqDLJqL74xS+qp6dHtm3L8zz19fXpu9/9 rp46+YhSqZRidqiDBw/q8ccf3xgKc3Z2VsWVeTU3N+uZZ55RKvXBf7/nebp4oV43Xr4ju+go FU/oa//gM5KMisvSxOuu5v7ckn/5LdeOhy11/UKTWg4nNPaKNDboKX0goWPPPqyG/a5KuUD9 dl63zxdUur3WCPG2udxMveQeMvLnJf/Gmw0VdrtR7Kij/NVAYd6o83ij9j7druFoQUMXSvKG 36dRIyLV7I3q6NOHtedoRJbz4c6z9fq5S7p1+658P9h25+EwlAIvVBhKliUZ28isdkpTMR9o 7EpRExdL2vdckyzHqG8lr/3PNKvlUERbOQNE4IUavljQQLaonk82qmG+pOt3biiVTO74axm/ FGr8elFDQVF7n2lW6+Et2CZDaXnW17X5rMbOlGTVGDV1p1UTJJRsr24NS/lQ/ZGcRhdLOvDU AXU+fkzWLm36iceiunazT/v3dXBNXYE/+tNvq621Wc8+dWrT7Y0Pqt/5wz9RR3urfuITT+ro oQMUpAJf/+0/0N6ONn3qmafU072PgpTBsizZjqP//eu/QzHWzwvxuE6cOKEjR+7vmDY3N6di sbiR3WwVArb1C8ogUBCEkkL5nq8gWL3o9TxPJc+TZYwsy5brOura16lYLKoLV64rm8spHlt9 InMlm9XZS1dVk0qqa2+HYrGompsa1L1/r15+7ZwWl5ZVm07Lsoxy+YJu3OrX4vKyfuLpJ+lq DAAAAADbgDFGNTU1isfj9zwda9bm1nYcR7ZtKx6PKxqNanFxcWN+hyAIlM/nlc/nlUwmyx7q 1olbMq5RNB7X3n17V6cbWAml6YIKR0tamQsUzEhWg+RkLDW0pVVT72qhpaj4EV/W20eRXF/2 Vil6zMhKGBVuhW+GaRHJaV5NePy3hm+2ZBildwu2Lcl2320FSbZjFE1bqum0FUlY8kvhh758 dmT1nwzrantvSJKxJWOtblMAADwIIpGI2tra7qv3miTV1NSovn7r508kYFtzZ2BYA0MjWs7m NDQ8qpGxca1ks/r+y6+robZWMkaPP/KQWpub9ORjj+jKGzf0n//L9/R//Ma/0S9+5ScVhqH+ 8E/+H527eFVf/cqLOnXiuCRpX2e7vvziZ/SP/9d/oX/8v/1L/de/+BVlalL6zvd/rL/4zve1 f1+HvviZT7ICAAAAAGAbsG1bzc3NisfjGh8fV1tbmxKJhHK5nCYnJ5VOp1VTU6NUKqWmpiaN jY1pbm5OruuqVCppbGxMxhg1NjaWNw+ikaK1oRZW5uVb/saQQLFkqLaHYyotSwOTRXmxUE6H kV1j5MYsJTK2Ok+t9nBa6Pfe8ZnGktwuo9bPu4o3WBr+TlFLg+E9YZreq3eUvRq+WWuN+QQv W8dyjOr3Okq32HLjlhbHvY9kOQyJzc44TsXfI6wFAGA3Xy+VMWSmbdsfyhCbBGxrXnr1jP7s 2/+vBobHVPJKWlnJqVgq6p//xr+Rba3eSfyzf/IP9PxzGbW3tehnf3Ps1dEAACAASURBVOrz CoJQf/03P9Rffef7Gyvt5376C/ryi5/VnpbV4Xhq02m98NwnNPf3F/XNP/9L/eqF/0kKVzeG J08+op//mS+qZz9dZAEAAABgu9y4NzY2qru7W/39/bJtW42NjZqfn9fAwIAOHDiguro6xWIx 7d+/X2NjY7p48aL27dunXC6nmzdvqrOzU62trWXf1Fuu5Fl5hebNW3XLNoqlLcXqLNkJI7VJ 8S5Lxl0NZWxHitfaitdZWnpLg7sxaz2S6o3CQqhYvaVEky07aWRikmmQ3G6jSL2RfMlrCBVk V3u7ua2SkzIykVBhQbJjRk7EyIkaGQZf2RLGSJGEpUh8dShJY0tuQh/e8H9rvaKwEzYWyYoa AjYAALYBArY1zz/3cR0+2K1cPv+e73no8EFFIxHZtq1DPd36u//Vz+vTP/EJTU7PyBijlqZG de3rUEvTm08q2rallqZG/cLPfFGnThzX+OS0fN9XXW1Gezva1L6nRZEIY28AAAAAwHYRj8d1 7NgxRSIRjYyMaGpqSo7j6ODBgzp48KDi8bgsy1Jra6sef/xx9fX16caNGwqCQHv27NHRo0eV Tqcr6A0Uvu2/q4zRaqN6XEo/bKv5UVfGlpINloxlJBO+Y44u2zGq63KU/WSg2YveaoBi3hxS Ln7SUuvzrlItllYmA42GJeVWAkWOGrV8xpWbMsoPFFXKrfaUsRwjN2lk4mwfW8qsdhSM1Vhq fTyiRJ39oQwD6ESNnASBzY7ZTOhRCgDAtkDAtmZvR5v2drTd/w1XLKr9+zq0t6NN+XxeMkbx WPRdn1B0HFutLU1qaW5ULl9QGIaKRtzyhgsBAAAAAHwoLMtSbW2tHnnkEfX09KhUKsl1XSUS CUWjb973xWIxHThwQK2trcrn8zLGKJlMKpFIyLar3x3IihnVHXLU/lhUlrMafL01WDPWapu7 kWRco7oOV8WVUMuDwZtt8ZZkMlJ8r6X2kxGlmmwtTfpa6PeVvxgouseo6bgrJ2o0XldSaTB8 M5yzzTuCPGwBI8VqbLUcsWS72vogxaz2lLToEQUAAFAWEp5Nsm1LyWTi/q5ZjVEiHqNoAAAA ALDNWZaleDyuWCx2zz3d2+/xIpGIIpGIgiCQMWZL57AyRrKjRm7cyHbuHQ7SjRsl22y5cfPm eyNGTszIOJLW/j+111LpiVB2THJjRpG4JTceyIqutRDYRm7MyI4YWTGj+COWIjUEax/69mev hl4AAADYvgjYAAAAAAB4D/cbmH0Yk6i/F9sxqut0lGqylai13zUMM7ZRTZOtzmeicuJF5efC jZ5R60NQvl2k3qjpUVfNh91753t6+zOmWbYTAAAAPHgI2AAAAAAA2MGMJcUztuIZved8XcZI 0ZSRG3c03+ipuOy/5feNnPhaT7e3NhgkpHSnrVSDLa+0Ni+cJVktklVrZNdK3pjk3whZCTt+ I9LGUKAAAAC4PwRsAAAAAADscPczhKMxRpYdynJWAzXLNmvzb0luwkgR8/ZfkGUbGevNYSdj HZZqnzCK1lkK/VAzr/rKDob0YtvRG49RJGmU3rs6xCgZGwAAwP0hYAMAAAAA4AFijFbnZlsP 5cybAd37BXXGlmqP2+r8eFTJBku5hUC5yZxyrwYKCdh2LMuS0i2OknW2nKiRBumRCAAAcD8I 2AAAAAAAeFCY1d5rkdRqwGYkWZZRpMZS8jFLiXZLTtTI2FKszsh2tDF0oBszSjRaitdaimds hYFkxySTlMK86MW2gzkRIydC3zUAAICyrqEoAQAAAAAADwbbler2OvJaQ7mx1YTNiRk1H3NV s8eWEzNKNtiSkdqfiCjZYK+GcI5Uu9dRqiVUJGFtDCNoLMlpN/LTkv8GPZ8AAADw4CBgAwAA AABgJ7Dub66192PbRjXNthRqdQ42SW7EqK7DUW3bak+19dcj+12ZtXnabMeopslWuP57awmb sYycJiMTDeUn1l6zVz8HAAAA2M0I2AAAAAAA2OaMJDuu1eEbN/lB6wHaW1+znXd+qm3d+9rb f8+yjeJNlgptgbK51d5rJibZKSM7YkjZAAAAsKsRsAEAAAAAsN0ZI8s1st03e4/d/++uZV1V zrvcuFH7ExG5KaOhsaJMbDVksyMVLicAAACwgxCwAQAAAACwE1QYklmOZEdU9cDLiRjVtjvK zQVyaoycHqNgLpSxV7+LfA0PzK65FmIbWtkAAHigcOoHAAAAAGA3Mqvhmpsyq0NLbkHiZdbm hbNjUqTdKHLCUtNjjmIpi4QND86uZklOwkiRt270odgJAADY3SxKAAAAAADA7mO02svMiRsZ 22zpFxlHcjJGDY84ans0okStxRRseGB2NGOt7WeRtdfsUIEJqA0AALscPdgAAAAAANilzNrc bVsVdhkjuTGjZKelwJeSTZYiSUuWQ7qGB2g/02ovNkkyEclEA3mmKMmmOAAA7GIEbAAAAAAA 7EZGcmJGNe2WomlrIwCo6ldYRulWR/s/ZRSGUjS5Ohwl8KDtaxvWhk0NjU9dAADY5QjYAAAA AADYhYyR4hlLe45HZUckawuGiTRGiqUtxWreTO8Mk1EAAADgAUDABgAAAADAbr3pjxg5ka3t UWaM7u3BAwAAADwAeK4MAAAAAAAAAAAAKAMBGwAAAAAAAAAAAFAGAjYAAAAAAAAAAACgDARs AAAAAAAAQKWMZNlGxqYUAAA8SAjYAAAAAAAAgApZthSrM4p2G1lJ6gEAwANzDUAJAAAAAAAA gMo4rlHDAVftn44o2m5JJqQoAAA8AAjYAAAAAAAAgApZjlGy3lamw5ZbQz0AAHhgrgEoAQAA AAAAAFA5Y2l1DjZDLQAAeFAQsAEAAAAAAAAAAABlIGADAAAAAAAAAAAAykDABgAAAAAAAAAA AJSBgA0AAAAAAAAAAAAoAwEbAAAAAAAAUA3GSJJCKgEAwK5HwAYAAAAAAABUgR2V5IQiYgMA YPcjYAMAAAAAAACqwI4byQkUErABALDrEbABAAAAAAAAVbI6SiQBGwAAux0BGwAAAAAAAAAA AFAGAjYAAAAAAAAAAACgDARsAAAAAAAAAAAAQBkI2AAAAAAAAIBNMpaRHZFkmH8NAIAHAQEb AAAAAAAAsAnGSLEao/rDjqyakgLjUxQAAHY5hxIAAAAAAPDewjBUqVSSJLmuK2PMxs+CIJDv +/I8T5ZlyXEcWZZ1z3sA7H6WZZRqdhSvtTVwtqDAeBQFAIBdjoANAAAAAID3EIahlpaW1N/f r2g0qp6eHkUiEUmS53manZ3V0NCQFhcXFYlE1NTUpPb2diUSCUI24EFiJDdq5EaNjOsrFMNE AgCw2zFEJAAAAAAA76FQKKivr09/+7d/q76+Pnneaq+UIAg0OzurM2fO6Pr168rn85qamtLp 06fV29urfD5P8QAAAIBdjIANAAAAAIB34XmexsfHdfXqVQ0PD28MEylJpVJJ/f39Ghsb02OP Paann35aTz/9tFpbW3X9+nXNzMwoCAKKCAAAAOxSBGwAAAAAALxNEASan5/XrVu3FIlEtG/f PlnW6i10GIZaWVnRyMiIGhoa1NHRoZqaGtXX16u7u1vLy8saHx+X7/sUEgAAANilmIMNAAAA AIC3CMNQuVxOd+7cUT6f15EjRxQEwT0BWzab1fLysrq6uhSNRmWMkWVZSqfTcl1Xs7OzKhaL cl233G9XGOqe3m9BIIVBoDBc/e4gCCUTyhjDPG8AAAB4YK7Rw/D+5jgNguBDGU2CgA0AAAAA gLfwPE+jo6MaHh7WwYMH1djYqL6+vnveUywW5XmeEonERvBmjJHjOIrFYioUCmX3YMvnC8rn cvJla2JiYuN1vyTNz0r5ZVuz0yuyx0NZjpFt20qn0xsBHwAAALAblUolzc3NqVgs3tf7Z2dn tbi4eN+BXKUI2AAAAAAAWBMEgWZnZ9Xb26uGhgZ1dna+69Ov6685zr231casBl+rPc3u/6nZ MAw1NzerifFpBbL0N3/zN2/+0Hdk3emUc7tVE7FhhaMjkhWovr5ep06dUnNzMwEbAAAAdq2V lRWdPn1aIyMj9xWaLS0t6ebNm3r88ce3dLkI2AAAAAAAWJPNZnXz5k3Nzc2pp6dnY761fD4v z/O0srIi27Y3/r29l1oYhvJ9X5ZlbfRsux/GGCUSCdVkahXI1pEjR978TN/SYpBSbj6mZFeL anpSMrYUi8UUj8cJ1wAAALCrrc+JXFdXd1/vn5+f19zc3JYvFwEbAAAAAABaDccWFxd1+/Zt TU5O6sqVK+rt7VU2m9X169dlWZZqa2t17NgxOY4j13WVz+c3nqJdD9fy+bwaGxvf0bvtg6TT GeUVUSDnnqdt/VKowVJRo5Oe9h1uUNvDrixnNVSzbZuADQAAALtaPB7X0aNH73vIx+npaQ0O Dm75dTIBGwAAAAAAa2KxmI4ePaq2tjZJq6GZ53mybXsjVLNtW9FoVMlkUnNzcyoUCopEIgqC QIuLiyoUCspkMnJdt6zvNkayjCWtzeW28XoYyrY9WZaR7dhyXEeWTagGAACAB4N52/XxB1m/ Zt9qBGwAAAAAAKzduGcyGT366KMb86et92rL5XJyHEePPfaY0um0fN9Xe3u7rl27ppGREXV0 dKhYLOr27duKx+NqaWmp7k09vdQAAACAbYWADQAAAACANetzq61b78GWSqXkOI5isZgcx5Fl Werq6tLk5KTOnTunoaEh5fN5zc3N6ejRo2pqaiprDjYAAAAAOwsBGwAAAAAA78EYo0gkokOH DsmyrI2haSzLUn19vZ544gkNDg5qcXFRqVRKBw4c0N69exWPxykeAAAAsIsRsAEAAAAA8D5i sZh6enpkjLmnd5vjOGpqalJdXZ08z5MxZmO+B8OQjgAAAMCuRsAGAAAAAMD7eL9J1S3LUiQS USQSoVAAAADAA4QB4QEAAAAAAAAAAIAyELABAAAAAAAAAAAAZSBgAwAAAAAAAAAAAMpAwAYA AAAAAAAAAACUgYANAAAAAIAdwBhqAAAAAGwXBGwAAAAAAOyEG3hXsl3qAAAAAGyL63NKAAAA AADADriBjxo5UUNXNgAAAGAbcChB+WbnFzQ4PKqZmbl3/XljQ532drSprjaz8VqpVNKVa726 OzisYqmk5qZGHTnYrT0tTTLcHAEAAAAAPoCxJHH7CAAAAGwLBGwVuDMwpG/95Xd16eoNuc47 S3jqxMP6qS+8oLrajMIw1OTUjP7jn/+FXj1zQRHXlWVZKhRL2tfZpi98+jk99/EnZNs2hQUA AAAAAAAAANgBCNgqMDU9q2s3+rS4tKyf+eKn3/Hz7q5O1WZqJEmzcwv63kuv6Zt//pc68fBR nXz0uOLxqPrvDOr85WvK5fNqaqjX8aOHKCwAAAAAAAAAAMAOQMBWgUKxqCAM9fBDh/Xf/71f ed/3joxN6C+/+325rqNf/bu/rKOHDijiuhqfmNJv//439fLr5/T9H79OwAYAAAAAAAAAALBD WJSgfIVCSYHvKx6Pvu/7fN/X+OSUrt/s08dOndBDa+GaJLW2NOnEw0cVjUZ16ep1FYslCgsA AAAAAAAAALAD0IOtAsViUZ7vyzKWJqamlcvl5QeBXMdRTU1KNcmEHMdRNpfXxNS08oWijh85 KGPdm2e2Njepsb5O0zNzmpqZVfueFooLAAAAAAAAAACwzRGwVSBfKCqXz+vu4LD+5W/9ns5d ekPzC4tqbm7Qi5/5pL7wwnPa29mubDan2bkFua6j5sYGGZl7PqcmlVS6JqXxySlNTROwAQAA AAAAAAAA7AQEbBUoFIsaGZvQ+OS0Eom4PvfCsyqVPP1/P3pF/9e//re61X9Xv/JLP6f6uoyK xaKMMYrFonpbvibXceS6jnzfV75QoLAAAAAAAAAAAAA7gAnDMKQM5bl6vVfXe/tVm0nrocM9 q+FZGGp2flH/y6//pq7d7NN/+7Wv6gsvPKc//fZf64/+9Nv65//zP9ILz31C9luGibxx67a+ 8Qd/rDeu9+rv/MKX9Vv/7j9sarmWlpc1MjqqeCym1pamd/SYw/3UcEUzc/OqzdSoNp2mIBVY XFrS3MKiatNpZdI1FKQMyysrml9YUiwWVWN9HQWpcB+eX1xUMh5XfV0tBalkH15e1vzCompS SdVlMhSkAgtLS1pYWFImXcNxsExBEOju0LBqUinVZtJyHZ4FK5fne7o7OLJ6LZNJy7GpYbmK pZKGRsZUm16toW3bFKVMhWJRI6PjymTSqsukZVlM/f1BwjDQ0vycpsaH5SQyst2oOtr2bPw8 EaT12Nxn1LTYrr7mi7qZeF0lw0Oa7yaXz2t+YVFhKLW1NlOQCmRzOc0vLMqyLLU2N+3ovyUe 1OjY0tPqnDmsgcbreqPmxyqY7JZ/70o2q/mFJTmOo5amhqp9bjpo0Mnpz6t+oVX9rRd1NfWS PFPcpffHWc0vLioaiaipoZ4ds0xDo2NyHUe1mbRi0SgFqcDg8Kii0YhqM2lFIxEKUoG7Q8NK xOOqzdQo4lLDcmTSNfrS51/Qr//mv9NXv/Ki/t6v/JIO7N9LYcowPT2tb33rWzpw4ICeeeYZ RbfoWMgddwUO7N+njrZWua6rZCK+8Xpdba2efeqk+u4MaGBoREvLK4rH4wqCQCvLWeltWWah UFQhX5DjOGpsrNfDDx3e1HKNjI1rbGxcqWRSRw52yzIEbOUaHpvQ4vKyWhob1d3VQUEqMDA8 qpVsTq3Njera205ByjA6PqlCoai6uoyOHuqmIJXsw6MTyhcKamio05Ge/RSkkhuxkXHlcwU1 Nzaoh4u3yo6DQ6PK5fJqaW7Ufo6DZSmVPA0Oj6ouk1Z3V+c911m4P7l8QXcHR1RfW6vurk7F YzSolGt5JavhkTE11K3WMBqlMaBc84tLGh2fVGN9nQ50dcp1ue38IEEQaGpiTF5+UYEdl+VG 77kedIKYUqNxuZOO6rtqdKh2nwLjUbh3a0yZmZfn+QrDkGvqCk1Nz6pU8uS4zo6voRNElZlO yrEd1XamdLBhr3xr6wOpickZlUqe4vFoVWvoekklolE5rq3arpQO1e9TaPxduR2OTUypWCwq nU6xL1d0LJxVIhFXV2e76mp5gLwS45NTytTUaP/eDmXSKQpSgZGxcdWma9S9r1M1qSQFKed4 77qanZsXfaN2wLUGJShfPBZ918YKyzJqqK9TNBJRvliU49hqrK+V5/kaGZ98xw6xsLiouYVF JeIxHTvcoz0tm3sy7MevntHZ85e0t71Vf+cXfka2xdO25Xrp1bMaHhnXk48/rBc/+ykKUoG/ +eHLmpqe1VOnTuhzzz9LQcrwypnzWlpe0eGe/fraV79CQSrwo1fPaGFpSY8eO6KvfvlFClKB 77/0mmbnF/T4I8f05Rc/Q0EqOQ7+4GXNzM3rYycf1RdeeI6ClGElm9MPXj6tIwe79aXPP6+W pkaKUqaZuXn97Q9f0UOHD+hLn3teDfSILtvo+IReevWsjh89pJ/83KdUm6FRqly37w7q9PnL euTYYX3pc88rlUxQlA/geZ5u3rih/xIUNJ8LJCtyz/Vg4BnNX40pe9PRkY8/qkTHURk6Br6r q9d79Rff+b6CIOCaukIXr15X/jvfUzwe3/E1DDyj5dsRLZ6L6uATR1Wz/4CMvfWNlWcvXlH2 Ozk1NtZXtYZ+0Wj2bFy5Xkc9zx1Xquvgrj0WvHb2opZXsura28G+XIFrN/vV2tyoFz/7SR3s 7qIgFbhw+Zq6uzr1pc89r/37eAi/Eq+cuaie7n360ueeV2f7HgpSBsuyZNmO/uBPvk0xtjkC tjLlCwWdv/SGRsYmdOzwQT10pOeen49PTCmXy6smmVBDfZ2amxpUm0nrwpVr8nxfztpQR0EQ aHB4TDNz83ro0Gq4ttkDzfDImCzLUk0qpYcO9TCcTSWNAQNDcl1HLc2NeuhwDwWpwBs3bini umptaaKGZRocGVU8HlN9XR21q1D/3UHFo1E1NlDDSt3su61YNKKWpgZqWKGr13sVibja08xx sFxLyyuyLEt1dRn17N/HTVgFJianJUn1dbU6eKBrxw/t9VGIx2MyxqihvlaHe/YTUlYglGQZ S00NdTpysFvpGp76/iCe56mYW1ZdbUaeVVBg7HvOIX4p1MBCQVNzJe3bX6fG7ogYefO9zyU1 qYR8P+A8XKG5+QUlkwmlkskdX0O/FGrcL2poqKi9XRm1HorIcrZ+tJ+JqWklk3HVptNVrWEp H6p/PKeZWU/79teq5VBk1wZsI2PjSsRjqq/LsC9XIBaLKl2T0v69HdSvQpFoRJlMjbq7OnX0 0AEKUoH1YUoPdO1VT/c+ClIGy7JkOw7t+zsAAVu5N4tBqItXr+uvvvsDnTrxsH75539KzY0N 8jxfdwaH9erZC4rHozrQtVe1mRq1tTbryccf1o9eOaMfvXpGjzx0RNGIq7tDI3r93CW5tq2n Tj26EbwBAAAAAAAAAABgeyPVKVM8HtPhnm69duaiXnr1jDzP05GD3coXCnrt7EUNDY/pJ575 mE6eOC7bttXW2qKf/Nzzunztpn77976p5599Sol4XBevXFP/nUE9efIRPfvxJygsAAAAAAAA AADADkHAVoFnnzqlRDyuP/lPf6UfvnJa3/3+jyUj1WUy+tLnX9CXf/IzOtC1V5KUSib01KkT +kd//7/R7/zRn+o//Nl/luf7qq/N6DOfekY/88VPq31PC0UFAAAAAAAAAADYIQjYKhCJuPr4 Eyf01KlHlS8UNDM7JyOj5qZGue47S5pKJvT5Tz+nzz7/jCanZ+X7vuoyaSUScYoJAAAAAAAA AACwwxCwbYIxRrFYTG2trZKRLPP+E+ValqWWpgaFkgzlAwAAAAAAAAAA2JEI2DbJSDLW/cdl xhjCNQAAAAAAAAAAgB3MogQAAAAAAAAAAADA/SNgAwAAAAAAAAAAAMpAwAYAAAAAAAAAAACU gYANAAAAAAAAAAAAKAMBGwAAAAAAAAAAAFAGAjYAAAAAAAAAAACgDARsAAAAAAAAAAAAQBkI 2AAAAAAAAAAAAIAyELABAAAAAAAAAAAAZSBgAwAAAAAAAAAAAMpAwAYAAAAAAAAAAACUwaEE AAAAAADcKwxDeZ6nUqmkIAhk27Zc15Vt2zLGbLwvCAIVi0V5nifLsuS6rhzHuec9AAAAAHYf AjYAAAAAAN4iCAItLi5qeHhY09PT8jxPruuqpaVFHR0dSiaTMsaoVCppampKQ0NDWl5eluM4 ampqUmdnp5LJpCyLQWMAAACA3YqADQAAAACANWEYanl5WVeuXNHt27fV3NysZDKp+fl53b17 V8vLyzp27Jii0ahmZmZ09uxZraysqLm5WSsrKxoaGtLKyoqOHTumRCJBQQEAAIBdioANAAAA AIA1QRBoZmZGd+7cUXd3t44fP65oNKrl5WWdPXtW169fV1tbm+rq6tTf36+pqSk9/fTT6ujo UKFQ0OXLl3Xz5s2N3m70YgMAAAB2J670AQAAAAB4C2OMurq6dODAAWUyGSUSCdXW1qqlpUVL S0vKZrNaWVnRyMiIGhsb1dbWpmQyqdraWu3fv1/ZbFbj4+PyPK+Ky8R6AQAAALYTerABAAAA ALDGsizt2bNHTU1NikajsixLYRiqVCppYWFBsVhMkUhE2WxW2WxWra2tikQiMsbIsizV1NQo Eolobm5OpVJJkUik/IUI32W5XMlyVsM/AAAAAB89AjYAAAAAANYYYxSNRhWNRjdeKxaLGh4e 1t27d7Vv3z5lMhlNT0+rVCopFottDANpjJFt24pGoyoWi/J9v6zvLpVKKhULCoyjhYWFjdcD L1ShFKjkhVpaKsmZt2TZq4FeLBaT67qsOAAAAOxavu8rm83e9wgR8/PzymazW75cBGwAAAAA ALyHQqGgwcFBnT9/XplMRkeOHFEymdTU1JSMMXKce2+r10O2MAwVhuF9f08Yhpqbm9Pk1JxC WfrBD37w5s98o+JoWrrdpBEzLvfOiowVKp1O6/jx42poaGCuNwAAAOxaKysrOnfunCYnJ+/r GntpaUm3bt3S8ePHt3S5CNgAAAAAAHibMAyVz+d1584dXbx4UbFYTCdPnlRzc7Msy5LrunIc 5x1P0YZhKN/3ZVlW2cM52rYtx3EUyFYymXzzM30jKx6VF7HlJqKKJUMZS4rFYrJtm5UFAACA Xc2yLMXjcaVSqft6fxAE94xIsVUI2AAAAAAAeIswDJXNZnXr1i1dunRJDQ0NevTRR9Xa2irX dRWGoSKRiBzHUT6fVxAEG7/neZ7y+bwaGxvf0bvt/RhjlKmtVdFEFcjWU0899WYDgS9N9ZY0 GYRqe7RVdV22LMtsDGdJ7zUAAADsZvF4XA8//PDGdfcHXcvPzMxoenp6y+cvJmADAAAAAOAt CoWC+vr6dP78ebW3t+vRRx9VY2PjPb3F1p+gnZ2dVaFQUDQale/7WlhYUKFQUG1tbdlzozkb Pdice57O9b1Qy4miItGS4omIUklXlm1YUQAAAHgg2Pa9Izzcz/U8PdgAAAAAAPgQ+b6viYkJ vf766wqCQK2trQqCQDMzMzLGyLIspVIpJRIJdXZ26vLlyxoYGFBnZ+dGMJdKpdTa2lrh8I1G Mu94ZePpW2OMZAjXAAAAgPe8ojZmy3uvSQRsAAAAAABsKJVKGhwcVF9fnyKRiF599VW5rrtx g15XV6dTp05pz5492rdvn6anp3X58mUNDQ2pUChoZWVFx44dU2NjI0M3AgAAALsYARsAAAAA AGts21ZnZ6d+7ud+7l3neIjFYkomk7JtW7W1tTp58qTGxsa0vLwsY4waGhq0Z88exWIxigkA AADsYgRsAAAAAACs3yQ7jjo6OtTe3v6e77FtW8YYOY6j+vp6ZTIZeZ638dr6z6vKSMbSO4aP BAAAAPAR3TtQAgAAAAAAVq2HZPfLsixZliXXdbdyoRRNGqU7X3T+5AAAIABJREFUbUXihowN AAAA2AYI2AAAAAAA2MYsS0o1OYrVWHIT1mpPNgAAAAAfKQI2AAAAAAC2MyNF4kaRmM0QkQCH AwAAsE3w3BsAAAAAADsBLevAg30IMJITMzI8Lg8AwLZAwAYAAAAAAABsd2sBm+WQtgMAsB0Q sAEAAAAAAAA7gLFEb1YAALYJAjYAAAAAAAAAAACgDARsAAAAAAAAAAAAQBkI2AAAAAAAAAAA AIAyELABAAAAAAAAAAAAZSBgAwAAAAAAAAAAAMpAwAYAAAAAAAAAAACUgYANAAAAAAAAAAAA KAMBGwAAAAAAAHYtY0mSoRAAAKCqCNgAAAAAAACwa9lRyXFFxgYAAKqKgA0AAAAAAAC7kjGS HTGyXLP6PwAAAFVCwAYAAAAAAIDdi1wNAABsAQI2AAAAAAAAAAAAoAwEbAAAAAAAAAAAAEAZ CNgAAAAAAAAAAACAMhCwAQAAAAAAAAAAAGUgYAMAAAAAAAB2EkMJAAD4qBGwAQAAAAAAADuE 5UqWTR0AAPjIz8mUAAAAAAAAANgZnJiRE6ELGwAAHzUCNgAAAAAAAGAnMEbGkowxDBMJAMBH jIANAAAAAAAA2EkI1wAA+MgRsAEAAAAAAAAAAABlIGADAAAAAAAAAAAAykDABgAAAAAAAAAA AJSBgA0AAAAAAAAAAAAoAwEbAAAAAAAAdi+z9g8AAKCKHEoAAAAAAMBHLwwlKZRCalF+7UL5 vq9SqaQwpICV1tDzPHmep12zERrJiRrFai3ZjtnyjC0IAnmeJ9/32aA2W0PPoxgV8n1fQRAo DAOKUSHP8xQEPueTTZ5PwiCghpuo4eo1DTXc7gjYAAAAAAD4iIVhqGKxuNowb3OrXi7f9zU+ Pq7R0RH5nidj2RSlTIVCQaOjo5qamlTg746GecsyqmlxFElaitdaMlucsOXzed29e1dzs7M0 iG5iOxwYGNDM7AwBUQWCIND8/Lyyy4sq5OsVBNSwkhpOT08rt7wkr1SiIBUolUoaGxtTIZ+V 7xOWV8LzPE1NT6uYy7IdbnNctX+IN0sr2ZwKhaLCMJDruorHYopEXIoDAAAAAA/4/aIkFYsF BX4oy6Zhvly+72t0dFS3+/vl+Z5cArayFYtF9fX1aWx0VH6wO3pgGUuKpS1FayxZH8Iwkblc TpcuXdL8cm5LAjZjVv/t5glfCoWC3njjDU1NTioMOBZWcj6Zm5vT0sKsCvkWgt4KBEGg8fFx Lc3PqlQqUpAKlEolDQ4OKr+ytNYrGuXyPE9Dg4PKZ5dUKhXZl7cxArYP6cC8sLikH716Rjd7 b6tQLKq9rVVPPPaIDvV0KRqJUCQAAAAAeICFYbj6j1JUXD/f91ef8qYRqmIbQ/PtohJuhFIf 0nZYLBa3rNeQMVKywVJ4yFEkYXbltHJhGKpQKDDM5iYEQaDAZ1i5zVgdZpMhIjd7PglDhr3e 7HYYhgEl3OYI2D6Ek9rtu0P6H/7p/6nXz13Wga5ORaIRjY5NqDaT1te++mV97Re/ItdhVQAA AAAAAOxkW9kgb9lGmT2Oapod2a60KxM2ABwLsVpDSrAjkOpsseHRCf3Jf/orXbnWq3/yD39V T3/spOLxmHr77ujf/+m39dd/+0Pt7WjTZz/1DMUCAAAAAADAuzOS7ZrVcA0AAHzkLEqwtcYm JvXDV87o6KEDevGzn9Khnv3q6mzX0x87qY+dOqGlpRX9+LWzFAoAAAAAdqgwDBUE22s4rmov 01b8jUEQbNlQettx+dZrWO1l3M69BLZ7DbfjvrvVNdyqdbJda7hVx65qfh413P3nk51yTt7O x0Kuazgnb1cEbFuoUCxqfHJK45NTOnniuBob6mRbqyVPJuI62L1PmXRKt+8OaXFpmYIBAAAA wA6yPlfQ7OysxsbGNDk5qaWlpY987qAgCLS0tKSpqSkVCoWq/J25XE5TU1PKZrNVafjwPE9z c3Oan5+X53nbbt36vq+FhQVNT0+rVCpVpYaLi4tVWyeSVCwWNTU1pYWFhW3ZoOd5nubn5zU7 O1u1Gi4sLGhyclLFYrEqn7eysqKpqSnlcrlt2aC3vp/Mzc1VZT956zqpxueFYahsNlvVY0O1 FQoFTU1NaWlpqSrLVywWNT09XbX9LgxDLS0taWJioir7yVac59b3k3w+X7UaTk5OamFhoSqf 5/t+VY81W1HD5eXlLTknr6ysVHWdLC4ubsvzSbW3w/X9bmpqqirnE0kqlUrb+pxcKpU0PT1d teO/7/uanZ3V5ORk1c7xuVxOExMTWlxc3FEhGwHbFspmc5qanlUQBOru6pT1tll1G+rrVFeb 0cLikqamZykYAAAAAOwg+XxefX19+tGPfqSXX35ZL730ks6cOaPJycmPNGQLgkAjIyO6cOFC VRqVwzDUzMyMzp8/r8nJyao0euTzed24cUO9vb1VC5yqqVQq6c6dO7py5YpyudymP8/3fQ0P D+vcuXNVa+jPZrM6d+6cBgYGtmVjXrFYVF9fn65fv658Pl+V7XpgYECnT5+uyjoJgkATExO6 cOGCZmdnt204VM39pFAoqLe3Vzdu3KjKOgnDUNPT07pw4YKmp6e33XYYBIEWFhZ07tw5jY6O VmX5stmsLl26pLt371YtpBwaGtLrr7+u5eXlbbcdBkGg8fHxqu4nuVxOp0+frtqxq1gsqr+/ X9euXduWYbnv+xodHdX58+erEr6EYajZ2VmdP39eExMTVanh8vKyzp49q6GhoW15PgmCQJOT kzp37lxVtsP166SzZ89WLejN5XI6f/687ty585E/aPVey3f58mVdv369KueTUqmkW7du6dy5 c1pZWanKsXB2dlanT5/WyMjItqzheyFg28qbrUJRS8srsm1bdZmM3j77bCIeUzKRULFU0vzC IgUDAAAAgB3C8zwNDw/r/PnzisfjOn78uPbv36+JiQlduXKlaiFKJdZ7laz3vqpGwLbeC6RQ KFTl71pv+F5cXNyWjSjrvQCr1XNI0sbT957nVa3XxnoPhu3aILq0tKSFhYWqrOP1HgzVCrDX t+vp6WkVi8VtGbCt96SsVq+SIAi0uLio+fn5qm0z1T42VNt6r5JqhLLr62R6erpq+9368Xpi YmJb9uYNw1D5fH5jP6lWDScnJ6vW++qtx+vt2ii/3uOsWj191ntSVusBFc/zNDk5uW17oq5v h9XqcfbW3rfVPCdPT09vy6A8DEP5vq+5ubmqnpPXe+ZX63yy3jN/u26H78XhtmhrLyY9z5Mx Rq7rvD1fk2VZsm1LQRBqbn5B33vp1U1935VrNxUEoWbnF/XKmYuyLPLTcvX2D6hQLOnu4Ihe Pn2BglSg/+6Q8oWibg8MU8My3ey7q+XlrEYnJqldhW7dHtByNq/h0QlqWHENB5XNFTQwPEYN N3EczOWLuj3IcbCSG88gDDU+Oa1zl69pcGScopRpbn5BxhiNTkzp7MU3VFeboShlmpicUihp ZHxSpy9cVbomRVHKNDA0oiAMNTQ6odfPXVYiEd+1x6wrly5qfn5O6foWTS+syPN85T3pBy+9 otnFrNo7OmRZ9gd+lud5utXbq6mZORUVkR0JN3UO8TxP/X23NHB3QOn6q6pvGJd524gq5d7b jo2O6NbtATnxGk3Nr2z6fnNlZVnXe2/Ltm0ZN6FEMrnpRplbvb0aGZvQwmJOTqS0qRoW8nld v9Gn+blZpWqvqCad3tTy+b6v3pu9Grg7qPoLV1VXX7+pdSJJCwsLunV7QHkvVEmOHMetyjoZ HhvXwuKygtBsqoa5bFbXbvapkM/LjaeVqqnZdA2vXevV3TuDev38ZaXTmU1/3tDggPruDCqa qtXI5Nymt+uF+Xn13RlU0ZcWFlcUcWc3VcPsyoqu996WZVmyIslN7yfZbFbXevtVKpUUSWaU TG7uHBcEgUaGh9R3Z1BuvEbjM4uybXtTn7m0tKhbtwc0t7SixZWsxiemK65hEASamZnWrdsD Cu2olvL+ppdvcWFBvbcHtLCcVzF0FIlENl3D3pu96r87pNMXrqi2tm6Tx2tfI8PDKhSLmltc 1JXrt5TNFze1nwwO3FXfnUHFUnUanpjd9H6yuLig/rtD8o0jz0Q2vU7yuZyu3exTdiWraKpO qVRqUzX0fV99t3pVKnmanVvQpTduaHZ+cVOfd/t2v/pvDyhd/4Yahic2VcMgCDQ+NqZbtwdk RRKaWcze17XG+5mfm1P/3SEFVkQ5z8hxnCqsk355vqfp2TlduHpdE5sYvW31eD2ovjuDSmau bXo7XF/Ht+8Mqu7iVTVs8jrprceupWxRgR2T627unOz7JQ0PjVT9AZqdNr/ZTmBCqrplxiem 9M1v/aV+/5vf0j/7H/+hPvvJZ2Tbb+7812726Rt/8Me60duvX/75n9Y//fV/vbkbilJJS8sr chxHrmPrHYkePvhG1PdVKpXkOs6mTyYPbg09lUoeNazwBF/yPFmWpcgmT8QP8vbneb5s25Lr UMPKa+jJth257MOV1dBbraHDcbD8i32FyuXyG9cyxvCwUCU3TLn8eg2dTd8oPoiCMFA+X9i4 lqGGFdQwCJQvrNXQdWR26X2JVypoZX5KthNRItOw0bjlFfNamp1QNJFSPFUncx8NQGEYKr+8 oKX/n737DI7rvPc8/+0cge5GRiPnTAAkmMQcxaBEyoqWJWffWV/Pbm3NTtW+2XXVzt3d2dq7 d66vx0EOkiiJIsUgkiIpMYg5gySInHMODTTQOZzufQEK1zTpsYimryHP86niG6lx0Pidc57z nOf/nOfYhtGY4lDrjOi0uojaAq9rGp/bidEch1Ktiej+MBwOE/C6cTsm0UVZUGsNEZ8bUjCA 2zGJDDn6aAtyRWTXzHAohMdpx+d1oTFaUChVaNSaCI5jCY/DjhTwYTDHo4iwbzm7j+34PE6M 5oT7+yTC+4eAH8fkKGqdAV2UOeLrphQM4J6ZJEwYlS4KuUKFJoLiQUgK4nFMEQqF0EfHPJEM PY4pfG4H0XHJKJTqiLfn9zjxuqbRRcWg0ugiP67v7xOlRodSa0AuV0RUgAlJQVwzNmTI0EfH RHyehKQgbscU4Se0TwiH8XtduB1TT7RtcE6NIVeqUGqjUCiV878/DocJ+L247BNoDdFoDNFP ZB877eOoNDp0RvNXauO/SvvvcdmJjk1GqdJEvL2A18XM1ARaowmdITqiAlY4HMbnceB1zqCP jkGt0UHE+9jPzMQwGn0UuihLxPtktq2xE5KC6E2xT6a9dk3jtNswWBLQ6gwRFXPC4TA+9wxe 1wwGUxwqjTaiazLhMH6fB/eMDZ3RjFpnjDjDYMCHY3IUrT4KrdEU8fUkJAXxOO14PW70plg0 Wh1yWWQZ+j1OPE47+ujYiI/DuX6Sy4HREh9xP+nLtssxOYJKo0cfbYk4Q7VKQbzZQH1DI2++ 8Tr/4Sc/Ijc7Y95/r91u5+zZs2i1WtatW0d0hBOH3G43V65cYWhoiGeffZaYCCcOSZJEb28v X3zxBZWVlZSXl0dcpBwfH+fw4cPk5uayevVqNJrI+16PIkZ9/oI0GjVGg+H+I/gO4MFaptfr w+P2oFKpyMlK59999/WIfl9rRxdHT35BeqqVjLQUxFjA4xseHaeju5eMVCvpqVYRyDwMDI/S 2zdAemoKaSlJIpDHMDo2Qe/AEGZTFPk5WSKQeZ7DfQNDxMVYyMlKF4HMw+DIGH39gyQnJpCZ niICmU87ODRC38AQaSnJpKUki0AeQyAocfl6NcmJ8WSkWtHptCKUx+T1+bl8vRprUgIZaSlo NWoRymNyuT1cr64hJTmRjLQU1GoxYeNxzThc3L5XT2pKEhlpKX+TEzbC4TBOxzQDPRossXHE J1lR3B/49nk99Ha2otXpSU7NQPUVCimhUIiJ0WFaGjzINDpUOi2Ly0v+7M/J4JEDTOFQCNv4 KPbJCazpWej1xgjH8sI4pu2MDvWTkJRCtCXyp68Cfh8jg/3I5XISklNRRfgUiBSUsI2PMDoy TAA1SpWaRaWFEWwvyPjIEB6Pi5S0LNTayK5J4VCIibER7JMTpGZko4twnwD4PB76uhWYzLHE JVkjfqrky33icntwB0Gt1lJalDfv7QX9fsZGhggGAySlpKHWRJ7h+MgQU5PjZOYWotHqItxe mOmpCSbGRkm0pmKMNkV8XHs9bvq7lYQVKpzeEDqdlqL8nAj2iZ+RwT5kcjmJT+A8Cfj9jA0P IEkSySnpqDSRF3Nm7FOMjwwSn5RCtMmCTB5Zhn6fl/4eNf5gGLc/TFR0FPk5mfP9grhdTgb7 uoiJSyImLiHi7+fzehjo1WCMiiYuwYpCqYg4Q9voMBNjI2TmFqLV6yPensM+xa1qO9FRBvJy szGZoiI67+yTNmzjoyRZUzE8gfPE5/XQ0yHHEjN7/Yy0SBkMBBgfGcTv95Ocmv5E2prJiTGq q+1YTFHkZGdjNOoj255tnMnxUazpWbNPjkZYHHLOTDMy2Ed8YjKmmLjI2y63m74uBZa4BGIT kiK+nszukyHqG5uJNZvIyszAYIhg4lAozLTdxvjIIMkpGRijTZFlGAozOTHK5MQoKRk56PWG iAvHfq+Xvm4lxigTCckpyCN8MlOSJCZGhiEcIhDw43a5cDqd8z5mXC7X3FK5LlfkKxF4PB7c bjcejweXy4VarY64wOZyufD5fHg8HpxO50MFtnA4/JWf6AuHwzgcjifyvtE/RxTY/oKijAaS EuIIBoN09w0QCof5w1PLNjnFhG2KKIOe8uJClpSXRvT7Pv/iEhev3uLlXTv40VuviiUi5+GT E6f5z//8Nq9941m+/8bLIpB5+PDAMX71zl7efPUF3nxllwjkMRw/dY639+ynqryU/+0//kQE Mg+Hj5/it3s+ZsOalfwvP/m+CGQe9h85wW/e28+uZ7by4++9IQKZVzt4lLf37OeNl5/n26+9 KAJ5DDMOB0s37Wbj2pX86K1XSE8VRd7HNTw6xtJNu9m6cTU/evNVkpMSRCiPqbOnj8273mTH lnX88K1XiYuNEaE8pvqmVl5868c8u20TP3rrVUzRUX9zf2MoFKKjo4PTp0+xtGoplYsrUd8v pNntU3z66XF0Oh2bN2/CbLb82e0FAgHu3LnNP/zD/8XQhB25El7Y8tSf/TmZTI5GrUbxR0VM KRiks7OT3t5eKhcvJjY2JqKZ1KFQiOHhIRobGigsLCI1LS3i+023y0VdfR0KhYKS4hL0en1E g1sBv5+2tjbu3qtlcNyOQqnm9ee3zHt7Pp+PluZm7NN2Fi9eQtQTWN6wva2Nnt4eli1bhsUS +ez2mZlprl1TkZaaRkFhQcRLRH65T/oHh+noHcFoNM4/w3AYj9dDc1MzPr+PsrIyjMbIM2xu aqK3r5e1a9bO7pMIB/P6+/ro6OygpLiExKTIB5Wnp+1cv67G45No6uglIc4cUYZut5u6+jrk cjmlpWWz50kk+9jtprGxgWAwyKJFizBEOKgcCoUYHBykpbmZwqIirFbrE1gi0sGtWzompmZo 6ewnyxo37wzD4RC2CRu37+jIycklOzs7su8XDjPjmKG6Wk9CfAIFhQVzbX8kGba3tdHW1sqa NWsxm80RH9dDQ0PU1VSTaDGyeVUleRFM4JUkib6+XjraOygrKyMhMTGy8+T+oPely3IyMzIp LCp6IktENjc343a7WVReTpTRGHGGnZ2d1N69hTUumqfXLiEjLXX+2wsG6e7ppquzk8rKxcTF x0V8TR4dGaG+Por8/ALSMzIibrvsU1Ncv64iKyuL3LzciK8nX+6TpsZ6UhNNbF+/lFRrckT7 ZKC/n+aWZirKKyI+DiVJorOjg67uLqqqlkbcT/qy7bp+TUVSUjJFxcURP33l8/lobGzg7t3b DPT1cOPGdXp7Oue9PZfLRWNjIxqNhnA4jE4X2SQVv99PY2MjNpsNk8kUcT8pHA4zNjZGa2sr gUAAm832UNsQCoXw+Xxfucg2MzNDW1sbpaWR1Vz+HFFg+wtSKBTEx8WQlmrlyo07/OQHb84u M8PsUoRtXb1MTk+zbtVy9PrIlyL4chkgtUqJXqcVBbZ5UKtU9zNUoRez5ueXoVqFTC4ynF92 ahRyOUqlUmQ3Txq1GplcjkolMpx3hioVcrkclTgO5389VquQy+SiHZyH2Zd+y1ApFWi1WpHf POjuP2GhUirRajUiw/lkeH82v1IlMpyv2ScnZaiUSnR/oxmGQiF0Wg1ajQadTotep5tbBs7n 1aJRq9Bq1Oi+YlsWVCmJj4sjr6CAofHruJ0zdHd1/dmfk8lm35Pyx/d+4XCYQCBAYmICE+Nj TE3aIh70CAaDJCUl4XQ66OxofyIZGvR6ZDIZ/f19Ed+/hsNhwuEQJrOZ9u4BANrbWiPankIh x2I2MzQ48ES+nyQFsSYnMzY6im1i4olkaE1OJhwO0dXZGfkya/f3iUqlwuWYRgp4I8owFAqh VqtQqZQMDgw8oTGKMKkpKQwNDT6RfRIMBkmIj8dun8LpdET87SRJwpqcTGdPH84ZO0pZKOIM DfeLav19vRH/zaFQCK1GAxoNA/39T2SfBINBEhMTcDpm6Op0P5HjOj4ujqlpBy7nNLaJ0Ygy lCSJ5KQk/D4vXZ0dT+z7yWTQ0939RJaSDgYDpKenMzIyzPj42BM5rtUaLX6fh/6+XpD8EW8v MTGBqalJHI6ZJ5JhakoK4XCIzo72iDMMh8OoVEqio6OeWHsdCARQa/S4nA56e3rwe1wRby8p KYmJiXHs9qkncD2RSEpKwu12PZFrsiRJWK3JSFLwiVxPvtwncoUSx/Q0vT3deJwzER+H1uTk J3IcfrlPrMnJT6Sf9OVxnZSUhFwuo7vryWQoQ4ZCoWB6aoq2tjZsE2MRfT+tVotMJqO9vf2J nCehUAiTyUR3d/cTu55YLBZmZmZoamp6KMMv99tXfeNZKBQiISGB6Ojov+iy/6LA9hckk8lI T01m28Y1/PKdvfz8t+/zzNYNGAx6bt6u5cyFKyTExbJl3VPi3Q6CIAiCIAiCIAhfo3s9tVqN SqXC7/c/cKMfCoXw+/1ER3/1994oFAoyMzPZtm0Ho3Yv9ukZ3nzzza/8XYR/VV1Tz5Q7jBSS ePXVV0Ug83Ct+i4TziBGvUFkOE8Xr91idNpPUmKCyHCevrh0jWG7l4LcHJHhPJy8fJe0lGS2 79hJaVG+CGQePjlzg8KCXHbs2ElBXrYIZB72fnqBorIKdj7zLDmZ4jUej8vr9bHnyFlKyhfz 7LPPkZ4mXmf0VYtrX5LL5ZjNZpR/wSXrRYHtLywuxsLTG9fQPzjCqXNXqG1oQalQMDllJ8Zi ZvvmdSwqKRBBCYIgCIIgCIIgfI1otVo0Gg0OhwNJkuZu+r98d4TRaPzKywPJZDKioqJITEoi 2mQmEIKsLPFO3vnoH5nAGG1CkiQyMzNFIPPQ1T+MMcpElNEoMpynlq4+DFHRmMwWkeE8JbR2 oTdGY7bEiAznQW+IItpkJtlqFfnN9zqvNxJttmBNSREZzpNGZ8BktpAiMpwXj8eLWqvHbIkh JTWVTFGknJe/9GQ0UWD7C1Or1eRmZfC9N17i8vVqhkfHkSSJRaWFLCopoKK0iOioKBGUIAiC IAiCIAjC1+hG3Wg0Ehsby9jYGNPT06jVaoLBICMjI0iSRHx8/GO/f+MPBwDEk2nz3zciQ5Gh yFBkKPxrdiI/kaHI8G+jHRQZLkyiwPZvQKNRU1qUR0lhLjMOJ6FQCL1eh+b+Gv2CIAiCIAiC IAjC14tOpyM3N5dLly5RW1tLbm4ubreb+vp6rFYrVqv1Ky8RKQiCIAiCIAjC148osP0bkslk mKLF02qCIAiCIAiCIAhfdwqFgvT0dCorK2ltbWVsbIxgMIjRaKSyspKYmBgx01gQBEEQBEEQ /oaJApsgCIIgCIIgCIIgPKYvl4lctGgRqampOJ3OuRepWyyWx14eUhAEQRAEQRCErxdRYBME QRAEQRAEQRCEeZDJZOj1enQ6HaFQCAC5XC6eXBMEQRAEQRCE/w6IApsgCIIgCIIgCIIgREAm k4n3rQmCIAiCIAjCf2fkIgJBEARBEARBEARBEARBEARBEARB+OpEgU0QBEEQBEEQBEEQBEEQ BEEQBEEQHoMosAmCIAiCIAiCIAiCIAiCIAiCIAjCYxAFNkEQBEEQBEEQBEEQBEEQBEEQBEF4 DIqf/vSnPxUx/G3w+nyEgaWVi8jOSEMmk4lQHpPH60OpULC0oozM9BQRyDy43R40GjVLKspI T7WKQB7r+POiVCopKcilMD9HBDLPDNUqJWXF+eTlZIpA5nMOe7xo1GoqyorIzkwTgUTSDpaX kpEm2sHHEQ6HmZicYtnicgpys9DrdCKUxyRJEpNT0zy1rJL8nCy0Wo0I5TEFgxIzDicrl1aS l52JRq0WoTymQCCI2+NhxdIKcrMyUKmUIpSvyB8IAJCWYmX5knIRyHwy9PtBJiMzPZWqijIR yDz4/H5kcjk5WelUlhWLQObB6/OhkMvJz8lkUXGBCGSeGSoVSorycyguyBWBPKZx2xRFeTmU FORiNkWLQOZhbGKS0qJ8ivJziI4yikDmYXTcRmVZEYV5OUQZDSKQx70/Jsz4xCRVFWUU5mVj 0Iv744VIFg6HwyIGQRAEQRAEQRAEQRAEQRAEQRAEQfhqxBKRgiAIgiAIgiAIgiAIgiAIgiAI gvAYRIFNEARBEARBEARBEARBEARBEARBEB6DKLAJgiAIgiAIgiAIgiAIgiAIgiAIwmMQb5te AKZnHLR2dDM5ZWfNyir0Oh0ymeyBz4RCIewzDqpr6ujpHUQul5GXnUlZcQGxMeYHPhsGAoEA 1Xfr6OjuxecLkJKcSFlxPump1od+vyRJNLd10tLexYzDiUGvJyczjYpFxSgViq9FhlPTM7R1 dDPjcLJ6xRK0Gs0jM5ycsnP7XgM9/YMo5HIKcrNZVFKlMpUaAAAgAElEQVTw0Atfw+Ew/kCA m3fu0dndTyAQJC0lmbLifFKtSQ/9/kAwSENzGy3tXTgcTmItFkqL8ijIy17w2YXDYfoGhmhs aWd03IZCoSAtJZmVSyvQqNUP5BgOh5myT1NT30RXTz+EITszncryYiym6Icy9wcC3LnXQHtn Dz6fn+SkBBaVFJCWkvzQZ8PhMA3NbTS3dTI948Bsiqa4IJfigtyHPruQTE5N09DcRk//AKFQ mBRrIiUFeViTEh76rMPpoq2zm6bWDjweLwnxsayoqiQ+LgaF/MH5Dl6fj/6BYW7XNjA5ZSfG bKKqooy01GS0Gs0jv4vb4+X2vXpUSiW52RnEx8Z8Lc5f25SdusZW+gYGARlpKUkU5eeSnBj/ 0GdnHE5a2rtoae/E5/OTmBDHiiUVxMXGIJc/eJx4vF56+we5W9eEfXoGi9nEssWLSLUmoVGr H/hsUJIYG5+guqae8YlJdDotedmZ5OVkYvkavBB6wjZFbUMz/UMjyOUy0lOtFOXlkJgQ98hr TlNbJ20d3fgDAaxJCSyrXERcbAx/fKq5PV66e/u519DMjMOJxWxiRVUF1qQE1CrVg+e7P0D/ 0DA19U1MTk0TZTBQmJdNTlb61+KF0OO2SWrqmhgcHkWhUJCZnkJhXg4JcQ+fR/bpGRpa2uno 6iUYDJKakkRVeRlxsZaHPutye+js6aO+sRWH00VMjImVVZUkJcajUv63u2FdPX109w6QlBBP VkYq+gX6QmOXy82d2ka6+wcIBiUS4mKoKC0iJTkR+R+1baFQiJr6Jlrbu3G53MTFxVBamEdu dsYjrwvtXT00tnQwYZvEoNdTmJdNRVnRA9sdHh2nq6ePySn7I79fSnISOVnpmKKjFux12OF0 UVPXSHffIFJIIik+nopFRSQnxD8ywzu1DbR1dON2z15LSovzyc5Ie2SGLe1dNLV2MDllJ8po pDA/h/KSgkdeW50uN+1dPTQ0teHx+bAmJrBqxRJMUcaHvsdCy3B6xkFNXRM9A0OEQhLJCQks Li8hIS7moe8eDAa5fb9/4vX6SEqMp6y4gIw06yMzbGrtoLm1g6npGUzRURTl51JalDf32UAw yO2aeiZsk//N77m4vJSkhDgUC7B/HQ6HmZya5l5DM32DQ4RCIaxJiVRVlBJrMT+Uod/vn8vQ 7w9gTU5kUUkBqdakR2ZY39xGy/0+nsVkorgwl6L8nIc+K4VCdHX30djazuTUNBqNmsy0FJYt KUepVLJQe4QOp4v2zh6a2ztxuT3EWkyUFuWTkWpFrVY/kJ/X66O3f5Dqe/VMTtqJiTGxrLKc jLQUNJoH+yeBQIDh0XFu3r7HxJQdg15HaWE++bmZGA2GuXwlSUKSJEbGxmlobmd4dHyuP7io pJAoo2HBX4dnHE5aO7pp7ejC4/ESG2OmrCifjLQUVCrVA8eKx+ulq6efO7UNTE87iLGYWLG0 kjRrMmq16qFth0IhHA4nN+/WEWU0UJCbRYzF/MD/lySJUCjE1PQMtQ0tDAyNIJfLyc1Kp6z4 4fvFhWps3EZzWyfdfQP4/X6SE+NYUVWJxWxC+Uf9jhmHk6bWDuqbWvD6fKRak1lRVUlCXMwj 26lgMMjg8ChtnT0kJcSRmZ76wLH15XGoUCjo7Omjb2CYtJQksjPSUKlUX4v87NMzNLV20NHV i9/vJzEhlrLiQtJTrQ+1g06Xi7bOHuoaW3C63MTHxfDU0sUkJ8Y/lPXs+RxkemaG6pp64mIt FORmz/WR//A8DofDTE3PcK++efZcVqnIykilMDf7kX3NBTc2Y5+moaWdrp4+gsEgSQlxlBTm k5aS/NBx5XS5aGnror65DbfHQ2J8HE8tW0xifOyfPAZtU3aqa+pISoinMC8Ho0H/iAxhdHyC 2sZWxidsaDUacrMzyM/JxGI2LdjsQqEQt+/V09nTj9vtwRQdRUFeFjkZaXPXki+Pw9k+XieN ze1MTE5h1OspKsiloqzoT/YzpuzTtLR2MO1wsOapZY8ce/zDrMPhMKFwmJu3awmFwxTmZZGU EL+gj79AMMidmnq6+gbweLxYTFEU5OWQlZ6CWq1GoVDM/c3hcJjGlva5fnK00UhxYR5lxfl/ MsMJ2yTNbZ14vT5WrViCXqd7oL8zOj5BV08/Y+MTc/9dJpPN/UuMjyM7K524mIV7Lvt8Pm7f a6C7bwCfz4/FbKK4IGf2eqxUPpRhfVMrTS3tTE3PYDFHU1pYQHFh7p+8dxgbt9HS3okkSaxc tvih8a1QKEQoFMLlctEzMERdfQtOj4fkxARWLCmfHT9b4GPVbo+HO/ca6O4fxO8PEGcxU1KU R0pyImqV6oEMQ6EQtQ0tNLd2MONwYLGYKSvOpzAv509mODw6TltHFzJg6ZJydFrt3LYCgQD1 TW0MDA0/9HNyuXzu9xYX5JGRloJSufDH/f+wnyaXy1EoFI/M5strADD3mT/VxoVCIYLBIAqF 4qHj6Q+vJzKZ7M9uC0SB7a8qGJRoam3n8PHTXLpejVqlorggF22y5oGd6/X5uFvbyO8/PEhX Tz8Wswl/wI/X66eyrIiXX9jBkopSZDIZQUliaHiUf/zF72hu7Zw7ybw+H2mpVl7YsZmdW9bP HRRjE5P8/sMD3LnXgFqtxhwdhdPtxj49Q2FeDv/+R2+SFB+3YBuvYDBIXWMLh0+c4drNu0RH GSkrykcTr/6jmzAfN+/cY8++T+jtH8Jijsbn8+PxnWRp5SJe3bWTRfcHmwLBIL39g/zTL9+h tb0bo0FPKBzG6/ORnZHGrp1b2LphNTKZjDBgt0/zi9/v5ebte4RCIZQqJV6fH1OUkZ1b1/Ot l19YsAUir9fHJydOc/z0BWyTUxgMekLSbDE3PyeT//l/+C7ZmWmolEokKcTd2gbe//goTW0d xJhNIJMxdfQzSgpz+dYrL1BZVoxcLiccDjM0PMYv39nL9ds1mKOjUCgUOJwukpMS2LVjC9u3 rJsr4AYCQX75zl7OX7mBFJTQajV4fT7UajWb1z3F99546c8ORP81XL1xhw8PfUpPbz/q+8VI j9dLUkI8r+zawbZNa+f2fWdPHweOfsbVm3cB0Ou02Gcc7Nl/hL///hssW1w+d3MwMjbBmQtX OHjsFH6/n1iLmYkpO/s+OclLz29jy/pVJMbHPXCz1tLRxe8+OEBDUxuF+dm8+cquBV9gC4VC XL5+mw8PHKN/aBitRk04zNwN/ssvbGfrhtVzn2/r7GH/Jye4eacWuVyOVqNmxunkw4PH+Pvv f4uq8lJ0utk2b2hkjM/OXuTY518Q8AexmKOZmLKz/5MTvLb7GTauXTmXj23KzrlL19l78FNc bjem6Cg8Hi9SKMSSilJ279zK4vKShXkDEQhw+cYd3t//CSOj42h1WkKhED5fgMz0FF5+YTsb 16yc+3xLexcfHjxGTV0TCoUctUqFw+UmPtbC33//W1SUFs0N7g0MjXD89HlOnrmIFJQwRRtn j8PDJ3jzlRdYv2rZ3ODU0MgYn35+jk9PnUMKhYgyGnA6XQAsXVzGCzu2UFlWvGDbwcvXq3lv 3xEmJifR63UEgxJ+f4C8nAy+8dw21j21bO7zTa0d7Nl/hPqmVlRKJUqlApfHQ3JCPD/+/hss Kimca696B4Y4evIsZy9eJSTN5mKzT/PRoeN8742XWL18ySMH7MLAzLSDn729h9rGFl7YsYWX nt++4ApswWCQxpYOfvv+xzS2tGM2R6OQy7FPO4iLtfDis0+zY/M69Hod4XAYl8vNz37zPldv 3kGlVKJWq3B7vERHGdmxZR2v7to5NyAVDAb58MAxPj93GYfDiV6vwx8IIEkh1qxYwt//4Fvo tFpkMhkNzW18fOQkLe1djxzQ2rR2Ja/s2rEgC2yBQJDahmZ+v/cgre3dmE3RyOUypuwzJMbH 8uruZ9i87il0Ou39SS4z/Mtv9nC9ugadVotKpcTl9hBjMfPM0+t58dltc9fWYDDIu3sPc/rC FdweL3qdFp8/AMD6Vcv4+x9864GCRWd3H0c/O8v5KzeRAXq9jrEJGweOfcZPfvgmpYX5aP9o 8H8h8AcC3K6pZ8/+I7R39cxmKJMxOTWNNSmBb770HOtWLUOnnc1wbNzGf/3dB1y/fY8ogwGl UoHT5SYhPpbnt2/i2W2bHuif/GbPfr64dB1/IIBOq8Hr86NUKti4ZgU/+vZrqJRKfD4/hz49 xZ3axkdf7ySJoCTxv//HnxAbY15w/Wq/P8C16rvsPfApXX39mKKjkMtk2KbspFmT+fZru1m5 tBKtVkMoFGZweJRfvbOXG7fvYTZFo1DIcThdWJMS2fXMFrZtWvtAhr/43Qecv3qTUCiMVqPG 4/Wh1WjYsv4pvvPNb8y1mbb71+lL16oJA3ExZrxePyNj42SkWvnJD98kJyv9oQkef211jS0c Pn6a6rv1SFKAsCQxZZ9CIZexc+tGdj27jdycbDQaDSNj45w8c4GPPznBzLQdo07LjMtFdLSJ 1196ge2b189NjhmfsHHq7AV+s2cvHreXGIuZsFyBSq1h3arlfOPZp0m1JmGz2RgeHubc5et8 cfEaDo8Pk8ky19eqLCvmB2++QmZ6yoLtE9bUNXHw2OfU1DciBQJIUoDp6Rk0GhXPb9/CN17Y SVpqKkqlksHhUY59fpbDxz7D5XBg0Gtxur28v9/Mt19/ic3rVj1QhPB4vVTfreW/vv0evQPD LF9ayffeeHmuD+P3+xkfH2dwaIjG5jaOnTrPtMON2Wy+P+kySElhHt9+bTfFBbkLNsNwOMyZ i1c5cvwM7Z3dhKQAUjDAjMNJXIyFv/vet9iwdtVccaGptYOPDh7j3MXLyMIhDEY9DpePjPQ0 vvetV3hq2WL09/vVXxbjjnz6GfuPnMDucLNr51ZefG7bXIEtGAwyMTHBwMAgt+uaOXe1muGR Md56dRfJiQlfiwLbzTu17Dt8gqaWNqSgn6Dfj9vjxmQy8dKunbyy6zmio6OQyWR09fZz4MgJ Pj9zHp/Xg0Gnw+3z835sLP/uO99k9YqqB/od0zMOzl+6wjsfHmDMNs3aVSv4wZsvEx1lJBgM MjU1xcjICOMTNu7VNXH64nX8wRBms5lgMIg/GKQoL4dvPPc0q5YvWbAZXrt1l48OHaeto4uQ FMDv8+LxeIiJsfDS8zt4+cXnMRoMyGQyOnv62HfoU86ev4zf60Gn1eAJBHjvo1j+/gdv8dSy xQ8UcKempzl38SrvfXiAUZudjetW8e++8zpGg55gMMj09DTDw8MMDY1w4849Ll6/jUKlwRQV hcfnR5IkSovy2LVzK08tW7ygcpNCIUZHx/mnX75LbWMLWq0aGWCz2VDIwiyrLOOFZ7aSlZlJ bGwscrmCd/Ye5PS5y8zMzBAOBfF43CgUKjasXcV/+Pc/nJuE8eX5WdvQwoFjn3Hx8jX0utmC Y1ZG+iP7JH6/n6GhIWYcDmoaWjl84ixRRiM/fOuVBVtgkySJ/sFh/uXt96ltbMFg0BIKSths E6iVCp5aupgXnn2a7KzM++07/Pq9fZy9cBW3y0FICuLxeNBoNWzesJb/8e++i0GvfyDD2zX1 HDh6kstXb5AQF0tRQc7c/Ug4HMZut3Pu/CWOfnaW5taO2fsSGSiVKrR6AwqFkpVLK3j5+R0L ssAWlCS6evr4xe/2UtfYQpTRgCQFmJiYQKdWsfappTy3fQvZ2VlERUUTDof5l9/s4dyl63g9 LsJSEI/Ph9FoZMfWjfzdd994oHgWCAS5cfse+w9/ys1bt8nKyqAwP4fkxIQHxjdsNht1DU18 cfEqV2/eRa3RkJCYyMSknQNHP+O73/wGK5dWPFDcXEj3x60d3fz63X3UN7dhijYSCgYYGxvD oNOyfvUytm3eQHZWJtHR0QSDEj97ew8Xr94kGPAhBf24PV5M0dHs3LaJH7z5Glqt9oF8rty8 w8eHT1B99y4Febnk5Wah02qRJInx8XG6e3t5f/8RblTXPPDdZHI5Wp0BhUKFFJL48fffuD8h RLdgrynhcBiv18vY2BgTExP47o8Tx8bGkpiYiO7+JIHZsQYXw8PDTE7OTng0m80kJydjND48 UVSSJCYmJhgZGSEtLQ2LxTI3ditJEjMzMwwPD2O325HL5VgsFpKSkoiKivqTRU/FT3/605+K Ute/PZfbzdmL19j/yUma27twudz09A/y2ovP3B9c+dcd1tjawQcfH+VObQM7t27g6U1rqCwr IRAIcLe+iUAwSEaaFbMpmgnbFO/u+4SDRz9n/eoVbNu4hmVLyjHodLR2dNM3MEROVjoJ8bEA 7D14jMPHT1OYl832zeuoqigjJzOdUCjEiTPnkclkLCopfGg25ULgdLn5/ItLHDj6OW2d3Tic boZHx3h19zNEGQ0PZFjb0MIHB47R0NzOM1vX8/TGNVSUFeH1+rlTW48MGelpyZiioxgeGWPP /iMcOXGGrRtW8/SGNSxdXIZGraa5rZPh0XGyM9OIj4shJEm8f+Ao+4+cJCcrnW2b1rJq+RIS 4+Po6x/iTm0D+blZJMbHLsiZ32cvXuOjg8cJBIJs3bCaDWtWUFKQi1Kl5MTpC2g16rmnTzq6 ezl07HNu19azcc0Ktm9aR2VZEVqtluu3a/D7A6Rak4i1mBm3TXLi9Hk+PHCMNSur2LZpHUsX LyIuxkJrRxc9/YOkJieSkpyIPxDg3MXr/GbPftJTrWzduIZVK5aQlpLMhG2SG9U1pCQnkpWe umAKlaFQiPGJSf7zz96mu3eA1SuqeHrjairLitHptNyta6Sto4f1q5ej02rx+wN8ePAYX1y+ QWZaCrt2bqWqsoy0lGSu36qhvbOH8tJCYi0WJEniwtWb7D10HKVCwTe/8RwrllZQmJ9Nc1sn za0dJMTFkp2Zdn8ge4ZT5y7z9nv77s8eakOtUrGkooSs9NQF2wZKksTI6Dj/5z/9ksHhETas XsHm9aupKCtCpVJRU9dIT/8Aa59aivZ+hu9+dIhL126Tl53JC9s3s6SylOTEeK5X19DW0U1V RRlmUzTBYJAzF65y4Nhn6LRaXtv9DCuqyinMz6G+qZXmti5SkhPJSLPi888+ZfmL332Iz+fn tRefZdXyJZQW5TM5ZedefTNSSKK8pPBPPjn41+y89Q0M8w//+AvGxm1s3biaTWtXUl5ahEwG NfVNDA6NsmrFEnRaDT6/n7ff28+N6hpKCvN47umNLK4oJS7Gwo3b92hu62RFVQVRRgOBQJAT Zy7wyYkzmKOjeHnXTpZXlVOYl01NXSMtHV1kpqWSak3C6XJz8dot9uw/gsUSzau7n2H5knKK 8nMZGhmlpq4ZpUJBaVH+gsswEAjS2dPHP/zjL5iyT7Nz63o2rF7BopJCJEmipr6JsYlJVlZV otNp8Xp9/Px3H3D7Xj2VZcU8s3UDi8tLMEVHc/NOLa0dXaxeMfskeiAQ5MiJM5w4fYG42Bhe en47y5aUk5ebRfXdOto6usnNySQ58RFPKEkS7398hBNnLtDe1UN+ThaVZUULbvZ8R1cvHx06 zqVr1WzZuJptG9eweFEpsTFm6hpbGBweJSkpnoy0FJwuN6fPXeHX7+2jorSIpzeuYcXSSpIT 4+kfGqG+qfX+eTk7AHz5+m3e2XsInVbDlvWrWbdqGTlZ6bjdHk6dv4I1KZ70FCtqtYpbd2q5 eK2auLgY3njpOZZUlD7wr7KsiIxU69yko4Wkpb2Tjw4f59adWrZsWMW2TWupLCvBYjZxt66R sXEb1uQE0lKSmZ5x8NnZS7z97j6WV5WzbdNalldVkBgfS3fvAC3ts21bekoyAOev3OT3Hx7E bI5m64bVrHlqKVnpqcw4nJy7cgNrUgLpqckolUpmnC4Of3qKc5euk56Wwu5nn2ZxeQnWpAQ+ O3uJUChETmY6MZaFN+u7obmNjw4dp7ahha0bZo/DyrJiTNFR3Lxby9TUNKnWJKzJiUxO2Tlx 5iLv7j3MquWL2bZpLcuWlBMXG0NHVy+dPX2kJieRak1CkiTOXbrBbz84QHJiPFs3rGb1yioy 0lKYnLJz5cYdrPePWYVCjkajoTAv+8Hjr7yU0qJ87tQ2EAqF2L55HRmpKQuuT1hT38xHh47T 2tHFlg2reXrDbJ8m2mjk6q07OJwu0lKSSUqMZ2zCxvFT59n3yXHWPrWM7ZvXUFW5iFiLmZb2 TvoGh0hNTsSalIjf7+eLi9d4e8/HZKan8vTG1axavoQ0axLjEzZu3qmd7eNlzPbxjn32BQeP fU5cjIVnn97IsiXl5OdkotfrOHjsFHKZjMK8nAX1VPTk1DTv7j3M9eoaMtOSKc3NQC0PYo42 0N7RTW1dPbJQkMTEeIxGI+ev3OT9fYeYto1TkpdOTmY65ig9bR3ttHf1kZJiJScrHb/Pxxfn L/L//NO/MDY6ysqqchJjTWSkWZHC0NjSSUiSiDNHceXKFa7fvMWBoycZHR0jPyuNzetXUVW5 iEAgyM0793C63KxZUbUgJ/3ZJu38Zs9+qmvqyEq3kp0Sj0GjwGKKorW1g9t372I06EhJsaLR avnsi4t8sO8QTvsEiwpzyc5MxajX0NHVRUfPAJnpaWSkzT5tNDZu45MTp/jFr3/PYH83fQPD REdbWF5VQao1iWAwSG9vL1evXqW1pY29B47S0dlJcW4W2zavZ1lVJQB37jUwbptk9Yolj5zI sRA0trTz3r5P6OrtJSXBQmKMkZSkOIx6LVeu36S1tY2CvBzSUq1M2qc5eOQEhz45ikYxO3if HB+DRimnrbMH29Q0aVYrKdZEwuEw/YPD/OxXv+O9D/bidswwPDFJRnoa5SWFxMVaCAaDjIyM 8unxk/z8V7+jtasPX0Cit3+IwrxsqipK0Wo1LFThcJgJ2xT//Ov3aGhuISM5ngSLAWtCLHq9 lobGRqpv3yU/N4sUq5VwOMy+Q59y4PBRAl4XSxYVk2ZNRKdR0NHVS1fvIEUFeSQlxCGXy+nt H2TfoSP89vfvMzE6TO/QOPFxsTy1bDGxFjOjo6PcuHGDhoZGunv6eH//YUaHh6iqKOHp+/fR fr+fmvompuwzLFu8aMH1aUKhMOMTk/y/P/8d7R1d5GZaiTfpSYwzo1WraWhs5m7NPfKzs0hO SiJMmPf3H+HIsROEAx4qSgtIT0lCrYSW1k66+4dYVFpEfOzsU+jdvf3sO3iUdz/4iJHBfnoH R0lOSmL18irMpmhsNhs3btzg5q1b1De18PEnx/F7XWxa+xRbNqylvLSQaYeDO7WNuD1elvzB xMyFYHzCxr7DJ/jo0KesXbWUNSuWEBulw+O0MzIyQntnN9P2SYJ+HwaDgbt1Lfx+70H0WhWp CWbiLVHEx5gZHx/n6vUbREVFU5iXi1qtxulyz07sOHKS+oZGBnq7GR4e4Rsv7CQxIeGRA88j IyOcPn2a6uo7HDtzmY6eAcLhEMsqF5GXk7kgz+Ph0XE+Onycw8dPs371ClZUlqFXyQj63AyN jNLR1YVtYgyNSonRaOTG7Tp++/7HWKL0JMdFkxgbTWyMmZHhYW7cuo3FYqGwIA+lUonD6eLY yS84cPQktfUN9Ha1M+1w8PLu54mNmR2YD4VCdHR08N77H3D7zl18Xg+VJbkkxs4+/bVp/ey9 T+WiYrIy0uYmVy8k/YPDfHToOCfPXmTj2pUsLS9Cowgj+b0MDg3T1d2DbWIMnUaNwWjg6s0a fv3eR8REG0iKMZCWnIA5ysBAfz9379WTlJhAYf7silQzDieHjn3OgSMnqKuvpb+3G38wxIvP 75yb+BEMBunv7+f8hQucOHWGy9dvoUCirDCbVcuryM/N4dqtu//aL12Axd6unn4+OnScc5eu s2X9SlZUlqKRh/B7XfT2D9DX18+kbQKVQo5Gq+PKjTu8/e4+UhJjSLQYsCbGYYoy0Nfby726 BhITEyjMm81wesbB/iMnOHzscxoaG+nr7kQKw+5ntmM2m5Akid7eXm7dvMnkxDh6rYo4SxQm owZZ0EOcOYrNG9YxMDyGx+dj7coqigvyUCgW7iolPp+PtrY2rl69ytjYGD6fj4GBATo7O1Eq lVgsFpRKJW63m4aGBm7duoXdbsdut9PR0UEgECAmJgbNH6xyFwwGsdlsXL9+nZs3b5KdnY3Z bH6gUH7r1i1u3bqFw+FgdHSU9vZ2QqHQQ9v6Q+IJtr/izVhndy8qlZLNa1fS3N7F0MjYIweh W9o6qa6po6Qgl2+/tpukhDhkMhkFOZmM/ext7tY2sqikgPRUK2MTNo59dhZrcgKv7X6G4sJc NGo1lWVFSKEQZy5c5fyVm5QW5QNw7vINgsEg61cvZ9umtahVKgLBIAnxsZw8c5HPzlzkzVde WJDLe9kmp2jv7kWv17FxzUoamtu5eefeIzNsaG7jXn0Ti4oLePPV2QwBcrMy+E//+Atu1dTN Lv+YnMTQyBgnz14kPc3KN196jrzsDFQqFeUlhfj8fq7dquHyjdsU5efg9fk4/OkpNCoVzz69 kY1rVmAw6LFNTmE06PnnX7/Hsc++oKQwb0HejDW3dSKFJDauWcmrLz5DrMVMIBiktDifsxeu cvnGbbZvXkeqNYn6plbu1DWSm5XBW6/unlsqc1FJIV09fVTX1LOopJC87EyGRsb4/IvLmE3R fPu1F8nNykClUjIxOYXL7eaLi9e4cOUWSytnbxb2Hz1JIBjk2W0b2bB6OUaDAYfTRXSUkX/6 5Tsc/PRz1q9avmAGpCRJoqd/kL6BIdatWsYru3eSm5UOMhkFednYJqf49NR52jt7MEVH0dnT x9Wbd4gxRfPS89tZs3IpcvlsJ8Pt9vCL33/I3bomkhMTcLpc3LpTy/T0DD/69mu8+Nw2lErF 7FIXIfj1ux9x624tFWVFpKUkM+NwcutuHYnxsezYsp7Wju4FvaTmXGEjGKSnb5C+gWF2bF3P q7t3kpGWCjLIyUpnYnKSi1er6ejqpaoiivauHtl2TtMAACAASURBVK7euENSQhwvPb+dlUsr kctnZ9c7XW5++fu91NQ3ER8Xw5R9mpu3a/F4fLz5yi5e2LEZhWI2w0AgyK/e/YjqmnpKCvNQ q1T09A/icnt467XdvLJrJzqthlA4jNGg51fvfER9UxuDw6ML7ukXvz8wdxy+vGsHr+zaSao1 iXA4TEaalQnbJHdqG2effC6Ppq2jm8s3bpOZlsJLz21n6eIyZDIZI2MTOF1ufvH7D6ltaMFi NjE2buNG9exTuS89v52dW9fPZejxePnVux9x+149BblZBIJB+gaG0KhVfOe1F9m09ikUCjmS JKFUKvj1u/toau1geGRswWXo9c0u09U/OMJbr+3ilV07SUqIIxwOk5KcyNiEjbrGFrr7BrCY o2lu6+TytWpKiwt46fntVJQVzU5EGRrB6XTx2/c/pq6xhaeWLWZoeJTr1TWolEpeem47T29c jUKhwB8I4Ha5+eU7e7lzr4GcjLS5SS9f7teG5jYOHPuc7Mw0pmccC/Y8Hp2w0dM3QGlhHt/9 5oukJCUhl8sYt00yMDRCdU0ddY2trF25lOkZBwePfY5KpeSlF7ZTVVGKTqvFPj2DQqHg/Y+P cPL0BdauXArA8VPnmZqe4bkdm9i9cytmUzQej5fU5CRu3qnl4yOfsaKqAoNBj8frQy6Xsai4 gNd2P/O16g+OjI4zMDhMeUkh33n9G6QmJwKzT3529/XT0NxGU2sHK5dWYpu0c/Szs+h0Wl5/ 8VnKigvQajRM2acJhUIcOnaK0+cus+r+rOyjJ8/idLl54+Xn2bllPaboKFxuD4nxsdTUNbL3 4Kc8tbQSrUZDU0s716prMJuieevVXVRVlBIOg8PpxO8PkBAXu2AHRweGRxkeHadyUTHffm33 3BLNVRWltHZ00drRTUtHF1WVZYyM2Thx+gJRUQa+9fILFObloFarsE3a8fv9nDhzgS8uXWf5 knKCQYmDn36O1+djx5Z1bFm/iiijEafLjcVsouGff83HR06ydkXV/b7oioe+m8fr5XZNPaFQ iOd3bCE7I21BLsPSNzDEuG2Sqoqy+0+bzA5YLCkvob6pdXZJ3O5eKsqKGBwa5fT5y1jMJr77 zRfJyphd6WDCNoXT6eL8lZtculZNVUUZXp+ffZ+cIBiSeG7bRtatWo7RoMfhcBJlNPCzt/dw +PgpNqxejkKh4Hr1XewzDnY/u5Xntm1Co1EjSRIFudl8fOQkF67e4sXntpFy/zxZGAN6Y/QO DJKdmcb6lYuZGB1icfkWMjKzOHDsc379+w/pGxziVnU1Ugiu37rDyPAQFYXZ/PC73yYzM4Pp 6Wn+y89/xZkLV7l89SaVZcU4HQ5OnjrNwNAoP/ret3nr9ReZmrRx8+ZNEhMSuHankYtXbyIL evB5PSjUBkan3Lz+4jOU5KWj12pYtqyC9FQrE5NTnD5/hTdeep70NOtDy5L/tQ2NjNI7MERB bjZLSnJwTE/y3I6tRJssfHDwKL/+3Qfcu1dHbnYWuXk+Ll+7xfjoCGtXLuHHP/oecXFxDA0N 8V9+/itu3G3g2q3blBblkxAXQ2dXF6dPf4HTbiPBEoXd4Z1bDjscDjMzM0NdXd3seR2XQPfw JDs3bSAzJQ5rgpkVK5aTc/9afOlaNc2tnZSXFi7IiZMd3b2MT0yQn51GnFHLiuVLKS4uZnrG yZTDy40bN7h+4waLSotpbu/i/KWr+DxOfvy9v+PZndvw+/1cv36Dqf2HqGto4m59I6XFeYQk idq6Oj77/BQhv5vCkmL8Xf+67JTH42FwcJCbN29y5swZenp7eenlV1Br9dgm7V+b63H/4DA9 /YMU5+cQH62hqCCPZcuWMTXt4LfvfcSevfs5c/YchQV5BIJhzl+8imN6kpd3P8d3vvU6CqWS +ro6XHv2cq+pmeo7tWSlpxJl1HOvto4vzl3ANTNJdmYaNmff3P3al4OHg4ODlC0qp2dgBFR6 ntm5hpgoLbkZVioqKkhKiGd03EZdU+v9FXkW1oSXUChE78AQfQODlJcWkGjRk2pNYsWKFUza Z/jNnv0c+uQop86cJSc7i4AU5sKlq3jdM+x6ZhtvvfE6arWK+oYGXL99jzs1tdyuqSfNmozR oOPuvVouXrqE1zFFalIso1MeuP8MfiAQoLu7m46ODvILClFohzFZ4tm4qpJ4s4El5UVYrVZM pihGRidobG6jf3B4QU0acjhc1Da2kJWRxuu7n0Uhk7gyPc5LLzxDfVsvn54+hz+sxOPxUFdX x+cXq3E4nCwty8NkULN50yYsMbGcu3SV//R//3+89+FHbN6wBoNBz7htksbWdnweF/EmHd1B L1JQIhQKEw6HHyo2f9kuXrt2nd6hMQJyHQmxlgVdJIf7y7u2dJCblcFru3cwPWnD67Cx9jvf 4sL1u5w6dxlfSE5nZydarY79R0/j8XrIzSgixmRg86ZNREVFceLUOf7xZ7/g/Q/3s23zehIT EmaXG21owudxYDEokUl+QqHQg+MbgQBTU1MoFAoSrWlkZmbwf/yv/xMymQytVovFYkGtVi/o DG1Tdto6uinIzeL1F59hsK+XoGeGLZvW89m5q1y4fAOfJKe1tRWlSsOHB47h93pJT4phUUkh a9asJoyMfQeP8Nt39vDh/kNs37IBvV7P0Mgod+/V4nPPoFeBVq144Pj7w2Ovu6cPtx8SrWm8 +dJzBLxOzGYjS6qWolKpUKlUC7JACbOvnejs6aO4IJdvfuM5RoYGcE1PsHbVWxw7e4nqu3WE lWq6uroIhWXs++RzQmGJrNR4stJTWb9uHcjk7D3wCe/u2cu+A5+wbdN6DAbD7OTle/WEAx6M alArIPwHx6FCoSAjIwOLxcLO+/9dkiQGBwe5fPkyVmsKKWmZXLx1j83rVlFSmI9KtXDLQqFQ iKmpKWpqajD8/+y9d5ik9XXn+3lD5VzV1dU55zg5Z2aYYWDIIEBIoCzb0sq7d+279l6vd/U8 115fr3Rlr4KxJYSVQCAJJITEgEgaBhgmT08Onae7ujpUzlXve/94q4vp6UZCz/1DNXp0/oOp p8Pp3+93zvmec75fi4U1a9Zgt9uJRqMcPnyYw4cPU15eTmVlJX6/n+PHj1NbW8vy5cuRJIkL Fy4wMDCA2+2ms7MTWZZJpVJMTExw4sQJDhw4UKSevBbrHRsb49SpU/T19dHb24uiKJw6dYqB gQF8Ph8Wi2VJfF/kj/Z7MVmWWdbbxcP33cHem7fjdCwNOqYzGaamZ0ml0yzr66LS5y0mYx1t zfR0thIMhblwaYhsLsdcMMzVySlWL++lvraqqDNUW11Jf3cHOp3MkeMDxYcskUxhNBqwW61F uhWdLOOw27BYzMQTSVRFLUkf6nQyq5b18vD9d7BnxxYc7+PDVDrD1PQM+Xye/t7OYnMNoLuj la6OFgLTs1weGiWbzTEXDDEVmGbNij7qaqqKdBb1tdUFGkk4fvIMeUUhEo0zNDJOa3MDzY11 WAqPvMftYkVfF75yD68fPESmQMlUatbV3sJ9d9zCji3r8RRoUnSyTE1VBd4yD+FIlEw2SzqT YXB4jFg8zvK+rgU6dNWVPpb3dRGNxhgaGSOeSOIPzHB5aIQ1K/tpbqgrPtplbhe9nW2YTSbO nL9EPJEkEtUaSu2tTbS3NBWpDOb1EZob6zh8bIBoPI6ilsZZFAQBi9nE/Xfu5e7bdlNXXanx oQsCLqedlsY6bT17NoiSVzh15gKBmVm6O1vp7+lAkjTuXqvFzJ17d6HX6Tg5cI6Z2TmGRsa5 MjxKhc/Ltk1rikCcJEls27gGX3kZl4dGGRwZA8BkNLKir4v/8OlH2L55HXar9YZ4A0VBxGaz 8NC9+7j7tpupqvAhigKiIOBxuWisr9WoZuaCKKrK8VNnmZkL0t/TQU9na9GHDruN23fvQBQF jp08w1wwzOWhEYbGxqmtrmDzulVF2gtJkti5ZT1et4uLl4cYGZtAlmWaGmr5yIfuYu+urZiM 2jSKJIrUVldS7vWQSqUJR2Kl50NRxO108NEP3cVdt+7C59WGL0RRxOtxU19bTS6bK4IbR06c JhgKs3JZD51tzUUOaY/Lyd6dW1EUhcPHT2m6oFeGGL06SWNdDetXL1/gw907NuNyaM2m8Qk/ BoOBns42Hr7/zoK/xeJna6sr8bidZLJZkql0yflQkjRfPfrQPdy5dxdlhQlEURTxeT3U1lSS yWaZC4ZQVZV3j50kHI2xdmU/rc0NRR/6yjzcvH0T2VyOQ0dOEIvFOXfxClcnp2hpqmfNir6i D3WyzN5d27BaLJw5f4nJqcA1CZ2Cf3qGf3/qWYwGjQLs2uZbqZnP6+HmHZt58N591FZVFnUQ vR43vvKyYoMmn88zGwxx7NQZVvZ309bUUJy8djrsdLY1U1Hu5fjAWeKJJPFEkmMDZ6iuLKe7 raW4uWcyGWlpqmNZbydHTgwwFwyTzyukCmerFOkLf5tVVpSzZ+cW7r9zb7G5BlBe5sHnLUNR FGLxeCGmzDFw7iJrV/XT0lhf3AjVdBFa8bidnDxzvujDIydOU19bRWdbc7G5bTGbaG1uoLuj lXcOHycUjqIoCsdOniEYCrOst4PlhcaxKGpv7Mc/fC/33r5nSW3RUrCaqgpu3bWNe2/fveBn 9JWXUe4tI5vLEY8nyeXyBGZmuHB5kLUr+2lurC9qNXncTro7WrHbrJw+d5F4Ikk0HufdY6do aaqno7UZWyG+Wi1m2psbaG9p5N2jJ4nEYotAlvmicCoww3ef/ikOu41bbtqygN65lKy+torb dm/nzlt3LtA/rfB5KS8vI5PJkkgkyeVyTAamuTI8ytoV/TTV1xXpHcs8Lnq62jCZDMUcLxyJ 8s7RE3S1NdPe2lQEQ2w2K+2tTTTW13Dk+ACxeAJVVUmm0+h1MnartcieIUkSdrsVh81GKp1G ySsl5bv5Ldt7b99DY101lZUVdHd3U19fz9pVKzCYLBhNFgKBac6dv8TFy4MYZZFN69fS2tqC 1+ulvr6eO/fdikEvc+bcOS5dGebipcucPXcBh8vNRx+6l/q6OlpbW6moqEAWFBpqq7g6McG7 R45R39DAdDCCIMrs3X0Tq1eu1OjmJrU4vnblMqZnZjk+cJZcLldy589kNHLLTVu4c+9N1NZU 0traSltbG3V1taxZuRy9yQyixOTkJGfPX+LylSEMOoHdO3fQ2NiI1+ulpaWFm2/ajojCmbMX GB4dJxqNMjw8hNUoc/vem1m3ZhWGawBiRVGYm5tjfHycyqoqhq4GUBG5+87b6Ovp4cqVK0Sj URrrali3chnhSIx3jpxAKdHauKrCx96d29i0diVdne10dXVRVVVFfX0dfb09CJKOmelpItEI Z85fZHRkhLqaGm7ZvROv10tlZSX9/X001FaRy6S5dGUY/9Q0IyMjXDx/jt7ONu66/Vbqa6ox 6A1FIMrv92sT4+Ewbe3trFrexz37dtPa1LCkHl6pmtls5I5bdrJr2wbaWpro7e2lpqaG+ro6 VqxYjqw34p/yMzcX1IavhofwlXm4dc/NVFVVUeHz0dOjbS4Lap4Tp88yPuHH7/czePkStZXl 3HX7XtpbmxdQ8mWzWVRVpbOzk5aWFtpaW/jUIw/x8AP3UeZxMz09remY+bzUVFWQyWSZC4VL zn+CoOUYd+3bzc3bNtJQV0NfXx+1tbU01NezfFkvksFEIDDNXDDIiYGzjI2N4fW42LNrJ9XV Vfh8Pnp7e1m/diVqPsuxEwP4A9PMzMwwOjxEtc/LHbftpa21GeGaJreqqpjNZlatWkVvTzcr lvXxyUcfYu/uXeTzOSKRCIIgUOErp6K8jGwuTyKZLCn/2WxWtm1cwyc/er82uKuqVFZWsmbN atrbWrBYbChI1NbWMn71KkdODFBV4UEnqjQ3NdHU1ER9XS3r166mp6ebs+cucOXyILlcDlEQ qPK6aKgqo6uthYrKqvcdEkilUgwNDXFlcJA8IhcuD7Hnpi00NtSWHD3z9eZ02Nm+ZR0f//C9 1FVXIgjQ3t7OyhXLaWluwmwxI+kM2O12RkZHeffoKWqryhHJ09HeTkNDA/X19WxYv5a2tlZO nz3HyOgYuVyOXC5LudtGY3U5K5f1U15Rsej7ZzIZIpEINrsDo9mC1+ulurqampoaysvLS765 BuBxOblp6wY++qE7qa4oRxQFOjs7WbGsn6aGBgxmM3qjCZPJxMjICO8cOUZdtQ+9TqS3t4ea mhqaGhvYvHEDNTU1HD1+gkABi00mEjgsejqb61i3ehUOh3PB987n80xNTTE9PY2kNxFNpFne 18u+vTezceNGmpubcTkdPHD3bTxw16001deWpA+9ZW5u3r6RD993O5U+L/l8no6ODlatWkFT QwN6vRGj0YLdbmdwaIgjJwZoqa9GQqG7q4va2lqamxrZvGEdNTXVHD9xEv9UgHw+Tyadpsxp pq2xhpUr+nE6XYvwIbvdTk1NDXV1ddTW1uJ2u0kmk3g8Hrp7unn+5TeQRJEdm9eVNOPV/Nue Tqex2+309Gjny+PxUF1dTUtLC8FgkFAoRDqdZmRkhFwuR3t7OxUVFZSXl9Pe3o7JZGJ4eJhE IlGk0Hz33XeZmZmhpaUFu92+YEFBURSNdldVqa+vx+fzUVFRQW1tLdlslmg0umTdB3/cYPu9 WUV5WXETbR4oX8ryea2bKksyNotliQfQRV5RmJ6dI53OkC0UTQ67fVHQtFktWMwmJvwB0ukM RqOBvq42Xjt4iMGRMTraNIHYVDrN4PAo0WiMtauWlWwgqPSVU+krRxAELlwe+g0+zJPL5ZFl eQEPdfEB9LjJZrPMzM6RSmfIZvMIgljUn7jWHDYbRoOBialp0qkM2WxO23SxWhZ1/o0GA16P m7PnL5NIagK18+BjqdjuHZuX9NfsXIhgKIzPW4bRYCAciTIzO4dBbyjSd11rDbWaYOz07ByT /gCB6Vky2WwBxF/4O5d7PXjcruJnI9EYwVCE5oZaLNfpC9msFhrrajjwtsbhb7OYEUsgsZNl me6OVro7Whf9Wyye4Ko/gMloKOoXjoxdJZPNUV7mWUDxJkkSdTWV2O1WRq9OEInGmJqeIRSO 0NJUvwiI85WX4XE7uTw4ylRgphjA77vjlhtia+1a0+t19HV30NfdsTCIApFYDP/UDCaTEV9Z GaIgMjg6Rj6vUO71LNiC0skyNdUV2G1WhkfHicXjTE7NEInGaG6ow1u2UIeuwufF5XIwFZhh emaWDWuWs3XDmgUaW/PBPDAzRzgaw2az4HKWnrC90WhgeV8Xy/u6FvkwHIkSmJ7FZDZRXuYG BK4MjaIW4o/NZlnwt6ip8mGzWouC2hOTU8Ticco8rkVi6lUV5bicDqamZ5mZC7JqeS+7tm1c BCxHY3EuD40QTyRpLtDqlhyYYjKxankvq5b3LvJhMBxhZjaIxWwq6vVdGhxBFAUqyssWTM0Z DHqqK31YLWYuDg6TTKcZm/CTSKbwlrnxuJ3XABAC1ZU+nA47k/4Ac8H3QJJINMrBd47yxluH +C9f+CyVFd7ioEwpWltzI23NjYv+fyQaIxgMY9Dr8bicpDNZpgIzRGNxbWPoukaYy+mgqtLH leFRJvwBREEgGAyzoq8b53UT2gaDgfaWJp574WX8U9M01teSTKVRCuD8+UuDRKJaU89oNFDp 8+JxuUp2Oq+rvWVJTR8tNoYxGY24HA5SqTRT0zMkEkm621sXadl43E4qyr2cPHOeSX8AQRAI hsLUVa/FYbNdd+6NtDY18JOfv8Tk1DSVPi+DI2PIsozTbmdoZJzp2Tky2RwGvY6Kci9VleUl G2f6uzvovy6WUHgHg6EwFrMZp8NGMpUqDq11tbcsokPxlrnxetyMjk8w6Q+QSqcJhiM01tUs mpK1WMw0NdSx/7U3mfRP43Y60evFRX/DI8cHOPD2Ef76P/4JjfU1JXsOV/ZroPD1FgpHCAbD 2KwW7IUNyMD0LNlsjvbWpkVnwuctw+1yMhsMMekPEAxHCIUi2hDadToZdquF+tpq3j58nAl/ ALPZREdLE1eGRhkeHS9ujmezOa4MjhCYmWX18j6s1tKaWG5qqKOpQK8fi8VoaKjH4XCQzmQZ HBlDkrShLKPBwGwwxNzcHLIk0NrajLGg2yLLMu1tLZhNRqamAkxM+IlG5ghHo7jcPhrra5Ek CZPJRFlZGWNjY5iMOpLJFIHpaZwOB/m8iiBoubPNZi02PpqbW/B5PWSyuSJQWmrW0lRPS1M9 uZwGhAPY7XbC0RhDo1eRJRGLyYjRaGAyECAUCmE2GmhpbizS9BiNRtpamzHoZSb9UwSmZ+hs baStpZm+Hk1H9+DBg4tqnmAwiKqqWK1WhkbGsFhMNNbXEgsHOX16gHA4rIErPi+SJHLh8iCq qgClt4m6ZkUfq5b1EIvFSKVSOBwOBFEkkUwxPjGJ2WTAZDKi0+nw+6eIx2PU1i7HXsANBEHA 5XJRXVmJJJ7BPxVgcmqacredLZs3cfddd3Lq1CkOHzm+CNBrbW3F7XYzPj7OyZMnsZhNN1Rt IhToZ9tbmkgkEsTjcaxWK5IkkUglGRvXhvJsVisGvZ6R8atEIxFaG2pobKgvNsysViutLc3I EoxfnSQYDuN2WNiwfi37bttb3CK41kwmE/39/UVgtKqygjUr+piYmEBVVXQ6HUJBV3R2LoTF bCpJ7SZJkuhqb6GzrZlkMkksFsNisaDT6YglElyd8KOXZew2K3p9gUEkFsXTUktDg6YDJggC NquVzvY2ZAmGR8cJhSM4bWY2rFvDbXv3MD09zS9ffPG6ulJPS0tLIfczUl1VRXd7E8eOHcNi sWAymYjF4gyPjDMXClPudZcctZzP6+HRB+8p1lH19fVUVlYi6/SEwlFQVcrL3KRSKW1IORLF 63aTy2bx+XzFeGK32ehob2P//pe4eOky69etoaqinPWrl9Pf3c5cOMrhU2cZHptc9DPkcjlt kOHcOSSdkeGr01T4ytmzYzP+mbmSZtUAbfD70QfuLv4u3d3dhTdKIhgKIyDicTpIpzOkMjlC kSi+MjfpVGqBD11OBy3NzRw8+BYXL16mp7uLKl852zatQ5IkhscneO3A20TiCxnI0uk0s7Oz ZDJZYtEIgalJfvXqG4iShNFkwWaz4PN6KHO7S1KCB7SlgkceuAvQmv/Lli3T3jdBJBgOI0sS TruNdDpDLpUlHIrgdtiwWqy4XK7ie+UrL6O+vo7TZ84yODRMZYUmD3PLrh04nU6OnRjgtQNv k8ovPH8zMzMaJWdce0P0ssCp02eJxZMIokQkkcFXXkZVRXlJbpKDxpLW0lhf9GFfX5/2swoi wXAEnU6n6UImk0TjCSKRGOUeJ0aDEbfbXfRhuddLbW0t58+fZ3BomJqaamqrK9l90zYcDgdH Twzw2oF3FsXaa/87l8sxMTHBpUuXaGlpITAX4dUD7/CZRx+kq72lZM/htfmF1+tl06ZNC7bG FEUhk8kgiiKSJJHL5QgEApjNZtxudzGnsVi0RncgECCRSGAuaCo2NTXhdrvx+/1Eo9FF39Ph cGA0GgkEAni9Xg0bDATQ6/W/UYPtjw2232MS98HAPyMOmw1FUZicmiafV4qAQK5A1ZVKp0kk k2QyGVwOO3q9nrGrk6QzGVRVRRAE8opS/Fw6kyEUiVBh9HLv7bdw7uIVXnjpdaKxOC1N9fin pnn9zUPYrBYefeDukl29/aA+tJhNOOw2cvk8U4Fp8opSpEbJ5fIkEknS6QzxRJJcLovLaUMn y4yNT2qC9qoWaPN5hWQqRTKVQifLROMx3C4HFrOJwPQs8Xiy6G9FUUhnMsQTCbK5HKFwhPIy D6JY2ldOURRm5kK8+OoBpqZneODu2yj3eohEYsQSCUxGA84lKN6cDjtGo4FYLIE/MEMwpAXf Mo8Lrvs7WcxmbFaLNtEXmCEWj6Oi4na5Fk05GvR6XE4HiqIyFZilqaGOUh6cisbjnDpzgbfe PU53Z1tBT0xmLhRGr5Mxm0xLBkCPy0k4EiWVThONxcnl8tit1iU/Oy+EHY3Ff+e7cCNYNBrj xKlzHD4+QE9nG/097ciyxNxcCINBVxQRXhgEJTxuF8FwhHQmQzQaQ8kr2KyWJX3osNsYG58g Fk8s+TOoaHogb7z1LtMzs+y5aQvNDXU3jA8jkShHTpzm5Onz9HS20dPZhigKzMwFMRuNGJfg jJYkCa/HxVwwRCab1Tb2VG1TYykfOh02ZueCxBPJRWDV6NVJopEYF64M8YuXX8eg17Fp3aqS ovT6bRYOR3j32CnOXbhCT1cbXe0tqCpMz8xhMZsxGPSL/CLLMh63i5nZINlsjnA4gljYdl3K hy6nHf/UdHGCNpPJcPbCZb7/o5+xYc0K9u7aypXh0RvuDqczmaKmX11tFcv7u0lnMszMBRFE Aa/HjXydmLrJaMRpt5HLadqMoiiQy+e12HKdbp8syXg92qbh9GyQTCZDsgA2nD53kZnZIFeG RonF41itFnZu2cDeXVtpqK25YSbp0+kMbx46yoXLQzQ31tPX3UEqnWEuGEYSRbxl7kWJvdlk xG63ks1mmQxMIwoCeSWPy+lYVDzpZF2x6RuY0RpOc8EQuVyO4bEJLlx5hqMnz2hNUoOeTWtX 8pEP3Ulrc0NJN3yvtVQ6zRtvHeby4DDdnW10dbSSTKUIhsKF986NKCz0ocVkwm6zks5kmAxM k81kURUFt9OxaNhMr9fhdjlQVZWp6VnaWxoXnC9FURgevcqPX3iJhrpqbtu9HZvVcsPcY1VV SWcyvHbgHQZHxli3ahntLY0kkylC4QiyLFPmcV2f4mG1aDneVGAGf2CGSDSKCoUm9+Icz+10 oOS1Tb/G+hpu2bmV8xcH+fXbh8krCr1d7YTDUV759duIosh9d+zBV1aaW73z4LjNZiOT1Zpr Tz/7C7xuJ0adSEtzE4NXtU0UgyhgNpuL6YbSGgAAIABJREFUoLwgCJhMJswmE4HZMHOhIMl4 hFxWO3/z910URcxmM4qiIEsiep2OVDpLIpEoMnRMTAaQUZidncVut5PKZIjG3tuCVRWlZM/d vJbGfCy5eGWY557fj6/Mictho621lQOHTpLLZjDb7UUw9NpGhclkJJVMEo0lsNlsdHV1IUkS U1NTC7aG5u9pMplElmUkSWZ2LoTb6UCn02E0GhFFkXg8jqqqGAx6rBYzgelZVLV07+615xAg Gotz5Pgpfv3mO9RVadPcDrtdqzeyaVxORxGwEgQBfaH2ElSVSDRKIpWirq6HujqtiXzx4sVF 36+yshKfT9Nqm5ubu6HrknlAzmzW8t94IsnA2Yu8+MprlLttrFq+jMrKCkKhMKqSx2IxY7gm T5FlGbPZjEEnEY/HSaczRf8ABIPBRf7R6/W43e7i/1dVlXg8zpUrV8hkMlRVVZFIpnjnyAku D42wclkPHa1NJe1Ds9mMqVD3xuIJTp05zytvHKTcbWN5fy+VFRXMhUKoqoLZZFpwlyVJ0nyo 1xGNRklnMpSXl+PxeBAEgUQisQhfEEURk8mEqqokEgmGhoY4d+4cY2NjVFbXMD0XZuDCEC++ +msSyST79uygoa66pO+xNqiR4djJsxw7dQar1Ux7cx3DwyPoDSYQRCxmI7lcGrPZXIwTBr0O r9cDAvgDAVKpNFarhaYmbSjm9LmLS1KbKYpCKBTi7Nmz5HIKV6fmmJkLccfuLbic9kU5U6nb fDzJZLIcPn6Kk6fP43TYqK7wEA3PYbG7ABWLyYiaTWAymYoxwqDXU1bmRlE1CuNsNofNaqGj Q6MHDkbiiNfFE1VVSSaTBAIBxkZHNFrASIjxkSHmQjH0ZhtebzlbNq5h786ttLc2lZw2+fWm 0+nweDxkszneOnyMU2cuUOZyUu62k4yFMdpcqIKAQS9jNpsWvIVGoxG3y4miKIxN+Mnl87jd bmw2G5Ikcf7i4KJ7PD+oFI1GGRkZxj8+yruHcrx76B2mZkLkBBmr1cbaFf08cPdt9Pd0lJSO 4vv50O12k85kePOdo5w9f4kKnwePy8Lc9BR6g3Z3jQY9eoNhwVtoNptwO50oisrVST9KPo/d bqevT2PGOXdpEOE33EtVVYnFYpw9exZZp8PucvO1x5+ivMzD7h2bKS/zlPw9vj4maxh+junp aS5evEhlZSVut5t8Pk88Hkev1y/QR5uPJ7FYjGw2q9G3+nx4vRozYCQSWVRTS5JEdXU1ra2t HDt2DL/fj6Io+P1+uru7qaioWJRPFt+dP7a6StskSaLC58VmtfLm20eYfPBuytxOBAT8gWmO nTrL1Ykp8v0KeUXBYbfR3tLEK2+8xcc/fC9mswm9rCMYCjNw7iIXLg1RV1NFJpNFRZucfvSh e/jGt3/Al77+LVRFaxDVVlfyuU8+TH9PR0lzsn5QH1ZVlGM0GDh46BgP3ruPskLxNjEV4Nip M0wWGm95RcXpcNBUX8uv3jjIpx99gCZZRifLzAZDDJy9yKUrw3S0NZPN5TDo9fR1dXD81BnO Xx6koa4ak9FILJ7g/KVBjp86pwGnBeqHUjZFUQmGwrxx8F2+/PXHWbOynzv37sLn9RAMhcjl 8kiShF63GFzT6/RIkkQ2lyOZSpHNZhEFAaPegLBEsqPTyeSVPMlUinQ6DaqWyFyfuImiiEGv 1xKWVKowMVqCQFQBED3w9hG+89SzSKLIX3z+k0We8nQmgyRK76u7YtRrzcl8XiGby6Gq6vtS MOh1OlRVJZvN/UG9dZoP07x64B1+8KOfYTYZ+cJnHimCmumMFhDlJYKZABj1ehLJFPm8QiaX Lfhq6bfLoNOhKGpx4/f6RCSRTPHdp5/jldcPsmZlP3ffdvMN8Q6qqgYq73/1AE8/9wucTjt/ 9vGHiqBvKp1BlqSlEwJBwGgwkMlkURSFbC4LggbEL30O9eTzyiKqqVAkyqe+8NdcvDKMoihs 27iWz37sITauXXFDAC6qqpJKp/n5S6/xk+dfosLn5VMf/RB6vY58Pk8qnUYny0iitGQCaDIY SKczqIpCJptFEIUifdqic6jXk8vlyeXzqKrK4PA4z+9/jUgsxl/9+We14ZYbDKTK5fKcOX+J b3z7SRKpFA/v3MrKvh6C4TCZTAYBlhQFlgpAsapogyySJBbfweu3jERR0Ao4QXszFEVBURRm 57Rmm89bxt5d20gkk7z4ygH+8X9/k6uTU3zyI/fT3tJ4A/gwx8DZC3zt376Hisqtu7bR193B zNwc6UwGBGHJQQNZktEX3rZUMoUoiaiq1gi6Xm+p6MNCIyqZSpPJ5rh4ZZhkKsWqZb385z/7 BLl8nv2vHODJn7xALJ7gc5/6CJ1tzSV/h7O5HCdPn+efHnsCk8nIrbu209PRij8wQyaTLWy7 GBZdLy0/0aHkFVKpFNlsDrUAfi72oahRpKkandL1FNbRWJyBcxc4ffYC//U//SlWy42zzaHR sWQ4PnCWL339cTxuJ7fdvJ2O1iauTk6RuSbHWwrQ0snae6nleBlAa05cX8CKkoRer0eFQo6n 0tpUz4P33sa/fedpvv74Dwp1CTjsNr7w6UdYs7K/SMdesnc4n+fC5SG+9L+/yeDgIPfv20F1 pUYdNzx5AEVREXVCcUJ5Pn5IkoROJ6Oq2lRuLptHFTSQ6nofA0iiiN5gwGKSGR4apNztQhbh xz99gdX97YyOjVFRUcGlK8O8duAdrR7JZFBL/PwJgkAmm2Xg7EX+6RuPMzY2wr6dG+nt7aGl pYXX3znx3tt2TT5T9KEkk8zkyOVyyLKMLMsoirLk/VNVlXw+r006iwKpTAajwYBY+Frz2rOq qiKJIjpZJplKo5a8FzVLJFMcOnqC//H3X4Zcit079rFpw3qMRiO5XF6rv667m5IkYSi8j9ls llw29168SKWW/HvN5+qZTOYPpi4RBKEwMHScrz32BDP+Se64ZTvrN6zD6dQ280E7h9f6b34j VRRFcrk8+bxS9E82m/2N3+9aQPT8+fMMDAzQ1tZGWXk5P9//Oj/7xa+or6ni0QfvuSEGhuZ9 eODtwzz2+PcJz81wy44NrFmzGrfbTSajxRJdAUe43oeyKJLN5sjnlaLm0nzd8ZviaSaTYW5u jnA4TD6f5xuP/4CRiRlyisqaFf187KF72L1jc8nH5Hw+z+DwGN99+jnOXrzMzk2rEfJpLBYz HpsLQRLRyRJkVGRZLv4+oihiNpoQEEil0+SVfHHLd/7fl7JkMsnFixcJhkLEUlneOnKCrRvX Fjeob0RTFIXLgyM88eRPGBweZeu6ZajZNA0NDeTQQeGtR5EW+lAStYFUIJFMoqpKMSaoqoog Lh1P1AKtZ01dPRfGZsioMq6yCnzePKIkMRNN89gTTzI0Ms5nHn2Qlf3dJe/DvKJw/tIg3/zO 00xMTmk+zKVpaW0lmsxpPhQldDrd4lhSyBNTSW0R4dqYjLD03yuZTDJw+rRG/RdLEAjGqa4o Y3V/BQ2NjQSCcV587QDBcIQ//fiHWbuqv/R9mFc4f3GQx779JMFQiJ2bV5NJxGmobyCUzBbl SXQ6ecFdkySpGH+TySSqysK8BuG3viEzMzOMjIzQ1t5BYDbEGwff5b/9xecoL3OXHLvab4sn 83XyzMwMR48eJRKJsHnzZpxOZ3EY6vpzOB9P8vl8MRecj8nvR5muqmrxs4qiFCkhFUVBluXi XV8qhvyxwXYD2PK+Lu7cexNf/sa3eehT/5Fd2zei5lXePHQEUZLwlZchS9qj5isv488+8WE+ +3/8DX/2F/+dLRvX4HLYOX3uIoGZWZrqa1EKU3gC8NNf/oqv/MsTtLc08qm//xCN9TVMBWbY /9oBvvi/vkowFOEjH7rzhpq6XcrWruhj701b+JcnnuIjn/nP3LR1A/lcntffOlSkctQmQWVq qyv41Efv53P/5xf5xOf/iu2b12G1mDl55jyhUISGuhpEQcCg15LBz3/qYf78v/4df/flb/DK G29RV1PF6PgEZy9epqu9hWOnzmDQ65YMxKVkE/4pnvnZizz+/WdYs6KP//nf/gKfV5sUEwUJ URBQUVGWaHLllTyqqiAKArIkIYoiKpBX80sGzvkHSxJFJKmw5qsqiwpWFZW8ki8CsFCaPkyl 0jz93C/4zg+fxWa18Ld/+XlW9L5H2yeJYsF3SxfkOSWPKIlQ0H4SBOF9P5svJCSCKPxBvXOp ZIrvPfNTvv+j5yn3evjzzzxCf3fnAjATlfcFNfKKgiAKhfMqgsDv7ENtYjTBF7/0NV5+/SC3 3LSFj37orpLl915UGKVSPP79H/HD535BQ201n/vkw/R0tl8DwGv3cslmv6olYbIsa+dQEBF4 /3OoJcbCAv0D0DZA/uRjDzExNc3g8ChvHz7BP/zTYzz60D3cf8ctS05MlpQPkym+8cST/OTn ++lobeZPP/bQNfR9QrGwWvocquTyeXR6XfEua2/bbz+zkViMA4eO8PaR43z20Qeprqy4oZJe LUnN8/rBQ3zxH7+K2WTkc594mJ1bNyCKAgJCsSmpKPmlQc7Cmbq2CbxkXFBV8koOVIpajPfs 282mdSupKPfSVF+rxSBV5RMfvpeP/4e/5oWXXmftin5aGutKGiRIZzK8fvAQ/+3v/wmPy8kX PvMIWzes0XwovOdDLS4u9IuiaoNWgkARBBAKd3VJHxbEnOXiHVbJ5fLs2LSeL3z2EcyFidDt m9YRDIV57eAh9uzcQltz46KmZ6nd4VfffIf/6+/+X2oqK/iLP/sk61YtK8QGLe9A1e7f9TdT URWUAhAliRKKpGo+fN9zmC8WwNff1stDo7z25iG8Hg97d24r+bfvWovF47z02kH+5u+/Qktj Pf/lC59hRX93UZ9S+q05Xv6aHE8ChPc5h8oCH4LAy68f5Kvf/B5Wi5n/57//JV1tzYTCUV49 8DZf/F9fZWYuyCMP3r1AJ66ULJPJcvDdY3zpa9/iypUr3Hfrdprqa9m6dQtVVVXodDKCKCCK 0gL9hvlifj62SoVhtHmAZFH8nc8vZR0V1TU4nU6mp6ep8dr5xS9fZGDgFBaDxMR0BOOB44Sj cSyF6fJSjyzzm5Nf+ZfHGR8bY+/29axbvZKNGzbgcrmKzQtFURdpYCiKgqKqCKK4KD95P8Cm CKqqWr6eURVUtfB2qmoxL1dVLY+X5BsDaA6FI7zw4qt86auPkYpH+PjD93L7bbdSX1+HKEmI koggSSh5dUFeqCgK+VwelUL9d4MC6/+/65J0mmdfeJmvf/PfCU4HuHXnZu6/5y5aW1rQ6/XI knaXr9fjm7/LoNUZv0u9Nq/7cu7cOY4fP05tbS0dnV088eRzPL//VZb3dvHpRx6gs4S31xbV xz/9Bf/67e+TiIXYtWUtd9+xj9bWVgwGA7IkgyAW79r1PlQBoZDn/S4grM1mY9myZbS1tWla YsPjLO/rRpCNnDhzgS9//XEmJgN86qP3L9qsLiU7fHyAL33tW0wFZrh581oqPBqr1Zo1a5ia jSCgYQeyTl7kv2xeG+6WJWmR5MnSOXyOsbExzp8/TzSZ5e2jp6muKGfXtg1MXB3XBtry+Rvu Hr995AT/8M//SjgUYvv6lbisBiorK+jr7+fC5VEENL1hVXjvzZ9/7/O5HKCik+QPhEEJgoDP 52PPnj309C3n3nvvocztpqGuioFTAxw48Gu2bN3Kd370C9569xh9Xe30d3e87wB2qdjBQ0f5 v7/8DdKpJNvXr8Bh1tHY2EhXdw8nTl9EgMJQ3/X3WHmv1ijkeB/UdLIOt8eLZJxkw7q1/OXn P8nAwEnOnTvHn378QUDktYOHOHX2PCuX9ZS0DxVF4ddvv8sX//FriILKzVvWYpJVqqur6Ozq 5vjAeUAoxtrr73JO0Yb9tPdy4Xn77TlphqGhIWRZxmS28tz+17FZrezduRWbzXrD3edsNovf 7+fIkSNMTk6yevVqmpqaMBgMpFIpJElaFE/m/wbzFMQfxBKJBAMDA4yNjbF169biBv/w8DAD AwOYTCaWLVuG6Trqe/hjg+2GMG+Zm7v27cbtdvHqr9/mzLlLlHlcPHz/nczOBfnFy69jNBqw ms3IssSmdSv5xpe+yP5XDuCfmiYeT7Bp/SqMBgOvH3iHqelZ7DYriWSKb37vGbweNw/cdSvr 16xAr9PR2lSPt8zNxGSAb3z7B+zavgmzyVTSgMpvM1+5l/vvvhWfz8sbB99l4OwFvGVuPvHw fUxOTfPz/a9iMpowm03IksS2Tev4xpe+yIuv/Jrxq37sdis7t25AEARe/fU7pFIp7DYroijQ 193B3/3Nf+Ll1w4yMnaV4dFxWpsb2LZpLW8fPs6pM+dxOOxLbjyUip08fZ7vPfNTDh09yZ23 7OLTjzyAz+spApEmkxGDwUC2IHJ/vcUTSbKZHEajAafDjqVAXxOLxhfRqKTTGZIpbQvEOU9L IkC8QF+zINnL5ojFEoiiiNNhXzRBXgo2Oxfk3777NC+/fpCO1iY++qG76OtuXwDiWi1mcrn8 +052RmNxTEYjep2MyWhAFIX3FV5OJFPaZFqJr8P/LjYzG+Trj3+f1948xPLeTh6673Z6O9oW vDl2q4VMNksms3j6U0UlEo3hcWs6S2aTEQGBZDK95PeLJzQ6INM1NAa5XJ7xiUn+9h/+mYuX h/joh+7itpu3U19bVbL83tfa9MwsX3ns3zl46CjrVy3jgbtvo6u9eYEPbVYr6XR6ye1HVVUI R2PU11YhSxJmsxFQSaVTSwOwiQR6vQ7jddRzBoOem3dsJpfLkclkOXXmPE889Sw/++UrVFX4 2LZxTcn6MDA9yz9+9ZscOnqS7RvXcd+dt9DR0vTeuyOA3WZlcHh0yYknRdHO4fzQi8VsQlXU wgbHUiB2AoNej16n4823j/Dqr99meU8nN21ZTzqTLryX2oZWLpcraIRmSxIMCEeiPPPTX/Iv TzxFd3sLH3voHlYu6ylu8cqyjNVqQVVVorH4IlA0U4gtkiTiLNDQSJJEIpEim8ktSpKjEY1a 2GazIcsyrU31NNbXopOlBf7R63Vs37SWoZExxiYmCYYiizQFS+YdnAvyzHO/5F+eeJKV/d18 4uH76e/pKNI76mQdVosZVVWIRmOo14F6mXSGZCKJJElFH4qiSCKRJJtdGFvzee1rANjtNswm EzpZptLnpa62agG9riRJrFnZz/GBs0xOTRONxRZoiZaS+QMz/PDZF/j2D37M6mW9fPqRB+ju aClO+ut0OiwWc2EaMbaoAEunMySTKU2LzmkvbrvF4wlt22MBGJUnFotrtMMO2wIQWlVVRscn uDQ4zJb1q7EuQVdcqjY+4eepn7zAkz9+ns3rVvEnH3uI9tbGInuBXqfDbDKTz+eJxRbTLKcL G5E6nQ7nNdSGsVicfG5xjhePJRAFAafDTiaT4alnXyg2zW/ZuRWDQduWrq2pZHj0Ks/89Jds Xr8Kr8dVck3LSDTG8y++wneeepZsOskt29bQ2dbM5k2baGhowGg0YjIa0ckyKrni+34tEJJO Z9DpdFitVtKCgiwKxOLxBWcrnU5rDaYc5BWVquoqduzYweTkJE2tLRw+dobzl4cYGx7ErdNz 2+4d6PV6/vYf/pkyl/MDNZ5+n7Hkx8/v5wfPPEcuk2LHhuVsXLeWjRvWU1FRodHvmUxIskQ6 nSZXYH2YB0Sz2SzpTAa93vKB8uR5WjlFUTTqJauVqelZbZM/myWXyxXpmuZZOhx222+dGv99 2+jYBN//0U/58U9/jkkncN8Dd3H7bXtpLgBRqqoW6NBk4olEsf5SVbVAQ6/FB7PZhNn4h1Nv fFALhsJ8+wc/5kfPPY+kZtm7czN337mPnp6eIk2VFifFwrZztgi0KYqinc28gt1o/MC0yoqi EAwGOXXqFGfPnqWpqYnaunq+8q/f5cTAOW65aQv37NtNa3PDDVGXzAZDfPM7T/HTF17CJKts 2LyWO27bS19fH9aCDILNZgVBIJ1JL9jum/dhNpfHbDJ+II2geT0eQdC2g+dpUnU6HauW95LO ZNm+fQfTwTA/fPYFnt//Kg11NezdtbXkfKeqKj9+/kX+7TtPYzEbuWP3FnSC5ou1a9dSUVlJ Hk0TWsNfdAviSTaXIxzStCydTsci3eOlLJVKcfnyZQ4fOcqYf5bZUJQ9OzZx5sxpJq5exWK1 Mjs7Qy6XI53R3llZlksSm5n3wY9+9iL/+sRTuB1W9mxbj17I09zcxMqVK7HbHQRmI4WN6Tw6 VSCTyaAoSnH7NBKNgSDgdrs+cANHkiSsVisdbVba0YYGZVnC5yvX3ghVZd2qZZy/NMTVySmm Z+dKdmAomUzxo+f389gTT+Irc7N9TS86UaWzs5MVK1ZgMptxOvxoQ1QqmUx2QX2cyWSJxmKa HIrH/YGw5Hmt2fr6elR/kHKPh6bGOiorfczMVHLy5EmUfJ7+3k4OHTvJ1PQMoXDp1nbRWLxQ Hz9JY00la5d3oWZTNDe3sXLlSsxmK4Ojk6iCqjFZZXML3sJ0OkMsGkcUBNwe1+9031RVJRwO MzIyQlVVFQoiR46fZuvGNTidjpK9u+9nmUyGsbExDh8+TDQaZd26dbS1tWGxWIrvvslkIpVK LTiH+XyedDqN0Wj8QHWDqqpEo1GGhoYoKyujubkZp9NZrCOHhoYYHByktbV1EU05/LHBdkOY LElU+cq5dddWVvV3k8pkMOj1lJd5eOrZnyMWtCR0Ormo0bR14xraWxpJJFJIsoTb6eDoydMk UikqK7zIsszo+ARXJ/xs3biG6qqKotaaHh0V3jKaG+r41RtvMeGfoqbKh0m6cRNsWZaorapg 3+7trFnRRzqTwWDQ4ysr44knf6zxC7ud6ApTjE6HnR2b19HZ2kQylUaWJdwuJ2+9e5R0Jk2F z1tMmI1GA2tW9NFQW13UxbLbbMzMzfH8/lepra7EZDSW7DbCidPn+O4Pn+PS4Aj37NvNnXt3 UlPlW/BYuF0OnI6CuP3M7KKvMRWYJp5I4HLYqa2uZHh0nFxO02K6HsAKhsLMBTWB5rrqSsKR KLIkcdWvcYRfa4lkigl/AJ0sU1tdWXLTKZFojG98+0kOHjrKhtUruHvfzXS0NmMyLqRNqvB5 ySsK4UiMTDZbpH/UNqaSzM6FWNbTicVsxu10YDIaCYYjpNLpBdzciWSKYDCM2WTE5XT8Qbxv 4UiUf/7X73Do2Em2b1rLnXt30dbSsIiTvLKinGwuRyQaI5vNFSe7FUUhGkswOxeiq70Fk9GI x+3EoNcTCkdIpzMLCrNEQtPgsVrMRZA4l8sxODzG33/lMY2y4ZEH2L5lPVW+8pKnhlRVlUgk xpe+9jjHTp1hz44t7Nuzg5bG+kUFaXWlj3Qmq/kwlytSF77nwyDrVi3DaDRQ5nEjyzKhsKZ9 cC1AEE8kmQuGsVstOGw2orE40zNzqKg0N9Qt2Hheb1nBq2++w4G3j3D5ynBJNtgURSEUjvI/ v/IYp85e4I5bbuLWm7fRWF+74PcWgNrqCt569xjRaLxIP/VewyLObDDE9kofer2O8jIPgigs 7cN4krlgiPIyDzqdjrMXLnPo6ElsVgsj4xMLEvPLgyP4AzOcPneRW3Zu4fOf+mhJ+S8wM8vz L77Kt773DFvWr+aBu/bS3dmGxfzeVJfJqKey3IuAwOjViUU0SdFYnMD0DEa9gbrqSgRBxKDX EZiZIZZIXJdgZxkdn0AUBKp8XowGPTqdjqXgg/mcSCzQDOVKdPp2cirAc7/4Fd//0c+4edsm Hrz3NjpbmxfoCphNRirKy1AVGB6bWPS7hKMxpmfnMBkN1FVXFYoNGX9gZtHARiqdZnzCjySK VFf6MJuMeFwuTKZJ1CWo1OZ1BHO53KLmaKnY2NVJnn3hJX7y/H723LSFD9+7j9bmxgVDABaz ifIyD4qiMDo+seh3CYWjzM6FMJuM1FVXkUqlkSWJyalpktdRo6VSKa5OTCHLEjWVFQsoiWfn QgwOj4EKa1b23zDbqMOj4/zo+f288PLr7N21jYfu3UdzQ90CKjKrxYy3zEU+n2dsiRxvLhQh GAwXc7w5i7mQ402Rum7YIJ5MMTkVQKeTtc8GQ1ydnKK60kd9TdV7sUQHXo+bzvZmfv32YSb8 AZKpNDZr6cTneCLJsz9/iR///EUsRpmm5ib6ejrZtGkT1dXVRToat8uJyWQmFQsyFQiQzWYx GAzkCzrRsXgCm91FeZmHhFHTnZ2ZmSUai2GzahqLwWAQSZLJ5LSNApvJiE6no7e3l77+flat XM3AwGnefPMAy5Yvp7+vj8MnTiNJIi1N9SU7MBmPJ3jqJy/ws1+8jMUg0dTSzLYtm1i3dg0e j6cYb8u9HoxGM4lkjNnZORoaGgqAaI6pqQCJZIpqbxWuDzAIIIoiVqu10LhMUVVZzqFjpwhF IkRDIWRZxmazaQM0kRiJREqLUSV8p69O+vnOD5/lxZdfwW3Rs3vnNu7Ydyt1dXULBlA8LidG gxG/f4p0Oo3FYinSE04FplEQ8LiduF1/GPXG7wKIfvM7T/PC/pexGSTWrV7BnbffTkd72wIw zefzojcYCYcjBIOhouZdOp3WfJrNU+ZyfiAWIFVVCYVCHDt2jIsXL9LR2UlVVQ1f/eb3OXd5 kPtu38OenVtpqK2+IaghI9EYjz3+A/a/+jpuq4EVfV3cvm8vXZ2dRV02gCqfF51OTzQSY24u iMPh0Ggl02kmJiZJZXJ4PR6s5t9OC5xIJLhy5QqiKFJVVU0kniCdzuArc2G1WpGSSco8Lurr 6zh5+hzvHDnJmfMXS67Blkym2P/aAb7++A9oqqtlRW8rqViYyppqVq9eTVVVFZIkUVNViU6n IxiJ4rR6CAaD5HI59Ho9yUSK4ZFRRFGkqaH+A+l8iaJIWVkZVruTq8fPMnp1kuDcHNl0gmQi zoHDp4inFRD1fPnrj3P05Glu33NkchL7AAAgAElEQVQTa1b0leQdfvGVX/P1b32f9qZ6Oltq UbMpli3rp6+vr6h3WF3pQydLBMNRqj1WQqEQ2WwWWZaJxeKMjo0jiSItTQ3vK91xreXzefx+ P1NTU9TV1VFWVlaMTZlMpjjYYLNa0cky2VzufSnqft8WCkd44eXX+eo3v0tfZyvtDVWgZFi9 ahW9vb04HA5UFaoqypFlmUg8STQWIxaLFbeFQuEIExOT6HV6WpoaP5AP57UHDQYDZpMJq9Vc zNXz+TxGoxG9Xo/JaECSJI2GVynN2m5mLsjP97/KY//+FCt7O+lqqSWTSiw4h4qiUunzIgoS 4Vgcq0kmGo0WWYVC4QiTk370eh0tjfW/05CtoigEAgFCoRBNza2MTU4RTyTYsmH1DScBlc1m GRsb4+DBgyiKwsaNG2loaFgQTyRJwuVyMTw8TDQaxWazaQ30AmWw0+lcRLn+m3yXz+fR6XQL qGNlWcZgMBTP+ZJ9hz+2r0rf/IEZrgyNYNDrWbW895pGRYQrQ6OYjAaaG+uKU7anzlwglU6z bvXyItAfiyeY8AcIh6NsWreqSOWniXGmFk3m5hWFeCJRENGWbmixYoAJf4DB4THMZiMr+t7j Og4Gw1waHMZus9JUX6tRdUVjnD53kUwmy4a1K4rBIBqLM3bVTzyRpK+rvUjjd+zEaWKJBD0d bTTU1RSAlzQXLg8yODzGlvWrMZRoMnx1copnX3iJ0fEJdm7dwF233kxtdcWiz5lNRqortabb uYtXyCtKceohl89z+vwlREmkuqoCp8OO1+vBW+bm8PEBMrnsezQ3isLw2FVmg1pDyemwI4oi rc0NnL1wiWA4Ql1NVZHvdnouyIXLg7Q01WviuiU2afHkj5/nzXeOsH71cu7et5uOlsYlA19X ewt2q4WRsauMX/XT1FBbBIoPHTtJLBanq70Zj9uBIEBVpY/xCT8XLg3S3/MeTeLZ85eYmp6h obaa+pqqG/5ty+XzfPeHz/H24WNs37yOu269uZA8LA5NPQXAfnBkjAn/FPW11cW7duT4KeLJ JD2dbTgddhrqavD5yvAHprl4ZZjerrbi1xk4d4Hp2Tn6utqLZ318ws93n36OC5cH+ezHHmLP js143K4bYms3lUrzre8/w6GjJ9l78zbuuOUmmuprl5zQ6e/p4NkXXuLK0Cj+qWlqqyuLwODR k6dJptL093Rgt1ppbqjD63Ez4Z/iytDoNTSJcPL0OeaCITatXUllRTnDY1d57oWXiScS/NWf fxaH3fZegqIqRdorpUR1KGPxBP/23R9y+PgA99y+m9v33ERdTeUiHwqCwPLebn7y85e4eGWY 1TNzVFWUF+JDjOMDZ8lksizv68ZiMdPa3IDb5WR8ws/wyDjtBUofRVU5duoMoVCEDWtWUF1Z jiSJfOLh+xb9bFPTM/inpvF5y+jtai/GmFICUd4+fJwfP7+flct6ePTBu2lvbVw0sS3LMh6P k4b6Go4eP00skcTtchbf+smpACPjkzQ11uJ0aGBeU0MdI6NXmQrMoHa2FTcUIrEYR0+epqmh jjKPi3Qmw89++QrhaIy1K/rp7mxd8L0Hh0fJZDK4nPbiIFGpFbFvvnOUn+9/jdXLe/n4w/fS 0lS/SLtPp5Mp87ioqa7g0JETfOLhe4ubZoqicHXSz4Q/QGN9bXF4oKWxnstDI0zPztHe0lj0 YSgS5eSZ87S1NOJxOZFliebGOk6eOc/4hFaAWa4BtAZHxsjl8zgd9pIUE58LhXnjrXd5+fWD rF21jI8/dA/N/x979x0c55kn+P3bOXcD6EZs5JwIkARzjqJI5TSSRjOzs7Pr3XO56uzzna/s K/tqbZ+rzt5yuPKuz948Mzsz0owkShTFIIo5ZxIgMhqpkVM3uhudg/9oqEcUKe1wZvcG0vw+ VahigW/jRf/w9vs+z/N7nt/zmHKgWq2GXEcOBXkObtxp5w+j0fSA6XL7ZHRsgpm5eRrqqsmy WQnrI1RXldPTP8iCx5tpJyZTKeY9Xjp7+5c/57aH2ifjk1O4hkYwGgw01VZ/LZ7H8wteTl+4 yoUrN9iyYQ2/98ZLmb7F5+l0WvJy7dhzsrl1r4NYPJ6JcyKZZHh0jAXvIm2rmzLXYU1VOQ+6 +/H6fJSkCn7ZxptfoM81THVlOVlZVuLz6b2uwst7An5xADqwlF5po1qB/ZJT5y5z4vQFLEYD RTkmykqKaGtrIzs7m1gslt6bWKmk2FlASbGTrs4F7t67T8uqVahUKkKhEOcvXCIYCtPcWk5F eQnhYJCy0hKu3+3k4pWbbN+8jrm5OSYmJlBptEzPTmI2G1CmYly9eo2aujoGhscoKcgjHg1T WV7KpvVt+IMRbt/vxGa1pEspqVZm9//Yp+c5dfYiFqOWHLOZDW2raW1ZhV6vz+z9pVarKS91 4iwqZMjVx9XrN6ioKMdqtTI/P8/la9eJxVNUVZZT/Jj+zBepVCpycnLIzs5mZmaGmopSopEI V6/fQkMUp9OJzWZjdn6B7n4XGo2KdaubH9kzesW0CSMRDh89xcUrVzFqYMuGtRzYvxe73U40 GiUajS7v9aehsqIce24uI6Oj9PX109KyilgsxujoaHqiZFJBWWkxRQX5v1PjLu99dIJTZy9g 0iqor67i0IEDlJYUk0gkWFpaQqlUotFoaKitoqCgkNm5ea7fuEVOTjZKpZJRt5t77Q+IJ6Cu tpq8XPuv0JYP09vby61bt2hubiYvN5+3D3/MrbsdvP7KMzy9d/vXJrkG8M7hjzl94TI5Fj0V xQUc2L+H8rIyksnkwzGsq8Gem8ucx8ONW7dxLE86c7vd3Lx9l0QKmhprf6XVKalUiqmpKdxu N9U19Vy6dZ/BYTd/9J2XmJmZobq6enmVYXqlSLpvsrL6JaFwhPauXv78r/6esuIi9mxbx9T4 KBaziebmZmw2W6YajlajoqqshLGJGRqqSnC73czMzJCXl4d7fIy799spKMinuqrqVxqU1+v1 tLS0gEpLRXU9E1MzxOMxxtwjzM3MUFPfwL0H/fgCS1RXllFXXbkiqxkEQyHudnTxlz96h6ry Eja3NTMxNkxTY2NmxclnzxODXktVZTmjY5PUVaxjeHiYiooKcnJyGBoZ5UFnF4WFhVRWVvzK iY1AIMDlK1c4e/Eqap2RjevWUFNRwvDwMCaTiby8PC7caCewFMRmtWBdgWX6AktBbt17wI/f +YDG2ko2rG5g0j3C2rVrqKqqQq1WE1qeuGcy6qmpKsc9MUNFkYPh4WHy8/PR6XT09fcz4Bqk vLycosKCX6lEv1qtprCwMF1VTLGATq1mcNjNqHuMsbEx8vLysFgsjE1MEQqHsVotK7Jv5wsE uH77Pu8cPkZLYx3b1rcw5OqnqakxUyI3tLwvnclooLK8BNfIOBVFuQwPD1NUVITRaKS3r5/B oSHKyspwFjmfaCw0Ho8zPz+fXqGuUNLrSpeKXN1U/7XaUzGVSuHxeLhx4wZzc3Ns376d/Pz8 R54narWa0tJSBgYGGBkZwWq1olKpGB8fZ3Z2lnXr1mH8FSZrKBQKjEYjDoeDiYkJZmZmMmNC c3Nz6XLsxcWPXb0GkmD7rQ6oLHgXiUSijE1M4fEskkgmGRx2E45EUatU5OfaybJZmZtf4PT5 q0zPzqFUKqkoL2FpKcipc5fp7nPR2tzA6uVB+GAozPU797l8/Q7xeILm5YHlm3c7uHz9NnZ7 Fru3bUrPUsnJprK8hIHBEW7d6yAnx0ZOlo2lYIh7D7q519FNZVkJ+XmORwZ6VgKPdxGP10ck GmV4dByv10c8HmdgaBR/IP1hK8zPxWoxMz0zx6lzl1j0pZcpV5SW4A8EOHHmIv2DI2zb2Ebz 8qBcYCnI1Zt3uXGnHRTQUFNFIpnk2q17XL99n4I8B9s3r09/4JMpOrp6uXD1Jvt3bWPrxrXo 9Xp6+wf5+NQ51CoVLx7alymts5IkUyk+PX+Fy9fvUOosoraqnMDSEt19roeOcxbmYzaZaKqv obysmBt32vn03GXWtKT3GLt1t4Pb9x5QU1lGU30NarUKZ0E+2za18dGJ0xw9cSaT7O0dGOLy tdsYDXq2bWpDrVZhMOh54dA+fvT2YU6dvYxarSbPkcPk1AyfnrvMgmeRH3znVbRa7YoZUInH 4/S5hvnFkROYDAaqK8shld5z5TNKpQKrxUKew05jXTV1NZX0Dgxx8sxFnt63A5PRwNDIGD98 +33sOdmsbW0iJzsLs8nEqoZa+gaGePejkxgMevIcdqZn53j3o5OEIxFWNdVRWlyUfrAEQ4xN TD3UsNTE1YyOTdLd50KjUZNls+LIWVlL56OxGN29Lt754GPsOdnUVJYTTyQYGBr5XAyV2KwW 8hw5rGqspa66gs7ufk6du8y+XVsx6HX0u4b56XsfUZify7rVzWTZLOh1Wprrazh++gIfHDuF Xq/FnpPNzMwcP//gGIlEktbmeoqLCvAu+rh2+z4nz16ivqaSmqpyZhc8zHu8Dw3KZttsK24W bziS7oj97P2jlDgLqaksJxqN0T848tDgUZbVQq4jh9bmemqqyrnT3kmJs4Dd2zeh1Wro7nXx 7pETlJUUsW51MxaLieqKUhrrazh/+QZHjp9OxyDLxvTMHD97/ygqpZLWVQ0UFeTiHp9i0efn 0/NXKCtxsnfHZmxWK8FQiOu37/Ogu588h53qitIV2BELc6+jm5+99xHVFWXUVJUTDIUfiqFa rSLLaiXXkcPalkaqK8u5fvs+zqJ8tm9ah1qtor2zlyMnPqWqvIQNa1dhNhqoqSqnsbaam/c6 OPrJWdQaNTarhcmpWX7y7hEMBh1rVjVQXFSIs6iA+sfsqfGgu58H3X001dfw2gtPU1NZvqIa vH2uYY6cOMPs/ALfff1FlEpleuXO51gtZgryHGRn2XjmqV386O3DHP/0PHu2bybLZmFkdJyz l64Ti8V4ave2zErlp3Zv44c/e5+zl66Rk51FibOABc8ip85dZmh0nN9/65V06WCVip7+QS5d v417fBIUkJ/rIByJ8KC7jys37lDiLKSyvHTFldZNpVJ097k4+sk5vD4/m9avIZVKMfC56w8g y2Ylz2HHYc9h/66t/Oidw3x86hw7t2zAYjYxOOzm/OUbpIC9OzZnYnhw/05++LP3OX3hKhaz iaKCPGbnFjh5+iLjk9P8/luvZMoXbljbwrVb97h9/wHHP73A5vVr0rHtc3Hl+h3KiosodRZm NtteSTHs6Orl+OkLBJaCrF/bQiKZpM81/NBxOVk2HPYcCvJz2bltI+9+eJyjJ8+xdeNaTEYD /a5hLl67iVajYeeWDajVKnQpLc8/vYcfvn2YU+euoNfpyM9zpNuUZy8zO7fA77/1KoYvdLJm 5xaYmpnLxPzr0Hm909HJJ2cvEYlEaWttJhaP09M/+NBx9pwsHDnZFBcVsHXjWo6dOsdHJ86w sa0VvV6X/hxeu43JZGDrxnQbz2g08NIz+/nR24f55OwlVErlchn6aU6fv4J30ccP3noVrUZD TpaNitJi+gaGuHm3g5LiQvIcOUSiMbp6+rl64w75eQ4KlleurhRDI2N8fOosM3PzVJfm4xro x7Mwj8frQ7v8eTEa9JSUFNPY2ERLcwM9vX3cae/BfPhD6utqcY+Nc+TYSQwmCxvaVlNeUkw8 Hmfb1s3cvNvO//V//z+4Rw+SjMfw+fwEoknc45M01dexuqWZzgcdTM/M8IuPTuHIslJRVsSu Hdvx+oOcv3KDzp5+dm5eT6mzcEVOHnINj/LRyTMseDwU5phwj05yXaNmcHg0M7BhMhppbmqg oqqa1pYmhoeHOX3uIlqNhpKSYvoHXFy4fAOzNYt1a1ooLipcXqG/xPjEFDOzs8zMLRCPJVgK hhhxjy9PCEpRVOSkq6uTZBKyLFp+8rN3aGtp4KUXn8fjSw+UXbt5l9qqCta2Nq/YVak37rRz /PQ5/D4vmmSYsbExDn9wJHMdApSXl7F18yaaG2poXdXM6bNn+Iu/+SFP7duNUqHg5u07jE0v UFBYQHNDLTarmVgsnl6NMDmFe2IKz6KPaCyGx7vI4Ig7vTJDr1tecelhdt6zPCFuhkg0yty8 h96BIawWM3q9jpKighVX4vWzNs17H50g4F9Er4wxNTXJ8RMnMSwPyikUkJeXx7Ytm6mpLKe1 tZmzZ87xznuHCQaXsJjN3OvooGtgmKwcO+tWr8qsmvYu+hifnGbEPcGCx5feSiGwhGt4lPn5 Oc6fPbN8Daa4cPkab7//Mfl5DmbGR7l99y7+wFJmcFCjVpNls+Cw56yoGCYSiXT/+MPjxMIh QokEExMJTp46zcXLV1Eo0vvJOhx2tm3ZTF11BS3NTVy7dpXDHx4lHA5htVi4e7+d+9395OUV sH5NK/acbBKJJB7vIlMzswyNjuHx+kimkvgDAVzDo4TCYdQafbrvceMafX1DnDh9kcDCFC3N DdgdeczOe+no7uPGnXaybJaHJg+uhOtvenaOdz44xsDgCM/s38nC/ByXL1/BbrczNTOHVqtF q9XgyMnG4XCwfXMb7x89hXtyjqWAn+MnTqIzGDl38SpTExN869WXKCkpRqVSseBZTFd2iUYZ GhljKRgikUwx7B5DbzCiUqkozM+lpamBmupKYrEY4XCYe/fuMugaZOeuXfy/P/xFZlL2wb07 HpqItVJiOD45zbtHTjDsHufgvu2MjAxx785tFha89PQNoFKp0Gm1OOzZlJSWcmDXVt45/DHj 0wv4fYuEwidQqbWcOnuB+fl5vvPmt8jPy0WpVDK/4M3EcNQ9QSgcIZZI4hoeJZ5Ir2YxGIw4 nU5+/t6H9A2Pc/XadTauaUZBkvr6ejp7B7ly4w5ZNit11RWYTaYVF8ORsQneP/oJY5NTHNq7 nYG+Xnq6u/EFAnR0dqNUKtHrddizsygtLeO5A7v46bsfMbu4xJVr15mbXyAUjvLxiVOEI1G+ 9/xBrMuTb+fmPXh96QpDY5PTRKMxogkFruHRTJWDbJuFhoZG3GMTaJUJrl69yn9IhSktKmD9 +vV09rq4cuMuOVlZVJYVY9CvvL6da8jNh8c/ZXp2nhcO7Kavt5e7d28z7/HS3duPSqXCqNeT lWUlv6CQp/du42fvHWV2MUDw3n08i4uEIzGOHv+USDTKs4eexrac0J6dW2DR5ycaizE+OUUk GgVVioHhUULLMSx1FpJMpieFmM1m4okk7vGpdIWO4qJfaV/GlSIejzM6OsqtW7eIx+PpxGNv b+b/LRYLq1atoqSkhMLCQsrLy+no6MDv96NWqxkeHqagoIDKyspMNYnP+yxB9/l+nNlspqGh gfn5eS5evEhZWRkAbrcbnU5HbW3tlybrJMH2W9LT5+LitVtMTKX3s+jucxGJRHnng2NYzCaU CiUvHtrHxrZWLGYzVquZs5eu8Rc/fJu6mkoW/QHutndRVJjPvp1bKC91ZgaCnYX5TExN8+Of f0BdTSWpVIregUGi0RiH9u2iuaEGhUKByWTkWy8e4vDHpzhz8Rrjk9M47NkEAkH6XENoNGq+ 98aL5Oc6VmSWu7Onn0vXbzM9M8+iz0d3n4tAMMTP3v8IkyFdH/1bLxxkTWsjNqsFk9HIpWu3 +MsfvkNtdQXeRV96FnxZCXt2bKbEmV4RpNdpKcjPZXRskr/76fvU1VSSSCTo6h1ID1jt3Ulj XVWmoV1SXIRn0ccHx07R0+/CYDAw7B5jcnKG5w/uZf3alhW5uX0kEuH85RuMuMfRajScPHPp scd991sv0NxYS0NtFft2bOHnHx7jb37yLms7mkiR4va9TkxGI/t3baOuugKA/DwHz+zfRU// IH//iyN097nQLydD5j1edm7ZwOb1azLX7PNP76WrZ4CL124xNTNLniOHielZhkbG2Lx+NYf2 7VxRdYKj0RjnL99gcNhNRVkx569c59bdjoeO0Wo1rG1p5Lmn95Brz+HAnu384sPjfHrhCuNT 05hNJtzjE7iGRnnxmX2Z8oYGvZ5N61czOOLmxp12IpEIhfl5TExOc7+rl3WrV7F5/RpsVgvR aIyhETd/+9P3M+edmplFqVRy7NQ57nV0Y8+2sWndavbt2rqirr9QKMy5y9cZGh3HoNdz+sJV rty4+9Axer2OttYmnn96D3kOOwf37eLdIyf45OwlRsYmMBoMjI6NMzo2ybdeOERddQV6nQ69 TsfWTW2Mjk1y9eZdAktL5Oc6GJ+c5v6DHrZsWMP6NS1YzGa6+1xcv32fiakZSp2FvP3+0Udm Juc5ctiycS07t6ys8oaBQJALV24y6p7AkZPNyTMXOf+FwW+T0cC6Nat47sAe8nMdPHdgD+8d PcnxMxcYHHGj02kZGR1namaW77z2Qrq0pFaLTqtl55b1TExNc+n6bRZ9Puz29KDog+5+dm7d QFtrE2aTiRJnAft2bmHEPc57R04yOOzGnp2Ff2mJrp70fXPvjs2ZCR8ryaLPz8Vrt3CPT+Es KuDYJ+ceaXxZLCY2rGnh2QO7KcjP5cVD+zh89BM+/uQsfQPpZ+XQyBjzC16+9/pLlJeWpMsO Z2exe/smZubmuXD1JvMeL9lZNsYnpunuG2D/rm2sbm7IzLyzPKaTNTkzl97zyGgg157z0OrA lTHRYIhL126h1+m4cbudG7fbHzlubWsjLz97AKvFzAsH99HR1cuxU+cYHh0ny2Zh1D3B+NQ0 Wze1sWf75szr9u3cQm//IJ09/Sz6ApkScl19LtavXcWLh/ZhNpnQaNSsW9uCa9jN9Vv38HgX cRYWEAyFaO/sQalU8uKh/dTXVK64VdCxeJyuPhfXbt3FbDJy7eY9rt2898hxm9at5rkDu8nJ svHc03to7+zh8NFTuIbSM5uHRsaYnplj+6Z17PxcGdan92ynp8/F3fudLHi8OAvy06uGBobY sLaFlw7tz1Q6aKyrZt+urXx47FPefv9junoHUKvVdHT1kkgmefHQfirLS1dcpywWi9PR1cet ux3YrBauXL/Dlet3Hjlux+Z1PL13B7n2bJ59ajedPf28c/hj+gYGMRoNDAyOMDfvYceWDWzd uDaTXH9m/266e11cu3WP2bl5CvIcTM3M4xoeZeO61Tz39O5HVl37l5ZYCgYpyM/FaDSs+D5J NBbjXkc3dzu6ceRkcfHqLS5evfXIcXt3bGbvzs0U5uVyaP8uegeG+NE7H9DZM4Ber6VvYIgF 7yK7tm5kU9tqAHRaDS8c3EtnTz8XrtxkcnqWPHs2E1MzDI+Os3n9Gg7u27k8Y9TAswd28140 yvXb9/D6fBTm5RKORugfHCEajfHKcweoKHGuqHb17fsP6OlzEQyFGJuAeAwCk/O4pxcyx5Q6 C8nKysZqMbNtUxtDI27u3L3H1dvttHf14vH68Ifi7NyxnR1bNmCzWkilUhw8sJ/+wRFOn7vI +0eOU1iYj8FoYXJ2gaLCAg7t28mGthays2z09PaiUqTo7B1AqdFxo72HpWv3GBwZo7zEyesv PbMi+yMAN++009s/RCIeRZmKoUyp6RoYQeH65cS1itJiysvLyLJa2L1tE+7xCdrbO/j0whVM RgM+/xJLsRT7du9gY9tqLGYTkUiUvoEhfvLuR0TCIRbm5whGYoxPTnPkxGmu3bpPnj2bNasa 2Lp1K/39/WxuW8Wd+12MzS1y/todFNfv0T84gkql4uVnn1qx++UAnLl4jaFhN3q1AqPNyujk PO6phYfvhUlobW2loqyUQwf2MjE1Q2ffML7AMYwGPfNeP2qdkYP7drG6uQGlUol30c+tex2c OH2Bhfn0DG6fL0BXn4vkh8fJslopLS5kdXMDnf2DdA+4mfKcZmrOg8ezyJ32TkLhCDqtlhJn AT9469UVt/olmUxy+fptXINu9BrQGHXMeoLMfa5do1QoaKyvZe2aNZSXl3Nw3y5mZ+dxuVx8 cOwTTAYDS6EIS9EUzxzYS2tzAyajgVA4zP3OHj78+FN8Pi8L83NEonGGxyZ478hJdBoVsXCA uvpGLFYbt9q7mfd4sedkcfv+A0YmZrA7OtAst09tNgsb17ZycN+OFdemuXDlJkMjY2RZ9KiU ahZ8Ea7f+WUfWaVUUl9Xzfp166iwZ/PMU7tZ8Hhxj45w5Pin6HU6AkthwnEFLz1/kFWNdRgN ekKhcGYCkN+3yPT0LMkkDI2O8fMPjmG1WCjIs1NXUUUqGSUSjVFZ6qSrfxiTzUHy3FViiQR9 A8Ms+nzs3bGFdaubV05yMplkYnKaY6fOoVSpeNDdj3/Rgz+SxD8xy8jkHACOnCz27dyKUqlk 744tjE/N4hoawWM1M+SeYGZ2nqnpWTZu2sQf/v53Mp+zzp4+Ll+/w/TsPPMeD1NzXpIKFUdO nOPS9fsoFApef/Ega1oasWdnLY93RInW15PncFBeWoLJaFiedGolZ/mYlZbgHR2b5JOz6TGt B139zE1PEE6o6ewfRjGQnrxWkOtITzLVaDi4bweDI2P0DY3hyDIx7J5kenaO2XkP27Zt5fvf eQPjcv+svbOHKzfvMjfvYXp2hsVAmFgixbtHTmC1WAAFb778DJs2bWJ2fpHFj4/T2dlNwO+n ob4Ob7ib/oFhAkshDuzZTltr84qb8BJPJBgacXPm4lWUKOjo6mVqYoxIXEl7twuFIj3xqrgw n+1bNqDX63ju6b30D47iGp0ix2pkcHSSubkFFhZ97Nmzi9dffiHT9rjb3sW12/eYX/AyNj5O IBwjHEvy9uGPsZjSq/l+/9sv0dDQgFanJalU4blwlas37hFf30aUdnpdw3h9Pg7u3cGqxroV 17eLxxMMDA5z/vJNdFoNdzu6mZpwp6/DviEU/cMAlJUUsWX9WkxGI88d2Eufa4TO/hHysq24 RsaZnp7D6/Ozd/duXn/l+cwqylt3O7hxtx3vop9R9xhL4TgJ4rzz/seYzekY/vH336Awz4HT 6cRut+MLxVj0BzAZjZhW4IQnKrQAACAASURBVIq/f4hOp2PDhg2ZahBfTJB9NnnDYrGwfv16 bDYbU1NTpFIpysrKqKurIzc395HXKhQKsrOzWb16daakZLr/p6a8vBy1Ws3AwABzc+n7b0FB AdXV1RQVFX1pe1r1J3/yJ38i6a7fQoKtf5B7D7oZHZskHIliMZsoLS4iEoni9y/h8wdorKui vLQYhz2bgrxc4ok4/a4Rel1DTM/MUVNZxpsvP8uGttZMbWWdTkdZiRO1Kr3H2sDQCBPLibNn D+zhmad2P7QvSm11Jdk2KzPzC/T0D9LT72J8ahqL2cyLh/bz5svPZvbeWIkJtvsPuhmbmCIS jWG1mCkuKiAcjuDzB/D5A7Q01VHqLCTXkUNerp1YLE7/4DC9A0PMzM5TX1PJW689z9qWpsx+ RXq9jtLiItQqJUMj4+kYTk2Tn+fghUP7eGrPNozLGxkrFArKSp1oNRqmZ+boHxphdGwSnVbD 3h1beOu157GazazESQLhUITOnv5M1v6zmH3xa+3qJpwF+ZjNJvJz7disFoZHx+nudzE6Nokj J4vXXjzEzi0bMo2tz0pZlTqLcI9N0j84zLB7HJ1Wy76dW3j26T0UFxZkOivZNiulzkK8i34G hkZxDbuJxWK0tTbx1mvPU1NZvqKuwVg8TmdPP6lkanmZfOSRuAVDQRz2HFqa6tBqtZQ4C8my Wphb8NDbP8jw6DipVIqndm/je6+/SK49J/MeHTnZOAsL0isKe130uYYJLC2xsa2VN15+lsba qswGvO7xSU6cvpA5b57DTq49J11KzR8gmUriLMynoW5llamKRmPppHUKNGoNwVD4kRiGI2Fy HXZamurTD7oSJxaLidm5eXr6B5f3YVJyYM92fu+NF8myWTMxzHPYKch34POnJzAMDI4QWFpi y4a1fPuVZ6mprECpVLKw4GVkbAKVUgUoMvffz38pFApKigqpXU4gr5gkZThMz8AgCqUSjVpN MBh65HePRKPk59ppba5Pr4AuK8ZoMDA9O0/vwCDu8Sk0Gg0H9+7ge2+8lCk5B1CQl0terp1F n5/u/kFcQ6MsLYXYsWU93371eSrKSlAqlWi16ZJhxUWF+Px+BodHGVxOOOXnpZN6B/ftXJGD UkvBEP2u4fR9UK1m6TExjMViFOTn0tJUD0B1eSl6vY7J6Vn6XEOMjU9hMBg4uG8n3339hYdW sxQV5OHIycbj9dHT52JwxE0oHGb3tk1857UXKHEWfmXHIBgMpZ/3VWU01FavqDIYsVic8clp JqdmsWdnfekzJNeew+pVjRgNenKybZSXFjM9M4draJShkTFSwNYNa3nthaep+FwJTJvVgrOo gHA4imvYzcDQCP6lJRprq/jBd16jsa46s1Kr1FlIXm4OS8EwgyNuXMMjTE3Pkp1l5aVnn+K5 A3soWIHXXzQWxz0+yczsAtk225fGsLAgNz3IZDRgz8misqyUiakZBgZHGBpN7xGxfct6Xn72 KcqKnQ/FsLiogEAwhGsoHcNgKERzQx3ff/OVh5KOGo0aZ2E+NouZyakZegYGcY9PotVqeOHg Pl56dj/5uY4V1x6MRmOMuMdZ8Cxis1q+NIYlzkIa66oxGQ04crIpK3EyPjHFwOAIw6PjaNRq 9mzfzAsH92XK5362J2/63hbANeTGNTxKJBJhzapGvvv6i9RWVTwSk+mZOfz+AHXVFWxat3rl J9gi6RntPl96n68vi2F5mZP6mqpMDEuKCtJ9jcGRdBtPp2X/7m08+9RunIX5mY5vdpaNUmdR prR9uo0XZ92aZt589XmqK8oyMawoKyHXnoPX56d3YJDuvgFG3ZOoVCpeOLiXN19+jlxHzoq6 DnsHhlhaCqFWa1Cptah1BjR6IxrdL78aGhrYt2cHpSXF5OfaKS4qIBiJMTmzgDcQRKszsHPb Fr73xss01FZnBgyys7JYvaoJ1FrmvQG8gTDhSJz6mipeee4A2zenS97k5uZSWVnJ6pYWUGmY 9fgYcU/iDyzRUFvFt148xMa21hV7DXb3uQiFwmi0OrSfxe8LMWxsbGTXjq3k5+VSkJ9LUUEe oUiMqTkvi0thNDoDu3ds4zuvv0RNZXpftlg8zuDIGKfPX2EpGCaRBKfTSa7DTiKRzLTxystK 2LxxHeXl5WzdvBGTxca8x8/gyDjTs3Pk5zp4/uBenjuwZ8UmKSG9r3YKMJksj42hRmdky8b1 NNanS6oX5OfiLCxgcSnIzPwi/lAUa1YWzz29l+cP7aN0efKpfylIT5+L67fbicYSaLR6iooK sVrMRJf39tXpNBQVpidxjEzMEo7EUKtUFObnYTQYMu0rrUbDlg1rMn3plSKVgs7uPmKJBAaD EYPR8kj8tAYTjY31bN64Dqsl/XzNy80lGIkxM+8lEI6iN5h5ak+6TV1clI9SqSQajdHTN8jF a7cJR2Kg1FBWWow9O4tYLE4wHCEvL58d27exceN6fMEoOqOZrBwHWr2JZEr5UPs0Ho9TVJBL c8PKmrgWTyTo7OknkUxiMJjQG8yPxFBvstDc2MS2zRswm02UOotw2LNZCkWZWfCxFI5hslh4 et9uvv/tVyjIS7c7ItEonT39XL15l3AkilKlpaK8lJzsLCKRKD5/AL1eR3NjPTu3b6GpsYHW llWkFGpml/t6s3PzZGVZeWrXNl56Zn/mWb9SkkNzCx76BoYpzM8lFI6QSPLI86S0rIzvfvt1 6utqcRYVUlpcxFIozPjkDAu+IDq9gY0bN/Cf/+H3WL2qKTNJvrOnn3udPYxNTBGLxcnJzqGs tJRYPIE/kO77tjTXU+IszFSuUiqVZGVlUVBQgMmU3urCYjaxelVj5hm/0hIbM7PzDA67lytZ REGlfuReWFVdxbffeJXKigoK8vMoLSnC719ibGoWjz+IwWhm6+ZN/NH332JVY32mndze1cP9 zh4mJmeIx5M4HA5KSoqJRuOZz2bbmmaqystoaW6irrYGlUaPJxBkes7D1Mw8ZpOJg/t28sLB vVSUFa+8GMbiTM/MMeKeINdhJxSOolBrHolhfV0db7z2EhUV5RTk5VJaXIRn0c/U7AKLS2FM Fis7t2/lB999nYbPlUq/19FFe2cvk9OzpFCQm5tHcVEhkUgsE8MNba2UFhfhLCqisbGBsrIy gpEEY5MzjIxPolQpeWr3Nl569ikqSotXXL8kFo8zMTnD+OQ09pxsgqHwY6/DpuZmvvXKC1RW VlCQn0t5aQnzC4tMzsyzGIhgybKxZ9dOvv/Wa9RWV2be5+37D+jo6mNqZg5QkJ+XT2FBIZHo L2O4ZcNaCvPzyM/Po7CwkGAwzNz8AuWlxezetvFrlTdRKpVkZ2dTW1tLQ0MD9fX1D31VVVWR nZ2NWq1GqVRiMBjIz8+nrKyMiooKKisrM///uJ9tNpspLi7GbDZnPuvpfcw12Gw2SkpKKCsr o6qqisrKSux2+2NXwmWSdqnUCt0URTym4ZciEoky7/ViNBiwmE2ov2JlWTQaw7voQ6VWYTYZ H9kT5Ys/eykYIhQOo9NqsJjNX/t91x4nmUwRiURY8C5iMhmxmIxfuTovGo3hWVxMb3JtMn1l 7fNYLI4vECCRTGI2GTHq9d/YazEai7Hg8aJY3gD7qzqbyWSSeY+XRCKJzWL+yv1bUqkUiz4/ 4UgUo0H/0GD/N0UsHiewFCQcjqT3s9HrvjJ2S8EQ3kUf2Vk2jAb9ipul89sa2PcvLRGNRsmy WtF/RQwTifR+kj5/gOwsGwa9fsWW9vlP/RkOBJaIxePYrJav3AA7kUgQCIYIBJbIzrI+Ug7t i5/hcCSCx+vDYjZhNOi/VnW+n3Rg3x9YIpFMYLVYvrJkWTyeYCkYJBAMkm2zYdDrvpHP2Cdp z3i8i0Rjccwm41dO5Pls76WlYAidVkuWzfKlxyZTKcLhMIu+ACqlEoc9+xt7z0ylUix4FonF 41jMpocmTz3uWH9giWAojF6nxWa1fOX1F4lG8fn8xOJxHPYcNJ/b4Pmb1SZMsuBZJJ5IYLWY vnLA97NJK6FwBINeh9Vi/p3+DD/UxlvwkkgmsVnNX1mq50nbeKFQmEAwmCnT+02LdyKZJBgM 4fX5yLb9w228YCjMos+HQa/HbDI+tu39Wbc+sBQkGAqh0+mwmE0rqgrEP2oME4lM4iE7y4bB oP+NV9mmUikUCgXhSHrynEqpwmIxZfbk/iaKxxN4F32EIxEc9mx0K6gs/9clfoFgkGAwlOnb SfyeNIbp/nEoHF6O4T/eOEo4EsG76Meg12EyGjOTs75J7UG/P0BQ2ie/UQz/Kdp4qVSKSDSK x7uYLo+ak72iJ2n8pu/1szaeyaDPlKD/x7o/eBd9hMIRch0539hnVCqVWi5DGsNsNGAyGeWz /DUjCTYhhBBCCCGEEEIIIYQQQgghnoAshRBCCCGEEEIIIYQQQgghhBDiCUiCTQghhBBCCCGE EEIIIYQQQognIAk2IYQQQgghhBBCCCGEEEIIIZ6AJNiEEEIIIYQQQgghhBBCCCGEeAKSYBNC CCGEEEIIIYQQQgghhBDiCUiCTQghhBBCCCGEEEIIIYQQQognIAk2IYQQQgghhBBCCCGEEEII IZ6AJNiEEEIIIYQQQgghhBBCCCGEeAKSYBNCCCGEEEIIIYQQQgghhBDiCUiCTQghhBBCCCGE EEIIIYQQQognIAk2IYQQQgghhBBCCCGEEEIIIZ6AJNiEEEIIIYQQQgghhBBCCCGEeAKSYBNC CCGEEEIIIYQQQgghhBDiCUiCTQghhBBCCCGEEEIIIYQQQognIAk2IYQQQgghhBBCCCGEEEII IZ6AJNiEEEIIIYQQQgghhBBCCCGEeAKSYBNCCCGEEEIIIYQQQgghhBDiCUiCTQghhBBCCCGE EEIIIYQQQognIAk2IYQQQgghhBBCCCGEEEIIIZ6AJNiEEEIIIYQQQgghhBBCCCGEeAKSYBNC CCGEEEIIIYQQQgghhBDiCaglBEIIIYQQQgghhBBCiG+yVCpFKpX6B49TKBSZ45VKWZsghBDi y0mCTQghhBBC/O5JJSA4Br/CIMvvLAWg1IHOAUqNxEMIIYQQX2uRSASPx0MkEvnSRJtSqcRk MgGQSCTIzs5Gq9VK8IQQQjyWJNiEEEIIIcTvnlQS/P0wcxESQYnHYymg5EXQ2CTBJoQQQoiv PZ/Px/Xr13G73aRSKSKRCH6/H41Gg8ViQalUYjAYqK2tJZVK4ff72bZtmyTYhBBCfClJsAkh hBBCiN9BKUiEwPWXEJqUcDyOQgmF+yQOQgghhPhGMBqN1NXV4XQ6SSaTzMzMcObMGcrLy2lr a0On06FSqcjKyiIcDmM2m9FoZJKREEKILycJNiGEEEII8TsvkZRqkZ9RKEAl240IIYQQ4hvG ZDJRW1sLQDKZZGxsjN7eXqqqqli9ejUGgwFI7722tLRENBpFp9ORSCQIh8MolUoUCgWhUIhk Moler0ev15NMJgkGg0SjUTQaDWazGbX6l0Oun70+FAoBZF73+WOEEEJ8PcmdXAghhBBC/E5L pcAXglBUYqEAdBrIMUsshBBCCPENa+coFKhUqof+rVQqUalUmS+AWCzGxMQEc3NztLa2olKp 6OrqIpFIoFQqmZycJBQKkZeXR2VlJeFwmOHhYTweDwaDgebmZkpLS9FqtUSjUSYmJhgYGMDj 8QBgs9morq7G6XSi0+nkDyOEEF9jkmATQgghhBBCiH8ikUiUVCqFVqtBqfztLA1MJpNEozEU CgU63a+3j0wylSIej5NMJNHrn3wwMBaLk0gkUKtVMmP/S8TjceLxBCqVCo1GYiSEEL8tiUSC yclJ+vr6qK+vR61W09PTg8vlor6+nvz8fFKpFJcuXaKrq4uioiLsdjtqtZqOjg5CoRA2m43s 7GwmJia4dOkSAFVVVSiVSoaGhrh8+TJbt26ltLRUnotCCPE1JndwIYQQQgghPpO7FUpf/d17 34kozJyFiRO/9o+YW/DQ2z/I4IibwFIQjVqNPSeLhppqqivLUKtVmWPnPV4Gh0cJhyO0rW7G uFySKfPrJBIMDI0yODxKriOHttZmFArFL88176Gn38XQ6NjyuTTpc9VWUVNZlpmB/lX6XEOM uieoLC+lrNSJ6jHJr3giwa077SSSSaoqyijIczxRTMKRCP/q3/6vLC0F+Zf/xQ9obqj9rfx5 H3T38x/+v7/DoNfzf/y7f4NW++T7yXR29/Pe0ZPML3j4g7dewz0+CfzDdVWLnYXUVlXw8w+O ceHqTXZt2cDvvfmy3Gse4+cfHufTc1fY2NbCH3//TQmIEEL8FsXjcSKRCKlUilQqRSQSQalU 0tzcTHl5OX6/n7m5Ofr7+9mwYQMNDQ0kEgkAOjo68Pl8GAwGuru78Xq97N27l+LiYhQKBdnZ 2Zw8eZKenh5yc3OxWCwScCGE+JqSBJsQQgghhBCf0WZB9mrQ5f1uve/gCHju/FovTaVSHDlx mqOfnMU9NolOp8NsMpJMJPD6/KRSKTa0tfKDt16l1FmIUqnEPT7Jex+dZHZugcry0ocSbIlk kk/OXuL9o5+g1+v4/psvZ5JrqVSKD49/ytGTZxmbmEKv02EyGUkkEiz6/KRSsHFdK3/wnVcp Liz4yhVjF6/d4uiJs7zx8jMUF+Wj0j66sisajfL24Y8JR6J8+9XnnjjBlkymGJuYxO9fIhSO /Nb+vKFwmJGxCcxGI6lfc7PBsYlJOnv6yXfYOfbpOU6evkgimXzoOgAeSoQCHNy7g9w3c1jw eBl1jzPv8cp95kt4vIuMjk1QVV4iwRBCiBVGpVJRWlpKfn4+RqMRgIKCAoLBIHl5eZhMJuLx ODk5OcRiMWKxGH6/H7fbTTQaJRgMMj4+DoDf7ycejzM+Ps7S0pIk2IQQ4mtMEmxCCCGEEEJk KEGlSyfafpeEp36tl6VSKR509/Gz947iDyyxdVMbq+prMRoNJBJJ5hYWOHf5Bh+dOEN+rp2X n32Kwvw8QqEwYxNTTE7NEovFHvp5py9c4WfvHyUcjrBz6wYqSosz/9fR3ctP3/2IYCjE9s3r aKqvwWgwkEgkmJ1b4PyVG3x47FMKch289Ox+CvJyv/R3n5v3MDA0woJ3keSXJJ2SySSj45OE whH8gaXf2U9FJBplYmoGf2CJlw7tp6KsmLISZyapNjw6zqlzl4nH4xzYs52KsuLMayvLSrBZ ZeBQCCHE15tCocBkMqHValEoFCiVSrRaLUajEY1Gk/neZ6vok8kkkUgEv9/PwsIC3d3dmf3W EokEBoOBnJycRyamCCGE+HqRBJsQQgghhBDi13bzbjudPf288vwB3nr1eSpKizODRZFIlLrq Sv7sr35MNBojGot/6c9JpVJcuHqLn/7iI8LhCM/s38WB3dvJyU4nO5PJJDdup8/1xsvP8u1X n6e8xJk5VzgSoa6mkj/7yx8TiUaJfcW5fhM+f4CBoRH0Oh3lpcX0uYaYmZ0nmUySn+ugrNRJ TpbtK39GPJ5g3uOlf3AYj2cRAJvNQk1lGY6cnIf230omkyz6/PQODOFd9JFMJrGYTZSXFlOY n/dQ6U2Amdk5+gdH8C760Ot1lBYXfWksZucWcE9MMr/gJZFIYDYZKXEWUrK80vDzx42OTaDT ati4rpWq8lI2r1/zuWugg+4+F9FolAN7trNhbcvj37hCQSoF8wte+lxDzC940Wo1lJc6KS0u Qq/75d5uiUQCz6KPvoGh9Kq3FFitZirLS8nPtaPVpMtcLgVD9PQPolYpaairznwfYGZunvGJ acxmIzWV5ZnvT0xNMzYxhXcxvcLSZrVQ4izEWZj/0K8bDIVxj08yPjlFKBRBq1GT67DTWFeN RqPOXHvjk9PMe7xkWa3YLGa6+13Mzi+g1WgoLS6ktNiJyfjLVZrRaIyJqWl6B4aIRmNk2SzU VlUQXy4tJoQQYmVSq9UPJcQUCkXm69FHngKVSoVer6eiooK1a9diWF6xn0wmicVi6HQ6Wb0m hBBf92eDhEAIIYQQQgjx6/Iu+onHE+TZ7dgslocGmXQ6LevXrOKPvvcGZpORbJv1sT8jmUxy +34nf/fTd1n0+Xnh0D6e3reTXEfOF87lI55IkOfIwWYxP3QuvU6XPtfvvYHVYiLrS871m5qe nefdD09gNBqorSqnzzXE3LyXRb8fs8nI5nVr2LdzC3m59se+PhyJ0NM/yNmL1+gdGEKlUqJQ KIjH41SVl7F7+yaa6qoxGPTEYjHc41N8fOocPQODqJUqIEUsnqDUWciubRtZt3oVarWKZDLJ 5PQs7310kgc9fShQYLNaKMzPJZFIkEw+vEqvu8/FhSs3GBwZIxaLpVejKRRkWS3s37WVta1N mYTX6NgEk9OzFOXnUVJU+GvHTqlQMDYxyYnTF+jqHcDnD+D1+SnKz+XFZ/azqrEOs8lIJBrF NTTK6QtX6OwZ+FyMEpSVONm5ZQOtzfWYjAYWPF7eOXwUg17PvygpRmv7ZYKtb2CYY6fOUVFW kkmw3W3v4sylq0zPzBGPJ0imUqiUSgoL8ti7fTNrWhoBWPT5uXDlJjfutuP1+lCplCQSSZRK JZvWr+aZ/buwmE0oFArau3q5eacde0429mwbD7r78fkD+PwBHPZsnjuwh7WtTVjMJoKhMN19 Axw5fhrXsJssmxWrxUTvwBCuoVGSqaTcVIQQ4hvCZDJht9vx+/1YrVZyc3NRKBT4fD46Ozsx Go3k5uZKoIQQ4mtMEmxCCCGEEEKIX1t1ZTkWs4mb9zooLiqguaGGLJsNs9mIdrlk0rZNbV/6 +lgsTm//IP/xb3/K+MQ0337tOQ7u20n+FxJUCoWCmqpyLCYTN+60U1SYT1NdDVk2a+ZcSqWS 7ZvX/ZO+X5/fz7Vb9whFIjzoLqKhtorqyjImpqa5cuMOfQND6HU6Xn7uqce+fsQ9zi8+OM7J sxdpW91Ma3MDaqWSOx1dvH34Y2bm5vn+my/TVF+DZ9HHpxeu8H/+x79l384tNK+qQa1Wce9B D0dOnmFiaobiogKKiwqIxeJ8fOocf/Xjn1NfW8WmtlaMRgOj7gke9PTh9wewmk1AOqH53kcn OXPxKuUlxaxtbUKjUeMem+DspWtMTs9SWVZCfp4DhULB6NgE/kCAdatXodVqfu3YRWMxuntd JBIJSpxFlJc6ae/s5ecfHieRTJKTnUVddQXjk9McPvoJvzhygrbVzaxpaUGtUvGgu48Pj51i bGIKg0HHmlWN+ANLXLl+B4vFTDQafeh8k9Mz6b9VOJx533/9k19w/0EPa1uaqK+tJJVK0e8a 5tTZSyx4vLQ01aFaPtdf/f0viEQibNmwluLCAmbn5zl/9RYnz16krMTJ2lWN6PU63OOTXLh6 E41aTWV5CWXFTqoqSunqHeDoybPE43HsOVk0N9QyPjnFux+e4N2PTvL03u2sXtVAMBjmbnsX Pf2DhEIRuakIIcQK8cWVaU9SzlGhUGA0GqmtreXy5cvcv3+f2tpaFAoFw8PDPHjwgPXr12dK SgohhPh6kgSbEEIIIYQQ4teiUCjYsXkdbaubuXz9NkMjY6xtaWT1qgZqKsvJz3NgMhqwWSzo dNpHBqZisRhDI2O8e+QEn5y9yH/3X/4zDu59NLkGoFQq2bllA8daz3Pl5h0GR9ysaWliTXMD NVXl5OXav/Jc/2jvGQWxRJwR9zj/7Ptv8uKh/disZsLhCH/703f5m5+8x4kzF3j+0N5HXptM prh28x7nr9xgTXMj//5/+FdkL5eTfNUf4F//yf/GlRt3aKitoqG2Cn9giRH3OKsaavlf/vv/ Gnt2FkqlkmH3OP/7n/813f0u7rR34izMJxgK8aO3D2MyGvjn/9l32bRuDWq1Cvf4JD/5xRH+ /K//PlMCMRqLcfNuO/bsLL77+ovs2rohPaPeH6Dt/BXOXrpOLB4nlUoRTyQYHZ8kGotTX1v1 G8XOu+gnt8rO6y89w9aNbaRSKfyBIA96+rnf2cPUzCy1VeXca+/i5JmL1FdX8Kd/8q8zZUL9 S0v8T3/6Z1y+docLV27S2lT/K587lUoRiUS5ePUm69a08AfffY1VDXUoFOlE3OnzV+npdxGL xVEqlQwMjWIyGnj9xUO88vwBdFotgaUgLc0NfOeP/yVnLl6lsqyEAr0OhQI83kVyHXZeff4g u7dtBCAcjjA4PEpX7wCj45M01tXQPzjCp+evsKqhhn//b/8bjAY9CoWCu+1d/Omf/RX3Orrk xiKEEP+JaLVanE4nNpvtodLICoUCq9VKYWEharUalUpFXl4eJpMJlUqVKQtptVrJz89H87ny xAaDgZKSEvR6PVqtlurqaqLRKL29vczOzqafw9EoTU1N1NbWZvZlE0II8fUkCTYhhBBCCCHE ry3LZuV//G//Oe9/9AkfHj/Nh8dP887hY6hUKooK8tiyYQ0vP/sULU31mM0mlJ9LfE1Mz/IX P36HqzfvkkwkUCmVpEiRSqUemyDLsln5n//Nf8W7H53gyPEzfHjsU955/2PUahVFBfnL5zrA qsbaTPm+fwoKhQKTwcAzT+3CakmvCtPrddRVV1JaXMjE1DTzC14syyvGPhMKhxkaHSMWj7Nu 7apMcg3AajGzfs0q7j/oYXRsgmAoRFV5Kf/u3/wL4vE4iWSSSCRKihQ5WTays2wEAkvMzM6T SCSYnVtgaHTs/2/vzoPjvOs7jr+f3efZ89nV6l6tbsuyZcu2bCe2cQxxHGKSENcJkARowrQF Ou30mOlMZ9rpP22G6UwHaGcKUwY6BXcYSNISyEGchJiQACEkcXwpvm3Jsu7LOvaW9uwfsmUr lkOUQID685rxH97j+e3ze36z0uqz3++P3XfcSri6cn5vtrpImE0b1+F/9PIeYIV8Acs0GR27 QP/gMLF4Arfbjc/r4Z67dvKxXZer7waGRhgYHCZg+2lrXfae5s2yTFa1Lmfrpo3z8xgM+Gmo jXCut4/Z2QzpmVn6YHsALQAAEpVJREFUBoeIJ5Ns2bRhPlwDCPj9bFzbzoFDR+npGyCRTC1p /HyhgGVZ9PUPMTwyRnNDHS7LorKinAfu271gvfzRpz7GA/ftvthes0AqPVcF11A31yJzcGh0 QcWcaZosa6xn+02b52/zeNzURsK8efwUqVSa9MwMI6PjJNNpPnDj+gX7snWsmQulT57u0puK iMj7wOFwEAqF2L59O263e0FIZlkWK1eupKmpCduea0m9adMmHA7HfCDmcrlYsWIFzc3NBIPB +T3XIpEIgUBgPrQLBAJ0dHTQ0NBAPB6nUCjg8/koLS3Ftu0FwZ6IiPz+UcAmIiIiIiLvSWV5 GZ994F4euG83w6NjHD1xhkOdxzlw5Bj/88QzPP70Pv7mL/6E++++k0i4av55yWSK8QuTfONf v8DX9zzC1/Y8jB3w8we330pJMLD4WBVlfP7B+/nM/fcwNDLKsZNnONh5nIOHj/Ho43v5wQ+f 52//6rPcu/tOaqp/M/uamKZJTbgKt2thpVwgYBMKBekfGGZycuqqgG1yappoLEHA7ydcWbHo ufl9XmLxBFPTMWy/n3giyUsvv8Yv9x9meHSMZCpNLp/nfN8AHrebXD5PNpdndHyCYrFIdUUF bpdr/piGYeDzeqisuFwV6PV6+NTHd/H1PY/w0Be/ysOP/ZDNN6xj643r2bp5I6Hg5b30zp7r ZfzCJM2Nc60P34uA7aekxMbhWBh8WpaTYnEuWI1GY0xNx/B5vUQWuX7lZSECtp9kMsXkVPQd j20YBn6flz//o0/ztT0P89d//wVWty1n88YObtq0gY3r2wna9vzji8Uibx47xcuvHuDk2W6m pqLMZrOkZ9IA5C5W+F3i93kpDQWvOrdL++PlCwWSyRTT0zHclkX1W66/w2FQGgoSvMa6FxGR Xz+Px0M4HL7qdofDQWlp6cKf0W/ZK83pdF71GMMwsG0b+4qfJ4Zh4PV68Xg8VFdXzx//N/Ul IBEReX8pYBMRERERkffEMAxcLguXy8LjqScSruLmrZuIJRKc7TrPQ1/6Kt/93ydZt3ol4StC k6bGOv7x7/6KLRs7qItU8w///G/s+e5juF0udt2+A6/H87ZjLWtqIBKu5kNbNxOPJzjddY5/ +uJX+fajT7CuvY3qqooFFXNXcl7841Y+X6CQLyz6mMxslkKhgOl04nRc3iPFYRiLtqF0Oh2Y TieFi60V3yqXy5PP5zEM46ogBsAyTZxOB/lCgXy+QE/fAHu++3327nuJG9evYV17GyVBG9M0 ef4nL9PT1w/MhUGZbAaKYFomhuPqPWNM01zw/9tv/RD1tTW8+sZhDnYe58Wfv8pTz75AdVUF n3vgPnbdvgPb7+PsufMUgaaGuvmquHfLYRjXvB6XoqpcPk8ud2mOrv5Wv+l04nQ6yecL5PK5 Ja/Te+++g9aWJl7Zf4gjx07yw+de4LEnn2V5SxN//OlPcNfO7QA8+vheHv3BXgzDYO3qFaxr X4nH7SYWS3Dg8DGKbz03hwPnIq/XuOLc8oU82XwOw2FgWuaia9KpSgYRkf+3vytpvzURkf9/ FLCJiIiIiMi7Nh2NkcnmKAnYuN0uLNPEMk1sv5+K8lKqKsq5ZdsWnnjmxwyNjJFOp+ef6/W4 aa6vxfb7aG9r5S/+5AG+tudhHvnB03g9Hu687eYFf4yaikbJZvOUBG3crotj2SYB209leSmV FWXs2LaFJ599geGRMdLpmQVt+K4UDAawLJNoLE48mcS3yONGxi8wMzNLWWkIv//y/flCgXR6 ZkEFE0A2m2M2k8XpcC4aDno8btxuF5lslkQyfdX9qZkZstkcbsvC4XBwqqubH734c9avWcVf fu5BystCWJZFLpfj1Nnu+YDNYRh4PB4w5tpQvjUwzOVyJBJJSgKXv1EfsP10rGmjsS7Czlu2 MT4xyYnTXTy+dx9f+c9v07qskVUrWuju6bvY/rDufVlPbrcLj8dNNpsjkbi6BWR6dpZMNovL svB6PGQyWTCMq67FpeuRnp1dcFuoJMjmjetoaW5g10d2MDp+gYNHjrHvp7/g63seZsOaVfj9 Xp7+0YsUCgXu3X0HN2/dhM/nAQx6+wff/Ydv08RlWRQKBdIzs1ef28zsoreLiIiIiMjvJgVs IiIiIiKyZMVikdnZDF/+j29CET79iV2sbmtdUKF0qT1hNp+jUCjgdDhwGJcrdAwuVym5XC5u vmkzQ6NjPL53H9976jkCtp/t2zZTLBZJp2f40lf/C6fDwR/eu5u2FS1XjeX1eshe3K/M4XQu WiV2yaoVLZQEAxw/dZYz3eevatlXLBZ56RevMTo+wQ0da6irudxCKp/PMzE5xfiFSbxeD+bF EHBqOsrE5DR+v5eKitKrxgyVBCgvC5FKpznfN3DV/X39Q6RnZigrC+F2W4yOXSAWS7ChYzXt bcvn94c5cbqbyanYfGWUaZqEKyuwTIuBwRHSF/cLg7nAbWx8gsnpKLU1c62ppqNxenr7qQlX UV1VQbi6knw+z/LmRjKZLP/y79/gXG8/pmkyNDJKVUU5zU3178u6CgZsKspKyWSzdPX0XnX/ 4NAI8USSstISSkuCxBMJTNMkkUpRuCJkS6ZSjE9MEo8nACgUCkxNx+jq6aWtdRm1NdXURcJk sy3URcIkUikee/I5evr6qawoZ3B4lNZlTaxdvZKW5gYAorE4vf1DlxYIxSWem+3zUVYaIpvN 0TcwtOC+aCzO2IUJkkvcV05ERERERH57FLCJiIiIiMi7YhgG0Wic1w4coUiRnbdso6m+Fp/P R7FQYCoa5cSpLt44dJTG+lpqa6pxuaxrHi9UEuCunbcwMTnFiz9/je899RyloSBrV6/EMAym o3H2H+wEw+C27TfRWFeLz+e9GJ5EOX7qLG8cPkpzQx214SpcluuaY61esZwNa1ez//CbPL53 H5lMlqb6Wlwui2gsztETp3nq2Z9QXhbihvXthKsXBnDZbI4nntnHPXftpKa6kvELkxzsPMZ0 LMa2zTcQsG1mZzMLnuNxu1nZ0kxFWSkHjhxl/6E3aW9rhWKRk2e6ef1gJ2WlIVa0NOP3+XBZ LorA0MgYsXgSr9dD/8AQP/vl6wwMDQMQiydwOAzKy0K0tTZzquscB44cw7b9eNwujp/u4qVf vL6gneV0NMZjP3yOSLiKW7ZtoamhFqfDyWwmw2wmg9PhxOPxcLqrh3gixcZ17dRUV70va8rt ctHS3EBdJMzBzmP8cv8hOtrbADjTfZ7XDnbi83pYtaIFr9eDZVlUVZZzqPMYJ89043a7yOfz HDxyjM5jJ+crIAuFIpNT0+x5+PvctHkj27ZsnD+n2dkM2WwOp9OJ1+vB7XLhsiymojEmpqZJ plIkEik6j5/i5VffwO/zEo3FyWazSwrZ3G43keoqykpDvHHoTQ52HqelqZ6Z2Qw/f2U/p7t6 5npKioiIiIjI7wUFbCIiIiIismSX9kJ74L7dZHM5jhw9ycDQCHWRMAHbplAoMDE1Tfe5Xvw+ Lx+7ayetyxp/5f4j9bU17L7zNqajcV4/cIRHH99LqCRIXaSGz9x/91x40nmc/oFh6iJhbNs/ N9bkFN09fdi2n0/sup2WpgaczmvvZ1VeFuKej95GNpfj5OkuRkbHaayP4HG7mZyKcvJMN5Zl suv227hx/doFLR9Np5Oy0hK6enr5wdPPEwzYDA6NcvjoCRpq51ouLrofl2GwYd1qPrLjg/z4 p6/wze98j/VrVlEsFjl68gyxeILbtt/EhrWr8Ho8NDfWsWpFC7947QDVFeV4PG6mpmM4HAbL lzWSPZ3l9YOd7N33Uz6yYxuf+vguvvXdx3jyuRfoPt+H7fdxYXKKC5NThKsqKFysuvJ63eRy eX72yn7O9w3S1FCL6TQZuzDBkWMn2b5tEyuXN/P43uexLJO6SBif1/O+ravVK5dz187tPPns C3zzO9/jxvVrKV4MIcfGJ/jQ1hvZcmMHhmFQEgiwfesm3jx2ike+/zSHj57AYRhMTk2TyWYp LwtRLBbnqil9XjKZDM/s+ylnz50nEq6iWJyriuvq6eWWD25mWWMDHreLGzes5bUDR3jq2Rfo OtdLJpslnkgSqali/dpV9A4M8cQzP+aT93yUd5qyORwGy5rq+fDNW3n6Ry/yjf9+hPa2VjLZ LMMjYwCEgoFF212KiIiIiMjvHudDDz30kKZBRERERK4rxTwkumFwL2QTzGQhlweCrVC+BQwn 5Geun3+ZCZjqxIgex3SC1wUYBjQ/CL4GcCxedWYYBvW1NTTV12KZFhcmJuntH6K3b4CBwWGS qTSNDbXct/sOdt2+g4ryMgASySTRaJzSUAk3b92E7fctOG51ZTnBgE08mWJmZpamxjrqa8PU 19bQWB/BcpqMT0xyvn9wbqyhEVLpNI0Nddx/953s+sgOystKf+UyaKiLUB8JY5pzx+vtH2Jw eJRkMkVLcwP33n0nH73tFmqqK+efMzw6zk9efpWgbfPpT+zmUOdxDnYeZ3h0nIa6Gu6+8zY+ fPNWnE4nhWKB7p4+KivK2bppPeVlpYRKgtRUV+F0Ounq6eXoiTOcPdeL0+Fg5y0f5A/uuJXm xnocjrn2mmWlIQYGRzh19hzneuZCszs+vJ2NHe0UigWGRsaIxuLccevNtC5vJpvNMjo6Tvf5 foZGx6irCbP9ps2UBANUVZSxfdtmSgIBaqormZmZpaund75N5lQ0xoqWJj734H2sWN7M4TdP UFYWYvPGDiLha1ewJVNppqaiVFaUs7GjnYpF5n54dIwiBmtWtbJqxfIF93X39hHw+/nADeuJ hKsIBmwiNdW43S66evp488Rpzp7rpVgssn3bZu6+88OsaGkG5lqLRmqqSKdnGRge4Wz3ecYn Julob2P9utXYPh/1dRG23LCOYMCmtibM1PQ0Z7vPc/xUF909vczOZtiwdjUP3n83DXU1mKZJ ZXkpqVSac739nOnqIZ5I0t7Wyic/dhdB22Z8YpK+wSHWrlqJ5bLIZrOsbF1Gx5pVC86tt38Q j8fNDR1raKqvJRDwU1tTTTKVoqd3gK6eXianptm6aQNtrcsoDQVZvqyJde0r9T4tIiIiIvI7 zijq63EiIiIicr0pZGD4edj/ZxRTw0ynIJ0BKrdBw73X33zkMzD2EsbQj3BbUGYDhgN2PAcV HwTT984OUyiQSqVJJJJgGJQEbXxe72/mJRcKJFMpkonUr2WsTCZLLJFgNpMhaNvYft+CtoqX HOo8zt9/4cu4LYv/+dZXcLtdTE1HMQyDgN+Px+N+R+MVi0Uy2SwXJqcxgIqyUizL4q1DFotF srkcFyan8Hm82H4fpjlXBZjL58nlclimuaAyMJ5IkkylcLvdBG3/21YNpmdmiScSFAoFgoGF czgyNo7T6SQYsHG7XO/7spw79zwXJiYBKAvN7U232HUBiCUSpFIz2LYPn8czv7/fYpKpNPFk EodhELTtRa9bvlAgFk+Qy+WwfT68V1TxzczO4nQ6MZ3Oa76et30LKhSYjsVJp2coDQXxuN1v +3pFREREROR3j1pEioiIiIhcMv7K3D95V5wOBwHbT8D2vy9jBW2boG3/Wo7nclmLVl4tqgiX vqZomSZVFeVLHs8wDNwuF7Xhql/5OJdlEVlkDzTzYsDzVku5Bl6PG+81QsFwVeVvdT3Nnbv5 ttVzV1rKevD7vPh93l+5xkpLgove53G739O5ORwOykIlECrRG4eIiIiIyO8pfUVORERERERE REREREREZAlUwSYiIiIi1zXDgKAXAh7NxaX5kGvz+32sXtmCaVo41dJPRERERETkuqWATURE RESue07lJPIO1deG+cvPP4hhOHC7XZoQERERERGR65QCNhERERG5Dhng9ELLn0I+pem41hyZ tqbhLXxeLytamjURIiIiIiIi1/un5mLx0vbcIiIiIiLXiWIeUgOgX4Xf5pMC4HCDuwIcluZD RERERERE5MqPzQrYRERERERERERERERERN457TYhIiIiIiIiIiIiIiIisgQK2ERERERERERE RERERESWQAGbiIiIiIiIiIiIiIiIyBIoYBMRERERERERERERERFZAgVsIiIiIiIiIiIiIiIi IkuggE1ERERERERERERERERkCRSwiYiIiIiIiIiIiIiIiCyBAjYRERERERERERERERGRJVDA JiIiIiIiIiIiIiIiIrIECthERERERERERERERERElkABm4iIiIiIiIiIiIiIiMgSKGATERER ERERERERERERWQIFbCIiIiIiIiIiIiIiIiJLoIBNREREREREREREREREZAkUsImIiIiIiIiI iIiIiIgsgQI2ERERERERERERERERkSX4P/Oz00dntCVRAAAAAElFTkSuQmCC --------------95FFF33748AAEF7C5BDB07F0-- From nobody Wed Apr 10 01:48:08 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91681202D3 for ; Wed, 10 Apr 2019 01:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1jYuiYux_yIR for ; Wed, 10 Apr 2019 01:48:03 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB471202D2 for ; Wed, 10 Apr 2019 01:48:03 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hE8te-0001za-V4; Wed, 10 Apr 2019 08:47:55 +0000 Date: Wed, 10 Apr 2019 10:47:54 +0200 Message-ID: <87ef6a2qmd.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: Jon Callas , "openpgp@ietf.org" , Justus Winter , Peter Gutmann In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 08:48:07 -0000 Hi Bart, Thanks for this mail. This much more succinct mail then I have been able to write captures my concerns with Jon's line of thinking. @Jon: I hope you'll take the time to respond to Bart's questions. Thanks! :) Neal On Sun, 31 Mar 2019 06:11:25 +0200, Bart Butler wrote: > On Saturday, March 30, 2019 4:09 PM, Jon Callas wrote: > > > On Mar 29, 2019, at 7:17 PM, Bart Butler bartbutler=40protonmail.com@dmarc.ietf.org wrote: > > > Hi Jon, > > > As others have noted, there is a lot of confusion on this thread, some of which you touched in your AEAD Conundrum message, like when we say AEAD should not release unauthenticated plaintext, do we mean the entire message or the chunk? > > > > > That is precisely the question. But the bigger question is whether you care about that. Sometimes it matters, sometimes it does not. > > > > > For example, let$B!G(Bs suppose that I have a very large blob on mass storage. Media failures happen. If there$B!G(Bs a bad block on a disk, do you want to lose the whole file because of it? Sometimes you want to throw your hands up in the air. This is most common in an interactive protocol, and in general the answer is yes. For example, an SSL connection to a server, if there$B!G(Bs funny business going on, you want to blow up the connection and try over again. On the other hand, if you had an archival thing (e.g. tar file with some historic documents), you want to recover as much as you can. > > > > > OpenPGP is in general the latter case rather than the former. I believe it$B!G(Bs less important to have strict semantics on failures because it$B!G(Bs usually storage. > > > > > I agree. I would say my point is that with sufficiently small chunks, the user/decrypter can choose what kind of failure behavior is appropriate. Large chunks robs the decrypter of that. > > > > Another piece of confusion is that Efail isn't a single vulnerability, it was several vulnerabilities related (at best) thematically. > > > > > I understand Efail. Trust me. > > I do. I was bit excessively pedantic defining everything because I felt that this thread has suffered from ambiguity in several terms. > > > > > > > So to be very specific, for the purpose of the following discussion, the advantage of smaller AEAD chunks is specifically to prevent Efail-style ciphertext malleability/gadget attacks, and the prohibition on releasing unauthenticated plaintext is applied to individual chunks, which is sufficient to foil this kind of attack in email. > > > > > I disagree. If you want to prevent something like Efail, you want larger chunks. Assuming that you believe that early release matters. > > > > > Let$B!G(Bs rewind here, and not talk about Efail, let$B!G(Bs talk about the real issue. If you want the entire blob to have all-or-nothing semantics, then you want the fewest number of chunks as is reasonable. If you have attacker-controlled inputs, then every joint between the chunks is a vulnerability. > > OK, I think this is the part that I don't understand. Why does it matter what chunking scheme is used here? If my app requires all-or-nothing semantics, I would program my app to enforce that all chunks must pass and not release plaintext unless that happened, with no truncation, etc. So why would every joint be a vulnerability? > > > > What value does large-chunk AEAD actually provide? What I'm getting from the AEAD Conundrum message is that it's a way for the message encrypter to leverage the "don't release unauthenticated chunks" prohibition to force the decrypter to decrypt the whole message before releasing anything. Why do we want to give the message creator this kind of power? Why should the message creator be given the choice to force her recipient to either decrypt the entire message before release or be less safe than she would have been with smaller chunks? > > > > > Let me summarize the conundrum: If you want strict AEAD no-release semantics, you want a fewer number of chunks. > > I guess this is my fundamental question. You can force no-release semantics at the application level for any chunk size scheme, right? > > > > > > > Coming back to Neal's point, it's really hard to see any sort of value in really large AEAD chunks, because the performance overhead is negligible at that point and the only security 'benefit' that I can see is the encrypter trying to use the spec to force the decrypter to not stream, which does not seem like something at all desirable. > > > > > Okay, here$B!G(Bs another thing that$B!G(Bs a pet peeve of mine. We$B!G(Bre arguing security and you brought up performance. I never mentioned performance, the people who want large chunks haven$B!G(Bt brought it up. They want large chunks because they perceive it to be more secure.. > > > > > If you respond to a security request with a performance answer, you literally don$B!G(Bt know what you$B!G(Bre talking about. So let$B!G(Bs toss that aside. > > I apologize, I was not trying to create a strawman here, but I am completely at a loss for what the benefit of large chunks is. > > > Elided out of this, and possibly important is that $B!H(Bsupport$B!I(B includes chunks smaller than that size. I should have said that, but I wanted it to be as stark as possible. So let me repeat it and abstract it with some variables: > > > > > (1) MUST support up to chunks. > > > > > > > > (2) SHOULD support up to chunks, as these are common.. > > (3) MAY support larger up to the present very large size. > > (4) MAY reject or error out on chunks larger than , but repeating ourselves, SHOULD support . > > > > > Clauses (3) and (4) set up a sandbox for the people who want very large chunks. They can do whatever they want, and the rest of us can ignore them.. Why get rid of that? It doesn$B!G(Bt add any complexity to the code. It lets the people who want the huge ones do them in their own environment and not bother other people. > > > > > My concern is over (1) and (2) and specifically that there$B!G(Bs both and sizes. > > > > > I think that$B!G(Bs an issue. If there are two numbers we are apt to end up with skew before settling on one, so it$B!G(Bs better to agree on just one. That$B!G(Bs the real wart in my proposal. > > > > > I'm OK with eliminating (2) and just using the MAY part to take care of any legacy 256K messages OpenPGP.js users might have. As I said, we don't have any of these messages in production yet and I'd err on the side of a cleaner spec. I just really want to understand the benefit of large chunks for security and right now I clearly do not. > > [1.2 OpenPGP digital signature ] > No public key for 99054465EF331E44 created at 2019-03-31T06:11:24+0200 using (unknown algorithm 22) > [2 ] > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Wed Apr 10 06:03:55 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E7612012A for ; Wed, 10 Apr 2019 06:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 40qZAzGV4oMy for ; Wed, 10 Apr 2019 06:03:50 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7093F1202DB for ; Wed, 10 Apr 2019 06:03:50 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hECtE-0004bj-1m; Wed, 10 Apr 2019 13:03:44 +0000 Date: Wed, 10 Apr 2019 15:03:43 +0200 Message-ID: <87d0lu2es0.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: =?ISO-8859-1?Q?=22Conrado_P=2E_L=2E_Gouv=EAa=22?= , "openpgp@ietf.org" , Justus Winter , Jon Callas , Peter Gutmann In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87zhpd21d3.wl-neal@walfield.org> <1554001112803.75759@cs.auckland.ac.nz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 13:03:53 -0000 T24gVHVlLCAwMiBBcHIgMjAxOSAxOTo0Mjo1MCArMDIwMCwNCkpvbiBDYWxsYXMgd3JvdGU6DQo+ ID4gT24gQXByIDIsIDIwMTksIGF0IDY6MTIgQU0sIENvbnJhZG8gUC4gTC4gR291dqi6YSA8Y29u cmFkb3BsZ0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+IA0KPiA+IE9uIFNhdCwgTWFyIDMwLCAyMDE5 IGF0IDExOjU5IFBNIFBldGVyIEd1dG1hbm4NCj4gPiA8cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5u ej4gd3JvdGU6DQo+ID4+IEknbSBub3Qgc2F5aW5nIHJlbW92ZSBpdCwganVzdCBnZXQgc29tZSBk YXRhIHRvIHN1cHBvcnQgbWFraW5nIGEgZGVjaXNpb24gaW4NCj4gPj4gc29tZSB3YXkuICBJbiBw YXJ0aWN1bGFyLCBBRUFEIGlzIGEgZ29vZCB0aGluZywgYnV0IHRoZXJlJ3Mgbm8gZXZpZGVuY2Ug dGhhdA0KPiA+PiBjaHVua2luZyB3aXRoIEFFQUQsIHdoaWNoIGNvbXBsaWNhdGVzIHRoaW5ncyBn cmVhdGx5LCBpcyB1c2VmdWwgb3IgbmVjZXNzYXJ5Lg0KPiA+PiANCj4gPiANCj4gPiBJIGtub3cg eW91J3JlIHRpcmVkIG9mIGhlYXJpbmcgYWJvdXQgaXQuLi4gYnV0IEVGYWlsLg0KPiA+IEV2ZW4g aWYgUEdQIHVzZWQgQUVBRCwgYnV0IHdpdGhvdXQgY2h1bmtzLCBFRmFpbCB3b3VsZCBwcm9iYWJs eSBzdGlsbA0KPiA+IGhhcHBlbi4gSWYgdGhlIEFFQUQgZGF0YSBpcyBhcmJpdHJhcmx5IGxhcmdl LCB0aGVuIGltcGxlbWVudGF0aW9ucw0KPiA+IHdvdWxkIGJlIGZvcmNlZCB0byBwcm92aWRlIGEg c3RyZWFtaW5nIEFQSSB0aGF0IGRpc2Nsb3Nlcw0KPiA+IHVuYXV0aGVudGljYXRlZCBwbGFpbnRl eHQsIGFuZCB0aGUgc2FtZSB0aGluZyB3b3VsZCBoYXBwZW4uDQo+IA0KPiBObywgbm8sIGl0oa9z IG9rYXksIGJlY2F1c2UgdGhpcyB3aHkgSSB3YXMgc2F5aW5nLCChsExldKGvcyBub3QgdGFsayBh Ym91dCBFZmFpbC6hsSBUaGUgQUVBRCBkaXNjdXNzaW9uIGlzIGdvb2QsIGFuZCB0aGVyZSBhcmUg bWFueSByZWFzb25zIHRvIHVwZ3JhZGUgdG8gYWxsb3cgaXRzIHVzZS4gSWYgb25lIG9mIHRob3Nl IHJlYXNvbnMgaXMgY29tcGxleCwgdGhlbiBoYXZpbmcgdGhhdCBiZSB0aGUgbWFqb3IgcmVhc29u IG1lYW5zIHRoYXQgdGhlcmWhr3MgYSBjb3VudGVyLWFyZ3VtZW50IHRoYXQgaXMgZXNzZW50aWFs bHksIKGwaWYgdGhpcyBpc26hr3QgdGhlIHNpbHZlciBidWxsZXQgY2xhaW1lZCwgdGhlbiBtYXli ZSB3ZSBzaG91bGRuoa90IGRvIGl0LKGxIGFuZCB3b3JzZSwgaXShr3MgYSBjb21wbGV0ZWx5IHJl YXNvbmFibGUgY291bnRlci1hcmd1bWVudC4gDQoNCkkgYWdyZWUgdGhhdCBFRmFpbCBpcyBub3Qg dGhlIG9ubHkgcmVhc29uIHRvIGNvbnNpZGVyIEFFQUQuICBBbmQsIEkNCnRoaW5rIHRoYXQgdGhl IGNvbXBsZXhpdHkgY291bnRlciBhcmd1bWVudCBpcyBhIGNvbnZpbmNpbmcgb25lLiAgTGlrZQ0K RmVyZ3Vzb24sIFNjaG5laWVyIGFuZCBLb2hubyBzYWlkIGluICJDcnlwdG9ncmFwaHkgRW5naW5l ZXJpbmciOg0KDQogIFRoZSBtb3JlIGNvbXBsZXggYSBzeXN0ZW0sIHRoZSBtb3JlIGxpa2VseSBp dCBoYXMgc2VjdXJpdHkgcHJvYmxlbXMuDQogIEluZGVlZCwgd2UgbGlrZSB0byBzYXkgdGhhdCBj b21wbGV4aXR5IGlzIHRoZSB3b3JzdCBlbmVteSBvZg0KICBzZWN1cml0eS4NCg0KQnV0LCBvbmNl IHdlIGRlY2lkZSB0aGF0IHdlIHdhbnQgQUVBRCwgSSB0aGluayBpdCBpcyBmYWlyIHRvIGFwcGx5 IHRoZQ0Kc2FtZSBjb3VudGVyIGFyZ3VtZW50IHRvIGFueSBwcm9wb3NhbHMuDQoNCkluIG91ciBj YXNlLCBwYXJhbWV0ZXJpemluZyB0aGUgY2h1bmsgc2l6ZSBhZGRzIGNvbXBsZXhpdHkuICBJdA0K c3RhbmRhcmRpemVzIG5vdCBhIHNpbmdsZSBhbGdvcml0aG0sIGJ1dCBhIGZhbWlseSBvZiBhbGdv cml0aG1zLiAgSSd2ZQ0KYWxyZWFkeSBzaG93biBob3cgdGhpcyBwYXJhbWV0ZXJpemF0aW9uIGNh biBiZSBhYnVzZWQuICBCdXQgd2hldGhlcg0KeW91IHRoaW5rIG15IGF0dGFjayBpcyByZWxldmFu dCBvciBub3QsIEkgdGhpbmsgd2UgYWdyZWUgdGhhdCB0aGUNCmJ1cmRlbiBvZiBqdXN0aWZpY2F0 aW9uIG91Z2h0IHRvIGJlIG9uIHRob3NlIGRlZmVuZGluZyB0aGUgY29tcGxleGl0eSwNCmkuZS4s IGFsbG93IG11bHRpcGxlIGNodW5rIHNpemVzLCBvciBhbGxvdyBsYXJnZSBjaHVuayBzaXplcy4N Cg0KQ3VycmVudGx5LCBJIHRoaW5rIHRoZSBvbmx5IGV4dGFudCBhcmd1bWVudCBpbiBmYXZvciBv ZiBsYXJnZSBjaHVua3MNCmlzIHlvdXIgYXJndW1lbnQgaW4gPEJGQzVFNEVFLTAxRDgtNDU1Mi1C QkIwLUY2QjA5RDUxMTE2MEBpY2xvdWQuY29tPg0Kb3IgYSB2YXJpYW50IHRoZXJlb2Y6DQoNCiAg SSBiZWxpZXZlIHRoYXQgdGhlIG1vcmUgeW91IGJlbGlldmUgdGlnaHQgc2VjdXJpdHkgaXMgbmVj ZXNzYXJ5LCB0aGVuDQogIHRoZSBtb3JlICp3aWxsaW5nKiB5b3Ugb3VnaHQgdG8gYmUgdG8gYWxs b3cgcGVvcGxlIHdpdGggc3BlY2lhbCBuZWVkcw0KICB0byBnbyBvZmYgaW4gdGhlIHdlZWRzIG9u IHRoZWlyIG93bi4NCg0KQnV0LCB3ZSBkb24ndCBwcm9oaWJpdCBwZW9wbGUgZnJvbSBleHBlcmlt ZW50aW5nISAgVGhhdCdzIHdoeSB3ZSBoYXZlDQphIHByaXZhdGUgbmFtZSBzcGFjZS4gIElmIHNv bWVvbmUgcmVhbGx5IGhhcyBzdWNoIHNwZWNpYWwgbmVlZHMsIHRoZXkNCmNhbiB1c2UsIGUuZy4s IFRhZyA2MSwgZm9yIGFuIEFFQUQgdmFyaWFudCB3aXRoIGxhcmdlIGNodW5rcy4gIElmIGl0DQp0 dXJucyBvdXQgdGhvc2UgbmVlZHMgYXJlIG5vdCBzbyBzcGVjaWFsLCB3ZSBjYW4gc3RhbmRhcmRp emUgdGhhdA0KdmFyaWFudC4NCg0KKFRvYmlhcyBoYXMgcHJvcG9zZWQgZm9yZWdvaW5nIGNodW5r aW5nLiAgVGhhdCdzIGEgZGlmZmVyZW50IGFyZ3VtZW50LA0KYW5kIG9uZSB0aGF0IEkgdGhpbmsg aXMgbm90IGludGVyZXN0aW5nIGZvciB1cyBzaW5jZSBpdCBwcmV2ZW50cw0Kc3RyZWFtaW5nLikN Cg0KSWYgdGhlcmUgYXJlIG90aGVyIHVuYWRkcmVzc2VkIGFyZ3VtZW50cyBpbiBmYXZvciBvZiBs YXJnZSBjaHVuaw0Kc2l6ZXMsIHBsZWFzZSBzdGF0ZSB0aGVtLiAgSWYgSSBtaXNzZWQgdGhlbSwg cGxlYXNlIHJlcGVhdCB0aGVtIGFuZA0KYWNjZXB0IG15IGFwb2xvZ2llcy4NCg0KVGhhbmtzIQ== From nobody Fri Apr 12 06:37:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCE9120641 for ; Fri, 12 Apr 2019 06:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 6-xejLCo_872 for ; Fri, 12 Apr 2019 06:37:12 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C844C1204C3 for ; Fri, 12 Apr 2019 06:37:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 438D0E2044; Fri, 12 Apr 2019 09:37:08 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 01265-01; Fri, 12 Apr 2019 09:37:04 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 8CA6FE2042; Fri, 12 Apr 2019 09:37:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1555076224; bh=izzzJr6Vp8hFUt3ODSs4lwmiRgIX75niPPpzPMjs6Jk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=rSJK9x1XH8pnQvW7yB4hZASdA1MkikSNWHGFuw0ti4vdfjaOifwLirUAsO3JgJvwY kaf5tQN0R7zQdFV3H3IsBKql0G5pxd6JF6qQQnWT/nCQIhAILzUcLe86qCIxEj5WAC pd8qQ4vl3n/6MZwkTyE5iLhAyoKdkoTCWNL1HO6k= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x3CDb0Uu004558; Fri, 12 Apr 2019 09:37:00 -0400 From: Derek Atkins To: Marcus Brinkmann Cc: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> Date: Fri, 12 Apr 2019 09:36:58 -0400 In-Reply-To: (Marcus Brinkmann's message of "Fri, 29 Mar 2019 00:58:30 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 13:37:15 -0000 [ Coming back to this late after traveling for a while. My apologies if I am re-opening wounds... ] Marcus Brinkmann writes: > The main question here is: What should a conforming application look like? > > The current behaviour of GnuPG is that it will process internally (e.g., > through the decompression and signature verification layer) and output > externally unauthenticated plaintext. If an AEAD chunk is modified by > an attacker, GnuPG will detect the modification and cancel the > operation, but only at the end of each chunk. Due to the asynchronous > buffer management in GnuPG, quite often some part of the modified chunk > has then already been processed and output, depending on the particular > state of the buffers, the buffer size and the chunk size. This > behaviour increases the surface for chosen ciphertext attacks and > possibly adaptive chosen plaintext attacks (if an oracle is exposed). In my mind, this sounds like the implementation is broken. If it releases AEAD plaintext before the end of the AEAD chunk then it is non-conforming and should be considered broken. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 12 06:46:14 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5BB120706 for ; Fri, 12 Apr 2019 06:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 N1Se2pYE5a1A for ; Fri, 12 Apr 2019 06:46:11 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAB21206EC for ; Fri, 12 Apr 2019 06:46:11 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hEwVL-0002zF-Dk; Fri, 12 Apr 2019 13:46:07 +0000 Date: Fri, 12 Apr 2019 15:46:06 +0200 Message-ID: <875zrj2v6p.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins Cc: Marcus Brinkmann , openpgp@ietf.org In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 13:46:13 -0000 On Fri, 12 Apr 2019 15:36:58 +0200, Derek Atkins wrote: > Marcus Brinkmann > writes: > > > The main question here is: What should a conforming application look like? > > > > The current behaviour of GnuPG is that it will process internally (e.g., > > through the decompression and signature verification layer) and output > > externally unauthenticated plaintext. If an AEAD chunk is modified by > > an attacker, GnuPG will detect the modification and cancel the > > operation, but only at the end of each chunk. Due to the asynchronous > > buffer management in GnuPG, quite often some part of the modified chunk > > has then already been processed and output, depending on the particular > > state of the buffers, the buffer size and the chunk size. This > > behaviour increases the surface for chosen ciphertext attacks and > > possibly adaptive chosen plaintext attacks (if an oracle is exposed). > > In my mind, this sounds like the implementation is broken. If it > releases AEAD plaintext before the end of the AEAD chunk then it is > non-conforming and should be considered broken. I fully agree with you. Given this position, it seems to me that all implementations will necessarily fail on very large chunks (e.g., 4 exabytes). So, why even allow them [1]? It seems to me that these permissible options just create a temptation to create broken implementations. Thanks, :) Neal [1] https://mailarchive.ietf.org/arch/msg/openpgp/n1-e2shFQMqLphGY2VUvxdr9T40 From nobody Fri Apr 12 06:47:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D1C120713 for ; Fri, 12 Apr 2019 06:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 Z-9Z1fwZc9Mi for ; Fri, 12 Apr 2019 06:47:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04565120710 for ; Fri, 12 Apr 2019 06:47:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D0E17E2044; Fri, 12 Apr 2019 09:37:55 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 01200-03; Fri, 12 Apr 2019 09:37:52 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id A1FD5E2042; Fri, 12 Apr 2019 09:37:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1555076272; bh=cJCZZUrq4ARnPPS2ddy2Ii8wmmsyyuEUJG0rw5jYA3o=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=NWNIamFewqZXzPwtL8NatD0Cac6IWGlsDYcmb3CnFK8jDLV7riylckVca+gE5zsP0 HXCDJQACKbnv+gvdx6NpX5kFikaxYfj1zs+n5XCGG0iM1OtzIdoJpIoorm07b7IyjF B2NsfYEosmfsXz0A+SwxhQElib6b+ZxWz7EpvcyU= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x3CDbmO9004632; Fri, 12 Apr 2019 09:37:48 -0400 From: Derek Atkins To: "brian m. carlson" Cc: Jon Callas , openpgp@ietf.org, Justus Winter , "Neal H. Walfield" , Jon Callas References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> <20190330001949.GB12419@genre.crustytoothpaste.net> Date: Fri, 12 Apr 2019 09:37:47 -0400 In-Reply-To: <20190330001949.GB12419@genre.crustytoothpaste.net> (brian m. carlson's message of "Sat, 30 Mar 2019 00:19:49 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 13:47:15 -0000 [ sorry for coming at this late -- I've been traveling ] "brian m. carlson" writes: > On Thu, Mar 28, 2019 at 07:19:39PM -0700, Jon Callas wrote: >> Like some interim replies, particularly Bart Butler, I thought we >> had a rough consensus and that it was approximately: >> >> * MUST support 16KB chunks. >> * SHOULD support 256K chunks, as these are common (Protonmail). >> * MAY support larger up to the present very large size. >> * MAY reject or error out on chunks larger than 16KB, but repeating >> ourselves, SHOULD support 256K. > > I think this is fine. It covers what's requires for interoperability, it > makes prudent suggestions, and it allows people leeway if they know > they're the only one consuming their data. +1. I support this proposal. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 12 07:10:39 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252F120748 for ; Fri, 12 Apr 2019 07:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=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=ihtfp.com 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 LBKvKujRDRJY for ; Fri, 12 Apr 2019 07:10:35 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D355120731 for ; Fri, 12 Apr 2019 07:10:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D1E13E2042; Fri, 12 Apr 2019 10:10:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02114-05; Fri, 12 Apr 2019 10:10:21 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 67672E2044; Fri, 12 Apr 2019 10:10:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1555078221; bh=8Z8Vj87FBEfEFvc2ArPW5gOjcCO/kH2xG40AK5BqEwg=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=fWRhCWgKVAGegBR62ViLRwvHzfDihvZDJ5r5T1fF0Vjp91ATuEHFixnuvwWsOltdl bMgw/Lgs1Ng9+rMX7o/D34Zl51kYmAwDJ6XPJgwQywAhp1YVqJbQqReZd5g0Vn5ueN i3c+hVhzc0nwH8dRYEJ+lbFNag+aERKo7RFl2xKc= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 12 Apr 2019 10:10:21 -0400 Message-ID: <44819be89ec2e4abb744ba6819c48815.squirrel@mail2.ihtfp.org> In-Reply-To: <875zrj2v6p.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <875zrj2v6p.wl-neal@walfield.org> Date: Fri, 12 Apr 2019 10:10:21 -0400 From: "Derek Atkins" To: "Neal H. Walfield" Cc: "Marcus Brinkmann" , openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:10:37 -0000 Hi, On Fri, April 12, 2019 9:46 am, Neal H. Walfield wrote: > On Fri, 12 Apr 2019 15:36:58 +0200, > Derek Atkins wrote: >> Marcus Brinkmann >> writes: >> [snip] >> In my mind, this sounds like the implementation is broken. If it >> releases AEAD plaintext before the end of the AEAD chunk then it is >> non-conforming and should be considered broken. > > I fully agree with you. > > Given this position, it seems to me that all implementations will > necessarily fail on very large chunks (e.g., 4 exabytes). So, why > even allow them [1]? It seems to me that these permissible options > just create a temptation to create broken implementations. Not necessarily; it could buffer to disk (just like PGP2 did, and even PGP3/5 in certain circumstances). In my mind, buffering to disk is not the same as releasing the plaintext. So it COULD still be conformant, even with 4 exabytes. > Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 12 09:13:54 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D77F1202EA for ; Fri, 12 Apr 2019 09:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 xLYwlUSJEUwG for ; Fri, 12 Apr 2019 09:13:52 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34F7120395 for ; Fri, 12 Apr 2019 09:13:50 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3CGDjjc030080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 12:13:47 -0400 Date: Fri, 12 Apr 2019 11:13:45 -0500 From: Benjamin Kaduk To: Nils Durner , openpgp@ietf.org Message-ID: <20190412161344.GB97741@kduck.mit.edu> References: <875zrnn23u.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875zrnn23u.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] [PATCH] Updated S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:13:53 -0000 On Tue, Apr 09, 2019 at 08:07:17AM +0200, Werner Koch wrote: > On Mon, 8 Apr 2019 22:14, ndurner=40googlemail.com@dmarc.ietf.org said: > > > + > + target='https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-04'> > > This is not a useful reference: > > It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress. With all due respect, that CFRG document is likely to get published well before 4880bis, and it is entirely normal for I-Ds to cite other related I-Ds. Dependency chains and avoidance of referring normatively to "works in progress" is handled as part of the normal operation of the RFC Editor function. So I must disagree with the statement that this is "not a useful reference". -Ben From nobody Fri Apr 12 13:13:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5193E1200EF for ; Fri, 12 Apr 2019 13:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 idUXX5_VkoSW for ; Fri, 12 Apr 2019 13:13:11 -0700 (PDT) Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBF91200EA for ; Fri, 12 Apr 2019 13:13:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id C5C2D7C99A2 for ; Fri, 12 Apr 2019 22:13:06 +0200 (CEST) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXMGByUWXHpN for ; Fri, 12 Apr 2019 22:13:06 +0200 (CEST) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id 8D38A7C999E for ; Fri, 12 Apr 2019 22:13:06 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 717B6C013E for ; Fri, 12 Apr 2019 22:13:05 +0200 (CEST) Date: Fri, 12 Apr 2019 22:13:00 +0200 From: ilf To: openpgp@ietf.org Message-ID: <20190412201300.GJ1226@zeromail.org> Mail-Followup-To: openpgp@ietf.org References: <87v9zt2y2d.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u2SGZJvfJjPItuJA" Content-Disposition: inline In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net> Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:13:14 -0000 --u2SGZJvfJjPItuJA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks a lot, great work! I fixed some minor spelling, grammar and formatting - please excuse the=20 amount of pull requests. One question: > Clients of an updates-only keystore cannot possibly use the keystore=20 > for certificate discovery, because there are no user IDs to match. I wonder about the definition of "certificate discovery" here. Even=20 without UIDs, these keystores could be used for the *retrieval* of=20 specific certificates whose fingerprint (or key ID) is known. This can=20 be the case for signatures (over mails, software or documents) or=20 keylists like in https://tools.ietf.org/html/draft-mccain-keylist Maybe we would want to add "certificate retrieval" at least to the next=20 sentence, which begins: > However, they can use it for certificate update I'm sure we can come up with a good wording - if my ovservation makes=20 sense in the first place. Happy to see this evolving. --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --u2SGZJvfJjPItuJA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAlyw8UwACgkQFT/jmIIc g5R3gxAArVNjJ/ScxnQVMKYR7kdc6awm2QwJ3u3GLaHJtMcKi1oCq13RxWC3F0/9 hK0QMldZn72iosM9YlUvEALnpYMbBb/KgOeJazLLnl4ih0HGbvxSF8PH6w++PJQ4 wYi4PYkl7hqXcXcwbKfs+M066OTq53IyIMO+YOr3DU+C0hWRWAY94AdEbvvu6yUp LJDazByW0VGVMtQvKc7YK6vntKMnbehW4QdIA0PRF1x55ZX+4p6ENfFL85cPDK4U KiGH/w0jsx0ml3JH/5LoXdyPtteBTXHgGQbkTfVXmEuTKFxTX7KRfDT3P/mVBjiC 1mikELhbrWLn0lIQKpZBOvBIxtYHThahWiKFzBvrKB+ss9OrBUhSctxl7lGe3x0v XDctYMyScc/ijUcPENToT0jvyXwk7SEy4ghBRJAcUWz5z9CtbdBC1GpRt770mc4u STy2SZ9ASb3ImausRPesE4xt3+FGekNZsOol0Qf+TNmcOkXjJQvYTc5H5v0jOrf4 yFci0lTjYdsnXPdzRTNOufEpTfMMg1sFh8fKGLIrK8Sooz0esqhy9gzmk075KGX5 8eSbpnzUACVVBach9ZTfvqVUvYOIathip21oaWp+sboqvNZzvD5+BY/LW3PkfdUZ pXssJdGas7URj3lPVq3XMJT9xLExAqGohjMZ/zuwnSsEaiJh+Mw= =7OCc -----END PGP SIGNATURE----- --u2SGZJvfJjPItuJA-- From nobody Mon Apr 15 10:35:07 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BCA1201E6 for ; Mon, 15 Apr 2019 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=PhTSNWoC; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=XcTm+AKC 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 rWLWgT-uY4tH for ; Mon, 15 Apr 2019 10:35:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21878120119 for ; Mon, 15 Apr 2019 10:35:03 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555349701; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=lyw49zmB91jxMyydBOoxJVYjaZB1zkDMyYhYv4twnw8=; b=PhTSNWoCGaWcbkjLInKOMWGYEZOTcJQpGcn9bPhBbJYl4X7OwEfZHKUr H2fmU13DO9AoFn0fW7Nwgi6dlF6xAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555349701; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=lyw49zmB91jxMyydBOoxJVYjaZB1zkDMyYhYv4twnw8=; b=XcTm+AKCjVxv5mgbv3aWRQ6vWuwy3NTVH+hp6TebpZrU2WvsGXclVlPK ciO+nsdIRoGK6AZzIDoAg2/vYL0ASSAnQgrcsN5S5POawm9tG/fCwkUji4 JLEdo3IvTamsDnVk9mwkpVpjGcJmsQFRakyEsC+CgwZLHcTPL6p3uS208S kFgHEAjpf5LDR0LlGjFpKU54VmQUNZKpSC4RjvIL1v+QjW4wAOFbYGw1o7 vZ7TzNXoBMMeKQZk8Kz9SDaeftUf/h9vg2gTffge6rTRIQsIqq8nRy4+nK SRlVfK7q4kjj28ur/apUrahNNy/kFazoqGEwemfGd7ZfQ/MApUO2Lw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 8ACF9F9A0; Mon, 15 Apr 2019 13:35:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id DC55E20268; Mon, 15 Apr 2019 12:59:38 -0400 (EDT) From: Daniel Kahn Gillmor To: ilf , openpgp@ietf.org In-Reply-To: <20190412201300.GJ1226@zeromail.org> References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190412201300.GJ1226@zeromail.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 15 Apr 2019 12:59:38 -0400 Message-ID: <87ef635hmt.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 17:35:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi ilf-- thanks for the review and the comments! On Fri 2019-04-12 22:13:00 +0200, ilf wrote: > I fixed some minor spelling, grammar and formatting - please excuse the=20 > amount of pull requests. I've only seen a few merge requests, and none of them from "ilf" -- if you're into the gitlab-style workflow, please make merge requests over here: https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore Thanks to the folks who have made these requests, though, they're helping make the document better! > I wonder about the definition of "certificate discovery" here. Even=20 > without UIDs, these keystores could be used for the *retrieval* of=20 > specific certificates whose fingerprint (or key ID) is known. This can=20 > be the case for signatures (over mails, software or documents) or=20 > keylists like in https://tools.ietf.org/html/draft-mccain-keylist I agree, but this distinction is what the document already tries to make between certificate *discovery* (lookup by UID or UID substring) and certificate *update* (lookup by primary key fingerprint). If that distinction wasn't clear in the reading, i'd welcome text that improves the clarity. thanks for pointing it out! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLS4egAKCRB2GBllKa5f +CzJAQDyrpRqVLN+ZHGCQ+qYQcn8Y/fmE+rSF9TdkYMOqneTtQD9FAsHZ9VoIR1E Srlmqq5bwdhBmC8quB0uGiuYSy7v8Qc= =c+eT -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 15 10:35:14 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725EA1201E6 for ; Mon, 15 Apr 2019 10:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=lBjbIOky; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=BruMn2dD 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 r55qLB4Te9X3 for ; Mon, 15 Apr 2019 10:35:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A69120131 for ; Mon, 15 Apr 2019 10:35:03 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555349701; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FFbmV6fu5lzzbjUO1Ggb6DXHmz3IlMdU34SMzgH8jZw=; b=lBjbIOkynzMD8rP9liSki8L/Y6PapaEJbkE942geyEcUi/8faIhrawYK r3Cmf+t6pDPjy6O6Z5NxRFcb/w+ACA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555349701; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FFbmV6fu5lzzbjUO1Ggb6DXHmz3IlMdU34SMzgH8jZw=; b=BruMn2dD1cmgtaK2GUsXZUNXmi2MP48y61Qmkc9qnWgiAB66Z6fDhi5c G3Iwwi8Resvpk8QPaI8xWLxEuLoVbDevnzLMMYTh2gJFx906PnxvT0fqdm 5k2R10AF7Slt4Heg8cCz/e3QxOsN4mIh0wa5Hd2J+QIiEl3VU0h2793guW vKjAkhqhmmaM+I/KOWGHrEl8o28iMGNpQNGrkQGD6FPAE72WWpcuoePx8r +Jm3/OdVcDooZ6+Yur4Al4oqtsLh1cipeOl0o+Un6foJB3YpkYquIRdSp/ GqI9X6Jm8pa9rD6wpNKxg8r0OsBx2onN1tvU2k1qicgtI3HZJUM8gQ== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 89AC1F99F; Mon, 15 Apr 2019 13:35:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 053652022A; Mon, 15 Apr 2019 13:16:08 -0400 (EDT) From: Daniel Kahn Gillmor To: Micah Lee , openpgp@ietf.org In-Reply-To: <2885d227-9dc4-c393-d259-fcbfd52a5c71@theintercept.com> References: <87v9zt2y2d.fsf@fifthhorseman.net> <8736mu350z.fsf@fifthhorseman.net> <2885d227-9dc4-c393-d259-fcbfd52a5c71@theintercept.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 15 Apr 2019 13:16:07 -0400 Message-ID: <87a7gr5gvc.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 17:35:08 -0000 --=-=-= Content-Type: text/plain Hi Micah-- Thanks for the thoughtful review and feedback. sorry it's taken me a little while to integrate it. Some thoughts below: On Mon 2019-04-08 10:06:36 -0700, Micah Lee wrote: > I completely agree with the (unfortunate) sentiment that searching by > user ID is not appropriate for key discovery, because user ID flooding > is trivial. However supporting some advanced querying of data in the > keystore, including by user ID, may be useful for non-key discovery > reasons, like to determine if someone else is impersonating your > certificate. I'm not sure i understand this concern, so i want to unpack it a bit. If you've got specific text you'd like me to add after this discussion, please do suggest it! First, a bit of pedantry (sorry!): i think the attack that you're describing is *not* someone impersonating your certificate, but rather someone impersonating your user ID. Is that what you're talking about? I've labeled the abuse-detection action you're describing as "identity monitoring" in draft -03. However, if flooding a given user ID makes certificate discovery impossible, then flooding a given user ID *also* makes "identity monitoring" impossible. So, i think what you're describing is an interesting tension -- but one that presumes some sort of authoritative nature for the keystore in the first place, in which case perhaps the authoritative element is where the appropriate filtering comes in, right? > I also think it's worth adding a mitigation that specifically deals with > this SKS Keyserver bug [1], probably in section 3. There is never a > legitimate reason for a certificate to contain a user ID packet with a > signature that doesn't verify, or with a signature that verifies using > any key other than the certificate's primary key. If such user ID and > signature packet pairs are found, they should always be rejected. I think you're making an argument that all keystores should do cryptographic validation. That has interesting implications, given that there might be use cases where it's useful to distribute certifications issued by keys that the keystore doesn't know about. I welcome textual suggestions that improve this guidance in the current draft! > If an abuse-resistent keystore wishes to provide a UI at all, as opposed > to just an API, then the UI should focus on protecting users from abuse, > and make it clear that certificates don't necessarily belong to the > people or email addresses in the User ID packets, and, if the keystore > doesn't reject malicious user IDs and revocation certificates, make it > clear that all of the information displayed about the key might be > inaccurate as displayed through that UI. But, perhaps a better option is > that the keystores should not provide a UI at all, and instead only > provide an API. I agree, the user interface for a keystore (if any exists) needs to make clear what work it has done to vet the data it offers. I've added a few paragraphs about user interface to the draft, and would welcome clarifications there. I don't want to make the document particularly elaborate in its discussion of user interface, because (a) the IETF isn't a particularly good forum for user interface discussion currently, and (b) many keystores have radically different UI/UX scenarios, and (c) full user interface details seem like they might warrant a distinct discussion that is more implementation-specific anyway. My current approach is to imply that a keystore has an (abstract) three-part API of "certificate submission" (new data proposed for inclusion), "certificate update" (certificate retrieval by fingerprint), and "certificate discovery" (certificate retrieval by user ID or substring match). I touch a bit on other potential API endpoints in the text. If you think i'm missing something, please point it out! > Also, as others have pointed out in this thread, I think that hosting a > keystore using modern distributed blockchain technology is a good idea, > and one of the few genuinely useful uses of blockchain technology. > Storing data in a blockchain is also much more reliable than keyservers > that periodically sync with some set of other keyservers, because every > keystore will have an exact copy of all data, rather than various > keystores having various different states of the data. I've added a section on global append-only logs ("blockchains") to draft -03. > Section 5 is dedicated to "non-append-only mitigations", which wouldn't > work with a blockchain. However I think that all of these mitigations > could be applied at _query time_, which would allow the keystore itself > to be append-only, but still provide users with the same resistance > against abuse as if this data was dropped at write time. This is a useful insight, and i've tried to document it in -03 as well. I welcome text to improve it. > Finally, I found a few typos saying "certiifcate" instead of "certificate". thanks, fixed! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLS8VwAKCRB2GBllKa5f +NFGAP9Y7uWaXKSqRBAULgYsYNH1I90vz59EM+vBpj/PdQG23gD+Kr4rdtgJf1Bd YRRw0NEvh0jFENZX7v8+tuI4YMAafQ8= =zz4q -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 15 10:35:20 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A591203DD for ; Mon, 15 Apr 2019 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=JyKbxIaW; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=sVOTwhK9 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 r9Gfo9LoGyYh for ; Mon, 15 Apr 2019 10:35:05 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056091201B7 for ; Mon, 15 Apr 2019 10:35:04 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555349702; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=HrWt1VQcN0Im2FjVCukEGMyEhM/uOwSs/1NCU22mEZw=; b=JyKbxIaWzTqiACFmAVAD55Zz679CJ6bqFY5GXt03Hd1W5Kr72m+JRdDd 9w/irOMnu0IwO6r0iMsRGbN4iCUWAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555349702; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=HrWt1VQcN0Im2FjVCukEGMyEhM/uOwSs/1NCU22mEZw=; b=sVOTwhK9AlTrVt6dD94Zj9Lf+7ceMUQmUCQAI0nWP3xGXZyoT2VIid8v fiRNO9619jkLWEARq/H7pnxaLepFMp+kNSYgHHI19iGJrA5clcUUc8BD17 ZWCPaUAlm++KjVRz3ikAnvVmJEalTNAlccfaWSKuHtkYYlsC2o/TkpD6N9 gqjZcXSm8zCXM9DNDru0NuEdo5NppeAgOiSk/nUNWtA3JnysdiF9n7x2SJ Gv+uTTB9jUTQAMYhIelw8us8mDoFqRbzdCPQREY9ST8tCnnCoALK7c97UV WRjLD6j9RNGo/OTPKWCiRUzkE9ff8S8npDPJaAw3gOvQwou6Mp8RTg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 9BD81F9A1; Mon, 15 Apr 2019 13:35:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4B30220329; Mon, 15 Apr 2019 12:55:38 -0400 (EDT) From: Daniel Kahn Gillmor To: Phil Pennock , openpgp@ietf.org, SKS development list In-Reply-To: <20190408222619.GA81055@osmium.pennocktech.home.arpa> References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190408222619.GA81055@osmium.pennocktech.home.arpa> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 15 Apr 2019 12:55:38 -0400 Message-ID: <87h8az5hth.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 17:35:13 -0000 Hi Phil-- thanks for the review! On Mon 2019-04-08 18:26:20 -0400, Phil Pennock wrote: > The references section uses my name in the SKS reference. While I > certainly wrote much of (a vast majority of?) the SKS operational > documentation, I did not write SKS and am no longer at all involved in > it. Another person's name should probably go there. In -03, I've put Yaron and Kristian ahead of your name there, but i've left you in place to acknowledge you as the source of much of the documentation. afaict, there is no one actively working on improving SKS at this point :( I appreciate the work you put into SKS in the past, and don't begrudge you stepping away from it. This document is at least in part my attempt to describe why i no longer have faith that SKS ecosystem will persist, and an attempt to offer guidance to whatever patchwork of things ends up supplanting it. If you still object to having your name there in a historical way, or you want it listed differently, please let me know and i'll spin a new draft with your role annotated however you like. > history has shown that this ease-of-abuse barrier-lowering does > directly lead to more abuse, including attempts to just spoil the > entire keyserver system. i've tried to describe your concerns in the "toxic data" section of draft -03. I welcome further discussion on it. all the best, --dkg From nobody Mon Apr 15 10:44:26 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9B41200E6 for ; Mon, 15 Apr 2019 10:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=lpYe7izN; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=bTIbuSNc 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 QoDvUgdGEugD for ; Mon, 15 Apr 2019 10:44:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBFE1200D7 for ; Mon, 15 Apr 2019 10:44:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555350256; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=iP7BBhe60ORDKfPSFUgG4opgfFHrrtZnefcnJzsy1Ms=; b=lpYe7izNFpyE/waYCNK5/IxrRDNew089nvdTaJjxixuZpiw4vMkYdT9D 1RTjD9eJuU90Fwst7AuL7cHueJ6GDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555350256; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=iP7BBhe60ORDKfPSFUgG4opgfFHrrtZnefcnJzsy1Ms=; b=bTIbuSNcZ9TsNyUjEuUbCk5KNahl8UlxtM/pH/amzwiQ/k0nbPVQizkV eFVid5+PFzeTfW43OVjnN+NioSBbksvsqBxuyCfhveI7AXDh6trpJQ/vS7 YK0xRTDxtxFD5wd8/4CBc5VBf284Cn/n3AQnjxCK/rDQ9FVycenMla7ezd 2W3vu+jt2Cdztoa9jrVjdYian55FJIsqVx4Ng02nDrRSsW6P9ARl19f8/e FDFRrK3/r8BF6ExrJpy0Vv98bx/zygXN3VhzQ4+HqEBXrGv5t5GF5VpuSv 08LTPSjn1D+cEhcw2dXQ74Ja/0PYdxRPrUwcLZucTdxR48stU916Iw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 9D277F99D; Mon, 15 Apr 2019 13:44:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 33FC6201BC; Mon, 15 Apr 2019 13:44:09 -0400 (EDT) From: Daniel Kahn Gillmor To: Micah Lee , openpgp@ietf.org, Phil Pennock , SKS development list In-Reply-To: <87h8az5hth.fsf@fifthhorseman.net>, <87a7gr5gvc.fsf@fifthhorseman.net> References: <87v9zt2y2d.fsf@fifthhorseman.net> <8736mu350z.fsf@fifthhorseman.net> <2885d227-9dc4-c393-d259-fcbfd52a5c71@theintercept.com> <87a7gr5gvc.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 15 Apr 2019 13:44:08 -0400 Message-ID: <8736mj5fkn.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 17:44:25 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon 2019-04-15 13:16:07 -0400, Daniel Kahn Gillmor wrote: > I've labeled the abuse-detection action you're describing as "identity > monitoring" in draft -03. [=E2=80=A6] > This is a useful insight, and i've tried to document it in -03 as well. > I welcome text to improve it. On Mon 2019-04-15 12:55:38 -0400, Daniel Kahn Gillmor wrote: > In -03, I've put Yaron and Kristian ahead of your name there, [=E2=80=A6] > i've tried to describe your concerns in the "toxic data" section of > draft -03. I welcome further discussion on it. Sigh. Please excuse the typos, these should all read -02, not -03. draft -03 does not exist yet. I've just published draft -02, which is available at the usual places: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-02 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore substantive changes between -01 and -02: * distinguish different forms of flooding attack * distinguish toxic data as distinct from flooding * retrieval-time mitigations * user ID redaction * references to related work (CT, keylist, CONIKS, key transparency, ledgers/"blockchain", etc) * more details about UI/UX The full text of the Markdown source for -02 is attached. I welcome feedback and edits! --dkg --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=draft-dkg-openpgp-abuse-resistant-keystore.md Content-Transfer-Encoding: quoted-printable =2D-- title: Abuse-Resistant OpenPGP Keystores docname: draft-dkg-openpgp-abuse-resistant-keystore-02 date: 2019-04-15 category: info ipr: trust200902 area: int workgroup: openpgp keyword: Internet-Draft stand_alone: yes pi: [toc, sortrefs, symrefs] author: - ins: D. K. Gillmor name: Daniel Kahn Gillmor org: American Civil Liberties Union street: 125 Broad St. city: New York, NY code: 10004 country: USA abbrev: ACLU email: dkg@fifthhorseman.net informative: RFC5322: RFC6962: RFC7929: I-D.shaw-openpgp-hkp: I-D.koch-openpgp-webkey-service: I-D.mccain-keylist: SKS: target: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home title: SKS Keyserver Documentation author: - name: Yaron Minsky ins: Y. Minsky org: SKS development team - name: Kristian Fiskerstrand ins: K. Fiskerstrand org: sks-keyservers.net pool operator - name: Phil Pennock ins: P. Pennock date: 2018-03-25 GnuPG: target: https://www.gnupg.org/documentation/manuals/gnupg.pdf title: Using the GNU Privacy Guard author: name: Werner Koch ins: W. Koch org: GnuPG development team date: 2019-04-04 MAILVELOPE-KEYSERVER: target: https://github.com/mailvelope/keyserver/ title: Mailvelope Keyserver author:=20 name: Thomas Obernd=C3=B6rfer ins: T. Obernd=C3=B6rfer DEBIAN-KEYRING: target: https://keyring.debian.org/ title: Debian Keyring author: name: Jonathan McDowell ins: J. McDowell org: Debian TOR: target: https://www.torproject.org/ title: The Tor Project PARCIMONIE: target: https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ title: Parcimonie author: name: Intrigeri PGP-GLOBAL-DIRECTORY: target: https://keyserver.pgp.com/vkd/VKDVerificationPGPCom.html title: PGP Global Directory Key Verification Policy date: 2011 author: org: Symantec Corporation MONKEYSPHERE: target: https://web.monkeysphere.info/ title: Monkeysphere author: - name: Daniel Kahn Gillmor ins: D. K. Gillmor - name: Jameson Rollins ins: J. Rollins KEY-TRANSPARENCY: target: https://keytransparency.org/ title: Key Transparency, a transparent and secure way to look up public= keys author: - name: Gary Belvin ins: G. Belvin org: Google - name: Ryan Hurst ins: R. Hurst org: Google CONIKS: target: https://coniks.cs.princeton.edu/ title: CONIKS Key Management System author: - name: Edward Felten ins: E. Felten org: Princeton University - name: Michael Freedman ins: M. Freedman org: Princeton University - name: Marcela Melara ins: M. Melara org: Princeton University - name: Aaron Blankstein ins: A. Blankstein org: Princeton University - name: Joseph Bonneau ins: J. Bonneau org: Stanford University/Electronic Frontier Foundation BITCOIN: target: https://bitcoin.org/ title: Bitcoin normative: RFC2119: RFC4880: RFC8174: I-D.ietf-openpgp-rfc4880bis: =2D-- abstract OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores. Unfortunately, since many keystores permit any third-party to add a certification with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. Furthermore, keystores that are searched by user ID can be made unusable for specific names or addresses by public submission of bogus data. And finally, keystores open to public submission can also face simple resource exhaustion from flooding with bogus submissions, or legal or other risks from uploads of toxic data. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various attacks. =2D-- middle Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements Language =2D-------------------- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here. Terminology =2D---------- * "OpenPGP certificate" (or just "certificate") is used interchangeably with {{RFC4880}}'s "Transferable Public Key". The term "certificate" refers unambiguously to the entire composite object, unlike "key", which might also be used to refer to a primary key or subkey. =20=20=20 * An "identity certification" (or just "certification") is an {{RFC4880}} signature packet that covers OpenPGP identity information -- that is, any signature packet of type 0x10, 0x11, 0x12, or 0x13. Certifications are said to (try to) "bind" a primary key to a User ID. =20=20=20 * The primary key that makes the certification is known as the "issuer". The primary key over which the certification is made is known as the "subject". * A "first-party certification" is issued by the primary key of a certificate, and binds itself to a user ID in the certificate. That is, the issuer is the same as the subject. This is sometimes referred to as a "self-sig". =20=20=20 * A "third-party certification" is a made over a primary key and user ID by some other certification-capable primary key. That is, the issuer is different than the subject. (The elusive "second-party" is presumed to be the verifier who is trying to interpret the certificate) * A "keystore" is any collection of OpenPGP certificates. Keystores typically receive mergeable updates over the course of their lifetime which might add to the set of OpenPGP certificates they hold, or update the certificates. * "Certificate discovery" is the process whereby a user retrieves an OpenPGP certificate based on user ID (see {{user-id-conventions}}). A user attempting to discover a certificate from a keystore will search for a substring of the known user IDs, most typically an e-mail address if the user ID is an {{RFC5322}} name-addr or addr-spec. Some certificate discovery mechanisms look for an exact match on the known user IDs. {{I-D.koch-openpgp-webkey-service}} and {{I-D.shaw-openpgp-hkp}} both offer certificate discovery mechanisms. * "Certificate validation" is the process whereby a user decides whether a given user ID in an OpenPGP certificate is acceptable. For example, if the certificate has a user ID of `Alice ` and the user wants to send an e-mail to `alice@example.org`, the mail user agent might want to ensure that the certificate is valid for this e-mail address before encrypting to it. This process can take different forms, and can consider many different factors, some of which are not directly contained in the certificate itself. For example, certificate validation might consider whether the certificate was fetched via DANE ({{RFC7929}}) or WKD ({{I-D.koch-openpgp-webkey-service}}); or whether it has seen e-mails from that address signed by the certificate in the past; or how long it has known about certificate. * "Certificate update" is the process whereby a user fetches new information about a certificate, potentially merging those OpnePGP packets to change the status of the certificate. Updates might include adding or revoking user IDs or subkeys, updating expiration dates, or even revoking the entire certificate by revoking the primary key directly. A user attempting to update a certificate typically queries a keystore based on the certificate's fingerprint. * A "keyserver" is a particular kind of keystore, typically means of publicly distributing OpenPGP certificates or updates to them. Examples of keyserver software include {{SKS}} and {{MAILVELOPE-KEYSERVER}}. One common HTTP interface for keyservers is {{I-D.shaw-openpgp-hkp}}. =20=20=20 * A "synchronizing keyserver" is a keyserver which gossips with other peers, and typically acts as an append-only log. Such a keyserver is typically useful for certificate discovery, certificate updates, and revocation information. They are typically *not* useful for certificate validation, since they make no assertions about whether the identities in the certificates they server are accurate. As of the writing of this document, {{SKS}} is the canonical synchronizing keyserver implementation, though other implementations exist. =20=20=20 * An "e-mail validating keyserver" is a keyserver which attempts to verify the identity in an OpenPGP certificate's user ID by confirming access to the e-mail account, and possibly by confirming access to the secret key. Some implementations permit removal of a certificate by anyone who can prove access to the e-mail address in question. They are useful for certificate discovery based on e-mail address and certificate validation (by users who trust the operator), but some may not be useful for certificate update or revocation, since a certificate could be simply replaced by an adversary who also has access to the e-mail address in question. {{MAILVELOPE-KEYSERVER}} is an example of such a keyserver. * "Cryptographic validity" refers to mathematical evidence that a signature came from the secret key associated with the public key it claims to come from. Note that a certification may be cryptographically valid without the signed data being true (for example, a given certificate with the user ID `Alice ` might not belong to the person who controls the e-mail address `alice@example.org` even though the self-sig is cryptographically valid). In particular, cryptographic validity for user ID in a certificate is typically insufficient evidence for certificate validation. Also note that knowledge of the public key of the issuer is necessary to determine whether any given signature is cryptographically valid. Some keyservers perform cryptographic validation in some contexts. Other keyservers (like {{SKS}}) perform no cryptographic validation whatsoever. * OpenPGP revocations can have "Reason for Revocation" (see {{RFC4880}}), which can be either "soft" or "hard". The set of "soft" reasons is: "Key is superseded" and "Key is retired and no longer used". All other reasons (and revocations that do not state a reason) are "hard" revocations. See {{revocations}} for more detail. Problem Statement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OpenPGP keystores that handle submissions from the public are subject to a range of attacks by malicious submitters. This section describes four distinct attacks that public keystores should consider. The rest of the document describes some mitigations that can be used by keystores that are concerned about these problems but want to continue to offer some level of service for certificate discovery, certificate update, or certificate validation. Certificate Flooding {#certificate-flooding} =2D------------------- Many public keystores (including both the {{SKS}} keyserver network and {{MAILVELOPE-KEYSERVER}}) allow anyone to attach arbitrary data (in the form of third-party certifications) to any certificate, bloating that certificate to the point of being impossible to effectively retrieve. For example, some OpenPGP implementations simply refuse to process certificates larger than a certain size. This kind of Denial-of-Service attack makes it possible to make someone else's certificate unretrievable from the keystore, preventing certificate discovery. It also makes it possible to swamp a certificate that has been revoked, preventing certificate update, potentially leaving the client of the keystore with the compromised certificate in an unrevoked state locally. Additionally, even without malice, OpenPGP certificates can potentially grow without bound. User ID Flooding {#user-id-flooding} =2D--------------- Public keystores that are used for certificate discovery may also be vulnerable to attacks that flood the space of known user IDs. In particular, if the keystore accepts arbitrary certificates from the public and does no verification of the user IDs, then any client searching for a given user ID may need to review and process an effectively unbounded set of maliciously-submitted certificates to find the non-malicious certificates they are looking for. For example, if an attacker knows that a given system consults a keystore looking for certificates which match the e-mail address `alice@example.org`, the attacker may upload hundreds or thousands of certificates containing user IDs that match that address. Even if those certificates would not be accepted by a client (e.g., because they were not certified by a known-good authority), the client typically still has to wade through all of them in order to find the non-malicious certificates. If the keystore does not offer a discovery interface at all (that is, if clients cannot search it by user ID), then user ID flooding is of less consequence. Keystore Flooding {#keystore-flooding} =2D---------------- A public keystore that accepts arbitrary OpenPGP material and is append-only is at risk of being overwhelmed by sheer quantity of malicious uploaded packets. This is a risk even if the user ID space is not being deliberately flooded, and if individual certificates are protected from flooding by any of the mechanisms described later in this document. The keystore itself can become difficult to operate if the total quantity of data is too large, and if it is a synchronizing keyserver, then the quantities of data may impose unsustainable bandwidth costs on the operator as well. Effectively mitigating against keystore flooding requires either abandoning the append-only property that some keystores prefer, or imposing very strict controls on initial ingestion. Toxic Data {#toxic-data} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Like any large public dataset, it's possible that a keystore ends up hosting some content that is legally actionable in some jurisdictions, including libel, child pornography, material under copyright or other "intellectual property" controls, blasphemy, hate speech, etc. A public keystore that accepts and redistributes arbitrary content may face risk due to uploads of toxic data. Simple Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D These steps can be taken by any keystore that wants to avoid obviously malicious abuse. They can be implemented on receipt of any new packet, and are based strictly on the structure of the packet itself. Decline Large Packets =2D-------------------- While {{RFC4880}} permits OpenPGP packet sizes of arbitrary length, OpenPGP certificates rarely need to be so large. An abuse-resistant keystore SHOULD reject any OpenPGP packet larger than 8383 octets. (This cutoff is chosen because it guarantees that the packet size can be represented as a one- or two-octet {{RFC4880}} "New Format Packet Length", but it could be reduced further) This may cause problems for user attribute packets that contain large images, but it's not clear that these images are concretely useful in any context. Some keystores MAY extend this limit for user attribute packets specifically, but SHOULD NOT allow even user attributes packets larger than 65536 octets. Enforce Strict User IDs =2D---------------------- {{RFC4880}} indicates that User IDs are expected to be UTF-8 strings. An abuse-resistant keystore MUST reject any user ID that is not valid UTF-8. Some abuse-resistant keystores MAY only accept User IDs that meet even stricter conventions, such as an {{RFC5322}} name-addr or addr-spec, or a URL like "ssh://host.example.org". As simple text strings, User IDs don't need to be nearly as long as any other packets. An abuse-resistant keystore SHOULD reject any user ID packet larger than 1024 octets. Scoped User IDs {#scoped-user-ids} =2D-------------- Some abuse-resistant keystores may restrict themselves to publishing only certificates with User IDs that match a specific pattern. For example, {{RFC7929}} encourages publication in the DNS of only certificates whose user IDs refer to e-mail addresses within the DNS zone. {{I-D.koch-openpgp-webkey-service}} similarly aims to restrict publication to certificates relevant to the specific e-mail domain. Strip or Standardize Unhashed Subpackets =2D--------------------------------------- {{RFC4880}} signature packets contain an "unhashed" block of subpackets. These subpackets are not covered by any cryptographic signature, so they are ripe for abuse. An abuse-resistant keysetore SHOULD strip out all unhashed subpackets. Note that some certifications only identify the issuer of the certification by an unhashed Issuer ID subpacket. If a certification's hashed subpacket section has no Issuer ID or Issuer Fingerprint (see {{I-D.ietf-openpgp-rfc4880bis}}) subpacket, then an abuse-resistant keystore that has cryptographically validated the certification SHOULD make the unhashed subpackets contain only a single subpacket. That subpacket should be of type Issuer Fingerprint, and should contain the fingerprint of the issuer. A special exception may be made for unhashed subpackets in a third-party certification that contain attestations from the certificate's primary key as described in {{fpatpc}}. Decline User Attributes =2D---------------------- Due to size concerns, some abuse-resistant keystores MAY choose to ignore user attribute packets entirely, as well as any certifications that cover them. Decline Non-exportable Certifications =2D------------------------------------ An abuse-resistant keystore MUST NOT accept any certification that has the "Exportable Certification" subpacket present and set to 0. While most keystore clients will not upload these "local" certifications anyway, a reasonable public keystore that wants to minimize data has no business storing or distributing these certifications. Decline Data From the Future =2D--------------------------- Many OpenPGP packets have time-of-creation timestamps in them. An abuse-resistant keystore with a functional real-time clock MAY decide to only accept packets whose time-of-creation is in the past. Note that some OpenPGP implementations may pre-generate OpenPGP material intended for use only in some future window (e.g. "Here is the certificate we plan to use to sign our software next year; do not accept signatures from it until then."), and may use modified time-of-creation timestamps to try to achieve that purpose. This material would not be distributable ahead of time by an abuse-resistant keystore that adopts this mitigation. Accept Only Profiled Certifications =2D---------------------------------- An aggressively abuse-resistant keystore MAY decide to only accept certifications that meet a specific profile. For example, it MAY reject certifications with unknown subpacket types, unknown notations, or certain combinations of subpackets. This can help to minimize the amount of room for garbage data uploads. Any abuse-resistant keystore that adopts such a strict posture should clearly document what its expected certificate profile is, and should have a plan for how to extend the profile if new types of certification appear that it wants to be able to distribute. Note that if the profile is ever restricted (rather than extended), and the restriction is applied to the material already present, such a keystore is no longer append-only (please see {{non-append-only}}). Accept Only Certificates Issued by Designated Authorities {#authorities} =2D-------------------------------------------------------- An abuse-resistant keystore capable of cryptographic validation MAY retain a list of designated authorities, typically in the form of a set of known public keys. Upon receipt of a new OpenPGP certificate, the keystore can decide whether to accept or decline each user ID of the certificate based whether that user ID has a certification that was issued by one or more of the designated authorities. If no user IDs are certified by designated authority, such a keystore SHOULD decline the certificate and its primary key entirely. Such a keystore SHOULD decline to retain or propagate all certifications associated with each accepted user ID except for first-party certifications and certifications by the designated authorities. The operator of such a keystore SHOULD have a clear policy about its set of designated authorities. Given the ambiguities about expiration and revocation, such a keyserver SHOULD ignore expiration and revocation of authority certifications, and simply accept and retain as long as the cryptographic signature is valid. Note that if any key is removed from the set of designated authorities, and that change is applied to the existing keystore, such a keystore may no longer be append-only (please see {{non-append-only}}). Decline Packets by Blocklist {#blocklist} =2D--------------------------- The maintainer of the keystore may keep a specific list of "known-bad" material, and decline to accept or redistribute items matching that blocklist. The material so identified could be anything, but most usefully, specific public keys or User IDs could be blocked. Note that if a blocklist grows to include an element already present in the keystore, it will no longer be append-only (please see {{non-append-only}}). Some keystores may choose to apply a blocklist only at retrieval time and not apply it at ingestion time. This allows the keystore to be append-only, and permits synchronization between keystores that don't share a blocklist, and somewhat reduces the attacker's incentive for flooding the keystore (see {{retrieval-time-mitigations}} for more discussion). Note that development and maintenance of a blocklist is not without its own potentials for abuse. For one thing, the blocklist may itself grow without bound. Additionally, a blocklist may be socially or politically contentious as it may describe data that is toxic ({{toxic-data}}) in one community or jurisdiction but not another. There needs to be a clear policy about how it is managed, whether by delegation to specific decision-makers, or explicit tests. Furthermore, the existence of even a well-intentioned blocklist may be an "attractive nuisance," drawing the interest of would-be censors or other attacker interested in controlling the ecosystem reliant on the keystore in question. Retrieval-time Mitigations {#retrieval-time-mitigations} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Most of the abuse mitigations described in this document are described as being applied at certificate ingestion time. It's also possible to apply the same mitigations when a certificate is retrieved from the keystore (that is, during certificate update or certificate discovery). Applying an abuse mitigation at retrieval time may help a client defend against a user ID flooding ({{user-id-flooding}}) or certificate flooding ({{certificate-flooding}}) attack. However, only mitigations applied at ingestion time are able to mitigate keystore flooding attacks ({{keystore-flooding}}). Some mitigations (like the non-append-only mitigations described in {{non-append-only}}) may be applied as filters at retrieval time, while still allowing access to the (potentially much larger) unfiltered dataset associated given certificate or user ID via a distinct interface. The rest of this section documents a specific mitigation that is applied only at retrieval time. Redacting User IDs {#user-id-redacting} =2D----------------- Some abuse-resistant keystores may accept and store user IDs but decline to redistribute some or all of them, while still distributing the certifications that cover those redacted user IDs. This draft refers to such a keystore as a "user ID redacting" keystore. The certificates distributed by such a keystore are technically invalid {{RFC4880}} "transferable public keys", because they lack a user ID packet, and the distributed certifications cannot be cryptographically validated independently. However, an OpenPGP implementation that already knows the user IDs associated with a given primary key will be capable of associating each certification with the correct user ID by trial signature verification. ### Certificate Update with Redacted User IDs A user ID redacting keystore is useful for certificate update by a client that already knows the user ID it expects to see associated with the certificate. For example, a client that knows a given certificate currently has two specific user IDs could access the keystore to learn that one of the user IDs has been revoked, without any other client learning the user IDs directly from the keystore. ### Certificate Discovery with Redacted User IDs It's possible (though non-intuitive) to use a user ID redacting keystore for certificate discovery. Since the keystore retains (but does not distribute) the user IDs, they can be used to select certificates in response to a search. The OpenPGP certificates sent back in response to the search will not contain the user IDs, but a client that knows the full user ID they are searching for will be able to verify the returned certifications. Certificate discovery from a user ID redacting keystore works better for certificate discovery by exact user ID match than it does for substring match, because a client that discovers a substring match may not be able to reconstruct the redacted user ID. However, without some additional restrictions on which certifications are redistributed (whether the user ID is redacted or not), certificate discovery can be flooded (see {{uploads-vs-discovery}}). ### Hinting Redacted User IDs {#uidhash} To ensure that the distributed certificate is at least structurally a valid {{RFC4880}} transferable public key, a user ID redacting keystore MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose contents are a zero-octet string) in place of the omitted user ID. This two-octet replacement user ID packet ("\xb4\x00") is called the "unstated user ID". To facilitate clients that match certifications with specific user IDs, a user ID redacting keystore MAY insert a non-hashed notation subpacket into the certification. The notation will have a name of "uidhash", with 0x80 ("human-readable") flag unset. The value of such a notation MUST be 32 octets long, and contains the SHA-256 cryptographic digest of the UTF-8 string of the redacted user ID. A certificate update client which receives such a certification after the "unstated user ID" SHOULD compute the SHA-256 digest of all user IDs it knows about on the certificate, and compare the result with the contents of the "uidhash" notation to decide which user ID to try to validate the certification against. ### User ID Recovery by Client Brute Force=20 User ID redaction is at best an imperfect process. Even if a keystore redacts a User ID, if it ships a certification over that user ID, an interested client can guess user IDs until it finds one that causes the signature to verify. This is even easier when the space of legitimate user IDs is relatively small, such as the set of commonly-used hostnames Contextual Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some mitigations make the acceptance or rejection of packets contingent on data that is already in the keystore or the keystore's developing knowledge about the world. This means that, depending on the order that the keystore encounters the various material, or how it discovers the material, the final set of material retained and distributed by the keystore might be different. While this isn't necessarily bad, it may be a surprising property for some users of keystores. Accept Only Cryptographically-verifiable Certifications =2D------------------------------------------------------ An abuse-resistant keystore that is capable of doing cryptographic validation MAY decide to reject certifications that it cannot cryptographically validate. This may mean that the keystore rejects some packets while it is unaware of the public key of the issuer of the packet. Accept Only Certificates Issued by Known Certificates =2D---------------------------------------------------- This is an extension of {{authorities}}, but where the set of authorities is just the set of certificates already known to the keystore. An abuse-resistant keystore that adopts this strategy is effectively only crawling the reachable graph of OpenPGP certificates from some starting core. A keystore adopting the mitigation SHOULD have a clear documentation of the core of initial certificates it starts with, as this is effectively a policy decision. This mitigation measure may fail due to a compromise of any secret key that is associated with a primary key of a certificate already present in the keystore. Such a compromise permits an attacker to flood the rest of the network. In the event that such a compromised key is identified, it might be placed on a blocklist (see {{blocklist}}). In particular, if a public key is added to a blocklist for a keystore implementing this mitigation, and it is removed from the keystore, then all certificates that were only "reachable" from the blocklisted certificate should also be simultaneously removed. Rate-limit Submissions by IP Address =2D----------------------------------- Some OpenPGP keystores accept material from the general public over the Internet. If an abuse-resistant keystore observes a flood of material submitted to the keystore from a given Internet address, it MAY choose to throttle submissions from that address. When receiving submissions over IPv6, such a keystore MAY choose to throttle entire nearby subnets, as a malicious IPv6 host is more likely to have multiple addresses. This requires that the keystore maintain state about recent submissions over time and address. It may also be problematic for users who appear to share an IP address from the vantage of the keystore, including those behind a NAT, using a VPN, or accessing the keystore via Tor. Accept Certificates Based on Exterior Process {#exterior-process} =2D-------------------------------------------- Some public keystores resist abuse by explicitly filtering OpenPGP material based on a set of external processes. For example, {{DEBIAN-KEYRING}} adjudicates the contents of the "Debian keyring" keystore based on organizational procedure and manual inspection. Accept Certificates by E-mail Validation =2D--------------------------------------- Some keystores resist abuse by declining any certificate until the user IDs have been verified by e-mail. When these "e-mail validating" keystores review a new certificate that has a user ID with an e-mail address in it, they send an e-mail to the associated address with a confirmation mechanism (e.g., a high-entropy HTTPS URL link) in it. In some cases, the e-mail itself is encrypted to an encryption-capable key found in the proposed certificate. If the keyholder triggers the confirmation mechanism, then the keystore accepts the certificate. Some e-mail validating keystores MAY choose to distribute certifications over all user IDs for any given certificate, but will redact (see {{user-id-redacting}}) those user IDs that have not been e-mail validated. {{PGP-GLOBAL-DIRECTORY}} describes some concerns held by a keystore operator using this approach. {{MAILVELOPE-KEYSERVER}} is another example. Non-append-only mitigations {#non-append-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The following mitigations may cause some previously-retained packets to be dropped after the keystore receives new information, or as time passes. This is entirely reasonable for some keystores, but it may be surprising for any keystore that expects to be append-only (for example, some keyserver synchronization techniques may expect this property to hold). Furthermore, keystores that drop old data (e.g., superseded certifications) may make it difficult or impossible for their users to reason about the validity of signatures that were made in the past. See {{in-the-past}} for more considerations. Note also that many of these mitigations depend on cryptographic validation, so they're typically contextual as well. A keystore that needs to be append-only, or which cannot perform cryptographic validation MAY omit these mitigations. Alternately, a keystore may omit these mitigations at certificate ingestion time, but apply these mitigations at retrieval time (during certificate update or discovery), and offer a more verbose (non-mitigated) interface for auditors, as described in {{retrieval-time-mitigations}}. Note that {{GnuPG}} anticipates some of these suggestions with its "clean" subcommand, which is documented as: Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring. Drop Superseded Signatures {#drop-superseded} =2D------------------------- An abuse-resistant keystore SHOULD drop all signature packets that are explicitly superseded. For example, there's no reason to retain or distribute a self-sig by key K over User ID U from 2017 if the keystore have a cryptographically-valid self-sig over from 2019. Note that this covers both certifications and signatures over subkeys, as both of these kinds of signature packets may be superseded. Getting this right requires a nuanced understanding of subtleties in {{RFC4880}} related to timing and revocation. Drop Expired Signatures {#drop-expired} =2D---------------------- If a signature packet is known to only be valid in the past, there is no reason to distribute it further. An abuse-resistant keystore with access to a functionally real-time clock SHOULD drop all certifications and subkey signature packets with an expiration date in the past. Note that this assumes that the keystore and its clients all have roughly-synchronized clocks. If that is not the case, then there will be many other problems! Drop Dangling User IDs, User Attributes, and Subkeys =2D--------------------------------------------------- If enough signature packets are dropped, it's possible that some of the things that those signature packets cover are no longer valid. An abuse-resistant keystore which has dropped all certifications that cover a User ID SHOULD also drop the User ID packet. Note that a User ID that becomes invalid due to revocation MUST NOT be dropped, because the User ID's revocation signature itself remains valid, and needs to be distributed. A primary key with no User IDs and no subkeys and no revocations MAY itself also be removed from distribution, though note that the removal of a primary key may make it impossible to cryptographically validate other certifications held by the keystore. Drop All Other Elements of a Directly-Revoked Certificate {#only-revocation} =2D-------------------------------------------------------- If the primary key of a certificate is revoked via a direct key signature, an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation. Note that the direct key revocation signature MUST NOT be dropped. In the event that an abuse-resistant keystore is flooded with direct key revocation signatures, it should retain the hardest, earliest revocation (see also {{revocations}}). In particular, if any of the direct key revocation signatures is a "hard" revocation, the abuse-resistant keystore SHOULD retain the earliest such revocation signature (by signature creation date). Otherwise, the abuse-resistant keystore SHOULD retain the earliest "soft" direct key revocation signature it has seen. If either of the above date comparisons results in a tie between two revocation signatures of the same "hardness", an abuse-resistant keystore SHOULD retain the signature that sorts earliest based on a binary string comparison of the direct key revocation signature packet itself. Implicit Expiration Date =2D----------------------- In combination with some of the dropping mitigations above, a particularly aggressive abuse-resistant keystore MAY choose an implicit expiration date for all signature packets. For example, a signature packet that claims no expiration could be treated by the keystore as expiring 3 years after issuance. This would permit the keystore to eject old packets on a rolling basis. FIXME: it's not clear what should happen with signature packets marked with an explicit expiration that is longer than implicit maximum. Should it be capped to the implicit date, or accepted? Warning: This idea is pretty radical, and it's not clear what it would do to an ecosystem that depends on such a keystore. It probably needs more thinking. Updates-only Keystores {#updates-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In addition to the mitigations above, some keystores may resist abuse by declining to accept any user IDs or certifications whatsoever. Such a keystore MUST be capable of cryptographic validation. It accepts primary key packets, cryptographically-valid direct-key signatures from a primary key over itself, subkeys and their cryptographically-validated binding signatures (and cross signatures, where necessary). Clients of an updates-only keystore cannot possibly use the keystore for certificate discovery, because there are no user IDs to match. However, they can use it for certificate update, as it's possible to ship revocations (which are direct key signatures), new subkeys, updates to subkey expiration, subkey revocation, and direct key signature-based certificate expiration updates. Note that many popular OpenPGP implementations do not implement direct primary key expiration mechanisms, relying instead on user ID expirations. These user ID expiration dates or other metadata associated with a self-certification will not be distributed by an updates-only keystore. Certificates shipped by an updates-only keystore are technically invalid {{RFC4880}} "transferable public keys," because they lack a user ID packet. However many OpenPGP implementations will accept such a certificate if they already know of a user ID for the certificate, because the composite certificate resulting from a merge will be a standards-compliant transferable public key. First-party-only Keystores {#first-party-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Slightly more permissive than the updates-only keystore described in {{updates-only}} is a keystore that also permits user IDs and their self-sigs. A first-party-only keystore only accepts and distributes cryptographically-valid first-party certifications. Given a primary key that the keystore understands, it will only attach user IDs that have a valid self-sig, and will only accept and re-distribute subkeys that are also cryptographically valid (including requiring cross-sigs for signing-capable subkeys as recommended in {{RFC4880}}). This effectively solves the problem of abusive bloating attacks on any certificate, because the only party who can make a certificate overly large is the holder of the secret corresponding to the primary key itself. Note that a first-party-only keystore is still problematic for those people who rely on the keystore for discovery of third-party certifications. {{fpatpc}} attempts to address this lack. First-party-only Without User IDs =2D-------------------------------- It is possible to operate an updates-only keystore that also declines to redistribute user IDs ({{user-id-redacting}}). This defends against concerns about publishing identifiable information, while enabling full certificate update for those keystore clients that already know the associated user IDs for a given certificate. First-party-attested Third-party Certifications {#fpatpc} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We can augment a first-party-only keystore to allow it to distribute third-party certifications as long as the first-party has signed off on the specific third-party certification. An abuse-resistant keystore SHOULD only accept a third-party certification if it meets the following criteria: * The third-party certification MUST be cryptographically valid. Note that this means that the keystore needs to know the primary key for the issuer of the third-party certification. * The third-party certification MUST have an unhashed subpacket of type Embedded Signature, the contents of which we'll call the "attestation". This attestation is from the certificate's primary key over the third-party certification itself, as detailed in the steps below: * The attestation MUST be an OpenPGP signature packet of type 0x50 (Third-Party Confirmation signature) =20=20=20 * The attestation MUST contain a hashed "Issuer Fingerprint" subpacket with the fingerprint of the primary key of the certificate in question. =20=20=20 * The attestation MUST NOT be marked as non-exportable. =20 * The attestation MUST contain a hashed Notation subpacket with the name "ksok", and an empty (0-octet) value. * The attestation MUST contain a hashed "Signature Target" subpacket with "public-key algorithm" that matches the public-key algorithm of the third-party certification. =20=20=20 * The attestation's hashed "Signature Target" subpacket MUST use a reasonably strong hash algorithm (as of this writing, any {{RFC4880}} hash algorithm except MD5, SHA1, or RIPEMD160), and MUST have a hash value equal to the hash over the third-party certification with all unhashed subpackets removed. =20=20=20 * The attestation MUST be cryptographically valid, verifiable by the primary key of the certificate in question. =20=20=20 =20=20=20 What this means is that a third-party certificate will only be accepted/distributed by the keystore if: * the keystore knows about both the first- and third-parties. =20 * the third-party has made the identity assertion =20 * the first-party has confirmed that they're OK with the third-party certification being distributed by any keystore. =20=20=20 FIXME: it's not clear whether the "ksok" notification is necessary -- it's in place to avoid some accidental confusion with any other use of the Third-Party Confirmation signature packet type, but the author does not know of any such use that might collide. Key Server Preferences "No-modify" =2D--------------------------------- {{RFC4880}} defines "Key Server Preferences" with a "No-modify" bit. That bit has never been respected by any keyserver implementation that the author is aware of. An abuse-resistant keystore following {{fpatpc}} effectively treats that bit as always set, whether it is present in the certificate or not. Client Interactions {#client-interactions} =2D------------------ Creating such an attestation requires multiple steps by different parties, each of which is blocked by all prior steps: * The first-party creates the certificate, and transfers it to the third party. =20 * The third-party certifies it, and transfers their certification back to the first party. =20 * The first party attests to the third party's certification. =20 * Finally, the first party then transfers the compound certificate to the keystore. The complexity and length of such a sequence may represent a usability obstacle to a user who needs a third-party-certified OpenPGP certificate. No current OpenPGP client can easily create the attestions described in this section. More implementation work needs to be done to make it easy (and understandable) for a user to perform this kind of attestation. Side Effects and Ecosystem Impacts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Designated Revoker {#designated-revoker} =2D----------------- A first-party-only keystore as described in {{first-party-only}} might decline to distribute revocations made by the designated revoker. This is a risk to certificate-holder who depend on this mechanism, because an important revocation might be missed by clients depending on the keystore. FIXME: adjust this document to point out where revocations from a designated revoker SHOULD be propagated, maybe even in first-party-only keystores. Certification-capable Subkeys =2D---------------------------- Much of this discussion assumes that primary keys are the only certification-capable keys in the OpenPGP ecosystem. Some proposals have been put forward that assume that subkeys can be marked as certification-capable. If subkeys are certification-capable, then much of the reasoning in this draft becomes much more complex, as subkeys themselves can be revoked by their primary key without invalidating the key material itself. That is, a subkey can be both valid (in one context) and invalid (in another context) at the same time. So questions about what data can be dropped (e.g. in {{non-append-only}}) are much fuzzier, and the underlying assumptions may need to be reviewed. If some OpenPGP implementations accept certification-capable subkeys, but an abuse-resistant keystore does not accept certifications from subkeys in general, then interactions between that keystore and those implementations may be surprising. Assessing Certificates in the Past {#in-the-past} =2D--------------------------------- Online protocols like TLS perform signature and certificate evaluation based entirely on the present time. If a certificate that signs a TLS handshake message is invalid now, it doesn't matter whether it was valid a week ago, because the present TLS session is the context of the evaluation. But OpenPGP signatures are often evaluated at some temporal remove from when the signature was made. For example, software packages are signed at release time, but those signatures are validated at download time. Further complicating matters, the composable nature of an OpenPGP certificate means that the certificate associated with any particular signing key (primary key or subkey) can transform over time. So when evaluating a signature that appears to have been made by a given certificate, it may be better to try to evaluate the certificate at the time the signature was made, rather than the present time. ### Point-in-time Certificate Evaluation {#point-in-time} When evaluating a certificate at a time T in the past (for example, when trying to validate a data signature by that certificate that was created at time T), one approach is to discard all packets from the certificate if the packet has a creation time later than T. Then evaluate the resulting certificate from the remaining packets in the context of time T. However, any such evaluation MUST NOT ignore "hard" OpenPGP key revocations, regardless of their creation date. (see {{revocations}}). ### Signature Verification and Non-append-only Keystores If a non-append-only keystore ({{non-append-only}}) has dropped superseded ({{drop-superseded}}) or expired ({{drop-expired}}) certifications, it's possible for the certificate composed of the remaining packets to have no valid first-party certification at the time that a given signature was made. Such a certificate would be invalid according to {{RFC4880}}, and consequently verification of any signature . However, there is a simple mitigation: anyone distributing a signature (e.g. a software archive) should ship the contemporary signing certificate alongside the signature. If the distributor does this, then the verifier can perform a certificate update (to learn about revocations) against any preferred keystore, including non-append-only keystores, merging what it learns into the distributed contemporary certificate. Then the signature verifier can follow the certificate evaluation process outlined in {{point-in-time}}, using the merged certificate. Global Append-only Ledgers ("Blockchain") {#gaol} =2D---------------------------------------- The append-only aspect of some OpenPGP keystores encourages a user of the keystore to rely on that keystore as a faithful reporter of history, and one that will not misrepresent or hide the history that they know about. An unfaithful "append-only" keystore could abuse the trust in a number of ways, including withholding revocation certificates, offering different sets of certificates to different clients doing key discovery, and so on. However, the most widely used append-only OpenPGP keystore, the {{SKS}} keyserver pool, offers no cryptographically verifiable guarantees that it will actually remain append-only. Users of the pool have traditionally relied on its distributed nature, and the presumption that coordination across a wide range of administrators would make it difficult for the pool to reliably lie or omit data. However, the endpoint most commonly used by clients to access the network is `hkps://hkps.pool.sks-keyservers.net`, the default for {{GnuPG}}. That endpoint is increasingly consolidated, and currently consists of hosts operated by only two distinct administrators, increasing the risk of potential misuse. Offering cryptographic assurances that a keystore could remain append-only is an appealing prospect to defend against these kinds of attack. Many popular schemes for providing such assurances are known as "blockchain" technologies, or global append-only ledgers. With X.509 certificates, we have a semi-functional Certificate Transparency ({{RFC6962}}, or "CT") ecosystem that is intended to document and preserve evidence of (mis)issuance by well-known certificate authorities (CAs), which implements a type of global append-only ledger. While the CT infrastructure remains vulnerable to certain combinations of colluding actors, it has helped to identify and sanction some failing CAs. Like other global append-only ledgers, CT itself is primarily a detection mechanism, and has no enforcement regime. If a widely-used CA were identified by certificate transparency to be untrustworthy, the rest of the ecosystem still needs to figure out how to impose sanctions or apply a remedy, which may or may not be possible. CT also has privacy implications -- the certificates published in the CT logs are visible to everyone, for the lifetime of the log. For spam abatement, CT logs decline all X.509 certificates except those issued by certain CAs (those in popular browser "root stores"). This is an example of the strategy outlined in {{authorities}}). Additional projects that provide some aspects of global append-only ledgers that try to address some of the concerns described here include {{KEY-TRANSPARENCY}} and {{CONIKS}}, though they are not specific to OpenPGP. Both of these systems are dependent on servers operated by identity providers, however. And both offer the ability to detect a misbehaving identity provider, but no specific enforcement or recovery strategies against such an actor. It's conceivable that a keystore could piggyback on the CT logs or other blockchain/ledger mechanisms like {{BITCOIN}} to store irrevocable pieces of data (such as revocation certificates). Further work is needed to describe how to do this in an effective and performant way. Certificate Discovery for Identity Monitoring {#identity-monitoring} =2D-------------------------------------------- A typical use case for certificate discovery is a user looking for a certificate in order to be able to encrypt an outbound message intended for a given e-mail address, but this is not the only use case. Another use caes is when the party in control of a particular identity wants to determine whether anyone else is claiming that identity. That is, a client in control of the secret key material associated with a particular certificate with user ID X might search a keystore for all certificates matching X in order to discover whether any other certificates claim it. This is an important safeguard as part of the ledger-based detection mechanisms described in {{gaol}}, but may also be useful for keystores in general. However, identity monitoring against a keystore that does not defend against user ID flooding ({{user-id-flooding}}) is expensive and potentially of limited value. In particular, a malicious actor with a certificate which duplicates a given User ID could flood the keystore with similar certificates, hiding whichever one is in malicious use. Since such a keystore is not considered authoritative by any reasonable client for the user ID in question, this attack forces the identity-monitoring defender to spend arbitrary resources fetching and evaluating each certificate in the flood, without knowing which certificate other clients might be evaluating. OpenPGP details =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This section collects details about common OpenPGP implementation behavior that are useful in evaluating and reasoning about OpenPGP certificates. Revocations {#revocations} =2D---------- It's useful to classify OpenPGP revocations of key material into two categories: "soft" and "hard". If the "Reason for Revocation" of an OpenPGP key is either "Key is superseded" or "Key is retired and no longer used", it is a "soft" revocation. An implementation that interprets a "soft" revocation will typically not invalidate signatures made by the associated key with a creation date that predates the date of the soft revocation. A "soft" revocation in some ways behaves like a non-overridable expiration date. All other revocations of OpenPGP keys (with any other Reason for Revocation, or with no Reason for Revocation at all) should be considered "hard". The presence of a "hard" revocation of an OpenPGP key indicates that the user should reject all signatures and certifications made by that key, regardless of the creation date of the signature. Note that some OpenPGP implementations do not distinguish between these two categories. A defensive OpenPGP implementation that does not distinguish between these two categories SHOULD treat all revocations as "hard". An implementation aware of a "soft" revocation or of key or certificate expiry at time T SHOULD accept and process a "hard" revocation even if it appears to have been issued at a time later than T. User ID Conventions {#user-id-conventions} =2D------------------ {{RFC4880}} requires a user ID to be a UTF-8 string, but does not constrain it beyond that. In practice, a handful of conventions predominate in how User IDs are formed. The most widespread convention is a name-addr as defined in {{RFC5322}}. For example: Alice Jones But a growing number of OpenPGP certificates contain user IDs that are instead a raw {{RFC5322}} addr-spec, omitting the display-name and the angle brackets entirely, like so: alice@example.org =20=20=20=20 Some certificates have user IDs that are simply "normal" human names (perhaps display-name in {{RFC5322}} jargon, though not necessarily conforming to a specific ABNF). For example: Alice Jones Still other certificates identify a particular network service by scheme and hostname. For example, the administrator of an ssh host participating in the {{MONKEYSPHERE}} might choose a user ID for the OpenPGP representing the host like so: ssh://foo.example.net Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document offers guidance on mitigating a range of denial-of-service attacks on public keystores, so the entire document is in effect about security considerations. Many of the mitigations described here defend individual OpenPGP certificates against flooding attacks (see {{certificate-flooding}}). But only some of these mitigations defend against flooding attacks against the keystore itself (see {{keystore-flooding}}), or against flooding attacks on the space of possible user IDs (see {{user-id-flooding}}). Thoughtful threat modeling and monitoring of the keystore and its defenses are probably necessary to maintain the long-term health of the keystore. {{designated-revoker}} describes a potentially scary security problem for designated revokers. TODO (more security considerations) Tension Between Unrestricted Uploads and Certificate Discovery {#uploads-vs= -discovery} =2D------------------------------------------------------------- Note that there is an inherent tension between accepting arbitrary certificate uploads and permitting effective certificate discovery. If a keystore accepts arbitrary certificate uploads for redistribution, it appears to be vulnerable to user ID flooding ({{user-id-flooding}}), which makes it difficult or impossible to rely on for certificate discovery. In the broader ecosystem, it may be necessary to use gated/controlled certificate discovery mechanisms. For example, both {{I-D.koch-openpgp-webkey-service}} and {{RFC7929}} enable the administrator of a DNS domain to distribute certificates associated with e-mail addresses within that domain, while excluding other parties. As a rather different example, {{I-D.mccain-keylist}} offers certificate discovery on the basis of interest -- a client interested in an organization can use that mechanism to learn what certificates that organization thinks are worth knowing about, regardless of the particular DNS domain. Note that this {{I-D.mccain-keylist}} does not provide the certificates directly, but instead expects the client to be able to retrieve them by certificate fingerprint through some other keystore capable of (and responsible for) certificate update. Privacy Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Keystores themselves raise a host of potential privacy concerns. Additional privacy concerns are raised by traffic to and from the keystores. This section tries to outline some of the risks to the privacy of people whose certificates are stored and redistributed in public keystores, as well as risks to the privacy of people who make use of the key stores for certificate discovery or certificate update. TODO (more privacy considerations) Publishing Identity Information =2D------------------------------ Public OpenPGP keystores often distribute names or e-mail addresses of people. Some people do not want their names or e-mail addresses distributed in a public keystore, or may change their minds about it at some point. Append-only keystores are particularly problematic in that regard. The mitigation in {{only-revocation}} can help such users strip their details from keys that they control. However, if an OpenPGP certificate with their details is uploaded to a keystore, but is not under their control, it's unclear what mechanisms can be used to remove the certificate that couldn't also be exploited to take down an otherwise valid certificate. Some jurisdictions may present additional legal risk for keystore operators that distribute names or e-mail addresses of non-consenting parties. Updates-only keystores ({{updates-only}}) and user ID redacting keystores ({{user-id-redacting}}) may reduce this particular privacy concern because they distribute no user IDs at all. Social Graph =2D----------- Third-party certifications effectively map out some sort of social graph. A certification asserts a statement of belief by the issuer that the real-world party identified by the user ID is in control of the subject cryptographic key material. But those connections may be potentially sensitive, and some people may not want these maps built. A first-party-only keyserver ({{first-party-only}}) avoids this privacy concern because it distribues no third-party privacy concern. First-party attested third-party certifications described in {{fpatpc}} are even more relevant edges in the social graph, because their bidirectional nature suggests that both parties are aware of each other, and see some value in mutual association. Tracking Clients by Queries {#tracking-clients} =2D-------------------------- Even without third-party certifications, the acts of certificate discovery and certificate update represent a potential privacy risk, because the keystore queried gets to learn which user IDs (in the case of discovery) or which certificates (in the case of update) the client is interested in. In the case of certificate update, if a client attempts to update all of its known certificates from the same keystore, that set is likely to be a unique set, and therefore identifies the client. A keystore that monitors the set of queries it receives might be able to profile or track those clients who use it repeatedly. Clients which want to to avoid such a tracking attack MAY try to perform certificate update from multiple different keystores. To hide network location, a client making a network query to a keystore SHOULD use an anonymity network like {{TOR}}. Tools like {{PARCIMONIE}} are designed to facilitate this type of certificate update. Keystores which permit public access and want to protect the privacy of their clients SHOULD NOT reject access from clients using {{TOR}} or comparable anonymity networks. Additionally, they SHOULD minimize access logs they retain. Alternately, some keystores may distribute their entire contents to any interested client, in what can be seen as the most trivial form of private information retrieval. {{DEBIAN-KEYRING}} is one such example; its contents are distributed as an operating system package. Clients can interrogate their local copy of such a keystore without exposing their queries to a third-party. Cleartext Queries =2D---------------- If access to the keystore happens over observable channels (e.g., cleartext connections over the Internet), then a passive network monitor could perform the same type profiling or tracking attack against clients of the keystore described in {{tracking-clients}}. Keystores which offer network access SHOULD provide encrypted transport. Traffic Analysis =2D--------------- Even if a keystore offers encrypted transport, the size of queries and responses may provide effective identification of the specific certificates fetched during discovery or update, leaving open the types of tracking attacks described in {{tracking-clients}}. Clients of keystores SHOULD pad their queries to increase the size of the anonymity set. And keystores SHOULD pad their responses. The appropriate size of padding to effectively anonymize traffic to and from keystores is likely to be mechanism- and cohort-specific. For example, padding for keystores accessed via the DNS ({{RFC7929}} may use different padding strategies that padding for keystores accessed over WKD ({{I-D.koch-openpgp-webkey-service}}), which may in turn be different from keystores accessed over HKPS ({{I-D.shaw-openpgp-hkp}}). A keystore which only accepts user IDs within a specific domain (e.g., {{scoped-user-ids}}) or which uses custom process ({{exterior-process}}) for verification might have different padding criteria than a keystore that serves the general public. Specific padding policies or mechanisms are out of scope for this document. User Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D {{client-interactions}} describes some outstanding work that needs to be done to help users understand how to produce and distribute a third-party-certified OpenPGP certificate to an abuse-resistant keystore. Additionally, some keystores present directly user-facing affordances. For example, {{SKS}} keyservers typically offer forms and listings that can be viewed directly in a web browser. Such a keystore SHOULD be as clear as possible about what abuse mitigations it takes (or does not take), to avoid user confusion. Experience with the {{SKS}} keyserver network shows that many users treat the keyserver web interfaces as authoritative, even though the developer and implementor communities explicitly disavow any authoritative role in the ecosystem, and the implementations attempt very few mitigations against abuse, permitting republication of even cryptographically invalid OpenPGP packets. Clearer warnings to end users might reduce this kind of misperception. Or the community could encourage the removal of frequently misinterpreted user interfaces. IANA Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document asks IANA to register two entries in the OpenPGP Notation IETF namespace, both with a reference to this document: * the "ksok" notation is defined in {{fpatpc}}. =20 * the "uidhash" notation is defined in {{uidhash}}. Document Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \[ RFC Editor: please remove this section before publication ] This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by e-mail to the author. Please direct all significant commentary to the public IETF OpenPGP mailing list: openpgp@ietf.org Document History =2D--------------- substantive changes between -01 and -02: * distinguish different forms of flooding attack * distinguish toxic data as distinct from flooding * retrieval-time mitigations * user ID redaction * references to related work (CT, keylist, CONIKS, key transparency, ledgers/"blockchain", etc) * more details about UI/UX substantive changes between -00 and -01: * split out Contextual and Non-Append-Only mitigations * documented several other mitigations, including: - Decline Data From the Future - Blocklist - Exterior Process - Designated Authorities - Known Certificates - Rate-Limiting - Scoped User IDs * documented Updates-Only Keystores * consider three different kinds of flooding * deeper discussion of privacy considerations * better documentation of Reason for Revocation * document user ID conventions =20 Acknowledgements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 This document is the result of years of operational experience and observation, as well as conversations with many different people -- users, implementors, keystore operators, etc. A non-exhaustive list of people who have contriubuted ideas or nuance to this document specifically includes: * Antoine Beaupr=C3=A9 * ilf * Jamie McClelland * Jonathan McDowell * Justus Winter * Marcus Brinkmann * Micah Lee * Neal Walfield * Phil Pennock * vedaal * Vincent Breitmoser * Wiktor Kwapisiewicz --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLTC6AAKCRB2GBllKa5f +O6aAQC+lTMJ8We+rvdVg2IlWW0QJL52h/mRlajH8Db1toj3PQD9EWP7Dujmxv/T r7G/YDfdBen7cYAIBbrgsdS7UgCwMgU= =zyxn -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Apr 15 11:02:58 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D36120098 for ; Mon, 15 Apr 2019 11:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 Nt94HoAanhGy for ; Mon, 15 Apr 2019 11:02:53 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE1912011D for ; Mon, 15 Apr 2019 11:02:52 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id t30so13789711lfd.8 for ; Mon, 15 Apr 2019 11:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=from:openpgp:autocrypt:organization:to:subject:message-id:date :mime-version; bh=FHg3bPUVQES88E4L9cG53YJ7XnCyIQn8DfDGUMBq/nc=; b=RedWten58lYhHyxs5KJjM3fhfwF2oGM91YfV0VIeuOcpGGfZ7ynTAmEUWY9xnJn1jo woVSTKitMKNwlFm16KH6tgm6CGhGtQa+BIDkqzVyRanNZ+2aeFhExkYrn3TTQdu7yaaG q3FpCnuNL/b30ostjvN/uD3jg81OOr/OsgH1R/CZKu8FEr/ZtyHwHfH9QZY7VNgHWq6H zNqUH2wEtabOxXFzWsk/108aMD7wZ9XTh/SUV4cyf7oXTaWHjNppP8/65OnS85cFp1XF +llzv2simcveLpix2dUJHZS/G6BTaUzbP/XG22j9szj+XAILMYtkKxRzBolLvI9iR3rA VGbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:openpgp:autocrypt:organization:to:subject :message-id:date:mime-version; bh=FHg3bPUVQES88E4L9cG53YJ7XnCyIQn8DfDGUMBq/nc=; b=eiEtgIEqdbUMS5xKHQQSXmlZko/7QhfVUZgVj+xUukLkmoB8FMwDuMVoj5n1NKuNpJ YSMr/okzMkYTqquM4gAU0Q1qx8fsp2F0C/st6zf7vmL5io/4cf7F8LTl2d3oohQPMgO6 Sa+wWBeTusd8sVbqX9APsn7A8+dRfp3zEoja3fY9nS0slvTF7bt6DiU2atbGwOuNNFJs A2w0ormMNgoE4J3MOjpoaVjc3lu0VE0purorEtZkxuWzavyxk1U0+e1UP8W4cT8rbVAK dA0Nc61UajjK8Atxb+8BOFThwwPQdraMtp+XkQ9xy8L9hnkbYQr+/3hHNg5xlEnVU7Dw XU3g== X-Gm-Message-State: APjAAAUfZ3AmeZD4l0Czj2ITOat3fMQDEeXp6U5j84DcXPDSW5Us/UcI 0FTVbIJ8cD69c7vVys5jvsXxCkcVPNTeEw== X-Google-Smtp-Source: APXvYqyzFTrCVOHWYJ6D+jfcfU3XupDfw/j9EeYXiEO23MYnYdQQBVP4XdQ6tRc6PBKLGDT+Y3iQyw== X-Received: by 2002:a19:cb09:: with SMTP id b9mr16633284lfg.55.1555351370392; Mon, 15 Apr 2019 11:02:50 -0700 (PDT) Received: from ?IPv6:2a02:a317:4e3d:46f0:8257:3c28:8576:2eba? ([2a02:a317:4e3d:46f0:8257:3c28:8576:2eba]) by smtp.googlemail.com with ESMTPSA id h2sm1218760lfc.77.2019.04.15.11.02.49 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 15 Apr 2019 11:02:49 -0700 (PDT) From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode To: "openpgp@ietf.org" Message-ID: Date: Mon, 15 Apr 2019 20:02:24 +0200 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hIc6msxKvKxWFLrYtC27ZHd25z4MHgsz5" Archived-At: Subject: [openpgp] Web Key Directory and advanced lookup method X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 18:02:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hIc6msxKvKxWFLrYtC27ZHd25z4MHgsz5 Content-Type: multipart/mixed; boundary="vbcScYnyF9nzdgbTE9kI7RCBXpXajdP88"; protected-headers="v1" From: Wiktor Kwapisiewicz To: "openpgp@ietf.org" Message-ID: Subject: Web Key Directory and advanced lookup method --vbcScYnyF9nzdgbTE9kI7RCBXpXajdP88 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello, I'd like to ask about the (potential) issue with advanced lookup method=20 in WKD. For those that don't remember what it is it converts e-mail (such as=20 "Joe.Doe@Example.ORG") into a URL that uses "openpgpkey" subdomain of=20 the e-mail domain (in this case=20 "https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9= q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe").=20 [0] There are some domains that allow users to register subdomains with any=20 name the user requests (with some exceptions). For example "github.io".=20 So if a user selects "openpgpkey" as a name and thus will be able to=20 host files under the ".well-known" directory they will effectively=20 intercept all WKD queries for e-mail addresses for that domain. That is query for key for "security@github.io" will go to the user that=20 registers "openpgpkey" name. The problem of domains under which Internet users can directly register=20 names also exists in browsers. To avoid various security issues w.r.t.=20 supercookies Mozilla manages Public Suffix List [1] that is used by all=20 major browsers. The list is quite big [2]. I did take a look at MTA-STS [3] as it also uses subdomain but in=20 MTA-STS's case they first start with DNS TXT record query and only then=20 query mta-sts subdomain so mere registration of subdomain wouldn't=20 trigger MTA-STS. I don't want to suggest any fixes to the spec just inquire if you think=20 it's a real issue or rather a quite obscure edge case. Thank you for your time! Kind regards, Wiktor [0]:=20 https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section-= 3.1 [1]: https://publicsuffix.org/ [2]: https://github.com/publicsuffix/list/blob/master/public_suffix_list.= dat [3]: https://tools.ietf.org/html/rfc8461 --=20 https://metacode.biz/@wiktor --vbcScYnyF9nzdgbTE9kI7RCBXpXajdP88-- --hIc6msxKvKxWFLrYtC27ZHd25z4MHgsz5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJyBAEBCABcFiEEWaKd6o03OIxlaGPfuXoe4J20F+wFAly0xzYpGGh0dHBzOi8v bWV0YWNvZGUuYml6L0B3aWt0b3Ivb3BlbnBncC9rZXkUHHdpa3RvckBtZXRhY29k ZS5iaXoACgkQuXoe4J20F+xHfg//QbQrjzBfO3tHNL2jicG9a+lzCILu5/w0Gf87 SKRxq0c6ildM6vG8n6bL86sKcYtkLiprzDQ8HJrqIdvpJ4bxwC70JjfBngmXcmRS ZU+8Ln1HuCmCGQ5Qi4mj2k/A9UOLhDtOWAQZ+xsP+xFJC/spfFcrJU7NG7xkS8r8 a5/sqZDfGb2LARkxFkW2r8VWUUNrbjfDgUSUkPGvr5LDI+f8WEeC29HbTJOf/DnI Od2CCNtBPQ/NX7XriBmdqHf3uMt30hExSXCdIZ1g2dzd+efefzGkoIUz1xTswclh 0TgJK0j8s4RJWicV9GlT+oHfi2ueCJeu+OUikhS9cjnDq46KLTOzho2BKWw+BVRK TZ1JIHZfXcl4A/zFpFBB5u0ZM82QWoL4cGPXufGZXvMqd+zKZhCjZpfoDMBd0RUr Z/0szEOhNBdiB+5zU0ghv450TIPm1nEk2cuyxdCX4vhV7o3yDvvjZG4igxa3olwJ Rm25iB7ng/3lCy6m54SR0oEP4EEwCYJmgXZDZxG8j13MPBUv3Quh1c2J2UhpnaZ0 g6JCSc8/j8VwISmHqx4nXhqDXI0UG9Q37GFlrg1p6itd0eic0xZ9Uw11J07+kc7y pXTlyWMcBPqyL0Vg4HaZDyv5e7shHvjXcTwHIFyw+m2lfzKJeDEFlb6tNHvsazLJ Mt2OvYs= =MfOi -----END PGP SIGNATURE----- --hIc6msxKvKxWFLrYtC27ZHd25z4MHgsz5-- From nobody Mon Apr 15 17:01:06 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0712009A for ; Mon, 15 Apr 2019 17:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 UqIZqKUt2NQa for ; Mon, 15 Apr 2019 17:01:02 -0700 (PDT) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2866120043 for ; Mon, 15 Apr 2019 17:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1555372860; bh=FbQ5SE/wXIW+yMs5Ujt6cW54O1XQYQVFqgL5hIdJGek=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=U4wnHCs2Xte1eVidA7/YMBriny8GXM8tkpSuLjJJr8g3tgNwK4HOEUM3/mfMDNtHl T+hdv7rxA9Wbv0hGMnEaktgA5k865YrWveBDPnM1ZhSUmc0drc4pSCKag1/zwC/pUg rxLK7SEsrOi2WVwuaFQdnh5R54vhaToeSPiNgmsBvnUbs9fl+3BeN4QnR4sL+Vkakh EP8vsm6JKPwyZKEmtrySGX9ezOzOOE8RFv7LI5ryJ5W0CEdJLxkV88wyBygI5TZ5l5 srJIufqcjLi5uqOINR2Kh5u+ir8g60GRbOX1zY6wOfcqfUmhlPm8l7U6WxKPPC91jf bm52DpYp6q1XA== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id C8EE9C014C; Tue, 16 Apr 2019 00:00:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: Date: Mon, 15 Apr 2019 17:00:58 -0700 Cc: Jon Callas , "openpgp@ietf.org" , Justus Winter , "Neal H. Walfield" , Peter Gutmann Content-Transfer-Encoding: quoted-printable Message-Id: <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> To: Bart Butler X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904150159 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 00:01:04 -0000 > On Mar 30, 2019, at 9:11 PM, Bart Butler = wrote: >=20 [...] >> OpenPGP is in general the latter case rather than the former. I = believe it=E2=80=99s less important to have strict semantics on failures = because it=E2=80=99s usually storage. >>=20 >=20 >=20 > I agree. I would say my point is that with sufficiently small chunks, = the user/decrypter can choose what kind of failure behavior is = appropriate. Large chunks robs the decrypter of that. We are mostly in violent agreement, I do believe. I feel like I'm saying = something like "a quarter is a coin with George Washington on one side = and an eagle on the other" and you're saying "a quarter is a coin with = an eagle on one side and George Washington on the other." We're talking = about the same coin, with a slightly different point of view. I wouldn't use a term like "rob" because that assigns value to the = condition. I think there are places where rejection matters and is a = Good Thing. I think there places where it is not a good thing and is = even a Bad Thing. That's why I was using terms like "strict semantics" = and a lot of conditionals. I don't want to bury my lede any deeper than this. What I'm saying is: * The more you want strict AEAD semantics of no-release, the fewer = chunks you want. * It seems to me that the people who most believe in strict AEAD release = are also the ones who are arguing for smaller packets. These seem to be = in opposition to each other. I've been confused through this discussion = because the rationales seem in opposition and confused. I don't get it, = and I want to understand; you all are smart people whom I respect, so if = I'm confused, maybe I'm not getting something. We might differ in that I have a nuanced opinion about AEAD rejection. I = think that there are places where it matters, and places where you = don't. For example, in networking, particularly the parts of the network = stack where you can easily get a forged packet. You want to reject that = packet as early as possible. Moreover, these places are always using = very small packets. (I'm going to wave my hand and say that under a = megabyte is "very small" for these purposes.) But in archival storage, you *don't* want to reject something because = there's a media error, you want to recover as much as possible. You = might even be required to do so by law. I have real-world anecdotes if = you want to hear them. On a network, rejection is a good thing. You reply a NAK to the sender = and they retransmit. In archival storage, there's no retransmitting on a = media error. That's the case where it's a Bad Thing, and in fact, it = might even be better to use CFB mode and an MDC than AEAD. It also might = not, and much depends on which AEAD mode one used. Nonetheless, if you believe in strict semantics, you also likely want = the fewest number of chunks. If there is more than one chunk, you have = to stage the output, you have to process *everything* (unless you're = going to say that the timing side-channel is not important) Sometimes this is not possible. Ironically, the place where it's most = possible is in storage, where it's the least needed. In online = protocols,=20 >=20 > OK, I think this is the part that I don't understand. Why does it = matter what chunking scheme is used here? If my app requires = all-or-nothing semantics, I would program my app to enforce that all = chunks must pass and not release plaintext unless that happened, with no = truncation, etc. So why would every joint be a vulnerability? >=20 >>> What value does large-chunk AEAD actually provide? What I'm getting = from the AEAD Conundrum message is that it's a way for the message = encrypter to leverage the "don't release unauthenticated chunks" = prohibition to force the decrypter to decrypt the whole message before = releasing anything. Why do we want to give the message creator this kind = of power? Why should the message creator be given the choice to force = her recipient to either decrypt the entire message before release or be = less safe than she would have been with smaller chunks? >>=20 >=20 >> Let me summarize the conundrum: If you want strict AEAD no-release = semantics, you want a fewer number of chunks. >=20 > I guess this is my fundamental question. You can force no-release = semantics at the application level for any chunk size scheme, right? Yes, you can, provided that there's a way to report that back, and your = caller checks the return value.=20 I suppose this really means no, you can't force it, because the library = writer can't force the application code to check the error return. I have heard that some issues that we're Not Going To Talk About had = among the issues improper checking GnuPG's report of an MDC failure was = an issue in at least one place. >> If you respond to a security request with a performance answer, you = literally don=E2=80=99t know what you=E2=80=99re talking about. So = let=E2=80=99s toss that aside. >=20 > I apologize, I was not trying to create a strawman here, but I am = completely at a loss for what the benefit of large chunks is. =46rom a standpoint of debate technique, coming up with a strawman makes = your whole side of it weaker because attacking a strawman is attacking a = strawman. It makes it look like you don't understand, when you actually = have a different issue. I think it has added to the confusion I have = been suffering from. The chunk size question is about adjusting security = parameters, and thus when you say, "it won't help performance" I can't = help but think that we're not discussing the same thing at all, as I'm = talking security, and you're talking performance. Good to put that to bed. Back to the chunk size debate. I don't know the specific benefits, either. I heard people asking for = it, and I'm defending the idea for them. I believe that an underlying difference between your thinking and mine = is that you're looking at this as an application writer, and I'm looking = at it like a protocol / API that has many clients, some of whom (and the = largest ones) aren't written yet. Moreover, there are a lot of people who use OpenPGP for a lot of things = that we don't know about. As Peter Gutmann pointed out there are a lot = of EDI systems, back ends of financial systems, and so on that = internally use OpenPGP implementations. They're not here. I'm trying to = watch out for them.=20 There are also people around who want to do something and for a lot of = reasons find it difficult to speak up. I'm not editor any more, Werner = is and I have every faith in him. Sometimes, though, old habits die = hard. I tend to see the AEAD packet format as being a successor to the = existing streaming, indefinite length things. That allows chunking up to = 2^30 and while absurdly large, it has never been an issue.=20 In my head, I think why not allow up to that, since it would preserve = anyone's weird thing? On the other side, implementers need guidance. Today, the guidance is = folklore with all the issues that go with it. It's better not to have = folklore. But, if we basically said, "do what you're doing today" then = we'd be looking at 8K chunks, as that's what GnuPG does today. The clauses I suggested about MAY support larger / MAY give larger the = finger seemed to be a compromise that would work because it gives you = the guidance you need; it lets whoever these people are the ability to = do what they want; and lastly should there be a consensus that it needs = to be larger in the real world, a consensus of implementers can change = it without a new document. It seemed to me that everyone wins. Yet I thought I perceived that you not only wanted to win, but you = wanted to salt the earth in the other people's territory. Fixing an = upper bound on memory has a long history of Famous Last Words going back = to the old clich=C3=A9d "640K is more than enough for anyone." The gods = punish hubris. Okay -- let's sort all this out. I really think we are ALMOST done here. Here's what I stated before. >=20 >> (1) MUST support up to chunks. >> (2) SHOULD support up to chunks, as these are = common.. >> (3) MAY support larger up to the present very large size. >> (4) MAY reject or error out on chunks larger than , = but repeating ourselves, SHOULD support . >>=20 >=20 >> Clauses (3) and (4) set up a sandbox for the people who want very = large chunks. They can do whatever they want, and the rest of us can = ignore them.. Why get rid of that? It doesn=E2=80=99t add any complexity = to the code. It lets the people who want the huge ones do them in their = own environment and not bother other people. >>=20 >=20 >> My concern is over (1) and (2) and specifically that there=E2=80=99s = both and sizes. >>=20 >=20 >> I think that=E2=80=99s an issue. If there are two numbers we are apt = to end up with skew before settling on one, so it=E2=80=99s better to = agree on just one. That=E2=80=99s the real wart in my proposal. >>=20 >=20 >=20 > I'm OK with eliminating (2) and just using the MAY part to take care = of any legacy 256K messages OpenPGP.js users might have. As I said, we = don't have any of these messages in production yet and I'd err on the = side of a cleaner spec. Me too. I think saying 256K is fine. I have an intuition it ought to be = at least as large as the largest Jumbo Frame, and that's 9K so round to = 16K. Let me restate the proposal. (1) MUST support up to chunks. (3) MAY support larger up to the present very large size. (4) MAY reject or error out on chunks larger than And it seems that 256K is the proposal for . Are we agreed = on all that? > I just really want to understand the benefit of large chunks for = security and right now I clearly do not. If you believe that no-release is a Good Thing, then you want fewer = chunks, ideally only 1 chunk. That's it. That's the ONLY reason. I believe that no-release can be a Good Thing, but rarely is for = OpenPGP's primary use case. As I said in my other missive, I don't think = that it's even possible in the general case. Networking packets, yes -- = both possible and desirable. Files, no -- neither possible nor = desirable. Jon From nobody Mon Apr 15 17:16:11 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CCA1202A7 for ; Mon, 15 Apr 2019 17:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 sD_aZRPodtCG for ; Mon, 15 Apr 2019 17:16:07 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE71E120043 for ; Mon, 15 Apr 2019 17:16:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 12ED1E2042; Mon, 15 Apr 2019 20:16:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04456-01; Mon, 15 Apr 2019 20:16:02 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 55B7CE2045; Mon, 15 Apr 2019 20:16:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1555373762; bh=Y2w2iHFEr+mRAwMFMtfU314CJJGMCNlZXhF98LD52fk=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=MDFDTvUo1sTAjHz8C903By5dDDOSpMlpuxrK3g63UqJ2ws2wkzT9fY9ldzB6ScFjh ZLVVeA2dDBAZoqYihmAOZzDF6zkTSZCeheEGCJ6aMHG/qHNU5roK6A/oPHGdt2sUiw X1Fe/gzio8v9vH4ua1KWo4Vg1mY3Z/6DYl9iqjcw= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 15 Apr 2019 20:16:02 -0400 Message-ID: <2dfa15ba7b415fe08df299c34bd42f61.squirrel@mail2.ihtfp.org> In-Reply-To: <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> Date: Mon, 15 Apr 2019 20:16:02 -0400 From: "Derek Atkins" To: "Jon Callas" Cc: "Bart Butler" , "openpgp@ietf.org" , "Justus Winter" , "Neal H. Walfield" , "Jon Callas" , "Peter Gutmann" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 00:16:10 -0000 Jon, On Mon, April 15, 2019 8:00 pm, Jon Callas wrote: > [snip] > Me too. I think saying 256K is fine. I have an intuition it ought to be at > least as large as the largest Jumbo Frame, and that's 9K so round to 16K. > Let me restate the proposal. > > (1) MUST support up to chunks. > (3) MAY support larger up to the present very large size. > (4) MAY reject or error out on chunks larger than > > And it seems that 256K is the proposal for . Are we agreed on > all that? I would rather 256K not be the One Required Size. It's larger than the RAM size on some of my systems. I would still prefer 16K (or even 8K). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 15 18:24:02 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8636B1202F8 for ; Mon, 15 Apr 2019 18:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 GPw7E9rHaZLV for ; Mon, 15 Apr 2019 18:23:59 -0700 (PDT) Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D901202F9 for ; Mon, 15 Apr 2019 18:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1555377838; bh=BYkIod8lu91B+JuC+AMwzVPhLfqqgJcYRqMY9nWbcRs=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=jLk8A9YudZtKfPdYtPq8aKKr/kwsAwRaDTfubsGwgAVAXu1MY5ukSxy6bjYIpCjb9 ops52+G//xToQqlC+AA1lDc0FMzjYjAf5fA2AtwjhbijgnPFvmTFCgNg7h8hhhTM0j Z+38FyK8NllNyzxn0iC+o4qRaZKyviPqo5Hh6GV2fuczXQj286+wMWmjSjhfABkbzs Va8LaEHj6lU8dujNblwiKJhSOlDS5fmiRjy2FZ+TmWwR9e0GInuLIy5FqICwIvj+k9 E7HYaNNObl1hAgROmLsZdVLemSD+tUy+FJ6Sx0k4JiGv4nPLoKp96pnPu/lQ8J+8kL K3PyNh8kkW7iw== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id E9D49A0005C; Tue, 16 Apr 2019 01:23:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas X-Priority: 3 (Normal) In-Reply-To: <2dfa15ba7b415fe08df299c34bd42f61.squirrel@mail2.ihtfp.org> Date: Mon, 15 Apr 2019 18:23:56 -0700 Cc: Jon Callas , Jon Callas , Bart Butler , "openpgp@ietf.org" , Justus Winter , "Neal H. Walfield" , Peter Gutmann Content-Transfer-Encoding: quoted-printable Message-Id: <766C654B-2406-483C-AE30-630B560D1E94@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> <2dfa15ba7b415fe08df299c34bd42f61.squirrel@mail2.ihtfp.org> To: Derek Atkins X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-16_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904160007 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 01:24:01 -0000 > On Apr 15, 2019, at 5:16 PM, Derek Atkins wrote: >=20 > Jon, >=20 > I would rather 256K not be the One Required Size. It's larger than = the > RAM size on some of my systems. I would still prefer 16K (or even = 8K). Bart, Neal? What do you guys think? I spent part of the afternoon verifying GnuPG's chunk size. I started = off using --list-packets to get the size of something, and then moved to = using pgpdump. gpg --list-packets reports the combined length of all the = partials as if it was one big thing, but pgpdump shows different. I = found that out after I sent my last thing. I thought it was using = single-chunk lengths even with some moderately large files. Only when it = was showing single size for something over a gigabyte did I go grab = pgpdump.=20 Playing around, GnuPG aggressively uses 8K chunks, and even when I = encrypted something below 8K in length, it used a 4K chunk, a 2K chunk, = and then tied off the rest.=20 Why not pick 8K? Arguments in favor: * It's what is done now. * As noted in Bart and Neal's comments, there isn't going to be a huge = performance difference. * It works in small implementations, as Derek says. Arguments against --=20 * I have no idea. Someone who isn't me should say something even like "I = want it." Anyone else? Jon= From nobody Tue Apr 16 10:39:23 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43636120391 for ; Tue, 16 Apr 2019 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 zXw4U2BDJq_O for ; Tue, 16 Apr 2019 10:39:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355DC120388 for ; Tue, 16 Apr 2019 10:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1555436356; bh=OXRr7Umc5vuNWyNHNQNtKBrySgXLxyWpPyuFA4J9/4Y=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=hF1ErXzb8Hg/+6R2ZcFGNq/aAspNKKCsgDErtbzgq1kv/lP+0HLrY8iwfJKwGboiI XVn43Pz+BnFfYxhNqszRf82/3BnSytzie2L2+h/aBHltdT8kRY01TLMm7rb4ABjLYd Gufq9yKGJj+nPmG7PD5S3kmyHZVdiDkSljwh6e8c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([80.132.239.73]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcWSI-1gWylG01yQ-00jpSD for ; Tue, 16 Apr 2019 19:39:16 +0200 To: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> <2dfa15ba7b415fe08df299c34bd42f61.squirrel@mail2.ihtfp.org> <766C654B-2406-483C-AE30-630B560D1E94@icloud.com> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQlSGVpa28gU3Rh bWVyIDxoZWlrby5zdGFtZXJAcG9zdGVvLmRlPohiBBMRAgAiAhsDAh4BAheABQJTnH9pBgsJ CAcDAgYVCAIJCgsEFgIDAQAKCRBPWE64+yvhT4n9AJwNsUcN5bx9/gtUs4LMmqBcePkQKwCf Y4FmM1D4rmTWsHQ1NRgsiqQhc265Aw0EN1gq2RAMAK4ZTZJZeaOmjIYhf9QfN7rQ6iXEF20r OG8NkeHLVLPw02t2QjejO5g4zGQplktPD+JCKBU1B/DL7l8BTDopofw4+fAierJ6C4jo/AbS pArZxaVJNkOVNbwHYPdCmO3yxieeMYQgYoZvtkBSA4OZZh2xLfmi3IRBPRSf+REiqPJBy9aA 0f7634vKldTG7R4PR2UP+THjpM/2SpNiyv/y9ZaEPYn3zHRkWsUw3xAMIiE73Hen6o/J9KIB 2e4jiI3VFiwq0LaKRv5whzltjKydGi2zVqcDLc93lDxsW2OXPE89GH3S/9irlEz/ciBuxtLT MMjSV3OeV34Mid7Muz8RE6whOaZteuEgAcLxONxe3FZHeG2cUuciCZDdFqDRtB6w0XhjltdI ZzD8zHBZyboRfBxubtRzriTxjFcxjI3L5df9uLWjuvkl0fSYpQV5dMX1Yus2kXiMHKUeTVE0 NtHqSnozzu88l6D+dCHX0i1BDFgkZi70oGEEaEW0NQgDItOdNwADBQv/a0d7nasV4JW9mjtF nlJDL9pyXHuGc+y9vfJNdy+DlzuHB44vtl+yH9ecTdpxE7RgB8ZvQvEwUmV+keBw+5NkR3ms +AnPrwZxwAIE/DxnwyBAQETkf9SIBH8cz0BCYQ37B+N4OW/pkYSWadjn2Bgi4IZRWyrDmnAI KwsGzfGUxPIKI3AMcRFFqjdhMaFo3L2GwJ2o0dBxd1LN0Xo6298ydcjrtAbKI1xuNXBfBAeU YCzGjg7cUw6XXfyjU5rTQkxKTu13xsKUwCnse7jOvDnfdNnYC+n7o4WNQBDhTiF0QMZ482ba FtCKcqdQJ3fQ9uioh1kOZirhJJ40xtYrDLcS3H9rQZff0X+CeOa94EdJYYYH7BIpysrfJ9c1 cxrg5brzeb9ofWaxLQvRIXBubbDtd0AunQMJXTfXHUmgYCdzSZVyy1tUzso1QacI4D0PhRIo euP8ihlWhqnHRv5tY8Ue18uFybaVIOWrsXXjQOVBUvXFmYCc9ykvJcyYSadLYkJliEYEGBEC AAYFAjdYKtkACgkQT1hOuPsr4U9xEwCeKB7jHvmUrWnuxsqx2Flvq2/gIk8AoKkOpGf2jud+ 8uWi5c1ohHWeuLtz Message-ID: Date: Tue, 16 Apr 2019 19:39:17 +0200 MIME-Version: 1.0 In-Reply-To: <766C654B-2406-483C-AE30-630B560D1E94@icloud.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Provags-ID: V03:K1:isIV405iIrxRduxPHFNGBWM30JxYt0wyoNeS4xxcuo3WoSrUn6F CTBK6dh6R/JoxVEDxhcpGiE823tkKkLLEvdDPpLQyCaFR10X2YQgwZRHN/dZ1fWIqvwkFOX RXa0A2Vx82gx9b390K/z8o3Dv+sakTppYFOEJeR2YfOEpm6Gx7RiiXEPG+WzChrc6IkgmUI ykHeN9gxqEm3149uIPEUA== X-UI-Out-Filterresults: notjunk:1;V03:K0:iHw/JtM939Y=:g7NyTrbQUdZncYliq4/4X5 a+6N3tlrlEH1q1bWl59t6NXcPcd/d4SZHyJ+t7RK1prUEH1hTcfhVqhUH2mEAfdgYEICgDm7j /PilnytzatIFLTM2f3QXRfWv9cT38Eris3eu3WOHtnzbDpt7z4Zdt0aO+z0KrdoBgFJA6M4oa Shm2HLspSuBRjEbjQqYEm/oyEzZgsZH7jfNHIGcL4NghAh0Tv81uvahuvl0yE+gMwHTUSrxAY 9BKdyFbNrTHnSQ3tD7IF280oUIGrySBqBl2E/gieqYYRQvq3f3et3tvbAbZKfUmZJG0WdWvBk M8JmtivSihFwloIVsKF8qvNWucP5jUv2IMbXQyhyCr/3lwLkh6mI+rh/C0fAFBSQ483yB+7U8 dm9ELLHy1XL91Xcw/ZrOeM2M4V0aUlwsFfvP+SOVNNF+upNtcKK4rJ8wW/dlKVdT+BKo2seBJ 4NLihzqgXH+qhodclOHcgt8yWUrqJVBzuNhjpXU+opIw9D9DKkCzEReRHhO/ftGkohUXuV2HN 6KzapU8Hg4TvaND5cMQRsm9h5R3zztSQoWY2EUdiLbxQoAtgm0Lmp0rBex58KAP5ax6C3JpSV lcRbroSGJhCkOxhsHs2OSo2NiLaO+apCEKLoxD0yUNrKyllcUNDvLGSCman4pX4uY2L76jmqm 0AshsABWLknLUoJh97p9ZYXPS6RiAHUM2qA9T3Vy2B9qj/2DMJDIl/PKGydLm15TDphn/iLyA 73wU6iNZLLidgA0pnX29q4j85ZA4Na3DCBVIM/CGR05Sb9pSwCgE7d2p6+iSk/joFXzjWNiPD GxvGH1Ivv1thQCib57T9mLUOu+PxcxlPadEQe7/RdeLdGa4hu9RscEW+winYaDTvdw6NEwlj0 gIJYEYgUymAsIrbq2WThATkC500+CxLCDMwshrRTAr2TctnOklgyWbso19r6jsdK6jdY19Ym+ ZOYuzk2qd7Q== Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 17:39:21 -0000 On Apr 16, 2019, at 03:23, Jon Callas wrote: > I spent part of the afternoon verifying GnuPG's chunk size. Thank you for analysis of GnuPG's behavior. DKGPG uses a fixed size of 64K for encryption now. However, I will change to 8K, if that is the desired and agreed default size. Bests, Heiko. From nobody Tue Apr 16 12:56:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3137212049B for ; Tue, 16 Apr 2019 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IghqyN8XTGSS for ; Tue, 16 Apr 2019 12:56:24 -0700 (PDT) Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2789F120046 for ; Tue, 16 Apr 2019 12:56:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id B60EA7C95E2 for ; Tue, 16 Apr 2019 21:56:19 +0200 (CEST) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPtwWJyCGJo6 for ; Tue, 16 Apr 2019 21:56:19 +0200 (CEST) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id 7F9187C94BA for ; Tue, 16 Apr 2019 21:56:19 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 22CE5BFC99 for ; Tue, 16 Apr 2019 21:56:18 +0200 (CEST) Date: Tue, 16 Apr 2019 21:56:14 +0200 From: ilf To: openpgp@ietf.org Message-ID: <20190416195614.GH1226@zeromail.org> Mail-Followup-To: openpgp@ietf.org References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190412201300.GJ1226@zeromail.org> <87ef635hmt.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BzSjWsyRXn5FzoOl" Content-Disposition: inline In-Reply-To: <87ef635hmt.fsf@fifthhorseman.net> Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 19:56:27 -0000 --BzSjWsyRXn5FzoOl Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor: > I've only seen a few merge requests, and none of them from "ilf" Sorry, my Gitlab skills are weak. I created patches but forgot to create=20 merge requests. They are now submitted, but unfortunately against the=20 now-outdated version. I assume that some are fixed, but most should=20 still work to merge easily. >> I wonder about the definition of "certificate discovery" here. Even=20 >> without UIDs, these keystores could be used for the *retrieval* of=20 >> specific certificates whose fingerprint (or key ID) is known. This can= =20 >> be the case for signatures (over mails, software or documents) or=20 >> keylists like in https://tools.ietf.org/html/draft-mccain-keylist > I agree, but this distinction is what the document already tries to make= =20 > between certificate *discovery* (lookup by UID or UID substring) and=20 > certificate *update* (lookup by primary key fingerprint). The "Terminology" section sais: > "Certificate discovery" is the process whereby a user retrieves an=20 > OpenPGP certificate based on user ID > "Certificate update" is the process whereby a user fetches new=20 > information about a certificate IMHO: > "Certificate discovery" is the process whereby a user retrieves an=20 > OpenPGP certificate based on the fingerprint (or key ID) With this definition, every "update" is a "retrieval", but not every=20 "retrieval" is an "update". I'm not sure how helpful yet another term=20 would be, maybe could leave it our for simplicity, but I for one=20 stumbled across that section. --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --BzSjWsyRXn5FzoOl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAly2M1wACgkQFT/jmIIc g5QyHRAAt1Ur4EBCsz0bv2lNcr8YHHhvcdfNzLb0RduXFtuAPfSmTK/Z28zLafjl eHNxhAneFN7L5yTrJ4jxb9AK4QbEv1qqp7tDMRkKTDswB5qBhohoKPfizprJ23KI QNU2Gw1QVnrdJ+QLXuv4o9FJXdS7x3Cdt6ZRbAwWzuJZdwvsA5yocOx9gWmnA1/T Ft2p6nJDYpT8rk/S7LFPxhlQe/4OdDQ4DFGMdHEO5aqUWnDVKXaENGwf0PueaRAy X5pES++TlnnYhRGf4AHz9G3TXgoZnvrsRo8eNlgcr0fjQ0/kB8rL/5/r/mJsMKY0 oETPoyWcZgWCuQejRHVtuJrH+r4jVEervLnf/OP6CAyNmcpexXHQ7x6qO8wClZpt S5CvPBfuUJcJRg99HsYcHilTMGUuYfHh+3fDT9owCbYd5PIL25tNEaKeWq93uIXJ 1e4QOC9KTW3vrpM098a6jhjkuL2hi17EOa1sEU40cc3YtYtrsi3cgHjBXQ3s2SvH IAwkwxi5SoYDnImHJGUs3LOR+gswWpfHad1i+l/FTSmlg++qTDHiOryJHUIPCZUg mRGb9Zp0nmfqQnlOlaWXw8WomekRg8AbpVZD2BIgQgAvxXjynrF4Rq7M7AaaltNw lUJjCwcdZcx0BPDVwLhRknBHbkB5V4r7mKKWFmnnT/amj6HImeU= =LouK -----END PGP SIGNATURE----- --BzSjWsyRXn5FzoOl-- From nobody Tue Apr 16 13:45:55 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AB41201C5 for ; Tue, 16 Apr 2019 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=i46qnCcZ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=hnIxlbAB 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 LPGDSr0g9_9J for ; Tue, 16 Apr 2019 13:45:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A43E120169 for ; Tue, 16 Apr 2019 13:45:51 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555447550; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=QQVuIJiO7IU6+jO5EFvVFBS3ahDNy4+HOcKv2vTnYzw=; b=i46qnCcZywe8Iyyk2ikFgK8VL166OV5JvakoHuVjmBUrcroPMJhNheiI ZMIPX0QMjD84yPTxI2ix6XeMbfEgAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555447550; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=QQVuIJiO7IU6+jO5EFvVFBS3ahDNy4+HOcKv2vTnYzw=; b=hnIxlbAB024/QZVcbhw5MFtn/b4nfPc7yTbZFrCuJ+ZJq/jwa+NVinim DNBwqB4K6Ujq82HwuTEFAJOqdcLYcF/m2jxT7jRR+VTcuHt+SZH9wXhc75 x2FIok50GWk9AX9zhMA6Ozfxw9k2XCST33/d6HrpYB6p+9VFxRVFbb1b5N pTmpHyJBXznRNLSHc0mMJwvjxoDn6Q987Iygzfapqo+i55ro3CcCtnUvID BqhQpIG9UGtAi3CHG31jB7AwvIdafFgo5dS1EwhzEIRQdGU8QfjNf+TMKF Ix3tEr52vUSf0kTYfuW5Ku/K5hXNxGajbW9vfWV9v+KEnLVOS7piCw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 20CC1F99D; Tue, 16 Apr 2019 16:45:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5FE5C20262; Tue, 16 Apr 2019 16:45:46 -0400 (EDT) From: Daniel Kahn Gillmor To: ilf , openpgp@ietf.org In-Reply-To: <20190416195614.GH1226@zeromail.org> References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190412201300.GJ1226@zeromail.org> <87ef635hmt.fsf@fifthhorseman.net> <20190416195614.GH1226@zeromail.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 16 Apr 2019 16:45:45 -0400 Message-ID: <87h8ax3chy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 20:45:54 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue 2019-04-16 21:56:14 +0200, ilf wrote: > Daniel Kahn Gillmor: >> I've only seen a few merge requests, and none of them from "ilf" > > Sorry, my Gitlab skills are weak. I created patches but forgot to create= =20 > merge requests. They are now submitted, but unfortunately against the=20 > now-outdated version. I assume that some are fixed, but most should=20 > still work to merge easily. Wow, thanks! I've reviewed and rebased all of those editorial cleanups, and closed the series of merge requests. Much appreciated. > The "Terminology" section sais: > >> "Certificate discovery" is the process whereby a user retrieves an=20 >> OpenPGP certificate based on user ID >> "Certificate update" is the process whereby a user fetches new=20 >> information about a certificate > > IMHO: > >> "Certificate discovery" is the process whereby a user retrieves an=20 >> OpenPGP certificate based on the fingerprint (or key ID) With this proposal, i think you're asking for three distinct changes, all of them interesting, but which i aim to dispose of differently: * you are using the word "retrieve" where i had used either "retrieve" or "fetch". Good catch, i'll use the same word consistently across the definitions. * You're including lookup by key ID, which wasn't previously mentioned. For what this draft defines as certificate update, lookup by key ID would be a mistake (because the client already has access to the fingerprint of the primary key). That said, this identifies a distinct use case, which is retrieval of an unknown certificate based on fingerprint or key ID alone (possibly of subkeys, not just primary keys!), typically at signature verification time, taking its parameter from the Issuer (i.e., keyid) or Issuer Fingerprint (full fingerprint) subpacket from the signature. The section titled "Signature Verification and Non-append-only Keystores" mentions an architectural change (shipping the issuing certificate alongside a signature) that would make this use case unnecessary, but this draft should still call it out explicitly as it will continue to be relevant. I think the next draft will use "certificate discovery" to refer only to this third case, and will rename lookup-by-user-id to "certificate lookup". Does that make sense? * you've conflated looking up a certificate (or a set of candidate certificates) based on their (spoofable) user ID, with retrieving a certificate based on cryptographically-verifiable hash. These two use cases have dramatically different consequences for the architecture of abuse-resistant keystores themselves, which is part of what this draft is trying to tease apart. So i don't think the draft should conflate them. Let me know what you think, or if you have any objections. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLY++gAKCRB2GBllKa5f +JjnAP9C5sqFW89h6+d8YFORWxmim99WjBDUz5zcGrtCbuUpyQD8D6ngYWQqSCs3 RHZbhuooNxcMc4ung1Y1NB5mbDC7JwA= =xZpU -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 16 14:36:59 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71E01201DB for ; Tue, 16 Apr 2019 14:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 C7kaHmpqXM8G for ; Tue, 16 Apr 2019 14:36:56 -0700 (PDT) Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD42120140 for ; Tue, 16 Apr 2019 14:36:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 6DFFE7C97F0 for ; Tue, 16 Apr 2019 23:36:52 +0200 (CEST) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxvlsvTHW8Ux for ; Tue, 16 Apr 2019 23:36:52 +0200 (CEST) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id 379297C979C for ; Tue, 16 Apr 2019 23:36:52 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 8754DBFC91 for ; Tue, 16 Apr 2019 23:36:51 +0200 (CEST) Date: Tue, 16 Apr 2019 23:36:49 +0200 From: ilf To: openpgp@ietf.org Message-ID: <20190416213649.GJ1226@zeromail.org> Mail-Followup-To: openpgp@ietf.org References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190412201300.GJ1226@zeromail.org> <87ef635hmt.fsf@fifthhorseman.net> <20190416195614.GH1226@zeromail.org> <87h8ax3chy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w0nMBknB8iaaAbdO" Content-Disposition: inline In-Reply-To: <87h8ax3chy.fsf@fifthhorseman.net> Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 21:36:59 -0000 --w0nMBknB8iaaAbdO Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks for merging (and rebasing). Daniel Kahn Gillmor: > I think the next draft will use "certificate discovery" to refer only=20 > to this third case, and will rename lookup-by-user-id to "certificate=20 > lookup". Does that make sense? Yes, sounds good to me. (Even if there are other ways of learning about a certificate=20 fingerprint like https://tools.ietf.org/html/draft-mccain-keylist) Thanks for your work! --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --w0nMBknB8iaaAbdO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAly2Su8ACgkQFT/jmIIc g5Q0mhAAtxJ09TODdeemIsmwMCz1QSqwGH8Fz7b5ZaH7Yt9QUj2pU2ugTfcFIlxr CmJ49GfGYpxhkvF+TrlobrlOlG4v6o9EP3VHaPW9ueHVurUV5BT0Q2o1l1valIAo FoQvxZomCtl61dON08O6AymM1iBCRf2KG7xbokUaHOjXYqlMiVaa1fch30J3BtKm 4O9o6HzWbYoXpsd0Ju3lrveyCVI2vBnGjobXJagzyyaj9fSDD2gPf3OSjaTtA3mk YOA5u++WlL2/dm9tr/xGoNf639poZ8euOoN/ZluwOpUJco0VCbD7CdKcWGrlkEKs 4gUnrg+aS2CSH4Wui+xyO+sEJShVLZoebGcxmztXYvu9MhNrLUoaR0eLLVCAoenb /yuC3ojJ4D6th3SGGkQa1kmU42VHap8SeuqoUJ++0iXLnHvzMTI3xiBGzxlhTsHx wVE75r0/+K16MJpZMsuPXXe2H4CzsUGEwmxGHRSFeycq/B/379/yTg331zuHrnGe C6wPd4fVmbTHi/1D1IC9GYQlotfcUzoJclSuCeLDysrqQVYDheEtqCQaIXhbpPor dxLviUWY0z7vecWQVaTw6HC90H+KA14XdmmZJODP/KfCYgsY6r/kHjB9mNgeMxy+ 6MdIp24rez1yLMvTXlvHWmge26hZs2Uw/tTCJCbA+xyaXaF8ECo= =Zg2O -----END PGP SIGNATURE----- --w0nMBknB8iaaAbdO-- From nobody Tue Apr 16 17:06:01 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECB1201A5 for ; Tue, 16 Apr 2019 17:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 vv0SJYqeIvp0 for ; Tue, 16 Apr 2019 17:05:56 -0700 (PDT) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB7F120199 for ; Tue, 16 Apr 2019 17:05:55 -0700 (PDT) Date: Wed, 17 Apr 2019 00:05:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1555459552; bh=KjN+ZFxg7Zvs6CITzBVjkw79RnIRudJm393+eBD2At8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=AyJfTpu1YTkp2Rlnl/QowI5lRWre0Wojw0Ci66UBSBK38ZgdhemdAXHNjxfDgsuPO lyz5A5Po6t3KKcQPbDa+7UCubHtkNV51YV+vxn8clBBHJKx8gOn9piGGmu+FF0xh9y ekif9IuH14S35Omb3Qx6O1chkUk8w2002AIl8npo= To: Jon Callas From: Bart Butler Cc: "openpgp@ietf.org" , Justus Winter , "Neal H. Walfield" , Peter Gutmann Reply-To: Bart Butler Message-ID: In-Reply-To: <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------f46540c63e1032020a1e33e76e3da95e"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 00:05:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------f46540c63e1032020a1e33e76e3da95e Content-Type: multipart/mixed;boundary=---------------------50dd0218b8decb19f6704670d86536e1 -----------------------50dd0218b8decb19f6704670d86536e1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Jon, = =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, April 15, 2019 5:00 PM, Jon Callas wrote= : > = > = > > On Mar 30, 2019, at 9:11 PM, Bart Butler bartbutler=3D40protonmail.com= @dmarc.ietf.org wrote: > = > [...] > = > > > OpenPGP is in general the latter case rather than the former. I beli= eve it=E2=80=99s less important to have strict semantics on failures becau= se it=E2=80=99s usually storage. > > = > > I agree. I would say my point is that with sufficiently small chunks, = the user/decrypter can choose what kind of failure behavior is appropriate= . Large chunks robs the decrypter of that. > = > We are mostly in violent agreement, I do believe. I feel like I'm saying= something like "a quarter is a coin with George Washington on one side an= d an eagle on the other" and you're saying "a quarter is a coin with an ea= gle on one side and George Washington on the other." We're talking about t= he same coin, with a slightly different point of view. > = > I wouldn't use a term like "rob" because that assigns value to the condi= tion. I think there are places where rejection matters and is a Good Thing= . I think there places where it is not a good thing and is even a Bad Thin= g. That's why I was using terms like "strict semantics" and a lot of condi= tionals. > = I said 'rob' because I think fundamentally that the release semantics shou= ld be something that is decided by the decrypter, not the encrypter, as on= ly the decrypter knows what kind of release semantics are safe or not. For= example, I have a 32 MB PGP/MIME message. I want to show a preview in my = email client. If we use 8K chunks, I can read the first chunk, know that i= t hasn't been messed with, and display it safely. If the spec allows a 32 = MB chunk, as an application developer I have some choices: 1. I can load the entire 32 MB and be really slow/bandwidth intensive 2. I can not show a preview for this message 3. I can ignore release semantics and do it anyway, risking the Problem Th= at Shall Not Be Named All of the options are terrible for a UX perspective. Meanwhile, if the ch= unk size is capped, this makes it easy, and if I, as an application develo= per, need strict release semantics for the entire file/message, I can do t= hat too. Now, with your proposal, the other implementations and I can come to some = agreement that hey, we just aren't going to allow chunks meaningfully high= er than the cap, what you call "normative" agreement. That's fine, but I'm= worried that these norms don't tend to be well-documented (I'm not sure t= he MAY in the RFC will be sufficient), and someone somewhere is going to w= rite an implementation at some point which exclusively uses big chunks. Wh= en they do, our implementations will reject them, and then their users wil= l complain to the app developers, who will in turn complain to the impleme= nters. I'm certainly not so arrogant to assume I can anticipate all future needs = here. But I think it's telling that we can come up with several negative c= onsequences of allowing the large chunks and the only benefit is something= that can be achieved at the application layer (or as an option at the imp= lementation layer even) if desired anyway. I also think that forcing no-release semantics via packet structure is mis= guided because app developers/implementors are likely to ignore if it beco= mes too annoying. That is, I anticipate some implementers just allowing so= me kind of unsafe mode that releases plaintext early with no integrity che= cks if this comes up (essentially streaming not along AEAD chunk boundarie= s), and I'm in general uncomfortable with choosing to build a feature whos= e failure case is "massive security hole", not to mention one that we've s= een before with the Problem That Shall Not Be Named. Do we want to allow p= eople to create messages which *cannot* be safely streamed when we have th= e choice not to do this with zero functional downside? Strict release sema= ntics can always be enforced at the implementation or application level. > I don't want to bury my lede any deeper than this. What I'm saying is: > = > - The more you want strict AEAD semantics of no-release, the fewer chu= nks you want. > - It seems to me that the people who most believe in strict AEAD relea= se are also the ones who are arguing for smaller packets. These seem to be= in opposition to each other. I've been confused through this discussion b= ecause the rationales seem in opposition and confused. I don't get it, and= I want to understand; you all are smart people whom I respect, so if I'm = confused, maybe I'm not getting something. This feeling is completely mutual. I respect everyone in this discussion a= nd know that all of you are smart people. I will try to rephrase what I th= ink is the fundamental question here, and it's not what release semantics = should be--those can be enforced in lots of places, and as you said, vary = by use case, which is very compatible with my views. I think the fundament= al question here is this: = *Should we allow creation of valid messages which cannot be streamed and a= ttempt to force strict no-release at the protocol layer?* I think, in the absence of a compelling reason to, the answer to this is a= pretty clear no. > = > We might differ in that I have a nuanced opinion about AEAD rejectio= n. I think that there are places where it matters, and places where you do= n't. For example, in networking, particularly the parts of the network sta= ck where you can easily get a forged packet. You want to reject that packe= t as early as possible. Moreover, these places are always using very small= packets. (I'm going to wave my hand and say that under a megabyte is "ver= y small" for these purposes.) > = > But in archival storage, you don't want to reject something because = there's a media error, you want to recover as much as possible. You might = even be required to do so by law. I have real-world anecdotes if you want = to hear them. > = > On a network, rejection is a good thing. You reply a NAK to the send= er and they retransmit. In archival storage, there's no retransmitting on = a media error. That's the case where it's a Bad Thing, and in fact, it mig= ht even be better to use CFB mode and an MDC than AEAD. It also might not,= and much depends on which AEAD mode one used. > = > Nonetheless, if you believe in strict semantics, you also likely wan= t the fewest number of chunks. If there is more than one chunk, you have t= o stage the output, you have to process everything (unless you're going to= say that the timing side-channel is not important) Why do you have to stage the output in the multi-chunk case? The only diff= erence in the multi-chunk case is that I'd check AEAD tags multiple times = instead of just at the end. There's no reason why I'd have to do anything = with the output differently than a single chunk if I embrace strict no-rel= ease. I could buffer it the exact same way I was buffering the single chun= k and the application/consumer doesn't have to know there is any differenc= e. Fundamentally, multi-chunk just gives you options. There is nothing stoppi= ng an implementation from doing strict no-release. = > = > Sometimes this is not possible. Ironically, the place where it's mos= t possible is in storage, where it's the least needed. In online protocols= , > = > = > > OK, I think this is the part that I don't understand. Why does it matt= er what chunking scheme is used here? If my app requires all-or-nothing se= mantics, I would program my app to enforce that all chunks must pass and n= ot release plaintext unless that happened, with no truncation, etc. So why= would every joint be a vulnerability? > > = > > > > What value does large-chunk AEAD actually provide? What I'm gettin= g from the AEAD Conundrum message is that it's a way for the message encry= pter to leverage the "don't release unauthenticated chunks" prohibition to= force the decrypter to decrypt the whole message before releasing anythin= g. Why do we want to give the message creator this kind of power? Why shou= ld the message creator be given the choice to force her recipient to eithe= r decrypt the entire message before release or be less safe than she would= have been with smaller chunks? > > = > > > Let me summarize the conundrum: If you want strict AEAD no-release s= emantics, you want a fewer number of chunks. > > = > > I guess this is my fundamental question. You can force no-release sema= ntics at the application level for any chunk size scheme, right? > = > Yes, you can, provided that there's a way to report that back, and your = caller checks the return value. You (as an implementation) could just not return the plaintext until the e= ntire message was read. There's nothing stopping implementations from havi= ng a strict no-release mode. > = > I suppose this really means no, you can't force it, because the library = writer can't force the application code to check the error return. Well, the library can always just not return the plaintext if we don't thi= nk it's safe. I just don't think it's the encrypter's business to be decid= ing what is safe or not for the decrypter. > = > I have heard that some issues that we're Not Going To Talk About had amo= ng the issues improper checking GnuPG's report of an MDC failure was an is= sue in at least one place. > = Sure, but this could have been configured as a hard failure. The apps didn= 't configure it as a hard failure because that would have collided with UX= /application concerns, and I fear that that collision will occur again if = we allow it to, with likely the same result. > > > If you respond to a security request with a performance answer, you = literally don=E2=80=99t know what you=E2=80=99re talking about. So let=E2=80= =99s toss that aside. > > = > > I apologize, I was not trying to create a strawman here, but I am comp= letely at a loss for what the benefit of large chunks is. > = > From a standpoint of debate technique, coming up with a strawman makes y= our whole side of it weaker because attacking a strawman is attacking a st= rawman. It makes it look like you don't understand, when you actually have= a different issue. I think it has added to the confusion I have been suff= ering from. The chunk size question is about adjusting security parameters= , and thus when you say, "it won't help performance" I can't help but thin= k that we're not discussing the same thing at all, as I'm talking security= , and you're talking performance. > = > Good to put that to bed. Back to the chunk size debate. > = > I don't know the specific benefits, either. I heard people asking for it= , and I'm defending the idea for them. > = > I believe that an underlying difference between your thinking and mine i= s that you're looking at this as an application writer, and I'm looking at= it like a protocol / API that has many clients, some of whom (and the lar= gest ones) aren't written yet. > = > Moreover, there are a lot of people who use OpenPGP for a lot of things = that we don't know about. As Peter Gutmann pointed out there are a lot of = EDI systems, back ends of financial systems, and so on that internally use= OpenPGP implementations. They're not here. I'm trying to watch out for th= em. > = > There are also people around who want to do something and for a lot of r= easons find it difficult to speak up. I'm not editor any more, Werner is a= nd I have every faith in him. Sometimes, though, old habits die hard. > = I'm sympathetic to all of this, and I don't want to put anyone on the spot= . It would be really great if anyone who has a use case for large chunks s= peaks up though, either through this thread or privately to me, Jon, or an= yone else they feel comfortable speaking with, because I do not want anyon= e's voice to not be heard, and if there is a use case for large chunks I d= o want to hear about it before this decision is finalized. > I tend to see the AEAD packet format as being a successor to the existin= g streaming, indefinite length things. That allows chunking up to 2^30 and= while absurdly large, it has never been an issue. > = Well, except that streaming this old stuff is unsafe if ciphertext modific= ation is a threat. > In my head, I think why not allow up to that, since it would preserve an= yone's weird thing? > = > On the other side, implementers need guidance. Today, the guidance is fo= lklore with all the issues that go with it. It's better not to have folklo= re. But, if we basically said, "do what you're doing today" then we'd be l= ooking at 8K chunks, as that's what GnuPG does today. > = > The clauses I suggested about MAY support larger / MAY give larger the f= inger seemed to be a compromise that would work because it gives you the g= uidance you need; it lets whoever these people are the ability to do what = they want; and lastly should there be a consensus that it needs to be larg= er in the real world, a consensus of implementers can change it without a = new document. It seemed to me that everyone wins. > = For the record, I'm pretty much OK with this, I just think it's opening us= up to future problems that it would be best to avoid. > Yet I thought I perceived that you not only wanted to win, but you wante= d to salt the earth in the other people's territory. Fixing an upper bound= on memory has a long history of Famous Last Words going back to the old c= lich=C3=A9d "640K is more than enough for anyone." The gods punish hubris. I'm sorry I gave that impression or was overly strident. I consider this a= rare opportunity to fix something before it becomes a problem rather than= afterward with a bunch of legacy baggage in tow. I have no interest in "w= inning" this argument for it's own sake--I would be happy to get a counter= -argument for large chunks that made me think "yes, there is a use case an= d that's why we want to risk having these future problems". > = > Okay -- let's sort all this out. I really think we are ALMOST done here. > = > Here's what I stated before. > = > > > (1) MUST support up to chunks. > > > (2) SHOULD support up to chunks, as these are co= mmon.. > > > (3) MAY support larger up to the present very large size. > > > (4) MAY reject or error out on chunks larger than = , but repeating ourselves, SHOULD support . > > = > > > Clauses (3) and (4) set up a sandbox for the people who want very la= rge chunks. They can do whatever they want, and the rest of us can ignore = them.. Why get rid of that? It doesn=E2=80=99t add any complexity to the c= ode. It lets the people who want the huge ones do them in their own enviro= nment and not bother other people. > > = > > > My concern is over (1) and (2) and specifically that there=E2=80=99s= both and sizes. > > = > > > I think that=E2=80=99s an issue. If there are two numbers we are apt= to end up with skew before settling on one, so it=E2=80=99s better to agr= ee on just one. That=E2=80=99s the real wart in my proposal. > > = > > I'm OK with eliminating (2) and just using the MAY part to take care o= f any legacy 256K messages OpenPGP.js users might have. As I said, we don'= t have any of these messages in production yet and I'd err on the side of = a cleaner spec. > = > Me too. I think saying 256K is fine. I have an intuition it ought to be = at least as large as the largest Jumbo Frame, and that's 9K so round to 16= K. Let me restate the proposal. > = > (1) MUST support up to chunks. > (3) MAY support larger up to the present very large size. > (4) MAY reject or error out on chunks larger than > = > And it seems that 256K is the proposal for . Are we agreed o= n all that? > = As some respondents would like 8K or 16K, I'm fine with doing that instead= of 256K. I would like to check with the maintainers of our libraries to f= ind out if there's any reason I'm ignoring that would favor one or the oth= er before committing though. > > I just really want to understand the benefit of large chunks for secur= ity and right now I clearly do not. > = > If you believe that no-release is a Good Thing, then you want fewer chun= ks, ideally only 1 chunk. That's it. That's the ONLY reason. > I think I discussed this to death above so I won't add to the word count h= ere. -Bart > I believe that no-release can be a Good Thing, but rarely is for OpenPGP= 's primary use case. As I said in my other missive, I don't think that it'= s even possible in the general case. Networking packets, yes -- both possi= ble and desirable. Files, no -- neither possible nor desirable. > = > Jon -----------------------50dd0218b8decb19f6704670d86536e1-- -----------------------f46540c63e1032020a1e33e76e3da95e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAly2bdsACgkQmQVEZe8zHkQ9qQEA7M5GlT7AusaDml9P2qaD lQ0Kf9vSu2Rby5hc/EjImaAA/1o52p76b4e12O50aNEkleugD0Ib4STrnfVk 31AXh6IM =eRZv -----END PGP SIGNATURE----- -----------------------f46540c63e1032020a1e33e76e3da95e-- From nobody Tue Apr 16 21:31:49 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF21B120073 for ; Tue, 16 Apr 2019 21:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=TmcbpROt; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=oD16uCVF 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 uKVNfwpACLhF for ; Tue, 16 Apr 2019 21:31:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D11C120047 for ; Tue, 16 Apr 2019 21:31:46 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555475505; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gstfNMN2LpjD96e4mHusEnzXWHwfOw4Dh6KpiiPwhKQ=; b=TmcbpROt9dzL9Y+kYSZvycqEbxKtcqhnMe6BzgPHKH3pxMLpGWbdOwV6 H90szAdyDfWFsJFe5EBIh215/wq8AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555475505; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gstfNMN2LpjD96e4mHusEnzXWHwfOw4Dh6KpiiPwhKQ=; b=oD16uCVF2Q/nFj9skYOntn9SCwVCh3kyoSTRNRV3W03A1CJH9GZUg81L XFXGIwCyqyYar32gKgtz8p2P+/l5Emgqu5pWOABooxo1n7rQsXnJQ1Ze/U JpbGAmIGnwaUWuM+gUn0FGVSJqbr/pP8T9JTT1I2pJLKMCqsNcvBMcEmeT E5AXHiqB4sCtQGs+o6ftuiF9NZ/bFnmtFdJ9Yn+1kUNsO+0dwdI0bU/OsV 3X5VrzTWs6mIK8bLbJdNS5U5UAQ5X9+3PmMmhdeGEotFHTbxI5QxTSIXBd qIPIWLjq/FMUA7iFk9H7tNygVQIV4J0HHJMPNuKTXQNCrK+qQteUmQ== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id ECE70F99F; Wed, 17 Apr 2019 00:31:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B8524204D2; Wed, 17 Apr 2019 00:30:04 -0400 (EDT) From: Daniel Kahn Gillmor To: ilf , openpgp@ietf.org In-Reply-To: <20190416213649.GJ1226@zeromail.org> References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190412201300.GJ1226@zeromail.org> <87ef635hmt.fsf@fifthhorseman.net> <20190416195614.GH1226@zeromail.org> <87h8ax3chy.fsf@fifthhorseman.net> <20190416213649.GJ1226@zeromail.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 17 Apr 2019 00:30:04 -0400 Message-ID: <87pnpl1cfn.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 04:31:48 -0000 On Tue 2019-04-16 23:36:49 +0200, ilf wrote: > (Even if there are other ways of learning about a certificate > fingerprint like https://tools.ietf.org/html/draft-mccain-keylist) That's discussed in the draft (in git) as a form of "certificate lookup" -- though i think it's interesting that keylist doesn't include a user ID field. Maybe that's something we should encourage Miles, Micah, and Nat to include there. --dkg From nobody Thu Apr 18 10:28:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D36712015E for ; Thu, 18 Apr 2019 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TO_EQ_FM_DIRECT_MX=2.499] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 Yt4RwT3i3KHb for ; Thu, 18 Apr 2019 10:28:40 -0700 (PDT) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DEA1201BB for ; Thu, 18 Apr 2019 10:28:40 -0700 (PDT) Date: Thu, 18 Apr 2019 17:28:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1555608517; bh=gl1uk/9KZtF/ZJlmi4fyNJuZMtZF2N6pLTsGFR5sYvg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=fH33YHIYitbhCX8iuDKY2Iiufg/0Hle0hLTUFU/5G/atelZkqhPP9TWgSIVtzk0hp TtgIi+dlJ0oSwBRKiE0o89TUkOtupCuGblRRvaowP+cD9pNgS6A2fUFR8NCJ/kHAT1 BrTJWg9kdx0+tawV0tVg58uPH0pxBj7MbuOgYZNI= To: Bart Butler From: Bart Butler Cc: "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------ed2ecb7f806cab1b589486d3d2a10432"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 17:28:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------ed2ecb7f806cab1b589486d3d2a10432 Content-Type: multipart/mixed;boundary=---------------------5fe294b3743c1cd17f2b20d9ea5a7b5a -----------------------5fe294b3743c1cd17f2b20d9ea5a7b5a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi all, Jon and I got on the phone today and discussed the AEAD chunk situation a = little more. The compromise we reached is: (1) MUST support chunks up to and including 8KiB. (2) SHOULD NOT emit chunks larger than 8KiB. (3) SHOULD reject chunks larger than 8KiB. Jon likes this because it doesn't fully shut the door on experimentation. = I like this because it strengthens the norm and puts the burden of justifi= cation for violating the norm on the person asking for huge chunks rather = than the implementer. I expect (though please correct me if not) that Dere= k, Neil, and others working on embedded or otherwise constrained system wi= ll like this because the normative limit is low enough for most embedded/c= onstrained systems to do streaming when incremental no-release semantics a= re desired. And I hope Werner likes this because GnuPG is already doing 8K= iB chunks, so the work involved in changing GnuPG's implementation should = be minimal :) Does anyone have any objections to or comments regarding this language? Thanks, Bart -----------------------5fe294b3743c1cd17f2b20d9ea5a7b5a-- -----------------------ed2ecb7f806cab1b589486d3d2a10432 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAly4s68ACgkQmQVEZe8zHkQX9QD/Q2urhClhnSgwZVpTQNc9 26dt5E9oJyjZj3zi37dmTrIBANW5Bpqri13Y3St8yVeU1cE+LJ2Hz97OPcTh sK1oiSMC =ECnv -----END PGP SIGNATURE----- -----------------------ed2ecb7f806cab1b589486d3d2a10432-- From nobody Thu Apr 18 10:41:31 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D2E120346 for ; Thu, 18 Apr 2019 10:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com 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 RE0CtqQExY18 for ; Thu, 18 Apr 2019 10:41:27 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E2F120383 for ; Thu, 18 Apr 2019 10:41:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A8645E2040; Thu, 18 Apr 2019 13:41:25 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13074-09; Thu, 18 Apr 2019 13:41:23 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id F3C8BE2042; Thu, 18 Apr 2019 13:41:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1555609283; bh=vbK8/ZhXAtt9J2uvLUNWSx08bLivG6ctJ7oAfSUGVts=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=cyu5N2XH5dSKcwKojuFLbb80Lptm0YtKQ+mbXJo2y/4zHS8pZ4rjk27YSGSc5Gh4a doMVJaXCzD81qHbz4g4kvCdMLs6devR9X+SSqp4aNxXJisNXXLd90hfd628EOBCrXg 4+Fc/ShdmhnbbtNKlAj3TNFyEnPUELOgWgO3R/q4= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 18 Apr 2019 13:41:22 -0400 Message-ID: In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> Date: Thu, 18 Apr 2019 13:41:22 -0400 From: "Derek Atkins" To: "Bart Butler" Cc: "openpgp@ietf.org" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 17:41:29 -0000 No objections from me! Thanks Bart! -derek On Thu, April 18, 2019 1:28 pm, Bart Butler wrote: > Hi all, > > Jon and I got on the phone today and discussed the AEAD chunk situation a > little more. The compromise we reached is: > > (1) MUST support chunks up to and including 8KiB. > (2) SHOULD NOT emit chunks larger than 8KiB. > (3) SHOULD reject chunks larger than 8KiB. > > Jon likes this because it doesn't fully shut the door on experimentation. > I like this because it strengthens the norm and puts the burden of > justification for violating the norm on the person asking for huge chunks > rather than the implementer. I expect (though please correct me if not) > that Derek, Neil, and others working on embedded or otherwise constrained > system will like this because the normative limit is low enough for most > embedded/constrained systems to do streaming when incremental no-release > semantics are desired. And I hope Werner likes this because GnuPG is > already doing 8KiB chunks, so the work involved in changing GnuPG's > implementation should be minimal :) > > Does anyone have any objections to or comments regarding this language? > > Thanks, > > Bart_______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 18 11:21:15 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B328112001B for ; Thu, 18 Apr 2019 11:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 IDf55JL9o3RO for ; Thu, 18 Apr 2019 11:21:09 -0700 (PDT) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6927D120301 for ; Thu, 18 Apr 2019 11:21:08 -0700 (PDT) Date: Thu, 18 Apr 2019 18:21:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1555611665; bh=n2b44z9HWpECaJ0Gd6ajsEiwJMC5ysiLdul5X//5LCY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=crMwHP47+O4L44yWJG+G0Z0wJE2CuuDOcROvDJcc7ZqIfWiyefHdkq5Gfybqhgb6y z2wccv6TM/b4M15oVAu0ke9d3zNz15+THZMk7z76JySm6SMbL4FTgK4ouBWXmehov8 Pn4biliGyXV2MIJfNGkCq6a49oyFL9Qia4Vblqfo= To: Wiktor Kwapisiewicz From: Bart Butler Cc: "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: References: Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------433cd1988b5bfdc802ae05afa20b2df7"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory and advanced lookup method X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 18:21:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------433cd1988b5bfdc802ae05afa20b2df7 Content-Type: multipart/mixed;boundary=---------------------ededb2f3de8ad9d1ac0a702c178e2ec5 -----------------------ededb2f3de8ad9d1ac0a702c178e2ec5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Wiktor, This is a good point and I do not think it's been discussed before. The re= ason WKD can't use the TXT record is that browsers can't look up TXT recor= ds, all they can do is try to resolve domains. I'd say that this is less of an attack vector and more of a 'mischief' vec= tor, and that public suffixes can easily protect themselves if it ever bec= omes an issue. WKD client implementations can also use the public suffix l= ist themselves to prevent the problem--a quick search yields libraries for= lots of platforms. Maybe this would be a reasonable suggestion to add to = the RFC, but it also doesn't seem critical to me. Cheers, Bart =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, April 15, 2019 11:02 AM, Wiktor Kwapisiewicz wrote: > Hello, > = > I'd like to ask about the (potential) issue with advanced lookup method > in WKD. > = > For those that don't remember what it is it converts e-mail (such as > "Joe.Doe@Example.ORG") into a URL that uses "openpgpkey" subdomain of > the e-mail domain (in this case > "https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy= 9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe"). > [0] > = > There are some domains that allow users to register subdomains with any > name the user requests (with some exceptions). For example "github.io". > So if a user selects "openpgpkey" as a name and thus will be able to > host files under the ".well-known" directory they will effectively > intercept all WKD queries for e-mail addresses for that domain. > = > That is query for key for "security@github.io" will go to the user that > registers "openpgpkey" name. > = > The problem of domains under which Internet users can directly register > names also exists in browsers. To avoid various security issues w.r.t. > supercookies Mozilla manages Public Suffix List [1] that is used by all > major browsers. The list is quite big [2]. > = > I did take a look at MTA-STS [3] as it also uses subdomain but in > MTA-STS's case they first start with DNS TXT record query and only then > query mta-sts subdomain so mere registration of subdomain wouldn't > trigger MTA-STS. > = > I don't want to suggest any fixes to the spec just inquire if you think > it's a real issue or rather a quite obscure edge case. > = > Thank you for your time! > = > Kind regards, > Wiktor > = > [0]: > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section= -3.1 > = > [1]: https://publicsuffix.org/ > = > [2]: https://github.com/publicsuffix/list/blob/master/public_suffix_list= .dat > = > [3]: https://tools.ietf.org/html/rfc8461 > = > ------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= ------------------------ > = > https://metacode.biz/@wiktor > = > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------ededb2f3de8ad9d1ac0a702c178e2ec5-- -----------------------433cd1988b5bfdc802ae05afa20b2df7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAly4wAwACgkQmQVEZe8zHkSrSAEAhF8OKiCuI/1oRnaOhDaE HEdO6beCCRpzIWnvSJAcHnsA/jUeAvB8rr1oRVu6EOppYY/Hb7iRUnVMI3lE KOG4kJEJ =hJry -----END PGP SIGNATURE----- -----------------------433cd1988b5bfdc802ae05afa20b2df7-- From nobody Thu Apr 18 13:27:54 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE54120306 for ; Thu, 18 Apr 2019 13:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 Bob7fSGbxvY2 for ; Thu, 18 Apr 2019 13:27:50 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D31B120131 for ; Thu, 18 Apr 2019 13:27:49 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id d13so2896294edr.5 for ; Thu, 18 Apr 2019 13:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to; bh=Z0sDOGgMcSsCQFDP1T+mZPJpRCc/g15thcuGOLCSsZ4=; b=zA0jdhpNOG81wqDxX6RaBtisIiMvDGbgPVb0GCAC/oknQL7KBFrVkXJrLNQDiWQF0F h8BKy/xjm4z1rtfH++yoRnZM/snXvt1HZv8ZgGUuMvxssspdiOrurFTWSEVYNulK2ycU JdF+YacTiSK2pv/mkmv46LjzshirUedPm7P0DUe7s7g44NrV3ljDVsDXLfUm+vDBCBGM l/B0kcRIuQWSVwTZXbtQgVL5oU5wimuz272sPR0bTI/XrAdbG4thZVlOIRy8Fydkidmb ouFicVeJxtBxaVE4D+Tn74pasURyBewxgn8IFzxCiy8cD6HG79Ye1B15yKLY9Q4+cL91 IRQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to; bh=Z0sDOGgMcSsCQFDP1T+mZPJpRCc/g15thcuGOLCSsZ4=; b=K9rL5skQxcDomn6nwURXSG3vG9W53vNhGK+qPoM8cRqvU98i4iztcpptLnjPWgOJZJ ucKAeRMAhbEbBZLZAIXI3kvlTwTyg6OBxqbYIV1t1eKs7JTM11gzU4EfP/T0XAk424uN ShSEFUl5Y9T2Q5OJEQP52II490bpUxnviVtjWhnRmNgciQqH3tZeXBS4UtUTmWqFfbcM gezslVhVS1YPwNZ0WjGovrK28scraqXa+FhzlTy+RfqAJVqcSVvbGqlCQbKq57OTo6Ak G2UV55zzRgBQkAE1N8yrVqrrzs/tuZLKN4khDtfmUyILyjp04Kx2TnTi9iotJeP+TY0c 3weQ== X-Gm-Message-State: APjAAAVFK9+4mqlSbRIHBQGIJNaj0Ivl6kU/7lEPKffwFMZSI7/a+TVa a8Zl5FHSKXPvrw0Kk/JZn65Qv4xAX6CVBg== X-Google-Smtp-Source: APXvYqxyu/oZpJIkJ4IfmWc4HeLjUnsBXt3BbdxJgrVY4QDXEJgEZB51nED4XxB/gU9VlLPhLMQDrg== X-Received: by 2002:a50:9974:: with SMTP id l49mr1499054edb.63.1555619267985; Thu, 18 Apr 2019 13:27:47 -0700 (PDT) Received: from ?IPv6:2a01:11bf:318:9400:ac89:af77:b02e:25cb? ([2a01:11bf:318:9400:ac89:af77:b02e:25cb]) by smtp.googlemail.com with ESMTPSA id r14sm760861edd.87.2019.04.18.13.27.45 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 13:27:46 -0700 (PDT) To: Bart Butler Cc: "openpgp@ietf.org" References: From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: <083fd6b7-6f8f-bed9-6666-6dddae121656@metacode.biz> Date: Thu, 18 Apr 2019 22:27:19 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O0YieGhVctkByaTibVLPQ7RkzPa69Mtf8" Archived-At: Subject: Re: [openpgp] Web Key Directory and advanced lookup method X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 20:27:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O0YieGhVctkByaTibVLPQ7RkzPa69Mtf8 Content-Type: multipart/mixed; boundary="gt0SWzM9XQSxpzKyTYm4qk1kPMsOk633L"; protected-headers="v1" From: Wiktor Kwapisiewicz To: Bart Butler Cc: "openpgp@ietf.org" Message-ID: <083fd6b7-6f8f-bed9-6666-6dddae121656@metacode.biz> Subject: Re: [openpgp] Web Key Directory and advanced lookup method References: In-Reply-To: --gt0SWzM9XQSxpzKyTYm4qk1kPMsOk633L Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Bart, On 18.04.2019 20:21, Bart Butler wrote: > This is a good point and I do not think it's been discussed before. The= reason WKD can't use the TXT record is that browsers can't look up TXT r= ecords, all they can do is try to resolve domains. Oh, I was not suggesting adding TXTs - believe me I'd like to have a=20 good Web compatibility too (that's why I asked about CORS previously,=20 and well... added support for WKD to OpenPGP.js :). > I'd say that this is less of an attack vector and more of a 'mischief' = vector, and that public suffixes can easily protect themselves if it ever= becomes an issue. WKD client implementations can also use the public suf= fix list themselves to prevent the problem--a quick search yields librari= es for lots of platforms. Maybe this would be a reasonable suggestion to = add to the RFC, but it also doesn't seem critical to me. Got it, thank you for your remarks! I was thinking about using just the=20 bare domain lookup (without subdomain) that avoids the issue altogether. = And if someone wants to delegate hosting keys to someone else adding=20 permanent redirect in HTTP server is usually simple (Nginx example): location ~ /.well-known/openpgpkey/(.*) { return 301 https://example.com/.well-known/openpgpkey/$1; } Kind regards, Wiktor P.S. I'm eagerly waiting for ProtonMail to add support for WKD too! :) --=20 https://metacode.biz/@wiktor --gt0SWzM9XQSxpzKyTYm4qk1kPMsOk633L-- --O0YieGhVctkByaTibVLPQ7RkzPa69Mtf8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJyBAEBCABcFiEEWaKd6o03OIxlaGPfuXoe4J20F+wFAly43a0pGGh0dHBzOi8v bWV0YWNvZGUuYml6L0B3aWt0b3Ivb3BlbnBncC9rZXkUHHdpa3RvckBtZXRhY29k ZS5iaXoACgkQuXoe4J20F+woZBAAh7arWdaAvq+YHs7bUp+nm/oyF9z3fAKYz8oJ 08TXJ0m8IP/ujGrzh+F3gKVuivfeMiFux9K65SxM+pESdr1RD0qM79qJXvFwKXvs Lf9wJzttP/IefoahxpW7MB5vLeyE4XJFFcaWPyCVEGpbd3q/HidzXGjPKsWjJ/SO Oh9nTshjaW8tZyAT/5aYcfgcvoqDJiDhnVSlRxx0g+tIwwN8zdn/tSaarnmBD+mJ sUtxldorCJbIRHMJwMVnwTpelVM2ukJGikhap+HXcXzLcDA9hzeSFckNkWW20yYN 94Twg3Qprf1B+fwMTuFyDHW2hsA+xturcXFQGAIR6gXeBbSQ/cx/4KfHrpFIYZ96 oEDkfXSqbuTQqvv089v6tFfxx/5IvOfokEV5zVsOV48H9ZYBQ46plJuPo1xaelL7 puioAL/UY8XtKLMeFsGuD+XRrxmlQpU84rPz1wi3TRT3MxnMKjF6p0XwbTr7Bf+0 BhxM8nEZTWCDHHFFrPK+1j8TF0lGmY9FKXfzTl28UPXtQy1iKbNIcBMjcjwyFmMd wlA45Zt3CB2/XUTfl8iYTzJqx/0CAOOPPjsXMXJdRBB8V0qBWCTFcZ0OxITLp5NH eo/z37aAFafToR+Uxc6yjzz+/mltHWXcaArSJrbt4fP8zB8GXzPGrGPtdNay+Q2p WoEXGmc= =EIqg -----END PGP SIGNATURE----- --O0YieGhVctkByaTibVLPQ7RkzPa69Mtf8-- From nobody Thu Apr 18 23:50:18 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D91B1202A7 for ; Thu, 18 Apr 2019 23:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=KZN1BRUh; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=XDeHA3Qx 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 NLQxlqhjHc2D for ; Thu, 18 Apr 2019 23:50:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDBE12010D for ; Thu, 18 Apr 2019 23:50:00 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555656599; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=q+gReLEtwKXXjT4HIPidIWeZgoYdgZOalLNXRWmQR7g=; b=KZN1BRUhi8YQlzgHjlziLbJVmYdRk4ccxIxSG9Uu5O1z7IIDYFgLqokR wuODWzgEedkDQVdjchquQXqoE2vfDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555656598; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=q+gReLEtwKXXjT4HIPidIWeZgoYdgZOalLNXRWmQR7g=; b=XDeHA3Qxm6LsKvvz/9mwX+u5FRVxbdfq2FYmIsfpwaVxr8NgtoYaEn2m VGYuIW+7gDozV9cNSr9LoeNl6mdQ5ghX30yYtwTWc2u/IygNAPJ8Re0kmb H7CQdHA2b9LW5DC2WsawyKptL+XWGBjVwkNK8KsnHFhs8u7ANwfMmAP+G3 J0l3RKeNFI22nUH7A+HqMnrmWmQRjUHCq4C9Dimzl1LQ6/E2k0mlpmHFFg tPSiSvsLTpE9TJ2RLrGJfYyyU9vlRYvJ87fESS9633k5WMN1bpUaiw71Jg o0sHmzjWIONoaTzjDmj6n/J3ukfcWoXAVWYVXWbxInQa1Ff4gtQrVQ== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id A12D2F99E; Fri, 19 Apr 2019 02:49:57 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 64ED5202AF; Fri, 19 Apr 2019 02:49:55 -0400 (EDT) From: Daniel Kahn Gillmor To: ilf , openpgp@ietf.org In-Reply-To: <87h8ax3chy.fsf@fifthhorseman.net> References: <87v9zt2y2d.fsf@fifthhorseman.net> <20190412201300.GJ1226@zeromail.org> <87ef635hmt.fsf@fifthhorseman.net> <20190416195614.GH1226@zeromail.org> <87h8ax3chy.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 19 Apr 2019 02:49:54 -0400 Message-ID: <87d0lizdyl.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 06:50:15 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue 2019-04-16 16:45:45 -0400, Daniel Kahn Gillmor wrote: > I think the next draft will use "certificate discovery" to refer only > to this third case, and will rename lookup-by-user-id to "certificate > lookup". Does that make sense? I've just released version 03, which makes this change, and also adds more nuance related to the ecosystem around keystores and how that might have to change in the face of abuse-resistant keystores. Identifying and naming this distinct interface helped to surface another attack, fingerprint flooding, which is also now documented. The new version is here: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03 From=20the document's changelog: substantive changes between -02 and -03: * new sections: * Keystore Interfaces * Keystore Client Best Practices * Certificate Generation and Management Best Practices * rename "certificate discovery" to "certificate lookup" * redefine "certificate discovery" to refer to lookup by signing (sub)key * new attack: fingerprint flooding * new retrieval-time mitigations -- tighter filters on discovery and update * recommend in-band certificates where possible to avoid discovery and loo= kup * new privacy considerations: * distinct keystore interfaces * certificate update * certificate discovery * certificate validation * more nuance about unhashed subpacket filtering =20 I really appreciate the feedback i've gotten in the course of this writeup, and welcome more. In particular, if someone has any pointers to how to think about e-mail address canonicalization within an OpenPGP User ID (which is a UTF-8 string), especially in the context of IDN and non-ASCII local-parts (does this mean RFC2047-decoding or encoding?) i'd love to see some pointers (or even better, proposed text). The full text of the markdown source for -03 is attached below. --dkg --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=draft-dkg-openpgp-abuse-resistant-keystore.md Content-Transfer-Encoding: quoted-printable =2D-- title: Abuse-Resistant OpenPGP Keystores docname: draft-dkg-openpgp-abuse-resistant-keystore-03 date: 2019-04-19 category: info ipr: trust200902 area: int workgroup: openpgp keyword: Internet-Draft stand_alone: yes pi: [toc, sortrefs, symrefs] author: - ins: D. K. Gillmor name: Daniel Kahn Gillmor org: American Civil Liberties Union street: 125 Broad St. city: New York, NY code: 10004 country: USA abbrev: ACLU email: dkg@fifthhorseman.net informative: RFC4366: RFC5322: RFC6960: RFC6962: RFC7929: I-D.shaw-openpgp-hkp: I-D.koch-openpgp-webkey-service: I-D.mccain-keylist: SKS: target: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home title: SKS Keyserver Documentation author: - name: Yaron Minsky ins: Y. Minsky org: SKS development team - name: Kristian Fiskerstrand ins: K. Fiskerstrand org: sks-keyservers.net pool operator - name: Phil Pennock ins: P. Pennock date: 2018-03-25 GnuPG: target: https://www.gnupg.org/documentation/manuals/gnupg.pdf title: Using the GNU Privacy Guard author: name: Werner Koch ins: W. Koch org: GnuPG development team date: 2019-04-04 MAILVELOPE-KEYSERVER: target: https://github.com/mailvelope/keyserver/ title: Mailvelope Keyserver author: name: Thomas Obernd=C3=B6rfer ins: T. Obernd=C3=B6rfer AUTOCRYPT: target: https://autocrypt.org/ title: Autocrypt - Convenient End-to-End Encryption for E-Mail author: - name: Vincent Breitmoser ins: V. Breitmoser - name: Holger Krekel ins: H. Krekel - name: Daniel Kahn Gillmor ins: D. K. Gillmor DEBIAN-KEYRING: target: https://keyring.debian.org/ title: Debian Keyring author: name: Jonathan McDowell ins: J. McDowell org: Debian TOR: target: https://www.torproject.org/ title: The Tor Project PARCIMONIE: target: https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ title: Parcimonie author: name: Intrigeri PGP-GLOBAL-DIRECTORY: target: https://keyserver.pgp.com/vkd/VKDVerificationPGPCom.html title: PGP Global Directory Key Verification Policy date: 2011 author: org: Symantec Corporation MONKEYSPHERE: target: https://web.monkeysphere.info/ title: Monkeysphere author: - name: Daniel Kahn Gillmor ins: D. K. Gillmor - name: Jameson Rollins ins: J. Rollins KEY-TRANSPARENCY: target: https://keytransparency.org/ title: Key Transparency, a transparent and secure way to look up public= keys author: - name: Gary Belvin ins: G. Belvin org: Google - name: Ryan Hurst ins: R. Hurst org: Google CONIKS: target: https://coniks.cs.princeton.edu/ title: CONIKS Key Management System author: - name: Edward Felten ins: E. Felten org: Princeton University - name: Michael Freedman ins: M. Freedman org: Princeton University - name: Marcela Melara ins: M. Melara org: Princeton University - name: Aaron Blankstein ins: A. Blankstein org: Princeton University - name: Joseph Bonneau ins: J. Bonneau org: Stanford University/Electronic Frontier Foundation BITCOIN: target: https://bitcoin.org/ title: Bitcoin UNICODE-NORMALIZATION: target: https://unicode.org/reports/tr15/ title: Unicode Normalization Forms date: 2019-02-04 author: name: Ken Whistler ins: K. Whistler org: Unicode Consortium normative: RFC2047: RFC2119: RFC4880: RFC8174: I-D.ietf-openpgp-rfc4880bis: =2D-- abstract OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores. Unfortunately, since many keystores permit any third-party to add a certification with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. Furthermore, keystores that are searched by user ID or fingerprint can be made unusable for specific searches by public submission of bogus certificates. And finally, keystores open to public submission can also face simple resource exhaustion from flooding with bogus submissions, or legal or other risks from uploads of toxic data. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various attacks, and the implications of these concerns and mitigations for the rest of the OpenPGP ecosystem. =2D-- middle Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements Language =2D-------------------- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here. Terminology =2D---------- * "OpenPGP certificate" (or just "certificate") is used interchangeably with {{RFC4880}}'s "Transferable Public Key". The term "certificate" refers unambiguously to the entire composite object, unlike "key", which might also be used to refer to a primary key or subkey. * An "identity certification" (or just "certification") is an {{RFC4880}} signature packet that covers OpenPGP identity information -- that is, any signature packet of type 0x10, 0x11, 0x12, or 0x13. Certifications are said to (try to) "bind" a primary key to a User ID. * The primary key that makes the certification is known as the "issuer". The primary key over which the certification is made is known as the "subject". * A "first-party certification" is issued by the primary key of a certificate, and binds itself to a user ID in the certificate. That is, the issuer is the same as the subject. This is sometimes referred to as a "self-sig". * A "third-party certification" is a made over a primary key and user ID by some other certification-capable primary key. That is, the issuer is different than the subject. (The elusive "second-party" is presumed to be the verifier who is trying to interpret the certificate) * All subkeys are bound to the primary key with an {{RFC4880}} Subkey Binding Signature. Some subkeys also reciprocate by binding themselves back to the primary key with an {{RFC4880}} Primary Key Binding Signature. The Primary Key Binding Signature is also known as a "cross-signature" or "cross-sig". * A "keystore" is any collection of OpenPGP certificates. Keystores typically receive mergeable updates over the course of their lifetime which might add to the set of OpenPGP certificates they hold, or update the certificates. * "Certificate validation" is the process whereby a user decides whether a given user ID in an OpenPGP certificate is acceptable for use. For example, if the certificate has a user ID of `Alice ` and the user wants to send an e-mail to `alice@example.org`, the mail user agent might want to ensure that the certificate is valid for this e-mail address before encrypting to it. Some clients may rely on specific keystores for certificate validation, but some keystores (e.g., {{SKS}}) make no assertions whatsoever about certificate validity, and others offer only very subtle guarantees. See {{certificate-validation}} for more details. * "Certificate lookup" refers to the retrieval of a set of certificates from a keystore based on the user ID or some substring match of the user ID. See {{certificate-lookup}} for more details. * "Certificate update" refers to retrieval of a certificate from a keystore based on the fingerprint of the primary key. See {{certificate-update}} for more details. * "Certificate discovery" refers to the retrieval of a set of certificates from a keystore based on the fingerprint or key ID of any key in the certificate. See {{certificate-discovery}} for more details. * A "keyserver" is a particular kind of keystore, typically a means of publicly distributing OpenPGP certificates or updates to them. Examples of keyserver software include {{SKS}} and {{MAILVELOPE-KEYSERVER}}. One common HTTP interface for keyservers is {{I-D.shaw-openpgp-hkp}}. * A "synchronizing keyserver" is a keyserver which gossips with other peers, and typically acts as an append-only log. Such a keyserver is typically useful for certificate lookup, certificate discovery, and certificate update (including revocation information). They are typically *not* useful for certificate validation, since they make no assertions about whether the identities in the certificates they server are accurate. As of the writing of this document, {{SKS}} is the canonical synchronizing keyserver implementation, though other implementations exist. * An "e-mail validating keyserver" is a keyserver which attempts to verify the identity in an OpenPGP certificate's user ID by confirming access to the e-mail account, and possibly by confirming access to the secret key. Some implementations permit removal of a certificate by anyone who can prove access to the e-mail address in question. They are useful for certificate lookup based on e-mail address and certificate validation (by users who trust the operator), but some may not be useful for certificate update or certificate discovery, since a certificate could be simply replaced by an adversary who also has access to the e-mail address in question. {{MAILVELOPE-KEYSERVER}} is an example of such a keyserver. * "Cryptographic validity" refers to mathematical evidence that a signature came from the secret key associated with the public key it claims to come from. Note that a certification may be cryptographically valid without the signed data being true (for example, a given certificate with the user ID `Alice ` might not belong to the person who controls the e-mail address `alice@example.org` even though the self-sig is cryptographically valid). In particular, cryptographic validity for user ID in a certificate is typically insufficient evidence for certificate validation. Also note that knowledge of the public key of the issuer is necessary to determine whether any given signature is cryptographically valid. Some keyservers perform cryptographic validation in some contexts. Other keyservers (like {{SKS}}) perform no cryptographic validation whatsoever. * OpenPGP revocations can have "Reason for Revocation" (see {{RFC4880}}), which can be either "soft" or "hard". The set of "soft" reasons is: "Key is superseded" and "Key is retired and no longer used". All other reasons (and revocations that do not state a reason) are "hard" revocations. See {{revocations}} for more detail. Problem Statement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OpenPGP keystores that handle submissions from the public are subject to a range of attacks by malicious submitters. This section describes five distinct attacks that public keystores should consider. The rest of the document describes some mitigations that can be used by keystores that are concerned about these problems but want to continue to offer some level of service for certificate lookup, certificate update, certificate discovery, or certificate validation. Certificate Flooding {#certificate-flooding} =2D------------------- Many public keystores (including both the {{SKS}} keyserver network and {{MAILVELOPE-KEYSERVER}}) allow anyone to attach arbitrary data (in the form of third-party certifications) to any certificate, bloating that certificate to the point of being impossible to effectively retrieve. For example, some OpenPGP implementations simply refuse to process certificates larger than a certain size. This kind of Denial-of-Service attack makes it possible to make someone else's certificate unretrievable from the keystore, preventing certificate lookup, discovery, or update. In the case of a revoked certificate that has been flooded, this potentially leaves the client of the keystore with the compromised certificate in an unrevoked state locally because it was unable to fetch the revocation information. Additionally, even without malice, OpenPGP certificates can potentially grow without bound. User ID Flooding {#user-id-flooding} =2D--------------- Public keystores that are used for certificate lookup may also be vulnerable to attacks that flood the space of known user IDs. In particular, if the keystore accepts arbitrary certificates from the public and does no verification of the user IDs, then any client searching for a given user ID may need to review and process an effectively unbounded set of maliciously-submitted certificates to find the non-malicious certificates they are looking for. For example, if an attacker knows that a given system consults a keystore looking for certificates which match the e-mail address `alice@example.org`, the attacker may upload hundreds or thousands of certificates containing user IDs that match that address. Even if those certificates would not be accepted by a client (e.g., because they were not certified by a known-good authority), the client typically still has to wade through all of them in order to find the non-malicious certificates. If the keystore does not offer a lookup interface at all (that is, if clients cannot search it by user ID), then user ID flooding is of less consequence. Fingerprint Flooding {#fingerprint-flooding} =2D------------------- A malicious actor who wants to render a certificate unavailable for update may generate an arbitrary number of OpenPGP certificates with the targeted primary key attached as a subkey. If they can convince a keystore to accept all of those certificates, and the keystore returns them by subkey match during certificate update, then the certificate update client will need to spend an arbitrary amount of bandwidth and processing power filtering out the irrelevant data, and may potentially give up before discovering the certificate of interest. A malicious actor may also want to confuse a certificate discovery request that was targeted at a particular subkey, by binding that subkey to multiple bogus certificates. If these bogus certificates are ingested and redistributed by the keystore, then a certificate discovery client may receive a set of certificates that cannot be adequately distinguished. Keystore Flooding {#keystore-flooding} =2D---------------- A public keystore that accepts arbitrary OpenPGP material and is append-only is at risk of being overwhelmed by sheer quantity of malicious uploaded packets. This is a risk even if the user ID space is not being deliberately flooded, and if individual certificates are protected from flooding by any of the mechanisms described later in this document. The keystore itself can become difficult to operate if the total quantity of data is too large, and if it is a synchronizing keyserver, then the quantities of data may impose unsustainable bandwidth costs on the operator as well. Effectively mitigating against keystore flooding requires either abandoning the append-only property that some keystores prefer, or imposing very strict controls on initial ingestion. Toxic Data {#toxic-data} =2D--------- Like any large public dataset, it's possible that a keystore ends up hosting some content that is legally actionable in some jurisdictions, including libel, child pornography, material under copyright or other "intellectual property" controls, blasphemy, hate speech, etc. A public keystore that accepts and redistributes arbitrary content may face risk due to uploads of toxic data. Keystore Interfaces {#keystore-interfaces} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some keystores have simple interfaces, like files present in a local filesystem. But many keystores offer an API for certificate retrieval of different types. This section documents a set of useful interactions that a client may have with such a keystore. They are represented in abstract form, and are not intended to be the full set of interfaces offered by any keystore, but rather a convenient way to think about the operations that make the keystore useful for its clients. Not all keystores may offer all of these interfaces, or they may offer them in subtly different forms, but clients will nevertheless try to perform something like these operations with keystores that they interact with. Certificate Update {#certificate-update} =2D----------------- This is the simplest keystore operation. The client sends the keystore the full fingerprint of the certificate's primary key, and the keystore sends the client the corresponding certificate (or nothing, if the keystore does not contain a certificate with a matching primary key). keystore.cert_update(primary_fpr) -> certificate? A client uses certificate update to retrieve the full details of a certificate that it already knows about. For example, it might be interested in updates to the certificate known to the keystore, including revocations, expiration updates, new third-party certifications, etc. Upon successful update, the client SHOULD merge the retrieved certificate with its local copy. Not all keystores offer this operation. For example, clients cannot use WKD ({{I-D.koch-openpgp-webkey-service}}) or OPENPGPKEY ({{RFC7929}} for certificate update. Certificate Discovery {#certificate-discovery} =2D-------------------- If a client is aware of an OpenPGP signature or certification that it cannot verify because it does not know the issuing certificate, it may consult a keystore to try to discover the certificate based on the Issuer or Issuer Fingerprint subpacket in the signature or certification it is trying to validate. keystore.cert_discovery(keyid|fpr) -> certificate_list This is subtly different from certificate update ({{certificate-update}}) in three ways: * it may return more than one certificate (e.g., when multiple certificates share a subkey, or when a primary key on one certificate is a subkey on another) * it is willing to accept searches by short key ID, not just fingerprint * it is willing to match against a subkey, not just a primary key While a certificate discovery client does not initially know the certificate it is looking for, it's possible that the returned certificate is one that the client already knows about. For example, a new subkey may have been added to a certificate. Upon successful discovery, the client SHOULD merge any retrieved certificates with discovered local copies (as determined by primary key), and then evaluate the original signature against any retrieved certificate that appears to be valid and reasonable for use in the signing context. It is unclear what a client should do if multiple certificates do appear to be valid for a given signature, because of ambiguity this represents about the identity of the signer. However, this ambiguity is similar to the ambiguity of a certificate with multiple valid user IDs, which the client already needs to deal with. Not all keystores offer this operation. For example, clients cannot use WKD ({{I-D.koch-openpgp-webkey-service}}) or OPENPGPKEY ({{RFC7929}} for certificate discovery. Certificate Lookup {#certificate-lookup} =2D----------------- If a client wants to encrypt a message to a particular e-mail address, or wants to encrypt a backup to some identity that it knows of but does not have a certificate for, it may consult a keystore to discover certificates that claim that identity in their user ID packets. Both {{I-D.koch-openpgp-webkey-service}} and {{I-D.shaw-openpgp-hkp}} offer certificate lookup mechanisms. {{RFC4880}} User IDs are constrained only in that they are a UTF-8 string, but some conventions govern their practical use. See {{user-id-conventions}} for more discussion of some common conventions around user ID structure. Note that lookup does not necessarily imply user ID or certificate validation. It is entirely possible for a keystore to return a certificate during lookup that the client cannot validate. Abuse-resistant keystores that offer a lookup interface SHOULD distinguish interfaces that perform full-string-match lookup from interfaces that perform e-mail address based lookup. ### Full User ID Lookup The most straightforward form of certificate lookup asks for the set of all certificates that contain a user ID that exactly and completely matches the query parameter supplied by the client. keystore.cert_lookup(uid) -> certificate_list In its simplest form, this match is done by a simple bytestring comparison. More sophisticated keystores MAY perform the comparison after applying {{UNICODE-NORMALIZATION}} form NFC to both the `uid` query and the user IDs from the stored certificates. ### E-mail Address Lookup However, some common use cases look for specific patterns in the user ID rather than the entire user ID. Most useful to many existing OpenPGP clients is a lookup by e-mail address. keystore.cert_lookup(addr) -> certificate_list For certificates with a user ID that matches the structure of an {{RFC5322}} `name-addr` or `addr-spec`, a keystore SHOULD extract the `addr-spec` from the user ID, canonicalize it (see {{e-mail-address-canonicalization}}), and compare it to the canonicalized form of of the `addr` query parameter. ### Other Lookup Mechanisms Some keystores offer other forms of substring or regular expression matching against the stored user IDs. These other forms of lookup may be useful in some contexts (e.g., {{identity-monitoring}}), but they may also represent privacy concerns (e.g., {{publishing-identity-information}}), and they may impose additional computational or indexing burdens on the keystore. Certificate Validation {#certificate-validation} =2D--------------------- An OpenPGP client may assess certificate and user ID validity based on many factors, some of which are directly contained in the certificate itself (e.g., third-party certifications), and some of which are based on the context known to the client, including: * Whether it has seen e-mails from that address signed by that certificate in the past, * How long it has known about the certificate, * Whether the certificate was fetched from a keystore that asserts validity of the user ID or some part of it (such as the e-mail address). A keystore MAY facilitate clients pursuing this last point of contextual corroboration via a direct interface: keystore.cert_validate(primary_fpr, uid) -> boolean In an e-mail-specific context, the client might only care about the keystore's opinion about the validity of the certificate for the e-mail address portion of the user ID only: keystore.cert_validate(primary_fpr, addr) -> boolean For some keystores, the presence of a certificate in the keystore alone implies that the keystore asserts the validity of all user IDs in the certificate retrieved. For others, the presence in the keystore applies only to some part of the user ID. For example, {{PGP-GLOBAL-DIRECTORY}} will only return user IDs that have completed an e-mail validation step, so presence in that keystore implies an assertion of validity of the e-mail address part of the user IDs returned, but makes no claim about the `display-name` portion of any returned user IDs. Note that a client retrieving a certificate from such a keystore may merge the certificate with a local copy -- but the validity asserted by the keystore of course has no bearing on the packets that the keystore did not return. In a more subtle example, the retrieval of a certificate looked up via WKD ({{I-D.koch-openpgp-webkey-service}}) or DANE ({{RFC7929}}) should only be interpreted as a claim of validity about any user ID which matches the e-mail address by which the certificate was looked up, with no claims made about any `display-name` portions, or about any user ID that doesn't match the queried e-mail address at all. A keystore that offers some sort of validation interface may also change its opinion about the validity of a given certificate or user ID over time; the interface described above only allows the client to ask about the keystore's current opinion, but a more complex interface might be capable of describing the keystore's assertion over time. See also {{in-the-past}}. An abuse-resistant keystore that clients rely on for any part of their certificate validation process SHOULD offer a distinct interface for making assertions about certificate and user ID validity to help clients avoid some of the subtleties involved with inference based on presence described above. Note that the certificate validation operation as described above has a boolean response. While a "true" response indicates that keystore believes the user ID or e-mail address is acceptable for use with the certificate referred to by the public key fingerprint, a "false" response doesn't necessarily mean that the keystore actively thinks that the certificate is actively bad, or must not be used for the referenced identity. Rather, "false" is the default state: no opinion is expressed by the keystore, and the client is left to make their own inference about validity based on other factors. A keystore MAY offer a more nuanced validity interface; if it does, it SHOULD explicitly document the semantics of the different response types so that clients can make appropriate judgement. Certificate Submission =2D--------------------- Different keystores have different ways to submit a certificate for consideration for ingestion, including: * a simple upload of a certificate via http * round-trip e-mail verification * proof of presence in some other service * vouching, or other forms of multi-party attestation =20 Because these schemes vary so widely, this document does not attempt to describe the keystore certificate submission process in detail. However, guidance can be found for implementations that generate, manage, and submit certificates in {{cert-best-practices}}. Simple Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D These steps can be taken by any keystore that wants to avoid obviously malicious abuse. They can be implemented on receipt of any new packet, and are based strictly on the structure of the packet itself. Decline Large Packets {#large-packets} =2D-------------------- While {{RFC4880}} permits OpenPGP packet sizes of arbitrary length, OpenPGP certificates rarely need to be so large. An abuse-resistant keystore SHOULD reject any OpenPGP packet larger than 8383 octets. (This cutoff is chosen because it guarantees that the packet size can be represented as a one- or two-octet {{RFC4880}} "New Format Packet Length", but it could be reduced further) This may cause problems for user attribute packets that contain large images, but it's not clear that these images are concretely useful in any context. Some keystores MAY extend this limit for user attribute packets specifically, but SHOULD NOT allow even user attributes packets larger than 65536 octets. Enforce Strict User IDs =2D---------------------- {{RFC4880}} indicates that User IDs are expected to be UTF-8 strings. An abuse-resistant keystore MUST reject any user ID that is not valid UTF-8. Some abuse-resistant keystores MAY only accept User IDs that meet even stricter conventions, such as an {{RFC5322}} `name-addr` or `addr-spec`, or a URL like `ssh://host.example.org` (see {{user-id-conventions}}). As simple text strings, User IDs don't need to be nearly as long as any other packets. An abuse-resistant keystore SHOULD reject any user ID packet larger than 1024 octets. Scoped User IDs {#scoped-user-ids} =2D-------------- Some abuse-resistant keystores may restrict themselves to publishing only certificates with User IDs that match a specific pattern. For example, {{RFC7929}} encourages publication in the DNS of only certificates whose user IDs refer to e-mail addresses within the DNS zone. {{I-D.koch-openpgp-webkey-service}} similarly aims to restrict publication to certificates relevant to the specific e-mail domain. Strip or Standardize Unhashed Subpackets {#standardize-unhashed} =2D--------------------------------------- {{RFC4880}} signature packets contain an "unhashed" block of subpackets. These subpackets are not covered by any cryptographic signature, so they are ripe for abuse. An abuse-resistant keystore SHOULD strip out all unhashed subpackets but the following exceptions: ### Issuer Fingerprint Some certifications only identify the issuer of the certification by an unhashed Issuer or Issuer Fingerprint subpacket. If a certification's hashed subpacket section has no Issuer Fingerprint (see {{I-D.ietf-openpgp-rfc4880bis}}) subpacket, then an abuse-resistant keystore that has cryptographically validated the certification SHOULD synthesize an appropriate Issuer Fingerprint subpacket and include it in the certification's unhashed subpackets. ### Cross-sigs Some Primary Key Binding Signatures ("cross-sigs") are distributed as unhashed subpackets in a Subkey Binding Signature. A cryptographically-validating abuse-resistant keystore SHOULD be willing to redistribute a valid cross-sig as an unhashed subpacket. The redistributed unhashed cross-sig itself should be stripped of all unhashed subpackets. ### First-party Attestations Some third-party certifications are attested to by the certificate primary key itself in an unhashed subpacket, as described in {{fpatpc}}. A cryptographically-validating abuse-resistant keystore SHOULD be willing to redistribute a valid first-party attestation as an unhashed subpacket. The redistributed first-party attestation itself should be stripped of all unhashed subpackets. Decline User Attributes =2D---------------------- Due to size concerns, some abuse-resistant keystores MAY choose to ignore user attribute packets entirely, as well as any certifications that cover them. Decline Non-exportable Certifications =2D------------------------------------ An abuse-resistant keystore MUST NOT accept any certification that has the "Exportable Certification" subpacket present and set to 0. While most keystore clients will not upload these "local" certifications anyway, a reasonable public keystore that wants to minimize data has no business storing or distributing these certifications. Decline Data From the Future =2D--------------------------- Many OpenPGP packets have time-of-creation timestamps in them. An abuse-resistant keystore with a functional real-time clock MAY decide to only accept packets whose time-of-creation is in the past. Note that some OpenPGP implementations may pre-generate OpenPGP material intended for use only in some future window (e.g. "Here is the certificate we plan to use to sign our software next year; do not accept signatures from it until then."), and may use modified time-of-creation timestamps to try to achieve that purpose. This material would not be distributable ahead of time by an abuse-resistant keystore that adopts this mitigation. Accept Only Profiled Certifications =2D---------------------------------- An aggressively abuse-resistant keystore MAY decide to only accept certifications that meet a specific profile. For example, it MAY reject certifications with unknown subpacket types, unknown notations, or certain combinations of subpackets. This can help to minimize the amount of room for garbage data uploads. Any abuse-resistant keystore that adopts such a strict posture should clearly document what its expected certificate profile is, and should have a plan for how to extend the profile if new types of certification appear that it wants to be able to distribute. Note that if the profile is ever restricted (rather than extended), and the restriction is applied to the material already present, such a keystore is no longer append-only (please see {{non-append-only}}). Accept Only Certificates Issued by Designated Authorities {#authorities} =2D-------------------------------------------------------- An abuse-resistant keystore capable of cryptographic validation MAY retain a list of designated authorities, typically in the form of a set of known public keys. Upon receipt of a new OpenPGP certificate, the keystore can decide whether to accept or decline each user ID of the certificate based whether that user ID has a certification that was issued by one or more of the designated authorities. If no user IDs are certified by designated authority, such a keystore SHOULD decline the certificate and its primary key entirely. Such a keystore SHOULD decline to retain or propagate all certifications associated with each accepted user ID except for first-party certifications and certifications by the designated authorities. The operator of such a keystore SHOULD have a clear policy about its set of designated authorities. Given the ambiguities about expiration and revocation, such a keyserver SHOULD ignore expiration and revocation of authority certifications, and simply accept and retain as long as the cryptographic signature is valid. Note that if any key is removed from the set of designated authorities, and that change is applied to the existing keystore, such a keystore may no longer be append-only (please see {{non-append-only}}). Decline Packets by Blocklist {#blocklist} =2D--------------------------- The maintainer of the keystore may keep a specific list of "known-bad" material, and decline to accept or redistribute items matching that blocklist. The material so identified could be anything, but most usefully, specific public keys or User IDs could be blocked. Note that if a blocklist grows to include an element already present in the keystore, it will no longer be append-only (please see {{non-append-only}}). Some keystores may choose to apply a blocklist only at retrieval time and not apply it at ingestion time. This allows the keystore to be append-only, and permits synchronization between keystores that don't share a blocklist, and somewhat reduces the attacker's incentive for flooding the keystore (see {{retrieval-time-mitigations}} for more discussion). Note that development and maintenance of a blocklist is not without its own potentials for abuse. For one thing, the blocklist may itself grow without bound. Additionally, a blocklist may be socially or politically contentious as it may describe data that is toxic ({{toxic-data}}) in one community or jurisdiction but not another. There needs to be a clear policy about how it is managed, whether by delegation to specific decision-makers, or explicit tests. Furthermore, the existence of even a well-intentioned blocklist may be an "attractive nuisance," drawing the interest of would-be censors or other attacker interested in controlling the ecosystem reliant on the keystore in question. Retrieval-time Mitigations {#retrieval-time-mitigations} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Most of the abuse mitigations described in this document are described as being applied at certificate ingestion time. It's also possible to apply the same mitigations when a certificate is retrieved from the keystore (that is, during certificate lookup, update, or discovery). Applying an abuse mitigation at retrieval time may help a client defend against a user ID flooding ({{user-id-flooding}}), certificate flooding ({{certificate-flooding}}), or fingerprint flooding ({{fingerprint-flooding}}) attack. It may also help a keystore limit its liability for redistributing toxic data ({{toxic-data}}). However, only mitigations applied at ingestion time are able to mitigate keystore flooding attacks ({{keystore-flooding}}). Some mitigations (like the non-append-only mitigations described in {{non-append-only}}) may be applied as filters at retrieval time, while still allowing access to the (potentially much larger) unfiltered dataset associated given certificate or user ID via a distinct interface. The rest of this section documents specific mitigations that are only relevant at retrieval time (certificate discovery, lookup, or update). Redacting User IDs {#user-id-redacting} =2D----------------- Some abuse-resistant keystores may accept and store user IDs but decline to redistribute some or all of them, while still distributing the certifications that cover those redacted user IDs. This draft refers to such a keystore as a "user ID redacting" keystore. The certificates distributed by such a keystore are technically invalid {{RFC4880}} "transferable public keys", because they lack a user ID packet, and the distributed certifications cannot be cryptographically validated independently. However, an OpenPGP implementation that already knows the user IDs associated with a given primary key will be capable of associating each certification with the correct user ID by trial signature verification. ### Certificate Update with Redacted User IDs A user ID redacting keystore is useful for certificate update by a client that already knows the user ID it expects to see associated with the certificate. For example, a client that knows a given certificate currently has two specific user IDs could access the keystore to learn that one of the user IDs has been revoked, without any other client learning the user IDs directly from the keystore. ### Certificate Discovery with Redacted User IDs A user ID redacting keystore is somewhat less useful for clients doing certificate discovery. Consider the circumstance of receiving a signed e-mail without access to the signing certificate. If the verifier retrieves the certificate from a user ID redacting keystore by via the Issuer Fingerprint from the signature, and the signature validates, the received certificate might not be a valid "transferable public key" unless the client can synthesize the proper user ID. A reasonable client that wants to validate a certification in the user ID redacted certificate SHOULD try to synthesize possible user IDs based on the value of the {{RFC5322}} From: header in the message: * Decode any {{RFC2047}} encodings present in the raw header value, converting into UTF-8 {{UNICODE-NORMALIZATION}} form C (NFC), trimming all whitespace from the beginning and the end of the string. * The resulting string should be an {{RFC5322}} `name-addr` or `addr-spec`. * If it is a `name-addr`, convert the UTF-8 string into an OpenPGP user ID and check whether the certification validates, terminating on success. * If the test fails, extract the `addr-spec` from the `name-addr` and continue. * Canonicalize the `addr-spec` according to {{e-mail-address-canonicalization}}, and check whether the certification validates, terminating on success. * If it doesn't validate wrap the canonicalized `addr-spec` in angle-brackets ("<" and ">") and test the resulting minimalist `name-addr` against the certification, terminating on success. * If all of the above fails, synthesis has failed. ### Certificate Lookup with Redacted User IDs It's possible (though non-intuitive) to use a user ID redacting keystore for certificate lookup. Since the keystore retains (but does not distribute) the user IDs, they can be used to select certificates in response to a search. The OpenPGP certificates sent back in response to the search will not contain the user IDs, but a client that knows the full user ID they are searching for will be able to verify the returned certifications. Certificate lookup from a user ID redacting keystore works better for certificate lookup by exact user ID match than it does for substring match, because a client that retrieves a certificate via a substring match may not be able to reconstruct the redacted user ID. However, without some additional restrictions on which certifications are redistributed (whether the user ID is redacted or not), certificate lookup can be flooded (see {{uploads-vs-lookup}}). ### Hinting Redacted User IDs {#uidhash} To ensure that the distributed certificate is at least structurally a valid {{RFC4880}} transferable public key, a user ID redacting keystore MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose contents are a zero-octet string) in place of the omitted user ID. This two-octet replacement user ID packet ("\xb4\x00") is called the "unstated user ID". To facilitate clients that match certifications with specific user IDs, a user ID redacting keystore MAY insert a non-hashed notation subpacket into the certification. The notation will have a name of "uidhash", with 0x80 ("human-readable") flag unset. The value of such a notation MUST be 32 octets long, and contains the SHA-256 cryptographic digest of the UTF-8 string of the redacted user ID. A certificate update client which receives such a certification after the "unstated user ID" SHOULD compute the SHA-256 digest of all user IDs it knows about on the certificate, and compare the result with the contents of the "uidhash" notation to decide which user ID to try to validate the certification against. ### User ID Recovery by Client Brute Force User ID redaction is at best an imperfect process. Even if a keystore redacts a User ID, if it ships a certification over that user ID, an interested client can guess user IDs until it finds one that causes the signature to verify. This is even easier when the space of legitimate user IDs is relatively small, such as the set of commonly-used hostnames Primary-key Only Certificate Update {#primary-key-only-update} =2D---------------------------------- Abuse-resistant keystores can defend against a fingerprint flooding {{fingerprint-flooding}} attack during certificate update by implementing a narrowly-constrained certificate update interface. Such a keystore MUST accept only a full fingerprint as the search parameter from the certificate update client, and it MUST return at most a single certificate whose primary key matches the requested fingerprint. It MUST NOT return more than one certificate, and it MUST NOT return any certificate whose primary key does not match the fingerprint. In particular, it MUST NOT return certificates where only the subkey fingerprint matches. Note that {{I-D.shaw-openpgp-hkp}} does not offer the primitive described in {{certificate-update}} exactly. In that specification, the set of keys returned by a "get" operation with a "search" parameter that appears to be a full fingerprint is ambiguous. Some popular implementations (e.g., {{SKS}}) do not currently implement this mitigation, because they return certificates with subkeys that match the fingerprint. Require Valid Cross-Sigs for Certificate Discovery {#require-cross-sig-disc= overy} =2D------------------------------------------------- By definition, certificate discovery needs to be able to match subkeys, not just primary keys. This means that the mitigation in {{primary-key-only-update}} is ineffective for a keystore that offers a certificate discovery interface. An abuse-resistant keystore that aims to defend its certificate discovery interface from a fingerprint flooding ({{fingerprint-flooding}}) attack can follow the following procedure. Such a keystore MUST accept only a full fingerprint or a 64-bit key ID as the search parameter from the certificate discovery client. It MUST only match that fingerprint against the following: * the fingerprint or key ID of a primary key associated with a valid certificate * the fingerprint or key ID of a cryptographically-valid subkey that also has a cross-sig. This defends against the fingerprint flooding attack because a certificate will only be returned by subkey if the subkey has agreed to be associated with the primary key (and vice versa). Note that this mitigation means that certificate discovery will fail if used for subkeys that lack cross-sigs. In particular, this means that a client that tries to use the certificate discovery interface to retrieve a certificate based on its encryption-capable subkey (e.g., taking the key ID from a Public Key Encrypted Session Key (PKESK) packet) will have no success. This is an acceptable loss, since the key ID in a PKESK is typically unverifiable anyway. Contextual Mitigations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some mitigations make the acceptance or rejection of packets contingent on data that is already in the keystore or the keystore's developing knowledge about the world. This means that, depending on the order that the keystore encounters the various material, or how it accesses or finds the material, the final set of material retained and distributed by the keystore might be different. While this isn't necessarily bad, it may be a surprising property for some users of keystores. Accept Only Cryptographically-verifiable Certifications =2D------------------------------------------------------ An abuse-resistant keystore that is capable of doing cryptographic validation MAY decide to reject certifications that it cannot cryptographically validate. This may mean that the keystore rejects some packets while it is unaware of the public key of the issuer of the packet. Accept Only Certificates Issued by Known Certificates =2D---------------------------------------------------- This is an extension of {{authorities}}, but where the set of authorities is just the set of certificates already known to the keystore. An abuse-resistant keystore that adopts this strategy is effectively only crawling the reachable graph of OpenPGP certificates from some starting core. A keystore adopting the mitigation SHOULD have a clear documentation of the core of initial certificates it starts with, as this is effectively a policy decision. This mitigation measure may fail due to a compromise of any secret key that is associated with a primary key of a certificate already present in the keystore. Such a compromise permits an attacker to flood the rest of the network. In the event that such a compromised key is identified, it might be placed on a blocklist (see {{blocklist}}). In particular, if a public key is added to a blocklist for a keystore implementing this mitigation, and it is removed from the keystore, then all certificates that were only "reachable" from the blocklisted certificate should also be simultaneously removed. Rate-limit Submissions by IP Address =2D----------------------------------- Some OpenPGP keystores accept material from the general public over the Internet. If an abuse-resistant keystore observes a flood of material submitted to the keystore from a given Internet address, it MAY choose to throttle submissions from that address. When receiving submissions over IPv6, such a keystore MAY choose to throttle entire nearby subnets, as a malicious IPv6 host is more likely to have multiple addresses. This requires that the keystore maintain state about recent submissions over time and address. It may also be problematic for users who appear to share an IP address from the vantage of the keystore, including those behind a NAT, using a VPN, or accessing the keystore via Tor. Accept Certificates Based on Exterior Process {#exterior-process} =2D-------------------------------------------- Some public keystores resist abuse by explicitly filtering OpenPGP material based on a set of external processes. For example, {{DEBIAN-KEYRING}} adjudicates the contents of the "Debian keyring" keystore based on organizational procedure and manual inspection. Accept Certificates by E-mail Validation =2D--------------------------------------- Some keystores resist abuse by declining any certificate until the user IDs have been verified by e-mail. When these "e-mail validating" keystores review a new certificate that has a user ID with an e-mail address in it, they send an e-mail to the associated address with a confirmation mechanism (e.g., a high-entropy HTTPS URL link) in it. In some cases, the e-mail itself is encrypted to an encryption-capable key found in the proposed certificate. If the keyholder triggers the confirmation mechanism, then the keystore accepts the certificate. Some e-mail validating keystores MAY choose to distribute certifications over all user IDs for any given certificate, but will redact (see {{user-id-redacting}}) those user IDs that have not been e-mail validated. {{PGP-GLOBAL-DIRECTORY}} describes some concerns held by a keystore operator using this approach. {{MAILVELOPE-KEYSERVER}} is another example. Non-append-only mitigations {#non-append-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The following mitigations may cause some previously-retained packets to be dropped after the keystore receives new information, or as time passes. This is entirely reasonable for some keystores, but it may be surprising for any keystore that expects to be append-only (for example, some keyserver synchronization techniques may expect this property to hold). Furthermore, keystores that drop old data (e.g., superseded certifications) may make it difficult or impossible for their users to reason about the validity of signatures that were made in the past. See {{in-the-past}} for more considerations. Note also that many of these mitigations depend on cryptographic validation, so they're typically contextual as well. A keystore that needs to be append-only, or which cannot perform cryptographic validation MAY omit these mitigations. Alternately, a keystore may omit these mitigations at certificate ingestion time, but apply these mitigations at retrieval time (during certificate update, discovery, or lookup), and offer a more verbose (non-mitigated) interface for auditors, as described in {{retrieval-time-mitigations}}. Note that {{GnuPG}} anticipates some of these suggestions with its "clean" subcommand, which is documented as: Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring. Drop Superseded Signatures {#drop-superseded} =2D------------------------- An abuse-resistant keystore SHOULD drop all signature packets that are explicitly superseded. For example, there's no reason to retain or distribute a self-sig by key K over User ID U from 2017 if the keystore have a cryptographically-valid self-sig over from 2019. Note that this covers both certifications and signatures over subkeys, as both of these kinds of signature packets may be superseded. Getting this right requires a nuanced understanding of subtleties in {{RFC4880}} related to timing and revocation. Drop Expired Signatures {#drop-expired} =2D---------------------- If a signature packet is known to only be valid in the past, there is no reason to distribute it further. An abuse-resistant keystore with access to a functional real-time clock SHOULD drop all certifications and subkey signature packets with an expiration date in the past. Note that this assumes that the keystore and its clients all have roughly-synchronized clocks. If that is not the case, then there will be many other problems! Drop Dangling User IDs, User Attributes, and Subkeys =2D--------------------------------------------------- If enough signature packets are dropped, it's possible that some of the things that those signature packets cover are no longer valid. An abuse-resistant keystore which has dropped all certifications that cover a User ID SHOULD also drop the User ID packet. Note that a User ID that becomes invalid due to revocation MUST NOT be dropped, because the User ID's revocation signature itself remains valid, and needs to be distributed. A primary key with no User IDs and no subkeys and no revocations MAY itself also be removed from distribution, though note that the removal of a primary key may make it impossible to cryptographically validate other certifications held by the keystore. Drop All Other Elements of a Directly-Revoked Certificate {#only-revocation} =2D-------------------------------------------------------- If the primary key of a certificate is revoked via a direct key signature, an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation. Note that the direct key revocation signature MUST NOT be dropped. In the event that an abuse-resistant keystore is flooded with direct key revocation signatures, it should retain the hardest, earliest revocation (see also {{revocations}}). In particular, if any of the direct key revocation signatures is a "hard" revocation, the abuse-resistant keystore SHOULD retain the earliest such revocation signature (by signature creation date). Otherwise, the abuse-resistant keystore SHOULD retain the earliest "soft" direct key revocation signature it has seen. If either of the above date comparisons results in a tie between two revocation signatures of the same "hardness", an abuse-resistant keystore SHOULD retain the signature that sorts earliest based on a binary string comparison of the direct key revocation signature packet itself. Implicit Expiration Date =2D----------------------- In combination with some of the dropping mitigations above, a particularly aggressive abuse-resistant keystore MAY choose an implicit expiration date for all signature packets. For example, a signature packet that claims no expiration could be treated by the keystore as expiring 3 years after issuance. This would permit the keystore to eject old packets on a rolling basis. An abuse-resistant keystore that adopts this mitigation needs a policy for handling signature packets marked with an explicit expiration that is longer than implicit maximum. The two obvious strategies are: * cap the packet's expiration to the system's implicit expiration date, or * accept the explicit expiration date. Warning: Any implementation of this idea is pretty radical, and it's not clear what it would do to an ecosystem that depends on such a keystore. It probably needs more thinking. Updates-only Keystores {#updates-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In addition to the mitigations above, some keystores may resist abuse by declining to accept any user IDs or certifications whatsoever. Such a keystore MUST be capable of cryptographic validation. It accepts primary key packets, cryptographically-valid direct-key signatures from a primary key over itself, subkeys and their cryptographically-validated binding signatures (and cross-sigs, where necessary). A client of an updates-only keystore cannot possibly use the keystore for certificate lookup, because there are no user IDs to match. And it is not particularly useful for certificate discovery, because the returned certificate would have no identity information. However, such a keystore can be used for certificate update, as it's possible to ship revocations (which are direct key signatures), new subkeys, updates to subkey expiration, subkey revocation, and direct key signature-based certificate expiration updates. Note that many popular OpenPGP implementations do not implement direct primary key expiration mechanisms, relying instead on user ID expirations. These user ID expiration dates or other metadata associated with a self-certification will not be distributed by an updates-only keystore. Certificates shipped by an updates-only keystore are technically invalid {{RFC4880}} "transferable public keys," because they lack a user ID packet. However many OpenPGP implementations will accept such a certificate if they already know of a user ID for the certificate, because the composite certificate resulting from a merge will be a standards-compliant transferable public key. First-party-only Keystores {#first-party-only} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Slightly more permissive than the updates-only keystore described in {{updates-only}} is a keystore that also permits user IDs and their self-sigs. A first-party-only keystore only accepts and distributes cryptographically-valid first-party certifications. Given a primary key that the keystore understands, it will only attach user IDs that have a valid self-sig, and will only accept and re-distribute subkeys that are also cryptographically valid (including requiring cross-sigs for signing-capable subkeys as recommended in {{RFC4880}}). This effectively avoids certificate flooding attacks, because the only party who can make a certificate overly large is the holder of the secret corresponding to the primary key itself. Note that a first-party-only keystore is still problematic for those people who rely on the keystore for retrieval of third-party certifications. {{fpatpc}} attempts to address this lack. First-party-only Without User IDs =2D-------------------------------- It is possible to operate an first-party-only keystore that redistributes certifications while declining to redistribute user IDs (see {{user-id-redacting}}). This defends against concerns about publishing identifiable information, while enabling full certificate update for those keystore clients that already know the associated user IDs for a given certificate. First-party-attested Third-party Certifications {#fpatpc} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We can augment a first-party-only keystore to allow it to distribute third-party certifications as long as the first-party has signed off on the specific third-party certification. An abuse-resistant keystore SHOULD only accept a third-party certification if it meets the following criteria: * The third-party certification MUST be cryptographically valid. Note that this means that the keystore needs to know the primary key for the issuer of the third-party certification. * The third-party certification MUST have an unhashed subpacket of type Embedded Signature, the contents of which we'll call the "attestation". This attestation is from the certificate's primary key over the third-party certification itself, as detailed in the steps below: * The attestation MUST be an OpenPGP signature packet of type 0x50 (Third-Party Confirmation signature) * The attestation MUST contain a hashed "Issuer Fingerprint" subpacket with the fingerprint of the primary key of the certificate in question. * The attestation MUST NOT be marked as non-exportable. * The attestation MUST contain a hashed Notation subpacket with the name "ksok", and an empty (0-octet) value. * The attestation MUST contain a hashed "Signature Target" subpacket with "public-key algorithm" that matches the public-key algorithm of the third-party certification. * The attestation's hashed "Signature Target" subpacket MUST use a reasonably strong hash algorithm (as of this writing, any {{RFC4880}} hash algorithm except MD5, SHA1, or RIPEMD160), and MUST have a hash value equal to the hash over the third-party certification with all unhashed subpackets removed. * The attestation MUST be cryptographically valid, verifiable by the primary key of the certificate in question. This means that a third-party certificate will only be accepted/distributed by the keystore if: * the keystore knows about both the first- and third-parties. * the third-party has made the identity assertion * the first-party has confirmed that they're OK with the third-party certification being distributed by any keystore. The "ksok" notification is not strictly necessary for this mitigation, but it is intended to avoid potential accidental confusion with any other use of the Third-Party Confirmation signature packet type. The author does not know of any current use that might collide. Key Server Preferences "No-modify" =2D--------------------------------- {{RFC4880}} defines "Key Server Preferences" with a "No-modify" bit. That bit has never been respected by any keyserver implementation that the author is aware of. An abuse-resistant keystore following {{fpatpc}} effectively treats that bit as always set, whether it is present in the certificate or not. Client Interactions {#client-interactions} =2D------------------ Creating such an attestation requires multiple steps by different parties, each of which is blocked by all prior steps: * The first-party creates the certificate, and transfers it to the third party. * The third-party certifies it, and transfers their certification back to the first party. * The first party attests to the third party's certification. * Finally, the first party then transfers the compound certificate to the keystore. The complexity and length of such a sequence may represent a usability obstacle to a user who needs a third-party-certified OpenPGP certificate. No current OpenPGP client can easily create the attestations described in this section. More implementation work needs to be done to make it easy (and understandable) for a user to perform this kind of attestation. Keystore Client Best Practices {#client-best-practices} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D An OpenPGP client that needs to interact with an abuse-resistant keystore can take steps to minimize the extent that its interactions with a keystore can be abused by other parties via the attacks described in {{problem-statement}}. This section describes steps that an abuse-resistant client can take. Use Constrained Keystores for Lookup =2D----------------------------------- When performing certificate lookup, an abuse-resistant client SHOULD prefer to query constrained keystores to avoid the risks described in {{uploads-vs-lookup}}. Normalize Addresses and User IDs for Lookup =2D------------------------------------------ When performing lookup by e-mail address, an abuse-resistant client SHOULD consider canonicalizing the e-mail address before searching (see {{e-mail-address-canonicalization}}). When searching by full User ID, unless there is a strong reason to believe that a specific non-normalized form is preferable, an abuse-resistant client SHOULD normalize the entire user ID into {{UNICODE-NORMALIZATION}} Form C (NFC) before performing certificate lookup. Avoid Fuzzy Lookups =2D------------------ Certificate lookup by arbitrary substring matching, or regular expression is prone to abuse. An abuse-resistant client SHOULD prefer exact-userid or exact-email match lookups where possible. In particular, an abuse-resistant client should avoid trying to offer reliable functionality that performs these sort of fuzzy lookups, and SHOULD warn the user about risks of abuse if the user triggers a codepath that unavoidably performs such a fuzzy lookup. Prefer Full Fingerprint for Discovery and Update =2D----------------------------------------------- Key IDs are inherently weaker and easier to spoof or collide than full fingerprints. Where possible, an abuse-resistant keystore client SHOULD use the full fingerprint when interacting with the keystore. Use Caution with Keystore-provided Validation =2D-------------------------------------------- When an abuse-resistant client relies on a keystore for certificate validation, many things can go subtly wrong if the client fails to closely track the specific semantics of the keystore's validation claims. For example, a certificate published by WKD ({{I-D.koch-openpgp-webkey-service}}) at `https://openpgpkey.example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1m= k4r39qejnbu3n5q?l=3Djoe.doe` offers a validation claim only for the e-mail address `joe.doe@example.org`. If the certificate retrieved at that address contains other user IDs, or if the user ID containing that e-mail address contains an {{RFC5322}} `display-name`, none of that information should be considered "validated" by the fact that the certificate was retrieved via certificate lookup by WKD. When certificate validation is represented more generally by a keystore via certificate retrieval (e.g. from an e-mail validating keyserver that has no distinct certificate validation interface), the thing validated is the certificate received from the keystore, and not the result of the merge into any local copy of the certificate already possessed by the client. Consider also timing and duration of these assertions of validity, which represent a subtle tradeoff between privacy and risk as described in {{validation-privacy}}. Certificate Generation and Management Best Practices {#cert-best-practices} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D An OpenPGP implementation that generates or manages certificates and expects to distribute them via abuse-resistant keystores can take steps to ensure that the certificates generated are more likely to be accessible when needed. This section describes steps such an abuse-sensitive implementation can take. Canonicalized E-Mail Addresses =2D----------------------------- E-mail addresses can be written in many different ways. An abuse-sensitive implementation considering attaching a user ID containing an e-mail address on a certificate SHOULD ensure that the e-mail address is structured as simply as possible. See {{e-mail-address-canonicalization}} for details about e-mail address canonicalization. For example, if the e-mail domain considers the local part to be case-insensitive (as most e-mail domains do today), if a proposed user ID contains the `addr-spec`: `Alice@EXAMPLE.org`, the implementation SHOULD warn the user and, if possible, propose replacing the `addr-spec` part of the user ID with `alice@example.org`. Normalized User IDs =2D------------------ User IDs are arbitrary UTF-8 strings, but UTF-8 offers several ways to represent the same string. An abuse-sensitive implementation considering attaching a user ID to a certificate SHOULD normalize the string using {{UNICODE-NORMALIZATION}} Form C (NFC) before creating the self-sig. At the same time, the implementation MAY also warn the user if the "compatibility" normalized form (NFKC) differs from the candidate user ID and, if appropriate, offer to convert the user ID to compatibility normalized form at the user's discretion. Avoid Large User Attributes =2D-------------------------- An abuse-sensitive implementation SHOULD warn the user when attaching a user attribute larger than 8383 octets, and SHOULD refuse to attach user attributes entirely larger than 65536 octets. (See {{large-packets}}) Provide Cross-Sigs =2D----------------- {{RFC4880}} requires cross-sigs for all signing-capable subkeys, but is agnostic about the use of cross-sigs for subkeys of other capabilities. An abuse-sensitive implementation that wants a certificate to be discoverable by subkey SHOULD provide cross-sigs for any subkey capable of making a cross-sig. Provide Issuer Fingerprint Subpackets =2D------------------------------------ Issuer subpackets contain only 64-bit key IDs. Issuer Fingerprint subpackets contain an unambiguous designator of the issuing key, avoiding the ambiguities described in {{id-vs-fingerprint-discovery}}. Abuse-sensitive implementations SHOULD providue Issuer Fingerprint subpackets. Put Cross-Sigs and Issuer Fingerprint in Hashed Subpackets =2D--------------------------------------------------------- Unhashed subpackets may be stripped or mangled. Placing cross-sigs and issuer fingerprint subpackets in the hashed subpackets will ensure that they are propagated by any cryptographically-validating keystore, even if that keystore fails to observe the exceptions in {{standardize-unhashed}}. Submit Certificates to Restricted, Lookup-Capable Keystores =2D---------------------------------------------------------- If an abuse-sensitive implementation wants other peers to be able to to retrieve the managed certificate by certificate lookup (that is, by searching based on user ID or e-mail address), it needs to be aware that submission to an unrestricted keystore is not reliable (see {{uploads-vs-lookup}} for more details). Consequently, such an implementation SHOULD submit the managed certificate to restricted, lookup-capable keystores where possible, as those keystores are more likely to be able to offer reliable lookup. Side Effects and Ecosystem Impacts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Designated Revoker {#designated-revoker} =2D----------------- A first-party-only keystore as described in {{first-party-only}} might decline to distribute revocations made by the designated revoker. This is a risk to certificate-holder who depend on this mechanism, because an important revocation might be missed by clients depending on the keystore. FIXME: adjust this document to point out where revocations from a designated revoker SHOULD be propagated, maybe even in first-party-only keystores. Key IDs vs. Fingerprints in Certificate Discovery {#id-vs-fingerprint-disco= very} =2D------------------------------------------------ During signature verification, a user performing certificate discovery against a keystore SHOULD prefer to use the full fingerprint as an index, rather than the 64-bit key ID. Using a 64-bit key ID is more likely to run into collision attacks; and if the retrieved certificate has a matching key ID but the signature cannot be validated with it, the client is in an ambiguous state -- did it retrieve the wrong certificate, or is the signature incorrect? Using the fingerprint resolves the ambiguity: the signature is incorrect, because the a fingerprint match is overwhelmingly stronger than a key ID match. Unfortunately, many OpenPGP implementations distribute signatures with only an Issuer subpacket, so a client attempting to find such a certificate MAY perform certificate discovery based on only the key ID. A keystore that offers certificate discovery MAY choose to require full fingerprint, but such a keystore will not be useful for a client attempting to verify a bare signature from an unknown party if that signature only has an Issuer subpacket (and no Issuer Fingerprint subpacket). In-band Certificates {#in-band-certificates} =2D------------------- There are contexts where it is expected and acceptable that the signature appears without its certificate: for example, if the set of valid signers is already known (as in some OpenPGP-signed operating system updates), shipping the certificate alongside the signature would be pointless bloat. However, OpenPGP signatures are often found in contexts where the certificate is not yet known by the verifier. For example, many OpenPGP-signed e-mails are not accompanied by the signing certificate. In another example, the use of authentication-capable OpenPGP keys in standard SSH connections do not contain the full OpenPGP certificates, which means that the SSH clients and servers need to resort to out-of-band processes if evaluation of the OpenPGP certificates is necessary. The certificate discovery interface offered by keystores is an attempt to accommodate these situations. But in the event that a keystore is unavailable, does not know the certificate, or suffers from a flooding attack, signature validation may fail unnecessarily. In an encrypted e-mail context specifically, such a failure may also limit the client's ability to reply with an encrypted e-mail. Certificate discovery also presents a potential privacy concern for the signature verifier, as noted in {{discovery-privacy}}. These problematic situations can be mitigated by shipping the certificate in-band, alongside the signature. Signers SHOULD adopt this practice where possible to reduce the dependence of the verifier on the keystores for certificate discovery. {{AUTOCRYPT}} is an example of e-mail recommendations that include in-band certificates. ### In-band Certificate Minimization and Validity OpenPGP certificates are potenitally large. When distributing an in-band certificate alongside a signature in a context where size is a concern (e.g. bandwidth, latency, or storage costs are a factor), the distributor SHOULD reduce the size of the in-band certificate by stripping unnecessary packets. For example, the distributor may: * Strip certification and signature packets that (due to creation and expiration time) are not relevant to the time of the signature itself. This ensures that the reduced certificate is contemporaneously valid with the signature. * Strip irrelevant subkeys (and associated Subkey Binding Signature packets and cross-sigs). If the signature was issued by a signing-capable subkey, that subkey (and its binding signature and cross-sig) are clearly relevant. Other signing-capable subkeys are likely to be irrelevant. But determining which other subkeys are relevant may be context-specific. For example, in the e-mail context, an encryption-capable subkey is likely to be contextually relevant, because it enables the recipient to reply encrypted, and therefore should not be stripped. * Strip user IDs (and associated certifications) that are unlikely to be relevant to the signature in question. For example, in the e-mail context, strip any user IDs that do not match the declared sender of the message. * Strip third-party certifications that are unlikely to be relevant to the verifier. Doing this successfully requires some knowledge about what the third-parties the recipient is likely to care about. Stripping all third-party certifications is a simple means of certificate reduction. The verifier of such a certificate may need to do certificate update against their preferred keystore to learn about third-party certifications useful to them. Certification-capable Subkeys =2D---------------------------- Much of this discussion assumes that primary keys are the only certification-capable keys in the OpenPGP ecosystem. Some proposals have been put forward that assume that subkeys can be marked as certification-capable. If subkeys are certification-capable, then much of the reasoning in this draft becomes much more complex, as subkeys themselves can be revoked by their primary key without invalidating the key material itself. That is, a subkey can be both valid (in one context) and invalid (in another context) at the same time. So questions about what data can be dropped (e.g. in {{non-append-only}}) are much fuzzier, and the underlying assumptions may need to be reviewed. If some OpenPGP implementations accept certification-capable subkeys, but an abuse-resistant keystore does not accept certifications from subkeys in general, then interactions between that keystore and those implementations may be surprising. Assessing Certificates in the Past {#in-the-past} =2D--------------------------------- Online protocols like TLS perform signature and certificate evaluation based entirely on the present time. If a certificate that signs a TLS handshake message is invalid now, it doesn't matter whether it was valid a week ago, because the present TLS session is the context of the evaluation. But OpenPGP signatures are often evaluated at some temporal remove from when the signature was made. For example, software packages are signed at release time, but those signatures are validated at download time. A verifier that does not already know the certificate that made the signature will need to perform certificate discovery against some set of keystores to find a certificate with which to check the signature. Further complicating matters, the composable nature of an OpenPGP certificate means that the certificate associated with any particular signing key (primary key or subkey) can transform over time. So when evaluating a signature that appears to have been made by a given certificate, it may be better to try to evaluate the certificate at the time the signature was made, rather than the present time. ### Point-in-time Certificate Evaluation {#point-in-time} When evaluating a certificate at a time T in the past (for example, when trying to validate a data signature by that certificate that was created at time T), one approach is to discard all packets from the certificate if the packet has a creation time later than T. Then evaluate the resulting certificate from the remaining packets in the context of time T. However, any such evaluation MUST NOT ignore "hard" OpenPGP key revocations, regardless of their creation date. (see {{revocations}}). ### Signature Verification and Non-append-only Keystores {#verification-and= -non-append-only} If a non-append-only keystore ({{non-append-only}}) has dropped superseded ({{drop-superseded}}) or expired ({{drop-expired}}) certifications, it's possible for the certificate composed of the remaining packets to have no valid first-party certification at the time that a given signature was made. If a user performs certificate discovery against such a keystore, the certificate it retrieves would be invalid according to {{RFC4880}}, and consequently verification of any signature by that certificate would fail. One simple mitigation to this problem is to ship a contemporaneously-valid certificate in-band alongside the signature (see {{in-band-certificates}}). If the distributor does this, then the verifier need only learn about revocations. If knowledge about revocation is needed, the verifier might perform a certificate update (not "certificate discovery") against any preferred keystore, including non-append-only keystores, merging what it learns into the in-band contemporary certificate. Then the signature verifier can follow the certificate evaluation process outlined in {{point-in-time}}, using the merged certificate. Global Append-only Ledgers ("Blockchain") {#gaol} =2D---------------------------------------- The append-only aspect of some OpenPGP keystores encourages a user of the keystore to rely on that keystore as a faithful reporter of history, and one that will not misrepresent or hide the history that they know about. An unfaithful "append-only" keystore could abuse the trust in a number of ways, including withholding revocation certificates, offering different sets of certificates to different clients doing certificate lookup, and so on. However, the most widely used append-only OpenPGP keystore, the {{SKS}} keyserver pool, offers no cryptographically verifiable guarantees that it will actually remain append-only. Users of the pool have traditionally relied on its distributed nature, and the presumption that coordination across a wide range of administrators would make it difficult for the pool to reliably lie or omit data. However, the endpoint most commonly used by clients to access the network is `hkps://hkps.pool.sks-keyservers.net`, the default for {{GnuPG}}. That endpoint is increasingly consolidated, and currently consists of hosts operated by only two distinct administrators, increasing the risk of potential misuse. Offering cryptographic assurances that a keystore could remain append-only is an appealing prospect to defend against these kinds of attack. Many popular schemes for providing such assurances are known as "blockchain" technologies, or global append-only ledgers. With X.509 certificates, we have a semi-functional Certificate Transparency ({{RFC6962}}, or "CT") ecosystem that is intended to document and preserve evidence of (mis)issuance by well-known certificate authorities (CAs), which implements a type of global append-only ledger. While the CT infrastructure remains vulnerable to certain combinations of colluding actors, it has helped to identify and sanction some failing CAs. Like other global append-only ledgers, CT itself is primarily a detection mechanism, and has no enforcement regime. If a widely-used CA were identified by certificate transparency to be untrustworthy, the rest of the ecosystem still needs to figure out how to impose sanctions or apply a remedy, which may or may not be possible. CT also has privacy implications -- the certificates published in the CT logs are visible to everyone, for the lifetime of the log. For spam abatement, CT logs decline all X.509 certificates except those issued by certain CAs (those in popular browser "root stores"). This is an example of the strategy outlined in {{authorities}}). Additional projects that provide some aspects of global append-only ledgers that try to address some of the concerns described here include {{KEY-TRANSPARENCY}} and {{CONIKS}}, though they are not specific to OpenPGP. Both of these systems are dependent on servers operated by identity providers, however. And both offer the ability to detect a misbehaving identity provider, but no specific enforcement or recovery strategies against such an actor. It's conceivable that a keystore could piggyback on the CT logs or other blockchain/ledger mechanisms like {{BITCOIN}} to store irrevocable pieces of data (such as revocation certificates). Further work is needed to describe how to do this in an effective and performant way. Certificate Lookup for Identity Monitoring {#identity-monitoring} =2D----------------------------------------- A typical use case for certificate lookup is a user looking for a certificate in order to be able to encrypt an outbound message intended for a given e-mail address, but this is not the only use case. Another use caes is when the party in control of a particular identity wants to determine whether anyone else is claiming that identity. That is, a client in control of the secret key material associated with a particular certificate with user ID X might search a keystore for all certificates matching X in order to find out whether any other certificates claim it. This is an important safeguard as part of the ledger-based detection mechanisms described in {{gaol}}, but may also be useful for keystores in general. However, identity monitoring against a keystore that does not defend against user ID flooding ({{user-id-flooding}}) is expensive and potentially of limited value. In particular, a malicious actor with a certificate which duplicates a given User ID could flood the keystore with similar certificates, hiding whichever one is in malicious use. Since such a keystore is not considered authoritative by any reasonable client for the user ID in question, this attack forces the identity-monitoring defender to spend arbitrary resources fetching and evaluating each certificate in the flood, without knowing which certificate other clients might be evaluating. OpenPGP details =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This section collects details about common OpenPGP implementation behavior that are useful in evaluating and reasoning about OpenPGP certificates. Revocations {#revocations} =2D---------- It's useful to classify OpenPGP revocations of key material into two categories: "soft" and "hard". If the "Reason for Revocation" of an OpenPGP key is either "Key is superseded" or "Key is retired and no longer used", it is a "soft" revocation. An implementation that interprets a "soft" revocation will typically not invalidate signatures made by the associated key with a creation date that predates the date of the soft revocation. A "soft" revocation in some ways behaves like a non-overridable expiration date. All other revocations of OpenPGP keys (with any other Reason for Revocation, or with no Reason for Revocation at all) should be considered "hard". The presence of a "hard" revocation of an OpenPGP key indicates that the user should reject all signatures and certifications made by that key, regardless of the creation date of the signature. Note that some OpenPGP implementations do not distinguish between these two categories. A defensive OpenPGP implementation that does not distinguish between these two categories SHOULD treat all revocations as "hard". An implementation aware of a "soft" revocation or of key or certificate expiry at time T SHOULD accept and process a "hard" revocation even if it appears to have been issued at a time later than T. User ID Conventions {#user-id-conventions} =2D------------------ {{RFC4880}} requires a user ID to be a UTF-8 string, but does not constrain it beyond that. In practice, a handful of conventions predominate in how User IDs are formed. The most widespread convention is a `name-addr` as defined in {{RFC5322}}. For example: Alice Jones But a growing number of OpenPGP certificates contain user IDs that are instead a raw {{RFC5322}} `addr-spec`, omitting the `display-name` and the angle brackets entirely, like so: alice@example.org Some certificates have user IDs that are simply normal human names (perhaps `display-name` in {{RFC5322}} jargon, though not necessarily conforming to a specific ABNF). For example: Alice Jones Still other certificates identify a particular network service by scheme and hostname. For example, the administrator of an ssh host participating in the {{MONKEYSPHERE}} might choose a user ID for the OpenPGP representing the host like so: ssh://foo.example.net E-mail Address Canonicalization {#e-mail-address-canonicalization} =2D------------------------------ When an OpenPGP user IDs includes an `addr-spec`, there still may be multiple ways of representing the addr-spec that refer to the same underlying mailbox. Having a truly canonical form of an `addr-spec` is probably impossible because of legacy deployments of mailservers that do odd things with the local part, but e-mail addresses used in an abuse-resistant ecosystem SHOULD be constrained enough to admit to some sensible form of canonicalization. ### Disallowing Non-UTF-8 Local Parts In {{RFC5322}}, the `local-part` can be any `dot-atom`. But if this is {{RFC2047}} decoded, it could be any arbitrary charset, not necessarily UTF-8. FIXME: Do we convert from the arbitrary charset to UTF-8? ### Domain Canonicalization FIXME: should domain name be canonicalized into punycode form? User IDs are typically user-facing, so i think the canonicalized form should be the {{UNICODE-NORMALIZATION}} Form C (NFC) of the domain name. Can we punt to some other draft here? ### Local Part Canonicalization FIXME: {{I-D.koch-openpgp-webkey-service}} recommends downcasing all ASCII characters in the left-hand side, but leaves all=20 Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document offers guidance on mitigating a range of denial-of-service attacks on public keystores, so the entire document is in effect about security considerations. Many of the mitigations described here defend individual OpenPGP certificates against flooding attacks (see {{certificate-flooding}}). But only some of these mitigations defend against flooding attacks against the keystore itself (see {{keystore-flooding}}), or against flooding attacks on the space of possible user IDs (see {{user-id-flooding}}). Thoughtful threat modeling and monitoring of the keystore and its defenses are probably necessary to maintain the long-term health of the keystore. {{designated-revoker}} describes a potentially scary security problem for designated revokers. TODO (more security considerations) Tension Between Unrestricted Uploads and Certificate Lookup {#uploads-vs-lo= okup} =2D---------------------------------------------------------- Note that there is an inherent tension between accepting arbitrary certificate uploads and permitting effective certificate lookup. If a keystore accepts arbitrary certificate uploads for redistribution, it appears to be vulnerable to user ID flooding ({{user-id-flooding}}), which makes it difficult or impossible to rely on for certificate lookup. In the broader ecosystem, it may be necessary to use gated/controlled certificate lookup mechanisms. For example, both {{I-D.koch-openpgp-webkey-service}} and {{RFC7929}} enable the administrator of a DNS domain to distribute certificates associated with e-mail addresses within that domain, while excluding other parties. As a rather different example, {{I-D.mccain-keylist}} offers certificate lookup on the basis of interest -- a client interested in an organization can use that mechanism to learn what certificates that organization thinks are worth knowing about, associated with a range of identities regardless of the particular DNS domain. Note that {{I-D.mccain-keylist}} does not provide the certificates directly, but instead expects the client to be able to retrieve them by primary key fingerprint through some other keystore capable of (and responsible for) certificate update. Privacy Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Keystores themselves raise a host of potential privacy concerns. Additional privacy concerns are raised by traffic to and from the keystores. This section tries to outline some of the risks to the privacy of people whose certificates are stored and redistributed in public keystores, as well as risks to the privacy of people who make use of the key stores for certificate lookup, certificate discovery, or certificate update. Publishing Identity Information {#publishing-identity-information} =2D------------------------------ Public OpenPGP keystores often distribute names or e-mail addresses of people. Some people do not want their names or e-mail addresses distributed in a public keystore, or may change their minds about it at some point. Append-only keystores are particularly problematic in that regard. The mitigation in {{only-revocation}} can help such users strip their details from keys that they control. However, if an OpenPGP certificate with their details is uploaded to a keystore, but is not under their control, it's unclear what mechanisms can be used to remove the certificate that couldn't also be exploited to take down an otherwise valid certificate. Some jurisdictions may present additional legal risk for keystore operators that distribute names or e-mail addresses of non-consenting parties. Updates-only keystores ({{updates-only}}) and user ID redacting keystores ({{user-id-redacting}}) may reduce this particular privacy concern because they distribute no user IDs at all. Social Graph =2D----------- Third-party certifications effectively map out some sort of social graph. A certification asserts a statement of belief by the issuer that the real-world party identified by the user ID is in control of the subject cryptographic key material. But those connections may be potentially sensitive, and some people may not want these maps built. A first-party-only keyserver ({{first-party-only}}) avoids this privacy concern because it distributes no third-party privacy concern. First-party attested third-party certifications described in {{fpatpc}} are even more relevant edges in the social graph, because their bidirectional nature suggests that both parties are aware of each other, and see some value in mutual association. Tracking Clients by Queries {#tracking-clients} =2D-------------------------- Even without third-party certifications, the acts of certificate lookup, certificate discovery, and certificate update represent a potential privacy risk, because the keystore queried gets to learn which user IDs (in the case of lookup) or which certificates (in the case of update or discovery) the client is interested in. In the case of certificate update, if a client attempts to update all of its known certificates from the same keystore, that set is likely to be a unique set, and therefore identifies the client. A keystore that monitors the set of queries it receives might be able to profile or track those clients who use it repeatedly. A privacy-aware client which wants to to avoid such a tracking attack MAY try to perform certificate update from multiple different keystores. To hide network location, a client making a network query to a keystore SHOULD use an anonymity network like {{TOR}}. Tools like {{PARCIMONIE}} are designed to facilitate this type of certificate update. Such a client SHOULD also decline to use protocol features that permit linkability across interactions with the same keystore, such as TLS session resumption, HTTP cookies, and so on. Keystores which permit public access and want to protect the privacy of their clients SHOULD NOT reject access from clients using {{TOR}} or comparable anonymity networks. Additionally, they SHOULD minimize access logs they retain. Alternately, some keystores may distribute their entire contents to any interested client, in what can be seen as the most trivial form of private information retrieval. {{DEBIAN-KEYRING}} is one such example; its contents are distributed as an operating system package. Clients can interrogate their local copy of such a keystore without exposing their queries to a third-party. "Live" Certificate Validation Leaks Client Activity {#validation-privacy} =2D-------------------------------------------------- If a client relies on a keystore's certificate validation interface, or on the presence of a certificate in a keystore as a part of its validation calculations, it's unclear how long the assertion from the keystore is or should be considered to hold. One seemingly simple approach is to simply query the keystore's validation interface each time that the client needs to validate the certificate. This "live" validation approach poses a quandary to the client in the event that the keystore is unavailable. How should in interpret the "unknown" result? In addition, live validation reveals the client's activity to the keystore with fine precision. A privacy-aware client that depends on keystores for certificate validation SHOULD NOT perform "live" certificate validation on each use it makes of the certificate. Rather, it SHOULD cache the validation information for some period of time and make use of the cached copy where possible. If such a client does a regular certificate update from the same keystore, it SHOULD also pre-emptively query the keystore for certificate validation at the same time. Choosing the appropriate time intervals for this kind of caching has implications for the windows of risk for the client that might use a revoked certificate. Defining an appropriate schedule to make this tradeoff is beyond the scope of this document. Certificate Discovery Leaks Client Activity {#discovery-privacy} =2D------------------------------------------ The act of doing certificate discovery on unknown signatures offers a colluding keystore and remote peer a chance to track a client's consumption of a given signature. An attacker with access to keystore logs could sign a message with a unique key, and then watch the keystore activity to determine when a client consumes the signature. This is potentially a tracking or "phone-home" situation. A signer that has no interest in this particular form of tracking can mitigate this concern by shipping their certificate in-band, alongside the signature, as recommended in {{in-band-certificates}}. A privacy-aware client MAY insist on in-band certificates by declining to use any certificate discovery interface at all, and treat a bare signature by an unknown certificate as an invalid signature. Certificate Update Leaks Client Activity {#update-privacy} =2D--------------------------------------- The act of doing certificate update itself reveals some information that the client is interested in a given certificate and how it may have changed since the last time the client updated it, or since it was first received by the client. This is essentially the same privacy problem presented by OCSP {{RFC6960}} in the X.509 world. In the online world of TLS, this privacy leak is mitigated by the CertificateStatus TLS handshake extension ({{RFC4366}}), a.k.a. "OCSP stapling". There is no comparable solution for the store-and-forward or non-online scenarios where OpenPGP is often found. Privacy-aware clients MAY prefer to access update interfaces from anonymity-preserving networks like {{TOR}} to obscure where they are on the network, but if the certificate being updated is known to be used only by a single client that may not help. Privacy-aware clients MAY prefer to stage their certificate updates over time, but longer delays imply greater windows of vulnerability for use of an already-revoked certificate. This strategy also does not help when a previously-unknown certificate is encountered in-band (see {{in-band-certificates}}), and the OpenPGP client wants to evaluate it for use in the immediate context. Distinct Keystore Interfaces Leak Client Context and Intent =2D---------------------------------------------------------- The distinct keystore interfaces documented in {{keystore-interfaces}} offer subtly different semantics, and are used by a reasonable keystore client at different times. A keystore that offers distinct discovery and update interfaces may infer that a client visiting the update interface already knows about the certificate in question, or that a client visiting the discovery interface is in the process of verifying a signature from a certificate it has not seen before. HKP itself ({{I-D.shaw-openpgp-hkp}}) conflates these two interfaces =2D- the same HKP query is be used to perform both discovery and update (though implementations like {{SKS}} are not at all abuse-resistant for either use), which may obscure the context and intent of the client from the keystore somewhat. A privacy-aware client that can afford the additional bandwidth and complexity MAY use the keystore's discovery interface for both update and discovery, since the discovery interface is a proper superset of the update interface. Cleartext Queries =2D---------------- If access to the keystore happens over observable channels (e.g., cleartext connections over the Internet), then a passive network monitor could perform the same type profiling or tracking attack against clients of the keystore described in {{tracking-clients}}. Keystores which offer network access SHOULD provide encrypted transport. Traffic Analysis =2D--------------- Even if a keystore offers encrypted transport, the size of queries and responses may provide effective identification of the specific certificates fetched during lookup, discovery, or update, leaving open the types of tracking attacks described in {{tracking-clients}}. Clients of keystores SHOULD pad their queries to increase the size of the anonymity set. And keystores SHOULD pad their responses. The appropriate size of padding to effectively anonymize traffic to and from keystores is likely to be mechanism- and cohort-specific. For example, padding for keystores accessed via the DNS ({{RFC7929}} may use different padding strategies that padding for keystores accessed over WKD ({{I-D.koch-openpgp-webkey-service}}), which may in turn be different from keystores accessed over HKPS ({{I-D.shaw-openpgp-hkp}}). A keystore which only accepts user IDs within a specific domain (e.g., {{scoped-user-ids}}) or which uses custom process ({{exterior-process}}) for verification might have different padding criteria than a keystore that serves the general public. Specific padding policies or mechanisms are out of scope for this document. User Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D {{client-interactions}} describes some outstanding work that needs to be done to help users understand how to produce and distribute a third-party-certified OpenPGP certificate to an abuse-resistant keystore. Additionally, some keystores present directly user-facing affordances. For example, {{SKS}} keyservers typically offer forms and listings that can be viewed directly in a web browser. Such a keystore SHOULD be as clear as possible about what abuse mitigations it takes (or does not take), to avoid user confusion. Keystores which do not expect to be used directly as part of a certificate validation calculation SHOULD advise clients as explicitly as possible that they offer no assertions of validity. Experience with the {{SKS}} keyserver network shows that many users treat the keyserver web interfaces as authoritative. That is, users act as though the keyserver network offers some type of certificate validation. Unfortunately, The developer and implementor communities explicitly disavow any authoritative role in the ecosystem, and the implementations attempt very few mitigations against abuse, permitting redistribution of even cryptographically invalid OpenPGP packets. Clearer warnings to end users might reduce this kind of misperception. Or the community could encourage the removal of frequently misinterpreted user interfaces entirely. IANA Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document asks IANA to register two entries in the OpenPGP Notation IETF namespace, both with a reference to this document: * the "ksok" notation is defined in {{fpatpc}}. * the "uidhash" notation is defined in {{uidhash}}. Document Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \[ RFC Editor: please remove this section before publication ] This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by e-mail to the author. Please direct all significant commentary to the public IETF OpenPGP mailing list: openpgp@ietf.org Document History =2D--------------- substantive changes between -02 and -03: * new sections: * Keystore Interfaces * Keystore Client Best Practices * Certificate Generation and Management Best Practices * rename "certificate discovery" to "certificate lookup" * redefine "certificate discovery" to refer to lookup by signing (sub)key * new attack: fingerprint flooding * new retrieval-time mitigations -- tighter filters on discovery and update * recommend in-band certificates where possible to avoid discovery and loo= kup * new privacy considerations: * distinct keystore interfaces * certificate update * certificate discovery * certificate validation * more nuance about unhashed subpacket filtering =20 substantive changes between -01 and -02: * distinguish different forms of flooding attack * distinguish toxic data as distinct from flooding * retrieval-time mitigations * user ID redaction * references to related work (CT, keylist, CONIKS, key transparency, ledgers/"blockchain", etc) * more details about UI/UX substantive changes between -00 and -01: * split out Contextual and Non-Append-Only mitigations * documented several other mitigations, including: * Decline Data From the Future * Blocklist * Exterior Process * Designated Authorities * Known Certificates * Rate-Limiting * Scoped User IDs * documented Updates-Only Keystores * consider three different kinds of flooding * deeper discussion of privacy considerations * better documentation of Reason for Revocation * document user ID conventions Acknowledgements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document is the result of years of operational experience and observation, as well as conversations with many different people -- users, implementors, keystore operators, etc. A non-exhaustive list of people who have contributed ideas or nuance to this document specifically includes: * Antoine Beaupr=C3=A9 * ilf * Jamie McClelland * Jonathan McDowell * Justus Winter * Marcus Brinkmann * Micah Lee * Neal Walfield * Phil Pennock * Philihp Busby * vedaal * Vincent Breitmoser * Wiktor Kwapisiewicz --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLlvkgAKCRB2GBllKa5f +Mg3AP4/tUocmu78POuA9TCPWStgFZn6/WvSFzFrR6kfsoA6EwEA+sARuE5FdwDl S32u8cYk7jfzEq40xSychQFsoUaiWQ0= =kZZj -----END PGP SIGNATURE----- --==-=-=-- From nobody Fri Apr 19 06:39:23 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17691202E9 for ; Fri, 19 Apr 2019 06:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=rt6xtmAq; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=3emvdRm6 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 VKe868DKU2lX for ; Fri, 19 Apr 2019 06:39:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1442F1202E6 for ; Fri, 19 Apr 2019 06:39:18 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555681157; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=zQjJNNMf3JlT+93Ip972g7WTW0sYIlbEdoSYz17xrhA=; b=rt6xtmAq5W4SRZ5nuu6s+YqSBJXktj7Hrxs7kf6NcWva8UeuloSXuCHz W3Q7eyb2QGloIwuxex3/nThg2W8cBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555681156; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=zQjJNNMf3JlT+93Ip972g7WTW0sYIlbEdoSYz17xrhA=; b=3emvdRm6BpmlF8mQhCIHGoSnawAiofdrNITEQsUJE3FPdIt7VMPRos/e bhOqr/QB4bNHLaqwE52IWwP7ClBXZ0ths1KzmUwnM6ur53GlIwFnOdf+HG DLjxQJ6e4u2Ht/Vc/PUvLVR7EwJrC7zXgsfrqBK4kv9Ylxf/RjYXFcFgco MqDakuLI9GkyRRva9A2tuHUfCFAjH15Qi9wCmaDe/aHs5+WAdLAx3ijKyn Dof/nkVn1yFDU6r2BIcfovs5K23nI//3GN1JajEqQJOqp31b4FAfgc3iwU 9HoqT/5F6X6rNIxqyaLTTv6SbNNCpfxbiIZaAUh2fe5YIWJJ9gCA1w== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 31F68F99D; Fri, 19 Apr 2019 09:39:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 64BDB2030E; Fri, 19 Apr 2019 03:27:44 -0400 (EDT) From: Daniel Kahn Gillmor To: Wiktor Kwapisiewicz , Bart Butler Cc: "openpgp\@ietf.org" In-Reply-To: <083fd6b7-6f8f-bed9-6666-6dddae121656@metacode.biz> References: <083fd6b7-6f8f-bed9-6666-6dddae121656@metacode.biz> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 19 Apr 2019 03:27:43 -0400 Message-ID: <87tveuxxn4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory and advanced lookup method X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 13:39:21 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2019-04-18 22:27:19 +0200, Wiktor Kwapisiewicz wrote: > Oh, I was not suggesting adding TXTs - believe me I'd like to have a > good Web compatibility too (that's why I asked about CORS previously, > and well... added support for WKD to OpenPGP.js :). The interesting thing about MTA-STS's fix is not that it was a TXT record, but rather that offers a gating mechanism for a domain to explicitly opt into the protocol, rather than everyone being automatically opted-in (and therefore potentially spoofed in the way that Wiktor is concerned about). Is there some analogous semantics that we can offer that would still be accessible from the browser? Or, if we decide to gate WKD by a TXT record, can a javascript in-browser implementation use something like DoH to do the TXT lookup? > Got it, thank you for your remarks! I was thinking about using just the=20 > bare domain lookup (without subdomain) that avoids the issue > altogether. I'm pretty sure i don't like the bare domain lookup, and would prefer that that fallback was removed from the draft. If i give you the ability to place files on my website, i don't expect you to be able to assert e-mail identity information for me or for my users. > And if someone wants to delegate hosting keys to someone else adding=20 > permanent redirect in HTTP server is usually simple (Nginx example): > > location ~ /.well-known/openpgpkey/(.*) { > return 301 https://example.com/.well-known/openpgpkey/$1; > } The draft doesn't seem to mention whether clients should follow HTTP redirects, or what the privacy/security/performance impacts of such a practice are. For example, should a WKD client follow an HTTP redirect to an http:// (not https://) site? If the other site redirects, how many layers of redirection should be followed? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLl4cAAKCRB2GBllKa5f +EF1AQCcYHkhi+4MRewVxLutL52RGBW7SywgECNASwYWpBM1KwEAr6wbe7YmsTV0 fSjsRgDOosni5KPGvFmxKgHBZbR3vwo= =qCK1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 19 06:39:30 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D661202E3 for ; Fri, 19 Apr 2019 06:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=9mEy3cVz; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=wyR4LAXv 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 YoI1mkRv3hg3 for ; Fri, 19 Apr 2019 06:39:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035051202E4 for ; Fri, 19 Apr 2019 06:39:18 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555681157; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=So+gGi6ZmcQnO+vsoke8aYyQl2jBGjze4gJZ00IRC1k=; b=9mEy3cVzWw33nLdRGYquw8aaLcLaLVR41vaqyR3iIpgtxmlU4zz3rt80 FRJJMcKK3gqZmzXIDO58AmmxiO2SAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555681156; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=So+gGi6ZmcQnO+vsoke8aYyQl2jBGjze4gJZ00IRC1k=; b=wyR4LAXvKdVKdtlKUHZx3X/Xc3qZgRWkkuECJjk7uPwENjOFrP8QPbtj OMKQxoqElnxby4NaRqAwGcbDTQwLOcK9SNFq51Rb3wvUVGK3GjvLm3hw8A icv0dQKeffYSbJke6ew0gPAKguEZeu7qVnFDmV5nZAka3uT5IaUEDdJSoi 91qzseW5wLMBCeHrfJD7bHYSGo9YeHLzAy8cAzG+wFKa/i9nHFPu1o1ls5 eEe5gp+3hGiEwRWXzwaLoL+v51uRCQwFqz0CwHM3APsZj++PDnkNFZQrqj MA5nLCHUXI3clVsQCOqs36zCCKpuEJdmcUBJuCrci9d92WbI0/ehgA== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 436CAF99E; Fri, 19 Apr 2019 09:39:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6EE0120299; Fri, 19 Apr 2019 03:18:26 -0400 (EDT) From: Daniel Kahn Gillmor To: Bart Butler , Wiktor Kwapisiewicz Cc: "openpgp\@ietf.org" In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 19 Apr 2019 03:18:25 -0400 Message-ID: <87wojqxy2m.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory and advanced lookup method X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 13:39:22 -0000 --=-=-= Content-Type: text/plain On Thu 2019-04-18 18:21:01 +0000, Bart Butler wrote: > I'd say that this is less of an attack vector and more of a 'mischief' > vector, and that public suffixes can easily protect themselves if it > ever becomes an issue. Why is this merely "mischief"? I can publish semi-authoritative records about the key material for all your users if you grant me access to a single specific subdomain. without noticing the appearance of this draft. That sounds like more than mischief to me. > WKD client implementations can also use the public suffix list > themselves to prevent the problem--a quick search yields libraries for > lots of platforms. Maybe this would be a reasonable suggestion to add > to the RFC, but it also doesn't seem critical to me. Resorting to the public suffix list is always a terrible solution, but maybe it's what we have to rely on. Writing down the explicit guidance on what to do there, and what it's implications are, is probably a good idea for thinking it through. Would this suggest, for example, that no e-mail address within @github.io would be able to effectively publish their OpenPGP certificate via WKD? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLl2QgAKCRB2GBllKa5f +LB5AP4zo7+6LLk8x9/XM569ini7gDXG1F1mbGGNHR1DzetZMQEAl5bh++E9+j2/ GfFkfozuuRBLOBXgV9RHHawxVFIxXgM= =jpbG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 21 23:55:26 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71481200FA for ; Sun, 21 Apr 2019 23:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 E_7Yam9SIM4L for ; Sun, 21 Apr 2019 23:55:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAA51200F4 for ; Sun, 21 Apr 2019 23:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1555916119; bh=tMktmsgqlARfiMYc+TIAr1FMxaJDZE7SENn9FGaolLY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=de8ZOi1rRn9NjWVxjwgsMiRc30bvEcIwt7ZdIkRczS2kGeOxMEGw2/qFGyDoqGJrT QmsialJfMdOCWaXVza/HYq2IxQCHb4m0hEDlVRiKaf0Jl1hX+xxpwOj74nwbWVa9bf UW9f3hJMNF7keSxxuNI/C/hzTHuYaLXnQifeELGE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.24] ([217.234.5.185]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtfJd-1gxunp2wf9-00v4Np for ; Mon, 22 Apr 2019 08:55:18 +0200 To: openpgp@ietf.org References: <87sgvh1ugy.fsf@wheatstone.g10code.de> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQlSGVpa28gU3Rh bWVyIDxoZWlrby5zdGFtZXJAcG9zdGVvLmRlPohiBBMRAgAiAhsDAh4BAheABQJTnH9pBgsJ CAcDAgYVCAIJCgsEFgIDAQAKCRBPWE64+yvhT4n9AJwNsUcN5bx9/gtUs4LMmqBcePkQKwCf Y4FmM1D4rmTWsHQ1NRgsiqQhc265Aw0EN1gq2RAMAK4ZTZJZeaOmjIYhf9QfN7rQ6iXEF20r OG8NkeHLVLPw02t2QjejO5g4zGQplktPD+JCKBU1B/DL7l8BTDopofw4+fAierJ6C4jo/AbS pArZxaVJNkOVNbwHYPdCmO3yxieeMYQgYoZvtkBSA4OZZh2xLfmi3IRBPRSf+REiqPJBy9aA 0f7634vKldTG7R4PR2UP+THjpM/2SpNiyv/y9ZaEPYn3zHRkWsUw3xAMIiE73Hen6o/J9KIB 2e4jiI3VFiwq0LaKRv5whzltjKydGi2zVqcDLc93lDxsW2OXPE89GH3S/9irlEz/ciBuxtLT MMjSV3OeV34Mid7Muz8RE6whOaZteuEgAcLxONxe3FZHeG2cUuciCZDdFqDRtB6w0XhjltdI ZzD8zHBZyboRfBxubtRzriTxjFcxjI3L5df9uLWjuvkl0fSYpQV5dMX1Yus2kXiMHKUeTVE0 NtHqSnozzu88l6D+dCHX0i1BDFgkZi70oGEEaEW0NQgDItOdNwADBQv/a0d7nasV4JW9mjtF nlJDL9pyXHuGc+y9vfJNdy+DlzuHB44vtl+yH9ecTdpxE7RgB8ZvQvEwUmV+keBw+5NkR3ms +AnPrwZxwAIE/DxnwyBAQETkf9SIBH8cz0BCYQ37B+N4OW/pkYSWadjn2Bgi4IZRWyrDmnAI KwsGzfGUxPIKI3AMcRFFqjdhMaFo3L2GwJ2o0dBxd1LN0Xo6298ydcjrtAbKI1xuNXBfBAeU YCzGjg7cUw6XXfyjU5rTQkxKTu13xsKUwCnse7jOvDnfdNnYC+n7o4WNQBDhTiF0QMZ482ba FtCKcqdQJ3fQ9uioh1kOZirhJJ40xtYrDLcS3H9rQZff0X+CeOa94EdJYYYH7BIpysrfJ9c1 cxrg5brzeb9ofWaxLQvRIXBubbDtd0AunQMJXTfXHUmgYCdzSZVyy1tUzso1QacI4D0PhRIo euP8ihlWhqnHRv5tY8Ue18uFybaVIOWrsXXjQOVBUvXFmYCc9ykvJcyYSadLYkJliEYEGBEC AAYFAjdYKtkACgkQT1hOuPsr4U9xEwCeKB7jHvmUrWnuxsqx2Flvq2/gIk8AoKkOpGf2jud+ 8uWi5c1ohHWeuLtz Message-ID: Date: Mon, 22 Apr 2019 08:55:20 +0200 MIME-Version: 1.0 In-Reply-To: <87sgvh1ugy.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Provags-ID: V03:K1:GZMd5sigQd8p38ZcoSa/TZ4Z2wWx//C/nwhu/kYED7u3uW2Dhg+ Qoa+SFGS/MbnRjzoi9I6pODpsNfqDIVFoOFA4EDddaa5R9scpWG9geTmR6iB45odtDBmsZj QOVI8WZwvnCsbotsOeUI4nsvNqyhTo80DSh0X4Em0KFHksFxqxwWeC1IcMpluuTmbDJL1I4 QX20dkmgSW/9iimB1MsXA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ChLmHYArEjU=:j3zq1scxtFTidJZpAe73Fc uR5Uc4g4/ZQCNSz5ptUKEgQLWbOxSgN9rNRyHmp7N0Yj/nF4sI1WMDNYBNBWp6f6q6Q7Wswqo 7D6x+EtrW2jcwxTmXbiPYamezeCvhwTfLZekKPnWEd9Ih2n4inZnkWvw7fJhMfg70HyKEnTNd k9MZ68iOfIv8F6mJBnmHcIwMR/2j1SjlJC2cIRnX4q/8pK5CZBL58pbaDjXE9hPFLndGlug4Q whRrsadmR3cIqIALnQMdjUz3qtCv8Z55XTVOEFjzMjvcUHOfqnHv0l5gqjb+3AbSBhbp6STlq zdxeb7BDQORnX619bR3T8brWfbiPO6I0xB2PB50KRYIk2IJgk47pISz3UUwX5xt4NHZ0cZ5BE D3m6W+BnF1wWSr7Bi+I2X0kHJxTw0nqwbAsCi5yS11ceoSR74gGpWUx6MN2Cdoix8eQYTverr HgyvgIVpSaFa8fCaZZLmANqWA+4dPUOIjHrbk6iWcV/TtkJQpJC3kDZ6Uv6S0mwjw+lmGQ+83 V7HqgBh2zijytaopvs+vJkW+si8EAkLlHzc55DcmABXR9UZsvBZWA6ffRSIFoplPLNeKE+NRg ZZJmdeuVs0RPl5bQRx02i3cQao9Mgd+Ru2kxycjZO5eafnrwrzLFFMvUXXQk72e3RtZ1j/qe/ toj7GPgjJVnvA35P7VaPAe/SJiDuj9a3aKdUX5eHMgik//NszO2zeOfqH1d75gzKLRPaBVwFs T7F7gUF3yzI0Ze1E8Hjd79wSXJ8EwB98QLjiMFboaXsHjqf/5oaeNvRh7dNcE3k5cZK+s8bwP MQp8Lnq9Gv3Vur0fOmat3Gp6MR0ft/EHDsq+JPYJAJ5P9wlv7JLRIN2OEZuXhDCj979jTnO49 x9Wg5JoHjQjUJyCIqZSHiKdHO2eXClvbVwp1jvjGz4qbdOnLWL50FVQtEsvuuXR2jFF4TNF0r ng87NvwhZUw== Archived-At: Subject: Re: [openpgp] v5 sample key X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 06:55:25 -0000 Hi Werner, during implementation of V5 keys and signatures in LibTMCG I discovered a minor issue with RFC 4880bis. Section 5.2.4 says at third paragraph: "When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet." There is no distinction between V3, V4, and V5 signatures resp. keys. However, GnuPG computes the hash in function hash_public_key() for V5 keys in a different way: starting with octet 0x9a and a four-octet length is given before the body of key packet is hashed. Thus, either this part should be specified in RFC 4880bis with more detail or GnuPG has to change its hash computation for signatures. Best regards, Heiko. PS. Taking the above issue into account the given V5 sample key is recognized by LibTMCG as required: PrivateKeyBlockParse(emma_armored, 3, "", emma) INFO: PacketDecode() = 5 version = 5 INFO: encdatalen = 0 INFO: skalgo = 0 INFO: aeadalgo = 0 INFO: s2kconv = 0 INFO: s2k_type = 0 s2k_hashalgo = 0 s2k_count = 0 INFO: key ID of private primary key: 19 34 7b c9 87 24 64 2 INFO: PacketDecode() = 13 version = 0 INFO: signature subpacket type = 33 found INFO: signature subpacket type = 2 found INFO: signature subpacket type = 27 found INFO: signature subpacket type = 11 found INFO: signature subpacket type = 34 found INFO: signature subpacket type = 21 found INFO: signature subpacket type = 22 found INFO: signature subpacket type = 30 found INFO: signature subpacket type = 23 found INFO: PacketDecode() = 2 version = 5 INFO: EdDSA rbits = 254 sbits = 255 INFO: PacketDecode() = 7 version = 5 INFO: encdatalen = 0 INFO: skalgo = 0 INFO: aeadalgo = 0 INFO: s2kconv = 0 INFO: s2k_type = 0 s2k_hashalgo = 0 s2k_count = 0 INFO: key ID of private subkey: e4 55 7c 2b 2 ff bf 4b INFO: signature subpacket type = 33 found INFO: signature subpacket type = 2 found INFO: signature subpacket type = 27 found INFO: PacketDecode() = 2 version = 5 INFO: EdDSA rbits = 256 sbits = 256 CheckSelfSignatures() INFO: key ID of primary key: 19 34 7b c9 87 24 64 2 INFO: fingerprint of primary key: 19 34 7b c9 87 24 64 2 5f 99 df 3e c2 e0 0 e d9 88 48 92 e1 f7 b3 ea 4c 94 0 91 59 56 9b 54 INFO: number of selfsigs = 0 INFO: number of keyrevsigs = 0 INFO: number of certrevsigs = 0 INFO: number of userids = 1 INFO: number of userattributes = 0 INFO: number of subkeys = 1 INFO: number of revkeys = 0 INFO: userid = "emma.goldman@example.net" INFO: number of selfsigs = 1 INFO: number of revsigs = 0 INFO: number of certsigs = 0 INFO: sig type = 0x13 pkalgo = 22 hashalgo = 8 revocable = true exportable = true version = 5 creationtime = 1553069284 expirationtime = 0 keyexpirationtime = 0 revcode = 0 packet.size() = 152 hspd.size() = 72 issuer = 19 34 7b c9 87 24 64 2 issuerfpr = 19 34 7b c9 87 24 64 2 5f 99 df 3e c2 e0 0 e d9 88 48 92 e1 f7 b3 ea 4c 94 0 91 59 56 9b 54 keyflags = 3 revkeys.size() = 0 INFO: left = f5 c0 INFO: user ID is valid INFO: primary key update expirationtime to 0 INFO: primary key update flags to 3 INFO: primary key update features to 7 INFO: primary key update psa to 9 8 7 2 INFO: primary key update pha to 10 9 8 11 2 INFO: primary key update pca to 2 3 1 INFO: primary key update paa to 2 1 INFO: primary key update revkeys with added INFO: key flags on primary key are CS CheckSubkeys() INFO: key ID of subkey: e4 55 7c 2b 2 ff bf 4b INFO: fingerprint of subkey: e4 55 7c 2b 2 ff bf 4b 4 f8 74 1 ec 33 6a f7 13 3d f 85 be 7f d0 9b ae fd 9c ae b8 c9 39 65 INFO: number of selfsigs = 0 INFO: number of bindsigs = 1 INFO: number of pbindsigs = 0 INFO: number of keyrevsigs = 0 INFO: number of certrevsigs = 0 INFO: number of revkeys = 0 INFO: sig type = 0x18 pkalgo = 22 hashalgo = 8 revocable = true exportable = true version = 5 creationtime = 1553069284 expirationtime = 0 keyexpirationtime = 0 revcode = 0 packet.size() = 124 hspd.size() = 44 issuer = 19 34 7b c9 87 24 64 2 issuerfpr = 19 34 7b c9 87 24 64 2 5f 99 df 3e c2 e0 0 e d9 88 48 92 e1 f7 b3 ea 4c 94 0 91 59 56 9b 54 keyflags = c revkeys.size() = 0 INFO: left = 39 24 INFO: subkey update expirationtime to 0 INFO: subkey update flags to c INFO: subkey update features to INFO: subkey update psa to INFO: subkey update pha to INFO: subkey update pca to INFO: subkey update paa to INFO: subkey update revkeys with added INFO: subkey is valid INFO: key flags on subkey are Ee !primary->Weak() INFO: EdDSA with curve "Ed25519" and 256 bits From nobody Tue Apr 23 01:15:28 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7A612040F for ; Tue, 23 Apr 2019 01:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 IxN2G7x4m91N for ; Tue, 23 Apr 2019 01:15:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3A8120409 for ; Tue, 23 Apr 2019 01:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yo73FO3xUWMQ96sCkAcCN5hcONxTmCwjtTCwx9zToFc=; b=c0qU3maCyvZV4+4VLCTIv55pUf Qihjuihyo9/whNqwavI/gTbIVDxhMEPs0z6gfmKW3H1aou+D/aw0vQn5Qmar7NgBZCYibMz8HG/uC J1rHKwJtCXESHOQ5bWJ2KSUSq+T0fG7TXpyec0HhHfYdJSl4Qb9RlikDrXVnMx57fH1Y=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1hIqa5-0008RW-Cd for ; Tue, 23 Apr 2019 10:15:09 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1hIqWL-0001t0-9V; Tue, 23 Apr 2019 10:11:17 +0200 From: Werner Koch To: Bart Butler Cc: Bart Butler , "openpgp\@ietf.org" References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bart Butler , Bart Butler , "openpgp\@ietf.org" Date: Tue, 23 Apr 2019 10:11:16 +0200 In-Reply-To: (Bart Butler's message of "Thu, 18 Apr 2019 17:28:31 +0000") Message-ID: <875zr5ywd7.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Yobie_M.P.R.I._Recce_Spillover_BOSS_supercomputer_William_Gates_Terr"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:15:23 -0000 --=Yobie_M.P.R.I._Recce_Spillover_BOSS_supercomputer_William_Gates_Terr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 18 Apr 2019 17:28, bartbutler=3D40protonmail.com@dmarc.ietf.org said: > hope Werner likes this because GnuPG is already doing 8KiB chunks, so I am not sure about the context. Are you talking about the partial length encoding or about the AEAD chunk size, a modification of AEAD to allow detection of transmission errors before the end of the data? GnuPG 2.3 creates AEAD chunks not larger than 128 MiB. This can be changed with an option down to 64 bytes. However such a values is only useful for regression testing as it slows down the performance. I may consider to change the default to 1 MiB but not lower. Let me repeat that the whole discussion on the size of the AEAD chunks is mostly off topic because the chunks are _only_ here to allow detection of transmission errors before Gigabytes of data have been processes. This was the reason why I suggested to Brian the addition of a chunking mode for AEAD. Whether the received data is authentic can only be asserted by checking the signature and that can obviously only be done after all AEAD chunks have been decrypted. Those implementations wanting to show a preview can do so regardless of any AEAD validation etc. They should just make clear to the user that this is an unauthenticated and possible corrupted preview of the data. For all other purposes I propose to use a different protocol on top of OpenPGP a (e.g MIME) and not to overload OpenPGP with unneeded stuff. Or well, start from scratch and use a different name for it. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Yobie_M.P.R.I._Recce_Spillover_BOSS_supercomputer_William_Gates_Terr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXL7IpQAKCRD/gK6dHew1 jdCMAP9zLT48XHMTmECtZEtDaQBGf4H9J4ctm4nyHkwY6SPFawD+JxDhyHjReaWw gTeMmelWnl8zs2nPRh2rxrbZLKUBYw4= =Aep4 -----END PGP SIGNATURE----- --=Yobie_M.P.R.I._Recce_Spillover_BOSS_supercomputer_William_Gates_Terr-- From nobody Tue Apr 23 01:30:13 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FF512023F for ; Tue, 23 Apr 2019 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 zW4itmf3nFs1 for ; Tue, 23 Apr 2019 01:30:10 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D2912023C for ; Tue, 23 Apr 2019 01:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WdntgiOt2NQHMwm6Hxs6o8sF6W1CyOB+Y+EPQ6mfBJA=; b=PQrPytbbOr/jutp5V9L3aZv95t TZCtVFYIxRJDPhnxeayjGxr7BnDK5qAJgzh8OcwWCGbpVLfRFMohHwRQ94/v5dBEbSKxU1cpN6ZEo xowITnmZo7/GZe7wKqpNCF2Mx/grfoQ1QuWxbnDXOIkfcxnatcicZcGKzUwJrQP3s8cs=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1hIqoa-00007J-SH for ; Tue, 23 Apr 2019 10:30:08 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1hIqmx-00020A-0Y; Tue, 23 Apr 2019 10:28:27 +0200 From: Werner Koch To: Heiko Stamer Cc: openpgp@ietf.org References: <87sgvh1ugy.fsf@wheatstone.g10code.de> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Heiko Stamer , openpgp@ietf.org Date: Tue, 23 Apr 2019 10:28:26 +0200 In-Reply-To: (Heiko Stamer's message of "Mon, 22 Apr 2019 08:55:20 +0200") Message-ID: <871s1tyvkl.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=PBX_UTU_Plague_Wackenhut_outage_Flu_rs9512c_Public_Health_FCIC_ASLET"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 sample key X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:30:12 -0000 --=PBX_UTU_Plague_Wackenhut_outage_Flu_rs9512c_Public_Health_FCIC_ASLET Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! On Mon, 22 Apr 2019 08:55, HeikoStamer@gmx.net said: > There is no distinction between V3, V4, and V5 signatures resp. keys. > However, GnuPG computes the hash in function hash_public_key() for V5 > keys in a different way: starting with octet 0x9a and a four-octet > length is given before the body of key packet is hashed. That is because 12.2 (Key IDS and Fingerprints) has A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire [...] A V5 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9A, followed by the four-octet packet length, followed by the entire I think it makes sense to keep the signature computation in sync with the fingerprint computation. Using the four-octet length and thus 0x9a is important because it remove ambiguities if the key material is larger than 2^16. > Thus, either this part should be specified in RFC 4880bis with more I would prefer to fix this flaw in rfc4880bis 5.2.4 (Computing Signatures): =2DWhen a signature is made over a key, the hash data starts with the +When a V4 signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body =2Dof the key packet. (Note that this is an old-style packet header for a =2Dkey packet with two-octet length.) A subkey binding signature (type =2D0x18) or primary key binding signature (type 0x19) then hashes the =2Dsubkey using the same format as the main key (also using 0x99 as the =2Dfirst octet). Primary key revocation signatures (type 0x20) hash only =2Dthe key being revoked. Subkey revocation signature (type 0x28) hash =2Dfirst the primary key and then the subkey being revoked. +of the key packet; when a V5 signature is made over a key, the hash +data starts with the octet 0x9a, followed by a four-octet length of +the key, and then body of the key packet. A subkey binding signature +(type 0x18) or primary key binding signature (type 0x19) then hashes +the subkey using the same format as the main key (also using 0x99 or +0x9a as the first octet). Primary key revocation signatures (type +0x20) hash only the key being revoked. Subkey revocation signature +(type 0x28) hash first the primary key and then the subkey being +revoked. > PS. Taking the above issue into account the given V5 sample key is > recognized by LibTMCG as required: Thanks for testing. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=PBX_UTU_Plague_Wackenhut_outage_Flu_rs9512c_Public_Health_FCIC_ASLET Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXL7MqgAKCRD/gK6dHew1 jVbXAQDSjCcHSzqWrjo4YGfT+XclumXC6Klu5zG+CBxRTNJjDAEA/5dNcdiVqFZ0 nT/m0x+rOtiOD1AqGGY9CTuNYx9j+gM= =poFY -----END PGP SIGNATURE----- --=PBX_UTU_Plague_Wackenhut_outage_Flu_rs9512c_Public_Health_FCIC_ASLET-- From nobody Tue Apr 23 11:58:33 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE7412035A for ; Tue, 23 Apr 2019 11:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 QX9hh2s43XGf for ; Tue, 23 Apr 2019 11:58:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C0B12027D for ; Tue, 23 Apr 2019 11:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556045907; bh=hmPX7sT8l5LrTrDhQcTW4ljVjcEksLDSIlpejPEUlnk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=HoFaEM8sYAP71xfo4qG/L28L79opUV4eyCEivEtHoNNdj2sfK359gS8/HX2UnUMu2 cl9IB/mmWokTYzlF5YkAbVl8yUZoMTC1n8GaPHJUMNqQZee6XKDk+v6i2BiWR2udoZ QxnzZtVCaC+4387p1YlILIV+MpPbIRnYxkwI4eaM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([80.132.239.73]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MYNJg-1hMm6D0DDO-00VTkr for ; Tue, 23 Apr 2019 20:58:27 +0200 To: openpgp@ietf.org References: <87sgvh1ugy.fsf@wheatstone.g10code.de> <871s1tyvkl.fsf@wheatstone.g10code.de> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQlSGVpa28gU3Rh bWVyIDxoZWlrby5zdGFtZXJAcG9zdGVvLmRlPohiBBMRAgAiAhsDAh4BAheABQJTnH9pBgsJ CAcDAgYVCAIJCgsEFgIDAQAKCRBPWE64+yvhT4n9AJwNsUcN5bx9/gtUs4LMmqBcePkQKwCf Y4FmM1D4rmTWsHQ1NRgsiqQhc265Aw0EN1gq2RAMAK4ZTZJZeaOmjIYhf9QfN7rQ6iXEF20r OG8NkeHLVLPw02t2QjejO5g4zGQplktPD+JCKBU1B/DL7l8BTDopofw4+fAierJ6C4jo/AbS pArZxaVJNkOVNbwHYPdCmO3yxieeMYQgYoZvtkBSA4OZZh2xLfmi3IRBPRSf+REiqPJBy9aA 0f7634vKldTG7R4PR2UP+THjpM/2SpNiyv/y9ZaEPYn3zHRkWsUw3xAMIiE73Hen6o/J9KIB 2e4jiI3VFiwq0LaKRv5whzltjKydGi2zVqcDLc93lDxsW2OXPE89GH3S/9irlEz/ciBuxtLT MMjSV3OeV34Mid7Muz8RE6whOaZteuEgAcLxONxe3FZHeG2cUuciCZDdFqDRtB6w0XhjltdI ZzD8zHBZyboRfBxubtRzriTxjFcxjI3L5df9uLWjuvkl0fSYpQV5dMX1Yus2kXiMHKUeTVE0 NtHqSnozzu88l6D+dCHX0i1BDFgkZi70oGEEaEW0NQgDItOdNwADBQv/a0d7nasV4JW9mjtF nlJDL9pyXHuGc+y9vfJNdy+DlzuHB44vtl+yH9ecTdpxE7RgB8ZvQvEwUmV+keBw+5NkR3ms +AnPrwZxwAIE/DxnwyBAQETkf9SIBH8cz0BCYQ37B+N4OW/pkYSWadjn2Bgi4IZRWyrDmnAI KwsGzfGUxPIKI3AMcRFFqjdhMaFo3L2GwJ2o0dBxd1LN0Xo6298ydcjrtAbKI1xuNXBfBAeU YCzGjg7cUw6XXfyjU5rTQkxKTu13xsKUwCnse7jOvDnfdNnYC+n7o4WNQBDhTiF0QMZ482ba FtCKcqdQJ3fQ9uioh1kOZirhJJ40xtYrDLcS3H9rQZff0X+CeOa94EdJYYYH7BIpysrfJ9c1 cxrg5brzeb9ofWaxLQvRIXBubbDtd0AunQMJXTfXHUmgYCdzSZVyy1tUzso1QacI4D0PhRIo euP8ihlWhqnHRv5tY8Ue18uFybaVIOWrsXXjQOVBUvXFmYCc9ykvJcyYSadLYkJliEYEGBEC AAYFAjdYKtkACgkQT1hOuPsr4U9xEwCeKB7jHvmUrWnuxsqx2Flvq2/gIk8AoKkOpGf2jud+ 8uWi5c1ohHWeuLtz Message-ID: Date: Tue, 23 Apr 2019 20:58:29 +0200 MIME-Version: 1.0 In-Reply-To: <871s1tyvkl.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:XmBJRTBF5YhUBlS3NOUvrccgn4DQdakUG4XUS5Cv/hUzEo9mpts r0M9ItK4VLGPAKz7OgFPq+XRjNtvKz+zVRZzu6PocT54ckM+jABYEO2/usexNYGo+yqS8R4 j6zR/HMxjRPHszbzVEeHYdWJNSouvlofzTDJUCwJm0tKHAMZV6nVi5d6Ekx//EeRzmeFjNk GEz7RPBfuB1eWEMTilIHg== X-UI-Out-Filterresults: notjunk:1;V03:K0:SaJ3AgUTpds=:ajGhkl7HOTBq95aXmNmOdo AUsjK8qoA1cyMbItiCuCkAZlsoreNE52mC2hqFnKovRcs3baSGDXdIO5ojV77cARhFXwwrIQq 7tua8edpe9NIKBiOUNMMo8vg+vhIx/1SwCggugbkP2D+zYV0MildPN4QgD9Bu284bTXolMBn3 tzQpiLaZViLJ1019at9A1v3UVw9ke2aap6ax/p/7MxuB/5Ke8/brLptuyirQco+Ks1MIL3x5c JDIfltE6HB4K2UOVJDQascFmQ5Rk5kbygy5tEdZZaDdNz9yihG4rMQm+KoVSolVbnc/dHM5Up DYcWHE6Q2m7lR5brKS50KXjaqxj3N+F6nhV2G7v2zNFFKrxM6xtQLV4SOtXe/4ITTPT8dEs1c lQnN5SjdMWMZ3ECO/bfBtPsSLnbMmKait/0Z+8Agl56o2ZJmi7XmIkCghXq85evZ2oppZ+1Ax ClkMw2LAMZh1M7Gsp4dzFA/UJ4Xj9r81A5ojeBXkBbZ3mHhaEtYeNzvOfMlErh0GyqdOfkfYb VtUxY4fEEZBUzbbkyuGOBIAFOj391n9H1j6nISZRikG/gJi7iGIr89ZizBq5vs+R5YPoo65LN I0CA66Z2+MrReMI7htHZMk9pIJ4SOGue1oil0JoA21xB6oYwapsmQ5KsM8DvjNFtqdDzvWzYq B1wGwoYvau4kqIZN5YwFZZTTJb2MgNeDEAB0kAeWITlBBFwqWTpLyFCQ7pJmF/vfFVsMmncRo qKI2sXGlbwJpwpGSwOXOtYsTkfFw8avL1YZwjdmWaaeb66W6aHczAarXsNxUiwFdmSLytqwCf 5/FWWEB5F9z8m2xhp+/RSXpi7MXvJCq4jcDQvekUkgDxdotmS0Vz/PLrMkiDfSyCW9lJUrnJI VFMcog8tt5oKZANyCoQ1kLloelyVDmQFXIPCrl6YBl+6RVHkpYSqxnVwl0/mF+l4IP29rmZJj PhX0rOIpAWg== Archived-At: Subject: Re: [openpgp] v5 sample key X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 18:58:32 -0000 On 23 Apr 2019 10:28, Werner Koch wrote: > +When a V4 signature is made over a key, the hash data starts with the > octet 0x99, followed by a two-octet length of the key, and then body > +of the key packet; when a V5 signature is made over a key, the hash > +data starts with the octet 0x9a, followed by a four-octet length of > +the key, and then body of the key packet. This change seems to be reasonable. But how V3 signatures are computed? =2D- Heiko. From nobody Thu Apr 25 01:35:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35E5120111 for ; Thu, 25 Apr 2019 01:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=jKo1KZ/z; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=JzDJpUy7 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 KR9tZtyMV_W0 for ; Thu, 25 Apr 2019 01:35:39 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4671200E5 for ; Thu, 25 Apr 2019 01:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902; h=Content-Type:MIME-Version:Message-ID:Subject:Cc: To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AH66/lRhjmroWWKMnK83s8HIBPqG3XoIIzwNNG71N9Q=; b=jKo1KZ/ziF9LcF4kxq7JSwaf3L MLmfrnKQHvoDGkS0zxrNuF/pCyRkM54GFHN/PSIzltJyKtoUxVAlwWFzvZxb0rHqbLlcVKjizlnNC 5Y9A6xJCvxebpvszRkxGuTkZZwADj06cGhki24kQ7vdhy5u5VSKJNBql16G6gwtk9vVLNIOlmB6T5 5gqdhWZf99Yb9ByWXOqPfDmcnpro3yH8wIORWhLYoQoYlnGWB4khZVo8XWk5IHsXPUZrSpc/j3ZPc UIM3a4VJ2wwxMSoPRm/WnWKA+MMgDgoO436wqibca8W00M5zl4o5AcCHpiv3Bxec/KZ0gt7vLo8hy joZ7K1+w==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902e2; h=Content-Type:MIME-Version:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AH66/lRhjmroWWKMnK83s8HIBPqG3XoIIzwNNG71N9Q=; b=JzDJpUy7+J8krwJwdbLAZ29dE3 1xwJNQ4yLJPF4y+1x9zpOXZOAJ2AEMS4t8bLPqaESR/6ACDLp3xD4TKwhVDQ==; Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) id 1hJZqw-000IIv-JP; Thu, 25 Apr 2019 08:35:34 +0000 Date: Thu, 25 Apr 2019 01:35:31 -0700 From: Phil Pennock To: Daniel Kahn Gillmor Cc: openpgp@ietf.org Message-ID: <20190425083528.GA16784@breadbox.private.spodhuis.org> Mail-Followup-To: Daniel Kahn Gillmor , openpgp@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: Subject: [openpgp] draft-dkg-openpgp-abuse-resistant-keystore-03 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 08:35:43 -0000 Daniel, Still loving this document overall; there's lots of overlap with some design notes I had for an SKS replacement, back when I was thinking in terms of onion layers of filters to be able to interoperate via the SKS protocol but restrict what was sent. But frankly, I no longer want the cesspool data on a machine which lands me with liability, so I've junked that idea. Although I had some stuff around tombstoning and I needed to investigate how the SKS reconciliation protocol could be ... cheated. I settled on "we" rather than "you" below; I don't mean to presume, I just mean "in it together" as opposed to "all this is on you". In some of the below, some of my thinking from that project carries forward, including the idea that advanced operations can be performed with a dedicated client which can PGP-sign action directives to the keyserver, to authenticate certain actions, as long as the signing key is "sufficiently trusted", which might be "is in the strong set" or might be "ACL". (Or "in the strong set and matches domain X via direct trust path from master key in X crossing only signed uids in X"). Perhaps a section 1.3 as a caveat to readers in the far far (far) future, explicitly noting that restrictions on fingerprints vs keyids are based on an assumption of V4 keys per [RFC4880] and that a future revision is expected to make the fingerprint be the keyid. I'm sure that 4880bis will be published one day. Or perhaps 13.2 is better (except that there are earlier mentions of the issue). (Are there any gotchas around V3 keys which we should mention?) In 5.1.4 the hinting for redacted user-ids hard-codes SHA256. Given that this is just hinting to match existing data from the query, I'm having a hard time seeing how a SHA2 family attack would lead to problems here, so simplicity says to leave it as is, but it feels strange to introduce algorithm inagility (creakiness?) to OpenPGP. Besides, just because I don't see the problem doesn't mean it doesn't exist. All tools which are going to match are going to be using OpenPGP parsers anyway. Can we just prepend the one octet hash algorithm code, but specify that SHA256 is the only algorithm which SHOULD be implemented, both client and server, barring future cryptographic breaks and failure mode revelations? In 5.1.5, what is the threat model? We seem to be switching to protecting an innocent client Alice from malicious upload by Mallory via redaction, to secrecy in public key data and letting untrustworthy client Ursula retrieve keys via fingerprint (which they must already have) but try to prevent Ursula from knowing what was in a self-attested identity? I wonder if there's a model for a section 6.6, where keys can be tentatively accepted via bearer token in the upload process, to facilitate PGP keysigning parties? I'll outline my loose thinking for this, in a way which is far too specific for the draft, but might trigger you thinking of even better approaches. My loose thinking for this is that anyone organizing a keysigning party, if they're already in the strong set, would issue a directive (aforementioned client tooling protocol, request signed by their key, so the keyserver evaluates and trusts) create a keysigning event, first-come first serve "Phil's Example Conference 2019" for instance, with associated expiration date, and be issued a bearer token which can be used for upload. I suspect that GnuPG would accept a simple patch, but really the client upload of a key is then just a curl(1) invocation. This puts the key into a group where general retrievals won't see it, but specific event retrievals will (second part of needed GnuPG integration, to give an event code or something, without needing the bearer token). Bearer tokens will leak, but not too fast. Folks can upload. Any key which gets enough cross-signatures will be promoted out. A nice UI could even give summary sheets for printing attendee lists with fingerprints. The upload might even trigger mandatory email address verification, so that party attendees might stop doing the caff thing and instead stick to validating human names and rely upon the service to have validated any email addresses they're signing. Because seriously, even amongst PGP keyparty folks, the number who bother with caff(1) is vanishingly small. I think I'm one of a number who I might count on the fingers of one hand, that I've encountered who actually do that. We can improve the ecosystem here. Other approaches are to just say "run a dedicated simple PGP keyserver for the event, we'll try to upload afterwards", in which case the 6.6 becomes something around authenticated upload for dedicated event keyservers, suggesting that "login" might be appropriate. Which leads to a thought: the models of accepting keys don't seem to include "non-PGP login". Eg, SAML integration to let the employees of a company upload PGP keys and strip the uids down to those which include their email address, or policy-allowed groups therefrom. This would not be first-party-only. So a contextual mitigation is "identity known to keyserver by external-to-OpenPGP means". SAML based OAuth2 flow being the example which makes most sense to many organizations. Or is this covered under 6.4, exterior process? In which case, I think it's a suitable second example. This might also factor into a valid criterion for section 10. Before moving on: how do PGP keysigning events factor into IP rate-limits? Part of my thinking here, with conferences behind NAT, is that ratelimits might be raised for the bearer-token uploads. 7.1 nit: "if the keystore have a" : have -> has 7.4: earliest by revocation date ... this seems to open a window for confusion if Mallory generates a new hard revocation with text saying "superseded by this key 0x1234...4321 which you should trust, no really". Humans pay attention to that, even when they shouldn't. I think a keyserver should remember both the earliest by revocation date and the first one seen. We'd just have to accept that in a peering system, if Mallory can race out a different revocation, then different revocations might be presented and some people will get untrusted text pointing the naive to a bad key. No worse than the current situation, but better than "spec says we have to propagate the reason for whomever generates the earliest claimed time". The one situation which has me being more careful about time-windows is generate-time revocation certificates being typed in and uploaded. 7.5: I was thinking before that there's an argument for "don't reveal any PGP keys which don't have a timestamp from the past 3 years", where the timestamp of an updated self-sig would be sufficient. If a human hasn't done a keep-alive in that time, let the key stale out of the system. Just move those keys to the graveyard, where they can still participate in web-of-trust reachability calculations, but not be retrieved. Interesting points here around "what about attestation sigs on other keys? If K1 signs K2, does that extend the life of K1?" and "if we keep keys in the graveyard to preserve WoT and signing another key doesn't preserve life, does this prevent _new_ WoT links with signatures after the date, until the key is brought back to life with an updated self-sig?" 10.1: should No-modify have any impact on keyservers not following the section 10 model? "Don't accumulate signatures by third parties"? Is this actively helpful? It seems that GnuPG is setting this by default and I don't know why. My main key and my new work key (generated by GnuPG 2.2.15) contain it and I know I didn't explicitly request this last week. 13.3.1 nit: potenitally -> potentially 14.3.1 : a local-part can be a quoted string. These are valid email addresses (by explicit configuration, not catch-all): "X'); DROP TABLE domains; DROP TABLE passwords; --"@spodhuis.org ""@spodhuis.org a~`*&^$#_-={}'?b@spodhuis.org I haven't double-checked lately but all of those should reach me. One didn't even need quoting. I've not yet had spammer web-scrapers pick those up despite repeated mentions in public mails. 14.3.3 fixme appears to be truncated 16.4 nit: "How should in interpret" in -> it 16.8 : should there be a warning that encryption to a pool system may not offer the privacy expected? Feel free to lift text from: Not covered so far (AFAICT): Operational threats to keystores: if the public pools are run by volunteers, traffic abuse becomes an issue. Eg, Beyond the threat to willingness of folks to offer gratis service to the public, is also there value in a section on good practice around not even needing to use keyservers? Avoiding being the abuse, or just resilient configuration. Regards, -Phil From nobody Thu Apr 25 02:11:39 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0E12007A for ; Thu, 25 Apr 2019 02:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earth.li 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 t_oTCwVT0RcS for ; Thu, 25 Apr 2019 02:11:36 -0700 (PDT) Received: from the.earth.li (the.earth.li [IPv6:2001:41c8:10:b1f:c0ff:ee:15:900d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C859312006D for ; Thu, 25 Apr 2019 02:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bSdSuZGFZLWMvIk5mQucFg4OtFil8NVUWdG5BijbWAI=; b=mvioBieXxbP+Ck/pmOIlblASor RhNw8fO9f+yTgR+cZnsK/mrYivDKWQPgGjaKwxBycO9cK6vSTNJxbx1dw1sbYftWjbVd9NUqQwgfX gmPdP6KEL0ODAl5ByLJcHuYjBSdFlUPgmcxFjVXq1m0YUL5mkLg4rIBNvyTNHInUAGkI20QjR+R++ OjEzUkXpBtLAe+FxeIVhdo+p+zU9+0FPpm3I3RLkIvlH1SEsvl9wjxi8NPOo+QsJzIhYBUTz+pX+x QNM2mKaSBUsOvX1j9p83Fw6Qq/p/1XK09vrqcnHtOAIWCeHJ7YTbcnX4RKrJ3ehKoGcCt9xOdtJiw UUAJzVLA==; Received: from noodles by the.earth.li with local (Exim 4.89) (envelope-from ) id 1hJaPl-0006bJ-Q9 for openpgp@ietf.org; Thu, 25 Apr 2019 10:11:33 +0100 Date: Thu, 25 Apr 2019 10:11:33 +0100 From: Jonathan McDowell To: openpgp@ietf.org Message-ID: <20190425091133.ayz4wyxzfe3xwdwf@earth.li> References: <87sgvh1ugy.fsf@wheatstone.g10code.de> <871s1tyvkl.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ssgqdaa43cuqvjfd" Content-Disposition: inline In-Reply-To: <871s1tyvkl.fsf@wheatstone.g10code.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [openpgp] v5 sample key X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 09:11:38 -0000 --ssgqdaa43cuqvjfd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 23, 2019 at 10:28:26AM +0200, Werner Koch wrote: > On Mon, 22 Apr 2019 08:55, HeikoStamer@gmx.net said: > > There is no distinction between V3, V4, and V5 signatures resp. keys. > > However, GnuPG computes the hash in function hash_public_key() for V5 > > keys in a different way: starting with octet 0x9a and a four-octet > > length is given before the body of key packet is hashed. >=20 > That is because 12.2 (Key IDS and Fingerprints) has >=20 > A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, > followed by the two-octet packet length, followed by the entire > [...] > A V5 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9A, > followed by the four-octet packet length, followed by the entire >=20 > I think it makes sense to keep the signature computation in sync with > the fingerprint computation. Using the four-octet length and thus 0x9a > is important because it remove ambiguities if the key material is larger > than 2^16. A move to easily enable key material > 2^16 bytes seems to be in conflict with dkg's work on trying to reinvigorate the usefulness of key servers + the suggestion to limit key material packets to < 8383 bytes. J. --=20 I have seen the future - the future is Channel 3. This .sig brought to you by the letter S and the number 38 Product of the Republic of HuggieTag --ssgqdaa43cuqvjfd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEERUuPEyEc/2gMWDpQ/xYvxc8/utEFAlzBecUACgkQ/xYvxc8/ utFkrhAAopUSDAY563ZTJKmkFYGhefrc3X42Neos5zXSpyEbVFRJdYxM56VONr+j VNTOgEOYCtTTIftv/wjJQyUg3uSQI4e7fLmfnf2EWdeWrfUISAdjAcaCZg4Rz/7W I3/2DumG24BcPvVMYth8+jjxNCpOB5UCakBHurKf8Ih7avf2Epeka/DzJexr4EWB Opkl95GucyymTP6JKYhhxfVEBWez7tbEUF0/4WkSzhbzauqtrK5AQYeazQyUNWGp oVuqUaYNWWz941mEwxScwIeqNnygfb+J2z2AkIq5IaqALV+/Y2zMFKBNwJPwpFjn XeaMx+fWpXqIxTF/li/pdVp1fLaan3T1Xavck3bqlLC8DkUuQvWafirgAJWq/hHd q+T8I+pK+8RglHCzq+32uzThBMJzKIkMGjcR2zkdyB2VBM+zDzhkr22CGNqPOyZ1 VqciSQfgM8WPfvCLG4uWYYguuNKD8je1JWzlLcIXZEOrc+smqyz6us5lZGDUoGiy u4o/OqUUAgrhiwIg41JZBy8kUBD8GYOzxITOTuGWwdC4OGaeTDzlui/LVdkEQUHL IMAUcY9sJMY5ZdF8Sa+FU7DCEx2pP53bUc1+DbsTkQUx9qF5lqSzWdQitnhD6fuG fli2TG8e6lO4LzP8khRcsQDwdIC6tt1R56p54B+yqe19etjU1DE= =EAG2 -----END PGP SIGNATURE----- --ssgqdaa43cuqvjfd-- From nobody Sat Apr 27 20:32:14 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8080A1200B1 for ; Sat, 27 Apr 2019 20:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8r-9aaHUjhWc for ; Sat, 27 Apr 2019 20:32:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD1F120048 for ; Sat, 27 Apr 2019 20:32:11 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3S3W7aj019634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 27 Apr 2019 23:32:09 -0400 Date: Sat, 27 Apr 2019 22:32:07 -0500 From: Benjamin Kaduk To: "openpgp@ietf.org" Message-ID: <20190428033206.GA60332@kduck.mit.edu> References: <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> <18FF6D9C-B285-406E-A344-E6362646DE68@icloud.com> <875zr5ywd7.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875zr5ywd7.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 03:32:13 -0000 Hi Werner, On Tue, Apr 23, 2019 at 10:11:16AM +0200, Werner Koch wrote: > On Thu, 18 Apr 2019 17:28, bartbutler=40protonmail.com@dmarc.ietf.org > said: > > > hope Werner likes this because GnuPG is already doing 8KiB chunks, so > > I am not sure about the context. Are you talking about the partial > length encoding or about the AEAD chunk size, a modification of AEAD to > allow detection of transmission errors before the end of the data? > > GnuPG 2.3 creates AEAD chunks not larger than 128 MiB. This can be > changed with an option down to 64 bytes. However such a values is only > useful for regression testing as it slows down the performance. I may > consider to change the default to 1 MiB but not lower. > > Let me repeat that the whole discussion on the size of the AEAD chunks > is mostly off topic because the chunks are _only_ here to allow I'm willing to believe that the reason you state is why it was originally added. But the volume of discussion we've had already makes me pretty skeptical that it remains the only reason people might want to have AEAD chunks, so your argument would be much stronger if you made some reference to the technical subjects that have been raised and why you believe they are not relevant. Thanks, Ben > detection of transmission errors before Gigabytes of data have been > processes. This was the reason why I suggested to Brian the addition of > a chunking mode for AEAD. > > Whether the received data is authentic can only be asserted by checking > the signature and that can obviously only be done after all AEAD chunks > have been decrypted. > > Those implementations wanting to show a preview can do so regardless of > any AEAD validation etc. They should just make clear to the user that > this is an unauthenticated and possible corrupted preview of the data. > > For all other purposes I propose to use a different protocol on top of > OpenPGP a (e.g MIME) and not to overload OpenPGP with unneeded stuff. > Or well, start from scratch and use a different name for it. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Apr 30 05:29:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81894120045 for ; Tue, 30 Apr 2019 05:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_RP_RNBL=1.31, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 pkD8UWRa11Hk for ; Tue, 30 Apr 2019 05:29:38 -0700 (PDT) Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6906D120025 for ; Tue, 30 Apr 2019 05:29:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 5021C7C9F30 for ; Tue, 30 Apr 2019 14:29:35 +0200 (CEST) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkmS0po8DgQB for ; Tue, 30 Apr 2019 14:29:35 +0200 (CEST) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id EA2F97C9F2D for ; Tue, 30 Apr 2019 14:29:34 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 35964BFABA for ; Tue, 30 Apr 2019 14:29:34 +0200 (CEST) Date: Tue, 30 Apr 2019 14:29:32 +0200 From: ilf To: openpgp@ietf.org Message-ID: <20190430122932.GD1456@zeromail.org> Mail-Followup-To: openpgp@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NtwzykIc2mflq5ck" Content-Disposition: inline Archived-At: Subject: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 12:29:42 -0000 --NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable https://github.com/RUB-NDS/Johnny-You-Are-Fired https://raw.githubusercontent.com/RUB-NDS/Johnny-You-Are-Fired/master/paper= /johnny-fired.pdf --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --NtwzykIc2mflq5ck Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAlzIP6oACgkQFT/jmIIc g5TNXA/6AvTtOXD14ikp/BwXuDF5/txfUoVEDUdZX/gzTjAXafgi01YmvCgdyTFC aRdPBzEuqlOr7oHD15mUMRCQNM2tG6YdBY+DhYG9FORkDGlwnIa6+lOrh5d3QHY8 aT+EkigDaEpYcmTO8etpy92PmgfGkcJ6kN3BZ0nTD4HdVpM7c4j1drLaZvc7UNN2 A0ozjPUhXd9lstAJM4LeG+cYpXv/XzY7DBSKWPzYgnl5xSRSeveLGSbLFd/hDJS/ q3iGcjwFa9n7bNl0mxeNhvc54T7bcfpA75OKuuehCkjsxOcmZtdJ4SUrt2g5+YFL yXWV/5eDj9tKqkf16ymmksv7pimUf04g1wPiC8l9kRNXm9q6n54f3YyRxzyBQrX5 0ILjV5GHa8EYAOQtv7a00evx3xQaPZzNwJGGQopEJUihkZtkPIysaqSUoIAXPvBJ D27i1mrobpEG0wJ/w6bSiTPOTzvVv/0QAv1xMR0I7DBNdBdib0Pl3eMqISAoRRcH bUdq2KAcvjPCfgYLVT6aD0OYqDnvD7wNHZaIzMAus/r+0Tpzj19uiaI6crLrPb7g VHcG3I2PP1WojzWQQgJcRqard2+0IQEMvAOjPjDss8lnrXLCdVk1gUF/ywk/V/r4 cXMsv/w+Q1DtJJzft3ZwI7FERLEMSlWZPyeKz8NwTX9yQBta2RM= =q24G -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- From nobody Tue Apr 30 06:19:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8793812007A for ; Tue, 30 Apr 2019 06:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 4XxD_TfUuuvW for ; Tue, 30 Apr 2019 06:19:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23549120075 for ; Tue, 30 Apr 2019 06:19:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A669BED5 for ; Tue, 30 Apr 2019 14:19:05 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw7eN6gE09Yi for ; Tue, 30 Apr 2019 14:19:05 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 08602BECA for ; Tue, 30 Apr 2019 14:19:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1556630345; bh=IUD/AAXkQhMwfZor3eoQouuaXBxpf94I7iD5ea8iupE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gp5/X7audwDUuVSoMnN1/xELhcCqLj3CX5ROWfUaWjJlVx8KY2o4UWU0GPIP5jj5K ZUeXNB8gsVjeGB5SDU6jvd7GDeTxN2KBng0KQwZVx0xMG+S0hY6d6pMHIc+iMxZaJ5 w6CS9tWLTrGXZoFspZ+0QZjE7zeiiK9/ffEcdKSY= To: openpgp@ietf.org References: <20190430122932.GD1456@zeromail.org> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 30 Apr 2019 14:19:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190430122932.GD1456@zeromail.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RTfsQU03faoNuHTgObxk24LqRRJAERrSr" Archived-At: Subject: Re: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 13:19:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RTfsQU03faoNuHTgObxk24LqRRJAERrSr Content-Type: multipart/mixed; boundary="pDmqKcne15bJu6szuXQ01YlwcwzN9h1C4"; protected-headers="v1" From: Stephen Farrell To: openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails References: <20190430122932.GD1456@zeromail.org> In-Reply-To: <20190430122932.GD1456@zeromail.org> --pDmqKcne15bJu6szuXQ01YlwcwzN9h1C4 Content-Type: multipart/mixed; boundary="------------0824999689ECC4206EA67033" Content-Language: en-GB This is a multi-part message in MIME format. --------------0824999689ECC4206EA67033 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 30/04/2019 13:29, ilf wrote: > https://github.com/RUB-NDS/Johnny-You-Are-Fired > https://raw.githubusercontent.com/RUB-NDS/Johnny-You-Are-Fired/master/p= aper/johnny-fired.pdf >=20 Great work, thanks! I guess that's another fine demonstration that code that's not really used in anger enough tends to have lots of frailties;-( A comment and a question: - I think it'd be a fine thing if this were to be presented at an IETF meeting - if some of the authors are going to be at one of those (or would present remotely) then contacting the security area directors and asking for a slot at some saag session would be a fine thing. - I wasn't clear how to interpret the missing combinations from Table 2, e.g. does the lack of mention of the Linux/TB/Enigmail combination mean that it was not vulnerable to the attacks or that it was not tested? (Or that it's almost certainly vulnerable but you'd already broken so much so well, it wasn't worth specifically documenting;-) Cheers, S. >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --------------0824999689ECC4206EA67033 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------0824999689ECC4206EA67033-- --pDmqKcne15bJu6szuXQ01YlwcwzN9h1C4-- --RTfsQU03faoNuHTgObxk24LqRRJAERrSr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlzIS0gACgkQWrL68XsX K+pQIBAAyKL6E3GYGC9ouxncx1B0BnSdxVtttUpe02n+us7PXpy7c2j7JU1tTvkO DREH8F3mFojhwE+ccs9lpeuN4l0N78aogen3vOB6bGX7F/a17SrVH8cpcavKJeo1 kBCEQKik2jDtKhT38/X5NK6EgfAeQkgs2WDxHEsd4HIFGT7+MtkksE5WIZZL1s84 It8MS1T9VX+hfseyUTcJlmmXIzUx1rNYB49xQE+MBSB4CELnsEzuY42tR4I9XEVc U59fAsi7S0G3d/Hma7hhGo2+T9CGx5hoirgeK0WVXQlpybg3owuHmEs9+189QcCh NXbLK/PJTdbnyYD5rCwcssRYzChoAFlugHvfYY/dYceZG0R0gM5fo+eH12O9ibKm 9a+0VJyNvrXuMkxUgbAyHnlgmtEMQkmwOBQmi4Z+XaXmdc44Q2ifJ97GMwWn2hjF Im396rwojKjHKiVGRod6UR1i5kR/8ez+xBNjtxNjYqlz4ekOju0N9Eyld02oRAk5 TMhEy3AD8rYKdvzM67JcvAAL671qdlbvmA9SZRkF1brQiO5rGwauNJZU2Iwep/G/ zpoxqXCiV/MgIOCxTVnzw57XlflLVdcfHzVtex4km/sD0kArl58Pb+0Beu1J9g2o rzqTew5+/DNBuGNoMIgOj0/ccc8CzvMLvF/DyhCj6KrldhNEsSI= =NyFx -----END PGP SIGNATURE----- --RTfsQU03faoNuHTgObxk24LqRRJAERrSr-- From nobody Tue Apr 30 07:04:58 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64075120108 for ; Tue, 30 Apr 2019 07:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 X7YcvReyzY_I for ; Tue, 30 Apr 2019 07:04:52 -0700 (PDT) Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [134.147.53.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72E51200B6 for ; Tue, 30 Apr 2019 07:04:51 -0700 (PDT) Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44tjvh4yv9z8SKr for ; Tue, 30 Apr 2019 16:04:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1556633088; bh=kEUv2hE937Vo6tmsxnUCMyyzaa9TJSOz8dU0RShJiPE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=OjtfLOaTR9DUhmL6jJMgLbypI2Oo/8JLMErqwrbaExE69qUbax/nPjmOSrG1pgQD5 AsJn8LXZgntbmcFb40HMjdogh2zL8qDOipRmSqWYcgkxOJ93RDWHWvNiXu+cjdrJxj obh6p834ClmadKvgpqTy3LtHMvRRt6yZ+x4cQp8Y= Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44tjvh3Z2Mz8SN4 for ; Tue, 30 Apr 2019 16:04:48 +0200 (CEST) X-RUB-Notes: Internal origin=134.147.42.227 X-Envelope-Sender: Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44tjvh34BHz8SVk for ; Tue, 30 Apr 2019 16:04:47 +0200 (CEST) Received: from [192.168.1.66] (unknown [134.147.203.251]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44tjvh3y3Lzyt3 for ; Tue, 30 Apr 2019 16:04:48 +0200 (CEST) To: openpgp@ietf.org References: <20190430122932.GD1456@zeromail.org> From: Marcus Brinkmann Openpgp: preference=signencrypt Autocrypt: addr=marcus.brinkmann@ruhr-uni-bochum.de; keydata= mQINBFZU6WABEADoVonKbB/tV0v25cm39DaSZyN7it70RhTZHLESbpDiHCwiAMi74MK/HB/q VR9LZDkTDF1x5xUnxxMHa2rpxO329dlk5dQFq1iELxIC/yBCEh5HMLT5MkWqwb8UkINYpaFU csQdPvdC2RzZ4Wt5/xX/6mvSnA4g7hSmUKwIiDX6489Fj5jHK3i0UQFnzKty3O7mqSbedTHs ym2q6fPcIlEOvU6unzxJRK4bgfW2NBM6aMqgLeQkKYIkd1Q/OXEWCXC4hQJepak+n34ChIrV RRHIBJ0GHRkEgHQgQUqPLS0fJlMYCaSZFmOAaqmigxVn1ErG3jTnFQPbPkfE5SCssFP2grNV N1ikJzOEpBLYA/4pOaJzSnZ0xx9aKPdUsyBksKmCsLQNiRt4ZTNFpJ2DJ8NbXYAFkrcu15og lrB//CVQj3CfkzUbpyfcwJHAho1K6XaPybI14znuorTJF3ml0qDd3XDkcmnF58s4hfvGHQtz +CEW+85gUF+T9jKLpwNGcNdBhbvdE6d3cSbR7dXeZsxiA4AmqqEhH6SnVmkSqmhX4+k6RksE MrHJnzefTyA4kXIR2QvD60nZXqta35VhhCzIcpkUpxcwABBR7C8nCxiGV7wNmGECgHv+Zl/O hQhWF1Ld1G93xCg7D+Nz0RerRdwtBOUatmCp+2HRTcRXNOW8jQARAQABtDZNYXJjdXMgQnJp bmttYW5uIDxtYXJjdXMuYnJpbmttYW5uQHJ1aHItdW5pLWJvY2h1bS5kZT6JAjgEEwECACIF AlZU6WACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIiwjVpXtiFAHDUP/0PuDwhn Cyn7b2S7Lrn0BBmi3LOS4ioalCZkV6BenkXydeGwJ9CVVix9WEbiLzCz/DHfvz97l/T9lxcM bACc1tX5a+qvqydzKd2eXFnVdH1JaihqdhG7sWYi22H1uWSyWbHd3rBZaDAts5Qialdg+WC0 kHh9pkmmlUE3BIkTaIOA9k4J93hz4QDOEO7xjB9XMOIRuasZ0lOOPraezS/pKLaQHlzPJZfo QEGL3ndn8U1FXZgR2DWhGtbClEvLaNXJ7RYhIlCeEwCwsTuGg48iDYC0+phvj/nwhZV60+Eb lR4Kux4DjY65s4Rp4kIzh51PRE+bLHtULPx1x9X1x5ZekYQdgwf6doBIIauARZFaxI6dt3i+ HSMjpga3k2Xn5iCaf6NeG1J2bh9sEAH7nntibOOp4sT8YR2SiQ5ab8PnDkydwbghUZcJ39a/ CZnN3f1RFeRX6d3zbfULPsf7o0LM/IvNKFvBoVzVb3AVYdhe5FNOE0DfhOe8lpE88ofu+es6 ECGumfR8UEcQc/O4dSyprngxZjjEdgdo5KqUkCEeGM8lVp+EFcmtLME3uqFhsUihk3YfF9Ni vZ0/0ZcLsmMp3zCZ9wS6HWr2UTkYrgc7Nr3YBClDs9W/jurcSPMmpwwhq2ycWaMMMPqULS4c U2vhGKh6JDPqfIfXFQIfhiVwCMx1uQINBFZU6WABEAC3meKoeQn4r37Z1WCvl/lRVgwYLIEw GX94WCZODxPPEy2zTWStj45yv1ZrSI0HyAqssZzXPelOFJzlM8M+iccxIMRgjnnGJJR0YqYU draf1Z2YQk/x2WjYNUg0blChdyeqwBhLAQKtnPOKkTPZBBGzPjsS+JeB8yN5r4vouFGMG+Cm YFUy4oCmcmuUrdLm9NlzM5ituyTJsPG9CDO834e4qlZsNW/yEzyPsYDW0PxJxgEe/WjLsDJ0 aiwaDhBpR8/i2FfEUTGXl+6wvdXR9lhddBoiUCVlNRu9jiKVxv2JVJepcZa9B/atJwcsDAkZ JgnjP0qRybixx/wo14KromgWVBGwpZ89sFEgZF6HcxPMKuWtieIORzs9kb0jpMFi1hW9xi60 UBHikrpDG9MnwA35d1lg/9kUlrF1nqTnyoz43UxntlgQejl6JcBR2Poaaib3ZtCR34yxslFz 4znXBermA2eEvusEmjYJlxPWozW18grbSYUr1tCmjvKZAIMrspVx37+WSm/4fy8Mq9iqhkIw eFQM10GL+fRQOGJTpSY/KiGxmkaTPtj9iaovJOcGAjUzzreGhi4toIrWWULPNKS6vuV4VgMB F4XxIcVqC9I43yzJ6/cYciwL9bxoWQ4EpHuIG3sewvOWbceeDO9j9DRSd9E6GX67NzrruDPX Ooge2QARAQABiQIfBBgBAgAJBQJWVOlgAhsMAAoJEIiwjVpXtiFAHBwP/3x5953X/1jR2Aeg R6oHSF0HAD8kMnKLP5cwLqrOzUpCwqzFGBCbYdvxrWG106jyvcZdUvtBSGd8n1FuE2WrpQrK gNjdRG65cN2kduk/w66Oq57EqSuO/r6OnadG9hgVZ1YP/QUsL6n4oF7coD0CJiH98UyLw1yP 3Em1ONX8ditvMVHNudVC1VoEN1BFjIX9VWqWoU843vPct9wKi6jLYHHAX3UpnEJtfqLHCj55 4s+0yhMhoaAIfNQZWU9iKzldM6Y0j8DJ/YBSThhw9S/TX7mClhXArJ/iPJSr6FPhlQMMcZRQ aSiQu1gDL76I5G03SkBWCnXbSpeNtTeMiSpsA58c8rpr2T4giCiV29FPgEj4We2/jBrBcwWA /XjSLE2RNOnF2G65dVxHAlaCc84lC2+bh9kVU+Tb+9YDWfHyNO+pNk/Lpaef2Kg6ScKmte6+ wVkWQZFTU8mgkHZqFvQk29RnV02phRTM0ryvWWldNgf3vzztS3iyD3GrJCPcxjm24cAflp+7 JfQ4qV/ec598k++HI4r3SfmSFKFcsxh+073p+oVjs5kIHxM0SExdjKewLOE3BKQYjn1r17xW XogKlIGbTEluQ4Odyh4n88/iA8ZLNPKjvjno7UuwBsZyJxdaTOXlQYt+ZRZNfIBSWqv0U9fY tp9qPuy4vCfkycCucIgO Message-ID: <155a904b-ca77-d38b-e5d8-eb42c816d1e8@ruhr-uni-bochum.de> Date: Tue, 30 Apr 2019 16:04:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 14:04:57 -0000 Hi, On 4/30/19 3:19 PM, Stephen Farrell wrote: > On 30/04/2019 13:29, ilf wrote: >> https://github.com/RUB-NDS/Johnny-You-Are-Fired >> https://raw.githubusercontent.com/RUB-NDS/Johnny-You-Are-Fired/master/paper/johnny-fired.pdf >> Great work, thanks! I guess that's another fine > demonstration that code that's not really used > in anger enough tends to have lots of frailties;-( > > > A comment and a question: > > - I think it'd be a fine thing if this were to be > presented at an IETF meeting - if some of the > authors are going to be at one of those (or > would present remotely) then contacting the > security area directors and asking for a slot at > some saag session would be a fine thing. I don't think any of us are at IETF meetings, but maybe something could be arranged, depending on the details. We will present at USENIX Security 2019, of course. > - I wasn't clear how to interpret the missing > combinations from Table 2, e.g. does the lack of > mention of the Linux/TB/Enigmail combination mean > that it was not vulnerable to the attacks or that > it was not tested? (Or that it's almost certainly > vulnerable but you'd already broken so much so well, > it wasn't worth specifically documenting;-) We did not include redundancies, for several reasons: * They would bias our evaluation result (we don't want to inflate our attack success rate artificially), * systematic testing is a lot of effort, so we had to limit the number of combinations, and * completeness is not feasible anyway. For example, you could also combine several attack types in a single attack to achieve an even higher success rate, but we did not evaluate that. BTW, other examples missing are Trojitá and KMail under Windows. In the case of Thunderbird I feel comfortable to say that all OpenPGP test cases have been developed under Linux and then confirmed on Windows, but we don't say that in the paper. Of course, we published our test cases, so it is easy to check additional combinations and software platforms! Thanks, Marcus -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Tue Apr 30 14:28:56 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BFA12003E for ; Tue, 30 Apr 2019 14:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 0ONqN3N2IaJ2 for ; Tue, 30 Apr 2019 14:28:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EBF120127 for ; Tue, 30 Apr 2019 14:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556659726; bh=XAm+Lt/2ALw2KpQmwiq4hQlqZ7kEwEhF+7BYCW4RFrU=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ZRo/FSfCYJ87fsygv1byjlvMmXoVTgz3xXZ51bMat38Q0R7jMeM3x+0BlJnwjek2Y iDdnDZ04Pu2DQ8qBTIB+Y8e0OhnFbBRo03zQ8jeAsTlQL6tuSGTdZXO3BrVdFLTJTF 2Tq7g+v2GQl4UPQuWLLVuBap8dRFyVKnC2KwbvEg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([80.132.239.73]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdaiW-1h7KB01Kns-00PK3t for ; Tue, 30 Apr 2019 23:28:46 +0200 To: openpgp@ietf.org References: <87sgvh1ugy.fsf@wheatstone.g10code.de> <871s1tyvkl.fsf@wheatstone.g10code.de> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQlSGVpa28gU3Rh bWVyIDxoZWlrby5zdGFtZXJAcG9zdGVvLmRlPohiBBMRAgAiAhsDAh4BAheABQJTnH9pBgsJ CAcDAgYVCAIJCgsEFgIDAQAKCRBPWE64+yvhT4n9AJwNsUcN5bx9/gtUs4LMmqBcePkQKwCf Y4FmM1D4rmTWsHQ1NRgsiqQhc265Aw0EN1gq2RAMAK4ZTZJZeaOmjIYhf9QfN7rQ6iXEF20r OG8NkeHLVLPw02t2QjejO5g4zGQplktPD+JCKBU1B/DL7l8BTDopofw4+fAierJ6C4jo/AbS pArZxaVJNkOVNbwHYPdCmO3yxieeMYQgYoZvtkBSA4OZZh2xLfmi3IRBPRSf+REiqPJBy9aA 0f7634vKldTG7R4PR2UP+THjpM/2SpNiyv/y9ZaEPYn3zHRkWsUw3xAMIiE73Hen6o/J9KIB 2e4jiI3VFiwq0LaKRv5whzltjKydGi2zVqcDLc93lDxsW2OXPE89GH3S/9irlEz/ciBuxtLT MMjSV3OeV34Mid7Muz8RE6whOaZteuEgAcLxONxe3FZHeG2cUuciCZDdFqDRtB6w0XhjltdI ZzD8zHBZyboRfBxubtRzriTxjFcxjI3L5df9uLWjuvkl0fSYpQV5dMX1Yus2kXiMHKUeTVE0 NtHqSnozzu88l6D+dCHX0i1BDFgkZi70oGEEaEW0NQgDItOdNwADBQv/a0d7nasV4JW9mjtF nlJDL9pyXHuGc+y9vfJNdy+DlzuHB44vtl+yH9ecTdpxE7RgB8ZvQvEwUmV+keBw+5NkR3ms +AnPrwZxwAIE/DxnwyBAQETkf9SIBH8cz0BCYQ37B+N4OW/pkYSWadjn2Bgi4IZRWyrDmnAI KwsGzfGUxPIKI3AMcRFFqjdhMaFo3L2GwJ2o0dBxd1LN0Xo6298ydcjrtAbKI1xuNXBfBAeU YCzGjg7cUw6XXfyjU5rTQkxKTu13xsKUwCnse7jOvDnfdNnYC+n7o4WNQBDhTiF0QMZ482ba FtCKcqdQJ3fQ9uioh1kOZirhJJ40xtYrDLcS3H9rQZff0X+CeOa94EdJYYYH7BIpysrfJ9c1 cxrg5brzeb9ofWaxLQvRIXBubbDtd0AunQMJXTfXHUmgYCdzSZVyy1tUzso1QacI4D0PhRIo euP8ihlWhqnHRv5tY8Ue18uFybaVIOWrsXXjQOVBUvXFmYCc9ykvJcyYSadLYkJliEYEGBEC AAYFAjdYKtkACgkQT1hOuPsr4U9xEwCeKB7jHvmUrWnuxsqx2Flvq2/gIk8AoKkOpGf2jud+ 8uWi5c1ohHWeuLtz Message-ID: <02d3c87e-f280-ff7f-5bee-d43c7b763546@gmx.net> Date: Tue, 30 Apr 2019 23:28:43 +0200 MIME-Version: 1.0 In-Reply-To: <871s1tyvkl.fsf@wheatstone.g10code.de> Content-Type: multipart/mixed; boundary="------------0B2318DEFAFB6267C98B0F6F" Content-Language: en-US X-Provags-ID: V03:K1:IY2juReN7NpEhzkVynxK3rkwop+PCHagr4xPmQBna/7FFK3i5W3 vGPDTnywidGyllSVI0EhFrs57fFCgJ34KIu0A1ANR/EhTmQFXLfeXlNe0NRPjcxAAHEawrt aQbVAKGXRXn3P1a4A2BnHaI7BtXp4j+BcmL2ZSLzMXW38xpX0dV1EkN8dCCK/j5eKypXmsX 1BMO3XhHi1mZv7IFv3pUg== X-UI-Out-Filterresults: notjunk:1;V03:K0:RGOoNi0l+MA=:VBNSBD807WizYZKhTiAhZW 6x9KXAEueioG+tYtgGtGe+jxTC63dIScJChJhe707AIt4BeVoavsdbUWWfpkcZ09+lx2KsdrT tzeeFsj5VR7q08cljHy/CkmMGn/dR4InAMreSm4Xjpqw6e7F6DzvluRAtsiAJwYyZOahrzIMy 9RdkcrE/ZeXoue2ijjL9YvtMrLgrqsuNtP4M3CbEFsK8xsOVKsXTkdDBsESy9hJ2dAgYW69uq G9ypU7BVmHC68bAw6zjeW/fxLKX/iEgDvfJJGHDvM4CwxOB8nXJGfsbS1iRJVsYBRoH4YrrMq 3dV+WBDOgJEoJIEFyaK050/biwgbNz4kJM0Tlj/FiK/2mf6rpWFbhwjcf1ZN7/EpW3o+t4/y4 oU9LdAutXZyOtloXHG61TelGt7W7jox9VJUTZM11b3Z6lX3EoULd1fCdpA9s6uBjgt5lsYMnO qSpmksuYEZSrkumipcWV8xXRDHaXIyj0LbBYpimjdl9gNHw2ZlzSDTGm0Pf7Vg66RwuSxQZaO tLk6/fOZn21bFqNkJdICQfc/sq2cBCfc5Ox4ApRXQtAokrBrEsgirn2AohX8V7yxRZnwKQw3m uBP6BfVBe8EjOiRcrL5eGvVhYUmKmDAWnAKiv+sj0aINp8Tly/ad4pKrcOPhDAVXtzZyxEwCC tzGiHxUiV9ZLvsa86YvMbVQClELn1oFf5M+zkC8RBDPEjI9wq81YloYWcKAWasuzZfCscaocD 6/+a9x3vlpznnZAJNbZqXEbFueBn8gXGKDzEwwaaXf0aXKpUD/N2nJAuePrqAit60NVYlJN3R 74TOtcmPH6uHXoHr2inkvjlgX1Ht4jUPmwmfWNQ8r5XXXkX9ulAKH8BaTy/tq+hIOBqcLBL5I 3pcgQHfqn5lHCnSxR3Mp4p8UGvFlBNKltqZsOY8aC8d5MgsDCHlQU5WaZiDDIL Archived-At: Subject: Re: [openpgp] v5 sample key X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:28:55 -0000 This is a multi-part message in MIME format. --------------0B2318DEFAFB6267C98B0F6F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 23 Apr 2019 10:28, Werner Koch wrote: > Thanks for testing. I've attached a detached v5 signature of this key for testing purposes. HTH, Heiko. --------------0B2318DEFAFB6267C98B0F6F Content-Type: text/plain; charset=UTF-8; name="dkgpg-1.1.1.tar.gz.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dkgpg-1.1.1.tar.gz.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IExpYlRNQ0cgMS40LjAN Cg0Kd244RkFCWUtBREgvQUFBQUJRSmN5THRYL3dBQUFDSWhCUmswZThtSEpHUUNYNW5mUHNM Z0FBN1ppRWlTNGZleg0KNmt5VUFKRlpWcHRVQUFEUWJnRC9keVFCaFE0SXRidTNia3lhTFZh aUhoVno0VUZWUEhUbEFPUzVYQ1VTb1hBQg0KQUpRdDhFTjVuS29rWE5ZNGZWWFBJR3EwUXBL VnhSUEthNElSRXFXb3hQSUMNCj1FV295DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0N Cg== --------------0B2318DEFAFB6267C98B0F6F-- From nobody Tue Apr 30 20:44:00 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5C120221 for ; Tue, 30 Apr 2019 20:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 w-hPkxztjS04 for ; Tue, 30 Apr 2019 20:43:57 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0E8120059 for ; Tue, 30 Apr 2019 20:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556682236; x=1588218236; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=R0de9+a/FN1lq4B83+WTd7hB1DvWR2KxMzNyPz8+paA=; b=28GHtOvMfVwzNuvQOJrrS1qHYuQcJOy1Gx/BsSc1VuIl6mJ3uAM+lIFK JKPBNsV3rcciGtKKNWE4yghjqdK+Dutun+HideCJYzNwSzRiNVN6BxOJ1 q/B/bn/K5u3l1F+uGSqfvgTWLB2mdikxpvMifLz4jM7igEwYHVtjBJ0bL JeDjHQVD1dPAiqFrWnBF+bKNXCVxAOvhyQ74imndl0yAE/YbVammv754D /Garug0GquhjS8VUUdrqrx77uf7x82F5vyo+dFfuFftoxhfY2G+85CBsd fw+nqE4jVaJXz0iwuzMz5rWM4sFhru2qFTrsvNKkRw90xMOJhCv8tlsCH A==; X-IronPort-AV: E=Sophos;i="5.60,416,1549882800"; d="scan'208";a="59660929" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 May 2019 15:43:45 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 May 2019 15:43:45 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 1 May 2019 15:43:45 +1200 From: Peter Gutmann To: ilf , "openpgp@ietf.org" Thread-Topic: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails Thread-Index: AQHU/1BxnC95R2AdXECuW021B845SqZVoVIS Date: Wed, 1 May 2019 03:43:44 +0000 Message-ID: <1556682221576.82651@cs.auckland.ac.nz> References: <20190430122932.GD1456@zeromail.org> In-Reply-To: <20190430122932.GD1456@zeromail.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 03:44:00 -0000 ilf writes:=0A= =0A= >https://github.com/RUB-NDS/Johnny-You-Are-Fired=0A= >https://raw.githubusercontent.com/RUB-NDS/Johnny-You-Are-Fired/master/pape= r/johnny-fired.pdf=0A= =0A= Thus confirming Shamir's law, "crypto is bypassed, not attacked". When I g= et=0A= asked to perform a security assessment of something involving crypto, I loo= k=0A= for the crypto code, ignore it, and look at the code next to it. I've neve= r=0A= failed to find vulns there. =0A= =0A= Crypto code in software is a beacon pointing you to where to the=0A= vulnerabilities are.=0A= =0A= Peter.=0A=