Re: a proposed change to JSON output to report verification of PGP/MIME signatures.

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

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.
> 
> [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└┬╴multipart/signed 80029 bytes
2 ├┬╴multipart/mixed 78178 bytes
3 │├╴text/plain 699 bytes
4 │└╴text/plain attachment [a_dancing_monkey.png] 76978 bytes
5 └╴application/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=mbox.

> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]