choosing an encryption target from a User ID

[Daniel Kahn Gillmor]

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.

Do you have any examples that are both public and still valid?  RFC 2440
(over a decade ago) mandates UTF-8 for user IDs:

  http://tools.ietf.org/html/rfc2440#section-5.11

> 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.

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.

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?) or plain insecure
mappings (e.g. an MUA developer who doesn't understand the problem of
certificate validation as well as the GnuPG developers).  Since most of
these tools rely on gpg as a backend, implementing a more-reasonable
choice in gpg seems like a good idea.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090925/08661186/attachment.pgp>