From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 644DF40DBC8 for ; Tue, 16 Nov 2010 12:07:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org 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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMGgvUSC215U for ; Tue, 16 Nov 2010 12:07:02 -0800 (PST) Received: from rodolpho.mayfirst.org (mail.freitas.net [209.234.253.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id DC68F40DDCB for ; Tue, 16 Nov 2010 12:07:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rodolpho.mayfirst.org (Postfix) with ESMTP id 5F1CB3CD51 for ; Tue, 16 Nov 2010 15:06:58 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at rodolpho.mayfirst.org Received: from rodolpho.mayfirst.org ([127.0.0.1]) by localhost (rodolpho.mayfirst.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBgswJ46eZUX for ; Tue, 16 Nov 2010 15:06:58 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: smtpauth@rodolpho.mayfirst.org) with ESMTPSA id 17BFB3CD4C Message-ID: <4CE2E45C.7080206@fifthhorseman.net> Date: Tue, 16 Nov 2010 15:06:52 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100918 Icedove/3.1.4 MIME-Version: 1.0 To: notmuch Subject: Re: a proposed change to JSON output to report verification of PGP/MIME signatures. References: <4CDE4486.2050101@fifthhorseman.net> <87hbfhdpa6.fsf@yoom.home.cworth.org> In-Reply-To: <87hbfhdpa6.fsf@yoom.home.cworth.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD73B070CC388B68353460BAC" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: notmuch List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 20:07:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD73B070CC388B68353460BAC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/16/2010 02:47 PM, Carl Worth wrote: > The current linearization of parts is a bug that should be fixed. And I= > think several aspects of your proposal are effectively workarounds for > this bug. So I'd rather we fix the json output to emit the tree > structure first, and then see what parts of the proposal can be > eliminated. >=20 > [And I think David Edmondson's reply said the same as above, but with > more detail. Right?] ok, good to know. that makes sense to me, and i'll plan my work around the idea of future tree-structured output. i didn't know whether the linearized output was considered a feature or not. tree-structured output makes me happier. > The only other piece I think I'd like to see is actually making the > content of the signature pieces available in the json output. Then, a > client could do its own verification. once we have tree-structured output, we'd only need to be able to request a literal byte-stream of any mime-part. so if the mime parts were structured this way: 1=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 80029 bytes 2 =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 78178 bytes 3 =E2=94=82=E2=94=9C=E2=95=B4text/plain 699 bytes 4 =E2=94=82=E2=94=94=E2=95=B4text/plain attachment [a_dancing_monkey.png]= 76978 bytes 5 =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] = 892 bytes then the client would need to be able to extract a clean (untampered, internal-headers included) copy of part 2, to verify against the signature found in part 5. Note that "notmuch part" currently emits only the content of the emitted parts. it strips off the internal mime headers, and apparently does some form of content mangling too (base64 decoding, etc). this is unacceptable for the purposes of signature verification. Maybe notmuch part needs a --unfiltered flag or something? Note also that clients that are willing and able to parse mime structures themselves can already do the signature verification themselves by fetching the whole thing with --format=3Dmbox. > Then if we had that would we not want to add the --verify support into > notmuch? (My guess is that we still would want it.) i think it's a good idea to enable verification on the backend, because we don't want to force each frontend author to reinvent the wheel. I also think it's a good idea to enable the possibility of frontend verification for frontends who want to do that (e.g. if i ever use a notmuch-based webmail app, i want my OpenPGP keyring stored on my local machine, not on the web server. so i'd want my verification to happen on the locally-trusted hardware, too, not on the web server. --dkg --------------enigD73B070CC388B68353460BAC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJM4uRcAAoJEMzS7ZTSFznpExsP/3rBPdB/ExCz50ECwxoDSFuu ER7GEZX3H1ZrQMDg+jb0qodZCbN8Ov3awE6zGqfDI+L3ZbV8vCbud3kSFv19PcwK 4LNLUW9RwhxtZWmse0WCZ85m7QrZi/g/pv4dc2YeFqmpuEvxIPp5zAkRGPgOumjp XgKvTf1FUfYu78oMGxWtZT0+sawEbVjXm2tp+5Resm42g7wi5SwL5vLhDsxHAUik stlAR+VrM8sKeHk8CyATVU6Tgcwr6CdLSBweNYhC05q6v0/g06QIib4GF3liaDXd IUYdT62HznL2VH9PqNLpcloFASEbDX5EFOBRGVDA6iI+JttdKPlmu+qqY9PI+WzC jMu19Q4U5cVN/qNGuqC3KBSGQd92tainBqMTYcE8W1nfX0d0IYl76xoLFmwQuOIZ gbjq7LKqjMfUtPqZZiRQT05dmbVdQWx46a/fkO15jWjbS5AZuWvEmlqj48dyE4Tz MxKGf3CSkDj0Ug6A5/B3A/u4/uPsCsAtLSEk6AAcOgeN3mI/NQLKpK2t1VFNhnbo 8ZdTc+D4pYTxN2yO2Vcvb/tulpZlxteeF/hMDb4Gg15NJZhqr38U31f5nbMTC8zI 3n2eJkxaLEM0oH72+PmKlPvdoR4pc2SXM/mVEcw66mTD6N3KjvXxOYlkLaianhQN MFWcvImF2mZX8MbLeYXH =qwDR -----END PGP SIGNATURE----- --------------enigD73B070CC388B68353460BAC--