Wish: group support for Kmail and gnupg

[Bernhard Reiter]

On Wednesday 29 November 2006 18:03, Werner Koch wrote:
> On Wed,  8 Nov 2006 11:00, bernhard at intevation.de said:
> > The alternative: Associate several keys with one email adress oder
> > identifier on client level. This seems more cumbersome to me.
>
> That is in fact the only solid way to implement it.  

I am unsure about this.
Actually the association from key to user id (including) email address
happens on the gpg level already. So having several clients
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.

Doing this sort of associations in frontends will multiply the place
where it would need to be configured.

> The --group 
> sopport in gpg was a hack and I always feared the problems.

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.

> > To improve the current situation is would be a good next step to have
> > KMail make it possible to select a gnupg group from the interface when
> > it is looking for a key for an email address.
> > For this gnupg must somehow provide the list of groups on request.
> > Werner: Do we have such a method in gpgme already?
>
> $ gpg --with-colons --list-config group
>
> Returns a listing of all defined groups.  This does not use the
> configure interface, though.  

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

> I am still not convinced that the group 
> feature is a good idea.  

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

> To implement it properly we need anotehr 
> database to store these aliases - using the configure file is a hack
> which does not scale.

I cannot say much about the implementation side.

> I thinking of a gpgk daemon to manage keys - with such a new
> infrastructure we could easily add aliases.  But it is all not a good
> solution: The receiving MUA does not know about this mapping and may
> want to complain about a mismatch in the addresses used in the mail
> and those used in the key to encrypt it.

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
Url : /pipermail/attachments/20061130/44b7c0ff/smime.bin