choosing an encryption target from a User ID

[Ingo Klöcker]

On Friday 25 September 2009, Daniel Kahn Gillmor wrote:
> On 09/24/2009 04:56 PM, Ingo Klöcker wrote:
> > Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created
> > with PGP 6 (or earlier) where the user ID is not UTF-8 encoded?
>
> hm; 0xCB0D4CAF looks to me like it expired 5 years ago; and
> 0xAB1BC4E6 doesn't appear to be available on the public keyservers at
> all.

I guess that's just my luck picking exactly those two keys in my keyring 
that have either expired or are not publically available. :-)


> Do you have any examples that are both public and still valid?

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)


> RFC 2440 (over a decade ago) mandates UTF-8 for user IDs:
>
>   http://tools.ietf.org/html/rfc2440#section-5.11

I'm fully aware of this.


> > Moreover, user IDs are not unique while key IDs (usually) are. So
> > if you want to be sure that the correct key is used you cannot use
> > the user ID.
>
> 8-xdigit key IDs are fairly easy to replicate with today's hardware,
> so relying on their uniqueness is not a good idea from a security
> perspective.  Full 40-xdigit fingerprints are probably effectively
> unique for the time being, though.

True. Actually, I lied about KMail using key IDs. Since about 6.5 years 
KMail uses gpgme and leaves all of those hairy details (like telling 
gpg what keys to use) to this library.


> You're not the first person to suggest that supplying the key ID (or
> fingerprint) directly is the best approach, but doing this just moves
> a serious problem from GnuPG onto the shoulders of the user (or their
> MUA or other tools).
>
> The problem that gets shifted in this case is: what key should you
> use to encrypt data to a specific person?  This is a potentially
> complicated problem, and the right answer changes in the face of
> changed/updated/revoked certifications, expirations, altered trust
> relationships, etc.  Asking the user (or their MUA) to hard-code a
> single key ID means that you're asking them to ignore all these
> possible changes when they happen.

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.


> Asking every MUA to implement their own mapping from User IDs to key
> IDs seems like a recipe for either weird divergence (should kmail
> select a different key than enigmail for foo at example.org?)

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.


> or plain  
> insecure mappings (e.g. an MUA developer who doesn't understand the
> problem of certificate validation as well as the GnuPG developers).

Full ACK. That's why MUA developers should use gpgme or an appropriate 
binding.


> Since most of these tools rely on gpg as a backend, implementing a
> more-reasonable choice in gpg seems like a good idea.



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/20090925/231b32a9/attachment-0001.pgp>