Re: [RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[notmuch-archives.git] / 69 / eafb029373453206dc8a34e2676168a903dcc7

Return-Path: <jon@callas.org>\r
X-Original-To: notmuch@notmuchmail.org\r
Delivered-To: notmuch@notmuchmail.org\r
Received: from localhost (localhost [127.0.0.1])\r
        by olra.theworths.org (Postfix) with ESMTP id 6A55A431FB6\r
        for <notmuch@notmuchmail.org>; Mon, 17 Jan 2011 18:20:56 -0800 (PST)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: 1.274\r
X-Spam-Level: *\r
X-Spam-Status: No, score=1.274 tagged_above=-999 required=5\r
        tests=[RDNS_NONE=1.274] autolearn=disabled\r
Received: from olra.theworths.org ([127.0.0.1])\r
        by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
        with ESMTP id 0oPYLTtvoRJ3 for <notmuch@notmuchmail.org>;\r
        Mon, 17 Jan 2011 18:20:54 -0800 (PST)\r
X-Greylist: delayed 375 seconds by postgrey-1.32 at olra;\r
        Mon, 17 Jan 2011 18:20:54 PST\r
Received: from merrymeet.com (unknown [173.164.244.100])\r
        by olra.theworths.org (Postfix) with ESMTP id 762D3431FB5\r
        for <notmuch@notmuchmail.org>; Mon, 17 Jan 2011 18:20:54 -0800 (PST)\r
Received: from localhost (localhost [127.0.0.1])\r
        by merrymeet.com (Postfix) with ESMTP id 1E45C2E11C\r
        for <notmuch@notmuchmail.org>; Mon, 17 Jan 2011 18:14:53 -0800 (PST)\r
Received: from merrymeet.com ([127.0.0.1])\r
        by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024)\r
        with ESMTP id 12997-04 for <notmuch@notmuchmail.org>;\r
        Mon, 17 Jan 2011 18:14:48 -0800 (PST)\r
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97])\r
        (Authenticated sender: jon)\r
        by merrymeet.com (Postfix) with ESMTPA id 906D52E05B\r
        for <notmuch@notmuchmail.org>; Mon, 17 Jan 2011 18:14:48 -0800 (PST)\r
Received: from [10.0.23.19] ([173.164.244.98])\r
        by keys.merrymeet.com (PGP Universal service);\r
        Mon, 17 Jan 2011 18:14:34 -0800\r
X-PGP-Universal: processed;\r
        by keys.merrymeet.com on Mon, 17 Jan 2011 18:14:34 -0800\r
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP\r
        certification\r
Mime-Version: 1.0 (Apple Message framework v1082)\r
From: Jon Callas <jon@callas.org>\r
In-Reply-To: <4D34F133.3000807@fifthhorseman.net>\r
Date: Mon, 17 Jan 2011 18:14:31 -0800\r
Message-Id: <AFC1EADB-7F7E-4090-A858-8C0012C9ED94@callas.org>\r
References: <4D34F133.3000807@fifthhorseman.net>\r
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>\r
X-Mailer: Apple Mail (2.1082)\r
Content-Type: text/plain; charset=us-ascii\r
Content-Transfer-Encoding: quoted-printable\r
X-Virus-Scanned: Maia Mailguard\r
X-Mailman-Approved-At: Tue, 18 Jan 2011 12:27:11 -0800\r
Cc: notmuch <notmuch@notmuchmail.org>\r
X-BeenThere: notmuch@notmuchmail.org\r
X-Mailman-Version: 2.1.13\r
Precedence: list\r
List-Id: "Use and development of the notmuch mail system."\r
        <notmuch.notmuchmail.org>\r
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
        <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
List-Post: <mailto:notmuch@notmuchmail.org>\r
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
        <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
X-List-Received-Date: Tue, 18 Jan 2011 02:20:56 -0000\r
\r
On the one hand, my only disagreement with you is to suggest that your =\r
proposal be tied into using SHA256 for a fingerprint. If you're going to =\r
expand the keyid to a fingerprint, why not get a better fingerprint?\r
\r
On the other hand, this has never been a problem. It's harder than you =\r
think, because you have to generate a new key each time, which takes a =\r
while on RSA.=20\r
\r
Nonetheless, I think it's a good idea. I'd just go all the way to a =\r
better fingerprint.\r
\r
        Jon\r
\r
\r
On Jan 17, 2011, at 5:47 PM, Daniel Kahn Gillmor wrote:\r
\r
> * PGP Signed by an unknown key\r
>=20\r
> Hi OpenPGP folks (and Cc'ed notmuch developers/users)--\r
>=20\r
> Some recent discussion about verifying OpenPGP signatures for the\r
> notmuch mail user agent got me thinking about different ways one might\r
> interpret a negative result from a signature made over a message.\r
>=20\r
> Most OpenPGP signatures i've seen use the (unhashed) issuer subpacket =\r
to\r
> refer to the low 64 bits of the fingerprint of the issuer's key (the\r
> issuer's "key ID"):\r
>=20\r
> https://tools.ietf.org/html/rfc4880#section-5.2.3.5\r
>=20\r
> Given that we can't assume that key IDs are unique with any high =\r
degree\r
> of confidence, this creates some ambiguity between these states:\r
>=20\r
> A) "you don't have the key that made this signature"\r
>=20\r
> B) "this signature is bad"\r
>=20\r
> a user-friendly MUA that thinks it is in state A might do something\r
> sensible like offer to do a keyserver lookup (if it is online), while\r
> simply reporting "signature error" if it thinks it is in state B.\r
>=20\r
> But a devious attacker could potentially create a colliding Key ID (i\r
> believe collisions of the low 64 bits of SHA1 are within reach today,\r
> i'd love to be corrected if this is not the case) and cause the\r
> user-friendly MUA to assume it is in state B when it is actually in\r
> state A.  The attacker doesn't even need access to the message or\r
> signature in question to do this.  They'd only need to have been able =\r
to\r
> supply a key to the user at some time in the past.  (e.g. push a new\r
> subkey to the keyservers which a user pulls during a keyring refresh)\r
>=20\r
> One way around this ambiguity would be to include the issuer's entire\r
> fingerprint instead of just the low 64 bits, which would make the\r
> certainty of state A vs. state B much clearer.\r
>=20\r
> Would there be any objection to a new subpacket type for OpenPGPv4 =\r
that\r
> would include the remaining 96 bits of the issuer's fingerprint?  (the\r
> "high 96" proposal)\r
>=20\r
> Alternately, what about a new subpacket type that simply includes the\r
> entire 160 bits of the issuer's fingerprint?   (the "full fingerprint"\r
> proposal)\r
>=20\r
> A third proposal would be a new subpacket type that simply includes =\r
the\r
> entire public key of the issuer (the "full pubkey" proposal).\r
>=20\r
> I lean toward "high 96", since using it in conjunction with the issuer\r
> subpacket retains backward compatibility with existing tools (which =\r
know\r
> how to interpret the issuer subpacket) while introducing the smallest\r
> amount of additional data per signature.\r
>=20\r
> Given that the size of a signature from a 2048-bit RSA key is 256 =\r
bytes\r
> already, adding an additional 12 bytes (plus a few bytes of subpacket\r
> overhead) per signature doesn't seem particularly excessive.\r
>=20\r
> I'm also assuming that the typical use of this subpacket would be in =\r
the\r
> unhashed section of a signature packet, since it is an advisory field\r
> and not intended to address attacks against an adversary capable of\r
> tampering directly with the data in the signature itself.\r
>=20\r
> I will write code to implement this using an experimental subpacket =\r
ID,\r
> but i'd like to know if anyone has any caveats, concerns, or =\r
preferences\r
> between the proposals i've outlined above (or entirely different\r
> proposals that would address the underlying concern).\r
>=20\r
> Any thoughts?\r
>=20\r
> Regards,\r
>=20\r
>       --dkg\r
>=20\r
>=20\r
> * Unknown Key\r
> * 0xD21739E9\r
\r