choosing an encryption target from a User ID

[Ingo Klöcker]

On Monday 28 September 2009, Daniel Kahn Gillmor wrote:
> On 09/25/2009 02:40 PM, Ingo Klöcker wrote:
> > 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo
> > Klöcker went to the same school and the same university as I did.)
> >
> > 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822,
> > 0x91190EF9 (this last one is definitely still in use)
>
> ok, thanks, those are not expired, though i only see non-unicode in
> three of them:  104B0FAF and F661F608, and 91190EF9.
>
> Those keyholders should probably create a new User ID that *is*
> UTF-8, with the same e-mail address as the non-UTF-8 one, and
> encourage the people who have certified the old User ID to re-certify
> the new one. Once enough certifications are through on the new, valid
> one, they can revoke the old one and move forward with a fully
> OpenPGP-compliant key.

Yes, I suppose this would be a sensible solution.


> > I don't see why harmless changes (see David's example) shouldn't be
> > ignored. If the user hard-coded the key Alice1, then what's wrong
> > with using this key as long as it's valid. Obviously, any changes
> > making a hard-coded key invalid need to be escalated and such a key
> > must not be used anymore by the MUA.
>
> If the user hard-coded a specific key (by fingerprint) to the Alice
> User ID, then of course GPG should respect that preference (and it
> should emit warnings if the key ever becomes invalid),  but i don't
> think that users should be asked to make permanent choices like this,
> since they might become invalidated by future circumstances; how will
> they know that another (maybe better) choice is available, or should
> be made?

If Alice does not tell them, then they might not know this. But I'm not 
sure whether this is a common problem or more an academic problem. 
Let's say Alice loses her first key and cannot revoke it because she 
didn't create a revocation certificate. She creates a new key, but Bob 
continues to use the old key. Unless Bob automatically imports unknown 
keys, he will notice that Alice now uses a different key because he 
cannot verify her signature anymore. And if Bob uses the old key to 
send an encrypted message to Alice, Alice will surely tell him what 
happened. So I don't really see the problem with a hardcoded choice.


> > If for some email address multiple matching valid keys are found by
> > KMail (or rather gpgme) then KMail asks the user which key(s) to
> > use (and then remembers the user's choice). This transparency gives
> > me a better feeling than some automagic behind-my-back key
> > selection based on user ID/email address.
>
> I hear what you're saying, but i think there are two problems with
> it:
>
>  0) for many users, they are being asked to make a choice that they
> don't understand; there are few things more frustrating than this. 
> If the tool *can* make a good choice based on the knowledge available
> to it, it shouldn't need to pester the user, who may or may not have
> as much understanding of the problem space.

I agree, but I also disagree. I agree that it's preferable to save the 
user from having to make a choice. But then again I disagree about 
the "not have as much understanding of the problem space". People who 
do not understand to a certain degree how the WoT works would be better 
off using a centralized PKI. IMO this is a major weakness of the WoT.


>  1) users are being asked to make an effectively permanent decision,
> even though relevant circumstances may change in the future.
> Presumably, this binding will produce warnings (with the option to
> change the binding) if the bound key suddenly actually drops into
> unknown calculated validity (for example, if you decide to revoke
> ownertrust on a relevant intermediary; has this been tested?)  But
> there might be other changes that make this selection suboptimal
> without causing it to throw warnings.

See above. I wonder how much of a real problem this is. How many people 
have multiple valid keys bound to the same email addresses? What is the 
use case for having multiple valid keys bound to the same addresses?

In the past, when I worked at the university, I used a private/home key 
and a work key. At home I could read anything. At work I could only 
read messages encrypted with my work key. So anything I was supposed to 
read at work needed to be encrypted with my work key. To make things 
more complicated my home key did have my work address as one user ID. 
So hardcoding my work address to my work key was basically mandatory.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20090929/9334917a/attachment.pgp>