Wish: group support for Kmail and gnupg

Werner Koch wk at gnupg.org
Thu Nov 30 12:32:25 CET 2006


On Thu, 30 Nov 2006 12:15, bernhard at intevation.de said:

> Actually the association from key to user id (including) email address
> happens on the gpg level already. So having several clients

That is coincidence.  A key does not need to have an email address.
Well, most do but it is not a requirement of gnupg.

> like KMail, mutt and other frontends that can make use of this information,
> this information is best maintained at the same level than the user ids.

Frontends have much more information about email adresses.  They need
to handle To, Cc and especailly Bcc - gpg does not know about this.
MUAs can also keep track of communication patterns and assign trust to
a key by looking at these patterns.  I hope this will eventually be
implemented.

Adding this stuff to gpg will finally add knowledge about email to it
which is not the Unix way.  I even hesitated to add PKA to gpg but
this is an exception because no other way to implement it exists.

> It solves an important use case: I know that more than one person
> is behind one email address, having several keys. I want to send there.

For me it jutts works adding these addresses to a --group.  It is more
of a problem with some MUAs.  Then again it should be fixed in the
MUA.

> As I can ask for user ids over gpgme, I would expect this to be available
> via gpgme and not via the configure interface.

No, it is not a key, it does not work.

> The use case described above is real and to promote encryption,
> it should be made easier to solve for frontends.

So where is the actual problem you want to solve?  It is Mutt, which
checks each recipient's key validity instead of leaving this to gpg.
Right?




Shalom-Salam,

   Werner




More information about the Gpa-dev mailing list