Message-ID: <4D4C37B0.1090202@fifthhorseman.net>
Date: Fri, 04 Feb 2011 12:30:24 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7
MIME-Version: 1.0
To: micah anderson <micah@riseup.net>
Subject: Re: new "crypto" branch providing full PGP/MIME support
References: <4CF15D67.1070904@fifthhorseman.net>
	<87aak08fu8.fsf@servo.finestructure.net>
	<87fwsf9mip.fsf@servo.finestructure.net>
	<87tygl29vu.fsf@servo.finestructure.net>
	<87hbclkrvh.fsf@algae.riseup.net>
	<4D4B0761.7040603@fifthhorseman.net>
	<87r5bn68hs.fsf@algae.riseup.net>
In-Reply-To: <87r5bn68hs.fsf@algae.riseup.net>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="------------enigC2820EB67D53802FCCAABF1E"
Cc: notmuch <notmuch@notmuchmail.org>
Precedence: list

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC2820EB67D53802FCCAABF1E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 02/04/2011 11:59 AM, micah anderson wrote:
> On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor <dkg@fifthhorse=
man.net> wrote:
>> when you say "encrypted by" do you mean "encrypted to"?  do you have
>> access to the corresponding secret key?
>=20
> If I open a message that was sent to me and was encrypted by the sender=

> using a key that they have since revoked, or has expired, I saw this.

so you hold key A, the sender holds key B, they encrypt the message with
B, and then revoke key B, and then you try to read the message (without
holding key B)?

or are you saying you hold key A, sender holds key B, they encrypt to A,
*sign* the message with B, and then revoke B?  If it's this case, does
the same thing happen even if the message is not encrypted?

Sorry for the nit-picking pedantry here -- I'm trying to get a clear
workflow for a test case.

> Most humans I know reference their key by the keyid, where keyid means
> the 8 character representation of their key. When they need to ensure
> that their key is not being spoofed they either rely on the tools to do=

> cryptographic verification, or inspect the fingerprint. I dont think
> moving towards using a longer format of the keyid helps here. The key i=
s
> unknown, and to get it known requires going through a key signing
> process, or fingerprint verification, which isn't aided by having a
> longer form keyid.=20
>=20
> If I am presented with a short form keyid, and I go and try and receive=

> that key from the keyservers and then I am presented with two different=

> options, then I'm going to inspect the two and determine then which one=

> is the right one. I dont need to front-load that knowledge in the
> interface.

and if you're presented with only one key, you will just accept that
one?  that puts you at the mercy of the network (or the keyserver
operator at least, and we can't all have the luxury of being or knowing
the keyserver operator directly).

If you're arguing "i would like to be able to recognize the key by
32-bit key ID" i don't think it's actually possible to do so because of
the spoofability; a tool that provides cryptographic assurances should
discourage attempts to make the user vulnerable to spoofing.

If you're saying we should remove the 64-bit keyID entirely and just say
"signature from unknown, non-validated key", i think that's a defensible
position, though it's not one i would take.

>> is this really a use case worth bothering with?
>=20
> No.

:)

>> do you have a suggestion for how you think it should behave
>> differently?
>=20
> I think my suggestion was already made: short form.

and as i said above, i think this is a mistake if we're trying to
provide tools that give cryptographic assurances.

thanks for the testing and the corner cases!

	--dkg


--------------enigC2820EB67D53802FCCAABF1E
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.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQJ8BAEBCgBmBQJNTDewXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD
Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpImAP/3/b21EHQZrKjVA5dYuPhAfN
WUbz2U6bvZ5RCE7FJpf5yuFHIefuCdEYH9DW9tsqlzeBJ9NvvuPibwZa381LsTQb
kvLGrzqNuoy6kjBVb0nQvomPrJZEEtyUEO/SkZKyTkFB0ihdRtDRKXjFOXij70yc
4P3CwEm/09L8ovrTBy6/93WluziK7e2v/0s1vbxIk0OL0O/E2AKcN8UBdjl7mVTK
MFAxiWtOgplLjx1hyOSVlOecGzk4+IkeAy5iHj1k1Nsq0hp2u+iZJDs3ewirzlzM
9YWM5hEa0MDrwVCTyfIjF0Rl0nRIEqBJ43JNhDeCRlxMTB36LTG8x0EM56T403lN
IDLUXj1/4DGHlF0/f5+ezglvObdV6PmxtxGRYUtHcFQqoYVMOXPQ84CFWXq5RZth
xJDEDt5AFnnstrBnXNZyh9m3kaQE6YvV38dj+zZDU76zIA62MTjaUSHLVY7LLWsG
cjehEmgkDklkrT+VGdzO6qASAByNt06afvEJ1ZdQfdWBwfntbCfAE6SRBt+QCXGu
+vnApCXWfFLLaOEZ9zAm391W2RvhSH6uqZkQh0QQZHjB9VBzkgI1e083SF+EKSK2
FhvjRrcuIRn7qVYUcOCB+G5ryolwGr5yIc/iK3zDhFpMgHEK78YSyTXF9bqpikOR
9UnkbGXHbMyMCtAtMsMB
=oXES
-----END PGP SIGNATURE-----

--------------enigC2820EB67D53802FCCAABF1E--