Wish: group support for Kmail and gnupg

[Bernhard Reiter]

On Thursday 30 November 2006 12:32, Werner Koch wrote:
> 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.

I know that it is not a requirement, but it is handy to get
the additional data of a key, like the uids.
This makes key management easier and this is important
for the solution to be secure.

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

Well I agree. The question to me is: On which level should what
be implemented. The knowledge which uidinformation belongs to
which group of keys is something that I would want to share 
with all my MUAs anyway. So implementing this within each MUA
is not a good idea. 

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

I only propose to add a mapping
	uid -> n* keys
if uid includes an email address, fine. If not: still good.

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

To do this I would want the MUAs to use gpgme because they will otherwise
have to implement another interface to GnuPG which makes it more complicated
and error prone I believe.

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

It works for other uid information like the email addresses,
if I remember correctly.

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

I want to solve it both for mutt and KMail/Kontact
and while doing this also for Claws getting the design right.

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20061206/62e02d28/attachment.pgp