Message-ID: <4CE2E45C.7080206@fifthhorseman.net>
Date: Tue, 16 Nov 2010 15:06:52 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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 <notmuch@notmuchmail.org>
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>
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="------------enigD73B070CC388B68353460BAC"
Precedence: list
Reply-To: notmuch <notmuch@notmuchmail.org>

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--