new "crypto" branch providing full PGP/MIME support

[Daniel Kahn Gillmor]

On 02/04/2011 11:59 AM, micah anderson wrote:
> On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>> when you say "encrypted by" do you mean "encrypted to"?  do you have
>> access to the corresponding secret key?
> 
> 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 is
> 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. 
> 
> 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?
> 
> No.

:)

>> do you have a suggestion for how you think it should behave
>> differently?
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/344de8a8/attachment-0001.pgp>