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.
> 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.
This seems like a reasonable stance for authors of MUAs and Plugins to
use. Werner, it looks like you're the upstream author on GpgME; does
GpgME do any different selection technique than GPG?
> 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 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.
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.
so i'm not a big fan of prompting users to hardcode bindings in general
(though i certainly support allowing users to hardcode bindings if they
prefer)
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
